Moby: 新機能のリクエスト：Dockerfileの特定のRUNコマンドのキャッシュを選択的に無効にする

これに対抗する方法は、キャッシュしたいDockerfileのポイントを取得し、それを将来のDockerfileのFROMで使用するイメージとしてタグ付けし、 -no-cacheビルドできるようにすることだと思います。ベースイメージは再構築されないため、結果なしで

しかし、これにより、キャッシュされたコマンドとキャッシュされていないコマンドのインターリーブが簡単に制限されませんか？

たとえば、サーバーからリポジトリとwgetファイルを更新し、その間に一連の手順を実行したいとします。たとえば、リポジトリからソフトウェアをインストールします（更新された可能性があります）。ダウンロードしたファイルに対して操作を実行します（サーバー）など。

理想的なのは、Dockerfileでdockerを指定して、毎回キャッシュなしで特定のコマンドを実行し、変更がない場合（たとえば、リポジトリの更新がない場合）に前のイメージのみを再利用する方法です。

これは持っていると便利ではないでしょうか？

DockerfileのCACHEONとCACHEOFFはどうですか？ 各命令は後続のコマンドに影響します。

ええ、Dockerfileでgit cloneコマンドを使用しています。更新を使用して再クローンを作成する場合は、行の最後にコメントを追加して、そこから再構築をトリガーする必要があります。ライン。 このステップでは、まったく新しいベースコンテナを作成する必要はありません。

コンテナIDを「このIDを超えてキャッシュしない」命令として「dockerbuild」に渡すことはできますか？ 'docker build'がDockerfileの変更された行までのすべてのステップをキャッシュする方法と同様ですか？

ビルドキャッシュをより強力かつきめ細かく制御する必要があることに同意します。 現在、これをユーザーに公開する方法が正確にはわかりません。

これは、今後のAPI拡張機能、特に名前付けとイントロスペクションによって簡単になると思います。

素晴らしい機能になります。 現在、私はRUN a=a some-commandようなばかげたものを使用していて、次にRUN a=b some-commandを使用してキャッシュを壊しています

キャッシュをより適切に制御できるようになると、CIのDockerを使用するのが非常に楽しくなります。

@shykes

--no-cacheをboolからstringに変更し、Dockerのどこでキャッシュを無効にしたいのかを正規表現で表すのはどうでしょうか。

docker build --no-cache "apt-get install" .

私は同意し、IRCでこの正確な機能を提案しました。

下位互換性を維持するために、新しいフラグ（たとえば、「-uncache」）を作成して、「-uncache。*」に解決される（非推奨の）boolフラグとして--cachedを保持できるようにする必要があります。

9:17で金、2014年2月7日には、マイケル・クロスビー[email protected]
書きました：

@shykes
--no-cacheをboolからstringに変更し、Dockerのどこでキャッシュを無効にしたいのかを正規表現で表すのはどうでしょうか。

docker build --no-cache "apt-get install" .

このメールに直接返信するか、GitHubで表示してください。
https://github.com/dotcloud/docker/issues/1996#issuecomment -34474686

他のみんなはこれについてどう思いますか？ この機能を実装する人はいますか？

他に誰も始めていないのなら、私は今日これを実装することに挑戦するつもりですか？

私はそれに取り組み始めました-アプローチが良さそうだと検証したかったのです。

• noCacheのフィールドbuildfileなり*regexp.Regexp 。
  
  
  
  • そこにあるnil値は、 utilizeCache = true以前に使用したものを意味します。
  
  
• 文字列をdocker build --no-cache渡すと、検証正規表現文字列がサーバーに送信されるようになりました。
• --no-cache呼び出すだけで、デフォルトの.*
• 次に、正規表現を新しいメソッドbuildfile.utilizeCache(cmd []string) bool使用して、キャッシュを無視するコマンドをチェックします

1つ：私が見る限り、flag / mflagパッケージは値のない文字列フラグをサポートしていないため、 --no-cacheと--no-cache some-regex両方をサポートするために追加の調整を行う必要があります。

これは別の新しい旗であるべきだと私は本当に思います。 --no-cacheの動作と構文はすでに明確に定義されており、多くの異なる人々によって多くの場所で使用されています。 私は--break-cacheまたはそれに類似したものに投票し、 --no-cache今日とまったく同じように実行させます（これは多くの人が信頼し、今でも望んでいる非常に便利な動作だからです）。

とにかく、IANTM（私はメンテナではありません）なので、これらは私の個人的な考えです。 :)

@tianon --no-cacheは現在ブール値であるため、これは単に既存の動作を拡張するものです。

• docker build --no-cache -以前と同じ動作：キャッシュを無視します
• docker build --no-cache someRegex - someRegex一致するRUNまたはADDコマンドを無視します

そうです、それはすべて大丈夫です。 問題は、 --no-cacheがブール値であるため、既存の動作は実際には次のようになることです。

• --no-cache=true -キャッシュを明示的に無効にする
• --no-cache=false -キャッシュを明示的に有効にする
• --no-cache - --no-cache=true省略形

また、これを解決するために「true」と「false」の特殊な正規表現文字列を作成することで、自分自身を不幸にすることになると思います。これは、将来、ユーザーに驚くべき動作を引き起こす可能性があるためです。 （「 --no-cacheを「true」または「false」のいずれかの正規表現で使用すると、想定どおりに機能しません！」）

@tianonはい、その通りです。 持っていた迅速な表情をし、人々は=真/偽のを使用しています。

あなたが提案するように新しいフラグを追加するためにPRを変更して幸せです、メンテナはどう思いますか（ @ crosbymichael 、@ shykes）？ これは、文字列/ブールフラグを許可するためにmflagに追加されたコードを削除できることも意味します。

@wagerlabsアプローチの+1

@ crosbymichael 、 @ timruffles Dockerfileの作成者が、キャッシュするビルドステップとキャッシュしないビルドステップを決定した方がよいのではないでしょうか。 Dockerfileを作成する人は、必ずしもイメージを作成する人と同じではありません。 決定をdockerbuildコマンドに移すには、特定のDockerfileを使用したい人からの詳細な知識が必要です。

誰かが既存のイメージ階層を再構築していくつかの依存関係を更新したいという企業環境を考えてみてください。 既存のDockerfileツリーは、何年も前に他の誰かによって作成された可能性があります。

@wagerlabsアプローチの+1

@wagerlabsアプローチの場合は+1ですが、時間間隔でバストをキャッシュする方法があればさらに

CACHE [interval | OFF]
RUN apt-get update
CACHE ON

これは、コンテナーが非決定論的であるという考えに反する可能性があることを理解していますが、パイプラインが優れた自動テストを備えている継続的デプロイのシナリオで実行したいのはまさにそのようなことです。

回避策として、現在、docker buildを実行するために使用するスクリプトでキャッシュバスターを生成し、それらをdockerfileに追加して、キャッシュバストを強制しています。

FROM ubuntu:13.10
ADD ./files/cachebusters/per-day /root/cachebuster
...
ADD ./files/cachebusters/per-build /root/cachebuster
RUN git clone [email protected]:cressie176/my-project.git /root/my-project

継続的インテグレーションにコンテナーを使用することを検討しています。キャッシュ内の特定の要素にタイムアウトを設定する機能は非常に価値があります。 これがないと、デプロイできません。 毎回完全な再構築を強制するのは遅すぎます。

これを回避する現在の計画は、 RUN echo 2014-04-17-00:15:00などのコマンドを動的に挿入し、生成された行を最後の15分に切り捨てて、丸められた数値がジャンプしたときにキャッシュ要素を無効にすることです。 15分ごとにアラ。 毎回dockerfileを生成するスクリプトがあるので、これはうまくいきますが、そのスクリプトがないと機能しません。

機能の+1。

この機能にも投票したいと思います。 マスターブランチでのみ更新されるgitリポジトリからコンテナの一部を構築する場合、キャッシュは煩わしいものです。
：+1：

@hiroprotagonist持つgit pullあなたにENTRYPOINTかもしれないのヘルプ？

@ amarnus @ tfooteが持っていたアイデアと同じように解決しました。 jenkinsジョブからビルドを実行していますが、docker buildコマンドを直接実行する代わりに、ジョブはビルドスクリプトを開始し、テンプレートからDockerfileを生成し、gitコマンドの上に「RUNechocurrentsMillies」という行を追加します。 sedとpipesのおかげで、これはほんの数分でした。 とにかく、私はまだDockerfile自体の一部としてこの機能を好みます。

@wagerlabsアプローチに+1を追加します。 CIでもこの問題が発生します。 とりあえず動的エコーRUNステートメントを使用しているだけですが、この機能が気に入っています。

CACHE ON / OFFの場合は+1。 私のユースケースはCI自動化でもあります。

+1、特に@ cressie176の例のように実行コマンドのキャッシュ間隔を設定する機能

「たとえば、リポジトリの更新やリモートファイルのダウンロード」

+1

それが誰かを助けるなら、これが私のJenkinsビルドで使用しているコードの一部です：

echo "Using build $BUILD_NUMBER for docker cachebusting"
sed -i s/cachebust_[0-9]*/cachebust_"$BUILD_NUMBER"/g Dockerfile

CACHE ON / OFFの+1

CACHE ON / OFFアプローチの可能な代替手段として、「ALWAYS」のような追加のキーワードはどうでしょうか。 このキーワードは、既存のコマンド（「ALWAYSRUN」や「ALWAYSADD」など）と組み合わせて使用​​されます。 設計上、「ALWAYS」キーワードは隣接するコマンドを完了するためにキャッシュに移動しません。 ただし、結果をCACHE（同じ行が実行された他の時間のキャッシュを暗黙的に）と比較し、ALWAYSコマンドの結果が変更されていない場合はキャッシュされたイメージにリンクします。

