En el subcapítol anterior vam veure que els workspaces no són la millor forma de separar entorns seriosos. Ara veurem l’estratègia recomanada per la comunitat: organitzar la infraestructura en directoris separats per entorn. És més explícita, més segura i molt més fàcil d’entendre. És com gestionen els entorns la majoria dels equips professionals.

En lloc d’un mateix codi que canvia de comportament segons el workspace, tens una carpeta per a cada entorn, cadascuna amb la seva pròpia configuració i el seu propi estat:

Cada carpeta d’entorn utilitza els mateixos mòduls (per no duplicar la lògica), però els passa valors diferents. Així, el «què es construeix» està als mòduls (compartit), i el «amb quina mida i configuració» està a cada entorn (separat).

Aquí és on brilla tot el que vas aprendre al Capítol 18. La lògica de la infraestructura viu una sola vegada als mòduls. Cada entorn simplement crida aquests mòduls amb els seus propis valors:

Mateix mòdul servidors, dos entorns, configuracions diferents. Si millores el mòdul, tots dos entorns se’n beneficien, però cadascun manté la seva mida i configuració pròpies. No hi ha duplicació de lògica.

Aquesta estratègia resol els problemes que vam veure al subcapítol 19.1:

Cada entorn és una carpeta independent amb el seu propi estat (recorda configurar un backend diferent per entorn, Capítol 11 i subcapítol 20.1). Producció i desenvolupament estan realment separats: un error en una carpeta no toca les altres.

Per treballar en producció, has d’entrar físicament a la carpeta prod/ i executar Terraform allà. No és un subtil workspace select que s’oblida: és un canvi de directori evident. Això redueix moltíssim el risc d’aplicar alguna cosa a l’entorn equivocat.

Mirant l’estructura de carpetes, veus d’una ullada quins entorns hi ha i què té cadascun. Obres entorns/prod/main.tf i saps exactament què hi ha en producció. És transparent i fàcil d’auditar.

Si producció necessita components que desenvolupament no té (per exemple, rèpliques de base de dades o còpies de seguretat extra), simplement els afegeixes a prod/main.tf sense afectar els altres entorns. Cada entorn pot divergir el que necessiti, sense condicionals enrevessats.

Analogia: els workspaces eren com tenir una sola casa i «canviar la decoració» segons qui la visita. L’estratègia de directoris és com tenir cases separades per a cada propòsit: una per viure (producció), una altra per experimentar (desenvolupament). Estan físicament separades, no et confons de casa, i pots reformar-ne una sense tocar l’altra.

Hauràs vist un fitxer terraform.tfvars a cada entorn. És on es posen els valors de les variables específics d’aquell entorn (ho veurem a fons al subcapítol 19.4). Així, la configuració de cada entorn (mides, noms, quantitats) queda separada i clara, sense tocar el codi.

Aquesta estratègia té un cost: hi ha certa repetició als fitxers main.tf de cada entorn (les crides als mòduls s’assemblen). En projectes amb molts entorns, aquesta repetició pot tornar-se molesta. Per això existeix una eina anomenada Terragrunt, que redueix aquesta repetició i veurem al següent subcapítol.

• L’estratègia recomanada per a entorns seriosos és separar per directoris: una carpeta per entorn (dev/, stg/, prod/), cadascuna amb la seva configuració i el seu estat propi.
• La lògica viu una sola vegada als mòduls (Capítol 18); cada entorn crida aquests mòduls amb valors diferents (mides, quantitats), evitant duplicar la lògica.
• Avantatges respecte als workspaces: separació clara i forta, difícil equivocar-se d’entorn (entres físicament a la carpeta), visibilitat total i flexibilitat perquè cada entorn divergeixi.
• Com cases separades per a cada propòsit, en comptes de redecorar la mateixa casa.
• Inconvenient: una mica de repetició entre entorns, que Terragrunt ajuda a reduir (següent subcapítol).

Al següent subcapítol veurem Terragrunt, una eina que manté les teves configuracions d’entorn DRY (sense repetició).