Compose: yaml構成に `copy`を追加します

ここでcopyのセマンティクスは何ですか？ docker-composeが実行されているホストから、 docker cpを使用して、新しく実行されているコンテナーにファイルをコピーしていますか？

AFAIKこれを行う現在の方法は_ありません_：

見る：

`` `＃！bash
$ docker cp -h

使用法：docker cp [オプション] CONTAINER：PATH HOSTDIR |-

ファイル/フォルダーをコンテナーのPATHからホストのHOSTDIRにコピーします
コマンドを実行します。 '-'を使用して、データをtarファイルとしてSTDOUTに書き込みます。

--help = false印刷の使用法
`` `

ここでのコピーのセマンティクスは何ですか？ docker-composeが実行されているホストからdockercpを使用して、新しく実行されているコンテナーにファイルをコピーしていますか？

はい

AFAIKこれを行う現在の方法はありません：

docker cpコマンドがそれを実行できないことがわかります。 それでも、ホスト側のコンテナデータにアクセスすることで可能です（私は醜いです）

http://stackoverflow.com/a/24805696/210090

ええ、私はこれを行うことをまったく主張しません。 これにより、Dockerに関する多くのことや想定が破られます。 これは、使用されている基盤となるストレージドライバーにも大きく依存します。 Dockerは不可知論者であることが意図されています。 私たちはあなたの問題に対して別の解決策を_すべき_と思います:)

docker-1.8がdocker cpを介したコンテナーへのコピーのサポートを追加し、swarm-0.4.0-rc2がdocker cpサポートを追加したので、作成レベルでこの問題を再検討するのは素晴らしいことです。 ユースケースは次のとおりです（これは、現在_ほぼ_本番環境で実際に行っていることを反映しています）。

CIで構築されたイメージタグによって多くのコンテナーについて言及しているdocker-compose.ymlファイル（つまり、本番環境ではbuild:を使用していません。現在は使用できるかもしれませんが、過去のリリースではswarmではうまく機能しませんでした）たとえば、デプロイ環境に完全に一致するマッピングされた静的Hadoop構成ファイルが必要です。 現在、docker-compose.ymlが存在するディレクトリを、群れの_each_ターゲットdocker-machineの正確なパスに手動で同期する必要があります。 次に、 volume:行のスタックを追加します。

docker cpをサポートすると、システム展開方法でカスタム構成ファイルの同期を削除できるようになり、構成の変更がいつ挿入されるかをより適切に制御できるようになります（ volume:行に記載されているファイルを変更した人が影響を受けるため）以前にデプロイされたすべてのコンテナー（および内部実装が前述の構成を再読み取りするときはいつでも、おそらく次のコンテナーの再起動時、おそらくコンテナー内のさまざまなツールの起動時、予期しない可能性があります）および将来（予想される）。

OTOH、（上記で簡単に説明したように）多分build:を使用する必要があります。 ここでの欠点は、デプロイメントコンテナタイプごとに追加のDockerfileを作成する必要があることです。 1つはCIビルドイメージ用で、もう1つは静的構成ファイルインジェクター用です。 copy:への最近の変更に裏打ちされたコンでdocker cpきちんと私たちはすべて、この重複を避けるためにできるようになります。

それでも、ボリュームを使用する方がこれを行うためのより良い方法のようです。 ホストボリュームである必要はなく、データボリュームコンテナで動作する必要があります。

Bedies docker-machineはdocker-machine scpがありますが、これはマシンの準備で実行できます。 次に、 dockerまたはdocker-composeの通常の方法でホストボリュームを実行できます。

「それでも、ボリュームを使用する方がこれを行うためのより良い方法のようです。ホストボリュームである必要はなく、データボリュームコンテナで動作する必要があります。」
ターゲットが群れである場合、それがどのように最適であるかがわかりません。 AFAICS、データボリュームコンテナがすべての可能なスウォームノードに存在する必要があることを表現する方法はありません。

