Curso de Docker Avanzado

Despliegue automático en Azure con GitHub Actions

Curso de Docker Avanzado

Contenido del curso

Optimización Avanzada en Docker

Orquestación

Despliegue automático en Azure con GitHub Actions

Resumen

Automatizar el despliegue de una imagen Docker hacia Azure Web App mediante GitHub Actions convierte tu pipeline en un flujo CI/CD real, donde cada commit publica tu contenedor sin pasos manuales. Esta guía es para desarrolladores que ya tienen integración continua y quieren cerrar el ciclo con despliegue continuo.

El objetivo final es que un simple git push ejecute docker build, docker push y publique el contenedor en producción, eliminando tres tareas rutinarias del flujo diario.

¿Qué diferencia hay entre CI y CD en este flujo?

La integración continua (CI) se encarga de construir y validar la imagen Docker cada vez que hay un cambio. El despliegue continuo (CD) toma esa imagen y la publica automáticamente en un entorno accesible.

¿Qué es CD en GitHub Actions? Es el paso que toma la imagen ya publicada en Docker Hub y la despliega en un servicio como Azure Web App, garantizando que cada commit se refleje en tu aplicación viva.

Hasta el paso anterior solo tenías CI funcionando. Ahora vas a sumar el último eslabón para que el ciclo sea verdaderamente CI/CD [00:15].

¿Cómo crear una Azure Web App para contenedores?

El primer paso es preparar el destino del despliegue dentro del portal de Azure. Aquí creas una Web App configurada para correr contenedores Linux.

Los parámetros clave durante la creación son:

  • Grupo de recursos: el mismo que usas para tus contenedores.
  • Identificador de la app: en este caso amin-es-webapp.
  • Tipo de publicación: contenedor sobre Linux.
  • Región: East US 2.
  • Plan de servicio: nivel básico, suficiente para pruebas y mucho más económico que el premium [01:20].

En la sección de container, conectas la imagen desde Docker Hub marcando el acceso como público, escribiendo el nombre de la imagen aminespinoza/website-platzi y el tag latest. No necesitas comandos de entrada ni inyección de red, pero sí dejas habilitado el acceso público para que la app sea alcanzable desde cualquier lado [02:30].

¿Por qué habilitar el basic auth en la configuración?

Una vez creado el recurso, vas a Configuración y activas las dos opciones de basic authentication en On. Sin esto, tu GitHub Action no podrá autenticarse contra la Web App al momento del despliegue [03:45].

Luego, en Deployment Center, confirmas que la fuente sea un container registry y habilitas Continuous deployment. Esta configuración se hace una sola vez y deja la app lista para recibir despliegues automáticos.

¿Cómo conectar el publish profile con GitHub Actions?

El publish profile es el archivo XML que contiene las credenciales que GitHub necesita para desplegar en tu Web App. Lo descargas desde el Deployment Center y lo abres con un bloc de notas.

¿Qué es el Azure publish profile? Es un archivo XML con las credenciales de despliegue de tu Web App. Debes mantenerlo restringido porque expone el acceso completo a tu sitio.

Dentro de tu repositorio en GitHub, vas a Settings, luego a Secrets and variables, Actions, y creas un nuevo secreto llamado AZURE_WEB_APP_PUBLISH_PROFILE. Pegas todo el contenido XML del archivo descargado y lo guardas [05:20].

¿Cómo modificar el workflow YAML para el despliegue?

En tu repositorio editas el archivo docker.yaml dentro de la carpeta .github/workflows. Después del paso que publica la imagen, agregas un nuevo step que usa la acción azure/webapps-deploy con tres datos:

  • app-name: el nombre de tu Web App, por ejemplo amin-es-webapp.
  • publish-profile: el secreto que acabas de crear, referenciado desde secrets.
  • images: la misma imagen publicada, en formato aminespinoza/website-platzi:latest.

Guardas los cambios y el workflow queda completo. Desde este punto, cada commit dispara la cadena completa: build, push y deploy.

¿Cómo validar que el despliegue automático funciona?

Para probarlo, modificas algo visible en tu Dockerfile, por ejemplo cambias el texto de la página de inicio a Desde GitHub Actions. Luego ejecutas en la terminal:

bash git status git add . git commit -m "nuevo Dockerfile" git pull --rebase git push

El git pull --rebase es importante la primera vez que sincronizas cambios remotos creados por GitHub, como los workflows [07:50].

En la pestaña Actions de tu repositorio ves correr el job Docker CI. La línea 10 confirma que el despliegue fue exitoso y la línea 11 muestra la URL pública de la app, que es la misma que aparece en el portal de Azure.

¿Por qué la nueva versión tarda en aparecer?

Al abrir la URL es normal ver la versión anterior durante uno o dos minutos. Azure necesita tiempo para sincronizar la nueva imagen desde Docker Hub. Refrescando la página, en pocos minutos aparece el cambio aplicado.

Con esta automatización en marcha, trabajar en equipo se vuelve más simple: haces commit, haces push y el resto del pipeline se encarga solo. Te quitas de encima tres pasos repetitivos y dejas que la infraestructura responda al ritmo de tu código.

¿Ya probaste integrar Azure Web App con tu pipeline de GitHub Actions? Cuéntame en los comentarios qué obstáculos encontraste al configurar el publish profile.