Rodolfo Pilas
bloger podcaster devops sysadmin profesor father
AWS CloudFormation
CLOUD COMPUTING
Gestión de infraestructura como código (IaC)
Taller de Clase
¿Qué es AWS CloudFormation?
- Servicio de AWS que permite modelar, aprovisionar y administrar recursos de AWS.
- Usa un enfoque de Infrastructure as Code (IaC).
- Objetivo: automatizar y estandarizar la creación de infraestructura.
Infrastructure as Code (IaC)
Definición:
Gestionar infraestructura usando archivos de configuración en lugar de procesos manuales.
Ventajas de IaC:
- Reproducibilidad
- Escalabilidad
- Control de versiones
- Reducción de errores humanos
Lenguaje de CloudFormation
- Formatos soportados:
- YAML (más legible)
- JSON (más estricto)
Estructura básica de un template:
Enfoque:
CloudFormation es declarativo: describes el estado final deseado y AWS se encarga de implementarlo.
- AWSTemplateFormatVersion
- Description
- Parameters
- Resources
- Outputs
La aplicación que vamos a construir
- Una web dentro de una red propia.
- Una dirección pública estable.
- Otro servidor en una segunda zona.
- Un balanceador como entrada de la aplicación.
Un mismo stack, varias versiones en Git.
Al terminar, eliminaremos los recursos.
Infraestructura imperativa y declarativa
Con comandos por recurso
Indicamos operaciones, recogemos sus IDs y organizamos la secuencia.
Con CloudFormation
Describimos recursos, propiedades y relaciones en un template.
CloudFormation organiza las operaciones necesarias.
AWS CLI también permite desplegar templates.
Template y stack
Template
Archivo YAML o JSON que describe la infraestructura.
Stack
Despliegue concreto del template, con sus parámetros, recursos y estado.
Un mismo template puede originar varios stacks.
En este taller actualizamos siempre el mismo.
Anatomía de un template
Esquema de sus secciones:
AWSTemplateFormatVersion: '2010-09-09'
Description: Una aplicacion web
Parameters:
# Valores de entrada
Resources:
# Recursos y propiedades
Outputs:
# Valores para usar el entorno
Resources es la única sección obligatoria.
Referencias entre recursos
SubnetId: !Ref PublicSubnetA
SecurityGroupIds:
- !Ref InstanceSecurityGroup
KeyName: !Ref LabKeyPair
Ref obtiene el identificador definido por el tipo.
GetAtt obtiene un atributo, como la IP o la AZ.
Server1 es un ID lógico. AWS asigna el ID físico.
Nuestra red forma parte del stack
- Una VPC propia.
- Dos subredes públicas en AZ diferentes.
- Internet Gateway y rutas de salida.
- Grupos de seguridad y registro de clave pública.
La red está escrita en el template inicial.
Seguiremos sus referencias antes de desplegar.
La aplicación arranca con UserData
UserData:
Fn::Base64: |
#!/bin/bash
dnf install -y nginx
systemctl enable --now nginx
El template user-data también crea la página y /health.
CloudFormation declara la infraestructura.
UserData ejecuta comandos dentro de EC2.
WA · Tarea 1
Una aplicación web en su propia red
25 minutos
Abrí la consigna en Webasignatura:
- Leé el template y completá los parámetros.
- Creá el stack y comprobá la página server1.
- Registrá Outputs y el primer commit.
veamos cómo EC2 se vincula con la red.
El stack y la aplicación
Events: operaciones y causas de error.
Resources: recursos e IDs físicos.
Outputs: direcciones e información de acceso.
CREATE_COMPLETE confirma la creación del stack.
La prueba HTTP confirma que nuestra web responde.
Una actualización y su change set
El change set muestra el impacto previsto:
- Add: recursos nuevos.
- Modify: recursos que cambian.
- Remove: recursos que se retiran.
También indica posibles reemplazos.
Primero revisamos. Después ejecutamos.
Una Elastic IP para Server1
EIP reserva una dirección pública.
EIPAssociation la vincula con una instancia.
AllocationId: !GetAtt Server1EIP.AllocationId
InstanceId: !Ref Server1
La dirección se conserva mientras mantenemos la asignación.
WA · Tarea 2
Una dirección pública estable
15 minutos
Abrí la consigna en Webasignatura:
- Agregá la EIP y su asociación.
- Actualizá Outputs y revisá el change set.
- Aplicá, comprobá HTTP y guardá un commit.
compararemos la IP y el ID de Server1.
Dos servidores en dos AZ
Server1: PublicSubnetA, en AZ1.
Server2: PublicSubnetB, en AZ2.
Ambos usan la misma AMI y tipo de instancia.
La subred determina la AZ de cada servidor.
Dos subredes distintas pueden pertenecer a una misma AZ.
WA · Tarea 3
Otra instancia en una segunda AZ
20 minutos
Abrí la consigna en Webasignatura:
- Agregá Server2 en PublicSubnetB.
- Identificá su página y publicá sus Outputs.
- Aplicá el cambio y comprobá ambas AZ.
Server1 debe conservar su ID físico.
Un Application Load Balancer
LoadBalancer
Ofrece una entrada pública mediante DNS.
Listener
Recibe HTTP en el puerto 80 y define la acción.
TargetGroup
Agrupa destinos y comprueba su salud.
Usamos la acción predeterminada del Listener.
Acceso mediante grupos de seguridad
ALB, puerto 80: ingreso desde Internet.
EC2, puerto 80: ingreso desde el SG del ALB.
EC2, puerto 22: ingreso desde nuestra IP /32.
Las instancias conservan IP pública para esta práctica.
HTTP directo a EC2 debe quedar bloqueado.
La salud de los destinos
El TargetGroup consulta /health en cada instancia.
Esperamos dos destinos en estado healthy.
La URL del ALB debe devolver nuestra aplicación.
Haremos varias solicitudes para observar ambos servidores.
Usa RR pero no esperamos una alternancia exacta.
WA · Tarea 4
Un ALB como punto de entrada
35 minutos
Abrí la consigna en Webasignatura
- Vinculá ALB, Listener y TargetGroup.
- Permití HTTP a EC2 solo desde el SG del ALB.
- Retirá la EIP y usá el DNS del balanceador.
Evidencia: dos targets healthy, web por ALB y bloqueo directo.
Qué aporta Git a la infraestructura
git diff permite revisar el cambio en el archivo.
El commit conserva una versión y su motivo.
El historial permite comparar y recuperar versiones.
Registramos también región, AMI y parámetros de reproducción.
GitLab o CodeCommit pueden alojar ese historial.
Revertir código y actualizar AWS
Agregamos un tag a Server1, guardamos y desplegamos.
git revert --no-edit HEAD
Git revierte el último commit.
AWS conserva el tag hasta que apliquemos otra actualización.
Un nuevo change set permite revisar esa reversión.
WA · Tarea 5 · Primera parte
Historial y reversión
15 minutos
Abrí la consigna final en Webasignatura.
- Agregá el tag Practice y desplegalo.
- Revertí únicamente ese commit.
- Observá AWS antes y después de volver a aplicar.
Al volver: explicaremos cuándo cambió el archivo y cuándo cambió AWS.
Eliminar el entorno
CloudFormation procesa los recursos del stack según sus dependencias.
Retain puede conservar recursos.
DELETE_FAILED requiere revisar Events.
Cuenta, permisos, AMI y repositorio son prerrequisitos.
Buscamos eliminar todos los recursos de nuestra aplicación.
WA · Tarea 5 · Cierre
Inventario, eliminación y entrega
20 minutos
- Guardá el inventario, Outputs y evidencias.
- Eliminá el stack y esperá DELETE_COMPLETE.
- Verificá que no quedaron recursos del taller.
Entrega: YAML, historial, bitácora y evidencia del borrado.
El docente mostrará cómo recrear el entorno desde Git.
Lo que ahora podemos explicar
¿Cómo se relacionan EC2, red, EIP y ALB?
¿Qué impacto anticipa un change set?
¿Qué conserva Git y qué aplica CloudFormation?
¿Qué eliminamos al borrar el stack?
El código conserva la arquitectura después de eliminar sus recursos.
Continuaciones del taller
- Auto Scaling con LaunchTemplate y AutoScalingGroup.
- HTTPS e instancias privadas.
- Drift y validación automática en Git.
Sobre esta presentación
CLOUD COMPUTING
Atribución 4.0 Internacional (CC BY 4.0)
https://creativecommons.org/licenses/by/4.0/deed.es
AWS CloudFormation Taller de Clase
By Rodolfo Pilas