他のコンテナalaスケジューリング戦略と同じように、とにかく群れ自体を介してデータボリュームコンテナをノードにデプロイすることはできませんか？

「Bediesdocker-machineには、マシンの準備で実行できるdocker-machine scpがあります。その後、dockerまたはdocker-composeの通常の方法でホストボリュームを実行できます。」
私は現在これを行っています。 痛いです。 デプロイメントを管理する人々は、構成ファイルを移動するのを忘れています。 docker-compose ymlでサポートされている場合は、手動の手順なしでコンテナーが再作成されるたびに発生します。

「他のコンテナアラスケジューリング戦略と同じように、とにかく群れ自体を介してデータボリュームコンテナをノードにデプロイすることはできませんか？」
可能かもしれませんが、スケーリングの観点からはどうなるかわかりません。

「他のコンテナアラスケジューリング戦略と同じように、とにかく群れ自体を介してデータボリュームコンテナをノードにデプロイすることはできませんか？」
うーん、私の群れがサイズ10ノードであることがわかっている場合。 特定のDockerエンジンノードで重複を許可しないというポリシーを使用して、データボリュームコンテナーをサイズ10にスケーリングできますか？ 問題は（私が何かを見逃していない限り）、たとえば、そのデータボリュームを参照する必要があるコンテナには、一致するインデックスを持つコンテナから--volume-への方法がないことです。 皆さん、私はこの問題を2か月間見てきました。 私ができる最善のことは、 docker-machine scpを使用するスクリプトを作成することです。 ただし、構成ファイルを編集した後、 docker-compose up前に手動で行う手順です。 また、docker-compose.ymlのルートとして群れのターゲットマシンに正確なパスを書き込むことができる必要があります（つまり、大きなハックのようなにおいがします）。

おそらく、工場での私の努力は、Dockerマシンを起動し、「正しい」データをすぐに使用できる状態でclsuterを群がらせるこのプロセスを自動化するのに役立つでしょうか？ （_まだ開発の初期段階であり、 docker-machineとdocker-composeを1つのsetp_0に組み合わせるために使用しています。

copyは操作であり、サービス構成の一部ではないため、作成ファイルには属していません。

Docker 1.9は新しいボリュームAPIを追加しており、ボリュームドライバーはすでに含まれています。 ボリュームは、これをサポートするための本当に正しい方法です。 ファイルをコピーしようとしない。

提案をありがとう！ しかし、これは今のところ作曲のデザインに本当に合っているとは思いません。

コピーは操作であり、サービス構成の一部ではないため、作成ファイルには属しません。

構成ファイルだけをコピーしたい場合はどうなりますか？ （Dockerの群れに対して、volume_fromは機能しません）

私はまったく同じ状況にあり、カスタムmysql、nginx、haproxyなどの構成ファイルをコピーしたいのですが、本番環境にクラスターがあり、1つのcopyコマンドを使用して構成をローカルからリモートにコピーする代わりに

イメージを使用し、ビルドし、プルする必要がありますが、何も必要はなく、コマンドをコピーするだけで、展開と開発の時間を大幅に節約できます。

これは、これが簡単にスクリプト化できないことに問題がない人が増えていることを私は非常に驚いています。 Dockerについて間違っていると思いますか？ 私の解決策は、ansibleを使用して構成ファイルをホストにコピーし、ホストからそれを必要とするコンテナーにボリュームマウントすることだと思います。

同じ問題を打つ。 N個の異なるサービスにDockerfileを再利用していますが、独自のCOPYコマンドを使用してN個の異なるDockerfileを作成したり、そのためだけにボリュームを作成したりしたくありません。

ところで、私は現在、数十行のsedコマンドを実行することでそれを解決しています-http：//unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

おそらく最適なソリューションではありませんが、docker-composeがファイルのコピーをサポートしていないことを考慮すると機能します。

ところで、マウントとコピーはもちろん可能ですが、docker-composeの自動化のオファーに反します-すべてを手動で実行したい場合は、docker-composeを使用しませんか？

