Argo CD

Introduction

Qu'est-ce que GitOps

GitOps est un cadre opérationnel qui utilise Git comme la source unique de vérité pour gérer à la fois l'infrastructure et le code des applications. Il étend les principes de l'Infrastructure as Code, permettant des déploiements et des retours en arrière automatisés en contrôlant l'ensemble du pipeline de livraison du code via le contrôle de version Git.

Workflow GitOps

Les développeurs commencent par committer leurs changements dans un repository Git centralisé. En général, ils travaillent dans des feature branches créées comme des copies de la base de code principale. Ces branches permettent aux équipes de développer de nouvelles fonctionnalités en isolation jusqu'à ce qu'elles soient prêtes. Un service de Continuous Integration (CI) construit automatiquement l'application et exécute des tests unitaires sur le nouveau code. Une fois les tests réussis, les changements sont soumis à un processus de révision et d'approbation par les membres de l'équipe concernés avant d'être mergés dans le repository central.

La dernière étape du pipeline est le Continuous Deployment (CD), où les changements du repository sont automatiquement déployés vers des Kubernetes clusters.

L'image illustre le workflow GitOps, montrant l'intégration de l'infrastructure, de la configuration et du code de l'application dans un repository Git, suivie des processus de continuous integration (CI) et de continuous deployment (CD) vers un Kubernetes cluster. Elle représente également le processus de branching et de merging dans Git.

Au cœur de GitOps se trouve le concept d'état défini de manière déclarative. Cela implique de maintenir votre infrastructure, les configurations des applications et les composants associés dans un ou plusieurs repositories Git. Un processus automatisé vérifie en continu que l'état stocké dans Git correspond à l'état réel dans l'environnement de production. Cette synchronisation est gérée par un GitOps operator qui fonctionne au sein d'un Kubernetes cluster. L'operator surveille le repository pour détecter des mises à jour et applique les changements souhaités au cluster — ou même à d'autres clusters si nécessaire.

Lorsque un développeur merge du nouveau code dans le repository de l'application, une série d'étapes automatisées est déclenchée : les tests unitaires sont exécutés, l'application est construite, une image Docker est créée et poussée dans un container registry, et enfin, les Kubernetes manifests dans un autre repository Git sont mis à jour.

L'image illustre un workflow GitOps, montrant le processus depuis le merging du code de l'application, la continuous integration, jusqu'au déploiement des Kubernetes manifests, avec les GitOps operators garantissant que l'état souhaité correspond à l'état réel dans les environnements de production.

L'operator GitOps compare en continu l'état souhaité (tel que défini dans Git) avec l'état réel dans le Kubernetes cluster. Si des écarts sont détectés, l'operator effectue les changements nécessaires pour garantir que l'environnement de production reste aligné avec la configuration souhaitée.

L'image illustre un workflow GitOps, montrant le processus depuis le repository du code de l'application jusqu'à l'intégration continue, puis le déploiement dans Kubernetes, mettant en évidence la synchronisation entre les états souhaité et réel.

Facilité des Rollbacks

L'un des principaux avantages de GitOps est la simplicité du processus de rollback. Puisque toute la configuration est maintenue dans Git, revenir à un état précédent est aussi simple que d'exécuter la commande git revert. L'operator GitOps détecte ce changement et effectue automatiquement un rollback de l'environnement de production pour correspondre à l'état souhaité.

L'image illustre un workflow GitOps, montrant le processus depuis le repository du code de l'application jusqu'à l'intégration continue, puis le déploiement dans Kubernetes, soulignant la synchronisation entre les états souhaité et réel.

---

Les principes de GitOps

Dans cette leçon, nous allons explorer les principes fondamentaux de GitOps, une approche du déploiement continu qui utilise Git comme la source unique de vérité pour l'état de l'infrastructure et des applications. La méthodologie GitOps repose sur quatre principes de base.

Rappel

GitOps assure la cohérence du système et réduit les erreurs humaines en imposant un modèle déclaratif pour la gestion de l'infrastructure.

1. Approche déclarative vs. impérative

Le premier principe met l'accent sur une méthodologie déclarative plutôt qu'impérative. Dans le modèle déclaratif, l'ensemble du système, y compris l'infrastructure et les manifests des applications, est décrit dans un état souhaité. Cela contraste avec l'approche impérative, où des commandes spécifiques sont exécutées séquentiellement pour modifier l'état du système. S'appuyer sur un style impératif peut compliquer la réconciliation, car il ne maintient pas un enregistrement complet de l'état prévu du système.

2. Stockage de l'état souhaité dans Git

Le deuxième principe stipule que tous les fichiers déclaratifs, qui représentent l'état souhaité du système, doivent être stockés dans un repository Git. Git offre non seulement de puissantes capacités de contrôle de version, mais préserve également l'immuabilité. Stocker l'état souhaité dans Git en fait la source définitive de vérité pour la configuration du système. Toute modification envoyée à Git est automatiquement reconnue et appliquée à travers le système.

3. Application automatisée de l'état souhaité via les opérateurs GitOps

Le troisième principe consiste à utiliser des GitOps operators, des agents logiciels qui surveillent en continu Git pour détecter des mises à jour. Une fois qu'ils détectent des changements, ces opérateurs récupèrent automatiquement l'état souhaité depuis le repository et l'appliquent à un ou plusieurs clusters ou environnements. Voici un exemple de manifeste de déploiement qu'un opérateur GitOps pourrait gérer :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx

Cet opérateur peut fonctionner dans un seul cluster et propager les changements de configuration vers d'autres clusters si nécessaire, garantissant ainsi l'uniformité et la scalabilité.

4. Réconciliation et Self-Healing

Le dernier principe se concentre sur la réconciliation continue. Les opérateurs GitOps maintiennent un système de Self-Healing en vérifiant constamment les écarts entre l'état actuel du système et l'état souhaité stocké dans Git. Ils exécutent ce processus en trois étapes clés :

• Observe: Surveiller un repository Git pour les mises à jour.
• Diff: Comparer l'état souhaité depuis Git avec l'état actuel du cluster.
• Act: Réconcilier les différences en mettant à jour le système pour refléter l'état souhaité déclaré.

Ce cycle de réconciliation continu minimise les risques de configuration drift et aide à maintenir un système robuste et résistant aux erreurs.

En comprenant et en appliquant ces principes GitOps, vous pouvez garantir que votre infrastructure reste cohérente, scalable et résiliente face aux changements.

---

GitOps Introduction

DevOps vs GitOps

Cette leçon explore les approches contrastées de DevOps et GitOps — deux méthodologies qui partagent des objectifs communs mais diffèrent de manière significative dans leur exécution et leurs outils.

GitOps utilise des technologies de containerisation telles que OpenShift et Kubernetes. Il se base sur Git comme la source unique de vérité pour l'infrastructure et les déploiements. En comparaison, DevOps est une méthodologie plus large qui peut être appliquée à divers environnements d'applications et workflows.

Pipeline DevOps

Un pipeline DevOps typique fonctionne comme suit :

1. Un développeur écrit du code dans un Integrated Development Environment (IDE) et le commit dans un système de gestion de code source.
2. Un processus de Continuous Integration (CI) détecte le commit, exécute des tests et construit les artefacts nécessaires.
3. Le pipeline crée ensuite une image de conteneur et la publie dans un container repository.
4. Enfin, le processus de Continuous Deployment (CD) se connecte à un Kubernetes cluster et utilise un outil en ligne de commande tel que kubectl (avec des commandes impératives) pour pousser les mises à jour directement vers le cluster.

Point clé

Dans DevOps, le déploiement est initié par l'envoi des changements directement dans le cluster.

Pipeline GitOps

Bien que les processus de CI dans un pipeline GitOps ressemblent à ceux de DevOps jusqu'à la publication de l'image de conteneur, le processus de déploiement est distinct :

1. Deux Git repositories séparés sont maintenus : l'un dédié au code de l'application et l'autre aux Kubernetes manifests.
2. Une fois l'image publiée, le manifest repository est cloné et mis à jour — généralement le nom de la nouvelle image est spécifié. Ces changements sont ensuite commit et poussés.
3. Le pipeline crée automatiquement une pull request pour le manifest repository. Un membre de l'équipe examine la pull request, suggère des ajustements si nécessaire, et merge les changements après approbation.
4. Un GitOps operator, fonctionnant dans le Kubernetes cluster, surveille en continu le repository. Lorsque des changements sont détectés, il synchronise l'état du cluster pour correspondre à la configuration du repository.

À

Dans un pipeline GitOps, l'operator de déploiement tire les changements depuis le repository et les applique au cluster, contrairement à l'approche push des workflows DevOps traditionnels.

L'image ci-dessous illustre une comparaison côte à côte des pipelines CI/CD dans DevOps et GitOps. Elle met en évidence les étapes clés, allant du développement du code au déploiement, et souligne les différences dans la gestion et l'application des mises à jour.

L'image compare les pipelines CI/CD de DevOps et GitOps, illustrant les processus d'intégration continue et de déploiement pour chaque approche. Elle met en évidence les étapes du développement du code au déploiement, montrant les différences dans la gestion et l'application des mises à jour.

Conclusion

Cet article a comparé les pipelines DevOps et GitOps en détaillant les étapes clés de chaque processus. Comprendre ces différences est essentiel pour choisir la bonne méthodologie pour vos projets. Dans la prochaine leçon, nous explorerons les avantages et les défis associés à chaque approche.

