Compose: デフォルトで開始されないサービスを定義する

オプション1の場合は+1

実際にはコンポジションの一部ではないが、たまたまそれにリンク/アタッチする必要があるサービスを追加することは、悪い設計上の選択だと思います。 何らかの形式のインクルード構文を許可することで解決できるユースケースは他にもいくつかあります。 1つの機能で複数の問題を解決することは常に素晴らしいことです。

これらの問題のいくつか（データのみのコンテナーを扱う問題、＃942、@ cpuguy83からの最後のコメント）は、実際には＃1754によってすでに修正されています。これ以上、問題と見なす必要はないと思います（1.5以降）。 ）。

Magento拡張機能を開発しています。 そのためには、LAMPスタックでWebストアを実行する簡単な方法が必要です。 作成すると、それが簡単になります。 しかし、phpunit、さまざまな静的分析ツール、ドキュメントビルダーなども実行したいと考えています。実際、「サービス」の大部分は、 docker-compose run --rm phplintような単なるコマンドです。 理想的には、次のような修飾されていないコマンド

docker-compose up -d

長時間実行されるサービス（実際の_services_）を開始するだけで、phpunitのような他の効果を不必要にトリガーすることはありません。 （Webサービスが起動する前にSeleniumテストを実行するなど、問題が発生しないようにすることも重要です。）

私たちが本当にやろうとしているのは、本番サービスを実行するのではなく、開発者から環境管理の苦痛を取り除くことです。 @dnephinのコメントが、Composeの方向性を表しているかどうかはわかりませんが、ComposeがまだニッチなFigにサービスを提供することを計画しているかどうかは、私にはあいまいに思えます（明確にするために、私はオプション1は、開発者が図のようにこれを使用する必要がある使いやすさをサポートしていないと思います。）Composeが複数の責任を負いたくないかどうかは完全に理解していますが、誰かが明確に知らせてくれることを願っていますこの製品を高速で分離された開発環境に使用している人が別の方向に進む必要がある場合。

@kojiromike 、あなたのユースケースに適さないのは（1）について何ですか？ それはコマンドのセマンティクス（ docker-compose run --rm phplint対docker-compose --file phplint.yml up ）についてですか？

そのdocker-compose up -dはphplintを「開始」しようとし、 docker-compose psはphplintの「サービス」がダウンしていることを報告します。 実際には、サービスコンテナではなく、ツールコンテナであるため、アップ/ダウンの概念はありません。 ツールコンテナはdockerに採用されており（redis-cliのようなものを実行する方法であり、明らかに「サービス」ではありません）、開発でより多く使用している一方で、本番用の場所もあると思います。 awkを本番マシンまたはコンテナーにインストールした理由のように、リンクを使用してコンテナーを実行して、予測可能な動作を取得してみませんか。

：+1：実行中の単体テストをカプセル化するために、他のサービスと一緒にtestsコンテナーを作成したいと日常的に思っています。 私の「回避策」は、コマンドを「/ bin / true」に設定し、CLIで指定された単体テストコマンドを使用してコンテナーを実行することです。 up時間に開始するコンテナを指定できると便利です。

（ところで、すべての周りの素晴らしい仕事、人々）

cc @jameydeorio

@ryneeverettセマンティクスはその一部です。 それは自己文書化と見つけやすさの問題です。 現在、開発者にdocker-compose run --rm foo barを通知しています。 シェル関数またはエイリアスを作成するように招待しますが、プロジェクトの標準エイリアス/ rcfileを維持していません。 （コンテナーの外部で標準化する必要はありません。Docker_to_standardizeを使用します。）一部のコマンドに新しいファイルを追加すると、重要な階層が作成されます。docker-compose.ymlファイルが重要な「デフォルト」ファイルになります。そして、「その他」のファイルはそれほど重要ではなくなります。

もう1つは、サービス間の関係を維持することがより面倒になることです。 デフォルトで実行されないものが必要だからといって、長時間実行されているサービスのlinkまたはvolumeを使用しないという意味ではありません。 extendsは、サービスを「コマンド」（1回実行サービス）にリンクするために必要なすべての機能を実際に提供するわけではありません。 たとえそうだったとしても、複数のyamlファイルを使用する必要がある場合は、他の方法では必要のない場所でextendsを使用する必要があります。

extendsは、サービスを「コマンド」（ワンランサービス）にリンクするために必要なすべての機能を実際に提供するわけではありません。 たとえそうだったとしても、複数のyamlファイルを使用する必要がある場合は、他の方法では必要のない拡張機能を使用する必要があります。

@kojiromikeそれは私が疑ったことです。 改善されたextendsサポート+単一のdocker-compose.yml内でサブコマンド（機能的にはextendsと同じ）を実行する方法に満足できるでしょうか。 しかし、おそらく後者は（4）と同じです。

2）サービスにオプションを追加して、デフォルトで開始しないようにします

オプション2に投票します。たとえば、 start: falseディレクティブのようなものです。 利点は、複数のcompose.ymlファイルや追加の構成ファイルが不要になることです。1つのcompose.ymlを読み取るだけで、アプリスタック全体の感触をつかむことができます。

https://github.com/docker/compose/issues/1987#issuecomment-139632238に対して提案されたソリューションでこれを処理できると思います。 「admin」サービスは別の構成に定義でき、コンポジションに対してadminコマンドを実行する必要がある場合は-fを追加できます。

@ dnephin ＃1987（コメント）のソリューションは「管理サービス」を処理しますが、「データのみのコンテナ」は処理しませんよね？ それでもcommand: /bin/true回避策を使用する必要があります。

作成はボリュームの再作成されたコンテナへのスワップを処理するため、composeでデータのみのコンテナは必要ありません。

@ cpuguy83次の例では、データコンテナは実際には必要ありませんが、ボリュームを変更する場合は、指定された1つの場所を確認するだけで済みます。

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

ただし、これはコーナーケースであり、構文を追加する価値はないことに同意します。 提案されたソリューションはこのケースを処理しないと言っているだけです。

確かに、データボリュームにはまだいくつかのコマンドが必要なので、そのコマンドをサポートするには最小限のイメージを使用する必要があります。

出てくる新しいボリュームAPIについては完全に最新ではありませんが、データボリュームをより適切に処理するように作成するvolumes:セクションを追加できることを願っています。 （それらのためのコンテナを必要とする代わりに）。

これは必ずしも正しい選択とは限りませんが、学習曲線/理解のしやすさを考慮する必要があると思います。

（2）が一番わかりやすい気がします。 これを確認する方法は実際にはありませんが、ここで解決しようとしている問題に遭遇するdocker-composeのオプションのすべてに精通していないほとんどの人は、次のように述べています。 「 docker-compose upを実行したときに、そのコンテナを_起動しない_ようにする方法があればいいのにと思います」と、 start: falseとbamが表示され、完了して満足しています。

彼らは、「これを解決するために、厄介なリンクストーリーを含む2番目のファイルを作成する方法があれば...」とは言いません（https://github.com/docker/compose/issues/ 1987＃issuecomment-139632238は、「厄介なリンクストーリー」に役立ちます。

（4）は漠然としたものでしたが、このようなスクリプトや1回限りの方法のための専用の手段は、この「理にかなっている」法案に適合します。

今日、私は正確に(2)を探していましたが、私の最も嫌いなソリューションである2番目のYMLファイルに行き着きました。 私のユースケース：

コンテナがいくつかあり、それらはすべて同じmongoコンテナにリンクしています。 私自身とチームに、フィクスチャをmongoデータベースにロードする機能を提供したいと思います。そのための最も簡単な方法は、 mongoコンテナを別の名前fixturesでロードすることです。それ自体がmongoにリンクしてから、 mongorestore --host mongo --port 27017 --drop /dumpます。 常にフィクスチャをロードしたくないので、 start: falseそれを持っているのは自然なことfixturesとmongo両方に別々のYMLファイルを持っていることになりました

うまく機能しますが、 start: falseははるかにクリーンなIMOです。 このいわゆるフィクスチャコンテナの順列が10個以上ある場合、はいstart: falseは悪い考えであり、 (1)ます。

docker-compose up -dコマンドで一部のサービスを実行してはならない作成ファイルを作成する必要がありました。 私にとって、オプション（2）は私の問題に対する最良の解決策です。

私もこれに出くわしました。 どちらが最善の解決策だと思うかはわかりませんが、私にとっては、コンポジションの一部として使用される画像を作成する機能が必要です。 これらは一時的なコンテナー用ですが、コンテナーをオンデマンドで実行できるように、イメージを使用できるようにする必要があります。

こんにちは！ ここで同じ問題、素晴らしいグループ化の問題があることをうれしく思います、素晴らしい仕事です！

私の場合、サービスを備えたいくつかのコンテナで動作するPythonスタックがあります。 すべてが正常に機能していますが、スタックからケースが見つかりました。 私はbowerを使用して静的な依存関係を管理しており、コンテナー内でbowerコマンドを実行したいのですが、これはたまに実行するスクリプトにすぎません。

私たちが持っているcompose構造内でこのスクリプトを実行するのは素晴らしいことです。 私は次のようなものをイメージします：
docker-compose run node bower install

だから私は4番目のオプションの2番目が好きです。 サービスを開始しない必要があります、それは必要ありません：P

コンセンサスがあれば、「再起動」などのプルリクエストを送信してみてください。
開始：常に
多分...わからない。

オプション2への別の投票。

オプション2もお勧めします。 新しいDockerデータコンテナはdocker-composeファイルで指定できますが、使用するために実行する必要はありません。

私にとってもオプション2

オプション2は素晴らしいでしょう。

オプション2の場合は+1

オプション2の場合は+1。複数のファイルを維持して名前を入力するのは時間の無駄です。 1つのブールフラグがそれらすべてを支配します。 ：ビール：

オプション4の場合は+1
私が2番目のお気に入りを選ぶ必要がある場合はそのopt2。

確かに、両方を+1できる場合、最良のオプションは2,4です。そうでない場合は、過半数を使用して2に投票します。

2に投票する

2と4の両方があればいいです。
2の+1

タスクに新しい概念を導入する必要はないと思います。 これらは私の意見では非常によく読まれており、多くの変更なしで可能です。

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

別の作成ファイルを使用した現在の「解決策」は、私の意見では実際には解決策ではありません。 @xakaが言ったように、誰もこれをすべて入力したくありません：

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

最終的には、 myTask前にすべての定型文を追加する./run-taskスクリプトが作成されます。 しかし、これで、マルチコンテナアプリに別のエントリポイントとインターフェイスが追加されました。 開発者が見るdocker-compose.ymlと思う：_ _そして今、あなたがそれらを伝えるために持っている「ああ素晴らしい、コンアプリ私はこの事を処理する方法を知っている。！」：_ "右を、あなたがそれを管理することができますdocker-compose他のすべての作成アプリと同じように...ああ、でも待ってください...知っておく必要のあるこの追加のスクリプトもあります... "_

start: false / up: false / some-additional-flag-to-a-service: falseはおそらく実装が最も簡単なものですが、おそらく最も明確で理解しやすいものでもあります。 そしてそれは使いやすさをとても改善するでしょう。

@sherterが言ったこと。 ：arrow_up：

：+1：そのため。 特にネットワークが関与している場合、個別のdockerfileは大きな苦痛です

start: true|falseアプローチは制限が多すぎます。 一部のサービスがテストに使用され、他のサービスが管理に使用され、残りが通常の操作に使用される場合はどうなりますか？

グループ化の概念をサービスに追加したいと思います。

    myservice:
       group: `admin`

group属性が定義されていない場合、 defaultが想定されます。
そうすれば、 docker-compose up -g admin -dを使用してデフォルトの管理サービスを開始できます。

さらに良いことに、 groupsを配列にします。

サービスのグループクラスを作成することは強力な機能のように思われますが、この問題に接しているようにも見えます。

docker-composeバージョン2では、すべてのコンテナーがservices:トップレベルアイテム内で宣言されます。
スクリプトを実行するためにstart: neverを使用してサービスを宣言するのは、間違っているように聞こえます。
したがって、新しい形式を考慮すると、_services _、_ volumes_、および_networks_とは別に、追加のトップレベルアイテムを宣言する必要がありますか？

わたしの提案：

• 新しいscripts: 、 transients: （またはより良い名前を考えてください）のトップレベルアイテムをv2に追加します。
• トランジェント内では、他のサービスと同じようにコンテナを定義できます
• 唯一の違いは、一時的な使用のみを目的としているため、_デフォルトで開始_されないことです。

例：

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

そして、あなたは実行することができます：

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

懸念事項：

• 開始を管理するというこの目的のためだけに別のトップレベルのアイテムを作成するのはOverPoweredのように聞こえますが、新しいフォーマットがトップレベルでの動作を宣言しているという事実に由来しています。
• 私はこれが追加するかもしれない余分な柔軟性（そして問題）を想像しようとしています。

