写点什么

80% 的软件环境管理问题,根因都在这里 | 研发效能提升 36 计

作者:阿里云云效
  • 2022 年 2 月 23 日
  • 本文字数:3607 字

    阅读完需:约 12 分钟

80%的软件环境管理问题,根因都在这里 | 研发效能提升36计


专栏策划|雅纯

志愿编辑|jimmy、吕瑞星


软件交付的终态是提供稳定可预期的系统,要做到这一点,我们需要确保:一、软件制品的一致性;二、运行环境的一致性。


第 3 讲我们分享了如何保证软件制品的一致性,这一讲我们来谈谈如何保证环境的一致性


运行环境一致性的目标是环境可预期、稳定、低成本。其中低成本比较关键,因为环境资源的成本一般比较高。


我们可以将运行环境分为 3 部分:制品、执行引擎和编排规则。


要保证制品的一致性,第一是保证代码及其依赖的一致性;第二是保证构建环境的一致性;最后是保证构建脚本的一致性。保证环境的一致性,也包含了三点:


  1. 应用的一致性,比如一致的容器镜像;

  2. 容器运行所需的上下文的一致性,比如一致的数据配置等;

  3. 编排规则的一致性,需要保证编排执行相同的规则,比如相同容器部署规则、相同节点分布规则、相同备份规则等。


保证这 3 点,部署完成之后才会形成一致的可运行环境。但是现实当中,环境还是会有很多其它的问题,比如:


  • 配置文件中有好多监控之类的配置,对于使用者来说,不知道配置的具体作用,需要修改时不知如何设置。

  • 测试的时候依赖的环境经常发生问题,耗费大量等待和排查时间。比如说依赖的 API 经常出问题,排查修复可能需要等待依赖方很久,导致测试工作无法继续进行。

  • 新环境的搭建很耗时。搭建一个新的环境是很痛苦的事情,比如国际化团队,经常要搭建新的站点,而每搭一个新的环境就要耗费一整天的时间是很痛苦的。

  • 应用在本地无法运行。比如因为缺某个资源导致应用无法正常运行。

  • 配置环境需要小心翼翼,可能出现配置遗漏。每次配环境的时候需要很小心,特别是当环境配置由多人配合时,会出现配置冲突,导致程序无法运行,需要全链路排查解决。


这里我们简单列了五个常见的问题,它们的根源都是环境缺乏清晰的定义:不清楚环境的具体内容、对环境搭建过程的认知模糊。


环境的清晰定义,包括环境包含什么制品、这些制品如何部署等。那么环境管理的终态是什么呢?



当制品相同、运行上下文相同,并且资源数据是一样的情况下,基于相同的编排规则,环境就应该是一致的。同时,环境可以由软件来定义和声明。这是我们认为的环境管理的终态,简单来说,即软件定义的不可变环境。软件定义的不可变环境,可以纳入版本管理,保证环境首先是定义明确的,其次是有明确版本的。

环境管理的 3 个阶段



阶段一:说明书


环境管理的第一个阶段是说明文档,这点相信很多人都经历过。当我们在做一个项目或产品时,会写整个产品的部署说明书、说明文档、升级文档等各种文档。但文档很难保证实用,也不一定是最新的、准确的。每次我们去现场交付时,都会遇到一些文档里没有描述的问题。这时候还得打电话确认,是否有遗漏什么。用文档或说明书去管理环境,存在很大的弊端,所以我们想到了用命令的方式去管理。


阶段二:命令


第二阶段,我们通过命令的方式,写了各种 shell、Python 脚本,把相关命令组合在一起。之前我们在做一个产品的私有化交付的时候,一开始的做法就是用脚本去管理环境,因为开启一个新环境实在太痛苦了,需要花很多时间改参数、找包、配 IP 等,效率太低。所以我们写了脚本来管理,用脚本代替了文档。

但是用脚本管理环境也存在很多问题。我们要应对各种各样的环境,同一个任务在不同的场景里,命令组合可能是不一样的,所以脚本会越来越多,维护脚本的成本也越来越高。


阶段三:声明


为了解决命令脚本的维护和稳定性问题,我们进入了第三个阶段,声明式——通过配置的方式表达环境,把环境定义出来。声明式的描述提供了环境的确定性表达。

以 k8s 为例,我们以一个例子来看,如何做环境声明


上图是 K8S 的简单架构,左上角是 K8S 的 master,左下角是 node,master 有好几个组件:scheduler、ControllerManager、APIserver,以及 Etcd。Etcd 是一个分布式存储,配置信息都在 Etcd 里面。Node 是物理机或者虚拟机,在每一个 Node 上面会有多个 pod,上面会运行很多的容器。


我们知道 K8S 的最小单元是 pod,里面有容器,还有各种网络存储等,通过 pod 声明去描述。声明被 apply 后,具体的事情在 controller 里面处理。

通过 sidecar 分离关注点



我们写一个应用,这个应用里面大量的代码其实与业务无关,而是包含很多服务治理的代码,例如日志、监控、限流、熔断等。这些代码占了很大的比重,而且这些代码的维护者和应用开发者不一定是同一批人。服务治理相关的代码,在很多企业会有专门的团队负责维护和升级,类似阿里的中间件团队。传统的情况下,我们需要升级并重新部署应用才能升级服务治理能力。但是在云原生时代,应用开发者希望仅关注应用业务代码,服务治理相关的代码放在其他的容器里面,业务容器和服务治理容器通常会编排在同一个 pod 里面,但是服务治理容器的管理、开发、发布都跟应用开发者没有关系,这些就是 sidecar 容器。sidecar 容器实现了关注点的分离,应用的开发者和中间件的开发者以及运维相关的开发者,都可以有自己的关注点。


