Principe de l'image Docker : système de fichiers commun et compréhension en couches (exemples détaillés)

Cet article vous apporte des connaissances pertinentes sur le système de fichiers commun et une compréhension en couches des principes de mise en miroir de Docker, y compris les problèmes liés aux systèmes de fichiers communs, aux structures hiérarchiques et aux pratiques en couches. J'espère qu'il sera utile à tout le monde.

Docker - Système de fichiers Union et compréhension en couches du principe de mise en miroir

1 Système de fichiers Union

UnionFS (Union File System)

UnionFS (Union File System) : Union File System (UnionFS) C'est. un système de fichiers en couches, léger et hautes performances. Il prend en charge les modifications du système de fichiers qui peuvent être superposées couche par couche en une seule soumission. En même temps, différents répertoires peuvent être montés sur le même système de fichiers virtuel (en regroupant plusieurs répertoires en un seul). un seul système de fichiers virtuel). Le système de fichiers Union est la base des images Docker. Les images peuvent être héritées par superposition. Sur la base de l'image de base (sans image parent), diverses images d'application spécifiques peuvent être produites.

De plus, différents conteneurs Docker peuvent partager certaines couches de base du système de fichiers et en même temps ajouter leurs propres couches de modifications uniques, améliorant considérablement l'efficacité du stockage.

L'AUFS (AnotherUnionFS) utilisé dans Docker est un système de fichiers union. AUFS prend en charge la définition d'autorisations en lecture seule, en lecture et en suppression pour chaque répertoire membre (similaire à une branche Git). En même temps, AUFS a un concept similaire aux hiérarchies pour les branches d'autorisation en lecture seule qui peuvent être logiquement modifiées de manière incrémentielle (sans affecter). la partie en lecture seule).

Docker prend actuellement en charge les types de systèmes de fichiers communs, notamment AUFS, btrfs, vfs et DeviceMapper.

Caractéristiques : chargez plusieurs systèmes de fichiers en même temps, mais de l'extérieur, un seul système de fichiers est visible. Le chargement conjoint superposera chaque couche de systèmes de fichiers, de sorte que le système de fichiers final contiendra tous les fichiers et répertoires sous-jacents. .

image de base

image de base signifie simplement qu'elle ne repose sur aucune autre image et est entièrement construite à partir de zéro. D'autres images sont construites dessus. Elle peut être comparée aux fondations d'un bâtiment et à l'auteur. d'images Docker.

l'image de base a deux significations : (1) Elle ne dépend pas d'autres images et est construite à partir de zéro (2) D'autres images peuvent être développées en fonction d'elle ;

Ainsi, ce que l'on peut appeler une image de base sont généralement des images Docker de diverses distributions Linux, telles que Ubuntu, Debian, CentOS, etc.

Principe de chargement de l'image Docker

L'image de Docker est en fait composée d'une couche de systèmes de fichiers, et cette couche de système de fichiers est UnionFS.

Linux typique nécessite deux FS pour démarrer et fonctionner, bootfs + rootfs :

bootfs (système de fichiers de démarrage) comprend principalement bpotloader et le noyau. Le chargeur de démarrage démarre et charge principalement le noyau Linux chargera le système de fichiers bootfs lorsque. il démarre en premier, au bas de l'image Docker se trouve bootfs. Cette couche est la même que celle de notre système Linux/Unix typique, y compris le chargeur de démarrage et le noyau du noyau. Une fois le chargement du démarrage terminé, l'intégralité du noyau est dans la mémoire. À ce moment, le droit d'utiliser la mémoire a été transféré de bootfs au noyau. À ce moment, le système désinstallera également bootfs.

rootfs (système de fichiers racine), au-dessus de bootfs. Contient des répertoires et des fichiers standard tels que /dev, /proc, /bin, /etc, etc. dans les systèmes Linux typiques. Les racines sont diverses distributions de systèmes d'exploitation, telles que Ubuntu, Centos, etc.

Pourquoi n'y a-t-il pas de noyau dans l'image Docker

En termes de taille d'image, une image relativement petite ne fait qu'un peu plus de 1 Ko, soit quelques Mo, alors que le fichier du noyau nécessite des dizaines de Mo, il n'y a donc pas noyau dans l'image. Après avoir été démarré en tant que conteneur, le noyau de l'hôte sera utilisé directement et l'image elle-même ne fournit que le rootfs correspondant, qui est le système de fichiers de l'espace utilisateur nécessaire au fonctionnement normal du système, tel que /dev. /, /proc, /bin, /etc, il n'y a donc pratiquement pas de répertoire /boot dans le conteneur, et /boot stocke les fichiers et répertoires liés au noyau.

