client 模式
docker命令对应的源文件是docker/docker.go,
docker [options] command [arg...]
其中options参数为flag，任何时候执行一个命令docker命令都需要先解析flag，然后按照用户生命的command向指定的子命令执行对应的操作
如果子命令为daemom，docker都会创建一个运行在宿主机上的daemom进程，即执行daemom模式。其余子命令都会执行client模式。处于client模式命令工作流程包含几个步骤
1.解析flag信息
docker命令支持大量的option，或者说flag，列出对于client模式下的docker比较重要的一些flag
Debug，对应-D和--debug参数，他将向系统中添加DEBUG环境变量且赋值为1，并把日志显示级别调为DEBUG级，这个flag用于启动调试模式
LogLevel，对应-l和--log-level 参数。默认等级为info，即只输出普通的操作信息。用户可以指定的日志等级现在有panic、fatal、error、warn、info、DEBUG这几种
hosts,对应-h和--hosts=[]参数，对于client模式，就是指本次操作需要连接的docker daemom位置，而对于daemom模式，则提供所要监听的地址，若host变量或者系统环境变量DOCKER_HOST不为空，说明用户指定了host对象；否则使用默认设置，默认情况下Linux系统设置为unix：///var/run/docker.sock
protAddrParts，这个参数来自-H参数中：//前后的两部分的组合，即与docker daemom建立通信的协议方式与socke地址
2创建client实例
client的创建就是在已有配置参数信息的基础上，调用api/client/cli.go#NewDockerCli,需要设置好proto（传输协议）、addr（host的目标地址）和tlsConfig（安全传输层协议的配置），另外还会配置标准输入输出及错误输出
3执行具体的命令
Docker client 对象创建成功后，剩下的执行具体命令的过程就交给cli/cli.go来处理
从命令到映射的方法
cli主要通过反射机制，从用户输入的命令（如run）得到匹配的执行方法（CmdRun），这就是所谓“约定大于配置”的方法命名规范。
同时，cli会根据参数列表的长度判断是否用于多级docker命令支持,然后根据找到的执行方法，把剩下的参数传入并执行。若参数传入的方法不正确或者错误，则返回docker的帮助并退出
每一个类似api/client/commnds.go#CmdRun 的方法都剥离出来作为一个单独的文件存在。docker run 这个命令的执行过程，就需要寻找api/client/run.go这个文件
执行对应的方法，发起请求
1.解析传入的参数，并针对参数进行配置处理
2.获取与Docker daemon通信所需要的认证配置信息
3.根据命令业务类型，给Docker daemon发送POST、GET等请求
4.读取来自Docker daemon
daemom 模式
一旦进入daemom模式，剩下的初始化工作都由docker的docker/daemon.go#CmdDaemon来完成；docker daemon通过一个server模块（api/server/server.go）接收来自client的请求，然后根据请求的类型，交由具体方法执行，因此daemom首先要启动并初始化这个server，另一方面启动server后。docker 进程需要初始化一个daemon对象（daemon/daemon.go）来负责处理server的请求。
docker daemon 初始化启动过程
API server的配置和初始化过程
启动过程
（1）整理解析用户指定的各项参数
（2）创建PID文件
（3）加载所需的server辅助配置，包括日志、是否允许远程访问、版本以及TLS认证信等。
（4）根据上述server配置，加上之前解析出来的用户指定的server配置（比如Host），通过goro-utine的方式启动API server。这个server监听的socket位置就是Host的值
（5）创建一个负责处理业务的daemon对象（对应daemon/daemon.go）作为负责处理用户请求的逻辑实体
（6）对APIserver中的路由表进行初始化，即将用户的请求和对应的处理函数相对应起来。
（7）设置一个channel，保证上述goroutine只是在server出错的情况才会退出
（8）设置信号捕获，docker daemon进程收到INT、TERM、QUIT信号时，关闭API server，用shutdowndaemon停止这个daemon
（9）如果上面流程完成后，API server就会与daemon绑定，并接受client的连接。
（10）最后，docker daemon进程向宿主机的init守护进程发送“READY=1”信号，表示docker daemon已经开始工作
关闭过程
（1）创建并设置一个channel，使用select监听数据。在正确完成关闭daemon工作后将channel关闭，标识该工作的完成；否则在超时15秒后报错
（2）调用daemon/daemon.go#Shoutdown方法执行如下工作
遍历所有运行中的容器，先用SIGTERM软杀死容器进程，如果10秒不能完成，则使用SIGKILL强制杀死
如果netController被初始化过，调用#libnetwork/controler.go#GC 方法进行垃圾回收
结束运行中的镜像驱动程序
在docker1.6版本以前的早期和以前所有版本，server的启动和初始化使用了一种复杂的job机制（API server即被看作一种job），并且依赖于一个专门的docker Engine来管理和运行这些job。1.7版本，这个设计在整个社区的推动下呗重构，上述说的是新的server初始化过程，该server会通过与daemon对象绑定来接受并处理完成具体的请求（类似于一个API接受器绑定了一个业务逻辑处理器）
daemon对象的创建与初始化
对象创建过程至少包括功能有：docker容器配置信息、检测系统支持及用户权限、配置工作路径、加载并配置graphdriver、创建docker网络环境、创建并初始化镜像数据库、创建容器管理驱动、检测DNS配置和加载已有Docker容器等。
docker 容器配置信息
容器配置信息的主要功能有：提供用户自由配置的docker容器的可选功能，使得docker容器运行更贴近用户期待的运行场景；设置默认的网络最大传输单元：当用户没有对-mut参数进行指定是，将其设置为1500.否则，沿用用户指定参数值 ；检测网桥配置信息：此部分配置为进一步配置docker网络提供铺垫
检测系统支持及用户权限
初步处理完docker的配置信息后，docker自身运行的环境进行一系列检测，主要包括3个方面
* 操作系统类型对docker daemon的支持，目前docker daemon只能运行在Linux上
* 用户权限的级别，必须是root权限
* 内核版本与处理器支持，只支持amd64架构的处理，且内核版本必须升至3.10.0及以是上。
配置daemon工作路径
配置docker daemon的工作路径，主要是创建Docker daemon 运行中所在的工作目录，默认为/var/lib/docker.若该目录不存在，则会创建，并赋予0700权限
配置docker容器所需的文件环境
这一步docker daemon会在docker工作目录/var/lib/docker 下面初始化一些重要的目录文件，来构建docker容器工作所需的文件系统环境
这一，创建容器配置文件目录。docker daemon在出创建docker容器之后，需要将容器内的配置文件放到这个目录下统一管理。目录默认位置：/var/lib/docker/containers,它下面会为每个具体容器保存如下几个配置文件，其中xxx为容器ID
[root@mast ~]# ls /var/lib/docker/containers/4d5464672680c97ed061b73e7d8336741b2971c2fb5a81fa5ac2ec8fac096cf9/ 4d5464672680c97ed061b73e7d8336741b2971c2fb5a81fa5ac2ec8fac096cf9-json.log checkpoints config.v2.json hostconfig.json hostname hosts mounts resolv.conf resolv.conf.hash
第二，配置graphdriver目录。它用于完成docker容器镜像管理所需的底层存储驱动层，所以在这一步的配置工作就是加载并配置镜像存储驱动graphdriver，创建存在驱动镜像管理层文件系统所需的目录和环境，初始化镜像层元数据存储。创建graphdriver时，首先会从环境变量DOCKER_DRIVER中读用户指定的驱动，若为空，则开始遍历优先级数组选择一个graphdriver，在Linux环境下，优先级从高到低依次为aufs、btrfs、zfs、devicemapper、overlay和vfs。 不同操作系统下，优先级列表的内容和顺序都会不同，而且随着内核的发展以及驱动的完善，会继续发生变化。
需要注意，目前vfs在docker中时用来管理volume的，并不作为镜像存储使用。另外，由于目前在overlay文件系统上运行的docker容器不兼容SELinux，因此当config中配置信息需要启动SELinux并且driver的类型为overlay时，该过程就会报错
当识别出对应的driver后，docker执行这个driver对应的初始化方法（位于daemon/graphdriver/aufs/aufs,go）,这个初始化的主要工作包括：尝试加载内核aufs模块来确定docker主机支持aufs，发送statfs系统调用获取当前docker主目录（/var/lib/docker）的文件系统信息，确定aufs是否支持该文件系统；创建aufs驱动根目录（默认：/var/lib/docker/aufs）并将该目录配置为私有挂载，在根目录下创建mnt、diff和layers目录作aufs驱动的工作环境，工作完成后，graphdriver的配置工作就完成。
第三，配置镜像目录。主要工作是在docker主目录下创建一个image目录，来存储所有镜像和镜像层管理数据，默认目录“/var/lib/docker/image”.在image目录下，每一graphdriver都有一个具体的目录用于存储使用该graphdriver存储的镜像相关的元数据
根据上一步graphdriver的选择情况（以aufs为例）创建image/aufs/layerdb/目录作为镜像层元数据存储目录，并创建MetadataStore用来管理元数据。根据graphdriver与元数据存储结构创建layerStore，用来管理所有的镜像和容器层，将逻辑镜像层的操作映射到物理存储驱动层graphdriver的操作，创建用于registry的镜像上传下载的uploadManager和downloadMannger
创建image/aufs/imagedb/目录用于存储镜像的元数据，根据layerStore创建imageStore，用来管理镜像的元数据。
第四，调用volume/local/local.go#New创建volume驱动目录（默认为/var/lib/docker/volumes）,docker中volume是宿主机上挂载到docker容器内的特定目录。volume目录下有一个metadata.db 数据库文件用于存储volume相关的元数据，其余以volume ID 命名的文件夹用于存储具体的volume内容。默认的volume驱动是local，用户也可以通过插件的形式使用其他volume驱动来存储
第五，准备“可信镜像”所需的工作目录。docker工作根目录下创建trust目录。这个存储目录可以根据用户给出的可信URL加载授权文件，用来处理可信镜像的授权和验证过程。
第六，创建distributionMetadataStore和referenceStore。referenceStore用于存储镜像仓库列表。记录镜像仓库的持久化文件位于docker根目录下的image/[graphdriver]/repositories.json中，主要记录镜像ID与镜像仓库之间的映射。distributionMetadataStore存储与第二版镜像仓库registry有关的元数据，主要用于做镜像层的diff_id与registry中镜像层元数据之间的映射
第七，将持久化在Docker根目录中的镜像、镜像层以及镜像仓库等的元数据内容恢复到daemon的imageStore、layerStore和reference中
第八，执行镜像迁移，docker1.10版本以后，镜像管理部分使用了基于内容寻址存储。在第一次启动daemon时，为了将老版本的graph镜像管理迁移到新的镜像管理体系中，这里会根据docker根目录中是否存在graph文件夹，如果存在就会读取graph中的老版本镜像信息，计算校验和并将镜像数据写入到新版本的imageStore和layerStore中，注意的是，迁移镜像中计算校验和是一项非常占CPU的工作，并且在未完成镜像迁移时，docker daemon是不会响应任何请求的，所有如果你本地的老版本镜像和容器比较多时，或者是在对服务器负载和响应比较敏感的线上环境尝试，docker版本升级，那就要注意妥善安排时间，docker提供了迁移工具让用户在老版本daemon运行的时候进行镜像迁移
这里docker daemon需要在docker根目录（/var/lib/docker）下创建并初始化一系列容器文件系统密切相关的目录和文件。
创建docker network
创建docker daemon运行环境的时候，创建网络环境是极为重要的一部分。这不仅关系着容器对外通信，同样也关乎着容器之间的通信。网络部分早已被抽离出来作为一个单独的模块，称为libnetwork，libnetwork通过插件的形式为docker提供网络功能，使得用户可以根据自己需求实现自己的dirver来提供不同的网络功能。截止docker1.10版本，libnetwork实现了host、null、birdge和overlay的驱动。其中，birdge driver 为默认驱动，和之前版本中的docker网络功能是基本等价的，需要注意的是，同之前的docker网络一样，bridge driver并不提供跨主机通信的能力，overlay driver则是用于多主机环境
初始化execdriver
execdriver是docker中用来管理容器的驱动，docker会调用execdrivers中NewDriver()函数来创建新的execdriver
在创建execdriver的时候，需要注意一下5部分信息
运行时中指定使用的驱动类型，在默认配置文件中默认使用native，即其对应的容器运行时为libcontainer；
用户定义的execdirver选项，即-exec-opt参数值
用户定义的-exec-root参数值，docker execdriver运行的root路径，默认为/var/run/docker;
docker 运行时的root路径，默认为/var/lib//docker
系统功能的信息，包括容器的内存限制功能，交换分区内存限制功能、数据转发功能以及AppArel安全功能等；AppArel通过host主机是否存在/sys/kernel/security/apparmor来判断是否加入AppArel配置
最后，如果选择netive作为这个execdriver的驱动实现，上述driver的创建过程就会新建一个libcontainer，这个libcontainer会在后面创建和启动Linux容器时发挥作用
daemon对象诞生
docker daemon进程在经过以上诸多设置以及创建对象之后，最终创建出了daemon对象实例
| ID | 根据传入的证书生成的容器ID，若没有传入则自动使用ECDSA算法生成 |
| repository | 部署所有docker容器的路径 |
| containers | 用于存储具体的docker容器信息的对象 |
| execCommands | docker容器所执行的命令 |
| referenceStore | 存储docker镜像仓库名和镜像ID的映射 |
| distributionMetadataStore | v2版registry相关的元数据存储 |
| trustkey | 可信任证书 |
| IDInfo | 用于通过简短有效的字符串前缀定位唯一的镜像 |
| sysInfo | docker所在宿主机的系统信息 |
| configStore | docker所需配置信息 |
| execDriver | docker 容器执行驱动，默认native类型 |
| statsCollector | 收集容器网络以及cgroups的信息 |
| dafaultLogConfig |
提供日志的默认配置信息 |
| registryService | 镜像存储服务相关信息 |
| EvenetsServer | 事件服务相关信息 |
| volume |
volume所使用的驱动，默认为local |
| root | docker运行的工作根目录 |
| uidMaps | uid的对应图 |
| gidMaps | gid的对应图 |
| seccompEnabled | 是否使用seccompute |
| nameIndex | 记录建和其名字的对应关系 |
| linkIndex | 容器的link目录，记录容器的link关系 |
恢复已有的docker容器
当docker daemon启动时，会去查看在daemon.repository也就是在/var/lib/docker/containers中的内容。若有已经存在的docker容器，则将相应信息收集并进行维护，同时重启restart policy 为always的容器
docker daemon的启动看起来非常复杂，这是docker在演进的过程中不断增加功能点造成的，但不管今后docker的功能点增加多少，docker daemon进程的启动都将遵循3步
（1）首先创建一个API server，它工作在用户通过-H指定socket
（2）然后docker使用NewDaemon方法创建一个daemon对象来保存信息和处理业务逻辑
（3）最后将上述API server和daemon对象绑定起来，接受并处理client的请求
只不过，NewDaemon方法的长度会不断增加而已
从client到daemon
发起请求
（1）docker run命令开始运行，用户端的docker进入client模式
（2）经过初始化，新建出了一个client
（3）上述client通过反射机制找到了CmdRun方法
CmdRun在解析过程用户提供的容器参数等一系列操作后，最终发出了这样两个请求：
“POST”，“/containers/create?”+containerValues //创建容器
“POST” ，“/containers/”+createResponse.ID+"/start" //启动容器
至此，client 任务结束
创建容器
在这一步docker daemon并不需要创建一个真正的Linux容器，它只需要理解用户通过client提交的POST表单，然后使用这些参数在daemon中新建一个container对象出来即可，这个container实体就是container/container_unix.go，其中的commonContainer字段定义在平台为主。
启动容器
这个时候daemon这边的重点来了。API server接受到start请求后告诉docker daemon进行container启动容器操作，这个过程daemon/start.go
此时，由于container所需的各项参数，如NetworkSetings、ImageID等，都已经在容器过程中赋好了值，docker daemon会在start.go 中直接执行daemon.ContainerStart，就能够宿主机上创建对应的容器了；创建容器过程是docker daemon，containerMonitor将daemon设置为自己的supervisor。所以经过一系列调用后。daemon.ContainerStart 实际上执行的操作是
即告诉daemon进程，请使用container相关的信息作参数，执行对应的execdriver的Run方法
最后一步
“万事俱备，只欠东风”。在docker daemon已经完成所有的准备工作，最后下达了执行Run操作的命令后，跟系统打交道的任务都交给ExecDriver.Run来完成；execdriver是docker的重要组成部分，它封装了对namespace、cgroups等所有对OS资源操作的方法，而在docker中。execdriver的默认实现（native）就是libcontainer了，到这一步。docker daemon只需要提供三大参数，接下来等着返回结果
* commandv：该容器需要的所有配置信息集合
* pipes：用于将容器stdin、stdout、stderr重定向到daemon
* startCallback():回调方法