Práticas recomendadas para entrega e integração contínuas no Google Kubernetes Engine

Neste guia, descrevemos um conjunto de práticas recomendadas para entrega e integração contínuas (CI/CD, na sigla em inglês) ao Google Kubernetes Engine (GKE). Essas práticas abrangem vários tópicos, do controle de origem às estratégias de implantação. Elas são específicas do GKE e as recomendações gerais para CI/CD ainda se aplicam. Para mais informações, consulte Tecnologia de DevOps: integração contínua e Tecnologia de DevOps: entrega contínua.

Integração contínua

A integração contínua (CI) é uma prática em que os desenvolvedores integram todas as alterações de código em uma ramificação principal sempre que possível. Ela tem o objetivo de acelerar falhas, expondo problemas o quanto antes no processo. Os pipelines de CI geralmente são acionados por desenvolvedores que enviam alterações de código. O pipeline envolve etapas para validar essas alterações, como inspeção, teste e criação. Um pipeline de CI normalmente produz um artefato que pode ser implantado em estágios posteriores do processo de implantação.

Crie pipelines que permitam iteração rápida

O tempo entre o momento em que um desenvolvedor faz uma alteração de código e que você tem uma versão do aplicativo em execução precisa ser o mais curto possível. Essa velocidade é especialmente importante durante o desenvolvimento de ramificações de recursos que envolve iteração rápida dos desenvolvedores. O ideal é que os pipelines de CI sejam executados em menos de 10 minutos. Se isso não for possível, crie dois tipos de pipeline de CI:

  • Pipelines rápidos: esses pipelines geralmente são executados em 10 minutos ou menos. Eles são destinados a ramificações de recursos e não são abrangentes. Pipelines rápidos podem resultar em artefatos instáveis.

  • Pipelines completos: podem demorar mais de 10 minutos para serem executados e executam testes e verificações mais abrangentes. Os pipelines completos são executados em solicitações de envio ou de mesclagem e confirmam a ramificação principal.

Teste as imagens de contêiner

Como parte dos pipelines de CI, verifique se você executou todos os testes necessários no código e artefatos criados. Eles precisam incluir testes de unidade, funcional, integração e carga ou desempenho.

Também é importante testar a estrutura das imagens de contêiner criadas. Testar a estrutura garante que todos os comandos sejam executados conforme o esperado dentro do seu contêiner. Os testes também permitem verificar se arquivos específicos estão no local certo e têm o conteúdo correto.

Para testar suas imagens de contêiner, use o framework de testes de estrutura de contêiner.

Estabeleça a segurança previamente nos pipelines

Faça verificações de segurança e balanceamentos o mais cedo possível no ciclo de vida de desenvolvimento. Quando se encontra riscos de segurança antes de criar artefatos ou implantar, é possível reduzir o tempo e o custo para resolvê-los.

Para garantir essa detecção precoce, você pode implementar as seguintes medidas de segurança nos pipelines:

  • Exija que especialistas no assunto analisem qualquer código integrado ao seu repositório de produção.

  • Implemente a inspeção e a análise de código estático no pipeline. Esses testes ajudam a detectar pontos fracos, como escape de entradas, dados de entrada brutos para consultas SQL ou vulnerabilidades no seu código.

  • Verifique se há vulnerabilidades na imagem do contêiner com a verificação de vulnerabilidades.

  • Evite que imagens com vulnerabilidades sejam implantadas nos clusters usando a autorização binária. A autorização binária requer uma assinatura do GKE Enterprise. Para fornecer maior confiança nas imagens produzidas, a autorização binária também exige atestados por diferentes entidades ou sistemas. Por exemplo, esses atestados podem incluir o seguinte:

    • Aprovado na verificação de vulnerabilidades
    • Aprovado no teste de controle de qualidade
    • Assinatura do proprietário do produto

Entrega contínua

A entrega contínua (CD) permite que você libere o código a qualquer momento. A CD opera no artefato produzido pelos pipelines de CI. Os pipelines de CD podem ser executados por muito mais tempo do que os pipelines de CI, especialmente se você estiver usando estratégias de implantação mais elaboradas, como implantação azul-verde.

Use a metodologia GitOps

GitOps é o conceito de infraestrutura declarativa armazenada nos repositórios Git e as ferramentas de CI/CD para implantar essa infraestrutura no ambiente. Ao usar uma metodologia GitOps, você garante que todas as alterações nos seus aplicativos e clusters sejam armazenadas em repositórios de origem e estejam sempre acessíveis.

O uso de metodologia de GitOps oferece as seguintes vantagens:

  • É possível revisar as alterações antes de serem implantadas por meio de solicitações de mesclagem ou envio.
  • Você tem um único local que pode ser usado para consultar a qualquer momento o estado dos seus aplicativos e clusters.
  • Os snapshots dos clusters e os aplicativos facilitam a recuperação quando há falhas.

Para saber mais sobre a metodologia GitOps e os diferentes padrões que podem ser usados nos repositórios de origem, consulte Conceitos do GitOps.

Algumas ferramentas comuns usadas para infraestrutura declarativa são o Terraform da Hashicorp e o Config Connector do Google Cloud. Para praticar o gerenciamento da infraestrutura com GitOps e outras ferramentas, consulte o tutorial Como gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps. Para saber como gerenciar aplicativos no estilo GitOps, teste a entrega contínua no estilo GitOps com o Cloud Build.

Promova, em vez de recriar imagens de contêiner

As imagens do contêiner não devem ser recompiladas enquanto passam pelos diferentes estágios de um pipeline de CI/CD. A recriação pode introduzir pequenas diferenças em ramificações de código. Essas diferenças podem causar falhas no aplicativo na produção ou provocar a adição acidental de código não testado à imagem do contêiner de produção. Para garantir que a imagem do contêiner testada seja a que você implanta, é melhor criá-la uma vez e promovê-la nos seus ambientes. Isso pressupõe que você está mantendo uma configuração específica do ambiente separada dos pacotes.

Use padrões de implantação e teste mais avançados

O GKE oferece a flexibilidade para implantar e testar seus aplicativos usando vários padrões. O padrão de implantação depende muito das metas de negócios. Por exemplo, talvez seja necessário implantar alterações sem tempo de inatividade ou em um ambiente ou subconjunto de usuários antes de disponibilizar um recurso para todos eles.

Estes são alguns dos diferentes padrões de implantação disponíveis:

  • Recriação de uma implantação: reduza totalmente a versão atual do aplicativo antes de escalonar a nova.

  • Implantação de atualização gradual: você atualiza um subconjunto de instâncias do aplicativo em execução, em vez de atualizar todas ao mesmo tempo. Depois, atualiza progressivamente outras instâncias até que todas sejam atualizadas.

  • Implantação azul-verde: implante um conjunto paralelo adicional de instâncias nas instâncias de produção existentes com uma versão atualizada do aplicativo. E passe o tráfego para as novas instâncias quando estiver pronto para implantar.

Separe os clusters por diferentes ambientes

A separação de ambientes é uma consideração importante para qualquer destino de implantação. O ideal é ter clusters separados para cada um dos ambientes a seguir:

  • Ambiente de desenvolvimento: é onde seus desenvolvedores implantam aplicativos para testes e experimentação. Essas implantações exigem integração com outras partes do aplicativo ou sistema (por exemplo, um banco de dados). Os clusters desse ambiente geralmente têm menos portões, e os desenvolvedores têm um controle maior sobre a configuração do cluster.

  • Ambientes de pré-produção (preparo ou controle de qualidade): esses ambientes precisam ser os mais parecidos possível. Eles são usados para executar testes de alterações em larga escala como testes de integração, carga, desempenho ou regressão.

  • Ambiente de produção: é onde são executadas as cargas de trabalho da produção e aplicativos e serviços voltados para o usuário.

Para saber mais sobre esses ambientes, consulte a seção Ambientes no Kubernetes e os desafios da entrega contínua de software.

Mantenha os ambientes de pré-produção próximos à produção

O ideal é que os clusters de pré-produção sejam idênticos aos clusters de produção. No entanto, por questão de custos, os clusters de pré-produção podem ter réplicas reduzidas. Manter os clusters iguais garante que qualquer teste seja feito nas mesmas condições ou em condições parecidas com as da produção. A paridade entre clusters de pré-produção e de produção também reduz a probabilidade de falhas inesperadas devido a diferenças ambientais quando você implanta na produção.

A infraestrutura declarativa e o GitOps ajudam você a conseguir uma paridade mais próxima dos seus ambientes, porque é possível duplicar a configuração do cluster subjacente com mais facilidade. Para garantir que seus ambientes tenham condições semelhantes para políticas e configurações, também é possível usar ferramentas como o Config Sync.

Prepare-se para falhas na produção

Nenhuma quantidade de testes pode garantir o comportamento adequado do aplicativo em produção. As falhas podem ser causadas por casos extremos com dados que não foram considerados ou padrões não testados de acesso dos usuários. É importante monitorar seu aplicativo em produção e ter mecanismos de reversão e implantação automatizados para reagir com rapidez e corrigir bugs ou interrupções. O uso de estratégias de implantação mais robustas permite reduzir o impacto dos problemas e afetar um número menor de usuários finais quando surgem problemas na produção.

Lista de verificação resumida

A tabela a seguir resume as tarefas que recomendamos ao usar um pipeline de CI/CD no GKE:

Área Tarefas
Integração contínua
Entrega contínua

A seguir