Dockerを深く掘り下げるほど、このツールの多くは「helloworld」に適しているように見えます/「\ shell \コマンド\ like \ this \ "でこのクールなものをどれだけ速くスピンアップできるか見てください単一マシンタイプのユースケース（docker-composeを含む）。 それをはるかに超えると、事態は非常に複雑になり始め、IMOは少し崩壊します。これは、従来のプロビジョニングツールが登場し、適切に使用すれば1日を節約できる場所です。

Dockerイメージを起動するために存在する必要のあるマシン固有のボリューム、ファイル、およびテンプレート化された構成ファイルがある場合、Ansibleを使用してべき等な方法でマシンをセットアップするのは非常に簡単であることがわかりました。 最後に、Ansibleを使用してdocker-compseを呼び出すか、構文がdockercomposeとほぼ同じでいくつかの優れたボーナス機能が追加されたAnsibledockerモジュールを使用することもできます。

結局のところ、上記のアプローチにより、すべてをスクリプト化し、べき等にし、最も重要なことにソース管理にチェックインすることができます。

@dnephin上記の一部の人々は、CPが構成の一部であるというユースケースを提案しました。CPは操作専用であり、構成用ではないという仮定を再検討することは理にかなっています。

簡単な例は、コンテナーを作成し、構成を正しい場所にコピーし、構成がコピーされたらコンテナーを開始することです。

これにより、実際の構成を埋め込まず、コンテナーの開始時にのみ構成をデプロイするイメージを作成できます。

間違いなく非常に役立ちます。 現在、postgresイメージをデータベースバックエンドとして使用していますが、 /docker-entrypoint-initdb.dフォルダー内のスクリプトを更新するためだけに、イメージを再構築したくありません。

機能が実装されるか、提案されたオプションを好む人は誰もいないので、人々が好む実行可能な解決策が見つかるまで、皆さんはこの問題を再度開いてみませんか？

@ctindelが述べたように、この問題は再度開く必要があります。

問題を再開してもらうための+1

オープニングも+1。

再開するには+1。

再開するには+1。

再開するには+1。

再開するには+1。

再開するには+1。

再開するには+1。

読み取り専用ボリュームの何が問題になっていますか？

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnautsはこれを見

👍再開のため

再開するには+1。

再開するには+1。

再開するための+1

再開するための+1

再開するための+1

再開するための+1

再開するための+1

再開するための+1

Composeでコピーを許可する理由は次のとおりです。

多数のコンテナで実行されているアプリケーションがあります。 議論のために、それらすべてがApacheを実行することを規定しましょう。 それらはすべて、「/ var / www / partX」のようなものを指すDocumentRoot定義を持っています。 DockerfileはApache構成の内容について何も認識せず、Composeは/ var / www / partXのボリューム参照を定義します。 コンテナの内容を変更せずにコードをデバッグおよび微調整できるため、これは開発に最適です。

摩擦は私が展開したいときです。 Dockerの主な魅力の1つは、独自のユニバースであるコンテナーをデプロイできることです。 コンテナー内のすべてを取得するには、ファイルをコピーする必要があります。つまり、開発に使用するものとは別のDockerfile定義とCompose定義を用意する必要があります。 大規模なプロジェクトでは、これは2セットの定義ファイルを維持する必要があることを意味し、エラーの可能性が高くなります。

私の好みは、Dockerfileの単一のセットを維持し、Composeファイルでオーケストレーションを行うことです。 作成は、/ var / www / partXを共有ボリュームとして設定するのか、ファイルをコンテナーにコピーするのかを定義する場所です。

共有ボリュームを使用して展開することは、ワームの缶のようです。 共有ボリュームに依存する本番環境の既存のバージョンを更新する場合、メンテナンスウィンドウを設定するか、共有ボリュームをバージョン管理するためのスキームを考え出すことなく、その共有ボリュームを更新することはできません。 私はコンテナーを外部ファイルと緊密に結合しており、そのような複雑さを導入する場合、Dockerを使用する利点の一部を否定しています。