最後に、_groups機能_についてはいいように聞こえますが、グループ化がそれほど多くある場合は、それぞれにdocker-composeファイルを作成しても問題は発生しません。 おそらくあなたが望む機能はdocker-composeファイルの継承です、それは素晴らしいでしょう！

PD： @bfirshアイデアが気に入ったら、「考えられる提案」に追加できます。

第二に、これはサービスを宣言する差し迫った新しいフォーマットのために、 4番目の提案の改良です。

オプション2への投票：最も明確で読みやすく、新しい概念を学ぶ必要がない
デフォルトで起動しないサービスが欲しいだけです

disabled: trueようなものはどうですか

@ cpuguy83これは、 runであっても、サービス全体が無効になっていることを意味しているようです。 紛らわしいと思います。

@qchoうーん、1.6からDockerに慣れてきたので、あなたと@gittycatが何について話しているのかがわかります。 その意味で、 @ gittycatのアプローチが本当に好き

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

一方、シェルでは…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

このようなアプローチは素晴らしく、このチケットの必要性を排除しますが、その範囲を超えています。

@kojiromikeそうは思いません。 これは、initシステムが自動的に起動してはならないサービスを参照する方法です。

また、これは単純であり、「混乱」はドキュメントで解決できます。
また、サービス開始の概念とはまったく関係のないこのグループ化よりもはるかに混乱が少ないと思います。

@ cpuguy83 「サービス」のセマンティクスは、そもそも混乱を招くものだと思います。 グループ化はスコープクリープであることに同意します。 その意味で、私はオプション4 / @qchoのアプローチを好みます。このアプローチでは、「サービス」と「サービスではないもの」を明確に区別します。

それがポイントです。なぜ、サービスを実行しないコンテナを「サービス...無効」カテゴリに入れる必要があるのですか。 誰かが作った醜いパッチのように聞こえますが、直感的ではありません。

たぶん、フォーマットの「バージョン2」はこの問題を考慮に入れるべきでした。 たとえば、別の仕様は

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

これで、グループ定義を使用した適切なサービスができました。 生産または開発サービスグル​​ープを開始できます。 または、some_script_containerでスクリプトを実行するだけです。 どのサービスでも定義されていないため、誰も開始されません

@qchoサービスの定義によって異なりますが、いずれにせよ、たまにしか実行しないものに疑問を投げかけ、実行するかどうかを判断できるのは人間だけです。

したがって、composeがjobオブジェクトのようなものを採用するとします。

1. ジョブは1回だけ実行されます
2. サービス後にジョブが開始されます
3. ジョブは終了する予定です
4. ???

現在、composeは、ジョブに関するローカル状態を維持する必要もありますが、現在はまったく実行していません。

これが、単純なauto-up: falseまたはautorun: false追加することが、これを処理するための最も簡単で不気味な（スコープ単位の）方法である理由です。

@ cpuguy83あなたは私が言っていることをもっと複雑なもので拡張していると思います。 私はdocker-composeが仕事やワークフローについて知っているつもりはありません。 そのために外部スクリプトを作成できます。 私が意図しているのは、docker-composeは、アプリケーションを実行するためのスタック全体を定義する必要があるということです。

スクリプトを作成し、あなたが言っている状態を維持することを想像できます。 サービス開始直後ではなく、サービス開始前にスクリプトを呼び出すこともできます。 インポートする必要のあるボリューム、または未知のコンテナーでファイルから抽出して適用するスクリプトを実行するために必要な構成を確認する必要があるため、自分でコンポーザーファイルを解析しているとは思いません。 したがって、docker-composeはそのコンテナーを提供する必要があると思います。 スクリプトを実行して状態を維持することが私の問題です。

なぜ人々がそれを言い続けるのか分かりません

services:
  my-script-container:
    auto-up:false

以下よりも単純です：

scripts/containers/transients/you_name_it:
  my-script-container:

それは同じレベルの複雑さです。 しかし、意味的にはハッキーではありません。

1つのスレッドでアイデアを得るには、＃2803を参照してください。

ユースケース：多くのコンポーネントとユーザーが何を選択してインストールするかを選択したプロジェクトがありますが、彼はファイルを作成してそれらすべてをインストールします。

提案：docker.composeで定義された画像を除外するためにdocker-cmpose.overrider.ymlに配置するオプションを追加します

すなわち

いくつかの画像：
除外：はい

動作は、docker-compose.ymlのそのエントリを無視することです。

チームの考えを教えてください。変更を加えることに興味があります。

＃2にも投票します...今日このニーズに遭遇しました。

@jimzuckerの提案も機能しますが、メインの.yamlファイルに「start：false」が表示されているので、明示的に呼び出さないとこの「サービス」が実行されないことがすぐにわかります。 それ以外の場合、あなた（または私の場合はdocker-composeファイルを渡したエンドユーザー/開発者）は、オーバーライドファイルを探すことを忘れないでください。

+1for2。composeの一部としてDockerイメージを作成する必要があるのに、サービスとして実行されないという状況があります。 他のサービス（Dockerソックスが内部にマウントされている）は、イメージからコンテナーを頻繁に実行します。

2の場合は+1、文言として「自動アップ」または「自動実行」の場合は+1。

そして、サービスのグループのケース（@gittycatで説明されている）は、環境変数ala "auto-up：$ {ADMIN}"を介して処理できませんか？

また、 docker-compose.yml内のサービスを、単純なdocker-compose up自動的に開始するのではなく、明示的にのみ開始するようにマークする実際のユースケースもあります。

解決策1）は現在可能な方法の1つですが、 docker-compose upを呼び出してファイルを分割または複製するのではなく、1つ以上のymlファイルを指定する必要があるため、私の意見では面倒です。

解決策2）のようなものが本当に見たいので（他の多くの人もそうです）、＃3047でこれの概念実証を実装しました。これを少し試して、実行可能かどうかを確認してください。解決。

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

オプション2と4の両方で+1

オプション2および4の場合は+1

オプション4の場合は+1。一部の構成はスクリプトに許可されるべきではありません（例：再起動：常に）

オプション2を使用すると、次のような奇妙なケースが発生する可能性があります。

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

それはどういう意味ですか？

@mathroc ：「composeの実行時にこのコンテナを自動起動しないでください。このコンテナが停止したら（明示的に起動した後）、終了コードに関係なく再起動してください。」 何がおかしいの？

@nikoそうそう、投稿する前にもう少し考えておく必要があります...

オプション2の「投票」を+1に変更する

オプション2の+1は、複数のプロジェクトでこれが必要でした。

ping @bfirsh @dnephin ：
この問題に関する最新情報を教えてください。 ここでのほとんどのコメントはオプション2を支持しているので、現在そのようなもの（またはオプション3/4）を実装する計画はありますか？
プルリクエスト（＃3047）を磨き上げて、マージを検討する場合は、テストとドキュメントで完了することができます。

ありがとうございました。

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

オプション1は機能すると思いますが、次の冗長性を減らすためのより良い方法が必要です。

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

おそらく、簡略化/拡張フラグを追加できますか？ docker-compose --augment tests upあり、 docker-compose.ymlバリエーションである場合は自動的に解決されます。そうでない場合、ユーザーは明示的である必要があります。

私は新しいトップレベルのキーワードのアイデアが本当に好きです、おそらくsuitesとcommands ？

次の構成では、次のことが可能になります。

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

コードから、「1回限りの」サービスの概念がすでに存在することがわかります（IMHOはdocker-compose runが呼び出された場合にのみ使用されます。
再利用できますか？
コンテナにcom.docker.compose.oneoff=Trueラベルを付けると、コンテナを起動しようとしますか？

それ以外の場合は、オプション2に投票します。

私はこれに偶然出くわしたので、ここに私の2つのユースケースがあります。

1. 「グローバル」環境変数：ここで推奨されるアプローチは、 extendsを使用することです。これは問題ありませんが、拡張元としてimageを定義する必要があります。 、 scratch使用することもできません（したがって、https：//hub.docker.com/r/tianon/true/になりました）。
2. 「スケーリング」サービス：デフォルトでは1つのMongoDBインスタンスがありますが、一部のテストでは、2つ目の非アクティブなインスタンスを定義したいので、それらのテスト用に起動できます。 ここでは、別のファイルでextendsを使用することは、実行可能なアイデアのように見えます（docker / docker-composeと関連するベストプラクティスについてはまだ学習しています）。

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1
単純な変更のようです...

+1オプション2

envとconfigの共通セットを共有する複数のコンテナのユースケースでは、拡張するベースコンテナを構築することは理にかなっていますが、実際にはコンテナを開始することはありません。

auto-start:true|false

昨年9月以来、 rocker-composeと呼ばれる優れたソリューションがあるので、実行することをお勧めします：_always_ | _once_ | _決して_。 私も状態が好きです：_running_ | _ran_ | _created_も。

この機能のためだけに別のプロジェクトを使用するのが好きではないので、これが実装されるまで、私はtianon / trueプロジェクトからTrueasmコードコマンドを盗むことになりました。

また、最初はオプション2が最適だと思っていましたが、制限が厳しすぎて、追加してすぐに、1回限りのタスクが必要になると思い始めました。 実際、私は現在、次のユースケースが必要なプロジェクトに取り組んでいます。

• スタック内で、最初のデプロイで1回実行され、将来の実行は外部でのみトリガーされるコンテナーを定義できるようにしたいので（スケジュール/イベント、API呼び出しなどを介して）、メインサービスコンテナーの状態を初期化/更新できます。同じスタック内（DBデータ/スキーマ、データボリュームの入力など）
• スタック内で、外部でのみトリガーされるコンテナーを定義して、ユーティリティ/管理タスク（状態/データ検査など）およびスケジュールに従ってトリガーされるプロセス（バックアップなど）をカプセル化するために使用できるようにしたい、または外部イベントによる（たとえば、S3バケットへの変更時にプロセスをトリガーする）

私の場合、 state: created （0回実行）とstate: ran （実行> = 1回）の区別は重要です。ユーティリティ/管理タスクの一部は破壊的であり、使用されるだけだからです。サービスの移行などの特定の状況では。

ロッカーコンポーズまたはオプション4のようにstate: running | ran | created傾いていることを考えると、トップレベルの_task_または_job_オブジェクト+依存関係を表現する機能により、サービスがタスクをトリガーしてタスクを前後に実行できるようになります。

これは私のユースケースにとって重要であることに言及したいと思います。 docker-composeを使用してテスト環境を作成し、テストスイートを実行します。 すべてのコンテナーを一度に開始する場合の問題は、テストスイートを実行する前にサービスコンテナー（データベースやセロリワーカーなど）を簡単に初期化できないことです。

次のようなことを達成できることが望ましいでしょう。

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

初期化が行われたことを確認するためにsleep 5よりも複雑なものを書くことができると想像できますが、サンプルスニペットでは必要ありません。

CLIフラグに関するオプションを読みませんでした。 したがって、オプションのリストに--excludeフラグを追加することを提案します。 --excludeフラグは、指定されたコンテナーを開始しないようにupコマンドに指示します。 --excludeフラグは、必要に応じて複数のコンテナーを起動から除外できるように解析されます。

：+1：

オプション2が適切なソリューションとなる別のユースケースを検討します。既存のアプリケーション内の新しいサブサービスを反復処理します。 プロジェクトのほとんどの開発者はまだ新しいサービスを必要としないでしょう、そしてあなたは間違いなく彼らの仕事を妨げる問題を望んでいませんが、あなたはまた長期間ツリー外のブランチを維持することを避けたいかもしれません時間。

別の「docker-compose-experimental.yml」ファイルは機能する可能性がありますが、コンポーネントがまだ実験的である間にそのコンポーネントで作業するためのすべてのドキュメントを一方向に記述し、標準セットの一部になったら改訂する必要があることを意味しますサービスの。

オプション2に+1

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

@acranプルリクエストを送信して、これを前進させるための牽引力を得ることができるかどうかを確認してください。おそらく、リベースして＃3047の競合を解消すると、問題が発生します。これに注意を向ける方法がわかりません。

@jimzucker well＃3047はすでにプルリクエストであり、

上記の私のコメントを参照し

+1オプション2

@acran 、関連するドキュメントとテストケースの更新をお手伝いしたいと思います。 大丈夫ですか ？

+1オプション2

または、Kubernetesのように、ある種のジョブを定義しますか？

オプション2の場合は+1

Docker-composeには複数のサービスがあり、そのうちの1つ（データベース）は開発環境で起動する必要がありますが、本番環境では起動しないでください。 したがって、2つのdocker-composeファイルを維持する必要があります。 オプション2はまさに私たちが探しているものです！

：+1：オプション2の場合

+1オプション2

