Moby: Compose v3 / docker stackdeployに `extends`機能のサポートを追加します

私はいくつかのメモを追加しましたhttps://github.com/docker/compose/issues/4315#issuecomment-280617251それがdockercomposeファイル2.1バージョンまで存在するので拡張を戻すことは良い考えではありませんが主な機能は私ですミスは、抽象サービスを宣言できることです（これは決して実行されるべきではありませんが、便宜上、サービスの共通プロパティをグループ化するために使用できます）。

docker / compose＃4315からのコメントで、 extendsは少し質素であることに同意しました。

解決策はお勧めしませんが、FWIWは、悪用の程度を示すために、作成ファイルの上部を飾る規則を次に示します。

#
# Docker Compose configuration
#
# Due to lack of "expressivity" in Compose, we define our own couple of service
# "pseudo-types":
#
#   - image-only services (name: *-image)
#
#     The only goal of these is to build images. No other services build images.
#
#     These have entrypoint overridden to exit immediately.
#
#   - base services (name: *-base)
#
#     These contain common configuration and are intended to be extended.
#
#     Their command (not entrypoint, to keep the original one) is overridden to
#     exit immediately. Service must support a command to exit immediately.
#
#   - task services (name: *-task)
#
#     These are intended for running one-off commands.
#
#     Their default command is overridden to exit immediately. Service must
#     support a command to exit immediately.
#
#   - "real" services
#
#     These are actual services that stay up and running.
#
version: '2'
services:
  ...

v2.1のように拡張するのは良い選択だと思います。 Extendsは実際には単純で理解しやすいものです。これは、各環境にとって、dev、prod、envの間で少し読みやすい変換を行うにはあまりにも良い習慣です。

実際、私は持っています

• 基本ルールを提示する一般的なdocker-composeファイル
• 開発Dockerは、それを拡張し、開発者向けの機能を備えています。
• ステージングドッカーは、この環境のための設備を備えた一般的な拡張も構成します
• プロダクションDockerは、この環境の機能、特にコンテナーレプリケーション、再起動に関するルールなどを備えた、一般的な拡張機能も備えています。

これは機能します。なぜこのチケットで完全な書き直しを検索する必要があるのか​​わかりませんが、興味深い機能を維持する必要があります。 Extendsは、他の手法では簡単に解決できない特別なユースケースの良い部分です。 私は拡張の可能性に満足しています。

v3.x形式へのアップグレードもブロックします。

Dockerコンテナの定義は、インスタンスごとのフォルダレイアウトに保持されます。各フォルダには、手元のコンテナインスタンスの環境仕様を定義するdocker-compose.ymlが含まれています。 一般的なもの（DRY）を除外するために、親フォルダー内の基本サービス定義を使用し、 extendを使用します。

したがって、特定のコンテナーインスタンスを管理する必要がある場合は、適切なフォルダーにcdするだけで、追加の構成なしでdocker-composeコマンドを直接実行できます（チームメンバーに-fフラグは必要ありません）ルックアップまたは知る必要があり、そのままで期待どおりに機能します）。

バージョン3の作成ファイルの使用がブロックされています。

私はservices.ymlを使用してサービスの基本レイアウトを定義し、それを開発環境（主にボリュームの追加）用にdev.services.ymlで拡張しますが、拡張の（DRY）再利用性が気に入っています。追加した。 これは取引を妨げるものではありませんが、必須の機能がない限り、バージョン3に移行できなくなります。

しかし、私はv2.1の「拡張」ソリューションをより適切なもので改善することに反対していません。 抽象サービスのようなものは、より安全に使用でき、より強力になる可能性があります。

たとえば（抽象的であるため）抽象ベースサービスがホスト部分を定義せずにローカルマウントポイントまたはサービスに必要なネットワークを定義する抽象ボリューム/マウントポイント/ネットワークのサポートを想像できます-つまり、派生サービスは/を定義できますマウント/ボリュームとネットワークのホスト部分を、ホスト/ステージ環境で適切なものにマップします。

これは、私が知る限り、「extends」では今はできないことの例であり、いくつかの興味深い可能性を開くでしょう。

拡張機能を削除しても、まったく役に立ちませんでした。 同じボリュームがマップされ、環境変数とラベルが設定された状態で開始された多くのWebサービスがあります。 また、同じヘルスチェックポリシーがあります。 そして、ポートは言うまでもありません。 同じホストで複数のプロジェクトを処理している場合、複数の-fオプションを使用して作成ファイルを組み合わせるのは面倒でエラーが発生しやすくなります。

@ shin-これは3.2スキーマに戻されますか？

私は本当に、本当にextendsファイル形式に戻したいと思っています。 私はこれを使用して、多くのプロジェクトの抽象サービスをさらに改良してきました。 複数の-fオプションがほぼ法案に適合することは理解していますが、常に機能するとは限りません。 たとえば、私は抽象サービスの名前を、目前のプロジェクトのコンテキストでより意味のある名前に変更することがよくあります。 これは、複数の-fオプションで発生するオーバーライドがサポートしていないものです。

ただし、ファイル内の抽象サービスを「インスタンス化」する他の方法である限り、正確なextends失ってもかまいません。

私は共通のサービスファイルとそれを拡張する一連のサービスを備えたセットアップを持っており、主にボリュームを変更しているので、 extends機能に依存していると思いますが、セットアップを説明する他の良い方法はありません。

--frustrated

+1
docker-composeファイルをフラット化するという推奨事項の背後にあるロジックはわかりますが、開発サービストポロジを定義するコードを複数のプロジェクトに複製するというアイデアは好きではありません。 今のところ、シェルスクリプトで-f回避策を使用して、開発者がどのサービスをどの場合に含めるかを覚えておく必要がないようにします。

構成構造のより良いファクタリングを可能にする満足のいく解決策がここに見つかることを願っています！

私のユースケースリストの一番上にあるのは、構成管理された一連のサービスをドライアップすることです。 v3の場合、「extends」を利用できると思いました。 v2に戻りたくありません...そして-fプロセスの回避策を使用しなければならない特別な場合はしたくありません。

ねえ、誰かがこれに取り組み始めましたか？ 追跡するPRが見つかりません。 ここでもいくつかのことが簡単になります（上記のユースケースと非常によく似ています）。

バージョン3がフリーズしていて、共通の構成を共有する方法が必要だったので、ここで共有できると思う小さな回避策をハッキングしました（これが適切な場所かどうかはわかりませんが、他にどこでできるか教えてください）この情報を共有する:)）

リポジトリにreadmeがあるので、ここでは詳しく説明しません。
素敵なものを持って、みんな☮️

編集：

申し訳ありませんが、ここにリンクがあります：D

+1

+1

+1

+1をありがとう💃
その間に、別のdocker noopイメージを見つけました。これは、10 ^ 3倍小さくなっています（実際のnoopがアセンブリで書き込まれているため）。

残念ながら、そのリポジトリにはライセンスがありません。 私はすでにfacebkで所有者にメッセージを書きましたが、彼はまだ答えていません。 もっと多くの人が彼にそれについて質問したら、たぶん彼はライセンスを追加するでしょう:)

拡張ユースケースの一部（単一ファイル内のもの）に役立つ可能性のあるものは、YAMLアンカーのサポートです： https ：

JSONスキーマがservice must be a mapping, not a NoneType.検証に失敗している可能性があります。

ねえ、 @グレーサイド、yamlアンカーは少なくとも私にとっては機能します。 私がそれらをどのように使用するかについては、上記の私のコメントを参照してください。

わかりましたが、noopサービスを使用するのは悲しいことではありませんか？

特にenv変数の場合、それらのenv変数はどのような値を処理しますか？ シークレットに関する場合は、スウォームシークレット機能（またはその他のシークレットソリューション）を使用します。 設定に関する場合、ほとんどの場合、設定はアプリ/サービス固有であり、サービス間で共有することを目的としていません。

サービス間で設定を共有する必要がある場合、ほとんどの場合、同じコンテナーイメージを起動しますが、実行時の目的/タスク（コンシューマー、プロデューサー、httpワーカーなど）が異なります。

設定に関する場合、ほとんどの場合、設定はアプリ/サービス固有であり、サービス間で共有することを目的としていません。

私は反対する傾向があります。 私が現在取り組んでいるプロジェクトでは、たとえばボリュームに使用します。

# Volume paths
environment:
  - &volume_a        volume-a:/usr/share/my_project/volumes/volume-a
  - &volume_b        volume-b:/usr/share/my_project/volumes/volume-b
  - &volume_c        volume-c:/usr/share/my_project/volumes/volume-c
  - &volume_d        volume-d:/usr/share/my_project/volumes/volume-d

これで、次のようにこれらのボリュームを指定できます。

volumes:
  - volume-a:
  - volume-b:
  - volume-c:
  - volume-d:

services:
  some-service:
    image: some-image
    volumes:
      - *volume_a
      - *volume_b

  some-other-service:
    image: some-other-image
    volumes:
      - *volume_b
      - *volume_c

  some-third-service:
    image: yet-another-image
    volumes:
      - *volume_a
      - *volume_b
      - *volume_c
      - *volume_d

これにより、どのコンテナを使用しているかを考えることなく、さまざまなボリュームを簡単にナビゲートできます。Imho、これは、Docker構成のセットアップをより一貫性のあるものにし、使用と保守を容易にする1つの方法です。

はい、 @ JanNashは理解していますが、以下の例では、noopサービスがありませんか？

しかし、多くの場合、アンカーだけでは不十分です。

私の場合は、同じプロジェクトで複数の環境をサポートする必要があります。 ここで私たちのプロジェクトの足場を見ることができ

開発時にはdevel.yamlを使用しますが、本番環境ではprod.yamlを使用します。 test.yamlます。 それらはすべてcommon.yamlから継承し、 .envファイルからいくつかの一般的な変数を取得します。

それぞれに独自の特性があります。

• 開発環境は開発速度を目的としているため、ビルド引数を使用してビルドを高速化し、開発者のコ​​ンピューターからのアプリコードを使用してボリュームをマウントし、アプリを外部から分離するダミーサービスを追加します。
• prodは代わりに安定性を目指しているため、すべてのコードをダウンロードしてコンパイルし、ボリュームを使用する代わりにイメージ自体にバンドルします。 ビルドは遅くなりますが、より安全です。
• testは、prodとまったく同じですが、外部サービスから分離して、外部の世界を汚染しないようにすることを目的としています。

この単純な分離により、非常に機敏で柔軟なDevOpsパイプラインを実現できます。このパイプラインでは、使用する環境に応じて少し調整するだけで、すべての人が異なるステージ間で同じコードを使用します。

ファイル形式v3を作成するように移動しようとしましたが、 extendsがサポートされてい.envがないためです。 SwarmとDRYのどちらを選ぶかは、今のところDRYを選択しましたが、いつかSwarmが必要になり、両方の機能が再びサポートされることを願っています...☺️

...または少なくとも、DRYフルソリューションから有効なDRYレスフォーマットを生成する方法があります。 docker-compose bundleはそのためだと思いましたが、今は非推奨になる運命にあるようです...

...または、すべてを作成する別のツールがあります（ ansible-containerにも

https://github.com/moby/moby/issues/31101#issuecomment -301212524のリンクには、YAMLアンカーの実例を含むREADMEが含まれてい

@JanNash👍

@Yajo聞いたことがありますが、これは回避策であり、

〜.envサポートがないため、回避策もハッキングしました（私のプロジェクトはまだ本番環境にないので、話は少し安いです、私は知っています:)）。 さまざまな環境（今のところ、ローカル開発と小さな開発サーバー）でさまざまな環境変数のセット（依存関係やイメージのバージョン/タグなど）をサポートするために、 local.env 2つのファイルを使用します。 development.envで、コマンドをdocker-compose <command>だけで実行する代わりに、前にそれぞれの.envファイルをシェルにソースするか、 (. local.env && docker-compose <command>)ように実行します。 まだハックですが、今のところ、私はこれに非常に満足しています。〜

素敵なものを持ってください、y'all🚶

たぶん2桁でも：D

@JanNash待って！ .envは3サポートされなくなりましたか？

私は実際には知りません、私はそれがそうではなかったというコメントを読んだだけです。
local.envとdevelopment.envのプロシージャを使用しているのは、主に、実装時にautoenvについて知らなかったためです：D
混乱の可能性をお詫び申し上げます。

ああ、 @ Yajoはこのコメントで.envサポートがないことに言及しました。
@Yajo、詳しく教えていただけますか？

すみません、私のせいです。 動作していないわけではなく、以前のように自動検出されるのではなく、 env_file: .envで必要があるだけです。 元の問題に戻りましょう。

extendsどこかに落とすという議論はありますか？ かなり使用されている機能であることがよく理解されていると思うので、ユースケースを示す前にそれを読んでみたいと思います。

こんにちは、私は1つの質問があります-いつですか？ 「拡張」サポートがv3に戻るのはいつですか？

@JanNashあなたはそれよりもはるかに小さくすることができます。 私はあなたのリポジトリに対してgithubに問題を提出しました、私は私のマシンの750kから1200バイトにnoopを取得しました。

現時点では、群れの中でextendを使用できないことがわかります。
同じ公開ポートを使用し、1つの追加の環境変数を持つサービス上の1つのコンテナーを使用して、同じサービスを起動する方法についてのアイデアはありますか？

スウォームスタックデプロイでのサポートを拡張するための+1

やあ、
複数のgitリポジトリに分散しているマイクロサービスアプリケーションを実行しています（それぞれにdocker-composeファイルがあります）。
デプロイは、各サービスを拡張する1つの「ルート」docker-composeファイルによって主導されます。私たちにとって、このextends機能はスタックデプロイに本当に必要です。
したがって、スウォームスタックデプロイのサポートを拡張するための+1もあります
ありがとう。

YAMLの単純な継承（ &default 、 <<: *default ）を一時的な解決策として使用できます。

version: '3'
services:
  worker: &default
    build: .
    command: bundle exec rake jobs:work
    env_file:
      - .env
    volumes:
      - .:/app
    depends_on:
      - db
      - redis
    links:
      - db:postgres
  web:
    <<: *default
    command: bundle exec puma -C config/puma.rb -p 3000
    ports:
      - "3000:3000"
  spring:
    <<: *default
    command: bundle exec spring server

もちろん、 extends機能の方が優れています

別のファイルを拡張する場合はどうですか？

