Как правильно масштабировать Дженкинс?

В моем проекте у нас есть один сервер AWS, на котором работает Jenkins Master + 1 Jenkins Slave (2 исполнителя) ... и нам нужно больше
, чтобы увеличить мощность нашей сборки, у нас есть три варианта:

1. Увеличьте масштаб : увеличьте число экземпляров AWS и добавьте больше исполнителей.
2. Увеличьте масштаб : увеличьте экземпляр AWS и добавьте еще один подчиненный процесс jenkins.
3. Масштабирование : создайте еще один экземпляр AWS с подчиненным jenkins и подключите его к мастеру

2. Мы хотим сделать это, поскольку мы находимся в большой организации, и наш нынешний мастер Дженкинс уже имеет доступ ко всем местам, в которых он нуждается. Вариант 3. «Новый сервер» сложен, так как требует большего бюрократического одобрения, что займет несколько недель.

Итак, мои вопросы:

• Есть ли технические проблемы в варианте 2? , Может быть, исполнители каждого раба Дженкинса не знают о других рабовладельцах?
• В целом, каков наилучший подход к масштабированию Дженкинса? Увеличение или уменьшение?

Нет никаких фундаментальных технических проблем с запуском нескольких подчиненных jenkins на одной машине. Фактически, запуск нескольких ведомых на одной машине приводит несколько веских причин для этого:

Хотя правильное использование исполнителей в значительной степени устраняет необходимость использования нескольких ведомых экземпляров на одном компьютере, существует несколько уникальных вариантов использования, которые следует учитывать:

• Вы хотите больше настраиваемости между настроенными узлами. Скажем, у вас есть один узел, который будет использоваться как можно чаще, а другой - только при необходимости.
• У вас может быть несколько мастер-установок Jenkins, строящих разные вещи, и поэтому эта конфигурация позволит вам иметь подчиненных для более чем одного мастера на одном блоке. Это верно, с Дженкинс вы действительно можете служить двум мастерам.
• Возможно, вы захотите воспользоваться простотой запуска / остановки / замены виртуальных машин, возможно, в сочетании с плагинами Jenkins, такими как плагин Libvirt Slaves .
• Вы хотите максимизировать свои инвестиции и использование оборудования, в то же время минимизируя эксплуатационные расходы (например, расходы на коммунальные услуги для работы холостых подчиненных).

В целом, масштабирование является предпочтительным, в первую очередь потому, что возможность масштабирования обычно ограничена типами / размерами доступных физических ресурсов.

В частности, для увеличения мощности сборки я бы порекомендовал проанализировать вашу фактическую сборку, чтобы определить, как она использует ресурсы машины, какие / где существуют ее узкие места и какие ограничения масштабируемости она выявляет, чтобы выявить, помогает ли даже масштабирование.

Например, я сталкивался со случаями, когда время сборки для двух параллельных сборок на одной машине было больше, чем объединенное время сборки тех же двух сборок, выполняемых последовательно (без перекрытия) на одной машине. В таком случае я бы даже не подумал об увеличении, поскольку это фактически уменьшило бы общую строительную мощность.

Используйте Kubernetes и Helm.

Я бы порекомендовал использовать диаграмму Дженкинса Хелма. Он устанавливается helm install stable/jenkinsи автоматически масштабируется.

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

Я думаю, что вы не должны делать ни;)

Ну вроде. Я думаю, что вам нужно больше исполнителей, может быть, ваши сборки действительно ресурсоемки? Я бы запустил по крайней мере 4, но мы запускаем 6-8 в зависимости от работы. Мне нравится сопоставлять количество ядер для участников. Так что вы можете захотеть увеличить ваши узлы, я думаю, что мы запустили M4 для наших 4-8 исполнителей.

Я также думаю, что вы должны масштабироваться, но вы должны делать это с умом. У Jenkins есть плагин для автоматического масштабирования в AWS в зависимости от того, что находится в очереди на сборку. В основном вы указываете, сколько рабочих мест и сколько времени ждут, прежде чем он встанет на подчиненное устройство и отправит задания новому ведомому. Вы также можете установить максимальное количество рабов, минимальное количество и т. Д.

Вместо масштаба я бы увеличил масштаб, перейдя к варианту 3. Мы сделали настройку, в которой все агенты Jenkins работают на ECS (настраиваемый докер на основе Jenkins) с группой автоматического масштабирования. У нас есть все наши мастера Jenkins, которые общаются с ECS, таким образом, разделяя нагрузку на ECS, и нет необходимости заново создавать мастера Jenkins в упражнении по расширению.