开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：声明式环境管理最佳实践】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13503
声明式环境管理最佳实践
内容介绍：
一. 通过 sidecar 分离关注点
二. 新的挑战
三. OAM 型
一. 通过 sidecar 分离关注点
问题：环境相关的配置太多了，我该怎么管理比较好？
答案：通过 laC 来定义环境
在云原生时代，我们讲 laC 的时候，它的技术就是使整个环境通过基础设施来描述出来。它的整个环境，包括它的中间件资源，都属于技术设施。那么这个层面就比原来单纯的上架要广得多。
从配置的角度来说，有应用配置，应用运维配置和基础设施 运维配置。甚至我们整个软件生产的过程也是用配置去合并 怎么发布，去构建。这里我们也要去做一些定义，定义作为一个软件需要符合什么样的质量，才可以在系统里以什么样的方式去运行。我们所有东西都是以代码的方式来去保管配置的， 他们的本质都是代码。
这里我们举一个简单的代码库的例子。
这里我们把应用代码和 lac 代码放在两个库里，有的人也会放到一个库里面，这两种方式各有利弊。
这里我们看到 laC Repo 里面放了一些东西，比如动态配置，就是运行时的配置。
BaaS 配置，就是技术设施资源以及数据库中间件的一些资源，比如存储、消息或中间线资源。监控配置，配置监控的力度以及监控的采样频率。发布配置，比如发布方式，每次每个批次发布间隔多少时间，还有一些策略，滚动方式，这些东西都会在里面被定义好。
二. 新的挑战
1. 灵活的代价
⑴开启这个插件还要在 ConfigMap 里定义一个变量
⑵Ingress 和 Rollout 原来要一起用才行
⑶HPA 和 CronHPA 原来是冲突的
⑷…
这些 yaml 文件仿佛原始人的火种，即使小心伺候也有熄灭的可能。
2. 知识的成本
⑴网络配置怎么有这么多种实现
⑵部署 MySQL 集群的正确姿势是什么
⑶怎么能让 Pod 用本地 SSD 磁盘
⑷…
灵活的代价，我们会尝试用一些范式来去定义出来，这样管理起来相对来说就会更事半功倍。
3. 主要矛盾在哪里？
运行一个系统，需要的技能是多方面的，但我们都把它想成配置文件这种，但是不是每个人都能用到那么多能力。而且本身它的关注点分离成好多个，但是我们用配置文件直接堆在那里，就没有把它分离出来。
在现在工业里，一般遇到这样的问题，会有怎么样的一些手段去处理他呢？
三. OAM 模型
首先，Open Application Model 是微软和阿里云联合推出的框架 ，也叫 OAM 框架 OAM 模型。其基本理论就是凯撒的归凯撒，上帝的归上帝。
这是什么意思呢？我们先看右边，在模型里面，任务是管理整个环境的配置的有三种角色。
第一种叫 Developer，就是开发应用，关注的是应用开发。
第二种叫 Application Operator，是做运营上应用上的一些运维配置。
第三种叫 Infrastructure Operator，是做基础设施的运维，负责基础设施组建这些能力的维护和开发。比如我们要做滚动发布的策略，然后有的一些资源的限制策略，这些就是在 Infrastructure Operator 里去处理的。
显然这三种人的工作背景和技能是完全不一样的，那么他们之间就必然会产生协作。如果他们之间的协作不好，就会产生我们前面遇到的问题，这些东西就会都混在一起。
所有在这个架构上，它就被抽象成了左边这个模型。
首先我们有 Application 这个应用，它是包含很多个Component 的，就是左下角的内容。每个 Component 里面都有很多容器，在 Component 里，就描述着我的协议是什么，我的容器是什么，我的端口是什么，包括一些参数在里面。
同时，右边有一个 Configuration，它会描述一些应用怎么运行起来，和应用的一些相关的配置，以及应用的用到的运维上的一些能力。
这样就把就开发者关心的东西跟应用运维关心的这些东西分成了 Component、Configuration、Triat 这三个部分。这样他们就可以去关心自己的那块就行了。
同时，在框架里面或者模型里面，会对中间或遇到出现的冲突的一些东西，做出预先的检测，这就保证这些东西不会在我发到一半的时候才出现问题。
而是可以预先把问题发现出来，就可以直接告诉你失败， 而不会影响线上的服务。
也就是说，在最早把应用给声明出来的时候，就会把相应的 OAM 模型的相应的配置给定义清楚，并且有一些配置之间需要包含的东西，哪怕加了新的配置，这些东西我们也可以提前做出一些相应的预警。另外很重要一点就是分离这一点。
