Despliegue automático de microservicios con GitHub Actions

Automatizar el despliegue de microservicios con GitHub Actions hacia Azure Container Apps elimina los clics manuales en el portal y convierte cada commit en un pipeline que compila, publica y despliega tu imagen Docker. Aquí verás cómo configurar el flujo, gestionar secretos y pasar variables de ambiente sin exponer tus credenciales.

Cómo conectar GitHub Actions con Azure Container Apps

La idea central es que un workflow tome el código de cada microservicio, construya la imagen, la publique en Docker Hub y la despliegue en una container app específica. Cada vez que hagas un commit a la rama main, el ciclo se ejecuta solo.

Lo primero que defines en el archivo YAML es un nombre claro del despliegue. Vas a crear un workflow por cada servicio porque mezclar todos en uno suele terminar mal cuando algo falla.

¿Por qué crear una GitHub Action por microservicio? Porque aislas fallos, identificas qué despliegue se está ejecutando y evitas que un error en un servicio bloquee a los demás.

Qué variables de ambiente necesitas declarar

En la cabecera del workflow se configuran cuatro variables que alimentan los pasos siguientes:

• El nombre del servicio que se despliega.
• El grupo de recursos de Azure.
• El nombre de la imagen que viajará a Docker Hub.
• El ambiente de container apps donde aterrizará el contenedor.

Después viene el clásico checkout del código. Y aquí aparece un detalle que no se puede pasar por alto: en la línea 19 se define la ruta del proyecto, por ejemplo microservicios/add-member. Si esa ruta está mal, todo el pipeline se rompe.

Cómo manejar secretos y credenciales sin exponerlos

El flujo continúa autenticándose contra Azure con credenciales guardadas en GitHub Secrets, compilando la imagen, iniciando sesión en Docker Hub y ejecutando docker push. Hasta aquí todo es estándar.

Lo crítico llega con el comando az containerapp, que recibe el nombre del servicio, la imagen, el grupo de recursos y el ambiente. Dentro de ese comando viajan las variables de ambiente que reemplazan al archivo appsettings.json.

¿Por qué no subir el archivo appsettings.json al repositorio? Porque contiene cadenas de conexión a Service Bus, queues, topics y SQL. Subirlo expone secretos y compromete la seguridad de tu infraestructura.

Por qué no incluir appsettings.json dentro de la imagen Docker

Una tentación común es copiar el appsettings.json dentro del Dockerfile. Mala idea. Estarías empaquetando tus credenciales dentro de la imagen, y cualquiera con acceso a ese contenedor podría leerlas.

La solución pasa por dos lugares:

1. Definir las variables de ambiente directamente en el workflow de GitHub Actions.
2. Guardar los valores sensibles, como la connection string, dentro de secrets del repositorio.

Así, cuando el workflow ejecuta el despliegue, inyecta esos valores como variables de ambiente al container app sin que nunca toquen el control de versiones.

Cómo leer variables de ambiente desde el código .NET

El puente entre el workflow y la aplicación se construye en Program.cs. En lugar de leer la cadena de conexión únicamente desde builder.Configuration, extiendes la lógica para que, si ese valor no existe, busque la variable de ambiente.

En entorno local el appsettings.json sí existe y la app lo usa. En el entorno de Docker no existe, así que la app cae al fallback de la variable de ambiente que el workflow inyectó. El mismo patrón aplica para el QueueName del Service Bus.

Después de eso, el workflow habilita el ingress y define el puerto por el que la container app se expone al exterior.

¿Qué pasa si la variable de ambiente no llega al contenedor? La aplicación no encuentra la cadena de conexión y falla al iniciar. Por eso conviene loguear ambos caminos: configuración local y variable de ambiente.

Cómo verificar que el despliegue funcionó

Con los cambios guardados y el push hecho directo a main, el pipeline arranca. Te vas a la pestaña Actions, seleccionas el workflow correspondiente, en este caso Add member deployment, y observas el avance paso a paso.

El orden esperado de ejecución es:

• Azure Login completado.
• Install AZ Container App Extension completado.
• Compilación de la imagen.
• Docker push hacia Docker Hub.
• Deploy Container App con un link de salida.

Ese link que aparece en el paso final es la URL pública de tu microservicio. La copias con Ctrl + C y la usas para probar el endpoint.

Cómo probar el endpoint sin Swagger

Como ya estás en un ambiente productivo entre comillas, Swagger deja de ser visible. La alternativa práctica es abrir el archivo .http que vive dentro del proyecto en Visual Studio, pegar la URL del despliegue y disparar las peticiones desde ahí. Eso te permite validar que el microservicio responde correctamente con la configuración inyectada por el workflow.

Queda un detalle nada menor: este mismo proceso, con su workflow propio, sus secretos y su archivo YAML, se repite para cada microservicio restante. Una vez replicado en todos, tienes un sistema de despliegue continuo donde cada commit mueve código a producción sin intervención manual.

¿Ya replicaste este flujo en alguno de tus proyectos? Cuéntame en los comentarios qué microservicio desplegaste primero.