応用読了目安 15 分#設定#環境変数#環境分離#既定値#フィーチャーフラグ
設定の管理 — 環境ごとに違う値を、どこに置くか
検証環境のつもりで流したバッチが、本番の顧客にメールを送った。設定が欠けたとき、安全側に倒れるか危険側に倒れるかで結果が変わる。
この記事の進み方
What — 設定には性質の違う3つが混ざっている
「設定」と一括りにされるものは、扱い方が違う3種類に分かれます。
環境によって違うが、秘密ではない。向き先やモード。
APP_ENV=staging API_BASE_URL=https://stg.example.com LOG_LEVEL=debug MAIL_ENABLED=false
- 秘密か
- いいえ
- 変える頻度
- 環境構築時
- リポジトリに置けるか
- 置ける
- 間違えたときの害
- 大きい
- –秘密ではないので、リポジトリに入れて差分を追える。
- –冒頭の事故はここ。秘密ではないが、間違えると本番を叩く。
同じ .env に並んでいても、変える頻度も、漏れたときの被害も違う。混ぜると、どれかの扱いが間違う。
- 環境変数
- プロセスに渡される名前と値の組。多くの言語から同じ方法で読める。
- 既定値
- 設定が無いときに使われる値。何を既定にするかが安全性を左右する。
- 設定の検証
- 起動時に、必要な設定が揃っているか・形式が正しいかを確かめること。
- 環境の分離
- 検証と本番で、同じ資源を共用しないようにすること。
「設定が無い」ときに何が起きるかが要点
冒頭の事故の核心はここです。
| 欠けたときの挙動 | 結果 |
|---|---|
| 起動を止める | 動かないので、事故は起きない |
| 安全な既定値を使う（送らない） | 何も起きない。気づきにくいが害は無い |
| 危険な既定値を使う（送る） | 冒頭の事故 |
| 前の値が残る | 最悪。何が使われているか分からない |
設定が欠けたときに、安全側に倒れるか、危険側に倒れるか。 これが設計の中心です。
Why — 設定はコードの一部なのに、コードほど守られていない
コードはレビューされ、テストされ、履歴が残ります。設定はそのどれも受けないことが多い。
環境変数には、型も必須も無い
RETRY_MAX=3 数値のつもり
RETRY_MAX=three 文字列として通る
RETRY_MAX= 空文字。0 と解釈される? エラー?
（未設定） undefined
言語が文字列としてしか渡さないので、書き間違いがそのまま通ります。true と True と 1 の扱いも、読む側の実装次第です。
「同じ名前で違う値」は、取り違えを誘う
API_BASE_URL という名前は、検証も本番も同じです。中身だけが違う。
人が見て区別できるのは値だけで、値は長い URL です。目視では取り違えが起きます。
設定ファイルのコピーは、差分を作らない
cp で運用すると、片方だけ更新されたときに検出できません。
新しい設定が本番にだけ足され、検証環境には無い。その状態で検証すると、本番でしか起きない不具合が生まれます。
演習 — まず自分で判断する
確認 — ここまで読めたか
`MAIL_ENABLED` が未設定のとき、既定値をどうすべきですか?
確認 — ここまで読めたか
次のうち、リポジトリにコミットしてよいものはどれですか?
読み終わりましたか?
読了にすると、これを前提とする記事がロードマップで開放されます。