Compose: docker-画像がローカルに存在する場合、composeupは最新の画像をプルダウンしません

docker-compose pull && docker-compose upが実用的でない理由はありますか？

賛成/反対のポイントのほとんどは、 --pullをdocker runに追加するための問題で説明したものと同じだと思います。 それらは、UXと一貫性から、スクリプト/ワークフローの容易さ、群れの統合にまで及びます（好奇心から、 docker-compose pullは群れで何をしますか？）。
それは大きな問題ではないと思いますが、考慮すべきことがあります。 他の場所でこの機能を望んでいた同じタイプのユーザーは、おそらくここでもそれを楽しむでしょう。

「docker-composebuild」を実行しようとしていますが、_-- pull_を使用する場合を除いて、Dockerfileで参照されているイメージが更新されません。

開始時に_up--build_を使用してコンテナーをビルドすることもできます。 ただし、最新の画像はプルされません。 「docker-composeup--build--pull」（または同様のもの）のようなsthgを期待できますか？ すべてのビルドを更新する必要があるわけではないため、YMLに配置するのが理にかなっているかもしれません（ローカルイメージを参照）。

cliに--pullを追加する代わりに（またはそれに加えて）、docker-composeファイルのサービス定義に何かを追加するのはどうですか？

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

このように、私が最新であることを気にしないサービスがあり、私が行っているサービスがある場合、docker-composeは私が興味のない画像をダウンロードする時間を無駄にしません

Kubernetesの本番クラスターで使用しているため、この機能を探してここに来ました。 タグは「imagePullPolicy」であり、「IfNotPresent」、「Always」、または「Never」に設定できます。 作成環境に似たものがあればいいのですが。

この場合、アプリケーションの最新の依存関係が更新されていることを確認するために、ベースイメージを毎日再構築する必要があります。 同じタグで最新のイメージをプルするためにDockerを作成するのは素晴らしい機能です。 なぜだめですか ！

これについて何かニュースはありますか？

やあ、

この問題に関するニュースはありますか？

+1

+1

前に述べたように、 docker-compose pull && docker-compose upは機能的に同じです。 別のフラグを追加する正当な理由はありません。

git fetch && git merge origin/masterは機能的に同一であるため、gitにpullがなかったと想像してください。

pull: trueタグを追加すると、たとえば、作成ファイルで使用する画像の一部がキャッシュにある場合に役立ちます。 docker-compose pullは、作成ファイル内の画像の_すべて_をプルします。これらの画像がキャッシュにあるがリポジトリにはない場合、そのプルは失敗します。

+1

docker-compose pull && docker-compose upが実用的でないシナリオの1つは、複数のdocker-composeファイルを使用している場合です。 docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml upようなコマンドで簡単に終わる可能性があります。

ローカルで開発し、リモートから一部の画像のみをプルしたいというシナリオがあります。 ローカルで開発されたもの（またはそれ以上）は、そのままにしておく必要があります。 その場合、docker-compose upを実行する前に、手動でイメージをビルド/プルする必要があります。
pull: trueが有益です。

@ shin-これについてのあなたの決定を再考するのはどうですか？ それらに対するコメントや反応は、十分に自己記述的であるように見えると思います。

いや、私は調子いいよ。 これはオープンソースプロジェクトです。機能を追加するときに私たちが採用する保守的なアプローチに同意できない場合は、フォークしてください。

docker-compose upコマンドにフラグを追加するか、構成にパラメーターを追加することに同意します。 開発プロセス中に頻繁に変更される傾向がある追加の構成を持つベースイメージを使用します。 開発者がデバッグする必要のないものをデバッグせずにdocker-composeを実行するだけの、誰にでもできる環境を作りたいと考えています。

同僚がプルリクエストをチェックしていて、ビルドが壊れたと言った後、実際にこのスレッドをヒットしました。 その理由は、ベースイメージにいくつかのパッケージがないだけでしたが、最終的なDockerfileで実行されたためです。 それは良い機能ですが、どうやらあなたが使ったものではないようです、@ shin-。

