Je détaille un peu mon expérience dkron. Je pense avoir été exhaustif.
TL;DR;
Bref, je suis plutôt content du soft et je le recommande.:
- Il fait le job
- il assure la dispo
- il est exploitable
- il est simple
- il est intégré à mon système sans trop de verrues
- il est fiable
Général
Le soft utilise un système de haute-dispo basé sur une implémentation célèbre protocole d’élection RAFT. Il n’a pas sa propre implémentation, mais utilise une implémentation faite par hashicorp [info cité de mémoire: a vérifier, peut être une confusion avec SERF]. Je ne sais pas si un noeud master qui est isolé suite à split brain va arrêter de bosser ou se considérer master. Je n’ai pas testé. La conf me laisse perplexe elle contient une directive qui donne le nombre minimum de noeud à “voir” pour le “bootstrap”. Le mot bootstrap me gêne car il évoque uniquement le démarrage.
La configuration est stockée sur disque et répliqué sur chaque noeud. Des qu’une modification est faite sur le master, elle est répliqué sur les autres noeuds. Je ne sais pas si cette réplication est faite en synchronisation avec la validation de l’appel à l’API REST, et donc résiliante a un crash juste après l’exécution d’une commande de mise à jour. Comme on parle d’un scheduler de job, cette hypothétique faute de synchro peut être acceptable, car la mise à jour des jobs n’est pas une opération a haute fréquence. Les updates de job sont fait à la main et donc ceci me parait acceptable, car l’opérateur se rends compte de l’erreur.
Dkron nécessite donc 3 serveur pour assurer sa disponibilité. Un serveur à le rôle de master, et manifestement s’occupe d’ordonnancer les taches sur les autres serveur (et lui même) qui se comporte en noeud follower.
A priori, les noeuds ne sont pas obligé d’avoir tous les rôles, il pourrait y avoir 3 noeuds sur des très petits serveur qui schédulent des jobs sur deux très gros noeuds dédiés à l’exécution. [note: je n'ai pas testé cette conf, c'est déduit de la doc]. On peut même avoir des noeud dédiés a des jobs et les exécuter uniquement sur ces noeuds.
La doc est dispo et est plutôt bien faite, mais pas totalement complète.
Il faut un peu de dev pour avoir une bonne intégration, mais ce n’est pas insurmontable. Cela permet de s’adapter aux différents systèmes de supervision.
Le cluster fonctionne chez moi depuis un an, et je n’ai rein a signaler. La dispo fonctionne bien (excepté le split brain qu’il faut contrôler). J’utilise des machines chez Online, et les disque cassent régulièrement, aussi j’ai eu pas mal de VM à réinstaller, et zéro interruption de service. [Note]: Je n’ai pas testé les cas au limites: que se passe-t-il si le serveur/service crève pendant l’exécution d’un job.
Exploitation
Il est simple à installer car il est packagé sur quelques OS. J’ai testé Centos/RPM, je ne sais pas pour le reste. Le soft est écrit en go, donc compilé en statique donc il fonctionne sans trop de dépendances, et est multiplateforme. Il n’est pas nécessaire de faire du “pip”, “npm” ou autre “gem” à qui il manque des dépendances, des problèmes de compatibilité de version, et tous les problèmes habituels de ces interpréteurs. Aussi l’utilisation de docker n’est pas indispensable.
/ 
L’initialisation du cluster n’est pas évidente. Elle n’est pas complexe non plus. Il faut faire une première étape avec un serveur unique pour créer le cluster, puis enregistrer/démarrer les autre noeuds et redémarrer le premier noeud en mode cluster. c’est expliqué dans le doc. Par la suite de l’exploitation il n’y a plus aucune manipulation de ce genre.
Pour une restauration d’un serveur du cluster, j’ai installé le soft et livré ses conf avec ansible, il a démarré et c’est immédiatement joint au cluster existant, et a commencé son job. Aucune commande à exécuter. C’est efficace et j’apprécie.
Le soft fourni une ligne de commande qui retourne le statut et d’autres infos et ainsi facilite l’exploitatiblité. Par exemple, voila l’état du cluster (mes IP sont obfusquées):
dkron raft list-peers --config /etc/dkron/dkron.yml
Node ID Address State Voter
batch05 batch05 192.168.x.a:6868 follower true
batch03 batch03 192.168.x.b:6868 follower true
batch04 batch04 192.168.x.c:6868 leader true
Coté supervision, il fourni une api http simple qui permet de connaitre l’état RAFT d’un noeud (“Alive”, “Leaving”, “Left”, “Failed”) ainsi que l’état effectif (“follower” ou “leader”). J’ai ecrit un petit script go qui collecte ces infos et les remontent a ma supervision via collectd. C’est tres simple de faire une script shell qui collecte ces infos. Voila ce que j’affiche dans Grafana. Ceci représente l’activité sur 30 jours:
Par ailleurs il s’intègre nativement avec prométheus, mais je n’ai pas testé ce point. Il fourni du statd, et c’est ce que j’exploite pour les métriques. Les métriques remontées sont un peu copieuses et ce n’est quasiment pas documenté. voila la liste de ce que je récupère:
1644274215.155 batch03/statsd/derive-dkron.agent.event_received.member-failed
1644274215.155 batch03/statsd/derive-dkron.agent.event_received.member-join
1644274215.155 batch03/statsd/derive-dkron.agent.event_received.member-update
1644274215.155 batch03/statsd/derive-dkron.memberlist.degraded.probe
1644274215.155 batch03/statsd/derive-dkron.memberlist.msg.alive
1644274215.155 batch03/statsd/derive-dkron.memberlist.msg.dead
1644274215.155 batch03/statsd/derive-dkron.memberlist.msg.suspect
1644274215.155 batch03/statsd/derive-dkron.memberlist.tcp.accept
1644274215.155 batch03/statsd/derive-dkron.memberlist.tcp.connect
1644274215.155 batch03/statsd/derive-dkron.memberlist.tcp.sent
1644274215.155 batch03/statsd/derive-dkron.memberlist.udp.received
1644274215.155 batch03/statsd/derive-dkron.memberlist.udp.sent
1644274215.155 batch03/statsd/derive-dkron.raft.state.candidate
1644274215.155 batch03/statsd/derive-dkron.raft.state.follower
1644274215.155 batch03/statsd/derive-dkron.raft.transition.heartbeat_timeout
1644274215.155 batch03/statsd/derive-dkron.serf.member.failed
1644274215.155 batch03/statsd/derive-dkron.serf.member.flap
1644274215.155 batch03/statsd/derive-dkron.serf.member.join
1644274215.155 batch03/statsd/derive-dkron.serf.member.update
1644274215.155 batch03/statsd/gauge-dkron.batch03.memberlist.health.score
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.alloc_bytes
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.free_count
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.heap_objects
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.malloc_count
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.num_goroutines
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.sys_bytes
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.total_gc_pause_ns
1644274215.155 batch03/statsd/gauge-dkron.batch03.runtime.total_gc_runs
1644274215.155 batch03/statsd/latency-dkron.grpc.agent_run-average
1644274215.155 batch03/statsd/latency-dkron.grpc.agent_run-percentile-90
1644274215.155 batch03/statsd/latency-dkron.grpc.call_execution_done-average
1644274215.155 batch03/statsd/latency-dkron.grpc.call_execution_done-percentile-90
1644274215.155 batch03/statsd/latency-dkron.grpc.execution_done-average
1644274215.155 batch03/statsd/latency-dkron.grpc.execution_done-percentile-90
1644274215.155 batch03/statsd/latency-dkron.grpc_agent.agent_run-average
1644274215.155 batch03/statsd/latency-dkron.grpc_agent.agent_run-percentile-90
1644274215.155 batch03/statsd/latency-dkron.memberlist.gossip-average
1644274215.155 batch03/statsd/latency-dkron.memberlist.gossip-percentile-90
1644274215.155 batch03/statsd/latency-dkron.memberlist.probeNode-average
1644274215.155 batch03/statsd/latency-dkron.memberlist.probeNode-percentile-90
1644274215.155 batch03/statsd/latency-dkron.memberlist.pushPullNode-average
1644274215.155 batch03/statsd/latency-dkron.memberlist.pushPullNode-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.candidate.electSelf-average
1644274215.155 batch03/statsd/latency-dkron.raft.candidate.electSelf-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.compactLogs-average
1644274215.155 batch03/statsd/latency-dkron.raft.compactLogs-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.fsm.apply-average
1644274215.155 batch03/statsd/latency-dkron.raft.fsm.apply-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.fsm.snapshot-average
1644274215.155 batch03/statsd/latency-dkron.raft.fsm.snapshot-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.appendEntries-average
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.appendEntries-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.appendEntries.processLogs-average
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.appendEntries.processLogs-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.appendEntries.storeLogs-average
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.appendEntries.storeLogs-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.processHeartbeat-average
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.processHeartbeat-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.requestVote-average
1644274215.155 batch03/statsd/latency-dkron.raft.rpc.requestVote-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.snapshot.create-average
1644274215.155 batch03/statsd/latency-dkron.raft.snapshot.create-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.snapshot.persist-average
1644274215.155 batch03/statsd/latency-dkron.raft.snapshot.persist-percentile-90
1644274215.155 batch03/statsd/latency-dkron.raft.snapshot.takeSnapshot-average
1644274215.155 batch03/statsd/latency-dkron.raft.snapshot.takeSnapshot-percentile-90
1644274215.155 batch03/statsd/latency-dkron.runtime.gc_pause_ns-average
1644274215.155 batch03/statsd/latency-dkron.runtime.gc_pause_ns-percentile-90
1644274215.155 batch03/statsd/latency-dkron.serf.coordinate.adjustment-ms-average
1644274215.155 batch03/statsd/latency-dkron.serf.coordinate.adjustment-ms-percentile-90
1644274215.155 batch03/statsd/latency-dkron.serf.msgs.received-average
1644274215.155 batch03/statsd/latency-dkron.serf.msgs.received-percentile-90
1644274215.155 batch03/statsd/latency-dkron.serf.msgs.sent-average
1644274215.155 batch03/statsd/latency-dkron.serf.msgs.sent-percentile-90
1644274215.155 batch03/statsd/latency-dkron.serf.queue.Event-average
1644274215.155 batch03/statsd/latency-dkron.serf.queue.Event-percentile-90
1644274215.155 batch03/statsd/latency-dkron.serf.queue.Intent-average
1644274215.155 batch03/statsd/latency-dkron.serf.queue.Intent-percentile-90
1644274215.155 batch03/statsd/latency-dkron.serf.queue.Query-average
1644274215.155 batch03/statsd/latency-dkron.serf.queue.Query-percentile-90
Les backup / restore sont plutôt simple. Ils se font avec une simple commande curl. Je les testé, c’est efficace. L’export est en JSON, la création du JSON peut être scripté.
La solution est pilotable par API REST. L’API est simple. et tout peut être configuré et manipulé par API. Perso, je l’ai très peu utilisé, alors je ne fait pas trop de commentaires. Pour info, l’interface web utilise cette API, et on peut donc utiliser le debugger du browser pour s’inspirer. La Doc API REST est au format swagger/openapi.
Il y a un systeme de webhook qui permet de faire des appels web a chaque exécution de job, et donc de logguer le statut, les erreurs, et éventuellement de lever des alertes. Pour ma part j’injecte les job en erreur dans mon soft de gestion de tickets.
Toutes les données dynamiques (modifiées pendant le runtime) du cluster sont dans un unique répertoire. Ce répertoire peut être supprimé et le noeud du cluster est reset. J’aime bien cette approche simple. Le noeud peut ensuite être détruit et réinitialisé facilement.
/ En cas d’échec d’un batch, le cluster fait un retry. Le nombre de retry est configurable. En revanche [Sauf erreur de ma part], le retry est fait uniquement sur le même serveur. Il ne change pas de serveur, et c’est dommage surtout si l’échec est lié au fait le job n’est pas installé sur le serveur.
Le soft fourni une interface web qui permet de piloter la solution (ajout / modification / suppression de jobs) et de visualiser l’exécution et les logs d’exécution.
L’ergonomie de l’interface web est pas top, la saisie des infos est très peu aidé et c’est facile de se tromper. Pour moi, cet inconvénient est acceptable, il devient marginal après un peu de manipulation.
Configuration
/ Par défaut chaque job est exécuté sur tous les serveurs. Il faut positionner un tag pour que le job soit exécuté sur un seul des serveurs du cluster. Je trouve que cette approche peut être trompeuse, voire destructrice pour certains services. Cela dit, je comprends l’approche car le système de tags permet de schéduler l’exécution de certains job sur certains serveurs.
/ La doc du webhook n’est pas faite ou n’est pas complète, j’ai du lire le code pour la comprendre. Il n’y a pas de fonction pour encoder du JSON, j’ai du utiliser un encodage url-encoded pour passer les infos sans probleme d’escape. Cela fonctionne par chance: 1: “urlquery” est fourni de base dans un soft en go qui utilise les templates go. 2: L’url-encoded encode tous les caractères spéciaux du JSON. En revanche mon serveur reçoit une requête dont le payload JSON doit être décodé deux fois: une fois en JSON, une seconde fois en url-encoded. Voila ma ligne de conf pour le payload du webhook:
webhook-payload: "{\"job\":\"{{.JobName}}\",\"node\":\"{{.NodeName}}\",\"env\":\"prod\",\"success\":{{.Success}},\"start\":\"{{.StartTime}}\",\"end\":\"{{.FinishedAt}}\",\"output\":\"{{.Output | urlquery}}\"}"
/ dkron reporte ses statistiques d’usage à un serveur de l’éditeur. C’est désactivable, mais attention à la négation dans la conf. Il faut affirmer la désactivation, plutôt que d’affirmer l’activation.
disable-usage-stats: true
Sécurité
La communication est chiffré via une clé partagée, qui sert également à créer le cluster et reconnaitre les membres.
Exécution des script en root. C’est pas top, on ne peut pas changer de user de base. Solution 1: un script wrapper qui change le user. Solution 2: modifier le code et faire un patch. Ce n’est pas très complexe, amis je n’ai pas eu le temps nécessaire pour faire une contribution acceptable.
Sauf erreur de ma part, l’interface web ne propose pas de SSL/TLS. Note: avec un haproxy et 10 lignes de conf, on peut ajouter de l’offloading SSL.
L’authentification n’est disponible qu’en version “entreprise”. Je n’ai rien contre ce modèle financier, mais je ne cautionne pas que les éléments de sécurité basique soit en option. Note: avec un haproxy et 10 lignes de conf, on peut ajouter du contrôle ip et de l’authentification “http basic”.
[remarque basée sur la documentation] En version “entreprise”, le mot de passe d’administration est stocké en clair dans la conf.
support
/ Les remontées de bug sur github sont suivies, et on a de l’aide facilement. Toutefois, j’ai rencontré un bug tout pourri sur un cas d’usage a la marge. et j’ai pas vraiment eu d’aide, j’ai du trouver le bug tout seul. La PR a été acceptées sans problèmes, mais la nouvelle release incluant le bugfix à tardé un pue a sortir.
/ En écrivant ceci, je viens de voir des échecs dans le logs 
, la haute dispo a fait le boulot et aucun job n’a été raté. Le serveur avec ces logs était follower, il a été vu down et est resté follower après redémarrage par systemd.
Feb 02 10:09:34 batch03 dkron[835]: 2022/02/02 10:09:34 [Recovery] 2022/02/02 - 10:09:34 panic recovered:
Feb 02 10:09:34 batch03 dkron[835]: runtime error: invalid memory address or nil pointer dereference
Feb 02 10:09:34 batch03 dkron[835]: /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/panic.go:212 (0x434cba)
Feb 02 10:09:34 batch03 dkron[835]: /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/signal_unix.go:734 (0x44dad2)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/hashicorp/raft@v1.3.1/api.go:1016 (0x1d85271)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/work/dkron/dkron/dkron/agent.go:613 (0x1d8526a)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/work/dkron/dkron/dkron/api.go:394 (0x1d85261)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/context.go:165 (0x1db05a2)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/work/dkron/dkron/dkron/api.go:128 (0x1db0585)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/context.go:165 (0x1d82e4e)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/work/dkron/dkron/dkron/api.go:134 (0x1d82e34)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/context.go:165 (0xc446d9)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/recovery.go:99 (0xc446c0)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/context.go:165 (0xc437b3)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/logger.go:241 (0xc43772)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/context.go:165 (0xc39ee9)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/gin.go:489 (0xc39ecf)
Feb 02 10:09:34 batch03 dkron[835]: /home/runner/go/pkg/mod/github.com/gin-gonic/gin@v1.7.1/gin.go:445 (0xc399bb)
Feb 02 10:09:34 batch03 dkron[835]: /opt/hostedtoolcache/go/1.16.8/x64/src/net/http/server.go:2867 (0x723882)
Feb 02 10:09:34 batch03 dkron[835]: /opt/hostedtoolcache/go/1.16.8/x64/src/net/http/server.go:1932 (0x71ecac)
Feb 02 10:09:34 batch03 dkron[835]: /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/asm_amd64.s:1371 (0x46d8e0)
