## 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** ```bash 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 : ```bash 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://admin@10.0.0.10 ``` 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 : ```bash docker context show ``` Si la sortie ne correspond pas à l'environnement prévu, basculez explicitement : ```bash 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 : ```bash 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 : ```bash docker service ls ``` Pour les projets Compose (à exécuter depuis le répertoire contenant votre docker-compose.yml) : ```bash 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é : ```bash docker inspect ``` Pour un service Swarm, utilisez : ```bash docker service inspect --pretty ``` 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 : ```bash docker volume ls ``` Inspectez un volume spécifique : ```bash 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 : ```bash docker inspect --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 : ```bash docker stop docker rm # Puis recréer avec la même commande ou le fichier compose, par exemple : docker run -d --name -v app_data:/var/lib/app your-image ``` Ou avec Compose : ```bash docker compose up -d --force-recreate ``` 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 : ```bash 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) : ```bash docker context create prod-swarm-test --docker "host=ssh://admin@10.0.0.10" ``` Pour un point de terminaison d'API Docker avec TLS : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash docker context export prod-swarm > prod-swarm.dockercontext ``` Cela crée une sauvegarde que vous pouvez réimporter si nécessaire : ```bash docker context import prod-swarm prod-swarm.dockercontext ``` Mettez ensuite à jour le contexte avec `docker context update` : ```bash docker context update prod-swarm --docker "host=ssh://admin@10.0.0.11" ``` Testez avant de basculer : ```bash 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 : ```bash 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 : ```bash ssh admin@10.0.0.10 'docker version --format "{{.Server.Version}}"' ``` **Vérifier la santé des services** Pour les conteneurs : ```bash 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 : ```bash docker inspect --format '{{json .State.Health}}' ``` Pour les services Swarm : ```bash docker service ps ``` 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 : ```bash docker service ps --no-trunc ``` Et vérifiez les journaux : ```bash docker service logs --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 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 --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 admin@10.0.0.10` 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 --tail 100` ou `docker service logs --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 ` 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.