根本的な必要性は、 「べき

また、ALWAYSやCACHE 1 WEEKADDなどのコマンドのプレフィックスも必要です...

それで、私はしばらくの間この問題に苦労していました、そして私はこれが整理されている間それが役立つ場合に備えて私の仕事を共有したかっただけです。 Dockerファイルの外部にビルド呼び出しに何かを追加したり、毎回ファイルを変更したりしたくありませんでした。 とにかくこれはばかげた例ですが、追加メカニズムを使用してキャッシュを無効にし、ファイル操作を必要としません。

From ubuntu:14.04

RUN apt-get -yqq update
RUN apt-get -yqq install git
RUN git clone https://github.com/coreos/fleet
ADD http://www.random.org/strings/?num=10&len=8&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new uuid
RUN cd fleet && git pull

明らかに、独自のユースケースとネットワークランダム生成を選択できます。 とにかく多分それはidkから何人かの人々を助けるでしょう。

@wagerlabsアプローチのもう1つの+1

機能への別の+1。 一方、 @ cruisibesarescondevの回避策を使用します。

機能リクエストに対してもう1つ+1。 回避策を提供してくれたます

機能の別の+1。

回避策については@cruisibesarescondevに乾杯します。

ALWAYSキーワードは、特に単純で明確なセマンティクスを備えているため、優れたアプローチだと思います。 もう少し複雑なアプローチは、最小時間を追加することです（ビルドファームや継続的インテグレーションなどで役立ちます）。 そのために、XXXがタイムアウトである構文「EVERYXXX」を提案します。 また、そのコマンドのキャッシュが作成されてからXXXより長い場合は、コマンドを再実行する必要があります。 そして、出力が変更されたかどうかを確認します。 変更がない場合は、キャッシュされた結果を再利用し、最後に更新された時刻を記録します。 これは、すべての0が常に同じになることを意味します。

現時点での回避策として、Pythonでempyテンプレートを使用してDockerfileを生成し、次のスニペットを埋め込みます。ただし、2回の連続実行で同じ結果は検出されませんが、XXX秒ごとに再トリガーが強制されます。 頂点で：

@{
import time
def cache_buster(seconds):
    ts = time.time()
    return ts - ts % seconds
}@

再実行を強制したい場所：

RUN echo @(cache_buster(60))

Dockerfileでは次のようになります

RUN echo 1407705360.0

ご覧のとおり、60に最も近い値に丸められるため、60秒が経過するたびに、次の実行で後続のすべてのコマンドが再実行されます。

ALWAYS構文の場合は+1。 +.5 CACHE ON / CACHEOFFの場合。

ALWAYS構文の場合は+1。

はい、常に構文は非常に直感的に見えます。

行は「自己完結型」である必要があり、Dockerfilesにブロックを追加すると、多くの「問題」が発生するため、CACHE ON / OFFは好きではありません（マージ時に「この行はキャッシュでカバーされていますか？」 。）。

@kuon USERやWORKDIRなど、後続の命令に影響を与えるコマンドはすでに多数あると思います

ええ、それは本当ですが、私は同じ理由でそれらを使用しません。 私はいつもRUN cd ... &&またはRUN su -c ...&&ます。

私はブロック表記を好みます：

CACHE OFF {
    RUN ...
}

これはより明確であり、 CACHE OFF行が誤って挿入されることを回避します（構文エラーが発生します）。

私はそれを考えすぎているかもしれませんが、Dockerfilesは実際には本番環境で実行されていないため（イメージをビルドするときだけ）、ビルド時にキャッシュを無効にしても実際にはそれほど害はありません。 しかし、Dockerfilesは本当に制限されていると感じています（膨大な数の画像を作成したり、変数を使用できなくなったりしないように、1回の実行ですべてのコマンドを&&でチェーンする必要があります...）。

たぶん、この問題は新しいDockerfile形式の機会です。

今言ったことに戻りたいと思います。 @shykesが別の問題https://github.com/docker/docker/pull/2266で言ったことを読み、彼にも同意します（Dockerfileは言語のような本当に単純なアセンブリである必要があります）。

変数などが欲しいと言いましたが、それは他の言語でカバーできますが、この場合、Dockerfileの各行は自己完結型である必要があります。例：

NOIMAGE ALWAYS RUN USER:jon  apt-get update

これは常にコマンド（キャッシュなし）を実行しますが、イメージを作成してユーザーjonを使用することもありません。

この種の自己完結型の行は、他の言語から生成するのがはるかに簡単です。 コンテキスト（ユーザー、キャッシュ、workdir）について心配する必要がある場合は、エラーが発生しやすくなります。

簡単にするためにRUN!でいいですか？

これに関するステータスの更新はありますか？

キャッシュを選択的に無効にすると非常に便利です。 （アマゾンAWSツールキットから）awscliコマンドを使用してリモートのアマゾンs3リポジトリからファイルを取得しますが、ADDコマンドを使用してキャッシュを無効にする簡単な方法はありません（少なくとも、Dockerfileを編集せずに方法を考えることはできません）トリガーする）。 RUNを使用するときに、キャッシュを選択的に無効にするために、ユーザーに制御が戻されるという強力なケースがあると思います。 誰かが私に提案を持っているなら、私はあなたから聞いてうれしいです。

この問題は私たちが非常に必要としているものなので、少し上げたかったのです。

ALWAYS構文が理想的な構文であるとまだ確信しています。

単純なBREAKステートメントはどうですか。

@ cpuguy83は、私の特定のユースケースでも機能します。

1つのコマンドだけをキャッシュせず、残りのコマンドをキャッシュすることが技術的に可能かどうかはわかりません。 dockerは増分差分に基づいているため、おそらくそうではありません。

BREAKをサポートすると、@ CheRuisiBesaresの提案に基づいて、現在の回避策と同等の機能が得られます。

私の以前の投稿に関しては、スクリプトのその時点からキャッシュを無効にするだけで十分であり、残りはインテリジェントなスクリプト設計になります（これでほとんどの人の要件に対応できると思います）。 キャッシュバストを選択的に無効にする代わりに、これは実行可能ですか？

@orreryビルドステップの前にCOPY追加することで、おそらくキャッシュを「破壊」することができます。 コピーされたファイルが異なる場合、それ以降のすべてのステップでキャッシュを使用しなくなります（このセクションを参照）。 汚いトリックですが、あなたのケースを解決するかもしれません。

ALWAYS （またはEVERY # DAYSような同様の概念）の鍵は、添付されたコマンドの後のキャッシュ比較です。 私自身（そして私は他の多くの人を想定しています）にとって、目標はキャッシュ自体を破壊することではありません。

• 目標は、コマンドの結果（つまり、「最新バージョンへのアップグレード」）が変更された場合に、キャッシュの使用を確実に停止することです。
• 結果はキャッシュされたバージョンと一致した場合にこれとは対照的に、我々はキャッシュを利用したいと

ALWAYSの出力がキャッシュされたバージョンと一致する場合にのみ、後続のコマンドにキャッシュを利用できるため、これは@hellaisによるコメントに

当然、同じロジックをCACHE ON / OFFモデルに含めることができます。 キャッシュとの比較は、後続のすべてのコマンドを再実行するよりも安価である可能性がありますが、それでもコストがかかる可能性があります。 CACHE ON / OFFブロックがユーザーにOFFブロックに追加のコマンドを含めるように促した場合（ ALWAYSでは発生しないこと）、パフォーマンスに大きな違いが生じる可能性があります。

@tfooteとまったく同じ状況にあります

EVERY構文の場合ALWAYS構文も仕事を成し遂げるでしょう。

@claytondaleyそれは素晴らしいポイントです。 ただし、コマンドのキャッシュを完全に無効にする機能を持つことは依然として重要です。 Dockerには本質的に見えない隠された状態が常に存在します。 たとえば、コマンドを実行すると、リモートサーバーの状態が変わる場合があります。

@mkoval 、あなたはALWAYSを使用する重要な時間として、 _created _隠し状態について良い点を挙げていますが、それがキャッシュの再開に関する私のロジックに影響を与えるとは思いません。 例を具体的にするために（多少些細な場合）、サードパーティシステムをアップグレードするコマンド：

• 非表示の状態を作成し（ ALWAYS実行する必要があります）、
• 現在のコンテナを変更しません

次のコマンドに非表示の状態が含まれていない場合（自明なことに、コンテナーに対するmvコマンド）、キャッシュは100％信頼できます。 同じコンテナ、同じコマンド、隠された情報への依存なし。

次のコマンド（または後続のコマンド）に非表示の情報が含まれる場合は、 ALWAYSキーワードを使用し、結果のコンテナーがキャッシュと一致する場合にのみキャッシュを再開する必要があります。

@claytondaleyあなたのソリューションは、私には非常にエレガントで効率的だと

ALWAYSおよびEVERYX推奨構文を使用したこの機能の+1。 CACHE ON / OFFは少し不器用ですが、使用します。 また、可能であればキャッシュを再開するという@claytondaleyの提案も本当に気に入っています。

ALWAYS構文の場合は+1。 特にgitリポジトリからのプルコードの場合。

+1これらのソリューションのいずれか。

