Cas d'usage réels

Ce qu'Ansible et AWX
peuvent faire pour vous.

Vous gérez une infrastructure Linux et réseau de façon manuelle ? Ces exemples concrets montrent comment des équipes IT réduisent le travail répétitif de semaines à minutes — sans expertise DevOps préalable.

Ansible, c'est quoi ?

Ansible est un outil open-source qui permet de décrire l'état souhaité de vos serveurs dans des fichiers YAML appelés "playbooks". Vous écrivez ce que vous voulez obtenir, Ansible se charge de comment l'appliquer — sur 1 ou 1 000 machines simultanément, sans agent à installer.

Il communique via SSH standard. Aucun logiciel supplémentaire sur vos serveurs. Aucune formation Bash avancée requise.

AWX, c'est quoi ?

AWX est l'interface web open-source qui orchestre Ansible à l'échelle. Là où Ansible s'exécute depuis un terminal, AWX offre une interface graphique pour lancer vos playbooks, gérer vos inventaires de serveurs, programmer des exécutions planifiées et centraliser les logs d'exécution.

C'est Ansible avec une tour de contrôle : gestion des droits, historique complet, API REST, webhooks Git intégrés.

Pourquoi Autoflow ?

Déployer AWX from scratch prend plusieurs jours : reverse proxy, certificats TLS, base de données, configuration réseau. Autoflow prépackage AWX avec une PKI interne, Gitea (SCM), Grafana (monitoring) et un wizard de déploiement — opérationnel en 15 minutes, même en environnement air-gap.

Les exemples ci-dessous fonctionnent tous sur une installation Autoflow standard.

Infra & Serveurs

Provisioning automatique de serveurs Linux

Transformer une machine vierge en serveur production-ready en moins de 10 minutes, de façon identique à chaque fois.

Le problème sans automatisation

Imaginez devoir configurer 50 serveurs RHEL ou Ubuntu pour un nouveau client. Sans automatisation, chaque serveur prend 45 minutes à configurer manuellement : installation des paquets, configuration réseau, sécurisation SSH, NTP, monitoring... Multipliez par 50, ajoutez le risque d'erreur humaine sur chaque étape, et vous comprenez pourquoi les équipes ops passent des semaines sur des tâches répétitives.

Comment Ansible + AWX le résout

Ansible résout ce problème avec un "playbook" — un fichier YAML qui décrit l'état final souhaité du serveur. AWX exécute ce playbook en parallèle sur tous vos serveurs simultanément, depuis une interface web. Aucune connexion SSH manuelle. Aucune étape oubliée.

8 min Temps de provisioning
0 Erreurs de config
100% Reproductibilité
Voir la démonstration Ansible : Premiers pas avec les Playbooks
provisioning.yml
---
- name: Provisioning serveur Linux
  hosts: new_servers
  become: true
  vars:
    base_packages:
      - curl
      - vim
      - git
      - fail2ban
      - auditd
    ntp_servers:
      - 0.fr.pool.ntp.org
      - 1.fr.pool.ntp.org

  tasks:
    - name: Mise à jour du cache apt
      apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Installation des paquets de base
      apt:
        name: "{{ base_packages }}"
        state: present

    - name: Configuration du fuseau horaire
      timezone:
        name: Europe/Paris

    - name: Sécurisation SSH (désactivation root)
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^PermitRootLogin"
        line: "PermitRootLogin no"
      notify: restart sshd

    - name: Activation fail2ban
      service:
        name: fail2ban
        state: started
        enabled: true

Hardening sécurité CIS Benchmark

Appliquer automatiquement les 200+ contrôles du standard CIS sur l'ensemble de votre parc, avec rapport de conformité généré à chaque exécution.

Le problème sans automatisation

Le CIS Benchmark (Center for Internet Security) est le référentiel de sécurité le plus reconnu pour les systèmes Linux. Il définit des centaines de contrôles à appliquer : désactivation de services inutiles, paramètres kernel sécurisés, politique de mots de passe, audit des accès... Appliqués manuellement sur chaque serveur, ces contrôles prennent des jours et sont presque impossibles à maintenir dans le temps lorsque le parc évolue.

Comment Ansible + AWX le résout

Avec Ansible, le hardening devient un playbook idempotent : exécutez-le autant de fois que nécessaire, il amènera toujours le serveur au bon état. Autoflow le programme dans AWX pour s'exécuter automatiquement après chaque provisioning. Le rapport de conformité est archivé à chaque passage.

