GitOps pour Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps est un ensemble de principes pour l’exploitation et la gestion d’un système logiciel. Cet article décrit les techniques d’utilisation des principes GitOps pour exploiter et gérer un cluster Azure Kubernetes Services (AKS).

Les logos Flux, Argo CD, OPA Gatekeeper, Kubernetes et git sont des marques commerciales de leurs sociétés respectives. L’utilisation de ces marques n’implique aucune approbation.

Architecture

Deux opérateurs GitOps que vous pouvez utiliser avec AKS sont Flux et Argo CD. Tous deux des projets validés de la Cloud Native Computing Foundation (CNCF) et sont largement utilisés. Les scénarios suivants montrent comment les utiliser.

Scénario 1 : GitOps avec Flux et AKS

Diagramme de GitOps avec Flux v2, GitHub et AKS.

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

Flux de données pour le scénario 1

Flux est une extension de cluster native pour AKS. Les extensions de cluster fournissent une plateforme pour l’installation et la gestion des solutions sur un cluster AKS. Vous pouvez utiliser le Portail Azure, Azure CLI ou des scripts IaC (Infrastructure As Code), comme des scripts Terraform ou Bicep, pour activer Flux en tant qu’extension d’AKS. Vous pouvez également utiliser Azure Policy pour appliquer des configurations Flux v2 à grande échelle sur des clusters AKS. Pour plus d’informations, consultez Déployez des applications de manière cohérente à l’échelle à l’aide de configurations Flux v2 et Azure Policy.

Flux peut déployer des manifestes Kubernetes, des graphiques Helm et des fichiers Kustomization sur AKS. Flux est un processus basé sur les interrogations, qui permet de détecter, d’extraire et de rapprocher les modifications de configuration sans exposer les points de terminaison de cluster à vos agents de build.

Dans ce scénario, les administrateurs Kubernetes peuvent modifier des objets de configuration Kubernetes, comme des secrets et des ConfigMaps, et valider les modifications directement dans un dépôt GitHub.

Le flux de données pour ce scénario est le suivant :

  1. Le développeur valide les modifications de configuration dans le dépôt GitHub.
  2. Flux détecte la dérive de configuration dans le dépôt Git et extrait les modifications de configuration.
  3. Flux rapproche l’état dans le cluster Kubernetes.

Alternatives pour le scénario 1

  • Vous pouvez utiliser Flux avec d’autres dépôts Git, comme Azure DevOps, GitLab et BitBucket.
  • Au lieu des dépôts Git, l’API Flux Bucket définit une source pour produire un artefact pour les objets à partir de solutions de stockage, comme les compartiments Amazon S3 et Google Cloud Storage. Vous pouvez également utiliser une solution qui a une API compatible S3. Minio et Alibaba Cloud OSS en sont deux exemples, mais il en existe d’autres.
  • Vous pouvez également configurer Flux sur un conteneur Stockage Blob Azure en tant que source pour produire des artefacts. Pour plus d’informations, consultez Configurations GitOps Flux v2 avec AKS et Kubernetes avec Azure Arc.

Scénario 2 : Utiliser GitOps avec Flux, GitHub et AKS pour implémenter la CI/CD

Diagramme de l’implémentation de la CI/CD en utilisant GitOps avec Flux, GitHub et AKS.

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

Flux de données pour le scénario 2

Ce scénario est un pipeline DevOps basé sur l’extraction pour une application web classique. Le pipeline utilise GitHub Actions pour la génération. Pour le déploiement, il utilise Flux comme opérateur GitOps pour extraire et synchroniser l’application. Les données circulent dans le scénario comme suit :

  1. Le code d’application est développé à l’aide d’un IDE, comme Visual Studio Code.
  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. L’opérateur Flux détecte la dérive de configuration dans le dépôt Git et extrait les modifications de configuration.
  6. Flux utilise des fichiers manifeste pour déployer l’application sur le cluster AKS.

Scénario 3 : GitOps avec Argo CD, dépôt GitHub et AKS

