Jak prawidłowo skalować Jenkinsa?

W moim projekcie mamy jeden serwer AWS z uruchomionym Jenkins Master + 1 Jenkins slave (2 executory) ... i potrzebujemy więcej
Aby zwiększyć naszą moc kompilacji, mamy trzy opcje:

1. Skaluj w górę : Zwiększ instancję AWS i dodaj więcej programów wykonawczych.
2. Skaluj w górę : Zwiększ instancję AWS i dodaj kolejny proces jenkins slave.
3. Wyskaluj : utwórz kolejną instancję AWS z urządzeniem typu Jenn slave i podłącz ją do elementu master

Chcemy zrobić 2., ponieważ jesteśmy w dużej organizacji, a nasz obecny Jenkins Master ma już dostęp do każdego miejsca, którego potrzebuje. Opcja 3. „Nowy serwer” jest skomplikowany, ponieważ wymaga więcej biurokratycznych zatwierdzeń, które potrwają tygodnie.

Więc moje pytania to:

• Czy w opcji 2 są jakieś problemy techniczne? . Może wykonawcy każdego niewolnika Jenkins nie są świadomi innych wykonawców slave?
• Ogólnie, jakie jest najlepsze podejście do skalowania Jenkinsa? Skalowanie w górę czy w górę?

Nie ma podstawowych problemów technicznych z działaniem wielu niewolników Jenkins na tej samej maszynie. W rzeczywistości uruchamianie wielu urządzeń podrzędnych na tej samej maszynie wymienia kilka dobrych powodów:

Chociaż poprawne użycie programów wykonawczych w dużej mierze eliminuje potrzebę wielu instancji podrzędnych na tym samym komputerze, istnieje kilka wyjątkowych przypadków użycia, które należy wziąć pod uwagę:

• Chcesz mieć większą konfigurowalność między skonfigurowanymi węzłami. Załóżmy, że masz jeden zestaw węzłów, który będzie używany w jak największym stopniu, a drugi węzeł będzie używany tylko w razie potrzeby.
• Być może masz wiele instalacji głównych Jenkins budujących różne rzeczy, więc ta konfiguracja pozwoli ci mieć niewolników dla więcej niż jednego mistrza na tym samym urządzeniu. Zgadza się, dzięki Jenkins możesz naprawdę służyć dwóm mistrzom.
• Możesz skorzystać z łatwości uruchamiania / zatrzymywania / wymiany maszyn wirtualnych, być może w połączeniu z wtyczkami Jenkins, takimi jak Libvirt Slaves Plugin .
• Chcesz zmaksymalizować inwestycję i wykorzystanie sprzętu, jednocześnie minimalizując koszty operacyjne (np. Wydatki na użytkowanie związane z pracą na jałowych urządzeniach podrzędnych).

Ogólnie rzecz biorąc , preferowane jest skalowanie, głównie dlatego, że zdolność do skalowania jest zwykle ograniczona przez typy / rozmiary dostępnych zasobów fizycznych.

W szczególności w celu zwiększenia mocy kompilacji zaleciłbym analizę rzeczywistej kompilacji w celu ustalenia, w jaki sposób wykorzystuje ona zasoby maszyny, jakie / gdzie są jej wąskie gardła i jakie ograniczenia skalowalności podnosi, aby ujawnić, czy skalowanie w ogóle pomaga.

Na przykład napotkałem przypadki, w których czas kompilacji 2 równoległych kompilacji na tej samej maszynie był dłuższy niż łączny czas kompilacji tych samych 2 kompilacji wykonanych sekwencyjnie (bez nakładania się) na tej samej maszynie. W takim przypadku nawet nie wziąłbym pod uwagę skalowania, ponieważ faktycznie zmniejszyłoby to ogólną pojemność budynku.

Użyj Kubernetes and Helm.

Poleciłbym użyć tabeli Jenkins Helm. Instaluje się helm install stable/jenkinsi automatycznie skaluje.

https://github.com/kubernetes/charts/tree/master/stable/jenkins

Myślę, że nie powinieneś tego robić;)

A więc, coś w tym stylu, tak. Myślę, że potrzebujesz więcej modułów wykonawczych, może twoje kompilacje naprawdę wymagają dużych zasobów? Uruchomiłbym co najmniej 4, ale działamy od 6 do 8 w zależności od zadań. Lubię dopasowywać # rdzeni do egzektorów. Więc może chcesz przeskalować swoje węzły, myślę, że uruchamiamy duże M4 dla naszych wykonawców 4-8.

Myślę też, że powinieneś skalować, ale powinieneś to zrobić mądrze. Jenkins ma wtyczkę do automatycznego skalowania w AWS w zależności od tego, co znajduje się w kolejce kompilacji. Zasadniczo mówisz, ile zadań i jak długo trzeba czekać, aż wstanie slave i wyśle ​​zadania do nowego slave. Możesz także ustawić maksymalną liczbę niewolników, minimalną liczbę itp.

Skalowałbym zamiast skalować w górę, wybierając opcję 3. Wprowadziliśmy konfigurację, w której wszyscy agenci Jenkins pracują na ECS (niestandardowy Jenkins oparty na Dockerze) z grupą automatycznego skalowania. Wszyscy nasi mistrzowie Jenkins komunikują się z ECS, dzieląc w ten sposób obciążenie ECS, i nie trzeba odtwarzać mistrza Jenkins w ćwiczeniu zwiększania skali.