grupo-15@fintech-nova:~/tp-2$

PLAY [Sprint Demo · FinTech Nova] *******************************************

De un deploy a mano a un pipeline automático y seguro

TASK [Gathering Facts] equipo: Grupo 15 audiencia: CTO de FinTech Nova plays: 1 terraform → Ghibaudo, Alan Yair 2 ansible → Sidorowicz, Sebastián Pablo 3 pipeline → Lambertucci, Juan Pablo

ok: [cto-fintech-nova]

TASK [Qué cambió para el negocio] ************************************

Qué cambió para el negocio

ANTES un script desde una computadora

AHORA infraestructura, servidor e imágenes como código

Una persona, su computadora y un script

→

RepetibleSiempre el mismo camino, sin pasos que alguien se olvide

Si esa persona o su máquina falla, no hay deploy

→

SeguroUna imagen con vulnerabilidades críticas conocidas no llega a producción

No se sabe qué versión está corriendo

→

TrazableVersión y commit en cada imagen: sabemos qué corre y podemos volver atrás

changed: [fintech-nova] => deploy: "manual" → "automático"

PLAY [Terraform · infraestructura] *********************************

TASK [Pasar de CloudFormation a Terraform] **************************

De CloudFormation a Terraform

--- antes · CloudFormation +++ ahora · Terraform - Plantilla propia de AWS; ver el impacto exigía armar change sets aparte. + terraform plan muestra qué se crea, cambia o destruye, antes de aplicar. + terraform apply ejecuta ese plan: solo cambia lo que difiere.

¿PARA QUÉ SIRVE?

Describimos la infraestructura en archivos de código y Terraform la crea en AWS: red, firewall y servidor.

PLAN

Una vista previa legible de los cambios. Se revisa antes de aplicar, sin sorpresas.

APPLY

Ejecuta lo que mostró el plan. Repetirlo no duplica recursos: es repetible.

changed: [aws] => iac: "CloudFormation" → "Terraform"

TASK [Crear la infraestructura en AWS] ******************************

Infraestructura como código

Terraform will perform the following actions: + red propia con una subred pública + salida a internet + firewall: solo el 443 abierto al público + administración por SSH desde una sola IP + servidor con rol para leer sus secretos + llave SSH del equipo + el estado vive de terraform en S3 Plan: 8 to add, 0 to change, 0 to destroy.

DECISIÓN

Terraform crea, Ansible configura

Antes Docker se instalaba en el arranque del servidor, una sola vez y sin verificación. Ahora lo hace Ansible: se puede repetir y comprobar.

ENTREGA AL PASO SIGUIENTE

Terraform genera el inventario de Ansible con la IP de la sesión.

# sandbox de AWS Academy: sesiones de 2 horas, IP y credenciales nuevas cada vez al_iniciar_sesion: terraform apply y actualizar las variables del pipeline

ok: [aws] => recursos: 8 · público: 443 · puerto 80: cerrado

TASK [Aplicar Terraform entre sesiones del lab] **************************

fatal: [tfstate]: FAILED! => {"msg": "el estado recordaba recursos que ya no existían"}

El estado local quedó desactualizado

SÍNTOMA

terraform state list mostraba VPC, subnets, Internet Gateway y route table de una sesión anterior. En la consola de AWS solo existía la VPC por defecto del lab.

CAUSA

El sandbox elimina los recursos al terminar la sesión, pero el terraform.tfstate local conserva el registro de lo que se creó.

RESOLUCIÓN

Como en AWS no quedaba nada, descartamos el estado y empezamos desde cero. El siguiente plan propuso crear todo.

LECCIÓN

En AWS Academy el estado es efímero: terraform destroy antes de cerrar el lab, o descartar el estado al iniciar. Mejora futura: backend remoto (estado en GitLab).

ok: [terraform] => rescued=1 · estado descartado · plan: crear todo

PLAY [Ansible · configuración y despliegue] ************************

TASK [Preparar el servidor y desplegar] *****************************

De servidor vacío a app funcionando

Servidor vacío

recién creado por Terraform

provision
.yml

Servidor listo

Docker
Certificados
Cliente de AWS
Compose con versión fija y verificada
Usuario con acceso a Docker

deploy.yml

Copia solo lo necesario
Configuración y certificado
Secretos en AWS
Levanta y espera a que esté sano

App funcionando

db

traefik

web

clientes

pagos

facturas

transacc.

tarjetas

Web y 5 APIs responden por HTTPS

Puerto 80 cerrado

IDEMPOTENTE1ª: instala→2ª: mismo resultado

HOYpipelineansiblea integrar

ok: [ec2-fintech-nova] => tareas: 21 · failed: 0

Ansible era una mejora pendiente de la Parte 1: reemplaza a los scripts por SSH. Contarlo de izquierda a derecha como la historia del servidor. Terraform nos deja un servidor vacío. El primer playbook, provision.yml, lo deja listo: Docker, certificados, el cliente de AWS, Compose con versión fija y verificada, y el usuario con acceso a Docker. El segundo, deploy.yml, despliega: copia solo los archivos de ejecución, sin código fuente; genera la configuración y el certificado si no existe; prepara los secretos; levanta todo y espera a que cada servicio esté sano (los 8 cuadros que se prenden). Al final verifica por HTTPS la web y las 5 APIs y confirma que el puerto 80 está cerrado. Abajo: es idempotente, correrlo dos veces deja el mismo resultado. Aclarar con honestidad si ya está integrado al pipeline o si todavía se corre aparte.

TASK [Gestión de secretos] *******************************************

Ninguna contraseña vive en el repositorio

GitLab

Variables del pipeline, enmascaradas y protegidas

Acceso al registry
Llave del servidor

El servidorgenera las claves de la base

las guarda cifradas

AWS SSMParameter Store, cifrado

en memoria · nunca a disco

Contenedoreslas reciben en cada deploy

Repositorio

0

secretos versionados

contraseñas
llaves
certificados
estado de la infraestructura

TASK [Guardar las claves de la base en SSM] # no_log: true ok: [ec2-fintech-nova] => {"censored": "the output has been hidden..."}

ok: [ec2-fintech-nova] => secretos en el repo: 0 · SSM: único camino

TASK [Qué pasa si un servicio se cae] ********************************

Qué pasa si un servicio se cae

SI UN CONTENEDOR FALLA

db

traefik

web

clientes

pagos

facturas

transacc.

tarjetas

Se reinicia soloreinicio automático del contenedor

Arranque ordenadolas APIs esperan a que la base esté lista

Recursos acotadoslímites de CPU y memoria por servicio

Vuelta atrása la versión anterior por su número

IMPACTO DE 1 HORA CAÍDOS

transacciones por hora

×

monto promedio

USD

×

comisión

%

=USD ___por hora

Estimación, sin contar reclamos ni pérdida de confianza.

EC2

HOYun solo servidor
punto único de falla

PRÓXIMO PASOotra zona y alertas

balanceador

zona A

zona B

alertas

ok: [ec2-fintech-nova] => restart: always · rollback: versión anterior

Dos casos. Botón api-pagos: se cae, se reinicia solo y vuelve, y el resto de los servicios nunca se entera. Botón base de datos: es el caso más delicado, porque las 5 APIs usan la misma base y mientras está caída todas dan error, aunque sigan corriendo. La base se reinicia sola y los datos no se pierden porque están en un volumen aparte; cuando vuelve, las APIs se reconectan. Si preguntan: es el único punto donde una caída afecta a todos, por eso los próximos pasos son backups y una base administrada con réplica. Ojo: depends_on solo ordena el arranque, no protege si la base se cae en el medio. A la izquierda, lo que ya nos protege, del lado de Docker Compose: el contenedor se reinicia solo (restart: always), las APIs arrancan recién cuando la base está sana (healthcheck y depends_on), cada servicio tiene límites de CPU y memoria, y volver atrás es desplegar la versión anterior: cada imagen aprobada tiene su número. Ansible acompaña en el deploy: espera a que todo esté sano y lo verifica por HTTPS. A la derecha, el impacto: escribir valores de ejemplo en los tres casilleros (Enter o Esc para salir) y el total se calcula solo. Aclarar que es una estimación con supuestos. Abajo, ser honestos: hoy todo corre en un solo servidor, es un punto único de falla. El próximo paso es una segunda instancia en otra zona con balanceador y alertas de monitoreo.

PLAY [Pipeline · CI/CD y seguridad] ********************************

TASK [Cómo llega un cambio a producción] *****************************

Cómo llega un cambio a producción

ok:(item=validar)Lint de cada Dockerfile

ok:(item=revisar_seguridad)Checkov revisa cada Dockerfile antes de construirSEGURIDAD

ok:(item=construir)Una imagen por servicio, etiquetada con su commit

ok:(item=escanear)Trivy analiza cada imagen construidaSEGURIDAD

ok:(item=publicar)Solo las aprobadas reciben versión (ej. 1.0.0)

pending:(item=desplegar)Llamar a los playbooks de Ansible · a integrar

