Docker on slash-root.fr

Docker : Metrics port 9323

Sun, 15 Jun 2025 18:55:14 +0200

L'option metrics-addr est une configuration importante du daemon Docker qui permet d'exposer les métriques de performance et d'utilisation des ressources via un endpoint HTTP. Cette fonctionnalité, combinée avec le port par défaut 9323, vous donne accès à une mine d'informations sur votre environnement Docker.

Comprendre l’option metrics-addr

L'option metrics-addr configure l'adresse IP et le port sur lesquels le daemon Docker expose ses métriques. Par défaut, quand cette option est activée, Docker utilise le port 9323.

Pourquoi le port 9323 ?

C'est un port non-privilégié (supérieur à 1024)
Il est officiellement alloué à Docker par l'IANA pour cette fonctionnalité
Il est peu susceptible d'entrer en conflit avec d'autres services courants
Il suit la convention de Prometheus pour les ports d'exportation de métriques (9xxx)

Ce que vous obtenez avec metrics-addr

Activer l'option metrics-addr dans le daemon.json vous donne accès à de nombreuses métriques Docker formatées nativement pour Prometheus :

Métriques système : Utilisation CPU, mémoire, disque et réseau par conteneur
Métriques du daemon : État du daemon, nombre d'objets gérés (conteneurs, images, volumes)
Métriques d'utilisation : Temps de démarrage des conteneurs, opérations réseau
Métriques de performance : Latences des opérations de build et de déploiement

Toutes ces métriques sont disponibles au format Prometheus, ce qui les rend facilement intégrables dans un système de monitoring existant.

ℹ️ Point technique : Le format Prometheus utilise des "labels" qui permettent de filtrer et d'agréger les métriques de manière flexible.

Cas d’utilisation pour metrics-addr

L'activation de metrics-addr est particulièrement utile dans les scénarios suivants :

Supervision d'infrastructure : Intégration avec Prometheus pour surveiller l'ensemble de votre environnement Docker
Alerting automatisé : Déclencher des alertes basées sur des seuils de métriques spécifiques
Dashboarding : Création de tableaux de bord Grafana pour visualiser les performances
Analyse de tendance : Collecter des données sur de longues périodes pour identifier les tendances
Détection d'anomalies : Repérer les comportements anormaux dans vos conteneurs

Configuration de metrics-addr

Configuration via daemon.json

La méthode recommandée pour activer les métriques Docker est de modifier le fichier de configuration du daemon :

Éditez le fichier de configuration Docker :
```
sudo vi /etc/docker/daemon.json
```
Ajoutez la configuration pour activer l'API de métriques :
```
{
 "metrics-addr" : "127.0.0.1:9323",
 "experimental" : true
}
```
Note : L'adresse 127.0.0.1 limite l'accès à la machine locale. Pour exposer les métriques au réseau, utilisez 0.0.0.0:9323 (avec précaution).
Redémarrez Docker pour appliquer les changements :
```
sudo systemctl restart docker
```
Vérifiez que les métriques sont disponibles :
```
curl http://localhost:9323/metrics
```
Vous devriez voir une sortie avec de nombreuses métriques au format Prometheus.

Visualisation simple avec Docker Stats

Pour un aperçu rapide des performances de vos conteneurs sans configuration supplémentaire :

docker stats

Cela affiche en temps réel les statistiques d'utilisation des ressources pour tous les conteneurs :

CPU% : Pourcentage d'utilisation du CPU
MEM% : Pourcentage d'utilisation de la mémoire
NET I/O : Transfert réseau entrant/sortant
BLOCK I/O : Lectures/écritures sur disque
PIDS : Nombre de processus

Pour cibler des conteneurs spécifiques :

docker stats container1 container2

Note: Pour des solutions plus avancées comme Prometheus+Grafana ou cAdvisor, voir la section "Solutions avancées" en fin d'article.

Les limites à connaître

Limites des métriques natives :
- Pas de persistance des données historiques
- Interface de visualisation minimale
- Absence d'alertes automatiques
Considérations de performance :
- L'activation des métriques consomme des ressources supplémentaires
- L'exposition sur le réseau nécessite des précautions de sécurité
- Le port 9323 doit être protégé par un pare-feu ou limité à localhost
Limites de fonctionnalités :
- Les métriques Docker ne couvrent pas les métriques applicatives
- Pas d'information sur la santé des applications à l'intérieur des conteneurs
- Nécessite des outils complémentaires pour une vision complète

Bonnes pratiques

Commencez simplement
- Identifiez les métriques critiques pour votre cas d'usage
- Augmentez progressivement la complexité
Automatisez les alertes
- Configurez des alertes sur les seuils critiques
- Évitez les alertes trop sensibles qui causeraient de la fatigue d'alarme
Corrélation de métriques
- Combinez les métriques Docker avec des métriques système et applicatives
- Utilisez des dashboards qui montrent des corrélations entre métriques
Conservation des données
- Définissez une politique de rétention adaptée à vos besoins
- Agrégez les données anciennes pour économiser de l'espace

En résumé

Les métriques Docker sont essentielles pour une gestion efficace des conteneurs en production. La configuration via daemon.json offre un moyen simple d'exposer ces données pour votre monitoring, vous donnant une première couche de visibilité sur vos conteneurs.

💡 Astuce : Commencez par les métriques natives et docker stats pour comprendre vos besoins, puis évaluez si vous avez besoin de solutions plus avancées.

Solutions avancées (Annexe)

1. Intégration avec Prometheus

Les métriques exposées via daemon.json sont déjà au format Prometheus. Pour les collecter :

# prometheus.yml
scrape_configs:
 - job_name: 'docker'
 static_configs:
 - targets: ['127.0.0.1:9323']

2. Utilisation de cAdvisor

Pour une solution prête à l'emploi avec interface web :

docker run \
 --volume=/:/rootfs:ro \
 --volume=/var/run:/var/run:ro \
 --volume=/sys:/sys:ro \
 --volume=/var/lib/docker/:/var/lib/docker:ro \
 --publish=8080:8080 \
 --detach=true \
 --name=cadvisor \
 gcr.io/cadvisor/cadvisor:latest

Interface disponible sur http://localhost:8080

Docker : live-restore, c’est quoi ?

Sun, 15 Jun 2025 18:06:04 +0200

live-restore est une fonctionnalité de Docker qui permet aux conteneurs de continuer à fonctionner normalement pendant que le daemon Docker redémarre. En activant cette option, vous évitez l'arrêt intempestif de vos applications lors des mises à jour ou des modifications de configuration du daemon Docker.

Le problème : Sans live-restore

Par défaut, quand vous exécutez systemctl restart docker :

Tous les conteneurs en cours d'exécution s'arrêtent immédiatement
Les applications deviennent inaccessibles
Les connexions réseau sont brutalement coupées
Les données en mémoire non sauvegardées peuvent être perdues

C'est comme couper l'électricité d'un bâtiment entier pour changer une ampoule !

La solution : Comment fonctionne live-restore ?

Quand vous activez live-restore, Docker modifie son comportement :

Découplage : Les conteneurs sont détachés du cycle de vie du daemon
Maintien en vie : Les processus continuent de s'exécuter sous la supervision du noyau Linux
Reprise : Le daemon Docker reprend le contrôle des conteneurs après son redémarrage

ℹ️ Important : Cela ne protège que contre les redémarrages du daemon Docker, pas contre les arrêts du système d'exploitation ou les pannes matérielles.

Quand utiliser live-restore ?

Cette fonctionnalité est particulièrement utile pour :

Mises à jour de sécurité : Appliquer des correctifs sans interruption de service
Maintenance planifiée : Modifier la configuration Docker sans impacter les applications
Environnements critiques : Où la disponibilité est essentielle
Déploiements complexes : Avec de nombreuses dépendances entre conteneurs

Comment l’activer ?

Éditez le fichier de configuration Docker :
```
sudo vi /etc/docker/daemon.json
```
Ajoutez ou modifiez la configuration :
```
{
 "live-restore": true
}
```
Redémarrez Docker :
```
sudo systemctl restart docker
```
Vérifiez l'activation :
```
docker info | grep -i live
```
Vous devriez voir : Live Restore Enabled: true

Les limites à connaître

