El plano de la aplicación empresarial se implementa a través de una serie de sistemas y canalizaciones automatizados. Cada canalización implementa un aspecto en particular del plano. Las canalizaciones proporcionan un mecanismo controlable, auditable y repetible para compilar el plano. En el siguiente diagrama, se muestra la interacción de las diversas canalizaciones, los repositorios y las personas.
El plano usa las siguientes canalizaciones:
- La canalización de infraestructura de base (parte del plano de bases empresariales) implementa la fábrica de aplicaciones, la canalización de infraestructura multiusuario y la canalización de alcance de flota.
- La canalización de infraestructura multiusuario implementa los clústeres de GKE y los otros servicios administrados en los que se basa el plano de la aplicación empresarial.
- La canalización con alcance de flota configura los permisos de la flota, los espacios de nombres y los roles y las vinculaciones de RBAC.
- La fábrica de aplicaciones proporciona un mecanismo para implementar canalizaciones de aplicaciones nuevas a través de un proceso con plantilla.
- La canalización de CI/CD de la aplicación proporciona una canalización de CI/CD para implementar servicios en clústeres de GKE.
- El Sincronizador de configuración implementa y mantiene configuraciones adicionales de Kubernetes, incluidas las restricciones de Policy Controller.
Repositorios, colaboradores del repositorio y responsables de aprobación de cambios del repositorio
Las canalizaciones de plano se activan mediante cambios en los repositorios de Git. En la tabla siguiente, se describen los repositorios que se usan en todo el plano, quién contribuye al repositorio, quién aprueba los cambios en el repositorio, qué canalización usa el repositorio y la descripción de lo que contiene el repositorio.
| Repositorio | Colaborador del repositorio | Responsable de aprobación de cambios del repositorio | Canalización | Descripción |
|---|---|---|---|---|
|
Desarrollador de la plataforma para desarrolladores |
Administrador de la plataforma para desarrolladores |
Canalización de infraestructura de base |
Repositorio que contiene el código para implementar la canalización de infraestructura multiusuario, la aplicación y la canalización con alcance de flota |
|
Desarrollador de la plataforma para desarrolladores |
Administrador de la plataforma para desarrolladores |
Infraestructura multiusuario |
Los módulos de Terraform que usan los equipos de plataformas de desarrolladores cuando crean la infraestructura |
|
Desarrollador de la plataforma para desarrolladores |
Administrador de la plataforma para desarrolladores |
Alcance de la flota |
El repositorio que define los permisos del equipo de la flota y los espacios de nombres en la flota |
|
Desarrollador de la plataforma para desarrolladores |
Administrador de la plataforma para desarrolladores |
Fábrica de aplicaciones |
El código que define el repositorio de la aplicación y hace referencia a los módulos en el repositorio |
|
Desarrollador de aplicaciones |
Operador de aplicaciones |
Fábrica de aplicaciones |
El código base que se coloca en el repositorio |
|
Desarrollador de la plataforma para desarrolladores |
Administrador de la plataforma para desarrolladores |
Fábrica de aplicaciones Infraestructura multiusuario |
Los módulos de Terraform que definen la aplicación y la infraestructura |
|
Desarrollador de aplicaciones |
Operador de aplicaciones |
CI/CD de aplicaciones |
El código de la aplicación que se implementa en los clústeres de GKE |
|
Desarrollador de la plataforma para desarrolladores |
Administrador de la plataforma para desarrolladores |
Sincronizador de configuración |
Las políticas que usan los clústeres de GKE para mantener sus configuraciones |
Las canalizaciones automatizadas ayudan a compilar la seguridad, la auditabilidad, la trazabilidad, la capacidad de repetición y la capacidad de control y cumplimiento en el proceso de implementación. Si usas sistemas diferentes que tienen diferentes permisos y colocas a diferentes personas en grupos operativos diferentes, creas la separación de responsabilidades y sigues el principio de privilegio mínimo.
Canalización de infraestructura de base
La canalización de infraestructura de base se describe en el plano de bases empresariales y se usa como un punto de entrada genérico para implementaciones de recursos adicionales. En la siguiente tabla, se describen los componentes que crea la canalización.
| Componente | Descripción |
|---|---|
Crea la infraestructura compartida que usan todos los usuarios de la plataforma para desarrolladores. |
|
Crea espacios de nombres y vinculaciones de roles de RBAC. |
|
Crea las canalizaciones de CI/CD de aplicaciones que se usan para implementar los servicios. |
Canalización de infraestructura de multiusuarios
La canalización de infraestructura de infraestructura de varios usuarios implementa flotas, clústeres de GKE y recursos compartidos relacionados. En el siguiente diagrama, se muestran los componentes de la canalización de infraestructura multiusuario.
En la siguiente tabla, se describen los componentes que compila la canalización de infraestructura de varios usuarios.
| Componente | Descripción |
|---|---|
Clústeres de GKE |
Proporciona hosting para los servicios de la aplicación alojada en contenedores. |
Policy Controller |
Proporciona políticas que ayudan a garantizar la configuración adecuada de los clústeres y servicios de GKE. |
Sincronizador de configuración |
Aplica las políticas de Policy Controller a los clústeres y mantiene una aplicación coherente de las políticas. |
Crea la clave de encriptación basada en la clave de encriptación administrada por el cliente (CMEK) para GKE, AlloyDB para PostgreSQL y Secret Manager. |
|
Secret de Secret Manager |
Proporciona un almacén de Secrets para el par de claves RSA que se usa en la autenticación de usuarios con tokens web JSON (JWT). |
Proporciona la política que usa el firewall de aplicación web de Google Cloud Armor. |
Canalización con permiso de flota
La canalización con permisos de flota es responsable de configurar los espacios de nombres y las vinculaciones de RBAC en los clústeres de GKE de la flota. En la siguiente tabla, se describen los componentes que compila la canalización con permiso de flota.
| Componente | Descripción |
|---|---|
Define los clústeres lógicos dentro del clúster físico. |
|
Define la autorización que tiene una cuenta de servicio de Kubernetes a nivel de clúster o de espacio de nombres. |
Fábrica de aplicaciones
La canalización de infraestructura de base implementa la fábrica de la aplicación y se usa a fin de crear infraestructura para cada aplicación nueva. Esta infraestructura incluye un proyecto de Google Cloud que contiene la canalización de CI/CD de la aplicación.
A medida que las organizaciones de ingeniería escalan, el equipo de la aplicación puede incorporar aplicaciones nuevas mediante la fábrica de aplicaciones. El escalamiento permite el crecimiento mediante la adición de canalizaciones de CI/CD de aplicaciones discretas y la compatibilidad con la infraestructura para implementar aplicaciones nuevas en la arquitectura multiusuario. En el siguiente diagrama, se muestra la fábrica de aplicaciones.
La fábrica de aplicaciones tiene los siguientes componentes:
- Repositorio de la fábrica de aplicaciones: Un repositorio de Git que almacena la definición declarativa de las aplicaciones.
- Canalizaciones para crear aplicaciones: Canalizaciones que requieren Cloud Build a fin de completar lo siguiente:
- Crear una definición declarativa de la aplicación y almacenarla en el catálogo de aplicaciones.
- Aplica la definición declarativa de la aplicación para crear los recursos de la aplicación.
- Repositorio de plantillas de aplicación de inicio: Son plantillas para crear una aplicación simple (por ejemplo, un microservicio de Java, Python o Golang).
- Módulos compartidos: módulos de Terraform que se crean con prácticas estándar y se usan para varios propósitos, incluida la integración y la implementación de aplicaciones.
En la siguiente tabla, se enumeran los componentes que crea la fábrica de aplicaciones para cada aplicación.
| Componente | Descripción |
|---|---|
Repositorio de código fuente de la aplicación |
Contiene el código fuente y la configuración relacionada que se usa para compilar e implementar una aplicación específica. |
Canalización de CI/CD de la aplicación |
Una canalización basada en Cloud Build que se usa para conectarse al repositorio de código fuente y proporciona una canalización de CI/CD a fin de implementar servicios de aplicaciones. |
Canalización de CI/CD de la aplicación
La canalización de CI/CD de la aplicación permite la compilación y la implementación automatizadas de aplicaciones basadas en contenedores. La canalización consta de pasos de integración continua (CI) y de implementación continua (CD). La arquitectura de la canalización se basa en el plano de CI/CD segura.
La canalización de CI/CD de la aplicación usa imágenes de contenedor inmutables en tus entornos. Las imágenes de contenedor inmutables ayudan a garantizar que la misma imagen se implemente en todos los entornos y no se modifique mientras el contenedor se ejecuta. Si debes actualizar el código de la aplicación o aplicar un parche, compila una imagen nueva y vuelve a implementarla. El uso de imágenes de contenedor inmutables requiere que externalices la configuración de tu contenedor para que la información de configuración se lea durante el tiempo de ejecución.
Para llegar a los clústeres de GKE a través de una ruta de red privada y administrar la autenticación kubeconfig, la canalización de CI/CD de la aplicación interactúa con los clústeres de GKE a través de la puerta de enlace de Connect. La canalización también usa grupos privados para el entorno de CI/CD.
Cada repositorio de código fuente de la aplicación incluye configuraciones de Kubernetes. Estas configuraciones permiten que las aplicaciones se ejecuten correctamente como servicios de Kubernetes en GKE. En la siguiente tabla, se describen los tipos de configuraciones de Kubernetes que aplica la canalización de CI/CD de la aplicación.
| Componente | Descripción |
|---|---|
Define un conjunto escalado de Pods (contenedores). |
|
Permite que se pueda acceder a una implementación a través de la red del clúster. |
|
Hace que una parte del servicio sea parte de la malla de servicios. |
|
Define cómo los pares en la malla de servicios deben llegar a un servicio virtual. Se usa en el plano a fin de configurar el balanceo de cargas de localidad para el tráfico este-oeste. |
|
Configura el control de acceso entre las cargas de trabajo en la malla de servicios. |
|
Define una identidad que usa un Service de Kubernetes. Workload Identity define la cuenta de servicio de Google Cloud que se usa para acceder a los recursos de Google Cloud. |
|
Permite que el tráfico de entrada externo llegue a un servicio. Solo las implementaciones que reciben tráfico externo requieren la puerta de enlace. |
|
Configurar SSL, Google Cloud Armor, la afinidad de sesión y el vaciado de conexiones para implementaciones que reciben tráfico externo. Solo las implementaciones que reciben tráfico externo usan GCPBackendPolicy. |
|
Configura la recopilación de métricas de Prometheus que exporta una aplicación. |
Integración continua
En el siguiente diagrama, se muestra el proceso de integración continua.
El proceso es el siguiente:
- Un desarrollador confirma el código de la aplicación en el repositorio de código fuente de la aplicación. Esta operación activa Cloud Build para comenzar la canalización de integración.
- Cloud Build crea una imagen de contenedor, envía la imagen de contenedor a Artifact Registry y crea un resumen de imágenes.
- Cloud Build realiza pruebas automatizadas para la aplicación. Según el lenguaje de aplicación, se pueden realizar diferentes paquetes de prueba.
- Cloud Build realiza los siguientes análisis en la imagen del contenedor:
- Cloud Build analiza el contenedor con el framework Container Structure Tests. Este framework realiza pruebas de comandos, de existencia de archivos, de contenido de archivos y de metadatos.
- Cloud Build usa el análisis de vulnerabilidades para identificar las vulnerabilidades de la imagen de contenedor en las bases de datos de vulnerabilidades que Google Cloud mantiene.
- Cloud Build aprueba la imagen para continuar en la canalización después de los resultados de análisis exitosos.
- La autorización binaria firma la imagen. La autorización binaria es un servicio en Google Cloud que proporciona seguridad para la cadena de suministro de software a las aplicaciones basadas en contenedores mediante el uso de políticas, reglas, notas, certificaciones, certificadores y firmantes. En el momento de la implementación, el ejecutor de políticas de la autorización binaria ayuda a garantizar la procedencia del contenedor antes de permitir su implementación.
- Cloud Build crea una versión en Cloud Deploy para comenzar el proceso de implementación.
Para ver la información de seguridad de una compilación, ve al panel de Estadísticas de seguridad. Estas estadísticas incluyen vulnerabilidades que se detectaron mediante Artifact Analysis y el nivel de seguridad de seguridad de la compilación indicado en los lineamientos de SLSA.
Cuando compilas tu aplicación, debes seguir las prácticas recomendadas para compilar contenedores.
Implementación continua
En el siguiente diagrama, se muestra el proceso de implementación continua.
El proceso es el siguiente:
- Al final del proceso de compilación, la canalización de CI/CD de la aplicación crea una versión nueva de Cloud Deploy para iniciar las imágenes de contenedor recién compiladas de forma progresiva a cada entorno.
- Cloud Deploy inicia un lanzamiento en el primer entorno de la canalización de implementación, que suele ser de desarrollo. Cada etapa de implementación está configurada para requerir aprobación manual.
- Las canalizaciones de Cloud Deploy usan una implementación secuencial para implementar imágenes en cada clúster de un entorno en orden.
- Al final de cada etapa de implementación, Cloud Deploy verifica la funcionalidad de los contenedores implementados. Estos pasos se pueden configurar dentro de la configuración de Skaffold para las aplicaciones.
Implementa una aplicación nueva
En el siguiente diagrama, se muestra cómo la fábrica de aplicaciones y la canalización de CI/CD de la aplicación funcionan juntas para crear y, luego, implementar una aplicación nueva.
El proceso para definir una aplicación nueva es el siguiente:
- Un operador de aplicaciones define una aplicación nueva dentro de su usuario mediante la ejecución de un activador de Cloud Build para generar la definición de la aplicación.
- El activador agrega una entrada nueva para la aplicación en Terraform y confirma el cambio en el repositorio de fábrica de la aplicación.
- El cambio confirmado activa la creación de repositorios y proyectos específicos de la aplicación.
- Cloud Build completa lo siguiente:
- Crea dos repositorios de Git nuevos para alojar el código fuente de la aplicación y la IaC.
- Envía los manifiestos de Kubernetes para las políticas de red y Workload Identity al repositorio de administración de configuración.
- Crea el proyecto de CI/CD de la aplicación y el activador de IaC de Cloud Build.
- El activador de IaC de Cloud Build para la aplicación crea la canalización de CI/CD de la aplicación y el repositorio de Artifact Registry en el proyecto de CI/CD de la aplicación.
- El Sincronizador de configuración implementa las políticas de red y las configuraciones de Workload Identity en los clústeres de GKE de multiusuario.
- La canalización de creación del alcance de la flota crea el alcance de la flota y el espacio de nombres para la aplicación en clústeres de GKE de multiusuario.
- La canalización de CI/CD de la aplicación realiza la implementación inicial de la aplicación en los clústeres de GKE.
- De forma opcional, el equipo de aplicaciones usa el activador de IaC de Cloud Build a fin de implementar proyectos y recursos adicionales (por ejemplo, bases de datos y otros servicios administrados) para proyectos dedicados de usuario único, uno para cada entorno.
Configuración de GKE Enterprise y administración de políticas
En el plano, los administradores de la plataforma de desarrollador usan el Sincronizador de configuración para crear configuraciones a nivel de clúster en cada entorno. El Sincronizador de configuración se conecta a un repositorio de Git que sirve como fuente de información para el estado elegido de la configuración del clúster. El Sincronizador de configuración supervisa de forma continua el estado real de la configuración en los clústeres y concilia todas las discrepancias mediante la aplicación de actualizaciones para garantizar el cumplimiento del estado elegido, a pesar de los cambios manuales. Los archivos de configuración se aplican a los entornos (desarrollo, no producción y producción) mediante una estrategia de ramificación en el repositorio.
En este plano, el Sincronizador de configuración aplica restricciones de Policy Controller. Estos parámetros de configuración definen los controles de seguridad y cumplimiento según lo definido por los administradores de la plataforma de desarrollador para la organización. Este plano se basa en otras canalizaciones para aplicar otras opciones de configuración: las canalizaciones de CI/CD de la aplicación aplican la configuración específica de la aplicación, y la canalización con permiso de la flota crea espacios de nombres y vinculaciones de roles asociadas.
Próximos pasos
- Lee sobre la arquitectura de aplicaciones de Cymbal Bank (el siguiente documento de esta serie).