当前位置: 首页 > >

大数据*台Docker应用之路

发布时间:

随着大数据*台型产品方向的深入应用实践和Docker开源社区的逐渐成熟,业界有不少的大数据研发团队开始拥抱Docker。简单来说,Docker会让Hadoop*台部署更加简单快捷、让研发和测试团队集成交付更加敏捷高效、让产线环境的运维更加有质量保障,而这背后的业务场景和具体的实践方法有哪些?在Docker容器服务逐步走向完善的过程中,大数据*台产品Docker模式的应用又是如何解决的?正是本文所着重阐述的。


实践中发现问题

场景一


在大数据*台型产品的开发过程中,经常要跟许多模块打交道,包括Hadoop、HBase、Hive、Spark、Sqoop、Solr、Zookeeper……等多达几十个开源组件,为了不影响团队成员间的工作任务协同,开发人员其实非常需要自己有一套独立的集群环境,以便反复测试自己负责的模块,可真实的企业开发环境往往只有一两个大的虚拟集群,这可怎么办?难道要给每个开发人员都配几台独立的物理机器?



场景二


针对每一次新版本的发布,产品测试组都需要反复的重装整个*台以便发现问题,而正如本文前面所阐述的那样,大数据*台所依赖的组件繁多,不同组件模块依赖的底层库也不尽相同,经常会出现各种依赖冲突问题,而一旦安装完成,就很难再让Linux系统恢复到一个非常干净的状态,通过Remove、UnInstall、rpm -e等手动方式卸载,往往需要花费很长的时间,那如何才能快速地恢复大数据*台集群的系统环境?



场景三


当测试人员在测试大数据*台过程中发现了一个Bug,需要保存现场,这里面包括相关的大数据组件配置、进程状态、运行日志、还有一些中间数据,可是,*台集群服务器节点数量很多,针对每个进程的配置目录和日志文件,都相对较独立,一般都需要专业的开发工程师或者运维工程师进入相关服务器节点,按照不同组件的个性化配置信息,手工方式收集所需的各个条目信息,然后打包汇集到日志中心服务器进行统一分析,而目前业界并没有一款能够自动分布式收集故障相关的日志系统,但测试工作还要继续,怎么办?



场景四


如何把一个部署好的大数据*台快速地迁移到其它地方?


你得注意以下几点:


1,如果是关键业务系统,数据不能丢;


2,如果是迁移物理机,机器可能会坏;


3,如果是不间断实时在线业务,要保证快速*稳切换。



传统解决方案的缺陷

想要解决这些问题,第一个想到的方案当然是用虚拟机,而笔者经历的团队,之前也确实用的就是虚拟机,但这种方式并不能完美的解决以上问题,比如:


1.虽然虚拟机也可以完成系统环境的迁移,但这并不是它所擅长的,不够灵活,很笨重。


2.虚拟机的快照可以保存当前的状态,但要恢复回去,就得把当前正在运行的虚拟机关闭,所以并不适合频繁保存当前状态的业务场景。


3.虽然可以给每个人都分配几个虚拟机用,但它是一个完整的系统,本身需要较多的资源,底层物理机的资源很快就被用完了,所以我们需要寻找其它方式来弥补这些不足。


Docker技术的引入

Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案,换句话说,它可以让我们把一台物理机虚拟成多台来使用,而且它还可以保存修改、完整迁移到其它地方、性能损耗小等等好处,能够很好解决我们之前遇到的问题。


那为什么不用虚拟机方案?


简单来说,因为它比虚拟机更轻便,启动一个Docker容器只要几秒种的时间,在一台物理机上可以创建几百上千个容器,而虚拟机做不到。


下面是虚拟机与Docker两种方案的实现原理:



VM设计图


虚拟机实现资源隔离的方法是利用独立的OS,并利用Hypervisor虚拟化CPU、内存、IO设备等实现的。例如,为了虚拟CPU,Hypervisor会为每个虚拟的CPU创建一个数据结构,模拟CPU的全部寄存器的值,在适当的时候跟踪并修改这些值。需要指出的是在大多数情况下,虚拟机软件代码是直接跑在硬件上的,而不需要Hypervisor介入。只有在一些权限高的请求下,Guest OS需要运行内核态修改CPU的寄存器数据,Hypervisor会介入,修改并维护虚拟的CPU状态。


Hypervisor虚拟化内存的方法是创建一个shadow page table。正常的情况下,一个page table可以用来实现从虚拟内存到物理内存的翻译。在虚拟化的情况下,由于所谓的物理内存仍然是虚拟的,因此shadow page table就要做到:虚拟内存->虚拟的物理内存->真正的物理内存。



Docker设计图


对比虚拟机实现资源和环境隔离的方案,docker就显得简练很多。docker Engine可以简单看成对Linux的NameSpace、Cgroup、镜像管理文件系统操作的封装。docker并没有和虚拟机一样利用一个完全独立的Guest OS实现环境隔离,它利用的是目前Linux内核本身支持的容器方式实现资源和环境隔离。简单的说,docker利用namespace实现系统环境的隔离;利用Cgroup实现资源限制;利用镜像实现根目录环境的隔离。


