ブログ | NGINX

Docker を使用した NGINX と NGINX Plus のデプロイ

NGINX-F5 水平黒タイプ RGB の一部
リック・ネルソン サムネイル
リック・ネルソン
2021年11月9日公開


編集者– Alpine Linux および Debian 用の NGINX Plus Dockerfiles は、最新のソフトウェア バージョンを反映するために 2021 年 11 月に更新されました。 また、改訂された手順とともに、NGINX Plus イメージを構築するときにライセンス情報を渡するために Docker シークレットを使用します。

Docker は、分散アプリケーションをコンテナ(アプリケーションの実行に必要なものがすべて含まれた軽量でスタンドアロンの実行可能なソフトウェア パッケージ) として構築、出荷、実行するためのオープン プラットフォームです。 コンテナは、 Kubernetesなどのコンテナ オーケストレーション プラットフォームによってデプロイおよびオーケストレーションできます。 (このブログで説明した Docker コンテナ テクノロジーに加えて、NGINX は NGINX Open Source ベースと NGINX Plus ベースのバージョンのF5 NGINX Ingress Controller を提供しています。NGINX Plus サブスクライバーには、追加料金なしでサポートが含まれています。)

ソフトウェア アプリケーションとしては、 NGINX Open SourceとF5 NGINX Plus はDocker の優れた使用例であり、Docker イメージのリポジトリであるDocker HubでNGINX Open Source イメージを公開しています。 この投稿では、次の方法について説明します。

導入

Docker オープン プラットフォームには、コンテナを構築、実行、オーケストレーションするオープン ソース ランタイムである Docker エンジンと、Docker 化されたアプリケーションが開発コミュニティ全体または特定の組織の範囲内で配布、共有、共同作業されるホスト型サービスである Docker Hub が含まれます。

Docker コンテナを使用すると、アプリケーションをインフラストラクチャの制約から分離することで、開発者はアプリケーションの「コンテンツ」に集中できるようになります。 Docker 化されたアプリケーションは、ラップトップ、ベアメタル サーバー、VM、クラウドなど、あらゆるインフラストラクチャに即座に移植可能であり、モジュール コンポーネントとして簡単に組み立て、再構築して完全な機能を備えた分散アプリケーションにすることができ、リアルタイムで継続的に革新することができます。

Docker の詳細については、 「Docker を選ぶ理由」または完全なDocker ドキュメントを参照してください。

NGINXオープンソースDockerイメージの使用

Docker Hub のNGINX オープンソース イメージを使用して、Docker コンテナー内に NGINX インスタンスを作成できます。

非常に簡単な例から始めましょう。 コンテナ内で実行され、デフォルトの NGINX 構成を使用する NGINX インスタンスを起動するには、次のコマンドを実行します。

# docker run --name mynginx1 -p 80:80 -d nginx fcd1fb01b14557c7c9d991238f2558ae2704d129cf9fb97bb4fadf673a58580d

このコマンドは、NGINX イメージに基づいてmynginx1という名前のコンテナを作成します。 このコマンドは、ログ ファイルの名前に使用されるコンテナー ID の長い形式を返します。 「ログの管理」を参照してください。

-pオプションは、 NGINX イメージによってコンテナ内で公開されるポート (ポート 80) を Docker ホスト上の指定されたポートにマップするように Docker に指示します。 最初のパラメーターは Docker ホスト内のポートを指定し、2 番目のパラメーターはコンテナーで公開されるポートにマッピングされます。

-dオプションは、コンテナがデタッチ モードで実行されることを指定します。つまり、コンテナは停止するまで実行を継続しますが、コマンド ラインで実行されるコマンドには応答しません。 次のセクションでは、コンテナと対話する方法について説明します。

コンテナが作成され、実行されていることを確認し、ポート マッピングを確認するには、 docker ps を実行します。 (ここでは読みやすくするために出力を複数行に分割しています。)

# docker psコンテナ ID イメージ コマンド 作成 ステータス ... fcd1fb01b145 nginx:latest "nginx -g 'デーモン 16 秒前 15 秒前 ... ... ポート名... 0.0.0.0:80->80/tcp mynginx1

