コンテナがサーバーパッケージを使用するか独自のパッケージを使用するかを判断するための決定的な方法

コンテナがサーバーパッケージを使用するか独自のパッケージを使用するかを判断するための決定的な方法

コンテナ化に関する私の理解は限られているため、この質問は見当違いである可能性がありますが、Docker コンテナはホスト システムのカーネル リソースの一部を利用して比較的軽量なままにしていることは事実です。私の知る限りでは、これは OS 分散パッケージ (binutils など) にも適用できます。

Docker コンテナにはホストが提供するパッケージを利用する機能があるという私の考えが間違っていないと仮定すると、コンテナが特定のサーバーでホストされているときにそのサーバー上で見つけることを意図/期待するすべてのパッケージを列挙する標準的な方法はありますか?

答え1

Docker コンテナは、比較的軽量なまま維持するために、ホスト システムのカーネル リソースの一部を利用していることは事実です。

はい、コンテナはホストカーネルを共有します。

私の知る限りでは、これは OS 分散パッケージ (binutils など) にも拡張できます。

それできるただし、これは非常に珍しいことであり、コンテナー外での手動セットアップが必要です。基本的には、ホストからボリュームをマウントして、コンテナーがファイル システムの関連部分にアクセスできるようにする必要があります。

ほとんどの場合、コンテナのユーザー空間部分はホストから完全に分離されています。コンテナがホスト上で見つけることを期待するパッケージを列挙する標準的な方法はありません。コンテナは通常そのような期待を持っておらず、そのような期待を宣言する方法もありません。そのようなコンテナに遭遇した場合は、ドキュメントでそれについて説明されているはずです。また、何らかのデプロイメント記述子があるかどうかも説明されているはずです (例えばたとえば、Kubernetes 用の Helm チャートなど) には、必要なボリュームとマウント ポイントが含まれます (ただし、ホストに何が必要かはわかりません)。

コンテナは実際にはホストに依存しません。適切なコンテナ ランタイムを備えた任意のシステムで実行され、ホストは任意のパッケージ システムを使用することも、まったく使用しないこともできます。そのため、コンテナにはホストからパッケージを要求するために必要な概念さえありません。これは、コンテナの背後にあるいくつかの基本原則に反することになります。

関連情報