Pesquisa de site

Agendamento dinâmico de cargas de trabalho Tekton usando Triggers

Atualize seu pipeline de CI/CD com este aplicativo nativo do Kubernetes.

Tekton é uma estrutura de integração e entrega contínua (CI/CD) nativa do Kubernetes. Ele permite que você crie cargas de trabalho em contêineres, combináveis e configuráveis de forma declarativa por meio de Definições de recursos personalizados (CRD) do Kubernetes.

Tekton Triggers é um componente Tekton que permite detectar e extrair informações de eventos de várias fontes e executar TaskRuns e PipelineRuns com base nessas informações. Ele também permite passar informações extraídas de eventos para TaskRuns e PipelineRuns.

Este artigo demonstra como o Tekton Triggers se integra a serviços externos, como um repositório Git, usando o GitLab como exemplo.

Pré-requisitos

Se quiser seguir as etapas deste artigo, você deve ter um cluster Kubernetes executando o Kubernetes 1.18 ou superior com um controlador de entrada instalado que possa fornecer um IP externo. Você também deve ter Tekton Pipelines e Tekton Triggers instalados.

Fluxo de gatilhos

Tekton Trigger permite que você crie um recurso especial chamado EventListener, que é um serviço Kubernetes que escuta solicitações HTTP recebidas de diferentes fontes, geralmente um repositório Git, incluindo aqueles hospedados no GitLab, GitHub e outros. Com base nesses eventos, o pod EventListener executa ações e cria recursos Tekton, como TaskRun ou PipelineRun.

Savita Ashture, CC BY-SA 4.0

Todas as definições de recursos Triggers são criadas em YAML, o formato de configuração mais comumente usado no Kubernetes. No entanto, antes de escrever arquivos YAML para definir um Trigger, é importante entender a terminologia do Tekton Triggers.

EventListener

Um EventListener é um serviço Kubernetes que escuta solicitações HTTP recebidas e executa um Trigger. Por exemplo, depois de receber uma solicitação específica, esta definição executa o gatilho gitlab-listener-trigger:

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: gitlab-event-listener
spec:
  serviceAccountName: gitlab-listener-sa
  triggers:
    - triggerRef: gitlab-listener-trigger
  resources:
    kubernetesResource:
      serviceType: NodePort

Acionar

Um Trigger decide o que fazer com um evento recebido. Ele também define TriggerBinding, TriggerTemplate e interceptores opcionais para execução. Os gatilhos usam interceptores para validar ou modificar as solicitações recebidas antes de prosseguir.

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: gitlab-listener-trigger
spec:
  interceptors:
    - name: "verify-gitlab-payload"
      ref:
        name: "gitlab"
        kind: ClusterInterceptor
      params:
        - name: secretRef
          value:
            secretName: "gitlab-secret"
            secretKey: "secretToken"
        - name: eventTypes
          value:
            - "Push Hook"
  bindings:
    - ref: binding
  template:
    ref: template

Interceptor

Um interceptor é um processador de eventos executado antes do TriggerBinding. Ele também realiza filtragem, verificação (usando um segredo) e transformação de carga útil; define e testa condições de disparo; e implementa outro processamento útil.

Por padrão, quatro interceptores principais são instalados ao instalar Triggers: GitHub, GitLab, Bitbucket e CEL. A instalação também inclui um interceptor Webhook para implementar lógica de negócios personalizada.

Interceptadores GitLab

Os interceptadores GitLab ajudam a validar e filtrar webhooks GitLab e filtrar eventos recebidos por tipo de evento. O interceptor GitLab requer um token secreto. Este token é definido ao criar o webhook no GitLab e é validado pelo interceptor GitLab quando a solicitação chega.

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-secret
type: Opaque
stringData:
  secretToken: "1234567"

Ligação de gatilho

Depois de validar e modificar a solicitação recebida, você precisa extrair valores da solicitação e vinculá-los a variáveis que você pode usar posteriormente em um TriggerTemplate para passar nosso Pipeline.

Para nosso exemplo, você só precisa de uma URL e uma revisão.

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: binding
spec:
  params:
    - name: gitrevision
      value: $(body.checkout_sha)
    - name: gitrepositoryurl
      value: $(body.repository.git_http_url)

Modelo de gatilho

O TriggerTemplate é um blueprint que instancia TaskRun ou PipelineRun quando EventListener detecta um evento.

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: template
spec:
  params:
    - name: gitrevision
    - name: gitrepositoryurl
  resourcetemplates:
    - apiVersion: tekton.dev/v1beta1
      kind: TaskRun
      metadata:
        generateName: gitlab-run-
      spec:
        taskSpec:
          resources:
            inputs:
              - name: source
                type: git
          steps:
            - image: ubuntu
              script: |
                #! /bin/bash
                ls -al $(inputs.resources.source.path)
        resources:
          inputs:
            - name: source
              resourceSpec:
                type: git
                params:
                  - name: revision
                    value: $(tt.params.gitrevision)
                  - name: url
                    value: $(tt.params.gitrepositoryurl)

