1. Docker Registry : qu’est-ce que c’est ?

Docker Registry est une application côté serveur utilisée pour versionner, stocker et distribuer des images Docker.
Un registry permet de contrôler l’origine d’une image et facilite le déploiement continu. Il existe différents registry, aussi bien en mode auto hébergé qu’en mode SaaS. Le plus connu d’entre eux est Docker Hub, les images officielles telles que Ubuntu, Debian et Alpine provenant en réalité de ce registry.

2. Comprendre les images Docker

Une image Docker est un manifeste qui définit le contenu d’un conteneur Docker. Cet article n’est pas destiné à expliquer le fonctionnement d’une image mais il est essentiel de comprendre les normes de nommage des images Docker.

Les images les plus communes sont Debian, Ubuntu et Alpine pour les distributions mais il en existe également pour des langages particuliers comme par exemple PHP, Node ou golang. Ces images sont des images dîtes officielles et sont fournies par Docker. Il est fortement conseillé de dériver de ces images plutôt qu’utiliser des images non sûres. Depuis peu, il est désormais possible de trouver des images créées par des éditeurs officiels et offrant donc plus de garanties. Pour toutes recherches à ce sujet, le site internet de Docker Hub est particulièrement bien conçu : https://hub.docker.com

Pour comprendre le fonctionnement d’une image, une des solutions consiste à analyser la composition de son nom. Pour les images officielles, il est possible de faire simplement « docker pull debian » par exemple mais en réalité le nom complet de cette image est library/debian:latest. Tout d’abord, « library » désigne le registry où se trouve l’image, puis « debian » désigne le nom de son repository, puis pour finir « latest » désigne son tag (Le tag pouvant être assimilé à une version). L’image Debian possède plusieurs tags comme par exemple « buster » pour sa version 10 ou encore « buster-slim » pour une version allégée de sa version 10.

Dans cet article, c’est principalement la partie nom du registry qui se révèle intéressante. Dans les exemples précédents, le registry était « library » qui représente le registry par défaut mais il en existe plusieurs. Certaines images sont rattachées à un autre registry, par exemple Nexus 3 est rattaché au registry de Sonatype, son éditeur. L’image s’appelle donc sonatype/nexus3.

3. Quelles sont les fonctions attendues pour un bon registry Docker ?

Avoir un registry privé permet de contrôler la provenance des images Docker utilisées dans les projets. Cela permet aussi de garder la main sur tous les déploiements. Mais celui-ci doit également répondre à un certain nombre de caractéristiques.

Il faut tout d’abord savoir si une solution auto-hébergée est totalement nécessaire ou si une solution SaaS serait plus adaptée. Dans le cas où le réseau interne nécessite un contrôle des flux internet assez restrictif, un registry auto-hébergé devient une nécessité. En contrepartie, une solution SaaS se révèle être un choix judicieux pour limiter les actions humaines de la part d’un administrateur, le support étant généralement un service proposé. Il est de plus important de noter que certaines solutions aussi bien SaaS qu’auto-hébergées ont un coût de licence, cette donnée pouvant impacter le choix d’une des catégories de produit.

La sécurité est un aspect important pour un registry, ce dernier devant être en mesure de fournir une authentification efficace tel qu’un support AD/LDAP. Certaines solutions proposent plutôt une authentification via token. Certains registry proposent également de scanner les images Docker présentes pour déceler les vulnérabilités. A noter enfin que quelques solutions intègrent également Docker Notary qui est un système destiné à signer les images pour plus de sécurité.

L’intégration continue et le déploiement continu sont tous deux des sujets importants, le choix d’un registry privé pourrait faciliter le déploiement d’image. Certaines plateformes proposent de construire l’image automatiquement lorsqu’un changement est détecté sur un outil de versionning comme Git.

La facilité d’utilisation constitue également un point à prendre en considération. Nous avons abordé la facilité de support des solutions SaaS mais l’aspect utilisateur doit aussi être pris en compte. Une interface graphique « User Friendly » permet de gérer les images contenues dans le registry sans trop de difficultés. Pour autant, beaucoup de solutions ne proposent pas la suppression d’images ou de garbage collector, ce qui est bien regrettable.

