Name: Tremplin Numérique
Price range: $$$

Vous débutez Docker et vous le trouvez un peu écrasant ? Les commandes peuvent être lourdes et les meilleures pratiques ne sont pas clairement énoncées. J'ai trois choses que j'aurais aimé savoir lors du démarrage de Docker, et qui pourraient vous aider.

Les grands projets logiciels comme Docker cachent souvent des bonnes pratiques et des avertissements cruciaux au cœur de la documentation technique. Les débutants sont confrontés à un déluge de détails techniques mais à peu de directives claires et concises pour les aider à tracer leur parcours d’apprentissage. Lorsque j'ai commencé, je ne comprenais pas comment gérer plusieurs services dépendants, gérer des commandes complexes ou les dangers précis liés à l'exécution de processus conteneurisés en tant que root. Si ces détails cruciaux avaient été clairement définis, j’aurais pu gagner beaucoup de temps et éviter des erreurs potentiellement coûteuses.

Sommaire

Ne pas utiliser Docker Compose pour les configurations multiservices

Docker est bien connu pour exécuter des services conteneurisés uniques ; vous lui fournissez une commande et les options nécessaires, et il exécutera votre service. Mais ce qui est peut-être moins connu des débutants, c'est qu'il peut coordonner plusieurs services ensemble à l'aide de Docker Compose. Docker Compose peut rendre l'extraction et la configuration d'un ou plusieurs services beaucoup plus simples, surtout s'ils dépendent les uns des autres.

Docker Compose est en fait une sous-commande de Docker et nécessite un fichier de configuration YAML (appelé docker-compose.yaml) pour spécifier les services. Ce qui suit est un extrait de la documentation officielle de Gitea (un serveur Git) :

# docker-compose.yaml
volumes:
  postgres-data:
  gitea-data:

services:
  server:
    image: docker.gitea.com/gitea:nightly
    volumes:
      - gitea-data:/data
    depends_on:
      - db

  db:
    image: docker.io/library/postgres:14
    volumes:
      - postgres-data:/var/lib/postgresql/data

L'exemple précédent utilise la version nocturne (instable, de développement) de Gitea, qui a fonctionné en novembre 2025, mais il se peut qu'elle ne fonctionne pas avec Postgres 14 à un moment donné dans le futur. Le fichier YAML est uniquement destiné à des fins de démonstration.

L'exemple précédent demande à Docker de créer deux services, l'un « dépend_de » l'autre. C'est un exemple non fonctionnel car il lui manque cruellement certaines options. Cependant, l'exemple suivant est entièrement fonctionnel.

# docker-compose.yaml
networks:
  gitea:
    external: false

volumes:
  postgres-data:
  gitea-data:

services:
  server:
    image: docker.gitea.com/gitea:nightly
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=gitea
      - TZ=America/New_York
    restart: always
    networks:
      - gitea
    volumes:
      - gitea-data:/data
    ports:
      - "3000:3000"
      - "2222:22"
    depends_on:
      - db

  db:
    image: docker.io/library/postgres:14
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=gitea
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - postgres-data:/var/lib/postgresql/data

Il y a plusieurs éléments à noter dans ce fichier Compose :

Les variables d'environnement fournissent des options de configuration pour chaque service, par exemple, créer des informations d'identification pour la base de données et donner ces informations d'identification à Gitea.
Le service Gitea stocke les données du référentiel dans le répertoire /data du conteneur, et nous les montons en tant que volume persistant sur l'hôte.
Le service Postgres stocke les données dans le répertoire /var/lib/postgresql/data du conteneur, et nous les montons en tant que volume persistant sur l'hôte.

Un volume persistant stocke les données en dehors du conteneur, dans /var/lib/docker/volumes.

Maintenant, accédez au répertoire contenant le fichier docker-compose.yaml et exécutez Docker compose. Docker extraira ensuite les images nécessaires et démarrera les deux services, qui fonctionneront ensemble de manière transparente. L'utilisation de Docker Compose simplifie le processus de spécification d'une pile complexe d'applications, le rendant plus simple et plus simple que l'écriture d'un script Bash.

Exécuter des processus conteneurisés en tant que root

Lorsque j'ai commencé à utiliser Docker, je pensais simplement que les conteneurs étaient complètement isolés ; que l'exécution d'un processus root dans un conteneur signifiait qu'il ne pouvait pas faire de mal. J'ai eu tort.