---

Push vs Pull Deployment

Dans cet article, nous explorons les différences entre les stratégies de déploiement push-based et pull-based pour les Kubernetes clusters. Nous examinerons leurs avantages, défis et cas d'utilisation, afin de vous aider à déterminer la meilleure approche pour votre environnement.

Push-Based Deployment

Le push-based deployment est couramment utilisé dans les pipelines CI/CD. Avec cette approche, le code de l'application passe par différentes étapes dans le pipeline CI avant que les mises à jour ne soient poussées directement vers le Kubernetes cluster.

Caractéristiques clés

• Le système CI nécessite un accès en lecture-écriture au Kubernetes cluster, ce qui signifie que les informations d'identification Kubernetes sont stockées dans le système CI, en dehors du cluster. Cette organisation peut introduire des risques potentiels de sécurité.
• En général, le système CI a un accès en lecture seule au Git repository et un accès en lecture-écriture au container registry, tandis que le Kubernetes cluster lui-même n'a qu'un accès en lecture seule au registre.
• Les déploiements peuvent tirer parti de divers plugins et outils. Par exemple, Jenkins peut utiliser plusieurs plugins ou approches, et les plugins Helm simplifient davantage le déploiement des Helm charts.

Warning

Le stockage des informations d'identification Kubernetes dans le système CI expose un risque de sécurité potentiel, car ces informations permettent un accès en lecture-écriture au cluster.

Challenges

• La configuration du déploiement est étroitement liée au système CI. Migrer d'une plateforme CI à une autre (par exemple, passer de Jenkins à une autre plateforme) nécessite souvent de retravailler de nombreuses configurations de déploiement.
• L'intégration des informations d'identification du cluster dans le système CI augmente le risque d'accès non autorisé si le système CI est compromis.

Pull-Based Deployment

Le pull-based deployment, souvent associé à GitOps, utilise un operator fonctionnant au sein du Kubernetes cluster. Cet operator surveille les changements — soit dans un container registry pour les nouvelles images, soit dans un Git repository pour les manifests mis à jour — et déploie ensuite ces changements de manière autonome.

Caractéristiques clés

• Le système CI/CD n'a besoin que d'un accès en lecture-écriture au container registry, sans nécessiter d'accès direct au Kubernetes cluster.
• Les déploiements sont exécutés en interne depuis le cluster, améliorant la sécurité en minimisant l'accès externe.
• Les GitOps operators sont particulièrement utiles dans les environnements multi-tenant, permettant aux équipes de gérer plusieurs repositories et namespaces. Par exemple, différentes équipes peuvent maintenir des Git repositories distincts et des namespaces correspondants pour leurs déploiements.
• Les secrets peuvent être gérés de manière sécurisée en les cryptant à l'aide d'outils comme HashiCorp Vault ou Bitnami Sealed Secrets. Ces secrets cryptés sont stockés dans Git ou décryptés lors du processus de déploiement.
• Les GitOps operators peuvent surveiller les container registries pour les nouvelles versions d'images et déclencher automatiquement le déploiement des dernières images.

Gestion des secrets

Bien que GitOps encourage la gestion déclarative, y compris des secrets, dans Git, le processus nécessite souvent des outils et des étapes supplémentaires (par exemple, la cryptographie et le décryptage) pour garantir la sécurité, en particulier pour les déploiements Helm charts.

Challenges

La gestion des secrets et des configurations peut être plus complexe par rapport au modèle push-based. Bien que les principes de GitOps promeuvent une approche déclarative, la gestion des informations d'identification cryptées ajoute une couche de complexité supplémentaire.

Comparaison visuelle

L'image compare les méthodes de déploiement push-based et pull-based pour Kubernetes, en mettant en évidence leurs processus, permissions d'accès, avantages et inconvénients.

L'image compare les méthodes de déploiement push-based et pull-based pour Kubernetes, illustrant les processus d'intégration continue et de déploiement pour chaque approche. Elle met en évidence les étapes allant du développement du code au déploiement, montrant les différences dans la gestion et l'application des mises à jour.

Résumé

Stratégie de déploiement	Avantages	Inconvénients
Push-Based	- Intégration directe avec les pipelines CI/CD - Configuration de déploiement flexible en utilisant divers outils et plugins	- Nécessite que le système CI ait des informations d'identification du cluster - Lié étroitement aux systèmes CI, ce qui rend les migrations difficiles
Pull-Based (GitOps)	- Sécurité améliorée en limitant l'accès externe - Prise en charge des environnements multi-tenant et des mises à jour automatiques des images	- Gestion des secrets plus complexe - Outils supplémentaires nécessaires pour la cryptographie et le décryptage des configurations

En résumé, les stratégies de déploiement push-based simplifient certains aspects de l'automatisation mais peuvent entraîner des problèmes de flexibilité et de sécurité potentiels. En revanche, les déploiements pull-based (GitOps) améliorent la gestion interne et la sécurité au prix d'une complexité accrue dans la gestion des secrets et des configurations.

---

Ensemble de fonctionnalités GitOps

Cet article fournit une vue détaillée des fonctionnalités GitOps et de leurs cas d’usage associés, démontrant comment le fait de stocker chaque configuration de manière déclarative dans un dépôt Git peut transformer vos workflows de déploiement.

Chaque configuration est stockée de façon déclarative dans Git, qui sert de single source of truth contenant l’état désiré complet du système. Cette approche simplifie non seulement les application rollbacks — permettant une récupération rapide via un simple git revert — mais garantit également que les audit trails sont automatiquement disponibles via les pull requests et l’historique des commits.

Avantage clé

• Stocker les configurations dans Git permet aux équipes de revenir facilement à un état précédent.
• Maintien d’une trace complète (audit trail) pour tous les changements.

Automatisation CI/CD et déploiement continu

L’automatisation CI/CD est un pilier fondamental de GitOps. En tirant parti de cette automatisation :

• Les tâches de build, de test et de déploiement sont déclenchées automatiquement en fonction de l’état désiré stocké dans Git.
• Le continuous deployment devient fluide et cohérent : les applications sont déployées automatiquement sur les clusters sans intervention manuelle.

Étendre GitOps à l’infrastructure et aux ressources de cluster

Une fois GitOps établi pour le déploiement applicatif, ces pratiques peuvent être étendues à la gestion des ressources de cluster et de l’Infrastructure as Code. Par exemple, dans des environnements Kubernetes, il est possible de gérer différentes ressources, notamment :

• Secrets management
• Networking agents et configurations de service mesh
• Database provisioning
• Prometheus monitoring

Le principe central ici est l’automatic reconciliation : le système compare continuellement l’état désiré dans Git avec l’état réel dans le cluster. Si des changements non désirés apparaissent, le système les annule automatiquement afin d’assurer la cohérence.

Automatic Reconciliation

• GitOps compare continuellement l’état désiré défini dans Git avec l’état réel au runtime.
• Tout drift est détecté et automatiquement annulé pour maintenir l’alignement de l’infrastructure.

Détection et prévention du configuration drift

• La détection précoce du configuration drift permet de résoudre les incohérences dès leur apparition.
• Agir rapidement évite que de petites divergences se transforment en problèmes majeurs.
• Cette posture proactive distingue GitOps des autres méthodologies de déploiement.

Déploiement multi-clusters simplifié

Gérer plusieurs clusters, en particulier répartis géographiquement, peut être complexe. GitOps simplifie ce processus en centralisant l’état des clusters dans Git. Cela signifie :

• Un seul operator peut déployer des applications sur plusieurs clusters.
• Pas besoin d’installer ou de configurer l’operator individuellement sur chaque cluster.
• Le processus de déploiement est rationalisé et significativement plus efficace.

L’image illustre un ensemble de fonctionnalités GitOps et des cas d’usage, présentant un workflow impliquant des outils comme Helm et Jenkins, des dépôts Git et des clusters Kubernetes pour le continuous deployment et l’automatisation. Elle met en avant des concepts tels que single source of truth, everything as code, auditable processes et multi-cluster deployments.

En adoptant GitOps, les équipes peuvent atteindre un haut niveau d’efficacité de déploiement, une meilleure gestion à travers des environnements variés et des mécanismes de récupération robustes, faisant de cette pratique une stratégie essentielle pour la gestion d’infrastructures modernes.

---

Avantages et inconvénients de GitOps

Cet article passe en revue les principaux avantages et défis associés à GitOps, fournissant des éléments pour gérer efficacement les déploiements d’applications Kubernetes.

Avantages de GitOps

GitOps offre plusieurs avantages convaincants :

• Il est léger et vendor-neutral, s’appuyant sur le protocole Git open source pour fonctionner de manière transparente sur des plateformes variées.
• GitOps permet des déploiements plus rapides et plus sûrs en garantissant des environnements immuables et reproductibles.
• Dans des équipes où des changements d’environnement peuvent survenir de manière inattendue, GitOps empêche les modifications non désirées. The GitOps operator impose la cohérence en interdisant les mises à jour manuelles, éliminant ainsi le configuration drift.
• En cas de mise à jour manuelle, the GitOps operator restaure automatiquement l’état désiré depuis Git.
• Les développeurs bénéficient de la familiarité de Git et des outils CI/CD. Le workflow reste simple : push the code to the repository, et un pipeline CI/CD gère les tests et le déploiement.
• L’historique Git permet de comparer facilement les révisions de fichiers déclaratifs, facilitant la corrélation des changements avec des change requests spécifiques.

