Qu'est-ce qu'un manifeste de conteneur?

Question

Le seul doc sur ce sujet semble supposer que je sais déjà ce qu'est un manifeste, le problème qu'il résout et comment il s'intègre dans l'écosystème docker. Après avoir lu le document, je ne sais toujours pas comment fonctionnent les manifestes.

Mon GCR privé contient des fichiers manifestes - je ne comprends pas vraiment leur objectif. Docker Hub utilise-t-il également des fichiers manifestes? Je peux voir qu'ils contiennent les couches et les hachages de chaque couche, mais je ne sais toujours pas comment Docker les génère/les utilise.

Quel est le but d'un manifeste de conteneur?

Phil E · Accepted Answer

Les types de manifestes sont en fait la description représentée par JSON d'une image nommée/balisée. Cette description (manifeste) est destinée à être consommée par un runtime de conteneur, comme le moteur Docker.

Tout registre ou runtime qui prétend prendre en charge la spécification d'image Docker distribution v2 API/v2.2 interagira avec les différents types de manifestes pour savoir:

quel contenu réel du système de fichiers (couches) sera nécessaire pour construire le système de fichiers racine pour le conteneur, et ..
toute configuration d'image spécifique nécessaire pour savoir comment exécuter un conteneur à l'aide de cette image. Par exemple, des informations telles que la commande à exécuter lors du démarrage du conteneur (comme probablement représentée dans le Dockerfile qui a été utilisé pour créer l'image).

Comme mentionné précédemment, un client (tel que docker pull implémentation) parler à un registre interagira via l'API Docker v2 pour récupérer d'abord le manifeste pour une image/balise spécifique, puis déterminer ce qu'il faut télécharger en plus pour pouvoir exécuter un conteneur basé sur cette image. Le format manifeste v2 ne contient pas de signatures codées, mais une vérification externe à l'aide d'outils comme un serveur notaire peut être utilisée pour valider des signatures externes sur le même "blob"/hachage de contenu pour une confiance cryptographique complète. Docker appelle cela "Docker Content Trust" mais ne l'exige pas lors de la conversation avec un registre, et ne fait pas partie du flux d'API lors de la conversation avec un registre d'images.

Un détail supplémentaire sur les manifestes dans la spécification v2.2: il y a non seulement un type de manifeste standard, mais aussi un type de liste de manifestes qui permet aux registres de représenter prise en charge de plusieurs plates-formes (variantes de processeur ou de système d'exploitation) sous un seul "image:tag "référence. La liste des manifestes contient simplement une liste d'entrées de plate-forme avec un redirecteur vers un manifeste existant afin qu'un moteur puisse récupérer les composants corrects pour cette combinaison plate-forme/architecture spécifique. Dans DockerHub aujourd'hui, toutes les images officielles sont désormais réellement listes de manifestes, permettant à de nombreuses plates-formes d'être prises en charge en utilisant la même image name:tag combinaison. J'ai un outil qui peut interroger des entrées dans un registre et montrer si ce sont des listes de manifestes et aussi vider le contenu d'un manifeste - à la fois des listes de manifestes et des manifestes "réguliers". Vous pouvez en savoir plus sur le référentiel GitHub de manifest-tool .

La diapositive 12 de cette présentation sur la conception de containerd a également une belle représentation graphique de la façon dont les listes de manifestes sont liées aux manifestes, qui représentent la configuration d'image et les couches pour une plate-forme spécifique.

Farhad Farahi · Answer

Un image est une combinaison de n manifeste JSON et fichiers de calques individuels. Le processus d'extraction d'une image se concentre sur la récupération de ces deux composants. Ainsi, lorsque vous tirez un fichier image:

Obtenez le manifeste:
```
GET /v2/<name>/manifests/<reference> 
```
Lorsque le manifeste est en main, le client doit vérifier la signature pour s'assurer que les noms et les couches sont valides.
Le client utilisera ensuite les résumés pour télécharger les couches individuelles. Les couches sont stockées sous la forme blobs dans le V2 API de registre, basée sur leur résumé.