Modifier

Partager via

CI/CD pour les applications AKS avec GitHub Actions et GitFlow

Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Pipelines

GitOps est un modèle d’exploitation pour les applications natives cloud, qui stocke le code des applications et de l’infrastructure déclarative dans Git, comme source de vérité pour la livraison continue automatisée. Avec GitOps, vous décrivez l’état souhaité de l’ensemble de votre système dans un dépôt Git et un opérateur GitOps le déploie dans votre environnement, généralement un cluster Kubernetes. Pour plus d’informations sur GitOps pour Kubernetes sur Azure, consultez GitOps pour Azure Kubernetes Service ou Disciplines CI/CD et GitOps avec Kubernetes avec Azure Arc.

L’exemple de scénario fourni dans cet article s’applique aux entreprises qui souhaitent moderniser le développement d’applications de bout en bout à l’aide de conteneurs, de l’intégration continue (CI) pour la génération et de GitOps pour le déploiement continu (CD). Dans ce scénario, une application Flask est utilisée comme exemple. Cette application web se compose d’un front-end écrit avec Python et le framework Flask.

Architecture

Les options suivantes explorent les approches CI/CD basées sur la poussée (push) et le tirage (pull).

Option 1 : CI/CD basé sur la poussée

Diagramme de l’architecture basée sur la poussée avec GitHub Actions.

Architecture basée sur la poussée avec GitHub Actions pour l’intégration continue et le déploiement continu.

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

Dataflow

Ce scénario traite d’un pipeline DevOps basé sur la poussée pour une application web à deux niveaux, avec un composant web front-end et un back-end qui utilise Redis. Ce pipeline utilise GitHub Actions pour la génération et le déploiement. Les données circulent dans le scénario comme suit :

  1. Le code de l’application est développé.
  2. Le code de l’application est commité dans un dépôt GitHub.
  3. GitHub Actions génère une image conteneur à partir du code de l’application et pousse l’image conteneur sur Azure Container Registry.
  4. Un travail GitHub Actions déploie ou envoie (push) l’application, comme décrit dans les fichiers manifestes, sur le cluster Azure Kubernetes Service (AKS) à l’aide de kubectl ou de l’action Déployer sur le cluster Kubernetes.

Option 2 : CI/CD basé sur le tirage (GitOps)

Diagramme de l’architecture basée sur le tirage avec GitHub Actions et Argo CD.

Architecture basée sur le tirage avec GitHub Actions pour l’intégration continue et Argo CD pour le déploiement continu.

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

Dataflow

Ce scénario traite d’un pipeline DevOps basé sur le tirage pour une application web à deux niveaux, avec un composant web front-end et un back-end qui utilise Redis. Ce pipeline utilise GitHub Actions pour la génération. Pour le déploiement, il utilise Argo CD comme opérateur GitOps pour tirer/synchroniser l’application. Les données circulent dans le scénario comme suit :

  1. Le code de l’application est développé.
  2. Le code de l’application est commité dans un dépôt GitHub.
  3. GitHub Actions génère une image conteneur à partir du code de l’application et pousse l’image conteneur sur Azure Container Registry.
  4. GitHub Actions met à jour un fichier de déploiement de manifeste Kubernetes avec la version actuelle de l’image en fonction du numéro de version de l’image conteneur dans le registre de conteneurs Azure.
  5. Argo CD se synchronise avec le dépôt Git (il effectue un tirage à partir du dépôt).
  6. Argo CD déploie l’application sur le cluster AKS.