Dockerfile定義への変更をスクリプト化してファイルを条件付きでコピーできるようですが、Dockerユニバース内のすべてのDockerロジックを処理するのはより「論理的」であり、Composeはそれを行う論理的な場所のようです。

再開するには+1。

+1。 Dockerfile代わりにdocker-compose.ymlファイルに構成ファイルをコピーすると非常に役立ちます。

+1。 サービスの構成ファイルを提供しようとして、それに遭遇しました。 読み取り専用ボリュームはオプションのように見えますが、むしろそれをコピーしたいと思います。

ボリュームをマウントするだけでうまくいく可能性があります。

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@ raszi-ええ、マウントされた構成は、今のところ進む方向です。 Dockerについて私が本当に気に入った点の1つは、外部の依存関係（リンクされた構成など）を気にせずに統合テストを実行できる自己完結型のコンテナーの概念でした。 青/緑またはA / Bのデプロイメントを行っていて、異なるバージョンのコンテナーで使用される構成に違いがある場合、状況は少し壊れやすくなる可能性があります。 各環境の共有ボリュームで構成ファイルをバージョン管理するなどの方法でこれを回避できますが、それはそれよりも複雑または脆弱に思えます。

「Dockerコンテナは、実行に必要なすべてのもの（コード、ランタイム、システムツール、システムライブラリなど、サーバーにインストールできる

私は同意します、この機能があれば素晴らしいと思います。 他の人を助けるために自分のソリューションを投稿しました。

再開するには+1。

+1

ボリュームのない再開または別のソリューションの場合は+1。

現在、docker-compose.ymlのEnvironment変数とdocker-entrypoint.shのj2を使用して、コンテナーのメインアプリを実行する前にそれらを構成ファイルに解析しています。 それはカスタム画像であり、すでに利用可能な完全な画像で箱から出して使用することはできませんが、私にとってはうまくいきます。

+1

+1

+1

+1

+1

+1

+1

+1

+1

再開するための+1

環境変数に基づく構成ではなく、コンテナーごとに異なるyamlファイルを持つ可能性を追加するには

+1非常に必要な機能

+1、機能があるのはうれしいです！

+1

+1

+1

+1

+1再開。 ブックマーク

+1これは非常に必要な機能です。

共有ボリュームをレイヤーとしてマークする方法があり、ボリュームはROのままで、書き込みは最上位のレイヤーに適用された場合、 copyディレクティブなしで幸せに暮らせるでしょう。 たとえば、抽出されたビルドアーティファクトを共有したいのですが、サービスはそのディレクトリ（ログやPIDファイルなど）に書き込みます。

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1非常に便利な機能なので、再開する場合

たぶんhttps://github.com/jwilder/dockerizeのテンプレート機能はあなたの何人かを助けることができます

+1

+1

+1

+1

+1

+1して問題を再開します

+1

Dockerシークレットを使用します。この例では、シークレットをnginxイメージとともに使用して、サーバー証明書と構成ファイルをコピーします。
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

それは良い点です。 正直なところ、私たちはすでに秘密を持っているので、コピーを持っている必要があるようです。秘密は、ある意味で、コピーする特定の種類のファイルにすぎないからです。 つまり、より慎重にプロビジョニングされたものであり、構成ファイルには必要ありません。

それはあなたが含めたいすべての構成ファイルのボリュームをマウントするホストを打ち負かします。

前に言ったように：

..。
ボリューム：
-./nginx/default.conf:/etc/nginx/conf.d/default。 conf：ro
-./nginx/nginx.conf:/etc/nginx/nginx。 conf：ro
..。

コピーの方が優れている理由は、a）ホストが実際には別々のマシンである群れの環境では、すべてのマシンの同じ場所にまったく同じファイルを置く必要はないはずです。 b）コピーは、作成が含まれるフォルダーに制限することもできますが、ホストマウントには絶対パスが必要です。 c）dockerのポイントは、含まれているアプリケーションがホストに侵入する場所の数を最小限に抑えることだと思います。 読み取り専用として設定してもホストのマウントは、持っていると、ファイルを保存するために、ホスト上の責任を作成します。 この単純な問題を解決するためにホストマウントを使用する必要はありません。