Note

Pour plus de détails sur les intégrations CI/CD avec GitOps, consultez la GitOps Documentation officielle.

Défis de GitOps

Malgré ses avantages, GitOps introduit quelques défis à adresser :

• Centralized Secret Management : GitOps ne sécurise pas les secrets par défaut. Bien qu’il recommande de stocker les secrets de manière déclarative dans les repositories Git, les équipes ops doivent intégrer des outils supplémentaires pour gérer les secrets de façon sécurisée.
• Repository Organization : À mesure que le nombre de microservices et d’environnements augmente, l’organisation des repositories Git devient complexe. Il faut décider s’il convient de stocker le source code et les manifests dans un seul repository ou d’utiliser plusieurs repositories/branches. Il n’existe pas de solution universelle — chaque organisation doit adapter cette approche à ses besoins applicatifs.
• Update Conflicts : Des mises à jour fréquentes en environnement de continuous delivery peuvent déclencher des processus CI simultanés, conduisant à plusieurs pull requests. Cela peut provoquer des conflits lorsque plusieurs processus tentent de mettre à jour le GitOps repository en concurrence, nécessitant souvent une résolution manuelle.
• Governance and Policy Enforcement : S’appuyer sur les pull requests (PRs) pour l’approbation peut réduire l’efficacité de l’application stricte des politiques d’entreprise après approbation d’une PR.
• Configuration Validation : Des fichiers YAML mal formés ou des erreurs de configuration peuvent survenir. Des outils externes de validation sont essentiels pour garantir que les manifest files respectent les standards requis.

Warning

Assurez-vous d’intégrer une gestion robuste des secrets et une stratégie claire d’organisation des repositories lors de la mise en place de GitOps afin d’atténuer efficacement ces défis.

L’image liste les avantages et les défis de GitOps, mettant en évidence des points tels que sa légèreté et son indépendance vis-à-vis des fournisseurs, ainsi que des enjeux comme la gestion des secrets et la multiplication des Git repositories.

---

Projets et outils GitOps

Dans cet article, nous explorons une variété de projets et outils GitOps disponibles à ce jour. Ces solutions sont conçues pour simplifier la gestion des applications Kubernetes en tirant parti des pratiques GitOps à travers différents controllers et outils d’automatisation.

Aperçu

Ce guide fournit des informations sur les controllers GitOps ainsi que sur les outils complémentaires qui améliorent le déploiement et la gestion des applications Kubernetes.

GitOps Controller : ArgoCD

ArgoCD est notre principal GitOps controller. Il s’agit d’un outil de déploiement continu déclaratif pour Kubernetes qui simplifie la gestion des applications tout en garantissant que le processus de déploiement reste automatisé et cohérent.

Outils GitOps supplémentaires

Améliorez vos workflows GitOps pour Kubernetes avec ces outils supplémentaires :

• Atlantis : Automatise les workflows Terraform en s’intégrant directement aux pull requests.
• AutoApply : Applique automatiquement les modifications de configuration depuis un repository Git vers votre cluster Kubernetes, réduisant l’intervention manuelle.
• CloudRollout : Fournit un système avancé de feature flagging, permettant aux équipes de déployer et itérer rapidement sans compromettre la sécurité.
• GitOps avec FluxCD : Offre des solutions de livraison continue et progressive optimisées pour les environnements Kubernetes.
• Helm Operator : Automatise le déploiement des Helm charts selon les principes GitOps.
• Flagger : Un operator Kubernetes spécialisé dans la livraison progressive. Il prend en charge les canary releases, les tests A/B et les déploiements blue-green.
• Ignite : Fonctionne comme un gestionnaire de machines virtuelles avec une expérience utilisateur proche des containers, intégrant des fonctionnalités GitOps.
• Faros : Un GitOps controller utilisant les Custom Resource Definitions (CRDs) pour simplifier les opérations.
• GitKube : Facilite la construction d’images Docker et leur déploiement sur des clusters Kubernetes via un workflow Git push.
• Jenkins X : Conçu pour Kubernetes, cette plateforme CI/CD offre l’automatisation des pipelines avec GitOps intégré et des environnements de preview.
• KubeStack : Utilise Terraform pour fournir un framework GitOps pour les distributions cloud Kubernetes comme AKS, GKE et EKS, avec des exemples CI/CD.
• Weave Cloud : Une plateforme d’automatisation et de gestion supportant à la fois les équipes de développement et DevOps.
• PipeCD : Une solution de continuous delivery pour Kubernetes déclaratif, serverless et applications d’infrastructure.

L’image liste ces différents projets et outils GitOps, chacun représenté par un logo et un nom, tels que ArgoCD, FluxCD et JenkinsX.

Pour aller plus loin

Pour approfondir vos connaissances sur Kubernetes et les pratiques GitOps, vous pouvez consulter des ressources telles que la documentation Kubernetes et Docker Hub.

---

ArgoCD Basics

WhatWhyHow ArgoCD

Cette leçon explore ArgoCD, en détaillant ce que c’est, pourquoi l’utiliser, et comment il fonctionne pour transformer votre workflow de continuous delivery.

ArgoCD utilise des spécifications déclaratives et la gestion de configuration basée sur Git, offrant des avantages significatifs pour le continuous delivery. Il constitue un élément central pour atteindre des opérations continues grâce à la combinaison de monitoring, d’analyses et de remédiation automatisée, ce qui le rend idéal pour les environnements d’entreprise. Ses fonctionnalités avancées telles que l’auditabilité, la conformité, la sécurité, le RBAC et le SSO renforcent encore son attrait.

Qu’est-ce qu’ArgoCD ?

ArgoCD est un outil GitOps de continuous delivery conçu pour Kubernetes. Il considère un repository Git comme la single source of truth pour l’état désiré de vos applications. En surveillant continuellement les applications en cours d’exécution, ArgoCD compare l’état actuel avec l’état désiré stocké dans Git. En cas de divergences, il signale ces différences et fournit des informations visuelles, permettant aux développeurs de synchroniser l’état live avec la configuration désirée, soit manuellement, soit automatiquement.

Point

ArgoCD simplifie la gestion des ressources Kubernetes en garantissant que l’état live de votre application reflète toujours la configuration définie dans votre repository Git.

Comment fonctionne ArgoCD ?

ArgoCD suit le modèle GitOps en utilisant les repositories Git comme référence pour l’état désiré de vos applications et pour l’environnement de déploiement cible. Cette approche transparente et cohérente rend les processus de déploiement fiables et facilement auditable.

L’image est une infographie expliquant ArgoCD, un outil GitOps de continuous delivery pour Kubernetes, détaillant ce que c’est, pourquoi l’utiliser et comment il fonctionne. Elle met en avant ses avantages, tels que les spécifications déclaratives, le monitoring continu et les fonctionnalités adaptées aux entreprises.

ArgoCD prend en charge une variété de manifests Kubernetes. Que vous travailliez avec des applications personnalisées, des Helm charts, des fichiers JSON ou YAML, ArgoCD automatise le processus de synchronisation pour garantir que l’état des applications déployées dans tous les environnements cibles correspond toujours à celui défini dans Git.

---

Concepts et terminologie

Avant d’explorer l’architecture d’ArgoCD, il est essentiel de comprendre ses concepts clés et sa terminologie. Une bonne connaissance de Git, Docker, Kubernetes, des principes CI/CD et de GitOps est fortement recommandée pour tirer le meilleur parti d’ArgoCD.

Recommandation

Avant de commencer, assurez-vous de bien maîtriser les technologies fondamentales mentionnées ci-dessus afin de faciliter l’intégration avec ArgoCD.

Concepts clés d’ArgoCD

ArgoCD Applications

Dans ArgoCD, vous travaillez principalement avec des objets appelés ArgoCD applications. Ces applications sont des Custom Resource Definitions (CRD) installées avec ArgoCD qui définissent à la fois la source (repository Git) et la destination (cluster Kubernetes) de vos ressources Kubernetes.

Source Types

Chaque ArgoCD application est associée à un source type qui identifie l’outil ou la méthode utilisée pour construire l’application.

• Helm et Kustomize sont des exemples courants de source types.
• Cette approche modulaire permet d’utiliser différents outils selon votre stratégie de déploiement.

ArgoCD Projects

Un ArgoCD project agit comme un regroupement logique d’applications, facilitant la gestion des ressources, surtout lorsque plusieurs équipes sont impliquées. Regrouper les applications liées sous un même projet simplifie l’application des politiques et la segmentation des ressources.

Target State vs Live State

• Target State : La configuration désirée stockée dans votre repository Git.
• Live State : L’état actuel des ressources déployées (pods, secrets, config maps, etc.) dans votre cluster Kubernetes.

ArgoCD compare continuellement ces deux états.

Sync Operation

Lorsque vous créez une ArgoCD application, l’outil synchronise le Target State (depuis Git) avec le Live State (dans le cluster). Ce processus, appelé sync, réconcilie la configuration actuelle du cluster avec la version spécifiée dans Git. Par exemple, si des modifications sont apportées dans le repository Git, une opération de sync met à jour le cluster Kubernetes en conséquence.

• Sync Status : Indique si le Live State correspond au Target State.
• Operation Status : Montre si une opération de sync s’est terminée avec succès.

Refresh Operation

Une opération de refresh dans ArgoCD réévalue le code le plus récent dans Git par rapport au Live State actuel. Elle :

• Identifie les différences éventuelles.
• Peut automatiquement initier un sync ou inviter un administrateur à le déclencher manuellement.

Health Assessments

ArgoCD inclut des évaluations de santé intégrées pour les ressources Kubernetes standards. Ces évaluations fournissent un état de santé global de vos applications, assurant une visibilité sur leur état opérationnel et leur conformité à la configuration.

---

Features

ArgoCD se distingue en rationalisant le déploiement, la surveillance et la gestion des applications à travers plusieurs clusters. Voici un aperçu de ses principales fonctionnalités :

• Déploiement automatique : Déploie continuellement les applications vers les cibles désignées à travers les clusters, garantissant cohérence et mises à jour rapides.
• Traçabilité complète : Offre une visibilité totale grâce à une piste d’audit détaillée des événements applicatifs et des appels API.
• Intégrations SSO : Sécurise votre infrastructure avec des intégrations single sign-on via GitHub, GitLab, Microsoft, LinkedIn, et d'autres plateformes.
• Synchronisation via Webhooks : Réagit immédiatement aux push events en synchronisant les applications via des webhooks provenant de GitHub, Bitbucket ou GitLab.
• Capacités de rollback : Permet de revenir facilement à toute configuration antérieure stockée dans votre dépôt Git en cas de problème.
• Interface Web intuitive : Permet de surveiller les activités applicatives en temps réel via une interface simple et conviviale.
• Détection et visualisation du drift : Détecte automatiquement les écarts entre l’état désiré et l’environnement réel, avec des outils visuels pour identifier les différences.
• Monitoring intégré : Exploite les métriques Prometheus prêtes à l’emploi, visualisables dans Grafana pour une surveillance avancée.
• Gestion flexible des configurations : Supporte plusieurs outils de configuration tels que Kustomize, Helm et les fichiers YAML simples selon vos besoins de déploiement.
• Stratégies de déploiement avancées : Améliore les déploiements grâce aux hooks pre-sync, sync et post-sync, offrant un support pour les stratégies blue-green et canary.
• Support multi-tenant : Permet d’implémenter des politiques RBAC personnalisées pour une gestion sécurisée des rôles dans des environnements multi-locataires.
• CLI robuste et automatisation : Propose une CLI complète et un support des tokens d’accès pour une intégration fluide avec les workflows CI.
• Analyse de l’état de santé : Fournit une compréhension détaillée de la santé de toutes les ressources applicatives grâce à des vérifications intégrées et personnalisables.
• Synchronisation personnalisable : Autorise le choix entre une synchronisation automatique ou manuelle afin de maintenir l’état désiré des applications.

Note

La richesse fonctionnelle d’ArgoCD simplifie des workflows de déploiement complexes, le rendant hautement scalable et idéal pour les organisations de toutes tailles.

---

Architecture

Cet article fournit un aperçu complet de l’architecture d’ArgoCD, détaillant son intégration avec Kubernetes et son puissant workflow GitOps. En tirant parti d’ArgoCD, vous pouvez gérer de manière fluide vos applications et votre infrastructure, en veillant à ce que l’environnement live soit toujours aligné avec l’état désiré défini dans vos dépôts Git.

Fonctionnalités clés et capacités

ArgoCD fonctionne comme un Kubernetes controller une fois installé dans votre environnement Kubernetes. Il fournit une interface robuste via une command-line interface (CLI) et une web-based UI, vous permettant de :

• Créer et gérer des applications ArgoCD
• Organiser et maintenir des projets efficacement
• Intégrer le single sign-on (SSO) avec des fournisseurs externes
• Ajuster finement les options de synchronisation pour les déploiements applicatifs

Comment

ArgoCD surveille continuellement les applications déployées en comparant l’état en cours d’exécution avec l’état désiré stocké dans votre dépôt Git. Lorsque des changements sont commit dans le dépôt, ArgoCD récupère et applique automatiquement ces mises à jour, assurant que vos environnements restent cohérents.

Workflow GitOps et déploiement multi-cluster

L’approche GitOps d’ArgoCD garantit que toute modification dans le dépôt Git déclenche une mise à jour automatisée des environnements cibles. Vous pouvez également configurer un webhook sur votre dépôt Git pour alerter ArgoCD d’événements spécifiques, entraînant une synchronisation rapide.

Cette conception prend en charge les modèles de déploiement single-cluster et multi-cluster, vous permettant de connecter et déployer des ressources à travers plusieurs environnements Kubernetes tels que development, staging et production.

API et intégration

Le cœur des fonctionnalités d’ArgoCD réside dans son API server, implémenté comme un gRPC REST server. Cette API est accessible :

• Via l’interface utilisateur Web (UI)
• Via la command-line interface (CLI)
• Par les systèmes CI/CD

Cette structure API flexible permet une intégration simple avec une variété d’outils et workflows, soutenant une automatisation et une orchestration fluides de vos tâches d’infrastructure.

Monitoring et observabilité

ArgoCD fournit également un service de notification out-of-the-box comprenant plusieurs triggers et des modèles de messages personnalisables. Ce service peut envoyer des alertes à diverses plateformes tierces comme Slack, email et GitHub. De plus, il expose une suite de métriques Prometheus que vous pouvez visualiser avec Grafana, améliorant considérablement le monitoring et l’observabilité globale du système.

Monitoring

Assurez-vous de configurer Prometheus et Grafana pour tirer pleinement parti des capacités de monitoring d’ArgoCD, vous permettant d’obtenir des informations critiques sur les performances des applications et les événements de synchronisation.

L’image illustre l’architecture d’ArgoCD, montrant le workflow de GitHub vers divers clusters Kubernetes (prod, dev, staging) avec des interactions via UI, CLI et gRPC/REST, et des notifications envoyées vers des plateformes comme Teams, Gmail et Slack.

Résumé

ArgoCD simplifie le déploiement applicatif en intégrant les principes GitOps avec Kubernetes. Sa capacité à surveiller, automatiser et alerter à travers plusieurs clusters en fait un outil puissant pour les pipelines de déploiement continu modernes.

---

Voici la traduction simple de ton texte en gardant les termes techniques en anglais, comme demandé :

---

Voici la traduction avec les titres formatés en Markdown, comme demandé :

---

D'accord, je m'excuse pour l'oubli des nombres dans les titres et des points de bullet. Je ferai plus attention la prochaine fois. Voici la version corrigée avec les titres numérotés comme dans l'original, et en conservant la structure intacte pour les sections à puces :

---

Options d'Installation

Explorez les différents modèles d'installation d'ArgoCD pour déterminer lequel correspond le mieux à vos besoins de déploiement. ArgoCD peut être installé en deux modes principaux : une installation de base pour un usage mono-tenant et une installation multi-tenant pour des environnements nécessitant un accès isolé pour plusieurs équipes.

Installation de base

L'installation de base est conçue pour les utilisateurs qui exécutent ArgoCD comme un service autonome. Ce mode fournit un déploiement minimal, non haute disponibilité (non-HA), ce qui le rend parfait pour des configurations simples qui ne nécessitent pas de multi-tenancy.

Installation Multi-Tenant

Les déploiements multi-tenant sont idéaux pour les organisations avec plusieurs équipes de développement d'applications, généralement gérées par une équipe plateforme centralisée. Dans le modèle multi-tenant, vous avez deux variantes d'installation :

1. Non-High Availability (non-HA)

Cette variante est excellente pour l'évaluation, les tests et les déploiements de proof-of-concept, bien qu'elle ne soit pas recommandée pour un usage en production.

install.yaml : Déploie ArgoCD avec un accès cluster-admin, ce qui le rend adapté aux clusters où ArgoCD déploie également des applications. De plus, les identifiants fournis permettent de déployer sur des clusters distants.

namespace-installed.yaml : Configure ArgoCD pour un accès au niveau du namespace, offrant des permissions restreintes. Cette option est utile lorsque vous voulez limiter l'accès d'ArgoCD tout en déployant des applications dans le même cluster si nécessaire.

2. High Availability (HA)

Pour les environnements de production, l'option haute disponibilité est le choix recommandé. Elle améliore la résilience en déployant plusieurs réplicas pour les composants critiques. Deux manifestes sont fournis :

ha-install.yaml ha-namespace-installed.yaml L'image est un diagramme de flux illustrant les options d'installation, montrant les chemins pour "Core" et "Multi-Tenant" menant aux configurations "Non High Availability" et "High Availability" avec les fichiers YAML correspondants. Un personnage de pieuvre est sur le côté gauche.

Note de Déploiement

Dans cette leçon, nous déploierons ArgoCD dans le namespace argocd en utilisant le manifeste d'installation non-HA (install.yaml).

Installation d'ArgoCD avec Helm

En plus de l'installation standard, ArgoCD peut être installé à l'aide de Helm via un chart maintenu par la communauté. Par défaut, le chart Helm déploie la version non-HA d'ArgoCD.

Après l'installation, téléchargez le CLI ArgoCD depuis son dépôt GitHub et déplacez-le dans votre répertoire binaire local. Le CLI vous permet d'interagir efficacement avec le serveur API d'ArgoCD.

Commandes d'Installation

Utilisez les commandes suivantes pour installer ArgoCD :

