
Docker とは何ですか?また、それはどのように機能しますか?
docker クライアントは、REST API 経由でコマンドを dockerd デーモンに送信します。
イメージを構築し、そこからコンテナを実行します。存在理由 Docker を使用すると、アプリケーションとそのすべての依存関係 (ライブラリ、構成、ランタイム) を 1 つのアーティファクト (イメージ) にパッケージ化し、開発者のラップトップ、CI、本番環境で同様に実行できます。これにより、古典的な「自分のマシンでは動作する」という問題が解決されます。
コンテナと仮想マシン。 VM はハードウェアを仮想化し、独自のカーネルを備えたゲスト OS 全体を出荷します。コンテナは、ホストのカーネルを使用する分離されたプロセスです。その結果、コンテナーは軽量になり、数分の一秒で起動し、使用するリソースが少なくなります。しかし、コンテナは 軽量 VM ではありません。コンテナはホスト カーネルに結び付けられており、その分離境界は VM よりも弱いです。 VM はハードウェア強制分離を備えていますが、共有カーネルの脆弱性はコンテナから逃れられる可能性があります。これは速度と密度のトレードオフです。ホストはコンテナーの種類と一致する必要があります。Linux コンテナーには Linux カーネルが必要で、Windows コンテナーには Windows カーネルが必要です。 macOS と Windows では、Docker Desktop は小さな Linux VM を透過的に実行します (WSL2 経由など)。そのため、そこにある Linux コンテナーは、OS のカーネルではなく、その VM のカーネルを共有します。
アーキテクチャ (クライアント/サーバー)。 Docker のドキュメントによると:
dockerクライアントは、ユーザーが Docker と対話する主な方法です。docker runのようなコマンドがデーモンに送信されます。dockerdデーモン は、コンテナーの構築、実行、配布という「重労働」を実行し、イメージ、コンテナー、ネットワーク、ボリュームなどのオブジェクトを管理します。- クライアントは、UNIX ソケットまたはネットワーク インターフェイスを介して REST API 経由でデーモンと通信するため、異なるマシン上で実行できます。
- レジストリにはイメージが保存されます。デフォルトのパブリックなものは Docker Hub です。
イメージとコンテナ 分かりやすいたとえ: イメージはクラス (またはディスク上のプログラム) のようなもので、コンテナはそのインスタンス (実行中のプロセス) です。 1 つのイメージから多数のコンテナを起動できます。
- イメージは、レイヤーから構築されたコンテナーを作成するための手順を含む読み取り専用のテンプレートです。これは Dockerfile によって定義されます。変更すると、変更されたレイヤーのみが再構築されます。
- コンテナは、イメージの実行可能なインスタンスです。画像の読み取り専用レイヤーの上に、薄い 書き込み可能なレイヤー (コピーオンライト) が追加されます。コンテナーが削除されると、そこに書き込まれた内容はすべて失われます。まさにこれが、永続データにボリュームが必要な理由です。
分離の仕組み (内部)。 dockerd はカーネルを直接呼び出しません。コンテナのライフサイクル管理を containerd に委任し、OCI ランタイムを呼び出します。 Docker ではデフォルトは runc ですが、ランタイムはプラグイン可能です (crun、gVisor、Kata など)。実際の分離は、Linux カーネル機能によって行われます。
- 名前空間 はリソースを分離します (man7 ページによれば、PID、ネットワーク、マウント、UTS、IPC、ユーザー、cgroup、時間の 8 つのタイプがあります)。プロセスは、自身の PID や自身のネットワーク スタックなどを「認識」するだけです。
- cgroups (コントロール グループ) は、リソース使用量 (CPU、メモリ、I/O) を制限および考慮します。
一般的なフォローアップ。 画像レイヤーはキャッシュされます。 docker compose はマルチコンテナー アプリを実行します。データはボリュームを介して保持されます (コンテナーはデフォルトでは一時的です)。 OCI は、イメージ形式 (image-spec)、ランタイム (runtime-spec)、およびレジストリ配布プロトコル (distribution-spec) を標準化します。これら 3 つの仕様により、エコシステムの相互運用性が保たれます。