コピーはdocker buildプロセスと同様にモデル化できると思います。このプロセスでは、 Dockerfileは通常、ビルドコンテキストに送信する必要のあるすべてのファイルとともにgitリポジトリで出荷されます。 Dockerfileは、正しくシンボリックリンクされていても、ディレクトリ構造の外部に存在するものを送信することは許可されていません。 srcがdocker-compose.ymlのディレクトリ（およびその下のディレクトリ）に制限されているcomposeでも同様のことができます。 基本的に、ワークフローは次のようになります。 docker-composeがコンテナを作成し、 src:dstペアごとに、現在のディレクトリの下でsrc見つけて、未起動のコンテナにコピーします。次に、コンテナを起動します。

現在、ホストマウントを回避するには、 Dockerfilesを追加し、 confファイルを修正されたイメージにビルドすることで実現できますが、新しいイメージのタグを付け直したり、ユーザーを強制したりする必要があるため、これはやり過ぎのようです。より好ましい（IMO） image属性の代わりに、 docker-compose build属性を使用します。 すでにサービス定義でbuild属性を使用していて、このようにしたい場合は、composeに属するべきである、非常に意見の分かれる構成ファイルで、他の方法では不可知論的なイメージビルダーを汚染することを余儀なくされます。および展開プロセス。

docker-composeコピー機能の+1

+1

+1

+1

コピーの場合は+1。

docker-composeコピー機能の場合は+1。 上記の賛成論は説得力があると思います。

コピー用+1

コピーの場合は+1。

私のPOVにありますが。 便利になることもありますが、多くのユーザーにとって制御不能になったり悪用されたりする可能性があり、ボリュームが陳腐化することさえあります。 特に群れのためにファイルをコンテナに配置する必要がある場合は、設定またはシークレットを使用できます。 しかし、静的フォルダーをnginxコンテナーに配置するような私の場合、Dockerfileで多段階ビルドを使用して、静的フォルダーをコンテナーに配置する必要があります。これには、目標が達成されるまでに多くのプロセスが必要です。 ですから、コピーオプションを追加すると非常に便利だと思います

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

再開するための+1

+1

再開するための+1

コンテナー（またはそれ自体）が特定の状態に達した後にボリュームで動作する機能は機能しませんか？
読み取り専用のようなフラグである可能性がありますが、代わりにコピー専用です！ 次に、コンテナ内で同期状態に達した後にリンクを削除する機能が追加された、通常のボリューム操作パイプライン/構文があります...

再開するには+1。 ボリュームマウントは常にオプションであるとは限りません。 それが今日ここに投稿する理由です。 ボリュームのマウントが禁止されているという独特のシナリオのため、ファイルをコピーするために多数のコンテナーを手動で変更する必要があります。

+！

+1

docker-composeコピー機能の+1

+1

+1

これは無意味だと思い始めています。 Dockerは、Dockerを構築した特定のユースケースに関連する機能のみを追加します。これはユースケース外の機能の1つであるため、おそらく追加することはありません。

+1

@stuaxo多くの人がフットガンを求めているからと

この場合、サービスの実行に必要なファイルは、ビルドにベイクするか（Dockerfileで宣言）、ボリュームから利用できるようにするか、（ docker stack / Swarmモードの場合）構成として存在する必要があります。または秘密のオブジェクト。 実行時に複数の宛先にファイルをコピーするのは遅く、エラーが発生しやすく、障害に強いわけではありません。

乾杯、それが不機嫌そうに出くわした場合はお詫びします。
「サービスの実行」とは、Webサービスのように長時間実行されることを意味していると思いますが、Dockerはこれを十分にカバーしています。

Dockersの階層化とキャッシュは、他のことに便利です。

古いWordPressブログをdockerに入れましたが、実行するだけです。データをエクスポートしたり、投稿がどのように表示されているかを確認したりできるように、数分間実行することもあります。

