Opérations de production avec Docker Context : liste de contrôle pratique et exemples

Introduction

Docker Context est un outil puissant pour gérer plusieurs environnements Docker, mais en production, il devient un lien critique entre votre poste de travail et l'infrastructure réelle. Un contexte mal configuré peut envoyer des commandes vers le mauvais cluster, exposer des secrets ou laisser des services cassés après un déploiement raté. Cet article propose une liste de contrôle pratique, axée sur la production, pour les opérations Docker Context, avec des commandes concrètes, des signaux du monde réel et des étapes de récupération.

Nous couvrirons l'inventaire de l'environnement, la configuration sécurisée, la vérification, les modes de défaillance courants et la maintenance. Que vous soyez développeur supportant la production, consultant DevOps ou membre d'une startup, vous trouverez des conseils actionnables pour fiabiliser et sécuriser vos Docker Contexts.

Inventaire de version et d'environnement

Avant de toucher à un Docker Context, sachez exactement avec quoi vous travaillez. Cela signifie enregistrer la version du moteur Docker, les points de terminaison des contextes, les nœuds actifs et la disposition de votre environnement.

Vérifier la version de Docker et la liste des contextes

docker version

La sortie attendue inclut les versions du client et du serveur. Si le point de terminaison du serveur est injoignable, vous verrez une erreur ici. Vérifiez ensuite vos contextes :

docker context ls

Exemple de sortie :

NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT   ORCHESTRATOR
local               moby                Current local context                    unix:///var/run/docker.sock
prod-swarm          swarm               Production Swarm cluster                  ssh://[email protected]

Recherchez le contexte marqué d'un astérisque (*) indiquant le contexte actif. Une erreur courante est d'exécuter des commandes sur le mauvais contexte. Vérifiez toujours le contexte actif avant toute opération destructive :

docker context show

Si la sortie ne correspond pas à l'environnement prévu, basculez explicitement :

docker context use prod-swarm

Inventorier les conteneurs et services en cours d'exécution

Une fois le contexte connu, vérifiez ce qui tourne. Cette observation en lecture seule doit être votre première étape avant tout changement.

Pour les conteneurs autonomes :

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

Cela produit un tableau propre des noms de conteneurs, de leur statut et des mappages de ports. En production, vous utilisez probablement Swarm ou Compose. Pour les services Swarm :

docker service ls

Pour les projets Compose (à exécuter depuis le répertoire contenant votre docker-compose.yml) :

docker compose ps

Soyez attentif aux services qui ne sont pas dans l'état « Running » ou dont le nombre de redémarrages augmente. Un conteneur qui redémarre en boucle est un signe classique de mauvaise configuration ou de dépendance manquante.

Inspecter un conteneur ou service spécifique

Lorsque vous avez besoin de détails sur les montages, les réseaux, les variables d'environnement ou l'état de santé :

docker inspect <container-name>

Pour un service Swarm, utilisez :

docker service inspect --pretty <service-name>

Le drapeau --pretty imprime la spécification dans un format plus lisible. Recherchez les montages de volumes, les secrets et les définitions de healthchecks.

Comprendre la persistance des données

Avant de modifier quoi que ce soit qui affecte les données, confirmez où les fichiers sont stockés. C'est critique en production. Deux modèles courants :

• Volume nommé : par exemple, app_data:/var/lib/app. Géré par Docker, survit à la recréation du conteneur et est portable entre hôtes (avec précaution).
• Montage bind : par exemple, ./data:/var/lib/app. Mappe directement un répertoire hôte, utile pour le développement mais pouvant causer des problèmes de permissions et de portabilité en production si le même chemin n'existe pas sur tous les nœuds.

Vérifiez vos volumes :

docker volume ls

Inspectez un volume spécifique :

docker volume inspect app_data

La sortie montre le point de montage sur l'hôte. Pour les montages bind, inspectez le conteneur ou le service pour voir le chemin source :

docker inspect <container-name> --format '{{json .Mounts}}'

Si le chemin source n'existe pas sur l'hôte, le conteneur ne démarrera pas. Assurez-vous toujours que les répertoires hôtes existent et ont les bonnes permissions avant de déployer.

Test de redémarrage

Un test simple de type production consiste à recréer un conteneur et à vérifier qu'il a toujours ses données. Pour un conteneur autonome :

docker stop <container-name>
docker rm <container-name>
# Puis recréer avec la même commande ou le fichier compose, par exemple :
docker run -d --name <container-name> -v app_data:/var/lib/app your-image

Ou avec Compose :

docker compose up -d --force-recreate <service-name>

