Tanquem el capítol de gestió d'entorns veient en detall com es passen els valors a Terraform: els fitxers .tfvars i les variables d'entorn. Ja els hem esmentat de passada; ara entendràs bé com separar la configuració (els valors que canvien) del codi (la lògica que es queda igual). Aquesta separació és clau per gestionar entorns de manera neta.

Recordatori: les variables

Recorda les variables del Capítol 10. Una variable és un «forat» al teu codi que s’omple amb un valor des de fora:

variable "tipus_instancia" {
  description = "Tipus d'instància EC2"
  type        = string
}

variable "quantitat_servidors" {
  type    = number
  default = 1
}

El codi fa servir var.tipus_instancia, però no fixa el valor. D’on surt aquest valor? Hi ha diverses maneres de proporcionar-lo, i aquí les veiem.

Els fitxers .tfvars: la forma principal

Un fitxer .tfvars és un fitxer on assignes valors a les variables. És la forma més habitual i ordenada de configurar un entorn. Per exemple:

# produccio.tfvars
tipus_instancia      = "t3.large"
quantitat_servidors  = 5
nom_projecte         = "botiga-prod"
# desenvolupament.tfvars
tipus_instancia      = "t3.micro"
quantitat_servidors  = 1
nom_projecte         = "botiga-dev"

Fixa’t en la idea clau: el codi és el mateix, però cada fitxer .tfvars li dóna valors diferents. Això és exactament el que permet fer servir la mateixa lògica per a diversos entorns (subcapítol 19.2).

Com s’utilitza un .tfvars

Indiques a Terraform quin fitxer de valors utilitzar amb l’opció -var-file:

terraform apply -var-file="produccio.tfvars"     # aplica amb valors de producció
terraform apply -var-file="desenvolupament.tfvars"   # aplica amb valors de desenvolupament

Cas especial — terraform.tfvars: si anomenes un fitxer exactament terraform.tfvars, Terraform el carrega automàticament sense que hagis d’indicar-ho. Per això, en l’estratègia de directoris (subcapítol 19.2), cada carpeta d’entorn sol tenir el seu propi terraform.tfvars que s’aplica sol.

Analogia: el codi Terraform és com una plantilla de carta amb forats («Benvolgut ___, la seva comanda ___ està llesta»). Els fitxers .tfvars són les dades que omplen els forats per a cada destinatari. Una plantilla, moltes cartes personalitzades. Canvies les dades, no la plantilla.

Les variables d’entorn: una altra manera de passar valors

Una altra manera de donar valors a les variables és a través de variables d’entorn del sistema operatiu, fent servir el prefix TF_VAR_:

TF_VAR_tipus_instancia = "t3.micro"

Terraform llegeix automàticament qualsevol variable d’entorn que comenci per TF_VAR_ i l’assigna a la variable corresponent (aquí, tipus_instancia).

Quan s’utilitza això? Sobretot en dos casos:

  • En automatització (CI/CD, Capítol 22): els sistemes automàtics solen passar els valors com a variables d’entorn, sense fitxers.
  • Per a dades sensibles (secrets): com veurem tot seguit, les contrasenyes i claus no han d’anar en fitxers .tfvars que es pugen a Git; les variables d’entorn són una manera de passar-les sense escriure-les en cap fitxer del repositori.

L’ordre de prioritat

Com que hi ha diverses maneres de donar valors, Terraform segueix un ordre de prioritat si un mateix valor es defineix en diversos llocs (de menor a major prioritat, a grans trets):

1. valor "default" a la definició de la variable   (la més baixa)
2. fitxer terraform.tfvars (automàtic)
3. fitxers -var-file que indiquis
4. variables d’entorn TF_VAR_
5. opció -var a la línia de comandes                (la més alta)

No cal memoritzar-ho, però queda’t amb la idea: si defineixes un valor en diversos llocs, guanya el més específic/directe. En cas de dubte, el que poses a la línia de comandes mana sobre la resta.

⚠️ Seguretat: mai posis secrets en .tfvars versionats

