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

Este guia descreve um conjunto de práticas recomendadas para a integração contínua e a entrega contínua (CI/CD) no Google Kubernetes Engine (GKE). Estas práticas abrangem uma vasta gama de tópicos, desde o controlo de fontes às estratégias de implementação. Estas práticas recomendadas são específicas do GKE e as práticas recomendadas gerais de CI/CD continuam a aplicar-se. Para mais informações, consulte os artigos Tecnologia de DevOps: integração contínua e Tecnologia de DevOps: entrega contínua.

Integração contínua

A integração contínua (IC) é uma prática em que os programadores integram todas as alterações de código novamente num ramo principal com a maior frequência possível. Destina-se a permitir falhas mais rápidas, expondo problemas o mais cedo possível no processo. Normalmente, os pipelines de CI são acionados por programadores que enviam alterações de código. O pipeline envolve passos para validar essas alterações, como a análise de erros, os testes e a compilação. Normalmente, um pipeline de CI produz um artefacto que pode implementar em fases posteriores do processo de implementação.

Crie pipelines que permitam uma iteração rápida

O tempo entre o momento em que um programador faz uma alteração ao código e o momento em que tem uma versão em execução da aplicação deve ser o mais curto possível. Esta velocidade é especialmente importante durante o desenvolvimento em ramificações de funcionalidades que envolvem uma iteração rápida por parte dos programadores. Idealmente, os seus pipelines de CI devem ser executados em menos de 10 minutos. Se tal não for possível, crie dois tipos de pipelines de CI:

  • Pipelines rápidas: normalmente, estas pipelines são executadas em 10 minutos ou menos. Estes pipelines destinam-se a ramificações de funcionalidades e não se destinam a ser abrangentes. Os pipelines rápidos podem resultar em artefactos instáveis.

  • Pipelines completos: estas pipelines podem demorar mais de 10 minutos a serem executadas e executam testes e verificações mais abrangentes. Os pipelines completos são executados em pedidos de união ou pedidos de obtenção, e commits para o ramo principal.

Teste as suas imagens de contentor

Como parte dos seus pipelines de IC, certifique-se de que executa todos os testes necessários no seu código e cria artefactos. Estes testes devem incluir testes de unidades, funcionais, de integração e de carga ou desempenho.

Também é importante testar a estrutura das imagens de contentores criadas. Testar a estrutura garante que todos os comandos são executados como esperado no interior do seu contentor. Os testes também permitem verificar se ficheiros específicos estão na localização correta e têm o conteúdo correto.

Para testar as suas imagens de contentores, pode usar a framework Container Structure Tests.

Estabeleça a segurança numa fase inicial dos pipelines

Tenha verificações de segurança e equilíbrios o mais cedo possível no ciclo de vida do desenvolvimento. Ao encontrar riscos de segurança antes de criar artefactos ou implementar, pode reduzir o tempo e o custo gastos na resolução destes riscos.

Para ajudar a alcançar a deteção precoce, pode implementar as seguintes medidas de segurança nos seus pipelines:

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

  • Implemente a análise estática de código e a lintagem numa fase inicial do pipeline. Estes testes ajudam a encontrar pontos fracos, como não escapar a entradas, aceitar dados de entrada não processados para consultas SQL ou vulnerabilidades no seu código.

  • Analise a imagem de contentor criada para verificar a existência de vulnerabilidades com a análise de vulnerabilidades.

  • Impedir a implementação de imagens que contenham vulnerabilidades nos seus clusters através da autorização binária. A autorização binária requer uma subscrição do GKE Enterprise. Para lhe oferecer maior confiança nas imagens produzidas, a autorização binária também lhe permite exigir atestados de diferentes entidades ou sistemas. Por exemplo, estas atestações podem incluir o seguinte:

    • Passou na análise de vulnerabilidades
    • Testes de CQ aprovados
    • Aprovação do proprietário do produto

Entrega contínua

A entrega contínua (EC) permite-lhe lançar código em qualquer altura. A CD opera no artefacto produzido por pipelines de CI. Os pipelines de CD podem ser executados durante muito mais tempo do que os pipelines de CI, especialmente se estiver a usar estratégias de implementação mais elaboradas, como implementações azul-verde.

Use a metodologia GitOps

O GitOps é o conceito de infraestrutura declarativa armazenada em repositórios Git e as ferramentas de CI/CD para implementar essa infraestrutura no seu ambiente. Quando usa uma metodologia GitOps, garante que todas as alterações às suas aplicações e clusters são armazenadas em repositórios de origem e estão sempre acessíveis.

A utilização de metodologias GitOps oferece-lhe as seguintes vantagens:

  • Pode rever as alterações antes de serem implementadas através de pedidos de união ou obtenção.
  • Tem uma única localização que pode usar para consultar o estado das suas aplicações e clusters em qualquer altura.
  • Os instantâneos dos seus clusters e aplicações facilitam a recuperação quando ocorrem falhas.

