こう
- 「開発、
ステージング、 本番の 環境を どう 分けて 管理しますか」 - 「データベースの
パスワードや API キーは、 どこに 置きますか」 - 「ステージングでは
動いたのに、 本番で 動かない ことがありました。 なぜだと 思いますか」
面接官が
- 環境ごとに、
置き場、 データ、 鍵 (秘密の 値) を 分けているか - 秘密の
値を コードや リポジトリに 書かず、 秘密の 値を 預かる 仕組みに 置くと言えるか - 環境の
違いを 「設定だけ」に 絞り、 作りは 同じにしようとしているか - 手で
作った 環境は 再現できない、と 分かっていて、 IaC (設定を コードで 書いて 環境を 作る 方法) を 知っているか
短い答え
- 開発、
ステージング、 本番で、 クラウドの プロジェクトや アカウント、 データベース、 鍵を 分け、 ステージングで 壊しても 本番に 届かないようにします。 - 環境ごとの
違いは 環境変数と 設定ファイルだけにし、 パスワードや API キーのような 秘密の 値は、 コードに 書かず、 秘密の 値を 預かる 仕組み (AWS Secrets Manager や Google Cloud の Secret Manager など ) に 置きます。 - 環境
その ものは Terraform のような IaC で 書き、 同じ 手順で 作り直せるようにします。 手で 作った 違いが、 本番だけで 起きる 不具合のもとに なるからです。
少し
3 つの
- 開発手元や
開発用の クラウドで、 自由に 試して 壊して よい環境です - ステージング本番と
できるだけ 同じ 作りに して、 出す前の 最後の 確かめを する 環境です。 データは 本物ではなく、 試し用の 物を使います - 本番利用者が
使う 環境です。 触れる 人を 絞り、 変更は 決まった 手順 (CI/CD) を 通してだけ入れます
分ける物
環境ごとに、
- 置き場 クラウドの
プロジェクトや アカウントを 環境ごとに 分けると、 権限も 料金も 分かれ、 間違えて本番を 消す事故を防げます - データステージングに
本番の 個人情報を そのまま 写しません。 要る ときは、 名前や メールを 置き換えてから使います - 鍵環境ごとに
別の 鍵を 使い、 ステージングの 鍵が 漏れても 本番には 入れないようにします。 人や 仕組みに 渡す権限は、 要る 分だけにします (最小権限)
コードは
ターミナル
# .env.example (値の無い見本だけをリポジトリに置く)
DATABASE_URL=
PAYMENT_API_KEY=
APP_ENV=development本物の.env は .gitignore に
IaC で
管理画面を
トレードオフ
環境を
IaC も、
話すときは、
よく
- 秘密の
値を コードや 設定ファイルに 書いて リポジトリに載せる 履歴に 残るので、 あとで 消しても 見えてしまいます。 載せてしまったら、 その鍵を 作り直します - ステージングに
本番の 個人情報を そのまま写すステージングは 守りが 弱いことが 多く、 漏えいのもとになります - ステージングと
本番の 作りが違う ステージングで 確かめた 意味が 薄れます。 違いは 設定だけにします
深掘りの問い
- 「ステージングで
動いて本番で 動かないのは、 なぜですか」 環境変数の 値や 権限の 違い、 データの 量や 中身の 違い、 手で 入れた 設定の ずれ、を 疑う、と答えます - 「秘密の
値を 誤って リポジトリに 載せたら、 どうしますか」 まず その鍵を 無効に して 作り直し、 使われた 跡が 無いかを 記録で 確かめ、 それから 履歴から 消す、と答えます - 「誰が
本番に 入れるようにしますか」本番の 権限は 要る 人だけに 絞り、 ふだんの 変更は CI/CD を 通し、 手で 入る ときは 記録が 残るように する、と答えます