作为docker的重度使用者，我从普通开发者(系统，运维，后端服务方向)的角度介绍下自己遇到过的几种使用场景：

无痛尝试新事物

这应该是最早让我感受到docker的便利性的使用场景了。

以前，如果想尝试新的编程语言/数据库/命令行工具，会先找找apt的源里有没有相应的包，没有的话再看看是否有PPA源可以用，再没有就只能尝试从源码编译，编译成功前可能还要经历一遍安装编译工具链，依赖库等过程，而这个过程中遇到下代码被墙，依赖库版本太老/太新等麻烦也不少见。

现在，我会先上http://hub.docker.com搜索相关的docker 镜像，有的话按照文档直接跑个docker run的命令就好了。比如前两天为了跟一份scala的入门文档，需要先安装一套scala开发环境，可我的开发机上连jdk都没有，好在有人build了一个scala开发环境的镜像，我只需要一条命令docker run -it --rm williamyeh/scala就得到了一个scala的REPL。

使用docker打包/发布各种服务

这应该是docker最广为人知的使用场景了，目前我们team的几乎所有服务都是跑在容器里的，比如：salt-master.

salt-master是saltstack的中心控制节点，saltstack是用Python写的一套服务器集群管理工具，通过salt-master可以批量完成对所管辖机器的配置下发，信息收集，远程命令执行等任务。salt-master节点上除了需要安装salt的相关包以外，还需要安装完成各项任务用的salt formula,各服务的配置信息等。

我们有多个环境的集群需要管理，安全起见，每个集群各自部署一套salt-master。之前部署一套salt-master的流程是：找一台虚拟机，装上salt的相关package，git clone各个依赖的salt formula，手工填上各项包括各种服务密码在内的配置。需要更新配置或salt formula的时候，都是运维人员连上该节点手动修改文件或执行git pull等命令。

实际上，按照之前的办法，部署或更新一个salt-master节点是比较繁琐，容易出错的。后来我们换到了用docker部署，通过Dockerfile定义安装salt-master及其依赖包和配置项的过程，并将Dockerfile，配置等信息用git管理起来。任何人需要修改salt-master的时候只要修改这个git repo的内容就可以了，完成代码审阅后，会通过jenkins自动build一个新的镜像。更新线上salt-master的时候，运维人员只需要执行docker pull,docker rm -f, docker run三个命令即可。

使用docker image打包各种命令行工具

一般关于docker的介绍中，大多是将其描述为打通”开发-测试-发布”整个pipeline的神器，似乎docker最主要的用途是发布服务类软件。但实际上，即使是命令行工具，使用docker镜像发布也能带来很大的便利性。

比如之前我们的环境里边遇到了docker在使用devicemapper方面的一个bug，为了定位到问题所在，我试图用systemtap来跟踪docker daemon的一些系统调用和代码路径，但systemtap依赖项众多，在每一台出问题的服务器上都装一遍这些包显然是不现实的，更何况像kernel debug info这种包公司内部乃至国内的一些mirror上都没有，还需要从官方源下载。但好在我们的所有服务器都是标准化配置的，kernel，libc等基础组件版本都一样。我只需要制作一个sytemtap的镜像，就可以在任何一台服务器上用systemtap进行debug了。case解决后，清理办法也简单，删掉启动的相关容器及下载的镜像就好了。

现在，每开始一个新的项目，无论是服务类还是工具类，除了init一个git repo外，我的另一个习惯就是写一份Dockerfile和一份usage.sh脚本，这样，当我需要向我的伙伴介绍这个项目时，我只需要build一份镜像，推送到我们的private registry，然后发邮件告诉他们“请尝试用命令docker run --rm <image-name> usage查看使用简介”。

搭建开发环境

答主之前做openstack相关的开发(当然现在也会做一些)，有过openstack开发经验的同学应该清楚搭建一份openstack的开发环境对初学者而言还是挺难的，没记错的话，当初入职的时候光是搭建稳定的开发环境就花了我差不多三个星期的时间。

上半年我给我们的openstack版本中的每一项服务都做了一份docker镜像，搭配docker-compose和两个bash脚本，成功实现了十分钟内在两台裸虚拟机(ubuntu 14.04,不带docker-engine)上搭建一套完整的openstack开发环境(一个控制节点，一个计算节点)。

使用docker build完成单元测试

以前用jenkins做自动化测试的时候，经常担心项目间的环境依赖会互相冲突。但现在依托于docker的隔离性，这个问题不复存在。只要写一份Dockerfile，通过docker build的过程完成依赖安装，pep8检查，单元测试等步骤，build成功则表示测试通过，否则表示测试失败，开发者可以在测试过程中执行几乎所有命令。

实际上，已经出现了基于这个思路的持续交付平台，比如：https://github.com/drone/drone