今回はDocker-composeは使わず、SynologyのGUI上から設定した。
ちなみにDSMのdockerでは変数は下画像の右下のように左辺に変数名、右辺に値という形で入力できる。
設定についてだが、ポート設定は例えばこんな感じ。
| ローカルポート(ルーターからの転送ポート) | コンテナのポート(固定値) | タイプ(固定値) |
|---|---|---|
| 4443 | 443 | tcp |
| 880 | 80 | tcp |
ルーターからのポートをコンテナのポートに割り振る。
次にボリューム。Docker内(動作時はオンメモリ)の設定ファイルを物理フォルダに割り当てる。
htmlは宛先を指定しない場合のコンテンツフォルダ。certsはSSL証明の保管フォルダ。
| ファイル/フォルダ(Volume内に自分で作成) | マウントパス(固定値) | タイプ |
|---|---|---|
| docker/https-portal/html | /var/www/vhosts | rw |
| docker/https-portal/certs | /var/lib/https-portal | rw |
最後に環境変数の設定。最低限追記しなければいけないのはこの2つ。
ドメインはアクセス元、転送先を -> でつなぐ。アクセス元だけ記載すると上記ボリューム先にドメイン名でコンテンツフォルダができる。STAGEはSSL証明取得の扱い。productionを選ぶと本気で取りに行くのだが、新規取得は週に5つという制限があるため、引っかかると1週間待つ必要がある。
| DOMAINS | XXX. YYY. JP , OOO. PPP. JP -> https://192.168.0.10 |
|---|---|
| STAGE | "staging" or "local" or "production" |
今回はここで嵌った。例によって他のサイトを参考にしたのだが(ありがとうございます)、docker-composeの設定に「FORCE_RENEW: 'true'」のコメントアウトを外せと書いてあるサイトが散見される。
作法なのかと思って例に倣っていたのだが、当然、起動毎に強制的にSSL証明を更新するため週5件制限にあっという間に引っかかってしまった。(dockerなので当然設定を変えるために停止→起動する)
確信が得られるまではSTAGEをstagingもしくはlocalで運用すべきだし、強制的に更新する必要はほとんどないのでコメントアウトのままでいいと思う。
あと、個人的な問題ではあるが、ブログの更新などに時間がかかる場合にリバースプロキシがタイムアウトすることがあるのだが、そういう場合は以下の手順を実行。
症状
サーバーに対してNASのリバースプロキシを介して接続した際、"413 Request Entity Too Large"と出る。今回は、別サーバーのMovableTypeに大きめのファイルをアップロードした際に再現することが多い。

我が家の場合はWebサーバーがそもそもApacheなのでnginxのメッセージが出ることはあり得ないというのが切り分けの決め手。たぶんWebサーバー側もnginxだったら混乱していたかもしれない。
このメッセージの出どころはリバースプロキシに使っているDockerコンテナ"https-portal"の中のnginx。
webサーバーだとよくある問題で、一度のアップロードで受け付けるファイルサイズの上限が決められていて、アップローダーなどを設置すると大体この問題に引っかかる。
phpだと"upload_max_filesize"、"post_max_size"とかApacheだと"LimitRequestBody"とか。
解決法
nginxそのものであれば/nginx/default.confを編集するのだが、今回はDockerなので、https-portal Advanced Usageにあるようにenvironmentとして追記した。
environment:
STAGE: local
DOMAINS: 'localhost -> http://192.168.0.10'
CLIENT_MAX_BODY_SIZE: 100M
https-portalのコンテナを再起動して解決。
以下の変数をenvironmentに加えるだけ。
PROXY_CONNECT_TIMEOUT 60 (それぞれ60秒が標準なのでそれ以上に延ばす)
PROXY_SEND_TIMEOUT 60
PROXY_READ_TIMEOUT 60