あなたはそれらを連鎖させます:)

したがって、たとえば、ジェネリックpostgresクライアントとジェネリックpython app envをセットアップするDockerfileが1つある場合、そのビルドの結果にタグを付け（たとえば、 mygenericenv ）、後続のDockerfileはFROM mygenericenv使用します。

例えば

## Dockerfile.genericwebapp might have FROM ubuntu
cat Dockerfile.genericwebapp | docker build -t genericwebapp -
## Dockerfile.genericpython-web would have FROM genericwebapp
cat Dockerfile.genericpython-web | docker build -t genericpython-web -
## and then this specific app i'm testing might have a docker file that containers FROM genericpython-web
docker build -t thisapp .

私はそれを行う方法、つまりgenericA --> specificAを見ることができますが、次のようなことを行う方法はありますか？

genericA --
            \
             ---> specificAB
            /
genericB --

？

公式の手段ではありませんが、これを達成するために画像階層を手動で変更することができた人もいます（ただし、これを行う場合は、自己責任で行ってください。すべての部分を保持できます）。

これが公式にサポートされない理由は、私が「ubuntu」を取り、「centos」を上に移植したいと想像するためです。 サポートの悪夢を引き起こす本当に楽しい衝突がたくさんあるので、そのようなことをしたいのであれば、あなたはあなた自身です。

わかりました。理由がわかります。 構成可能な機能ブロックを探していましたが、これはDockerのユースケースではないかもしれません...生のコンテナーをセットアップするためにそれを使用し、その上でansibleやsaltstackなどを実行してソフトウェアを構成する必要があるようです。

コンテナの背後にある考え方は、実際の構成の最小単位がコンテナであるということです。 つまり、コンテナは、他に何と組み合わせるかわからないまま、事前に作成できる最小のものであり、コンテナがどのように動作し、他のコンポーネントと相互作用するかについて強力な保証があります。

したがって、コンテナよりも小さいユニット（Rubyまたはシェルスクリプト、C ++ソースツリー、それ自体のバイナリ、構成ファイルのセット、システムパッケージなど）は、動作するため、安全に構成できません。ビルドの依存関係、実行時の依存関係、およびコンポジションの一部である他のコンポーネントによって、非常に異なります。

その現実は、ブルートフォースによって部分的に覆い隠される可能性があります。 そのような総当たり攻撃は、実用的で「十分に良い」（アプリのよりポータブルなビルドのためにすべてを自動検出する巨大なMakefile）または過度に壮大な（「コンポーネント間のすべての依存関係と干渉のすべての可能な順列を事前にモデル化して、表現する」ことができますそれらを高レベルの抽象化で！ "）

「コンポーザブルコンポーネント」を作成するためにAnsible、Chef、またはその他の構成管理に依存している場合、リークのある抽象化に依存しています。これらのコンポーネントは実際にはコンポーザブルではありません。 あるシステムから次のシステムへと、100万通りの動作が異なるビルドを生成します。 最終的にすべての余分な抽象化はあなたをほとんど買わないでしょう。

私のアドバイスは、1）ソースコードと2）実行可能なコンテナの2つに焦点を当てることです。 これらは、構成の2つの信頼できるポイントだけです。

13:46の日、2013年12月29日には、anentropic [email protected]
書きました：

わかりました。理由がわかります。 構成可能な機能ブロックを探していましたが、これはDockerのユースケースではないかもしれません...生のコンテナーをセットアップするためにそれを使用し、その上でansibleやsaltstackなどを実行してソフトウェアを構成する必要があるようです。

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

より多くの視点を与えてくれてありがとう。

つまり、Dockerfilesの一部を再利用するために利用できるツールは、コピーアンドペーストだけだということですか？ 「ops」の観点よりも「dev」の観点から来ると、少し間違っているように感じます。

画像の公開インデックスを持っているのは間違いかもしれません。シェフのレシピに漠然と類似した再利用可能なビルディングブロックを共有できるように見えますが、これまでの私の経験では、次の理由で役に立ちません。
a）ほとんどの画像について、それが何をするのか、そして何が中にあるのかについての情報はありません
b）ドキュメントはあなたの作品をインデックスにコミットすることを奨励しています（後でそれを引っ張ることができます）あなたが作ったものはおそらく他の人には役に立たないでしょうが、そこにあるもののほとんどはおそらく共有する価値がないと思います

現時点では、ドキュメントがDockerを賢明な方法で使用するように実際にガイドしていないように感じます

@anentropic Dockerfilesでこれを行う正しい方法は、複数のDockerfilesで複数のイメージを構築することです。
次に例を示します。Dockerfile1はUbuntuベースイメージの上に汎用イメージを構築し、Dockerfile2はDockerfile1の結果のイメージを使用してデータベースサーバーのイメージを構築し、Dockerfile3はデータベースサーバーイメージを使用して特別な役割に構成します。 。

docker buildは非常に簡単に実行でき、不必要な複雑さを追加しないでください。

画像の公開インデックスは非常に便利です。 Dockerイメージは通常、個別のコンテナーで実行できない1つのサービスまたは一連のサービスを実行することを目的としています。 通常、イメージをプルして実行し、多くの労力をかけずにいくつかの便利なソフトウェアを起動して実行できます。

理解しました...上記のアスキーアートで概説したシナリオでは、Dockerの方法は次のようになります。

• 独立したイメージGenericAおよびGenericB Dockerfilesから始めます
• 画像にするためにSpecificAB私はの内容をコピーして貼り付けますGenericB ：開始とのこと新しいDockerfileにDockerfileをFROM GenericA

私が見ている問題は、 GenericBの「レシピ」（シェフの用語を借りる）が非常に複雑で多くのステップがある場合、DockerfileをGithubに公開する以外に、この情報を共有する方法がないことです。他の人が関連する部分を自分のDockerfileに_コピーアンドペースト_できること。

パブリックインデックスを使ってみましたか？ たとえば、「postgres」を検索しました...次のような画像の有用性を判断する（または何らかの方法で区別する）にはどうすればよいですか？

• https://index.docker.io/u/cthulhuology/postgres/
• https://index.docker.io/u/alvin/postgres/
• https://index.docker.io/u/antihero/postgres/
• https://index.docker.io/u/dbraden/postgres/

？

危険なものが何も隠されていない特定のベースイメージで、Postgresサーバーを希望どおりにセットアップしたことを確認する唯一の方法が、自分でゼロから作成することである場合、これらはどのような価値を提供しますか。

公開インデックスで、いくつかの「公式に祝福された」ベース画像の価値を見ることができます。 自分のカスタムイメージのプライベートインデックスをプルする準備ができていることの価値を理解できます。

しかし、Dockerfile内の一連のコマンドをレシピとして共有する方法が（コピーアンドペーストを除いて）ないのは残念なことのようです...ここで拒否された「include」コマンドの提案などhttps：// github .com / dotcloud / docker / pull / 2108

@anentropic信頼できるイメージを使用できます。また、postgresDockerfileを見つけてイメージを自分でビルドすることもできます。

通常、イメージは、Dockerfileをカスタマイズして、正確なニーズに合うようにする場合に役立ちます。 そのため、同じソフトウェアのイメージをレジストリにアップロードするユーザーが増えていることがわかりました。

postgresイメージのような既存の特定のイメージは、特定のニーズを満たさない場合がありますが、ベースイメージもあり、これらをすぐに使用して、便利なものを作成できます。

