eadl:bloc4:fm4:td4

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
eadl:bloc4:fm4:td4 [2026/06/25 02:21] – jcheroneadl:bloc4:fm4:td4 [2026/06/25 13:14] (Version actuelle) – [8. Pourquoi systemd plutôt que nohup] jcheron
Ligne 37: Ligne 37:
   * Java 17 et Maven installés sur le poste de travail   * Java 17 et Maven installés sur le poste de travail
  
-<WRAP round help> 
 Rappel sur les environnements d'exécution : 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é   * 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 ===== ===== 1. Compréhension de l'application =====
Ligne 61: Ligne 59:
 </sxh> </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> </WRAP>
  
Ligne 120: Ligne 118:
  
 <WRAP round todo> <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> <sxh bash>
Ligne 130: Ligne 128:
 </WRAP> </WRAP>
  
-<WRAP round help> +<WRAP round question> 
-Pourquoi utilise-t-on ''-DskipTests'' ici ?+Dans un pipeline CI/CD en production, ignorer les tests avec ''-DskipTests'' est une mauvaise pratique.
  
-Dans quel cas ne faudrait-il pas ignorer les tests ?+  * Dans quelle situation précise serait-il acceptable de l'utiliser malgré tout ? 
 +  * Quels types de tests seraient les plus critiques à conserver pour une application qui manipule une base de données ?
 </WRAP> </WRAP>
  
Ligne 139: Ligne 138:
  
 Avant d'automatiser, on effectue un déploiement manuel pour valider que l'application fonctionne. Avant d'automatiser, on effectue un déploiement manuel pour valider que l'application fonctionne.
- 
-<WRAP round help> 
-Rappel : le jar est compilé sur le poste de travail. L'EC2 n'a besoin que de Java pour l'exécuter. Maven n'est pas nécessaire sur l'instance. 
-</WRAP> 
  
 <WRAP round todo> <WRAP round todo>
-Étape 1 : Vérifier que Java est disponible sur l'instance EC2. +Copier le jar sur l'instance EC2 :
- +
-Se connecter à l'instance : +
- +
-<sxh bash> +
-ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP +
-</sxh> +
- +
-Vérifier Java depuis l'instance : +
- +
-<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> +
- +
-Étape 2 : Copier le jar sur l'instance EC2 depuis le poste de travail :+
  
 <sxh bash> <sxh bash>
Ligne 182: Ligne 148:
 </sxh> </sxh>
  
-Étape 3 : Se connecter à l'instance et lancer l'application :+Se connecter à l'instance et lancer l'application :
  
 <sxh bash> <sxh bash>
Ligne 195: Ligne 161:
 </WRAP> </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é ?+
 </WRAP> </WRAP>
  
Ligne 211: Ligne 176:
 </sxh> </sxh>
  
-<WRAP round help> +<WRAP round question> 
-Analysez l'erreur :+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 :+Commande utile pour tester la connectivité réseau depuis l'instance EC2 :
  
 <sxh bash> <sxh bash>
-# Depuis l'instance EC2 
 nc -zv RDS_HOST 5432 nc -zv RDS_HOST 5432
 </sxh> </sxh>
Ligne 231: Ligne 194:
  
 On automatise maintenant le déploiement pour qu'il soit reproductible. 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'' Fichier : ''ansible/inventory.ini''
-<sxh bash>+<sxh ini;gutter:false>
 [web] [web]
 EC2_IP ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/ma-cle.pem EC2_IP ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/ma-cle.pem
Ligne 241: Ligne 202:
  
 Fichier : ''ansible/ansible.cfg'' Fichier : ''ansible/ansible.cfg''
-<sxh bash>+<sxh ini;gutter:false>
 [defaults] [defaults]
 host_key_checking = False host_key_checking = False
Ligne 289: Ligne 250:
 Lancer le playbook : Lancer le playbook :
  
