Semana 3

El camino de una petición

Internet
  → Application Load Balancer (puerto 80)
  → Listener
  → Target Group
  → Tarea de Fargate (contenedor, puerto 8080)

Auto scaling por seguimiento de objetivo

Fije una métrica objetivo (ej. CPU 50%).

  • CPU sube → ECS agrega tareas.
  • CPU baja → ECS quita tareas (hasta el mínimo).

El número de tareas sigue la carga, sin intervención.

Por qué falla una tarea

  1. Mire la tarea detenida y su stoppedReason.
  2. ¿No puede bajar la imagen? → URI o permisos de ECR.
  3. ¿El contenedor salió solo? → los logs de la aplicación.
  4. ¿No pasa el health check? → la ruta de salud, o el puerto.

Ejercicio 12

Configurar el escalado y verificar la salud

Configurar auto scaling para el servicio con seguimiento de CPU (objetivo 50%, mínimo 1, máximo 4 tareas). Luego, en el target group del ALB, confirmar que las tareas están registradas como sanas.

Anatomía de un pipeline

Source        Build          Deploy
(CodeCommit) → (CodeBuild) → (ECS)
  • Stage — una fase del flujo (Source, Build, Deploy).
  • Action — un paso dentro de una etapa.
  • Artifact — lo que una etapa produce y pasa a la siguiente.
  • Transition — el paso de una etapa a la siguiente.

Leer un pipeline

  1. ¿Qué dispara la primera etapa?
  2. ¿Qué artefacto produce cada etapa?
  3. ¿Dónde hay aprobaciones manuales?
  4. ¿En qué etapa falla?

Preguntas puente

  1. ¿Qué etapas necesitaría el pipeline de la aplicación, y en qué orden?
  2. ¿Dónde agrega valor una aprobación manual, y dónde solo estorba?
  3. Cuando el build termina, ¿quién debería enterarse y por qué medio?