Operable公司如何使用Docker开发ChatOps工具Cog

  1. 云栖社区>
  2. DockOne.io>
  3. 博客>
  4. 正文

Operable公司如何使用Docker开发ChatOps工具Cog

猫饭先生 2017-10-11 15:24:00 浏览1130
展开阅读全文
本文讲的是Operable公司如何使用Docker开发ChatOps工具Cog【编者的话】这篇文章是对Operable公司CTO Kevin Smith在Monki Gras大会上做的演讲的总结,其中有关于ChatOps的介绍以及他对Docker的很多个人观点,值得学习。

【上海站|3天烧脑式微服务架构训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。
01.jpg

Operable是一家专注于运维工具开发的创业公司,Cog是他们开发的先进的ChatOps(可以理解为聊天工具与运维工具的结合)工具;他们改用Docker容器来开发部署Cog后,不仅获得了开发速度的提升,而且客户部署Cog也变得容易了。

在2017年RedMonk公司举办的Monki Gras大会上Operable的CTO与联合创始人Kevin Smith 阐述了他们开发Cog这个ChatOps的过程。

ChatOps是会话驱动(conversation-driven)开发的简称,它是融合了运维工具与聊天对话的功能,将聊天机器人(chatbot)、定制化的开发组件与定制化的脚本融合在一起的运维工具——它的设计初衷是为了更好的团队协作(特别是远程的团队合作)与自动化。

ChatOps正在成为解决远程团队合作问题的重要工具,不管你的团队成员使用什么工具,语言或者身在何处都能使用它来解决问题。以前,你可能需要额外的工具来监控系统中谁在什么时候动了什么“手脚”,而如今,如果使用chatbots,则一切尽在掌握了。此外,它还提供了很多自动化运维工具,帮助你做持续部署。

不管你跟你的团队是一起办公还是分布式办公,你们可能正在使用一些团队通信工具如slack;那么试想一下,在这些工具中只要使用一个ChatOps的代理通道,你就能跟踪团队成员的一举一动,如:跟踪bug,查看测试结果等等,这岂不是很酷。

“我想Docker的最大创新就是Docker镜像”——Kevin Smith,Operable公司CTO。
除了Cog,市面上还是有很多可供定制化的其他chatbots的,如:HubotLitaErrbit;但是就像Smith在会上( Kevin Smith - Modern Shrink-wrap Software)支持指出的“ChatOps本质上不会比你开发的运维工具更出色,也不会比你现有的运维插件更好”。Cog的截图:
02.png

Smith演讲中说的并不局限在产品介绍,而是其开发Cog过程中的切身体会。他指出,在一开始他们花了大量的时间去决定要支持什么样的基础设施(视频中的各种云平台AWS,Azure,OpenStack,MySQL,Postgre,Redis等等)、如何监控应用程序与如何实现自动化运维上,但是忽略了一个重要的因素——人。

Cog使用Unix shell风格的命令行操作;同时还是一个“开箱即用”(modern shrink wrap for software)的软件,这里的“开箱即用”指的是Cog使用Docker镜像来分发与安装,包括它的plug-in API。

为什么使用Docker?Smith说:“Docker最大的创新不是容器——虽然容器很棒,很有用,但是不是它的核心创新点,也不是使用Docker可以简化部署的核心原因。”,他称容器只是Docker创新的副产品。

“我觉得Docker的最大创新是Docker镜像,”Smith说,“可以称之为可执行的包(executable packages)。” 因为镜像有以下的特点:
  • 镜像自包含(Self-contained)
  • 镜像可以执行(Executable)
  • 镜像可以被嗅探与测试(Inspectable and testable)
  • 镜像可以跨平台(Cross-platform)

Operable在开发Cog的一开始就开始使用Docker,因为开发人员都很喜欢Docker,他们甚至使用Docker来分发源代码。Smith说:“为了使用Docker,我们改变了一切。”,而使用Docker镜像来分发产品的好处有:
  • 利用Docker可以对整个产品的运行环境有完全的控制,自从有这个特性,团队可以非常及时的发布版本
  • 符合应用程序12个基本开发原则(12-factor app methodology)的标准化配置方式;所有配置均通过环境变量实现
  • 能够很快的进行分布式部署,如借助Kubernetes或者Swarm实现
  • 简化运维支持与debug,产品使用Alpine Linux 镜像,整个包只有5MB,整个产品的镜像也只有22MB

在会上,Smith接下来讲述了Cog开发中的配置与设计原则:
  • 采用环境变量而不是配置文件来实现系统的配置
  • 合理的默认配置(Sane defaults)非常重要——你必须保证产品开箱即用而不是进行一堆配置后才能使用
  • 可配置的目录映射(Directory mounts),保证机器在意外重启后可以保持数据的完整性

“所有这些原则我们都是经过深思熟虑后的结果”,Smith补充道。

开发人员创新性的将源代码与应用程序打包在一个Docker镜像中(不同的layer上),这样我们就能非常直观的看到,代码的变化如何影响到应用程序的行为的了。“所以当我们发布新版本时,我们就有足够的信心保证它能跑!”Smith说。

使用基于容器技术的工具生态,开发团队可以将dogfooding(指开发者与客户都基于相同的技术基础,这里指都是使用Docker)发挥到极致,“我们在Docker中做一切的事情,就跟用户使用我们交付的产品一样,我们在Docker容器中做单元测试、功能测试、集成测试”,Smith说:“我们不在自己的电脑上运行任何本地代码,这样可以使我们像用户最终使用产品一样开发。我们使用Docker Compose做集成测试,就像最终用户运行产品一样”。
03.jpg

Smith还指出,在Cog的Api开发过程中他们这么使用Docker来提高开发、部署的效率:
  1. 安装:只是运行pull命令将镜像拉回本地
  2. 升级:对比Docker镜像的tag,然后pull镜像到本地,重新启动容器即可
  3. 配置:Docker的环境变量
  4. 卸载:杀死docker容器进程与镜像
  5. 运行:启动容器进程,因为可以向外暴露端口,所以你可以控制容器的行为。

Cog的研发团队这么操作Docker容器:
  • 他们并不使用Docker的CLI(命令行),因为这样会带来性能降低,也不利于产品的长期发展。
  • 因为Docker是开源的,我们读了源代码,然后通过Docker Daemon的Restful API自己实现了一个Docker client。

“我们通过这种方式保证产品的可靠性与稳定性,我们不需要用户对Docker的操作十分了解才能使用我们的产品” Smith说,他指出,通过这个方法,使得Cog的运行效率得到了提高:
  • 200ms之内启动容器
  • 容器运行过程中没有额外的进程开销
  • 90ms内销毁容器
    04.png

演讲的最后,Smith指出使用Docker构建Cog也褒贬不一,他总结如下:

使用Docker消极方面

他指出,使用Docker构建Cog平台在启动容器过程中的扩展性不是很好,当容器数量增多时,时间呈指数增长,所以在开发过程中不得不做尽量多的使用缓存来保证性能。“Docker还需要持续公开更多的容器IO API”,Smith说:“相对于其他开源系统,Docker的IO API公开有点少”。

使用Docker积极方面:

  • 因为很多用户都谙熟Docker,所以用户教育比较少,文档量也小了;
  • Docker将镜像格式组织得非常好。
  • Docker提供了安全的进程运行环境。
  • Docker Repository分发机制非常好。

最后,他说,尽管Docker不完美,但是对于搭建Cog平台来说足够了。

原文链接:How Operable Built its ChatOps Cog Platform on Docker Images(翻译:肖劲)

原文发布时间为:2017-03-27

本文作者:肖劲

本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:Operable公司如何使用Docker开发ChatOps工具Cog

网友评论

登录后评论
0/500
评论
猫饭先生
+ 关注
所属团队号: DockOne.io