出力のPORTSフィールドには、Docker ホストのポート 80 がコンテナーのポート 80 にマップされていることが報告されます。 NGINX が実行中であることを確認する別の方法は、そのポートに HTTP リクエストを送信することです。 デフォルトの NGINX ウェルカム ページのコードが表示されます。

# カール http://localhost<!DOCTYPE html>
<html>
<head>
<title>nginx へようこそ!</title>
<style>
body {
width: 35em; 余白: 0 自動; フォントファミリー: Tahoma、Verdana、Arial、sans-serif; } さらに設定が必要です。

NGINX Dockerコンテナの操作

これで、動作する NGINX Docker コンテナができましたが、コンテンツと NGINX 構成をどのように管理すればよいでしょうか? ログ記録についてはどうでしょうか?

SSH に関する注意事項

NGINX インスタンスへの SSH アクセスを有効にするのは一般的ですが、Docker コンテナは一般に単一の目的 (この場合は NGINX の実行) を目的としているため、NGINX イメージには OpenSSH がインストールされていません。 代わりに、Docker でサポートされている他の方法を使用します。

次のコマンドの代わりに、SSH セッションを開始する代わりに、実行中の NGINX コンテナへの対話型シェルを開くために次のコマンドを実行することもできます。 ただし、これは上級ユーザーにのみお勧めします。

  • Alpine Linux システムの場合:

    # docker exec -it NGINX_コンテナID sh

  • Debian システムの場合:

    # docker exec -it NGINX_コンテナID bash

コンテンツと構成ファイルの管理

NGINX によって提供されるコンテンツと NGINX 構成ファイルの両方を管理する方法はいくつかあります。 ここではいくつかのオプションについて説明します。

オプション 1 – Docker ホスト上のコンテンツと構成を維持する

コンテナが作成されると、Docker に Docker ホスト上のローカル ディレクトリをコンテナ内のディレクトリにマウントするように指示できます。 NGINX イメージはデフォルトの NGINX 構成を使用します。この構成では、コンテナのルート ディレクトリとして/usr/share/nginx/html を使用し、構成ファイルを/etc/nginxに配置します。 ローカル ディレクトリ/var/wwwにコンテンツがあり、 /var/nginx/confに設定ファイルがある Docker ホストの場合は、次のコマンドを実行します (ここでは読みやすくするために複数行で表示しています)。

# docker run --name mynginx2 --mount type=bind source=/var/www,target=/usr/share/nginx/html,readonly --mount type=bind,source=/var/nginx/conf,target=/etc/nginx/conf,readonly -p 80:80 -d nginx

これで、Docker ホスト上のローカル ディレクトリ/var/wwwおよび/var/nginx/conf内のファイルに加えられた変更が、コンテナー内のディレクトリ/usr/share/nginx/htmlおよび/etc/nginxに反映されます。 readonlyオプションは、これらのディレクトリはコンテナー内からではなく、Docker ホスト上でのみ変更できることを意味します。

オプション 2 – Docker ホストからファイルをコピーする

もう 1 つのオプションは、コンテナの作成中に Docker に Docker ホスト上のローカル ディレクトリからコンテンツ ファイルと構成ファイルをコピーさせることです。 コンテナが作成されると、ファイルが変更されたときに新しいコンテナを作成するか、コンテナ内のファイルを変更することによって、ファイルが維持されます。 ファイルをコピーする簡単な方法は、Docker Hub の NGINX イメージに基づいて新しい Docker イメージの生成中に実行されるコマンドを含むDockerfile を作成することです。 Dockerfile内のファイルコピー ( COPY ) コマンドの場合、ローカル ディレクトリ パスはDockerfileが配置されているビルド コンテキストを基準とします。

この例では、コンテンツはcontentディレクトリにあり、構成ファイルはconfディレクトリにあります。どちらもDockerfileが配置されているディレクトリのサブディレクトリです。 NGINX イメージには、 /etc/nginx/nginx.confおよび/etc/nginx/conf.d/default.confというデフォルトの NGINX 構成ファイルが含まれています。 代わりにホストから構成ファイルを使用するため、デフォルトのファイルを削除するRUNコマンドを含めます。

