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:36] – jcheroneadl:bloc4:fm4:td4 [2026/06/25 13:14] (Version actuelle) – [8. Pourquoi systemd plutôt que nohup] jcheron
Ligne 60: Ligne 60:
  
 <WRAP round question> <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>
  
 ===== 2. Build de l'application ===== ===== 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'' Fichier : ''app/pom.xml''
Ligne 118: 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 129: Ligne 129:
  
 <WRAP round question> <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 137: 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.
- 
-Le jar est compilé sur le poste de travail. Avant de le copier sur l'EC2, il faut s'assurer que Java est disponible sur l'instance. 
  
 <WRAP round todo> <WRAP round todo>
-Étape 1 : Vérifier que Java est installé sur l'instance EC2. +Copier le jar sur l'instance EC2 :
- +
-<sxh bash> +
-ssh -i ~/.ssh/ma-cle.pem ec2-user@EC2_IP +
- +
-# Sur l'instance EC2 – vérifier Java +
-java -version +
-</sxh> +
- +
-Si Java n'est pas installé : +
- +
-<sxh bash> +
-# Sur l'instance EC2 +
-sudo yum install -y java-17-amazon-corretto +
- +
-# Vérifier l'installation +
-java -version +
- +
-# Quitter la session +
-exit +
-</sxh> +
- +
-Étape 2 : Copier le jar sur l'instance EC2 depuis le poste de travail :+
  
 <sxh bash> <sxh bash>
Ligne 171: 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 185: Ligne 162:
  
 <WRAP round question> <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 201: Ligne 177:
  
 <WRAP round question> <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 220: 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 prépare 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 230: 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 278: 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 284: 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 question> 
-Ansible installe Java automatiquement via la tâche dédiée. Ce comportement est idempotent. 
- 
-  * Que se passe-t-il si on rejoue le playbook alors que Java est déjà installé ? 
-  * Pourquoi l'idempotence est-elle importante dans un contexte d'automatisation ? 
 </WRAP> </WRAP>
  
Ligne 303: Ligne 268:
 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 406: Ligne 371:
  
 <WRAP round question> <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'' ? +
-  * Pourquoi ne jamais stocker ce secret dans le dépôt Git, même dans un fichier de variables Ansible ?+
 </WRAP> </WRAP>
  
Ligne 416: Ligne 379:
  
 <WRAP round question> <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 & nohup java -jar demo.jar &
 </sxh> </sxh>
  
-  * Que se passe-t-il avec ''nohup'' si l'instance 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ésout-il ces deux problèmes ? +
-  * Quelle option du service systemd gère le redémarrage automatique ?+
 </WRAP> </WRAP>
  
Ligne 432: Ligne 393:
  
 On automatise maintenant le build et le déploiement via GitHub Actions. On automatise maintenant le build et le déploiement via GitHub Actions.
- 
-Le runner GitHub Actions joue le même rôle que le poste de travail : il compile le jar avec Maven et Java, puis lance Ansible pour déployer sur l'EC2. 
  
 Fichier : ''.github/workflows/deploy.yml'' Fichier : ''.github/workflows/deploy.yml''
Ligne 495: Ligne 454:
 Identifiez les problèmes avant de passer à la section suivante : Identifiez les problèmes avant de passer à la section suivante :
  
-  * Quels secrets GitHub doivent être configurés pour que le pipeline fonctionne ? +  * 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 ? 
-  * Pourquoi le runner GitHub Actions ne peut-il pas se connecter à EC2 par défaut ? +  * 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 ? 
-  * Quel fichier Ansible permet d'éviter l'erreur de vérification de la clé SSH hôte en CI ? +  * 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 ?
-  * Pourquoi la valeur ''EC2_IP'' dans ''inventory.ini'' doit-elle être remplacée par une vraie adresse ?+
 </WRAP> </WRAP>
  
Ligne 531: Ligne 489:
  
 <WRAP round question> <WRAP round question>
-Questions sur la sécurité des secrets CI/CD : +  * 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 ?
-  * Pourquoi ne faut-il jamais mettre une clé AWS dans un fichier commité dans Git ? +
-  * Quelle est la différence entre un secret GitHub et une variable GitHub Actions ? +
-  * Comment s'assurer que les logs du pipeline n'affichent pas les valeurs des secrets ?+
 </WRAP> </WRAP>
  
Ligne 561: Ligne 516:
  
 <WRAP round question> <WRAP round question>
-  * Que doit retourner la commande ''systemctl status demo'' si le déploiement est réussi ? +  * 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. 
-  * Quelle différence y a-t-il entre accéder à l'application via l'IP EC2 et via l'ALB ? +  * 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 ?
-  * Pourquoi vaut-il mieux exposer uniquement l'ALB et non l'IP de l'instance ?+
 </WRAP> </WRAP>
  
Ligne 620: Ligne 574:
 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 628: Ligne 582:
  
 <WRAP round question> <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>
  
Ligne 645: 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 652: 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>
Ligne 660: Ligne 612:
  
 <WRAP round question> <WRAP round question>
-Réflexion sur la limite de l'architecture actuelle : +  * 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é. 
-  * Le playbook Ansible utilise encore SSH pour se connecter à l'instance. Pourquoi ? +  * 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 ?
-  * Ansible dispose d'un plugin de connexion SSM. Quels seraient les avantages de l'utiliser ? +
-  * Pourquoi le passage complet à SSM pour Ansible est-il plus complexe qu'un simple changement de configuration ? +
-  * Dans une architecture sans SSH, quelle alternative à Ansible pourrait être envisagée pour la configuration des instances ?+
 </WRAP> </WRAP>
  
Ligne 689: Ligne 638:
 Questions de synthèse : Questions de synthèse :
  
-  * Quels sont les points faibles restants dans cette architecture ? +  * 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, quels éléments du pipeline doivent changer ? +  * 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. 
-  * Comment garantir qu'un déploiement raté ne met pas l'application hors service ?+  * 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 697: 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 749: Ligne 698:
  
 <WRAP round question> <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.1782347781.txt.gz
  • Dernière modification : il y a 5 semaines
  • de jcheron