Вступление
Buildbot - это система непрерывной интеграции на основе Python для автоматизации процессов сборки, тестирования и выпуска программного обеспечения. В предыдущих уроках мы installed Buildbot и https://www.digitalocean.com/ community / tutorials / how-to-create-systemd-unit-files-for-buildbot [созданные файлы модулей systemd], чтобы позволить системе инициализации сервера управлять процессами. Buildbot поставляется с собственным встроенным веб-сервером, который прослушивает порт 8010, и для защиты веб-интерфейса с помощью SSL нам потребуется настроить обратный прокси-сервер.
В этом руководстве мы покажем, как настроить Nginx в качестве обратного прокси-сервера, чтобы перенаправлять запросы браузера, защищенные SSL, в веб-интерфейс Buildbot.
Предпосылки
Чтобы следовать этому уроку, вам понадобится:
-
* Один сервер Ubuntu 16.04 с не менее 1 ГБ ОЗУ *, настроенный для пользователя без полномочий root + sudo + и брандмауэра, следуя https://www.digitalocean.com/community/tutorials/initial-server-setup -with-ubuntu-16-04 [Руководство по первоначальной настройке сервера Ubuntu 16.04]
Кроме того, вам необходимо пройти следующие уроки на сервере:
Когда вы выполните эти требования, вы готовы начать.
Шаг 1 - Настройка Nginx
В обязательном учебном пособии Как защитить Nginx с помощью Let’s Encrypt в 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Во-первых, мы добавим определенные журналы доступа и ошибок в блок SSL + сервер +.
/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию
. . .
server {
# SSL Configuration
#
. . .
# include snippets/snakeoil.conf;
. . .Далее мы настроим параметры прокси.
Поскольку мы отправляем все запросы в Buildbot, нам нужно удалить или закомментировать стандартную строку + try_files +, которая, как написано, вернет 404 ошибки до того, как запросы достигнут Buildbot.
Затем мы добавим конфигурацию обратного прокси. Первая строка включает в себя поставляемый Nginx + proxy_params +, чтобы гарантировать, что информация, такая как имя хоста, протокол запроса клиента и IP-адрес клиента, будет доступна в наших файлах журнала. + Proxy_pass + устанавливает протокол и адрес прокси-сервера, который в нашем случае является сервером Buildbot, доступ к которому осуществляется на локальном хосте через порт 8010.
/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию
. . .
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 Events - более простой и более REST-совместимый протокол, чем WebSockets, которые разрешить клиентам подписываться на события. Конечная точка Buildbot SSE требует собственной настройки
+ proxy_pass +и получает выгоду от отключения+ proxy_buffering +. -
* Настройки WebSocket * WebSocket - это протокол для обмена сообщениями между веб-сервером и веб-браузерами. Как и протокол SSE, для него требуется собственный параметр
+ proxy_pass +. Дополнительная передача также требуется для передачи информации заголовка. Вы можете узнать больше об этих настройках из Nginx WebSocket прокси-документации.
/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию
. . .
# Server sent event (sse) settings
location /sse {
proxy_buffering off;
proxy_pass http://localhost:8010;
}
# 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;
proxy_read_timeout 6000s;
}
. . .После внесения этих изменений сохраните и выйдите из файла.
Наконец, мы отредактируем + ssl_params.conf + и увеличим + ssl_session_timeout + до рекомендованного для проекта значения 1440 минут (24 часа) для размещения более длинных сборок:
sudo nano /etc/nginx/snippets/ssl-params.confВ нижней части файла добавьте следующую строку:
/etc/nginx/snippets/ssl-params.conf
. . .Когда вы закончите, сохраните и выйдите из файла.
Мы не будем перезагружать Nginx до тех пор, пока не настроим Buildbot, но мы проверим нашу конфигурацию сейчас на случай, если мы допустили какие-либо ошибки:
sudo nginx -tЕсли все хорошо, команда вернет:
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulЕсли нет, исправьте обнаруженные ошибки, пока тест не пройдет.
Шаг 2 - Настройка Buildbot
Buildbot использует корневые ссылки в своем веб-интерфейсе и должен иметь базовый URL-адрес, определенный в + master.cfg + для правильной работы ссылок.
sudo nano /home/buildbot/master/master.cfgНайдите параметр + buildbotURL +, измените + http + на + https + и измените + localhost + на свой домен. Удалите спецификацию порта (+: 8010 +), поскольку Nginx будет передавать запросы прокси, сделанные на обычные веб-порты. * Важно: * Протокол должен быть + https +, а определение должно содержать завершающий слеш.
/home/buildbot/master/master.cfg
. . .
c['buildbotURL'] = "http:///"
. . .Мы также гарантируем, что мастер не будет принимать прямые соединения от работников, работающих на других хостах, путем привязки к локальному интерфейсу обратной связи. Закомментируйте или замените существующую строку протокола, + c ['protocol'] = {'pb': {'port': 9989}} +, следующим текстом:
/home/buildbot/master/master.cfg
. . .
c['protocols'] = {"pb": {"port": "tcp:9989:interface=127.0.0.1"}}
. . .Когда вы закончите, сохраните и выйдите из файла.
Теперь, когда мы используем HTTPS и доменное имя, мы установим https://service-identity.readthedocs.io/en/stable/ [+ service_identity + module], который предоставляет инструменты для определения действительного сертификата для целевое назначение.
sudo -H pip install service_identityЕсли мы пропустим этот шаг, Buildbot все равно перезапустится, но выдаст предупреждение пользователя «У вас нет рабочей установки модуля service_identity», которое будет видно в выходных данных команды systemd + status +.
Шаг 3 - Перезапуск Сервисов
Теперь мы готовы перезапустить Nginx:
sudo systemctl restart nginxПоскольку + systemctl + не обеспечивает вывод, мы будем использовать его команду + status +, чтобы убедиться, что Nginx запущен.
sudo systemctl status nginxВыходные данные должны выделять «Active: active (выполняется)» и заканчиваться примерно так:
OutputMay 08 18:07:52 buildbot-server systemd[1]:
Started A high performance web server and a reverse proxy server.Далее мы перезапустим buildmaster и работника, используя + systemctl +, который мы настроили в https://www.digitalocean.com/community/tutorials/how-to-create-systemd-unit-files-for-buildbot [предыдущий урок].
Сначала проверьте файл конфигурации на наличие синтаксических ошибок:
sudo buildbot checkconfig /home/buildbot/master/OutputConfig file is good!Если об ошибках не сообщается, перезапустите службу:
sudo systemctl restart buildbot-master
sudo systemctl status buildbot-masterВывод должен выделять «Active: active (выполняется)» и заканчиваться чем-то вроде:
OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot master service.Далее мы перезапустим работника:
sudo systemctl restart buildbot-worker
sudo systemctl status buildbot-workerОпять же, выходные данные должны выделять «Active: active (выполняется)» и в этом случае заканчиваться примерно так:
OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot worker service.Теперь, когда мы перезапустили Nginx, мастера сборки и работника, мы готовы проверить, работает ли обратный прокси-сервер должным образом. Когда мы заходим на сайт через + https, мы должны быть перенаправлены на` + https` и успешно попасть на наш сайт Buildbot.
В веб-браузере введите «http: //», заменив свой домен на «+ your.ssl.domain.name». После того, как вы нажмете ввод, URL должен начинаться с + https +, а строка адреса должна указывать, что соединение защищено. + изображение: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-secure.png [Снимок экрана домашней страницы Buildbot с защищенным URL-адресом]
Далее, мы возьмем момент и увидим, что отправленные события веб-сокета и сервера правильно проксируются.
Сначала зайдите в каталог + / sse +. Если перенаправление работает правильно, браузер должен вернуться на следующую страницу. Обратите внимание, что страница будет продолжать загружаться, и это нормальное поведение:
изображение: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-sse-redirect.png [страница Buildbot SSE]
Затем перейдите в каталог / ws. Если перенаправление прокси не правильно, посещение каталога + / ws + вернет ошибку +404 Not Found +. Если все хорошо, браузер должен вернуть следующую страницу: + image: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-ws-redirect.png [Buildbot WebSocket page]
Наконец, поскольку встроенный веб-сервер прослушивает все интерфейсы, мы удалим наше правило, разрешающее внешний трафик на порт 8010, чтобы предотвратить незашифрованные соединения при доступе к серверу по IP-адресу:
sudo ufw delete allow 8010OutputRule updated
Rule updated (v6)Теперь мы настроили Nginx в качестве обратного прокси-сервера и запретили пользователям доступ к Buildbot с помощью + HTTP +.
Заключение
В этом руководстве мы настроили Nginx в качестве обратного прокси-сервера для встроенного веб-сервера Buildbot для защиты наших учетных данных и другой информации, передаваемой через веб-интерфейс. Если вы новичок в Buildbot, вы можете изучить руководство The Quick Tour проекта Buildbot. Когда вы будете готовы узнать, как настроить полный процесс непрерывной интеграции, ознакомьтесь с нашими https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-with-buildbot-on -ubuntu-16-04 [Как настроить непрерывную интеграцию с Buildbot в Ubuntu 16.04].