🧹.env にさよなら！全てのサービス開発者が実感するビルドプロセス改善🔐⏱️⚙️

はじめに こんにちは！株式会社ダイニーの Platform Team に所属しています。0tanyです。 モダンなモジュラーモノリスアーキテクチャでは、環境変数の管理が重要な課題の一つです。事業成長とともにサービス数と環境数が増加すると、その管理複雑性は指数関数的に増大していきます。 本記事では、この移行を通じて得られた知見を共有します。同様の課題を抱えるチームの参考になれば幸いです。 従来のアーキテクチャの問題点 環境別の.env ファイルと Docker イメージの管理地獄 上記が従来のアーキテクチャです。ダイニーでは飲食店向けのモバイルオーダーサービスを 4 つの環境（develop/staging/beta/production）で運用しており、それぞれの環境に対して 4 つのサービス（web、backend、backend-online-payment、backend-reser

[masatomo-m]

これ、そもそも前提からしておかしくて、イメージをbuildする時に.envファイルの中身に依存する構成にしたこと自体がダメでは。本番と検証で別の.envでビルドしたイメージを使ってたなら最初から設計がおかしいと思うぞ

[oooooo4150]

そもそもがおかしな設計だったから直しましたという記事ではある

[manaten]

環境ごとにビルド分けないほうがいいのはそのとおりだけど、あんまりそうだって発信されてる例も少ないので大事な気がする。あとフロントのビルドスタックはそのままだと環境変数バンドルしがち

[work996]

Build・Release・Run、大事やね。こうやってダメな構成を直しそれを発信してくれる全ての人に感謝したい。

[Makeneko]

環境が違っても同じコンテナイメージを使うようにしてるし、バッチも同じコンテナイメージで実行コマンドを上書きして使ってます

[yo_aibou]

方法論に関してはおま環のため千差万別だが、4つの設計原則は額縁に入れて飾っておきたい

[mole-studio]

確かに.env早く滅んでほしい

[prograti]

機密情報でないセッション時間みたいな普通の環境変数はどうやって管理するのかしら？そういったものも全部Secret Managerで管理？

[circled]

英語圏のカンファレンスの発表とか見てると「コンテナってさ？開発が大変だからデプロイも大変にしてやろう！みたいに気分で使われてると思うよね？」みたいなジョーク発言を時折見かける