A 06-05 va quedar tot dit tret de l'essencial. Saps quin és el problema —la infraestructura d'AlpinaShop existeix només perquè la Marta va executar les comandes correctes, i ningú no sabria reproduir-la—, saps què és la infraestructura com a codi, entens l'estat i coneixes el procediment de migració pas a pas. El que falta és l'eina amb què fer-ho.

Aquesta lliçó la porta, i amb ella es tanca el mòdul. En acabar, la VPC d'AlpinaShop, les seves subxarxes, les seves regles de tallafoc i els seus buckets estaran escrits en fitxers que es revisen en un pull request, s'apliquen des d'un pipeline i es poden reproduir en una altra regió canviant una variable. I la resposta a «quant de temps es triga a reconstruir l'entorn?» passarà de «ningú no ho sap» a «uns vint minuts».

Un avís sobre l'abast: aquesta lliçó ensenya Terraform prou per gestionar la infraestructura d'AlpinaShop amb criteri. Terraform dona per a un curs sencer, i aquí es cobreix el que es fa servir el 95 % del temps, assenyalant el que queda fora.

1. Per què Terraform va guanyar
2. Els conceptes: proveïdor, recurs, font de dades, variable, sortida i dependències
3. L'estat: què conté i per què no va mai a Git
4. El backend remot a Cloud Storage
5. El flux de treball: init, validate, plan, apply, destroy
6. Com es llegeix un pla
7. Codi real d'AlpinaShop: la xarxa i el bucket
8. Variables, tfvars i entorns
9. Mòduls: escriure el mòdul red-alpinashop
10. Mòduls del registre públic, amb criteri
11. Importar el que ja existeix
12. Terraform a CI/CD: plan a cada pull request
13. Què NO ha de gestionar Terraform
14. prevent_destroy i el perill de terraform destroy
15. Infrastructure Manager i alternatives
16. L'estat final d'AlpinaShop

A 06-05 es va veure per què Deployment Manager va perdre. L'altra cara és per què va guanyar Terraform, i no és només mèrit tècnic:

La primera fila importa més del que sembla fins i tot per a qui només fa servir GCP. La infraestructura real d'AlpinaShop no és només GCP: hi ha un registre DNS al registrador del domini, repositoris i proteccions de branca a GitHub, potser demà una CDN externa. Amb Terraform, tot això es declara al mateix lloc i amb el mateix flux, i les dependències entre proveïdors funcionen igual que dins d'un.

Una nota sobre la llicència, perquè cal ser honest: el 2023 HashiCorp va canviar Terraform d'una llicència de codi obert a la Business Source License, cosa que va provocar l'aparició d'OpenTofu, una bifurcació sota llicència oberta gestionada per una fundació. Per a l'ús normal —una empresa gestionant la seva pròpia infraestructura— la BSL no imposa cap restricció pràctica, i totes dues eines són compatibles a nivell de codi i d'estat. És una cosa que convé conèixer; per a AlpinaShop no canvia res.

Terraform s'escriu en HCL (HashiCorp Configuration Language), i té pocs tipus de bloc. Amb aquests sis es fa gairebé tot.

Proveïdor (provider): el complement que sap parlar amb una API. Es declara amb la versió fixada:

Fixar la versió del proveïdor no és opcional. Sense version, Terraform descarrega l'última disponible, i una versió major pot canviar el comportament de recursos existents. La sintaxi ~> 6.0 permet actualitzacions menors i de pedaç però no el salt a la 7, que és on hi ha els canvis incompatibles.

Recurs (resource): alguna cosa que Terraform crea i gestiona.

La distinció entre el nom local (principal) i l'atribut name (alpinashop-vpc) confon al principi. El local és l'etiqueta amb què altres parts del codi referencien el recurs; l'atribut name és el que apareix a la consola de GCP.

Font de dades (data): consulta alguna cosa que existeix però que Terraform no gestiona.

La diferència amb un resource és total: un data només llegeix, mai no crea ni modifica. Serveix per obtenir el número de projecte, l'última imatge d'un sistema operatiu o un recurs creat per un altre equip.

Variable (variable): entrada parametritzable.

El bloc validation és l'equivalent als esquemes de Deployment Manager de 06-05, i produeix un error clar abans de tocar res.

Sortida (output): valor que s'exposa en acabar.

sensitive = true evita que el valor aparegui a la sortida. No el xifra ni l'amaga de l'estat, que és una distinció important i que reprenem a l'apartat 3.

Dependències. La majoria són implícites: neixen de referenciar un recurs des d'un altre.

Terraform construeix un graf, crea primer la xarxa i després la subxarxa, i paral·lelitza tot el que no té dependències entre si. Les explícites amb depends_on són l'últim recurs, per a dependències que no s'expressen mitjançant dades:

Consell: fes servir depends_on el mínim possible. Un depends_on que es pot substituir per una referència és una oportunitat perduda que el codi expressi la relació real.

A 06-05 es va explicar què és l'estat conceptualment. Aquí toca la part pràctica, que és on hi ha els problemes reals.

El fitxer terraform.tfstate és un JSON que conté, per a cada recurs gestionat: el seu nom local, el seu tipus, el seu identificador real a GCP i tots els seus atributs tal com estaven a l'última operació.

Mira l'última línia. La contrasenya és en clar al fitxer d'estat. No és un error de configuració: és el funcionament normal. Terraform desa tots els atributs de cada recurs, i alguns atributs són secrets. El mateix passa amb claus generades, testimonis i certificats.

D'aquí les quatre regles de l'estat:

I una conseqüència important que es deriva de tot això: l'accés a l'estat és tan sensible com l'accés a producció. Qui pot llegir el bucket de l'estat pot llegir les contrasenyes que Terraform gestioni. Per això l'apartat 13 insisteix que Terraform no ha de gestionar valors de secrets.

El .gitignore no és negociable:

Amb una excepció deliberada: .terraform.lock.hcl SÍ que va a Git. Aquest fitxer fixa les versions exactes dels proveïdors i les seves sumes de verificació, i versionar-lo garanteix que tot l'equip i el pipeline usen exactament el mateix. És l'equivalent a un package-lock.json.

El backend defineix on viu l'estat. Per a GCP, Cloud Storage.

Primer es crea el bucket, i això és l'únic que es fa a mà en tot el procés —problema de l'ou i la gallina—:

I es declara al codi:

El prefix és més important del que sembla: separa estats. prod/red, prod/datos, dev/red són estats independents, i aquesta separació limita el radi de dany: un error operant la xarxa no pot afectar l'estat de la base de dades.

El bloqueig funciona sol, sense configuració. Terraform crea un objecte .tflock mentre opera; si una altra persona llança apply alhora, obté un error clar en lloc de corrompre l'estat:

Si un procés mor deixant el bloqueig posat —una compilació cancel·lada, per exemple—, s'allibera amb terraform force-unlock ID. És una comanda que cal fer servir amb compte: només quan estiguis segur que no hi ha cap operació en curs.

El detall de -out=plan.tfplan mereix èmfasi perquè és la diferència entre revisar i confiar. Sense ell, terraform apply recalcula el pla en aquell moment; si alguna cosa va canviar entremig, aplica una cosa diferent de la que es va revisar. Amb el fitxer, aplica exactament l'aprovat. En un pipeline és obligatori.

I terraform destroy destrueix tot el de l'estat. El seu ús legítim és un entorn efímer de proves. En producció és la comanda més perillosa de l'eina, i l'apartat 14 explica com protegir-se'n.

Saber llegir un pla és l'habilitat més important d'aquesta lliçó. Un apply mal revisat és un incident.

Els quatre símbols:

I la línia resum al final:

La regla d'or és la del -/+. Un reemplaçament passa quan canvia un atribut que l'API de GCP no permet modificar en calent. Terraform, sense més opcions, destrueix i crea. I en alguns recursos això és catastròfic:

Aquest pla destruiria la base de dades de comandes d'AlpinaShop amb totes les seves dades. Terraform ho diu amb claredat —# forces replacement— però un apply automàtic o distret l'executa sense dubtar.

Què fer davant d'un -/+ inesperat, en aquest ordre: llegir quin atribut el força —Terraform ho marca amb # forces replacement—; decidir si aquest canvi és realment necessari; si ho és, buscar una via sense destruir —crear el recurs nou, migrar i esborrar el vell—; i si no ho és, corregir el codi. Mai aplicar sense haver entès la causa.

Un altre cas que confon: els plans que no surten mai buits encara que no canviïs res. Solen deure's a un atribut que GCP normalitza —una llista que reordena, un valor per defecte que emplena— i es resolen o bé escrivint el valor real al codi, o bé, quan el proveïdor té un comportament incorrecte, amb lifecycle { ignore_changes = [...] }. Aquesta segona opció és un pedaç i convé fer-la servir amb moderació: cada ignore_changes és una part de la infraestructura que Terraform deixa de vigilar.

Ara el codi de veritat, explicat línia a línia.

Fixa't en dues coses d'aquest codi que són la raó de ser de l'exercici. Primer, els comentaris expliquen el perquè, no el què: que 35.191.0.0/16 són les sondes de Google, que private_ip_google_access trenca mig mòdul 3 si falta. Aquest coneixement vivia al cap de la Marta i ara viu al repositori. I segon, les etiquetes entorno, equipo, centro-coste i aplicacion són les de tot el curs: en ser codi, deixen d'aplicar-se «quan algú se'n recorda» i s'apliquen sempre.