ベースなどの画像ubuntu 、 centosとから一部の画像stackbrew/*あなたが必要なものを構築するために使用できるイメージです。

すぐに使用できる優れた画像の例は、 stackbrew/registryです。 このイメージでは、 docker pull stackbrew/registryとdocker run -p stackbrew/registry実行が完了するとすぐに、プライベートDockerレジストリを試してみることができます。

Dockerの目標は、ソフトウェアが実行される環境のデプロイと準備を支援することです。 つまり、ビルドは線形であり、最初のビルド中にのみ実行されますが、毎回まったく同じソフトウェアを実行します。

構成管理システムを使用すると、さらに何かを実行したり、他のトリックを使用したりできる場合がありますが、それらは「不変」ではなく、構成管理ソフトウェアによって検出されない微妙な違いがある2つのホストを持つことになります。

古いスレッドをネクロするのは嫌いですが、IMHOが元のポスターの問題を解決し、この問題の同様の解決策を探している他の人を助けることができる何かを提供したいと考えていました。

簡単にするために、それらはすべて同じベースイメージR使用すると仮定します。 私がサービスAとサービスBを持っていると想像してください。 それらを別々のDockerイメージに入れ、両方を同じDockerイメージに配置したいと思います。

サービスAをインストールするスクリプトを作成し、サービスBをインストールする別のスクリプトを作成します。 次に、 AスクリプトとスクリプトB別のgitリポジトリを用意します。 ビルドされる3つのDockerイメージすべてのgitリポジトリを作成します。 それぞれに、使用されるインストールスクリプトを含むgitサブモジュールが含まれています。 各Dockerfileは、インストールスクリプトをADD 、次にインストールスクリプトをRUN 、一方または両方のスクリプトに対してこれを実行します。 画像からスクリプトを削除したい場合は、実行後にスクリプトを追加してください。

このようにして、各インストールスクリプトとそれらを使用するDockerイメージのコピーが1つあります。 これにより、コードの不要なコピーが回避され、メンテナンスの負担が最小限に抑えられます。 作業の唯一の重複は、サブモジュールによって使用されるコミットを上に移動することです。これは、代替モジュールよりも大幅に優れており、おそらく自動化できます。

私はこれがどのように機能するかを誤解していると思うので、説明を得るために返信しています。 公式のseleniumdockerイメージでUbuntu11を使用したいと思います。 彼らはUbuntu15を使用しています。

https://github.com/SeleniumHQ/docker-selenium/blob/master/Base/Dockerfile

これを行うための正しい方法は何ですか？ そのリポジトリのクローンを作成し、すべてのファイルを編集して、15ではなくUbuntu 11と言うには？ これは正しくありえませんね？ これは、公式画像のあらゆる側面に不一致がある人は誰でも、それらのコードを複製せずにそれらを利用できないことを意味します。 私はそれが間違っていると思います、誰かが説明できますか？ Ubuntu 11で公式のセレンイメージを使用する正しい方法は何ですか？

@rjurneyはい、それがどのように機能するかです。 あなたの例では、Dockerfile全体がubuntu：15.04を念頭に置いて開発されています。 それらのパッケージはubuntu：11で利用できます

Dockerはベースイメージとイメージの間の_differences_のみを保存するため、既存のイメージのベースイメージを「交換」することもできません。 したがって、別のベースイメージを使用すると、予測できない結果が発生します（たとえば、「ファイルXを削除」。「ファイルX」は元のベースイメージには存在しますが、選択したベースイメージには存在しません）。 また、ベースイメージの「上」に構築されたイメージのパッケージ/バイナリは、そのバージョン用に構築されたパッケージであり、これらのバイナリは別のベースイメージと互換性がない場合があります。

これは、公式画像のあらゆる側面に不一致がある人は、コードを複製せずにそれらを利用できないことを意味します

はい。 公式画像は、それらの画像のメンテナ（この場合はSeleniumのメンテナ）によってサポートされています。 これらの画像に変更が必要だと思われる場合は、リポジトリで機能リクエストを開くのが最善の方法です。 その機能要求が受け入れられない場合は、おそらく独自のバージョンを作成する必要があります。

（公式のubuntu:11画像がないことにも注意してください）

ソフトウェアの世界の残りの部分では、単一の継承は次のように見られていません
必要なセマンティクスを合理的に表現するのに十分です。 それは多くのコードにつながります
重複。これはバグと見なされます。 なぜこれは
Dockerに受け入れられますか？ 一度に1つのサービスを構築している場合でも、
構成は、オペレーティングシステムレベルで必要です。 私は勝つつもりはありません
死んだ馬ですが、この制限は少し極端に思えます。 それは良いかもしれません
ベストプラクティスとして表現されていますか？ これの厳格さの結果として
決定、誰かが構成または複数を行うツールを構築します
継承し、単一の継承と複製を通じてそれらを表現します。
これをDockerの外部に適切に配置しても、Dockerコミュニティには役立ちません。

2015年12月9日水曜日、Sebastiaan van Stijn <
[email protected]>は次のように書いています：

@rjurney https://github.com/rjurneyはい、それがどのように機能するかです。 の
あなたの例では、Dockerfile全体がubuntu：15.04を念頭に置いて開発されています。
それらのパッケージはubuntu：11で利用できます
それらの上に？ Dockerfileで変更を加える必要がある可能性があります
Ubuntuの別のバージョンで動作させるため。

既存の画像のベース画像を「交換」することも機能しません。
Dockerは、ベースイメージと
画像。 したがって、別のベースイメージを使用すると、予測不能になります
結果（たとえば、「ファイルX」が元のベースに存在する場合、「ファイルXを削除」
画像ですが、選択したベース画像にはありません）。 また、パッケージ/バイナリ
ベースイメージの「上」に構築されるイメージでは、構築されるパッケージです
_that_バージョンの場合、これらのバイナリは別のバイナリと互換性がない可能性があります
ベースイメージ。

これは、
公式画像は、それらのコードを複製せずにそれらを利用することはできません

はい。 公式画像はそれらの画像のメンテナによってサポートされています
（この場合、Seleniumのメンテナーです）。 あなたが変化を考えるなら
それらの画像に必要な場合、最良の方法はで機能リクエストを開くことです
彼らのリポジトリ。 その機能のリクエストが受け入れられない場合は、
おそらく独自のバージョンを作成します。

（公式のubuntu：11画像がないことにも注意してください）

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

ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

@rjurneyの多重継承も非常に複雑であり、結果、コーナーケース、および非互換性を

12749は、そのような機能を追加するための最新の試みでした。最初に実行する必要のある他の作業があるため、最終的には拒否されました。

これをかなり開くことができるクライアント駆動型ビルドを有効にすることを含め、ビルダーで行われている多くの作業があります。

単一継承のDockerfilesは、（大部分の）ユースケースで機能するため、これを急いで強化する必要はありません。 それは正しくそして慎重に行われる必要があります。
上記のコメントに基づいて、実際には多重継承は必要ないと思います。既存のコードを複製せずに、Dockerfileが実行されるベースイメージを指定する方法です。

そうです、それは私のニーズを満たすでしょう。 の一部のプロパティを変更できる
dockerfilesのチェーン。

わかりました、あなたがこれの上にいると聞いてうれしいです。 お待ち頂きまして、ありがとうございます ：）

9:59に水曜日、2015年12月9日には、ブライアン・ゴフの[email protected]は書きました：

@rjurneyhttps ：//github.com/rjurney多重継承も
非常に複雑で、考えずに追加したものだけではありません
結果、コーナーケース、および非互換性について。

12749https ：//github.com/docker/docker/pull/12749が最新でした

そのような機能を追加しようとします-あるため、最終的に拒否されました
最初に行うべき他の作業。
ビルダーで行われている作業はたくさんあります。
これをかなり開くことができるクライアント駆動型ビルド。

単一継承Dockerfilesは、（大部分の）ユースケースで機能します。
そのため、これを強化するための急いでいることはありません。 それは正しく行われる必要があり、
故意に。
そして、上記のあなたのコメントに基づいて、私はあなたが実際に複数を必要としないと思います
継承、Dockerfileが実行されるベースイメージを指定する方法
既存のコードを複製せずに。

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

ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

@rjurneyどこで情報を入手しますか。 私の知る限り、Javaには多重継承がありませんし、そうなることもありません。 同じことが多くの言語にも当てはまると確信しています。 多くの人は、多重継承は予測可能なコードをほとんど不可能にする可能性があるため、非常に有害であると考えています。 Dockerコンテナについても同じことが言えます。

私が見ているように、dockerに必要なのは、多重継承の概念ではなく、インクルードまたは外部依存関係の概念です。 例：実行時にコンテナをマウントできます。 本当に必要なのは、画像と同等のものにする方法です。 したがって、たとえば、Fedora 22に基づくように定義されたイメージを作成し、データベース機能を追加するためにOracleイメージをマウントすることができます。

これは、コンテナーを実行するときに非常にうまく実行できますが、イメージで指定するための構文はありません。 したがって、実行時まで、dockerがこれらの依存関係を認識したり、とにかくそれらを管理したりする方法はありません。

多重継承と構成について言及したことに注意してください。
確かに、これを行うには作曲が好ましい方法です。

私はあなたが言った他のすべてに同意するので、+ 1。

2015年12月9日（水曜日） 、ビル・C Riemersで[email protected]
書きました：

@rjurneyhttps ：//github.com/rjurneyどこで情報を入手しますか。
私の知る限り、Javaには多重継承がありませんし、そうなることもありません。
同じことが多くの言語にも当てはまると確信しています。 多くの人が複数を検討します
継承は非常に有害であり、ほとんど不可能になる可能性があります
予測可能なコード。 Dockerコンテナについても同じことが言えます。

私が見ているように、Dockerに必要なのは複数の概念ではありません
継承ですが、インクルードまたは外部依存関係の概念です。 例えば
実行時にコンテナをマウントできます。 本当に必要なのは
画像と同等です。 たとえば、次のような画像を作成できます。
Fedora 22に基づくように定義され、追加するOracleイメージをマウントします
データベース機能。

これは、コンテナーを実行するときに非常にうまく実行できますが、
画像で指定するための構文はありません。 したがって、実行時まではありません
Dockerがこれらの依存関係について知る方法、またはとにかくそれらを管理する方法
君。

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

ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

この後は黙ってしまいますが、誤ってこのチケットの代わりに前述のプルリクエストにこの暴言を入れてしまいました。 だから私はそれをここに置いています。

誰かがこれを構築しようとしています。 INCLUDEを追加するプルを受け入れない場合、この機能が遅延して外部化されます。 これがここでの決定の基礎となるはずです。これはDockerの内側にあるのか、それともdockerの外側にあるのでしょうか。

例が思い浮かびます。 Apache Pigでは、多くの要求があったにもかかわらず、チームはループを含めないことを決定しました。これは、PigがDAGデータフローに最適であると判断されたためです。 代わりに、pigスクリプトをスクリプト化するための統合が作成されたため、任意のJVM言語のスクリプトをループできます。 これは意識的な決定であり、代替案が追求されたことに注意してください。 これが私の意見のモデルプロセスです。

別のPigの例が思い浮かびます... PigMacros。 彼らは存在せず、誰か（わかりました、私）が彼らの大きな豚プロジェクトがどれほど醜いのか、そして外部ツールから豚を生成せずにこの問題を解決する方法がないというスレッドを始めるまで、「豚ではありませんでした」望ましくない。 多くの人がチャイムを鳴らし、Pigチームがマクロを追加しました。 マクロはきれいな豚を可能にし、コミュニティは恩恵を受けました。

決定に正面から取り組み、それについて話し合うことをお勧めしますが、これはまだここでは行われていません。ファインダビリティのために、おそらくここに属します。 これは存在します。 ドメイン固有言語でスクリプトを複製するのはひどいです。 人々はそれを要求するでしょう。 この機能はDockerの内部にありますか、それともDockerの外部にありますか？ Dockerの外部でこの動作をどのように促進しますか？

申し訳ありませんが、メーリングリストに多くのコンテキストが欠落している可能性がありますが、新しいDockerユーザーとして...既存のレシピからdockerfileを作成する機能がなくても、Dockerで多くのことを行うのは非常に躊躇しています。 私はPigと一緒にこの道を進みました、そしてそれはほとんど私を殺しました。 多くの人がこのように感じると思います。

誰かが気にする場合に備えて...

Pigのループとマクロに関する半ば採用されたプレゼンテーション： http ：
Pig Macro JIRA： https ：
Pig JIRAへのAPIインターフェース： https ：
Apache Hiveを尊重することを完全に拒否されたもの... PigにSQLを追加します： https ：

最後に、この変更を簡単にするかもしれないという考えがありました... INCLUDEされたファイルが継承できない場合はどうなりますか？ つまり、物事を非常にシンプルに保つことで、反対意見を避けることができます。 より多くが学ばれるので、後で残りを扱います。 たとえば、前提条件とバイナリをインストールし、UbuntuでMySQLのデーモンをセットアップする単純なDockerfileが存在する可能性があります。 必要に応じて、これはUbuntuとMySQLのバージョンによってバージョン管理できます。 個人的には、ユーティリティをハックしてこれらの単純なINCLUDEを実行し、それを使用してdockerfilesをこのように整理します。 コードを注文して再利用するのが待ちきれません。

INCLUDEアイデアの場合は+1。 継承を禁止することで問題が変わるだけだと思いますが、継承元のメインストリームイメージを変更できるようになりますが、他のイメージを変更することはできなくなります。 基本的に、既存のベースイメージを壊す可能性のあるオペレーティングシステムのものを提供しないという点で、イメージを「包含可能」に指定できれば、意味があります。 このフラグは、Dockerビルドプロセスで設定する必要があり、適切にフラグが設定されていないイメージが含まれるのを防ぎます。 そして、私はそれに直面しましょう。 Dockerfilesで遊んでいる場合は、おそらく最初の日に自分のマシンを見ている人ではないので、dockerのエンドユーザーが愚かなことをするのを防ぐのは理にかなっていると思いますが、もう少しあるはずです。それらの画像を実際に作成する人のための自由。 そして、真剣に言うと、ベースイメージを選択し、アプリをプロビジョニングするために必要なものをすべて含めることができるのは、非常に素晴らしいことです。

INCLUDEの場合は+1。 nginxとsshの画像を1つに組み合わせるだけです。 なぜこれはそれほど難しい必要があるのですか？

これが必要ないという考えは、率直に言って混乱を招きます。
不誠実。 作成されている場合、ほとんどのユーザーはこれを使用します。 "sshを追加する
「ubuntu」と「nginxをubuntuに追加する」は、誰もが行う非常に一般的なタスクです。
繰り返す必要はありません。 Docker HQがこれについて実際に言っているように見えるのは、
「明らかに必要ですが、醜くなりすぎると思います。だから私たちはふりをします。」 これ
あなたが実際にこれについて正直でオープンであることができればもっと良いでしょう。
気難しいならごめんなさい。

18:22時土、2016年1月23日には、Vazyの[email protected]は書きました：

INCLUDEの場合は+1。 nginxとsshの画像を1つに組み合わせるだけです。 なぜ
これはとても難しい必要がありますか？

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

ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

@rjurneyビルドのスピンアウトを待ちましょう; この方法では、イメージをビルドする方法が複数あるためです（したがって、それを行うカスタムビルダーが表示される可能性があります）。 Dockerメンテナ（Dockerで動作しているかどうか）が気難しい理由の1つは、柔軟性と単純さを追加したい場所に複雑さが追加されるためです。 ビルダーを抽出することで、関心の分離（イメージの構築と実行の間）が向上し、カスタムビルダーで多くのユースケースがより自由に実装されます。

ここでも、これをプロジェクトから押し出しますか？ カスタムサウンド...ではありません
デフォルトのインクルード方法。 実際には、インクルードは単純な必要性です
ほとんどの人が持っています。 繰り返すのは複雑です。 継承のみ
複雑。 誰もが最も簡単な方法で必要とするマッチを含む
可能。

2016年1月24日（日曜日）には、ヴィンセントDemeester [email protected]
書きました：

@rjurneyhttps ：//github.com/rjurneyビルドのスピンアウトを待ちましょう;
この方法では、イメージを構築する方法が複数あるためです（したがって、
それを行うカスタムビルダーが表示される可能性があります）。 Dockerの理由の1つ
メンテナ（Dockerで働いているか働いていないか）はそれについて気難しいです、
柔軟性を追加したい場所に複雑さが加わり、
シンプルさ。 ビルダーを抽出することで、
懸念事項（イメージの構築と実行の間）と多くのユースケース
カスタムビルダーでより自由に実装されます。

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

ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

+1、画像を組み合わせると非常に便利です。 （神は禁じられている）C ++のユースケースを想像してみてください。 ブーストを使用してイマジネーションを作成し、Qtを使用して、すべて同じコンパイラを使用してイマジネーションを作成します。ここで、ブーストとQtの両方を使用してアプリを作成するとします。この場合、2つとprestoを組み合わせる必要があります。開発環境の準備ができています。 これは非常に便利です。

個人的には、これは取り組まない問題としてはあまりにも重要だと感じています。 そうは言っても、どこに実装されているかに関係なく、問題と範囲が何であるかをよく理解する必要があります。

ですから、これらの問題はマージによって提示されます。

1. マージの競合の処理。
2. さまざまなベース（UbuntuとCentOS）を解決します。

最初のものでは、簡単な答えはそうではないと思います。 私には、それは複雑で潜在的に問題があるように聞こえ、解決するには一連のツールが必要であり、それでも魔法が多すぎる可能性があります。 したがって、これが追加された場合、マージの競合は失敗するはずです。 後で再検討されるかもしれないと思いますが、それは価値があるよりも厄介なようです。

2番目のケースについては、いくつかのベースレイヤーを共有するという制約を追加できるようです。 ここで問題は、いくつで十分かということです。 開始時の正解は、マージされる2つの画像が同じFROM画像である必要があるということだと思います。 ここにはさらに制約が必要かもしれませんが、それらのケースが問題1に該当しないかどうかは私にはわかりません。問題1は、単にそれを禁止することで解決しました。

私がここで見逃している他の問題はありますか？

マージする試みはないはずだと思います...私はそれが起こっているのを見ることができません

より現実的なアプローチは、テンプレートタイプのソリューションである可能性があります。つまり、Dockerfile _fragment _（ FROM句はなく、コマンドのリストのみ）を実際のDockerfileにINCLUDE許可します...フラグメントは、互換性のあるベースイメージDockerfileに対して共有、再利用、および含めることができます

http://docktitude.io

私はDockerにまったく慣れておらず、謙虚に学んでいます。 しかし、Dockerの主なポイントは、非常に小さな_再利用可能な_アプリケーションを構築して、後でWebアプリのように大きな最終的なアプリケーションに組み合わせることができると思いました。 その場合、IMHOはINCLUDEようなステートメントが必須です。

@jmcejuelaは、多くの場合、「再利用」とは、特定のサービス専用のイメージを作成し、それらのイメージ/コンテナーを組み合わせてアプリケーションを形成することです。 アプリケーションの個々のコンポーネントは再利用可能ですが（おそらく、コンテナーの構成のみが異なります）、それらを組み合わせる方法によって実際のアプリケーションが形成されます。

@thaJeztahわかりました、ありがとうございます。

しかし、以前に投稿された人々のように具体的にすると、scalaアプリケーション（画像A ）を実行するWebアプリを構築し、nginx（画像B ）を使用してWebサーバーを作成し、sshを実行するとします。 （画像C ）、追加のpythonアプリケーション（画像D ）が必要です。 それぞれに4つのDockerfileを作成したとします。 それらをDockerと組み合わせて、最終的なWebアプリを作成するにはどうすればよいですか（画像E ？）

これを行う簡単な方法が必要です。 多重継承に関する哲学の論争、含めるかどうか、作曲するかどうかなどは気にしません。確かに、以前に提案されたようにコピー＆ペーストしたくありません。

どうもありがとうございました。 私はまだDockerを学んでいます。

@jmcejuela _images_を組み合わせるのではなく、それらを別々のコンテナーとして実行し、それらを連携させてアプリケーションを形成します。 これは、「スタック」を定義できるDockerComposeを使用して行うことができます。 たとえば、 https：//github.com/docker/example-voting-app/blob/master/docker-compose.yml （およびREADME; https://github.com/docker/example-voting-app/）を参照して

「ssh」の部分については、実際にはそれを何に使用したいかによって異なります。 全体として、コンテナーは「不変」と見なされるため、コンテナーにSSHで接続して変更するのではなく、新しいコンテナーを起動して古いコンテナーを置き換えます。 コンテナのライフサイクルを超えて存続する必要のあるデータは、新しいコンテナがそれらのファイルを使用できるように、ボリュームに保存されます。

@jmcejuela Docker BuilderはSTDINでDockerfileのコンテンツを受け入れるので、「比較的」簡単に生成できますか？ コンテキストを渡す必要がある場合は、すべてを風袋引きしてdocker buildフィードする必要があります。 私の経験では、これがコンポジションを取得するための最も簡単な方法です。

私は、上記の概念に基づいたアプローチを開発しています（そして遊んでいます）。 nodejsアプリケーションは、メモリ内のTARファイル（ Dockerfileと追加されたファイルを含む）を準備し、それをSTDOUTにダンプします。 STDOUTはdocker buildパイプされます。 構成可能なパーツは、バージョン管理され、テストされ、NPMモジュールとしてリリースされます。 crondテストイメージを示す非常に短い例を示します-http：//pastebin.com/UqJYvxUR

ありがとう@thaJeztah結局、私は共同開発者が開発スタック全体を持つために実行できる単一のファイルが必要であり、必要に応じてそれをprodでも実行できます。 dockercomposeについて詳しく見ていきます。

また、 INCLUDEはずっと前に提案されました（https://github.com/docker/docker/issues/735）。

@jmcejuela実際、ほとんどの

あなたがそれを間違っている場合にのみ、 docker execコマンドはかなり前から存在していて、それ以来私はsshを必要としませんでした...

@anentropicこれは、依存関係のない単純なサービスをデプロイする場合にのみ当てはまります。 たとえば、機械学習に関連するサービスなど、依存関係の複雑なチェーンがある場合は、サービスをデプロイするためのコードを複製することになります。 そして、あなたがそれをしなければならない正当な理由はありません。 dockerがドメイン固有言語であるからといって、プログラミング言語に関する知識の大部分が公開されているわけではなく、古いレッスンはどれも当てはまりません。 正気はまだ重要である必要があります。 レシピのコピーと貼り付けは狂気です。

また、すべてのDockerユーザーではない「単一サービス」の世界観にサブスクライブしている場合にのみ適用されます。

@anentropic Dockerロードマップによると、 docker execを介して実行中のコンテナーをプロビジョニングすることも同様に間違っている可能性があります。

PSrktエンジンはv1.0に

@rjurney 、：100：

愛されているか嫌われているかにかかわらず、多重継承は複雑な機能であり、間違いなく抵抗があります。 Includeは、Dockerfilesをビルドレシピから、解決が難しいパスの問題がある言語に変換します。

問題を別の方法で見るとどうなりますか。 「 ADD / COPY 」で、別のDockerイメージからビルド中のイメージにファイルを選択できた場合はどうなりますか。 このようにして、機能を再利用し、コードの重複を回避することができます。 画像でFROM複数回使用するのではなく、明示的にバイナリをコピーするだけなので、これは明確に定義された方法で動作するはずです。そうでない場合は失敗です。 これはDockerイメージで機能し、新しい検索パスではなく、ソリューションとしてレジストリを活用できることを考えると、これが合理的な提案であることを願っています。 追加のボーナスは、同じコードを複数回再実行する必要がないことです。 また、うまくいけば、ビルダーへの大規模な変更を回避することができます。 考え？

多分これは他の場所で提案されています、その場合はリンクがいいでしょう。

こんにちは、
どのソリューションを選択しても、複数の独立したソースから画像を準備することは、私が非常に驚いたことであり、不可能です。
実行時にこのプロセスを実行できるため、イメージの準備をスキップしたかったので、実行時に一連のイメージがデプロイされ、依存関係が変更されるたびにイメージを再作成する必要はありません。
私は代替案を探しましたが、まだ有効なものは見つかりませんでした。これは大きな使用上のギャップです。
ACIを使用して実行するのは非常に簡単に見えます。
ありがとう！

：+1：これに対する解決策が大好きで、少なくとも話題になっていることをうれしく思います。 ベースイメージが同じである必要がある場合でも。

他の画像からのコピーが他の場所で提案されていることが判明しました。 これが問題です（https://github.com/docker/docker/issues/18596）。

ありがとう@jakirkham ..

Dockerの多重継承機能の+1

編集：

https://github.com/docker/docker/issues/13026も参照して

あなたが直面している問題は、レシピを作成できないことが意味をなさないということだと思います。 Docker composeは、アプリケーションで複数のコンテナーを使用するのに最適です。 Docker swarmは、複数のノードで同じことを行うのに最適です。 しかし、多くの場合、ソースコードレベルで他の人の作業を含める方法はありません。 一度継承するか、再作成する必要がありますが、これには制限があります。

2016年3月18日金曜日9:01 AM、Alvin Chevolleaux < [email protected]

書きました：

@thaJeztahhttps ：//github.com/thaJeztahによる返信は非常に
啓発。 私はDockerを初めて使用しますが、なぜ結合できないのかわかりません
複数の_images_を一緒に使用しますが、DockerComposeが解決策のようです
複数の_containers_を私が探していた1つのアプリケーションに結合する
にとって。

私にとっての問題は、最初はDockerを理解したと思ったことだと思います
しかし今、私はそうではないことがわかりました。 戻ってもう少しやります
読む！

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/3378#issuecomment -198426036

ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

@rjurneyはい、Dockerを調べた後、もう少し正解です。これはまさに私の混乱です。 たとえば、PHPイメージとCentosイメージがありますが、異なるイメージ間の継承がないため、すべてまたはまったくありません。 公式のPHPイメージではdebian:jessie使用していますが、セットアップをCentosベースにしたいので、特定のイメージを使用する場合は、残りのセットアップを受け入れるか、ソースDockerfileをコピーして貼り付ける必要があるようです。自分の画像を最初からロールバックしますが、画像を組み合わせて組み合わせることができる中間点はないようです。

編集：
明確にするために、UbuntuベースのイメージとCentosベースのイメージを一緒に混合できない理由は理解していますが、ある種の階層構造を持てない理由はわかりません。 次に、画像全体をダウンロードする代わりに、ある画像から別の画像への変更をダウンロードするだけです。

INCLUDEは私にとってもめちゃくちゃ便利です。 それがなければ、私はコピー＆ペーストすることになります。

@RomanSaveljevわかりません：

Dockerロードマップによると、 docker execを介して実行中のコンテナーをプロビジョニングすることは、同様に間違っている可能性があります。

docker execが非推奨になるとは言っていません。 docker execは常にデバッグツールであるため、DockerコンテナでSSHを使用する必要があります。

これに参加するのはばかげていると思いますが、なんてことでしょう...もう一度これを提案します：

問題を単純化して、継承を許可しないようにINCLUDEを実装することから始めてみませんか？ つまり、FROMがないファイルのみを含めることができます。

これは多くのユースケースを処理し、合理的なオペレーティングシステムで動作するように人々が含めるファイルに弾みがつきます。 unameには理由があります。 これは最初のステップであり、この実装に関するフィードバックは、さらに何かを定義するのに役立ちます。

それは簡単な決断のようです。 それはたくさんの仕事ではないでしょう。 複雑ではありません。 右？

@rjurneyそれは基本的にhttps://github.com/docker/docker/pull/12749が行うことです

@rjurney ：愚かではありません。 INCLUDEは最初の質問を完全にはカバーしていませんが、正しい方向への一歩です。 カプセル化されたいくつかの問題があります。

1. いくつかの独立した作品を組み合わせる方法は？
2. そのようなコンパイルを効率的に保存する方法は？
3. ビルドレベルではなく、バイナリレベルでいくつかの作業を組み合わせるにはどうすればよいですか？

このリストに追加できるアイテムはおそらくもっとあるでしょう。 INCLUDEソリューションは、最初の箇条書きを処理します。 それが整ったら、バイナリストレージの効率をエンドユーザーに対して透過的に改善できる標準的なフレームワークが構築されます。 それが整ったら、画像ファイルに対して同じ操作を直接行うツールについて話すのは理にかなっています。 ただし、この最後のステップはもちろん非常に疑わしいものです。 画像ファイルで直接実行するとすぐに、画像が壊れてしまう可能性が非常に高くなります。 ただし、パワーユーザー（自分が何をしているのかを正確に知っているユーザー）だけが3番目のオプションを実行すると想定される場合、それは私には不合理な追加のようには思えません...最終的には。

このように本当に構成可能なものが必要な場合は、Nix（NixOS、Linuxディストリビューションおよびパッケージ管理システム）をご覧ください。 すべてのソフトウェアを再パッケージ化し、通常はソースからビルドし、Linuxについて知っていると思っていたものをすべて放棄するだけです;）。 いいシステムですが、使う人が少ないので手間がかかりますが、うまくいくことを心から願っています。

他の人が言っているように、Dockerの構成可能性は、サービスレベルでの構成に関するものです。

：+1：構成可能なモデルについて考える価値のあるdefo-動作をdockerfileにインポートできれば素晴らしいでしょう。 たとえば、Alpine linuxに基づく非常に異なるビルドコンテナの数にapachethriftを含めたいというユースケースがあります。Javaサービスをビルドするものもあれば、PHPやその他のノードをビルドするものもあります。

コピーして貼り付けるのではなく、節約インストールを含めることができればよいでしょう。シェルスクリプトに簡単に抽出して、追加して実行できると思います。

では、ruby-2.3とjava-8の両方のイメージを使用するにはどうすればよいですか？ 彼らはベースと同じdebianjessieイメージを使用しています（私はdockerfilesを読みました）。 両方にあるコマンドを実行したいだけです。 現状では、JavaDockerfileをRubyDockerfileにコピーして貼り付ける必要がありました。 アプリには両方が必要です。私がそれを回避する方法は絶対にありません。

貼り付け中にいくつかのDockerfileコマンドを削除する機会を利用しました。これらのコマンドは有害ではありませんが、「ベース」のDockerfile（コマンドを貼り付けていた）がすでにこれらの手順を実行しているため、単に不要です。 したがって、「ruby」と「java」のイメージは本当に必要ではなく、実際には3番目の「ruby + javaall-in-one」イメージを作成していたという議論を見ることができます。

ただし、この特定のケースでは、これら2つの画像のコマンドは完全に互換性があるように見えます。単純に連結した場合は、機能するはずです。 そのような状況を特定できると便利です。 私はコピー/貼り付けアプローチの大ファンではありません。私の場合、JavaとRubyのDockerfileは十分に単純でしたが、一部のDockerfileははるかに複雑です。

ただし、この機能を必要としている私のような他のすべての人にとって、これが問題になる状況はたくさんあります。 したがって、同じDockerイメージで「nginx」を実行してから「ssh」を実行する機能を提供するだけの問題ではありません。同じ機能を使用すると、「debian」と「centos」を実行することもできます。実行可能な画像。 これが導入された場合、それは実験的なオプションである必要があるように思われます。デフォルトではオフになっており、大量の警告が添付されています。

したがって、この機能のインターフェイスが何であれ、再利用可能な動作（コマンドのセット）を正しく取得する責任はDockerfile開発者にあることを明確にする必要があります。

編集：ああ、私はINCLUDEの議論を逃しました。

問題を単純化して、継承を許可しないようにINCLUDEを実装することから始めてみませんか？ つまり、FROMがないファイルのみを含めることができます。

これは多くのユースケースを処理し、合理的なオペレーティングシステムで動作するように人々が含めるファイルに弾みがつきます。 unameには理由があります。 これは最初のステップであり、この実装に関するフィードバックは、さらに何かを定義するのに役立ちます。

それは簡単な決断のようです。 それはたくさんの仕事ではないでしょう。 複雑ではありません。 右？

：+1：

@rjurneyそれは基本的に＃12749が行うことです

：+1：完璧です。最終的な形で何ができるかを楽しみにしています。

このコンセプトにも非常に興味があります。 「INCLUDE」メカニズムは非常に大雑把なソリューションですが、正直なところ、一連のDockerファイルの保守性においてかなり大きな前進を示します。

個人的には、 FROMに遭遇したときに_失敗_したくないので、 FROMを_無視_して、残りのコマンドを順番に適用したいと思います。

FROMのサポートなしではこれがまだ起こっていないことはオープンソースです
トラベスティ。

10:19の木、2017年1月19日には、ケン・ウィリアムズ[email protected]
書きました：

このコンセプトにも非常に興味があります。 「INCLUDE」メカニズムは非常に
大雑把な解決策ですが、正直なところ、
Dockerファイルのセットの保守性。

個人的には、FROMに遭遇したときに失敗したくありません。
FROMを無視して、残りのコマンドを適用するだけです。
順序。

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

-
ラッセル・ジャーニーtwitter.com/rjurneyラッセル。 [email protected] relato.io

これが問題です。必ずしもマージする必要はありません。 多くの問題はリベースで解決できると思います。 私の通常のユースケースは

A（ubuntu）-> B（例：nginx）
A（ubuntu）-> C（例：ノード）

そして、BとCを組み合わせた画像が必要です。 通常、それらは互いに何の関係もないので、AとCの間のすべての差をBにリベースするだけで十分です。

A-> B-> C '

それは解決するのがより簡単な問題のようです。

@cloutiertyler通常、Node.jsアプリケーションはNginxで動作するためにこの機能を必要としません（私の意見では）。 Dockerの方法は、2つのコンテナーになります。1つはNginx用で、もう1つはNode用です。 Nginxコンテナーにのみポートを公開するようにNodeコンテナーを構成し、Nginxコンテナーにパブリックポート（80など）をリッスンさせます。 Nginxがノードと同じコンテナにある必要がある理由は何ですか？

サンプルのDockerComposeファイルは次のようになります。

version: "2.1"

services:
  app: # Node.js application image
    build: .
  nginx: # Nginx container who can make request to app container
    image: nginx:1.10-alpine
    depends_on:
      - app
    ports:
      - "${PORT:-8080}:80" # public port, you may want PORT=80

@franklinyu返信

ところで、それは正確にリベースではありませんが、Dockerfilesの多くのユースケースを開きます。
Dockerfileはマルチステージビルドをサポートするようになりました。 例：

FROM golang AS myapp
COPY . /myapp
RUN cd /myapp && go build

FROM scratch
COPY --from=myapp /myapp /usr/bin/myapp

ステージはいくつでも構いません。
--fromパラメーターは、基本的にコンテキストを指定されたビルドターゲット名に切り替えます。
docker build -t myapp .場合、 myapp:latestという結果の画像は最終段階のものになります。
たとえば、 docker build --target=myappを使用して特定のステージを構築することもできます。

17.05（現在RC1として利用可能）には他にもいくつかの非常に優れたDockerfileの機能強化があります。試してみてください！

今それは面白いです！ 私はあなたがそれをすることができるとは知りませんでした。 それが私の一般的なユースケースを解決するかどうかを確認するために、それを試してみる必要があります。

これは素晴らしい機能ですが、試してみても、私の最も一般的な問題は実際には解決されません。 今日もまた出くわしました。

コンテナ内からビルドできるように、DockerがインストールされたJenkinsイメージが欲しいです。 問題の事実は、Dockerfileでどちらかのインストールプロセスを複製せずにこれを行う方法はないということです。

これは、各コンテナは1つのサービスのみである必要があるため、これについてのまばゆいばかりの議論は明らかに適用されない場合です。 私の「1つのサービス」は、DockerとJenkinsの機能を組み合わせたものです。

問題の事実は、Dockerfileでどちらかのインストールプロセスを複製せずにこれを行う方法はないということです。

それで、2つのdockerfileを1つにスマッシュして、コピー/貼り付けする必要がないようにしたいですか？

この場合、コピー/貼り付けはフォークに相当します。 私がやりたいのは、Dockerfileをフォークしないようにすることです。そうすれば、バグ/セキュリティの改善や、後で必ず変更されるその他の変更を見逃すことはありません。

ただ通り過ぎることはできません。 画像の継承の長いチェーン（2より深い）に変更を分散する方法を探しています。 多段階は問題を解決するものではないようです。 ディレクティブのブロックだけを含むことができるエンティティを持っていると、それをすべての継承イメージに含めることができ、ベースイメージの機能とともに合理的な進化のように見えます。

Dockerの観点から、これを行う正しい方法を疑問に思っている人は、数分かけて確認してください。
https://github.com/floydhub/dockerfiles

ここで、彼はDockerfilesのツリー全体を作成します。 ツリーを下に行くと、依存関係のさまざまな組み合わせが見つかります。それぞれがツリーの上のレベルからのものです。 だからあなたがから木をたどった場合
-ubuntu->common-deps->python3->deepLearningBase->pyTorch
そしてあなたは本当に欲しかった

-ubuntu->common-deps->python3->deepLearningBase->pyTorch 
+
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow 

両方のdeepLearningBaseの下にノード（フォルダー）を追加するだけです。
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow-pyTorch

ここでも、pyTorchとTensorFlowのdockerfileを組み合わせたdockerfileを作成する必要がありますが、
重要なのは、これらのファイルが非常にシンプルで、deepLearningBaseの上に数行インストールするだけであるということです。

したがって、本当に必要なのは、Web開発、ディープラーニング、組み込みソフトウェアなどのさまざまな「世界」のための、このようないくつかの大規模なgithubリポジトリです。

次に、ツリーに従って必要なビルドを実行します。まだ誰も作成していない場合は、ノードを追加し、2つまたは3つのapt-get行を組み合わせて、新しい環境を作成します。

それは「きみならどうする？」スタイルの作曲のように見えます。 INCLUDEの方がはるかに簡単です。 地獄、私は指定されたgccイメージをnanoので、毎回apt-getからnanoをインストールする必要はありません！

私は彼の上記のコメントで@chambmに同意します。 ほとんどの場合、これが不可能である理由はありません（手動で管理されるOS上にあるため、競合はかなりまれです）。

これは、1つの@cloutiertylerと非常によく似ユースケースであるコメントでもない@franklinyuさん、ソリューション、どちらもマルチステージがビルドコメント@ cpuguy83によって適用されます。

• A（debian：stretch-slim）
  
  
  
  • dockerfileAB- > B（python：slim-stretch）
  
  
  • dockerfileAC- > D（[build-stage] python-slim）
    
    
    
    
    
    • dockerfileDE- > E（ghdl / ext：vunit）
    
    
    
  
  
  • dockerfileAC- > C（ghdl / run：stretch-mcode）
  
  

どこ：

• AからCへのステップは、BからDへのステップ（dockerfileAC）とまったく同じです。
• Bの開発チームは、C、D、またはEについて何も知りません。
• Cの開発チームは、B、D、またはEについて何も知りません。

D（および/またはE）をビルドする意思のあるユーザーは、dockerfileACにアクセスできる必要がありますが、dockerfileABについて知っている必要はありません。 したがって、ユーザーは一方の依存関係（C）をもう一方の依存関係（B）よりもよく理解している必要があります。 理想的には、チームAとBに依存し、DをA + (diff(B,A) + diff(C,A)) （マージ）またはA + diff(B,A) + diff(C,A) （リベース）としてビルドすることが可能である必要があります。

GHDLはWebサービスではなく、VUnitはWebクライアントではないため、両方のツールを同じイメージ/コンテナー（E）にインストールする必要があります。 2つのFROMラベルを使用して（おそらく不明な）dockerfileをビルドする必要があるため、マルチステージビルドは役に立ちません。これは、単一のフォワードチェーンではありません。

2つのgitブランチのマージ/リベースに似たこのユースケースを見つけた場合：競合がない場合、競合が簡単に解決できる場合、共通の履歴がないためにまったくマージできない場合...ツールはありますか？この機能を提供する公式または外部のいずれか？ ツールが2つの画像をgitブランチにエクスポートし、実際にマージにgitを使用する場合は問題ないことに注意してください。

@ 1138-4EBhttps ： //github.com/moby/buildkitを参照して

驚くべきことに、これはまだ問題とトピックです。 「inCLUDEsomeimage」を作成するのはどれほど難しいですか。解析するときに、ベースが互換性があることを確認し（FROMチェーン内）、互換性がある場合は、その時点でそのファイルの残りを実行します（プロジェクトからDockerfileをコピーしたかのように）そしてそれを私のものに貼り付けました）？

「人々は気づかない悪いことをするだろう」という言い訳全体は、この文脈ではばかげています。 これはすでにめちゃくちゃ複雑であり、それを単純化するためにこれが必要な理由です。

@rainabbaこれはまったく役に立たないコメントです。
それが行われない理由は基本的に2つあります。

1. それほど簡単ではありません
2. 誰もその仕事をするのに時間をかけていません。

実際には、通常は両方です。

1. これは、コードのどこにあるかを知っていれば、新しいコーダーが10分以内に達成できる構文解析と文字列置換の問題です。 すべての場合に使用できるとは言いませんが、ここで何度も提案されている限られたケース（ベースが事実上一般的である場合）では、デッドリンガーです。

2. もちろんそうではありませんが、このスレッドは、実行できない、または実行すべきではない理由を102まで提供します。それでは、なぜ誰もがそれを実行しようと考えるのでしょうか。

一方、私のコメントは（ここにある他の多くの人のように）、邪魔な態度に影響を与えるか、少なくともリマインダーとして機能する必要があり、希望を持っていることを示すのに役立ちます。 それが「まったく役に立たない」場合は、この問題（機能要求を無視）がまだここにあり、アクティブであり、技術的な問題ではない理由を説明したばかりです。

これは、道より多くの文字列を解析よりもです。
DockerとDockerfileは、何百万もの人々によって使用されています。 APIを追加することは重要です...それ以外でも、基礎となる実装は「文字列の解析」ではありません。

いずれにせよ、問題を解決するための多くの提案があり、これは非常に古くて閉じた問題です。

Dockerがこのシナリオのクリーンな解決策を見つけられない場合、おそらくそれを理解するツールに置き換えられると思います。

同僚の1人が次のパターンを使用していることに気付きました。これは、適切な回避策である可能性があります。

ARG from
FROM $from
... rest of dockerfile

私はそれを自分で試したことがないので、実際にどのように機能するかわかりません。たとえば、キャッシュでどのように動作するかなどです。

確かに、これは非常に重要な問題であり、適切に対処されていません。 Dockerがまだ取り組んでいないほど大きな会社に驚いています。

ちょうど私の2セント...私は今Dockerについてもっと学んでいて、INCLUDEのようなものが非常に役立つと感じています。 私は上記の多重継承の例が好きで、起こりうる問題とそれとの衝突についてのコメントに対処したいと思いました。

多重継承は、それをサポートするどの言語でも難しいですが、競合が発生した場合、Dockerファイル作成者は、実行していることを再考してやり直す責任があります。 Dockerはイメージをビルドするだけで、ビルドに問題がないことを証明しようとしないでください。

@cosminonea

INCLUDEのようなものがとても便利だと思います

https://github.com/larytet/dockerfile-generator/でマクロをサポートしています。「include」もサポートできます。

それは要点を逃しているでしょう。 目標はDockerfileを含めないことです
意味。 目標は、Dockerイメージを含めることです。 これは
それは私の頭のてっぺんから外れているので、ばかげているようです：

フェドーラから
ubuntu / ubuntuを含める
debian / debianを含める

当然のことながら、これはフェドー​​ラのイメージから始まると思います。
次に、フォルダー/ ubuntuの下にubuntuのイメージを追加します。 次に、を追加しました
/ debianの下のdebianの画像。

これはもちろんばかげています、それでなぜ私はたくさんの操作を混ぜたいのですか
システムを1つの画像に？ しかし、より有用な例は次のとおりです。

フェドーラから
プレックス/プレックスを含める
commericalremover / plex / add-on / commericalremoverを含める

この場合、それはより理にかなっています。 その中でこれらが他の画像である場合
特定のコンポーネントを操作する必要はありません私は物事を作る簡単な方法があります
基本単位。

午前15時48分の水、2018年8月8日には、アルカディMiasnikov [email protected]
書きました：

INCLUDEのような感じ
でマクロをサポートしています
https://github.com/larytet/dockerfile-generator/ 「インクルード」を追加でき
サポートも。

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

その最後のものはすでに可能です。 COPY --fromは、ビルドステージとイメージの両方を受け入れます。たとえば、

FROM busybox

COPY --from=alpine:latest / /
COPY --from=docker:latest /usr/local/bin/docker /usr/local/bin/

編集; または実際の例を取り上げます。

FROM fedora

COPY --from=ubuntu:latest / /ubuntu/
COPY --from=debian:latest / /debian/

その通り。 そのため、「COPY」を追加した2017年のアップデートを検討します。
--from」は元のリクエストを完了したものとして。絶対にあります
このチケットから私が探していたものはこれ以上ありません。

インクルードの自動リベースのように後で持ち上がったアイデアは、
素晴らしい機能。 しかし、彼らは当初の質問を超えています。

よろしく、

明細書

12時55分に木、2018年8月9日には、SebastiaanバンStijn [email protected]
書きました：

その最後のものはすでに可能です。 COPY--fromは両方を受け入れます
ビルドステージ、またはイメージなど。

忙しいボックスから

COPY --from = alpine：latest //
COPY --from = docker ：latest / usr / local / bin / docker / usr / local / bin /

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

@thaJeztahこれにマルチステージビルドを使用するには、各イメージからコピーするファイルを_正確に_知る必要があります。 これは、セットアップコードを別のイメージからコピーして貼り付けるよりも維持するのがさらに困難です。

もちろん、Dockerイメージのマージは簡単ではありません。 ビルド中に任意のスクリプトを実行できるため、ビルドプロセスは、自動競合検出の一般的な試みに抵抗します。 停止性問題はこんにちはと言います！ あなたができる最善のことは（ビルドができることを大幅に制限することを除いて）正確なセマンティクスを定義することです：最後のFROM / INCLUDE勝利（たとえば、同じファイルを「書き込む」場合）またはファイルシステムレベルの競合で失敗するか...。

時々述べられるさまざまな「ベース」イメージの問題（ストレッチvs ubuntu vsアルパインvs ...）、ただし、_is_ simple：イメージの依存関係のDAGには、単一のソース（現在のイメージ）だけでなく、単一のシンクも必要です。 （「階層」内のすべての画像の共有された「祖先」）。

もちろん、最終的には、garbage-in-garbage-outが発生しますが、実際にはこれまでとは異なりますか？

FWIW、私のユースケースは次のとおりです。

1. PostgreSQLデータベースとS3オブジェクトストアを使用してTomcatWebアプリケーションを実行します。
   これはDockerComposeを使用して解決できますが、単一のコンテナーの方が適している場合があります。
2. 多言語ビルドはDockerコンテナで実行されます（Jenkins、Circle CIなど）。
   最も人気のあるツールチェーンの公式イメージがありますが、ここで説明した問題では、複数の実行を処理するために単一のコンテナーを装備することができます。

@ reitzig 、

• https://github.com/avirshup/DockerMake
• http://docteurklein.github.io/2015/01/11/docker-auto-builds-and-me/
• https://blog.dockbit.com/templating-your-dockerfile-like-a-boss-2a84a67d28e9
• https://github.com/larytet/dockerfile-generator/

@reitzigこれが唯一のオプションではありません。 正しいオプションは、大きな問題を回避するためにINCLUDEを制約することです。 INCLUDEは継承できません。 そこにそれがある。 単純。 それでも信じられないほど便利です。

この機能リクエストは人気がありますが、DockerはBeerのように無料ですが、Freedomのように決して無料ではありません。

@rjurney 18.06以降のビルドキットサポートの

もちろん、カスタムDockerfileフロントエンドに独自の「INCLUDE」動作を追加することもできます。または、Dockerfileとはまったく異なることを行うこともできます（buidpackの例があります）。

カスタムフロントエンドを使用するには、Dockerを処理できるイメージに向ける必要があります。 Dockerfileの最初の行（またはそれが何であれ）へのコメントとしてこれを行いますsyntax = myCustomFrontendImage

詳細はこちら：
https://docs.docker.com/develop/develop-images/build_enhancements/#overriding -default-frontends

buildkitを有効にすると、Dockerは、必要な機能を使用して、必要なものをビルドできます（Dockerfile形式である必要はありません）。

この機能リクエストは人気がありますが、DockerはBeerのように無料ですが、Freedomのように決して無料ではありません。

そのメモはオフトピックですが、あなたが間違っていることに注意する必要があると思います。 DockerのApacheライセンスのおかげで、誰もがここで開発された機能を提供するDockerfiles用の独自のインタープリターをフォークして開発する自由があります。 注意すれば、結果のイメージは既存のDockerランタイム/ツールと互換性があります。
もちろん、Dockerプロジェクトのメンテナも同様に、そのような機能をフォーク（元の？）にマージしないように自由にできます。

@reitzigそれは、実際に自由ソフトウェアとは何かを言及しなければ、明らかに無意味な暴言です。 もちろん、Mobyはフリーソフトウェアです。

現在Apacheのライセンスが付与されていることを知りませんでした。 ご発言をお詫び申し上げます。
これは素晴らしいと思います！

ラッセル・ジャーニー@rjurney http://twitter.com/rjurney
ラッセル。 [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

4:17ラファエルR.ので水曜日、2019年1月16日に[email protected]書きました：

この機能リクエストは人気がありますが、DockerはBeerのように無料ですが、
FreedomのようにFreeを意味します。

そのメモはオフトピックですが、あなたは
間違い。 DockerのApacheライセンスのおかげで、誰もが自由に
フォークして、Dockerfiles用の独自のインタプリタを開発します。
ここで開発された機能。 注意すれば、結果の画像は次のようになります
既存のDockerランタイム/ツールと互換性があります。
もちろん、Dockerプロジェクトのメンテナも同様に自由です。
そのような機能をフォーク（元の？）にマージします。

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

すみません、よく眠れず、間違えました。 私のコメントは立っています。
ビールのように無料はApacheを意味します。 自由のように自由とは、コミュニティの管理を意味します。
Apacheプロジェクトまたはその他の形式のガバナンス。

ラッセル・ジャーニー@rjurney http://twitter.com/rjurney
ラッセル。 [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

2019年1月16日水曜日12:32 PM Russell Jurney [email protected]
書きました：

現在Apacheのライセンスが付与されていることを知りませんでした。 ご発言をお詫び申し上げます。
これは素晴らしいと思います！

ラッセル・ジャーニー@rjurney http://twitter.com/rjurney
ラッセル。 [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

4:17ラファエルR.で水曜日、2019年1月16日には[email protected]
書きました：

この機能リクエストは人気がありますが、DockerはBeerのように無料ですが、
FreedomのようにFreeを意味します。

そのメモはオフトピックですが、あなたは
間違い。 DockerのApacheライセンスのおかげで、誰もが自由に
フォークして、Dockerfiles用の独自のインタプリタを開発します。
ここで開発された機能。 注意すれば、結果の画像は次のようになります
既存のDockerランタイム/ツールと互換性があります。
もちろん、Dockerプロジェクトのメンテナーも同様に自由です
そのような機能をフォーク（元の？）にマージしないでください。

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

ビールのように無料はApacheを意味します。

同意しない。 フリーウェアはプロプライエタリソフトウェアにすることができます。

自由のように自由とは、コミュニティの管理を意味します。

コミュニティコントロールとは何ですか？ 財団によって運営されているプロジェクト？ では、VS Code、Atomエディター、Ubuntuを非フリーソフトウェアと見なしますか？ その場合、あなたの定義は、FSF、EFF、および他の多くの組織によって提案されたものとは大幅に異なります。

Docker Incがこの問題でコミュニティと積極的に話し合っていないことに同意しますが、これは「FreeasinFreedom」とは何の関係もありません。

申し訳ありませんが、課題追跡システムでこの種のディスカッションを行わないようにしましょう。

DockerIncがこの問題でコミュニティと積極的に話し合っていないことに同意します

docker buildを介して、必要なビルド形式をサポートできるようになりました。 「公式の」Dockerfile形式はこのオプションをサポートしていませんが、それはdocker buildがそれを利用できないという意味ではありません。
docker buildで動作するカスタムフロントエンドを構築する例として、 https：//matt-rickard.com/building-a-new-dockerfile-frontend/を確認して
このフロントエンドは、Dockerfile形式とはまったく異なることを行う方法の例ですが、必須ではないことに注意してください。 必要に応じて、既存のDockerfile形式を使用して、独自の機能を追加できます。

公式のDockerfile形式に何かを追加する限り、提案はいつでも歓迎されます。形式はます。
ただし、すべての新機能は、将来実行できることを制限することを含む、保守の新しい負担を意味することを覚えておいてください。

複数のDockerfileを組み合わせるユースケースの多くは、Dockerfileの新しい機能で実際に解決できる可能性が高いと思います...具体的には、任意の画像からCOPY --fromとRUN --mountを取得する機能です。

この架空のINCLUDEで、@＃$％を指定する必要がなく、暗黙の詳細として追加のコンテナーを作成できれば、構成可能なコンテナーの暗黙的で危険な売り込みを取り巻くフラストレーションの量を大幅に減らすことができます。 私は本当にアプリケーションに戻って機能を提供したいだけです。 悪い雰囲気で申し訳ありませんが、私はdocker / container noobであり、他の多くのポスターがすでに表現しているのと同じ混乱に遭遇しました。

これができるとしたら：

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   custom image (with both python and rust)
             \                                 /
              \----- rust:1.44-alpine3.12 ----/

_両方の画像が同じ画像の子孫であることに注意してください。 これが鍵です！_

これと同じくらい簡単：

FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

_「COPY--fromimage」命令（マルチステージビルド）を使用する場合と比較して、実装の詳細（コピーするファイル/環境変数）について考える必要はありません。_

画像を組み合わせたい場合の現在の様子

FROM alpine:3.12.0

# INCLUDE rust:1.44-alpine3.12
COPY --from=rust:1.44-alpine3.12 / /
ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH \
    RUST_VERSION=1.44.1

# INCLUDE python:3.8.3-alpine3.12
COPY --from=python:3.8.3-alpine3.12 / /
ENV PATH /usr/local/bin:$PATH
ENV LANG C.UTF-8
ENV GPG_KEY E3FF2839C048B25C084DEBE9B26995E310250568
ENV PYTHON_VERSION 3.8.3
ENV PYTHON_PIP_VERSION 20.1.1
ENV PYTHON_GET_PIP_URL https://github.com/pypa/get-pip/raw/eff16c878c7fd6b688b9b4c4267695cf1a0bf01b/get-pip.py
ENV PYTHON_GET_PIP_SHA256 b3153ec0cf7b7bbf9556932aa37e4981c35dc2a2c501d70d91d2795aa532be79

_ENV-命令は、これらのイメージのDockerfileからコピーして貼り付けられます。_

これにより、コンテナの再利用が大幅に向上し、コンパイルやビルドに時間がかかる可能性のあるものを非常に簡単にまとめることができます。

このアプローチでは、プログラムはプラットフォーム/ベースイメージのバージョンごとに1回だけコンパイルする必要があり、自分で実装するよりも再利用する方が簡単であると考えてください。 優れた/ユニバーサルなパッケージマネージャーがないために、C ++で「ホイールが再実装された」回数を考えてみてください。 Dockerでも同様の状況が発生するようにしますか？

@ bergkvist 、 https： //github.com/moby/moby/issues/3378#issuecomment-381449355およびhttps://github.com/moby/moby/issues/3378#issuecomment-381641675を参照してください。

あなたが提案する解決策のどれも図に対応していないように私には感じます。 代わりに、次のことを行っています。

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   \
             \                                   \
              \----- rust:1.44-alpine3.12 --------\ custom image 

したがって、 rustで変更されたファイルはすべてpythonで上書きされ

@eineはい、競合が発生した場合、ファイルは上書きされます。 それは本当だ。 したがって、図が対称であるということは、（関連する）ファイルが重複していない場合の特殊なケースになります。 図のバージョンはより一般的です。

両方の画像を同じ正確な画像から継承することについての私のポイントは、重大な競合の可能性はわずかである可能性があるということです。

パッケージマネージャーファイルに関連するいくつかの競合が発生する可能性があると思います。 両方のイメージがパッケージマネージャーを使用して異なるものをインストールした場合。 ある種の特殊なケースで処理できるような「一般的な競合」が他にあるかどうかはわかりません。

2つのファイルをマージするのは簡単ではありません。 一般的なケースでは、賢くしようとするよりも、単に上書きする方が良いかもしれないと思います。 少なくとも、うまくいかないときはデバッグが簡単になります。

4日前にここにコメントしたので、Golangを学び、moby / buildkitコードのフロントエンドコードを調べることにしました。

上記で説明したように、INCLUDEステートメントを受け入れるカスタムフロントエンドを作成しました。

#syntax=bergkvist/includeimage
FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

カスタム構文を使用するには、ビルド時にDOCKER_BUILDKIT = 1を設定することを忘れないでください。

DOCKER_BUILDKIT=1 docker build -t myimage .

コードはここから入手できます： https ：
そしてDockerHubのイメージ： https ：