Components

  • GitHub Actions est une solution d’automatisation qui peut s’intégrer aux services Azure pour l’intégration continue (CI). Dans ce scénario, GitHub Actions orchestre la création d’images conteneur basées sur les commits effectués dans le contrôle de code source, pousse ces images sur Azure Container Registry, puis met à jour les fichiers manifeste Kubernetes dans le dépôt GitHub.
  • AKS (Azure Kubernetes Service) est une plateforme Kubernetes managée, qui vous permet de déployer et de gérer des applications conteneurisées sans avoir à maîtriser l’orchestration de conteneurs. En tant que service Kubernetes hébergé, Azure gère pour vous des tâches critiques telles que l’analyse de l'intégrité et la maintenance.
  • Azure Container Registry stocke et gère les images conteneur qui sont utilisées par le cluster AKS. Les images sont stockées de manière sécurisée. La plateforme Azure peut les répliquer dans d’autres régions pour accélérer les déploiements.
  • GitHub est un système web de contrôle de code source qui s’exécute sur Git et que les développeurs utilisent pour stocker et versionner leur code d’application. Dans ce scénario, GitHub est utilisé pour stocker le code source dans un dépôt Git, puis GitHub Actions est utilisé pour la génération et la poussée de l’image conteneur sur Azure Container Registry dans l’approche basée sur la poussée.
  • Argo CD est un opérateur GitOps open source qui s’intègre à GitHub et AKS. Argo CD prend en charge le déploiement continu (CD). Flux aurait également pu être utilisé pour cela. Cependant, Argo CD montre comment une équipe d’application peut choisir un outil distinct pour ses préoccupations spécifiques en termes de cycle de vie d’application, plutôt que l’outil utilisé par les opérateurs de cluster pour la gestion de cluster.
  • Azure Monitor vous permet de suivre les performances, de gérer la sécurité et d’identifier des tendances. Les métriques obtenues par Azure Monitor peuvent être utilisées par d’autres ressources et outils tels que Grafana.

Autres solutions

  • Azure Pipelines vous permet d’implémenter un pipeline CI/CD et de test pour n’importe quelle application.
  • Jenkins est un serveur d’automatisation open source qui peut s’intégrer aux services Azure pour l’intégration continue et la livraison continue.
  • Flux peut être utilisé comme opérateur GitOps. Il peut effectuer les mêmes tâches qu’Argo CD et fonctionne de la même façon avec AKS.

Détails du scénario

Dans ce scénario, la génération et le déploiement automatisés de votre application utilisent plusieurs technologies. Le code est développé dans VS Code et stocké dans un dépôt GitHub. GitHub Actions est utilisé pour générer l’application comme conteneur, puis pousser l’image conteneur sur un conteneur de registres Azure. GitHub Actions est utilisé pour mettre à jour le fichier de déploiement de manifeste Kubernetes nécessaire, également stocké dans le dépôt Git, et l’opérateur GitOps Argo CD y récupère les fichiers manifeste Kubernetes et déploie l’application sur le cluster AKS.

Voici d’autres exemples : fournir un environnement de développement automatisé, valider de nouveaux commits de code et pousser de nouveaux déploiements dans des environnements de préproduction et de production. Traditionnellement, les entreprises devaient générer et compiler des applications et des mises à jour, et gérer une base de code monolithique et volumineuse. Avec une approche moderne du développement d’applications utilisant l’intégration continue et GitOps pour le déploiement continu, vous pouvez générer, tester et déployer des services rapidement. Cette approche moderne vous permet de proposer plus rapidement des applications et des mises à jour à vos clients et de vous adapter aux variations des besoins de l’entreprise de manière plus agile.

À l’aide de services Azure et GitHub comme AKS, Container Registry, GitHub et GitHub Actions, les entreprises peuvent utiliser les tout derniers outils et techniques de développement d’applications pour simplifier le processus d’implémentation de la haute disponibilité. En outre, à l’aide de technologies open source telles que Flux ou Argo CD pour GitOps, les entreprises simplifient le déploiement et appliquent l’état souhaité des applications.

Cas d’usage potentiels

Les autres cas d’usage appropriés sont les suivants :

  • Moderniser les pratiques de développement d’applications en adoptant une approche basée sur les conteneurs et les microservices.
  • Accélérer le développement d’applications et les cycles de vie de déploiement.
  • Automatiser les déploiements sur les environnements de test ou d’acceptation pour la validation.
  • Assurer les configurations et l’état souhaité de l’application.
  • Automatiser la gestion du cycle de vie du cluster.

Options CI/CD

Ce document présente comment utiliser GitOps pour adopter une approche moderne de la gestion du déploiement continu dans un pipeline CI/CD. Chaque organisation est cependant différente. Le déploiement d’applications sur des clusters Kubernetes avec des pipelines de livraison automatisés nécessite de bien comprendre les différentes façons de procéder.