220+ Contrôles CIS appliqués
< 20 min Par serveur
Auto Rapport de conformité
Voir la démonstration Ansible Security Hardening — CIS Benchmarks
hardening.yml
---
- name: CIS Level 2 Hardening — RHEL 9
  hosts: production_servers
  become: true
  vars:
    cis_level: 2
    cis_rule_1_1_disable_cramfs: true
    cis_rule_3_1_ipv6_disabled: false
    cis_rule_5_3_password_policy:
      minlen: 14
      dcredit: -1
      ucredit: -1
      ocredit: -1
      lcredit: -1

  roles:
    - role: ansible-cis-rhel9
      tags: always

  post_tasks:
    - name: Génération du rapport de conformité
      command: >
        oscap xccdf eval
        --profile cis_server_l2
        /usr/share/xml/scap/ssg-rhel9-ds.xml
      register: cis_report
      failed_when: false

    - name: Archivage du rapport HTML
      fetch:
        src: /tmp/cis-report.html
        dest: "reports/{{ inventory_hostname }}-{{ ansible_date_time.date }}.html"
        flat: true

Gestion des mises à jour OS sur 100+ machines

Patcher l'ensemble d'un parc hétérogène (RHEL, Ubuntu, Debian) en rolling update, sans interruption de service, avec validation automatique avant/après reboot.

Le problème sans automatisation

La gestion des mises à jour est l'une des tâches les plus critiques — et les plus redoutées — des équipes ops. Patcher manuellement 100 serveurs, c'est du risque à chaque étape : un mauvais reboot, un service qui ne redémarre pas, un noyau incompatible. Les équipes diffèrent souvent les patchs pour éviter le risque, créant des dettes de sécurité importantes. Sans compter les nuits et week-ends pour minimiser l'impact en production.

Comment Ansible + AWX le résout

Ansible orchestre les mises à jour en "rolling update" : il patche et redémarre un lot de serveurs à la fois (par exemple 25%), en vérifiant après chaque lot que les services sont opérationnels avant de continuer. En cas d'anomalie, le processus s'arrête. AWX planifie ces runs sur des plages horaires définies.

100+ Serveurs patchés/nuit
0 h Intervention manuelle
Auto Rollback si anomalie
Voir la démonstration Ansible Patch Management — Rolling Updates
updates.yml
---
- name: Patch management — Rolling update
  hosts: all
  serial: "25%"        # 25 % des serveurs simultanément
  max_fail_percentage: 5
  become: true

  pre_tasks:
    - name: Vérification charge système
      shell: uptime | awk '{print $10}' | tr -d ','
      register: load_avg
      failed_when: load_avg.stdout | float > 2.0

    - name: Snapshot si VM (VMware/KVM)
      vmware_guest_snapshot:
        hostname: "{{ vcenter_hostname }}"
        name: "{{ inventory_hostname }}"
        snapshot_name: "pre-patch-{{ ansible_date_time.date }}"
      delegate_to: localhost
      when: ansible_virtualization_type == "VMware"

  tasks:
    - name: Mise à jour des paquets (Debian/Ubuntu)
      apt:
        upgrade: dist
        update_cache: true
      when: ansible_os_family == "Debian"

    - name: Mise à jour des paquets (RHEL)
      dnf:
        name: "*"
        state: latest
        security: true
      when: ansible_os_family == "RedHat"

    - name: Reboot si noyau mis à jour
      reboot:
        reboot_timeout: 300
        test_command: systemctl is-active sshd

  post_tasks:
    - name: Validation des services critiques
      service_facts:
      register: service_state
    - name: Échec si service critique arrêté
      fail:
        msg: "Service {{ item }} arrêté après patch !"
      when: service_state.ansible_facts.services[item].state != "running"
      loop: "{{ critical_services }}"

Réseau

Configuration automatisée de switches et routeurs

Gérer la configuration de votre infrastructure réseau Cisco et Arista comme du code — versionnée, rejouable, et auditée.

Le problème sans automatisation

La configuration réseau est l'un des derniers bastions du manuel dans les DSI. Chaque switch Cisco ou routeur Arista est configuré via une session SSH interactive, avec les risques que cela implique : erreurs de frappe, configurations divergentes entre sites, impossibilité d'auditer qui a changé quoi et quand. En cas d'incident, identifier la "mauvaise config" dans 200 switches est un exercice périlleux.

Comment Ansible + AWX le résout

