Docker est une **plateforme de conteneurisation** qui permet d'empaqueter des applications et leurs dépendances dans des conteneurs légers et isolés.
### Les conteneurs : révolution de l'infrastructure moderne
Un conteneur est une unité logicielle standardisée qui contient :
- L'application elle-même
- Toutes ses dépendances (bibliothèques, runtime, outils système)
- Un système de fichiers isolé
- Des variables d'environnement et configuration
**Différence avec les machines virtuelles** :
- **Conteneur** : Partage le noyau de l'OS hôte, démarre en quelques secondes, très léger (~Mo)
- **VM** : Émule un OS complet, démarre en minutes, plus lourd (~Go)
### Avantages de Docker
1.**Portabilité** : "Runs anywhere" - fonctionne identiquement en développement, test et production
2.**Isolation** : Chaque conteneur est isolé, évitant les conflits de dépendances
3.**Légèreté** : Consomme moins de ressources qu'une VM (pas de virtualisation complète)
4.**Rapidité** : Démarrage instantané des applications
5.**Reproductibilité** : Image Docker = environnement identique à chaque fois
6.**Écosystème** : Docker Hub contient des milliers d'images prêtes à l'emploi
## Docker Compose : orchestration simplifiée
Docker Compose est un **outil d'orchestration** pour définir et gérer des applications multi-conteneurs.
### Pourquoi Docker Compose ?
Sans Compose, déployer une application avec plusieurs conteneurs (app + base de données + cache + ...) nécessite de longues commandes `docker run` difficiles à maintenir.
Avec Compose :
- **Configuration déclarative** : Tout est défini dans un fichier `compose.yml`
- **Gestion groupée** : Démarrer/arrêter tous les services en une commande
- **Réseaux automatiques** : Les conteneurs communiquent facilement entre eux
- **Volumes persistants** : Gestion simple du stockage
- **Variables d'environnement** : Configuration flexible via fichiers `.env`
### Fichier compose.yml
Un fichier Compose définit :
- Les **services** (conteneurs)
- Les **réseaux** (communication entre conteneurs)
- Les **volumes** (persistance des données)
- Les **variables d'environnement** (configuration)
## Exemples de stacks Docker Compose
Mes stacks Docker Compose sont disponibles dans le dépôt Ansible sous `stacks/`. Voici quelques exemples représentatifs :
### Exemple 1 : Traefik - Reverse Proxy avancé
Traefik est le point d'entrée de toute l'infrastructure. Ce compose illustre une configuration avancée avec **deux instances Traefik** (publique et privée) :
- Possibilité de restreindre certains services au local uniquement
### 5. Restart policies et graceful shutdown
Configuration de la résilience :
```yaml
restart: unless-stopped
stop_grace_period: 10s
```
-`unless-stopped` : Redémarre automatiquement sauf si arrêt manuel
-`stop_grace_period` : Temps pour terminer proprement avant SIGKILL
### 6. Watchtower pour le monitoring des mises à jour
Label pour activer le monitoring :
```yaml
labels:
- "com.centurylinklabs.watchtower.enable=true"
```
**Important** : Watchtower est utilisé **uniquement pour notifier** des nouvelles versions d'images disponibles. Les mises à jour sont effectuées **manuellement** pour garder le contrôle sur les changements.
Dans le [Futur Homelab](../homelab-futur/index.md), la gestion automatisée des mises à jour sera implémentée via Renovate Bot directement intégré à Forgejo.
## Gestion des stacks avec Docker Compose
### Commandes essentielles
```bash
# Démarrer tous les services
docker compose up -d
# Arrêter tous les services
docker compose down
# Voir les logs d'un service
docker compose logs -f service_name
# Redémarrer un service
docker compose restart service_name
# Mettre à jour les images et redéployer
docker compose pull
docker compose up -d
# Voir l'état des conteneurs
docker compose ps
```
### Déploiement via Ansible
Dans ma configuration, les stacks sont déployées automatiquement par Ansible :
1. Génération des fichiers `.env` depuis les templates
2. Synchronisation des dossiers `stacks/` vers `/opt/stacks/`
3. Exécution de `docker compose up -d` pour chaque stack
Voir la page [Playbooks Ansible](./playbooks-ansible.md) pour plus de détails.
## Avantages de Docker Compose pour un homelab
### Simplicité
- Fichiers YAML lisibles et maintenables
- Pas de syntaxe complexe comme Kubernetes
- Courbe d'apprentissage douce
### Performance
- Démarrage instantané des services
- Faible overhead (pas de cluster Kubernetes)
- Idéal pour des machines modestes
### Flexibilité
- Facile d'ajouter/retirer des services
- Possibilité de tester rapidement de nouvelles applications
- Configuration par environnement (dev, staging, prod)
### Écosystème riche
- Docker Hub : des milliers d'images prêtes à l'emploi
- LinuxServer.io : images optimisées et bien maintenues
- Communauté active : documentation et support
## Limitations de Docker Compose
Malgré ses avantages, Docker Compose a des limitations pour un usage production à grande échelle :
1.**Pas de haute disponibilité** : Tout est sur une seule machine
2.**Pas de scaling horizontal** : Impossible de répartir la charge sur plusieurs serveurs
3.**Pas d'orchestration avancée** : Pas de rolling updates, canary deployments, etc.
4.**Gestion manuelle** : Déploiements via Ansible, pas de GitOps natif
**Note** : L'utilisation de `restart: unless-stopped` assure le redémarrage automatique des conteneurs après un arrêt inattendu, offrant une forme basique de résilience.
Ces limitations expliquent pourquoi je migre vers **Kubernetes (K3S)** pour le futur homelab. Voir la section [Futur Homelab](../homelab-futur/index.md).
## Pourquoi pas Docker Swarm ?
Lors de la réflexion sur l'évolution de mon infrastructure, **Docker Swarm** a été considéré comme une alternative à Kubernetes pour l'orchestration de conteneurs.
### Docker Swarm : un choix tentant mais dépassé
**Avantages de Docker Swarm** :
- Intégré nativement à Docker (pas d'installation supplémentaire)
- Configuration plus simple que Kubernetes
- Courbe d'apprentissage plus douce
- Utilise directement les fichiers Docker Compose (avec quelques adaptations)
- Moins gourmand en ressources que Kubernetes
**Pourquoi je ne l'ai pas choisi** :
1.**Kubernetes est le standard de l'industrie** : La grande majorité des entreprises utilisent Kubernetes en production. Apprendre K8S offre des compétences directement transférables au monde professionnel.
2.**Écosystème et communauté** : Kubernetes bénéficie d'un écosystème beaucoup plus riche (Helm, operators, nombreux outils DevOps) et d'une communauté bien plus large.
3.**Fonctionnalités avancées** : Kubernetes offre des capacités que Docker Swarm ne possède pas :
- Rolling updates et rollbacks plus avancés
- Gestion fine des ressources (CPU/RAM limits, requests)
- Politiques réseau (Network Policies) plus élaborées
- Support natif du GitOps (ArgoCD, Flux)
- Stockage distribué mieux intégré (CSI drivers)
4.**Évolution et support** : Docker Inc. a clairement orienté son développement vers Kubernetes plutôt que Swarm. Swarm est maintenu, mais n'évolue plus beaucoup.
5.**Objectif d'apprentissage** : Mon but étant d'acquérir des compétences DevOps modernes, maîtriser Kubernetes est un meilleur investissement à long terme.
**Conclusion** : Bien que Docker Swarm soit plus simple et suffisant pour de nombreux homelabs, j'ai préféré investir directement dans l'apprentissage de Kubernetes, qui est devenu le standard incontournable de l'orchestration de conteneurs.