この一連の記事：
ディレクトリ
1ドッカーアーキテクチャ
2つのドッカー成分
3ドッカープロセス
3.1クライアントプロセス
3.2サーバー・プロセス
3.3レジストリプロセス
1ドッカーチャート
私は最初、3つのことを行うには良いアーキテクチャ図を考える：すべての重要なコンポーネントことを証明するために、第二に：明確レベル、スコープと通信プライマリとセカンダリのこれらの構成要素の関係を定義します。第三：人々が一目できることをシンプルに十分であることが。私は、すべてのアーキテクチャ図が行われた上だと思います。
クライアント（クライアント）、サーバー（ドッカーデーモン呼ぶdockerd）及び登録サーバ3つの成分（レジストリ）によってドッカーは、典型的には、C / Sアーキテクチャです。前記操作対象サーバ側コンポーネントは、次のとおり鏡（画像）と容器（コンテナ）。ドッカー様々な構成要素は、同じホスト上または別のホスト上にあってもよいです。したがって、ドッカーは、もはや簡単なツールとして見られないことができますが、プラットフォームとして見られるべきです。
2つのドッカー成分
ドッキングウィンドウの3つのコンポーネントが使用すると、生産と加工企業のアナロジーを使用することができますその職務を、行っています。
1）ドッキングウィンドウのクライアント：管理。デーモンは、ドッキングウィンドウに仕事の組織の責任です。
2）ドッキングウィンドウレジストリ：セクタを倉庫。原料（画像）を記憶する責任を負います。
3）ドッキングウィンドウデーモン：生産部門。倉庫及び通信部門、原材料へのアクセス、および通信管理は、製造品（容器）のタスクを与えられました。
3ドッカープロセス
ドッカーがデフォルトのレジストリケースではインストールされません。次のようにクライアントデーモンパッケージパスは、次のとおりです。
1）クライアント：は/ usr / binに/ドッカ
2）デーモン：は/ usr / binに/ dockerd
3.1クライアントプロセス
客户端进程生命周期很短，从发送命令给 daemon，再到 daemon 响应返回、打印到控制台，往往几秒钟就结束了。下图是客户端进程的一个快照。
3.2 服务端进程
可以直接使用如下命令来启动服务端进程。
但是一般情况下，docker 安装程序会将服务端封装成一个操作系统后台服务，然后交给系统控制器 (systemctl) 来统一进行管理。这样做的好处是以后可以只通过名称(docker)而不是路径(/usr/bin/dockerd) 来管理后端服务了。
sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl stop docker
sudo systemctl restart docker
sudo systemctl status docker
后台服务配置文件路径 /usr/systemd/system/docker.service。截图如下：
从截图可以看出系统服务运行时会依赖哪些其他服务（Unit单元）、真正调用的后台程序是（/usr/bin/dockerd)、资源限制（Limit）、重启策略（Restart）等。
执行如下命令启动服务端进程。
sudo systemctl start docker
ps aux | grep dockerd | grep -v grep
3.3 registry 进程
这里首先要区分两个概念：registry 和 repo。repo 仅仅表示存储概念，而 registry 是 repo + 认证(鉴权、授权)。也就是说仓库并不是谁访问都可以，它还需要有一个认证和准入的操作。
また、レジストリだけでなく、公共および民間のポイント。ドッキングウィンドウのデフォルトは、公開レジストリ（hub.docker.com）です。だから、プロセスのローカルレジストリで見ることができません。あなたはまた、ローカルレジストリにプロセスを見たい場合は、レジストリのミラーリングをダウンロードして、ジョブを実行してコンテナに画像をロードする必要があります。
須藤ます。mkdirは/ opt /データ/レジストリ-p
sudoのドッキングウィンドウの実行には、-p 5000を-d：5000 -vは/ opt /データ/レジストリ：/ tmpに/レジストリレジストリ：2
