En el subcapítol anterior vam muntar un pipeline bàsic amb GitHub Actions. Funciona molt bé, però existeixen eines especialitzades en el flux de Terraform que ho fan encara més còmode i segur. La més coneguda és Atlantis. En aquest subcapítol entendràs què aporta i per què molts equips l’adopten per portar el GitOps de la seva infraestructura a un altre nivell.
Recordatori: GitOps
Vam veure el concepte de GitOps al subcapítol 12.5: gestionar la infraestructura a través de Git i Pull Requests, de manera que tot canvi es proposa, es revisa i s’aplica mitjançant el flux de Git. Atlantis és una eina dissenyada específicament per fer GitOps amb Terraform de la manera més fluida possible.
Què és Atlantis
Atlantis és una eina open source que automatitza Terraform directament des dels Pull Requests, mitjançant comentaris. En comptes que el pipeline executi el plan i l’apply «pel seu compte», amb Atlantis tu i el teu equip controleu aquestes accions escrivint comentaris al mateix PR.
Al Pull Request, escrius un comentari: "atlantis plan" → Atlantis executa el plan i el publica com a resposta "atlantis apply" → Atlantis aplica els canvis (després d’aprovació)
Analogia: Atlantis és com un assistent que viu dins dels teus Pull Requests. Li dones ordres per comentaris («planifica això», «aplica-ho») i ell les executa i et respon allà mateix, deixant tot registrat a la conversa del PR. És com tenir Terraform «ficat» a la discussió del canvi.
Com funciona el flux amb Atlantis
El flux típic és molt natural i conversacional:
1. Algú obre un Pull Request amb canvis a Terraform
│
▼
2. Atlantis detecta el PR i executa "plan" AUTOMÀTICAMENT
→ publica el plan com a comentari al PR
│
▼
3. L’equip REVISA el plan al PR (subcap. 12.5)
│
▼
4. Un company APROVA el PR
│
▼
5. Algú comenta "atlantis apply"
→ Atlantis aplica els canvis i publica el resultat
│
▼
6. El PR es fusionaTot passa dins del Pull Request: el plan, la revisió, l’aprovació i l’apply queden registrats en un sol lloc, com una conversa. És traçabilitat total i molt fàcil de seguir.
Què aporta Atlantis davant d’un pipeline genèric
Podries fer quelcom semblant amb GitHub Actions (subcapítol 22.1), llavors quins avantatges té Atlantis?
- Dissenyat específicament per a Terraform
Atlantis «entén» Terraform: gestiona el plan i l’apply, l’estat, els locks, els workspaces... de manera nativa. No has de construir tota aquesta lògica a mà en un pipeline genèric.
- El plan, sempre visible al PR
Atlantis publica automàticament el plan com a comentari, integrant-lo perfectament a la revisió. La «xarxa de seguretat» de revisar el plan (subcapítol 12.5) queda incorporada de sèrie.
- Control mitjançant comentaris
Tu decideixes quan s’aplica, escrivint atlantis apply només quan tot està revisat i aprovat. Dona un control explícit i deliberat sobre el moment del desplegament.
- Locking a nivell de Pull Request
Atlantis afegeix un bloqueig intel·ligent: si un PR està «treballant» sobre certa infraestructura, bloqueja que un altre PR toqui el mateix alhora. Això complementa el state locking (subcapítol 20.2) evitant conflictes entre canvis simultanis, ja des de la fase de revisió.
Una consideració: cal allotjar-lo
Una diferència pràctica important: Atlantis és una aplicació que has d’executar i mantenir tu (normalment en un servidor o contenidor dins de la teva infraestructura). No és un servei que «simplement fas servir» com GitHub Actions. Això dona més control i privacitat (el teu codi i credencials no surten del teu entorn), però també suposa responsabilitat de manteniment.
GitHub Actions: ho gestiona GitHub (no mantens res) Atlantis: l’allotges i mantens tu (més control, més responsabilitat)
Quan fer servir Atlantis?
| Situació | Recomanació |
|---|---|
| Començant, equip petit | Un pipeline simple (GitHub Actions) és suficient |
| Equip que vol GitOps fluid per a Terraform | Atlantis encaixa molt bé |
| Molts repos/equips usant Terraform | Atlantis centralitza i ordena el flux |
| No vols mantenir una eina extra | Pipeline genèric o Terraform Cloud (subcap. 22.3) |
Consell: com amb altres eines (recorda Kubernetes al Capítol 17, o Terragrunt al 19.3), no adoptis Atlantis només perquè sigui popular. Comença amb un pipeline simple. Si el teu equip creix i el flux GitOps amb Terraform esdevé central en el teu dia a dia, Atlantis aporta molt. Tria per necessitat real.
El que has de recordar
- Atlantis és una eina open source que automatitza Terraform directament des dels Pull Requests, controlada mitjançant comentaris (
atlantis plan,atlantis apply). Com un «assistent dins del PR». - El flux és conversacional i queda tot registrat al PR: Atlantis executa el plan automàticament, l’equip el revisa, s’aprova, i algú comenta
atlantis applyper desplegar. - Aporta davant d’un pipeline genèric: dissenyat per a Terraform, el plan sempre visible al PR, control per comentaris i locking a nivell de PR.
- A diferència de GitHub Actions, tu allotges i mantens Atlantis (més control i privacitat, però més responsabilitat).
- No l’adoptis per moda: comença simple i passa’t a Atlantis si el GitOps amb Terraform esdevé central per al teu equip.
Al següent subcapítol veurem l’opció «gestionada» que evita mantenir eines: Terraform Cloud / HCP Terraform, el servei de la mateixa HashiCorp.
Cloud, AWS & Terraform — De zero a expert
Capítol 1 · Què és el cloud computing
- 1.1 El model client-servidor tradicional
- 1.2 Problemes que venia a resoldre el núvol
- 1.3 On-premise vs cloud vs híbrid
- 1.4 Els tres models de servei: IaaS, PaaS, SaaS
- 1.5 Els cinc pilars del cloud (segons NIST)
- 1.6 Avantatges reals: elasticitat, pagament per ús, disponibilitat global
Capítol 2 · El mercat cloud i els grans proveïdors
- 2.1 AWS, Azure i GCP: diferències i quotes de mercat
- 2.2 Per què aprendre AWS primer
- 2.3 Conceptes que són universals entre proveïdors
Capítol 3 · Regions, zones de disponibilitat i edge
- 3.1 Què és una regió AWS i com triar-la
- 3.2 Availability Zones: alta disponibilitat des del disseny
- 3.3 Edge locations i CloudFront
- 3.4 Latència, resiliència i sobirania de dades
Capítol 4 · Càlcul: EC2
- 4.1 Instàncies: tipus, famílies i quan triar cadascuna
- 4.2 AMIs, key pairs i Security Groups
- 4.3 Cicle de vida d'una instància
- 4.4 Elastic IPs i Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítol 5 · Emmagatzematge: S3
- 5.1 Buckets, objectes i claus
- 5.2 Classes d'emmagatzematge (Standard, IA, Glacier…)
- 5.3 Versionat i cicle de vida d'objectes
- 5.4 Polítiques de bucket i ACLs
- 5.5 Hosting de llocs web estàtics
Capítol 6 · Xarxes: VPC
- 6.1 Què és una VPC i per què la necessites
- 6.2 Subxarxes públiques i privades
- 6.3 Internet Gateway i NAT Gateway
- 6.4 Route Tables i Network ACLs
- 6.5 VPC Peering i endpoints
Capítol 7 · Identitat i accés: IAM
- 7.1 Usuaris, grups, rols i polítiques
- 7.2 El principi de mínim privilegi
- 7.3 Polítiques basades en identitat vs en recurs
- 7.4 MFA i credencials temporals (STS)
- 7.5 Bones pràctiques de seguretat IAM
Capítol 8 · Bases de dades gestionades
- 8.1 RDS: motors, Multi-AZ i rèpliques de lectura
- 8.2 Aurora i els seus avantatges sobre RDS vanilla
- 8.3 DynamoDB: model clau-valor / documents
- 8.4 ElastiCache per a memòria cau en memòria
- 8.5 Quan utilitzar cada tipus de base de dades
Capítol 9 · Per què Infraestructura com a Codi
- 9.1 Problemes del provisionament manual
- 9.2 IaC declaratiu vs imperatiu
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El cicle plan → apply → destroy
Capítol 10 · HCL: el llenguatge de Terraform
- 10.1 Blocs resource, variable, output, locals
- 10.2 Tipus de dades: string, number, bool, list, map, object
- 10.3 Expressions, referències i funcions built-in
- 10.4 Condicionals i bucles (count, for_each, for)
Capítol 11 · Providers i estat
- 11.1 Com funciona el provider d'AWS
- 11.2 El fitxer terraform.tfstate i la seva importància
- 11.3 State local vs state remot (S3 + DynamoDB)
- 11.4 Comandes essencials: init, plan, apply, destroy, fmt, validate
Capítol 12 · La teva primera infraestructura real amb Terraform
- 12.1 Crear una VPC amb subxarxes des de zero
- 12.2 Posar en marxa una instància EC2 pública
- 12.3 Associar un Security Group i una Elastic IP
- 12.4 Outputs i referències entre recursos
- 12.5 Flux de treball en equip: PR review de plans
Capítol 13 · Balanceig de càrrega i autoescalat
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners i regles
- 13.3 Auto Scaling Groups: polítiques i mètriques
- 13.4 Warm pools i lifecycle hooks
Capítol 14 · Serverless amb Lambda
- 14.1 El model d'execució de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestió de dependències i capes (Layers)
- 14.4 Cold starts i estratègies per reduir-los
- 14.5 Límits i antipatrones
Capítol 15 · Missatgeria i esdeveniments
- 15.1 SQS: cues estàndard vs FIFO, DLQ
- 15.2 SNS: topics, subscripcions, fan-out
- 15.3 EventBridge: event buses i regles
- 15.4 Patrons: pub/sub, desacoblament, saga
Capítol 16 · Lliurament de contingut i DNS
- 16.1 Route 53: tipus de registres i routing policies
- 16.2 CloudFront: distribucions, memòries cau i origins
- 16.3 ACM: certificats SSL/TLS gratuïts
- 16.4 WAF integrat amb CloudFront
Capítol 17 · Contenidors a AWS
- 17.1 Docker: repàs exprés de conceptes clau
- 17.2 ECR: registre privat d'imatges
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: quan Kubernetes i quan no
Capítol 18 · Mòduls: reutilització i composició
- 18.1 Anatomia d'un mòdul Terraform
- 18.2 Variables d'entrada, outputs i dependències
- 18.3 Mòduls locals vs mòduls del Terraform Registry
- 18.4 Versionat de mòduls amb Git tags
- 18.5 Disseny de mòduls genèrics vs específics de domini
Capítol 19 · Workspaces i gestió d'entorns
- 19.1 Workspaces de Terraform: casos d'ús i limitacions
- 19.2 Estratègia de directoris per entorn (dev/stg/prod)
- 19.3 Terragrunt: DRY per a configuracions d'entorn
- 19.4 Variables d'entorn i fitxers .tfvars
Capítol 20 · Backends remots i locking
- 20.1 Configurar S3 + DynamoDB com a backend
- 20.2 State locking: evitar corrupció en equip
- 20.3 Migració d'estat entre backends
- 20.4 terraform import: portar recursos existents a l'estat
Capítol 21 · Testing d'infraestructura
- 21.1 Terraform validate i fmt en CI
- 21.2 Checkov i tfsec: anàlisi de seguretat estàtica
- 21.3 Terratest: tests d'integració en Go
- 21.4 Contract testing entre mòduls
Capítol 22 · Terraform en CI/CD
- 22.1 Pipeline bàsic: lint → plan → apply a GitHub Actions
- 22.2 Atlantis: GitOps per a Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection i reconciliació automàtica
Capítol 23 · Seguretat en profunditat
- 23.1 AWS Organizations i Service Control Policies
- 23.2 AWS Config: compliment continu
- 23.3 GuardDuty: detecció d'amenaces
- 23.4 Security Hub: visió centralitzada
- 23.5 KMS: gestió de claus i rotació
- 23.6 Secrets Manager vs Parameter Store
Capítol 24 · Observabilitat: logs, mètriques i traces
- 24.1 CloudWatch Logs, mètriques i alarmes
- 24.2 CloudWatch Dashboards i Contributor Insights
- 24.3 X-Ray: traçat distribuït
- 24.4 OpenTelemetry a AWS
- 24.5 Managed Grafana i Managed Prometheus
Capítol 25 · Optimització de costos
- 25.1 AWS Cost Explorer i pressupostos amb alertes
- 25.2 Trusted Advisor i Compute Optimizer
- 25.3 Rightsizing: com detectar sobredimensionament
- 25.4 Savings Plans vs Reserved Instances: decisió estratègica
- 25.5 FinOps: cultura i processos per controlar la despesa
Capítol 26 · Alta disponibilitat i disaster recovery
- 26.1 RTO i RPO: definir els objectius
- 26.2 Estratègies: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks i failover automàtic
- 26.4 AWS Backup: política centralitzada de còpies
Capítol 27 · Well-Architected Framework d'AWS
- 27.1 Els sis pilars: excel·lència operacional, seguretat, fiabilitat, eficiència de rendiment, optimització de costos, sostenibilitat
- 27.2 Well-Architected Tool: revisions formals
- 27.3 Com aplicar el framework en decisions de disseny
Capítol 28 · Arquitectures serverless a escala
- 28.1 Event-driven architecture amb Lambda + EventBridge
- 28.2 Saga pattern per a transaccions distribuïdes
- 28.3 Step Functions: orquestració de workflows complexos
- 28.4 Lambda@Edge i CloudFront Functions
Capítol 29 · Plataformes de dades a AWS
- 29.1 Data Lake amb S3, Glue i Athena
- 29.2 Kinesis Data Streams i Firehose per a streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: govern del dada
Capítol 30 · Multi-compte i landing zones
- 30.1 Per què separar workloads en comptes diferents
- 30.2 AWS Control Tower i Account Factory
- 30.3 Gestió centralitzada de logs i seguretat
- 30.4 Terraform a escala multi-compte amb mòduls compartits
Capítol 31 · Platform Engineering i Internal Developer Platform
- 31.1 Golden paths i abstraccions sobre Terraform
- 31.2 Service Catalog d'AWS
- 31.3 Backstage com a portal de desenvolupadors
- 31.4 Mòduls Terraform com a producte intern
Capítol 32 · Certificacions AWS rellevants
- 32.1 Cloud Practitioner: val la pena?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Capítol 33 · Projectes per consolidar el que s'ha après
- 33.1 Projecte 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Projecte 2: API REST amb ECS Fargate + RDS + ALB
- 33.3 Projecte 3: plataforma de dades amb Glue + Athena + Redshift
- 33.4 Projecte 4: landing zone multi-compte amb Terraform i Control Tower
