SRE发布工程师如何做好配置管理
配置管理是发布工程师与SRE 紧密合作的一个区域。虽然初看起来，配置管理可能很简单，但是这其实是不稳定性的一个重要来源。因此、我们的发布流程和系统运维与配置管理流程都随着时间不停地发展。今天我们使用下面几段描述的模型来分发配置文件。所有这些模型都需要将配置文件存放于我们的主要代码仓库中，同时进行严格的代码评审。使用主分支版本配置文件。这是配置Borg服务的第一个方法（以及配置Borg 之前的那些系统）。使用这个模型，开发者和SRE可以同时修改主分支上的配置文件。这些修改经过代码评审之后会应用到正在运行的系统上。这样做的结果是，二进制文件的发布与配置文件的修改是异步进行的。虽然理解起来和执行起来都比较容易，但这种方式经常会造成提交的版本和实际运行的配置文件不一致，因为任务必须要经过更新才能应用这些变更。
将配置文件与二进制文件打包在同一个MPM包中。对没有多少配置文件的项目来说，或者那些每次发布都会改变文件的项目来说，配置文件可以直接和二进制文件放在一个MPM包里。虽然这个策略在灵活性上有一定限制，但是简化了部署，仅仅需要安装一个包。
将配置文件打包成 MPM配置文件包。我们也可以将密闭原则应用到配置管理上。二进制配置文件一般与某个二进制版本紧密相关，我们也可以利用编译系统和打包系统来发布配置文件。就像二进制文件那样，可以利用构建 ID来重新构建某一时刻的配置文件。
例如，某个实现了新功能的变更可以与配置该功能的配置文件一起发布。通过打包两个MPM包，一个二进制文件，一个配置文件，可以对两个包进行单独修改。如果某个功能需要一个功能开关 first_foLio，但是我们后面发现这个开关值应该为 bad_quarto（这些是没有实际意义的名字），可以将这个变更cherry picking 到发布分支上，重新构建配置包，再实际部署。这种方式可以避免再构建一次二进制文件。
我们可以利用 MPM的标签功能选择哪些 MPM包应该同时安装。much_ado这个标签可以应用到上面那段中的 MPM包上，这样我们可以用一个标签同时获取两个版本。因为这些标签在每个 MPM 命名空间内部都是唯一的，只有最后一个包才能被用到。
从外部存储服务中读取配置文件。某些项目的配置文件需要经常改变，或者动态改变（在二进制文件运行时）。这些文件可以存放在Ch y、Bigtable或者 Google自己的基于源代码仓库的文件系统中（参见文献 【Kem11】）。
总之，项目负责人在分发和管理配置文件时有多种选择，可以按需决定究竟哪种最适合该服务。
虽然本章讨论的是 Google的发布工程的特有方法，以及发布工程师与SRE共同合作的区域，但其实这些实践适用于更广阔的范围。
页:
[1]