Руководство по архитектуре и повышению производительности Jenkins

1. Обзор

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

2. Архитектура Дженкинса

Некоторые потребности не могли быть удовлетворены с помощью одного сервера Jenkins. Во-первых, нам может понадобиться несколько разных сред для тестирования наших сборок. Один сервер Jenkins не сможет этого сделать. Во-вторых, если регулярно создаются более крупные и тяжелые проекты, один сервер Jenkins будет перегружен.

Распределенная архитектура Jenkins была создана для удовлетворения вышеуказанных требований. Кроме того, Jenkins управляет распределенными сборками, используя архитектуру Master-Slave . Протокол TCP/IP используется для связи между ведущим и ведомым в этой конструкции.

2.1. Дженкинс Мастер

Мастер Jenkins отвечает за планирование заданий, назначение подчиненных устройств и отправку сборок подчиненным устройствам для выполнения заданий. Он также будет отслеживать состояние подчиненного устройства (офлайн или онлайн) и получать ответы о результатах сборки от подчиненных устройств и отображать их на выходе консоли.

2.2. Дженкинс Раб

Он работает на удаленном сервере. Сервер Jenkins следует запросам мастера Jenkins и совместим со всеми операционными системами . Строительные задания, отправленные ведущим, выполняются подчиненным. Также проект можно настроить на выбор конкретной ведомой машины.

2.3. Распределенная архитектура Master-Slave

Давайте посмотрим на архитектуру Jenkins на примере. Один главный и три подчиненных Jenkins изображены на диаграмме ниже:

Давайте посмотрим, как мы можем использовать Jenkins для тестирования в различных системах, таких как Ubuntu, Windows или Mac:

На схеме учтены следующие элементы:

• Дженкинс будет регулярно проверять репозиторий GIT на наличие изменений в исходном коде.
• Для каждой сборки Jenkins требуется собственная среда тестирования, которую нельзя создать на одном сервере. Дженкинс достигает этого, нанимая различных рабов по мере необходимости.
• Jenkins Master сообщит этим ведомым устройствам запрос на тестирование, а также отчеты о тестировании.

3. Интерфейс командной строки Дженкинса

Jenkins имеет интерфейс командной строки, который пользователи и администраторы могут использовать для доступа к Jenkins из среды сценариев или оболочки. SSH, клиент Jenkins CLI или файл JAR, включенный в Jenkins, могут использовать этот интерфейс командной строки .

Для этого мы должны сначала загрузить jenkins-cli.jar с контроллера Jenkins по URL-адресу /jnlpJars/jenkins-cli.jar , фактически JENKINS_URL/jnlpJars/jenkins-cli.jar, а затем запустить его следующим образом:

java -jar jenkins-cli.jar -s http://localhost:8080/ -webSocket help

Этот параметр доступен, если выбрать «Jenkins CLI» в разделе «Инструменты и действия» на странице «Управление Jenkins»:

В этой области отображается список доступных команд. Мы можем использовать инструмент командной строки для доступа к различным функциям с помощью этих команд.

4. Перезапустите Дженкинс вручную

Если мы хотим вручную перезапустить или выключить Jenkins, просто выполните следующие шаги:

4.1. Запустить снова

Мы можем выполнить перезапуск с помощью Jenkins Rest API. Это заставит процедуру перезапуститься, не дожидаясь завершения существующих заданий:

http://(jenkins_url)/restart

Мы можем выполнить safeRestart, используя Jenkins Rest API. Это позволяет нам закончить любые существующие задачи:

http://(jenkins_url)/safeRestart

Если мы установим его как пакет rpm или deb , команда ниже будет работать:

service jenkins restart

4.2. Убунту

Мы также можем использовать apt-get/dpkg для установки следующего:

sudo /etc/init.d/jenkins restart
Usage: /etc/init.d/jenkins {start|stop|status|restart|force-reload}

4.3. Для безопасного отключения Дженкинса

Если мы хотим безопасно закрыть Jenkins, мы можем выполнить выход с помощью Jenkins Rest API:

http://(jenkins_url)/exit

Мы можем выполнить kill, используя Jenkins Rest API, чтобы завершить все наши процессы:

http://(jenkins_url)/kill

5. Повышение производительности Дженкинса

Отставание или медленная реакция — типичная жалоба пользователей Jenkins, и есть много сообщений об ошибках. Медленные системы CI неудобны, так как замедляют разработку и тратят время. Используя несколько простых рекомендаций, мы можем увеличить производительность этих систем.

