写点什么

OpenStack 持续交付的六大挑战与四个统一

2015 年 9 月 09 日

在 3 月 21 日由 OpenStack 中国用户组主办的 OpenStack Meetup 活动上,UnitedStack 运维团队负责人,同时也是 OpenStack 社区核心开发者的余兴超分享了多年运维 OpenStack 服务的经验和体会。本文根据余兴超演讲的部分内容整理而成,主要包含 OpenStack 在实际服务运维工作中所遇到的具体挑战,以及统一运维的具体策略。

持续集成(CI)和持续交付(CD)是 OpenStack 运维工程师们所面临的两大课题。其中,持续集成是保证整个研发团队的开发进度保持同步,其目的是消除由于集成问题引起的项目延期;持续集成的最后一公里是交付,所谓交付,也就是将代码最终部署到线上环境,转变成生产环境中提供服务的软件。

六大挑战困扰OpenStack持续运维

要实现持续集成和持续交付的目标对于 UnitedStack 的运维团队是一项异常艰巨的任务。具体说来,运维的挑战来自以下六个方面。

  1. 项目和服务众多的问题。这其中包含了 Nova(计算)、Glance(镜像)、KeyStone(识别)、Neutron(网络)等常规的 OpenStack 的服务组件,也有 UnitedStack 内部开发的一系列服务,例如 Placebo(面板)、Kiki(消息通知)、Ticket(计费)、Gringotts(API 中间件 )等等。另外,还需要管理一系列的基础服务,例如消息队列、数据库、负载均衡、高可用软件等。
  2. 服务软件包的依赖复杂度。比方说,计算服务 Nova 的软件包的线上运营需要安装 13 个相关的 Nova 包、163 个相关依赖包,同时还要升级 9 个相关的依赖包。大多数依赖包都有非常严格的版本要求。
  3. 配置文件和选择繁多。还是以 Nova 为例,仅 Nova.conf 就有 835 个配置选项,算上注释,大约有 1700 多行。
  4. OpenStack 灵活的架构带来的运维挑战。OpenStack 可以将某些功能和后端驱动抽象为独立的 Filter 和 Plugin。比方说,你可以选择用 Nova-Network 还是 Neutron 来构建 SDN,可以选择用 Ceph 还是 Sheepdog 作为 Cinder backend,还可以选择 KVM 还是 Xen 作为 Nova-compute 的 Hypervisor。
  5. 私有 Patch 太多。事实上,UnitedStack 的服务运维团队对于私有 Patch 的态度是非常谨慎的。我们会尽量把 Patch 提交到社区,即便未提交的社区,也会尽可能地不去破坏 Patch 的代码逻辑,即便不得不进行修改,也会尽可能地保持代码的可维护性。但即便如何,运维的难度依然很大,目前 UnitedStack 团队运维的很多服务的私有 Patch 都超过了 100 个,例如 Keystone、Ceph 和 Neutron。
  6. 这些坑都趟过了,等着你的还有 OpenStack 各个项目版本频繁变更带来的运维陷阱。这也是由社区和我们自己的研发结构所决定的。大家都知道,每隔 6 个月,OpenStack 社区的各个项目都会发布新的版本。UnitedStack 的服务版本更新则穿插其间,过去的半年时间,我们每个月平均上线 2.6 个新项目。回顾 UnitedStack 过去 32 周的线上环境软件包版本的变更次数,我们发现,版本变更始在过去的半年多的时间里保持了相当高的变更频率,其中由两周的变更次数超过了 70 次。

**“四个统一”**实现运维自动化

越是复杂和多变的系统,就越需要统一的运维规范和框架。而这里说的统一是指统一的框架、统一的工具、统一的处理流程,以及统一的接口。

  1. 统一的框架

在 UOS 1.0 版本开发时,UnitedStack 活力四射的工程师们开发了很多项目,编程语言也是多种多样,Java、Python、Ruby 都有,持久化后端有的用 SQL,有的用 NoSQL,消息队列有的用 RabbitMQ,有的用 ZeroMQ。我们的运维团队很快就 Hold 不住这些大神们了。我们也曾经尝试过制定相关的开发规定,但是无法起到实际的约束作用。最后,还是由运维团队牵头,制定了名为 BoneDragon 的统一的开发框架。这一框架是用 Python 语言编写的,可以一键生成项目的基础开发框架,包含标准化的 API 模块、数据库模块和测试用例。BoneDragon 框架已经开源,并且发布到 GitHub 上。
2. 统一的工具 UnitedStack 已经建立了一套由统一的工具构成的持续交付系统工作流程。统一的工具组由 PSRForge(包管理系统)、Puppet(配置管理系统)、Ansible (任务编排系统)和 Jenkins(自动构建系统)组成。它们覆盖的软件打包、任务编排上线、任务部署、部署验证任务的完整流程。

