建设网站好公司,长春企业建站平台,西安宝马建设科技股份有限公司网站,wordpress文字添加图片简介#xff1a;80%的软件环境管理问题#xff0c;根因都在这里#xff0c;云效云原生应用管理平台AppStack正是基于OAM的应用交付平台#xff0c;企业在云效AppStack#xff0c;可以通过应用编排、占位符、变量等声明式定义#xff0c;实现一套编排多环境差异化部署80%的软件环境管理问题根因都在这里云效云原生应用管理平台AppStack正是基于OAM的应用交付平台企业在云效AppStack可以通过应用编排、占位符、变量等声明式定义实现一套编排多环境差异化部署同时基于版本和基线实现环境一键拉起、一键回滚。 专栏策划雅纯 志愿编辑jimmy、吕瑞星
软件交付的终态是提供稳定可预期的系统要做到这一点我们需要确保一、软件制品的一致性二、运行环境的一致性。
第3讲我们分享了如何保证软件制品的一致性这一讲我们来谈谈如何保证环境的一致性。
运行环境一致性的目标是环境可预期、稳定、低成本。其中低成本比较关键因为环境资源的成本一般比较高。
我们可以将运行环境分为3部分制品、执行引擎和编排规则。 要保证制品的一致性第一是保证代码及其依赖的一致性第二是保证构建环境的一致性最后是保证构建脚本的一致性。保证环境的一致性也包含了三点
应用的一致性比如一致的容器镜像容器运行所需的上下文的一致性比如一致的数据配置等编排规则的一致性需要保证编排执行相同的规则比如相同容器部署规则、相同节点分布规则、相同备份规则等。
保证这3点部署完成之后才会形成一致的可运行环境。但是现实当中环境还是会有很多其它的问题比如
配置文件中有好多监控之类的配置对于使用者来说不知道配置的具体作用需要修改时不知如何设置。测试的时候依赖的环境经常发生问题耗费大量等待和排查时间。比如说依赖的API经常出问题排查修复可能需要等待依赖方很久导致测试工作无法继续进行。新环境的搭建很耗时。搭建一个新的环境是很痛苦的事情比如国际化团队经常要搭建新的站点而每搭一个新的环境就要耗费一整天的时间是很痛苦的。应用在本地无法运行。比如因为缺某个资源导致应用无法正常运行。配置环境需要小心翼翼可能出现配置遗漏。每次配环境的时候需要很小心特别是当环境配置由多人配合时会出现配置冲突导致程序无法运行需要全链路排查解决。
这里我们简单列了五个常见的问题它们的根源都是环境缺乏清晰的定义不清楚环境的具体内容、对环境搭建过程的认知模糊。
环境的清晰定义包括环境包含什么制品、这些制品如何部署等。那么环境管理的终态是什么呢 当制品相同、运行上下文相同并且资源数据是一样的情况下基于相同的编排规则环境就应该是一致的。同时环境可以由软件来定义和声明。这是我们认为的环境管理的终态简单来说即软件定义的不可变环境。软件定义的不可变环境可以纳入版本管理保证环境首先是定义明确的其次是有明确版本的。
环境管理的3个阶段 阶段一说明书
环境管理的第一个阶段是说明文档这点相信很多人都经历过。当我们在做一个项目或产品时会写整个产品的部署说明书、说明文档、升级文档等各种文档。但文档很难保证实用也不一定是最新的、准确的。每次我们去现场交付时都会遇到一些文档里没有描述的问题。这时候还得打电话确认是否有遗漏什么。用文档或说明书去管理环境存在很大的弊端所以我们想到了用命令的方式去管理。
阶段二命令
第二阶段我们通过命令的方式写了各种shell、Python脚本把相关命令组合在一起。之前我们在做一个产品的私有化交付的时候一开始的做法就是用脚本去管理环境因为开启一个新环境实在太痛苦了需要花很多时间改参数、找包、配IP等效率太低。所以我们写了脚本来管理用脚本代替了文档。
但是用脚本管理环境也存在很多问题。我们要应对各种各样的环境同一个任务在不同的场景里命令组合可能是不一样的所以脚本会越来越多维护脚本的成本也越来越高。
阶段三声明
为了解决命令脚本的维护和稳定性问题我们进入了第三个阶段声明式——通过配置的方式表达环境把环境定义出来。声明式的描述提供了环境的确定性表达。
以k8s为例我们以一个例子来看如何做环境声明 上图是K8S的简单架构左上角是K8S的master左下角是nodemaster有好几个组件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可以通过应用编排、占位符、变量等声明式定义实现一套编排多环境差异化部署同时基于版本和基线实现环境一键拉起、一键回滚。
原文链接
本文为阿里云原创内容未经允许不得转载。
