Déboguer un conteneur diffère du débogage d'une application classique : le processus s'exécute dans un namespace isolé, sans accès direct au shell dans les cas normaux, avec des logs parfois redirigés vers stdout. Les outils Docker exposent l'état interne du conteneur sans nécessiter d'accès SSH.
Conteneurs et machines virtuelles répondent au même besoin d'isolation des applications, mais à des niveaux différents de la pile système. Comprendre cette différence architecturale explique pourquoi les deux technologies coexistent plutôt que l'une remplace l'autre.
Une image Docker mal construite peut peser plusieurs gigaoctets, exposer des secrets dans ses couches, ou s'exécuter en root sans raison valable. Ces problèmes sont évitables avec quelques principes de construction appliqués systématiquement.
Une image Docker est un artefact statique. Un conteneur est une image en cours d'exécution. Cette distinction est simple mais fondamentale : on distribue des images, on exécute des conteneurs. Comprendre leur structure et leur cycle de vie permet de diagnostiquer rapidement les problèmes et de concevoir des Dockerfiles efficaces.
Les applications modernes s'appuient sur une combinaison de services — base de données, cache, broker de messages, runtime applicatif — chacun avec ses dépendances de version spécifiques. Sans conteneurs, chaque développeur configure son environnement local manuellement, les versions divergent entre machines, et le déploiement implique de reconfigurer chaque serveur à la main. Docker résout ces problèmes en encapsulant l'application et ses dépendances dans une unité portable et reproductible.
GitHub Container Registry (GHCR) est le registry d'images Docker intégré à GitHub. Il stocke les images au même endroit que le code source, partage la gestion des accès avec les dépôts GitHub, et s'intègre nativement dans les workflows GitHub Actions via le token GITHUB_TOKEN.