Ansible dispose de modules natifs pour les équipements réseau Cisco IOS, Arista EOS, Juniper JunOS et bien d'autres. La configuration réseau devient du YAML versionné dans Git. Autoflow utilise Gitea comme SCM et AWX pour exécuter les changements — chaque modification passe par une revue de code avant d'être appliquée sur le parc.

< 5 min Déploiement 50 switches
Git Config versionnée
Zéro Session SSH manuelle
Voir la démonstration Network Automation with Ansible — Cisco & Arista
network-config.yml
---
- name: Configuration switch Cisco IOS
  hosts: cisco_access_switches
  gather_facts: false
  connection: network_cli
  vars:
    ansible_network_os: ios

    vlans:
      - id: 10
        name: PROD_SERVERS
      - id: 20
        name: DMZ
      - id: 100
        name: MANAGEMENT

    ntp_servers:
      - 192.168.100.10
      - 192.168.100.11

    syslog_servers:
      - 192.168.200.50

  tasks:
    - name: Création des VLANs
      cisco.ios.ios_vlans:
        config: "{{ vlans }}"
        state: merged

    - name: Configuration NTP
      cisco.ios.ios_ntp_global:
        config:
          servers:
            - server: "{{ item }}"
              prefer: "{{ loop.index == 1 }}"
        loop: "{{ ntp_servers }}"

    - name: Configuration Syslog
      cisco.ios.ios_logging_global:
        config:
          hosts:
            - host: "{{ item }}"
              severity: informational
        loop: "{{ syslog_servers }}"

    - name: Sauvegarde running-config → startup-config
      cisco.ios.ios_config:
        save_when: always

    - name: Archivage de la config dans Gitea
      net_get:
        src: running-config
        dest: "backups/{{ inventory_hostname }}/{{ ansible_date_time.date }}.cfg"

Déploiement de VPN WireGuard sur une flotte de serveurs

Construire un réseau privé chiffré entre tous vos serveurs — cloud, on-premise, multi-sites — en générant et distribuant automatiquement les clés cryptographiques.

Le problème sans automatisation

WireGuard est le VPN le plus performant et le plus sûr disponible aujourd'hui. Mais le configurer manuellement sur 30 serveurs répartis sur 3 datacenters, c'est un cauchemar : chaque nœud doit connaître la clé publique de tous les autres, les adresses IP du tunnel doivent être cohérentes, et la moindre erreur de configuration rompt la connectivité. Sans automatisation, ce type de déploiement mesh est réservé aux équipes avec beaucoup de temps libre.

Comment Ansible + AWX le résout

Ansible génère les paires de clés cryptographiques pour chaque nœud, collecte les clés publiques de tous les serveurs, puis distribue des configurations WireGuard cohérentes et personnalisées à chaque hôte. En 15 minutes, un réseau mesh chiffré relie tous vos serveurs — qu'ils soient chez OVH, AWS ou dans votre datacenter.

15 min Déploiement mesh complet
Auto Rotation des clés
ChaCha20 Chiffrement moderne
Voir la démonstration WireGuard VPN Automation with Ansible
wireguard.yml
---
- name: Déploiement WireGuard VPN Mesh
  hosts: vpn_nodes
  become: true
  vars:
    wireguard_port: 51820
    wg_network: "10.10.0.0/24"

  tasks:
    - name: Installation WireGuard
      package:
        name: wireguard
        state: present

    - name: Génération de la clé privée
      shell: wg genkey
      register: wg_private_key
      args:
        creates: /etc/wireguard/privatekey
      no_log: true

    - name: Stockage sécurisé de la clé privée
      copy:
        content: "{{ wg_private_key.stdout }}"
        dest: /etc/wireguard/privatekey
        mode: "0600"
      no_log: true

    - name: Dérivation de la clé publique
      shell: "cat /etc/wireguard/privatekey | wg pubkey"
      register: wg_public_key
      changed_when: false

    - name: Partage de la clé publique entre tous les nœuds
      set_fact:
        wg_public_keys: >-
          {{ wg_public_keys | default({}) | combine({
            inventory_hostname: wg_public_key.stdout
          }) }}
      delegate_to: localhost
      delegate_facts: true

    - name: Génération de la config wg0.conf
      template:
        src: wg0.conf.j2
        dest: /etc/wireguard/wg0.conf
        mode: "0600"
      notify: restart wireguard

  handlers:
    - name: restart wireguard
      service:
        name: wg-quick@wg0
        state: restarted
        enabled: true

Prêt à automatiser votre infrastructure ?

Ces exemples tournent sur Autoflow en 15 minutes. Réservez une démo pour voir votre cas d'usage spécifique en live.