Ubuntu16.04でNginxを使用してDigitalOceanスペースをプロキシする方法
注:このチュートリアルが公開されて以来、DigitalOcean Spacesは、カスタマイズ可能なエンドポイントサブドメインを備えた無料のCDNオプションを追加しました。 このCDN機能は、キャッシュ、カスタムドメイン、SSL、アセットをユーザーに近づけるなど、以下で説明するほとんどの機能を提供します。
CDN を有効にし、 CDNエンドポイントをカスタマイズする方法については、公式Spaces製品ドキュメントをお読みください。
序章
DigitalOcean Spacesは、S3APIと互換性のあるオブジェクトストレージサービスです。 このチュートリアルでは、Nginxを使用してSpace上のオブジェクトのリクエストをプロキシする方法を示します。 NginxはユーザーからHTTP(S)リクエストを受信し、それらをSpacesサービスに渡します。Spacesサービスは結果をNginxを介して送り返します。
Spacesの前にNginxプロキシを配置する理由は、次のとおりです。
- カスタムドメインを追加する
- 独自のキャッシュを追加する
- 独自のSSL証明書を使用する
- 異なるアクセス制御メカニズムを使用する
- ユーザーに近いデータセンターにアセットをキャッシュする
このチュートリアルでは、独自のドメインでリクエストに応答するようにNginxを設定し(オプションのLet's Encrypt SSL証明書を使用)、それらのリクエストをpublicアセットのあるスペースに転送します。 次に、キャッシュを追加して、頻繁にアクセスされるオブジェクトに対する後続の応答を高速化します。
前提条件
このチュートリアルを完了するには、次のものが必要です。
チュートリアルUbuntu16.04にNginxをインストールする方法で説明されているように、NginxがインストールされたUbuntu16.04サーバー
DigitalOcean を使用してホスト名を設定する方法に従って、サーバーを指すドメイン名。 このチュートリアル全体でassets.example.comを使用します
DigitalOceanスペース。 DigitalOcean Spacesの紹介を読むと、新しいスペースを作成する方法を学ぶことができます。
個々のスペースのURLを知っている必要があります。 DigitalOceanコントロールパネルでスペースに移動すると、それを見つけることができます。 URLは、UIのスペース名のすぐ下にあります。 これは、以下のスクリーンショットで強調表示されています。
また、テストするためにSpaceにファイルをアップロードする必要があります。 前述のSpacesの記事は、SpacesWebGUIを使用してファイルをアップロードする方法を示しています。 このチュートリアルでは、
example.png
を使用します。
プロキシの設定
UbuntuにNginxをデフォルトでインストールすると、すべてのリクエストに対して Welcome toNginxプレースホルダーページが返されます。 ドメインへのリクエストで何か他のことをするようにNginxに指示するために、いくつかの新しい構成を追加する必要があります。
これを行うには、/etc/nginx/sites-available
で新しい構成ファイルを開きます。
sudo nano /etc/nginx/sites-available/assets.example.com
これにより、nano
テキストエディタで空のファイルが開きます。 次の構成で貼り付けます。強調表示された部分を、独自のドメイン名とスペースのURLに置き換えてください。
/etc/nginx/sites-available/assets.example.com
server { listen 80; listen [::]:80; server_name assets.example.com; location / { proxy_pass https://example.nyc3.digitaloceanspaces.com/; proxy_hide_header Strict-Transport-Security; } }
ファイルを保存し、完了したらエディタを終了します。 これは標準のNginxserver
ブロックです。 まず、IPv4とIPv6の両方でポート80
をリッスンするように指示し、Nginxが応答するserver_name
を指定します。
次に、location
ブロックを作成します。 このブロック内({
と}
の中括弧の間)の構成ディレクティブは、特定のURLにのみ適用されます。 この場合、ルートURLである/
を指定するため、すべての場所がこのブロックと一致します。
proxy_pass
ディレクティブは、指定されたサーバーにリクエストを渡すようにNginxに指示します。 proxy_hide_header
行は、応答をクライアントに返す前にStrict-Transport-Security
ヘッダーを取り除きます。 Spacesはこのヘッダーを使用して、すべての接続をHTTPSに強制します。 サイトがHTTP接続とHTTPS接続の両方でアクセス可能である場合、このヘッダーをユーザーに渡すと、意図しない結果が生じる可能性があります。
構成が設定されたので、それを有効にする必要があります。 これは、/etc/nginx/sites-enabled/
ディレクトリに構成ファイルへのリンクを作成することによって行われます。
sudo ln -s /etc/nginx/sites-available/assets.example.com /etc/nginx/sites-enabled/
構成構文を確認するには、rootとしてnginx -t
を実行します。
sudo nginx -t
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
最後に、Nginxをリロードして、新しい構成を取得します。
sudo systemctl reload nginx
構成ファイルを設定したら、プロキシをテストしましょう。
プロキシのテスト
コマンドラインでcurl
を使用してプロキシ接続をテストできます。 curl -I
は、応答のHTTPヘッダーのみを返します。 これは、物事がうまく機能していることを判断するのに十分です。
まず、 digitaloceanspaces.com URLを使用して、スペースから直接オブジェクトをフェッチします。 example.png
ファイルを使用します。
curl -I https://example.nyc3.digitaloceanspaces.com/example.png
OutputHTTP/1.1 200 OK Content-Length: 81173 Accept-Ranges: bytes Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx000000000000000002398-005a1edfcd-afba2-nyc3a Content-Type: image/png Date: Wed, 29 Nov 2017 16:26:53 GMT Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
出力の最初の行の200 OK
から、これが成功した要求であることがわかります。 サーバーは、ファイルのサイズ(Content-Length
)、ファイルタイプ(Content-Type
)、およびその他の日付とキャッシュに関連する情報を返しました。
次に、プロキシを介して同じファイルをフェッチします。
curl -I http://assets.example.com/example.png
OutputHTTP/1.1 200 OK Server: nginx/1.10.3 (Ubuntu) Date: Wed, 29 Nov 2017 16:27:24 GMT Content-Type: image/png Content-Length: 81173 Connection: keep-alive Accept-Ranges: bytes Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx00000000000000000a045-005a1edfec-a89a3-nyc3a
応答はほとんど同じです。 主な変更点は、Nginxを識別するServer
ヘッダーです。 出力が類似している場合、プロキシは正しく機能しています。
次のステップでは、プロキシとSpacesの間の帯域幅の使用を減らし、応答時間を短縮するためにキャッシュを設定します。
キャッシングの設定
応答をキャッシュするには、Nginxにキー、メタデータ、および実際の応答コンテンツを保存する場所が必要です。 システムの/tmp
ディレクトリにキャッシュディレクトリを設定します。 そのために、/etc/nginx/conf.d/
の新しいファイルに構成スニペットを追加します。 今すぐそのファイルを開きます:
sudo nano /etc/nginx/conf.d/example-cache.conf
次の行に貼り付けて、ファイルを保存して閉じます。
/etc/nginx/conf.d/example-cache.conf
proxy_cache_path /tmp/example-cache/ levels=1:2 keys_zone=example-cache:16m max_size=10g inactive=60m use_temp_path=off;
この行は、キャッシュのいくつかの特性を定義します。 オプションを実行してみましょう:
/tmp/example-cache/
はキャッシュへのパスです。levels=1:2
は、キャッシュされたコンテンツを格納するための2レベルのディレクトリ階層を設定します。 1つのディレクトリに多くのファイルを配置すると、速度と信頼性の問題が発生する可能性があるため、Nginxはこのオプションに基づいてファイルを複数のディレクトリに分割します。keys_zone=example-cache:16m
はキャッシュに名前を付け、キーを格納するために16メガバイトのメモリを設定します。 これは、100,000を超えるキーのデータを格納するのに十分なメモリである必要があります。max_size=10g
は、キャッシュのサイズを10ギガバイトに制限します。 ストレージと使用法のニーズに合わせてこれを調整できます。inactive=60m
は、キャッシュされたファイルがその時間内にアクセスされていない場合(ファイルがまだ有効で有効期限が切れていない場合でも)、60分後にNginxが削除することを意味します。 アクセス頻度の低いオブジェクトがたくさんある場合は、これを増やしてみてください。use_temp_path=off
は、一時ファイルをキャッシュディレクトリに書き込むようにNginxに指示します。これにより、パフォーマンスを低下させる可能性のあるファイルシステム間でファイルをコピーする必要がなくなる可能性があります。
キャッシュを定義したので、サーバーブロックでキャッシュを有効にし、いくつかの追加オプションを設定する必要があります。 サイトの構成ファイルを再度開きます。
sudo nano /etc/nginx/sites-available/assets.example.com
location /
ブロックの最後(proxy_hide_header
ディレクティブの後、}
ブラケットを閉じる前)に以下を追加します。
/etc/nginx/sites-available/assets.example.com
. . . proxy_cache example-cache; proxy_cache_valid 200 60m; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_cache_revalidate on; proxy_cache_lock on; proxy_ignore_headers Set-Cookie; add_header X-Cache-Status $upstream_cache_status; . . .
ファイルを保存して閉じます。 これらの構成オプションを1つずつ見ていきましょう。
proxy_cache
は、使用するキャッシュをNginxに指示します。 この場合、example-cache.conf
ファイルで設定したexample-cache
を指定します。proxy_cache_valid
は、200
応答が60分間有効であると見なすようにNginxに指示します。 これは、プロキシがSpacesからファイルを正常にフェッチした後、次の60分間、NginxはSpacesに更新を要求することなくキャッシュされたコピーを使用することを意味します。 オブジェクトにCache-Control
ヘッダーが設定されている場合、ヘッダーの値がこの構成をオーバーライドすることに注意してください。proxy_cache_use_stale
を使用すると、Spacesサーバーがタイムアウトしたり、エラーを返したり、キャッシュされた応答が更新中の場合に、Nginxが古い(期限切れの)応答を返すことができます。proxy_cache_revalidate
を使用すると、プロキシは条件付きGET要求を使用してキャッシュされたファイルを再検証できます。 つまり、キャッシュされたファイルの有効期限が切れ、Nginxがスペースの変更を確認する必要がある場合、NginxはIf-Modified-Since
またはIf-None-Match
ヘッダーを使用して、オブジェクトが実際に変更された場合にのみオブジェクトをフェッチします。 更新されていない場合、Spacesは304 Not Modified
応答を返し、Nginxは単に既存のキャッシュされた応答を再び有効としてマークします。proxy_cache_lock
は、プロキシがすでにバックエンドサーバーからオブジェクトをフェッチしている場合、オブジェクトへの後続のリクエストを保留にします。 最初のリクエストが完了すると、他のリクエストはキャッシュから処理されます。proxy_ignore_headers Set-Cookie
は、キャッシュを妨げる可能性のあるCookieを無視します。add_header X-Cache-Status...
は、リクエストがキャッシュから提供されたか(HIT
)、そうでないか(MISS
)に関する情報を含むヘッダーを追加します。 リクエストがキャッシュにあったが期限切れになった場合は、代わりに(REVALIDATED
)が表示されます。
これで、構成にエラーがないことを確認する準備が整いました。それが成功した場合は、Nginxをリロードします。
sudo nginx -t sudo systemctl reload nginx
キャッシュを設定したら、再度テストして、キャッシュが期待どおりに機能していることを確認できます。
キャッシュのテスト
キャッシュが機能していることを確認するために、curl
を再度使用して、X-Cache-Status
ヘッダーを探すことができます。
curl -I http://assets.example.com/example.png
OutputHTTP/1.1 200 OK Server: nginx/1.10.3 (Ubuntu) Date: Wed, 29 Nov 2017 18:40:28 GMT Content-Type: image/png Content-Length: 81173 Connection: keep-alive Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a X-Cache-Status: MISS Accept-Ranges: bytes
最初のリクエストはMISS
である必要があります。 もう一度試してください:
curl -I http://assets.example.com/example.png
OutputHTTP/1.1 200 OK Server: nginx/1.10.3 (Ubuntu) Date: Wed, 29 Nov 2017 18:40:53 GMT Content-Type: image/png Content-Length: 81173 Connection: keep-alive Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a X-Cache-Status: HIT Accept-Ranges: bytes
HIT
! 現在、Spacesからオブジェクトをプロキシしてキャッシュしています。 次のステップでは、プロキシへの通信を保護するためにSSL証明書を設定します。
TLS/SSLの設定
この手順はオプションですが、Webサイトとアセットを安全なHTTPS接続で利用できるようにすることを強くお勧めします。 チュートリアルUbuntu16.04でNginxサーバーブロックを使用してLet'sEncryptを設定する方法を読むと、Let'sEncrypt認証局から無料の証明書をダウンロードしてインストールする方法を学ぶことができます。
結論
このチュートリアルでは、オブジェクトのリクエストをSpacesサービスにプロキシするためのNginx構成を作成しました。 次に、パフォーマンスを向上させるためにキャッシュを追加し、プライバシーとセキュリティを向上させるためにTLS/SSL証明書を追加しました。
ここに示されている設定は良い出発点ですが、独自のトラフィックパターンとニーズに基づいていくつかのキャッシュパラメータを最適化することをお勧めします。 Nginxドキュメント、特に ngx_http_proxy_module は、利用可能な構成オプションに関するより詳細な情報を提供できます。