Estamos utilizando mucho Terraform para el aprovisionamiento de la nube de AWS. Nuestra estructura base de terraformación se ve así:
├─ modules ├── x ├── y ├─ environments ├── dev │ ├── main.tf │ ├── output.tf │ └── variables.tf └── uat │ ├── main.tf │ ├── output.tf │ └── variables.tf └── prod ├── main.tf ├── output.tf └── variables.tfA medida que llegamos a un punto en el que tenemos muchos módulos y muchos entornos, la duplicación de código se convierte en un dolor de cabeza más serio ahora, nos gustaría deshacernos de él tanto como sea posible.
Nuestra principal preocupación actualmente es con los archivos output.tf : cada vez que ampliamos un módulo existente o agregamos un nuevo módulo, debemos establecer la configuración específica del entorno para él (esto es lo esperado), pero aún tenemos que copiar/pegar las partes requeridas en output.tf para generar los resultados del aprovisionamiento (como direcciones IP, ARN de AWS, etc.).
¿Hay alguna manera de deshacerse de los archivos duplicados de output.tf ? ¿Podríamos simplemente definir las salidas deseadas en los propios módulos y ver todas las salidas definidas cada vez que ejecutamos terraform para un entorno específico?
Construimos y abrimos Terragrunt para resolver este mismo problema. Una de las características de Terragrunt es la capacidad de descargar configuraciones remotas de Terraform. La idea es que defina el código de Terraform para su infraestructura solo una vez, en un solo repositorio, llamado, por ejemplo, modules :
└── modules ├── app │ └── main.tf ├── mysql │ └── main.tf └── vpc └── main.tfEste repositorio contiene el código típico de Terraform, con una diferencia: cualquier cosa en su código que deba ser diferente entre entornos debe exponerse como una variable de entrada. Por ejemplo, el módulo de la aplicación podría exponer las siguientes variables:
variable "instance_count" { description = "How many servers to run" } variable "instance_type" { description = "What kind of servers to run (eg t2.large)" } En un repositorio separado, llamado, por ejemplo, en vivo, define el código para todos sus entornos, que ahora consta de solo un archivo .tfvars por componente (por ejemplo, app/terraform.tfvars , mysql/terraform.tfvars , etc.). Esto le da el siguiente diseño de archivo:
└── live ├── prod │ ├── app │ │ └── terraform.tfvars │ ├── mysql │ │ └── terraform.tfvars │ └── vpc │ └── terraform.tfvars ├── qa │ ├── app │ │ └── terraform.tfvars │ ├── mysql │ │ └── terraform.tfvars │ └── vpc │ └── terraform.tfvars └── stage ├── app │ └── terraform.tfvars ├── mysql │ └── terraform.tfvars └── vpc └── terraform.tfvars Observe cómo no hay configuraciones de Terraform (archivos .tf ) en ninguna de las carpetas. En su lugar, cada archivo .tfvars especifica un bloque terraform { ... } que especifica desde dónde descargar el código de Terraform, así como los valores específicos del entorno para las variables de entrada en ese código de Terraform. Por ejemplo, stage/app/terraform.tfvars puede verse así:
terragrunt = { terraform { source = "git::git@github.com:foo/modules.git//app?ref=v0.0.3" } } instance_count = 3 instance_type = "t2.micro" Y prod/app/terraform.tfvars puede verse así:
terragrunt = { terraform { source = "git::git@github.com:foo/modules.git//app?ref=v0.0.1" } } instance_count = 10 instance_type = "m2.large"Consulte la documentación de Terragrunt para obtener más información.
Una forma de resolver esto es crear un entorno base y luego vincular los elementos comunes, por ejemplo:
├─ modules ├── x ├── y ├─ environments ├── base │ ├── output.tf │ └── variables.tf ├── dev │ ├── main.tf │ ├── output.tf -> ../base/output.tf │ └── variables.tf -> ../base/variables.tf ├── uat │ ├── main.tf │ ├── output.tf -> ../base/output.tf │ └── variables.tf -> ../base/variables.tf ├── super_custom │ ├── main.tf │ ├── output.tf # not symlinked │ └── variables.tf # not symlinked └── prod ├── main.tf ├── output.tf -> ../base/output.tf └── variables.tf -> ../base/variables.tf Este enfoque solo funciona realmente si sus archivos output.tf y variables.tf son los mismos para cada entorno, y aunque puede tener variantes sin enlaces simbólicos (por ejemplo, super_custom arriba), esto puede volverse confuso ya que no es inmediatamente obvio qué entornos son personalizados. y cuales no lo son. YMMV. Intento mantener los cambios entre entornos limitados a un archivo .tfvars por entorno.
Vale la pena leer la excelente publicación de Charity Major sobre los archivos tfstate , que me puso en este camino.
Si sus entornos dev , uat y prod tienen la misma forma, pero diferentes propiedades, puede aprovechar los espacios de trabajo para separar el estado de su entorno, junto con archivos *.tfvars separados para especificar las diferentes configuraciones.
Esto podría parecerse a:
├─ modules │ ├── x │ └── y ├── dev.tfvars ├── prod.tfvars ├── uat.tfvars ├── main.tf ├── outputs.tf └── variables.tfPuede crear un nuevo espacio de trabajo con:
terraform workspace new uatLuego, implementar cambios se convierte en:
terraform workspace select uat terraform apply --var-file=uat.tfvarsLa función de espacios de trabajo garantiza que los diferentes estados de los entornos se gestionen por separado, lo cual es una ventaja.
Este enfoque solo funciona cuando las diferencias entre los entornos son lo suficientemente pequeñas como para que tenga sentido encapsular la lógica en los módulos individuales (por ejemplo, tener un indicador de high_availability que agregue alguna infraestructura redundante adicional para uat y prod ).