Jenkins Slave-Nutzung

By | 18. September 2016

Sofern man sich beim Jenkins für die Skalierung mittels Build-Slaves entschieden hat, läuft man zwangsläufig in eines der Jenkins Grundprobleme:
Man hat zwar nun mehere Build-Slaves, die Jobs werden aber nach wie vor nach dem Jenkins Prinzip auf dem entsprechenden Node gestartet.

Was meine ich nun mit Jenkins-Prinzip ?
Jenkins startet grundsätzlich den auszuführenden Job IMMER dort, wo er zuletzt ausgeführt wurde.

Wenn also alle meine Jobs bisher auf dem Master ausgeführt wurden, werden sie auch weiterhin dort ausgeführt, was dann den Aufbau von Build-Slaves ad Absurdum führt 🙁

Die Lösung

Es gibt ein sehr zu empfehlendes Plugin für Jenkins: Scoring Load Balancer

Das Plugin überschreibt das Standardverhalten vom Jenkins und entscheidet anhand von Konfigurationen, wie die Last auf die Knoten verteilt werden soll.

Es gibt bei diesem Plugin diverse Möglichkeiten die Last gewichtet zu verteilen, allerdings ist meine präferierte Einstellung bei diesem Plugin das „Scoring by Node Loads“.

Hier wird im Endeffekt für jeden Build-Knoten zunächst ein Wert „Scale for Scores“ definiert.
Jeder „Freie Build-Executor“ erhält nun noch einen inkrementellen Wert und jeder „Belegte Build-Executor“ einen dekrementellen Wert.

Um zu verdeutlichen, wie das Ganze nun funktioniert, nehmen wir einfach mal folgende Jenkins-Knoten-Konfiguration an:

Knoten Anzahl Build-Prozessoren Knoten Score
Master 30 300 (30*(1*10))
Slave 1 30 300 (30*(1*10))

Wird jetzt auf dem Master ein Job ausgeführt, sinkt der Knoten Score auf 290, da ja ein Build-Prozessor belegt ist.
Wird nun während des laufenden Builds auf dem Master ein weiterer Build angestoßen, sucht das Plugin nun nach dem Knoten, der den höchsten verfügbaren Knoten-Score hat. In diesem Fall wäre das dann der theoretische Knoten Slave 1.

Das Plugin bietet des Weiteren diverse Kombinationsmöglichkeiten von Gewichtigungsvarianten, allerdings bin ich bisher mit dieser einfachen Konfiguration am besten gefahren. 🙂

Kommentar verfassen