Certbot で Let's Encrypt の SSL 証明書を取得する（Web サーバーの HTTPS 対応）

更新: 2022-12-03
作成: 2022-12-03

何をするか？

数年前に Google が Web サイトの常時 SSL 化を推奨し始めて、今では多くの Web サイトが HTTPS によるアクセスに対応しています。 Web サーバーを HTTPS (SSL) 対応するには、第三者機関となる認証局 (CA: Certificate Authority) から SSL 証明書を発行してもらう必要があるのですが、Let’s Encrypt という認証局を使うと、SSL 証明書を無料で発行してもらえます（感謝！）。

/p/io4gs6h/img-001.png — 図: Let's Encrypt + Certbot による HTTPS 対応

レンタルサーバー側で提供されている WordPress 環境などを使用している人は、知らないうちに Let’s Encrypt を使った HTTPS 化の恩恵を受けているかもしれません。ここでは、VPS などで自力で Web サーバーを立ち上げている人が、HTTPS (SSL) 対応する方法を説明します。

Let’s Encrypt からの SSL 証明書の発行には、Certbot というツールを使うのが一般的です。 Certbot による証明書取得や、Web サーバー (nginx) のヴァーチャルホスト設定をまとめて行ってしまう Docker イメージなども存在しますが、ここでは、Certbot の基本的な振る舞いを理解するために、certbot コマンドを直接実行する前提で説明していきます。

Certbot とは

Certbot は、Let’s Encrypt 認証局から SSL 証明書を発行してもらうためのクライアントツールで、以下のような作業を自動で行ってくれます。

Web サーバー用の公開鍵ファイル（CA に送られる）と秘密鍵ファイルの生成
Let’s Encrypt という認証局で SSL 証明書（CRT ファイル）を発行
自動生成した秘密鍵ファイルや、発行された SSL 証明書を Web サーバー（nginx や Apache）に設定

認証局となる Let’s Encrypt は、無料で SSL 証明書を発行してくれれます。つまり、Certbot を使えば、Web サーバーの HTTPS 対応を無料で簡単に行うことができます。証明書の取得までを Certbot で行い、Web サーバーの設定は別の仕組み（手動など）で行う、という使い方も一般的です。

事前準備（HTTP でのアクセス確認）

Certbot は、基本的に HTTPS (SSL) 対応したい Web サーバー上で実行する必要があり、その Web サーバーがすでに HTTP でアクセスできる状態になっている必要があります。また、Let’s Encrypt によって発行される SSL 証明書は、ドメイン検証 (Domain Validation; DV) 型の証明書であり、Web サーバーにドメイン名でアクセスできるようになっている必要があります。

例えば、example.com というドメインで運用する Web サーバーを HTTPS 対応する場合は、次のような前提条件を満たしておく必要があります（DDNS サービスなどを使えば、必ずしも固定の IP アドレスは必要なかったりしますが、ここではより一般的なグローバル IP アドレスの使用を前提とします）。

前提条件:

Web サーバーにグローバル IP アドレスが割り当てられていること
- 参考: 固定アドレスを使える VPS → ConoHa VPS / お名前.com VPS / さくら VPS
独自ドメインを取得済みであること
- 参考: 独自ドメインの取得 → お名前.com / バリュードメイン
DNS の A レコードで、ドメイン名から IP アドレスを正引きできるよう設定されていること
http://example.com/ といったアドレス（80 番ポート）で Web サーバーにアクセスできること

Let’s Debug というサイトに対象のドメイン名を入力すると、証明書発行の準備ができているかを確認することができます。あるいは、対象のホスト上で次のようにコマンド実行して確認するのでも OK です。

$ curl ifconfig.me     # 自ホストのグローバル IP アドレスを確認
$ dig example.com      # 独自ドメイン (example.com) の正引き結果が上記と同じか確認
$ curl -I example.com  # Web サーバーに HTTP アクセスできるか確認 (HTTP/1.1 200 OK)

ここでは、Web サーバーが立ち上げられていることまで前提条件に含めましたが、後述の Certbot の standalone モードを使用すれば、Certbot 内部で起動する Web サーバーを利用して証明書の発行だけを行うことができます。

certbot コマンドのインストール

certbot コマンドのインストールは、Certbot Instructions に従って進めれば OK です。ほとんどの Linux 系ディストリビューションでは、snap でインストールできます（snap はディストリビューションに依存しないパッケージ管理ツールです）。