Yamlにはファイル拡張機能がありません:(

Dockerへの寄稿者からこの機能に関する更新はありますか？ これは再導入される予定ですか？ そうでない場合、同様の計画はありますか？ そうでない場合は、なぜそうではありません..？

@quolpr 、「プロトタイプ」（つまり&default ）は常にDocker Composeによって解釈されるため、ほとんどの場合、「YAML単純継承」コードはextendsに置き換わらないのではないかと思います。 workerというサービス。 a）したがって、どのサービスを明確に定義する必要があるか、b）望ましくない可能性があります。

とにかく、間違いなく興味深い機能です。

@laugimethodsは、YAML参照も使用できます。

version: '3'
services:
  spring:
    build: ./app
    command: /bin/sh -c "bundle exec spring server"
    volumes: &default_volumes
      - ./app:/app:delegated
      - bundle:/bundle:nocopy
  worker:
    build: ./app
    command: bundle exec sidekiq -v -C config/sidekiq.yml
    volumes: *default_volumes

（ &default_volumesと*default_volumes注意してください）

しかし、なぜextends機能が削除されたのか本当に理解できません🤔

参考までに、不足している「拡張」機能を置き換えるために、現在、 .yamlファイルの合成/マージを使用しています。
https://github.com/Logimethods/smart-meter/blob/master/README.md#docker -compose

拡張機能が拡張機能を何らかのアンチパターンと見なす場合は、それを使用しないでください。ただし、切り取らないでください。

extendsを使用せずに、意図したアプローチの明確な説明をお願いできますか？ 特にGitサブモジュールに含まれるファイルから継承する場合、クロスアプリケーションネットワーク配線などを処理するメタプロジェクトの定義を可能にする場合に、これを広範囲に使用します。複数のdocker-compose.ymlファイルを指定できることはよく知っていますが、それらをオーバーライドします。これは、 extendsを使用してソース管理にチェックインできるのではなく、コマンドラインで相互接続を指定する必要があることを意味しますか？ または、v3のどこかでいくつかの新機能を見逃しましたか？

複数のプロジェクトでextendsを頻繁に使用して、さまざまな環境やさまざまなホストのサービス属性の共通セットを継承しています（読み取り： extendsを使用して別のファイルから継承しています）。

昏迷でextendsキーワードの削除を読み、デイジーチェーン接続を必要としない代替品を見つけようとした後、 -f dockercomposeファイルextendsを削除する理由は何ですか。

linksとvolume-fromの問題は理解していますが、ベースymlファイルでの使用を控えるのが最善の方法のようです。

車をひっくり返すのに慣れているからといって、車のホイールを取り外すことはまずありません...そうですか？

PS：noopとanchorsは面白そうに見えますが、最も単純なプロジェクトに不必要な複雑さを追加します...

非常に単純な例として：

common/common.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  ports:
    - "8080:8080"

prod/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  image: the-prod-image:latest-release
  ports:
    - "80:80"
    - "80:443"
  environment:
    NEW_RELIC_KEY:

extendsなしでDRYの原則をどのように維持するのですか？

現在、これが原因でバージョン2.1からアップグレードする理由はありません。

@teodorescuserban 、

デイジーチェーン接続-fdockercomposeファイル

それの何が問題なのですか？ docker-composeを呼び出すために、短いエイリアスを使用して独自のスクリプトを作成できます。

次の構造を使用します。

common / common.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev / docker-compose.yml

services:
  web:
    ports:
      - "8080:8080"

prod / docker-compose.yml

services:
  web:
    image: the-prod-image:latest-release
    ports:
      - "80:80"
      - "80:443"
    environment:
      NEW_RELIC_KEY:

コマンド

docker-compose -f common/common.yml -f dev/docker-compose.yml -p myproject up --build

docker-compose -f common/common.yml -f prod/docker-compose.yml -p myproject up --build

私はその機能を知りませんでした。 CLIは💩になりますが、機能します。

それがextendsの正式な代替品になるのであれば、それを簡単にする方法があるはずだと思います。

例えば：

docker-compose.yml

version: "3"  # or whatever
extend:
  - ./common/common.yml
  - ./dev/docker-compose.yml
services: # Not required now
  # etc.

このようにして、必要なすべてを実行する単一のdocker-compose.ymlファイルを指すことができます。

便利な代替手段は、 COMPOSE_FILE環境変数で複数の作成ファイルをサポートすることです。

@ヤジョ

便利な代替手段は、COMPOSE_FILE環境変数で複数の作成ファイルをサポートすることです。

https://docs.docker.com/compose/reference/envvars/#compose_fileから：

この変数は、パス区切り文字で区切られた複数のComposeファイルをサポートします（LinuxおよびmacOSではパス区切り文字は: 、Windowsでは; ）。 例： COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml 。 パス区切り文字は、 COMPOSE_PATH_SEPARATORを使用してカスタマイズすることもできます。

@ dermeister0 https://github.com/ImmobilienScout24/yamlreaderなどのツールを使用して、これらのファイルを永続的にマージすることもでき

> yamlreader common/common.yml prod/docker-compose.yml > docker-compose-prod.yml
> docker-compose -f docker-compose-prod.yml -p myproject up --build

> cat docker-compose-prod.yml
services:
    web:
        build: .
        environment:
            DOMAIN: null
            NEW_RELIC_KEY: null
            PREFIX: null
        image: the-prod-image:latest-release
        ports:
        - 80:80
        - 80:443

@ dermeister0あなたの提案に感謝します、残念ながらそれはそれからの不格好な方法です。 extendsすると、それらをデイジーチェーン接続する必要があるかどうかを実際に知る必要がなくなります。 私は自分でそれを行うことで生きることはできますが、このソリューションを私の親愛なる開発者に適用することはできませんでした。

ただし、 COMPOSE_FILE env変数に複数の値を含めることができることに気づいていませんでした。 ありがとう@gsong ！ それは素晴らしく、それを使用することができます（私はそれを.envファイルで定義します）。 ここに1つの問題があります。ベース/共通ファイルには、必要のないサービスも含まれている可能性があります。

たとえば、データベースとWebコンテナを定義するフラットな共通ファイルを考えてみましょう。 ステージングでは、それらをすべてまとめておく必要がありますが、prodでは、db用とweb用に別々のホストが必要になります。

また、docker-compose.override.ymlがデフォルトでロードされます。

https://docs.docker.com/compose/extends/#understanding -multiple-compose-files

私はバージョン3.3でこのアプローチを使用します：

• 一般的な構成オプションとサービスをdocker-compose.ymlます;
• 特定の開発構成とサービス（たとえばxdebugなど）にはdocker-compose.override.ymlを使用します。
• 特定のステージング構成オプションにはdocker-compose.staging.ymlを使用します。

注：本番環境ではDockerを実行していません。

このアプローチを使用すると、 docker-compose buildを使用してローカルで簡単にビルドでき、ステージングでデプロイする場合は次を使用します。

docker-compose -f docker-compose.staging.yml -f docker-compose.yml build

Apacheを使用していますが、開発用とステージング用に別々の仮想ホストファイルがありません。 私は別のファイルを持つことを避けるためにかなりの時間を費やしました。 結局、有効なアプローチは<IfDefine>と環境変数（ymlファイルのenvironmentセクションで設定したもの）を使用して、たとえばssl構成を含めることだけです。 また、TLDとドメインプレフィックスを使用しているので、 www.example.local http：//www.example.local/ ：8080やwww.staging.example.comhttp ： //www.staging.example.comのようなものを使用できます。 / 。 ローカルでは、Webサイトはhttpおよびhttpsでのステージングで実行されます。 このアプローチでは、ファイルの異なるバージョンを維持する必要はありません。 同じことが本番環境でも可能だと思いますが、私が言ったように、本番環境ではDockerを避けたいと思います。

パスはすべて相対パスであるため、コンテナはどのような環境でも機能します。

私の2セント

-フィリッポ

私の場合、以前は次のようなものを使用していました。

• common.yml
• devel.yml-> common.ymlの拡張
• prod.yml-> common.ymlの拡張
• docker-compose.yml->ローカル、git-ignored、目的の環境（develまたはprod）へのシンボリックリンク。

https://github.com/moby/moby/issues/31101#issuecomment -329482917とhttps://github.com/moby/moby/issues/31101#issuecomment -329512231に感謝しますが、これについては知りませんでした。これで、別のスキーマを使用してv3に移行できます。

• docker-compose.yml->以前はcommon.ymlでした
• devel.yml-> docker-compose.ymlのオーバーライド
• prod.yml-> docker-compose.ymlのオーバーライド
• docker-compose.override.yml->ローカル、git-ignored、目的の環境（develまたはprod）へのシンボリックリンク。

env変数を使用して必要なハックを行うこともできるので、私の場合は問題が修正されています。 ありがとう！ 🎉（申し訳ありませんが、文句を言う前に新しいドキュメントを正しく読む必要がありました）。

PS：それでも、 extendsを取り戻すのは良いことですが、少なくとも十分に公平な代替手段があります。 😊

@ shin-最初に、 extends機能が3.0にないのを見て非常に失望しましたが、YAMLアンカー（例：https：//github.com/JanNash/docker-noop）は十分な交換以上。

唯一のことは、上記の例のように、アンカーをdocker-compose.ymlファイルの有効なセクションに配置する必要があるということです。

（トップレベルの） templatesプロパティまたはGitLabのような隠しキーを取得して、アンカーを定義する方法をより柔軟にすることはできますか？

@ schmunk42はhttps://github.com/docker/cli/pull/452をご覧ください

docker-compose.override.ymlに依存する場合の問題は、含める必要のあるオーバーライドのタイプが1つだけであり、オーバーライドのレイヤーが1つしかないことを前提としていることです。

私の場合、すべてのローカル開発に共通の特定の動作が必要ですが、開発者がWindows、OSX、またはLinuxを実行している場合は、微妙に異なる動作が必要になる場合があります。 これをdocker-composev3コンテキストで管理しやすくするために、Linuxユーザーはステージング環境と同じ動作で動作しています。これは機能しますが、他の開発者とは少しずれていることを意味します。

-fをローカル開発に使用することは避けています。これは、人為的エラーが非常に発生しやすく、あまりにも多くのことを切り替えるために

参考までに、上記のx-たハックと、 .envプロジェクトファイルのCOMPOSE_FILE変数を使用してdocker-composeファイルをデイジーチェーン接続し、docker-を追加すると思います。 compose.override.ymlは、これまでに遭遇したすべてのユースケースを解決するはずです。

ymlアンカーも、近い将来使用する予定の気の利いたものです。

x-ハックの美しさにあまり満足していませんが、私はそれで生きることができます。

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

extends削除すると、胸焼けが多くなり、v3への移行がブロックされるか、ハッキングに頼るようになります。 いくつかの一般的なもの（更新ポリシーなど）を実行できる「テンプレート」（または抽象）サービスを定義する機能が好きです。

私は、Docker作成ファイルをextendsで前処理し、拡張機能が解決されたクリーンなv3ファイルを吐き出すことができる単純なgolangフィルターユーティリティに取り組んでいます。
解決-作成 docker stack deploy -c docker-compose.yaml
（またはdocker-構成する）

これは、少なくともいくつかのユースケースで機能しますか/なぜ落とし穴ですか？

@pnickolovそれは私にとってゴージャスだろう。

私はansible-containerを探していました（私はansibleを個人的に使用していますが、まだ作業していません）。これは必要なすべてを実行するように見えますが、あなたのようなスクリプトの方が望ましいです（チャーンが少ない）

extends:キーを再帰的に処理できる限り、私は幸せです！

わかりました、 extends代替案を見つけたようです...👍

気がかりなのは、Mobyのプロジェクト管理が互換性を維持することを重要な要素と見なしていないように見えるという事実です。 上位互換性は、特に本番環境に展開される大規模なアプリケーションの場合、広く採用するために不可欠です。 extendsようなコア機能が残る保証がない場合、Docker Swarm / Docker EEをどのようにプッシュできますか？ 👎
良い評判は勝つことは難しく、失うことは簡単です...

個人的には、カスタムスクリプトやansibleのようなより大きなソリューションではなく、 v2構文でextendsによって処理されるタスクを実行するためにネイティブYAML機能に依存したいと思います。 私は以前に同様の問題を抱えていて、複数の.ymlファイルなどを使用するなどの解決策が出る前に独自のコンバーターを書き始めました。（https://github.com/schmunk42/yii2-yaml-converter-command）-しかし、そうではありませんでした実行可能なソリューション。

私にとって、これがバージョン管理ポリシーと一緒に行われる場合、機能を非推奨にすることも問題ありません。 たとえこれが私たちの側で何らかの仕事を意味するとしても、あなたは古いものを永遠に運ぶことはできません。

@ schmunk42機能の

• 削除された機能は、実際には使用されていないか、進化の本当のブロッカーです
• 事前に発表されます
• 移行パスがすぐに提供されます

残念ながら、（私の本の）これらの要件はいずれもextends非推奨には適用されません...

@laugimethods v3を使用する必要がある理由は何ですか？

@ schmunk42群れのため：

最新の推奨バージョンであるバージョン3.xは、ComposeとDockerEngineのスウォームモードの間で相互互換性があるように設計されています。 これは、YAMLのルートにあるバージョン：「3」またはバージョン：「3.1」などのエントリで指定されます。

docker stack deployコマンドは、バージョン「3.0」以降のすべての作成ファイルをサポートします。

ところで、私のコメントはextendsでなく、将来発生する可能性のある（痛みを伴う）非推奨にも関連しています...

ええ、スウォームモードのために同じ問題に直面しています。

そもそも、DockerCLIが--composer-file入力を使用できるようになった理由を自問しました。 しかし、 docker/swarmでの学習から、（自己管理）スウォームでスタックを実行することはかなり複雑なことのように見えます。これがエンジンに移行された理由はいくつかあります。

ここで私の発見のいくつかに注意するだけです... v2からv3.4への移行は簡単ではありv2 。

私の問題のいくつか：

• volumes_fromような他のサポートされていないオプションがありますが、とにかくそれを削除したかったので、回避するのはかなり簡単です
• .envファイル（ docker-compose ）はDockerCLIでは効果がありません
• 複数の作成ファイル（ docker stack deploy -c docker-compose.yml -c docker-compose.override.yml doro ）を指定すると、正しく機能しないようです。エラーはありませんが、正しくマージされていないように見えますが、 docker-compose configようなコマンドもありません。
• v3.4構文をサポートするdocker-compose 「インストールが簡単な」（プレリリース）バイナリはありません。 Dockerエッジのように
• 外部ネットワークは--scope swarmで作成する必要があります

CC：@handcode

最新のビルドを使用する

• docker 17.09.0-ce
• docker-compose 1.17.0dev

現在、この構成パイプラインを使用して、_extend_と_noop_の使用を置き換えています。
物事を少し乾燥させます
これが誰かを助けることを願っています

base.yml （共有定義、これは有効なyamlドキュメントであるため、_docker-compose config_を使用してマージ可能）

version: '3.4'
networks:
  net_back:
    external: true

base-inject.yml （共有アンカー定義。残念ながら、アンカーは異なるyamlファイル間で参照できないため、 base.ymlに追加できません。代わりに、これらはテキストとしてfoo.ymlに挿入されます。これを

x-logging: &logging
  driver: json-file
  options:
    max-size: "50m"
    max-file: "2"

foo.yml （汎用スタック定義、 base.ymlからのオブジェクトの参照、 base-inject.ymlからのアンカー、およびfoo-dev.ymlでオーバーライドされたオブジェクト）

version: '3.4'
[[base-inject]]
services:
  foo:
    image: ${DOCKER_REGISTRY}/foo:${IMAGE_VERSION}
    volumes:
      - type: volume
        source: "volfoo"
        target: "/foo"
    networks:
     - net_back
    logging:
      <<: *logging

foo-dev.yml （環境スタック定義ごと）

version: '3.4'
services:
  foo:
    ports:
      - "8080:80"
volumes:
  volfoo:
    name: '{{index .Service.Labels "com.docker.stack.namespace"}}_volfoo_{{.Task.Slot}}'
    driver: local

次に、展開コマンド：

docker stack rm stack_foo && echo "waiting..." && sleep 3 &&
  cat foo.yml | sed -e '/base-inject/ {' -e 'r base-inject.yml' -e 'd' -e '}' > ./foo-temp1.yml &&
  export $(sed '/^#/d' ./dev.env | xargs) &&
  docker-compose -f base.yml -f ./foo-temp1.yml -f foo-dev.yml config > ./foo-temp2.yml
  docker stack deploy --with-registry-auth --prune --compose-file ./foo-temp2.yml stack_foo

1. 古いスタックを削除します
2. スタックリムーバブルが伝播するのを待つ
3. アンカーを一般的な定義に挿入し、tmpファイルに保存します
4. ファイルからenvファイル変数を読み取り+設定します
5. docker-composeを使用して、3つのファイルをマージします
6. マージされたファイルをデプロイする

3つ以上のファイルの作成でextendsを欲しがっている人のために、 baclinというツールを手に入れました。 baclinそのようなディレクティブを線形化し、すべてのextendsディレクティブをそれらのコンテンツで再帰的に置き換えます。 これはアルファ版ソフトウェアです。現在、Swarmモードとスタック展開をサポートするコードを記述しているため、コードは私の機械の一部です。 baclin初期バージョンのプラットフォームバイナリは、こちらから入手できここに報告してください。

これは本当に紛らわしいです！
最新のDockerリリース（ v17.09 ）のドキュメントとv17.06リリースドキュメントを読むと、この機能が利用できるはずです。

$ head -n1 docker-compose.yml
version: '3'

しかし、 compose upは

ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.admin_application: 'extends'

extendsキーワードを使用する場合。
また、 composeログでextendsの削除について何も見つかりません。

さて、どっち？！
このような重要な情報を見つけたり、githubのあいまいな問題の中に隠したりするのは難しいことではありません。

$ docker --version
Docker version 17.09.0-ce, build afdb6d4

$ docker-compose --version
docker-compose version 1.16.1, build 6d1ac21

@jottr 、ドキュメントを参照してください：

extendsキーワードは、Composeファイルバージョン2.1までの以前のComposeファイル形式でサポートされています（v1のextendsおよびv2のextendsを参照）が、Composeバージョン3.xではサポートされていません。

したがって、 extendsを使用する場合は、 version: '2.1'に固執する必要があります。

私の悪い。 それはまだドキュメントの上部にあり、赤い非推奨の警告サインが付いているはずです。

私の悪い。 それはまだドキュメントの上部にあり、赤い非推奨の警告サインが付いているはずです。

@jottr Githubを使用して、そのための別の問題を作成したり、そのためのPRを作成したりするだけです。 問題階層を作成しました： https ：

私の場合、次のようにdocker-compose-override.ymlがあります。
yaml version: "3.4" services: common: extra_hosts: - "host1:172.28.5.1" - "host2172.28.5.2" - "host3:172.28.5.3" networks: default: external: name: "common-network"
そして、ネットワークとextra_hostsを共有する必要がある他のいくつかのdocker-compose.ymlファイルがあります。 拡張機能なしでこれを行う方法は？

yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" hostname: "mongo" volumes: - "/opt/docker/mongo/default.conf:/usr/local/etc/mongo/mongod.conf" - /opt/data/mongo:/data/db" ports: - "27017:27017" command: "mongod --config /usr/local/etc/mongo/mongod.conf" networks: default: ipv4_address: "172.28.5.4"
docker-composeでサポートされているyamlアンカーと異なるファイル間の参照があれば素晴らしいと思います。 たぶん、ファイルをマージした後にアンカーと参照を適用します。
例えば：
yaml version: "3.4" services: common: &common extra_hosts: ... networks: ...
yaml version: "3.4" services: mongo: <<: *common image: "mongo" container_name: "mongo" ...
結果は次のようになります。
yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" extra_hosts: // EXTRA HOSTS HERE networks: ...

@ sandro-csimasこれは次の方法で可能です： https ：//docs.docker.com/compose/compose-file/#extension -fields
@ shin-このチケットを閉じることはできますか？

@rdxmbそうは思いません。 私が見ることができることから、あなたは別のdocker-composeファイルから拡張することはできません

これはhttps://github.com/docker/compose/issuesの問題だと思い

いくつかのデバッグ：

# cat docker-compose.yml 
version: "3.4"
services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

これは
docker stack deploy -c docker-compose.yml test

docker-composeを使用する場合：

# docker-compose up 
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./docker-compose.yml", line 4, column 10

ymlファイルを次のように変更します。

version: "3.4"

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR

docker-composeでも動作します。

したがって、これは複数のファイルでも機能するはずだと考えましたが、そうではありません。

# docker-compose -f compose-services.yml -f compose-default.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10
t# docker-compose -f compose-default.yml -f compose-services.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10

# cat compose-services.yml 
version: "3.4"

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

# cat compose-default.yml 
x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

ただし、もちろん、これをマージするには、 cat使用するだけです。

# cat compose-default.yml compose-services.yml > docker-compose.yml && docker-compose up -d
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.

Creating network "test_default" with the default driver
Creating test_foo-bar_1 ... 
Creating test_foo-not-bar_1 ... 
Creating test_foo-bar_1
Creating test_foo-bar_1 ... done

バージョンでxenialで実行：

# docker --version
Docker version 17.11.0-ce, build 1caf76c
# docker-compose --version
docker-compose version 1.17.0, build ac53b73

@rdxmb 、ありがとう！
したがって、「cat」コマンドを使用して作成ファイルをマージし、最終ファイルを実行する必要があります。

また、これを行うためにdocker-compose configを使用します。 環境固有の設定の例：

これはCIパイプラインによって実行されます： docker-compose -f docker-compose.yml -f docker-compose.override.prod.yml config > docker-compose.prod.ymlそしてdocker stack deploy -c .\docker-compose.prod.yml my-stackを使用します

これに投票してください。extendsはv3で非常に役立ちます。

v2でよく使用しましたが、非常に便利です。
+1

v3でextendsサポートが見たいです。 それは私のdocker-compose.ymlファイルを大いに乾かすのに役立ちます。

この問題が提起されてからほぼ1年が経ち、多くの人々がこの機能を必要としていることは明らかです。 それでも、Docker開発者がこのリクエストに応答するのをまったく読んでおらず、リリース前にdocker-composev3に含まれていなかった理由の説明もありません。

新しいテクノロジーを信頼するお客様のために機能を伝達または維持することさえできない場合のソフトウェアの悲しい状態。

状況の考えられる解釈の1つ（および現在のスレッドの要約も）は次のようになります。

• YAMLアンカー/参照と3.4の拡張フィールドは、ほぼ同じことを実現します。
• マルチファイルを機能させることができます。 このスレッドの単純なcatと高度なアプローチを参照してください。 単純なアプローチのコメントは、docker-composeが最後に向かって複数のファイルをロードする問題を示しています（誰かがその問題を作成しましたか？）。 それがdocker-composeで修正された場合、ファイルをマージする必要すらありません。 したがって、私にとって、マルチファイルのサポートを希望する人は、 @ rdxmbが提案したように、 / compose / issuesで続行する必要があります。
• extends取り戻すことが検討され（ GitHubプロジェクトイベントを参照、Dockerチームからの透明性が高い、ありがとう！）、結果を「戦略的に重要な他のものがたくさんある」と解釈するかもしれませんが、可能です。まだextendsプルリクエストを書いてください。

私にとって、それは完全に理解できる視点です。

@aCandidMind同意しました。

IMHOは、 extendsによって提供されるよりシンプルでクリーンなメカニズムに複雑さを追加します。
私かもしれませんが、適度に複雑な拡張構成を拡張フィールドに移動すると、読み取りと保守がはるかに困難になります。
多くのコメントや投稿を読んだ後でも、extendsが削除された理由と、この機能の低下の利点は何であるかはまだわかりません。

少しのbashマジックで、自分で試すことができるようにテストリポジトリを作成することができます。

stack deployコマンドを次のように構成するだけです。

docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config) <stackname>

