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.

Création d'applications

Les applications représentent des déploiements dans des clusters cibles. Chaque application définit une source (dépôt Git) et une destination (cluster et espace de noms). Une fois appliqué, Argo CD créera les ressources spécifiées par des manifestes dans le référentiel Git dans l'espace de noms du cluster. Les applications spécifient souvent des déploiements de charges de travail, mais elles peuvent gérer toutes les ressources Kubernetes disponibles dans le cluster de destination.

Conditions préalables

Création d'une application de base

Définissez une application déployée à partir d'un dépôt Git :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps
    targetRevision: HEAD
    path: guestbook
  destination:
    name: in-cluster
    namespace: default

Appliquez l'application :

kubectl apply -f application.yaml

Afficher le statut de la demande :

kubectl get application guestbook -n argocd

Configuration de la source

Référentiel Git :

spec:
  source:
    repoURL: https://github.com/example/my-app
    targetRevision: main
    path: kubernetes/manifests

Tag ou commit Git spécifique :

spec:
  source:
    targetRevision: v1.2.0  # or commit SHA

Tableau du casque :

spec:
  source:
    repoURL: https://github.com/example/helm-charts
    targetRevision: main
    path: charts/my-app
    helm:
      valueFiles:
      - values.yaml
      parameters:
      - name: image.tag
        value: v1.2.0

Diagramme de Helm avec des valeurs provenant d'un dépôt Git externe (modèle multi-source) :

spec:
  sources:
  - repoURL: https://github.com/example/helm-charts
    targetRevision: main
    path: charts/my-app
    helm:
      valueFiles:
      - $values/environments/production/values.yaml
  - repoURL: https://github.com/example/config-repo
    targetRevision: main
    ref: values

Pour plus d'informations, consultez la section Fichiers Helm Value provenant d'un référentiel Git externe dans la documentation du CD Argo.

Tableau de bord de l'ECR :

spec:
  source:
    repoURL: oci://account-id.dkr.ecr.region.amazonaws.com/repository-name
    targetRevision: chart-version
    chart: chart-name
      

Si le rôle de capacité dispose des autorisations ECR requises, le référentiel est utilisé directement et aucune configuration de référentiel n'est requise. Consultez Configuration de l'accès au référentiel pour plus de détails.

Dépôt Git provenant de CodeCommit :

spec:
  source:
    repoURL: https://git-codecommit.region.amazonaws.com/v1/repos/repository-name
    targetRevision: main
    path: kubernetes/manifests

Si le rôle de capacité dispose des CodeCommit autorisations requises, le référentiel est utilisé directement et aucune configuration de référentiel n'est requise. Consultez Configuration de l'accès au référentiel pour plus de détails.

Dépôt Git provenant de CodeConnections :

spec:
  source:
    repoURL: https://codeconnections.region.amazonaws.com/git-http/account-id/region/connection-id/owner/repository.git
    targetRevision: main
    path: kubernetes/manifests

Le format de l'URL du référentiel est dérivé de l'ARN de CodeConnections connexion. Si le rôle de capacité dispose des CodeConnections autorisations requises et qu'une connexion est configurée, le référentiel est utilisé directement et aucune configuration de référentiel n'est requise. Consultez Configuration de l'accès au référentiel pour plus de détails.

Personnalisez :

spec:
  source:
    repoURL: https://github.com/example/kustomize-app
    targetRevision: main
    path: overlays/production
    kustomize:
      namePrefix: prod-

Politiques de synchronisation

Contrôlez la façon dont Argo CD synchronise les applications.

Synchronisation manuelle (par défaut) :

Les applications nécessitent une approbation manuelle pour être synchronisées :

spec:
  syncPolicy: {}  # No automated sync

Déclenchez manuellement la synchronisation :

kubectl patch application guestbook -n argocd \
  --type merge \
  --patch '{"operation": {"initiatedBy": {"username": "admin"}, "sync": {}}}'

Synchronisation automatique :

Les applications se synchronisent automatiquement lorsque des modifications de Git sont détectées :

