5.2 KiB
\newpage
Open Container Initiative
Formée en juin 2015, l'Open Container Initiative (OCI) a pour but d'établir le standard commun aux programmes de contenerisation, afin d'éviter une fragmentation de l'écosystème.
Spécifications
Trois spécifications ont été écrites :
runtime-spec: définit les paramètres du démarrage d'un conteneur ;image-spec: définit la construction, le transport et la préparation des images ;distribution-spec: définit la manière dont sont partagées et récupérées les images.
runtime-spec
runc est l'implémentation de cette spécification ; elle a été extraite de
docker, puis donnée par Docker Inc. à l'OCI.
Pour démarrer un conteneur, la spécification indique qu'il est nécessaire
d'avoir un fichier de configuration config.json ainsi qu'un dossier où l'on
peut trouver la racine de notre conteneur.
Le plus gros de la spécification concerne le format de ce fichier de configuration : il contient en effet l'ensemble des paramètres avec lesquels il faudra créer le conteneur : tant d'un point de vue isolement (on peut par exemple choisir de quel namespace on souhaite se dissocier, ou le(s)quel(s) rejoindre), quelles capabilities resteront disponibles, quels nouveaux points de montages, ... Voir la suite.
Aujourd'hui, docker utilise runc pour l'étape de lancement du conteneur,
après avoir téléchargé l'image puis mis en place l'empilement de couches dans
un répertoire prédéterminé. docker ne lance donc plus de conteneur à
proprement parler, il fait seulement en sorte d'atteindre l'état voulu par
cette spécification, avant de passer la main à runc.
::::: {.question}
Si docker fait appel à un programme externe pour lancer effectivement nos conteneurs, c'est que l'on peut changer cette implémentation ? {-}
Oui ! Et il n'y a même pas besoin de faire beaucoup d'efforts, car c'est une
possibilité qui est offerte au travers d'une option du daemon Docker. Le
binaire doit simplement avoir la même interface de ligne de commande que runc
(les arguments create et start, nous les verrons plus tard).
Pour l'ajouter, il convient de passer l'option suivante au daemon Docker lors
de son lancement (dans le fichier de service systemd, ou d'init) :
Ou bien en passant par le fichier de configuration /etc/docker/daemon.json :
Pour chaque nouveau conteneur lancé, il sera alors possible de préciser le runtime à utiliser grâce à l'option --runtime :
:::::
image-spec
Une image OCI est composée d'un manifest, d'une série de couches de systèmes de fichiers, d'une configuration ainsi que d'un index d'image optionnel.
Le manifest est toujours le point d'entrée d'une image : il référence l'emplacement où trouver les différents éléments : configuration et couches. Lorsqu'une même image a des variations en fonction de l'architecture du processeur, du système d'exploitation, ... dans ce cas l'index d'image est utilisé pour sélectionner le bon manifest correspondant au système.
Le format des couches de système de fichiers sont spécifiées : il est nécessaire de passer par des formats standards (comme les tarballs), contenant éventuellement des fichiers et dossiers spéciaux représentant les modifications ou les suppressions éventuelles de la couche.
La
configuration
contient l'ensemble des métadonnées qui serviront par exemple à construire le
config.json attendu par runc lorsqu'il faudra lancer l'image (c'est
là-dedans que finissent toutes les métadonnées que l'on inscrit dans nos
Dockerfile : CMD, VOLUME, PORT, ...). On y retrouve également l'ordre
des couches du système de fichiers, ainsi que l'historique de l'image.
distribution-spec
Enfin, cette spécification fédère la notion de registre et la manière dont les clients vont interagir avec : il s'agit d'une API REST au dessus du protocole HTTP.
Cela permet de récupérer des images, mais aussi d'en envoyer, en gérant éventuellement la manière de s'authentifier.
\
Nous allons voir plus en détails, dans les chapitres suivantes, ce que l'on peut tirer de ces spécifications, en décortiquant des usages précis.