Al Capítol 11 vam veure per sobre l’estat remot. Ara hi aprofundirem, perquè és un dels pilars del treball en equip amb Terraform. En aquest subcapítol configurarem el backend més utilitzat al món AWS: S3 + DynamoDB. S3 guarda l’estat, i DynamoDB s’encarrega del «locking» (bloqueig) perquè diverses persones no es trepitgin. Vegem-ho pas a pas.

Repàs: per què necessites un backend remot

Recorda del subcapítol 11.3 el problema de l’estat local: si el fitxer terraform.tfstate és al teu portàtil, el teu equip no pot col·laborar (cadascú tindria la seva pròpia còpia), i si perds el fitxer, perds el control de la teva infraestructura. La solució és guardar l’estat en un lloc central i compartit: un backend remot.

Estat local (malament per equips):     Estat remot (bé):
  tfstate al teu portàtil               tfstate a S3 (central)
  - només tu el tens                    - tot l’equip el comparteix
  - es pot perdre                       - segur, amb còpies i versions

El backend S3 + DynamoDB: els dos components

El backend estàndard a AWS combina dos serveis que ja coneixes, cadascun amb un paper:

┌─────────────── Backend remot ───────────────┐
│  S3        → guarda el fitxer d’estat        │
│  DynamoDB  → gestiona el "lock" (bloqueig)   │
└────────────────────────────────────────────────┘
  • S3 (Capítol 5): emmagatzema el fitxer tfstate. És durador, està versionat i xifrat.
  • DynamoDB (subcapítol 8.3): gestiona el bloqueig per evitar que dues persones modifiquin l’estat alhora (ho veurem a fons al subcapítol 20.2).

Pas 1: Crear el bucket de S3 i la taula de DynamoDB

Aquests dos recursos són els «fonaments» que han d’existir abans de configurar el backend. Se solen crear només una vegada:

# Bucket de S3 per guardar l’estat
resource "aws_s3_bucket" "estat" {
  bucket = "la-meva-empresa-terraform-estat"
}

# Activar versionat: guarda l’historial de l’estat (molt recomanable!)
resource "aws_s3_bucket_versioning" "estat" {
  bucket = aws_s3_bucket.estat.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Taula de DynamoDB per al locking
resource "aws_dynamodb_table" "locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Fixa’t en dos detalls importants:

  • El versionat del bucket (recorda el subcapítol 5.3) guarda l’historial de l’estat. Si alguna cosa surt malament, pots tornar a una versió anterior. És una xarxa de seguretat molt valuosa.
  • La taula de DynamoDB utilitza una clau LockID: aquí és on Terraform escriu el «cadenat» quan algú està treballant.

Pas 2: Configurar el backend al teu projecte

Un cop existeixen el bucket i la taula, configures el teu projecte perquè utilitzi aquest backend. Això es fa al bloc terraform:

terraform {
  backend "s3" {
    bucket         = "la-meva-empresa-terraform-estat"   # el bucket S3
    key            = "produccio/terraform.tfstate"        # ruta de l’estat
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"                   # la taula de locking
    encrypt        = true                                # xifra l’estat
  }
}

Repassem cada línia:

  • bucket: el bucket de S3 on es guarda l’estat.
  • key: la ruta del fitxer dins del bucket. Fixa’t en produccio/...: utilitzar una ruta diferent per entorn és clau per a l’estratègia de directoris (subcapítol 19.2). Cada entorn té el seu propi estat separat.
  • dynamodb_table: la taula que gestiona els bloquejos.
  • encrypt = true: xifra l’estat en repòs. Important, perquè l’estat pot contenir dades sensibles (subcapítol 11.2).

Pas 3: Inicialitzar

Després de configurar el backend, executa terraform init (subcapítol 11.4). Terraform detecta el backend i, si ja tenies estat local, et pregunta si vols migrar-lo al remot:

terraform init
  → Terraform detecta el backend S3
  → "Migrar l’estat existent a S3?" → yes
  → a partir d’ara, l’estat viu a S3

Ja està! El teu estat ja està centralitzat, versionat, xifrat i amb bloqueig. El teu equip pot col·laborar de manera segura.

Un detall: el «problema de l’ou i la gallina»

Potser et preguntes: si Terraform crea el bucket i la taula... on es guarda l’estat d’aquests recursos abans que el backend existeixi? És un petit dilema circular. La solució habitual:

  1. Crees el bucket i la taula amb estat local (sense backend encara).
  2. Un cop existeixen, afegeixes la configuració del backend i fas init per migrar l’estat a S3.

Una altra opció és crear aquests recursos «base» manualment una vegada. En qualsevol cas, és un pas inicial que només es fa una vegada per organització.

El que has de recordar

  • L’estat local no serveix per a equips (no es comparteix i es pot perdre); necessites un backend remot central i compartit.
  • El backend estàndard a AWS és S3 + DynamoDB: S3 guarda el fitxer d’estat (durador, versionat, xifrat) i DynamoDB gestiona el bloqueig (lock) perquè ningú es trepitgi.
  • Configuració: crea el bucket S3 (amb versionat, com a xarxa de seguretat) i la taula DynamoDB (clau LockID); després declara el backend "s3" amb bucket, key (ruta per entorn), dynamodb_table i encrypt = true.
  • Utilitza una key diferent per entorn (produccio/..., dev/...) per separar els estats (estratègia del subcapítol 19.2).
  • Un cop configurat, terraform init migra l’estat al backend. Els recursos «base» (bucket i taula) es creen només una vegada (amb un pas inicial per a l’«ou i la gallina»).

Al següent subcapítol aprofundirem en la peça que fa segur el treball en equip: el state locking i com evita la corrupció 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