La imagen aurora-api:2.0.0 es correcta, pero la construyes tú, en tu portátil, con tu caché y tu git status. Esta lección quita al humano de en medio: cada git push dispara una cadena que ejecuta las pruebas, construye para dos arquitecturas, escanea, firma, publica y despliega, sin que nadie tenga que acordarse de nada.

1. CI, delivery y deployment: tres conceptos, dos siglas
2. Por qué Docker encaja: el artefacto es la imagen
3. Anatomía del pipeline
4. Pruebas dentro de contenedores con Compose
5. La etapa pruebas del Dockerfile y --target
6. El pipeline de Aurora Libros: disparadores y permisos
7. Etiquetado automático con metadata-action
8. Construcción multiarquitectura con caché gha
9. Escaneo con Trivy que rompe la build
10. Firma keyless, SBOM y procedencia
11. El pipeline equivalente en GitLab CI
12. Docker-in-Docker frente al socket montado
13. Gestión de credenciales: OIDC y tokens efímeros
14. Versionado automático desde las etiquetas de Git
15. El despliegue automatizado

Advertencia. Un runner de CI con acceso a tu registro y a tus servidores es una pieza de infraestructura crítica: quien controle el pipeline puede publicar y desplegar cualquier cosa. Los permisos de los runners, el alcance de los tokens y el acceso SSH a los entornos deben definirse y revisarse con el responsable de infraestructura y de seguridad de tu organización.

Las dos últimas comparten la abreviatura CD y se confunden constantemente. La diferencia práctica es un botón: en delivery, la imagen está lista y espera un apruebo; en deployment, cada merge a main que pase todas las puertas llega a producción sola. Aurora Libros hará delivery hacia producción y deployment hacia staging: es la combinación más habitual y la más sensata mientras la cobertura de pruebas no dé para confiar a ciegas.

Antes de los contenedores, el artefacto de CI era un .jar, un .zip o un tarball, y el entorno donde corría se preparaba por separado: de ahí venía el "en mi máquina funciona", porque el artefacto viajaba y el entorno no. Con Docker, el artefacto incluye su entorno, y eso desbloquea tres propiedades que hacen fiable un pipeline:

• Inmutabilidad. El digest identifica un contenido exacto: sha256:a1b2... es la misma cosa en CI, en staging y en producción, para siempre.
• Promoción sin reconstruir. Se promociona retiquetando. Reconstruir para producción significa desplegar un artefacto que nadie ha probado.
• Paridad de entornos. El contenedor que pasó las pruebas es, byte a byte, el que atiende a los clientes.

La regla que resume el módulo: construir una vez, desplegar muchas. Un commit produce una imagen, esa imagen tiene un digest, y ese digest es el que se promociona a staging y a producción. Si tu pipeline tiene un docker build por entorno, tiene un fallo de diseño.

El orden no es arbitrario: lo barato y lo que más falla, primero. Un lint de 20 segundos que detecta el error evita gastar cuatro minutos de build multiarquitectura. Es el mismo principio de la caché de capas de 02-02, aplicado al pipeline.

Probar contra una base de datos real, y no contra un mock, es lo que distingue una prueba útil de una que aprueba código roto. Con Compose es trivial y, sobre todo, idéntico en tu portátil y en el runner.

Las dos banderas son el corazón del asunto y conviene entenderlas bien:

• --abort-on-container-exit para toda la pila en cuanto un contenedor termina. Sin ella, las pruebas acaban y PostgreSQL sigue vivo: el comando nunca retorna y el job se queda colgado hasta el timeout.
• --exit-code-from pruebas hace que el código de salida de docker compose sea el del contenedor de pruebas, no el de la operación de Compose. Sin ella, el comando devuelve 0 aunque las pruebas fallen, y el pipeline se pone verde con el código roto. Este es, con diferencia, el error más frecuente de esta lección.

El tmpfs sobre el directorio de datos de PostgreSQL merece una nota: en pruebas no necesitas durabilidad, así que poner los datos en RAM elimina la escritura a disco y suele reducir la suite entre un 30 % y un 50 %. Nunca, jamás, en producción.

El Dockerfile de 06-01 ya tenía la etapa preparada. Ejecutarla sola es un --target:

Aurora Libros usa las dos primeras a la vez: compose.pruebas.yaml construye con target: pruebas. Y hay un beneficio de caché nada menor: la etapa deps que instala node_modules es común a las pruebas y a la imagen final, así que el build de producción reutiliza esas capas y no reinstala nada.

Sobre los disparadores: los pull requests ejecutan las pruebas y construyen sin publicar, porque una rama de nadie no debe poder subir una imagen al registro. Los push a main publican con la etiqueta edge y despliegan a staging. Las etiquetas v*.*.* producen la versión SemVer publicable.

Esta acción sustituye el guion de sed y git describe que todo el mundo acaba escribiendo. De la etiqueta v2.0.0 deduce sola las cuatro etiquetas móviles y genera además las etiquetas OCI de 06-01 con la fecha, el commit y la URL del repositorio, sin que tengas que pasarlas como --build-arg.

El type=sha es el más importante de la lista aunque parezca el más aburrido: cada build produce una etiqueta única e irrepetible, así que siempre puedes referirte a una construcción concreta aunque latest y 2.0 se hayan movido diez veces.

Los dos parámetros de caché son la diferencia entre un pipeline usable y uno insoportable. Sin ellos, cada ejecución arranca con una caché vacía —el runner es una máquina nueva— y npm ci se ejecuta entero dos veces, una por arquitectura. Con type=gha, BuildKit guarda las capas en la caché de GitHub Actions y las recupera en el siguiente build.

mode=max guarda también las capas intermedias de las etapas previas —incluidas deps y deps-dev—, así que ocupa más caché pero acierta muchísimo más. El scope evita que dos workflows distintos se pisen las entradas. Y un aviso operativo: la caché de GitHub Actions tiene un límite de 10 GB por repositorio y expulsa por antigüedad, así que un mode=max con muchas ramas puede desalojar entradas útiles.

El escaneo se hace por digest, no por etiqueta: garantiza que analizas exactamente la imagen que acabas de construir y no otra que alguien haya publicado con el mismo nombre entretanto.

La estructura en dos pasos es deliberada. El primero recoge todo (críticas y altas) y lo sube a la pestaña de seguridad para tener visibilidad; el segundo, mucho más estricto, es la puerta: solo rompe ante críticas con parche disponible. Ese ignore-unfixed no es relajación, es pragmatismo: bloquear los despliegues por una CVE que nadie ha corregido todavía no mejora tu seguridad, solo impide que publiques la corrección de otro fallo. Cuál es el umbral aceptable para tu organización lo decide su política de seguridad, no este curso.

La firma keyless de 05-03 encaja aquí como un guante. No hay clave privada que guardar, rotar ni filtrar: Cosign pide un token OIDC de corta vida a GitHub, obtiene un certificado efímero de Fulcio y registra la firma en el log público de transparencia Rekor. El certificado caduca en minutos; lo que queda es la prueba, verificable por cualquiera:

Fíjate en lo que verifica esa identidad: no dice "está firmada", dice "la construyó ese workflow, de ese repositorio". Una imagen firmada desde el portátil de alguien no pasa esa comprobación. Junto con el provenance: mode=max y el sbom: true del paso anterior, tienes las tres piezas de la cadena de suministro: qué lleva dentro (SBOM), quién y cómo la construyó (procedencia) y que nadie la ha tocado desde entonces (firma).

La caché es la diferencia práctica más visible: GitHub tiene un backend propio, mientras que en GitLab lo habitual es guardar la caché en el propio registro con type=registry, que además funciona en cualquier proveedor.

Para construir imágenes, el runner necesita acceso a un daemon. Hay tres formas, y no son equivalentes en seguridad.

Las dos primeras filas dicen lo mismo con palabras distintas: cualquier job puede tomar el control del runner. Con DinD, porque el contenedor privilegiado tiene todas las capacidades. Con el socket montado, porque quien habla con el daemon puede lanzar docker run -v /:/host --privileged y leer o modificar el disco entero del anfitrión, incluidas las credenciales de los demás pipelines.

En un repositorio privado con colaboradores de confianza, cualquiera de las dos es la práctica común. En cuanto aceptes pull requests de terceros, el socket montado es inaceptable: un PR malicioso que modifique el workflow se lleva tus secretos. Las alternativas son runners efímeros de un solo uso (lo que hacen los runners alojados de GitHub) o construir sin daemon con BuildKit rootless.

El GITHUB_TOKEN no es un secreto que hayas creado: GitHub lo genera al empezar la ejecución, con exactamente los permisos del bloque permissions:, y lo invalida al terminar. Robado media hora después, no vale nada.

La regla que nunca se rompe es la de no imprimir un secreto. Los proveedores enmascaran los valores conocidos y muestran ***, pero el enmascarado se salta con facilidad: echo $CLAVE | base64 sale en claro, y un set -x en un script bash imprime cada comando con sus argumentos. Por eso las credenciales se pasan siempre por stdin (--password-stdin) y nunca como argumento de línea de comandos, que además queda visible en la lista de procesos del runner.

metadata-action traduce esa etiqueta a las cuatro de la imagen sin intervención:

Las dos filas que nunca se mueven son las que sirven para producción; las móviles son cómodas para desarrollo y peligrosas en despliegues. El compose.prod.yaml de Aurora Libros fija el digest, con lo que ni siquiera depende de que 2.0.0 siga apuntando a lo mismo.

Cuatro detalles que hacen que esto sea un despliegue y no una ruleta. El --wait (que ya usabas en el onboarding) espera a que los healthcheck pasen y devuelve error si no lo hacen, así que un despliegue roto pone el job en rojo en vez de dejarte un servicio caído en silencio. El set -euo pipefail corta a la primera línea que falle. El usuario despliegue no es root y solo puede tocar ese directorio. Y se despliega por digest, no por etiqueta: el up -d arranca exactamente la imagen que acaba de pasar las pruebas.

Aun así, esto es un despliegue de una sola máquina: durante unos segundos el servicio se recrea y no hay nadie sirviendo. A partir de 06-03 el paso final deja de ser un docker compose up remoto y pasa a ser una instrucción al orquestador, que sustituye las réplicas de una en una sin cortar el servicio.

• Olvidar --exit-code-from. El pipeline se pone verde con las pruebas en rojo, que es peor que no tener pruebas: da confianza falsa. Compruébalo a propósito rompiendo una prueba.
• Reconstruir la imagen en el job de despliegue. Rompe la trazabilidad y despliega algo que nadie ha probado. Se promociona por digest.
• Construir sin caché remota. Un pipeline de cuatro minutos por cambio hace que la gente deje de hacer push pequeños, y eso empeora todo lo demás.
• Escanear por etiqueta en vez de por digest. Analizas una imagen que puede no ser la tuya. Usa siempre imagen@sha256:....
• exit-code: 1 con todas las severidades. El pipeline se rompe cada mañana por una CVE baja sin parche, y la gente aprende a saltarse la puerta. Sé estricto donde importa.
• Publicar desde pull requests. Cualquiera que abra un PR puede subir una imagen a tu registro: condiciona push: al evento. Y nunca pases secretos como argumentos, que aparecen en ps dentro del runner y en muchos logs; siempre --password-stdin.
• Consejo: haz el pipeline reproducible en local. Si docker compose -f compose.pruebas.yaml up es lo mismo que ejecuta CI, depurar un fallo del pipeline no requiere veinte commits de prueba.
• Consejo: usa concurrency con cancel-in-progress. Diez pushes seguidos no deben lanzar diez builds multiarquitectura; solo importa el último.

Ejercicio 1. Demuestra el peligro de --exit-code-from: rompe deliberadamente una prueba de aurora-api y ejecuta la pila de pruebas con y sin esa bandera, comparando los códigos de salida. Explica qué habría hecho el pipeline en cada caso.

Ejercicio 2. Mide el efecto de la caché remota: ejecuta el pipeline tres veces (frío, con caché y con caché tras un cambio solo en src/) y construye la tabla de tiempos. Explica por qué el tercer caso es el más rápido.

Ejercicio 3. Verifica la cadena de suministro completa de una imagen publicada: comprueba la firma exigiendo que provenga de tu workflow, extrae el SBOM y localiza el commit exacto que la generó.

Solución 1.

Los dos códigos de salida, ante exactamente la misma prueba fallida, resumen el ejercicio:

Lo perverso del primer caso es que el fallo sí aparece en el log, con su AssertionError y todo, pero nadie lo lee: la marca verde dice que todo está bien. Sin la bandera, docker compose up informa de si él pudo levantar la pila —y pudo—, no de si el contenedor de pruebas terminó satisfecho.

De ahí una práctica que merece la pena adoptar: la primera vez que montas un pipeline, rómpelo a propósito. Un pipeline que nunca has visto fallar no es un pipeline verde, es un pipeline sin comprobar.

Solución 2.

El tercer caso es el más rápido por la misma razón que estudiaste en 02-02, ahora aplicada a una máquina distinta cada vez. El Dockerfile de 06-01 copia primero package.json y package-lock.json, ejecuta npm ci, y solo después copia src/. Si únicamente cambia el código fuente, la capa de npm ci sigue siendo válida y BuildKit la trae desde la caché de GitHub en lugar de reinstalar 180 paquetes.

Lo que hace posible que un runner nuevo aproveche el trabajo del anterior es cache-from: type=gha: el runner es efímero, pero la caché no. Sin ella, las tres columnas de la tabla darían 4 min 35 s.

Un matiz importante para no engañarte con el número: los 41 segundos son de dos arquitecturas. La construcción arm64 corre bajo emulación QEMU y es unas tres veces más lenta que la nativa; sin caché, ese solo hecho añadiría más de dos minutos.

Solución 3.

Las comprobaciones responden a preguntas distintas, y juntas cierran el círculo:

El dato decisivo es el Subject, y conviene detenerse en él: no dice "alguien firmó esta imagen", dice qué workflow, de qué repositorio y desde qué referencia de Git la construyó. Si un atacante consiguiera publicar una imagen en tu registro con la etiqueta 2.0.0, la firma no verificaría contra esa identidad y el despliegue debería rechazarla. Esa comprobación es la que se automatiza en el clúster con una política de admisión.

Y el par SBOM + revision es lo que convierte una alerta de seguridad en trabajo de diez minutos: cuando se publique la próxima CVE crítica de una librería, cosign download sbom te dice en segundos si tu imagen la incluye y en qué versión, y la etiqueta revision te lleva al commit exacto sobre el que aplicar la corrección.

El camino del commit a la imagen publicada ya no lo recorres tú. Distingues la integración continua de la entrega y del despliegue continuos —tres conceptos y dos siglas— y sabes por qué Aurora Libros hace deployment a staging y delivery a producción. Has interiorizado la regla que sostiene todo el módulo: construir una vez y desplegar muchas, porque el artefacto es la imagen y su digest es el mismo objeto en todos los entornos; un docker build por entorno es un fallo de diseño, no una comodidad.

Las pruebas corren contra un PostgreSQL y un Redis reales en una pila efímera con los datos en tmpfs, y sabes que --abort-on-container-exit sin --exit-code-from produce el peor resultado posible: un pipeline verde sobre pruebas rojas, que has provocado a propósito para verlo. El workflow completo de GitHub Actions encadena lint y pruebas, metadata-action traduciendo v2.0.0 a cuatro etiquetas más el sha- irrepetible, build-push-action construyendo para amd64 y arm64 con cache-to: type=gha,mode=max —que llevó el build de 4 min 35 s a 41 s cuando solo cambia src/—, Trivy informando de todo y rompiendo solo ante críticas con parche disponible, y la firma keyless de Cosign que no obliga a custodiar ninguna clave privada. Has verificado la cadena entera desde fuera: firma válida, Subject que nombra el workflow y la etiqueta de Git que la produjo, SBOM con las versiones de cada paquete y la etiqueta OCI revision con el commit exacto.

Conoces también el equivalente en GitLab CI con su tabla de correspondencias, el compromiso real entre Docker-in-Docker y el socket montado —donde ambas opciones significan, dicho sin rodeos, que un job puede tomar el control del runner—, y las reglas de credenciales: tokens efímeros con permisos por job, OIDC en lugar de contraseñas estáticas y nada de secretos por línea de comandos. El paso final, por ahora, es un docker compose pull && up -d --wait remoto por SSH desplegando por digest.

Y ahí está el límite. Ese despliegue tiene un hueco de segundos en el que nadie sirve, corre en una sola máquina y, si esa máquina se apaga, Aurora Libros desaparece de internet. En la siguiente lección, Orquestando Contenedores con Docker Swarm, montarás tu primer clúster: varios nodos con managers y workers, redes overlay que conectan contenedores de máquinas distintas, servicios que se reprograman solos cuando un nodo cae, y el compose.yaml que ya conoces desplegado como stack con docker stack deploy.