Prácticas recomendadas para el control de versión

En este documento, se proporcionan prácticas recomendadas de control de versión que debes tener en cuenta cuando usas Terraform para Google Cloud.

Al igual que con otras formas de código, almacena el código de la infraestructura en el control de versión para preservar el historial y permitir reversiones sencillas.

Esta guía no es una introducción a Terraform. Para obtener una introducción al uso de Terraform con Google Cloud, consulta Comienza a usar Terraform.

Usa una estrategia de ramificación predeterminada

Para todos los repositorios que contienen un código de Terraform, usa la siguiente estrategia de forma predeterminada:

  • La rama main es la rama de desarrollo principal y representa el código aprobado más reciente. La rama main está protegida.
  • El desarrollo ocurre en ramas de funciones y corrección de errores que se bifurcan de la rama main.
    • Nombra las ramas de funciones feature/$feature_name.
    • Nombra las ramas de corrección de errores fix/$bugfix_name.
  • Cuando se complete una función o una corrección de errores, vuelve a combinarla en la rama main con una solicitud de extracción.
  • Para evitar conflictos de combinación, modifica las ramas antes de combinarlas.

Usa ramas de entorno para la configuración raíz

Para los repositorios que incluyen configuraciones raíz que se implementan directamente en Google Cloud, se requiere una estrategia segura de lanzamiento. Recomendamos tener una rama separada para cada entorno. Por lo tanto, los cambios en la configuración de Terraform se pueden promover mediante la combinación de cambios entre las diferentes ramas.

Rama separada para cada entorno

Permite una visibilidad amplia

Haz que el código fuente y los repositorios de Terraform sean visibles y accesibles en todas las organizaciones de ingeniería para los propietarios de la infraestructura (por ejemplo, SRE) y las partes interesadas de la infraestructura (por ejemplo, desarrolladores). Esto garantiza que las partes interesadas de la infraestructura puedan comprender mejor la infraestructura de la que dependen.

Incentiva a las partes interesadas de la infraestructura para que envíen solicitudes de combinación como parte del proceso de solicitud de cambio.

Nunca confirmes objetos Secret

Nunca confirmes objetos Secret en el control de origen, incluso en la configuración de Terraform. En su lugar, súbelos a un sistema como Secret Manager y haz referencia a ellos mediante las fuentes de datos.

Ten en cuenta que estos valores sensibles aún pueden terminar en el archivo de estado y que también pueden exponerse como resultados.

Organiza los repositorios según los límites del equipo

Si bien puedes usar directorios separados para administrar los límites lógicos entre los recursos, los límites organizacionales y la logística determinan la estructura del repositorio. En general, usa el principio de diseño de que las configuraciones con diferentes requisitos de aprobación y administración se separen en diferentes repositorios de control de origen. Para ilustrar este principio, se incluyen algunas opciones de configuración de repositorio posibles:

  • Un repositorio central: en este modelo, un solo equipo de plataforma administra todo el código de Terraform de forma central. Este modelo funciona mejor cuando hay un equipo de infraestructura dedicado responsable de toda la administración de la nube y aprueba cualquier cambio que soliciten otros equipos.

  • Repositorios de equipos: en este modelo, cada equipo es responsable de su propio repositorio de Terraform en el que administra todo lo relacionado con la infraestructura que posee. Por ejemplo, el equipo de seguridad puede tener un repositorio en el que se administran todos los controles de seguridad, y los equipos de aplicaciones tienen su propio repositorio de Terraform para implementar y administrar su aplicación.

    Organizar repositorios a través de límites de equipos es la mejor estructura para la mayoría de las situaciones empresariales.

  • Repositorios desacoplados: en este modelo, cada componente lógico de Terraform se divide en su propio repositorio. Por ejemplo, las herramientas de redes pueden tener un repositorio dedicado, y puede que haya un repositorio de fábrica del proyecto separado para la creación y administración de proyectos. Esto funciona mejor en entornos muy descentralizados donde las responsabilidades cambian con frecuencia entre los equipos.

Estructura del repositorio de muestra

Puedes combinar estos principios para dividir la configuración de Terraform en diferentes tipos de repositorios:

  • Básica
  • Específica de la aplicación y el equipo

Repositorio básico

Un repositorio básico que contiene los principales componentes centrales, como las carpetas o la IAM de la organización. El equipo central de la nube puede administrar este repositorio.

  • En este repositorio, incluye un directorio para cada componente principal (por ejemplo, carpetas, redes, etcétera).
  • En los directorios de componentes, incluye una carpeta separada para cada entorno (que refleje la orientación de estructura del directorio que se mencionó antes).

Estructura básica del repositorio

Repositorios específicos de la aplicación y el equipo

Implementa repositorios específicos de la aplicación y el equipo por separado para que cada equipo administre su configuración de Terraform única y específica de la aplicación.

Estructura del repositorio específico de la aplicación y el equipo

¿Qué sigue?