其实你可以这么想，把Docker理解成一个庞大的包装系统。它既不是那种硬梆梆的虚拟化，也不是单纯的程序打包，它提供了一整套让程序从开发到部署再到运行的完整机制。开发者只需要把应用和它需要的各种依赖打包成一个标准化的“箱子”，就能把这个箱子放进任何机器里运行，几乎瞬间就能启动。这整个系统背后有个Docker Engine，它是客户端-服务器这种C/S模型来运行的。核心组件里有个后台守护进程叫docker daemon，它24小时不睡觉，专门负责接收你在命令行输入的指令和发送过来的API请求，然后把这些操作真正落实到本地系统上去。除了这个守护进程，官方还提供了一个REST风格的HTTP接口，也就是REST API，开发者可以通过这个接口用程序去控制Docker，比如批量启动容器或者实时查看日志之类的操作。至于docker CLI，这就是个给人类用的命令行工具，是你输入可读指令的入口。当你敲下一条docker run的时候，其实是CLI把这些参数打包成了一个API请求发给了守护进程，再由守护进程去执行具体的操作。 现在来聊聊三个关键名词：镜像、容器和仓库。镜像是一个只读的模板，里面装着应用运行需要的全部软硬件环境，就好比是“源代码加上编译工具”。容器就是这个镜像的实例，一旦启动它就像是一台微型虚拟机，每一个容器之间都是相互隔离的，资源也会被限制住。仓库就是存放镜像的地方，既可以是本地的一个文件夹，也可以是远程的Registry服务。 给大家讲个具体的例子，咱们以部署Tomcat为例看看整个流程是怎么回事。你在客户端执行docker pull tomcat指令之后，指令先到守护进程那里。守护进程先查本地有没有缓存的Tomcat镜像，如果没有的话就会去远程Registry服务那里把它拉下来。等拉取完成之后，你再执行docker run命令让守护进程基于Tomcat镜像创建一个容器，并启动里面的Tomcat服务。整个应用运行起来之后，日志、端口映射还有卷挂载这些配置你都可以随时通过CLI或者API去动态调整。 这几样东西凑一块儿就成了一个完整的Web应用环境了。