spec:
  syncPolicy:
    automated: {}

Auto-guérison :

Annulez automatiquement les modifications manuelles apportées au cluster :

spec:
  syncPolicy:
    automated:
      selfHeal: true

Lorsqu'il est activé, Argo CD annule toutes les modifications manuelles apportées directement au cluster, garantissant ainsi que Git reste la source de vérité.

Élagage :

Supprimez automatiquement les ressources supprimées de Git :

spec:
  syncPolicy:
    automated:
      prune: true

Synchronisation automatique combinée :

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Réessayez la configuration :

Configurez le comportement des nouvelles tentatives en cas d'échec des synchronisations :

spec:
  syncPolicy:
    retry:
      limit: 5  # Number of failed sync attempts; unlimited if less than 0
      backoff:
        duration: 5s  # Amount to back off (default unit: seconds, also supports "2m", "1h")
        factor: 2  # Factor to multiply the base duration after each failed retry
        maxDuration: 3m  # Maximum amount of time allowed for the backoff strategy

Cela est particulièrement utile pour les ressources qui doivent d'abord CRDs être créées, ou lorsque vous travaillez avec des instances kro où le CRD n'est peut-être pas immédiatement disponible.

Options de synchronisation

Configuration de synchronisation supplémentaire :

Créez un espace de noms s'il n'existe pas :

spec:
  syncPolicy:
    syncOptions:
    - CreateNamespace=true

Ignorez le cycle à sec en cas de ressources manquantes :

Utile lors de l'application de ressources qui dépendent de celles CRDs qui n'existent pas encore (comme les instances Kro) :

spec:
  syncPolicy:
    syncOptions:
    - SkipDryRunOnMissingResource=true

Cela peut également être appliqué à des ressources spécifiques à l'aide d'une étiquette apposée sur la ressource elle-même.

Validez les ressources avant de les appliquer :

spec:
  syncPolicy:
    syncOptions:
    - Validate=true

Appliquer de manière désynchronisée uniquement :

spec:
  syncPolicy:
    syncOptions:
    - ApplyOutOfSyncOnly=true

Fonctionnalités de synchronisation avancées

Argo CD prend en charge les fonctionnalités de synchronisation avancées pour les déploiements complexes :

Pour plus de détails, consultez Sync Waves et Resource Hooks dans la documentation d'Argo CD.

Ignorer les différences

Empêchez Argo CD de synchroniser des champs spécifiques gérés par d'autres contrôleurs (comme la gestion des répliques par HPA) :

spec:
  ignoreDifferences:
  - group: apps
    kind: Deployment
    jsonPointers:
    - /spec/replicas

Pour plus de détails sur les modèles d'ignorance et les exclusions de champs, voir Diffing Customization dans la documentation d'Argo CD.

Déploiement dans plusieurs environnements

Déployez la même application dans plusieurs environnements :

Développement :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/my-app
    targetRevision: develop
    path: overlays/development
  destination:
    name: dev-cluster
    namespace: my-app

Produktion :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/my-app
    targetRevision: main
    path: overlays/production
  destination:
    name: prod-cluster
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Surveiller et gérer les applications

Afficher le statut de la demande :

kubectl get application my-app -n argocd

Accédez à l'interface utilisateur d'Argo CD :

Ouvrez l'interface utilisateur du CD Argo via la console EKS pour afficher la topologie de l'application, l'état de synchronisation, l'état des ressources et l'historique des déploiements. Consultez les instructions Travailler avec Argo CD d'accès à l'interface utilisateur.

Applications de rétrogradation :

Revenez à une version précédente à l'aide de l'interface utilisateur Argo CD, de l'Argo CD CLI, ou targetRevision en mettant à jour la spécification de l'application avec un commit ou une balise Git précédent.

À l'aide de l'Argo CD CLI :

argocd app rollback argocd/my-app <revision-id>

Pour plus d'informations, consultez la section restauration de l'application argocd dans la documentation d'Argo CD.

Ressources supplémentaires