La aplicación en línea
El despliegue — CloudFormation como caja negra
El salto de la imagen a la aplicación
En la sección anterior se construyó y publicó la imagen Docker en ECR. Pero una imagen en un registro no es una aplicación en línea: alguien tiene que lanzar el contenedor, colocarlo detrás de un balanceador de carga, conectarlo a una base de datos, y configurar la red. Hacer eso paso a paso desde la consola tomaría más de una hora y sería difícil de reproducir exactamente.
AWS CloudFormation resuelve este problema con un enfoque declarativo: se describe en un archivo YAML o JSON qué recursos se quieren —un clúster ECS, un servicio Fargate, un ALB, una tabla DynamoDB, grupos de seguridad, roles de IAM— y CloudFormation los crea todos en el orden correcto, manejando las dependencias automáticamente.
El template de esta semana
El instructor provee el archivo taller-semana1.yaml. Este template es, por ahora,
una caja negra: se lanza con dos parámetros y se obtiene un ambiente funcional
en minutos. No es necesario entender su contenido esta semana —eso es el tema de la Semana 2.
Lo que despliega el template:
- Una tabla de DynamoDB para la aplicación.
- Un clúster ECS y un servicio Fargate que ejecuta la imagen Docker.
- Un Application Load Balancer (ALB) que recibe el tráfico HTTP y lo dirige al contenedor.
- Los roles de IAM, grupos de seguridad, y configuración de red necesarios para que todo funcione junto.
Los únicos parámetros configurables son el nombre del stack y el URI de la imagen en ECR. El resto lo gestiona el template.
Un detalle que vale la pena notar
Al abrir la URL del ALB en el navegador, se ve cargarse esta misma guía: la plataforma del taller servida desde el despliegue en ECS. La aplicación que se construyó, desplegó, y opera es exactamente el entorno desde el que se leen estas instrucciones. No es un ejemplo genérico —es el sistema real.
Práctica guiada: lanzar el stack de CloudFormation
Abrir CloudFormation
- Abrir CloudFormation.
- Confirmar que la región seleccionada (esquina superior derecha) es la misma que se ha usado para todos los recursos del taller.
Crear el stack
- Pulsar Create stack y seleccionar With new resources (standard).
- En la sección Specify template, seleccionar Upload a template file.
- Pulsar Choose file y seleccionar el archivo
taller-semana1.yamlprovisto por el instructor. - Pulsar Next.
Completar los parámetros
- En Stack name, escribir
taller-<su-nombre>(por ejemplo:taller-maria). El nombre del stack identifica el ambiente en la consola y debe ser único en la región. - En los parámetros del template, localizar el campo correspondiente al URI de
la imagen. Pegar el URI completo copiado de ECR al final de la sección anterior.
El formato es:
123456789012.dkr.ecr.us-east-1.amazonaws.com/taller-aws-<su-nombre>:latest - Revisar los demás parámetros. Dejarlos con sus valores predeterminados a menos que el instructor indique lo contrario.
- Pulsar Next.
Configurar opciones del stack
- En la pantalla de opciones, no es necesario cambiar nada. Pulsar Next.
Confirmar y lanzar
- En la pantalla de revisión, desplazarse hasta la sección Capabilities al pie de la página. Se verá un aviso sobre que el template puede crear recursos de IAM. Marcar la casilla I acknowledge that AWS CloudFormation might create IAM resources with custom names.
- Pulsar Submit (o Create stack, según la versión de la consola).
Seguir la creación del stack
- CloudFormation lleva automáticamente a la vista del stack recién iniciado. Seleccionar la pestaña Events. Se ve cómo se van creando los recursos en tiempo real, uno por uno, con su estado.
- Esperar hasta que el estado del stack (en la parte superior) cambie a CREATE_COMPLETE. El proceso toma entre 3 y 8 minutos, dependiendo de la región. Si algún recurso falla, el estado cambia a ROLLBACK_IN_PROGRESS y CloudFormation deshará los cambios automáticamente —revisar el evento fallido para entender el motivo.
Obtener la URL de la aplicación
- Una vez en CREATE_COMPLETE, seleccionar la pestaña Outputs.
- Se verá una salida llamada
ALBUrl(o similar, según el template). Copiar el valor —es la URL pública del Application Load Balancer. - Abrir esa URL en una nueva pestaña del navegador. En unos segundos se ve cargarse esta guía del taller, servida desde el contenedor recién desplegado en ECS.
Ejercicio 7 — Desplegar la aplicación
Lanzar el stack de CloudFormation con el template taller-semana1.yaml provisto por
el instructor. Usar como URI de la imagen el valor copiado de ECR al terminar el
Ejercicio 4. Al terminar, abrir la URL del ALB en el navegador y confirmar que la
aplicación está en línea.
- En la consola de AWS, abrir CloudFormation.
- Pulsar Create stack → With new resources (standard).
- Seleccionar Upload a template file, pulsar Choose file, y subir
taller-semana1.yaml. - Pulsar Next.
- En Stack name, escribir
taller-<su-nombre>. - En el campo del URI de la imagen, pegar el URI completo de ECR con la etiqueta
latest(por ejemplo:123456789012.dkr.ecr.us-east-1.amazonaws.com/taller-aws-maria:latest). - Pulsar Next dos veces para llegar a la pantalla de revisión.
- En la sección Capabilities, marcar la casilla de aceptación de recursos de IAM.
- Pulsar Submit.
- En la pestaña Events, esperar a que el estado del stack llegue a CREATE_COMPLETE.
- En la pestaña Outputs, copiar el valor de ALBUrl.
- Abrir esa URL en el navegador. Se verá la plataforma del taller corriendo desde el despliegue.
Destruir, y recrear, el ambiente
Por qué se practica la destrucción desde el primer día
En un sistema operado manualmente, un error puede dejar el ambiente en un estado inconsistente difícil de diagnosticar y corregir. El tiempo de recuperación depende de cuánto se recuerde de cómo se construyó originalmente, y de si esa memoria es precisa.
Cuando el ambiente se define como código —en este caso, un template de CloudFormation— la situación cambia radicalmente. Si algo sale mal, la corrección no es reconstruir desde la memoria: es borrar y volver a crear. El proceso es el mismo que se siguió hace unos minutos, tarda lo mismo, y produce exactamente el mismo resultado. El costo de un error se convierte en minutos de espera, no en horas de diagnóstico.
Esta es la razón por la que se practica el ciclo completo de destrucción y recreación en la Semana 1: para que en las semanas siguientes, si algo falla, la respuesta refleja no sea la urgencia sino la calma. Se borra, se recrea, se sigue.
Qué sobrevive a la destrucción del stack
Antes de borrar el stack, es útil entender qué destruye CloudFormation y qué no.
El template taller-semana1.yaml crea y gestiona: el clúster ECS, el servicio Fargate,
el ALB, la tabla de DynamoDB, los roles de IAM, y la configuración de red. Todos esos
recursos se eliminan cuando se borra el stack.
Lo que no forma parte del stack y por lo tanto sobrevive:
- El repositorio de CodeCommit con todo el historial de commits.
- El repositorio de ECR con la imagen Docker publicada.
- El proyecto de CodeBuild configurado en la sección anterior.
Esto significa que al recrear el stack basta con volver a proporcionar el URI de la imagen en ECR: el ambiente completo se reconstituye en minutos, sin volver a hacer el build ni resubir el código.
Práctica guiada: borrar el stack
Iniciar la eliminación
- En la consola de AWS, abrir CloudFormation.
- En la lista de stacks, seleccionar el stack
taller-<su-nombre>. - Pulsar Delete.
- En el diálogo de confirmación, pulsar Delete stack.
Seguir los eventos de borrado
- CloudFormation comienza a eliminar los recursos en orden inverso al de creación (primero los que dependen de otros, luego los recursos base). La pestaña Events muestra cada eliminación en tiempo real.
- Esperar hasta que el stack desaparezca de la lista o, si la consola lo muestra, hasta que el estado sea DELETE_COMPLETE. El proceso toma entre 3 y 6 minutos.
Nota: si algún recurso no puede eliminarse automáticamente (por ejemplo, una tabla de DynamoDB con protección contra eliminación, o un bucket de S3 con objetos), el estado cambiará a DELETE_FAILED y el evento fallido indicará el recurso y el motivo. El instructor indicará cómo proceder en ese caso.
Confirmar que la aplicación ya no está en línea
- Intentar abrir de nuevo la URL del ALB usada antes. El navegador debe mostrar un error de conexión —el balanceador ya no existe.
Práctica guiada: recrear el stack
Lanzar el stack de nuevo
- Con el stack eliminado, pulsar Create stack → With new resources (standard).
- Subir nuevamente el template
taller-semana1.yaml. (Si la consola ofrece reutilizar el template anterior porque se subió recientemente, se puede hacer.) - En Stack name, usar exactamente el mismo nombre:
taller-<su-nombre>. - En el campo del URI de la imagen, pegar el mismo URI de ECR usado antes. La imagen sigue en ECR — no es necesario volver a hacer el build.
- Pulsar Next, aceptar las capacidades de IAM, y pulsar Submit.
- En la pestaña Events, esperar a que el estado vuelva a CREATE_COMPLETE.
Verificar que la aplicación está de nuevo en línea
- En la pestaña Outputs, la URL del ALB puede ser diferente a la anterior —los balanceadores de carga generan nombres DNS únicos. Copiar el nuevo valor.
- Abrir la URL en el navegador. La aplicación debe responder exactamente igual que antes. El ciclo completo está cerrado.
Ejercicio 8 — Destruir, y recrear, el ambiente
Eliminar el stack de CloudFormation por completo. Confirmar que la aplicación ya no responde. Luego recrear el stack con los mismos parámetros y confirmar que la aplicación vuelve a estar en línea.
Destrucción:
- En la consola de AWS, abrir CloudFormation.
- Seleccionar el stack
taller-<su-nombre>. - Pulsar Delete → Delete stack.
- En la pestaña Events, seguir los eventos hasta que el stack desaparezca de la lista.
- Intentar abrir la URL del ALB anterior. El navegador debe mostrar un error de conexión, confirmando que el balanceador ya no existe.
Recreación:
- Pulsar Create stack → With new resources (standard).
- Subir el template
taller-semana1.yaml(o reutilizar el cargado anteriormente). - En Stack name, escribir
taller-<su-nombre>. - En el campo del URI de la imagen, pegar el URI de ECR con la etiqueta
latest. La imagen sigue disponible en ECR sin necesidad de un nuevo build. - Avanzar por las pantallas, aceptar las capacidades de IAM, y pulsar Submit.
- En la pestaña Events, esperar a CREATE_COMPLETE.
- En la pestaña Outputs, copiar la nueva URL del ALB.
- Abrirla en el navegador. La guía del taller debe cargarse de nuevo —el ambiente está completamente restaurado.
Preguntas puente
Estas preguntas abren la sesión del viernes. Conviene pensarlas después de la sesión del miércoles, cuando el ambiente todavía está fresco. No se buscan las respuestas de inmediato: se razonan desde lo que se construyó. Al comenzar la sesión remota, cada participante comparte su respuesta y se discute en conjunto antes de continuar.
Pregunta 1
¿Qué hace exactamente CodeBuild con el buildspec.yml, fase por fase, y dónde queda
el resultado?
CodeBuild lee el archivo buildspec.yml desde la raíz del repositorio de CodeCommit
y ejecuta los comandos de cada fase en secuencia, dentro de un contenedor efímero
(un entorno limpio que se destruye al terminar el build):
install: prepara el entorno de ejecución. En elbuildspec.ymldel taller, esta fase verifica que Docker (con buildx) y la CLI de AWS estén disponibles — la imagen administrada de CodeBuild ya los trae, así que no hay nada que instalar.pre_build: se ejecuta antes de la construcción principal. En elbuildspec.ymldel taller, esta fase correhadolintsobre elDockerfile, autentica con Amazon ECR usando las credenciales del rol de IAM del proyecto —sin este paso, el push posterior fallaría por falta de permisos— y crea el builder de BuildKit que permite exportar cache hacia el registro.build: ejecutadocker buildx buildusando elDockerfileen la raíz del repositorio, etiqueta la imagen con el URI completo del repositorio de ECR y la publica en el mismo paso (--push), junto con su cache de capas (tag:cache).post_build: verifica conaws ecr describe-imagesque la imagen quedó publicada en el repositorio de ECR.
El resultado —la imagen Docker— queda almacenado en Amazon ECR, identificado por
el URI del repositorio y la etiqueta definida en la variable IMAGE_TAG (en este
caso, latest). El entorno de CodeBuild en sí desaparece al terminar: no hay
servidores que persistan entre builds.
Pregunta 2
Si se borra el stack de CloudFormation, ¿qué sobrevive —el repositorio de CodeCommit, la imagen en ECR, ambos, o ninguno? ¿Por qué?
Sobreviven ambos: el repositorio de CodeCommit y la imagen en ECR.
La razón es que CloudFormation solo gestiona los recursos que se declararon en el template.
El template taller-semana1.yaml describe el clúster ECS, el servicio Fargate, el
Application Load Balancer, la tabla de DynamoDB, los roles de IAM y la configuración
de red. Esos recursos los creó CloudFormation y los elimina cuando se borra el stack.
El repositorio de CodeCommit y el repositorio de ECR (junto con la imagen que contiene) se crearon directamente desde la consola, fuera de cualquier stack de CloudFormation. CloudFormation no los conoce y no los toca. Por eso al recrear el stack basta con proporcionar de nuevo el URI de la imagen: la imagen ya está en ECR, exactamente como la dejó el build.
Esta separación es intencional: el código fuente y los artefactos de build tienen un ciclo de vida distinto al del ambiente de ejecución. Los primeros crecen con cada commit y cada build; el segundo puede destruirse y recrearse cuantas veces sea necesario.
Pregunta 3
El template desplegó la aplicación detrás de un ALB. ¿Qué pasos manuales se ahorró, y cuáles de esos recursos se reconocen en la consola?
El template automatizó al menos los siguientes pasos que, de otro modo, habría que ejecutar manualmente desde la consola:
- Crear la tabla de DynamoDB con el nombre y la configuración de clave correctos.
- Crear el clúster de ECS.
- Definir la task definition de Fargate: especificar la imagen, los límites de CPU y memoria, las variables de entorno, el rol de ejecución.
- Crear el servicio ECS que mantiene el número de tareas en ejecución y las reemplaza si fallan.
- Crear el Application Load Balancer, el listener en el puerto 80, y el target group que apunta al servicio ECS.
- Crear los grupos de seguridad que permiten el tráfico HTTP hacia el ALB y del ALB hacia los contenedores.
- Crear el rol de IAM de ejecución de ECS para que Fargate pueda descargar la imagen de ECR.
- Conectar todo: el ALB al target group, el target group al servicio, el servicio a la task definition, la task definition a la imagen en ECR.
En la consola se puede verificar cada uno de estos recursos directamente:
- ECS → Clusters: se verá el clúster y, dentro de él, el servicio y las tareas en
estado
RUNNING. - EC2 → Load Balancers: se verá el ALB con su DNS público.
- DynamoDB → Tables: se verá la tabla creada por el template.
- IAM → Roles: se verá el rol de ejecución de ECS cuyo nombre contiene el nombre del stack.
El valor de CloudFormation es que todos esos pasos, incluyendo el orden correcto de creación y las dependencias entre recursos, quedan codificados en el archivo YAML. Reproducirlos requiere lanzar el template, no recordar los pasos.
Dónde estamos
Al cerrar la Semana 1, cada participante tiene el flujo completo de la primera parte del taller funcionando de punta a punta:
- Un repositorio en CodeCommit con el código de la aplicación, versionado con git.
- Un pipeline de build en CodeBuild que construye la imagen Docker y la publica
en ECR a partir del
buildspec.yml. - La aplicación en línea sobre ECS/Fargate detrás de un ALB, desplegada con un template de CloudFormation.
- El ciclo de recuperación practicado: destruir y recrear el ambiente en minutos.
Se construyó, desplegó, y operó el sistema. Lo que todavía es una caja negra es cómo ese template arma todo por dentro.
Qué sigue en la Semana 2
La próxima semana se abre la caja negra. Se va a:
- Leer el template
taller-semana1.yamlrecurso por recurso, y entender la infraestructura como código: parámetros, recursos, salidas, y funciones intrínsecas. - Actualizar el stack de forma segura con change sets, y ver cómo CloudFormation maneja cambios, drift, y rollback.
- Conocer los primeros contenedores por dentro: las task definitions y los services de ECS/Fargate que el template creó.
Al final de la Semana 2 se comprenderá, y se podrá modificar, el ambiente que esta semana solo se lanzó.