:Gerenciar pipelines

Informações básicas

Ao criar uma aplicação, a plataforma gera um ambiente padrão. Nesse ambiente, especifique o evento git que aciona o pipeline e configure-o conforme necessário. Escolha entre configuração automática ou personalizada. Na configuração automática, a plataforma cria o pipeline com valores padrão para cada item. Já na configuração personalizada, defina o método de acionamento por evento git para o pipeline do ambiente e selecione o ambiente de execução. Informações como detalhes do git e da aplicação são transmitidas ao pipeline como contexto de execução.

Ao editar as configurações do pipeline, além do método de acionamento e do ambiente de execução, você também pode configurar notificações do DingTalk e o arquivo yaml de descrição de recursos.

• Configurar um pipeline ao criar uma aplicação ou ambiente

  Ao criar uma aplicação ou ambiente, especifique o método de acionamento git e o ambiente de execução do pipeline.

  

• Editar um pipeline em um ambiente

  Para um ambiente existente, edite o método de acionamento git, o ambiente de execução, as notificações do DingTalk e o arquivo yaml de descrição de recursos na aba Pipeline management.

  

Configuração de pipeline

A configuração do pipeline abrange quatro itens principais: método de acionamento, ambiente de execução, yaml de descrição de recursos e notificação por robô do DingTalk. Defina o método de acionamento e o ambiente de execução durante a criação da aplicação ou do ambiente. Após a criação, configure todos os quatro itens clicando em no botão Edit.

Método de acionamento do pipeline

O Application Center permite personalizar os eventos git que acionam os pipelines. A plataforma utiliza webhooks para receber esses eventos. Ao detectar um evento correspondente às regras de acionamento, o sistema cria e executa um pipeline com base no arquivo yaml configurado. Os métodos de acionamento suportados são:

• Acionamento por branch: o ambiente deve estar associado a uma branch específica. Corresponde a todos os eventos Push dessa branch.

• Acionamento por tag: corresponde a todos os eventos de criação de tag para a expressão de tag especificada.

• Acionamento por merge de branch: corresponde a eventos de Merge ou Pull Request originados em uma branch source específica e direcionados à branch alvo associada ao ambiente.

Ambiente de execução do pipeline

O Pipeline Execution Environment possui dois modos: Default Environment e Custom Environment.

Ambiente de execução padrão

No Default Environment, a plataforma gerencia integralmente os recursos do pipeline. O Alibaba Cloud Function Compute cobre os custos de execução, isentando você de taxas. Cada tarefa do pipeline roda em um container isolado e independente. A plataforma garante o isolamento do seu ambiente de execução. O ambiente padrão apresenta os seguintes limites:

• Especificações de recursos da instância: 4 vCPU, 8 GB de memória.

• Espaço em disco temporário: 10 GB.

• Timeout de execução da tarefa: 15 minutos.

• Limites de região: a implantação direta de modelos e as fontes de código GitHub utilizam a região de Singapura fora da China. Gitee, GitLab público e Codeup utilizam a região China (Hangzhou).

• Limites de rede: não há suporte para endereços IP fixos, blocos CIDR, acesso a sites específicos via lista de permissões de IP nem acesso a recursos dentro da sua vpc.

Ambiente de execução dedicado

O Custom Environment executa tarefas do pipeline na sua conta e oferece mais opções de personalização. Mediante sua autorização, o Application Center gerencia totalmente as tarefas no ambiente dedicado e agenda instâncias do Function Compute na sua conta para executar os pipelines em tempo real. Assim como o ambiente padrão, o ambiente dedicado é totalmente serverless, eliminando a necessidade de gerenciar a infraestrutura subjacente.

O Custom Environment fornece as seguintes opções de personalização:

• Região e rede: especifique a região e a vpc do ambiente de execução para habilitar cenários como acesso a repositórios de código de rede privada, repositórios de artefatos, repositórios de imagens e servidores Maven privados. Para mais informações sobre regiões suportadas, consulte Regiões.

• Especificações de recursos da instância: defina as especificações de CPU e memória para o ambiente de execução. Por exemplo, utilize uma instância maior para acelerar builds.

  Nota

  A proporção de vCPUs para memória em GB deve estar entre 1:1 e 1:4.

• Armazenamento persistente: configure montagens NAS e OSS. Monte um sistema de arquivos NAS para cache de arquivos e aceleração de builds, por exemplo.

• Logs: indique um projeto SLS e Logstore para persistência dos logs de execução do pipeline.

• Timeout: personalize o timeout de execução das tarefas do pipeline. O padrão é 600 segundos, com máximo de 86.400 segundos.

YAML

O Serverless Application Center integra-se profundamente à ferramenta de desenvolvimento Serverless Devs. Utilize o arquivo de descrição de recursos do Serverless Devs para declarar a configuração de recursos da sua aplicação. O arquivo padrão chama-se s.yaml, mas você pode definir outro nome. Após especificar o arquivo de descrição de recursos, utilize-o no pipeline de duas formas:

• Ao usar o plugin de implantação @serverless-cd/s-deploy, ele emprega automaticamente o arquivo de descrição de recursos indicado para a implantação. Isso ocorre pela adição do comando -t/--template à instrução de operação do Serverless Devs. No exemplo abaixo, o arquivo yaml especificado é demo.yaml, resultando na execução do comando s deploy -t demo.yaml pelo plugin.

