Argo WorkflowTemplates: Types, Examples, and Basic Operations

Article Content

What Are Argo WorkflowTemplates?

Argo Workflows is an open source engine for container-native workflows. It orchestrates parallel jobs on Kubernetes, implemented as a Kubernetes Custom Resource Definition (CRD).

A WorkflowTemplate is a definition of a Workflowthat resides in a cluster. You can leverage Workflow templates to build a library for your frequently-used templates, which you can reuse by referencing in a Workflow or submitting them directly.

WorkflowTemplate vs Template

People often confuse WorkflowTemplates with templates due to their similar names. However, these are not interchangeable concepts:

  • template—written in lower-case, a template is a task in a Workflow or in the templates field in a WorkflowTemplate. When you define the Workflow, you need to specify at least one template to run, though usually, you’ll choose multiple templates. Types of templates include script, container, dag, steps,  suspend, or resource. Other dag or step templates (or entrypoints) can reference each template.
  • WorkflowTemplate—this capitalized term refers to a Workflow definition residing in the cluster. Because it defines the entire workflow, it contains individual templates. The  WorkflowTemplate and other WorkflowTemplates or Workflows in the cluster can reference the templates. 

Here are common types of templates that can be used within a WorkflowTemplate:

  • Container—schedules containers. It has an identical template spec to Kubernetes container specifications, which you can define in the same way you usually define containers in Kubernetes. It is perhaps the most popular template type.
  • Resource—performs operations directly on cluster resources. This template lets you send resource requests like CREATE, GET, APPLY, REPLACE, PATCH, and DELETE. 
  • Script—wraps containers for convenience. It is similar to container specifications, but it has a source:field to define the script in place. You can save scripts to files for execution. The result of a script produces automatically exports to Argo variables such as {{tasks.<NAME>.outputs.result}} or {{steps.<NAME>.outputs.result}}.
  • Suspend—suspends a workflow’s execution indefinitely or for a specified period. You can manually resume the workflow from the CLI, API endpoint, or UI (using the command argo resume).
  • Invocator—call or invoke other templates to control how they execute.
  • Steps—defines workflows as sequences of tasks (steps). It is a type of invocator. The template structure includes a set of inner lists running in parallel and outer lists running in sequence. You control the execution via various settings. 
  • DAG—a type of invocator that defines workflow tasks using dependency graphs. The directed acyclic graph (DAG) lists the tasks and their dependencies, specifying the execution order. If a task does not have any dependencies, Argo runs it immediately.

Examples of Argo WorkflowTemplates

The code examples were taken from the official Argo Workflow documentation.

Container Set Template

A container set template lets you run multiple containers in a single pod. All these containers will be scheduled on the same host. Instead of using persistent volume claims, the template uses cheap empty-dir volumes to share data between template steps.

Note that by default, this type of template will run containers in parallel. If you want to specify dependencies, you’ll need to use the Emissary Executor. It is not suitable for large-scale deployments with hundreds of containers.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: container-set-template-
spec:
  entrypoint: main
  templates:
   —name: main
      volumes:
       —name: workspace
          emptyDir: { }
      containerSet:
        volumeMounts:
         —mountPath: /workspace
            name: workspace
        containers:
         —name: a
            image: argoproj/argosay:v2
         —name: b
            image: argoproj/argosay:v2
         —name: main
            image: argoproj/argosay:v2
            dependencies:
             —a
             —b
      outputs:
        parameters:
         —name: message
            valueFrom:
              path: /workpsace/message

HTTP Template