@ tylerbuchea-そのbash魔法の唯一の欠点は、 WARNING: Some services (<service-name(s)>) use the '<key>' key, which will be ignored. Compose does not support '<key>' configuration取得する可能性があることです。 これにより、混乱が生じる可能性があります。 しかしねえ、それは動作します👍

@dnmgnsあなたは正しいです！ それを指摘してくれてありがとう。 @joaoccが言ったように、ネイティブサポートに勝るものはありませんが、bash以外の依存関係がないことを考えると、上記のソリューションが私が見つけた最良のソリューションです。

@tylerbuchea 1つの汚い方法は、stderrを/ dev / nullにリダイレクトすることです:)
docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config 2> /dev/null) <stackname>

恥ずかしくないです😄

extendに関するこの混乱について、ドキュメントはより明確にすべきだと思います。
extendの説明は、ユーザーをアップグレード方法のドキュメントにリダイレクトします。アップグレード方法のドキュメントは、詳細についてextendの説明に戻ります。 これは十分に役に立ちません。ユーザーとして、この問題全体に対処する方法、私が持っているオプション、および考慮すべきことについての助けを期待します。 v3からextendを削除するという決定の背後には、明確なアイデアがあったと確信しています。

見る：
https://docs.docker.com/compose/extends/#extending -services
https://docs.docker.com/compose/compose-file/compose-versioning/#upgrading