nginx から
rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf を実行
content /usr/share/nginx/html をコピー
conf /etc/nginx をコピー

Dockerfileが配置されているディレクトリから次のコマンドを実行して、独自の NGINX イメージを作成します。 コマンドの末尾のピリオド (“.”) に注意してください。 現在のディレクトリをビルド コンテキストとして定義します。ビルド コンテキストには、 Dockerfileとコピーするディレクトリが含まれます。

ビルドが完了したら、 docker を実行します。

ここで、このコマンドを実行して、 mynginx_image1イメージに基づいてmynginx3というコンテナを作成します。

# docker run --name mynginx3 -p 80:80 -d mynginx_image1

コンテナ内のファイルに変更を加えたい場合は、オプション 3 で説明したようにヘルパー コンテナを使用します。

オプション 3 – コンテナ内のファイルを維持する

SSH に関する注意で述べたように、SSH を使用して NGINX コンテナーにアクセスすることはできないため、コンテンツまたは構成ファイルを直接編集する場合は、シェル アクセスを持つヘルパー コンテナーを作成する必要があります。 ヘルパー コンテナがファイルにアクセスできるようにするには、イメージに適切なDocker データ ボリュームが定義された新しいイメージを作成する必要があります。 オプション 2 のようにファイルをコピーし、ボリュームも定義したい場合は、次のDockerfileを使用します。

nginxRUN から rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
コンテンツ /usr/share/nginx/html をコピー
conf /etc/nginx をコピー
ボリューム /usr/share/nginx/html
ボリューム /etc/nginx

次に、次のコマンドを実行して新しい NGINX イメージを作成します (最後のピリオドに注意してください)。

ビルドが完了したら、 docker を実行します。

ここで、このコマンドを実行して、 mynginx_image2イメージに基づいて NGINX コンテナ ( mynginx4 ) を作成します。

# docker run --name mynginx4 -p 80:80 -d mynginx_image2

次に、次のコマンドを実行して、シェルを持つヘルパー コンテナーmynginx4_files を起動し、作成したmynginx4コンテナーのコンテンツと構成ディレクトリにアクセスできるようにします。

# docker run -i -t --volumes-from mynginx4 --name mynginx4_files debian /bin/bash root@b1cbbad63dd1:/#

新しいmynginx4_filesヘルパー コンテナーは、永続的な標準入力 ( -iオプション) と tty ( -tオプション) を使用してフォアグラウンドで実行されます。 mynginx4で定義されたすべてのボリュームは、ヘルパー コンテナー内のローカル ディレクトリとしてマウントされます。

debian引数は、ヘルパー コンテナが Docker Hub の Debian イメージを使用することを意味します。 NGINX イメージも Debian を使用しているため (これまでのすべての例でも NGINX イメージを使用しています)、Docker に別のオペレーティング システムをロードさせるのではなく、ヘルパー コンテナーに Debian を使用するのが最も効率的です。 /bin/bash引数は、 bashシェルがヘルパー コンテナー内で実行され、必要に応じてファイルを変更するために使用できるシェル プロンプトが表示されることを意味します。

コンテナを起動および停止するには、次のコマンドを実行します。

# docker スタート mynginx4_files # docker ストップ mynginx4_files

シェルを終了してコンテナを実行したままにするには、 Ctrl+p を押してからCtrl+qを押します。 実行中のコンテナへのシェル アクセスを回復するには、次のコマンドを実行します。

# docker アタッチ mynginx4_files

シェルを終了してコンテナを終了するには、 exitコマンドを実行します。

ログの管理

デフォルトまたはカスタマイズされたログ記録を構成できます。

デフォルトのログの使用

NGINX イメージは、デフォルトでメインの NGINX アクセス ログとエラー ログを Docker ログ コレクターに送信するように構成されています。 これは、それぞれstdoutとstderrにリンクすることによって行われます。両方のログからのすべてのメッセージは、Docker ホスト上のファイル/var/lib/docker/containers/ container-ID / container-ID -json.logに書き込まれます。ここで、 container-ID は、コンテナを作成したときに返される長い形式の ID です。 たとえば、 「NGINX オープンソース Docker イメージの使用」で作成した初期コンテナの場合は、 fcd1fb01b14557c7c9d991238f2558ae2704d129cf9fb97bb4fadf673a58580dになります。

