五阿哥钢铁电商平台Docker容器云平台建设实践——你想知道的都在这里！

前言

五阿哥钢铁电商平台（www.wuage.com）是由钢铁行业第一的中国五矿与互联网第一的阿里巴巴联手打造，并充分运用双方股东优点资源，即：阿里巴巴在大数据、电商运营、互联网产品技术上的巨大优点，尤为是在B2B终端买家上的独有市场基础，以及中国五矿67年的行业经验，和遍及全球的200多个营销和物流网点，致力于为钢铁行业带来全新而持续的发展。Docker容器云平台是运维技术团队为内部服务整合、开发的一套容器管理平台，支持基础设施私有云和公有云对接，实现云上和云下实例使用一套平台进行管理，业务实例按需弹性扩容和缩容，规范化的项目管理流程、测试、上线流程，旨在将开发、测试人员从基础环境的配置与管理中解放出来，使其更聚焦于本身的业务开发。

本文主要结合在五阿哥业务场景状况，从如下三个部分讲解：

一、为何使用Docker技术 。

二、Docker容器云架构方案。

三、技术的选型和实践。

为何使用Docker技术

1.硬件资源利用率的问题，形成部分红本的浪费

在网站功能中不一样的业务场景有计算型的，有IO读写型的，有网络型，有内存型的，集中部署应用就会致使资源利用率不合理的问题。好比，一个机器上部署的服务都是内存密集型，那么CPU资源就都很容易浪费了。

2.单物理机多应用没法进行有效的隔离，致使应用对资源的抢占和相互影响

一个物理机器跑多个应用，没法进行所使用的CPU，内存，进程进行限制，若是一个应用出现对资源的抢占问题，就会引发连锁反应，最终致使网站部分功能不可用。

3.环境、版本管理复杂，上线部署流程缺少，增长问题排查的复杂度

因为内部开发流程的不规范，代码在测试或者上线过程当中，对一些配置项和系统参数进行随意的调整，在发布时进行增量发布，一旦出现问题，就会致使测试的代码和线上运行的代码是不一致的，增长了服务上线的风险，也增长了线上服务故障排查的难度。

4.环境不稳定，迁移成本高，增长上线风险

在开发过程当中存在多个项目并行开发和服务的依赖问题，因为环境和版本的复杂性很高，不能快速搭建和迁移一个环境，致使没法在测试环境中没法模拟出线上的流程进行测试，不少同窗在线上环境进行测试，这里有很高的潜在风险，同时致使开发效率下降。

5.传统虚拟机和物理机占用空间大，启动慢，管理复杂等问题

传统虚拟机和物理机在启动过程进行加载内核，执行内核和init进行，致使在启动过程占用很长时间，并且在管理过程当中会遇到各类各样的管理问题。

Docker容器云架构方案

基于Docker容器技术，运维技术团队开发了五阿哥网站的容器云平台。总体架构图以下：

基础设施

基础设施包含网络、服务器、存储等计算资源。

多云对接

私有云（VMware）和公有云（aliyun）进行统一托管，包含网络区域配置，VM实例开通及Docker的环境初始化配置等。

弹性调度

Docker容器云平台集群节点管理，Saltstack进行配置管理，镜像中心管理业务镜像，统一监控，统一日志管理，定时任务管理。

服务编排

服务注册，服务发现，容器节点在线的扩容和缩容，服务优雅上线，回滚降级，规范Java，Node，Python，iOS，Android等规范化的上线。

统一门户

规范化整个业务流程，简洁的用户流程，可动态管理整个云环境的全部资源。

技术选型及实践

镜像标准

众所周知，Docker的镜像是分层的。对镜像分层进行约定：
第一层是操做系统层，由CentOS/Alpine等基础镜像构成，安装一些通用的基础组件；
第二层是中间件层，根据不一样的应用程序，安装它们运行时须要使用到的各类中间件和依赖软件包，如，nginx、tomcat等；
第三层是应用层，这层仅包含已经打好包的各应用程序代码。

经验总结：如何让本身的镜像变的更小，PUSH的更快？

• dockerfile构建应用镜像，在中间件层遇到一些须要安装的软件包时，尽量的使用包管理工具（如yum）或以git clone方式下载源码包进行安装，目的是将软件包的copy和安装控制在同一层，软件部署成功后清除一些无用的rpm包或源码包，让基础镜像的尺寸更小。
• Java应用镜像中并无将jdk软件包打入镜像，将jdk部署在每台宿主上，在运行镜像时，经过挂载目录的方式将宿主机上的java家目录挂载至容器指定目录下。由于它会把基础镜像撑得很是大；
• 在构建应用镜像时，docker会对这两层进行缓存并直接使用，仅会从新建立代码出现变更的应用层，这样就提升了应用镜像的构建速度和构建成功后向镜像仓库推送的速度，从总体流程上提高了应用的部署效率。

