Te recomendamos que uses una infraestructura declarativa para implementar la base de manera coherente y controlable. Este enfoque ayuda a habilitar la administración coherente mediante la aplicación de controles de política sobre las configuraciones aceptables de recursos en las canalizaciones. El plano se implementa mediante un flujo de GitOps, con Terraform que se usa a fin de definir la infraestructura como código (IaC), un repositorio de Git para el control de versiones y la aprobación de 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 Administra 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 administrar recursos en tu organización.
Capas de la canalización
Para separar los equipos y la technology stack responsables de administrar diferentes capas de tu entorno, recomendamos un modelo que use diferentes canalizaciones y personas diferentes que sean responsables de cada capa de la pila.
En el siguiente diagrama, se presenta nuestro modelo recomendado para separar una canalización de base, una canalización de infraestructura y una canalización de aplicación.
En el diagrama, se presentan las capas de canalización en este modelo:
- La canalización base implementa los recursos base que se usan en toda la plataforma. Recomendamos que un solo equipo central sea responsable de administrar los recursos básicos que consumen varias unidades de negocios y cargas de trabajo.
- La canalización de infraestructura implementa proyectos y una infraestructura que usan las cargas de trabajo, como las instancias de VM o bases de datos. El plano configura una canalización de infraestructura independiente para cada unidad de negocios, o es posible que prefieras una sola canalización de infraestructura que usen varios equipos.
- La canalización de aplicación implementa los artefactos para cada carga de trabajo, como imágenes o contenedores. Es posible que tengas muchos equipos de aplicaciones diferentes con canalizaciones de aplicaciones individuales.
Las siguientes secciones presentan el uso de cada capa de la canalización.
La canalización base
La canalización de base implementa los recursos de base. También configura la canalización de infraestructura que se usa para implementar la infraestructura que usan las cargas de trabajo.
Para crear la canalización de base, primero debes clonar o bifurcar la base de datos de Terraform a tu propio repositorio de Git. Sigue los pasos del archivo README de 0-bootstrap para configurar tu carpeta de arranque y tus recursos.
| Etapa | Descripción |
|---|---|
Inicia una organización de Google Cloud. En este paso, también se configura una canalización de CI/CD para el código del plano en etapas posteriores.
|
Después de crear la canalización de base en la etapa 0-bootstrap, las siguientes etapas implementan recursos en la canalización de base. Revisa las instrucciones de README para cada etapa y, luego, implementa cada etapa de forma secuencial.
| Etapa | Descripción |
|---|---|
Configura carpetas compartidas de nivel superior, proyectos para servicios compartidos, registros a nivel de la organización y configuración de seguridad de referencia a través de políticas de la organización. |
|
Configura entornos de desarrollo, de no producción y de producción dentro de la organización de Google Cloud que creaste. |
|
o |
Configura las VPC compartidas en la topología elegida y en los recursos de red asociados. |
Canalización de infraestructura
La canalización de infraestructura implementa los proyectos y la infraestructura (por ejemplo, las instancias y bases de datos de VMs) que usan las cargas de trabajo. La canalización base implementa varias canalizaciones de infraestructura. Esta separación entre la canalización de base y la canalización de infraestructura permite una separación entre los recursos de toda la plataforma y los recursos específicos de la carga de trabajo.
En el siguiente diagrama, se describe cómo el plano configura varias canalizaciones de infraestructura destinadas a usarse por equipos separados.
En el diagrama, se describen los siguientes conceptos clave:
- Cada canalización de infraestructura se usa para administrar los recursos de infraestructura sin importar los recursos base.
- Cada unidad de negocios tiene su propia canalización de infraestructura, administrada en un proyecto dedicado en la carpeta
common. - Cada una de las canalizaciones de infraestructura tiene una cuenta de servicio con permiso para implementar recursos solo en los proyectos asociados con esa unidad de negocios. Esta estrategia crea una separación de obligaciones entre las cuentas de servicio con privilegios usadas para la canalización de base y las que usa cada canalización de infraestructura.
Este enfoque con varias canalizaciones de infraestructura se recomienda cuando tienes varias entidades dentro de la organización que tienen las habilidades y el acierto para administrar su infraestructura por separado, en especial si tienen requisitos diferentes, como los tipos de políticas de validación de canalizaciones que quieren aplicar. Como alternativa, puedes tener una sola canalización de infraestructura administrada por un solo equipo con políticas de validación coherentes.
En terraform-example-foundation, la etapa 4 configura una canalización de infraestructura y la etapa 5 muestra un ejemplo del uso de esa canalización para implementar recursos de infraestructura.
| Etapa | Descripción |
|---|---|
Configura una estructura de carpetas, proyectos y una canalización de infraestructura. |
|
|
Implementa proyectos de carga de trabajo con una instancia de Compute Engine mediante la canalización de infraestructura como ejemplo. |
Canalización de aplicación
La canalización de aplicación es responsable de implementar artefactos de aplicación para cada carga de trabajo individual, como imágenes o contenedores de Kubernetes que ejecutan la lógica empresarial de la aplicación. Estos artefactos se implementan en los recursos de infraestructura que implementa tu canalización de infraestructura.
El plano de base empresarial configura la canalización de base y la canalización de infraestructura, pero no implementa una canalización de aplicación. Para ver un ejemplo de canalización de aplicación, consulta el plano de aplicación empresarial.
Automatiza tu canalización con Cloud Build
El plano usa Cloud Build para automatizar los procesos de CI/CD. En la siguiente tabla, se describen los controles que se compilan en la canalización de base y en la canalización de infraestructura que implementa 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 |
|---|---|
Separa las configuraciones de compilación para validar el código antes de implementar |
El plano usa dos archivos de configuración de compilación de Cloud Build para toda la canalización, y cada repositorio asociado con una etapa tiene dos activadores de Cloud Build que son asociados con esos archivos de configuración de compilación. Cuando el código se envía a una rama de repositorio, los archivos de configuración de compilación se activan para ejecutar |
Verificaciones de políticas de Terraform | El plano incluye un conjunto de restricciones del Agente de políticas abiertas que aplica la validación de políticas en Google Cloud CLI. Estas restricciones definen las configuraciones de recursos aceptables que puede implementar tu canalización. Si una compilación no cumple con la política en la primera configuración de compilación, la segunda configuración no implementa ningún recurso. Las políticas aplicadas en el plano se bifurcan desde |
Principio de privilegio mínimo | La canalización base tiene una cuenta de servicio diferente para cada etapa con una política de permisos que otorga solo los roles de IAM mínimos para esa etapa. Cada activador de Cloud Build se ejecuta como la cuenta de servicio específica para esa etapa. El uso de cuentas diferentes ayuda a mitigar el riesgo de que modificar un repositorio pueda afectar los recursos que administra otro repositorio. Para comprender los roles específicos de IAM que se aplican a cada cuenta de servicio, consulta el código de Terraform |
Grupos privados de Cloud Build | El plano 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 del servicio de VPC. |
Compiladores personalizados de Cloud Build | El plano crea su propio compilador personalizado para ejecutar Terraform. Para obtener más información, consulta |
Aprobación de la implementación | De manera opcional, puedes agregar una etapa de aprobación manual a Cloud Build. Esta aprobación agrega un punto de control adicional después de que se activa la compilación, pero antes de que se ejecute para que un usuario con privilegios pueda aprobar la compilación de forma manual. |
Estrategia de ramificación
Recomendamos una estrategia de rama persistente para enviar el código a tu sistema de Git y, luego, implementar recursos a través de la canalización de base. En el siguiente diagrama, se describe la estrategia de la rama persistente.
En el diagrama, se describen tres ramas persistentes en Git (desarrollo, no producción y producción) que reflejan los entornos de Google Cloud correspondientes. También hay varias ramas de características efímeras que no corresponden a los recursos implementados en los entornos de Google Cloud.
Recomendamos que apliques un proceso de solicitud de extracción (PR) a tu sistema de Git para que cualquier código que se combine con una rama persistente tenga una PR aprobada.
Para desarrollar código con esta estrategia de rama persistente, sigue estos pasos de alto nivel:
- Cuando desarrolles funciones nuevas o trabajes en una corrección de errores, crea una rama nueva basada en la rama de desarrollo. Usa una convención de nombres para tu rama que incluya el tipo de cambio, un número de ticket o algún otro identificador, y una descripción legible por humanos, como
feature/123456-org-policies. - Cuando completes el trabajo en la rama de funciones, abre una PR que se oriente a la rama de desarrollo.
- Cuando envías la PR, esta activa la canalización de base para realizar
terraform planyterraform validatea fin de almacenar en etapa intermedia 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 base para ejecutar
terraform applya fin de implementar los últimos cambios en la rama de desarrollo en el entorno de desarrollo. - Revisa los cambios en el entorno de desarrollo mediante revisiones manuales, pruebas funcionales o pruebas de extremo a extremo que sean relevantes para tu caso de uso. Luego, promueve los cambios en el entorno que no sea de producción. Para ello, abre una PR que se oriente a la rama de no producción y combina tus cambios.
- Para implementar recursos en el entorno de producción, repite el mismo proceso que en el paso 6: revisa y valida los recursos implementados, abre una PR para la rama de producción y combina.
Próximos pasos
- Lee sobre las prácticas recomendadas de operaciones (siguiente documento de esta serie).