Buildbot – это система непрерывной интеграции на основе Python, которая позволяет автоматизировать процессы сборки, тестирования и выпуска программного обеспечения. В предыдущих руководствах вы узнали, как установить Buildbot и создать unit-файл для этого сервиса. Buildbot предоставляет собственный встроенный веб-сервер, который прослушивает порт 8010. Чтобы защитить веб-интерфейс с помощью SSL, нужно настроить обратный прокси-сервер.
Данное руководство поможет настроить Nginx как обратный прокси-сервер для перенаправления запросов SSL на веб-интерфейс Buildbot.
Требования
- Подготовленный сервер Ubuntu 16.04 (читайте статью Начальная настройка сервера Ubuntu 16.04).
- 1 Гб RAM минимум.
- Предварительно установленная система Buildbot.
- Unit-файл для Buildbot.
- Установленный сервер Nginx.
- Сертификат Let’s Encrypt.
Читайте также:
- Установка Buildbot в Ubuntu 16.04
- Создание unit-файла systemd для Buildbot
- Установка Nginx в Ubuntu 16.04
- Создание сертификата Let’s Encrypt для Nginx в Ubuntu 16.04
1: Настройка Nginx
Согласно руководству Создание сертификата Let’s Encrypt для Nginx в Ubuntu 16.04, настройки Nginx для поддержки SSL хранятся в файле /etc/nginx/sites-available/default. Создайте резервную копию этого файла.
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.ssl.bak
Откройте файл default:
sudo nano /etc/nginx/sites-available/default
Теперь нужно добавить в него настройки обратного прокси-сервера. Сначала укажите логи доступа и ошибок в блоке server для SSL.
. . .
server {
# SSL Configuration
#
. . .
# include snippets/snakeoil.conf;
access_log /var/log/nginx/buildbot.access.log;
error_log /var/log/nginx/buildbot.error.log;
. . .
Поскольку все запросы будут направляться в Buildbot, нужно удалить или закомментировать стандартную строку try_files (иначе сервер вернет ошибку 404 и запросы не дойдут до Buildbot).
Примечание: В отличие от большинства приложений, с включенным параметром try_files на запрос к document root BuildBot возвращает код ответа 200. Если ресурсы кэшируются браузером, Buildbot может работать, если нет – система вернет пустую страницу.
Затем нужно указать параметры проксирования. Строка proxy_params будет добавлять в логи имя хоста, протокол клиентского запроса и IP-адрес клиента. Строка proxy_pass указывает адрес и протокол проксируемого сервера (в данном случае это сервер Buildbot с доступом по localhost и порту 8010).
. . .
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404;
# Reverse proxy settings
include proxy_params;
proxy_pass http://localhost:8010;
}
. . .
После этого блока нужно настроить дополнительные блоки /sse и /ws.
- SSE, или Server Sent Event (события, посылаемые сервером) – это более простой и REST-совместимый протокол, чем WebSockets. Он позволяет клиентам подписываться на события. Конечной точке SSE Buildbot требуется собственный параметр proxy_pass, также нужно отключить proxy_buffering.
- WebSocket – это протокол обмена сообщениями между веб-сервером и браузером. Как и SSE, он требует собственный параметр proxy_pass. Для отправки заголовков необходима дополнительная конфигурация. Больше о параметрах WebSocket можно узнать в документации.
. . .
# Server sent event (sse) settings
location /sse {
proxy_buffering off;
proxy_pass http://localhost:8010/sse/;
}
# Websocket settings
location /ws {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://localhost:8010/ws;
proxy_read_timeout 6000s;
}
. . .
Сохраните и закройте файл.
В файле ssl_params.conf нужно увеличит значение ssl_session_timeout. Проект рекомендует 1440 минут (24 часа) – это позволит выполнить сложную сборку.
sudo nano /etc/nginx/snippets/ssl-params.conf
Добавьте в конец файла:
ssl_session_timeout 1440m;
Сохраните и закройте файл.
Примечание: Образец конфигурационного файла Nginx в документации Buildbot содержит строку ssl_session_cache со значением 1440 Мб, что позволяет поддерживать более 5 миллионов соединений. В руководстве используется более щадящее значение в 10 Мб. Каждый мегабайт может хранить около 4000 сессий, следовательно, 10 Мб может хранить около 40 000 сессий; этого достаточно в большинстве случаев.
Перезапускать Nginx до настройки Buildbot не нужно. Пока что достаточно проверить ошибки в настройках.
sudo nginx -t
Если ошибок нет, команда вернёт:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Если команда обнаружила ошибки, исправьте их и повторите проверку.
2: Настройка Buildbot
Интерфейс Buildbot использует ссылки на root; потому для правильной работы ссылок ему нужен базовый URL-адрес, определенный в файле master.cfg.
sudo nano /home/buildbot/master/master.cfg
Найдите buildbotURL и измените http на https, вместо localhost укажите своё доменное имя.
Важно! Обязательно укажите https и поставьте слеш.
. . .
c['buildbotURL'] = "https://your.ssl.domain.name/"
. . .
Также мастер не должен принимать прямые соединения от воркеров, работающих на других нодах. Для этого нужно настроить локальный интерфейс loopback. Закомментируйте или замените строку c[‘protocols’] = {‘pb’: {‘port’: 9989}} следующей строкой:
. . .
c['protocols'] = {"pb": {"port": "tcp:9989:interface=127.0.0.1"}}
. . .
Сохраните и закройте файл.
Теперь нужно установить модуль service_identity, который предоставляет инструмент для валидации сертификата.
sudo -H pip install service_identity
Если вы не установите этот модуль, Buildbot всё равно перезапустится, но выдаст предупреждение « You do not have a working installation of the service_identity module» в выводе команды status.
3: Перезапуск сервисов
Теперь можно перезапустить Nginx:
sudo systemctl restart nginx
Команда systemctl не выводит результат некоторых команд, потому проверить состояние Nginx нужно с помощью команды status:
sudo systemctl status nginx
В выводе должна быть строка Active: active (running), а в конце будут такие строки:
May 08 18:07:52 buildbot-server systemd[1]:
Started A high performance web server and a reverse proxy server.
Затем нужно перезапустить buildmaster:
sudo systemctl restart buildbot-master
sudo systemctl status buildbot-master
В выводе должна быть строка Active: active (running), а в конце будет такая строка:
May 10 21:28:05 buildbot-server systemd[1]: Started BuildBot master service.
Чтобы перезапустить воркер, введите:
sudo systemctl restart buildbot-worker
sudo systemctl status buildbot-worker
Опять же, вывод должен содержать строку Active: active (running) и заканчиваться так.
May 10 21:28:05 buildbot-server systemd[1]: Started BuildBot worker service.
Теперь можно проверить работу обратного прокси-сервера. Попробуйте посетить сайт по http, сервер должен перенаправить запрос на https и открыть сайт Buildbot.
Откройте браузер и введите:
http://your.ssl.domain.name
Примечание: Вместо your.ssl.domain.name укажите свой домен.
Нажмите enter. После этого в начале URL-адреса появится https.
Спустя пару минут вы можете убедиться, что Web Socket и Server Sent Events проксируются правильно.
Запросите каталог /sse.
https://your.ssl.domain.name/sse
Вы увидите страницу:
event: handshake
data: 2b6977f1-e4dc-4b2f-840d-10ac15ac6c57
Затем откройте каталог /ws. Если перенаправление прокси работает неправильно, эта ссылка вернет ошибку 404 Not Found. Если все в порядке, браузер должен вернуть следующую страницу:
AutobahnPython 17.5.1
I am not Web server, but a WebSocket Endpoint.
You can talk to me using the WebSocket protocol. […]
Поскольку встроенный веб-сервер прослушивает все интерфейсы, заблокируйте порт 8010, чтобы предотвратить незашифрованные соединения при доступе к серверу по IP-адресу:
sudo ufw deny 8010
Rule updated
Rule updated (v6)
Теперь Nginx работает как обратный прокси-сервер для Buildbot и блокирует доступ к серверу по HTTP.
Заключение
Обратный прокси-сервер включает поддержку шифрования данных и защищает учётные данные и другую конфиденциальную информацию, передаваемую с помощью веб-интерфейса.