# Déployer ArgoCD en utilisant le manifeste Kubernetes
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Ajouter le dépôt Helm pour ArgoCD
helm repo add argo https://argoproj.github.io/argo-helm

# Installer ArgoCD en utilisant Helm (version non-HA)
helm install my-argo-cd argo/argo-cd --version 4.8.0

# Télécharger le dernier CLI ArgoCD
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64

# Définir les permissions d'exécution pour le CLI
chmod +x /usr/local/bin/argocd

Étapes Suivantes

Dans les prochains labs pratiques, vous allez configurer le CLI, vous connecter et interagir avec le serveur API d'ArgoCD via ces commandes.

---

---

---

---

Argo CD Intermediate

Configuration déclarative

Dans ce guide, nous démontrons comment configurer des ressources Kubernetes de manière déclarative à l’aide d’un exemple d’application Mono. La gestion déclarative consiste à définir les ressources Kubernetes (telles que les Deployments, Services, Secrets et ConfigMaps) et les objets ArgoCD (y compris Applications, Repositories et Projects) dans des fichiers de manifeste. Ces fichiers peuvent être appliqués à l’aide de l’interface en ligne de commande kubectl pour garantir que l'état souhaité soit maintenu.

Auparavant, nous avons créé des applications ArgoCD à l’aide de l'interface en ligne de commande (CLI) et de l'interface utilisateur (UI), en fournissant de manière interactive la source et la destination. En revanche, cette approche utilise des fichiers de manifeste déclaratifs pour définir et gérer ces applications de manière systématique.

Pourquoi utiliser la configuration déclarative ?

Définir votre infrastructure sous forme de code dans Git offre une traçabilité claire, un contrôle de version et simplifie la gestion des changements à travers différents environnements.

Structure du dépôt Git

Supposons que vous ayez un dépôt Git avec la structure ci-dessous. Le dépôt contient un répertoire appelé "declarative" avec deux sous-répertoires : "manifests" et "mono-app".

Structure du dépôt Git :
└── declarative
    ├── manifests
    │   ├── geocentric-model
    │   │   ├── deployment.yml
    │   │   └── service.yml
    └── mono-app
        └── geocentric-app.yml

Dans le répertoire "mono-app", vous trouverez un fichier YAML d’application ArgoCD. Ce fichier définit l’application en spécifiant :

