Implantar o blueprint

Last reviewed 2024-04-19 UTC

Nesta seção, descrevemos o processo que pode ser usado para implantar o blueprint, as convenções de nomenclatura e as alternativas às recomendações de blueprint.

Resumo geral

Para implementar a arquitetura descrita neste documento, conclua as etapas desta seção.

Implantar o blueprint em uma nova organização

Para implantar o blueprint em uma nova organização do Google Cloud, faça o seguinte:

  1. Crie sua infraestrutura de base usando o blueprint de fundamentos empresariais. Preencha os campos:

    1. Crie uma estrutura organizacional, incluindo pastas para separação de ambientes.
    2. Configurar permissões básicas do IAM para conceder acesso a administradores da plataforma de desenvolvimento.
    3. Crie a rede VPC.
    4. Implantar o pipeline de infraestrutura da base.

    Se você não usar o blueprint de base empresarial, consulte Implantar o blueprint sem o blueprint do nível empresarial.

  2. O administrador da plataforma do desenvolvedor usa o pipeline de infraestrutura de base para criar o pipeline de infraestrutura de vários locatários, a fábrica de aplicativos e o pipeline do escopo da frota.

  3. O administrador da plataforma do desenvolvedor usa o pipeline de infraestrutura multilocatário para implantar clusters do GKE e infraestrutura compartilhada.

  4. Os operadores de aplicativos usam a fábrica de aplicativos para integrar novos aplicativos. Os operadores adicionam uma ou mais entradas no repositório da fábrica de aplicativos, o que aciona a criação de recursos específicos do aplicativo.

  5. Os desenvolvedores usam o pipeline de CI/CD do aplicativo na infraestrutura específica do aplicativo para implantar aplicativos na infraestrutura multilocatário.

Implantar o blueprint sem o blueprint de bases empresariais

Se você não implantar o blueprint do aplicativo corporativo no blueprint de base empresarial, conclua as etapas a seguir:

  1. Crie os seguintes recursos:
    • Uma hierarquia de organização com development, nonproduction e pastas production
    • Uma rede VPC compartilhada em cada pasta
    • Um esquema de endereço IP que considera os intervalos de IP necessários para os clusters do GKE.
    • Um mecanismo de DNS para seus clusters do GKE
    • Políticas de firewall alinhadas à sua postura de segurança
    • Um mecanismo para acessar APIs do Google Cloud por meio de endereços IP particulares.
    • Um mecanismo de conectividade com o ambiente no local
    • Geração de registros centralizada para segurança e auditoria
    • Security Command Center para monitoramento de ameaças
    • Políticas da organização alinhadas com sua postura de segurança
    • Um pipeline que pode ser usado para implantar a fábrica de aplicativos, o pipeline de infraestrutura multilocatário e o pipeline do escopo da frota
  2. Depois de implantar os recursos, prossiga para a etapa 2 em Implantar o blueprint em uma nova organização.

Incorporar o blueprint na implantação do GKE

Esse blueprint exige que você implante primeiro a plataforma do desenvolvedor e, em seguida, os aplicativos nela. A tabela a seguir descreve como você pode usar o blueprint se já tiver aplicativos conteinerizados em execução no Google Cloud.

Uso Estratégia de migração

Já tem um pipeline de CI/CD.

É possível usar a frota e a arquitetura de cluster do blueprint mesmo quando diferentes produtos são usados para a criação e a implantação de aplicativos. No mínimo, recomendamos que você espelhe imagens em duas regiões.

Tenha uma estrutura organizacional que não corresponda ao blueprint das bases empresariais.

É recomendado ter pelo menos dois ambientes para implantações sequenciais mais seguras. Não é necessário implantar ambientes em pastas ou VPCs compartilhadas separadas. No entanto, não implante cargas de trabalho que pertençam a diferentes ambientes no mesmo cluster.

Não use IaC.

Se o processo atual de implantação de aplicativos não usa IaC, avalie sua prontidão com o modelo de maturidade do Terraform no Google Cloud. Importe os recursos para um projeto diferente do Terraform, organizado de maneira semelhante a este blueprint, com a separação de pipelines de vários locatários e por locatário. Para criar novos clusters, use os módulos do Terraform para Google Cloud.

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

É possível agrupar clusters de vários projetos em uma frota. Verifique se os namespaces têm significados exclusivos na mesma frota. Antes de adicionar clusters a uma frota, peça que as equipes movam os aplicativos para um namespace com um nome exclusivo (por exemplo, não default).

Em seguida, é possível agrupar namespaces em escopos.

Os clusters estão em uma única região.

Não é preciso usar várias regiões em produção e não produção para adotar o blueprint.

Existem diferentes conjuntos de ambientes.

É possível modificar o blueprint para oferecer suporte a mais ou menos de três ambientes.

A criação de clusters é delegada às equipes de desenvolvedores ou operadores de aplicativos.

Para ter a plataforma de desenvolvedor mais segura e consistente, tente transferir a propriedade dos clusters das equipes de aplicativo para a equipe da plataforma do desenvolvedor. Se não for possível, ainda será possível adotar muitas das práticas de blueprint. Por exemplo, você pode adicionar os clusters de diferentes equipes de aplicativo a uma frota. No entanto, ao combinar clusters com propriedade independente, não use a Identidade da carga de trabalho ou o Anthos Service Mesh, porque eles não fornecem controle suficiente sobre quem pode declarar quais identidades de carga de trabalho. Em vez disso, use uma política da organização personalizada para impedir que as equipes ativem esses recursos nos clusters do GKE.

Quando os clusters são agrupados em uma frota, ainda é possível auditar e aplicar políticas. É possível usar uma política personalizada da organização para exigir que os clusters sejam criados em uma frota correspondente à pasta do ambiente em que o projeto do cluster está. É possível usar a configuração padrão da frota para exigir que novos clusters usem o controle de políticas.

Alternativas às recomendações padrão

Nesta seção, descrevemos alternativas às recomendações padrão deste guia.

arearea de decisão Alternativas possíveis

Todos os aplicativos são executados no mesmo conjunto de cinco clusters.

O blueprint usa um conjunto de cinco clusters, dois em produção, dois em não produção e um em desenvolvimento. É possível modificar o blueprint para criar conjuntos adicionais de cinco clusters.

Atribuir aplicativos a conjuntos de cinco clusters. Não vincule os escopos ou os namespaces da frota de um aplicativo a clusters nos outros conjuntos. É possível separar os aplicativos em diferentes conjuntos de cluster para concluir atividades como as seguintes:

  • Agrupe alguns aplicativos com preocupações regulatórias especiais (por exemplo, PCI-DSS).
  • Isole os aplicativos que exigem processamento especial durante upgrades do cluster (por exemplo, aplicativos com estado que usam volumes permanentes).
  • Isole aplicativos com perfis de segurança arriscados (por exemplo, processar conteúdo fornecido pelo usuário em uma linguagem não segura para a memória).
  • Isole os aplicativos que exigem GPUs, sensibilidade ao custo e sensibilidade ao desempenho.
  • Se você estiver se aproximando do limite de clusters do GKE no número de nós (15.000 nós), crie um novo conjunto de clusters.
  • Use uma VPC compartilhada diferente para aplicativos que precisam ser executados em um perímetro do VPC Service Controls. Crie um conjunto de clusters no perímetro e um conjunto fora dele.

Evite criar novos conjuntos de clusters para cada aplicativo ou locatário, porque essa prática pode resultar em uma das seguintes circunstâncias:

  • Aplicativos que não fazem bom uso do tamanho mínimo do cluster (três VMs x 2 regiões), mesmo com os menores tipos de instância disponíveis.
  • Potencial perdido de redução de custos devido ao empacotamento de diferentes aplicativos em pacotes.
  • Planejamento tedioso e incerto de crescimento de capacidade, porque ele é aplicado a cada aplicativo individualmente. As previsões de capacidade são mais precisas quando feitas de maneira agregada para um amplo conjunto de aplicativos.
  • Atrasos na criação de novos clusters para novos locatários ou aplicativos, reduzindo a satisfação do locatário com a plataforma. Por exemplo, em algumas organizações, as alocações de endereços IP necessárias podem levar tempo e exigir aprovações extras.
  • Atingir o limite de clusters particulares em uma rede VPC.

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

Para reduzir a latência para usuários finais em várias regiões, implante 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). Essa estratégia de implantação aumenta o custo e a sobrecarga de manutenção de recursos em regiões adicionais.

Se todos os aplicativos tiverem requisitos de disponibilidade mais baixos, implante cargas de trabalho de produção e não produção em apenas uma região (um ambiente de produção, um de não produção e um de desenvolvimento). Essa estratégia ajuda a reduzir os custos, mas não protege o mesmo nível de disponibilidade que uma arquitetura birregional ou multirregional.

Se os aplicativos tiverem requisitos de disponibilidade diferentes, será possível criar conjuntos de clusters distintos para cada aplicativo (por exemplo, cluster-set-1 com dois ambientes de produção, dois de não produção e um de desenvolvimento, e cluster-set-2 com um ambiente de produção, um de não produção e um de desenvolvimento).

A topologia de hub e spoke corresponde melhor aos seus requisitos do que a VPC compartilhada.

É possível implantar o blueprint em uma configuração hub e spoke, em que cada ambiente (desenvolvimento, produção e não produção) é hospedado no próprio spoke. A topologia de hub e spoke pode aumentar a segregação dos ambientes. Para mais informações, consulte Topologia de rede hub e spoke.

Cada aplicativo 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 você usar um monorepo, poderá modificar o componente fábrica de aplicativos do blueprint para oferecer suporte ao repositório. Preencha os campos:

  • Em vez de criar um novo repositório para cada aplicativo novo, crie um subdiretório no repositório atual.
  • Em vez de conceder permissões de proprietário no novo repositório ao grupo de desenvolvedores de aplicativos, conceda permissão de gravação no repositório existente e torne o grupo de desenvolvedores do aplicativo um revisor necessário para alterações no novo subdiretório. Use o recurso CODEOWNERS e a proteção de ramificação.

A seguir