Tota aplicació real necessita diversos entorns: un de desenvolupament per provar, un altre de staging (preproducció) per validar, i el de producció on hi ha els usuaris reals. En aquest capítol veurem com gestionar aquests entorns amb Terraform. Comencem per una eina que el mateix Terraform ofereix: els workspaces. Però, compte, també veurem per què tenen limitacions importants.

Mai no has de provar canvis directament en producció: seria com fer experiments amb els clients reals mirant. Per això es separen els entorns:

Cada entorn sol tenir la mateixa estructura d’infraestructura (una VPC, uns servidors, una base de dades...), però amb diferències: producció és més gran i robusta, desenvolupament és més petit i barat. El repte és: com gestiono el mateix codi per a diversos entorns sense duplicar-ho tot?

Recorda l’estat de Terraform (Capítol 11): el fitxer que registra quins recursos existeixen. Un workspace (espai de treball) és, en essència, un estat separat dins del mateix codi. Canviant de workspace, Terraform utilitza un estat diferent, cosa que et permet tenir diverses còpies de la mateixa infraestructura sense que es barregin.

Les comandes bàsiques:

Dins del codi, pots saber en quin workspace estàs amb terraform.workspace, i adaptar valors en conseqüència:

Analogia: els workspaces són com tenir diverses partides guardades del mateix videojoc. El joc (el codi) és el mateix, però cada partida (workspace) té el seu propi progrés (estat) independent. Canvies de partida i treballes sobre una altra realitat sense afectar les altres.

Els workspaces semblen la solució perfecta, però tenen problemes seriosos que has de conèixer abans d’adoptar-los per gestionar entorns. De fet, la comunitat no recomana fer servir workspaces per separar dev/stg/prod. Vegem per què.

Tots els workspaces comparteixen el mateix codi i el mateix backend (el mateix bucket d’estat). Això significa que la separació entre producció i desenvolupament és fràgil: un error pot afectar diversos entorns, i no hi ha una barrera forta entre ells.

Com que canvies d’entorn amb un simple workspace select, és fàcil oblidar en quin estàs i aplicar un canvi al lloc equivocat. Imagina executar un apply pensant que estàs a dev quan en realitat estàs a prod. ⚠️ Aquest error ha causat incidents reals.

Si els teus entorns són molt diferents (no només en mida, sinó en estructura: producció té components que desenvolupament no), forçar-ho tot en un mateix codi amb condicionals (terraform.workspace == ...) es torna enrevessat i difícil de llegir.

No és evident, mirant el codi, què hi ha a cada entorn. Tot està barrejat i depèn de quin workspace estiguis, cosa que dificulta entendre i auditar la infraestructura.

Els workspaces tenen el seu lloc en casos senzills:

• Quan els entorns són gairebé idèntics i només canvien detalls menors (una mida, un nom).
• Per crear còpies temporals de prova (per exemple, un entorn per cada branca de desenvolupament, que crees i destrueixes ràpid).
• En projectes petits on la separació forta no és crítica.

Per gestionar entorns seriosos (dev/stg/prod en una empresa), la recomanació general és no utilitzar workspaces, sinó una estratègia de directoris separats per entorn, que veurem al següent subcapítol (19.2). Aquesta estratègia dona una separació molt més clara, segura i visible.

Conclusió clau: els workspaces existeixen i són útils per a casos simples, però no són la millor eina per separar producció de desenvolupament en projectes reals. Coneix-los, però sigues conscient dels seus límits.

• Tota aplicació real necessita diversos entorns (dev, staging, producció) per no experimentar mai directament sobre els usuaris reals.
• Un workspace de Terraform és un estat separat dins del mateix codi, cosa que permet tenir diverses còpies de la infraestructura (com «partides guardades» del mateix joc). Es gestiona amb terraform workspace new/select/list.
• Limitacions importants: comparteixen codi i backend (separació dèbil), és fàcil confondre’t d’entorn (perillós), es compliquen si els entorns són molt diferents, i donen poca visibilitat.
• Fes-los servir per a casos senzills (entorns gairebé idèntics, còpies temporals), però no com a forma principal de separar dev/stg/prod en projectes seriosos.
• L’alternativa recomanada per a entorns seriosos és la separació per directoris, que veurem a continuació.

Al següent subcapítol veurem aquesta estratègia recomanada: organitzar la teva infraestructura en directoris per entorn.