Architecture logicielle-technologie du conteneur Docker

table des matières

La composition du moteur de conteneur

Prenons tout d'abord l'exemple du moteur de conteneur containerd de la CNCF pour décrire la composition générale du moteur de conteneur.

Si vous le divisez entre les côtés gauche et droit dans la figure ci-dessus, vous pouvez penser que containerd fournit deux fonctions principales.

1. runtime , qui est la gestion du cycle de vie du conteneur.
2. stockage , c'est-à-dire la gestion d'un stockage en miroir.

Selon le niveau de vue:

• La première couche est GRPC. Pour la couche supérieure, containerd fournit des services à la couche supérieure sous la forme de service GRPC. Métriques Cette partie fournit principalement du contenu des métriques de groupe de contrôle;
• Le côté gauche de la couche inférieure est un stockage d'images de conteneurs, le milieu d'images, de conteneurs et le bas de métadonnées. Cette partie des métadonnées est stockée sur le disque via bootfs. Les tâches sur la droite représentent la structure du conteneur du conteneur de gestion. Evénements signifie que certaines opérations sur le conteneur auront un événement envoyé à la couche supérieure, puis la couche supérieure pourra s'abonner à cet événement, sachant ainsi quels changements se sont produits dans l'état du conteneur;
• La couche inférieure est la couche Runtimes. Ces Runtimes peuvent être distingués par type, tel que runC ou conteneur kata.

Composants Docker

L'architecture logicielle de Docker comprend:

• Client Docker : lancez une demande au processus Docker Server, telle que la génération, l'extraction, l'exécution et d'autres opérations. Le client Docker peut accéder à la fois au processus démon local (hôte local) et au processus démon distant (hôte distant).
• Serveur Docker : écoutez les demandes de l'API REST et gérez les objets Docker, tels que les images, les conteneurs, les réseaux et les volumes. Le démon peut également communiquer avec d'autres démons pour gérer les services Docker.
• Docker Registry (registre, serveur d'enregistrement d'entrepôt) : un entrepôt central qui stocke les images Docker. Parmi eux, Docker Hub est un registre public que tout le monde peut utiliser. La configuration par défaut de Docker Server est de rechercher des images sur Docker Hub. Les particuliers peuvent également exécuter un registre privé. Si Docker DataCenter est utilisé, il inclut Docker Trusted Registry (DTR). Lorsque vous utilisez la commande docker pull ou docker run, l'image requise sera extraite du registre configuré par Docker Server.

Notez qu'il existe une différence entre le référentiel et le registre. Il y a souvent plusieurs référentiels stockés sur le registre, et chaque référentiel contient plusieurs images, et chaque image a une balise différente.

Architecture logicielle de Docker

Comme le montre la figure ci-dessus, les principaux modules de Docker sont:

• Client Docker
• Démon Docker
• Registre Docker
• Graphique
• Chauffeur
• Libcontainer
• Conteneur Docker

Les utilisateurs utilisent Client pour établir la communication avec Daemon et envoyer des requêtes à ce dernier. Daemon, en tant que noyau de Docker, fournit d'abord au Serveur pour accepter les requêtes du Client, puis exécute une série de tâches dans Docker via Engine. Chaque tâche est basée sur un Job. L'existence de la forme.

• Lorsqu'il est nécessaire de fournir une image pour le conteneur, téléchargez l'image à partir du registre et utilisez la gestion des images pour conduire Graphdriver à stocker l'image téléchargée sous la forme de Graph;
• Lorsque vous devez créer un environnement réseau pour le conteneur, créez et configurez l'environnement réseau du conteneur via le pilote de gestion réseau Networkdriver;
• Lorsqu'il est nécessaire de limiter les ressources en cours d'exécution ou d'exécuter des instructions utilisateur pour le conteneur, cela se fait via Execdriver.