私は少し混乱しています。 キャッシュをオフにした後、どのようにしてキャッシュをオンに戻すことができますか？ オフにしてコンテナに何らかの変更を加えたら、基本的にキャッシュをオンに戻すと、キャッシュがオフになっているときに実行されたDockerfileコマンドによって行われた変更が破棄されませんか？ キャッシングを実行できる理由は、実行された以前のコマンドの完全なリストを正確に知っていて、コンテナー内にあるものがまったく同じであることを保証できるためだと思いました。 キャッシングをオフにした場合（そして私はそれのルックアップ側について話している）、それはその保証を吹き飛ばしませんか？ それとも、これはキャッシュにデータを入力しないことについてですか？

提案についての私の理解は、Dockerfileコマンドの一部として「ALWAYS」を指定して、常にステップを再実行できるということです。 たとえば、「RUN ALWAYS git clone https://example.com/myrepo.git 」は常に実行されます（これにより、常にリポジトリのクローンが作成されます）。 次に、 @ claytondaleyが示唆しているのは、このコマンドを再度実行した後、Dockerがキャッシュに対して変更をチェックすることです。 チェックサムが同じである場合（つまり、複製されたリポジトリに変更がないため、最新のレイヤーがキャッシュ内の同じレイヤーと同一である場合）、キャッシュをオンにして続行できます。 キャッシュが無効になると、それ以降のすべてのステップでキャッシュを使用できなくなります。 これらの提案は、キャッシュをいつ使用するかをより細かく制御できるようにするだけでなく、可能な場合はキャッシュから再開することについても賢明です。

@curtiszimmerman ...正確に

@duglin ...数学的プロキシを使用すると、このアイデアはより明白になる可能性があります。 （この文脈で）キャッシュの結果のメモリだけでaction Bに適用されたときにstate Aあなたはそれを再処理する必要はありません。 一連のコマンドを実行するとします。

• 6始まります
• 常に* x実行します。ここで、 xの値はgitリポジトリからダウンロードされます（したがって、変更される可能性があります）
• + 12実行します

コマンドを初めて実行するとき、 xは8なので、次のシーケンスを取得（およびキャッシュ）します。

• 6
• 48 （ * xが6適用された結果）
• 60 （ + 12が48適用された結果）

私のマシンが再び（任意のシーケンスで）状態48到達し、コマンド+ 12が与えられた場合、処理を再度実行する必要はありません。 私のキャッシュは、このコマンドの結果が60ことを認識しています。

難しいのは、同じ状態（ 48 ）に戻ったときを把握することです。

• 理論的には、すべてのコマンドの後でマシンを他のすべてのキャッシュイメージと比較できますが、これはリソースを大量に消費し、一致するものを見つける可能性は非常に低くなります。
• 私の提案はそれをシンプルに保つことです。 ある状態（例： 6 ）にあり、コマンド（例： * x ）を押すたびに、同じ状態にあった前回（または複数回）の結果をキャッシュと比較します。同じコマンドを実行します。 このプロセス後のマシンの状態が同じである場合（たとえば、 48 ）、キャッシュを再開します。 次のコマンドがまだ+ 12場合、結果を処理するのではなく、キャッシュから取得します。

@claytondaleyですが、現在の状態をどのように判断するのかわかりません。 おっしゃるように、コンテナ内のすべてのファイルを比較しているわけではありません。 キャッシュが現在機能する方法は、基本的に、現在のコンテナのすべての既知の子コンテナに対して実行する次のコマンドをstrcmpすることです。 フロー内のコンテナをスキップした瞬間、現在のコンテナが、ファイルシステム内のすべてのファイルをチェックしない他のキャッシュされたコンテナと同じであると想定できる方法がわかりません。 しかし、おそらく私はあなたがしていることを理解していません。

言い換えると、ランダムなコンテナ（キャッシュを使用していない場合は基本的にこれがあります）が与えられた場合、キャッシュ内のすべてのファイルを比較せずに、それに一致するコンテナをどのように見つけることができますか？容器？

@claytondaley @duglin説明したように、変更がないために「キャッシュなし」操作をキャッシュできるかどうかを判断するのは難しい問題です。 また、厳密に必要というよりも、持っているほうがいいです。

個人的には、コマンドが常に実行されるようにする機能だけがあれば幸いです。 次のようなDockerfileを取得します。

RUN install_stuff_take_forever
RUN always_do_it   #will not run every time
RUN more_stuff

現在、 always_do_it行は、テキストを編集してキャッシュバストを強制しない限り、初めて実行されます。 私たちのほとんどは、 more_stuffが不必要に実行されることがあることを喜んで受け入れると思います（ always_do_itが変更されていない場合、代わりにinstall_stuff_take_foreverキャッシュを保持できます。

RUN install_stuff_take_forever
NOCACHE
RUN always_do_it
RUN more_stuff

@pikeas私は完全にNOCACHEコマンドを取得し、それは簡単に実行できます。 私が得られないのは、ファイルシステム全体の差分/ハッシュ/何でもせずにそれを元に戻すコマンドです。

Dockerの「レイヤー」の説明を読んで、次のことを意味します。

• Dockerは、コマンドごとに「レイヤー」を作成します。
• そのレイヤーには、そのコマンドによって変更された（または変更されたか変更されていないかにかかわらず「保存」された）ファイルのみが含まれます。
• ファイルシステムの現在の状態は、その特定のファイルの（最新の更新された）バージョンが見つかるまで各レイヤーを順番にチェックすることによって論理的に（操作上ではない場合）達成されます。

この場合、同じコマンドの2つのインスタンスの比較は比較的安価です。 最上位のレイヤーを比較するだけで済みます（すべての基礎となるレイヤーが共有されているため）。 コマンドによって変更されたファイルの特定のリストがあります。 それらのファイルのみがレイヤーに含まれます。 確かに...そのレイヤー内のすべてのファイルを比較する必要があります...ただし、ファイルシステム全体を比較する必要はありません。

（網羅的であるとは限りませんが）新しいレイヤーをコマンドが最後に実行されたときとのみ比較することも可能です。

• ほとんどの場合（git pullまたはソフトウェアアップグレード）、現在のバージョンは（1）前のバージョンと同じか、（2）新しいバージョンのいずれかになります...ただし、少なくともまれに、以前のバージョンにロールバックすることはありません。バージョン。
• まれに（dev-masterにアップグレードしてから安定バージョンに戻すなど）、古いバージョンに戻すことができます。 ただし、これらは非常にまれであるため、ほとんどの場合、（頻繁に）最新バージョンのみをチェックし、まれにロールバックを実行するコマンドを再実行する方がよいでしょう。

もちろん、以前のすべてのバージョンでハッシュチェックを実行してから、完全なファイルチェックを実行して、オーバーヘッドなしで完全なサポートを提供することもできます。

https://github.com/docker/docker/pull/9934の下部を見ると、Dockerfileコマンドのサポートオプションに関する説明が表示されます。 このコマンドに「キャッシュを使用しない」ことを意味する--no-cacheオプションがすべて（または単にRUN）で使用可能であった場合はどうなりますか？ 例えば：
RUN --no-cache apt-get install -y my-favorite-tool
これにより、残りのコマンドのキャッシュも自動的に無効になります（私は思います）。
これで問題は解決しますか？

意味的に同一である「RUNALWAYS」と「RUN--no-cache」の間では、個人的にはより自然に見える「RUNALWAYS」構文を好みます。 そのPRに関する最後のコメントに同意します。--optionは読みやすさを損ない、Dockerfilesを醜くするだろうと思います。 さらに、Dockerfileコマンドは、それに続く実際のコマンドとは非常に区別する必要があると思います。 「RUN--no-cachemyapp --enable-cache」のような複雑な構文の例を想像してみてください。このようなオプションを使用すると、すぐに表現できるようになります。

@curtiszimmermanあなたの例は私には非常に明確です。 --no-cacheはRUN用で、-enable-cacheはmyapp用です。 配置が重要です。 たとえば、次を見てください。
docker run -ti ubuntu ls -la
人々は、-tiが「run」を表し、「-la」が「ls」を表すことを理解しています。 これは、人々が慣れているように見える構文です。
RUN ALWAYSのようなものの問題の1つは、拡張性です。 すべてのDockerfileコマンドで機能し、値の受け渡しをサポートできる構文が必要です。 たとえば、人々は特定のコマンドにUSERを指定することに関心を示しています。
RUN USER = foo myapp
技術的には、myappのシェル内でenv varUSERを「foo」に設定しています。 したがって、ここではあいまいです。
一方：RUN --user = foomyappにはこの問題はありません。
は：RUN var = foo myapp
'var'と呼ばれるenvvarを設定しようとしていますか、それともRUNオプションを取得しようとしているタイプミスですか？
IOW、既存の有効なコマンドであるIMOと重複する可能性は、最初に単語を許可するよりもはるかに少なくなります。

私は実際には逆のシーケンスEVERY <options> COMMAND提唱しています。 いくつかの理由：

• 「ユーザー」と「キャッシュ」の場合（少なくとも）、これらは実際には任意のコマンドをラップできる環境特性です（ただし、他のコマンドに実質的な影響を与えることはありません）。
• 構文RUN ALWAYSは、 RUNコマンドインタープリターを変更することを意味しますが、これは不要に聞こえます。
• RUN EVERY 5 daysと、すべてに付加されたオプションによってさらにあいまいさが生じるため、この問題はさらに悪化します。 EVERY 5 days RUNは、オプションが影響するコマンドについて明確です。 RUN USER usrとUSER usr RUN同じ問題が発生します。 （1）コマンドキーワードが決してオプションではないか、（2）それらを回避する簡単な方法がある限り、これは明白です。

