Docker Gerer le demarrage automatique des conteneurs
  • 13 août 2025
  • ComputaSYS
  • 0


I. Présentation

Dans ce tutoriel, nous allons voir comment désactiver et gérer l’auto-démarrage des conteneurs Docker au démarrage de l’hôte.

Si vous utilisez souvent Docker pour des tests, pour apprendre ou même à plus grande échelle, vous avez surement remarqué que certains de vos conteneurs Docker se lancent au démarrage de votre hôte. Cela peut être ce que vous souhaitez s’il s’agit d’un environnement de production dédié à l’exécution de conteneurs. Cependant, dans certains cas, le démarrage automatique des conteneurs peut avoir plusieurs impacts négatifs et non souhaités : 

Consommation inutile de ressources : les conteneurs lancés exécutent des processus et même s’ils ne sont pas sollicités activement, consomment des ressources de l’hôte.

Sécurité : en fonction des configurations de vos conteneurs, ceux-ci peuvent exposer des services sur le réseau. S’ils ne sont pas sécurisés, ils peuvent ouvrir des accès non désirés à votre hôte sans que vous le sachiez.

Nous allons voir comment rapidement vérifier la configuration de vos conteneurs Docker et activer ou désactiver le lancement automatique de ces derniers.

II. Docker : qu’est-ce que la restart policy ?

Sous Docker, la restart policy est la politique (ou configuration) qui concerne les conditions de démarrage et redémarrage d’un conteneur. Avant tout, elle permet de gérer le comportement d’un conteneur en cas de crash de ce dernier ou de (re)démarrage du service Docker lui-même.

Au lancement manuel d’un conteneur, la restart policy est par défaut à no, cela signifie qu’un conteneur Docker n’est pas configuré pour démarrer automatiquement au démarrage de l’hôte ou du service Docker. Les valeurs existantes pour l’option qui gère cette politique sont les suivantes : 

no 

on-failure [nombre maximal de tentatives]

always

unless-stopped

Ces différentes valeurs possibles sont assez explicites. On soulignera juste que le on-failure indique que le conteneur doit redémarrer uniquement en cas d’erreur (crash) et le unless-stopped est similaire à always (toujours) sauf s’il s’agit d’un arrêt intentionnel du conteneur par l’utilisateur.

Si vous observez un conteneur qui se lance au démarrage du service Docker (et donc de l’hôte qui l’exécute), c’est qu’il a été explicitement configuré pour le faire lors de sa création. Si vous êtes passé par un fichier docker-compose.yml (commande docker compose), vous trouverez surement une instruction telle que celle-ci à l’intérieur : 

# Exemple du contenu d’un fichier docker-compose.yml
$ cat docker-compose.yml 

version: “3”
services:
  database:
    image: postgres:11.6-alpine
    restart: always
  wordpress:
    image: wordpress
    depends_on:
      – database
    ports:
      – “80:80”
    restart: always

Ici, mes deux conteneurs sont configurés pour démarrer au lancement du service Docker, ce qui revient à les avoir lancés avec les options suivantes : 

# Equivalent en one-line du contenu d’un fichier docker-compose.yml
docker run -d –name database –restart always postgres:11.6-alpine
docker run -d –name wordpress –restart always -p 80:80 –link database wordpress

Pour en savoir plus sur les détails et les subtilités de cette politique de redémarrage, je vous oriente vers la Documentation officielle Docker :

III. Gérer la restart policy d’un conteneur Docker

A. Relever la restart policy avec docker inspect

Dans un premier temps, relevons la liste de nos conteneurs (actifs ou stoppés) :

# Lister les conteneurs Docker
$ docker ps -a

CONTAINER ID   IMAGE                     COMMAND                  CREATED       STATUS                     NAMES
da66d4c7152e   postgres:11.6-alpine      “docker-entrypoint.s…”   5 days ago    Up 23 minutes              database-1
b629cc6c176e   docker.n8n.io/n8nio/n8n   “tini — /docker-ent…”   4 weeks ago   Exited (137) 9 days ago    n8n-n8n-1
9ceeeb84e738   traefik                   “/entrypoint.sh –ap…”   4 weeks ago   Exited (0) 9 days ago      n8n-traefik-1

J’en ai ici trois, notez bien les ID des conteneurs que vous souhaitez traiter. Nous allons ensuite utiliser docker inspect pour relever un paramètre précis de ces derniers : la politique de redémarrage. 

