ユースケースは何ですか？ 私が見た提案された使用法のほとんどはアンチパターンでした。

提供されたリンクをクリックすると、多くのユースケースのいくつかを見ることができます。 ご覧のとおり、多くのサブスクライバーは、「アンチパターン」ではなく、本当に便利な機能だと考えています。

おっと、もうコメントがまったくないので、「何か」が問題＃2105に起こったのがわかります...
おそらく私は間違ったリンクを提供しました...

そのため、いくつかの構成/初期化ファイルをコンテナーにコピーすると非常に便利です。 例として、dbコンテナ用の* .sqlのもの、apache / nginxコンテナ用のhtml / js / cssコンテンツ、またはjavaコンテナ用のjarファイルもあります。 これにより、ボリュームをマウントする場合のように、それが構成されたマシンだけでなく、「グローバルに」使用可能/実行可能になります。 主に、これはホストローカルファイルとコンテナに含まれるファイルの組み合わせになります。 実際、どのコンテナーも、構成や初期化なしでは役に立たないと見なすことができます。

これは正しいリンクです： https ：

+1

これにより、ボリュームをマウントする場合のように、それが構成されたマシンだけでなく、「グローバルに」利用可能/実行可能になります。

これに伴う問題は、コンテナが再作成されるたびに操作を繰り返す必要があるため、非常に近視眼的である（したがって「アンチパターン」という用語）ことです。 スケーリングが非常に悪いという事実は言うまでもありません（コンテナが10個ある場合はどうなりますか？20？100？）

問題の実際の解決策は、これらの必要なファイルをビルド（Dockerfile）に含め、更新が必要なときに再構築することです。

もちろん、すべての「共有」コンテンツをコンテナに含めて構成されている場合、10-20-100-コンテナのスケーリングははるかに簡単になります。 必要なのは、リポジトリからプルして、ノード固有の構成のみをマウント（はい、この場合はマウント）することです。 さらに、各ノードでdocker-composeを実行する必要はありません。
確かに、docker-composeをbuild：＆Dockerfileと組み合わせて使用​​できますが、状況は少し複雑になり、docker-composeのyaml構成ははるかに「エレガント」になります：o）

コピーが便利になる問題が発生しています（少なくともオーバーライドとして）。 私は主にMacで開発しているので、コンテナ内でrootとして実行され、マウントされたボリュームにエクスポートするコマンドで問題が発生することはほとんどありません。 ただし、最近、CentOで同じワークフローを使用すると、rootユーザーが所有するファイルがマウントされたボリュームを介してホストに追加されるため、大きな問題が発生しました。 このような場合、ホストファイルをマウントするのではなく、コンテナにコピーできるようにしたいと思います。

関連する問題：＃1532

更新

私の場合、DockerfileでCOPYを使用し、複数のdocker-composeファイルを使用することで回避できると思います。そのうちの1つはボリュームマウントを使用します。

使用事例：
コンテナ内の読み取り専用ファイルシステムのディレクトリを使用したい。 アプリケーションはそのディレクトリに新しいファイルを作成しますが、ファイルシステムは読み取り専用であるため、これによりエラーが発生します。

ファイルシステムが読み取り専用であるため、rwボリュームを使用できません。
効果は同じなので、roボリュームは使えません。

コンテナが実行されたときにのみ持続する書き込みを作成するのは素晴らしいことです。 ラッパー（https://stackoverflow.com/questions/36362233/can-a-dockerfile-extend-another-one）をCOPYファイルのみに作成できますが、これをvolumeと同様に作成します。

ユースケース：gitリポジトリのディレクトリに書き込む必要がある.gitlab-ci.ymlから複数のDockerコンテナを同時に開始します。

コンテナ内のプロセスが失敗した場合、またはコンテナがクリーンアップされる前にciジョブがキャンセルされた場合、権限がないため、残りのファイルをgitlab-runnerで削除できません。 これで、コンテナ内のファイルをボリュームから別のディレクトリにコピーできましたが、それはアンチパターンになりますね。

これはvolumes: - ./folder_on_host/ :/folder_in_container/とは異なりますか？
この方法で、作成ファイルでファイルをホストからコンテナ（COPYと同等）にコピーできます。

@harpratapあなたは正しいですが、欠点は/ folder_in_containerが存在してはならないか、空でなければならないことです。 エントリポイントとしてbashスクリプトがある場合は、/ some_empty_locationにボリュームを作成した後、ファイルを元の目的のディレクトリにシンボリックリンクすることでこれを回避できます。

COPY機能を持つための+1。 私たちのユースケースは、ローカル開発環境を迅速に立ち上げ、開発設定の構成をコピーするためのものです。

COPYの場合は+1。 これは本当に便利な機能です。

ユースケース：スウォームモードで、mysqlイメージを使用するサービスがあります。 MySQLが実行できるように、初期化スクリプトを/docker-entrypoint-initdb.d/にコピーする必要があります。

mysqlの上にイメージを作成することは可能ですが、ファイルをコピーして使用するか、mysqlに接続します
群れでタスクを実行してから手動でスクリプトを実行するのは、私の意見ではちょっと不必要です。

コピー/追加の場合は+1、

使用事例：
Fluentdでは、実行時に構成ファイルをコンテナーに移動する必要があります。 これらの構成ファイルは、Jenkins Engineによって実行時に作成され、dockercomposeにCOPY / ADDがないと失敗します。

コピーの場合は+1

多数のDockerマシン間で共有構成ファイルがあり、Dockerfileがdocker-composeディレクトリの下のそれぞれのサブディレクトリにあるとします。 その共有構成を各イメージにどのようにコピーしますか？ COPY failed: Forbidden path outside the build contextを取得せずに、Dockerfileコンテキストから../シンボリックリンクすることはできません

この例では、docker-compose buildを実行するときに、docker buildステップを実行する前に、docker-composeコンテキストから構成ファイルをコピーしたいと思います。

もちろん、誰かがクリーンな回避策を提案できれば幸いです。

これは機能があるといいですね！

+1だけでコメントしないでください-それはみんなの時間の無駄です。 提供する追加情報がある場合は、そうしてください; それ以外の場合は、元の問題に賛成するだけです。

_いくつかの_ケースで_最終的に_問題を引き起こす可能性があるという理由だけで、それがアンチパターンであると独断的に主張することの使用は何ですか？ これは、追加のフォルダーとファイルを作成してから、そこに追加するファイルを移動する代わりに、既存のファイルに1行を追加できるため、間違いなく有効です。 この無意味で官僚的な小さなファイルの作成は本当のアンチパターンであり、ユーザーがdocker-composeファイルをシンプルで保守しやすいものにすることを妨げています。

ユーザーがDockerで有害なことをしたい場合、ユーザーはあなたが何をしても方法を見つけるでしょう。 誰かがいつかそれらを誤用するかもしれないという理由だけで合法的な機能を追加することを拒否することは愚かです。

この場合、あなたがしていることは実際にはそれを実行する正しい方法だと思います。

ここで提起された問題は、mongo.confファイルが1つのdocker-composeファイルによって調整された3つのdockerイメージ間で共有されたと仮定するようなものでした。 各dockerbuildサブディレクトリで同じであることをどのように確認しますか？

たとえば、シンボリックリンクを使用する場合、dockerは、ファイルがビルド環境の外部にあると文句を言います。たとえば、dockerビルドは、そのディレクトリの外部で変更するとビルドが変更される可能性があるため、再現性に欠けます。

したがって、これを調整する唯一の方法は、ファイルコピーを使用することです。これは、現在、docker-composeを実行する前にMakefileまたはシェルスクリプトで行う必要があります。したがって、これがdocker-composeが実行できる機能であるかどうかを議論するアイデアのように見えました。確かにそれは一般的なユースケースです。

あなたが提起している問題は、ローカルファイル変更の実行時（起動時）の注入に関するもののようです。

私はあなたが実際にあなたがしていることに問題がないと思います、あなたが上で言ったことはまさにそれがどのように行われるかです。 Dockerイメージは、構成ディレクトリがどこにあるかなどの質問に答えるために環境変数を受け入れるように常に構築でき、その構成ディレクトリは実行時にボリュームを使用して「挿入」できますが、それはDockerイメージの設計次第です。環境変数とボリュームマッピング（dockerがランタイム構成の変更としてサポートする機能です）。

私はあなたのコメントを誤解していないこと、そして私の返事がお役に立てば幸いです。

@ jpz-どういうわけか元のコメントを削除しました

私の最初のコメントは次のようなものでした。

私のユースケースは、 /etc/mongod.confような構成ファイルをコピーするためだけに独自のカスタムイメージを作成することなく、 mongoを使用してサービスを宣言したいというものです。

更新： volumes 。 一年か二年前-私はこれを悪い経験で試したと思っていました...しかしそれは問題ないようです。

コピーの場合は+1

このための簡単な要点を作成しました。 Docker構成サービスの名前はphpfpmであると想定していますが、これは任意の名前に変更できます。 自由に変更してください。
https://gist.github.com/markoshust/15efb29aa5eebf8adae402af18b2e674

こんにちは、この問題の進捗状況を教えてください。 現在、docker-toolboxを備えたWindows 10Homeを使用しています。 マウントファイルをボリュームとしてコンテナにバインドしようとすると、ほとんどエラーのように見えます。 docker-composeにCOPY機能があると便利です

COPY / ADDは間違いなく歓迎すべき機能です。

ユースケース：開発目的でDockerでGraylogインスタンスを実行します。 入力を自動的に起動するには、JSON仕様を/ usr / share / Graylog / data / contentpacksに配置する必要があります
COPY / ADD機能を使用すると、YMLの1行と同じくらい簡単になります。

今すぐ（2018年10月16日に）機能させるには、そのポイントにボリュームをマウントし、そのフォルダーの元のコンテンツを永続ボリュームにコピーする必要があります。 静かに不便です。

私はそれから恩恵を受けるでしょう、私はデータベースシードをコンテナにインポートするツールのセットを持っていて、それから私はそのファイルに基づいてdevtoolsデータベースインポーターを実行します。 私はする必要はありません：

docker cp "${seed_file}" $(docker-compose ps -q devtools):/tmp/seed_file

シードをインポートできるようにします。 いいえ、固定スキーマを使用して開発イメージをコンパイルしません。これは、少なくともWeb開発パターンに反します。 コンテナは、データではなく、アプリの移植性のためのものである必要があります。

次のことを行う方が理にかなっています。

docker-compose cp "${seed_file}" devtools:/tmp/seed_file

全体として、基本的に同じことを行うのは速記ですが、何かを混ぜるよりも、どこでもdocker-composeを活用する方が良いようです...

1）これは＃3593の複製のようです
2）@ shin-に同意します-手の込んだユースケースはアンチパターンに従っている
3）しかし、Dockerのcpコマンドをまとめることは理にかなっています、imo

@funkyfutureこれらのユースケースがアンチパターンに従っていると思われる場合は、そうでない解決策を提案してください。

