Introduction
Récemment, lors d'un échange de localisation d'OS, j'ai appris que lorsque certaines entreprises migrent vers BClinux 8.2 ou Anolis 8.2, l'activité docker d'origine doit être migrée vers une nouvelle plateforme de conteneurs : Podman pour compléter la nouvelle gestion des conteneurs. Podman (nom complet Pod Manager) est un outil open source permettant de développer, gérer et exécuter des conteneurs sur les systèmes Linux®. Développé à l'origine par les ingénieurs Red Hat® en collaboration avec la communauté open source, Podman exploite la bibliothèque lipod pour gérer tout un écosystème de conteneurs. L'affirmation officielle : Podman - La nouvelle génération d'outils de conteneurs Linux, il peut non seulement gérer les conteneurs OCI, mais également les pods.
Podman est un outil de gestion de conteneurs open source publié par RedHat . Son intention initiale est de remplacer Docker. Il est similaire à Docker utilisé, mais il est très différent. La plus grande différence entre Docker et Docker est l'architecture . Docker fonctionne sur l'architecture C/S. La commande docker que nous utilisons habituellement n'est qu'une interface de ligne de commande. Elle doit appeler dockerd pour terminer l'opération réelle, et dockerd est un privilège root par défaut.Démon. Podman n'a pas besoin de processus démon et démarre le conteneur directement via fork/exec sans privilèges root. C'est également l'un des plus grands avantages de Podman. Il adopte une architecture inclusive sans processus démon, qui peut gérer les conteneurs de manière plus sûre et plus simple. Couplé aux outils et fonctions de support tels que Buildah et Skopeo, les développeurs peuvent Il joue en fait le même rôle que Docker et est largement compatible avec Docker, fournissant presque les mêmes commandes. En bref, Podman est un runtime de conteneur développé sur la base de la bibliothèque libpod pour gérer et exécuter des conteneurs sur le système d'exploitation Linux. Contrairement au runtime de conteneur Docker traditionnel, Podman n'a pas besoin de dépendre du démon Docker et peut s'exécuter indépendamment dans différentes distributions Linux. Il prend en charge les fonctions courantes de gestion des conteneurs, telles que le démarrage, l'arrêt, le redémarrage et la suppression de conteneurs, ainsi que la création, le transfert et l'extraction d'images de conteneurs. Podman prend également en charge la gestion des réseaux de conteneurs et du stockage, peut utiliser des plug-ins CNI pour créer et gérer des réseaux de conteneurs et prend en charge l'utilisation de plusieurs pilotes de stockage, tels que overlayfs, btrfs et zfs.
Une caractéristique notable de Podman est qu'il utilise le mode sans racine, ce qui signifie qu'il peut être exécuté avec les privilèges utilisateur normaux et ne nécessite pas de privilèges root. Cela contribue à améliorer la sécurité et la portabilité des opérations de conteneurs. Dans le même temps, Podman prend en charge la gestion d'un groupe de conteneurs associés via des Pods, qui peuvent facilement gérer des applications complexes.
De plus, Podman prend également en charge l'utilisation de systemd pour gérer les conteneurs, ce qui le rend mieux intégré aux systèmes Linux, exécutant et gérant avec d'autres services système. Mais dans tous les cas, en tant que moteur d'exécution, la couche inférieure de Podman est principalement basée sur des technologies telles que Cgroup et Namespace de Linux.
Podman peut m'aider à réaliser les objectifs suivants :
Gérez les images de conteneurs et le cycle de vie complet des conteneurs, y compris l'exécution, la mise en réseau, la vérification et le déploiement.
Exécutez et isolez les ressources pour les conteneurs et les pods sans racine.
Les images OCI et Docker sont prises en charge, ainsi qu'une CLI compatible Docker.
Créez un environnement sans démon qui augmente la sécurité et réduit la consommation de ressources inutilisées.
Déployez une API REST pour prendre en charge les fonctionnalités avancées de Podman.
Implémentez un point de contrôle/restauration pour les conteneurs Linux avec un point de contrôle/restauration dans l'espace utilisateur (CRIU). CRIU peut geler les conteneurs en cours d'exécution et enregistrer le contenu et l'état de leur mémoire sur le disque afin que les charges de travail conteneurisées puissent être redémarrées plus rapidement.
Mettez automatiquement à jour les conteneurs. Podman détecte si un conteneur mis à jour ne démarre pas et revient automatiquement à la dernière version fonctionnelle. Cela peut porter la fiabilité des applications à de nouveaux niveaux.
Informations associées : containersd , Podman , introduction de Podman , site officiel , projet Podman
2. Structure et fonction
2.1, exécution d'exécution
"Runtime" correspond au moment où le programme est en cours d'exécution, c'est-à-dire lorsque les instructions sont chargées dans la mémoire et exécutées par le processeur. En fait, il s'agit d'une API en langage C pur de niveau relativement bas. Il s'agit d'une bibliothèque de langage C qui contient de nombreuses API en langage C de bas niveau pour une meilleure communication avec le noyau Linux. Cela correspond au "temps de compilation", qui fait référence au moment où le code est compilé, c'est-à-dire lorsque le code C est compilé dans un fichier exécutable et que l'instruction n'est pas exécutée par le CPU à ce moment-là. La bibliothèque d'exécution correspondante est la bibliothèque dont le programme doit dépendre lors de son exécution.
Chaque environnement a son propre runtime. Ici, nous passons principalement en revue le runtime de conteneur (runtime), qui est un outil pour exécuter et gérer des processus et des images de conteneur. Il peut exécuter des processus dans des conteneurs et appeler Linux via un SDK ou des commandes. Fonctions du noyau pour créer des conteneurs ou d'autres éléments sous-jacents associés aux conteneurs. Le runtime est clairement défini dans une organisation OCI (Open Container Initiative). OCI a publié deux spécifications : la spécification d'exécution et la spécification de format d'image ; de cette manière, les conteneurs développés par différentes organisations et fabricants sur la base de cette spécification peuvent fonctionner sur différents environnements d'exécution, garantissant ainsi la portabilité et l'interopérabilité des conteneurs. Cette spécification stipule quel type d'environnement et comment exécuter l'application dans le conteneur. Par exemple, quel fichier exécutable sera exécuté sur le système de fichiers racine du conteneur, quel utilisateur sera utilisé pour l'exécuter, quel type de processeur est nécessaire. , et quel type de ressources de mémoire, de stockage externe et quel type d'exigences de partage, etc. Comme mentionné ci-dessus, le runtime est l'endroit où le conteneur (qui peut être compris comme un processus indépendant) s'exécute réellement. L'ensemble du processus doit fonctionner en étroite collaboration avec le noyau du système d'exploitation pour fournir un environnement d'exécution pour le conteneur. Par exemple : dans l'exemple d'environnement Java courant, un programme Java peut être considéré comme un conteneur et une JVM comme un environnement d'exécution. JVM fournit un environnement d'exécution pour les programmes Java. De la même manière, les conteneurs ne peuvent s’exécuter qu’au moment de l’exécution.
Présentation de la spécification OCI :
La spécification d'image (souvent appelée "images OCI 1.0") définit le contenu de l'image du conteneur. La
spécification d'exécution (souvent appelée "CRI (Container Runntime Interface) 1.0" ou interface d'exécution du conteneur) exprime la "configuration de le conteneur, l'environnement d'exécution et le cycle de vie". L'interface d'exécution de conteneur (Container Runtime Interface, CRI) fait référence à l'interface de plug-in selon laquelle l'application de couche supérieure peut prendre en charge plusieurs environnements d'exécution de conteneur sans compilation, et les conteneurs de différents packages peuvent être appliqués via la commutation de plug-ins.
La Container Networking Interface (CNI) décrit comment configurer les interfaces réseau à l'intérieur des conteneurs, bien qu'elle soit standardisée sous CNCF et non sous OCI.
Il existe actuellement trois environnements d'exécution de conteneurs courants :
LXC est un environnement d'exécution de conteneur vétéran sous Linux. Docker utilisait à l'origine lxc comme moteur d'exécution. lxc est l'outil de gestion de lxd.
runc est un runtime de conteneur développé par Docker lui-même, qui est conforme à la spécification oci et constitue désormais le runtime par défaut de Docker. Après que Docker ait fait don de sa technologie de base de conteneur libcontainer à OCI (Open Container Initiative), il a changé son nom en runC. L'outil de gestion de Runc est le moteur Docker. Le moteur Docker comprend deux parties : le démon d'arrière-plan et le cli. Le Docker qui est souvent mentionné fait référence au moteur Docker.
rkt est un runtime de conteneur développé par CoreOS, conforme à la spécification oci, il peut donc exécuter des conteneurs Docker. L'outil de gestion de Rkt est rkt cli.
Avec le développement actuel, d'autres runtimes sont apparus, tels que Kata Container, CRI-O, etc. Au début, Docker utilisait LXC mais l'isolation des couches n'était pas complète, donc Docker a développé libcontainer, et a finalement évolué vers runC.
Le Runtime définit principalement les spécifications suivantes et les enregistre dans le fichier /run/docker/runtime-runc/moby/container ID/state.json au format json. Ce fichier mettra à jour le contenu en temps réel en fonction de l'état du conteneur :
Informations sur la version : stocke le numéro de version spécifique de la norme OCI.
ID du conteneur : généralement une valeur de hachage, qui peut être extraite de tous les fichiers state.json pour effectuer
des opérations par lots sur les conteneurs (fermer, supprimer, etc.), ce fichier sera supprimé après la fermeture du conteneur, et sera automatiquement généré après le conteneur démarre.
PID : numéro de processus du premier processus exécuté dans le conteneur sur la machine hôte, c'est-à-dire que le processus de la machine hôte est défini comme
processus démon du conteneur.
Répertoire du fichier conteneur : le répertoire dans lequel sont stockés les rootfs du conteneur et les configurations correspondantes. Les programmes externes n'ont besoin que de lire state.json pour
localiser le répertoire du fichier conteneur sur la machine hôte.
Création de conteneurs : créez divers contenus, notamment le système de fichiers, les espaces de noms, les groupes de contrôle et les autorisations utilisateur.
Démarrez le processus du conteneur : exécutez le processus de démarrage du conteneur, le fichier se trouve dans
/run/containerd/io.containerd.runtime.v1.linux/moby/container ID/config.json.
Cycle de vie du conteneur : le processus du conteneur peut être arrêté par un programme externe. La spécification d'exécution définit la
capture des signaux de fonctionnement du conteneur et effectue le traitement de récupération des ressources correspondant pour éviter l'émergence de processus zombies.
L'image du conteneur OCI comprend principalement le contenu suivant :
Système de fichiers : définit le système de fichiers enregistré par calque. Dans l'image, il s'agit de layer.tar. Chaque calque enregistre
la partie qui change entre le calque et le calque supérieur. La spécification du format d'image définit quels fichiers doivent être enregistrés par le calque, et comment
exprimer l'ajout, la modification et les fichiers supprimés, etc.
fichier manifeste : décrivez les couches, les étiquettes de balise et le nom du fichier de configuration.
fichier de configuration : il s'agit d'un fichier json nommé d'après hash, qui enregistre la plate-forme d'image et
certaines informations nécessaires à l'exécution du conteneur lorsque le conteneur est en cours d'exécution, telles que les variables d'environnement, le répertoire de travail, les paramètres de commande, etc.
fichier d'index : un fichier facultatif, pointant vers les fichiers manifestes de différentes plates-formes, ce fichier peut garantir qu'un miroir
peut être utilisé sur toutes les plates-formes, chaque plate-forme a un fichier manifeste différent utilisant index comme index.
Image parent : la structure de méta-informations de la plupart des calques contient un champ parent, pointant vers l'image parent de l'image.
Paramètres :
ID : ID miroir, chaque couche possède une
balise d'ID Balise : La balise est utilisée pour mapper le nom descriptif spécifié par l'utilisateur à l'ID miroir
Warehouse : Entrepôt miroir du référentiel
os :
architecture de type de définition : définir l'architecture du processeur
auteur : auteur Informations
créer : date de création de l'image
Le moteur d'exécution du conteneur a la capacité de contrôler l'intégralité du cycle de vie du fonctionnement du conteneur, y compris la création et la gestion des images, l'exploitation et la gestion du conteneur, ainsi que d'autres fonctions. L'interface d'exécution de conteneur (Container Runtime Interface, CRI) fait référence à l'interface de plug-in selon laquelle l'application de couche supérieure peut prendre en charge plusieurs environnements d'exécution de conteneur sans compilation, et les conteneurs de différents packages peuvent être appliqués via la commutation de plug-ins. Le runtime du conteneur fournit une interface d'appel de conteneur vers le haut, y compris les fonctions de gestion du cycle de vie complet de génération et de destruction des conteneurs, et fournit une interface d'appel vers le bas responsable des opérations de conteneur spécifiques. Par exemple, dans un cluster Kubernetes typique, Kubernetes ne prend pas en charge des conteneurs spécifiques. Sachant que, bien que l'API du client CRI soit implémentée via le kubelet proxy de nœud Kubernetes, tout environnement d'exécution de conteneur qui implémente l'API du serveur CRI peut être utilisé pour gérer les conteneurs et les pods sur ses nœuds.
Selon les fonctions fournies par le runtime du conteneur, le runtime du conteneur peut être divisé en runtime de bas niveau et en runtime de haut niveau.
1) Le runtime de bas niveau est principalement responsable de la gestion du système d'exploitation hôte, de l'exécution du processus de conteneur sur l'hôte selon l'image du conteneur spécifiée et de la gestion de l'ensemble du cycle de vie du conteneur. Et ce runtime de bas niveau est le composant responsable de l'exécution des opérations de base telles que la définition de l'espace de noms du conteneur et des groupes C que nous avons expliqués plus tôt. Les types d'exécution de bas niveau courants sont :
RunC : Le runtime traditionnel, basé sur la technologie Linux Namespace et Cgroups, représente la réalisation de Docker
RunV : Le runtime basé sur le programme de gestion de machine virtuelle, grâce à la virtualisation du noyau invité, isole le conteneur de l'hôte, rendant sa limite plus claire , représentant L'implémentation est Kata Container et Firecracker
Runsc: runc + safety, qui intercepte tous les appels système de l'application et fournit un bac à sable d'exécution de conteneur léger pour l'isolation de la sécurité. L'implémentation représentative est gVisor de Google
2) Le runtime de haut niveau est principalement responsable de la gestion et de la transformation de l'image, effectuant les préparatifs préalables au fonctionnement du conteneur. Les principaux environnements d'exécution de haut niveau sont principalement containersd et CRI-O.
Le runtime de haut niveau et le runtime de bas niveau remplissent leurs propres tâches. Le runtime du conteneur télécharge généralement d'abord l'image du conteneur à partir du runtime de haut niveau, la décompresse et la convertit en un fichier de système d'exploitation requis pour l'exécution du conteneur, et puis démarre et gère le conteneur par le runtime de bas niveau.
En outre, il existe également un moteur de conteneurs, containersd, qu'il convient de noter ici. En 2020, la Fondation CNCF a annoncé que la version 1.20 de Kubernetes ne prendrait plus uniquement en charge les outils de gestion de conteneurs Docker ; l'ancien Docker 1.11 incluait containersd dans le moteur Docker, et maintenant containersd. Le Docker Engine a été entièrement séparé et développé indépendamment en tant que projet open source indépendant, dans le but de fournir une infrastructure d'exécution de conteneurs plus ouverte et plus stable. Par rapport à containersd dans Docker Engine, le containers indépendant aura plus de fonctions et pourra couvrir tous les besoins de l'ensemble de la gestion du runtime du conteneur. De plus, après l'indépendance, l'évolution des fonctionnalités de containersd peut être séparée de Docker Engine, en se concentrant sur la gestion du temps d'exécution des conteneurs, qui peut être plus stable.
Containerd est un environnement d'exécution de conteneur standard, axé sur la simplicité, la robustesse et la portabilité. Il peut s'exécuter comme un processus démon sous Linux et Windows. Il peut gérer le cycle de vie complet des conteneurs sur le système hôte : transmission et stockage d'images. , conteneurs Exécution et surveillance du stockage et de la mise en réseau de bas niveau. Chaque conteneur n'est responsable que d'une seule machine, de l'image d'extraction, des opérations du conteneur (démarrage, arrêt, etc.), du réseau et du stockage sont tous effectués par conteneurd. Le conteneur en cours d'exécution spécifique est responsable de runC, en fait, tant que le conteneur est conforme à la spécification OCI, il peut le prendre en charge.
Containerd est différent de Docker. Containerd se concentre sur l'intégration dans des systèmes à grande échelle , tels que Kubernetes, Swarm, Mesos, etc. [Pour les services d'orchestration de conteneurs, seul containersd+runC est nécessaire au moment de l'exécution, ce qui est plus léger et plus facile à gérer. 】. Containerd est conçu pour être intégré dans un système plus vaste, et non pour être utilisé directement par les développeurs ou les utilisateurs finaux.
2.2. Comment Podman gère-t-il les conteneurs ?
Les utilisateurs peuvent appeler Podman via la ligne de commande pour extraire des conteneurs des référentiels et les exécuter. Podman appelle le runtime de conteneur configuré pour créer des conteneurs en cours d'exécution. Sans démon dédié, Podman utilise systemd (un gestionnaire de systèmes et de services pour les systèmes d'exploitation Linux) pour mettre à jour et faire fonctionner les conteneurs en arrière-plan. En intégrant systemd à Podman, nous pouvons générer des unités de contrôle pour les conteneurs et les exécuter avec systemd automatiquement activé.
Les utilisateurs peuvent gérer leurs propres référentiels sur le système et contrôler le démarrage et la gestion automatiques de leurs propres conteneurs via les unités systemd. Permettre aux utilisateurs de gérer leurs propres ressources et de faire fonctionner les conteneurs sans racine évite les mauvaises pratiques telles que rendre le répertoire /var/lib/containers accessible en écriture ou d'autres pratiques de gestion du système qui pourraient exposer l'application à des problèmes de sécurité supplémentaires. Cela garantit également que chaque utilisateur dispose d'un ensemble distinct de conteneurs et d'images et peut utiliser Podman simultanément sur le même hôte sans interférer les uns avec les autres. Au fur et à mesure que les utilisateurs terminent leur travail, ils peuvent appliquer des modifications à un référentiel de miroirs partagé, partageant ainsi leurs miroirs avec d'autres.
Podman peut également déployer une API RESTful (API REST) pour gérer les conteneurs. REST est un acronyme pour Representational State Transfer. L'API REST est une interface de programmation d'applications qui suit la spécification de l'architecture REST et prend en charge l'interaction avec les services Web RESTful. Avec l'API REST, vous pouvez appeler Podman à partir de nombreuses plates-formes, notamment cURL, Postman et le client Advanced REST de Google.
3. Configuration du déploiement
4. Application de l'outil
4.1
4.2. Outil de gestion de bureau Podman
Podman Desktop vous permet d'utiliser facilement des conteneurs dans votre environnement local, Podman Desktop est sans démon, il utilise Podman Engine pour fournir des outils de conteneur légers et sans démon. L'outil permet de parcourir, de gérer le cycle de vie des conteneurs, d'inspecter les conteneurs, les images de différents moteurs de conteneurs, etc. De plus, bien qu'il se concentre sur l'utilisation de Podman comme moteur de conteneur packagé par défaut, il est également compatible avec d'autres moteurs de conteneur. Podman Desktop possède certaines des fonctionnalités suivantes :
- Gérer les conteneurs : répertoriez, recherchez, inspectez, connectez, exécutez et arrêtez les conteneurs.
- Créez, extrayez et envoyez des images : créez des images à partir de l'outil, extrayez et envoyez des images en gérant les référentiels et exécutez des conteneurs à partir de ces images.
- Gérer les ressources Podman : afficher la mémoire allouée, le processeur et le stockage ; créer de nouvelles machines si nécessaire
- Compatible avec l'extension de bureau Docker : Spécifiez l'image OCI de l'extension de bureau Docker pour l'importer.
- Podman Desktop a la possibilité d'utiliser les plugins de l'interface utilisateur Docker Desktop en ajoutant des wrappers pour intercepter les appels API. Vous pouvez étendre les fonctionnalités de Podman Desktop en ajoutant des extensions Docker Desktop. Les plugins peuvent également être utilisés en arrière-plan pour gérer différents moteurs de conteneurs. En ajoutant de nouveaux plugins.
Acquisition de ressources : packages binaires
5. Annexe :
5.1. Examen de Containerd
Comme le montre la figure ci-dessus, docker nous fournit une interface d'appel de conteneur abstraite, tandis que l'implémentation spécifique de ses fonctions internes est appelée contanierd ; en 2016, docker a divisé le module containersd responsable du cycle de vie du conteneur et l'a fait don à la communauté.
Caractéristiques de Containerd :
API concise basée sur gRPC et bibliothèque client.
Prise en charge complète d'OCI (environnement d'exécution et spécifications d'image).
Fonctionnalité de base du conteneur bien définie avec à la fois stabilité et hautes performances.
Un système découplé (découplage de l'image, du système de fichiers et du runtime) permet l'extension et la réutilisation des plug-ins.
Le rôle de Containerd :
Gérer le cycle de vie des conteneurs (de la création du conteneur à la destruction du conteneur).
Tirer/pousser des images de conteneurs.
Gestion du stockage (gestion de l'image et stockage des données du conteneur).
Appelez runC pour exécuter le conteneur (interagissez avec les environnements d'exécution du conteneur tels que runC).
Gérez les interfaces réseau et la mise en réseau des conteneurs.
En utilisant bucketbench pour tester les performances de Docker, crio et Containerd, y compris le démarrage, l'arrêt et la suppression de conteneurs, pour comparer le temps qu'ils prennent, on peut constater que Containerd fonctionne bien dans tous les aspects et que ses performances globales sont meilleures que Docker et crio.
Architecture Containerd : Containerd adopte une architecture C/S standard : le serveur fournit une API stable via le protocole GRPC ; le client effectue des opérations avancées en appelant l'API du serveur. Afin de réaliser le découplage, Containerd divise les différentes responsabilités en différents composants, et chaque composant équivaut à un sous-système. Les composants qui connectent différents sous-systèmes sont appelés modules. containersd doit appeler runC, veuillez donc installer runC avant d'installer containersd.
L'architecture technique de containersd :
Containerd est divisé en trois morceaux : stockage, métadonnées et runtime.
Les deux sous-systèmes de Containerd sont :
Bundle : dans Containerd, Bundle contient des données de configuration, de métadonnées et de système de fichiers racine, que vous pouvez comprendre comme le système de fichiers du conteneur. Et le sous-système Bundle permet aux utilisateurs d'extraire et de regrouper des bundles à partir d'images.
Runtime : Le sous-système Runtime est utilisé pour exécuter des Bundles, comme la création de conteneurs. Parmi eux, le comportement de chaque sous-système est complété par un ou plusieurs modules.
[Plusieurs notions] :
1) containersd est un runtime de conteneur avancé, alias gestionnaire de conteneurs. En termes simples, il s'agit d'un démon qui gère le cycle de vie complet des conteneurs sur un seul hôte : création, démarrage, arrêt des conteneurs, extraction et stockage des images, configuration des montages, mise en réseau, etc.
2) ctr est un client de ligne de commande fourni dans le cadre du projet containersd. L'interface ctr est [évidemment] incompatible avec la Docker CLI et, à première vue, peut ne pas sembler très conviviale. Parce que son public principal est constitué de développeurs de conteneurs qui testent des démons. ctr + containersd est plus proche des conteneurs réels que docker + dockerd.
3) nerdctl est un client de ligne de commande relativement nouveau pour containersd. Contrairement à ctr, nerdctl vise à être convivial et compatible avec Docker. D'une certaine manière, nerdctl + containerd peut remplacer de manière transparente docker + dockerd.
4) crictl est un client de ligne de commande pour les environnements d'exécution de conteneurs compatibles [kubernetes] CRI. Présentation de l'interface d'exécution de conteneur Kubernetes (CRI) pour rendre le runtime de conteneur Kubernetes indépendant. Le kubelet proxy de nœud Kubernetes implémente l'API client CRI et peut utiliser n'importe quel environnement d'exécution de conteneur qui implémente l'API du serveur CRI pour gérer les conteneurs et les pods sur ses nœuds.
Ressources associées : site officiel de Containerd , étapes d'installation officielles de Containerd
5.2, la relation entre Docker et containersd
1) En ce qui concerne Docker lui-même, y compris Docker Client et Dockerd, il s'agit d'un outil client utilisé pour envoyer les requêtes des utilisateurs au démon Docker (dockerd). dockerd : dockerd est l'encapsulation de niveau supérieur des opérations liées aux conteneurs, directement orientée vers les utilisateurs opérationnels. Le démon Docker est aussi généralement appelé moteur Docker. Lorsque dockerd démarre, il lancera le processus enfant containersd.
containersd-shim est un transporteur qui exécute réellement des conteneurs. Afin de prendre en charge plusieurs environnements d'exécution OCI, containersd utilise containersd-shim en interne. Chaque fois qu'un conteneur est démarré, un nouveau processus containersd-shim démarre. Il spécifie généralement trois facteurs : l'ID du conteneur, le répertoire du bundle (correspondant au répertoire généré par un certain conteneur, généralement situé à : /var/run/docker/containerd/containerID)
2) containersd inclut tout le nécessaire pour exécuter un conteneur sur une seule machine ; containersd est un environnement d'exécution de conteneur standard de l'industrie, qui met l'accent sur la simplicité, la robustesse et la portabilité, et inclut presque tout ce qui est nécessaire pour exécuter un environnement d'exécution de conteneur sur une seule machine. Tout : exécution , distribution, surveillance, mise en réseau, builds, journaux, etc. Les principales fonctions sont :
1), gérer le cycle de vie du conteneur (de la création du conteneur à la destruction du conteneur)
2), pull/push l'image du conteneur
3), gestion du stockage (gérer le stockage de l'image et des données du conteneur)
4), appeler runC pour exécuter le conteneur (avec runC, etc. Interaction d'exécution du conteneur)
5), gérer l'interface réseau et le réseau du conteneur
Ce que dockerd appelle réellement est toujours l'interface API de containersd, et containersd est un composant de communication intermédiaire entre dockerd et runC. runC est un outil léger pour exécuter des conteneurs.Nous pouvons exécuter des conteneurs directement sans utiliser le moteur Docker.