Comment fonctionne Docker : créer, expédier, exécuter

Comment fonctionne Docker : créer, expédier, exécuter

Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire ce visuel

• Lisez les trois colonnes de gauche à droite : Construire, Expédier, Exécuter.
• La bande inférieure, « Système d'exploitation hôte », constitue la fondation : le conteneur à la fin du flux s'exécute SUR celui-ci, partageant son noyau.
• L'image est l'artefact dans lequel tout le reste se déplace : du moteur Docker au registre et de nouveau au moteur d'exécution.

Construire l'image

"Le développeur écrit un Dockerfile décrivant l'application" est une recette, pas un résultat : une image de base, les dépendances à installer, les fichiers à copier et la commande à exécuter. "docker build emballe l'application et ses dépendances" exécute la recette, et "La build produit une image : un instantané en lecture seule" est le résultat : un artefact immuable dans un système de fichiers en couches. La reproductibilité est le point important : le même Dockerfile produit la même image sur n'importe quelle machine.

Expédition de l'artefact

"L'image est poussée vers un registre ou extraite d'un registre" est la loi "Expédier". Le registre est le réseau de distribution d'images : un registre privé pour votre équipe, un registre public pour les images de base. L'image ne change jamais pendant l'expédition, ce qui rend le déploiement déterministe : ce que vous avez testé est exactement ce que vous exécutez.

Exécuter le conteneur

"docker run démarre un conteneur à partir de l'image" passe du moteur Docker au cluster "Exécution du conteneur". "Le conteneur est isolé avec des espaces de noms et des groupes de contrôle" est le mécanisme d'isolation : les espaces de noms donnent au processus sa propre vue du système de fichiers, du réseau et de la table des processus, les groupes de contrôle limitent son processeur et sa mémoire. "Le conteneur partage le noyau hôte mais possède son propre système de fichiers" se situe dans la bande "Système d'exploitation hôte" pour rendre explicite le contraste avec une machine virtuelle, et "Le processus d'application s'exécute de la même manière partout" est la récompense qui justifie l'ensemble de la pile.

Relations et enseignements clés

• Une image est un instantané en lecture seule ; un conteneur en est une instance en cours d'exécution.
• Les conteneurs partagent le noyau hôte et simulent une isolation avec les espaces de noms : c'est pourquoi ils démarrent en quelques secondes alors que les machines virtuelles prennent quelques minutes.
• Les groupes de contrôle limitent ce qu'un conteneur peut consommer, de sorte qu'un voisin bruyant ne peut pas affamer l'hôte.
• L’immuabilité de l’image est ce qui rend vrai « c’est pareil partout ».
• Docker fournit le packaging et le runtime ; les orchestrateurs comme Kubernetes gèrent de nombreux conteneurs sur plusieurs hôtes.

Quand utiliser ce visuel

• Expliquer à un développeur pourquoi Docker fonctionne et en quoi un conteneur diffère d'une machine virtuelle.
• Intégrer une équipe au modèle build-ship-run avant qu'elle n'écrive son premier Dockerfile.
• Fonder une conversation sur la dérive de l'environnement : pourquoi "fonctionne sur ma machine" cesse de s'appliquer.

Comment cela fonctionne

1. Annotez vos étapes Dockerfile

   Sur la zone Dockerfile, répertoriez les couches réelles de votre build (image de base, installation des dépendances, source de copie, commande d'exécution) pour que la recette soit concrète.

2. Nommez vos registres

   Renommez l'étape de registre avec vos registres réels (un ECR privé, une image publique) et notez les images que vous transmettez et celles que vous extrayez.

3. Ajouter les cases réseau et volume

   Étendez la colonne d'exécution avec la façon dont vos conteneurs parlent (un réseau de pont) et où réside l'état (un volume), car ce sont les deux parties que les débutants manquent le plus souvent.

4. Lien vers l'orchestration

   Si vous utilisez Kubernetes, ajoutez une note pointant du conteneur en cours d'exécution vers le visuel Kubernetes et ce que le kubelet change concernant l'endroit où le conteneur s'exécute.

Questions fréquentes

Quelle est la différence entre un conteneur et une machine virtuelle ?

Une machine virtuelle virtualise le matériel : elle embarque un système d'exploitation complet et un hyperviseur assure la médiation du tout, ce qui la rend lourde et lente à démarrer. Un conteneur virtualise le système d'exploitation : il partage le noyau hôte et utilise des espaces de noms pour l'isolation et des groupes de contrôle pour les limites de ressources. C'est pourquoi les conteneurs démarrent en quelques secondes et sont beaucoup plus légers : le compromis est que tous les conteneurs d'un hôte partagent le noyau de cet hôte.

Qu'est-ce qu'une image par rapport à un conteneur ?

Une image est l'artefact statique : un instantané en lecture seule de l'application et de ses dépendances, construit à partir du Dockerfile. Un conteneur est cette image en mouvement : un processus en cours d'exécution avec un calque inscriptible au-dessus. Vous créez une image une fois et pouvez démarrer des milliers de conteneurs à partir de celle-ci, chacun isolé des autres.

Comment Docker isole-t-il les conteneurs ?

Avec deux fonctionnalités du noyau Linux. Les espaces de noms donnent à chaque conteneur sa propre vue du système (son propre système de fichiers, sa pile réseau, sa table de processus et ses identifiants utilisateur), de sorte qu'il semble être sa propre machine. Les groupes de contrôle (groupes de contrôle) limitent et mesurent les ressources, plafonnant la quantité de CPU, de mémoire et d'E/S qu'un conteneur peut consommer afin qu'un conteneur ne puisse pas faire tomber ses voisins.

Pourquoi Docker rend-il les applications portables ?

Parce que l'image regroupe l'application avec son runtime, ses bibliothèques et sa configuration : tout sauf le noyau. Partout où un moteur Docker existe, l'image s'exécute de la même manière, de sorte que l'écart entre l'ordinateur portable d'un développeur, un exécuteur CI et un serveur de production se réduit à la configuration qui est délibérément conservée en dehors de l'image.

Modifier ce visuel dans QueryChart (FlowJam)

Ouvrez ce canevas Docker exact en tant que votre propre graphique, renommez les clusters en votre pile et annotez votre pipeline d'images.

Modifier ce visuel dans QueryChart (FlowJam)