La Infraestructura com a Codi (Infrastructure as Code, IaC) és la pràctica de definir i gestionar la infraestructura —servidors, xarxes, bases de dades, balancejadors, regles de seguretat— mitjançant fitxers de codi versionats, en lloc de configurar-la a mà per consoles web o comandes soltes. Igual que el codi de la teva aplicació viu en un repositori, la descripció de la teva infraestructura també, amb tot el que això aporta: control de versions, revisió per parells, reproductibilitat exacta i automatització en pipelines. Importa perquè elimina la configuració a mà (lenta, propensa a errors i no documentada), evita la "deriva de configuració" (que l'entorn real es desviï de l'esperat) i permet crear, replicar o destruir entorns complets en minuts de forma fiable. Aquesta lliçó tanca el mòdul ensenyant-te els conceptes i les eines clau, amb Terraform com a exemple principal.

1. El problema que resol IaC.
2. Declaratiu davant d'imperatiu.
3. Comparativa d'eines: Terraform, CloudFormation i Ansible.
4. Idempotència: el concepte central.
5. Exemple pràctic amb Terraform.
6. IaC en pipelines de CI/CD.
7. Errors comuns i consells.
8. Exercicis i solucions.

La gestió manual d'infraestructura (fer clic a la consola del proveïdor) té problemes greus: no és reproduïble (muntar el mateix entorn dues vegades dona resultats diferents), no queda documentada (ningú sap per què existeix aquesta regla de firewall), no és revisable (no hi ha manera de revisar un canvi abans d'aplicar-lo) i produeix deriva de configuració (drift): l'entorn real divergeix a poc a poc del previst. IaC converteix la infraestructura en codi: una font de veritat única, versionada a Git, revisable mitjançant pull requests i aplicable de forma automàtica i repetible.

Hi ha dos enfocaments per descriure infraestructura:

• Imperatiu: dones instruccions seqüencials ("crea un servidor, després instal·la això, després obre aquest port"). Tu controles el com.
• Declaratiu: descrius l'estat final desitjat ("vull un servidor amb aquestes característiques i aquest port obert") i l'eina esbrina quines accions calen per assolir-lo des de l'estat actual. És l'enfocament dominant en IaC moderna per ser més robust i fàcil de raonar.

Distinció clau sovint confosa: aprovisionar (crear la infraestructura: VM, xarxes) davant de gestionar la configuració (instal·lar i configurar programari dins de les màquines). Terraform i CloudFormation destaquen a aprovisionar; Ansible destaca a configurar l'interior dels servidors. És molt comú combinar-los: Terraform crea les màquines i Ansible les configura. Terraform fa servir el seu propi llenguatge, HCL (HashiCorp Configuration Language); CloudFormation fa servir YAML/JSON i està lligat a AWS.

Idempotència significa que aplicar la mateixa operació una o moltes vegades produeix el mateix resultat final, sense efectes secundaris acumulatius. En IaC és fonamental: executar terraform apply deu vegades sobre una configuració que no ha canviat no ha de crear deu servidors, sinó deixar l'estat tal com està. L'eina compara l'estat desitjat (el teu codi), l'estat real (el que existeix al proveïdor) i el seu fitxer d'estat (el que creu que gestiona), i només aplica la diferència (el plan). Gràcies a la idempotència, IaC és segura de reexecutar, cosa que permet automatitzar-la en pipelines sense por de duplicar recursos.

Definim una instància de servidor i el seu grup de seguretat a AWS amb HCL. Terraform funciona en un cicle: escriure el codi, veure el plan (què canviarà) i aplicar.

Explicació bloc a bloc:

• provider "aws": configura el proveïdor i la regió. Terraform baixarà el plugin adequat.
• variable "instance_type": declara un paràmetre amb valor per defecte t3.micro, que es pot sobreescriure per entorn (així reutilitzes el mateix codi en proves i producció).
• resource "aws_security_group" "web_sg": crea un grup de seguretat (un firewall) que permet trànsit entrant (ingress) al port 80 des de qualsevol IP (0.0.0.0/0).
• resource "aws_instance" "servidor_web": crea la màquina. instance_type = var.instance_type fa servir la variable. vpc_security_group_ids = [aws_security_group.web_sg.id] referencia el grup anterior: Terraform detecta aquesta dependència i crea primer el grup de seguretat i després la instància, en l'ordre correcte. Les tags etiqueten el recurs.
• output "ip_publica": després d'aplicar, Terraform mostrarà la IP pública de la instància.

El cicle de treball a la terminal:

