Azure Resource Manager 概述

应用程序的基础结构通常由许多组件构成:可能有虚拟机、存储帐户和虚拟网络,或 Web 应用、数据库、数据库服务器和第三方服务。 这些组件不会以独立的实体出现,而是以单个实体的相关部件和依赖部件出现。 如果希望以组的方式部署、管理和监视这些这些组件, 那么,可以使用 Azure 资源管理器以组的方式处理解决方案中的资源。 可以通过一个协调的操作为解决方案部署、更新或删除所有资源。 可以使用一个模板来完成部署,该模板适用于不同的环境,例如测试、过渡和生产。 资源管理器提供安全、审核和标记功能,以帮助你在部署后管理资源。

术语

如果不熟悉 Azure 资源管理器,则可能不熟悉某些术语。

  • 资源 - 可通过 Azure 获取的可管理项。 部分常见资源包括虚拟机、存储帐户、Web 应用、数据库和虚拟网络,但这只是其中一小部分。
  • 资源组 - 一个容器,用于保存 Azure 解决方案的相关资源。 资源组可以包含解决方案的所有资源,也可以只包含以组的形式进行管理的资源。 根据对组织有利的原则,决定如何将资源分配到资源组。 请参阅 资源组
  • 资源提供程序 — 一种服务,提供可以通过 Resource Manager 进行部署和管理的资源。 每个资源提供程序提供用于处理所部署资源的操作。 部分常见资源提供程序包括 Microsoft.Compute(提供虚拟机资源)、Microsoft.Storage(提供存储帐户资源)和 Microsoft.Web(提供与 Web 应用相关的资源)。 请参阅 资源提供程序
  • Resource Manager 模板 — 一个 JavaScript 对象表示法 (JSON) 文件,用于定义一个或多个要部署到资源组的资源。 它也会定义所部署资源之间的依赖关系。 使用模板能够以一致方式反复部署资源。 请参阅 模板部署
  • 声明性语法 - 一种语法,允许声明“以下是我想要创建的项目”,而不需要编写一系列编程命令来进行创建。 Resource Manager 模板便是声明性语法的其中一个示例。 在该文件中,可以定义要部署到 Azure 的基础结构的属性。

使用 Resource Manager 的优势

Resource Manager 提供多种优势:

  • 可以以组的形式部署、管理和监视解决方案的所有资源,而不是单独处理这些资源。
  • 可以在整个开发生命周期内重复部署解决方案,并确保以一致的状态部署资源。
  • 可以通过声明性模板而非脚本来管理基础结构。
  • 可以定义各资源之间的依赖关系,以便按正确的顺序进行部署。
  • 可以将访问控制应用到资源组中的所有服务,因为基于角色的访问控制 (RBAC) 已在本机集成到管理平台。
  • 可以将标记应用到资源,以逻辑方式组织订阅中的所有资源。
  • 可以通过查看一组共享相同标记的资源的成本来明确组织的帐单。

Resource Manager 提供了一种新方法来部署和管理解决方案。 如果使用早期的部署模型并想要了解这些更改,请参阅了解 Resource Manager 部署和经典部署

一致的管理层

Resource Manager 提供一致的管理层,用于管理通过 Azure PowerShell、Azure CLI、Azure 门户、REST API 和开发工具执行的任务。 所有工具使用一组通用操作。 可以使用最合适的工具,并且可以换用这些工具而不发生混淆。

下图显示了这些工具如何与同等的 Azure Resource Manager API 交互。 API 将请求传递给 Resource Manager 服务,后者对请求进行身份验证和授权。 Resource Manager 随后将请求路由到相应的资源提供程序。

Resource Manager 请求模型

指南