Dernier point à aborder, la disponibilité. Pour les solutions SaaS, la question ne se pose généralement pas, la haute disponibilité étant gérée par le fournisseur. Mais pour les solutions auto-hébergées, ce n’est pas toujours le cas. La disponibilité des images étant essentielle pour le bon fonctionnement des services, c’est un point à particulièrement soigner.

4. Tour d’horizon des différentes solutions

Solutions SaaS	Authentification AD/LDAP	Build automatique	Scan vulnérabilités	Remarques	Payant
GitLab CE	Oui	Oui mais avec GitLab CI	Non	Le registry est intégré à GitLab donc très pratique si on utilise déjà le produit. A noter que GitLab existe aussi en version auto-hébergée	Non
GitLab EE					Oui
Quay	Oui	Non	Oui	Proposé avec une interface graphique bien pensée. Quay appartenait anciennement à CoreOS mais a été racheté par RedHat récemment. Des changements sont en cours.	Oui
Docker Hub	Avec un compte Docker Hub	Peut être lié avec GitHub et BitBucket	Non	Docker Hub est le registry le plus utilisé mais reste limité. La création d’un compte est obligatoire et ne permet pas l’authentification AD/LDAP. Cependant, il reste un bon choix pour le partage d’images publiques.	Les registry publics sont gratuits mais pas les privés

 

Solutions Auto-Hébergées	Authentification AD/LDAP	Build automatique	Scan vulnérabilités	Remarques	Payant
Docker Trusted Registry	Oui	Non	Oui	Docker Trusted Registry reste la solution logique pour les entreprises utilisant la version Entreprise de Docker. Etant la version officielle, il propose la plupart des fonctionnalités attendues. La fonctionnalité qui manque principalement à DTR est la construction automatique des images.  A noter qu’il est possible d’avoir une version SaaS de Docker Trusted Registry.	Oui (avec Docker EE)
Nexus	Oui	Non	Non	Nexus n’est pas seulement un registry Docker et propose de plus du stockage pour différents types d’artefacts. C’est une solution assez lourde et ne convient pas si le besoin se restreint à un registry Docker. A noter aussi que l’interface graphique reste très sommaire.	Non
Artifactory	Oui	Non	Non	En ce qui concerne le registry, Artifactory et Nexus sont similaires. Seule différence notable, Artifactory ne propose pas le registry dans sa version gratuite.	Oui
Harbor	Oui	Non	Oui	Très récemment proposée en version Open Source par VMWare, c’est l’une des solutions les plus intéressantes. Mais comme tout produit très jeune, il subsiste encore pas mal de bugs. L’installation est particulièrement laborieuse.	Non
Portus	Oui	Non	Oui	Proposé par openSUSE, son installation se révèle bien moins délicate que celle de Harbor, son principal concurrent. En effet, il existe une simple image sur le Docker Hub (opensuse/portus). Portus propose un bon nombre de fonctionnalités aussi bien pour améliorer la sécurité que la disponibilité.	Non

5. Le projet Docker Distribution, construisez votre propre solution !

Si aucune des solutions ne vous convient ou qu’une fonctionnalité vous manque, le projet Docker Distribution est pour vous. Ce projet Open Source, disponible sur le GitHub de Docker, constitue une base pour vous permettre de développer votre propre solution.
Sans interface graphique et avec un système d’authentification assez sommaire, il fournit néanmoins tous les composants nécessaires à un bon registry. Il peut être installé via l’image Docker officielle distribution/registry:2.0 mais ne convient en aucun cas pour une utilisation en production. Le projet Docker Distribution reste cependant une solution parmi les autres.

6. Conclusion

L’intégration d’un registry Docker à une infrastructure me parait essentiel en ces temps où la mouvance DevOps est en plein essor. L’automatisation est une problématique très en vogue et le registry en est un élément essentiel. Le choix d’une solution est à étudier en fonction des besoins spécifiques de l’entreprise, des compétences de ses équipes mais aussi en fonction de son infrastructure.

 

Il est possible de retrouver l’intégralité de cet article dans le numéro 230 du mois de juin 2019 du magazine « Programmez ».