【DevOps】 基于数据驱动的Azure DevOps案例实现
推荐超级课程：
@TOC
客户场景：
为大量客户提供基于Azure云的成果物重复部署服务。这可能涉及到现有应用程序的更新和新版本。协助开发一个具有以下特点的新系统：
- 自动化发布
- 提供模板化的方法来部署和配置新版本
- 允许重用现有版本
- 提供对部署成果物进行元数据标记的功能
- 采用数据驱动的方法来生成成果物
- 对非IT员工来说易于使用
在研究了众多商业可用的部署管理产品后，该合作伙伴希望与开发一个定制的内部系统。他们表示希望摆脱“脚本管理业务”，并希望有一个新的系统，该系统具有基于Web的界面，非IT员工可以使用该界面将应用程序和系统部署到Azure的新旧订阅中。 最后两个要求意味着BICEP和ARM不能成为他们新系统的主要组件。他们希望有一个部署管理系统，可以抽象掉部署脚本制作的复杂性。
解决方案：
考虑到这一点，决定构建新的部署管理系统，启动了一个POC来证明架构方法并展示用户友好的功能。
架构：
POC开发的架构如下所示：
POC架构的主要组件：
- Azure Web App – 简单的SPA，提供Web界面以启动示例部署
- Azure SQL Database – 提供数据结构，以表示示例部署背后的所有数据对象
- Azure DevOps – 创建了一个构建管道来接收部署请求，以及一个发布管道来完成请求的部署。选择Azure DevOps而不是GitHub是出于客户的偏好
架构细节：
Web App前端 – 一个简单的ASP.Net SPA，提供一个Web页面来启动示例部署。向Azure DevOps发起REST API调用以启动构建管道。解析HTTP响应体以向用户显示管道的状态。HTTP响应体还包含一个URL链接，也显示给用户，允许他们跳过ADO并进一步调查发布的状态。 为了在Web页面和ADO之间进行身份验证，使用了个人访问令牌（PAT），因为从POC的角度来看，这是配置安全的最快、最简单的途径。 图2下面提供了此REST API调用的代码片段：
为了正确授权启动构建管道的REST调用，第51行从项目的配置文件中检索PAT字符串并将其添加到HTTP请求头中，而第55行检索ADO构建管道的URL以用于HTTP请求。请注意，在第54行，所有启动ADO管道的REST API调用都必须使用POST动词。 图3提供了一个代码片段，演示了如何解析HTTP响应体以向用户提供管道的初始状态：
HTTP响应被转换为JSON对象，这允许通过元素名称进行轻松索引。第66行检索用于显示的初始管道状态，而第68行检索用于相同目的的ADO管道状态URL。
数据库后端 – 该合作伙伴特别要求他们的新发布系统采用数据驱动的方法。他们希望轻松地在客户之间共享发布和部署，同时保持它们的独特性和针对每个客户的定制化。他们认为关系后端是满足这些要求的最佳解决方案。
后端的一般方法是为每种类型的Azure资源存储通用BICEP模板。将通过每个模板中的占位符标签来实现定制，这些标签将在运行时用每个客户部署的特定值替换。虽然参数文件是一个可能的替代方案，但在POC期间遇到了挑战，这推动了目前描述的架构。
除了客户特定的参数之外，合作伙伴还希望能够将一对多的元数据标签应用到每个部署的成果物上。这些将有助于生产后的计费和报告。因此，除了每个成果物参数的表之外，还应该有一个额外的表来关联成果物和标签。
以下图显示了POC中使用的关联数据模型：
如图4所示，Customers和CusomerModels表表示客户和客户模型之间的关系，客户可以有多个模型进行部署，每个模型都通过名称和唯一编号进行标识。
每个模型将包含一个或多个要部署的Azure成果物。这种关系由CustomerModelComponents表表示。
对于要部署的每个组件，OptraMetaModel表中都会有一个条目。该表中的每一行都包含生成特定Azure成果物所需的通用BICEP脚本，以及部署过程中要应用于Azure成果物的任何所需标签。Azure成果物由ResourceType列标识，该列是从AzureResources表的外键。
最后，CustomerModelComponentParms表为OptraMetaModel表中包含的脚本中的每个参数（s）提供要使用的值，允许在客户和部署之间重用模型，每个模型都有一组唯一的参数。
应该注意的是，此数据库架构需要根据生产场景进行扩展。例如，当前架构只允许将单个标签应用到每个部署的成果物上。这是为了快速完成。对于生产，需要额外的表来允许将多个标签应用到每个成果物上。
构建和发布管道 – 如前所述，发布过程由Azure DevOps中的构建和发布管道共同完成。我们将在以下段落中仔细研究这两个管道。
构建管道执行两个主要功能。第一个是根据用户请求的参数检索所有必要的BICEP模板。第二个是将它们编译成可部署的模板，供发布管道使用。此过程的整体流程如图5所示：
以下图显示了发布管道的YAML代码片段：
如您所见，构建管道中的大部分处理都是通过内联PowerShell脚本完成的。在此代码片段中，第28行到第35行显示了用于检索由客户编号传递给管道的BICEP脚本的SQL select命令。在实际场景中，用户将从网页上的屏幕选择中选出客户名称和模型编号以进行部署。为了在POC的时间限制内操作，数据库中创建了一个客户和一个模型。因此，从REST API调用中向管道传递了一个硬编码的客户编号。
同样，图7中第43行到第50行的SQL检索与所需客户模型相关联的参数。
作为此管道第一个任务的一部分的最后一步，图8展示了PWS脚本如何解析BICEP脚本的每一行。在第67行，它尝试将脚本中的参数名称与从CustomerModelComponentParms表中检索的参数名称进行匹配。如果找到匹配项，则第68行将占位符标签替换为表中的参数值。
如图9所示，管道中的下一个任务调用Azure CLI命令来构建第一步中生成的BICEP脚本。第91行调用CLI命令。请注意输入和输出文件的位置。
如图10所示，构建管道中的最后一个任务从上一个任务中获取编译的BICEP文件并将其发布，供发布管道使用。
与构建管道相比，发布管道相当简单，只有一个步骤和任务。 图11展示了发布管道的YAML，其中发布管道中的编译BICEP脚本被ARM模板部署任务接收。请注意，POC中Azure资源组和位置是硬编码的。这些值在生产环境中需要参数化。
结论
POC能够证明Azure资源的部署可以是数据驱动的、可定制的和可重复的。它在一组Azure资源被部署到给定的资源组后，由用户从Web页面发起操作。