この機能を新しいバージョンで導入していただければ幸いです。

@ shin- @blockloopは、 git例で、プルオプションがいかに便利で便利かを示したと思います。 正直なところ、プロジェクトをフォークする必要がないことを願っています。

私は保守的なアプローチを完全に理解していますが、それはもはや選択肢として考えられていないように感じます。 多分それは次のバージョンの一部になることができますか？

pull: IfNotPresentがいいでしょう。 したがって、次のようなフォールバックを使用できる可能性があります
1）ローカル画像を使用する
2）ローカルでない場合はプル
3）引っ張ることができない場合は構築する

@ shin-あなたは&&メソッドがそれをカットしない理由を尋ね続けます、そして私の理由はこれです。 テスト用の「アプリ」イメージ（Puppet PDK / Onceover）に使用します。 作成ファイルはテンプレートリポジトリの一部であるため、puppet開発者（実際にはopsの人々）が新しいモジュールを作成する必要がある場合、そのリポジトリをフォークします。 Jenkinsは、そのモジュールリポジトリでマージ検証用のイメージを実行します（内部には、ジョブの更新を処理するjenkinsプラグインがあります）。これを使用する人々は、Dockerの専門家ではなく、&&を実行するように指示する必要があります。彼らが台無しにすることができる（そしておそらくそうするであろう）ステップ。 なぜそれが難しいのか、それがどのような不利益をもたらすのかはわかりませんが、この推論はそれを追加する価値のある理由のようです。 これは、開発者が必要な指示や手順が少ないものを送信するのに役立ちます。

それの不足は....怠惰から保護するために

より良い理由は次のとおりです。 &&は同期しています。 しかし、docker-composeには、このようなものを最適化する並列エグゼキューターの優れたサポートが組み込まれています。 docker-compose up --pull --buildは、すべてのイメージがプルされるのを待ってからビルドを開始する代わりに、イメージのビルドを開始し、プルされるとすぐに実行できます。

@shinは、Dockerfileを更新することはめったになく、ごくまれに自分で使用していると想定しています。
しかし、開発者が使用するDockerイメージを毎日更新する場合、1人の開発者が毎日行う必要のあるイメージをプルするのを忘れると、開発の問題が急速に発生します（特に、Dockerにあまり詳しくない人はそうです）。実際には、それを知って覚えておくのは彼らのビジネスではありません）。 災害プログラム。
このオプションをdocker-compose.ymlに追加するだけで大​​きな問題になりますか？
つまり、他のものを変更することはなく、機能を追加するだけです。 ..

これが、docker-composeを使用できず、従来のdocker runコマンドを使用してラッパースクリプトを作成する必要がある最大の理由ですが、それは醜いです。

このチケットがクローズされた状況を把握しようとしています-誰かが詳しく説明してくれませんか？ それが助けになるなら、私は--pullフラグをdocker-compose up追加することに賛成です。

ここで議論されている2つの提案があると思います。

1-これをコマンドラインオプションとして追加する必要がありますか？ 実際に投稿された問題。
2-このオプションをYMLファイルに追加する必要があります。

@shinは実際にはコメントしていませんが、

前者に関しては彼の主張は理解できますが、その論理的根拠は少し広すぎると思います。 一連のステートメントを&&チェーンすることにより、コマンドラインでほぼすべてのことを実行できます。 はっきりさせておきましょう。これらは1つではなく、2つのコマンドです。 基準は次のとおりです。2つではなく1つのステップで実行できるようにするために、これに対する十分な需要がありますか。 それが十分に頻繁に使用される場合、数連鎖コマンドは増え続けるからです。 重要なのは、スクリプトを作成するときは、できるだけ簡潔にする必要があるということです。

@orodbhenは議論する必要はありません。 ここでは誰も私たちの話を聞いていません。

フラグを追加する理由を追加するために...昨年かそこらの間に、私は自分自身がこのことを探していることに気づき、ここにたどり着きましたが、 --pullフラグ。 次回もここにいると思います。

