Qu'est-ce que Image de conteneur ?

Modèle en lecture seule à partir duquel on crée des conteneurs. Elle empile en couches les fichiers d'une application, comme les exécutables, les bibliothèques et les réglages, et y ajoute une configuration comme la commande à lancer au démarrage ; elle ne contient pas de noyau d'OS. Les images sont construites à partir d'un Dockerfile ou d'un fichier similaire, puis stockées et distribuées par des registres. Une image se désigne par un nom de dépôt et un tag (par exemple web:1.4), ou de façon univoque par un condensé (digest) calculé à partir de son contenu (sha256:…). Les couches identiques sont partagées entre images.

Nom japonais: コンテナイメージ

« Image de conteneur » apparaît dans 3 questions d'entraînement réparties sur 1 thèmes, dont Bases du cloud et des conteneurs.

Domaine: Bases du cloud et des conteneurs

Fonctionnement des couches

Chaque instruction d'un Dockerfile qui modifie des fichiers (RUN, COPY, etc.) devient une couche. Les couches sont identifiées par un condensé calculé à partir de leur contenu : les images construites sur la même image de base partagent donc cette couche, qui n'est téléchargée et stockée qu'une seule fois. Supprimer un fichier dans une couche ultérieure laisse le contenu de la couche antérieure dans l'image ; les gros fichiers temporaires sont donc soit supprimés dans la même instruction, soit tenus hors de l'image finale par une construction multi-étapes.

Tags et condensés

Un tag, comme latest ou web:1.4, est un nom donné par des personnes et peut plus tard être déplacé vers une autre image. Un condensé est calculé à partir du contenu de l'image et change si un seul bit diffère. En production, ou partout où il faut utiliser exactement ce qui a été testé, les images sont désignées par leur condensé.

Rendre les images petites et sûres

Omettre les compilateurs et les gestionnaires de paquets inutiles à l'exécution rend les images plus petites, plus rapides à récupérer et moins exposées aux vulnérabilités. Une méthode courante est la construction multi-étapes, qui sépare une étape de construction d'une étape d'exécution. Les secrets ne sont pas placés dans les images, mais transmis au démarrage.

S'entraîner : questions sur Image de conteneur

Quelle description de la relation entre une image de conteneur et un conteneur est correcte ?

AQuand un conteneur est arrêté, les modifications faites à l'intérieur sont automatiquement réécrites dans l'image, ce qui écrase l'image d'origine
BUne image est un modèle en lecture seule, et l'on peut démarrer à partir d'une seule image plusieurs conteneurs ayant chacun sa propre couche inscriptible
COn ne peut démarrer qu'un seul conteneur à la fois à partir d'une image ; pour en démarrer un deuxième, il faut d'abord copier l'image sous un autre nom

Afficher la réponse et l'explication

Réponse : B. Une image est un modèle en lecture seule, et l'on peut démarrer à partir d'une seule image plusieurs conteneurs ayant chacun sa propre couche inscriptible

Une image est un modèle en lecture seule qui regroupe les fichiers et les réglages nécessaires pour exécuter une application, et un conteneur est une unité d'exécution créée à partir d'une image. À la création d'un conteneur, une couche inscriptible qui lui est propre est empilée sur les couches de l'image. On peut donc démarrer de nombreux conteneurs à partir d'une seule image, et les modifications faites dans l'un n'affectent ni les autres conteneurs ni l'image. Pour conserver une modification dans une image, on modifie habituellement le Dockerfile et l'on reconstruit l'image.

Dans un Deployment Kubernetes, l'image de conteneur du modèle de Pod est remplacée par une nouvelle version. Quelle description de ce qui se passe avec la stratégie de mise à jour par défaut (RollingUpdate) est correcte ?

AUn nouveau ReplicaSet est créé, et des Pods de la nouvelle version sont ajoutés pendant que des Pods de l'ancienne version sont retirés. L'ancien ReplicaSet est conservé avec 0 Pod pour un retour arrière
BL'image de conteneur des Pods en cours d'exécution est remplacée sur place par la nouvelle version sans recréer les Pods : ni les adresses IP ni les noms des Pods ne changent
CTous les Pods de l'ancienne version sont supprimés d'un coup, puis les Pods de la nouvelle version sont créés ensemble : le service est donc interrompu temporairement pendant la mise à jour

Afficher la réponse et l'explication

Réponse : A. Un nouveau ReplicaSet est créé, et des Pods de la nouvelle version sont ajoutés pendant que des Pods de l'ancienne version sont retirés. L'ancien ReplicaSet est conservé avec 0 Pod pour un retour arrière

Quand le modèle de Pod change, un Deployment crée un ReplicaSet pour le nouveau modèle et, tout en vérifiant que les nouveaux Pods sont devenus prêts, réduit progressivement les Pods de l'ancien ReplicaSet. Un certain nombre de Pods continuent ainsi de traiter les requêtes pendant la mise à jour. L'ancien ReplicaSet est conservé avec 0 Pod, ce qui permet à kubectl rollout undo de revenir à la version précédente. La stratégie qui supprime d'abord tous les Pods puis les recrée est Recreate, utilisée seulement si on l'indique explicitement.

Questions fréquentes

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

Une image est un modèle en lecture seule, et un conteneur est une instance en cours d'exécution (ou arrêtée) créée à partir de celle-ci. On peut créer de nombreux conteneurs à partir d'une seule image, et chacun reçoit sa propre couche inscriptible. C'est comparable à la relation entre un fichier de programme et un processus.

Le tag latest donne-t-il toujours la version la plus récente ?

latest est un tag ordinaire sans signification particulière. C'est simplement le nom par défaut utilisé quand aucun tag n'est indiqué, et il ne désigne une nouvelle version que si quelqu'un le déplace. Pour figer une version, on indique un tag précis ou un condensé.

Questions mentionnant « Image de conteneur » (3)

Termes associés

Conteneur Kubernetes Pod CI/CD (intégration continue et livraison continue) Variable d'environnement Déploiement bleu-vert (blue-green deployment) Déploiement canari (canary release) Docker Informatique sans serveur (serverless) Infrastructure en tant que code (IaC)

Retour au glossaire