プロジェクト名は重要ではありません。 私はランダムなプロジェクト名のアイデアが好きです。 さらに良い– fig.ymlへのパスのハッシュを生成してそれを使用できますか？

実際、プロジェクト名はかなり重要だと思います。 CIパイプライン内のイメージで何でもできるようにしたい場合は、プロジェクト名を知って、それらを別のものとして再タグ付けできるようにする必要があります。

環境変数からプロジェクト名をオーバーライドできるため、これらを一意で予測可能に保つことが容易になります。 何が起こっても、環境変数からのオーバーライドをサポートする必要があると思います。

プロジェクト名をファイルから構成できるようにするというアイデアが好きです。 （＃45）でも同様の議論があったと思います。 .fig/project-nameプロジェクト名があると、非常に小さなファイルがたくさん発生するようです。 fig.yml自体に入れる方が簡単だと思います（＃45で提案されているように、Dockerの1つが提案を作成します）。

別のディレクトリとファイルに配置することの利点は何ですか？

別のファイルに入れる理由はいくつかあります。その背後にある私の考えを説明しようと思います。

• プロジェクトの_開始_に使用された名前（つまり、 --project-name=foobar ）を保持するため。これは、自動プロジェクト名とは異なる場合があります。
• プロジェクトの複数のインスタンスまたは_バージョン_を同じサーバー上で実行し、それらが互いに競合しないようにする
• または、要するに、 .fig/project-nameはプロジェクトの_そのインスタンス_の名前を保持します。

おそらく、ファイルはinstance-nameまたは同様のものと呼ばれるべきです。

プロジェクト名をファイルから構成可能にするというアイデアが好きです

この提案でこれを行うことは_可能_ですが（ project-nameファイルを手動で作成することにより）、私の主な使用例は、使用された名前を保存するために_fig_にファイルを作成させることでした。

非常に小さなファイルがたくさん発生します。

確かに、別の方法は.figディレクトリをスキップすることですが、将来追加のものが必要になった場合は、プロジェクトのルートを乱雑にすることなく追加のファイルを追加できます。 Gitも同様で、クリーンなアプローチだと思います。

fig.ymlに入れるほうが簡単だと思います

どちらのオプションも補完できると思います。 名前がフラグまたは環境変数によってオーバーライドされない場合は、デフォルトとしてfig.ymlの名前を使用します。 プロジェクトを_開始_するために実際に使用される名前を.fig/project-name

環境変数からプロジェクト名をオーバーライドできるため、これらを一意で予測可能に保つことが容易になります。 何が起こっても、環境変数からのオーバーライドをサポートする必要があると思います。

奇妙な; 複数のプロジェクトの管理をどのように処理しますか？ つまり、 cd project-a && fig ps 、次にcd project-b fig <something> ？

ご意見ありがとうございます！

奇妙な; 複数のプロジェクトの管理をどのように処理しますか？

私は通常の実行figからpython-tox私はので、私は本当に私のシェルでそれを設定することはありませんよ、環境を設定することができました。 また、tmuxを使用する傾向があるため、プロジェクトごとに異なるシェルを使用しています。

両方のオプションを補完できると思います

かっこいい、同意します。

.fig/instance-name販売されているのか、インスタンス固有のオーバーライドを含む可能性のある.fig-instance.ymlで販売されているのかはわかりませんが、これはマイナーな点だと思います。

プロジェクト名を考える; 私があなたの状況を正しく理解している場合、生成される_images_、たとえばmyapp:build12345 、または_containers_の名前を制御できることが重要です。 あなたの状況の「感触」を得るためだけに。

「ランダムな」プロジェクト名の背後にある私の考えは、Figがプロジェクトのコンテナを見つけることができる限り、見栄えの良い名前は重要ではないということでした。 ユーザーとして、サービス名（ fig stop web ）を介してサービスのコンテナーにアクセスできる場合、実際のコンテナーの名前は重要ではありません。

figは、 .figディレクトリ内のローカルストレージ内のIDによってコンテナを追跡できると考えていました（これは、実行中のコンテナが多数あるマシンでパフォーマンスが向上する可能性があります）。 しかし、それは本当に別の問題のためのものです。

'project-name'ファイルを「暗黙的に」作成すること、またはfig init介して「明示的に」作成することについて何か考えはありますか？ おそらく、これからの休暇中に少し時間があれば、少し実験することができます（Pythonで何もコーディングしたことがないので、_本当に_実験的です:)）

myapp：build12345など、生成されるイメージ、またはコンテナーの名前を制御できることが重要ですか？

イメージは本当に重要だと思いますが、コンテナー名が競合しないようにすることも、共有ホストでは非常に重要です。 この提案は、実際にはその問題にも対処することを目的としていると思います。

しかし、コンテナの予測可能な名前は依然として重要だと思います。 外部システム（図だけでなく）がコンテナーを名前で識別できることが重要ないくつかのタスクを考えることができます。

• 古いコンテナを削除するためのクリーンアップスクリプト。どのプロジェクトがコンテナを作成したかを識別できます。
• コンテナのデバッグ/検査

コンテナ名がどうなるかはすでにわかっているので、どちらも今はとても簡単です。 名前を検索する必要がある場合は、多少複雑になります。

figは.figディレクトリ内のローカルストレージにあるIDでコンテナを追跡できるとさえ考えていました

これがパフォーマンスの向上になる可能性があるのは事実ですが、これは間違ったアプローチであると心配しています。 figに永続的な状態を追加すると、（状態に付随する）多くのバグが発生する可能性があります。 むしろ、これがdockerdのラベリングシステムによって処理されることを望んでいます。 figがコンテナーにラベルを付けるだけで、そのラベルが付いたすべてのコンテナーを照会できる場合、すべての状態を1つの場所（dockerd）に保持します。 ある時点でこの話があったことは知っていますが、ロードマップにあるかどうかはわかりません。

'project-name'ファイルを「暗黙的に」作成すること、またはfig initを介して「明示的に」作成することについて何か考えはありますか？

暗黙的に下位互換性が高いと思います。 どうしても必要な場合を除いて、 fig init避けたいと思います。 baseirを使用する代わりに、 <basename>-<4 digit random id>プロジェクト名を暗黙的に作成していることがわかりました。

figがランダムな名前を生成し始めた場合にのみ、単一のホストで1000以上のコンテナーを実行し、名前でそれらを識別できなくなった場合は、それから切り替えます。

@ frank-dspeedユースケースを追加していただきありがとうございます。 私が正しく理解していれば、figを使用してコンテナーを_開始_しますが、その後、Figが使用する命名規則を使用して、Dockerを介してコンテナーを直接_ "管理"しますか？

おそらくこれもあなたにとって興味深いことです： https ：

ああ、そうです、たとえば新しいfildを追加するだけで、そのような提案をたくさんしましたが、その場合はENVを追加するだけで終わり、コスチュームfildとして解析できます：dart：

プロジェクト名の明確さを管理することは、figの責任ではないと思います。

私があなたの提案を正しく理解したとき、ランダムな名前を生成すると、 FIG_PROJECT_VARIABLEと--project-nameオプションが役に立たなくなります。 これは「テンプレート」サービスに便利です。

プロジェクト名の明確さを管理することは、figの責任ではないと思います。

私はちょっと確信が持てません; 同じ名前のディレクトリにたまたまあると厄介なことがあるため、図は別のプロジェクトのコンテナを「サイレントに」上書きします。

私があなたの提案を正しく理解したとき、ランダムな名前を生成すると、FIG_PROJECT_VARIABLEと--project-name-optionが役に立たなくなります。 これは「テンプレート」サービスに便利です。

上記の議論に続いて、私はこのようなものがうまくいくと思います

• --project-nameが提供されている場合は、それを使用します（そして、 .project-nameを書き込み/更新しますか？わからない）
• --project-nameは提供されていませんが、 FIG_PROJECT_NAMEは、 FIG_PROJECT_NAME使用します（そして.project-name書き込み/更新しますか？）
• 上記のいずれでもないが、 .project-nameが設定されている場合は、 .project-name使用します
• 上記のどれでもない; _random_名を作成し、それを.project-name書き込みます

名前を処理してfigに渡すスクリプトでfigを使用する人の観点からは、プロジェクト（私の場合はテンプレート）の場所に名前を格納することは意味がありません。

それでも、 fig up実行したときに、結果のコンテナの名前にディレクトリ名が使用されていることは非常に直感的
たとえば、 docker ps -aを見ると、ランダムな名前で埋められている場合はあまり役に立ちません。

オプション--random-nameはあなたの状況に役立ちますか？
それに加えて、名前空間を反映するために[a-zA-Z0-9_].*を付加する機能は、より広範な展開に役立つと思います。

fig.ymlを使用してそのような情報を保存するのはどうですか？

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

そして、BCを維持するために、compose / project.py :: from_configで

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse私はあなたが提案したようなものにとても

とにかく、このチケットで解決するために？ 提案された＃1233は、下位互換性を損なうことなく、ユーザーが実行するアクションを決定できるようにすることで、両方の長所を提供しているようです。

もともとはdocker-compose.ymlの名前が​​欲しかったのですが、もっと考えてみると、別のファイルというアイデアがとても気に入っています。

別のファイルを使用すると、必要に応じてバージョン管理の対象外にすることができます（各ユーザーが異なるプロジェクト名を持つことができるようにする場合）。

新しいネットワークサポートでは、ネットワーク名も構成できるようにする機能要求があります（デフォルトではプロジェクト名になります）。 したがって、別の構成ファイルを使用して、デフォルトのネットワーク名、デフォルトのスケールなどを含めることができます。アプリケーション定義の一部ではないが、コンポジションの実行に関連するすべてのメタ構成。

私はドネフィンが言ったことに同意します。 ファイル.docker-composeどうですか？ そこにすべてのコマンドライン引数のデフォルトオプションをリストできます。

@dnephin sgtm

@mikehaertlこの例では.docker-composeフォルダーを使用しましたが、保存する情報の量によっては、ファイルも機能する可能性があります。

@thaJeztahああ、そうだ、ごめんなさい。 私は逃しました。

@mikehaertlはそれらの名前を.figから.docker-compose ;-)

正しい ：）

実際、私は単純なファイルを好みます。 iniスタイルはどうですか？ 上部のグローバルオプション、セクション内のコマンド固有のオプション：

project-name = blabla

[build]
no-cache

同じファイルまたは同じディレクトリに保存したい半関連情報のアイデア：

• ネットワーク名（ユーザーはプロジェクト名とは異なるネットワーク名を希望する場合があります。すでに1つのリクエストがあります。）
• クライアントAPIバージョン
• Dockerホスト
• デフォルトのスケール値

複数の作成ファイルをサポートするようになったので、構成として使用する作成ファイルへのパスを含めることも興味深いかもしれません。

クライアントAPIバージョン

おそらくdocker_host ？

それも良いもののように聞こえます（追加）

私はちょうどこの問題に遭遇しました。

Docker構成の基本構造が決まった時点で、他のサービスに複製しています。 すべてのプロジェクトは同じ構造を持っているため、すべて同じサブディレクトリ（したがってデフォルトのプロジェクト名）を使用します。 つまり、同じホストで2つのサービスを安全にスプールすることはできません。

プロジェクトのディレクトリ名がデフォルトになるように構造を変更する必要があるかもしれませんが、イメージのビルド時にファイルをコピーすることについて100％肯定的ではありません。

ここでも同じですが、 Makefileターゲットで同様の問題を解決しました。 それでも、カスタムdocker-composeコマンドを実行する場合は、 -p customnameを使用する必要があります。

現在、 /home/alice/myprojectと/home/bob/myproject docker-composeセットアップが互いのコンテナーを踏まないようにする方法を見つけようとしています。 最後のディレクトリ名だけでなく、完全なファイルパスからコンテナ名を取得する方法はありますか？

@ chris-martinこれは単なる回避策です...

alias docker-compose="docker-compose -p ${PWD}"

docker-composeはプロジェクト名から/取り除きますが？

プロジェクト名に使用できる文字は文書化されていますか？

最終的にディレクトリ構造を変更し、docker-compose.ymlをプロジェクトルートに配置しました。これは十分に適切な回避策です。

すべてのgitリポジトリを同じディレクトリ（たとえば、$ HOME、または$ HOME / projects）に配置する傾向がある場合は、ある程度の保護が提供されますが、別の構造（たとえば、組織ごとに1つのディレクトリ）を使用すると面倒になります。多くの場合）、またはマシンがboot2dockerを使用している場合、docker-machineが個別のVMを提供するように注意しない限り、同じボックス上のユーザー間で情報がリークする傾向があります。

＃2294またはdocker-machineをより衛生的にすることで、問題が解決すると思います。

また、プロジェクトルートに配置し、別のフォルダー名を付けることをお勧めします。

私の場合、AWSに共有マシンがあり、ルートにdocker-compose.ymlがありますが、ユーザーがリポジトリを別の名前のディレクトリに複製できるため、最初のプロジェクト名を設定したいと思います。 それが現在発生している場合、コンテナの起動/停止で問題が発生します。

新しいv2構文を使用すると、 https： //github.com/docker/compose/issues/745#issuecomment-74028861で説明されているように実装でき

実はcontainer_name_prefixですよね？

@ schmunk42

それは実際には単なるcontainer_name_prefixですよね？

volume_name_prefix 、 image_name_prefix 、 network_name_prefixとしても使用されるので、 project_nameの方が一般的な用語だと思います。

.docker-compose docker-compose.override.ymlは、多くの点で
したがって、 @ JosephEarlのユースケースを有効にするために、 docker-compose.ymlにproject_nameキーを追加するという＃745（コメント）での@jderusseの提案に賛成です。

ユーザー固有のカスタマイズは、 docker-compose.override.ymlを使用し、 .gitignore介して除外することで、すでに実装できます。
3番目の明示的にユーザー固有のオーバーライドファイルが必要な場合は、 .docker-compose.local-override.yml勧めします。

YAMLの構造に関しては、 projectという新しいトップレベルキーを作成することをお勧めします。これにはproject_nameが含まれ、将来的には他の変数が含まれる可能性があります。 これにより、最上位の名前空間の汚染が回避されます。 説明する：

project:
  project_name: "your-project"
  network_prefix: "abc"

network_prefixを使用する代わりに、ネットワーク自体の名前を直接カスタマイズする方が理解しやすい場合があることに注意してください。 私が理解しているように、2つのケースがあります。

• 最初のケースは、「ネットワークに一意の名前を付けるだけですが、どちらが正確かは関係ありません」です。 この場合、 project_nameで十分です。
• もう1つのケースは、外部システムによって参照されるネットワークです。 この場合、とにかくネットワーク名自体を明示的に指定する方がおそらく良いでしょう。

上で提案された提案は私には良さそうです、私たちは余分な設定ファイルを導入したくないことに同意します

この問題の概念に+1
ただし、リポジトリに別のファイルを追加する代わりに、 docker-compose.ymlキーを使用する場合も+1します。

以前のコメントを要約すると、プロジェクト名のルックアップシーケンスの1つの提案は次のようになります。 前のアイテムが後のアイテムよりも優先されます。

1. 指定されている場合は--project-name使用します
2. 指定されている場合はCOMPOSE_PROJECT_NAME使用します。
3. docker-compose.yml （またはその設定が保存されている場所）のproject_nameキーを使用します。
4. プロジェクトディレクトリのbasenameを使用します

2対3の優先順位がわかりません。

• --project-nameとの一貫性をCOMPOSE_PROJECT_NAMEはproject_name:を確実にオーバーライドする必要があります。
• ただし、 COMPOSE_PROJECT_NAMEをproject_name:よりも優先させると、環境変数が設定されているために誤って間違ったプロジェクト名を使用する可能性があります。 これはデバッグが難しい場合があります。 この場合、警告メッセージが問題になる可能性がありますか？

BCを維持するためにデフォルト値%(project_name)s_%(service_name)s_%(instance_number)s新しいプロパティcontainer_name_patternを導入するのはどうですか
このパラメーターを使用すると、自由にhardcodedproject_%(service_name)s_%(instance_number)sに変更して、この問題を確実に修正できます。

この機能を10分間探した後、この問題が発生しました。

私が最初にしたことは、ファイル参照の作成ドキュメントで正しいキーを検索することでした。したがって、 docker-compose.yml project_nameキーを+1します。

：+1： @ cr7pt0gr4ph7戦略の場合

@ cr7pt0gr4ph7戦略の+1

Composeには、環境置換の構文があります。 プロジェクト名に環境変数を使用するのではなく、気になる人に自分でやらせてもらえませんか？

一方、Dockerマシンは、エンドを使用して、composeビルドをビルドするマシンを決定するため、プロジェクト名とターゲットは同じように機能するはずです。 うーん、これは難しいものです。

https://github.com/docker/compose/issues/745#issuecomment-182296139は正しく聞こえます。 環境変数は、デフォルトとして機能する作成ファイルの値よりも優先されます（プロジェクト名が作成ファイルに属していると想定）。

それぞれがプロジェクト名を定義する複数の作成ファイルを使用するとどうなりますか？

ファイルを「プライマリ」または「エクストラ」にするエラーではないと思いますが、現時点ではそうではありません。 任意のファイルを単独で使用することも、他のファイルと組み合わせて使用​​することもできます。

警告が妥当な場合もあれば、完全に無視する場合もあります（オプションまたは環境変数を設定することで値を無視できるため）。

それぞれがプロジェクト名を定義する複数の作成ファイルを使用するとどうなりますか？

docker-compose -f compose1.yml -f compose2.yml upようなことをし、両方のファイルがプロジェクト名を定義する場合、使用される名前はcompose2.ymlからのものでなければなりません。

誰もが私がすでに気に入っているソリューションに取り組んでいると思います:-)つまり、docker-compose.yamlのproject_nameです。 docker-compose.yamlファイルにプロジェクト名を含めるための別のユースケースについて説明したいと思います。

プロジェクトのHTTP500 Internal Server Errorページで、問題を修正またはトラブルシューティングする方法を開発者に伝えます。たとえば、サーバーがPostgreSQLデータベースがないことに気付いた場合はzcat database-dump.tgz | docker exec -i projectname_db_1 psqlできることを開発者に伝えます。ユーザーが作成されました。次に、自分でprojectnameを選択します。そうしないと、ヘルプメッセージをコンソールにコピーして貼り付けることができません。

COMPOSE_PROJECT_NAMEがcompose.ymlのプロジェクト名をオーバーライドするときに警告が表示されることに同意します。この動作は既存のDockerコマンドに基づいて意味がありますが、特に論理的でも初心者にとっても明白ではありません。

@ cr7pt0gr4ph7戦略の+1

何も見つからなかったので、自分で問題を開く前に何かを検索してみました。
docker.compose.ymlファイルのproject_name +1。 v2では、これはますます理にかなっていると思います。

COMPOSE_PROJECT_NAMEがcompose.ymlのプロジェクト名をオーバーライドするときに警告が表示されることに同意します。この動作は既存のDockerコマンドに基づいて意味がありますが、特に論理的でも初心者にとっても明白ではありません。

環境変数が構成設定をオーバーライドし、コマンドライン引数が構成設定と環境変数をオーバーライドするのは、ごく普通の動作です。
本当にその警告ですか？ 誰かが誤ってCOMPOSE_PROJECT_NAMEという名前の環境変数を作成するようなものではありません。

これを実現するためにdocker-compose.ymlからproject_nameを使用するPRを作成しても大丈夫でしょうか？ または、すぐに参照される最後のymlファイルのproject_name値を使用するような追加のものが必要ですか？

これはどう？

version: "2"
project:
    default_name: "app"

この形式の実装（https://github.com/docker/compose/pull/3118）を変更します。 しかし、 projectセクションが必要かどうかはわかりません。

+1この機能を見たい

@timgriffiths 、プロジェクトに環境ファイルを追加することで、最新のRCでこれが可能になるようです。

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel環境ファイルを調べましたが、作成ファイル内でプロジェクト名を定義できる良いユースケースがあると思います。

私たちの状況では、Prod、Staging、UAT、Devの作成ファイルがあるので、アプリケーションスタックの異なるバージョンを起動できます。また、同じ群れでStagingとUAT環境を立ち上げたい場合もあるので、環境を使用できます。変数などは、ユーザーがこれを設定することを覚えているかどうかに依存します。これは、作成ファイルにあるかのように、すべてがリポジトリにチェックインされ、すべてをインラインに保ち、すべてのユーザーに簡単に説明できるようにします。

+1作成ファイルに事前構成されたリモートボリュームへの参照がある状況があります。 Composeは、プロジェクト名をそれらのボリューム名に自動的に追加しますが、名前が一致しないためにマウントに失敗します。 作成ymlファイルでプロジェクト名を明示的に設定できると、環境によって異なる可能性のあるあいまいな外部ファイルに環境変数を隠すのではなく、プロジェクトに関係する他のユーザーにとって命名規則がはるかにわかりやすくなります。

@edevenportの場合、名前付きボリュームの外部オプションを使用できます。

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

ありがとう@ fesor-私はもっ​​と詳細に入る必要がありました。 私は実際に次のような構成を使用してglusterfsボリュームをマウントしています：

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

この場合、 mediaはホスト上でprojectname_mediaになり、glusterfsボリュームがプロジェクト名で事前に作成されていない限り、マウントに失敗します。 glusterfsボリュームをホストに手動でマウントし、docker-composeファイルでexternalを使用することを考えていましたが、事前にすべてのノードで手動で行う必要はありませんでした。

@edevenport私はそれを理解しています。 ただし、このボリュームをdocker volume createを使用して手動で追加し、使用することもできます。

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

したがって、プロジェクトを変更する必要はなく、プレフィックスを削除します。

@timgriffithsの場合はもっと複雑で、回避策はありません。 プロジェクト名を覚えていないために、 docker-compose周りに単純なラッパーを使用します。

@fesorなので、作成ファイルを説明的なフォルダー名に貼り付けるだけで問題を回避できました。これにより、この制限を回避できます。 しかし、それが後のリリースで追加されるのを見るのはとてもいいことです

@timgriffiths私はPRを作成しました（https://github.com/docker/compose/pull/3118）-多分これは役立つでしょう。 ただし、複数の作成ファイルがある場合は、ケースを処理できません。

@fesor PRは完璧だと思いますが、それを統合する可能性はありますか？

これで、Composeは環境ファイルを提供するので、プロジェクト名をそこに永続化できます。

@mkuzmin COMPOSE_FILEがあるのに、 COMPOSE_OVERRIDE_FILEがないのは悲しいことです。

@fesorAFAIK複数のファイルを指定できます

@ schmunk42プロジェクト名も指定できます。 しかし、これは問題を解決しません。 デプロイスクリプトに次のようなものが必要です。

docker-compose up -d

の代わりに

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

上記の例のCOMPOSE_PROJECT_NAMEはCIによって指定されています。 そして、 .envファイルのような機能はかっこいいですが...プロジェクト名の永続性の場合には役に立ちません。

.envを使用して環境変数をDRYします（そしてdocker-compose <1.7の場合、単純なラッパーを使用します）が、他の問題は解決しません。 @timgriffithsは、swarmクラスターへのデプロイのケースをすでに指摘しています。

COMPOSE_FILE=one.yml:two.ymlは、複数のファイルを設定する方法です。 したがって、オーバーライドファイルを$COMPOSE_FILE含めるだけです。

@dnephinはその機能を見逃しました。

ええと...スウォームデプロイメントについては、jenkinのジョブENV変数でCOMPOSE_PROJECT_NAMEを介してすでに処理しているため、手動デプロイメントでのみ問題が発生します。 そして、私の実装では、デフォルトのプロジェクト名を上書きすることはできません。

この問題はほぼ2年前のものであり、まだ解決されていません。 Dockerチームが最終的に適切な修正を追加するのを正確に妨げているのは何でしょうか。 docker-compose.ymlファイルに単純な新しい構成ディレクティブを追加するのは本当に難しいですか？

.envの回避策は優れていますが、常に使用できるわけではありません（ .envファイルはアプリケーションですでに使用されている可能性があります）。 そして、それはまだ回避策です。

また、プロジェクト名に関連する可能性のある他の新しい問題が最新バージョン（＃3966）に忍び寄るのを見たこともあります。

それで、本当に問題は何ですか？

docker-compose.ymlファイルに単純な新しい構成ディレクティブを追加するのは本当に難しいですか？

番号！ 問題は、実装の難しさではありませんでした。

.envの回避策は優れていますが、常に使用できるわけではありません（ .envファイルはアプリケーションですでに使用されている可能性があります）。 そして、それはまだ回避策です。

これは回避策ではなく、解決策です。 .envファイルには、Composeによって読み取られる環境変数が含まれています。 アプリケーションで読み取る環境変数がある場合は、それらを別のファイル（たとえば、 app.env ）に配置し、 env_fileオプションを使用して参照します。

それで、本当に問題は何ですか？

プロジェクト名をdocker-compose.ymlファイルに追加すると、移植性が低下します。これは、私たちが推奨したいことではありません。 docker-compose.ymlの移植性を犠牲にすることなく、プロジェクト名を永続的に指定する方法（ .env ）があるので、構成オプションとして追加する場合は弱くなります。 これが、この問題が解決されなかった主な理由です。

プロジェクト名をdocker-compose.ymlファイルに追加すると、移植性が低下します。

これはオプションではありませんか？ 個人的には、 docker-compose.ymlチェックインすることはありませんが、ローカルで調整したリポジトリにdocker-compose-example.ymlを提供するだけです。 たとえば、開発中に、いくつかの追加のenv変数を追加したり、追加のボリュームをコンテナーにマップしたりする場合があります。 プロジェクト名を指定するオプションも提供してみませんか？

議論に続いて、すべてのnetworkオプションを.env移動する必要があります。これらは通常、まったく移植性がなく、ホストマシンのネットワーク設定に依存するためです。

別の言い方をすれば、プロジェクト名が特別な理由は何ですか？ docker-compose.ymlには、実際には移植性のない他の多くのオプションがすでにあります。 開発者に、ユースケースに最適なものを選択するオプションを提供してみませんか？

また、オプションを利用できるようにする必要があると思います。 Dockerの使用が広まるにつれて、ワークフロー内でコンテナー化を使用する開発者が1人だけのプロジェクトがますます一般的になります。 これらのユースケースでは、プロジェクト名が一定であっても問題ありません。 このような柔軟性を可能にする別のプロジェクトの良い例は、 Vagrantfileです。 彼らは、大規模なチームには確かにユースケースがあることを認識していますが、一匹狼の開発者のシナリオも認識しています。

ここでプロジェクト名オプションを実装することは、採用のために重要だと思います。 「スケーラブルなプロジェクト名の構成戦略」を気にしない一人の開発者を捨てる可能性があります。

プロジェクト名をdocker-compose.ymlファイルに追加すると、移植性が低下します。これは、私たちが推奨したいことではありません。 docker-compose.ymlの移植性を犠牲にすることなく、プロジェクト名を永続的に指定する方法（.envを使用）があるため、構成オプションとして追加する場合は弱くなります。 これが、この問題が解決されなかった主な理由です。

プロジェクト名をdocker-compose.yml追加すると、移植性が低下しますか？

@mikehaertlによって作成された＃3966に示されているように、私見では実際には逆です。 この問題は、プロジェクト名がdocker-compose.yml格納されていないため、実際には移植性が低くなることを明確に示しています（たとえば、同じマシンから開始された他の作成プロジェクトと衝突する可能性が高くなります）。多くの人が少なくとも最初は知らないコンテナフォルダ名。

.envファイルを追加すると、Composeを採用したい新しい人のために学ぶことが追加されるだけでなく、これらを防ぐためにdocker-compose.yml横のリポジトリに追加する必要があるためです。衝突docker-compose.ymlプロジェクト名を定義するだけで、移植性がどのように異なるかはわかりません。

また、docker-compose.ymlに名前を追加するためのものです。 .envファイルは、私が使用している他のフレームワークで使用されており、リポジトリから離れていることが重要です。 ただし、開発者全体でローカライズされたコンテナーを維持するには、Dockerについての知識が少ないほど（最初は）優れています。 他のプロジェクトと衝突しないシンプルなエントリポイントが必要です。 なぜ物事がそうなっているのか説明したくありません。 単純な

クローンリポジトリ
docker-構成する

現在の私の回避策は、 @ schmunk42が提案したファイルを作成することです。

コンテナ自体はプロジェクト名を気にする必要はありません。 ホストが気にすることだけを目的としたメカニズムとして環境変数を使用するのはなぜですか？

docker-compose.ymlファイルでこれがサポートされていることを確認したいと思います。 環境変数を介して設定する必要がある場合は、 .envファイル内で定義し（ホストに直接設定されていない場合）、 docker-compose.ymlファイルの変数置換を介して使用できます。

名前付きコンテナが許可されている場合、名前付きプロジェクトが許可されないのはなぜですか？

.ymlファイルでのプロジェクト名の定義が便利なユースケースは次のとおりです。
異なるWebサーバー（異なるデータベース資格情報、異なるデータボリューム、ロゴなどのいくつかの小さな違い）に対して同じdocker-composeファイルがあります。 実行中のアプリケーションごとに3つのサービスがあり、それらは作成ファイルで構成されます。 複数のサーバーが隣り合って実行されている場合、どのサービスがどのプロジェクトに属しているかを確認すると便利です。

コンテナー名の変数置換は、プレフィックスとして$ COMPOSE_PROJECT_NAMEを使用すると便利です。 .env-fileソリューションはよく理解していますが、これにより、（CI）デプロイメント環境での「開発者にとって使いやすい」ものにはなりません。

-pまたは環境変数が設定されておらず、「docker」サブフォルダーにdocker-composeを作成したため、まったく異なるdocker-composeのdocker-composeキルコンテナーを1つ持つことは、私の意見では重大なバグです。

深刻な展開では、エラーの余地が多すぎます。 -p、.env、またはその他の場所でプロジェクト名を指定することを忘れてください。何が起こったかに気付くまで、しばらくの間オフラインになります。 さらに悪いことに、衝突しているサービスは、作業中のサービスではなく、オフラインになります。 あなたは幸せな一日を過ごすでしょう:(

@dnephinこれを最終的に実装するために

たぶん私はここでこれにいくつかの懸念を持っている唯一の人ですが、とにかく。
このセットアップでは、環境を切り替えるために.envファイルとapp.envファイルのみを変更しますが、これは複数のファイルを持ち、 ymlファイルをマージすることに依存しています。

これが実装されたら、BCについて考えてください。

例えば。 プロジェクト名がdocker-compose.ymlと.env定義されている場合は、後者が優先されます。 そうしないと、 .envを介してこれを管理することに依存している人々は、現在のワークフローやフォルダー名に依存している場合のように、スタックの重複について同様の問題を抱えています。

@ schmunk42 .env機能を削除する必要があると言っているわけではありません。 プロジェクト名を.envに入れたい場合は、単にdocker-compose.yml設定しないでください。

しかし、ここでの議論が明確に示しているように、他の人はそれをdocker-compose.yml入れることを好みます。 彼らが望むなら、彼らはそうすることができるはずです。 これはオプションの機能です。 両方が構成されている場合に優先されるのは、単純な規則を定義することです。

Srsly、名前付きプロジェクトを追加してください。 使用事例：
プロジェクト1：
docker-compose up --build --remove-orphans

• nginx
• 静的コンテンツ
  プロジェクト2：
  docker-compose up --build --remove-orphans
• nginx
• 静的コンテンツ

プロジェクト2が開始すると、出口137（コード128 +レベル9）でプロジェクト1のコンテナーが強制終了されます。

今、私はdocker system pruneを実行し、ネットワークを毎日再構築して、数十のデッドコンテナが発生しないようにする必要があります。

export COMPOSE_PROJECT_NAME=somethingnew

コアチームの誰かが最終的に説明できますか、この機能を妨げているのは何ですか？ それはとてもイライラします、とても簡単に修正できるものが正当な理由もなくブロックされる方法。

これまでの唯一の議論は、 docker-compose.yml移植可能に保つこと

• コンポーザーファイル内のプロジェクト名によって、自動的に移植性が失われることはありません
• 誰もがこの要件を持っているわけではありません
  
  
  
  • 同じ方法で移植性を制限できる他のオプションがすでにあります： networks 、 port 、..。
  
  

それはすべて、特定のユースケースに大きく依存します。 しかし、単にいくつかは、このオプションをしたくないので、することは誰もが自分の意見に従うことを持っていることを意味してはいけません！

@mikehaertlあなたはすでに永続的なプロジェクト名を持っています。 .envファイルを置き、そこにCOMPOSE_PROJECT_NAME変数を設定するだけです。 作成ファイルのプロジェクト名にメリットはありません。

@fesorマシン/環境固有の設定が含まれているため、通常、バージョン管理下に.envファイルはありdocker-compose.ymlファイルでプロジェクト名を構成できるようにしたいのです。 。

@fesor ： @thasmoはこれで正しいと思います。 プロジェクト名は、プロジェクトを使用するすべての開発者に関連する場合はバージョン管理下にある必要があるため、 compose.ymlファイルで指定するオプションが必要です。

@fesor申し訳ありませんが、個人的な好みが本当の議論だとは思いません。 本当の問題は、なぜ.envや環境変数を使いたくないのかということではありません。 それは逆です：なぜそれが属する設定ファイルに入れられなかったのですか？

コマンドラインでdockerに渡すことができるほとんどすべてのオプションは、そのファイルで指定できます。 プロジェクト名のみがいくつかの不思議な理由で除外されています。 これは議論の中でアパルトヘイトの一形態ですか？ ：PIはそれらすべてに対して平等な権利を主張します！ 開発者に決定を任せ、人為的な制約を課さないでください。

そして再び：誰もあなたから古いオプションを奪っていません-私たちはついにこの追加のオプションが欲しいだけです。 それは公正なことです。

@dnephin ：あなたと他のみんながcr7pt0gr4ph7のこの問題の改良で述べられた解決策に満足しているようです。

それを実装するプルリクエストを喜んで受け入れますか、それともメンテナの1人にそれを書いてもらうつもりですか？

@ cr7pt0gr4ph7

* compose.ymlにプロジェクト名を持つ@ dnephin @ fesorは、統一された構成スキーマを容易にします

プロジェクト名が重要な理由は私にはわかりません。 構成ファイルのどの部分も、特定のプロジェクト名に依存するべきではありません。

プロジェクト名の唯一の重要な品質は、他のプロジェクトの名前と競合しないことです。これは、実際には、 docker-compose.ymlファイルに入れることに反対する議論です。 プロジェクトの開発者は、プロジェクトごとに異なるディレクトリ名を使用することが多いため、ほとんどのユースケースではデフォルトが正しいことがよくあります。

デフォルトが正しくない場合、開発者がそれをオーバーライドする方法があります（ -p 、またはCOMPOSE_PROJECT_NAME ）。これはエイリアスにするか、 .envファイルに入れることができます。 。

私はプロジェクト名を定義するプロジェクトファイルに反対していません。この機能が一部の人にとって非常に重要である理由を理解したいと思います。 作成ファイルに特定のプロジェクト名が必要なためである場合は、別の問題として別の方法で対処する必要があると思います。

1つのディレクトリに4つの作成ファイルが必要でした。 ここでは、デフォルトでディレクトリ名が間違っています。 私が持っている唯一のオプションは、1つのディレクトリ内の1つの作成ファイルに対してのみ機能する.envです。

_COMPOSE_PROJECT_NAMEと-p：_を除外する理由
COMPOSE_PROJECT_NAMEと-pは、設定することを忘れないようにする必要があるため、本番環境では保存されないと思います。 または、起動スクリプトを作成し、dockercomposeを直接使用しないことを忘れないでください。 人物Aがこのメカニズムに依存していて、人物Bがそれを知らない場合、それは特定の失敗です。
（私はすでにそれを上で詳述しました）

@dnephin私と私のチームにとって、アプリケーションロジックは通常、プロジェクトフォルダーのhtdocsフォルダーに保存されます。 これにより、他の関連ドキュメント/リソースを1つのディレクトリにまとめることができます。 リモート開発者と協力する開発者として。 フォルダー構造について何も想定する必要がなければ、Dockerを採用してもらうのは簡単です。 私は過去にこれを述べましたが、.envは通常、私たち全員が共有するリポジトリの一部ではないため、私にとってオプションではありません。

プロジェクト名が重要な理由は私にはわかりません。 構成ファイルのどの部分も、特定のプロジェクト名に依存するべきではありません。

ホストで「docker-composedown」を実行し、必要なコンテナとは異なるコンテナをダウンさせたことが何度もありました。 覚えていなかったからといって、 .envファイルにも構成があったことを。

プロジェクト名の唯一の重要な品質は、他のプロジェクトの名前と競合しないことです。これは、実際には、docker-compose.ymlファイルに配置することに反対する議論です。 プロジェクトの開発者は、プロジェクトごとに異なるディレクトリ名を使用することが多いため、ほとんどのユースケースではデフォルトが正しいことがよくあります。

多分それはあなたにも当てはまりmyapp/app/docker-compose.ymlようなものです。 したがって、すべてのアプリはディレクトリ名app共有します。 また、ホスト上に複数のコンテナーがあります。

デフォルトが正しくない場合、開発者がそれをオーバーライドする方法（-p、またはCOMPOSE_PROJECT_NAME）があります。これは、エイリアスにすることも、.envファイルに入れることもできます。

真剣に、私はここでカフカの小説にいるように感じ始めます。 それはあなたが基本的にのためのすべてのコマンドラインオプション置くことができることを、明らかにされていませんdockerにdocker-compose.ymlこの一つの大きな例外を除いて- ？

何度も何度も私たちに尋ねて私たちの答えを無視する代わりに、なぜ誰かが最終的に抵抗を正当化できないのですか？ そしていいえ：「...しかし私はそれを必要としない」は有効な議論ではありません！

@dnephin独自のgitリポジトリに複数のプロジェクトがあり、ルートプロジェクトディレクトリをクリーンに保つために、すべてのDocker関連のものをdockerというサブフォルダーに配置します（ビルドコンテキストは.. 、すべてが美しく機能します）。

1つのサーバーで複数のプロジェクトを実行するには、現在、各リポジトリにdocker/.env.distを作成し、 cp docker/.env.dist docker/.env後にgit clone cp docker/.env.dist docker/.envを作成する必要があります。 それ以外の場合、プロジェクト名はdocker 、これは明らかに必要ありません。 .envにパスワードなどが含まれている場合もあるので、とにかく.env.distコピーする必要がありますが、ほとんどの場合、 COMPOSE_PROJECT_NAMEを定義する方法がないという理由だけで、 .envが存在します。 COMPOSE_PROJECT_NAME docker-compose.yml 。

同じCOMPOSE_PROJECT_NAMEがdocker-compose.yml内で2回使用されると、コンテナーの開始方法と停止方法に不具合が生じる可能性があることを理解していますが、 .env.distをコピーするのを忘れると、すでに発生していますまたは、同じサーバー上の2つの異なる.envファイルに誤って同じ名前を割り当てた場合。 私にとっては、 default_compose_project_nameをdocker-compose.ymlで直接定義し、プロジェクトのステージングコピーを実行したい場合は、 .envの値をオーバーライドできれば理想的です。 。 これは紀元前100％ですが、より便利です。

私は過去にこれを述べましたが、.envは通常、私たち全員が共有するリポジトリの一部ではないため、私にとってオプションではありません。

たぶん、それがすべての根本原因です。前に、 docker-composeこのファイルを「ハイジャック」し、名前をapp.envに変更せざるを得なかったと言いました。

たぶんdocker-compose.envが正しい選択だったでしょう。

FWIW：本番環境では.envファイルのみを変更しています。必要に応じて、 ymlファイルはdocker-compose.override.ymlとマージされます。

回避策は、ymlファイルを.envファイルなしで開始しないように定義することでもあります。 変数image: $IMAGEを使用します。

これは、 @ schmunk42の上の1つのディレクトリケースにある4つのdocker-composeファイルの回避策です。 本当に？

@RobIsHereしかし、とにかく-fを使用する必要がありますよね？

このコメントの@dnephinへの返信：

プロジェクト名が重要な理由は私にはわかりません。

docker-composeが管理するDockerコンテナの名前に影響するため、これは重要です。 プロジェクト名の設定を忘れた場合、 docker-compose psは、以前にdocker-compose --project-name <project_name> up -d <container_name>作成したコンテナーを見つけられません。

また、グローバルコマンドdocker psを実行すると、実行中のコンテナのリストにプロジェクト名が含まれるため、コンテナの出所がわかります。 たとえば、すべてがMySQLを使用する複数のコードプロジェクトを一度にテストしていて、それぞれにmysqlコンテナがある場合、 docker psはあいまいなコンテナのリストが表示されます。 したがって、プロジェクト名は、同じマシンで実行されている多くのDockerプロジェクトのコンテキストで重要です。

構成ファイルのどの部分も、特定のプロジェクト名に依存するべきではありません。

_DockerComposeプロジェクトに関連付けられている他のすべての変数_とは異なる場所にプロジェクト名を設定する必要があることは意味がありません。

プロジェクト名の唯一の重要な品質は、他のプロジェクトの名前と競合しないことです。これは、実際には、docker-compose.ymlファイルに配置することに反対する議論です。

私の最初の段落で述べた理由により、これは_「プロジェクト名の唯一の重要な品質」_ではありません。 使いやすさと理解のためです。

プロジェクトの開発者は、プロジェクトごとに異なるディレクトリ名を使用することが多いため、ほとんどのユースケースではデフォルトが正しいことがよくあります。

開発者が_all_関連のDockerファイルをdockerディレクトリに配置するデフォルト以外の場合、これはDockerプロジェクトを整理するための完全に合理的な方法であり、プロジェクト名を設定する魔法は競合するプロジェクト名を作成します。 したがって、この特定のケースでは、あなたが言及したのと同じ競合が発生します。 とにかくプロジェクト名を明示的に設定している場合、開発者をプロジェクト名の衝突から保護する必要はありません。

デフォルトが正しくない場合、開発者がそれをオーバーライドする方法（-p、またはCOMPOSE_PROJECT_NAME）があります。これは、エイリアスにすることも、.envファイルに入れることもできます。

環境変数の設定は、必要のない余分なレベルの複雑さです。 バージョン管理を使用して開発者間でプロジェクトを共有する場合は、ファイルのみを使用するのが理にかなっています。 呼び出しごとにコマンドラインパラメータを含める必要があるのは面倒で、エラーが発生しやすくなります。 また、 .envファイルは、プロジェクト固有の変数ではなく、ユーザー固有の変数を含むことになっているため、バージョン管理で共有できません。 したがって、プロジェクト名を設定する現在の方法は不十分です。

私はプロジェクト名を定義するプロジェクトファイルに反対していません。この機能が一部の人にとって非常に重要である理由を理解したいと思います。 作成ファイルに特定のプロジェクト名が必要なためである場合は、別の問題として別の方法で対処する必要があると思います。

docker-composeの機能に影響を与えるすべての変数は、同じ場所、 docker-compose.ymlファイルに配置する必要があります。 プロジェクト名を設定する現在の方法は、不必要な複雑さをもたらします。

この問題を購読しているほぼすべての人がこれらの点に同意します。

docker-config.ymlプロジェクト名を設定する機能を追加しても、現在の機能と競合することはありません。 それを実装しない理由はありません。

@ schmunk42前回チェックしたとき、dockerは.envファイルの名前を選択することを許可しませんでした。 私は何かを逃しましたか（変更に追いつくのは難しいです）。 docker-compse.envのようなものに変更すると、私のユースケースで修正されます。 私が抱えている問題は、両方とも.envファイルを必要とする2つの非常に人気のあるテクノロジーを使用していることです。 PHP Laravelフレームワークは、リポジトリ内のそのファイルを追跡せず、本番環境ではファイルが存在しない場合があります。

@RobIsHereが示すように、Dockerを最初に採用したとき、これは実際のスタブリングブロックであることがmyapp/htdocs/docker-compose.yml形式です。 Dockerを採用した初期の頃、私は意図していなかった他のコンテナーを誤って削除してしまいました。 私の場合、dockerがフォルダー名を使用するのではなく、プロジェクトにランダムに名前を付けた方がよいでしょう。

Dockerを採用し始めている他のリモート開発者が何人かいます。 チームとして、これらのアプリケーションを実行するために、これらの開発者に常に/のみdocker-compose upを指示する方が常に簡単です。 これらのアーリーアダプターがDockerについて知っていることが少ないほど良いです。 彼らがその背後にある力を見ると、彼らは自分で拾うでしょう。

要約すると、ユースケースはデフォルトが適切でない場合のようです。 デフォルトをオーバーライドする方法はすでにありますが、エラーが発生しやすく、アーリーアダプターには明らかではない可能性があります。

デフォルトが適切でない場合は次のとおりです。

• 同じディレクトリ内の複数の作成ファイル（それらを実行するには、すでに-fを指定する必要があります）
• すべてのプロジェクトに同じディレクトリ名を使用します（これには-fも指定する必要があると思います。考えられる回避策は、一意のディレクトリ名を使用することです）。

@dnephin追加しますが、Dockerを早期に採用する人にとってはつまずきの可能性が1つ少なくなります。

@dnephinこのコメントにもこれらの懸念がありました：

もともとdocker-compose.ymlで名前が欲しかったのですが、もっと考えてみると、別のファイルのアイデアが本当に好きです。 別のファイルを使用すると、必要に応じてバージョン管理の対象外にすることができます（各ユーザーが異なるプロジェクト名を持つことができるようにする場合）。

このようにプロジェクト名解決の優先順位を設定すると、その問題が解決されます（大きな数字は小さな数字よりも優先されます）。

1. docker-compose.yml
2. COMPOSE_PROJECT_NAME環境変数
3. --project-nameコマンドラインオプション

前回チェックしたとき、dockerは.envファイルの名前を選択することを許可しませんでした。

@fiveanddone AFAIKそれはできませんが、プロジェクトに必要なENVファイルを知る必要があるため、問題が発生するだけです。

phd5の場合、（app）-environmentをsrc/ 、 .envは単に「control-environment-file」であるため、ここで説明しようとし
私はこれが好きではなく、自分で変更することもなかったでしょう。 これは多くのプロジェクトでは不可能かもしれないことを私は知っています。
しかし持つ.envあなたと同じレベルで、アプリケーションからdocker-compose.ymlあなたがそこにaとb属していない、あなたの「コントロール・環境」の変数を取得する）ので、超迷惑になります）これらの変数が必要な場合は、コンテナに転送する必要があります。c） app.envファイルでこれらの変数を上書き/変更することはできなくなります。

@dnephin優先環境ファイルとしてdocker-compose.envを導入し、フォールバックとして.envを使用するのfig.ymlでも同じことを1回行いました。

それですべての人の問題が解決するとは思いません。 .envファイルの名前は、私には別の問題のように感じます。

問題の核心はこれだと思います：

docker-compose upの元の設計は、サービスを実行するために実行できる単一の（短い）コマンドでした。 これは、開発者が期待していることです。 ただし、一部のユーザー（この場合）ではその動作を実現できません。

この問題を回避する方法はたくさんありますが、すべての人に役立つと思われる方法はありません。

優先順位（最高から最低）は次のようにする必要があると思います。

1. --project-name （常にオーバーライド）
2. COMPOSE_PROJECT_NAME環境変数
3. バージョン管理されたファイルとは別に、ユーザーが定義したデフォルト
4. プロジェクトによって定義されたデフォルトで、チェックインできます
5. ディレクトリ名（何も指定されていない場合のデフォルト）

（3） .docker/project-nameファイルで実現できます（OPで提案されているように）
（4） docker-compose.ymlファイルのフィールドで実現できます

プロジェクト名を設定するために非常に多くの異なる方法が必要なのは残念です。

@dnephinは3に関して、ユーザーにデフォルトを設定させます。これがenv変数の目的であり、ファイルを作成する必要はありません。

うーん...そして、問題を少し一般化して、 docker-compose.yml default_environmentセクションを導入するとどうなるでしょうか。 このようにして、yamlに特別なフィールドを導入せずにCOMPOSE_PROJECT_NAMEを設定できますが、ファイル全体の他の場所に存在する可能性が高い他のデフォルト変数を定義することもできます。 これにより、 .env.distを.envコピーする必要がある場合の数が減り、コピーを忘れるコストが少なくなります。

使用例：

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

このyamlは、私がよく使用するものと非常によく似ています。visスケッチについて説明しています。このスケッチには、常にwebというサービスがありますが、ミニAPIサーバーやデータベースを備えたコンテナーによってバックアップすることもできます。 https://github.com/jwilder/nginx-proxyがすべての前面にあり、実際のポート80と443をリッスンしていると想定されてい

現時点では、ローカルマシンを使用している場合でも、リモートサーバーを使用している場合でも、 .envを維持し、そこに_all_環境変数が設定されていることを確認する必要があります。 たとえば、 SUBDOMAINを忘れた場合、コンテナは起動しますが、Webサーバーは壊れたままです。

default_environmentセクションを自由に使用できるので、すべての本番変数を1つのファイルに配置でき、サーバー上で.env.distをコピーする必要はありません。 ローカルマシンでは、上記の例では、1つの変数を.envに配置します。これは、 ROOT_HOST=example.com.dev （または、bashプロファイルでexport ROOT_HOST=example.com.devを使用することもできますか？ ）

要約すると、 default_environment中にセクションdocker-compose.yml唯一我々が現在議論されている問題を解決することはできませんが、また100％BCと理解しやすいでありながら、いくつかの余分な素敵なトリックを有効にすることができます！

WDYT？

それはいいですね、シナリオによっては重宝するかもしれません。

ただし、上記の（加熱された）議論に照らして、
ソリューションは大まかに次のように解釈されます。「新しいファイルをに追加する代わりに
yml、新しいセクションを追加するのはどうですか？」 :)

火曜、2017年2月28日には、午前0時02分アレクサンダーKachkaev [email protected]
書きました：

うーん...そして、問題を少し一般化して単純に紹介するとどうなるでしょうか
docker-compose.ymlのdefault_envセクション。 このように定義します
yamlに特別なフィールドを導入せずにCOMPOSE_PROJECT_NAME、ただし
他のデフォルト変数を定義することもできます。
ファイル全体のどこかに存在します。 これにより、ケースの数が減ります
.env.distを.envにコピーする必要がある場合、およびコピーするのを忘れるコスト
そうすることは少なくなります。

使用例：

〜/ projects /ketches/sketch-42/docker/docker-compose.yml

バージョン：「2」
default_env：
サブドメイン=スケッチ-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = Sketch-42
サービス：
ウェブ：
ビルド：
環境： ../
dockerfile：docker / Dockerfile
環境：
--VIRTUAL_HOST = $ {SUBDOMAIN}。$ {ROOT_HOST}、www。$ {SUBDOMAIN}。$ {ROOT_HOST}
-VIRTUAL_PORT = 80
-VIRTUAL_NETWORK =プロキシ
--LETSENCRYPT_HOST = $ {SUBDOMAIN}。$ {ROOT_HOST}、www。$ {SUBDOMAIN}。$ {ROOT_HOST}
--LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
再起動：常に
ネットワーク：
-プロキシ

ネットワーク：
プロキシ：
外部：
名前：プロキシ

このyamlは、私がよく持っているものと非常によく似ています-visについて説明しています
スケッチ。常にウェブと呼ばれるサービスがありますが、バックアップすることもできます
ミニAPIサーバーとデータベースを備えたコンテナによって。 想定されている
https://github.com/jwilder/nginx-proxyが前面に座ってリッスンしている
実際のポート80および443に。

現時点では、ローカルマシンを使用している場合でも、リモートサーバーを使用している場合でも、
.envを維持し、すべてを確認することを忘れないでください
そこで環境変数が設定されます。 たとえば、私が忘れてしまった場合
サブドメイン、コンテナは起動しますが、Webサーバーは壊れたままです。

default_envセクションを自由に使用できるので、すべての本番環境を使用できます。
変数が配置されていれば、サーバーに.env.distをコピーする必要はありません。
ローカルマシンでは、1つの変数を.envに入れるだけです。
ROOT_HOST = example.com.dev（または多分私はエクスポートすることさえできます
bashプロファイルのROOT_HOST = example.com.dev？）

要約すると、docker-compose.ymlのdefault_envセクションは
今説明している問題を解決しますが、さらにいくつかの優れた使用法を有効にすることもできます
シナリオ！

WDYT？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/745#issuecomment-282885661 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
。

docker-compose.yml内に「project_name」を含めると、スタックの問題が解決します。
複数のプロジェクトを処理する標準化されたツリーを備えたモノリスリポジトリがあります。これは多かれ少なかれ次のようになります。

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

明らかに現実の世界よりも複雑なので、docker-compose.ymlファイルを「projectA / projectB」フォルダーに移動するだけでは不十分です。

起動するプロジェクトを尋ねるCLIがルートにあり、プロジェクト名はdocker_compose.ymlの親フォルダーに直接依存しているため、競合が発生しています。

docker-composeコマンド（CLIスクリプト内にラップされている）を自分で作成しないため、コマンドに「-p」引数を手動で追加することはできません。
私たちの解決策は、CLIスクリプト内で常にproject_nameを生成することです。そのため、docker-composeを呼び出すときは、absolute_pathに基づいて常に「-p」がありますが、奇妙に聞こえます。

ここにいる人の中には、「ほとんどのプロジェクトでほとんどの場合動作します。docker-compose.ymlはプロジェクトのルートフォルダー内にあり、プロジェクトの名前は異なり、競合を回避します」と言った人もいますが、私は同意できません。この。 常にルートフォルダ内にあるとは限りません。

サービスのdocker-compose.ymlファイル（スケーリングを無効にする）で「container_name」を定義できるのに、docker-compose.ymlファイル自体の「project_name」をと同じレベルで定義できないのはなぜですか。 「バージョン」/「サービス」/「ネットワーク」/「ボリューム」？

これは、コンテナ名が明確になるようにscale使用する場合に必要と思われます。 （例： <project_name>_<container_name>_1 ）。

これは、DNSにコンテナ名を使用するときに役立ちます。

これが行われたことを期待してここに来ました。 がっかりしたまま。 3年以上

ええ、それはDockerの最も愚かなユーザビリティの問題の1つであり、修正されていません。

私たちはそれについて開発者と議論することに多くの時間を費やしました、そしてコンセンサスがあったとしても、それが悪いデザインであるという承認はありませんでした。

これに対する明らかなユーザーサポートがあるのでイライラしますが、開発者自身のユースケースに適合しないため、毎年毎年再ハッシュされています。

cliを使用してオプションを追加する必要がある場合、docker-composeのポイントは何ですか？
命名スキームのおかげで、いくつかのコンテナが上書きされました。

今日、私はプロジェクトに永続的な名前を付けるために、さらに別の.envファイルを使用してさらに別のdocker-composeプロジェクトを設定していました。 それで、最後にチェックしてから数年が経ちましたので、この問題をチェックすると思いました。 しかし、私が見る限り、ここでは何も新しいことはありませんか？ .env回避策を使い続ける必要があると思います。 私には、yamlファイルでプロジェクトに名前を付けることが最も基本的なことのように思えますが、まだ解決されていないため、これについては理解できないことがあると思います。

プロジェクト名を外部で（コマンドラインまたは変数で）指定する必要がありますが、 docker-compose.ymlファイル（他のすべてを完全に指定するファイル）でプロジェクト名を設定できないのは無意味です。 親ディレクトリ名、シェル環境、または特定の.env内の特定の行の存在に関係なく、プロセスが任意のdocker-compose.ymlファイルに基づいてサービスの特定のスタックをアドレス指定する必要がある場合がたくさんあります。 .envファイル。 CIジョブがプロジェクト名を継続的に「把握」する必要はありません。ジョブがプロジェクト名を抽出して使用できるように、プロジェクト名をdocker-compose.yml明確に記載する必要があります。

これはこのプロジェクトで何度も起こるようです。 Dockerは素晴らしいテクノロジーですが、開発者が実際に実際の経験を持っているのか、それとも18歳のハッカーで、自分たちが最もよく知っていると思っているのでしょうか。 人々は、常に回避策を探すのではなく、実際の作業にこのようなものを使用したいと考えています。

その間、チームはこの問題を無視していると思います。 Docker開発者を説得しようとすることは、それを穏やかに言えば本当に苦痛になる可能性があります。

明確な議論は、あまり意味をなさないいくつかの奇妙な論理で対抗されます。 同じ理由で全員がここに来るという現実世界のユーザーの意見は無視されます。 それは残念だ。

CIジョブがプロジェクト名を継続的に「把握」する必要がないようにします。ジョブがプロジェクト名を抽出して使用できるように、docker-compose.ymlに明確に記載する必要があります。

スタックの名前が「build1234」のようになっている、またはスタックの名前をdocker exec build1234_myservice script.shように別の場所でどのように使用したいのかという問題がありますか？

どのユースケースにも適合しないかもしれませんが、それを言ってもらうために...

私たちのセットアップでは、（クローン）プロジェクトをセットアップするときに.envファイルのみを変更します。 変更または動的構成が必要な場合は、 docker-compose.yml .env変数を再利用します。 利点は、変数が欠落している場合、docker-composeが警告（または失敗）することです。

私もこの問題に悩まされていたので、ワークフローを変更する必要があるとは言いたくありません。
基本的には、 docker-compose.ymlへの変更をソースコードへの変更のように扱いますが、 .envは単なる構成です。 しかし、プロジェクトに大きく依存するnetworkように、 docker-compose.ymlにはいくつかのオプションがあることにも同意します。 上記に戻ります。 ネットワークの.env変数を定義します。 🤐

私もこの問題に悩まされていたので、ワークフローを変更する必要があるとは言いたくありません。

自分の状況をもう少し考えました。 プロジェクト名を外部で設定することに実際には問題はありません。実際、これは-p <project_name>フラグを使用して行います。これにより、CI内のスタックの一意のインスタンスを分離し、複数のスタックを同時に実行できます。必要。 そのCIチェーンだけがそのプロジェクト名を知っている必要があるので、自動生成またはランダム（ただし既知）で問題ありません。 また、環境変数を使用してデフォルト名をオーバーライドすることに問題はありませんが、 .envトリックは自明ではありません。

ただし、プロジェクトの_デフォルト名_をどこかに明示的に定義しておくと便利な状況もあります。 では、なぜ親ディレクトリ名をこの名前のソースとして使用するのでしょうか。 それが私にとっての弱点です。 それはどこからでも取ることができます-親ディレクトリの選択は恣意的であり、多くの理由はありません（たとえば、ほとんどすべての私のプロジェクトでは、 docker-compose.ymlファイルはdockerというサブディレクトリにあります）。 したがって、任意にする場合は、多くの場合、ディレクトリのコンテンツから完全に独立している必要がある親ディレクトリ名に影響を与えて外部の副作用を作成するのではなく、ymlファイルなどのより明示的な場所に保存します（年に基づく）再利用可能なリソースでの作業経験）。

それはどこからでも取得できます-親ディレクトリの選択は恣意的であり、理由はあまりありません（たとえば、ほとんどすべてのプロジェクトで、docker-compose.ymlファイルはdockerというサブディレクトリにあります）。

ランダムID以外のものが必要な場合は、親ディレクトリに代わるものはありません。 少なくとも、スタックが「どこから来たのか」を知るチャンスがあります。
しかし、私もあなたに同意します。私たちのプロジェクトでは、 .envファイルがないと-互いにひどく衝突するtestsフォルダーにテストスタックしているからです。 そのため、私はdocker-compose.envというファイルを優先することを提案しました。これは私見でははるかに明確です。

あなたたちは、あなたが気にしないことを認めてこのバグを閉じるだけですか、それとも私たちの大多数が望んでいる信じられないほど単純なことを実装しますか？ 2。86年後です。 ポットを降ります。 あなたの決定を所有するか、あなたの間違いを修正してください。 しかし、あなたはそれを見たいです。 何もしないでください。

@matsamanと彼のコメントを

あなたたちは、あなたが気にしないことを認めてこのバグを閉じるだけですか、それとも私たちの大多数が望んでいる信じられないほど単純なことを実装しますか？ 2。86年後です。 ポットを降ります。 あなたの決定を所有するか、あなたの間違いを修正してください。 しかし、あなたはそれを見たいです。 何もしないでください。

「君たち」は誰ですか？ オープンソースでは、コミュニティが決定を所有し、他の人の間違いを修正します。 Dockerはオープンソースです。 泣き言を言う代わりに、プルリクエストを送信することを検討してください。

これがまだ実装されていないのも残念です。 しかし、オープンソースでは、貢献するか、辛抱強く待つかのどちらかです。

CLI引数：

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

不合格。

環境ファイル：

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

不合格。

ymlファイルにプロジェクト名が含まれる提案されたソリューション：

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

わーい！

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

O /

「君たち」は誰ですか？

@benjaminwoodこのプロジェクトのメンテナーです。 私たちが複雑な変化について話していて、誰もそれをする時間を見つけられないなら、あなたの議論は理にかなっています。

これは、ここでは当てはまらないことは明らかです。実装は、コードベースに精通している人にとっては非常に簡単で、外部の人にとってははるかに難しいでしょう。 ですから、誰もそれをする時間がないということではなく、むしろメンテナがそれをしたくない

ここに何度も投稿されている回避策はすべてよく知られていますが、すべての人に適用できるわけではありません。 そして、 docker-compose.yml機能でプロジェクト名だけが省略されている理由は、まだ答えが見つかりませんdocker-compose.yml 。 誰かが考えた場合、それはそこに属していないので、使用しないでください！ しかし、それに対する需要が圧倒的に明白である場合は、他人に対するあなたの意見を妨げないでください。

これを別の観点から見てみましょう。

docker-compose.ymlファイルのあるフォルダーにいる場合、スタックのプロジェクト名を確認するにはどうすればよいですか？
これはかなり基本的な質問ですが、簡単な答えはありません。

現在は（優先度でソート）：

• -pの値
• ご使用の環境からのCOMPOSE_PROJECT_NAMEの値
• .envファイルからのCOMPOSE_PROJECT_NAMEの値
• 現在のディレクトリ名

悪魔の擁護者になるために、なぜこのすでに混乱している設定に5番目のものを追加するのですか？

その決定にもかかわらず、現在の名前に関する「ドライラン可能な」情報があるはずです。 docker-compose configはそれがなく、スタックが実行されていない場合はdocker-compose psもありません。
たぶんdocker-compose createが現在利用可能な最良のオプションですが、完璧にはほど遠いです。

少なくともdocker-compose config --project-nameようなものが必要です。 現在、上記の場所を知り、正しい順序で確認する必要があります。

docker-compose.ymlファイルのあるフォルダーにいる場合、スタックのプロジェクト名を確認するにはどうすればよいですか？

繰り返しになりますが、使用したくない場合は使用しないでにとって良いです!! 何も変わらないので、混乱することはありません！

しかし、他の人が異なる要件を持っていることを受け入れることはできませんか？ 必要なのは、この論理的に欠落している部分が最終的に追加されることです。

悪魔の擁護者になるために、なぜこのすでに混乱している設定に5番目のものを追加するのですか？

混乱する可能性がある唯一の理由は、プロジェクト名が最初にdocker-compose.ymlから除外されたためです。 それ以外の場合は、すべてがそのファイルに含まれるようになります。 優先順位のリストを定義できます-問題ではありません。

現在、上記の場所を知り、正しい順序で確認する必要があります。

プロジェクトのDocker名がわからないのはなぜですか。また、それが自分に関係しているのはなぜですか。 そして、それがあなたをとても混乱させるなら、なぜあなたはあなたのすべてのプロジェクトで同じメカニズムを使わないのですか？

繰り返しになりますが、使用したくない場合は使用しないでください。 あなたがあなたの解決策に満足しているなら-あなたにとって良いです!! 何も変わらないので、混乱することはありません！

私の質問は、新しい機能の使用についてではなく、既存の機能の欠如についてでした。 プロジェクト名は、 docker-composeが特定のコンテナセットを開始および停止するために使用する唯一の関連情報です。
プロジェクト名はスタックのはないため、このスレッドの人々は間違ったコンテナーを強制終了することについて不平を言います。

しかし、他の人が異なる要件を持っていることを受け入れることはできませんか？ 必要なのは、この論理的に欠落している部分が最終的に追加されることです。

これを追加すると、事前にディレクトリ名を使用していたため、スタックの一部であるため、間違ったコンテナを強制終了することについて不平を言うでしょう。

混乱する可能性がある唯一の理由は、プロジェクト名が最初にdocker-compose.ymlから除外されたためです。 それ以外の場合は、すべてがそのファイルに含まれるようになります。 優先順位のリストを定義できます-問題ではありません。

実際には、これをBCウェイに追加することはできません。これは、ディレクトリ名としての優先順位を低くする必要があり、役に立たなくなるためです。 だから「プロジェクト名の取得方法」を聞いていました。

プロジェクトのDocker名がわからないのはなぜですか。また、それが自分に関係しているのはなぜですか。

私は通常ディレクトリ名を使用しますが、 .envカスタム値を使用することもあるため、プロジェクト名はアクションが実行されるコンテナを定義するため、関連性があります。

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

これにより、最初のスタックが強制終了されます。 ymlファイルのプロジェクト名と同じになります。

そして、それがあなたをとても混乱させるなら、なぜあなたはあなたのすべてのプロジェクトで同じメカニズムを使わないのですか？

私はそうです、私はデフォルトのdocker-compose機能を使用しています。 ほとんどの場合、ディレクトリ名は問題ありませんが、名前を変更する必要があるが、同じコンテナセットで作業を続けたい場合は、 .envファイルを追加します。

これを追加すると、以前にディレクトリ名を使用していたため、スタックの一部であるため、間違ったコンテナを強制終了することについて不平を言うでしょう。

それは意味がありません。 誰かがプロジェクト名をdocker-compose.yml追加しなければ、何も変わりません。 そして、彼らがそれを追加した場合、それは彼らがそこにそれを望んでいるからです！ 彼らがそれを必要としない限り、誰もそれを追加しません。

そして、たとえそうだとしても、すべてが順調です。 ここでどの問題を構築しようとしているのかわかりません。 あなたは物事を複雑にしすぎています。

プロジェクト名を構成できるすべてのオプションを組み合わせると、これが問題だと思います。 あなたはそれをするべきではありません。

ディレクトリに複数の名前付き作成ファイルがあると、優先度ツリーの4つのオプションのうち3つは無意味になります。 サブディレクトリを作成するように言わないでください。サブディレクトリ間で.envファイルを共有しているからです。

サブディレクトリを作成するように言わないでください。サブディレクトリ間で.envファイルを共有しているからです。

env_file使用されるアプリケーション固有の.envファイルを共有していますか？
または、 docker-compose使用するものですか？
それとも混ぜますか？

それは意味がありません。 誰かがプロジェクト名をdocker-compose.ymlに追加しなければ、何も変わりません。

それは問題ではありませんが、追加されると動作が大幅に変わります。

一時インスタンスを生成するために（つまり、アップグレードをテストするために）スタックを新しいディレクトリにコピーする場合、 docker-compose.ymlに触れる必要はまったくありません。 ただし、これがスタックの一部である場合は、 .envオーバーライドするか、 docker-compose.yml変更するかを決定する必要があります。

ええ、そもそも追加されるべきで

4つの名前付きcomposeファイル（同じディレクトリ内）が使用する共通の単一の.envファイルがあります。 環境変数はありません。 シェルスクリプトはありません。 私はただ作曲を使います。

私はこれを好む

docker-compose -f service1.yml up -d

代わりにそれはこのようなものです

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42これは、docker-composeコマンドごとに、おそらくcomposeファイル名に加えて、

サービスごとに1つのフォルダーを使用しても、一番上のフォルダーに.envファイルを保持することはできませんか？

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

プロジェクト名をファイル（-パス）に書き込むだけです😉

あきらめる。 このための顧客ベースが変わったことは明らかです。

私があなたに提案したことの何が問題なのか教えてください。

最初は同じ懸念がありましたが、利用可能な機能に合わせてワークフローを調整しました。

私たちのチームの誰もが、過去2年間に誤ってスタックを殺したことを覚えていません。 この方法で、約1.000個のコンテナーと1.000個の自動または手動の再デプロイで200を超えるスタックを実行しています。

私はここに参加したくありません...しかし、私は抵抗できません。

現在の状況を考えると「解決策」と、存在する可能性を考えると「正しい」解決策との間には非常に重要な違いがあります。 この問題に焦点を当てるべきなのは、「正しい」解決策を見つけることです。これは、私に関する限り、まだ同意しない人もいるかもしれませんが、かなり明白です。

@ schmunk42 ＆

私たちのチームの誰もが、過去2年間に誤ってスタックを殺したことを覚えていません。

私は尋ねなければなりません。 あなたは両方ともcodemix組織の一部であることがわかります。 あなたは同僚ですか？ 舞台裏で2人がrotflであるかどうか疑問に思い始めています。

現在は（優先度でソート）：

1. -pの値
2. ご使用の環境からのCOMPOSE_PROJECT_NAMEの値
3. .envファイルのCOMPOSE_PROJECT_NAMEの値
4. 現在のディレクトリ名

悪魔の擁護者になるために、なぜこのすでに混乱している設定に5番目のものを追加するのですか？

私が見ている問題は、現在使用可能な_すべての単一の値_が_環境固有_であるということです。 プロジェクト固有のオプションを提供する方法はありません。

1 +2。 コマンドを呼び出すユーザーが手動で提供する必要があります。

1. 共有できますが、実際には.envは無視し、正当な理由で共有しないでください。 （私は.env.example共有することでこれを回避しますが、それでも追加の手動手順が必要です。）
2. 事実上ランダムであり、ユーザー/環境に固有です。 （プロジェクト名を作成する必要があるため、これもフォールバックと見なします。同じ名前の異なるディレクトリに競合するプロジェクトが存在する可能性があるため、これはあまり良いフォールバックではありません。）

私の意見では、そしてこのスレッドの多くの人は、3から4の間に存在するオプションがあるはずです。このプロジェクトで使用されているdocker-composeファイルにデフォルトのプロジェクト名を指定でき、最初のプロジェクトとして使用されます。後退する。 この値は、このプロジェクトを展開するすべての人によって共有されます。 オプション1〜3はその値を上書きし、オプション4は指定されていない場合にのみ使用されます。

@benjaminwoodこの問題について誰も笑っていないことを保証できます。 はい、私たちはかなり長い間お互いを知っています、そしてそれは私たちが根本的に反対するのは初めてではありません。 ここの何人かのユーザーには迷惑に聞こえるかもしれませんが、それは私の意図ではありません。 実際、私は自分の経験を共有し、解決策を提案したいと思います。 私はこのトピックについて豊富な経験を持っていると思います。 この機能が提案どおりに導入された場合、セットアップで発生する可能性のあるエラーの膨大な原因が発生します。

@joshuajabbour

1. 共有することもできますが、実際には.envは無視し、正当な理由で共有しないでください。

これはセットアップによって異なりますが、すべてのプロジェクトリポジトリで無視されています。
ただし、ステージングおよび本番スタックのみのリポジトリでは無視しません。 あなたはでコミット名前を共有する場合はdocker-compose.ymlあなたもコミットすることができます.env （このファイルはのみですdocker-compose -何もないコマンド）

1. 事実上ランダムであり、ユーザー/環境に固有です。

docker-compose.yml値よりも多かれ少なかれランダムではありません。スタック構成を単一のファイルではなく、フォルダーとして表示する必要があります。 その場合、 .env名前を付けるか、サブフォルダー名を付けることができます。

最後にもう1つ選択肢があります。

docker stack deploy -c docker-compose.yml the-project-name

（*）スウォームモードでのみ使用可能

将来、プロジェクト名をymlファイルに配置する方法がわかりません。これは、スタック定義の概念と完全に矛盾し

@ schmunk42に感謝します。 このスレッドに表示されたすべての強い意見の中で、あなたとあなたは物事を非常にうまく処理したと思います。

セットアップで発生する可能性のあるエラーの膨大な原因が発生します。

擦れがあります。 問題を閉じます。

これはセットアップによって異なりますが、すべてのプロジェクトリポジトリで無視されています。 ただし、ステージングおよび本番スタックのみのリポジトリでは無視しません。

それで、他の誰もが望んでいるこの機能は、あなたの変わったリポジトリアーキテクチャを壊してしまうので、導入すべきではありませんか？

コミットあなたが名前を共有する場合はdocker-compose.ymlあなたもコミットすることができます.env （ -何もこのファイルが唯一のドッキングウィンドウ-コンコマンドのですが）。

ええと、私の.envファイルの唯一のものがCOMPOSE_PROJECT_NAMEだったとしたら、そうです。 しかし、コミットしたくない他の多くの_secure_変数が入力されています。 そして、それらをdocker-composeにenvironmentプロパティを使用してインポートします。 これが.envファイルの一般的な目的です...

私の提案では、ディレクトリから取得したデフォルトのプロジェクト名を上書きするだけなので、これがセットアップをどのように壊すのかはまだよくわかりません。 そして、それに依存している場合（リポジトリが複製されるディレクトリではなく、リポジトリにコミットされたディレクトリであるため）、docker-compose.yml設定によってどのようにオーバーライドされますか（これもコミットされているため）あなたのリポジトリに;あなたはあなたのシナリオで両方のものを制御します）？

@ schmunk42あなたの言うことは、「新しい機能は必要ない。それ以外の場合は、プロジェクトのセットアップが理解できなくなったからだ」ということです。

真剣に？ これは、これを必要とする他のすべての人になしでやってもらいたい理由です。

念のために言っておきますが、私もここにいます。 気軽に問題を解決してください。 ここでの議論は無意味になりました。

それで、他の誰もが望んでいるこの機能は、あなたの変わったリポジトリアーキテクチャを壊してしまうので、導入すべきではありませんか？

私は、それが追加のエラーの原因をもたらす可能性があるという懸念を表明しています。

ええと、私の.envファイルにあるのがCOMPOSE_PROJECT_NAMEだけだった場合は、そうです。 しかし、コミットしたくない他の多くの安全な変数が入力されています。 そして、environmentプロパティを使用してそれらをdocker-composeにインポートします。

使用secrets.envのためのものとを経由して、それをインポートenv_file 。
それはワークフローにどのように影響しますか？

これは、.envファイルの一般的な目的です...

本当です...しかし、問題はdocker-composeが.envファイルを乗っ取るということだと思います。

これらの変数に加えて、 IMAGE_VERSIONなどのdocker-compose.ymlのトップレベルで使用される変数を、 docker-compose.envというファイルに設定できるとしたら、どうでしょうか。

私はあえてCOMPOSE_COMMAND_ENV_FILENAME=.envを提案したことはありません-今まで:)

私はまだこれがあなたのセットアップをどのように壊すのか本当に理解していません...

それがすぐに壊れないのは事実ですが、それは単に私の最初のポイントについてであり、さらに多くのオプションを導入しています。

複数のファイル-f docker-compose.A.yml -f docker-compose.B.ymlを使用することを考えてみてください。たとえば、Aがプロジェクトであり、ディレクトリごとにプロジェクト名に依存しているとします（制御するため、これを行います）。 project_name: extraの追加サービスのセット。プロジェクト名をCOMPOSE_PROJECT_NAME=testingで上書きした.envファイルのあるフォルダーでテスト中に誤って導入されました。

しかし、 .envファイルなしで開始されたプロジェクトは、 extraという名前になります。 💥

複数の*.envファイルを含む、複数のレベルでファイルをマージしています。これは非常に有効なユースケースです。

真剣に？ これは、これを必要とする他のすべての人になしでやってもらいたい理由です。

警告：トピックから少し外れていますが、Dockerに関連しています...

• 「本当に必要だとは思わない」
• 「必要以上のレイヤーがあります。複雑さが増します」

@mikehaertl私はあなたがそれをこのように見ているのだろうかと本当に思っています;）

みなさん、

私たちはこのスレッドで熱心な議論を取り上げました（それを礼儀正しく心のこもったものにしてくれた皆さんに感謝します！）そしてプロジェクト名はComposeファイル内に属していないと基本的に信じていますが、私たちは何を思いついたのですか？私たちは、次のPRで合理的な中間点であると信じています：＃5378。 とは言うものの、それがあなたのニーズに確実に答えられるように、これについてのフィードバックをいただければ幸いです。

要点は次のとおりです。

• 作成ファイル内にx-project-nameエントリを追加できます。 このキーはデフォルトでは無視されます。
• 環境（または.envファイル）にCOMPOSE_X_PROJECT_NAMEが設定されている場合、ComposeはComposeファイル内のx-project-nameエントリからプロジェクト名を取得しようとします。
• このオプションの優先度は、 COMPOSE_PROJECT_NAMEおよび--project-nameよりも低くなります。

これに関する質問や懸念に喜んでお答えします。

@ shin-では、機能をアクティブにするには、 COMPOSE_X_PROJECT_NAMEを1に設定する必要がありますか？

もしそうなら、 COMPOSE_ENABLE_X_PROJECT_NAMEも考えるべき名前かもしれませんが、これらは私の2セントです-とにかくそれを使用しません😄

@ schmunk42 「truth-y」の値ならどれでも機能しますが、そうです、それがアイデアです。

@matsamanかっこいい、便利で実用的なフィードバックをありがとう。

エンドユーザーに変数を設定するかパラメータを呼び出すように指示する必要があると言う代わりに、エンドユーザーに変数を設定するかパラメータを呼び出すように指示する必要があると言っています。

正直なところ、そして本当に何の意味もありませんが、あなたがこれをどのように解決策と考えているのか想像できません。

@ shin-この変更がどのように有用な違いをもたらさないかを説明します：

作成ファイルでプロジェクト名を検索できるように環境変数を設定する必要があることは、プロジェクト名自体に環境変数を設定することとほぼ同じです{作業量、忘却のリスク、および利便性}。

作成ファイルにプロジェクト名を設定することの要点は、環境変数を使用する必要がないようにすることです。 プロジェクト名環境変数の優先順位を使用して、作成ファイル内のプロジェクト名をオーバーライドするオプションをユーザーに与えることができます。

BCを壊さず、上記のようにマージ中にエラーが発生するのを回避できるため、非常に優れたソリューションだと思います。

作成ファイルでプロジェクト名を検索できるように環境変数を設定する必要があることは、プロジェクト名自体に環境変数を設定することとほぼ同じです{作業量、忘却のリスク、および利便性}。

そうではありません。この設定は、環境内でグローバルに1回行うことができます。すべてのプロジェクトでこれを行う必要はありません。

そうではありません。この設定は、環境内でグローバルに1回行うことができます。すべてのプロジェクトでこれを行う必要はありません。

私はあなたがあなたのコンピュータ上でスポーンするあなたのすべてのシェルでグローバルに意味していると仮定しています。 そうすると、まったく関係のないプロジェクトで望ましくない動作が発生する可能性があります。 また、開発者がバージョン管理からプロジェクトをプルし、環境変数の設定を忘れた場合にも混乱が生じます。

作成ファイルにプロジェクト名を含めることの最も重要な目標の1つは、作成プロジェクトに関係するすべての変数がバージョン管理に格納されるようにすることです。

@nhooey @matsaman
これは特に、同じディレクトリに複数の作成ファイルがあり、 .envファイルソリューションを選択できない人を支援することを目的としています。 プロジェクトでこれを常にオンにする必要がある場合は、 .envファイル、 .profile 、またはx-project-nameが常に使用されるようにするその他の場所に簡単に設定できます。考慮に入れます。

エンドユーザーに変数を設定するかパラメータを呼び出すように指示する必要があると言う代わりに、エンドユーザーに変数を設定するかパラメータを呼び出すように指示する必要があると言っています。

これに関する私たちの主な関心事は、「エンドユーザー」が独自のプロジェクトを持っており、名前の競合を絶対に避けたいということです。 その点で、彼らはディストリビューターではなく、プロジェクト名を管理する必要があります。 「ターンキー」プロジェクトを顧客に出荷する場合、関連する.envファイルにCOMPOSE_X_PROJECT_NAMEを設定することも同様に簡単です。したがって、正直に言うと、これのどの部分が懸念事項であるか混乱しています。

そうすると、まったく関係のないプロジェクトで望ましくない動作が発生する可能性があります。

例を挙げていただけますか？ シェルにCOMPOSE_X_PROJECT_NAMEを設定しただけでは、望ましくない動作は考えられません。

作成ファイルにプロジェクト名を含めることの最も重要な目標の1つは、作成プロジェクトに関係するすべての変数がバージョン管理に格納されるようにすることです。

なぜ.envを使用できないのですか？ .envをバージョン管理に保存することを禁止する人は誰もいません（はい、それは一般的ではありません）。

最初は.envでした。 あなたは明らかに会話全体を逃しました。

@matsamanあなたは真剣にあなたの態度を

混乱のいくつかを明確にするために

あなたはすでにそれをすることができます

以前は、環境変数を使用してプロジェクト名を設定できました。 新しい環境変数は名前ではなく、作成ファイルにプロジェクト名を設定できる機能を有効にするトグルです。

私はあなたがあなたのコンピュータ上でスポーンするあなたのすべてのシェルでグローバルに意味していると仮定しています。 そうすると、まったく関係のないプロジェクトで望ましくない動作が発生する可能性があります。

「他のプロジェクト」という意味では、「作曲されていないものがこれを読んで壊れてしまう」というのは現実的ではないと思います。 すべてのシェルにはたくさんの環境変数が設定されています。 環境変数は、「COMPOSE_X_」として適切に名前空間が付けられています。

「他の作成プロジェクト」を意味する場合、この変数が必要な理由について実際に議論していると思います。 この機能がデフォルトで有効になっている場合、現在のデフォルトの動作に依存している人はだれでも壊れてしまいます。

どちらでもない場合は、明確にしてください。

また、開発者がバージョン管理からプロジェクトをプルし、環境変数の設定を忘れた場合にも混乱が生じます。

プロジェクトが特定のプロジェクト名でのみ機能する場合は、他にも問題があると思います。 プロジェクトが単一の名前でのみ機能する場合は決してありません。

これは、プロジェクト名を作成ファイルに入れないためのもう1つの引数と考えています。 プロジェクト名が作成ファイルにある場合、2つのプロジェクトで同じ名前が使用され、競合が発生して両方のプロジェクトが破損する可能性があります。 名前は、他のプロジェクト名がすでに使用されていることを知っている開発者が実際に設定する必要があります。

残念ながら、1年以上前にすでに述べた理由から、これは私にとっても役に立ちません。

環境変数を含むソリューションでは、最初にそれらを作成する方法を知る必要があるユーザーが必要になります。 信じられないかもしれませんが、ターミナル内で全員が働いているわけではありません。 繰り返しますが、リポジトリに.envを配置することは私にとってオプションではありません。

docker-composeの美しさはupです。 その通話を設定する方法についての説明ではありません。

@fiveanddone

繰り返しますが、リポジトリに.envを配置することは私にとってオプションではありません。

それを拡張できますか？ 技術的な知識が少ないユーザーについては完全に耳にしますが、ユーザーがコードや環境と対話することを意図していない場合、プロジェクトに.envファイルを含めることが問題になるのはなぜですか？

@ shin-ええ、問題ありません。

そのファイルをリポジトリに含めている場合もありますが、常に機能するとは限りません。 私のユースケースは主に、開発者の技術的知識が大きく異なる可能性があるWeb開発に関係しています。

.envは、他のフレームワークで使用されるパラメーターが格納されています。 .env内の変数のいくつかは、SMTPなどの外部サービスの資格情報です。 私のチームの開発者のほとんどは、独自の.envファイルを使用して、これらのサービスを独自のエンドポイントにポイントしています。 .envがない場合は、デフォルトがあります。

CSSを変更したいだけの技術的でない開発者にとって、アプリケーションは.envファイルがなくても問題なく動作します。 これは、すべてのプロジェクトフォルダに同じ名前が付けられているわけではないことを前提としています。 :)

それほど多くはないように思われるかもしれませんが、全国にまたがる複数の開発者やデザイナーと仕事をしている場合は、シンプルであるほど良いでしょう。

Dockerは私の人生をとても楽にしてくれて、このプロジェクトにとても感謝していますが、このスレッドの周りのフラストレーションに関係することができます。

@fiveanddone洞察力をありがとう！ それで、 .envファイルが代わりにdocker-compose.env （または同様のもの）と呼ばれた場合、それはあなたの懸念を軽減しますか？

@ shin-

はい、それは私のユースケースに当てはまります。

envファイルはDockerComposeによって自動的にロードされますか？

そうでない場合、 docker-compose.envを自動的にロードできますか？

@nhooey .envという名前の場合、envファイルは自動的にロードされます。 また、サービスごとに個別にenvファイルを指定することもできます。 ドキュメントを参照してください。

.envという名前の場合、envファイルは自動的にロードされます。 また、サービスごとに個別にenvファイルを指定することもできます。 ドキュメントを参照してください。

ここではニトピッカーではありませんが、それは実際には正しくありません。 そして私見は、トピック全体の誤解の最大の原因です。

.envの変数は、明示的に転送しない場合、いずれかを使用

env_file: 
  - .env

または

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

.envファイルは自動的にロードされます。はい。ただし、追加の構成を行わないと、これらのComposeCLI環境変数にのみ適用され

これをデフォルトでdocker-compose.env名前変更することを強くサポートします。これは、その変数であるため、1つのENV

（それを礼儀正しく心のこもったものにしてくれた皆さんに感謝します！）

私はあなたの言うことを聞きます、そして私はいつも私の落ち着きを保つとは限らないという罪を犯しています。 そのために残念。 いくつかのコメントは時々本当に私を始めさせます...それでうまくいくでしょう。

プロジェクト名が作成ファイルにある場合、2つのプロジェクトで同じ名前が使用され、競合が発生して両方のプロジェクトが破損する可能性があります。

これに関する私たちの主な関心事は、「エンドユーザー」が独自のプロジェクトを持っており、名前の競合を絶対に避けたいということです。 その点で、彼らはディストリビューターではなく、プロジェクト名を管理する必要があります。

@ shin-これは一般的に合意されているように聞こえますが、 docker-compose.ymlは常にプロジェクトの一部であり、プロジェクトリポジトリに存在します。 それは必ずしも真実ではないと思います。 docker-compose.yml共有しない人

また、「名前の競合を回避する」について：プロジェクト名との名前の競合の代わりに、ファイルシステムレベルで（IMO）より重大な名前の競合が発生しました。 .envは、プロジェクトがプロジェクトを定義するために使用する一般的な名前です。アプリ固有の設定。 開発者が本当にそうしたいのでない限り、Docker設定で汚染されるべきではありません。 ただし、この決定は開発者に任せる必要があります。

提案は次のとおりです。プロジェクト名に他の2つのオプションを追加し、 docker-compose.yml V4で.env使用を非推奨にするのはどうですか？ 一つは、 project_nameでdocker-compose.yml 、別のファイルである.dockerproject名のみが含まれていますし、リポジトリに提出すべきではない決して。 ローカルファイルである必要があります。

優先順位についての私の提案は次のとおりです（最初に最高）：

• -p CLI引数
• .dockerprojectファイル
• project_nameでdocker-compose.yml （あれば、避けるべきであるdocker-compose.ymlプロジェクトと一緒に配布されます）
• 環境からのCOMPOSE_PROJECT_NAME
• COMPOSE_PROJECT_NAMEから.env （非推奨）
• ディレクトリ名

このようにして、誰かが分散docker-compose.ymlハードコーディングした場合でも、エンドユーザーは常に.dockerprojectプロジェクト名を上書きできます。

更新： .dockerproject代わりに.dockerenvまたはdocker.envを使用して生活することもできます。 ただし、問題を解決するには優先順位を高くする必要があります。ここでは、 docker-compose.ymlハードコードされたプロジェクト名をオーバーライドする必要があります。

こんにちは、みんな、

まず、このケースを見てくれた@dnephinと@ shin-に感謝します。 @ shin-が送信した変更は、この問題を解決するための大きな一歩のように見えます。

次のユースケースについて、テストプロジェクトでPR 5378を検証しました： A default project name defined by the project, that can be checked in （https://github.com/docker/compose/issues/745#issuecomment-282858900）。 そのために、さまざまな可能性を示すgitリポジトリを作成しました： https ：

ユースケースを部分的にカバーしているPR＃5378を見つけました。 問題は、ソリューションにCOMPOSE_X_PROJECT_NAME env変数が必要なことです。 可能な解決策：

1. プロジェクトのフォルダーにenv変数を永続化します。 .envファイルを試しましたが、docker-composeが別の場所から呼び出された場合は機能しません（コマンドの例、ファイルの作成を参照）
2. COMPOSE_X_PROJECT_NAMEをグローバルに定義します（.profileまたは同等のもの）。 それは機能しますが、プロジェクトで指定することはできません。つまり、ユースケースdefined by the project, that can be checked inソリューションではありません。
3. 別のオプションはありますか？

うまくいけば、ここで取り上げるユースケースを説明することができました。

親愛なるメンテナ、docker-composeファイルにオプションのproject_nameプロパティを導入するPR＃5369によってユースケースがどのように解決されるかを検討してください。 このプロパティの優先度は低くなりますが、環境や作業ディレクトリには依存しません。

1. 別のオプションはありますか？

このオプションdocker-compose --project-directory <PATH> （代替作業ディレクトリを指定）があります。 .envファイルでも機能するはずです。

別の微妙なユースケースをミックスに追加するには：
私のユースケースでは、2つのリポジトリがあります。1つはメインプロジェクト（ビルド/デプロイに使用）用で、もう1つはdevops（Dockerfile、docker-compose.ymlなどを含む）用です。
現在のセットアップでは、メインプロジェクトリポジトリはルート./にあり、devopsリポジトリはサブディレクトリ./devops/にチェックアウトされています。

この設定では、.envファイルの使用は次のようにする必要があるため機能しません。

docker-composeコマンドが実行されるフォルダー（現在の作業ディレクトリ）に配置されます。
（ドキュメント参照）

docker-compose -f devops/docker-compose.ymlとして呼び出されるため、これは機能しません。
もちろん、ここに-pパラメーターを追加することもできます。これは現在使用しているものですが、上記で参照したように人為的エラーが発生しやすくなります。

.env（または提案されたdocker-compose.env）ファイルをdocker-compose.ymlと同じディレクトリから読み取ることができれば、そこでプロジェクト名を定義することでうまくいくでしょう。

docker-compose.yml内でenv_fileディレクティブを使用しても機能しません。これは、これらのenv変数がコンテナー内でのみ適用され、コンテナーの作成には適用されないためです。

最終的に、私の目標は、実際のプロジェクトコードベースを汚染しない方法で、devops関連のファイルを自己完結型に保つことですが、そのリポジトリと並行してアクセス/実行することはできます。

このオプションがありますdocker-compose--project-directory（代替の作業ディレクトリを指定します）。 .envファイルでも機能するはずです。

@ schmunk42は良いショットかもしれませんが、 --project-directoryは.envファイルでは機能しません。 次のように試しましたが、.envファイルは無視されました（プロジェクトファイル）：

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

今後は、会話に貢献しないコメントを建設的に削除していきます。 私は子供たちと交流することに興味がありません。

設定可能な.env名を持つことについて
どの.envファイルを使用するかを指定する環境変数を持つことの問題は、それが本質的に循環依存であるということです。 環境変数の解釈方法に例外を導入する必要があります。これは、賢明ではありますが、本質的に直感に反します。

.env名前自体について
.env名前が多数のソフトウェアやフレームワークで使用されており、通常はバージョン管理でコミットすることを意図していないことは、今では明らかです。 重大な変更を加えることに非常に敏感ですが、前者が存在しない場合は、 .envファイルへのフォールバックを使用して代替名（例： docker-compose.env ）を導入することができます。他のユーザーと共有される場合があります。

作成ファイルにproject_nameを追加する場合
私たちはすでにこれに対する私たちのスタンスを何度か繰り返しました-私たちがその変更を行うことに反対しているいくつかの理由については、ダニエルの最新のコメントを参照してください。 それは難しいことではありません。 それは私たちがそれについて考えなかったということではありません。 私たちはそれを評価するのに多くの時間を費やしました、そして私たちはそれを（この形で）追加することを正当化する結果としてプロジェクトの品質があまりにも悪くなるだろうと感じています。 現実的に言えば、＃5378は、オプトインおよび下位互換性のある方法でこれを機能させるために行うことができる最善の譲歩です（編集：もちろん、これらのパラメーター内でその提案を改善する提案を受け入れます）

--project-directory
少し正接ですが、このオプションは現在少し壊れていることを私は知っています。 振り返ってみると、解決するよりも多くの問題が発生するため、まったく追加しないほうがよかったと思います。 私はそれが修正可能かどうかを確認するためにしばらく時間を費やしますが、それは本当に信頼できないものにする奇妙なエッジケースがたくさんあります。

そうは言っても、 docker-compose.env +＃5378が満足のいく解決策ではない人はいますか？ 私はそれがあなたの好ましい解決策ではないかもしれないことを理解しています、しかし私はそれがあなたが対処できる合理的な譲歩をしているのかどうか尋ねています。

冗談はさておき...

ダニエルの最新のコメントが「プロジェクトの質」にどのように関係しているかはまだわかりません。 さらに、辞書にキーを追加しても下位互換性が損なわれることはないというのが一般的な経験則です。 プログラマーがそうではない方法で物事を実装した場合は常にありますが、私は余談です。

プロジェクトの「名前」はツールの多くの側面の基本であるため、 project-name （またはその他）フィールドを必要とするキャンプは正当化されると思います。 このキャンプの人々は、環境変数やフラグのようなコマンドのようなより一時的な解決策の問題を回避するために、この名前を石のどこかに単に書き留めたいと思うかもしれません。

これが建設的なものであったことを願っています。

@estarterこれはバグだと思いますが、別の問題を開く価値があるかもしれません

実際、これはディレクトリPR_5378の.envファイルで機能すると思います。

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

作成ファイルにproject_nameを追加する場合

@ shin-決定はすでに行われているようです。 しかし、私はまだ背景を理解しようとしています。 私は以前にこれを尋ねましたが、答えは得られませんでした（これが、議論が私にとってとても迷惑だと感じた理由の1つです）。

我々が持っているなぜあなたは、私が理解して助けをしてもらえcontainer_nameとさえnetworkでdocker-compose.yml ？ 1つ目は、潜在的な競合の原因になる可能性もあります。 そして後者は非常にホスト固有です。 あなたの論理に従うと、それらの2つ（および他の）もそこにあるべきではありません。 project_nameとの違いがわかりません。

この質問を二度と無視しないでください。

@ michael-k project_nameはcontainer_nameと同じだと言っていますか？ そういえば、1つのプロジェクトが複数のコンテナで構成されている可能性があることをお知らせします。 それとも私はあなたを誤解しましたか？

network場合、必ずしもホスト固有である必要はありません。 プロジェクトで、1つのコンテナが他のネットワークと相互作用する中央の分離されたネットワークが必要な場合が多くあります。 そして、その構成はdocker-compose.yml保存されます。

@AyushyaChitranshあなたは誤解しました。 問題は、 container_name 、 networkなどがdocker-compose.ymlのに、 project_nameがそこにあることを許可されるべきではないのはなぜですか？ それらはすべて、共有すべきではない競合またはホスト固有の構成の同じ可能性を共有します。

@aanand私はこの機会について知っています。 また、コンテナ名についても同じことが言えますが、作成ファイルにコンテナ名を設定する機会はありますか？

はい、でもそれを追加するのは良い考えではないと思います。

関連するディスカッションからdocker-composeファイルでネットワーク名を指定します。

@estarterこれはバグだと思いますが、別の問題を開く価値があるかもしれません

@ schmunk42メンテナがこれを認識していることがわかりますのコメントのOn --project-directoryに加えて、＃4709、＃4933、＃4841を参照してください

実際、これはディレクトリPR_5378の.envファイルで機能すると思います。
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

--project-directoryが-fパラメーターに影響を与えると仮定しました。
実際にはそうではありません、このコマンドはIOError: [Errno 2] No such file or directory: u'./docker-compose.yml'与えます

--project-directoryが-f影響を与えないのは非常に良いことです。そうでなければ、 --project-directoryと複数のdocker-composeファイルをすべて異なるディレクトリで使用することは悪夢になると想像してください。

私が解決した問題と見なしていることについて多くの審議が行われているのを見て、私は非常に驚いています。

これは私が見慣れている優先順位です：

1. ハードコードされている
2. CLIオプション
3. 環境
4. project.rc
5. 正気のデフォルト

project_name 、現在、オプション＃1もオプション＃4もありません。 これは人々が直面している根本的な問題であり、下位互換性のある方法で解決するのは簡単なようです。

私たちは純粋さについて哲学的な議論をしているようですが、それは役に立たないかもしれません。 一方、非常に一般的なOSSカスケード構成スキームを使用すると非常に役立ちます。

私たちは純粋さについて哲学的な議論をしているようですが、それは役に立たないかもしれません。

しかし、この議論を持つことは実際には目的ではありません。 当初から、Composeファイルでのプロジェクト名の定義に関して私たちがどこに立っているかについて非常に明確でした。

しかし、これについては透明にさせてください。 これはdocker-composeでは決して起こりません。 それがこの問題に対して受け入れても構わないと思っている唯一の解決策である場合は、プロジェクトをフォークして自分で実行するという非常にOSSプロセスを実行する必要があります。 コードは利用可能であり、非常に寛容なライセンスで共有されています。

docker-compose.ymlにcontainer_name、さらにはネットワークがある理由を理解するのを手伝っていただけませんか？ 1つ目は、潜在的な競合の原因になる可能性もあります。 そして後者は非常にホスト固有です。 あなたの論理に従うと、それらの2つ（および他の）もそこにあるべきではありません。 project_nameとの違いがわかりません。

container_name場合、そのオプションはプロジェクトの存続期間の非常に早い段階で導入されました。 @ schmunk42が指摘したように、
networkに関しては、あなたの心の中でどのように比較されるのか完全にはわかりませんか？

私が言及したオプション＃4はどうですか？ ローカルディレクトリ固有の設定に.docker-composeを導入するという話を見ました。 これは、 _x_環境フラグ（環境管理が必要）を導入するよりもはるかに望ましい（imo）でしょう。

次のようになります。

# <my-project-dir>/.docker-compose
project_name: foobar

上記は環境変数オプションとは異なり、優先順位リストの下位にあります。

これは私のユースケースをうまく解決し、リストから別の標準構成パスをチェックします。

@thedeeno私たちの考えでCOMPOSE_PROJECT_NAME 、 .envファイル内のCOMPOSE_PROJECT_NAMEは、すでにそれを達成しています（アウトラインと同じ優先順位で）。 しかし、我々はあなたを聞いた上で.env 、我々が検討している理由である名前のお粗末な選択、というdocker-compose.env代替として。 それはあなたのために働きますか？

私たちの考えでは、.envファイル内のCOMPOSE_PROJECT_NAMEはすでにそれを達成しています

@ shin-これは私たちが同意しないところです。 私はそうは思わない。

私は個人的に.envファイルを

これは、上記のnumber 3環境ベースの構成を支援するのに最適です。

環境にプロジェクト名を所有させたくない場合のために、エスケープハッチ（ number 4 ）は提供されません。

私の場合、開発者はそれぞれ独自の.envファイル（VCではない）を持っています。 docker-compose.yaml注入するための秘密が含まれています。 これが大好き。

ただし、プロジェクト名は一部のツールと強く結びついているため、開発者がプロ​​ジェクト名を制御することは望ましくありません。 .envはバージョン管理されていないため、このアプローチでは開発者に手動でCOMPOSE_PROJECT_NAMEを設定させる必要があります。 それは秘密ではないので、他の人とは異なります。

残念ながら、 .envのデフォルトのソースパスを変更するだけでは、ここでは役に立ちません。 .envが自動的に供給されるのが大好きです。 プロジェクト名をそのように指定したくないだけです。

私の練習から1つのユースケースを示します：

.envファイルを使用して画像のバージョンを指定し、奇妙なsed / awk / perl /その他の解析を回避するために、CIの値を上書きするだけです。

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

後でdocker-compose.yml 、画像は次のように指定されます。

    image: my.registry.example.net/app:${APP_VERSION}

この種の変数がさらに必要な場合は、複数の.envファイルがサポートされていない限り、解析を行う必要があります。