An HTTP Template can be used to execute HTTP Requests. HTTP Templates use the Argo Agent, which executes the requests independently of the controller. The Agent and the Workflow Controller communicate through the WorkflowTaskSet CRD.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: http-template-
spec:
  entrypoint: main
  templates:
   —name: main
      steps:
       —- name: get-google-homepage
            template: http
            arguments:
              parameters: [{name: url, value: "https://www.google.com"}]
   —name: http
      inputs:
        parameters:
         —name: url
      http:
        timeoutSeconds: 20 # Default 30
        url: "{{inputs.parameters.url}}"
        method: "GET" # Default GET
        headers:
         —name: "x-header-name"
            value: "test-value"
        # Template will succeed if evaluated to true, otherwise will fail
        # Available variables:
        #  request.body: string, the response body
        #  request.headers: map[string][]string, the response headers
        #  response.url: string, the request url
        #  response.method: string, the request method
        #  response.statusCode: int, the response status code
        #  response.body: string, the response body
        #  response.headers: map[string][]string, the response headers
        successCondition: "response.body contains \"google\"" # available since v3.3
        body: "test body" # Change request body

Related content: Read our guide to Argo Workflow examples

Managing WorkflowTemplates

Following are several ways you can create WorkflowTemplate resources in your cluster via the Argo Workflow interface. However, note that it is preferred to create templates GitOps style, in a central repository that holds your cluster state, rather than by directly applying them to your cluster. You can add templates GitOps style using Argo CD.

Creating WorkflowTemplates via CLI

Use this CLI command to create some example templates:

argo template create https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/workflow-template/templates.yaml

You can create a workflow directly from one of these templates using the argo submit command:

argo submit https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/workflow-template/hello-world.yaml

Alternatively, you can create a WorkflowTemplate using the --fromflag:

argo submit --from workflowtemplate/workflow-template-submittable

The submit operation supports multiple parameters that control the creation of templates—see the full list here.

Creating WorkflowTemplates via kubectl

You can create WorkflowTemplates with this command:

kubectl apply -f

You can view current WorkflowTemplates in the cluster by running this command:

kubectl get wftmpl

Creating WorkflowTemplates via the UI

Users can specify options under enumto enable drop-down list selection when submitting WorkflowTemplates from the UI.

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: workflow-template-with-enum-values
spec:
  entrypoint: argosay
  arguments:
    parameters:
     —name: message
        value: one
        enum:
         —  one
         —  two
         —  three
  templates:
   —name: argosay
      inputs:
        parameters:
         —name: message
            value: '{{workflow.parameters.message}}'
      container:
        name: main
        image: 'argoproj/argosay:v2'
        command:
         —/argosay
        args:
         —echo
         —'{{inputs.parameters.message}}'

What Is templateDefaults?

The TemplateDefaults feature lets you define a value that will be used for all templates in a workflow—unless a template uses a specific value, which will then take precedence. Default values are applied at runtime.

The following example shows how to configure a templateDefault in the WorkflowSpec YAML. It is also possible to configure templateDefault at the controller level, meaning the default values will apply to all workflows.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: template-defaults-example
spec:
  entrypoint: main
  templateDefaults:
    timeout: 30s   # timeout value will be applied to all templates
    retryStrategy: # retryStrategy value will be applied to all templates
      limit: 2
  templates:
 —name: main
    container:
      image: docker/whalesay:latest

Using Argo Workflows in Codefresh

Codefresh now fully incorporates Argo Workflows and Argo Events, including the Codefresh Hub for Argo. This is a central hub for Codefresh platform users and Argo users to consume and share workflow templates.

Codefresh Argo Hub

On a technical level adopting Argo Workflows has the following advantages:

  • Mature and battle-tested runtime for all pipelines.
  • Kubernetes native capabilities such as being able to run each step in its own Kubernetes pod.
  • Offering a set of reusable steps in the form of Workflow Templates
  • Ability to reuse all existing Artifact integrations instead of spending extra effort to create our own.

The non-technical advantages are just as important:

  • Organizations familiar with Argo Workflows can adopt Codefresh workflows with minimal effort.
  • Faster delivery of new features – any new feature shipped by the Argo Workflows project is available to Codefresh users.

The World’s Most Modern CI/CD Platform

A next generation CI/CD platform designed for cloud-native applications, offering dynamic builds, progressive delivery, and much more.

Check It Out
Related Argo Workflows articles