既存のコンテナのコンテナ ID を取得するには、次のコマンドを実行します。container ‑nameは、コンテナの作成時に--nameパラメータで設定された値です (たとえば、上記のコンテナ ID の場合はmynginx1です)。

# docker examine --format '{{ .Id }}'コンテナ名

container-ID -json.logファイルを直接開いてログを表示することもできますが、通常は次のコマンドを実行する方が簡単です。

# docker はコンテナ名をログに記録します

Docker Unix ソケットに対してGETリクエストを発行することで、 Docker Engine API を使用してログ メッセージを抽出することもできます。 このコマンドは、アクセス ログ ( stdout=1で表される) とエラー ログ ( stderr=1 ) の両方を返しますが、それらを個別に要求することもできます。

curl --unix-socket /var/run/docker-sock http://localhost/containers/コンテナ名/logs?stdout=1&stderr=1

その他のクエリ パラメータの詳細については、 Docker Engine API ドキュメント(そのページで「コンテナ ログの取得」を検索) を参照してください。

カスタマイズされたログの使用

別のログ収集方法を実装する場合、または特定の構成ブロック ( server{}やlocation{}など) でログ記録を異なる方法で構成する場合は、コンテナー内のログ ファイルを保存するディレクトリの Docker ボリュームを定義し、ログ ファイルにアクセスするためのヘルパー コンテナーを作成し、任意のログ記録ツールを使用します。 これを実装するには、ログ ファイル用のボリュームを含む新しいイメージを作成します。

たとえば、NGINX がログ ファイルを/var/log/nginx/logに保存するように構成するには、オプション 3のDockerfileから開始し、このディレクトリのVOLUME定義を追加するだけです。

nginxRUN から rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
コンテンツ /usr/share/nginx/html をコピー
conf /etc/nginx をコピー
ボリューム /var/log/nginx/log

次に、上記のようにイメージを作成し、それを使用して、ログ ディレクトリにアクセスできる NGINX コンテナーとヘルパー コンテナーを作成します。 ヘルパー コンテナーには、必要なログ記録ツールをインストールできます。

NGINXの制御

NGINX コンテナのコマンドラインに直接アクセスできないため、 nginxコマンドを使用して NGINX を制御することはできません。幸い、シグナルを使用して NGINX を制御することができ、Docker はコンテナにシグナルを送信するためのkillコマンドを提供しています。

NGINX 構成を再ロードするには、次のコマンドを実行します。

# docker kill -s HUPコンテナ名

NGINX を再起動するには、次のコマンドを実行してコンテナを再起動します。

# docker restartコンテナ名

Docker を使用した NGINX Plus のデプロイ

これまで、NGINX Open Source 用の Docker について説明してきましたが、商用製品である NGINX Plus でも使用できます。 違いは、NGINX Plus は商用製品として Docker Hub では利用できないため、最初に NGINX Plus イメージを作成する必要があることです。 幸いなことに、これは非常に簡単に実行できます。

注記： NGINX Plus イメージを Docker Hub などのパブリック リポジトリにアップロードしないでください。 そうすることはライセンス契約に違反します。

NGINX Plus の Docker イメージを作成する

NGINX Plus イメージを生成するには、まずDockerfile を作成します。 ここで提供する例では、ベース Docker イメージとして Alpine Linux 3.14 と Debian 11 (Bullseye) を使用します。 NGINX Plus Docker イメージを作成する前に、 nginx-repo.crt ファイルとnginx-repo.keyファイルのバージョンをダウンロードする必要があります。 NGINX Plus のお客様は、カスタマー ポータルでこれらを見つけることができます。NGINX Plus の無料トライアルをご利用の場合は、トライアル パッケージで提供されています。 ファイルをDockerfileが配置されているディレクトリ (Docker ビルド コンテキスト) にコピーします。

NGINX Open Source と同様に、デフォルトでは、NGINX Plus のアクセス ログとエラー ログは Docker ログ コレクターにリンクされます。 ボリュームは指定されていませんが、必要に応じて追加できます。また、前述のように、各Dockerfile を使用してベースイメージを作成し、そこからボリュームを指定して新しいイメージを作成することもできます。

