1、标准化

2、API化，通过API接口操作项目的部署（CPU、内存分配、机器分配、实例数管理等），而不是原来物理机环境的的手工命令行操作。

上述工作，原有的技术手段不是不可以做，可是太麻烦，可用性和扩展性都不够好。

2、容器之间、容器与物理机之间可以互通

3、容器编排：健康检查、容器调度等

4、使用方式：通过yaml/json来描述任务，通过API部署

Overlay

• 隧道，通常用到一个专门的解封包工具
• 路由，每个物理机充作一个路由器，对外，将容器数据路由到目标机器上；对内，将收到的数据路由到目标容器中。

通常需要额外的维护物理机以及物理机上容器IP（段）的映射关系。

Underlay

不准确的说，容器的网卡暴露在物理网络中，直接收发，通常由外部设备（交换机）负责网络的连通性。

经过对比，我们采用了MacVLAN，主要是因为：

1. 简单
2. 效率高
3. 我们就是想将容器“当成”虚拟机用，容器之间互通就行，不需要支持复杂的网络伸缩、隔离、安全等策略。

关于MacVLAN，这涉及到LAN ==> VLAN => MacVLAN的发展过程，请读者自行了解。网络部分参见《Docker MacVLAN实践》（http://qiankunli.github.io/2017/01/13/docker_macvlan.html）。

IP分配问题

对于物理机、KVM等虚拟机来说，其生命周期很长，IP一经分配便几乎不变，因此通常由人工通过命令或Web界面手动分配。而对于Docker容器来说，尤其是测试环境，容器的创建和销毁非常频繁，这就涉及到频繁的IP分配和释放。因此，IP分配必须是自动的，并且有一个IP资源池来管理IP。

在Docker网络中，CNM（Container Network Management）模块通过IPAM（IP address management）driver管理IP地址的分配。我们基于TalkingData/Shrike改写了自己的IPAM插件，fix了在多实例部署模式（一个Docker host部署一个IPAM，以防止单实例模式出现问题时，整个系统不可用的问题）下的重复存取问题。

Docker镜像的实践主要涉及到以下问题：

• 预分发，但这不解决根本，只适用部分场景
• 对layer进行压缩，京东目前采用该方案

4、镜像化带来的容器重启问题。因为镜像是一体的，哪怕只有一点更改，镜像的发布都必须销毁之前的容器，然后按照新镜像创建新容器。耗时是一方面，对以下场景也很不友好：

对于具体的场景，可以有具体的办法规避。对于通用的解决方案，阿里通过改写Docker，对镜像支持HotFix标识，deploy这类镜像，不再创建新容器，而是更新容器。

我们要对镜像的layer进行组织，以最大化的复用layer。

写到这里，我们可以看到一个技术之外的技术问题。阿里对于docker image feature的改造。

1. 可以减少容器的重启次数，进而减少IP的分配和释放。容器生命周期的延长，给用户的感觉是更像一个虚拟机。减少IP变化对其它组件的影响，一些组件不再必要。
2. 影响到容器的编排策略。即deploy新的任务不再是选择一个机器运行容器，而是找到原来的容器应用变更。这大概是阿里采用Docker Swarm编排工具并改造Docker Swarm的部分原因。毕竟Docker Swarm起点就是一个Docker编排工具，跟Docker更亲近，也更容易改造。
3. 我们在Docker化的过程中，对Docker的各种特性一则认为天经地义，二则逆来顺受。出现问题，要么想办法规避，要么在外围造个轮子去解决（还是规避）。这让我想到了最近在看的《大明王朝1566》，皇帝要大兴土木，严党要贪污，胡宗宪左支右绌，勉力维持。海瑞认为问题的根儿在皇帝，直接上了《治安疏》。两者都算不上什么错，胡宗宪在他的位置，重要的是保住总督的位置，这样才能打倭寇。作为一个名义上的严党分子，这样的话也不能他来说。我们在技术的选择上，也经常碰到这样的问题，各种妥协。但越早的认识到各种方案的缺陷，才会避免陷入为了方案而方案，做到预判，嗅到风向变化，随机应变。

关键是提供几套不同的模板，以方便不同业务的童鞋使用。

IP变化

许多系统的正常运行依赖IP，IP不稳定带来一系列的问题。而解决IP的变化问题主要有以下方案：

1、新增组件屏蔽IP变化

• 既然重启后，IP会改变，就减少容器重启
• 服务与IP绑定（这个方案非常不优雅）

对于Web服务，IP的变化导致要经常更改Nginx配置，为此，我们专门改写了一个Nginx插件来解决这个问题。参见一个大牛的工具weibocom/nginx-upsync-module（https://github.com/weibocom/nginx-upsync-module），我为大牛的工具新增了zk支持，参见qiankunli/nginx-upsync-module-zk（https://github.com/qiankunli/nginx-upsync-module-zk）。

对于RPC服务，我司有自己独立开发的服务治理系统，实现服务注册和发现。但该系统有审核机制，系统认为服务部署在新的机器上时（通过IP识别新机器）应先审核才能对外使用。我们和开发同学协调，在服务上线时，进行额外处理来屏蔽掉这个问题。遗憾的是，对于跨语言调用，因为rpc客户端不通用，仍有很多不便。

文件存储

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解决。

部署有状态服务

1、 Base image的影响

1. 时区、Tomcat PermGensize、编码等参数值的修正。
2. base image为了尽可能精简，使用了alpine。其一些文件的缺失，导致一些java代码无法执行。比如，当去掉/etc/hosts中ip和容器主机名的映射后，加上/etc/sysconfig/network的缺失，导致Java代码InetAddress.getLocalHost()执行失败。参见《Java InetAddress.getLocalHost() 在Linux里实现》（http://blog.csdn.net/raintungli/article/details/8191701）。

2、Safe shutdown，部分服务退出时要保存状态数据

3、支持sshd（已解决，但对解决其他问题是个有益的参考），以方便大家查看日志文件（Web Console对查看大量日志时，还是不太好用）

1. 使用supervisord（管理SSH和Tomcat），需要通过supervisord传导SIGTERM信号给Tomcat，以确保Tomcat可以safeshutdown。该方法比较low，经常发生supervisord让Tomcat退出，但自己不退出的情况。
2. 每台机器启动跟一个专门的容器，映射一些必要的volume，以供大家查看日志等文件。

4、Marathon多机房主备问题

5、容器的漂移对日志采集、分析系统的影响

6、对容器提供DNS服务，以使其可以正确解析外部服务的hostname

7、如何更好的推广与应用的问题（这是个大问题，包括分享PPT的写作思路、Jenkins模板的创建等，不比解决技术难题耗费的精力少）

2、一个集中式的DC。当下，项目部署的各个阶段分散在不同的组件中。呈现出来的使用方式，不是面向用户的。

• Jenkins负责代码的编译和Marathon job的触发
• Marathon负责任务调度、销毁和回滚等
• Portainer负责容器数据的界面化以及Web Console

这样带来的问题是：

1. 对于运维人员人说，一些操作不能固化下来，比如回滚等，手工操作易出错。
2. 对于用户来说，容易想当然的通过portainer进行增删改容器的操作，进而引起系统的不一致。
3. 因为是现成系统，很难加入我们自己的逻辑，这使得配置上经常出现一些语义冲突的情况。