骞 骞云科技DevOps实践

随着公司业务的快速发展，有必要加快开发过程的标准化和自动化，以提高产品开发和交付的效率。之前的开发、测试和资源管理都是以半自动为主，个人生产力和资源利用率还是有很大提高空。在DevOps的具体实践中，一方面Gerrit+git lab+Jenkins+CMP(ansi ble)共同构建了更好的CI/CD流程，优化了自动化连续交付流水线；另一方面，CMP(自助门户)帮助建立自助运维门户，让公司所有人员通过统一的门户自行申请各种资源，自行完成日常运维。

为什么要加强DevOps？

公司成立初期，为了尽快实现产品从0到1的转型，投入了更多的资源开发产品的新功能，产品开发自动化投入不高。

随着公司业务的快速发展，一方面团队规模不断扩大，服务器资源不断增加；另一方面，产品的功能逐渐丰富，开发代码项目和分支数量增加，而开发测试和资源管理仍然以半自动为主。

面临的问题:

人力资源浪费

手动打包、手动虚拟机创建、手动部署、手动升级、低级自动化测试，这些重复低效的开发测试模式导致开发人员和测试人员无法将宝贵的时间花在更有创意的工作上，不利于个人和公司的快速发展。

IaaS资源管理混乱

我们的开发和测试环境主要建立在内部的vSphere和OpenStack云平台上，当然资源也会在阿里云、AWS、Azure等公有云上创建。在日常工作中，我们经常会听到这样的声音:“为什么我的环境这么卡”“阿里巴巴云没钱”“我想把OpenStack上的机器删了”“谁删了我的机器，我的数据还在上面”。因为没有权限控制，资源随意创造，资源没有及时释放，导致大量资源闲置浪费。此外，还有资源被误删的情况。

内部系统运行和维护成本仍然很高

我们没有专职的内部系统操作和维护人员。在正常开发过程中，CPU/内存调整、磁盘物理卷/逻辑卷扩展、操作系统故障、应用程序故障等一系列问题。将占用R&D人员大量的时间和精力。

产品交付很困难

为了满足稳定性、高可用性、可扩展性等交付需求，我们的产品在软件架构设计上具有很高的复杂性，这使得安装、部署和实施更加困难。售前团队去客户现场做POC，很难快速部署一套公司产品。售后团队在项目交付过程中经常会遇到各种安装配置问题。

基于上述问题，我们希望通过改革和增强DevOps工作流来提高产品开发和交付的效率，以及个人生产率和资源利用率。

DevOps总体规划

我们将DevOps工作流转换分为两个方面，一个是优化CI/CD工作流，另一个是搭建自助和自营门户。

CI/CD目标

所有代码工程能够自动化打包所有代码提交后能够自动构建编译检查以及单元测试任务每小时完成一次软件集成、部署以及核心功能的集成测试（API&UI）每天完成一次完整功能的集成测试（API&UI）每周完成一次7x24小时Longrun系统测试自动更新经过测试的nightly build到开发测试环境自动发布经过测试的weekly build到Demo环境

自助和自营目标

公司全体员工可以通过统一的门户网站自行申请各种IaaS资源，如x86物理服务器、vSphere虚拟机、OpenStack虚拟机、Kubernetes上的容器服务、阿里云、AWS、Azure等公共云上的云资源；自助申请日常开发所需的软件应用，如Nginx、Tomcat、MySQL、RabbitMQ、SmartCMP等。

开发Dev，测试QA，售前交付需要使用不同的资源，做到资源隔离；资源的使用需要有权限控制；需要能够一键部署单节点和HA多节点应用系统；提供环境自动初始化，一键升级能力；提供系统和应用级别的监控告警；资源需要能够定期回收。

建立更好的配置项/光盘流程

总结

我们的DevOps工具链由GitLab、Gerrit、Jenkins和CMP组成。

GitLab：代码托管Gerrit：代码审查Jenkins：单元测试、自动化打包、集成测试CMP：vSphere、OpenStack、Kubernetes等云资源统一管理，应用系统自动化部署，版本更新

具体工作流程如下图所示:

开发人员提交代码后，Jenkins被触发完成代码编译检查和单元测试。Jenkins将代码检查结果返回给Gerrit，手动Review后合并代码，触发Jenkins完成项目的打包。詹金斯定期完成各个项目的集成和打包，然后通过调用CMP的API触发自动部署。部署完成后，进行场景集成测试，测试完成后移除资源。

持续整合(詹金斯)

起初，我们使用GitLab Runner实现CI，并添加了”。gitlab-ci.yaml "文件添加到每个代码项目。不同的项目创建和维护自己的。gitlab-ci.yaml脚本。这种实现可以解决自己项目的编译、测试和打包问题，在代码项目数量较少的时候，我们也使用了很长时间。

现在有20多个代码项目，每个代码项目都有访问权限。如果一个特殊的人需要维护配置项脚本，他需要能够访问所有的代码项目。显然，这是不合理的，不适合在任何项目中放入集成的打包脚本。

考虑到詹金斯强大的CI能力，他可以通过安装插件快速的与Gerrit和GitLab集成，并且可以参数化的执行各种类型的脚本。所以我们用詹金斯而不是gitlab-runner来完成CI。詹金斯可以统一管理各种项目的编译、测试和打包，构建一个管道来完成更多的工程集成打包和测试更方便。

持续部署(可移植)

我们的产品由20多项服务组成，这些服务可以部署在一台或多台虚拟机上。用Shell脚本或者Python脚本很难完成这么多服务程序的自动安装和部署配置。

恰好团队有使用Ansible部署复杂系统的经验，Ansible的学习成本也比较低，所以我们选择使用Ansible Playbook来实现这20多个服务程序的统一安排、部署和配置，可以同时支持单节点和HA多节点自动部署。

下图是Ansible自动化部署的拓扑图:

当我们设计Ansible Playbook时，我们将每个服务设置为独立的角色，从而确保每个服务部署的独立性。这种分布式部署架构为未来的容器化部署和微服务奠定了基础。

Ansible自动化标准化部署不仅大大缩短了部署时间，还大大降低了部署错误的概率。本来按照HA架构部署一套产品需要一天的时间来完成每个服务的部署和配置。使用Ansible playbook，我们只需要45分钟，在中间过程中可以自由做其他事情。

集成测试(机器人框架)

目前在詹金斯用Robot Framework做集成测试。机器人框架(Robot Framework，以下简称RF)是一个基于Python的可扩展的关键字驱动测试自动化框架。

为什么选择射频:

一致性：目前公司的UI自动化测试使用的就是RF框架，RF框架也完全有能力做集成测试，因此使用RF框架做集成测试，可以降低学习成本，提高可维护性。复用性：在安装了Robot-Framework-JMeter-Library后，RF可以运行JMeter脚本，并且将JMeter运行结果转为Html格式。公司目前性能测试用的就是JMeter，对于相同场景，只要小幅修改JMeter脚本即可将其复用到集成测试上面。

选择射频也有一些问题:

如果不复用JMeter脚本，编写的API测试用例的成本非常高。 RF对于变量类型的规定堪称僵硬（当然，这么规定带来的好处是方便类型检测），RF中对于字典类型的创建非常麻烦（嵌套的字典实例如下），对于我们公司API请求中携带大量参数的情况，只能创建关键字来解决，不管是采取RF自带创建字典的方法，还是创建关键字的方法，都比较浪费时间（因为难以复用）。RF可以轻松扩展关键字，也因此可能带来乱扩展关键字的问题，导致测试用例可读性和可维护性差的问题。

在RF中，关键字其实是Python/Java类方法，所以非常容易扩展。但是一旦关键词多了，其他人(甚至过了一段时间)维护一个同事写的测试用例就很麻烦了(你需要回去看看关键词是怎么指定的)。因此，严格规定关键词创作的规范值得深入探讨。

建立自助自助运维门户

我们利用云管理平台(以下简称CMP)对公司内部资源进行管理，使公司所有人员都可以通过CMP提供的自助服务门户自行申请IaaS资源和计算/存储/网络等软件应用，并可以自助进行日常运维操作。

化学机械抛光平台的准备

通过LDAP将公司的AD账号导入到CMP平台，为开发、测试、售前和售后团队创建不同的业务组和资源池。每个资源池都被赋予不同的资源配额，以便合理分配资源并相互隔离。为每个业务组设置一个管理员，以批准业务组成员的资源申请。

我们使用Shell、Python脚本或Ansible配置管理工具，对一些常用软件和应用系统的安装过程进行打包，发布到CMP平台，提供标准化的蓝图供大家申请。

自助和自营门户

在门户中可以看到发布的服务卡，点击服务卡就可以完成IaaS资源或应用系统的自助应用。在正常的开发和测试过程中，我们不再需要关心底层复杂的系统或网络配置。

在门户中可以清晰的看到自己管理的资源的性能，简单方便的完成一些日常的基本运维操作:重启、调整配置、添加逻辑卷、扩展逻辑卷等等。

另外，使用管理账号登录CMP管理平台，可以清楚的看到公司内部资源的整体使用情况。

总结和建议

在千云科技的DevOps实践中，一方面，我们将GitLab、Gerrit、Jenkins、Ansible、JMeter、Robot Framework等开源技术与企业内部云管理平台相结合，实现了开发测试过程的高度自动化，促进了产品的持续集成和交付，减少了大量重复性工作，提高了开发测试效率。

另一方面，通过云管理平台的使用，为复杂异构的IaaS资源提供服务，降低了使用难度；根据业务部门的需求合理划分资源，减少资源浪费，加强资源的有效隔离，避免误操作；自助服务和自我运营维护的模式极大地提高了公司的整体R&D效率。

我们的DevOps实践方案适用于各种场景，如灵活的扩展、迁移和负载平衡。IT在传统IT、金融、互联网、游戏等行业也具有普适性。

未来发展方向

在介绍Ansible自动化部署时，提到我们的业务系统由20多个服务组成，符合面向服务的架构设计，现在可以满足私有化的部署要求。随着新功能的不断引入，一些业务子系统的复杂性和团队开发的耦合度会逐渐增加，协作效率和部署效率会变低。此外，当前的软件架构和部署架构无法满足未来的SaaS部署。因此，我们仍然需要在更细的粒度上分割服务，逐步转换到微服务架构，并使用容器化部署来进一步降低开发和部署成本。

问答。A

问:CMP和各种云平台使用平台的jar，需要各种资源来生成。这不是工作量大吗？如果api更新，代码量也很大，对吗？

答:我们的核心业务是做一个云管理平台。我们的产品完成了各种云平台的对接，主要是调用各个云平台的API。公有云的API更新频率不是很高，每当API更新时，我们都会及时进行适配。

问:问:詹金斯的首次提交也能触发构建吗？每个自动构建的版本号是如何更新的？

答:我们的项目代码在Jenkins上创建项目构建Job之前满足构建条件，因此它在首次提交时不会触发构建。每个构建的版本号由两部分组成，一部分是产品的发布版本号，另一部分是环境变量Jenkins构建号。

问:和Gerrit在一起，为什么是GitLab？Gerrit也可以宿主代码？

答:这有历史背景。我们首先选择GitLab进行代码托管，然后加入Gerrit进行代码审查。Gerrit在代码审查方面比GitLab的mergerrequest方便很多，更适合企业内部使用。关于这一点，我的想法是要么GitLab迁移到Gerrit，要么不使用Gerrit，GitLab的合并请求可以用来审核，所以GitLab其实是没有必要的。