Créer un pipeline CI/CD pour les applications AKS à l’aide d’Azure Pipelines

Important

Cet article décrit une version de l’architecture de base d’intégration continue et de déploiement continu (CI/CD). Il se concentre spécifiquement sur le déploiement d’applications Azure Kubernetes Service (AKS) à l’aide d’Azure Pipelines.

Azure Pipelines orchestre les activités de déploiement sur AKS dans le cadre d’un plan de remise d’application reproductible. Vous pouvez intégrer vos processus de génération et de mise en production dans un pipeline pour réduire le risque d’erreur humaine, accélérer les cycles de mise en production et améliorer la qualité globale des logiciels. Cet article explique comment utiliser Azure Pipelines pour implémenter des mises à jour d’applications CI/CD et push vers des clusters AKS.

Architecture

Le flux passe de gauche à droite. Il commence par l’étape 1, où un ingénieur envoie (push) des modifications de code vers un référentiel Git Azure Repos et un pipeline Azure Pipelines PR est déclenché. Ce pipeline comprend les tâches suivantes : Restauration, compilation, tests unitaires, examen des pull requests et analyse du code incluant le lint, l'analyse de sécurité et d'autres outils. À l'étape 2, un pipeline CI de Azure Pipelines est déclenché. Ce pipeline inclut les tâches suivantes : récupération des secrets, linting, restauration, compilation, tests unitaires, tests d'intégration, publication des artefacts de compilation et publication des images de conteneur. À l’étape 3, une image conteneur est publiée dans un registre de conteneurs Azure hors production. À l’étape 4, un pipeline CD dans Azure Pipelines est déclenché. Ce pipeline comprend les tâches suivantes : Déployer sur l'environnement de préproduction, les tests d'acceptation, promouvoir l'image du conteneur, l'intervention manuelle facultative et la mise en production finale. À l’étape 5, le pipeline CD se déploie dans un environnement intermédiaire qui inclut AKS. À l’étape 6, l’image conteneur est promue dans le registre de conteneurs Azure de production. À l’étape 7, le pipeline CD est publié dans un environnement de production qui inclut AKS. À l’étape 8, le service managé Azure Monitor pour Prometheus transfère les données de télémétrie vers Azure Monitor. L’étape 9 est représentée par une section qui inclut un opérateur, Azure Monitor, un service managé Azure Monitor pour Prometheus, un espace de travail Log Analytics, Microsoft Security DevOps, des coffres de clés, Azure Managed Grafana et Defender pour cloud. Une ligne en pointillés passe de l’étape 1 à Microsoft Security DevOps. Plusieurs lignes en pointillés partent de l'étape 2, de l'étape 4, et de la ligne entre l'étape 4 et les environnements intermédiaires et de production pour revenir à l'ingénieur.

Téléchargez un fichier Visio de cette architecture.

Dataflow

Le flux de données suivant correspond au diagramme précédent :

1. Une pull request (PR) vers un dépôt Git d'Azure Repos ou un dépôt GitHub déclenche un pipeline PR.

   Ce pipeline exécute des vérifications de qualité, notamment les opérations suivantes :

   • Création de code, qui peut nécessiter l’extraction de dépendances à partir d’un système de gestion des dépendances
   • Utilisation d’outils pour analyser le code, comme l’analyse statique du code, le linting et l’analyse de sécurité
   • Exécution de tests unitaires

   Si des vérifications échouent, l’exécution du pipeline se termine et le développeur doit apporter les modifications requises. Si toutes les vérifications passent, le pipeline nécessite une révision d'une pull request. Si la révision du pull request échoue, le pipeline se termine et le développeur doit apporter les modifications nécessaires. Une exécution de pipeline réussie entraîne une fusion de tirage réussie.

2. Une fusion vers Azure Repos Git déclenche un pipeline CI. Ce pipeline exécute les mêmes tâches que le pipeline de PR et ajoute des tests d’intégration.

   Si les tests d’intégration nécessitent des secrets, le pipeline les obtient à partir d’Azure Key Vault, une ressource dédiée au pipeline CI de cet environnement.

   Si des vérifications échouent, le pipeline se termine et le développeur doit apporter les modifications requises.

