开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：声明式环境管理最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1274
声明式环境管理最佳实践
内容介绍：
一、通过 IaC 来定义环境
二、新的挑战
三、Open Application Model（OAM 模型）
四、总结
一、通过 IaC 来定义环境
对于 IaC 的概念理解，例如云机房的上架会用到 IaC，这是早期接触的。
比如给一个新的机器装配 Windows7 的系统，并配有 DNS 等，按照原有的方式一条一条命令发布会很麻烦。
可以定义一个文件，例如杨某文件再搜索 step 这类工具将它建立起来。现如今云原生再讲 IaC 时可以将整个环境通过基础设施描述出来，包括中间线资源都属于基础设施，这比原有单纯的上架涉及要广。从整个配置的角度来看，有应用配置、应用运维配置、基础设施运维配置。对于整体软件生产的过程也是需要配置，例如怎么合并、怎么发布、怎么构建。
例如作为一个软件，需要符合怎样的质量才能在系统中，以怎样的方式去运行。其中的配置都可以用代码的方式保管，将其保存在代码库中。
举个简单的代码库的示例，将应用代码和 IaC 代码分成两个库，也会有放在一个库中。
例如所看到的在 IaC Repo 中放入动态配置（运行时的配置）、Baas 配置（基础设施资源所依赖的数据库，中间键资源，比如存储，消息队列）、监控配置（监控的力度，监控的采样频率）、发布配置（以金丝雀的发布方式，对于每个批次的间隔时间，发布策略，发布形式的定义），通过这样的方式管理放在代码库中可以完成的很好。
二、新的挑战
1、灵活的代价
每一种组件，都有自己的配置方式，例如开发一个插件可以用于限流，或者做一个资源水位的管控，或是超卖的管控，开启这个插件需要在ConfigMap 中定义一个变量。需要将 Ingress 和 Rollout 放在一起工作才能完成。
如果同时使用 HPA 和 CronHPA 会引起冲突，在中途会出现错误。这些 yaml 文件仿佛原始人的火种，即使小心伺候也有熄灭的可能。
2、知识的成本
网络配置存在有很多种，不清楚怎样去选择实现。在机械应用中MYSQL 设计时没有考虑 HBase 这样的场景，对于 HBase 并不是很友好，不清楚 MYSQL 集群该怎样去部署。
例如在阿里云买了一个 Pod 的机群，但是需要大数据的处理能力，并且需要很快绑定 SSD 磁盘，但是不清楚怎么能将它们联系在一起。下面是对源代码的展示，go 语言存在200多万代码，需要了解清楚如何放置和组织。
例如灵活的代价，尝试着用范式定义这样管理会比较省时省力。
三、Open Application Model（OAM 模型）
凯撒的归凯撒，上帝的归上帝。
对于下面环境配置的管理，有三种角色，第一种是 Developer 开发者，关注的是应用开发，第二种是 Application Operator 应用运维，开发者会去做运营上应用的运维配置，例如应用线轴。第三种是 Infrastructure Operator 基础设施运维，对组建能力的维护和开发。例如做滚动发布需要发布策略，手里资源的限制策略，这些需要在 Infrastructure 处理。
这三种角色的技能背景和技能战术是完全不一样的，他们之间必然会产生协作，如果他们之间协作不好，会产生前面所遇到的问题。在这个架构中把抽象形的左边内容，每个 component 里面包含需要的参数和描述，同时右边的配置 application 和另一个配置的 configuration，描述如何应用的一些相关的配置，同时也会描述 Triat。
将开发者关心的、应用运维关心的和技术设置有关的分成三块，一个是 component 另一个是 application configuration 部分以及 Triat 部分分成三块。
同时在框架或者模型中对它们之间会出现的冲突做了预先的检测，保证中间不会出现问题。这样预先找到错误不会对线上服务有很大影响。提前给出应用说明将 OAM 模型相应的配置定义清楚，并提前做一些相应的预警，只有组合在一起才能够替换。另外重要的一点是分离。
四、总结
前半部分基本介绍周围一致的环境包含什么，并且怎样去维护环境，维护环境是可以用 IaC 的方式，引用 OAM 模型去管理这些配置。回到环境本质还是希望能够有一个稳定可预期并且低成本的环境。