@acranフィードバックを取得するための適切なプロセス/チャネルを見つけるために、ここSFのいくつかの接続に

オプション2の場合は👍

オプション2の場合は+1

+1オプション2

+1オプション2

また、私はオプション2に投票します

別のアイデア：トップレベルのnetworksとvolumesができたので、 imagesオプションも追加できます。 これは、アプリケーションが機能するためにこれらのイメージをプルまたはビルドする必要があることを作成するためのヒントになりますが、 docker-compose up実行すると実行されません。

これは、頭のてっぺんから離れた2つのユースケースで機能します。

1）ここでの一般的な問題。ある種の管理コマンドを実行する必要があります。 docker-compose runは、サービスが存在しない場合、実行中のイメージにフォールバックする可能性があります。
2）Dockerイメージを実行するこのようなアプリですが、常に実行されているわけではありません。

/ cc @dnephin @aanand @ shin-

短期コンテナが必要とするすべてのオプション（つまり、ボリューム/マウントポイント、ネットワーク、リンク、名前など）をdocker-composeファイルで構成できると便利な場合を除いて、そうしないようにします。そのコンテナを実行する必要があるたびにそれらを追加し続ける必要があります...

2016年9月13日午前3時58分41秒AM CDTには、ベンFirshmanの[email protected]は書きました：

別のアイデア：トップレベルのnetworksとvolumesができたので、
imagesオプションも追加します。 これは、これらを作成するためのヒントになります
アプリケーションを機能させるには、イメージをプルまたはビルドする必要がありますが、イメージは
docker-compose up実行すると、実行されません。

これは、頭のてっぺんから離れた2つのユースケースで機能します。

1）ある種の管理が必要なここでの一般的な問題
実行するコマンド。 docker-compose runは実行中のイメージにフォールバックする可能性があります
サービスが存在しない場合。
2）のようなアプリこれ
Dockerイメージですが、常に実行されているわけではありません。

/ cc @dnephin @aanand @ shin-

あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/docker/compose/issues/1896#issuecomment -246618909

K-9Mailを使用してAndroidデバイスから送信されました。 簡潔に申し訳ありません。

これについては@mgriegoに同意します。 ビルド生成コンテナについて考えてみてください。コマンドとオプションをすべて設定し、 docker-compose up fooだけを設定して、ビルドと終了を実行するのが最善です。

ここでより多くの理解を得ようとしています：オプション2）は、より一般的な「 docker-compose.yml initial_scale値が必要」の特殊なケースですか？ （＃1661、＃2496などを参照）

@ankonは

images追加[セクション]

@bfirshこれは、 https：//github.com/dnephin/dobiで取った方向に動き始め

1. networksとvolumesは、実際に直接操作されることはなく、コンテナによって必要に応じて作成されるだけです。 画像を独自のセクションに分割しても、現在の動作は変わりません。作成構成がより複雑になるだけです。 イメージを作成するだけの場合は、 docker-compose buildます。
2. この問題で特定された問題が実際に修正されるとは思いません。 人々は画像だけでなくコンテナを望んでいます

スレッドと、作成ファイルでのスケーリング制約の宣言に関する＃2496の説明を読み直すと、オプション2よりもオプション4（つまり新しいトップレベルセクション）を優先するようになりました。

具体的には、 utilitiesようなセクション名が適しています。通常は必要ないコンポーネントですが、必要な場合は、リンクする他のコンポーネントを事前に構成しておく必要があります。人々に適切なdocker run呪文を自分で構築してもらいます。

このアプローチでは、1回限りの管理コマンドだけでなく、pgwebやCelery Flowerなどの補助的なデバッグおよびイントロスペクションサービスもカバーされます（これらは開発で実行すると非常に便利ですが、セキュリティが強化されているため、通常は本番環境では必要ありません。彼らが作成する脅威の表面積）。

これらの新しい「notservices」のセマンティクスの定義もはるかに簡単になります。 docker-compose buildような非修飾コマンドを除いて、 services （その形式に対する今後のすべての変更を含む）と_正確に_同じです。 docker-compose build 、 docker-compose pull 、およびdocker-compose upそれらを完全に無視します。「サービス」ではなく「ユーティリティ」にリストされているコンポーネントを処理する場合は、具体的に名前を付ける必要があります（ただし、 docker-compose rmの現在のオプションと同様に、おそらく--allオプションである可能性があります。 ただし、これらのユーティリティを名前で操作するためのCLIは、通常のサービスを操作するためのCLIと同じであり（追加のユーティリティ構成ファイルを指定する必要がある現状とは異なり）、docker-composeが名前の競合を防ぎます。サービスとユーティリティの定義の間。

＃2496のスケーリング提案は、この動作を実現するために（ab）使用される可能性がありますが、適切に設計された機能というよりは、回避策のように感じられます。

私はそのデザインが好きです、@ ncoghlan。

utilities代わりに、 .servicesどうですか？ これは当然、 servicesと.servicesがまったく同じセマンティクスを使用することを伝えます。唯一の違いは、 .servicesがデフォルトで実行されないことです。 これは、デフォルトで表示されないファイル名に非常によく似ています。 欠点は、2つの違いが少し微妙なことだと思います。

@ncoghlanがそこで話している基本的な考え方は好きですが…

1. _all_unqualifiedコマンドがデフォルトでこれらのユーティリティを無視することに同意しないでください。 私の意見では、コンテナが実行されるコマンドを除いて、すべてのコマンドは正常に実行されるはずです。 （つまり、基本的に、 upとstartです。）
2. @dsemのコメントに関しては、「。services」よりも「utility」のセマンティクスの方が好きです。 私は一義的な隠しファイルの推論を理解していますが、これらは単なる隠しサービスではなく、サービスヘルパーです。

@bfirsh @ncoghlan @dnephinに完全に同意します：

この問題で特定された問題が実際に修正されるとは思いません。 人々は画像だけでなくコンテナを望んでいます

私（そしてここにいるほとんどの人）が私の希望するワークフローに必要なのは単純なサービスです。 通常のサービスと同じように定義され、通常のサービスと同じように開始/停止されます。
_only_の違いは、デフォルトでは単純なdocker-compose upによって自動的に開始されるのではなく、明示的に指定された場合（または依存関係としてプルされた場合）にのみ開始されることです。

したがって、これらの1回限りのコンテナーについて、新しいトップレベルセクションや完全に新しい概念は必要ないと思いますが、サービスごとの構成パラメーターはオプションです。
これは、概念実証としてプルリクエスト＃3047に実装しました。 これは非常に小さな変更ですが、私のユースケースを完全に満足させるでしょう。 それで、私にできることがもっとあるなら、これをマージするために、私に知らせてください（=

これをテストしたい人のために、ここにdocker-composeをコンテナーでビルドして実行するコマンドがあります。

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran 、関連するドキュメントとテストケースの更新をお手伝いしたいと思います。 大丈夫ですか ？

@ dattran-vn01もちろん、私は幸せです：smiley：

この例のup bazを使用して実行できます。
複数の作成ファイルを使用して同じことを実行することもできます。

一部のコマンドをデフォルトサービスの異なるリストで動作させることは非常に混乱しているように思われ、この機能が気に入らない理由の1つです。

あなたの例の@acranは、現在のComposeとは異なる動作をする唯一のコマンドであり、その動作は
複数の作成ファイルを使用して同じことを実行することもできます。

@dnephinはい、正確に、私は知っています、そしてこの例ではそれが最も簡単な方法でしょう。
しかし、これを10個のサービスと1回限りのサービス（「init」または「backup」/「dump」など）で想像してみてください。その場合、1つのサービスを除いてすべてのサービスをコマンドラインにリストする必要があります- docker-compose up service1 service2 ... service10ようなオフサービス（以下を参照）。 特に、すべてのサービスを覚えて、 docker-compose.yml変更を手動で追跡する必要があります。

複数のYAMLファイルを使用する可能性についても知っています。上記の最初のコメントを参照し

問題を視覚化するための別の例docker-compose.ymlを次に示します。

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

単純なdocker-compose up _with_ auto_up属性は、サービスinitを除くすべてのサービスをここから開始します。 それなしで同じことを達成するには、10個のサービスではるかに長いコマンドを入力するか、YAMLファイルを分割して複数のファイルを指定する必要があります。

したがって、ここで要求される機能は、完全に新しい機能ではなく、利便性とCLIでの入力の削減に関するものです。

「複数の構成ファイルを使用する」オプション（これは実際に現在利用可能な最良のオプションです）に関して、それに関するユーザビリティの問題は、実際には次のように見えることです。

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

次に、不一致がプロジェクトのドキュメントと自動化の_すべて_に影響します。ユーティリティコマンドを実行したいすべての人が_two_構成ファイルを使用できるようにする必要があります。ユーティリティファイル内のコマンドに対して完全な呼び出しが行われるようにする必要があります。コマンドがある場合は、または、サービスが「常に実行中」から「明示的に要求された場合にのみ実行」に降格される場合は、構成ファイル名を提供しない呼び出しを見つけて追加する必要があります。

これはすべて_実行可能_です。作成ファイルで「これは明示的に要求された場合にのみ実行し、デフォルトでは実行しないでください」と言うことができるのに比べて面倒です。

ある人が私にこう言ったことがあります。

このカードはこの典型的な例のようです:)

dockerが長時間実行されるコマンドに対してネイティブにサービスの概念をサポートするようになったため、最善のアプローチは、コマンドと呼ばれる新しいセクションを追加することです。これにより、再起動ポリシーを除いてサービスと同じ機能が可能になります。

私のセットアップでは、インフラストラクチャ（nginx、データベース、ウェブサーバー、メッセージキューなど）を実行するために必要なサービスがdocker-composeにあります。 また、デバッグの理由でのみ必要な追加のサービス（データベースのWeb GUIなど）を定義しました。

「デバッグ」サービスを自動的に開始しないようにしたいのですが、追加したい場合は、単純なdocker-compose up -d database-guiで追加でき、追加されるだけです。

また：時々気が変わって、これらのサービスの1つを常に開始したい... =>オプション2）を使用すると、その1つのフラグを変更できます

=>オプション2に投票してください。これは単純であり、ここですべての人の要件を満たしているように見えるためです。 他のすべてのソリューションは、私には過剰設計のように感じます...実際の必要性ではなく、まれな、または想像上のユースケースに基づいて構成を複雑にします。

私の+1を追加するためにここにあります。 私はDjangoアプリで実行していますが、Dockerで実行する場合は、シェルやテストを実行するコンテナー、さらに言えば移行コマンドを実行するコンテナーがあると便利です。 しかし、アプリを起動するたびにこれらのいずれも実行したくありません。 複数の構成ファイルを使用することはできますが、1マイルの長さのコマンドラインを入力、スクリプト化、またはエイリアス化する必要があります。 作曲をまったく使用しないようにしたい場合は、コンテナーをシェルスクリプト化するだけです（またはPythonスクリプトを作成します...コンテナー構成を格納するために統合YAMLファイルを追加します...待ってください...）コンテナでデータベースの移行を実行するためだけにdocker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrateようなことはしたくありません。 別の方法は、コマンドとして/bin/trueを使用し、 docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate'ようなことを実行することですが、これもエレガントではありません。 したがって、構成のどこかに1回限りのコマンドを格納しておくと非常に便利です。 オプション2、3、4のどれでも私にはうまくいくでしょう。

このスレッドからのフィードバックに部分的に基づいて私が取り組んできたツールであるdobiをご覧になることをお勧めします。

composeは、「環境」を形成する長期実行サービスを開始するように設計されています。
dobiは、シーケンシャルプロジェクトビルドタックに焦点を当てています。

探しているもの（シェルの実行、単体テストの実行、移行の実行）はすべてプロジェクトタスクであるため、dobiモデルにはるかによく適合します。

dobiとcomposeは非常にうまく連携し、 composeリソースを使用してdobiからcomposeを起動できます。

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

これを使用して実行できます：

dobi dev-environment

ここに、構成統合と実行中のデータベース移行の例があります： https ：

多くのワークフロー（テストの実行、インタラクティブシェルの開始、リリース、最小限のイメージの構築など）の例がここにあります： http ：

2）の場合は+1。 私たちの観点では、1回限りのコマンドのような珍しいユースケースを考えて議論する必要はありませんが、作成されてすぐに使用できる実際のサービスが必要ですが、必要に応じてオンデマンドで開始できます（デフォルトでは消費されません）リソース）。

「珍しいユースケース」？ データベースの移行を実行していますか？ ユニットテストを実行しますか？ lintを実行しますか？ webpack？

はい、私は走っていますが、私の意見では、それはコンテナ内で達成および制御できます。 しかし、私はあなたの見解や要求を損なうことを望まないので、この議論を炎上させないようにしましょう。 dockercomposeに関する要件は必ずしも矛盾していません。

mysqlコンテナ内のデータベースを消去し、ダウンロードしたダンプからスキーマを再ロードするスクリプト用のdocker-composeコンテナを作成する方法を見つけようとしているこのスレッドに出くわしました。 これは非常に時間のかかる破壊的なプロセスであるため、サービスを起動するたびに実行する必要はありませんが、独自のdockerfileを使用して構成されたコンテナーのセット内で実行する必要もあります。

それらをタスク、コマンドなどと呼んでください。

私はこれを偶然見つけて、他の何かを探していました。ユースケースにチップを入れたかっただけです...私たちの開発者は、サービスからバックアップするデータを定義する能力が最も高いことがわかりました。 docker-compose.ymlファイルが手元にあり、名前付きボリュームが使用されているため、これを使用してバックアップ戦略を定義することにしました...これは私たちが使用していた古いdocker-compose.ymlの要約例です。

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

ボリュームデータをバックアップできるようにするために、必要なデータをtarするためにbusyboxコンテナーを使用することにしましたが、柔軟性があり、開発者がバックアップしたいボリュームのみを実行する必要があります。 最後に、すべてのボリュームを個別にバックアップできるはずです。 これを実現するために、すべてのdocker-compose.ymlに3つのサービスを追加しました

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

バックアップおよび復元サービスは、ボリュームを使用して構成する必要があるだけで、残りはコマンドが実行します。 バックアップまたは復元するボリュームを選択できるように、構成を少し追加することを計画していますが、今のところ、すべてを実行します...これら2つのサービスをすべてのdocker-composeで開始したくないためです。 upコマンドでは、必要なすべてのサービスを指定する必要がありましたが、これは面倒な場合があります...そこで、bootというダミーのサービスを追加しました。実行する必要のあるすべてのサービスに依存するだけで、これを呼び出すだけです。 docker-構成します。

これは小さなハックでいっぱいですが、 docker-compose up backupを簡単に実行して、バックアップをホストの/ backups / latestに保存し、そこからバージョン管理/プルーニングロジックを実行できます。

同様のことを達成しようとしている人に役立つことを願っています...しかし、最終的には、docker-composeにこれらの2つのサービスを起動しないように指示できるので、3番目のサービスは必要なく、docker-composeupコマンド。

開発中、現在4つのdocker-composeファイルがあります。

• docker-compose.yml ：アプリを完全に操作するために必要なコアサービスを定義します。たとえば、redis、MySQL、php-fpm、Laravelキュープロセッサー、nginx、Solr
• docker-compose-utils.yml ：開発タスクの実行に必要なユーティリティサービスを定義します。たとえば、gulp、npm、artisan（Laravel）、composer、redis-cliなど、通常は上記のサービスで実行されます
• 上記のサービスの環境とボリュームを定義するためのさらに2つのdocker-composeファイル

Dockerの外部では、開発環境の依存関係が最小限であるため、このセットアップは適切に機能します。 欠点は、単純なユーティリティを実行するために必要なすべての.ymlファイルを指定するために必要な扱いにくいコマンドラインです。

macOS、Windows、Linuxで開発しています。 さらに、開発タスクの多くは何らかのパラメーター化を必要とするため（DB移行の作成、独自の引数を使用したcomposer / artisan / npmコマンドの実行など）、ゼロインストールクロスとしてschmich/runxを作成しました。一般的な開発タスクをバンドルするプラットフォームタスクランナー。

たとえば、これにより、 runx merge ：make create_some_tableを使用してdocker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_tableを効果的に実行したり、 runxnpmを古くして古いJS依存関係を表示したりできます。

上記のdobiは使用していませんが、 runxは、Docker環境に合わせて調整されていませんが、精神的には似ています。 最終的には、絶対に必要な場合を除いて、どこでも依存関係を避けたいと思います。サービス自体と、開発に必要なユーティリティスクリプトです。

連絡あった？ この機能があれば本当にいいと思います！ defaultようなトップレベルの構成のソリューションに投票します。ここでは、実行する必要のあるサービスを指定できます。
bootダミーサービスは素晴らしいですが、私はプロセスをフォアグラウンドのままにしておくことを好みます。したがって、この作業が終了したら、ターミナルを閉じるだけですべてを停止できます。 デフォルトで出力をアタッチするのも良いことですが、これはダミーサービスでは発生しません。

nobobyが.envファイルを使用してユースケースにコメントしたので、ここに私のものがあります：

docker-compose.yml、docker-compose.local.yml、docker-compose.prod.yml、docker-compose.ci.ymlの4つの作成ファイルがあります。 環境ごとに異なる.envがあります。

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

等々...

環境はすでに個別に構成されているため、ユーザーやスクリプトは、使用する作成ファイルについて心配する必要はありません。

しかし、最終的に実行するメンテナンスインスタンスがあり、メインのdocker-compose.yml内で構成することはできません。解決策のひとつは、docker-compose.worker.ymlを作成し、3つの「-f」オプションを変更してコマンドラインを実行することです。各環境で。 これはエラーが発生しやすく、使用可能なオプションにはなりません。

私が見つけた解決策は、ディレクトリ「worker」を作成し、そこにymlファイルを配置し、上位の.envファイルをこのディレクトリにリンクして、空のdocker-compose。[ci | local | prod] .ymlファイルを作成することでした（そうでない場合は、 COMPOSE_FILE変数の値を変更します）。

これは問題なく機能しますが、最適とは言えません。 OPの他のソリューションは、混乱することなくこれを解決します。

ここでの議論、多くの使用例の例、およびこれに頻繁に重複する問題があるという事実は、「デフォルトで開始されないサービスを定義する」可能性に対する多くのユーザーによる実際の要求があることを明確に示していると思います。 "。

そのため、ここでの議論を、これをもっと実装する必要がある場合から、どのように実装する必要があるかということに移したいと思います。 私たちはおそらくこれに同意できますか？

_how_に関して、これは達成できました@bfirshは、冒頭のコメントにいくつかのオプションをリストしました。

1）別の作成ファイルを使用するようにユーザーに推奨する

これは、このユースケースで現在利用可能な唯一のソリューションです。 ただし、上記のように、この場合は、長いコマンドラインを手動で入力し、実行するコマンドに含める作成ファイルを覚えておく必要があるため、より多くの回避策があります。
もちろん、CIセットアップまたは本番環境への自動展開では、これは問題ではありません。コマンドラインを一度定義するだけで、手動で入力する必要がないためです。 したがって、これは、自動化されていない環境、つまり、 docker-composeマニュアルによるとCompose自体の主なユースケースの1つである開発での利便性に関するものです。

これらの機能を組み合わせることで、開発者がプロ​​ジェクトを開始するための便利な方法が提供されます。 Composeを使用すると、複数ページの「開発者入門ガイド」を1つの機械可読なComposeファイルといくつかのコマンドに減らすことができます。

ローカルセットアップを初期化するためだけにdocker-compose -f docker-compose.yml -f docker-compose-utils.yml run initようなものを入力する必要があることは、私には_便利_に聞こえませんが、_複数ページの「開発者入門ガイド」_にあるようなものです。

そして、ここでオプション1b）を検討します。

ラッパースクリプト/ツールを使用して個別の作成ファイルを使用することをユーザーに推奨します

このためだけに追加のツールと依存関係を取得する必要がある場合、そもそもなぜdocker-composeを使用するのですか？ docker-composeが行うことはすべて、理論的には、カスタムシェルスクリプトとネイティブのdockerクライアントだけで直接実行することもできます。
標準化されたユーザーインターフェイスにdocker-composeの主な利点があります（プロジェクトのクローンを作成し、そこにdocker-compose.ymlがあり、開始するにはdocker-compose upを実行する必要があることを知っています） 。 この利点を大幅に弱めるものに使用する作成ファイルを常に知る必要があります。

2）サービスにオプションを追加して、デフォルトで開始しないようにします
3）最上位の構成オプションを追加して、デフォルトのサービスを定義します

これらの2つのオプションは、基本的に同じです。1つの作成ファイルでデフォルト
ほとんどの場合、単一の作成ファイルに「1回限りのサービス」よりも多くのデフォルトサービスがあることを考えると、他のすべてのサービスをホワイトリストに登録し、デフォルトサービスが取得されるたびにホワイトリストを更新するよりも、1つのサービスをブラックリストに登録する方がおそらく簡単です。追加または削除されました。 また、オプション2）を使用すると、複数の作成ファイルをマージする方がおそらく簡単です。

4）サービスのようなものの概念を追加しますが、これは1回限りのコマンド（「スクリプト」、「タスク」など）専用です。

上記の例のほとんどでは、目的の1回限りのコンテナーは基本的に他のサービスと同じように定義されており、通常のサービスとほぼ同じように定義されているため、オプション4）はオプション2）または3）の特殊化にすぎないと思います。 'デフォルトでは開始されません。 （または、「サービス」との大きな違いを見逃しましたか）。

したがって、私の意見では、オプション2）が最適です。変更が最小限で済みますが、同時に、ここで説明するほとんど（またはすべて？）のユースケースを満たすのに十分な柔軟性があり、同時に使用すると非常に便利です。
それでも、オプション3）または4）のようなものがアップストリームにマージされるのを見るのも同様に嬉しいです。 それで、ここで1年以上議論した後、これがいつ起こるか、または起こるかどうかのタイムラインはありますか？

オプション2がおそらく最も侵襲性が低いことに同意します。 オプション4が提供する可能性がある唯一の機能は、既存のコンテナーでコマンドを実行する機能です（docker execメカニズムを使用）。 たとえば、データベースの移行または単体テストを実行するだけの場合、アプリを実行しているコンテナーが既にある場合は、そのコンテナー用にまったく別個のコンテナーを作成する理由がない可能性があります。 とは言うものの、コンテナは軽量であり、オプション2で完全に満足しています。

@MadWombatオプション4についても同じ気持ちです。そのため、このユースケースに別の機能を提案しました：＃4096。 ここで説明する機能と重複していますが、それ自体で、またはこれに加えて役立つ可能性があると思います

@mathroc @acranがオプション2と4の間に有意差があるかどうかを尋ねたので、 docker execを使用してオプション4について言及しました。ただし、具体的にコマンドを実行したい実際のユースケースを思い付くことができません。目的のために別の同様のコンテナを立ち上げるのではなく、既存のコンテナ。 一部のサービスまたは既存のコンテナによってすでに使用されている他の制限されたリソースへの永続的な接続が制限されているシナリオがあるかもしれませんが、私はそれを考えることができません。

オプション4が提供する可能性がある唯一の機能は、既存のコンテナーでコマンドを実行する機能です（docker execメカニズムを使用）。

これは確かに、サービスとは異なる新しいトップレベルの概念を導入することを正当化する（そして必要とする）新しいユースケースです。 ただし、既存のサービスコンテナ内でdocker execを介してコマンドを実行する必要がない限り、既存のサービスの概念で十分です。

ただし、その目的のために別の同様のコンテナーを起動するのではなく、既存のコンテナーでコマンドを実行したいという実際のユースケースを思いつくことはできません。

私が考えることができる最も近いケースは、コンテナー内の構成ファイルを変更し、アプリケーションによるリロードをトリガーするようなものです。 ＃4096の@mathrocの例を使用：

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

この問題に関連していますが、＃4096には独自のユースケースがあり、オプション4）をそこに移動するのが最善でしょうか？

1年以上の議論があり、私たちはこれ以上先に決定を下すことができないようです。 @bfirshはスタイルを選んでそれを

+1

+1、それは非常に便利な機能です。

そして、オプション2の+1は、 auto-start: falseやenabled: falseです。

私のユースケースはサービスの拡張です。 depends_on設定されているサービスを拡張することはできないので、私がやりたいのは、サービステンプレートを定義し、そこからいくつかのサービスを拡張することです。 明らかに、テンプレートを作成する必要がありますが、自動で実行しないでください。

私は独自のソリューションを作成し、自由に使用できるようにしました。
まだベータ版です:)

https://github.com/jonathanborges/picles-docker

ここにはたくさんの素晴らしいオプションがあります。 この機能の必要性は現実のものです。

オプション2は、明らかにより人気のある出来事です。

1-> 4
2-> 52
3-> 3
4-> 10

オプション2の別の👍

これは、最初のエントリポイントまたは単に戻るコマンドを使用する「ツール」サービスでかなり簡単に処理できます。 次に、別のコマンドを使用してこのサービスを実行し、必要な処理（テストやデータのシードなど）を実行します。 例えば

docker-compuse up -d
docker-compose run tools tests

はい、ツールサービスはdocker-compose psで「停止」と表示されます。 これが受け入れられない場合は、 https：//github.com/docker/compose/pull/2051のマルチファイルオプションが機能し

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

多くのオーケストレーションヘルパーがこの必要性のために書かれているように見えますが、私も1つに取り組んでいる罪を犯しています:)。

個人的には、十分な回避策があり（上記の2つ、エントリポイント/コンテナでクリエイティブになる、および/またはシェルエイリアス/ヘルパーでマルチファイルアプローチを使用する）、作成をシンプルに保つことができると思います。

@briceburgは、上記の説明を参照してください。ここでの問題は、他の方法では実行できなかった機能の欠落に関するものではありません。 ここの人々が達成したいほとんどすべての回避策があります。 しかし、それらはdocker-composeの通常のユースケースではなく、回避策とダーティハックです。

それは便利さについてであり、CLIでdocker-compose -f docker-compose.yml -f docker-compose-tools.yml upを手で入力する必要がないことについてです。それがdocker-compose run tools testsかdocker-compose run utils testsかを覚えておく必要がないか、あるいは頼る必要さえありません。 _複数ページの「開発者入門ガイド」_ですが、代わりに開発者向けの統一されたシンプルなインターフェイスを備えています。

ここでも、CCing @bfirsh、@dnephin：あなたはこの問題に_any_フィードバックを提供してくださいだろうか？ docker-composeの今後のロードマップでこのようなものを見ることができるという希望はありますか？

単純な環境の@briceburgは、回避策が受け入れられる場合もありますが、受け入れられない場合もあります。 私の設定を見てください：

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

workerディレクトリにあるファイルの他に、8つの作成ファイル（複数の組み合わせで使用）があり、「デフォルトでは開始しない」コンテナーを構成します。 workerディレクトリ（親にリンクされた.envファイルと、親の.env COMPOSE_FILE変数に準拠するためのいくつかの空の作成ファイルを含む）が私の回避策ですが、次のソリューションがあれば、私の生活ははるかに楽になりますこの問題。

@vipseixasファイルリストからこのソリューションの健全性を

ほとんどの場合、テストを実行する前に、依存するサービス/コンテナーでヘルスチェックが渡されることを確認する必要があります。たとえば、これらのテストを実行する前に、jenkinsが稼働している（：8080などで接続を受け入れる）。 以前、私はこれにdockerizeを使用しました。

特効薬を提案する場合、環境変数（DOCKER_COMPOSE_PROFILE = "tests"など）を介して作成プロファイルを設定できるようにし、サービスをプロファイルに依存できるようにします。すべてのサービスはデフォルトで「デフォルト」になります。 「プロフィールか何か。 また、別のサービスに依存しているサービスも、そのサービスのHEALTHCHECKに_依存_していることを確認します。 だから何かのような

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

オプション2の場合は+1。

ここの多くは興味深い新機能を提案していますが、ここでの問題の核心は何ですか？ 私はそれをできるだけ単純に保つことに投票します。

現在のところ、docker-compose.yml内のすべてのサービスはdocker-compose up起動されると想定しています。 私たちは皆、独自のカスタムブートストラップスクリプト、makefile、ビルドツールなどを使用しています。幸い、docker-composeとdockerはどちらも、キッチンシンクが「稼働」すると、個々のコンテナーを管理するための広範なAPIを公開します。

私の唯一の必要性、この議論に私を導いた中心的な必要性は、私が定義したサービスの1つが、何らかの理由でデフォルトで「アップ」したいものではないことを指定することです。

私たち全員にとって「それを成し遂げる」最も簡単な機能は何ですか？ これは、 docker -compose.yml仕様（ autostart: false指定できます。

私は投票します：「私たちのために何かをしてください、ありがとう」。 投票します。少なくとも1つの答えが必要です。 4神！

私たち全員にとって「それを成し遂げる」最も簡単な機能は何ですか？ これはdocker -compose.yml仕様（

それは他のどの選択肢よりもずっと良いです:)

とても簡単です。
scale: 0
https://github.com/docker/compose/issues/1661

@ drew-r何？

@ jonathanborges1542 docker-compose scale servname=2です。 docker-compose.ymlファイルに同等のものはありません。

@ drew-r scale: 0現在、サービスのすべてのコンテナーにSIGTERM / SIGKILLを送信するようにdockerデーモンに指示しています。 これにより、メンテナンスジョブがまだ完了していない場合でも、メンテナンスジョブが強制終了されます。 それが予想される動作です。 これを変更することは、現時点で明確な動作であるものをオーバーロードする悪いケースになります。

@gittycatわかりましたが、ここで必要なのは「docker-compose up」と入力することで、すべての準備が整います。 その場合、それは機能しません。

私はこのトピックを1年以上フォローしています（ほとんどの投稿はDocker側にあります）。
「サービス」、「ボリューム」、「ネットワーク」と共存する新しいトップレベルの「仕事」が最良の選択肢だと思います。 これは、上記のOPリストのオプション4です。
これは、Dockerリポジトリでの提案でもあります。
https://github.com/docker/docker/issues/23880

@briceburg

ファイルリストからこのソリューションの健全性を判断するのは困難です

多くのファイルの組み合わせがあり、複数の「-f」オプションを使用するとエラーが発生しやすく、手動で実行できないことを示すことが目的でした。

自動起動したくないサービスに対しては何もしないデフォルトのエントリポイント/コマンドを使用することをお勧めします。

時には運命から逃れることはできません。 しかし、私は自分の解決策を好みます。「構成」されることのない別のディレクトリを使用するので、環境を汚染する無駄な停止コンテナはありません。 そのため、親「.env」にリンクされた「.env」を持つワーカーディレクトリがあります。

特効薬を提案する場合は、環境変数（DOCKER_COMPOSE_PROFILE = "tests"など）を介して作成プロファイルを設定できるようにします。

それが最善の解決策です。 しかし、開発者が複雑さを増す傾向があるとは思いません...

ベースイメージを作成し、これを同じdocker-compose.ymlで「拡張」して、2番目のイメージのみを開始します。これは、現時点では1つのステップでは実行できません。 オプション2の場合はそうなりますが、ベースイメージの作成が行われる「ビルドステージ」と「実行ステージ」を使用する方がより適切でクリーンな方法かもしれません。 現時点では、1つだけでなく2つのコマンドを実行する必要があります。

+1 @ draw-r＃1661

この問題はある時点で実装される予定ですか、それとも構成開発者がやりたくないことですか？ コミュニティが別の解決策を探し始めることができるように知っておくといいでしょう。

ちなみに私はオプション2に投票します。

ありがとうございました

オプション2の場合は+1。
ただし、明示的な依存関係は尊重されますか... linksなど？

docker-compose up [service]で起動するサービスを指定している場合、問題のサービスとその依存関係以外のサービスを開始することはめったにありません。

オプション2への別の投票。 @ acranが作成して

作成開発者がこれを望まない場合は、それを一度だけ述べてから、チケットを閉じてロックし、コメントを防ぐ必要があります。

@msabramoの作成は、基本的にDockerエンジンレベルで決定される内容によって妨げられます。

リクエストは、Dockerエンジンリポジトリhttps://github.com/docker/docker/issues/23880で追跡され
そこから決定/作業が行われます。

この問題を解決することをお勧めします。

@gittycat composeには、エンジンにサービスを開始するように指示するかどうかのオプションがあります。 これはまだ非常に有効なリクエストです。

私は本番環境でDockerをあきらめましたが、多くの問題があります。 次に、vagrantに移行します。

2）への別の投票

2と4の別の投票。

ユースケースを指摘するために、一部のサービスには循環依存関係があり、構成ファイルを生成する必要があり、他の多くの可能性の中でテストスイートを実行します。 Dockerから切り離したり、他のツールを使用したりできますが、プロジェクトの設定が不必要に複雑になります。

セットアップやテストのための簡単なコマンドがあると、物事がずっときれいになります。

2にもう一度投票してください！

このスレッドを読んだことがありますが、新しい投稿（https://github.com/docker/compose/issues/4650）を作成することにしました。この投稿は閉じられ、ここで紹介されました。 私が言いたかったのは、このスレッドでの議論のほとんどは実行中のコンテナーを無効にするフラグに関するものですが、私のユースケースは3番目の状態であるコンテナーの作成です。

コンテナーが実行されないようにするだけでなく、最初からコンテナーを作成できないようにしたい（私のユースケースでは、これを実現するユーザー主導のプロセスがあります）

@ekkisどうしてそうなったのか

あなたの問題についてもっと詳しく教えていただけませんか？

@frnco 、あなたが何についてもっと詳しく知りたいのかわかりません。 コンテナを作成せずにイメージを作成したい場合があります。 私のはそのようなケースの1つです。 特定の画像を他の多くの画像と一緒に作成したいのですが、この特定の画像は、私が作成したプロセスで使用されます。 ビルドするための2つの別々のプロセスが必要ではなく、 build-onlyフラグを設定すると、その問題を解決できます。

@ ekkis ＃963を

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

オプション2の場合は+1

：+1：オプション＃2で、この機能の見積もりについて質問がありますか？ 最善の回避策は何ですか？ 私が想像できる限り、次のようなすべてのサービスをリストする必要があります。

docker-compose up service1 service2 service3

...そしてデフォルトで開始したくないものを省略します

オープンソースコミュニティの私たちが、強く要求されているように見えるこの機能に貢献できる方法はありますか？

オプション2の場合は+1。
'ステージ'を指定する方法は素晴らしいでしょう。 たとえば、サービスは本番環境でのみ実行されます。

オプション2の場合は+1。

オプション2に投票する

upコマンドフィルタリングは完璧です– docker-compose up service1 service3

：+1：オプション2および4の場合

この時点で、オプション2がユーザーが望んでいることは明らかです。 これを実現するための次のステップは何ですか？

ここでオプション2の+1に、この機能がすでに存在することを期待してこの問題に遭遇しました。

オプション2で+1

...そしてオプション2の場合はもう1つ+1

オプション2の場合は+1

オプション2の+1 :-)

オプション2および4の場合は+1

こんにちは、みんな、
+1オプション2

IMHO、オプションは、マイクロサービスまたは六角形のアーキテクチャに基づくアプリケーションがある場合、ローカル環境で非常に役立ちます。 開発者として、私は自分の最も近い仕事に必要な要素だけを実行できます。

オプション2は、ほとんどのユーザーが望んでいるものです。 これに関する決定はまだ行われていませんか、それともこれに関する開発が開始され、どこかで追跡されていますか？

数か月で大学を卒業して時間があれば、この機能を自分で実装する方がはるかに速いと思います（ただし、composeが書かれていると思うPythonを学んだことはありません）が、それを見ました。膨大な数の投票とリクエストが2年間、前進することなく、自己実装が次の5年間の解決策のようです（その機能が正式に実装されるまで）。

もちろん、オプション2の場合は+1000

+1オプション2

オプション2に投票した場合、違いはありますか？ 'そうなる可能性は低いようです。

ここでのコメントは最近、不気味になり、新しいフィードバックは実際には表面化していないため、このスレッドをロックすることを検討しています。 ここでやり取りするときは、礼儀正しくしてください。

これは、この問題に関するメンテナチームの現在の公式の立場です。 この機能を追加するか、または同様の機能を便利なオプションとして追加するかはまだ検討中ですが、強調表示されている理由と、それに適した他のツールが存在するため、優先事項ではありません。

@ shin-これをロックする前に、コミュニティが開発する意思があるかどうかを明確にすることができますか？コアチームは、チームの基準を満たしている場合、それをマージしますか？ スレッドには、実装とそれを完了することをいとわないコミュニティメンバーがあり、彼らはそれが彼らの投資の無駄ではないといういくつかの確認を探していました。 フィードバックを得ることができれば、それらのスレッドを追跡して移動し、これをクロージャに移動できるかどうかを確認します。

@jimzuckerいいえ-ここでの問題は実装ではないためです。 これの基本的な実装は、平均的な開発者にとって半日かかります。 ここで懸念しているのは、基本的な設計の問題です。

1. サービスとは何ですか？ 設計上、サービスは明確に定義された長期実行プロセスであり、他のサービスと相互作用してアプリケーションを形成します。 これは、Composeが動作する基本的な前提であり、実装するすべての機能ではないにしても、ほとんどの設計をガイドします。
2. その定義によれば、「デフォルトで開始されないサービス」は実際にはサービスではありません[1]。これは、コンテナーの一部ではなく、コンテナーで実行され、アプリケーションで動作する、事前定義されたタスクです。
3. したがって、それをサービスと呼ぶのは（基本的には設計上）間違っています。 その時点で、Composeファイルに新しいタイプの定義を作成することを検討する必要があります（簡潔にするために「タスク」と呼びます。正確な用語はここでは重要ではありません）。
4. タスクは本質的に短時間実行されるプロセスであるため、サービスとは異なるオプションのセットを使用します。 たとえば、タスクがポートを公開する必要がないことを直感的に理解できます[2]。 一方、 CIDファイルのような、サービスにはほとんど意味のないオプションは、タスクに非常に役立つ可能性があります。
5. 現在、ほとんどのプロジェクトでは、タスクに依存関係チェーンがある傾向があります（そのため、従来の非コンテナーの世界では、Makefileがあります）-したがって、並列処理を備えた依存関係チェーンの少なくとも基本的な実装が必要です。常に10分かかる1つのJARビルドタスクを実際に再度実行する必要がある場合。
6. 次に、一部のサービスは、開始する前に実行されたタスクに実際に依存しているため、依存関係の計算方法と処理方法がさらに複雑になります。
7. また、一部のタスクを実行するには、いくつかのサービスを起動する必要があります（データベースの移行など）。

この時点で、これは、スコープと複雑さの点でおそらくcmakeに一致するか、それを超えるまったく新しいコードになっています。 これが、これを長い間実装することに抵抗した理由です。これは、Composeが意図したことではないこともありますが、[3]この機能を実装または維持するための時間やリソースがないためです。人々にとって本当に役立つものになる必要があるでしょう。

うまくいけば、これは物事をもう少し明確にします。 私は人々がこのスレッドでの応答（またはその欠如）に動揺して失望していることを知っています、そしてこれが何らかの形でそれを軽減するかどうかはわかりませんが、それはあります。

[1]「オプションのサービス」が必要だと言う人もいますが、それはこのスレッドで言及されている最も一般的なユースケースではありません。 私の知る限り、ほとんどの人は「タスク」機能を望んでいます。
[2]ポートを公開する必要があるタスクの例で誰かが私と矛盾することは間違いありません。これは、各セットに適用できるオプションを決定する練習が簡単ではないことを示すだけです。
[3]そして、現時点でdocker-compose積極的に取り組んでいるのは私だけなので、この時点で私は「私」を意味します。

@ shin-要点がわかります。 私が追求しているのは、脚注の「オプションサービス」とそのユースケースであり、タスクのアイデアではありません。それは私が擁護しようとしているスレッドの一部であったため、そのポイントをどのように進めることができるかについて、どういうわけか合意できますか。私のチケットは、このスレッドを支持して閉じられたそのパス上に明確にあります。 あなたが「タスク」として明確に定義したポイントからそれを分離することができれば、私たちはいくらか前進することができます。 私の読書で人々がオプション2に対して+1をしているとき、それはオプションのサービスに対するものです。 これをオフラインにして話し合い、フォーラムに戻ることができます。私は[email protected]にいます。

@ shin-あなたのポイント＃2は間違っています。 サービスは、実行されているかどうかに関係なくサービスです。 依存関係が利用できない場合に依存サービスが動作を変更するユースケースは無数にあります。そのため、アプリケーション層では、すべての「サービス」が常に利用可能である必要はありません。

最も伝統的な用語で考える場合、Webサーバーは「サービス」であると考えてください。ただし、特定のホストでデフォルトで起動しないようにシャットダウンまたは構成することはできますが、サービス以外のことは誰も考えません。

この機能を要求している多くの人は、タスクではなくオプションのサービスを実行したいと思っていると思います。 たとえば、Dockerコンテナーとして実行されている一連のマイクロサービスがあり、それらすべてをサービス全体としてデプロイする場合、いつか要件が変更され、すべてのサーバーですべてのコンテナーを実行する必要がなくなる可能性があります。必須ではないコンテナーに含まれている特定の機能は必要ありません。

さらに、これは開発環境にとって素晴らしい機能だと思います。 特定のコンテナのバグを修正する場合、そのコンテナのすべてのコンテナを起動する必要はありません。

正確に言えば、単純なブールフィールドを使用すると、 .envファイルからサービスを簡単に有効/無効にし、yamlファイルの編集を回避できます。

@ekkisフォールトトレランスとディスペンサ

全員：アプリケーションで一部のサービスがオプションである場合、現在の機能でこれを処理することはすでに可能であることに注意してください。 これを行うための推奨される方法は、 -fフラグを使用して含めたり除外したりできる個別の作成ファイルを用意することです。 これらは、このオプションを追加するための非常に説得力のある議論ではありません。

@ shin-この対話に時間を割いていただきありがとうございます。 複数のymlファイルを提案すると、サービスのリストを渡すこともできますが、これらは便利ではなく、ユーザーエラーが発生してオペレーショナルリスクが発生するため、いくつかの方法があることに同意します。 特に商用製品の場合、1つの作成ファイルを配布し、デフォルトで目的の一般的な動作を取得して高度なオプションの指示を出します。1つのファイルで、開発、CI / CD、および配布の両方でこれほどすっきりします。 デフォルトでENV変数を追加することは、私たちにとって大きな助けとなり、多くのymlファイルを持つ必要がなくなりました。これは、デプロイメントを記述する単一のファイルを管理するためのもう1つのステップになります。

コアチームがこのLMKへの貢献を喜んで受け入れる形はありますか。

@shin 、フォールトトレランスまたはディスペンサ

@ shin-私は@ekkisに強く同意します：開始されないことは_デフォルトで_サービスであるという定義に違反しないので、あなたのポイント2は_必ずしも_真実ではない仮定であり、連続するポイントは2の仮定。

例：mysql DBを使用してアプリケーションを開発する場合、通常、追加の_service_ phpmyadmin定義します。 これは真のサービスです。他のサービスに依存する、長時間実行され、公開されたポートです。
しかし、私はこのサービスを_デフォルトで_開始したくはありませんが、_オンデマンド_ /開発中のみです。
現在、このサービスを追加のdocker-compose.yml 、両方のファイルをdocker-compose提供することで開始することで、これを実現しています。上記で提案したとおりです。

したがって、はい、これを達成するための可能な方法はすでにあります。 サービスを複数のファイルに分割するか、 docker-compose以外のツールを使用するだけです。 しかし、すでに上で書いたように、この問題は、まったく新しい機能/機能や新しい概念（つまり、_tasks_）に関するものではなく、特に開発環境における利便性に関するものです。
docker-compose -f docker-compose.yml -f docker-compose-tools.yml upを入力しなければならないのは便利ではないので、 docker-composeはそれ自体の約束を果たしません。

これらの機能を組み合わせることで、開発者がプロジェクトを開始するための便利な方法が提供されます。 Composeを使用すると、複数ページの「開発者入門ガイド」を1つの機械可読なComposeファイルといくつかのコマンドに減らすことができます。

どのサービスを開始するか、またはどのymlファイルをどの環境で使用するかは、通常、_multi-page「開発者入門ガイド[s]」_にあります。

したがって、私の意見では、 @ jimzuckerが書いたように、ここでのほとんどの+1は、タスクの新しい概念ではなく、実際には「オプションのサービス」のためのものです。 少なくともそれらのすべては、デフォルトで開始されるかどうかにかかわらず、_service_にフラグを立てる単純なブール値を使用する方が適切です。

私のPoCが示すように、「オプションのサービス」に必要なコードの変更は非常に管理しやすく、ここのほとんどの人に利便性の大きなメリットを提供します。 オプション2-「_サービスをオプションとしてマークする可能性_」と読む-は、この問題を解決するための妥当な妥協案です。

@ shin-ユーザーにサービスをオプションとしてマークする可能性を与えることに同意しませんか？しかし、それらはまだサービスです-彼らを大いに助けますか？
「_services_をオプションとしてマークする/デフォルトでは開始されない」に減らすと、この問題/これに対するプルリクエストは受け入れられてマージされますか？

@shin 、上記の@acranのポイントに追加するために、 名前を使用する他のサービスによって実行されるためです。 私はすべての時間は「アップ」私は、彼らがデータベース内の情報を使用して実行する必要があるとして、これらは意味をなさないなどproject_app_1という名前の「サービス」、project_otherapp_1の束を得ることを考える（私は、マスター・サービスを持っているキックオフそれらを） 。 だから私はいつも彼らを殺さなければなりません。 したがって、私にとってNO_RUNまたはBUILD_ONLYフラグは完全に理にかなっています。 これは便利でしょう

@acran

ユーザーにサービスをオプションとしてマークする可能性を与えること（しかし、それらはまだサービスである）が彼らを大いに助けることに同意しませんか？

私はそれがどれほど役立つかについては同意しません-私は「大いに」誇張されていると思います。 あなたの例では、オプションで含めることができるdocker-compose.phpmyadmin.ymlを持っているだけで、環境変数を設定したり、メインファイル内のサービス定義を変更したりするよりも（「開発者ガイド」の説明に関して）煩わしく複雑ではありません。
また、厳密に必要ではない場合に、開発者に「フットガン」を提供することのトレードオフも検討しています。

「サービスをオプションとしてマークする/デフォルトで開始されない」に減らすと、この問題/これに対するプルリクエストは受け入れられてマージされますか？

上記を参照してください–この機能が利用可能になるとすぐに、人々はそれを意図された目的以外の目的で使用し始め、それをサポートするための新しい機能セットを実装することを期待します。 また、cc @jimzucker ; 私は現在、このシナリオの展開を妨げる実装を考えることはできません。 できれば、この問題はずっと前に解決されていたでしょう。

@ekkisこれらのサービスを自分で開始したくない場合、それらを別のファイルに分離することがなぜ問題になるのでしょうか。 なぜこれがここでそんなにハングアップするのか、私は本当に混乱しています。

@shin docker -compose.ymlを使用してサービスをビルドできる場合、ビルドプロセスを一元化するのに最も便利なツールです。 実際には、実行する前に（条件付きで）サービスを構築したいというのは非常に理にかなっています。その機能に拍手を送ります。

したがって、docker-composeファイルは私のmakefileでもあります。 しかし、何かを構築したからといって、それを実行したいという意味ではありません。 docker-composeは、サービスを実行し、その名前を考案し、適切なパラメーター/環境変数などを使用せずに実行することを想定しても意味がありません。

率直に言って、この単純なパッチに対する異議が何であるかを理解できません。 それは私にとって非常に役に立ちます

以前の投稿で、チームの公式の見解が、作成ファイルをMakefileとして使用してはならないということを明確に指摘しました。 私たちがこれについて間違っていると信じていて、それでもそうしたいのであれば、それはあなたの特権ですが、それをサポートする機能を追加することを主張するのは少し馬鹿げています。

@ shin-

あなたの例では、オプションで含めることができるdocker-compose.phpmyadmin.ymlを用意するだけで、環境変数を設定したり、メインファイル内のサービス定義を変更したりするよりも煩わしく複雑ではありません（「開発者ガイド」の説明に関して）。

実際、私はまだここで環境変数を含めることを考えていませんでした。 私が望むワークフロー「オプションサービス」が最終的に許可するのは次のとおりです。

• 新しいプロジェクトをコピー/クローンします
• （単一の） docker-compose.ymlファイルが含まれていることがわかります。したがって、 docker-compose upを実行するだけで、アプリケーションがビルドされて実行されます。
• ここで、開発目的でオプションのサービスの1つを開始したいと思います（追加のデバッグ、phpMyAdminなど）。 私がしなければならないのはdocker-compose up phpmyadminです。

私にとって、これは複数のdocker-compose.ymlファイルを使用するよりもはるかに便利であり、他のほとんどの人にとっても理解できます。 ここに「オプションサービス」があることの利点は

• 開発者は、複数のファイル間で何も複製する必要がなく、どの定義をどのファイルに入れるかを慎重に検討する必要はありませんが、サービスに1つのブールフラグ（ auto_up: false ）を設定するだけで済みます。
• どのサービスにどのファイルを含めるかをユーザーが知っている/覚えている必要がない場合：実行する必要がありますか
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml upまたはさらに
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ？
  
  
• 代わりに、ユーザーが_知る_必要があるのは、 phpmyadminというサービスがあり、ユーザーはそれを開始する方法をすぐに知っているということだけです。

上記を参照してください–この機能が利用可能になるとすぐに、人々は意図された目的以外の目的でそれを使い始め、それをサポートするために新しい機能セットを実装することを期待します

誤解しないでください、私はここであなたの懸念を理解するだけでなく、それに同意します：機能が意図されていなかったとしても、この機能または他の（！）機能を希望のワークフローに合うように曲げるユーザーは常に存在しますそのように使用されます。
しかし、「タスク」の機能が不足している「オプションサービス」に対するリクエストについては、サービスはタスクではなく、タスクは最初に新しい概念として導入する必要があるため、（まだ）サポートされていないと簡単に主張できます。 つまり、サービスをオプションとしてマークするだけではなく、タスクの概念（オプション4など）への一歩であり、その間に明確な切り口があります。

_service_をオプションとしてマークする機能により、私たちはまだそのカットの右側にいます。 「この機能自体は実装するにはそれほど複雑ではありませんが、ユーザーが誤って使用するように誘惑する可能性があります」現在、この機能に反対する唯一の本当の（有効ではありますが！）議論は、実装しない理由としてはかなり不十分です-少なくともそれを正しい方法で使用しながら、それから多くの利便性を得ることができたユーザー™。