コマンドの前にオプション（ ALWAYS AS user RUN ... ）を付けることで参加できます。 オプションにGNUスタイルのlongoptsを使用することについて、私は本当に心配しています。なぜなら、それらは古い目やガラス張りの目とあまり離れていないからです。 wtfが起こっているのではないかと思って、20時間後に複雑なDockerfileコマンドを見つめている自分を想像することができます。 しかし、私は--optionsが関係なく発生するだろうと予測しています。

しかし、私は--optionsが関係なく発生するだろうと予測しています。

それどころか、まだ何も決まっていない。 @duglinが示唆している構文は、以前に提案/決定された構文に対する_カウンター提案_です。 詳細については、＃9934をお読みください。

また、 @ duglinはその決定を下す人ではありません（少なくとも、一人ではありません）。 あなたが提起しているポイントのいくつかは、他のスレッドで言及されています。

読みやすさについての懸念を共有しますが、複数のオプションを指定する必要がある場合、提案された他の構文でも同じ問題が発生する可能性があると思います。

この問題は、Dockerfileを読みやすくフォーマットすることで解決できる可能性があります。 適切にフォーマットされたときに読みやすさが問題になるかどうかをテスト/チェックするために、さらにいくつかの例を書くのは良いことだと思います。

そして、はい、あなたの意見はそれについて歓迎されています。

Dockerfile自体にキャッシュの場所を定義させることについてはまだ非常に-1です
適用すべきであり、適用すべきではありません。 私はまだ良い例を見ていません
キャッシュバストに適切に書き換えることができなかったDockerfileと
当然、基盤となるリソースを更新する必要がある場合。

特定の場所でキャッシュを停止するための「dockerbuild」にフラグを設定する
IMOの方がはるかに柔軟です（そしてキャッシュの制御を元に戻します
とにかくそのキャッシュを管理するようになるシステムオペレータの手に）。

@tianonの-1に+1（つまり、-1です！）、ステップNでブレークするフラグを追加するのは妥当なようです。 キャッシュが壊れると、とにかくDockerfileの残りの部分でキャッシュが壊れることを考えると、これは理にかなっていると思います。

これの主な必要性は、Dockerのキャッシュメカニズムが画像の保存と転送に直接関連しているためです。これにより、効率的なキャッシュが可能になりますが、非常に大きな画像とのトレードオフが発生します。 だからそれを修正しましょう！

この機能について私がどのように感じているかはわかりませんが、正直に言うと、誰かが（「dockerbuild」から）ステップNで停止するとどのように想像しますか？ 今日のステップNが明日のステップN + 1になると、ちょっと壊れやすいようです。
Dockerfile内にある種の「ラベル」を追加して、ビルドcmd行からそのラベルを参照できるようにする方法が必要な場合があるようです。
それがあった場合、それとDockerfileに表示される「STOP-CACHING」コマンドの追加との間に大きな違いが見られるかどうかはわかりません。
毎回キャッシュを破壊するDockerfilecmdの良い例は何ですか？

まあ、それが実際にそれを作るために最初に議論された理由です
行コンテンツベースの正規表現、これも問題ありません（特に
どのステップ番号を正確に知るよりも、スクリプトを作成する方がはるかに簡単です。
キャッシュされたくない-現在の完全なコピーを書いているわけではない
BashのDockerfileパーサー、ありがとう：D）。

Tianon Gravi [email protected]書きました：

まあ、それが実際にそれを作るために最初に議論された理由です
行コンテンツベースの正規表現、これも問題ありません（特に
以来
これは、どのステップ番号を正確に知るよりもスクリプトを作成する方がはるかに簡単です。
君
キャッシュされたくない-現在の完全なコピーを書いているわけではない
BashのDockerfileパーサー、ありがとう：D）。

私の以前の提案を言い直したいと思います、それは常に/キャッシュを壊します
「RUN」は「RUN！」になります。 1ワードのコマンド構造（？）を維持します。

特定のステップでキャッシュを壊すために、Dockerfileを編集する必要があるのは厄介なようです（プレースホルダーであるため、基本的にランダムなものを追加します）。 常に特定のステップを実行するdocker build CLIオプションを使用しますが、コマンドにフィードするために特定の行番号を追跡する必要があることは扱いにくいというgit clone直前にランダムな文字（！）をDockerfileに追加するという余分な手順を実行する必要はありません。

@curtiszimmerman私が提案したのは（！）、英語で緊急性に似た何かを示しているからです。 （「これを行う必要があります！」）

Dockerfileは、どのコマンドをキャッシュ不可/キャッシュ可能にするかを定義するための少なくとも1つの適切な場所だと思います。 「--no-cache = git」（これはあなたが提案したものではないことはわかっていますが、引用/比較するために何も提案しなかった）でビルドする必要があるのはもっと厄介なようです。

なぜRUNに焦点を合わせるのですか？ コマンドのためにキャッシュを無効にしないのはなぜですか？
追加するようです：
バストキャッシュ
Dockerfileコマンドのタイプははるかに柔軟です。 そして、実際に柔軟性を追加するために、オプションでフラグを許可することができます。
BUST-CACHE $ doit
$ doitが定義されている場合にのみ適用されます-ビルド時に-eオプションのサポートを追加すると（https://github.com/docker/docker/pull/9176）、次のことが可能になります。
docker build -e doit = true..。

@zamabeああ、私は完全にRUN!を使用します、ごめんなさい。 ここで私は（！）を使って「これは珍しいです！」と言っていました。 特定のステップでキャッシュを壊したいときはいつでもDockerfileを編集することについて。 特定のステップが役立つ前に、Dockerfile内のキャッシュを無効にすることができます（さらに勝つために、そのcache-bustingコマンドの後のステップがキャッシュ内のものと同じ結果である場合は、キャッシュから続行するのに十分賢いです）。 BUST-CACHEまたはALWAYS RUN （またはRUN ALWAYS ）またはRUN! ...この機能をサポートする実際のメカニズムなら、私はそれを使用します。

@duglinごめんなさい？ バグのタイトルには、例として挙げるのが簡単なRUNと書かれています。

@curtiszimmermanああ。

余談として; キャッシュの再検証（？）は、このバグが探しているキャッシュの無効化を少し超えていると思います。 私はあなたが提案していることを気に入っていますが、Dockerfileを並べ替えて、キャッシュを無効にするコマンドをできるだけ最後に配置します。 これは、必要な計算/比較を_常に_行うため、_possible_キャッシュヒットから得られる利点を打ち消します。これは、キャッシュバスティングを使用する人々がおそらくキャッシュミスを期待/期待しているため、Dockerfileビルドを通常終了するよりも重いペナルティです。

@zamabe同意しました。 実装がこれを行うのにかなり些細なことである場合は、おそらく、キャッシュを無効にする識別子とは別の、キャッシュから続行するための特別なコマンドをお勧めします。 ある時点でDISABLE-CACHEに、毎回キャッシュを無効にします。キャッシュから続行するのに比べて、Dockerfileの残りの部分が高価になるユースケースがある場合、 DISABLE-CACHE?なります。可能であれば、キャッシュから続行します。 これは提案ではなく、私が話していることを伝えるための単なるデモンストレーションです。

gitリポジトリからのプルコードの+1

+1

これは巨大でしょう！ 現在、継続的インテグレーションの一部として、gitクローンのキャッシュを壊すためだけにgit commitハッシュをDockerfileに書き込んでいます（プレースホルダーを上書きしています）。

この問題に対処するために、このPRを送信しました： https ：
キャッシュをオンに戻すことはサポートされていませんが、今日はそれが不可能だと思います。

+1

Dockerfileで乱数を生成していますが、キャッシュされます...
NOCACHERUN命令の場合は+1

+1
すべてを再構築せずに毎回実行する必要があるいくつかの実行に本当に役立つはずです

git cloneはキャッシュにヒットしますが、 go get -dはヒットしないことに気づきました。 なぜ何かアイデア？

@ LK4D4 @calavera @jfrazelle @crosbymichael @tiborvass_と_Collectiveレビュー

実際のユースケースはそれほど多くないため、これを閉じます（詳細については、関連する＃10682を参照してください）。

RUNの場合は+1。 いいだろう。

+1

docker1.9ではビルド時の変数が導入されています。 それらを（誤）使用して、キャッシュを強制的に破壊する可能性があります。 詳細については、 https：//github.com/docker/docker/issues/15182を参照して

これはまだ機能ではないのですか？

@ hacksaw6ここで言われたことを見ることができます： https ：

+1

+1

+1これはまだ問題ではありません!!! ???！

+1建物をよりきめ細かく制御するには、この機能が必要です。

+1

+1

+1

+1

+1非常に便利
（今のところ@timrufflesの回避策を使用）

+1

+1

+1

+1だけでなくユースケースを投稿して、これが必要な機能である理由を人々が理解できるようにすると便利かもしれません。

+1、キャッシュされたgitクローンの解決策を探してGoogle経由でここに到着しました。

私のユースケース：
Docker構成があり、ビルド中に、ドライランモードでGroovyマイクロサービスアプリをgradle経由で呼び出します。 これにより、（リモートmvnリポジトリからの）すべての依存Javaライブラリがローカルdockermvnリポジトリにダウンロードされます。 ドライランはアプリを実行してすぐに戻りますが、すべてのJavaライブラリの依存関係が読み込まれるようにします。
Dockerの実行フェーズでは、同じアプリがgradle--offlineモードで実行されます。 つまり、マイクロサービスアプリはローカルのmvnリポジトリディレクトリからロードするだけです。 高価で時間のかかるリモートライブラリのフェッチは行われません。 このようなライブラリの新しいスナップショットバージョンをリリースすると、dockerディレクトリを変更しない限り、dockerはビルド中にリモートフェッチをトリガーしません（つまり、彼は私のgradle dryrun cmdを呼び出しません）。

