【入門】Docker Hub Nginx 公式イメージの徹底活用ガイド

コンテナ技術の普及により、アプリケーションのデプロイメントと管理は大きく進化しました。その中心にあるのがDockerであり、Webサーバーとして不動の地位を築いているNginxも、Dockerコンテナとして利用するのが一般的になりつつあります。

この記事では、Docker Hubで提供されている公式のNginxイメージに焦点を当て、その基本的な使い方から、実際の開発や運用で必要となる様々な応用方法までを、初心者の方でも理解できるよう丁寧に解説します。約5000語にわたる詳細な説明を通じて、Dockerized Nginxを自在に操るための知識とスキルを習得しましょう。

1. はじめに：なぜNginxをDockerで使うのか？

Nginxは、高性能かつ軽量なWebサーバー、リバースプロキシ、ロードバランサー、HTTPキャッシュとして広く利用されています。静的なファイルの配信から、複雑なアプリケーション構成まで、Webサービスにおける多くの場面でその力を発揮します。

一方、Dockerは、アプリケーションとその依存関係をコンテナと呼ばれる独立した実行環境にパッケージ化し、どの環境でも同じように動作することを保証する技術です。これにより、「私の環境では動くのに、あなたの環境では動かない」といった問題を解消し、開発、テスト、デプロイメントのプロセスを劇的に効率化します。

この二つを組み合わせることで、以下のような多くのメリットが得られます。

環境構築の簡素化と高速化: OSへのNginxのインストールや設定に時間をかけることなく、数コマンドでNginx環境を立ち上げることができます。
環境の分離と一貫性: Nginxとその設定はコンテナ内に完全に隔離されます。ホストOSや他のアプリケーションの影響を受けることがなく、常に同じ設定で動作します。開発環境、ステージング環境、本番環境など、異なる環境間での差異を最小限に抑えることができます。
ポータビリティ: 作成したコンテナイメージは、Dockerが動作するあらゆる環境で実行可能です。これにより、開発者のPC、テストサーバー、クラウド上のVMなど、場所を選ばずにNginx環境を展開できます。
バージョン管理とロールバック: 特定のバージョンのNginxイメージを使用することで、Nginx本体のバージョン管理が容易になります。問題が発生した場合も、以前の安定したバージョンのイメージに簡単に戻すことができます。
リソース効率: コンテナは仮想マシンに比べてオーバーヘッドが小さく、より効率的にリソース（CPU、メモリ）を利用できます。
依存関係の管理: Nginxが依存するライブラリなどはイメージ内に含まれているため、ホストOSのライブラリとの競合などを気にする必要がありません。
設定のコード化: Nginxの設定ファイルや静的コンテンツをホストOS上のファイルとして管理し、Dockerのボリューム機能を使ってコンテナにマウントすることで、設定をコードとして管理し、バージョン管理システム（Gitなど）で追跡できます。
マイクロサービスとの親和性: アプリケーションの一部としてNginxをコンテナ化することで、システム全体をコンテナベースで構築するマイクロサービスアーキテクチャに適応しやすくなります。

これらのメリットから、NginxをDockerコンテナとして利用することは、現代のWebアプリケーション開発および運用において、ほぼ必須の手法となっています。

この記事では、Docker Hubで公開されている公式のNginxイメージ nginx を中心に解説を進めます。このイメージは、Nginxを動作させるために必要最低限の構成要素を含んでおり、カスタマイズのベースとして最適です。

2. 事前準備：Dockerのインストール

この記事を読み進めるにあたり、お使いのPCまたはサーバーにDockerがインストールされている必要があります。まだインストールしていない場合は、以下の公式ドキュメントを参考に、お使いのOSに合った手順でDockerをインストールしてください。

Docker Desktop (Windows, macOS): https://www.docker.com/products/docker-desktop/
Docker Engine (Linux): https://docs.docker.com/engine/install/

インストール後、ターミナルまたはコマンドプロンプトを開き、以下のコマンドを実行してDockerが正しくインストールされ、動作しているか確認してください。

bash docker --version docker run hello-world

docker --version でバージョン情報が表示され、docker run hello-world で “Hello from Docker!” といったメッセージが表示されれば準備完了です。

また、基本的なターミナルの操作（ディレクトリの移動、ファイルの作成、編集など）に関する知識があると、よりスムーズに学習を進められます。

3. Docker Hub 公式 Nginx イメージとは？

Docker Hubは、Dockerイメージを共有するための公式レジストリです。世界中の開発者が作成したイメージが公開されており、OS、データベース、ミドルウェア、プログラミング言語の実行環境など、様々なソフトウェアの公式イメージが提供されています。

「公式イメージ (Official Image)」とは、Docker社によってレビューされ、ベストプラクティスに従って構築され、セキュリティパッチなどが定期的に適用される信頼性の高いイメージです。Nginxの公式イメージもその一つであり、Docker Hubで nginx という名前で公開されています。

Docker Hubの nginx ページはこちらです: https://hub.docker.com/_/nginx

このページには、イメージの概要、サポートされているタグ（バージョンやバリアント）、使い方、Dockerfileのリンクなどが記載されています。ドキュメントは常に最新の状態に保たれているため、利用する際は参照することをお勧めします。

公式イメージは、特別な設定を行わずにNginxを起動するだけであれば、最小限の手順で済みます。多くのユースケースに対応できるよう設計されていますが、デフォルトの状態では静的なHTMLファイルを表示するだけのシンプルなWebサーバーとして動作します。実際の用途に合わせて、設定ファイルやコンテンツをカスタマイズする必要があります。

4. 基本的なNginxコンテナの起動

それでは、早速公式Nginxイメージを使ってコンテナを起動してみましょう。

4.1. イメージの取得 (Pull)

Dockerコンテナを実行するには、まず元となるイメージが必要です。docker run コマンドは、ローカルにイメージが存在しない場合、自動的にDocker Hubから取得しようとします。しかし、事前に docker pull コマンドを使って明示的にイメージを取得しておくことも可能です。

bash docker pull nginx

このコマンドを実行すると、Docker Hubから最新版の公式Nginxイメージ（デフォルトでは latest タグ）がダウンロードされます。インターネット接続環境にもよりますが、通常は数十秒から数分で完了します。

Using default tag: latest latest: Pulling from library/nginx ... (ダウンロードの進行状況が表示される) ... Status: Downloaded newer image for nginx:latest docker.io/library/nginx:latest

ダウンロードが完了したら、以下のコマンドでローカルに保存されているイメージのリストを確認できます。

bash docker images

リストの中に nginx という名前のイメージが表示されていれば成功です。

REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest ... ... ... MB hello-world latest ... ... ... KB

4.2. Nginxコンテナの実行 (Run)

イメージの準備ができたら、いよいよコンテナを実行します。最も基本的な docker run コマンドは以下のようになります。