Les deux options de CI/CD les plus courantes pour le déploiement d’une application sur un cluster AKS sont celles basées sur la poussée et sur le tirage. L’option basée sur la poussée utilise GitHub Actions pour le déploiement continu et l’option basée sur le tirage utilise GitOps pour le déploiement continu.

Option 1 : Architecture basée sur la poussée avec GitHub Actions pour l’intégration continue et le déploiement continu

Dans le cadre de cette approche, le code commence par la partie CI du pipeline, qui procède à la poussée des modifications comme déploiements sur le cluster Kubernetes. Les déploiements sont basés sur un déclencheur. Différents déclencheurs peuvent démarrer le déploiement, par exemple, des commits sur le dépôt ou un déclencheur d’un autre pipeline CI. Avec cette approche, le système de pipeline a accès au cluster Kubernetes. Le module basé sur la poussée est le modèle le plus couramment utilisé aujourd’hui par les outils de CI/CD.

Raisons d’utiliser une approche basée sur la poussée :

  • Flexibilité : Actuellement, la plupart des opérateurs GitOps s’exécutent uniquement dans Kubernetes. Si votre organisation souhaite déployer des applications sur un environnement autre que Kubernetes, vous devez pousser l’application sur cet environnement à l’aide d’autres outils de CI/CD tels que GitHub Actions.

  • Efficacité : Il est plus efficace d’employer une approche standardisée pour le déploiement de vos applications classiques et natives cloud. Actuellement, GitOps offre la solution la mieux adaptée pour les applications natives cloud qui s’exécutent sur Kubernetes.

  • Simplicité : Le CI/CD basé sur la poussée est bien connu par la majorité des ingénieurs (dans de nombreuses organisations). Une approche basée sur la poussée peut être plus simple qu’une combinaison d’approches CI/CD basées sur la poussée et le tirage.

  • Structure : Il se peut que la structure de dépôt actuelle utilisée pour votre application ne soit pas bien adaptée à GitOps. Dans ce cas, une planification et une restructuration importantes seront nécessaires pour l’adapter à GitOps.

Option 2 : Architecture basée sur le tirage avec GitHub Actions pour l’intégration continue et l’opérateur GitOps Argo CD pour le déploiement continu

Cette approche est axée sur l’application de toutes les modifications à partir d’un cluster Kubernetes. Le cluster Kubernetes inclut un opérateur qui analyse un dépôt Git pour déterminer l’état souhaité du cluster. Il récupère et applique les éventuelles modifications qui doivent être apportées. Dans ce modèle, aucun client externe n’a d’informations d’identification de niveau administrateur pour l’accès au cluster Kubernetes. Le modèle basé sur le tirage n’est pas nouveau, mais n’est pas couramment utilisé par les outils de CI/CD. Récemment, l’introduction de GitOps a stimulé l’adoption de ce modèle. De nombreuses organisations utilisent GitOps pour faciliter le déploiement continu dans leurs pipelines CD/CD.

Raisons d’utiliser une approche basée sur le tirage :

  • Cohérence : Avec GitOps, un opérateur compare l’état de vos clusters Kubernetes à l’état souhaité de votre configuration et de vos applications dans un dépôt Git. En cas d’écart par rapport à la configuration ou aux applications, l’opérateur GitOps rétablit automatiquement l’état souhaité du cluster Kubernetes.

  • Sécurité : Une approche du CI/CD basée sur le tirage avec GitOps vous permet de déplacer les informations d’identification de sécurité vers votre cluster Kubernetes. En évitant de stocker les informations d’identification dans vos outils de CI externes, vous réduisez la surface de risque et gagnez en sécurité. Vous pouvez également réduire les connexions entrantes autorisées et limiter l’accès de niveau administrateur à vos clusters Kubernetes.

  • Versioning : Dans la mesure où GitOps utilise un dépôt Git comme source de vérité, votre déploiement continu a des capacités de versioning, de restauration et d’audit intrinsèques.

  • Multilocataire : Une approche basée sur le tirage avec GitOps convient bien aux équipes distribuées et aux environnements multilocataires. Avec GitOps, vous pouvez utiliser des dépôts Git distincts et des droits d’accès distincts et distribuer les déploiements sur différents espaces de noms.

  • Cloud natif : D’autres applications sont en cours de modernisation ou de création pour offrir des solutions natives cloud. Pour toutes les organisations dont la plupart des applications s’exécutent dans Kubernetes, l’utilisation d’un opérateur GitOps pour le déploiement continu est plus simple et plus efficace qu’une approche du CI/CD classique basée sur la poussée.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Dans ce scénario, Azure Monitor est utilisé pour le monitoring des performances de vos applications et le signalement des problèmes. Il vous permet de monitorer et de résoudre les problèmes de performances qui peuvent nécessiter des mises à jour du code, qui peuvent ensuite être déployées avec le pipeline CI/CD.

