私はこれを調べていました

使用法：docker build [オプション]パス| URL | -

だからあなたが走れば

docker build -t my / things my-dockerfile

tarファイルが短すぎると文句を言います。

'PATH'オプションはドキュメント化されていないように思われるので、レガシーな意味があるのではないでしょうか。

つまり、PATHがファイルであり、Tarfileではないかどうかを検出するのではないかと思います。

個人的には、テストに使用するDockerfileのセットがあり、それらすべてを1つのディレクトリに配置し、完全なコンテキストを設定したいと考えています。

そのPATHは、特定のDockerfileではなく、ディレクトリを参照します。

ああ、それからそのディレクトリをタールにしてサーバーに送信します-かっこいいです！

そのため、isafileを検出し、dirをその中にタールアップしてから、そのtarball内のDockerfileを指定されたファイルに置き換えることができます。

または、同じ方法で-fを使用します-Dockerfile定義がペイロードとは別に存在できるようにします

今すぐテストがどのように機能するかを理解するために、それを試してみて、それが私のために機能するかどうかを確認してください

何もタールアップしません-PATHは、 Dockerfileがあると想定するディレクトリです。

それがそのPATHで行うすべてではありません-コードを読み取ると、「コンテキスト」はディレクトリを風袋引きすることによってサーバーに送信されます。

（わかりました、それで私はまだ行くのかわかりません、そして私は最後の数分間だけコードを読んでいるので、懐疑論の粒でそれを取ります）

正解です。ADDを介して参照される非リモートファイルも同じディレクトリにある必要があります。そうでない場合、デーモンはそれらにアクセスできません。

ああ、私はあなたが言っていることを理解しています-はい-それはまさに私が望んでいることです--fでdockerfileを指定する方法、そして別のディレクトリPATH。

だから私は持つことができました：

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108（Dockerfilesにincludeディレクティブを追加）は興味深いしわを追加します

インクルードは、指定されたdockerfileまたはPATHに関連している必要があります。 しかし、まだ重要ではありません。

楽しい：

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

追加のボーナスとして-CmdBuildテストはまだないので、最初に何を学ぶかを推測してください:)

@SvenDowideitあなたはこれに取り組んでいますか？ 今日はハッキングすることを考えていました

私はゆっくりとコードに慣れてきたので、それを試してみてください-ユニットテストを書くだけでとても楽しいです（おそらく、テストコミットを使用して助けることができます:)

私がやります:)

この機能も見たいです。 3つの異なるモードで実行できるシステムがあり、モードごとに1つずつ、3つの異なるコンテナーをデプロイしたいと考えています。 つまり、CMDだけが異なる3つの実質的に同一のDockerファイルです。 しかし、パスはディレクトリのみであり、ディレクトリはADDコマンドのコンテキストであるため、現在これを機能させることはできません。

だから：私から+1！

このように、＃1618と同じ最終目標があるようです（ただし、アプローチは異なります）。 ここで概説するように、複数のDockerfileとインクルードシステムではなく、複数のTAG命令を含む単一のDockerfileを使用して複数のイメージを作成するという考え方があります。 考え？

Dockerfileをパイプでつなぐことができれば、パスも指定できるはずです。 ＃1618がどうなるか興味がありますが、これはもっと多くの可能性を提供すると思います。

これが私がいる場所です： https ：

Dockerfileを含むディレクトリがビルドコンテキストであることがドキュメントに明確に記載されていないという事実に驚かされました-ビルドコンテキストが現在の作業ディレクトリであると誤って想定したため、代わりにDocerfileへのパスを渡した場合現在のディレクトリにあるので、現在の作業ディレクトリから追加しようとしたファイルは、「そのようなファイルまたはディレクトリはありません」というエラーで爆破されました。

同じエラーが発生します、任意のアイデア

docker build Dockerfile

コンテキストのアップロード

2013/12/11 21:52:32エラー：エラービルド：Tarballが短すぎます

@bscott docker build .代わりに

動作したThx !、異なるDockerファイルから選択したいだけです。

私から+1。

ソースから複数の画像を作成する必要があります。 各イメージは個別の関心事であり、同じコンテキストを構築する必要があります。 （＃1618で提案されているように）単一のDockerfileを汚染するのは不安定です。 ソースに3つの別々の<image-name>.dockerファイルを保持する方がはるかにクリーンです。

このようなものが実装されるのを見たいです。

これは、最初に思われるよりも実装が困難です。 ./Dockerfileはかなり焼き付けられているようです。最初の調査の後、少なくともこれらのファイルが関係しています。

api/client.go
archive/archive.go
buildfile.go
server.go

client使用archiveタールbuild contextし、それを送信server次に使用するarchive解凍しにbuild contextそして、バイトをbuildfile渡します。

最も簡単な実装では、 clientとarchiveを変更して、tarの./Dockerfileをこのオプションで指定したファイルで上書きする必要があるようです。 さらに調査します。

@thedeeno簡単に見て、変更を加える必要があることを示します。 一箇所だけだと思います。

私から+1！

私は＃1618と＃2112の両方をフォローしてきましたが、これは最もエレガントなソリューションです。

私の開発では、この機能が非常に便利な1つの特定のユースケースがあります...「Web」と「ワーカー」の両方の役割を持つアプリケーションで作業する場合。 この状況のた​​めに、「Dockerfile-web」と「Dockerfile-worker」の2つのDockerファイルを作成したいと思います。 次に、両方をビルドしてタグを付け、イメージリポジトリにプッシュすることができます。 次に、ロードバランサーと複数のワーカーの背後で複数のWebフロントエンドインスタンスを実行して、キューにプッシュされるタスクを処理します。

＃2745の代わりに+1。

+1

Dockerfileがハードコードされていること、およびビルドコンテキストがDockerfileのディレクトリに強制され、コマンドラインフラグを使用してもオーバーライドできないことに驚いた。 これにより、開発、テスト、およびデプロイツールとしてのDockerの有用性と柔軟性が大幅に制限されます。

+1
その変更をいただければ幸いです

+1
本当にこれが必要です。

5033はこの機能を許可する必要があります。 cc / @ crosbymichael

@shykesこの変更についてどう思いますか？ 私はあなたが同じ問題を解決するためのより良い解決策に同意したか、多分知っているとは思わない。

躊躇しています。

一方では、ビルドをカスタマイズする人々の能力を制限したくありません。

一方、_run -v / host：/ container_および_expose80：80_の場合と同じことが起こるのではないかと心配しています。 言い換えれば、それは彼らが何をしているのかを知っている1％がクールなカスタマイズを追加することを可能にします-そして他の99％はそれからかなりひどく足を撃ちます。

たとえば、通常のボリュームではなく、ホストにマウントされたボリュームから始める新しいDockerユーザーがたくさんいます。 また、正当な理由もなく、ホストごとに複数回実行できない画像を公開する人が多すぎるため、_expose80：80_構文を完全に非推奨にする必要がありました。

だから私の質問は：_dockerbuildで繰り返しビルドできないソースリポジトリがたくさんあるリスクはありませんか？

@shykesこのDockerfileの制限の_理由_であなたが説明する問題に遭遇しています。 以下にいくつかのユースケースを示します。

1. アーティファクト（この場合はJARファイル）を生成するDockerベースのビルド環境があります。 ビルド環境は実行環境とは異なります（依存関係の違い、イメージの拡大など）。したがって、ビルド環境をランタイムに継承したくありません。 Dockerfileビルドを使用するのが最も理にかなっています。そして、JARの周りでランタイム環境を実行します。したがって、ビルド環境をビルドして実行し、JARを作成する別のDockerfile.buildファイルがあります。ただし、Dockerfileを指定できないため、 scripts/buildを作成する必要がありました。 docker build < Dockerfile.build docker run -v ...を実行し、 scripts/buildファイル（パイプインされたDockerfileを使用してADDを使用できないため）。代わりに、 docker build -t foobar/builder -f Dockerfile.build 、 docker run foobar/builder 、 docker build -t foobar/runtime 、 docker run foobar/runtimeを実行し、両方のDockerfileでADDコマンドを使用できるようにします。
2. ONBUILD命令を使用して、FROM命令にルートDockerfileがあるが、プロジェクトのルートを次のように使用できるサブディレクトリにDockerfileを配置できるようにしたい（またはルートにDockerfile.envなどのファイルがある）それらのビルドコンテキスト。 これは、たとえば、さまざまな環境の構成パラメーターを取り込む場合に役立ちます。 ルートDockerfileは引き続き有用なコンテナーを生成しますが、他のコンテナーは必要なさまざまなバリアントを作成します。

ですから、私が本当に望んでいるのは、「ビルドコンテキスト」の概念を「Dockerfileの場所/名前」から分離できるようにすることだと思います。 もちろん、それを行うための潜在的な方法はたくさんありますが、これは私には比較的簡単な方法のように思えます。

@ cap10morganあなたの例1、またはそれに近いものを私に指摘できる可能性はありますか？ だから私は遊んで、同じことについて話していることを確認することができます。

@shykeshttps ：//github.com/shykesはまさにこの移植性の夢ではありません
それは画像インデックスが何のためにあるのですか？ ビルド環境が必要な理由
ポータブルでも？