Diagramme de GitOps avec Argo CD, GitHub et AKS.

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

Flux de données pour le scénario 3

Dans ce scénario, les administrateurs Kubernetes peuvent modifier des objets de configuration Kubernetes, comme des secrets et des ConfigMaps, et valider les modifications directement dans le dépôt GitHub.

Le flux de données pour ce scénario est le suivant :

  1. L’administrateur Kubernetes apporte des modifications de configuration dans les fichiers YAML et les valide dans le dépôt GitHub.
  2. Argo CD effectue un tirage des modifications à partir du dépôt Git.
  3. Argo CD rapproche les modifications de configuration apportées au cluster AKS.

Argo CD n’a pas besoin de synchroniser automatiquement l’état cible souhaité avec le cluster AKS. Il est implémenté en tant que contrôleur Kubernetes qui surveille en permanence les applications en cours d’exécution. Il compare l’état actif actuel du cluster AKS à l’état cible souhaité spécifié dans le dépôt Git. Argo CD signale et visualise les différences, tout en fournissant des fonctionnalités permettant de synchroniser automatiquement ou manuellement l’état dynamique avec l’état cible souhaité.

Argo CD fournit une interface utilisateur basée sur un navigateur. Vous pouvez l’utiliser pour ajouter des configurations d’application, observer l’état de synchronisation par rapport au cluster et lancer la synchronisation sur le cluster. Vous pouvez également utiliser la ligne de commande Argo CD pour effectuer ces opérations. L’interface utilisateur et l’interface de ligne de commande fournissent des fonctionnalités permettant d’afficher l’historique des modifications de configuration et de restaurer une version précédente.

Par défaut, l’interface utilisateur Argo CD et le serveur d’API ne sont pas exposés. Pour y accéder, nous vous recommandons de créer un contrôleur d’entrée qui a une adresse IP interne. Vous pouvez également utiliser un équilibreur de charge interne pour les exposer.

Alternatives pour le scénario 3

Tout dépôt compatible avec Git, y compris Azure DevOps, peut servir de référentiel source de configuration.

Scénario 4 : Utiliser GitOps avec Argo CD, GitHub Actions et AKS pour implémenter CI/CD

Diagramme de l’implémentation de la CI/CD en utilisant GitOps avec Argo CD, GitHub et AKS.

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

Flux de données pour le scénario 4

Ce scénario est un pipeline DevOps basé sur l’extraction pour une application web classique. Le pipeline utilise GitHub Actions pour la génération. Pour le déploiement, il utilise Argo CD comme opérateur GitOps pour tirer et synchroniser l’application. Les données circulent dans le scénario comme suit :

  1. Le code d’application est développé à l’aide d’un IDE, comme Visual Studio Code.
  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 effectue un tirage à partir du dépôt Git.
  6. Argo CD déploie l’application sur le cluster AKS.

Alternatives pour le scénario 4

Tout dépôt compatible avec Git, y compris Azure DevOps, peut servir de référentiel source de configuration.

Détails du scénario

GitOps est un ensemble de principes pour l’exploitation et la gestion d’un système logiciel.

  • Il utilise le contrôle de code source comme source unique de vérité pour le système.
  • Il applique des pratiques de développement, telles que la gestion de version, la collaboration, la conformité, ainsi que l’intégration continue et le déploiement continu (CI/CD), à l’automatisation d’infrastructure.
  • Vous pouvez l’appliquer à n’importe quel système logiciel.

GitOps est souvent utilisé pour la gestion de cluster Kubernetes et la livraison d’applications. Cet article décrit certaines options courantes pour utiliser GitOps avec un cluster AKS.

Selon les principes de GitOps, l’état souhaité d’un système géré par GitOps doit être :

  1. Déclaratif : un système que GitOps gère doit avoir son état souhaité exprimé de manière déclarative. La déclaration est généralement stockée dans un référentiel Git.
  2. Versionné et immuable : l’état souhaité est stocké d’une manière qui applique l’immuabilité et le contrôle de version, et conserve un historique des versions complet.
  3. Extrait automatiquement : les agents logiciels extraient automatiquement les déclarations d’état souhaitées à partir de la source.
  4. Rapproché en continu : les agents logiciels observent en permanence l’état réel du système et tentent d’appliquer l’état souhaité.