bash docker run nginx

このコマンドを実行すると、ターミナルにNginxのアクセスログやエラーログが表示され始め、Nginxがフォアグラウンドで起動します。

/docker-entrypoint.sh: /docker-entrypoint.d/ is empty, skipping... /docker-entrypoint.sh: Configuration complete; writing /etc/nginx/conf.d/default.conf 2023/10/27 10:00:00 [notice] 1#1: using the "epoll" event method 2023/10/27 10:00:00 [notice] 1#1: nginx/1.25.2 2023/10/27 10:00:00 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) ... (Nginxの起動ログ) ...

しかし、この状態ではホストOSからNginxにアクセスできません。なぜなら、Nginxはコンテナ内部のネットワーク上でポート80をリッスンしていますが、そのポートがホストOSのポートに紐づいていないからです。また、このコマンドだとターミナルがNginxのログで占有されてしまい、他の作業ができなくなります。

4.3. ポートマッピング (-p)

ホストOSからコンテナ内のサービスにアクセスできるようにするには、ポートマッピングが必要です。docker run コマンドの -p オプションを使用します。

構文は -p ホストのポート:コンテナのポート です。Nginxはデフォルトでコンテナ内のポート80で待ち受けているため、例えばホストOSのポート8080をコンテナのポート80にマッピングするには、以下のように指定します。

bash docker run -p 8080:80 nginx

このコマンドを実行した後、Webブラウザを開き、http://localhost:8080/ または http://127.0.0.1:8080/ にアクセスしてみてください。

Nginxのデフォルトページである “Welcome to nginx!” が表示されれば成功です！

4.4. デタッチモード (-d)

先ほどのコマンドでは、Nginxがフォアグラウンドで起動し、ターミナルがブロックされてしまいました。コンテナをバックグラウンドで実行し、ターミナルを解放するには、-d オプション（デタッチモード）を使用します。

bash docker run -d -p 8080:80 nginx

このコマンドを実行すると、コンテナのID（長い文字列）が表示され、ターミナルに戻ります。

bash $ docker run -d -p 8080:80 nginx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

これで、Nginxコンテナはバックグラウンドで実行されたまま、他のコマンドを入力できるようになります。ブラウザから http://localhost:8080/ にアクセスして、引き続きNginxのデフォルトページが表示されることを確認してください。

4.5. コンテナに名前をつける (–name)

実行中のコンテナを識別したり、後から操作したりする際に、自動生成される長いコンテナIDを使うのは不便です。--name オプションを使うと、コンテナにわかりやすい名前を付けることができます。

bash docker run -d -p 8080:80 --name my-nginx-container nginx

これで、このコンテナは my-nginx-container という名前で参照できるようになります。

docker ps コマンドを実行すると、現在実行中のコンテナのリストが表示されます。名前を付けたコンテナがリストに含まれていることを確認してください。

bash docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES xxxxxxxxxxxx nginx "nginx -g 'daemon of…" 10 seconds ago Up 9 seconds 0.0.0.0:8080->80/tcp my-nginx-container

NAMES 列に my-nginx-container と表示されていますね。

4.6. 実行中のコンテナの確認 (`docker ps`)

-d オプションで起動したコンテナが正しく実行されているか確認するには、docker ps コマンドを使います。

bash docker ps

実行中のコンテナが表示されます。-a オプションを付けると、停止中のコンテナも含め、全てのコンテナが表示されます。

bash docker ps -a

4.7. コンテナの停止と削除

実行中のコンテナを停止するには、docker stop コマンドにコンテナIDまたはコンテナ名を指定します。

bash docker stop my-nginx-container

停止したコンテナは、docker ps -a で確認できますが、システムのリソース（ディスク容量など）を消費したままです。完全に削除するには、docker rm コマンドを使用します。停止していないコンテナを削除しようとするとエラーになるため、通常は stop の後に rm を実行します。

bash docker rm my-nginx-container

停止と削除を一度に行いたい場合は、-f または --force オプションを docker rm に付けます。

bash docker rm -f my-nginx-container

ただし、運用中のコンテナに対して -f を使うのは注意が必要です。

これで、Nginxコンテナの基本的な起動、アクセス、停止、削除ができるようになりました。

5. 静的コンテンツの配信

Nginxの最も一般的な用途の一つは、静的なHTMLファイル、CSS、JavaScript、画像などのコンテンツを高速に配信することです。Dockerized Nginxで静的コンテンツを配信するには、主に二つの方法があります。

ボリュームを使ってホストOS上のディレクトリをマウントする: これが最も一般的で柔軟な方法です。ホストOSで管理している静的ファイルを、実行中のコンテナにリアルタイムに反映させることができます。
Dockerfileを使ってカスタムイメージを作成し、静的ファイルをイメージに含める: 静的ファイルが頻繁に変更されない場合や、アプリケーションと一緒に静的ファイルもパッケージングしたい場合に適しています。

ここでは、より一般的なボリュームマウントの方法を解説します。

5.1. Nginxコンテナ内の静的コンテンツディレクトリ

公式Nginxイメージでは、デフォルトの静的コンテンツのルートディレクトリは /usr/share/nginx/html です。デフォルトの “Welcome to nginx!” ページもこのディレクトリに含まれています。

私たちは、ホストOS上の静的コンテンツをこのディレクトリにマウントすることで、Nginxに配信させます。

5.2. ボリュームマウントの設定 (`-v`)

ボリュームマウントには、docker run コマンドの -v オプションを使用します。

構文は -v ホストのパス:コンテナのパス です。ホストOS上の特定のディレクトリを、コンテナ内の /usr/share/nginx/html にマウントします。

例として、ホストOSのカレントディレクトリ（コマンドを実行している場所）に html という名前のディレクトリを作成し、その中に index.html ファイルを作成してNginxに配信させてみましょう。

まず、ホストOSでディレクトリとファイルを作成します。

“`bash

html ディレクトリを作成

mkdir html

index.html ファイルを作成し、簡単な内容を書き込む

echo “

Hello from Dockerized Nginx!

This page is served from a volume mount.

” > html/index.html
“`

これで、ホストOSの現在のディレクトリ構造は以下のようになります。

. └── html └── index.html

次に、この html ディレクトリをNginxコンテナの /usr/share/nginx/html にマウントしてコンテナを起動します。

bash docker run -d -p 8080:80 --name my-nginx-static -v $(pwd)/html:/usr/share/nginx/html nginx

-d: バックグラウンドで実行
-p 8080:80: ホストの8080ポートをコンテナの80ポートにマッピング
--name my-nginx-static: コンテナに my-nginx-static という名前を付ける
-v $(pwd)/html:/usr/share/nginx/html: ホストOSのカレントディレクトリにある html ディレクトリ（絶対パスに展開するために $(pwd) を使用。Windowsの場合は %cd% など環境に合わせて変更するか、絶対パスを直接指定）を、コンテナ内の /usr/share/nginx/html にマウント

