EXERCISE_3_IDEMPOTENCE_ANALYSIS

Exercice 3 : Analyse détaillée de l’idempotence

Résultats observés

Lorsque le playbook configure_sample_app_playbook.yml est relancé une deuxième fois, exactement les mêmes résultats sont obtenus :

PLAY RECAP
localhost : ok=6 changed=1 unreachable=0 failed=0 skipped=1

Comparaison : 1ère vs 2ème exécution

Tâche	1ère exécution	2ème exécution	Idempotent ?
Gathering Facts	ok	ok	✅ OUI
Install Node.js setup repository	ok	ok	✅ OUI
Install Node.js	ok	ok	✅ OUI
Copy sample app	ok	ok	✅ OUI
Check if app is already running	ignored (failed)	ignored (failed)	✅ OUI
Stop any existing app	skipped	skipped	✅ OUI
Start sample app	changed	changed	❌ NON

Pourquoi “Start sample app” n’est PAS idempotent ?

- name: Start sample app
  shell: nohup node /home/ec2-user/app.js > /tmp/app.log 2>&1 &
  args:
    chdir: /home/ec2-user/
  become_user: ec2-user

Problèmes :

1. Pas de condition (when:) — s’exécute TOUJOURS
2. Pas de changed_when: false — marque toujours comme “changed”
3. Pas de détection d’état — ne vérifie pas si l’app tourne déjà
4. Résultat : À chaque exécution, un nouveau processus Node est créé → 2, 3, 4+ instances en écoute sur le port 8080 → problème grave

---

Solutions pour rendre le rôle idempotent

Solution 1 : Ajouter une condition + changed_when: false (MINIMAL)

- name: Start sample app (IDEMPOTENT - version minimale)
  shell: nohup node /home/ec2-user/app.js > /tmp/app.log 2>&1 &
  args:
    chdir: /home/ec2-user/
  become_user: ec2-user
  when: app_running.rc != 0         # Ne s'exécute que si app NOT running
  changed_when: false               # Ne marque jamais comme "changed"

Avantages :

• Minimal, facile à comprendre
• La tâche s’exécute seulement si l’app n’est pas en cours

Inconvénients :

• Toujours un shell non-structuré
• Pas de gestion des redémarrages ou crashes
• Logs dans /tmp/app.log (non managé)

Résultat idempotent : 2ème exécution → skipped (condition fausse, app déjà en cours)

Solution 2 : Service systemd (MEILLEUR)

Créer /etc/systemd/system/sample-app.service :

- name: Create systemd service file for sample app
  copy:
    dest: /etc/systemd/system/sample-app.service
    mode: '0644'
    content: |
      [Unit]
      Description=Sample Node.js Application
      After=network.target
      
      [Service]
      Type=simple
      User=ec2-user
      WorkingDirectory=/home/ec2-user
      ExecStart=/usr/bin/node /home/ec2-user/app.js
      Restart=on-failure
      RestartSec=10
      StandardOutput=journal
      StandardError=journal
      
      [Install]
      WantedBy=multi-user.target
 
- name: Enable and start sample app service
  systemd:
    name: sample-app
    state: started
    enabled: yes
    daemon_reload: yes

Avantages :

• ✅ PLEINEMENT IDEMPOTENT — systemd gère l’idempotence
• ✅ Redémarrage automatique en cas de crash (Restart=on-failure)
• ✅ Logs centralisés dans journalctl
• ✅ Contrôle facile : systemctl start/stop/restart sample-app
• ✅ Démarrage automatique après reboot (enabled: yes)

Inconvénients :

• Nécessite become: yes ou exécution en root

Résultat idempotent :

• 1ère exécution : changed (service créé et démarré)
• 2ème exécution : ok (service existe et tourne déjà)

---

Fichiers fournis

Variante 1 : Idempotence minimale

Fichier : roles/sample-app/tasks/main_idempotent.yml

• Ajoute la condition when: app_running.rc != 0
• Ajoute changed_when: false
• Minimal mais fonctionnel

Variante 2 : Meilleure pratique (systemd)

Fichier : roles/sample-app/tasks/main_systemd.yml

• Crée un service systemd complet
• Gestion professionnelle de l’app
• Idempotence garantie

Variante 3 : Originale (non-idempotente)

Fichier : roles/sample-app/tasks/main.yml (actuellement utilisée)

• Montre le problème de non-idempotence
• À titre pédagogique uniquement

---

Comment utiliser les variantes

Pour utiliser la version idempotente minimale :

cp roles/sample-app/tasks/main_idempotent.yml roles/sample-app/tasks/main.yml
ansible-playbook -i inventory.aws_ec2.yml configure_sample_app_playbook.yml

Pour utiliser la meilleure pratique (systemd) :

cp roles/sample-app/tasks/main_systemd.yml roles/sample-app/tasks/main.yml
ansible-playbook -i inventory.aws_ec2.yml configure_sample_app_playbook.yml

Puis relancer le playbook — la 2ème exécution doit montrer ok (aucun changement).

---

Leçons apprises

1. Idempotence = Talon d’Achille : Beaucoup de playbooks Ansible naïfs ne sont PAS idempotents.
2. Signes de non-idempotence :
   • shell: ou command: sans changed_when: ou when:
   • Tâches qui modifient l’état sans vérifier l’état existant
   • Redémarrage/relancement d’apps en boucle
3. Bonnes pratiques :
   • Utiliser des modules de haut niveau (yum:, copy:, systemd:, etc.) — ils sont idempotents par défaut
   • Pour les scripts personnalisés (shell:), ajouter when: ou changed_when:
   • Préférer les services systemd ou supervisors pour la gestion d’applications
4. Vérification : Relancer le playbook deux fois de suite — la 2ème exécution doit produire 0 changement (ou très peu).