Docker コンテナとイメージを理解するのに役立つ 10 枚の写真

[[271565]]

この記事は、読者が Docker コマンド、コンテナとイメージの違い、コンテナと実行中のコンテナの違いをより深く理解するのに役立つことを願っています。

私がまだ Docker テクノロジーに少ししか詳しくなかった頃は、Docker コマンドを理解するのが非常に難しいと感じていました。そこで私は数週間かけて、Docker の仕組み、より正確には Docker 統合ファイルシステムに関する知識を学習しました。その後、Docker コマンドを振り返ってみると、すべてが自然でシンプルになりました。

余談ですが、個人的には、技術を習得し、合理的に使用するための最良の方法は、その背後にある動作原理を深く理解することです。通常、新しいテクノロジーの誕生には、メディアによる大々的な宣伝や宣伝が伴うことが多く、ユーザーがそのテクノロジーの本質を理解することが難しくなります。もっと正確に言えば、新しいテクノロジーは、その普及を促進するために常に新しい用語や比喩を生み出します。これは初期段階では非常に役立ちますが、テクノロジーの原理にサンドペーパーの層をかぶせることになり、後期段階でユーザーがテクノロジーの真の意味を理解するのに役立ちません。

Git は良い例です。以前は Git をうまく使いこなせなかったので、時間をかけて Git の原理を学びました。そのとき初めて、私は Git の使い方を本当に理解したのです。 Git の内部を本当に理解している人だけがこのツールを使いこなせると私は固く信じています。

画像の定義

イメージは、一連の読み取り専用レイヤーの統合ビューです。この定義は理解するのが難しいかもしれません。次の図は、読者が画像の定義を理解するのに役立ちます。

左側には、複数の読み取り専用レイヤーが重なり合っているのがわかります。最下層を除き、各層には次の層を指すポインターがあります。これらのレイヤーは Docker 内部の実装の詳細であり、ホストのファイル システムからアクセスできます。統合ファイル システム テクノロジは、さまざまなレイヤーを 1 つのファイル システムに統合し、これらのレイヤーに対して統一された視点を提供することで、複数のレイヤーの存在を隠すことができます。ユーザーの観点から見ると、ファイル システムは 1 つだけです。この遠近法の形は写真の右側で見ることができます。

これらのレイヤーのファイルは、ホスト ファイル システム上にあります。これらのレイヤーは実行中のコンテナ内では表示されないことに注意してください。私のホストでは、/var/lib/docker/aufs ディレクトリの下に存在していました。

 sudo ツリー -L 1 /var/lib/docker/
 /var/lib/docker/├── aufs├── containers├── graph├── init├── linkgraph.db├── repositories-aufs├── tmp├── trust└── volumes7 ディレクトリ、2 ファイル

コンテナの定義

コンテナの定義はイメージの定義とほぼ同じであり、レイヤーのスタックの統一されたビューでもあります。唯一の違いは、コンテナの最上位層が読み取りおよび書き込み可能であることです。

注意深い読者は、コンテナの定義ではコンテナが実行中かどうかについては言及されていないことに気付くかもしれません。はい、これは意図的です。この発見のおかげで、多くの混乱を理解することができました。

重要なポイント: コンテナー = イメージ + 読み取り/書き込みレイヤー。また、コンテナの定義では、コンテナを実行するかどうかについては言及されていません。

次に、コンテナの実行について説明します。

実行中のコンテナ定義

実行中のコンテナは、読み取りおよび書き込み可能な統合ファイル システムと、分離されたプロセス スペースおよびそこに含まれるプロセスとして定義されます。次の画像は実行中のコンテナを示しています。

Docker を有望なテクノロジーにしているのは、ファイル システム分離テクノロジーです。コンテナ内のプロセスはファイルを変更、削除、または作成する可能性があり、これらの変更は読み取り/書き込みレイヤーで実行されます。次の画像はこの動作を示しています。

次のコマンドを実行すると、上記の内容を確認できます。

 docker run ubuntu touch happiness.txt

Ubuntu コンテナが実行されていない場合でも、ホストのファイル システムで新しいファイルを見つけることができます。

検索 / -名前happiness.txt
 /var/lib/docker/aufs/diff/860a7b...889/happiness.txt

散在するデータを統合するために、イメージレイヤーの概念を提案しました。次の図はイメージレイヤーについて説明しています。この図から、レイヤーにはファイル システムへの変更だけでなく、その他の重要な情報も含まれることがわかります。

メタデータはこのレイヤーに関する追加情報であり、Docker が操作中および構築中に情報を取得できるようにするだけでなく、親レイヤーの階層情報も含まれます。読み取り専用レイヤーと読み取り/書き込みレイヤーの両方にメタデータが含まれていることに注意してください。

さらに、各レイヤーには親レイヤーへのポインターが含まれています。レイヤーにこのポインターがない場合は、そのレイヤーが最下層にあることを意味します。

メタデータの場所:

自分のホストでは、イメージ レイヤーのメタデータが「json」という名前のファイルに保存されていることがわかりました。次に例を示します。

 /var/lib/docker/graph/e809f156dc985.../json

e809f156dc985...はこのレイヤーのIDです

コンテナのメタデータは多くのファイルに分割されているようですが、大体/var/lib/docker/containers/にあります。ディレクトリで見つかった、読み取り可能なレイヤーの ID です。このディレクトリ内のファイルのほとんどは、ネットワーク、ログなどのランタイム データです。

