web-dev-qa-db-ja.com

Dockerコンテナー内のプロセスはどのように見えますか?

Dockerコンテナーの内部で呼び出すコマンドとプロセスに関して、最近Dockerコンテナーとは何か、具体的には内部で何が起こっているかについて混乱が何度かあると聞きました。

誰かが何が起こっているのかについての高レベルの概要を提供できますか?

33
slm

Dockerは仮想化バケットに投入されます。これは、ハードウェアを仮想化していると人々が想定しているためです。これは、Dockerが使用する用語、主にコンテナーという用語から浸透する誤称です。

ただし、Dockerはシステムのハードウェアの仮想化に関して魔法のようなことはしていません。むしろ、それは、プロセスがネットワーク、ファイルシステム、アクセス許可などのリソースと対話して、対話しているような錯覚を与えることを可能にする、主要機能の周りに「フェンス」を構築するLinuxカーネルの機能を利用しています。完全に機能するシステム。

Dockerコンテナを起動して/bin/bashを呼び出して入力したときの状況を示す例を次に示します。

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

さて、このコンテナの中から、ps -eafを実行すると:

ss01

Dockerコンテナーをホストしているホストシステムにログインしている別のターミナルタブに切り替えると、コンテナーが「実際に」使用しているプロセススペースを確認できます。

ss02

Dockerタブに戻り、その中のいくつかのプロセスを起動してそれらすべてをバックグラウンド化すると、Dockerコンテナーの起動の一部として最初に開始したプライマリBashプロセスの下でいくつかの子プロセスが実行されていることがわかります。

注:プロセスは4つのsleep 1000コマンドであり、バックグラウンドで実行されています。

ss03

Dockerコンテナー内で、プロセスに48〜51のプロセスID(PID)が割り当てられていることに注目してください。それらのps -eaf出力でも確認してください。

ss04

ただし、この次の画像では、Dockerが実行している「魔法」の多くが明らかになります。

ss05

4つのsleep 1000プロセスが実際に元のBashプロセスの単なる子プロセスであることを確認してください。また、元のDockerコンテナ/bin/bashは、実際にはDockerデーモンの子プロセスでもあることに注意してください。

ここで、元のsleep 1000コマンドが完了するまで1000秒以上待ってから、さらに4つの新しいコマンドを実行し、次のように別のDockerコンテナーを起動します。

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

ps -eafからのホストコンピュータの出力は次のようになります。

ss06

そして、他のDockerコンテナはすべて、Dockerデーモンの下のプロセスとして表示されます。

ご覧のとおり、Dockerは実際には仮想化されていません(伝統的な意味)。さまざまなカーネルリソースの周りに「フェンス」を構築し、特定のプロセス+子の可視性を制限しています。 。

55
slm

Insideコンテナ。プロセスは隔離(隔離)されている必要があります。実際には、指定したプロセス以外のプロセスは表示されません(少なくともシェル)。 「社交性」テスト用ではありません。 chrootとの唯一の類似点は、ホストカーネルが使用されることです。 Dockerは、何かを分離する必要がある場合、またはホストで実行されているものとは異なるバージョンのプラットフォームアーキテクチャソフトウェアを使用する場合に最適です。 (JavaまたはPythonの別のフォーク)の非常に古いバージョン。処理しているフォルダとバイナリが同じではない可能性があることに注意してくださいホスト上のものと同じです。/binフォルダーなどとは異なります。

編集:VMではなくchrootとの類似性。

3
mckenzm