DockOne技术分享（三十四）：搭建企业内私有Docker Registry实战分享

介绍

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

实战聊天运维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 。它是基于nodejs+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的拓扑图，如图
  
  
• 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有没有遇到过什么问题？

能够实时监控registry，就能观察用户的行为，当我们在负载量很大的时候，能够有效保持registry稳定运行。维护私有的registry的问题，就是要跟进官方的更新，看看是否也需要同步。

Q：Rancher实际上是基于Docker的开源PaaS，基于容器技术的开源PaaS很多，比如Deis、Flynn等，但是Rancher跟这些项目不同的地方是，它尽可能的和Docker生态圈工具兼容。请问当初为什么会选择Rancher？在你看来，Rancher最吸引你的地方是什么？

Rancher的UI比较方便于上手和使用。而且Rancher的概念也更接近Docker compose，目前官方的文档也比较齐全。

Q：flowdock+hubot这种方式下的监控是否必须用Sensu，是否支持采用zabbix作监控，zabbix的远程脚本可以实现一些自动重启等等操作?

Sensu不是必须的，你可以使用你熟悉的监控服务，比如zabbix

Q：flowdock+hubot在一些安全性要求比较高的生产环境上是否可用，其发布的命令采用什么方式连接到容器/虚拟机或者主机上？要不要建立SSH免密码连接之类的操作？

hubot是拉取flowdock的信息，所以hubot可以部署在公司防火墙内。目前hubot使用docker remote API来控制虚拟机上的容器。

Q：请教一下，Rancher可以理解为compose的增强版吗？特别是可视化部分

Rancher自己有一套rancher-compose，提供load balance和auto scaling, 可以算是compose的增强版。可视化部分，是rancher的一个feature。

Q：rancher的lb是用的haproxy么？

Q：有没有做过横向比较，k8s和swarm+compose,rancher+compose。在这几种选择间做过比较？或者说为什么最终选择了rancher？

最初是选择swarm+compose，但是由于那个时候的swarm不太稳定，有bug，集群管理工作不起来。rancher部署方便，操作简单，所以就用了它。

Q：rancher的网络具体是怎么做的呢？

据目前了解，是overlay模式。各主机之间采用IPsec Tunneling来实现通信，使用udp的500和4500端口。启动时在各个主机部署容器之前启动一个Network  Agent管理容器网络。具体可以参看文档：docs.rancher.com

Q：rancher master如何实现的高可用？之前看了文档搭建之后，cpu等监控图无法显示了

通过rancher-compose提供load balance和auto scaling实现高可用。监控图无法显示也是我们遇到的问题，目前正在解决。

Q：从描述看rancher的网络类似于weave吧，给每个容器分配固定IP，对集群规模比较大的或者IP地址段受限的似乎不太够用？

从我们目前的经验来看，的确有这样的限制，如果有大规模集群的需求下，需要重新评估Rancher来管理和部署。

Q： hubot是不是也支持非容器方式的部署，比如部署在虚拟机上？

可以，可以参照 https://hubot.github.com

Q：hubot使用docker remote API是否采用了安全策略？另外docker registry采用了何种安全策略？

remote API使用了TLS验证。目前我们的private registry使用了LDAP+token作为安全认证。

Q：在部署方面很重要的是动态伸缩和灰度发布，在这两方面你们是怎么考虑的？rancher在这两个方面有支持吗？

通过rancher-compose提供load balance和auto scaling实现动态伸缩。其他方面，还没有考虑过。

Q：rancher的管理数据是不是都放在了mysql里面？mysql需要搭建在物理机上吗？

mysql是rancher server自己提供的，无需手工部署。

Q：rancher能支持云存储吗？

最新版本的rancher对Docker volume插件有了支持，可以通过它来实现container的数据存储管理。

Q：请问你们实践或了解到的基于rancher的集群规模有多大？

目前我们的使用规模比较小，还没有这方面的准确数据。

Q：从介绍看整个系统是搭建在openstack上的，采用swift作为存储，那docker的部署是不是采用的nova-docker呢？容器是部署在物理机上还是虚机上的，如果是虚拟机采用的是哪种hypervisor, 性能方面如何，有没有做过相关的压测？

Docker是部署在kvm的虚拟机上，使用的企业私有云平台，目前没有做过性能测试。

Q：rancher 实际应用中有哪些要特别注意的问题，麻烦分享下？

rancher版本更新快，较低的版本会有很多bug。

Q：有考虑过升级问题么？比如registry从v1升级到v2？或者docker 升级到1.9？

目前我们使用的就是v2，使用rancher upgrade来升级。 升级Docker的成本较大，目前还没有相关最佳实践。

Q： rancher中文资料多嘛？有推荐嘛？

目前我们看的都是官方英文文档，这样能看到最新的信息，中文文档没有关注。