私は頭をDockerに巻き付けようとしていますが、それを理解するのに苦労しています。私は小さなプロジェクト(MERNスタック)でそれを実装しようとしましたが、開発環境(おそらくステージング環境)と実稼働環境をどのように区別するかを考えていました。
1つの 例 2つのDockerファイルと2つのdocker-composeファイルを使用しました(それぞれ1つのenvのペアです。 -dev.yml for dev)。
しかし、これは私にとってはちょっとやり過ぎのように思えます。私は2つのファイルのみでそれを持ちたいと思います。
また、問題の1つは、開発のために、nodemonをグローバルにインストールしますが、poductionにはインストールしません。
完全なソリューションでは、そのような何かを実行することを想像します
docker-compose -e ENV=dev build
docker-compose -e ENV=dev up
私はまだdockerを完全に取得していないことに注意してください。したがって、dockerについての私の誤解を見つけた場合は、それらを指摘できます。
「 プロダクションで構成を使用 」からいくつかの手がかりを得ることができます
ほぼ確実に、実際の環境により適したアプリの構成を変更する必要があります。これらの変更には以下が含まれます。
- アプリケーションコードのボリュームバインディングを削除して、コードがコンテナー内に残り、外部から変更できないようにする
- ホスト上の異なるポートへのバインド
- 環境変数を異なる方法で設定する(例:ロギングの詳細度を下げる、またはメール送信を有効にする)
- ダウンタイムを回避するための再起動ポリシー(再起動:常に)の指定
- 追加のサービス(ログアグリゲーターなど)の追加
このアドバイスは、あなたが言及した例とはまったく似ていません。
このため、おそらく追加の構成ファイル、たとえば
production.yml
は、実稼働に適した構成を指定します。この構成ファイルに含める必要があるのは、元の構成ファイルから行う変更のみです。docker-compose -f docker-compose.yml -f production.yml up -d
このオーバーライドメカニズムは、1つの構成ファイルにdevロジックとprodロジックを混在させ、環境変数を選択して試すよりも優れています1。
注:2番目のdockerfileにdocker-compose.override.yml
、 シンプルな docker-compose up
は、オーバーライドを自動的に読み取ります。
しかし、あなたの場合、環境に基づいた名前はより明確です。
Docker Composeは、デフォルトでdocker-compose.yml
およびdocker-compose.override.yml
を読み取ります。 nderstanding-Multiple-Compose-Files
デフォルトのdocker-compose.yml
と異なる上書き作成ファイルを設定できます。たとえば、docker-compose.prod.yml
docker-compose.test.yml
などです。それらを同じ場所に保管してください。
次に、各envに対してdocker-compose.override.yml
という名前のシンボリックリンクを作成します。docker-compose.{env}.yml
ファイルを追跡し、docker-compose.override.yml
を.gitignore
に追加します。
製品環境:ln -s ./docker-compose.prod.yml ./docker-compose.override.yml
テスト環境:ln -s ./docker-compose.test.yml ./docker-compose.override.yml
プロジェクト構造は次のようになります。
project\
- docker-compose.yml # tracked
- docker-compose.prod.yml # tracked
- docker-compose.test.yml # tracked
- docker-compose.override.yml # ignored
#linked to override composefile for current env
- src/
- ...
その後、完了しました。各環境で、同じコマンドdocker-compose up
でcompose-fileを使用できます
不明な場合は、docker-compose config
を使用して、適切にオーバーライドされているかどうかを確認してください。