前回の記事では、docker-composeで使う.envファイルの基本的な書き方や役割について解説しました。
今回はその続きとして、.envファイルを応用し、開発環境と本番環境を切り替えるための構成方法を、より実践的な視点でわかりやすくご紹介していきます。
Contents
なぜ環境ごとに設定を分ける必要があるのか？
開発環境と本番環境では、設定内容が大きく異なることがよくあります。
- 使用するポート番号（例：開発は3000、本番は80）
- APIキーやデータベースの接続先
- デバッグやログの出力設定
これらをひとつの設定ファイルでまとめてしまうと、本番にテスト用の設定を誤って使ってしまうなどの事故につながる可能性があります。環境ごとに設定をしっかり分けておくことが、安全で効率的な運用につながります。
.envファイルの使い方
開発と本番で別々の.envファイルを用意して、それぞれに必要な値を記述しておきます。
.env.dev（開発環境用）
|
1 2 3 |
APP_ENV=development APP_PORT=3000 DEBUG=true |
.env.prod（本番環境用）
|
1 2 3 |
APP_ENV=production APP_PORT=80 DEBUG=false |
そして、docker-compose.ymlファイルでは、変数名を共通に保ったまま読み込めるようにしておきます
|
1 2 3 4 5 6 7 |
services: app: image: myapp environment: - NODE_ENV=${APP_ENV} ports: - "${APP_PORT}:3000" |
docker-composeで環境を切り替えて起動する
--env-fileオプションを使えば、環境ごとに異なる.envファイルを指定してdocker-composeを起動することができます。
開発環境で起動する場合
開発中は、デバッグモードを有効にしたり、ローカルポート（たとえば3000番など）を使いたいケースが多くあります。そんなときは、開発用の.env.devファイルを指定します。
|
1 |
$ docker-compose --env-file .env.dev up -d |
本番環境で起動する場合
本番サーバーでは、ポート番号を80番にしたり、DEBUG=falseに設定するなど、本番向けの値を使いたいことが多いです。その場合は、.env.prodファイルを指定します。
|
1 |
$ docker-compose --env-file .env.prod up -d |
このように、docker-compose.ymlの中身は共通のままにしておき、.envファイルだけを切り替えることで、開発環境と本番環境を簡単に使い分けることができます。
docker-compose.override.ymlとの併用
開発環境では、本番とは異なる追加設定を行いたい場面が多くあります。たとえば、ソースコードのホストマウントや、ログ出力の詳細化などです。
そういった用途で便利なのが、docker-compose.override.ymlの仕組みです。
このファイルは、docker-compose.ymlと同じ階層に置いておくだけで、docker-compose upを実行した際に自動的に読み込まれてマージされます。
つまり、開発専用の設定をoverride.ymlに切り分けておくことで、docker-compose.ymlは本番環境向けの内容として保ったまま運用できます。
ただし、この自動読み込みは本番環境でも同じように働くため、本番でoverride.ymlを適用したくない場合は、明示的にdocker-compose.ymlのみを指定して起動するようにしましょう。
例：本番環境で override を除外して起動する
|
1 |
$ docker-compose -f docker-compose.yml --env-file .env.prod up -d |
安全に運用するためのコツ
- 開発用と本番用の.envファイルを明確に分ける
たとえば.env.dev（開発用）と.env.prod（本番用）など、名前で用途がすぐにわかるようにしておくとミスが起きにくくなります。 - 本番環境では–env-fileオプションを明示的に指定する
docker-compose.override.ymlのような自動読み込みファイルがある場合、-f docker-compose.ymlを指定して余計なファイルを読み込まないようにしましょう。 - 本番用.envファイルは必ず除外管理（gitignore）
パスワードや秘密鍵など、本番固有の情報を誤ってGitに上げないよう、.gitignoreに記載しておくことが重要です。 - 変数名の構造は統一し、値だけ変える
APP_PORTやDEBUGなど、同じ名前で値を切り替えることで、docker-compose.yml側を1つに保つことができます。 - 例として使える.envテンプレートを残しておく
.env.exampleを作っておけば、新しい開発者や他環境でもスムーズにセットアップできます。
まとめ
.envファイルを環境ごとに分けておくことで、安全かつ柔軟に設定を管理できるようになります。--env-fileオプションを活用すれば、共通のdocker-compose.ymlを使いながら、設定だけを切り替えることが可能です。docker-compose.override.ymlを併用すれば、開発専用の設定を分離して運用することができます。
ここまで、docker-composeと.envファイルを使って、開発環境と本番環境を柔軟に切り替える方法をご紹介してきました。
次のステップでは、GitHub Actionsを使った自動デプロイなど、CI/CDの活用に進んでいきたいところです。
…ですがその前に、少し立ち止まって、「GitHubってそもそも何だろう？」という基本に立ち返ってみましょう。
リポジトリ、ブランチ、プルリクエストなど、GitHubの仕組みをきちんと理解しておくことで、このあとのステップもぐっとスムーズになります。
ということで、次回は 「GitHubとは？リポジトリ・ブランチ・プルリクの基本をやさしく解説」 をお届けします！
新着情報
ブログランキングに参加しています。クリックして応援していただけると嬉しいです。