En paralelo

Los 8 servicios avanzan cada uno por su cuenta: si uno falla, no frena al resto.

Cuándo corre

Con cambios en dev y main. A main solo se llega por merge request desde dev.

Runner

Runner compartido del laboratorio, sin Docker-in-Docker. [confirmar por qué]

ok: [gitlab-pipeline] => etapas: 6 · servicios en paralelo: 8

TASK [Controles de seguridad en cada corrida] ************************

Cuatro controles en cada corrida

role: hadolint

Buenas prácticas en los Dockerfiles

Encontró: chequeos de salud mal escritos en 5 servicios. Corregido.

role: checkov

Seguridad del Dockerfile antes de construir

Encontró: la base de datos no avisaba cuándo estaba lista. Corregido.

role: trivy

Vulnerabilidades y secretos en cada imagen

Encontró: 12 vulnerabilidades críticas con parche en 4 de las 8 imágenes.

role: reporte

Un resumen descargable por corrida

Todos los hallazgos, por servicio, quedan como artifact del pipeline.

ok: [gitlab-pipeline] => controles: 4 · se ejecutan en cada corrida

TASK [Promover imagen a producción] *********************************

Si una imagen tiene una vulnerabilidad crítica con parche, no llega a producción

# la condición que decide si una imagen recibe su versión when: - trivy.criticas_con_parche == 0 - checkov.chequeos_fallidos == 0

1

La imagen se construye y se guarda con su commit, para poder revisarla.

2

El pipeline queda en advertencia, visible para todo el equipo.

3

No recibe versión: producción sigue con la última aprobada.

skipping: [imagen-con-criticas] => producción sigue con la última imagen aprobada

TASK [Corregir vulnerabilidades críticas] ****************************

Qué encontramos y cómo lo resolvimos

12 → 0

vulnerabilidades críticas con parche, en 4 de las 8 imágenes

excepciones: 0

SERVICIO	QUÉ TENÍA	QUÉ HICIMOS
clientes	Librería de base de datos con riesgo de inyección SQL	Actualizada a la versión corregida
facturas	9 críticas en el framework web	Migrada a la nueva versión mayor del framework
db	Un componente que no usamos, con una falla de TLS	Eliminado de la imagen
web	Librería de compresión desactualizada	Paquetes de la imagen base actualizados

changed: [4 imágenes] => críticas con parche: 12 → 0 · sin excepciones

TASK [Versionar cada imagen] *****************************************

Cada imagen tiene su número de versión

RAMA	ETIQUETA	EJEMPLO	PARA QUÉ
todas	El commit que la generó	:a1b2c3d	Saber exactamente de qué código salió
dev	Versión de prueba	:1.0.0-dev.57	Probar antes de liberar
main	Versión liberada	:1.0.0	Lo que corre en producción

SOLO LAS APROBADAS

Una imagen que no pasa los controles queda solo con su commit.

NO SE PISA

Una versión liberada nunca se reemplaza: para un cambio, se sube el número.

VUELTA ATRÁS

Volver a producción anterior es desplegar la versión anterior por su número.

changed: [imágenes] => latest: ya no se usa · versión: 1.0.0

TASK [Aplicar mejoras pendientes de la Parte 1] ***********************

Qué resolvimos de la Parte 1

changed:Plantilla de CloudFormation → Terraform

changed:Scripts por SSH desde una computadora → Ansible, con playbooks idempotentes

changed:Secretos en Parameter Store como variante → único camino

changed:Base sin chequeo de salud → las APIs esperan a que esté lista

changed:Sin escaneo automático → Checkov y Trivy en cada corrida

changed:Imágenes solo con latest → versión semántica que no se pisa

pending:Un usuario de base de datos por microservicio

pending:Más de un servidor

changed: [parte-1] => resueltas: 6 · pendientes: 2

PLAY RECAP *******************************************************************

cto-fintech-nova : ok=3 changed=2 failed=0 skipped=0 rescued=0 aws : ok=2 changed=0 failed=0 skipped=0 rescued=1 ec2-fintech-nova : ok=3 changed=0 failed=0 skipped=0 rescued=0 gitlab-pipeline : ok=4 changed=2 failed=0 skipped=1 rescued=0

PRÓXIMAS TASKS

pending:Desplegar desde el pipeline llamando a Ansible

pending:Registry de GitLab con token de solo lectura

pending:Estado de Terraform fuera de las computadoras

pending:Segunda instancia y alertas de monitoreo

¡Muchas Gracias!

¿Preguntas?

grupo-15@fintech-nova:~/tp-2$