什么是基础结构即代码？

  • 10 分钟

公司要求你评估基础结构即代码是否可能是公司资源预配的重要方法。 你要查看适用于部署的选项，包括：

  • Azure 门户
  • Azure CLI
  • Azure PowerShell
  • Azure 资源管理器模板（JSON a和 Bicep）

你要寻找一个可重复的选项，并且需要决定使用哪种技术来部署 Azure 基础结构。

在本单元中，你将了解基础结构即代码帮助你以自动且可重复的方式部署 Azure 基础结构的方式和原因。

Azure CLI 命令用于说明概念。 你将详细了解如何使用命令在 Bicep 学习路径的其他模块中部署资源。

定义基础结构即代码

你的公司设计新玩具以投放市场，其中大多数新玩具在购买后需要进行组装。 公司的设计团队创建每个玩具随附的说明手册。 每个手册提供有关如何正确组装玩具的详细信息。

你可以将基础结构即代码视为类似于基础结构的说明手册。 手册详细介绍资源的最终配置以及如何达到该配置状态。

基础结构即代码是实现基础结构预配自动化的过程。 它使用描述性编码语言和版本控制系统，这与源代码类似。 创建应用程序时，源代码将在每次进行编译时生成相同的结果。 同样，基础结构即代码部署是自动化、一致且可重复的部署。 基础结构即代码可以自动部署基础结构资源，例如虚拟网络、虚拟机、应用程序和存储。

Diagram that shows the infrastructure as code process using a source code repository with a template that deploys Azure resources.

回想一下新玩具的说明手册，有多种方法可以编写说明手册。 一种选择是详细说明生成过程的每个步骤。 另一种选择是显示组装玩具所需的各个部件的分解图。 本单元的后面将介绍命令性代码和声明性代码之间的差异，以及它们与公司的说明手册的关系。

为什么使用基础结构即代码？

采用基础结构即代码方法为资源预配提供了许多好处。 使用基础结构即代码，可以：

  • 提高部署置信度。
  • 管理多个环境。
  • 更好地了解云资源。

提高置信度

使用基础结构即代码的好处之一是在一致性和安全性方面的改进中获得的部署置信度。

  • 与当前流程的集成：如果组织已在使用标准软件开发做法，则可以针对基础结构部署采用这些相同的流程。 例如，同级评审可以帮助检测进行手动更改时可能难以检测到的配置问题。

  • 一致性：采用基础结构即代码方法可帮助团队遵循完整的流程来部署基础结构。 通过遵循这些流程，责任从一小组人员转移到自动化流程和工具。 基础结构即代码有助于减少资源预配中的人为错误并确保一致的部署。

  • 自动扫描：可通过用于检查代码中的错误的自动化工具来扫描基础结构即代码配置。 自动化工具还可以查看建议的更改，以确保遵循安全做法和性能做法。

  • 机密管理：许多解决方案需要机密，如连接字符串、加密密钥、客户端机密和证书。 在 Azure 中，Azure Key Vault 是用于安全存储这些密钥的服务。 许多基础结构即代码工具可以与 Key Vault 集成，以在部署时安全地访问这些机密。

  • 访问控制：通过基础结构即代码部署，你可以选择使用托管标识或服务帐户实现资源预配自动化。 此过程确保仅通过这些标识修改云资源。 它还帮助防止不正确的配置部署到生产环境中。 如有必要，你可以使用紧急访问帐户（经常称为“破窗式帐户”）或使用 Microsoft Entra ID Privileged Identity Management 功能来覆盖此过程。

  • 避免配置偏移：幂等性是往往与基础结构即代码关联的术语。 如果是幂等运算，则意味着它在每次运行时都提供相同的结果。 如果选择使用幂等运算的工具，则可以避免配置偏移。

作为幂等性示例，请考虑以下 Azure CLI 命令。 该命令在美国东部区域中创建一个名为 storage-resource-group 的 Azure 资源组。

az group create \
  --name storage-resource-group \
  --location eastus

如果再次运行此命令，则会收到完全相同的输出，因为这个 Azure CLI 命令根据设计是幂等的。 你不会收到错误，也不会获得重复的资源组。

使用基础结构即代码时，可以在每次发布解决方案时重新部署环境。 这些版本可能包含较小的配置更改，甚至重大更新。 此过程有助于避免配置偏移。 如果对资源进行了意外更改，则可以通过重新部署配置进行更正。 通过遵循此方法，使用代码记录你的环境。

管理多个环境

许多组织维护多个应用程序环境。 玩具公司的开发人员可能在存储库中暂存了多个版本的应用程序代码，以发布到不同的环境。 这些环境可能包括开发、测试和生产。 某些组织为分布在全球的应用程序维护多个生产环境。 其他组织（例如独立软件供应商 (ISV)）为其客户维护多租户环境。

