本文讲的是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等。
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的，如：
Hubot
，
Lita
与
Errbit
；但是就像Smith在会上（
Kevin Smith - Modern Shrink-wrap Software
）支持指出的“ChatOps本质上不会比你开发的运维工具更出色，也不会比你现有的运维插件更好”。Cog的截图：
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做集成测试，就像最终用户运行产品一样”。
Smith还指出，在Cog的Api开发过程中他们这么使用Docker来提高开发、部署的效率：
- 安装：只是运行pull命令将镜像拉回本地
- 升级：对比Docker镜像的tag，然后pull镜像到本地，重新启动容器即可
- 配置：Docker的环境变量
- 卸载：杀死docker容器进程与镜像
- 运行：启动容器进程，因为可以向外暴露端口，所以你可以控制容器的行为。
Cog的研发团队这么操作Docker容器：
- 他们并不使用Docker的CLI（命令行），因为这样会带来性能降低，也不利于产品的长期发展。
- 因为Docker是开源的，我们读了源代码，然后通过Docker Daemon的Restful API自己实现了一个Docker client。
“我们通过这种方式保证产品的可靠性与稳定性，我们不需要用户对Docker的操作十分了解才能使用我们的产品” Smith说，他指出，通过这个方法，使得Cog的运行效率得到了提高：
- 200ms之内启动容器
- 容器运行过程中没有额外的进程开销
- 90ms内销毁容器
演讲的最后，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
