Comprendre Azure Container Registry

Lorsque vous arrivez à la fin d'un pipeline de build devops, vous vous retrouvez avec un ensemble d'artefacts: binaires, fichiers de configuration, pages Web, même des machines virtuelles et des conteneurs. Ce sont les composants qui vont ensemble pour construire une application moderne. Emballer autant de ces composants que possible dans un conteneur a beaucoup de sens, vous offrant un modèle de déploiement plus simple. Mais cela laisse une nouvelle série de questions: comment gérez-vous ces conteneurs et comment les déployez-vous dans une application cloud à l'échelle mondiale?

Des services tels que GitHub offrent des registres privés et publics pour vos artefacts de construction, en utilisant des normes ouvertes et du code open source. Azure a fait de même, en utilisant le Docker Registry 2.0 open source comme base de son propre registre de conteneurs, conforme à Open Container Initiative. Il n'est pas destiné uniquement aux conteneurs; avec l'importance croissante des applications cloud natives basées sur Kubernetes, il est censé être un référentiel unique pour tous vos artefacts de build compatibles OCI. Cela inclut désormais les graphiques Helm, vous pouvez donc utiliser Azure Container Registry (ACR) comme hub de déploiement pour vos applications, en utilisant Helm 3.0 pour la livraison aux instances Kubernetes.

Premiers pas avec ACR

Les outils tels que Azure Container Registry sont mieux considérés comme des registres privés. Seuls vous, votre équipe et vos services avez accès à votre registre, ce qui automatise la livraison aux services Azure qui utilisent des conteneurs. Des outils familiers tels qu'Azure DevOps et Jenkins peuvent être configurés pour utiliser le registre comme point de terminaison de génération, afin que vous puissiez passer directement de la fusion d'une pull request à un conteneur sur Azure, prêt à être déployé.

Microsoft propose actuellement trois versions d'ACR: Basic, Standard et Premium, à trois prix différents. Ils fonctionnent tous avec des hooks Web, utilisent Azure Active Directory pour l'authentification et ont la capacité de supprimer des images. Basic a la capacité la plus faible; Premium inclut la prise en charge de la réplication dans les régions et ajoute la prise en charge de la signature d'images. Vous êtes le plus susceptible d'utiliser Standard, qui vous offre 100 Go de stockage, 60 Mo de bande passante de téléchargement et prend en charge jusqu'à 10 Web hooks. Le prix est par registre et par jour, avec des coûts de réseau supplémentaires et des frais distincts pour l'utilisation du processeur lors de la création de nouvelles images de conteneur.

La création d'un nouveau registre de conteneurs est relativement simple, à l'aide de l'interface de ligne de commande Azure ou du portail. Les instances ACR sont liées à des groupes de ressources, vous pouvez donc avoir un registre distinct pour chaque application que vous exécutez sur Azure. Une fois qu'un registre a été créé, vous recevez l'URL d'un serveur de connexion. C'est le point final de l'intégration avec les outils devops ou les instances Docker de bureau de vos développeurs.

Interagir avec un registre ACR

La commande Azure CLI acrest probablement le moyen le plus utile d'interagir avec un registre. Connectez-vous et vous pouvez commencer à y envoyer des images de conteneur. C'est une bonne idée de commencer à partir du bureau pour avoir une idée de son fonctionnement, en étiquetant une image Docker locale avec le nom du serveur de connexion ACR, puis en utilisant la docker pushcommande pour envoyer l'image au registre ACR, en créant automatiquement le référentiel approprié dans Azure. Une fois qu'une image se trouve dans un référentiel ACR, utilisez les outils de ligne de commande pour répertorier les fichiers, les supprimer et même utiliser les commandes Docker pour les exécuter.

L'automatisation d'ACR peut réduire considérablement votre charge de travail grâce aux tâches ACR. Les tâches regroupent ce qui aurait été un ensemble de scripts Azure CLI dans des flux de travail simples qui gèrent les opérations courantes. Par exemple, ils offrent une série de déclencheurs qui automatisent la création de nouvelles images lorsque des changements se produisent dans votre pipeline de construction ou dans votre système d'intégration continue / de livraison continue (CI / CD).

Une option, la tâche rapide, englobe toutes les étapes utilisées pour créer un ensemble de fichiers dans un conteneur en une seule commande. Tout ce dont vous avez besoin est un répertoire de travail avec vos fichiers et un registre ACR existant et un Dockerfile. Une seule commande prend ces fichiers et utilise le Dockerfile pour créer une image, en la stockant automatiquement dans un référentiel ACR. Une autre tâche rapide exécute l'image sur l'hôte choisi.

Mettez-les ensemble et vous disposez d'un ensemble d'outils de base pour tester les images de conteneurs. Les déploiements plus complexes nécessiteront des scripts plus complexes, par exemple le déploiement d'un conteneur sur une instance Kubernetes gérée à l'aide d'AKS. Vous pouvez également automatiser l'ensemble du processus, en créant une tâche qui surveille un dépôt GitHub pour les modifications dans une branche de déploiement, en créant une nouvelle image lorsque vous fusionnez une demande d'extraction dans la branche ou effectuez une validation.

Sécurisation des conteneurs dans ACR

Travailler avec ACR présente des avantages de sécurité. L'un des gros problèmes auxquels est confronté quiconque crée des applications modernes est de comprendre et de gérer votre arbre de dépendances. Comment savoir si une nouvelle version d'une bibliothèque de clés ou d'un composant obscurci peut être utilisé en toute sécurité? Vous devez être en mesure de faire confiance à vos conteneurs et ACR propose deux méthodes pour vous assurer de toujours déployer du code de confiance.

Tout d'abord, il fournit des images de conteneur signées, afin que votre cluster Kubernetes puisse vérifier que le code qu'il exécute est le code que vous avez poussé vers votre registre à partir de votre système de génération. Les images signées garantissent que personne n'a altéré le contenu d'un conteneur pendant son déploiement. Deuxièmement, ACR peut s'intégrer au centre de sécurité d'Azure. Cela vous permet d'analyser les images telles qu'elles sont stockées dans le registre, en vérifiant non seulement les vulnérabilités dans votre code et dans l'image de base, mais également dans toutes les dépendances incluses ou référencées à partir du fichier image. À l'aide du scanner de Qualys, les rapports Security Center vous aideront à identifier les vulnérabilités avec des recommandations de correctifs.

Les choses deviennent intéressantes lorsque vous commencez à utiliser vos instances ACR pour plus que des conteneurs. OCI a commencé à ouvrir la norme de registre aux artefacts, avec Helm, l'outil de facto pour le déploiement d'applications Kubernetes, en l'utilisant dans la dernière version. L'industrie a vu une prolifération de registres et de référentiels, et il est logique de normaliser sur un pour tous les composants de votre application, en particulier lorsqu'ils font tous partie de la même application native du cloud.

ACR prend désormais en charge le registre OCI en tant que stockage (ORAS). À l'aide d'un outil ORAS, vous pouvez pousser et extraire tous vos artefacts du même référentiel ACR. Installez ORAS sur vos machines de développement ou ajoutez une prise en charge à votre pipeline de build. Une fois connecté à votre registre avec un principal de service Azure Active Directory disposant de droits de transmission, utilisez l'outil de ligne de commande ORAS pour envoyer de nouveaux artefacts au registre.

L'utilisation d'un outil de ligne de commande dans Azure CLI vous donne la flexibilité de créer ORAS push dans votre choix d'outils de génération, sous la forme d'un script qui peut être appelé en cas de besoin. Le même outil de ligne de commande peut extraire des artefacts et vous pouvez l'intégrer dans vos scripts de déploiement afin que tous les composants qui composent vos applications puissent se déployer automatiquement lorsqu'une nouvelle version est transférée vers vos référentiels ACR.

Le code privé a besoin de référentiels privés et conserver vos conteneurs et autres artefacts de build dans Azure les place là où ils sont nécessaires. Un processus de construction devops complet doit aller de la validation de code à l'exécution de l'application sans intervention humaine, ce qui rend les outils tels que Azure Container Registry et ses composants d'automatisation des tâches associés essentiels dans tout pipeline ciblé Azure. Non seulement le code est automatiquement stocké et déployé à l'échelle mondiale, mais il est analysé pour les risques de sécurité chaque fois qu'il y a un changement.