すべてを結びつける

ここで、上記の実装の詳細と合わせて Docker コマンドを理解していきましょう。

 docker create <イメージID> 

docker create コマンドは、指定されたイメージに読み取りおよび書き込み可能なレイヤーを追加し、新しいコンテナを形成します。このコンテナは実行されていないことに注意してください。

docker start <コンテナID>

Docker の start コマンドは、コンテナ ファイル システムのプロセス分離スペースを作成します。各コンテナにはプロセス分離スペースを 1 つしか持つことができないことに注意してください。

docker run <イメージID>

このコマンドを見ると、読者は通常、「docker start コマンドと docker run コマンドの違いは何ですか?」という疑問を抱きます。

図からわかるように、docker run コマンドはまずイメージを使用してコンテナを作成し、次にコンテナを実行します。このコマンドは非常に便利で、両方のコマンドの詳細を隠しますが、その一方で、ユーザー間で誤解を招きやすい可能性があります。

話題から外れますが、前回の Git に関する話題の続きですが、docker run コマンドは git pull コマンドに似ていると思います。 git pull コマンドは、git fetch コマンドと git merge コマンドの組み合わせです。同様に、docker run は docker create コマンドと docker start コマンドの組み合わせです。

ドッカーps

docker ps コマンドは実行中のコンテナをすべて一覧表示します。これにより、実行されていないコンテナの存在が隠されます。これらのコンテナを検索するには、次のコマンドを使用する必要があります。

docker ps –a

docker ps –a コマンドは、実行中か停止中かに関係なく、すべてのコンテナを一覧表示します。

Docker イメージ

docker images コマンドはすべてのトップレベルのイメージを一覧表示します。実際、ここではイメージと読み取り専用レイヤーを区別する方法がないため、トップレベルのイメージを作成します。コンテナの作成に使用されたイメージ、または直接プルダウンされたイメージのみをトップレベル イメージと呼ぶことができ、各トップレベル イメージの下には複数のイメージ レイヤーが隠されています。

docker イメージ –a

docker images –a コマンドはすべてのイメージ、つまりすべての読み取り可能なレイヤーを一覧表示します。特定のイメージ ID の下にあるすべてのレイヤーを表示する場合は、docker history を使用して表示できます。

docker stop <コンテナID>

docker stop コマンドは、実行中のコンテナに SIGTERM シグナルを送信し、すべてのプロセスを停止します。

docker kill <コンテナID>

docker kill コマンドは、コンテナ内で実行されているすべてのプロセスに非友好的な SIGKILL シグナルを送信します。

docker pause <コンテナID>

docker stop コマンドと docker kill コマンドは、実行中のプロセスに UNIX シグナルを送信します。 docker pause コマンドは異なります。 cgroup の特性を利用して、実行中のプロセス空間を一時停止します。具体的な内部原理については、https://www.kernel.org/doc/Doc ... m.txt を参照してください。ただし、この方法の欠点は、SIGTSTP シグナルの送信がプロセスが理解できるほど単純ではないため、すべてのプロセスを一時停止できないことです。

docker rm <コンテナID>

docker rm コマンドは、コンテナを構成する読み取り/書き込みレイヤーを削除します。このコマンドは実行されていないコンテナでのみ実行できることに注意してください。

docker rmi <イメージID>

docker rmi コマンドは、イメージを構成する読み取り専用レイヤーを削除します。 docker rmi は最上位レイヤー (イメージとも呼ばれます) を削除する場合にのみ使用できますが、-f パラメータを使用して中間の読み取り専用レイヤーを強制的に削除することもできます。

docker commit <コンテナID>

docker commit コマンドは、コンテナの読み取り/書き込みレイヤーを読み取り専用レイヤーに変換し、コンテナを不変のイメージに変換します。

ドッカービルド

docker build コマンドは非常に興味深く、複数のコマンドを繰り返し実行します。

上図からわかるように、ビルドコマンドはDockerfileファイル内のFROM命令に従ってイメージを取得し、1)実行（作成・起動）、2)変更、3)コミットを繰り返します。ループ内の各ステップで新しいレイヤーが生成されるため、多数の新しいレイヤーが作成されます。

docker exec <実行中のコンテナID>

docker exec コマンドは、実行中のコンテナ内で新しいプロセスを実行します。

docker examine <コンテナID> または <イメージID>

docker inspect コマンドは、コンテナまたはイメージの最上位レベルのメタデータを抽出します。

docker save <イメージID>

docker save コマンドは、別のホストの Docker で使用できるイメージの圧縮ファイルを作成します。エクスポート コマンドとは異なり、このコマンドは各レイヤーのメタデータを保存します。このコマンドは画像に対してのみ有効です。

docker export <コンテナID>

docker export コマンドは、tar ファイルを作成し、メタデータと不要なレイヤーを削除して、複数のレイヤーを 1 つに統合し、統一された観点から現在表示されているコンテンツのみを保存します (翻訳者注: エクスポートされたコンテナーを Docker にインポートすると、docker images –tree コマンドを通じて 1 つのイメージのみが表示されます。保存されたイメージは異なり、このイメージの履歴イメージを表示できます)。

docker history <イメージID>

docker history コマンドは、指定されたイメージの履歴イメージを再帰的に出力します。