De l'importance de l'idempotence dans l'automatisation DevOps

Parmi les principes DevOps, la recherche de l'idempotence, qui consiste à s'assurer que les traitements automatisés n'ont pas d'effets secondaires indésirables et peuvent être répétés sans altérer le résultat final est un objectif vraiment très intéressant.

Après plusieurs sessions de formation, il apparaît toutefois que cet objectif a un coût en termes de développement. En effet, créer un Playbook Ansible aux traitements idempotents nécessite souvent d'augmenter significativement la quantité de code afin de garantir que chaque étape du processus soit exécutée de manière prévisible et reproductible. Pour les étudiants qui débutent dans l'automatisation, cela ne facilite pas l'apprentissage.

Voici les liens vers deux supports de travaux pratiques qui illustrent la hauteur de la marche à franchir entre placer une ou deux tâches dans un Playbook Ansible et garantir un traitement reproductible conforme avec l'état attendu de l'infrastructure cible.

Le lab « Use Ansible to Back Up and Configure a c8000v Router » propose une introduction à la création de Playbooks Ansible.

Le lab « Using Ansible to automate the installation of web services on Incus containers » utilise à nouveau Ansible pour automatiser la gestion de conteneurs à partir d'un inventaire dynamique. L'installation et la configuration de services web servent ensuite de prétexte pour manipuler les fichiers de configuration et valider le fonctionnement de ces services.

Les points clés sont :

1. L'idempotence et le développement
   Les traitements montrent l'importance de l'idempotence dans l'automatisation, tout en illustrant les conséquences sur la complexité du code.
2. Ansible et l'automatisation
   Ansible s'est imposé comme un outil de référence en matière d'automatisation et ses modules occupent une place essentielle.
3. Sensibilisation aux concepts DevOps
   L'objectif principal est de sensibiliser les étudiants aux concepts clés de l'automatisation DevOps, notamment la déclaration précise de l'état attendu d'une infrastructure IaaS.

Prenons l'exemple du lancement de conteneurs. Dans un contexte procédural, on écrirait le code de la commande de lancement dans un script Bash exécuté via SSH. Dans la liste des tâches Ansible ci-dessous, on commence par obtenir la liste des conteneurs attendus, puis on ne crée que ceux qui n'existent pas (when item.rc !=0) et on lance ceux qui ont l'état 'STOPPED'. Le code idempotent contient 3 tâches.

  tasks:
    - name: CHECK CONTAINERS STATE
      ansible.builtin.shell:
        cmd: set -o pipefail && incus ls --format csv -c n,s | grep {{ item }}
        executable: /bin/bash
      register: container_states
      with_inventory_hostnames:
        - containers
      changed_when: false
      failed_when: false
      check_mode: false

    - name: LAUNCH INCUS CONTAINERS
      ansible.builtin.command:
        cmd: incus launch {{ container_image }} "{{ item.item }}"
      loop: "{{ container_states.results }}"
      when: item.rc != 0 # Container not found
      register: containers_created
      changed_when: containers_created is changed

    - name: START STOPPED CONTAINERS
      ansible.builtin.command:
        cmd: incus start "{{ item.item }}"
      loop: "{{ container_states.results }}"
      when: item.rc == 0 and 'STOPPED' in item.stdout
      register: containers_started
      changed_when: containers_started is changed

À travers cet exemple, on voit que l'idempotence constitue le fil conducteur pédagogique qui unifie les deux supports de travaux pratiques tout en servant de critère d'évaluation de la qualité des automatisations développées.

Dans le Lab 15 sur la configuration des routeurs, les étudiants découvrent progressivement que l'idempotence ne peut être atteinte qu'en reprenant l'édition du code des playbooks vers une approche plus modulaire et spécialisée - passant d'une simple tâche ios_config à une structure plus sophistiquée utilisant des modules dédiés comme ios_interfaces et ios_l3_interfaces. Cette progression illustre parfaitement la trajectoire d'apprentissage visée : comprendre que l'état déclaratif d'une infrastructure nécessite un investissement en termes de conception logicielle.

De même, le Lab 16 sur l'installation des serveurs Web dans des conteneurs Incus pousse les étudiants à développer une logique conditionnelle élaborée pour vérifier l'état actuel avant toute modification, comme l'illustrent les tâches de gestion des conteneurs qui déterminent si un conteneur doit être créé ou simplement démarré. Ces exercices pratiques transforment un concept théorique - l'idempotence - en compétence technique concrète. Ils permettent ainsi aux étudiants de comprendre par la pratique que la déclaration précise de l'état attendu d'une infrastructure IaaS exige une réflexion approfondie sur les conditions préalables, les états intermédiaires et les résultats finaux de chaque opération d'automatisation.

En conclusion, l'objectif de l'édition 2025 des supports de travaux pratiques du module d'automatisation DevOps est de montrer aux étudiants l'importance de l'idempotence et de la précision dans la déclaration de l'état attendu d'une infrastructure. En utilisant des outils comme Ansible, ces supports pratiques proposent une approche concrète pour comprendre comment gérer efficacement les infrastructures automatisées.

Vous êtes invités à explorer ce document et à partager vos retours. Votre expérience contribuera à l'amélioration continue de ces ressources pédagogiques.