Как мы масштабировали Jenkins менее чем за день

Масштабируйте агентов Jenkins с помощью Kubernetes

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

Jenkins - самый популярный на рынке инструмент непрерывной интеграции и непрерывной доставки (CI / CD) с открытым исходным кодом. Причина его популярности? Твердая поддержка со стороны таких организаций, как CloudBees, отличная поддержка сообщества, тысячи плагинов с огромной базой разработчиков и абсолютная простота установки и использования.

Это позволяет организациям подключать Jenkins к популярным инструментам управления версиями, таким как Git, Subversion и Mercurial; для интеграции с программным обеспечением для анализа кода, таким как SonarQube и Fortify; запускать сборки Maven и Gradle; выполнять тесты JUnit и Selenium; и многое другое.

Хотя это мощный инструмент, начать с Дженкинса несложно. Вам просто нужен веб-сервер Java, такой как Tomcat, и свободно доступный jenkins.war файл, и все готово. Есть несколько способов использовать Jenkins, и теперь я расскажу о некоторых типичных шаблонах.

Автономный сервер Jenkins

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

Конфигурация Мастер-Агента

Использование автономного сервера Jenkins имеет свои недостатки.

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

Чтобы решить эту проблему, вы можете перенести некоторые задания на разные машины, называемые агентами Jenkins. Агенты Jenkins запускают небольшую программу, которая связывается с мастером Jenkins, чтобы проверить, есть ли какое-либо задание, которое он может выполнить. Когда Jenkins находит запланированное задание, он передает сборку на сервер агента. Задача решена? Что ж, читайте дальше.

Масштабируемый Дженкинс

Давайте сделаем еще один шаг. Вам не нужны статические серверы, чтобы разгрузить ваши рабочие места в Jenkins по простой причине - CI - это пик.

У вас нет сборок, работающих 24 часа в сутки, семь дней в неделю, и в течение всего времени, в течение которого серверы простаивают, это просто пустая трата ресурсов сервера.

Если вы запустите оркестратор контейнеров, такой как Kubernetes, вы можете заставить Дженкинса делать более умные вещи. Идея проста. У вас есть мастер Jenkins, который отвечает за конфигурацию хостинга и распределение заданий между несколькими агентами. Однако вам не обязательно, чтобы агенты существовали заранее - их можно создавать на лету, когда они требуются.

Это упрощает жизнь во многих отношениях:

Вам не нужно планировать мощность своего сервера Jenkins

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

Все может быть еще лучше, если вы запустите свой кластер в облачном провайдере, таком как Google Cloud Platform, как это сделали мы. Google Kubernetes Engine (GKE) не только позволяет масштабировать контейнеры по горизонтали, но также добавляет или удаляет рабочие узлы кластера в зависимости от нагрузки на кластер, что дает вам практически бесконечную емкость для масштабирования.

Вы можете запускать сборки параллельно

Больше не нужно планировать исполнителей и ограничивать их; вместо этого Дженкинс развернет экземпляр агента и запустит в нем вашу сборку. Задача решена!

Распределение нагрузки равномерное

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

Возможно автоматическое лечение

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

Это экономит много времени на устранение неполадок, поскольку теперь агенты являются незаменимыми ресурсами. Если агент не работает, Дженкинс попросит Kubernetes удалить его и создать еще один. Простой!

Как мы использовали Дженкинса?

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

Поскольку тогда у нас не было Kubernetes, единственные варианты, которые у нас были, - это либо выбрать конфигурацию главного агента через серверы, либо масштабировать сервер по вертикали, добавив больше ЦП и памяти. Мы выбрали второе, так как это было для нас быстрее и удобнее. Однако мы поняли, что это ненадолго, и начали искать альтернативные варианты.

Как мы решили проблему

Как-то времена менялись, и технический директор компании решил продолжить облачную стратегию. Хорошо для нас. Мы решили переместить наш Jenkins в облако и перенести его в кластер Kubernetes, который мы создали и в который перенесли все наши инструменты. Просто, не правда ли? Давайте разберемся.

У нас было два варианта: либо поместить мастер в контейнер и использовать его отдельно, либо создать масштабируемый Jenkins с помощью Kubernetes. Мы придумали следующую архитектуру:

Одна копия мастера Jenkins работает как плоскость управления. Мастер Jenkins - это место, где все пользователи входят в систему и создают свои рабочие места и управляют ими.

