大家好，今天我将分享通联数据使用Docker和Rancher构建自动化发布管道的经验，我会介绍通联数据自动化发布的流程及方案设计，我们从踩过的一些坑中总结出来的经验，以及我们的自动化发布管道的系统运行现状。
 

一、通联数据的需求及选择Rancher的原因

 
通联数据是一家这几年新崛起的金融科技公司，主要目标是致力于将大数据、云计算、人工智能等技术和专业投资理念相结合，打造国际一流的、具有革命性意义的金融服务平台。这里面涉及到几个关键词：大数据、云计算、人工智能，这些热词已经有很多企业提及过，因此我也不赘述了。
 
通联数据作为一家创业公司，也会遇到很多创业公司都会遇到的问题，比如产品太多，而且每年很多产品都会推翻重来，就会遇到各种各样的问题。比如，应用在开发时，涉及到需要多少CPU、需要用什么语言去编程等问题，开发人员不会与后台人员事先沟通，出来一个产品，直接让运维人员上线。
 
基于这样一个背景，我们迫切需要打通上线这条管道，因为在可预见的将来，通联数据每年将会有大量的新应用出现，如何打通上线这条管道亟待解决。
 
我们做的第一件事，就是做持续集成。由于我们公司每年会有上百个新的项目产生，每个项目的语言、框架、部署方法都不尽相同，发布流程也是比较冗长低效的，部署应用占用了运维人员大量时间。
 
我们决定用容器解决这个问题，评估了多家供应商后选择了Rancher，主要原因在于：
 
首先，Rancher的操作界面非常简单，相信用过Rancher的人都会有这种感受，它不需要太多专业的知识，很容易上手；其次，Rancher在部署时也非常简单，可以一键式部署，Rancher还提供了良好的API支持，方便集成。
 
二、自动化发布的流程
 
随后，我们开始搭建自己的CI/CD。当时我们在流程方面遇到了很多困境，下图已经是简化制作后的了，实际上还有更多各种各样的分杈和分枝：

就我们原来的流程来说，流程最开始的部分是研发；随后进入QA环境部署，这时候就需要人去部署，通常是运维人员，但是运维一般不愿意做这个事情；部署完成后，进入QA环境测试阶段，通知开发和测试人员进行测试，过程中可能会出现延迟，因为测试人员可能正忙于其它的事情，不能马上进行测试；QA环境测试通过后，进入STG环境部署；随后再进行STG环境测试，这几个过程可能会循环很多次。跟着进入安全测试阶段；测试通过后，还有一个正式包的一个准备过程，最后才能上生产部署。即使是这个简化后的流程也是非常复杂的，而且其中涉及到很多线下的沟通，效率不可能高得起来。
 
在使用Rancher之后，原本的流程大大简化了，改进后的简化流程如下图：

流程的第一步即持续集成，意味着开发人员写好代码后可以直接通过CI，CI触发自动编译，随后自动部署脚本，测试环境已经就绪。简单来说，每次开发人员提交代码之后，测试环境就始终处一个就绪的状态，这时候就可以直接进入测试阶段，整个过程都处于线下，不需要走任何流程，全部实现自动化了。
 
测试人员完成测试后，再进行STG环境测试，因为后台已经跟Rancher完成对接并实现自动化，这赋予了QA环境测试从未有过的强大的自动化能力，意味着QA环境测试可以自动对接到STG环境测试。测试通过后，进入安全测试阶段，这个阶段是公司要求的，无法避免，安全测试通过后就进入到生产部署。以前绕不开的线下沟通那些步骤和一些部署就可以省去了，整个流程优化并且简洁，效率也提升了。
 
CI/CD说起来可能很简单，比如PUSH代码、QA环境自动就绪。但是实际操作起来并非如此，仍然存在很多需要解决的问题。比如开发的分支模型就涉及到在开发代码的时，要PUSH什么分支才能部署，还是PUSH所有的分支都能部署？
 

三、开发分支模型

 
当时我们想到最好就是PUSH任意分支都能部署，这样就非常方便。但随后就发现这方法行不通，会造成混乱，而且难以管理。此前我们Git的一个The Successful Branch Modeling分支模型就类似于此，此模型规定了一个develop分支、一个feature类型的分支、一个release类型的分支、一个hotfixes类型的分支和一个master分支。

在平时开发时，开发人员常常会在develop分支上切出一个feature的分支，比如,开发一个包含很多功能的story，那么所有人切一个story，这边story有自己的ID，然后再去开发，把story开发完之后，再把它merge过来。最终，我们只选择了一条线做CI，当代码PUSH或者合并到develop分支时，我们帮你去做这个，而在这个feature分支的时候，我们另作处理。
 
feature分支意味着当用户提交一个feature分支之后，我们会另外帮你部署一套，每一个feature分支部署一套，相当于每一个story都可以分开独立去测试，最后把它合并到develop分支。那么测试的时候，测试可以根据自己的需求来决定它到底在哪一条分支线上去测试。
 
比如，A测试中如果用户只关心story A，那就在story A这个分支测试环境去测，这些story全部合并进来之后，再进行一次集中测试，测试通过后，在发布时把这个分支切到release 的一个分支上来，然后，在release上发布正式包，让QA在STG环境继续进行测试，就如前面看的那个流程图。分支模型非常混乱，为了做CI，我们会跟开发人员定义好每一条分支，每个分支对应的每个不同行为也定义好，这在混乱的分支模型下非常有用。
 

四、版本号规则

 
为了做CI，版本号的规则必须一致，如果每个团队版本号命名不一样的话，匹配规则就会非常麻烦和混乱。后来，我们选择了Semantic Versioning的一个版本号的规则，就是几点几点X，这是一种常见的版本号命名方法，此版本号包含标准的一个文档，文档描述了此版本号的具体定义，第一个叫MAJOR，第二个叫MINOR，第三个叫PATCH，后面还可以加各种自己的版本号。

 

五、CI触发路径

 
下面我将介绍我们的CI的触发路径——Git push，push到develop分支，Git push就会push到Gitlab的server上，随后通过webhook去调用Jenkins，Jenkins会把这个包bulid出来。原本我们是想通过Jenkins调用Rancher的API，后来发现直接调用Rancher有差距，过程进行的也不那么顺利，为了解决Jenkins和Rancher之间的gap这一问题，我们在它们之间装了一个Ponyes的软件。

为什么需要Ponyes这一中间层？它到底提供了哪些价值？
 
（1）动态修改版本号
 
首先，它可以解决动态修改版本号的问题，大家用Rancher的时候，发现Rancher的商店非常好用，我们可以在商店里把一些东西定义好，接着QA只要填几个参数，就可以把一个应用部署起来了，没有Ponyes这一中间层之前，必须找运维人员去做，过程也比较复杂。
 
为了用起来Rancher应用商店，我们还定义了一个应用商店的模板，这样我们就可以在每次PUSH代码的时候，把这个模板生成一个真正可以部署的应用。但是，版本号还是存在一些问题，我们每次PUSH代码的时候，到Jenkins，我们会根据阅览数给Jenkins升级一次版本号，比如说1.0.1.0-1，第一次阅览是-1，第二次阅览即-2，Jenkins的版本号根据阅览次数相应变化。这时候应用商店也要随之而变。
 
因此，我们做了这样一个模板，通过这样一种方式，在Ponyes中，每个Jenkins可以获得对应的版本号，然后把这个版本号通过变量把它注入进去：

sample:
  image:    {{ REGISTRY }}/automation/auto-sample:{{ m['auto-sample']}}

 
这一过程还涉及到registry，因为QA环境和STG环境是完全分开的，在进行模板渲染时，我们需要知道到底是发到QA环境还是STG环境，从而对registry的地址做出相应改变，这样的话，上面说的修改版本号的问题就解决了。
 
（2）多service管理
 
还有一个比较棘手的问题，即一个stack中有多个服务怎么办？比如，一个比较小的团队可能总共就几个人，每个人负责好几个项目，与微服务的关系有些相似，那么一个stack可能有好几个服务，最典型的就是前端、后端，或者是其他的一些中间件，每一项是一个服务。
 
开始部署时，Rancher里面的这些服务也要用一个stack来管理，有多个服务就会面临怎样管理的问题。比如，一个stack有ABC三个服务，服务C更新时，整个stack也应该更新版本号，因为在Rancher里面，stack被部署出来之后，有个update available的黄色按钮，如果有新版本，点这个按钮，就可以升级这个stack，而且必须升级整个stack，而不是只升级某个服务，这时候就需要管理多个服务。Ponyes记录了服务和stack之间的关系，任意一个服务更新，也会触发stack的更新，更新的方法就是每个服务每次更新，stack的版本号+1。
 