私はプルリクエスト＃3047を現在のマスターにリベースし、これが受け入れられるために必要な研磨を行います。お知らせください;）

私のユースケースは、すべてのイメージをDocker HubまたはQuayにプッシュしたり、独自のレジストリを持ったりしないことです。サービスをデフォルトで実行されないものとしてマークできるということは、できることを意味します。 docker-compose.ymlで定義された、開始されないベースイメージがあり、それを使用するか、その上に構築されている他のコンテナーがあります。

この特異な機能のためだけにこの機能を実装するdocker-composeフォークを使用する傾向があります。

@ shin-私たちは皆あなたの主張を理解し、それに共感していると思いますが、「誤用されるかもしれない」というのは、明らかに多くの実行可能なユースケースを持つ何かの良い議論ではないと思います。 もちろん、それは誤用されます。 それがまさにソフトウェアと新しいアイデアが成長する方法です。 テクノロジーを完全に使用することから。 過去25年間、提供されたすべてのテクノロジーを悪用していなければ、Webは今日のようにはなりませんでした。

とにかく。
あなたによると-単純化された-サービスとタスクの違いは寿命です。 理にかなっています。あなたはそれらを2つの異なる概念と見なしており、ワームの潜在的な可能性があると感じていると思います。 しかし、この区別は、ドキュメントではどこにも明確化または説明されていません。 また、dockerが一時的なプロセスをスピンアップするために使用されることを意図していないことも指摘されていません。
私が言いたいのは、Dockerチームがこれについて強いスタンスを持っている場合、それは最初から明確にされるべきであるということです。
また。 タスクまたはサービス、明らかに重複があります。 また、サービスをオプションとしてマークすることは、タスク側に固有のものではありません。
実用的な観点から、私は@acranに間違いなく同意しdocker -composeファイルを持つことはDXがはるかに優れており、多くを単純化し、複数のdocker-composeファイルを持つよりもエラーが発生しにくいです。

ふふ、「ブラウザ」に画像を表示させるよう働きかけたときの激しい議論を覚えています。反対派の主な議論は、ハイパーテキスト転送プロトコルと呼ばれているということです。
古いオナラを彷彿とさせるOTをごめんなさい。

@ shin- docker-composeをmakefileとして使用しない場合は、makefile機能を提供しないでください。 それが私のプロジェクトを構築することを可能にするなら（ブラボー！）それがメイクファイルではないという立場を取ることはばかげています

@ shin-見て、あなたたちは、あなたの理由がどれほど不合理であろうと、あるいはその機能がどれほど有用であろうと、あなたが望まない機能を実装する必要はありません。 それは、それを使用する私たちにとってツールの有用性を低下させるだけです。 私たちはユーザーであり、ユースケースを知っています-そしてツールはユースケースに対応するのと同じくらい有用で価値があります

これは私にとっては小さな苛立ちに過ぎません。理由もなくスポーンされたものを手動で殺さなければなりません。_サービスをアップするたびに_。 他の人にとってはそれが障害になるかもしれません、刺激は重症度が異なります

たとえそれが私たちが必要とするものに対してやり過ぎであっても、私たちはドビを使うべきであるという公式の立場を理解しています。 しかし、その公式の立場は、あなたが有用なPRを受け入れることを躊躇する根拠を説明していません。 docker-composeの需要が大きすぎる場合、または重なりが移行するのに十分な場合でも、dobiを使用できますが、これは非常に小さな変更であり、すべての生活がはるかに良くなります。

ちなみに、私は「好奇心旺盛」ではありませんが、それ以上の議論を防ぐためにスレッドをロックすることは、単に非民主的で権威主義的です。 オープンソースはオープン性の原則に基づいて構築されており、このプロジェクトが検閲と独裁的な戦術を使用して管理されているのを見るのは悲しいことです

@rysiekplこれは、別の方法で解決しようとしている問題です。https：//github.com/docker/cli/pull/452を参照して

@creyndersこれは少し<img>タグを明示的に閉じることが有効かどうか、および特定のブラウザがそれをサポートする必要があるかどうかを議論することに似ています。

また、あなたのポイントに：

しかし、この区別は、ドキュメントではどこにも明確化または説明されていません。 また、dockerが一時的なプロセスをスピンアップするために使用されることを意図していないことも指摘されていません。

これは実際にはhttps://docs.docker.com/compose/overview/ページの最初の段落です（私の強調）：

Composeは、マルチコンテナのDockerアプリケーションを定義して実行するためのツールです。 Composeでは、Composeファイルを使用してアプリケーションのサービスを構成します。 次に、1つのコマンドを使用して、構成からすべてのサービスを作成して開始します。

@ekkis Composeが実際にあなたのプロジェクトに役立つことを本当にうれしく思います！ 私はこれらすべてにおいて不誠実であるとは思わないことを望みます、それがあなたがソフトウェアを使いたい方法であるならばそれは絶対に大丈夫です。 しかし、私が言っているのは、それをその方向にさらに進めると、おそらく長期的には悪化するだろうということです。 あまりにも多くのことを行おうとするアプリケーションがどうなるかは誰もが知っています（Emacsがそれをやってのけたと思いますが：stuck_out_tongue :)

私は「権威主義者」ではなかったと思いますが、自分を正しく表現していなかったのかもしれません。 私の意図は、人々が彼らの相互作用において市民的で前向きであり続けることを奨励することでした。 スレッドはまだロック解除されており、人々が卑劣または失礼であることを控えている限り、スレッドは継続します。

構成からすべてのサービスを作成して開始します。

そして、私たちの主張は、「作成および/または開始」を読むべきだったと思いますが、言語に公平であるためには、ORが暗黙的に含まれているため、ORを示す必要はありません。 言い換えれば、サービスの作成と開始の両方が可能であることは事実ですが、両方を実行する必要があるという意味はありません。

あまりにも多くのことを行おうとするアプリケーションがどうなるかは誰もが知っています

はい、ドメインの境界を管理していることを感謝します

私は「権威主義者」ではなかったと思います

私はオープンソース運動が大好きです。 意見の相違はありますが、まだ一緒にいます。 ビットコインコミュニティ内の戦争はひどいものでした、そして私はまだそれから動揺していると思います、それで礼儀の側にとどまってくれてありがとう

別れの考えとして、 https：//github.com/docker/compose/issues/4650を再確認して

複数のファイルを定義するというアイデアが本当に好きです。 ただし、元のファイルを含めて複数の-fを持つすべてのファイルを含めることは、完全にやり過ぎのようです。

実際にはもっと実用的な方法があります（以下のPSを参照）：実行したくないすべてのサービスをdocker-compose.override.ymlます。 また、通常の起動にはdocker compose -f docker-compose.yml upを使用します（これは1回限りのコマンドであることに注意してください）。 連続するすべての呼び出しで、オーバーライドが発生します。

全体として、これはすべて非常に直感的ではなく、少し満足のいくものではありません。 追加：

• サービスを無効にするオプションは、特により複雑なオーバーライドの場合に意味があります

• -fオプションは最小限ですが、あまり直感的ではありません。オーバーライドを追加するだけの別の-F <name>オプションは、非常に歓迎されます（つまり、docker-compose）。.yml。 別の方法は、すべての.ymlファイルが供給されるディレクトリとして：シンボリックリンクとともに、これは/etc/apache/sites.available -> /etc/apache/sites.enabledと同様に強力です。

一方、誰でもシェルに単純なラッパースクリプト（関数）を提供して、この動作をエミュレートできます...

PS：私のユースケースは、デバッガーをサービスとして定義することです。 明らかに、このサービスは常に必要なわけではありませんが、正しく機能するにはリンクが必要です（セキュリティ上の理由からも）。

オプション2が優れているもう1つのユースケース：

同じプロジェクトに取り組んでいる人々のチームがあるとしましょう。 AWSマネージドサービスにアクセスできるものもありますが、対応するリソースをローカルコンテナとして実行する必要があるものもあります。 そのため、ワークフローに応じて、コンポジションコンステレーションにRedisコンテナとMySQLコンテナが_常に_または_決して_必要ありません。

このユースケースでは、複数の作成ファイルを管理するのはばかげていると言っておきます。 オーバーラップの量はコミカルです。 複数のファイルを維持することは足がかりです-それらは同期から外れ、混乱を引き起こします。 率直に言って、誰もがそのオプションを_any_ユースケースで真剣に受け止めたことに少しショックを受けました。

構成の大きなブロックをコメントアウトせずに（YAMLでは扱いにくく、誤ってコミットすると非常に面倒になります）、サービスをすばやく有効または無効にできることは、それ自体が素晴らしいことです。 しかし、composeがいつか変数を構成に補間する機能を取得した場合、この機能は自動的に指数関数的に強力になります。 それまでは、それは_単に_非常に便利です。

@campadrenalinに完全に同意します。

私が理解しているように、この議論全体は基本的に多数の人々がオプション2を実装するための非常に多くの非常に良い理由を提供し、誰かがこの機能の存在を誤解して他の無関係な機能を要求する可能性があるため、開発者は拒否します。

OT：

しかし、composeがいつか変数を構成に補間する機能を取得した場合、この機能は自動的に指数関数的に強力になります。

この機能は長い間利用できませんでしたか？ https://docs.docker.com/compose/compose-file/#variable-substitutionを参照して.envファイルを使用してCompose開発環境をカスタマイズできるようにするために使用しています。たとえば、ソースコードの場所、ポートマッピングなどです。composeファイルバージョン2.1以降、シェルスタイルの変数のデフォルト（ ${VARIABLE:-default} / ${VARIABLE-default ）がサポートされています。

私が理解しているように、この議論全体は基本的に多数の人々がオプション2を実装するための非常に多くの非常に良い理由を提供し、誰かがこの機能の存在を誤解して他の無関係な機能を要求する可能性があるため、開発者は拒否します。

これは、トーンが少し厳しいかもしれませんが、本質的には有効であることがわかりました。@ rysiekplによる非常に優れた要約です。
それで、@ shin-、私たちはこの問題に関する決定に近づきましたか？ それを閉じるだけなのか、それともオプション2のPRを実装/受け入れるのか。

私はあなたの懸念を完全に理解していますが、これはかなり小さな変更ですが、多くの人々にはるかに多くの_便利な_ワークフローの可能性を提供するため、誰かがこれを悪用する可能性のあるリスクを上回る利点もあります。

とにかくdocker-composeは長期的にはdockerstackを優先して削除されるようですので、できるだけ早く新しいv3形式とdocker stackツールに移行することをお勧めします。

群れのスタックを使用して（1ノードでも）、これを指定できます。

        deploy:
            mode: replicated
            replicas: 0

レプリカがゼロの場合、基本的にサービスの実行が無効になります。

envsubstなどの環境変数置換を適用する場合は、そのymlを生成するための他のツールが必要です。

次に、ymlでプレースホルダーを使用できます。

        deploy:
            mode: replicated
            replicas: ${R}

そしてそれをこのように処理します：

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

したがって、 docker-composeが長期的に非推奨になる場合、すでに存在するdocker-composeがドードーの道を進んでいる場合、「誰かが奇妙な機能を要求する」というのはどうして本当の問題なのでしょうか。

docker-composeは長期的に削除され、dockerstackが優先されるようです。

したがって、docker-composeが長期的に非推奨になる場合

待って、ワット？ docker-composeは、群れのマネージャーをほとんど必要としない開発ワークフローの多くの人々の中心です。 この点に関するDockerの公式声明を教えていただけますか？

私はこれを間違って読んでいるかもしれませんが、dockerswarmとdockerstackはdockerクラウドサービスと緊密に結合されているようです。 これらはスタンドアロンのオフラインシステムで構成できますか？

これらはスタンドアロンのオフラインシステムで構成できますか

はい、オフラインで使用できます。

私には、docker-swarmのスタックが最終的にdocker-composeの機能のスーパーセットになるように見えます。 記述子ファイルはすでに非常に似ていると思います。 うまくいけば、この移行はそれほど難しくはありません。 私が見ることができる最大の煩わしさは、スタックとは別に群れを管理することです。 構成されたアプリケーションを複数のノードで実行することに興味がないため、オーバーヘッドが増えます。

または多分私はすべてを誤解しています...？

オプション2で+1！
そして、スウォームスタックを支持するDocker構成のドロップは、コミュニティにとって大きな欠点になると思います。 Dockercomposeはとてもシンプルで使いやすいです!!

@tberne私はそれに同意します。 docker-composeはシンプルで、シンプルは良いことです。 私たちはそれを維持するために投票する必要があります

ええ、なんて大規模な議論でしょう！ このコメントにはあまり注意を払わないでください。私の2セントだけです。

