El patrón duplicado se basa en replicar el diseño de un entorno o entornos concretos en otro u otros. Por lo tanto, este patrón se aplica principalmente a las arquitecturas que siguen el patrón entorno híbrido. En ese patrón, ejecutas tus cargas de trabajo de desarrollo y pruebas en un entorno, mientras que ejecutas tus cargas de trabajo de preproducción y producción en otro.
El patrón reflejado presupone que las cargas de trabajo de prueba y de producción no deben comunicarse directamente entre sí. Sin embargo, debería ser posible gestionar e implementar ambos grupos de cargas de trabajo de forma coherente.
Si usas este patrón, conecta los dos entornos informáticos de forma que se ajusten a los siguientes requisitos:
- La integración y la implementación continuas (CI/CD) pueden desplegar y gestionar cargas de trabajo en todos los entornos informáticos o en entornos específicos.
- Los sistemas de monitorización, gestión de la configuración y otros sistemas administrativos deben funcionar en todos los entornos informáticos.
- Las cargas de trabajo no pueden comunicarse directamente entre entornos informáticos. Si es necesario, la comunicación debe ser precisa 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, monitorización, gestión de la configuración, otros sistemas administrativos y comunicación de cargas de trabajo:
La descripción de la arquitectura del diagrama anterior es la siguiente:
- Las cargas de trabajo se distribuyen en función de los entornos funcionales (desarrollo, pruebas, CI/CD y herramientas administrativas) en VPCs independientes en el lado de Google Cloud .
- VPC compartida se usa para cargas de trabajo de desarrollo y pruebas. Se usa una VPC adicional para las herramientas de CI/CD y de administración. Con VPCs compartidas:
- Las aplicaciones las gestionan 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 de 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 cortafuegos 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 con el fin de prevenir amenazas sin cambiar el diseño ni el enrutamiento. El cortafuegos empresarial de nueva generación de Cloud funciona creando endpoints de cortafuegos zonales gestionados por Google que usan tecnología de interceptación de paquetes para inspeccionar de forma transparente las cargas de trabajo en busca de las firmas de amenazas configuradas. También protege las cargas de trabajo frente a las amenazas.
- Permite la comunicación entre las VPCs emparejadas mediante direcciones IP internas.
- El peering de este patrón permite que los sistemas de CI/CD y administrativos desplieguen y gestionen cargas de trabajo de desarrollo y pruebas.
- Consulta estas prácticas recomendadas generales.
Para establecer esta conexión de CI/CD, debes usar una de las opciones de conectividad de redes híbridas y multinube que se han descrito y que cumpla los requisitos de tu empresa y tus aplicaciones. Para que puedas implementar y gestionar 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 solapamientos.
Si las instancias de los entornos de desarrollo y de pruebas requieren acceso a Internet, considera las siguientes opciones:
- Puedes desplegar Cloud NAT en la misma red del proyecto del host de VPC compartida. Si implementas en la misma red del proyecto host de VPC compartida, evitarás que se pueda acceder directamente a estas instancias desde Internet.
- Para el tráfico web de salida, puedes usar Secure Web Proxy. El proxy ofrece varias ventajas.
Para obtener más información sobre las Google Cloud herramientas y las funciones que te ayudan a compilar, probar e implementar en Google Cloud y en entornos híbridos y multicloud, consulta la entrada de blog DevOps y CI/CD en Google Cloud : explicación.
Variantes
Para cumplir diferentes requisitos de diseño y, al mismo tiempo, tener en cuenta todos los requisitos de comunicación, el patrón de arquitectura reflejado ofrece estas opciones, que se describen en las siguientes secciones:
- VPC compartida por entorno
- Cortafuegos de capa de aplicación centralizado
- Topología de concentrador y radios
- 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 aplicación o de servicio entre entornos, incluidas las herramientas de CI/CD y las administrativas que puedan ser necesarias para cumplir determinados requisitos de seguridad de la organización. Estos requisitos limitan la comunicación, el dominio administrativo y el control de acceso de los diferentes servicios, que también deben gestionar distintos equipos.
Este diseño consigue la separación proporcionando aislamiento a nivel de red y de proyecto entre los distintos entornos, lo que permite una comunicación más precisa y un control de acceso de Gestión de Identidades y Accesos (IAM).
Desde el punto de vista de la gestión y las operaciones, este diseño ofrece la flexibilidad necesaria para gestionar 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 gestionar las redes de VPC y sus funciones de seguridad en función de las siguientes estructuras posibles:
- Un equipo gestiona todos los proyectos host en todos los entornos.
- Diferentes equipos gestionan los proyectos host en sus respectivos entornos.
Las decisiones sobre la gestión de proyectos 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 red de VPC compartida de cada opción de diseño de zona de aterrizaje del entorno. Sin embargo, debes tener en cuenta los requisitos de comunicación del patrón replicado 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 muestra en el siguiente diagrama:
Cortafuegos de capa de aplicación centralizado
En algunos casos, los requisitos de seguridad pueden exigir que se tengan en cuenta la capa de aplicación (capa 7) y la inspección profunda de paquetes con mecanismos de cortafuegos avanzados que superen las funciones del cortafuegos de nueva generación de Cloud. Para cumplir 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 partners de seguridad ofrecen opciones que se adaptan bien a esta tarea.
Como se muestra 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 mediante varias interfaces de red.
Este diseño también se puede usar con varias VPCs compartidas, como se muestra en el siguiente diagrama.
La NVA de este diseño actúa como capa de seguridad perimetral. También sirve de base para habilitar la inspección del tráfico en línea y aplicar políticas de control de acceso estrictas.
Para disfrutar de una estrategia de seguridad multicapa sólida que incluya reglas de cortafuegos de VPC y funciones de servicio de prevención de intrusiones, añade más inspección de tráfico y control de seguridad a los flujos de tráfico este-oeste y norte-sur.
.Topología de concentrador y radios
Otra posible variación del diseño es usar VPCs independientes (incluidas las VPCs compartidas) para el desarrollo y las diferentes fases de prueba. En esta variante, como se muestra en el siguiente diagrama, todos los entornos de staging se conectan con la VPC de CI/CD y la administrativa en una arquitectura de concentrador y radios. Usa esta opción si debes separar los dominios administrativos y las funciones de cada entorno. El modelo de comunicación de concentrador y radios puede ayudarte a cumplir los siguientes requisitos:
- Las aplicaciones necesitan acceder a un conjunto común de servicios, como la monitorización, las herramientas de gestión de la configuración, la integración continua y la entrega continua o la autenticación.
- Es necesario aplicar un conjunto común de políticas de seguridad al tráfico entrante y saliente de forma centralizada a través del centro de control.
Para obtener más información sobre las opciones de diseño de concentrador y radios, consulta Topología de concentrador y radios con dispositivos centralizados y Topología de concentrador y radios sin dispositivos centralizados.
Como se muestra en el diagrama anterior, la comunicación entre VPCs y la conectividad híbrida pasan por la VPC de concentrador. Como parte de este patrón, puedes controlar y restringir la comunicación en la VPC de concentrador para que se ajuste a tus requisitos de conectividad.
Como parte de la arquitectura de red en malla, estas son las principales opciones de conectividad (entre las VPCs de los radios y del centro) en Google Cloud:
- Emparejamiento entre redes VPC
- VPN
- Usar 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 tener en cuenta en tu diseño, consulta Arquitectura de red de concentrador y radios. Un factor clave que influye en la elección de una VPN en lugar del emparejamiento de VPC entre los radios y la VPC de concentrador es cuando se requiere la transitividad del tráfico. La transitividad del tráfico significa que el tráfico de un spoke puede llegar a otros spokes a través del centro de conectividad.
Arquitectura distribuida de confianza cero de microservicios
Las arquitecturas híbridas y multinube pueden requerir varios clústeres para alcanzar sus objetivos técnicos y empresariales, como separar el 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, sobre todo cuando se requieren para cumplir determinados requisitos de seguridad.
No basta con cumplir los requisitos de seguridad de las arquitecturas de microservicios distribuidas y basadas en la nube actuales, sino que también debes tener en cuenta las arquitecturas distribuidas de confianza cero. La arquitectura distribuida de confianza cero de microservicios admite tu arquitectura de microservicios con la aplicación de políticas de seguridad a nivel de microservicio, la autenticación y la identidad de la carga de trabajo. La confianza se basa en la identidad y se aplica a cada servicio.
Al usar una arquitectura de proxy distribuido, como una malla de servicios, los servicios pueden validar de forma eficaz a los llamantes e implementar políticas de control de acceso pormenorizado para cada solicitud, lo que permite crear un entorno de microservicios más seguro y escalable. Cloud Service Mesh te ofrece la flexibilidad de tener una malla común que puede abarcar tus despliegues deGoogle Cloud y on-premise. La malla usa políticas de autorización para proteger las comunicaciones entre servicios.
También puedes incorporar Apigee Adapter for Envoy, que es un despliegue ligero de la pasarela de APIs de Apigee en un clúster de Kubernetes, con esta arquitectura. Apigee Adapter for Envoy es un proxy de servicio y de edge de código abierto diseñado para aplicaciones 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 GKE Enterprise
- Conectar con Google
- Conecta un clúster de GKE Enterprise local a una redGoogle Cloud .
- Configurar una malla multinube o híbrida
- Despliega Cloud Service Mesh en entornos y clústeres.
Prácticas recomendadas para los patrones reflejados
- Los sistemas de integración y entrega continuas (CI/CD) necesarios para desplegar o reconfigurar las implementaciones de producción deben tener una alta disponibilidad, lo que significa que todos los componentes de la arquitectura deben diseñarse para proporcionar el nivel de disponibilidad del sistema esperado. Para obtener más información, consulta Google Cloud fiabilidad de la infraestructura.
- Para eliminar los errores de configuración en procesos repetidos, como las actualizaciones de código, es fundamental automatizar las compilaciones, las pruebas y los despliegues.
- La integración de NVAs centralizadas en este diseño puede requerir la incorporación de varios segmentos con diferentes niveles de controles de acceso de seguridad.
- Al diseñar una solución que incluya NVAs, es importante tener en cuenta la alta disponibilidad (HA) de las NVAs para evitar un único punto de fallo que pueda bloquear todas las comunicaciones. Sigue las directrices de diseño e implementación de alta disponibilidad y redundancia proporcionadas por tu proveedor de VNA.
- Si no exportas las rutas IP on-premise a través del emparejamiento de VPC o de la VPN a la VPC de desarrollo y pruebas, puedes restringir la accesibilidad de la red desde los entornos de desarrollo y pruebas al entorno on-premise. Para obtener más información, consulta el artículo Intercambio de rutas personalizadas en el emparejamiento entre redes de VPC.
- En el caso de las cargas de trabajo con direcciones IP privadas que requieran acceso a las APIs de Google, puedes exponer las APIs de Google mediante un punto final de Private Service Connect en una red de VPC. Para obtener más información, consulta Acceso restringido en esta serie.
- Consulta las prácticas recomendadas generales para los patrones de arquitectura de redes híbridas y multinube.