Différences

Ci-dessous, les différences entre deux révisions de la page.

--- eadl:bloc4:fm4:td4 [2026/06/25 02:15] – jcheron
+++ eadl:bloc4:fm4:td4 [2026/06/25 13:14] (Version actuelle) – [8. Pourquoi systemd plutôt que nohup] jcheron
@@ Ligne 33: / Ligne 33: @@
   * Infrastructure TD2 et TD3 opérationnelle
-  * Instance EC2 accessible via SSH
+  * Instance EC2 accessible via SSH ou Session Manager
   * Dépôt GitHub disponible avec les droits d'administration
   * Java 17 et Maven installés sur le poste de travail
-<WRAP round help>
 Rappel sur les environnements d'exécution :
-  * Le poste de travail et le runner CI/CD ont besoin de Java et Maven pour **compiler** l'application
+  * Java et Maven sont nécessaires sur le **poste de travail** pour compiler l'application
-  * L'instance EC2 a besoin de Java uniquement pour **exécuter** le jar
+  * Java est nécessaire sur **l'EC2** pour exécuter le jar
   * Maven n'a pas sa place sur l'EC2 : on y dépose uniquement le jar déjà compilé
-</WRAP>
 ===== 1. Compréhension de l'application =====
@@ Ligne 61: / Ligne 59: @@
 </sxh>
-<WRAP round help>
+<WRAP round question>
-Questions de compréhension :
+Ce fichier sera commité dans Git avec le reste du code source.
-  * Pourquoi le mot de passe en clair dans ce fichier pose-t-il un problème de sécurité ?
+  * Quelles sont les conséquences concrètes si un dépôt contenant ce fichier devient public, même brièvement ?
-  * Que se passe-t-il si ce fichier est commité dans Git ?
+  * Un attaquant qui récupère ce fichier a-t-il accès à la base de données directement ? Quels autres éléments lui manquent-il ?
-  * Quel service AWS permet de corriger cette situation ?
+  * Pourquoi externaliser ce secret dans Secrets Manager ne suffit pas si le code qui le récupère est lui-même mal sécurisé ?
 </WRAP>
 ===== 2. Build de l'application =====
-Le build se fait sur le poste de travail. L'EC2 ne reçoit que le jar final.
+Le fichier Maven minimal pour construire le projet :
 Fichier : ''app/pom.xml''
@@ Ligne 120: / Ligne 118: @@
 <WRAP round todo>
-Compiler l'application depuis le répertoire ''app/'' sur le poste de travail :
+Compiler l'application depuis le répertoire ''app/'' :
 <sxh bash>
@@ Ligne 127: / Ligne 125: @@
 </sxh>
-Vérifier que le fichier ''app/target/demo-1.0.jar'' est bien généré :
+Vérifier que le fichier ''app/target/demo-1.0.jar'' est bien généré.
-<sxh bash>
-ls -lh app/target/demo-1.0.jar
-</sxh>
 </WRAP>
-<WRAP round help>
+<WRAP round question>
-Questions de compréhension :
+Dans un pipeline CI/CD en production, ignorer les tests avec ''-DskipTests'' est une mauvaise pratique.
-  * Pourquoi utilise-t-on ''-DskipTests'' ici ?
+  * Dans quelle situation précise serait-il acceptable de l'utiliser malgré tout ?
-  * Dans quel cas ne faudrait-il pas ignorer les tests ?
+  * Quels types de tests seraient les plus critiques à conserver pour une application qui manipule une base de données ?
-  * Où se trouve le jar produit par Maven ? Pourquoi ce répertoire est-il généralement dans ''.gitignore'' ?
 </WRAP>
 ===== 3. Déploiement manuel =====
-Avant d'automatiser, on effectue un déploiement manuel pour valider que l'application fonctionne sur l'EC2.
+Avant d'automatiser, on effectue un déploiement manuel pour valider que l'application fonctionne.
-Cette section introduit volontairement un problème que vous devrez identifier.
-<WRAP round todo>
-Étape 1 : Vérifier que Java est disponible sur l'instance EC2.
-Se connecter à l'instance :
-<sxh bash>
-ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP
-</sxh>
-Depuis l'instance, vérifier Java :
-<sxh bash>
-java -version
-</sxh>
-Si Java n'est pas installé, l'installer manuellement :
-<sxh bash>
-sudo yum install -y java-17-amazon-corretto
-# Vérifier l'installation
-java -version
-</sxh>
-Quitter la session SSH :
-<sxh bash>
-exit
-</sxh>
-</WRAP>
 <WRAP round todo>
