El patrón duplicado se basa en replicar el diseño de un entorno o entornos existentes determinados en un entorno o entornos nuevos. Por lo tanto, este patrón se aplica principalmente a las arquitecturas que siguen el patrón de híbrido de entorno. En ese patrón, ejecutas tus cargas de trabajo de desarrollo y prueba en un entorno, mientras que ejecutas tus cargas de trabajo de producción y de etapa de prueba en otro.
El patrón duplicado supone que las cargas de trabajo de prueba y de producción no deben comunicarse directamente entre sí. Sin embargo, debería ser posible implementar y administrar ambos grupos de cargas de trabajo de manera coherente.
Si usas este patrón, conecta los dos entornos de computación de manera tal que se cumplan los siguientes requisitos:
- La integración continua/implementación continua (CI/CD) puede implementar y administrar cargas de trabajo en todos los entornos de computación o en entornos específicos.
- Los sistemas de supervisión, administración de la configuración y otros sistemas administrativos deben funcionar en todos los entornos de computación.
- Las cargas de trabajo no pueden comunicarse directamente entre los entornos de computación. Si es necesario, la comunicación debe ser detallada y controlada.
Arquitectura
En el siguiente diagrama de arquitectura, se muestra una arquitectura de referencia de alto nivel de este patrón que admite CI/CD, supervisión, administración de la configuración, otros sistemas administrativos y comunicación de cargas de trabajo:
La descripción de la arquitectura en el diagrama anterior es la siguiente:
- Las cargas de trabajo se distribuyen según los entornos funcionales (desarrollo, pruebas, herramientas administrativas y de CI/CD) en VPC independientes en el lado de Google Cloud .
- La VPC compartida se usa para las cargas de trabajo de desarrollo y prueba. Se usa una VPC adicional para las herramientas administrativas y de CI/CD. Con las VPC compartidas:
- Las aplicaciones son administradas por diferentes equipos por entorno y por proyecto de servicio.
- El proyecto host administra y controla la comunicación de red y los controles de seguridad entre los entornos de desarrollo y prueba, así como fuera de la VPC.
- La VPC de CI/CD está conectada a la red que ejecuta las cargas de trabajo de producción en tu entorno de computación privado.
- Las reglas de firewall solo permiten el tráfico autorizado.
- También puedes usar Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para implementar la inspección profunda de paquetes para la prevención de amenazas sin cambiar el diseño ni el enrutamiento. Cloud Next Generation Firewall Enterprise funciona creando extremos de firewall zonales administrados por Google que usan tecnología de interceptación de paquetes para inspeccionar con transparencia las cargas de trabajo en busca de las firmas de amenazas configuradas. También protege las cargas de trabajo contra amenazas.
- Permite la comunicación entre las VPCs interconectadas a través de direcciones IP internas.
- El intercambio de tráfico en este patrón permite que los sistemas administrativos y de CI/CD implementen y administren las cargas de trabajo de desarrollo y de prueba.
- Considera estas prácticas recomendadas generales.
Para establecer esta conexión de CI/CD, usa una de las opciones de conectividad de redes híbridas y de múltiples nubes que se analizaron y que cumplen con los requisitos de tu empresa y tus aplicaciones. Para permitirte implementar y administrar cargas de trabajo de producción, esta conexión proporciona accesibilidad a la red privada entre los diferentes entornos de computación. Todos los entornos deben tener un espacio de direcciones IP RFC 1918 sin superposición.
Si las instancias en los entornos de desarrollo y pruebas requieren acceso a Internet, considera las siguientes opciones:
- Puedes implementar Cloud NAT en la misma red del proyecto host de la VPC compartida. La implementación en la misma red del proyecto host de VPC compartida ayuda a evitar que se pueda acceder a estas instancias directamente desde Internet.
- Para el tráfico web saliente, puedes usar el proxy web seguro. El proxy ofrece varios beneficios.
Para obtener más información sobre las herramientas y capacidades de Google Cloud que te ayudan a compilar, probar y realizar implementaciones en Google Cloud y en entornos híbridos y de múltiples nubes, consulta el blog DevOps y CI/CD en Google Cloud explicados.
Variantes
Para cumplir con diferentes requisitos de diseño y, al mismo tiempo, tener en cuenta todos los requisitos de comunicación, el patrón de arquitectura duplicada ofrece las siguientes opciones, que se describen en las secciones a continuación:
- VPC compartida por entorno
- Firewall de capa de aplicación centralizado
- Topología de concentrador y radio
- Arquitectura distribuida de confianza cero de microservicios
VPC compartida por entorno
La opción de diseño de VPC compartida por entorno permite la separación a nivel de la aplicación o del servicio en todos los entornos, incluidas las herramientas administrativas y de CI/CD que podrían ser necesarias para cumplir con ciertos requisitos de seguridad de la organización. Estos requisitos limitan la comunicación, el dominio administrativo y el control de acceso para los diferentes servicios que también deben administrar diferentes equipos.
Este diseño logra la separación proporcionando aislamiento a nivel de la red y del proyecto entre los diferentes entornos, lo que permite una comunicación más detallada y un control de acceso de Identity and Access Management (IAM) más preciso.
Desde una perspectiva de administración y operaciones, este diseño proporciona la flexibilidad necesaria para administrar las aplicaciones y las cargas de trabajo creadas por diferentes equipos por entorno y por proyecto de servicio. Los equipos de operaciones de redes pueden aprovisionar y administrar las redes de VPC y sus funciones de seguridad según las siguientes estructuras posibles:
- Un equipo administra todos los proyectos host en todos los entornos.
- Diferentes equipos administran los proyectos host en sus respectivos entornos.
Las decisiones sobre la administración de proyectos de host deben basarse en la estructura del equipo, las operaciones de seguridad y los requisitos de acceso de cada equipo. Puedes aplicar esta variación de diseño a la opción de diseño de zona de destino de red de VPC compartida para cada entorno. Sin embargo, debes tener en cuenta los requisitos de comunicación del patrón duplicado para definir qué comunicación se permite entre los diferentes entornos, incluida la comunicación a través de la red híbrida.
También puedes aprovisionar una red de VPC compartida para cada entorno principal, como se ilustra en el siguiente diagrama:
Firewall centralizado de la capa de aplicación
En algunas situaciones, los requisitos de seguridad pueden exigir que se considere la capa de aplicación (capa 7) y la inspección profunda de paquetes con mecanismos avanzados de firewall que superen las capacidades de Cloud Next Generation Firewall. Para cumplir con los requisitos y estándares de seguridad de tu organización, puedes usar un dispositivo NGFW alojado en un dispositivo virtual de red (NVA). Varios Google Cloud socios de seguridad ofrecen opciones adecuadas para esta tarea.
Como se ilustra en el siguiente diagrama, puedes colocar la NVA en la ruta de red entre la nube privada virtual y el entorno de computación privado con varias interfaces de red.
Este diseño también se puede usar con varias VPC compartidas, como se ilustra en el siguiente diagrama.
En este diseño, la NVA actúa como la capa de seguridad perimetral. También sirve como base para habilitar la inspección de tráfico intercalada y aplicar políticas estrictas de control de acceso.
Para una estrategia de seguridad sólida de varias capas que incluya reglas de firewall de VPC y capacidades de servicio de prevención de intrusiones, incluye una mayor inspección del tráfico y control de seguridad para los flujos de tráfico este-oeste y norte-sur.
Topología de concentrador y radio
Otra posible variación del diseño es usar VPCs separadas (incluidas las VPCs compartidas) para el desarrollo y las diferentes etapas de prueba. En esta variación, como se muestra en el siguiente diagrama, todos los entornos de etapa de desarrollo se conectan con la VPC administrativa y de CI/CD en una arquitectura de concentrador y radio. Usa esta opción si debes separar los dominios administrativos y las funciones en cada entorno. El modelo de comunicación de concentrador y radio puede ayudarte con los siguientes requisitos:
- Las aplicaciones deben acceder a un conjunto común de servicios, como supervisión, herramientas de administración de configuración, CI/CD o autenticación.
- Se debe aplicar un conjunto común de políticas de seguridad al tráfico entrante y saliente de forma centralizada a través del concentrador.
Para obtener más información sobre las opciones de diseño de concentrador y radio, consulta Topología de concentrador y radio con dispositivos centralizados y Topología de concentrador y radio sin dispositivos centralizados.
Como se muestra en el diagrama anterior, la comunicación entre VPC y la conectividad híbrida pasan por la VPC central. Como parte de este patrón, puedes controlar y restringir la comunicación en la VPC del concentrador para que se alinee con tus requisitos de conectividad.
Como parte de la arquitectura de red de concentrador y radio, las siguientes son las principales opciones de conectividad (entre las VPC de radio y de concentrador) en Google Cloud:
- Intercambio de tráfico entre redes de VPC
- VPN
- Uso de un dispositivo virtual de red (NVA)
- Con varias interfaces de red
- Con Network Connectivity Center (NCC)
Para obtener más información sobre qué opción debes considerar en tu diseño, consulta Arquitectura de red de concentrador y radio. Un factor clave que influye en la selección de VPN en lugar del intercambio de tráfico entre VPCs entre las VPCs radiales y la VPC central es cuando se requiere la transitividad del tráfico. La transitividad del tráfico significa que el tráfico de un radio puede llegar a otros radios a través del concentrador.
Arquitectura distribuida de confianza cero de microservicios
Las arquitecturas híbridas y de múltiples nubes pueden requerir varios clústeres para lograr sus objetivos técnicos y comerciales, incluida la separación del entorno de producción de los entornos de desarrollo y pruebas. Por lo tanto, los controles de seguridad del perímetro de la red son importantes, en especial cuando se requieren para cumplir con ciertos requisitos de seguridad.
No basta con satisfacer los requisitos de seguridad de las arquitecturas de microservicios distribuidas actuales que priorizan la nube, sino que también debes considerar las arquitecturas distribuidas de confianza cero. La arquitectura distribuida de confianza cero de microservicios admite tu arquitectura de microservicios con aplicación de la política de seguridad a nivel del microservicio, autenticación e identidad de la carga de trabajo. La confianza se basa en la identidad y se aplica para cada servicio.
Con una arquitectura de proxy distribuido, como una malla de servicios, los servicios pueden validar de manera eficaz a los llamadores y aplicar políticas de control de acceso detalladas para cada solicitud, lo que permite un entorno de microservicios más seguro y escalable. Cloud Service Mesh te brinda la flexibilidad de tener una malla común que puede abarcar tus implementacionesGoogle Cloud y locales. La malla usa políticas de autorización para ayudar a proteger las comunicaciones de servicio a servicio.
También puedes incorporar Apigee Adapter for Envoy, que es una implementación de puerta de enlace de API de Apigee liviana dentro de un clúster de Kubernetes, con esta arquitectura. El adaptador de Apigee para Envoy es un proxy de servicio y de código abierto diseñado para las aplicaciones centradas en la nube.
Para obtener más información sobre este tema, consulta los siguientes artículos:
- Arquitectura distribuida de confianza cero
- Entorno híbrido de Google Kubernetes Engine (GKE)
- Conectar con Google
- Conecta un clúster local a una red deGoogle Cloud .
- Configura una malla híbrida o de múltiples nubes
- Implementa Cloud Service Mesh en entornos y clústeres.
Prácticas recomendadas para el patrón duplicado
- Los sistemas de CI/CD necesarios para implementar o reconfigurar implementaciones de producción deben tener alta disponibilidad, lo que significa que todos los componentes de la arquitectura deben diseñarse para proporcionar el nivel esperado de disponibilidad del sistema. Para obtener más información, consulta Google Cloud confiabilidad de la infraestructura.
- Para eliminar los errores de configuración en procesos repetidos, como las actualizaciones de código, la automatización es fundamental para estandarizar tus compilaciones, pruebas e implementaciones.
- La integración de NVAs centralizados en este diseño puede requerir la incorporación de varios segmentos con diferentes niveles de controles de acceso de seguridad.
- Cuando diseñes una solución que incluya AVN, es importante tener en cuenta la alta disponibilidad (AD) de las AVN para evitar un único punto de falla que pueda bloquear toda la comunicación. Sigue la guía de diseño e implementación de alta disponibilidad y redundancia que te proporciona tu proveedor de NVA.
- Si no exportas las rutas IP locales a través del intercambio de tráfico entre VPCs o la VPN a la VPC de desarrollo y pruebas, puedes restringir la accesibilidad a la red desde los entornos de desarrollo y pruebas al entorno local. Para obtener más información, consulta Intercambio de rutas personalizadas del intercambio de tráfico entre redes de VPC.
- Para las cargas de trabajo con direcciones IP privadas que pueden requerir acceso a las APIs de Google, puedes exponer las APIs de Google con un extremo de Private Service Connect dentro de una red de VPC. Para obtener más información, consulta Ingreso controlado en esta serie.
- Revisa las prácticas recomendadas generales para los patrones de arquitectura de redes híbridas y de múltiples nubes.