Automatizar y observar

Construir el pipeline

Automatizar el flujo de punta a punta

Se va a construir el pipeline que automatiza lo que hoy se hace a mano: un commit en CodeCommit dispara un build en CodeBuild, y la imagen resultante se despliega en ECS —con una pausa de aprobación manual antes del despliegue.

Lo que la etapa de Deploy necesita

La acción de despliegue a ECS de CodePipeline no toma la imagen directamente: toma un pequeño archivo, imagedefinitions.json, que indica qué contenedor actualizar y con qué imagen. Ese archivo lo produce el build. Antes de crear el pipeline, hay que agregar a buildspec.yml una fase que lo genere y lo declare como artefacto:

  post_build:
    commands:
      - echo Publicando la imagen en ECR...
      - docker push $IMAGE_URI:$IMAGE_TAG
      - printf '[{"name":"app","imageUri":"%s"}]' "$IMAGE_URI:$IMAGE_TAG" > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

El nombre app debe coincidir con el nombre del contenedor en la task definition (el que se leyó en la Semana 2). Subir este cambio a CodeCommit antes de continuar —el pipeline tomará la versión más reciente.

Práctica guiada: crear el pipeline

Iniciar la creación

1. Abrir CodePipeline y pulsar Create pipeline.
2. En Pipeline name, escribir taller-aws-<su-nombre>-pipeline.
3. Dejar que CodePipeline cree un nuevo rol de servicio. Pulsar Next.

Etapa Source

1. En Source provider, seleccionar AWS CodeCommit.
2. Elegir el repositorio taller-aws-<su-nombre> y la rama main.
3. En el método de detección de cambios, dejar Amazon CloudWatch Events (la opción recomendada): así un git push a main dispara el pipeline automáticamente.
4. Pulsar Next.

Etapa Build

1. En Build provider, seleccionar AWS CodeBuild.
2. Elegir el proyecto taller-aws-<su-nombre>-build (el de la Semana 1).
3. Pulsar Next.

Etapa Deploy

1. En Deploy provider, seleccionar Amazon ECS.
2. Elegir el clúster y el servicio.
3. Pulsar Next, revisar, y pulsar Create pipeline.

CodePipeline ejecuta el pipeline por primera vez de inmediato: se verán las tres etapas correr de izquierda a derecha.

Agregar la aprobación manual

El pipeline recién creado despliega sin pausa. Agregar una aprobación antes del Deploy:

1. En la vista del pipeline, pulsar Edit.
2. Pulsar Add stage entre Build y Deploy; nombrarla Aprobacion.
3. Dentro de esa etapa, Add action group: tipo de acción Manual approval. Nombrarla y guardar.
4. Pulsar Save para confirmar la edición del pipeline.

Ahora, entre Build y Deploy, el pipeline se detiene y espera una aprobación explícita.

Probar el flujo completo

1. Hacer un cambio pequeño en el código, y subirlo:

   git commit -am "Probar el pipeline"
   git push codecommit main
   

2. En CodePipeline, observar el avance: Source detecta el commit, Build construye y publica la imagen, y el pipeline se detiene en la etapa de aprobación.

3. Pulsar Review en la etapa de aprobación y Approve. El Deploy actualiza el servicio de ECS con la nueva imagen.

4. Confirmar en ECS que el servicio realizó un despliegue nuevo, y recargar la URL del ALB.

Ejercicio 13 — Crear y ejecutar el pipeline

Crear un pipeline con etapas Source (CodeCommit main), Build (el proyecto de CodeBuild) y Deploy (el servicio de ECS), con una etapa de aprobación manual antes del Deploy. Subir un commit, observar el flujo, aprobar el despliegue, y confirmar que la nueva imagen llegó a ECS.

Notificaciones — del pipeline a Teams

Que el pipeline avise solo

El pipeline ya corre sin intervención, pero todavía hay que mirarlo para saber cómo le fue. La última pieza de la automatización es que el pipeline avise solo: cuando una ejecución termina, o falla, o se detiene esperando aprobación, el equipo se entera por el canal donde ya conversa. En esta organización ese canal es Microsoft Teams.

El flujo de notificación

El evento del pipeline viaja por una cadena de servicios hasta llegar a Teams:

De un evento a un canal de Teams

CodePipeline / CodeBuild (evento)
  → CodeStar Notifications (regla)
  → Amazon SNS (tema)
  → AWS Chatbot
  → canal de Microsoft Teams

flowchart LR
  P["CodePipeline /<br/>CodeBuild (evento)"] --> R["CodeStar<br/>Notifications"]
  R --> S[("Amazon SNS<br/>(tema)")]
  S --> CB["AWS Chatbot"]
  CB --> TM["Microsoft Teams"]
  S -.->|laboratorio| IA["App del instructor<br/>(toast)"]

• Una regla de notificación (CodeStar Notifications) escucha eventos del pipeline: ejecución exitosa, fallida, o detenida en una aprobación.
• La regla publica el evento en un tema de Amazon SNS, el servicio de mensajería que desacopla a quien emite de quien recibe.
• AWS Chatbot está suscrito al tema y entrega el mensaje, ya formateado, a un canal de Microsoft Teams.

Cada paso tiene una sola responsabilidad: la regla decide qué eventos importan, SNS los transporta, y Chatbot los entrega al canal. Cambiar el destino (otro canal, otro equipo) no toca el pipeline: solo cambia la suscripción.

Por qué en el laboratorio lo vemos distinto

Conectar Teams de verdad requiere una suscripción de AWS Chatbot al espacio de Teams de la organización —algo que cada participante no puede montar en su cuenta del taller. Para no perder el aprendizaje, el laboratorio usa un espejo del mismo flujo: los eventos de la cuenta llegan a la aplicación del instructor, que los muestra como avisos (toasts) sobre esta misma guía.

El mecanismo cambia, la idea no: lo que en el lab aparece como un toast en la guía, en la organización aparecería en un canal de Teams. La regla de notificación, el tema de SNS, y la lógica de "qué eventos importan" son idénticos; solo difiere el último salto.

Ver cómo se ve un aviso

Antes de disparar el pipeline de verdad, conviene reconocer el formato del aviso. El botón siguiente pide a la aplicación del instructor que emita un toast de ejemplo: el servidor arma una notificación de prueba —atribuida al pod demo— y la difunde por el mismo canal que usan los eventos reales. Cada pulsación produce uno de los tres estados que la regla selecciona, con su color: ejecución exitosa (verde), fallida (rojo), y aprobación pendiente (azul).

El aviso aparece arriba a la derecha y se descarta solo a los pocos segundos. Es el mismo componente que muestra los eventos del pipeline; solo cambia el origen del dato. En producción, ese aviso llegaría a un canal de Teams.

Práctica guiada: crear la regla de notificación

Definir la regla sobre el pipeline

1. Abrir CodePipeline y entrar al pipeline.
2. Pulsar Notify → Create notification rule.
3. En Detail type, elegir Full. En Events, marcar al menos:
   • Pipeline execution: Succeeded
   • Pipeline execution: Failed
   • Manual approval: Needed
4. En Targets, seleccionar el tema de SNS que indique el instructor (el que alimenta la aplicación del taller). Pulsar Submit.

Disparar la regla y observar el aviso

1. Subir un commit a main para iniciar una ejecución del pipeline.
2. A medida que el pipeline avanza, los eventos seleccionados llegan a la aplicación del instructor y aparecen como toasts en la guía, identificados con el pod.
3. Cuando el pipeline se detenga en la aprobación, se verá el aviso Manual approval: Needed; al aprobar y completarse, se verá Succeeded.

Nota: la recepción de los toasts depende de que el instructor haya configurado el tema de SNS y la aplicación del taller. Si aún no está disponible, esta sección se sigue como demostración: el flujo y la regla son reales; el último salto lo muestra el instructor.

Ejercicio 14 — Notificar los eventos del pipeline

Crear una regla de notificación sobre el pipeline que publique, en el tema de SNS del taller, los eventos de ejecución exitosa, fallida, y de aprobación pendiente. Disparar una ejecución y observar los avisos.

Observabilidad — métricas y logs

Saber qué hace el sistema en ejecución

El sistema ya se construye, se despliega, y se notifica solo. Falta la última dimensión: saber qué hace mientras corre. Cuando la aplicación responde lento, o devuelve errores, o una tarea se reinicia, la respuesta no está en el código —está en lo que el sistema emite mientras opera. Esa es la observabilidad, y en AWS empieza con dos fuentes: métricas y logs de CloudWatch.

Métricas: la salud en números

Una métrica es una serie de valores numéricos en el tiempo: uso de CPU, número de peticiones, latencia, tareas en ejecución. AWS publica métricas automáticamente, sin configuración, agrupadas por namespace (el servicio que las emite).

Las que importan para la aplicación:

Estas cinco, leídas juntas, cuentan una historia: cuánta carga llega, cuán rápido se responde, cuántos errores hay, y cuántos recursos se consumen.

Logs: el detalle de cada evento

Donde la métrica dice cuánto, el log dice qué pasó. Cada tarea de Fargate envía la salida de su contenedor —todo lo que la aplicación escribe a la consola— a un grupo de CloudWatch Logs, el mismo que se identificó en la Semana 2. Ahí está el detalle de cada petición, cada error, cada arranque.

Métricas vs. logs

Logs Insights

Buscar a mano en miles de líneas no escala. CloudWatch Logs Insights permite consultar los logs con un lenguaje sencillo. Por ejemplo, las veinte líneas más recientes:

fields @timestamp, @message
| sort @timestamp desc
| limit 20