@ shin-、この問題を再度開くか、ロックしてください。 それはほぼ2年間開いており、絶え間ない解説（インテリジェントで面白いものの両方）、数十人の参加者、そして数百の投票を受けています。
ただし、作曲チームがこの機能の追求に関心がないことは明らかです。 ですから、誰かの時間を無駄にしたり、そうでない場合に問題が復活するという誤った希望の余地を与えたりしないでください。

冒とく的な表現はご遠慮ください。

元のリクエストには有用性があると思いますが、このスレッドの多くの人はオープンソースの精神を忘れているようです。それがあなたにとってそれほど重要である場合は、自由にフォークして心ゆくまで変更できます。 私はあなたがフォークを維持したいない可能性があることを理解し、しかし、メンテナは機能を実装しないことに不満をすることは逆効果である：それは機能が実装され得る方法はありません、とメンテナが少ない、あなたを助けたいと思うようになります。

特に誰もその製品を使用するためにお金を払っていない場合は、機能の需要があるかどうかは実際には問題ではありません。 誰もが望むすべての機能をメイン製品に組み込むだけでなく、考慮すべきことがたくさんあります。 これに対する@ shin-の応答を尊重し、それを実装しない正当な理由があると信じる必要があります。

@lig議論する

必要に応じて、フォークはやり過ぎかもしれません。 私の特定のケースでは、非常に基本的なスクリプトでない限り、Composeはスクリプトにあまり適していないことがわかりました。 Docker Python APIと私自身のYAMLファイルを使用して設定を保持する方が、より用途が広く、多くの場合、より簡単です。

@ bdharrington7 —ただし、フォークを維持し、使用するすべてのマシンにインストールしておく必要があります（ほとんど不可能です）。 警告はDockerComposeが人気であり、他の人は「誰が気にしますか？」と言われるでしょう。

現実には、「オープンソースです。独自のフォークを作成してください」というコメントは現実的ではありません。 独自のフォークを維持し、メインリポジトリからの最新の変更で最新の状態に保つためのオーバーヘッドにより、投資する価値があることはめったにありません。 はるかに優れたアプローチは、メンテナに請願し、機能が重要である理由について適切な理由を提供することです。

悲しいことに、それは常にいくつかの不満を伴うこのような問題を引き起こします。 ここでの主な問題は、なぜこれが悪い考えであるかについて提起された適切なケースがなかったように思われることだと思います。 議論

「これに対する@ shin-の反応を尊重し、それを実装しない正当な理由があると信じるべきです。」

人々を満足させることはできません。 コミュニティは「正当な理由」を確認する必要があります。

拳を叩いて物乞いをすることはめったに起こらないという点が残っています
あなたが望むものを手に入れる際に、その多くはこのスレッドで起こっていました。
スレッドでも多くの優れたユースケースが取り上げられていますが、
しかし、実際にソフトウェアにお金を払っていない限り、義務はありません
メンテナからそれについて何かをするために、または理由を与えるために。 私
@ shin-と会社にここでの疑いの利益を与えるだけです。
5:39グレッグPakesで土、2018年3月24日に[email protected]書きました：

現実には、「オープンソースです。独自のフォークを作成してください」というコメントがあります。
現実的ではありません。 あなた自身のフォークを維持するオーバーヘッドと
メインリポジトリからの最新の変更で最新の状態に保つ
投資する価値はめったにありません。 はるかに良いアプローチは請願することです
メンテナは、機能がなぜであるかについて適切な理由を提供します
重要。

悲しいことに、それは常にこのような問題を引き起こすでしょう
不満。 ここでの主な問題は、
なぜこれが悪い考えであるかについて提唱された適切なケースでした。 NS
引数「これに対する@ shin- http：/// shin-の応答を尊重する必要があり
そして、それを実装しないのには正当な理由があると信じています。」
人々を満足させるつもりです。 コミュニティは「正当な理由」を確認する必要があります。

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

拳を叩いて物乞いをしても、欲しいものが手に入るということはめったにないというのがポイントです。

