Déploiement avancé et orchestration

🎯 Objectif : À la fin de ce chapitre, tu sauras orchestrer des déploiements avancés — rolling updates, canary, blue/green — et les intégrer dans un pipeline CI/CD. ⏱️ Durée estimée : 55 minutes | Niveau : Avancé

Lancer ansible-playbook deploy.yml sur 50 serveurs d’un coup en priant pour que tout se passe bien, c’est du suicide opérationnel. En production, un déploiement mal orchestré peut mettre à genoux tout un service en quelques secondes. Ce chapitre t’apprend à déployer intelligemment — par vagues, avec des filets de sécurité, et en automatisant le tout dans un pipeline CI/CD.

Pourquoi le déploiement avancé est crucial

En entreprise, un déploiement raté coûte cher. Pas juste en temps de correction — en revenus perdus, en confiance client érodée, en astreintes qui sautent à 3h du matin. La différence entre une équipe qui déploie sereinement 10 fois par jour et une qui tremble à chaque mise en production, c’est la stratégie de déploiement.

Ansible propose trois leviers fondamentaux pour maîtriser le risque :

• serial — contrôle combien de serveurs sont mis à jour simultanément
• max_fail_percentage — stoppe tout si trop de serveurs échouent
• Health checks — vérifie que chaque batch fonctionne avant de continuer

🧠 À retenir : Un bon déploiement n’est pas celui qui va vite, c’est celui qui peut s’arrêter proprement au premier signe de problème.

Comprendre les stratégies de déploiement

Rolling Update

Le rolling update déploie sur un sous-ensemble de serveurs à la fois. Si un batch échoue, seule une fraction de ton infra est touchée. C’est la stratégie la plus utilisée en production.

Le principe est simple : tu retires un serveur du load balancer, tu le mets à jour, tu vérifies qu’il fonctionne, puis tu le réintègres. Rinse and repeat.

Voici un playbook complet de rolling update avec gestion du load balancer et health checks :

---
- name: Rolling update de l'application
  hosts: webservers
  become: true
  serial: 2
  max_fail_percentage: 25

  pre_tasks:
    - name: Retirer du load balancer
      ansible.builtin.uri:
        url: "http://{{ lb_host }}/api/backends/{{ inventory_hostname }}/disable"
        method: POST
      delegate_to: localhost

    - name: Attendre la fin des connexions actives
      ansible.builtin.wait_for:
        timeout: 30

  roles:
    - app-deploy

  post_tasks:
    - name: Health check applicatif
      ansible.builtin.uri:
        url: "http://{{ inventory_hostname }}:{{ app_port }}/health"
        status_code: 200
      retries: 5
      delay: 5
      register: health
      until: health.status == 200

    - name: Réintégrer dans le load balancer
      ansible.builtin.uri:
        url: "http://{{ lb_host }}/api/backends/{{ inventory_hostname }}/enable"
        method: POST
      delegate_to: localhost

Canary et Blue/Green

Le canary est un rolling update limité à un seul serveur. Tu déploies sur une machine, tu observes les métriques, et seulement si tout va bien, tu continues sur le reste. C’est ton filet de sécurité ultime.

Le blue/green maintient deux environnements identiques. Tu déploies sur l’environnement inactif, tu vérifies, puis tu bascules le trafic d’un coup. L’avantage : un rollback instantané — il suffit de re-basculer.

💡 Tip DevOps : Utilise serial progressif pour combiner canary et rolling — commence par 1 serveur, puis 3, puis tout le reste :

serial:
  - 1        # Canary : 1 seul serveur
  - 3        # Petit batch de validation
  - "100%"   # Le reste d'un coup

Commandes et paramètres essentiels

Ansible offre plusieurs paramètres pour contrôler finement le comportement d’un déploiement. Voici ceux que tu dois connaître.

Le paramètre serial accepte un nombre fixe, un pourcentage, ou une liste progressive. max_fail_percentage définit le seuil au-delà duquel Ansible stoppe tout. Et any_errors_fatal: true est le mode “zéro tolérance” — le moindre échec arrête le déploiement.

Pour le rollback, le pattern le plus fiable est le symlink swap : chaque release est un dossier, et un lien symbolique pointe vers la version active. Voici comment implémenter un rollback propre :

---
- name: Rollback applicatif
  hosts: webservers
  become: true
  tasks:
    - name: Basculer vers la version précédente
      ansible.builtin.file:
        src: "/opt/releases/{{ rollback_version }}"
        dest: /opt/app/current
        state: link
      notify: Restart app

    - name: Vérifier la santé post-rollback
      ansible.builtin.uri:
        url: "http://{{ inventory_hostname }}:{{ app_port }}/health"
        status_code: 200
      retries: 5
      delay: 3

Pour déclencher un rollback, une seule commande suffit :

ansible-playbook rollback.yml -e "rollback_version=v2.3.1"

