Aller au contenu principal

Playbooks Ansible

Qu'est-ce qu'Ansible ?​

Ansible est un outil d'automatisation informatique open-source développé par Red Hat. Il permet de gérer la configuration, le déploiement et l'orchestration d'infrastructures de manière déclarative et reproductible.

Pourquoi Ansible ?​

Ansible présente plusieurs avantages majeurs :

  • Agentless : Pas besoin d'installer un agent sur les machines cibles, fonctionne via SSH
  • Déclaratif : On décrit l'état désiré, Ansible s'occupe de le réaliser
  • Idempotent : Exécuter plusieurs fois le même playbook produit le même résultat
  • Lisible : Syntaxe YAML simple et claire, accessible même aux débutants
  • Extensible : Large bibliothèque de modules pour gérer tous types de systèmes

Pourquoi maîtriser Ansible aujourd'hui ?​

Ansible est devenu un standard de l'industrie pour l'automatisation des infrastructures :

  1. DevOps et SRE : Compétence essentielle pour les rôles DevOps, SRE et administrateur système moderne
  2. Infrastructure as Code : Permet de versionner et documenter l'infrastructure comme du code
  3. Gain de temps : Automatise les tâches répétitives et réduit les erreurs humaines
  4. Scalabilité : Gère facilement des dizaines ou centaines de serveurs
  5. Intégration CI/CD : S'intègre parfaitement dans les pipelines d'intégration continue

Structure de mes playbooks​

Mon infrastructure Ansible est disponible sur Forgejo :

Architecture du projet​

infra-ansible/
├── playbook.yml              # Playbook principal
├── inventory/
│   └── hosts.yml            # Inventaire des serveurs
├── roles/                   # Rôles Ansible
│   ├── common/             # Configuration de base
│   ├── docker/             # Installation Docker
│   ├── cockpit/            # Interface web Cockpit
│   └── services/           # Déploiement des services
├── stacks/                  # Docker Compose files
│   ├── traefik/
│   ├── vaultwarden/
│   ├── photoprism/
│   └── ...
├── templates/               # Templates Jinja2
│   └── env/                # Templates .env
└── vars/                    # Variables
    └── secrets.yml         # Secrets chiffrés (Ansible Vault)

Playbook principal​

Le playbook principal (playbook.yml) orchestre le provisionnement complet du homelab :

- name: Provision Homelab
  hosts: homeserver
  become: true

  vars:
    cloudflare_dns: "1.1.1.1"

  vars_files:
    - vars/secrets.yml

  roles:
    - common
    - cockpit
    - docker
    - services

Rôles Ansible​

1. Rôle common - Configuration de base​

Le rôle common configure les éléments fondamentaux du système :

Paquets installés :

  • Utilitaires système : git, curl, htop
  • Firewall : firewalld
  • Stockage : mergerfs pour unifier les disques
  • DNS local : dnsmasq

Configuration DNS locale :

  • Désactivation de systemd-resolved
  • Configuration de dnsmasq pour résoudre *.local.tellserv.fr localement
  • Redirection des autres requêtes vers Cloudflare DNS (1.1.1.1)
  • Écoute sur le port 53 (UDP et TCP) pour les clients locaux et Tailscale

Configuration Firewall :

  • Ouverture SSH (22/tcp)
  • Ouverture HTTP/HTTPS (80/tcp, 443/tcp)
  • Ouverture DNS (53/udp, 53/tcp)

Stockage MergerFS :

  • Création du point de montage /mnt/storage
  • Permet d'unifier plusieurs disques en un seul système de fichiers

2. Rôle docker - Installation Docker​

Le rôle docker installe et configure Docker selon les bonnes pratiques officielles :

Installation :

  • Ajout du dépôt officiel Docker
  • Installation de Docker Engine, CLI et plugins (Compose, Buildx)
  • Configuration du service Docker (démarrage automatique)

Configuration Traefik :

  • Création du réseau Docker traefik_network (partagé entre tous les services)
  • Création des répertoires pour les logs Traefik (/var/log/traefik)
  • Création des répertoires pour les certificats Let's Encrypt (/etc/letsencrypt/traefik)

Gestion des utilisateurs :

  • Ajout de l'utilisateur Ansible au groupe docker pour exécuter les commandes sans sudo

