O padrão espelho é 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 enquanto executa as cargas de trabalho de preparo e produção em outro.
O padrão espelhado pressupõe que as cargas de trabalho de teste e de 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 estar alinhado com os seguintes requisitos:
- A integração contínua/implantação contínua (CI/CD, na sigla em inglês) 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 os 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, ferramentas administrativas e CI/CD) 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 VPCs compartilhadas:
- Os aplicativos são gerenciados por diferentes equipes 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, bem como fora da VPC.
- A VPC de CI/CD está conectada à rede que executa as cargas de trabalho de produção no seu ambiente de computação particular.
- As regras de firewall só permitem o tráfego permitido.
- Você também pode 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 alterar o design ou o roteamento. O Cloud Next Generation Firewall Enterprise cria 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. Ele 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 nesse 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.
Estabeleça essa conexão de CI/CD usando uma das opções de conectividade de rede híbrida e multicloud que atendam aos requisitos dos seus negócios e aplicativos. Para implantar e gerenciar 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 exigirem acesso à Internet, considere estas opções:
- É possível implantar o Cloud NAT na mesma rede do projeto host da VPC compartilhada. O provisionamento na mesma rede de projeto host da VPC compartilhada ajuda a evitar que essas instâncias sejam acessadas diretamente pela Internet.
- Para o tráfego de saída da Web, use o Proxy seguro da Web. 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 em Google Cloud e em ambientes híbridos e multicloud, consulte o blog DevOps e CI/CD no Google Cloud explicados (em inglês).
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 espelho 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-and-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 de aplicativos ou de nível de serviço entre ambientes, incluindo ferramentas de CI/CD e administrativas que podem ser necessárias para atender a determinados requisitos de segurança organizacionais. 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 fornecendo isolamento de rede e projeto entre os diferentes ambientes, o que permite uma comunicação mais detalhada e o 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 os workloads criados por diferentes equipes por ambiente e projeto de serviço. A rede VPC e os recursos de segurança dela podem ser provisionados e gerenciados por equipes de operações de rede com base nas seguintes estruturas:
- Uma equipe gerencia todos os projetos de host em todos os ambientes.
- Equipes diferentes gerenciam os projetos host nos respectivos ambientes.
As decisões sobre o gerenciamento de projetos de host devem ser baseadas na estrutura da equipe, nas operações de segurança e nos requisitos de acesso de cada equipe. É possível aplicar essa variação de design à rede VPC compartilhada para cada opção de design da zona de destino do ambiente. No entanto, é preciso considerar os requisitos de comunicação do padrão espelhado para definir quais comunicações são permitidas 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 do aplicativo (camada 7) e uma inspeção detalhada de pacotes com mecanismos avançados de firewall que excedam os recursos do firewall de última geração do Cloud. 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 de 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 neste 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 em várias camadas que inclui 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 o desenvolvimento e diferentes estágios de teste. Nesta variação, conforme mostrado no diagrama abaixo, todos os ambientes de estágio se conectam à VPC de CI/CD e administrativa 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-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 as opções de design hub and spoke, consulte Topologia hub and spoke com dispositivos centralizados e Topologia hub and spoke sem dispositivos centralizados.
Conforme mostrado no diagrama anterior, a comunicação inter-VPC e a conectividade híbrida passam pela VPC hub. Como parte desse padrão, é possível controlar e restringir a comunicação na VPC hub para se alinhar aos seus requisitos de conectividade.
Como parte da arquitetura de rede hub-and-spoke, estas são as principais opções de conectividade (entre as VPCs spoke e hub) no Google Cloud:
- Peering de rede VPC
- VPN
- Usar o 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 o VPN sobre o peering de VPC entre os raios e a VPC hub é quando a transitividade do tráfego é necessária. A transitividade do 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
Arquiteturas híbridas e multicloud podem exigir vários clusters para atingir 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 cumprir determinados requisitos de segurança.
Não basta oferecer suporte aos requisitos de segurança das arquiteturas de microsserviços distribuídos de nuvem, você também precisa considerar arquiteturas distribuídas de confiança zero. A arquitetura distribuída de microsserviços de confiança zero 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 na identidade e aplicada para cada serviço.
Ao usar uma arquitetura de proxy distribuída, como uma malha de serviço, os serviços podem validar eficazmente os autores de chamadas 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 flexibilidade para ter uma malha comum que pode abranger as 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 (link em inglês), 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 projetado para aplicativos com priorização da nuvem.
Para mais informações sobre esse assunto, consulte os seguintes artigos:
- Arquitetura distribuída de confiança zero
- Ambiente híbrido do GKE Enterprise
- Conectar ao Google
- Conecte um cluster do GKE Enterprise local a uma redeGoogle 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, ou seja, todos os componentes da arquitetura precisam ser projetados para fornecer o nível esperado de disponibilidade do sistema. Para mais informações, consulte Google Cloud confiabilidade da infraestrutura.
- 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 níveis variados 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 acessibilidade da rede dos ambientes de desenvolvimento e teste ao 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 Ingresso controlado nesta série.
- Consulte as práticas recomendadas gerais para padrões de arquitetura de rede híbrida e multicloud.