Baozou Container

docker自2013年发布以来， 迅速成为最火热的容器技术之一。我们一直关注着它的发展，并且比较早的将其投入生产环境，目前来说已经发展成为暴漫技术体系重要部分。

首先介绍一下公司后端的技术组成：

1. 核心：ruby系的Web服务（rails）, 体现在暴走漫画、暴走日报的站点和Webservices。

2. 辅助：golang编写的独立服务或者服务中间件（推送服务、聊天室等）

3. 历史遗留下的python和php（暴漫旗下的其他站点和应用）

4. 少量scala用于数据分析和数据挖掘

对于docker的引入，最开始持谨慎态度，于是先从耦合度比较低的独立服务和服务中间件开始入手。

目前如下模块已经完全docker化：

— 代码托管，持续集成 ，镜像私服 （gitlab、 ci 、docker registry）

— 日志收集和数据服务 （elk ）

— 消息推送、网络爬虫等微服务

具体的应用，可以参考这篇博客： 暴走漫画的docker实践

确实docker给我们的开发和运维带来很多方便，但是随着时间的增长，越来越多的问题暴露出来。

一 . 缺乏统一调度中心,

1. 服务碎片化

技术部门分布在各个城市，不能完美保持沟通和协调，难免将业务部署到自认为合理的机器或者其群上，随着时间增长造成服务很分散。有时候会发现某台机器突然多出个服务，还要去花时间去查看确认，给维护和清理工作造成困难。

2. 五花八门的启动方式

目前来说并没有一个统一容器运行规范，造成不同服务有不同的启动方式 ：docker run,docker-compose 甚至python操作shell。这给运维造成非常大的麻烦，经常找不到docker run指令或者docker-compose的目录。

二. 资源分配不均匀

不知道现在集群还有多少资源，也不知道服务改部署到哪里去最合适，只能去凭借主观想法部署业务。

三、缺乏监控和应急措施

1. 缺乏健康状况监测

容器健康状态的监控应该由两部分组成，一个是监控容器的健康状态，即容器是running还是dead，另外一个是监控应用的健康状态，容器承载应用，容器的存活并不代表应用正常运行。只有容器＋应用正常了，服务才能正常。

2.缺乏报警体系

服务异常应该及时反馈（邮件/信息）。

3.缺乏应急措施

— restart=always ， 只能提供基本的故障重启，缺乏rollback等高级应急措施。

所以用docker跑服务只是个开始，真正的生产环境我们遇到了这么多问题，为了解决这些，我们引入容器编排系统。