k8sのような「データセクション」はどうですか？
例えば：

services:
  service1:
    image: image.name
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2
      filename2.yml: |
        foo:
          bar: val1

またはおそらく同じですが、 volumes:セクション用です

volumes:
  service_config:
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2

services:
  service1:
    image: image.name
    volumes:
      - service_config:/service/config

@ shin-

これに伴う問題は、コンテナが再作成されるたびに操作を繰り返す必要があるため、非常に近視眼的である（したがって「アンチパターン」という用語）ことです。 スケーリングが非常に悪いという事実は言うまでもありません（コンテナが10個ある場合はどうなりますか？20？100？）

ここでの実際の問題は、実際のユースケースシナリオの限られたビジョンと矛盾するため、要求された機能をすぐに破棄できない人がいることです。

ここでは、dockerhubから取得したコンテナーに構成ファイルをコピーする方法を探しています。 元のDockerfileにアクセスできないので、この機能があると非常に便利です（上に別のレイヤーを構築しようとする代わりに、機能しますが、不便です。何かを変更したときに再構築したくありません）。

使用事例：

統合テスト環境でデータベースを実行し、コンテナーの開始時に反復ごとにデータをリセットしたいと考えています。 カスタムイメージへのデータの埋め込みは機能しますが、ボリュームのマウントは面倒です。ホスト上のデータをリセットする必要があるためです。

データは個別に管理されており、標準のデータベースイメージを使用するのが最も便利です。つまり、実行を開始する前にデータをコピーします。 現在、これはdocker-composeでは不可能のようです。

私はユースケースを念頭に置いています。 一般的なApacheサーバーなど、既成のイメージからイメージを作成したいと思います。 画像の作成中にHTMLをコピーしたい。 そうすれば、いつでもベースイメージを更新でき、copyディレクティブにより、コンテンツが新しいイメージに確実に含まれるようになります。

ところで、私は現在、docker-compose.yamlでdockerfilesとbuildディレクティブを使用してこれを行っています。 dockerファイルが必要ない場合は便利です。

@ tvedtorama-

使用事例：

統合テスト環境でデータベースを実行し、コンテナーの開始時に反復ごとにデータをリセットしたいと考えています。 カスタムイメージへのデータの埋め込みは機能しますが、ボリュームのマウントは面倒です。ホスト上のデータをリセットする必要があるためです。

データは個別に管理されており、標準のデータベースイメージを使用するのが最も便利です。つまり、実行を開始する前にデータをコピーします。 現在、これはdocker-composeでは不可能のようです。

この問題では、実行時ではなく、イメージのビルド時にファイルをコピーしたいという要望について説明します。 そのメリットについて話し合うために、別のチケットを発行することをお勧めしますか？ この議論を混乱させて、ランタイムファイルインジェクションの議論に移る可能性があります（私はあなたが話していることを解釈します）。

@ c0ze-

k8sのような「データセクション」はどうですか？
例えば：

..。

私はその構成が何をするかについて完全には理解していませんが、はい、それは解決策になるようです。 基本的に、シークレットがある場合（たとえば、データベースへのログインユーザー名/ pwd /ポートは何ですか）、コードを大量に記述せずに、Dockerイメージ（クライアントとサーバー）にそれを挿入するにはどうすればよいですか？

kubernetesデータセクションのようなものが機能する可能性があります-それは信頼できる唯一の情報源であるためです。 そうしないと、複数のDockerイメージ間で同じシークレットが複数回維持されていることに気付く場合があります。

そこには先行技術もあり、これが実際に採用する価値のある良いアイデアであるかどうかに合わせて会話を進めるのに役立ちます。

私にとって、これはすべて、コンテナー間で不変の構成ファイルを共有したいということから始まりました。外部でdocker-composeにスクリプトを作成し、信頼できる唯一の情報源からそれぞれに構成を書き込むことなしに、それを行う方法はないことに気づきました。 docker-composeフォルダーの下にあるDockerフォルダー。 もちろん、私はDockerの不変性の議論を取得します（たとえば、Dockerfileディレクトリはイメージの構築方法を完全かつ完全に説明します）ので、そのディレクトリに物事をコピーする自動化を求めることは、それらの原則に直面してわずかに飛ぶように見えます。

議論は、docker-composeがどれほど邪魔になるのかということだと思います。 これは、そのような自動化を正当化するのに十分な一般的なユースケースですか？ そうでない場合は、環境変数の受け渡しメカニズムに、信頼できる唯一の情報源から外部から秘密を注入する責任を負わせるように見えます（実行時など）。ここで私のポイントが十分に一貫していることを願っています。

これは私にとってあまり重要ではありませんが、ユースケースについて議論する価値があると思います。

それは私にとって非常に役に立ちます。 ウイルスソフトウェアは、Windows10がボリュームをコンテナーと共有する機能をブロックします。 それは巨大な組織であり、別の大陸で設定されたポリシーのためにそれらを変更することは初心者ではありません。

こんにちは、私のユースケース：私はオープンソースのPrometheus docker-composeセットアップを使用しています（リポジトリは他の人によって維持されています）。 コンテナにマウントされる構成があります。 問題：構成を適切にマウントできないため、リモートマシン（aws docker-machineやCI / CDランナー内など）でdocker-composeを実行できません。 この場合、それらをコピー/埋め込みしたいと思います。 RWデータの場合、ボリュームがあり、ROの場合-？

初期データを設定する可能性のあるROボリュームを持つことは他のオプションです。