私の使用例：画像で使用するライブラリの最新のサードパーティバージョンを取得します。 そのためにdockerhubとAFAIKを使用していますが、何もキャッシュされません。 しかし、それがいつ変わるかは誰にも分かりません。
dockerにNOCACHEのようなコマンドフラグがあれば、イメージがどこに構築されていても、それが保証されます。

最新バージョンのIMHOよりもビルドシステムの「機能」に依存する方が悪いです。

新しい構文を追加するのはどうですか： FORCE RUN git clone .... ？

現在、 RUN _=$(date) git clone ...を使用してキャッシュを無効にしています。

@ c9sは実際に機能しますか？ そうは思わない。

@duglin設定環境変数は私のために働きます。 「FORCERUN」は単なる提案です：]

@ c9s env varの設定がどのように機能するかわかりません。これは、Dockerfile処理ではなく、コンテナーのシェルによって行われるためです。 RUN _=$(date) echo hiを試すと、2番目のビルドでキャッシュが使用されます。

@duglinあなたは正しいです：| キャッシュを無効にしません

@ c9s代わりにこれを試してください

FROM foo
ARG CACHE_DATE=2016-01-01
RUN git clone ...

docker build --build-arg CACHE_DATE=$(date) ....

@thaJeztahありがとう！ できます！

+1クローニングgitリポジトリ（ユースケース）

非常に多くの+1があるため、Dockerファイルでgitレポジトリをプルすると、キャッシュによってイメージが構築されなくなります。 CIを介してビルドをプッシュするのが少し難しくなります。

+1クローン作成gitリポジトリ（gitリポジトリで小さな編集が行われるたびにイメージを最初から作成する必要があるのは非常に面倒です）

@Vingtoftリポジトリ内のファイルを更新している場合、キャッシュは無効になります。

@itsprdp知らなかった、明確にしてくれてありがとう。

@itsprdpテストしました。 リポジトリを更新してイメージをビルドしているとき、Dockerはまだキャッシュを使用しています。
おそらく私は何かを誤解していますか？

@itsprdpそれは私の経験では正しくありません。 テストするためにリポジトリに新しいコミットを行いました。再度ビルドすると、同じキャッシュが使用されます。

リポジトリの前にDockerファイルを変更すると、もちろんキャッシュが無効になりますが、リポジトリを更新するだけではこの問題は解決しないようです。

@RyanHartje混乱してすみません。 リポジトリが更新された場合、キャッシュを無効にすることになっています。これは、寄稿者が検討する必要があることです。
@Vingtoftが期待するユースケースは、リポジトリをキャッシュし、リポジトリ内の変更されたファイルのみを更新することです。 これは実装が複雑になる可能性があります。

@itsprdpリポジトリ内の変更されたファイルのみを更新するのは素晴らしいことですが、それより少ない（またはもっと言うべきですか？）のも同様です。
私のユースケース（および他の多くのケース）では、実際のgitpullはそれほど時間はかかりません。それは開発フローを殺す他のすべてのものの構築です。