これには、docker composeを使用してMySQLとApacheを分離するのに少し手間がかかりましたが、それらがすべて一緒にスムージングされているかどうかは気にしません。

Dockersのキャッシュは、Cairoのようなデスクトップライブラリの構築を試すときに楽しいものです。 私がやろうとしていたことのほとんどは、詳細を忘れてしまいましたが、サービスの実行とは関係なく、建物の側面にあります。

+ 1docker-composeコピーを追加する必要があります。 これにより、構成ファイルのフローとコンテナーの更新がはるかに簡単になります。

dockercpとdockerconfigを使用します

金、2018年3月2日に21時19分で、ジェームズ・ハーン[email protected]は書きました：

+ 1docker-composeコピーを追加する必要があります。 それははるかに簡単な流れを可能にします
構成ファイルとコンテナーの更新の

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

>>

ジェームズミルズ/プロロジック

E： [email protected]
W：prologic.shortcircuit.net.au

docker-composeコピーの場合は+1。 ここで説明コピーのみを使用するという考え方です。

+1

+1

この場合、サービスの実行に必要なファイルは、ビルドにベイクするか（Dockerfileで宣言）、ボリュームを介して利用できるようにするか、（docker stack / Swarmモードの場合）構成オブジェクトまたはシークレットオブジェクトとして存在する必要があります。 実行時に複数の宛先にファイルをコピーするのは遅く、エラーが発生しやすく、障害に強いわけではありません。

多くの場合、必要なのは単一の構成ファイルを更新することだけです。この場合、標準の公式イメージの独自のイメージをベイク処理することは悪い習慣であり、将来的に多くの技術的負債が発生します。ボリュームはX10を超えてしまい、そうしません。デフォルトの場所にある単一のファイルだけでなく、フォルダ全体を処理する必要があるという問題は言うまでもなく、ファイルの同期を維持する必要があります。また、構成設定を取得するだけでなく、システムファイルを更新する必要があります。

私はあなたの懸念を理解していますが、彼らの必要性が現実ではないことをみんなに伝えるだけで、人々をあなたのプロジェクトとそれを使用してあなたの仕事をサポートしたいコミュニティから遠ざけるだけです。 私たちはここであなたと協力して、うまくいく解決策を見つけたいと思っていますが、あなたが言いたいのは、私たちが必要だと思うものは必要ないということだけです。

うわー、これがまだ行われていないなんて信じられない。 この基本的な機能は、今ではdocker-composeにあると思いました。 ああ、OSSプロジェクトの美しさ...

docker-compose --force-recreate --rebuildで解決し、変更された場合（またはそう思われる場合）に新しいファイルをコピーします。 理想的ではありませんが、機能します。

+1

+1

+1

+1

+1これは私を狂わせる控えめなキーです。1つの構成ファイルのためだけにボリュームをマウントする必要があるのはばかげているようです。

+1

ボリュームを使用したdockercomposeを使用して、コンテナーにファイルを追加する方法があります。 作成ドキュメントにconfigs設定があることに気付いたので、単一のファイルを追加することもできます。

https://docs.docker.com/compose/compose-file/#configs

ただし、人々が望んでいるのは、ファイルをホストからコンテナ内のディレクトリにマージする方法であり、コピーが機能すると予想される方法であるoverwrite if existsを優先します。

作成ファイルのvolumes構成にnocopyオプションがあるのは不思議です。

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

これは次のように説明されています：
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

それで、それはまさに望ましいものを無効にしますか？

私が望むユースケースは、開発用のWebアプリケーションです。 提供するデフォルトのWebサイトを含め、Webサイトを提供するために必要なすべてのものを画像に含める必要がありますが、ファイルを配置する以外に、他の構成（キー）を使用せずに、これらのファイルをWebサイトの現在の作業状態とマージ/上書きするオプションがありますホスト上の適切な場所。 コンテナにコピーされたときに一時的なファイル。 ネットワーク共有にないことを意味します。

