@jmmills 「

@aanmはい。ただし、機能はサービス定義のデフォルトとしてミラーリングする必要があると思います。 たぶん、常に実行する必要のある最小限のワーカーセットがあり、それをデフォルトとして明確に宣言したいと思います。

@ @aanm docker-compose upがscaleパラメータを考慮に入れるべきだと思いますか？ 私が見ているこれに関する唯一の問題は、基礎となるDocker / Docker APIの概念とは互換性がないが、DockerComposeに非常に固有のパラメーターを宣言型構成に導入していることです。

これを今後行うとしたら、 私は次のようなものを提案します：

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

ここで、 $<parameter>は、DockerCompose固有のものを示します。

scaleがYAMLに属しているかどうかを行ったり来たりしました。 以前に追加するPRがありました（＃630）。 移植性が低下するため、ほとんどの人は構成にスケール番号を入れるべきではないと私はまだ考えていますが、そうするためのユースケースは理解しています。

Composeファイルをextends拡張する基本的な方法ができたので（そしてうまくいけばすぐにもっと良いもの-＃1380、＃758）、 https：//github.com/docker/composeで私が提起した懸念

通常は開始したくないテスト関連サービスのymlにscale=0を設定したいと思います。 これらのサービスをdocker-compose runまたは明示的なscale明示的に作成したいだけです。

@jamshid私はよくそれを望んでいました。これは、環境をセットアップするが、デフォルトでは実行されない定義です。 私は（ docker runを介して）ユニットテストを実行するベースイメージ（ゼロ/ノーオペレーションスケールも役立ちます）の作成に追いやられており、コンテナ構成はベース画像。

このようなものは、開発構成に非常に役立つようです

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmillsサービスごとのYAMLファイルのenabledパラメーター/キーはどうですか？ サービスを無効/有効にできるように？

@prologic 「スケール」パラメータが両方のニーズを解決する
実行中のプロセス/コンテナをクラスのインスタンスとして想像したい場合は、 instancesという名前を付けることもできます。

@jmmills現在のdocker-composeを壊すことを伴わない、ユースケースの_解決策_を見つけようとしています。 私はscale=0が適切ではないと思う傾向があり、 scale=XをCompose自体の一部にする必要があるかどうかについて2つの考えがあります。

私の意見では、スケール（またはコピー数）はサービスの構成の一部であるため、構成に含める必要があります。

scale=0またはdisabledキーがあると思います。

：+1：インスタンスのデフォルトのscaleサイズを設定する機能がある場合。 そして、私は同意します。スケールが入ると、スケールを0に設定するだけなので、 disabledキーは必要ありません。

+1

また、別のユースケース：コンテナの数をスケーリングしたいが、すべてのサービスをバックグラウンドにしたくない場合、または別のターミナル（またはプロセス）にジャンプしてスケール番号を設定する必要がある場合はどうなりますか...
例えば：

$ docker-compose up && docker scale thing=4

upが終了しないため、機能しません。
しかし、私の構成ファイルが私のコンテナのスケールを設定する場合...

$ docker-compose up

DWIMになります。

私が本当にこれが好きかどうかはわかりません。 突然のupはすべて、次の2つの機能を利用します。

• scaleパラメータを持たないコンテナを起動します。
• scale=0コンテナをすべて起動します。

現在、「up」コマンドを実際に悪用しています。 「スケール」はまた、2つのことを行うという点で新しい意味を持ちます。