したがって、おそらく、 docker-compose.env.d/*または.docker-compose.env.d/*またはdocker-compose.d/*ような「ディレクトリ」サポートも追加します。

ただし、そのようなglobは、エディターのバックアップ（ *~ 、 *.bak ）のマッチングの問題を即座に引き起こす可能性があるため、代わりに拡張機能を使用することをお勧めします： docker-compose.env.d/*.sh

...しかし、繰り返しになりますが、 docker-compose.ymlで構成可能にするだけで、どのルートレベルの.envファイルがロードされますか、それとも鶏が先か卵が先かという問題が発生しますか？ 構成パーサーがどのように機能するかわかりません:)

少しオフトピックですが、 COMPOSE_PROJECT_NAME envではプレフィックスを完全に制御できません。それでも、 A-Za-z0-9_に一致するように削除されます...プレフィックスに-を使用したかったのです。 （私は今これを報告した場所を見つけることができませんが、それは対処されていません）

docker自体が制限するのと同じ文字を許可するのは論理的です。

@glenscこれは環境を管理するための多くのインフラストラクチャです。 私は個人的にそれがdocker-composeの責任だとは思いません。

私が他のプロジェクトで行っているのを見たのは、自動的に.env

@glensc @thedeeno理想的には、2つの*.envファイルがあります。1つは他のユーザーと共有するためのもので、もう1つはプライベートに保たれ、両方が同じ変数を定義する場合、後者が前者をオーバーライドしますか？

先週のコメントで、構成可能な.env名前について説明しました。

パブリックdocker-compose.env （プライベート.env自動ソーシングしながら）を持つことは私たちにとって素晴らしいことです！

これをrcファイルのように扱い、ソース管理をコミットします。

パブリック/プライベートのenvファイルがあると、ここに記載されているほとんどのユースケースが解決する可能性が高いと思います。 -がプロジェクト名でも許可されるとしたら、それは素晴らしいことです。

@ thedeeno @ glenscパブリックENVファイルの値をオーバーライドするプライベートENVファイルが必要なユースケースを教えてください。

シークレットはコンテナに自動転送されないため、 docker-compose.envで定義しないでください。 それでも.envファイルを使用して、それを使ってやりたいことができます。 しかし、 docker-composeとスタック内のコンテナーを混在させるのは、私には混乱しているように見えます。

@ schmunk42私にはそのユースケースがないので、そこではあまり役に立ちません。 project_nameをバージョン管理にコミットする必要があります。 docker-compose.env解決します。

私があなたの2番目の段落に従うかどうかわかりません。 シークレットには.envを使用し、手動でdocker-compose.yaml挿入します。

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

これ${variables} 、 image値に対して${variables}を定義する場所が.envファイルのように見えるからです。

@glensc同意しました！

しかし、代わりに、 docker-compose.override.envを提案して、 ymlファイルの現在のオーバーライド機能に合わせます。

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

私があなたの2番目の段落に従うかどうかわかりません。 シークレットには.envを使用し、docker-compose.yamlに手動で挿入します。

@thedeeno私はあなたがこれをしていると思います：

environment:
  - ${SECRET_VAR_FROM_DOTENV}

これはdocker-compose.override.envでも可能です。 または、次のことができます。

env_file:
  - .env

よりdocker-compose固有のものを優先して.envを削除することを提案していますか？
道？

.envの自動ソーシングをスキップすると、私の悪影響になります
チームのワークフロー。 他のツールについては、このファイルに依存しています。 私たちは結局
私たちの秘密を2つに入れます（.envとあなたが提案しているこの他のファイル）
docker-composeが.envの表示を停止した場合に配置します。

1:15トビアス・ムンクの木、2017年11月23日には[email protected]
書きました：

@glensc https://github.com/glensc同意しました！

しかし、代わりに、docker-compose.override.envを提案してそれを調整します
ymlファイルの現在のオーバーライド機能。

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

私があなたの2番目の段落に従うかどうかわかりません。 シークレットには.envを使用し、
docker-compose.yamlに手動で挿入します。

@thedeeno https://github.com/thedeeno私はあなたがこれをしていると思います：

環境：

• $ {SECRET_VAR_FROM_DOTENV}

これはdocker-compose.override.envでも可能です。 もしくは、あなた
出来ました：

env_file：

• .env

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/745#issuecomment-346538315 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
。

よりdocker-compose固有のものを優先して.envを削除することを提案していますか？
道？

必ずしもそうではありません、BCのためにdocker-compose 、まだ見て可能性が.env他はと同じ、見つからない場合はfig.yml一回。 次の場合を決定するのは難しいかもしれませんが：

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.envは最後のケースでは使用されませんが、一部のユーザーは.envをオーバーライドとして使用し、他のユーザーはフォールバックとして使用するため、最初の2つを処理する方法は未定です。

私にとって、.envはすべての場合に使用する必要があります。 特別な意味を持つファイルです
より広い生態系で。

3番目のケースでは、優先順位が最も低いファイルだけです。

必要なのは、プロジェクト名をソース管理にコミットする方法だけです。 私はしません
特に、より洗練されたカスケード環境に注意してください
管理。 私は実際にこのプロジェクト名戦略には何もなかったほうがいいと思います
環境変数を使用します。

構成ファイルがテーブルから外れていて、コミットする方法がある場合
あなたが取っているこのenvカスケードを持つproject_name私はそれを喜んで使用します
でも！

1:31トビアス・ムンクの木、2017年11月23日には[email protected]
書きました：

よりdocker-compose固有のものを優先して.envを削除することを提案していますか？
道？

必ずしもそうとは限りませんが、BC docker-composeの場合、次の場合でも.envを確認できます。
fig.ymlと同じように、他のものは見つかりません。 かもしれませんが
次の場合を決定するのは難しいです。

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

最後のケースでは.envは使用されませんが、処理方法は未定です。
最初の2つに、一部のユーザーは.envをオーバーライドとして使用し、他のユーザーは
後退する。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/745#issuecomment-346539891 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
。

ネットワークに関しては、あなたの心の中でどのように比較されるのか完全にはわかりませんか？

@ shin-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

docker-compose.ymlをレポにコミットしたことがないので、間違っていると思います。 常にホスト固有の設定が含まれています。 プロダクションの開発では、まったく異なるコンテンツが含まれる可能性があります。

私は「4project.rc」のファンですが、おそらく別の形式の代わりにdocker-project.yamlようなものを使用するでしょう。 これはまさに元の問題が説明していることです。 私に関する限り、composeファイルにプロジェクト名を入れることについての議論は別の問題にあるべきです。

必要なのは、プロジェクト名をソース管理にコミットする方法だけです。

これはまだ私にはわからない点です。 ハードコードされた単一のプロジェクト名を要求する理由はないはずです。 一貫した名前を期待する外部ツールがある場合、そのツールがdocker-compose呼び出す前にプロジェクト名を設定しないのはなぜですか？

my_project_network_on_my_localhostは私には間違っているようです。 外部ネットワークでプロジェクト名が必要なのはなぜですか？ 作成プロジェクト名と一致する必要はありません。

my_project_network_on_my_localhostは私には間違っているようです。

これはほんの一例です。 ローカル開発マシンと本番サーバーのネットワーク設定が異なります。 docker-compose.yml他の多くの設定も、本番環境とは定期的に異なります。たとえば、プロジェクト固有のものを構築したり、データベースを維持したりするためにユーティリティコンテナを定義しています。

私が理解したように、最初はdocker-compose （またはより良いfig ）の背後にある主なアイデアは、複雑なコンテナセットアップ用の長いdockerコマンドラインオプションをすべてうまく整理すること1つのオプションが省略されています。 しかし、私はどういうわけか、これがその背後にある主要なアイデアではなくなったことを見逃したようです。

docker-compose.ymlの他の多くの設定も定期的に本番環境とは異なります。たとえば、プロジェクト固有のものをビルドしたり、データベースを維持したりするためにユーティリティコンテナーを定義しています。

ここでも同じワークフローがあります。 私たちの場合、「一般的な」docker-compose定義はほとんど何も要約し
開発設定の主要部分は別のファイルで定義され、自動マージは.envファイルを介して行われます。 テストのセットアップについても同じです。

私たちの場合はフォルダにあるので、次のようなことができます

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

テスト用...またはこれ

(cd production && docker-compose logs -f --tail 100)

本番用（ボーナス：別のマシンを指すように本番環境でDOCKER_HOSTを定義できますが、 docker-compose ）。

しかし、ええ、それはファイルではなくフォルダであり、動作するには2か所にcp .env-dist .envが必要です。そうでない場合、無効な作成ファイルで失敗します。 実際、私はこのIMHOのきちんとしたワークフローを共有したかっただけです。

これはまだ私にはわからない点です。 ハードコードされた単一のプロジェクト名を要求する理由はないはずです。 一貫した名前を期待する外部ツールがある場合、そのツールがdocker-composeを呼び出す前にプロジェクト名を設定しないのはなぜですか？

@dnephin理由があります。

はい、回避策があります。 質問は、それをより便利で予測可能にすることです。

ハードコードされたプロジェクト名が役立つ1つの例を次に示します。traefikのdocker構成は、デフォルトで次の形式でコンテナーのホストルールを作成します： <service>.<project>.<domain> 。 このフォーマットは簡単に変更できません。 Docker-composeサービスに同じfqdnを使用することは、開発者にとって非常に有益です。 一貫性を保証する唯一の方法は、a）クローンに特定のディレクトリ名を使用するように強制するb）traefikのルールを手動で指定することであるため、ゼロ構成セットアップを使用できれば素晴らしいと思います。 両方とも吸う。

もう1つは、docker-composeで作成されたイメージを参照することです。 プロジェクト名を保証できない場合、これらの画像名を保証することはできず、自信を持って参照することもできません。 確かに、定義ごとにimage_nameをハードコーディングすることはできますが、_コンベンションを使用したい_ので、率直に言って冗長に感じますが、異なるファイル名を使用することを選択した開発者がツールで非常に驚くべき失敗をすることを懸念しています。

みんな、たくさんの議論...これの状況はどうですか、 .docker-composeファイルにデフォルトのプロジェクト名を設定できますか？
それとも、このスレッドでさらに議論が必要ですか？

プロジェクト名をdocker-compose.ymlファイルに保存することは、PyCharmなどの他のツールで使用する場合に非常に意味があります。

同じYAMLファイルに保存しておくと便利ですが、必要に応じてオーバーライドすることもできます。

この問題の核心は、デフォルトのプロジェクト名が現在のディレクトリのベース名として単純に（_naively_？と言うべきですか？）取られているという事実から来ていると思います。 これにより、ファイルシステムの名前空間（階層）がフラットな名前空間に効果的に圧縮されます。これは、名前の競合のために問題があります。 たとえば、これにより、 ~/fooproject/masterおよび~/barproject/masterサービスを実行しているユーザーに問題が発生します。

プロジェクト名は重要ではないと思います。 それで、おそらくdocker-composeを堅牢にする方法は、フルパス（つまりhome_flaviovs_fooproject_master ）に基づいてプロジェクト名を生成することですか？

しかし、私は永続的なアイデアが好きです。 プロジェクト名をGitにコミットできるようにすることは、そのような一般的なユースケースです。 おそらく読んで.env.defaultの前にファイルを.env （BTWだけでなくとして長年＃210の世話をするだろう）、このためのシンプルなソリューションですか？

docker-composeバイナリを独自の関数でラップして、どこからでも関数を呼び出せるようにすることで、これを解決しました。 これにより、.envファイルが読み込まれ、適切なdocker-composeファイルがどこでも使用されます。

もちろん、これを拡張して、プロジェクトごとに機能を持たせることもできます。 それには欠点があるかもしれないと思いますが、私はそれらを見つけていません。

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

画像の衝突に問題があります。非常に論理的で単純な解決策に見えるため、docker-compose.ymlでproject_nameを設定できないのは本当に奇妙に見えます。 実際、そもそもプロジェクトフォルダから名前を付けるのは悪い考えでした。 多くの場合、プロジェクトフォルダーは/ home / project1 / repository、/ home / project2 / repositoryなどのようになります。この場合、dockerはrepository_appのような同じイメージ名を生成しました。

@vedmant docker-compose.ymlで画像名を設定できます。 imageとbuild使用するだけです。

だから...同じ名前のフォルダ上のプロジェクトで区切られているのはどうですか？

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

おそらくこれはすでに提案されています。 しかし、 version: 4重大な変更を加えて、 docker-compose.ymlからプロジェクト名を設定できるようにする新しいキーワードを追加してみませんか？

私の.docker-compose / project-nameが機能しませんでした..。
-プロジェクト名は機能しました

docker-compose.ymlにもプロジェクト名を設定したいと思います。

私のユースケースは、Webアプリとpostgressデータベースサービスを含むdocker-compose.ymlファイルがあります。
また、アドホックタスク用に個別のdocker-compose.ymlファイルが必要です。基本的には、docker-composeでオーケストレーションしたいアドホックタスクについて説明します。 これらのアドホックタスクは、メインプロジェクトで使用されているものと同じサービス/ネットワーク/ボリュームを活用する必要があります。

docker-composeを使用してオーケストレーションしたいアドホックタスクの例は次のとおりです。 データをpostgressデータベースに移行します。 このタスクを実行するために、現在のものと一緒に追加のサービスとボリューム、ネットワークなどを起動する必要がある場合があるため、docker-composeを使用してこれを調整するのに役立ちます。

したがって、これを実現するために、タスクを表す個別のdocker-compose.adhoctask.ymlファイルを作成して、必要な場合にのみそのタスクをオンデマンドで実行できるようにすることができます。 元のdocker-composeファイルと同じディレクトリにあるため、デフォルトで同じプロジェクト名を取得し、同じネットワーク、ボリュームなどにアクセスできますか？ とものが動作します。

ただし、このアドホックタスクのymlファイルをメインのdocker-compose.ymlと同じトップレベルディレクトリ（または同じリポジトリ）に配置したくない場合に問題が発生します。 たとえば、アドホックタスクdocker-compose.adhoc.ymlをサブフォルダーに配置し、 DOCKERFILEと、タスクが必要とするアセットを、それ自体の懸念事項として適切に分離/グループ化したいとします。 サブフォルダーに移動するとすぐに、プロジェクト名が一致しなくなります。 これは、メインプロジェクトで定義されているのと同じボリューム/ネットワークなどにアクセスできなくなったことを意味します。

docker-compose.ymlとdocker-compose.adhoc.yml projectnameを指定できれば、必要に応じて構造化でき（別々のリポジトリに配置することもできます）、実行する必要はありません。常に追加のコマンドライン引数を指定するか、環境変数を切り替えます。

これは私にとって本当の問題です。名前の競合が発生するからです。

構造内にいくつかのプロジェクトがあります

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

これで、1つのプロジェクトでdocker-composeを開始すると、ネットワークbackend_defaultが作成され、明示的に名前が付けられていないコンテナーのプレフィックスがbackend_ます。正しいフォルダーに戻り、最初にdocker-compose downを実行して競合を防ぎます。そうしないと、同じネットワークで新しいコンテナーが起動し、それらをオフにすると、orhanがない場合にorhanについて文句を言います。

私にとっても問題です。 私は複数のプロジェクトを持っており、単一のマシン上の動的デモスタンドにdocker-composeを使用しています。

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

そのため、「マスター」と「開発者」はプロジェクト間で競合しています。 .docker-composeファイルでそれを解決できます。

@simplesmiler自分自身を繰り返すリスクを冒して、 .envはすでにそれを解決しています。

@ shin- .envは、バージョン管理されていないシークレットによく使用されます。

@simplesmilerが望んでいるのは、 .envをバージョン管理の外に保ちながら、プロジェクト名をバージョン管理にコミットする方法です。

私の知る限り、これを簡単に行う方法はまだありません。

@thedeenoそれは彼らの投稿が言っていることではありません。 一緒に働いていますか？ そうでない場合は、他の誰かのユースケースが明示的に書かれているものを超えていると推測するべきではありません。

私たちは一緒に働いていません。 それが彼らの問題の私の解釈です。 完全に公平な点ですが、私は間違っているかもしれませんし、推測しているかもしれません。

コーヒーを飲みながら一緒に仕事ができたらいいのにと思います。 私がここで急いでいるとは思わないでください。

たぶん私はこのスレッドを間違って覚えているだけです： .env無視したまま、プロジェクト名をバージョン管理にコミットする方法はありますか？

.envを無視したまま、プロジェクト名をバージョン管理にコミットする方法はありますか？ それとも、これはまだ不足している機能ですか？

現在はありません。 数か月前に述べたように^ 1、バージョン管理に含めることができるセカンダリenvファイルとしてdocker-compose.envを使用する予定です。 優先順位のリストをいくらか下回っていますが、すぐに到達したいと思っています。

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

それは良い知らせだ！ PRを受け入れますか？

私はずっと前に希望をあきらめましたが、もう一度試してみましょう。

ここにいる多くの人は、なぜこの設定のために2番目のファイルを維持する必要があるのか​​まだ理解していないと思います。

私が理解しているように、ここでいくつかの場合、それは彼らのプロジェクトのセットアップを壊します。 しかし、このスレッドの大多数にとって、それは問題ではありません。 では、これらの少数の人々が、この機能を欠いている他のすべての人々にこの制限を課すのはどうしてですか？ 名前を構成して決定を私たちに任せる方法について、いくつかのオプションがないのはなぜですか？

論理的にも意味がありません。 docker-compose.ymlにこの設定がないことは明らかであるため、マニュアルでこのオプションを探したときに、このオプションが欠落しているとは信じられませんでした。 セットアップのほぼすべての他の側面をそこで構成できます。 私にとって、これは構成ロジックの明確な中断です。

docker-compose.yml （ほぼ）すべての設定は、プロジェクト名によって「スコープ」されていると言えると思います。

＃4841で提案されているように、使用する.envファイル（つまり--env-file ）を指定するオプションは非常に便利です。

@roipoussierehttps ： //github.com/docker/compose/issues/4841#issuecomment-414543951を参照してください

@ schmunk42に感謝します。
しかし、それは私が次のような階層を作成しなければならないことを意味します：

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

次のような簡単なものの代わりに：

.
├── a.env
├── b.env

はい、 https： //github.com/docker/compose/issues/745#issuecomment -345054893も参照してここで非表示になることがあるため、新しいウィンドウで開く必要がある場合があります：nerd_face：

2番目に--env-file提案です。 そのためだけにチケットを作った。 このオプションが必要な場合は、行って

だから私はこのバグ/機能についていくつかのコメントを読んだだけです、そして議論が続いていてそれが開かれているという事実はこれが最初に開かれてから4年が経ち、まだ解決策がないという結論に私を導きますか？ 部分的な決定をしてから先に進むことはできますか？

確かに、この問題全体と関連するすべての問題を読んだわけではありませんが、このトピックには興味深い問題があり、一見したところよりも複雑になっています。 たとえば、 .envは一般的に秘密の値に使用されることは誰もが知っているので、通常はバージョン管理からそれを無視します。

ただし、Stripeを使用しているとしましょう。これにより、テストキーとライブキー（別名）を使用できるようになります。 使用する2セットのキー。 開発ではテストキーを使用するのが非常に一般的であり、本番環境ではライブキーを使用することになります。

つまり、環境ごとに異なるキーがあり、ファイル内の値を実行と実行の間に切り替える必要がないため、 .envを単独で使用してシークレット値を処理することはできません。 devまたはprodのアプリ（クレイジーで非常にエラーが発生しやすい）。

最終的に行う可能性が高いのは、 .env .env.prodファイルとenv_fileで

ただし、本番環境では、本番環境の作成ファイルで.envと.env.prod両方を参照します。

しかし、これがどこに向かっているのかわかりますか？ 現在、Docker Composeでは、オプションのenv_fileファイルを使用できません。 ファイルが存在しない場合、DockerComposeを実行しようとするとすぐにDockerComposeが爆発します。

あなたは、自動的に必要なので、 .envあなたがそれを使用する予定がある場合は、最後に存在するファイルをenv_file 、これはストライプのいずれかに限定されるものではありません。 多くのWebフレームワークには、環境固有の特定の設定がありますが、開発と本番の両方で変更されます（つまり、FlaskではSERVER_NAME ）。

つまり、バージョン管理にコミットする.env_exampleファイルのようなものに制限されており、エンドユーザーがそのファイルの名前を.envに変更すると、このファイル内に次のファイルが含まれることになります。私たちの旧友COMPOSE_PROJECT_NAME 。

これで問題が発生します。 プロジェクト名を設定する別の方法が実際に必要ですか？ 私はそうすることを確信していませんが、カスタムプロジェクト名を設定することは、どのプロジェクトでも、または少なくともフォルダ名以外の名前を設定することは良い考えであると確信しています。名前の競合が発生しやすいからです。

この問題はいくつかのロードマップにありますか？

このユースケースは、プロジェクトに複数のdocker-composeファイル（たとえば、dev、test、おそらくbase、おそらくtest localなど）がある場合にCOMPOSE_PROJECT_NAMEを変更することです。スピンする必要があるかもしれません。互いに分離された2つの非常に異なる環境。

この場合、メイクファイルにCOMPOSE_PROJECT_NAMEを作成することで、このdocker-composeの制限を回避できます。

これをcomposeyaml自体から構成できるようにしたいと思います。

これはまだ開いていますか？ 何てことだ...

購読しました。 また、composeyamlファイルにプロジェクト名を設定できるようにしたいです。

これは永遠にかかります🤦‍♂

この機能があると非常に役立ちます

この機能は、私が取り組んでいるプロジェクトでは大歓迎です。

さて、この長いスレッドから、プロジェクト名はdocker-compose.ymlファイルに含まれないと結論付けることができます。これは、メインの開発者がこれに反対しており、そのようなプルリクエストをマージしないためです。

それでは、元の提案に戻って、この問題の冒頭にあるプロジェクト名を永続化してください。 ファイル.docker-composeまたはディレクトリ.docker-composeのいずれかを使用することは、私には問題ないように思えます。 しかし、最終的にそれを実装する上でいくらかの進歩を得ることができれば素晴らしいでしょう。

その選択肢のリストにENV変数を追加します。

すべての不一致の実質的な原因は、このスレッド/問題は、多くの人にとって、ENV変数内にあると機能しないということです。 彼らはそれをリポジトリにコミットできることを望んでいます（もちろん、標準の推奨事項はそれをコミットしないことです）。

yamlのコンテンツではなくENVにすることは、異なるプロジェクト間でyamlファイルを共有するという哲学と矛盾します。 実際、公式に文書化されています： https ：//docs.docker.com/compose/extends/（たとえば、「ユースケースの例」を参照）。 単一のベースyamlファイルを使用し、dev、test、prodのファイルをオーバーライドし、神が他に何を知っている場合、同じプロジェクト名で実行したり、ENV / cliでプロジェクト名を設定したりしても意味がありません。 Nが有効な間は、N * Nの組み合わせを作成するだけです。

私はこれらの議論のいくつかを横断し、プロジェクト名をYMLファイルで構成可能にすることを望んでいる人々からのコメントのトンを見ました。 しかし、それが行われるべきではない理由を説明する単一のコメントではありません。 これらの議論は古くからあります。

使いやすいソリューションを探していて、実行されたコマンドラインに注意を払う必要のないプロジェクト名を設定する簡単な方法がないことに気付いた人として（これは、あなたが使用するツールのコアアイデアと競合します） upを渡し、サーバーの完全なクラスターを魔法のように開始します）-これが未解決の質問であることにショックを受けました。 なぜ問題があるのか​​、実装するのが難しいのかについて明確な説明があれば、興味があります。

エレガントな解決策は、 container_nameプロパティでプレースホルダーを使用することです（およびボリューム、ネットワークなどの他の動的な名前付け）

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

このような構成では、

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

編集：これは完璧な解決策ではありません。同じフォルダー名内で2つの異なるプロジェクトを使用する人にとっては競合するからです。

@jderusse

エレガントな解決策は、 container_nameプロパティでプレースホルダーを使用することです（およびボリューム、ネットワークなどの他の動的な名前付け）

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

このような構成では、

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

編集：これは完璧な解決策ではありません。同じフォルダー名内で2つの異なるプロジェクトを使用する人にとっては競合するからです。

私もこれを行っており、これで競合の問題が修正されると思いましたが、 COMPOSE_PROJECT_NAME変数を.envファイルの一意の値に設定する必要があります。

この時点で、メンテナがソリューションを拒否している理由を本当に理解したいと思います。 ソリューションのプルリクエストはすでにあります。

何が悪いのかがわかったら、それを修正することができます。 この時点で、「拒否」以外のフィードバックは表示されません。

これらの2つのコメントがあります：

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

しかし、私はそれらのコメントを読んでも認めなければなりません。なぜプロジェクト名をyamlファイルに追加しないのか完全には理解していません。 docker-compose.yamlファイルの一般性が低下すると考える人は、yamlファイルに名前を入れないでください。ただし、他の人にそうするオプションを与えてください。

OK、私は他のコメントへの参照を読むために最善を尽くしています。 私が正しいことを読んで正しいコンテンツを取得していることを確認するのに役立つリファレンスに加えて、リファレンスのコンテンツを参照する少なくとも短い宣伝文を本当に感謝します。

私が見ているものが懸念事項であることを要約しようと思います。 これを明確にするための助けをいただければ幸いです。

（1）YMLファイルにプロジェクト名を追加すると、複数のプロジェクト名で1つのYMLファイルを実行できなくなるか、少なくとも複雑になるため、プロジェクトの再利用性が低下する可能性があります。
（2）「（この形式で）プロジェクトを追加することを正当化するには、結果としてプロジェクトの品質が大幅に低下する」
（3）「プロジェクト名が作成ファイルにある場合、2つのプロジェクトで同じ名前を使用すると、競合が発生し、両方のプロジェクトが破損する可能性があります。」

私はこれらについて考えましたが、対処する必要のある懸念について合意できるまでコメントを保留します。 それは合理的ですか？

（4）下位互換性のある方法での実装（値の優先順位/順序）

（1）YMLファイルにプロジェクト名を追加すると、複数のプロジェクト名で1つのYMLファイルを実行できなくなるか、少なくとも複雑になるため、プロジェクトの再利用性が低下する可能性があります。

繰り返しになりますが、構成をベースとファイルに分割して継承する公式の方法があります-https：//docs.docker.com/compose/extends/。 基本構成でプロジェクト名を設定できませんでした。

私にとって、私が探している主なユースケースは、プロジェクトの複数のインスタンスをローカルで実行する機能です（開発、テスト環境など）。

おそらく解決策は、プロジェクト名を明示的に設定するか、パストラバーサルを設定できるようにすることです。

yamlファイルでプロジェクト名をmy-projectように明示的に設定すると、プロジェクトの単一インスタンスの場合や、すべてのDockerファイルをdockerフォルダーに追加するような場合に簡略化できます。複数のプロジェクトにまたがって。

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

しかし、これは同じプロジェクトの複数のインスタンスでは役に立たないので、パストラバーサルで何かをするのはどうですか

project_name: ../(*)だから、同じ例で

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

同様にproject_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

トラバーサルを指定する方法は、おそらく私の親指よりも少し深く考える必要がありますが、少なくともこれを行うことで、すべてのユースケースをカバーする柔軟性があると思います。

冗談半分だけ：つまり、docker-compose.ymlで固定名を構成するということは、必要な名前でファイルを作成してから、 project_name: name-of-the-file-named-like-the-name-i-want設定するということです。

現在、同じディレクトリにdocker-composeファイルがdc-work.yml 、 dc-server.ymlなどのように、すべてが異なる無関係のサービスをロードします。

docker-compose up dc-A.ymlを実行してから、 docker-compose up dc-B.yml実行すると、Dockerは、孤立したサービスが実行されていることを通知します（もちろん、実行されていないのは、プロジェクト名がひどいためです）。

これを解決する方法は本当にありませんか？ 各dc-A|B|C|etc.ymlファイルを独自のディレクトリに移動してから、それぞれに移動してすべてのサービスをロードするのは、本当に時間の無駄のように思えますか、それとも何かが足りませんか？

この問題が解決されていないのはなぜですか？ 明確でわかりやすい解決策は、 @ cr7pt0gr4ph7によってここに提示されhttps ：//github.com/docker/compose/issues/745#issuecomment-182296139。 たくさんの賛成票を獲得しました。 議論の中で、すべての懸念が取り上げられました。 そして、最も重要なことは、それは多くの人々の多くの問題を解決することです。 何が得られますか？

また、Docker関連のものをすべて含む.dockerフォルダーを持つ固定プロジェクトディレクトリ構造を使用しているため、この問題が発生します。そのため、多くの.dockerプロジェクト名が表示されます-マイクロサービスアーキテクチャに取り組んでいますしたがって、複数のアップがあるのは正常です...しかし、この小さなことは邪魔になり続けます->また、PHPStormなどには-p / -project-dir引数を渡すオプションがなく、私はできません本当にこれには.envを使用します。なぜなら、私を信じて、正しい値を設定するのを忘れてしまうからです...

開発者の方は、どのように解決したいかをお知らせください。

たぶん、プロジェクト名を設定するためにdocker-composeファイルにプロパティを追加しますか？

@AyushyaChitransh

開発者の方は、どのように解決したいかをお知らせください。

これは最高の要約です：
https://github.com/docker/compose/issues/745#issuecomment -182296139

たくさんの議論がありました。 これ以上議論する必要はありません。 プロジェクトのメンテナは、スレッド（複数形）を読んで必要なことをするだけです。

私にとってはまだこれです： https ：

私にとってはまだこれです： ＃745（コメント）

はい、既存の、しかし不十分な解決策があります。 それらのコメントは反対票を投じられ、問題は多くの人によって明確に述べられています。 リンクされたコメントは、これらのスレッドで提起された正当な懸念のほとんどに対処していません。

Tbh、それは一種の論点です。 私たちの多くは、 docker-composeタイプの機能のためにKubernetesに移行しました。 少し冗長です。 しかし、それは機能しており、クラウドベンダーによって十分にサポートされています。

@AyushyaChitransh
ここで説明するように、メカニズムを使用してプロジェクト名を設定します： https ：

1. コマンドライン引数。
2. 環境変数（.envファイル）
3. ファイルを直接作成する
4. フォルダパス

これに異議があるとは思わないでください。

そこには、前述のように、 container_nameを使用する場合の移植性に関するものがありますが、これもdocker-compose.yml一部であってはなりません。 同じ構成を既存の設定で再利用することはできません。

ワークフローがフォルダーパスに依存していて、どういうわけかproject-nameが構成に挿入される場合。 マージ、複数の作成ファイル、テンプレートなどを通じて、...-同じ問題が発生します-既存のスタックを上書きします。

申し訳ありませんが、これはwontfixとして

@ schmunk42

ワークフローがfolder-pathに依存し、どういうわけかproject-nameが構成に挿入される場合、たとえば。 マージ、複数の作成ファイル、テンプレートなどを通じて、...-同じ問題が発生します-既存のスタックを上書きします。

まず、プロジェクト名は、それを必要とするユーザーによってのみ作成ファイルに設定されます。これは、作成ファイルが既存のスタックで機能することを望んでいるためです。 この設定に関するドキュメントに警告を追加できます。
次に、特定のプロジェクト名に依存している場合は、次のことを考慮してください。

1. 作成ファイルがgitリポジトリからダウンロードされた場合、次のコミットでリポジトリの所有者はそれを別のサブフォルダーに移動しますか？ または、フォルダの名前を変更しましたか？ ファイルを移動できるため、ワークフローへの影響はすでに存在しており、プロジェクト名に影響を与えます。
2. 特定のプロジェクト名に依存している場合は、環境変数（.envファイル）を使用するか、Dockercomposeの実行時にコマンドライン引数を使用することでそれを保証するメカニズムを提案しました-どちらもたまたまにあった値をオーバーライドします作成ファイル（何らかの理由で追加された場合）。

これをwontfixとして閉じることは、上記が十分ではない理由を説明したり、解決策への道を提供したりしない限り、あまり役に立ちません。

私のワークフロー（またはチーム全体のワークフロー）が、コードをチェックアウトするフォルダーの名前に依存することを望んでいません。

.envファイルソリューションに関する私の主な問題は、このファイルがコマンドrunの作業ディレクトリにある必要があることです-一方、docker-composeはcomposeファイルを親ディレクトリに解決します。 したがって、すべての開発者が（A）同じ名前のフォルダーにコードをチェックアウトするか（コードリポジトリのルートにあるdocker-compose.ymlファイルを想定）、（B）でdocker-composeコマンドのみを実行することが不可欠になります。それ以外の場合、リポジトリのルートフォルダーは競合するスタックを作成するか、（C）スタック名が異なり、すべてのドキュメントとスクリプトでreplace stack name hereと言う必要があります。

（C）が推奨される「ポータブル」ソリューションとしてdockerが提案するものである場合、docker-composeCLIはdockerCLIコマンドを備えた機能を備えている必要があります。それでも、この機能の使用例はまだあります。

ワークフローがfolder-pathに依存し、どういうわけかproject-nameが構成に挿入される場合、たとえば。 マージ、複数の作成ファイル、テンプレートなどを通じて、...-同じ問題が発生します-既存のスタックを上書きします。

プロジェクト名がdocker-composeファイルに追加された場合、それは確かに理由があります（docker-composeファイルの他のすべての行と同様）。 悲しいことに、今はチェックアウトしたフォルダーの名前を変更しただけでも（gitで追跡された変更を加えていない）、システムが壊れています。

2020年だとは信じられませんが、この巨大なユースケースはまだ修正されていません。 これは重大な変更ではなく、完全にオプションの機能であり、完全に理にかなっています。 Kubernetesがdockerの事実上のデプロイツールになったことを考えると、docker-composeは開発/ローカルデプロイメントでの使用がほとんどであり、リポジトリのルートにdocker-composeファイルを配置してリポジトリ内のコードをローカルで実行することは非常に人気があります使用事例。

@ dc-pmは次のように書いています：「KubernetesがDockerの事実上のデプロイツールになりました」

docker-composeファイルを作成しなくなりました。 生産が見られないものには十分なメリットがありません。 Kubernetesにも癖があります。 しかし、それはクラウドベンダーによって広くサポートされています。

正直なところ、私の開発環境でコンテナーを扱うことでさえ、日々非常に面倒です。 プログラムを実行するだけです...

@ dc-pmは書いた：

2020年だとは信じられませんが、この巨大なユースケースはまだ修正されていません。

修正されていないだけでなく、開発者が積極的に修正を拒否しているのです。

問題は、このソフトウェアを開発する10代の若者が、このユースケースの意味を理解するための深い経験を持っていないか、または対処を要求する経験豊富なユーザーの膨大な数に耳を傾けていないことです。 この時点で、彼らが複数のスタックがある環境で、あるいはおそらくチームでさえ働いたことがあるとは思えません。 そうでなければ、率直に言って、_これは完全に明白な機能強化になるでしょう！_

いくつかのフレンドリーなリマインダー...
オープンソース開発者はあなたの「従業員/大学」ではなく、ほとんどの場合、彼らはほとんど無料で働いています。
それが明らかにあなたにとって問題である場合は、解決策を調査す​​る（そしてPRをプッシュする）ために少し時間がかかります。

非難は解決策ではありません。

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

開発者がそれに反対しているときに変更をプッシュすることはかなり難しいです...

土では、午前3時19時2020年3月14日、アントワーヌGravelot [email protected]
書きました：

いくつかのフレンドリーなリマインダー...
ほとんどの場合、オープンソース開発者はあなたの「従業員/大学」ではありません
彼らはほとんど無料で働いています。
それが明らかに問題である場合は、解決策を調査す​​るために時間をかけてください
PRをプッシュします。

非難は解決策ではありません。

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/745#issuecomment-598991880 、または
退会
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
。

@agravelotいくつかのPRがあったと思いますが、理想的ではないかもしれません。 しかし、すべてのディスカッションを通じて、所有者はこの機能を望まないという期待を非常に明確に設定しています。 コーディングの問題ではありません。

@agravelot遅れてすみません。 そして、私は本当にここに貢献する多くの素晴らしくて才能のある人々を軽視しないことを意味しました。 しかし、努力の欠如を非難することも役に立ちません。

私は、非常に長い期間にわたる明確な支持にもかかわらず、数え切れないほどの機会に聞かれなかったアイデアの支持を単に強調します。 私たちの行動規範で定義されているこの（そして一般的にはOSS）の全体的なポイントは、人々がコードを提供し、すべてのアイデアを尊重できるようにすることです。

すでに複数のプルリクエストが作成されていますが、それが状況に役立つ場合は、別のプルリクエストを作成できてとてもうれしいです。

より建設的な方法は何でしょうか？

すでに複数のプルリクエストが作成されていますが、それが状況に役立つ場合は、別のプルリクエストを作成できてとてもうれしいです。

はい、開発者はレビューを続けるか、これを「修正しない」（おそらく議論）として閉じる必要があります...公式のフィードバックなしでこれを何年も開いたままにしておくと、（最も広い意味で）貢献者の時間を無駄にしているだけです）。 これも無礼です、IMO。

ねえ、みんな、ユーザーとして私は自分のユースケースを共有したかっただけです。 つまり、2つのdocker-compose.ymlファイルがあります。1つは開発環境用、もう1つは本番環境用です。 それらは同じフォルダにあります。 どちらにも「データベース」と呼ばれる同じ名前のサービスがあります。 これらのサービスの両方を同時にデプロイしたいと思います。できるという理由だけで、これは私たちが話しているコンテナ化であり、必要なだけ拡張できます。 ただし、「container_name」の値は異なります。

だから私は実行します：

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

「prod」プロジェクトにあるサービスを明確に参照しているときに、「recreatingdatabase-dev」と表示されていることに注意してください。 実際に既存のコンテナを上書きします。 データベースは終了し、コンテナは後者に置き換えられます。

私は、個別の「docker-compose.yml」ファイルが個別のプロジェクトを意味することを前提としてこれを行っていますが、これは実際には問題ではないようです。 サービスがデプロイされるプロジェクトは、「docker-compose.yml」の場所によって決まります。 それらを別々のプロジェクトの一部にするには、環境変数でプロジェクト名を別々に指定する必要があります。 それは最終的にこれで動作します：

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

単一コマンドの展開についてはこれだけですが、絶対的な冗談です。 私の意見では、.ymlはこのコンテキストでプロジェクト名を指定するのに最適な場所です。

または、「database-dev」と「database-prod」という異なる名前を付けることで、サービスを1つのプロジェクトに配置することもできました。 このアプローチの唯一の問題は、以前にインスタンス化されたサービスが他のdocker-compose.ymlに記載されていないため、孤立するという警告があることです。

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

これは意味がありません、なぜそれはこのようでなければならないのですか？ なぜそれが実際にそのようでなければならないのですか？

編集1：@ dc-pm
EDIT2：両方の作成ファイルを別々のディレクトリに入れて出来上がり

すっごく？

メンテナ、ここに誰か？
開発者は6年間待ちます！

こんにちは！ 私はcompose-specに問題を作成し、composeファイルに追加できるものを管理するプロジェクト名をcomposeスキーマに追加しました。
project-nameプロパティがcompose仕様に追加されたら、docker-composeで実装を開始できます。