それから恩恵を受けるフレームワークの例は、Laravelのようなものです。 他の構成（ボリューム、ネットワーク共有など）なしでLaravelスプラッシュページを提供できるイメージを作成しますが、作成ファイルは、ファイルをホストからコンテナーのLaravelルートにコピーするように書き込まれます。上書きされます。

これにネットワーク共有を使用することは、一時的な環境の追加の維持です（開発は常に一定ではありません）。 Laravelのようなフレームワークでボリュームマウントを使用するには、そのボリュームにアプリをビルドする必要があります。つまり、ホストにPHPとcomposerをインストールするか、アプリが作成されるホスト上の場所を共有します。 どちらもより多くのメンテナンスを作成します。

編集：

テスト後、ボリュームをマウントすると、その場所のイメージに存在していたファイルが、ボリュームの元のコンテンツよりも優先して永続ボリュームにコピーされるようです。 つまり、上書きされません。

私は実際、これが望ましい結果の解決策だと思います。

ねえ、みんな、参考までに、問題は受け取った反応の数で並べ替えることができるので、「+ 1」コメントを追加するよりも、この問題のトップメッセージに親指を立てる反応を与える方が良いです。

+1

+1 Dockerチームにお願いします、あなたのコミュニティを考慮してください。

@ shin-現在の問題は、ボリューム機能により、単一の構成ファイルを外部ボリュームからコンテナーにプラグインできないことです。

そのフォルダーにある他のすべてを消滅させることなく、nginx構成ファイルを/etc/something/whatever.confにプラグインしたいとします。 単一のファイルに名前付きボリュームを作成することはできません（moby / moby＃30310を参照）。また、単一のファイルを含むディレクトリボリュームを作成してから、その特定のファイルをコンテナにマウントすることもできません（moby / moby＃を参照）。 32582）。

残された唯一のオプションは、実際のDockerホスト内の固定された場所を構成ファイルで汚染し、それらをバインドマウントすることです。もちろん、Dockerホスト間を移動したり、Dockerを操作したりする場合は、これはうまくいきません。ファイルシステムにアクセスできないホスト（オンラインCIなど）、または複数のスタックを並行して実行するだけのホスト。

ここで何かが道を譲る必要があります。Dockerのボリューム機能を変更して、実際に使用して構成ファイルをスタックに挿入できるようにするか、 copyようなものを使用してcomposeで回避する必要があります。

FWIW私はもはやComposeのメンテナではありませんが、そのユースケースは、Dockerfileを使用してビルド時に構成ファイルを挿入することによって最もよく提供されるように思われます。

@ shin-残念ながら、構成ファイルはビルド時に不明です。イメージは、どこに展開するのか、どの構成で展開するのかがわかるずっと前に、CIサーバーで準備されます。

私は@masaeeduとcomposeの機能が忍び寄らないようにするという概念的な理想を理解しているため、この機能を追加したくありませんが、実際には、この機能が失われると、composeを使用せずに使用できる状況が大幅に減少します。

A）問題のコンテナを立ち上げるために、ある種の恐ろしいスクリプトをまとめる必要があります（composeは、標準化を支援し、実行する必要がないようにすることを目的としていました）、

B）すべての構成を処理する他のツールを追加する必要があります（これは実行可能ですが、特定の.confと.envを各コンテナーにコピーするだけでよい中小規模のプロジェクトに大量のオーバーヘッドを追加します。イメージのビルド時に実行したくない、つまり、ソフトウェアに構成ファイルがあるのではなく、すべてのオプションをC ++にハードコーディングする必要があると言うのと同じです。これにより、数十の余分なイメージを維持する必要があります）、または

C）特定のソフトウェアの可能な構成ごとに個別のイメージを維持する必要があります。構成を少し変更する必要があるたびにカスタムイメージを作成します。これはどちらも現実の世界では機能しません。また、本番ソフトウェアに必要な種類の堅牢なQAおよびテストパイプラインを作成することも不可能になります。