Après la recréation, vérifiez les journaux et l'accessibilité des données. Si les données ont disparu, le service écrivait probablement dans le système de fichiers éphémère du conteneur au lieu d'un volume persistant. C'est un piège courant en production.

Chemin de configuration sécurisé

Les changements de configuration des Docker Contexts doivent être délibérés, limités et réversibles. L'objectif est d'éviter de casser votre capacité à gérer la production tout en maintenant la sécurité.

Examiner la configuration actuelle du contexte

Pour voir les détails complets d'un contexte, utilisez :

docker context inspect prod-swarm

Cela renvoie du JSON avec des champs comme docker.endpoint, docker.ca, docker.cert et docker.key. Faites attention aux chemins des certificats. Un matériel TLS mal configuré est une cause fréquente de défaillance des contextes.

Créer un nouveau contexte en toute sécurité

Ne modifiez jamais directement un contexte de production fonctionnel ; créez-en un nouveau et testez-le avant de basculer.

Pour une connexion SSH directe (recommandée pour Swarm) :

docker context create prod-swarm-test --docker "host=ssh://[email protected]"

Pour un point de terminaison d'API Docker avec TLS :

docker context create prod-api-test \
  --docker "host=tcp://10.0.0.10:2376,ca=/path/to/ca.pem,cert=/path/to/cert.pem,key=/path/to/key.pem"

Vérifiez ensuite la connexion :

docker --context prod-swarm-test ps

Si cela fonctionne, vous pouvez basculer en toute sécurité avec docker context use prod-swarm-test. Si cela échoue, supprimez le contexte de test sans affecter la production :

docker context rm prod-swarm-test

Protéger les informations d'identification et les secrets

N'incorporez jamais de secrets dans les définitions de contexte ou les scripts shell. Utilisez des variables d'environnement ou des outils de gestion des secrets. Pour les certificats, assurez-vous que les permissions des fichiers sont restrictives :

chmod 600 /path/to/key.pem

Pour les contextes SSH, utilisez le transfert d'agent SSH ou une authentification par clé avec phrase secrète, et évitez l'authentification par mot de passe.

Modifier les points de terminaison du contexte avec un rayon d'impact minimal

Si vous devez mettre à jour le point de terminaison d'un contexte, exportez d'abord la configuration existante :

docker context export prod-swarm > prod-swarm.dockercontext

Cela crée une sauvegarde que vous pouvez réimporter si nécessaire :

docker context import prod-swarm prod-swarm.dockercontext

Mettez ensuite à jour le contexte avec docker context update :

docker context update prod-swarm --docker "host=ssh://[email protected]"

Testez avant de basculer :

docker --context prod-swarm ps

Si le nouveau point de terminaison échoue, vous avez toujours l'ancien fichier de contexte pour restaurer.

Bonnes pratiques de configuration pour Docker Context en production

• Utilisez des noms descriptifs pour les contextes, par exemple prod-eu-swarm, prod-us-swarm, staging.
• Évitez d'utiliser le contexte local par défaut pour le travail de production ; créez des contextes explicites.
• Documentez chaque contexte dans votre runbook : point de terminaison, objectif, propriétaire.
• Passez régulièrement en revue les contextes et supprimez ceux qui ne sont pas utilisés pour réduire la confusion.

Vérification et diagnostic

Après tout changement de configuration, la vérification est obligatoire. Voici comment vérifier systématiquement votre Docker Context et les applications qu'il gère.

Vérifier la connectivité du contexte

La vérification la plus simple :

docker context use prod-swarm
docker info

docker info renvoie les détails du serveur. S'il se bloque ou renvoie une erreur, la connectivité est rompue. Pour les contextes SSH, testez SSH directement :

ssh [email protected] 'docker version --format "{{.Server.Version}}"'

Vérifier la santé des services

Pour les conteneurs :

docker ps --filter "health=unhealthy"

Cela montre uniquement les conteneurs en mauvaise santé. Si vous avez défini des healthchecks, vous verrez l'état de santé dans la sortie de docker ps. Si un conteneur est en mauvaise santé, inspectez son journal de healthcheck :

docker inspect --format '{{json .State.Health}}' <container-name>

Pour les services Swarm :

docker service ps <service-name>

Recherchez les tâches dans l'état « Running ». S'il y a des échecs dans l'historique des tâches (par exemple, « Failed » ou « Rejected »), inspectez la tâche spécifique :

docker service ps --no-trunc <service-name>

Et vérifiez les journaux :

docker service logs <service-name> --tail 50

Diagnostiquer les problèmes courants

