- 为什么选择AWS和Docker
- 为什么选择CoreOS部署我们的应用
- CoreOS在AWS平台上如何快速构建集群并且进行管理
- 应用过程中遇到的问题与解决方案
1、为什么选择AWS和Docker
首先我先介绍一下猎豹移动的一些业务，如图， 我们在海外有着庞大的用户群体，接近16E下载量，月活用户4.94E，71%来自海外，战略合作伙伴主要以阿里、百度、腾讯、小米……
这么大的海外用户量我们是这么做业务部署和服务的呢？
首先在选择服务商的方面我们选择了实力最强的亚马逊AWS作为我们的云服务商，我们海外几乎所有的服务都是架构在AWS的平台上面。
这给我们带来了什么好处呢，总结起来有3点：
- 便捷的全球化部署
因为我们的用户遍布全球，所以便捷的全球化部署是我们非常看重的，我们使用了AWS全球9个地区的region，其中包括美国3个，欧洲1个，亚太地区3个，南美洲1个，遍布全球 。 - 弹性的扩展
对于云服务，弹性的扩展是最为便捷的，可以在几分钟（而不是几小时或几天）内增加或减少服务器。可以同时管理一个、数百个，甚至数千个服务器实例。当然，因为这全是通过Web服务或API控制。 - 成本的优化
而且无需前期的投资，持续的成本优惠与调整；提高了资源利用率，按需付费；无需出国，管理世界各地的服务器，节约人力成本。
介绍完我们基础平台的选择后，为了更好的自动化，集群化，我们开始接触容器技术，而且是如何在AWS平台上实现容器化。
我们把容器的概念进行理解：给你的应用程序“打包”，能够执行一个“进程”，同时能把你执行的内容和其他“进程隔离”开来的东西，容器化有什么好处呢？
这些好处在所有网站上看到的东西，听完这个介绍，感觉有点空洞，还是不知道是什么，我们用到的一些package，我再所有的系统里面都可以运行这些进程，而且进程隔离开，为什么还要Docker，这也是我们团队刚刚接触时遇到的困惑，除了Linux系统，最早提出容器化的VMware、Microsoft都有这方面的尝试，只不过他们的容器是虚拟机，而互联网的发展需要一个轻量级的容器。
这个图是借鉴了Yahoo的架构，非常的可爱形象，比普通的架构图更加生动，我们猎豹有很多广告业务，商业的开发同学做的ADserver，也会有很多流式数据实时处理的系统，通过data highway汇聚到大数据处理系统，Hadoop、Spark计算，后端储存我们用的是aws-s3。如果要完成这套系统，基础架构，需要多少人力物力呢？可想而知，单单运维方面上百人的团队就这样建立起来了。
以往，我们一批机器只做一件事，比如100个adserver只做广告接口，另外100台机器只做广告检索，再有100台机器做数据传输处理，某个模块出问题去扩容或者处理某个模块，这是大家最常见的方法。这对架构的高可用设计是个很大学问，需要多机房冗余，多地部署等等。如果引入微服务的概念呢？
如左边图，一台机器上面只运行各自的模块和依赖，不同机器各司其职，出问题处理问题模块。而右边微服务的设计，我无所谓我的程序如何分布，每台host都可以部署多个模块混合复用，自定义哪些模块可以和哪些分配到同一台host，哪些模块不能和哪些模块分配到同一台host，一旦某个模块挂掉，调度编排工具可以帮助马上启动一个新的docker替代工作。扩容的时候不需要针对不通模块去部署和发布，只需要调整一下各个docker的数量即可。
2、为什么选择CoreOS部署我们的应用
下面我介绍一下我们线上稳定运行很久的一个RCV日志处理集群的容器化改造过程，下图是我们开始的架构图：
开始我们的架构很简单，前端接收，经过各个模块处理后存储，然后统一进行处理分析，报表延迟很长，而且经常出问题需要手动补数据。
后来我们对架构进行了容器话的改造，而且引入了数据流式处理，每个region部署一个收集集群，frontend的数据可以buffer一周的时间，并且可以故障后续传，通过Kafka汇总到我们的*region的nrt系统进行准实时的数据汇总和分析，报表延迟可以控制到5分钟以内，而且每个region的集群都可以像管理一台机器一样管理。
这套系统我们团队为他命名为Meissa，是猎户座最亮的一颗星，他底层搭建在CoreOS上，用CoreOS只带的etcd和Fleet进行集群的服务发现和编排管理，程序使用Docker进行打包，利用Jenkins进行发布，images保存在自建的docker-registry里面供集群使用。
3、CoreOS在AWS平台上如何快速构建集群，并且进行管理
在AWS上面开通一套CoreOS 的集群非常方便，只需要在AWS的镜像仓库里面 选择合适的CoreOS版本，编写好user-data（Linux的cloud-init）传入正确的cloud-config即可，这个可以参考CoreOS的官网。这里说一下etcd token的使用，etcd的功能和ZooKeeper很相似，可以在私网自己通过IP定义leader的节点和数量，也可以通过官网进行token注册，比较方便。这里举个例子：
一个集群都用这个配置文件（可以根据不同用途修改metadata的名字），开机后会自动发现集群并且注册到一起，如下图：
这个是集群列表，标注每个host的名字方便调度
这个是units列表，看这个@符号，后面有1234，4台机器上运行，之前服务端的同学写个while true 脚本或者使用supervisor去判断程序是否启动，挂了拉起来，而且不可以跨服务器去守护进程，fleet可以帮你在符合条件的units任意一台上面启动这个服务，可以跨服务器。
etcd的discovery key已经把各个leader节点信息记录到token的url里面，同步到各个节点，去个各个节点做服务注册和发现。
使用fleetctl可以随需求安排程序的启动，fleet相当于集群版systemd。
4、应用过程中遇到的问题与解决方案
fleet 配置文件编写的一些技巧，如何合理编排自己的服务 。
CMD ENTRYPOINT不建议使用，add和cp都一样，ENTRYPOINT可以传参数，还是写到run里面ENTRYPOINT后面写命令，“一个参数 空格 一个参数”，这样写的话转义就出问题了，这是Docker的问题，用数组的方式[bash,-c]；关闭进程用stop，不要直接kill进程，因为如果你写了个shell脚本启动你的程序，那么这个进程的pid=1为bash，kill掉的是bash，而不是你的容器程序， 或者使用exec，这样会把子进程替换父进程；docker的stop会有一个tw时间，默认应该是60s，如果你的程序关闭比较慢，比如kafka需要落磁盘，60秒不够怎么办，可以手动传入比较长的timeout时间；Docker默认的ulimit是1024，有时候发现你的Docker总是莫名重启，可以看看是不是ulimit用尽了。
Q&A
Q：没有用到Flannel，网络实现是什么，未来对CoreOS的容器管理工具rkt的计划？A：网络上我们直接使用的host的方式，容器主要是看中了CI和CD的便利好没有往高密度的场景设计的计划，rkt是个好东西，更有开源的感觉，看后期Docker社区发展情况是否越来越封闭。Q：registry怎么ha的，是在容器还是VM？
A：这个问题之前也是一直困扰着我们，我们用AWS的ELB做负载均衡，后端放2台EC2，镜像存到S3，缓存写在Redis里，我们是使用官方的image，随时用随时上传和使用，挂了就再启动一个，不依赖长期有效的hub。Q：最近暴漏的安全问题需要内核升级才能解决，这正是CoreOS的优势、不必重启系统，猎豹是否在线上有这种经验？实际中CoreOS在升级内核时是否真那么方便？
A：这个是我们非常喜欢的一个特性，自动升级内核，做过运维的同学都知道，做一次内核升级是多么痛苦，我们最开始用的是stable766.4，现在都不用我们去升级就自动帮我们升级到8xx的stable版本了。Q：集群中etcd节点数目是多少，奇数个etcd节点的优势具体怎么体现的，以及etcd的代理节点在业务中的价值？
A：etcd很类似于ZooKeeper，leader节点必须是奇数个，我们一般是3个，最多5个，所有节点都会主动和leader节点通讯，leader节点可以运行在集群任何节点上，也可以通过API接口手动调整leader节点所在的底层服务器，很灵活，任何一台都可以选举成leader，不用部署任何额外配置，省心。Q：编排调度都是自己开发的系统吗，如何管理那么多的容器？
A：用的CoreOS自带的模块，etcd+fleet+systemd，很底层，登陆任何一台机器做操作就可以管理整个集群，就像管理一台机器一样，我们把日常发布等操作基本都用Jenkins代劳了。
以上内容根据2016年10月25日晚微信群分享内容整理。分享人齐海澎（Kuma Qi），猎豹移动高级运维工程师。负责猎豹移动商业广告产品与大数据相关产品的运维团队管理，作为猎豹移动运维部的管理团队成员，负责商业广告业务和大数据计算在AWS服务上的稳定运行，并帮助公司开展容器技术的初步尝试。3年AWS服务使用与运维经验，运维全球8个region数以千计的计算服务资源，搭建并运维起跨5个地区的基于CoreOS的Docker集群。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2016-10-31
本文作者：齐海澎
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享( 九十）：猎豹移动基于CoreOS在AWS上的项目实践