Este documento descreve uma estrutura para implementar processos de integração contínua/entrega contínua (CI/CD) modernos numa plataforma de entrega de software de várias equipas que usa o Google Kubernetes Engine.
Em seguida, pode iterar na plataforma para melhorar ainda mais o desempenho do desenvolvimento e das operações, incluindo a velocidade de lançamento, a fiabilidade da plataforma e o tempo de recuperação de falhas.
Este documento faz parte de uma série:
CI/CD moderno com o GKE: uma framework de entrega de software (este documento)
CI/CD moderno com o GKE: crie um sistema de CI/CD (arquitetura de referência)
CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador
Este documento destina-se a arquitetos empresariais e programadores de aplicações, bem como a equipas de segurança de TI, DevOps e engenharia de fiabilidade do site. Alguma experiência com ferramentas e processos de implementação automatizados é útil para compreender os conceitos neste documento.
Um argumento a favor da CI/CD moderna
A CI/CD é uma abordagem de desenvolvimento de software que lhe permite automatizar as fases de compilação, teste e implementação do desenvolvimento de software através de várias ferramentas e processos repetíveis.
Além da automatização da CI/CD, o Kubernetes e os contentores permitiram que as empresas alcançassem melhorias sem precedentes na velocidade de desenvolvimento e implementação. No entanto, mesmo à medida que a adoção do Kubernetes e dos contentores aumenta, muitas organizações não se apercebem totalmente das vantagens em termos de velocidade de lançamento, estabilidade e eficiências operacionais, porque as respetivas práticas de CI/CD não tiram total partido do Kubernetes nem abordam as preocupações de operações e segurança.
Uma abordagem de CI/CD verdadeiramente moderna tem de abranger mais do que apenas a automatização. Para tirar o máximo partido das melhorias na velocidade e segurança, e usar o poder do Kubernetes e dos contentores, tem de simplificar a integração de aplicações, as práticas de CI/CD e os processos operacionais.
Ao usar a infraestrutura consistente oferecida pela plataforma GKE, os métodos de CI/CD uniformes e as práticas recomendadas na implementação, a sua organização pode obter as seguintes vantagens para o desenvolvimento e as operações:
Reduzir o tempo de processamento das alterações.
Permita que as equipas de operações e segurança criem e atualizem as práticas recomendadas para o aprovisionamento de aplicações e a política de aprovisionamento na plataforma.
Simplifique a integração de aplicações oferecendo às equipas projetos iniciais totalmente funcionais e implementáveis que tenham as práticas recomendadas da sua organização incorporadas.
Diminuir o tempo necessário para restaurar o serviço.
Faça a gestão de toda a configuração de forma declarativa através do GitOps para uma auditoria, uma reversão e uma revisão simplificadas.
Padronize as metodologias de implementação e monitorização em toda a organização para diminuir o tempo necessário para identificar os fatores que contribuem para um problema que afeta o serviço.
Aumentar a frequência de implementação.
Certifique-se de que os programadores de aplicações podem iterar independentemente nas respetivas sandboxes de desenvolvimento (ou zonas de destino) sem interferir uns com os outros.
Use o GitOps para a implementação, a gestão de lançamentos melhorada e o acompanhamento de alterações.
Implemente restrições para que as equipas de serviços possam fazer implementações com frequência.
Crie um processo de implementação progressiva para implementar de forma consistente em ambientes de pré-produção, dando aos programadores a confiança de que precisam para implementar alterações na produção.
Para ver como estas vantagens e conceitos se concretizam com o GKE e a CI/CD, consulte os outros documentos desta série:
Avalie a prontidão para uma abordagem moderna
Antes de implementar ferramentas e processos de CI/CD modernos com o GKE, tem de avaliar se a sua organização e equipas estão prontas para adotar uma nova plataforma.
Traits organizacionais
A adoção de uma plataforma moderna requer o seguinte apoio por parte da liderança e das equipas técnicas da sua empresa:
Patrocinador da liderança. A adoção de uma plataforma de entrega de software é normalmente um grande esforço realizado por várias equipas multifuncionais. Normalmente, o processo resulta em alterações nas funções e responsabilidades, bem como nas práticas de desenvolvimento de software. Para ter sucesso na adoção destas ferramentas e técnicas, precisa de um forte apoio técnico de um ou mais membros da equipa de liderança. Os patrocinadores da liderança mais eficazes são aqueles que veem estas alterações como um processo contínuo de melhoria e querem capacitar as suas equipas em vez de as gerir.
Alinhamento técnico e da estratégia empresarial. Recomendamos que as suas equipas empresariais e técnicas se alinhem nas quatro principais medidas de entrega de software definidas pela DevOps Research and Assessment (DORA): tempo de processamento de alterações, frequência de implementação, tempo de restauro do serviço e taxa de falhas de alterações. O alinhamento com essas medidas dá às equipas empresariais e técnicas um objetivo comum, o que lhes permite calcular em conjunto o retorno do investimento, ajustar a taxa de alteração e modificar o nível de investimento.
Recursos. Para ter sucesso, as equipas que desenvolvem práticas de CI/CD modernas e criam cadeias de ferramentas precisam dos recursos necessários: tempo, pessoas e infraestrutura. Estas equipas precisam de tempo para experimentar e selecionar os melhores processos e ferramentas. Idealmente, estas equipas representam muitas funções diferentes no processo de entrega de software e podem usar outros recursos de toda a organização. Por último, as equipas precisam da capacidade de aprovisionar infraestrutura, incluindo recursos na nuvem e ferramentas de software.
Abertura à adoção de novas ferramentas. As ferramentas e as técnicas de CI/CD modernas incluem frequentemente novas ferramentas e processos. As equipas têm de experimentar esses processos e ferramentas e estar abertas à sua adoção. É necessário um ciclo de feedback para que as equipas da plataforma possam receber feedback das equipas de aplicações, operações e segurança que estão a usar a plataforma.
Disposição cultural. Para ter êxito na implementação e adoção de um sistema de CI/CD moderno com o GKE, a organização e as equipas técnicas que desenvolvem o sistema têm de estar preparadas para alterar a forma como operam e trabalham em conjunto. Por exemplo, as equipas de desenvolvimento e operações têm de estar dispostas a assumir mais responsabilidade pela segurança, e as equipas de segurança e operações têm de estar dispostas a simplificar os processos de aprovação de alterações.
Capacidades técnicas
A adoção de uma abordagem de CI/CD moderna também requer que as suas equipas estejam tecnicamente preparadas das seguintes formas:
Experiência com contentores. As equipas que estão a adotar abordagens de CI/CD modernas precisam de alguma experiência com contentores. Idealmente, esta experiência inclui técnicas de desenvolvimento para criar imagens de contentores e combinar contentores para criar sistemas maiores.
Estratégia de integração contínua. As equipas precisam de alguma experiência na utilização de ferramentas de CI (como Jenkins, TeamCity, Bamboo e CircleCI) e na realização de alguma integração contínua e testes automatizados. Recomendamos que as organizações planeiem como melhorar ainda mais esses processos.
Automatização da implementação. As equipas precisam de alguma experiência com a automatização da implementação. Os exemplos de ferramentas de implementação automatizadas incluem scripts de shell básicos, o Terraform, o Chef ou o Puppet. Ter conhecimentos básicos de ferramentas e processos de implementação automatizados é fundamental para simplificar e automatizar as implementações.
Arquiteturas orientadas para serviços. Embora não seja um pré-requisito para a adoção de processos de CI/CD modernos, a adoção de arquiteturas mais modulares e orientadas para serviços tem de ser um objetivo a longo prazo das organizações que querem adotar ferramentas e técnicas de CI/CD modernas com o GKE. Foi demonstrado que as arquiteturas baseadas em serviços melhoram a velocidade e a fiabilidade.
Controlo de origem moderno. As ferramentas de controlo de origem modernas, como o Git, permitem que as equipas estabeleçam fluxos de trabalho, como o desenvolvimento baseado no tronco, ramificações de funcionalidades e pedidos de união.
Crie CI/CD moderno com o GKE
Esta secção descreve uma plataforma de fornecimento de software e os respetivos componentes. Para melhorar o desempenho da entrega de software, tem de implementar a CI/CD e outras práticas recomendadas técnicas que permitam às equipas fazer lançamentos rapidamente e operar de forma eficiente.
Esta secção também aborda a infraestrutura necessária para suportar o ciclo de vida de entrega de software e como gerir essa infraestrutura de forma consistente com o GKE. Por último, esta secção fornece 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 design são revistas:
Plataforma de fornecimento de software. A estrutura e as capacidades técnicas que constituem as bases de um processo de lançamento de aplicações fiável e de alta velocidade.
Infraestrutura da plataforma. Os componentes de infraestrutura e as considerações de gestão de que precisa para criar a plataforma e executar as suas aplicações.
Fluxo de trabalho de envio de software. Como as equipas trabalham em conjunto para criar, testar e implementar código de forma mais eficiente.
Repositórios de código. Repositórios que executam várias funções, incluindo o armazenamento da lógica de negócio real, a configuração específica da aplicação e o código para criar infraestrutura. Também podem ser repositórios iniciais que facilitam a adoção de práticas recomendadas e ajudam a manter a consistência nos processos automatizados.
Zonas de destino da aplicação. Entidade lógica que permite aos programadores implementar e iterar autonomamente nas respetivas aplicações através das restrições que implementar.
Modelo de funcionamento. Ferramentas, processos e métodos técnicos para gerir a infraestrutura e as aplicações que compõem a plataforma.
Governação. Processos e considerações que tem de manter e gerir na plataforma de entrega de software.
Plataformas de fornecimento de software
Uma plataforma de entrega de software unifica as ferramentas e simplifica os processos necessários para criar, entregar, implementar e operar aplicações.
A responsabilidade pela manutenção da configuração, da estabilidade, do tempo de atividade e da escala de uma aplicação varia entre os operadores, a segurança e as equipas de programadores, mas todos os componentes e equipas têm de trabalhar em conjunto para acelerar os lançamentos. Embora este documento descreva métodos para melhorar a gestão do controlo de origem e a observabilidade das aplicações, centra-se principalmente na integração contínua (IC), na implementação contínua (IC) e na gestão da configuração.
Para criar uma plataforma de distribuição de software completa, precisa de cada componente no seguinte diagrama:
Cada um destes componentes oferece funcionalidades ao sistema e às aplicações em execução na plataforma:
Monitorização da infraestrutura. O nível base de monitorização necessário ao aprovisionar para validar o funcionamento correto dos clusters do Google Kubernetes Engine (GKE), das instâncias de máquinas virtuais (VMs) e de outra infraestrutura necessária para o funcionamento das aplicações.
Orquestração de contentores. A plataforma que coordena a implementação e o funcionamento de aplicações baseadas em contentores. Exemplos de plataformas para orquestração de contentores: Kubernetes, GKE ou GKE Enterprise.
Container Registry. O armazenamento e o controlo de acesso para imagens de contentores.
CI. O processo de aplicação de tarefas automatizadas a uma aplicação antes da implementação. Normalmente, as tarefas de CI incluem a criação, a embalagem e os testes. Os tipos de tarefas variam consoante a aplicação e a organização.
CD. Processos de implementação altamente automatizados e aplicados com alta frequência. Alguns exemplos de metodologias incluem aprovações manuais, implementações canary, implementações azul-verde ou implementações contínuas.
Política. Políticas de configuração de segurança e infraestrutura definidas pelas equipas de operações e segurança, e aplicadas e impostas continuamente pela plataforma.
Gestão do código-fonte. Por exemplo, armazenamento com controlo de versões para código, ficheiros de configuração e definições de políticas. Num sistema de CI/CD moderno, a gestão do código fonte é normalmente feita com o Git.
Gestão da configuração. O sistema usado para armazenar e aplicar a configuração da aplicação para diferentes ambientes.
Observabilidade das aplicações. O registo ao nível da aplicação, a monitorização, os alertas e o rastreio que as equipas de programadores, operadores e segurança usam para resolver problemas e validar o funcionamento adequado das aplicações.
Infraestrutura da plataforma
Para criar uma plataforma de entrega de software escalável, precisa de clusters do Kubernetes para o desenvolvimento, ambientes de pré-produção e vários clusters de produção. Os clusters podem servir muitas funções diferentes:
Desenvolvimento. Nestes clusters, os programadores fazem implementações ad hoc das respetivas aplicações para testes e experiências.
O ambiente da aplicação.
Pré-produção. Para cada ambiente de pré-produção no seu fluxo de trabalho, deve ter um cluster do Kubernetes para alojar as suas aplicações. Estes clusters devem ser semelhantes aos clusters de produção para que possa reduzir ou eliminar as diferenças entre os ambientes e, como resultado, melhorar as taxas de êxito da implementação.
Produção. Estes clusters executam as suas cargas de trabalho de produção. Deve usar vários clusters distribuídos geograficamente. Ao fazê-lo, melhora a fiabilidade em caso de falhas de infraestrutura e facilita as preocupações de operações do dia 2, como atualizações e dimensionamento de clusters.
O diagrama seguinte mostra a arquitetura de alto nível:
Nesta arquitetura, gere os clusters de cada ambiente através do Config Sync. A configuração consistente do cluster é fundamental porque dá confiança às equipas de programadores, operadores e segurança de que os ambientes de pré-produção e produção funcionam de forma semelhante. Pode usar o Config Sync para armazenar e aplicar configurações comuns na sua frota de clusters. Depois de a configuração do cluster ser padronizada, auditável e escalável, pode concentrar-se no fluxo de trabalho de entrega de software, bem como na integração e implementação de aplicações.
Faz a gestão das suas implementações em clusters de desenvolvimento, preparação e produção através dos pipelines de CI/CD da aplicação. A gestão do controlo de origem serve como ponto de coordenação para o código e a configuração da aplicação. Os pipelines de CI/CD e as imagens de contentores de uma aplicação estão isolados no ambiente dessa aplicação. Inicializa os repositórios de aplicações e de configuração através de repositórios iniciais e ferramentas automatizadas. Por exemplo, pode usar o Cloud Build para executar o Terraform para integrar e inicializar novas aplicações automaticamente.
Implementa aplicações nas respetivas zonas de destino em cada cluster, para que as aplicações estejam isoladas da rede e da identidade. Inicializa as zonas de destino das aplicações em todos os ambientes através da sincronização de configuração e usa o Cloud Service Mesh ou o Multi Cluster Ingress para fazer com que os clusters de produção pareçam um cluster criando uma malha de rede que abranja muitos clusters.
Fluxo de trabalho de entrega de software
Um componente essencial 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, têm de garantir que cada componente produz ou consome artefactos que cumprem uma interface padronizada. A utilização de uma interface padronizada simplifica a substituição de componentes quando é disponibilizada uma melhor implementação no mercado.
Quando cria uma plataforma para aplicações em contentores, pode usar as três interfaces padronizadas entre componentes: repositórios Git, imagens Docker e manifestos Kubernetes. Estas interfaces permitem-lhe criar um pipeline de CI/CD reutilizável e flexível com um fluxo de trabalho de desenvolvimento, compilação e lançamento, conforme mostra o seguinte diagrama:
Este fluxo de trabalho funciona da seguinte forma:
Os programadores comprometem o código da aplicação com os repositórios de código.
O sistema de CI testa o código, cria um artefacto de imagem Docker e armazena o artefacto num registo.
Depois de o artefacto estar pronto para implementação, é adicionada uma referência ao mesmo à configuração da aplicação.
Essa configuração da aplicação é renderizada num formato legível por Kubernetes e armazenada num repositório de código. As atualizações a este repositório acionam um pipeline de implementação que implementa os artefactos num ambiente de desenvolvimento integrado.
Após a conclusão dos testes no ambiente de programação integrado, os operadores promovem a implementação para o ambiente de pré-produção.
Depois de se certificar de que a aplicação está a funcionar como esperado no ambiente de pré-produção, os operadores obtêm as aprovações no pipeline de implementação e promovem o lançamento para o ambiente de produção.
Quando os operadores fazem alterações às configurações base, essas alterações são aplicadas em toda a organização. À medida que os operadores confirmam as alterações aos respetivos repositórios, as atualizações de configuração da aplicação (e as implementações subsequentes) podem ser acionadas automaticamente. Em alternativa, as alterações dos operadores podem ser detetadas na próxima vez que os programadores implementarem as respetivas alterações.
Em paralelo, os engenheiros de segurança podem implementar e ajustar políticas que definem o que pode ser implementado e, em seguida, confirmar essas políticas no respetivo repositório de políticas.
Ao usar uma metodologia GitOps, pode exigir uma abordagem declarativa para quaisquer alterações às aplicações e aos clusters. Com esta abordagem, todas as alterações estão sujeitas a auditoria e revisão antes de poderem ser aplicadas. Neste modelo declarativo, armazena os ficheiros de configuração num repositório Git, o que lhe permite manter um registo de alterações, reverter implementações com falhas e ver o potencial impacto das alterações propostas.
Na arquitetura de referência associada, usa o kustomize para controlar as configurações da aplicação na sua organização. A ferramenta kustomize
permite que os operadores criem as chamadas bases de configurações de aplicações que
as suas equipas de desenvolvimento podem ajustar sem ter de adicionar nem alterar código na
base. Ao definir configurações base, as equipas de plataforma podem criar e iterar
nas práticas recomendadas para a organização. Os operadores e os programadores podem iterar nas respetivas implementações de forma independente, com os programadores a aplicarem as práticas recomendadas configuradas pelos operadores. Quando os operadores precisam de implementar uma nova prática recomendada para a organização, fazem a alteração na base, e a alteração é automaticamente incluída na próxima implementação dos programadores.
Repositórios de código
Os repositórios de código-fonte estão no centro do sistema de CI/CD. Os operadores, os programadores e os engenheiros de segurança têm os seus próprios repositórios para propagar alterações na plataforma. A utilização de um repositório Git como base para todas as alterações no sistema oferece várias vantagens:
Capacidade de auditoria incorporada. Os commits contêm informações sobre quando, o quê e quem alterou o sistema.
Um processo de reversão simplificado. A capacidade de reversão do Git permite-lhe reverter para um estado anterior do sistema.
Controlo de versões. Pode etiquetar commits do Git para indicar uma versão do estado do sistema.
Transações. Tem de resolver explicitamente os conflitos de estado e revê-los antes de poder integrar as alterações no estado.
O diagrama seguinte mostra como várias equipas interagem com um repositório centralizado para todas as alterações:
As secções seguintes explicam como os operadores, os programadores e os engenheiros de segurança usam o repositório Git num sistema de CI/CD moderno.
Repositórios de operadores
Os repositórios geridos pelo operador contêm práticas recomendadas para CI/CD e configuração de aplicações para ajudar as suas equipas a integrar aplicações, ao mesmo tempo que adotam práticas recomendadas organizacionais desde o início. Com os operadores a gerirem os repositórios, os programadores podem consumir quaisquer atualizações às práticas recomendadas organizacionais com a menor interrupção possível do respetivo fluxo de trabalho.
Os operadores podem codificar as práticas recomendadas das respetivas organizações em dois repositórios. O primeiro repositório é onde os operadores mantêm as práticas recomendadas da pipeline de CI/CD partilhada. Neste repositório, os operadores fornecem aos programadores uma biblioteca de tarefas predefinidas que podem usar para criar os respetivos pipelines. Os repositórios de aplicações dos programadores herdam automaticamente estas tarefas e a lógica nelas contida. Não é necessário copiá-las manualmente. Seguem-se alguns exemplos das tarefas que pode padronizar em toda a organização:
Construção e armazenamento de artefactos
Metodologias de testes para vários idiomas
Passos de implementação
Verificações de políticas
Análise de segurança
O segundo repositório que os operadores mantêm armazena as práticas recomendadas para configurar uma aplicação. No contexto do GKE, as práticas recomendadas envolvem garantir uma forma de gerir manifestos declarativos no modelo de recursos do Kubernetes. Estes manifestos descrevem o estado pretendido da aplicação. Os operadores podem criar configurações base para diferentes tipos de aplicações, o que oferece aos programadores um caminho simplificado para implementarem as respetivas apps de acordo com as práticas recomendadas organizacionais.
Repositórios de aplicações
Os repositórios de aplicações armazenam a lógica empresarial da aplicação e qualquer configuração especializada necessária para a aplicação funcionar corretamente.
À medida que os operadores criam e mantêm práticas recomendadas de forma codificada, os programadores podem usar essas práticas recomendadas. Para tal, os programadores fazem referência às tarefas de CI/CD e às bases de aplicações que os operadores criaram nos seus próprios repositórios. Depois de os programadores fazerem as alterações, os operadores podem personalizar ainda mais a implementação da aplicação adicionando configurações específicas do ambiente, como URLs de bases de dados ou etiquetas e anotações de recursos.
Seguem-se exemplos dos artefactos que pode armazenar em repositórios de aplicações:
Código-fonte da aplicação
Um
Dockerfileque descreve como criar e executar a aplicaçãoA definição do pipeline de CI/CD
Extensões ou modificações às bases de configuração da aplicação criadas pelos 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 as aplicações. A infraestrutura pode incluir plataformas de rede e orquestração de contentores, como o GKE. Normalmente, os administradores de infraestrutura são os proprietários destes repositórios. Os operadores podem atualizá-los para implementar práticas recomendadas.
Seguem-se exemplos dos artefactos que pode armazenar em repositórios de aplicações:
- Código de idioma declarativo (Terraform, Pulumi) que representa objetos de infraestrutura.
Scripts de shell ou Python que complementam as definições de API declarativas.
Extensões ou modificações aos modelos de infraestrutura base criados pela equipa de infraestrutura.
Repositórios de configuração e políticas
Garantir uma plataforma consistente e com segurança melhorada é uma das principais prioridades dos operadores e dos engenheiros de segurança.
Configuração
A configuração centralizada permite-lhe propagar alterações de configuração em todo o sistema. Seguem-se alguns itens de configuração comuns que pode gerir centralmente:
Namespaces do Kubernetes
Quotas
Controlos de acesso baseados em funções (CABF)
Políticas de Rede
Deve aplicar consistentemente estes tipos de configurações em todos os seus clusters para que as equipas de aplicações não usem indevidamente nem abusem da infraestrutura. A utilização de um repositório Git para armazenar a configuração pode melhorar processos como a auditoria e a implementação da configuração através de métodos como o GitOps. As ferramentas como a sincronização de configuração podem simplificar o processo de aplicação uniforme de configurações na sua infraestrutura.
Política
Uma vez que os programadores podem expandir as configurações base criadas pelos operadores, precisa de uma forma de restringir os recursos criados nos clusters que compõem a plataforma. Em alguns casos, pode criar uma política que permita aos programadores criar recursos apenas se esses recursos cumprirem requisitos específicos, por exemplo, criar objetos do serviço Kubernetes que não podem ser configurados para equilibrar a carga externa.
Na arquitetura de referência associada, usa o Policy Controller para aplicar políticas.
Repositórios iniciais
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 significativamente o custo associado à adoção de práticas recomendadas. Por sua vez, as práticas recomendadas ajudam a aumentar a velocidade das funcionalidades, a fiabilidade e a produtividade da equipa. Na arquitetura de referência associada, existem vários repositórios iniciais para CI, CD, configurações do Kubernetes, Go, Java e infraestrutura e aplicações iniciais do Python.
Integração contínua
Normalmente, as organizações têm um conjunto padrão de tarefas que são aplicadas às aplicações durante a CI. Por exemplo, na implementação de referência, o conjunto base de fases de IC é o seguinte: compilar código e criar uma imagem de contentor. Uma vez que essas fases estão definidas no repositório inicial, são aplicadas de forma uniforme em toda a plataforma. As equipas de aplicações individuais podem adicionar passos adicionais.
Entrega contínua
Semelhante à CI, o processo de CD tem normalmente um conjunto padrão de passos para implementar aplicações através dos ambientes de desenvolvimento, pré-produção e produção. Independentemente das metodologias de implementação usadas, o repositório inicial permite que as equipas de plataforma apliquem essas metodologias de forma uniforme em todas as aplicações e ambientes. Na implementação de referência, o processo de implementação inclui implementações para desenvolvimento, implementações de pré-produção, uma implementação de produção em vários clusters e aprovações manuais para a implementação de produção através do Cloud Deploy.
Configuração da aplicação
Para que uma plataforma de entrega de software seja eficaz, precisa de uma forma uniforme e consistente de aplicar a configuração da aplicação. Ao usar ferramentas como o
kustomize e repositórios iniciais para configurações do Kubernetes, as plataformas
podem fornecer uma base consistente para a configuração de aplicações. Por exemplo, na implementação de referência, a kustomize configuração base inicializa os repositórios do ambiente de aplicações com um conjunto base conhecido de configurações. Em seguida, as equipas de aplicações individuais podem adaptar as configurações às suas necessidades.
Aplicações de iniciação
As aplicações iniciais podem ajudar a reduzir os custos gerais associados à adoção de práticas recomendadas, por exemplo, práticas recomendadas de observabilidade e contentores.
Observabilidade. Para operar uma aplicação de forma eficiente e ajudar a garantir a fiabilidade, as aplicações têm de ter em conta o registo, as métricas e os rastreios. As aplicações iniciais ajudam as equipas a criar frameworks e estratégias que promovem a observabilidade.
Práticas recomendadas para o contentor. Quando cria aplicações contentorizadas, deve criar imagens de contentores pequenas e limpas. As práticas recomendadas para contentores incluem o acondicionamento de uma única aplicação numa imagem, a remoção de ferramentas desnecessárias da imagem e a tentativa ativa de produzir imagens pequenas a partir de imagens de base mínimas.
A arquitetura de referência fornece uma app Go básica, uma app Java básica e uma app Python básica como ponto de partida. Deve adicionar aplicações iniciais personalizadas para os idiomas, as pilhas de tecnologia e os tipos de aplicações que as suas equipas desenvolvem.
Repositórios de iniciação de infraestrutura
Os repositórios iniciais de infraestrutura incluem o código pré-escrito necessário para criar diferentes componentes de infraestrutura. Estes repositórios usam modelos e módulos padrão, conforme decidido pela equipa de infraestrutura.
Por exemplo, na implementação de referência, o platform-template contém o código inicial para criar um Google Cloud projeto, uma nuvem privada virtual e um cluster do GKE. Normalmente, este modelo é usado por equipas de infraestrutura para gerir a infraestrutura usada por várias equipas de aplicações como um recurso partilhado. Da mesma forma, o infra-template contém código de infraestrutura inicial básico que uma aplicação pode exigir, por exemplo, um Cloud Storage ou uma base de dados do Spanner. Normalmente, este modelo é usado pelas equipas de aplicações para gerir a infraestrutura das respetivas aplicações.
Repositórios de modelos partilhados
Os repositórios de modelos partilhados oferecem modelos de tarefas padrão que qualquer pessoa numa organização pode reutilizar. Por exemplo, módulos de infraestrutura como código, como os módulos Terraform, que podem ser usados para criar recursos de infraestrutura, como redes e computação.
Zonas de destino da aplicação
Quando usa CI/CD partilhada, configuração de aplicações partilhada e política e configuração consistentes em todos os clusters, pode associar estas capacidades para criar zonas de destino de aplicações.
Uma zona de destino é uma entidade lógica bloqueada que permite aos programadores implementar e iterar nas respetivas aplicações. As zonas de destino das aplicações usam as restrições que implementa para que os programadores possam operar de forma autónoma. Para cada aplicação, cria um namespace do Kubernetes em cada cluster de cada ambiente (por exemplo, para produção, desenvolvimento ou teste). Esta consistência ajuda os operadores a depurar e manter os ambientes ao longo do tempo.
O diagrama seguinte ilustra o conceito de zonas de aterragem:
Modelo de funcionamento
Quando opera uma plataforma de entrega de software com CI/CD moderna, é importante manter os ambientes, a infraestrutura e os processos consistentes e atualizados. Por conseguinte, tem de planear e escolher cuidadosamente o modelo de funcionamento da plataforma. Pode escolher entre vários modelos, como clusters como serviço, projetos ou uma infraestrutura multi-inquilino.
Uma vez que é importante manter uma infraestrutura consistente, limitar a expansão e permitir que as equipas se concentrem na disponibilização de aplicações, recomendamos que implemente uma infraestrutura multi-inquilino. A implementação de aplicações numa infraestrutura multi-inquilino elimina a necessidade de as equipas de aplicações gerirem a infraestrutura e permite que as equipas de operadores e de segurança se concentrem em manter a infraestrutura consistente.
Considerações para infraestruturas multi-inquilino
Quando cria uma plataforma de entrega de software multiinquilino, há várias aspetos que pode considerar incorporar na plataforma:
Isolamento da carga de trabalho. O conceito de zonas de destino de aplicações consiste em fornecer uma estrutura para isolar cargas de trabalho. As zonas de destino são uma combinação de espaços de nomes, políticas de rede e RBAC. Todas estas políticas devem ser geridas e aplicadas centralmente através da sincronização de configuração.
Monitorização da utilização do inquilino. Para obter discriminações de custos em namespaces e etiquetas individuais num cluster, pode usar a medição de utilização do GKE. A medição da utilização do GKE monitoriza informações sobre pedidos de recursos e utilização de recursos para as cargas de trabalho de um cluster, que pode filtrar ainda mais por namespaces e etiquetas. Quando ativa a medição da utilização do GKE no cluster multiinquilino, os registos de utilização de recursos são escritos numa tabela do BigQuery. Pode exportar métricas específicas do inquilino para conjuntos de dados do BigQuery no projeto de inquilino correspondente e, em seguida, os auditores podem analisar essas métricas para determinar discriminações de custos.
Quotas de recursos. Para garantir que todos os inquilinos que partilham um cluster têm acesso justo aos recursos do cluster, tem de aplicar quotas de recursos. Crie uma quota de recursos para cada espaço de nomes com base no número de pods que cada inquilino implementa e na quantidade de memória e CPU que cada pod requer.
Vários clusters para cada ambiente. Para melhorar a fiabilidade da aplicação e da plataforma, deve usar vários clusters para cada ambiente de pré-produção e produção. Com vários clusters disponíveis, pode implementar aplicações individualmente em clusters para obter níveis adicionais de validação de testes beta. Além disso, ter vários clusters facilita as preocupações relacionadas com o ciclo de vida da gestão e das atualizações dos clusters.
Registo e monitorização específicos do inquilino. Para investigar as operações das respetivas aplicações, os inquilinos precisam de acesso a registos e métricas. Num ambiente multi-inquilino, o registo e a monitorização devem ser específicos da aplicação. Para métricas e monitorização, pode usar o serviço gerido do Google Cloud para Prometheus e o Grafana para cada espaço de nomes. Para os registos, tem de criar um destino para exportar entradas de registo para conjuntos de dados do BigQuery e, em seguida, filtrar os conjuntos de dados por espaço de nomes do inquilino. Em seguida, os inquilinos podem aceder aos dados exportados no BigQuery.
Para mais informações acerca de uma infraestrutura multi-inquilino, consulte o artigo Práticas recomendadas para multi-inquilinos empresariais.
Limites de isolamento
Uma plataforma de entrega de software é criada e usada por várias equipas, o que torna importante ter limites de isolamento adequados entre os diferentes componentes da plataforma. Os limites de isolamento ajudam a criar uma plataforma robusta, oferecendo as seguintes caraterísticas:
Desassociar responsabilidades. Cada equipa gere os recursos nos respetivos limites de isolamento sem se preocupar com o resto. Por exemplo, a equipa de infraestrutura só é responsável pela manutenção dos clusters do GKE. Os operadores ou os programadores são responsáveis apenas pela manutenção dos pipelines de CI/CD e do código da aplicação.
Controlo de acesso detalhado. Se os recursos estiverem segregados por limites de isolamento, use o controlo de acesso detalhado para limitar o acesso.
Reduz as áreas afetadas. Pode fazer alterações a um componente de forma independente sem afetar outros componentes.
Reduz os erros manuais. Uma vez que o controlo de acesso é detalhado, pode evitar erros manuais, como a implementação acidental num cluster de produção a partir de um ambiente de desenvolvimento.
Estes limites de isolamento podem existir entre diferentes aplicações, infraestruturas e aplicações ou até mesmo entre os diferentes ambientes de uma aplicação.
Governança
O objetivo principal das plataformas de entrega de software e dos sistemas de CI/CD modernos é melhorar a eficiência do processo geral de entrega de software. Em termos de gestão da plataforma, tem duas considerações principais: a integração da aplicação, que geralmente se enquadra na categoria de governação, e o desenvolvimento e a manutenção contínuos da plataforma (ou seja, tratar a plataforma como um produto).
Integração e gestão de aplicações
O objetivo da adoção da metodologia e das ferramentas de CI/CD modernas é simplificar o processo de lançamento e a integração de novos serviços. A integração de novas aplicações deve ser um processo simples que pode realizar com um contributo mínimo das equipas de operações e segurança. Isto não significa que as equipas de operações e segurança não estejam envolvidas, mas sim que a respetiva contribuição inicial de uma perspetiva de implementação e segurança é processada automaticamente através do processo de aprovisionamento. Após a integração, as equipas de operações e segurança são naturalmente incluídas no processo de lançamento através de pedidos de união, atualizações de políticas e aplicação de práticas recomendadas.
Recomendamos que crie alguma automatização para integrar uma nova aplicação. Isto pode incluir a criação de repositórios de código, pipelines de CI/CD, zonas de destino e qualquer infraestrutura necessária para a aplicação. A automatização desvincula as dependências complexas das equipas de desenvolvimento de outras equipas na organização e oferece aos programadores autonomia para usar uma aplicação em regime de self-service. Isto permite aos programadores começar a iterar no código da aplicação muito rapidamente e não perder tempo a realizar tarefas que não sejam escrever o código. A automatização deve permitir que os programadores executem a aplicação num ambiente de desenvolvimento. Para levar a aplicação a ambientes superiores, devem envolver-se outras equipas e seguir-se o processo de revisão.
Na arquitetura de referência associada, esta automatização é denominada Application Factory.
Plataforma como produto
O fluxo de trabalho de CI/CD é um produto de software, exceto que os utilizadores do produto são equipas de desenvolvimento, operações e segurança. Tendo isto em conta, a plataforma requer as mesmas funções e processos de desenvolvimento de software, como proprietários de produtos, marketing (embora seja interno), ciclos de feedback dos utilizadores e ciclos de desenvolvimento de funcionalidades.
Implemente CI/CD com o GKE
À medida que começa a implementar a CI/CD moderna com o GKE na organização, a escolha das melhores aplicações de teste-piloto é fundamental. As equipas de desenvolvimento, operações e segurança também têm de considerar outros fatores à medida que trabalham, que são abordados nesta secção.
Selecionar uma aplicação de teste-piloto
Escolher as primeiras aplicações a mover para a plataforma pode ser um primeiro passo difícil. Os bons candidatos para testes-piloto são serviços que processam dados ou processam pedidos, mas não armazenam dados, por exemplo, camadas de cache, front-ends Web ou aplicações de processamento baseadas em eventos. Normalmente, estas aplicações são mais resistentes a pequenas quantidades de tempo de inatividade e erros de implementação que podem ocorrer em qualquer altura que trabalhe com novas técnicas de gestão de implementação e configuração. À medida que as equipas ganham mais experiência com a CI/CD e começam a sentir vantagens na fiabilidade e velocidade, pode começar a mover os serviços principais para a plataforma de entrega de software.
Considerações para programadores
Quando trabalha num processo de desenvolvimento de CI/CD moderno, as funcionalidades, as alterações e as implementações podem ocorrer com maior frequência e de forma mais assíncrona. As equipas de desenvolvimento têm de perceber como as alterações afetam os sistemas a jusante ou dependentes e como essas alterações são testadas. Os caminhos de comunicação entre as equipas de desenvolvimento, operações e segurança têm de ser fluidos. É uma boa prática investir em melhores práticas de controlo de versões para as aplicações e os contratos de dados através dos quais os diferentes serviços comunicam. Além de melhorar os métodos de comunicação e o controlo de versões, a implementação de funcionalidades em pequenos fragmentos e a utilização de ramificações e flags de funcionalidades podem melhorar a forma como testa e lança funcionalidades.
Considerações do operador
Com uma plataforma de entrega de software, as equipas de operações têm de funcionar mais como equipas de desenvolvimento. Em vez de criar funcionalidades viradas para o exterior, estão a criar ferramentas e processos internos que ajudam a facilitar o desenvolvimento, a implementação e o funcionamento de aplicações viradas para o exterior. As ferramentas da plataforma são usadas pela sua própria equipa, bem como pelas equipas de desenvolvimento e segurança. Os operadores devem criar ferramentas para ajudar na implementação de novas versões de aplicações e também na reversão das mesmas em caso de erros de aplicações ou falhas de implementação. Os operadores também devem dar mais ênfase à criação de sistemas de monitorização e alerta para detetar proativamente falhas e emitir alertas em conformidade.
Considerações da equipa de segurança
As equipas de segurança devem trabalhar para tornar a segurança mais uma responsabilidade partilhada entre si e as equipas de operações e desenvolvimento. Este padrão é normalmente denominado mudança para a esquerda na segurança, em que a segurança da informação (InfoSec) está envolvida no início do processo de desenvolvimento, os programadores trabalham com ferramentas pré-aprovadas e os testes de segurança são automatizados. Além dessas técnicas, pode definir e aplicar programaticamente a política de segurança com o Policy Controller. A combinação de técnicas e ferramentas coloca a aplicação da segurança numa posição mais proativa.
O que se segue?
Experimente implementar aspetos desta arquitetura de CI/CD moderna.
Saiba mais sobre as práticas recomendadas para configurar a federação de identidades.
Leia o artigo Kubernetes e os desafios do fornecimento contínuo de software.
Ler acerca dos padrões de registo e monitorização híbridos e em várias nuvens.