+ 1、gitclone中に使用されるキャッシュ:(

統合ソリューションがあればいいのですが、それまでの間、 ARGを使用して特定のDockerfile命令でキャッシュを無効にすることができます。

Dockerfileの場合：

ARG CACHEBUST=1
RUN git clone https://github.com/octocat/Hello-World.git

コマンドライン：

docker build -t your-image --build-arg CACHEBUST=$(date +%s) .

CACHEBUSTを現在の時刻に設定すると、常に一意になり、DockerfileのARG宣言の後の命令はキャッシュされません。 CACHEBUST build-argを指定せずにビルドすることもできることに注意してください。これにより、デフォルト値の1が使用され、キャッシュが保持されます。 これは、gitリポジトリの新しいコピーを常にチェックアウトしたり、最新のSNAPSHOT依存関係をプルしたりするために使用できます。

編集：ええと、 @ thaJeztahが言ったことです。 彼の解決策の追加の説明としてこれを残しておきます。

@ shane-axiom CACHEBUST値としてgit commitハッシュを使用するのはどうですか？

export CACHEBUST=`git ls-remote https://[email protected]/username/myRepo.git | grep refs/heads/develop | cut -f 1` && \
echo $CACHEBUST && \
docker build -t myDockerUser/myDockerImage \
   --build-arg blah=blue \
   --build-arg CACHEBUST=$CACHEBUST \
   .

http://stackoverflow.com/questions/15677439/how-to-get-latest-git-commit-hash-command#answer-15679887からの手がかりに基づく

@pulkitsinghalこれは、gitリポジトリのキャッシュを

CACHEONの+1 | オフ

+1

+1

@CheRuisiBesaresのアプローチについて覚えておいてください。キャッシュの問題の回避策として、いつでもADD https://www.random.org/strings/?num=16&len=16&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new uuidを使用できます。

追加のユースケースを投稿するには...

COPY package.json /usr/src/
RUN npm install

package.json 、通常、いくつかのプライベートgithub依存関係のmasterタグを指します。 これは、 package.jsonファイルを変更しない限り、最新のmaster実際に取得することはないことを意味します（通常、説明に-を追加し、テスト中に削除します）。

RUN代わりにRUN NO CACHEを使用するのは、良い解決策のようです。

+1

キャッシュを使用し、npmで新しく公開されたライブラリを使用しないnpmインストールについても同様の問題があります。

DockerファイルのRUNコマンドごとにキャッシュを無効にできると便利です。

@brycereynolds @mmobini手動でキャッシュを無効にする方法については、 https： //github.com/docker/docker/issues/1996#issuecomment-172606763を参照して

キャッシュを無効にできないことが問題の原因となっているユースケースがあります。 DockerからDropwizardアプリケーション（Mavenで構築されたJava RESTサービス）を実行しており、自動化されたシステムがすべてのコンテナーの構築とデプロイを行っています。 リポジトリにDockerfileを含め、残りはそれで行います。 システムは、アプリケーションの製品版と1つ以上の開発版を実行します。 開発ビルドは私が問題を抱えているところです。

開発中、プロジェクトの依存関係の一部には、バージョン番号にSNAPSHOTが含まれています。 これは、バージョンが開発中であり、ビルドごとに新しいバージョンをダウンさせる必要があることをMavenに指示します。 その結果、同一のファイル構造により、2つの異なるビルドが発生する可能性があります。 SNAPSHOTの依存関係でバグが修正されている可能性があるため、これは望ましい動作です。 これをサポートするには、ファイルシステムの現在の状態に基づいてコマンドの効果を判断する方法がないため、Dockerに特定のコマンドを実行させると便利です。 MavenスタイルのSNAPSHOT依存関係はいくつかの異なるビルドシステムで使用されるため、Javaプロジェクトの大部分はこれに遭遇します。

@ctrimble --no-cacheまたは--build-argを使用して、キャッシュを無効にすることができます。
キャッシュ可能なすべてのコマンドを含むベースイメージを用意することで、 --no-cacheの影響を最小限に抑えることができます。

@ cpuguy83返信ありがとうございます。 スレッドを読み、現在のオプションを理解しました。 キャッシュ無効化引数を提供するために使用しているビルドシステムでチケットを開きました。 1つのアプリケーションに対して2つの異なるイメージを生成することは、ビルドを高速化するために多くの作業を行う必要があるように思われます。 次のようなものを指定できる方がはるかに簡単です。

1. ファイルシステムが同一である場合にキャッシュできることを行う
2. いつ実行されるかに基づいてファイルシステムを変更する可能性のあることを行う
3. 前の手順でファイルシステムが変更されなかった場合にキャッシュできる可能性のある処理をさらに実行します

このパターンは、開発ビルドで頻繁に発生します。 Dockerfileにそのセマンティクスがあると便利です。

@ctrimble 1つのステップでキャッシュを無効にすると、後続の各ステップで常にキャッシュが無効になります。

@ cpuguy83正確に。 私のビルドシステムのセマンティクスは、開発ビルドでは一時的なものです。 キャッシュよりも正しいビルドを選択する必要があります。 本当に両方欲しいです。

ここではかなりの議論がありました。すでに提案されている場合はお詫びしますが、次のようなものがあった場合はどうなりますか。

CHECK [FILE_PATH]

dockerが行うのは、ファイルのMD5（またはその他のハッシュがヒップ）を保存することだけです。ファイルが変更されると、それ以降のすべてのステップが無効になります。

私はおそらく次のようなことをしているでしょう：

CHECK Gemfile
CHECK package.json
CHECK composter.json
CHECK project.json

また、一定期間後に何らかの経過が経過したことを確認できるようにすることもできます。 aptプラグイン用のAnsibleのcache_valid_timeパラメーターは、いくつかのインスピレーションを提供する可能性があります： http ：

そのための構文は次のようになります。

EXPIRE 1234567 
RUN apt-get update
RUN bundle install

Dockerは最終実行時間を認識し、「現在」に基づいて時間が経過したかどうかを計算します。

@atrauzzi 1.13のビルドで--squashをサポートするだけです（現時点では実験的です）。

@ cpuguy83 --squashについて、私が読むことができるドキュメントや説明はありますか？ 当初、名前は私が考えていることをしているようには聞こえません。 しかし、私は間違っている可能性があります（そしておそらく間違っています）！

@atrauzziはい、ビルドリファレンスにあります。

基本的に、 --squashはレイヤーキャッシュを保持し、Dockerfile内のすべてが単一のレイヤーで発生したかのように2番目のイメージを作成します。

ファイルキャッシュがまだ個別に有効であることを確認する必要がある理由がわかりません。 ADDとCOPYは、コピーされるすべてのものに対してすでにこれを行っています。

@ cpuguy83良い点、それも考えていませんでした。もちろん、私はすでにそれを使用しています。

タイムスタンプ/期間のアプローチはどうですか？ それはすでに利用可能なもので実行可能ですか？

タイムスタンプ/期間のアプローチはどうですか？ それはすでに利用可能なもので実行可能ですか？

build-argsを介して;

ARG expire_after=never
RUN do some thing

docker build --build-arg expire_after=2016-12-01 -t foo .

キャッシュを無効にするようにビルド引数を変更します

よりクリーンな方法のための+1

よりクリーンな方法のための+1

キャッシュの読み取りを無効にするためと、キャッシュへの書き込みを無効にするための別々のオプションも必要です。 たとえば、イメージを最初から新しく作成し、キャッシュされたレイヤーを無視して、結果の新しいレイヤーをキャッシュに書き込むことができます。

+1

ステップ番号をビルドコマンドに渡すことをお勧めしますか？

このようなもの：
docker build --step 5 .

ビルド後のステップ5以降のすべてのキャッシュを無視します。

+1
お願いします。

キャッシュオン|オフ+1

これらのCACHE ON|OFFコマンドの問題は、キャッシュがオフになっているステップが何であれ、それ以上のステップをキャッシュする方法がないことです。 唯一の賢明なコマンドはENDCACHEです。

それは有効な考え/精神です。 このコマンドは、キャッシュがオンに戻された時点で、キャッシュされていないすべてのレイヤーを1つのレイヤーにまとめる必要があります。 もちろん、機能の最良の命名/セマンティクスの正確さ/優先構文についても議論することができます。

+1

+1必須機能

CACHE ON | OFF + 1に同意します

+1は素晴らしいでしょう。

Dockerが以前にステップをキャッシュする方法を本当に理解しておらず、システムが正しく構築されていない理由を調査するために半日を費やしました。 それは「gitclone」キャッシングでした。

ALWAYSキーワードが欲しいです。

どのように閉じられますか？

最善の回避策は何ですか？

https://github.com/moby/moby/issues/1996#issuecomment -185872769を試しましたが、機能しました
Dockerfileの場合：

ARG CACHEBUST=1
RUN git clone https://github.com/octocat/Hello-World.git

コマンドライン：

docker build -t your-image --build-arg CACHEBUST=$(date +%s)

RUNに似た新しいコマンドを作成しませんが、RUN NO CACHEのRUNNCをキャッシュしないのはなぜですか？

確認できます、 @ habeebr （https://github.com/moby/moby/issues/1996#issuecomment-295683518） ますissuecomment -191543335

+1

RUNNCは素晴らしいアイデアです！

なぜこの問題は解決されたのですか？ 本質的に同じことを要求する無数の複製と、これらの複製の複数の長いコメント履歴の間で、この機能が利用可能であることに健全な関心があることは明らかです。

難しいと思います。おそらく、ニーズを満たし、魅力的なDockerの追加として十分にクリーンな、十分にエレガントなソリューションを提案した人はいないでしょう...しかし、それは_必要がない_という意味ではありません。

これを閉じることに賛成して私が聞いた他の唯一の議論は、これを達成する他の方法があるということです...しかし、その議論は実際には召集を通過しません。 キャッシュ制御の欠如を回避することを唯一の目的として複数のベースイメージを作成することは扱いにくく、ARGを介して無効化を考案することは鈍感で直感的ではありません。 ユーザーは、Docker開発者がツールにずさんなハックを公式に組み込みたいのと同じくらい、これらの「回避策」を利用したいと思っていると思います。

難しいことではありません： https ：
簡単なソリューション、簡単なUX。 それを行うべきかどうかについての明確なコンセンサスはありません。

うわー、ただうわー...

私はそれについて聞く必要がないだけですでにそれを実装していたでしょう、ユーザーベースがそれを望んでいるという明確なコンセンサスがあることを気にしないでください。 私はそのような大きなオープンソースプロジェクトの開発者側にはいませんでした。はるかに小さなプロジェクトだけなので、何かが足りないのかもしれません。

+1

賢明なセキュリティとより良いパフォーマンスのための+1

+1

+1

+1

+1

+1

+1

+1のスパムをやめられますか？ 反応機能を使用して賛成票を投じるだけです。

何か変更はありますか？
この問題が解決された理由はまだわかりません。
私の意見では、これはリモートgitリポジトリからのバージョンプルを完全に処理する必須の機能です。

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

なぜこれを閉じるのですか？ 便利だと思います

+1

+1

+1

現在、レイヤー（および以下）のキャッシュを無効にする最も簡単な方法：

Dockerfile

ARG CACHE_DATE
RUN wget https://raw.githubusercontent.com/want/lastest-file/master/install.sh -O - | bash

また、イメージを作成するときに、 --build-argを追加する必要があります

docker build  --build-arg CACHE_DATE="$(date)"

その後、キャッシュを使用するのではなく、イメージをビルドするたびにwgetコマンドが実行されます。

RUNNCまたはCACHE OFFがいいでしょう

それまでの間、これは有望に見えます。
http://dev.im-bot.com/docker-select-caching/

あれは：

私は落ち着いて群れに参加するつもりです：

+1

ええ、コマンドを選択的にキャッシュする必要があります。 設定ファイルの単語を1つだけ変更すると、 COPYは80％の確率で失敗します。 COPYキャッシュせずに、他のすべてをキャッシュしたいと思います。 CACHE ONとCACHE OFFがあると便利です。

RUN X
RUN X
CACHE OFF
COPY /config /etc/myapp/config
CACHE ON

@shadycuzいずれかの方法を使用してキャッシュを無効化/無効化した後は、キャッシュを「再度有効化」することはできません。 ビルドは、キャッシュされていないレイヤーが、新しいレイヤーで考慮する必要のあるファイルシステム内の他の何かを変更していないことを（妥当な時間内に妥当な量のリソースで）検証できません。 常に外部構成ファイルをプルする必要があるという影響を最小限に抑えるために、 COPYディレクティブをDockerfileのできるだけ下に配置する必要があります（Dockerがビルドキャッシュをできるだけ多く使用できるようにするため）キャッシュが無効になる前に、可能な限りプロセスを構築します）。

ビルドプロセスの特定の時点でキャッシュを無効にするには、前述の--build-argとARG使用に関する他のコメントを参照してください。

@shadycuz @curtiszimmermanはい、 CACHE OFFのみを保持し、 CACHE ONは保持しない場合があります。これは、前のレイヤーが変更された場合、次のレイヤーを再構築する必要があるためです。

CACHE ONは技術的な観点からは意味がないことに同意します。 ただし、実際にはどのレイヤーを無効にすることを意図しているのか、意図をより明確に表現するのに役立ちます。

より柔軟な解決策は、 RUN似たコマンドで、キャッシュを無効にする必要があるかどうかをシェルコードで判断できるようにします。 終了コード0は、「キャッシュを使用する」および1「キャッシュを無効にする」を意味する場合があります。 シェルコードが指定されていない場合、デフォルトでは、これ以降、キャッシュが無効になる可能性があります。 たとえば、コマンドはINVALIDATEと呼ばれる可能性があります。

なぜこれはコメントなしで閉じられたのですか？

コメントがありましたが、githubによって隠されています
https://github.com/moby/moby/issues/1996#issuecomment -93592837

+1

この機能は、今のところ私にとって命の恩人になるでしょう。

+1

多くの実際のユースケースが見られないため、これを閉じます

212のコメントとカウントがありますが、それでもユースケースはありませんか？ かなり無知のようです。

+1

+1

+1

+1

+1

問題はまだここにあり、解決策が必要です。 実世界での使用はまだたくさんあります。

+1

Docker開発者には、これを実装するインセンティブがないのではないかと思います。これは、集中型の建物インフラストラクチャがキャッシュなしのリクエストによってDDsSされるのを防ぐためです。

また、キャッシュなしのビルドを容易にする並列インフラストラクチャは、エンタープライズユーザーにとって興味深いものになると思います。

全体として、この問題はソフトウェア機能に関するものではなく、サービススケーリングの問題です。

@jaromilこれは完全に真実ではありません。これは、自己ホスト型リポジトリでも不可能だからです。

セルフホストリポジトリを実行するためにどのようなソフトウェアがありますか？ 私はあなたが何を指しているのか本当にわかりません。
単純なセルフホストソリューションは、cronクローニングgitリポジトリとrunnig docker build --no-cache-オープンソースソフトウェアでは発生しないと確信しています。その後、誰でもdockerbuildコマンドラインを変更できます。

@jaromilそれは問題ではないと思います。 DockerHubのオープンソースプロジェクトに使用する方が効率的です（有料のプロジェクトと同様に、ビルドの数に課金されません）。 ビルドが頻繁に行われるCI / CD環境では、これはさらに悪化します。

それを行う必要がある限り（dockerとgitを使用していて、5つのコンテナーで共有ボリュームを実行したくない場合）、コンテナーを再構築して、新しいバージョンをアップロードするたびにアップロードする必要があります。 コンテナ全体。
コード内のキャッシュなしフラグを使用すると、ビルドを実行するたびに、バージョンを更新するためのコンテナー全体ではなく、その単一のレイヤーをビルドして置き換えるだけです。

セルフホスティングの担当者については、驚かれることでしょう。 @bluziのコメントを理解し

確かに、これは私が想像していたより複雑なシナリオです。 今私は思う...一種のnocache単一層ハッシュでアップロードする...プッシュしてオーバーライドする、あなたはそれに名前を付ける。 私はわかりません

TLDR：Dockerドキュメントのいくつかの改善が大いに役立つと思います。

私自身の問題/キャッシングの混乱に遭遇した後、私はここに行き着きました。 こことhttps://github.com/moby/moby/pull/10682ですべてのコメントを読んだ後、特定のユースケースで実行可能な解決策を見つけました。 それでもどういうわけか、私はまだこれに対するDockerの応答に不満を感じており、他の多くの人も同じように感じているようです。

どうして？ これをいくつかの異なる角度から考えた後、ここでの問題は、漠然としたユースケース、提案された変更に対する過度に一般化された議論（有効かもしれませんが、提示されたユースケースに直接対処しない）、およびいくつかの一般的なユースケースに関するDockerの推奨事項のドキュメント。 おそらく、私は物事を明確にし、この状況を支援するために改善できるドキュメントを特定するのを手伝うことができます。

行間を読むと、この機能要求に関する初期のコメント投稿者のほとんどは、Dockerfileの特定のポイントでキャッシュを無効にするためにdocker image buildへの追加の引数を使用するソリューションに満足しているように思えます。 これに対するDockerの現在のソリューション（https://github.com/moby/moby/issues/1996#issuecomment-172606763で説明）は、これらのほとんどの場合に十分であるように思われ、多くのユーザーがこれに満足しているようです。 。 （ docker image build追加の引数を提供できるユースケースがあるが、このソリューションがまだ不十分な場合は、これが不十分である理由を説明するコメントを追加すると役立つでしょう。）

残りのフラストレーションはすべて、キャッシュ動作を制御するために追加の引数をdocker image buildに渡すという要件に関連しているようです。 ただし、これに関連するユースケースはあまりよく説明されていません。

行間をもう一度読むと、これらのユースケースはすべて、ユーザーに代わってdocker image buildを実行するサービスに関連しているか、 docker image build実行する他のユーザーに配布されるDockerfilesに関連しているように見えます。 docker image build追加の引数を渡すことが問題となる他のユースケースがある場合は、ユースケースを詳細に説明するコメントを追加すると役立つでしょう。）

これらのケースの多くでは、ユースケースでは、Dockerfileの特定のポイント（この機能リクエストの元のポイント）でキャッシュを無効にする機能は実際には必要ないようです。 代わりに、多くのユーザーは、 docker image buildへの "--no-cache"引数を使用せず、各前にDockerfileを手動で変更することなく、Dockerfile内からキャッシュを完全に無効にする機能に満足しているようです。建てる。 （ユースケースを説明するときは、部分的なキャッシュが実際に必要かどうか、またはキャッシュを完全に無効にするだけでユースケースに十分かどうかを説明すると役立つでしょう。）

サービスがユーザーに代わってdocker image buildを実行する場合、Dockerは、そのようなすべてのサービスが無条件にキャッシュを無効にするか、ユーザーにキャッシュを無効にするオプションを提供することを期待しているようです。 https://github.com/moby/moby/pull/10682#issuecomment-73777822によると、DockerHubは無条件にキャッシュを無効にします。 サービスがまだこれを行っていない場合、Dockerはhttps://github.com/moby/moby/pull/10682#issuecomment-159255451がサービスプロバイダーにそれについて不平を言うことを提案しています。

これは、 docker image buildを実行するサービスに関してDockerが取る合理的な立場のように思えます。 ただし、サービスプロバイダーとユーザーの両方が何を期待できるかを理解できるように、この位置を目立つ場所に公式に文書化する必要があります。 この位置またはDockerHubのキャッシュ動作は、現在、その巨大な/古代の/クローズされたプルリクエストの奥深くに埋め込まれているオフザカフコメント以外の場所で文書化されているようには見えないため、サービスプロバイダーとユーザーの両方が日常的にこれを間違えます。 おそらく、ビルドサービスによるキャッシングの使用に関するDockerの意見を説明する情報をdocker buildリファレンスに追加し、 DockerHubのキャッシング動作に関する情報を

Dockerfileが他のユーザーに配布されてからdocker image build実行する場合、単純なdocker build .コマンド（追加の引数なし）の使用は非常に一般的であるため、 Dockerfileビルダーがユーザーに引数の追加を要求するのは不合理ですが、他の人は（例：https：//github.com/moby/moby/issues/1996#issuecomment-72238673 https://github.com/moby/moby/pull / 10682＃issuecomment-73820913 https://github.com/moby/moby/pull/10682#issuecomment-73992301）は、ユーザーがDockerfileにキャッシュオーバーライドをハードコーディングすることでキャッシングを無条件に使用できないようにすることは不適切であると主張しています。 このための詳細で説得力のあるユースケースがないため、Dockerは、キャッシュを制御するために追加のコマンドライン引数を要求するという経営陣の決定を下しました。 （これに関連する説得力のあるユースケースがある場合は、それを詳細に説明するコメントを追加すると役立つでしょう。）

ただし、Dockerは、追加の引数なしでdocker build .を実行するというユーザーの習慣を破るだけで、すべての人を幸せにすることができるように思われます。 キャッシュの動作と「--no-cache」引数は、関連するDockerチュートリアル（ thisやthisなど）では言及されていません。
またはこれ）。 さらに、 docker buildドキュメントには「--no-cache」引数が記載されていますが、その重要性を説明したり、多くの一般的なユースケースで重要であるという事実を強調したりしていません。 （ docker image buildドキュメントは空であることに注意してください。少なくともdocker buildドキュメントを参照する必要がありDockerfileのリファレンスとベストプラクティスのドキュメントのみが実際にキャッシュの動作を説明し、役割について言及しているようです。 「--no-cache」引数の。 ただし、これらのドキュメントは、高度なDockerfileライターによってのみ読み取られる可能性があります。 したがって、上級ユーザーだけが「--no-cache」引数に精通していること、およびほとんどのユーザーが追加の引数なしでdocker build .を実行するだけで、動作しないときに混乱することは当然のことです。彼らまたはDockerfileライターがどのように期待/望んでいるか。 おそらく、チュートリアルとdocker buildドキュメントを更新して、「-no-cache」引数とその重要性について言及すると、この問題が解消される可能性がありますか？

+1

+1

dockerの公式ツール

+1

+1

私が今直面しているユースケースは、プライベートパッケージをインストールするためのビルド引数として、一時的で短命なシークレットを渡したいというものです。 これは、シークレットが変更されるたびに（基本的にすべてのビルド）、キャッシュが無効になり、パッケージが再インストールされることを意味するため、キャッシュが完全に壊れます。ただし、唯一の変更はシークレットです。

ARGを指定する前にCOPYされるスクリプトでARGを使用することでこれを回避しようとしましたが、ARG入力が変更された場合、DockerはARGが宣言された後にすべてを無効にするように見えます。

私が見たい動作は、ビルドを呼び出すときにDockerfileまたはCLIのいずれかで、常にキャッシュしているものとしてARGにフラグを立てることができるようにすることです。 シークレットのようなユースケースの場合、それは多くの場合あなたが望むものです。 パッケージリストの内容は、ARGに渡される引数ではなく、キャッシュが無効になるタイミングを指示する必要があります。

これらのセクションを2番目のイメージに引き出して、ベースイメージとして使用できるという理論を理解していますが、package.json、requirements.txt、Gemfileなどのように、パッケージがプロジェクトで使用される場合はかなり厄介です。 。そのベースイメージも継続的に再構築されます。

この行ディレクティブから+1からCACHE OFF -私は文字通り何年もこれを待っていました。

Dockerハブ/ Dockerクラウドのキャッシュを無効にする必要がありました。これにより、大きなレイヤーをキャッシュして、dockerfileの終わり近くでnocache updateコマンドを実行できれば、時間とビルドを大幅に節約できます。

私が見たい動作は、ビルドを呼び出すときにDockerfileまたはCLIのいずれかで、常にキャッシュしているものとしてARGにフラグを立てることができるようにすることです。 シークレットのようなユースケースの場合、それは多くの場合あなたが望むものです。 パッケージリストの内容は、ARGに渡される引数ではなく、キャッシュが無効になるタイミングを指示する必要があります。

--build-arg PASSWORD=<wrong>は、 --build-arg PASSWORD=<correct>とは異なる結果を生成する可能性があるため、パッケージリストの内容を確認するだけでうまくいくかどうかはわかりません。 ビルダーは、環境変数の設定/変更が実行されるステップにどのような影響を与えるかをそれ自体で予測することはできません（ make DEBUG=1 fooとmake DEBUG=0 fooは同じですか？）。 現在行われている唯一の例外は、 xx_PROXY環境変数の場合です。この場合、ネットワーク接続にはプロキシが必要であると想定されますが、別のプロキシに切り替えると同じ結果が得られます。 したがって、それが機能するためには、キャッシュのために無視される特定の環境変数（/ build arg）を示す何らかの方法が必要になります。

BuildKitはRUN --mount=type=secretとRUN --mount=type=sshを実験的にサポートするようになりました。これはシークレット/クレデンシャルを渡すのに役立つ可能性がありますが、これらのシークレットが変更された場合でもキャッシュを無効にする可能性があります（わからない;これはビルドキットの課題追跡システム（https://github.com/moby/buildkit/issues）を表示します。

Dockerハブ/ Dockerクラウドのキャッシュを無効にする必要がありました

Docker Hub / Cloudは実際にキャッシュを_使用_しますか？ そこではキャッシュは使用されていないと思います（たとえば、エフェメラルビルド環境を使用しています）

DockerHubはビルドキャッシングを使用していなかったのを覚えていますが、このチケットの直前にDocker Cloudで自動ビルドを確認していました。現在、各ブランチのAutobuildスライダーの横にBuilding Cachingスライダーがありますが、デフォルトではオフになっています。

git cloneようなステップは、変更されないディレクティブ文字列のみを比較するため、最新のリポジトリダウンロードを取得しないため、ビルドキャッシュを有効にしないでください。 何年もの間私たちの側でとげになっている今日の同僚にこの問題を説明すると、多くのユースケースにとって大きな欠陥のように見えるので、彼は驚いていました。

最初のgit clone && make buildをキャッシュしてから、 git pull && make buildステップでNO CACHEして、はるかに小さなコード更新と、最後にまだインストールされていない依存関係のみを取得することをお勧めします。これにより、ビルドだけでなく、今より重要なことに、毎回数百MBのレイヤーを再ダウンロードして置き換える必要があるすべてのクライアントにとって、イメージの大部分を効率的にキャッシュできます。これは非常に非効率的です。

サイズは、プロジェクトの多くに多数の依存関係があるためです。 システムパッケージ+ PerlCPANモジュール+ PythonPyPIモジュールなど。

システムパッケージの依存関係とCPANおよびPyPIの依存関係を追加すると、Alpineを使用してもそれほど小さくはありません。これは、Alpineを何年も使用して、より小さなイメージを作成できるかどうかを確認しようとしているためですが、依存関係がたくさんあると、そうではありません。システムパッケージを追加するとそのほとんどがすぐに追加されるため、ベースが小さくなった場合は大きな違いがあります。

すべてのシステムパッケージ+ CPAN + PyPIモジュールを含む以前のレイヤーをキャッシュすると、ほとんどの場合、動作中のインストール済みモジュールを更新しないため、更新の最後のレイヤーで変更されることはほとんどありません（ bash-toolsのスクリプトを使用しました）不要な非バグ修正アップデートのインストールを回避するために、まだインストールされていないパッケージのみをインストールするユーティリティサブモジュールリポジトリ）

しばらくの間、ARGを変更するようなトリックを使用することを検討していました（http://dev.im-bot.com/docker-select-caching/などのブログを検索して得たアイデア）：

Dockerfileの場合：

ARG NOCACHE=0

次に、次のようにdockerbuildを実行します。

docker build --build-arg NOCACHE=$(date +%s) ...

しかし、これはDockerCloudでは不可能だと思います。

環境変数はありますが、上記のエポックなどの動的コンテンツを使用することはできないようです（または少なくとも私が見つけた文書化されていません）。環境変数を使用すると、そのディレクティブ行以降のキャッシュが無効になるかどうかはわかりません。

@thaJeztahはい、この種の動作は、誤解されたり乱用されたりすると、簡単に悪影響を与える可能性がありますが、特定のユースケースを非常にうまく解決します。

--build-arg PASSWORD=<wrong>は、 --build-arg PASSWORD=<correct>とは異なる結果を生成する可能性があるため、パッケージリストの内容を確認するだけでうまくいくかどうかはわかりません。

異なる結果が得られることは正しいですが、パッケージリストが変更されていない場合は、パスワードが正しいか間違っているかは気にしません。 パッケージはすでに前のイメージに含まれているため、これを実行しているユーザーはすでにアクセス権を持っています（つまり、セキュリティ上の懸念はありません）。以前にパスワードが間違っていた場合、Dockerfileの作成者がインストールに失敗する負担が予想されます。必要な場合は、パスワードを修正した後でもパッケージを正しくインストールする機会が得られることを意味します。

はい、 docker build --force-cache-build-arg SECRET=supersecretようなものを描いていました。 それはかなり不格好です、誰かがもっと良いものを思い付くことができると確信しています。

@HariSekhonあなたのユースケースは実際には私の反対のようですが、そうですか？ キャッシュを選択的に強制的にヒットするのではなく、キャッシュを選択的に強制的にミスしたいですか？

これを追加することは私のために働いた：

ADD http://date.jsontest.com/ /tmp/bustcache

しかし、そのサイトは現在ダウンしています。 これはうまくいくはずです

ADD http://api.geonames.org/timezoneJSON?formatted=true&lat=47.01&lng=10.2&username=demo&style=full /tmp/bustcache

@itdependsnetworks

完璧です。これは良い回避策であり、サイトは現在バックアップされています。 イメージのビルド日を記録することも役立ちます。

私はこれを試しましたが、同様の他の特別なファイルは毎回変更されるはずです

COPY /dev/random ...

しかし、 RUN ls -l -R /etcがそのようなファイルが存在することを示していても、それらは常に見つからなかったので、それは機能しませんでした。特別なファイルの使用に対する何らかの保護があると思います。

DockerHub / Docker Cloudで詳しく考えると、ビルド前のフックを使用して日付スタンプを含むファイルを生成し、それをキャッシュバストしたいレイヤーの直前のイメージにコピーして、同様の結果を得ることができますが、追加上に示したように、ローカルのDockerおよびクラウドビルドへの移植性が高いと思います。

このキャッシュバスティングの回避策については、より信頼性の高い日付印刷サイトを見つける必要があります。上記の両方がデモであるか、割り当てがあるため、信頼性が低く、ランダムにビルドが中断されます。

最初のものは常に1日の割り当てを破り、2番目のものは現在このエラーを出している

{"status": {
  "message": "the daily limit of 20000 credits for demo has been exceeded. Please use an application specific account. Do not use the demo account for your application.",
  "value": 18
}}

ビルドごとに実行されるDockerファイルに命令を入れて、出力が前回のビルドと異なる場合は、後続のレイヤーが再ビルドされるのは素晴らしいことだと思います。

使用例は次のようになります。

FROM something
... 
CACHE_BUST git ls-remote my-git-repo HEAD
RUN git clone --depth=1 my-git-repo ...
...
CMD ["my-cmd"]

上記のCACHE_BUST命令のコマンドは、指定されたリポジトリのHEADからSHAを出力します。これにより、dockerfileは、リポジトリへの変更に基づいてクローンを作成するかどうかを知ることができます。

ここでの私のユースケースはすべて、上記のように非決定論的なネットワーク関連のレイヤーに関連しています。 現在、ここではすべてのニーズにARGを使用できますが、それは、dockerfile自体だけを維持するのがよい場合に、dockerfileを使用するビルドスクリプトが必要になることが多いことを意味します。 （さらに、一部のツールでは引数を許可していません）

私の現在のワークフローは次のようになります。

ARG SHA_TO_BUILD
RUN echo SHA_TO_BUILD
RUN git clone ...
...everything else reliant on that clone

$> ./build-my-image.sh $(get-latest-sha)

コマンドごとにキャッシュのオンとオフを切り替えるのは悪い考えだと思います。ファイルは、1つのレイヤーを再構築する必要がある場合、残りのレイヤーも再構築する必要があるように書き込む必要があります。 しかし、ファイルの特定の時点で強制的に再構築できると便利だと思います。

そのような素晴らしい機能、なぜまだ保留中ですか？

もう1つの使用例は、ファイルの内容が変更されたが、 Dockerfileは変更されていない場合です。

たとえば、 COPY file.txt .あり、 file.txtを変更した場合、Dockerはキャッシュされた古いバージョンを引き続き使用します。

Dockerがコピーしたファイルのチェックサムを実行する場合、次回はそれを使用して、問題を解決するキャッシュレイヤーを使用する必要があるかどうかを判断します。

今のところ、私は--no-cacheを使用することを余儀なくされており、それは必要以上にダウンロードして実行します（時間と帯域幅を浪費します）。

@brennancheungその場合、それはバグです。 再現可能な手順で別の問題を開いてください。

@brennancheungの要点だと思います
https://github.com/brennancheungは、たとえば、
構成ファイル（または同様のもの）をロードします。 あなたはする必要はありません
アプリケーション全体を再インストールし、これらのファイルとコマンドを更新するだけです
それに関連付けられて、Dockerと出来上がりを実行し、システムが設定されます。
もちろん、多くの場合、設定ファイルを最後の方に置くことができます
あなたのスタックですが、常にそうであるとは限りません。

Am Mi.、20.März2019um00:10 Uhr schrieb Tibor Vass <
[email protected]>：

@brennancheung https://github.com/brennancheungその場合は、
バグです。 再現可能な手順で別の問題を開いてください。

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

-
チアゴ・ロドリゲス

これを試してみましたhttps://github.com/moby/moby/issues/1996#issuecomment-185872769

ただし、キャッシュに影響を与えるのは最初の使用時/はありません。

https://docs.docker.com/engine/reference/builder/#impact -on-build-caching

Dockerfileが以前のビルドとは異なる値のARG変数を定義している場合、「キャッシュミス」は、その定義ではなく、最初の使用時に発生します。

@samstav "first use" RUN後に最初のARG （そのARGがビルドステージの場合）。

ARG FOO=bar

FROM something
RUN echo "this won't be affected if the value of FOO changes"
ARG FOO
RUN echo "this step will be executed again if the value of FOO changes"

FROM something-else
RUN echo "this won't be affected because this stage doesn't use the FOO build-arg"

次世代ビルダー（BuildKit）を使用している場合、上記は少し異なります。 DOCKER_BUILDKIT=1有効にすると、BuildKitは最終段階で必要ない場合は構築段階をスキップできるため、構築段階をスキップできます。それらが完全にキャッシュできる場合）