Затем мы используем Kubernetes для развертывания дополнительных контейнеров агента Jenkins, когда кто-то запускает сборку; запускает задание в контейнере; и, в случае успеха, удаляет контейнер.

Давайте узнаем, как можно настроить аналогичную конфигурацию.

Создание главного образа Docker для Jenkins

Мы создали главный образ Docker Jenkins, используя следующий файл Dockerfile.

Создайте образ Docker:

docker build -t <your-docker-registry>/jenkins-master:0.0.1 .

Отправьте образ Docker в реестр Docker:

docker push <your-docker-registry>/jenkins-master:0.0.1

Dockerfile для мастера прост, и мы не устанавливали в него какое-либо программное обеспечение, так как ему не нужно запускать сборки, а только управлять агентами. Вы можете настроить Dockerfile в соответствии со своими требованиями.

Загрузка главного экземпляра Jenkins

Затем мы создали главный экземпляр Jenkins, используя файл манифеста Kubernetes, аналогичный приведенному ниже.

Файл манифеста определяет следующее:

• Учетная запись службы с именем jenkins в пространстве имен по умолчанию
• Привязка роли кластера, jenkins-crb, которая связывает учетную запись службы jenkins с ролью кластера cluster-admin. Это позволит мастеру Jenkins взаимодействовать и аутентифицироваться с кластером Kubernetes и выполнять cluster-admin задачи, такие как запуск и удаление модулей.
• Требование постоянного тома jenkins-pv-claim, которое запрашивает том 30 ГБ для сохранения данных Jenkins.
• Развертывание, которое раскручивает главный контейнер Jenkins с использованием учетной записи службы jenkins и тома jenkins-pv-claim и предоставляет порт 8080 (который является портом пользовательского интерфейса) и 50000 (который является портом JNLP)
• Служба, которая предоставляет мастер Jenkins на IP-адресе кластера.
• Входящий ресурс, который представляет услугу клиентам jenkins.example.com или по любому выбранному вами URL.

Вышеупомянутая конфигурация использует входящий трафик для пропуска трафика. Вы можете выбрать выставление Jenkins на балансировщике нагрузки или NodePort. Вам нужно изменить значения в соответствии с вашими требованиями, а затем применить файл манифеста с помощью kubectl apply -f <manifest_file>. Получите доступ к Jenkins по jenkins.example.com (или по указанному вами URL-адресу) из своего браузера.

Создание образа агента Docker

Мы решили использовать другое изображение для агента Дженкинса по очень веской причине. Образ агента Docker имеет другое назначение. Идея в том, что он не заботится об управлении вашей работой, а вместо этого создает вашу работу. Поэтому мы должны были убедиться, что в нем установлены все требования.

Поскольку приложения, которые мы создаем, представляют собой микросервисы, которые работают в контейнерах, нам необходимо включить среду выполнения Docker в подчиненный контейнер Jenkins, чтобы мы могли запускать сборки Docker внутри агентов. Используемый нами Dockerfile похож на следующий:

Создайте образ Docker:

docker build -t <your-docker-registry>/jenkins-slave .

Отправьте образ Docker в реестр Docker:

docker push <your-docker-registry>/jenkins-slave

Настройка кластера Kubernetes на Jenkins

Теперь, когда у нас есть готовый и отправленный образ агента Docker, следующим шагом будет настройка Jenkins для использования Kubernetes для раскрутки копий контейнера агента при запуске сборки. Мы выполнили следующие шаги:

Получите URL-адрес или свой сервер Kubernetes API, запустив kubectl cluster-info | grep master.

Перейдите в настройки облака Jenkins ([your_jenkins_url]/configureClouds/) и выполните следующие действия:

Примените и сохраните конфигурацию.

Отключение главного исполнителя

Чтобы гарантировать, что мастер просто действует как плоскость управления и не создает задания внутри себя, нам пришлось установить количество исполнителей на мастере равным 0.

Для этого перейдите к [your_jenkins_url]/computer/(master)/configure, установите исполнителей на 0 и сохраните.

Тестирование конфигурации

Создайте фристайл-задание с именем job-1 и этап сборки с исполняемой оболочкой со следующим содержимым:

Создайте job-2, идентичный job-1.

Запустите оба задания вместе, и вы должны заметить, что оба задания должны запускать новый модуль на кубернетах и ​​выполняться параллельно.

Проверьте консольный вывод job-1 и job-2, и он должен выглядеть следующим образом:

Дальнейшее чтение

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