Això és crític. Els teus fitxers .tfvars amb la configuració normal (mides, noms) es guarden a Git sense problema. Però MAI has de posar dades sensibles —contrasenyes de bases de dades, claus d’API, tokens— en fitxers .tfvars que puges al repositori. Si ho fas, aquests secrets queden exposats a l’historial de Git per a qualsevol que hi accedeixi.

❌ MALAMENT:  password = "LaMevaContrasenya123" en un .tfvars pujat a Git
✅ BÉ: el secret es passa per variable d’entorn, o encara millor,
       es llegeix d’un gestor de secrets (Secrets Manager, Cap. 23)

Les formes correctes de gestionar secrets:

  • Variables d’entorn (TF_VAR_password), que no queden en cap fitxer del repo.
  • Gestors de secrets com AWS Secrets Manager o Parameter Store (que veurem al Capítol 23): Terraform els llegeix al moment, sense que el secret s’escrigui mai al codi.
  • Afegir els fitxers .tfvars amb secrets al .gitignore perquè mai es pugin.

Recorda també (del Capítol 11) que el mateix estat pot contenir dades sensibles, per la qual cosa el backend remot ha d’estar xifrat i amb accés restringit. La gestió de secrets és un tema seriós que reprendrem en profunditat al Capítol 23.

El que has de recordar

  • Les variables deixen «forats» al codi; els valors es proporcionen des de fora, separant la configuració del codi (la mateixa lògica serveix per a diversos entorns).
  • Els fitxers .tfvars són la forma principal d’assignar valors; fas servir -var-file="entorn.tfvars", i un fitxer anomenat terraform.tfvars es carrega automàticament.
  • Les variables d’entorn amb prefix TF_VAR_ són una altra manera de passar valors, útil en CI/CD i per a secrets.
  • Hi ha un ordre de prioritat quan un valor es defineix en diversos llocs: guanya el més directe (línia de comandes > entorn > fitxers > default).
  • ⚠️ Seguretat crítica: mai posis secrets (contrasenyes, claus) en .tfvars versionats a Git. Fes servir variables d’entorn, gestors de secrets (Secrets Manager, Capítol 23) i .gitignore.

Has acabat el Capítol 19! Ja saps gestionar múltiples entorns de manera neta i segura. Al Capítol 20 aprofundirem en un dels temes més importants per treballar en equip: els backends remots i el locking de l’estat.

Cloud, AWS & Terraform — De zero a expert

Capítol 1 · Què és el cloud computing

Capítol 2 · El mercat cloud i els grans proveïdors

Capítol 3 · Regions, zones de disponibilitat i edge

Capítol 4 · Càlcul: EC2

Capítol 5 · Emmagatzematge: S3

Capítol 6 · Xarxes: VPC

Capítol 7 · Identitat i accés: IAM

Capítol 8 · Bases de dades gestionades

Capítol 9 · Per què Infraestructura com a Codi

Capítol 10 · HCL: el llenguatge de Terraform

Capítol 11 · Providers i estat

Capítol 12 · La teva primera infraestructura real amb Terraform

Capítol 13 · Balanceig de càrrega i autoescalat

Capítol 14 · Serverless amb Lambda

Capítol 15 · Missatgeria i esdeveniments

Capítol 16 · Lliurament de contingut i DNS

Capítol 17 · Contenidors a AWS

Capítol 18 · Mòduls: reutilització i composició

Capítol 19 · Workspaces i gestió d'entorns

Capítol 20 · Backends remots i locking

Capítol 21 · Testing d'infraestructura

Capítol 22 · Terraform en CI/CD

Capítol 23 · Seguretat en profunditat

Capítol 24 · Observabilitat: logs, mètriques i traces

Capítol 25 · Optimització de costos

Capítol 26 · Alta disponibilitat i disaster recovery

Capítol 27 · Well-Architected Framework d'AWS

Capítol 28 · Arquitectures serverless a escala

Capítol 29 · Plataformes de dades a AWS

Capítol 30 · Multi-compte i landing zones

Capítol 31 · Platform Engineering i Internal Developer Platform

Capítol 32 · Certificacions AWS rellevants

Capítol 33 · Projectes per consolidar el que s'ha après

Capítol 34 · Recursos i comunitat

© Copyright 2024. Tots els drets reservats