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 découlent directement du fonctionnement des couches, décrites dans Docker : conteneurs et images, et du cache de build, présenté dans Docker, et s'évitent 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 structure tout l'outillage : les images se distribuent, les conteneurs s'exécutent. 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.
Nginx est un serveur web événementiel conçu pour gérer un grand nombre de connexions simultanées avec une faible empreinte mémoire. Contrairement aux serveurs qui dédient un processus ou un thread à chaque connexion (Apache avec les MPM prefork ou worker), il utilise un modèle non-bloquant à base de boucle d'événements : chaque worker process gère des milliers de connexions sans créer un thread par connexion. Cette architecture en fait un choix courant comme reverse proxy en frontal d'une infrastructure.
Un proxy et un reverse proxy remplissent tous les deux un rôle d'intermédiaire réseau, mais ils se positionnent de chaque côté de la connexion : l'un représente le client, l'autre protège le serveur. Confondre les deux mène à des architectures mal configurées et à des règles de sécurité inefficaces.
Quand une séquence de steps se répète dans plusieurs workflows (checkout + setup + build, ou authentification + push Docker), la factoriser dans une action évite la duplication et centralise la maintenance. Une correction ou une mise à jour s'applique à tous les workflows consommateurs sans toucher chacun individuellement.
Quand plusieurs dépôts partagent la même stack technique, chacun maintient souvent une copie quasi-identique de ses workflows CI/CD. Une modification (nouvelle version d'un outil, changement de runner, ajout d'une étape de sécurité) doit être répercutée manuellement dans chaque dépôt. Un dépôt centralisé de workflows mutualisés résout ce problème : les dépôts consommateurs appellent les workflows du dépôt central, qui devient le seul point de maintenance.
Sans automatisation, livrer du code en production est un processus manuel : un développeur fusionne une branche, lance les tests à la main, construit l'image Docker, se connecte au serveur, déploie. Chaque étape est une occasion d'oublier quelque chose, de sauter un test, ou de déployer une version qui n'a pas été vérifiée. À mesure que l'équipe et le rythme de livraison augmentent, ce processus ne tient plus.