https-portalを使ってみて、個人的にぶつかりそうな壁の解決方法

とても参考になったもの

実際にやっていくと、「？、これ..どうすんだっけ」が何個かあったので

STAGEがlocal、staging(default)、productionとある...

1. localはドメインも持っていないが、とりあえず一連の流れをやってみたい
2. stagingはドメインを持っていて、本番サーバーではないが、とりあえず一連の流れをやってみたい
3. productionはドメインを持っていて、本番サーバーで動かす場合

実際にlocalでやるには

hostsを書き換えて適当なドメイン名がローカルサーバーに行くように設定

hosts

192.168.1.100 domain.local # 実在しないのでも
192.168.1.100 qiita.com    # 実在するのでも

stagingでやるには

ドメインはあってもなくても良いけど、stagingなんで、実際のドメインでやるけどサーバーが本番サーバーじゃない的な
*お名前とかのレジストラで、ドメインのAレコードをテスト用のサーバーに向けるとか
*自分1人でテストするならlocalのようにhostsで強制しても構わない

local、stagingは警告が出るがhttps通信のオレオレ

productionでやってみた

let's encryptに証明書を取得して、実際にアクセス出来るまでに結構ラグがあった。
コーヒー一杯作る時間は待つと思う。

FORCE_RENEW=true

基本的にはlocalやstagingで実行するので通常は必要ない。どうしても証明書にキャッシュが効いてて挙動がおかしいとかそういうときだけに使う。
productionでは基本使わない。どうしてもおかしい場合は、一回だけtrueにしてdocker再起動させて、すぐにコメントアウトでもしておく。
そうじゃないとLet's Encryptにはrate limitがあるから最悪証明書が取れなくなる。

About Rate Limits of Let's Encrypt

For most people the most important rate limits are:

5 failed validation attempts per hour
50 certificates per registered domain per week
5 duplicated certificate per week (for renewal)

普通使いそうなオプション

色々サイトを回ってみたけど、余り触れられてない。
けど、有用なオプションが結構ある。

CLIENT_MAX_BODY_SIZE
nginxはアップロード量の制限がデフォルトで1MBなんで、まずい。

docker-compose.ymlの環境変数

environment:
#  CLIENT_MAX_BODY_SIZE: 0  # これだと無制限
  CLIENT_MAX_BODY_SIZE: 10M # とか

WEBSOCKET
websocketを使う時はこれを入れてないと動かない

docker-compose.ymlの環境変数

environment:
  WEBSOCKET: "true"

HSTS_MAX_AGE
HTTPで来ても、強制HTTPS

docker-compose.ymlの環境変数

environment:
  HSTS_MAX_AGE: 60 # 秒

いきなり1日分とかデカイ秒数設定すると、その時間HTTPには戻れないから注意してとある。

SSL Certificatesをdockerホスト上に保存

https-portal:
  # ...
  volumes:
    - /data/ssl_certs:/var/lib/https-portal

他のプログラムで同じ物を使う場合とからしいけど、こうしておけば多分コンテナを消しても再生成しなくてすむから、テスト中は時間短縮によさそう。

参考

ここの3ファイルは眺めておくと、挙動が分かりやすいと思う。