-<sxh bash>+<sxh bash;gutter:false>
 ansible-playbook -i ansible/inventory.ini ansible/deploy.yml ansible-playbook -i ansible/inventory.ini ansible/deploy.yml
 </sxh> </sxh>
Ligne 295: Ligne 256:
 Vérifier que le jar est bien présent sur l'instance : 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/ ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP ls -lh /opt/demo/
 </sxh> </sxh>
-</WRAP> 
- 
-<WRAP round help> 
-Ansible installe Java automatiquement si nécessaire. C'est l'un des avantages de l'automatisation : l'état cible est garanti, quelle que soit la situation initiale de l'instance. 
- 
-  * Qu'est-ce que l'idempotence dans Ansible ? Pourquoi est-ce important ici ? 
-  * Que se passe-t-il si on rejoue le playbook alors que Java est déjà installé ? 
 </WRAP> </WRAP>
  
Ligne 311: Ligne 265:
 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. 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 : 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 ?
 </WRAP> </WRAP>
  
Ligne 416: Ligne 370:
 </sxh> </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 ? 
 +  * 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 ? 
 +</WRAP> 
 + 
 +===== 8. Pourquoi systemd plutôt que nohup ===== 
 + 
 +<WRAP round question> 
 +Comparez les deux approches du point de vue opérationnel : 
 + 
 +<sxh bash;gutter:false> 
 +# Approche nohup – à ne pas utiliser en production 
 +nohup java -jar demo.jar & 
 +</sxh>
  
-  * Pourquoi utilise-t-on ''no_log: true'' sur la tâche de récupération du secret ? +  * 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. 
-  * Pourquoi le fichier ''application.properties'' a-t-il les permissions ''0600'' ? +  * 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 ?
-  * Pourquoi ne jamais stocker ce secret dans le dépôt Git, même dans un fichier de variables Ansible ?+
 </WRAP> </WRAP>
  
-===== 8. Mise en place CI/CD =====+===== 9. Mise en place du pipeline CI/CD =====
  
-<WRAP round help> +On automatise maintenant le build et le déploiement via GitHub Actions.
-Pourquoi le pipeline échoue ?+
  
-Pistes :+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 :
  
-  * accès SSH +  * 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 ? 
-  * credentials AWS+  * 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> </WRAP>
  
-===== 10. Correction CI/CD =====+===== 11. Correction – Configuration des secrets GitHub =====
  
 <WRAP round todo> <WRAP round todo>
-Configurer dans GitHub :+Dans le dépôt GitHub, aller dans Settings > Secrets and variables > Actions.
  
-  * clé SSH privée +Créer les secrets suivants :
-  * credentials AWS+
  
-Modifier le workflow pour les utiliser.+  * ''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> </WRAP>
  
-===== 11. Vérification =====+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> <WRAP round todo>
-Valider :+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>
  
-  * application accessible via ALB +<WRAP round question> 
-  * connexion RDS OK +  * 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. 
-  * déploiement automatique fonctionnel+  * 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> </WRAP>
  
-===== 12. Amélioration sécurité – Remplacer SSH par Session Manager =====+===== 13. Amélioration sécurité – Remplacer SSH par Session Manager =====
  
-Objectif :+Objectif de cette section :
  
   * supprimer le port 22 du Security Group   * supprimer le port 22 du Security Group
Ligne 464: Ligne 528:
   * améliorer la traçabilité des connexions   * améliorer la traçabilité des connexions
  
-===== 12.1 Configuration IAM pour Session Manager =====+===== 13.1 Configuration IAM pour Session Manager =====
  
 Fichier : ''terraform/ec2_ssm.tf'' Fichier : ''terraform/ec2_ssm.tf''
Ligne 505: Ligne 569:
 </WRAP> </WRAP>
  
-===== 12.2 Test de connexion via Session Manager =====+===== 13.2 Test de connexion via Session Manager =====
  
 <WRAP round todo> <WRAP round todo>
 Tester la connexion sans clé SSH : Tester la connexion sans clé SSH :
  
