关键是提供几套不同的模板，以方便不同业务的童鞋使用。
容器变化带来的问题
使用Docker后，容器在物理机之间自由漂移，物理机的角色弱化成了：单纯的提供计算资源。但带来的问题是，影响了许多系统的正常运行。
IP变化
许多系统的正常运行依赖IP，IP不稳定带来一系列的问题。而解决IP的变化问题主要有以下方案
1、新增组件屏蔽IP变化
2、提供DNS服务（有缓存和多实例问题）
3、不要改变IP
· 既然重启后，IP会改变，就减少容器重启
· 服务与IP绑定（这个方案非常不优雅）
对于Web服务，IP的变化导致要经常更改Nginx配置，为此，我们专门改写了一个Nginx插件来解决这个问题。参见一个大牛的工具weibocom/nginx-upsync-module，我为大牛的工具新增了zk支持，参见qiankunli/nginx-upsync-module-zk。
对于RPC服务，我司有自己独立开发的服务治理系统，实现服务注册和发现。但该系统有审核机制，系统认为服务部署在新的机器上时（通过IP识别新机器）应先审核才能对外使用。我们和开发同学协调，在服务上线时，进行额外处理来屏蔽掉这个问题。遗憾的是，对于跨语言调用，因为rpc客户端不通用，仍有很多不便。
文件存储
有许多项目会将业务数据存储在文件中，这就意味着项目deploy进而容器重启之后，要能找到并访问这些文件。在Docker环境下主要有以下两种方案：
1、Docker volumn + cluster fs
2、Docker volume plugin
我们当下主要采用第一种，将cluster fs mount到每台Docker host的特定目录（例如/data），打通container /data ==> docker host /data == cluster fs /data，任意容器即可共享访问/data目录下的数据。
日志采集与查看
为了将日志持久化存储，我们将容器的日志目录映射到了物理机上。but，一个项目的日志分散在多个物理机中。
我司原有日志采集报警系统，负责日志采集、汇总、报警。因此容器化后，日志的采集和报警并不会有什么影响。但该系统只采集错误日志，导致开发人员要查看日志以调试程序时，比较麻烦。最初，我们提供了一个Web Console来访问容器，操作步骤为：login ==> find container ==> input console ==> op。但很多童鞋依然认为过于繁琐，并且Web Console的性能也不理想。而直接为每个容器配置ssh server，又会对safe shutdown等产生不良影响。因此
1、登陆测试环境，90%是为了查看日志
2、和开发约定项目的日志目录，并将其映射到物理机下
3、间接配置ssh。每个物理机启动一个固定ip的ssh container，并映射日志目录
4、使用go语言实现了一个essh工具，essh -i marathon_app_name即可访问对应的ssh container实例并查看日志。
当然，日志的问题，也可以通过elk解决。
部署有状态服务
其它问题
Mesos + Marathon + Docker的文章很多，其实这才是本文的重点。
1、Base image的影响
时区、Tomcat PermGensize、编码等参数值的修正
base image为了尽可能精简，使用了alpine。其一些文件的缺失，导致一些java代码无法执行。比如，当去掉/etc/hosts中ip和容器主机名的映射后，加上/etc/sysconfig/network的缺失，导致Java代码InetAddress.getLocalHost()执行失败。参见《Java InetAddress.getLocalHost() 在linux里实现》
2、Safe shutdown，部分服务退出时要保存状态数据
3、支持sshd（已解决，但对解决其他问题是个有益的参考），以方便大家查看日志文件（Web Console对查看大量日志时，还是不太好用）
使用supervisord（管理SSH和Tomcat），需要通过supervisord传导SIGTERM信号给Tomcat，以确保Tomcat可以safeshutdown。该方法比较low，经常发生supervisord让Tomcat退出，但自己不退出的情况。
每台机器启动跟一个专门的容器，映射一些必要的volume，以供大家查看日志等文件
4、Marathon多机房主备问题
5、容器的漂移对日志采集、分析系统的影响
6、对容器提供DNS服务，以使其可以正确解析外部服务的hostname
7、如何更好的推广与应用的问题（这是个大问题，包括分享PPT的写作思路、Jenkins模板的创建等，不比解决技术难题耗费的精力少）
todo
1、日志采集，简化日志搜索
2、一个集中式的DC。当下，项目部署的各个阶段分散在不同的组件中。呈现出来的使用方式，不是面向用户的。
· Jenkins负责代码的编译和Marathon job的触发
· Marathon负责任务调度、销毁和回滚等
· Portainer负责容器数据的界面化以及Web Console
这样带来的问题是：
1、对于运维人员人说，一些操作不能固化下来，比如回滚等，手工操作易出错。
2、对于用户来说，容易想当然的通过portainer进行增删改容器的操作，进而引起系统的不一致。
3、因为是现成系统，很难加入我们自己的逻辑，这使得配置上经常出现一些语义冲突的情况。
Q&A
Q：镜像精炼影响很大吗？Docker相同层不是只下载一次吗？
A：我们绝大部分是Java项目，通常一个war包五六十M，更大的也有，占用一个layer。频繁的发布和部署，仅仅是下载这一个layer，时间上还是有一点耗时的。
Q：网络对于Kubernetes出来容易，进去很难。不知道你们说的物理机和Docker网络是怎么互通的？希望能详细说下。
A：首先通过docker ipam driver我们为每个容器分配一个IP，Docker本身也支持MacVLAN，不准确的说，相当于每个容器有一个物理网卡，只是和物理机网段不同。我们通过交换机连通两个网段。
Q：问一下，配置的统一管理是怎么做的？哪些配置信息做了统一管理，数据库的链接信息也是放到配置信息里吗？
A：可能我文中用配置一词不太对，文中的配置更多指的是，Tomcat的安装目录，Tomcat的Web端口、debug端口号，日志目录命名等约定。这个是做镜像时便已经确定的。
Q：容器有了固定IP那么就不需要NAT了，那么在原Mesos下的服务发现就不适用了，能详细介绍下这块怎么搞么？
A：从根本上，不管容器IP变不变，因为以后做扩容缩容，我们认为服务的IP总是会变得。因此我们写了Nginx插件等额外组件来屏蔽IP的变化，而不是尝试让IP不变。
Q：怎么收集Tomcat启动时的log？ 有没有想过用WebSocket？
A：我们公司有自己的日志采集系统，可以采集并分析业务日志。至于Tomcat日志，我们业务上暂时还不需要采集。我们有自己的手段来采集Tomcat运行状态。这里顺便说下，很多方案我们的选择，是基于公司目前已有的一些框架工具，大家要按照自己的情况因地制宜。
Q：将容器的应用端口映射到主机端口，能不能解决IP变化问题？
A：因为容器会在主机之间漂移，我们通过“物理机IP：物理机port”来访问容器时，容器对应的物理机IP在deploy后，还是会变得。