⚠️ Attention : Sans mécanisme de rollback préparé à l’avance, tu te retrouves à improviser sous pression. Toujours avoir un plan B déjà codé et testé.

Cas concret : pipeline CI/CD en entreprise

🔥 Cas réel : Une équipe e-commerce avec 12 serveurs web derrière un load balancer. Chaque push sur main déclenche : tests → déploiement staging → smoke tests → déploiement production en rolling update. Tout est automatisé via GitHub Actions + Ansible.

Voici le workflow GitHub Actions qui orchestre le déploiement complet, du push Git jusqu’à la production :

name: Deploy with Ansible
on:
  push:
    branches: [main]

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - name: Install Ansible
        run: pip install ansible

      - name: Setup SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519

      - name: Deploy staging
        run: |
          ansible-playbook deploy/site.yml \
            -i deploy/inventory/staging.yml \
            --vault-password-file <(echo "${{ secrets.VAULT_PASSWORD }}") \
            -e "app_version=${{ github.sha }}"

      - name: Smoke test
        run: curl -sf https://staging.example.com/health || exit 1

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Install Ansible
        run: pip install ansible

      - name: Deploy production (rolling)
        run: |
          ansible-playbook deploy/site.yml \
            -i deploy/inventory/production.yml \
            --vault-password-file <(echo "${{ secrets.VAULT_PASSWORD }}") \
            -e "app_version=${{ github.sha }}" \
            -e "serial_count=2"

Pour les équipes qui ont besoin d’une interface graphique et de contrôle d’accès, AWX (version open source d’Ansible Tower) centralise tout : exécution des playbooks via le web, gestion des credentials dans un coffre-fort, RBAC pour contrôler qui peut déployer quoi, et un historique complet de chaque exécution.

L’API AWX permet aussi de déclencher des déploiements depuis n’importe quel outil. Voici comment lancer un job template via curl :

curl -X POST "https://awx.example.com/api/v2/job_templates/42/launch/" \
  -H "Authorization: Bearer $AWX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"extra_vars": {"app_version": "v2.4.0"}}'

💡 Tip DevOps : Même si tu utilises GitHub Actions, considère AWX comme couche d’abstraction. Ton pipeline CI déclenche AWX via API, et AWX gère l’exécution Ansible avec les credentials sécurisées. Ça évite de stocker des clés SSH dans les secrets GitHub.

Pièges fréquents

Pas de health check entre les batchs. Sans vérification, un rolling update peut déployer du code cassé sur 100% de tes serveurs avant que tu t’en rendes compte. Toujours valider chaque batch avec un uri + retries.

serial trop agressif. Mettre serial: "50%" sur un cluster de 4 serveurs, c’est déployer sur 2 en même temps — la moitié de ta capacité. En cas de problème, tu perds la moitié de ton service. Commence toujours petit.

Oublier le drain du load balancer. Si tu mets à jour un serveur qui reçoit encore du trafic, les utilisateurs en cours vont voir des erreurs. Toujours retirer du LB → attendre → déployer → vérifier → réintégrer.

Secrets en clair dans le CI. Ne jamais mettre les mots de passe Vault ou clés SSH directement dans les fichiers de config. Utilise les secrets de ton CI (GitHub Secrets, GitLab CI Variables) et nettoie-les en post ou always.

⚠️ Attention : max_fail_percentage: 0 combiné avec serial: 1 signifie qu’un seul serveur qui échoue stoppe tout. C’est parfait pour un canary, mais catastrophique si tu l’appliques à un rolling update classique sur un serveur instable.

Exercice pratique

Objectif : Implémenter un déploiement canary + rolling update complet.

Crée un playbook deploy-safe.yml qui fait les choses suivantes. D’abord, déploie sur 1 seul serveur (canary) avec max_fail_percentage: 0. Ensuite, lance un health check avec 5 retries. Si le canary passe, déploie sur le reste en batchs de 2 avec max_fail_percentage: 25. Ajoute un mécanisme de rollback en cas d’échec.

Voici le squelette pour te lancer :

---
# Phase 1 : Canary
- name: Canary deployment
  hosts: webservers
  serial: 1
  max_fail_percentage: 0
  tasks:
    # À toi : deploy + health check

# Phase 2 : Rolling complet
- name: Full rolling deployment
  hosts: webservers
  serial: 2
  max_fail_percentage: 25
  tasks:
    # À toi : deploy + health check + LB management

Bonus : Intègre ce playbook dans un workflow GitHub Actions qui se déclenche sur push dans main.

🧠 À retenir :

• serial contrôle le rythme — commence petit, accélère progressivement
• Canary → Rolling → Full est le pattern le plus sûr en production
• Toujours prévoir un rollback codé et testé avant de déployer
• CI/CD + Ansible = déploiements reproductibles et auditables
• AWX apporte l’interface graphique, le RBAC et l’audit trail pour les équipes

➡️ La suite

Dans le prochain chapitre, on explore le dynamic inventory multi-cloud, les custom modules et l’optimisation des performances Ansible.