Inicio / Lab OpenTofu · GCP / Pasos a seguir

Pasos a seguir

Lab OpenTofu sobre Google Cloud · 2026.

Guía operativa: del primer tofu init al tofu destroy final. Antes de arrancar revisá Prerequisitos — si todos los checks pasan, podés empezar con la Fase 0.

Fase 0 — Preparación inicial

Configuración que se hace una sola vez por máquina y por proyecto GCP.

1. Clonar el repositorio

git clone <url-del-repo>
cd labs/tofu-gcp

2. Autenticarse en GCP

Dos logins distintos: el de gcloud (uso interactivo) y el de Application Default Credentials (lo que usa OpenTofu).

gcloud auth login
gcloud config set project <TU_PROJECT_ID>

gcloud auth application-default login
gcloud auth application-default set-quota-project <TU_PROJECT_ID>

3. Verificar identidad y proyecto

gcloud auth list
gcloud config get-value project
ls ~/.config/gcloud/application_default_credentials.json

4. Bootstrap: APIs + bucket de estado

El lab 00-bootstrap habilita las APIs necesarias y crea el bucket GCS para guardar el estado remoto:

cd 00-bootstrap
cp terraform.tfvars.example terraform.tfvars
# Editar terraform.tfvars:
#   project_id        = "tu-project-id"
#   region            = "us-central1"
#   state_bucket_name = "tfstate-sd2026-<tu-id-unico>"   # nombre global, único

tofu init
tofu plan
tofu apply

⚠ Nombres globales. El nombre del bucket GCS es global en todo Google Cloud. Si el apply falla con bucket already exists, cambiá state_bucket_name a algo más único (ej. agregá tu legajo o iniciales).

Fase 1 — Ejecutar los labs en orden

Cada lab es independiente. Patrón común: init → plan → apply → probar → destroy.

Patrón estándar por lab

cd 0X-nombre-lab
cp terraform.tfvars.example terraform.tfvars
# editar project_id (y otras vars si aplica)

tofu init       # descarga providers
tofu plan       # muestra qué va a crear
tofu apply      # crea los recursos (confirmar con "yes")

# ... probar el recurso (SSH a la VM, curl al LB, kubectl, etc.) ...

tofu destroy    # ¡IMPORTANTE! limpia todo

Fase 2 — Comandos de verificación

Cómo probar lo que cada lab desplegó.

Para VMs (labs 01–04)

# Listar VMs creadas
gcloud compute instances list

# SSH a una VM pública
gcloud compute ssh <nombre-vm> --zone=<zona>

# Probar nginx (lab 02)
curl http://<EXTERNAL_IP>

# IAP a VM privada (lab 03)
gcloud compute ssh <nombre-vm> --tunnel-through-iap --zone=<zona>

Para el Load Balancer (lab 04)

# Ver IP del LB (sale en outputs)
tofu output lb_ip

# Curl repetido para ver round-robin entre instancias
for i in {1..10}; do curl http://<LB_IP>; done

Para GKE (labs 05–06)

# Conectarse al cluster
gcloud container clusters get-credentials <cluster-name> --region=us-central1

kubectl get nodes
kubectl get pods -A

# Lab 06: ver la app desplegada
kubectl get svc
kubectl get deploy

Fase 3 — Limpieza obligatoria

No olvidar el tofu destroy. En GCP varios recursos facturan por hora aunque no haya tráfico.

⚠ Recursos que facturan continuamente:

• GKE Autopilot — el control plane factura aunque no haya pods.
• Load Balancer HTTP — la forwarding rule factura por hora.
• Cloud NAT — gateway-hour + procesamiento de datos.
• VMs e2-micro entran en free tier, pero solo una a la vez.

# Destruir un lab puntual
cd 0X-nombre-lab
tofu destroy

# Cuando termines TODO el curso, también el bootstrap:
cd 00-bootstrap
tofu destroy   # borra el bucket de estado (force_destroy = true)

Verificación de cuenta limpia

Que no quede ningún recurso vivo después de destruir:

gcloud compute instances list
gcloud compute forwarding-rules list
gcloud compute routers list
gcloud container clusters list
gcloud storage buckets list

# Salida esperada: vacío o "Listed 0 items."

Errores comunes durante el flujo

Activar backend remoto (opcional)

Cada lab tiene un bloque backend "gcs" comentado. Una vez que 00-bootstrap creó el bucket, podés activarlo en cada lab para guardar el estado remoto:

terraform {
  backend "gcs" {
    bucket = "tfstate-sd2026-<tu-id>"
    prefix = "01-vm-basica"
  }
}

Luego correr tofu init -migrate-state para subir el estado local al bucket.