原文链接：http://geek.csdn.net/news/detail/94850

本文是docker落地比较好的实践案例，文中很多地方多可以学习一下，以下是摘录：

为什么要容器化

对传统的垂直行业来讲，Docker也是最近几年才出来的技术，技术理念非常先进，因此采用Docker容器化技术对我们而言需要综合的评估，但是我们为什么要去做呢？首先，从行业现状来说，证券行业一方面量化交易、高频交易、实时风控要求高，其次，行业创新非常多，创新业务也很频繁，另外，监管方面，证监会证监局对我们要求交易事故零容忍，当然，最近几年互联网金融发展非常快，众筹、P2P非常多，再次，天量行情，2014年底到去年，最高一天有两万亿的市场行情，这样的话对我们整个交易系统是非常大的挑战。

我们在业务发展过程中一直团绕我们的就是怎样利用有限的资源去支撑业务创新，真正做到IT引领业务；另一方面，我们和其他大型的互联网公司在资源方面是没有办法比的，所以怎样利用有限的资源支撑业务创新，这些都是我们要考虑的事情。 
在使用容器化技术之前，我们遇到一些比较典型的痛点：

1. 以项目为单位部署系统：一个项目采购一批机器，分别各自部署，每个项目之间的机器相互孤立，做不到资源共享。追成极大资源浪费。

2. 传统的交易系统升级是非常困难的，例如，要升级要有一个后台数据表，因为表的数据量非常大，所以这个升级基本上是只能在周末升级，升级时间要1个或几个小时。

3. 还有交易系统要升级要打补丁，在系统里面升级一个补丁，把补丁放上去，补丁打的越多导致生产环境的系统的版本变得不可维护，不敢随便去做改动或重新部署。

4. 测试环境搭建非常耗时，快速部署非常困难。

5. 系统在大的升级完后基本是不可回退的。

6. 行业乌龙指等黑天鹅事件时有发生，根本的原因就是技术系统实时风控速度达不到业务的要求，冒险把比较耗时的风控去掉。

容器化技术很好的解决了我们上面所遇到的问题，因为采用容器化至少有以下几个方面的好处：

① 轻量的引擎，高效虚拟化 
② 秒级部署，轻松迁移和扩展 
③ 易于移植、弹性伸缩，简单管理 
④ 开始具备一点“云”的能力 
⑤ 让微服务成为可能 
⑥ 标准化的服务器端交付物 
⑦ 向DevOps迈进的重要一步

容器技术与云的落地

1. Docker绝对不是一个虚拟机，而且它也不是干这个事的，我们的理解是Docker其实就是一个进程的替代者。

2. 广义讲，云其实就是一个单机多进程的跨网络多进程的延伸，要实现云肯定要实现对资源对进程进行远程编排跟调度，我们认为这构成云的基础。

举一个简单的监控服务例子，一个基于statsd完备的监控服务需要有influxdb、grafana、statsd三个服务组成，每个服务只是一个单一的功能，单纯的一个服务是不能提供监控服务的，要把它提供成一个服务，肯定要组合起来，所以我们是通过compose文件把三个服务组成一个关系，这样就是一个完整的服务。

influxdb:p_w_picpath: "docker.gf.com.cn/gfcloud/influxdb:0.9"ports:- "8083:8083"- "8086:8086"expose:- "8090"- "8099"volumes:- "/var/monitor/influxdb:/data"environment:- "PRE_CREATE_DB=influxdb"- "ADMIN_USER=root"- "INFLUXDB_INIT_PWD=root"
grafana:p_w_picpath: "docker.gf.com.cn/gfcloud/grafana"ports:- "3000:3000"volumes:- "/var/monitor/grafana:/var/lib/grafana"
statsd:p_w_picpath: "docker.gf.com.cn/gfcloud/statsd"ports:- "8125:8125/udp"links:- "influxdb:influxdb"volumes:- "/var/monitor/statsd/log:/var/log"environment:- INFLUXDB_HOST=influxdb- INFLUXDB_PORT=8086- INFLUXDB=influxdb- INFLUXDB_USERNAME=root- INFLUXDB_PASSWORD=root

对于容器编排，可以从以下两个方面理解。

1. 容器编排是跨主机去管理多个集群Container的一种行为，随着Docker的发展，生态圈越来越完善，比较常见的Kubernetes、Mesos + Mathon、Rancher等都属于此类范畴。

2. 容量编排是为了将资源利用率最大化，同时均衡系统因容错需要不断变化的需求。

容器技术与云的最佳实践

不可变运维

因为有了容器技术，使得我们在管理变更，自动化部署方面有了可能，生产系统随着时间的推移，无论如何服务器都会积攒下许多变更，包括：新应用、升级、配置变更、计划任务，以及问题的修正。有一点是毫无疑问的：配置好的服务器运行时间越长久，它就越有可能处于未知状态。对于前面所述的每次变更，不可变运维将通过重新创建新的容器实例来解决确定服务器状态的问题。这样之前我们提到的升级打补丁的一系列痛点问题都得到很好的解决。

不可变，顾名思义就是一旦创建，便不再修改，以下是我们生产实践在使用Docker容器方面的一些原则：

①、容器一旦实例化后，永不改变 
②、服务的变更（升级，降级，修改配置）都通过重新部署实现 
③、不修改容器的内部

Docker最佳实践

①. 除了持久存储外，不用映射外部文件

特别是日志文件，不通过映射外部文件的方式，可以通过flume、kafka等接口把日志数据写入到集中地方。

②.不要使用本地网络

不使用”Host”模式，Host模式会污染宿主机，同时也不符合云计算

③.镜像使用标签，抛弃Latest

生产应用中一律使用Tag来标识应用，不使用Latest，因为使用Latest将无法实现回滚。

④.Build编译应用和Build Image分离

使用专用的编译Docker来编译应用本身，如用Maven、Go、C++的p_w_picpath来编译应用。编译后再把应用通过Dockerfile加到服务Image里面。

⑤.Apt-get安装Package用完即删

如下图的例子，Apt-get在一条命令里面写完，因为Docker是分层存储，如果是在另一个RUN命令里面卸载临时软件包，对Docker的Images的大小减小没有帮助。

⑥.Docker内部不要Daemon

服务在Docker内部不要有守护进程，应用挂掉就让它挂掉。通过外部监控来实现应用重启等操作。

FROM docker.gf.com.cn/gfcloud/ubuntu
RUN echo "deb http://nginx.org/packages/ubuntu/ trusty nginx" >> /etc/apt/sources.list && \
echo "deb-src http://nginx.org/packages/ubuntu/ trusty nginx" >>/etc/apt/sources.list
RUN apt-get update && apt-get install -y wget \&& wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key \&& apt-get update  && apt-get install -y nginx \&& rm -rf /var/lib/apt/lists/* \&& echo "\ndaemon off;" >> /etc/nginx/nginx.conf \ && apt-get purge -y --auto-remove wget
#  chown -R www-data:www-data /var/lib/nginx# Define mountable directories.
VOLUME ["/etc/nginx/sites-enabled", "/etc/nginx/certs", "/etc/nginx/conf.d", "/var/log/nginx", "/var/www/html"]# Define working directory.
WORKDIR /etc/nginx# Define default command.# Expose ports.
EXPOSE 80
EXPOSE 443
CMD ["nginx","-g","daemon off;"]