我们以两个角色为例,一是业务的开发者,关注的是应用的容器,所以发布的时候,他的关注点都在应用容器这一块。二是企业的 SRE,他的关注点往往在 sidecar 的各种服务治理容器上,比如 logagent 的日志级别和采样率是否合理等。


通过 sidecar,业务开发者和 SRE 的关注点就分离了。这样分离还有一个好处,就是中间件下沉,都以 sidecar 的方式管理。一旦遇到相应的中间件需要升级,业务代码不需要做任何的改变和发布,只需要做 sidecar 的发布就好了。


我们前面提到,一致的环境需要有 3 个组成部分:相同的制品、相同的运行上下文以及相同的编排规则。相同的运行上下文,本质就是里面的配置要一致。最早我们是用文档告诉我们怎么把环境管理起来,之后用脚本,最后用环境声明。


然而,用声明式的方式定义环境也并不完美。举个具体的例子,在应用运行的时候需要有一些相应的配置,中间件、基础资源、CPU、存储等都需要配置,这样会面临一个很大的问题——环境相关的配置太多了。

环境相关的配置太多,该怎么管理好呢?

通过 IaC 来定义环境



为了解决这个问题,业内采用了 IaC 的概念(InfrastructureasCode)。早期在云机房上架的时候会用到 IaC,比如有一个新的机器过来,要装成 centos7 的系统,里面要配特定的 DNS 服务等等。这是就会定义一个声明文件,发送给 saltstack 这样的工具。现在整个环境都是通过基础设施来描述出来的,所以整个环境包括中间件的资源都是基础设施了,在范围上比原先要广的多。


从配置的角度,我们有应用配置、运维配置、基础设施运维配置,甚至软件生产过程的配置。我们把应用代码和 IaC 代码,放在两个库里面(也有放到一个库里面的,各有利弊,在此我们不展开也不评价)。


比如上图中,在 IaCRepo 里我们放了动态配置(即运行时的配置)、BaaS 配置(基础设施,如数据库、中间件存储、消息队列等)、监控配置(如监控粒度、采样频率)、发布配置等。所有的配置都声明在代码库里面,基于该声明编排的所有环境就都是一致的了。


任何事情都是有利有弊,用 IaC 的方式管理环境又会带来什么新的挑战呢?



首先是“灵活的代价”。因为所有的配置都是松散的文本,缺少统一的聚合根,导致修改者需要自己理解这些配置背后对应的依赖关系。比如某个配置项设置为 on 会开启限流,但是必须配合特定的 configMap 一起使用;比如开启了一个 Ingress 插件,但如果另一个 Rollout 插件没有开启,会无法正常工作;再比如 HPA 和 CronHPA 无法同时使用,会产生冲突。由于编写的灵活性,会导致无穷的组合形式,其组合产生的后果往往在运行时才会发现。


其次是知识的成本。IaC 将一个环境所有的配置都以文本的界面给到了开发者,但是很多配置项是需要专业背景的,比如运维相关的策略、比如监控的配置方式等等,价值 IaC 本身的学习成本,往往让很多开发者望而生畏。


为了解决这个问题,阿里联合微软一起发布了 OAM 模型,以应用为统一维度,将 IaC 包含的各类资源和角色进行了分类和聚合。



首先,OAM 引入了应用(Application)的概念,将应用的各类 IaC 配置都聚合在一起,解决其依赖问题。


其次,OAM 将 IaC 的使用者分离为:应用开发者、应用运维、基础设施运维三大角色,彼此的关注点进行了分离。


OAM 抽象和简化了 IaC 的定义和维护方式,降低开发者的学习和使用成本。


总结一下,我们认为,环境管理的终态是软件定义的不可变环境,而当下,它的最佳实践我们认为是基于 OAM 模型的、以应用为核心的 IaC 声明。


云效云原生应用管理平台 AppStack 正是基于 OAM 的应用交付平台,企业在云效 AppStack,可以通过应用编排、占位符、变量等声明式定义,实现一套编排多环境差异化部署,同时基于版本和基线实现环境一键拉起、一键回滚。感兴趣的同学点下方链接即可免费使用。


https://www.aliyun.com/product/yunxiao/appstack?channel=yy_rccb_36


下篇预告:环境管理的目标是希望有一个稳定、可预期、低成本的环境。在软件开发中,我们会涉及到开发、测试、生产各种环境,如何保证这些环境的稳定、可预期、低成本呢?下一节我们将进一步展开,敬请期待。



阅读上篇:这样才是代码管理和 Commit 的正确姿势!



发布于: 刚刚阅读数: 2
用户头像

还未添加个人签名 2021.11.05 加入

云效,云原生时代一站式BizDevOps平台,支持公共云、专有云和混合云多种部署形态,通过云原生新技术和研发新模式,助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷,打造“双敏”组织,实现 10 倍效能提升

评论

发布
暂无评论
80%的软件环境管理问题,根因都在这里 | 研发效能提升36计