Observe que o módulo de recursos do pipeline está, no momento da escrita, sendo obsoleto e será substituído por tarefas git-clone, de tektoncd/catalog.

Agende cargas de trabalho dinamicamente configurando um webhook

Primeiro, crie um novo namespace, demo:

$ kubectl create ns demo

Em seguida, antes de aplicar o recurso Triggers, configure o controle de acesso baseado em função (RBAC) necessário:

$ kubectl -n demo apply -f \
"https://gist.githubusercontent.com/savitaashture/596bc4d93ff6b7606fe52aa20ba1ba14/raw/158a5ed0dc30fd1ebdac461147a4079cd6187eac/triggers-rbac.yaml"

Nota: As configurações do RBAC variam dependendo das permissões.

Aplicar recursos de gatilhos:

$ kubectl -n demo apply -f \
"https://gist.githubusercontent.com/savitaashture/8aa013db1cb87f5dd1f2f96b0e121363/raw/f4f592d8c1332938878c5ab9641e350c6411e2b0/triggers-resource.yaml"

Após a aplicação, verifique a criação bem-sucedida do objeto EventListener e do pod:

O status READY do objeto EventListener deve ser True. 

$ kubectl get el -n demo
NAME                    ADDRESS                                                     AVAILABLE REASON              READY             REASON                                                                                                             
gitlab-event-listener   http://el-gitlab-event-listener.demo.svc.cluster.local:8080   True                 MinimumReplicasAvailable   True

O status do pod EventListener deve ser Em execução.

$ kubectl get pods -n demo
NAME                                       READY          STATUS    RESTARTS              AGE
el-gitlab-event-listener-fb77ff8f7-p5wnv   1/1            Running   0                     4m22s

Crie entrada para obter o IP externo para configurar no webhook do GitLab:

$ kubectl -n demo apply -f \
"https://gist.githubusercontent.com/savitaashture/3b3554810e391477feae21bb8a9af93a/raw/56665b0a31c7a537f9acbb731b68a519be260808/triggers-ingress.yaml"

Obtenha o IP de entrada:

$ kubectl get ingress triggers-ingress-resource -n demo

NAME               CLASS    HOSTS     ADDRESS                             PORTS   AGE
ingress-resource   <none>   *         <address>                            80      6s

Configure um webhook no GitLab. No seu repositório GitLab, vá para Configurações -> Webhooks.

Em seguida, defina os campos abaixo:

  • URL: endereço IP externo do Ingress com caminho /
  • Token secreto: 1234567, que deve corresponder ao valor secreto criado acima no arquivo triggers-resource.yaml

Escolha o tipo de evento na seção Trigger, selecione Push events, desmarque Ativar verificação SSL e clique em Adicionar webhook.

Savita Ashture, CC BY-SA 4.0

Testando eventos do GitLab pressionando PR

Clone seu próprio repositório GitLab, faça alterações e envie por push. Por exemplo:

$ git clone https://gitlab.com/savitaashture1/gitlabtest-triggers
$ cd gitlabtest-triggers
               $ git commit -m "empty-commit" --allow-empty && git push origin main
[main 934ecba] empty-commit
Username for 'https://gitlab.com': savitaashture
Password for 'https://savitaashture@gitlab.com': 
warning: redirecting to https://gitlab.com/savitaashture1/gitlabtest-triggers.git/
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 183 bytes | 183.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://gitlab.com/savitaashture1/gitlabtest-triggers
   ff1d11e..934ecba  main -> main

Os eventos serão gerados e enviados para o pod EventListener. Você pode verificar isso fazendo:

kubectl get pods -n demo
kubectl logs -f <pod_name> -n demo

Verifique a entrega bem-sucedida de eventos executando uma operação get para TaskRun.

$ kubectl  -n demo get taskruns | grep gitlab-run-

gitlab-run-hvtll   True        Succeeded   95s         87s

Limpe todos os recursos criados pelos Triggers removendo o namespace demo:

$kubectl delete ns demo

Conclusão

Tekton Triggers é um dos módulos mais úteis que ajuda a agendar cargas de trabalho dinamicamente em resposta a um conjunto de eventos definido pelo usuário. Por causa deste módulo, minha equipe conseguiu alcançar CI/CD de ponta a ponta.

Artigos relacionados: