O padrão espelhado é baseado na replicação do design de um ou mais ambientes existentes em um ou mais ambientes novos. Portanto, esse padrão se aplica principalmente a arquiteturas que seguem o padrão híbrido de ambiente. Nesse padrão, você executa as cargas de trabalho de desenvolvimento e teste em um ambiente e as de preparo e produção em outro.
O padrão espelhado pressupõe que as cargas de trabalho de teste e produção não devem se comunicar diretamente umas com as outras. No entanto, é preciso que você possa gerenciar e implantar os dois grupos de cargas de trabalho de maneira consistente.
Se você usar esse padrão, conecte os dois ambientes de computação de maneira a atender aos seguintes requisitos:
- A integração contínua/implantação contínua (CI/CD) pode implantar e gerenciar cargas de trabalho em todos os ambientes de computação ou em ambientes específicos.
- O monitoramento, o gerenciamento de configuração e outros sistemas administrativos precisam funcionar em todos os ambientes de computação.
- As cargas de trabalho não podem se comunicar diretamente entre ambientes de computação. Se necessário, a comunicação precisa ser refinada e controlada.
Arquitetura
O diagrama de arquitetura a seguir mostra uma arquitetura de referência de alto nível desse padrão que oferece suporte a CI/CD, monitoramento, gerenciamento de configuração, outros sistemas administrativos e comunicação de carga de trabalho:
A descrição da arquitetura no diagrama anterior é a seguinte:
- As cargas de trabalho são distribuídas com base nos ambientes funcionais (desenvolvimento, teste, CI/CD e ferramentas administrativas) em VPCs separadas no lado Google Cloud .
- A VPC compartilhada é usada para cargas de trabalho de desenvolvimento e teste. Uma VPC extra é usada para as ferramentas administrativas e de CI/CD. Com as VPCs compartilhadas:
- Os aplicativos são gerenciados por equipes diferentes por ambiente e por projeto de serviço.
- O projeto host administra e controla a comunicação de rede e os controles de segurança entre os ambientes de desenvolvimento e teste, além de fora da VPC.
- A VPC de CI/CD está conectada à rede que executa as cargas de trabalho de produção no ambiente de computação particular.
- As regras de firewall permitem apenas o tráfego autorizado.
- Também é possível usar o Cloud Next Generation Firewall Enterprise com o serviço de prevenção de invasões (IPS) para implementar a inspeção detalhada de pacotes para prevenção de ameaças sem mudar o design ou o roteamento. O Cloud Next Generation Firewall Enterprise funciona criando endpoints de firewall zonais gerenciados pelo Google que usam a tecnologia de interceptação de pacotes para inspecionar de maneira transparente as cargas de trabalho quanto às assinaturas de ameaças configuradas. Ela também protege as cargas de trabalho contra ameaças.
- Permite a comunicação entre as VPCs com peering usando endereços IP internos.
- O peering neste padrão permite que a CI/CD e os sistemas administrativos implantem e gerenciem cargas de trabalho de desenvolvimento e teste.
- Considere estas práticas recomendadas gerais.
Para estabelecer essa conexão de CI/CD, use uma das opções de conectividade de rede híbrida e multicloud discutidas que atendam aos requisitos dos seus negócios e aplicativos. Para permitir que você implante e gerencie cargas de trabalho de produção, essa conexão oferece acessibilidade de rede particular entre os diferentes ambientes de computação. Todos os ambientes precisam ter um espaço de endereços IP RFC 1918 sem sobreposição.
Se as instâncias nos ambientes de desenvolvimento e teste precisarem de acesso à Internet, considere as seguintes opções:
- É possível implantar o Cloud NAT na mesma rede do projeto host da VPC compartilhada. A implantação na mesma rede de projeto host da VPC compartilhada ajuda a evitar que essas instâncias sejam acessíveis diretamente da Internet.
- Para o tráfego de saída da Web, use o Secure Web Proxy. O proxy oferece vários benefícios.
Para mais informações sobre as ferramentas e os recursos do Google Cloud que ajudam a criar, testar e implantar no Google Cloud e em ambientes híbridos e multicloud, consulte o blog DevOps e CI/CD no Google Cloud explicados.
Variações
Para atender a diferentes requisitos de design, mas sem deixar de considerar todos os requisitos de comunicação, o padrão de arquitetura espelhado oferece estas opções, que são descritas nas seções a seguir:
- VPC compartilhada por ambiente
- Firewall de camada do aplicativo centralizado
- Topologia hub e spoke
- Arquitetura distribuída de microsserviços de confiança zero
VPC compartilhada por ambiente
A opção de design de VPC compartilhada por ambiente permite a separação no nível do aplicativo ou do serviço em todos os ambientes, incluindo CI/CD e ferramentas administrativas que podem ser necessárias para atender a determinados requisitos de segurança organizacional. Esses requisitos limitam a comunicação, o domínio administrativo e o controle de acesso para diferentes serviços que também precisam ser gerenciados por equipes diferentes.
Esse design alcança a separação ao fornecer isolamento no nível da rede e para envolvidos no projeto entre os diferentes ambientes, o que permite uma comunicação mais granular e controle de acesso do Identity and Access Management (IAM).
Do ponto de vista de gerenciamento e operações, esse design oferece a flexibilidade de gerenciar os aplicativos e as cargas de trabalho criados por diferentes equipes por ambiente e por projeto de serviço. O provisionamento e o gerenciamento da rede VPC e dos recursos de segurança dela podem ser feitos por equipes de operações de rede com base nas seguintes estruturas possíveis:
- Uma equipe gerencia todos os projetos host em todos os ambientes.
- Equipes diferentes gerenciam os projetos host nos respectivos ambientes.
As decisões sobre o gerenciamento de projetos host precisam ser baseadas na estrutura da equipe, nas operações de segurança e nos requisitos de acesso de cada equipe. Você pode aplicar essa variação de design à opção de design de zona de destino da rede VPC compartilhada para cada ambiente. No entanto, é necessário considerar os requisitos de comunicação do padrão espelhado para definir qual comunicação é permitida entre os diferentes ambientes, incluindo a comunicação pela rede híbrida.
Também é possível provisionar uma rede VPC compartilhada para cada ambiente principal, conforme ilustrado no diagrama a seguir:
Firewall de camada do aplicativo centralizado
Em alguns cenários, os requisitos de segurança podem exigir a consideração da camada de aplicativo (Camada 7) e uma inspeção detalhada de pacotes com mecanismos avançados de firewall que excedam os recursos do Cloud Next Generation Firewall. Para atender aos requisitos e padrões de segurança da sua organização, use um dispositivo NGFW hospedado em um dispositivo virtual de rede (NVA). Vários Google Cloud parceiros de segurança oferecem opções adequadas para essa tarefa.
Conforme ilustrado no diagrama a seguir, é possível colocar o NVA no caminho da rede entre a nuvem privada virtual e o ambiente de computação particular usando várias interfaces de rede.
Esse design também pode ser usado com várias VPCs compartilhadas, conforme ilustrado no diagrama a seguir.
O NVA nesse design atua como a camada de segurança do perímetro. Ele também serve como base para ativar a inspeção de tráfego inline e aplicar políticas rígidas de controle de acesso.
Para uma estratégia de segurança robusta de várias camadas que inclua regras de firewall da VPC e recursos de serviço de prevenção de intrusões, inclua mais inspeção de tráfego e controle de segurança nos fluxos de tráfego leste-oeste e norte-sul.
Topologia hub e spoke
Outra variação possível do design é usar VPCs separadas (incluindo VPCs compartilhadas) para desenvolvimento e diferentes estágios de teste. Nessa variação, conforme mostrado no diagrama a seguir, todos os ambientes de estágio se conectam à VPC administrativa e de CI/CD em uma arquitetura hub-and-spoke. Use essa opção se você precisar separar os domínios administrativos e as funções em cada ambiente. O modelo de comunicação hub-and-spoke pode ajudar com os seguintes requisitos:
- Os aplicativos precisam acessar um conjunto comum de serviços, como monitoramento, ferramentas de gerenciamento de configuração, CI/CD ou autenticação.
- Um conjunto comum de políticas de segurança precisa ser aplicado ao tráfego de entrada e saída de maneira centralizada pelo hub.
Para mais informações sobre opções de design hub-and-spoke, consulte Topologia hub-and-spoke com dispositivos centralizados e Topologia hub-and-spoke sem dispositivos centralizados.
Como mostrado no diagrama anterior, a comunicação entre VPCs e a conectividade híbrida passam pela VPC hub. Como parte desse padrão, é possível controlar e restringir a comunicação na VPC do hub para se alinhar aos seus requisitos de conectividade.
Como parte da arquitetura de rede hub-and-spoke, as seguintes são as principais opções de conectividade (entre as VPCs spoke e hub) no Google Cloud:
- Peering de rede VPC
- VPN
- Usando um dispositivo virtual de rede (NVA)
- Com várias interfaces de rede
- Com o Network Connectivity Center (NCC)
Para mais informações sobre qual opção considerar no seu design, consulte Arquitetura de rede hub and spoke. Um fator importante para selecionar a VPN em vez do peering de VPC entre os spokes e a VPC do hub é quando a transitividade de tráfego é necessária. A transitividade de tráfego significa que o tráfego de um spoke pode alcançar outros spokes pelo hub.
Arquitetura distribuída de microsserviços de confiança zero
As arquiteturas híbridas e multicloud podem exigir vários clusters para atingir os objetivos técnicos e comerciais, incluindo a separação do ambiente de produção dos ambientes de desenvolvimento e teste. Portanto, os controles de segurança do perímetro de rede são importantes, especialmente quando são necessários para atender a determinados requisitos de segurança.
Não basta oferecer suporte aos requisitos de segurança das arquiteturas de microsserviços distribuídos com priorização da nuvem atuais. Também é preciso considerar arquiteturas distribuídas de confiança zero. A arquitetura distribuída de confiança zero de microsserviços oferece suporte à sua arquitetura de microsserviços com aplicação de política de segurança no nível do microsserviço, autenticação e identidade da carga de trabalho. A confiança é baseada em identidade e aplicada a cada serviço.
Ao usar uma arquitetura de proxy distribuída, como uma malha de serviço, os serviços podem validar os chamadores e implementar políticas de controle de acesso refinadas para cada solicitação, permitindo um ambiente de microsserviços mais seguro e escalonável. O Cloud Service Mesh oferece a flexibilidade de ter uma malha comum que pode abranger suas implantaçõesGoogle Cloud e no local. A malha usa políticas de autorização para ajudar a proteger as comunicações entre serviços.
Você também pode incorporar o Adaptador da Apigee para Envoy, que é uma implantação leve de gateway de API da Apigee em um cluster do Kubernetes, com essa arquitetura. O adaptador da Apigee para Envoy é um proxy de serviço e borda de código aberto desenvolvido para aplicativos com priorização da nuvem.
Para mais informações sobre esse assunto, consulte os artigos a seguir:
- Arquitetura distribuída de confiança zero
- Ambiente híbrido do Google Kubernetes Engine (GKE)
- Conectar ao Google
- Conecte um cluster local a uma rede Google Cloud .
- Configurar uma malha híbrida ou de várias nuvens
- Implante o Cloud Service Mesh em ambientes e clusters.
Práticas recomendadas para padrão espelhado
- Os sistemas de CI/CD necessários para implantar ou reconfigurar implantações de produção precisam ter alta disponibilidade. Isso significa que todos os componentes da arquitetura precisam ser projetados para fornecer o nível esperado de disponibilidade do sistema. Para mais informações, consulte Confiabilidade da infraestrutura doGoogle Cloud .
- Para eliminar erros de configuração em processos repetidos, como atualizações de código, a automação é essencial para padronizar builds, testes e implantações.
- A integração de NVAs centralizados nesse design pode exigir a incorporação de vários segmentos com diferentes níveis de controles de acesso de segurança.
- Ao projetar uma solução que inclua NVAs, é importante considerar a alta disponibilidade (HA) dos NVAs para evitar um ponto único de falha que possam bloquear toda a comunicação. Siga o design de alta disponibilidade e redundância as orientações de implementação fornecidas pelo fornecedor do NVA.
- Ao não exportar rotas IP locais por peering de VPC ou VPN para a VPC de desenvolvimento e teste, é possível restringir a capacidade de alcance da rede dos ambientes de desenvolvimento e teste para o ambiente local. Para mais informações, consulte Troca de rotas personalizadas do peering de rede VPC.
- Para cargas de trabalho com endereçamento IP particular que podem exigir acesso às APIs do Google, é possível expor as APIs do Google usando um endpoint do Private Service Connect em uma rede VPC. Para mais informações, consulte Entrada controlada nesta série.
- Consulte as práticas recomendadas gerais para padrões de arquitetura de rede híbrida e multicloud.