Neste documento, descrevemos um framework para implementar processos modernos de integração/entrega contínua (CI/CD) em uma plataforma de entrega de software com várias equipes que usa o Google Kubernetes Engine.
Assim, é possível iterar na plataforma para melhorar ainda mais o desempenho para desenvolvimento e operações, incluindo a velocidade de lançamento, a confiabilidade da plataforma e o tempo de recuperação contra falhas.
Este documento faz parte de uma série:
CI/CD moderno com GKE: um framework de entrega de software (este documento)
CI/CD moderno com o GKE: como criar um sistema de CI/CD (arquitetura de referência)
CI/CD moderno com GKE: como aplicar o fluxo de trabalho do desenvolvedor
Este documento destina-se a arquitetos corporativos e desenvolvedores de aplicativos, bem como a equipes de TI, DevOps e engenharia de confiabilidade do site. Ter alguma experiência com ferramentas e processos de implantação automatizados é útil para entender os conceitos apresentados neste documento.
Uma caso de CI/CD moderno
CI/CD é uma abordagem de desenvolvimento de software que permite automatizar as fases de criação, teste e implantação de desenvolvimento de software usando várias ferramentas e processos repetidos.
Além da automação de CI/CD, o Kubernetes e os contêineres permitiram que as empresas conseguissem melhorias sem precedentes na velocidade de desenvolvimento e implantação. Ainda assim, mesmo com a adoção do Kubernetes e do contêiner, muitas organizações não percebem os benefícios da velocidade de lançamento, estabilidade e eficiência operacional porque as práticas de CI/CD não aproveitam ao máximo o Kubernetes ou as soluções de problemas de segurança e operações
Uma abordagem de CI/CD realmente moderna precisa abranger mais do que apenas automação. Para realizar todas as melhorias de velocidade e segurança e usar o poder do Kubernetes e dos contêineres, você precisa simplificar a integração de aplicativos, as práticas de CI/CD e os processos operacionais.
Ao usar a infraestrutura consistente oferecida pela plataforma GKE, métodos uniformes de CI/CD e práticas recomendadas de implementação, sua organização pode ter os seguintes benefícios para desenvolvimento e operações:
Redução do tempo de lead para alterações.
Permita que as equipes de operações e segurança criem e atualizem práticas recomendadas para o provisionamento de aplicativos e a política de provisionamento em toda a plataforma.
Simplifique a integração de aplicativos, dando às equipes projetos funcionais e implantáveis que têm as práticas recomendadas da organização integradas.
Diminuir o tempo necessário para restaurar o serviço.
Gerencie toda a configuração de maneira declarativa usando o GitOps para auditoria, reversão e revisão simplificadas.
Padronize as metodologias de implantação e monitoramento em toda a organização para diminuir o tempo necessário para identificar os fatores de contribuição de um problema que afeta o serviço.
Aumento da frequência de implantação
Certifique-se de que os desenvolvedores de aplicativos possam iterar de maneira independente nos próprios sandboxs de desenvolvimento (ou zonas de destino) sem interferir entre si.
Use o GitOps para implantação, gerenciamento de versões aprimorado e controle de alterações.
Implementem vias de controle para que as equipes de serviço consigam implantar com frequência.
Crie um processo de lançamento progressivo para implantar consistentemente em ambientes de pré-produção, dando aos desenvolvedores a confiança de que precisam para implantar as alterações na produção.
Para ver como esses benefícios e conceitos são conseguidos com o GKE e o CI/CD, consulte os outros documentos desta série:
Avaliar a prontidão para uma abordagem moderna
Antes de implementar ferramentas e processos de CI/CD modernos com o GKE, você precisa avaliar se a organização e as equipes estão prontas para adotar uma nova plataforma.
Características da organização
A adoção de uma plataforma moderna exige a seguinte ajuda da sua liderança de negócios e das equipes técnicas:
Patrocinador de liderança. A adoção de uma plataforma de entrega de software geralmente é um grande esforço realizado por várias equipes multifuncionais. O processo geralmente resulta em alterações de papéis e responsabilidades, bem como em práticas de desenvolvimento de software. Para ser bem-sucedido na adoção dessas ferramentas e técnicas, você precisa de um forte suporte de um ou mais membros da equipe de liderança. Os patrocinadores de liderança mais eficazes são aqueles que veem essas alterações como um processo contínuo de melhoria e querem capacitar as equipes em vez de gerenciá-las.
Alinhamento de estratégias técnicas e de negócios. Recomendamos que suas equipes de negócios e equipes técnicas se alinhem às quatro principais medidas de entrega de software definidas pelo DevOps Research and Assessment (DORA): tempo de lead para alterações, frequência de implantação, tempo para restaurar o serviço e alterar a taxa de falha. Alinhar essas medidas oferece às equipes de negócios e às equipes técnicas uma meta comum, permitindo que elas calculem o retorno do investimento em conjunto, ajustem a taxa de mudança e modifiquem o nível de investimento.
Recursos. Para serem bem-sucedidas, as equipes que desenvolvem práticas modernas de CI/CD e criação de cadeias de ferramentas precisam dos recursos necessários: tempo, pessoas e infraestrutura. Essas equipes precisam de tempo para tentar selecionar os melhores processos e ferramentas. O ideal é que essas equipes representem muitas funções diferentes no processo de entrega de software e possam usar outros recursos de toda a organização. Por fim, as equipes precisam provisionar infraestrutura, incluindo recursos em nuvem e ferramentas de software.
Abertura para adotar novas ferramentas. As ferramentas e técnicas modernas de CI/CD geralmente vêm com novas ferramentas e processos. As equipes precisam testar esses processos e ferramentas e estar aberto para a adoção delas. Um loop de feedback é necessário para que as equipes de plataforma possam ouvir as equipes de aplicativos, operações e segurança que usam a plataforma.
Prontidão cultural. Para ser bem-sucedida na implantação e adoção de um sistema moderno de CI/CD com o GKE, a organização e as equipes técnicas que desenvolvem o sistema precisam estar preparadas para mudar o modo como elas operam e trabalham juntas. Por exemplo, as equipes de desenvolvimento e operações precisam estar dispostas a assumir mais responsabilidade por segurança, e as equipes de segurança e operações precisam estar dispostas a simplificar os processos de aprovação de mudanças.
Habilidades técnicas
A adoção de uma abordagem moderna de CI/CD também exige que suas equipes sejam preparadas tecnicamente das seguintes maneiras:
Use contêineres. As equipes que adotam abordagens modernas de CI/CD precisam de alguma experiência com contêineres. O ideal é que essa experiência inclua técnicas de desenvolvimento para criar imagens de contêiner e combinar contêineres para criar sistemas maiores.
Estratégia de integração contínua. As equipes precisam de experiência usando ferramentas de CI (como Jenkins, TeamCity, Bamboo e CircleCI) e executando alguma integração contínua e teste automatizado. Recomendamos que as organizações planejem como melhorar esses processos.
Automação de implantação. As equipes precisam de alguma experiência com a automação de implantação. Exemplos de ferramentas de implantação automatizadas incluem scripts de shell básicos, Terraform, Chef ou Puppet. Ter um conhecimento básico de processos e ferramentas de implantação automatizada é essencial para simplificar e automatizar implantações.
Arquiteturas orientadas a serviços. Embora não seja um pré-requisito para adotar processos modernos de CI/CD, a adoção de arquiteturas mais complexas e orientadas a serviços precisa ser uma meta de longo prazo das organizações que querem adotar as ferramentas e técnicas modernas de CI/CD com o GKE. São mostradas arquiteturas de serviço para melhorar a velocidade e a confiabilidade.
Controle de origem moderno. As ferramentas modernas de controle de origem, como o Git, permitem que as equipes estabeleçam fluxos de trabalho, como desenvolvimento baseado em troncos, ramificações de recursos e solicitações de mesclagem.
Criar CI/CD modernas com o GKE
Esta seção descreve uma plataforma de entrega de software e componentes dela. Para melhorar o desempenho da entrega de software, você precisa implementar CI/CD e outras práticas recomendadas técnicas que permitem às equipes lançar e operar de maneira eficiente.
Nesta seção, também abordamos a infraestrutura necessária para oferecer suporte ao ciclo de vida de entrega de software e como gerenciar essa infraestrutura de forma consistente com o GKE. Por fim, esta seção apresenta um exemplo de fluxo de trabalho de entrega de software e mostra como os repositórios iniciais simplificam a integração e a implementação de práticas recomendadas. As seguintes considerações de projeto são revisadas:
Plataforma de entrega de software. O framework e os recursos técnicos que compõem as bases de um processo de lançamento de aplicativos confiável e de alta velocidade.
Infraestrutura de plataforma. Os componentes da infraestrutura e as considerações de gerenciamento são necessários para criar a plataforma e executar seus aplicativos.
Fluxo de trabalho de entrega de software. Como as equipes trabalham juntas para criar, testar e implantar códigos com mais eficiência.
Repositórios de código. Repositórios que executam várias funções, incluindo armazenamento da lógica de negócios real, configuração específica do aplicativo e código para criar infraestrutura. Eles também podem ser repositórios iniciais que facilitam a adoção de práticas recomendadas e ajudam a manter a consistência entre os processos automatizados.
Zonas de destino do aplicativo. Entidade lógica que permite que os desenvolvedores implantem e iterem automaticamente os aplicativos usando os trilhos de segurança colocados.
Modelo de operação. Ferramentas, processos e métodos técnicos para gerenciar a infraestrutura e os aplicativos que compõem a plataforma.
Governança. Processos e considerações de que você precisa manter e gerenciar a plataforma de entrega de software.
Plataformas de envio de software
Uma plataforma de entrega de software unifica as ferramentas e simplifica os processos necessários para criar, entregar, implantar e operar aplicativos.
A responsabilidade de manter a configuração, a estabilidade, o tempo de execução e o escalonamento do aplicativo varia entre operadores, equipes de segurança e equipes de desenvolvedor. No entanto, todos os componentes e equipes precisam trabalhar juntos para acelerar os lançamentos. Neste documento, descrevemos métodos para melhorar o gerenciamento de controle de origem e a observabilidade do aplicativo, mas ele se concentra principalmente na integração contínua (CI), na entrega contínua (CD) e no gerenciamento da configuração.
Para criar uma plataforma de entrega de software completa, você precisa de cada componente no diagrama a seguir:
Cada um desses componentes fornece funcionalidade para o sistema e os aplicativos em execução na plataforma:
Monitoramento da infraestrutura. O nível básico de monitoramento necessário ao provisionar para verificar o funcionamento correto dos clusters do Google Kubernetes Engine (GKE), instâncias de máquina virtual (VM) e outras infraestruturas necessárias para que os aplicativos funcionem.
Orquestração de contêineres. A plataforma que coordena a implantação e a operação de aplicativos baseados em contêiner. Exemplos de plataformas para orquestração de contêineres são o Kubernetes, o GKE ou o GKE Enterprise.
Container Registry. Armazenamento e controle de acesso para imagens de contêiner.
CI. O processo de aplicação de tarefas automatizadas a um aplicativo antes da implantação. As tarefas de CI geralmente incluem criação, empacotamento e teste. Os tipos de tarefas variam de acordo com o aplicativo e a organização.
CD. Processos de implantação que são altamente automatizados e aplicados com alta frequência. Os exemplos de metodologias incluem aprovações manuais, implantação canário, implantação azul-verde ou implantação contínua.
Política. Políticas de configuração de segurança e infraestrutura definidas pelas equipes de operações e segurança e aplicadas e aplicadas continuamente pela plataforma.
Gerenciamento do código-fonte. Por exemplo, armazenamento controlado por versão para código, arquivos de configuração e definições de política. Em um sistema moderno de CI/CD, o gerenciamento de código-fonte normalmente é Git.
Gerenciamento de configurações. O sistema usado para armazenar e aplicar a configuração de aplicativos para diferentes ambientes.
Observabilidade do aplicativo. A geração de registros no nível do aplicativo, monitoramento, alerta e rastreamento que as equipes de desenvolvedores, operadores e segurança usam para solucionar problemas e verificar o funcionamento adequado dos aplicativos.
Infraestrutura de plataforma
Para criar uma plataforma escalonável de entrega de software, você precisa de clusters do Kubernetes para desenvolvimento, ambientes de pré-produção e vários clusters de produção. Os clusters podem oferecer muitas funções diferentes:
Desenvolvimento. Nesses clusters, os desenvolvedores realizam implantações ad hoc dos aplicativos para testes e experimentação.
O ambiente do aplicativo.
Pré-produção. Para cada ambiente de pré-produção no fluxo de trabalho, você precisa ter um cluster do Kubernetes para hospedar os aplicativos. Esses clusters precisam ser semelhantes aos clusters de produção para que você possa reduzir ou eliminar as diferenças entre os ambientes e, como resultado, melhorar as taxas de sucesso da implantação.
Produção. Esses clusters executam as cargas de trabalho de produção. Você precisa usar vários clusters distribuídos geograficamente. Isso melhora a confiabilidade de falhas de infraestrutura e facilita preocupações relacionadas às operações do segundo dia, como upgrades e escalonamento de clusters.
O diagrama a seguir mostra a arquitetura geral:
Nesta arquitetura, você gerencia os clusters para cada ambiente por meio do Config Sync. A configuração consistente do cluster é fundamental porque dá ao desenvolvedor, ao operador e às equipes de segurança a confiança de que os ambientes de pré-produção e produção operem de maneira semelhante. É possível usar o Config Sync para armazenar e aplicar configurações comuns em toda a frota de clusters. Depois que a configuração do cluster estiver padronizada, auditável e escalonável, você poderá se concentrar no fluxo de trabalho de entrega de software e na integração e implantação de aplicativos.
Você gerencia as implantações para clusters de desenvolvimento, preparo e produção por meio dos pipelines de CI/CD do aplicativo. O gerenciamento do controle de origem serve como ponto de coordenação para o código e a configuração do aplicativo. Os pipelines de CI/CD e as imagens de contêiner de um aplicativo são isolados no ambiente desse aplicativo. Inicialize os repositórios de aplicativos e de configuração usando repositórios iniciais e ferramentas automatizadas. Por exemplo, é possível usar o Cloud Build para executar o Terraform para integrar e inicializar novos aplicativos automaticamente.
Você implanta aplicativos nas próprias zonas de destino em cada cluster, para que os aplicativos sejam isolados de rede e identidade. Inicialize as zonas de destino do aplicativo nos ambientes usando o Config Sync. Em seguida, use o Anthos Service Mesh ou Ingress de vários clusters para fazer com que os clusters de produção pareçam um cluster criando uma malha de rede que abrange muitos clusters.
Fluxo de trabalho de envio do software
Um componente importante da plataforma de entrega de software é o sistema de CI/CD. Quando os criadores de plataformas começam a definir o processo de CI/CD, eles precisam garantir que cada componente produza ou consuma artefatos que obedeçam a uma interface padronizada. O uso de uma interface padronizada simplifica a substituição de componentes quando uma melhor implementação surgir no mercado.
Ao criar uma plataforma para aplicativos em contêiner, é possível usar as três interfaces padronizadas entre componentes: repositórios Git, imagens do Docker e manifestos do Kubernetes. Essas interfaces permitem criar um pipeline de CI/CD reutilizável e flexível com um fluxo de trabalho de desenvolvimento, criação e lançamento, como mostra o diagrama a seguir:
Esse fluxo de trabalho funciona da seguinte maneira:
Os desenvolvedores confirmam o código do aplicativo nos repositórios.
O sistema de CI testa o código, cria um artefato de imagem do Docker e armazena o artefato em um registro.
Depois que o artefato estiver pronto para implantação, uma referência para ele será adicionada à configuração do aplicativo.
Essa configuração de aplicativo é renderizada em um formato legível pelo Kubernetes e armazenada em um repositório de código. As atualizações deste repositório acionam um pipeline de implantação que implanta os artefatos em um ambiente de desenvolvimento integrado.
Após a conclusão dos testes no ambiente de desenvolvimento integrado, os operadores promovem a implantação no ambiente de pré-produção.
Depois de garantir que o aplicativo está funcionando como esperado no ambiente de pré-produção, os operadores recebem as aprovações no pipeline de implantação e promovem a versão para o ambiente de produção.
Quando os operadores fazem alterações nas configurações base, elas são aplicadas em toda a organização. Conforme os operadores executam as alterações nos repositórios, as atualizações de configuração do aplicativo (e as implantações subsequentes) podem ser acionadas automaticamente. Ou então, as alterações dos operadores podem ser detectadas na próxima vez que os desenvolvedores implantarem as alterações.
Paralelamente, os engenheiros de segurança podem implementar e ajustar políticas que definem o que pode ser implantado e, em seguida, confirmar essas políticas no repositório de políticas.
Com uma metodologia GitOps, é possível exigir uma abordagem declarativa para qualquer alteração nos aplicativos e clusters. Com essa abordagem, todas as alterações estão sujeitas à auditoria e revisão antes de serem aplicadas. Nesse modelo declarativo, você armazena os arquivos de configuração em um repositório Git. Isso permite que você mantenha um registro das alterações, reverta as implantações com falha e observe o possível impacto das alterações que estão sendo propostas.
Na
arquitetura de referência
associada, use
kustomize
para controlar as configurações do aplicativo na sua organização. A ferramenta
kustomize permite que os operadores criem bases chamadas de configurações de aplicativo que
as equipes de desenvolvimento possam ajustar sem precisar adicionar ou alterar qualquer código
na base. Ao definir configurações de base, as equipes de plataforma podem criar e iterar
sobre as práticas recomendadas para a organização. Operadores e desenvolvedores podem iterar nas
próprias implantações de maneira independente, com a aplicação das práticas recomendadas
pelos operadores. Quando os operadores precisam implementar uma nova prática recomendada para
a organização, eles fazem a alteração na base, e a mudança é
extraída automaticamente com a próxima implantação dos desenvolvedores.
Repositórios de código
Os repositórios de código-fonte são a base do sistema de CI/CD. Operadores, desenvolvedores e engenheiros de segurança têm repositórios próprios para propagar alterações na plataforma. Há vários benefícios em usar um repositório Git como base para todas as alterações no sistema:
Auditoria integrada. As confirmações contêm informações sobre quando, o que e quem alterou o sistema.
Um processo de reversão simplificado. A funcionalidade de reversão do Git permite reverter para um estado anterior do sistema.
Controle de versões. É possível marcar as confirmações do Git para indicar uma versão do estado do sistema.
Transações. Você precisa resolver explicitamente os conflitos de estado e analisá-los antes de integrar as alterações ao estado.
O diagrama a seguir mostra como várias equipes interagem com um repositório centralizado para todas as alterações:
As seções a seguir explicam como operadores, desenvolvedores e engenheiros de segurança utilizam o repositório Git em um sistema moderno de CI/CD.
Repositórios de operador
Os repositórios gerenciados por operadores contêm práticas recomendadas para CI/CD e configuração de aplicativo para ajudar suas equipes a integrar aplicativos, enquanto adotam as práticas recomendadas da organização desde o início. Com os operadores que gerenciam repositórios, os desenvolvedores podem consumir atualizações para as práticas recomendadas organizacionais com o mínimo de interrupção possível no fluxo de trabalho delas.
Os operadores podem codificar as práticas recomendadas da organização em dois repositórios. O primeiro repositório é onde os operadores mantêm as práticas recomendadas de pipeline de CI/CD compartilhadas. Neste repositório, os operadores fornecem aos desenvolvedores uma biblioteca de tarefas predefinidas que podem ser usadas para criar pipelines. Os repositórios de aplicativos dos desenvolvedores herdam automaticamente essas tarefas e a lógica dentro delas. As tarefas não precisam ser copiadas manualmente. Exemplos de tarefas que é possível padronizar em toda a organização incluem:
Criação e armazenamento de artefatos
Como testar metodologias para várias linguagens
Etapas da implantação
Verificações de política
Verificação de segurança
O segundo repositório que mantém os operadores armazena as práticas recomendadas para configurar um aplicativo. No contexto do GKE, as práticas recomendadas envolvem garantir uma maneira de gerenciar manifestos declarativos no modelo de recurso do Kubernetes. Esses manifestos descrevem o estado pretendido do aplicativo. Os operadores podem criar configurações de base para diferentes tipos de aplicativos, oferecendo aos desenvolvedores um caminho simplificado para a implantação de aplicativos de acordo com as práticas recomendadas organizacionais.
Repositórios de aplicativos
Os repositórios de aplicativos armazenam a lógica de negócios do aplicativo e qualquer configuração especializada necessária para que o aplicativo funcione corretamente.
Os operadores criam e mantêm práticas recomendadas de uma maneira coordenada, e os desenvolvedores podem usá-las. Para isso, os desenvolvedores fazem referência às tarefas de CI/CD e às bases de aplicativos criadas pelos operadores nos próprios repositórios. Depois que os desenvolvedores fazem as alterações, os operadores podem personalizar ainda mais a implantação do aplicativo ao adicionar configurações específicas do ambiente, como URLs de bancos de dados ou rótulos de recursos e anotações.
Os exemplos dos artefatos que podem ser armazenados nos repositórios de aplicativos incluem:
Código-fonte do aplicativo
Um
Dockerfileque descreve como criar e executar o aplicativoDefinição do pipeline de CI/CD
Extensões ou modificações nas bases de configuração do aplicativo criadas por operadores.
Infraestrutura como repositórios de código
Os repositórios de infraestrutura como código armazenam o código para criar a infraestrutura necessária para executar os aplicativos. A infraestrutura pode incluir plataformas de orquestração de redes e contêineres, como o GKE. Normalmente, esses repositórios pertencem aos administradores de infraestrutura. Os operadores podem atualizá-los para implementar as práticas recomendadas.
Os exemplos dos artefatos que podem ser armazenados nos repositórios de aplicativos incluem:
- Código de linguagem declarativa (Terraform, Pulumi) que representa objetos de infraestrutura.
Scripts shell ou Python que complementam as definições declarativas da API.
Extensões ou modificações nos modelos de infraestrutura base criados pela equipe de infraestrutura.
Repositórios de configuração e política
Garantir que uma plataforma aprimorada e consistente seja a prioridade mais importante para operadores e engenheiros de segurança.
Configuração
A configuração centralizada permite propagar alterações de configuração em todo o sistema. Alguns itens comuns de configuração que podem ser gerenciados centralmente incluem o seguinte:
Namespaces do Kubernetes
Cotas
Controles de acesso baseado em papéis (RBAC, na sigla em inglês)
Políticas de rede
Aplique consistentemente esses tipos de configurações em todos os clusters para que as equipes de aplicativo não façam uso indevido ou abuse da infraestrutura. Usar um repositório Git para armazenar a configuração pode aprimorar processos, como a auditoria e a implantação, por meio de métodos como o GitOps. Ferramentas como o Config Sync podem simplificar o processo de aplicar configurações de modo uniforme em toda a infraestrutura.
Política
Como os desenvolvedores podem estender as configurações básicas criadas pelos operadores, você precisa restringir os recursos criados nos clusters que compõem a plataforma. Em alguns casos, é possível criar uma política que permita aos desenvolvedores criar recursos somente se esses recursos atenderem a requisitos específicos, por exemplo, criar objetos de serviço do Kubernetes que não possam ser configurados para balanceamento de carga externo.
Na arquitetura de referência associada, use o Policy Controller para aplicar políticas.
Repositórios para iniciantes
Os repositórios iniciais ajudam na adoção de práticas recomendadas de CI/CD, infraestrutura e desenvolvimento em toda a plataforma. Os repositórios iniciais podem reduzir muito o custo associado à adoção de práticas recomendadas. As práticas recomendadas, por sua vez, ajudam a aumentar a velocidade, a confiabilidade e a produtividade da equipe. Na arquitetura de referência associada, há vários repositórios iniciais para CI, CD, configurações do Kubernetes, Go, Java e aplicativos e infraestrutura do Python iniciais.
Integração contínua
As organizações normalmente têm um conjunto padrão de tarefas aplicadas a aplicativos durante a CI. Por exemplo, na implementação de referência, o conjunto básico de estágios de CI é: compilar o código e criar uma imagem de contêiner. Como esses estágios são definidos no repositório inicial, eles são aplicados de maneira uniforme em toda a plataforma. As equipes de aplicativos individuais podem adicionar outras etapas.
Entrega contínua
Assim como a CI, o processo de CD normalmente tem um conjunto padrão de etapas para implantar aplicativos por meio de dev, ambientes de pré-produção e produção. Independentemente das metodologias de implantação utilizadas, o repositório inicial permite que as equipes de plataforma apliquem-as uniformemente em aplicativos e ambientes. Na implementação de referência, o processo de implantação inclui lançamentos para desenvolvimento, implantações de pré-produção, uma implantação de produção em vários clusters e aprovações manuais para a implantação de produção usando o Cloud Implantar.
Configuração do aplicativo
Para que uma plataforma de entrega de software seja eficaz, você precisa de uma maneira uniforme e
consistente para aplicar a configuração do aplicativo. Ao usar ferramentas como
kustomize e repositórios iniciais para as configurações do Kubernetes, as plataformas
podem fornecer uma base consistente para a configuração do aplicativo. Por exemplo, na
implementação de referência, a
configuração de base kustomize
inicializa os repositórios de ambiente de aplicativos com um conjunto básico de configurações
conhecidas. As equipes de aplicativos individuais podem adaptar as
configurações às necessidades.
Aplicativos iniciais
Os aplicativos iniciais podem ajudar a reduzir a sobrecarga associada à adoção de práticas recomendadas, por exemplo, observabilidade e práticas recomendadas para contêineres.
Observabilidade. Para operar com eficiência um aplicativo e ajudar a garantir a confiabilidade, os aplicativos precisam considerar a geração de registros, métricas e corridas. Os aplicativos para iniciantes ajudam as equipes a criar estruturas e estratégias que promovem a observabilidade.
Práticas recomendadas de contêiner. Ao desenvolver aplicativos em contêineres, crie imagens de contêiner pequenas e limpas. As práticas recomendadas para contêineres incluem empacotar um único aplicativo em uma imagem, remover ferramentas desnecessárias da imagem e tentar produzir imagens pequenas de imagens de base mínimas. Para mais informações, consulte Práticas recomendadas para criar contêineres.
A arquitetura de referência fornece um aplicativo Go básico, um aplicativo Java básico e um aplicativo Python básico como ponto de partida de dois minutos. É necessário adicionar aplicativos iniciais personalizados para linguagens, pilhas de tecnologia e tipos de aplicativo desenvolvidos por suas equipes.
Repositórios básicos de infraestrutura
Os repositórios iniciais de infraestrutura vêm com o código pré-escrito necessário para criar diferentes componentes de infraestrutura. Esses repositórios usam modelos e módulos padrão, conforme decidido pela equipe de infraestrutura.
Por exemplo, na implementação de referência, o platform-template contém o código inicial para criar um projeto do Google Cloud, uma nuvem privada virtual e um cluster do GKE. Esse modelo normalmente é usado por equipes de infraestrutura para gerenciar a infraestrutura usada por várias equipes de aplicativos como um recurso compartilhado. Da mesma forma, o infra-template contém um código básico de infraestrutura inicial que um aplicativo pode exigir, por exemplo, um banco de dados do Cloud Storage ou do Spanner. Normalmente, esse modelo é usado pelas equipes de aplicativos para gerenciar a infraestrutura dos aplicativos.
Repositórios de modelos compartilhados
Os repositórios de modelos compartilhados oferecem modelos de tarefas padrão que qualquer pessoa em uma organização pode reutilizar. Por exemplo, os módulos de infraestrutura como código, como módulos do Terraform, que podem ser usados para criar recursos de infraestrutura, como redes e computação.
Zonas de destino do aplicativo
Ao usar CI/CD compartilhado, configuração de aplicativo compartilhado e política e configuração consistentes nos clusters, é possível vincular esses recursos para criar zonas de destino do aplicativo.
Uma zona de destino é uma entidade lógica bloqueada que permite aos desenvolvedores implantar e iterar nos aplicativos. As zonas de destino do aplicativo usam os trilhos de segurança que você colocou para que os desenvolvedores possam operar de forma autônoma. Para cada aplicativo, você cria um namespace do Kubernetes em cada cluster de cada ambiente. Por exemplo, para produção, dev ou preparação. Essa consistência ajuda os operadores a depurar e manter os ambientes ao longo do tempo.
O diagrama a seguir ilustra o conceito de zonas de destino:
Modelo de operação
Ao operar uma plataforma de entrega de software com CI/CD moderno, é importante manter os ambientes, a infraestrutura e os processos consistentes e atualizados. Portanto, é preciso planejar e escolher cuidadosamente o modelo operacional para a plataforma. É possível escolher entre vários modelos, como clusters como um serviço, blueprints ou uma infraestrutura de vários locatários.
Como é importante manter uma infraestrutura consistente, limitar a expansão e permitir que as equipes se concentrem na entrega dos aplicativos, recomendamos a implantação de uma infraestrutura de vários locatários. A implantação de aplicativos em uma infraestrutura de multilocação elimina a necessidade de equipes de aplicativos gerenciarem infraestrutura e permite que as equipes de operador e segurança se concentrem em manter a infraestrutura consistente.
Considerações sobre a infraestrutura de vários locatários
Quando você cria uma plataforma de entrega de software multilocatário, há vários pontos que você pode considerar para usar na plataforma:
Isolamento da carga de trabalho. O conceito das zonas de destino do aplicativo é fornecer uma estrutura para isolar as cargas de trabalho. As zonas de destino são uma combinação de namespaces, políticas de rede e RBAC. Todas essas políticas devem ser gerenciadas e aplicadas centralmente por meio do Config Sync.
Monitoramento de uso de locatário. Para detalhar os custos de namespaces e rótulos individuais de um cluster, use a Medição de uso do GKE. A medição de uso do GKE rastreia informações sobre solicitações e uso de recursos para as cargas de trabalho de um cluster, que podem ser filtradas por namespaces e rótulos. Quando você ativa a medição de uso do GKE no cluster multilocatário, os registros de uso de recursos são gravados em uma tabela do BigQuery. É possível exportar métricas específicas de locatário para conjuntos de dados do BigQuery no projeto de locatário correspondente. Assim, os auditores podem analisar essas métricas para determinar detalhamentos de custos.
Cotas de recursos. Para garantir que todos os locatários que compartilham um cluster tenham acesso justo aos recursos do cluster, você precisa aplicar cotas de recursos. Crie uma cota de recursos para cada namespace de acordo com o número de pods implantados por cada locatário e a quantidade de memória e CPU necessárias para cada pod.
Vários clusters para cada ambiente. Para melhorar a confiabilidade do aplicativo e da plataforma, use vários clusters para cada ambiente de pré-produção e produção. Com vários clusters disponíveis, é possível lançar aplicativos individualmente para ter mais níveis de validação canário. Além disso, ter vários clusters facilita as preocupações relacionadas ao ciclo de vida do gerenciamento e dos upgrades de clusters.
Geração de registros e monitoramento específicos do locatário. Para investigar as operações dos aplicativos, os locatários precisam de acesso aos registros e métricas. Em um ambiente com vários locatários, a geração de registros e o monitoramento precisam ser específicos do aplicativo. Para métricas e monitoramento, é possível usar o Google Cloud Managed Service para Prometheus e o Grafana para cada namespace. Para registros, é preciso criar um coletor para exportar entradas de registro para conjuntos de dados do BigQuery e filtrar os conjuntos de dados por namespace de locatário. Os locatários podem acessar os dados exportados no BigQuery.
Para mais informações sobre uma infraestrutura de multilocação, consulte Práticas recomendadas para multilocatário empresarial.
Limites de isolamento
Uma plataforma de entrega de software é construída e usada por várias equipes, o que torna importante ter limites de isolamento adequados entre diferentes componentes da plataforma. Os limites de isolamento ajudam a criar uma plataforma robusta ao fornecer as seguintes características:
Dissociando responsabilidades. Cada equipe gerencia os recursos nos limites isolados sem se preocupar com o resto. Por exemplo, a equipe de infraestrutura é responsável apenas pela manutenção dos clusters do GKE. Os operadores ou desenvolvedores são responsáveis apenas pela manutenção dos pipelines de CI/CD e do código do aplicativo.
Controle de acesso granular. Se os recursos forem segregados por limites de isolamento, use o controle de acesso granular para limitar o acesso.
Reduz as áreas afetadas. Você pode fazer mudanças em um componente de maneira independente, sem afetar os outros.
Reduz erros manuais. Como o controle de acesso é granular, você pode evitar erros manuais, como fazer a implantação acidental em um cluster de produção a partir de um ambiente de desenvolvimento.
Esses limites de isolamento podem existir entre diferentes aplicativos, infraestruturas e aplicativos ou até mesmo entre os diferentes ambientes de um aplicativo.
Governança
O principal objetivo das plataformas de entrega de software e dos sistemas modernos de CI/CD é melhorar a eficiência do processo geral de entrega de software. Em relação ao gerenciamento da plataforma, você tem duas considerações principais: integração de aplicativos, que geralmente se enquadra na categoria de governança, desenvolvimento contínuo e manutenção da plataforma, ou seja, tratar a plataforma como um produto.
Integração e gerenciamento de aplicativos
O objetivo da adoção de ferramentas e metodologia modernas de CI/CD é simplificar o processo de lançamento e a integração de novos serviços. A integração de novos aplicativos precisa ser um processo simples que possa ser executado com uma quantidade mínima de entrada de equipes de operações e segurança. Isso não significa que as equipes de operações e segurança não estejam envolvidas, mas que a entrada inicial dessas equipes, de uma perspectiva de implantação e segurança, é gerenciada automaticamente pelo processo de provisionamento. Uma vez integradas, as equipes de operações e de segurança são naturalmente incluídas no processo de lançamento por meio de solicitações de mesclagem, atualizações de políticas e aplicação de práticas recomendadas.
É recomendável criar automação para integrar um novo aplicativo. Isso pode incluir a criação de repositórios de código, pipelines de CI/CD, zonas de destino e qualquer infraestrutura necessária para o aplicativo. A automação separa as dependências complexas das equipes de desenvolvimento de outras equipes da organização e oferece autonomia aos desenvolvedores para o autoatendimento de um aplicativo. Isso permite que os desenvolvedores comecem a iterar no código do aplicativo muito rapidamente e não percam tempo realizando outras tarefas além de escrever o código. A automação deve permitir que os desenvolvedores executem o aplicativo em um ambiente de desenvolvimento. Para levar o aplicativo a ambientes superiores, outras equipes precisam estar envolvidas e o processo de revisão deve ser seguido.
Na arquitetura de referência associada, essa automação é chamada de Application Factory.
Plataforma como produto
O fluxo de trabalho de CI/CD é um produto de software, exceto pelo fato de os usuários do produto serem equipes de desenvolvimento, operações e segurança. Sabendo disso, a plataforma requer os mesmos papéis e processos de desenvolvimento de software, como proprietários de produtos, marketing (ou seja, internamente), ciclos de feedback do usuário e ciclos de desenvolvimento de recursos.
Implantar CI/CD com o GKE
Quando você começa a implantar CI/CD moderno com GKE na organização, escolher os melhores aplicativos piloto é fundamental. As equipes de desenvolvimento, operações e segurança também precisam considerar outros fatores durante o trabalho, que são abordados nesta seção.
Como selecionar um aplicativo piloto
Escolher os primeiros aplicativos a serem transferidos para a plataforma pode ser uma primeira etapa difícil. Bons candidatos para pilotos são serviços que processam dados ou solicitações, mas não armazenam dados. Por exemplo, camadas de armazenamento em cache, front-ends da Web ou aplicativos de processamento baseados em eventos. Normalmente, esses aplicativos são mais resistentes a pequenas quantidades de erros de inatividade e implantação que podem ocorrer sempre que você trabalhar com novas técnicas de implantação e gerenciamento de configuração. Conforme as equipes adquirem mais experiência com CI/CD e começam a ter benefícios em confiabilidade e velocidade, comece a mover os serviços principais para a plataforma de entrega de software.
Considerações para desenvolvedores
Quando você trabalha em um processo de desenvolvimento de CI/CD moderno, recursos, alterações e implantações podem ocorrer com maior frequência e de forma mais assíncrona. As equipes de desenvolvimento precisam entender como as mudanças afetam os sistemas downstream ou dependentes e como essas mudanças são testadas. Os caminhos de comunicação entre as equipes de desenvolvimento, operações e segurança precisam ser fluidos. É recomendável investir em práticas melhores de controle de versões para aplicativos e contratos de dados usados pelos diferentes serviços. Além de aprimorar os métodos de comunicação e o controle de versão, a implementação de recursos em pequenas partes e a utilização de ramificações e sinalizações de recursos pode melhorar a forma como você testa e lança recursos.
Considerações do operador
Uma plataforma de entrega de software permite que as equipes de operações precisem trabalhar mais como equipes de desenvolvimento. Em vez de criar recursos voltados para fora, eles estão criando ferramentas e processos internos que facilitam o desenvolvimento, a implantação e a operação de aplicativos externos. As ferramentas da plataforma são usadas pela própria equipe e pelas equipes de desenvolvimento e segurança. Os operadores precisam criar ferramentas para auxiliar na implantação de novas versões de aplicativos e na reversão delas em caso de erros ou falhas na implantação. Os operadores também precisam dar mais ênfase à criação de sistemas de monitoramento e alerta para detectar proativamente falhas e alertas.
Considerações sobre a equipe de segurança
As equipes de segurança precisam trabalhar para que a segurança seja mais responsabilidade compartilhada entre elas e as equipes de operações e desenvolvimento. Esse padrão é comumente conhecido como mudança à esquerda em segurança, em que a segurança da informação (InfoSec) está envolvida no início do processo de desenvolvimento. Os desenvolvedores trabalham com ferramentas pré-aprovadas e os testes de segurança são automatizados. Além dessas técnicas, é possível definir e aplicar a política de segurança de maneira programática com o Controlador de Políticas. A combinação de técnicas e ferramentas coloca a aplicação de segurança em uma postura mais proativa.
A seguir
Tente implementar aspectos dessa arquitetura moderna de CI/CD.
Saiba mais sobre práticas recomendadas para configurar a federação de identidade.
Leia Kubernetes e os desafios da entrega contínua de software.
Leia sobre padrões de monitoramento e geração de registros de ambientes híbridos e de várias nuvens.