Primeres passes amb Terraform per a crear infraestructures

Terraform és una eina potent. Molt probablement ja n’has sentit a parlar en algun projecte, o fins i tot has llegit alguna cosa de la documentació oficial i has pensat que sona bé, però abstracte. Quan un ve del món de l’scripting o de l’aprovisionament manual, l’enfocament declaratiu de Terraform pot semblar un canvi de paradigma… i de vegades més una complicació que una solució.

1. Abans d’escriure una sola línia: defineix l ‘estat com una prioritat

Una de les primeres sorpreses desagradables amb Terraform sol venir del terraform.tfstate. És fàcil començar deixant l’estat en local, sobretot si estàs fent proves. Però el problema no és començar així: és quedar-se aquí.

Si estàs treballant només en el teu portàtil i mai has de compartir aquest codi, endavant. Però quan vulguis col·laborar, automatitzar o fer servir Git com a base de treball real, necessites externalitzar l’estat. I més important: necessites bloquejar-lo correctament.

El més comú (i raonable) és fer servir un backend de tipus s3 amb bloqueig mitjançant DynamoDB a AWS. T’estalvia més d’un disgust quan dues persones executen terraform apply alhora. La configuració porta 5 minuts i t’evita hores de conflictes o estats corromputs.

Exemple mínim per a S3 + DynamoDB:

terraform {
  backend "s3" {
    bucket         = "infra-terraform-state"
    key            = "prod/vpc/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Aquest patró funciona bé. No intentis inventar res aquí. El que experimenta amb l’emmagatzematge de l’estat acaba penedint-se.

2. No et compliquis al començament amb mòduls personalitzats

Terraform té un sistema de mòduls que sembla molt atractiu: encapsulació, reutilització, inputs/outputs… en teoria sona bé. A la pràctica, he vist més mals de cap que beneficis quan s’intenta modularitzar des del primer dia.

El consell aquí és clar: comença en pla. Tot en un sol arxiu, o en diversos arxius però sense encapsular en mòduls. Quan vegis patrons repetits o estructures que vulguis reutilitzar, aquí sí, crea mòduls. Però no abans.

Crear mòduls massa aviat sovint porta a dissenys rígids, difícils de depurar i amb APIs internes que canvies cada dos dies. Si estàs escrivint Terraform i també has de mantenir un microframework de mòduls interns que només tu entens, alguna cosa va malament.

3. La validació d’inputs no és opcional

A aquestes alçades Terraform permet validacions força decents amb validation i type en variables. Fer-les servir des del començament t’evita errors difícils de detectar, sobretot quan d’altres comencen a fer servir les teves definicions sense saber exactament què espera cada paràmetre.

Exemple:

variable "environment" {
  type = string
  description = "Deployment environment"
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be one of dev, staging or prod."
  }
}

És un detall menor que t’estalvia temps cada vegada que algú omple malament un terraform.

4. Estructura de carpetes

Una altra decisió que sovint es fa sense pensar gaire: com organitzar els arxius. Hi ha moltes formes, però algunes escalen millor que d’altres. Una forma que ha funcionat bé en equips mitjans i grans és aquesta:

infra/
├── global/
│   └── networking/
├── prod/
│   ├── vpc/
│   ├── eks/
│   └── rds/
├── staging/
│   ├── vpc/
│   ├── eks/
│   └── rds/
└── modules/
    └── vpc/

Separar per entorn (prod/staging/dev) i després per component és més clar que fer-ho només per tipus de recurs. Et permet treballar en paral·lel sense col·lisions d’estat, i aplicar per parts. El més important és que cada bloc de recursos tingui el seu propi terraform init i el seu propi backend.

Evita els monòlits de centenars de recursos gestionats des d’ un únic main.tf. Són impossibles de mantenir i bloquegen el treball en equip.

5. El cicle de vida : plan, apply, errors i rollback

terraform plan i terraform apply són segurs… fins que no ho són. El que no es diu amb prou claredat és que Terraform no té rollback real. Si una operació falla a meitat de camí (per exemple, falla en crear un recurs després d’haver-ne destruït un altre), et toca arreglar-ho a mà.

Per això, quan el pla implica destrucció, pren-te temps per revisar-ho. I si pots, evita els canvis de tipus “destroy + recreate” en recursos crítics. Hi ha vegades que no es pot evitar, però almenys planifica l’impacte.

Fes servir lifecycle amb prevent_destroy en certs recursos (bases de dades, buckets, load balancers en producció) és una bona pràctica. T’obliga a ser explícit si realment vols destruir alguna cosa.

resource "aws_db_instance" "main" {
  # ...
  lifecycle {
    prevent_destroy = true
  }
}

Un cop ho actives, no pots esborrar la base per accident des de Terraform. Has de treure explícitament la protecció. De vegades molesta, però més molesta perdre dades.

6. Variables sensibles i secrets: evita temptacions

Terraform no és un gestor de secrets. Pots passar secrets per variables, sí, però això no vol dir que ho hagis de fer. Tot el que posis a terraform.tfvars, a l’estat o com a sortida (output) pot quedar en text pla.

Si necessites passar secrets a recursos (per exemple, contrasenyes per a bases de dades), és millor integrar-lo amb un gestor com AWS Secrets Manager, Vault, o el que fas servir habitualment. I si no en queda una altra, almenys marca les variables i outputs com a sensibles:

variable "db_password" {
  type      = string
  sensitive = true
}
output "password" {
  value     = var.db_password
  sensitive = true
}

Això no xifra res, però evita que surtin per pantalla en aplicar o fer un pla.

7. El que no gestiona Terraform: els límits del sistema

Terraform es porta bé amb la infraestructura, però malament amb el que canvia constantment. Configuracions que varien per cada entorn, registres DNS que apunten a recursos fora de l’ abast de Terraform, desplegaments continus de contenidors, etc. De vegades és millor deixar certes peces fora.

L’error comú és intentar posar tot a Terraform: des de l’IAM fins a les dades de configuració d’un microservei. És temptador, perquè així “queda tot gestionat”. Però els canvis freqüents acaben forçant actualitzacions de l’estat, canvis d’entorn innecessaris o problemes de sincronització.

Divideix amb sentit. Terraform per a infra estable. Una altra eina per al cicle de vida d’apps.

8. Automatització

És normal executar Terraform a mà al principi. Però no caiguis en l’error de deixar això sense documentar. Apunta què necessites tenir configurat (credencials, versions de Terraform i proveïdors, directoris des dels quals s’executa, variables necessàries…). Després, això es converteix en la teva base per automatitzar en CI/CD.

Quan automatices, no escales al llop. Un bon patró és:

1. terraform fmt -check
2. terraform validate
3. terraform plan -out=planfile
4. Aprovació manual
5. terraform apply planfile

Evita córrer apply directe en pipelins. Que algú ho aprovi abans. I guarda els plan com a artefactes per si cal revisar-los després.

9. Versionat

Un error que es veu molt al principi és deixar que cada desenvolupador o sistema CI faci servir una versió diferent de Terraform o del proveïdor. Això trenca reproducibilitat, sobretot quan hi ha canvis subtils entre versions (que n’hi ha, i molts).

Sempre fixa la versió de Terraform i també les versions dels proveïdors.

Exemple:

terraform {
  required_version = ">= 1.5.0, < 1.6.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.39.0"
    }
  }
}

No bloquegis a una versió exacta tret que tinguis una necessitat molt concreta. Però fes servir rangs compatibles, i actualitza conscientment, no per accident.

En repos grans, automatitzar proves amb versions noves (tot i que no s’utilitzin en producció encara) ajuda a detectar incompatibilitats a temps.

10. L’estat com a font de veritat

Terraform assumeix que l’estat és la font de veritat. Però en entorns reals, això es trenca sovint. Algú esborra un recurs a mà, canvia un paràmetre a la consola, o modifica una etiqueta sense passar per Terraform. Tard o d’hora passa.

Per això és tan important entendre com funciona, i quan fer servir import.

És útil per a incorporar recursos que ja existeixen al núvol. Però no és màgia: necessites definir prèviament el recurs a HCL. No crea codi per tu. La documentació dona a entendre que és directe, però el cert és que pot ser tediós, especialment si el recurs té molts paràmetres obligatoris.

I compte amb fer servir terraform apply sense revisar bé el pla quan hi ha desincronització entre estat i realitat: pots destruir una cosa que no volies.

En infra compartida (per exemple, subnets creades per a un mòdul de xarxa però fetes servir per EKS), estableix clarament què gestiona Terraform i què no. Documenta els límits. Les zones grises són on es trenca tot.

11. Blocs locals, data i output

locals no és sucre sintàctic: és clau per evitar repetició innecessària i encapsular lògica simple. Especialment útil en estructures condicionals o llistes filtrades. Estalvia errors.

Exemple:

locals {
  enabled_azs = slice(data.aws_availability_zones.available.names, 0, 2)
}

També convé conèixer bé els data, sobretot quan necessites consultar informació externa sense gestionar-la. Per exemple, recuperar l’ID d’una AMI oficial, o l’ARN d’un role que no crees tu.

Evita fer servir data per resoldre coses que podries parametritzar millor. Si passes un valor com a input, la teva infraestructura és més portable.

Pel que fa als output, són molt útils en entorns compartits, especialment si els connectes amb altres mòduls o sistemes externs. Però no abusos. Si tot és output, és difícil saber què és rellevant.

12. Errors comuns

Alguns errors que he vist fins i tot en entorns madurs:

1. Manca de naming consistent. Els noms importen. Fes servir un patró, documenta i aplica. Especialment en etiquetes (tags) i noms de recursos.
2. Dependències implícites. Terraform ordena operacions automàticament, però si dos recursos depenen d’un output compartit que no està declarat com a dependència, es pot trencar. Usa depends_on amb criteri.
3. Ambients mal aïllats. Usar un sol backend per a múltiples entorns o tenir recursos compartits entre entorns genera problemes. Aïlla bé: fins i tot si és més codi, és més control.
4. Recursos orfes. Si esborres un recurs del .tf però no fas apply, continua existint. Terraform no t’avisa. Usa terraform plan freqüentment per netejar.

13. Patrons que funcionen bé

Aquests patrons han demostrat ser estables en projectes reals:

1. Un repositori per entorn, o almenys branques ben separades amb backends diferents. Compartir codi entre entorns està bé, compartir estats no.
2. Mòduls versionats i publicats en repos específics. No mantinguis els mòduls a la mateixa carpeta que el codi d’ infraestructura. Tampoc els deixis sense versionar.
3. CI/CD que permet pla autònom però requereix aprovació humana per a apply. Terraform no entén el negoci. Una persona hauria de revisar abans d’aplicar.
4. Variables passades sempre per arxius .tfvars versionats o injectades des del pipeline. Mai valors codificats.

14. Quan Terraform no és suficient

Hi ha casos on Terraform no és la millor eina. Si el que necessites és gestionar desenes de microserveis amb cicles de vida independents, és probable que un sistema com Pulumi, CloudFormation + CodePipeline o fins i tot una eina d’orquestració ad-hoc et doni més control.

Terraform s’adapta malament a entorns amb molta mutabilitat. També requereix que la infraestructura estigui definida de forma determinista, i això no sempre és possible si hi ha parts creades per altres sistemes.

L’error no és fer servir Terraform. L’error és insistir que ho faci tot, encara que no encaixi.

15. Conclusió

Terraform no és difícil. Però és fàcil fer-ho malament. I quan això passa, els errors no es veuen fins que trenques alguna cosa en producció. Per això, el consell més útil en començar és anar pas a pas: pla, aïllat, explícit. La resta pot venir després.

No cal que inventis el teu propi framework de Terraform, ni que converteixis cada component en un mòdul. El que necessites és control, claredat i seguretat. Això no ve del nombre de línies d’HCL, sinó de com tens la teva feina.

Si véns del món dels scripts, t’ha de semblar que Terraform treu poder. Si véns de la consola, que dona massa responsabilitat. En tots dos casos, el temps t’ensenya a valorar que l’important no és automatitzar, sinó fer-ho de forma predictible i llegible.

I aquí, Terraform continua sent una bona elecció.