@tylerbucheaの優れたワンライナーbashベースのソリューションに関しては、
残念ながら、いくつかの高度なDockerスタック機能をサポートしていません。

WARNING: Some services (web) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (web) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.

https://github.com/docker/cli/pull/569が18.03からマージされるため、 docker stack deployは複数の作成ファイルを1つにマージすることをサポートします。 これは、composefile形式v2のextendsキーを完全に置き換えるものではありませんが、より多くのユースケースをカバーしていることを願っています👼

私自身の回避策は、 yqを使用すること

yq merge --overwrite docker-stack.yml docker-stack.preprod.yml > merged-docker-stack.yml
docker stack deploy -c merged-docker-stack.yml preprod

@ Lucas-Cは、出力にdeploy configキーとdocker-compose -f docker/prod.yml -f docker/dev.yml configを実行すると、これを確認できます

これは、作成ファイルv3.4以降用です。 クロスyaml参照（部分的）をサポートします。 私はこのzshエイリアス/ perlスクリプトで終了しました：

alias regen=$'perl -MFile::Slurp=read_file -MYAML=Load,Dump -MHash::Merge::Simple=merge -E \'
  local $YAML::QuoteNumericStrings = 1;
  $n=read_file("/data/docker-compose.yml");
  $s=Dump(merge(map{Load($n.read_file($_))}@ARGV));
  local $/ = undef;
  $s =~ s/\\bno\\b/"no"/g;
  say $s;
  \' $(find /data -mindepth 2 -maxdepth 4 -name docker-compose.yml) >! /data/x-docker-compose.yml'
regen
export COMPOSE_FILE=/data/x-docker-compose.yml

1. 共通部分を使用して/data/docker-compose.ymlを読み取ります。
2. すべてのdockercomposeを再帰的に検索します（たとえば、このプロジェクトには約40の異なるcontainers / docker-compose.ymlファイルがあります）
3. 各docker-compose.ymlの前に/data/docker-compose.ymlコンテンツを追加します
4. マージ
5. 結果を/data/x-docker-compose.ymlに保存します

長所：perlは一般的なツールであり、すべてのperlモジュールも、生成が高速です。
短所：私はハックが嫌いですが、DRYの他の方法はありません。 最終的なdocker-composeは約900行です。 最初から1つのファイルとしてサポートしてほしいですか？ バイナリdockerをpythondocker-composeでperlhackでラップするのは残念です。

どうすればextendsのような機能を取り出すことができますか？ それはコア機能のようです。

使用してdocker-compose configの標準入力オプションにパイプdocker stack deploy -c -私のために問題を解決しました。

docker-compose -f docker-compose.yml \
               -f docker-compose.extended.yml \
               config \
| docker stack deploy -c - my-stack

私はこれを試していませんが、 docker stack deployドキュメントでもこれに気づきました。

基本構成や環境固有のオーバーライドなど、構成が複数の作成ファイルに分割されている場合は、複数の--compose-fileフラグを指定できます。

これを例として：

docker stack deploy --compose-file docker-compose.yml -f docker-compose.prod.yml vossibility

https://docs.docker.com/engine/reference/commandline/stack_deploy/#compose -file

extendsを削除する理由はどこかに文書化されていますか？ 公式ドキュメントでは説明されていないようです。例： https ：//docs.docker.com/compose/extends/#extending -services
ユーザーが論理的根拠を理解できれば、ユーザーは削除にどのように対応するかについてより良いアイデアを開発することができます。 ありがとう。

@ shaun-blake私は複数の作成ファイルを使用することになりました。 それが人々が使うアプローチのようです。 継承というよりは、ミックスインのようなものです。 ビルドまたは実行するときに、正しい環境yamlテンプレートをdocker-compose.override.ymlにコピーします。

複数のドッキングウィンドウには、ファイルを構成する（例： base.yml 、 local.yml 、 prod.yml ）他のファイルからのサービス利用YAMLアンカーを聞かせていないファクタリングサービス定義が複数のYMLファイルの中で定義することができませんでしたので、 。
注、この問題は、ほとんどのコメント13日である： https://github.com/moby/moby/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-descと第三最も好きでした。

ユーザーが論理的根拠を理解できれば、ユーザーは削除にどのように対応するかについてより良いアイデアを開発することができます。 ありがとう。

そもそもextendsを削除する理由に関するドキュメントの+1 ...

ほぼ1年半後もまだ_extends_はありません。 Cmon、devs、uは代替手段を与えずにsthを削除しません。

彼らはそうしました、彼らは作曲と呼ばれる代替案を提供します。 スレッドで私の答えを読んでください。

-フィリッポ

2018年7月30日には、9：41に、Xiaohui劉[email protected]は書きました：

ほぼ1年半後もまだ延長はありません。 Cmon、devs、uは代替手段を与えずにsthを削除しません。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/moby/moby/issues/31101#issuecomment-408790200で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/AAS_0AOynjpfVnVo4ZqciMbmjBmkcTQ3ks5uLsbN

@dedalozzo 、 "スレッド内" ==？

ここで私のコメントを見てください：

https://github.com/moby/moby/issues/31101#issuecomment -329527600 https://github.com/moby/moby/issues/31101#issuecomment-329527600

基本的に、.ymlファイルのチェーンを使用して、コンテナーの構成をオーバーライドまたは変更する必要があります。

「複数の作成ファイルの指定」をお読みください

複数の-f構成ファイルを指定できます。 複数のファイルを提供する場合、Composeはそれらを1つの構成に結合します。 Composeは、ファイルを指定した順序で構成をビルドします。 後続のファイルは、前のファイルをオーバーライドして追加します。

https://docs.docker.com/compose/reference/overview/ https://docs.docker.com/compose/reference/overview/

このアプローチでは、継承よりも合成を使用して、多かれ少なかれ同じ結果を取得します。

2018年7月30日には、午後3時23分で、セルバンTeodorescuの[email protected]は書きました：

@dedalozzo https://github.com/dedalozzo 、 "in the thread" ==？

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

組み合わせると同じ拡張性を取り戻すことができないでしょうか
yaml拡張フィールド（2.1 + / 3.4 +を構成）
それらのx-フィールドが他のファイルを

したがって、ルートincludeリストで、ロードするファイルを指定できるようにすることができます。
それらはx-includeに入れられ、標準のYAMLアンカーとマージを介して即座に使用できます。

# /docker-compose.yml
version: '2.1'

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

# /proxy/docker-compose.yml
version: '2.1'
services:
  proxy:
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '2.1'
services:
  app:
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /proxy/docker-compose.yml
version: '3.9'
services:
  proxy:
    &proxy
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '3.9'
services:
  app:
    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /docker-compose.yml
version: '3.9'
include:
  - /proxy/docker-compose.yml
  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    restart: 'always'
    << : *proxy
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    restart: 'no'
    extends:
      file: web1/docker-compose.yml
      service: app
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

@@ /proxy/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   proxy:
+    &proxy
     build: ./
     volumes:
       - /certs:/certs:ro
 ```

 ```diff
 @@ /webservice/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   app:
+    &app
     build:
       context: ./folder
       args:
         LINUX_VERSION: 20.s
         LINUX_FLAVOR: dash
     environment:
       - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
       - bootstrap.memory_lock=true
     ulimits:
       memlock:
         soft: -1
         hard: -1
 ```

 ```diff
 @@ /docker-compose.yml @@
-version: '2.1'
+version: '3.9'
+include:
+  - /proxy/docker-compose.yml
+  - /webservice/docker-compose.yml

 volumes:
   nginx_file_sockets:
     external: false
     driver: local

 services:
   reverse_proxy:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'always'
     ports:
       - "80:80"
       - "443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   reverse_proxy_test:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'no'
     ports:
       - "8080:80"
       - "8443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'always'
     environment:
       ENVIRONMENT: 'production'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web_staging:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'no'
     environment:
       ENVIRONMENT: 'staging'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx
 ```
<hr>
Resulting in the final version, which should be already yaml parsable:

```yml
# /docker-compose.yml
version: '3.9'
#include:
#  - /proxy/docker-compose.yml
#  - /webservice/docker-compose.yml
x-include:
  /proxy/docker-compose.yml:
    version: '3.9'
    services:
      proxy:
        &proxy
        build: ./
        volumes:
          - /certs:/certs:ro
  /webservice/docker-compose.yml:
    version: '3.9'
    services:
      app:
        &app
        build:
          context: ./folder
          args:
            LINUX_VERSION: 20.s
            LINUX_FLAVOR: dash
        environment:
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
          - bootstrap.memory_lock=true
        ulimits:
          memlock:
            soft: -1
            hard: -1

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

同じファイル内でパーツが繰り返されないようにするために、言語仕様自体に組み込まれているYAML機能であるAFAIK。 別のファイルを使用する場合、それは基本的に不可能です。

その機能をYAML仕様自体に提案する必要があります。

この議論は次のようになります。

• docker-compose -f file.ymlがdocker-compose -f file.yml -f file_extension.ymlよりもはるかに優れているのはなぜですか？
• または：コマンドレベルでの配線_vs_ファイルレベルでの配線。

コマンドラインで作業する場合にのみ、不便が顕著になります。 私たちはそれを少しの間認めなければなりません。 とにかく、他のすべてはスクリプト可能です。

それが本当の議論である場合、 docker-compose up serviceはdocker-compose -f service.yml upよりも優れたセマンティクスを持っています：ローカル開発（別名コマンドライン）に必要なすべてをdocker-compose.override.yml定義します。

与えられたセマンティクスは非常にクリーンでよく考え抜かれています。 コマンドラインでの使用にservice.ymlを採用することは、おそらくUXを下げることを意味します。 それには別の議論があります。一見すると明らかですが、 docker-compose.ymlとは何か、 service.ymlは何でも、実際には何でもかまいません。

免責事項：挑発的な意見。 ：wink：考えられるすべてのユースケースを考慮していませんでした...

この長期にわたる議論の後、それが成功するかどうかはわかりません。 IMHO、extendsはクールで、単に削除するのではなく、少なくとも慎重に非推奨にしてから議論したに違いありません。

私たちにできることの1つは、v2とv3のドキュメントストーリーを改善することだと思います。 多くの人がv3がv2に

v2： docker-composecliのみ。 単一のマシンとエンジンに焦点を当てた開発ワークフロー。 CIビルド/テストワークフローにも適しています。 このバージョンのブランチは、2017年12月にv17.12で新機能を受け取りました。

v3：マルチノードの概念を備えたSwarm / Kubeスタックに最適で、ほとんどのdocker-composecli機能のサポートを維持します。

SwarmまたはDockerEnterprise Kubernetesスタックを使用していない場合、 v3を使用する理由はありはヘルスチェック付きのdepends_onを含むすべてのdocker-compose cli機能を利用できます（待機スクリプトを回避するため）。

v3は、単一エンジンのdocker-composecliワールドとマルチノードクラスターワールドの機能をマージするために作成されました。 すべてのv2機能（depends_onなど）がクラスターで意味をなすわけではありません。 他の機能（extendなど）はv3に組み込まれていません。おそらく、v3が存在する前は、すべてのコードがdocker-compose Pythonであり、v3.0がSwarmをサポートするには、docker cliGoでそれを書き直す必要がありました。そして今、彼らはそれをエンジンデーモンに再び書き込んで、最終的にはまだ存在しないSwarmスタックAPIを作成しています。

この問題に不慣れな人のために、3.0リリース以降、さまざまな構成、テンプレート、およびチームワークフローの懸念を解決するために行われている作業の多くにも注意してください。

• この記事で簡単に説明する3つの機能（env変数、テンプレート、および構成スコープ）
• オーバーライドファイル、 docker -compose config 、および.envファイル
• docker-app実験的なテンプレートとパッケージングのCLI。 これをチェックしてください
• 今後のdocker-composeGUI（DockerCon 2018基調講演でのティーザー）

https://docs.docker.com/compose/extends/#extending -servicesのドキュメントでは、extendsキーワードがv3で削除されていることを赤で強調する必要があります。これは、単なる_note_よりも重要だからです。
ドキュメントを移行してスキミングし、機能しなくなった理由を確認してから、いくつかのクローズされた問題を追跡してからここに到達し、元のドキュメントに戻って文言に気づきました。

extendsキーワードは、Composeファイルバージョン2.1までの以前のComposeファイル形式でサポートされています（v1のextendsおよびv2のextendsを参照）が、Composeバージョン3.xではサポートされていません。

次のように言い換えることができます：

extendsキーワードは、Composeバージョン3.xで削除されましたが、Composeファイルバージョン2.1までの以前のComposeファイル形式で引き続きサポートされています（v1のextendsおよびv2のextendsを参照）。

これは小さな違いですが、ドキュメントをスキミングするときに見落としがちな違いです。

@krisrpPRが始まりました^^^

ありがとう@BretFisher