サンプルDockerfilesでは NGINX Plus のバージョンを意図的に指定していないため、NGINX Plus の新しいリリースに更新するときにファイルを編集する必要がありません。 ただし、ファイルをバージョン固有にしたい場合はコメントを解除できるように、関連する手順のコメント付きバージョンも含まれています。

同様に、 NGINX Plus の公式動的モジュールをインストールする手順 (コメントアウト) も含まれています。

デフォルトでは、コンテナが作成されても Docker ホストからファイルはコピーされません。 各DockerfileにCOPY定義を追加したり、作成したイメージを上記のように別のイメージのベースとして使用したりすることもできます。

NGINX Plus Dockerfile (Debian 11)

NGINX Plus Dockerfile (Alpine Linux 3.14)

NGINX Plus イメージの作成

Dockerfile 、 nginx-repo.crt 、 nginx-repo.keyファイルが同じディレクトリにある状態で、次のコマンドを実行して、 nginxplusという Docker イメージを作成します (前と同じように、最後のピリオドに注意してください)。

# DOCKER_BUILDKIT=1 docker build --no-cache -t nginxplus --secret id=nginx-crt,src= your_cert_file --secret id=nginx-key,src= your_key_file .

DOCKER_BUILDKIT=1フラグは、以下で説明する--secretオプションを含める場合に必要となる、イメージのビルドにDocker BuildKit を使用していることを示します。

--no-cacheオプションは、 Docker にイメージを最初から構築するように指示し、最新バージョンの NGINX Plus がインストールされるようにします。 以前にDockerfileを使用してイメージを構築し、 --no-cacheオプションを含めなかった場合、新しいイメージは Docker キャッシュからの NGINX Plus のバージョンを使用します。 (前述のとおり、NGINX Plus の新しいリリースごとにファイルを変更する必要がないように、 Dockerfileでは意図的に NGINX Plus のバージョンを指定していません。) 以前にビルドしたイメージの NGINX Plus バージョンを使用しても問題ない場合は、 --no-cacheオプションを省略します。

--secretオプションは、データが公開されたり、Docker ビルド レイヤー間でデータが保持されるリスクなしに、NGINX Plus ライセンスの証明書とキーを Docker ビルド コンテキストに渡します。 id引数の値は、ベースのDockerfile を変更せずに変更することはできませんが、 src引数を NGINX Plus 証明書とキー ファイルへのパスに設定する必要があります (前の手順に従った場合は、Docker イメージを構築しているディレクトリと同じディレクトリです)。

docker images nginxplusコマンドからの次のような出力は、イメージが正常に作成されたことを示します。

# docker images nginxplusリポジトリ タグ イメージ ID 作成日 仮想サイズ nginxplus 最新 ef2bf65931cf 6 秒前 91.2 MB

このイメージに基づいてmynginxplusという名前のコンテナを作成するには、次のコマンドを実行します。

# docker run --name mynginxplus -p 80:80 -d nginxplus

NGINX Plus コンテナは、NGINX オープンソース コンテナと同じ方法で制御および管理できます。

まとめ

NGINX、NGINX Plus、Docker は連携して非常にうまく動作します。 Docker Hub の NGINX オープンソース イメージを使用する場合でも、独自の NGINX Plus イメージを作成する場合でも、Docker コンテナで NGINX および NGINX Plus の新しいインスタンスを簡単に起動し、Kubernetes 環境にデプロイできます。 また、ベースイメージから新しい Docker イメージを簡単に作成できるため、コンテナの制御と管理がさらに簡単になります。 Docker コンテナで実行されているすべての NGINX Plus インスタンスがサブスクリプションの対象になっていることを確認してください。 詳細については、 NGINX セールス チームにお問い合わせください。

Docker には、この記事で紹介した内容以外にも多くの機能があります。 詳細については、無料の O'Reilly 電子書籍「Container Networking」をダウンロードしてください。 Docker から Kubernetes まで– またはwww.docker.comをご覧ください。

関連ドキュメント

Docker に NGINX と NGINX Plus をデプロイする

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"