幽灵学院

骞云科技 DevOps 实践一 构建更好的CI/CD流程

2019-03-13 21:42 来源:网络整理 编辑:幽灵学院  人气:   评论一下

本周二(2月26日)20:30 - 22:00,骞云科技在 DockOne 社区进行了主题为「骞云科技 DevOps 实践」的在线直播,反响热烈。分享内容及问答整理如下:

摘要

随着公司业务的快速发展,需要加快开发流程的规范化和自动化,以提高产品的开发效率和交付效率。之前的开发测试和资源管理主要是半自动化的,个人生产力和资源利用率仍有很大提升空间。

在DevOps的具体实践中,一方面, Gerrit + GitLab +Jenkins + CMP(Ansible)共同构建了更好的 CI/CD流程,对自动化持续交付流水线进行了优化;另一方面,CMP(Self-Service Portal)帮助建立了自服务自运维门户,公司所有人员都可以通过统一的门户自助申请各类资源,并自助完成日常运维。

主要内容:

1.为什么我们要加强DevOps?

2.DevOps整体规划

3.DevOps实践(一):构建更好的CI/CD流程

4.DevOps实践(二):建立自服务自运维门户

5.总结与建议

6.未来发展方向

为什么我们要加强 DevOps?

在公司创立早期,为了尽快实现产品从0到1的转化,我们将更多的资源投入到了产品的新功能开发上,在产品开发自动化方面的投入并不高。

随着公司业务的迅速发展,一方面,团队规模不断扩大,服务器资源也越来越多;另一方面,产品的功能逐渐丰富,开发代码工程数和分支数增加,而开发测试和资源管理仍以半自动化为主。

面临的问题

问题一:人力资源浪费

手工打包、手工创建虚机、手工部署、手工升级、较低程度的自动化测试,这些重复且低效的开发测试模式导致开发测试人员不能将宝贵的时间用于更加有创造力的工作上,不利于个人和公司的快速发展。

问题2:IaaS资源管理混乱

我们的开发测试环境主要构建在内部的vSphere和OpenStack云台上,当然也会在Aliyun、AWS、Azure等公有云上创建资源。在日常工作过程中,我们经常会听到这样的声音:“我的环境怎么这么卡”、“阿里云上又没钱啦”、“OpenStack上的机器我要删了啊”、“谁删了我的机器,我的数据还在上面呢”。由于没有权限控制导致资源随意创建,资源不及时释放导致大量资源闲置和浪费,另外还存在资源误删除情况。

问题3:内部系统运维成本居高不下

我们没有专职的内部系统运维人员,平时开发过程中,遇到CPU/Memory调整、磁盘物理卷/逻辑卷扩容、操作系统故障、应用故障等一系列问题都会占用研发人员大量的时间和精力。

问题4:产品交付难度大

为满足稳定性、高可用性、可扩展性等交付需求,我们的产品在软件架构设计上具有较高的复杂度,这样一来安装部署实施的难度也就比较大。售前团队到客户现场做POC,想要快速部署一套公司产品比较困难;售后团队在项目交付的过程中也经常遇到各种各样的安装配置问题。

基于上述问题,我们希望通过对DevOps工作流程进行改造和增强,以提高产品开发效率和交付效率,以及提升个人生产力和资源利用率。

DevOps整体规划

我们将DevOps工作流程改造分为了两个方面,一个是对CI/CD工作流的优化,一个是搭建自服务自运维门户。

(一) CI/CD目标

·所有代码工程能够自动化打包

·所有代码提交后能够自动构建编译检查以及单元测试任务

·每小时完成一次软件集成、部署以及核心功能的集成测试(API&UI)

·每天完成一次完整功能的集成测试(API&UI)

·每周完成一次7x24小时Longrun系统测试

·自动更新经过测试的nightly build到开发测试环境

·自动发布经过测试的weekly build到Demo环境

(二)自服务自运维目标

公司所有人员,都可以通过一个统一门户Portal,自助申请各种类型的IaaS资源,如: x86物理服务器、vSphere虚拟机、OpenStack虚拟机、Kubernetes上的容器服务,以及Aliyun、AWS、Azure等公有云上的云资源;自助申请日常开发所需的软件应用,如:Nginx、Tomcat、MySQL、RabbitMQ,以及SmartCMP等。

具体目标如下:

·开发Dev,测试QA,售前交付需要使用不同的资源,做到资源隔离;

·资源的使用需要有权限控制;

·需要能够一键部署单节点和HA多节点应用系统;

·提供环境自动初始化,一键升级能力;

·提供系统和应用级别的监控告警;

·资源需要能够定期回收。

DevOps实践(一):构建更好的CI/CD流程

概述

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

·GitLab:代码托管

·Gerrit:代码审查

·Jenkins:单元测试、自动化打包、集成测试

·CMP:vSphere、OpenStack、Kubernetes等云资源统一管理,应用系统自动化部署,版本更新

骞云科技 DevOps 实践一 构建更好的CI/CD流程

开发人员提交代码后,触发Jenkins完成代码编译检查和单元测试,Jenkins返回代码检查结果给Gerrit,人工Review后merge代码,触发Jenkins完成该项目的打包。Jenkins定时完成各个工程的集成打包,然后通过调用CMP的API触发自动化部署,部署完成后进行场景化的集成测试,测试完成后卸除资源。

持续集成(Jenkins)

起初我们使用GitLabRunner实现CI,在每个代码工程中添加“.gitlab-ci.yaml”文件,不同项目各自创建和维护自己的.gitlab-ci.yaml脚本,这样的实现可以解决各自工程的编译测试和打包问题,在代码工程数量较少时,我们也使用了较长一段时间。

现在我们的代码工程数量已超过20个,每个代码工程都设置了访问权限,如果需要专人维护CI脚本的话,那他需要能够访问所有代码工程,显然这样是不合理的,而且把集成打包脚本放在哪个工程里都不合适。

考虑到Jenkins有强大的CI能力:通过安装插件就能快速与Gerrit、GitLab集成,能够参数化执行各种类型的脚本。所以,我们使用Jenkins代替gitlab-runner完成CI,通过Jenkins可以统一管理各个工程的编译、测试、打包,而且比较方便构建流水线完成较多工程集成打包及测试。

骞云科技 DevOps 实践一 构建更好的CI/CD流程

持续部署(Ansible)

我们的产品由20多个服务组成,可部署在一个或多个虚拟机上,使用Shell脚本或Python脚本已经很难完成这么多服务程序的自动化安装部署配置。

[提醒] 除特别声明外,该内容由( )发布,转载请保留文章出处!
  •  我顶 
  • 点击
  • 收藏