Desplegar el plano

Last reviewed 2024-12-13 UTC

En esta sección se describe el proceso que puedes usar para desplegar el blueprint, sus convenciones de nomenclatura y las alternativas a las recomendaciones del blueprint.

Resumen

Para implementar la arquitectura descrita en este documento, sigue los pasos que se indican en esta sección.

Implementar el blueprint en una nueva organización

Para implementar el blueprint en una nueva organización, haz lo siguiente: Google Cloud

  1. Crea tu infraestructura básica con el blueprint de bases empresariales. Haz lo siguiente:

    1. Crea una estructura de organización, incluidas carpetas para separar los entornos.
    2. Configura los permisos básicos de gestión de identidades y accesos para conceder acceso a los administradores de la plataforma para desarrolladores.
    3. Crea la red de VPC.
    4. Implementa la canalización de infraestructura de base.

    Si no utilizas el plano de los fundamentos de la empresa, consulta Implementar el plano sin el plano de los fundamentos de la empresa.

  2. Despliega el modelo de aplicación empresarial de la siguiente manera:

    1. El administrador de la plataforma para desarrolladores usa el flujo de procesamiento de la infraestructura base para crear el flujo de procesamiento de la infraestructura multiempresa, la fábrica de aplicaciones y el flujo de procesamiento de ámbito de flota.
    2. El administrador de la plataforma para desarrolladores usa la infraestructura multicliente para desplegar clústeres de GKE e infraestructura compartida.
    3. Los operadores de aplicaciones usan la fábrica de aplicaciones para incorporar nuevas aplicaciones. Los operadores añaden una o varias entradas al repositorio de la fábrica de aplicaciones, lo que activa la creación de recursos específicos de la aplicación.
    4. Los desarrolladores de aplicaciones usan el flujo de procesamiento de CI/CD de aplicaciones en su infraestructura específica de la aplicación para desplegar aplicaciones en la infraestructura multicliente.

Implementar el plano sin el plano de aspectos básicos de las empresas

Si no implementas el plano técnico de la aplicación empresarial en el plano técnico de las bases empresariales, sigue estos pasos:

  1. Crea los siguientes recursos:
    • Una jerarquía de organización con carpetas development, nonproduction y production
    • Una red de VPC compartida en cada carpeta
    • Un esquema de direcciones IP que tenga en cuenta los intervalos de IP necesarios para tus clústeres de GKE
    • Un mecanismo de DNS para tus clústeres de GKE
    • Políticas de cortafuegos que se ajusten a tu postura de seguridad
    • Mecanismo para acceder a las APIs de Google Cloud a través de direcciones IP privadas
    • Un mecanismo de conectividad con tu entorno local
    • Registro centralizado para seguridad y auditoría
    • Security Command Center para la monitorización de amenazas
    • Políticas de la organización que se ajusten a tu postura de seguridad
    • Una canalización que se puede usar para implementar la fábrica de aplicaciones, la canalización de infraestructura multiinquilino y la canalización de ámbito de flota
  2. Después de implementar los recursos, continúa con el paso 2 de Implementar el blueprint en una organización nueva.

Incorporar el blueprint a tu implementación de GKE

Para usar este blueprint, primero debes desplegar la plataforma para desarrolladores y, a continuación, desplegar las aplicaciones en ella. En la siguiente tabla se describe cómo puedes usar el blueprint si ya tienes aplicaciones en contenedores que se ejecutan en Google Cloud.

Uso actual Estrategia de migración

Ya tienes un flujo de procesamiento de CI/CD.

Puedes usar la arquitectura de flota y clúster del plano técnico incluso cuando se utilicen diferentes productos para la compilación y la implementación de aplicaciones. Como mínimo, te recomendamos que repliques las imágenes en dos regiones.

Tener una estructura organizativa que no coincida con el plan de la empresa.

Se recomienda tener al menos dos entornos para que las implementaciones secuenciales sean más seguras. No es necesario implementar entornos en VPCs compartidas o carpetas independientes. Sin embargo, no despliegues cargas de trabajo que pertenezcan a entornos diferentes en el mismo clúster.

No uses IaC.

Si tu proceso de implementación de aplicaciones actual no usa IaC, puedes evaluar tu preparación con el modelo de madurez de Terraform onGoogle Cloud . Importa recursos a otro proyecto de Terraform que esté organizado de forma similar a este blueprint, con la separación de las canalizaciones multicliente y por cliente. Para crear clústeres, puedes usar módulos de Terraform para Google Cloud.

Los clústeres se distribuyen en varios proyectos del mismo entorno.

Puedes agrupar clústeres de varios proyectos en una flota. Verifica que tus espacios de nombres tengan significados únicos en la misma flota. Antes de añadir clústeres a una flota, pide a los equipos que muevan sus aplicaciones a un espacio de nombres con un nombre único (por ejemplo, que no sea default).

Después, puedes agrupar los espacios de nombres en ámbitos.

Los clústeres están en una sola región.

No es necesario que uses varias regiones en producción y en entornos que no sean de producción para adoptar el plan.

Existen diferentes conjuntos de entornos.

Puedes modificar el plano para que admita más o menos de tres entornos.

La creación de clústeres se delega en los equipos de desarrolladores o de operadores de aplicaciones.

Para disfrutar de una plataforma de desarrollo más segura y coherente, puedes intentar transferir la propiedad de los clústeres de los equipos de aplicaciones al equipo de la plataforma de desarrollo. Si no puedes hacerlo, puedes adoptar muchas de las prácticas recomendadas. Por ejemplo, puedes añadir a una flota los clústeres que pertenezcan a distintos equipos de aplicaciones. Sin embargo, cuando combines clústeres con propiedad independiente, no uses la federación de identidades de carga de trabajo para GKE o Cloud Service Mesh, ya que no proporcionan suficiente control sobre quién puede afirmar qué identidades de carga de trabajo. En su lugar, usa una política de organización personalizada para evitar que los equipos habiliten estas funciones en los clústeres de GKE.