v2の名前を「version：docker-cli」に、v3の名前を「version：swarm / kube」に変更する予定はありますか？
他のほとんどのバージョン管理スキームでv3がv2に取って代わる方法を考えると、このように区別する方が理にかなっています。 現在、両方とも維持され、分岐しているので、私が間違えない限り、両方ともしばらくの間存在するようです。

@krisrp逆に、メジャーバージョン番号をインクリメントする理由は、互換性の相違を示すためです。

@ cpuguy83私は他のことを暗示していませんでした。 より明確または明確になっていないことをお詫びします。
IIRC Gnome 2＆3も、それぞれの独立したフォークが維持されていた数年前にこの混乱を経験しました。

バージョニング（駄洒落）のセマンティクスについて議論するためにこのスレッドを脱線させたくないので、そのままにしておきます。 先週のv2とv3のドキュメントの改善に関する

@ shin- @ cpuguy83 1年以上後にこの問題を見て、バージョン3に戻さない理由は何ですか？

「私たちはそれを別の方法で行うことができた」以外はそれについて多くを見つけることができませんでした（しかし実際のより良い解決策は提供されませんでした）
技術的限界はありますか？ それとも単にプルリクエストがないのですか？

結局のところ、私のcompose2.1ファイルはまだ正常に実行されています。

これだけでなく、変更ログには「これは削除されました。詳細については、「アップグレード方法」を参照してください」と記載されています。 アップグレード方法の詳細については「アップグレード方法」を見ており、「詳細については「サービスの拡張」を参照してください」と書かれています。 「拡張サービス」に移動すると、ファイルを拡張する方法がようやくわかりますが、「これは削除されました。詳細については、変更ログを参照してください」と表示されます。

この時点で、これはドキュメント作成者が演じている残酷な冗談のよ​​うです。

最終的に、「スタック」形式はここでは制御されず、DockerCLIの一部です。

個人的にはv3から除外された理由はわかりません...実際に誰かが追加しようとしているのを見たことがないと思います。
これをdocker / cliで表示するのが最善かもしれません...おそらく、機能がそこにあるかのように機能する高レベルのドキュメント変更を伴うPRでさえ、それについて話し合い、設計が承認されたら実装を追加できます。 。

基本的に、誰かがそれを望むなら、PRをしなさい。 拒否された場合に多くの時間を無駄にしないようにするために、ドキュメントを変更することをお勧めします...繰り返しますが、v3から省略された理由がわかりません。

同上。 docker-composeを再度使用する前に、これが解決されるのを待っています。

+1これを修正してください。拡張ベースのcomposeファイルがあり、composeをswarmに使用できないためです。

拡張機能の+1

これに関するニュースはありますか？

まだ待っています

こっちも一緒。 まだ待っている。

すべてのアップデート？

なぜ取り出されたのか、理由はありましたか？

2019年8月5日月曜日、11：10 Jaykishan、 notifications @ github.comは次のように書いています。

すべてのアップデート？

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/31101?email_source=notifications&email_token=ABOE6GA4CXY6ESMZMTDSFGDQC74CZA5CNFSM4DANZGS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABOE6GCEFFJ3SOLDWRWX2IDQC74CZANCNFSM4DANZGSQ
。

すべてのアップデート？

だから..それはほぼ3年です...
しかし、私はまだそれが着陸することを望んでいます：D

それが戻ってこない場合は、拡張するための何らかの代替手段が必要です。 抽象サービスを許可しないのはなぜですか？ ファイル形式はフラットで、すべてのサービス宣言が1つのファイルに含まれます。 （ &を介して）ノードのエイリアスを追加するyamlの機能と組み合わせて抽象サービスを使用すると、 <<:演算子を介してそれらのエイリアスを再利用できます。

なんで3年!! あなたは誰も気にしないことに集中して働いているようです

これに関する更新はありますか？

これは哀れです。 Terraformはコンポジションを使用します-それは実行可能です、なぜコンポジションはこの良いデザインプラクティスに従うことができないのですか？！
Terraformモジュールの構成
Terraformのベストプラクティス

「哀れな」、いいね。

@ Cristian-Malinescuどうぞ、実装してください。
これは無料のオープンソースソフトウェアです。

このチャットで他の人と同じように文句を言う代わりに。
それは、実際には、ここでは何の価値も追加しません。
何度か言ったように、これまで誰もこれを実装したくありませんでした、
だから、他の誰かがkを修正する必要があるのは問題です、ありがとう。

@luckydonald @ Cristian-Malinescuを簡単/受動的攻撃的な答えで

スレッドをスキミングし、サポートされているYAML機能を活用することが言及されています。

この例が役立つかもしれないと思った。

@nomasprimeその発見に感謝します！ 私は自分のプロジェクトでv2とv3のどちらかを決定していましたが、これによりこのスレッドの大きなジレンマが解決されました。 これらの代替ソリューションが拡張サービス機能の公式ドキュメントに記載されていないことに驚いた。

ドキュメントページの右側のナビゲーションバーにあるRequest docs changesリンクを使用する良い機会のようですね。

@nomasprimeうん、そのアイデアは以前このスレッドにあった。

それを他のymlファイルのファイル読み込みメカニズムと組み合わせることができれば、古いdepends機能をすべて持つために本当に必要なのはそれだけです。

上記を参照してください。例： https ：

あまり_読みやすい_ではありませんが、少なくとも_可能_です。

@nomasprimeその発見に感謝します！ 私は自分のプロジェクトでv2とv3のどちらかを決定していましたが、これによりこのスレッドの大きなジレンマが解決されました。

@arseniybanayev Mediumの記事には、v3についてのみ記載されていますが、 v2の新しいバージョンでは、swarmではなくdocker-composeを使用するため、v2（より具体的には2.4）を選択します（v3はコンテナメモリの制限などのv2の一部の機能をサポートしていません）

また、v3は、コンテナメモリの制限などのv2の一部の機能をサポートしていません。

v3はメモリの制限をサポートしていますが、フィールドはdeploy -> resources -> limitsますhttps://docs.docker.com/compose/compose-file/#resources

@thaJeztahつまり、 docker-compose （以前のコメントで参照していたプロジェクトで群れを使用していないため）。 IIRCの展開は群れのためだけですよね？

swarmとlocalに別々の設定をするのは理にかなっていますか？ これら2つは互いに競合しているようです。 当然のことながら、Dockerは群れの使用量を増やしたいと考えていますが、多くの人はローカル開発のためにcomposeのみを使用しています。

私は、ECS、k8s、またはGAEのいずれかを使用して、本番環境でスウォームおよび実行コンテナーを使用したことがありません。

ほとんどのオプションは、swarm / kubernetesサービスと、composeを介してデプロイされたコンテナーの両方で翻訳可能/使用可能である必要があります。 memory制限がdocker-compose適用されない理由を確認する必要があります

まだ拡張機能がありませんが、私の主なユースケースでは、 COMPOSE_FILE環境を介して複数のDocker作成ファイルに切り替えました。 私は主に、異なるパスワードまたは構成でdevとprodに同じベースdocker-compose.ymlを使用するために使用します。

例：