L'objectiu és que alpinashop-dev i alpinashop-prod comparteixin el mateix codi amb valors diferents, resolent la deriva de configuració de 06-05.

Carpetes per entorn davant de workspaces, que és la decisió estructural que cal prendre:

AlpinaShop tria carpetes per entorn, i la raó principal és de seguretat operativa: amb workspaces, l'única diferència entre aplicar en desenvolupament i aplicar en producció és haver executat terraform workspace select prod abans, i és massa fàcil oblidar-ho. Amb carpetes, cadascuna té el seu propi backend i el seu propi provider, i aplicar en producció exigeix ser físicament al directori de producció. És una barrera petita que evita l'error més car.

L'estructura resultant del repositori alpinashop-infra:

Un mòdul és un directori amb codi Terraform que s'invoca amb paràmetres. És el mecanisme de reutilització.

I el seu ús des de cada entorn:

Les tres regles d'un bon mòdul:

1. Una responsabilitat clara. red-alpinashop fa la xarxa. Un mòdul que crea la xarxa, la base de dades i el balancejador és un monolit amb un altre nom.
2. Parametritzar el que varia, fixar el que no. private_ip_google_access = true està fixat a propòsit: no és una decisió que cada entorn hagi de prendre, és una regla d'AlpinaShop.
3. Exposar les sortides que altres necessiten. Un mòdul les sortides del qual no basten obliga a trencar-ne l'encapsulació.

I un advertiment sobre l'excés d'abstracció, que és l'error més comú en descobrir els mòduls: un mòdul amb vint variables per cobrir tots els casos imaginables és més difícil d'usar que escriure el recurs directament. Comença amb codi pla, extreu un mòdul quan el repeteixis per segona vegada, i no abans.

El Terraform Registry allotja milers de mòduls públics, i Google manté una col·lecció de mòduls per a GCP de qualitat notable.

Els criteris per decidir si usar un mòdul públic o escriure el teu:

La regla que faig servir: com més complex és el recurs, més compensa el mòdul públic. Un mòdul per crear una VPC amb dues subxarxes estalvia poc i afegeix una dependència externa; un mòdul per muntar una VPC compartida amb regles jeràrquiques, o un clúster de GKE endurit amb totes les seves bones pràctiques, estalvia setmanes de feina i d'errors.

I dos advertiments seriosos. Fixa sempre la versió amb version = "~> X.Y": sense això, un terraform init al pipeline pot portar una versió nova del mòdul que canviï recursos de producció sense que ningú ho hagi decidit. I un mòdul públic és codi de tercers amb permisos sobre la teva infraestructura: per a mòduls d'organitzacions no conegudes, llegeix-lo abans, o bifurca'l al teu propi repositori. És exactament el mateix raonament de la cadena de subministrament de programari de 06-01.

Aquest és el moment d'aplicar el procediment de 06-05 amb l'eina real. Tot el que la Marta va crear a mà als mòduls 2 i 3 ha de passar a estar gestionat sense destruir ni recrear res.

La forma moderna, amb blocs import declaratius:

I el truc que estalvia la major part de la feina manual:

Terraform escriu a generado.tf la configuració dels recursos declarats als blocs import, llegida de la realitat. Després toca netejar-la —treure camps calculats, substituir literals per referències, afegir comentaris— exactament com es va explicar a 06-05.

El procediment complet, amb el cicle que cal respectar:

Consells perquè la migració no s'entravessi:

• De tres en tres, no de cinquanta en cinquanta. Un pla amb cinquanta recursos importats té centenars de línies i les diferències importants es perden. Importa un grup petit, verifica pla buit, avança.
• Comença pel que és inofensiu. Regles de tallafoc i buckets buits primer; Cloud SQL, l'últim.
• Tot primer a alpinashop-dev. Un error allà no costa res.
• prevent_destroy abans del primer apply en qualsevol recurs amb dades.
• Un -/+ t'atura sempre. La regla de l'apartat 6, aplicada amb més raó durant una importació.

El format de l'identificador varia per recurs i està documentat al final de la pàgina de cadascun al proveïdor google. És el detall més tediós, i no hi ha drecera.

Aquí convergeix tot el mòdul: el repositori de 06-02, el pipeline de 06-01 i la infraestructura com a codi de 06-05.

El flux que AlpinaShop implanta:

El pipeline de plan, que corre a cada pull request:

El pas que publica el pla com a comentari del pull request és el que canvia la cultura de l'equip. Sense ell, revisar un canvi d'infraestructura obliga a llegir HCL i imaginar-ne l'efecte. Amb ell, el revisor veu exactament quins recursos es creen, es modifiquen i es destrueixen, sense executar res. És l'aplicació literal del principi de 06-05: revisar la infraestructura com es revisa el codi.

El pipeline d'apply, amb aprovació manual:

Fixa't que aplica el fitxer de pla generat al PR, no un de recalculat. És el que garanteix que s'executa exactament l'aprovat. I el -auto-approve no és perillós aquí precisament per això: l'aprovació humana ja va passar, al disparador --require-approval de 06-01.

I sense cap clau. El compte de servei del pipeline s'autentica amb la identitat de Cloud Build; si l'apply corregués a GitHub Actions, seria amb Workload Identity Federation de 06-02. En cap punt d'aquest flux existeix un fitxer JSON de credencials.

Els permisos del compte de servei d'apply mereixen una nota: és el compte amb més poder de tota la infraestructura, perquè pot modificar xarxes, IAM i bases de dades. Ha d'estar acotat als recursos que gestiona, no ser Editor del projecte, i el seu ús ha d'estar auditat. És el mateix advertiment de 06-01 elevat un nivell.

Tan important com saber què gestionar és saber què deixar fora. La regla, ja enunciada a 06-05: Terraform gestiona la forma, no el contingut.

La primera fila és la més important i la més incomplerta. Mira la diferència:

I un cas intermedi que convé resoldre bé: una contrasenya generada aleatòriament. random_password també queda a l'estat, així que la solució correcta és que la generi el proveïdor —Cloud SQL pot fer-ho— o un procés extern, i que Terraform només creï el contenidor.

La pregunta que resol els dubtes: això canvia per si sol, o canvia perquè algú ho decideix? El que canvia sol —dades, instàncies autoescalades, taules de pipelines— no és de Terraform. El que canvia perquè algú ho decideix, sí.

terraform destroy destrueix tot el que hi ha a l'estat. És una operació legítima per a entorns efímers i una catàstrofe en producció, i hi ha tres maneres d'executar-la sense voler: escriure-la al directori equivocat, un apply amb un -/+ no revisat, i esborrar recursos del codi sense adonar-se que esborrar-los significa destruir-los.

La protecció de primer nivell, prevent_destroy, en tot el que contingui dades:

Amb prevent_destroy = true, un pla que intenti destruir el recurs no s'executa:

És un error de l'eina, no un avís. Per destruir-lo de veritat cal editar el codi, treure la protecció i tornar a aplicar: dos passos deliberats en lloc d'un d'accidental.

Les cinc capes de protecció d'AlpinaShop, defensa en profunditat:

I una precisió sobre l'abast de prevent_destroy: protegeix el recurs, no l'estat. Si algú esborra el bloc del codi, Terraform no ho veu i no protegeix res. La protecció real la donen les capes 3, 4 i 5 juntes.

Executar Terraform tu mateix implica gestionar el bucket de l'estat, el bloqueig, les versions i els permisos del pipeline. Infrastructure Manager és el servei gestionat de Google que fa tot això executant Terraform per sota:

Per a AlpinaShop, que ja té el pipeline de 06-01 funcionant i vol control total sobre el flux, Terraform propi és l'elecció. Infrastructure Manager és excel·lent per a equips que prefereixen no gestionar l'estat i viuen exclusivament a GCP.

Les alternatives al Terraform propi, per tenir el mapa complet:

Recomanació per a AlpinaShop: Terraform, per la raó que obre la lliçó —l'ecosistema i la gent que ja el coneix—. I una observació sobre Pulumi que mereix dir-se: escriure infraestructura en un llenguatge de propòsit general és temptador i té un risc real, perquè és fàcil escriure infraestructura massa intel·ligent. La limitació d'HCL és en part una virtut: obliga que la infraestructura sigui llegible per algú que no va escriure el codi.

Val la pena mirar l'abans i el després, perquè el recorregut ha estat llarg:

Aquest canvi de l'última fila és el resum cultural del mòdul. El coneixement ha sortit dels caps i ha entrat al repositori.

Pujar el .tfstate a Git. Conté secrets en clar i Git no oblida. Backend remot a Cloud Storage amb versionatge, i .gitignore des del primer commit.

No fixar la versió del proveïdor ni dels mòduls. Un init al pipeline pot portar una versió nova que canviï recursos de producció sense que ningú ho hagi decidit. version = "~> 6.0" sempre.

Executar apply sense fitxer de pla. Recalcula el pla i pot aplicar una cosa diferent de la revisada. plan -out=fitxer i apply fitxer.

Ignorar un -/+. És l'error més car de l'eina. Un reemplaçament sobre Cloud SQL o sobre un bucket amb contingut destrueix dades. Atura't sempre i entén quin atribut el força.

Gestionar secrets amb Terraform. El valor acaba en clar a l'estat. Terraform crea el contenidor a Secret Manager; el valor s'estableix fora.

Esborrar recursos del codi pensant que «deixen de gestionar-se». Esborrar-los del codi significa destruir-los. Per deixar de gestionar sense destruir: terraform state rm.

