Spécification des workflows Argo

Explique le CRD Argo Workflows, la structure YAML, les types de templates, les templates de conteneurs, les méthodes de soumission et les bonnes pratiques pour créer des pipelines d’automatisation Kubernetes réutilisables.

Dans cette leçon, nous examinons la spécification des workflows Argo et comment créer des pipelines d’automatisation réutilisables en tant que ressources personnalisées Kubernetes.

Argo Workflows est implémenté sous forme de Custom Resource Definition (CRD) Kubernetes, ce qui permet de définir des pipelines CI/CD et d’automatisation complexes à l’aide de fichiers YAML familiers. Un workflow est une séquence structurée de tâches automatisées qui, ensemble, accomplissent un objectif — couramment utilisé en DevOps pour le déploiement, les tests et la promotion d’applications.

Composants clés d’un manifest Argo Workflow :¶

• Header : métadonnées Kubernetes (apiVersion, kind, metadata)
• spec : décrit le comportement du workflow et les templates qui exécutent le travail

Les sections suivantes expliquent la structure, les types de templates courants et comment soumettre un workflow.

Structure d’un fichier workflow¶

Un fichier YAML de workflow typique contient les parties principales suivantes :

• Header : apiVersion, kind et metadata
• Metadata : vous pouvez spécifier name ou generateName. Utilisez generateName pour éviter les collisions lorsque vous soumettez plusieurs fois le même manifest — Argo ajoute un suffixe unique.

• spec : le cœur du workflow. Champs importants :

• entrypoint : nom du template qui démarre l’exécution

• templates : liste de templates réutilisables. Les templates décrivent les tâches et peuvent se référencer entre eux

💡 Utilisez generateName lorsque vous souhaitez soumettre plusieurs fois le même workflow sans collision de noms. Chaque soumission recevra un suffixe unique.

Types de templates (aperçu)¶

Les templates sont les éléments de base des workflows. Argo prend en charge plusieurs types de templates selon les cas d’usage :

Les templates peuvent être composés — les templates steps ou dag référencent des templates container/script/resource pour exécuter les tâches.

Templates de conteneur¶

Les templates de type container acceptent les mêmes champs qu’un conteneur Kubernetes. Vous pouvez donc utiliser :

• image
• command et args
• env et envFrom
• volumeMounts et volumes
• resources

Comme ils reflètent Kubernetes, vous pouvez réutiliser vos connaissances YAML existantes.

Exemple :¶

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: cowsay-
spec:
  entrypoint: cowsay-template
  templates:
  - name: cowsay-template
    container:
      image: rancher/cowsay
      command: ["cowsay"]
      args: ["Argo Workflow!!!!"]

Soumettre un workflow¶

Vous pouvez soumettre des workflows via l’interface utilisateur Argo ou la CLI.

Exemple CLI (namespace argo) :¶

# soumettre workflow.yml dans le namespace 'argo'
argo submit -n argo workflow.yml

L’interface Argo est disponible si votre serveur Argo est exposé ; elle fournit une visualisation des templates, DAGs et étapes.

⚠️ Le champ entrypoint doit correspondre à l’un des noms de template définis dans templates. Sinon, le workflow ne démarrera pas.

Conseils pratiques et bonnes pratiques¶

• Utilisez generateName pour les soumissions récurrentes ou pilotées par CI
• Gardez les templates petits et réutilisables
• Composez des workflows complexes à partir de blocs simples (container, script, steps, dag)
• Utilisez resources et resourceLimits pour gérer les ressources
• Versionnez vos manifests avec votre code applicatif ou infra

Référence rapide : champs spec¶

Liens et références¶

• Documentation Argo Workflows
• Interface Argo Workflows
• Documentation CLI Argo
• Kubernetes CRDs
• Pods et conteneurs Kubernetes

Notes¶

• La section container correspond directement à un spec de conteneur Kubernetes et supporte env, volumeMounts et resources.
• Assurez-vous toujours que entrypoint correspond à un template existant.

Construit avec Mintlify.