Architecture Decision Record環境変数の設定
目次:
概要
課題
アプリケーションを、成果物/バイナリ/ソースの外部で設定可能にし、1 つのビルドがデプロイ環境に応じて異なる動作をするようにしたい。
これを実現するために、環境変数による設定を使用したい。
バージョン管理できるファイルを使用して設定を管理したい。
何を設定できるか、関連するデフォルト値は何かを知ることなど、開発者体験の人間工学を提供したい。
決定
関連するデフォルトファイルとスキーマファイルを伴う .env ファイルに決定しました。
状態
決定済み。新しい機能が登場した場合は、検討に対してオープンです。
詳細
前提
アプリケーションコードと環境コードの分離を支持します。開発環境、テスト環境、デモ環境、本番環境など、異なる環境でアプリが異なる動作をする必要があると想定しています。
「12 ファクターアプリ」、さらにそれに関連する「15 ファクターアプリ」という業界の実践を支持します。
私たちの過去の多くのプロジェクトでは、.env ファイル、または同様の .env ディレクトリという慣例を使用してきました。これらをバージョン管理の外に置き、代わりに他の方法でデプロイ、バージョン管理、管理するのが一般的な慣行です。
制約
シークレットを、ソースコード管理(SCM)のバージョン管理システム(VCS)の外に置きたい。
一般的なソフトウェアフレームワークやライブラリとの互換性を目指したい。たとえば、Node には環境変数設定を読み取るためのモジュール "dotenv" があります。
ポジション
いくつかのアプローチを検討しました:
config.jsファイルのように、設定をアプリ内に保存する。.envファイルのように、設定を環境内に保存する。ライセンスサーバーのような既知の場所から設定を取得する。
論拠
.env ファイルのアプローチを選択した理由は次のとおりです:
専門家の間でも人気がある。
私たちのチームが多くのプロジェクトで何度も成功裏に使用してきた
.envファイルのパターンに従っている。シンプルである。特に、ライセンスサーバーのアプローチと比べて監査機能が欠けているなど、私たちが認識している大きなトレードオフは、今のところ許容できます。
影響
公開されている環境変数の設定を、シークレット管理から分離する方法を考える必要があります。
関連
関連する決定
すべてのアプリケーションがこのアプローチを使用することを期待しています。
バイナリやソースコードへのハードコーディングなど、能力の低いアプローチを使用しているアプリケーションは、アップグレードを計画します。
ライセンスサーバーなど、より能力の高いアプローチを使用しているアプリケーションは、そのまま維持します。
関連する要件
フック、テスト、継続的インテグレーションを含む、ファイルのための devops 機能を追加します。
すべての開発者チームメイトにこの決定についてトレーニングする必要があります。
関連する成果物
デプロイする各領域には、それぞれ独自の .env ファイルと関連ファイルが必要になります。
関連する原則
容易に元に戻せる。
メモ
.env ファイルの例:
NAME=Alice Anderson
EMAIL=alice@example.com
.env.defaults ファイルの例:
NAME=Joe Doe
EMAIL=joe@example.com
キーのみの .env.schema ファイルの例:
NAME
EMAIL