• Project Name: Le projet dans ArgoCD.
• Source Configuration: Inclut l'URL du dépôt Git, la révision (par exemple, HEAD), et le chemin pointant vers les manifestes Kubernetes souhaités (c’est-à-dire le répertoire "geocentric-model" dans "declarative/manifests"). Ce répertoire contient deux fichiers YAML : un pour le Deployment et un pour le Service.
• Destination Configuration: Spécifie le cluster cible (en utilisant l'URL du cluster local) et le namespace où les ressources seront déployées.
• Sync Policy: Une politique optionnelle qui peut automatiser le processus de synchronisation et d'auto-réparation.

Création de l'application

Une fois que vous avez défini votre manifeste, créez l’application en exécutant la commande suivante :

$ kubectl apply -f mono-app/geocentric-app.yml  
application.argoproj.io/geocentric-model-app created  

Après la création de l'application, ArgoCD va récupérer les manifestes de Deployment et de Service depuis le dépôt Git. Il créera ensuite les ressources sur le cluster cible, soit manuellement via une opération de synchronisation, soit automatiquement si la synchronisation est configurée.

Avantage

En gérant à la fois la définition de votre application et ses ressources correspondantes dans le contrôle de version, vous pouvez facilement suivre les changements et maintenir un état cohérent entre vos environnements.

Exemple de manifeste d'application ArgoCD

Voici un exemple de manifeste d'application ArgoCD qui encapsule cette configuration déclarative :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: geocentric-model-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/sidd-harth/test-cd.git
    targetRevision: HEAD
    path: ./declarative/manifests/geocentric-model
  destination:
    server: https://kubernetes.default.svc
    namespace: geocentric-model
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      selfHeal: true

Ce manifeste définit l’application en spécifiant tous les détails nécessaires, y compris le dépôt, la révision, et les chemins des ressources. Il configure également des options de synchronisation automatisée, garantissant que votre application correspond en permanence à l'état souhaité défini dans Git.

Utiliser une approche déclarative avec Git comme source unique de vérité garantit que les changements d’infrastructure sont versionnés, audités et facilement annulés si nécessaire. Pour plus de lecture sur les meilleures pratiques Kubernetes et ArgoCD, consultez la Documentation Kubernetes et la Documentation ArgoCD.

---

Configuration déclarative de l’application Mono

Dans cette leçon, vous apprendrez comment gérer une application ArgoCD unique de manière déclarative. Contrairement aux approches précédentes qui utilisaient l'interface en ligne de commande (CLI) ou l'interface utilisateur (UI) d'ArgoCD, cette méthode consiste à stocker et gérer les manifestes d'application ArgoCD dans un dépôt Git, tout comme pour tout autre manifeste de déploiement ou de service Kubernetes.

L’image montre une interface web pour configurer une application dans ArgoCD, avec des options pour définir le nom de l'application, le nom du projet, la politique de synchronisation et d’autres paramètres. La barre latérale gauche affiche les indicateurs d'état de synchronisation et de santé.

Dans l'UI ArgoCD, vous définissez les métadonnées de l'application, les détails de la source et de la destination. En coulisse, cela crée une spécification YAML qui décrit l’application. Voici un exemple de manifeste :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sample-app
spec:
  destination:
    namespace: sample
    server: https://kubernetes.default.svc
  source:
    path: ./sample
    repoURL: http://139.59.21.103:3000/siddhanth/gitops-argocd
    targetRevision: HEAD
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Note

ArgoCD peut créer et gérer des applications automatiquement en utilisant des spécifications YAML stockées dans des dépôts Git.

Créer une application ArgoCD déclarative

Pour configurer une application ArgoCD unique en utilisant l’approche déclarative, suivez ces étapes :

• 1. Localiser le répertoire du dépôt
  Dans votre dépôt GitOps ArgoCD, trouvez le répertoire "MonoApplication". Dans cet exemple, le manifeste de l'application est stocké dans le répertoire "mono-app". Vous devriez y voir un fichier nommé geocentric-app.yml.

L’image montre une interface de dépôt Gitea avec des détails sur les branches, les commits et les changements récents. Elle comprend des options pour créer un fichier, télécharger un fichier ou appliquer un patch.

• 2. Vérifier le manifeste YAML
  Voici un extrait du fichier geocentric-app.yml qui définit l'application ArgoCD. Cet exemple inclut des champs essentiels tels que le type, la version API, le projet et les détails de la source :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: geocentric-model-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
    targetRevision: HEAD
    path: ./declarative/manifests/geocentric-model
  destination:
    server: https://kubernetes.default.svc
    namespace: geocentric-model
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

Ce manifeste indique à ArgoCD de récupérer les manifestes de l'application depuis le répertoire spécifié, de les déployer dans le namespace geocentric-model, et d'activer la synchronisation automatisée avec des options de nettoyage (pruning) et d'auto-réparation (self-healing).

Tip

Les extraits YAML dupliqués ont été consolidés pour plus de clarté. Utilisez le même manifeste pour garantir la cohérence des déploiements.

• 3. Déployer l’application avec kubectl

Suivez ces étapes pour récupérer le dépôt dans votre cluster Kubernetes et créer l'application :

Clonez le dépôt et naviguez jusqu’au dossier mono-app :

mkdir demo
cd demo/
git clone http://139.59.21.103:3000/siddharth/gitops-argocd
cd gitops-argocd/
ll

Naviguez vers le répertoire declarative/mono-app/ et confirmez le contenu du fichier geocentric-app.yml :

cd declarative/mono-app/
cat geocentric-app.yml

Appliquez le manifeste dans le namespace argocd avec la commande suivante :

kubectl -n argocd apply -f geocentric-app.yml

Une fois appliqué, vous devriez voir la sortie suivante, indiquant un succès :

application.argoproj.io/geocentric-model-app created

• 4. Vérifier le déploiement de l’application

Confirmez l'état de l'application en utilisant à la fois la CLI ArgoCD et les commandes kubectl :

Listez les applications avec ArgoCD :

argocd app list

Cela affichera la liste des applications, y compris geocentric-model-app.

Vous pouvez également vérifier son état avec :

kubectl -n argocd get applications

Avec la synchronisation automatisée activée, ArgoCD mettra à jour automatiquement l'application. Vérifiez l'UI ArgoCD pour confirmer que les ressources de déploiement et de service sont correctement déployées.

Exposer l'application

Accédez à l'application déployée via le service exposé en NodePort. Par exemple, si le service est exposé sur le port 30682, vous pouvez utiliser ce port pour accéder à l'UI de l'application. Voici un exemple de manifeste de service :

apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","kind":"Service","metadata":{},"labels":{"app.kubernetes.io/instance":"geocentric-model-app"},"name":"geocentric-model-svc","namespace":"geocentric-model"}
  creationTimestamp: '2022-09-23T17:52:34Z'
  labels:
    app.kubernetes.io/instance: geocentric-model-app
  name: geocentric-model-svc
  namespace: geocentric-model
spec:
  clusterIP: 10.111.125.181
  ports:
    - nodePort: 38684
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: geocentric-model
  type: NodePort

Warning

Assurez-vous que le fichier geocentric-app.yml est créé dans le namespace ArgoCD pour éviter tout problème de déploiement.

Résumé

Dans ce guide, vous avez appris à gérer une application ArgoCD unique de manière déclarative en :

• Stockant le manifeste YAML dans un dépôt Git.
• Déployant l'application à l'aide de kubectl.
• Vérifiant l'état de l'application via la CLI et l'UI ArgoCD.

Cette approche déclarative simplifie la gestion des applications en intégrant les principes GitOps, garantissant que le déploiement de votre application soit reproductible et contrôlé en version.

---

App of Apps

Dans cet article, nous explorons le modèle "App-of-Apps" dans ArgoCD—une approche déclarative qui simplifie la création et la gestion des applications ArgoCD. Plutôt que de déployer manuellement chaque application, ce modèle génère et gère de manière programmatique plusieurs applications ArgoCD à partir d'une seule configuration racine.

L'idée principale est de créer une application racine ArgoCD dont la source pointe vers un dossier contenant des fichiers de définition YAML pour chaque microservice ou application. Chaque fichier YAML spécifie un chemin vers un répertoire contenant les manifestes Kubernetes associés. Une fois tous ces fichiers de configuration commis dans un dépôt Git, ArgoCD détecte automatiquement et déploie les applications définies.

Comment cela fonctionne

L'application racine agit en tant qu'orchestre. Elle indique à ArgoCD de parcourir le répertoire spécifié, en lisant chaque fichier YAML pour instancier les applications associées. Cela garantit que les mises à jour dans votre dépôt Git déclenchent une synchronisation automatique avec votre cluster Kubernetes.

Exemple de structure du dépôt

Supposons que votre dépôt Git soit organisé de sorte que chaque répertoire contienne les fichiers nécessaires pour une application spécifique. L'exemple suivant examine le fichier YAML de l'application racine ArgoCD, qui est placé dans un répertoire multi-applications. Cette application racine pointe vers le répertoire app-of-apps, incitant ArgoCD à créer toutes les applications enfants définies dans ce dossier.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
spec:
  project: default
  source:
    repoURL: https://github.com/sidd-harth/test-cd.git
    targetRevision: HEAD
    path: ./declarative/app-of-apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Dans cet exemple, trois fichiers YAML d'application ArgoCD sont définis dans le répertoire spécifié. ArgoCD lit ces définitions et crée automatiquement les applications correspondantes.

Examen détaillé : Fichier YAML de l'application Circle

Voyons maintenant le fichier YAML de l’application Circle App en tant qu'exemple. Chaque fichier YAML d'application comprend un champ source qui fait référence à son répertoire de manifeste spécifique. Dans l'exemple de Circle App, ArgoCD utilise les détails fournis pour créer ou mettre à jour le déploiement et le service dans le cluster Kubernetes.

# declarative/app-of-apps/app-of-apps.yml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/sidd-harth/test-cd.git
    targetRevision: HEAD
    path: ./declarative/app-of-apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

# declarative/app-of-apps/circle-app.yml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: circle-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/sidd-harth/test-cd.git
    targetRevision: HEAD
    path: ./declarative/manifests/circle
  destination:
    server: https://kubernetes.default.svc
    namespace: circle
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

En utilisant ce modèle, ArgoCD crée automatiquement toutes les applications listées et déploie leurs manifestes Kubernetes associés. Cette approche peut être étendue pour gérer n'importe quel objet Kubernetes—y compris ArgoCD lui-même. Chaque fois qu'une définition d'application est mise à jour ou qu'une nouvelle application est ajoutée dans votre dépôt Git, ArgoCD garantit que vos déploiements restent synchronisés en mettant à jour ou en créant automatiquement les applications correspondantes.

Avantages du modèle App-of-Apps

Avantage	Description
Contrôle centralisé	Gérer plusieurs applications à partir d'une seule application ArgoCD.
Synchronisation automatisée	Détecter et déployer automatiquement les changements de votre dépôt Git vers votre cluster Kubernetes.
Gestion évolutive	Ajouter ou mettre à jour des applications facilement sans intervention manuelle sur chaque déploiement.

Résumé

Le modèle App-of-Apps dans ArgoCD permet de gérer plusieurs applications de manière déclarative et automatisée à partir d'une application racine. Ce modèle facilite la gestion de déploiements complexes tout en améliorant l'efficacité opérationnelle, ce qui en fait un outil essentiel dans les workflows modernes basés sur GitOps.

Pour plus d’informations sur Kubernetes et les modèles de déploiement déclaratifs, vous pouvez consulter les ressources suivantes :

L'utilisation du modèle App-of-Apps simplifie les déploiements complexes et améliore l'efficacité des opérations, en garantissant que chaque modification dans votre dépôt Git se reflète instantanément dans vos déploiements Kubernetes.

---

Configuration déclarative avec l'App of Apps

Dans cette leçon, vous apprendrez à étendre l'approche déclarative des applications ArgoCD en déployant plusieurs applications à l'aide du modèle "app-of-apps". Ce modèle permet à une seule application ArgoCD de gérer d'autres applications ArgoCD, simplifiant ainsi le déploiement et la gestion de plusieurs services.

La structure du dépôt pour cette configuration organise plusieurs configurations ArgoCD dans des répertoires distincts, chacun contenant les fichiers manifestes pour des applications individuelles.

Application ArgoCD multi-applications

L'application principale multi-applications pointe vers le dépôt Git et spécifie le chemin contenant les manifestes qui gèrent d'autres applications ArgoCD. Sa définition est la suivante :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
    targetRevision: HEAD
    path: ./declarative/multi-app
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Note

La configuration multi-app récupère les manifestes à partir d'un répertoire spécifique, offrant ainsi une configuration centralisée pour gérer les applications imbriquées.

Configuration de l'App of Apps

L'application principale fait référence au répertoire app-of-apps, où plusieurs manifestes d'applications ArgoCD résident. La configuration pour l'App of Apps est la suivante :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
    targetRevision: HEAD
    path: ./declarative/app-of-apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Dans le répertoire declarative/app-of-apps, vous trouverez trois manifestes d'applications ArgoCD :

• Heliocentric App : récupère les manifestes Kubernetes à partir d'un chemin spécifique.
• Geocentric App : pointe vers un autre chemin de manifeste.
• Applications supplémentaires : vous pouvez ajouter d'autres sous-applications pour étendre encore les capacités de déploiement.

Manifeste de l'application Heliocentric

Voici l'exemple du manifeste pour l'application Heliocentric :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: heliocentric-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
    targetRevision: HEAD
    path: ./declarative/manifests/heliocentric-model
  destination:
    server: https://kubernetes.default.svc
    namespace: heliocentric
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

Manifeste de l'application Geocentric

Le manifeste de l'application Geocentric est configuré de manière similaire :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: geocentric-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
    targetRevision: HEAD
    path: ./declarative/manifests/geocentric-model
  destination:
    server: https://kubernetes.default.svc
    namespace: geocentric
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

Manifestes Kubernetes des applications

Au-delà des manifestes d'applications ArgoCD, le répertoire déclaratif contient également des manifestes Kubernetes séparés pour chaque application, notamment des déploiements et des services. Lorsque vous créez l'application App-of-Apps ArgoCD principale, elle déclenche automatiquement la création de trois autres applications ArgoCD.

Par exemple, une version alternative du manifeste app-of-apps avec un namespace de destination différent pourrait être définie comme suit :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
    targetRevision: HEAD
    path: ./declarative/app-of-apps
  destination:
    server: https://kubernetes.default.svc
    namespace: kubernetes
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Chaque application imbriquée déploie ensuite ses ressources Kubernetes respectives en fonction de son propre manifeste.

Processus de déploiement

Pour déployer des applications à l'aide du modèle App-of-Apps, suivez ces étapes :

1. Supprimez toute application Geocentric model précédemment déployée si elle existe, car elle sera recréée sous le nouveau modèle de gestion.
2. Naviguez vers le répertoire multi-app, qui contient le fichier app-of-apps.yml.
3. Appliquez le manifeste dans le namespace argocd en exécutant :

cd multi-app/
ll
# Assurez-vous que le fichier app-of-apps.yml est présent ici.
kubectl -n argocd apply -f app-of-apps.yml

Après le déploiement, l'interface ArgoCD affichera plusieurs applications :

• app-of-apps (gérant les applications imbriquées)
• geocentric-app
• heliocentric-app
• heliocentric-app sans Pluto (une variante alternative)

Conseil de déploiement

Assurez-vous qu'aucune ancienne configuration n'interfère avec le nouveau déploiement en supprimant les applications obsolètes avant d'appliquer le nouveau manifeste.

Affichage des applications dans l'interface ArgoCD

Dans le tableau de bord ArgoCD, cliquez sur n'importe quelle sous-application (par exemple, geocentric-app ou heliocentric-app) pour afficher des informations détaillées sur le manifeste. Voici un extrait de manifeste pour une application en cours de synchronisation :

status:
  health:
    status: Healthy
  history:
    deployStartDate: '2022-09-23T20:05:21Z'
    deployEndDate: '2022-09-23T20:05:24Z'
    revision: e2edb3a016b752028c38adb898d34114c1ec6
    path: ./declarative/manifests/heliocentric-model
    repoURL: http://165.22.209.118:3000/siddharth/gitops-argocd.git
  operationState:
    finishedAt: '2022-09-23T20:05:24Z'
    message: successfully synced (all tasks run)
    initiatedBy:
      automated: true
    retry:
      limit: 5
    sync:
      prune: true
      revision: e2edb3a016b752028c38adb898d34114c1ec6
      syncOptions:
        - CreateNamespace=true
    phase: Succeeded
    startedAt: '2022-09-23T20:05:21Z'
    syncResult:
      resources:
        - group: 
            hookPhase: Succeeded
            kind: Namespace
            message: namespace/heliocentric created
            namespace: heliocentric
            status: Synced
            syncPhase: PreSync
            version: v1
        - group: 
            hookPhase: Running
            kind: Service
            message: service/heliocentric-model-svc created
            name: heliocentric-model-svc
            namespace: heliocentric
            status: Sync

Accéder aux applications Kubernetes déployées

Chaque sous-application déploie son propre ensemble de ressources Kubernetes, y compris des services qui exposent les applications. Voici les détails de configuration pour ces services :

Service du modèle Geocentric :

apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"geocentric-app"},"name":"geocentric-model-svc","namespace":"geocentric"}}
  labels:
    app.kubernetes.io/instance: geocentric-app
  name: geocentric-model-svc

