Gérer les conteneurs

Cycle de vie et gestion avancée

La puissance théorique de Docker s'exprime dans l'élégance du cycle de vie des conteneurs. Comprendre qu'un conteneur est conçu depuis sa racine absolue pour crasher, mourir et être remplacé sans hésitation ni états d'âmes est le pivot conceptuel pour une orchestration propre, comme sur Kubernetes.

Le Machine State du cycle de vie (LifeCycle)

Observez ce graphe d'états. Une image stockée sur disque (Inerte) devient un conteneur configuré (Created) qui va être réveillé en un processus Unix standard (Running). S'il plante ou est stoppé, il n'est pas mort : il est juste endormi (Exited/Stopped), occupant encore de l'espace disque. Ce n'est qu'après un "Remove" (Deleted) que ses données volatiles sont purgées.

📦

Image

docker run

Created

start

Running

docker pause ⏸ Paused unpause

docker stop ↕ docker start

Stopped / Exited

docker rm

🗑️

Deleted

💡 La Règle d'or de l'Immutabilité Le cycle est délibérément fluide car un conteneur est fondamentalement JETABLE (Éphémère). On ne se connecte jamais en SSH sur un conteneur de production pour effectuer l'équivalent d'un "apt-get upgrade" ou modifier le code source à la main. On met à jour l'image parente, on détruit l'ancien conteneur, et on déploie une copie instanciée de la nouvelle image.

Diagnostics & Chirurgie Interne : L'Inspection

Même détruit, ou crashé avant de démarrer, l'inspection permet de retracer le contexte fatal (problèmes de variables d'environnement manquantes, adresse IP réseau, etc).

Diagnostic Avancé JSON

# Le `inspect` déverse l'intégralité du cerveau (Metadata) du conteneur en format JSON brut
docker inspect mon-conteneur

# L'usage pro : filtrer (jq) une information ultra-précise (ex: trouver l'IP Interne du conteneur)
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mon-conteneur

# Extraire brutalement un fichier de configuration capricieux /etc/nginx depuis le conteneur crashé vers l'hôte (Desktop) local pour l'ausculter
docker cp mon-conteneur:/etc/nginx/nginx.conf ./nginx.conf.backup

# Injection d'un nouveau fichier réparé
docker cp ./nginx_fix.conf mon-conteneur:/etc/nginx/nginx.conf

Gouvernance et Control Groups (cgroups)

Par défaut absolue, un conteneur n'a aucune limite matérielle. Un script Python infini (Memory Leak) à l'intérieur d'un conteneur peut tranquillement consommer les 64 Go de RAM de votre serveur de production jusqu'au crash de l'OS hôte (Kernel Panic).

Il est VITAL de brider vos conteneurs en production :

Restriction Hard Limits

# Hard Limit Mémoire : Tue violemment le processus (OOMKilled) s'il dépasse 512 Mo de RAM
# Swap bridge : Bloque le swap à 1 Go, sinon le conteneur trichera sur le disque.
docker run -d --memory 512m --memory-swap 1g mon-api-python

# Bridage CPU : N'autorise ce conteneur à utiliser mathématiquement que 50% des cœurs totaux.
docker run -d --cpus="0.5" mon-calcul-lourd

# --- L'Auto-Heal (La magie DevOps des redémarrages automatiques) ---
# unless-stopped : Si mon serveur crash ou redémarre électriquement, l'API se relancera avec lui pour toujours.
docker run -d --restart unless-stopped mon-api-python

# on-failure:5 : Tente de relancer l'application crashée (Erreur 500 fatales), mais abandonne après 5 échecs consécutifs.
docker run -d --restart on-failure:5 data-analyzer

← Précédent