Explicació: terraform init prepara el directori. terraform plan és el pas de seguretat clau: mostra exactament què canviarà abans de tocar res, cosa que permet revisar-ho. terraform apply executa el plan i convergeix a l'estat desitjat (és idempotent: si res no ha canviat, no fa res). terraform destroy elimina el que s'ha creat, molt útil per a entorns de proves que s'aixequen i es tiren.

El veritable poder d'IaC apareix en integrar-lo en un pipeline automatitzat: cada canvi a la infraestructura passa per revisió i s'aplica sol. Un flux típic amb GitHub Actions:

Explicació: el pipeline es dispara en pull requests i en push a main. En un PR executa terraform plan, de manera que els revisors veuen el canvi proposat a la infraestructura abans d'aprovar-lo (igual que es revisa codi). Només quan el canvi es fusiona a main s'executa terraform apply -auto-approve, aplicant la infraestructura de forma automàtica. Així, la infraestructura es governa amb el mateix rigor que el programari: revisió, traçabilitat i desplegament automatitzat. Aquesta pràctica es coneix com a GitOps quan el repositori Git és la font de veritat de l'estat desitjat.

• No versionar el fitxer d'estat correctament. L'estat de Terraform és sensible i crític: guarda'l en un backend remot compartit (amb bloqueig) i mai el pugis en text pla a Git, ja que pot contenir secrets.
• Editar a mà el que gestiona IaC. Canviar recursos per la consola provoca deriva: el codi deixa de reflectir la realitat. Canvia sempre per codi.
• No revisar el plan abans d'aplicar. terraform plan existeix per evitar sorpreses (com destruir una base de dades sense voler). Llegeix-lo sempre.
• Secrets hardcodejats al codi IaC. Fes servir variables, gestors de secrets o variables d'entorn; mai incrustis credencials als .tf.
• Monòlits d'IaC gegants. Un únic estat per a tota l'empresa és fràgil i lent. Divideix per entorns i dominis (mòduls, workspaces).
• Consell: tracta la infraestructura com a programari descartable i reproduïble. Si no pots recrear un entorn des de zero amb una comanda, encara no tens veritable IaC. Recorda que en sectors regulats els canvis d'infraestructura poden requerir controls i aprovacions addicionals; valida el flux amb el teu equip de govern i compliance.

1. Explica amb les teves paraules què significa que terraform apply sigui idempotent i per què això és important per executar-lo dins d'un pipeline.
2. El teu company ha canviat a mà la mida d'una instància des de la consola del proveïdor, però el codi IaC segueix amb el valor antic. Quin problema es produeix i què farà Terraform en el següent apply?
3. Vols crear màquines al núvol i, a més, instal·lar i configurar programari dins d'elles. Quines eines combinaries i quin rol tindria cadascuna?

1. Que terraform apply sigui idempotent significa que aplicar la mateixa configuració una o diverses vegades deixa el sistema en el mateix estat final: si res no ha canviat al codi, no crea ni modifica recursos. Això és important en un pipeline perquè permet executar-lo automàticament i repetidament sense por de duplicar infraestructura o provocar efectes acumulatius; sempre convergeix a l'estat desitjat.
2. Es produeix deriva de configuració (drift): l'estat real divergeix del declarat al codi. En el següent terraform plan/apply, Terraform detectarà que el recurs real no coincideix amb el desitjat i proposarà revertir el canvi manual per tornar al valor del codi (o mostrarà la diferència perquè decideixis). Per això no s'ha d'editar a mà el que gestiona IaC.
3. Combinaria Terraform (o CloudFormation) per aprovisionar la infraestructura: crear les màquines, xarxes i grups de seguretat; i Ansible per a la gestió de configuració: instal·lar paquets, desplegar l'aplicació i ajustar el sistema operatiu dins d'aquestes màquines. Terraform crea el "contenidor" físic/virtual i Ansible el deixa llest per funcionar.

Has après què és la Infraestructura com a Codi i per què substitueix la configuració manual: reproductibilitat, versionat i automatització. Hem distingit l'enfocament declaratiu de l'imperatiu, hem comparat Terraform, CloudFormation i Ansible, hem entès la idempotència com a concepte central, hem escrit un exemple complet en Terraform i l'hem integrat en un pipeline de CI/CD amb revisió del plan. Amb això tanques el Mòdul 8 d'Arquitectura al Núvol i Desplegament: ara disposes de les peces per dissenyar, contenidoritzar, executar (amb o sense servidor) i aprovisionar aplicacions cloud-native de principi a fi, llestes per escalar i operar amb fiabilitat en producció.