Einführung
Buildbot ist ein auf Python basierendes kontinuierliches Integrationssystem zur Automatisierung von Softwareerstellungs-, Test- und Freigabeprozessen. In den vorherigen Tutorials haben wir installed Buildbot und https://www.digitalocean.com/ community / tutorials / erstelle-systemd-unit-dateien-für-buildbot [erstellte systemd-unit-dateien], damit das init-system des servers die prozesse verwalten kann. Buildbot wird mit einem eigenen integrierten Webserver geliefert, der Port 8010 überwacht. Um die Webschnittstelle mit SSL abzusichern, müssen Sie einen Reverse-Proxy konfigurieren.
In diesem Lernprogramm wird gezeigt, wie Sie Nginx als Reverse-Proxy konfigurieren, um SSL-gesicherte Browseranforderungen an die Buildbot-Weboberfläche weiterzuleiten.
Voraussetzungen
Um diesem Tutorial zu folgen, benötigen Sie:
-
* Ein Ubuntu 16.04-Server mit mindestens 1 GB RAM *, der mit einem Benutzer ohne Rootberechtigung ("+ sudo +") und einer Firewall konfiguriert wurde. Befolgen Sie dazu die Anweisungen unter https://www.digitalocean.com/community/tutorials/initial-server-setup -with-ubuntu-16-04 [Ubuntu 16.04 Installationsanleitung für Server]
Außerdem müssen Sie die folgenden Lernprogramme auf dem Server ausführen:
Wenn Sie diese Anforderungen erfüllt haben, können Sie beginnen.
Schritt 1- Konfigurieren von Nginx
Im vorausgesetzten Lernprogramm wird unter https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04 beschrieben, wie Nginx mit Let’s Encrypt gesichert wird Unter Ubuntu 16.04] haben wir Nginx so konfiguriert, dass SSL in der Datei + / etc / nginx / sites-available / default + verwendet wird. Bevor wir beginnen, erstellen wir eine Sicherungskopie unserer funktionierenden Konfigurationsdatei:
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.ssl.bakAls nächstes öffnen wir "+ default" und fügen Ihre Reverse-Proxy-Einstellungen hinzu.
sudo nano /etc/nginx/sites-available/defaultZunächst werden im SSL-Block "+ server +" bestimmte Zugriffs- und Fehlerprotokolle hinzugefügt.
/ etc / nginx / sites-available / default
. . .
server {
# SSL Configuration
#
. . .
# include snippets/snakeoil.conf;
. . .Als Nächstes konfigurieren wir die Proxy-Einstellungen.
Da wir alle Anfragen an Buildbot senden, müssen wir die Standardzeile "+ try_files +" löschen oder auskommentieren, die wie geschrieben 404-Fehler zurückgibt, bevor Anfragen an Buildbot gelangen.
Anschließend fügen wir die Reverse-Proxy-Konfiguration hinzu. Die erste Zeile enthält das von Nginx bereitgestellte "+ proxy_params ", um sicherzustellen, dass Informationen wie der Hostname, das Protokoll der Clientanforderung und die Client-IP-Adresse in unseren Protokolldateien verfügbar sind. Das ` proxy_pass +` legt das Protokoll und die Adresse des Proxy-Servers fest, in unserem Fall des Buildbot-Servers, auf den auf dem lokalen Host über Port 8010 zugegriffen wird.
/ etc / nginx / sites-available / default
. . .
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;
}
. . .Direkt nach dieser Zeilengruppe konfigurieren wir zwei zusätzliche Speicherorte: "+ / sse " und " / ws +":
-
* Einstellungen für Server Sent Event (SSE) * Server Sent Events sind ein einfacheres, REST-kompatibleres Protokoll als WebSockets Ermöglichen Sie Clients, Ereignisse zu abonnieren. Der Buildbot-SSE-Endpunkt benötigt eine eigene Einstellung für "+ proxy_pass " und profitiert vom Deaktivieren von " proxy_buffering +".
-
* WebSocket-Einstellungen * WebSocket ist ein Protokoll für das Versenden von Nachrichten zwischen dem Webserver und Webbrowsern. Wie das SSE-Protokoll erfordert es eine eigene Einstellung für "+ proxy_pass +". Zusätzliche Konfiguration ist auch erforderlich, um Header-Informationen zu übergeben. Weitere Informationen zu diesen Einstellungen finden Sie in der Nginx WebSocket-Proxy-Dokumentation.
/ etc / nginx / sites-available / default
. . .
# 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;
}
. . .Speichern und schließen Sie die Datei, sobald Sie diese Änderungen vorgenommen haben.
Abschließend bearbeiten wir die Datei "+ ssl_params.conf " und erhöhen das " ssl_session_timeout +" auf die vom Projekt empfohlene Einstellung von 1440 Minuten (24 Stunden), um längere Builds zu berücksichtigen:
sudo nano /etc/nginx/snippets/ssl-params.confFügen Sie am Ende der Datei die folgende Zeile hinzu:
/etc/nginx/snippets/ssl-params.conf
. . .Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Wir werden Nginx erst neu starten, nachdem wir Buildbot konfiguriert haben, aber wir werden unsere Konfiguration jetzt testen, falls wir Fehler gemacht haben:
sudo nginx -tWenn alles in Ordnung ist, gibt der Befehl Folgendes zurück:
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulWenn nicht, beheben Sie die gemeldeten Fehler, bis der Test bestanden ist.
Schritt 2 - Buildbot konfigurieren
Buildbot verwendet root-relative Links in seiner Weboberfläche und muss die Basis-URL in der + master.cfg + definiert haben, damit Links ordnungsgemäß funktionieren.
sudo nano /home/buildbot/master/master.cfgSuchen Sie die Einstellung "+ buildbotURL ", ändern Sie " http " in " https " und " localhost " in Ihre Domain. Entfernen Sie die Portspezifikation (`: 8010 `), da Nginx Anforderungen an die herkömmlichen Web-Ports weiterleitet. * Wichtig: * Das Protokoll muss " https +" sein und die Definition muss den abschließenden Schrägstrich enthalten.
/home/buildbot/master/master.cfg
. . .
c['buildbotURL'] = "http:///"
. . .Wir werden auch sicherstellen, dass der Master keine direkten Verbindungen von Workern akzeptiert, die auf anderen Hosts ausgeführt werden, indem er sich an die lokale Loopback-Schnittstelle bindet. Kommentieren Sie die vorhandene Protokollzeile aus oder ersetzen Sie sie durch "+ c ['protocols'] = {'pb': {'port': 9989}} +":
/home/buildbot/master/master.cfg
. . .
c['protocols'] = {"pb": {"port": "tcp:9989:interface=127.0.0.1"}}
. . .Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Da wir nun HTTPS und einen Domainnamen verwenden, installieren wir das https://service-identity.readthedocs.io/en/stable/ [+ service_identity + -Modul], das Tools zur Feststellung der Gültigkeit des Zertifikats bereitstellt den beabsichtigten Zweck.
sudo -H pip install service_identityWenn wir diesen Schritt überspringen, wird Buildbot immer noch neu gestartet, gibt jedoch die Meldung "Sie haben keine funktionierende Installation des service_identity-Moduls" aus, die in der Ausgabe des systemd-Befehls "+ status +" angezeigt wird.
Schritt 3 - Neustarten der Dienste
Jetzt können wir Nginx neu starten:
sudo systemctl restart nginxDa "+ systemctl " keine Ausgabe liefert, verwenden wir den Befehl " status +", um sicherzustellen, dass Nginx ausgeführt wird.
sudo systemctl status nginxDie Ausgabe sollte "Active: active (running)" markieren und mit etwas enden, wie:
OutputMay 08 18:07:52 buildbot-server systemd[1]:
Started A high performance web server and a reverse proxy server.Als nächstes werden wir den Buildmaster und den Worker mit + systemctl + neu starten, was wir in der https://www.digitalocean.com/community/tutorials/how-to-create-systemd-unit-files-for-buildbot konfiguriert haben [vorheriges Tutorial].
Überprüfen Sie zunächst die Konfigurationsdatei auf Syntaxfehler:
sudo buildbot checkconfig /home/buildbot/master/OutputConfig file is good!Wenn keine Fehler gemeldet werden, starten Sie den Dienst neu:
sudo systemctl restart buildbot-master
sudo systemctl status buildbot-masterDie Ausgabe sollte "Active: active (running)" hervorheben und mit etwas enden wie:
OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot master service.Als Nächstes starten wir den Worker neu:
sudo systemctl restart buildbot-worker
sudo systemctl status buildbot-workerAuch hier sollte die Ausgabe "Aktiv: Aktiv (läuft)" hervorheben und in diesem Fall mit etwas enden wie:
OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot worker service.Nachdem wir Nginx, den Buildmaster und den Worker neu gestartet haben, können wir überprüfen, ob der Reverse-Proxy wie erwartet funktioniert. Wenn wir die Site über "+ https" besuchen, sollten wir zu "+ https" umgeleitet werden und unsere Buildbot-Site erfolgreich erreichen.
Geben Sie in Ihrem Webbrowser "http: //" ein und ersetzen Sie "+ your.ssl.domain.name" durch Ihre Domain. Nachdem Sie die Eingabetaste gedrückt haben, sollte die URL mit "+ https +" beginnen und die Adressleiste sollte anzeigen, dass die Verbindung sicher ist. + image: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-secure.png [Screenshot der Buildbot-Startseite mit sicherer URL]
Als Nächstes nehmen wir uns einen Moment Zeit und prüfen, ob die Web Socket- und Server Sent-Ereignisse ordnungsgemäß übertragen werden.
Besuchen Sie zuerst das Verzeichnis + / sse +. Wenn die Umleitung ordnungsgemäß funktioniert, sollte der Browser die folgende Seite zurückgeben. Beachten Sie, dass die Seite weiterhin versucht zu laden. Dies ist ein normales Verhalten:
image: https://assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-sse-redirect.png [Buildbot-SSE-Seite]
Besuchen Sie als Nächstes das Verzeichnis / ws. Wenn die Proxy-Umleitung nicht korrekt ist, wird beim Aufrufen des Verzeichnisses "+ / ws +" der Fehler "+404 nicht gefunden +" zurückgegeben. Wenn alles in Ordnung ist, sollte der Browser die folgende Seite zurückgeben: + image: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-ws-redirect.png [Buildbot WebSocket page]
Da der integrierte Webserver alle Schnittstellen überwacht, löschen wir unsere Regel, die externen Datenverkehr an Port 8010 zulässt, um unverschlüsselte Verbindungen beim Zugriff auf den Server über die IP-Adresse zu verhindern:
sudo ufw delete allow 8010OutputRule updated
Rule updated (v6)Wir haben Nginx nun als Reverse-Proxy konfiguriert und Benutzer daran gehindert, mit + HTTP + auf Buildbot zuzugreifen.
Fazit
In diesem Lernprogramm haben wir Nginx als Reverse-Proxy für den integrierten Webserver von Buildbot konfiguriert, um unsere Anmeldeinformationen und andere Informationen, die über die Weboberfläche übertragen werden, zu sichern. Wenn Sie mit Buildbot noch nicht vertraut sind, lesen Sie möglicherweise die http://docs.buildbot.net/current/tutorial/tour.html Anleitung für Buildbot-Projekte. Wenn Sie lernen möchten, wie Sie einen vollständigen kontinuierlichen Integrationsprozess einrichten, lesen Sie unsere https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-with-buildbot-on -ubuntu-16-04 [So richten Sie die kontinuierliche Integration mit Buildbot unter Ubuntu 16.04 ein] Anleitung.