Conteneur on slash-root.fr

Docker : Configuration des réseaux par défaut

Sun, 15 Jun 2025 16:17:21 +0200

Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans le fascinant (et parfois frustrant) monde des réseaux Docker. Comme on dit dans notre jargon : "Un conteneur sans réseau, c'est comme un pingouin sans banquise - techniquement possible, mais pas vraiment utile."

Les réseaux Docker par défaut

Docker, cet invité un peu sans-gêne, s'installe et crée directement trois réseaux :

bridge : Le réseau par défaut où tous vos conteneurs font la fête (172.17.0.0/16)
host : Pour quand vos conteneurs veulent se sentir comme à la maison
none : Pour les conteneurs asociaux qui préfèrent rester dans leur coin

Le réseau bridge s'approprie allègrement la plage 172.17.0.0/16. Mais que se passe-t-il quand cette plage est déjà occupée par votre infrastructure existante ? Eh bien, c'est un peu comme deux familles qui réservent le même bungalow pour les vacances - ça crée des tensions.

Résolution des conflits avec le réseau par défaut

Pour modifier la plage d'adresses que Docker utilise par défaut, éditez le fichier /etc/docker/daemon.json (si le fichier n'existe pas, créez-le avec la même joie que lorsque vous créez un nouveau répertoire batman) :

{
 "default-address-pools": [
 {
 "base": "192.168.66.0/24",
 "size": 24
 }
 ]
}

Après cette modification, un petit redémarrage s'impose :

sudo systemctl restart docker

Incrémentation automatique des réseaux Docker

Quand vous créez de nouveaux réseaux Docker avec docker network create, Docker fait preuve d'une logique implacable pour l'allocation des sous-réseaux. En fonction de votre configuration default-address-pools, Docker va attribuer automatiquement des plages d'adresses IP qui s'incrémentent à chaque nouveau réseau :

docker network create mon-super-reseau

Pour cette commande, Docker utilisera automatiquement la première plage disponible: 192.168.66.0/24

docker network create mon-autre-reseau

Pour ce deuxième réseau, Docker passera à la plage suivante: 192.168.67.0/24

C'est comme distribuer des tranches de gâteau - mais en version IP.

Si vous préférez choisir votre part vous-même :

docker network create --subnet=192.168.42.0/24 mon-reseau-avec-le-nombre-de-la-vie

Les différents types de réseaux Docker

Dans un Docker Engine standalone

Un Docker Engine standard (non-Swarm) propose plusieurs types de réseaux pour répondre à des besoins distincts :

bridge : Le réseau par défaut utilisé par les conteneurs. C'est un réseau virtuel interne qui permet aux conteneurs de communiquer entre eux et avec l'hôte.
host : Supprime l'isolation réseau entre le conteneur et l'hôte. Le conteneur utilise directement la pile réseau de l'hôte. Utile pour les performances mais réduit l'isolation.
none : Désactive complètement le réseau. Le conteneur n'a aucun accès réseau externe. Utile pour les traitements isolés ne nécessitant pas de communication.
macvlan : Attribue une adresse MAC physique aux conteneurs, les faisant apparaître comme des périphériques physiques sur le réseau. Idéal pour migrer des applications legacy qui dépendent d'IPs spécifiques.

# Créer un réseau bridge personnalisé (recommandé au lieu du bridge par défaut)
docker network create --driver bridge mon-reseau-bridge

Dans un cluster Docker Swarm

Docker Swarm, c'est comme une colocation de conteneurs répartis sur plusieurs serveurs. La communication entre nœuds nécessite des réseaux spéciaux :

overlay : Permet aux conteneurs de différents nœuds de communiquer comme s'ils étaient sur le même hôte. Crée un réseau virtual "au-dessus" de l'infrastructure physique.
ingress : Un réseau overlay spécial qui facilite le routage du trafic entrant vers les services appropriés, indépendamment du nœud qui héberge le conteneur. Gère également l'équilibrage de charge interne.

# Créer un réseau overlay pour les services Swarm
docker network create --driver overlay --attachable mon-reseau-multi-hote

Tous ces réseaux peuvent coexister sur le même hote ou cluster, permettant ainsi une architecture réseau flexible et adaptée à chaque cas d'usage.

Le réseau Ingress et la plage 10.0.0.0/8

Par défaut, ce cher réseau ingress s'installe confortablement dans la plage 10.0.0.0/8. Si vous utilisez déjà cette plage, les symptômes sont clairs :

Docker vous lance des erreurs cryptiques avec "network overlap"
Vos conteneurs deviennent subitement muets
Vous commencez à douter de vos choix de carrière

Reconfiguration du réseau Ingress

Contrairement à ce qu'on pourrait croire, pas besoin de quitter le swarm pour résoudre ce problème ! Une approche beaucoup plus civilisée consiste à :

Supprimer poliment le réseau ingress existant :

docker network rm ingress

Créer un nouveau réseau ingress avec votre propre plage :

docker network create \
 --driver overlay \
 --ingress \
 --subnet=172.30.0.0/16 \
 --gateway=172.30.0.1 \
 ingress

Voilà qui est beaucoup moins traumatisant pour votre swarm que de tout démolir et reconstruire !

Bonnes pratiques pour la gestion des réseaux Docker

Planifiez votre allocation d'adresses IP : Un schéma bien pensé vaut mieux qu'une nuit blanche de débogage
Choisissez le bon type de réseau : Ne vous limitez pas au bridge par défaut.
- Bridge personnalisé (docker network create my_bridge) : Résolution DNS entre conteneurs, isolation, idéal pour les applications sur un seul hôte
- Overlay (docker network create -d overlay my_overlay) : Communication entre hôtes dans Swarm
- Macvlan (docker network create -d macvlan --subnet=192.168.40.0/24 --gateway=192.168.40.1 -o parent=eth0 my_macvlan) : Intégration au réseau physique
Sécurisez votre infrastructure : Évitez d'exposer les ports de base de données (comme MySQL, PostgreSQL, MongoDB) sur votre réseau hôte. C'est une faille de sécurité courante et totalement évitable. Dans les réseaux Docker Compose ou Swarm, la communication inter-services se fait nativement via le nom du service. En pratique, votre service d'application peut simplement utiliser db:3306 comme adresse de connexion, sans jamais avoir à publier le port 3306 sur l'interface de l'hôte. Dans Swarm, cette communication fonctionne même entre des conteneurs déployés sur différents nœuds physiques via les réseaux overlay
Adoptez une nomenclature claire : Préférez project_frontend_net ou prod_db_network à des noms génériques comme net1
Documentez votre architecture réseau : Votre futur vous (ou votre remplaçant après votre burnout) vous remerciera

Conclusion

La gestion des réseaux Docker ressemble parfois à un jeu de Tetris avec des blocs CIDR - challenging mais satisfaisant une fois maîtrisé. En comprenant comment Docker assigne et gère les adresses IP, vous pourrez éviter ces moments où, tard dans la nuit, vous fixez votre écran en murmurant "mais pourquoi ça ne communique pas ?".

Une bonne configuration réseau vous permettra de dormir tranquille, sachant que vos conteneurs peuvent socialiser entre eux sans créer d'incident diplomatique sur votre infrastructure.