これは真実ではありません。 私はそれを自由な仕事をするように頼む戦略として容認しませんが、それは実際には非常に効果的です。 それはまさに請願がどのように機能するかであり、「こぶしを叩く」人が増えるほど、重要な人が注意を払う可能性が高くなります。 繰り返しますが、私はそれを承認すると言っているのではありません

スレッドでも多くの良いユースケースが取り上げられています

基本的に「代わりにこれらの2つのコマンドを実行できます」という1つのケースを見ることができます。 しかし、明らかに人々はそれを望んでいません。 ですから、彼らと関わり、なぜそれが良い回避策であるかについて彼らを教育してください。

メンテナからそれについて何かをする義務はなく、理由を説明することもありません

同意します。 しかし、あなたは人々がそれに不満を感じることを期待しなければなりません。 それは否定的な態度です。 結局のところ、ここにいる全員が同じチームに所属しています。 プロジェクトを管理する人々とプロジェクトのユーザーはすべて、プロジェクトの成功を望んでいます。

ここで正確に無料の製品はどれですか？ docker-compose.exeを使用してdockerEEを実行している場合、実際に製品の料金を支払っているという意味ではありませんか？

IMHO --buildはプルする必要があります。 他のフラグや構成は必要ありません。 プルしたくない場合は、イメージのバージョンを指定してください。

@ ET-CS：画像バージョンは単なるタグであり、別のハッシュに変更できます

良い点@lifeofguenterありがとうございます。 画像が別のハッシュに変更されたかどうかを確認し、その場合もプルできますか？

このようなシーンでは、開発者が新しいハッシュを使用し、本番環境が古いハッシュを使用するようになったため、すべての環境（dev、prod）に可能な限り同じイメージを持たせたいと思います。

--buildがすべてを最新のものにすることを期待しています。

だから、ここに良いユースケースがあります：

マイクロサービスプロジェクトにCIを実装しました。これは、バックエンドサービスで新しい機能を開発するときに、新しいイメージをレジストリにプルします。 フロントエンドチーム（Dockerについてほとんど知らない）は、ローカルマシンでバックエンドスタック全体を起動する方法を持っている必要があり、最新のイメージに依存しています。 何かが壊れた場合にのみ、彼らは画像を引っ張ることを覚えています。

これが起こったことです。誰かがバックエンドイメージを更新するのを忘れたため、開発スプリント全体が失敗し、古いバージョンに基づいて機能全体を開発しました。 フロントエンドチームのせいですが、これはこの機能で回避できます（ラッパースクリプトを使用して行います）。

@agnjunio本当に残念に聞こえます、ごめんなさい。 ただし、その人がdocker-compose pullを実行するのを忘れた場合、架空の--pullフラグの使用を忘れる可能性がどのように低くなるかわかりません。

@ shin-申し訳ありませんが、重要なことについて言及するのを忘れました。私の場合の解決策は、タグpull: alwaysをyaml内、おそらくimage:オプション内に配置することです。

@ ET-CS from https://github.com/docker/compose/issues/3574#issuecomment -382451356：

--buildがすべてを最新のものにすることを期待しています。

IMHO--buildはプルする必要があります。 他のフラグや構成は必要ありません。 プルしたくない場合は、イメージのバージョンを指定してください。

depends_onビルドの結果であるFROMを使用したビルドでユースケースをブロックするAFAIK。

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

https://github.com/docker/compose/issues/3574#issuecomment-252861859およびhttps://github.com/docker/compose/issues/3574#issuecomment-279460839で提案されているフラグに賛成です

@solsson
このユースケースでブロックされている理由や内容がわかりません。
可能であれば、それについての詳細を共有してください。

@ shin-ここでの違いは、 docker-compose up --helpを実行すると、：latestイメージの使用方法を説明する方法が表示されることです。代わりに、最近はドキュメントまたはGoogleで検索する必要があります。このスレッドと私はdocker-compose upが私が必要とする/望むことをしないことを理解するためにすべてのコメントを読む必要があるので、今私は2つのコマンドを実行する必要があります。

