Automatizar el despliegue de contenedores con GitHub Actions y Docker Hub te permite publicar imágenes con cada push, sin compilar nada en local. Esta guía es para quienes ya manejan Docker y quieren dar el salto a integración continua aplicada a contenedores.
Cuando tienes muchos contenedores en producción, hacerlo manual se vuelve interminable. Por eso, configurar un workflow que construya y publique tus imágenes cada vez que haces commit ahorra horas de trabajo repetitivo.
¿Qué necesito antes de configurar un workflow de Docker en GitHub Actions?
Antes de tocar YAML, conviene tener listo el terreno. La idea es que tu repositorio tenga el Dockerfile en una ubicación clara y que GitHub pueda autenticarse contra Docker Hub.
¿Cómo organizo el Dockerfile dentro del repositorio?
Lo primero es crear una carpeta dedicada, por ejemplo ci, y colocar dentro un Dockerfile sencillo. En la clase se usa una imagen base de NGINX sirviendo un HTML mínimo, suficiente para validar el flujo [01:00].
Después subes los cambios con los comandos de siempre:
git status para ver la carpeta nueva.git add y git commit -m "carpeta CI agregada".git push para reflejar los cambios en GitHub.
Cuando el repositorio recibe la nueva carpeta, la pestaña Actions te sugiere plantillas, incluida una para Docker. Aun así, vale la pena armar el workflow manualmente para entender cada pieza.
¿Qué es un workflow en GitHub Actions? Es un archivo YAML, ubicado en .github/workflows, que define qué pasos automáticos ejecuta GitHub cuando ocurre un evento como un push a la rama main.
¿Cómo configuro los secrets de Docker Hub en GitHub?
Para que el agente pueda hacer login en Docker Hub, necesitas dos secrets dentro de tu repositorio: el username y un token de acceso personal. Nunca uses tu contraseña real.
¿Dónde encuentro mi username y cómo genero el token?
Tu username aparece en Docker Hub debajo de tu foto de perfil. En la clase es aminespinoza [04:30]. Ese valor lo guardas como secret en GitHub, en Settings > Security > Secrets > Actions, con un nombre en mayúsculas como DOCKERHUB_USERNAME.
El token lo generas así:
- Entra a la configuración de tu cuenta en Docker Hub.
- Busca Personal access tokens y crea uno nuevo.
- Asígnale un nombre descriptivo, por ejemplo Docker Actions.
- Dale permisos de leer, escribir y borrar.
- Copia el token de inmediato, porque no podrás volver a verlo [05:50].
Ese token lo pegas como otro secret, por ejemplo DOCKERHUB_TOKEN. Una práctica útil: escribe siempre los nombres de los secrets en mayúsculas, así los identificas rápido dentro del YAML.
¿Por qué usar un token y no la contraseña? El token tiene permisos limitados y se puede revocar sin cambiar tu contraseña, lo que reduce el riesgo si se filtra en algún log.
¿Cómo se construye y publica la imagen desde el workflow?
El archivo YAML define un job llamado Docker Build que corre sobre Ubuntu y se dispara con cada push a la rama main. Aunque comitear directo a main no es buena práctica en producción, en la clase se usa para acelerar la demo [07:40].
¿Qué pasos ejecuta el job de Docker Build?
El flujo se divide en etapas claras que reproducen lo que harías en tu terminal:
- Checkout del código: el agente extrae el contenido del repositorio para acceder al Dockerfile.
- Login a Docker Hub: usa los secrets
DOCKERHUB_USERNAME y el token configurados antes.
- Build de la imagen: ejecuta
docker build con la plataforma linux, el tag aminespinoza/websiteplatzi:latest y el parámetro -f ci/Dockerfile para apuntar al archivo correcto.
- Push a Docker Hub: publica con
docker push aminespinoza/websiteplatzi:latest.
Especificar la ruta con -f es clave cuando tu repositorio tiene varios Dockerfiles. Le dices al workflow exactamente cuál compilar.
¿Cómo verifico que el despliegue funcionó?
Después del commit, ve a la pestaña Actions. Verás un círculo amarillo mientras el job corre y los pasos se expanden uno a uno: build, push y un post login que limpia los archivos temporales [09:30].
Si todo salió bien, aparece una palomita verde. Al volver a Docker Hub y refrescar, la imagen websiteplatzi muestra una marca de actualización de hace menos de un minuto, confirmando que la automatización funcionó.
De aquí en adelante, cada push con cambios en tu Dockerfile dispara el mismo flujo. Ya no compilas en local ni publicas a mano: tu repositorio se vuelve la fuente única, y Docker Hub recibe las imágenes actualizadas en automático.
¿Has probado este flujo en tus propios proyectos? Cuéntame en los comentarios cómo te fue con la configuración de los secrets y qué optimizarías en el YAML.