certbot コマンドのインストール

$ sudo snap install --classic certbot

次のように実行できればインストールはできています。

$ certbot --version
certbot 1.32.0

Let’s Encrypt のステージング環境について

Let’s Encrypt による SSL 証明書の発行処理にはさまざまなレート制限が設けられており、例えば、Web サーバーの準備ができていない状態で証明書のリクエストを繰り返していると、すぐにリクエストが拒否されるようになってしまいます。 Web サーバーの接続検証は 1 時間に 5 回までしか実行できません（参考: Failed Validation Limit）。また、同一ホスト用の証明書発行は、1 週間に 5 回までに制限されています（参考: Duplicate Certificate Limit）。

リクエスト上限に達したときのエラー

too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

Let’s Encrypt が用意してくれている ステージング環境 を使用すると、このレート制限が緩和されるので、Web サーバーの接続テストはステージング環境を使用することが推奨されています（1 時間あたりの接続検証回数が 60 回に緩和されています）。 certbot コマンドを使用する場合は、--test-cert オプションを指定することで、ステージング環境による検証（証明書の取得テスト）を行うことができます。

Certbot のプラグイン

certbot コマンドは、実行時にプラグインを指定するようになっており、環境や用途によって使い分けます。大きく分けて 2 種類のプラグインがあり、SSL 証明書取得だけを行うプラグイン (standalone, webroot) と、SSL 証明書取得に加えて Web サーバーへの設定まで行うプラグイン (nginx, apache) があります。後者は、特定の Web サーバー用に作り込まれたプラグインです。どのプラグインを使用するかは、certbot コマンド実行時にオプションで指定します。

--standalone: Certbot 内部で接続確認用の Web サーバー（80 番ポート）を立ち上げ、証明書の取得を行います。コマンドライン引数でドメイン名（-d オプション）を指定するだけで、そのドメイン用の証明書を取得できます。一番シンプルな仕組みですが、実行時に内部的な Web サーバーを立ち上げるため、運用中の Web サーバー（80 番ポート）を停止してから実行しなければいけません。
--webroot: 証明書の取得時に、既存の Web サーバーの webroot ディレクトリを、接続テスト用のファイル置き場として使用するプラグインです。 Let’s Encrypt はサーバーの存在確認のために、Web サーバーの http://<DOMAIN>/.well-known/acme-challenge/xxxx というパスにアクセスしてきます。 webroot プラグインでは、-w オプションで指定したディレクトリ (webroot) に .well-known/ ディレクトリを自動生成することで、このチャレンジリクエストに対応します。
--nginx: 証明書の取得時に、既存の nginx サーバーの webroot ディレクトリを、接続テスト用のファイル置き場として使用するプラグインです。このプラグインでは、nginx の設定ファイル (.conf) を自動で書き換えて、証明書や秘密鍵ファイルの設定 (ssl_certificate, ssl_certificate_key) まで行ってくれます。
--apache: 証明書の取得時に、既存の Apache サーバーの webroot ディレクトリを、接続テスト用のファイル置き場として使用するプラグインです。このプラグインでは、Apache の設定ファイル (.conf) を自動で書き換えて、証明書や秘密鍵ファイルの設定 (SSLCertificateFile, SSLCertificateKeyFile) まで行ってくれます。

表にまとめると次のような感じでしょうか。

	秘密鍵の生成	証明書の取得	Web サーバーの webroot を利用	Web サーバーの設定を書き換え
`standalone`	✅	✅	─	─
`webroot`	✅	✅	✅	─
`nginx`	✅	✅	✅	✅
`apache`	✅	✅	✅	✅

standalone プラグインは、もっともシンプルに証明書を取得できますが、本番環境用の Web サーバーを停止して実行しなければいけないので、実運用では使いにくいでしょう。 webroot プラグインは、特定の Web サーバー実装に依存しないので汎用的ですが、秘密鍵や証明書の情報を Web サーバーの設定ファイルに自力で設定する必要があります。 nginx や apache などの各種 Web サーバー用のプラグインを使用すると、Web サーバーの設定まで自動で行ってくれますが、何が自動的に設定されるのかをちゃんと把握した上で使用する必要があります。

証明書の発行（standalone プラグイン）

