J'ai essayé de mettre en place Enterprise Jenkins avec la configuration Haute disponibilité. La configuration actuelle consiste en deux maîtres Jenkins partageant le même home Jenkins, disons master1 et master2, une installation du rpm jenkins-ha-monitor-1.1-1.1 sur ces deux maîtres, disons monitor1 et monitor2. Avec cette configuration, selon la documentation au moins, le plugin HA devrait fonctionner comme prévu. Les scripts scripts sont similaires à ceux de la documentation (seules l'adresse IP et l'interface sont différentes, mais l'approche est la même).
Pour la rétrogradation
ifconfig eth0:2 down
Pour la promotion
ifconfig eth0:2 the.floating.ip
Maintenant, pour que les nœuds soient enregistrés correctement, je dois démarrer master1, master2, monitor1 et monitor2 dans cet ordre. Je vois que lorsque les services sont démarrés dans cet ordre, ils sont enregistrés correctement par les deux services de surveillance en tant que nœuds d'un cluster, et dans l'interface de statut HA de la console jenkins.
Maintenant, lorsque master1 est tué en lui envoyant un signal KILL, monitor2 le reconnaît et exécute le script de promotion script. Mais le moniteur 1 continue de lancer :
Oct 24, 2012 3:47:36 PM com.cloudbees.jenkins.ha.singleton.HASingleton$3 suspect INFO : Suspecter une défaillance de nœud dans un cluster : jenkins-master-1-285 Oct 24, 2012 3:47:39 PM com.cloudbees.jenkins.ha.singleton.HASingleton$3 suspect INFO : Suspecter une défaillance de nœud dans un cluster : jenkins-master-1-285
continuellement sans jamais exécuter le script de rétrogradation. Maintenant, puisque master2 a pris l'ip flottante via sa promotion script, et que master1 a toujours cette ip parce que la démotion script n'a pas été exécutée, la configuration se retrouve avec deux boîtes revendiquant la même ip. De plus, redémarrer master1 ne fait rien, c'est-à-dire que master1 n'est pas ajouté au cluster en tant que second nœud, monitor1 continue de cracher les messages ci-dessus dans le journal, l'ip flottante continue de renvoyer "Unable to connect" et master2 et monitor2 affichent le cluster comme master2, monitor2 et monitor1. Ma question/problème est donc double : pourquoi master1 n'est-il pas accepté à nouveau dans le cluster ? Et pourquoi le script de rétrogradation script ne s'exécute-t-il pas comme il le devrait ?
Pour information, j'ai essayé de faire un
service jenkins stop
et dans ce cas, le script de rétrogradation script s'exécute, mais il y a à nouveau des problèmes similaires lorsque
service jenkins start
est exécuté sur le maître qui a été arrêté plus tôt puisque la promotion script est exécutée indépendamment de l'existence d'un jenkins primaire. Et dans ce cas, les deux moniteurs enregistrent des clusters différents comme monitor1 : master1,monitor1 et monitor2 : master2,monitor2. L'exécution d'un ifconfig montre que les deux maîtres ont pris l'ip flottante à ce stade.
Toute aide est la bienvenue ! Merci d'avance !