3. Une exécution réussie du pipeline CI crée et publie une image conteneur dans un registre de conteneurs Azure hors production. Defender pour conteneurs analyse les images conteneur lorsqu’elles sont envoyées à Azure Container Registry et signale les vulnérabilités d’image à Microsoft Defender for Cloud. Si vous le souhaitez, les images conteneur peuvent être signées pour garantir l’intégrité de l’image conteneur.

4. L’achèvement du pipeline CI déclenche le pipeline CD.

5. Le pipeline CD déploie un modèle YAML dans l’environnement AKS intermédiaire qui inclut un agent Defender. Ce déploiement utilise un modèle push et s’exécute via kubectl ou Helm. Le modèle fait référence à l’image de conteneur du registre de non-production.

   Le pipeline effectue des tests d’acceptation sur l’environnement intermédiaire pour valider le déploiement. Si les tests réussissent, le pipeline peut comporter une tâche de vérification manuelle afin de confirmer le déploiement et de reprendre le pipeline. Certaines charges de travail sont déployées automatiquement. Si des vérifications échouent, le pipeline se termine et le développeur doit apporter les modifications requises.

6. Lorsqu’un individu reprend l’intervention manuelle, le pipeline CD promeut l’image du registre de conteneurs Azure hors production vers le registre de production. Defender pour conteneurs analyse les images conteneur lorsqu’elles sont envoyées à Container Registry et signale les vulnérabilités d’image à Microsoft Defender for Cloud.

7. Le pipeline CD déploie un modèle YAML dans l’environnement AKS de production qui inclut un agent Defender. Le modèle spécifie l’image conteneur du registre de production.

8. Le service managé Azure Monitor pour Prometheus transfère régulièrement les métriques de performances, les données d’inventaire et les informations d’état d’intégrité des hôtes de conteneur et des conteneurs vers Azure Monitor.

9. Un espace de travail Log Analytics stocke toutes les données. Azure Monitor fournit plusieurs outils pour analyser les données collectées par d’autres fonctionnalités. Différents tableaux de bord Grafana combinent différents ensembles de données de télémétrie Kubernetes. Application Insights collecte des données de surveillance spécifiques à l’application, telles que les traces.

   Defender pour conteneurs effectue des analyses périodiques des conteneurs exécutés dans AKS ainsi que des images de conteneurs stockées dans le registre de conteneurs. Defender pour conteneurs fournit également une protection contre les menaces en temps réel pour les environnements conteneurisés pris en charge et génère des alertes pour les activités suspectes. Ces informations permettent d’identifier les problèmes de sécurité et d’améliorer la sécurité des conteneurs.

Components

• Azure Pipelines est un composant d’Azure DevOps qui génère, teste et déploie automatiquement du code sur sa cible de calcul. Dans cette architecture, elle crée et teste des images conteneur, les charge dans Container Registry et les déploie dans AKS.

• Le service managé Azure Monitor pour Prometheus est une fonctionnalité Azure qui fournit une surveillance pour les environnements conteneurisés. Dans cette architecture, elle collecte des métriques de performances, des journaux et des données d’intégrité à partir de conteneurs et transfère ces données d’observabilité à Azure Monitor pour l’analyse et les alertes.

• Key Vault est un service cloud permettant de stocker et d’accéder aux secrets, tels que les clés API, les mots de passe, les certificats ou les clés de chiffrement. Dans cette architecture, le pipeline obtient les secrets requis pour tester le code à partir de Key Vault.

• Azure Monitor est une solution de supervision qui collecte, analyse et répond aux données de télémétrie à partir d’environnements cloud et locaux. Dans cette architecture, elle sert de plateforme d’observabilité centrale qui fournit une surveillance et des alertes pour les clusters AKS et les opérations de pipeline CI/CD.