以下建议将帮助你在使用解决方案时充分利用 Resource Manager。

  1. 通过 Resource Manager 模板中的声明性语法而不是强制性的命令来定义和部署基础结构。
  2. 在模板中定义所有部署和配置步骤。 在设置解决方案时不应执行手动步骤。
  3. 运行强制性命令来管理资源,例如启动或停止应用或计算机。
  4. 排列资源组中具有相同生命周期的资源。 使用标记来组织其他所有资源。

有关企业可如何使用 Resource Manager 有效管理订阅的指南,请参阅 Azure 企业基架 - 出于合规目的监管订阅

资源组

定义资源组时,需要考虑以下几个重要因素:

  1. 组中的所有资源应该共享相同的生命周期。 一起部署、更新和删除这些资源。 如果某个资源(例如数据库服务器)需要采用不同的部署周期,则它应在另一个资源组中。
  2. 每个资源只能在一个资源组中。
  3. 随时可以在资源组添加或删除资源。
  4. 可以将资源从一个资源组移到另一个组。 有关详细信息,请参阅将资源移到新资源组或订阅
  5. 资源组可以包含位于不同区域的资源。
  6. 资源组可用于划分对管理操作的访问控制。
  7. 资源可与其他资源组中的资源进行交互。 两个资源相关但并不共享相同生命周期时(例如,连接到数据库的 Web 应用),这种交互会很常见。

创建资源组时,需要为该资源组提供一个位置。 你可能想知道,“为什么资源组需要一个位置? 以及,如果资源可以具有与资源组不同的位置,资源组的位置应该不重要啊? ” 资源组存储与资源有关的元数据。 因此,当指定资源组的位置时,也就指定了元数据的存储位置。 出于合规性原因,可能需要确保数据存储在某一特定区域。

资源提供程序

每个资源提供程序都会提供一组用于 Azure 服务的资源和操作。 例如,若要存储密钥和密码,可以使用 Microsoft.KeyVault 资源提供程序。 此资源提供程序提供名为“保管库”的资源类型,用于创建密钥保管库。

资源类型的名称采用以下格式:{resource-provider}/{resource-type}。 例如,Key Vault 类型为 Microsoft.KeyVault/vaults

开始部署资源之前,应了解可用的资源提供程序。 了解资源提供程序和资源的名称可帮助定义想要部署到 Azure 的资源。 此外,还需要知道每种资源类型的有效位置和 API 版本。 有关详细信息,请参阅资源提供程序和类型

模板部署

使用 Resource Manager 可以创建(JSON 格式的)模板,用于定义 Azure 解决方案的基础结构和配置。 使用模板,可以在解决方案的整个生命周期内重复部署该解决方案,确保以一致的状态部署资源。 从门户创建解决方案时,该解决方案会自动包含部署模板。 无需从头开始创建模板,因为可以从解决方案的模板着手,并根据特定需求自定义该模板。 可以通过导出资源组的当前状态或查看特定部署所用的模板,来检索现有资源组的模板。 查看导出的模板是了解模板语法的有用方法。

若要了解模板的格式及其构造方法,请参阅创建第一个 Azure 资源管理器模板。 若要查看资源类型的 JSON 语法,请参阅定义 Azure Resource Manager 模板中的资源

Resource Manager 像处理其他任何请求一样处理模板(请参阅一致的管理层图像)。 它会分析模板,并将其语法转换为相应资源提供程序所需的 REST API 操作。 例如,当 Resource Manager 收到具有以下资源定义的模板时:

"resources": [
  {
    "apiVersion": "2016-01-01",
    "type": "Microsoft.Storage/storageAccounts",
    "name": "mystorageaccount",
    "location": "chinanorth",
    "sku": {
      "name": "Standard_LRS"
    },
    "kind": "Storage",
    "properties": {
    }
  }
]

它会将该定义转换为以下 REST API 操作,然后,该操作将发送到 Microsoft.Storage 资源提供程序:

PUT
https://management.chinacloudapi.cn/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/mystorageaccount?api-version=2016-01-01
REQUEST BODY
{
  "location": "chinanorth",
  "properties": {
  }
  "sku": {
    "name": "Standard_LRS"
  },   
  "kind": "Storage"
}