# Vérifier la valeur du paramètre RestartPolicy d’un conteneur
$ docker inspect -f ‘{{.HostConfig.RestartPolicy.Name}}’ da66d4c7152e 
always

$ docker inspect -f ‘{{.HostConfig.RestartPolicy.Name}}’ b629cc6c176e 
no

$ docker inspect -f ‘{{.HostConfig.RestartPolicy.Name}}’ 9ceeeb84e738 
no

Le résultat est assez clair. Parmi mes 3 conteneurs Docker, deux sont à no et un à always. Le conteneur da66d4c7152e est donc configuré pour redémarrer en cas de crash, mais aussi au démarrage/redémarrage du service Docker (donc, de l’hôte aussi).

Si vous n’avez qu’un ou deux conteneurs à analyser, cela peut être assez rapide. Mais si vous en avez des dizaines, cela peut être assez long. Je vous propose donc la commande suivante qui permet de récupérer la politique de redémarrage du tous vos conteneurs d’un seul coup : 

# Vérifier la valeur du paramètre RestartPolicy de tous les conteneurs
$ for container in $(docker ps -aq); do docker inspect -f ‘{{.Id}} – {{.Name}} – {{.HostConfig.RestartPolicy.Name}}’ “$container”; done

da66d4c7152e4d7296628bd07efb380f5305f87a90d0b531e085e1368ffe6cf0 – /database-1 – always
b629cc6c176e9896072a84d7a875e2d9012da3177dd6aef7a84e789c99089111 – /n8n-n8n-1 – no
9ceeeb84e738d5f6fca11f5f9b8907bdd71eca9d06568a057302ec1ded019b4a – /n8n-traefik-1 – no

Cette commande utilise une boucle for basée sur la sortie de la commande docker ps -aq. Cette dernière renvoie les ID de tous les conteneurs créés sur l’hôte. Ces ID sont ensuite utilisés pour alimenter la commande docker inspect vue précédemment. Vous avez donc en retour l’ID (format long), le nom du conteneur et sa politique de redémarrage.

B. Activer/Désactiver l’auto-start des conteneurs

Si vous êtes dans le cas d’un lancement de conteneur Docker et que vous souhaitez définir dès le début son comportement de redémarrage, il vous faut utiliser l’option –restart au lancement (commande docker run) :

# Lancer un conteneur avec un restart policy explicite à no
docker run -d –restart no  mariadb

N’oubliez pas, vous pouvez utiliser les valeurs no, on-failure, always ou unless-stopped pour cette option. 

Dans le cas d’un conteneur déjà créé (qu’il soit stoppé ou en cours d’exécution), nous pouvons utiliser la commande docker update, qui permet de modifier à la volée certaines configurations des conteneurs. Par exemple, je souhaite modifier la politique de redémarrage du conteneur identifié comme étant en always précédemment : 

# Changer la politique de démarrage d’un conteneur déjà créé
$ docker update –restart=no da66d4c7152e

da66d4c7152e

Je viens de passer sa politique de redémarrage à no, nous pouvons ensuite confirmer ce changement avec la commande docker inspect vue précédemment : 

# Vérifier le changement effectué
$ docker inspect -f ‘{{.HostConfig.RestartPolicy.Name}}’ da66d4c7152e 

no

Et voilà, si vous voulez faire le test jusqu’au bout, redémarrez votre hôte (ou plus simplement, votre service Docker) pour ensuite constater que votre conteneur n’a pas démarré ! 

IV. Conclusion

J’espère que cette astuce rapide vous aidera à mieux comprendre le comportement de vos conteneurs. 

L’essentiel à retenir sont la commande docker update, le rôle de la politique de démarrage et le fait que par défaut, les conteneurs ne sont pas configurés pour démarrer tous seuls. Si tel est le cas, regardez dans votre docker-compose.yml ou vos options de lancement et recherchez l’instruction restart qui peut avoir été paramétrée pour changer ce comportement par défaut.

N’hésitez pas à nous indiquer dans les commentaires si ce tutoriel vous a été utile et si vous souhaitez voir ce sujet plus souvent abordé sur IT-Connect ! 

Co-fondateur d’IT-Connect.fr.
Auditeur/Pentester chez Orange Cyberdéfense.



Source link

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *