踩坑小结！喜马拉雅 FM 测试环境的 Docker 化实践

随着容器技术的流行，作为线上应用 Docker 的铺垫，喜马拉雅 FM 从 2016 年开始推进测试环境的 Docker 化。本文重点介绍笔者在 Docker 化的过程中如何进行技术选型、环境搭建，和实践中碰到的一些问题及其解决方案。

为什么要Docker化?

1.标准化

• 配置标准化，以部署 Tomcat 为例，实际物理环境中，通常一台物理机部署多个 Tomcat，这就存在 Tomcat 的端口及目录管理问题。理想状态下：一个项目一个主机 Tomcat，Tomcat 永远位于/ usr / local / tomcat(或其他你喜欢的位置)下，对外端口是 8080，debug 端口是 8000。
• 部署标准化，现在云平台越来越流行，同时，也不会立即丢弃物理环境，因此必然存在着同时向云环境和物理环境部署的问题。这就需要一系列工具，能够屏蔽物理环境和云环境的差异，Docker 在其中扮演重要角色。

2.API 化

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

3.自动化

调度系统可以根据API进行一些策略性的反应，比如自动扩容缩容。

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

Docker 化的四个小目标

1.业务之间不互相干扰

• 一个项目/ war 一虚拟机/容器
• Ip-pert-task

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

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

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

总结一下，基于 n 台物理机搭建容器环境，整个工作的主线：

一个项目一个主机 ==>物理机资源不够 ==>虚拟化 ==>轻量级虚拟化 ==> Docker ==>针对 Docker 容器带来的网络、存储等问题 ==>集群编排 ==>对 CI / CD 的影响。

虚拟化网络的两种思路

Overlay

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

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

Underlay

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

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

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

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之外的编排工具

Docker 解决了单机的虚拟化，但当一个新部署任务到达，由集群中的哪一个 Docker 执行呢?因此，Docker 之外，需要一个编排工具，实现集群的资源管理和任务调度。

这些工具均采用 Master / Slave 架构，假设我们将物理机分为 Master 和 Slave，这些工具在 Slave 上运行一个 Agent(任务执行和数据上报)，在 Master 上运行一个 Manager(任务分发和数据汇总)。从功能上说，任务分发和容器资源汇总，这些工具可以满足要求。它们的根本区别就是：发展历程的不同。

• 从一个 Docker / 容器化调度工具， 扩展成一个分布式集群管理工具
• 从一个分布式资源管理工具，增加支持 Docker 的 Feature

到目前为止，根据喜马拉雅FM测试环境的实践，发现有以下特点：

• 对编排的需求很弱，基本都是单个微服务项目的部署。微服务项目的协同、服务发现等由公司的服务治理框架负责。
• 基础服务，比如 MySQL、Hadoop 等暂不上 Docker 环境。
• 需要查询编排工具的 API 接口，同时有一个良好的 Web 界面，对编排工具的数据汇总、资源管理能力有一定要求。

因此我们决定使用 Marathon + Mesos 方案。在后面实践的过程中，因为网络和编排工具的选择，IP 变化的问题带来很大的困扰，我们甚至专门开发了几个小工具，参见下文。

image 的组织

Docker 的厉害之处，不在于发明了一系列新技术，而在于整合了一系列老技术，广为人知的阿里、腾讯等大厂在 Cgroups、Namespace 等基础上搞了一套自己的容器工具。对于阿里，使用 Docker 初衷是 Docker 镜像化，也就是其带来的应用环境标准化，而不是容器化。

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

1.搭建私有 imagerepository

2.对 layer 进行组织

3.镜像的分发较慢

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

4.镜像化带来容器重启

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

• 只是更新一个文件，项目、容器均需要重启
• 因为加载缓存等原因，项目、容器启动比较耗时

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

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

因为只是在测试环境使用，镜像较慢的矛盾还不是太突出。这里有一个技术之外的问题。阿里对于 docker image feature 的改造，实现了如下优化：

• 可以减少容器的重启次数，进而减少 IP 的分配和释放。
• 影响到容器的编排策略，即 deploy 新的任务不再是选择一个机器运行容器，而是找到原来的容器应用变更。
• 对 Docker 的各种特性的认识，一则认为天经地义，二则逆来顺受。出现问题，要么想办法规避，要么在外围造个轮子去解决(还是规避)。

CI

Jenkins 如何跟 Marathon 结合，现成的方案很多。关键是提供几套不同的模板，方便不同业务的使用。

容器变化带来四大问题

使用 Docker 后，容器在物理机之间自由漂移，物理机的角色弱化成了：单纯的提供计算资源。但带来的问题是，影响了许多系统的正常运行。

1.IP 变化

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

• 新增组件屏蔽 IP 变化
• 提供 DNS 服务(有缓存和多实例问题)
• 不要改变 IP

既然重启后，IP 会改变，就减少容器重启

服务与 IP 绑定(这个方案非常不优雅)

对于 Web 服务，IP的变化导致要经常更改 Nginx 配置，为此，我们专门改写了一个 Nginx 插件来解决这个问题。

对于 RPC 服务，技术团队有独立开发的服务治理系统，实现服务注册和发现。但该系统有审核机制，对于跨语言调用，因为rpc客户端不通用，仍有很多不便。

2.文件存储

有许多项目会将业务数据存储在文件中，这就意味着项目 deploy 进而容器重启之后，要能找到并访问这些文件。在 Docker 环境下主要有以下两种方案：

• Dockervolumn + cluster fs
• Dockervolume plugin

我们当下主要采用第一种，将 cluster fs mount 到每台 Docker host 的特定目录(例如 / data)，打通 container / data ==> docker host / data == cluster fs / data，任意容器即可共享访问 /data 目录下的数据。

3.日志采集与查看

为了日志持久化存储，技术将容器的日志目录映射到了物理机上。but，一个项目的日志分散在多个物理机中。

原有的日志采集报警系统，负责日志采集、汇总、报警。因此容器化后，并不会有什么影响。但该系统只采集错误日志，导致开发人员要查看日志以调试程序时，比较麻烦。

最初，提供了一个 Web Console 来访问容器，操作步骤为：login ==> findcontainer ==> input console ==> op。

但依然过于繁琐，并且 Web Console 的性能也不理想。而直接为每个容器配置 ssh server，又会对 safe shutdown 等产生不良影响。因此：

• 登陆测试环境，90%是为了查看日志。
• 和开发约定项目的日志目录，并将其映射到物理机下。
• 间接配置 SSH。每个物理机启动一个固定 IP 的 SSHContainer，并映射日志目录。
• 使用 Go 语言实现了一个 essh 工具，essh-imarathon_app_name 即可访问对应的 SSH Container 实例并查看日志。

当然，日志的问题，也可以通过 elk 解决。

其他问题

1.Base image 的影响

• 时区、Tomcat PermGensize、编码等参数值的修正。
• base image 为了尽可能精简，使用了 alpine。它的一些文件缺失，导致一些Java代码无法执行。比如，当去掉 / etc / hosts 中 ip 和容器主机名的映射后，加上 /etc/sysconfig/network 的缺失，导致 Java 代码 InetAddress.getLocalHost()执行失败。

2.Safeshutdown，部分服务退出时要保存状态数据

3.支持 sshd，以方便大家查看日志文件

使用 supervisord(管理 SSH 和 Tomcat)，需要通过 supervisord 传导 。SIGTERM 信号给 Tomcat，以确保 Tomcat 可以 safeshutdown。该方法经常发生 supervisord 让 Tomcat 退出，但自己不退出的情况。

每台机器启动跟一个专门的容器，映射一些必要的 volume，以供大家查看日志等文件。

4.Marathon 多机房主备问题

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

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

7.如何更好的推广与应用的问题

todo

1.日志采集，简化日志搜索

2.一个集中式的 DC

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

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

这样带来的问题是：

对于运维人员来说，一些操作不能固化下来，比如回滚等，手工操作易出错。

对于用户来说，容易想当然的通过 portainer 进行增删改容器的操作，进而引起系统的不一致。

因为是现成系统，很难加入技术自己的逻辑，这使得配置上经常出现一些语义冲突的情况。

李乾坤

喜马拉雅 FM Java 开发工程师