Usar workspaces per separar producció de desenvolupament. L'única barrera és recordar-se de workspace select, i algun dia algú no se'n recordarà. Carpetes per entorn.

Crear mòduls massa aviat. Un mòdul amb vint variables per cobrir tots els casos és pitjor que el codi pla. Extreu un mòdul la segona vegada que repeteixis alguna cosa.

Importar cinquanta recursos de cop. El pla resultant és il·legible i les diferències perilloses es perden. De tres en tres, verificant pla buit.

Oblidar prevent_destroy en recursos amb dades. Són dues línies i poden salvar la base de dades.

Continuar tocant coses a mà. El pecat original de la infraestructura com a codi. Tan bon punt el codi i la realitat divergeixen, l'eina deixa de ser fiable i tornes al punt de partida.

Consell final: comença pel que és nou. Si la migració de tot el que ja existeix sembla inabordable, adopta la regla que a partir d'avui, tot el que és nou es crea amb Terraform, i ves important el vell quan el toquis. En uns mesos, la major part estarà gestionada sense haver fet mai un projecte de migració.

Escriu un mòdul bucket-alpinashop que creï un bucket de Cloud Storage amb les convencions d'AlpinaShop: accés uniforme, prevenció d'accés públic, versionatge configurable, les quatre etiquetes obligatòries (entorno, equipo, centro-coste, aplicacion), una regla de cicle de vida parametritzable i prevent_destroy per a producció. Escriu-ne les variables amb validació, les sortides, i el bloc que l'invoca per crear alpinashop-datalake en producció. Explica què vas decidir parametritzar i què vas decidir fixar, i per què.

Un pull request d'alpinashop-infra genera aquest pla:

Analitza cada canvi, classifica'l per risc, digues si aprovaries el PR i què demanaries a l'autor. Indica quin és el més perillós i per què.

La Marta et demana dissenyar de principi a fi el flux de treball d'infraestructura d'AlpinaShop, donant per fet que la migració de 06-05 ja està completa. Defineix: l'estructura del repositori, la configuració del backend i la separació d'estats, els pipelines de Cloud Build necessaris, els permisos IAM de cada compte de servei implicat, les proteccions de branca i CODEOWNERS, i el procediment d'emergència per a quan calgui canviar alguna cosa en producció a les 3 de la matinada amb el pipeline caigut. Justifica les decisions de seguretat.

Solució 1

Què vaig parametritzar i per què:

El principi de disseny: es parametritza el que varia legítimament entre casos; es fixa el que és una decisió de l'organització. Convertir public_access_prevention en variable seria obrir la porta al fet que algú, amb presses, creï un bucket públic «només per a una prova». Si en algun moment calgués un bucket públic de veritat —un lloc estàtic—, es declara amb google_storage_bucket directament i aquest cas excepcional rep una revisió específica. Un mòdul també serveix per fer difícil el que no s'hauria de fer.

Sobre prevent_destroy, una decisió discutible que convé raonar. L'he fixat a true sempre, en lloc de parametritzar-lo per entorn. El motiu és que prevent_destroy no admet expressions: el bloc lifecycle no pot usar variables, així que prevent_destroy = var.entorno == "prod" dona error de sintaxi. És una limitació real de Terraform. Les opcions són fixar-lo a true per a tots —cosa que obliga a un pas manual per esborrar un bucket de proves, molest però segur— o crear dos mòduls. He triat el primer: la molèstia d'esborrar a mà un bucket de desenvolupament és molt menor que el risc de destruir-ne un de producció.

I un advertiment sobre dynamic: els blocs dinàmics són potents i fan el codi més difícil de llegir. Amb tres regles de cicle de vida condicionals, el mòdul comença a acostar-se al límit del raonable. Si creixessin a vuit, seria millor exposar una variable de llista de regles i deixar que qui l'usa les declari explícitament.

Solució 2

Anàlisi canvi a canvi:

Canvi 1 — destruir la regla d'SSH. És l'únic canvi que podria ser una millora: si aquesta regla permetia SSH des de rangs amplis, eliminar-la és exactament el que recomana 03-01. Però un - destroy en un pla sempre exigeix preguntar per què desapareix. Hi ha dues causes possibles amb implicacions oposades: que l'autor l'hagi esborrat deliberadament del codi, o que l'hagi esborrat per accident en editar el fitxer. El que cal demanar: que la descripció del pull request ho expliqui, i confirmació que ningú no depèn d'aquest accés —un proveïdor, un procés de còpies, un accés de suport—. Si ningú no ho sap, l'alternativa segura és restringir l'origen en lloc d'eliminar la regla, i observar durant una setmana amb els registres de tallafoc de 06-06 abans de retirar-la.

Canvi 2 — el reemplaçament de la subxarxa. Aquest és el que fa que el PR es rebutgi.