Dans GitOps, l’infrastructure as code (IaC) utilise du code pour déclarer l’état souhaité des composants d’infrastructure, tels que les machines virtuelles (VM), les réseaux et les pare-feu. Ce code fait l’objet d’une gestion de version et peut être audité.

Kubernetes décrit tous les éléments, de l’état du cluster aux déploiements d’applications de manière déclarative avec des manifestes. GitOps pour Kubernetes place l’état souhaité de l’infrastructure du cluster sous une gestion de version. Un composant du cluster, généralement appelé opérateur, synchronise en continu l’état déclaratif. Cette approche permet d’examiner et d’auditer les modifications de code qui affectent le cluster. Cela améliore la sécurité en appliquant le principe des privilèges minimum.

Les agents GitOps rapprochent en continu l’état du système avec l’état souhaité stocké dans votre référentiel de code. Certains agents GitOps peuvent rétablir des opérations effectuées en dehors du cluster, comme la création manuelle d’objets Kubernetes. Les contrôleurs d’admission, par exemple, appliquent des stratégies sur les objets lors des opérations de création, de mise à jour et de suppression. Vous pouvez les utiliser pour vous assurer que les déploiements changent uniquement si le code de déploiement dans le référentiel source change.

Vous pouvez combiner des outils de gestion et d’application des stratégies avec GitOps pour appliquer des stratégies et fournir des commentaires sur les modifications de stratégie proposées. Vous pouvez configurer des notifications pour différentes équipes afin de leur fournir un état GitOps à jour. Par exemple, vous pouvez envoyer des notifications de réussites de déploiement et d’échecs de rapprochement.

GitOps comme source unique de vérité

GitOps assure la cohérence et la standardisation de l’état du cluster, et peut aider à améliorer la sécurité. Vous pouvez également utiliser GitOps pour garantir la cohérence de l’état entre plusieurs clusters. Par exemple, GitOps peut appliquer la même configuration sur les clusters principaux et de récupération d’urgence (DR), ou sur une batterie de clusters.

Si vous souhaitez appliquer une règle selon laquelle seul GitOps peut modifier l’état du cluster, vous pouvez restreindre l’accès direct au cluster. Il existe différentes façons de procéder, notamment le contrôle d’accès en fonction du rôle (RBAC) Azure, les contrôleurs d’admission et d’autres outils.

Utiliser GitOps pour démarrer la configuration initiale

Vous pourriez avoir besoin de déployer des clusters AKS dans le cadre de la configuration de base. Par exemple, vous devez déployer un ensemble de services partagés ou une configuration avant de déployer des charges de travail. Ces services partagés peuvent configurer des modules complémentaires AKS, comme :

Vous pouvez activer Flux en tant qu’extension appliquée lorsque vous créez un cluster AKS. Flux peut ensuite démarrer la configuration de base sur le cluster. L’architecture de référence pour un cluster AKS suggère d’utiliser GitOps pour le démarrage. Si vous utilisez l’extension Flux, vous pouvez démarrer des clusters très tôt après le déploiement.

Autres outils et modules complémentaires GitOps

Vous pouvez étendre les scénarios décrits à d’autres outils GitOps. Jenkins X est un autre outil GitOps qui fournit des instructions pour l’intégration à Azure. Vous pouvez utiliser des outils de livraison progressive, comme Flagger, pour le déplacement progressif des charges de travail de production déployées via GitOps.

Cas d’usage potentiels

Cette solution tire parti de toute organisation souhaitant profiter des avantages relatifs au déploiement d’applications et à infrastructure as code, avec un journal d’audit de chaque modification.