Service du modèle Heliocentric (avec NodePort) :

apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"heliocentric-app"},"name":"heliocentric-model-svc","namespace":"heliocentric"},"spec":{"clusterIP":"10.183.221.139","clusterIPs":["10.183.221.139"],"externalTrafficPolicy":"Cluster","internalTrafficPolicy":"Cluster","ipFamilies":["IPv4"],"ipFamilyPolicy":"SingleStack","ports":[{"nodePort":31334,"port":80,"protocol":"TCP","targetPort":80}],"selector":{"app":"heliocentric-model"},"sessionAffinity":"None","type":"NodePort"}}
spec:
  clusterIP: 10.183.221.139
  clusterIPs:
    - 10.183.221.139
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  ports:
    - nodePort: 31334
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: heliocentric-model
  sessionAffinity: None
  type: NodePort
  loadBalancer: {}

Service du modèle Heliocentric (sans Pluto) :

apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"heliocentric-model-no-pluto-app"},"name":"heliocentric-model-no-pluto-svc","resourceVersion":"1964046","uid":"73603805-36c2-4296-bd9c-2f14cac42080"}}
spec:
  clusterIP: 10.180.97.241
  externalIPs:
    - 10.180.97.241
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamily:
    - IPv4
  ipFamilyPolicy: SingleStack
  ports:
    - name: nodePort
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: heliocentric-model-no-pluto
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

Fun

Beaucoup d’utilisateurs considèrent que Pluto ne devrait pas être classé comme une planète en raison de son orbite distante et de sa rotation rétrograde, ce qui explique pourquoi une variante d’application excluant Pluto est fournie.

Toutes ces applications sont déployées à l'aide d'une seule configuration ArgoCD App-of-Apps. Ce modèle simplifie non seulement la gestion, mais permet également un contrôle centralisé sur plusieurs applications à partir d'un seul dépôt Git et instance ArgoCD.

---

Déployer des applications avec un Helm Chart

Dans cet article, nous explorons comment ArgoCD déploie et gère des applications en utilisant des Helm Charts, simplifiant ainsi la gestion de Kubernetes et adoptant les principes de GitOps.

Helm est le gestionnaire de paquets pour Kubernetes qui simplifie l'installation et la gestion du cycle de vie des applications en utilisant des collections de fichiers de configuration YAML, appelées Helm Charts. Ces Charts regroupent les définitions YAML nécessaires au déploiement d'un ensemble de ressources Kubernetes. Avec les définitions d'applications déclaratives comme principe fondamental de GitOps, les Helm Charts peuvent être stockés dans des dépôts spécialement conçus pour les empaqueter et les distribuer.

ArgoCD améliore ce processus en déployant des Helm Charts empaquetés, en les surveillant pour des mises à jour, et en gérant leur cycle de vie après leur déploiement. Par exemple, si vous avez un dépôt Git structuré avec un Helm Chart, l'interface en ligne de commande (CLI) d'ArgoCD peut être utilisée pour créer une application qui le déploie. En spécifiant l'URL du dépôt, le chemin vers le chart, et les valeurs de remplacement via l'option Helm Set, vous obtenez un processus de déploiement flexible et continu.

ArgoCD est polyvalent et prend en charge le déploiement à partir de diverses sources :

• Artifactory Hub
• Bitnami Helm Charts

De plus, vous pouvez déployer un Helm Chart en utilisant l'interface utilisateur (UI) d'ArgoCD. L'UI simplifie la connexion aux dépôts en prenant en charge les intégrations SSH, HTTPS ou GitHub App. Elle permet également de configurer les détails du dépôt, tels que le nom, le type, l'URL, et les informations d'identification pour accéder aux dépôts privés.

Note

Une fois qu'ArgoCD déploie une application en utilisant un Helm Chart, la gestion est entièrement transférée à ArgoCD. Par conséquent, l'exécution de la commande helm ls ne permettra pas d'afficher le release déployé, car il n'est plus géré par Helm.

Voici un exemple montrant comment créer deux applications ArgoCD :

1. Une qui déploie un Helm Chart depuis un dépôt Git.
2. Une autre qui déploie le Helm Chart Nginx depuis le dépôt Bitnami.

Après le déploiement, la commande helm ls confirme que les applications sont entièrement gérées par ArgoCD.

$ argocd app create random-shapes \
  --repo https://github.com/sidd-harth/test-cd.git \
  --path helm-chart \
  --helm-set replicaCount=2 \
  --helm-set color.circle=pink \
  --helm-set color.square=violet \
  --helm-set service.type=NodePort \
  --dest-namespace default \
  --dest-server https://kubernetes.default.svc
application 'random-shapes' created

$ argocd app create nginx \
  --repo https://charts.bitnami.com/bitnami \
  --helm-chart nginx \
  --revision 12.0.3 \
  --values-literal-file values.yaml \
  --dest-namespace default \
  --dest-server https://kubernetes.default.svc
application 'nginx' created

$ helm ls
NAME   NAMESPACE REVISION UPDATED STATUS CHART APP VERSION

Cet exemple illustre clairement les points suivants :

• Comment créer des applications ArgoCD en utilisant la CLI.
• Comment configurer les paramètres d'un Helm Chart lors du déploiement.
• Comment vérifier qu'après le déploiement, la gestion est assurée par ArgoCD et non par Helm.

Principaux Ressources et Références

Composant	Description	Commande Exemple / Lien
ArgoCD CLI	Utilisé pour créer et gérer les applications ArgoCD	Exemples de commande argocd app create ci-dessus
Helm Package	Simplifie l'installation et la gestion des applications Kubernetes	Documentation Helm
Principe GitOps	Configuration déclarative et automatisation du déploiement des applications	GitOps Kubernetes

Warning

Assurez-vous que vous avez les bonnes autorisations d'accès et que vos informations d'identification sont correctement configurées lorsque vous vous connectez à des dépôts privés. Une mauvaise configuration peut entraîner des échecs de déploiement.

---

Déploiement d'applications multi-clusters

ArgoCD simplifie la gestion des déploiements multi-clusters en permettant de déployer des applications soit dans son propre cluster, soit sur des clusters externes. Dans ce guide, nous vous expliquerons comment configurer un cluster Kubernetes externe et déployer des applications sur plusieurs clusters à l’aide d'ArgoCD.

Vue d'ensemble

Avant de déployer des applications sur plusieurs clusters, vous devez disposer d'un cluster Kubernetes externe. ArgoCD intègre des clusters externes en lisant leurs détails d'identification depuis le fichier kubeconfig. Cela permet à ArgoCD de gérer les déploiements en dehors de son propre cluster.

Configuration du Cluster Externe

Commencez par mettre à jour votre fichier kubeconfig pour enregistrer votre cluster externe. Utilisez les commandes suivantes pour définir la configuration du cluster et des identifiants :

$ kubectl config set-cluster prod --server=https://1.2.3.4 --certificate-authority=prod.crt
Cluster "prod" set.

$ kubectl config set-credentials admin --client-certificate=admin.crt --client-key=admin.key
User "admin" set.

Après avoir défini le cluster externe dans votre kubeconfig, ajoutez-le à ArgoCD en référencant le nom de contexte approprié :

$ argocd cluster add <context-name>

Avertissement

Cette commande crée un compte de service sur le cluster externe avec un accès complet au niveau du cluster. Assurez-vous de comprendre les implications de sécurité avant de procéder.

Une fois que vous confirmez, ArgoCD crée automatiquement le compte de service, le rôle de cluster, et l'association du rôle de cluster, validant ainsi le cluster externe comme cible de déploiement.

Exemple détaillé

Voici un exemple complet illustrant toutes les étapes essentielles pour ajouter un cluster externe :

$ kubectl config set-cluster prod --server=https://1.2.3.4 --certificate-authority=prod.crt
Cluster "prod" set.

$ kubectl config set-credentials admin --client-certificate=admin.crt --client-key=admin.key
User "admin" set.

$ kubectl config set-context admin-prod --cluster=prod --user=admin --namespace=prod-app
Context "admin-prod" set.

