Настройка Buildbot для поддержки SSL с помощью обратного прокси-сервера Nginx

Python, Ubuntu | Amber | Комментировать запись

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.

Заключение

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