编排工具

Rancher图形化管理界面，部署简单、方便， 能够与AD、LDAP、GITHUB集成，基于用户或用户组进行访问控制，快速将系统的编排工具升级至kubernetes或者swarm，同时有专业的技术团队进行支持，下降容器技术入门的难度。

基于以上优势咱们选择Rancher做为咱们容器云平台的编排工具，在对应用的容器实例进行统一的编排调度时，配合Docker-Compose组件，能够在同一时间对多台宿主机执行调度操做。同时，在服务访问出现峰值和低谷时，利用特有的rancher-compose.yml文件调用“SCALE”特性，对应用集群执行动态扩容和缩容，让应用按需求处理不一样的请求。
[https:/zhuanlan.zhihu.com/p/2...]()

网络模型

因为后端开发基于阿里的HSF框架，生产者和消费者之间须要网络可达，对网络要求比较高，须要以真实IP地址进行注册和拉取服务。因此在选择容器网络时，咱们使用了Host模式，在容器启动过程当中会执行脚本检查宿主机并分配给容器一个独立的端口，来避免冲突的问题。

持续集成

监测代码提交状态，对代码进行持续集成，在集成过程当中执行单元测试，代码Sonar和安全工具进行静态扫描，将结果通知给开发同窗同时部署集成环境，部署成功后触发自动化测试(自动化测试部分后续会更新https://zhuanlan.zhihu.com/id...）。

静态扫描结果：

持续部署

是一种能力，这种能力很是重要，把一个包快速部署在你想要的地方。平台采用分布式构建、部署，master管理多个slave节点，每一个slave节点分属不一样的环境。在master上安装并更新插件、建立job、管理各开发团队权限。slave用于执行job。

基于上述架构，咱们定义了持续部署规范的流程：

1. 开发同窗向gitlab提交代码；
2. 拉取项目代码和配置项文件，执行编译任务；
3. 拉取基础镜像，将编译好的应用包打入生成最新的应用镜像，推送到镜像仓库；
4. 根据当前应用及所属环境定制化生成docker-compose.yml文件，基于这个文件执行rancher-compose命令，将应用镜像部署到预发环境（发布生产前的测试环境，相关配置、服务依赖关系和生产环境一致）。
5. 预发环境测试经过后将应用镜像部署至线上环境，测试结果通知后端测试同窗。

监控管理

经过zabbix 自动注册（AutoRegistration），Grafana经过调用zabbix的API接口进行监控指标的统一展现。

日志管理

容器在运行时会在只读层之上建立读写层，全部对应用程序的写操做都在这层进行。当容器重启后，读写层中的数据（包含日志）也会一并被清除。虽然能够经过将容器中日志目录挂载到宿主机解决此类问题，但当容器在多个宿主机间频繁漂移时，每一个宿主机上都会有留存应用名的部分日志，增长了开发同窗查看、排查问题的难度。

综上所述，日志服务平台做为五阿哥网站日志仓库，将应用运行过程当中产生的日志统一存储，而且支持多种方式的查询操做。

经过在日志服务的管理界面配置日志采集路径，在容器中部署agent把应用日志统一投递到logstore中，再在logstore中配置全文索引和分词符，以便开发同窗可以经过关键字搜索、查询想要的日志内容。
经验总结：如何避免日志的重复采集问题？

• 日志服务agent须要在配置文件“ilogtail_config.json”中增长配置参数“check_point_filename”，指定checkpoint文件生成的绝对路径，而且将此路径挂载至宿主机目录下，确保容器在重启时不会丢失checkpoint文件，不会出现重复采集问题。

服务注册

etcd是一个具有高可用性和强一致性的键值存储仓库，它使用相似于文件系统的树形结构，数据所有以“/”开头。etcd的数据分为两种类型：key和directories，其中key下存储单独的字符串值，directories下则存放key的集合或者其余子目录。

在五阿哥环境中，每一个向etcd注册的应用服务，它们的根目录都以”/${APP_NAME}_${ENVIRONMENT}”命名。根目录下存储每一个应用实例的Key信息，它们都以“${IP}-${PORT}”的方式命名。
下图是使用上述约定，存储在etcd上某应用实例的数据结构：

能够看到我是使用get方法向etcd发送请求的，请求的是部署在预发环境（PRE）的搜索服务（search）；在它的根目录“/search_PRE”下，仅存储了一个应用实例的信息，这个实例的key是“172.18.100.31-86”；对应的value是“172.18.100.31:86‘’，整个注册过程是这样的：

①经过代码为容器应用程序生成随机端口，和宿主机正在使用的端口进行比对，确保端口没有冲突后写入程序配置文件；
②把经过python和etcd模块编写的服务注册工具集成在脚本中，将IP地址和上一步获取的随机端口以参数的方式传递给服务注册工具；
③待应用程序彻底启动后，由服务注册工具以约定好的数据结构将应用实例的写入etcd集群，完成服务注册工做；
④容器定时向etcd发送心跳，报告存活并刷新ttl时间；
⑤容器脚本捕获rancher发送至应用实例的singnal terminal信号，在接收到信号后向etcd发送delete请求删除实例的数据。
注：在ttl基础上增长主动清除功能，在服务正常释放时，能够马上清除etcd上注册信息，没必要等待ttl时间。

经验总结：容器在重启或者意外销毁时，让咱们一块儿看一下这个过程当中容器和注册中心都作了什么事情？

应用在注册是携带key 和value时携带了ttl超时属性，就是考虑到当服务集群中的实例宕机后，它在etcd中注册的信息也随之失效，若不予清除，失效的信息将会成为垃圾数据被一直保存，并且配置管理工具还会把它当作正常数据读取出来，写入web server的配置文件中。要保证存储在etcd中的数据始终有效，就须要让etcd主动释放无效的实例信息，来看一下注册中心刷新的机制，代码直接奉上：

服务发现

confd是一个轻量级的配置管理工具，支持etcd做为后端数据源，经过读取数据源数据，保证本地配置文件为最新；不只如此 ，它还能够在配置文件更新后，检查配置文件语法有效性，以从新加载应用程序使配置生效。这里须要说明的是，confd虽然支持rancher做为数据源，但考虑易用性和扩展性等缘由，最终咱们仍是选择了etcd。

和大多数部署方式同样，咱们把confd部署在web server所在的ECS上，便于confd在监测到数据变化后及时更新配置文件和重启程序。confd的相关配置文件和模板文件部署在默认路径/etc/confd下，目录结构以下：
/etc/confd/
├── conf.d
├── confd.toml
└── templates
confd.toml是confd的主配置文件，使用TOML格式编写，由于etcd是集群部署，有多个节点，将interval、nodes等选项写到了这个配置文件里。
cond.d目录存放web server的模板配置源文件，也使用TOML格式编写。该文件用于指定应用模板配置文件路径（src）、应用配置文件路径（dest）、数据源的key信息（keys）等。

templates目录存放web server下每一个应用的模板配置文件。它使用Go支持的text/template语言格式进行编写。在confd从etcd中读取到最新应用注册信息后，经过下面的语句写入模板配置文件中：
{{range getvs "/${APP_NAME}/*"}}

server {{.}};

{{end}}

经过supervisor管理confd进程。confd在运行后会每隔5秒对etcd进行轮询，当某个应用服务的K/V更新后，confd会读取该应用存储在etcd中的数据，写入到模板配置文件中，生成这个应用配置文件，最后由confd将配置文件写入到目标路径下，从新加载nginx程序使配置生效。（代码请参考：https://zhuanlan.zhihu.com/id...）

总结

以上是五阿哥运维技术团队针对Docker容器云平台建设实践，目前已经将权限开放给开发同窗，实现云上和云下实例使用一套平台进行管理，业务实例按需弹性扩容和缩容，规范化的项目管理和发布流程，实例和业务可按需进行扩容和缩容，实现7*24小时“一站式”的持续交付，开发同窗更聚焦于本身的业务开发，提升了公司的研发过程的效能。

接下来会不断优化和适配各类业务场景，逐渐完善容器云平台，同时会将容器云平台各类功能，总结的经验和教训不断分享给你们，给你们在工做中一些参考，避免走重复的“弯路”。

做者简介：刘晓明，五阿哥（www.wuage.com）公司运维技术负责人，拥有10年的互联网开发和运维经验。一直致力于运维工具的开发和运维专家服务的推动，赋能开发，提升效能。最后给本身代个盐~~欢迎你们有空时翻下我牌子(知乎号：布道 )，看看以前的文章，顺便关注下专栏“开发运维”。