（3）多版本并行发布
 
接下来还有一个更严重的问题，如果多版本并行发布，我们应该怎么去处理？比如说我们ABC三个模块，A发布过1.0和2.0，B发布过3.0、4.0，C发布过5.0和6.0。如果发布一个C应用的5.0.2，那么对应的AB模块号应该选什么，这个问题困扰了我们很久。
 
有好几种方法可以解决，比如用某个东西记录C5.0和AB的一个版本号之间的关系，这表示用户可以自定义。但也存在一个问题，用户需要自己去管理它们之间的版本号关系，时间长了，可能会弄乱或弄错版本号，或者弄错版本号之间的关系，随后上线到生产环境，后果更严重。
 
还有一种方法，就是将用户的C版本号最后一次发布到5.0时AB是什么版本静态地记录下来。但这样的话系统会变得相当复杂，很容易出错。
 
最后，我们选择去除多版本并行发布的能力，只支持单个版本的发布，意味着如果要发布，必须是最新版本，历史版本可以用另外的方法进行人工处理，这样的话，系统会更简单，而且不容易出错，也不需要用户去维护一个版本号之间的关系。以上这些功能都是借助我们自己写的Ponyes解决的。
 
Rancher 2.0也提到了CI/CD这样一个功能，在实际过程中，会遇到一个非常现实的问题，从代码研发到整个生产环境部署有许多环节，具体情况也非常复杂，而CI的作用可能仅止于QA，后面的环节还会有新的难题，这时就需要一个体系把整个生命周期贯穿起来管理，Rancher承担的作用就在于此。
 

六、肉身踩坑总结的三条经验

 
（1）部署几套Rancher环境？
 
这问题看似很小，最初也在我们内部也引发过不少讨论。最初我们只部署了一套Rancher，在Rancher里面用环境去区分QA或production。部署一套Rancher的方式最简单，但是有一个严重的问题：Rancher升级了怎么办？这套Rancher既管了QA，又管了production，升级的时候需要把生产环境也升级，此刻如果出现bug，问题将非常严重。
 
后来我们把它拆成四套，Rancher平台本身也得有一个升级的环境。建议大家在前期部署Rancher的时候要部署多套环境（至少两套），我们实际上是dev、QA、staging、production每个环境都有一套，总共四套。
 
（2）配置项爆炸
 
第二个问题是关于配置项。我们最开始是使用Rancher compose的，它非常简单强大，我们在Rancher Catalog里点一下“部署”，配置选项全弹出来，我们只需要点选一些东西，就可以部署一个很复杂的应用。后来我们却发现，应用的配置项越来越多（甚至多达上百个）。这导致它们难以在一个页面里展现，同时上百项的配置让我们无从填写，运维也无法成功部署，我们从而面临了配置项爆炸的问题。
 
我们的解决经验是，在容器平台里面，配置项一定要集中管理。我们把配置项全部用consul管理，每次容器启动时到consul里把配置拉到对应的容器里来。如此一来，容器可以在任意平台漂移。另外配置项本身在原server存有副本，我们copy原配置项加以修改，就可以部署另一个实例了。所以说，配置项一定要全部集中管理起来。
 
（3）泛域名+Rancher LB
 
我们每一个业务都有一个web服务，要申请自己的域名。每年我们有上百个项目上线，这意味着有上百个域名要申请。加上这些域名都分别需要在开发、测试、生产环境中使用，所以我们每年要申请将近五百个域名。这是一件恐怖的事情。
 
后来我们就用了泛域名的方法。比如用.sub.example.com的域名，直接CNM到Rancher环境中的其中一台主机。然后在Rancher上设置它的LB，LB就可以分布在所有的主机上，每个主机上都会有同样的LB。这个域名任意指向一台主机，它都可以工作。
 
比如说，在QA环境，这个LB上serve了如下这些域名，若主机坏掉了，容器本身会启动，入口问题则可以很简单地通过修改量来搞定。如果是生产环境则可以在上面再加层nginx，配三个upstream，死掉任意一台，还可以通过另外两个入口进来。
 
使用泛域名的方法，在配置好泛域名之后，在Rancher LB上再加任意域名都不用再去申请新的域名，而是可以直接写123.sub.example.com，然后直接在LB上配置，配完之后域名即可用，无须再走申请的流程了。

本文转自 RancherLabs 51CTO博客，原文链接:http://blog.51cto.com/12462495/2071022