基础架构与配置代码

环境中的应用程序或服务的现代堆栈是什么样子的？

在这里，云原生项目组织包含了其中很多贡献者的想法。

https://github.com/cncf/landscape/

下面一组是用于提供可变基础设施的技术的子集，包括图中其他地方的许多部分。那就是基础设施作为代码，现在已经很容易理解了。这些 salt/ansible/puppet/chef scripts都在源代码控制之下，或者您的做法非常错误。

上面的组在图中标题为协调和服务发现。考虑到功能标志和其他辅助实时应用程序和服务设置应该保存在相同的系统中，我认为分组应该是“代码配置”。

以下是我如何看待环境中应用程序或服务的现代堆栈:

从以前的博客条目: 配置、部署和应用程序配置周期。

配置、部署和应用程序配置周期

在我看来:

以下是一个简单的假设环境的示意图:

在我详细介绍之前，有必要了解一下持续交付管道思维背后的理论基础。

Infrastructure as Code

对于非活动环境，您应该在源代码控制下维护蓝图脚本，这些脚本可以从头创建或重新创建整个环境。这应该包括分配虚拟机、安装所需的包(Apache、 Tomcat、 MySql、反向代理、负载平衡器) ，这些都是普通虚拟机上所选择的基础操作系统所不具备的。也许是“平台”这个词所暗示的一切。你还可以在虚拟机内部连接防火墙，域名解析系统。包的配置也在这里。例如 Apache 的 httpd.conf。

对于生产，您也可以使用蓝图脚本，但是实际上只能按照 CD 最佳实践进行 delta 式的更改。至少你已经上线了。

所讨论的源代码控制回购只包含基础结构作为代码。也许每个环境只有一个分支，也许没有。模板化也可以算出:

my_provision QA3 --from templates/one_vm_fewest_processes.yaml

有时企业需要一个自助服务门户进行配置。如果命令行工具在功能上一样好，我不确定是否需要这样做。

虽然 Terraform 是新的和非常酷的，但是同事 Jefferson Girao，David McHoull 和 Deluan Quintao 在九个月前使用 Anble 完成了一个伟大的蓝图实现。

来自该项目的 Github repo，一个“宠物商店”应用程序(两个 VM)的 YAML 蓝图示例:

# This playbook deploys the whole application stack in this site.- name: apply common configuration to all nodes  hosts: all  roles:    - common- name: configure and deploy the web-servers and application code  hosts:    - www.petshop.example.com  roles:    - ruby19    - passenger    - nginx- name: deploy MySQL and configure the databases  hosts:    - db.petshop.example.com  roles:    - mysql

应用程序二进制部署

您可能有 Jenkins 01到 Jenkins 10的环境，Jenkins-CI 在进入构建管道的“完整堆栈”Selenium 阶段之前将其部署到每次提交中。人类不会进入那些。持续集成循环中的一些团队，可能希望在每个部署和 Selenium 测试阶段提供一个新的临时环境，但是我认为您不需要这样做——它们可以在这个上下文中重用。

定期部署到 QA1、 QA2或 UAT，可以通过在 Jenkins 中单击按钮实现。至少，在选择了二进制(比如 rel-1.1-build-12345)和环境之后。除了简单的 app-XXX 应用程序版本 N.n 进入 YYY 环境-拥有一个命令行等价物将会取悦开发团队中更多的技术成员。一些公司想要一个用于部署的门户，而不是便宜的 Jenkins 实现。该门户中最少的选择——“您是否被授权(重新)部署?”“哪个版本的应用程序?”还有“去哪儿?”将是对部署门户的最小控制。

您可以在 QA 环境中使用 CD 样式的自动部署。只有在重新部署不能使环境暂时可用的情况下。如果部署上的不稳定确实发生了，那么可能只有在约定的时间才会发生重新部署。CD，对于最先进的团队，当然意味着部署到生产环境中。