• Le contexte pointe vers le mauvais point de terminaison : vous exécutez docker ps et voyez des conteneurs qui ne semblent pas corrects. Correction : docker context show, basculez si nécessaire.
• Certificat expiré : l'erreur persiste « x509: certificate has expired or is not yet valid ». Correction : renouvelez les certificats et mettez à jour le contexte avec les nouveaux chemins.
• La connexion SSH tombe : erreur « ssh: handshake failed » ou délais d'attente. Correction : vérifiez le réseau, le démon SSH et les informations d'identification.
• Application qui ne répond pas : après le déploiement, vérifiez les journaux et les healthchecks. Si le healthcheck est mal configuré, mettez à jour le Dockerfile ou le fichier compose.

Utiliser Docker Desktop pour le diagnostic

Si vous utilisez Docker Desktop, l'interface graphique fournit un aperçu visuel des contextes et des conteneurs en cours d'exécution. Mais pour les scripts et la répétabilité, appuyez-vous sur les commandes CLI documentées ici.

Modes de défaillance et récupération

Même avec une planification minutieuse, les défaillances surviennent. Voici les modes de défaillance courants des Docker Contexts, leurs symptômes et les étapes de récupération.

Défaillance : perte d'accès à la production en raison d'un fichier de contexte égaré

Symptômes : docker context ls montre un contexte manquant, ou docker context use prod-swarm renvoie une erreur. Vous avez peut-être accidentellement supprimé un contexte ou votre répertoire de configuration Docker ~/.docker est corrompu.

Récupération :

• Si vous avez exporté une sauvegarde (voir Chemin de configuration sécurisé), réimportez-la.
• Sinon, recréez le contexte manuellement en utilisant le point de terminaison connu et les certificats.
• Documentez les étapes de création du contexte dans votre runbook pour rendre cela rapide.

Défaillance : la rotation des certificats casse le contexte

Symptômes : les commandes échouent avec des erreurs TLS même si le point de terminaison est joignable.

Récupération :

• Mettez à jour le contexte avec les nouveaux chemins de certificats.
• Testez avec docker --context <name> ps avant de vous y fier.
• Si les certificats sont gérés par un magasin de secrets, assurez-vous que les fichiers sont mis à jour sur les machines clientes.

Défaillance : perte de données d'application après la recréation du conteneur

Symptômes : après avoir exécuté docker compose up -d --force-recreate, l'application affiche des données manquantes ou démarre à neuf.

Récupération :

• Arrêtez immédiatement le conteneur.
• Vérifiez si un volume ou un montage bind a été utilisé : docker inspect <container> --format '{{json .Mounts}}'.
• Si le montage manquait, vérifiez les définitions de volumes dans le fichier compose. Corrigez le montage et redéployez.
• Si les données ont été écrites dans la couche du conteneur, elles sont perdues à moins d'avoir une sauvegarde. Cela souligne l'importance du stockage persistant.

Défaillance : mauvais contexte utilisé pour une commande destructive

Symptômes : vous avez supprimé ou mis à jour quelque chose sur le mauvais environnement. Par exemple, docker stack rm en production alors que vous pensiez être en staging.

Récupération :

• C'est difficile. Si vous avez de l'infrastructure-as-code ou des sauvegardes, restaurez.
• Prévenez en vérifiant toujours docker context show avant les commandes destructives.
• Utilisez des noms de contexte qui indiquent clairement l'environnement, et envisagez d'utiliser des invites de shell qui affichent le contexte actuel.

Défaillance : rotation des clés SSH

Symptômes : les contextes basés sur SSH échouent à l'authentification.

Récupération :

• Mettez à jour votre clé SSH sur les nœuds cibles.
• Assurez-vous que votre agent SSH local est en cours d'exécution et que la nouvelle clé est ajoutée.
• Testez SSH manuellement : ssh [email protected] avant de tester le contexte.

Liste de contrôle des opérations

Cette section condense les conseils en une liste de contrôle reproductible pour les opérations quotidiennes, hebdomadaires et mensuelles.

Contrôles quotidiens

• [ ] Exécutez docker context ls et vérifiez que le contexte actif est correct pour votre travail actuel.
• [ ] Exécutez docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" (ou docker service ls pour Swarm) pour voir les charges de travail en cours d'exécution.
• [ ] Vérifiez les conteneurs en mauvaise santé ou qui redémarrent : docker ps --filter "health=unhealthy" et docker service ps --filter "desired-state=running" | grep -v Running (pour Swarm).
• [ ] Examinez les journaux pour les erreurs : docker logs <container> --tail 100 ou docker service logs <service> --since 24h.

Maintenance hebdomadaire