O contar errores en una ventana de tiempo filtrando por una palabra. La consulta se ejecuta sobre el grupo de logs y devuelve resultados en segundos.

Práctica guiada: leer métricas y logs

Ver una métrica del servicio

1. Abrir CloudWatch → Metrics → All metrics.
2. Entrar a ECS → por servicio, y seleccionar CPUUtilization para el servicio.
3. Observar la gráfica. Ajustar el rango temporal (última hora, último día) en la esquina superior.

Para que la métrica tenga algo que mostrar, se genera carga real en el pod con el botón de abajo. El evento viaja al propio servidor (mismo origen), así que la CPU se quema en la task de ECS, y el pico aparece en CloudWatch.

Consultar los logs

1. Abrir CloudWatch → Logs → Logs Insights.
2. En el selector de grupos, elegir el grupo de logs del contenedor (el que se vio en la task definition).
3. Pegar la consulta de las veinte líneas recientes y pulsar Run query. Leer la salida de la aplicación.

Al pulsar los botones de arriba, las acciones dejan rastro en los logs. Buscar líneas como cpu-burst started, counter incremented, o ignoring duplicate event id: cada una nombra el evento, el handler, y el resultado. Así se ve un log útil —cuenta qué pasó, con qué datos, y cómo terminó— y eso es justo lo que se consulta con Logs Insights.

Métricas personalizadas

Las métricas que AWS publica solas describen la infraestructura: CPU, latencia, peticiones. Una métrica personalizada la publica la propia aplicación, y mide lo que el equipo define como salud del negocio —pedidos procesados, ítems en una cola, reintentos— más allá de lo que el contenedor revela por fuera.

Hay dos vías para llevar un número a CloudWatch:

Enviar un valor por cada vía con los controles de abajo. Ambos publican en el namespace Taller/Custom, métrica CustomValue, con la dimensión method (emf o api) que distingue su origen. El valor se acota a 0–100 (límite del taller, no de CloudWatch).

Abrir CloudWatch → Metrics → Taller/Custom y observar CustomValue con sus dos valores de dimensión. El envío por EMF, además, aparece como una línea de log —se la ve llegar en la Live Tail de la sección siguiente.

Seguir los logs en vivo (Live Tail)

Logs Insights consulta el pasado. Cuando lo que importa es ahora —reproducir un problema y verlo aparecer— sirve CloudWatch Logs Live Tail: una cola en vivo del grupo de logs, línea a línea, a medida que la aplicación las emite.

1. Abrir CloudWatch → Logs → Live Tail.
2. Seleccionar el grupo de logs del contenedor y pulsar Start.
3. Dejar la cola corriendo en una pestaña.

Para tener algo que ver, se fabrican líneas de log a demanda con el contador de abajo. Cada incremento dispara un evento counter en el pod, que escribe en DynamoDB y emite la línea counter incremented —que aparece en la cola casi al instante. El valor a la derecha se actualiza en vivo por SSE, aunque viva en otra parte de la página: misma acción, dos vistas del mismo flujo de eventos.

Pulsar el botón unas cuantas veces y observar las líneas counter incremented llegar en orden a la Live Tail. Eso es tailing de logs: el mismo grupo que se consulta con Insights, visto en tiempo real mientras se genera la actividad.

Ejercicio 15 — Leer la métrica y el log

Para la aplicación, abrir la métrica CPUUtilization del servicio en CloudWatch, y consultar las líneas de log más recientes del contenedor con Logs Insights.

Dónde estamos

Al cerrar la Semana 3, el sistema no solo está en línea: está operado, automatizado, y observado:

• Opera el workload: entiende el camino del tráfico, configuró el escalado automático, y sabe diagnosticar una tarea que no arranca.
• Automatizó la entrega con un pipeline de CodePipeline: del commit al despliegue, con disparo automático y una aprobación manual, y con notificaciones del pipeline hacia Teams (o, en el lab, hacia la guía).
• Abrió la observabilidad: lee las métricas de salud del servicio y consulta los logs del contenedor con Logs Insights.

Se pasó de operar a mano a tener un sistema que se entrega y se reporta solo.

Qué sigue en la Semana 4

La última semana cierra la observabilidad y el curso. Se va a:

• Construir dashboards que reúnan las métricas clave en una sola vista, y alarmas que avisen —por el mismo camino a Teams— cuando un umbral se cruza.
• Activar Container Insights para ver el detalle por tarea y por servicio, e introducir la trazabilidad operacional: seguir un síntoma desde la métrica hasta la línea de log que lo explica.
• Cerrar con un repaso del flujo completo y un ejercicio integrador de extremo a extremo.

Se llegará al final con el ciclo entero en la cabeza: del código a la imagen, al despliegue, a la operación, y a la observación —y las herramientas para diagnosticar cuando algo se sale de lo esperado.