其中,包管理系统 PSRForge 是我们自行开发的,因为当时我们没有找到合适的开源项目。我们的团队目前维护着大概 230 个软件包。包管理系统共分为三个子系统,分别是 Spec 管理系统、软件包自动构建系统和软件仓库管理系统。

配置管理系统是 OpenStack 服务持续交付工具链的核心组件。在谨慎的调研和考量后,我们选择了 Puppet 作为配置管理工具。在此我想强调的是,没有任何一个工具是万能的,既然选择使用一个工具,运维团队必须清晰地明确它的能力和局限。拿 Puppet 来说,它非常适合做软件包的安装、配置文件的管理、服务状态的管理、命令的执行等;但它也有一些天然的短板,比方说不太适合做源代码的管理、依赖包的管理,也不太适合做服务的初始化操作、服务状态的监控和恢复,以及节点间的依赖管理。

因为 Puppet 缺少任务编排能力,因此我们一直在寻找一个工具,可以达到我们的期望。任务编排系统我们最终选择使用的是 Ansible。在此之前,我们陆续使用过 Dispatcher、ClusterShell 和 Mcollective 。其中,Dispatcher 是我们基于 SSH+ini 配置文件自行编写的,后来我们发现开源项目 ClusterShell 同样是基于 SSH,并且功能十分完善。后来我们转向 Mcollective,这是 Puppet Lab 专门收购的一款配置管理工具,后来放弃 Mcollective 的主要原因是它的架构过重,同时是用 Ruby 语言编写的,而统一一直是我们追求的目标。Ansible 目前在 UnitedStack 的运维效果我们是比较满意的,它的优势体现在无代理、基于 yaml 的配置文件,并且可用于集群的任务编排。

Jenkins 是目前业内运用最为广泛的自动构建系统。目前,UnitedStack 所有重复性的工作,比如执行单元测试、集成测试、构建软件包等工作必须以 Jenkins 的 job 形式出现,这样使得打包和测试工作自助化,也是我们实现自动化运维的前提。目前,UOS 的各项目单元测试、UOS 各项目打包、Doctor 集成测试、UOS 环境构建和清理已经全部在 Jenkins 平台完成。
3. 统一的流程 在高速运转的持续交付流水线中,流程的统一举足轻重,这也就意味着流程的制定是非常关键的,要既合理,又尽量简单。目前,我们使用的流程包括软件包管理、线上服务变更、软件发布周期管理、部署逻辑代码提交、公共库变更等等。

我个人觉得非常值得分享的是我们的持续打磨的 OpenStack 跨大版本升级流程。我们是从 2011 年的 Diablo 版本开始接触 OpenStack,期间经历了数次的大版本升级,至今已经总结出了相对成熟的大版本升级的具体流程。

在研发端,研发团队需要确认项目的 upstream Base,也就是确认版本的合并点;然后,完成私有 patch 的合并工作;第三,给出依赖库的版本变更列表,放入 requirements 项目中;第四,给出配置选项的变更列表;第五,给出数据库 schema 的变更版本,以方便部署是的检查。

在部署端,我们首先需要更新 SPEC、SOURCES 文件,制作新版本软件包;然后更新 puppet-xxx module,合并私有 patch;接下来在开发环境上线进行调试,并且打上预发布版本号,在测试环境上线,同时需要通过集成测试。

线上的变更是需要特别谨慎的,稍有不慎就会有意外事件的发生。在版本最终上线前,开发团队需要给出线上业务变更单,说明业务变更内容,可能造成的影响,执行流程,回滚流程等;涉及公共库变更的,需要所有相关人员确认;业务的变更流程已预先制定完成,则必须借助工具自动执行。你只能与命令行工具做交互,输入 Yes or No,但不能输入任何命令。
4. 统一的接口 在 UnitedStack,我们的自研项目和 OpenStack 项目都提供了统一的 API,我们也有自己的命令行工具(UOS CLI)对一些资源操作进行封装和简化,这些前提使得我们的自动化测试工作变成可能。

