Tanquem el capítol d’HCL amb les eines que fan el teu codi intel·ligent i eficient: els condicionals (prendre decisions) i els bucles (crear molts recursos sense repetir-te). Sense ells, hauries de copiar i enganxar el mateix bloc una vegada i una altra. Amb ells, escrius una vegada i Terraform genera el que calgui.

El problema: no repetir-se

Imagina que necessites tres servidors idèntics. Sense bucles, escriuries tres blocs resource gairebé iguals. Si necessitessis canviar alguna cosa, ho hauries de canviar als tres. Això és feixuc i propens a errors.

Els bucles resolen això: declares el recurs una vegada i indiques «crea’l N vegades». Vegem les eines.

count: crear N còpies

L’argument count crea diverses còpies d’un recurs. Li dónes un número i Terraform crea aquesta quantitat.

resource "aws_instance" "web" {
  count         = 3                  # ← crea 3 instàncies
  ami           = "ami-0c1234567890abcde"
  instance_type = "t3.micro"
  tags = {
    Name = "web-${count.index}"      # web-0, web-1, web-2
  }
}
  • count = 3 crea tres instàncies.
  • count.index és el número de cada còpia (0, 1, 2), útil per donar-los noms diferents.

Analogia: count és com dir-li a una fotocopiadora «fes-me 3 còpies d’aquest document». Totes iguals, numerades.

count també serveix per a condicionals (crear o no un recurs):

resource "aws_instance" "bastion" {
  count = var.crear_bastion ? 1 : 0   # 1 si true, 0 si false
  # ...
}

Si var.crear_bastion és true, en crea 1; si és false, en crea 0 (és a dir, cap). Aquest és un truc molt comú per fer un recurs «opcional».

for_each: crear còpies a partir d’una col·lecció

L’argument for_each crea una còpia per cada element d’un map o un set. A diferència de count (que usa números), for_each usa claus amb significat.

resource "aws_instance" "servidor" {
  for_each      = {
    web = "t3.micro"
    api = "t3.small"
    db  = "m5.large"
  }
  ami           = "ami-0c1234567890abcde"
  instance_type = each.value           # el valor: t3.micro, t3.small, m5.large
  tags = {
    Name = each.key                    # la clau: web, api, db
  }
}
  • Crea una instància per cada entrada del map.
  • each.key és la clau (web, api, db).
  • each.value és el valor (t3.micro, etc.).

Analogia: for_each és com tenir una llista de comandes personalitzades: «per a web, una t3.micro; per a api, una t3.small; per a db, una m5.large». Cada una amb les seves característiques.

count vs for_each: quin faig servir?

Aquesta és una decisió important i una font típica de confusió:

count for_each
Es basa en Un número Un map o un set
Identifica cada còpia per Posició (0, 1, 2…) Clau amb significat
Bo per a Còpies idèntiques o recursos opcionals Recursos amb identitat pròpia
Problema en esborrar-ne un del mig Reordena i pot recrear altres No afecta els altres

Regla pràctica:

  • Fes servir count per crear N còpies idèntiques o per fer un recurs opcional (count = condició ? 1 : 0).
  • Fes servir for_each quan cada recurs té una identitat pròpia (noms diferents, configuracions diferents). És més segur a l’afegir o treure elements.

Per què for_each sol ser preferible: amb count, si esborres l’element del mig d’una llista, els següents «es desplacen» i Terraform pot destruir i recrear recursos innecessàriament. Amb for_each, cada recurs està lligat a la seva clau, així que treure’n un no afecta els altres. Per això molts professionals prefereixen for_each excepte en casos simples.

L’expressió for: transformar col·leccions

No confonguis el bucle for_each (que crea recursos) amb l’expressió for (que transforma dades). L’expressió for genera una nova llista o map a partir d’una altra, semblant a una fórmula.

locals {
  noms        = ["web", "api", "db"]
  noms_majus  = [for n in local.noms : upper(n)]
  # resultat: ["WEB", "API", "DB"]
}

Llegeix així: «per a cada n a la llista noms, retorna upper(n)». És una forma compacta de transformar tots els elements d’una col·lecció.

Exemple útil: convertir una llista de noms en un map, o filtrar elements que compleixin una condició. És una eina avançada que veuràs en codi real, però al principi n’hi ha prou amb reconèixer-la.

Condicionals: l’operador ternari

Per prendre decisions dins d’una expressió, Terraform fa servir l’operador ternari (el mateix de molts llenguatges):

condició ? valor_si_cert : valor_si_fals

Exemples:

instance_type = var.entorn == "prod" ? "m5.large" : "t3.micro"
# Si l’entorn és "prod", usa m5.large; si no, t3.micro

count = var.alta_disponibilitat ? 2 : 1
# Si vols alta disponibilitat, crea 2; si no, 1

Analogia: és com dir «és producció? Llavors el servidor gran; si no, el petit». Una decisió ràpida en una sola línia.

Un exemple realista

variable "entorn" {
  type    = string
  default = "dev"
}

variable "subxarxes" {
  type = map(string)
  default = {
    publica-a  = "10.0.1.0/24"
    publica-b  = "10.0.2.0/24"
  }
}

resource "aws_subnet" "aquesta" {
  for_each   = var.subxarxes              # una subxarxa per cada entrada
  vpc_id     = aws_vpc.principal.id
  cidr_block = each.value                 # el rang de cada subxarxa
  tags = {
    Name = each.key                       # publica-a, publica-b
    Tipus = var.entorn == "prod" ? "produccio" : "desenvolupament"  # condicional
  }
}

Aquest codi crea una subxarxa per cada entrada del map subxarxes (bucle for_each), i etiqueta cada una segons l’entorn (condicional ternari). Has escrit un bloc i Terraform genera tantes subxarxes com defineixis, sense repetir codi.

El que has de recordar

  • count: crea N còpies d’un recurs (count = 3) o el fa opcional (count = condició ? 1 : 0). Identifica còpies per posició (count.index).
  • for_each: crea una còpia per cada element d’un map o set, amb identitat pròpia (each.key, each.value). Més segur a l’afegir/treure elements.
  • Regla: count per a còpies idèntiques o opcionals; for_each quan cada recurs és diferent (sol ser preferible).
  • L’expressió for transforma col·leccions (no confondre amb el bucle for_each).
  • L’operador ternari condició ? a : b pren decisions en una línia (ideal per diferenciar entorns).

Amb això tanques el Capítol 10 i ja saps llegir i escriure HCL. Al Capítol 11 veurem dues peces fonamentals perquè Terraform funcioni: els providers (com parla amb AWS) i l’estat (com recorda el que ha creat).

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