Salta el contingut

Comprendre l'Arquitectura de Terraform

2. Comprendre l'Arquitectura de Terraform

Per utilitzar Terraform efectivament, és fonamental entendre com funciona internament. Vegem els components clau de la seva arquitectura.

El Workflow Bàsic de Terraform

El workflow de Terraform segueix un cicle de tres passos principals que es repeteix cada vegada que vols fer canvis a la teva infraestructura:

1. Write (Escriure): Escrius o modifiques fitxers de configuració .tf que descriuen la infraestructura desitjada. Aquests fitxers utilitzen HCL (HashiCorp Configuration Language) i són on defines quins recursos vols crear, amb quines propietats, i com es relacionen entre ells.

2. Plan (Planificar): Executes terraform plan. Terraform compara l'estat actual de la teva infraestructura (emmagatzemat en el "state file") amb l'estat desitjat (definit en els teus fitxers .tf), i et mostra exactament quins canvis farà: quins recursos crearà (marcats amb un +), quins modificarà (marcats amb un ~), i quins destruirà (marcats amb un -). Aquesta és una oportunitat per revisar els canvis abans d'aplicar-los.

3. Apply (Aplicar): Si estàs satisfet amb el pla, executes terraform apply. Terraform fa els canvis reals a la infraestructura, cridant les APIs del proveïdor cloud per crear, modificar o destruir recursos segons el pla. Després d'aplicar els canvis, Terraform actualitza el state file per reflectir el nou estat de la infraestructura.

Aquest cicle és segur i predictible. El pas de "plan" t'assegura que mai t'emportaràs sorpreses: sempre saps exactament què passarà abans que passi.

State: La Memòria de Terraform

El concepte més important en Terraform és l'estat (state). El state file (per defecte anomenat terraform.tfstate) és un fitxer JSON que conté un mapatge complet de tots els recursos que Terraform ha creat, amb totes les seves propietats i metadata.

Per què és necessari el state? Perquè Terraform necessita saber què ha creat prèviament per poder fer canvis intel·ligents. Quan executes terraform plan, Terraform:

  1. Llegeix els teus fitxers .tf per saber què vols (l'estat desitjat)
  2. Llegeix el state file per saber què tens (l'estat conegut)
  3. Consulta l'API del proveïdor per verificar l'estat real
  4. Compara aquests tres estats i determina els canvis necessaris

Sense el state, Terraform no sabria si un recurs ja existeix o si necessita crear-lo. Cada vegada que executis terraform apply, intentaria crear tots els recursos de nou, el que obviament causaria errors (perquè molts recursos no permeten duplicats) o, pitjor encara, recursos òrfens.

El state també conté informació sensible: per exemple, si crees una base de dades, el state contindrà les credencials. Per això, és extremadament important protegir el state file. Mai l'has de cometre directament a Git (especialment en repositoris públics). Idealment, el state s'hauria d'emmagatzemar en un backend remot i encriptat (ho veurem més endavant).

Providers: Els Traductors de Terraform

Els providers són plugins que Terraform utilitza per interactuar amb diferents serveis. Cada proveïdor sap com parlar amb l'API d'un servei específic: AWS, Azure, Google Cloud, Kubernetes, GitHub, Cloudflare, etc.

Quan escrius codi de Terraform, primer declares quins providers necessites:

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

provider "aws" {
  region = "eu-west-1"
}

Quan executes terraform init, Terraform descarrega els providers necessaris. Cada provider ve amb:

  • Recursos: Coses que pots crear (per exemple, aws_instance per crear un servidor EC2)
  • Data Sources: Maneres de consultar informació existent (per exemple, consultar quines AMIs estan disponibles)
  • Documentació: Cada provider té documentació detallada de tots els seus recursos i opcions

HashiCorp manté els providers per als grans clouds (AWS, Azure, GCP), però la comunitat ha creat centenars de providers per a pràcticament qualsevol servei que puguis imaginar. Pots veure tots els providers disponibles al Terraform Registry: https://registry.terraform.io/browse/providers

Referència oficial: La documentació dels providers està disponible al Terraform Registry. Per exemple, el provider d'AWS es pot consultar a: https://registry.terraform.io/providers/hashicorp/aws/latest/docs

Resources: Els Blocs de Construcció

Els resources són els components individuals de la teva infraestructura. Cada recurs representa una cosa concreta que vols crear: un servidor, una xarxa, una base de dades, una regla de firewall, etc.

La sintaxi bàsica d'un recurs és:

resource "tipus_recurs" "nom_local" {
  # propietats del recurs
}

Per exemple:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "Web Server"
  }
}

Això crea un servidor EC2 a AWS. El tipus_recurs (aws_instance) indica quin tipus de recurs és i quin provider el gestiona. El nom_local (web_server) és com l'identificaràs en el teu codi de Terraform (no és el nom del recurs a AWS).

Dependencies: L'Ordre Importa

Molts recursos depenen d'altres. Per exemple, no pots crear un servidor en una xarxa si la xarxa no existeix encara. Terraform gestiona automàticament aquestes dependencies de dues maneres:

Dependencies Implícites: Terraform detecta dependencies automàticament quan un recurs referència un altre. Per exemple:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id  # Referència al VPC
  cidr_block = "10.0.1.0/24"
}

Terraform veu que aws_subnet.public referencia aws_vpc.main.id, així que automàticament sap que ha de crear el VPC abans que el subnet.

Dependencies Explícites: A vegades necessites especificar dependencies manualment:

resource "aws_instance" "app" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  depends_on = [aws_db_instance.database]
}

Això assegura que la base de dades existeix abans de crear el servidor, fins i tot si no hi ha una referència directa en el codi.

Terraform construeix un "dependency graph" complet de tots els recursos i utilitza aquest graf per determinar l'ordre òptim en què crear, modificar o destruir recursos. També pot paral·lelitzar operacions quan és segur fer-ho (per exemple, creant múltiples servidors simultàniament).

Backends: On Viu l'Estat

Per defecte, Terraform guarda el state en un fitxer local (terraform.tfstate). Però en entorns reals, això té problemes:

  • Si treballes en equip, cadascú tindria el seu propi state local, causant inconsistències
  • No hi ha bloqueig, així que dos persones podrien executar terraform apply simultàniament, corrompent l'estat
  • No hi ha backup automàtic; si perds el fitxer, has perdut el rastre de tota la teva infraestructura
  • El state conté informació sensible que no hauries de tenir en un portàtil

La solució és utilitzar un backend remot. Els backends més comuns són:

  • S3 (AWS): Guarda l'estat a un bucket S3, amb bloqueig via DynamoDB
  • Azure Storage: Per a entorns Azure
  • Google Cloud Storage: Per a entorns GCP
  • Terraform Cloud: Servei gestionat de HashiCorp que ofereix state management, execució remota, i molt més
  • Consul: Per a entorns on-premises

Configurar un backend és simple:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "eu-west-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

Amb un backend remot, múltiples persones poden treballar en la mateixa infraestructura de manera segura, l'estat està encriptat i amb backup, i hi ha bloqueig per prevenir execucions simultànies.