Veille : l'Infrastructure as Code, d'Ansible à GitOps

L'initiation à Ansible pendant le stage m'a conduit à étudier le sujet plus large de l'Infrastructure as Code (IaC) : décrire les serveurs et leur configuration dans des fichiers versionnés plutôt que de les configurer manuellement. Synthèse de cette veille.

Le principe

Avec Ansible, une configuration devient un playbook YAML versionné dans Git. Différence structurante avec un script shell : l'idempotence - rejouer le playbook converge vers l'état décrit, sans effet de bord. Le playbook sert aussi de documentation exécutable de l'infrastructure.

# playbook.yml - exemple minimal testé pendant le stage
- hosts: web
  become: true
  tasks:
    - name: Installer nginx
      ansible.builtin.apt:
        name: nginx
        state: present
    - name: Démarrer et activer le service
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

L'écosystème

La tendance dépasse Ansible : Terraform et OpenTofu pour le provisioning cloud, conteneurs et Kubernetes pour l'exécution, GitOps pour piloter l'ensemble depuis des dépôts Git. Le fil conducteur : appliquer à l'infrastructure les pratiques du développement logiciel - revue de code, CI, historique, rollback.

Mon analyse

Pour mon profil, l'IaC est une compétence charnière entre développement et opérations - exactement la zone où je veux travailler. Limite constatée en stage : dans une petite structure, tout automatiser n'est pas toujours rentable ; l'IaC se justifie quand l'infrastructure évolue ou se multiplie. Savoir évaluer ce seuil fait partie du métier.

• À court terme : approfondir Ansible (rôles, inventaires, Vault) sur mes propres projets.
• À moyen terme : Terraform sur un petit projet cloud personnel.
• En continu : suivre les blogs d'ingénierie et l'actualité DevOps pour rester en veille active.