En el subcapítol anterior vam veure que l’estratègia de directoris per entorn és excel·lent, però té un petit inconvenient: certa repetició entre els entorns. Quan tens molts entorns o molts components, aquesta repetició creix. Terragrunt és una eina de la comunitat que resol just això, ajudant-te a mantenir el teu codi DRY. Vegem què és i quan val la pena.

DRY significa «Don't Repeat Yourself» («No et repeteixis»). És un principi fonamental de la programació: cada peça d’informació o lògica ha d’existir en un sol lloc. Repetir codi és dolent perquè, si cal canviar alguna cosa, l’has de canviar a molts llocs (i és fàcil oblidar-se’n d’algun).

Al subcapítol 19.2 vam veure que l’estratègia de directoris deixa una mica de repetició als main.tf de cada entorn (la configuració del backend, les crides a mòduls similars...). Terragrunt ataca aquesta repetició.

Terragrunt és una eina que embolcalla Terraform (un «wrapper»), creada per l’empresa Gruntwork. No reemplaça Terraform: el complementa, afegint funcionalitats per gestionar millor múltiples entorns i reduir la repetició.

Analogia: si Terraform és el motor, Terragrunt és un sistema d’assistència a la conducció que es munta a sobre: el motor segueix fent la feina, però conduir es torna més còmode i comets menys errors, sobretot en trajectes llargs i repetitius (molts entorns).

Recorda que cada entorn necessita configurar el seu backend d’estat (Capítol 11, subcapítol 20.1), i això es repeteix a cada carpeta. Amb Terragrunt, defineixes la configuració del backend una sola vegada i cada entorn l’hereta, generant automàticament la part que canvia (per exemple, la ruta de l’estat de cada entorn).

Els valors que comparteixen tots els entorns (la regió, etiquetes comunes, comptes...) es defineixen una vegada i s’hereten, en lloc de copiar-los a cada entorn.

Cada entorn es redueix a un fitxer petit que diu «fes servir aquest mòdul amb aquests valors concrets», mentre tota la maquinària comuna (backend, providers, configuració) està centralitzada. Els fitxers de cada entorn queden mínims: només les seves diferències.

Terragrunt també ajuda a orquestrar diversos components d’infraestructura (xarxa, base de dades, aplicació) i les seves dependències, aplicant-los en ordre, cosa que en projectes grans és molt útil.

Com tota eina, Terragrunt afegeix la seva pròpia complexitat (una altra eina que aprendre i mantenir). La decisió d’adoptar-lo depèn de la mida del teu projecte:

Consell important: no adoptis Terragrunt des del primer dia. Comença amb Terraform i l’estratègia de directoris del subcapítol 19.2. Només quan sentis que la repetició entre entorns esdevé un problema real, planteja’t Terragrunt. Adoptar-lo massa aviat afegeix complexitat innecessària (recorda la lliçó del Capítol 17 sobre no triar eines complexes per moda).

Convé saber que Terragrunt no és l’única opció. El mateix Terraform ha anat incorporant millores, i plataformes com Terraform Cloud / HCP Terraform (que veurem al Capítol 22) també ajuden a gestionar entorns. Terragrunt segueix sent molt popular, però l’ecosistema evoluciona; tria segons el que el teu equip necessiti i conegui.

• DRY («Don't Repeat Yourself») és el principi de no repetir codi: cada cosa ha d’estar en un sol lloc, per no haver-la de canviar a molts llocs.
• Terragrunt és una eina que embolcalla Terraform (no el reemplaça) per reduir la repetició en gestionar múltiples entorns. Com un «assistent a la conducció» sobre el motor de Terraform.
• Resol: configuració del backend sense repetir, valors comuns en un lloc, menys codi per entorn (només les diferències) i orquestració de dependències entre components.
• No l’adoptis des del principi: comença amb Terraform + directoris per entorn (subcap. 19.2), i passa’t a Terragrunt només si la repetició esdevé un problema real. No afegeixis complexitat per moda.

A l’últim subcapítol del capítol veurem com es gestionen els valors de cada entorn en detall: les variables d’entorn i els fitxers .tfvars.