ホストにインストールする必要があるすべてのソフトウェアがある場合、なぜLinuxディストリビューションをDockerfileベースとして提供するのですか？

Question

Dockerイメージの作成を開始します。私は、Amazon Linuxマシンに配備した.net Core 2.0 Web APIサービスを持っています。それは正常に動作しますが、ビルドとデプロイメントのプロセスを少し自動化したいと思います。

私が考える限り、私が構築する必要のある画像のための親画像は必要ありません。ある場所からいくつかのファイルを取得し、いくつかのdotnet CLIコマンドを実行し、Apacheをリバースプロキシとして使用してサービスを実行するかもしれません。私は本当にそれのいずれかで親画像の必要性を見ていない。

私が見た例のほとんどに基本イメージが含まれているので、私はこの質問をしています。たいていの場合、「From Ubuntu」のような非常に一般的なものです。私は、ほとんどの画像に親画像が含まれることを読んでいます。 Dockerのドキュメントによると、

親画像は、画像の元になった画像です。 DockerfileのFROMディレクティブの内容を参照します。 Dockerfileのそれ以降の各宣言は、この親イメージを変更します。ほとんどのDockerfilesは、ベースイメージではなく親イメージから開始します。しかし、これらの用語は、時々交換可能に使用されます。

正確にUbuntuを継承するポイントは何ですか？ Dockerのドキュメントでさえ、Debianを「非常に厳密に制御され、最小限に抑えられているので」と示唆しています。それはあなたのLinuxマシンにUbuntuディストリビューションがあることを保証しますか？ Amazon Linuxを使用していてDebianイメージをベースにしていても問題はありますか？

Answer 1

ドッカーイメージは、ボリュームをバインドマウントする場所以外のホストから接続されていないファイルシステムの名前空間のセットで動作します。つまり、ホストにインストールされたツールはコンテナで利用できません。ホストがAmazon Linuxを実行しているからといって、Amazon Linuxが提供するユーザースペースコマンド（およびそれらのコマンドを実行するために使用するライブラリ）がゲストに提供されるわけではありません。

コンテナ内でLinuxディストリビューションが利用できない場合、ファイルをダウンロードし、ソフトウェアを実行するツールをインストールするパッケージ管理ツール（yum、apt-getなど）はありません（おそらくlibc、OpenSSLのコピー、または他の共有コンポーネントにリンクされています）。あなたのディストリビューションによってユーザランドに提供され、Dockerのインストールでホストから共有されないリゾルバのような動作中のLinuxシステムのランタイム部分もあります。ベースイメージを使用して

はあなたのコンテナ内部で利用可能なツールを持っていることを保証します - とそれはそのコンテナが互換性のあるカーネルとハードウェアアーキテクチャで任意のLinuxシステム上で一貫して動作するようになります。

多くのツールをホストからバインドマウントすることができます（/usrをボリュームとして公開するなど）が、Dockerが移植性の点で多くの利点を失うことになります。