Lab #8 — Informe de entrega

1. Contexto

Este repositorio contiene la solución del Laboratorio #8 de Terraform en Azure. El objetivo fue construir una arquitectura reproducible usando Infrastructure as Code: definir, aprovisionar y versionar toda la infraestructura con Terraform.

El lab cubre desde el bootstrap del backend remoto hasta la validación del Load Balancer respondiendo desde dos VMs distintas, pasando por un pipeline de GitHub Actions con autenticación OIDC.

Este archivo sirve como guía representativa del repositorio. El análisis técnico completo y la reflexión extendida se encuentran en el informe de laboratorio adjunto.

---

2. Objetivos del laboratorio

• Desplegar infraestructura en Azure usando Terraform.
• Modularizar la solución en tres módulos: vnet, compute y lb.
• Guardar el estado en un backend remoto en Azure Storage con bloqueo.
• Validar el despliegue con un Load Balancer público y 2 VMs Linux sirviendo nginx.
• Documentar seguridad, costos, evidencias y limpieza final.

---

3. Arquitectura desplegada

El diagrama muestra cómo están conectados todos los componentes dentro del Resource Group, incluyendo el backend externo de Terraform.

Componentes principales:

• Resource Group lab8-rg — contenedor de todos los recursos de la solución.
• Virtual Network con dos subredes:
  • subnet-web aloja las VMs detrás del Load Balancer.
  • subnet-mgmt aloja Azure Bastion para acceso administrativo seguro.
• Azure Load Balancer (L4) con IP pública, health probe TCP/80 y regla de balanceo 80 → 80.
• 2 VMs Ubuntu LTS aprovisionadas con cloud-init para instalar nginx y servir el hostname.
• NSG que permite únicamente HTTP público (80/TCP) y SSH restringido a la IP del administrador.
• Azure Bastion para acceso SSH sin exponer IP pública en las VMs.
• Azure Storage como backend remoto del estado de Terraform, separado del Resource Group principal.

---

4. Estructura del repositorio

.
├─ infra/
│  ├─ main.tf              # Wiring principal de módulos
│  ├─ providers.tf
│  ├─ variables.tf
│  ├─ outputs.tf
│  ├─ backend.hcl          # Configuración del backend remoto (se genera en el workflow de validacion y despliegue)
│  ├─ cloud-init.yaml      # Provisiona nginx en cada VM
│  └─ env/
│     └─ dev.tfvars        # Variables del entorno de desarrollo (se genera en cada etapa del workflow)
├─ modules/
│  ├─ vnet/                # Red virtual y subredes
│  ├─ compute/             # VMs, NICs y Bastion
│  └─ lb/                  # Load Balancer, probe y NSG
├─ assets/                 # Capturas y diagrama
└─ .github/workflows/      # Pipeline de GitHub Actions

La separación en módulos no es solo una convención: permite reutilizar cada pieza de forma independiente y hace que los cambios tengan un alcance más controlado.

---

5. Flujo de trabajo realizado

1. Se verificaron los prerequisitos: Azure CLI, Terraform >= 1.6, SSH key y suscripción activa.
2. Se creó el backend remoto con Resource Group, Storage Account y Container dedicados.
3. Se configuraron infra/backend.hcl e infra/env/dev.tfvars.
4. Se ejecutaron terraform init, fmt, validate, plan y apply.
5. Se validó el Load Balancer viendo respuestas alternadas desde las dos VMs.

5.1 Bootstrap del backend remoto

El backend remoto se crea antes que cualquier otra cosa porque Terraform necesita un lugar estable donde guardar el estado antes de administrar la infraestructura principal. Tenerlo separado también evita el riesgo de borrar accidentalmente el estado si se hace un destroy de la solución.

SUFFIX=$RANDOM
LOCATION=eastus
RG=rg-tfstate-lab8
STO=sttfstate${SUFFIX}
CONTAINER=tfstate

az group create -n $RG -l $LOCATION
az storage account create -g $RG -n $STO -l $LOCATION --sku Standard_LRS --encryption-services blob
az storage container create --name $CONTAINER --account-name $STO

Con esto creado, el archivo backend.hcl queda apuntando a ese Storage Account y Terraform puede inicializarse con estado centralizado desde el primer init.

---

6. Backend remoto y por qué importa

En Terraform, el "backend" no es el backend de una aplicación: es el lugar donde se guarda el archivo terraform.tfstate. Usar Azure Storage como backend remoto tiene tres ventajas concretas en un contexto de equipo:

• El estado no depende de ninguna máquina local. Si alguien borra su carpeta o cambia de computador, el estado sigue intacto.
• Azure Storage ofrece bloqueo de estado, lo que previene que dos personas hagan apply al mismo tiempo y corrompan el archivo.
• Queda separado de la infraestructura que se gestiona con ese estado, así que un destroy del lab no toca el backend.

---

7. Seguridad y costos

Medidas aplicadas

• Autenticación SSH exclusivamente por llave pública, sin contraseñas.
• Regla SSH en el NSG restringida a la IP pública del administrador en formato /32.
• Acceso administrativo por Azure Bastion, sin IP pública expuesta en las VMs.
• Etiquetas en todos los recursos: owner, course, env, expires.
• Backend remoto en un Resource Group separado del lab.

Costo esperado

El lab usa dos VMs de tamaño reducido y componentes básicos de red. El costo es bajo mientras los recursos están activos, pero la práctica correcta es destruirlos en cuanto se termina la entrega. Al final se corre terraform destroy y se conserva evidencia del proceso.

---

8. CI/CD con GitHub Actions

El pipeline configurado en .github/workflows/terraform.yml sigue un flujo de dos fases:

• En cada pull request se ejecutan fmt, validate y plan. El resultado del plan se publica como artefacto para revisión antes de cualquier cambio.
• El apply y el destroy son manuales, lanzados con workflow_dispatch eligiendo la acción deseada.

---

9. Capturas del proceso

9.1 Creación de la llave SSH

Generación de la llave ed25519 que se usa para autenticarse en las VMs sin contraseña. La llave pública se referencia desde dev.tfvars y Terraform la inyecta al crear cada VM.

9.2 Verificación de IP pública

Se verifica la IP pública del equipo para construir la regla SSH del NSG en formato /32. Esto asegura que solo esa dirección pueda iniciar conexiones SSH hacia las VMs.

9.3 Suscripción activa en Azure

Verificación de la cuenta y suscripción con la que se trabaja el laboratorio antes de crear ningún recurso.

9.4 Bootstrap del backend

Creación del Resource Group, Storage Account y Container para el estado remoto. Este paso es previo a cualquier terraform init del lab principal.

9.5 Archivo backend.hcl

Configuración del backend remoto de Terraform apuntando al Storage Account recién creado.

9.6 Archivo dev.tfvars

Variables del entorno de desarrollo: prefijo, región, conteo de VMs, usuario administrador, clave SSH, IP restringida para SSH y etiquetas de los recursos.

9.7 terraform init con backend remoto

Inicialización de Terraform apuntando al backend remoto. Desde este momento el estado se guarda en Azure Storage y no en el disco local.

9.8 terraform plan

El plan muestra exactamente qué va a crear, modificar o destruir antes de aplicar ningún cambio. Es la oportunidad de revisar la infraestructura antes de que exista.

9.9 Resource Group creado en el apply

Confirmación en el portal de Azure de que el Resource Group principal quedó creado durante el apply.

9.10 terraform apply

Ejecución exitosa del apply con el aprovisionamiento completo de la arquitectura: VNet, subredes, VMs, Load Balancer, NSG y Bastion.

9.11 Validación del Load Balancer

El Load Balancer responde y distribuye el tráfico entre las dos VMs. Al refrescar la página se puede ver el hostname alternando entre VM-1 y VM-2, confirmando que el balanceo está funcionando.

---

10. Video demostrativo

Enlace del video: https://pruebacorreoescuelaingeduco-my.sharepoint.com/:v:/g/personal/david_sarria-a_mail_escuelaing_edu_co/IQChgR1j_hkISZWrL6TWk5DEAUpS0F5xLqvrImKvaPdXKuM?nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D&e=JwU8yf

El video muestra la ejecución del apply, la validación del Load Balancer con ambas VMs respondiendo y la evidencia del destroy al final.

---

11. Reflexión técnica

¿Por qué Load Balancer (L4) y no Application Gateway (L7)?

Para este lab el único requisito era distribuir tráfico HTTP entre dos VMs idénticas. El Load Balancer de Azure resuelve eso sin añadir complejidad ni costo extra. El Application Gateway tendría sentido si hubiera múltiples aplicaciones detrás, necesidad de ruteo por rutas o headers, o terminación TLS centralizada. Para dos VMs con nginx sirviendo una página estática, es overhead innecesario.

¿Qué pasa con el acceso SSH?

Exponer el puerto 22 siempre implica superficie de ataque, aunque esté restringido por IP. En este lab se mitigó usando Azure Bastion, que no expone ninguna IP pública en las VMs y enruta las sesiones SSH a través del plano de control de Azure. La restricción de IP en el NSG se mantiene como segunda capa defensiva.

¿Qué cambiaría en producción?

Monitoreo activo con alertas sobre el estado del health probe, autoscaling con VM Scale Sets en lugar de VMs fijas, VPN o Private Link para la administración, revisión periódica de costos con presupuestos y alertas en Azure Cost Management, y un pipeline de CI/CD con aprobaciones manuales antes de cualquier apply en producción.

---