-Étape 2 : Copier le jar sur l'instance EC2 depuis le poste de travail :
+Copier le jar sur l'instance EC2 :
 <sxh bash>
@@ Ligne 188: / Ligne 148: @@
 </sxh>
-Étape 3 : Se connecter à l'instance et lancer l'application :
+Se connecter à l'instance et lancer l'application :
 <sxh bash>
@@ Ligne 201: / Ligne 161: @@
 </WRAP>
-<WRAP round help>
+<WRAP round question>
-Questions d'analyse :
+Sur un système Linux, les arguments passés à un processus sont visibles via ''ps aux''.
-  * Quels sont les problèmes concrets de cette méthode de déploiement ?
+  * Quelle est la conséquence concrète de passer le mot de passe en argument de ligne de commande sur un serveur multi-utilisateurs ?
-  * Que se passe-t-il si l'instance EC2 redémarre ?
+  * Cette méthode de déploiement crée une dépendance forte entre le déploiement et la présence d'un opérateur humain. Quels risques cela introduit-il à l'échelle ?
-  * Pourquoi passer le mot de passe en argument de ligne de commande est-il risqué ?
-  * Quelle commande Linux permet de voir les arguments passés à un processus en cours d'exécution ?
 </WRAP>
@@ Ligne 218: / Ligne 176: @@
 </sxh>
-<WRAP round help>
+<WRAP round question>
-Analysez l'erreur avant de passer à la suite :
+Avant de chercher la solution :
-  * Pourquoi l'application ne peut-elle pas se connecter à ''DB_HOST'' ?
+  * L'erreur indique ''refused'' et non ''timed out''. Quelle différence technique cela implique-t-il sur l'origine du problème ?
-  * Quelle valeur devrait remplacer ''DB_HOST'' ?
+  * Listez les couches réseau à vérifier dans l'ordre pour isoler la cause : application, Security Group, sous-réseau, routage.
-  * Comment vérifier que l'instance EC2 peut joindre le RDS ?
 Commande utile pour tester la connectivité réseau depuis l'instance EC2 :
@@ Ligne 230: / Ligne 187: @@
 nc -zv RDS_HOST 5432
 </sxh>
-  * Si cette commande échoue, quel composant AWS est probablement en cause ?
-  * Quel Security Group faut-il vérifier en priorité ?
 Ne cherchez pas la solution immédiatement. Identifiez d'abord l'origine exacte du problème.
@@ Ligne 240: / Ligne 194: @@
 On automatise maintenant le déploiement pour qu'il soit reproductible.
-Ansible se connecte à l'EC2 via SSH depuis le poste de travail. Il installe Java si nécessaire, dépose le jar, et configure le service.
 Fichier : ''ansible/inventory.ini''
-<sxh ini>
+<sxh ini;gutter:false>
 [web]
 EC2_IP ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/ma-cle.pem
@@ Ligne 250: / Ligne 202: @@
 Fichier : ''ansible/ansible.cfg''
-<sxh ini>
+<sxh ini;gutter:false>
 [defaults]
 host_key_checking = False
 stdout_callback = yaml
 </sxh>
-<WRAP round help>
-Pourquoi ''host_key_checking = False'' est-il utile ici ?
-Serait-ce acceptable dans un environnement de production ? Pourquoi ?
-</WRAP>
 Fichier : ''ansible/deploy.yml''
@@ Ligne 302: / Ligne 248: @@
 <WRAP round todo>
-Lancer le playbook depuis le poste de travail :
+Lancer le playbook :
-<sxh bash>
+<sxh bash;gutter:false>
 ansible-playbook -i ansible/inventory.ini ansible/deploy.yml
 </sxh>
@@ Ligne 310: / Ligne 256: @@
 Vérifier que le jar est bien présent sur l'instance :
-<sxh bash>
+<sxh bash;gutter:false>
 ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP ls -lh /opt/demo/
 </sxh>
