コンピュータプログラミングの問題の1つは、同じ名前が常に異なる目的で使用されていることです。たとえば、名前空間という用語 多くの異なる方法で使用されます。人々がKubernetes内の名前空間について話すとき、私はしばしば混乱します。たとえば、この用語を聞いて仮想クラスターについて考える人もいますが、それを聞くと、ポッドやコンテナーで使用されるLinux名前空間を思い浮かべます。同様に、 image コンテナレジストリに保存されているVMイメージ、コンテナイメージ、またはOCIイメージを参照できます。
[次のこともお勧めします：7つの楽しいLinuxコンテナ/画像転送機能]
しかし、コンテナの世界では、 containerほど使い古された用語はありません。 。
最近、ユーザーがPodmanの問題を作成し、この用語に対する不満を表明しました：
不明確な用語：画像とコンテナ
私の理解では、そのイメージは読み取り専用のテンプレートですが、コンテナーは読み取り/書き込みのものです。いつも。したがって、何かがコンテナである場合、podmanとbuildahの両方がそれをコンテナと見なします。何かが画像である場合、podmanとbuildahの両方がそれを画像と見なします。
私は--nameabcスクラッチからbuildahを呼び出します。 buildah画像とpodman画像の出力は同じであり、新しいものを画像とは見なしません。
podmanコンテナlsには何も表示されないため、新しいものは、コンテナではなくpodmanの観点からのものです。
ただし、 buildahコンテナは新しいものを返すため、新しいものはコンテナになります（CONTAINER NAME =abc、IMAGE NAME =strike、BUILDER =* =yes IMAGE ID =""）。
つまり、新しいものはbuildahの観点からはコンテナですが、podmanの観点からはコンテナではありません。これは完全に紛らわしいです。
buildahの観点からのコンテナとpodmanの観点からのコンテナの違いについて詳しく説明してください。
コンテナについて考えます 実行する準備ができている環境または何かの中でプロセスを実行することとして。対照的に、画像 コミットされたコンテナであり、新しいコンテナを作成するために他の人と共有する準備ができています。
使用しているコンテナエンジン（Podman、Buildah、CRI-O、Skopeo）はすべて、同じイメージの概念を共有しています。
イメージはコンテナー/イメージで定義され、コンテナーレジストリ、Dockerアーカイブ、OCIアーカイブ、docker-daemon、コンテナー/ストレージなどのさまざまなストレージまたはトランスポートに保存されます。これらのストレージタイプまたはトランスポートについては、以前の記事で書きました。
ほとんどの人は、画像をコンテナ/ストレージまたはコンテナレジストリに配置されていると考えています。この説明の残りの部分では、コンテナ/ストレージに集中します。
ちなみに、Skopeoはコンテナの概念がないため、実際にはコンテナエンジンではありません。代わりに、Skopeoはコンテナ画像を処理し、異なるタイプのコンテナストレージ間でそれらを移動するだけです。
コンテナ/ストレージコンテナ
コンテナ/ストレージライブラリは、ストレージコンテナの独自の概念も提供します。基本的に、ストレージコンテナは、まだコミットされていない中間ストレージコンテンツです。これは、ディスク上のファイルとコンテンツを説明するJSONと考えてください。
Podman、Buildah、CRI-Oはすべてストレージコンテナを使用しています 。 3つのコンテナエンジンすべてに、それ自体に固有の追加データもあります。
Buildahコンテナ
Buildahコンテナーには、ContainerfileまたはDockerfileを構成するさまざまなコマンドを参照する追加のコンテンツが含まれています。
たとえば、Workingdir、Env変数、およびその他のデータは、コンテナイメージの構築に使用されます。
Podmanコンテナ
Podmanには、Podmanコンテナに関連するデータの独自のデータストアがあります。 Podmanデータベースには、Buildahデータベースよりもはるかに多くのデータが保存されています。 Buildahデータベースは、Podmanデータベースのサブセットと考えることができます。
CRI-Oコンテナ
CRI-Oには、コンテナを記述するための独自のデータストアもあります。
3つのツールはすべて異なる進化を遂げており、独自のコンテナに対するアイデアや要件も異なります。
たとえば、CRI-Oコンテナは、それらを制御する単一のデーモンに依存して進化しました。パフォーマンスと、KubernetesCRIに対する1秒あたり数百/数千の応答を共有する必要性に重点が置かれています。 CRI-Oは、データストアを処理するのはCRI-Oだけであることを認識しているため、情報をメモリに保存することを利用できます。 CRI-Oは、知らないうちに他のプロセスが入ってコンテナを変更することを気にする必要はありません。
一方、Podmanは、コンテナの複数のユーザーを同時に処理する必要があります。ファイルシステムのロックにさらに依存し、何百ものPodman実行可能ファイルが同じデータストアを確実に共有できるようにする必要があります。最終的にPodmanのデータストアをCRI-Oにマージして、CRI-OとPodmanがより適切に連携できるようにすることについて話し合いましたが、時間の経過とともに、リスク/メリットをマージすることを正当化するのは難しいと感じています。
Buildahも独立したツールとして開発されました。メンテナは、Podmanデータストアの不要な重みと複雑さを、追加のメリットをほとんどまたはまったく受けずに引き受けることを後押ししました。 Buildahコンテナには1つの目的があります。それは、コンテナイメージを構築することですが、ほとんどのPodmanコンテナは、アプリケーションとサービスの実行に関するものです。 Buildahコンテナには、Podmanが必要とするすべての情報が含まれているわけではありません。
Podmanは、buildah from scratchして作成されたコンテナをどのように処理しますか コマンド？
これらの部分的に作成されたコンテナを別の方法で処理する必要があります。したがって、Podmanにそれらを同等と見なさせるか、デフォルトでpodman psにリストするようにします。 コマンドはユーザーを混乱させるでしょう。
互換性
Podmanは実際にこれらのコンテナを操作できます。
Podmanの最新バージョンでは、システムで利用可能なストレージコンテナを一覧表示できるようになりました。
$ podman ps -a --external | grep buildah
578edf9430ee scratch buildah 13 days ago storage working-container これらのコンテナをマウントおよびアンマウントできます：
# podman mount working-container
/home/dwalsh/.local/share/containers/storage/overlay/a4f596beaabdc78efc7694a67d690097e327aa12bbc59165d011e62b646e93c0/merged
# podman unmount working-container
working-container これらのコンテナを削除することもできます：
$ podman rm working-container
working-container
podman buildを使用してこれらのコンテナを作成することもできます 。もちろん、これらのコンテナはビルド中に一時的にのみ作成されます。これらのBuildahコンテナにはPodmanコンテナと同じデータがないため、Podmanはそれらを開始および停止できず、podman ps 実行中は表示されません。
Podmanには、CRI-Oコンテナを操作する同様の機能もあります。
[この無料のチートシートでKubernetesの使用の基本を学びます。 ]
まとめ
コンテナという用語については 、コンテキストはしばしば重要です。用途の違いを理解することが不可欠です。コンテナツールに関しては、基盤となるコンテンツ、ストレージ、ライブラリのほとんどを共有しています。ただし、各ツールの概念や定義、またはそれらのコンテナがわずかに異なるのには正当な理由があります。