CI/CD moderno com GKE: como criar um sistema de CI/CD

Implantar a arquitetura de referência

1. Defina o projeto no Cloud Shell:

   gcloud config set core/project PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

2. No Cloud Shell, clone o repositório do Git:

   git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
   cd software-delivery-blueprint/launch-scripts
   git checkout single-project-blueprint
   

3. Crie um token de acesso pessoal no GitHub com os seguintes escopos:

   • repo
   • delete_repo
   • admin:org
   • admin:repo_hook

4. Há um arquivo vazio chamado vars.sh na pasta software-delivery-bluprint/launch-scripts. Adicione o seguinte conteúdo ao arquivo:

   cat << EOF >vars.sh
   export INFRA_SETUP_REPO="gke-infrastructure-repo"
   export APP_SETUP_REPO="application-factory-repo"
   export GITHUB_USER=GITHUB_USER
   export TOKEN=TOKEN
   export GITHUB_ORG=GITHUB_ORG
   export REGION="us-central1"
   export SEC_REGION="us-west1"
   export TRIGGER_TYPE="webhook"
   EOF
   

   Substitua GITHUB_USER pelo nome de usuário do GitHub.

   Substitua TOKEN pelo token de acesso pessoal do GitHub.

   Substitua GITHUB_ORG pelo nome da organização do GitHub.

5. Execute o script bootstrap.sh: Se o Cloud Shell solicitar sua autorização, clique em Autorizar:

   ./bootstrap.sh
   

   O script inicializa a plataforma de entrega de software.

Conhecer os repositórios de código

Nesta seção, você conhecerá os repositórios de código.

Faça login no GitHub.

1. Em um navegador da Web, acesse github.com e faça login na sua conta.
2. Clique no ícone de imagem na parte superior da interface.
3. Clique em Suas organizações.
4. Escolha a organização que você forneceu como entrada no arquivo vars.sh.
5. Clique na guia repositório.

Conhecer os repositórios de ativação, operadora, configuração e infraestrutura

Nos repositórios de ativação, operador, configuração e infraestrutura, os operadores e administradores da plataforma definem as práticas recomendadas comuns para criar e operar a plataforma. Esses repositórios são criados na sua organização do GitHub quando a arquitetura de referência é inicializada.

Repositórios para iniciantes

Os repositórios iniciais ajudam na adoção de práticas recomendadas de CI/CD e desenvolvimento em toda a plataforma. Para mais informações, consulte CI/CD moderna com o GKE: um framework de entrega de software (em inglês)

Repositórios iniciais de aplicativos

Nos repositórios iniciais de aplicativos, os operadores podem codificar e documentar práticas recomendadas, como CI/CD, coleta de métricas, geração de registros, etapas de contêiner e segurança para aplicativos. A arquitetura de referência inclui exemplos de repositórios iniciais para aplicativos Go, Python e Java.

Os repositórios iniciais de código padrão app-template-python, app-template-java e app-template-golang contém código boilerplate que é possível usar para criar novos aplicativos. Além de criar aplicativos, é possível criar modelos com base nos requisitos deles. Os repositórios iniciais do aplicativo fornecidos pela arquitetura de referência contêm:

• A base kustomize e os patches na pasta k8s.

• Código-fonte do aplicativo

• Um Dockerfile que descreve como criar e executar o aplicativo

• Um arquivo cloudbuild.yaml que descreve as práticas recomendadas para as etapas de CI.

• Um arquivo skaffold.yaml que descreve as etapas da implantação.

No próximo documento desta série, CI/CD moderna com GKE: aplicar o fluxo de trabalho do desenvolvedor, use o repositório app-template-python para criar um novo aplicativo.

Repositórios básicos de infraestrutura

Nos repositórios iniciais de infraestrutura, os operadores e administradores de infraestrutura podem codificar e documentar práticas recomendadas, como pipelines de CI/CD, IaC, coleta de métricas, geração de registros e segurança para infraestrutura. A arquitetura de referência inclui exemplos de repositórios de infraestrutura inicial que usam o Terraform. O repositório inicial de infraestrutura infra-template contém um código boilerplate do Terraform que pode ser usado para criar os recursos de infraestrutura exigidos por um aplicativo, como o bucket do Cloud Storage, o banco de dados do Spanner, entre outros.