模板和资源组的定义方式完全取决于用户及其所需的解决方案管理方式。 例如,可以通过单个模板在单个资源组中部署三层式应用程序。

三层模板

但是,无需在单个模板中定义整个基础结构。 通常,合理的做法是将部署要求划分成一组有针对性的模板。 可以轻松地将这些模板重复用于不同的解决方案。 若要部署特定的解决方案,请创建链接所有所需模板的主模板。 下图显示如何通过包含三个嵌套模板的父模板部署三层式解决方案。

嵌套层模板

如果希望层具有不同的生命周期,可将这三个层部署到不同的资源组。 请注意,资源仍可链接到其他资源组中的资源。

层模板

有关嵌套模板的信息,请参阅将链接模板与 Azure 资源管理器配合使用

Azure Resource Manager 会分析依赖关系,以确保按正确的顺序创建资源。 如果一个资源依赖于另一个资源(例如虚拟机需要存储帐户才能访问磁盘)中的值,请设置依赖关系。 有关详细信息,请参阅在 Azure Resource Manager 模板中定义依赖关系

还可以使用模板对基础结构进行更新。 例如,可以将新的资源添加到应用程序,并为已部署的资源添加配置规则。 如果模板指定要创建资源,但该资源已存在,则 Azure Resource Manager 会执行更新而不是创建新资产。 Azure Resource Manager 会将现有资产更新到相同状态,就如同该资产是新建的一样。

如果需要其他操作(例如,安装未包含在安装程序中的特定软件)时,Resource Manager 可提供所需的扩展。 如果已在使用配置管理服务(如 DSC、Chef 或 Puppet),则可以使用扩展来继续处理该服务。 有关虚拟机扩展的信息,请参阅关于虚拟机扩展和功能

最后,该模板成为应用程序源代码的一部分。 可以将它签入源代码存储库,并随着应用程序的发展更新该模板。 可以通过 Visual Studio 编辑模板。

定义模板后,即可将资源部署到 Azure。 有关部署资源的命令,请参阅:

标记

资源管理器提供了标记功能,可根据管理或计费要求为资源分类。 如果有一系列复杂的资源组和资源,并想要以最有利的方式可视化这些资产,则可以使用标记。 例如,可以标记组织中充当类似角色或者属于同一部门的资源。 如果不使用标记,组织中的用户可以创建多个资源,这可能会使将来的标识和管理变得困难。 例如,你可能想要删除某个特定项目的所有资源。 如果这些资源没有针对项目进行标记,则必须手动查找它们。 标记是降低不必要的订阅成本的重要方法。

资源不需要驻留在同一个资源组中就能共享一个标记。 可以创建自己的标记分类,以确保组织中的所有用户使用公用的标记,避免用户无意中应用稍有不同的标记(如“dept”而不是“department”)。

以下示例显示了应用到虚拟机的标记。

"resources": [    
  {
    "type": "Microsoft.Compute/virtualMachines",
    "apiVersion": "2015-06-15",
    "name": "SimpleWindowsVM",
    "location": "[resourceGroup().location]",
    "tags": {
        "costCenter": "Finance"
    },
    ...
  }
]

若要检索具有标记值的所有资源,请使用以下 PowerShell cmdlet:

Find-AzureRmResource -TagName costCenter -TagValue Finance

或者运行以下 Azure CLI 2.0 命令:

az resource list --tag costCenter=Finance

也可通过 Azure 门户查看标记的资源。

订阅的使用情况报告包括标记名称和值,可用于按标记对成本进行细分。 有关标记的详细信息,请参阅 使用标记来组织 Azure 资源

访问控制

资源管理器可以控制谁有权访问组织的特定操作。 Resource Manager 原生地在管理平台中集成了基于角色的访问控制 (RBAC),并向资源组中的所有服务应用该访问控制。

