Patrón duplicado

Last reviewed 2025-01-23 UTC

El patrón reflejo se basa en replicar el diseño de un entorno o entornos existentes en uno o más entornos nuevos. Por lo tanto, este patrón se aplica principalmente a las arquitecturas que siguen el patrón de entorno híbrido. En ese patrón, ejecutas las cargas de trabajo de desarrollo y de prueba en un entorno mientras ejecutas las cargas de trabajo de etapas de prueba y de producción en otro.

El patrón reflejado 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 alineen con los siguientes requisitos:

  • La integración continua/implementación continua (IC/EC) puede implementar y administrar las cargas de trabajo en todos los entornos de computación o en entornos específicos.
  • La supervisión, la administración de la configuración y otros sistemas administrativos deberían funcionar en todos los entornos de computación.
  • Las cargas de trabajo no pueden comunicarse directamente entre 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 configuraciones, otros sistemas administrativos y comunicación de cargas de trabajo:

Flujos de datos entre un CI/CD y una VPC de administrador en Google Cloud y un entorno de producción local Los datos también fluyen entre la VPC de CI/CD y los entornos de desarrollo y pruebas dentro de Google Cloud.

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, herramientas de CI/CD y administrativas) en VPC separadas en el lado Google Cloud .
  • La VPC compartida se usa para cargas de trabajo de desarrollo y prueba. Se usa una VPC adicional para las herramientas administrativas y de IC/CD. Con las VPC compartidas, puedes hacer lo siguiente:
    • Diferentes equipos administran las aplicaciones por entorno y por proyecto de servicio.
    • El proyecto host administra y controla los controles de seguridad y comunicación de red 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 permitido.
    • También puedes usar Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para implementar una 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 mediante la creación de 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 VPC vinculadas con direcciones IP internas.
    • El intercambio de tráfico en este patrón permite que los sistemas administrativos y de IC/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 múltiples que se mencionaron antes y que cumplan 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 de 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 directamente a estas instancias 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 Google Cloud herramientas y capacidades que te ayudan a compilar, probar e implementar en Google Cloud y en entornos híbridos y de múltiples nubes, consulta el blog DevOps y CI/CD en Google Cloud explicado.

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 reflejo ofrece estas opciones, que se describen en las siguientes secciones:

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 de CI/CD y administrativas 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 de 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).

Desde una perspectiva de administración y operaciones, este diseño proporciona la flexibilidad para administrar las aplicaciones y las cargas de trabajo que crean diferentes equipos por entorno y por proyecto de servicio. Los equipos de operaciones de red 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 de 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é tipo de 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:

El intercambio de tráfico de VPC en Google Cloud comparte datos entre los entornos de desarrollo y de prueba, y las subredes administrativas y de CI/CD. Las subredes comparten datos entre Google Cloud y un entorno local.

Firewall centralizado de la capa de aplicación

En algunos casos, los requisitos de seguridad pueden exigir la consideración de la capa de aplicación (capa 7) y la inspección profunda de paquetes con mecanismos avanzados de firewall que superan 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 mediante varias interfaces de red.

El intercambio de tráfico de VPC en Google Cloud comparte datos entre entornos de desarrollo y de prueba, y subredes administrativas y de CI/CD. Las subredes comparten datos entre Google Cloud y un entorno local a través de una red de VPC de tránsito.

Este diseño también se puede usar con varias VPC compartidas, como se ilustra en el siguiente diagrama.

El intercambio de tráfico de VPC en Google Cloud comparte datos entre entornos de desarrollo y de prueba, y subredes administrativas y de CI/CD. Las subredes usan una NVA para compartir datos entre Google Cloud y un entorno local a través de una red de VPC de tránsito.

La NVA en este diseño actúa como la capa de seguridad perimetral. También sirve como base para habilitar la inspección de tráfico intercalado y aplicar políticas de control de acceso estrictas.

Para obtener una estrategia de seguridad sólida de varias capas que incluya reglas de firewall de VPC y capacidades del servicio de prevención de intrusiones, incluye más inspecciones de tráfico y control de seguridad en los flujos de tráfico este-oeste y norte-sur.

Topología de concentrador y radio

Otra posible variación de diseño es usar VPC independientes (incluidas las VPC compartidas) para tu desarrollo y las diferentes etapas de prueba. En esta variación, como se muestra en el siguiente diagrama, todos los entornos de etapa se conectan con la VPC administrativa y de CI/CD en una arquitectura de concentrador y radios. Usa esta opción si debes separar los dominios administrativos y las funciones en cada entorno. El modelo de comunicación de metrópolis y radios puede ayudarte con los siguientes requisitos:

  • Las aplicaciones deben acceder a un conjunto común de servicios, como la supervisión, las herramientas de administración de parámetros de configuración, CI/CD o la 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.

Los entornos de desarrollo y pruebas comparten datos con un centro de CI/CD de VPC y una VPC de administrador con un entorno local.

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 alinearla con tus requisitos de conectividad.

Como parte de la arquitectura de red de concentrador y radios, las siguientes son las opciones de conectividad principales (entre los radios y las VPC del concentrador) en Google Cloud:

  • Intercambio de tráfico entre redes de VPC
  • VPN
  • Con un dispositivo virtual de red (NVA)

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 la VPN sobre el intercambio de tráfico entre VPC entre los radios y el VPC del concentrador 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 requiere cumplir con ciertos requisitos de seguridad.

No es suficiente admitir los requisitos de seguridad de las arquitecturas de microservicios distribuidas actuales que priorizan la nube. También debes considerar 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, la autenticación y la identidad de la carga de trabajo a nivel de microservicios. La confianza se basa en la identidad y se aplica para cada servicio.

Cuando se usa una arquitectura de proxy distribuida, como una malla de servicios, los servicios pueden validar de manera eficaz a los llamadores y, además, implementar políticas de control de acceso detallado para cada solicitud, lo que permite crear 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 implementaciones deGoogle 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 liviana de la puerta de enlace de API de Apigee en 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.

Los datos fluyen entre los servicios en Google Cloud y un entorno local a través de una arquitectura de proxy distribuida.

Para obtener más información sobre este tema, consulta los siguientes artículos:

Prácticas recomendadas para patrones simétricos

  • 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 Confiabilidad de la infraestructura deGoogle Cloud .
  • Para eliminar los errores de configuración de los procesos repetidos, como las actualizaciones de código, la automatización es esencial para estandarizar tus compilaciones, pruebas e implementaciones.
  • La integración de NVA 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 NVA, es importante tener en cuenta la alta disponibilidad (HA) de las NVA para evitar un punto único de fallo que podría bloquear toda la comunicación. Sigue la guía de diseño y de implementación de la HA y la redundancia que te proporciona tu proveedor de NVA.
  • Si no exportas las rutas de IP locales a través del intercambio de tráfico entre VPC o 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 local. Para obtener más información, consulta Intercambio de rutas personalizado del intercambio de tráfico entre redes de VPC.
  • En el caso de las cargas de trabajo con direcciones IP privadas que pueden requerir acceso a las APIs de Google, puedes exponer las APIs de Google mediante un extremo de Private Service Connect dentro de una red de VPC. Para obtener más información, consulta Ingresos con control de acceso en esta serie.
  • Revisa las prácticas recomendadas generales para los patrones de arquitectura de redes híbridas y de múltiples nubes.