Partie intégrante du cluster AKS, un équilibreur de charge distribue le trafic des applications vers un ou plusieurs conteneurs ou pods qui exécutent votre application. Cette méthode d’exécution des applications en conteneur dans Kubernetes assure à vos clients une infrastructure hautement disponible.

Notes

Cet article n’aborde pas directement la haute disponibilité des pipelines CI/CD. Pour plus d’informations, consultez Haute disponibilité pour GitHub Actions et Argo CD - Declarative GitOps CD for Kubernetes (Argo CD - Outil de déploiement continu GitOps déclaratif pour Kubernetes).

Des composants de résilience sont intégrés à Kubernetes. Ces composants supervisent et redémarrent les conteneurs, ou pods, en cas de problème. Quand plusieurs nœuds Kubernetes sont combinés, votre application peut tolérer un pod ou un nœud non disponible.

Pour obtenir des conseils d’ordre général sur la conception de solutions résilientes, consultez Conception d’applications Azure fiables.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Pour assurer la séparation des informations d’identification et des autorisations, ce scénario utilise un principal de service Microsoft Entra dédié. Les informations d’identification de ce principal de service sont stockées sous la forme d’un objet d’informations d’identification sécurisé dans GitHub, comme secrets GitHub Actions, pour qu’elles ne soient pas directement exposées ni visibles dans les scripts ou le pipeline de build.

Pour obtenir une aide générale sur la sécurisation des applications sur des clusters AKS, consultez Concepts de sécurité pour les applications et les clusters dans AKS.

Dans une optique de séparation des préoccupations, il est recommandé de séparer le calcul qui exécute l’application métier des agents CD ou de l’opérateur GitOps en exécutant l’application métier et l’opérateur GitOps dans des espaces de noms distincts sur le cluster Kubernetes. Pour une séparation des préoccupations plus poussée, l’opérateur GitOps peut être exécuté sur un cluster Kubernetes dédié à l’instance GitOps, distinct du cluster Kubernetes de production qui exécute l’application métier.

Notes

Cet article n’aborde pas directement la façon de sécuriser un pipeline CI/CD.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

AKS vous permet de mettre à l’échelle le nombre de nœuds de cluster pour répondre aux besoins de vos applications. À mesure que vos applications se développent, vous pouvez effectuer un scale-up du nombre de nœuds Kubernetes qui exécutent votre service.

Avec GitHub Actions, le fournisseur de cloud met à l’échelle le nombre d’exécuteurs automatiquement. Si des exécuteurs auto-hébergés sont utilisés, l’hôte de l’exécuteur sera chargé de les mettre à l’échelle selon les besoins.

Pour plus d’informations sur la scalabilité, consultez la check-list relative à l’efficacité des performances.

Déployer ce scénario

Suivez les étapes de l’implémentation de référence AKS-baseline-automation pour déployer le scénario. Le dépôt de l’implémentation de référence inclut des guides pas à pas pour les scénarios CI/CD basé sur la poussée et CI/CD basé sur le tirage (GitOps).

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Ce scénario utilise Azure Container Registry et AKS pour stocker et exécuter une application basée sur des conteneurs. Azure Container Apps et Azure Container Instances peuvent également être utilisés pour exécuter des applications basées sur des conteneurs, sans avoir à provisionner de composants d’orchestration. Pour plus d’informations, consultez Vue d’ensemble d’Azure Container Instances et Vue d’ensemble d’Azure Container Apps.

Documentation du produit :

Modules Microsoft Learn :