@agnjunio本当に残念に聞こえます、ごめんなさい。 ただし、その人がdocker-compose pullを実行するのを忘れた場合、仮想の--pullフラグの使用を忘れる可能性がどのように低くなるかわかりません。

心から

docker-composeを使用する主な理由の1つは、 docker-compose.yamlファイルをリポジトリに配置し、開発者がリポジトリをプルしてdocker-compose up [service]を実行したときに再現可能な出力を持つ機能です。

docker-composeファイル内でいくつかのサービスを使用して、codegenの実行やツールの実行などのタスクを実行し、JSONスキーマを単一のファイルに逆参照します。
これらのツールが最新であることを確認することは、特にcodegenイメージを更新して、すべてのプロジェクトで見られる一般的な重大な問題を修正する場合に重要です。

配置する能力を持っている：

services:
  codegen:
    image: myimage:latest
    pull: Always

アプリを起動する前に一連のコマンドまたはスクリプトを実行して最新の利用可能なイメージをプルするように開発者に通知するドキュメントですべてのリポジトリを補足する必要はなく、開発者にdocker-composeを確実に実行させて期待される結果を得る能力を保持します。

「これらのコマンドを実行してこれを行う機能はすでに存在する」ということではなく、より優れたユーザーエクスペリエンスです。

誰かが--stopをdocker-compose rm追加することを提案したとき、答えは「 docker-compose stop myapp && docker-compose rm myapp何が問題なのか、または誰かがdocker-compose downの実装を要求した場合、彼らはただだった」と想像してみてください。なぜdocker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ...実用的でないのかと尋ねられました。

このスレッドは2年前に作成されましたが、docker-compose.ymlにフラグを追加するのが最善の方法だと思いました。 私の場合、群れの中に37のサービスがあり、その合計から4〜5の画像を更新するのは簡単ではありません。 今のところ、リポジトリからの変更を監視し、サービスが更新されている場合はサービスを再作成する前に特定のイメージのプルを実行できるシェルを作成しました。

ここでのもう1つのポイントは、 docker-compose upには--quiet-pullオプションがあるということです。 upにプルが含まれているかどうかを最初に把握しようとしたとき、その存在に基づいてプルが含まれていると思いました。 --quiet-pullを使用しないと、冗長なプルが発生するのは当然のことです。

Docker Composeのメンテナーに、別のコマンドを実行しなくても--pullオプションを使用する方が良い経験になると説得しようとした2年間の人々。 docker-composeメンテナがこの機能を実装したばかりの場合、そもそも、すべての人の生活が良くなるでしょう。 現在のメンテナがコミュニティの改善のためにこの機能を追加したくないことは明らかなようです。

たぶん、docker-composeを自分でフォークして更新する必要があります。

誰かがPRを提出した場合、それが受け入れられればチャンスはありますか？
これはオープンソースです。 私はそれをいくつか実装することを検討してきました
自分自身を回します。 私はそれが受け入れられる可能性があると思います、さもなければこの役割は閉じられます、
右？

私はこれと同じ問題と聖なるがらくた、ここでたくさんの泣き言に出くわしました。 これは無料のオープンソースソフトウェアです。 メンテナに休憩を与えます。 彼らにはこれよりもはるかに重要な取り組みがあると確信しています。 誰かがこれをひどく必要としているなら、PRを開いてみませんか？ コードが最小限のリスクでクリーンである場合、なぜ彼らがそれを受け入れないのかわかりません。

議論にはこの要求を実行しない正当な理由がないため、この問題を再度開く必要があります。 人々は、閉じた問題よりも_開いた_問題に取り組み始める可能性が高くなります。

この「クローズド」問題が非常に活発なままであるという事実は、それがうまく処理されていないことを示唆しています。

残念ながら、一部のGitHubリポジトリで投稿を発行するための応答はあまり役に立たないことがわかりました。 口調はしばしば簡潔であり、フィードバックが歓迎されていないことを示唆しています。

