Pruebas automáticas de Docker con GitHub Actions

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:50

Pruebas automáticas de Docker con GitHub Actions

Curso de Docker Avanzado

Clase 23 de 34

Clase 23 / 34

Recursos

Automatizar pruebas de contenedores Docker con GitHub Actions te permite validar imágenes antes de desplegarlas a producción, integrando DevOps y CI/CD en un solo flujo. Esto es útil para desarrolladores que ya manejan Docker y quieren llevar sus pipelines al siguiente nivel sin depender de pruebas manuales.

La clave está en entender que las limitantes no son técnicas, son de creatividad. Puedes encadenar tantos pasos como necesites, segmentar por carpetas o archivos, y diseñar el flujo a tu medida.

Cómo creo un workflow de testing en GitHub Actions desde cero

Antes de tocar código, conviene partir de un archivo limpio. Las plantillas suelen requerir más correcciones que un workflow escrito desde cero, así que empezar en blanco te da control total sobre la indentación de YAML, que es donde más errores aparecen.

El primer paso es crear un nuevo flujo dentro de la carpeta de actions, separado del workflow de CI que ya existe. A este nuevo archivo lo nombras Testing en lugar de Main, y defines:

El nombre del workflow.
La rama que lo dispara, en este caso Main.
El job principal, llamado docker-test.
El agente donde corre, que será Ubuntu.

Dejar una línea en blanco entre bloques no es obligatorio, pero ayuda a que el archivo se lea mejor cuando vuelves a revisarlo semanas después [01:30].

¿Por qué falla mi YAML por un espacio? Porque YAML usa la indentación para definir jerarquía. Un espacio de más rompe la estructura y GitHub Actions no puede interpretar el archivo. Revisa visualmente las líneas guía del editor.

Qué pasos necesita un job para probar un contenedor Docker

El flujo dentro del job docker-test sigue una secuencia lógica que replica lo que harías en tu terminal local, pero automatizado. Cada paso depende del anterior y, si uno falla, el workflow se detiene.

Checkout, build y run del contenedor

El primer paso siempre es el checkout del repositorio, que extrae todos los archivos para que el agente pueda trabajar con ellos. Después viene la configuración del motor de Docker dentro de la action, lo que prepara el entorno para construir y correr imágenes.

El tercer paso es Run Docker Container, donde ejecutas docker run sobre una imagen de Alpine. Aquí agregas parámetros que mantienen al contenedor esperando un evento, haciendo su vida persistente para que no se apague de inmediato y puedas ejecutar pruebas dentro [02:45].

Ejecutar pruebas dentro del contenedor con docker exec

El paso de pruebas usa docker exec para entrar al contenedor en ejecución. Hay un detalle crítico: Alpine no incluye Bash, así que debes invocar Shell en su lugar. Si intentas usar Bash, el comando falla.

Dentro del contenedor puedes:

Moverte a un directorio con cd y mkdir.
Generar un archivo de prueba con printf, por ejemplo ejemplo.txt.
Verificar que el archivo existe.
Salir del contenedor al terminar.

¿Qué es docker exec? Es el comando que ejecuta instrucciones dentro de un contenedor que ya está corriendo, sin necesidad de iniciar uno nuevo. Lo usas para inspeccionar, probar o modificar el entorno en vivo.

Cómo verifico que el workflow corrió bien en GitHub Actions

Una vez que guardas los cambios y los empujas a la rama Main, GitHub Actions dispara automáticamente las ejecuciones. En la pestaña Actions verás dos workflows corriendo en paralelo: el Docker CI original y el nuevo docker-test.

Al seleccionar la ejecución de docker-test puedes expandir cada paso para ver el log detallado. El proceso típico muestra:

Docker build configura y descarga la imagen.
La imagen se ejecuta como contenedor, indicando que no estaba disponible localmente.
El paso de pruebas muestra el comando solicitado y su salida.
Aparecen los movimientos entre carpetas y la creación del archivo ejemplo.txt.
El resultado final confirma que las pruebas pasaron [04:50].

La ejecución suele ser tan rápida que termina antes de que alcances a abrir el log. Eso es señal de que el pipeline está optimizado.

Por qué adaptar las pruebas al tipo de contenedor que uso

No todos los contenedores se prueban igual. La estrategia cambia según lo que estés desplegando, y aquí viene lo interesante: GitHub Actions no te impone un formato, tú defines qué validar.

Algunos ejemplos prácticos:

Si despliegas una API, puedes lanzar una sentencia curl para verificar que los endpoints responden.
Si corres un script, replicas la ejecución dentro del contenedor como en el ejemplo anterior.
Si trabajas con una base de datos, puedes correr queries de validación.

El punto es que cada imagen tiene su propio tipo de pruebas, y el workflow debe adaptarse a eso. Cuando confirmas que el contenedor funciona como esperas, puedes extender el mismo GitHub Action para que despliegue la imagen a la nube automáticamente.

La ganancia real es que dejas de ser tú quien prueba manualmente cada cambio. El pipeline lo hace por ti, en cada push, sin descanso. ¿Qué tipo de pruebas estás aplicando a tus contenedores hoy?

Optimización Avanzada en Docker

Optimización avanzada de Docker para cloud native

Docker productivo vs comandos básicos

Multi-stage builds en Docker con ASP.NET

Cómo escanear vulnerabilidades en imágenes Docker

Imágenes distroless: de 840 MB a 52 MB

Imágenes Docker para múltiples arquitecturas

Cómo funciona el caché en Docker builds

De 1.19 GB a 126 MB con Alpine

Qué es el build context en Docker

Docker Hub para compartir imágenes en la nube

Buenas Prácticas en Docker

Cómo reducir capas en Docker

Cómo usar .dockerignore para imágenes más pequeñas

Limpia Docker y recupera gigas con prune

Creando usuarios en Docker sin privilegios root

6 prácticas Docker para imágenes listas para producción

Instalación y Configuración en Entornos Multiplataforma

Publica imágenes Docker en Azure Container Registry

Azure Container Registry hacia Container App

Redes Avanzadas y Balanceo de Carga

Redes en Docker: los 5 modelos explicados

Cómo funcionan los puertos en Docker

Balanceo de carga con NGINX en Docker

Automatización de CI/CD

Optimizar Dockerfile con comandos RUN y scripts

Automatiza Docker con GitHub Actions

Pruebas automáticas de Docker con GitHub Actions

Despliegue automático en Azure con GitHub Actions

Orquestación

Docker Compose: balanceo de cargas automatizado

Estructura y plantilla de Docker Compose YAML

Volúmenes Docker: bind vs nombrados

docker-compose down vs Control C en apagado

Docker Swarm para principiantes paso a paso

Despliegue Docker Swarm con réplicas de Nginx

Costos ocultos de contenedores en la nube

Cómo habilitar Kubernetes en Docker Desktop

Planes y límites de Docker Hub en producción

Develop

Dev containers en VS Code con Docker

Pruebas automáticas de Docker con GitHub Actions