• 開発時： export COMPOSE_FILE= docker-compose.yml`＃デフォルト
• 製品上： export COMPOSE_FILE= docker-compose。 yml： docker

docker-compose.prod.ymlでは、env変数をprodパスワードで上書きするだけです。

この設定は簡単で、 docker-composeコマンドに常に複数の「-f」を追加する必要はありません。 devコンピューターとサーバーでCOMPOSE_FILE env varを設定する必要があり、gitはdocker-compose.prod.ymlファイルを無視します。

まだ待っている ：）

私はこれを拡張する方法として使用してきました：

docker-compose \
  -f ./docker/base.yml \
  -f ./docker/extended.yml \
  up

ただし、ファイル内で拡張する方が適切であり、追加のbashスクリプトは必要ありません。

また、これを使用して、bashスクリプトから動的に拡張しています。

extended_docker_compose="
  version: '3.5'
  services:
    my-service:
      restart: always
"

echo "$extended_docker_compose" | docker-compose \
  -f ./docker/base.yml \
  -f /dev/stdin \
  up

@ dave-dmこれらは単純な古いオーバーライドです！

これはextendsの潜在的な有効なユースケースだと思います

https://github.com/NerdsvilleCEO/devtools/blob/master/doctl/docker-compose.yml#L10

サービスの環境に使用するdocker-composeラッパーがありますhttps://github.com/nowakowskir/docker-compose-wrapper

編集：別の可能なユースケースは、誰かがLAMP / LEMPスタックを持っていて、ワードプレスなどの特定のサービスで使用するためにそれらのサービスを拡張したい場合です。

Dockerは代替案を作成している間、2017年からまだ待っています。

@nomasprimeうん、そのアイデアは以前このスレッドにあった。

それを他のymlファイルのファイル読み込みメカニズムと組み合わせることができれば、古いdepends機能をすべて持つために本当に必要なのはそれだけです。

上記を参照してください。例： ＃31101（コメント）

あまり_読みやすい_ではありませんが、少なくとも_可能_です。

@luckydonald指摘してくれてありがとう。 奇妙なことに、組み込みのYAMLインクルード機能はなく、確かに多くの問題を解決します。

サードパーティのソリューションを実装するのはかなり簡単なようですが、なぜこれがv3に導入されていないのかわかりません🤷‍♂

多くの人がこの機能を望んでいることを少し思い出させてください:)

それをv3btwに移植しない理由は何ですか？

忘れてしまいましたが、実際に持ち去られた理由はありますか？

2020年5月6日水曜日、23：14 Julien Marechal、 notifications @ github.comは次のように書いています。

多くの人がこの機能を望んでいることを少し思い出させてください:)

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

yamlアンカーがこのユースケースを処理する方法は、 extendと比較して少し不便です。 私の意見では、その力は主に要素の再帰的なマージから来ました。 アンカーは、おそらく75％の道のりをたどります。つまり、yamlを再帰的にマージすることはありません。 すべてのマージはトップレベルで行われます。 アンカーされたサービステンプレートを参照してからenvironmentブロックを再定義すると、マージされるのではなく、アンカーされたサービスの環境ブロックが上書きされます。 extendキーワードの動作に一致させるには、辞書の再帰ツリーの下にあるすべての辞書をアンカーして参照する必要があります。

例：

# anchors for the service, environment, deploy, and deploy.placement blocks
# you'll need an anchor for every dict that you want to merge into
x-common-app: &common-app
  image: app:1.0
  environment: &common-app-environment
    common_option: a
    overwrite_option: b
  deploy: &common-app-deploy
    max-replicas-per-host: 3
    placement: &common-app-deploy-placement
      constraints:
        - 'node.labels.app_host==true'

services:
  myapp: << *common-app
    environment: << *common-app-environment
      foo: bar
      baz: xyzzy
      overwrite_option: quz
    deploy: << *common-app-deploy
      replicas: 15
      placement: << *common-app-deploy-placement
        preferences:
          - spread: node.labels.region

# The above yields the following:
services:
  myapp:
    image: app:1.0
    environment:
      common_option: a
      overwrite_option: quz
      foo: bar
      baz: xyzzy
    deploy:
      replicas: 15
      max-replicas-per-host: 3
      placement:
        constraints:
          - 'node.labels.app_host==true'
        preferences:
          - spread: node.labels.region

この例ではそれほど煩わしく見えないかもしれませんが、1つの拡張ブロックから複数（10以上）のサービスをテンプレート化すると、煩わしく読みにくくなります。

私の考えでは、理想的なシナリオは、yamlアンカーアプローチとextendアプローチの組み合わせです。 extendは、最上位のx-プレフィックス付き拡張フィールドブロックからのみ許可されます。よりスマートなマージ特性。

私の組織では、yamlアンカーが構文的に少しずさんなことがわかったので、基本的に外部のpythonスクリプトでextend機能を再実装しました。 それは私たちにとってはうまくいきますが、何かに対処しなければならないのは不完全な方法です。 同様に、v3 / Swarmスタックのdepends_onの削除に対処するために、独自の外部ツールを作成する必要がありました。

最近、多くのgitlab CIYAMLを実行しました。 まさにこれらの機能を備えており、読みやすく管理しやすいテンプレートと最終構成を実現するのに非常に便利です。

• 他のYAMLファイルを含めることができます（テンプレートに適しています）
• 拡張でき
• また、本物と見なされないように「隠す」こともできます。 作成形式ではx-が、gitlab CIでは最初の.です。

これは、これらのファイルを耐えられるものにする機能の正確なセットです。

私はdockerdocsからこの問題に到達しました。私の場合、 docker-composeセットアップをテンプレート化したいと思い、「回避策」として上記のアドバイスに従い、既存のテンプレートプログラムを探すことにしました。 私はそれらの時間を取り戻すことができないので、この実際の機能要求に関する議論に関係なく、ここで見つけたものの少しを詳しく説明しますが、関係者はYAMLベースのテンプレートシステムの使用を感じるかもしれませんこの機能をdocker-compose自体に統合するのではなく、作成ファイルを生成する方が、カプセル化とジョブに適したツールの選択の観点から適切な場合があります。

いくつかのコンテキストでは、Let's Encryptといくつかのアプリケーションコンテナ（今のところNextcloud、1つは私用、いくつかは友人用）で基本的なリバースプロキシを使用しています-この場合、Nextcloudコンテナのテンプレートを作成したかったので非常によく似た設定のキーストロークでの間違いや重複を避けることができます。 次のパッケージは私が試したものでした：

• ytt
• ダール
• 合図
• Jsonnet

yttは非常に包括的であり、YAMLをネイティブに使用する唯一のオプションです。 これは強力で仕事に適したツールのようで、PythonのスーパーセットであるStarlarkをYAMLファイル内で直接使用して処理を実行します。 しかし、間もなく、テンプレートは非常に乱雑になり、コードのフラグメントとYAMLのフラグメントが散らばり、辞書や配列などのPythonデータ型とYAMLフラグメント（テキストのように処理されるように見えます）が混在しています。文字列などのタグを出力するHTMLテンプレートエンジン）は、最終的にエラーが多すぎてファイルが乱雑になりすぎました。 Dhallも非常に包括的で、さまざまな形式に出力できる独自の母国語を使用しています。 テンプレートシステムというよりはメタプログラミング言語のように見えますが、構文が機能し、かなり厳密に型指定されているため、非構造化YAMLの単純なテンプレートよりもすぐに複雑になりました。 JSONとHaskellのブレンドのように見えるので、私が必要なことを言語に組み込むには、あまりにも多くの考えが必要でした。

興味深いことに、Dhallとyttの両方で困難だったのは、パラメーター化されたフィールド名を使用することでした。どちらもそうでなければ十分に機能しましたが、インスタンスの名前をサービス名とボリューム名に表示する必要があります。これはやや醜いものでした。 ハッシュ内の値に引数を使用するのは簡単ですが、キーの名前にこれらの引数を使用するのは面倒であるか、それを適切に行う方法が見つかりませんでした。さらに、Dhallは型の安全性を強制し、これは単にその概念に反します。 Jsonnetでは、式を角かっこで囲むだけで簡単にできました。

CUEとJsonnetはどちらもJSON指向ですが、コンバーターを介してこれらを実行することはまったく難しくありません。また、Dhallのように、CUEには多くの強力な機能があり、Jsonnetの欠点から生まれたようですが、ドキュメントの一部に含まれています。 、それはすでにやり過ぎであることが明らかになりました。 おそらくそれを適切に学ぶためにもっと多くの時間があれば、それは優れたオプションでしょうが、CUEは単純なテンプレートジョブよりも検証とスキーマに重点を置いているようです。

最後に、これらすべてを完了して初めて、これらのツールをLiquidタグまたは同様のHTMLテンプレートの単純さと比較している間ずっと、Liquidを最初に使用できたのではないかと気づきました。 私はJekyllサイトのコンテキストでのみ使用したので、スタンドアロンパッケージを入手することは決してありませんでしたが、基本的なループとリスト、および式をインプレーステキストに直接評価する機能を備えているため、おそらく仕事にとってもはるかに良かった。 JsonifyはおそらくJSONに優れていますが、Liquidは純粋なYAMLで動作する可能性があるため、ファイルは再び読みやすくなります。

+1 docker-composeは、このチケットが多数のテスト環境のk8への移行をサポートするために作成されて以来、私が職場で実装したオーダーメイドのソリューションの背後にある1つのインスピレーションでした。 私はベルやホイッスルを避けるように非常に注意しましたが、類似の機能をすぐに正当化しました。 哲学的な議論（構成と継承など）は、私には常識からの気晴らしのように見えます（利益の後知恵があります-ほぼ3年後もまだ解決されていません）。 明らかに、docker-composeを使い続ける可能性のある人々が必要としています。

+1：+1：

以前、 dev / test / ci環境でこの機能を頻繁に使用しました。この環境では、 ./config/{dev,test,ci}/compose.yamlサブディレクトリパスにある作成ファイルから拡張できました。 COMPOSE_ENV=devを持つ.envがありますが、開発者はオーバーライドでき、明らかにciオーバーライドします。

この機能を廃止し、同様のことを実行できるものに置き換えないことにショックを受けました。 たぶん、jinja2を使用して、やりたいことを実行できるようにするだけです。 Docker-Composeのアンチドライが少なくなることを願っています。 ： '（

extendsはv1.27（https://github.com/docker/compose/pull/7588）以降docker-composeサポートされているようです。

この機能を多用するユースケースの1つは、Dockerイメージをバージョン管理してコード化することです。 私のdockerdevファイルとprod作成ファイルはどちらもdocker-images.ymlから拡張されており、基本的なサービスとサービスのイメージのタグ付きバージョンのみがリストされています。

v3ではこれに対する簡単な回避策は見つかりませんでした。