对于企业内部搭建Docker Registry来说，部署和运维尤为重要。今天为大家简单分享下惠普企业R&D团队在这两方面的项目实战和应用。
1 实战聊天运维ChatOps 什么是ChatOps ChatOps这个概念最初是由Github团队提出，简单来说，是基于对话驱动的开发方式。实际做法是：把你的工具带到您的沟通过程中，并使用一个聊天机器人编写定制化的脚本，使团队可以自动执行相应任务和协同工作，使运维工作更透明更高效。
因此，实施ChatOps需要两个重要组成部分：聊天室和机器人。聊天室也就是我们常说的团队协作平台，比较知名的有：
Flowdock，知名团队协作平台，目前我们在使用它。
Slack，国外著名的团队协作平台，界面美观。
HipChat，国外著名的团队协作平台，界面简洁。
Zulip，Dropbox旗下的group chat平台，已开源。
Teambition，国内知名的团队协作工具，具有文档管理功能。
这里是一篇比较Slack、Flowdock和HipChat的文章：http://www.slant.co/topics/1359/compare/~slack_vs_hipchat_vs_flowdock。
机器人选取了由Github团队开发的，当下最广泛使用Hubot。它是基于Node.js+CoffeeScript编写的，支持众多协作平台，如果没有你在用的，自己写adapter也很简单。除此之外，还有一些机器人：
lita，Ruby写的robot。
Errbot，Python写的robot。
团队中的任何一个人，只要在Flowdock这样的协作平台上，像聊天一样，输入相应指令，比如hubot show registry status，收到这条指令的Hubot就会根据后台定制的脚本，自动把相应信息通过一条聊天信息返回给你。
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的数量等。
目前hubot对于我们的Registry的运维还比较基础，将来我们希望通过增强hubot的运维能力（添加自动化脚本），来提高Registry的负载能力。例如通过hubot监测到Registry运行负载剧增，然后使用hubot实施auto scaling来保证Registry运行稳定。
Hubot可以作为连接和协同众多独立的微服务的一种桥梁，扩展的便利性尤为重要，而目前手动编写自定义的脚本不是特别方便。我们计划在企业内开发一套图形化扩展hubot的平台，集成企业内常用的各种服务，包括代码管理服务（SVN、Git）、通知服务（邮件、Flowdock）和部署服务（企业私有云）。对于特有应用的服务，可以提供自定义脚本扩展。
我们需要一个平台来管理生产环境中的容器，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根据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命令行工具，方便容器部署自动化，与其他流程进行整合。
发布新的image，可以用Rancher upgrade的功能，实现无缝更新。本质上Rancher启动新的service，然后切换link到新的service。如果需要回滚，则可以很方便的切换回之前的service。
Rancher对于主机和容器进行实时监控，通过用户界面可以查看cpu和memory的使用情况。
Service Health Check，是基于HAProxy开发的对于service状态的监控。
缺乏自主修复的功能。如果有些host无法和Rancher Server连接，Rancher无法重新调配container。
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的增强版吗，特别是可视化部分？
A：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的成本较大，目前还没有相关最佳实践。
@Container容器技术大会正在火热报名中，知名公司的Docker、Kubernetes、Mesos应用案例，点击下图可查看大会具体内容。
点击左下角阅读原文链接可进入大会官网
查看原文：http://www.zoues.com/2016/10/20/%e6%90%ad%e5%bb%ba%e4%bc%81%e4%b8%9a%e7%a7%81%e6%9c%89docker-registry%e5%ae%9e%e6%88%98%e5%88%86%e4%ba%ab/
253
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