- name: deploy
  context:
    data:
      deployFile: demo.yaml
      steps:
      - plugin: '@serverless-cd/s-setup'
      - plugin: '@serverless-cd/checkout'
      - plugin: '@serverless-cd/s-deploy'
  taskTemplate: serverless-runner-task

• Ao executar via script, referencie o nome específico do arquivo de descrição de recursos com ${{ ctx.data.deployFile }}. Por exemplo, o código abaixo executa o comando s plan com o arquivo especificado caso exista; caso contrário, utiliza o arquivo padrão s.yaml.

- name: pre-check
  context:
    data:
      steps:
      - run: s plan -t ${{ ctx.data.deployFile || s.yaml }}
      - run: echo "s plan finished."
  taskTemplate: serverless-runner-task

DingTalk Chatbot Notification Settings

Após ativar esta configuração, defina o Webhook address, a signature key, as regras de notificação e as custom messages do robô DingTalk. Gerencie centralmente as tarefas que exigem notificação aqui ou ative notificações individualmente para cada tarefa via arquivo yaml do pipeline. Concluída a configuração global neste local, refine as definições de notificação para cada tarefa nos Pipeline Details.

Variáveis de ambiente do pipeline

Na seção Pipeline Environment Variables, clique em Modify, escolha um método para configurar o ambiente, conclua a configuração conforme descrito abaixo e clique em Deploy.

• Edição via formulário (padrão)

  1. Clique em +Add Variable.

  2. Configure o par chave-valor da variável de ambiente:

     • Variable: Personalizado.

     • Value: Personalizado.

• Edição em formato JSON

  1. Clique em Edit in JSON Format.

  2. Na caixa de texto, insira o par chave-valor em formato JSON conforme abaixo.

     {
         "key": "value"
     }

     Veja um exemplo a seguir.

     {
         "REGION": "MY_REGION",
         "LOG_PROJECT": "MY_LOG_PROJECT"
     }

As variáveis de ambiente entram em vigor no pipeline do Serverless Devs. Referencie-as no s.yaml usando ${env(key)} ou em comandos shell via $Key. Confira o exemplo abaixo.

vars:
  region: ${env(REGION)}
  service:
    name: demo-service-${env(prefix)}
    internetAccess: true
    logConfig:
      project: ${env(LOG_PROJECT)}
      logstore: fc-console-function-pre
    vpcConfig:
      securityGroupId: ${env(SG_ID)}
      vswitchIds:
        - ${env(VSWITCH_ID)}
      vpcId: ${env(VPC_ID)}

Detalhes do pipeline

Na seção Pipeline Details, configure o fluxo do pipeline e defina parâmetros detalhados para tarefas e suas dependências. A plataforma gera automaticamente um fluxo padrão editável.

O gerenciamento de pipelines ocorre via arquivo yaml. Dois métodos de configuração estão disponíveis: Hosting on Platform e Read from Repository .

Hospedado na plataforma

Por padrão, a plataforma hospeda o arquivo yaml do pipeline. Isso significa que a configuração é gerenciada centralmente e entra em vigor na próxima implantação após uma atualização.

Leitura do repositório

O arquivo yaml de descrição do pipeline reside em um repositório git remoto. Ao editá-lo e salvá-lo no console, a plataforma submete as alterações ao seu repositório git em tempo real. Esse commit não dispara uma execução de pipeline. Quando um evento no repositório de código acionar o pipeline, a plataforma utilizará o arquivo yaml do repositório git especificado para criar e executar o fluxo.

Selecione Read from Repository acima da seção Pipeline Details e insira o nome do arquivo yaml, conforme ilustrado na figura a seguir.

A parte principal da seção Pipeline Details consiste na área de ferramentas de suporte à esquerda e na área de edição yaml à direita:

• Área de edição yaml: edite diretamente o arquivo yaml do pipeline para modificar o fluxo. Para mais informações, consulte Usar um arquivo yaml para descrever um pipeline.

• Área de ferramentas de suporte: oferece recursos para auxiliar na edição yaml, incluindo:

  • Process Preview: fornece visualização gráfica e capacidades simples de edição para o fluxo do pipeline.

  • Task Template: disponibiliza uma série de modelos yaml para tarefas comuns.

No canto superior direito da seção, encontram-se três botões: Save, Full screen mode e Reset:

• O botão Save grava as alterações feitas no arquivo yaml na página e as sincroniza com o arquivo yaml do pipeline.

• O botão Full screen mode expande a área principal de edição para tela cheia.

• O botão Reset cancela todas as alterações desde o último salvamento e reverte ao estado inicial.

Visualizar histórico de execução do pipeline

Clique em uma versão específica de execução do pipeline para ver seus detalhes. Essas informações permitem verificar rapidamente logs e status, facilitando o monitoramento do progresso ou a solução de problemas.

Atualizar o runtime do ambiente de build do pipeline

Defina a versão do runtime do pipeline usando o plugin de pipeline runtime-setup ou modificando as variáveis de ambiente no arquivo de descrição de recursos.