現在の解決策：sshを介してdockerホストに接続し、リポジトリを複製/更新して、docker-composeupを実行します。 これは手動の場合には機能しますが、自動化には苦痛です:(

+1

ユースケース：データベースを実行する開発Dockerマシンがあり、それをセットアップするたびに、データベースの最近のダンプをインストールする必要があります。 事実上、それは次のことを意味します。

1. externからデータベースdockerイメージをプルします。
2. ZIPをコピーして実行中のイメージに抽出します。
3. ボリューム内でdb-restoreを実行します。
4. データベースダンプを削除します。

ここで大きな問題は、そのデータベースには多くの異なるダンプバージョンがあるため、ステップ2は開発者ごとに常に異なることです。したがって、各開発者が特定のダンプの場所/バージョンを持つ独自の作成ファイルを持っている場合が最も簡単です。 dockerに、作成中にその特定のファイルの場所でイメージをアセンブルさせます。これは、別のバージョンが必要な場合にオンザフライで変更することもできます。

私のユースケースは単純です。 ボリュームは必要ありませんし、自分のイメージをロールバックしたくありません。 構成ファイルの作成後、開始前に、構成ファイルの単純な防御コピーをコンテナーに入れたいだけです。

これはまだ問題ですか？
非常に長い設定ファイルを持つdjangoアプリケーションがあります。 私にとっては、Dockerイメージを作成し、単一の構成ファイルを各コンテナーにコピーする方がはるかに簡単です。
すべての設定をENVとして渡すことは、私にとってアンチパターンです。 多くのコードを必要とし、保守が難しく、1つのコピーコマンドで解決できます。

＃6643を開いて、アンチパターンと見なされる方法についてのフィードバックをお待ちしています。 特に、多数の構成ファイルをオンザフライで追加/変更する必要がある環境では。

@ shin-

これに伴う問題は、コンテナが再作成されるたびに操作を繰り返す必要があるため、非常に近視眼的である（したがって「アンチパターン」という用語）ことです。 スケーリングが非常に悪いという事実は言うまでもありません（コンテナが10個ある場合はどうなりますか？20？100？）

複数のコンテナでdocker-compose execはどのように機能しますか？

    --index=index     index of the container if there are multiple
                      instances of a service [default: 1]

cp同じ動作をしようとすべきではありませんか？

IMHO execは、 cpと同じくらい短命です。 とにかく、私はいつもそれを「開発」コマンドだと考えています。開発環境は一時的なものでなければなりませんね。

私はここで多くの開発者についてのコメントを見たことがありませんでした。彼らはこの機能を要求することによってこれをあまりにも早く修正しようとすることによって近視眼的であると言っています。 これは少し厳しくて見下すようなものだと思います。 私が長年の開発から学んだことが1つあるとすれば、それは次のとおりです。

それはあなたのソフトウェアがすることではありません、それは重要なのはユーザーがそれを使ってすることです

もちろん、あなたには物事がおかしくなるのを防ぐ役割があることは理解していますが、誰かがあなたのビジョンに基づいてツールを誤って使用しているからではなく、誰もがそのようにそれを始め、すべての地獄が解き放たれます。

私がここで見たすべての特別なケースは、ほとんどの場合非常に適切です。 そして、これらの特別なケースのほとんどは、本番システムでは発生しないはずです。たとえば、先ほど説明した私の場合のように、開発環境をカスタマイズして、使用できないコンテナーで特別なファイルを実行します。ボリュームマッピング。 ほとんどの例は、スキーマ、データ、または構成ファイルを焼き付けたくないこと、およびボリュームマッピングを使用できないことを明確に示しているため、「近視眼」という用語を使用するほど不便である理由がわかりません。

そのようなことを言うときは、慎重に言葉に重みを付ける必要があると思います...

1. 何を言ったり書いたりすることが許されているかについての講義は本当に必要ありません。 「近視眼的」があなたを怒らせてすみません。 これらのものは設計上Dockerfileに属していると言っても間違いありません。
2. 私はもうメンテナーではありません。 私がもはや制御できないことについて私に@-するのをやめてください。

1. 私はここでcrazycodrの側にいると言わなければなりません...実用的で現実的な代替手段を提供せずに、完全に有効な現実世界のユースケースを「アンチパターン」として却下することは、開発者にとって不親切なアプローチであり、正直なところ少し失礼です。
2. メンテナーであろうとなかろうと、githubのディスカッション部分に参加したことがある場合は、基本的に、コメントにコメントしている人々と一緒に暮らす必要があります。 それがまさにその仕組みです。 それに対処する...

持ち帰りましょう。 ここで正直な技術的な質問。 Dockerスタックには、「configs」オプションがあります。 これはネイティブのDocker機能ですが、コンテナーではなくサービス用です。 そのようなものをサービスレベルではなくコンテナレベルで機能させることの実行可能性は何ですか？ Dockerスタックはどのように構成プロビジョニングを実装しますか？ その実装をdocker-compose用に複製できますか？

ここで説明するユースケースの少なくとも半分は構成に関するものであるため、そのかゆみだけを傷つければ多くの人が満足するでしょう。

もう1つの簡単な使用例は、Googleドメイン検証などです。 ワードプレスの画像を使用している場合、Googleがチェックするファイルを追加することはできません。 それを行うには、まったく新しいイメージを作成する必要があります。

また、物事が「アンチパターン」であるというこれらのコメントは、ほとんど意味をなさない、エリート主義の悪臭。

編集：yikes、続きを読む、彼はもうメンテナではない神に感謝します

つまり、小さな構成ファイルをビルド済みのイメージ（たとえば、 nginxまたはmariadb ）にコピーする場合は、独自のイメージビルドセットアップを管理して複製する必要があると言っています。使用されているディスク容量（元のイメージと構成済みイメージ）？

これは機能であるはずです。

使用したディスク容量を複製する

Dockerを使用しているときではありません。

私はあなたが彼の言ったことから一つのことを選ぶ方法が好きです。それはそのすべての中で最もマイナーなことです。 これは機能である必要があります。 この問題は、一般的なユースケースであるため、Dockerが成長するにつれて人々がここに来るために成長し、成長します。人々は、常識のために存在することを期待します。これは、ここの元および現在のメンテナには欠けているようです。

私はあなたが彼の言ったことから一つのことを選ぶ方法が好きです。それはそのすべての中で最もマイナーなことです。

無効な引数はそのように注意する必要があります。

ここで重要なのは、特定のビジネス戦略が与えられれば、「アンチパターン」引数が有効になる可能性があるということです（ docker-compose代替を実装できるのは、@ shin-のdocker-pyでの過去の取り組みです。

どのような「アンチパターン」引数ですか？ 議論はありません。 それは、背後にロジックがなく、何もバックアップせずに言うだけの「いいえ、アンチパターン」です。 最悪のシナリオを頭の中で考え、そのシナリオはアンチパターンであると判断し、いわゆるアンチパターンシナリオについても書かずにすべてを却下したと言っているようなものです。

それはただのエリート主義です。 ここでの多くのコメントは、これを追加しない理由がいかにばかげているかについてであり、それらはすべて無視されています。

常識と論理はあなたの感情やエリート主義を気にしません。 または、作成したアンチパターン。

ええ、 @ robclancy 、それを市民のFFSにしてください。 この機能が欲しいのですが、メンテナにたわごとを話すだけの場合は、redditでベントしてください。 @funkyfutureの以前の修正は完全に保証されています。

結局、docker-composeの代替を実装できるのは@ shin-のdocker-pyでの過去の取り組みです。

私は明らかに、docker-composeのフォークを望んでいません。それがあなたが提案しているのであれば、特にそのような微細な機能強化のために。 これが起こる唯一の他の方法であり、それはコミュニティにとって悪いことです。

誰かがPRを提出した場合、それは実際に考慮されますか？ それとも、これはdocker-composeチームが受け入れないことを固く決めたものですか？ Dockerスタック構成と互換性のある構成セクションを追加することに沿った何かがあなたが検討するものでしょうか？

これは軌道から外れました...説明のない「アンチパターン」は、「アンチパターン」を非常に広い定義に変え、反論することは不可能です。 また、「アンチパターン」がどちら側にあるかについて明確な方向性もありません。 dockerまたはdocker-compose。

アンチパターン応答の明確な定義は素晴らしく、非常に高く評価されます。

コミュニティは成長を続けるため、確立された一連の定義が存在する必要があります。

これを使用して、Docker構成スタックで実行されているjenkinsパイプラインによって生成されたアーティファクトをコピーしたいと思います。 そして、コンテナ名はランダムにすることができるので、 docker cp使用することはできません。

今日私は使用しなければなりません

docker cp $(docker-compose -f docker-compose.development.ci.yml ps -q test):/app/tests_output ./tests_output

これはvolumes: - ./folder_on_host/ :/folder_in_container/とは異なりますか？
この方法で、作成ファイルでファイルをホストからコンテナ（COPYと同等）にコピーできます。

私は同じことをしようとしています。 csvファイルのあるフォルダーがあり、logstashに提供したいと思います。
どうやってやるの。 またはコンテナ内のどのフォルダですか？
現時点で私はこれを持っています：
./path/to/storage:/usr/share/logstash/ data：ro

どんな提案も役に立ちます

@ shin-このチケットは現在1。5年前のものです。 160人があなたが間違っているとあなたに言うとき-あなたはおそらくそうです。

これを実装する必要があることを納得させるために、他に何が必要ですか？

顧客の話を聞かない会社である@isapirは、すぐに廃業する傾向があります。 ですから、近い将来、本番環境に対応したDockerの代替案がいくつか見られるはずです。

@ shin-このチケットは現在1。5年前のものです。 160人があなたが間違っているとあなたに言うとき-あなたはおそらくそうです。

😆🤣💯🥇😲😮

また、

私はもうメンテナーではありません。 私がもはや制御できないことについて私に@-するのをやめてください。

@ sfuerteDocker -Composeに取って代わったKubernetesという名前の小さなプロジェクトがあります。 ユーザーのフィードバックに対する態度がもっと前向きだったら、それは起こっただろうかと思います。

彼らの流行語に対抗するための流行語が必要です。 彼らが対処できるのはそれだけです。

この機能は完全にpro-patternます。 それはそれをする必要があります。 違いは、私がその愚かなことをしたとしても、明らかに一般的なユースケースである方法でこれの利点を示すこの問題には多くのコメントがあるということです。 また、 anti-patternインスタンスは1つもありません。

@ shin-あなたは実際には根拠のないこのでたらめなアンチパターンのがらくたを始めたので、これでタグ付けされます。 だからあなたが引き起こした何かについて泣くのをやめなさい。

k楽しんで

私の場合は：

• 「開発」中にソースコードを「ボリューム」としてビルドして、開発中に自動的に更新されるようにしたい
• アプリをリリースする準備ができており、「デプロイ」する必要がある場合、ボリュームではなく、コピーしたファイルをコピーしたいと思います。

これを解決する最も簡単な方法は、開発用に1つの作成ファイルと本番用に1つの作成ファイルを用意することだと思います。

ここでの問題は、Dockerファイルで「ボリューム」を指定できるのに、Dockerファイルで「コピー」を指定できないことです。

私と同じケースの人はいますか？ 私は何かが足りませんか？

@ shin-これはアンチパターンですか？ この問題をどのように解決しますか？

@hems 、完璧な世界では、アプリケーションをスタンドアロンのDockerイメージとしてデプロイする必要があります。 したがって、アプリケーションを作成している場合、デプロイするソースコードはおそらくDockerfile一部である必要があるため、イメージにはアプリケーション全体が含まれます。 したがって、 Dockerfile 、ソースが/ var / wwwにある場合は、

COPY my-app-src /var/www

ソースは環境固有ではないため、Dockerイメージに属しているだけです。 簡単。

私たちのほとんどは、既存のイメージが特定のdocker-compose構成で適切に機能するように、環境固有の構成ファイルをコンテナーに含めたいと考えています。 そして、小さなファイル用のボリュームを作成したり、新しいイメージをローリングしたりせずに、これを実行できるようにしたいと考えています。

docker-composeチームの誰かが、これを真剣に公平に見て、最終的な評決（できればすべての未熟な人々を無視する評決）を描くことができますか？ この問題は永遠に開かれています。 結果は重要ですが、個人的には通知を受け取るのにうんざりしています。

COPY my-app-src /var/www

それが私が言っていることです。開発では、docker-composeファイルを使用してボリュームをイメージにマウントし、本番ビルドではファイルをイメージにコピーしたいので、ボリュームをコピーしてマウントできるはずだと思います。 docker-composeファイルを使用しているので、開発用に1つ、本番ビルド用に1つの作成ファイルを作成できます。

私はComposeを管理しているチームで働いており、この議論に飛び込むことができてうれしいです。 まず、DockerfilesとComposeファイルの責任をどのように見ているかについて概説します。

Dockerfilesはイメージを構築するためのレシピであり、サービスを機能させるために必要なすべてのバイナリ/その他のファイルを追加する必要があります。 これにはいくつかの例外があります：シークレット（つまり：資格情報）、構成（つまり：構成ファイル）、およびアプリケーション状態データ（例：データベースデータ）。 シークレットと設定は読み取り専用であることに注意してください。

作成ファイルは、一連のサービスがどのようにデプロイされ、相互作用するかを説明するために使用されます。 Compose形式は、単一のエンジン（つまり、 docker-compose ）だけでなく、SwarmやKubernetesなどのオーケストレーションされた環境でも使用されます。 Compose形式の目標は、アプリケーションを簡単に作成してローカルでテストし、ほとんどまたはまったく変更を加えずに、オーケストレーションされた環境にデプロイできるようにすることです。 この目標は、各環境がボリュームやデータストレージを処理する方法などの根本的な違いのために、フォーマットで変更できるものを制限します。

このようにDockerfileとComposeファイルの責任を削減することで、懸念事項を適切に分離できます。各コンテナーイメージの内容（Dockerfile）、サービスのデプロイ方法と相互作用（Composeファイル）。

次に、画像に保存するものの各例外について説明します。 秘密については、盗まれる可能性があり、時間の経過とともに変化する可能性があるため、これらを画像に焼き付けたくない場合があります。 Dockerシークレットは、これを解決するために使用されます。 これらは、デプロイする環境によって少し異なりますが、基本的には、実行時にコンテナー内のtmpfsディレクトリに読み取り専用でマウントされるファイルに資格情報を格納できるという考え方です。 このディレクトリは常に/run/secrets/なり、ファイルはシークレットの名前になることに注意してください。 シークレットは、Swarm、エンジンのみ（ docker-compose ）、およびKubernetesでサポートされています。

構成ファイルまたはブートストラップデータには、 DockerConfigsがあります。 これらはシークレットと同様に機能しますが、どこにでもマウントできます。 これらはSwarmとKubernetesでサポートされていますが、 docker-composeではサポートされていません。 これらのサポートを追加する必要があり、この問題にリストされているいくつかのユースケースに役立つと思います。

最後に、外部に保存する必要のあるアプリケーション状態データがあります。 この問題とは関係がないので、これについては詳しく説明しません。

そのフレーミングで、私はいくつかの質問に答えることができます：

• 作成フォーマットにcopyフィールドを追加しますか？ いいえ、組織化された環境では意味がないため、そうなるとは思いません。
• configsサポートをdocker-composeに追加しますか？ はい、そうすべきだと思います。
• docker-compose cpを追加しますか？ たぶん、これについてはまだわかりません。 これは基本的にdocker container cpエイリアスになります。

それを考えると、ここで使用できるツールがいくつかあります。

• ターゲットを使用してイメージにファイルを条件付きで追加できるマルチステージビルド。
• 実行時に資格情報をサービスに渡すことを可能にするシークレット。
• 実行時に構成情報をサービスに渡すことができる構成。

これらのツールは、このスレッドで発生したすべての問題を解決すると思います。

この糸はかなり加熱されています。 各GitHubハンドルの後ろには本物の生きている人がいて、おそらく彼らは最善を尽くそうとしていることを覚えておいてください（彼らの欲求不満が現れていても）。 私たちは皆、Composeに情熱を注いでおり、プロジェクトが引き続き繁栄することを望んでいます。

docker-compose cpを追加しますか？ たぶん、これについてはまだわかりません。

docker-compose execような便利な機能があると思います。

@ chris-croneすばらしい反応、ありがとう！

私は皆のために話すわけではないことを知っていますが、 configsサポートがここへの関心の大部分を満たしているという印象を受けます。 このために問題が開かれますか？

そして、いくつかの代替アプローチを提供してくれてありがとう。 私は今まで多段階ビルドについて知りませんでした。

configsサポートは、ここでの関心の大部分を満たしているという印象を受けます。

ここの大多数がSwarmを使用しておらず、 config機能がそれを必要としているのではないかと思うので、これは疑わしいです。

はい、現在Swarmが必要ですが、@ chris-croneのコメントから...

これらはSwarmとKubernetesでサポートされていますが、docker-composeではサポートされていません。 これらのサポートを追加する必要があり、この問題にリストされているいくつかのユースケースに役立つと思います。

...これはdocker-compose（sans Swarm）で実装できると読んでいます

Compose形式の目標は、アプリケーションを簡単に作成してローカルでテストし、ほとんどまたはまったく変更を加えずに、オーケストレーションされた環境にデプロイできるようにすることです。

複雑なアプリでは、オンザフライで調整する必要のある構成ファイルがかなりある場合があります。 今のところ、それを行う最も効率的な（時間とコストの面で）方法は、ボリュームキーを埋めることです（複数の構成をテストしている間、正気の人が別のイメージを作成することはないためです..お金を使うのが大好きな上司がいない限り開発時間）。

Swarmとconfigは、リストされているいくつかのユースケースに実際には答えません。 「関心の分離」も、composeがdockerで実行できることをすでに実行しているため、適用されませんが、単純化されています。 ラッパーは分離ではありません...もう少し拡張するようにお願いしています...

https://github.com/docker/compose/issues/6643

それでハックしてください..新しいキーの下のすべてのファイルが単一のボリュームに動的にリンクされ、それぞれの内部パスにマップされるボリューム機能を拡張します...

ここには完全に有効な2つのシナリオがあると思います。1つは約
開発環境。 人々はソースを使って柔軟な環境を作ります
それらの画像にマウントされたコード。 ソースコードは開発とともに進化します
発生し、イメージを常に再構築できないか、単に無駄にします
膨大な時間。 それはまさに私のシナリオであり、私はこれを見ることができます
シナリオは他の多くの人々に当てはまります。

2つ目は、ソースコードをベイク処理する本番イメージに関するものです。
（コンパイルされていないスクリプトを使用している場合）イメージに（および
それからまた、私はそうではありませんでした、私はまだそれを私の側に取り付けていました）またはあなたはただ
アプリケーションをコンパイルして、最終的なイメージにコピーします。 その時点で、
アプリケーションは非常にポータブルになります。

誰もがそれを理解していると思います！ 問題は、docker-composeを実行することです
開発者は時間をかけてケースを読み、ニーズを理解しましたか？ がある
理論上、ここにはアンチパターンはありません。必要があり、必要な開発者だけです。
尊重されるべきです。

私たちはdocker、docker-compose、そしてすべてのエコシステムが大好きです。
それを愛し、私たちがそれを使用しているので、あなたには仕事があります（少なくともあなたの何人かは支払われています
それのために私は願っています）。

過去数年間に私がここに持ち帰りたいことを学び、
以下があり、このシナリオに非常によく当てはまります。

重要なのはソフトウェアが行うことではなく、ユーザーが行うことです
重要なのは

乾杯と幸せな継続！
ᐧ

10：55の木、2019年6月6日には、jadon1979 [email protected]は書きました：

Compose形式の目標は、アプリケーションを簡単に作成できるようにすることです。
ローカルでテストしてから、次のようなオーケストレーションされた環境にデプロイします。
変更はほとんどまたはまったくありません。

複雑なアプリでは、必要な構成ファイルがかなりある場合があります
オンザフライで微調整します。 現在、最も効率的な（時間とコストの面で）方法
それを行うことは、ボリュームキーを埋めることです（正気の人が行かないため）
複数の構成をテストしながら別のイメージを作成するには..
彼らには、開発時間にお金を使うのが大好きな上司がいます）。

Swarmとconfigは、実際にはいくつかのユースケースに答えるつもりはありません
記載されています。 「関心の分離」も、すでに作成されているため適用されません
dockerでできることを実行しますが、単純化します。 ラッパーはそうではありません
分離...もう少し拡張するようにお願いしています...

6643 https://github.com/docker/compose/issues/6643

それでハッキーになります..下のすべてのファイルが下にあるボリューム機能を拡張します
新しいキーは、単一のボリュームに動的にリンクされ、それらにマップされます
それぞれの内部パス..

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

Docker Tomcat環境を起動して、 ROOT.warという名前ではない.warからアプリを実行したいと思います。 これを行うには、Tomcatのwebappsディレクトリにコピーし、名前をROOTに変更して、現在バインドされているポート8005/9で実行されるようにする必要があります。 「不正アクセス」に関するエラーを伴うポートの再バインドの問題が原因で、他のすべてが失敗します。 これらは一時的なテストビルドであるため、Dockerfileに入れることはできません。 これが私がdocker-compose欲しい理由です

@washtubs

すべての人に話しかけるわけではないことは知っていますが、構成のサポートがここでの関心の大部分を満たしているという印象を受けます。 このために問題が開かれますか？

これに関する問題がまだない場合は、問題を作成してここにリンクしてください。 プライベートチームトラッカーに何かを追加しました。

@washtubs @funkyfuture

...これはdocker-compose（sans Swarm）で実装できると読んでいます

私たちはすでに基本的な秘密のサポートを持っており、設定は同様の方法で実装できます。

間違いなく不足している機能。 唯一の「アンチパターン」は、dockerfileのエントリポイントスクリプトを変更したり、マウントファイルをコンテナにバインドしたりするなど、他の方法ではこれを行うのが難しいという事実を回避する必要がある場合です。

必要なのは、一度（できれば公式に）構築され、ユースケース、つまりdocker-composeで構成可能なコンテナーです。

Dockerの人々が気付いていないのは、「Dockerfile」がDockerの概念全体の中で最大のアンチパターンであるということです。特に、全体がまったく読み取れず、保守できないためです。 dockerに関係のある人が「アンチパターン」という言葉を知っているように投げ出すと、本当に笑わせてくれます。

Dockerfileは、実際には、ビルドスクリプト、またはパッケージマネージャーやmakeなどのビルド用に実際に設計されたものを使用した場合に利用できる通常のデバッグと整理を防ぎます。

私自身は、すべてのユースケースで同じDockerFileを使用して（パターンにしています！）、さまざまな使用法ごとにDockerFileを変更することを提案していますが、これは実際にはアンチパターンです。

そして、「configs support」はそれをまったくカットせず、必要のないところに構造を課します。

基本的な問題は、mountを/ etc / nginxとバインドする場合、構成を調整するスクリプトを実行できるようにするには、rwである必要があることです（別名envsubst）。 そして、これにより入力構成が変更されます（不変のままである必要があります）...構成全体に書き込むコンテナーよりもはるかに多くのアンチパターンが得られないため、再作成時にファイルをコンテナーにコピーするオプションが必要です。解決。

つまり、コンテナではバインドマウントディレクトリrwですが、ホストではroです。 真剣にこれを許可することはあなたを殺しますか？

間違いなく不足している機能。 唯一の「アンチパターン」は、dockerfileのエントリポイントスクリプトを変更したり、マウントファイルをコンテナにバインドしたりするなど、他の方法ではこれを行うのが難しいという事実を回避する必要がある場合です。

必要なのは、一度（できれば公式に）構築され、ユースケース、つまりdocker-composeで構成可能なコンテナーです。

Dockerの人々が気付いていないのは、「Dockerfile」がDockerの概念全体の中で最大のアンチパターンであるということです。特に、全体がまったく読み取れず、保守できないためです。 dockerに関係のある人が「アンチパターン」という言葉を知っているように投げ出すと、本当に笑わせてくれます。

Dockerfileは、実際には、ビルドスクリプト、またはパッケージマネージャーやmakeなどのビルド用に実際に設計されたものを使用した場合に利用できる通常のデバッグと整理を防ぎます。

私自身は、すべてのユースケースで同じDockerFileを使用して（パターンにしています！）、さまざまな使用法ごとにDockerFileを変更することを提案していますが、これは実際にはアンチパターンです。

そして、「configs support」はそれをまったくカットせず、必要のないところに構造を課します。

基本的な問題は、mountを/ etc / nginxとバインドする場合、構成を調整するスクリプトを実行できるようにするには、rwである必要があることです（別名envsubst）。 そして、これにより入力構成が変更されます（不変のままである必要があります）...構成全体に書き込むコンテナーよりもはるかに多くのアンチパターンが得られないため、再作成時にファイルをコンテナーにコピーするオプションが必要です。解決。

つまり、コンテナではバインドマウントディレクトリrwですが、ホストではroです。 真剣にこれを許可することはあなたを殺しますか？

このようなもの：

`` `

ファイルの場合は上書きします

ディレクトリの場合、宛先の内容を上書き/追加します

元の宛先構造を維持するためにソースからのコンテンツを使用

source：file ：p ermission：owner ：group

svc：
コピー：
-'。/ source / filename： / path /
-'。/ source / dir： / path /

＃または
svc：
コピー：
-ソース： './ source / file'
宛先： '/ destination'
許可：ro
所有者：所有者
グループ：グループ
-ソース： './ source / directory'
宛先： '/ destination'
許可：ro
所有者：所有者
グループ：group```

ユースケース：アプリケーションのdocker-composeファイルを含むオーケストレーションされていないコンテナソリューションがあります。 Gitリポジトリ内のSSL証明書などをVMにプルします。 次に、サービスを起動し、SSL証明書、構成ファイルなどをコンテナーのボリュームに移動します。 これは現在、COPYコマンドを備えたDockerfileが付属していない場合は不可能です。 クローンされたgitリポジトリ内のファイルをいじりたくありません。 アプリケーションがファイルを変更する場合は、毎回リポジトリをクリーンアップする必要があります。

@MartinMajewskiを使用すると、証明書をボリュームとして使用してディレクトリをマウントし、アプリケーション構成で指定できます。

ユースケース（および一度に質問する方法）：
postgresイメージがあり、開始時に1つの環境変数を設定します： POSTGRES_PASSWORD 。 DockerSecretで設定したい。 私がする必要があるのは、アタッチされたシークレットを実行中のコンテナーのenvvarにエクスポートする独自のentrypoint.shを配置することです。 起動時に、このエントリポイントを何らかの方法でコンテナに追加する必要があります。 2行のDockerbuildがないと–できません。 1つのファイルのコピー–実行できません。

PS postgresはその一例です。 _FILE envvarsをサポートしていないと仮定します。

内部追跡の問題https://docker.atlassian.net/browse/COMPOSE-89

ユースケース：Karaf
プロジェクトをビルドするたびに再構築したくないkarafベースイメージを使用して、アプリをすばやくデプロイし、ビルドごとにコンテナーを再構築できるようにしたいと考えています。 ただし、コンテナを起動するときに、_features.xml_と_jar_をデプロイディレクトリにコピーする必要があります。

これまでの私の解決策は、さらに別のDockerfile（overlayfsに依存しています。最終的にはオーバーレイが不足し、画像を手動で削除する必要があります）とavast / gradle-docker-compose-pluginのベースイメージとしてkarafイメージを使用することでした。 initコマンドは確かに環境変数として渡すことができますが、features.xmlの内容は渡すことができません。 コンテナ内の特定の場所にファイルとして保存する必要があります。 現在、これを行うにはボリュームバインドマウントのみを使用できます。 リモートマシンでそのボリュームにデータを取り込むにはどうすればよいですか？ ビルドスクリプトにはさらに多くのロジックが必要です（たとえば、org.hidetake.groovy.sshは、ビルドスクリプトを秘密のパスワード/キーロジックで複雑にします）。 docker-compose cpが使用可能な場合は、必要なcopyコマンドをdocker-compose.ymlに追加するだけで済みます。 avast / gradle-docker-compose-pluginは、追加のリモートファイルシステムアクセスロジックなしで、コンテナーのビルドとビルド出力からのファイルのコンテナーへの直接コピーを処理します。

このDockerfileは、スクリプトのdocker-compose.ymlビルド部分に追加されます。 どちらかといえば、これはアンチパターンです。ビルドごとにアップストリームのDockerイメージにオーバーレイを追加するだけだからです（イメージを手動で削除する必要があるまでは、ビルドが非常に遅くなります）。

FROM myregistry:443/docker/image/karaf-el7:latest

COPY karafinitcommands /usr/local/karaf/etc/

COPY features.xml \
     *.jar \
     /usr/local/karaf/deploy/

docker cpがランタイムコピーで正常に機能するのはイライラしますが、docker-composeには同等のメカニズムがありません。

ローカルディレクトリを/ usr / local / karaf / deployにバインドマウントし、そこにファイルをドロップするというアイデアだと思いました。 これを実現するために、イメージを再構築したり、Dockerファイルを使用したりする必要はないと思います。

ローカルディレクトリを/ usr / local / karaf / deployにバインドマウントし、そこにファイルをドロップするというアイデアだと思いました。 これを実現するために、イメージを再構築したり、Dockerファイルを使用したりする必要はないと思います。

それは確かにそのように達成可能です。 読み直して、これが純粋に便利な問題であることに注意してください。コンテナはgradleビルドによって再ビルドされます。次のロジック手順は、新しいビルドファイルを/ usr / local / karaf / deployにマウントされた「ローカルディレクトリ」に移動するにはどうすればよいですか。 私の場合、「ローカルディレクトリ」は、より正確には、ホストがリモートホストである「ホストディレクトリ」です。 そのため、ビルドスクリプトにrsyncなどを追加して、ファイルをそこに取得し、古いファイルが置き換えられ、余分なファイルが削除されていることを確認する必要があります。 docker-composecpが利用可能であれば不要です。 ポートフォワーディングを介してセットアップした既存のDockerクライアントからDockerデーモン接続を利用できます。

Dockerボリュームは、ビルドごとに削除できます。 マウントボリュームをバインドできません。 それらが空の場合にのみ再入力さ

この場合も、dockercpを使用してランタイム環境へのコピーを実行できます。 それはイライラする部分です。

ああ、わかりました。私は自分の設定に慣れすぎています。 私はhttp://github.com/keithy/groanを使用して、ビットとピースをリモートサーバーに自己展開するbashスクリプトを使用してから、dockerを呼び出します。

ユースケース：GoogleCloudのビルドとビルドアーティファクト

必要なアーティファクト：Webクライアント（自動生成）はgraphqlバインディングに反応します。 クライアントのコンパイルに必要なファイルを作成するには、サーバーを実行する必要があります。 クライアントイメージには、サーバーアドレスを指定してバインディングを作成するためのツールがあります。 したがって、バックグラウンドでサーバーイメージを起動し、サーバーを指すクライアントコンテナーを実行する必要があります。 では、生成されたファイルをコンテナから「ワークスペース」ホストディレクトリに移動する方法を教えてください。 Dockerコンテナ内のマウントされたディレクトリに既にいるため、ディレクトリのマウントは許可されていません。 docker-compose cpができると、コンテナIDを取得するという余分な面倒な手順が軽減されます。

$(docker-compose ps -q SERVICE)を使用して適切なコンテナーをターゲットにすると、このようなコンテナー中心の操作にプレーンなdockercliを使用できます。 新しいコマンドを導入すると、それを要求するいくつかのユースケースで確実に簡単になりますが、必須ではありません。 作成CLIとDockerCLIの間でコードが重複しないようにするには、この問題を解決する必要があると思います。

使用しているdockerデーモンのバージョンが原因で、composeとplain dockerのビルドキャッシュが異なるという未解決の問題があります。つまり、CI環境でキャッシュを壊さないように純粋なcomposeを使用する必要があります（https：// github .com / docker / compose / issues / 883）したがって、これらの問題が解決されるまで、プレーンなdockerコマンドとcomposeコマンドを混在させるとキャッシュが壊れます。 構成構成は、構成でベイクされたすべての種類を指定し、プレーンなdockerコマンドを使用して重複構成を手動で指定する必要性を軽減します。

$(docker-compose ps -q SERVICE)を使用して適切なコンテナーをターゲットにすると、このようなコンテナー中心の操作にプレーンなdockercliを使用できます。 新しいコマンドを導入すると、それを要求するいくつかのユースケースで確実に簡単になりますが、必須ではありません。 作成CLIとDockerCLIの間でコードが重複しないようにするには、この問題を解決する必要があると思います。

これらのシナリオはかなり一般的であり、変更、イメージのビルド、再変更、イメージのビルドなどは、docker-composeを介してそれらを処理できるタイムシンクであるため、これは「言及されたいくつかのユースケース」よりもはるかに深くなります。 「dockercliで実行できるので、そこで実行する」という引数は、docker-composeに追加された他の多くのことをほとんど無効にします。

この1つの問題は、ほぼ1年間開かれており、この問題以外にも多くの議論があります。 それが実際に解決されない限り、それは間違いなく閉じられるべきではありません。

@ dionjwa ＃883は、

@ jadon1979この機能リクエストをブロックしようとはしていませんが、1年以上前に開かれたことに気づきました。
この機能リクエストへのフィードバックと、「より良い方法」を提供するための開発努力の欠如によると、docker-composeとdocker cliの組み合わせを使用するための提案された回避策は、簡単にエイリアスできると言っています。使いやすくするための環境は、合理的な回避策です。
さて、誰かが新しいcpコマンドを提供するためにPRを開いたら、私はそれをレビューさせていただきます。

誰もがすべてのユースケースは
アンチパターン。 そして、数日ごとに新しいユースケースが投稿されていますが、どれもありません
アンチパターン。

17:31ニコラス・デ・てのひらで月、2019年11月18日には[email protected]
書きました：

@dionjwa https://github.com/dionjwa＃883
https://github.com/docker/compose/issues/883は本当に必要です
docker-composeを次のように調整する必要があるため、調査しました（まだ関連している場合）
dockerCLI。

@ jadon1979https ：//github.com/jadon1979これをブロックしようとはしていません
機能リクエスト、1年以上前にオープンしたことに気づき、
コアメンテナの誰もそれが十分に重要であると考えていませんでした
新しいコマンドを導入しましたが、寄稿者もそのPRを提案しませんでした。
この機能リクエストへのフィードバックによると、
そして「より良い方法」を提供するための開発努力の欠如、提案された
docker-composeとdockercliを組み合わせて使用​​するための回避策
環境内で簡単にエイリアスを作成して、使いやすくすることができます。
合理的な回避策。
さて、誰かが新しいcpコマンドを提供するためにPRを開いたら、私は喜んで
レビューする。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NS64IYANNVTGFTULQUL3TZA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWS
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAGRIFY7CULCUS3TDDTTHZLQUL3TZANCNFSM4EKAVONA
。

私のユースケースは、コンテナに物をコピーするのではなく、実行後にコンテナからコピーします。 これは、おそらく機能が低下する不格好な回避策を使用して、CLIから実行できます。 詳細は以下をご覧ください。

私はDevOpsエンジニアであり、ベアメタルビルドエージェントの依存関係地獄の代わりとして、コンテナーに大きく依存しています。 私のCIシステムがリポジトリをテストするとき、それは同じリポジトリ内のDockerfileからビルドし、すべてのチェック（ bundle exec rspec 、 npm testなど）を_コンテナー内で_実行することから始まります。 ドキュメントやテスト結果のように作成されたビルドアーティファクトがある場合は、 docker cpを使用してコンテナーからコピーします。

統合テストでは、 docker-composeを使用して、テストを実行するコンテナーにサービスの依存関係（データベースサーバーなど）を提供し始めました。 残念ながら、この場合、「docker CLIの回避策」は、ファイルをコピーするのにあまり役立ちません。

この構成を検討してください： docker-compose-minimal.yml

version: "3"
services:
  artifact-generator:
    image: busybox

コンテナーを作成し、そのコンテナーでコマンドを実行し、コンテナーIDを取得して、 docker cpを使用してファイルを抽出してみます。

$ # Prepare the images and (stopped) containers.  In this case there is only one.
$ docker-compose --file docker-compose-minimal.yml up --no-start
Creating network "docker-compose-cp-test_default" with the default driver
Creating docker-compose-cp-test_artifact-generator_1 ... done
$ # Determine the ID of the container we will want to extract the file from
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # Generate the artifact in the container
$ docker-compose --file docker-compose-minimal.yml run artifact-generator touch hello.txt
$ # Check that container ID again, just to be sure
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # OK, that looks like the only answer we're going to get.  Can we use that to copy files?
$ docker cp $(docker-compose --file docker-compose-minimal.yml ps -q artifact-generator):hello.txt ./hello-artifact.txt
Error: No such container:path: 050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88:hello.txt
$ # Nope.  Let's take a look at why this is
$ docker container ls -a
CONTAINER ID        IMAGE                        COMMAND                   CREATED              STATUS                          PORTS               NAMES
9e2cb5d38ba0        busybox                      "touch hello.txt"         About a minute ago   Exited (0) About a minute ago                       docker-compose-cp-test_artifact-generator_run_dd548ee686eb
050753da4b0a        busybox                      "sh"                      2 minutes ago        Created                                             docker-compose-cp-test_artifact-generator_1

ご覧のとおり、 docker-compose psは、更新されたコンテナIDを実際には認識していません。 これは残念です。 run_dd548ee686ebが実行したdocker-compose runに何らかの形で関連していることを知る方法があれば、これはそれほど悪くはありませんが、それを達成する方法はありません。

この回避策には不格好な回避策があります。これは、実行コマンドに--nameを追加することです。

$ docker-compose --file docker-compose-minimal.yml run --name blarg artifact-generator touch hello.txt
$ docker cp blarg:hello.txt ./hello-artifact.txt
$ ls 
docker-compose-minimal.yml  hello-artifact.txt

成功！ ...ちょっと

ここでの問題は、複数のビルドを並行して実行している場合、 --nameグローバルに一意にするという問題に取り組む必要があることです。 そうしないと、最良の場合はノイズの多い衝突が発生し、最悪の場合は破損した結果（エラーは発生しませんが、間違ったファイルが抽出されます）が発生します。 Dockerがすでに作成したものを使用するのではなく、コンテナIDの生成を再発明する必要があるため、これは不格好です。

最低限、 docker-compose runコマンドの結果であるコンテナーのIDを知る方法が必要です。

@ndeloof

$（docker-compose ps -q SERVICE）を使用して適切なコンテナーをターゲットにすると、このようなコンテナー中心の操作にプレーンなdockercliを使用できるようになります。

False、前のコメントのデモンストレーションを参照してください。

ここでは、何年にもわたって新しいユースケースがあります。 待って、私は新しい反を意味します
パターン...

2019年12月13日金曜日、11：40 Ian、 notifications @ github.comは次のように書いています。

@ndeloof https://github.com/ndeloof

$（docker-compose ps -q SERVICE）を使用して、適切なコンテナーをターゲットにします
このようなコンテナ中心のプレーンDockerCLIを使用できるようにします
操作。

False、前のコメントのデモンストレーションを参照してください。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NFPTKY3QKRIXQ5RTQYONHLA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWS
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAGRIF3S4UHF5NG3VKYXJB3QYONHLANCNFSM4EKAVONA
。

メンテナに連絡するために誰に言及できますか？ 彼らが私たちと話し始めるまで、この問題は無意味です。 単純な「現在のソフトウェアアーキテクチャのために実行できない」などです。 しかし、そのような問題を不活性のままにしておくことは、Dockerのようなこの非常に人気のあるソリューションから見たいものではありません...

このデプロイメントでは、bazelを使用してDockerイメージを構築し、Dockerレジストリにアップロードしてから、Terraform docker_containerリソースとuploadスタンザを使用して、構成ファイルをコンテナーにコピーします。 Terraformの代わりにdocker-composeを使用するには、このデプロイメントプロセスを移行する必要があります。 docker-composeがコンテナーごとの構成に機能を提供しないことに驚いています。

この号は2年間発行されています。 これが、Kubernetesの人気がDockerを上回っている理由ですか？ Kubernetesはconfig関数とsecrets関数を提供します。 Dockerチーム、少なくとも構成機能を追加してください。

tbf docker-composeはk8sと正確に比較できるわけではなく、本番環境での使用はお勧めしません。 これは、開発と迅速なテストを目的としています。 docker swarmはk8sと比較するものであり、非常に単純ですが、構成やシークレットなどの機能があります。

それが開発のためだけのものであるなら、それはこの問題のさらに多くの理由です
動作するはずです。 くだらない「アンチパターン」ルールはそれでさえあるべきではありません
重要（通常の使用の豊富さから明らかなので、私はくだらないと言います
アンチパターンに似たものではない場合）。

12:56デビッドMilumで火、2020年3月3日には[email protected]
書きました：

tbf docker-composeはk8sと正確に比較できないため、お勧めしません
生産用。 これは、開発と迅速なテストを目的としています。 docker
群れはk8sと比較するものであり、それは非常に
単純化すると、構成やシークレットなどの機能があります。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIFZTKGRWMZZ5H6DG3FDRFUSEJA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWS
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAGRIF4NTQQSR2QQWPJT6PLRFUSEJANCNFSM4EKAVONA
。

別の「アンチパターン」：

ローカル開発中のコンテナオーケストレーションにはdocker-composeを使用し、本番環境にはk8sを使用します。

Docker自身のアドバイスに従って、サービスの起動/シャットダウンの順序を管理するためにwait-for-it.shスクリプトを実装しました。

現状では、この1つのファイルだけで各サービスにボリュームをマウントする場合を除いて、各サービスのDockerfileを含むディレクトリにスクリプトのコピーが必要です。

代わりに、 wait-for-itスクリプトの単一のコピーをトップレベルのディレクトリに保持し、ローカルで実行するときにdocker-composeを各コンテナにコピーします。これは、他の方法ではk8sで管理されるためです。つまり、これらの懸念が私のサービスのDockerfile汚染することを望まないということです。

エマーソンがかつて書いたように、「愚かな一貫性は、小さな政治家や哲学者や神々に愛された、小さな心のホブゴブリンです。」

おそらく、ユーザーの話を聞くときです...

@Phylodomeは、コンテナのヘルスチェックとdocker-compose depends_onを使用できませんか？ これが、コンテナーの起動の依存関係を正常に保つ方法です。

私の理解では、 wait-for-it.shは実際にはハックです。なぜなら、サービス自体は、行き来する依存関係に対して回復力があるはずだからです。 スタートアップはその個々のケースにすぎません。

@ianfixes 「あなたのサービス」は、 それとも、docker -composeを使用する私たちが作成したサービスのように「私たちの」サービスを指すことを意味しますか？ あなたが「ユーザー」の役割で書いているのか、docker-compose開発者の役割で書いているのかわかりません。

「あなたのサービス」は、docker-composeサービス自体を指すことを意味しますか、それとも「私たちの」サービスを指しますか？

開発者として構築するサービスは、回復力が必要です。 これは、次のドキュメントによるものです： https ：

たとえば、データベースの準備が整うのを待つという問題は、実際には分散システムのはるかに大きな問題のサブセットにすぎません。 本番環境では、データベースが使用できなくなったり、ホストがいつでも移動したりする可能性があります。 アプリケーションは、これらのタイプの障害に対して回復力がある必要があります。

これを処理するには、障害後にデータベースへの接続を再確立しようとするようにアプリケーションを設計します。 アプリケーションが接続を再試行すると、最終的にデータベースに接続できます。

最善の解決策は、起動時と何らかの理由で接続が失われたときの両方で、アプリケーションコードでこのチェックを実行することです。 ただし、このレベルの復元力が必要ない場合は、ラッパースクリプトを使用して問題を回避できます。

そして、さまざまな待機スクリプトについても言及します。

私は多くのことをする理由の詳細を知らない人々からの一般的なアドバイスではなく、最も単純で目立たないローカル実装を好みます。 dこれを実行したい（たとえば、Webpackの開発サーバーを介してUI開発を実行するためのボリュームマウントの問題）。

いずれにせよ、これは、この機能になる予定のユースケースの長いリストの中で、ユーザーの裁量に任せるべきものの1つにすぎません。

私に向けられた怒りを聞いていますが、あなたのアプローチに対する一方的な「アドバイス」を聞くのがなぜイライラするのか理解しています。 しかし、私は謝罪する方法さえわかりません。 あなた自身が「Docker自身のアドバイス」と呼んでいるURLからのテキストを引用しました。これは、待機スクリプトが「問題を回避する」方法であると_明示的に_述べています。 それだけの価値があるので、とにかくごめんなさい。

あなたは怒りを聞いていません。 あなたは、かなり明白な機能であるべきものをグーグルで調べたときに、一連のメンテナが完全に有効な機能に対するコミュニティの嘆願を継続的にひいきにして拒否した100コメントのスレッドに出くわした誰かの憤慨した口調を聞いています。

私はここで私の経験を共有しませんでしたb / c私は謝罪したかったです。 Dockerユーザーがcomposeを使用するときに追加の柔軟性を望んでいるという証拠の長いリストに追加するために、それを共有しました。

もちろん、他のツールと同様に、その柔軟性は悪用の可能性とともに発生します。 ただし、この機能を追加するだけではるかに簡単に解決できる特定のユースケースを解決するための回避策をユーザーが見つけなければならない場合、同じ可能性が存在します。

さらに、謝罪してユーザーにガス灯を当てるのは見栄えが悪いです。

私はこのプロジェクトの維持者でも貢献者でもありません。そこで混乱が生じたことをお詫びします。 私が提供できると思っていた小さな支援は、望ましくなく、役に立たなかったようです。時間を無駄にして申し訳ありません。

分散アプリケーションの一部であるGoコンテナーにこの機能が必要です。 .envファイルをGoアプリケーションのルートに含める必要があるため、別の.envを作成する必要があります...一方、この機能があれば、トップレベルの.envファイルを用意し、ビルド時にそれをGoコンテナーにコピーします。 それは私が追跡する必要があるものが少なくなることを意味します...

私の回避策は、GoコンテナのDockerfileを介してこのファイルを作成するか、そのコンテナ用に.envファイルを作成することです。 しかし、それでも、新しいenv varを追加するときはいつでも、おそらく2か所で更新する必要があります。 ここでの良いユースケース。 または、シェルスクリプトを使用してファイルをcpすることもできます...

コピー機能の+1

Kubernetesではサイドカーを使用してこれをすでに達成しており、多くのユースケースがあります。 これはアンチパターンではなく、docker-composeを維持する機能の1つにすぎません。

何かが足りないかもしれませんが、現在5分間アプリをビルドしていると、その間ずっとビルドフォルダーが「流動的」であり、不整合のためにアプリが起動しません。
ビルドフォルダをコンテナに_コピー_したいので、コンテナを起動するときに内部のフォルダを引き継ぎます。 このようにして、コンテナを停止/開始するときに、アプリは1秒ほどオフラインになります。

dockerすでにサポートしている場合、これはどのようにアンチパターンですか？ docker-composeは、Dockerの使いやすさに近いため、従うことは理にかなっています。そうしないこと自体がアンチパターンです。

これに伴う問題は、コンテナが再作成されるたびに操作を繰り返す必要があるため、非常に近視眼的である（したがって「アンチパターン」という用語）ことです。 スケーリングが非常に悪いという事実は言うまでもありません（コンテナが10個ある場合はどうなりますか？20？100？）

それは開発者次第だと思います。 単一のローカル構成ファイルをコピーするだけでは、オーバーヘッドはわずかです。 ナイフのせいにしないでください。

PS私のユースケース; DockerfilesのないプロジェクトのNginxコンテナーに構成を追加したいと思います。

もう誰も知らない。
新しいプロジェクトを立ち上げて、新しいものを探す必要がありました
ツール、Landoはこれよりもはるかに優れています。 使ってほしい
より早く。
より速く、理解しやすく、すぐに使えるサポートと
見下すような（元）メンテナ/寄稿者がいません。

@ chris-あなたのコメントに関するcrone..。

構成ファイルまたはブートストラップデータには、Docker構成があります。 これらはシークレットと同様に機能しますが、どこにでもマウントできます。 これらはSwarmとKubernetesでサポートされていますが、docker-composeではサポートされていません。 これらのサポートを追加する必要があり、この問題にリストされているいくつかのユースケースに役立つと思います。

docker-composeは、swarm構成と同等の構成サポートの実装に関心がありますか？

これのチケットがある場合（または私もそれで問題ないものを作成する必要がある場合）、私はそれを購読し、このゴミの火から購読を解除したいと思います。 個人的にはこれを閉じてリンクしますが、それは私だけです。

@harpratapあなたは正しいですが、欠点は/ folder_in_containerが存在してはならないか、空でなければならないことです。 エントリポイントとしてbashスクリプトがある場合は、/ some_empty_locationにボリュームを作成した後、ファイルを元の目的のディレクトリにシンボリックリンクすることでこれを回避できます。

COPY機能を持つための+1。 私たちのユースケースは、ローカル開発環境を迅速に立ち上げ、開発設定の構成をコピーするためのものです。

丁度。 すべてが同じようにスケーリングするわけではありません。 私の会社では、SALTを使用して、さまざまなアプリに必要な.confファイルを作成しています。 1つのビルド（基本を使用）、次にdocker-composeを使用して、MACアドレス、IP、ポート、ライセンス、モジュールなどの固有の部分に基づいて個々のインスタンスを作成します。コマンドラインから実行できますが、はるかに簡単で少ないです。 docker-composeでエラーが発生しやすくなります。

ユースケースがあります。 sslのセットアップが必要なテストビルドがあります。 証明書はdocker-composeのサービスによって生成されます...次に、それらの証明書をクライアントコンテナーに追加します...マウントすると、既存の証明書が失われ、dockerビルドに配置できなくなります。まだ存在していません。

したがって、2つのdocker-composeを実行する必要があります。1つはサービスを起動して証明書を作成し、もう1つはサービスを構築してテストを実行します。 散らかっています。

ここで多くの問題が発生しました。ユーザーは機能の多くのユースケースを提案しましたが、メンテナーが考えているように撃墜されている、アンチパターンである、または人々がそれを使用しない、または他のストーリー。

1人にとってはアンチパターンのように見えるかもしれませんが、この機能を要求している1000人の人々は、そうではないと考えているので、同様に聞く必要があると確信しています。 機能の開発に助けが必要な場合は、多くの人が手を貸してくれると思います。

私のユースケース：構成に加えて、5つのRailsアプリケーションコンテナー（Debian）にインストールする必要のあるライブラリ（RPM）がいくつかあります。 Ruby / Railsのバージョンが異なるため、同じベースイメージを使用できないため、ファイルを1つの場所に保存して、ビルド時にコンテナーにコピーできるはずです。1.5GBのデータをダウンロードしたくないのですが。構築中。

@gauravmanchanda

私のユースケース：構成に加えて、5つのRailsアプリケーションコンテナー（Debian）にインストールする必要のあるライブラリ（RPM）がいくつかあります。 Ruby / Railsのバージョンが異なるため、同じベースイメージを使用できないため、ファイルを1つの場所に保存して、ビルド時にコンテナーにコピーできるはずです。1.5GBのデータをダウンロードしたくないのですが。構築中。

このための多段階ビルドを見たことがありますか？ より堅牢なソリューションになると思います。

マルチステージビルドでは、複数のイメージに同じDockerfileを使用できます。 これにより、それらを因数分解し、各画像に必要なビットのみを含めることができます。

その良い例は、 DockerComposeのビルドに使用するものです。 これはDebianまたはAlpineのいずれかを使用してビルドされますが、一般的なコードを因数分解することができます。

私たちのセットアップでは、docker-composeを使用して約12のシミュレーターを立ち上げます。 シミュレーターはそれ以外は同じですが、1つのinitファイルはターゲットごとに異なり、このファイルは起動時に消費されます（サーバーが稼働しているときに削除されます）。 1つのファイルが異なるという理由だけで、ほぼ同一の画像を1ダースほど作成する必要があることを本当に提案していますか？ それはIMOには意味がありません。

dockerを使用すると、-copy-serviceフラグを使用してこれを実現できます。 docker-composeで使用できる代替手段はありますか？

こんにちは@megaeater 、

docker-composeを使用して約12のシミュレーターを立ち上げます。 シミュレーターはそれ以外は同じですが、1つのinitファイルはターゲットごとに異なり、このファイルは起動時に消費されます（サーバーが稼働しているときに削除されます）。

これは興味深いユースケースです。 いくつかの質問：これらのシミュレーター（またはその一部）は本番環境で実行されたことがありますか（つまり、開発者のマシンやCIでは実行されません）？ コードが開いている（または同様のシステムが開いている）場合は、コードをリンクして、確認してください。

これらのファイルのバインドマウントやボリュームの代わりにコピーが必要な理由を知ることも興味深いでしょう。

1つのファイルが異なるという理由だけで、ほぼ同一の画像を1ダースほど作成する必要があることを本当に提案していますか？ それはIMOには意味がありません。

画像はまさにこの理由でレイヤーベースです。異なるファイルを含むレイヤーを除いて、すべての画像は同じレイヤーを参照します。

コンテナ作成時のコピーなどの問題は、オーケストレーションされた環境ではパターンが壊れやすいか不可能になるため、同じコードを取得して本番環境で実行するのが困難になることです（つまり、主要なロジックの書き換えが必要です）。

これは、Composeでこのようなものを実装してはならないということではありません。 むしろ、変更によってユーザーが本番環境でローカルに機能するものを再利用できなくなる場合は、一時停止して、同じ目標を達成するためのより堅牢な方法があるかどうかを確認したいと思います。

コメントありがとうございます@ chris-crone

Dockerは本番環境では実行されていません。これは、開発目的のためだけです。 ボリュームの使用に関する問題（私が正しく理解している場合）は、シミュレーター（サードパーティ）に、起動時にファイルを削除するこの起動スクリプトがあることです。 削除に失敗するとスクリプトの実行が停止するため、rwとしてマウントする必要があります。 また、ファイルの削除が許可されている場合は、元のファイルが削除されないように、これらのファイルを提供するための一時ディレクトリを作成するメカニズムが必要になります。 そのため、docker-composeの上にコンポジションを追加するには、なんらかの無関係なスクリプトが必要になります。

@ chris-croneリンクありがとうございます。 私はそれが私たちのために働くかどうか見てみます👍

ちょっと@ chris-crone私はマルチステージビルドを使ってみました、そしてそれは私たちがライブラリ/設定を1つの場所だけに保持してそれらをコピーするのを助けました、しかし今はどこにいても.dockerignoreが無視されるという問題があります置きます。

新しいDOCKER_BUILDKITオプションを指定してDockerを使用している場合は機能しますが、docker-composeを使用している場合は機能せず、 COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build試しましたが、それでも機能しませんでした。 何か案は？

この問題https://github.com/docker/compose/issues/6022に出くわしたときに、composeで.dockerignoreを探す場所を指定するオプションがあるかどうか疑問に思いました。 coz 1の寄稿者は、これは役に立たないと考えています。

私がここで正直であるならば、これはかなりイライラします！

これはMacOSでは非常に重要です。開発サイクルを本番環境にできるだけ近づけることが最も重要だからです。 明らかに、適切な継続的デリバリーの実践のためです。 たとえば、コンテナをビルドしますが、ビルドサイクル時間を節約するために、現在作業中のソフトウェアの新しいバージョンをコンテナにバインドマウントします。 残念ながら、バインドマウントは非常にコストがかかり、3〜5倍遅くなります。

例として、Tomcatの起動時間は、コンテナー内の私のアプリでは約3秒です。 〜/ .bash_historyのバインドマウントを追加すると4秒になります。 私のアプリのバインドマウントを追加すると、通常は約18〜20秒です。 Linuxでは、バインドマウントのパフォーマンスはローカルファイルシステムのパフォーマンスと似ていますが、MacOSではそうではありません。 それを1日100回にスケーリングすると、それは重要です。

これには、アプリに初めてアクセスするときに続く速度低下は含まれていません。 コードファイルがキャッシュされるまで。 私にとって、これは3分を意味します。これには、モノリシックOracleデータベースに接続して小さなフレーズを別のフレーズに変更するためのインターネット上のラグが含まれ、それでも問題がないかどうかを確認します。 くそーcovid-19、笑。

理想的には、docker-composeを再度実行して、実行中のコンテナーでアプリを「更新」し、tomcatにリロードを依頼できるようにしたいと思います。 Tomcatマネージャーを使用して変更をアップロードすることもできますが、管理対象コンテナーを使用しないバックエンドアプリもあるため、別のソリューションを使用する必要があります。

docker-composeが、本番環境のデプロイだけでなく、開発にも対応していると便利です。

このユースケースは、ディスカッションに関連しています： //github.com/docker/compose/issues/3593#issuecomment -637634435

@ chris-crone

@gauravmanchanda

私のユースケース：構成に加えて、5つのRailsアプリケーションコンテナー（Debian）にインストールする必要のあるライブラリ（RPM）がいくつかあります。 Ruby / Railsのバージョンが異なるため、同じベースイメージを使用できないため、ファイルを1つの場所に保存して、ビルド時にコンテナーにコピーできるはずです。1.5GBのデータをダウンロードしたくないのですが。構築中。

このための多段階ビルドを見たことがありますか？ より堅牢なソリューションになると思います。

マルチステージビルドでは、複数のイメージに同じDockerfileを使用できます。 これにより、それらを因数分解し、各画像に必要なビットのみを含めることができます。

その良い例は、 DockerComposeのビルドに使用するものです。 これはDebianまたはAlpineのいずれかを使用してビルドされますが、一般的なコードを因数分解することができます。

マルチステージビルドはクールですが、独自の問題があります。同じコンテキスト内ですべてのステージを実行する必要があるため、常に可能であるとは限りません。 また、私の知る限り、あなたは簡単に使用することはできませんCOPY --from別Dockerfileで定義されているとして構築された画像をdocker-compose build （私はあなたが構築し、それらを手動でタグ付けすることによってそれを行う可能性が想定します）。

COPY自体は、ビルドコンテキストからのみインポートできるという点で非常に制限されています。 docker cpは、イメージとコンテナの間でコピーできないことを除いて、どこからでもどこにでもコピーできます（ COPY --fromのようなもの）。

私自身のユースケースは少し異なり（読み取り専用の構成ファイルをコピーすることを除けば、別のマシンにデプロイする場合はローカルボリュームマウントは最善のアイデアではありません）、現在行っているのはアンチパターンです... 。 ビルド時にコンパイルおよび縮小されたJS + HTML +アセットバンドル（小さな角度のアプリを考えてください）を生成するいくつかの異なるイメージと、それらすべてを提供する単一のnginxサーバー（プラグインのためにカスタムイメージからビルドされたnb）が存在する可能性があります。

現在、私がしなければならないのは、起動時に「ビルド」イメージから「デプロイ」パッケージをコピーすることです。 理想的には、これはコンテナの作成時またはビルド時に実行する必要がありますが、後者では「moddednginx」の上に別のイメージを作成する必要があります。

次のプロジェクトレイアウトをイメージします（サブプロジェクトは別々のリポジトリにあり、お互いを知らない場合があります）。

app1/
  src/
    ...
  Dockerfile
app2/
  src/
    ...
  Dockerfile
app3/
  src/
    ...
  Dockerfile
nginx/
  ...
  Dockerfile
docker-compose.yml

各ファイルapp{1,2,3}/Dockerfileは、アプリを/usr/src/app/distビルドするターゲット/ステージbuildが含まれています。 nginx/Dockerfileは1つのステージしかなく、 nginx/nginxと同様のイメージを構築しますが、必要なすべてのプラグイン（構成なし）を使用します。

docker-compose.yml：

version: '3.8'
services:
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app1 \
        && cp -vr /usr/src/app/dist /dist-volume/app1 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  app2-build:
    build:
      context: app2/
      target: build
    image: app2-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app3 \
        && cp -vr /usr/src/app/dist /dist-volume/app3 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  #... same thing for app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    volumes:
      - 'dist:/var/www'
      - # ... (config files etc)

volumes:
  dist:

さて、これは明らかに理想的ではありません。各アプリ構築イメージは不必要に実行されてすぐに終了し、デプロイされたイメージは共有ボリュームに存在します（これはパフォーマンスに悪影響を与えると思いますが、まだ確認できませんでした）。 copyまたはcopy_fromがdocker-composeオプションである場合、同じように書くことができます。

version: '3.8'
services:
  # assuming the images have default entrypoint and cmd combination that immediately returns with success.
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build

  #... same thing for app2-build app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    copy:
      - from: app1-build  # as image or service, both have their pros and cons, service would mean an image associated with this service
         source: /usr/src/app/dist
         destination: /var/www/app1
      - from: app2-build
         source: /usr/src/app/dist
         destination: /var/www/app2
      - from: app3-build
         source: /usr/src/app/dist
         destination: /var/www/app3
    volumes:
      - # ... (config files etc)

私のユースケースは、ビルドステップまたはスタートアップステップではありません。 サービスのコンテナまたはすべてのコンテナ内で生成されたファイルをフェッチしています。これらのコンテナはリモートDockerエンジンで実行されます。 これまでのところ、 docker-compose ps -qa <service> | xargs -i docker cp {}:<there> <here>ようなことをしていることに

@ chris-crone

これらのファイルのバインドマウントやボリュームの代わりにコピーが必要な理由を知ることも興味深いでしょう。

あなたは自己鞭打ちを楽しんでいますか？ その場合は、MacOSでバインドマウントを使用してアプリケーションを実行することをお勧めします。 🤣詳細については、以前の投稿を参照してください。

これは、Composeでこのようなものを実装してはならないということではありません。 むしろ、変更によってユーザーが本番環境でローカルに機能するものを再利用できなくなる場合は、一時停止して、同じ目標を達成するためのより堅牢な方法があるかどうかを確認したいと思います。

@ chris-crone構成やデータを一時的な方法で管理しないなど、Dockerのアンチパターンの実装に取り​​掛かる人が非常に多いため、これは素晴らしい感情だと思います。

どういうわけか、dockerとAppleがバインドマウントのパフォーマンスの問題を修正するために協力することができるのだろうか。 少なくとも私にとっては、開発にバインドマウントを使用するため、Dockerのcomposecpオプションは必要ありません。 今のところ、バインドマウントを使用するには苦痛が多すぎます。 Linuxを搭載した仮想マシンに切り替えると、Macが数バイトになる可能性があります。

@megaeater

Dockerは本番環境では実行されていません。これは、開発目的のためだけです。 ボリュームの使用に関する問題（私が正しく理解している場合）は、シミュレーター（サードパーティ）に、起動時にファイルを削除するこの起動スクリプトがあることです。 削除に失敗するとスクリプトの実行が停止するため、rwとしてマウントする必要があります。 また、ファイルの削除が許可されている場合は、元のファイルが削除されないように、これらのファイルを提供するための一時ディレクトリを作成するメカニズムが必要になります。 そのため、docker-composeの上にコンポジションを追加するには、なんらかの無関係なスクリプトが必要になります。

うーん..シミュレータベンダーと協力できれば、それがこの問題を解決する最良の方法だと思います。 必要に応じてファイルを移動するシミュレーターのエントリポイントスクリプトを使用して、これを回避できます。 当然のことながら、これは厄介です。

@gauravmanchanda

これは、library / configを1つの場所にのみ保持し、それらをコピーするのに役立ちましたが、どこに配置しても.dockerignoreが無視されるという問題があります。
新しいDOCKER_BUILDKITオプションを指定してDockerを使用している場合は機能しますが、docker-composeを使用している場合は機能せず、 COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build試しましたが、それでも機能しませんでした。 何か案は？

嬉しい多段階ビルドが役に立ちました！ どのバージョンのDockerとdocker-composeを使用していますか？ 私は最新のものを試してみて、問題がまだあるかどうかを確認します。 .dockerignoreファイルを尊重する必要があります。

@Marandil 、 docker buildが問題のプロジェクト構造（つまり、ディレクトリ構造）を処理していないようです。 docker buildx bake （https://github.com/docker/buildx）のようなものを使用して、このユースケースを解決できる可能性があります。 buildxは作業中であるため、まだ非常に安定していませんが、ヒットしているもののいくつかを解決することを目的としています。

@itscaro 、ご意見ありがとうdocker buildを使用してFROM scratchイメージから結果を出力することです。 これは、単一のコンテナーの出力が必要な場合にのみ機能します。

@TrentonAdams Docker Desktopのファイルシステムパフォーマンスの改善に取り組んできましたが、こことここにパフォーマンスチューニングに関するドキュメントがあり

@ chris-crone

@Marandil 、 docker buildが問題のプロジェクト構造（つまり、ディレクトリ構造）を処理していないようです。 docker buildx bake （https://github.com/docker/buildx）のようなものを使用して、このユースケースを解決できる場合があります。 buildxは作業中であるため、まだ非常に安定していませんが、ヒットしているもののいくつかを解決することを目的としています。

ありがとう、 docker buildx bake調べます。 有望に見えますが、適切なリファレンスやドキュメントが見つかりませんでした。docs.docker.comのページはかなり裸です（https://docs.docker.com/engine/reference/commandline/buildx_bakeを参照）。 /）。 これまでのところ、いくつかの例を参照しているhttps://twitter.com/tonistiigi/status/1290379204194758657を見つけました（https://github.com/tonistiigi/fsutil/blob/master/docker-bake.hcl、https://github .com / tonistiigi / binfmt / blob / master / docker-bake.hcl）、これは良い出発点かもしれませんが、良いリファレンスとは言えません。

@TrentonAdams Docker Desktopのファイルシステムパフォーマンスの改善に取り組んできましたが、

@ chris-crone地獄はい、どうもありがとう！ 新しいオプションでは3〜4秒の改善があり、「キャッシュ」を使用すると、コンテナーの外部で実行するのと同じパフォーマンスが得られるため、これは私にとって非常に大きな問題です。 私たちのアプリの起動時間は2800ミリ秒と短いので、もう11〜18秒ではありません。 わーい！ とにかく毎回コンテナを再作成しているだけなので、キャッシュ以外は必要ありません。

@ chris-crone MacOSでのパフォーマンスチューニングとフィードバックを支援するためにパフォーマンス関連のものを投稿する必要がある場所はありますか？ cachedを使用しないと、バインドマウントを使用して新しく起動したコンテナが遅くなるのはなぜだろうと思います。 まったく新しい場合でも、起動時にすべてのファイルが同期しているかどうかをチェックするという奇妙なことがあるはずです。

ユースケース：コンテナーを実行すると、ファイルが変更されます（具体的には、Keycloakは環境変数などに基づいて構成ファイルを変更します）。 そのファイルのコピーをローカルディスクに保存して、その変更の結果を確認し、コンテナスクリプトを変更するときに進行状況を追跡できるようにします。 現在、 docker cp使用できるように、毎回新しいコンテナIDを見つける必要があります。

使用事例：
Dockerで開発中。
ロックファイルをホストマシンに逆伝播する必要があります。そうしないと、コンテナがプロジェクトフォルダをマウントするときに上書きされます。

ユースケース：秘密鍵を含むファイルをコピーする必要があります。 コンテナ内で実行されるアプリは、そのファイルをメモリに読み込み、ディスクから削除します。

ユースケース：Dockerコンテナでc ++ユニットテストを実行しています。 実行するたびに、コードを既存のイメージにコピーするだけです。

1）別のdockerfile COPYを使用してこれを行うと、コードが新しい不要なイメージに書き込まれ、次の実行で最新のコードで新しいイメージが作成されるように、そのイメージを削除する必要があります。

2）docker-compose volumes yaml configを使用してこれを行うと、 Dockerはソースコードをroot:rootとしてchownします（IDEをchownするまで編集を完全に停止します！）

@ shin-コンテナでユニットテストを実行することでアンチパターンに従っていますか？ これを解決する非アンチパターンの方法は何ですか？

....痛みが最も少ないので、オプション1を使い続けています。 しかし、私はdocker-composeがコピー構成をサポートしているのを見て、とても素晴らしい拡張機能です！ 少なくともこのワークフローでは！

@soulseekahそのユースケースでは、composeでシークレットを使用

私はそれが私のために働くための回避策を見つけました：

1. でDockerfileを作成します
   COPY a_filename .
2. Dockerfileを使用してイメージをビルドします
   docker build -t myproject:1.0 .
3. docker-composeを編集して、作成したばかりのイメージを使用します

version: "3.7"
services:
  app:
    image: myproject:1.0
    ports:
      - 3000:3000
    networks:
       - mynetwork
       - internal
    environment:
      MYSQL_HOST: mysql
      MYSQL_USER: root
      MYSQL_PASSWORD: not_so_secret_password # don't do this 
      # https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
      MYSQL_DB: appdb
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 100M

完全な回避策ではありませんが、私のユースケースでは機能します。

@soulseekahそのユースケースでは、composeでシークレットを使用

残念ながら、前回試したときは群れが必要です:(

@soulseekahそのユースケースでは、composeでシークレットを使用

残念ながら、前回試したときは群れが必要です:(

@soulseekah多分私が（あなたの上で）使用する回避策を使用しますか？

@ChristophorusReyhanその@ zoombinisのコメントに示されてい

別のdockerfileCOPYを使用してこれを行うと、コードが新しい不要なイメージに書き込まれ、次の実行で最新のコードで新しいイメージが作成されるように、そのイメージを削除する必要があります。

実用的なソリューションですが、不要なメンテナンスにつながる可能性があります。 たとえば、不要な画像をクリーンアップするには、_気になる画像も保持しながら_：

docker-compose up && docker-compose down --rmi local

ただし、気になるすべての画像にカスタムタグがあり、テスト/ダミー画像にはないことを確認してください