Bien comprendre les registres de conteneurs

Registres de conteneurs : les fondamentaux

Les registres de conteneurs renferment généralement un dépôt d’images et des moyens pour rechercher ou découvrir des images et des microservices. Un registre correspond finalement à un système de contrôle de code source pour les images de conteneurs. En fait, ces systèmes, comme Git, Bitbucket ou Mercurial ont la capacité d’automatiser la création d’une image mise à jour après une vérification du code et sa construction. Le dépôt fournit quant à lui un espace central pour la publication, le stockage, la découverte, le téléchargement et la gestion des images.

Comme un SCCS, un registre de conteneurs fournit également le contrôle de version d’une image et une base de données comportant les métadonnées et description des images ; ce qui peut réduire l’accumulation de versions d’images presqu’identiques pour différentes applications. Ainsi, le registre est plus qu’un dépôt d’images, mais aussi une base de données.

Les registres peuvent utiliser des méta-images comme Dockerfile, pour spécifier les composants d’un conteneur et permet la reconstruction automatique et l’assemblage d’images à chaque nouvelle version de code. Les registres  incluent également des services de noms de domaines pour disposer d’un nom unique et d’une IP virtuelle pour chacune des images. Cela simplifie la recherche et la connexion à des microservices spécifiques dans un cluster de conteneurs. Les applications complexes bâties sur des microservices peuvent être ainsi automatiquement assemblées à la volée par un système d’orchestration, comme Kubernetes ou Docker Compose, rien qu’en s’appuyant sur les descriptions des dépendances d’une image.

Les registres de conteneurs peuvent aussi automatiser les deux premières étapes de la méthodologie « 12 Facteurs » - à savoir, utiliser une unique base de code  qui est gérée via un système de contrôle de version et déclarer les dépendances qui sont automatiquement résolues par un outil d’intégration. L’orchestration (les systèmes de gestion de clusters) automatisent quant à eux le facteur 3 (config) et 5 (build, release, run).

Les  principaux registres du marché

Les registres sont rarement des applications autonomes ; ils font généralement parti d’une plateforme, comme Docker, ou d’un service Cloud, comme le propose AWS.  Voici les registres les plus communément utilisés :

• Docker Registry et Compose. Certainement la plateforme de gestion de conteneurs la plus courante. Il s’agit aussi probablement de l’outil qui a suscité l’intérêt pour les conteneurs – pour leur capacité de déploiements d’applications. Docker est à la fois un projet Open Source et une suite logicielle qui renferme les éléments clés d’un écosystème de conteneurs. Le Docker Registry associe le stockage d’image à leur delivery et propose une intégration avec la chaîne d’outillage DevOps.
• CoreOS Quay. Il s’agit d’un registre développé par les créateurs de la distribution Linux éponyme et est disponible soit sous la forme d’un service Cloud, soit sur site. La solution propose la réplication automatique d’un datacenter à l’autre et le support des processus d’intégration continue, comme la construction automatique de nouvelles images à partir de Dockerfile. Le scan d’images pour identifier d’éventuelles vulnérabilités y est aussi inclus.
• Rancher regroupe quant à lui plusieurs technologies Open Source au sein d’une plateforme complète de conteneurs. Il propose des modules pour l’infrastructure, l’orchestration de conteneurs, le scheduling, la gestion des utilisateurs et des politiques de l’entreprise et un catalogue d’applications. Rancher supporte les registres Docker et CoreOS Quay.
• AWS EC2 Container Service (ECS) est un service de conteneurs compatible Docker qui s’appuie sur des instances EC2 comme hosts de conteneurs. Il propose un registre Docker managé, EC2 Container Registry (ECR). ECR chiffre automatiquement les images stockées et est intégré à AWS Identity et Access Management pour le contrôle d’accès. Les workflows peuvent être automatisés via les lignes de commandes Docker, pour par exemple pousser les images d’un dépôt de code vers ECR et ECS. Cela favorise les déploiements automatiques et le dimensionnement des conteneurs.
• Azure Container Service (ACS) est une offre compatible Docker qui supporte plusieurs moteurs d’orchestration, tels que Swarm, Marathon (Mesos) et bientôt Kubernetes. Azure Container Registry (actuellement en beta) repose sur la version Open Source de Docker Registry v.2 et supporte les images Linux et Windows.  ACS s’intègre à Visual Studio Team Services et permet donc aux développeurs d’automatiser le déploiement de conteneurs, de la compilation de code vers la mise en registre de l’image.
• Google Container Registry (un composant de Google Container Engine) est également un registre qui s’appuie sur la version 2 de Docker et renferme de nombreux outils d’intégration et de déploiements, comme Jenkins et CircleCI. Le service s’adosse logiquement au stockage de Google Cloud, avec des options de réplication de registres d’une région à l’autre (pour améliorer le temps de réponse). La recherche d’images par nom et meta-données y est aussi possible.

Recommandations

Le format Docker ainsi que les APIs des dépôts sont devenus des standards de facto chez la plupart des plateformes, y compris chez les 3 principaux fournisseurs de services Cloud – même si CoreOS Quay est un concurrent sérieux avec ses capacités d’automatisation. La décision finale portera soit sur un registre privé, soit sur un service Cloud.

Le registre est généralement associé à toutes les plateformes de conteneurs, comme Docker, CoreOS Tectonic ou Joyent Triton, pour n’en citer que certains. Certains comme Rancher supportent les registres Docker et CoreOS. Etant donné son omniprésence, il est pertinent d’utiliser un registre Docker pour éviter des problèmes d’intégration à un pipeline d’intégration et de déploiement continu.