3. Rôle cockpit - Interface web d'administration​

Le rôle cockpit installe Cockpit, une interface web moderne pour administrer le serveur Linux :

  • Installation du paquet cockpit
  • Activation et démarrage du service
  • Accessible via le navigateur pour surveiller le serveur (CPU, RAM, disques, services, etc.)

4. Rôle services - Déploiement des stacks Docker​

Le rôle services est le plus complexe. Il gère le déploiement de tous les services Docker Compose :

Génération des fichiers .env :

  • Utilise des templates Jinja2 pour générer les fichiers .env
  • Les secrets sont stockés dans vars/secrets.yml (chiffré avec Ansible Vault)
  • Génère les .env en local avant la synchronisation

Synchronisation des stacks :

  • Copie l'ensemble du dossier stacks/ vers le serveur (/opt/stacks/)
  • Préserve les permissions des fichiers

Déploiement automatique :

  • Recherche tous les fichiers compose.yml dans /opt/stacks/
  • Arrête les conteneurs existants (docker compose down)
  • Met à jour les images Docker (docker compose pull)
  • Déploie chaque stack avec docker compose up -d --build

Déploiement sélectif avec tags :

  • Permet de déployer un seul service avec --tags <service_name>
  • Exemple : ansible-playbook playbook.yml --tags traefik
  • Disponible pour tous les services (traefik, vaultwarden, photoprism, etc.)

Gestion des secrets​

Les secrets sensibles (mots de passe, tokens API, etc.) sont chiffrés avec Ansible Vault :

# Éditer les secrets
ansible-vault edit vars/secrets.yml

# Exécuter le playbook avec les secrets
ansible-playbook playbook.yml --ask-vault-pass

Cette approche garantit que les secrets ne sont jamais stockés en clair dans Git.

Exécution du playbook​

Déploiement complet​

# Déployer l'infrastructure complète
ansible-playbook playbook.yml --ask-vault-pass

Déploiement avec tags​

# Déployer seulement la configuration de base
ansible-playbook playbook.yml --tags common

# Déployer seulement Docker
ansible-playbook playbook.yml --tags docker

# Mettre à jour les images et redéployer les services
ansible-playbook playbook.yml --tags deploy,pull

# Déployer un seul service
ansible-playbook playbook.yml --tags traefik

Génération des fichiers .env uniquement​

# Regénérer les .env sans déployer
ansible-playbook playbook.yml --tags env,secrets

Avantages de cette approche​

Reproductibilité​

En exécutant le playbook sur un nouveau serveur Ubuntu, l'infrastructure complète est recréée à l'identique :

  • Tous les paquets installés
  • Toutes les configurations appliquées
  • Tous les services déployés

Documentation vivante​

Le code Ansible documente l'infrastructure :

  • Chaque tâche décrit une action précise
  • Les rôles structurent logiquement l'infrastructure
  • Les commentaires expliquent les choix techniques

Maintenance simplifiée​

Modifier l'infrastructure devient simple :

  • Mise à jour d'un service : modifier le compose.yml et relancer Ansible
  • Ajout d'un service : créer un nouveau dossier dans stacks/ et ajouter le template .env
  • Changement de configuration : modifier le rôle et redéployer

Sécurité​

  • Les secrets sont chiffrés avec Ansible Vault
  • Les fichiers .env sont générés à la volée et jamais versionnés
  • Les configurations sont revues et testées avant déploiement

Limitations actuelles​

Malgré ses nombreux avantages, cette approche présente des limitations :

  1. Versionnement tardif : Le dépôt Git Infra_ansible_dockercompose a été créé après coup pour présenter le travail. Dans la pratique initiale, Git, les tests automatisés et la CI/CD n'étaient pas utilisés, faute de connaissances à l'époque.
  2. Pas de tests automatisés : Pas de validation automatique des playbooks (Molecule, tests d'intégration)
  3. Infrastructure monomachine : Ansible est conçu pour gérer plusieurs serveurs, mais je ne gère qu'un seul serveur
  4. Pas d'intégration CI/CD : Les déploiements sont manuels, pas de pipeline automatisé

Ces limitations seront adressées dans le Futur Homelab avec l'adoption de Kubernetes et GitOps.