Estos son los artÃculos de la presente sección:
Infraestructura de tamaño pequeño con TerraformInfraestructura de tamaño mediano con TerraformInfraestructura de tamaño grande con TerraformFuente: 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 -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).
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.
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).
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, ).
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).
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 -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).
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.
Pocos recursos, sin dependencias externas. Una sola cuenta de AWS.
Una sola región. Un sólo entorno.
Disponible
Varias cuentas y entornos en AWS, módulos estándar de infraestructura utilizando Terraform.
Disponible
Muchas cuentas de AWS, muchas regiones, necesidad urgente de reducir el copiado y pegado, módulos de infraestructura personalizados, uso intensivo de composiciones utilizando Terraform.
TEP (Trabajo en proceso)
muy grande
Varios proveedores (AWS, GCP, Azure). Despliegues multi nube utilizando Terraform.
No Disponible
mediana
Varias cuentas y entornos de AWS, módulos estándar de infraestructura, patrón de composición con Terragrunt.
No Disponible
grande
Muchas cuentas de AWS, muchas regiones, urgente necesidad de reducir el copiado y pegado, módulos de infraestructura personalizados, uso intensivo de composiciones utilizando Terragrunt.
No Disponible
muy grande
Varios proveedores (AWS, GCP, Azure). Despliegues multi nube utilizando Terragrunt.
No Disponible
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).