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:
Crie sua infraestrutura de base usando o blueprint de fundamentos empresariais. Preencha os campos:
- Crie uma estrutura organizacional, incluindo pastas para separação de ambientes.
- Configurar permissões básicas do IAM para conceder acesso a administradores da plataforma de desenvolvimento.
- Crie a rede VPC.
- 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.
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.
O administrador da plataforma do desenvolvedor usa o pipeline de infraestrutura multilocatário para implantar clusters do GKE e infraestrutura compartilhada.
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.
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:
- Crie os seguintes recursos:
- Uma hierarquia de organização com
development
,nonproduction
e pastasproduction
- 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
- Uma hierarquia de organização com
- 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 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:
Evite criar novos conjuntos de clusters para cada aplicativo ou locatário, porque essa prática pode resultar em uma das seguintes circunstâncias:
|
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,
|
|
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:
|
A seguir
- Saiba mais sobre o Blueprint de bases empresariais.
- Saiba mais sobre a entrega de software no Google Cloud nos artigos a seguir:
- Saiba mais sobre como executar aplicativos no GKE do
seguinte:
- Práticas recomendadas para criar contêineres
- Práticas recomendadas para redes do GKE
- Práticas recomendadas para multilocação empresarial no GKE
- Práticas recomendadas para trabalhar com contêineres
- Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE
- Repositório de cluster mais seguro do GKE
- Aumentar a segurança do cluster