GitOps protège le développeur contre la complexité de la gestion d’un environnement de conteneur. Les développeurs peuvent continuer à utiliser des outils familiers, comme Git, pour gérer les mises à jour et les nouvelles fonctionnalités. De cette façon, GitOps améliore la productivité des développeurs.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour 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é.

La résilience est l’un des piliers clés de la fiabilité. L’objectif de la résilience est que l’application retrouve un état entièrement fonctionnel suite à une défaillance. Si un cluster devient indisponible, GitOps peut en créer un nouveau rapidement. Il utilise le référentiel Git comme source unique de vérité pour la configuration Kubernetes et la logique d’application. Il peut créer et appliquer la configuration de cluster et le déploiement d’applications en tant qu’unité d’échelle, et établir le modèle d’empreinte de déploiement.

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é.

Avec l’approche de GitOps, les développeurs ou administrateurs individuels n’accèdent pas directement aux clusters Kubernetes pour appliquer des modifications ou des mises à jour. Au lieu de cela, les utilisateurs envoient les modifications vers un référentiel Git et l’opérateur GitOps (Flux ou Argo CD), les lit et les applique au cluster. Cette approche permet de respecter les meilleures pratiques en matière de sécurité d’accès minimal en n’accordant pas aux équipes DevOps d’autorisations d’écriture sur l’API Kubernetes. Au cours des scénarios de diagnostic ou de résolution des problèmes, vous pouvez octroyer des autorisations de cluster pendant une durée limitée au cas par cas.

Outre la tâche de configuration des autorisations de référentiel, envisagez d’implémenter les mesures de sécurité suivantes dans les référentiels Git qui se synchronisent avec des clusters AKS :

  • Protection de branche : empêcher l’envoi direct des modifications aux branches représentant l’état des clusters Kubernetes. Utilisez des demandes de tirage pour apporter des modifications, et faites en sorte qu’au moins une autre personne examine chaque demande de tirage. Utilisez également les PR pour effectuer des vérifications automatiques.
  • Révision de demande de tirage : demandez à ce que les PR bénéficient d’au moins un réviseur afin d’appliquer le principe des quatre yeux. Vous pouvez également utiliser la fonctionnalité des propriétaires du code GitHub pour définir des personnes ou des équipes chargées de la révision de fichiers spécifiques dans un référentiel.
  • Historique immuable : n’autorisez que les nouvelles validations en plus des modifications existantes. L’historique immuable est particulièrement important pour les audits.
  • Mesures de sécurité supplémentaires : demandez à vos utilisateurs GitHub d’activer l’authentification à deux facteurs. En outre, autorisez uniquement les validations signées pour empêcher les modifications.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

  • Sur le niveau gratuit, AKS offre une gestion de cluster gratuite. Les coûts sont limités aux ressources de calcul, de stockage et de mise en réseau utilisées par AKS pour héberger des nœuds.
  • GitHub offre un service gratuit, mais pour utiliser des fonctionnalités avancées en matière de sécurité, telles que les propriétaires du code ou les réviseurs requis, vous avez besoin d’un plan d’Équipe. Pour plus d’informations, consultez la Page de tarification GitHub.
  • Azure DevOps offre un niveau gratuit que vous pouvez utiliser pour certains scénarios.
  • Utiliser la calculatrice de prix Azure pour estimer les coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

GitOps peut augmenter la productivité de DevOps. L’une des fonctionnalités les plus utiles est la possibilité de restaurer rapidement les modifications qui se comportent de façon inattendue, en effectuant simplement des opérations Git. Le graphique de validation contient toujours toutes les validations pour qu’il puisse servir lors de l’analyse post-mortem.

Les équipes GitOps gèrent souvent plusieurs environnements pour la même application. Il est normal que plusieurs étapes d’une application soient déployées sur différents clusters ou espaces de noms Kubernetes. Le référentiel Git, qui est la seule source de vérité, indique les versions des applications actuellement déployées sur un cluster.

Déployer un scénario

La liste suivante fournit des références pour obtenir des informations sur le déploiement des cinq scénarios suivants :

Contributeurs

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

Auteur principal :

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

Étapes suivantes