L'Open Container Initiative (OCI), un consortium fondé par un groupe d’entreprises pour développer des standards ouverts de référence pour les conteneurs, indépendants des plates-formes pour mettre fin à la guerre Docker vs CoreOS, a livré la première version de sa spécification. Cette version comprend deux normes particulièrement importantes qui ne devraient pas affecter la manière dont les développeurs travaillent avec les conteneurs. Par contre, elles devraient avoir un impact réel pour les éditeurs développant des produits pour les conteneurs, surtout s'ils veulent se prévaloir de la certification OCI.
Les deux standards finalisés par l'Open Container Initiative concernent donc deux composants clés de l'écosystème de conteneurs : le format d'image et les runtimes. Le premier, l’OCI Image Format, est assez facile à appréhender. Il décrit la constitution interne d’une image de conteneur et ses différents composants. Selon l’OCI, Image Format est comparable aux systèmes de gestion de paquets .deb et .rpm sous Linux, qui précise que Image Format est « une spécification ouverte fiable, que l’on peut partager entre différents outils et que l’on peut faire évoluer tout en maintenant sa compatibilité qur de très longues périodes ». L'autre norme appelée OCI Runtime Specification, décrit la configuration d’un conteneur, comment il est exécuté et placé sur les principales plates-formes sur lesquelles tournent les conteneurs OCI - Linux, Windows et Solaris.
La distribution des conteneur bientôt dans OCI
Ces trois environnements supportent désormais les conteneurs de type Docker, mais chaque plate-forme possède ses propres particularités d'implémentation et la spécification permet d’inclure ces particularités. Les spécifications d'image et de runtime ont toutes deux des implémentations de référence dans Go, largement dérivées d’implémentations déjà très couramment utilisées par les développeurs. Beaucoup d’aspects relatifs aux conteneurs ne sont pas couverts par les normes OCI, comme la distribution des conteneurs, c’est à dire la manière dont un runtime de conteneur tire une image d'un référentiel, pour laquelle il n’existe pas encore de spécification OCI. Mais le Consortium semble vouloir s’y attaquer.
Une autre étape importante de cette standardisation menée par l’OCI concerne la mise en place d’un programme de certification basé sur ces nouvelles normes. Les apps et services souhaitant adhérer aux standards OCI pourront être certifiés par le Consortium après une série de tests afin de vérifier que leur mode d’implémentent du format d'image du conteneur et des runtimes sont conformes à ses exigences. Les entreprises ne sont pas autorisées à se prévaloir elles-mêmes de la certification. Seul, le Consortium est habilité à délivrer son label.
Docker garde la main sur les normes
Il est probable que la spécification 1.0 aura, à court terme, peu d’impact sur le travail des développeurs qui utilisent des conteneurs pour déployer leurs apps et services. En grande partie, les spécifications OCI existantes sont le fruit d’un travail déjà effectué sur le terrain. C’est le cas par exemple du format d'image Image Format V2 de Docker pour les conteneurs et de son runtime containerd (qui implémente le format d'image). Quand les premières images et runtimes certifiés OCI commenceront à faire leur apparition, ils seront probablement identiques à ceux qu’utilisent déjà les développeurs, ou à peine différents. Par contre, l’impact des normes OCI et du processus de certification risquent d’être plus sensibles pour les éditeurs de produits commerciaux pour les conteneurs. En théorie, ces produits n’auront pas besoin d’être certifiés OCI tant qu'ils se comportent comme les autres produits de conteneurs certifiés, mais ils auront sans doute du mal à justifier l’absence de label.
Docker et l’OCI veulent tous deux rassurer sur le fait que Docker continuera seul à orienter le développement des normes pour les conteneurs. L’an dernier, Docker a passé la main en cédant la gouvernance du format d'image à l’OCI et en plaçant containerd sous la direction de la Cloud Native Computing Foundation (CNCF), où il a trouvé une place à côtés du propre runtime rkt de CoreOS. Il sera intéressant de voir comment évoluera la gouvernance de ces projets et qui fournira le plus gros du travail quand le processus de certification de l’OCI sera sur la route.