Repositórios de modelos compartilhados

Nos repositórios de modelos compartilhados, os administradores e operadores de infraestrutura oferecem modelos padrão para realizar tarefas. Há um repositório chamado terraform-modules fornecido com a arquitetura de referência. O repositório inclui um modelo de código do Terraform para criar vários recursos de infraestrutura.

Repositórios de operador

Na arquitetura de referência, os repositórios de operadores são os mesmos que os repositórios iniciais do aplicativo. Os operadores gerenciam os arquivos necessários para CI e CD nos repositórios iniciais do aplicativo. A arquitetura de referência inclui os repositórios app-template-python, app-template-java e app-template-golang.

• Eles são modelos iniciais e contêm os manifestos básicos do Kubernetes para os aplicativos em execução no Kubernetes na plataforma. Os operadores podem atualizar os manifestos nos modelos iniciais conforme necessário. As atualizações são recebidas quando um aplicativo é criado.
• Os arquivos cloudbuild.yaml e skaffold.yaml nesses repositórios armazenam as práticas recomendadas para executar CI e CD, respectivamente, na plataforma. Assim como nas configurações do aplicativo, os operadores podem atualizar e adicionar etapas às práticas recomendadas. Pipelines de aplicativos individuais são criados usando as etapas mais recentes.

Nesta implementação de referência, os operadores usam kustomize para gerenciar as configurações básicas na pasta k8s dos repositórios iniciais. Os desenvolvedores podem estender os manifestos com mudanças específicas do aplicativo, como nomes de recursos e arquivos de configuração. A ferramenta kustomize é compatível com a configuração como dados. Com esta metodologia, entradas e saídas kustomize são recursos do Kubernetes. Você pode usar as saídas de uma modificação dos manifestos para outra modificação.

O diagrama a seguir ilustra uma configuração básica para um aplicativo Spring Boot:

A configuração como modelo de dados em kustomize tem um grande benefício: quando os operadores atualizam a configuração base, as atualizações são consumidas automaticamente pelo pipeline de implantação do desenvolvedor na próxima execução, sem nenhuma alteração no do desenvolvedor.

Para mais informações sobre como usar o kustomize para gerenciar manifestos do Kubernetes, consulte a documentação de kustomize.

Repositórios de configuração e política

A arquitetura de referência inclui a implementação de um repositório de configurações e políticas que usa o Config Sync e o Controlador de Políticas. O repositório acm-gke-infrastructure-repo contém a configuração e as políticas implantadas em todos os clusters do ambiente de aplicativos. A configuração definida e armazenada por administradores de plataforma nesses repositórios é importante para garantir que a plataforma tenha uma aparência consistente para as equipes de operações e desenvolvimento.

Nas seções a seguir, explicamos detalhadamente como a arquitetura de referência implementa repositórios de configuração e política.

Configuração

Nesta implementação de referência, você usa o Config Sync para gerenciar centralmente a configuração de clusters na plataforma e aplicar políticas. O gerenciamento centralizado permite propagar alterações de configuração em todo o sistema.

Usando o Config Sync, sua organização pode registrar clusters para sincronizar a configuração deles com um repositório Git, um processo conhecido como GitOps. Quando novos clusters são adicionados, eles são sincronizados automaticamente com a configuração mais recente e reconciliam continuamente seu estado com base nessa configuração, caso sejam feitas alterações fora da banda.

Para mais informações sobre o Config Sync, consulte a documentação dele.

Política

Nesta implementação de referência, use o Controlador de Políticas, que é baseado no Open Policy Agent, para interceptar e validar cada solicitação para os clusters do Kubernetes na plataforma. É possível criar políticas usando a linguagem da política de Rego, que permite controlar totalmente os tipos de recursos enviados ao cluster, mas também a configuração deles.

A arquitetura no diagrama a seguir mostra um fluxo de solicitação para usar o Policy Controller para criar um recurso:

Você cria e define regras no repositório do Config Sync, e essas alterações são aplicadas ao cluster. Depois disso, as novas solicitações de recursos da CLI ou dos clientes de API são validadas em relação às restrições pelo Controlador de políticas.

Para mais informações sobre como gerenciar políticas, consulte a visão geral do Policy Controller.

Repositórios de infraestrutura

O documento contém uma implementação do repositório de infraestrutura usando o Terraform. O repositório gke-infrastructure-repo contém uma infraestrutura como código para criar clusters do GKE nos ambientes de desenvolvimento, teste e produção, além de configurar o Config Sync neles usando o repositório acm-gke-infrastructure-repo. gke-infrastructure-repo contém três ramificações, uma para cada ambiente de desenvolvimento, preparo e produção. Ele também contém pastas de desenvolvimento, preparo e produção em cada ramificação.

Analisar o pipeline e a infraestrutura

A arquitetura de referência cria um pipeline no projeto do Google Cloud. Esse pipeline é responsável por criar a infraestrutura compartilhada.

Pipeline

Nesta seção, você vai analisar o pipeline de infraestrutura como código e executá-lo para criar a infraestrutura compartilhada, incluindo clusters do GKE. O pipeline é um gatilho do Cloud Build chamado create-infra no projeto do Google Cloud vinculado ao repositório de infraestrutura gke-infrastructure-repo. Você segue a metodologia GitOps para criar a infraestrutura, conforme explicado no vídeo sobre ambientes repetíveis do GCP em escala com pipelines de infraestrutura como código do Cloud Build.

gke-infrastructure-repo tem ramificações de desenvolvimento, preparo e produção. No repositório, há também as pastas "dev", "staging" e "production" que correspondem a essas ramificações. Há regras de proteção de ramificação no repositório que garantem que o código só possa ser enviado para a ramificação de desenvolvimento. Para enviar o código para as ramificações de preparo e produção, é preciso criar uma solicitação de envio.

Normalmente, alguém com acesso ao repositório analisa as alterações e mescla a solicitação de envio para garantir que somente as mudanças pretendidas sejam promovidas para a ramificação superior. Para permitir que os indivíduos testem o blueprint, as regras de proteção de ramificação foram flexibilizadas na arquitetura de referência para que o administrador do repositório possa ignorar a revisão e mesclar a solicitação de envio.

Quando um push é feito para gke-infrastructure-repo, ele invoca o gatilho create-infra. Esse gatilho identifica a ramificação em que o push ocorreu e vai para a pasta correspondente no repositório dessa ramificação. Depois de encontrar a pasta correspondente, ele executa o Terraform usando os arquivos contidos nela. Por exemplo, se o código for enviado para a ramificação de desenvolvimento, o gatilho vai executar o Terraform na pasta de desenvolvimento da ramificação de dev para criar um cluster de desenvolvedor do GKE. Da mesma forma, quando um push acontece para a ramificação staging, o gatilho executa o Terraform na pasta de preparo da ramificação de preparo para criar um cluster de preparo do GKE.

Execute o pipeline para criar clusters do GKE:

1. No console do Google Cloud, acesse a página do Cloud Build.

   Acessar a página do Cloud Build

   • Há cinco gatilhos do webhook do Cloud Build. Procure o gatilho com o nome create-infra. Esse gatilho cria a infraestrutura compartilhada, incluindo clusters do GKE.

2. Clique no nome do acionador. A definição do acionador é aberta.

3. Clique em ABRIR O EDITOR para ver as etapas executadas pelo acionador.

   Os outros gatilhos são usados quando você integra um aplicativo em CI/CD moderna com o GKE: aplicar o fluxo de trabalho do desenvolvedor

   

4. No console do Google Cloud, acesse a página do Cloud Build.

   Acessar a página de gatilhos do Cloud Build

   Revise o pipeline presente na página do histórico. Quando você implantou a plataforma de entrega de software usando bootstrap.sh, o script enviou o código para a ramificação de desenvolvimento do repositório gke-infrastructure-repo que iniciou esse pipeline e criou o cluster dev do GKE.

5. Para criar um cluster de preparo do GKE, envie uma solicitação de envio da ramificação de dev para a de preparo:

   1. Acesse o GitHub e navegue até o repositório gke-infrastructure-repo.

   2. Clique em Solicitações de envio e em Nova solicitação de envio.

   3. No menu Base, escolha staging e no menu Compare, selecione dev.

   4. Clique em Criar solicitação de envio.

