Déploiement de conteneurs dans Azure
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
Nous avons abordé les conteneurs dans ce chapitre et dans le chapitre 1. Nous avons vu que les conteneurs offrent de nombreux avantages aux applications natives cloud, notamment la portabilité. Dans le cloud Azure, vous pouvez déployer les mêmes services en conteneur dans les environnements intermédiaires et de production. Azure propose plusieurs options pour héberger ces charges de travail en conteneur :
- Azure Kubernetes Services (AKS)
- Azure Container Instances (ACI)
- Azure Web App pour conteneurs
Azure Container Registry
Lors de la conteneurisation d’un microservice, vous créez d’abord une « image » de conteneur. L’image est une représentation binaire du code de service, des dépendances et du runtime. Bien que vous puissiez créer manuellement une image à l’aide de la commande Docker Build à partir de l’API Docker, une meilleure approche consiste à la créer dans le cadre d’un processus de génération automatisé.
Une fois créées, les images conteneur sont stockées dans des registres de conteneurs. Ils vous permettent de créer, stocker et gérer des images conteneur. De nombreux registres sont disponibles, tant publics que privés. Azure Container Registry (ACR) est un service de registre de conteneurs entièrement managé dans le cloud Azure. Il conserve vos images au sein du réseau Azure, ce qui réduit le temps de les déployer sur des hôtes de conteneur Azure. Vous pouvez également les sécuriser à l’aide des mêmes procédures de sécurité et d’identité que celles que vous utilisez pour d’autres ressources Azure.
Vous créez un Azure Container Registry à l’aide des outils Portail Azure, Azure CLI ou PowerShell. La création d’un registre dans Azure est simple. Il nécessite un abonnement Azure, un groupe de ressources et un nom unique. La figure 3-10 montre les options de base de création d’un registre, lequel sera hébergé sur registryname.azurecr.io.
Figure 3-10. Créer un registre de conteneurs
Une fois que vous avez créé le Registre, vous devez vous authentifier auprès de celui-ci avant de pouvoir l’utiliser. En règle générale, vous allez vous connecter au registre à l’aide de la commande Azure CLI :
az acr login --name *registryname*
Une fois authentifié, vous pouvez utiliser des commandes Docker pour y envoyer (push) des images conteneur. Toutefois, avant de pouvoir le faire, vous devez baliser votre image avec le nom complet (URL) de votre serveur de connexion ACR. Il aura le format registryname.azurecr.io.
docker tag mycontainer myregistry.azurecr.io/mycontainer:v1
Une fois que vous avez étiqueté l’image, vous utilisez la commande docker push pour envoyer (push) l’image à votre instance ACR.
docker push myregistry.azurecr.io/mycontainer:v1
Une fois que vous avez envoyé une image au Registre, il est judicieux de supprimer l’image de votre environnement Docker local à l’aide de cette commande :
docker rmi myregistry.azurecr.io/mycontainer:v1
La meilleure pratique consiste à ne pas envoyer (push) manuellement des images dans un registre de conteneurs. Utilisez plutôt un pipeline de build défini dans un outil comme GitHub ou Azure DevOps. Pour en savoir plus, consultez le chapitre DevOps natif cloud.
ACR Tasks
ACR Tasks est un ensemble de fonctionnalités disponibles à partir du Azure Container Registry. Il étend votre cycle de développement en boucle interne en créant et en gérant des images conteneur dans le cloud Azure. Au lieu d’appeler un docker build et docker push localement sur votre ordinateur de développement, ils sont gérés automatiquement par ACR Tasks dans le cloud.
La commande AZ CLI suivante génère une image conteneur et l’envoie (push) à ACR :
# create a container registry
az acr create --resource-group myResourceGroup --name myContainerRegistry008 --sku Basic
# build container image in ACR and push it into your container registry
az acr build --image sample/hello-world:v1 --registry myContainerRegistry008 --file Dockerfile .
Comme vous pouvez le voir à partir du bloc de commande précédent, il n’est pas nécessaire d’installer Docker Desktop sur votre ordinateur de développement. En outre, vous pouvez configurer des déclencheurs de tâche ACR pour reconstruire des images de conteneurs sur le code source et les mises à jour des images de base.
Azure Kubernetes Service
Nous avons parlé d’Azure Kubernetes Service (AKS) en détail dans ce chapitre. Nous avons vu qu’il s’agit de l’orchestrateur de conteneurs de facto qui gère les applications cloud natives en conteneur.
Une fois que vous avez déployé une image dans un registre, comme ACR, vous pouvez configurer AKS pour extraire et déployer automatiquement une image. Avec un pipeline CI/CD en place, vous pouvez configurer une stratégie de mise en production canary pour réduire le risque lié au déploiement rapide des mises à jour. La nouvelle version de l’application est initialement configurée en production sans aucun trafic acheminé vers celui-ci. Ensuite, le système acheminera un petit pourcentage d’utilisateurs vers la version nouvellement déployée. À mesure que l’équipe gagne en confiance dans la nouvelle version, elle peut déployer davantage d’instances et mettre hors service l’ancienne. AKS prend facilement en charge ce style de déploiement.
Comme pour la plupart des ressources dans Azure, vous pouvez créer un cluster Azure Kubernetes Service à l’aide du portail, de la ligne de commande ou des outils d’automatisation tels que Helm ou Terraform. Pour commencer à utiliser un nouveau cluster, vous devez fournir les informations suivantes :
- Abonnement Azure
- Resource group
- Nom du cluster Kubernetes
- Région
- Version de Kubernetes
- Préfixe du nom DNS
- Taille du nœud
- Nombre de nœuds
Ces informations sont suffisantes pour commencer. Dans le cadre du processus de création dans le Portail Azure, vous pouvez également configurer des options pour les fonctionnalités suivantes de votre cluster :
- Scale
- Authentification
- Mise en réseau
- Surveillance
- Balises
Ce guide de démarrage rapide décrit le déploiement d’un cluster AKS à l’aide du Portail Azure.
Azure Bridge to Kubernetes
Les applications natives cloud peuvent grandir et devenir complexes, nécessitant des ressources de calcul importantes à exécuter. Dans ces scénarios, l’ensemble de l’application ne peut pas être hébergé sur un ordinateur de développement (en particulier un ordinateur portable). Azure Bridge to Kubernetes résout les lacunes. Il permet aux développeurs d’utiliser une version locale de leur service tout en hébergeant l’ensemble de l’application dans un cluster de développement AKS.
Lorsque vous êtes prêt, les développeurs testent leurs modifications localement tout en s’exécutant sur l’application complète dans le cluster AKS, sans répliquer les dépendances. Sous le capot, le pont fusionne le code de l’ordinateur local avec des services dans AKS. Itérer et déboguer rapidement le code directement dans Kubernetes à l’aide de Visual Studio 2017 ou de Visual Studio Code
Gabe Monroy, ancien vice-président de la gestion des produits chez Microsoft, décrit bien :
Imaginez que vous êtes un nouvel employé qui tente de résoudre un bogue dans une application de microservices complexe composée de dizaines de composants, chacun avec ses propres services de configuration et de stockage. Pour commencer, vous devez configurer votre environnement de développement local afin qu’il puisse imiter la production, notamment la configuration de votre IDE, la création d’une chaîne d’outils, des dépendances de service conteneurisées, un environnement Kubernetes local, des simulations pour les services de stockage, etc. Avec tout le temps impliqué pour la configuration de votre environnement de développement, la correction de ce premier bogue peut prendre des jours ! Vous pouvez également utiliser Bridge to Kubernetes et AKS.