Et souvenez-vous : dans un monde de conteneurs éphémères, seule une bonne configuration réseau est éternelle (ou du moins, jusqu'au prochain docker-compose down).

Déployer une application sur Kubernetes

Thu, 06 Feb 2025 08:30:54 +0100

Introduction

Aujourd'hui, je vous embarque à bord de mon voyage, ce voyage consiste à progressivement remplacer mes conteneurs Docker par des services Kubernetes dans mon homelab.

Pourquoi ce changement ?
Car étant encore étudiant et en plein dans le sujet, quoi de mieux que de mettre les mains dans le camboui ?

Préparation

La cible

Parmi la liste des applications que je dois migrer, j'ai dû en choisir une, et Mealie a été l'heureuse gagnante.
C'est quoi Mealie ? Mealie est un gestionnaire de recettes de cuisine accessible via navigateur, entièrement self hosté.

L’existant

---
services: 
 mealie:
 image: ghcr.io/mealie-recipes/mealie:latest 
 container_name: mealie-front-01
 restart: always
 networks:
 - mealie-network
 - reverse-proxy
 labels:
 - traefik.enable=true
 - traefik.http.middlewares.sslheader.headers.customrequestheaders.X-Forwarded-Proto=https
 - traefik.http.routers.mealie-https.entrypoints=https
 - traefik.http.routers.mealie-https.rule=Host(`mealie.homelab.domain.fr`)

 volumes:
 - mealie-vol:/app/data/
 env_file:
 - /opt/docker/apps/mealie/stack.env

networks:
 reverse-proxy:
 external: true
 mealie-network: {}

volumes:
 mealie-vol: {}

Ci-haut, vous pouvez voir le yaml docker-compose ayant servi à créer mon conteneur Mealie.

Nous pouvons y observer:

Une image en tag latest (on ne juge pas !).
2 Réseaux alloués
- mealie-network étant le réseau propre de cette stack.
- reverse-proxy permettant de relier le conteneur au conteneur Reverse Proxy traefik, permettant d'exposer Mealie et de lui attribuer un Certificat Let's Encrypt.
Des labels:
- Des middlewares classiques pour sécuriser l'accès au service Mealie.
- Deux routeurs, un https pour forcer le port d'entrée sur le 443 et un routeur pour attribuer un hostname au conteneur.
Un volume Docker monté sur le chemin /app/data du conteneur
Un fichier d'environnement contenant toutes les clés-valeurs requises pour que Mealie fonctionne.
Le port d'exposition du Conteneur dans le pod (ici, 9000)

La migration

Maintenant que nous avons décortiqué les éléments présents, il va falloir les traduire en manifests Kubernetes.
Les manifests Kubernetes sont des fichiers yaml déclaratif qui vont dire à Kubernetes comment on veut que notre application soit déployée.

Il est important de noter que mes volumes sont provisonnés sur mon TrueNAS Scale grâce à une StorageClass via le protocole NFS, contrairement à Docker, où les volumes étaient stockés en local.
Mealie étant une application tournant sur du LiteSQL, le site de l'application ne recommande pas de faire du LiteSQL avec du NFS, j'ai donc dû opter pour une PostgreSQL dédiée.

(Petite information, il existe un binaire nommé kompose qui permet de faire une traduction d'un fichier docker-compose en manifests yaml, mais ça s'appelle enlever le fun de la découverte.)

Reprenons notre liste à puce de la partie précédente.
Il nous faut:

Il nous faut un objet de type Deployment, il va servir à déployer les Pods avec des configuration que j'aurais définie.
Ce manifest yaml contiendra:
- L'image Docker de Mealie (On enlève le tag latest, c'est risqué de pointer sur un tag d'image en mouvement perpétuel).
- Le nombre de Replicas du pod (Un replica est une copie d'un pod, si l'un tombe l'autre prend la relève, sert aussi de loadbalancing en cas de workload important).
- Un appel à des clés-valeurs d'une Configmap, qui est un objet contenant ici mes variables d'environnement.
- Un appel a des clés-valeurs d'un Secret, qui est un objet qui contient ici les mots de passe de la base de donnée PostgreSQL.
- Un appel à un PersistentVolumeClaim, qui lui même est lié à un PersistentVolume qui sera monté sur app/data nous reviendrons plus tard dessus, mais retenez que c'est le volume.
Un objet de type StatefulSet pour déployer la base de donnée.
Le StatefulSet fonctionne presque exactement comme un Deployment, mais il est fait pour les services type stateful, les pods sont identifiés et non-interchangeable.
Ensuite, on va avoir besoin de créer les objets Configmap et Secret.
Ces objets permettent de stocker sous forme de clé-valeur des informations, que ce soit des variables d'environnement, des arguments de commande, etc.., ils peuvent ensuite être consommés par des pods.
La différence entre un Secret et une Configmap réside dans le fait que les Secrets sont encodés en base64, et sont fait pour contenir des données sensibles.
Exemple d'une configmap:
```
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mealie-configmap
 namespace: mealie
data:
 ALLOW_SIGNUP: "false"
 TZ: "Europe/Paris"
 DB_ENGINE: "postgres"
 POSTGRES_USER: admin
```
Pour que les pods puissent communiquer entre eux ET que le pod du front web soit disponible dehors, il nous faut des objets de type Services.
Les Services permettent d'exposer un ou plusieurs pods, car les pods de nature sont amenés à être détruits et recréés, et leur IP changent également.
La logique d'un service fonctionne donc comme ça:
Les Pods ont des labels sous forme de clé valeur --> Les Services qui ont une IP statique visent ces labels, et sont donc attribués à ces pods, le service peut même faire du LoadBalancing entre les pods qu'il expose.
Un service au minimum demande:
- Le protocole du port qu'on va exposer (TCP ou UDP).
- Le port que le Service expose (donc son propre port).
- Le port du conteneur que le Service va viser.

Pour nos besoins, il faudra créer un service pour exposer la base de donnée et un service pour exposer le front.

Pour les volumes, il faut faire une introduction aux PersistentVolumes (PV) et aux PersistentVolumeClaims (PVC).
Un PV est un volume de stockage défini provisionné manuellement ou dynamiquement (via une StorageClass).
Le PVC quant à lui est une requête pour consommer un PV.
Dans mon cas à moi, j'utilise une StorageClass qui est issue du CSI (Container Storage Interface) DemocraticCSI, ça me permet de créer un CSIDriver spécifiquement fait pour interagir avec l'API de TrueNAS, afin de provisionner des PV stockés sur un Dataset ZFS via le protocole NFS.
Il nous faut donc 2 volumes:

Le premier sera monté sur le app/data du front de Mealie, il stockera les Metadata du front, et fera 1Gi.
Le deuxième sera le volume de la base de donnée PostgreSQL, ce dernier ne sera pas défini dans son propre manifest yaml mais directement dans le manifest du StatefulSet.

Nous en avons terminé avec les objets qui constituent l'application en elle-même, pour finir il nous faut un objet de type Ingress.
Un Ingress c'est un objet créé par un IngressController, vous connaissez surement quelques noms connus d'IngressController: Nginx, Traefik, HAProxy, par exemple, pour ma part, j'utilise Traefik car je m'en servais déjà sur Docker.
Un Ingress est un Reverse Proxy et LoadBalancer de couche 7, il agit comme un point d'entrée pour des routes HTTP et HTTPS et redirige les requêtes selon les règles qu'il contient, par exemple, il peut rediriger une requête vers un objet de type service précis, lui même redirigeant à un pod , dépendant de l'URL (machin.fr/app qui redirige au service app).
Il peut également gérer plusieurs noms de domaine, utiliser des headers de sécurité et implémenter un certificat SSL/TLS.
Normalement, il faudrait créer un objet de type certificat contenu dans un Secret Kubernetes et appeler ce secret dans le manifest de l'Ingress, mais comme j'utilise Cert-Manager qui est relié à mon domaine dans Cloudflare, je n'ai qu'à rajouter une annotation dans l'objet pour faire une requête de Certificat Let's Encrypt.
Je ne rentrerais pas en détail dans le sujet de Cert-Manager, cependant, voici la documentation officielle du projet.

Construction

.
└── base
 ├── kustomization.yaml
 ├── mealie-configmap.yaml
 ├── mealie-db-service.yaml
 ├── mealie-deployment.yaml
 ├── mealie-pvc.yaml
 ├── mealie-secret.yaml
 ├── mealie-statefulset.yaml
 ├── mealie-ingressroute.yaml
 └── mealie-web-service.yaml

Bon, appliquer tous ces fichiers yaml à la main, ça serait VRAIMENT pénible.
Comment faire pour tout faire d'un coup ?
Avec la commande CLI builtin et les manifests Kustomize.

Voici un exemple d'un manifest kustomize:

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
 - mealie-deployment.yaml
 - mealie-statefulset.yaml
 - mealie-secret.yaml
 - mealie-web-service.yaml
 - mealie-db-service.yaml
 - mealie-ingressroute.yaml
 - mealie-configmap.yaml
 - mealie-pvc.yaml

Pour appliquer ce fichier il faut lancer la commande kubectl apply -k ./base, le -k spécifie qu'on vise un manifest kustomize.
Kustomize va donc appeler chaque manifest yaml de la liste définie dans resources et les appliquer un à un dans Kubernetes.
On peut faire des choses très utiles avec Kustomize, mais ce n'est pas le but de l'article. Néamoins, Voici un article en parlant.

Conclusion

Et voilà ! À table !

Au final si jamais vous vous posez la question, est-ce que vous devez utiliser Kubernetes ou Docker dans votre homelab, sachez une chose.

Utiliser Docker est vraiment vraiment plus simple dans un petit environnement, quel intérêt d'utiliser Kubernetes ?
Apprendre et évoluer ! Bien sûr c'est suffisant d'utiliser Docker, mais Kubernetes apporte son lot d'avantage, de satisfaction, (de soirée perdues).

Watch Tower : Auto update docker images

Tue, 11 Apr 2023 08:04:46 +0200

Présentation

Watch Tower permet de mettre à jour les images docker utilisées de façon automatique. Il va permettre de télécharger la nouvelle image, supprimer proprement le conteneur l'utilisant et le relancer avec les mêmes options. Par défaut, cela utilise le Docker Hub, mais il est possible de paramétrer un registry privé en spécifiant des credentials.

La documentation complète peut être accessible ici : https://containrrr.dev/watchtower/

Installation

L'installation est très simple car Watch Tower va tourner lui-même en conteneur.

Je vais utiliser un fichier docker-compose.yml pour exécuter l'application :

version: '3.8'
services:
 watchtower:
 image: containrrr/watchtower:latest
 container_name: watchtower
 restart: unless-stopped
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 command: --schedule "0 0 4 * * *" --cleanup

docker.sock : Indispensable pour avoir accès au socket docker de l'hôte dans le conteneur afin de surveiller tous les autres conteneurs.
schedule : Permet de préciser quand vérifier les mises à jour sous un format à 6 colonnes (contrairement à crontab). La 1ère colonne correspond aux secondes. Ici, 4h tous les jours.
cleanup : Permet de supprimer les anciennes images docker.

Par défaut toutes les images de tous les conteneurs sont surveillées. Il est possible d'affiner ce comportement.

D'autres options sont disponibles (Se référer à la documentation précisée en introduction).

Exécution

Lancer simplement le docker-compose.yml :

docker-compose up -d

Docker-Compose : Portainer Agent

Mon, 15 Aug 2022 16:55:25 +0200

docker-compose.yml

version: '3'

services:
 agent:
 image: portainer/agent
 container_name: portainer_agent
 restart: unless-stopped
 security_opt:
 - no-new-privileges:true
 volumes:
 - /etc/localtime:/etc/localtime:ro
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /var/lib/docker/volumes:/var/lib/docker/volumes
 ports:
 - 9001:9001