剑客
关注科技互联网

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

【编者的话】Docker的出现,为更简便、更细粒度地对云资源的调控提供了一个强有力的支撑,WeX5开发者云基于Rancher+Docker,在如何提高物理资源利用率的课题上做了一些探索和研究,总的来说可以规划为以下几点:

  1. 智能路由
  2. 自动启停
  3. 资源调控
  4. 动态应用部署
  5. 容器资源池

一般情况下,开发者从无到有开发一个可用于公网访问的HTML5的APP应用的流程是这样的:配置开发环境、开发应用、本地调试、租用公网服务器、注册域名、远程部署、远程调试,就算是一个很有经验的开发者,这整个过程还是需要花费不少时间,尤其是面对一个不断更新修改的应用。

于是我们就有了WeX5开发云,一个给WeX5开发者提供的从开发到部署测试一体化的云开发平台,实现WeX5之上的DevOps,让开发者更专注于应用开发,而不再关注应用的部署运维。

对于WeX5开发云来说,需求场景是这样的:开发者众多,用于测试演示的应用多,但是访问很少,资源利用率很低,同时又要求很高的响应速度,另一方面,WeX5开发云还提供在线Wex5设计IDE,这类IDE容器非常耗费资源,但是并发占用率不高。

这就要求我们的WeX5开发云在有限的成本支撑下能够尽可能地提高资源利用率,并且保障应用的可用性,经过一番努力,我们探索出以下几条途径:

  1. 智能路由
  2. 自动启停
  3. 资源调控
  4. 动态应用部署
  5. 容器资源池

首先我们来看下WeX5开发云的基础架构层次:

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

其中,IaaS层由阿里云支持,Monitor层采用Open-Falcon、Prometheus实现,Container Cluster采用Rancher+Docker实现,Controller Gateway由AutoStart、Regulator、IDE Pool、Proxy等组件组成。

一、智能路由

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

应对场景:统一的访问入口,环境与环境之间隔离,并且多个子网关之间要能够做到一定程度的负载均衡。

实现逻辑:创建应用的时候,会根据LoadBalancer集群的负载情况,选择一个负载较少的LoadBalancer作为该应用的路由网关,提供负载均衡及路由转发功能。控制网关接收到访问请求后,根据请求域名与LoadBalancer的映射关系,将请求转发到该LoadBalancer上。如上图所示,ENV_01与ENV_02的Docker网络是隔离的,在同一个环境中,请求域名与LoadBalancer的绑定可以动态调配。

二、自动启停

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

应对场景:目前WeX5开发云上的应用以开发者测试演示应用为主,这类应用的特点是数量多、访问少,甚至有很多应用创建后访问一两次,就再也没有访问,长此以往,这类应用会逐步占用大量的物理资源,如果按传统方法,直接将这些应用清除,又会影响开发者的下一次使用,这就要求我们寻找一个既能为开发者不可预期的访问提供支持,又能保证资源的的最大化利用的解决方案。

实现逻辑:应用创建后系统默认应用是停止状态,控制网关接收到第一次访问的时候,会调用Rancher API启动该应用,并且在redis中为该应用记录一个生存时间,在该时间范围内,认为该应用是健康运行的,再次接收到的请求立即转发并刷新生存时间。若一段时间没接收到访问请求,生存时间结束,触发事件调用Rancher API接口停止该应用,释放物理资源。

三、资源调控

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

应对场景:为了最大化地利用物理机的资源,WeX5开发云引入了自动启停技术,物理资源会处于超售状态,超售能够降低成本,最大化地利用物理机的资源,但同时也会带来资源争取的情况,甚至会因为节点上运行状态容器的资源消耗量超出系统负荷,导致节点宕机。

实现逻辑:Redis中记录应用最后一次访问的时间,Open-Falcon中监控各个Host主机的物理资源,当某项物理资源指标达到预设阀值的时候,触发事件调用Regulator API,计算该主机上最后一次访问时间最早的若干个应用,并调用Rancher API接口将其停止,释放资源。

四、动态应用部署

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

应对场景:开发测试过程中的应用往往需要频繁更新调整,对于有依赖关系的应用,频繁的中断服务会影响这些应用的可用性,即使是通过灰度滚动升级,也需要不断地调整链接参数。

实现逻辑:采用Rancher中的Sidekick机制,将整个的Wex5应用分为Wex5 app容器、Mysql容器与Deployer容器,当应用代码文件等有更新时,提交到Deployer并执行重启,即可完成整个Wex5应用的更新升级并且保证服务的不间断运行。

五、容器资源池

DockOne微信分享(八十七):基于Docker的开发云提高资源利用率的实践

应对场景:WeX5开发云上提供了Wex5应用在线设计,这个在线设计的应用也是跑在容器中的,但是由于设计器本身需要加载大量的资源文件,如果由开发者自行创建一个在线IDE的容器,从创建到正常运行大概需要30秒,时间等待较长,即使加入自动启停功能,第一次访问启动容器的时间也在15-20秒左右,用户体验太差,所以我们需要一个类似于资源池的功能,将IDE容器与开发者资源分离,其中的IDE容器长时间处于运行状态,开发者获取该资源的使用权限后,只需要加载开发者的资源文件,这样就可以大大优化用户体验。