Pas de protection contre :
- Les redémarrages du système d'exploitation
- Les pannes matérielles
- Les arrêts intempestifs du système
Fonctionnalités limitées pendant le redémarrage :
- La CLI Docker est indisponible
- Pas de création/suppression de conteneurs
- Gestion réseau et stockage limitée
Compatibilité :
- Certains drivers de stockage peuvent poser problème
- Les fonctionnalités expérimentales ne sont pas toujours supportées

Bonnes pratiques

Testez d'abord en préproduction
Surveillez les métriques système pendant les redémarrages
Documentez la procédure pour votre équipe
Ayez un plan de secours en cas de problème

En résumé

live-restore est un outil précieux pour maintenir la disponibilité de vos conteneurs lors des opérations de maintenance du daemon Docker. Bien qu'il ne soit pas une solution miracle, il peut vous aider à réduire considérablement les temps d'arrêt non planifiés.

💡 Astuce : Pour une haute disponibilité complète, combinez live-restore avec d'autres stratégies comme l'orchestration de conteneurs (Swarm, Kubernetes) et la répartition de charge.

Docker : Configuration et gestion des logs

Sun, 15 Jun 2025 17:33:44 +0200

Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans l'univers des logs Docker. Comme on dit dans notre jargon : "Sans logs, c'est comme chercher une erreur dans un datacenter éteint - théoriquement possible, mais pas vraiment efficace."

Comprendre les logs dans Docker

Docker propose plusieurs pilotes de journalisation pour gérer les logs de vos conteneurs. Par défaut, tous vos messages sont acheminés vers le pilote json-file, qui stocke les logs sous forme de fichiers JSON dans /var/lib/docker/containers/[container-id]/.

Le problème ? Ces fichiers peuvent grossir... grossir... et encore grossir, jusqu'à dévorer tout l'espace disque de votre serveur. Une véritable histoire d'horreur pour tout admin système qui se respecte.

Configuration du pilote de logs par défaut

La configuration des logs se fait dans le fichier /etc/docker/daemon.json. Voici comment éviter le scénario catastrophe du disque plein :

{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3"
 }
}

Note : Cette configuration limite la taille de chaque fichier de log à 10 Mo et permet une rotation sur 3 fichiers maximum.

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

sudo systemctl restart docker

Les différents pilotes de logs

Docker ne se limite pas au format JSON. Voici les principaux pilotes disponibles, chacun avec ses forces et ses faiblesses :

json-file : Le pilote par défaut
- Stocke les logs dans des fichiers JSON
- Accessible via docker logs
- Exemple de configuration personnalisée :
```
docker run --log-driver=json-file \
 --log-opt max-size=10m \
 --log-opt max-file=3 \
 --log-opt labels=app_name \
 nginx
```
- Parfait pour le développement et les petits déploiements
local : Le petit frère optimisé
- Format binaire plus compact que JSON
- Toujours accessible via docker logs
- Exemple d'utilisation :
```
docker run --log-driver=local \
 --log-opt max-size=10m \
 --log-opt max-file=5 \
 --log-opt compress=true \
 nginx
```
- Idéal pour les environnements de production avec espace disque limité

syslog : L'option du barbu expérimenté

Envoie les logs au service syslog de l'hôte

Configuration type avec rotation via logrotate :

# Dans /etc/docker/daemon.json
{
"log-driver": "syslog",
"log-opts": {
 "syslog-address": "udp://192.168.1.100:514",
 "tag": "{{.ImageName}}/{{.Name}}/{{.ID}}",
 "syslog-facility": "local7"
}
}

Configuration équivalente dans docker-compose :

services:
app:
 image: nginx
 logging:
 driver: syslog
 options:
 syslog-address: "udp://192.168.1.100:514"
 tag: "{{.ImageName}}/{{.Name}}/{{.ID}}"

Petit prix à payer : docker logs ne fonctionne plus directement

journald : L'ami des systèmes modernes

Parfait pour les systèmes basés sur systemd

Exemple de configuration :

# Activer journald dans /etc/docker/daemon.json
{
"log-driver": "journald",
"log-opts": {
 "tag": "{{.ImageName}}/{{.Name}}/{{.ID}}",
 "labels": "app_name,environment"
}
}

Pour consulter les logs :

# Voir les logs d'un conteneur
journalctl CONTAINER_NAME=mon_conteneur

# Suivre les logs en temps réel
journalctl -f CONTAINER_NAME=mon_conteneur

# Filtrer par priorité
journalctl -p err CONTAINER_NAME=mon_conteneur

Le choix évident si vous utilisez déjà systemd pour tout le reste

Les poids lourds : pour les environnements critiques

Splunk :

docker run --log-driver=splunk \
 --log-opt splunk-token=YOUR_TOKEN \
 --log-opt splunk-url=https://your-splunk:8088 \
 --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" \
 nginx

AWS CloudWatch Logs :

docker run --log-driver=awslogs \
 --log-opt awslogs-region=eu-west-1 \
 --log-opt awslogs-group=my-log-group \
 --log-opt awslogs-stream=my-stream \
 nginx

Fluentd :

# docker-compose.yml
version: '3'
services:
 app:
 image: nginx
 logging:
 driver: "fluentd"
 options:
 fluentd-address: localhost:24224
 tag: docker.{{.Name}}

 fluentd:
 image: fluent/fluentd
 volumes:
 - ./fluentd/conf:/fluentd/etc
 ports:
 - "24224:24224"

GELF (Graylog Extended Log Format) :

docker run --log-driver=gelf \
 --log-opt gelf-address=udp://graylog:12201 \
 --log-opt tag="{{.ImageName}}/{{.Name}}" \
 nginx

Ces solutions sont idéales pour les environnements de production à grande échelle nécessitant une analyse avancée des logs.

Configuration par conteneur

Parfois, un conteneur mérite un traitement spécial. Vous pouvez configurer le pilote de logs individuellement, comme un couturier qui ajuste un costume sur mesure :

docker run --log-driver=journald --log-opt labels=app_id --name=mon-app nginx

Ou dans un fichier docker-compose.yml :

version: '3'
services:
 mon_service:
 image: mon_image
 logging:
 driver: json-file
 options:
 max-size: "10m" # Taille maximale d'un fichier de log
 max-file: "3" # Nombre maximum de fichiers de rotation

Bonnes pratiques pour la gestion des logs

La rotation, c'est la vie
- Configurez toujours max-size et max-file
- Évitez les fichiers de logs de 42 Go qui font pleurer les disques durs
Étiquetez, c'est gagné
- Utilisez des tags personnalisés pour chaque conteneur
- Ajoutez des labels pour plus de contexte
Les logs, c'est comme le bon vin : ça se conserve
- Centralisez avec ELK, Graylog ou Loki
- Pensez à la rétention et à l'archivage
La surveillance, c'est comme le café du matin : indispensable
- Surveillez l'espace disque utilisé par les logs
- Configurez des alertes pour les cas critiques, surtout en production
Structurez vos logs : encouragez vos développeurs à générer des logs au format JSON pour faciliter leur analyse

Conclusion

Les logs, c'est un peu comme le journal intime de vos conteneurs. Une bonne configuration peut transformer une enquête policière en simple coup d'œil. Ou l'inverse.

Comme dirait un vieux barbu de l'IT : "Les logs, c'est comme le papier toilette - on ne réalise leur importance que quand on en a plus." Alors, à vos fichiers de configuration, et que la force des logs soit avec vous !

Et souvenez-vous : dans un monde de conteneurs éphémères, seuls les logs racontent l'histoire complète (du moins jusqu'à ce qu'ils soient eux aussi supprimés par rotation).

Docker : Configuration et gestion du stockage

Sun, 15 Jun 2025 16:56:25 +0200

Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans les profondeurs du stockage Docker. Comme on dit dans notre jargon : "Un disque mal configuré est à un admin système ce que Kryptonite est à Superman - une faiblesse qui peut tout paralyser."

Comprendre le stockage dans Docker

Docker utilise un système de stockage en couches qui peut être à la fois génial et déroutant. Chaque instruction dans un Dockerfile crée une nouvelle couche en lecture seule, et seul le conteneur en fonctionnement dispose d'une couche supérieure en lecture-écriture.

Par défaut, Docker stocke toutes ses données (images, conteneurs, volumes) dans /var/lib/docker. Sur un serveur de production, cette partition peut rapidement devenir le goulot d'étranglement de votre système.

Configuration du pilote de stockage

Docker propose plusieurs pilotes de stockage, chacun avec ses avantages et inconvénients. Vous pouvez configurer le pilote à utiliser dans le fichier /etc/docker/daemon.json :

{
 "storage-driver": "overlay2"
}

Note : overlay2 est généralement le pilote recommandé pour les distributions Linux modernes, offrant le meilleur équilibre entre performance et fonctionnalités.

Après cette modification, un redémarrage du service Docker est nécessaire :

sudo systemctl restart docker

Les différents pilotes de stockage

overlay2 : Le pilote recommandé pour la plupart des cas d'usage
- Avantages : Bonnes performances, compatibilité
- Prérequis : Noyau Linux 4.0+ et systèmes de fichiers modernes
Le pilote overlay2 repose sur la fonctionnalité OverlayFS du noyau Linux, qui permet de superposer plusieurs systèmes de fichiers. Il fonctionne avec la plupart des systèmes de fichiers courants (ext4, xfs) et offre de bien meilleures performances que l'ancien pilote overlay.
devicemapper : Utilisé principalement sur les anciennes versions de CentOS/RHEL
- Pour la production, configurez-le en mode direct-lvm plutôt qu'en mode loop-lvm par défaut
- Permet d'utiliser un périphérique de bloc dédié pour les données Docker, offrant de meilleures performances

{
 "storage-driver": "devicemapper",
 "storage-opts": [
 "dm.directlvm_device=/dev/xvdf"
 ]
}

Systèmes de fichiers avancés et distribués : Pour aller plus loin
- Les systèmes comme btrfs et zfs offrent des fonctionnalités avancées comme les snapshots
- Les systèmes de fichiers distribués comme Ceph ou GlusterFS permettent de créer une infrastructure de stockage Docker hautement disponible et évolutive
Astuce : Pour tirer pleinement profit de ces systèmes distribués, utilisez la technique du "volume bind déguisé" qui permet de créer un volume Docker qui pointe vers un point de montage réseau

Déplacer le répertoire de données Docker

Si votre partition /var est trop petite, vous pouvez déplacer le répertoire de données Docker vers un autre emplacement :

{
 "data-root": "/mnt/docker-data"
}

Attention : Ne modifiez jamais ce paramètre sur une installation Docker existante sans migrer correctement les données !

Pour migrer les données d'une installation existante :

# Arrêter Docker
sudo systemctl stop docker

# Créer le nouveau répertoire
sudo mkdir -p /mnt/docker-data

# Copier les données existantes
sudo rsync -aP /var/lib/docker/ /mnt/docker-data/

# Configurer le nouveau chemin dans daemon.json
# Puis redémarrer Docker
sudo systemctl start docker

Volumes bind déguisés : la technique du ninja du stockage

Une des techniques les plus astucieuses dans l'arsenal de l'admin Docker est celle du "volume bind déguisé" - ou comment faire passer un bind mount pour un volume Docker respectable, tout en gardant le contrôle sur l'emplacement physique des données.

Imaginez pouvoir dire à vos conteneurs : "Voici un volume Docker standard" alors qu'en coulisses, vous stockez les données sur votre cluster Ceph soigneusement configuré. C'est comme servir un plat végétarien à vos invités sans qu'ils ne remarquent l'absence de viande - l'élégance à l'état pur.

Cette technique est particulièrement précieuse quand vous travaillez avec :

Des systèmes de stockage distribués (Ceph, GlusterFS)
Des montages NFS pour un stockage partagé
Des volumes qui doivent survivre à la migration de vos conteneurs

Pour les détails d'implémentation, consultez mon article dédié : Docker : Volume bind déguisé qui vous explique pas à pas comment mettre en place cette technique.

Nettoyage de l’espace disque

Docker a tendance à accumuler des données inutilisées. Voici quelques commandes pour faire le ménage :

# Supprimer les conteneurs arrêtés, réseaux non utilisés, images dangling et cache de build
docker system prune

# Pour être encore plus agressif et supprimer aussi les images non utilisées
docker system prune -a

# Pour récupérer de l'espace sur les volumes non utilisés
docker volume prune

Bonnes pratiques pour la gestion du stockage

Utilisez des images légères : Préférez les images basées sur Alpine quand c'est possible
Optimisez vos Dockerfiles :
- Combinez les commandes RUN pour réduire le nombre de couches
- Nettoyez les caches de paquets dans la même instruction qui les installe

