TOC

Comment configurer Buildbot avec SSL à l’aide d’un proxy inverse Nginx

introduction

Buildbot est un système d’intégration continue basé sur Python permettant d’automatiser les processus de création, de test et de publication de logiciels. Dans les tutoriels précédents, nous installed Buildbot et https://www.digitalocean.com/ communauté / didacticiels / comment-créer-systèmed-unité-fichiers-pour-buildbot [fichiers unité créés systemd] pour permettre au système init du serveur de gérer les processus. Buildbot est livré avec son propre serveur Web intégré, à l’écoute sur le port 8010. Pour sécuriser l’interface Web avec SSL, nous devons configurer un proxy inverse.

Dans ce didacticiel, nous montrerons comment configurer Nginx en tant que proxy inverse afin de diriger les demandes de navigateur sécurisées par SSL vers l’interface Web de Buildbot.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

En outre, vous devrez suivre les didacticiels suivants sur le serveur:

Lorsque vous avez rempli ces conditions, vous êtes prêt à commencer.

Étape 1- Configuration de Nginx

Dans le didacticiel préalable, Comment sécuriser Nginx avec Let’s Encrypt sur Ubuntu 16.04, nous avons configuré Nginx pour utiliser SSL dans le fichier + / etc / nginx / sites-available / default +. Avant de commencer, nous allons faire une sauvegarde de notre fichier de configuration de travail:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.ssl.bak

Ensuite, nous allons ouvrir + default et ajouter vos paramètres de proxy inverse.

sudo nano /etc/nginx/sites-available/default

Nous allons d’abord ajouter des journaux d’accès et d’erreurs spécifiques dans le bloc SSL + serveur +.

/ etc / nginx / sites-available / default

. . .
server {
       # SSL Configuration
       #
. . .
        # include snippets/snakeoil.conf;


. . .

Ensuite, nous allons configurer les paramètres du proxy.

Puisque nous envoyons toutes les demandes à Buildbot, nous devrons supprimer ou commenter la ligne + try_files + par défaut qui, comme écrit, renverra 404 erreurs avant que les demandes atteignent Buildbot.

Ensuite, nous ajouterons la configuration du proxy inverse. La première ligne inclut les paramètres + proxy_params + fournis par Nginx pour garantir des informations telles que le nom d’hôte, le protocole de la demande du client et l’adresse IP du client seront disponibles dans nos fichiers journaux. Le + proxy_pass + définit le protocole et l’adresse du serveur mandaté, qui dans notre cas est le serveur Buildbot accédé sur l’hôte local sur le port 8010.

/ 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;
            }
. . .

Juste après cette strophe, nous allons configurer deux emplacements supplémentaires, + / sse + et + / ws +:

  • * Paramètres SSE (Server Sent Event) * Server Sentevents sont un protocole plus simple, plus conforme à REST que WebSockets permettre aux clients de s’abonner à des événements. Le point de terminaison Buildbot SSE requiert son propre paramètre + proxy_pass + et tire profit de la désactivation de + proxy_buffering +.

  • * Paramètres WebSocket * WebSocket est un protocole de messagerie entre le serveur Web et les navigateurs Web. Comme le protocole SSE, il nécessite son propre paramètre + proxy_pass +. Une configuration supplémentaire est également requise pour transmettre les informations d’en-tête. Vous pouvez en savoir plus sur ces paramètres à partir de la documentation Nginx WebSocket.

/ 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;
       }
. . .

Une fois ces modifications apportées, enregistrez et quittez le fichier.

Enfin, nous éditerons le + ssl_params.conf + et augmenterons le + ssl_session_timeout + au réglage recommandé du projet de 1440 minutes (24 heures) pour permettre des générations plus longues:

sudo nano /etc/nginx/snippets/ssl-params.conf

Au bas du fichier, ajoutez la ligne suivante:

/etc/nginx/snippets/ssl-params.conf

. . .

Lorsque vous avez terminé, enregistrez et quittez le fichier.

Nous n’allons pas redémarrer Nginx avant d’avoir configuré Buildbot, mais nous allons maintenant tester notre configuration au cas où nous aurions commis des erreurs:

sudo nginx -t

Si tout va bien, la commande retournera:

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Sinon, corrigez les erreurs signalées jusqu’à la réussite du test.

Étape 2 - Configuration de Buildbot

Buildbot utilise des liens relatifs à la racine dans son interface Web et nécessite que l’URL de base soit définie dans le fichier + master.cfg + pour que les liens fonctionnent correctement.

sudo nano /home/buildbot/master/master.cfg

Localisez le paramètre + buildbotURL +, remplacez + http + par + https +, et remplacez + localhost + par votre domaine. Supprimez la spécification du port (+: 8010 +) car Nginx enverra des requêtes proxy aux ports Web conventionnels. * Important: * Le protocole doit être + https + et la définition doit contenir la barre oblique finale.

/home/buildbot/master/master.cfg

. . .
c['buildbotURL'] = "http:///"
. . .