コンテナが起動したら、ブラウザで http://localhost:8080/ にアクセスしてください。

作成した index.html の内容、「Hello from Dockerized Nginx!」が表示されれば成功です。

ホストOSの html ディレクトリ内のファイルを変更してブラウザを更新すると、変更がすぐに反映されることが確認できます（ブラウザのキャッシュにご注意ください）。例えば、html/index.html を編集して内容を保存し、ブラウザをリロードしてみましょう。

この方法の利点は、コンテナを再起動することなく静的ファイルを更新できることです。Webサイトのコンテンツを頻繁に更新する場合や、開発中にライブリロードのような仕組みを構築する場合に非常に便利です。

コンテナを停止・削除するには、docker stop my-nginx-static && docker rm my-nginx-static を実行します。

6. Nginx設定のカスタマイズ

Nginxを実際の用途（リバースプロキシ、ロードバランシング、SSL設定、カスタムヘッダーなど）で利用するには、デフォルト設定をカスタマイズする必要があります。静的コンテンツと同様に、設定ファイルのカスタマイズにも主に二つの方法があります。

ボリュームを使ってホストOS上の設定ファイルをマウントする: これが最も一般的で、設定変更の柔軟性が高い方法です。
Dockerfileを使ってカスタムイメージを作成し、設定ファイルをイメージに含める: 設定が固定されている場合や、アプリケーションの一部として設定も含めて配布したい場合に適しています。

ここでも、ボリュームマウントを中心に解説します。

6.1. Nginxコンテナ内の設定ファイル構造

公式Nginxイメージでは、Nginxの設定ファイルは主に /etc/nginx/ ディレクトリ以下に格納されています。

/etc/nginx/nginx.conf: Nginxのメイン設定ファイルです。ワーカプロセス数、イベントモデル、エラーログの場所、HTTP設定の共通部分などが記述されています。
/etc/nginx/conf.d/: このディレクトリ内に配置された .conf で終わるファイルは、nginx.conf の http ブロック内で include /etc/nginx/conf.d/*.conf; という行によって自動的に読み込まれます。個別のサーバーブロック（virtual hostに相当）や、HTTP設定に共通のディレクティブを追加するのに便利な場所です。デフォルトでは default.conf がここに配置されており、”Welcome to nginx!” ページを配信する設定が記述されています。
/etc/nginx/sites-available/, /etc/nginx/sites-enabled/: Debian/Ubuntu系のパッケージでよく使われるサイト設定の管理方法ですが、公式Dockerイメージのデフォルト設定では conf.d が推奨されており、これらのディレクトリは通常使われません。

カスタマイズの際は、conf.d ディレクトリに新しい設定ファイルを追加するか、既存の default.conf を変更する、またはメインの nginx.conf を変更するといったアプローチを取ります。

6.2. `conf.d` ディレクトリへの設定ファイル追加（推奨）

最も一般的なカスタマイズ方法は、ホストOS上の設定ファイルを conf.d ディレクトリにマウントすることです。これにより、メインの nginx.conf を変更することなく、個別のサイト設定や機能設定を追加・変更できます。

例として、Nginxのデフォルト設定を変更し、特定のパスへのアクセスをカスタマイズする設定ファイルを作成してみましょう。

まず、ホストOS上で設定ファイル用のディレクトリとファイルを作成します。

“`bash

conf.d ディレクトリを作成

mkdir conf.d

default.conf を作成（今回はデフォルト設定を少し変更する想定）

例: /hello パスにアクセスしたら “Hello, World!” を返す

cat < conf.d/default.conf
server {
listen 80;
server_name localhost; # または実際のドメイン名

# デフォルトのルートディレクトリ
root /usr/share/nginx/html;
index index.html index.htm;

# ルートパスへのアクセス
location / {
    try_files \$uri \$uri/ =404;
}

# /hello パスへのアクセス設定を追加
location /hello {
    return 200 "Hello, World!\n"; # HTTPステータス200と共に文字列を返す
    add_header Content-Type text/plain; # レスポンスヘッダーを追加
}

# 別のパス例: /status にアクセスしたら Nginx のスタッス情報を返す
# この機能を使うには、Nginx を --with-http_stub_status_module でビルドする必要がある場合があります。
# 公式イメージは通常これが有効化されています。
location /status {
    stub_status on;
    allow 127.0.0.1; # アクセスを許可するIPアドレス（localhostのみに制限）
    deny all;         # それ以外のIPアドレスからのアクセスを拒否
}

# エラーページ設定
error_page 500 502 503 504 /50x.html;
location = /50x.html {
    root /usr/share/nginx/html;
}

}
EOF
“`

作成した conf.d/default.conf は、Nginxのデフォルト設定をベースに、/hello パスへのアクセスでテキストを返す設定と、/status パスでNginxのステータスを表示する設定を追加したものです。

次に、この conf.d ディレクトリをコンテナの /etc/nginx/conf.d にマウントしてコンテナを起動します。

bash docker run -d -p 8080:80 --name my-nginx-custom-conf \ -v $(pwd)/conf.d:/etc/nginx/conf.d \ nginx

-v $(pwd)/conf.d:/etc/nginx/conf.d: ホストOSのカレントディレクトリにある conf.d ディレクトリを、コンテナ内の /etc/nginx/conf.d にマウントします。これにより、コンテナ内の元の default.conf はこのマウントされたディレクトリの内容に置き換えられるか、マウントしたディレクトリがコンテナ側のディレクトリを隠蔽します。

コンテナが起動したら、ブラウザで以下のURLにアクセスして確認してください。

http://localhost:8080/: Nginxのデフォルトページが表示されるはずです（もし /usr/share/nginx/html に index.html が存在する場合）。
http://localhost:8080/hello: “Hello, World!” というテキストが表示されるはずです。
http://localhost:8080/status: Nginxのステータス情報が表示されるはずです（localhost からアクセスしている場合）。

期待通りの結果が得られれば成功です。

6.3. メイン設定ファイル (`nginx.conf`) のカスタマイズ

nginx.conf 自体を完全に置き換えたい場合もあります。例えば、ワーカプロセス数やイベント処理の設定、ログフォーマットなどを根本的に変更したい場合です。

この場合もボリュームマウントを使用しますが、マウント先は /etc/nginx/nginx.conf という単一のファイルになります。

まず、ホストOS上でカスタムの nginx.conf ファイルを作成します。公式イメージに含まれるデフォルトの nginx.conf をベースにするのが良いでしょう。コンテナからデフォルトファイルをコピーしてくることができます。

“`bash

一時的にNginxコンテナを起動し、デフォルト設定ファイルをコピー

docker run –rm -v $(pwd):/tmp nginx cat /etc/nginx/nginx.conf > nginx.conf

`--rm`: コンテナ終了時に自動的に削除するオプション

`-v $(pwd):/tmp`: ホストのカレントディレクトリをコンテナの /tmp にマウント

`cat /etc/nginx/nginx.conf`: コンテナ内でデフォルト設定ファイルの内容を表示

`> nginx.conf`: その内容をホストOSのカレントディレクトリの nginx.conf ファイルにリダイレクト

“`

これで、ホストOSにデフォルトの nginx.conf がコピーされました。このファイルを編集して、必要なカスタマイズを行います。

例：ワーカプロセス数をホストOSのコア数に合わせる、ログフォーマットを変更するなど。

“`nginx

nginx.conf の内容例 (抜粋)

user nginx;

worker_processes auto; # デフォルトは auto。具体的な数値にすることも可能

worker_processes 1; # 例: ワーカプロセスを1つに固定

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

# log_format  main  '$remote_addr - \$remote_user [\$time_local] "\$request" '
#                   '\$status \$body_bytes_sent "\$http_referer" '
#                   '"\$http_user_agent" "\$http_x_forwarded_for"';

# カスタムログフォーマットの例
log_format custom '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" '
                  '$request_time'; # リクエスト処理時間を追加

access_log  /var/log/nginx/access.log custom; # カスタムフォーマットを使用

sendfile        on;
#tcp_nopush     on;

keepalive_timeout  65;

#gzip  on;

include /etc/nginx/conf.d/*.conf; # この行は残しておくのが一般的

}
“`

編集した nginx.conf を使ってコンテナを起動します。

bash docker run -d -p 8080:80 --name my-nginx-main-conf \ -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf \ -v $(pwd)/conf.d:/etc/nginx/conf.d \ nginx

-v $(pwd)/nginx.conf:/etc/nginx/nginx.conf: ホストOSの nginx.conf ファイルをコンテナの /etc/nginx/nginx.conf にマウントします。
-v $(pwd)/conf.d:/etc/nginx/conf.d: conf.d ディレクトリのマウントも忘れずに行います。新しい nginx.conf が include /etc/nginx/conf.d/*.conf; を含んでいる場合、このマウントによってカスタム設定も読み込まれます。

この方法では、コンテナ起動時に /etc/nginx/nginx.conf がホスト側のファイルで完全に置き換えられます。

注意点:
* 単一ファイルをマウントする場合、ホスト側のファイルが存在しないとエラーになる可能性があります。
* コンテナ側の元のファイルは隠蔽されるため、元の設定を参考にしたい場合は事前にコピーしておく必要があります。
* ディレクトリをマウントする -v /host/dir:/container/dir と、ファイルをマウントする -v /host/file:/container/file では挙動が異なります。特にファイルの所有者やパーミッションに注意が必要です。公式イメージは通常 nginx ユーザーで実行されます。ホスト側のファイルに適切な読み取り権限がないと、コンテナ内のNginxから読み込めずにエラーになる可能性があります。

6.4. 設定変更の反映（リロード）

ボリュームマウントを使ってNginxの設定ファイルを変更した場合、その変更をNginxに認識させるには、通常「リロード」という操作が必要です。Nginxを停止・起動するのではなく、設定ファイルを再読み込みさせることで、サービスを中断せずに変更を反映できます。

Dockerコンテナ内で実行中のNginxにリロードコマンドを送るには、docker exec コマンドを使用します。

bash docker exec --name my-nginx-custom-conf nginx -s reload

docker exec my-nginx-custom-conf: 指定したコンテナ（my-nginx-custom-conf）内でコマンドを実行します。
nginx -s reload: Nginxに対して設定ファイルのリロードシグナルを送るコマンドです。-s はシグナルを送るオプションで、reload はシグナルの種類です。

設定ファイルに構文エラーがある場合、リロードは失敗します。エラーの内容は docker logs my-nginx-custom-conf で確認できます。リロード前に構文チェックだけを行うことも可能です。

bash docker exec my-nginx-custom-conf nginx -t

nginx -t コマンドは設定ファイルの構文チェックを行います。問題がなければ syntax is ok と表示されます。問題がある場合はエラー内容が表示されるため、リロード前に必ず実行することをお勧めします。

ボリュームマウントと docker exec によるリロードは、開発中や運用中にNginxの設定を頻繁に変更する場合に非常に強力な手法です。

7. 異なるバージョンの利用 (Tags)

Dockerイメージは「タグ (Tag)」によってバージョンやバリアントが管理されています。デフォルトで docker pull nginx や docker run nginx とした場合に使用されるのは latest タグですが、これは最新版のNginxを指しており、予期せぬ変更が含まれる可能性があります。本番環境などでは、特定の安定したバージョンを指定するのが一般的です。

Docker HubのNginxページを見ると、非常に多くのタグが存在することがわかります。

latest: 最新の安定版Nginx。OSとしてはDebianベースのフルイメージが多いです。
バージョン番号 (1.25.2, 1.24.0 など): 特定のNginxバージョンを指します。
バージョン番号とOS (1.25.2-bookworm, 1.24.0-alpine など): 特定のNginxバージョンと、ベースとなるOSディストリビューション（Debian bookworm, Alpine Linuxなど）を組み合わせたタグです。
バリアント (alpine, stable など): Alpine Linuxをベースにした軽量なイメージ（alpine）や、安定版ブランチの最新（stable）などがあります。

タグを指定するには、イメージ名に続けて : の後にタグ名を記述します。

“`bash

特定バージョンを指定して取得

docker pull nginx:1.25.2

特定バージョンかつAlpine版を指定して取得

docker pull nginx:1.25.2-alpine

特定バージョンを指定して実行

docker run -d -p 8080:80 –name my-nginx-specific nginx:1.25.2
“`

7.1. `latest` タグについて

latest タグは便利ですが、注意が必要です。latest は常に「最新版」を指すため、いつ docker pull latest を実行するかによって、取得するイメージの内容が変わる可能性があります。これにより、異なる環境で同じコマンドを実行しても、異なるバージョンのNginxが起動してしまう、あるいは予期せぬアップデートによって既存の設定が動かなくなる、といった問題が発生する可能性があります。

開発環境で気軽に試す分には問題ありませんが、本番環境やCI/CDパイプラインなど、再現性が求められる場所では、必ず特定のタグを指定することを強く推奨します。

7.2. Alpine バリアント (`-alpine`)

多くの公式イメージには -alpine というタグが付いたバリアントが存在します。これは、Alpine Linuxという非常に軽量なLinuxディストリビューションをベースに構築されたイメージです。

メリット: イメージサイズが非常に小さい（数十MB程度）。セキュリティの攻撃対象領域が少ない。
デメリット: 一部のツールやライブラリが含まれていない場合がある。libcとしてglibcではなくmusl libcを使用しているため、特定のバイナリ互換性に注意が必要な場合がある。

WebサーバーとしてNginxを使うだけであれば、Alpine版で十分なことが多く、イメージサイズが小さいことはイメージのプルやデプロイの高速化につながるためメリットが大きいです。特別な理由がなければ、-alpine タグの利用を検討する価値があります。

“`bash

Alpine版の最新安定版を取得

docker pull nginx:alpine

特定バージョンかつAlpine版を実行

docker run -d -p 8080:80 –name my-nginx-alpine nginx:1.25.2-alpine
“`

利用目的や環境に合わせて、適切なタグを選択することが重要です。

8. カスタムNginxイメージの構築 (Dockerfile)

ボリュームマウントは柔軟ですが、設定ファイルや静的コンテンツがホストOSに依存するという側面もあります。「アプリケーション本体」「Nginxの設定」「静的ファイル」をまとめて一つのポータブルな単位として扱いたい場合は、Dockerfileを使ってカスタムイメージを構築するのが良いでしょう。

Dockerfileは、Dockerイメージを自動的に構築するための一連の命令を記述したテキストファイルです。

8.1. なぜカスタムイメージをビルドするのか？

ポータビリティ: 設定やコンテンツをイメージに含めることで、イメージ単体でどこでも同じように実行できます。ボリュームマウントのように、ホストOS側に特定のディレクトリ構造やファイルが存在している必要がありません。
ビルド時の処理: イメージビルド時に追加のパッケージをインストールしたり、ファイルを生成したりといった処理を実行できます。
レイヤーキャッシュの利用: Dockerはイメージをレイヤー構造で管理しており、Dockerfileの各命令は新しいレイヤーを作成します。変更がないステップは前回のビルドのキャッシュが再利用されるため、効率的にイメージをビルドできます。
バージョン管理: Dockerfile自体をバージョン管理システムで管理することで、イメージの構築手順とその内容を追跡できます。

8.2. Dockerfileの基本構成

簡単なNginxのカスタムイメージを構築するDockerfileの例を見てみましょう。目的は、静的ファイルとカスタム設定をイメージに含めることです。

まず、プロジェクトのディレクトリ構造を以下のように準備します。

. ├── Dockerfile ├── html/ │ └── index.html └── conf.d/ └── default.conf

先ほど作成した html/index.html と conf.d/default.conf をこのディレクトリに配置します。

Dockerfile ファイルを作成し、以下の内容を記述します。

“`dockerfile

ベースイメージとして公式のNginxイメージを指定

FROM nginx:latest # または nginx:1.25.2-alpine など特定のタグを指定

静的コンテンツをイメージにコピー

ホストOSの ./html ディレクトリの内容を、コンテナ内の /usr/share/nginx/html にコピー

COPY html/ /usr/share/nginx/html/

カスタム設定ファイルをイメージにコピー

ホストOSの ./conf.d ディレクトリの内容を、コンテナ内の /etc/nginx/conf.d にコピー

COPY conf.d/ /etc/nginx/conf.d/

Nginxがデフォルトで使うポート80を公開することを宣言 (ドキュメント目的)

EXPOSE 80

デフォルトのCMDはベースイメージから引き継がれるため、ここでは指定しない

ベースイメージのCMDは通常 [“nginx”, “-g”, “daemon off;”] となっており、これがNginxをフォアグラウンドで起動する

“`

FROM nginx:latest: どのイメージをベースにするかを指定します。公式Nginxイメージの latest タグを使っていますが、本番では特定のバージョンやAlpine版を指定すべきです。
COPY html/ /usr/share/nginx/html/: ホストOSのカレントディレクトリにある html ディレクトリの中身を、イメージ内の /usr/share/nginx/html にコピーします。
COPY conf.d/ /etc/nginx/conf.d/: 同様に conf.d ディレクトリの中身をイメージ内の /etc/nginx/conf.d にコピーします。
EXPOSE 80: このイメージがポート80をリッスンすることを示すメタデータです。必須ではありませんが、ドキュメントとして役立ちます。実際にポートをホストに公開するには docker run -p が必要です。

8.3. イメージのビルド

Dockerfileを作成したら、docker build コマンドを使ってイメージをビルドします。Dockerfileが置かれているディレクトリで以下のコマンドを実行します。

bash docker build -t my-custom-nginx .

-t my-custom-nginx: ビルドするイメージに my-custom-nginx という名前（タグ）を付けます。名前の後に :tag を付けてバージョンなどを指定することもできます（例: -t my-custom-nginx:v1.0）。
.: Dockerfileが置かれているパスを指定します。. はカレントディレクトリを意味します。

ビルドプロセスが開始され、Dockerfileの各命令が実行されます。成功すると、指定した名前のイメージがローカルに作成されます。

bash $ docker build -t my-custom-nginx . [+] Building 12.3s (8/8) FINISHED => [internal] load .dockerignore => [internal] load build definition from Dockerfile ... => [1/4] FROM nginx:latest => [2/4] COPY html/ /usr/share/nginx/html/ => [3/4] COPY conf.d/ /etc/nginx/conf.d/ => [4/4] EXPOSE 80 => [+] Exporting to image => [+] Exporting to image

docker images コマンドで、作成されたイメージを確認できます。

bash docker images

REPOSITORY TAG IMAGE ID CREATED SIZE my-custom-nginx latest ... ... seconds ago ... MB # 作成したイメージ nginx latest ... ... ago ... MB # ベースイメージ ...

8.4. カスタムイメージの実行

ビルドしたカスタムイメージを使ってコンテナを起動します。実行方法は、公式イメージを使う場合とほとんど同じです。

bash docker run -d -p 8080:80 --name my-nginx-from-image my-custom-nginx

このコンテナは、イメージに含まれている静的ファイルと設定ファイルを使ってNginxを起動します。ブラウザで http://localhost:8080/ や http://localhost:8080/hello にアクセスして、期待通りに動作することを確認してください。

カスタムイメージの利点は、この my-custom-nginx イメージをDockerレジストリ（Docker Hubやプライベートレジストリ）にプッシュすれば、どの環境でも同じ設定とコンテンツを持つNginxコンテナを簡単に起動できるようになる点です。

“`bash

(オプション) Docker Hubにプッシュする場合（要ログイン、イメージ名にユーザー名/必要に応じてレジストリ名をつける）

docker tag my-custom-nginx your-dockerhub-username/my-custom-nginx:v1.0

docker push your-dockerhub-username/my-custom-nginx:v1.0

“`

8.5. その他のDockerfile命令

Dockerfileでは、他にも様々な命令を使用してイメージをカスタマイズできます。

RUN: イメージビルド中にコマンドを実行します（例: 追加パッケージのインストール apt-get update && apt-get install -y some-package）。
WORKDIR: 以降の命令（RUN, COPY, CMD など）が実行されるディレクトリを指定します。
USER: 以降の命令や、コンテナ実行時のユーザーを指定します（例: USER nginx でNginxユーザーで実行）。
ARG: ビルド時に引数として渡せる変数を定義します。
ENV: 環境変数を設定します。

より高度なカスタマイズが必要な場合は、これらの命令を組み合わせて使用します。

9. 環境変数

Dockerコンテナの設定の一部を環境変数で指定することはよく行われます。公式Nginxイメージは、デフォルトではNginx自体の設定に関する組み込みの環境変数をあまりサポートしていません。Nginxの設定は主に設定ファイルを編集することで行われるためです。

ただし、エントリーポイントスクリプトによっては、特定の環境変数を読み取ってNginxの設定ファイルを生成・変更する場合があります。公式イメージのエントリーポイントスクリプト (/docker-entrypoint.sh) は、/docker-entrypoint.d/ ディレクトリにあるシェルスクリプトや実行可能ファイルを起動前に実行します。

例えば、カスタムスクリプトを作成して、環境変数からNginx設定ファイルの一部を動的に生成し、それを /etc/nginx/conf.d/ に配置するといったことが可能です。

簡単な例として、環境変数 SERVER_NAME の値を conf.d/default.conf に反映させるスクリプトをイメージに含めることを考えます。

まず、docker-entrypoint.d ディレクトリを作成し、スクリプトファイル (10-server-name.sh など) を用意します。ファイル名の若い順に実行されます。

“`bash
mkdir docker-entrypoint.d

cat < docker-entrypoint.d/10-server-name.sh

!/bin/sh

set -e

環境変数 SERVER_NAME が設定されているかチェック

if [ -n “\$SERVER_NAME” ]; then
echo “Using server_name: \$SERVER_NAME”
# default.conf をテンプレートとして読み込み、SERVER_NAME を置換して新しい設定ファイルを生成
# 実際のテンプレート処理はもっと複雑になる場合があります。ここでは簡略化のためsedを使用
sed -i “s/server_name localhost;/server_name \$SERVER_NAME;/” /etc/nginx/conf.d/default.conf
else
echo “SERVER_NAME environment variable not set. Using default.”
fi

DockerfileのCOPY命令でこのスクリプトをイメージにコピーし、実行可能にする

COPY docker-entrypoint.d/ /docker-entrypoint.d/

RUN chmod +x /docker-entrypoint.d/*

EOF
“`

このスクリプトは、コンテナ起動時に $SERVER_NAME 環境変数をチェックし、存在すれば /etc/nginx/conf.conf の server_name localhost; 行を $SERVER_NAME; に置き換えます。

次に、このスクリプトをDockerfileでイメージにコピーし、実行権限を付けます。

“`dockerfile
FROM nginx:latest

COPY html/ /usr/share/nginx/html/
COPY conf.d/ /etc/nginx/conf.d/ # 元の default.conf も必要

カスタムエントリーポイントスクリプトをコピーし、実行可能にする

COPY docker-entrypoint.d/ /docker-entrypoint.d/
RUN chmod +x /docker-entrypoint.d/*

EXPOSE 80
“`

イメージをビルドし、SERVER_NAME 環境変数を指定して実行します。

“`bash

イメージをビルド

docker build -t my-nginx-env .

環境変数を指定してコンテナを実行

docker run -d -p 8080:80 –name my-nginx-env \
-e SERVER_NAME=example.com \
my-nginx-env
“`

-e SERVER_NAME=example.com: SERVER_NAME という環境変数に example.com という値を設定してコンテナを実行します。

コンテナ内で実行されるエントリーポイントスクリプトがこの環境変数を読み取り、Nginx設定ファイルを変更してNginxを起動します。

この手法は、データベースの接続先やAPIキーなど、コンテナのデプロイ時に外部から渡したい設定情報があり、かつそれがNginxの設定に影響する場合に有効です。ただし、Nginxのすべての設定項目を環境変数で制御するのは現実的ではないため、主に動的な値（サーバー名、アップストリームサーバーのリストなど）に使用されます。

10. その他の応用と発展

DockerとNginxの組み合わせは、様々な用途に応用できます。ここではいくつかの例を紹介します。

10.1. リバースプロキシとして利用

Nginxはリバースプロキシとして非常に優れています。これは、クライアントからのリクエストをNginxが受け付け、それをバックエンドのアプリケーションサーバー（例えばNode.js, Python, Javaなどのサーバー）に転送する役割です。これにより、Nginxで静的ファイルの配信、SSL終端、ロードバランシングなどを担当させ、バックエンドはアプリケーションロジックに専念させることができます。

リバースプロキシの設定も、Nginxの設定ファイル（通常 conf.d 内のファイル）をボリュームマウントするか、カスタムイメージに含めることで実現します。

例：ホストOSのポート8080でNginxが待ち受け、コンテナネットワーク上の別のコンテナ（例えば my-app という名前のNode.jsアプリコンテナ）のポート3000にリクエストを転送する設定。

conf.d/reverse-proxy.conf:

“`nginx
server {
listen 80;
server_name localhost; # またはリバースプロキシとして待ち受けるドメイン名

location / {
    # リクエストを別のコンテナに転送
    # コンテナ名（my-app）がDNS名として解決できる前提（Docker Composeなどで同じネットワークに配置する場合）
    proxy_pass http://my-app:3000;

    # プロキシに関するヘッダー設定 (任意、推奨)
    proxy_set_header Host \$host;
    proxy_set_header X-Real-IP \$remote_addr;
    proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto \$scheme;
}

# 静的ファイルはNginxが直接配信するなど、他のロケーションブロックも設定可能
# location /static/ {
#     alias /usr/share/nginx/html/static/;
# }

}
“`

この設定ファイルを使ってNginxコンテナを起動し、同時にバックエンドのアプリケーションコンテナも起動します。この構成は通常、Docker Composeを使用して定義・管理します（後述）。

10.2. SSL/TLS終端

HTTPSを有効にするには、SSL証明書と秘密鍵をNginxコンテナから参照できるようにし、Nginx設定でSSLを構成します。

証明書と秘密鍵も、ボリュームマウントを使ってコンテナに渡すのが一般的です。

例：conf.d/ssl.conf (または既存のサーバーブロックに追記):

“`nginx
server {
listen 443 ssl; # HTTPS ポートでリッスン
server_name your.domain.com;

ssl_certificate /etc/nginx/certs/fullchain.pem; # コンテナ内の証明書パス
ssl_certificate_key /etc/nginx/certs/privkey.pem; # コンテナ内の秘密鍵パス

# 推奨されるSSL設定 (セキュリティとパフォーマンスのため)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s; # OCSP StaplingのためのDNSリゾルバー
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

# HTTP から HTTPS へのリダイレクト設定 (オプション)
# server {
#     listen 80;
#     server_name your.domain.com;
#     return 301 https://$host$request_uri;
# }

location / {
    # 静的ファイル配信、またはプロキシ設定など
    # root /usr/share/nginx/html;
    # index index.html;
    proxy_pass http://my-app:3000;
    # ...
}

}
“`

証明書ファイル (fullchain.pem) と秘密鍵ファイル (privkey.pem) をホストOS上のディレクトリ（例: ./certs）に置き、それをコンテナの /etc/nginx/certs/ にマウントしてコンテナを起動します。

“`bash

ホストOSに certs ディレクトリを作成し、証明書と秘密鍵を配置

mkdir certs

(ここに fullchain.pem と privkey.pem を置く)

コンテナ起動コマンド

docker run -d -p 80:80 -p 443:443 –name my-nginx-ssl \
-v $(pwd)/conf.d:/etc/nginx/conf.d \
-v $(pwd)/certs:/etc/nginx/certs \
nginx
“`

ポートマッピングでポート80と443の両方を公開し、設定ファイルと証明書をマウントします。

Let’s Encryptなどのツールを使って証明書を取得する場合、それを自動化するために certbot などのDockerイメージと組み合わせて使用することも可能です。

10.3. Docker Composeとの連携

複数のコンテナを組み合わせてアプリケーションを構築する場合（例えばNginx + アプリケーションサーバー + データベース）、Docker Composeを使うのが非常に便利です。Docker Composeを使うと、複数のコンテナの設定、依存関係、ネットワークなどを docker-compose.yml という一つのファイルに定義し、docker-compose up コマンド一つでまとめて起動・管理できます。

リバースプロキシやSSL終端の例のように、Nginxが他のサービスコンテナと連携する場合、Docker Composeは必須とも言えるツールです。

簡単な docker-compose.yml の例：NginxがバックエンドのPython/Flaskアプリにリクエストをプロキシする構成。

“`yaml

docker-compose.yml

version: ‘3.8’

services:
web:
image: nginx:latest # または特定のタグ
ports:
– “80:80”
– “443:443” # SSLを使う場合
volumes:
– ./conf.d:/etc/nginx/conf.d # Nginx設定ファイルのマウント
– ./html:/usr/share/nginx/html # 静的ファイルのマウント (任意)
– ./certs:/etc/nginx/certs # SSL証明書のマウント (任意)
depends_on:
– app # app サービスの起動を待つ
networks:
– my_network # 同じネットワークに配置

app:
build: ./app # ./app ディレクトリにあるDockerfileからイメージをビルド
# image: my-backend-app:latest # または既存のイメージ
ports:
– “3000” # ホストに公開せず、同じネットワーク内の他のサービス（web）からアクセス可能にする
networks:
– my_network

networks:
my_network: # カスタムネットワークを定義
driver: bridge
“`

この docker-compose.yml ファイルがあるディレクトリで docker-compose up -d を実行すると、web サービス（Nginxコンテナ）と app サービス（アプリケーションコンテナ）が起動し、定義されたネットワーク内で互いに通信できるようになります。Nginxの設定ファイル (conf.d/reverse-proxy.conf など) では、バックエンドのアドレスとして http://app:3000 のようにサービス名（app）をホスト名として指定できます。

Docker ComposeはNginxを含む複数のコンテナで構成されるアプリケーションを管理するための標準的な方法であり、ぜひ使い方を習得することをお勧めします。

11. トラブルシューティング

Dockerized Nginxを使っていると、いくつかの一般的な問題に遭遇する可能性があります。

Nginxにアクセスできない (接続 refused/timeout):
- ポートマッピングの確認: docker run -p でホストOSのポートとコンテナのポートが正しくマッピングされているか確認してください。docker ps の PORTS 列で確認できます。
- コンテナの起動状態: docker ps でコンテナが Up 状態になっているか確認してください。エラーになっている場合は docker logs <container_name> でログを確認します。
- ファイアウォール: ホストOSやネットワークのファイアウォールが、指定したポートへのアクセスをブロックしていないか確認してください。
- Nginxの設定: Nginxが正しいポート（デフォルトは80、SSLなら443）で待ち受ける設定になっているか確認してください（conf.d の設定など）。
“Welcome to nginx!” 以外のコンテンツが表示されない:
- ボリュームマウントの確認: 静的ファイルや設定ファイルをマウントしている場合、docker inspect <container_name> コマンドで Mounts セクションを確認し、ホストOSのパスとコンテナのパスが正しくマッピングされているか確認してください。特にホスト側の絶対パス指定が正しいか注意が必要です。
- ファイルの存在とパーミッション: マウントしたホストOS側のディレクトリやファイルが、コンテナ内のNginxユーザー（デフォルトは nginx）から読み取り可能になっているか確認してください。Linuxの場合、ファイルの所有者やグループ、パーミッションが原因でアクセスできないことがあります。chown や chmod で調整が必要な場合があります。
- Nginxの設定: Nginxの設定ファイル（conf.d 内など）で、root ディレクティブや alias ディレクティブが正しいコンテナ内のパスを指しているか、index ファイルが正しく指定されているか確認してください。
- 設定のリロード: 設定ファイルを変更した場合、docker exec <container_name> nginx -s reload で設定をリロードしたか確認してください。
Nginxが起動しない、またはエラーログが出力される:
- コンテナログの確認: docker logs <container_name> コマンドで、コンテナ起動時のログやNginxのエラーログを確認してください。設定ファイルの構文エラーや、ボリュームマウントされたファイルの読み取りエラーなどが表示されます。
- 設定ファイルの構文チェック: docker exec <container_name> nginx -t コマンドで、コンテナ内のNginxが設定ファイルの構文をチェックできるか確認してください。
- ポート衝突: docker run 時に指定したホストOSのポートが、既に他のプロセスによって使用されていないか確認してください。
イメージのプルが遅い/失敗する:
- インターネット接続: ネットワーク接続が安定しているか確認してください。
- Docker Hubへのアクセス: Docker Hubへのアクセスが制限されていないか確認してください。
- 指定したタグが存在しない: 指定したタグがDocker Hubに存在するか確認してください。

トラブルシューティングの基本は、「ログを見る」「設定を確認する」「環境（ファイルパス、パーミッション、ネットワーク）を確認する」ことです。Dockerの logs、ps、inspect、exec といったコマンドを駆使して、問題の原因を特定しましょう。

12. まとめと次のステップ

この記事では、Docker Hub公式のNginxイメージの使い方を、基本的な起動から、静的コンテンツの配信、設定ファイルのカスタマイズ、異なるバージョンの利用、カスタムイメージの構築、そして応用例やトラブルシューティングまで、幅広くかつ詳細に解説しました。

NginxをDockerコンテナとして利用することは、環境構築の手間を省き、アプリケーションのポータビリティを高め、開発・運用ワークフローを効率化する上で非常に効果的な手法です。ボリュームマウントによる設定・コンテンツの柔軟な管理と、Dockerfileによるアプリケーションを含めた一貫したパッケージングという二つの主要なアプローチを理解することは、Dockerized Nginxを使いこなす上で不可欠です。

ここで学んだことを活かして、ぜひ実際に手を動かしてみてください。

様々なNginx設定（リダイレクト、キャッシュ、gzip圧縮など）を試す。
リバースプロキシとして、簡単なバックエンドアプリケーション（PythonのFlaskやNode.jsのExpressなど）と連携させてみる。
Let’s Encryptなどで取得した証明書を使ってSSL設定をしてみる。
Dockerfileを使って、より複雑なカスタムイメージをビルドしてみる。
Docker Composeを使って、複数のサービスで構成されるアプリケーション全体を定義・起動してみる。

これらのステップに進むことで、DockerとNginxを使った本格的なWebアプリケーション環境の構築・運用スキルが身につくはずです。

DockerとNginxの世界は奥深く、この記事で触れたのはその入り口に過ぎません。しかし、公式イメージの基本的な使い方とカスタマイズ方法を理解した今、Docker HubのドキュメントやNginxの公式ドキュメントなどを参照しながら、さらに高度な機能や設定にも挑戦できるようになっていることでしょう。

Happy containerizing!

【入門】Docker Hub Nginx 公式イメージの徹底活用ガイド

1. はじめに：なぜNginxをDockerで使うのか？

2. 事前準備：Dockerのインストール

3. Docker Hub 公式 Nginx イメージとは？

4. 基本的なNginxコンテナの起動

4.1. イメージの取得 (Pull)

4.2. Nginxコンテナの実行 (Run)

4.3. ポートマッピング (-p)

4.4. デタッチモード (-d)

4.5. コンテナに名前をつける (–name)

4.6. 実行中のコンテナの確認 (docker ps)

4.7. コンテナの停止と削除

5. 静的コンテンツの配信

5.1. Nginxコンテナ内の静的コンテンツディレクトリ

5.2. ボリュームマウントの設定 (-v)

html ディレクトリを作成

index.html ファイルを作成し、簡単な内容を書き込む

Hello from Dockerized Nginx!

6. Nginx設定のカスタマイズ

6.1. Nginxコンテナ内の設定ファイル構造

6.2. conf.d ディレクトリへの設定ファイル追加（推奨）

conf.d ディレクトリを作成

default.conf を作成（今回はデフォルト設定を少し変更する想定）

例: /hello パスにアクセスしたら “Hello, World!” を返す

6.3. メイン設定ファイル (nginx.conf) のカスタマイズ

一時的にNginxコンテナを起動し、デフォルト設定ファイルをコピー

--rm: コンテナ終了時に自動的に削除するオプション

-v $(pwd):/tmp: ホストのカレントディレクトリをコンテナの /tmp にマウント

cat /etc/nginx/nginx.conf: コンテナ内でデフォルト設定ファイルの内容を表示

> nginx.conf: その内容をホストOSのカレントディレクトリの nginx.conf ファイルにリダイレクト

nginx.conf の内容例 (抜粋)

worker_processes auto; # デフォルトは auto。具体的な数値にすることも可能

6.4. 設定変更の反映（リロード）

7. 異なるバージョンの利用 (Tags)

特定バージョンを指定して取得

特定バージョンかつAlpine版を指定して取得

特定バージョンを指定して実行

7.1. latest タグについて

7.2. Alpine バリアント (-alpine)

Alpine版の最新安定版を取得

特定バージョンかつAlpine版を実行

8. カスタムNginxイメージの構築 (Dockerfile)

8.1. なぜカスタムイメージをビルドするのか？

8.2. Dockerfileの基本構成

ベースイメージとして公式のNginxイメージを指定

静的コンテンツをイメージにコピー

ホストOSの ./html ディレクトリの内容を、コンテナ内の /usr/share/nginx/html にコピー

カスタム設定ファイルをイメージにコピー

ホストOSの ./conf.d ディレクトリの内容を、コンテナ内の /etc/nginx/conf.d にコピー

Nginxがデフォルトで使うポート80を公開することを宣言 (ドキュメント目的)

デフォルトのCMDはベースイメージから引き継がれるため、ここでは指定しない

ベースイメージのCMDは通常 [“nginx”, “-g”, “daemon off;”] となっており、これがNginxをフォアグラウンドで起動する

8.3. イメージのビルド

8.4. カスタムイメージの実行

(オプション) Docker Hubにプッシュする場合（要ログイン、イメージ名にユーザー名/必要に応じてレジストリ名をつける）

docker tag my-custom-nginx your-dockerhub-username/my-custom-nginx:v1.0

docker push your-dockerhub-username/my-custom-nginx:v1.0

8.5. その他のDockerfile命令

9. 環境変数

!/bin/sh

環境変数 SERVER_NAME が設定されているかチェック

DockerfileのCOPY命令でこのスクリプトをイメージにコピーし、実行可能にする

COPY docker-entrypoint.d/ /docker-entrypoint.d/

RUN chmod +x /docker-entrypoint.d/*

カスタムエントリーポイントスクリプトをコピーし、実行可能にする

イメージをビルド

環境変数を指定してコンテナを実行

10. その他の応用と発展

10.1. リバースプロキシとして利用

10.2. SSL/TLS終端

ホストOSに certs ディレクトリを作成し、証明書と秘密鍵を配置

mkdir certs

(ここに fullchain.pem と privkey.pem を置く)

コンテナ起動コマンド

10.3. Docker Composeとの連携

docker-compose.yml

11. トラブルシューティング

12. まとめと次のステップ

コメントする 返信をキャンセル

4.6. 実行中のコンテナの確認 (`docker ps`)

5.2. ボリュームマウントの設定 (`-v`)

6.2. `conf.d` ディレクトリへの設定ファイル追加（推奨）

6.3. メイン設定ファイル (`nginx.conf`) のカスタマイズ

`--rm`: コンテナ終了時に自動的に削除するオプション

`-v $(pwd):/tmp`: ホストのカレントディレクトリをコンテナの /tmp にマウント

`cat /etc/nginx/nginx.conf`: コンテナ内でデフォルト設定ファイルの内容を表示

`> nginx.conf`: その内容をホストOSのカレントディレクトリの nginx.conf ファイルにリダイレクト

7.1. `latest` タグについて

7.2. Alpine バリアント (`-alpine`)

コメントする返信をキャンセル