开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：不可变环境：打造:稳定、可预期低成本的运行环境】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1272
不可变环境：打造:稳定、可预期低成本的运行环境
内容介绍
一、回顾
二、 终态治理的环境
三、环境管理
一、回顾
本节课讲解开发运行的基础设施，整个课程会围绕着普遍基础设施实际交付流水线，还有安全性发布，简单回顾一下之前的讲解内容，首先讲一个不可变构建一个概念，就是说希望是相同的源码在相同的环境上用相同的构建脚本，它所产生的软件制品是一致的，那么这个这个概念可能看起来好像就是一个正确的废话，但是其实很多时候自己去检视一下现在的工作，会发现真正能够做到相同源码，相同环境，相同课件脚本，其实是有很多的难度，很多的事情仍需要去努力。
那第二个是去把这个构建做好，认为应该要通过 Dockfile 的方式去描述构建环境，构建脚本以及运行环境，这样能够很好做到不可变的构建。
第三个是作为容器的一个基本的一个要求叫 One process 和 per container，一个容器就是一个进程，这个是一个容器的基本概念，
如果在容器中它的是 One process 和 per container，那可能需要做一些调整，第四个提到那个代码代码库和代码组织是一个结构上，就是我觉得应该按照一个逻辑单库的一个概念去组织代码库和代码组，那这样的话它才能够以更好的一个组织形态去协作，一起去把它更好的维护好。
接下来，是在有代码组和代码库的情况下，做好代码提交，代码软件交付，它本质上是一个代码围绕代码库的一个协作过程，所以这个代码提交的希望是 SLA 及Small、Linear、 Atomic 就是又小又线性，有原子化的去提交代码。最后一个提到就是将环境相关的配置与镜像分离，这个就是上回 part one 所有的整个的一个内容的回顾。
不可变构建:相同的源码+相同的环境+相同的构建脚本=>一致的软件制品
通过 Dockerfile 描述构建环境、构建脚本及运行环境
One process 和 per container
按逻辑单库的结构组织代码库和代码组
软件交付过程，其本质是开发者围绕代码库的协作过程，按 SLA(Small、Linear、 Atomic)的原则提交代码
将环境相关的配置与镜像分离
二、终态治理的环境
对运行环境相关的配置属于哪一层，是配置越靠里成本越高，在终态中希望提供一个稳定可预期的一个运行的一个系统。要做到这一个有两点，一个是确保运行环境的一致性，还有另外一个软件制品的一致性，而针对这个运输环境，应该有一个目标，那比如说要去做到环境的可预期稳定，那环境应该有一个很重要的一个目标除了稳定可预期，另外一个很重要一点就是低成本。因为环境这种资源相对来说成本相对来说比较高，所以说要强调低成本这一点。
其实整个运行环境来说，在这整个角度来说，其实它分为三部分，要保证一致性的话，第一个要代码及其依赖的一致性，或者说相同的另外一个构建环境的一致性，另外一个就是构建脚本。
那么从环境的角度来说，第一个就是应用所服务的一个制品，比如说像容器镜像，还有另外一个是逻辑性上它要运行起来的这样一个一个商家的人员，比如说像数据配置相关的，那另外一个就是说怎么在上面跑，它的一个编排一个规则，部署在哪些容器里，或者说在哪些机器上哪些节点。
这些东西通过一个部署的一个动作营造了一个环境。这是部署完之后才会形成一个可运行的环境。但现实当中在环境这里还是会有很多的问题的，通过跟各个各个团队沟通，发现就是说环境这个问题往往是一个痛点，会产生以下常见问题：
1、配置文件中有好多监控之类的配置，我不知道该怎么设置？
比如说配置文件中有好多监控相关的配置，这个配置不懂，因为写业务代码的，不知道这个东西是干什么的，但是他又在那里好像还要动它，不知道怎么设置
2、测试依赖的环境经常发生问题，耗费大量的等待和排查时间
那个测试的时候依赖的环境经常发生问题，比如依赖一个API这个 Api经常挂了，那么这个时候就要去排查，可能还要等待那个对方的修复，等到这个时间就很长，然后有可能就是因为这个问题，可能要查一天，可能还做不了一次测试
3、搭建一套新的环境很痛苦，经常需要耗费整天的时间
要搭一个新的环境，这个是很痛苦的事情，比如说像国际化这种团队，他经常要去一个新的站点，那搭一个新的环境，可能要copy一整天的时间，这个是很痛苦的一个事情。
4、开发的应用在本地跑不起来
这个很常见，就是说我的应用在本地跑不起来，缺这个缺那个但是有这个资源的要求，所以跑不起来。
5、每次配置环境都需要小心翼翼，生怕漏修改了某个配置
每次退环境的时候都很小心，因为很有可能就漏了一个配置，然后就跑不起来了，或者会出什么错。举个例子，因为之前在一些小公司的，去客户那里就是去做测试，然后环境是前一个同学可能会先去布上，然后后一同学过来的时候他也不知道改什么，可能他们有人去改了一下，改了一下发现在下一个人过来的时候，发现有的服务怎么跑不下来，其实服务已经出问题，但是他不知道，然后就发现他要做的事情做不了，再去改又出问题，所以整个排查也很麻烦，整条链路都要走一遍。
所以说这里只是简单列出了5个常见的1个问题，问题的本质是:环境没有清晰的定义,所谓的环境其实是一个属于混沌的一个过程，就是他是很多人做过很多事情，最后达到了这么一个效果，那这个效果到底是怎么来的，其实不知道，所以包含什么也不知道，然后这就造成说环境是个不清晰的，那因为环境不清晰就带来很多很多的问题，不管是排查也好，去创建新环境也好，都会带很多问题。
所以说没有清晰的定义，指的是说环境里头应该包含什么，包含到这些东西，怎么部署起来的，那么这些东西都需要有一个明确的定义。 所以说环境管理的状态应该是软件定义的一个不可变的环节。是可以被定义出来的，那这个定义是个明确的一致的。
所以相同的认为就是当制品相同的时候，有相同的运行上下的资源，数据是一样的情况下，基于相同的编排规则，那环境就应该是一致的，就是这个时候它的环境在任何一个地方，比如物理的那个地方，它其实都是一样的，不会有相当的偏差，那这个就是认为环境管理的一个状态。如上图左边的东西其实是可以通过版本代码库版本管理的这种方式，然后给它定义出来。 那么这样的话，环境它基本上第一个是定义明确的，第二个是有明确版本的，所以说这样就可以保证不同的版本它的环境的一致性在那个版本应该是一致的。
其实它最后对应的也是一个一个文件或者 commit，它是有版本的，最后这个环境可以说也是有一个版本的。
