Introducción: La importancia del CI/CD y del despliegue automático

El despliegue automático, es decir, CI/CD (Integración Continua/Entrega Continua), se está convirtiendo en una necesidad, no en una opción, para un flujo de trabajo de desarrollo eficiente. Si el proceso de construcción, pruebas y despliegue se realiza automáticamente al hacer un push de código en GitHub, se puede aumentar drásticamente la productividad del desarrollo.

Existen varias maneras de implementar este despliegue automático, pero las más representativas son utilizar GitHub Actions que GitHub ofrece por sí mismo y usar la función de Webhook de GitHub para implementar la lógica de despliegue directamente.

¿Por qué implementar Webhook directamente en lugar de utilizar GitHub Actions?

La escena de un gato de GitHub lanzando un avión de papel Webhook a Tux

GitHub Actions es sin duda una herramienta de CI/CD poderosa y conveniente. Permite definir flujos de trabajo complejos en solo unas pocas líneas de archivo YAML y automatizar muchos procesos como construcción, pruebas y despliegue a través de diversas acciones en su marketplace. No se puede negar que GitHub Actions es una excelente opción para la mayoría de los proyectos.

Sin embargo, GitHub Actions no siempre es la mejor elección en todos los casos. Especialmente para los desarrolladores que se encuentran en las siguientes situaciones, la implementación directa usando GitHub Webhook puede ser mucho más atractiva.

  • Desarrolladores individuales o equipos pequeños sensibles a los costos: GitHub Actions es prácticamente ilimitado y gratuito para repositorios públicos, pero para repositorios privados se incurrirá en cargos si se supera una cierta cantidad de minutos y almacenamiento en la asignación gratuita. Si quiere evitar por completo la posibilidad de costos inesperados, la implementación directa es la respuesta.

  • Desarrolladores que están operando un servidor de staging propio, como Raspberry Pi 5: Si ya posee un servidor físico (incluyendo VPS o instancias en la nube), entonces es más eficiente aprovechar al máximo los recursos de su propio servidor en lugar de alquilar el entorno virtual (Runner) de GitHub. Recibir y desplegar el código directamente desde su servidor es más rentable y ventajoso en términos de utilización de recursos.

  • Desarrolladores que desean un control total y libertad sobre la lógica de despliegue: GitHub Actions utiliza flujos de trabajo y acciones estandarizadas, pero al implementar Webhooks directamente, se puede diseñar y controlar cada parte del script de despliegue como desee. Esto es ventajoso cuando se requieren lógicas personalizadas complejas especializadas para entornos específicos o una integración perfecta con pipelines existentes.

En esta serie, abordaremos cómo implementar la lógica de despliegue directamente en mi servidor usando GitHub Webhook para quienes se encuentren en estas situaciones. Nos dirigimos a desarrolladores de Python y planeamos usar un marco web simple pero poderoso, FastAPI, para construir el endpoint de Webhook. Aunque DRF (Django REST Framework) es una excelente opción, consideramos que FastAPI es la mejor elección para esta lógica muy ligera que solo procesa las solicitudes de Webhook. No es necesario conducir un coche deportivo solo para ir al supermercado; un coche pequeño es suficiente.

Elementos básicos necesarios para construir un sistema de despliegue automático

La implementación real comenzará en el siguiente capítulo. En este artículo, organizaremos los elementos que necesitará preparar de antemano para una progresión fluida.

  1. Repositorio de GitHub:

    • Necesita un repositorio de GitHub que contenga un proyecto de Python en el que desee aplicar el despliegue automático. (No importa si es público o privado)

    • El despliegue comenzará cada vez que haga push de código a este repositorio.

  2. Servidor de staging (Servidor Auto-alojado):

    • Necesita un servidor real donde se realizará el despliegue. Raspberry Pi 5, un VPS personal (Servidor Privado Virtual) o una instancia en la nube (AWS EC2, GCP Compute Engine, etc.) son todas buenas opciones.

    • Debe ser accesible externamente (desde GitHub) a través de una dirección IP pública o dominio. (Preste atención a la configuración del firewall).

    • Recomendamos un entorno Linux como Ubuntu Server.

    • Instalación de Docker: Debe tener Docker instalado en el servidor para que la aplicación que se va a desplegar pueda ser construida o ejecutada en contenedores Docker.

  3. Entorno de desarrollo de Python:

    • Debe tener instalada una versión de Python 3.8 o superior en el servidor de staging. (Se recomienda usar un entorno virtual)

  4. Git:

    • Debe tener Git instalado en el servidor de staging. Se usará para obtener el código más reciente del repositorio de GitHub mediante el comando git pull.

  5. FastAPI y Uvicorn:

    • Necesita FastAPI, el marco para implementar el endpoint de Webhook en Python, y Uvicorn, un servidor ASGI. En el siguiente capítulo, abordaremos las instalaciones y configuraciones básicas.

  6. Clave SSH:

    • Para acceder de forma segura al repositorio de GitHub y obtener el código en el servidor de staging, necesita configurar una clave SSH. La mayoría probablemente ya tendrá claves SSH registradas en su cuenta. (Si aún no las ha registrado, asegúrese de hacerlo en GitHub. Es común utilizar una clave Deploy key para despliegues).

  7. Comprensión sobre servidores web (Nginx o Apache2) y configuración de dominio/HTTPS:

    • GitHub Webhook generalmente recomienda comunicaciones seguras a través de HTTPS. Por lo tanto, es altamente recomendable preparar un subdominio como deployer.example.com para recibir el webhook y obtener un certificado HTTPS (por ejemplo, un certificado gratuito a través de Let's Encrypt) para este dominio.

    • No creo que alguien esté conectando directamente su aplicación FastAPI mediante port forwarding en un router ISP, pero para aquellos que lo piensen, es mejor que la aplicación no esté expuesta directamente al exterior. Es más seguro utilizar un servidor web como Nginx o Apache2 como Proxy Inverso para pasar las solicitudes de webhook a la aplicación FastAPI. Tener una comprensión básica y experiencia en esta configuración será de gran ayuda.

  8. Comprensión sobre el servicio Systemd (opcional pero recomendado):

    • Este servidor de webhook FastAPI debe residir y ejecutarse siempre en su servidor de staging. Para ello, se recomienda registrarlo como un Servicio Systemd para que se inicie automáticamente incluso después de un reinicio del servidor, lo que facilita la gestión del servicio (inicio/parada/reinicio).

    • Nota: Configurar lógicas de despliegue complejas que requieran ejecutar comandos git o docker dentro de un contenedor Docker no solo va en contra del propósito del diseño del contenedor, sino que también requiere configuraciones complejas como docker-in-docker o docker-out-of-docker que no son seguras. Si ya tiene git y docker instalados en su servidor, es mucho más eficiente y sencillo ejecutar el servidor de webhook FastAPI como un Servicio Systemd y utilizar los comandos git y docker del sistema directamente en los scripts de despliegue. Esta serie se centrará en este enfoque.

Ahora todo está listo. En el próximo capítulo, construiremos el endpoint de Webhook FastAPI en el servidor de staging preparado y configuraremos GitHub Webhook para realizar nuestro primer despliegue automático. ¡Estén atentos!