-<sxh bash>+<sxh bash;gutter:false>
 aws ssm start-session --target INSTANCE_ID aws ssm start-session --target INSTANCE_ID
 </sxh> </sxh>
Ligne 517: Ligne 581:
 </WRAP> </WRAP>
  
-<WRAP round help> +<WRAP round question> 
-Comparez les deux méthodes de connexion : +  * 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 ? 
-  * Quelle différence y a-t-il entre une session SSH et une session SSM du point de vue réseau ? +  * 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 ?
-  * Où sont enregistrées les sessions SSM ? Comment cela améliore-t-il la traçabilité ? +
-  * Quel service AWS peut être utilisé pour stocker les logs de sessions SSM ?+
 </WRAP> </WRAP>
  
-===== 12.3 Suppression du port SSH =====+===== 13.3 Suppression du port SSH =====
  
 <WRAP round todo> <WRAP round todo>
Ligne 535: Ligne 597:
 Vérifier qu'une connexion SSH directe est bien refusée : Vérifier qu'une connexion SSH directe est bien refusée :
  
-<sxh bash>+<sxh bash;gutter:false>
 ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP
 # Attendu : Connection refused ou timeout # Attendu : Connection refused ou timeout
Ligne 542: Ligne 604:
 Vérifier que Session Manager fonctionne toujours : Vérifier que Session Manager fonctionne toujours :
  
-<sxh bash>+<sxh bash;gutter:false>
 aws ssm start-session --target INSTANCE_ID aws ssm start-session --target INSTANCE_ID
 </sxh> </sxh>
 </WRAP> </WRAP>
  
-===== 12.4 Limite actuelle =====+===== 13.4 Limite actuelle – Ansible et SSM =====
  
-<WRAP round help> +<WRAP round question> 
-Pourquoi Ansible fonctionne-t-il encore en SSH ici ? +  * 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é. 
-Pourquoi le passage complet à SSM est plus complexe ?+  * 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> </WRAP>
  
Ligne 558: Ligne 620:
  
 <WRAP round todo> <WRAP round todo>
-Améliorer :+L'objectif est d'améliorer l'architecture sur les points suivants.
  
-  * redémarrage propre de l'application +Point 1 : Rotation automatique du secret
-  * logs +
-  * sécurisation globale +
-</WRAP>+
  
-<WRAP round help> +Configurer Secrets Manager pour effectuer une rotation automatique du mot de passe RDS tous les 30 jours.
-Quels sont les derniers points faibles de cette architecture ? +
-</WRAP>+
  
-===== Bonus =====+Point 2 : Inventaire Ansible dynamique
  
-<WRAP round todo> +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.
-Mettre en place :+
  
-  * systemd pour gérer l'application+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>
  
-<WRAP round help> +<WRAP round question> 
-Pourquoi systemd est préférable à nohup ?+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> </WRAP>
  
Ligne 584: Ligne 646:
  
 <WRAP round todo> <WRAP round todo>
-Mettre en place un déploiement sans interruption de service :+Mettre en place un déploiement sans interruption de service.
  
 Modifier le playbook Ansible pour : Modifier le playbook Ansible pour :
Ligne 635: Ligne 697:
 </sxh> </sxh>
  
-<WRAP round help> +<WRAP round question> 
-  * Pourquoi utiliser un lien symbolique facilite-t-il un retour arrière (rollback) ? +  * 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 ? 
-  * Comment modifier ce playbook pour conserver uniquement les 3 dernières releases ? +  * 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 ? 
-  * Quelle est la différence entre ce déploiement et un vrai Blue/Green sur AWS ?+  * 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> </WRAP>
  
  • eadl/bloc4/fm4/td4.1782346884.txt.gz
  • Dernière modification : il y a 5 semaines
  • de jcheron