Remplacement diagrammes PDF par PNG, ajout note Docker Swarm, traductions complètes
- Replace PDF diagrams with PNG images for inline display in docs - Add infrastructure diagram to Homelab actuel category page - Add network diagram to single-machine HA homelab page - Add Docker Swarm vs Kubernetes decision note in docker-compose page - Complete English translations for homepage tagline - Translate homepage tagline dynamically using Docusaurus i18n - Remove PDF diagram files from static assets (homelab-actuel-infra.pdf, homelab-futur-network.pdf) - Add new documentation pages: Docker Compose, Ansible playbooks, Traefik - Add Future Homelab pages: single-machine HA and 3-node Proxmox cluster - Remove example pages and notions category - Update sidebar configuration
This commit is contained in:
parent
cb1640c1cc
commit
ed2cca8c0e
27 changed files with 1482 additions and 636 deletions
500
docs/homelab-actuel/docker-compose.md
Normal file
500
docs/homelab-actuel/docker-compose.md
Normal file
|
|
@ -0,0 +1,500 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Docker et Docker Compose
|
||||
|
||||
## Qu'est-ce que Docker ?
|
||||
|
||||
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) :
|
||||
|
||||
```yaml
|
||||
services:
|
||||
traefik-public:
|
||||
image: traefik:v3
|
||||
container_name: traefik-public
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- "192.168.1.2:80:80"
|
||||
- "192.168.1.2:443:443"
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
networks:
|
||||
- traefik_network
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
- ./traefik-public.yml:/etc/traefik/traefik.yml:ro
|
||||
- ./dynamic-public:/etc/traefik/dynamic:ro
|
||||
- ./letsencrypt-public:/letsencrypt
|
||||
- /var/log/traefik:/var/log/traefik
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.traefik-dashboard-public.rule=Host(`traefik-public.local.tellserv.fr`)"
|
||||
- "traefik.http.routers.traefik-dashboard-public.entrypoints=local"
|
||||
- "traefik.http.routers.traefik-dashboard-public.tls.certresolver=cloudflare-local"
|
||||
- "traefik.http.routers.traefik-dashboard-public.tls=true"
|
||||
- "traefik.http.routers.traefik-dashboard-public.service=api@internal"
|
||||
- "traefik.http.middlewares.crowdsec-bouncer.forwardauth.address=http://crowdsec-bouncer:8080/api/v1/forwardAuth"
|
||||
environment:
|
||||
- CF_DNS_API_TOKEN=${CF_DNS_API_TOKEN}
|
||||
- TZ=Europe/Paris
|
||||
|
||||
traefik-private:
|
||||
image: traefik:v3
|
||||
container_name: traefik-private
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- "192.168.1.3:80:80"
|
||||
- "192.168.1.3:443:443"
|
||||
networks:
|
||||
- traefik_network
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
- ./traefik-private.yml:/etc/traefik/traefik.yml:ro
|
||||
- ./dynamic-private:/etc/traefik/dynamic:ro
|
||||
- ./letsencrypt-private:/letsencrypt
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.traefik-dashboard-local.rule=Host(`traefik-private.local.tellserv.fr`)"
|
||||
environment:
|
||||
- TZ=Europe/Paris
|
||||
- CF_DNS_API_TOKEN=${CF_DNS_API_TOKEN}
|
||||
|
||||
networks:
|
||||
traefik_network:
|
||||
external: true
|
||||
```
|
||||
|
||||
**Points clés** :
|
||||
- **Deux instances** : Séparation publique (Internet) et privée (réseau local uniquement)
|
||||
- **Socket Docker** : Traefik détecte automatiquement les nouveaux conteneurs via `/var/run/docker.sock`
|
||||
- **Certificats Let's Encrypt** : Génération automatique avec DNS-01 challenge (Cloudflare)
|
||||
- **Labels Traefik** : Configuration dynamique via labels Docker
|
||||
- **Middleware CrowdSec** : Intégration avec CrowdSec pour bloquer les IPs malveillantes
|
||||
- **Réseau externe** : Tous les services se connectent au réseau `traefik_network`
|
||||
|
||||
### Exemple 2 : Photoprism - Application avec base de données
|
||||
|
||||
Photoprism illustre une stack applicative classique (app + DB) avec configuration avancée :
|
||||
|
||||
```yaml
|
||||
services:
|
||||
photoprism:
|
||||
image: photoprism/photoprism:241021
|
||||
stop_grace_period: 10s
|
||||
depends_on:
|
||||
- mariadb
|
||||
restart: unless-stopped
|
||||
security_opt:
|
||||
- seccomp:unconfined
|
||||
- apparmor:unconfined
|
||||
working_dir: "/photoprism"
|
||||
volumes:
|
||||
- "/mnt/storage/photos:/photoprism/import"
|
||||
- "/mnt/storage/photoprism/originals:/photoprism/originals"
|
||||
- "/mnt/storage/photoprism/storage:/photoprism/storage"
|
||||
environment:
|
||||
- PHOTOPRISM_DATABASE_DRIVER=mysql
|
||||
- PHOTOPRISM_DATABASE_SERVER=mariadb:3306
|
||||
- PHOTOPRISM_DATABASE_NAME=photoprism
|
||||
- PHOTOPRISM_DATABASE_USER=${MARIADB_USER}
|
||||
- PHOTOPRISM_DATABASE_PASSWORD=${PHOTOPRISM_DATABASE_PASSWORD}
|
||||
- PHOTOPRISM_ADMIN_USER=${PHOTOPRISM_ADMIN_USER}
|
||||
- PHOTOPRISM_ADMIN_PASSWORD=${PHOTOPRISM_ADMIN_PASSWORD}
|
||||
- PHOTOPRISM_SITE_URL=https://photoprism.tellserv.fr/
|
||||
- PHOTOPRISM_HTTP_COMPRESSION=gzip
|
||||
- PHOTOPRISM_JPEG_QUALITY=85
|
||||
networks:
|
||||
- traefik_network
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.${COMPOSE_PROJECT_NAME}-local.rule=Host(`${COMPOSE_PROJECT_NAME}.local.tellserv.fr`)"
|
||||
- "traefik.http.routers.${COMPOSE_PROJECT_NAME}-local.entryPoints=local"
|
||||
- "traefik.http.routers.${COMPOSE_PROJECT_NAME}-local.tls=true"
|
||||
- "traefik.http.routers.${COMPOSE_PROJECT_NAME}-prod.rule=Host(`${COMPOSE_PROJECT_NAME}.tellserv.fr`)"
|
||||
- "traefik.http.routers.${COMPOSE_PROJECT_NAME}-prod.entryPoints=websecure"
|
||||
- "traefik.http.routers.${COMPOSE_PROJECT_NAME}-prod.tls.certResolver=cloudflare"
|
||||
- "traefik.http.services.${COMPOSE_PROJECT_NAME}.loadbalancer.server.port=2342"
|
||||
- "com.centurylinklabs.watchtower.enable=true"
|
||||
|
||||
mariadb:
|
||||
image: mariadb:11
|
||||
restart: unless-stopped
|
||||
stop_grace_period: 5s
|
||||
command: >
|
||||
--innodb-buffer-pool-size=512M
|
||||
--transaction-isolation=READ-COMMITTED
|
||||
--character-set-server=utf8mb4
|
||||
--collation-server=utf8mb4_unicode_ci
|
||||
--max-connections=512
|
||||
volumes:
|
||||
- ./database:/var/lib/mysql
|
||||
environment:
|
||||
- MARIADB_DATABASE=photoprism
|
||||
- MARIADB_USER=${MARIADB_USER}
|
||||
- MARIADB_PASSWORD=${MARIADB_PASSWORD}
|
||||
- MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
|
||||
networks:
|
||||
- traefik_network
|
||||
|
||||
networks:
|
||||
traefik_network:
|
||||
external: true
|
||||
```
|
||||
|
||||
**Points clés** :
|
||||
- **Dépendances** : `depends_on` garantit que MariaDB démarre avant Photoprism
|
||||
- **Volumes montés** : Accès au stockage MergerFS (`/mnt/storage`) pour les photos
|
||||
- **Base de données** : MariaDB optimisée pour Photoprism (buffer pool, character set UTF-8)
|
||||
- **Variables d'environnement** : Secrets injectés via fichier `.env` (non versionné)
|
||||
- **Double exposition** : Accessible en local (`.local.tellserv.fr`) et sur Internet (`.tellserv.fr`)
|
||||
- **Watchtower** : Label pour activer les mises à jour automatiques
|
||||
- **Optimisations DB** : Configuration MariaDB adaptée (buffer pool, connexions, charset)
|
||||
|
||||
### Exemple 3 : Mobilizon - Application multi-conteneurs avec réseau interne
|
||||
|
||||
Mobilizon démontre l'utilisation de **réseaux Docker multiples** (externe + interne) :
|
||||
|
||||
```yaml
|
||||
services:
|
||||
mobilizon:
|
||||
user: "1000:1000"
|
||||
restart: always
|
||||
image: docker.io/framasoft/mobilizon
|
||||
env_file: .env
|
||||
depends_on:
|
||||
- db
|
||||
volumes:
|
||||
- ./uploads:/var/lib/mobilizon/uploads
|
||||
- ./tzdata:/var/lib/mobilizon/tzdata
|
||||
networks:
|
||||
- traefik_network
|
||||
- mobilizon_internal
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.mobilizon-local.rule=Host(`mobilizon.local.tellserv.fr`)"
|
||||
- "traefik.http.routers.mobilizon-local.entryPoints=local"
|
||||
- "traefik.http.routers.mobilizon-prod.rule=Host(`mobilizon.tellserv.fr`)"
|
||||
- "traefik.http.routers.mobilizon-prod.entryPoints=websecure"
|
||||
- "traefik.http.routers.mobilizon-prod.tls.certResolver=cloudflare"
|
||||
- "traefik.http.services.mobilizon.loadbalancer.server.port=5005"
|
||||
|
||||
db:
|
||||
image: docker.io/postgis/postgis:15-3.4
|
||||
restart: always
|
||||
env_file: .env
|
||||
volumes:
|
||||
- ./db:/var/lib/postgresql/data:z
|
||||
networks:
|
||||
- mobilizon_internal
|
||||
|
||||
networks:
|
||||
mobilizon_internal:
|
||||
ipam:
|
||||
driver: default
|
||||
traefik_network:
|
||||
external: true
|
||||
```
|
||||
|
||||
**Points clés** :
|
||||
- **Deux réseaux** :
|
||||
- `traefik_network` (externe) : Mobilizon communique avec Traefik
|
||||
- `mobilizon_internal` (interne) : Communication privée entre Mobilizon et PostgreSQL
|
||||
- **Sécurité** : La base de données n'est pas exposée sur le réseau Traefik
|
||||
- **PostgreSQL avec PostGIS** : Extension géographique pour gérer les événements géolocalisés
|
||||
- **User ID** : Exécution avec UID/GID spécifique pour gérer les permissions fichiers
|
||||
- **Volume avec SELinux** : Flag `:z` pour la compatibilité SELinux
|
||||
|
||||
### Exemple 4 : Vaultwarden - Gestion des secrets
|
||||
|
||||
Vaultwarden (gestionnaire de mots de passe) montre une configuration axée sécurité :
|
||||
|
||||
```yaml
|
||||
services:
|
||||
vaultwarden:
|
||||
image: vaultwarden/server:1.32.7
|
||||
container_name: vaultwarden
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- TZ=Europe/Paris
|
||||
- ADMIN_TOKEN=${VAULTWARDEN_ADMIN_TOKEN}
|
||||
- SIGNUPS_ALLOWED=${SIGNUPS_ALLOWED}
|
||||
- SMTP_FROM=${SMTP_FROM}
|
||||
- SMTP_HOST=${SMTP_HOST}
|
||||
- SMTP_PORT=${SMTP_PORT}
|
||||
- SMTP_SECURITY=${SMTP_SECURITY}
|
||||
- SMTP_USERNAME=${SMTP_USERNAME}
|
||||
- SMTP_PASSWORD=${SMTP_PASSWORD}
|
||||
- EXPERIMENTAL_CLIENT_FEATURE_FLAGS=ssh-key-vault-item,ssh-agent
|
||||
volumes:
|
||||
- ./vw-data:/data
|
||||
networks:
|
||||
- traefik_network
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.vaultwarden-local.rule=Host(`vaultwarden.local.tellserv.fr`)"
|
||||
- "traefik.http.routers.vaultwarden-prod.rule=Host(`vaultwarden.tellserv.fr`)"
|
||||
- "traefik.http.routers.vaultwarden-prod.tls.certResolver=cloudflare"
|
||||
- "com.centurylinklabs.watchtower.enable=true"
|
||||
|
||||
networks:
|
||||
traefik_network:
|
||||
external: true
|
||||
```
|
||||
|
||||
**Points clés** :
|
||||
- **Secrets via .env** : Tous les mots de passe et tokens dans des variables d'environnement
|
||||
- **Configuration SMTP** : Envoi d'emails pour les notifications et récupération de compte
|
||||
- **Features expérimentales** : Support des clés SSH dans le coffre-fort
|
||||
- **Volume de données** : Persistance du coffre-fort dans `./vw-data`
|
||||
- **Exposition sécurisée** : HTTPS obligatoire via Traefik avec Let's Encrypt
|
||||
|
||||
## Patterns et bonnes pratiques
|
||||
|
||||
### 1. Réseau externe `traefik_network`
|
||||
|
||||
Tous mes services utilisent un **réseau Docker externe** partagé :
|
||||
|
||||
```yaml
|
||||
networks:
|
||||
traefik_network:
|
||||
external: true
|
||||
```
|
||||
|
||||
Avantages :
|
||||
- Traefik détecte automatiquement les nouveaux services
|
||||
- Communication entre services via leurs noms (ex: `http://vaultwarden`)
|
||||
- Isolation par défaut (services non connectés ne peuvent pas communiquer)
|
||||
|
||||
### 2. Labels Traefik pour la configuration dynamique
|
||||
|
||||
Au lieu de fichiers de configuration statiques, j'utilise des **labels Docker** :
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.myapp.rule=Host(`myapp.tellserv.fr`)"
|
||||
- "traefik.http.routers.myapp.tls.certResolver=cloudflare"
|
||||
```
|
||||
|
||||
Avantages :
|
||||
- Configuration colocalisée avec le service
|
||||
- Déploiement d'un nouveau service = ajout automatique dans Traefik
|
||||
- Pas de rechargement manuel de Traefik
|
||||
|
||||
### 3. Variables d'environnement avec fichiers .env
|
||||
|
||||
Tous les secrets sont extraits dans des fichiers `.env` :
|
||||
|
||||
```env
|
||||
VAULTWARDEN_ADMIN_TOKEN=supersecret123
|
||||
MARIADB_PASSWORD=dbpassword456
|
||||
CF_DNS_API_TOKEN=cloudflare_token_789
|
||||
```
|
||||
|
||||
Avantages :
|
||||
- Aucun secret en clair dans les fichiers Compose versionnés
|
||||
- Fichiers `.env` générés dynamiquement par Ansible (templates Jinja2)
|
||||
- Rotation facile des secrets
|
||||
|
||||
### 4. Double exposition : local et production
|
||||
|
||||
Chaque service a deux entrées :
|
||||
- **Local** : `service.local.tellserv.fr` (réseau local uniquement)
|
||||
- **Production** : `service.tellserv.fr` (accessible depuis Internet)
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
- "traefik.http.routers.myapp-local.rule=Host(`myapp.local.tellserv.fr`)"
|
||||
- "traefik.http.routers.myapp-local.entryPoints=local"
|
||||
- "traefik.http.routers.myapp-prod.rule=Host(`myapp.tellserv.fr`)"
|
||||
- "traefik.http.routers.myapp-prod.entryPoints=websecure"
|
||||
```
|
||||
|
||||
Avantages :
|
||||
- Accès rapide en local (pas de latence Internet)
|
||||
- Accès à distance possible quand nécessaire
|
||||
- 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.
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Exemple
|
||||
|
||||
Ceci est une page d'exemple dans la catégorie Homelab actuel.
|
||||
|
||||
## Description
|
||||
|
||||
Cette page démontre comment documenter un service ou une configuration du homelab actuel.
|
||||
|
||||
## Configuration Docker Compose
|
||||
|
||||
Exemple de configuration d'un service :
|
||||
|
||||
```yaml
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
exemple-service:
|
||||
image: nginx:latest
|
||||
container_name: exemple
|
||||
ports:
|
||||
- "8080:80"
|
||||
volumes:
|
||||
- ./config:/etc/nginx/conf.d
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
## Playbook Ansible
|
||||
|
||||
Exemple de déploiement avec Ansible :
|
||||
|
||||
```yaml
|
||||
---
|
||||
- name: Déployer le service exemple
|
||||
hosts: homelab
|
||||
become: yes
|
||||
|
||||
tasks:
|
||||
- name: Copier le fichier docker-compose
|
||||
copy:
|
||||
src: docker-compose.yml
|
||||
dest: /opt/exemple/docker-compose.yml
|
||||
|
||||
- name: Démarrer le service
|
||||
command: docker-compose up -d
|
||||
args:
|
||||
chdir: /opt/exemple
|
||||
```
|
||||
|
||||
## Maintenance
|
||||
|
||||
Points importants pour la maintenance :
|
||||
|
||||
- Sauvegardes régulières
|
||||
- Mises à jour de l'image Docker
|
||||
- Surveillance des logs
|
||||
- Tests de restauration
|
||||
|
|
@ -15,17 +15,31 @@ Mon homelab actuel utilise une approche simple et efficace :
|
|||
|
||||
## Architecture
|
||||
|
||||
### Schéma d'infrastructure
|
||||
|
||||
Le diagramme illustre l'architecture complète de mon homelab actuel, incluant :
|
||||
- L'infrastructure réseau avec le serveur principal
|
||||
- Les services Docker déployés
|
||||
- La configuration Traefik pour le reverse proxy (instances publique et privée)
|
||||
- Les connexions entre les différents composants
|
||||
- La configuration DNS locale avec dnsmasq
|
||||
|
||||
|
||||
|
||||
### Infrastructure physique/virtuelle
|
||||
- Serveurs dédiés ou VM
|
||||
- Réseau local sécurisé
|
||||
- Stockage et sauvegardes
|
||||
- Serveur dédié Ubuntu Server
|
||||
- Réseau local sécurisé avec DNS local (dnsmasq)
|
||||
- Stockage unifié avec MergerFS
|
||||
- Firewall avec firewalld
|
||||
|
||||
### Stack technique
|
||||
- **OS** : Linux (Debian/Ubuntu)
|
||||
- **OS** : Linux (Ubuntu Server)
|
||||
- **Conteneurisation** : Docker & Docker Compose
|
||||
- **Automatisation** : Ansible playbooks
|
||||
- **Reverse proxy** : Traefik ou Nginx
|
||||
- **Monitoring** : Prometheus, Grafana
|
||||
- **Reverse proxy** : Traefik v3 (instances publique et privée)
|
||||
- **Sécurité** : CrowdSec, TLS avec Let's Encrypt
|
||||
- **Monitoring** : Beszel, Uptime Kuma
|
||||
- **DNS local** : dnsmasq pour la résolution *.local.tellserv.fr
|
||||
|
||||
## Services déployés
|
||||
|
||||
|
|
@ -41,18 +55,39 @@ La documentation détaille :
|
|||
- Simple à mettre en place et maintenir
|
||||
- Ansible permet une automatisation complète
|
||||
- Docker Compose facilite la gestion des services
|
||||
- Reproductible et versionné avec Git
|
||||
- Idéal pour un apprentissage progressif de l'automatisation
|
||||
|
||||
## Limitations
|
||||
|
||||
- Scalabilité limitée
|
||||
- Pas de haute disponibilité native
|
||||
- Orchestration manuelle pour certaines tâches
|
||||
Cette infrastructure présente plusieurs limitations importantes qui motivent l'évolution vers une nouvelle approche (voir section "Futur Homelab").
|
||||
|
||||
Ces limitations motivent l'évolution vers Kubernetes (voir section "Futur Homelab").
|
||||
### Absence initiale de versionnement Git
|
||||
|
||||
## Articles
|
||||
L'une des principales limitations de cette approche initiale était l'**absence de versionnement de l'infrastructure avec Git**. À ce stade de mon parcours, je ne maîtrisais pas encore la philosophie DevOps et les bonnes pratiques de gestion du code d'infrastructure.
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
**Conséquences de cette limitation :**
|
||||
- Pas d'historique des changements de configuration
|
||||
- Difficile de revenir en arrière en cas de problème
|
||||
- Pas de traçabilité des modifications
|
||||
- Collaboration complexe
|
||||
- Absence de processus de revue de code (code review)
|
||||
- Risque de divergence entre documentation et réalité
|
||||
|
||||
<DocCardList />
|
||||
Cette lacune a été une **leçon importante** qui m'a poussé à :
|
||||
1. Corriger progressivement cette infrastructure en versionnant les playbooks Ansible et Docker Compose
|
||||
2. Adopter Git et les pratiques DevOps pour tous mes projets futurs
|
||||
3. Intégrer la philosophie "Infrastructure as Code" dès la conception
|
||||
|
||||
**Note importante** : 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 réalisé. Dans la pratique initiale, Git, les tests automatisés et la CI/CD n'étaient pas utilisés, faute de connaissances à l'époque.
|
||||
|
||||
Le versionnement Git est maintenant en place pour cette infrastructure, mais l'architecture elle-même reste limitée (voir ci-dessous).
|
||||
|
||||
### Limitations techniques de l'architecture
|
||||
|
||||
- **Scalabilité limitée** : Infrastructure monomachine sans possibilité de distribution de charge
|
||||
- **Pas de haute disponibilité** : Point unique de défaillance (SPOF)
|
||||
- **Orchestration manuelle** : Certaines tâches nécessitent encore une intervention manuelle
|
||||
- **CI/CD absent initialement** : Déploiements manuels via Ansible (pas d'automatisation sur push Git)
|
||||
- **Tests limités** : Pas de validation automatique des changements avant déploiement
|
||||
|
||||
Ces limitations motivent l'évolution vers Kubernetes (K3S) et une approche Infrastructure as Code complète avec CI/CD (voir section [Futur Homelab](../homelab-futur/index.md)).
|
||||
|
|
|
|||
241
docs/homelab-actuel/playbooks-ansible.md
Normal file
241
docs/homelab-actuel/playbooks-ansible.md
Normal file
|
|
@ -0,0 +1,241 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# 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.
|
||||
17
docs/homelab-actuel/traefik.md
Normal file
17
docs/homelab-actuel/traefik.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Traefik - Reverse Proxy moderne
|
||||
|
||||
:::info
|
||||
Cette page sera complétée prochainement avec des détails sur la configuration Traefik.
|
||||
:::
|
||||
|
||||
## À venir
|
||||
|
||||
- Configuration détaillée des deux instances Traefik (publique et privée)
|
||||
- Gestion des certificats SSL avec Let's Encrypt
|
||||
- Intégration avec CrowdSec pour la sécurité
|
||||
- Configuration des middlewares
|
||||
- Routing et gestion des domaines
|
||||
11
docs/homelab-futur/cluster-3-noeuds-proxmox.md
Normal file
11
docs/homelab-futur/cluster-3-noeuds-proxmox.md
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Cluster 3 noeuds Proxmox : un véritable Homelab HA
|
||||
|
||||
Documentation à venir...
|
||||
|
||||
## Architecture cible
|
||||
|
||||
Cette page sera complétée avec les détails de l'architecture finale du cluster Proxmox 3 nœuds.
|
||||
|
|
@ -1,153 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Exemple
|
||||
|
||||
Ceci est une page d'exemple dans la catégorie Futur Homelab.
|
||||
|
||||
## Description
|
||||
|
||||
Cette page démontre comment documenter les configurations et déploiements Kubernetes du futur homelab.
|
||||
|
||||
## Déploiement Kubernetes
|
||||
|
||||
Exemple de manifeste pour un déploiement :
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: exemple-app
|
||||
namespace: production
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: exemple
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: exemple
|
||||
spec:
|
||||
containers:
|
||||
- name: app
|
||||
image: nginx:latest
|
||||
ports:
|
||||
- containerPort: 80
|
||||
resources:
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 128Mi
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: exemple-service
|
||||
namespace: production
|
||||
spec:
|
||||
selector:
|
||||
app: exemple
|
||||
ports:
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
type: ClusterIP
|
||||
```
|
||||
|
||||
## Configuration OpenTofu
|
||||
|
||||
Exemple de ressource infrastructure :
|
||||
|
||||
```hcl
|
||||
resource "kubernetes_namespace" "production" {
|
||||
metadata {
|
||||
name = "production"
|
||||
labels = {
|
||||
environment = "production"
|
||||
managed-by = "opentofu"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
resource "kubernetes_deployment" "exemple" {
|
||||
metadata {
|
||||
name = "exemple-app"
|
||||
namespace = kubernetes_namespace.production.metadata[0].name
|
||||
}
|
||||
|
||||
spec {
|
||||
replicas = 3
|
||||
|
||||
selector {
|
||||
match_labels = {
|
||||
app = "exemple"
|
||||
}
|
||||
}
|
||||
|
||||
template {
|
||||
metadata {
|
||||
labels = {
|
||||
app = "exemple"
|
||||
}
|
||||
}
|
||||
|
||||
spec {
|
||||
container {
|
||||
image = "nginx:latest"
|
||||
name = "app"
|
||||
|
||||
resources {
|
||||
limits = {
|
||||
cpu = "100m"
|
||||
memory = "128Mi"
|
||||
}
|
||||
requests = {
|
||||
cpu = "50m"
|
||||
memory = "64Mi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## GitOps avec ArgoCD
|
||||
|
||||
Configuration ArgoCD Application :
|
||||
|
||||
```yaml
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: exemple-app
|
||||
namespace: argocd
|
||||
spec:
|
||||
project: default
|
||||
source:
|
||||
repoURL: https://forgejo.tellserv.fr/Tellsanguis/k8s-manifests.git
|
||||
targetRevision: HEAD
|
||||
path: apps/exemple
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: production
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
```
|
||||
|
||||
## Observabilité
|
||||
|
||||
Points de surveillance pour ce service :
|
||||
|
||||
- Métriques Prometheus exposées sur `/metrics`
|
||||
- Logs agrégés dans Loki
|
||||
- Traces distribuées avec Tempo
|
||||
- Alertes configurées dans Prometheus AlertManager
|
||||
|
|
@ -70,9 +70,3 @@ Cette migration représente :
|
|||
- **Apprentissage pratique** : Expérimentation en conditions réelles
|
||||
- **Évolution technique** : Passage à des solutions modernes et scalables
|
||||
- **Portfolio** : Démonstration de compétences DevOps avancées
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
|
|
|
|||
279
docs/homelab-futur/premiere-version-ha-monomachine.md
Normal file
279
docs/homelab-futur/premiere-version-ha-monomachine.md
Normal file
|
|
@ -0,0 +1,279 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Première version : le Homelab "HA" monomachine (projet initial)
|
||||
|
||||
## Introduction
|
||||
|
||||
**Note importante** : Cette page décrit le **projet initial** que j'avais envisagé pour expérimenter avec Kubernetes. Ce projet a **évolué** vers une décision finale différente : un cluster Proxmox 3 nœuds (voir [Cluster 3 noeuds Proxmox](./cluster-3-noeuds-proxmox.md)).
|
||||
|
||||
L'idée initiale était de créer une **étape transitoire** vers une infrastructure distribuée complète, en expérimentant avec Kubernetes (K3S), l'Infrastructure as Code (OpenTofu/Terraform), Git et les pipelines CI/CD, tout en restant sur une seule machine physique.
|
||||
|
||||
## Objectifs de cette version
|
||||
|
||||
### Apprentissage pratique
|
||||
|
||||
Cette infrastructure monomachine permet d'acquérir une expérience concrète sur :
|
||||
|
||||
1. **Kubernetes (K3S)** :
|
||||
- Installation et configuration d'un cluster K3S
|
||||
- Gestion des pods, déploiements, services
|
||||
- Configuration des ingress controllers
|
||||
- Gestion du stockage persistant
|
||||
- Utilisation de Helm pour les déploiements
|
||||
|
||||
2. **Infrastructure as Code** :
|
||||
- Déclaration de l'infrastructure avec OpenTofu/Terraform
|
||||
- Versionnement de toute la configuration dans Git
|
||||
- Modules réutilisables et bonnes pratiques IaC
|
||||
|
||||
3. **GitOps et CI/CD** :
|
||||
- Intégration avec Forgejo Actions pour les pipelines
|
||||
- Déploiement automatique sur push Git (GitOps)
|
||||
- Tests automatisés avant déploiement
|
||||
- Rollback automatique en cas d'échec
|
||||
|
||||
4. **Observabilité** :
|
||||
- Stack Prometheus + Grafana pour les métriques
|
||||
- Loki pour la centralisation des logs
|
||||
- Alerting et dashboards personnalisés
|
||||
|
||||
### Validation des concepts
|
||||
|
||||
L'objectif était de valider les concepts suivants avant d'investir dans du matériel :
|
||||
- Valider l'architecture globale
|
||||
- Tester les configurations Kubernetes
|
||||
- Affiner les processus de déploiement
|
||||
- Identifier les services compatibles avec K8S
|
||||
|
||||
**Évolution du projet** : Après réflexion, j'ai décidé d'utiliser des **VMs multiples** pour simuler un vrai cluster et apprendre les aspects distribués dès le début. Cette approche m'a permis d'expérimenter avec la répartition de charge, la tolérance aux pannes et les politiques d'affinité, ce qui n'aurait pas été possible sur un nœud unique.
|
||||
|
||||
## Architecture réseau
|
||||
|
||||
Le schéma illustre l'architecture réseau de cette première version :
|
||||
|
||||
|
||||
|
||||
### Composants de l'architecture
|
||||
|
||||
**Infrastructure physique/virtuelle** :
|
||||
- Serveur unique avec ressources suffisantes (16+ GB RAM, 4+ cœurs CPU)
|
||||
- Stockage local pour les volumes persistants
|
||||
- Réseau local standard (pas de VLAN segmenté)
|
||||
|
||||
**Cluster K3S** :
|
||||
- Node unique (control plane + worker combinés)
|
||||
- Ingress controller (Traefik intégré ou NGINX)
|
||||
- Local Path Provisioner pour le stockage dynamique
|
||||
|
||||
**Services déployés** :
|
||||
- Services applicatifs migrés depuis Docker Compose
|
||||
- Stack d'observabilité (Prometheus, Grafana, Loki)
|
||||
- ArgoCD pour le GitOps
|
||||
- Services de test et développement
|
||||
|
||||
**CI/CD** :
|
||||
- Forgejo avec Actions pour les pipelines
|
||||
- Déploiements automatiques via ArgoCD
|
||||
- Tests de validation automatisés
|
||||
|
||||
## Ce qu'on peut apprendre
|
||||
|
||||
Cette infrastructure monomachine permet d'acquérir des compétences essentielles :
|
||||
|
||||
### Compétences Kubernetes
|
||||
|
||||
- **Déploiements** : Création et gestion de Deployments, StatefulSets, DaemonSets
|
||||
- **Services** : LoadBalancer, ClusterIP, NodePort, ExternalName
|
||||
- **Ingress** : Configuration du routing HTTP/HTTPS
|
||||
- **ConfigMaps et Secrets** : Gestion des configurations et credentials
|
||||
- **Volumes** : PersistentVolumes, PersistentVolumeClaims, StorageClasses
|
||||
- **RBAC** : Gestion des permissions et rôles
|
||||
- **Namespaces** : Isolation logique des applications
|
||||
- **Labels et Selectors** : Organisation et sélection des ressources
|
||||
- **Health checks** : Liveness, Readiness et Startup probes
|
||||
|
||||
### Compétences DevOps
|
||||
|
||||
- **Infrastructure as Code** : Déclaration complète de l'infrastructure
|
||||
- **GitOps** : Synchronisation automatique Git → Cluster
|
||||
- **CI/CD** : Pipelines de test, build et déploiement
|
||||
- **Monitoring** : Métriques, alertes, dashboards
|
||||
- **Logging** : Centralisation et analyse des logs
|
||||
- **Sécurité** : Network Policies, Pod Security Standards
|
||||
- **Helm** : Packaging et déploiement d'applications complexes
|
||||
|
||||
### Compétences en automatisation
|
||||
|
||||
- **Ansible** : Provisioning automatique du serveur et installation K3S
|
||||
- **OpenTofu** : Gestion déclarative de l'infrastructure
|
||||
- **Scripts** : Automatisation des tâches récurrentes
|
||||
- **Backups** : Stratégies de sauvegarde des volumes et états
|
||||
|
||||
## Limitations de cette approche
|
||||
|
||||
### 1. Pas de vraie haute disponibilité (HA)
|
||||
|
||||
**Limitation principale** : Avec une seule machine, il n'y a **pas de redondance** :
|
||||
|
||||
- Si le serveur tombe en panne, tous les services sont indisponibles
|
||||
- Pas de basculement automatique (failover)
|
||||
- Maintenance = downtime obligatoire
|
||||
- Point unique de défaillance (Single Point of Failure - SPOF)
|
||||
|
||||
**Ce qui nécessiterait plusieurs nœuds physiques ou VMs** :
|
||||
- Simulation réaliste de pannes réseau entre nœuds
|
||||
- Performance réseau inter-nœuds en conditions réelles
|
||||
- Consommation électrique et gestion thermique d'un vrai cluster
|
||||
|
||||
### 2. Stockage distribué impossible à tester
|
||||
|
||||
**Limitation critique** : Le stockage distribué (Ceph, Linstor DRBD, Longhorn avec réplication) nécessite **au minimum 3 nœuds** pour garantir la redondance :
|
||||
|
||||
- **Ceph** : Requiert 3 nœuds minimum (idéalement 5+) pour le quorum et la réplication
|
||||
- **Linstor DRBD** : Nécessite plusieurs nœuds pour la réplication synchrone des données
|
||||
- **Longhorn** (réplication) : Ne peut pas répliquer les données sur d'autres nœuds
|
||||
|
||||
**Conséquences** :
|
||||
- Utilisation du Local Path Provisioner uniquement (stockage non répliqué)
|
||||
- Pas d'expérience sur la gestion du stockage distribué
|
||||
- Pas de simulation de panne de disque avec récupération automatique
|
||||
- Performances limitées (pas de parallélisation des I/O)
|
||||
|
||||
**Ce qu'on ne peut pas apprendre** :
|
||||
- Configuration et tuning de Ceph (OSDs, MONs, MGRs)
|
||||
- Gestion des placement groups et crush maps
|
||||
- Réplication et résilience du stockage
|
||||
- Performance du stockage distribué vs local
|
||||
- Stratégies de backup dans un système distribué
|
||||
|
||||
### 3. Scalabilité limitée
|
||||
|
||||
**Pas de scaling horizontal réel** :
|
||||
- Impossible d'ajouter des nœuds workers pour augmenter la capacité
|
||||
- Limitations matérielles de la machine unique (CPU, RAM, réseau)
|
||||
- Pas d'expérience sur l'auto-scaling (Horizontal Pod Autoscaler sur plusieurs nœuds)
|
||||
|
||||
**Ce qu'on ne peut pas apprendre** :
|
||||
- Ajout et retrait dynamique de nœuds
|
||||
- Load balancing entre nœuds
|
||||
- Gestion de la capacité globale du cluster
|
||||
- Politiques de placement des pods selon les ressources disponibles
|
||||
|
||||
### 4. Réseau simplifié
|
||||
|
||||
**Pas de simulation de réseau distribué** :
|
||||
- Tous les pods sont sur la même machine physique
|
||||
- Latence réseau négligeable (pas de simulation réelle)
|
||||
- Pas de complexité liée aux CNI multi-nœuds
|
||||
- Pas de VLAN ou segmentation réseau avancée
|
||||
|
||||
**Ce qu'on ne peut pas apprendre** :
|
||||
- Configuration de CNI avancés (Cilium, Calico avec BGP)
|
||||
- Network policies complexes entre nœuds
|
||||
- Performance réseau inter-nœuds
|
||||
- Gestion des overlays réseau (VXLAN, etc.)
|
||||
|
||||
### 5. Pas de simulation de pannes réalistes
|
||||
|
||||
**Limitations pour le chaos engineering** :
|
||||
- Impossible de simuler une panne de nœud (on n'a qu'un seul nœud)
|
||||
- Pas de test de basculement automatique
|
||||
- Pas de vérification de la reprise après sinistre (DR)
|
||||
|
||||
**Ce qu'on ne peut pas apprendre** :
|
||||
- Procédures de gestion de crise
|
||||
- Temps de récupération réels (RTO/RPO)
|
||||
- Comportement du cluster en situation dégradée
|
||||
|
||||
## Pourquoi commencer par une version monomachine ?
|
||||
|
||||
Malgré les limitations, cette approche présente des **avantages significatifs** :
|
||||
|
||||
### 1. Coût et simplicité
|
||||
|
||||
- **Investissement réduit** : Pas besoin d'acheter 3-5 serveurs immédiatement
|
||||
- **Consommation électrique** : Un seul serveur à alimenter
|
||||
- **Espace physique** : Pas besoin de rack ou d'infrastructure réseau complexe
|
||||
- **Maintenance** : Moins de machines = moins de pannes potentielles
|
||||
|
||||
### 2. Courbe d'apprentissage progressive
|
||||
|
||||
- **Complexité maîtrisée** : Se concentrer sur Kubernetes sans la complexité multi-nœuds
|
||||
- **Debugging simplifié** : Moins de points de défaillance à diagnostiquer
|
||||
- **Erreurs moins coûteuses** : Reconfigurer une machine est plus rapide que 5
|
||||
|
||||
### 3. Validation de l'architecture
|
||||
|
||||
- **Test des services** : Vérifier quels services fonctionnent bien sur K8S
|
||||
- **Optimisation des configurations** : Affiner les ressources (CPU, RAM) par service
|
||||
- **Identification des problèmes** : Détecter les incompatibilités avant de scaler
|
||||
|
||||
### 4. Préparation à l'évolution
|
||||
|
||||
Cette version sert de **fondation** pour le cluster complet :
|
||||
- Code IaC réutilisable (OpenTofu/Ansible)
|
||||
- Manifests Kubernetes testés et validés
|
||||
- Pipelines CI/CD opérationnels
|
||||
- Documentation complète des processus
|
||||
|
||||
## Évolution vers un vrai cluster
|
||||
|
||||
Une fois cette version stabilisée, l'évolution vers un cluster multi-nœuds devient naturelle :
|
||||
|
||||
### Matériel supplémentaire nécessaire
|
||||
|
||||
**Minimum pour un cluster HA fonctionnel** :
|
||||
- 3 nœuds (1 control plane + 2 workers, ou 3 nœuds mixtes)
|
||||
- Switch réseau Gigabit (ou 10GbE pour meilleures performances)
|
||||
- Stockage distribué (Ceph requiert idéalement 5 nœuds)
|
||||
|
||||
**Idéal pour tester toutes les fonctionnalités** :
|
||||
- 5 nœuds (3 control plane + 3 workers avec stockage Ceph)
|
||||
- Switch manageable pour VLAN
|
||||
- Onduleur (UPS) pour éviter les corruptions de données
|
||||
|
||||
### Migration progressive
|
||||
|
||||
**Stratégie de migration** :
|
||||
1. Ajouter un deuxième nœud au cluster existant
|
||||
2. Tester la répartition des pods entre nœuds
|
||||
3. Ajouter un troisième nœud pour activer HA
|
||||
4. Déployer Ceph ou Linstor pour le stockage distribué
|
||||
5. Migrer les workloads critiques avec réplication
|
||||
6. Configurer les Network Policies avancées
|
||||
|
||||
### Réutilisation du code existant
|
||||
|
||||
**Ce qui reste valide** :
|
||||
- Manifests Kubernetes (Deployments, Services, Ingress)
|
||||
- Configurations Helm
|
||||
- Pipelines CI/CD
|
||||
- Scripts d'automatisation Ansible
|
||||
|
||||
**Ce qui doit être adapté** :
|
||||
- StorageClass : migration vers Ceph/Linstor
|
||||
- PodDisruptionBudgets : garantir la disponibilité
|
||||
- Affinité/Anti-affinité : répartir les pods intelligemment
|
||||
- Configuration réseau : CNI multi-nœuds
|
||||
|
||||
## Conclusion et évolution vers le cluster 3 nœuds
|
||||
|
||||
Ce projet initial de homelab "HA" monomachine a été une **réflexion importante** dans l'évolution de mon infrastructure :
|
||||
|
||||
**Points positifs de la réflexion initiale** :
|
||||
- Identification claire des objectifs d'apprentissage Kubernetes
|
||||
- Validation de l'architecture et des configurations cibles
|
||||
- Compréhension des limitations d'une approche monomachine
|
||||
|
||||
**Décision finale** :
|
||||
Après avoir analysé les limitations, notamment l'impossibilité de tester les aspects distribués (haute disponibilité, stockage Ceph, répartition de charge), j'ai décidé d'opter directement pour un **cluster Proxmox 3 nœuds**.
|
||||
|
||||
Cette décision permet :
|
||||
- D'expérimenter avec de vraies VMs multiples simulant un cluster distribué
|
||||
- De tester la haute disponibilité et le stockage distribué (Ceph)
|
||||
- D'apprendre les aspects réseau complexes d'un cluster réel
|
||||
- De construire une base solide pour une infrastructure production-ready
|
||||
|
||||
Pour plus de détails sur l'architecture finale retenue, voir la page [Cluster 3 noeuds Proxmox](./cluster-3-noeuds-proxmox.md).
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Exemple
|
||||
|
||||
Ceci est une page d'exemple dans la catégorie Notions.
|
||||
|
||||
## Description
|
||||
|
||||
Cette page démontre comment structurer du contenu dans une catégorie. Elle peut contenir :
|
||||
|
||||
- Des explications détaillées
|
||||
- Des exemples de code
|
||||
- Des diagrammes
|
||||
- Des références
|
||||
|
||||
## Utilisation
|
||||
|
||||
Vous pouvez dupliquer cette page pour créer de nouveaux articles dans cette catégorie.
|
||||
|
||||
### Configuration
|
||||
|
||||
Pour ajouter une nouvelle page, créez un fichier `.md` dans le dossier `docs/notions/` avec le front matter approprié :
|
||||
|
||||
```yaml
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
```
|
||||
|
||||
### Contenu
|
||||
|
||||
Le contenu peut être écrit en Markdown ou MDX pour inclure des composants React personnalisés.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Notions
|
||||
|
||||
Cette section regroupe des concepts et notions techniques fondamentales utilisées dans mes projets.
|
||||
|
||||
## Objectif
|
||||
|
||||
Documenter et expliquer les concepts clés pour :
|
||||
- Faciliter la compréhension des choix techniques
|
||||
- Servir de référence pour les projets
|
||||
- Partager des connaissances théoriques et pratiques
|
||||
|
||||
## Thématiques abordées
|
||||
|
||||
Les notions couvertes incluent :
|
||||
|
||||
### Infrastructure
|
||||
- Virtualisation et conteneurisation
|
||||
- Réseaux et sécurité
|
||||
- Stockage et sauvegarde
|
||||
|
||||
### Automatisation
|
||||
- Infrastructure as Code (IaC)
|
||||
- Configuration Management
|
||||
- CI/CD et pipelines
|
||||
|
||||
### DevOps
|
||||
- GitOps et versionnement
|
||||
- Observabilité (monitoring, logging, tracing)
|
||||
- Pratiques et méthodologies
|
||||
|
||||
### Orchestration
|
||||
- Kubernetes et conteneurs
|
||||
- Service mesh
|
||||
- Load balancing et scaling
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
|
|
@ -12,6 +12,10 @@
|
|||
"message": "Home",
|
||||
"description": "The homepage title"
|
||||
},
|
||||
"homepage.tagline": {
|
||||
"message": "Research and reflections on technical challenges",
|
||||
"description": "The homepage tagline"
|
||||
},
|
||||
"homepage.description": {
|
||||
"message": "Technical blog to document my research and reflections on technical challenges",
|
||||
"description": "The homepage meta description"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Docker and Docker Compose
|
||||
|
||||
:::info
|
||||
Full English translation coming soon.
|
||||
:::
|
||||
|
||||
Docker is a **containerization platform** that allows packaging applications and their dependencies into lightweight and isolated containers.
|
||||
|
||||
## What is Docker?
|
||||
|
||||
A container is a standardized software unit that contains:
|
||||
- The application itself
|
||||
- All its dependencies (libraries, runtime, system tools)
|
||||
- An isolated filesystem
|
||||
- Environment variables and configuration
|
||||
|
||||
**Difference with virtual machines**:
|
||||
- **Container**: Shares the host OS kernel, starts in seconds, very lightweight (~MB)
|
||||
- **VM**: Emulates a complete OS, starts in minutes, heavier (~GB)
|
||||
|
||||
## Docker Compose: Simplified orchestration
|
||||
|
||||
Docker Compose is an **orchestration tool** for defining and managing multi-container applications.
|
||||
|
||||
### Why Docker Compose?
|
||||
|
||||
- **Declarative configuration**: Everything defined in a `compose.yml` file
|
||||
- **Grouped management**: Start/stop all services with one command
|
||||
- **Automatic networks**: Containers communicate easily between them
|
||||
- **Persistent volumes**: Simple storage management
|
||||
- **Environment variables**: Flexible configuration via `.env` files
|
||||
|
||||
## Configuration examples
|
||||
|
||||
My Docker Compose stacks are available in the Ansible repository under `stacks/`. Key examples include:
|
||||
- **Traefik**: Advanced reverse proxy with two instances (public and private)
|
||||
- **Photoprism**: Application with database (app + DB)
|
||||
- **Mobilizon**: Multi-container application with multiple networks
|
||||
- **Vaultwarden**: Security-focused configuration
|
||||
|
||||
## Patterns and best practices
|
||||
|
||||
1. **External network `traefik_network`**: All services share a common Docker network
|
||||
2. **Traefik labels**: Dynamic configuration via Docker labels
|
||||
3. **Environment variables with .env files**: Secrets extracted from Compose files
|
||||
4. **Dual exposure**: local and production access for each service
|
||||
5. **Restart policies**: `unless-stopped` for resilience
|
||||
6. **Watchtower for monitoring**: Watchtower is used **only for notifications** of available image updates. Updates are performed **manually** to maintain control over changes. In the [Future Homelab](../homelab-futur/index.md), automated update management will be implemented via Renovate Bot integrated directly with Forgejo.
|
||||
|
||||
## Benefits for a homelab
|
||||
|
||||
- **Simplicity**: Readable and maintainable YAML files
|
||||
- **Performance**: Instant service startup, low overhead
|
||||
- **Flexibility**: Easy to add/remove services
|
||||
- **Rich ecosystem**: Docker Hub with thousands of ready-to-use images
|
||||
|
||||
## Why not Docker Swarm?
|
||||
|
||||
When considering the evolution of my infrastructure, **Docker Swarm** was evaluated as an alternative to Kubernetes for container orchestration.
|
||||
|
||||
### Docker Swarm: a tempting but outdated choice
|
||||
|
||||
**Advantages of Docker Swarm**:
|
||||
- Natively integrated with Docker (no additional installation)
|
||||
- Simpler configuration than Kubernetes
|
||||
- Gentler learning curve
|
||||
- Uses Docker Compose files directly (with some adaptations)
|
||||
- Less resource-intensive than Kubernetes
|
||||
|
||||
**Why I didn't choose it**:
|
||||
|
||||
1. **Kubernetes is the industry standard**: The vast majority of companies use Kubernetes in production. Learning K8S provides skills directly transferable to the professional world.
|
||||
|
||||
2. **Ecosystem and community**: Kubernetes benefits from a much richer ecosystem (Helm, operators, numerous DevOps tools) and a much larger community.
|
||||
|
||||
3. **Advanced features**: Kubernetes offers capabilities that Docker Swarm doesn't have:
|
||||
- More advanced rolling updates and rollbacks
|
||||
- Fine-grained resource management (CPU/RAM limits, requests)
|
||||
- More elaborate network policies
|
||||
- Native GitOps support (ArgoCD, Flux)
|
||||
- Better integrated distributed storage (CSI drivers)
|
||||
|
||||
4. **Evolution and support**: Docker Inc. has clearly oriented its development toward Kubernetes rather than Swarm. Swarm is maintained, but no longer evolves much.
|
||||
|
||||
5. **Learning objective**: My goal being to acquire modern DevOps skills, mastering Kubernetes is a better long-term investment.
|
||||
|
||||
**Conclusion**: Although Docker Swarm is simpler and sufficient for many homelabs, I preferred to invest directly in learning Kubernetes, which has become the essential standard for container orchestration.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Current Homelab category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to document a service or configuration of the current homelab.
|
||||
|
||||
## Docker Compose Configuration
|
||||
|
||||
Example service configuration:
|
||||
|
||||
```yaml
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
example-service:
|
||||
image: nginx:latest
|
||||
container_name: example
|
||||
ports:
|
||||
- "8080:80"
|
||||
volumes:
|
||||
- ./config:/etc/nginx/conf.d
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
## Ansible Playbook
|
||||
|
||||
Deployment example with Ansible:
|
||||
|
||||
```yaml
|
||||
---
|
||||
- name: Deploy example service
|
||||
hosts: homelab
|
||||
become: yes
|
||||
|
||||
tasks:
|
||||
- name: Copy docker-compose file
|
||||
copy:
|
||||
src: docker-compose.yml
|
||||
dest: /opt/example/docker-compose.yml
|
||||
|
||||
- name: Start the service
|
||||
command: docker-compose up -d
|
||||
args:
|
||||
chdir: /opt/example
|
||||
```
|
||||
|
||||
## Maintenance
|
||||
|
||||
Important maintenance points:
|
||||
|
||||
- Regular backups
|
||||
- Docker image updates
|
||||
- Log monitoring
|
||||
- Restore testing
|
||||
|
|
@ -15,17 +15,31 @@ My current homelab uses a simple and effective approach:
|
|||
|
||||
## Architecture
|
||||
|
||||
### Infrastructure Diagram
|
||||
|
||||
The diagram illustrates the complete architecture of my current homelab, including:
|
||||
- Network infrastructure with the main server
|
||||
- Deployed Docker services
|
||||
- Traefik configuration for the reverse proxy (public and private instances)
|
||||
- Connections between different components
|
||||
- Local DNS configuration with dnsmasq
|
||||
|
||||
|
||||
|
||||
### Physical/Virtual Infrastructure
|
||||
- Dedicated servers or VMs
|
||||
- Secure local network
|
||||
- Storage and backups
|
||||
- Ubuntu Server dedicated server
|
||||
- Secure local network with local DNS (dnsmasq)
|
||||
- Unified storage with MergerFS
|
||||
- Firewall with firewalld
|
||||
|
||||
### Tech Stack
|
||||
- **OS**: Linux (Debian/Ubuntu)
|
||||
- **OS**: Linux (Ubuntu Server)
|
||||
- **Containerization**: Docker & Docker Compose
|
||||
- **Automation**: Ansible playbooks
|
||||
- **Reverse proxy**: Traefik or Nginx
|
||||
- **Monitoring**: Prometheus, Grafana
|
||||
- **Reverse proxy**: Traefik v3 (public and private instances)
|
||||
- **Security**: CrowdSec, TLS with Let's Encrypt
|
||||
- **Monitoring**: Beszel, Uptime Kuma
|
||||
- **Local DNS**: dnsmasq for resolving *.local.tellserv.fr
|
||||
|
||||
## Deployed Services
|
||||
|
||||
|
|
@ -41,18 +55,39 @@ The documentation details:
|
|||
- Simple to set up and maintain
|
||||
- Ansible enables complete automation
|
||||
- Docker Compose facilitates service management
|
||||
- Reproducible and versioned with Git
|
||||
- Ideal for progressive automation learning
|
||||
|
||||
## Limitations
|
||||
|
||||
- Limited scalability
|
||||
- No native high availability
|
||||
- Manual orchestration for certain tasks
|
||||
This infrastructure has several important limitations that motivate the evolution toward a new approach (see "Future Homelab" section).
|
||||
|
||||
These limitations motivate the evolution towards Kubernetes (see "Future Homelab" section).
|
||||
### Initial Absence of Git Versioning
|
||||
|
||||
## Articles
|
||||
One of the main limitations of this initial approach was the **absence of infrastructure versioning with Git**. At this stage of my journey, I had not yet mastered the DevOps philosophy and infrastructure code management best practices.
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
**Consequences of this limitation:**
|
||||
- No history of configuration changes
|
||||
- Difficult to roll back in case of problems
|
||||
- No traceability of modifications
|
||||
- Complex collaboration
|
||||
- Absence of code review process
|
||||
- Risk of divergence between documentation and reality
|
||||
|
||||
<DocCardList />
|
||||
This gap was an **important lesson** that led me to:
|
||||
1. Progressively correct this infrastructure by versioning Ansible playbooks and Docker Compose files
|
||||
2. Adopt Git and DevOps practices for all my future projects
|
||||
3. Integrate the "Infrastructure as Code" philosophy from the design phase
|
||||
|
||||
**Important note**: The Git repository [Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose) was created **after the fact** to present the work done. In the initial practice, Git, automated tests, and CI/CD were not used due to lack of knowledge at the time.
|
||||
|
||||
Git versioning is now in place for this infrastructure, but the architecture itself remains limited (see below).
|
||||
|
||||
### Technical Architecture Limitations
|
||||
|
||||
- **Limited scalability**: Single-machine infrastructure without load distribution capability
|
||||
- **No high availability**: Single point of failure (SPOF)
|
||||
- **Manual orchestration**: Some tasks still require manual intervention
|
||||
- **Initially absent CI/CD**: Manual deployments via Ansible (no automation on Git push)
|
||||
- **Limited testing**: No automatic validation of changes before deployment
|
||||
|
||||
These limitations motivate the evolution toward Kubernetes (K3S) and a complete Infrastructure as Code approach with CI/CD (see [Future Homelab](../homelab-futur/index.md) section).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Ansible Playbooks
|
||||
|
||||
:::info
|
||||
Full English translation coming soon.
|
||||
:::
|
||||
|
||||
Ansible is an open-source IT automation tool that enables configuration management, deployment, and infrastructure orchestration. In a homelab context, Ansible has become essential for maintaining reproducible and documented infrastructure.
|
||||
|
||||
## What is Ansible?
|
||||
|
||||
Ansible is an **Infrastructure as Code (IaC)** tool that allows you to:
|
||||
- **Automate** repetitive system administration tasks
|
||||
- **Standardize** configurations across multiple machines
|
||||
- **Document** infrastructure in executable format (code is documentation)
|
||||
- **Reproduce** identical environments easily
|
||||
- **Version** infrastructure with Git
|
||||
|
||||
## Project structure
|
||||
|
||||
My Ansible infrastructure is available:
|
||||
- **Online repository**: [https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose)
|
||||
|
||||
## Ansible roles
|
||||
|
||||
The infrastructure uses several roles:
|
||||
- **common**: Base system configuration, dnsmasq, firewalld, MergerFS
|
||||
- **cockpit**: Web admin interface
|
||||
- **docker**: Docker Engine installation and configuration
|
||||
- **services**: Docker stack deployment
|
||||
|
||||
## Secrets management
|
||||
|
||||
Secrets are encrypted with Ansible Vault and injected via Jinja2 templates into `.env` files.
|
||||
|
||||
## Benefits of this approach
|
||||
|
||||
1. **Reproducibility**: Infrastructure can be recreated identically in minutes
|
||||
2. **Living documentation**: Ansible code documents the infrastructure precisely
|
||||
3. **Complete automation**: No need to SSH for deployment or updates
|
||||
4. **Security**: Secrets are encrypted and never committed in plain text
|
||||
|
||||
## Current Limitations
|
||||
|
||||
Despite its many advantages, this approach has limitations:
|
||||
|
||||
1. **Late versioning**: The Git repository [Infra_ansible_dockercompose](https://forgejo.tellserv.fr/Tellsanguis/Infra_ansible_dockercompose) was created **after the fact** to present the work. In the initial practice, Git, automated tests, and CI/CD were not used due to lack of knowledge at the time.
|
||||
2. **No automated tests**: No automatic playbook validation (Molecule, integration tests)
|
||||
3. **Single-machine infrastructure**: Ansible is designed to manage multiple servers, but I only manage one
|
||||
4. **No CI/CD integration**: Deployments are manual, no automated pipeline
|
||||
|
||||
These limitations will be addressed in the [Future Homelab](../homelab-futur/index.md) with the adoption of Kubernetes and GitOps.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Traefik - Modern Reverse Proxy
|
||||
|
||||
:::info
|
||||
This page will be completed soon with detailed Traefik configuration.
|
||||
:::
|
||||
|
||||
## Coming soon
|
||||
|
||||
- Detailed configuration of two Traefik instances (public and private)
|
||||
- SSL certificate management with Let's Encrypt
|
||||
- CrowdSec integration for security
|
||||
- Middleware configuration
|
||||
- Routing and domain management
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# 3-Node Proxmox Cluster: A True HA Homelab
|
||||
|
||||
Documentation coming soon...
|
||||
|
||||
## Target Architecture
|
||||
|
||||
This page will be completed with details of the final 3-node Proxmox cluster architecture.
|
||||
|
|
@ -1,153 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Future Homelab category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to document Kubernetes configurations and deployments for the future homelab.
|
||||
|
||||
## Kubernetes Deployment
|
||||
|
||||
Example deployment manifest:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: production
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: example
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: example
|
||||
spec:
|
||||
containers:
|
||||
- name: app
|
||||
image: nginx:latest
|
||||
ports:
|
||||
- containerPort: 80
|
||||
resources:
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 128Mi
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example-service
|
||||
namespace: production
|
||||
spec:
|
||||
selector:
|
||||
app: example
|
||||
ports:
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
type: ClusterIP
|
||||
```
|
||||
|
||||
## OpenTofu Configuration
|
||||
|
||||
Example infrastructure resource:
|
||||
|
||||
```hcl
|
||||
resource "kubernetes_namespace" "production" {
|
||||
metadata {
|
||||
name = "production"
|
||||
labels = {
|
||||
environment = "production"
|
||||
managed-by = "opentofu"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
resource "kubernetes_deployment" "example" {
|
||||
metadata {
|
||||
name = "example-app"
|
||||
namespace = kubernetes_namespace.production.metadata[0].name
|
||||
}
|
||||
|
||||
spec {
|
||||
replicas = 3
|
||||
|
||||
selector {
|
||||
match_labels = {
|
||||
app = "example"
|
||||
}
|
||||
}
|
||||
|
||||
template {
|
||||
metadata {
|
||||
labels = {
|
||||
app = "example"
|
||||
}
|
||||
}
|
||||
|
||||
spec {
|
||||
container {
|
||||
image = "nginx:latest"
|
||||
name = "app"
|
||||
|
||||
resources {
|
||||
limits = {
|
||||
cpu = "100m"
|
||||
memory = "128Mi"
|
||||
}
|
||||
requests = {
|
||||
cpu = "50m"
|
||||
memory = "64Mi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## GitOps with ArgoCD
|
||||
|
||||
ArgoCD Application configuration:
|
||||
|
||||
```yaml
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: argocd
|
||||
spec:
|
||||
project: default
|
||||
source:
|
||||
repoURL: https://forgejo.tellserv.fr/Tellsanguis/k8s-manifests.git
|
||||
targetRevision: HEAD
|
||||
path: apps/example
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: production
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
```
|
||||
|
||||
## Observability
|
||||
|
||||
Monitoring points for this service:
|
||||
|
||||
- Prometheus metrics exposed on `/metrics`
|
||||
- Logs aggregated in Loki
|
||||
- Distributed traces with Tempo
|
||||
- Alerts configured in Prometheus AlertManager
|
||||
|
|
@ -70,9 +70,3 @@ This migration represents:
|
|||
- **Practical learning**: Experimentation in real conditions
|
||||
- **Technical evolution**: Moving to modern and scalable solutions
|
||||
- **Portfolio**: Demonstration of advanced DevOps skills
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
|
|
|
|||
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# First Version: Single-Machine "HA" Homelab (Initial Project)
|
||||
|
||||
:::info
|
||||
Full English translation coming soon.
|
||||
:::
|
||||
|
||||
## Introduction
|
||||
|
||||
**Important note**: This page describes the **initial project** I had planned to experiment with Kubernetes. This project **evolved** into a different final decision: a 3-node Proxmox cluster (see [3-Node Proxmox Cluster](./cluster-3-noeuds-proxmox.md)).
|
||||
|
||||
The initial idea was to create a **transitional step** toward a complete distributed infrastructure, experimenting with Kubernetes (K3S), Infrastructure as Code (OpenTofu/Terraform), Git, and CI/CD pipelines, while remaining on a single physical machine.
|
||||
|
||||
## Objectives
|
||||
|
||||
### Practical Learning
|
||||
|
||||
This single-machine infrastructure allows acquiring hands-on experience with:
|
||||
- **Kubernetes (K3S)**: Installation, configuration, and management
|
||||
- **Infrastructure as Code**: OpenTofu/Terraform for declarative infrastructure
|
||||
- **GitOps and CI/CD**: Automated deployments with Forgejo Actions
|
||||
- **Observability**: Prometheus, Grafana, Loki stack
|
||||
|
||||
## Network Architecture
|
||||
|
||||
|
||||
|
||||
## What Can Be Learned
|
||||
|
||||
This single-machine infrastructure allows acquiring essential skills:
|
||||
- Kubernetes deployments and management
|
||||
- DevOps practices (IaC, GitOps, CI/CD)
|
||||
- Monitoring and logging
|
||||
- Automation with Ansible and OpenTofu
|
||||
|
||||
## Limitations of This Approach
|
||||
|
||||
### 1. No Real High Availability (HA)
|
||||
|
||||
**Main limitation**: With a single machine, there is **no redundancy**:
|
||||
- Single point of failure (SPOF)
|
||||
- Maintenance requires downtime
|
||||
- No automatic failover
|
||||
|
||||
### 2. Distributed Storage Impossible to Test
|
||||
|
||||
**Critical limitation**: Distributed storage (Ceph, Linstor DRBD, Longhorn with replication) requires **at least 3 nodes**:
|
||||
- **Ceph**: Requires 3 nodes minimum (ideally 5+) for quorum and replication
|
||||
- **Linstor DRBD**: Needs multiple nodes for synchronous data replication
|
||||
- **Longhorn** (replication): Cannot replicate data to other nodes
|
||||
|
||||
### 3. Limited Scalability
|
||||
|
||||
- Cannot add worker nodes to increase capacity
|
||||
- Hardware limitations of single machine
|
||||
- No experience with horizontal auto-scaling
|
||||
|
||||
### 4. Simplified Network
|
||||
|
||||
- All pods on the same physical machine
|
||||
- Negligible network latency
|
||||
- No multi-node CNI complexity
|
||||
|
||||
### 5. No Realistic Failure Simulation
|
||||
|
||||
- Cannot simulate node failure
|
||||
- No automatic failover testing
|
||||
- No disaster recovery validation
|
||||
|
||||
## Why Start with Single Machine?
|
||||
|
||||
Despite limitations, this approach has **significant advantages**:
|
||||
|
||||
### 1. Cost and Simplicity
|
||||
|
||||
- Reduced investment (no need to buy 3-5 servers immediately)
|
||||
- Lower power consumption
|
||||
- Simplified maintenance
|
||||
|
||||
### 2. Progressive Learning Curve
|
||||
|
||||
- Manageable complexity
|
||||
- Simplified debugging
|
||||
- Less costly mistakes
|
||||
|
||||
### 3. Architecture Validation
|
||||
|
||||
- Test which services work well on K8S
|
||||
- Optimize resource configurations
|
||||
- Identify incompatibilities before scaling
|
||||
|
||||
### 4. Preparation for Evolution
|
||||
|
||||
This version serves as a **foundation** for the complete cluster:
|
||||
- Reusable IaC code
|
||||
- Tested and validated Kubernetes manifests
|
||||
- Operational CI/CD pipelines
|
||||
|
||||
## Evolution Toward Real Cluster
|
||||
|
||||
Once stabilized, evolution toward multi-node cluster becomes natural:
|
||||
|
||||
**Minimum for functional HA cluster**:
|
||||
- 3 nodes (1 control plane + 2 workers, or 3 mixed nodes)
|
||||
- Gigabit network switch
|
||||
- Distributed storage (Ceph ideally requires 5 nodes)
|
||||
|
||||
**Migration strategy**:
|
||||
1. Add second node to existing cluster
|
||||
2. Test pod distribution between nodes
|
||||
3. Add third node to enable HA
|
||||
4. Deploy Ceph or Linstor for distributed storage
|
||||
5. Migrate critical workloads with replication
|
||||
|
||||
## Conclusion
|
||||
|
||||
This single-machine "HA" version is an **essential pedagogical step** before deploying a real Kubernetes cluster:
|
||||
|
||||
**Positive points**:
|
||||
- Learn Kubernetes without multi-node complexity
|
||||
- Validate architecture and configurations
|
||||
- Reduced cost and simplified maintenance
|
||||
- Solid foundation to evolve toward complete cluster
|
||||
|
||||
**Assumed limitations**:
|
||||
- No real high availability
|
||||
- Distributed storage impossible to test (Ceph, Linstor)
|
||||
- Limited scalability
|
||||
- No realistic failure simulation
|
||||
|
||||
This approach allows **methodical progression** toward a complete cloud-native infrastructure while mastering each step of the process.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Concepts category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to structure content in a category. It can contain:
|
||||
|
||||
- Detailed explanations
|
||||
- Code examples
|
||||
- Diagrams
|
||||
- References
|
||||
|
||||
## Usage
|
||||
|
||||
You can duplicate this page to create new articles in this category.
|
||||
|
||||
### Configuration
|
||||
|
||||
To add a new page, create a `.md` file in the `docs/notions/` folder with the appropriate front matter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
```
|
||||
|
||||
### Content
|
||||
|
||||
Content can be written in Markdown or MDX to include custom React components.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
This section groups fundamental technical concepts and notions used in my projects.
|
||||
|
||||
## Objective
|
||||
|
||||
Document and explain key concepts to:
|
||||
- Facilitate understanding of technical choices
|
||||
- Serve as reference for projects
|
||||
- Share theoretical and practical knowledge
|
||||
|
||||
## Topics Covered
|
||||
|
||||
Covered concepts include:
|
||||
|
||||
### Infrastructure
|
||||
- Virtualization and containerization
|
||||
- Networking and security
|
||||
- Storage and backup
|
||||
|
||||
### Automation
|
||||
- Infrastructure as Code (IaC)
|
||||
- Configuration Management
|
||||
- CI/CD and pipelines
|
||||
|
||||
### DevOps
|
||||
- GitOps and versioning
|
||||
- Observability (monitoring, logging, tracing)
|
||||
- Practices and methodologies
|
||||
|
||||
### Orchestration
|
||||
- Kubernetes and containers
|
||||
- Service mesh
|
||||
- Load balancing and scaling
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
18
sidebars.ts
18
sidebars.ts
|
|
@ -25,17 +25,6 @@ const sidebars: SidebarsConfig = {
|
|||
'projets-openclassrooms/p13-migration-cloud-aws',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Notions',
|
||||
link: {
|
||||
type: 'doc',
|
||||
id: 'notions/index',
|
||||
},
|
||||
items: [
|
||||
'notions/exemple',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Homelab actuel - Docker Compose & Ansible',
|
||||
|
|
@ -44,7 +33,9 @@ const sidebars: SidebarsConfig = {
|
|||
id: 'homelab-actuel/index',
|
||||
},
|
||||
items: [
|
||||
'homelab-actuel/exemple',
|
||||
'homelab-actuel/playbooks-ansible',
|
||||
'homelab-actuel/docker-compose',
|
||||
'homelab-actuel/traefik',
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
@ -55,7 +46,8 @@ const sidebars: SidebarsConfig = {
|
|||
id: 'homelab-futur/index',
|
||||
},
|
||||
items: [
|
||||
'homelab-futur/exemple',
|
||||
'homelab-futur/premiere-version-ha-monomachine',
|
||||
'homelab-futur/cluster-3-noeuds-proxmox',
|
||||
],
|
||||
},
|
||||
],
|
||||
|
|
|
|||
|
|
@ -16,7 +16,13 @@ function HomepageHeader() {
|
|||
<Heading as="h1" className="hero__title">
|
||||
{siteConfig.title}
|
||||
</Heading>
|
||||
<p className="hero__subtitle">{siteConfig.tagline}</p>
|
||||
<p className="hero__subtitle">
|
||||
<Translate
|
||||
id="homepage.tagline"
|
||||
description="The homepage tagline">
|
||||
Recherches et réflexions sur les défis techniques
|
||||
</Translate>
|
||||
</p>
|
||||
<div className={styles.buttons}>
|
||||
<Link
|
||||
className="button button--secondary button--lg"
|
||||
|
|
|
|||
BIN
static/img/diagrams/homelab-actuel-infra.png
Normal file
BIN
static/img/diagrams/homelab-actuel-infra.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.7 MiB |
BIN
static/img/diagrams/homelab-futur-network.png
Normal file
BIN
static/img/diagrams/homelab-futur-network.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Loading…
Add table
Add a link
Reference in a new issue