-</WRAP>
-<WRAP round help>
-Questions de compréhension :
-  * Pourquoi crée-t-on un utilisateur dédié ''appuser'' plutôt que de lancer l'application en tant que ''root'' ou ''ec2-user'' ?
-  * Pourquoi Ansible installe-t-il Java sur l'EC2 alors qu'on l'a peut-être déjà installé manuellement à la section 3 ?
-  * Qu'est-ce que l'idempotence dans Ansible ? Pourquoi est-ce important ici ?
 </WRAP>
 ===== 6. Problème volontaire – L'application ne se connecte pas à la base =====
-Le jar est déployé et Java est installé, mais l'application ne peut pas démarrer correctement car les variables de connexion à la base de données ne sont pas fournies.
+Le jar est déployé mais l'application ne peut pas démarrer correctement car les variables de connexion à la base de données ne sont pas fournies.
-<WRAP round help>
+<WRAP round question>
 Avant de regarder la section suivante :
-  * Quel élément manque dans le playbook actuel ?
+  * Le playbook copie le jar mais ne fournit aucune configuration à l'application. Quels mécanismes Spring Boot permettent d'injecter cette configuration sans modifier le jar lui-même ?
-  * Comment Ansible peut-il récupérer un secret depuis AWS Secrets Manager ?
+  * Ansible peut exécuter des commandes AWS CLI sur la machine cible. Quelles permissions IAM l'instance EC2 doit-elle posséder pour que cette approche fonctionne sans clé d'accès statique ?
-  * Pourquoi ne doit-on pas mettre le mot de passe directement dans le playbook ?
+  * Quelle différence y a-t-il entre stocker le mot de passe dans un fichier de variables Ansible chiffré avec Ansible Vault et le stocker dans Secrets Manager ? Dans quel contexte chaque approche est-elle préférable ?
-  * Pourquoi ne pas le mettre non plus dans un fichier de variables Ansible commité dans Git ?
 </WRAP>
-===== 7. Correction – Récupération du secret et service systemd =====
+===== 7. Correction – Récupération du secret depuis Secrets Manager =====
-On complète le playbook avec la récupération du secret, la génération du fichier de configuration, et le démarrage via systemd.
+On ajoute la récupération du secret et le lancement de l'application via un service systemd.
 Fichier : ''ansible/deploy.yml'' (version complète)
@@ Ligne 433: / Ligne 370: @@
 </sxh>
-<WRAP round help>
+<WRAP round question>
-Questions de compréhension :
+  * ''no_log: true'' masque la valeur dans les logs Ansible, mais le secret est tout de même écrit sur le disque dans ''application.properties''. Quelles mesures complémentaires permettraient de réduire la durée d'exposition de ce secret sur le système de fichiers ?
+  * Le service systemd démarre l'application avec l'utilisateur ''appuser'' qui n'a pas de shell. Quel est l'intérêt de cette contrainte par rapport à un utilisateur standard ?
-  * Pourquoi utilise-t-on ''no_log: true'' sur la tâche de récupération du secret ?
+  * Si Secrets Manager retourne le secret sous forme de JSON ''{"password":"valeur"}'' plutôt qu'une chaîne brute, que faut-il modifier dans la tâche de récupération ?
-  * Pourquoi le fichier ''application.properties'' a-t-il les permissions ''0600'' ?
-  * Quel rôle IAM doit avoir l'instance EC2 pour que la commande ''aws secretsmanager'' fonctionne ?
-  * Pourquoi ne jamais stocker ce secret dans le dépôt Git, même dans un fichier de variables Ansible ?
 </WRAP>
 ===== 8. Pourquoi systemd plutôt que nohup =====
-<WRAP round help>
+<WRAP round question>
-Comparez les deux approches :
+Comparez les deux approches du point de vue opérationnel :
-<sxh bash>
+<sxh bash;gutter:false>
-# Approche nohup – ne pas utiliser en production
+# Approche nohup – à ne pas utiliser en production
 nohup java -jar demo.jar &
 </sxh>
