Что такое jenkins slave
linux-notes.org
Я ранее рассказывал как можно установить Jenkins на сервер. Сейчас, я хотел бы поделится своей заметкой по установке Jenkins-а и Jenkins-slave. Я для своего примера, буду использовать Docker + docker-compose чтобы поднять все необходимое. Конечно, это не самый хороший способ сделать отказоустойчевый сервер. Но тем не менее — у меня на маке все работает. Тем более, я настроил данное чудо не для ПРОД-а, а для локальной лабы. Чтобы более поробно изучить дженкинс. Хотелось бы сказать, ребят, если вы будете выбирать между CI/CD — не берите дженкинс (ИМХО). Есть ума других крутых тулов. Я хочу многие из них попробовать и конечно же — написать статейку в виде заметки.
Установка Jenkins в Unix/Linux
Как я говорил ранее, я буду использовать докер для установки дженкинса. ОС которую я использую — Mac OS X. Многие скажует, да какая разница, ты же запускаешь в докере. Но на самом деле — докер немного по разному работает на разных Unix/Linux ОС. Немного пришлось поплясать с бубном, чтобы зависти все это чудо на маке.
Мой docker-compose.yml файл выглядит следующим образом:
Кто работает с докер-компос, тот сможет прочитать данный файл и понять в чем дело. Но если кто-то не знает, я немного расскажу на что стоит заострить внимание. И так:
Я данным сервисом запускаю 3 контейнера, — gitlab, jenkins (master) и socat. Gitlab — система управления репозиториями кода для Git. данные конфиг делался универсальным и чтобы он работал в любом месте и на Unix/Linux системах. Если что-то не будет работать, то стоит рассмотреть поле DNS (в данном поле прописаны ДНС-ы которые служат резолвом в самих докер-контейнера. Иногда это уместно, когда на работе или дома используются свои ДНС, а остальные блокируются).
Можно заюзать статью чтобы проверить, какие ДНС-ы используются:
PS: Для данного поля стоит использовать, ТОЛЬКО 3 DNS ЗАПИСИ, не более! Иначе, они просто не будут работать и моугт сломать контейнер(ы).
Многие посмотрет на «socat» конейнер и спросят, а зачем он тут вообще упал? Так вот, он тут служит перенаправлением данных с порта (2375) на Unix сокет (/var/run/docker.sock). И сново могут полететь вопросы, а зачем?
Да дело в том, что докер-прогеры «не смогли» запилить «docker_opts»/»hosts» переменную в докер под Mac OS X. Данная переменная выполняет собственно аналогичные действия, но нативным спообом. Выглядит это вот так (на стороне Linux):
Т.е данную команду нужно прописать в конфиг докера, или можно запустить демон следующим образом:
Мне не совсем понятно почему нельзя было добавить такое в поддержку мака, но воркераунд найден и он работает. Вообще, такое чудо должно работать и на линуксе, но я не проверял. Если кому-то будет интересно, проверьте и напишите в комментариях результат.
На все это дело, я потратил около 7 часов времени и мне не очень было понятно почему не работает. Но в интернете нашелся пример моего бедствия. Я взял идею и опробовал ее — костыльненько, но а что поделать!
Собственно, gitlab + jenkins — готовы к использованию. Перейдем к настройке jenkins-slave.
Установка Jenkins-Slave в Unix/Linux
Стоит поставить: Docker Plugin плагин. Я еще ставил — Docker Slaves Plugin плагин, но не понял как он работает. Я покажу какие плагины у меня имеются в дженкинсе, возможно кому-то пригодится, но для начала, скачаем CLI для Jenkins:
Мои установленные плагины:
После того как плагины поставились, открываем дженкинс и переходим:
Кликаем по «Docker Cloud Details» чтобы ввести необходимые данные:
Задаем имя, у меня это — Docker. В поле «Docker Host URI» прописываем хост и порт который юзает докер. У меня — «tcp://172.6.6.2:2375». Почему-то, не прокатило использование хостнейма от соката в этом случае. Может исправлю попозже или на крайний случай — можно оставить как есть, т.к эта лаба служит в качестве примера. Стоит отметить, если у вас используется авторизация к докер хосту, то стоит заполнить «Server credentials». Если нажать на «Advanced», то выпадет список дополнительных параметров которые можно заполить тоже:
Нажмите на «Test connection» чтобы получить тестовое подключение (чтобы убедится что коннекшен работает как нужно).
Идем дальше, клацаем по «DOCKER AGENT TEMPLATES…» Я привел к виду:
Заполнил поле и лейблу как мне угодно. В поле «Docker image» я прописал Jenkins-Slave образ, который я взял с официального докер-регистра — «jenkinsci/slave». Так же, по необходимости заполните все необходимые поля (креденшелы, дополнительные опции).
Первый билд (джоба) на Jenkins-е
Создаем проект под свои нужды. Потом, создаем «Pipeline» проект, например:
Тестовый pipeline projec для Java
Нажимаем на «OK» и сейчас создадим все необходимое.
Находим «Run the build inside Docker containers» и ставим чекбокс. В поле «Docker Image» ставим наш образ, у меня — «jenkinsci/jnlp-slave:latest». Так же, можно прописать «Advanced settings» опции и выставить использовании по памяти. У меня все имеет вид:
Идем дальше, находим «Pipeline» вкладку и заполняем ее под свои нужды. У меня все приведено и имеет вид:
Т.е я заюзал свой гитлаб сервер. В нем есть репозиторий с проектом. Так же, добавил подключение к гитлабу. Собственно, все готово, можно нажимать на «SAVE»!
Слева вверху, нажимаем на «Build Now» и смотрим что получилось!
Видно что поднялся слейв и запустил джобу. Можно открыть ее и поглядеть статус выполнения:
Я думаю что на этом пока все, статья «Установка Jenkins и Jenkins-slave в Unix/Linux» завершена.
Непрерывная интеграция и развертывание (Deployment) с помощью Jenkins
Сначала мне было трудно работать с Jenkins, потому что большинство статей по его установке и настройке устарели. Поэтому я пишу об этом, чтобы облегчить кому-то работу и сделать так, чтобы им не пришлось проходить через то, что пришлось пройти мне, устанавливая его.
Прежде всего, что такое Jenkins?
Jenkins — это средство автоматизации с открытым исходным кодом, которое используется для автоматизированного создания, тестирования и развертывания программного обеспечения, упрощая непрерывную интеграцию и непрерывное развертывание для пользователей.
По сути, это означает, что Jenkins (и многие другие инструменты) позволяют автоматизировать процесс развертывания или предоставления изменений в вашем программном обеспечении пользователям сразу после того, как эти изменения готовы. Представим насколько удобно пользователям видеть обновленные сайты сразу после объединения PR с master (или main).
Почему именно Jenkins?
У него сильное сообщество, поэтому найти поддержку не проблема.
Jenkins можно легко настроить, и я надеюсь доказать это в данной статье, так что читайте дальше.
В этом руководстве мы узнаем, как выполнить CI/CD для приложения Node с помощью Jenkins. Давайте начнем с определения всех шагов, которые мы предпримем, а затем подробно объясним их ниже:
Создайте репозиторий GitHub для приложения node
Создайте простое приложение node и поместите его на GitHub
Создайте приложение Heroku для развертывания
Добавьте веб-хук GitHub для внесения изменений в Jenkins
Сконфигурируйте приложение с помощью Jenkins
Добавьте плагины GitHub в Jenkins
Сконфигурируйте Jenkins для развертывания на Heroku после успешного тестирования
Необходимые условия
Учетная запись на GitHub. Можно зарегистрироваться здесь.
Учетная запись Heroku. Можно зарегистрироваться здесь.
Учетная запись на GitHub. Можно зарегистрироваться здесь.
Учетная запись Heroku. Можно зарегистрироваться здесь.
Итак, давайте начнем!
После создания репозитория, клонируйте его на локальную машину с помощью следующей команды:
Не забудьте изменить repository_url на свой.
Вы можете удалить или изменить то, что находится в блоке скриптов вашего файла package.json, и добавить start и test для запуска и тестирования приложения:
Мы будем использовать express для нашего примера приложения node, поэтому инсталлируйте его, запустив эту команду в терминале:
Далее создайте файл index.js, который будет служить точкой входа в наше приложение node, и добавьте в него следующие строки:
Запустите npm start и зайдите на http://localhost:4000/ через браузер для просмотра приложения Node, на экране появится Hello world.
Далее мы добавим пару тестов в наше приложение, впоследствии, с помощью CI, мы должны убедиться, что тесты доступны и выполняются перед тем как объединить изменения.
Итак, вернитесь в терминал, убедитесь, что вы находитесь в корневом каталоге вашего проекта, и установите пакеты jest и supertest с помощью следующей команды:
Далее в корневом каталоге проекта создайте папку и назовите ее __test__ (два знака подчеркивания, предшествующий и завершающий). Внутри этой папки __test__ создайте файл index.test.js и добавьте в него по крайней мере следующий код (вы всегда можете сделать свои тесты более полными).
Запустите npm test или npm run test в терминале, и вы убедитесь, что тест(ы) прошел(и):
Теперь, когда наш код запущен и тесты пройдены, можно закоммитить изменения и отправить их на GitHub.
Войдите в свою панель управления Heroku.
Посмотрите в правый верхний угол и нажмите на New.
Выберите Create new app (Создать новое приложение).
Добавьте App name (название приложения) по своему выбору и выберите регион (Choose a region), в котором вы находитесь.
Нажмите Создать приложение (Create app).
Вернитесь в терминал вашего проекта и login (войдите) в Heroku с помощью Heroku CLI. Если вы еще не установили Heroku CLI, вы можете прочесть эту статью.
После этого добавьте remote в ваш локальный репозиторий с помощью:
Затем введите код с помощью:
Это делается для того, чтобы убедиться, что все работает правильно, прежде чем автоматизировать его. Вы можете нажать open app (открыть приложение) на приборной панели приложения Heroku, чтобы проверить, правильно ли оно работает.
Откройте новый терминал и войдите на свой сервер под учетной записью пользователя non-root.
После этого мы можем обновить ядро с помощью следующей команды:
Выполните следующую команду для установки java runtime:
Выполните следующие команды одну за другой для установки Jenkins.
Теперь, когда Jenkins и все зависимости инсталлированы мы можем запустить его с помощью:
Вы можете проверить успешность запуска Jenkins, используя:
Он должен показать active:
Поскольку Jenkins выполняется на порту 8080, давайте откроем его с помощью ufw:
Вы можете проверить состояние ufw с помощью:
Теперь посетите сайт http://ip_address:8080 для настройки Jenkins, на котором вы должны увидеть экран Unlock Jenkins.
Чтобы разблокировать Jenkins, вернитесь к терминалу и введите следующую команду для отображения пароля. Скопируйте пароль и вставьте его в поле Administrator password (Пароль администратора).
На следующем экране отображается Customize Jenkins (Настроить Jenkins), нажмите на Install suggested plugins (Установите предложенные плагины).
После завершения установки мы перейдем к экрану Create First Admin User (Создание первого пользователя-администратора). Введите Username (имя пользователя), Password (пароль), Full name (полное имя) и E-mail address (адрес электронной почты) для вашего пользователя, затем Save and Continue (Сохранить и продолжить).
После этого введите IP-адрес сервера, т.е. http://ip_address:8080, затем Save and Finish (Сохранить и Завершить).
Ура, Jenkins готов! Нажмите на Start using Jenkins (Начать использование Jenkins).
В репозитории GitHub приложения перейдите в Settings (Настройки), затем на боковой панели нажмите на Webhooks. Нажмите на Add webhooks (Добавить веб-хуки) и введите url Jenkins с приставкой /github-webhook/ в поле Payload URL.
Выберите application/json для Content-type.
Выберите Just the push event для события, запускающего веб-хук.
Установите флажок Active и нажмите Add webhook. Теперь GitHub может успешно отправлять события в Jenkins.
Откройте новую вкладку или окно терминала и войдите на свой сервер с той же учетной записью пользователя non-root.
В том же терминале включите привилегии root, используя:
После переключения пользователя с правами root и инсталляции npm, Jenkins автоматически создает нового пользователя после завершения установки. Переключитесь на него с помощью этой команды.
Сгенерируйте новый ключ SSH с помощью следующей команды:
Нажмите клавишу Enter для ввода местоположения и не указывайте пароль при запросе, просто нажмите клавишу Enter.
После завершения процесса распечатайте информацию об открытом ключе с помощью:
Скопируйте открытый ключ.
Теперь войдите обратно как пользователь non-root в новом терминале.
Откройте папку authorized_keys следующей командой:
Вставьте открытый ключ id_rsa и выйдите.
Чтобы убедиться, что ключи настроены правильно, переключитесь на терминал сервера jenkins и попробуйте войти в систему как пользователь non-root, используя ssh. Вы успешно войдете в систему, если будете следовать всем вышеописанным действиям.
На приборной панели Jenkins перейдите в раздел Manage jenkins (Управление jenkins), а затем нажмите на Manage plugins (Управление плагинами).
На вкладке Available найдите github и выберите Github Integration plugin (Интеграционный плагин Github).
Нажмите на Install without restart (Установить без перезагрузки), и плагин будет установлен через несколько секунд.
Теперь, когда GitHub подключен к Jenkins, мы можем создать новый проект.
На боковой панели нажмите на New Item (Новая тема), выберите Freestyle project из предложенных вариантов и нажмите OK.
Далее вы должны попасть на страницу конфигурации, но если этого не произошло, можно открыть ее, нажав Configure на левой боковой панели.
Далее прокрутите вниз до раздела Source Code Management (Управление исходным кодом), выберите Git и добавьте Repository URL с расширением .git (тот же url, который вы использовали для клонирования репозитория).
Вы можете изменить master ветвь на main или любые другие ветви, которые вам нужны для процесса развертывания.
Нажмите на кнопку Add repository (Добавить репозиторий), чтобы добавить второй репозиторий, указывающий на ваше приложение Heroku.
Чтобы получить ссылку на репозиторий приложения Heroku, перейдите в App settings (настройки приложения) на панели управления Heroku и скопируйте ссылку.
Вернитесь на приборную панель Jenkins и вставьте эту ссылку в Repository URL.
Нам понадобятся новые учетные данные, поэтому нажмите на Add, чтобы создать их для нашего приложения Heroku.
Выберите Jenkins из списка, и у вас должно появиться всплывающее окно.
Введите username (имя пользователя) по своему выбору, но лучше всего, чтобы оно было каким-нибудь описательным. Я буду использовать heroku в качестве имени пользователя.
Далее нам нужно будет добавить Heroku Api key (Api-ключ) в поле Password
(Пароль) и Save (Сохранить). Чтобы получить Heroku Api key, перейдите на приборную панель Heroku, нажмите на Account Settings (Настройки аккаунта) и прокрутите вниз, чтобы увидеть Api key. Скопируйте его и вставьте в поле Password (Пароль).
Вы можете добавить Description (Описание) для этой учетной записи, если хотите.
Нажмите Add (Добавить), чтобы завершить создание учетной записи.
Теперь убедитесь, что в выпадающем списке выбраны новые учетные данные, которые мы только что создали. Если нет, нажмите на выпадающий список и выберите их.
Далее нажмите на advanced и добавьте Name, чтобы идентифицировать это хранилище среди других удаленных хранилищ. Это имя понадобится нам позже. Я назвал свое хранилище jenkinsTest, потому что это легко и понятно.
Далее прокрутите вниз до раздела Build Triggers и отметьте опцию GitHub hook trigger for GITScm polling (Триггер хука GitHub для опроса GITScm).
В разделе Build нажмите на кнопку Add build step (Добавить шаг сборки) и затем нажмите на Execute shell (Выполнить командную оболочку). Введите в оболочку следующий код:
Нажмите на Add post-build action (Добавить действие после сборки), выберите Git Publisher и укажите опцию Push Only If Build Succeeds (Запускать только в случае успеха сборки).
Нажмите на Add Branch (Добавить ветвь), введите имя ветви для развертывания в поле Branch to Push и добавьте Name, используемое для идентификации репозитория приложения Heroku, в поле Target remote name (мое имя было jenkinsTest, если вы помните, поэтому добавьте сюда свое).
Затем Save (сохраните).
Перейдите на приборную панель проекта, нажмите Build now (Построить сейчас) на левой боковой панели и с удовольствием наблюдайте за успешной сборкой вашего кода!
Внесите изменения в свой код и опубликуйте его на GitHub. Затем посмотрите, как ваш код будет автоматически развернут на Heroku.
Приглашаем всех желающих ознакомиться с онлайн-курсами, которые помогут прокачаться в JavaScript-разработке:
Jenkins Configure Master and Slave Nodes
Learn about the importance of the master and slave nodes and set up a sample freestyle project.
Join the DZone community and get the full member experience.
Take a look at master and slave nodes in Jenkins.
Jenkins Master and Slave Concept
A Jenkins master comes with the basic installation of Jenkins, and in this configuration, the master handles all the tasks for your build system.
If you are working on multiple projects you may run multiple jobs on each and every project. Some projects need to run on some particular nodes, and in this process, we need to configure slaves. Jenkins slaves connect to the Jenkins master using the Java Network Launch Protocol.
Jenkins Master and Slave Architecture
The Jenkins master acts to schedule the jobs and assign slaves and send builds to slaves to execute the jobs.
It will also monitor the slave state (offline or online) and getting back the build result responses from slaves and the display build results on the console output. The workload of building jobs is delegated to multiple slaves.
Steps to Configure Jenkins Master and Slave Nodes
Enter the required information.
Some required fields include:
6. Enter the Hostname in the Host field.
7. Select the Add button to add credentials. and click Jenkins.
8. Enter Username, Password, ID, and Description.
9. Select the dropdown menu to add credentials in the Credentials field.
10. Select the next dropdown to add the Host Key Verification Strategy under Non verifying Verification Strategy.
11. Select Keep this agent online as much as possible in the Availability field.
12. Click the Save button.
Creating a Freestyle Project and Running on The Slave Machine
Creating a Pipeline and Running on The Slave Machine
6. Click on Save, it will redirect to the Pipeline view page.
7. On the left pane, click the Build Now button to execute your Pipeline.
8. After Pipeline execution is completed, the Pipeline view will be as shown below.
9. We can verify the history of executed build under the Build History by clicking the build number.
10. Click on build number and select Console Output. Here you can see that the pipeline ran on a slave machine.
Jenkins: запуск Jenkins в Docker и подключение SSH Slave
Имеется две EC2, на одной будет запущен Jenkins, который будет мастером, второй EC2 надо настроить и подключить как slave для Jenkins.
Для этого – на второй машине потребуется Java, настроенная SSH авторизация по ключам, и отдельный пользователь.
На Jenkins потребуется SSH Slaves Plugin.
Начинаем со слейва.
Настройка Jenkins Unix slave
Установка Java
Подключаемся на слейв, устанавливаем Java. Тут Ubuntu, поэтому apt :
# apt install openjdk-8-jdk
Добавление пользователя
Создаём пользователя, под которым будет подключаться Jenkins:
Настройка Master
Установка Docker
Переключаемся на мастер, устанавливаем Docker:
# curl https://get.docker.com/ | bash
# chmod +x /usr/local/bin/docker-compose
# docker run hello-world
Создание пользователя
Добавляем его в группу docker :
Меняем владельца каталогов:
# chown jenkins:jenkins /jenkins/
# chown jenkins:jenkins /home/jenkins/
Настройка SSH
Т.к. это EC2, и парольная авторизация отключена – то быстрее будет просто руками скопировать ключ, чем использовать ssh-copy-id :
Добавляем его в /home/jenkins/.ssh/authorized_keys на слейве.
Проверяем SSH с мастера:
ОК, тут всё работает.
Запуск Jenkins
На мастере переключаемся на пользователя jenkins :
Создаём Compose файл:
Из лога запуска получаем пароль, заходим на Jenkins, активируем:
Добавление Jenkins Slave
Проверяем наличие плагина SSH Slaves Plugin:
Переходим в Manage Jenkins > Manage Nodes:
Сейчас тут только один хост – сам мастер:
Создаём новый слейв:
В Host Key Verification Strategy можно использовать Manually trusted, результат:
Жмём Save, переходим к агенту, слева жмём Trust SSH Host Key: