Skip to content

Template Types

Quote

A finir la partie template invocators

Vue d'ensemble des types de templates Argo Workflows, expliquant les définitions et invocators tels que Container, Script, Resource, Suspend, Plugin, Container Set, HTTP, Steps et DAG

Les templates peuvent être considérés comme des fonctions, ils définissent les instructions à exécuter. La spec d’un workflow inclut un champ entrypoint qui spécifie le template principal qui sera exécuté en premier.

Template Types

Il existe neuf types de templates au total, répartis en deux catégories:

  • Template Definitions
  • Template Invocators

Template Definitions

Ces templates définissent le travail à effectuer dans un workflow

Container

Le template container est le type de template le plus courant: Il permet de scheduler un container Kubernetes avec une spec identique à celle d'un pod (image, command, args, env, resources, volumeMounts, etc.).

Tout ce qui est affiché via stdout, par exemple avec echo ou print est automatiquement récupérée par Argo Workflow et stockée dans une variable réutilisable {{tasks.<NAME>.outputs.result}} ou {{steps.<NAME>.outputs.result}}, selon son mode d’appel.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-  # Name of this Workflow
spec:
  entrypoint: hello-world     # Defines "hello-world" as the "main" template
  templates:
  - name: hello-world         # Defines the "hello-world" template
    container:
      image: busybox
      command: [echo]
      args: ["hello world"]   # This template runs "echo" in the "busybox" image with arguments "hello world"

Script

Le template script est un wrapper qui exécute un container. Il utilise les champs image et command comme le template container, mais permet d’écrire un script inline avec le champ source. Argo Workflows crée le container, place le script dans un fichier et l’exécute. La sortie du script est capturée depuis le stdout et est disponible comme variable dans le workflow Argo, exactement comme avec le template container.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: random-number-
spec:
  entrypoint: random-number
  templates:
  - name: random-number
    script:
      image: python:alpine3.23
      command: [python]
      source: |
        import random
        i = random.randint(1, 100)
        print(i)

Resource

Le template resource sert à gérer directement des resources Kubernetes (create, apply, delete, replace, patch, get) depuis Argo workflow. Le manifeste à gérer est fourni inline dans le champ manifest.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: k8s-resource-
spec:
  entrypoint: k8s-resource
  templates:
  - name: k8s-resource
    resource:
      action: create
      manifest: |
        apiVersion: v1
        kind: ConfigMap
        metadata:
          generateName: dev-env-
        data:
          key: value

Suspend

Le template suspend met en pause l’exécution du workflow pour une durée (duration) ou indéfiniment jusqu’à une reprise manuelle via CLI, API, ou UI.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: delay-
spec:
  entrypoint: delay
  templates:
  - name: delay
    suspend:
      duration: "20s"

CLI pour reprendre:

argo -n argo resume delay-xyzb

Plugin

Le template plugin permet à Argo workflow d’utiliser des executor plugins (built-in ou third-party) afin d’étendre son comportement, en référençant un plugin pour exécuter des actions externes sans lancer de container.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: argocd-example-
spec:
  entrypoint: main
  templates:
  - name: main
    plugin:
      argocd:
        serverUrl: https://my-argocd.com/
        actions:
        - sync:
            project: highway-animation
            apps:
            - highway-animation
            - health-check-app
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: slack-example-
spec:
  entrypoint: main
  templates:
  - name: main
    plugin:
      slack:
        text: "{{workflow.name}} finished!"

ContainerSet

Le template containerSet est similaire à un template container ou script, mais permet de définir plusieurs containers exécutés dans un même pod. Le champ containerSet contient un tableau de containers.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: container-set-template-
spec:
  entrypoint: main
  templates:
  - name: main
    containerSet:
      containers:
      - name: a
        image: rancher/cowsay
        command: [cowsay]
        args: ["Container A!!!!"]
      - name: b
        image: rancher/cowsay
        command: [cowsay]
        args: ["Container B!!!!"]

HTTP

Le template http permet d’exécuter des requêtes HTTPs, avec la possibilité de définir l’url, la method (GET par défaut), les headers et le body. Le contenu de la réponse est automatiquement exporté dans un output result.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: http-template-example-
spec:
  entrypoint: fetch-todo-item
  templates:
  - name: fetch-todo-item
    http:
      url: "https://x.y.com/todos/1"
      method: "GET"
      headers:
      - name: "Content-Type"
        value: "application/json"

Template Invocators

  • Les templates steps et DAG sont les deux types d’invocateurs.
  • Ils ne font pas de travail eux-mêmes mais définissent comment d’autres templates (définitions) sont appelés et composés dans un workflow.
  • Steps pour des flux séquentiels/parallèles et DAG pour des graphes d’exécution basés sur les dépendances.

Avec ces types de templates, vous pouvez exprimer une large variété de patterns d’orchestration, des tâches container simples à l’automatisation multi-ressources complexe et aux intégrations avec d’autres systèmes.

Ces templates sont utilisés pour invoquer/appeler d’autres templates et fournir un contrôle d’exécution.

Steps

Un template steps permet de définir vos tâches sous forme d’une série d’étapes. La structure du template est une "liste de listes" :

  • Les listes externes s’exécutent séquentiellement
  • Les listes internes s’exécutent en parallèle

Si vous souhaitez exécuter les listes internes une par une, vous pouvez utiliser la fonctionnalité Synchronization.

Vous pouvez également configurer de nombreuses options pour contrôler l’exécution, comme les clauses when pour exécuter conditionnellement une étape.

👉 Dans cet exemple :

  • step1 s’exécute en premier
  • Une fois terminé, step2a et step2b s’exécutent en parallèle
- name: hello-hello-hello
  steps:
  - - name: step1
        template: prepare-data
  - - name: step2a
        template: run-data-first-half
      - name: step2b
        template: run-data-second-half

DAG

Un template DAG permet de définir vos tâches sous forme de graphe de dépendances (Directed Acyclic Graph).

Dans un DAG:

  • Vous listez toutes vos tasks
  • Vous définissez les dependencies entre elles
  • Les tâches sans dépendances sont exécutées immédiatement
- name: diamond
  dag:
    tasks:
    - name: A
      template: echo
    - name: B
      dependencies: [A]
      template: echo
    - name: C
      dependencies: [A]
      template: echo
    - name: D
      dependencies: [B, C]
      template: echo
  • A s’exécute en premier
  • Une fois terminé, B et C s’exécutent en parallèle
  • Une fois B et C terminés, D s’exécute