Terraform per si sol no sap res d’AWS, ni d’Azure, ni de cap núvol. Necessita un «traductor» que sàpiga parlar amb cada plataforma. Aquest traductor és el provider. En aquest subcapítol entendràs què és un provider, com Terraform es comunica amb AWS i com es configura. És la peça que connecta el teu codi amb el núvol real.

Un provider és un complement (plugin) que ensenya a Terraform a comunicar-se amb una plataforma concreta. El provider d’AWS sap com crear, llegir, modificar i esborrar recursos d’AWS a través de la seva API.

Analogia: Terraform és com una persona que vol donar instruccions a molts països diferents. El provider és l’intèrpret/traductor que coneix l’idioma de cada país. El provider d’AWS «parla AWS»; el d’Azure «parla Azure». Tu dones les instruccions en HCL i el provider les tradueix a l’idioma del núvol corresponent.

Això és el que fa que Terraform sigui multi-núvol (recorda el Capítol 9): el mateix Terraform fa servir diferents providers per parlar amb diferents plataformes. Hi ha centenars de providers: AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare, i molts més.

El flux, simplificat, és aquest:

1. Tu escrius el que vols en HCL (resource "aws_instance"...).
2. Terraform processa el teu codi.
3. El provider d’AWS tradueix això en trucades a l’API d’AWS (les mateixes que fa servir la consola web per darrere).
4. AWS crea/modifica/esborra els recursos reals.

Cada recurs que comença per aws_ (com aws_instance, aws_s3_bucket) el gestiona el provider d’AWS.

Al teu codi declares quin provider vols fer servir i el configures. Això sol anar en un bloc terraform (per fixar la versió) i un bloc provider:

Desglossem:

• El bloc terraform { required_providers { ... } } declara que necessites el provider d’AWS, d’on descarregar-lo (hashicorp/aws) i quina versió (~> 5.0 vol dir «versió 5.x»).
• El bloc provider "aws" { ... } el configura: aquí indiques, per exemple, la regió on treballar (recorda el Capítol 3).

Per què fixar la versió importa: els providers s’actualitzen i a vegades canvien el seu comportament. Fixar la versió (~> 5.0) garanteix que el teu codi segueixi funcionant igual encara que surtin versions noves. És una bona pràctica per evitar sorpreses.

Perquè AWS li permeti crear recursos, Terraform necessita credencials (recorda IAM, Capítol 7). Però, molt important, les credencials no s’escriuen al codi. Hi ha formes segures de proporcionar-les:

⚠️ Regla de seguretat crítica: MAI escriguis claus d’accés dins del teu codi .tf. Si ho puges a Git, estaries filtrant les teves credencials (recorda els desastres del Capítol 7). En el seu lloc, fes servir l’AWS CLI, variables d’entorn o, el millor, rols d’IAM (subcapítol 7.4). Terraform les recull automàticament de l’entorn, sense que apareguin al codi.

Abans de poder fer servir un provider, cal descarregar-lo. Això ho fa la comanda terraform init, que és la primera comanda que executes en qualsevol projecte de Terraform.

init llegeix la teva configuració, descarrega els providers necessaris i deixa tot a punt per a plan i apply (recorda el cicle del subcapítol 9.4). L’executes:

• La primera vegada que comences un projecte.
• Cada cop que afegeixes un provider nou o canvies la seva versió.
• (També configura el backend de l’estat, que veurem al subcapítol 11.3.)

Així, el cicle complet de Terraform és en realitat: init → plan → apply → ... → destroy.

Per a casos avançats, pots fer servir diversos providers alhora o el mateix provider amb configuracions diferents. Per exemple, desplegar a dues regions d’AWS fent servir dues configuracions del provider AWS amb alias:

Això és útil per a arquitectures multi-regió (Capítol 26) o multi-compte (Capítol 30). No et preocupis per això ara; n’hi ha prou amb saber que és possible.

• Un provider és el «traductor» que permet a Terraform parlar amb una plataforma. El provider d’AWS tradueix el teu HCL en trucades a l’API d’AWS.
• Gràcies als providers, Terraform és multi-núvol (n’hi ha centenars: AWS, Azure, GCP, Kubernetes…).
• Es declara amb required_providers (fixant la versió, bona pràctica) i es configura amb el bloc provider (regió, etc.).
• Les credencials MAI van al codi: fes servir AWS CLI, variables d’entorn o, millor, rols d’IAM.
• terraform init descarrega els providers i és la primera comanda que executes en un projecte.

Al següent subcapítol veurem el concepte més característic (i a vegades confús) de Terraform: el fitxer d’estat (terraform.tfstate) i per què és tan important.