Te recomendamos que uses una infraestructura declarativa para desplegar tu base de forma coherente y controlable. Este enfoque ayuda a habilitar una gobernanza coherente al aplicar controles de políticas sobre las configuraciones de recursos aceptables en tus pipelines. El plano se implementa mediante un flujo de GitOps, con Terraform para definir la infraestructura como código (IaC), un repositorio Git para el control de versiones y la aprobación del código, y Cloud Build para la automatización de CI/CD en la canalización de implementación. Para obtener una introducción a este concepto, consulta Gestionar la infraestructura como código con Terraform, Cloud Build y GitOps.
En las siguientes secciones se describe cómo se usa la canalización de implementación para gestionar los recursos de tu organización.
Capas de flujo de procesamiento
Para separar los equipos y la pila de tecnología responsables de gestionar las diferentes capas de tu entorno, te recomendamos un modelo que use diferentes pipelines y diferentes perfiles responsables de cada capa de la pila.
En el siguiente diagrama se muestra el modelo recomendado para separar una canalización de base, una canalización de infraestructura y una canalización de aplicaciones.
En el diagrama se presentan las capas de la canalización de este modelo:
- La pipeline de base implementa los recursos de base que se usan en toda la plataforma. Recomendamos que un único equipo central se encargue de gestionar los recursos básicos que utilizan varias unidades de negocio y cargas de trabajo.
- La pipeline de infraestructura despliega proyectos e infraestructura que utilizan las cargas de trabajo, como instancias de VM o bases de datos. El blueprint configura una canalización de infraestructura independiente para cada unidad de negocio, aunque también puedes usar una sola canalización de infraestructura para varios equipos.
- La pipeline de la aplicación despliega los artefactos de cada carga de trabajo, como contenedores o imágenes. Puede que tengas muchos equipos de aplicaciones diferentes con pipelines de aplicaciones individuales.
En las siguientes secciones se explica cómo usar cada capa de la canalización.
El flujo de procesamiento de la base
La canalización de la base implementa los recursos de la base. También configura la canalización de infraestructura que se usa para implementar la infraestructura que utilizan las cargas de trabajo.
Para crear la canalización de Foundation, primero debes clonar o bifurcar el repositorio de ejemplo de Terraform en tu propio repositorio de Git. Sigue los pasos que se indican en el archivo
0-bootstrap README
para configurar la carpeta y los recursos de arranque.
| Fase | Descripción |
|---|---|
Inicializa una organización de Google Cloud . En este paso también se configura una canalización de CI/CD para el código del blueprint en fases posteriores.
|
Después de crear la canalización de base en la fase 0-bootstrap, las fases siguientes implementan recursos en la canalización de base. Consulta las instrucciones del archivo README de cada fase e implementa cada una de ellas de forma secuencial.
| Fase | Descripción |
|---|---|
Configura carpetas compartidas de nivel superior, proyectos para servicios compartidos, registros a nivel de organización y ajustes de seguridad básicos mediante políticas de la organización. |
|
Configura entornos de desarrollo, de no producción y de producción en la organización Google Cloud que has creado. |
|
o |
Configura las VPCs compartidas en la topología que elijas y los recursos de red asociados. |
La canalización de infraestructura
La canalización de infraestructura implementa los proyectos y la infraestructura (por ejemplo, las instancias de VM y las bases de datos) que utilizan las cargas de trabajo. El flujo de trabajo de la base implementa varios flujos de trabajo de infraestructura. Esta separación entre la canalización de la base y la canalización de la infraestructura permite separar los recursos de toda la plataforma de los recursos específicos de la carga de trabajo.
En el siguiente diagrama se describe cómo configura el blueprint varias pipelines de infraestructura que están pensadas para que las usen distintos equipos.
En el diagrama se describen los siguientes conceptos clave:
- Cada canalización de infraestructura se usa para gestionar los recursos de infraestructura independientemente de los recursos de la base.
- Cada unidad de negocio tiene su propia canalización de infraestructura, gestionada en un proyecto específico de la carpeta
common. - Cada una de las pipelines de infraestructura tiene una cuenta de servicio con permiso para implementar recursos solo en los proyectos asociados a esa unidad de negocio. Esta estrategia crea una separación de responsabilidades entre las cuentas de servicio con privilegios que se usan en el flujo de procesamiento de la base y las que se usan en cada flujo de procesamiento de la infraestructura.
Este enfoque con varias canalizaciones de infraestructura se recomienda cuando tienes varias entidades en tu organización que tienen las habilidades y la motivación para gestionar su infraestructura por separado, sobre todo si tienen requisitos diferentes, como los tipos de política de validación de canalización que quieren aplicar. También puedes preferir tener una sola infraestructura de canalización gestionada por un solo equipo con políticas de validación coherentes.
En terraform-example-foundation, la fase 4 configura una canalización de infraestructura y la fase 5 muestra un ejemplo de cómo usar esa canalización para desplegar recursos de infraestructura.
| Fase | Descripción |
|---|---|
Configura una estructura de carpetas, proyectos y una infraestructura pipeline. |
|
|
Despliega proyectos de cargas de trabajo con una instancia de Compute Engine usando la canalización de infraestructura como ejemplo. |
El flujo de procesamiento de la aplicación
La canalización de aplicaciones se encarga de desplegar los artefactos de la aplicación para cada carga de trabajo, como imágenes o contenedores de Kubernetes que ejecutan la lógica empresarial de tu aplicación. Estos artefactos se implementan en recursos de infraestructura que ha implementado tu canalización de infraestructura.
El blueprint de aspectos básicos de seguridad para empresas configura tu flujo de procesamiento de aspectos básicos y tu flujo de procesamiento de infraestructura, pero no implementa un flujo de procesamiento de aplicaciones. Para ver un ejemplo de una canalización de aplicaciones, consulta el blueprint de aplicaciones empresariales.
Automatizar tu flujo de trabajo con Cloud Build
El blueprint usa Cloud Build para automatizar los procesos de CI/CD. En la siguiente tabla se describen los controles integrados en el flujo de procesamiento de la base y en el flujo de procesamiento de la infraestructura que se implementan mediante el repositorio terraform-example-foundation. Si desarrollas tus propias canalizaciones con otras herramientas de automatización de CI/CD, te recomendamos que apliques controles similares.
| Control | Descripción |
|---|---|
Configuraciones de compilación independientes para validar el código antes de implementarlo |
El plano usa dos archivos de configuración de compilación de Cloud Build para toda la canalización. Cada repositorio asociado a una fase tiene dos activadores de Cloud Build asociados a esos archivos de configuración de compilación. Cuando se envía código a una rama de un repositorio, se activan los archivos de configuración de compilación para que primero se ejecute |
Comprobaciones de políticas de Terraform | El plano incluye un conjunto de restricciones de Open Policy Agent que se aplican mediante la validación de políticas en la CLI de Google Cloud. Estas restricciones definen las configuraciones de recursos aceptables que puede implementar tu canal. Si una compilación no cumple la política en la primera configuración de compilación, la segunda configuración de compilación no implementará ningún recurso. Las políticas aplicadas en el plano se han bifurcado de |
Principio de mínimos accesos | La canalización de la base tiene una cuenta de servicio diferente para cada fase con una política de permiso que concede solo los roles de gestión de identidades y accesos mínimos para esa fase. Cada activador de Cloud Build se ejecuta como la cuenta de servicio específica de esa fase. Usar cuentas diferentes ayuda a mitigar el riesgo de que la modificación de un repositorio pueda afectar a los recursos gestionados por otro repositorio. Para saber qué roles de gestión de identidades y accesos se aplican a cada cuenta de servicio, consulta el |
Grupos privados de Cloud Build | El blueprint usa grupos privados de Cloud Build. Los grupos privados te permiten aplicar controles adicionales de forma opcional, como restringir el acceso a repositorios públicos o ejecutar Cloud Build dentro de un perímetro de Controles de Servicio de VPC. |
Compiladores personalizados de Cloud Build | El blueprint crea su propio compilador personalizado para ejecutar Terraform. Para obtener más información, consulta |
Aprobación de la implementación | De forma opcional, puedes añadir una fase de aprobación manual a Cloud Build. Esta aprobación añade un punto de control adicional después de que se active la compilación, pero antes de que se ejecute, para que un usuario con privilegios pueda aprobarla manualmente. |
Estrategia de ramificación
Te recomendamos que uses una estrategia de rama persistente para enviar código a tu sistema Git y desplegar recursos a través de la pipeline de la base. En el siguiente diagrama se describe la estrategia de ramificación persistente.
En el diagrama se describen tres ramas persistentes en Git (desarrollo, no producción y producción) que reflejan losGoogle Cloud entornos correspondientes. También hay varias ramas de funciones efímeras que no se corresponden con recursos implementados en tusGoogle Cloud entornos.
Te recomendamos que implementes un proceso de solicitud de extracción (PR) en tu sistema Git para que cualquier código que se combine en una rama persistente tenga una PR aprobada.
Para desarrollar código con esta estrategia de ramificación persistente, sigue estos pasos generales:
- Cuando desarrolles nuevas funciones o trabajes en una corrección de errores, crea una rama a partir de la rama de desarrollo. Usa una convención de nomenclatura para tu rama que incluya el tipo de cambio, un número de incidencia u otro identificador y una descripción legible, como
feature/123456-org-policies. - Cuando hayas terminado de trabajar en la rama de la función, abre una solicitud de extracción que tenga como destino la rama de desarrollo.
- Cuando envías la PR, esta activa la canalización de la fundación para realizar
terraform planyterraform validatepara organizar y verificar los cambios. - Después de validar los cambios en el código, combina la función o la corrección de errores en la rama de desarrollo.
- El proceso de combinación activa la canalización de la base para ejecutar
terraform applypara implementar los últimos cambios de la rama de desarrollo en el entorno de desarrollo. - Revisa los cambios en el entorno de desarrollo mediante las revisiones manuales, las pruebas funcionales o las pruebas integrales que sean relevantes para tu caso práctico. Después, promueve los cambios al entorno de no producción abriendo una solicitud de extracción que tenga como destino la rama de no producción y combina los cambios.
- Para desplegar recursos en el entorno de producción, repite el mismo proceso que en el paso 6: revisa y valida los recursos desplegados, abre una solicitud de extracción en la rama de producción y combínala.
Siguientes pasos
- Consulta las prácticas recomendadas para las operaciones (el siguiente documento de esta serie).