🌐 También en: English · Deutsch · Français
Hoy he dedicado un rato a explorar Jenkins en mi homelab.
Para quienes de algún modo han conseguido esquivar Jenkins durante la última década: Jenkins es uno de los servidores de automatización de código abierto más utilizados hoy en día. Publicado originalmente en 2011 como fork del proyecto Hudson, Jenkins se ha convertido en uno de los pilares de los flujos de trabajo DevOps modernos. Se usa sobre todo para integración continua (CI) y entrega continua (CD), automatizando compilaciones de software, pruebas, despliegues y todo tipo de tareas administrativas recurrentes. Si un proceso se puede automatizar, lo más probable es que Jenkins pueda encargarse de él. 😎
Hasta ahora usaba dos tareas cron clásicas en mi homelab. Su función es bastante sencilla: cada noche usan rsync para crear copias de seguridad de dos instancias de Nextcloud expuestas a Internet.
El montaje llevaba bastante tiempo funcionando sin problemas. Pero en cuanto a monitorización y registros, cron sigue siendo la herramienta preferida de los fans de la línea de comandos y los veteranos de Unix. Normalmente acabas rebuscando en ficheros de log, comprobando a mano si las tareas se ejecutaron bien y preguntándote de vez en cuando si una copia de seguridad fallida fue hace tres días o hace tres semanas.
Por supuesto, cron es increíblemente fiable y ligero. Pero seamos sinceros: no ofrece precisamente la experiencia de usuario más moderna.
Como es muy probable que Jenkins tenga un papel más importante en mi entorno profesional en el futuro, decidí desplegarlo por fin también en mi homelab y ganar algo de experiencia práctica.
Un detalle a destacar: Jenkins corre en la misma máquina que ya aloja GitLab. Como GitLab ya escucha en el puerto TCP 8080, tuve que configurar Jenkins para que usara el puerto TCP 8090.
Configuración actual de Jenkins
De momento, la configuración de Jenkins es sencilla a propósito.
He creado dos jobs de tipo Freestyle Project. Igual que en mi antiguo montaje con cron, cada job tiene su propia programación que define cuándo debe ejecutarse. La copia de seguridad en sí no es más que la ejecución de un script de shell local.
Hasta ahora todo ha funcionado a la perfección. Jenkins ofrece una práctica interfaz web en la que veo al instante si los jobs se han ejecutado correctamente, cuándo se ejecutaron, cuánto tardaron y qué salida generaron.
Comparado con revisar los logs de cron a mano, esto ya se nota como una mejora considerable en la calidad de vida. 😊
Hizo falta un ajuste adicional. Jenkins se ejecuta con su propia cuenta de servicio jenkins, mientras que mis scripts de copia de seguridad esperan ejecutarse como el usuario user3. En lugar de rediseñar permisos y propietarios, simplemente configuré el paso de compilación para lanzar los scripts mediante sudo -u user3. Así, Jenkins sigue encargándose de programar y supervisar los jobs, mientras que la lógica de la copia de seguridad se ejecuta con la cuenta que ya tiene acceso a los ficheros y directorios necesarios. 😎
Exportar la configuración de los jobs como XML
Una función especialmente útil que descubrí es que Jenkins permite exportar la configuración de cada job como XML.
Para obtener la configuración de un job, basta con añadir /config.xml a la URL del job y autenticarte con una cuenta de usuario válida de Jenkins:
curl -u <user>:<password> \
http://192.168.10.x:8090/job/Backup-InstanceB/config.xml
Curiosamente, acceder directamente a la configuración XML desde el navegador no me funcionó. En cambio, con curl desde la línea de comandos funcionó perfectamente.
El XML resultante contiene la definición completa del job, lo que lo hace útil no solo para documentación, sino también como copia de seguridad ligera de la configuración de Jenkins.
Configuración de Backup-InstanceA
user3@hp1:~$ curl -u <user>:<password> http://192.168.10.x:8090/job/Backup-InstanceA/config.xml
<?xml version='1.1' encoding='UTF-8'?>
<project>
<actions/>
<description>rsync</description>
<keepDependencies>false</keepDependencies>
<properties/>
<scm class="hudson.scm.NullSCM"/>
<canRoam>true</canRoam>
<disabled>false</disabled>
<blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
<blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
<triggers>
<hudson.triggers.TimerTrigger>
<spec>H 1 * * *</spec>
</hudson.triggers.TimerTrigger>
</triggers>
<concurrentBuild>false</concurrentBuild>
<builders>
<hudson.tasks.Shell>
<command>sudo -u user3 /raid5/shared/shared/ablage/nextcloud_backup_and_restore/instance-a_backup_nextcloud_remote.sh</command>
<configuredLocalRules/>
</hudson.tasks.Shell>
</builders>
<publishers/>
<buildWrappers/>
</project>
Configuración de Backup-InstanceB
user3@hp1:~$ curl -u <user>:<password> http://192.168.10.x:8090/job/Backup-InstanceB/config.xml
<?xml version='1.1' encoding='UTF-8'?>
<project>
<description>rsync</description>
<keepDependencies>false</keepDependencies>
<properties/>
<scm class="hudson.scm.NullSCM"/>
<canRoam>true</canRoam>
<disabled>false</disabled>
<blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
<blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
<triggers>
<hudson.triggers.TimerTrigger>
<spec>H 2 * * *</spec>
</hudson.triggers.TimerTrigger>
</triggers>
<concurrentBuild>false</concurrentBuild>
<builders>
<hudson.tasks.Shell>
<command>sudo -u user3 /raid5/shared/shared/ablage/nextcloud_backup_and_restore/sofie_backup_nextcloud_remote.sh</command>
<configuredLocalRules/>
</hudson.tasks.Shell>
</builders>
<publishers/>
<buildWrappers/>
</project>
Conclusión
Desde un punto de vista puramente técnico, sustituir dos tareas cron que funcionan perfectamente por Jenkins es probablemente un ejemplo de manual de sobreingeniería. 😄
Por otro lado, Jenkins ofrece registros centralizados, historial de ejecuciones, información de estado y una interfaz web amigable que hace mucho más cómodo supervisar las tareas programadas.
Por ahora, Jenkins se limita a lanzar dos scripts de copia de seguridad. Pero todo experimento de homelab empieza pequeño, y la experiencia demuestra que, una vez que Jenkins está disponible, rara vez se queda en solo dos jobs.
A ver adónde nos lleva este viaje. 🚀