まずは、standalone プラグインで、秘密鍵の作成と、証明書の発行のみを行ってみます。 certbot コマンドが内部的な Web サーバーを立ち上げるので、既存の Web サーバー（80 番ポート）が稼働している場合は、先に停止してください。 certbot コマンドは、下記のようなディレクトリにアクセスするため、sudo を付けて root 権限で実行する必要があります。

/etc/letsencrypt/ … 生成した秘密鍵、取得した証明書、ドメインごとの certbot コマンド設定など
/var/lib/letsencrypt/ … バックアップなど
/var/log/letsencrypt/ … ログファイルなど

standalone プラグインで証明書を発行するには、次のように certbot certonly --standalone コマンドを使用します。ここでは、Let’s Encrypt のステージング環境を利用するため、--test-cert オプションを付けていますが、本番環境用の証明書を発行する場合は、このオプションを外してください（これで取得した証明書を使うと、Web ブラウザでアクセスしたときに ERR_CERT_AUTHORITY_INVALID といったエラーになります）。

standalone モードで example.com 用の証明書を発行

$ sudo certbot certonly --standalone -d example.com --test-cert

出力例

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Requesting a certificate for example.com
Performing the following challenges:
http-01 challenge for example.com
Waiting for verification...
Cleaning up challenges

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-03-04.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

実行に成功すると、/etc/letsencrypt/live/<DOMAIN>/ ディレクトリ以下に各種キーファイルや証明書が格納されます。この下のファイル群は、実際にはシンボリックリンクですが、通常はこの下のファイルを Web サーバーに設定すれば大丈夫です。

cert.pem … SSL 証明書
chain.pem … 中間 CA 証明書
fullchain.pem … SSL 証明書＋中間 CA 証明書（cert.pem と chain.pem をマージしたもの）
privkey.pem … 秘密鍵 (private key)

Web サーバーによって使用するファイルが異なりますが、最近の Web サーバーでは、fullchain.pem と privkey.pem の 2 つを使用します。

証明書の発行 (webroot プラグイン）

webroot プラグインで証明書を発行する場合は、既存の Web サーバーの webroot 領域を間借りして .well-known/acme-challenge/xxxx ファイルを配置することで、Let’s Encrypt からの接続テストに対応します。何らかの Web サーバーが必要なので、ここでは Docker で nginx サーバーを起動しておくことにします。

/home/maku/docker-compose.yml

version: "3"
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./public:/usr/share/nginx/html

nginx サーバーを起動しておく

$ cd /home/maku
$ mkdir public
$ docker compose up -d

上記のように nginx を起動すると、ホスト上では /home/maku/public/ ディレクトリが webroot となります。 Certbot の webroot プラグインで証明書を取得するには、certbot certonly --webroot コマンドを使用します。このとき、webroot ディレクトリを -w オプションで指定します。

webroot モードで example.com 用の証明書を発行

$ sudo certbot certonly --webroot -w /home/maku/public -d example.com --test-cert

出力例

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-03-04.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

standalone プラグインのときと同様ですが、うまくいくと、次のようなファイルが生成されるので、これを nginx サーバーの設定ファイルなどに設定することになります。

/etc/letsencrypt/live/example.com/fullchain.pem （証明書）
/etc/letsencrypt/live/example.com/privkey.pem （秘密鍵）

nginx サーバーに証明書を設定する

秘密鍵の生成と SSL 証明書の発行に成功したら、あとは nginx サーバーなどの設定ファイルでそれらのファイルパスを指定することで、HTTPS (SSL) 対応が完了します。ここでは、Docker で nginx サーバーを立ち上げて確認してみます。

~/public/index.html（サンプル HTML）

<html>Hello</html>

docker-compose.yml ファイルの変更点は、SSL ポート 443 を公開しているところと、サーバーの設定ファイルと証明書ファイル用のディレクトリをマウントしている部分です。

~/docker-compose.yml

version: "3"
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./public:/usr/share/nginx/html
      - ./conf.d:/etc/nginx/conf.d:ro
      - /etc/letsencrypt:/etc/letsencrypt:ro

☝️ バインドマウントの起点に注意

証明書のディレクトリとして、/etc/letsencrypt/live 以下をマウントしたくなりますが、このディレクトリにはシンボリックリンクしか含まれていないので、実体となるファイルも含めるように /etc/letsencrypt ディレクトリごとマウントしなければいけません。 live ディレクトリ以下だけをマウントすると、Docker で nginx サーバーを起動しようとしたときに、次のようにファイルを見つけられないエラーが発生します。

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": BIO_new_file() failed

nginx の設定ファイルでは、証明書ファイルと、秘密鍵ファイルのパスを設定します。

~/conf.d/example.com.conf

server {
    server_name example.com;
    listen 80;       # IPv4
    listen [::]:80;  # IPv6

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    server_name example.com;
    listen 443 ssl http2;       # IPv4
    listen [::]:443 ssl http2;  # IPv6

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        root  /usr/share/nginx/html;
        index index.html;
    }
}

これで、Web サーバーの HTTPS 対応は完了です。次のように、Web ブラウザから https:// でアクセスできるようになっていれば成功です。

できたー ٩(๑❛ᴗ❛๑)۶ わーぃ

Let's Encrypt Certbot

Let's Encrypt 関連記事
へ戻る

🏠 技術系ネットワーク gRPC / Protocol Buffers

Protocol Buffers の .proto ファイルから API ドキュメントを自動生成する (protoc-gen-doc)

gRPC Protocol Buffers

更新: 2022-11-29
作成: 2022-11-29

protoc-gen-doc とは？

David Muto 氏が公開している protoc-gen-doc という protoc コマンドのプラグインを使用すると、.proto ファイルから、HTML 形式や Markdown 形式のドキュメントを自動生成することができます。複数の .proto ファイルの内容をまとめて 1 つのページとして出力してくれるので、シンプルで見通しのよいドキュメントになります。

生成されたドキュメントの例: HTML 形式 / Markdown 形式 / JSON 形式

protoc-gen-doc は protoc コマンドのプラグインとして動作するのですが、実行環境が Docker イメージとして提供されているので、docker コマンド一発で、簡単に .proto ファイルからドキュメントを生成できます。もちろん、protoc コマンドと protoc-gen-doc を両方インストールして実行することもできますが、Docker を使った方が断然お手軽です。

Protocol Buffers Compiler（protoc コマンド）に関しては、こちらを参考にしてください。

.proto ファイルからのドキュメント生成

protoc-gen-doc コマンドの基本

protoc-gen-doc の Docker イメージを使って、.proto ファイルからドキュメントを生成してみます。 Docker の実行環境は、Docker Desktop などでインストールしてください。 .proto ファイルが手元になければ、とりあえず下記のファイルをダウンロードして試せます。

Vehicle.proto（サンプル .proto ファイル）

proto/Vehicle.proto のように、proto ディレクトリに格納すれば準備完了です。あとは次のように実行すると、docs ディレクトリに index.html ファイルが生成されます。

HTML 形式のドキュメント (docs/index.html) を生成

$ docker container run --rm \
    -v $(pwd)/docs:/out \
    -v $(pwd)/proto:/protos \
    pseudomuto/protoc-gen-doc --doc_opt=html,index.html

protoc-gen-doc は、デフォルトでコンテナ内の /protos ディレクトリにある .proto ファイルを読み込んで、コンテナ内の /out ディレクトリに出力しようとします。なので、docker container run コマンドに指定しているマウントオプション (-v) は、次のような意味になります。

-v $(pwd)/docs:/out … ローカルの docs ディレクトリを出力先にする
-v $(pwd)/proto:/protos … ローカルの proto ディレクトリ内の *.proto を読み込む

出力形式を変えたい場合などは、--doc_opt オプションを変更します。

`--doc_opt` オプションの例	説明
`--doc_opt=markdown,api.md`	出力形式を Markdown (`.md`) にする
`--doc_opt=:google/,somepath/`	対象外にする `.proto` 指定する（`:` の後ろに記述）

.proto ファイルが深い階層にあるとき

