Desplegando microservicios con GitHub Actions
Contenido del curso
Ulises Serrano Pérez
Royer Guerrero Pinilla
Royer Guerrero Pinilla
Geisemberg Marcos Zamora Yuave
Geisemberg Marcos Zamora Yuave
Geisemberg Marcos Zamora Yuave
Eso es cierto todas las clases esta ya diseñadas y muy pocas veces tiene errores. Pero si tiene razón Amin, gran parte de implementar esto y otras arquitecturas es resolver muchos problemas sobre la marcha. Pero el resultado de esa curva de aprendizaje siempre va a valer la pena.
Es cierto que las clases son verlo copiar y pegar... y los fundamentos sobre los microservicios quedaron en el garete
Es chistoso que explique eso quien que no se dedique al desarrollo de software sabe que nada sale a la primera casi nunca. Asi que explica lo que ya sabemos
¿Qué pasa si mi microservicio es interno?
Si tienes un microservicio que solo procesa datos en segundo plano (como un worker que lee de una cola de mensajes) y no necesita recibir peticiones HTTP de los usuarios, debes cerrar sus puertas al exterior. Al replicar tu archivo de despliegue, es crucial eliminar cualquier configuración de puertos externos o reglas de Ingress. En términos de seguridad, esto es como tener una bóveda dentro de un banco: los empleados (otros microservicios) pueden acceder a ella mediante la red interna privada, pero no hay una puerta directa desde la calle. Al quitar la exposición pública, reduces drásticamente la superficie de ataque de tu aplicación y optimizas el consumo de recursos en tu entorno de nube.
¿Cómo replicar Actions para múltiples microservicios rápidamente?
Para escalar tu integración continua sin reinventar la rueda, la estrategia más efectiva es usar plantillas base. En lugar de escribir cada flujo desde cero, tomas un archivo .yml funcional y lo duplicas, modificando únicamente las variables de entorno específicas de cada proyecto. Piensa en esto como un molde de galletas: la estructura principal (el proceso de build y deploy) es la misma, pero el resultado cambia al actualizar el nombre de la imagen de Docker, la ruta del código fuente y las credenciales. Es vital revisar meticulosamente las rutas de los directorios (working-directory) para asegurar que GitHub Actions apunte a la carpeta correcta del microservicio correspondiente. Esta práctica no solo ahorra horas de configuración, sino que estandariza el proceso de despliegue en toda tu arquitectura.
¿Cuál es la mejor forma de probar despliegues?
La forma más ágil de validar que tus microservicios están operando correctamente en la nube es utilizar herramientas integradas en tu editor, como la extensión REST Client. En lugar de depender de interfaces gráficas pesadas, puedes mantener archivos .http o .rest directamente en tu repositorio junto a tu código. Al actualizar la URL de tu entorno local por la nueva URL pública generada por tu plataforma en la nube, puedes disparar peticiones reales con un solo clic. Esto te permite verificar rápidamente si el enrutamiento funciona y si la comunicación con la base de datos remota es exitosa. Es una práctica excelente mantener estas colecciones de peticiones versionadas para que cualquier desarrollador del equipo pueda probar los endpoints inmediatamente después de un despliegue.
