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.
Fuente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
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 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.
En proyectos grandes como el aquí descrito, los beneficios de utilizar Terragrunt se hace palpable. Revisar Ejemplos de Estructuras de Código con Terragrunt.
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.
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).
Estos son los artículos de la presente sección: