DockOne技术分享(三十四):搭建企业私有Docker Registry实战分享


【编者的话】对于企业内部搭建Docker Registry来说,部署和运维尤为重要。今天为大家简单分享下惠普企业R&D团队在这两方面的项目实战和应用。

@Container容器技术大会将于2016年1月24日在北京举行,来自爱奇艺、微博、腾讯、去哪儿网、美团云、京东、蘑菇街、惠普、暴走漫画等知名公司的技术负责人将分享他们的容器应用案例。

实战聊天运维ChatOps

什么是ChatOps

ChatOps这个概念最初是由Github团队提出,简单来说,是基于对话驱动的开发方式。实际做法是:把你的工具带到您的沟通过程中,并使用一个聊天机器人编写定制化的脚本,使团队可以自动执行相应任务和协同工作,使运维工作更透明更高效。

因此,实施ChatOps需要两个重要组成部分:聊天室和机器人。聊天室也就是我们常说的团队协作平台,比较知名的有:
  • Flowdock,知名团队协作平台,目前我们在使用它。
  • Slack,国外著名的团队协作平台,界面美观。
  • HipChat,国外著名的团队协作平台,界面简洁。
  • Zulip,Dropbox旗下的group chat平台,已开源。
  • Teambition,国内知名的团队协作工具,具有文档管理功能。


这里是一篇比较Slack、Flowdock和HipChat的文章:
http://www.slant.co/topics/135 ... wdock

机器人选取了由Github团队开发的,当下最广泛使用Hubot。它是基于Node.js+CoffeeScript编写的,支持众多协作平台,如果没有你在用的,自己写adapter也很简单。除此之外,还有一些机器人:
  • lita,Ruby写的robot。
  • Errbot,Python写的robot。


团队中的任何一个人,只要在Flowdock这样的协作平台上,像聊天一样,输入相应指令,比如hubot show registry status,收到这条指令的Hubot就会根据后台定制的脚本,自动把相应信息通过一条聊天信息返回给你。

为什么要使用ChatOps

ChatOps的实施使运维工作更加透明,更加简洁。这样的好处很多:
  • 把过去团队成员在各自工具中输入命令的这个黑匣子过程前端化、透明化了。团队每个成员都能随时了解其他成员的一举一动,打造真正的无死角透明团队。
  • 非常有利于新人的培养。显然,能够直观看到团队的微观运作,对于刚入职的新手来说,比任何培训的效果都更好。


目前是如何利用ChatOps

我们公司目前内部署了私有Docker Registry,我们希望监控它的运行和使用情况,并且能够快速地对一些可预知的问题进行处理。通过Flowdock+Hubot(Hubot运行在Docker容器里)就能实现这点:
  • 通过Hubot监控Registry是否正常运行。主要使用了Sensu来做Registry的health check。一旦发现Registry没有正常运行,hubot就会发送一条信息到flowdock里,使用@team来通知团队。然后团队的成员可以使用hubot指令hubot fetch registry error cause,让hubot帮我们调查并返回出错的原因。根据出错原因,再使用hubot指令进行应急处理。
  • 通过Hubot定时发Registry运行情况到Flowdock Inbox里。通过Sensu作为服务监控,收集Registry本身一些运行数据,包括CPU,内存等,发送到Graphite,生成时序统计图,发布到flowdock上。
  • 通过Hubot实时获取Registry的使用情况。首先Registry进行了notification配置,Registry使用元信息会被发送到定制的收集服务(Notification analysis service)中去。通过分析这些使用元信息,获取不同Registry镜像的pull/push数量,由Notification analysis service提供相应的聚合搜索API。调用这些API,可以获取每小时、每天的Registry使用情况(json),将这些信息发送给相应的GraphOps平台,就能生成相应的图像,发布到flowdock上。我们目前比较常用的指令,就是hubot graph me registry usage since 24 hours,hubot立刻会返回最近24小时内Registry的使用情况,包括pull/push的数量等。


对于ChatOps未来计划

  • 目前hubot对于我们的Registry的运维还比较基础,将来我们希望通过增强hubot的运维能力(添加自动化脚本),来提高Registry的负载能力。例如通过hubot监测到Registry运行负载剧增,然后使用hubot实施auto scaling来保证Registry运行稳定。
  • hubot可以作为连接和协同众多独立的微服务的一种桥梁,扩展的便利性尤为重要,而目前手动编写自定义的脚本不是特别方便。我们计划在企业内开发一套图形化扩展hubot的平台,集成企业内常用的各种服务,包括代码管理服务(SVN、Git)、通知服务(邮件、Flowdock)和部署服务(企业私有云)。对于特有应用的服务,可以提供自定义脚本扩展。


使用Rancher实现Docker容器集群环境的部署和管理

为什么使用Rancher

我们需要一个平台来管理生产环境中的容器,Rancher是一个开源项目,使用起来非常简单,容易上手,一方面Rancher提供UI,可视化创建开关容器,另一方面,当时我们对docker-compose已有一定的了解,Rancher是支持标准化docker-compose.yml的。除此以外,Rancher实现了跨主机的overlay network。基于以上考虑,我们采用Rancher,基本上满足我们对于容器部署管理的需求。

准备环境

  • 安装Rancher的Server,其名为rancher/server的docker image,主要用于提供用户界面、追踪集群中容器状态、meta data和容器的调度、处理API请求等。
  • 给Rancher添加host,即在host上运行rancher/agent 这个docker image。Rancher的environment对应一个overlay network,把多个主机加入到一个environment中,Rancher根据资源和端口,自主调配容器在哪个主机上运行,每个容器将获得一个IP(10.42.0.0/16),容器之间是网络联通的。


Rancher进行部署

  • Rancher根据docker-compose.yml来部署容器,一个docker-compose.yml定义的container cluster,在Rancher里,被称为Stack。一个environment可以起多个Stack。对于docker compose中的link, Rancher有自己的Distributed DNS Service discovery的功能,根据link,生成service name对应IP的DNS record。Rancher也支持Docker volume, 并且提供其快照和备份的功能。我们通常还配有一个私有Registry,这样部署的时候Rancher可以从私有Registry去pull image.

  • 与docker-compse.yml一起工作的有rancher-compose.yml,在rancher-compose.yml中定义service scale,即一个service的container数量。例如
    db:
    scale: 2

  • Rancher内置的load balancer,我们用来做流量的路由。例如,在docker-compose.yml中,有如下定义
    lb:
    image: rancher/load-balancer-service
    labels:
    io.rancher.loadbalancer.target.service1: example.com:443/service1=3000
    io.rancher.loadbalancer.target.service2: example.com:80/service2=5000
    service1:
    ...
    service2:
    ...

    意思是我们定义了一个lb的service,是rancher/load-balancer-service的image,labels中的内容则配置lb的路由规则,即访问example.com:443/service1,流量会被分发到service1,而example.com:80/service2,流量被分发到service2。我们常常在一个envrionment中,指定一台host,专门用于运行lb。然后,云服务上配置DNS,使域名绑定到这个主机的IP。这样无论如何部署,总可以很顺利地通过域名来访问这些服务。

  • 容器编排scheduling的功能。Rancher允许用户给每个host定义label,比如我们常常给专门来运行load balance的主机定义一个label是for=lb,如果要lb这个service一定在此主机上运行,那么可以在docker-compose.yml中这样定义:
    lb:
    labels:
    io.rancher.scheduler.affinity:host_label: for=lb


Rancher有更多高级的scheduling规则编写的功能,包括否定,软指定等。
io.rancher.scheduler.affinity:host_label_ne: for=lb 指service一定不能在for=lb的host上运行。
io.rancher.scheduler.affinity:host_label_soft: for=lb 指service在条件允许的情况下尽量在for=lb的host上运行。

  • 可以从用户界面上部署容器,Rancher自动生成docker-compose.yml,并且提供Service之间相互link的拓扑图,如图
    RancherServiceLink.JPG

  • Rancher有rancher-compose命令行工具,方便容器部署自动化,与其他流程进行整合。


生产环境使用Rancher

  • 发布新的image,可以用Rancher upgrade的功能,实现无缝更新。本质上Rancher启动新的service,然后切换link到新的service。如果需要回滚,则可以很方便的切换回之前的service。
  • Rancher对于主机和容器进行实时监控,通过用户界面可以查看cpu和memory的使用情况。
  • Service Health Check,是基于HAProxy开发的对于service状态的监控。


目前发现的缺点

  • 缺乏自主修复的功能。如果有些host无法和Rancher Server连接,Rancher无法重新调配container。


团队

  • 惠普企业RnD部门,从事DevOps及Docker的研究和相关工具的研发,开源社区贡献者。
  • 成员:李文权、林箐、王春阳。


Q&A

Q:目前有没有尝到监控Register运行和使用情况的好处,或者在维护私有Register有没有遇到过什么问题?

A:能够实时监控Registry,就能观察用户的行为,当我们在负载量很大的时候,能够有效保持Registry稳定运行。维护私有的Registry的问题,就是要跟进官方的更新,看看是否也需要同步。
Q:Rancher实际上是基于Docker的开源PaaS,基于容器技术的开源PaaS很多,比如Deis、Flynn等,但是Rancher跟这些项目不同的地方是,它尽可能的和Docker生态圈工具兼容。请问当初为什么会选择Rancher,在你看来,Rancher最吸引你的地方是什么?

A:Rancher的UI比较方便于上手和使用。而且Rancher的概念也更接近Docker compose,目前官方的文档也比较齐全。
Q:Flowdock+Hubot这种方式下的监控是否必须用Sensu,是否支持采用zabbix作监控,Zabbix的远程脚本可以实现一些自动重启等等操作?

A:Sensu不是必须的,你可以使用你熟悉的监控服务,比如Zabbix。
Q:Flowdock+Hubot在一些安全性要求比较高的生产环境上是否可用,其发布的命令采用什么方式连接到容器\虚拟机或者主机上?要不要建立SSH免密码连接之类的操作?

A:Hubot是拉取Flowdock的信息,所以Hubot可以部署在公司防火墙内。目前Hubot使用docker remote API来控制虚拟机上的容器。
Q:请教一下,Rancher可以理解为Compose的增强版吗,特别是可视化部分?

Rancher自己有一套rancher-compose,提供load balance和auto scaling,可以算是Compose的增强版。可视化部分,是Rancher的一个Feature。
Q:Rancher的lb是用的HAProxy么?

A:是的。
Q:有没有做过横向比较,Kubernetes和Swarm+Compose,Rancher+Compose,在这几种选择间做过比较,或者说为什么最终选择了Rancher?

A:最初是选择Swarm+Compose,但是由于那个时候的Swarm不太稳定,有bug,集群管理工作不起来。Rancher部署方便,操作简单,所以就用了它。
Q:Rancher的网络具体是怎么做的呢?

A:据目前了解,是overlay模式。各主机之间采用IPsec Tunneling来实现通信,使用udp的500和4500端口。启动时在各个主机部署容器之前启动一个Network Agent管理容器网络。具体可以参看文档:docs.rancher.com
Q:rancher master如何实现的高可用?之前看了文档搭建之后,cpu等监控图无法显示了

A:通过rancher-compose提供load balance和auto scaling实现高可用。监控图无法显示也是我们遇到的问题,目前正在解决。
Q:从描述看Rancher的网络类似于weave吧,给每个容器分配固定IP,对集群规模比较大的或者IP地址段受限的似乎不太够用?

A:从我们目前的经验来看,的确有这样的限制,如果有大规模集群的需求下,需要重新评估Rancher来管理和部署。
Q: Hubot是不是也支持非容器方式的部署,比如部署在虚拟机上?

A:可以,可以参照https://hubot.github.com
Q:Hubot使用docker remote API是否采用了安全策略,另外Docker Registry采用了何种安全策略?

A:Remote API使用了TLS验证。目前我们的private registry使用了LDAP+token作为安全认证。
Q:在部署方面很重要的是动态伸缩和灰度发布,在这两方面你们是怎么考虑的?Rancher在这两个方面有支持吗?

A:通过rancher-compose提供load balance和auto scaling实现动态伸缩。其他方面,还没有考虑过。
Q:Rancher的管理数据是不是都放在了MySQL里面?MySQL需要搭建在物理机上吗?

A:MySQL是rancher server自己提供的,无需手工部署。
Q:Rancher能支持云存储吗?

A:最新版本的Rancher对Docker volume插件有了支持,可以通过它来实现Container的数据存储管理。
Q:请问你们实践或了解到的基于Rancher的集群规模有多大?

A:目前我们的使用规模比较小,还没有这方面的准确数据。
Q:从介绍看整个系统是搭建在OpenStack上的,采用Swift作为存储,那Docker的部署是不是采用的nova-docker呢?容器是部署在物理机上还是虚机上的,如果是虚拟机采用的是哪种hypervisor,性能方面如何,有没有做过相关的压测?

A:Docker是部署在KVM的虚拟机上,使用的企业私有云平台,目前没有做过性能测试。
Q:Rancher 实际应用中有哪些要特别注意的问题,麻烦分享下?

A:Rancher版本更新快,较低的版本会有很多bug。
Q:有考虑过升级问题么?比如Registry从v1升级到v2?或者docker 升级到1.9?

A:目前我们使用的就是v2,使用rancher upgrade来升级。 升级Docker的成本较大,目前还没有相关最佳实践。
Q: Rancher中文资料多嘛,有推荐嘛?

A:目前我们看的都是官方英文文档,这样能看到最新的信息,中文文档没有关注。
===========================================================
以上内容根据2015年11月24日晚微信群分享内容整理。分享人: 李文权,去年开始参与关于OpenStack的项目forj,这是一个持续集成和分发的开源平台。负责搭建公司内部使用的Docker Registry,跟Docker社区成员一起贡献了OpenStack Swift作为Registry V2的代码。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesx,进群参与,您有想听的话题可以给我们留言。

1 个评论

在结构图中,有几个问题想请教:
1、cache 容器采用的是什么方案(镜像)?
2、web 容器采用的是什么方案(镜像)?
3、db 容器采用的是什么方案(镜像)?

要回复文章请先登录注册