使用基于角色的访问控制时,必须了解两个主要概念:

  • 角色定义 - 描述一组权限,可以在多个分配中使用。
  • 角色分配 - 将具有某标识(用户或组)的定义与特定作用域(订阅、资源组或资源)相关联。 下级作用域将继承分配。

可以将用户添加到预定义的平台和资源特定角色。 例如,可以使用名为“读取者”的预定义角色来允许用户查看资源,但不允许更改资源。 为此,可将组织中需要此类访问权限的用户添加到“读取者”角色,并将该角色应用到订阅、资源组或资源。

Azure 提供以下四种平台角色:

  1. 所有者 - 可以管理所有内容(包括访问权限)
  2. 参与者 - 可以管理访问权限以外的所有内容
  3. 读取者 - 可以查看所有内容,但不能进行更改
  4. 用户访问管理员 - 可以管理用户对 Azure 资源的访问

Azure 还提供资源特定的多种角色。 一些常见的角色包括:

  1. 虚拟机参与者 - 可以管理虚拟机,但不能授予对它们的访问权限,并且无法管理它们连接到的虚拟网络或存储帐户
  2. 网络参与者 - 可以管理所有网络资源,但不能授予对它们的访问权限
  3. 存储帐户参与者 - 可以管理存储帐户,但不能授予对它们的访问权限
  4. SQL Server 参与者 - 可以管理 SQL 服务器和数据库,但不能管理其安全相关的策略
  5. 网站参与者 - 可以管理网站,但不能管理其连接到的 Web 计划

有关角色及允许操作的完整列表,请参阅 RBAC:内置角色。 有关基于角色的访问控制的详细信息,请参阅 Azure 基于角色的访问控制

在某些情况下,可能需要运行访问资源的代码或脚本,但不希望在用户的凭据下运行它。 在某些情况下,我们想要为应用程序创建名为服务主体的标识,并为该服务主体分配适当的角色。 在 Resource Manager 中可为应用程序创建凭据,以编程方式对应用程序进行身份验证。 若要了解如何创建服务主体,请参阅以下主题之一:

可以显式锁定关键资源,以防止用户删除或修改这些资源。 有关详细信息,请参阅 使用 Azure Resource Manager 锁定资源

活动日志

Resource Manager 记录所有创建、修改或删除资源的操作。 活动日志可用于在故障排除时查找错误,或用于监视组织内用户对资源的修改。 若要查看日志,请在某资源组的“设置”边栏选项卡选择“活动日志”。 可按多个值筛选日志,包括启动操作的用户。 有关使用活动日志的信息,请参阅查看活动日志以管理 Azure 资源

自定义的策略

资源管理器可创建自定义策略来管理资源。 创建的策略类型可包括各种方案。 可以在资源上实施命名约定,限制可部署的资源的类型和实例,或限制可托管资源类型的区域。 可以要求资源上的标记值按部门组织计费。 可以通过创建策略来降低成本并在订阅中保持一致性。

使用 JSON 定义策略,并在订阅或资源组中应用这些策略。 策略不同于基于角色的访问控制,因为策略应用于资源类型。

以下示例中显示的策略通过指定所有资源都必须包含 costCenter 标记来确保标记一致性。

{
  "if": {
    "not" : {
      "field" : "tags",
      "containsKey" : "costCenter"
    }
  },
  "then" : {
    "effect" : "deny"
  }
}

可创建许多其他类型的策略。 有关详细信息,请参阅什么是 Azure 策略?

SDK

Azure SDK 适用于多种语言和平台。 每种语言实现可通过其生态系统包管理器和 GitHub 来使用。

以下是我们的开放源代码 SDK 存储库。 欢迎提出反馈、问题和要求。

有关在资源中使用这些语言的信息,请参阅:

Note

如果 SDK 未提供所需的功能,也可以直接调用 Azure REST API

后续步骤