• コンテナを拡大/縮小する
• ` scale=0コンテナ/サービスを無効にします

なぜscale=0コンテナを立ち上げるのでしょうか？
Buildは、 scale=0を使用してイメージをビルドするため、ベースイメージの必要性が高まります。

私は_間違っている可能性があります_が、あなたの最後のコメントを読むと、それは一種のことを暗示しています:)

詳しく説明させてください。

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

さて、期待される動作： docker-compose buildは「ビルド」でコンテナをビルドします（ビルド時に外部イメージをプルインしますか？覚えていません）、 docker-compose upは正のスケールで何でも実行します（デフォルトは1）、 docker-compose run test_harnessは、必要に応じて「base_thing」をビルドし、1つのコマンドを実行します。 精通していますか？ :)

編集： docker-compose upは1 "thing"と4 "workers_for_thing"を実行します

わかりました:)ありがとう; あなたの例は、 scale=0意図に関して、biをより意味があり、少し明確にします。

docker-composeはup / run画像を「引っ張る」と思います。

テスト、生産、品質保証などのために、ディスタンスの数（スケール）を示すレシピを作成する必要があります。

scale=X場合
また、 @ jmmillsコメントの+1には、構成の説明と期待される結果が含まれています。

わーい！ scale=x 。 コンテナーのセットを初期化すると、クラスター構成をセットアップするときに潜在的な競合状態を特定するのに間違いなく役立ちます。

+1のためのscale=x （を含むscale=0初期のための無効化サービスにdocker-compose up ）

scale=x場合

xはNaN -1を提案します。

scale = xの場合は+1。

+1

+1

+1で止めてみませんか？

+ 1'ingは、機能の関心のレベルを確認するのに役立ちます。

@shofetim私はそれを行うためのより良い方法を知っています：問題の機能を実装し、プルリクエストを送信します...

+1することは、提案された解決策に人々が同意することを確認するための良い方法でもあります。 github全体でかなり一般的な動作です。 それが問題である場合、通知から購読解除ボタンをクリックすると、これらがオフになります。

さて、こんな人のようですね。 作曲バックログ（図の残り）にも同様の項目がありますが、いつかコメントしたと思います。 今夜遅くにフォローアップしようと思います。
私は今週のほとんどがPuppetConにいるので、ハックの時間があればいいのですが。これを書けるかどうかを確認します。

「scale = 0」ユースケースの回避策は次のとおりです。

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkelええ、私は過去に同様のことをしました。

私は現在、composeコードベースに慣れるために取り組んでいます。composeのすべてがどこにあるかがわかったら、スケール構成パラメーターのPRをハックします。
それほど難しくはないようです。CLIインターフェイスのバックエンドであるプロジェクトにはscaleメソッドがあるので、実際に行う必要があるのは、に「スケール」を追加することだけです。フィールドスキーマ、コンテナの作成後に呼び出すために存在する場合は確認してください...次に、ゼロに設定されている場合はコンテナが実行されないことを確認してください。

実際、これには本当に古いPRが開かれています：＃630。

問題は、スケールが運用上の問題であり、アプリケーション定義の一部ではないため、作成ファイルに実際には適合しないことです。

デフォルトのスケールレベルの構成をサポートするのは良いことですが、作成ファイルが適切な場所ではないと思います。

scale: 0の場合は、＃1754ですでに対処されているはずです。 「no-op」コンテナには、すぐに終了するコマンド（echo、trueなど）を含めることができます。 scale: 0が必要な場合は、通常、データボリュームコンテナまたは「アドホック/管理タスク」の2つのうちの1つです。

ボリュームは新しいAPIエンドポイントを取得しているため、すぐにデータボリュームコンテナは必要なくなり、コンテナを必要とせずにボリュームを定義できるようになります。

管理タスクは＃2051でより適切に処理されます。 admin.ymlを定義できます。これにより、コアdocker-compose.ymlが拡張され、それぞれの定義を混乱させることなく、管理タスクを「コア構成」にリンクできます。

これらの変更は両方とも現在マスターにあり、1.5.0リリース（すぐ近くにあります）で利用できるようになります。

そのため、デフォルトでサービスを1より大きいサイズにスケーリングしたい場合のみが残ります。 このようなスクリプトを作成するのはすでにかなり簡単ですが、それを構成ファイルに入れることができればそれでもいいでしょう。 ＃745で別の構成のアイデアを探求するつもりだと思います。 この新しい構成は、アプリケーション定義の一部ではないもの（プロジェクト名、デフォルトのネットワーク名、デフォルトのスケールなど）に適した場所になると思います。

敬意を表して、私は規模が運用上の懸念にすぎないことに同意しません。 アプリケーションは、実行中のサービスの最小数を気にすることができます。
ノーオペレーションコンテナに関しては、そのコンテナの目的が、他のコンテナがimageフィールドに使用するベースイメージの構築をトリガーすることである場合、実際にコンテナを実行するのは厄介だと感じます。

アプリケーションは、実行中のサービスの最小数を気にすることができます。

このケースの例を挙げていただけますか？

ノーオペレーションコンテナに関しては、そのコンテナの目的が、他のコンテナがイメージフィールドに使用するベースイメージの構築をトリガーすることである場合、実際にコンテナを実行するのは厄介です。

ベースイメージを同じビルドの一部にする必要がある理由はありますか？ ＃1455で述べたように、composeは主に「dockerbuild」ツールではありません。 実行時にコンテナーの構成を提供することが目標です。 考えられるすべてのビルドシナリオをサポートしようとすると、作成の範囲が大幅に広がり、コンテナの作成から焦点が外れます。 イメージの構築を中心に設計されたツールでさえ、これらの要求のすべてをサポートすることは困難です。 より良い方向は、ビルドの複雑さをできるだけ多く構成しないようにし、ユーザーがdocker-compose build代わりに適切なビルドツールにスワップできるようにすることだと思います。

私が気にかけているユースケースはscale = 0です（おそらくabstract = trueの方が適切な記述子です）。 異なるコマンド間で画像と環境変数を共有したいと思います。 具体的には、1つのWebサーバーと1つのバックグラウンドジョブサーバーを、両方とも同じコードで、両方とも同じ環境変数で実行する必要があります。

@wkonkelはあなたの例を使用していますが、これも機能すると思いますか？

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

ports no-opオーバーライドを使用する抽象サービスをcommandと交換します。 それは正しいですか？

1988年は抽象的なサービスに関連しています。

@dnephinはい、私の場合は機能します。

実際、私はそれを取り戻します... docker-compose-1.4.2で試してみましたが、「ports：[]」は親をオーバーライドしていないようです。そのため、app_workerは「portisalreadyassigned」で開始できません。 "。

@dnephinスレッドにはもっと良い説明があるかもしれませんが、ここで明確に説明しようと思います。

最初に頭に浮かぶのは、同じコードを実行する個別のコンテナーを、親-> fork（）->子プールタイプのサービスのようにモデル化できるジョブシステムです。デフォルトのアプリケーション構成では、同時実行のために最小数のワーカーが必要です。

これに対する私のインスピレーションは、Pythonパッケージ（ワーカーコード）を含むベースイメージを共有しているが、キューごとに複数のインスタンスが実行されている、異なるキューに接続されたRQワーカーを使用するアプリから来ました。 実行時間の長いジョブのため、同時実行性の最小可用性はアプリケーションの要件でした。

no-opコマンドを使用すると、他のアプリケーションスタックと同じ方法で共有ベースイメージを構築するためだけにリソースを浪費するように思えます。 ベースイメージのためだけにwhile / sleepループが発生します。これはクールな回避策ですが、これを実現するための直感的な方法とは思えません。 言うまでもなく、ランタイム関数のないアイテムをプロセスツリーに残します。

docker-composeがイメージのビルド関係を体系化するドメインに本当にクロスオーバーしない場合は、ビルドオプションを削除し、ベースイメージをビルドするためのビルドターゲットを定義できるように、他のビルド定義システムを作成する必要があります。 、そしていくつかの変更されたアーティファクト/構成でそのベースを消費する他の画像を正しい順序で？

あるいは、私はあまりにも意見が分かれているので、Dockerの作成コマンドをシェルスクリプトでラップして、サービスをスケールで起動し、すべてのイメージビルドを依存関係のあるmakeターゲットとして定義する必要があります。

no-opコマンドを使用すると、他のアプリケーションスタックと同じ方法で共有ベースイメージを構築するためだけにリソースを浪費するように思えます。

＃1754（次のリリース）では、これはもう必要ありません。 サービスは終了でき、残りのサービスを停止することはありません。 したがって、ベースを終了するだけで、心配する必要はありません。

@dnephin Coolでは、最初にビルドされることを確認するために、そのベース/中間コンテナーにlinkを提供しますか？

@dnephin ： docker compose upと同等のCIランナーがあります。 テスト環境を複数のバージョンのサービス（つまり、スケール）で実行したい。 構成ブロック全体をコピーすることもできますが、これには自分自身を繰り返す必要があります。 この場合、これは「単なる運用上の懸念」ではなく、クラスター化されたアプリケーションを開発するときに開発環境で必要なものです。クラスター化されたアプリケーションは、現在、作成ファイルについて完全に説明されています。 現時点では、帯域外のスケール構成が必要で、どういうわけかdocker-compose scale呼び出す必要があると思いますが、これは理想的ではないようで、失敗やレースの機会がさらに増えます。

本番環境の場合、最小限の規模でサービスにスターを付けることができます。 たとえば、あるクラスターから別のクラスターに移行し、例を簡単にするために、移行の難しい部分をコピーデータとして保持するとします。 そして、実際には最初からトラフィックの処理を開始する必要があるため、dockerを使用してデプロイする必要があります。たとえば、Webなどのサービスのインスタンスを少なくとも（n）個作成します。

構成ファイルのサービスの下にスケールがあると、実際にそれを処理できます。 これはユーザビリティのユースケースでもあります。ユースケースが実際に、開始点に1つだけでなく、少なくとも（n）個のサービスのインスタンスを実行するという要件を公開している場合です。

私の観点からすると、スケールは実際にはトポロジーと構成のパラメーターを定義するものです。

@dnephin

このケースの例を挙げていただけますか？

Consul、MariaDB Master-Master、またはSwarm上のその他の分散アプリは、信頼性を確保するために、クラスター内に少なくとも3つのノードが必要です。 設定ファイルで利用できるサービスの数には確かにユースケースがありますが、なぜそう反対しているのかわかりません。 ビッグ：+1：ここで私から。

スケールを設定する方法に反対しているわけではありません。作成ファイルとは独立して変化する状態であるため、作成ファイルに属しているとは思いません。

作成ファイルにスケール構成を追加することを前提としたこの例を見てください。

1. サービスの初期スケールを3に設定しました
2. docker-compose up -dを実行すると、サービスは3に拡張されます
3. docker-compose scale service=4を実行します
4. いくつか変更を加え、 docker-compose up -d再デプロイします..どうなりますか？ 再び3にダウンスケールしますか？ 今はスケールを完全に無視していますか？

これらのシナリオはどちらも適切でも適切でもありません。これは、インスタンスの障害を無視する簡単な例です（これによりさらに複雑になります）。

作成ファイルに追加する場合は、競合しないようにscaleコマンドを削除したいと思います。

あなたが与える例は、運用要件の例です。 アプリケーションを実行するために複数のマスターは必要ありません。サービスの信頼性（操作）のために必要です。 そして、あなたはまだscale db=xそれを達成することができます。

@dnephinによって上記の例を使用すると：

まず、scaleコマンドも単純なものだと思います。サービスをスケールアップするかスケールダウンするかがわからないため、2つのdiffコマンドを使用して、サービスの数を伝えるだけでスケールアップまたはスケールダウンの意図を説明できます。それぞれ作成または削除したい場合は、はるかに優れています。

@dnephinによって提起された質問に対する答えは、変更前と同じ数のサービス/コンテナーが実行されることを期待しているということです。

Composeはステートレスツールであり、Docker APIを使用して、問題があると思われる場所でOpsがオーケストレーションを行うのを支援します。composeは、完全なオーケストレーションサービスではなく、ヘルプツールとして設計されています。そして今、それが必要です。エンジンがうまく動作し、プロビジョニングするマシンがあり、それらすべてをクラスターに参加させるための群れがありますが、実際のオーケストレーションサービス/ツールをリークして構成の柔軟性を提供しますデプロイされたサービス/コンテナをk8sのように管理します。 今のところcomposeはそれによく似ていますが、このプロジェクトの将来がもっと大きなものに進化しない場合は、公式の開発者とメンテナからそれについて話して、別のことを理解できるようにするのが最善の考えです。それを行うことができるツール。

個人的には、composeは素晴らしいツールであり、私たち全員によく知られているので、composeを進化させる方が良いと思います。

私はこれを見てうれしいです： docker-compose > docker compose 。
残りのツールについてはよくわかりませんが、このためには、エンジンとステートフルに統合するのが本当にいいでしょう。 少し話題から外れたコメントでごめんなさい。

scaleコマンドを削除してscaleオプションに置き換えるという提案のために＃2496を作成しました（上記の投稿から）。 この提案に対するフィードバックは素晴らしいものです。

＃2496コンポーズの@dnephinは、簡単にスケールアップまたはスケールダウンする機能を失います。コンポーズファイルを再構成してから、1つのインスタンスをスケールダウンまたはスケールアップするだけで、コンポーズを再度実行する必要があります。これはかなり良いと思います。複雑。

繰り返しになりますが、このすべてのシナリオは、composeがステートレスツールであり、サービスの状態と、ある時点でのサービスの数を制御できないという点から来ているという点を失っています。

新しい提案で言及したシナリオは、状態が完全なサービス/ツールのnew-composeによって簡単に解決されます。

+1

+1

+1

@dnephin次の場合、動作は同じではありません。

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

構成が内部的にどのように拡張されるかについては、それほど問題ではありません。

それが、「アプリケーションの作成」はステートレスです。 唯一の状態は、1）作成ファイル、および2）エンジンによって管理されるDockerコンテナーラベルです。

作成ファイルは、作成ではなく、人間によってのみ編集されます。 同じコメント、順序、構造でyamlを書き出すのは面倒です。 pyyamlではサポートされておらず、とにかく本当にやりたいことではありません。

Dockerエンジンはスケールを認識しないため、その状態を保存できません。 はるかに大きなアーキテクチャの変更で可能ですが、それはこの問題の範囲外です。

今のところ、私たちのオプションは基本的にコマンドラインオプションとしてスケールを維持するか、それを作成ファイルに移動することですが、＃2496で説明しているように、両方があると混乱し、誤った動作につながると思います。

up && scale && up実際に今正しいことをしています。 upはすべてのコンテナーを再作成し、構成にスケール値がないため、目的のスケールがどうあるべきかについて混乱することはありません。 すでにscaleコマンドで設定されており、コンテナラベルで追跡されています。

@dnephin私はあなたが言っていることに同意すると思います、[この仮定では間違っているかもしれません]あなたが本当に質問しているのは、コンポーネントのインスタンスの数が実際にはサービスの構成（コンテナのグループ化）の問題であるということですさまざまなコンポーネントコンテナを実行しています）。 cliとcompositiondefinition（yaml）の間にパリティがないという警告だけで、現在その懸念に対処していると言えます。

スケールが構成の問題ではないと責任の範囲が決定された場合は、CLIオプションとしてスケールを削除する必要があります（おそらく多くのユーザーを怒らせます）、またはスケールがサービスの構成の問題であると判断された場合N + 1を必要とするクラスター化されたインスタンスを説明するために、最小インスタンスの追加サポートを使用して、cliとyamlの間に同等性がある必要があること。

@jmmillsに同意する特にデータコンテナのクラスタを実行する場合、可用性とレプリケーションがscaleがアプリケーションの一部になります。適切なスケールがないと、機能しない場合もあります。

+1

+1

+1

現在、私はそのようなことを宣言する必要があります：

セレン-クロム1：
..。
セレン-クロム2：
..。

それはいいだろう：
セレンクロム：
スケール：2

+1

@caioquirinoが言ったこととまったく同じです。 +1

docker-compose upは、他の作業を必要とせずに作業環境を立ち上げる必要があります。 複数のノードを必要とするサービスを起動する唯一の方法は、 @ caioquirinoが言及するパターンを使用することです。 ここでDRY違反を無視すると、どの「サービス」をスケーリングする必要があるかが明確でないため、scaleコマンドを使用して別のノードを追加しようとすると、パターンの臭いが悪くなります。

ymlファイルのスケールでこれが修正されます。

Big +1、これを使用して、最初にスケールが0に設定されているサービスを定義したいと思います。

の線に沿って...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

同じdocker-compose.ymlを使用して、開発環境から本番環境にシームレスに移行できるという考え方です。 consul_masterインスタンスは自動的にラフトに参加し、 docker-compose scale consul_master=3実行してクォーラムを確立します。 これはかなりクールでしょう。

@dnephinに返信するには...

作成ファイルにスケール構成を追加することを前提としたこの例を見てください。

1. サービスの初期スケールを3に設定しました
2. docker-compose up -dを実行すると、サービスが3にスケーリングされます
3. docker-compose scale service = 4を実行します
4. いくつかの変更を加え、docker-compose up -dで再デプロイします。どうなりますか？ 再び3にダウンスケールしますか？ 今はスケールを完全に無視していますか？
5. 大好きです
6. 大丈夫
7. 私はまだあなたと一緒です
8. 継続的な更新を受信して​​いる既存のデプロイメントのスケールの継続性を維持できるように、既存のデプロイメントと新しいデプロイメントをある程度区別する必要があると思います。 個々のデプロイには、DOCKER_HOST envなどが、各コンポーネントのスケール、イメージID、および再デプロイの履歴とともに含まれます。 これは、継続的デプロイやブルーグリーンデプロイメントなどのアップスタックメカニズムに接続するのに適した場所でしょうか？ もう少し本番環境に対応したワークフローを想像しているので、別のDOCKER_HOSTに接続してdocker-compose up -dを実行し、フックを提供して、アップスタックツールがCIや青/緑のロールアウトなどを管理できるようにします。 DOCKER_COMPOSE_ENV = {"testing" ||のようなものを追加するかもしれません 「プロダクション」|| "dev"}？

IMHOは、「ハードコードされた」 scale持っており、たとえば3と言うと、3つのコンテナーで開始する必要があります。

「scale」パラメーターと「scale」コマンドに関する多くの混乱は、YAMLパラメーターに「initial_scale」または「default_scale」という名前を付けることで軽減されると思います。 これは、何らかのオーバーライドがない場合に使用される値にすぎないことを明確に示しています。 また（少なくともIMHO）、この「initial_scale」パラメーターは、docker-composeがサービスを初めて起動するときにのみ参照され、docker-composeを実行しているときには参照されず、サービスの一部のインスタンスが既に実行されていることも合理的です。

「initial_scale」の場合は+1です。また、docker自体にはそのようなパラメーターがないため、このパラメーターは構成固有として明示的に記述されます。

興味深いことが起こります。ブログ投稿

+1

+1

何百万もの問題とリクエストのscale / initial_countなど..まだ計画されていません。

それ以外の点では優れたプロジェクトを見るのは悲しいことですが、人々は言い訳を見つけて、新しい重複した問題を作成し、問題を閉じて作業を「実行」するだけです。

+1

+1

+1

+1

停止してください！
+1を追加しないでください！
問題を購読するだけです！

+1（ @pierrre申し訳ありません）

+1その非常に重要（ @pierrre 、申し訳ありません）

同意しますが、あなたの「+1」に対して100000の通知を受け取りたくありません。

/ me forks dockerが作成し、コードベースの学習を開始します。

上記の多くの有効なポイントは、構成ファイルにdefault/inital scaleパラメーターがあるように見えます+ scale cliコマンドは両方に対処します。 初期スケールオプションをサポートするユースケースを追加するには、クォーラムがX個のノードで構成され、それ以外の場合は動作してはならない（たとえば、3つ以上）クラスター化されたサービスを検討します。 docker-composeのポイントは、そのようなシステムの完全に含まれた記述子を持つことです。

私のユースケースは次のとおりです。

重複を減らすために、いくつかの一般的な設定でサービスを拡張しました。 ただし、基本サービスは作成され（サービス名を明示的に指定せずに実行した場合）、手動でシャットダウンします。 基本サービスの初期スケールを0にしたいと思います。

私は一般的に同意します。 私の考えでは、この問題とリンクされた/関連する問題は、わずかに異なる問題に要約されます。 upとscale最終的には同じコマンドになりたいということです。

彼らは時々すでにです：

• docker-compose up service
• docker-compose scale service=1 。

また、 scaleがupが実行するすべてのCLIオプション（ --force-recreate ）を公開した場合、またはupがカウントについて知っていた場合、基本的には公開されます。

この問題が提案するように、「初期スケール」ディレクティブがdocker-compose.ymlに追加された場合、 upはカウントを学習する必要があります。 どの時点で、 upはカウント構文docker-compose up service=10 （yamlで定義されたスケールを上書きする可能性があります）をサポートするだけではいけませんか？

「初期スケール」と「スケール」には違いがあり、さまざまなコマンドのドメインである可能性があります。 ただし、 upはべき等であり、必ずしも状態を変更せずに繰り返し実行されるように設計されているため、この区別は厳密ではないと思います。 代わりに、 up scale完全に共食いすることを検討する必要があると思います。

@mattgiles同意します、それは私が＃2496で行っていたところです、しかし私はservice=countがup追加されることができるとは考えていませんup webは、Webサービスとその依存関係のみを起動することを意味するということです。 up web=3を実行しようとすると、同じことを意味し続ける必要があります。 つまり、すべてをupて、スケールカウントを一度にオーバーライドする方法はありませんが、おそらく問題ありません。

＃2496で提案を更新します

@dnephin最近の提案を見逃しました。 素晴らしい！

fwiw、 docker-compose up web=3が「web」サービス用の3つのコンテナーと、yamlで定義された比率（ scaleようなものごと）で依存関係を表示するのは完全に直感的だと思います

その後のup呼び出しは、現在のように、既存のコンテナーをそのままにしておくことができます。 現在のスケールがyamlで定義されているスケールよりも小さい場合にのみ、禁止されているスケールに一致するようにカウントが変更されます。 定義されたスケールは、1のスケールを意味し続けることはありません。

--force-recreateようなものも、yamlで定義されているよりも高い場合は、カウントをそのままにしておく必要がありますが、他の属性と一致するようにすべてのコンテナーを再作成します。

docker-compose up web=2などを呼び出すことで、現在scaleでできるように、コンテナを強制終了できることも私には理にかなっています。

+1

+1（ @pierrreを困らせる

+1

scale = xの場合は+1。

これに関連して、私はシングルトンを説明する方法が大好きです。 scale=1

スケールオプションでここで成功した場合

+1

上流からこれについて新しいことは何も見ていません。個人的には、パッチをハックできるかどうかを確認する機会がありませんでした。

ありがとう、
ジェイソンミルズ

• 携帯から送られました。

2016年8月8日には、17:19で、lavvy [email protected]書きました：

スケールオプションでここで成功した場合

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

+1

+1

+1

+1

+1（ @pierrreを再び困らせる

+1

繰り返しになりますが

scale = 0
テスト、デバッグに役立ちます。 通常は起動したくないが、定義したいサービスなどをプローブします。これらは通常、ファイル内の他のサービスのコンテキストで使用されるためです。

スケール= 1
私はこれらのうちの1つだけが欲しいので-_ever_。 MariaDBクラスターでは、特定のストレージエンジン（Spider、ColumnStoreなど）で構成された単一のノードのみが必要になる場合があります。

スケール= n
たとえば、「n」サービスを実行する必要があることがわかっているため、常に1つのプライマリ（構成あり）と2つのセカンダリ（プライマリとは異なる構成）を持つMariaDBクラスターがあります。

@alvinrは私には完全に理にかなっています。 デフォルトの確率は1です。

免責事項：私はマラソンや中間圏の代表ではありません

これは、Dockerサポートチームによって1年以上放棄/延期された、非常に単純な機能リクエストのさらに別の例です。 https://github.com/docker/docker/pull/12749は別の例です。 KubernetesとMarathonには、かなり前からこれらのオプションがあり（「インスタンス」：marathon.jsonファイルの3）、自動スケーリングも実装されています。 しばらくの間、Dockerデータセンターと群れから私を遠ざけてきたのは、Dockerサポートグループの不本意です。

Kontenaにはこれもinstances: 3 （https://www.kontena.io/docs/references/kontena-yml）

これを行う別の方法は、作成ファイルバージョン2にscaleセクションを追加することです。

サービスで使用されるdockerのみのオプションと混同することはありません。

例は次のとおりです。

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

scale: 0を指定する機能を備えたこれは、1つの石で2羽の鳥を殺す可能性があり、もう1つはhttps://github.com/docker/compose/issues/1896です。

これは簡単なことのようです。

3つまたは4つのnodejsインスタンスでnginx + nodejs + mongodbをデプロイしたいと思います。 アプリを起動するたびに。

それを行うためのコマンドラインオプションがある場合は、ymlファイルに入れてみませんか？

docker-スケールアップを構成するnodejs = 4

します。

簡単だ。 彼らは「他の誰かがそれを構築し、私たちがそれを構築する」というルートに行きたいと思っています
それをサポートしようとします」。ベースDockerを除いて、彼らは作成していません
なんでも。 作曲は彼らが消費した別の製品でした、そして今彼らは持っています
それをサポート/拡張する方法がわからないため、マラソンや
kubernetesは群れよりも人気があります。

2016年10月16日午後9時36分、「MichaelSchwartz」 [email protected]
書きました：

これは簡単なことのようです。

3つまたは4つのnodejsインスタンスでnginx + nodejs + mongodbをデプロイしたいと思います。 毎日
アプリを起動するとき。

それを行うためのコマンドラインオプションがある場合は、ymlファイルに入れてみませんか？

docker-スケールアップを構成するnodejs = 4

します。

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

正直なところ、これが非常に明白であるように思われるため、これに_any_プッシュバックがあることに少し驚いています...

@westlakem Docker for MacOSが同じ運命をたどらないことを期待しましょう。うまくいけば、Unikernelの連中が固執します。

一度にその機能サイズで完全なスタックを立ち上げるのは素晴らしいことです。 現在のユースケースでは、サービススタックが正しく機能するには「workers = 16」が必要です。

これはひどいです：

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

これは明らかに次のようなものに置き換えることができます。

docker-compose up --abort-on-container-exit --scale workers=16

編集：「Rancher」にはdocker-composeのような構文があり、初期スケールパラメータをサポートしていることがわかります： https ：

回避策は、YAMLアンカーおよびマージ機能を使用し、docker-composeファイル内でサービスを複製することです。

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

NS ...

これはとても便利です！

これは超奇妙ですこれは存在しません...

私はとても怠け者なので、重複したサービスを作成しなければならなくなる可能性があります。

これは、composerファイルv3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.jsonですでに作業中であり、docker-composev1ですでにサポートされています。 10.0-rc1

彼らの「サービス」オファリングにはパラメータが組み込まれています。
この問題の購読者は、開発チームの誰も私たちにそのことを知らせませんでした
それはサービス製品で提供されていたので、誰かがRCノートを読まなければなりませんでした
洞察のために1.10のために。 Docker担当者はどこにいますか？

2017年1月6日金曜日午前6時30分、Yasmany Cubela Medina <
[email protected]>は次のように書いています：

これは、composerファイルv3https ：//github.com/aanand/ですでに作業中です
構成ファイル/blob/master/schema/data/config_schema_v3.0.json
そして、docker-composev1.10.0-rc1ですでにサポートされています

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

+1

+1

こんにちは、関連する質問があります。
docker-compose upが今までに設定したスケールを覚えているのではないかと思ったことはありませんか。

たとえば、 docker-compose scale nodejs_web=4からdocker-compose down 、
次に、 docker-compose up再開すると、4つのnodejs_webが開始されます。

scaleコマンドが数字4をどこに保存するのか知りたいですか？

docker-compose.ymlは次のようになります。

version: '2'
services:
  nodejs_web:
    image: node
    command: node

＃2496の@dnephin提案をサポートし
この基本的な機能を教えてください。

新しいバージョンのDockerのサービスは、「レプリカ」機能を提供します。

15:28時月、2017年3月20日には、alwaysastudent [email protected]
書きました：

＃2496の@dnephinhttps ：//github.com/dnephin提案をサポートし
https://github.com/docker/compose/issues/2496
この基本的な機能を教えてください。

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

@ westlakem-その機能は群れのためのものです。 通常のサービススケーリング用ではありません。

非常に多くの長所、少数の短所。 この問題の問題は何ですか？

https://github.com/docker/compose/issues/2496にscaleコマンドを完全に削除することに関する最近の提案があり

作成ファイルにinitial_scale: 3オプションがない理由や理由が本当にわかりません（ scale: 3だけではいけない理由はわかります）

1.13.0で実装されました。 皆様からのフィードバックと忍耐に感謝します。

@ shin-なぜこれは閉鎖されていると見なされるのですか？ すべてが自動化され、バージョン管理されている大規模なアプリを管理する場合、Dockerを実行するAnsibleを変更して、実行されるサービスのインスタンスの数を定義する必要があります。

Ansibleは、Dockerを実行できるようにすべてをセットアップする必要があります。 Dockerは、アプリに必要なサービスのインスタンスの数を定義する必要があります。 サービスのインベントリを知るのはDockerの責任ですが、スピンアップするコンテナの数を知るためにDockerを呼び出すのはAnsibleの責任ですか？

@greenscar申し訳ありませんが、問題が何であるか正確には

これがバージョン3に存在しないのはなぜですか？ 「deploy.replicas」と「up」は同等ではないため、非常に混乱します。この機能はv3にはないものと言えます。

@cgarciae deploy.replicasは、 scaleと同じ目的を果たします。 なぜあなたの見解ではそれらは同等ではないのですか？

@ shin-スウォームを作成せずにdocker-compose up -dのみを使用する場合、dockercomposeは「デプロイ」設定を無視するように指示します。

@cgarciae Swarmを作成したくないのに、なぜv3ファイルを使用しているのですか？

dockerを使用している人は誰でも、scaleパラメーターがdocker2または3ファイルのいずれかで機能することを期待していると思います。 そうしない理由はなく、deploy.replicasのデフォルト値を設定することもできます。 したがって、deploy.replicasが設定されている場合、群れのスケールをオーバーライドします。 この画像の何が問題になっていますか？それは誰もが期待することです（もちろん、それが気に入らない場合は、docker-compose.ymlで使用する必要はありません）。

前回の再配置以降の以前のようにスケールアップするのを忘れたため、スケールパラメータが欠落しているため、サービスが失敗しました-.-なぜこれがサービスを節約し、実行内容によっては命を救うことになるのでしょうか。

この問題もヒットします。 Docker構成構成内から開始するサービスの数を指定する方法がないようですか？ dockercomposeドキュメントにdocker-composeで機能しないものに関するドキュメントがたくさんあることはさらに混乱します...

ちょっと待ってください。dockercomposeconfigをversion: "2.2"に変更すると、 scale: 2使用できますが、それ以降のバージョンに移動したい場合は、これを行うオプションはありませんか？

わかりました。この「バージョン」の問題は、実際にはバージョンがすでに表示されていることを意味するものではありません。https：//github.com/docker/compose/issues/4693

2.2には存在しないいくつかの構成が必要なため、v3.6を使用します。 ローカル開発では、群れを使用しませんが、docker-compose.overrides.ymlのいくつかのコンテナーにscale = 0を設定したいと思います。 それらのいくつかは、frontendbuildコンテナのようなビルドプロセス専用であるためです。 このコンテナーは、実行中の他のコンテナーと一部のボリュームを共有しますが、docker-composeupでこれらの他のコンテナーと一緒に開始しないでください。 したがって、buildcontainerはrunコマンドで実行するだけです。 はい、docker-composeupを呼び出すときに--scaleparamを設定できますが、構成に直接書き込む方がよいと思います。 :)

スケールパラメータをありがとう。 誰でもConsulとVaultのHA構成を使用できるように、非実稼働のdocker-compose.yml使用することができました。 scaleパラメーターにより、ローカルHA構成のプロビジョニングが容易になりました。 https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

この場合、誰かがHA構成でConsulとVaultを試して、ConsulDNSを使用することのみを目的としています。

どのバージョンのdockercomposeを実行していますか？ v3以降、この機能は削除されたため（つまり、実装されたことはありません）、無視されます。 https://docs.docker.com/compose/reference/scale/を参照して

機能が不足しているため、v3形式を使用することはありません。 使用している機能に応じて、最も低い2.1または2.2形式を使用する傾向があります。

編集：私がv3フォーマットを避けると言うのは言うまでもありません。 私が作成ファイルを書きに行くとき、それは通常私が使いたいものを失っています。

さて、あなたはスウォームスタックを使ったdockercomposeについて話していると思います。それが理由です。 私は試したことはありませんが、オーケストレーターとマルチノードなしでdockercomposeを使用してHAについて話すのは奇妙です。 それは「poc」またはテスト目的ですか？ とにかく、私はこの文脈で試したことはありません

この場合、HAは単に領事クラスターとボールトクラスターを指します。 これは、実験とブートストラップの容易さに利用できる概念実証として機能することを目的としています。 HAは、DockerHAやマルチマシンHAを指すものではありません。 実験者がクラスターコンテナの1つを強制終了し、領事やボールトサービスが影響を受けていないことを確認できるのはHAだけです。