当新建一个容器时,docker不需要和虚拟机一样重新加载操作系统内核。我们知道,引导、加载操作系统内核是一个比较费时费资源的过程,当新建一个虚拟机时,虚拟机软件需要加载Guest OS,这个新建过程是分钟级别的。而docker由于直接利用宿主机的操作系统,则省略了这个过程,因此新建一个docker容器只需要几秒钟。另外,现代操作系统是复杂的系统,在一台物理机上新增加一个操作系统的资源开销是比较大的,因此,docker对比虚拟机在资源消耗上也占有比较大的优势。事实上,在一台物理机上我们可以很容易建立成百上千的容器,而只能建立几个虚拟机。


可见容器是在操作系统层面上实现虚拟化,直接复用本地主机的操作系统,而传统方式则是在硬件层面实现。当然,一些容器核心模块依赖于高版本内核,存在部分版本兼容问题。


如何基于Docker实现大数据*台的敏捷部署与运维?

第一步:搭建基础的Docker环境


在实践过程中,部署一套可用的大数据*台Docker环境,必需做好以下前提工作:


1.搭建私有镜像仓库,用来统一存放构建好的镜像文件


2.搭建一个安装包仓库,用来存放我们发布的各种版本的大数据组件安装包


3.配置多个物理机上的Dcoker容器可以相互通信,可参考官方给出的方案


第二步:为大数据*台定制基础镜像


1.既然要在Docker容器内安装我们的大数据*台,那就需要一个统一的Linux系统做为我们的Dcoker容器,像Ubuntu、CentOS等发行商都会发布自己的Docker基础镜像到Docker Hub上,如果Docker Hub上恰好没有你需要的镜像,也可以自己制作。


2.比如用CentOS6.8做为我们的基础镜像,那么请先把它pull下来



3.然后我们用这个镜像创建一个容器,并在里面配置一些我们大数据*台依赖的参数,比如ntpd、httpd服务等等,最终生成我们*台专属的基础镜像。



4.这是很关键的一步,有了它以后,所有人员可以随时创建一个自己需要的Linux环境出来,以便在其内进行产品的研究和实验,且每个人的环境互不相干,当容器内的环境被破坏后,可以删掉再创建,这样一来,场景一和场景二所遇到的问题也就迎刃而解。


第三步:将已经部署好的集群做成镜像


我们可以把已经部署了集群的容器保存成多种镜像,如:只包含了Hadoop的集群、同时包含Hadoop、Zookeeper、Hbase的集群,或安装了所有组件的集群等等,然后上传到私有仓库,其它人需要的时候,直接启动自已需要的集群就可以了,因为免去了部暑与配置等步骤,因而大幅度提高了工作效率,也提高了产品迭代速度。



上图是已经做好的镜像,图中共三种类型的镜像:


  • 第一个箭头指基础镜像
  • 第二个箭头指的是已经安装了大数据*台的镜像,因为是分布式,所以有五个
  • 第三个是单节点版的大数据集群,所以只有一个镜像
    第四步:镜像的修改与保存

    Docker提供了commit功能可以将一个正在运行的容器保存起来,假如在测试过程中遇到一个Bug并且需要先保存下来,执行一条简单的命令即可,如:


    # docker commit container_name image:v2


    在以后需要复现的时候用这个镜像创建容器即可,像下面这样


    # docker run -tid ?name c1 image:v2 bash


    但注意,并不是所有状态都能被保存下来,它只保存文件层面的状态,不能保存内存中的状态,所以再次启动容器的时候,容器内的所有服务都已经变成了停止状态,需要再手动启动一次,这样就导致有些类型的Bug不能复现。


    不过欣慰的是,Docker官方打算在后面的版本中加入checkpiont功能,它可以保存容器中的所有状态,这样就可以完整地复现Bug,这个新功能的用法就像下面这样:



    这个功能对很多人来说,绝对是个好消息!


    第五步:脚本化部署、监视、删除

    当然了,每个人都不应该把过多的精力放在怎么使用Docker的问题上,这样会为团队带来额外的工作量,最简单的办法当然是把所有重复性的工作脚本化,向每个人提供最简便的使用接口,只需要一条简单的命令就可以创建自己想要的集群环境,当不需要的时候一条命令即可删除,这样即降低了学*成本又解决了容器管理问题。


    根据笔者的实践经验,脚本化的实现应该着重考虑几个方面:


    • 1.多种类型集群的创建
    • 2.记录每个集群的所属者,容器所属的物理机,创建时间等等
    • 3.可实时查看所有容器的运行状态,物理机资源使用情况
    • 4.删除指定的集群
      结语

      现在已经有很多开源的Docker容器管理框架,但需求总是复杂多变的,并不能适用所有的场景。比如笔者所负责的大数据*台就需要为每个容器做端口映射、内含大数据组件的镜像在启动后还需做Hostname与IP映射等,总之,目前开源容器框架的易用性还有很大的改进空间,都存在一些手动配置的工作。


      关于容器服务,在具体的实践过程中,一定还会遇到很多问题,比如服务发现和编排。当下在应用层面虽还算不上特别的成熟,但已经使原本部署与配置很复杂的大数据*台变得简单快速,让一部分研发团队的产品迭代得到加速。当然,不管是大数据*台产品,还是Docker开源社区本身,都还在不断的完善中。


      本文由 联想大数据团队 投稿至36大数据,并经由36大数据编辑发布,转载必须获得原作者和36大数据许可,并标注来源36大数据http://www.36dsj.com/archives/75999,任何不经同意的转载均为侵权。


      End.



友情链接: