3.2. Comprendre les pipelines OpenShift

Task les ressources sont les éléments constitutifs d'un pipeline et consistent en des étapes exécutées de manière séquentielle. Il s'agit essentiellement d'une fonction d'entrées et de sorties. Une tâche peut être exécutée individuellement ou dans le cadre d'un pipeline. Les tâches sont réutilisables et peuvent être utilisées dans plusieurs pipelines.

Steps sont une série de commandes qui sont exécutées séquentiellement par la tâche et qui permettent d'atteindre un objectif spécifique, tel que la construction d'une image. Chaque tâche s'exécute en tant que pod, et chaque étape s'exécute en tant que conteneur au sein de ce pod. Comme les étapes s'exécutent dans le même module, elles peuvent accéder aux mêmes volumes pour les fichiers de mise en cache, les cartes de configuration et les secrets.

L'exemple suivant illustre la tâche apply-manifests.

apiVersion: tekton.dev/v1beta1 1
kind: Task 2
metadata:
  name: apply-manifests 3
spec: 4
  workspaces:
  - name: source
  params:
    - name: manifest_dir
      description: The directory in source that contains yaml manifests
      type: string
      default: "k8s"
  steps:
    - name: apply
      image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
      workingDir: /workspace/source
      command: ["/bin/bash", "-c"]
      args:
        - |-
          echo Applying manifests in $(params.manifest_dir) directory
          oc apply -f $(params.manifest_dir)
          echo -----------------------------------

Cette tâche démarre le pod et exécute un conteneur à l'intérieur de ce pod en utilisant l'image spécifiée pour exécuter les commandes spécifiées.

spec:
  pipeline:
    disable-working-directory-overwrite: false
    disable-home-env-overwrite: false

Les expressions When protègent l'exécution des tâches en définissant des critères pour l'exécution des tâches au sein d'un pipeline. Elles contiennent une liste de composants qui permet à une tâche de s'exécuter uniquement lorsque certains critères sont remplis. Les expressions When sont également prises en charge dans l'ensemble final des tâches spécifiées à l'aide du champ finally dans le fichier YAML du pipeline.

Les éléments clés d'une expression when sont les suivants :

Les expressions when déclarées sont évaluées avant l'exécution de la tâche. Si la valeur d'une expression when est True, la tâche est exécutée. Si la valeur d'une expression when est False, la tâche est ignorée.

Vous pouvez utiliser les expressions when dans différents cas d'utilisation. Par exemple, si :

L'exemple suivant montre les expressions when pour une exécution de pipeline. Le pipeline n'exécutera la tâche create-file que si les critères suivants sont remplis : le paramètre path est README.md, et la tâche echo-file-exists n'est exécutée que si le résultat exists de la tâche check-file est yes.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun 1
metadata:
  generateName: guarded-pr-
spec:
  serviceAccountName: 'pipeline'
  pipelineSpec:
    params:
      - name: path
        type: string
        description: The path of the file to be created
    workspaces:
      - name: source
        description: |
          This workspace is shared among all the pipeline tasks to read/write common resources
    tasks:
      - name: create-file 2
        when:
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        workspaces:
          - name: source
            workspace: source
        taskSpec:
          workspaces:
            - name: source
              description: The workspace to create the readme file in
          steps:
            - name: write-new-stuff
              image: ubuntu
              script: 'touch $(workspaces.source.path)/README.md'
      - name: check-file
        params:
          - name: path
            value: "$(params.path)"
        workspaces:
          - name: source
            workspace: source
        runAfter:
          - create-file
        taskSpec:
          params:
            - name: path
          workspaces:
            - name: source
              description: The workspace to check for the file
          results:
            - name: exists
              description: indicates whether the file exists or is missing
          steps:
            - name: check-file
              image: alpine
              script: |
                if test -f $(workspaces.source.path)/$(params.path); then
                  printf yes | tee /tekton/results/exists
                else
                  printf no | tee /tekton/results/exists
                fi
      - name: echo-file-exists
        when: 3
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo file exists'
...
      - name: task-should-be-skipped-1
        when: 4
          - input: "$(params.path)"
            operator: notin
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: exit 1
...
    finally:
      - name: finally-task-should-be-executed
        when: 5
          - input: "$(tasks.echo-file-exists.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo finally done'
  params:
    - name: path
      value: README.md
  workspaces:
    - name: source
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 16Mi

La page Pipeline Run details de la console web de OpenShift Container Platform montre l'état des tâches et des expressions de temps comme suit :

Les tâches finally sont le dernier ensemble de tâches spécifiées à l'aide du champ finally dans le fichier YAML du pipeline. Une tâche finally exécute toujours les tâches du pipeline, que les exécutions du pipeline soient réussies ou non. Les tâches finally sont exécutées en parallèle après l'exécution de toutes les tâches du pipeline, avant que le pipeline correspondant ne se termine.

Vous pouvez configurer une tâche finally pour qu'elle consomme les résultats de n'importe quelle tâche du même pipeline. Cette approche ne modifie pas l'ordre d'exécution de cette tâche finale. Elle est exécutée en parallèle avec d'autres tâches finales après l'exécution de toutes les tâches non finales.

L'exemple suivant montre un extrait de code du pipeline clone-cleanup-workspace. Ce code clone le référentiel dans un espace de travail partagé et nettoie l'espace de travail. Après avoir exécuté les tâches du pipeline, la tâche cleanup spécifiée dans la section finally du fichier YAML du pipeline nettoie l'espace de travail.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-cleanup-workspace 1
spec:
  workspaces:
    - name: git-source 2
  tasks:
    - name: clone-app-repo 3
      taskRef:
        name: git-clone-from-catalog
      params:
        - name: url
          value: https://github.com/tektoncd/community.git
        - name: subdirectory
          value: application
      workspaces:
        - name: output
          workspace: git-source
  finally:
    - name: cleanup 4
      taskRef: 5
        name: cleanup-workspace
      workspaces: 6
        - name: source
          workspace: git-source
    - name: check-git-commit
      params: 7
        - name: commit
          value: $(tasks.clone-app-repo.results.commit)
      taskSpec: 8
        params:
          - name: commit
        steps:
          - name: check-commit-initialized
            image: alpine
            script: |
              if [[ ! $(params.commit) ]]; then
                exit 1
              fi

Un site TaskRun instancie une tâche à exécuter avec des entrées, des sorties et des paramètres d'exécution spécifiques sur un cluster. Il peut être invoqué seul ou dans le cadre d'une exécution de pipeline pour chaque tâche d'un pipeline.

Une tâche consiste en une ou plusieurs étapes qui exécutent des images de conteneur, et chaque image de conteneur effectue un travail de construction spécifique. Une exécution de tâche exécute les étapes d'une tâche dans l'ordre spécifié, jusqu'à ce que toutes les étapes s'exécutent avec succès ou qu'un échec se produise. Un TaskRun est automatiquement créé par un PipelineRun pour chaque tâche d'un pipeline.

L'exemple suivant montre une tâche qui exécute la tâche apply-manifests avec les paramètres d'entrée appropriés :

apiVersion: tekton.dev/v1beta1 1
kind: TaskRun 2
metadata:
  name: apply-manifests-taskrun 3
spec: 4
  serviceAccountName: pipeline
  taskRef: 5
    kind: Task
    name: apply-manifests
  workspaces: 6
  - name: source
    persistentVolumeClaim:
      claimName: source-pvc

Un site Pipeline est un ensemble de ressources Task disposées dans un ordre d'exécution spécifique. Elles sont exécutées pour construire des flux de travail complexes qui automatisent la construction, le déploiement et la livraison d'applications. Vous pouvez définir un flux de travail CI/CD pour votre application à l'aide de pipelines contenant une ou plusieurs tâches.

Une définition de ressource Pipeline se compose d'un certain nombre de champs ou d'attributs qui, ensemble, permettent au pipeline d'atteindre un objectif spécifique. Chaque définition de ressource Pipeline doit contenir au moins une ressource Task, qui reçoit des données d'entrée spécifiques et produit des données de sortie spécifiques. La définition du pipeline peut également inclure Conditions, Workspaces, Parameters, ou Resources en fonction des exigences de l'application.

L'exemple suivant montre le pipeline build-and-deploy, qui construit une image d'application à partir d'un dépôt Git en utilisant la ressource buildah ClusterTask :

apiVersion: tekton.dev/v1beta1 1
kind: Pipeline 2
metadata:
  name: build-and-deploy 3
spec: 4
  workspaces: 5
  - name: shared-workspace
  params: 6
  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "pipelines-1.9"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks: 7
  - name: fetch-repository
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.git-url)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
    - name: revision
      value: $(params.git-revision)
  - name: build-image 8
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests 9
    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter: 10
    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests

Un site PipelineRun est un type de ressource qui lie un pipeline, des espaces de travail, des informations d'identification et un ensemble de valeurs de paramètres spécifiques à un scénario pour exécuter le flux de travail CI/CD.

Un site PipelineRun est l'instance en cours d'exécution d'un pipeline. Il instancie un pipeline pour l'exécuter avec des entrées, des sorties et des paramètres d'exécution spécifiques sur un cluster. Il crée également une exécution de tâche pour chaque tâche de l'exécution du pipeline.

Le pipeline exécute les tâches de manière séquentielle jusqu'à ce qu'elles soient terminées ou qu'une tâche échoue. Le champ status suit la progression de chaque tâche et la stocke à des fins de contrôle et d'audit.

L'exemple suivant exécute le pipeline build-and-deploy avec les ressources et les paramètres appropriés :

apiVersion: tekton.dev/v1beta1 1
kind: PipelineRun 2
metadata:
  name: build-deploy-api-pipelinerun 3
spec:
  pipelineRef:
    name: build-and-deploy 4
  params: 5
  - name: deployment-name
    value: vote-api
  - name: git-url
    value: https://github.com/openshift-pipelines/vote-api.git
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api
  workspaces: 6
  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

Les espaces de travail déclarent les volumes de stockage partagés dont une tâche d'un pipeline a besoin au moment de l'exécution pour recevoir des données d'entrée ou fournir des données de sortie. Au lieu de spécifier l'emplacement réel des volumes, les espaces de travail vous permettent de déclarer le système de fichiers ou les parties du système de fichiers qui seraient nécessaires au moment de l'exécution. Une tâche ou un pipeline déclare l'espace de travail et vous devez fournir les détails de l'emplacement spécifique du volume. Celui-ci est ensuite monté dans cet espace de travail lors de l'exécution d'une tâche ou d'un pipeline. Cette séparation entre la déclaration de volume et les volumes de stockage au moment de l'exécution rend les tâches réutilisables, flexibles et indépendantes de l'environnement de l'utilisateur.

Avec les espaces de travail, vous pouvez

Vous pouvez spécifier des espaces de travail dans les sites TaskRun ou PipelineRun en utilisant :

L'exemple suivant montre un extrait de code du pipeline build-and-deploy, qui déclare un espace de travail shared-workspace pour les tâches build-image et apply-manifests telles que définies dans le pipeline.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces: 1
  - name: shared-workspace
  params:
...
  tasks: 2
  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces: 3
    - name: source 4
      workspace: shared-workspace 5
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces: 6
    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...

Les espaces de travail aident les tâches à partager des données et vous permettent de spécifier un ou plusieurs volumes dont chaque tâche du pipeline a besoin pendant son exécution. Vous pouvez créer une demande de volume persistant ou fournir un modèle de demande de volume qui crée une demande de volume persistant pour vous.

L'extrait de code suivant de l'exécution du pipeline build-deploy-api-pipelinerun utilise un modèle de demande de volume pour créer une demande de volume persistante afin de définir le volume de stockage de l'espace de travail shared-workspace utilisé dans le pipeline build-and-deploy.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: build-deploy-api-pipelinerun
spec:
  pipelineRef:
    name: build-and-deploy
  params:
...

  workspaces: 1
  - name: shared-workspace 2
    volumeClaimTemplate: 3
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

Utilisez Triggers en conjonction avec les pipelines pour créer un système CI/CD à part entière où les ressources Kubernetes définissent l'ensemble de l'exécution CI/CD. Les déclencheurs capturent les événements externes, tels qu'une demande d'extraction Git, et les traitent pour en extraire des informations clés. La mise en correspondance de ces données d'événement avec un ensemble de paramètres prédéfinis déclenche une série de tâches qui peuvent ensuite créer et déployer des ressources Kubernetes et instancier le pipeline.

Par exemple, vous définissez un flux de travail CI/CD à l'aide de Red Hat OpenShift Pipelines pour votre application. Le pipeline doit démarrer pour que toute nouvelle modification prenne effet dans le référentiel de l'application. Les déclencheurs automatisent ce processus en capturant et en traitant tout événement de changement et en déclenchant une exécution du pipeline qui déploie la nouvelle image avec les dernières modifications.

Les déclencheurs sont constitués des principales ressources suivantes, qui fonctionnent ensemble pour former un système CI/CD réutilisable, découplé et autonome :