Docker背后的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统，类似船舶使用的集装箱，野心勃勃的他们成功了。
Docker可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。Docker能处理的事情包括：
- 隔离应用依赖
- 创建应用镜像并进行复制
- 创建容易分发的即启即用的应用
- 允许实例简单、快速地扩展
- 测试应用并随后销毁它们
标准化应用发布，docker容器包含了运行环境和可执行程序，可以跨平台和主机使用；
节约时间，快速部署和启动，VM启动一般是分钟级，docker容器启动是秒级；
方便构建基于SOA架构或微服务架构的系统，通过服务编排，更好的松耦合；
节约成本，以前一个虚拟机至少需要几个G的磁盘空间，docker容器可以减少到MB级；
方便持续集成，通过与代码进行关联使持续集成非常方便；
可以作为集群系统的轻量主机或节点，在IaaS平台上，已经出现了CaaS，通过容器替代原来的主机。
目前大型互联网公司有腾讯、京东、美团、新浪、大众点评等都在使用。比如说腾讯的盖亚，基于docker部署管理，据说已经有万台规模，用于大数据处理。美团主要是用于持续集成，自动构建方面，另外新浪也做了实践。容器化是一个大趋势，以后这方面的公司会越来越多。
Docker提供功能广泛，这里有几个的例子：
Images（镜像）：Docker可以通过Pull和Push命令构建对象到服务中心
Containers（容器）：Docker可以通过Start/Stop命令管理容器的生命周期
Logging（日志）：Docker可以通过stdout，stderro捕获输出所有的容器内部信息
Volumes（存储）：Docker可以创建和管理容器的相关文件存储
Networking（网络）：Docker可以创建管理虚拟的接口和内部所有容器之间的网络桥接
RPC：Docker服务器提供允许外部程序去控制所有容器的行为的API
镜像管理
镜像是Docker管理最基础的部分，同时也是Docker最大的亮点。镜像管理涉及到镜像的制作、更新、存储、分发、权限等多个方面。
镜像制作方面，应该坚持三个原则，第一是坚持镜像总是从Dockerfile生成。这样做最大的好处是可以通过Dockerfile“阅读”镜像，在后续的协作、升级维护等方面会带来巨大的便利。第二是镜像之间应该避免依赖过深，建议为三层，这三层分别是基础的操作系统镜像、中间件镜像和应用镜像。第三是坚持所有镜像都应该有对应的Git仓库，以方便后续的更新。
镜像的更新需要一个自动化的流程，这可以通过SCM和CI系统自动触发实现。具体的流程如下图所示。开发者首先将代码和Dockerfile提交到Git仓库，然后Git通过webhook方式触发Jenkins的主动获取代码和Dockerfile文件，Jenkins再通过Docker相关的插件生成镜像并推送镜像到私有的Registry。这样，在服务器上就可以通过拉取新的镜像部署容器。
关于Registry，可能会涉及三方面的问题，一个是单点问题，对应的解决方案可以考虑DRBD、分布式存储以及云存储。二是Regitry的性能问题，目前可用的解决方案是通过HTTP反向代理缓存来加速Layer的下载。三是Registry用户权限，Nginx LUA可以提供一个简单快速的实现方案。
发布管理
和传统的发布流程相比，Docker最大的好处是不需要考虑外部依赖，利用容器的自包含的特点，我们可以将发布回滚流程标准化和产品化。而传统的发布和回滚，需要casebycase去针对不同应用做升级回滚的方案。要做到基于Docker的发布，镜像的生成必须坚持自动化，否则会发现升级比传统的方法更麻烦。因此在现实中我们也发现很多企业将代码目录放到主机目录映射到容器内，这样做破坏了Docker的自包含特性，解决的办法是坚持应用镜像更新自动化。
发布管理
和传统的发布流程相比，Docker最大的好处是不需要考虑外部依赖，利用容器的自包含的特点，我们可以将发布回滚流程标准化和产品化。而传统的发布和回滚，需要casebycase去针对不同应用做升级回滚的方案。要做到基于Docker的发布，镜像的生成必须坚持自动化，否则会发现升级比传统的方法更麻烦。因此在现实中我们也发现很多企业将代码目录放到主机目录映射到容器内，这样做破坏了Docker的自包含特性，解决的办法是坚持应用镜像更新自动化。
日志管理
由于容器是无状态的，所以存储在容器内的日志会随着容器的销毁而消失。stdout/stderr类型的日志，可通过logspout转发到syslog中心来收集。打印到文件的支持，比如accesslog，需要将日志存储到外部的Volume，并在Docker主机上使用logstash收集转发。
配置管理
容器里没有CM agent，无法接收CM指令。CM运行到Host上也无法管理容器中的文件，如果手工修改容器内的配置，那新创建的容器仍然是旧的。配置大体上分为两种类型，一种是服务之间的连接信息，这种配置建议考虑使用服务发现系统，也可以使用一些更加传统的方法，比如通过环境变量来协调作开发和生产环境的配置差异。一种是一般的配置文件参数，配置文件和Dockerfile应该一起存储到一个Git仓库，修改后自动build更新镜像。
网络管理
目前Docker支持的网络包括Host网络、NAT网络、物理网桥和网络虚拟化。Host网络中容器和主机共享网络命名空间，不同容器需要做好端口规划，防止端口冲突。Nat网络是基于四层代理以及NAT技术，依赖portmap，进出都需要转发，性能低，主机上需要做好端口规划，容易搞混。物理网桥方案，和传统虚拟机的网桥没有区别，适合容器数量有限且相对静止的场景。网络虚拟化是基于隧道的overlay网络，目前开源方案有SocketPlane、Weave、Flannel，适合数量大，动态创建销毁容器的场景。