Buildbot – это система непрерывной интеграции на основе Python, предназначенная для автоматизации процессов сборки, тестирования и выпуска программного обеспечения.
В предыдущем руководстве показано, как установить мастер (/home/buildbot/master) и воркер (/home/buildbot/worker) Buildbot на одной машине Ubuntu 16.04, создать пользователя и группу для Buildbot и вручную запустить тестовую сборку.
Это руководство поможет создать unit-файл systemd для сервиса Buildbot, чтобы система инициализации сервера могла управлять процессами Buildbot.
Требования
- Сервер Ubuntu 16.04 (1 Гб RAM минимум).
- Пользователь с доступом к sudo.
- Настроенный брандмауэр.
- Установленный мастер и воркер Buildbot.
Все инструкции по настройке можно найти в руководствах:
1: Остановка сервисов
Если вы находитесь в сессии пользователя buildbot, введите exit, чтобы вернуться в сессию обычного пользователя с правами sudo.
Затем остановите мастер и воркер buildbot:
sudo buildbot stop /home/buildbot/master
sudo buildbot-worker stop /home/buildbot/worker
Каждая команда вернет:
buildbot process 1234 is dead
и укажет ID процесса. Если команда вернула:
buildmaster not running
это значит, что сервис не был запущен.
2: Создание unit-файла мастера
Создайте файл buildbot-master.service и откройте его в редакторе:
sudo nano /lib/systemd/system/buildbot-master.service
В разделе [Unit] нужно указать описание сервиса и настроить доступ к сетевым подключениям. В разделе [Service] нужно определить пользователя и группу, которые запускают процесс (в данном случае это buildbot), указать рабочий каталог и добавить команду для запуска мастера. Раздел [Install] указывает, что сервис должен запускаться как часть многопользовательской системы.
[Unit]
Description=BuildBot master service
After=network.target
[Service]
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/master
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
ExecStart=/usr/local/bin/buildbot start \
--nodaemon
[Install]
WantedBy=multi-user.target
Сохраните и закройте файл. Чтобы протестировать его, запустите сервис:
sudo systemctl start buildbot-master
Проверьте состояние сервиса:
sudo systemctl status buildbot-master
В выводе должна быть строка Active: active (running), последняя строка вывода выглядит так:
May 08 21:01:24 BuildBot-Install systemd[1]: Started BuildBot master service.
Добавьте buildmaster в автозагрузку:
sudo systemctl enable buildbot-master
Created symlink from /etc/systemd/system/multi-user.target.wants/buildbot-master.service to /lib/systemd/system/buildbot-master.service.
3: Создание unit-файла воркера
Создайте и откройте в редакторе файл buildbot-worker.service. Он будет содержать те же параметры, что и buildbot-master.service, но со значениями воркера. В разделе [Install] в WantedBy укажите buildbot-master.service, чтобы воркер запускался после мастера.
sudo nano /lib/systemd/system/buildbot-worker.service
[Unit]
Description=BuildBot worker service
After=network.target
[Service]
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/worker
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
ExecStart=/usr/local/bin/buildbot-worker start \
--nodaemon
[Install]
WantedBy=buildbot-master.service
Сохраните и закройте файл. Запустите воркер:
sudo systemctl start buildbot-worker
Проверьте его состояние с помощью команды:
sudo systemctl status buildbot-worker
Опять же, вывод должен содержать строку Active: active (running)и заканчиваться так:
. . .
May 08 21:54:46 BuildBot-Install systemd[1]: Started BuildBot worker service.
Добавьте воркер в автозагрузку:
sudo systemctl enable buildbot-worker.service
Created symlink from /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service to /lib/systemd/system/buildbot-worker.service.
Чтобы убедиться, что сервис запускается автоматически, перезапустите сервер.
Заключение
Теперь вы умеете создавать unit-файлы systemd, с помощью которых система инициализации сможет управлять процессами мастера и воркера Buildbot и запускать их автоматически.
Читайте также: Настройка Buildbot для поддержки SSL с помощью обратного прокси-сервера Nginx