В следующих разделах мы обсудим несколько предложений по улучшению Jenkins и вызову улыбки на лицах наших инженеров.

5.1. Минимизируйте сборки на главном узле

Главный узел — это место, где фактически выполняется приложение; это мозг Дженкинса, и, в отличие от раба, его нельзя заменить . Поэтому мы хотим, чтобы наш мастер Jenkins был как можно более «свободным», используя ЦП и ОЗУ для планирования и запуска сборок на подчиненных устройствах. Мы можем добиться этого, ограничив наши задания меткой узла, например SlaveNode .

При выделении узла для конвейерных заданий используйте метку, например:

stage("stage 1"){
    node("SlaveNode"){
        sh "echo \"Hello ${params.NAME}\" "
    }
}

В этих случаях блок задач и узлов будет выполняться только на ведомых устройствах с меткой SlaveNode .

5.2. Не храните слишком много истории сборки

При настройке задания мы можем указать, сколько его сборок должно храниться в файловой системе и как долго. Когда мы запускаем много сборок задания за короткое время, эта функция, известная как «Отменить старые сборки», становится полезной.

Мы видели примеры, когда предел истории был установлен слишком высоким, что приводило к сохранению избыточных сборок. Кроме того, в этих условиях Дженкинсу приходилось загружать много старых сборок.

5.3. Очистить старые данные Дженкинса

Продолжая предыдущее предложение для данных сборки, еще один ключевой элемент, который нужно знать, — это старые функции управления данными. Дженкинс, как мы знаем, управляет заданиями и хранит данные в файловой системе. Формат данных может измениться, когда мы предпримем такие действия, как обновление нашего ядра, установка или обновление плагина.

Дженкинс сохраняет старый формат данных в файловой системе и загружает новый формат в память в этой ситуации. Это очень полезно, если нам нужно откатить обновление, но бывают случаи, когда в ОЗУ загружается слишком много данных. Медленная реакция пользовательского интерфейса и даже проблемы с нехваткой памяти являются признаками высокого использования памяти. Рекомендуется открыть предыдущую страницу управления данными, чтобы избежать таких ситуаций:

5.4. Определите правильный размер кучи

Опция максимального размера кучи используется многими текущими Java-приложениями. Существует важный аспект JVM, о котором следует помнить при определении размера кучи. UseCompressedOops — это название этой функции, и она работает только на 64-битных платформах, которые использует большинство из нас. Он уменьшает указатель объекта с 64 до 32 бит, экономя значительный объем памяти.

Этот флаг включен по умолчанию для куч размером до 32 ГБ (чуть меньше) и перестает работать с кучами большего размера. Куча должна быть расширена до 48 ГБ, чтобы компенсировать потерянную емкость. В результате при определении размера кучи рекомендуется не превышать 32 ГБ.

Мы можем использовать следующую команду ( jinfo включена в JDK), чтобы увидеть, установлен ли флаг:

jinfo -flag UseCompressedOops <pid>

5.5. Настройте сборщик мусора

Сборщик мусора — это система управления памятью, работающая в фоновом режиме.

Его основная цель — найти неиспользуемые объекты в куче и освободить содержащуюся в них память. Приложение Java может зависнуть в результате некоторых действий GC (помните зависание пользовательского интерфейса?). Это, скорее всего, произойдет, если наше приложение имеет огромную кучу (более 4 ГБ). Чтобы уменьшить время задержки в этих обстоятельствах, требуется оптимизация GC. После решения этих проблем в нескольких установках Jenkins мы пришли к следующим рекомендациям:

• Включить G1GC — самую последнюю реализацию сборщика мусора (по умолчанию в JDK9).
• Включите ведение журнала GC — это поможет в будущем мониторинге и настройке.
• При необходимости настройте GC с дополнительными флагами
• Продолжайте следить

6. Заключение

В этом кратком руководстве мы впервые обсудили распределенную архитектуру master-slave в Jenkins. После этого мы рассмотрели несколько вариантов ручного запуска, остановки и перезапуска Jenkins. Наконец, мы изучили различные конфигурации в Jenkins, чтобы повысить производительность.

Если мы посвятим некоторое время Jenkins и будем следовать этим рекомендациям, мы сможем воспользоваться его многочисленными полезными возможностями, избегая при этом потенциальных опасностей.