Nginxリバースプロキシを使用してSSLでBuildbotを構成する方法

注：このチュートリアルは古いバージョンのBuildbotを対象としているため、現在のバージョンでは手順が機能しない場合があります。この記事が更新されるまで、公式のBuildbotリバースプロキシ構成ドキュメントを追加で使用できます。

序章

Buildbotは、ソフトウェアのビルド、テスト、リリースのプロセスを自動化するためのPythonベースの継続的インテグレーションシステムです。前のチュートリアルでは、 Buildbot をインストールし、 systemdユニットファイルを作成して、サーバーのinitシステムがプロセスを管理できるようにしました。 Buildbotには、ポート8010でリッスンする独自の組み込みWebサーバーが付属しており、SSLを使用してWebインターフェイスを保護するには、リバースプロキシを構成する必要があります。

このチュートリアルでは、SSLで保護されたブラウザリクエストをBuildbotのウェブインターフェースに送信するために、Nginxをリバースプロキシとして設定する方法を示します。

前提条件

このチュートリアルに従うには、次のものが必要です。

少なくとも1GBのRAMを備えた1台のUbuntu16.04サーバー。ルート以外のsudoユーザーと、Ubuntu16.04初期サーバーセットアップガイドに従ってファイアウォールで構成されています。

さらに、サーバーで次のチュートリアルを完了する必要があります。

Ubuntu16.04にBuildbotをインストールする方法
BuildbotのSystemdユニットファイルを作成する方法
Ubuntu16.04にNginxをインストールする方法
Ubuntu16.04でLet'sEncryptを使用してNginxを保護する方法。

これらの要件を完了すると、開始する準備が整います。

ステップ1-Nginxを構成する

前提条件のチュートリアルUbuntu16.04でLet'sEncryptを使用してNginxを保護する方法では、/etc/nginx/sites-available/defaultファイルでSSLを使用するようにNginxを構成しました。始める前に、作業構成ファイルのバックアップを作成します。

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

次に、defaultを開き、リバースプロキシ設定を追加します。

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

まず、SSLserverブロックに特定のアクセスログとエラーログを追加します。

/ etc / nginx / sites-available / default

. . . 
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行を削除またはコメントアウトする必要があります。これは、記述されているように、リクエストがBuildbotに到達する前に404エラーを返します。

注：ほとんどのアプリケーションとは異なり、Buildbotは、try_files設定が有効になっている場合、ドキュメントルートへのリクエストに対して200応答を返します。アセットがブラウザによってキャッシュされている場合、Buildbotが機能しているように見えることがあります。キャッシュされたアセットがないと、空白のページが返されます。

次に、リバースプロキシ構成を追加します。最初の行には、ホスト名、クライアントリクエストのプロトコル、クライアントIPアドレスなどの情報がログファイルで利用できるようにするために、Nginxが提供するproxy_paramsが含まれています。 proxy_passは、プロキシされたサーバーのプロトコルとアドレスを設定します。この場合は、ポート8010のローカルホストでアクセスされるBuildbotサーバーです。

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

このスタンザの直後に、/sseと/wsの2つの追加の場所を構成します。

サーバー送信イベント（SSE）設定 サーバー送信イベント are a simpler, more REST compliant protocol than WebSockets that allow clients to subscribe to events. The Buildbot SSE endpoint requires its own proxy_pass setting and benefits from turning off proxy_buffering.
WebSocket設定 WebSocket is a protocol for messaging between the web server and web browsers. Like the SSE protocol, it requires its own proxy_pass setting. Additional configuration is also required to pass header information. You can learn more these settings from the NginxWebSocketプロキシドキュメント.

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

これらの変更を行ったら、ファイルを保存して終了します。

最後に、ssl_params.confを編集し、ssl_session_timeoutをプロジェクトの推奨設定である1440分（24時間）に増やして、より長いビルドに対応します。

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

ファイルの最後に、次の行を追加します。

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

 . . . 
ssl_session_timeout 1440m;

完了したら、ファイルを保存して終了します。

注： BuildbotドキュメントのサンプルNginxファイルには、ssl_session_cacheサイズを1,440メガバイトに設定する行が含まれています。これにより、500万を超える接続が可能になります。メモリをあまり消費しない10メガバイトの設定を維持することを選択しました。 1メガバイトあたり約4000セッションを保存できるため、これは約40,000セッションを保存します。これは、ほとんどのユースケースに十分です。

Buildbotを構成するまで、Nginxを再起動しませんが、間違いがあった場合に備えて、構成をテストします。

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は、Webインターフェイスでルート相対リンクを使用します。リンクが正しく機能するには、master.cfgでベースURLが定義されている必要があります。

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

buildbotURL設定を見つけ、httpをhttpsに変更し、localhostをドメインに変更します。 Nginxは従来のWebポートに対して行われたリクエストをプロキシするため、ポート指定（:8010）を削除します。 重要：プロトコルはhttpsである必要があり、定義には末尾のスラッシュが含まれている必要があります。

/home/buildbot/master/master.cfg

 . . .
 c['buildbotURL'] = "https://your.ssl.domain.name/"
 . . .

また、ローカルループバックインターフェイスにバインドすることにより、マスターが他のホストで実行されているワーカーからの直接接続を受け入れないようにします。コメントアウトするか、既存のプロトコル行c['protocols'] = {'pb': {'port': 9989}}を次のように置き換えます。

/home/buildbot/master/master.cfg

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

完了したら、ファイルを保存して終了します。

HTTPSとドメイン名を使用しているので、 service_identityモジュールをインストールします。これは、証明書が意図した目的に対して有効であるかどうかを判断するためのツールを提供します。

sudo -H pip install service_identity

この手順をスキップした場合でも、Buildbotは再起動しますが、systemdのstatusコマンドの出力に表示されるUserWarning「service_identityモジュールのインストールが機能していません」を発行します。

ステップ3—サービスの再起動

これで、Nginxを再起動する準備が整いました。

sudo systemctl restart nginx

systemctlは出力を提供しないため、statusコマンドを使用して、Nginxが実行されていることを確認します。

sudo systemctl status nginx

出力は「アクティブ：アクティブ（実行中）」を強調表示し、次のように終了する必要があります。

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

次に、前のチュートリアルで構成したsystemctlを使用して、ビルドマスターとワーカーを再起動します。

まず、構成ファイルで構文エラーを確認します。

sudo buildbot checkconfig /home/buildbot/master/

OutputConfig file is good!

エラーが報告されない場合は、サービスを再起動します。

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

出力は「アクティブ：アクティブ（実行中）」を強調表示し、次のように終了する必要があります。

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

次に、ワーカーを再起動します。

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

繰り返しますが、出力は「アクティブ：アクティブ（実行中）」を強調表示する必要があり、この場合は次のように終了します。

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

Nginx、ビルドマスター、およびワーカーを再起動したので、リバースプロキシが期待どおりに機能していることを確認する準備が整いました。 http経由でサイトにアクセスすると、httpsにリダイレクトされ、Buildbotサイトに正常にアクセスできるはずです。

ウェブブラウザで「http：// your.ssl.domain.name 」と入力し、ドメインをyour.ssl.domain.nameに置き換えます。 Enterキーを押すと、URLはhttpsで始まり、ロケーションバーに接続が安全であることが示されます。

次に、少し時間を取って、Webソケットとサーバー送信イベントが適切にプロキシされていることを確認します。

まず、/sseディレクトリにアクセスします。リダイレクトが正しく機能している場合、ブラウザは次のページを返す必要があります。ページは引き続きロードを試みますが、これは正常な動作であることに注意してください。

次に、/wsディレクトリにアクセスします。プロキシリダイレクトが正しくない場合、/wsディレクトリにアクセスすると、404 Not Foundエラーが返されます。すべてが順調であれば、ブラウザは次のページを返すはずです。

最後に、組み込みのWebサーバーはすべてのインターフェイスをリッスンするため、IPアドレスでサーバーにアクセスするときに暗号化されていない接続を防ぐために、ポート8010への外部トラフィックを許可するルールを削除します。

sudo ufw delete allow 8010

OutputRule updated
Rule updated (v6)

これで、Nginxをリバースプロキシとして構成し、ユーザーがHTTPを使用してBuildbotにアクセスできないようにしました。

結論

このチュートリアルでは、Webインターフェイスを介して送信される資格情報やその他の情報を保護するために、Buildbotの組み込みWebサーバーへのリバースプロキシとしてNginxを構成しました。 Buildbotを初めて使用する場合は、Buildbotプロジェクトのクイックツアーガイドを参照することをお勧めします。完全な継続的インテグレーションプロセスをセットアップする方法を学ぶ準備ができたら、 Ubuntu16.04でBuildbotとの継続的インテグレーションをセットアップする方法ガイドを確認してください。