Ampliar 10.20.0.0/24 a 10.20.0.0/22 és una operació aparentment raonable —més adreces disponibles— i l'API de GCP no permet canviar el rang d'una subxarxa en calent quan hi ha recursos a dins. Terraform, sense més opcions, proposa destruir-la i crear-la.

El que passaria en aplicar: la destrucció de sn-datos-euw1 afecta tot el que hi viu, començant per la instància de Cloud SQL alpinashop-pedidos amb la seva IP privada. En el millor cas, l'operació falla a mitges perquè GCP es nega a esborrar una subxarxa amb recursos, i l'estat queda incoherent —Terraform creu haver començat una operació que no pot acabar—. En el pitjor, si alguna cosa hagués pogut esborrar-se, les IP privades canviarien i tot el que les referencia deixaria de funcionar. En cap dels dos casos el resultat és acceptable.

I hi ha una alternativa que fa el reemplaçament completament innecessari, i és el que cal proposar a l'autor: GCP permet ampliar el rang d'una subxarxa existent sense recrear-la, mitjançant gcloud compute networks subnets expand-ip-range. L'operació és no destructiva i només admet ampliar, mai reduir:

Després s'actualitza l'ip_cidr_range al codi i terraform plan surt buit, perquè la realitat ja coincideix. És un cas on l'operació correcta es fa fora de Terraform i el codi es limita a reflectir-la, i convé reconèixer-ho: forçar l'eina a fer una cosa que l'API no suporta bé és pitjor que fer una excepció documentada.

Canvi 3 — reduir el tier de Cloud SQL. No destrueix dades i per això molta gent el donaria per bo. Però passar de db-custom-4-15360 a db-custom-2-7680 redueix a la meitat la CPU i la memòria de la base de dades de producció, i té dues conseqüències immediates: un reinici de la instància, és a dir, tall de servei d'uns minuts, i una capacitat sensiblement menor per al mateix trànsit.

Les preguntes a l'autor: és intencionat o és un tfvars equivocat? I si és intencionat, està justificat amb dades? Aquí és on 06-04 entra en joc: si la CPU de Cloud SQL porta mesos per sota del 20 %, és un estalvi perfectament raonable. Si està al 60 %, reduir a la meitat la capacitat és provocar el proper incident. Un canvi de dimensionament sense la mètrica que el sustenti és una conjectura. I en qualsevol cas, s'ha d'aplicar en una finestra de manteniment, no un dimarts a les onze del matí.

Una sospita raonable, dit sigui de passada: que aquest canvi provingui d'haver aplicat dev.tfvars sobre producció per error, perquè db-custom-2-7680 té tota la pinta de ser el valor de desenvolupament. Val la pena comprovar-ho.

Canvi 4 — crear el bucket. L'únic inofensiu. Es revisa que tingui accés uniforme, prevenció d'accés públic, les quatre etiquetes i el seu cicle de vida, i ja està.

Aprovaria el PR? No. I el que demanaria, en aquest ordre:

1. Dividir el pull request en tres. Aquest PR barreja una millora de seguretat, un canvi de xarxa, un canvi de dimensionament i un recurs nou. Són quatre intencions diferents, amb riscos i moments d'aplicació diferents. Un PR amb una sola intenció es revisa bé, s'aprova ràpid i es reverteix netament si surt malament.
2. Treure l'ampliació de la subxarxa de Terraform, fer-la amb expand-ip-range i actualitzar el codi després.
3. Justificar el canvi de tier amb la mètrica de CPU dels últims dos mesos, i programar-lo en una finestra de manteniment.
4. Explicar a la descripció per què desapareix la regla d'SSH i confirmar que ningú no en depèn.

El més perillós és el canvi 2, sense discussió, i per una raó que convé explicitar: és l'únic irreversible. El canvi 3 es desfà tornant al tier anterior; el canvi 1 es desfà recreant la regla; el canvi 4 es desfà esborrant el bucket. Un recurs destruït no torna, i amb ell s'endú per davant les adreces IP privades de tot el que contenia.

I la lliçó de procediment: aquest pla és exactament l'argument a favor de publicar el plan com a comentari del pull request. Llegint només l'HCL modificat, el canvi de /24 a /22 sembla una edició menor d'un caràcter. És el pla el que revela que aquest caràcter destrueix la subxarxa de la base de dades.

Solució 3

Estructura del repositori alpinashop-infra:

Backend i separació d'estats. Bucket alpinashop-terraform-estado a alpinashop-cicd, amb versionatge, accés uniforme i prevenció d'accés públic. I estats separats per entorn i per domini:

La separació d'estats és una decisió de seguretat, no d'organització. Amb un únic estat, qualsevol operació sobre qualsevol recurs bloqueja tot i un error té abast total. Amb estats separats, tocar un tauler de Cloud Monitoring no pot afectar la base de dades ni tan sols en el pitjor cas.

Pipelines:

Que desenvolupament s'apliqui automàticament és deliberat: és la manera de garantir que alpinashop-dev reflecteix sempre main, que és just el que impedeix la deriva de 06-05. Producció exigeix aprovació per l'impacte.

Permisos IAM:

La decisió de seguretat més important: sa-tf-plan és de només lectura. El plan s'executa a cada pull request, i un pull request el pot obrir qualsevol —inclòs algú amb males intencions que modifiqui el cloudbuild-plan.yaml a la seva branca—. Si aquest compte tingués permisos d'escriptura, obrir un PR seria suficient per modificar producció. És exactament l'antipatró que es va explicar a 06-01, i aquí és encara més greu perquè parlem d'infraestructura.

La segona: les persones no tenen escriptura directa en producció. S'impersona sa-tf-apply-prod amb serviceAccountTokenCreator, cosa que queda registrada als registres d'auditoria amb el nom de la persona. És l'aplicació literal de 03-04 i de «ningú no és owner de prod».

Protecció de branques i CODEOWNERS:

Sobre main: prohibit el push directe, una aprovació mínima (dues per a entornos/prod/), CI en verd obligatòria, aprovacions que caduquen en haver-hi canvis nous, historial lineal, sense excepcions per a administradors i escaneig de secrets.

El procediment d'emergència, que és la part de l'exercici que més gent resol malament.

La resposta ingènua és «que la Marta tingui permisos permanents d'emergència». És dolenta: un permís permanent s'acaba usant fora de les emergències i erosiona tota la resta. La resposta correcta té quatre elements:

1. Accés d'emergència amb impersonació registrada. La Marta pertany a un grup gcp-emergencia@ que pot impersonar sa-tf-apply-prod sense passar pel pipeline. No és un permís ocult: és un camí documentat, auditat i amb nom.

2. El plan no se salta ni en una emergència. És el primer que la gent proposa eliminar per pressa, i és exactament al revés: a les 3 de la matinada, amb son i amb pressió, és quan més falta fa veure què es destruirà. Costa vint segons i evita convertir un incident en dos.

3. Alerta automàtica de l'ús de l'accés d'emergència. Amb el sortidor a Pub/Sub de 06-06, qualsevol impersonació de sa-tf-apply-prod fora del pipeline publica un missatge que arriba al canal de seguretat en el moment. No per impedir-ho, sinó perquè tothom sàpiga que va passar.

4. Regularització obligatòria en 24 hores. El canvi d'emergència es va fer amb el codi de main, així que l'estat i el codi coincideixen només si el canvi es va fer editant el codi. Si es va fer amb gcloud a mà, hi ha deriva. En tots dos casos, en les 24 hores següents cal obrir un pull request que documenti el canvi i demostri amb un plan buit que codi i realitat coincideixen de nou. Sense aquest pas, la primera emergència és el principi del retorn al caos, perquè a partir d'aquí ningú no confia que el codi sigui la veritat.

I la reflexió que tanca l'exercici. Un procediment d'emergència ben dissenyat no elimina les proteccions: les substitueix per traçabilitat. En condicions normals, la protecció és preventiva —revisió, aprovació, permisos acotats—. En una emergència, la protecció és detectiva —alerta immediata, registre d'auditoria, regularització obligatòria—. El que no ha d'existir mai és un camí sense cap de les dues, perquè aquest camí es converteix en l'habitual.

AlpinaShop té la seva infraestructura escrita, versionada, revisable i reproduïble. La pregunta que obria 06-05 —quant es triga a reconstruir l'entorn— ja té resposta: uns vint minuts i un terraform apply.

Saps per què Terraform va guanyar: multiproveïdor, ecosistema de mòduls, maduresa, comunitat, i el reconeixement definitiu que Infrastructure Manager és Terraform gestionat per Google. Amb la nota honesta sobre la llicència i OpenTofu.

Domines els conceptes: proveïdor amb la seva versió fixada perquè no fer-ho és deixar que una actualització decideixi per tu; recurs amb el seu nom local diferent del nom real; font de dades que només llegeix; variable amb validation; sortida amb sensitive, sabent que amaga però no xifra; i dependències implícites que neixen de les referències, amb depends_on com a últim recurs.

Entens l'estat de veritat: què conté —incloses contrasenyes en clar—, per què no va mai a Git, i les quatre regles que se'n deriven. Saps muntar el backend a Cloud Storage amb versionatge, bloqueig automàtic i prefixos que separen estats per limitar el radi de dany. I saps que .terraform.lock.hcl sí que va a Git.

Manejes el flux init → validate → plan → apply, amb el -out=fitxer que garanteix que s'aplica exactament el revisat. I sobretot saps llegir un pla: +, ~, - i el -/+ que ha d'aturar-te sempre, amb la taula de en quins recursos un reemplaçament és acceptable i en quins significa perdre dades.

Tens el codi real d'AlpinaShop en HCL —la VPC, les subxarxes amb private_ip_google_access, les regles de tallafoc amb els rangs de les sondes de Google explicats en un comentari, el bucket amb el seu cicle de vida i les seves quatre etiquetes— i amb això el coneixement que vivia al cap de la Marta ha passat al repositori. Saps parametritzar amb variables i tfvars perquè alpinashop-dev i alpinashop-prod comparteixin codi, i per què AlpinaShop tria carpetes per entorn davant de workspaces: perquè l'única barrera d'un workspace és recordar-se de seleccionar-lo.

Saps escriure un mòdul amb les seves tres regles —una responsabilitat, parametritzar el que varia i fixar el que és política, exposar les sortides necessàries— i quan consumir mòduls del registre públic, amb la regla que com més complex és el recurs més compensa, i els dos advertiments: fixa la versió, i un mòdul de tercers és codi amb permisos sobre la teva infraestructura.

Saps importar el que ja existeix amb blocs import declaratius i -generate-config-out, de tres en tres, verificant el pla buit, començant pel que és inofensiu i deixant Cloud SQL per al final. Tens Terraform al pipeline: plan automàtic a cada pull request publicat com a comentari —el que canvia la cultura de l'equip, perquè el revisor veu l'efecte sense executar res—, apply només després d'aprovació i aplicant el pla ja revisat, i sense una sola clau JSON en tot el flux.

Saps què no ha de gestionar Terraform —valors de secrets, dades, objectes efímers— amb la regla que ho resumeix: gestiona la forma, no el contingut, i la pregunta que resol els dubtes: això canvia sol, o perquè algú ho decideix? I tens les cinc capes de protecció contra l'esborrat accidental, amb prevent_destroy i deletion_protection com les dues primeres i la revisió humana com la que de veritat importa.

Finalment, coneixes Infrastructure Manager com a forma gestionada d'executar-lo i el mapa d'alternatives —Pulumi, Config Connector, Crossplane, CDKTF— amb l'observació que la limitació d'HCL és en part una virtut, perquè obliga que la infraestructura sigui llegible.

I aquí acaba el mòdul 6. Mira què ha canviat.

En començar, AlpinaShop tenia una aplicació que es desplegava des d'un portàtil amb l'etiqueta latest, uns manifests a Drive, una funció pendent des del mòdul 5, cap manera de saber si la botiga funcionava tret d'esperar el correu d'un client, i una infraestructura que existia només a l'historial d'un terminal.

Ara hi ha lliurament automatitzat: el codi a GitHub amb revisió obligatòria, Cloud Build construint, provant i publicant imatges etiquetades amb el commit, promoció a producció amb aprovació, i el pipeline d'ML per fi en nivell 2 de maduresa. Hi ha peces per esdeveniments que reaccionen soles, amb idempotència, reintents i dead letter. Hi ha observabilitat completa: mètriques, taulers, alertes que avisen en cinc minuts, comprovacions des de quatre continents, registres estructurats, traces distribuïdes i un recorregut provat que va de l'alerta a la línia de codi en disset minuts. I hi ha infraestructura com a codi: versionada, revisada en pull requests i reproduïble.

El sistema ja no depèn que dues persones es recordin d'executar les coses.

El que queda són les decisions que es van anar ajornant, i ara hi ha base per prendre-les. El catàleg continua a GKE, tot i que DA-001 va decidir fa temps que el seu lloc és Cloud Run —i ara que hi ha pipeline, observabilitat i infraestructura com a codi, aquest moviment és per fi viable—. Hi ha un magatzem físic amb sistemes propis que algú haurà d'integrar. Les xarxes es van quedar en allò bàsic i hi ha converses pendents sobre VPC compartida i connectivitat híbrida. La seguretat es va construir peça a peça i mai no es va revisar en conjunt. La factura ha crescut amb cada mòdul i ningú no l'ha mirat amb deteniment. S'han muntat alertes, però no s'ha definit què significa «funcionar bé»: no hi ha SLO ni pressupostos d'error. I l'organització ja té tres projectes, quatre repositoris, desenes de comptes de servei i cap política que governi el conjunt.

Al mòdul 7, temes avançats, es resolen tots: Anthos per a l'híbrid i el multinúvol, Cloud Run per portar el catàleg on sempre hauria d'haver estat, xarxes avançades amb VPC compartida, aparellament i connectivitat híbrida, seguretat revisada de dalt a baix, gestió de costos perquè la factura deixi de ser una sorpresa mensual, fiabilitat amb SLO i pressupostos d'error que converteixin les alertes de 06-04 en objectius mesurables, i govern a escala amb polítiques d'organització i auditoria.

AlpinaShop ja construeix, desplega i s'observa sola. Ara toca fer-la robusta, econòmica i governable.