Tellsanguis
3c18e17224
- Ajouter champ last_update dans le frontmatter de tous les fichiers de documentation - Dates extraites de l'historique git (en excluant le commit de modification des tags) - Résout le problème des dates incorrectes sur Cloudflare Pages (shallow clone) - Projets OpenClassrooms: 22 novembre 2025 - Homelab actuel: 25-30 novembre 2025 - OpenWRT et autres: 2-3 décembre 2025
244 lines
8.7 KiB
Markdown
244 lines
8.7 KiB
Markdown
---
|
|
sidebar_position: 2
|
|
tags: [ansible, automatisation, iac, homelab]
|
|
last_update:
|
|
date: 2025-12-03
|
|
---
|
|
|
|
# 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 :
|
|
- **Dépôt en ligne** : [https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose)
|
|
|
|
### 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 :
|
|
|
|
```yaml
|
|
- 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** :
|
|
|
|
```bash
|
|
# É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
|
|
|
|
```bash
|
|
# Déployer l'infrastructure complète
|
|
ansible-playbook playbook.yml --ask-vault-pass
|
|
```
|
|
|
|
### Déploiement avec tags
|
|
|
|
```bash
|
|
# 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
|
|
|
|
```bash
|
|
# 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](https://forgejo.tellserv.fr/Tellsanguis/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](../homelab-futur/index.md) avec l'adoption de Kubernetes et GitOps.
|