これはオープンソースプロジェクトであり、（少なくとも私たちのほとんどは）顧客にお金を払っていないという指摘もあります。 ただし、問題の解決に参加する場合は、問題レポートの送信に多大な時間の投資が必要になることにも注意してください。

問題のトラブルシューティングに時間を費やし、回避策を見つけたユーザーまたは開発者は、問題を報告するためにさらに時間を費やすかどうかを決定します。 メンテナからの受け入れがたい反応は、次回は気にしないことを選択する結果になる可能性があります。

このソフトウェアは、「無料のビール」という意味では、実際には「無料」ではありません。 私たちは皆、それをより良くすることに参加しようとしているので。 ソフトウェアをテストしてフィードバックを提供してくれる人がいることは、貴重なリソースです。 必要なプログラミングスキルを持っている人は、コードを提供することさえ喜んでいますが、彼らはそれに時間を費やす前に、彼らの貢献が歓迎されているという何らかの兆候を望んでいます。

明らかに、単に問題について不平を言い、それを修正することを要求するコメントは役に立ちませんが、大多数はそれをしていません、そして「それはオープンソースです、ただそれをフォークしてください」のようなコメントも同様に役に立たないです。

@ shin-なぜ「--build」が実装されたのですか？ docker-compose build && docker-compose upとは異なりますか？ --build（追加された）と--pull（冗長と見なされた）の哲学的な違いを理解しようとしているだけです。 思考プロセスを理解することは、物事がどのように機能するかを思い出すのに役立つかもしれません。 また、問題が発生した場合は、PRを送信させていただきます。 @everybodyelse ...何かが気に入らない場合にフォークするのは、本当に「オープンソースの精神」ですか？ オープンソースの精神は、「何かが気に入らない場合は、a）必要に応じて貢献すること、b）可能であればコードに貢献すること」であり、要件が非常に高い場合にのみフォークすることだと思いました。明らかにあなただけが恩恵を受ける何か。 つまり、共有するときに最もメリットがあると思いましたが、ここで教育を受けられてうれしいです。

2年間主張した後、無視される正当な理由と、これを実際に実装するための多大なコミュニティのサポートを与えて、@ shin-が望んでいないという理由だけでこの機能は機能しないと思います。 主張し続ける理由はありません。

1つの理由があります。1つのプルが失敗した場合、dockerはイメージを更新せず、それを行わない正当な理由はありません。

dockercomposeでkubernetesイメージプルポリシーを探しています。「プル」を使用できると便利です。

@ shin-子供っぽくなるのをやめなさい。 この機能を実装する理由はたくさんあります。 少なくともPRにオープンである...

あなたは私に反対することができますが、@ Wenzilという人身攻撃に訴えることに失望しています。 私たちのコミュニティは一般的に、より高い水準を維持しています。

@ shin-私たちのコミュニティは、あなたが言及した理由のために、それを言わないままにしておくこととほとんど同じだと考えています。 @Wenzilはそれを大声で言うのに十分正直です。
私が知っている多くの人々は、わざわざ気にしないことを好み、docker-composeをユーザーに向けて動かすよう説得しようとすることをあきらめました。

説明されている非常に正当な理由で、多くの人が@ shin-に同意しません。 少なくとも、これはサービス宣言である必要があります。 bashコマンドをつなぎ合わせるのは、プログラムによる展開には特に適したソリューションではありません。

私が知っている多くの人々は、わざわざ気にしないことを好み、docker-composeをユーザーに向けて動かすよう説得しようとすることをあきらめました。

この。 そして、それはdocker-composeだけではありません。 Docker-stack、docker-machine、docker-cliはすべて似ています。

https://github.com/docker/compose/issues/6316#issuecomment -438564025

これが脱線し続けるのでロックします。 https://github.com/docker/cli/pull/1498の運命に応じて再評価し

更新として、サービス定義にpull_policyパラメーターを追加することを検討することを社内で決定しました。 オプションと正確な構文がどうなるかを理解する必要がありますが、このスレッドで表現されているニーズを満たすことを願っています。