Étant donné que le conteneur démarre et s'exécute directement en utilisant le noyau de l'hôte, il n'appelle pas directement le matériel physique, il n'implique donc pas de pilotes matériels, donc le noyau et les pilotes ne sont pas utilisés. Et si la technologie des machines virtuelles, chaque machine virtuelle a son propre noyau indépendant

2. Structure hiérarchique

L'image Docker est une structure en couches, chaque couche est construite au-dessus des autres couches, permettant ainsi une augmentation incrémentielle de la fonction du contenu. L'image Docker est également téléchargée en couches. Prenons l'exemple du téléchargement de l'image Redis :

Vous pouvez voir que la nouvelle image est générée à partir de l'image de base couche par couche. Chaque fois que vous installez un logiciel, vous ajoutez une couche à l'image existante.

Pourquoi l'image Docker adopte-t-elle cette structure en couches ?

Le plus grand avantage est le partage des ressources. Par exemple, si plusieurs images sont créées à partir de la même image de base, l'hôte n'a besoin de conserver qu'une seule image de base sur le disque, et une seule image de base doit être chargée dans la mémoire, afin qu'elle puisse servir tous les conteneurs. et chaque couche de l'image peut être partagée.

Couche de conteneur inscriptible

Les images Docker sont en lecture seule Lorsque le conteneur démarre, une nouvelle couche inscriptible est chargée au-dessus de l'image.

Ce nouveau calque est le calque conteneur inscriptible, et tout ce qui se trouve en dessous du conteneur est appelé le calque miroir.

Docker utilise une stratégie de copie sur écriture pour garantir la sécurité de l'image de base, ainsi que des performances et une utilisation de l'espace plus élevées.

• Lorsque le conteneur a besoin de lire un fichier

Commencez par la couche d'image supérieure et recherchez vers le bas, lisez-le dans la mémoire. S'il est déjà dans la mémoire, vous pouvez l'utiliser directement. En d’autres termes, les conteneurs Docker exécutés sur la même machine partagent les mêmes fichiers au moment de l’exécution.

• Lorsque le conteneur doit modifier un fichier

Recherchez de haut en bas et copiez-le dans la couche conteneur après l'avoir trouvé. Pour le conteneur, vous pouvez voir le fichier dans la couche conteneur, mais pas le fichier dans. la couche d'image, puis modifiez directement les fichiers au niveau de la couche conteneur.

• Lorsque le conteneur doit supprimer un fichier

Recherchez de haut en bas, et après l'avoir trouvé, enregistrez la suppression dans le conteneur. Ce n'est pas une véritable suppression, mais une suppression logicielle. Cela entraîne une augmentation et non une diminution de la taille de l'image.

• Lorsque le conteneur doit ajouter des fichiers

ajoutez-les directement au calque inscriptible le plus haut du conteneur sans affecter le calque d'image.

Toutes les modifications apportées au conteneur, qu'il s'agisse d'ajout, de suppression ou de modification de fichiers, n'auront lieu que dans la couche conteneur. Seule la couche conteneur est accessible en écriture et toutes les couches d'images situées sous la couche conteneur sont en lecture seule, de sorte que l'image peut être partagée par plusieurs conteneurs.

3. Pratique de superposition - engagez-vous à soumettre l'image

Créez un conteneur à travers l'image, puis exploitez la couche conteneur, conservez la couche image inchangée, puis emballez la couche conteneur exploitée et la couche image dans une nouvelle image pour la soumission.

docker commit : créez une nouvelle image avec un conteneur.

Syntaxe :

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

OPTIONS description :

• **-a*L'auteur de l'image soumise
• **-c*Utilisez la commande Dockerfile pour créer l'image
• **-m *Le texte de description ; lors de la soumission ;
• **-p * Mettre le conteneur en pause lors de la validation.

Exemple d'utilisation : créez un conteneur via une image, puis exploitez la couche conteneur, puis emballez la couche conteneur exploitée et la couche d'image dans une nouvelle image à soumettre.

1. Téléchargez d'abord l'image Tomcat

2. Créez et exécutez le conteneur Tomcat via l'image Tomcat :

docker run -d --name="tomcat01" tomcat

3. Entrez le conteneur Tomcat en cours d'exécution :

docker exec -it tomcat01 /bin/bash

4. du conteneur Tomcat dans le répertoire webapps :

cp -r webapps.dist/* webapps

5. Docker commit Soumettez l'image

Enregistrez le conteneur dc904437d987 en tant que nouvelle image et ajoutez les informations de l'émetteur et les informations de description. L'image soumise est nommée tomcatplus et la version est. 1.0 :

docker commit -a="wanli" -m="add webapps files" dc904437d987 tomcatplus:1.0

Vous pouvez voir que la taille de la nouvelle image Tomcat après la validation est un peu plus grande que l'image Tomcat d'origine car nous avons copié les fichiers dans la couche conteneur.

Apprentissage recommandé : "Tutoriel vidéo Docker"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!