• Container Registry est un service de registre de conteneurs privé géré sur Azure. Container Registry stocke des images conteneur privées. Dans cette architecture, la plateforme de calcul extrait l’image conteneur de l’application à partir de Container Registry.

• AKS est un service Kubernetes managé dans lequel Azure gère les tâches critiques, telles que la surveillance et la maintenance de l’intégrité. Dans cette architecture, elle sert de plateforme de calcul pour l’application.

• L’extension Microsoft Security DevOps Azure DevOps vous permet d’incorporer l’analyse de sécurité directement dans vos flux de travail CI/CD. Dans cette architecture, Microsoft Security DevOps effectue une analyse statique et fournit une visibilité des postures de sécurité sur plusieurs pipelines dans le développement et le déploiement AKS. Microsoft Security DevOps fait partie de la sécurité Microsoft Defender pour Cloud DevOps, qui fournit une visibilité complète, la gestion de la posture et la protection contre les menaces dans les environnements multiclouds.

Alternatives

Considérez les alternatives suivantes pour votre implémentation.

Modèle basé sur le pull (GitOps)

Ce scénario montre un modèle axé sur la poussée pour déployer des ressources dans AKS. Les déploiements basés sur push fonctionnent mieux quand vous avez besoin de mises à jour déterministes pour vos clusters. Les pipelines lancent activement des déploiements, surveillent leur réussite et prennent des mesures directes si les déploiements échouent. Cette approche est souvent une caractéristique importante des pratiques de déploiement sécurisées dans les charges de travail. Les déploiements basés sur push répondent également à plusieurs cibles de déploiement, telles que les environnements bleu-vert, où vous avez besoin d’un modèle de déploiement hautement contrôlé au sein d’un seul cluster ou d’un cluster à l’autre.

Les déploiements basés sur extraction reposent également sur des clusters pour extraire et appliquer des mises à jour. Ce modèle dissocie la logique de déploiement du pipeline, ce qui permet aux clusters individuels de se rapprocher d’un état souhaité stocké dans un emplacement central, tel qu’un dépôt Git dans des workflows GitOps ou un registre d’artefacts. Les déploiements basés sur le tirage fonctionnent le mieux pour les environnements qui hiérarchisent la cohérence, l'auditabilité, et l'auto-réparation. La source de la vérité réside en externe, souvent dans les systèmes contrôlés par la version, de sorte que les clusters surveillent et appliquent en permanence des mises à jour pour correspondre à cet état souhaité. Cette approche réduit le risque de dérive. Si un cluster rencontre une défaillance ou devient indisponible, il peut se réconcilier automatiquement après son retour en ligne sans nécessiter de redéploiement à partir d’un pipeline central.

Le modèle d’extraction GitOps supprime également la nécessité pour les pipelines d’accéder directement aux clusters ou d’utiliser les informations d’identification de déploiement associées, ce qui élimine un vecteur d’attaque. Les clusters ont uniquement besoin d’un accès en lecture seule au référentiel source. Pour plus d’informations, consultez GitOps pour AKS.

Pipeline CI/CD généré avec GitHub Actions

Vous pouvez remplacer Azure Pipelines par GitHub Actions pour AKS. GitHub Actions est une plateforme CI/CD que vous pouvez utiliser pour automatiser votre pipeline de génération, de test et de déploiement. Envisagez d’utiliser un flux de travail de démarrage pour AKS et personnalisez-le en fonction de vos besoins ci/CD.

Étapes suivantes

• Pour obtenir un ensemble complet de services basés sur Azure Monitor qui surveillent l’intégrité et les performances de différentes couches dans l’infrastructure et les applications Kubernetes qui en dépendent, consultez la supervision Kubernetes dans Azure Monitor.
• Architecture de base de référence CI/CD qui utilise Azure Pipelines
• Formation : Présentation de Kubernetes sur Azure

Ressources associées

• Architecture de microservices sur AKS
• Parcours de solution AKS