Implemente o projeto

Last reviewed 2024-12-13 UTC

Esta secção descreve o processo que pode usar para implementar o esquema, as respetivas convenções de nomenclatura e alternativas às recomendações do esquema.

Reunir tudo num só lugar

Para implementar a arquitetura descrita neste documento, conclua os passos nesta secção.

Implemente o projeto num novo organização

Para implementar o projeto num novo Google Cloud organização, conclua o seguinte:

  1. Crie a sua infraestrutura de base com o projeto de base empresarial. Faça o seguinte:

    1. Crie uma estrutura organizacional, incluindo pastas para a separação de ambientes.
    2. Configure as autorizações IAM fundamentais para conceder acesso aos administradores da plataforma de programadores.
    3. Crie a rede de VPC.
    4. Implemente o pipeline de infraestrutura fundamental.

    Se não usar o esquema de base empresarial, consulte o artigo Implemente o esquema sem o esquema de base empresarial.

  2. Implemente o projeto de aplicação empresarial da seguinte forma:

    1. O administrador da plataforma do programador usa o pipeline de infraestrutura de base para criar o pipeline de infraestrutura multiinquilino, a fábrica de aplicações e o pipeline de âmbito da frota.
    2. O administrador da plataforma do programador usa o pipeline de infraestrutura multi-inquilino para implementar clusters do GKE e infraestrutura partilhada.
    3. Os operadores de aplicações usam a fábrica de aplicações para integrar novas aplicações. Os operadores adicionam uma ou mais entradas no repositório da fábrica de aplicações, o que aciona a criação de recursos específicos da aplicação.
    4. Os programadores de aplicações usam o pipeline de CI/CD de aplicações na respetiva infraestrutura específica da aplicação para implementar aplicações na infraestrutura multi-inquilino.

Implemente o projeto sem o projeto de bases empresariais

Se não implementar o esquema da aplicação empresarial no esquema das bases empresariais, conclua os seguintes passos:

  1. Crie os seguintes recursos:
    • Uma hierarquia de organização com pastas development, nonproduction e production
    • Uma rede de VPC partilhada em cada pasta
    • Um esquema de endereços IP que tem em conta os intervalos de IP necessários para os seus clusters do GKE
    • Um mecanismo de DNS para os seus clusters do GKE
    • Políticas de firewall alinhadas com a sua postura de segurança
    • Um mecanismo para aceder às Google Cloud APIs através de endereços IP privados
    • Um mecanismo de conetividade com o seu ambiente nas instalações
    • Registo centralizado para segurança e auditoria
    • Security Command Center para monitorização de ameaças
    • Políticas organizacionais alinhadas com a sua postura de segurança
    • Um pipeline que pode ser usado para implementar a fábrica de aplicações, o pipeline de infraestrutura multiinquilino e o pipeline de âmbito da frota
  2. Depois de implementar os recursos, continue com o passo 2 em Implemente o projeto no âmbito de uma nova organização.

Incorpore o projeto na sua implementação do GKE existente

Este plano requer que implemente primeiro a plataforma do programador e, em seguida, implemente aplicações na plataforma do programador. A tabela seguinte descreve como pode usar o esquema se já tiver aplicações em contentores em execução no Google Cloud.

Utilização existente Estratégia de migração

Já tem uma pipeline de CI/CD.

Pode usar a arquitetura de frota e cluster do projeto mesmo quando são usados diferentes produtos para a criação e a implementação de aplicações. No mínimo, recomendamos que espelhe as imagens em duas regiões.

Ter uma estrutura organizacional existente que não corresponda ao projeto de base empresarial.

Recomendamos que tenha, pelo menos, dois ambientes para implementações sequenciais mais seguras. Não tem de implementar ambientes em VPCs partilhadas ou pastas separadas. No entanto, não implemente cargas de trabalho que pertençam a ambientes diferentes no mesmo cluster.

Não use IaC.

Se o seu processo de implementação de aplicações atual não usar IaC, pode avaliar a sua prontidão com o Terraform no Google Cloud modelo de maturidade. Importe recursos existentes para um projeto do Terraform diferente que esteja organizado de forma semelhante a este projeto, com a separação de pipelines multi-inquilino e por inquilino. Para criar novos clusters, pode usar módulos do Terraform para Google Cloud.

Os clusters estão distribuídos por vários projetos no mesmo ambiente.

Pode agrupar clusters de vários projetos numa frota. Verifique se os seus espaços de nomes têm significados exclusivos na mesma frota. Antes de adicionar clusters a uma frota, peça às equipas que movam as respetivas aplicações para um espaço de nomes com um nome exclusivo (por exemplo, não default).

Em seguida, pode agrupar os espaços de nomes em âmbitos.

Os clusters estão numa única região.

Não precisa de usar várias regiões em produção e não produção para adotar o esquema.

Existem diferentes conjuntos de ambientes.

Pode modificar o esquema para suportar mais ou menos de três ambientes.

A criação de clusters é delegada aos programadores de aplicações ou às equipas de operadores de aplicações.

Para ter uma plataforma de programadores mais segura e consistente, pode tentar transferir a propriedade dos clusters das equipas de aplicações para a equipa da plataforma de programadores. Se não conseguir, pode adotar muitas das práticas do plano de ação. Por exemplo, pode adicionar os clusters pertencentes a diferentes equipas de aplicações a uma frota. No entanto, quando combinar clusters com propriedade independente, não use a federação de identidade da carga de trabalho para o GKE ou o Cloud Service Mesh, porque não oferecem controlo suficiente sobre quem pode afirmar que identidades de carga de trabalho. Em alternativa, use uma política de organização personalizada para impedir que as equipas ativem estas funcionalidades em clusters do GKE.

Quando os clusters são agrupados numa frota, ainda pode auditar e aplicar políticas. Pode usar uma política de organização personalizada para exigir que os clusters sejam criados numa frota que corresponda à pasta do ambiente em que o projeto do cluster se encontra. Pode usar a configuração predefinida da frota para exigir que os novos clusters usem o controlo de políticas.

Alternativas às recomendações predefinidas

Esta secção descreve alternativas às recomendações predefinidas incluídas neste guia.

Área de decisão Alternativas possíveis

Todas as aplicações são executadas no mesmo conjunto de cinco clusters.

O projeto usa um conjunto de cinco clusters (dois em produção, dois em não produção e um em desenvolvimento). Pode modificar o esquema para criar conjuntos adicionais de cinco clusters.

Atribuir aplicações a conjuntos de cinco clusters. Não associe os âmbitos de uma aplicação nem os namespaces da frota a clusters nos outros conjuntos. Pode querer separar as aplicações em diferentes conjuntos de clusters para concluir atividades como as seguintes:

  • Agrupar algumas aplicações com preocupações regulamentares especiais (por exemplo, PCI-DSS).
  • Isolar aplicações que requerem processamento especial durante as atualizações do cluster (por exemplo, aplicações com estado que usam volumes persistentes).
  • Isolar aplicações com perfis de segurança arriscados (por exemplo, processamento de conteúdo fornecido pelo utilizador num idioma com memória não segura).
  • Isolar aplicações que requerem GPUs, sensibilidade aos custos e sensibilidade ao desempenho.
  • Se estiver a aproximar-se do limite do cluster do GKE no número de nós (65 000 nós), pode criar um novo conjunto de clusters.
  • Use uma VPC partilhada diferente para aplicações que precisam de ser executadas num perímetro dos VPC Service Controls. Crie um conjunto de clusters no perímetro e um conjunto de clusters fora do perímetro.

Evite criar novos conjuntos de clusters para cada aplicação ou inquilino, uma vez que esta prática pode resultar numa das seguintes circunstâncias:

  • Aplicações que não fazem uma boa utilização do tamanho mínimo do cluster (3 VMs x 2 regiões), mesmo com os tipos de instâncias disponíveis mais pequenos.
  • Potencial perdido de redução de custos devido à organização de diferentes aplicações.
  • Planeamento do crescimento da capacidade tedioso e incerto, porque o planeamento é aplicado a cada aplicação individualmente. As previsões de capacidade são mais precisas quando são feitas de forma agregada para um conjunto alargado de aplicações.
  • Atrasos na criação de novos clusters para novos inquilinos ou aplicações, o que reduz a satisfação dos inquilinos com a plataforma. Por exemplo, em algumas organizações, as atribuições de endereços IP necessárias podem demorar algum tempo e exigir aprovações adicionais.
  • Atingir o limite de clusters privados numa rede VPC.

Os ambientes de produção e não produção têm clusters em duas regiões.

Para uma latência mais baixa para os utilizadores finais em várias regiões, pode implementar as cargas de trabalho de produção e não produção em mais de duas regiões (por exemplo, três regiões para produção, três regiões para não produção e uma região para desenvolvimento). Esta estratégia de implementação aumenta o custo e a sobrecarga da manutenção de recursos em regiões adicionais.

Se todas as aplicações tiverem requisitos de disponibilidade mais baixos, pode implementar cargas de trabalho de produção e não de produção apenas numa região (um ambiente de produção, um ambiente de não produção e um ambiente de desenvolvimento). Esta estratégia ajuda a reduzir o custo, mas não protege o mesmo nível de disponibilidade que uma arquitetura de duas regiões ou várias regiões.

Se as aplicações tiverem requisitos de disponibilidade diferentes, pode criar diferentes conjuntos de clusters para diferentes aplicações (por exemplo, cluster-set-1 com dois ambientes de produção, dois ambientes de não produção e um ambiente de desenvolvimento e cluster-set-2 com um ambiente de produção, um ambiente de não produção e um ambiente de desenvolvimento).

A topologia de hub e raios corresponde melhor aos seus requisitos do que a VPC partilhada.

Pode implementar o esquema num padrão de hub-and-spoke, em que cada ambiente (desenvolvimento, produção e não produção) está alojado no seu próprio spoke. A topologia de hub e raios pode aumentar a segregação dos ambientes. Para mais informações, consulte o artigo Topologia de rede em estrela.

Cada aplicação tem um repositório Git separado.

Algumas organizações usam um único repositório Git (um monorepo) para todo o código fonte em vez de vários repositórios. Se usar um monorepo, pode modificar o componente application factory do esquema para suportar o seu repositório. Faça o seguinte:

  • Em vez de criar um novo repositório para cada nova aplicação, crie um subdiretório no repositório existente.
  • Em vez de conceder autorizações de proprietário no novo repositório ao grupo de programadores da aplicação, conceda autorização de escrita no repositório existente e torne o grupo de programadores da aplicação um revisor obrigatório para as alterações ao novo subdiretório. Use a funcionalidade CODEOWNERS e a proteção de ramificações.

O que se segue?