应用程序二进制文件只能发生在已经正确配置的环境中。这意味着基础设施作为代码的事情已经发生了，如果这还不是很明显的话。如果环境配置和应用程序二进制部署在没有配置的情况下发生(见下文) ，那么在这个阶段环境不可用。

其中哪些部分处于源代码控制之下？

除了常规的构建脚本，我还希望看到完整的 CI 管道定义。CruiseControl 过去就是这么做的，我希望詹金斯这样的人也能这么做(就像我曾经对詹金斯的创造者川口浩介(Kohsuke Kawaguchi)说的那样)。构建的产品-应用程序二进制本身？许多企业应该将二进制文件放在防篡改的存储库(而不是源代码控制)中，然后将它们从存储库中提取出来进行部署。一些高水平的 CD 团队不会为此烦恼。相反，他们会在构建/测试周期结束时部署，并丢弃二进制文件。

Configuration as Code

问题: 即使在重新部署二进制文件之后，您也希望此应用程序配置保留在环境中。最好的办法是什么？

已安装的应用程序可以在正交更改时接收配置。这可以是二进制切换，如果您正在进行暗部署或可以关闭应用程序的非关键部分，以提高性能(或抵御攻击)。还可以考虑更多的设置(JSON) :

"first_line_support": {  "cell": "415 867 5309",  "name": "Jenny"}

如果你在一个堆栈上进行穷人负载平衡，你也可以在这个类别的 config (JSON)中编码端点信息:

"zipcode_service": [	{    "name": "zipcodez.qa2.sandwichcorp.com",    "port": 33452,    "state": "active"  }, {    "name": "zipcodez02.qa2.sandwichcorp.com",    "port": 11233,    "state": "active"		  }, {    "name": "zipcodez.qa2.sandwichcorp.com",    "port": 44444,    "state": "suspended"			}]

你希望这些东西在源代码控制之下(再次单独回购)。环境的概念意味着应用程序配置方差和二进制方差。因此，您需要在每个环境中使用一个分支(也许不是所有的 Jenkins XX 分支)。如果需要，这将允许您在环境之间合并键和/或值。高度成熟的 CD 团队将使新的密钥在一个不理解它们的系统上善意地运行，这样它们就可以提前实现。您可以将更改提升为一个集合，或者单独提升(初选)。

注意: Zookeep 和 Etcd 解决了同样的问题，但是除非源代码控制是底层系统，并且是往返的，否则我不会感到舒服。

App config 还需要什么？

App Config 还能是什么？

合作伙伴和第三方互操作配置，无论是一个或两个合作伙伴，还是数万个合作伙伴。专业服务团队可能会维护每个版本，并希望从二进制版本解耦的启动周期，这正是 Configuration as Code 所促进的。

内容管理也在我的脑海中浮现。源代码管理分支可以是允许协调“内容”更改的地方，也可以是在最终提升(合并)到生产之前以某种方式获得批准的地方。区分也有帮助，无论是在内容的协调返工期间，还是在推广活动结束之前(作为最后的验证阶段)。

对比三个生命周期

Infra as Code 和 AppBinary Deployments 当然是传统管道视图的一部分。但是，作为代码的配置生命周期却不是这样。它与此正交，但对于应用程序的一致性至关重要。

前两个是由开发人员和 DevOps 专家加入到源代码控制中的。Config as Code 是针对生产准备状态的更精细的以人为中心的管理的一部分。许多非开发人员将参与获得正确的配置。也许他们会在为维护配置而构建的 web 应用程序中这样做(我们使用 AngularJS 来廉价地实现对我构建的概念 Logan 的验证所需的验证)。源代码控制给你安全-跟踪什么改变了，什么时候改变了，谁改变了，是否改变了战争。事实上(回到命令行，有一些硬核工具可以恢复选择的更改)。

进一步阅读

当然，我正在重新讨论之前的想法和图片: 请参考专业服务团队的 CD 时代的应用程序架构，以及我的博客类别的各种代码配置。