以此为基础,我们构建起名为 Doctor 的健康检查服务。Doctor 服务主要的功能包括,诊断 UOS 所有的服务是否正常;恢复 UOS 所有的服务至正常状态;收集 UOS 服务的错误日志和相关的系统信息。

下图是创建 volume snapshot 操作失败后的反馈,Doctor 服务会描述操作的执行时间、执行过程、故障发生的步骤、服务的错误日志等,都会详细地展示并说明。

【注】演讲者余兴超是 UnitedStack 运维团队负责人、OpenStack 社区核心开发者,目前负责 UnitedStack 运维组的工作。他努力追求极致的运维管理服务技术,同时也是 OpenStack 多个项目的深度参与开发工程师。

2015 年 9 月 09 日 19:00710

评论

发布
暂无评论
发现更多内容

PC五年,华为如水

脑极体

uni-app跨端开发H5、小程序、IOS、Android(一):太强了,一次性搞定全端开发

黑马腾云

微信小程序 uni-app uniapp web前端 3月日更

微服务的下一步,离不开服务网格

xcbeyond

微服务 Service Mesh 服务网格 3月日更

Java程序员面试15家公司收到15份offer,月薪35K全靠这Java面试小抄(2021版)开源分享

云流

Java 程序员 面试

思维转换 - 更好的认识世界

石云升

程序员成长 思维模型 28天写作 3月日更

阿里P9春招特此分享:Java核心开发成长手册(2021版)涵盖所有p5-p8技术栈

比伯

Java 编程 架构 面试 程序人生

Kubernetes入门——深入浅出讲Docker

百度开发者中心

Docker Kubernetes 云原生

Kyuubi: 网易数帆开源的企业级数据湖探索平台(架构篇)

网易数帆

大数据 spark 开源 Kyuubi

吉他扒谱该怎么做?分享一款超好用的扒谱工具!

奈奈的杂社

区块链电子证照应用赋能政府服务

13530558032

惊讶!阿里大佬总结的图解Java小册火了,完整版笔记开放下载

周老师

Java 编程 程序员 架构 面试

阿里二面:什么是mmap?

艾小仙

案例+源码!阿里新产高并发技术小册太香了!内容涵盖高并发、网络编程、微服务、数据处理等诸多技术栈

程序员小毕

Java 程序员 面试 高并发 阿里

您的客户管理决策是否低于10毫秒?

VoltDB

5G 物联网 解决方案 电信

Java的“泛型”特性,你以为自己会了?(万字长文)

比伯

Java 编程 程序员 架构 计算机

校招开始,你做好【终身成长】的准备了吗?

闲鱼技术

NAC公链——Nirvana NA公链白皮书

区块链第一资讯

挖矿 区块链+

干货来袭!这份阿里内部面试题库已经助我拿到了5个大厂Offer!

Java王路飞

Java 程序员 架构 面试 阿里

Kubectl Plugin 推荐(三)| 插件开发篇

郭旭东

Kubernetes kubectl kubectl plugin

网易云音乐:基于分布式图学习PGL的推荐系统优化之路

百度开发者中心

Kubernetes入门——Kubernetes工作原理及使用

百度开发者中心

#Kubernetes# #技术课程#

对htmlMeta的实例详解

佰草

html5

4面字节跳动,终于“跳进去”了! 分享一波字节的面经。

Java成神之路

Java 程序员 架构 面试 编程语言

快手、饿了么、小红书等14家互联网企业面经分享,感谢60多位面试官让我更加认清我自己

Java成神之路

Java 程序员 架构 面试 编程语言

五个问题,三大策略,手把手教你定制App性能监控方案

友盟全域数据

监控 应用性能 监控工具 告警设置 质量监控

再迎巅峰!阿里内部Java编程思想全栈技术实录Github上线7天已经星标89K!

程序员小毕

Java 编程 程序员 架构 面试

面试官:啥?SynchronousQueue是钟点房?

四猿外

Java 并发编程 高并发 并发 SynchronousQueue

在vscode中go编码发生的问题整理

happlyfox

golang 学习 vscode 28天写作 3月日更

最新阿里Java岗位四面面经分享:并发+JVM+事务+集群+秒杀架构+数据库等

Java成神之路

Java 程序员 架构 面试 编程语言

论如何快速吃透算法?186道高阶算法题+学习资料程序员面试必备

比伯

Java 编程 架构 面试 程序人生

云原生时代下,容器安全的“四个挑战”和“两个关键”

阿里巴巴云原生

容器 云原生 k8s 安全 监控

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

OpenStack持续交付的六大挑战与四个统一-InfoQ