-  * Que se passe-t-il avec ''nohup'' si l'instance EC2 redémarre ?
+  * Un processus lancé avec ''nohup'' plante silencieusement à 3h du matin. Décrivez la chaîne d'événements jusqu'à la détection du problème sans systemd, puis avec systemd.
-  * Que se passe-t-il avec ''nohup'' si l'application plante ?
+  * systemd expose des métriques sur les redémarrages successifs d'un service. En quoi cette information est-elle utile pour distinguer un bug applicatif d'un problème d'infrastructure ?
-  * Comment systemd rés
+</WRAP>
+===== 9. Mise en place du pipeline CI/CD =====
+On automatise maintenant le build et le déploiement via GitHub Actions.
+Fichier : ''.github/workflows/deploy.yml''
+<sxh yaml>
+name: Build and Deploy
+on:
+  push:
+    branches: [ "main" ]
+jobs:
+  build-and-deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Récupérer le code
+        uses: actions/checkout@v4
+      - name: Configurer Java 17
+        uses: actions/setup-java@v4
+        with:
+          distribution: temurin
+          java-version: 17
+      - name: Compiler l'application
+        run: |
+          cd app
+          mvn clean package -DskipTests
+      - name: Configurer les credentials AWS
+        uses: aws-actions/configure-aws-credentials@v4
+        with:
+          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
+          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+          aws-region: eu-west-1
+      - name: Préparer la clé SSH
+        run: |
+          mkdir -p ~/.ssh
+          echo "${{ secrets.EC2_SSH_KEY }}" > ~/.ssh/ma-cle.pem
+          chmod 600 ~/.ssh/ma-cle.pem
+      - name: Installer Ansible
+        run: |
+          sudo apt-get update -q
+          sudo apt-get install -y ansible
+      - name: Déployer avec Ansible
+        run: |
+          ansible-playbook \
+            -i ansible/inventory.ini \
+            ansible/deploy.yml \
+            -e "rds_host=${{ secrets.RDS_HOST }}"
+</sxh>
+===== 10. Problème volontaire – Le pipeline échoue =====
+En l'état, le pipeline GitHub Actions va échouer pour plusieurs raisons.
+<WRAP round question>
+Identifiez les problèmes avant de passer à la section suivante :
+  * Le runner GitHub Actions est une machine éphémère hébergée chez GitHub. Quelles contraintes réseau cela implique-t-il pour joindre une instance EC2 dans un sous-réseau public ?
+  * L'inventaire Ansible contient ''EC2_IP'' en dur. Quelles sont les deux situations concrètes dans lesquelles cette valeur devient invalide sans que personne ne s'en aperçoive immédiatement ?
+  * Si la vérification de la clé SSH hôte est active, le pipeline se bloque en attente d'une confirmation interactive. Pourquoi ce comportement est-il particulièrement problématique dans un contexte CI/CD ?
+</WRAP>
+===== 11. Correction – Configuration des secrets GitHub =====
+<WRAP round todo>
+Dans le dépôt GitHub, aller dans Settings > Secrets and variables > Actions.
+Créer les secrets suivants :
+  * ''AWS_ACCESS_KEY_ID'' : clé d'accès du compte AWS
+  * ''AWS_SECRET_ACCESS_KEY'' : clé secrète correspondante
+  * ''EC2_SSH_KEY'' : contenu complet du fichier ''.pem'' de la clé SSH
+  * ''RDS_HOST'' : endpoint du RDS récupéré depuis la console AWS
+Mettre à jour l'inventaire Ansible avec l'IP réelle de l'instance :
+</WRAP>
+Fichier : ''ansible/inventory.ini''
+<sxh ini>
+[web]
+EC2_IP_REELLE ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/ma-cle.pem
+</sxh>
+Fichier : ''ansible/ansible.cfg''
+<sxh ini>
+[defaults]
+host_key_checking = False
+stdout_callback = yaml
+remote_user = ec2-user
+</sxh>
+<WRAP round question>
+  * Les secrets GitHub sont chiffrés au repos et masqués dans les logs. Malgré cela, un secret GitHub n'offre pas les mêmes garanties que Secrets Manager. Identifiez au moins deux différences en termes de contrôle d'accès et d'auditabilité.
+  * Ce pipeline utilise une clé d'accès AWS statique. Quelle alternative AWS permettrait d'authentifier GitHub Actions sans clé longue durée, et sur quel mécanisme repose-t-elle ?
+</WRAP>
+===== 12. Vérification du déploiement =====
+<WRAP round todo>
+Vérifier que l'application est bien démarrée sur l'instance EC2 :
+<sxh bash>
+ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP
+# Vérifier le statut du service
+sudo systemctl status demo
+# Consulter les logs de l'application
+sudo journalctl -u demo -n 50 --no-pager
+</sxh>
+Vérifier que l'application répond via l'ALB :
+<sxh bash>
+curl http://ALB_DNS/actuator/health
+</sxh>
+</WRAP>
+<WRAP round question>
+  * L'accès direct à l'IP de l'instance EC2 fonctionne, mais l'accès via l'ALB retourne une erreur 502. Sans regarder les logs, listez les causes possibles dans l'ordre le plus probable.
+  * Dans une architecture avec plusieurs instances EC2 derrière l'ALB, pourquoi le fait de vérifier uniquement une instance ne suffit-il pas à valider le déploiement ?
+</WRAP>
+===== 13. Amélioration sécurité – Remplacer SSH par Session Manager =====
+Objectif de cette section :
+  * supprimer le port 22 du Security Group
+  * éviter la gestion des clés SSH
+  * améliorer la traçabilité des connexions
+===== 13.1 Configuration IAM pour Session Manager =====
+Fichier : ''terraform/ec2_ssm.tf''
+<sxh js>
+resource "aws_iam_role" "ec2_ssm_role" {
+  name = "ec2-ssm-role"
+  assume_role_policy = jsonencode({
+    Version = "2012-10-17"
+    Statement = [{
+      Effect = "Allow"
+      Principal = {
+        Service = "ec2.amazonaws.com"
+      }
+      Action = "sts:AssumeRole"
+    }]
+  })
+}
+resource "aws_iam_role_policy_attachment" "ssm_core" {
+  role       = aws_iam_role.ec2_ssm_role.name
+  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
+}
+resource "aws_iam_instance_profile" "ec2_ssm_profile" {
+  name = "ec2-ssm-profile"
+  role = aws_iam_role.ec2_ssm_role.name
+}
+</sxh>
+<WRAP round todo>
+Appliquer la configuration Terraform :
+<sxh bash>
+terraform apply
+</sxh>
+Associer le profil IAM à l'instance EC2 existante depuis la console AWS :
+EC2 > Instance > Actions > Security > Modify IAM role
+</WRAP>
+===== 13.2 Test de connexion via Session Manager =====
+<WRAP round todo>
+Tester la connexion sans clé SSH :
+<sxh bash;gutter:false>
+aws ssm start-session --target INSTANCE_ID
+</sxh>
+Vérifier que la session s'ouvre correctement, puis taper ''exit''.
+</WRAP>
+<WRAP round question>
+  * SSH ouvre un port entrant sur l'instance. SSM n'en ouvre aucun. Expliquez le mécanisme qui permet à SSM de fonctionner malgré l'absence de port entrant ouvert.
+  * Un administrateur se connecte via SSM et exécute des commandes sensibles. Où ces actions sont-elles enregistrées, et quel service AWS permet de les consulter a posteriori ?
+  * SSM améliore la traçabilité, mais introduit une nouvelle dépendance. Laquelle, et quel impact cela a-t-il en cas de panne de connectivité vers les endpoints AWS ?
+</WRAP>
+===== 13.3 Suppression du port SSH =====
+<WRAP round todo>
+Modifier le Security Group de l'instance EC2 pour supprimer la règle entrante sur le port 22.
+Depuis la console AWS :
+EC2 > Security Groups > Sélectionner le SG de l'instance > Inbound rules > Supprimer la règle port 22
+Vérifier qu'une connexion SSH directe est bien refusée :
+<sxh bash;gutter:false>
+ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP
+# Attendu : Connection refused ou timeout
+</sxh>
+Vérifier que Session Manager fonctionne toujours :
+<sxh bash;gutter:false>
+aws ssm start-session --target INSTANCE_ID
+</sxh>
+</WRAP>
+===== 13.4 Limite actuelle – Ansible et SSM =====
+<WRAP round question>
+  * Le playbook Ansible utilise encore SSH pour se connecter à l'instance alors que le port 22 vient d'être fermé. Quelle est la conséquence immédiate sur le pipeline CI/CD ?
+  * Dans une architecture sans SSH, deux alternatives à Ansible sont envisageables : le plugin de connexion SSM d'Ansible, ou le remplacement d'Ansible par AWS Systems Manager Run Command. Comparez ces deux approches sur les critères suivants : complexité de mise en oeuvre, dépendances, traçabilité.
+  * Plus largement, le modèle push d'Ansible et le modèle pull de certains outils (AWS CodeDeploy, Chef) répondent différemment à ce problème. Quelle architecture serait la plus adaptée si les instances EC2 sont dans un sous-réseau strictement privé sans accès entrant ?
+</WRAP>
+===== Challenge final =====
+<WRAP round todo>
+L'objectif est d'améliorer l'architecture sur les points suivants.
+Point 1 : Rotation automatique du secret
+Configurer Secrets Manager pour effectuer une rotation automatique du mot de passe RDS tous les 30 jours.
+Point 2 : Inventaire Ansible dynamique
+Remplacer le fichier ''inventory.ini'' statique par un inventaire dynamique qui récupère automatiquement l'IP de l'instance EC2 via les tags AWS.
+Point 3 : Notifications de déploiement
+Ajouter une étape dans le pipeline GitHub Actions pour envoyer une notification (Slack ou email) en cas de succès ou d'échec du déploiement.
+</WRAP>
+<WRAP round question>
+Questions de synthèse :
+  * La rotation automatique du secret en point 1 résout un problème de sécurité, mais crée un risque opérationnel. Lequel, et comment le playbook Ansible doit-il être adapté pour y faire face ?
+  * Si l'instance EC2 est remplacée par un conteneur ECS Fargate, identifiez les éléments du pipeline qui deviennent obsolètes et ceux qui restent pertinents.
+  * Ce pipeline déploie en continu sur la branche ''main''. Un déploiement raté laisse l'application dans un état inconnu. Quelle stratégie de déploiement permet de garantir qu'une version précédente reste disponible pendant la mise à jour ?
+</WRAP>
+===== Bonus – Déploiement Blue/Green simplifié =====
+<WRAP round todo>
+Mettre en place un déploiement sans interruption de service.
+Modifier le playbook Ansible pour :
+  * déployer le nouveau jar dans un répertoire horodaté
+  * basculer un lien symbolique vers la nouvelle version
+  * redémarrer le service uniquement si le jar a changé
+Fichier : ''ansible/deploy_bluegreen.yml''
+</WRAP>
+<sxh yaml>
+---
+- hosts: web
+  become: true
+  vars:
+    app_dir: /opt/demo
+    releases_dir: /opt/demo/releases
+    app_jar: demo.jar
+    app_user: appuser
+    timestamp: "{{ ansible_date_time.epoch }}"
+  tasks:
+    - name: Créer le répertoire de la release
+      file:
+        path: "{{ releases_dir }}/{{ timestamp }}"
+        state: directory
+        owner: "{{ app_user }}"
+        mode: '0755'
+    - name: Copier le jar dans le répertoire de la release
+      copy:
+        src: ../app/target/demo-1.0.jar
+        dest: "{{ releases_dir }}/{{ timestamp }}/{{ app_jar }}"
+        owner: "{{ app_user }}"
+        mode: '0644'
+    - name: Basculer le lien symbolique vers la nouvelle release
+      file:
+        src: "{{ releases_dir }}/{{ timestamp }}/{{ app_jar }}"
+        dest: "{{ app_dir }}/current.jar"
+        state: link
+        owner: "{{ app_user }}"
+    - name: Redémarrer le service
+      systemd:
+        name: demo
+        state: restarted
+</sxh>
+<WRAP round question>
+  * Ce déploiement réduit l'interruption de service à la durée du redémarrage JVM. Pourquoi un vrai Blue/Green sur AWS avec deux groupes cibles ALB va plus loin, et quel est le coût de cette approche ?
+  * Le lien symbolique est basculé avant le redémarrage du service. Si le redémarrage échoue, dans quel état se trouve l'application ? Comment modifier le playbook pour détecter cet échec et revenir automatiquement à la release précédente ?
+  * Sans politique de nettoyage, les répertoires de releases s'accumulent sur le disque. Rédigez la tâche Ansible qui conserve uniquement les 3 releases les plus récentes.
+</WRAP>