Pipeline de CI orientado a eventos com EventBridge - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Crie um Pipeline de CI automatizado eficiente, rápido e econômico usando EventBridge e o sistema de fluxo de trabalho distribuído Argo Workflows. Essa abordagem simplifica e acelera a entrega de aplicações.

Pré-requisitos

Você já ativou o EventBridge e concedeu as permissões.
Você já criou um cluster de fluxo de trabalho Argo.
Você já criou um sistema de arquivos.
Você já criou uma instância Enterprise Edition.
Você concedeu a permissão AliyunAdcpFullAccess a um usuário RAM. Para mais informações, consulte Conceder permissões a um usuário RAM.

Como funciona

Um Pipeline de CI automatizado e orientado a eventos consiste em duas partes:

O commit de código em um repositório Git aciona um evento Git.
O sistema de CI executa testes de pré-build, cria uma imagem Docker e envia a imagem para um repositório de imagens.

Após criar a imagem com êxito, use um sistema de implantação contínua (CD), como o ACK One GitOps, para sincronizar a nova tag da imagem com seu cluster Kubernetes.

Este tutorial usa o EventBridge como solução orientada a eventos devido às suas vantagens em disponibilidade, facilidade de uso, segurança e escalabilidade. O componente de CI emprega o Argo Workflows, projeto graduado da Cloud Native Computing Foundation (CNCF). O cluster de fluxo de trabalho gerencia totalmente o Argo Workflows, melhorando a estabilidade e a observabilidade. Ele também oferece recursos de operações e manutenção (O&M) para ajudar você a construir Pipelines de CI maiores, mais rápidos e econômicos.

Um usuário faz commit de código em um repositório Git.
Com base em uma regra de evento configurada, o EventBridge captura o evento Git e o encaminha para o cluster de fluxo de trabalho do ACK One, acionando o fluxo de trabalho de CI.
Um fluxo de trabalho de CI em um cluster de fluxo de trabalho do ACK One cria uma imagem Docker e a envia para um repositório de imagens. Em seguida, use o GitOps para sincronizar automaticamente as alterações da imagem com um cluster ACK.

Etapa 1: Preparar o ambiente de CI

Crie uma credencial de acesso ao ACR EE e monte um volume NAS. Para mais informações, consulte a Etapa 1 e a Etapa 2 em Criar um Pipeline de CI para um projeto Golang usando um cluster de fluxo de trabalho.

Nota
Certifique-se de que o namespace seja o mesmo do recurso Workflow.
Este tutorial usa o projeto echo-server como código de aplicação de exemplo. Faça um fork do projeto para sua conta GitHub e modifique o WorkflowTemplate seguindo as instruções em Clonar um repositório Git privado em um Pipeline de CI.

Etapa 2: Acionar o pipeline de CI com o EventBridge

Crie um barramento de eventos personalizado.
Integre o EventBridge ao GitHub. Para mais informações, consulte a Integração com GitHub.
Opcionalmente, configure uma regra de evento. O código abaixo fornece um exemplo de configuração. Para mais detalhes sobre como configurar regras de evento, consulte Gerenciar regras de evento.
1. Padrão de evento: a configuração a seguir aciona alterações apenas na branch release-v1.
```
{
    "source": [
        "github.event"
    ],
    "data": {
        "body": {
            "ref": [
                "refs/heads/release-v1"
            ]
        }
    }
}
```
2. Configure o destino do evento.
  1. Service Type: Selecione Container Service for Kubernetes.
  2. Cluster KubeConfig: Insira o KubeConfig para acessar o cluster de fluxo de trabalho pela VPC.
  3. YAML Configuration: Selecione Template.
  4. Parameters: Adicione workflowName para configurar o ID do evento.
```
{
  "workflowName": "$.id"
}
```
  5. Template: Insira o recurso personalizado (CR) do Workflow de CI. O exemplo a seguir serve apenas como referência; crie o CR com base nas suas informações reais.
    
    Importante
    As configurações de recurso exigem que você defina explicitamente name e namespace. Não é possível usar generateName. Se um recurso pertencer ao namespace padrão default, declare-o obrigatoriamente.
```
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: ci-go-v1-eb-${workflowName}
  namespace: default
  labels:
    workflows.argoproj.io/workflow-template: ackone-ci
spec:
  arguments:
    parameters:
    - name: repo_url
      value: https://github.com/ivan-cai/echo-server.git
    - name: repo_name
      value: echo-server
    - name: target_branch
      value: release-v1
    - name: container_image
      value: "YOUR-IMAGE-REGISTRY-ADDRESS"     # Replace this with the address of your container image repository.
    - name: container_tag
      value: "v1.0.0"
    - name: dockerfile
      value: ./Dockerfile
    - name: enable_suffix_commitid
      value: "true"
    - name: enable_test
      value: "true"
  workflowTemplateRef:
    name: ci-go-v1
    clusterScope: true
```
  6. Network Access: Recomendamos o uso de uma VPC. Selecione a VPC, o vSwitch e o grupo de segurança correspondentes ao cluster de fluxo de trabalho.
Com a configuração anterior, ao modificar e fazer commit de código na branch release-v1 do seu repositório GitHub, essa ação aciona um processo automatizado. Verifique isso das seguintes maneiras:
1. Visualize o rastreamento de eventos.
  1. Faça login no console do EventBridge. No painel de navegação à esquerda, clique em Event Buses.
  2. Clique no nome do seu barramento de eventos. No painel de navegação à esquerda, clique em Event trace.
  3. Na página Event trace, visualize o rastreamento do evento.
    
    Nos detalhes do rastreamento de eventos, o ID do evento é b91299ae-355d-4f66-ac53-8d84e5d84b97, o tipo de evento é eventbridge:Events:HTTPEvent, o nome do barramento de eventos é ci-test e a origem do evento é github.event. Na seção Event Delivery, a regra ttt entregou o evento ao destino https://8.217.97.153:6443. O status da entrega é Succeeded, a latência de entrega é de 59 ms e a resposta da entrega é [200]NoMessage.
2. Verifique a topologia de execução do Workflow recém-criado.
  
  Essa topologia encontra-se no cluster de fluxo de trabalho. Para mais informações, consulte Habilitar o Argo Server para acessar o cluster de fluxo de trabalho.
  
  O Workflow chama-se ci-go-v1-eb-3999580c-1ee4-4e10-a75b-af6e8eddccde. Sua topologia de execução em grafo acíclico dirigido (DAG) mostra as seguintes etapas: git-checkout-pr (Succeeded), run-test (Succeeded) e build-push-image (Running).