3.0 KiB
| layout | title |
|---|---|
| post | CI/CD con Gitea + Drone |
Drone CI es un sistema de CI/CD autónomo y autogestinado que puede asemejarse a lo que es Gitlab CI, Github Actions, Travis CI, etc. En mi caso, al usar Gitea, me viene perfecto para dar soporte de CI a mis proyectos.
Tengo ambos sistemas corriendo en Docker, y a mayores tengo un runner en cada servidor donde quiero tener funcionando cosas desatendidas.
Desde un simple archivo .drone.yml puedo configurar tanto la build del proyecto como el despliegue del mismo, ya que al tener también mi propio registro de Docker (lo que viene siendo un DockerHub privado), entre los tres puedo montar la imágen con Drone, push al registro y despliegue de la nueva imágen para finalizar en el servidor que toque.
Y todo "privado".
Caso de uso
El ejemplo es este mismo blog. Cuando creo/edito una entrada, o literalmente cualquier archivo del mismo, al commitear los cambios a git se ejecuta un pipeline en el runner que corresponda, reconstruye el sitio y crea una imágen del resultado final, lo manda al registro, y se despliega la nueva imágen. Con prácticamente 0 downtime, rollbacks, versionado y código 100% visible y disponible.
Nota: Esto sería en un escenario ideal y así estaba en la anterior versión, pero en la actual no se monta una imágen aun, se monta el resultado del sitio en el host. Eso cambiará a futuro.
El resumen del archivo .drone.yml sería:
- build del sitio con la imágen de docker de Jekyll.
- build de la imágen final basada en nginx (por ejemplo) copiando el contenido de
_site. - push de la imágen al registro.
- pull del registro y restart de la nueva imágen donde se esté ejecutando.
Web server
Como el contenido hay que servirlo desde alguna parte, tengo la siguiente configuración en el vhost de nginx de sergio.am para que haga distinción entre el contenido del blog y el de Gitea, ya que se sirven desde el mismo dominio:
server {
...
...
}
Planes a futuro
Mi idea a futuro es tener el blog servido desde algún alojamiento gratuito como puede ser Github Pages, o Netlify, o cualquier CDN que lo permita.
De forma más inmediata cambiaré el setup del servidor que mueve todo para que pase cacheado con Cloudflare, pero para ello tengo que cambiar bastante la infraestructura, ya que el proxy de Cloudflare no permite más conexiones que HTTP/S, y ahora mismo tanto HTTP/S como SSH van a la misma conexión, por lo que al activar el proxy pierdes la conectividad SSH.
La alternativa de Cloudflare Tunnel es viable, pero un poco overkill para mi sencillo entorno. Por ello prefiero separar SSH y HTTP/S, aunque ello me lleve un tiempo de cambios aquí y allá.