实现逻辑:IDE资源池为了节省物理资源,同样加入了自动启停机制,将资源池分为POOL_ACTIVE与POOL_INACTIVE两块,开发者访问在线设计功能时,控制网关首先接收到请求,从POOL_ACTIVE资源池中获取一个运行状态的IDE容器,与开发者的访问域名绑定,并且在redis中为记录一个生存时间,在该时间范围内,该开发者具有此容器的使用权限,再次接收到的请求立即转发并刷新生存时间,同时,从POOL_INACTIVE中启动一个备用资源补充到POOL_ACTIVE资源池中。若开发者一段时间没有访问该IDE资源,生存时间结束,该资源释放到POOL_INACTIVE,并删除开发者上传的资源文件。

碰到比较坑的问题:

  1. Docker的存储驱动,早期我们使用的是Docker默认的Devicemapper(loop-lvm)的存储驱动,存在很大问题,尤其是数据盘的大小不是绝对固定的情况下,很容器导致Docker数据丢失,建议采用Devicemapper(direct-lvm)、OverlayFS、AUFS等作为Docker的存储驱动。
  2. Docker Daemon服务执行重启操作的过程中,会执行Docker容器的启动操作,假如有容器强依赖其他容器的话,这个启动过程就会出现问题,例如我们使用Convoy NFS服务作为外部卷存储的统一提供者,其他Docker容器需要挂载的Volume由Convoy NFS统一管理,这时候如果Convoy NFS容器没有启动的话,挂载了Volume的容器也无法启动,Docker Daemon的重启进程会不断尝试启动各个容器,直到把Convoy NFS容器启动起来,其他的容器才会慢慢正常启动,这个情况在容器量不大的情况下并不明显,但是如果主机上又几百个容器,这就会耗费很长时间,一度让我们怀疑系统是由于其他原因导致了宕机。Docker 1.12中Docker Daemon添加了一个 –live-restore 的参数,使得当Docker Daemon停止运行时,容器仍然可以保持运行以解决此类问题。

Q&A

Q:你好,你们有做不影响服务的升级和自动伸缩吗?

A:是的,上边提到的“动态应用部署”组件就是能够实现应用的升级更新不受影响,自动伸缩通过Rancher的监控和应用多实例来实现,监控到应用容易的CPU、内存、网络等如果在一个时间段内一直处于较高的利用率,就增加应用实例,反之则减少,保证应用的连续性。

Q:请问对Docker学习需要看Docker源码吗? 还是用Docker等工具来解决问题就可以了?

A:这个得根据实际需要来了,如果是说需要从Docker容器层面上来定制开发,那Docker源码肯定是需要去研究的,若仅仅是将Docker作为工具使用,那关注点可以放在相关的工具如Rancher、Mesos、Kubernetes等,当然了,若时间允许,了解源码好处多多,可以从底层弄清楚Docker的各种机制,有利无弊。

Q:感谢分享,请问在容器资源池部分提到的 “运行状态的IDE容器,与开发者的访问域名绑定” 假设有两个用户 用户A和用户B,他们访问的域名分别是什么?

A:这个是用户自定义的二级域名,假如基于顶级域名cloudx5.com,用户A创建一个IDE实例,这是他可以输入一个二级域名如a.cloudx5.com(或者我们自动生成一个),资源池组件就会将这个域名与获取的IDE容器绑定,用户A就可以访问了。

Q:想问下Docker部署应用,应用配置参数怎么处理?改一个参数就要重新打一包吗?

A:其实在我们这个结构中,用户并不需要关心打包及参数配置,他需要做的,就是把开发的代码上传,我们后端使用了Jenkins来做统一的打包,打包完成后会调用“动态应用部署”环节提到的Deployer容器,这个Deployer会去约定好的目录下载打包好的文件做部署配置。

Q:实例收缩的时候能保证释放的容器没有业务访问?

A:这个不需要保证,运行着的实例容器都是无状态的,实例之间的Session是共享的,需要持久化的数据也是存在别的容器中的如MySQL。

Q:LB路由WebApp的时候是按照IP寻址的吗?这样如何保证WebApp重启时候IP不变化?

A:LB路由的本质是一个带有服务发现功能的Haproxy,WebApp重启后IP变化了,LB会得知这个变化并修改配置和reload。

Q:就是说配置文件还是打到Docker里的,比如这时开发要改个配置或加一配置,而代码都没变,这时只能在打一个新的包?

A:关于这个我们做了一些约定,例如上边讲到的一个最基本的Wex5应用,我们将其分为Wex5 APP容器、MySQL容器与Deployer容器,APP应用容器访问MySQL容器都是通过Rancher的内部DNS解析MySQL容器在Rancher中的服务名称来访问,这个是相对固定的,例如在外卖APP应用中配置的MySQL的地址是:database.waimai,database是服务名称,waimai是Rancher的stack名称。

以上内容根据2016年10月20日晚微信群分享内容整理。分享人 史绍虎,起步科技WeX5云平台架构师,专注于云计算领域PaaS的技术亚久,早期基于OpenStack和CloudFoundry做私有云PaaS产品,现负责公司WeX5开发者云产品落地实现 。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址