1 of 6

Ejemplos de estructura del código

Estructuras de código de Terraform

Estos ejemplos son presentados con AWS como proveedor pero la mayoría de los principios mostrados en los ejemplos pueden ser aplicados a otros proveedores de nube pública así como a otro tipo de proveedores (DNS, DB, Monitoring, etc).

Tipo

Descripción

Disponibilidad

Estructuras de código de Terraform

Tipo

Descripción

Disponibilidad

Terragrunt

Terraform

Estos son los artículos de la presente sección:

Infraestructura de tamaño pequeño con Terraform

Fuente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño pequeño, en donde no son utilizadas dependencias externas.

Perfecta para comenzar y refactorizar a medida que avanzas.
Perfecta para módulos de recurso pequeños.
Bueno para módulos de infraestructura pequeños y lineares (por ejemplo, terraform-aws-atlantis).
Bueno para un número pequeño de recursos (menos de 20 o 30).

Contar con un sólo archivo de estado para todos los recursos puede hacer lento el proceso de trabajo con Terraform si el número de recursos está creciendo (considerar el uso del argumento -target para limitar el número de recursos).

Infraestructura de tamaño mediano con Terraform

Fuente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño mediano que utiliza:

2 cuentas de AWS.
2 entornos separados (prod y stage, los cuales no comparten nada). Cada entorno vive en una cuenta separada de AWS.
Cada entorno utiliza diferentes versiones del módulo estándar de infraestructura (alb) proveniente del Registro de Terraform -Terraform Registry-.
Cada entorno hace uso de la misma versión del módulo interno modules/network dado que es procedente de un directorio local.

Perfecta para proyectos en donde la infraestructura está separa lógicamente (cuentas separadas de AWS).
Buena cuando no hay necesidad de modificar recursos compartidos entre las diferentes cuentas de AWS (un entorno = una cuenta AWS = un archivo de estado).
Buena cuando no hay necesidad de orquestación de los cambios entre los entornos.
Buena cuando los recursos de infraestructura son diferentes por entorno intencionalmente y no pueden ser generalizados (por ejemplo, algunos recursos están ausentes en un entorno o en algunas regiones).

A medida de que el proyecto crezca, estos entornos serán más difíciles de mantener actualizados al día unos de otros. Considerar utilizar módulos de infraestructura (estándares o propios) para tareas repetibles.

Infraestructura de tamaño grande con Terraform

Fuente:

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño grande que utiliza:

2 cuentas de AWS.
2 entornos separados (prod y stage, los cuales no comparten nada). Cada entorno vive en cuentas separadas de AWS.
Cada entorno utiliza diferentes versiones del módulo estándar de infraestructura (alb) proveniente de -Terraform Registry-.
Cada entorno hace uso de la misma versión del módulo interno modules/network dado que es procedente de un directorio local.

En proyectos grandes como el aquí descrito, los beneficios de utilizar Terragrunt se hace palpable. Revisar .

Perfecta para proyectos en donde la infraestructura está separa lógicamente (cuentas separadas de AWS).
Buena cuando no hay necesidad de modificar recursos compartidos entre las diferentes cuentas de AWS (un entorno = una cuenta AWS = un archivo de estado).
Buena cuando no hay necesidad de orquestación de los cambios entre los entornos.
Buena cuando los recursos de infraestructura son diferentes por entorno intencionalmente y no pueden ser generalizados (por ejemplo, algunos recursos están ausentes en un entorno o en algunas regiones).

Infraestructura de tamaño mediano con Terraform

Fuente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño mediano que utiliza:

2 cuentas de AWS.
2 entornos separados (prod y stage, los cuales no comparten nada). Cada entorno vive en una cuenta separada de AWS.
Cada entorno utiliza diferentes versiones del módulo estándar de infraestructura (alb) proveniente del Registro de Terraform -Terraform Registry-.
Cada entorno hace uso de la misma versión del módulo interno modules/network dado que es procedente de un directorio local.

Perfecta para proyectos en donde la infraestructura está separa lógicamente (cuentas separadas de AWS).
Buena cuando no hay necesidad de modificar recursos compartidos entre las diferentes cuentas de AWS (un entorno = una cuenta AWS = un archivo de estado).
Buena cuando no hay necesidad de orquestación de los cambios entre los entornos.
Buena cuando los recursos de infraestructura son diferentes por entorno intencionalmente y no pueden ser generalizados (por ejemplo, algunos recursos están ausentes en un entorno o en algunas regiones).

Infraestructura de tamaño grande con Terraform

Fuente:

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño grande que utiliza:

2 cuentas de AWS.
2 entornos separados (prod y stage, los cuales no comparten nada). Cada entorno vive en cuentas separadas de AWS.
Cada entorno utiliza diferentes versiones del módulo estándar de infraestructura (alb) proveniente de -Terraform Registry-.
Cada entorno hace uso de la misma versión del módulo interno modules/network dado que es procedente de un directorio local.

En proyectos grandes como el aquí descrito, los beneficios de utilizar Terragrunt se hace palpable. Revisar .

Perfecta para proyectos en donde la infraestructura está separa lógicamente (cuentas separadas de AWS).
Buena cuando no hay necesidad de modificar recursos compartidos entre las diferentes cuentas de AWS (un entorno = una cuenta AWS = un archivo de estado).
Buena cuando no hay necesidad de orquestación de los cambios entre los entornos.
Buena cuando los recursos de infraestructura son diferentes por entorno intencionalmente y no pueden ser generalizados (por ejemplo, algunos recursos están ausentes en un entorno o en algunas regiones).