Prácticas recomendadas para el control de versiones

En este documento se describen las prácticas recomendadas de control de versiones que se deben tener en cuenta al usar Terraform para Google Cloud.

Al igual que con otras formas de código, almacena el código de infraestructura en el control de versiones para conservar el historial y permitir restauraciones sencillas.

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

Usar una estrategia de ramificación predeterminada

En todos los repositorios que contengan código de Terraform, utiliza 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 se lleva a cabo en ramas de funciones y corrección de errores que se derivan de la rama main.
  • Asigna nombres a 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, combínala de nuevo en la rama main con una solicitud de extracción.
• Para evitar conflictos de combinación, cambia la base de las ramas antes de combinarlas.

Usar ramas de entorno para las configuraciones raíz

En el caso de los repositorios que incluyen configuraciones raíz que se implementan directamente enGoogle Cloud, se requiere una estrategia de lanzamiento segura. Te recomendamos que tengas una rama independiente para cada entorno. Por lo tanto, los cambios en la configuración de Terraform se pueden promover combinando los cambios entre las diferentes ramas.

Permitir una visibilidad amplia

Haz que el código fuente y los repositorios de Terraform sean visibles y accesibles para todos los miembros de las organizaciones de ingeniería, los propietarios de la infraestructura (por ejemplo, los ingenieros de fiabilidad de sitios) y las partes interesadas de la infraestructura (por ejemplo, los desarrolladores). De esta forma, las partes interesadas de la infraestructura pueden comprender mejor la infraestructura de la que dependen.

Anima a los participantes de la infraestructura a enviar solicitudes de combinación como parte del proceso de solicitud de cambios.

No confirmes nunca secretos

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

Ten en cuenta que estos valores sensibles pueden acabar en el archivo de estado y también pueden exponerse como salidas.

Organizar repositorios en función de los límites de los equipos

Aunque puedes usar directorios independientes para gestionar los límites lógicos entre recursos, los límites organizativos y la logística determinan la estructura del repositorio. Por lo general, aplica el principio de diseño de que las configuraciones con diferentes requisitos de aprobación y gestión se separen en diferentes repositorios de control de código fuente. Para ilustrar este principio, estas son algunas configuraciones de repositorio posibles:

• Un repositorio central: en este modelo, todo el código de Terraform lo gestiona de forma centralizada un único equipo de plataforma. Este modelo funciona mejor cuando hay un equipo de infraestructura especializado responsable de toda la gestión de la nube y aprueba los cambios solicitados por otros equipos.

• Repositorios de equipo: en este modelo, cada equipo es responsable de su propio repositorio de Terraform, donde gestiona todo lo relacionado con la infraestructura que posee. Por ejemplo, el equipo de seguridad puede tener un repositorio donde se gestionen todos los controles de seguridad, y los equipos de aplicaciones pueden tener cada uno su propio repositorio de Terraform para desplegar y gestionar su aplicación.

  Organizar los repositorios según los límites de los equipos es la mejor estructura para la mayoría de los casos empresariales.

• Repositorios desacoplados: en este modelo, cada componente lógico de Terraform se divide en su propio repositorio. Por ejemplo, las redes pueden tener un repositorio específico, y puede haber un repositorio de fábrica de proyectos independiente para la creación y la gestión de proyectos. Esta opción es la más adecuada en entornos muy descentralizados en los que las responsabilidades cambian con frecuencia entre los equipos.

Estructura del repositorio de ejemplo

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

• Foundational
• Específicas de la aplicación y del equipo

Repositorio de base

Un repositorio fundamental que contiene los principales componentes centrales, como carpetas o gestión de identidades y accesos de la organización. El equipo central de la nube puede gestionar este repositorio.

• En este repositorio, incluya un directorio para cada componente principal (por ejemplo, carpetas, redes, etc.).
• En los directorios de componentes, incluye una carpeta independiente para cada entorno (siguiendo las directrices de estructura de directorios que hemos mencionado anteriormente).

Repositorios específicos de aplicaciones y equipos

Implementa repositorios específicos de aplicaciones y equipos por separado para cada equipo, de forma que puedan gestionar su configuración de Terraform específica de la aplicación.

Siguientes pasos

• Consulta las prácticas recomendadas para las operaciones de Terraform.
• Consulta las prácticas recomendadas para usar Terraform de forma segura.