RUN apt update && apt install -y \
 package1 \
 package2 \
 && apt clean \
 && rm -rf /var/lib/apt/lists/*

Utilisez .dockerignore pour exclure les fichiers inutiles du contexte de build
Surveillez régulièrement l'espace disque utilisé par Docker avec docker system df
Configurez un cron job pour nettoyer périodiquement les ressources inutilisées

Conclusion

La gestion du stockage Docker ressemble parfois à un jeu de Tetris où les blocs seraient des gigaoctets - il faut savoir optimiser l'espace pour éviter le game over.

En configurant correctement votre pilote de stockage et en adoptant de bonnes pratiques de nettoyage, vous pourrez éviter ce moment gênant où vous devez expliquer pourquoi le serveur de production s'est arrêté juste parce qu'il y avait trop d'images "hello-world" qui traînaient.

Et souvenez-vous : dans un monde de conteneurs éphémères, les données persistantes méritent toujours une réflexion approfondie (et un bon volume Docker).

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).

Docker-Compose : Mise à jour manuelle des images

Mon, 01 Jul 2024 11:15:09 +0200

Pré-requis

Assurez-vous de vous placer dans le répertoire contenant le fichier docker-compose.yml avant de suivre les étapes ci-dessous.

Étapes pour la mise à jour

Télécharger les images mises à jour

Utilisez la commande suivante pour télécharger les dernières versions des images spécifiées dans le fichier docker-compose.yml :

docker compose pull

Redémarrer les conteneurs avec les nouvelles images

Redémarrez les conteneurs pour appliquer les mises à jour. Utilisez l'option -d pour détacher le processus et --remove-orphans pour supprimer les conteneurs qui ne sont plus définis dans le fichier docker-compose.yml :

docker compose up -d --remove-orphans

Nettoyer les images obsolètes

Pour libérer de l'espace disque, supprimez les images qui ne sont plus utilisées par aucun conteneur actif :

docker image prune

Docker-Compose : WordPress (MariaDB)

Sat, 15 Jun 2024 11:53:16 +0200

Le fichier docker-compose.yml

services:
 wordpress:
 image: wordpress
 container_name: "wordpress"
 restart: unless-stopped
 ports:
 - "8080:80"
 environment:
 WORDPRESS_DB_HOST: db
 WORDPRESS_DB_USER: "wordpress"
 WORDPRESS_DB_PASSWORD: "wordpress_db_password"
 WORDPRESS_DB_NAME: wordpress
 volumes:
 - ./wordpress:/var/www/html
 - /etc/localtime:/etc/localtime:ro
 depends_on:
 - db
 networks:
 - network

 db:
 image: mariadb
 container_name: "wordpress-db"
 restart: unless-stopped
 environment:
 MYSQL_RANDOM_ROOT_PASSWORD: '1'
 MYSQL_DATABASE: wordpress
 MYSQL_USER: "wordpress"
 MYSQL_PASSWORD: "wordpress_db_password"
 volumes:
 - ./db:/var/lib/mysql
 - /etc/localtime:/etc/localtime:ro
 networks:
 - network

networks:
 network:
 driver: bridge

Execution

docker compose up -d

Docker : Volume bind déguisé

Wed, 11 Oct 2023 11:25:12 +0200

Avec Docker, il y a principalement 2 types de volumes qui sont utilisés :

Les volumes "volume" : Permet de stocker un répertoire du conteneur dans un volume docker stocké sur l'host (/var/lib/docker/volumes).
Les volumes "bind" : Permet de monter un répertoire présent sur l'host dans un conteneur.

Personnellement, j'utilise la plupart du temps des volumes de type "bind" afin d'avoir de la persistence pour certaines données d'un conteneur. Par exemple, une base de donnée.

Le problème que je recontre parfois est la gestion des utilisateurs/groupes propriétaires et des permissions sur les données stockées dans ce type de volume "bind".

Avec un volume "volume", l'avantage est que tout est géré par docker. Par contre, je ne souhaite pas forcément stocker ce volume docker dans /var/lib/docker/volumes de l'host.

Alors, nous allons voir comment utilisé un volume docker mais qui en faites sera un volume de type bind. Ce que je nomme un volume bind déguisé en volume docker 🙂

Création du volume docker

Tout d'abord, créer un répertoire local sur l'host qui stockera les données :

sudo mkdir -m 775 -p /srv/docker/volumes/data

Puis, changer l'utilisateur et groupe propriétaire :

sudo chown -R $USER:docker /srv/docker/volumes

Enfin, créer le volume docker :

docker volume create --driver local \
 --opt type=none \
 --opt device=/srv/docker/volumes/data \
 --opt o=bind vol_data

--driver local : Définit le driver docker à utiliser à local (par défaut).
--opt type=none : Il est important de bien définir le type à none.
--opt device= : Où seront stocké les données du volume sur l'host.
--opt o=bind : C'est avec cette option que le volume docker sera en faites un volume bind.

Vérifier la création du volume :

$ docker volume list
DRIVER VOLUME NAME
local vol_data

Vérifier les propriétés du volume :

$ docker inspect vol_data
[
 {
 "CreatedAt": "2023-10-11T11:15:38+02:00",
 "Driver": "local",
 "Labels": null,
 "Mountpoint": "/var/lib/docker/volumes/vol_data/_data",
 "Name": "vol_data",
 "Options": {
 "device": "/srv/docker/volumes/data",
 "o": "bind",
 "type": "none"
 },
 "Scope": "local"
 }
]

Un volume nommé vol_data est à présent disponible pour un conteneur.

Utilisation du volume docker

Avec docker run

Pour utiliser ce volume docker avec docker run , comme avec un volume docker "classique", utiliser l'option --volume vol_data:/data. Cela montera le volume docker "vol_data" précédement créé dans le point de montage "/data" du conteneur.

Avec docker compose

Pour utiliser ce volume docker dans un docker-compose.yml, c'est comme un volume classique :

version: '3'
services
 app:
 #...
 volumes:
 - vol_data:/data
 #...
volumes:
 vol_data:

Portainer

Si portainer est utilisé pour gérer l'hôte docker, le volume apparaitra dans la section "Volumes" de l'interface web. Si vous créez vos conteneurs, services, stacks swarm sur Portainer, vous pourrez l'utiliser sans problème.

Toutefois, il est impossible de créer ce genre de volume via l'interface web de portainer.

Attention cependant au nom du volume que vous lui donner lors de sa création.

Par exemple, je souhaite utiliser un volume docker (qui finalement sera de type bind) dans une stack swarm qui s'appelle "webapp". Lors de la création du volume, je le nommerai "webapp_vol_data" et dans mon fichier yaml de la stack, j'appelerai ce volume uniquement "vol_data".

Si le volume utilisé dans un docker-compose n'est pas bien définit au niveau du nommage, un volume docker "standard" sera alors automatiquement créer à la place et celui-ci sera dans /var/lib/docker/volumes.

Donc bien penser à vérifier que les données soient au bon endroit sur l'host. Surtout si les données doivent être stockées sur un volume réseau !

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 : Drawio

Mon, 12 Sep 2022 07:24:05 +0200

Le fichier docker-compose.yml

version: '3.3'
services:
 drawio:
 image: jgraph/drawio
 container_name: drawio
 ports:
 # http://localhost:8080
 - 8080:8080
 # https://localhost:8443
 - 8443:8443

Execution

docker-compose up -d

Docker Swarm : Stack Drawio

Mon, 12 Sep 2022 07:21:23 +0200

Informations importantes

Avoir réalisé l'enregistrement DNS adéquat pour url.application.com
Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Fichier stack.yml

version: '3.3'

services:
 drawio:
 image: jgraph/drawio
 networks:
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 labels:
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Indiquer l'URL d'accès à l'application
 - traefik.http.routers.drawio-http.rule=Host(<code>url.application.com</code>)
 - traefik.http.routers.drawio-http.entrypoints=http
 - traefik.http.routers.drawio-http.middlewares=https-redirect
 # Indiquer l'URL d'accès à l'application
 - traefik.http.routers.drawio-https.rule=Host(<code>url.application.com</code>)
 - traefik.http.routers.drawio-https.entrypoints=https
 - traefik.http.routers.drawio-https.tls=true
 - traefik.http.routers.drawio-https.tls.certresolver=le
 - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000
 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true
 - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true
 - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN
 - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true
 - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true
 - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin
 - traefik.http.routers.drawio-https.middlewares=hsts-headers
 - traefik.http.services.drawio.loadbalancer.server.port=8080

networks:
 traefik-public:
 external: true

Déploiement

docker stack deploy -c stack.yml drawio

Accès

https://url.application.com

Docker-Compose : OpenVAS

Sun, 04 Sep 2022 22:36:59 +0200

Le fichier docker-compose.yml

version: '3.7'
services:
 openvas:
 image: immauss/openvas
 container_name: openvas
 environment:
 # Indiquer un MotDePasseTresSecure or play with env's file
 PASSWORD: MotDePasseTresSecure
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 - ./data:/data
 ports:
 - 9392:9392

Execution

mkdir data
docker-compose up -d

Docker Swarm : Stack OpenVAS

Sun, 04 Sep 2022 12:16:16 +0200

Informations importantes

Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Fichier stack.yml

version: '3.3'

services:

 app:
 image: immauss/openvas
 environment:
 # Indiquer un mot de passe pour le compte admin de l'application
 PASSWORD: MotDePasseTresSecure
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label.
 - data:/data
 networks:
 # Indispensable pour communiquer avec traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 - node.labels.openvas_data == true
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Indiquer l'URL de l'application (openvas.example.com)
 - traefik.http.routers.openvas-http.rule=Host(`openvas.example.com`)
 - traefik.http.routers.openvas-http.entrypoints=http
 - traefik.http.routers.openvas-http.middlewares=https-redirect
 # Indiquer l'URL de l'application (openvas.example.com)
 - traefik.http.routers.openvas-https.rule=Host(`openvas.example.com`)
 - traefik.http.routers.openvas-https.entrypoints=https
 - traefik.http.routers.openvas-https.tls=true
 - traefik.http.routers.openvas-https.tls.certresolver=le
 # Indiquer le nomagentapplication pour les headers à travers traefik
 - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000
 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true
 - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true
 - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN
 - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true
 - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true
 - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin
 - traefik.http.routers.openvas-https.middlewares=hsts-headers
 - traefik.http.services.openvas.loadbalancer.server.port=9392

networks:
 traefik-public:
 external: true

volumes:
 data:
 driver: local

Déploiement

docker stack deploy -c stack.yml openvas

Docker-Compose : OpenProject

Thu, 25 Aug 2022 11:55:11 +0200

Changelog

04/09/2022 : Fix environnement

Informations importantes

Tous les services tournent dans un seul conteneur.
Le compte par défaut est admin avec le mot de passe admin.
URL d'accès : http://localhost:8080
Par défaut des connexions anonymes sont autorisées. Dans le menu Administration / Authentification, il est possible de modifier ce comportement :

Fichier docker-compose.yml

version: '3.3'

services:

 openproject:
 image: openproject/community:12
 environment:
 OPENPROJECT_HOST__NAME: localhost:8080
 OPENPROJECT_HTTPS: "false"
 # head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32 ; echo ''
 OPENPROJECT_SECRET_KEY_BASE: A_GENERER_AVEC_LA_CMD_CI-DESSUS
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 - pgdata:/var/openproject/pgdata
 - assets:/var/openproject/assets
 ports:
 - 8080:80

volumes:
 pgdata:
 driver: local
 assets:
 driver: local

Execution

docker-compose up -d

Docker Swarm : Stack Keycloak (v19 latest)

Mon, 22 Aug 2022 10:39:09 +0200

Informations importantes

Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Cette stack est faites pour du développement (avec persistance des données) et non de la production
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Fichier stack.yml

version: '3.3'

services:

 app:
 image: quay.io/keycloak/keycloak:latest
 security_opt:
 - no-new-privileges:true
 command: start-dev
 environment:
 PROXY_ADDRESS_FORWARDING: "true"
 KC_FEATURES: token-exchange
 KC_PROXY: passthrough
 KEYCLOAK_ADMIN: admin
 # Indiquer un mot de passe pour le compte admin sur l'application keycloak
 KEYCLOAK_ADMIN_PASSWORD: MotDePasseTresSecure

 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label.
 - conf:/opt/keycloak/conf
 - data:/opt/keycloak/data
 - providers:/opt/keycloak/providers
 - themes:/opt/keycloak/themes
 networks:
 # Indispensable pour communiquer avec traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 - node.labels.keycloak_quay-io_conf == true
 - node.labels.keycloak_quay-io_data == true
 - node.labels.keycloak_quay-io_providers == true
 - node.labels.keycloak_quay-io_themes == true
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Indiquer l'URL de l'application (keycloak.example.com)
 - traefik.http.routers.keycloak_quay-io-http.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak_quay-io-http.entrypoints=http
 - traefik.http.routers.keycloak_quay-io-http.middlewares=https-redirect
 # Indiquer l'URL de l'application (keycloak.example.com)
 - traefik.http.routers.keycloak_quay-io-https.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak_quay-io-https.entrypoints=https
 - traefik.http.routers.keycloak_quay-io-https.tls=true
 - traefik.http.routers.keycloak_quay-io-https.tls.certresolver=le
 - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000
 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true
 - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true
 - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN
 - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true
 - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true
 - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin
 - traefik.http.routers.keycloak_quay-io-https.middlewares=hsts-headers
 - traefik.http.services.keycloak_quay-io.loadbalancer.server.port=8080

networks:
 traefik-public:
 external: true

volumes:
 conf:
 driver: local
 data:
 driver: local
 providers:
 driver: local
 themes:
 driver: local

Déploiement

docker stack deploy -c stack.yml keycloak

Docker Swarm : Stack Nextcloud

Thu, 18 Aug 2022 13:00:13 +0200

Changelog

22/08/2022 : Fix traefik headers as same origin, trusted proxy, redirectregex

Informations importantes

Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Fichier stack.yml

version: '3.3'

services:

 mariadb:
 image: mariadb
 command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --skip-innodb-read-only-compressed
 environment:
 # Indiquer les mots de passe souhaités
 MYSQL_ROOT_PASSWORD: MotDePasseTresSecure
 MYSQL_PASSWORD: MotDePasseTresSecure
 MYSQL_DATABASE: nextcloud
 MYSQL_USER: nextcloud
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label.
 - mariadb:/var/lib/mysql
 networks:
 - net
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 #- node.role == worker
 - node.labels.nextcloud_mariadb == true

 app:
 image: nextcloud
 environment:
 # Indiquer le mot de passe inscrit précédement
 MYSQL_PASSWORD: MotDePasseTresSecure
 MYSQL_DATABASE: nextcloud
 MYSQL_USER: nextcloud
 MYSQL_HOST: mariadb
 TRUSTED_PROXIES: traefik
 # Indiquer le domaine souhaité de l'application
 OVERWRITEHOST: nextcloud.example.com
 OVERWRITEPROTOCOL: https
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label.
 - nextcloud:/var/www/html
 networks:
 - net
 # Indispensable pour communiquer avec traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 #- node.role == worker
 - node.labels.nextcloud_nextcloud == true
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Indiquer le domaine souhaité pour l'application
 - traefik.http.routers.nextcloud-http.rule=Host(`nextcloud.example.com`)
 - traefik.http.routers.nextcloud-http.entrypoints=http
 - traefik.http.routers.nextcloud-http.middlewares=https-redirect
 # Indiquer le domaine souhaité pour l'application
 - traefik.http.routers.nextcloud-https.rule=Host(`nextcloud.example.com`)
 - traefik.http.routers.nextcloud-https.entrypoints=https
 - traefik.http.routers.nextcloud-https.tls=true
 - traefik.http.routers.nextcloud-https.tls.certresolver=le
 # Middleware pour nextcloud
 - traefik.http.middlewares.nextcloud-redirectregex.redirectRegex.permanent=true
 - traefik.http.middlewares.nextcloud-redirectregex.redirectRegex.regex=https://(.*)/.well-known/(card|cal)dav
 - traefik.http.middlewares.nextcloud-redirectregex.redirectRegex.replacement=https://$${1}/remote.php/dav/
 - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000
 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true
 - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true
 - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN
 - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true
 - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true
 - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin
 - traefik.http.routers.nextcloud-https.middlewares=hsts-headers,nextcloud-redirectregex
 # Indiquer le port utiliser de l'application
 - traefik.http.services.nextcloud.loadbalancer.server.port=80

networks:
 net:
 driver: overlay
 attachable: true
 traefik-public:
 external: true

volumes:
 mariadb:
 driver: local
 nextcloud:
 driver: local

Déploiement

docker stack deploy -c stack.yml nextcloud

Docker Swarm : Stack Keycloak (v16 depreciated)

Thu, 18 Aug 2022 11:47:44 +0200

Changelog

22/08/2022 : Ajout information depreciated

Informations importantes

Nécessite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Ce stack utilise une image docker provenant de jboss qui est un keycloak en v16. La dernière version actuelle est la v19. Stack disponible ici : /docker-swarm-stack-keycloak-v19-latest/

Fichier stack.yml

version: '3.3'

services:
 postgres:
 image: postgres
 environment:
 POSTGRES_DB: keycloak
 POSTGRES_USER: keycloak
 # Indiquer le mot de passe souhaité
 POSTGRES_PASSWORD: MotDePasseTresSecure
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 - postgres_data:/var/lib/postgresql/data
 networks:
 - net
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph)
 - node.labels.keycloak_postgres_data == true

 keycloak:
 image: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 # Indiquer le mot de passe inscrit dans le service postgre
 DB_PASSWORD: MotDePasseTresSecure
 KEYCLOAK_USER: admin
 # Indiquer le mot de passe souhaité
 KEYCLOAK_PASSWORD: MotDePasseTresSecure
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 networks:
 - net
 # Réseau utilisé par le conteneur traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Modifier le domaine de l'application keyclaok
 - traefik.http.routers.keycloak-http.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak-http.entrypoints=http
 - traefik.http.routers.keycloak-http.middlewares=https-redirect
 - traefik.http.routers.keycloak-https.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak-https.entrypoints=https
 - traefik.http.routers.keycloak-https.tls=true
 - traefik.http.routers.keycloak-https.tls.certresolver=le
 # Indiquer le port utiliser de l'application
 - traefik.http.services.keycloak.loadbalancer.server.port=8080

networks:
 net:
 driver: overlay
 attachable: true
 traefik-public:
 external: true

volumes:
 postgres_data:
 driver: local

Déploiement

docker stack deploy -c stack.yml keycloak

Docker Swarm : Stack Rocket.Chat

Thu, 18 Aug 2022 11:34:33 +0200

Informations importantes

Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Fichier stack.yml

version: '3.3'

services:

 rocketchat:
 image: registry.rocket.chat/rocketchat/rocket.chat:latest
 environment:
 MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
 MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
 # Modifier l'URL d'accès à l'application RocketChat
 ROOT_URL: https://rocketchat.example.com
 PORT: 3000
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 - uploads:/app/uploads
 networks:
 - net
 # Réseau utilisé par le conteneur traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph)
 - node.labels.rocketchat_uploads == true
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Modifier le domaine de l'application RocketChat
 - traefik.http.routers.rocketchat-http.rule=Host(`rocketchat.example.com`)
 - traefik.http.routers.rocketchat-http.entrypoints=http
 - traefik.http.routers.rocketchat-http.middlewares=https-redirect
 # Modifier le domaine de l'application RocketChat
 - traefik.http.routers.rocketchat-https.rule=Host(`rocketchat.example.com`)
 - traefik.http.routers.rocketchat-https.entrypoints=https
 - traefik.http.routers.rocketchat-https.tls=true
 - traefik.http.routers.rocketchat-https.tls.certresolver=le
 - traefik.http.services.rocketchat.loadbalancer.server.port=3000

 mongodb:
 image: docker.io/bitnami/mongodb:4.4
 environment:
 MONGODB_REPLICA_SET_MODE: primary
 MONGODB_REPLICA_SET_NAME: rs0
 MONGODB_PORT_NUMBER: 27017
 MONGODB_INITIAL_PRIMARY_HOST: mongodb
 MONGODB_INITIAL_PRIMARY_PORT_NUMBER: 27017
 MONGODB_ADVERTISED_HOSTNAME: mongodb
 MONGODB_ENABLE_JOURNAL: "true"
 ALLOW_EMPTY_PASSWORD: "yes"
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 - mongodb_data:/bitnami/mongodb
 networks:
 - net
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph)
 - node.labels.rocketchat_mongodb_data == true

networks:
 net:
 driver: overlay
 attachable: true
 # Réseau utilisé par le conteneur traefik
 traefik-public:
 external: true

volumes:
 mongodb_data:
 driver: local
 uploads:
 driver: local

Deploiement

docker stack deploy -c stack.yml rocketchat

Docker Swarm : Stack Traefik

Thu, 18 Aug 2022 11:28:10 +0200

Export variables

export EMAIL=mon@email.com
export DOMAIN=traefik.example.com
export USERNAME=admin
export PASSWORD=MotDePasseTresSecure
export HASHED_PASSWORD=$(openssl passwd -apr1 "$PASSWORD")

Fichier stack.yml

version: '3.3'

services:

 traefik:
 # Use the latest Traefik image
 image: traefik:latest
 ports:
 # Listen on port 80, default for HTTP, necessary to redirect to HTTPS
 - target: 80
 published: 80
 mode: host
 # Listen on port 443, default for HTTPS
 - target: 443
 published: 443
 mode: host
 deploy:
 placement:
 constraints:
 # Make the traefik service run only on the node with this label
 # as the node with it has the volume for the certificates
 - node.labels.traefik-public.traefik-public-certificates == true
 labels:
 # Enable Traefik for this service, to make it available in the public network
 - traefik.enable=true
 # Use the traefik-public network (declared below)
 - traefik.docker.network=traefik-public
 # Use the custom label "traefik.constraint-label=traefik-public"
 # This public Traefik will only use services with this label
 # That way you can add other internal Traefik instances per stack if needed
 - traefik.constraint-label=traefik-public
 # admin-auth middleware with HTTP Basic auth
 # Using the environment variables USERNAME and HASHED_PASSWORD
 - traefik.http.middlewares.admin-auth.basicauth.users=${USERNAME?Variable not set}:${HASHED_PASSWORD?Variable not set}
 # https-redirect middleware to redirect HTTP to HTTPS
 # It can be re-used by other stacks in other Docker Compose files
 - traefik.http.middlewares.https-redirect.redirectscheme.scheme=https
 - traefik.http.middlewares.https-redirect.redirectscheme.permanent=true
 # traefik-http set up only to use the middleware to redirect to https
 # Uses the environment variable DOMAIN
 - traefik.http.routers.traefik-public-http.rule=Host(`${DOMAIN?Variable not set}`)
 - traefik.http.routers.traefik-public-http.entrypoints=http
 - traefik.http.routers.traefik-public-http.middlewares=https-redirect
 # traefik-https the actual router using HTTPS
 # Uses the environment variable DOMAIN
 - traefik.http.routers.traefik-public-https.rule=Host(`${DOMAIN?Variable not set}`)
 - traefik.http.routers.traefik-public-https.entrypoints=https
 - traefik.http.routers.traefik-public-https.tls=true
 # Use the special Traefik service api@internal with the web UI/Dashboard
 - traefik.http.routers.traefik-public-https.service=api@internal
 # Use the "le" (Let's Encrypt) resolver created below
 - traefik.http.routers.traefik-public-https.tls.certresolver=le
 # Enable HTTP Basic auth, using the middleware created above
 - traefik.http.routers.traefik-public-https.middlewares=admin-auth
 # Define the port inside of the Docker service to use
 - traefik.http.services.traefik-public.loadbalancer.server.port=8080
 volumes:
 # Add Docker as a mounted volume, so that Traefik can read the labels of other services
 - /var/run/docker.sock:/var/run/docker.sock:ro
 # Mount the volume to store the certificates
 - traefik-public-certificates:/certificates
 command:
 # Enable Docker in Traefik, so that it reads labels from Docker services
 - --providers.docker
 # Add a constraint to only use services with the label "traefik.constraint-label=traefik-public"
 - --providers.docker.constraints=Label(`traefik.constraint-label`, `traefik-public`)
 # Do not expose all Docker services, only the ones explicitly exposed
 - --providers.docker.exposedbydefault=false
 # Enable Docker Swarm mode
 - --providers.docker.swarmmode
 # Create an entrypoint "http" listening on address 80
 - --entrypoints.http.address=:80
 # Create an entrypoint "https" listening on address 443
 - --entrypoints.https.address=:443
 # Create the certificate resolver "le" for Let's Encrypt, uses the environment variable EMAIL
 - --certificatesresolvers.le.acme.email=${EMAIL?Variable not set}
 # Store the Let's Encrypt certificates in the mounted volume
 - --certificatesresolvers.le.acme.storage=/certificates/acme.json
 # Use the TLS Challenge for Let's Encrypt
 - --certificatesresolvers.le.acme.tlschallenge=true
 # Enable the access log, with HTTP requests
 - --accesslog
 # Enable the Traefik log, for configurations and errors
 - --log
 # Enable the Dashboard and API
 - --api
 # Set CA Server fir Let's Encrypt
 # - --certificatesresolvers.le.acme.caServer=
 networks:
 # Use the public network created to be shared between Traefik and
 # any other service that needs to be publicly available with HTTPS
 - traefik-public

volumes:
 # Create a volume to store the certificates, there is a constraint to make sure
 # Traefik is always deployed to the same Docker node with the same volume containing
 # the HTTPS certificates
 traefik-public-certificates:

networks:
 # Use the previously created public network "traefik-public", shared with other
 # services that need to be publicly available via this Traefik
 traefik-public:
 external: true

Déploiement

docker stack deploy -c stack.yml traefik

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

Docker-Compose : Portainer Server

Sat, 13 Aug 2022 17:53:08 +0200

docker-compose.yml

version: '3'

services:
 portainer:
 image: portainer/portainer-ce:latest
 container_name: portainer_server
 restart: unless-stopped
 security_opt:
 - no-new-privileges:true
 volumes:
 - /etc/localtime:/etc/localtime:ro
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - ./portainer-data:/data
 ports:
 # Only to http
 # - 9000:9000
 # Only to Edge Agent
 # - 8000:8000
 # Only to https
 - 9443:9443

Docker-Compose : Tactical RMM

Mon, 13 Dec 2021 11:56:12 +0100

docker-compose.yml

version: "3.7"

# networks
networks:
 proxy:
 driver: bridge
 ipam:
 driver: default
 config:
 - subnet: 172.20.0.0/24
 api-db: null
 redis: null
 mesh-db: null # docker managed persistent volumes

volumes:
 tactical_data: null
 postgres_data: null
 mongo_data: null
 mesh_data: null
 redis_data: null

services:
 # postgres database for api service
 tactical-postgres:
 container_name: trmm-postgres
 image: postgres:13-alpine
 restart: always
 environment:
 POSTGRES_DB: tacticalrmm
 POSTGRES_USER: ${POSTGRES_USER}
 POSTGRES_PASSWORD: ${POSTGRES_PASS}
 volumes:
 - ./postgres_data:/var/lib/postgresql/data
 networks:
 - api-db

 # redis container for celery tasks
 tactical-redis:
 container_name: trmm-redis
 image: redis:6.0-alpine
 command: redis-server --appendonly yes
 restart: always
 volumes:
 - ./redis_data:/data
 networks:
 - redis

 # used to initialize the docker environment
 tactical-init:
 container_name: trmm-init
 image: ${IMAGE_REPO}tactical:${VERSION}
 restart: on-failure
 command: [ "tactical-init" ]
 environment:
 POSTGRES_USER: ${POSTGRES_USER}
 POSTGRES_PASS: ${POSTGRES_PASS}
 APP_HOST: ${APP_HOST}
 API_HOST: ${API_HOST}
 MESH_USER: ${MESH_USER}
 MESH_HOST: ${MESH_HOST}
 TRMM_USER: ${TRMM_USER}
 TRMM_PASS: ${TRMM_PASS}
 depends_on:
 - tactical-postgres
 - tactical-meshcentral
 networks:
 - api-db
 - proxy
 volumes:
 - ./tactical_data:/opt/tactical

 # nats
 tactical-nats:
 container_name: trmm-nats
 image: ${IMAGE_REPO}tactical-nats:${VERSION}
 restart: always
 environment:
 API_HOST: ${API_HOST}
 ports:
 - "4222:4222"
 volumes:
 - ./tactical_data:/opt/tactical
 networks:
 api-db: null
 proxy:
 aliases:
 - ${API_HOST}
 default:

 # meshcentral container
 tactical-meshcentral:
 container_name: trmm-meshcentral
 image: ${IMAGE_REPO}tactical-meshcentral:${VERSION}
 restart: always
 environment:
 MESH_HOST: ${MESH_HOST}
 MESH_USER: ${MESH_USER}
 MESH_PASS: ${MESH_PASS}
 MONGODB_USER: ${MONGODB_USER}
 MONGODB_PASSWORD: ${MONGODB_PASSWORD}
 MESH_PERSISTENT_CONFIG: ${MESH_PERSISTENT_CONFIG}
 networks:
 proxy:
 aliases:
 - ${MESH_HOST}
 mesh-db: null
 volumes:
 - ./tactical_data:/opt/tactical
 - ./mesh_data:/home/node/app/meshcentral-data
 depends_on:
 - tactical-mongodb

 # mongodb container for meshcentral
 tactical-mongodb:
 container_name: trmm-mongodb
 image: mongo:4.4
 restart: always
 environment:
 MONGO_INITDB_ROOT_USERNAME: ${MONGODB_USER}
 MONGO_INITDB_ROOT_PASSWORD: ${MONGODB_PASSWORD}
 MONGO_INITDB_DATABASE: meshcentral
 networks:
 - mesh-db
 volumes:
 - ./mongo_data:/data/db

 # container that hosts vue frontend
 tactical-frontend:
 container_name: trmm-frontend
 image: ${IMAGE_REPO}tactical-frontend:${VERSION}
 restart: always
 networks:
 - proxy
 environment:
 API_HOST: ${API_HOST}

 # container for django backend
 tactical-backend:
 container_name: trmm-backend
 image: ${IMAGE_REPO}tactical:${VERSION}
 command: [ "tactical-backend" ]
 restart: always
 networks:
 - proxy
 - api-db
 - redis
 volumes:
 - ./tactical_data:/opt/tactical
 depends_on:
 - tactical-postgres

 # container for django websockets connections
 tactical-websockets:
 container_name: trmm-websockets
 image: ${IMAGE_REPO}tactical:${VERSION}
 command: [ "tactical-websockets" ]
 restart: always
 networks:
 - proxy
 - api-db
 - redis
 volumes:
 - ./tactical_data:/opt/tactical
 depends_on:
 - tactical-postgres
 - tactical-backend

 # container for tactical reverse proxy
 tactical-nginx:
 container_name: trmm-nginx
 image: ${IMAGE_REPO}tactical-nginx:${VERSION}
 restart: always
 environment:
 APP_HOST: ${APP_HOST}
 API_HOST: ${API_HOST}
 MESH_HOST: ${MESH_HOST}
 CERT_PUB_KEY: ${CERT_PUB_KEY}
 CERT_PRIV_KEY: ${CERT_PRIV_KEY}
 networks:
 proxy:
 ipv4_address: 172.20.0.20
 ports:
 - "8010:80"
 - "8011:443"
 volumes:
 - ./tactical_data:/opt/tactical

 # container for celery worker service
 tactical-celery:
 container_name: trmm-celery
 image: ${IMAGE_REPO}tactical:${VERSION}
 command: [ "tactical-celery" ]
 restart: always
 networks:
 - redis
 - proxy
 - api-db
 volumes:
 - ./tactical_data:/opt/tactical
 depends_on:
 - tactical-postgres
 - tactical-redis

 # container for celery beat service
 tactical-celerybeat:
 container_name: trmm-celerybeat
 image: ${IMAGE_REPO}tactical:${VERSION}
 command: [ "tactical-celerybeat" ]
 restart: always
 networks:
 - proxy
 - redis
 - api-db
 volumes:
 - ./tactical_data:/opt/tactical
 depends_on:
 - tactical-postgres
 - tactical-redis

.env

IMAGE_REPO=tacticalrmm/
VERSION=latest

# tactical credentials (Used to login to dashboard)
TRMM_USER=tacticalrmm
TRMM_PASS=password

# dns settings
APP_HOST=rmm.example.com
API_HOST=api.example.com
MESH_HOST=mesh.example.com

# mesh settings
MESH_USER=tacticalrmm
MESH_PASS=password
MONGODB_USER=mongouser
MONGODB_PASSWORD=password
MESH_PERSISTENT_CONFIG=0

# database settings
POSTGRES_USER=postgres
POSTGRES_PASS=password

certificates

echo -e "\n# certs" >> .env
echo "CERT_PUB_KEY=$(base64 -w 0 /path/to/fullchain.pem)" >> .env
echo "CERT_PRIV_KEY=$(base64 -w 0 /path/to/privkey.pem)" >> .env

Docker-Compose : RocketChat

Mon, 13 Dec 2021 11:48:02 +0100

docker-compose.yml

version: '2'

services:
 rocketchat:
 image: registry.rocket.chat/rocketchat/rocket.chat:latest
 container_name: rocketchat
 command: >
 bash -c
 "for i in `seq 1 30`; do
 node main.js &&
 s=$$? && break || s=$$?;
 echo \"Tried $$i times. Waiting 5 secs...\";
 sleep 5;
 done; (exit $$s)"
 restart: unless-stopped
 volumes:
 - ./uploads:/app/uploads
 environment:
 - PORT=3000
 - ROOT_URL=https://rocketchat.example.com
 - MONGO_URL=mongodb://mongo:27017/rocketchat
 - MONGO_OPLOG_URL=mongodb://mongo:27017/local
# - MAIL_URL=smtp://smtp.email
# - HTTP_PROXY=http://proxy.domain.com
# - HTTPS_PROXY=http://proxy.domain.com
 depends_on:
 - mongo
 ports:
 - 3000:3000
 labels:
 - "traefik.backend=rocketchat"
 - "traefik.frontend.rule=Host: your.domain.tld"

 mongo:
 image: mongo:4.0
 container_name: rocketchat_mongo
 restart: unless-stopped
 volumes:
 - ./data/db:/data/db
 #- ./data/dump:/dump
 command: mongod --smallfiles --oplogSize 128 --replSet rs0 --storageEngine=mmapv1
 labels:
 - "traefik.enable=false"

 # this container's job is just run the command to initialize the replica set.
 # it will run the command and remove himself (it will not stay running)
 mongo-init-replica:
 image: mongo:4.0
 command: >
 bash -c
 "for i in `seq 1 30`; do
 mongo mongo/rocketchat --eval \"
 rs.initiate({
 _id: 'rs0',
 members: [ { _id: 0, host: 'localhost:27017' } ]})\" &&
 s=$$? && break || s=$$?;
 echo \"Tried $$i times. Waiting 5 secs...\";
 sleep 5;
 done; (exit $$s)"
 depends_on:
 - mongo

 # hubot, the popular chatbot (add the bot user first and change the password before starting this image)
 hubot:
 image: rocketchat/hubot-rocketchat:latest
 restart: unless-stopped
 environment:
 - ROCKETCHAT_URL=rocketchat:3000
 - ROCKETCHAT_ROOM=GENERAL
 - ROCKETCHAT_USER=bot
 - ROCKETCHAT_PASSWORD=password
 - BOT_NAME=bot
 # you can add more scripts as you'd like here, they need to be installable by npm
 - EXTERNAL_SCRIPTS=hubot-help,hubot-seen,hubot-links,hubot-diagnostics
 depends_on:
 - rocketchat
 labels:
 - "traefik.enable=false"
 volumes:
 - ./scripts:/home/hubot/scripts
 # this is used to expose the hubot port for notifications on the host on port 3001, e.g. for hubot-jenkins-notifier
 ports:
 - 3001:8080

 #traefik:
 # image: traefik:latest
 # restart: unless-stopped
 # command: >
 # traefik
 # --docker
 # --acme=true
 # --acme.domains='your.domain.tld'
 # --acme.email='your@email.tld'
 # --acme.entrypoint=https
 # --acme.storagefile=acme.json
 # --defaultentrypoints=http
 # --defaultentrypoints=https
 # --entryPoints='Name:http Address::80 Redirect.EntryPoint:https'
 # --entryPoints='Name:https Address::443 TLS.Certificates:'
 # ports:
 # - 80:80
 # - 443:443
 # volumes:
 # - /var/run/docker.sock:/var/run/docker.sock

Docker-Compose : qBittorrent

Mon, 13 Dec 2021 11:44:54 +0100

docker-compose.yml

qbittorrent:
 image: gists/qbittorrent
 container_name: qbittorrent
 ports:
 - "8080:8080"
 - "6881:6881"
 - "6881:6881/udp"
 volumes:
 - ./data:/data
 environment:
 - UID=1000
 - GID=1000
 restart: unless-stopped

Docker-Compose : Pi-Hole

Mon, 13 Dec 2021 11:43:04 +0100

docker-compose.yml

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
 pihole:
 container_name: pihole
 image: pihole/pihole:latest
 ports:
 - "53:53/tcp"
 - "53:53/udp"
 - "67:67/udp"
 - "8085:80/tcp"
 environment:
 TZ: 'Europe/Paris'
 WEBPASSWORD: "password"
 # Volumes store your data between container upgrades
 volumes:
 - './etc-pihole/:/etc/pihole/'
 - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
 # Recommended but not required (DHCP needs NET_ADMIN)
 # https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
 cap_add:
 - NET_ADMIN
 restart: unless-stopped

Docker-Compose : Nginx Proxy Manager

Mon, 13 Dec 2021 11:41:08 +0100

docker-compose.yml

version: '3'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 container_name: npm
 restart: unless-stopped
 ports:
 - '80:80'
 - '8082:81'
 - '443:443'
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt

Credentials

Email: admin@example.com
Password: changeme

Docker-Compose : Nextcloud

Mon, 13 Dec 2021 11:37:28 +0100

docker-compose.yml

version: '2'

services:
 db:
 image: mariadb
 container_name: nextcloud_mariadb
 restart: unless-stopped
 command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --skip-innodb-read-only-compressed
 volumes:
 - ./db:/var/lib/mysql
 environment:
 - MYSQL_ROOT_PASSWORD=password
 - MYSQL_PASSWORD=password
 - MYSQL_DATABASE=nextcloud
 - MYSQL_USER=nextcloud
 - APACHE_DISABLE_REWRITE_IP=1
 - TRUSTED_PROXIES=172.16.0.10 # Si reverse proxy, mettre son IP sinon commenter la ligne

 app:
 image: nextcloud
 container_name: nextcloud
 restart: unless-stopped
 ports:
 - 8084:80
 links:
 - db
 volumes:
 - ./nextcloud:/var/www/html
 environment:
 - MYSQL_PASSWORD=password
 - MYSQL_DATABASE=nextcloud
 - MYSQL_USER=nextcloud
 - MYSQL_HOST=db
 - APACHE_DISABLE_REWRITE_IP=1
 - TRUSTED_PROXIES=172.16.0.10 # Si reverse proxy, mettre son IP sinon commenter la ligne

Docker-Compose : Netdata

Mon, 13 Dec 2021 11:33:45 +0100

docker-compose.yml

version: '3'
services:
 netdata:
 image: netdata/netdata
 container_name: netdata
 hostname: HOSTNAME # set to fqdn of host
 ports:
 - 19999:19999
 restart: unless-stopped
 cap_add:
 - SYS_PTRACE
 security_opt:
 - apparmor:unconfined
 volumes:
 - ./netdataconfig/netdata:/etc/netdata:ro
 - netdatalib:/var/lib/netdata
 - netdatacache:/var/cache/netdata
 - /etc/passwd:/host/etc/passwd:ro
 - /etc/group:/host/etc/group:ro
 - /proc:/host/proc:ro
 - /sys:/host/sys:ro
 - /etc/os-release:/host/etc/os-release:ro

volumes:
 netdatalib:
 netdatacache:

Docker-Compose : Keycloak

Mon, 13 Dec 2021 11:30:58 +0100

docker-compose.yml

version: '3.3'

services:
 postgres:
 restart: unless-stopped
 image: postgres
 container_name: keycloak_postgres
 volumes:
 - ./postgres_data:/var/lib/postgresql/data
 environment:
 POSTGRES_DB: keycloak
 POSTGRES_USER: keycloak
 POSTGRES_PASSWORD: password
 keycloak:
 container_name: keycloak
 restart: unless-stopped
 image: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 DB_PASSWORD: password
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: password
 ports:
 - 8083:8080
 depends_on:
 - postgres

Docker-Compose : Dashy

Mon, 13 Dec 2021 11:27:42 +0100

docker-compose.yml

version: "3"
services:
 dashy:
 # To build from source, replace 'image: lissy93/dashy' with 'build: .'
 # build: .
 image: lissy93/dashy
 container_name: dashy
 # Pass in your config file below, by specifying the path on your host machine
 volumes:
 - ./my-config.yml:/app/public/conf.yml
 ports:
 - 8081:80
 # Set any environmental variables
 environment:
 - NODE_ENV=production
 # Specify your user ID and group ID. You can find this by running `id -u` and `id -g`
 - UID=1000
 - GID=1000
 # Specify restart policy
 restart: unless-stopped
 # Configure healthchecks
 healthcheck:
 test: ['CMD', 'node', '/app/services/healthcheck']
 interval: 1m30s
 timeout: 10s
 retries: 3
 # start_period: 40s

Docker on slash-root.fr

Docker : Metrics port 9323

Comprendre l’option metrics-addr

Pourquoi le port 9323 ?

Ce que vous obtenez avec metrics-addr

Cas d’utilisation pour metrics-addr

Configuration de metrics-addr

Configuration via daemon.json

Visualisation simple avec Docker Stats

Les limites à connaître

Bonnes pratiques

En résumé

Solutions avancées (Annexe)

1. Intégration avec Prometheus

2. Utilisation de cAdvisor

Docker : live-restore, c’est quoi ?

Le problème : Sans live-restore

La solution : Comment fonctionne live-restore ?

Quand utiliser live-restore ?

Comment l’activer ?

Les limites à connaître

Bonnes pratiques

En résumé

Docker : Configuration et gestion des logs

Comprendre les logs dans Docker

Configuration du pilote de logs par défaut

Les différents pilotes de logs

Configuration par conteneur

Bonnes pratiques pour la gestion des logs

Conclusion

Docker : Configuration et gestion du stockage

Comprendre le stockage dans Docker

Configuration du pilote de stockage

Les différents pilotes de stockage

Déplacer le répertoire de données Docker

Volumes bind déguisés : la technique du ninja du stockage

Nettoyage de l’espace disque

Bonnes pratiques pour la gestion du stockage

Conclusion

Docker : Configuration des réseaux par défaut

Les réseaux Docker par défaut

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

Incrémentation automatique des réseaux Docker

Les différents types de réseaux Docker

Dans un Docker Engine standalone

Dans un cluster Docker Swarm

Le réseau Ingress et la plage 10.0.0.0/8

Reconfiguration du réseau Ingress

Bonnes pratiques pour la gestion des réseaux Docker

Conclusion

Déployer une application sur Kubernetes

Introduction

Préparation

La cible

L’existant

La migration

Construction

Conclusion

Docker-Compose : Mise à jour manuelle des images

Pré-requis

Étapes pour la mise à jour

Télécharger les images mises à jour

Redémarrer les conteneurs avec les nouvelles images

Nettoyer les images obsolètes

Docker-Compose : WordPress (MariaDB)

Le fichier docker-compose.yml

Directory

Execution

Docker : Volume bind déguisé

Création du volume docker

Utilisation du volume docker

Avec docker run

Avec docker compose

Portainer

Watch Tower : Auto update docker images

Présentation

Installation

Exécution

Docker-Compose : Drawio

Le fichier docker-compose.yml