6. Se você for um administrador no repositório, mescle a solicitação de envio. Caso contrário, peça ao administrador para mesclar a solicitação de envio.

7. No console do Google Cloud, acesse a página Histórico do Cloud Build.

   Acessar a página de gatilhos do Cloud Build

   Um segundo pipeline do Cloud Build começa no projeto. Esse pipeline cria o cluster de preparo do GKE.

8. Para criar clusters do GKE de produção, envie um pull request do preparo para a ramificação de produção:

   1. Acesse o GitHub e navegue até o repositório gke-infrastructure-repo.

   2. Clique em Solicitações de envio e em Nova solicitação de envio.

   3. No menu Base, escolha prod e no menu Comparar, escolha staging.

   4. Clique em Criar solicitação de envio.

9. Se você for um administrador no repositório, mescle a solicitação de envio. Caso contrário, peça ao administrador para mesclar a solicitação de envio.

10. No console do Google Cloud, acesse a página Histórico do Cloud Build.

    Acessar a página de gatilhos do Cloud Build

    Um terceiro pipeline do Cloud Build começa no projeto. Esse pipeline cria o cluster de produção do GKE.

Infraestrutura

Nesta seção, você vai conhecer a infraestrutura criada pelos pipelines.

• No Console do Google Cloud, acesse a página de clusters do Kubernetes.

  Acessar a página de clusters do Kubernetes

  Nesta página, listamos os clusters usados para desenvolvimento (gke-dev-us-central1), preparo (gke-staging-us-central1) e produção ( gke-prod-us-central1, gke-prod-us-west1):

  

Cluster de desenvolvimento

O cluster de desenvolvimento (gke-dev-us-central1) permite que os desenvolvedores acessem um namespace que pode ser usado para iterar nos aplicativos. Recomendamos que as equipes usem ferramentas como o Skaffold, que fornece um fluxo de trabalho iterativo. Para isso, ele monitora ativamente o código em desenvolvimento e o reaplica aos ambientes de desenvolvimento conforme as alterações são feitas. Esse loop de iteração é semelhante à recarga dinâmica. No entanto, em vez de ser específico a uma linguagem de programação, o loop funciona com qualquer aplicativo que você possa criar com uma imagem do Docker. É possível executar o loop dentro de um cluster do Kubernetes.

Como alternativa, os desenvolvedores podem seguir a repetição de CI/CD de um ambiente de desenvolvimento. Esse loop faz com que as alterações no código fiquem prontas para promoção em ambientes superiores.

No próximo documento desta série, CI/CD moderno com GKE: aplicar o fluxo de trabalho do desenvolvedor, use o Skaffold e a CI/CD para criar o loop de desenvolvimento.

Cluster de preparo

Este cluster executa o ambiente de preparação dos seus aplicativos. Nesta arquitetura de referência, você cria um cluster do GKE para preparo. Normalmente, um ambiente de preparo é uma réplica exata do ambiente de produção.

Cluster de produção

Na arquitetura de referência, você tem dois clusters do GKE para seus ambientes de produção. Para sistemas de redundância geográfica ou de alta disponibilidade (HA, na sigla em inglês), recomendamos adicionar vários clusters a cada ambiente. Para todos os clusters em que os aplicativos são implantados, o ideal é usar clusters regionais. Essa abordagem isola os aplicativos das falhas no nível da zona e de todas as interrupções causadas por upgrades de pool de nós ou de cluster.

Para sincronizar a configuração dos recursos do cluster, como namespaces, cotas e RBAC, recomendamos o uso do Config Sync. Para mais informações sobre como gerenciar esses recursos, consulte Repositórios de configuração e política.

Aplicar a arquitetura de referência

Agora que você conhece a arquitetura de referência, pode explorar um fluxo de trabalho de desenvolvedor baseado nessa implementação. No próximo documento desta série, CI/CD moderno com Anthos: como aplicar o fluxo de trabalho do desenvolvedor, você irá criar um novo aplicativo, adicionar um recurso e, depois, implantar o aplicativo nos ambientes de preparação e produção.