Aunque los clústeres estén agrupados en una flota, puedes auditar y aplicar políticas. Puedes usar una política de organización personalizada para requerir que los clústeres se creen en una flota que corresponda a la carpeta del entorno en la que se encuentre el proyecto del clúster. Puedes usar la configuración predeterminada de la flota para requerir que los clústeres nuevos usen el control de políticas.

Alternativas a las recomendaciones predeterminadas

En esta sección se describen alternativas a las recomendaciones predeterminadas que se incluyen en esta guía.

Área de decisión Posibles alternativas

Todas las aplicaciones se ejecutan en el mismo conjunto de cinco clústeres.

El plan usa un conjunto de cinco clústeres (dos en producción, dos en no producción y uno en desarrollo). Puedes modificar el plano para crear más conjuntos de cinco clústeres.

Asigna aplicaciones a conjuntos de cinco clústeres. No vincules los ámbitos de una aplicación ni los espacios de nombres de la flota a clústeres de otros conjuntos. Puede que quieras separar las aplicaciones en diferentes conjuntos de clústeres para completar actividades como las siguientes:

  • Agrupar algunas aplicaciones con problemas normativos especiales (por ejemplo, PCI-DSS).
  • Aísla las aplicaciones que requieran un tratamiento especial durante las actualizaciones del clúster (por ejemplo, las aplicaciones con estado que usen volúmenes persistentes).
  • Aísla las aplicaciones con perfiles de seguridad arriesgados (por ejemplo, procesar contenido proporcionado por el usuario en un lenguaje que no sea seguro para la memoria).
  • Aísla las aplicaciones que requieren GPUs, sensibilidad a los costes y sensibilidad al rendimiento.
  • Si te acercas al límite de clústeres de GKE en el número de nodos (65.000 nodos), puedes crear un nuevo conjunto de clústeres.
  • Usa otra VPC compartida para las aplicaciones que deban ejecutarse dentro de un perímetro de Controles de Servicio de VPC. Crea un conjunto de clústeres en el perímetro y otro fuera del perímetro.

No crees conjuntos de clústeres para cada aplicación o inquilino, ya que esta práctica puede provocar una de las siguientes situaciones:

  • Aplicaciones que no aprovechan bien el tamaño mínimo del clúster (3 VMs x 2 regiones) incluso con los tipos de instancia más pequeños disponibles.
  • Se ha perdido la oportunidad de reducir costes al no empaquetar en contenedores diferentes aplicaciones.
  • Planificación del crecimiento de la capacidad tediosa e incierta, ya que la planificación se aplica a cada aplicación de forma individual. Las predicciones de capacidad son más precisas cuando se hacen de forma agregada para un conjunto amplio de aplicaciones.
  • Retrasos en la creación de clústeres para nuevos inquilinos o aplicaciones, lo que reduce la satisfacción de los inquilinos con la plataforma. Por ejemplo, en algunas organizaciones, las asignaciones de direcciones IP necesarias pueden llevar tiempo y requerir aprobaciones adicionales.
  • Alcanzar el límite de clústeres privados en una red VPC.

Los entornos de producción y no producción tienen clústeres en dos regiones.

Para reducir la latencia de los usuarios finales en varias regiones, puedes desplegar las cargas de trabajo de producción y no de producción en más de dos regiones (por ejemplo, tres regiones para producción, tres regiones para no producción y una región para desarrollo). Esta estrategia de implementación aumenta el coste y la sobrecarga de mantener recursos en regiones adicionales.

Si todas las aplicaciones tienen requisitos de disponibilidad más bajos, puedes implementar cargas de trabajo de producción y no de producción en una sola región (un entorno de producción, un entorno que no sea de producción y un entorno de desarrollo). Esta estrategia ayuda a reducir los costes, pero no ofrece el mismo nivel de disponibilidad que una arquitectura birregional o multirregional.

Si las aplicaciones tienen diferentes requisitos de disponibilidad, puedes crear diferentes conjuntos de clústeres para diferentes aplicaciones (por ejemplo, cluster-set-1 con dos entornos de producción, dos entornos que no son de producción y un entorno de desarrollo, y cluster-set-2 con un entorno de producción, un entorno que no es de producción y un entorno de desarrollo).

La topología de concentrador y radios se adapta mejor a tus requisitos que la VPC compartida.

Puedes desplegar el blueprint en una configuración de concentrador y radios, donde cada entorno (desarrollo, producción y no producción) se aloja en su propio radio. La topología de concentrador y radios puede aumentar la segregación de los entornos. Para obtener más información, consulta la topología de red de concentrador y radios.

Cada aplicación tiene un repositorio de Git independiente.

Algunas organizaciones usan un único repositorio de Git (un monorepo) para todo el código fuente en lugar de varios repositorios. Si usas un monorrepositorio, puedes modificar el componente fábrica de aplicaciones del blueprint para que sea compatible con tu repositorio. Haz lo siguiente:

  • En lugar de crear un repositorio para cada aplicación nueva, crea un subdirectorio en el repositorio que ya tengas.
  • En lugar de dar permisos de propietario en el nuevo repositorio al grupo de desarrolladores de la aplicación, dale permiso de escritura en el repositorio y haz que el grupo de desarrolladores de la aplicación sea un revisor obligatorio de los cambios en el nuevo subdirectorio. Usa la función CODEOWNERS y la protección de ramas.

Siguientes pasos