Després del blog serverless (subcapítol 33.1), pugem un esglaó de complexitat amb el segon projecte: una API REST amb contenidors. Mentre el blog era 100 % serverless, aquest projecte et porta al món dels contenidors (Capítol 17) i les bases de dades relacionals (Capítol 8), combinant ECS Fargate, RDS i un balancejador de càrrega (ALB). És un patró molt comú en el món real per a aplicacions de backend, i consolida una part diferent (i molt demandada) dels teus coneixements.

Què és una API REST (un repàs ràpid)

Una API REST és una «porta d’entrada» a la qual altres aplicacions (una web, una app mòbil...) fan peticions per obtenir o modificar dades. Per exemple, una API d’una botiga amb la qual l’app mòbil consulta productes, crea comandes, etc. És el «cervell» de backend que serveix dades i lògica als clients.

   App mòbil / web  ──petició──►  API REST  ──►  processa i respon amb dades
   "dóna’m els productes"            (el backend)    [llista de productes]

Aquest projecte construeix aquesta API, però usant contenidors per executar-la i una base de dades relacional per a les dades.

Les peces i com encaixen

El projecte combina tres serveis principals, cadascun amb el seu paper:

ECS Fargate: executar l’API en contenidors (sense servidors)

Recorda els contenidors (Capítol 17): empaqueten la teva aplicació amb tot el que necessita per funcionar igual a qualsevol lloc. ECS amb Fargate (subcapítol 17.3) executa aquests contenidors sense que hagis de gestionar els servidors que hi ha a sota (Fargate és l’opció serverless per a contenidors). Aquí, la teva API va dins d’un contenidor que ECS Fargate executa i escala.

ECS Fargate → executa la teva API (en un contenidor), sense gestionar servidors
   → escala sol segons la demanda

💡 Aquest projecte et fa practicar el flux de contenidors que vam veure: empaquetar l’app en una imatge Docker (subcapítol 17.1), guardar-la a ECR (subcapítol 17.2) i executar-la a ECS Fargate (subcapítol 17.3).

RDS: la base de dades relacional

RDS (Capítol 8) proporciona la base de dades relacional (gestionada per AWS) on l’API guarda i consulta les dades (productes, comandes, usuaris...). A diferència del blog (que usava DynamoDB, NoSQL), aquí fem servir una base de dades relacional (SQL), adequada quan les dades tenen relacions estructurades. RDS la gestiona per tu (còpies, pegats...).

RDS → la base de dades relacional on l’API guarda/consulta dades

ALB: el balancejador de càrrega (repartir el trànsit)

L’Application Load Balancer (ALB) (subcapítol 13.1) reparteix les peticions entre els contenidors de la teva API. Si tens diversos contenidors executant l’API (per aguantar més càrrega), l’ALB distribueix el trànsit entre ells de manera equilibrada, i comprova la seva salut (recorda els health checks, subcapítol 13.2). És la «porta d’entrada» que rep els clients i els dirigeix.

Clients → ALB (reparteix el trànsit) → contenidors de l’API (diversos)

L’arquitectura completa

Així encaixen les peces:

   Clients (app, web)
        │
        ▼
   ALB (balancejador: reparteix i comprova salut)
        │
        ▼
   ECS Fargate (diversos contenidors amb la teva API, escalen sols)
        │
        ▼
   RDS (base de dades relacional: les dades)

Els clients arriben a l’ALB, que reparteix les seves peticions entre els contenidors de l’API (a ECS Fargate), i aquests llegeixen/escriuen a la base de dades RDS. Si arriba més trànsit, ECS Fargate afegeix més contenidors i l’ALB els inclou en el repartiment: escala automàticament.

Conceptes clau que consolides

Aquest projecte aferma una part important (i molt emprable) del llibre, diferent de la del blog serverless:

   Conceptes del llibre que consolides:
   - Contenidors: Docker, ECR, ECS Fargate (Cap. 17)
   - Bases de dades relacionals amb RDS (Cap. 8)
   - Balanceig de càrrega amb ALB (Cap. 13)
   - Xarxes: posar la BD en subxarxes privades, l’API protegida... (Cap. 6)
   - Seguretat: Security Groups, secrets de la BD (Caps. 6, 23)
   - Tot amb Terraform! (Parts II-V)

⚠️ Bones pràctiques a aplicar (que has après al llibre):

  • Posa la base de dades en subxarxes privades (Capítol 6), no accessible des d’internet directament: només l’API ha de poder parlar amb ella.
  • Desa la contrasenya de la base de dades a Secrets Manager (subcapítol 23.6), mai al codi ni a .tfvars (recorda el subcapítol 19.4).
  • Fes servir Security Groups (Capítol 6) perquè només l’ALB parli amb els contenidors, i només els contenidors amb la base de dades.

Exemple del món real: algú vol consolidar els seus coneixements de contenidors i bases de dades relacionals (diferents dels del blog serverless). Construeix una API REST per a una botiga: empaqueta l’aplicació en una imatge Docker, la desa a ECR, l’executa a ECS Fargate (diversos contenidors), posa un ALB davant per repartir el trànsit, i fa servir RDS per a les dades (productes, comandes), amb la base de dades en subxarxes privades i la contrasenya a Secrets Manager. Tot ho desplega amb Terraform. En construir-ho, s’enfronta a reptes reals —com connectar els contenidors amb la base de dades de manera segura, com configurar l’ALB i els health checks— i en resoldre’ls interioritza com funciona una arquitectura de contenidors de veritat. Acaba amb una API real, escalable i segura, i un domini sòlid d’un patró molt demandat al mercat.

El que has de recordar

  • El projecte d’API REST amb contenidors puja un esglaó sobre el blog serverless, portant-te al món dels contenidors (Cap. 17) i les bases de dades relacionals (Cap. 8). Una API REST és la «porta d’entrada» de backend a la qual altres apps fan peticions.
  • Combina tres peces: ECS Fargate (executa l’API en contenidors sense gestionar servidors, escala sola, Cap. 17), RDS (la base de dades relacional, Cap. 8) i ALB (reparteix el trànsit entre els contenidors, Cap. 13).
  • Arquitectura: clients → ALB (reparteix) → contenidors a ECS Fargate → RDS (dades). Escala automàticament afegint contenidors.
  • Consolida: contenidors (Docker/ECR/ECS, Cap. 17), RDS (Cap. 8), balanceig (Cap. 13), xarxes i seguretat (Caps. 6, 23), tot amb Terraform.
  • ⚠️ Aplica bones pràctiques: base de dades en subxarxes privades, contrasenya a Secrets Manager (mai al codi), i Security Groups restrictius.

Al següent subcapítol abordarem un projecte del món de les dades: una plataforma de dades amb Glue, Athena i Redshift.

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