Remplacer les tâches cron par Jenkins pour les sauvegardes Nextcloud 🚀

🌐 Aussi en: English · Deutsch · Español

Aujourd’hui, j’ai pris un peu de temps pour explorer Jenkins dans mon homelab.

Pour ceux qui ont réussi, on ne sait comment, à éviter Jenkins pendant la dernière décennie : Jenkins est l’un des serveurs d’automatisation open source les plus utilisés aujourd’hui. Publié à l’origine en 2011 comme fork du projet Hudson, Jenkins est devenu l’un des piliers des workflows DevOps modernes. Il sert principalement à l’intégration continue (CI) et à la livraison continue (CD) : il automatise les builds logiciels, les tests, les déploiements et toutes sortes de tâches d’administration récurrentes. Si un processus peut être automatisé, Jenkins sait probablement s’en charger. 😎

Jusqu’à présent, j’utilisais deux tâches cron classiques dans mon homelab. Leur rôle est assez simple : chaque nuit, elles utilisent rsync pour créer des sauvegardes de deux instances Nextcloud exposées sur Internet.

Ce montage fonctionne parfaitement depuis un bon moment. Mais côté supervision et journalisation, cron reste avant tout l’outil des adeptes de la ligne de commande et des vétérans d’Unix. On finit généralement par fouiller dans les fichiers de log, par vérifier à la main si les tâches se sont bien exécutées, et par se demander de temps en temps si une sauvegarde ratée date d’il y a trois jours ou de trois semaines.

Bien sûr, cron est incroyablement fiable et léger. Mais soyons honnêtes : on ne peut pas dire qu’il offre l’expérience utilisateur la plus moderne qui soit.

Comme Jenkins va très probablement prendre plus de place dans mon environnement professionnel à l’avenir, j’ai décidé de le déployer enfin dans mon homelab aussi, pour acquérir un peu d’expérience pratique.

Un détail à noter : Jenkins tourne sur la même machine que GitLab. Comme GitLab écoute déjà sur le port TCP 8080, il a fallu configurer Jenkins pour utiliser le port TCP 8090.

Configuration actuelle de Jenkins

Pour l’instant, la configuration de Jenkins est volontairement simple.

J’ai créé deux jobs de type Freestyle Project. Comme dans mon ancienne configuration cron, chaque job a sa propre planification qui définit quand il doit s’exécuter. L’opération de sauvegarde elle-même n’est rien de plus que l’exécution d’un script shell local.

Jusqu’ici, tout fonctionne sans accroc. Jenkins fournit une interface web pratique où je vois immédiatement si les jobs se sont bien déroulés, quand ils ont été exécutés, combien de temps ils ont pris et quelle sortie ils ont produite.

Comparé à l’inspection manuelle des logs cron, c’est déjà un vrai gain de confort au quotidien. 😊

Un ajustement supplémentaire a été nécessaire. Jenkins tourne sous son propre compte de service jenkins, alors que mes scripts de sauvegarde doivent être exécutés en tant qu’utilisateur user3. Plutôt que de revoir les permissions et les propriétaires, j’ai simplement configuré l’étape de build pour lancer les scripts via sudo -u user3. Ainsi, Jenkins reste chargé de la planification et de la supervision des jobs, tandis que la logique de sauvegarde proprement dite s’exécute sous le compte qui a déjà accès aux fichiers et répertoires nécessaires. 😎

Exporter les configurations des jobs en XML

Une fonctionnalité particulièrement utile que j’ai découverte : Jenkins permet d’exporter la configuration de chaque job au format XML.

Pour récupérer la configuration d’un job, il suffit d’ajouter /config.xml à l’URL du job et de s’authentifier avec un compte utilisateur Jenkins valide :

curl -u <user>:<password> \
http://192.168.10.x:8090/job/Backup-InstanceB/config.xml

Curieusement, l’accès direct à la configuration XML depuis un navigateur n’a pas fonctionné chez moi. En revanche, avec curl en ligne de commande, tout a marché parfaitement.

Le XML obtenu contient la définition complète du job, ce qui le rend utile non seulement pour la documentation, mais aussi comme sauvegarde légère de la configuration de Jenkins.

Configuration 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>

Configuration 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>

Conclusion

D’un point de vue purement technique, remplacer deux tâches cron parfaitement fonctionnelles par Jenkins est sans doute un cas d’école de sur-ingénierie. 😄

D’un autre côté, Jenkins offre une journalisation centralisée, un historique des exécutions, des informations d’état et une interface web conviviale qui rend la supervision des tâches planifiées nettement plus confortable.

Pour l’instant, Jenkins se contente de lancer deux scripts de sauvegarde. Mais toute expérience de homelab commence petit, et l’expérience montre qu’une fois Jenkins en place, il se limite rarement à deux jobs.

Voyons où ce voyage nous mènera ensuite. 🚀