下面是基础结构即代码可帮助你管理环境的一些主要方式：

  • 预配新环境：云计算的主要优势之一是能够进行缩放。 基础结构即代码可帮助你缩放到应用程序的多个实例。 这些实例可以在负载增加时提供帮助，也可以为世界上其他区域的用户部署它们。 在测试应用程序时（例如在渗透测试、负载测试和 bug 测试期间），这种灵活性也十分有利。 使用定义明确的代码库，可以一致的方式动态预配这些新环境。

  • 非生产环境：组织面临的常见问题是生产环境和非生产环境之间的差异。 在单独的环境中手动预配资源时，最终配置可能不匹配。 例如，将新功能部署到与生产环境不同的非生产环境时。 由于两个环境之间的差异，新功能在生产环境中可能无法按预期工作。 使用基础结构即代码有助于最大程度地减少这些问题。 可以为每个环境使用相同的配置文件，但提供不同的输入参数来创建唯一性。

  • 灾难恢复：在某些情况下，基础结构即代码可以用作组织的灾难恢复计划的一部分。 例如，由于服务中断，你可能需要在另一区域中重新创建环境。 通过使用基础结构即代码，可以快速预配新实例进行故障转移，而不是手动部署和重新配置所有内容。

更好地了解云资源

基础结构即代码可帮助你更好地了解云资源的状态：

  • 审核线索：对基础结构即代码配置所做的更改采用与应用程序源代码相同的方式进行版本控制。 在你的工具中跟踪这些更改，与 Git 的版本历史记录一样。 此审核线索表示你可以查看每个更改的详细信息、执行更改的人员以及进行更改的时间。

  • 文档：可以使用多个基础结构即代码配置来添加元数据（如注释），这些元数据描述了配置中代码的用途。 如果贵组织已遵循代码文档流程，请考虑将这些相同的过程用于基础结构代码。

  • 统一系统：当开发人员多次使用新功能时，必须对应用程序代码和基础结构代码进行更改。 使用通用系统时，贵组织可以更好地了解应用程序与基础结构之间的关系。

  • 更好地了解云基础结构：使用 Azure 门户预配资源时，许多流程都是从视图中提取的。 基础结构即代码可帮助更好地了解 Azure 的工作原理以及如何解决可能出现的问题。 例如，使用 Azure 门户创建虚拟机时，某些已创建的资源是从视图中提取的。 在后台部署托管磁盘和网络接口卡。 使用基础结构即代码部署同一个虚拟机时，可以完全控制已创建的所有资源。

命令性代码和声明性代码

可以通过不同的方式为新玩具组装编写说明手册。 自动部署服务和基础结构时，可以采用两种方法：命令性和声明性。

  • 使用命令性代码，可以按特定顺序执行一系列命令，以实现最终配置。 此过程定义代码应该完成的内容，并定义如何完成任务。 命令性方法与分步说明手册类似。

  • 使用声明性代码，可以仅指定最终配置。 代码未定义如何完成任务。 声明性方法与分解图说明手册类似。

对资源预配选择使用命令性方法还是声明性方法时，请考虑组织中可能已在使用的工具。 另请考虑哪种方法可能匹配你自己的技能。

强制性代码

在 Azure 中，命令性代码方法是使用脚本语言（如 Bash 或 Azure PowerShell）通过编程方式完成的。 脚本执行一系列步骤来创建、修改甚至删除资源。

此示例演示了两个创建资源组和存储帐户的 Azure CLI 命令。

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

第一个命令在美国东部区域中创建一个名为 storage-resource-group 的资源组。 第二个命令在 storage-resource-group 资源组（已在第一个命令中创建）中创建一个名为 mystorageaccount 的存储帐户。 第二个命令还配置存储帐户的一些属性，包括存储帐户类型及其访问层。

可以使用命令性方法完全自动执行资源预配，但此方法有一些缺点。 随着体系结构的发展，管理脚本变得越来越复杂。 命令可能会更新或弃用，这需要评审现有脚本。

声明性代码

在 Azure 中，声明性代码方法是使用模板完成的。 有许多类型的模板可用，包括：

  • JSON
  • Bicep
  • Ansible，由 RedHat 提供
  • Terraform，由 HashiCorp 提供

注意

本模块重点介绍如何使用 Bicep 模板。

请查看下面配置存储帐户的 Bicep 模板的示例。 存储帐户的配置与 Azure CLI 示例匹配。

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

资源部分定义存储帐户配置。 本部分包含存储帐户的名称、位置和属性，包括其 SKU 和所属的帐户类型。

你可能会注意到，Bicep 模板未指定如何部署存储帐户。 它仅指定存储帐户所需的外观。 在后台执行的用于创建此存储帐户或更新它以匹配规范的实际步骤留给 Azure 决定。