‫Très bien, dans cette conférence, nous allons parler de couches d'image.
‫Il s’agit donc d’un concept fondamental du fonctionnement de Docker. Il utilise quelque chose appelé le système de fichiers de
‫l'union pour présenter une série de modifications du système de fichiers sous la forme d'un système de fichiers réel.
‫Nous allons plonger dans l'historique, inspecter les commandes et voir comment nous pouvons les utiliser pour
‫comprendre en quoi une image est réellement faite. Nous allons en apprendre un peu plus sur le concept
‫de copie sur écriture du fonctionnement d'un conteneur en tant que couche supplémentaire au-dessus d'une image.
‫Qu'est-ce que je veux dire par couches d'image?
‫Lorsque vous utilisez Docker, il est complètement transparent. Toutefois, lorsque vous commencez à explorer certaines commandes, telles
‫que la commande history, inspect et commit, vous commencez à avoir l’impression qu’une image
‫n’est pas un gros bloc de données qui va et vient dans un énorme morceau.
‫Droite?
‫Si vous remarquez que lorsque Docker a été extrait, il arrive parfois que des mots indiquent que vous
‫possédez déjà quelque chose, comme si vous en aviez déjà mis en cache une partie, et que
‫tout se résume au fait que les images sont conçues à l'aide de le concept de système de fichiers union consistant à créer
‫des couches sur les modifications.
‫Si nous pouvions rapidement regarder ce que nous avons dans Docker ... dans les images de Docker en fait ...
‫Il y a quelque temps, nous jouions avec les tags avec Nginx. Droite? Nous nous souvenons que l’ID
‫image Nginx est le même et que nous avions différentes étiquettes pour le même nom d’image.
‫Faisons donc un historique rapide du menu fixe sur le dernier nginx.
‫Qu'est-ce que je regarde ici?
‫Ce n'est pas une liste de choses qui se sont réellement passées dans le conteneur car il s'agit d'une image.
‫C'est en fait une histoire des couches d'image.
‫Chaque image commence depuis le tout début avec un calque vierge appelé scratch.
‫Chaque ensemble de modifications intervenant ensuite sur le système de fichiers, dans l'image, constitue un autre calque.
‫Vous pouvez avoir un calque, vous pouvez avoir des dizaines de calques et certains calques ne changent peut-être pas en termes
‫de taille de fichier.
‫Vous remarquerez ici que nous avons en fait un changement qui consistait simplement en un changement de métadonnées concernant la
‫commande que nous allons réellement exécuter. Nous y reviendrons dans un instant lorsque nous examinerons le
‫fichier Docker.
‫Mais, pour le moment, vous pouvez réellement voir que celui-ci a ajouté une énorme quantité de fichiers, soit 123 Mo.
‫Ensuite, nous avons apporté un changement ici et un changement ici et je sais que,
‫grâce à Dockerfiles, il s’agit en réalité de métadonnées Dockerfile.
‫Au fur et à mesure que vous montez, nous avons d’autres modifications de données.
‫Vous verrez que c'est en fait assez différent dans une autre image.
‫Donc, si nous allons à docker history mysql, il a un ensemble de couches d’image complètement différent.
‫Laissez-moi dessiner ceci un peu pour vous et peut-être que cela aidera.
‫Lorsque nous commençons une image, lorsque nous
‫créons une nouvelle image, nous commençons avec un calque. Chaque couche a son propre SHA unique qui aide le système à déterminer si cette
‫couche est vraiment la même chose qu'une autre couche.
‫Disons simplement qu'au début de l'un des vôtres, vous pourriez avoir Ubuntu tout en bas.
‫C'est la première couche de votre image.
‫Ensuite, vous créez un fichier Docker, qui ajoute quelques fichiers supplémentaires et constitue une couche supplémentaire
‫par-dessus cette image. Peut-être que nous utilisons Apt pour cela.
‫Ensuite, dans votre fichier Docker, vous modifiez une variable d’environnement. Cela ensemble est votre image.
‫D'accord?
‫Vous pouvez avoir une image différente qui commence à partir de debian: jessie, puis sur cette image,
‫vous pouvez également utiliser Apt
‫pour installer des éléments, disons MySQL. Vous pouvez copier certains fichiers, vous pouvez ouvrir un port.
‫Ainsi, chacune de ces modifications que vous apportez habituellement dans le fichier Docker, mais vous pouvez également apporter des modifications
‫à l'aide de la commande commit docker que nous allons extraire dans une minute.
‫C'est aussi une autre image et celles-ci sont toutes regroupées.
‫Que se passe-t-il si j'ai une autre image qui utilise également la même version de Jessie?
‫Eh bien, cette image peut avoir ses propres modifications au-dessus
‫du même calque que j'ai dans mon cache. C’est là que le concept fondamental de la mise en cache des
‫couches d’image nous fait économiser beaucoup de temps et d’espace. Parce que nous n’avons pas besoin de télécharger les calques que
‫nous avons déjà, rappelez-vous qu’il utilise un SHA unique pour chaque calque, il est donc garanti que ce sera
‫exactement le calque dont il a besoin. Il sait comment les faire correspondre entre Docker Hub et notre cache local. Lorsque nous modifions
‫nos images, elles créent davantage de calques.
‫Si nous décidons de faire en sorte que la même image soit l'image de base de plusieurs calques, le
‫logiciel n'enregistre qu'une copie de chaque calque.
‫Dans ce système, l'un des principaux avantages est que nous ne stockons jamais les mêmes données d'image plus d'une
‫fois sur notre système de fichiers.
‫Cela signifie également que lors du téléchargement, nous n'avons pas besoin de télécharger
‫et de télécharger
‫les mêmes couches que celles que nous avons déjà de l'autre côté. Si vous deviez avoir votre propre image et que c'était
‫une coutume que vous ayez créée vous-même, vous avez ensuite ajouté, par exemple, un serveur Apache en plus de cela en tant que couche
‫supplémentaire dans votre fichier Docker, puis vous deviez ouvrir le port 80. Puis, à la fin, vous lui avez dit de copier le code source, mais vous avez
‫en fait deux fichiers Dockerfiles différents pour deux sites Web différents, et chaque ligne du fichier
‫Dockerfile était identique, à l'exception du dernier site où vous avez copié le site Web. A dans l'image, puis le
‫site Web B, vous obtiendrez deux images. Nous montrerons cela dans une minute. Cela constitue une image
‫et une image, mais les seuls fichiers réellement stockés sont celui-ci, celui-ci,
‫ce calque, puis ce petit calque, puis ce petit calque.
‫Nous ne stockons donc jamais plus d'une fois l'intégralité de la pile de calques d'image s'il s'agit réellement des mêmes calques.
‫Comment cela fonctionne-t-il avec les conteneurs?
‫Si vous avez votre image, disons que nous avons notre image Apache et que nous décidons d'exécuter un conteneur à partir
‫de celui-ci. Tout ce que Docker fait, c'est qu'il crée un nouveau calque de lecture / écriture pour ce
‫conteneur au-dessus de cette image Apache. Lorsque nous examinons le système de fichiers et tous ces
‫éléments, tous les conteneurs et les images ressemblent tous à un système de fichiers classique, mais sous le pilote de stockage
‫utilisé par Docker se superpose, comme une pile de pancakes, toutes ces modifications apportées
‫les uns sur les autres.
‫Ainsi, si j’exécutais deux conteneurs simultanément sur la même image Apache, les conteneurs 1 et 2 ne feraient que montrer, en
‫termes d’espace fichier, qu’ils feraient uniquement la différence entre ce qui s’est passé sur ce
‫conteneur en cours d’exécution et ce se passe dans l'image de base, qui est en lecture seule.
‫Lorsque vous exécutez Containers et modifiez des fichiers qui passaient dans l'image, supposons que
‫j'ai démarré le conteneur 3 et que je suis entré et ai modifié un fichier qui figurait dans cette image dans le conteneur en
‫cours d'exécution ...
‫c'est ce qu'on appelle copie sur écriture.
‫Qu'est-ce que cela fait est que le système de fichiers prendra ce fichier de l'image et le copiera dans cette différence ...
‫ici... et stocker une copie de ce fichier dans la couche conteneur.
‫Alors maintenant, le conteneur ne concerne que le processus en cours d'exécution
‫et les fichiers qui diffèrent de ceux figurant dans l'image Apache.
‫Si nous revenons à notre liste d’images et que nous regardons à nouveau ces commandes, nous regardons celle
‫du bas et voyons en quoi les dates sont différentes? Nous pouvons voir en réalité, lorsque cette image a été modifiée dans
‫Docker Hub et a été mise à jour au fil du temps, que ces modifications
‫n’ont pas été modifiées dans la couche inférieure en quatre semaines et que les dernières modifications ont eu lieu ces deux
‫dernières semaines.
‫Oh, au fait, ne vous inquiétez pas de la partie manquante.
‫C'est en fait un abus de langage dans l'interface de Docker.
‫Cela ne signifie pas que quelque chose ne va pas ou qu'il est mal configuré. Ce que cela signifie, c’est que vraiment, cette image
‫mysql ici est cet identifiant d’image.
‫Les autres couches de l'image ne sont pas réellement des images elles-mêmes.
‫Ce ne sont que des calques à l'intérieur
‫de cette image, de sorte qu'ils n'auraient pas nécessairement leur propre ID d'image.
‫Personnellement, je pense que dire cela est un peu trompeur dans l'interface, mais c'est ainsi qu'ils l'ont écrit.
‫Alors maintenant que nous avons une idée de la commande history pour
‫nous montrer de quoi une image peut être faite, utilisons la commande inspect.
‫Cela nous donne tous les détails sur l'image.
‫C'est fondamentalement les métadonnées. Rappelez-vous que lorsque nous avons parlé du fait
‫qu'une image est composée de deux parties, les fichiers binaires
‫et ses dépendances, et ensuite les métadonnées sur cette image? Eh bien, inspecter vous rend les métadonnées.
‫Outre les informations de base, telles que l'ID d'image et ses balises, vous obtenez toutes sortes de détails sur la manière dont
‫cette image doit être exécutée.
‫Il a en fait la possibilité d'exposer ces deux ports dans l'image pour que vous sachiez quand vous voulez le démarrer,
‫quels ports vous devez ouvrir à l'intérieur de votre hôte Docker si vous voulez qu'il accepte les connexions.
‫Vous pouvez réellement voir que les variables d'environnement ont été transmises, y compris la version
‫de Nginx en cours d'exécution et le chemin d'accès. Vous pouvez réellement voir la commande à exécuter lors du démarrage de
‫l'image par défaut.
‫Encore une fois, beaucoup de ces choses peuvent être changées comme nous l’avons déjà fait avec la commande
‫docker container run.
‫Mais ceux-ci nous montrent tous les paramètres par défaut et quelques autres informations intéressantes, comme l'auteur,
‫et ici, en bas, qu'il s'agit d'une architecture d'AMD64, qui est à peu près celle sur laquelle fonctionnent actuellement tous
‫les PC et Mac normaux.
‫Nous n'avons pas vraiment beaucoup de machines 32 bits, il s'agit donc d'une architecture Intel
‫64 bits standard conçue pour fonctionner sous le système d'exploitation Linux.
‫Ok, une revue rapide.
‫Nous avons donc beaucoup appris sur les images et leur composition, et nous
‫découvrons qu’elles ne sont pas si complexes. En réalité, il ne s'agit que d'une série de modifications apportées au système de fichiers et de métadonnées relatives à ces modifications.
‫Vous avez appris que chaque couche a sa propre identité unique en tant que SHA.
‫Ils ne sont stockés qu'une seule fois sur chaque système. Par conséquent, sur chaque démon Docker, chaque couche n'est représentée qu'une fois dans
‫le système de fichiers.
‫Cela nous permet d’économiser beaucoup d’espace et de transférer des images d’un registre
‫à l’autre, comme Docker Hub. Et, vraiment, lorsque vous démarrez un
‫conteneur, il ne s'agit que d'une couche de modifications au-dessus d'une image existante.
‫C'est donc généralement très petit. Nous avons appris l'histoire et les commandes d'inspection et comment elles peuvent
‫nous apprendre ce qui se passe dans une image et comment elle a été créée.