一部のビルドプロセスでは、バニラで可能な以上のものが必要です。
Dockerfile。 さらに、コンテキストごとに1つのDockerfileを適用します（これが
このリクエストは修正を目的としています）は非常に制限されています。

これは本当に私たちのチームに影響を与えます。 私たちのセットアップでは、複数を生成したいと思います
同じ「コンテキスト」からの画像。 --fileオプションを追加することで、次のことが可能になります。
私たちが本当にやりたいこと- foo.dockerとbar.dockerを追加することです
リポジトリルートに。 代わりに、コピーするbashスクリプトを作成することになります
大量のファイルを一時的な場所に配置してコンテキストを確立し、名前を変更します
名前付きdockerファイルを魔法のDockerfileに入れて、 docker buildができるようにします
仕事。

私にとって、これらのフープは正当な理由もなく存在します。 私たちのチームの誰かが望むなら
イメージを構築するには、カスタムスクリプトを実行してジョブを実行する必要があります-
この制限に固執することで回避できると思う正確なこと。

4時23分PMに月、2014年4月7日には、ソロモンHykesの[email protected] ：

@ cap10morganhttps ：//github.com/cap10morganあなたが指摘できるチャンス
私をあなたの例1に、またはそれに近いものに？ だから私は遊ぶことができます
周りにいて、同じことについて話していることを確認してください。

このメールに直接返信するか、Gi tHubhttps：//github.com/dotcloud/docker/issues/2112#issuecomment-39778691で表示してください
。

@shykesは「修正されていない」ように見えるので、この問題に対処するためのドキュメントまたはDocker認定の方法の説明を指摘できますか？

私のユースケースは、Dockerを使用してビルドしたいアプリがあり、テストの要件が本番イメージとは異なる場合です。 これはかなり一般的だと思います。

これと.dockerignoreの問題（https://github.com/dotcloud/docker/pull/3452）（.gitディレクトリ全体をビルドコンテキストにコピーする）は、dockerを試してみるときに最初に遭遇する重大な問題点です。過去数日間の私たちのプロジェクトの中で、私には頭がおかしいようには見えませんが、これらの問題には反発があるようです。

これも必要に応じて+1します。単一のコードベースがあり、そこで複数のマイクロサービスが開発されています。 複数の画像を生成できるようにしたいと考えています。たとえば、services / base / *とservices / fooservice / *を含む1つの画像です。 また、services / base / *とservices / barservices / *、およびstaticfiles / *を含む別のイメージ。
Dockerはサービスフォルダー内にDockerfilesを配置できません。これは、Dockerがそのフォルダーをコンテキストとして扱い、フォルダー構造の上位にあるものを追加できないためです。 2つのDockerfileは同じ名前になるため、ルートに配置することはできません。
私たちが持っている唯一の解決策は、Dockerfileをサービスフォルダーに配置し、選択したDockerfileを解析するカスタムスクリプトを記述し、追加するパス（すべてプロジェクトルートに対して指定）を決定してから、それらを新しいものにコピーすることです。一時フォルダーで、選択したDockerfileをその新しいフォルダーのルートにコピーし、最後に「dockerbuildtempfolder」を実行します。 それは本当に必要ですか？
Dockerfileがどこにあり、コンテキストがどこにあるかを別々に「dockerbuild」に指示できれば、はるかに簡単だったでしょう。

この問題にも遭遇しました..ある種の修正を見たいと思います。

+1、この制限を回避するコーディングは大きな苦痛です。

ビルドコンテキストとは別のDockerfileパスを指定する-fフラグの+1

Dockerは非常に優れたツールですが、コンテキストと特定のDockerfileのこの緊密な結合により、Dockerチームは間違いなく少し汚染されます。 ディレクトリ構造は、必ずしも「コンテナ/サブシステム」構造を正確に反映しているわけではありません。

修正するのはどれくらい難しいですか？ そして、これにはいくつかのPRがありましたが、それらは無視されました。

関連する単純な追加は、コンテキストに追加したくないものの無視ファイルを用意することです-はい、あなたを見ています、.git .. ..

これにより、実際にはDockerをスキップして、Vagrant + Ansibleに戻る可能性があります。 良い。

@davber .dockerignoreは->＃6579にあります

しかし、はい、貢献管理は今少し苦痛であり、これまでのところ、Dockerについてのまれな失望の1つです。 うまくいけば、彼らは少し圧倒されていると思います。

Dockerチーム、どうすればこのようなことをレビューしてもらうことができますか？ なぜこれが本当に悪いのか、そしてプロジェクトがこの問題をどのように回避すべきかについて明確な考えがあれば、私たちはそれを聞きたいですが、これは説明するのは簡単な問題であり、解決するのは簡単な問題のようです。

/ cc @shykes @creack @crosbymichael @vieux

-fフラグの場合は+1。 また、ビルド設定をオーバーライドするDOCKERFILE環境変数。

@jakehowはい、確かに圧倒される要素があります。すべてのメンテナには、少なくとも1,000人が積極的に何かを要求し、なぜそれがまだ行われていないのかについての詳細な説明を要求しています。 私たちは本当に最善を尽くしています。＃dockerおよび＃docker-dev ircチャネルにアクセスすると、消防ホースを直接目にすることができます。

しかし、この場合、Dockerfileとソースディレクトリの1-1マッピングを維持する方がよい理由について明確な答えがあります。 もう一度繰り返します。Dockerビルドの自己記述型のプロパティを保持したいと思います。 _帯域外の他の情報なしで_ソースコードディレクトリをポイントし、それからアップストリーム開発者の仕様に正確に合わせてイメージを構築できるという事実は、非常に強力であり、Dockerの重要な差別化要因です。

確かに、ディレクトリXとDockerfile Yをオンザフライで動的に組み合わせることができるのは、やや便利です（ただし、その必要性を感じたことはなく、Dockerを頻繁に使用しています）。 しかし、それは愚かなことをするのを非常に簡単にします-つまり、あなたのビルドの自己記述的な性質を壊します。 そして、それは非常に貧弱なトレードオフのようです。 したがって、この機能を実装しないという決定。

「1つのソースリポジトリ、複数の画像」の例については、はい、確かにそれが必要であることに同意します。 必要なのは、単一のソースディレクトリで複数のビルドターゲットを定義するためのDocker標準の方法です。 これは、マルチパートDockerfileを使用するか、複数のDockerfileを使用して行うことができます。ただし、これらのDockerfileを明確にリストして選択できるように、明確に定義されたファイル名規則がある場合に限ります。

誰かがこれに貢献したいのなら、私たちはそれをマージしたいと思います。 そしていつものように、私たちは初めての貢献者を喜んでお手伝いします。IRCで挨拶してください。あなたが始められるようになります。

@davber Vagrantには、プロジェクトごとに1つの記述ファイルという同じ制限があるという印象を受けました（おそらく同様の理由で）。 Vagrantに戻すと、問題はどのように正確に解決されますか？

@gabrtvマルチイメージを取り戻してみませんか？ 暫定的な提案は次のとおりです。

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

その提案は私たちにとってはうまくいくでしょうし、他の人々にとっても他の問題を解決することがわかります。

@shykes Dockerfile形式の複雑さを増すことは、1つのDockerfileを維持するための価値のあるトレードオフだとは思いません。

makefilesを例にとってみましょう。プロジェクトに「Makefile」があるのが一般的ですが、makeでは「-f」を使用して別のmakefileを指定することもできます。

また、ソースフォルダーとイメージの間の1：1マッピングは、あなたが理解するよりも役に立たないと思います-ビルドフォルダーを生成し、その中からビルドして、コンテキストにコピーされたデータの量を維持するのが一般的であることがわかりました最小、したがってより小さな画像。

「つまり、私の質問は、Dockerビルドでは繰り返しビルドできないソースリポジトリがたくさんあるリスクを冒さないでください」と言うことです。

しかし、これはすでに当てはまると思います。一部のプロジェクト要件は、単一のビルド方法が実用的ではないことを意味し、Dockerfile構文では多くの構成可能性が許可されていません（設計上、変更したくない） ...）。

また、-onlyの提案は特に好きではありません。 ビルド時に/ want /するデフォルトは、すべてではなく特定のコンテキストをビルドすることだと思います。dockerbuildを実行するときは、/ only / Dockerfileを実行する必要があります。 しかし、私は/ can /を構築できる別のイメージを持つ機能も必要です。

私の理解によると、ここでの問題は、
Dockerfile（cat Dockerfile | docker build-）をパイプ処理すると、作業が失われます
ADDおよびCPのディレクトリ。

Dockerビルドのフラグを追加することで問題を解決します。
ソースフォルダの内容がどこにあるかを指定しますか？

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

この提案では、 --cwdフラグがADDおよびCPのベースフォルダーを指定します
コマンド。

2014-06-29 19:42 GMT + 10：00ピーターブレーデン[email protected] ：

あなたは「だから私の質問は：私たちはたくさんの情報源を持つ危険を冒さないでください
dockerbuildで繰り返しビルドできないリポジトリ」

しかし、私はこれがすでに当てはまると思います、いくつかのプロジェクト要件はそれを意味します
ビルドする単一の方法は実用的ではなく、Dockerfile構文は実用的ではありません
非常に多くの構成可能性を考慮に入れてください（設計上、私は望んでいません
変更すること...）。