$ argocd cluster add admin-prod
WARNING: This will create a service account `argocd-manager` on the cluster referenced by context `admin-prod` with full cluster level admin privileges. Do you want to continue [y/N]? y
INFO[0011] ServiceAccount "argocd-manager" created in namespace "kube-system"
INFO[0011] ClusterRole "argocd-manager-role" created
INFO[0011] ClusterRoleBinding "argocd-manager-role-binding" created
Cluster 'https://1.2.3.4' added

$ argocd cluster list
SERVER                                  NAME         VERSION  STATUS      MESSAGE   PROJECT
https://1.2.3.4                         admin-prod   1.21     Successful            <none>
https://kubernetes.default.svc          in-cluster   1.20     Successful            <none>

Vous pouvez vérifier la liste des clusters disponibles pour le déploiement en exécutant la commande argocd cluster list. Notez que les identifiants pour les clusters externes (ou serveurs API) sont stockés de manière sécurisée en tant que secrets dans le namespace ArgoCD.

---

ArgoCD AdvancedAdmin

Gestion des utilisateurs RBAC dans ArgoCD

Dans cette leçon, nous explorons comment ArgoCD met en œuvre le contrôle d'accès basé sur les rôles (RBAC) pour gérer l'accès à ses ressources de manière efficace. ArgoCD utilise des politiques définies en notation CSV, qui sont appliquées soit à des utilisateurs individuels, soit à des groupes SSO. Il est important de noter que les permissions RBAC pour les applications peuvent différer de celles appliquées à d'autres types de ressources.

Comment fonctionne le RBAC dans ArgoCD

Au cœur de la politique RBAC dans ArgoCD, on retrouve quatre composants :

• Rôle: Un ensemble de permissions.
• Ressource: La ressource cible, comme les clusters, les certificats, les applications, les dépôts ou les journaux.
• Action: L'opération autorisée (par exemple, obtenir, créer, mettre à jour, supprimer, synchroniser, ou remplacer).
• Projet/Objet: Pour les objets d'application, le chemin de la ressource est exprimé par le nom du projet suivi d'un slash et du nom de l'application.

Note

Les politiques RBAC personnalisées permettent un contrôle granulaire sur qui peut effectuer des actions spécifiques, garantissant que seuls les utilisateurs autorisés ont accès aux ressources sensibles.

Exemple : Création d'un rôle "Créer un cluster" personnalisé

L'exemple suivant montre comment configurer un rôle personnalisé nommé createCluster qui permet à un utilisateur de créer des clusters dans ArgoCD. Dans ce scénario, le rôle est attribué à un utilisateur nommé jai en patchant la configmap RBAC d'ArgoCD avec la politique appropriée.

$ kubectl -n argocd patch configmap argocd-rbac-cm \
--patch='{"data":{"policy.csv":"p, role:create-cluster, clusters, create, *, jai, role:create-cluster"}}'
configmap/argocd-rbac-cm patched

Dans cette configuration, le rôle createCluster est attribué à l'utilisateur jai, lui permettant de créer des clusters. Vous pouvez vérifier les permissions avec la commande argocd account can-i :

• Vérifier si jai peut créer des clusters renvoie "oui".
• Tenter de supprimer un cluster renvoie "non" car le rôle createCluster ne comprend pas la permission de suppression.

Exemple : Attribution d'un rôle au niveau du projet

Les rôles peuvent également être attribués au niveau du projet. Considérons un rôle personnalisé nommé kia-admins, qui accorde des droits de modification illimités pour toute application au sein du projet kia-project. Ce rôle est attribué à un utilisateur nommé ali. Lorsque ali tente de synchroniser les applications dans le projet kia-project, le système confirme les permissions avec une réponse "oui".

$ kubectl -n argocd patch configmap argocd-rbac-cm \
--patch='{"data":{"policy.csv":"p, role:create-cluster, clusters, create, *, jai, role:create-cluster"}}'
configmap/argocd-rbac-cm patched

$ argocd account can-i create clusters '*'
yes # Logged in as - jai

$ kubectl -n argocd patch configmap argocd-rbac-cm \
--patch='{"data":{"policy.csv":"p, role:kia-admins, applications, *, kia-project/*, allow, ali, role:kia-admins"}}'
configmap/argocd-rbac-cm patched

$ argocd account can-i delete clusters '*'
no # Logged in as - jai

$ argocd account can-i sync applications kia-project/*
yes # Logged in as - ali

Warning

Bien que l'utilisateur ali ait reçu des permissions au sein du projet kia-project, il n'est pas autorisé à synchroniser des applications dans d'autres projets.

Conclusion

Cette leçon a fourni un aperçu de la manière de configurer le RBAC dans ArgoCD pour garantir que seuls les utilisateurs correctement autorisés puissent effectuer des actions spécifiques sur diverses ressources. En définissant soigneusement des politiques à l'aide de la notation CSV, vous pouvez gérer efficacement l'accès aux clusters, aux applications et à d'autres composants critiques dans ArgoCD.

---

Gestion des utilisateurs dans ArgoCD avec RBAC

Cet article explique comment gérer les utilisateurs dans ArgoCD, en se concentrant sur la gestion des utilisateurs locaux. Par défaut, ArgoCD inclut un utilisateur administrateur intégré avec un accès complet de super-utilisateur. Pour de meilleures pratiques de sécurité, il est recommandé d'utiliser le compte administrateur uniquement pour la configuration initiale, puis de le désactiver une fois que tous les utilisateurs nécessaires ont été ajoutés.

ArgoCD prend en charge deux types de comptes utilisateur :

• Utilisateurs locaux
• Utilisateurs authentifiés via Single Sign-On (SSO) (par exemple, via Okta ou des produits similaires)

Dans ce guide, nous nous concentrons sur la configuration des utilisateurs locaux.

Important

Il est recommandé de désactiver le compte administrateur par défaut après avoir configuré des comptes supplémentaires afin de minimiser les risques de sécurité.

Configuration des utilisateurs locaux

Les utilisateurs locaux dans ArgoCD sont gérés en mettant à jour le ConfigMap. Chaque utilisateur est défini avec des capacités associées, telles que la génération de clé API et l'accès à l'interface utilisateur. La capacité de clé API permet à un utilisateur de créer un JSON Web Token (JWT) pour les interactions API, tandis que la capacité de connexion permet l'accès à l'interface utilisateur.

Après avoir modifié le ConfigMap, votre liste d'utilisateurs pourrait ressembler à ceci :

$ argocd account list
NAME   ENABLED  CAPABILITIES
admin  true     login
jai    true     apiKey, login
ali    true     apiKey, login

Pour ajouter ou mettre à jour les comptes utilisateur, vous pouvez patcher le ConfigMap avec les commandes appropriées :

$ kubectl -n argocd patch configmap argocd-cm --patch='{"data":{"accounts.jai": "apiKey,login"}}'
configmap/argocd-cm patched

$ kubectl -n argocd patch configmap argocd-cm --patch='{"data":{"accounts.ali": "apiKey,login"}}'
configmap/argocd-cm patched

Mise à jour des mots de passe des utilisateurs

ArgoCD fournit des commandes CLI pour définir ou mettre à jour les mots de passe des utilisateurs. Lorsque vous êtes connecté en tant qu'administrateur, vous devez entrer le mot de passe actuel de l'administrateur pour changer le mot de passe d'un autre utilisateur. Notez que les nouveaux utilisateurs n'ont pas d'accès tant que leur mot de passe n'est pas configuré.

ArgoCD vient avec deux rôles prédéfinis :

• Lecture seule : Accorde aux utilisateurs un accès uniquement pour visualiser les ressources.
• Administrateur : Accorde aux utilisateurs un accès complet et illimité.

Par défaut, le compte administrateur se voit attribuer le rôle administrateur. Cependant, vous pouvez modifier cette attribution ou créer des rôles personnalisés en éditant le ConfigMap RBAC d'ArgoCD.

Par exemple, pour mettre à jour le mot de passe de l'utilisateur "jai", utilisez la commande suivante :

$ argocd account update-password --account jai
*** Entrez le mot de passe de l'utilisateur actuellement connecté (admin) :
*** Entrez le nouveau mot de passe pour l'utilisateur jai :
*** Confirmez le nouveau mot de passe pour l'utilisateur jai :
Mot de passe mis à jour

Alternativement, vous pouvez exécuter la mise à jour dans une seule commande :

$ argocd account update-password \
--account jai \
--new-password j€i_p@ssw0rd \
--current-password @dmin_p@$sword
Mot de passe mis à jour

Personnalisation des rôles

Le rôle lecture seule par défaut permet aux utilisateurs de visualiser toutes les ressources sans apporter de modifications. Pour attribuer des rôles personnalisés ou modifier les attributions de rôles, vous devez éditer le ConfigMap RBAC d'ArgoCD. En configurant ces paramètres, vous pouvez vous assurer que les utilisateurs sans mappages de rôles explicites se voient attribuer automatiquement un rôle lecture seule par défaut.

Pour une compréhension plus approfondie du contrôle d'accès basé sur les rôles (RBAC) dans ArgoCD et pour explorer des configurations détaillées, référez-vous à la documentation officielle d'ArgoCD.

Lectures supplémentaires

Pour plus d'informations sur la gestion sécurisée des utilisateurs et la configuration RBAC dans ArgoCD, explorez des ressources supplémentaires sur RBAC dans Kubernetes et les meilleures pratiques en matière de sécurité cloud-native.

---