Libcontainer est un module de gestion de conteneur indépendant. Networkdriver et Execdriver utilisent tous deux Libcontainer pour effectuer les opérations sur le conteneur. Après l'exécution d'une série de tâches d'exécution du docker, un conteneur réel est en cours d'exécution. Le conteneur dispose d'un système de fichiers indépendant, d'un environnement d'exploitation indépendant et sûr, etc.

Client Docker

Le client Docker apparaît comme un fichier exécutable docker sous Linux. Une fois que le client reçoit la réponse renvoyée par Daemon et effectue un traitement simple, le cycle de vie complet du client est terminé. Le client peut établir la communication avec Daemon de 3 manières:

1. tcp: // hôte: port
2. unix: chemin_à_socket; fd: // socketfd
3. Configurer la connexion TLS en définissant les paramètres de ligne de commande

Démon Docker

Docker Daemon apparaît comme un processus système qui réside en arrière-plan sous Linux et peut être géré par systemd. En fait, il s'agit du même fichier exécutable docker que Docker Client.

Docker Daemon peut être subdivisé en modules suivants:

• Serveur API : Daemon démarrera un serveur Docker en arrière-plan. Il s'agit d'un serveur API basé sur le package Gorilla / Mux de Golang. Il accepte les requêtes envoyées par les clients et les achemine vers différents gestionnaires pour traitement.

Il est à noter que le démarrage de Docker Server se fait en exécutant un Job nommé serveapi. Ainsi, l'essence de Server est l'un des nombreux emplois.

• Moteur : C'est le moteur de Docker, il joue le rôle d'entrepôt de stockage Docker Container et manipule et gère ces conteneurs en exécutant Job. Docker Engine a deux versions différentes: Docker Engine Enterprise (Enterprise Edition) et Docker Engine Community (Community Edition).

• Job : un Job peut être considéré comme l'unité d'exécution de travail la plus élémentaire du moteur. Chaque travail effectué par Docker peut être résumé dans un Job. Par exemple: exécuter un processus à l'intérieur du conteneur, c'est un travail; créer un nouveau conteneur, c'est un travail, télécharger un document depuis Internet, c'est un travail, etc. Le concepteur de Job a conçu Job pour être similaire à Unix Processor. Par exemple: le travail a un nom, des paramètres, des variables d'environnement, une entrée et une sortie standard, une gestion des erreurs et un état de retour.

Registre Docker

Docker Registry est un référentiel pour stocker des images. Pendant le fonctionnement de Docker, Daemon communiquera avec le Registre et implémentera trois fonctions: rechercher des miroirs, télécharger des miroirs et télécharger des miroirs. Les jobs correspondant à ces trois fonctions sont la recherche, le pul et le push.

Docker peut utiliser le registre Docker public, à savoir: Docker Hub, à partir duquel vous pouvez trouver des images Docker de projets open source, de fournisseurs de logiciels et même de comptes personnels. Dans le même temps, Docker permet également aux utilisateurs de créer un registre Docker privé local, qui peut garantir que l'acquisition d'images de conteneurs est terminée sur l'intranet.

Graphique

Graph agit en tant que gardien des miroirs téléchargés et enregistreur de la relation entre les miroirs téléchargés. D'une part, Graph stocke les miroirs du système de fichiers local avec les informations de version, et d'autre part, il enregistre également la relation entre tous les miroirs du système de fichiers via GraphDB.

Parmi eux, GraphDB est une petite base de données de graphes construite sur SQLite, qui implémente la dénomination des nœuds et l'enregistrement de la relation entre les nœuds. Il n'implémente qu'un petit sous-ensemble de la plupart des bases de données de graphes, mais fournit une interface simple pour représenter la relation entre les nœuds.

Dans le même temps, dans le répertoire local de Graph, à propos de chaque image de conteneur, les informations spécifiques stockées sont: les métadonnées de l'image de conteneur, les informations de taille de l'image de conteneur et les Rootfs spécifiques représentés par l'image de conteneur.

Chauffeur

