9 articles tagués avec « Conteneurisation »

Sur un poste de développement, la deuxième construction d'une image est rapide : le démon Docker garde les couches de la première, et seules les instructions dont les entrées ont changé sont rejouées. Un runner de CI éphémère n'a pas cette mémoire. Chaque job démarre avec un démon vide, télécharge les images de base, réinstalle toutes les dépendances et recompile tout, même quand seul un fichier de code a changé. BuildKit, le moteur de construction de Docker, sait exporter son cache hors du démon et le relire au build suivant ; reste à choisir où le ranger et comment l'empêcher de s'accumuler.

Un runner de CI auto-hébergé qui doit démarrer des conteneurs (valider une stack Docker Compose, lancer des tests d'intégration, construire une image) a besoin d'un démon Docker. Lui donner le socket de l'hôte revient à lui donner la main sur tous les conteneurs de la machine, production comprise. Un démon dédié, lancé dans un conteneur docker:dind (Docker-in-Docker), cantonne les jobs à leurs propres conteneurs, volumes et réseaux. Cette isolation n'est toutefois réelle que si le démon dédié n'est pas lui-même laissé ouvert aux conteneurs qu'il exécute, et si le répertoire de travail partagé avec lui ne contient aucun secret.

Dans un déploiement Docker Compose, l'état persistant des services (bases de données, fichiers utilisateurs, configuration générée) vit dans des volumes nommés, sous /var/lib/docker/volumes. La commande docker volume sait créer, inspecter, lister et supprimer ces volumes, mais n'offre aucune fonction d'export ni de sauvegarde. Sans mécanisme dédié, la perte du disque hôte, une suppression accidentelle (docker compose down -v) ou une migration applicative ratée emportent les données. offen/docker-volume-backup comble ce manque avec un conteneur qui archive, chiffre et expédie périodiquement le contenu des volumes vers un stockage distant.

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 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.