Par défaut, les processus exécutés dans les conteneurs Docker partagent le même espace de noms UID avec l'hôte. Si vous exécutez un processus racine dans un conteneur, il a l'UID 0 sur l'hôte mais avec des capacités restreintes. Cependant, cela crée toujours un risque de sécurité sérieux, car les attaquants pourraient exploiter les vulnérabilités pour sortir du conteneur et obtenir un accès root à la machine hôte.

Les processus isolés sur localhost ne sont pas non plus entièrement exempts de risques. Si vos applications conteneurisées traitent des données externes de quelque manière que ce soit (par exemple, surveillance du réseau, lecture de documents, réception de trafic, etc.), votre système est alors exposé à des données malveillantes et à une éventuelle exploitation. Au minimum, vous devez traiter les conteneurs root comme s'il s'agissait de processus au niveau racine et éviter complètement les actions risquées avec eux.

La solution consiste à exécuter Docker en mode sans racine. Si vous suivez les étapes fournies dans la documentation de Docker, l'exécution d'un processus au niveau racine à l'intérieur du conteneur doit le mapper à un utilisateur non privilégié sur l'hôte. La même chose s'applique également au démon Docker : les deux exécutent des processus sans véritables privilèges root.

Si vous ne souhaitez pas faire cela, vous devez au moins exécuter des processus avec l'indicateur –user ou une directive USER dans votre Dockerfile. Cependant, cela s'avère parfois insuffisant, car votre processus conteneurisé doit modifier les zones protégées à l'intérieur du conteneur.

Personnellement, j'utilise Podman au lieu de Docker car il exécute par défaut des conteneurs en tant qu'utilisateurs non privilégiés. Podman remplace Docker, est 100 % compatible avec celui-ci et il existe également un bureau Podman. Je recommande vivement Podman.

Ne pas utiliser d'interface utilisateur, de complétions de shell ou d'alias

Les commandes Docker peuvent être longues et si vous êtes comme moi, vous les exécutez souvent. Cela conduit à un scénario dans lequel la saisie de dizaines de commandes interrompt votre flux de travail.

Prenez, par exemple, la commande Pi-hole (comme suggéré par la documentation officielle) :

docker run 
  --name pihole 
  -p 53:53/tcp 
  -p 53:53/udp 
  -p 80:80/tcp 
  -p 443:443/tcp 
  -e TZ=Europe/London 
  -e FTLCONF_webserver_api_password="correct horse battery staple" 
  -e FTLCONF_dns_listeningMode=all 
  -v ./etc-pihole:/etc/pihole 
  -v ./etc-dnsmasq.d:/etc/dnsmasq.d 
  --cap-add NET_ADMIN 
  --restart unless-stopped 
  pihole/pihole:latest

En réalité, pour exécuter cette commande, vous utiliserez soit Docker Compose, soit un service systemd. Cependant, les commandes Docker sont souvent lourdes, et c'est indéniable.

Pour gérer ces commandes longues, nous disposons de trois options : une interface utilisateur (UI), des complétions de shell et des alias.

Une interface utilisateur est ma préférée, et bien que Docker Desktop soit souvent recommandé, je préfère personnellement une interface utilisateur de terminal : lazydocker. Les deux sont d’excellents choix, et le premier convient mieux à la plupart. Cependant, si vous comptez beaucoup sur les raccourcis clavier, essayez lazydocker.

Néanmoins, il y aura des moments où vous devrez exécuter directement les commandes Docker. Avec les complétions du shell, il est non seulement simple de choisir des options, mais également de choisir des noms de conteneurs : tapez votre commande Docker et appuyez sur la touche Tab lorsque vous souhaitez qu'elle fournisse une liste d'options parmi lesquelles choisir.

Les alias sont un autre excellent choix, à la fois à l’intérieur et à l’extérieur d’un conteneur. Vous pouvez mapper les alias Docker sur votre hôte ou mapper les alias de service à l'intérieur d'un conteneur. Le premier permet de raccourcir les commandes Docker ; ce dernier permet d'exécuter le contenu d'un conteneur de manière plus expressive.

Docker n'est pas aussi simple qu'on le pense. Il est excellent pour emballer un outil ou un service, mais il comporte des pièges et peut être difficile à utiliser. Lorsque j'ai commencé à utiliser Docker, ces conseils n'étaient pas immédiatement disponibles, je les mets donc à votre disposition. Essentiellement:

Utilisez Docker Compose pour les configurations complexes.
Assurez-vous d’exécuter les processus en tant qu’utilisateur limité.
Utilisez des outils pour faciliter l'administration de Docker.