Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Concepts d'Argo CD

Argo CD implémente Git GitOps en considérant Git comme la seule source fiable pour vos déploiements d'applications. Cette rubrique présente un exemple pratique, puis explique les concepts de base que vous devez comprendre lorsque vous travaillez avec l'EKS Capability for Argo CD.

Commencer à utiliser Argo CD

Après avoir créé la fonctionnalité Argo CD (voirCréation d’une fonctionnalité Argo CD), vous pouvez commencer à déployer des applications. Cet exemple décrit l'enregistrement d'un cluster et la création d'une application.

Étape 1 : Configurer

Enregistrez votre cluster (obligatoire)

Enregistrez le cluster dans lequel vous souhaitez déployer des applications. Dans cet exemple, nous allons enregistrer le même cluster sur lequel Argo CD est exécuté (vous pouvez utiliser le nom in-cluster pour des raisons de compatibilité avec la plupart des exemples d'Argo CD) :

# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.arn' \
  --output text)

# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
  --aws-cluster-name $CLUSTER_ARN \
  --name in-cluster \
  --project default

Vous pouvez également enregistrer le cluster à l'aide d'un secret Kubernetes (voir Enregistrer les clusters cibles pour plus de détails).

Configurer l'accès au référentiel (facultatif)

Cet exemple utilise un GitHub référentiel public, aucune configuration de référentiel n'est donc requise. Pour les référentiels privés, configurez l'accès à l'aide de AWS Secrets Manager ou de Kubernetes Secrets (voir Configuration de l'accès au référentiel pour plus de détails). CodeConnections

Pour les AWS services (ECR pour les graphiques Helm CodeConnections, et CodeCommit), vous pouvez les référencer directement dans les ressources de l'application sans créer de référentiel. Le rôle de capacité doit disposer des autorisations IAM requises. Consultez Configuration de l'accès au référentiel pour plus de détails.

Étape 2 : Créer une application

Créez ce manifeste d'application dans my-app.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    name: in-cluster
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Appliquez l'application :

kubectl apply -f my-app.yaml

Après avoir appliqué cette application, Argo CD : 1. Synchronise l'application de Git avec votre cluster (déploiement initial) 2. Surveille les modifications apportées au dépôt Git 3. Synchronise automatiquement les modifications ultérieures sur votre cluster 4. Détecte et corrige toute dérive par rapport à l'état souhaité 5. Fournit l'état de santé et l'historique de synchronisation dans l'interface utilisateur

Consultez le statut de la demande :

kubectl get application guestbook -n argocd

Vous pouvez également afficher l'application à l'aide de l'interface de ligne de commande Argo CD (argocd app get guestbook) ou de l'interface utilisateur du CD Argo (accessible depuis la console EKS sous l'onglet Capabilities de votre cluster).

Concepts de base

GitOps principes et types de sources

Argo CD implémente GitOps, où la source de votre application est la seule source fiable pour les déploiements :

Types de sources pris en charge :

Cette flexibilité permet aux entreprises de choisir les sources qui répondent à leurs exigences de sécurité et de conformité. Par exemple, les organisations qui limitent l'accès à Git depuis les clusters peuvent utiliser l'ECR pour les diagrammes Helm ou les images OCI.

Pour plus d'informations, consultez la section Sources d'applications dans la documentation Argo CD.

Synchronisation et réconciliation

Argo CD surveille en permanence vos sources et vos clusters afin de détecter et de corriger les différences :

Les ondes de synchronisation contrôlent l'ordre de création des ressources à l'aide d'annotations :

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"  # Default if not specified

Les ressources sont appliquées par ordre de vague (les nombres les plus bas d'abord, y compris les nombres négatifs comme-1). Cela vous permet de créer des dépendances telles que des espaces de noms (wave-1) avant les déploiements (wave0).

L'autoréparation annule automatiquement les modifications manuelles :

spec:
  syncPolicy:
    automated:
      selfHeal: true

Pour des informations détaillées sur les phases de synchronisation, les hooks et les modèles avancés, consultez la documentation de synchronisation Argo CD.

État de santé des applications

Argo CD surveille l'état de toutes les ressources de votre application :

État de santé :* Sain - Toutes les ressources fonctionnent comme prévu * Progression - Ressources en cours de création ou de mise à jour * Dégradée - Certaines ressources ne sont pas saines (pods tombent en panne, tâches échouent) * Suspendue - Application interrompue intentionnellement * Manquante - Les ressources définies dans Git ne sont pas présentes dans le cluster

Argo CD intègre des contrôles de santé pour les ressources Kubernetes courantes (déploiements, tâches StatefulSets, etc.) et prend en charge les contrôles de santé personnalisés pour. CRDs

L'état de santé de l'application est déterminé par toutes ses ressources. Si une ressource l'estDegraded, c'est bien l'application qui l'estDegraded.

Pour plus d'informations, consultez Resource Health dans la documentation d'Argo CD.

Modèles multi-clusters

Argo CD prend en charge deux modèles de déploiement principaux :

H ub-and-spoke - Exécutez Argo CD sur un cluster de gestion dédié qui se déploie sur plusieurs clusters de charge de travail :* Contrôle et visibilité centralisés * Politiques cohérentes sur tous les clusters * Une instance Argo CD à gérer * Séparation claire entre le plan de contrôle et les charges de travail

Par cluster : exécutez Argo CD sur chaque cluster, en gérant uniquement les applications de ce cluster :* Séparation des clusters (une défaillance n'affecte pas les autres) * Simplification du réseau (aucune communication entre clusters) * Configuration initiale plus facile (pas d'enregistrement du cluster)

Choisissez hub-and-spoke pour les équipes de plateforme qui gèrent de nombreux clusters, ou par cluster pour les équipes indépendantes ou lorsque les clusters doivent être complètement isolés.

Pour une configuration multicluster détaillée, voirConsidérations relatives à Argo CD.

Projets

Les projets fournissent un regroupement logique et un contrôle d'accès pour les applications :

Toutes les applications appartiennent à un projet. S'il n'est pas précisé, ils utilisent le default projet (qui n'est soumis à aucune restriction). Pour la production, créez des projets avec les restrictions appropriées.

Pour la configuration du projet et les modèles RBAC, voirConfigurer les autorisations d'Argo CD.

Organisation du référentiel

La plupart des équipes utilisent une organisation basée sur des annuaires avec des superpositions Kustomize ou des fichiers de valeurs Helm pour différents environnements :

my-app/
├── base/
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    ├── staging/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

Cette approche apporte flexibilité et clarté tout en conservant toutes les configurations d'environnement dans un référentiel unique.

Pour connaître les modèles de structure de référentiel détaillés et les meilleures pratiques, consultez la documentation des meilleures pratiques d'Argo CD.

Options de synchronisation

Ajustez le comportement de synchronisation à l'aide des options courantes :

spec:
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true

Pour une liste complète des options de synchronisation, consultez la documentation des options de synchronisation Argo CD.

Étapes suivantes