Algumas ferramentas comuns usadas para infraestrutura declarativa são o Terraform da Hashicorp e o Config Connector da Google Cloud. Para praticar a gestão de infraestrutura com o GitOps e outras ferramentas, experimente o tutorial Gerir a infraestrutura como código com o Terraform, o Cloud Build e o GitOps. Para saber como gerir aplicações ao estilo GitOps, experimente a entrega contínua ao estilo GitOps com o Cloud Build.

Promova imagens de contentores em vez de as reconstruir

As imagens de contentores não devem ser recriadas à medida que passam pelas diferentes fases de um pipeline de CI/CD. A recompilação pode introduzir pequenas diferenças nos ramos de código. Estas diferenças podem fazer com que a sua aplicação falhe na produção ou provocar a adição acidental de código não testado na imagem do contentor de produção. Para garantir que a imagem de contentor que testou é a imagem de contentor que implementa, é melhor criar uma vez e promover nos seus ambientes. Este conselho pressupõe que mantém a configuração específica do ambiente separada dos pacotes.

Pondere usar padrões de implementação e testes mais avançados

O GKE oferece-lhe a flexibilidade de implementar e testar as suas aplicações através de vários padrões. O padrão de implementação que escolher depende em grande medida dos objetivos da sua empresa. Por exemplo, pode ter de implementar alterações sem tempo de inatividade ou implementar alterações num ambiente ou num subconjunto de utilizadores antes de disponibilizar uma funcionalidade de forma geral.

Alguns dos diferentes padrões de implementação disponíveis incluem o seguinte:

  • Recriar uma implementação: reduz totalmente a escala da versão da aplicação existente antes de aumentar a escala da nova versão da aplicação.

  • Implementação de atualização progressiva: atualiza um subconjunto de instâncias da aplicação em execução em vez de atualizar todas as instâncias da aplicação em execução ao mesmo tempo. Em seguida, atualiza progressivamente mais instâncias da aplicação em execução até que todas estejam atualizadas.

  • Implementação azul/verde: implementa um conjunto paralelo adicional de instâncias nas instâncias de produção existentes com uma versão atualizada da sua aplicação. Muda o tráfego para as novas instâncias quando estiver tudo pronto para a implementação.

Clusters separados para diferentes ambientes

A separação de ambientes é uma consideração importante para qualquer destino de implementação. Idealmente, deve ter clusters separados para cada um dos seguintes ambientes:

  • Ambiente de desenvolvimento: neste ambiente, os seus programadores implementam aplicações para testes e experiências. Estas implementações requerem integração com outras partes da aplicação ou do sistema (por exemplo, uma base de dados). Normalmente, os clusters deste ambiente têm menos limites, e os programadores têm maior controlo sobre a configuração dos respetivos clusters.

  • Ambientes de pré-produção (teste ou controlo de qualidade): estes ambientes devem assemelhar-se o mais possível ao ambiente de produção. São usados para realizar testes em grande escala de alterações, como testes de integração, carregamento, desempenho ou regressão.

  • Ambiente de produção: este ambiente é onde as suas cargas de trabalho de produção e aplicações e serviços virados para o utilizador são executados.

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

Idealmente, os clusters de pré-produção são idênticos aos clusters de produção, mas, para fins de custos, podem ser réplicas reduzidas. Manter os clusters semelhantes garante que os testes são feitos nas mesmas condições ou em condições semelhantes às da produção. A paridade entre os clusters de pré-produção e produção também reduz a probabilidade de falhas inesperadas devido a diferenças ambientais quando implementa na produção.

A infraestrutura declarativa e o GitOps ajudam a alcançar uma paridade mais próxima dos seus ambientes porque pode duplicar mais facilmente a configuração do cluster subjacente. Para garantir que os seus ambientes têm condições semelhantes para políticas e configurações, também pode usar ferramentas como o Config Sync.

Prepare-se para falhas na produção

Nenhum teste pode garantir o comportamento adequado da sua aplicação em produção. As falhas podem ser causadas por casos extremos com dados que não foram considerados ou padrões de acesso dos seus utilizadores que não foram testados. É importante monitorizar a sua aplicação em produção e ter mecanismos de reversão e implementação automáticos para poder reagir e corrigir rapidamente erros ou interrupções. A utilização de estratégias de implementação mais robustas permite-lhe reduzir o impacto dos problemas e afetar menos utilizadores finais quando surgem problemas na produção.

Resumo da lista de verificação

A tabela seguinte resume as tarefas que recomendamos quando usa um pipeline de CI/CD no GKE:

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

O que se segue?