Problema

Muchos ingenieros recién graduados o con experiencia en desarrollo backend quieren pasar a roles de DevOps, pero se quedan en la teoría. Aprenden conceptos de arquitectura, bases de datos y redes, y luego instalan Docker, Kubernetes o Terraform sin enfrentarse a situaciones que aparecen en producción: un despliegue que se queda colgado, un aumento inesperado del gasto en la nube, o una alerta de monitoreo que no saben interpretar. El reto es crear un entorno de práctica que reproduzca esos dolores reales sin necesidad de montar infraestructuras costosas en proveedores públicos.

Causa

  1. Entornos de “sandbox” demasiado simples – Usar solo Docker Compose en una laptop no expone problemas de networking, escalado o límites de recursos que aparecen en clústers reales.
  2. Falta de métricas y alertas – Sin un sistema de observabilidad (Prometheus, Grafana, CloudWatch) el ingeniero no ve cuándo una aplicación está sobrecargada o cuándo una pipeline falla por falta de recursos.
  3. Ausencia de políticas de costos – En la mayoría de los tutoriales no se configura budgets, tags o políticas de auto‑escalado, por lo que el alumno nunca experimenta la presión de mantener el gasto bajo control.
  4. Despliegues sin rollback estructurado – La mayoría de los labs hacen “apply” y asumen que siempre funciona. En producción, los cambios pueden romper bases de datos, provocar downtime o generar errores de configuración que requieren revertir rápidamente.

Solución

Diseñar un mini‑proyecto “end‑to‑end” que incluya los componentes críticos de un flujo DevOps real:

  1. Repositorio Git con CI/CD
    • Usa GitHub Actions, GitLab CI o cualquier runner local.
    • Configura al menos dos pipelines: build (compilación, pruebas unitarias, lint) y deploy (terraform apply, helm upgrade).
  2. Infraestructura como código (IaC)
    • Define la infraestructura en Terraform (VPC, subnets, security groups, un clúster EKS o un clúster K3s local).
    • Versiona los módulos y usa workspaces para separar entornos dev y staging.
  3. Contenedores y orquestación
    • Empaqueta la aplicación (por ejemplo, una API Flask) en Docker.
    • Despliega con Helm charts que incluyan liveness/readiness probes, recursos (CPU/mem) y políticas de rollout (maxSurge, maxUnavailable).
  4. Observabilidad
    • Instala Prometheus y Grafana en el clúster.
    • Exporta métricas de la aplicación y del propio Kubernetes (CPU, memory, pod restarts).
    • Configura alertas básicas: uso de CPU > 80 % durante 5 min, despliegue fallido, pod en CrashLoopBackOff.
  5. Gestión de costos
    • En proveedores cloud, habilita budget alerts y etiquetas de costos.
    • En entornos locales, simula costos con scripts que calculen el consumo de recursos (ej. docker stats o kubectl top nodes).
  6. Rollback y recuperación
    • Implementa una estrategia de blue‑green o canary usando Helm hooks.
    • Añade un job de rollback que ejecute helm rollback si la pipeline detecta fallas post‑deploy.

Paso a paso resumido

  1. Crear repositorio 
    git init devops-practice && cd devops-practice
mkdir -p infra helm app
  2. Terraform – archivo infra/main.tf con provider y recursos mínimos (VPC, subnets, EKS o K3s).
  3. Dockerfile en app/ que compile la API y exponga el puerto 8080.
  4. Helm chart en helm/app/ con valores para recursos y probes.
  5. GitHub Actions (.github/workflows/ci.yml) que ejecute:
    • docker build -t myapp:${{ github.sha }}
    • terraform init && terraform apply -auto-approve
    • helm upgrade --install myapp ./helm/app --set image.tag=${{ github.sha }}
  6. PrometheusRule para alertas críticas.
  7. Script de costos (scripts/cost.sh) que sume CPU y memoria usados y compare contra umbrales definidos.

Cuándo aplicar esta solución

  • Entornos de aprendizaje donde el objetivo es experimentar con fallos reales sin comprometer producción.
  • Equipos pequeños que necesitan validar procesos de CI/CD antes de adoptarlos a gran escala.
  • Entrevistas técnicas donde se pide demostrar capacidad de diseñar pipelines, manejar observabilidad y controlar costos.

No es adecuada cuando:

  • Se dispone de recursos ilimitados en la nube y el objetivo es solo probar una herramienta aislada.
  • El proyecto requiere certificaciones específicas que obligan a usar herramientas propietarias no cubiertas por este stack.

Código

# Build Docker image
docker build -t myapp:latest ./app

# Deploy Terraform (assume AWS credentials are set)
terraform -chdir=infra init
terraform -chdir=infra apply -auto-approve

# Helm upgrade with new image tag
helm upgrade --install myapp ./helm/app \
  --set image.repository=myapp \
  --set image.tag=$(git rev-parse --short HEAD)

Verificación

  1. Pipeline exitosa – Revisa la ejecución de la acción en GitHub; debe terminar en green y mostrar los pasos de build, terraform y helm.
  2. Aplicación accesible – Ejecuta kubectl get svc myapp -o wide y verifica que el EXTERNAL-IP responde a curl http://<IP>:8080/health.
  3. Alertas activas – Genera una carga artificial (por ejemplo, hey -n 1000 -c 50 http://<IP>:8080/) y confirma que Grafana muestra la métrica de CPU > 80 % y que Prometheus dispara la alerta configurada.
  4. Costo simulado – Corre bash scripts/cost.sh y verifica que el script avisa cuando el consumo supera el umbral definido (ej. 2 vCPU).
  5. Rollback – Introduce un error deliberado en el Dockerfile (cambia el puerto) y vuelve a lanzar la pipeline; la alerta debe dispararse y el job de rollback debe ejecutar helm rollback myapp <previous_revision>.

Notas adicionales

  • Persistencia de datos – Usa PersistentVolumeClaims con storageClass “standard” para simular bases de datos; los fallos de PVC son una fuente frecuente de incidentes.
  • Seguridad básica – Añade escaneo de imágenes con Trivy en la pipeline; los hallazgos críticos deben bloquear el despliegue.
  • Versionado de Helm – Mantén un historial de releases (helm history myapp) para facilitar auditorías y rollback rápidos.
  • Auto‑escalado – Configura HPA (Horizontal Pod Autoscaler) y observa cómo la carga variable dispara la creación de pods; esto ayuda a entender el impacto en costos y en la latencia de la aplicación.
  • Documentación viva – Genera automáticamente un README.md desde los archivos de Terraform y Helm usando terraform-docs y helm-docs; así el proyecto siempre tiene documentación actualizada.