喜马拉雅FM测试环境Docker化实践

发表于:2017-6-13 13:20

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:李乾坤    来源:DockOne

  【编者的话】随着容器技术的流行,作为线上应用Docker的铺垫,喜马拉雅FM从16年开始推进测试环境Docker化。本次分享将重点为大家介绍我们在Docker化的过程中如何进行技术选型、环境搭建,特别是实践中碰到的一些问题及其解决方案。
  【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务,在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目,它还很年轻,官方文档中缺乏实现上全面、系统的介绍,本课程深入浅出地介绍了etcd的实现,并为运维和二次开发提供了系统的指导和建议。
  简介
  为什么要Docker化?
  1、标准化
  配置标准化,以部署Tomcat为例,实际物理环境中,通常一台物理机部署多个Tomcat,这就存在Tomcat的端口及目录管理问题。 理想状态下:一个项目一个主机Tomcat,Tomcat永远位于/usr/local/tomcat(或其它你喜欢的位置)下,对外端口是8080,debug端口是8000。
  部署标准化,现在云平台越来越流行,同时,也不会立即丢弃物理环境,因此必然存在着同时向云环境和物理环境部署的问题。这就需要一系列工具,能够屏蔽物理环境和云环境的差异,Docker在其中扮演重要角色。
  2、API化,通过API接口操作项目的部署(CPU、内存分配、机器分配、实例数管理等),而不是原来物理机环境的的手工命令行操作。
  3、自动化,调度系统可以根据API进行一些策略性的反应,比如自动扩容缩容。
  上述工作,原有的技术手段不是不可以做,可是太麻烦,可用性和扩展性都不够好。
  几个小目标
  1、业务之间不互相干扰
  · 一个项目/war一虚拟机/容器
  · Ip-pert-task
  2、容器之间、容器与物理机之间可以互通
  3、容器编排:健康检查、容器调度等
  4、使用方式:通过yaml/json来描述任务,通过API部署
 
  总结一下,基于n台物理机搭建容器环境,整个工作的主线:一个项目一个主机 ==> 物理机资源不够 ==> 虚拟化 ==> 轻量级虚拟化 ==> Docker ==> 针对Docker容器带来的网络、存储等问题 ==> 集群编排 ==> 对CI/CD的影响。
  网络
  虚拟化网络的两种思路:
  Overlay
  · 隧道,通常用到一个专门的解封包工具
  · 路由,每个物理机充作一个路由器,对外,将容器数据路由到目标机器上;对内,将收到的数据路由到目标容器中。
  通常需要额外的维护物理机以及物理机上容器IP(段)的映射关系。
  Underlay
  不准确的说,容器的网卡暴露在物理网络中,直接收发,通常由外部设备(交换机)负责网络的连通性。
  经过对比,我们采用了MacVLAN,主要是因为:
  · 简单
  · 效率高
  · 我们就是想将容器“当成”虚拟机用,容器之间互通就行,不需要支持复杂的网络伸缩、隔离、安全等策略。
  关于MacVLAN,这涉及到LAN ==> VLAN => MacVLAN的发展过程,请读者自行了解。网络部分参见《Docker 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之外,需要一个编排工具,实现集群的资源管理和任务调度。
  
  这些工具均采用Master/Slave架构,假设我们将物理机分为Master和Slave,这些工具在Slave上运行一个Agent(任务执行和数据上报),在Master上运行一个Manager(任务分发和数据汇总)。从功能上说,任务分发和容器资源汇总,这些工具基本都可以满足要求。就我的理解,其实这些工具的根本区别就是:发展历程的不同。
  1、从一个Docker/容器化调度工具, 扩展成一个分布式集群管理工具
  2、从一个分布式资源管理工具 ,增加支持Docker的Feature
  其中的不同,请大家自己体会一下。
  到目前为止,根据我们测试环境的实践,发现我司有以下特点:
  1、对编排的需求很弱,基本都是单个微服务项目的部署。微服务项目的协同、服务发现等由公司的服务治理框架负责。
  2、基础服务,比如MySQL、Hadoop等暂不上Docker环境
  3、需要查询编排工具的API接口,同时有一个良好的Web界面,对编排工具的数据汇总、资源管理能力有一定要求。
  因此,最终我们决定使用Marathon + Mesos 方案。当然,后面在实践的过程中,因为网络和编排工具的选择,ip变化的问题给我们带来很大的困扰,甚至专门开发了几个小工具,参见下文。
  image的组织
  Docker的厉害之处,不在于发明了一系列新技术,而在于整合了一系列老技术,比如AUFS、LXC等,在Docker之前,我司运维也经常使用Cgroups来限制一些c项目进程使用的资源。阿里、腾讯等大厂在Cgroups、Namespace等基础上搞一套自己的容器工具,现在也广为人知。甚至在《尽在双11:阿里巴巴技术演进与超越》关于Docker部分中提到,对于阿里,使用Docker初衷是Docker镜像化,也就是其带来的应用环境标准化,而不是容器化。
  Docker镜像的实践主要涉及到以下问题:
  1、搭建私有image repository
  2、对layer进行组织
  3、镜像的分发较慢
  预分发,但这不解决根本,只适用部分场景
  对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》,皇帝要大兴土木,严党要贪污,胡宗宪左支右绌,勉力维持。海瑞认为问题的根儿在皇帝,直接上了《治安疏》。两者都算不上什么错,胡宗宪在他的位置,重要的是保住总督的位置,这样才能打倭寇。作为一个名义上的严党分子,这样的话也不能他来说。我们在技术的选择上,也经常碰到这样的问题,各种妥协。但越早的认识到各种方案的缺陷,才会避免陷入为了方案而方案,做到预判,嗅到风向变化,随机应变。 ### CI
  本质上Jenkins如何跟Marathon结合的问题,现成的方案很多,本文不再赘述。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号