また、-onlyの提案は特に好きではありません。 デフォルトだと思います
人々が構築するときに/欲しい/は、特定のコンテキストを構築することです。
すべてではありません-dockerbuildを実行するとき、Dockerfileに/ only /
実行されます。 しかし、私はまた、/ can /であることができる別の画像を持つ能力が欲しいです
構築されました。

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

@llonchjは実際にはhttps://github.com/dotcloud/docker/pull/5715でそれを（ある意味で）解決し、すでにマスターにマージされています。

@shykesは間違いなく別のマルチイメージPRにオープンですが、＃5715を見た後、この特定のPRがもう関連性があるかどうか疑問に思っています。

@peterbradenの元のコメントによると..

[コマンド編集済み]を指定して、ファイルを追加したり、複数のdockerfileを作成したりできると便利です。

@ cap10morganごと...

ですから、私が本当に望んでいるのは、「ビルドコンテキスト」の概念を「Dockerfileの場所/名前」から分離できるようにすることだと思います。

それはまさに＃5715がしていることではありませんか？ 私が理解しているように：

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

これではリポジトリルートからのマルチイメージビルドが解決されないことはわかっていますが（これはいいと思います）、この特定のPR /実装を＃5715で停止できるかどうか疑問に思っています。

@ gabrtv ＃5715は、常に機能する単一のコマンドを持つという@shykesの基準に適合していないように思われます。 tar -C subfolder -c . | docker build -t gabrtv/myotherimage -は、私には非常に自明ではありません。

さらに、リポジトリのレイアウトに関して、開発者に煩わしい（面倒ではないにしても）制約を課します。 修正不可能ではありませんが、「ああ、リポジトリ全体を再編成する必要があります」は、Dockerに切り替えるように上司を説得するのに役立ちません。

私は個人的に@shykesによる最新の提案が

実装によっては、ビルドコンテキストをすべてのイメージに一度だけアップロードできるため、複数のイメージをビルドするコストを削減できます。 私は.dockerignoreを持っていないので、ビルドコンテキストは数百メガバイトであり、コンテキストがアップロードされるまでかなりの時間を待たなければならないので、これは素晴らしいことです。

@rattrayalexは私を信じています、私は「常に機能する単一のコマンドを持つ」という目標に同意します。 コードを書いてPRを提出することになる可能性は十分にあります。 ：ウィンク：

私のポイントは、プロジェクト組織の観点から、 Allow specifying of a dockerfile as a path, not piping inというタイトルの引き出された問題ではなく、他の場所でその議論を行う必要があるということです。

1. ここでの議論のほとんどは、 https： //github.com/dotcloud/docker/issues/2112#issuecomment-47448314の@shykesの新しい提案とは無関係です。
2. 元の根本的な問題（ビルドコンテキストをDockerfileから分離する）は＃5715で対処されていますが、誰もが好むとは限りません。

@llonchjを引用...

私の理解によると、ここでの問題は、Dockerfile（cat Dockerfile | docker build-）をパイプ処理するときに、ADDとCPの作業ディレクトリが失われるという事実にあります。

つまり、 docker build -t <image> -f <path-to-dockerfile>で問題がなければ、 @ shykesプロポーザルのPRをまとめるまで、機能的に同等の回避策としてtar -C <path-to-context> -c . | docker build -t <image> -を使用できます。

これを閉じて、別の場所で新しいディスカッションを開始することをお勧めします（メーリングリスト？新しい問題？）。

今日この問題に参加してくれたすべての人に感謝します。

@shykesの推論に感謝します。 これが必要な理由（他の人がチャイムを鳴らすことができる）は、私たちの経験にあると思います。すべてのアプリケーションは、選択したコンテキストで実行するために帯域外情報を必要とします。 すべてのアプリケーションには複数のコンテキストがあります。 Dockerビルドの構造化により、アプリケーション開発者はその情報の知識をリポジトリ構造に移動するか、情報を含むDockerビルドの動作をオーバーライドするカスタムビルドスクリプトを作成する必要がありました。

@gabrtvここでの議論のほとんどすべてが特にこの問題に関連していると思います、そしてそれが最終的にここで議論されるのを見てうれしいです。 問題のタイトルといくつかの「発見」の投稿はおそらくわずかに無関係なので、これを参照するクリーンスタートの新しい問題またはPRはおそらく良いでしょう。

@shykesのコメントからの提案は、私にとっては解決策のように聞こえますが、これについて以前に行われた作業で、参照用に取得または確認できる場所はありましたか？

「Dockerfile.frontend-prod」の方が優れているので、すべてのDockerfileが
ディレクトリ内で自然に一緒にソートしますか？

申し訳ありませんが、それはばかげています。 私のリポジトリが100個のサービスを構築する場合、ルートに100個のDockerfileを置きたくないことは確かです。 （例：dotCloud PAASリポジトリ。）

100セクションの巨大なDockerfileも1つも必要ありません。

100個のDockerfileが必要で、それらを別々のディレクトリに配置したいと思います。

（いいえ、ほとんどすべてのサービスが各サービスのディレクトリの_outside_にある共通のコードとライブラリを使用するため、各サービスを独自のディレクトリに構築することはできません。）

繰り返しになりますが、Dockerfileへのパス（デフォルトはDockerfile ）を指定するための追加のフラグがあることがなぜそれほど重要なのか理解できませんか？

さらに、現在の提案（ <imagename>.Dockerfile ）は、自動ビルドの現在の設計とはまったく一致していません。 ビルドシステムのいずれかで1つのリポジトリが侵害された場合、攻撃者はすべてのリポジトリを過負荷にする可能性があります...？

@jpetazzoは最も合理的な人々のように私は意見の相違を歓迎しますが、愚かなと呼ばれることは嫌いです。 あなたの仲間の知性を侮辱することなくあなたの議論を提示するように努力してください。 ありがとう。

_繰り返しになりますが、Dockerfileへのパス（デフォルトではDockerfileのみ）を指定するための追加のフラグがあることがなぜそれほど重要なのか理解できませんか？_

私は上記で特定の議論をしました。 それを読んで、反論を提示してください。

Re：散らかっています。 @gabrtvはIRCについても同じ懸念を

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

同じ考えですが、ルートリポジトリにある個々のファイルは少なくなります。

さらに、現在の提案（.Dockerfile）は、自動ビルドの現在の設計とはまったくマッピングされません。 ビルドシステムのいずれかで1つのリポジトリが侵害された場合、攻撃者はすべてのリポジトリを過負荷にする可能性があります...？

さて、彼らは今どのように名付けられていますか？ プレーンなDockerfileだけを含む「abc」という名前のリポジトリがある場合、それによって生成された「abc」という名前のイメージの意味がわかります。 「Dockerfile.abc」と「Dockerfile.zzz」を含むリポジトリ「xyz」がある場合は、それらからビルドに「xyz-abc」と「xyz-zzz」という名前を付けるのが理にかなっています。

私もあなたと同じような状況にあり（それぞれが共通の部分を持つ独自のサブフォルダーにある多くのサービス）、ビルド時に使用するDockerfileを設定する明示的なオプションを使用すると、思考が容易になりますが、それでもわかります。 「Dockerfile。*」プロポーザルをすでにリリースされている「tarfileas context」と組み合わせて、必要なものを取得する方法-各サービスのルートdockerfilesは、ビルドイメージ（コンパイラーなどを含む）を生成します。実行されると、コンパイル済みの実行可能ファイルと、実行時の依存関係のみを持つイメージを記述する本番Dockerfile（サービスフォルダー自体から取得）を含むコンテキストのtarが出力されます。

実際、ビルド環境はすべてのサービスでほぼ同じであり、実行時にパラメーターを渡すだけで、作成するサービスリリースコンテキストtarを指定できるため、単一のルートDockerfileを使用してこれを記述しています。

@shykesよく、Dockerfile / *を

...愚かなと呼ばれるのが嫌い

「愚かな」が不快に感じられることを私は知りませんでした。 たぶん「不器用」という意味だったので、誤用してしまったことをお詫びします。

あなたの具体的な議論は、「人々がDockerfilesをランダムな場所に置き、厳密に必要でないときに-fを体系的に使用し始めてほしくない」というものだったと思います。 そうですか？ その場合、リポジトリの上部に1つのDockerfileを義務付け、他のDockerfileをリストすることは理にかなっています。 そのファイルが存在しない場合、ビルダーは操作を拒否する（または警告を発行する）ことができ、Dockerfileが1つだけリストされている場合、ビルダーは警告を発行することもできます。 ここでは、 -vと-pとの並列処理は適切ではないと思います。

@aigariusを実行すると、各サブDockerfileを子イメージにマップする方法がわかりにくくなります。 ./Dockerfile.*と./Dockerfiles/*の両方の利点は、結果の画像に名前を付けるために使用できる単一の名前空間にマップされることです。 対照的に、 ./foo/Dockerfile.dbと./bar/Dockerfile.db 、 docker build -t shykes/myapp .場合、どちらがshykes/myapp/dbと呼ばれますか？

どちらがshykes / myapp / dbと呼ばれますか？

ない。 このようなシナリオでは、Dockerfileへのフルパスを名前にエンコードするため、「shykes / myapp / bar / db」と「shykes / myapp / foo / db」が作成されます。 これはJavaの名前空間に不快に近づきますが、それが良いか悪いかは他の人に任せます。

@shykes ：Vagrantに関しては、私、そしておそらく他のかなりの数の人が、Dockerのいくつかの重複する機能にVagrantを使用しています。 したがって、私にとっては、Dockerfilesを使用するときに、現在のマルチマシンビルド（Vagrantで複数のマシン定義を使用して行う）がそれほど厄介にならないことを確信する必要があります。 重要なのは、Vagrantでは「コンテキスト」がはるかに柔軟であり、共有dirによって任意の場所からコンテキストをその場で取得できることです。言語もそうなので、1つのサービス（またはマシン）を構築したいだけの場合は環境変数を設定して「vagrantup / provision」することができます。 私は毎日その方法を使用して、システム内のいくつかのサービスを作成またはプロビジョニングするだけです。 また、増大するVagrantfileにイライラしすぎた場合は、個々のサービスまたはアスペクトを説明するサブVagrantfileを簡単に「ロード」できます。

複数のDockerfileを処理するための具体的な提案については、そうです。これにより、個々のサービスのロジックを分割できるようになります。 素晴らしい。 しかし、私はしばしば1つのサービスを分離して構築したい、または構築する必要があるので、特定のDockerfileを1つ指定する必要性に戻っています...

したがって、ここでの私の問題は2つあります。

1. すべてのサービスで巨大な乱雑なファイルを取得していない
2. そのファイル/ファイルのクラスター内に1つの特定のサービスを構築できること

繰り返しになりますが、Dockerは天才的なアイデアとツールなので、私のような人々には、特定の種類の機能やユースケースについてVagrantをあきらめてもらいたいと思います。

上記で徹底的に扱ったものを繰り返して申し訳ありませんが、「-f」オプションをサポートするよりもどのような解決策が優れているかわかりません。 つまり、コンテキストルートにあるDockerfileへの根深い依存関係に起因するモジュロ実装の問題ですが、不利な点は見られません。

'-f'オプションを使用すると、上記のDockerfiles /アプローチのように、サブディレクトリとサブDockerfilesを確実に構造化できます。 はい、正確な動作を模倣するには、単純な1行のバッシャーが必要になります...

共有と柔軟性の間には緊張関係があるようです。

共有が最も重要な機能である場合は、はい、標準のdockerfile
理にかなっています。

共有は最も重要な機能ではないと思います。 共有が実現されます
画像経由。

さらに、明示的に共有できないプロジェクトではdockerを使用します。 の
これらの場合、柔軟性は私たちにとってはるかに価値があります。 多くのように聞こえます
スレッドanyはこの同じ位置にあります。

目的の-fオプションは、必要な柔軟性を提供します。 反対に、
ビルドコンテキストの絶対パスを指定できることも
仕事。
2014年7月3日午後6時、「DavidBergman」 [email protected]は次のように書いています。

上記で徹底的に扱われたことを繰り返すと申し訳ありませんが、私は見ることができません
'-f'オプションをサポートするよりもどのソリューションが優れているか。 つまり、モジュロ
に深く根ざした依存関係による実装の問題
Dockerfileはコンテキストルートにありますが、不利な点は見られません
それ。

'-f'オプションを使用すると、サブディレクトリを確実に構造化できます
およびサブDockerfiles。ただし、Dockerfiles /などの任意のサブDockerfiles
上記のアプローチ。 はい、簡単な1行のバッシャーが必要になります
正確な動作を模倣します。

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

-fが最小限の「驚き」で最大の柔軟性を提供することに同意しました（私は個人的にそのようなフラグがあると思い、このスレッドに来る前にそれを試しました）。
ディレクトリまたはtarのいずれかで-c追加してコンテキストを提供することも、すばらしい追加のように思えます。 これにより、大規模なビルドプロセスから定数cdが削除されます。 企業で。

さらに、 docker build -f foo/bar/Dockerfile -c foo/への指示を含むREADMEは、私にとって不快に思われるようには思えません。
また、 docker buildがDockerfile簡単に検索できることにも同意しました。 このように、レポは次のように構成されています。

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

起こりうる名前の競合（ repo/bar/subbar ）を回避し、金額を簡単に推論でき、多くの開発コンテキストで意味をなすはずです。 これにより、多くのコンテキストを構築するdocker build 、ほとんどのコンテキストで無関係なDockerfileを省くことができるdocker build -fの両方を簡単に使用できるようになります。

-fがDockerを含むディレクトリではなくファイルである場合、それも機能するはずです。これにより、開発者はdocker build実行時にビルドされないdockerfileを使用できます。

これが失われないように、昨日@shykesとのIRCディスカッションで、彼はこれを実装することについて別のアイデアを持っていました。

• リポジトリのルートにマスターDockerfileがあり、生成される各イメージの「INCLUDE foo / bar / DockerfileASbar-foo」などの新しい形式の行が数行しか含まれていません。
• 個別のイメージを必要とする各サブプロジェクト（fooサブプロジェクトのbarモジュールなど）は、foo / bar / Dockerfileに通常のDockerfileを維持します。 そのDockerfile内のパス（ADDおよびCOPYの場合）は、リポジトリのルート（マスターDockerfileが存在する場所）であるコンテキストルートに引き続き相対的です。
• 「dockerbuild-t mycorp / myapp」への定期的な呼び出し。 ルートDockerfileに登録されているすべてのイメージをビルドし、この例では「mycorp / myapp / bar-foo」などの名前を割り当てます。
• 「dockerbuild-t mycorp / myapp --only bar-foo、baz-db」など、宣言されたイメージの一部のみをビルドするには、「dockerbuild」への追加のコマンドラインオプションを導入する必要があります。

人々がまだ回避策を探している場合に備えて：

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

@shykes ping？ 特定の設計ソリューションに対するコア開発者の承認がある場合、誰かがそれを実装してプルリクエストを行う可能性がはるかに高くなります。

-fソリューションに+1します。理論的には、各リポジトリが独自のサービスをデプロイする必要があることに同意します。 一部の人々はそのソリューションの贅沢を持っていません。 私の特定の問題は、複数のクックブックを含むシェフリポジトリがあり、多くのサービスを構築できる必要があることです。 ただし、上記のディレクトリを追加できる必要があります。 したがって、コンテキストをルートに保持し、サブディレクトリ内のDockerファイルを指すことが最適です。

「-f」は、すでに説明した理由により、おそらく実装されません。

ビルドはホスト間でまったく同じように機能することが不可欠であり、ホストを特定の方法でセットアップすることに依存するもの（つまり、ランダムな場所のDockerfileと他の場所のコンテキスト）があると、この契約が破られます。

＃7115がおそらくこれに対する適切な解決策だと思います

＃7204もあり、これもこのユースケースの多くに適合すると思います。

dockerfileに構文を追加することを含む2つの提案されたソリューションの両方が嫌いです。 どちらも簡単には見えません。 ＃7115は、たとえば、プロジェクトの1つで「テスト」画像を生成し、 「製品」の画像。 ＃7204は、別の問題を解決する非常に複雑なソリューションのようです-fは、ビルドに_configurability_を許可しますが、これらのソリューションは両方とも_sub_builds_に対応します。

「ビルドがホスト間でまったく同じように機能することが不可欠です」という説明が本当に必要です。 なぜこれがそのような重要な原則なのかわかりません。

現状では、この問題全体の回避策として、 makeを使用してDocker環境を生成しています。これは、ホスト間の実行の同じ命令にすでに違反しているようです。

私には、 -fは実用的な解決策のように見えますが、それが受け入れられない場合は、dockerfileを本格的なプログラミング構文に変換する必要のない解決策を考えることができます。

ビルドがホスト間でまったく同じように機能することが不可欠です

私もこれが重要な理由についてもっと知りたいです。 私たちのチームは現在
ビルドプロセスをスクリプト化することを余儀なくされました-あなたが避けようとしている正確なこと。

レジストリから画像をダウンロードすると、正常に機能します。 私はする必要はありません
それを構築します。 それはホスト間の再現性を達成していませんか？ なぜビルドするのですか
また、ホスト間で繰り返し可能にする必要がありますか？

10:43時月、2014年7月28日には、ピーター・ブレーデン[email protected]
書きました：

構文を追加することを含む2つの提案されたソリューションの両方が嫌いです
dockerfile。 どちらも簡単には見えません。 ＃7115
https://github.com/docker/docker/issues/7115まだそれのようには見えません
いくつかのタイプの画像を生成したいユースケースを解決します
たとえば、私のプロジェクトの1つで行っているように、単一のリポジトリから
'test'イメージと 'prod'イメージを生成します。 ＃7204
https://github.com/docker/docker/pull/7204は
別の問題を解決する複雑すぎるソリューション-fは許可します
ビルドに対する_configurability_、これらのソリューションは両方とも対応します
_sub_builds_。

「ビルドが機能することが不可欠です。
ホスト間でまったく同じ」。なぜこれがそのような鍵なのかわかりません。
原理。

現状では、makeを使用してdocker環境を次のように生成しています。
この問題全体の回避策は、すでに違反しているようです。
ホスト間で同じことを実行する必要があります。

私には、-fは実用的な解決策のように見えますが、それが受け入れられない場合は、
そうすれば、おそらく私たちは、
dockerfileを本格的なプログラミング構文に変換します。

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

私が理解している限り、重要なアイデアは、gitリポジトリをプルでき、そこにDockerfileが表示されている場合は、「docker build -tmytag」を実行できるということです。 その中に、完全な期待されるビルドを取得します。 ここで重要なのは、人々が間違えたり、知らなかったりする可能性のあるカスタムビルド手順がないことです。
妥協点となる可能性があるのは、単一のコンテキストで複数のDockerイメージを定義する方法です。デフォルトでは、すべてのイメージが事前定義されたサブタグで構築され、多くの可能なイメージのうち1つだけを構築するオプションがあります。
このようにして、共通のビルド構文が保持されると同時に、次の両方が可能になります。1）1つのコンテキストから多くの異なるイメージを生成する。 2）「詳細」オプションを使用してそれらの1つのみを生成することを選択します。
提案された構文は、上記の私のコメントで説明されています-https

@algariusに感謝します。この時点で、_INCLUDE_構文の新しい設計提案を開く必要があると思います。 設計提案の例については、＃6802または＃6805を参照してください。

プロセスは次のようになります。

• 設計提案を提出する
• 設計提案について話し合う
• 設計提案を承認します
• 設計提案のPRを送信

正直に言って、ビルドは現在実際には再現可能ではありません。

DockerfileにRUN apt-get update && apt-get install build-essentials ruby python whateverがある場合、私はすでに
イメージを作成した時点でリポジトリ内の「最新」のものは何でも。 もしも
1週間後にイメージを作成すると、さまざまなバージョンのイメージが得られる可能性があります。
私が得たものへの依存関係。

@codeaholicsしかし、それはバージョンをペギングしないためのあなたの

おそらく公正なコメント

@codeaholicsは、ビルドの再現性が完全ではないことは

再現性だけではありません。 ビルドが特定の引数のセットに依存していて、_docker build_で検出できない場合、カスタムツールはそれをビルドできる世界で唯一のビルドツールです。ネイティブで検出可能な_dockerbuild_。

＃7115の@peterbradenでは、複数のPUBLISH呼び出しの機能を追加すると、複数の画像を生成できるようになりました。 次に、構築するサブイメージを選択できるようにすることで、構成可能性を追加できます。 重要なのは、構成可能性が_Dockerによって検出可能なサブイメージのセット内で_行われることです。 そうすれば、発見可能性を維持できます。

@shykes >ビルドがDockerのアップストリームのサードパーティツールに依存する場合
それ自体...ビルドの再現性は基本的にゼロです。

同意します。 私のDockerfilesのほとんどはaptとaptリポジトリに依存していると思います
絶えず変化しています。 今日のビルドはビルドと同じではありません
昨日。 構築されたイメージは、唯一のゴールドスタンダードのimoです。

再現性が制限の主な理由ではない場合、CIプラグイン
サポートはかなり弱いフォールバックのようです。 ビルドツールは次のように設計されています
特異なユースケースをサポートします。 何もしないプラグイン
docker build cmdを構成するのはかなり役に立たないようです。 私のビルドツールは
すでにスクリプト環境。 さらに悪いことに、すべての可能性をシャベルで削る
Dockerfileの残業へのユースケースは、アーキテクトにとって悪い方法のようです
それ。 Dockerfileは、次の方法で新しいイメージを作成することに集中する必要があります。
ベースイメージにレイヤーを追加します。 他の作品はバンド外のようです。

これまでのところ、Dockerが大好きです。 素晴らしい仕事仲間！ この特定の問題はちょうど起こります
悩みの種になります。

12:25時月、2014年7月28日には、ソロモンHykes [email protected]
書きました：

@peterbraden https://github.com/peterbraden in＃7115
https://github.com/docker/docker/issues/7115 、機能を追加したら
複数のPUBLISH呼び出しの場合、複数の画像を作成できるようになりました。 次にあなた
ビルドするサブイメージを選択できるようにすることで、構成可能性を追加できます。
重要なのは、構成可能性が_のセット内で行われることです。
Docker_によって検出可能なサブイメージ。 そうすれば、発見可能性を維持できます。

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

@thedeeno Dockerfileの目標は、ソースコードリポジトリをDockerが実行できるものに変換する方法を指定することです。

「_a_Dockerfileの目標は、ソースコードリポジトリをDockerが実行できるものに変換する方法を指定することです。」はどうですか。

複数のリポジトリ->画像マッピングを作成する方法が本当に必要であることに同意できると思います。 現状では、私たちの多くはこれを行うためにシェルスクリプトとmakefileを悪用しています。 私の経験では、Makefileという名前のカスタムはあまり見たことがありません。構成とデフォルトは強力な力です。 このため、私は、コンベンションを悪用する人々が現実的なシナリオであるとは確信していません。

提案する代替案であるDockerfile構文にキーワードを追加すると、Dockerfileの作成がより複雑になります。 私はその構文をできるだけ単純に保つことに賛成です。 PUBLISH et alは、他のDockerfile構文と比較してエレガントではないようです。

既存のツール規則に従うという考えもあります。 すでに述べたように、-fは非常に一般的なパターンであるため、機能することさえ知らずに試してみます。 UIは直感的で、人々は_get_-fフラグを立てる必要があります。 新しいDockerfile構文を理解することは、それほど直感的ではありません。

@ peterbraden @ shykes私は-f

ソフトウェアをテストしたり、複数の環境でソフトウェアを実行したりしない状況でない限り、これはエッジケースではありません。 過去10年間に触れたすべてのリポジトリには、さまざまなコンテキストで実行できるようにする必要があります。 このスレッドの多くの人が同じ問題を抱えていると思います。 私たちは皆、（私が思うに）慣例を持つことは、アプリケーションのデフォルトのコンテキストにとって明らかに価値があることに同意しています（あなたがそれを持っていると仮定します）。

私は＃7115を（すばやく）読んで、それがこの問題をどのように解決するかを理解していません。おそらくこれはPRに関するドキュメントの問題ですが、伝達が難しい場合は、フラストレーションとエラーIMOが発生しますが、-fまたは同様のフラグは、正しく説明して使用するためにほとんど労力を必要としません。

そのINCLUDEのアイデアで新しい提案を作成しました-https ：//github.com/docker/docker/issues/7277

ちなみに、不格好な「RUN apt-get install -y ....」（その後、YUM、EMERGE、PACMANなど）ではなく、より効率的な「APT」コマンドを検討する価値があるかもしれません。

とにかく多くの人が実際に「-f」オプションを試してみることを考えると、それを使おうとすると、新しいソリューションを説明するドキュメントのページに移動するように指示する素敵なエラーメッセージが表示されると便利です。

私たちは本当に部屋の中の象を無視していると思います。

@shykesは、「帯域外の他の情報なしでソースコードディレクトリをポイントし、

これは、「ディレクトリにdocker build .と入力すると、常に正しいことが行われるはずです」と言うのと同じだと確信しています。これは、「明確な正しいことがないプロジェクトがある場合」と言うのと同じです。 docker build .やるべきこと、あなたは間違っている」

この問題を購読している他の人々の動機について話すことはできませんが、この問題に対する私自身の動機は、まさにdocker build .に明らかな振る舞いがない場合です。 デバッグバージョンまたはリリースバージョンが必要でしたか？ postgresを焼き付けたいのですか、それとも別々のアプリとpostgresの画像を出力する必要がありますか？ テストデータまたは本番データをロードしましたか？ テストを実行しましたか？

確かに、ビルドを取得するために人々がこれらの質問に答える必要がない世界に住みたいと思います。 しかし、私はその世界に住んでいません。 もちろん、これらの質問に対するいくつかの回答を任意に選択して、 docker build .動作を定義することもできます。 しかし、実際のところ、ユーザーがdocker build .と入力したときに任意の何かを構築することは、「正しいことをしている」わけではありません。

状況の現実は、構築する明確な正しいものがないプロジェクトがあるということです。 -fサポート、他の場所からインポートされたターゲットのリストからユーザーに選択させる、その他のさまざまな提案など、Docker内でこれを解決する方法はたくさんあります。 しかし、それらはすべて、設計上、 docker build .壊れるという特性を持っています。 ここには基本的なインピーダンスの不一致があり、それから抜け出す方法を提案することはできません。

すべてのプロジェクトがdocker build .実行するのに賢明なことを選択できるという考えは、幻想です。 賢明なことをすることができない可能性のあるプロジェクトが存在し、その数は多い。 この時点での唯一の質問は、Dockerがこれらのプロジェクトのマルチビルド製品の性質を直接サポートするのか、それともmakeやシェルスクリプトなどの従来のビルドツールにフォールバックするのかということです。 これは現在起こっています。たとえば、Dockerに分散された大規模なプロジェクトの1つであるDiscourseは、この問題を解決するために、自家製のビルドシステムを部分的に使用しています。

@drewcrawfordご覧のとおり、それがまさに問題です。 「dockerbuild。」 _the_イメージを構築する必要があります。 唯一無二の真のイメージ。 Dockerの実行パラメーターを変更して、唯一のイメージの動作をさまざまな環境に合わせて調整する必要があります。
このコンテキストでは、リリースバージョンが必要になる可能性があります。アプリだけで、他には何も必要ありません。 「postgresimage」のような他のすべてのものは、実行時にアプリにリンクされるさまざまなものです。 同じリリースイメージを取得し、デフォルト以外のコマンドで実行して、テストを実行できます。
理想的には、マルチイメージのサポートにより、「リリース」、「デバッグ」、「テストあり」のビルドから選択する必要さえありません。ベースビルドと3つの小さな違いのビルドが上にあるだけです。
Dockerを古い考え方に曲げようとすると、ひどい時間を過ごすことになります。 ドライバーでネジを叩こうとしないでください。

@algarius問題は、この考え方が実際のアプリケーションには当てはまらないことだと思います。ここでパラダイムシフトが実際に発生することになっている場合、どのように機能するかについては誰も説明していません。

複数のイメージを許可することは、ほとんどの実際のネットワークアクセス可能なアプリケーション（異なる依存関係を持つ複数の環境）の要件をサポートするための最も簡単で直感的な方法です。 これを解決するために、伝達できない方法で文法をより複雑にしているのでしょうか。 結局、ソフトウェアのエンドユーザーにほとんど説明を必要としない複数のDockerfilesのように簡単な方法で簡単に表現できる、異なる依存関係を持つ1つ以上の環境があるという事実を再設計して難読化するだけです。

@drewcrawfordは、Dockerサポートとともに配布されている現在の現実世界で人気のあるアプリケーションでこれがどのように処理されるかについての具体的な例を提供しました。 彼らはこれをどのように行うべきですか？

@aigarius 「

たとえば、本番環境には遅すぎる特定のロギングコードを条件付きでコンパイルする必要があるため、テストには別のビルド（正直な_recompile _）が必要になる場合があります。

これがmakeシステムの仕事のように聞こえる場合は、その通りです。実際、私のような人々は、実際のビルドシステムを使用してDockerビルドをスクリプト化する方法を見つけています。

ここでの問題は、Dockerfileをビルドに適したユーザーインターフェイスにすることも、 makeよりも大幅に強力にすることもできないことです。 これは、構築に適した、同様の機能を備えたユーザーインターフェイスにすることも、実際のユーザーインターフェイスとしてmakeなどを使用する低レベルのツールにすることもできます。 しかし、「実際の」ビルドシステムは恣意的に複雑ではありません。人々が機能を使用するために複雑になり、単純化されたDockerビルドの量がそれを変えることはありません。 発生するのは、dockerが新しいccになり、人々がmake呼び出すことだけです。

@shykes @drewcrawford @aigariusこのスレッドで前述した@shykesと同じ方法で、単純な-fオプションの提案を作成しました：＃7284

@drewcrawfordあなたが正しいです、ビルドのための好ましいユーザーインターフェースであるために、 docker buildは少なくとも例えばと同じくらい強力である必要があります。 make 。 これを行うには2つの方法があります。

• 1）makeのすべてのバリエーションのすべての機能、およびそこに作成するためのすべての代替手段（Maven、scons、rake、そしてもちろん古き良きシェルスクリプト）を再実装することを試みることができます。

また

• 2）これらのビルドツールはそれ自体が実行可能プログラムであることがわかりました。つまり、実行時の依存関係があり、ビルドの依存関係からビルドされたということです。 また、お気に入りのビルドツールを_実際に使用_する方法を提供することもできます。 したがって、実際にmakeをビルドして実行できるため、makeを再実装する必要はありません。

makeと言うとき、どのフレーバーのメイクを指しますか？ どのバージョン？ どのsvnチェックアウトから正確に構築されましたか？ どのビルドオプションを使用しますか？ どのlibcにリンクされていますか？ あなたも言及しているccについての同じ質問。 多分それは問題ではありません-多分あなたのアプリは私がそれを使って構築することになったmakeランダムなバージョンに関係なくまったく同じになるでしょう。 しかし、繰り返しになりますが、おそらくそれは重要です。 たぶん、私があなたとまったく同じビルドを取得する唯一の方法は、あなたが使用したのとまったく同じビルドのMakeとCcを使用することです。 そして、今日それを行う簡単な方法はありません-しかし、それが私がやりたいことです。

私は実際にはdocker buildをビルドツールとは考えていません。正確には、メタビルドツールとして考えています。これは、任意のビルド環境を確実に再構成できる既知の開始点です。 それが＃7115の動機です。

@shykes make、Maven、rakeなどから_すべての機能を実際に複製する必要はないと思います。結局のところ、これらのツールはお互いのすべての機能を複製するわけではなく、どういうわけかうまくいきます。

ただし、Dockerfileが現在よりも表現力豊かな言語になる必要があります（Dockerがイメージを構築するための優先ユーザーインターフェイスである場合）。

この号の提案は、実際にはその線に沿った控えめな動きです。「makeの_targets_に相当するものが必要です」と言っています。 「makeのどのバージョン」の問題は実際にはわかりません。「ターゲット」の概念は、make、Maven、rake、およびその他すべての本格的なビルドシステムに共通しています。 それらは異なる構文を持っていますが、機能自体が普遍的であるという事実は、これが人々が物を作るときに頻繁に行うことであるという手がかりになるはずです。

彼らが構築しているものがCプログラム、Dockerイメージ、またはその間のものであるかどうかは関係ありません-あなたはまだいくつかのターゲットを構築しています。 ビルドターゲットの考え方は非常に基本的であるため、ビルドシステムの実装、プログラミング言語、オペレーティングシステムにまたがっています。 ここでは、あいまいなGNU Make固有の機能を複製することについて話しているのではなく、可能な限り幅広い合意があるものについて話しているのです。

ここで「メタビルドツール」の概念を紹介しようとしていますが、そのようなことはありません。 dockerがmakeビルドをオーケストレーションできるのと同じように、makeもdockerビルドをオーケストレーションできます。実際、Dockerにビルドターゲットを指定する方法がないため、makeは現在そのように使用されています。 しかし、いずれにせよ、どちらのシステムも本質的に他のシステムよりも多かれ少なかれメタであり、それらはすべてターゲットをビルドする単なるビルドシステムですが、Dockerの場合、許可されるのは1つだけです。これが問題です。

＃7115のような提案は興味深いものですが、何かが足りない場合を除いて、ターゲットの効果的な代替にはなりません。 ターゲットは何を構築するかを教えてくれます。 ＃7115は、より柔軟なDSLを提供しますが、それでも1つのものしか構築できません。 それは何かですが、ここで要求されているものではありません。

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

@drewcrawfordは、dockerがMakeターゲットと同等の何かを許可したかどうかを確認するためだけに、1）ビルドするターゲットを指定できます。 make clean; make foo 、2）デフォルトで_all_ターゲットを構築し、3）ターゲットを列挙する方法があります...それで十分でしょうか？

それで十分です...すべてのターゲットをデフォルトにするのではなく、開発者が選択したターゲットをデフォルトにすることをお勧めしますが、どちらのソリューションも受け入れます

それはいいです。

@shykes @drewcrawford ：+1：

発生するのは、dockerが新しいccになり、人々がmakeで呼び出すことだけです。

この号の提案は、実際にはその線に沿った控えめな動きです。「makeのターゲットに相当するものが必要です」と言っています。 「makeのどのバージョン」の問題は実際にはわかりません。「ターゲット」の概念は、make、Maven、rake、およびその他すべての本格的なビルドシステムに共通しています。 それらは異なる構文を持っていますが、機能自体が普遍的であるという事実は、これが人々が物を作るときに頻繁に行うことであるという手がかりになるはずです。

@drewcrawford ：+1：+1,000,000

これが私が遭遇し続ける状況です：

リポジトリから2つのDockerコンテナを構築したいと思います。 たぶん、人はサーバーであり、人はデータベースです。 または、一方がサーバーで、もう一方がAPI呼び出しを介してサーバーに対して自動テストを実行するクライアントである可能性があります。

いずれにせよ、これらのコンテナの両方に追加する必要のあるファイルがリポジトリにあります。 現状では、bashスクリプトで個別のDockerfileを一度に1つずつコピーし、ビルドを実行してから、Dockerfileを置き換えるか削除しない限り、これを行うことはできません。

私はどちらかが必要です：

1. Dockerfileとして使用するファイルを指定する-fコマンド。
2. Dockerfileのダウンパスではなくファイルを追加する機能。

ナンバーワンはノーゴーだと繰り返し言われていますが、ナンバー2は技術的にさらに難しいと思いますが、これを行うための「適切な」方法は何でしょうか。

@ShawnMilo

@shykesの最後のコメントは、これがかつてほど不快ではなくなったことを示しているように見えましたが、既存の提案が適切であるか、そうでない場合に何を変更する必要があるかについてはまだ不明です。

@jakehow更新していただきありがとうございます。 したがって、問題の公式な修正はまだ遠いようです。 それまでの間、それを行うための「良い方法」はありますか？ 私が持っている最良のアイデアは、ファイルを一度に1つずつリポジトリルートの「Dockerfile」にコピーしてイメージをビルドするbashスクリプトです。 動作しますが、汚れた感じがします。

@ShawnMiloはい、ほとんどの人がビルドツール（make、rakeなど）または単なる古いbashスクリプトを使用してこれを行っていると思います。

誰かの上に、これも処理するビルダー画像があるスニペットが表示されました。

これがこの問題に対処する私の方法です。 プラットフォームのさまざまなバージョン（たとえばv2とv3）のイメージを作成する必要があります。 だから私はDockerfile.v2とDockerfile.v3を持っていますビルドを作成したいときは最初にln -s ./Dockerfile.v3 ./Dockerfileを実行し、次にdocker build .実行します実際にはスクリプトがあり、 ./build v3実行するだけですまたは./build v2

現在、指定されたDockerfileを./Dockerfileにリンクするスクリプトを使用していますが、これは優れた機能です。

これに対処するためにPR＃7995を作成しました。 この（長い:-)）スレッドで説明されている解決策のいくつかは、人々が使用するのにひどく苦痛に思えます。 Dockerの（私にとっての）最大のセールスポイントの1つは、使いやすさでした。そのため、この種のフープを飛び越えて、非常に簡単な質問のように感じることを人々に求めるのは正しくありません。

さて、何かが足りない可能性がありますが、「Dockerfile」という名前にする必要がある技術的な理由はありますか？ PRを作成しているときに見つかりませんでしたが、簡単に変更できることに嬉しい驚きを覚えました。

@duglinあなたは私のすべてのサポートを持っています。

これは、現在のプロジェクトで-fオプションが不足していることを回避するために行っていることです。

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

これを-f追加に対する+1と考えてください。

現在、キキトなども管理しています。 同じコンテキストから異なるイメージを構築するためにいくつかのシェルスクリプトを作成しましたが、すでに提案されているように、CLI引数からdockerファイルを指定する方法を知りたいと思います。 このリクエストの+1。

+1000

Dockerを使用してクロスプラットフォームのgolangプロジェクトを構築しようとしたときに、今日これに遭遇しました。 これは機能します。boot2dockerを参照してください。Dockerビルドプロセスの内部と外部をつなぎ合わせるためにMakefileが必要です。Dockerの内部からビルドディレクトリへのアーティファクトのdocker cpです。

ただし、これをリポジトリのサブディレクトリで使用しようとすると、リポジトリルートの.gitフォルダがないため、 GOPATHが壊れます。 リポジトリルートをADDてから、サブディレクトリ内にビルドする必要がありますが、これはdockerでは許可されていません。

この長いスレッドを読んだ後、ビルドを再現できないという懸念がありました。 これを軽減できる1つの方法は、 -fオプションのみがビルドコンテキスト内またはそれ以下を指すようにすることです。 このようにして、サブディレクトリに複数のDockerfileを置き、リポジトリルートからそれらを構築できます。 さらに、これをリポジトリの境界内に制限することもできます。たとえば、.git / .hg / .fooと同じレベル以下で、リポジトリの外側には制限できません。

これが私が考えていることです

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

これにより、3つの画像が生成されます。

1. 「myimage」と呼ばれるメイン画像。例として、実際には何も含まれていません。
2. myimage-myname1という画像
3. myimage-myname2という画像

BUILDキーワードは、名前とDockerfileへのパスを取ります。 このDockerfileは、元のコンテキスト内にある必要があります。
各ビルド命令は、メインビルドから完全なコンテキストにアクセスできます。
Dockerfileが含まれているdir-treeにコンテキストを制限することは価値があるかもしれませんが。

-1

この特殊なケースでは、 dockerfeedのようにコンテキストフィーダーを使用してdocker build -することができます。

@itsafire重要なのは、このタイプの機能をDockerに組み込んで、プロジェクトをビルドするためのサポートされた方法にすることです。 自動化されたビルドでもこれが機能することを人々は望んでいると確信しています。

私はここで途方に暮れています。 この追加機能に対するプルリクエストがいくつかありますよね？ そして、それは難しいことではないように見えます... @maxnordlundが言及したルールを強制することさえできます：パスをコンテキスト/ルートに相対するように制限します。 これにより、少なくともboot2docketなどでよりスムーズに動作し、「ポータブル」になります。

これはDockerで最も苛立たしいギャップであり、機能の一部としてDockerを使用するツールが増えるにつれ、これらのツールに対応できるように「-f」フラグの機能をすばやく追加することが重要です。これらの関連する「メタ」ツールは、Dockerfileごとに1つのイメージを想定していることが多いため、マルチイメージのDockerfileを使用してもカットされません。 また、「-」を使用しても、これらのツールではうまくいきません。また、ご存知のとおり、機能が大幅に制限されます。

権限のある人が、この修正がまだマージされていない理由、または少なくともこのひどく欠けている機能がまだ存在しない理由を説明できますか？

トワイライトゾーンのように感じ始めています。

DockerチームがDockerを使用する方法/ Dockerの使用を希望する方法と、コミュニティの大部分がDockerを使用する方法に不一致があると思います。 私が間違っている場合は私を訂正してください。

Dockerチームは、Debianプロジェクトのリポジトリとそれほど変わらないソフトウェアリポジトリを構築したいと考えています。 人々がお気に入りのソフトウェアを入手して簡単に実行できる場所。 ソフトウェアのビルドプロセスは、再現性があり、明白である必要があります。

他の人は、既存の社内ソフトウェア展開を自動化したいと考えています。これは、多くのビルドツール、CIシステムなどですでに非常に複雑になる可能性があります。彼らにとって、Dockerはインフラストラクチャに適合しなければならないもう1つのツールです。 また、Dockerの使用方法にもう少し柔軟性が必要です。

Docker（.debなど）は両方のニーズを満たすことができると思いますが、妥協する必要があります。

基本的な問題は次のとおりです。これはどこで終わりますか？ Dockerfileのチューリング完全性？ おそらくそうではありません。 特別な場合を解決するには、常に柔軟性を高める必要があります。 Dockerfile言語に入るアイデアもあれば、そうでないアイデアもあります。 dockerはビルドでstdinを介してコンテキストを食べることができるため、不足している機能はプリプロセッサーを介して実装できます。

@itsafire前回チェックしたとき、 Dockerfileを食べることができますが、コンテキストは食べられません。 実際、Dockerfileをそのように指定すると、コンテキストは無視されます。 彼らがあなたが提案したことに対するサポートを追加した場合、これはクローズドな問題になるでしょう。

しばらく調べていませんが、基本的なリクエストは次のとおりです。ビルド中にDockerfileとcontext両方を指定する明示的な方法を教えてください。 正直なところ、これは8か月後のようで、まだ開いています。

@thedeenoこれは確かに可能です
cat mystuff.tar.gz | docker build -

@ cpuguy83しかし、そのコマンドで明示的なDockerfileを提供することはできません。 右？

@thedeenoはい、必要なコンテキストで必要なDockerfileをタールアップします。

@ cpuguy83 @thedeenoいいえ、それは機能しません。これは、Dockerfileで通常取得する「cwd」スコープにファイルがないため、ファイルを追加できないためです。

編集：このステートメントは間違っています。 @ cpuguy83の例を誤解しました。

@ShawnMiloはい、そうです。 タールの中のものはすべてコンテキスト内にあります。

@ cpuguy83申し訳ありませんが、私の間違いです。 tarball全体ではなく、Dockerfileをパイプするだけであると急いで読みました。

@ cpuguy83いいね！ あなたが提案するようにそれが機能するならば、私はそれから近くに投票します。

副次的な質問ですが、私のカスタムソリューションでは、タイムスタンプが風袋引き時にキャッシュを破壊しました。 それはまだ問題ですか？ 同じフォルダを複数回tarすると、ビルド時にキャッシュが使用されますか？

これからもいい結果を出し続けてください！

コンテキスト全体をパイプすることは、上記で説明したことをまったく軽減しません。

私たちが必要としているのは、さまざまなDockerfileで_same_コンテキストを使用する方法です。 前述の「ロギングありビルド」や「ロギングなしビルド」など、個別のイメージとして。 これが必要な他の多くのユースケースがあります。

ディレクトリをタールボール化することがこれにどのように役立つかわかりません。 はい、特別なディレクトリを作成してそこに特定のDockerfileをコピーしてから、コンテキストディレクトリ全体をコピーするか、tarして新しいDockerfileを追加してからgzipすることができます。 しかし、dockerを実行する前に正しいDockerfileを配置するプリプロセッサスクリプトを使用するという現在採用しなければならない[かなりひどい]回避策よりも、どのように簡単ですか？

そして、私が上で述べたように、これはDockerエコロジーには役立ちません。

私は何かを逃したことがありますか？

繰り返しますが、単純な「-f」オプションです。 お願いします。 どうぞ、かなりお願いします。 コンテキストの相対パスになるように強制します。 それは結構です。

@davber本当に必要なのは、DockerがコンテキストとDockerfileのtarballを処理することです。
そして、私はこれに完全に反対しているわけではありません。 ネストされたビルドがこれに対するより良い解決策かもしれないと思いますが。

@ cpuguy83 ：はい、Dockerに処理してもらいたいのですが、そうです。これには、ある場所からコンテキスト部分を選択し、別の場所からDockerfileを選択するか、非標準の名前を使用することが含まれます。 つまり、個別の '-f'フラグをサポートします:-)

ネストされたビルドは、このスレッドを開始した問題を解決せず、継続します。

つまり、同じルートコンテキストを使用したいのです。

はい、ファイルをコピーできます。はい、これを回避するために、コンテキストと「Dockerfile」という名前の正確なDockerfileとの奇妙な結合を回避します。 しかし、それは理想的ではなく、ファイルが実際に元のファイルと同一であることを確認するためにrsyncを設定するのは奇妙なことです。

@ cpuguy83 ：ネストされたビルドが私、またはここにある他の「泣き言」にどのように役立つかを説明できますか？ :-)

@davber
私の見解はこれです：

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

この：

docker build -t myimage .

「myimage」、「myimage-myname1」、「myimage-myname2」の3つの画像が生成されます。
各内部ビルドは、絶対パスとして完全なビルドコンテキストにアクセスできます。 相対パスはDockerfileを基準にしています。
そして、「myimage」は、BUILDの指示だけでなく、独自のものを持つこともできます。

前に述べたように、より優れた（そして素晴らしい！）Dockerエコロジーの多くの新しいツールは、各Dockerfileが正確に1つのDockerイメージに関連付けられていることを前提としています。 そこにあるさまざまな「イチジク」のようなオーケストレーションツール。 また、Dockerを特別にサポートする新旧のクラウドソリューションの多くにも、この1対1の前提があります。 確かに、「-f」オプションによって作成された世界では、コンテキストを取得する必要があります（たとえば、tarボールなど）だけでなく、場合によっては別個のDockerfileも取得する必要があります。 ただし、そのような各アップロードは、1つのDockerイメージに正確に対応します。

Dockerfileをコンテキストルートから分離する可能性のあるルートを使用する場合、これらのツールがこのシナリオで機能し始めることを願っています。

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

コンテキストのトップレベルでの「Dockerfile」のこの強力な結合に長くとどまるほど、エコロジーに深く根付いたものになります。 つまり、Dockerの世界は一般的な素晴らしさのために迅速に動くので、今すぐ行動する必要があります。

そして、正直なところ、Dockerfilesとイメージの間に同型性があるというのは合理的で概念的に魅力的な仮定です。前者は厳密にコンテキストディレクトリ（風袋引き...）とDockerfilesの製品スペースであり、デフォルトは（null、 file）Dockerfileのみが提供されている場合、および（context、context / 'Dockerfile'）コンテキストのみが提供されている場合。

そして、ローカル展開の場合でも、少なくともローカルオーケストレーションにFigを使用したいとします。それをどのように行うのでしょうか。 このようなマルチビルドDockerfileからイメージを事前に作成してから、図のそれらのイメージを参照する必要があります。最適ではありません。

Dockerfilesと画像の間の同型

このスレッドの人々がDockerfilesをどのように使用しているかについては、この仮定はすでに破られています。 つまり、Dockerビルドを実行する前に、スクリプトを使用してDockerfileを手動で置き換えます。 また、おそらく独自のオーケストレーションも用意されています。 この機能リクエストは、Dockerランドスケープを変更することではなく、特定の種類の用途でDockerを機能させることを目的としています。

@hanikesn ：2つのコメント：

1. ビルドする前にDockerfilesを所定の場所にコピーする必要があるため、その仮定が破られるのはなぜですか。 それでも1つのDockerfile <-> 1つのイメージになりますか？
2. 私が主張しているのは、ここで思いついたソリューションがあれば、このランドスケープに大きな変更を加えることなく、既存の成長中のDockerランドスケープと_連携_したいということです。 そして私は、同型写像が言及したことを_維持_することによって、そうしていると思います。

ここでの他の提案は、1つのマルチイメージDockerfileを作成し、サブDockerfileを呼び出す可能性があることです。 これは、ほとんどのツール（図など）が現在Dockerを使用している方法では機能しません。

@davber

ネストされたビルドは、このスレッドを開始した問題を解決せず、継続します。

私はすでに前に指摘したこの解決策を提案します：

$ docker-pre-processor [ --options ... ] . | docker build -

--optionsはルールですが、（ここでは）現在のディレクトリのコンテキストが変更されてdockerに渡されます。 これは、コンテキストを含む一時的なtarアーカイブを作成することにより、その場で実行する必要があります。 そうすれば、ソースコンテキストは変更されないままになります。 Dockerfile構文よりもプリプロセッサを変更する方が簡単です。

@itsafire

今日Dockerfilesを期待しているツールはどうですか？ それらは、AmazonやGoogleなどを使用してより豊富になっています。 そして、Figと同様のオーケストレーションフレームワーク。

次に、標準化された「docker-pre-processor」ツールとそのようなツールの使用を、それらのフレームワーク、プロバイダー、およびツールにプッシュする必要があります。

少なくともこのスレッドをトリガーするオプションを「docker」で適切にサポートする方がはるかに簡単です。

@itsafireこの問題を解決したすべての人は、この目標を達成するために、Dockerビルドの周りに何らかのプリプロセッサまたはラッパーをすでに使用しています。

この状況をめぐる断片化は、 @ dockerチームが表明した「再現性」という目標と矛盾しています。 この議論と他の議論は、この問題の解決についてです。

1年以上と130以上のコメントと、ほとんどのユーザーに影響を与える単純な問題を数えています...私は感銘を受けました。 Dockerさん、これからもよろしくお願いします。

+1

ツールは、人々が自分のやり方に従うのを助けるべきですが、「正しい」やり方を課すことはできません。 私をこの議論に導いた単純なケース：

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

私の方法は、プロジェクトのルートをクリーンに保つことです。 ただし、 ADD ../srcと-f deploy/Dockerfileは機能しません。 今のところ、プロジェクトルートにDockerfileと.dockerignoreがありますが、それは私にとって苦痛です。

私の側では、 .dockerignoreファイルがADDによって無視されるという問題が発生したため、必要なファイルを含むフォルダーを準備し、標準のコマンドラインdocker build -t my/image .を実行するスクリプトを作成しました。 ADD ..。

+1は、1つのリポジトリに複数のDockerfileを含めることができるようにすることを確実に望んでいます。 私のユースケース：1つのイメージは本番環境での使用と展開用であり、別のイメージは同じバックエンドツールとデータベース接続を使用するように設計されたレポートインスタンスですが、フロントエンド、Web、システムサービス、またはプロセスの監視は必要ありません...

このために+1。 サーバーごとに、同じフォルダーの別のイメージにファイルを追加する必要があります。

+1これまでDockerを楽しんでいますが、チームのセットアップ方法が原因で、1つのリポジトリから適切なコードチャンクを共有するさまざまなデプロイ可能ファイルを構築する方法が本当に必要です。 それらすべてをuberdockerコンテナーに組み込むことには特に熱心ではありません。その場合、それらのデプロイメント/リリースサイクルは不必要に結び付けられます。 これを回避するためのベストプラクティスは何ですか？

@jfgreen ：複数のDockerfileを好きな場所に配置し、好きな名前を付けます。 次に、それらを「./Dockerfile」としてリポジトリルートに一度に1つずつコピーし、「docker build」を実行してから、それらを削除するbashスクリプトを用意します。 それは私が複数のプロジェクトに対して行っていることであり、それは完璧に機能します。 データベース、ベース、テストなど、すべてDockerfilesという名前のファイルを含む「dockerfiles」フォルダーがあります。

@ShawnMiloありがとう、それは非常に合理的な回避策のようです。

+1

+1

+1から-f 。 フラグが省略された場合、Dockerが_正しいことを行う_という正しいデフォルトがあります。_何らかの理由で_正しいこと_の非常に具体的なビューがユーザー_間違ったこと_である場合、 -fます。 上記のmakeようなツールとの比較は妥当だと思います。 makeも、もともと1976年に書かれた非常に意見の分かれたユーティリティであり、機能セットを安定させるのに十分な時間がありました。 man makeで、非常に簡単な概要で言及される唯一のフラグは... -fことが有益だと思います。

       make [ -f makefile ] [ options ] ... [ targets ] ...

意見の分かれた、UX中心のユーティリティには問題はありませんが、 -fようなものは、ユーザーが住んでいる現実世界への実用的なうなずきです。ツールは、あなたの生活を難しくするのではなく、楽にするはずです。 -fなしでツールを回避するためにMakefileまたはシェルスクリプトを作成する必要がある場合、それはツールの失敗です。 コメントに時間をかけ、+ 1に加重したユーザーの数から明らかなように、この機能は最初に提案されてから1年経っても大きな有用性を持っています。

+1

+1（または推奨される回避策を含む公式ブログ投稿）

+1

+1

@ crosbymichael ＃9707がマージされたため、これを閉じることができると思います

勝利。

この新機能を試してみたい場合は、マスター用のバイナリを次の場所からダウンロードできます。

master.dockerproject.com

ありがとう@duglin ！

：拍手：

バイナリをありがとう@crosbymichael ！ ：+1：

よくやったみんな！ ：拍手：

それでdocker build -f Dockerfile.dev .ですか？ 編集：うん