Driver est le module de pilote et Docker utilise Driver pour personnaliser l'environnement d'exécution du conteneur. Peut être divisé en trois types de pilotes suivants:

1. Pilote graphique
2. Pilote de réseau
3. Execdriver

Pilote graphique

Graphdriver est utilisé pour terminer la gestion des images, y compris le stockage et la récupération. Lorsque l'utilisateur a besoin de télécharger l'image spécifiée, Graphdriver stockera l'image dans le répertoire local spécifié; lorsque l'utilisateur doit utiliser l'image spécifiée pour créer les Rootfs du conteneur, Graphdriver obtiendra l'image de conteneur spécifiée à partir du répertoire de stockage d'images local.

Avant l'initialisation de Graphdriver, 4 types de systèmes de fichiers ou de systèmes de type fichier y sont enregistrés. Ils sont:

1. Sur
2. Btrfs
3. VFS
4. Devmapper

Lorsque Graphdriver est initialisé, il obtient la variable d'environnement système DOCKER_DRIVER pour extraire le type spécifié de pilote utilisé. Toutes les opérations graphiques suivantes sont exécutées à l'aide de ce pilote.

L'architecture de Graphdriver est la suivante:

Pilote de réseau

Networkdriver est utilisé pour terminer la configuration de l'environnement réseau du conteneur, notamment:

• Créer un pont pour le démon Docker lorsqu'il démarre;
• Créez un périphérique de carte réseau virtuelle dédié pour le conteneur lors de sa création, attribuez une adresse IP et un port au conteneur, effectuez le mappage de port avec l'hôte et définissez la stratégie de pare-feu du conteneur.

L'architecture de Networkdriver est la suivante:

Execdriver

En tant que pilote d'exécution du conteneur, Execdriver est responsable de la création de l'espace de noms d'exécution du conteneur, responsable des statistiques et des restrictions d'utilisation des ressources du conteneur, et responsable du fonctionnement réel des processus internes du conteneur.

Lors de la première implémentation d'Execdriver, LXC Driver était utilisé pour appeler l'interface de LXC afin de manipuler la configuration et le cycle de vie du conteneur. Désormais, Execdriver utilise le pilote natif par défaut et ne dépend plus de LXC. Il peut être sélectionné en spécifiant le paramètre ExecDriverflag lors du démarrage de Daemon. La valeur par défaut est native.

L'architecture d'Execdriver est la suivante:

Libcontainer

Libcontainer est une bibliothèque implémentée dans Golang dans l'architecture Docker. L'intention initiale de la conception est que la bibliothèque puisse accéder directement aux API liées aux conteneurs dans le noyau sans dépendre d'aucune dépendance.

C'est précisément grâce à l'existence de Libcontainer que Docker peut enfin manipuler l'espace de noms, les groupes de contrôle, l'Apparmor, l'équipement réseau et les règles de pare-feu du conteneur. L'achèvement de cette série d'opérations n'a pas besoin de s'appuyer sur LXC ou d'autres bibliothèques.

L'architecture de Libcontainer est la suivante:

Docker supprime le runtime du conteneur sous-jacent pour obtenir une meilleure indépendance de la plateforme. LibContainer est une abstraction de divers conteneurs, développée en RunC, et a contribué à l'organisation OCP en tant que standard pour définir l'environnement du conteneur.

Conteneur Docker

Docker Container devient un processus de conteneur s'exécutant sur le système d'exploitation Linux, qui est la forme finale de la fourniture de services Docker.

• L'utilisateur peut spécifier l'image afin que le conteneur puisse personnaliser le système de fichiers tel que Rootfs.
• L'utilisateur spécifie le quota de ressources informatiques pour permettre au conteneur d'utiliser les ressources informatiques spécifiées.
• L'utilisateur configure le réseau et ses politiques de sécurité pour permettre au conteneur d'avoir un environnement réseau indépendant et sécurisé.
• L'utilisateur oblige le conteneur à effectuer le travail spécifié en spécifiant la commande à exécuter.