protoc-gen-doc はデフォルトで、Docker コンテナ内の /protos/*.proto というパスで検索されるファイルを入力ファイルとして扱います。これ以外のパスに配置される .proto ファイルを扱いたいときは、ちょっと工夫が必要です。例えば、次のようなケースです。

深い階層にある .proto ファイルを入力ファイルとして使いたい
複数の階層に .proto ファイルが配置されている
特定のディレクトリの .proto ファイルは無視したい

このようなケースでは、基本的に次のように末尾に .proto ファイルを列挙することになります。

$ docker container run --rm ...(省略)... dir1/foo.proto dir2/bar.proto

これらのパスは、proto のルートディレクトリからの相対パスで指定するのですが、Docker コンテナ側の /protos からの相対パス を指定すれば OK です（暗黙的に --proto_path=/protos が指定されたものとして扱われるからです）。例えば、マウントオプションで-v $(pwd)/proto:protos と指定しているなら、$(pwd)/proto ディレクトリからの相対パスで指定します。ファイル数が多いと、OS の glob パターン（ワイルドカード）を使用したくなりますが、パターンがコンテナ側で処理されないので使えません。公式サイトにも、このことが注意事項として記述されています。

Remember: Paths should be from within the container, not the host!

NOTE: Due to the way wildcard expansion works with docker you cannot use a wildcard path (e.g. protos/.proto) in the file list. To get around this, if no files are passed, the container will generate docs for protos/.proto, which can be changed by mounting different volumes.

なかなか厳しい制約ですね。この問題に対処するには、例えば、次のようにシェルスクリプトで入力対象としたい .proto ファイルを列挙してしまうのが手っ取り早いです。

#!/bin/bash

# このスクリプトが置かれているディレクトリ（絶対パス）
SELF_DIR=$(cd $(dirname $0); pwd)

# .proto ファイルのルートディレクトリ（絶対パス）
PROTO_DIR=$SELF_DIR/proto

# 出力先ディレクトリ（絶対パス）
OUT_DIR=$SELF_DIR/docs

# 入力対象の .proto ファイルを列挙する（PROTO_DIR からの相対パス）
PROTO_FILES=$(find $PROTO_DIR -name '*.proto' -printf '%P ')

# ドキュメントを生成する
docker run --rm -v $PROTO_DIR:/protos -v $OUT_DIR:/out \
    pseudomuto/protoc-gen-doc --doc_opt=html,index.html $PROTO_FILES

入力する .proto ファイルをもっと細かく制御したいとき（特定のディレクトリを対象外とするなど）は、find コマンド部分を調整してやれば OK です。

参考: ファイルやディレクトリを検索する (find, grep) - まくまく Linux/Shell ノート

（おまけ）GitHub Actions で API ドキュメントを自動生成する

GitHub で .proto ファイルを管理している場合は、GitHub Actions でドキュメントを自動生成するように設定しておくと便利です。ワークフローの中で、protoc-gen-doc を呼び出して Markdown ファイルを自動生成し、GitHub wiki か GitHub pages にデプロイするようにしておけば、開発メンバーがいつでも最新の API ドキュメントを参照できるようになります。

例えば、メインリポジトリの tools ディレクトリなどに次のようなスクリプトを配置しておいて、

tools/gendoc.sh

#!/bin/bash

# 第 1 引数で出力先ディレクトリ名を指定（デフォルトはカレントディレクトリ）
out_dir=$1

# API ドキュメントを生成
docker run --rm -v $(pwd)/$out_dir:/out -v $(pwd)/proto:/protos pseudomuto/protoc-gen-doc --doc_opt=markdown,docs.md

GitHub Actions のワークフローの中で次のような感じで呼び出してやれば OK です。 GitHub Actions の Ubuntu イメージは標準で docker コマンドを実行できるようになっているので、protoc-gen-doc のように Docker イメージが提供されているコマンドはとても簡単に呼び出せます。

.github/workflows/gendoc.yml（抜粋）

- name: Generate API documents
  run: ./tools/gendoc.sh .wiki

上記のように API ドキュメントの生成コマンドをシェルスクリプト化しておけば、ローカルでの開発中も簡単にドキュメント生成できます。

開発中はこうやってドキュメント生成結果を確認

$ ./tools/gendoc.sh

gRPC Protocol Buffers

gRPC / Protocol Buffers 関連メモ
へ戻る

🏠 技術系 Nginx（Web サーバー）

Nginx の設定: Nginx の設定内容を確認する (nginx -T)

nginx

更新: 2022-11-27
作成: 2022-11-27

nginx サーバーが読み込む設定情報を確認するには、nginx -T コマンドを使用します。正確には、このコマンドは設定ファイルの検証 (nginx -t) と、内容の出力を同時に行うコマンドです。

下記は、nginx -T コマンドを実行したときの出力例です。最初の 2 行が設定ファイルの検証結果で、3 行目以降が具体的な設定内容です。

nginx -T コマンドの出力例

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

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
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"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

# configuration file /etc/nginx/mime.types:

types {
    text/html                                        html htm shtml;
    text/css                                         css;
    text/xml                                         xml;
    image/gif                                        gif;
    image/jpeg                                       jpeg jpg;
    application/javascript                           js;
    application/atom+xml                             atom;
    application/rss+xml                              rss;

    text/mathml                                      mml;
    text/plain                                       txt;
    text/vnd.sun.j2me.app-descriptor                 jad;
    text/vnd.wap.wml                                 wml;
    text/x-component                                 htc;

    image/avif                                       avif;
    image/png                                        png;
    image/svg+xml                                    svg svgz;
    image/tiff                                       tif tiff;
    image/vnd.wap.wbmp                               wbmp;
    image/webp                                       webp;
    image/x-icon                                     ico;
    image/x-jng                                      jng;
    image/x-ms-bmp                                   bmp;

    font/woff                                        woff;
    font/woff2                                       woff2;

    application/java-archive                         jar war ear;
    application/json                                 json;
    application/mac-binhex40                         hqx;
    application/msword                               doc;
    application/pdf                                  pdf;
    application/postscript                           ps eps ai;
    application/rtf                                  rtf;
    application/vnd.apple.mpegurl                    m3u8;
    application/vnd.google-earth.kml+xml             kml;
    application/vnd.google-earth.kmz                 kmz;
    application/vnd.ms-excel                         xls;
    application/vnd.ms-fontobject                    eot;
    application/vnd.ms-powerpoint                    ppt;
    application/vnd.oasis.opendocument.graphics      odg;
    application/vnd.oasis.opendocument.presentation  odp;
    application/vnd.oasis.opendocument.spreadsheet   ods;
    application/vnd.oasis.opendocument.text          odt;
    application/vnd.openxmlformats-officedocument.presentationml.presentation
                                                     pptx;
    application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
                                                     xlsx;
    application/vnd.openxmlformats-officedocument.wordprocessingml.document
                                                     docx;
    application/vnd.wap.wmlc                         wmlc;
    application/wasm                                 wasm;
    application/x-7z-compressed                      7z;
    application/x-cocoa                              cco;
    application/x-java-archive-diff                  jardiff;
    application/x-java-jnlp-file                     jnlp;
    application/x-makeself                           run;
    application/x-perl                               pl pm;
    application/x-pilot                              prc pdb;
    application/x-rar-compressed                     rar;
    application/x-redhat-package-manager             rpm;
    application/x-sea                                sea;
    application/x-shockwave-flash                    swf;
    application/x-stuffit                            sit;
    application/x-tcl                                tcl tk;
    application/x-x509-ca-cert                       der pem crt;
    application/x-xpinstall                          xpi;
    application/xhtml+xml                            xhtml;
    application/xspf+xml                             xspf;
    application/zip                                  zip;

    application/octet-stream                         bin exe dll;
    application/octet-stream                         deb;
    application/octet-stream                         dmg;
    application/octet-stream                         iso img;
    application/octet-stream                         msi msp msm;

    audio/midi                                       mid midi kar;
    audio/mpeg                                       mp3;
    audio/ogg                                        ogg;
    audio/x-m4a                                      m4a;
    audio/x-realaudio                                ra;

    video/3gpp                                       3gpp 3gp;
    video/mp2t                                       ts;
    video/mp4                                        mp4;
    video/mpeg                                       mpeg mpg;
    video/quicktime                                  mov;
    video/webm                                       webm;
    video/x-flv                                      flv;
    video/x-m4v                                      m4v;
    video/x-mng                                      mng;
    video/x-ms-asf                                   asx asf;
    video/x-ms-wmv                                   wmv;
    video/x-msvideo                                  avi;
}

# configuration file /etc/nginx/conf.d/default.conf:
server {
    listen       80;
    server_name  localhost;

    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

Docker がインストールされている環境では、上記の出力は次のような感じで確認できます。

nginx:alpine コンテナで nginx -T を実行する

$ docker container run --rm nginx:alpine sh -c "nginx -T"

nginx

Nginx（Web サーバー）のメモ
へ戻る

メニュー

技術系

読書

日記・コラム

ツール

遊び

設定

雑多

管理人