最初は、ある種のenabledフラグを追加するだけで大​​多数に同意しました。
それから私はグループによるブランチ定義への提案を見て、それを良い考えだと考えました。
それから私はDobiについて読み、それを試し、それが今私のプロジェクトで使用できないことを確認し、読み続けました。
それから私は@ shin-の議論を読み、いくつかの反論にも同意したにもかかわらず、それらは十分に良いと考えました。

私の現在の解決策は、いくつかのdocker-compose yamlを作成し、docker-composeを手動で実行しないようにいくつかのbashラッピングスクリプトを作成することです。

たとえば、これはWebサイトを実行するコンテナを実行する方法です（ ./docker/scripts/upスクリプト）：

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

オプション2または3のいずれかに大きな+1。

オプション2または3の場合は+1。

また、提案された「グループ」の概念は面白そうです！

オプション2の場合は+1

_ +1 on option xが多すぎるため、元のステートメントすら見つかりません。 代わりに、投稿の下にあるリアクションボタンを使用してください。_

新しいアイデアを追加するには：

デフォルトのスケールを0設定することはできませんか？

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

人々は何年も待っていたので、オプション2（ただし、代わりにnostartなど）を実行する必要があります。ツールが制限されすぎているため、独自の構成マネージャーでdocker-composeをラップします。これは、dockercomposeが行うべきことを実行しているためポイントを打ち負かします。やっている。 2年以内に、誰かが独自のより強力なdocker-composeを作成できるようになりました。 それはこの問題が開かれている多くの時間です。

長期的には、真のオプションのグループ化を検討する必要があります。 ビルドにのみ関連するもの、実行にのみ関連するもの、相互に関連するものがあります（少なくとも実行のためにネストのレイヤーが必要な場合、または単に分離してビルドセクションを作成し、問題を解決する必要があります）。 現在、構成には多くの問題がありますが、バージョン5ですべてを作り直すだけですが、その時点で正しくする必要があります（主に、使用法をマップするのではなく、技術レベルのドメインで実際を表すことによって）ベースのドメインまたは過度に単純な場合は、代わりに、適切なものの上にそれらの目標の構成レイヤーを作成します。逆に行うことはできません）。 そのような状況のために、迅速な修正は正当化されると思います。

オプション2または4の場合は+1

現在この機能を追加する予定がない場合は、コンポジションでそのようなサービス（またはタスク）を実行する方法をdocker-composeのドキュメントに記述してください。

これは古いスレッドであり、 docker-composeが_startから実行されないサービス_を気にし

しかし、私は通常testサービスも追加するので、これが私がしたことです：

1. サービスのentrypointを上書きします。

2. 新しいentrypoint 、利用可能なttyがあるかどうかを確認します（ docker-compose runはデフォルトで--ttyを使用しますが、 upは使用しません）。

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   これにより、 tty （たとえば、 docker-compose upを使用して）実行すると、 docker-compose run期待どおりに実行されている間、常にサービスが終了します。

@paulodiovaniそれは解決策というよりはハックのように見えます。

機能リクエストの場合は+1。
何もしないコマンドを持つようなハックは、コンテナが実行されなくても、ビルド、初期化などを行う必要があることを意味します。

提供された引数に基づいて適切なdocker-composeコマンドを呼び出す単純なbashスクリプトを提供することにより、プロジェクトでこれを解決しました。

./docker-compose.sh -e testing upと、結果はdocker-compose -f docker-compose.yml -f docker-compose.testing.yml upを実行した場合と同じになります。
./docker-compose.sh upを実行すると、ご想像のとおり、通常のdocker-compose upます。

したがって、私の-e ${environment}オプション（ --env略）は基本的に-f docker-compose.yml -f docker.compose.${environment}.ymlエイリアスです。 これにより、 docker-compose.ymlがベース/デフォルトの作成ファイルになり、 docker-compose.testing.ymlようなファイルがその拡張子になります。

これにより、ユーザーがdocker-composeコマンドに含めるファイル（およびその順序）がわからないという@acranの問題が、適用することである程度解決されます。 より複雑な作成ファイルの組み合わせを使用するものもあるため、これはあまり堅牢なソリューションではありませんが、 docker-composeでも同様のことができるはずです。 ほとんどのdocker-composeファイルはdocker-compose.始まり、とにかく.yml終わる可能性が高いので、なぜこのような長いコマンド（ docker-compose -f docker-compose.yml -f docker-compose.testing.yml upを常に入力する必要があるのですか？ ）テスト環境に1つの追加サービスが必要な場合はどうなりますか？

envsubstは必要ありません。docker-composeconfigが環境変数を実行し、dockerstackがstdinから取得します。

docker-compose config | docker stack deploy --prune --compose-file -

docker-compose.env置換も使用してみましょう。

@kogliここでの問題は、オプションを選択することだと思います。 すべてに長所と短所があります。 以前お話ししたように：

すべてのソリューションは、一部のユースケースではより良く、他のユースケースではより悪く（または役に立たない）なります。 何かが実装されれば、それは永遠に維持されるので、彼らはそれを使って時間を割くのが賢明だと思います。

@ shin-あなたが質問する人だと思います：これを検討することは意味がありますか？ チームの現在の位置、それを設計するのがどれほど難しいか、そしてそこにある多くのツールを考えると、これが起こらないことを人々に単に伝えるのは簡単ではないでしょうか？ ここでコメントしたすべての人ではないにしても、ほとんどの人がそれに対処する方法を見つけました。

これを閉じるのはかなり良いようです。さらに、重要なことに集中できます。プルリクエストを行う必要があるかどうか、およびそれらすべてのニーズを同時に満たす方法については誰も疑問に思いません。 彼らはただ何か他のものを作りに行くことができ、そして多分他の人を助けるためにそれを公開することさえできます。

念のために言っておきますが、私のソリューションは完璧ではありませんでしたが、依存関係をインストールして大量の問題を修正し、プロジェクトを実行するのに2日かかったよりもはるかに優れていました（そしてすでにDockerを使用していました）。 DockerとDockerComposeを唯一の依存関係として使用する3つのコマンド。 はい、思った以上のコードがありました。 はい、コマンドを実行するためのくだらない順序があります。 そして、はい、覚えておくべきことがもう少しあります。 Wikiページがそれらをカバーしました。 自分でそう言うと、 Docker Composeがその仕事をしたということですが、他にも何かが必要でした。

重要なのは、それが範囲外である場合、それについて議論し続けるのは時間の無駄です。 多くの人は、何をすべきかを決める前に、ここに立ち寄ってこれについて質問し、意見を述べます。 これが閉じられた場合でも、彼らは他の何かを見つけたり構築したりします。 そして、ベビーシッターのスレッドが1つ少なくなります。

編集：それを置くための良い方法を考えただけです： PRを受け入れる明確な基準がなく、それに関与しているか、近い将来にそれを検討することを計画しているコアチームに誰もいない場合、それは「問題」、ただのアイデア。

問題リストを乱雑にする理由はわかりません。ここにある多くのアイデアは良いと思いますが、良いか悪いかにかかわらず、どこかに属していると思います。 ほぼ3年になりますが、いつか状況が変わる可能性がない場合は、いつでもこれを再開するか、新しい問題を開くことができます。

この機能は非常にシンプルなため、実装に1日ほどかかります。 しかし、2年間の議論の後、まだ何もありません。 悲しい。

@rubycutええ、それはいわゆる「より高い原則」が使いやすさと使いやすさから引き継いだときに起こることです。 私は、開発者が非論理的な機能で製品を詰まらせたくないことを完全に理解しています。 ただし、この特定の非常に要求された機能は実際には理にかなっているようです。 開発者がユーザーよりもよく知っていると思うのは悲しいことです。 （繰り返しますが、彼らは通常そうします。しかし常にではありません。今回はそうではありません。）

@rubycut Talkは安いので、コードを見せてください。 可能であればPRを送信し、できない場合は報告して待ってください。

@wangwenpei冗談ですか？ まず第一に、あなたはこのプロジェクトのメンテナではありません。 メンテナがこのアイデアを受け入れ、「help want」タグを付けると、誰かがプルリクエストを提供できると確信しています。 しかし、彼らは興味がないと言った。 それで、それが受け入れられないのに、なぜわざわざリクエストをプルするのか。

参考までに、「コード」はすでに存在します：＃3047

@wangwenpeiええと、＃3047、プルリクエストがあります...
2年以上の間、少なくともいくつかのフィードバックを得るのを待っています。 最近閉店しました

https://github.com/docker/compose/issues/1896#issuecomment-322285976で強調表示されている理由により

https://github.com/docker/compose/issues/1896#issuecomment -322285976で指定された引数は、プルリクエストとはまったく関係がないため、正直に言うと非常に怒ります。

1. サービスとは何ですか？ 設計上、サービスは明確に定義された長期実行プロセスであり、他のサービスと相互作用してアプリケーションを形成します。 これは、Composeが動作する基本的な前提であり、実装するすべての機能ではないにしても、ほとんどの設計をガイドします。
2. その定義によれば、「デフォルトで開始されないサービス」は実際にはサービスではありません[1]。これは、コンテナーの一部ではなく、コンテナーで実行され、アプリケーションで動作する、事前定義されたタスクです。

アサーションBy that definition, a "service that is not started by default" is not really a serviceが真であるとは思わない。 デフォルトで開始されないサービスは、デフォルトで開始されないサービスであり、現時点ではそれ以上でもそれ以下でもありません。 デフォルトで開始されるかどうかは、サービスが長時間実行されているかどうか、アプリケーションの一部であるかどうかについては何も言いません。デフォルトで開始されないことだけを示します。

そして、それはプルリクエストの変更が行うことでもあります。サービスをデフォルトで開始するかどうかをマークする機能を追加します。
これを行うために、タスクなどの新しい概念を導入する必要はありません。 実際、 https： //github.com/docker/compose/issues/1896#issuecomment -322285976の他のすべての引数は、2の誤った前提に基づいているため、何も実行しようとしないプルリクエストには適用されません。そうしないと。

完全を期すために：

[1]「オプションのサービス」が必要だと言う人もいますが、それはこのスレッドで言及されている最も一般的なユースケースではありません。 私の知る限り、ほとんどの人は「タスク」機能を望んでいます。

はい、1回限りのタスクの例がありましたが、定義に応じた_real_サービスの
これを使用して1回限りのタスクを実行できるので、これに対する有効な引数として実際に受け入れることはできません。 完全に有効なdocker-compose.yml 、長時間実行されず、ポートを公開せず、アプリケーションの重要な部分ではない_service_を定義することはすでに可能です。

実際、これは推奨される回避策の1つでもあります。 _tasks_を個別のdocker-compose.yml分割するだけです。
言及されている他の回避策は、独自の自家製（プラットフォーム依存）スクリプトを使用することです。これは、docker-composeの自己記述の目的と完全に矛盾します。上記の私のコメントを参照するか、単に別のツールに切り替える、つまり完全に破棄します。現在のツールチェーン（docker-compose）に簡単に実装できる便利なこの1つの小さな機能を取得するためだけに、うまく機能するツールチェーン。

オプション2の最も基本的な実装に対して提起された唯一の本当の議論-つまり、デフォルトで特定のサービスを開始しないようにdocker-composeに指示する_何らかの方法_を持ち、それ以上、新しい概念などはありません-これは可能性があるということですbe_somehow_は_some_ユーザーによって誤用されます。
しかし、この議論は、それに対する需要とここで提起された正当なユースケースと比較して非常に弱いです...

@ shin-

しかし、私たち[3]には、この機能が人々にとって本当に役立つものになるために必要なものを実装または維持するための時間やリソースがないためです。
[3]そして、現時点でdocker-composeに積極的に取り組んでいるのは私だけなので、この時点で私は「私」を意味します。

アクティブなメンテナは1人しかいないことを強調する一方で、プルリクエストを無視するだけなので、他の開発者をプロジェクトに参加させる機会を無駄にすることは、私には理解できません。
＃3047で提供されたコード変更は、すでに[多くの]人々に_本当に役立つ機能を_do_実装しています_-おそらく、_すべて_のユースケースを持つ人々ではなく、ここにいるほとんどの人々です。

完全に新しい概念、新しい依存関係管理、最大cmakeような複雑さを導入する必要があるすべての追加要件は、単に誤った前提に従うだけです！

このような機能を探していたので、ほんの数日前にこの問題に遭遇しました。

残念ながら実装されていないため、そして私が収集できたものから、公式にサポートされている代替手段は、複数のyamlファイルを使用することです。

デフォルトで実行されないサービスに複数のyamlファイルを使用するという考えは、デフォルトで実行されないサービスごとに1つの追加設定を含むすべてのサービスに1つのyamlファイルを使用するのと比較して不十分な代替手段だと思います。

だから、これが私の+1です。