• [ ] Validez l'intégrité des sauvegardes pour les volumes et les montages bind.
• [ ] Testez la connectivité du contexte depuis une autre machine ou un autre utilisateur pour détecter les problèmes de permissions.
• [ ] Vérifiez l'utilisation du disque : docker system df pour voir si les images ou les conteneurs sont gonflés.
• [ ] Examinez les dates d'expiration des certificats : openssl x509 -enddate -noout -in cert.pem.

Revue mensuelle

• [ ] Supprimez les contextes inutilisés : docker context rm <name> après avoir confirmé qu'ils ne sont pas nécessaires.
• [ ] Mettez à jour la documentation avec tout changement d'adresses IP, de noms d'hôte ou de rôles.
• [ ] Effectuez un exercice de reprise après sinistre : recréez un contexte à partir de zéro et vérifiez l'accès.
• [ ] Vérifiez les mises à jour du moteur Docker et testez-les sur un contexte de staging avant de les appliquer à la production.

Propriété et cadence

Attribuez des propriétaires pour ces contrôles. Par exemple :

• Gestion des contextes : Priya Shah, ingénieure DevOps. Revues mensuelles des contextes.
• Gestion des certificats : Marcus Chen, responsable sécurité. Revues hebdomadaires de l'expiration.
• Vérification des sauvegardes : l'ingénieur de garde exécute des contrôles de sauvegarde quotidiens.
• Reprise après sinistre : le chef d'équipe, Carlos Rivera, planifie des exercices trimestriels.

Pièges courants et comment les éviter

1. Utiliser le contexte local par défaut pour tout

Pourquoi cela arrive : les développeurs commencent souvent avec local et ajoutent des hôtes distants mais oublient de changer de contexte. Cela conduit à exécuter des commandes sur votre ordinateur portable alors que vous vouliez la production.

Évitement : créez un contexte dédié pour chaque environnement et définissez DOCKER_CONTEXT dans votre profil shell sur la valeur par défaut correcte pour votre travail. Utilisez une convention de nommage claire.

2. Stocker des secrets dans les fichiers de contexte ou les scripts

Pourquoi cela arrive : la commodité. Intégrer des mots de passe ou des clés dans les commandes semble plus rapide.

Évitement : utilisez des clés SSH avec phrase secrète ou une authentification par certificat. N'écrivez jamais de secrets en clair. Utilisez des variables d'environnement ou des gestionnaires de secrets et référencez-les dans les scripts.

3. Ne pas tester les changements de contexte avant de basculer

Pourquoi cela arrive : l'urgence des problèmes de production conduit à des changements rapides.

Évitement : créez toujours un contexte de test, exécutez une commande en lecture seule, puis basculez. Gardez l'ancien contexte jusqu'à ce que vous soyez sûr que le nouveau fonctionne.

4. Ignorer la persistance des données dans les conteneurs

Pourquoi cela arrive : les conteneurs sont éphémères par conception, et les développeurs peuvent supposer que les données sont automatiquement persistées.

Évitement : définissez explicitement des volumes ou des montages bind pour tous les services avec état. Effectuez régulièrement un test de redémarrage.

5. Ne pas documenter les contextes et leurs points de terminaison

Pourquoi cela arrive : les contextes sont créés ad hoc et non enregistrés.

Évitement : maintenez une entrée de runbook pour chaque contexte avec le point de terminaison, la méthode d'authentification et l'objectif. Mettez-la à jour lors des revues mensuelles.

6. Négliger l'expiration des certificats

Pourquoi cela arrive : les certificats sont définis et oubliés jusqu'à ce qu'ils cassent.

Évitement : automatisez les vérifications avec un outil de surveillance et définissez des rappels calendaires avant l'expiration.

Conclusion

Les opérations de production avec Docker Context exigent de la discipline : observer avant de changer, garder un rayon d'impact limité, protéger les secrets, vérifier les résultats et documenter les chemins de récupération. Cette liste de contrôle fournit une base, mais chaque environnement est unique. Adaptez ces étapes à votre propre infrastructure et à vos flux de travail d'équipe.

Commencez dès aujourd'hui par une vérification à faible risque : vérifiez votre contexte actuel, listez les conteneurs en cours d'exécution et inspectez un volume. Passez ensuite en revue votre configuration de contexte, créez un contexte de test et suivez les contrôles quotidiens. Au fur et à mesure que vous gagnez en confiance, intégrez les routines hebdomadaires et mensuelles aux opérations de votre équipe.

Une configuration fiable de Docker Context rend les défaillances visibles, protège les valeurs sensibles et limite les changements à la ressource prévue. Avec cette liste de contrôle, vous pouvez exploiter vos environnements Docker avec plus de sécurité et de confiance.