Nous veillerons également à ce que le maître n’accepte pas les connexions directes de travailleurs exécutés sur d’autres hôtes en se liant à l’interface de bouclage local. Mettez en commentaire ou remplacez la ligne de protocole existante, + c ['protocoles'] = {'pb': {'port': 9989}} +, par ce qui suit:

/home/buildbot/master/master.cfg

. . .
c['protocols'] = {"pb": {"port": "tcp:9989:interface=127.0.0.1"}}
. . .

Lorsque vous avez terminé, enregistrez et quittez le fichier.

Maintenant que nous utilisons HTTPS et un nom de domaine, nous allons installer le https://service-identity.readthedocs.io/en/stable/ [module `` + service_identity + `]], qui fournit des outils pour déterminer si le certificat est valide pour le but prévu.

sudo -H pip install service_identity

Si nous ignorions cette étape, Buildbot redémarrerait toujours, mais émettrait le message UserWarning «Vous n’avez pas d’installation fonctionnelle du module service_identity», ce qui serait visible dans le résultat de la commande + status + de systemd.

Étape 3 - Redémarrage des services

Nous sommes maintenant prêts à redémarrer Nginx:

sudo systemctl restart nginx

Comme + systemctl + ne fournit pas de sortie, nous utiliserons sa commande + status + pour être sûr que Nginx est en cours d’exécution.

sudo systemctl status nginx

La sortie doit mettre en évidence “Actif: actif (en cours d’exécution) et se terminer par quelque chose comme:

OutputMay 08 18:07:52 buildbot-server systemd[1]:
Started A high performance web server and a reverse proxy server.

Ensuite, nous allons redémarrer le buildmaster et le worker en utilisant + systemctl +, ce que nous avons configuré dans https://www.digitalocean.com/community/tutorials/how-to-create-systemd-unit-files-for-buildbot [tutoriel précédent].

Commencez par vérifier le fichier de configuration pour les erreurs de syntaxe:

sudo buildbot checkconfig /home/buildbot/master/
OutputConfig file is good!

Si aucune erreur n’est signalée, redémarrez le service:

sudo systemctl restart buildbot-master
sudo systemctl status buildbot-master

La sortie doit mettre en évidence "Actif: actif (en cours d’exécution) et se terminer par quelque chose comme:

OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot master service.

Ensuite, nous allons redémarrer le travailleur:

sudo systemctl restart buildbot-worker
sudo systemctl status buildbot-worker

Encore une fois, la sortie doit mettre en évidence "Actif: actif (en cours d’exécution) et dans ce cas se termine par quelque chose comme:

OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot worker service.

Maintenant que nous avons redémarré Nginx, le maître de build et le travailleur, nous sommes prêts à vérifier que le proxy inverse fonctionne comme prévu. Lorsque nous visitons le site via + https, nous devrions être redirigés vers` + https` et atteindre avec succès notre site Buildbot.

Dans votre navigateur Web, entrez "http: //" en remplaçant votre domaine par + votre.ssl.domaine.nom. Après avoir appuyé sur Entrée, l’URL devrait commencer par + https + et la barre d’adresse devrait indiquer que la connexion est sécurisée. + image: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-secure.png [Capture d’écran de la page d’accueil de Buildbot avec une URL sécurisée]

Nous allons maintenant prendre un moment pour constater que les événements Web Socket et Server Sent sont correctement mandatés.

Tout d’abord, visitez le répertoire + / sse +. Si la redirection fonctionne correctement, le navigateur devrait retourner la page suivante. Notez que la page continuera à essayer de charger, ce qui est un comportement normal:

image: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-sse-redirect.png [page Buildbot SSE]

Ensuite, visitez le répertoire / ws. Si la redirection du proxy n’est pas correcte, visiter le répertoire + / ws + retournera une erreur +404 Not Found +. Si tout va bien, le navigateur devrait retourner la page suivante: + image: https: //assets.digitalocean.com/articles/buildbot-nginx-ubuntu-1604/buildbot-ws-redirect.png [Page Buildbot WebSocket]

Enfin, comme le serveur Web intégré écoute toutes les interfaces, nous allons supprimer notre règle autorisant le trafic externe sur le port 8010 afin d’empêcher les connexions non cryptées lors de l’accès au serveur par adresse IP:

sudo ufw delete allow 8010
OutputRule updated
Rule updated (v6)

Nous avons maintenant configuré Nginx en tant que proxy inverse et empêché les utilisateurs d’accéder à Buildbot avec + HTTP +.

Conclusion

Dans ce didacticiel, nous avons configuré Nginx en tant que proxy inverse du serveur Web intégré de Buildbot afin de sécuriser nos informations d’identité et autres informations transmises via l’interface Web. Si vous débutez avec Buildbot, vous pouvez explorer le the Quick Tour du projet Buildbot. Lorsque vous êtes prêt à apprendre à mettre en place un processus d’intégration complet et continu, consultez notre https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-with-buildbot-on -ubuntu-16-04 [Comment configurer l’intégration continue avec Buildbot sur Ubuntu 16.04].

Related