Azure-云管理实用指南-全-

Azure 云管理实用指南（全）

原文：annas-archive.org/md5/649587b180cdb9f8a1b502e61a720011

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

欢迎来到Azure 云管理实战。本书旨在帮助你入门 Azure，并指导你踏上云计算之旅。我们将从云计算的概念开始，帮助你理解云与本地基础设施的区别。基础的基础设施即服务（IaaS）和平台即服务（PaaS）服务将会被讲解，帮助你理解如何利用云服务。接下来，我们将讨论迁移和混合云，解释如何将你的服务迁移到云端，并如何将其与本地资源结合。还将讲解身份和安全，以帮助你保障和保护云资源。最后，我们将讨论一些最佳实践和基础设施即代码（Infrastructure-as-Code），以帮助你管理和监控资源。

本书将通过真实的案例和逐步的指导，帮助你理解云计算的原则，并在你的环境中应用这些知识。

本书的目标读者

本书面向 IT 专业人员、系统工程师、管理员、DevOps 从业者以及任何想要了解 Azure 和云计算概念的人。你应该具备基本的云计算知识，并具备中级的网络和服务器管理知识。

为了充分利用本书

建议具备基本的云计算知识。为了更好地理解本地基础设施与云基础设施之间的关键差异，建议具备中级的服务器和网络管理知识。本书将使用以下工具：

Windows Server 2016
MS SQL Server 2016
Hyper-V
Active Directory
PowerShell
Microsoft Azure
Azure PowerShell
Azure CLI

下载示例代码文件

你可以从www.packt.com的账户中下载本书的示例代码文件。如果你在其他地方购买了本书，可以访问www.packt.com/support，注册后将文件直接发送到你的邮箱。

你可以通过以下步骤下载代码文件：

在www.packt.com登录或注册。
选择 SUPPORT 标签。
点击“代码下载与勘误”。
在搜索框中输入书籍名称，并按照屏幕上的指示操作。

文件下载后，请确保使用以下最新版本的工具解压或提取文件夹：

适用于 Windows 的 WinRAR/7-Zip
适用于 Mac 的 Zipeg/iZip/UnRarX
适用于 Linux 的 7-Zip/PeaZip

本书的代码包也托管在 GitHub 上，网址是github.com/PacktPublishing/Hands-On-Cloud-Administration-in-Azure。如果代码有更新，它会在现有的 GitHub 库中进行更新。

我们还有其他来自丰富书籍和视频目录的代码包，访问github.com/PacktPublishing/查看！

下载彩色图像

我们还提供了一份 PDF 文件，其中包含本书中使用的截图/图表的彩色图像。你可以在这里下载它：www.packtpub.com/sites/default/files/downloads/9781789134964_ColorImages.pdf。

使用的规范

本书中使用了一些文本规范。

CodeInText：表示文本中的代码字、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。这里有一个例子：“基础级 VM 适用于dev/test环境，尽管它们的性能与标准级 VM 相似，但仍有一些限制。”

一段代码的格式如下所示：

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "name": {

所有的命令行输入或输出格式如下所示：

Connect-AzureRmAccount

粗体：表示新术语、重要词汇或在屏幕上看到的词汇。例如，菜单或对话框中的词汇在文本中会以这种方式出现。这里有一个例子：“要创建一个新的 Azure 虚拟机，我们需要选择‘新建资源’，然后选择‘新建虚拟机’。”

警告或重要事项以这种方式出现。

提示和技巧以这种方式出现。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何部分有疑问，请在邮件主题中提及书名，并通过customercare@packtpub.com与我们联系。

勘误表：虽然我们已尽力确保内容的准确性，但错误是难免的。如果你在本书中发现了错误，请向我们报告。请访问www.packt.com/submit-errata，选择你的书籍，点击勘误提交表单链接，并填写相关信息。

盗版：如果你在互联网上发现我们作品的任何非法复制版本，我们将非常感激你能提供该材料的地址或网站名称。请通过copyright@packt.com与我们联系，并提供该材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专长，并且有兴趣撰写或为书籍做贡献，请访问authors.packtpub.com。

书评

请留下评论。一旦你阅读并使用了本书，为什么不在你购买的站点上留下评论呢？潜在读者可以看到并参考你的公正意见来做出购买决策，我们 Packt 可以了解你对我们产品的看法，作者们也能看到你对他们书籍的反馈。谢谢！

如需了解更多关于 Packt 的信息，请访问packt.com。

第一章：云计算的关键概念

云计算已经成为一个流行词，并且在 IT 领域是一个大趋势。越来越多的公司开始了他们的云计算之旅，但开始这些旅程并不容易。与传统的本地 IT 环境相比，云计算需要不同的技能和思维方式，而云管理员的需求也在不断增长。在本书中，我们将共同开启云计算之旅，帮助你掌握云管理并理解 Microsoft Azure 的服务与架构。成为 Azure 专家，帮助你的公司顺利且安全地过渡到 Azure。

我们将要讨论的主题包括以下内容：

云计算概念
云服务模型
Azure 订阅模型

云计算概念

由于我们将使用 Microsoft Azure，因此理解云计算的关键概念，尤其是公共云的概念非常重要，因为 Azure 正是一个公共云。

在过去，我们看到过许多 IT 行业的趋势；其中一些是短期的，而另一些则持续了很长时间。许多人认为云计算是一个短期趋势，未来不会存在太久，但他们并没有真正理解云计算的概念以及这一切是如何开始的。

云计算并不是从公共云服务开始的，而是始于 1990 年代。显然，云计算的形式与今天并不相同，而是更多地作为企业内部实施的一种方式，为员工提供按需创建虚拟机的选项。在这一阶段，云计算包括一个虚拟化平台，允许员工基于预先准备好的镜像按需创建开发/测试环境。云计算的基础包括两个组成部分：虚拟化和按需资源。没有服务器虚拟化，这一切都无法实现，服务器虚拟化允许我们在单一物理服务器上创建多个虚拟机。云计算将虚拟化提升到另一个层次，超越了单纯的服务器虚拟化，但我们稍后会详细讨论。

按需获取资源的能力，正是云计算的基础。如前所述，云计算始于虚拟化平台，企业通过创建平台使员工能够按需创建虚拟机。今天，我们称之为私有云。

云计算的类型

云计算有不同的类型，而且对如何分类也有不同的看法。就我个人而言，我认为以下四种类型是最合逻辑的：

私有：一切都托管在内部，即我们自己的数据中心。
托管：介于私有云和公共云之间；服务提供商在他们的数据中心创建一个独立的环境，仅为我们提供一个专用的云。
公共：服务提供商提供的服务对所有人开放——公共可用。虽然仍然有租户隔离，但我们稍后会讨论这个问题。
混合云：私有云与公共云的结合。部分服务使用公共云，但一些服务保留在本地数据中心，并且两个或多个环境之间有直接连接。根据我的经验，这是最常见的云计算形式。我们稍后会详细解释更多内容。

在私有云中，所有资源都位于本地数据中心，无需互联网访问即可访问资源。互联网和资源是分开访问的，如下图所示。构建自己的私有云以前需要大量的投资，无论是物质上还是在知识上。首先，你需要空间，并且需要考虑其他因素，如冷却和电力。然后，你需要投资硬件，如防火墙、路由器、网络交换机、服务器和存储设备。

你需要为虚拟化层、虚拟机的操作系统许可证以及各种软件购买许可证。最终，如果没有合适的人来设置和维护系统，所有的物质投资都将付之东流。一旦一切就绪，私有云投入运行后，每隔几年就需要进行新的投资，因为你需要新版本的软件（虚拟化、操作系统及其他软件），硬件也需要替换：

托管云是从私有云到公共云过渡的第一步。由于创建和维护自己的私有云需要大规模投资，一些公司开始提供租用部分数据中心的服务，将其作为自己的私有云使用。他们专注于此类服务；由于供应商提供大宗采购折扣，他们更容易购买硬件和软件。因此，在托管云中创建环境比在私有云中创建相同的环境要便宜。

另一个问题是前期投资；使用私有云要求所有硬件和大部分软件许可证需提前支付，因此许多公司决定使用托管云，因为他们不需要进行前期投资，而是每月或每年订阅。此外，数据中心更容易提供专家来维护系统，因为一个专家可以同时照看多个客户的环境。而对于私有云，你需要网络工程师、存储专家、虚拟化专家等，这些仅仅是单一数据中心所需的人员。

在托管云的情况下，仍然需要所有工作人员，但一名专家可以为多个客户设置和维护环境，且维护成本低于私有云。请注意，访问托管云通常需要某种形式的虚拟专用网络（VPN），无论是站点到站点还是点到站点。我们通过访问位于自己网络外部并位于其他托管网络中的资源，如下图所示：

在云计算发展的下一阶段，公共云应运而生。大型服务提供商提供大量的资源供按需使用。与托管云类似，你使用的资源仍然位于本地基础设施之外，并由专门提供此类服务的服务提供商托管。

有两个关键区别。第一个区别是，在托管数据中心中，资源的数量通常是预先确定的，若需要更多资源，你必须等待新资源的配置（如果资源有可用的话）。而在公共云中，服务提供商有大量的资源可供按需请求，你可以随时获取所需资源。你可以根据需要创建任何种类和数量的资源。所需的仅是创建一个订阅并连接互联网以开始部署。这也意味着你拥有高度可扩展的环境，不受初始创建的资源大小限制。例如，如果你创建了一个有四个 CPU 和 16 GB RAM 的虚拟机，并且随着时间的推移发现该虚拟机无法处理你所需的工作负载，你不需要创建新的虚拟机；你可以使用扩展选项来更改大小。扩展的详细信息将在后面解释。反过来，如果你发现最初创建的虚拟机的大小对于你的工作负载来说过大，你不需要继续保持该大小并为不需要的部分支付费用。只需缩小即可解决问题。在这种情况下，我们通过互联网访问资源，如下图所示：

托管云与私有云的另一个区别在于定价。在托管云中，您将获得一定量的资源，并且无论这些资源以何种容量使用，您都要支付每月或每年的订阅费用，无论是 10%还是 100%。在公共云中，定价是基于使用量，支付模式是您仅支付实际使用的内容。因此，在公共云中，如果您创建了虚拟机，您将仅为实际使用的时间支付该虚拟机的费用。如果停止或删除此虚拟机，您将不再支付费用。不同云服务提供商的支付模式不同，可以按每天、每小时或每分钟使用量变化而异。由于我们将讨论微软 Azure，重要的是要提到 Azure 使用的是按分钟计费系统。因此，例如，如果您在 Microsoft Azure 中创建了一个虚拟机，并在 12 天 11 小时 13 分钟后将其删除，您将按照精确的使用时间计算支付金额。在按小时计费系统中，您将支付 12 天 12 小时的费用。在按天计费系统中，您将支付 13 天的费用。

另一个不同之处是多租户。即使公共云对所有人都可用；创建自己的订阅会生成自己的租户。通过使用特定的基础结构，这个租户会将您的资源与其他租户分离开来，而在该租户中创建的资源仅对具有访问该特定租户权限的人员可用。

总之，公共云的关键概念包括：

通过互联网访问
多租户
资源池化
按需消费
高度可扩展

术语云或公共云并非始于现代 IT，而是始于上世纪六十年代的资源时间共享概念。该概念在上世纪九十年代随着私有云而演变。然而，云技术在二十一世纪进一步演变和转型成为现代形式。

一切都始于亚马逊网络服务（Amazon Web Services），这是亚马逊的子公司，当他们在 2006 年发布了他们的弹性云计算（EC2）。Google 在 2008 年发布了 Google App Engine。微软在 2008 年 10 月宣布了他们的云版本，并在 2010 年 2 月公开可用。其他服务提供商纷纷效仿，如 IBM 或 Oracle 都有自己的公共云服务。就市场份额和发展速度而言，我们可以将云服务提供商中的前两名列为亚马逊网络服务和微软。

Azure 的简要历史（从 ASM 到 ARM）

我们之前提到过，微软在 2008 年宣布了他们的公共云版本，公共发布是在 2010 年。那时，微软公共云平台的正式名称是 Windows Azure。2014 年 4 月，该名称更改为 Microsoft Azure。更名的原因从未公开宣布，但有很多猜测。一个理论是，微软需要更改名称以适应开源软件的拥抱。随着微软将 Linux 虚拟机添加到其产品中，名称的命名规则变得过于混乱。最初，运行 Linux 的虚拟机在微软公共云上会被称为 Windows Azure Linux 虚拟机，而 Windows 和 Linux 放在同一个名称中确实让人困惑。将其更名为 Microsoft Azure Linux 虚拟机则更为合理。现在，这只是你可以找到的理论之一，并非官方更名原因。

不仅仅是名称在这些年中发生了变化。Azure 的第一个版本，Windows Azure，拥有完全不同的规格和类型的门户。第一个 Azure 门户可以通过地址https://manage.windowsazure.net访问，并且基于 Silverlight 技术。这个门户后来被称为经典门户，而在经典门户中创建的资源管理模型被称为Azure 标准管理（ASM）。经典门户的布局如下图所示：

在这个时候，微软意识到他们的云模型存在问题，并开始着手开发全新的架构。2014 年，微软宣布了全新的 Azure 门户。伴随着新的门户，我们还迎来了全新的管理模型，称为Azure 资源管理器（ARM）。ARM 带来了像基于角色的访问控制（RBAC）和资源组等新特性。

这些特性改变了我们在云中管理资源的方式。在 ASM 中，允许某人管理 Azure 资源的唯一方式是将其添加为 Azure 订阅的共同管理员。这个人将拥有对该订阅的完全访问和控制权。通过 RBAC，我们有了为用户提供不同权限级别的选项，例如阅读者或贡献者，而不需要给予他们对订阅的完全访问权限。

资源组更进一步。Azure 中的资源组代表逻辑容器，你可以根据选择的约定将资源放入其中。例如，你可以将单个应用程序使用的所有资源放入一个资源组中。这将允许你为用户分配访问某个资源组的权限，并且该用户只能管理或访问该特定资源组。当该用户登录到租户时，他将只能看到分配给他的资源组，即使你在同一订阅或租户下有其他资源组。你还可以使用 RABC 进一步细化权限，指定用户只能访问特定资源，但这过于细化且难以管理。基于资源组的分配被认为是最佳实践，也是管理 Azure 资源的最佳方式。

新的 Azure 门户在 2015 年 12 月之前被视为预览版本。当时，它成为了正式门户，并可以通过portal.azure.com访问。该门户在 2014 年 4 月宣布时就已上线，但当时只是预览版本。新的门户布局如下截图所示：

经典门户宣布将被淘汰，并最终在 2018 年 1 月完成退役。与 RBAC 和资源组一起，ARM 为我们带来了另一个惊人的功能——ARM 模板。ARM 模板是包含 Azure 资源信息的 JSON 文件，可用于部署新资源或编辑现有资源。

通过 ARM 模型和 ARM 模板，微软提升了云计算业务，并且真正改变了云业务。在云计算和 DevOps 领域，基础设施即代码（IaC）概念非常重要，这正是 ARM 模板的作用。你可以创建一个 ARM 模板，并多次重复使用它来创建类似的环境。通过这种方式，你自动化了基础设施部署步骤，并消除了部署和配置过程中的潜在错误。

云服务模型

说到 IaC，我们在云计算领域有很多术语。微软 Azure（以及一般云计算）的主要服务类型包括：

基础设施即服务（IaaS）
平台即服务（PaaS）
软件即服务（SaaS）

每种类型代表不同的服务级别以及我们对该资源的控制。为了说明每种类型及其关系，最好将它们与本地数据中心的服务进行对比。所有模型的服务层在下图中展示，我们将利用此图来解释云模型之间的关系：

在私人数据中心中，我们需要负责搭建和维护所有内容。我们需要设置网络堆栈，准备和配置存储，购买和准备硬件，安装软件，配置虚拟化主机。然后，我们需要配置镜像和服务器，部署并管理数据库。安全性在所有方面都是我们的责任——物理安全、网络安全、主机和操作系统安全，最后是所有运行在我们服务器上的应用程序软件的应用安全。

使用 IaaS，事情变得更简单了。我们不再需要准备任何东西；我们只需要注册订阅，在需要时创建一个虚拟机并开始使用。我们不再需要关心购买、准备、配置和维护这些工作，这些都由云服务提供商负责，在我们的例子中是微软的 Azure。准备镜像和部署也不再是我们的责任。安全性变得更加简单，微软负责处理物理、安全、网络和主机的安全。我们仍然在安全方面有一定责任，需要保持操作系统的最新版本、修补和确保安全。应用程序安全也是我们的责任，我们需要不断应用最佳的安全实践，以保持安全和稳定。许多人忘记了，迁移到云时，我们需要加强安全性。由于云服务提供商负责了大部分安全工作，很多人因此变得舒适和放松，忽视了自己需要负责的安全部分。当迁移到云时，我们需要记住，资源和应用程序会公开暴露，相比使用本地基础设施时，它们将面临更多的“攻击”。在本地基础设施上攻击资源通常意味着突破防火墙、入侵服务器并获取数据。而现在，许多服务可以通过互联网访问，因此你需要比以往任何时候都更加重视安全性。当谈到 IaaS 时，微软 Azure 的最佳示例就是 Azure 虚拟机。微软 Azure 中既有 Windows Server 虚拟机，也有 Linux 虚拟机。一个有趣的事实是，根据微软 2017 年 10 月发布的信息，Azure 中超过 40%的虚拟机运行的是 Linux。

PaaS 比 IaaS 更容易使用。我们所说的云服务提供商负责的内容都适用，而且更多。在这种服务中，微软负责操作系统、所需的附加软件和额外的安全层。我们仍然需要维护我们放置在其中的所有内容（取决于 PaaS 服务），而剩下的安全问题仍然是我们的问题。再次强调，人们往往很快忘记这一点，认为更多的责任转嫁到了微软。然而，IaaS 通常与 VPN 连接一起使用（无论是点对点还是站点到站点），此时端点不会公开暴露。而 PaaS 则通常通过互联网进行访问。因此，我们需要非常重视安全性，除非我们希望丢失数据或无法访问我们的服务。Azure 中 PaaS 的最佳例子是 Azure 应用服务或 Azure SQL 数据库。

最后，我们来看 SaaS。在 SaaS 中，云服务提供商几乎全程负责，处理所有事情。在这种情况下，我们拥有一个完整的解决方案，只需要创建一个订阅并为用户分配不同的访问权限。通常，SaaS 需要模块、管理员和用户。管理员模块用于管理用户和访问级别；用户模块则用于实际使用我们订阅的软件功能。安全性也是我们的责任，只有在用户级别上，我们需要确保用户意识到他们需要保护好自己的凭证，并设置足够强大的密码以防止账户被暴力破解。Microsoft Cloud 中 SaaS 的最佳例子就是 Office 365。

这个解释“披萨即服务”的图表通常用来描述云服务如何与现实生活情境相关，并帮助更好地理解云计算所提供的内容：

在这种情况下，我们可以将披萨与前面图表中解释的 IaaS、PaaS、SaaS 和本地计算的四种类型进行比较。

与本地计算相比，披萨就像是自制的选择。我们需要购买所有的配料，混合所有的材料，烘烤它，买饮料，并进行服务。将披萨与 IaaS 相比，我们会买冷冻披萨并烘烤，准备好桌子并进行服务。相比 PaaS，披萨就像是外卖——我们只需要点披萨，买饮料并提供服务。最后，SaaS 版本的披萨就像是在餐馆里用餐：我们出去点餐，一切都为我们准备好了。我们得到披萨，得到饮料，一切都有人服务。

云服务模型的优缺点

我们已经讨论了每种云服务模型为我们带来的一些特点和优势。IaaS 比 PaaS 需要更多的注册和维护。SaaS 比 PaaS 更少需要人工干预，几乎不需要维护，除了用户管理。

但这也有另一面。SaaS 要求最小的维护和管理，但也提供最少的定制。如果你需要在 SaaS 中做出更改，你可能需要联系你的云服务提供商，由他们进行更改。

在 PaaS 中，你在管理、维护和定制方面拥有更多自由。然而，这些变化通常是一个预配置的选项集，你可以从中选择，但比 SaaS 有更多的选择。

IaaS 需要最多的管理和维护，但也为你提供了最好的定制选项。因为你控制着从操作系统开始的一切（你可以选择不同的预配置镜像，甚至带入自己的操作系统镜像），所以你也有最好的控制权。你可以选择你要配置的功能，服务器上要配置的角色，甚至在虚拟机上安装任何类型的软件。

关键是你需要决定在特定情况下哪种功能最适合你。在某些情况下，最简单的解决方案可能是 SaaS，因为该产品提供了你所需要的一切。如果你需要最新的设置和功能，你可能会使用 PaaS 模型。如果你有一些遗留依赖，IaaS 将是最合适的选择。通过这种方式，你将能够配置和安装与该依赖相关的所有内容。

云的其他好处

云计算的第一个好处显而易见，正如之前所说的：它更容易维护和管理。

使用云计算时，有许多专业领域你不需要自己提供；云服务提供商会为你管理这些事情。但这也可能是一种陷阱——云资源不是自我管理的，你仍然需要 IT 专业人员来管理和维护你的资源，确保它们的健康。这些 IT 专业人员与本地数据中心的有所不同，但我们仍然需要懂得核心 IT 的人。如果你使用的是 IaaS，你仍然需要 Windows 服务器管理员（或 Linux 服务器管理员，取决于你的偏好）。如果你使用的是数据库，你仍然需要数据库管理员。IT 专业人员需要调整他们的技能和角色以适应云计算，并告别本地部署，但我们依然非常需要他们。

财务上的好处也是明显的优点之一。在本地环境中，你需要预先购买并支付所有资源费用，然后才能开始使用它们。为了建设本地数据中心，我们需要准备许多不同的硬件组件，比如防火墙、网络交换机、存储设备、服务器、不间断电源等。我们还需要为这种硬件准备基础设施，比如一个合适的服务器房间。冷却系统必须保持硬件在最佳温度，或者提供足够的电力，使我们能够运行而不至于超载电网。而当所有这些都准备好之后，我们还需要为虚拟化主机购买合适的许可，为每台虚拟机购买操作系统许可，以及为任何计划使用的额外软件（如 SQL Server、端点保护或其他所需软件）购买许可证。在本地数据中心，你需要提前购买并准备一切。这对任何组织来说可能是一次巨大的财务冲击。

而且，在初期成本之后，我们还需要支付维护费用。我们需要支付电费、冷却系统费用、所需的备用零件费用，以及雇佣人员来维护这一切。

几年之后，我们的硬件和软件就会变得过时，需要重新开始一切。在这种情况下，保持跟上并保持相关性可能会很困难。

在云端，我们无需为任何东西预先支付费用；我们使用的是按需付费的服务模型，根据实际使用的资源按分钟计费。我们不需要对任何东西进行大量投资——你可以在需要时创建资源，只使用所需的时间，使用完毕后可以删除它们。

如果我们需要一台新服务器，在云端几分钟内就能完成。无需联系不同的经销商，不需要填写订单和等待交付。在 Azure 中，你只需在需要时启动虚拟机（或其他任何资源）。一旦不再需要，删除它，它就不再收费了。这也是云和本地部署之间的一个区别：你不会被你购买的资源束缚。在本地数据中心，你需要先购买资源才能使用。一旦不再需要它们，它们并不会从你的服务器室中神奇地消失。即使它们真的消失了，你仍然花了钱。

关于我们为特定服务所需资源的评估也可能是一个大问题。假设我们正在创建一个新的网站应用程序，准备向最终用户提供。应用程序已经完成，我们需要在某个地方托管它，以便用户开始注册并使用该应用程序。这个应用程序可能需要服务器、Web 服务器和数据库服务器。我们需要为这些服务器购买新硬件和许可证。这里的问题是，我们需要购买能够处理工作负载的硬件。工作负载需要根据初始用户数量以及随时间的增长来估算，但这非常难以预估。如果我们猜测初始的工作负载，很容易在增长数据上犯错。如果我们高估了工作负载，我们会被一些我们实际上不需要但已经付费的东西困住。如果我们低估了工作负载，我们就需要非常快速地进行升级。升级可能带来两个问题：时间和金钱。

升级和解决工作负载问题可能需要一些时间。在此期间，用户可能会因为高负载导致的糟糕性能而流失。由于应用程序的性能不佳而失去用户是我们绝对希望避免的，但有时这可能是不可控的，因为获取权限（特别是在大公司中）来订购升级组件、接收它们并升级我们的服务器需要时间。升级服务器还会导致一定的停机时间，因为我们需要关闭服务器以便添加新组件。同样，这也是我们想要避免的。

关于升级的第二个问题是它们需要花费金钱。增加服务器工作负载可能需要相当大的费用。在某些情况下，如果我们需要升级内存，除非我们同时升级 CPU，否则无法做到。有时，升级 CPU 需要先升级主板才能继续。但这也取决于服务器是否可以升级，因为有时我们受限于现有设备，根本无法进行升级。在这种情况下，我们需要购买全新的硬件，而我们已经支付的旧服务器却成了不需要的负担。

云计算使这些问题变得更加简单，且更容易解决。如果我们决定使用 IaaS，我们将创建两个服务器；如果我们决定使用 PaaS（我们在这里有多个选择），则会创建两个其他服务。管理工作负载和资源数量简单、快速且容易。

如果时间证明我们高估了自己的需求，我们可以简单地缩减资源，问题就得到解决。我们不会被不需要的东西困住，也不需要为其付费。我们只需缩减服务器/资源，从那时起，我们只需为一个更小的服务器付费，而这个服务器我们实际上是需要的。

如果我们低估了需求，我们也可以像扩容一样轻松快速地增加资源量。我们不需要等待零件，也不必等到升级组件最终交付。我们只需增加资源量，问题就解决了。

云计算的另一个好处与资源数量相关。在某些情况下，我们的应用程序会出现流量峰值。流量峰值是工作负载的突然增加，可能是可预测的也可能是不可预测的。例如，如果我们在运营一个在线商店应用程序，当我们对热销商品提供折扣或者节假日期间的工作负载增加时，可以预测到流量峰值。如果我们运营的是新闻门户网站，那么由于突发新闻等原因，可能会出现不可预测的流量峰值。

无论是不可预测的还是可预测的流量峰值，我们在设置将要使用的资源时都需要考虑到它们。即使我们的资源大部分时间处于闲置和未被充分利用的状态，我们仍然需要购买能够处理这些工作负载的硬件。所以，如果我们在正常情况下有 10,000 个用户，而在流量峰值时有 1,000,000 个用户，我们就需要购买能够处理 1,000,000 用户工作负载的资源。否则，在流量峰值期间，用户将面临高负载和无法响应的应用程序，最终我们将再次失去用户。然而，购买一台 90%的时间都不被充分利用的服务器是我们希望避免的，因为这很昂贵。我们只有两种选择：要么支付费用，要么失去客户。

云计算还可以帮助我们快速处理这个问题。我们可以非常轻松、简单且快速地进行扩展和缩减。根据是否是不可预测或可预测的流量峰值，可以采取两种不同的方式。

在可预测的流量峰值情况下，我们可以根据需求增加或减少资源量。通过这样做，我们就不再为我们实际不需要的资源支付费用。在正常期间，我们只为正常工作负载付费，而在流量增加的情况下，我们为高负载付费，但仅限于高负载期间，之后我们将资源缩回到正常状态时，就不会继续支付额外费用。

在不可预测的流量峰值情况下，我们可以设置性能计数器和警报，按需触发扩容（或缩容）。例如，我们可以设置一个监控 CPU 的触发器。一旦 CPU 使用率达到 90%，我们可以安排自动扩展，并增加分配给该服务的资源量。通过这种方式，用户不会因为高负载和应用程序使用量增加而遇到任何问题。我们需要注意自动扩展，因为这会导致价格上涨，除非我们缩回资源，否则我们将支付更高的费用。缩容可以手动进行，但也可以自动完成。我们可以创建另一个触发器，当 CPU 降到 50%以下时执行缩容。这样，我们就能始终只使用实际需要和使用的资源。

理解 Azure 订阅模型

大多数云服务提供商都有类似的订阅模型，但也有一些独特的功能。我们将重点介绍 Microsoft Azure，因为这是本书中将要讨论的云服务。从现在起，我们将讨论的所有功能都是针对 Azure 的。

对于 Microsoft Azure 订阅，最高级别的管理是租户。Azure 是一个公共云，拥有遍布全球的数据中心，向所有人开放。也有一些例外，比如仅供美国政府机构使用的美国政府数据中心、仅供中国官方机构使用的中国政府数据中心，或仅供注册在德国的公司使用的德国数据中心。

作为公共云提供商，Microsoft 必须为每个用户保持数据隔离。Azure 架构用于在数据中心中隔离资源，并将其绑定到特定客户。因此，即使你共享物理资源，如网络、服务器和存储，你的服务只能由你自己访问和管理。

作为 Azure 的最高级别，租户在你创建第一个 Azure 订阅时默认创建。很多人没有意识到，如果他们使用 Office 365，那么他们已经有了一个 Azure 租户。Office 365 需要 Azure Active Directory，并且会创建你的第一个 Azure 租户。我见过很多人犯这样的错误：即使他们已经在使用 Office 365，仍然创建了一个新的 Azure 租户。问题在于，租户是与 Azure Active Directory 绑定的，创建一个新租户相当于创建一个新的 Azure Active Directory 副本。这使得 Azure Active Directory 难以管理，因为你会有两个副本，并且随着时间的推移会出现差异。

创建你的第一个 Azure 订阅时，会创建一个新的 Azure 租户和一个新的 Azure Active Directory。管理 Azure Active Directory 有多种选择，但我们将在第八章中讨论，Azure Active Directory – 云中的身份管理。创建额外的 Azure Active Directory 也会创建一个新的 Azure 租户。

在租户下的下一级是 Azure 订阅。你可以在单个租户下拥有多个 Azure 订阅。创建一个新的租户将导致一个空租户，仅包含 Azure Active Directory 而没有订阅。由于 Azure Active Directory 有多个层级，你无法在没有有效订阅的情况下将 Azure Active Directory 从基础版（即免费版）升级到其他层级。为了收集使用信息、生成账单报告，并最终开具服务使用发票，必须有一个订阅。

Azure 订阅可以用来通过财务和管理逻辑将 Azure 环境进行隔离。你可以通过多种方式来实现这一点，设计方案可以根据你的需求来定制。一个例子是，企业层面使用一个租户，并为每个部门设置一个 Azure 订阅。这样，你可以为每个订阅/部门指定不同的管理员，并跟踪每个部门的开支。另一个订阅隔离的例子是使用不同的阶段环境。我见过许多公司将他们的订阅分为开发、测试和生产环境，并为每个环境设置不同的 Azure 订阅。这种方式使你能够分别管理每个环境，但同时也能洞察你在每个环境中的花费。

隔离资源的第三部分是使用资源组。资源组是在 ARM 模型中引入的，并带来了许多好处。和订阅一样，你可以使用资源组从逻辑或计费层面来隔离资源。一个例子是为每个部门或开发/测试/生产环境设置不同的资源组。然后，你可以为每个资源组分配不同的管理员，并跟踪每个资源组的计费。请注意，计费时你仍然会在月底收到一张合并账单，并需要手动管理和跟踪开支。订阅层面的计费隔离要容易得多。如果你需要按部门/环境隔离账单，应该选择订阅隔离。

Azure 中的每个资源都可以通过层级结构进行追踪。资源属于资源组，资源组属于订阅，订阅属于租户。登录到 Azure 门户将连接到默认租户。你可以管理哪个租户是默认租户，因为一个账户可以在多个租户中存在。例如，我的公司账户默认在我的公司租户中，但我还是多个客户租户中的访客用户。默认情况下，我连接到公司租户，但可以从下拉列表中选择客户租户。我还可以更改默认租户，并选择在登录到我的 Microsoft Azure 账户时，默认登录哪个租户。

从微软 Azure 的角度来看，当你使用账户登录 Microsoft Azure 时，Azure fabric 会确定你可以访问哪个租户，并将你登录到默认租户，你可以访问该租户中的所有订阅。从那里，你可以管理属于该租户的所有订阅、资源组和资源。通过切换租户，你可以访问属于不同租户的订阅、资源组和资源。所有这些操作都由 Azure fabric 处理，以便将客户端环境进行隔离。

这种方法要好得多，因为 ARM 模型引入后，事情变得与 ASM 时代大不相同。在 ASM 中，登录后你会访问所有属于该单一帐户的订阅。Azure Active Directory 并未与特定的租户绑定，一个租户中可以有多个 Azure Active Directory。在没有资源组的情况下，很难跟踪资源，唯一的区分方式是订阅级别。

类似的层级结构也可以应用到资源管理上。你也可以为用户分配一定的资源访问权限。访问级别可以具有不同的权限，例如所有者、贡献者、读取者等。你可以构建自定义权限来实现自己的规则和政策。用户角色可以在租户、订阅、资源组或单个资源级别上分配。管理资源级别的用户访问可能很困难且费时，我不建议采用这种方法。

另一方面，租户级别的访问通常是你要避免的，因为在大多数情况下，你不希望用户对所有资源具有相同的访问权限。少数管理员可以作为例外，但这种方法一般来说是你要避免的。最佳且最常见的选项是为用户分配订阅或资源组级别的访问权限。如果你为每个订阅设置不同的部门或环境，则可以使用订阅级别的访问权限，并可以为该部门或环境指定管理员作为订阅管理员。如果你在资源组中有一个单一的应用程序或环境，可以将访问权限应用到资源组级别，并为相应的资源组指定应用程序/环境管理员。这些并不是你可以使用的唯一选项或模型，但你可以根据需要调整并创建最适合你的选项。例如，我见过一些组织将相似的资源放在一个资源组中，并根据他们在本地的角色分配管理员。所有的网络资源都会放在一个资源组中，网络工程师则被分配到网络资源组中。所有数据库都会放在另一个资源组中，并为该资源组指定数据库管理员，依此类推。

Azure 订阅类型

要创建你的第一个 Azure 订阅，你需要做几件事。第一件事是提供一个电子邮件地址，必须是 Microsoft Live 账户或 Office 365 账户。你还需要提供一个电话号码。最后，你需要提供信用卡或借记卡信息以及账单地址。即使是免费订阅，也需要信用卡信息，因为 Microsoft 会用它来验证你的身份。

当谈到 Azure 订阅时，我们可以将其分为三种不同的类型：

赞助订阅
按需付费
企业订阅

Azure 中有几种不同的赞助订阅：试用版、Azure Pass、MSDN 订阅、Azure 赞助等。它们的共同点是都有一定数量的免费资源可以供你使用。另一个共同点是，并非所有服务都可以在所有区域使用。例如，只有在选择北欧地区时，你才可以创建 A2 标准虚拟机，而在其他任何地区都无法创建这种虚拟机。

Azure 试用版为你提供 200 美元的服务，期限为 30 天。订阅会在以下两种情况中到期：要么你用完了 200 美元，要么在月底到期。你需要提供信用卡/借记卡信息来进行这种类型的订阅。你可以随时通过该卡或提供新卡信息将试用订阅转换为按需付费模式。必须提供信用卡信息——这仅用于身份验证，除非你明确表示希望取消消费限制并在试用期结束后开始计费，否则你不会被收取任何费用。微软希望通过这种方式防止用户利用 Azure 从事非法活动。如果没有信用卡信息，任何人都可以创建一个试用订阅，并用它来托管非法内容，期限为 30 天。在试用期结束时，这个人可能会重新创建一个试用订阅，继续使用 Azure 服务来托管非法内容。在这种情况下，微软将无法提供谁在使用 Azure 从事非法活动的信息，相关当局将追究他们的责任。

Azure Pass 是另一种试用订阅类型，提供一定额度的信用，期限为 30 天。这种订阅与微软的官方课程相关联，信用额度取决于课程的类型，每种课程的信用额度不同。这种订阅不需要信用卡，你只需要注册课程，并且可以使用课程注册信息在必要时进行身份验证。与试用订阅类似，创建的资源类型、可用资源数量以及资源可创建的区域都会受到限制。

MSDN Azure 订阅与用户的 MSDN 订阅相关联，根据信息技术和开发人员 MSDN 订阅的不同级别（例如专业版和企业版），每个级别的额度也会有所不同。所提供的信用额度是按月计算的，并且你在每个计费周期的开始时会获得一定额度（计费周期取决于激活日期，激活日期将成为计费周期的开始日期，而计费周期的结束日期为 30 天后）。

只要 MSDN 订阅仍然有效，Azure 订阅就会保持激活状态。无需提供信用卡信息，因为可以使用另一种验证方式（MSDN 支付信息）。如果你在某个月达到支出限制，你的资源将在计费周期结束之前被停用并停止服务。

若要再次使用这些服务，你需要等到新计费周期开始，或者提供信用卡信息，该信息将用于收费超出赞助金额的部分。可以选择将移除限制应用到单个月份或整个订阅。单月移除将仅在该月移除支出限制，而订阅移除则会永久移除支出限制，并在每次达到支出限制时开始计费。在单月移除限制的情况下，限制只会移除指定月份，如果下个月再次发生同样的问题，服务将会被禁用。如果限制被从订阅中移除，一旦达到支出限制，系统将自动开始对你的使用进行收费。

请注意，在每种情况下，首先会使用赞助金额，然后才会激活信用卡。MSDN 的 Azure 订阅仅限于开发和测试；绝不能用于商业或生产用途。你还会遇到资源和区域的使用限制。MSDN 订阅对于资源也有不同的定价。在这种开发/测试环境下，你不需要支付软件许可费用，且资源价格也因此更便宜。

Azure 赞助与 MSDN 订阅非常相似。它不应被用于商业或生产用途。Azure 赞助也有支出限制，但这次的限制不是按月计算，而是按年计算。计费周期是 Azure 赞助与 Azure MSDN 订阅之间的两个区别之一，其中赞助是按年计费，MSDN 是按月计费。支出限制可以移除；资源和区域也有限制。第二个区别是适用正常价格，你将为软件许可付费。

按需付费是 Azure 最简单且最常见的订阅类型。你注册 Azure 订阅，提供信用卡信息，且此信用卡将在每个月底用于计费。这个名称几乎解释了所有内容：没有任何限制，你只需为自己使用的部分付费。如果你在订阅中没有任何资源，微软将不会因仅有订阅而向你收费。如果你在订阅中有资源，只有这些资源会被收费。如果你添加了一些资源，你将额外收费。如果你删除了某些资源，你将只为仍然激活的资源付费。你的订阅没有最低或最高限制；你可以每月不花费一分钱，也可以花费数百万。

企业订阅需要签订一份合同，合同中确定了你在 Azure 资源上的最低支出金额。你承诺每年花费一定金额，便可以享受资源价格的折扣。费用按月结算，基于合同中的金额。任何超过合同规定的最低金额部分，将在年底单独计费。使用企业订阅时，还可以选择将自己的许可证带入 Azure，从而允许你重用已有的本地资源许可证。

此外，还有预留实例折扣。这可以应用于按需计费和企业订阅。你需要确定在接下来一段时间内将使用的虚拟机数量和类型。时间段可以是 1 年或 2 年。一年期为你提供折扣，而两年期则给予额外折扣（因为你承诺更长时间使用服务，折扣也更大）。你可以随时编辑预留实例协议，增加或删除虚拟机。增加数量可以提供额外折扣，而减少数量则会导致处罚。

在 IaaS 和 PaaS 之间做决定

一旦订阅完成，你就可以开始创建资源，以便使用它们并部署你的应用程序。在微软 Azure 提供的广泛选择面前，选择使用什么以及何时使用可能会让人感到不知所措。在开始之前，我们需要考虑不同的方法和架构。

我们已经讨论过 IaaS、PaaS 和 SaaS。微软 SaaS 的一个例子是 Office 365，作为一种云软件，它采用订阅模式提供。Office 365 甚至运行在 Azure 数据中心（这也是这些数据中心的最初目的之一，除了身份管理——我们现在称之为 Azure Active Directory），但我们不会进一步讨论这个产品，因为它与 Azure 订阅没有直接关系。我们的目标是区分微软 Azure 在 IaaS 和 PaaS 方面的产品。

IaaS 是迁移到云的第一步。传统 IT 专业人员通常会接受这作为云之旅的第一步。创建 Azure 虚拟机非常简单，从虚拟机层面看，本地虚拟机与云虚拟机之间没有太大区别。你无法访问硬件或主机组件，这使得维护更简单、更便宜。但是，在 Azure 中管理虚拟机和管理本地版本差别不大，无论我们本地使用什么主机——Hyper-V、VMWare 或其他（微软 Azure 使用的是修改版的 Hyper-V 主机，与本地使用的版本有所不同）。

你选择操作系统的镜像，选择虚拟机的大小，以及其他一些参数。从这里开始，你可以连接到虚拟机并根据需要安装特性和软件。你可以控制所有安装在虚拟机上的软件的访问、框架和数据；你需要为其支付订阅费用，或者提供你自己的有效许可证。如果你创建一个带有 Windows Server 2016 和 SQL Server 2016 的虚拟机，你将额外支付这两项许可证费用。

创建 PaaS 资源比 IaaS 更简单。它也更容易管理和维护。但另一方面，控制权不再完全掌握在自己手中。你可以编辑一些预定义的关键特性，使它们具有不同的值或开关状态。但有些内容是默认的，你将无法编辑它们。所有的许可证都已默认包含在资源的价格中。

假设你有一个运行在 IIS 前端的 Web 应用程序和一个在 SQL Server 后端的数据库，让我们考虑一个简单的场景。

对于 IaaS，你需要创建两个虚拟机，一个 Web 服务器和一个数据库服务器。为了托管你的应用程序，你需要在将运行 Windows Server 2016 的 Web 服务器上设置 IIS。数据库服务器可以是一个运行 Windows Server 2016 上的 SQL Server 2016 的虚拟机。到目前为止，加上我们的计算价格，我们已经有了两个 Windows Server 许可证和一个 SQL Server 许可证（如果选择 Web、Standard 或 Enterprise 版本，SQL Server 的价格也会有所不同）。一旦我们安装并配置好 IIS，我们需要创建防火墙和网络安全组规则，这将允许我们通过互联网访问我们的应用程序。我们还需要设置 Web 服务器和数据库服务器之间的通信，并创建类似的规则，以便我们的应用程序与数据库之间能够相互通信。到这里，我们已经很忙了，在 IaaS 中启用一个简单的场景。

对于 IaaS，我们将设置应用服务计划，以托管我们的 Web 应用程序和后端的 Azure SQL 数据库。所有许可证已经配置好，我们不需要做其他的配置工作。这个过程更加简单易行。

请注意，PaaS 在大多数情况下的定价更便宜。

但另一方面，PaaS 并不总是能满足我们运行应用程序所需的一切。如果我们需要使用某个框架的旧版本，PaaS 将无法工作。PaaS 已经预配置了一些框架，你可以使用它们，但无法额外安装任何内容。如果你的数据库有一些在 Azure SQL 中不受支持的特性，或者存在兼容性问题，你需要在虚拟机中使用 SQL Server。

总体而言，PaaS 通常比 IaaS 更便宜且需要更少的关注，但 IaaS 提供了更好的控制和更好的传统支持。

服务产品每天都在增长，每隔几周，Microsoft Azure 就会推出新服务和新功能。我们提到的几个服务只是简单场景中的示例。IaaS 确实让我们可以控制 VM 中的内容，并提供比单一资源更好的组合，但 PaaS 的服务列表远不止于此。对于 Azure PaaS，我们可以创建应用服务、内容分发网络、Azure SQL 数据库、流量管理器、服务总线、Azure Functions、Azure CosmosDB、Azure 存储、Redis 缓存等，以上只是其中的一些。

Azure 数据平台有超过 50 种不同的 PaaS 服务，其他平台如网页、媒体、计算等也是如此。从财务角度和性能角度来看，选择合适的服务都很有利。我们需要考虑是否有些服务存在限制，迫使我们使用其他服务来弥补这一限制。同时，也有可能存在其他服务能够覆盖这两个方面，这样就无需使用额外的服务。如果我们没有全面考虑所有方面，并试图预测所有可能的场景，限制可能会导致性能问题。幸运的是，在 Azure 中，我们不会被单一的解决方案束缚，即便我们发现自己选择的服务并不能真正满足需求——我们可以随时扩展或完全切换到另一个服务。

了解 Azure 资源的定价

在 Microsoft Azure 中，关于定价有几个需要考虑的方面。有些资源有固定定价，有些资源则按消费定价。此外，固定定价的资源有时会包括基础价格中的服务级别限制。一旦达到该限制，您将根据消费量额外收费。这可能会将固定定价资源转变为消费定价资源。还有一些例外情况，适用不同的使用方式。

固定定价的资源会在您创建时立即加入到账单中。固定定价资源按月计费，具有固定价格，并在创建时加入到您的账单中。此类服务的示例包括 OMS 或 Azure Active Directory（在更高的服务等级上）。预留公共 IP 地址也是固定成本资源之一。在您删除此类资源后，它将被加入到当前计费周期的账单中。

Azure 存储基于消费模式，您为存储账户中的数据量付费。但是，数据量每个月都在变化，月初或月末可能数据较少，而月中数据量则可能较多。在这种情况下，会计算平均消费量，并且您会根据 Azure 存储的平均消费量进行计费。

一个有性能级别限制的服务的例子是带宽。传入数据传输是免费的，只要数据流向 Azure 数据中心，你不需要支付任何费用。每月前 5 GB 的外发数据是免费的，超过 5 GB 的部分需要额外收费。另一个服务限制的例子是 Azure 容器注册表，你有 100 分钟的 CPU 时间包含在内，但超过这个限制会额外收费。Azure Function 也是这种资源类型的一个例子，前 1,000,000 次执行是免费的，之后的执行则需要收费。

基于计算的资源是按分钟计算的。如果你运行虚拟机或应用服务，只要删除这些资源，计费就会停止。这同样适用于某些情况下停止的资源。Azure SQL 数据库不能停止，但定价会按分钟计算。如果你删除 Azure SQL 数据库，删除的那一刻起就停止支付费用。对于虚拟机和应用服务，你可以停止这些资源，之后就不再支付计算小时费用。需要注意的是，虚拟机的定价有一些细节。虚拟机价格信息，你可以在 Azure 门户中创建虚拟机时找到，或在 Azure 计算器中查看，它仅适用于计算小时。虚拟机还使用 Azure 存储，存储费用与计算费用分开计算，无论虚拟机是否正在运行，你都会为存储付费。某些网络组件可能会为虚拟机产生额外费用。例如，你可以预留一个公共 IP 地址，并为此单独收费。

在 Azure 中，跟踪你的资源并了解你正在使用什么，资源是否被利用，以及当前资源的限制是什么，非常重要。如果你没有正确使用某个资源，或者根本没有使用它，你仍然需要为它付费。这与传统 IT 环境不同，在传统环境中，你的资源是预付费的，只要你没有达到主机级别的资源限制，即使某个虚拟机没有被使用，也不会影响费用。在 Azure 中，你为你创建的每个资源（或在某些情况下运行的资源）付费，因此你需要跟踪活跃的资源以及你实际需要的资源。否则，云可能变成一个非常昂贵的解决方案，账单会开始堆积。财务上的好处可以是巨大的，但如果你不小心，也可能适得其反。我见过很多公司在没有控制的情况下使用开发和测试环境，许多资源是没人知道是谁创建的，更别提是否有实际使用这些资源的人了。生产环境中不太常见这种问题，但在某些情况下也会发生。

聪明一点，Azure 会帮助你，但如果你不跟踪使用情况和账单，它可能会反过来对你不利。这是你的选择：你可以被晋升，也可以被解雇！

ARM 革命

2014 年 4 月，微软宣布了对 Azure 的新方法，引入了新的门户和 ARM 模型。我们已经讨论过 ARM 和 RBAC 如何改变了 Azure 资源的管理，使得云端生活变得更加轻松。

但 ARM 带来的另一个选项是 ARM 模板。ARM 模板是 JSON 格式的文件，包含单个资源组中所有资源的信息。我们可以使用 ARM 模板来部署新资源、更新资源或从资源组中删除资源。Azure 门户中的每个资源组都有一个自动化面板，允许我们保存该资源组的 ARM 模板、重新部署资源或将模板下载到本地。这使得我们能够快速且简单地复制资源组中的资源。

这就是为什么在 Azure 中为单一应用程序放置资源是常见做法。如果我们有一个复杂的环境，部署可能需要一些时间，这时 ARM 模板就非常有用。例如，假设我们有一个 SharePoint 集群，其中有运行域控制器角色的 Windows Server，两个 SharePoint 集群服务器，以及两台额外运行 SQL Server 的服务器。这要求我们创建一个虚拟网络，创建五个服务器，并将它们加入到虚拟网络中。手动在 Azure 门户中执行这些操作需要一些时间。但使用 ARM 模板，我们可以在几秒钟内完成这些操作。

使用 ARM 模板部署基础设施只是作为代码的基础设施的一种方式。我们也可以通过 PowerShell 和 Azure CLI 实现类似的功能。使用作为代码的基础设施使我们能够以快速可靠的方式部署运行应用程序所需的基础设施。它也是一种更一致的选择，因为我们排除了部署中的手动任务，创建了自动化过程，并消除了部署中的人为错误。

关于 ARM 模板的另一个好处是，它们可以被添加到我们的应用程序项目中并存储在代码仓库中，我们可以跟踪环境的版本。不同版本的应用程序可能需要改变环境，而通过 ARM 模板和代码仓库，我们可以追踪这些变化，确保为我们要部署的应用程序版本部署正确的环境。

总结一下，ARM 模板是一种快速、可靠、一致的部署 Azure 资源的方法，能够帮助我们跟踪环境版本并自动化部署过程。这对于在软件交付中实现 DevOps 尤为有趣和有用。结合作为代码的配置（我们将在后面的章节中讨论），我们可以构建或复制任何环境，包含所有所需资源，并应用所需配置，确保一切顺利运行。

下面是一个空的 ARM 模板示例：

{
 "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 },
 "variables": {
 },
 "resources": [
 ],
 "outputs": {
 }
}

ARM 模板包含有关参数、变量、资源和输出的信息。通过这些信息，我们定义了需要部署哪些资源，使用哪些参数，以及哪些参数可以是可以更改的变量。最后，我们定义了输出作为回应，但这一部分是可选的。

总结

在本章中，我们解释了云计算类型及其随时间演变的过程，重点介绍了公有云和微软 Azure。下一步是解释公有云服务模型，以及 IaaS、PaaS 和 SaaS 的工作原理和这些公有云类型的基本概念。你还应该了解 Azure 订阅是如何工作的，资源的价格是如何计算的，以及与 Azure 订阅和 ARM 模型相关的基本管理概念。我们提供了关于 ARM 的一般信息，并解释了它如何与 RBAC 和 ARM 模板连接。

理解 Azure 订阅和 ARM 模板，以及 IaaS 和 PaaS 在 Azure 中的应用非常重要，因为我们将在接下来的章节中使用这些知识。

下一步将是 IaaS，作为云计算的第一步。IaaS（以及所有其他 Azure 服务）的基础是 Azure 网络堆栈，我们将从这一部分开始。

问题

哪种类型的云需要互联网连接并允许任何人注册服务？
1. 私有云
2. 托管云
3. 公有云
哪种云服务模型允许我们对资源进行最多的控制？
1. IaaS
2. PaaS
3. SaaS
哪种云服务模型需要最少的管理和行政操作？
1. IaaS
2. PaaS
3. SaaS
哪种云服务模型始终提供最新的功能和更新？
1. IaaS
2. PaaS
3. SaaS
在 Azure 中，是什么负责将客户端环境与其他客户端分隔开？
1. Azure 架构
2. Azure 租户
3. Azure 订阅
Microsoft Azure 中的第一个访问层是什么？
1. Azure 架构
2. Azure 租户
3. Azure 订阅
在 Azure 资源中，你可以分配访问权限的最低粒度是什么？
1. Azure 资源
2. Azure 资源组
3. Azure 订阅
应为 Azure 资源分配什么访问级别是推荐的？
1. Azure 资源
2. Azure 资源组
3. Azure 订阅
如何计算 Microsoft Azure 的定价？
1. 每年
2. 每月
3. 每分钟
ARM 模板属于什么？
1. 基础设施即代码
2. IaaS
3. 配置即代码

第二章：Azure 网络 - Azure IaaS 的基础

我们云旅程中的下一步是 Azure 网络。此步骤将为我们的 Azure 基础设施奠定基础，并将在接下来的章节中为 IaaS 和 PaaS 使用。设计和实施 Azure 网络时，必须考虑到未来将使用的所有 Azure 服务。这将为你节省大量麻烦，并使你的云之旅安全且稳定。

本章将涵盖以下内容：

Azure VNet
地址范围
子网
IP 地址类型和预留
DNS
网络安全组（NSGs）
Azure 虚拟机网络

技术要求

本章内容你需要一个 Azure 订阅。

Azure 网络基础

Microsoft Azure 中的网络栈非常重要，它是其他服务的基础，特别是当我们谈到 IaaS 时。正确设置 Azure 网络非常重要，因为它是设置 IaaS 基础设施并允许虚拟机进行通信的关键。Azure 中的网络栈由两个组成部分构成，外部和私有。外部用于通过互联网访问服务端点，私有用于 Azure 服务之间的内部通信。

几乎所有 Azure 服务默认都有外部端点配置，但在某些特殊情况下，我们不希望启用互联网访问。在这些情况下，我们可以禁用外部端点，并将这些服务设置为仅使用私有流量。这同样适用于 PaaS，尽管这些服务通常默认没有配置私有网络访问（除了某些为此设计的 PaaS 服务，例如隔离应用服务）。在本章中，我们将讨论基本的网络功能，并将在适当时继续探讨针对特定服务的网络选项。

IaaS 通常也有外部端点配置，但我们可以选择禁用这些端点，不允许通过互联网访问。另一方面，IaaS 总是会配置一个私有网络。每个 Azure 虚拟机都必须分配到一个虚拟网络，并分配一个私有 IP 地址。即使我们只配置了一个虚拟机，并希望它仅用于公共互联网访问，系统也会在后台创建一个虚拟网络，并为该虚拟机分配一个私有 IP 地址。

Azure 网络还扩展到 VPN 选项，允许你仅通过私有网络和私有 IP 地址访问服务。这使你能够进一步保护资源，并禁用任何类型的公共访问。我们将在讨论与 Microsoft Azure 的混合云时探讨这些功能和选项。

在 Azure 中创建你的第一个虚拟网络

Azure 虚拟网络（Azure VNet）有两种创建方式：一种是创建新的 VNet，另一种是创建新的 Azure 虚拟机。两者的选项相似，但我建议先创建 Azure VNet，并将虚拟机加入到现有的 VNet 中，因为这样会有更多的选项。

要创建一个新的 Azure Vnet，请打开 Azure 门户，选择“创建资源”，然后在“网络服务”中选择“虚拟网络”（或在搜索栏中搜索Virtual network），如下面的截图所示：

你需要为虚拟网络提供一些参数。资源名称在资源组级别必须唯一，并且必须是单个字符串，不允许有空格。我的资源名称是 PacktVNet，但如果我想分开这两个词，也可以使用 Packt_VNet。接下来的参数是地址空间。这将定义在此 VNet 中可用的 IP 地址数量，使用 CIDR 格式。最大的地址空间是 /8，最小的是 /29。在这种情况下，我将使用 /16，这将为我提供足够的地址空间。我们需要选择放置资源的订阅（仅当有多个订阅时需要选择；如果只有一个订阅，系统将默认选择）。资源组名称有两个选项，可以选择创建一个新的资源组，也可以选择现有的资源组。由于我通常会在创建其他资源之前配置虚拟网络，因此会与 VNet 一起创建一个新的资源组。接下来的步骤是选择我们希望创建资源的区域。我建议选择离你最近的 Azure 数据中心，因为这样将来能提供最低的网络延迟。如果选择了现有的资源组，该选项将自动选择资源组所在的相同区域。你需要为默认子网命名，并为该子网提供地址空间。子网的地址范围必须在 VNet 地址空间的地址范围内。

默认情况下提供基础的 DDoS 保护，是免费的，但你可以选择标准层，它需要单独收费。我们将在第九章，Azure 安全与管理 中进一步讨论 DDoS。以下截图展示了虚拟网络部署所需的信息示例：

最后的选项与服务端点有关。如果我们启用此功能，会显示新的窗口，如下面的截图所示。此选项允许你将 PaaS 服务附加到你的 VNet。你可以选择 Azure Cosmos DB、事件中心、密钥保管库、服务总线、SQL 和存储，或者选择全部。在此，我将禁用端点，稍后我们会讨论它们：

最后一步是确认选项并开始创建资源的过程。Azure 虚拟网络工作相对较快，资源应该在不到一分钟的时间内创建完成。这可能取决于数据中心的工作负载和请求数量，但即使在需求量大的情况下，也应能相对快速地完成。

Azure 虚拟网络代表了你在云中的自有网络。它具备类似于本地网络的特性，例如 IP 地址范围和子网。如果你熟悉本地网络环境的网络设置，那么理解 Azure 网络将会非常容易。

Azure 虚拟网络选项

部署完成后，你会有不同的管理选项可供选择。定位到你的资源组并打开虚拟网络选项卡。在“概览”标签页中，你可以看到有关虚拟网络的不同信息，比如资源组、订阅位置等等。

在设置中，我们有多个可供配置的选项：地址空间、连接设备、子网、DDoS 保护、DNS 服务器、对等连接和服务端点。每个 Azure 资源都有属性、锁定和自动化脚本，而这些不仅仅限于 Azure 虚拟网络。属性提供关于资源的只读信息，锁定显示是否有依赖于该服务的其他服务。自动化脚本会为资源的重新部署生成 ARM 模板。请注意，此选项会为整个资源组生成 ARM 模板，而不仅仅是为某个特定资源。自动化脚本可以在未来的重新部署中使用，万一我们需要为新的客户或新环境复制资源。

在地址空间中，我们可以编辑现有的地址空间或添加新的地址空间。这里有两个限制：地址空间不能重叠，并且不能将一个地址空间缩小到比使用该地址空间的子网还要小。例如，如果你创建了地址空间10.1.0.0/16和子网10.1.0.0/16，那么该地址空间不能更改为小于10.1.0.0/16，除非先更改子网。如何使用地址空间是很重要的；在未来的 VPN 连接中，你不能将 Azure 虚拟网络连接到使用相同地址空间的网络（无论是 Azure 网络还是物理网络）。添加新地址空间可以参见以下截图。确保新的地址空间不会与现有地址空间重叠：

在子网选项卡中，你有两个选择：更改现有子网或添加一个新的子网。对于这两种选项，你必须使用现有的地址空间，且子网不能重叠。现有的子网不能更改为使用比已用的地址空间更少的空间。例如，如果你的地址空间是10.1.0.0/24并且该子网已经有 200 个虚拟机，那么你不能将其更改为小于/24的地址空间，因为/25只有 128 个可用地址。

另一个需要注意的事项是，你在子网中并没有完整的 IP 地址范围；有五个 IP 地址被保留用于 Azure 提供的网络角色，例如 DNS 或 DHCP。说到 DHCP，Azure 不支持自定义 DHCP 解决方案，你必须使用 Azure 提供的 DHCP。DNS 则不同；默认情况下，你使用的是 Azure DNS 服务，但也可以使用自定义解决方案。

要添加一个新子网，你需要提供与 VNet 部署时创建默认子网时相似的信息，但你会有几个额外的选项。你需要提供子网的名称和 IP 地址范围，这些范围必须使用你 VNet 中现有的 IP 地址，并且不能与 VNet 上的其他子网重叠。请注意，在这里你会看到关于为 Azure 网络服务保留五个 IP 地址的信息。类似的 VNet 部署选项是服务端点选项，允许你将 PaaS 服务添加到子网中。你可以将网络安全组分配到子网级别，并分配路由表。

网络安全组（NSG）是你控制 Azure VNet 流量的主要工具，我们稍后会详细讨论它们。Azure 会自动在同一 VNet 上的所有子网之间路由流量，但你可以创建自定义路由表来覆盖默认选项。这在你使用 VPN 或虚拟设备（例如第三方防火墙）时非常有用。如下图所示，这是向 VNet 添加新子网的示例：

DNS 窗格允许我们为 VNet 添加自定义 DNS 解决方案。如前所述，默认情况下这是 Azure 提供的，但你也可以使用自己的 DNS，无论是使用带有 DNS 的虚拟机还是公共 DNS。

如果你有一个 Site2Site 连接到本地网络，那么它可以作为本地网络的 DNS。如果是这种情况，我建议在 Azure 中使用 DNS 的副本。这将使响应更快，并确保在 VPN 连接或本地网络因某些原因不可用时，DNS 仍可在 Azure VNet 中使用。提供自定义 DNS 的选项如下图所示。你需要提供 DNS 服务器的 IP 地址，如果选择使用公共 DNS，则提供公共 IP 地址；如果在 VNet 中部署 DNS，则提供私有 IP 地址：

在部署过程中，我们有机会为 VNet 添加服务端点，但我们可以随时使用服务端点窗格添加，如下图所示。由于添加这些服务会启动一个配置过程，设置路由和规则，因此该过程可能需要最多 15 分钟才能完成。服务端点选项可用于 VNet 和子网级别，因此你可以为整个网络或单个子网启用端点。使用单个子网可以提供更多控制，并能够将 PaaS 服务与虚拟网络的其他部分分离：

对等连接允许你将 VNet 连接到其他 VNet，以便交换流量。这仅适用于同一个 Azure 租户中的 VNet（但可跨该租户中的订阅使用）。你需要为连接指定一个名称，然后选择适当的订阅和虚拟网络。你还有一些额外的选项可以定义，例如是否需要流量转发、是否允许网关中继以及是否使用远程网关。默认情况下，只有来自一个 VNet 的流量会被转发到第二个 VNet。来自对等连接外部的流量（例如来自第二个对等网络，只有一个 VNet 涉及，或者通过网关传输的流量）不会被转发，除非你指定这些选项。

例如，假设我们有三个 VNet：A、B 和 C。A 连接到 B，C 也连接到 B，但 A 和 C 之间没有直接连接。默认情况下，流量会被允许从 A 到 B，从 B 到 A，从 B 到 C，以及从 C 到 B。A 到 C 或 C 到 A 的流量不会被允许。如果我们启用流量转发，A 到 C 和 C 到 A 的流量将会被转发。

虚拟网关也有类似的情况。假设我们有 A 和 B 两个网络，并且这两个 VNet 之间有对等连接。VNet A 有一个虚拟网关，并且已连接到我们的本地网络。默认情况下，A 到 B、B 到 A、本地网络到 A 以及 A 到本地网络的流量都会被允许。除非我们使用额外选项允许网关中继和远程网关的使用，否则本地网络到 B 和 B 到本地网络的流量将不被允许。

另一种实现方式是为每个 VNet 创建一个虚拟网关，并创建一个 Site2Site 连接，这与连接到本地网络时所使用的连接方式相同（我们将在混合云章节讨论这个问题）。这两种方法的主要区别在于，对等连接是免费的，而虚拟网关是收费的。如果你希望连接位于不同租户的两个 VNet，你需要使用虚拟网关；而对等连接仅适用于同一个租户中的 VNet。

为了连接不同的网络，无论是 VNet 到 VNet 还是 VNet 到本地网络，IP 地址空间/子网不能重叠。如果两个网络使用相同的子网，你将无法创建该连接，因为这会造成混淆，并使路由变得不可能。将无法区分哪个设备属于哪个网络，也无法确定流量应该流向哪里。如何在你的订阅中将 VNet 连接到另一个 VNet，如下图所示：

在多个网络通过对等连接或 Site2Site 连接的情况下，建议使用路由表。自定义路由表允许我们在特定情况下创建并转发流量，并定义有关流量应该去往哪里的一些规则。

连接的设备

我们的虚拟网络已经配置好并准备就绪，但我们需要在其中添加资源才能实际使用它。第一步是将新的 Azure 虚拟机添加到虚拟网络中，以便开始使用 Azure 网络栈。

创建 Azure 虚拟机

为了通过门户创建新的 Azure 虚拟机，我们需要执行三个步骤。我们需要选择“新建资源”，然后选择新的虚拟机。我们有成百上千的镜像可供选择，稍后将在章节中讨论这些镜像：

在这种情况下，我们只需要一台虚拟机来展示其网络选项，并且我们将设置所有默认参数以便快速完成。我选择了 Windows Server 2016 镜像，并开始提供所需的基本信息：名称、虚拟机磁盘类型、用户名、密码、订阅、资源组和位置。请注意，在位置选项下，你可以选择创建新的资源组或选择现有的资源组。我选择了“使用现有资源组”，即与我们的虚拟网络所在的资源组相同。

基本虚拟机创建的示例如下所示：

下一步是选择虚拟机的大小。这个步骤与网络部分无关，我将选择系统提供的第一个选项，B1s，见下图：

在最后一步，我们进入了包含网络选项的部分。我将所有其他选项保留默认设置，并专注于网络部分。

首先，我们需要选择虚拟机将连接的虚拟网络（VNet）。我们可以选择一个现有的虚拟网络或创建一个新的虚拟网络。如果没有找到任何虚拟网络，将自动提供新的虚拟网络参数。如果在我们放置虚拟机的资源组中已经存在一个虚拟网络，系统会自动选择该虚拟网络。在我们的案例中，第一步创建的 PacktVNet 在以下截图中显示：

我们的第二个选项是选择虚拟机的子网。如果我们在创建虚拟机的同时也创建了一个新的虚拟网络，这个选项将不可用；只有默认子网会被创建。为了能够在子网之间进行选择，虚拟网络必须在虚拟机之前创建，并且需要指定要使用的子网。在这种情况下，我将选择将虚拟机加入之前创建的 DMZ 子网。选择子网选项如下图所示：

我们还可以选择虚拟机的公共 IP 地址。我们可以选择一个现有的公共 IP 地址（一个不再使用的保留 IP 地址）或创建一个新的公共 IP 地址。网络安全组也是如此：我们可以选择现有的一个或创建一个新的。我将选择为我的虚拟机创建一个新的公共 IP 地址和新的网络安全组，如下图所示：

完成后，虚拟机的部署开始，直到过程完成通常需要几分钟。部署一个新的 Azure 虚拟机所需的时间取决于虚拟机的大小、截图以及对数据中心的请求次数。

IP 地址类型

一旦虚拟机的部署完成，我们可以在虚拟网络刃下的“已连接设备”中看到该设备。以下截图显示了连接设备刃的示例。这里显示的信息包括设备名称、连接的设备类型、私有 IP 地址以及设备分配的子网。IP 地址信息与私有 IP 地址相关，这个 IP 地址是在 VNet 级别分配给我们虚拟机的，仅用于内部流量。请注意，设备类型是网络接口。每个虚拟机都有一个网络接口卡（NIC），用于与网络通信，并且会在创建虚拟机时自动创建一个。虚拟机可以有多个 NIC，如果需要连接多个子网，或者确保虚拟机在一个 NIC 故障时仍然可用。NIC 的数量取决于虚拟机的大小，从基本层虚拟机的 1 个 NIC 到更高层虚拟机的 8 个 NIC：

如果我们点击设备，它将带我们进入 NIC 刃如以下截图所示。我们也可以通过在资源组中选择 NIC 来进入相同的页面。在 IP 配置中，我们可以启用或禁用 IP 转发，改变 NIC 连接的子网，并查看私有和公共 IP 地址的 IP 配置：

私有 IP 地址

如果我们选择 IP 配置，我们将有更多的 IP 地址选项。以下截图展示了一个示例。

默认情况下，公共 IP 地址是启用的，但如果需要，我们可以禁用它。这通常用于虚拟机位于后端且不需要公共曝光的场景。在这种情况下，我们需要确保有其他方式连接到虚拟机，通常是通过 VPN。禁用公共 IP 地址通常发生在混合云场景中，当不需要通过互联网访问时。除了使用分配的公共 IP 地址外，我们还可以在这里创建一个新的 IP 地址。

默认情况下，私有 IP 地址是动态的，并且会随着时间变化。IP 地址的变化不会无缘无故发生，而是在虚拟机重启或关闭的情况下发生。如果我们使用私有 IP 地址与 VNet 上的其他虚拟机通信，我们可能希望保持该地址不变。可以通过将 IP 地址分配方式从动态设置为静态来实现。这将为该 NIC 保留 IP 地址，即使虚拟机长时间关闭：

DNS 是 VNet 和虚拟机级别都可用的另一选项。我们可以为特定的 NIC 分配自定义 DNS。如果我们将 DNS 分配到 VNet 级别，该 DNS 将应用于连接到该 VNet 的所有虚拟机。NIC DNS 的默认选项是继承自虚拟网络设置。在这种情况下，它将是 Azure DNS 或自定义 DNS，具体取决于 VNet 设置。如果我们为 VNet 选择了自定义 DNS，则无法在 NIC 级别选择 Azure DNS。我们唯一的可选项是使用“从虚拟网络继承”或“自定义 DNS”。NIC 级别的 DNS 刀锋如下图所示：

网络安全组

NSG（网络安全组）是一组应用于您的 Azure 网络资源的安全规则。它们是执行和控制资源网络流量规则的主要工具。NSG 可以应用于两种类型的资源：子网和 NIC。如果 NSG 应用于子网，规则将应用于连接到该子网的所有设备。当 NSG 应用于 NIC 时，规则仅适用于该设备。

在 NSG 刀锋的概览中，我们可以看到当前应用的所有规则，包括入站和出站规则。默认情况下，来自外部的所有入站流量都会被禁用，除了 3389 端口，它允许我们远程连接到虚拟机。来自虚拟网络内部或 Azure 负载均衡器的所有入站流量是允许的。这些规则可以根据需要进行编辑和添加。

默认情况下，所有级别的出站流量都允许流向虚拟网络或外部。这些规则也可以编辑，但通常无需限制出站流量。

所有规则都有一个优先级分配给它们；较低的数字表示具有较高优先级的规则。例如，我们有优先级为 1000 的 RDP 规则，以及优先级为 65500 的 DenyAllInBound 规则（该规则会阻止所有入站流量）。即使强制执行了 DenyAllInBound 规则来阻止所有入站流量，允许 RDP 的规则优先级更高，将首先执行。因此，所有入站流量都会被阻止，除了 RDP 规则，由于其优先级更高，允许连接。

NSG 设置可以通过 NIC 刀锋或通过在资源组的资源列表中选择 NSG 打开。NSG 刀锋的概览如下图所示：

要添加新规则，请转到入站安全规则并选择添加新规则。您可以选择基本或高级。如果选择基本，则只会提供一些选项供选择。我建议使用高级，这样可以让您对规则有更多的控制权：

源：对于源，你可以在几个选项之间进行选择。Any将允许来自任何源的流量。IP 地址将仅允许来自指定地址的流量；你可以输入单个 IP 或 CIDR 格式的 IP 地址范围。这对于限制通过端口3389的访问以及保护虚拟机非常有用。服务标签将允许来自特定服务的流量。例如，使用服务标签选项，你可以允许来自 Azure 存储的流量，但阻止其他所有流量。

源的最后一个选项是应用程序安全组（ASG）。ASG 允许你创建规则并仅允许流量进入网络上某一特定资源组。例如，我们在 VNet 中有多个服务器，Web 服务器和数据库服务器。允许通过端口1433到数据库服务器的流量应该对 Web 服务器启用，但不允许通过互联网。将 Web 服务器放入 ASG 并创建规则，可以只允许 Web 服务器通过端口1433访问我们的数据库，并阻止任何其他流量。
源端口范围：通过源端口范围，我们还可以限制流量，仅允许来自特定端口或端口范围的流量。
目标端口范围：目标端口范围选项与源选项类似；我们有相同的可用选项集。ASG 可以用于仅允许网络中特定类型的虚拟机访问。例如，将 Web 服务器放入 ASG，并允许通过端口443或80的流量，这样就只有这些服务器可以通过这些端口进行访问，并且阻止对任何其他类型虚拟机的流量。

目标端口范围允许我们指定流量允许经过的端口，可以将其限制为单一端口或一个范围。
协议：它帮助我们定义哪些协议是允许的，可以选择 TCP 或 UDP。
操作：它定义了这个规则是用于允许流量还是阻止流量。NSG 可以双向使用，它可以帮助我们定义是否允许特定的流量，但也可以用于拒绝流量，从而帮助我们在 Azure 中保护资源。
优先级：此选项非常重要，因为它帮助我们定义首先应用哪些规则，哪些规则具有优先权。如前所述，分配给规则的优先级数字越低，规则的优先级越高。规则会按顺序处理，从最高优先级的规则（数字最小）到优先级较低的规则（数字较大），直到满足条件。一旦条件满足，规则就会被处理，并且规则处理停止。例如，我们创建一个规则，阻止所有通过端口1433的流量，并给它优先级1000，然后创建一个规则，允许某些来源通过端口1433的流量，优先级为2000。由于优先级较高的规则正在阻止该流量，因此端口1433上的流量永远无法通过。
名称：最后的选项是为规则命名并输入描述。描述是可选的，但我建议您填写，因为这将帮助您日后跟踪和理解为何首次创建某个规则。

示例设置展示了 NSG 中高级选项的配置，如下截图所示：

NSG 可以应用于两个级别，即网络接口卡 (NIC) 和子网。如果将 NSG 应用于 NIC，则该 NSG 中定义的规则仅对连接到该 NIC 的虚拟机生效。如果将 NSG 应用于子网，则该子网上的所有虚拟机都将遵循这些规则。

在某些情况下，可以同时在子网和 NIC 上应用 NSG。在这种情况下要小心配置，因为只有在两个级别都允许的流量才会通过。如果在子网级别允许端口 80 的流量但在 NIC 级别阻止，端口 80 上将不会有流量通过。反之亦然，如果在 NIC 上允许但在子网上阻止，则端口上也不会有流量通过。如果要在已在子网和 NIC 级别应用了 NSG 的 VM 上阻止某些内容，只需在其中一个 NSG 上阻止命名端口上的流量即可。

使用 NSG 与 ASG 结合是保护和确保资源安全的最佳方式。

让我们创建一个场景，其中我们有三组服务器：web、应用和数据库。

我们需要使 web 服务器能够连接到应用服务器，应用服务器能够连接到数据库服务器。仅允许通过互联网连接到 web 服务器，而我们不希望在任何情况下通过互联网连接到数据库服务器。第一步是创建三个 Azure 安全组，每个安全组用于一个服务器角色。接下来是使用 ASG 配置 NSG 规则。

仅允许通过互联网连接到位于 web ASG 中的服务器。仅允许来自位于 web ASG 中的服务器的流量连接到应用服务器。通过设置一条规则来实现此目标，该规则允许来自应用 ASG 的流量到达应用 ASG，阻止其他一切。最后，我们创建一条规则，允许仅在流量来自应用 ASG 时连接到数据库服务器 (数据库 ASG)。

这种方法使管理和维护变得更加简单和一致。如果要将服务器添加到任何三个池中的一个，您需要设置适当的规则并应用所需的设置。很容易犯错，导致该服务器未拥有所有必要的连接，或者在最坏的情况下成为安全问题。使用 NSG 和 ASG 来跟踪所有规则时，我们只需将新服务器添加到适当的 ASG 中，所有规则和设置将自动应用。

公共 IP 地址

公共 IP 地址设置可以通过 NSG 设置进行访问，或者通过在资源组面板中选择公共 IP 地址来访问。

公共 IP 地址的设置与私有 IP 地址类似。默认情况下，它们是动态的，因此在重启或关机时，IP 可能会发生变化，但我们可以将此设置更改为静态。静态 IP 会保留我们的 IP 地址，但在这种情况下，公共 IP 地址和私有 IP 地址之间有一个区别。私有 IP 地址的保留是免费的，因为这是一个内部 IP 地址，所以你可以选择范围，甚至为特定虚拟机（VM）保留该范围内的 IP 地址。而公共 IP 地址是分配的，并且没有选择所需 IP 地址的选项。另一个区别是，公共 IP 地址的保留是收费的；每个订阅可以免费保留前五个公共 IP 地址，但超过这个数量的每次保留都将收费。超过前五个公共 IP 地址的保留价格并不高（大约每月$3），但了解你为此付费是很重要的。

如果你想限制访问，可以从 NIC 中删除公共 IP 地址（私有 IP 地址不能删除）。如果你选择使用公共 IP 地址，你可能需要它来远程连接到虚拟机，或者用于应用程序。如果你不想创建保留，还有一个选项，可以使用 DNS 名称标签。此选项将为你的 NIC 分配一个 DNS 名称，你可以使用它来访问虚拟机。任何公共 IP 地址的变化（可能由于虚拟机重启或关机而发生）将由 Azure DNS 处理。公共 IP 地址配置的选项如下图所示：

其他 Azure 网络服务

我们目前所涵盖的 Azure 服务只是 Azure 网络栈的一部分。Azure 网络栈并不止于此，还有许多其他与网络相关的 Azure 服务，例如流量管理器、负载均衡器或虚拟网关。其中一些将在后续章节中介绍。

例如，我们将讨论具有虚拟机高可用性的负载均衡器。当我们讨论 PaaS 的高可用性时，流量管理器将是一个类似的案例。虚拟网关将在关于 Microsoft Azure 混合云的章节中讨论。

混合场景和安全性可以通过虚拟设备进行管理。虚拟设备是带有第三方防火墙软件的 Azure 虚拟机。大多数领先的行业防火墙都受支持并可用（例如 Barracuda、CheckPoint、Cisco 和 PaloAlto）。虚拟设备的虚拟机镜像可以通过 Azure 市场获得，你可以轻松配置并设置虚拟设备，使用它来管理和保护你的 Azure 网络。

然而，Microsoft Azure 正在不断发展，越来越多的服务正在推出。涵盖所有服务和功能是不可能的。本书的每一章都可能成为一本独立的书。

ARM 模板

我们已经讨论了 ARM 模板以及它们如何帮助我们实现自动化。在本章中，我创建了一个虚拟网络，并将一台虚拟机加入到该网络中。

如果您转向自动化，您可以找到一个 JSON 格式的 ARM 模板，您可以使用它重新部署我的资源。该 ARM 模板将包含所有资源和所有设置：虚拟网络及其参数、包含有关镜像和大小的虚拟机、NSG 规则等。它将包含所有依赖项的信息，以及需要首先创建的内容。例如，为了创建虚拟机，需要先创建一个子网，将虚拟机加入到该子网，而子网无法在虚拟网络创建之前创建。

请注意，某些参数（例如密码）没有提供，因为密码不能以明文显示，只能作为安全字符串提供，因此您需要手动提供这些参数：

{
 "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "virtualMachines_PacktVM1_name": {
 "defaultValue": "PacktVM1",
 "type": "String"
 },
 "virtualNetworks_PacktVNet_name": {
 "defaultValue": "PacktVNet",
 "type": "String"
 },
 "networkInterfaces_packtvm1240_name": {
 "defaultValue": "packtvm1240",
 "type": "String"
 },
 "publicIPAddresses_PacktVM1_ip_name": {
 "defaultValue": "PacktVM1-ip",
 "type": "String"
 },
 "networkSecurityGroups_PacktVM1_nsg_name": {
 "defaultValue": "PacktVM1-nsg",
 "type": "String"
 },
 "subnets_DMZ_name": {
 "defaultValue": "DMZ",
 "type": "String"
 },
 "subnets_default_name": {
 "defaultValue": "default",
 "type": "String"
 },
 "securityRules_default_allow_rdp_name": {
 "defaultValue": "default-allow-rdp",
 "type": "String"
 },
 "adminUsername": {
 "type": "string",
 "metadata": {
 "description": "Default Admin username"
 }
 },
 "adminPassword": {
 "type": "securestring",
 "metadata": {
 "description": "Default Admin password"
 }
 }
 },
 "variables": {},
 "resources": [
 {
 "type": "Microsoft.Compute/virtualMachines",
 "name": "[parameters('virtualMachines_PacktVM1_name')]",
 "apiVersion": "2017-12-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "hardwareProfile": {
 "vmSize": "Standard_B1s"
 },
 "storageProfile": {
 "imageReference": {
 "publisher": "MicrosoftWindowsServer",
 "offer": "WindowsServer",
 "sku": "2016-Datacenter",
 "version": "latest"
 },
 "osDisk": {
 "osType": "Windows",
 "name": "[concat(parameters('virtualMachines_PacktVM1_name'),'_OsDisk_1_b6ae3bba44ef491f8c2acd7bfb5aa975')]",
 "createOption": "FromImage",
 "caching": "ReadWrite",
 "managedDisk": {
 "storageAccountType": "Standard_LRS"
 },
 "diskSizeGB": 127
 },
 "dataDisks": []
 },
 "osProfile": {
 "computerName": "[parameters('virtualMachines_PacktVM1_name')]",
 "adminUsername": "[parameters('adminUsername')]",
 "adminPassword": "[parameters('adminPassword')]",
 "windowsConfiguration": {
 "provisionVMAgent": true,
 "enableAutomaticUpdates": true
 },
 "secrets": []
 },
 "networkProfile": {
 "networkInterfaces": [
 {
 "id": "[resourceId('Microsoft.Network/networkInterfaces', parameters('networkInterfaces_packtvm1240_name'))]"
 }
 ]
 },
 "diagnosticsProfile": {
 "bootDiagnostics": {
 "enabled": true,
 "storageUri": "https://nagiosdiag316.blob.core.windows.net/"
 }
 }
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/networkInterfaces', parameters('networkInterfaces_packtvm1240_name'))]"
 ] 
 },
 {
 "type": "Microsoft.Network/networkInterfaces",
 "name": "[parameters('networkInterfaces_packtvm1240_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "2d51720b-041b-4248-ab04-8dd9fd3fa7d9",
 "ipConfigurations": [
 {
 "name": "ipconfig1",
 "etag": "W/\"b681e202-2d98-4d28-a30d-aaf93b9f1243\"",
 "properties": {
 "provisioningState": "Succeeded",
 "privateIPAddress": "10.1.1.4",
 "privateIPAllocationMethod": "Static",
 "publicIPAddress": {
 "id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPAddresses_PacktVM1_ip_name'))]"
 },
 "subnet": {
 "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworks_PacktVNet_name'), parameters('subnets_DMZ_name'))]"
 },
 "primary": true,
 "privateIPAddressVersion": "IPv4"
 }
 }
 ],
 "dnsSettings": {
 "dnsServers": [],
 "appliedDnsServers": [],
 "internalDomainNameSuffix": "gbyhmwrx0mmutogdwlxg2i521c.ax.internal.cloudapp.net"
 },
 "macAddress": "00-0D-3A-2E-EA-03",
 "enableAcceleratedNetworking": false,
 "enableIPForwarding": false,
 "networkSecurityGroup": {
 "id": "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_PacktVM1_nsg_name'))]"
 },
 "primary": true
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPAddresses_PacktVM1_ip_name'))]",
 "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworks_PacktVNet_name'), parameters('subnets_DMZ_name'))]",
 "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_PacktVM1_nsg_name'))]"
 ]
 },
 {
 "type": "Microsoft.Network/networkSecurityGroups",
 "name": "[parameters('networkSecurityGroups_PacktVM1_nsg_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "11b65174-a94e-44e1-947c-dd140c45a6c8",
 "securityRules": [
 {
 "name": "default-allow-rdp",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "protocol": "TCP",
 "sourcePortRange": "*",
 "destinationPortRange": "3389",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Allow",
 "priority": 1000,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 }
 ],
 "defaultSecurityRules": [
 {
 "name": "AllowVnetInBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow inbound traffic from all VMs in VNET",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "VirtualNetwork",
 "destinationAddressPrefix": "VirtualNetwork",
 "access": "Allow",
 "priority": 65000,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "AllowAzureLoadBalancerInBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow inbound traffic from azure load balancer",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "AzureLoadBalancer",
 "destinationAddressPrefix": "*",
 "access": "Allow",
 "priority": 65001,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "DenyAllInBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Deny all inbound traffic",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Deny",
 "priority": 65500,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "AllowVnetOutBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow outbound traffic from all VMs to all VMs in VNET",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "VirtualNetwork",
 "destinationAddressPrefix": "VirtualNetwork",
 "access": "Allow",
 "priority": 65000,
 "direction": "Outbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "AllowInternetOutBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow outbound traffic from all VMs to Internet",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "Internet",
 "access": "Allow",
 "priority": 65001,
 "direction": "Outbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "DenyAllOutBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Deny all outbound traffic",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Deny",
 "priority": 65500,
 "direction": "Outbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 }
 ]
 },
 "dependsOn": []
 },
{
 "type": "Microsoft.Network/publicIPAddresses",
 "sku": {
 "name": "Basic",
 "tier": "Regional"
 },
 "name": "[parameters('publicIPAddresses_PacktVM1_ip_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "972b3091-fe6e-49cc-bd06-22d260608254",
 "ipAddress": "40.74.60.181",
 "publicIPAddressVersion": "IPv4",
 "publicIPAllocationMethod": "Dynamic",
 "idleTimeoutInMinutes": 4,
 "ipTags": []
 },
 "dependsOn": []
 },
{
 "type": "Microsoft.Network/virtualNetworks",
 "name": "[parameters('virtualNetworks_PacktVNet_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "5a767030-d337-4919-b8c3-b2ee6e23fcda",
 "addressSpace": {
 "addressPrefixes": [
 "10.1.0.0/16",
 "10.2.0.0/16"
 ]
 },
 "subnets": [
 {
 "name": "default",
 "etag": "W/\"98f91850-e7b2-40b6-8043-1caa5bf4865a\"",
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.0.0/24",
 "serviceEndpoints": []
 }
 },
 {
 "name": "DMZ",
 "etag": "W/\"98f91850-e7b2-40b6-8043-1caa5bf4865a\"",
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.1.0/24",
 "serviceEndpoints": []
 }
 }
 ],
 "virtualNetworkPeerings": [],
 "enableDdosProtection": false,
 "enableVmProtection": false
 },
 "dependsOn": []
 },
{
 "type": "Microsoft.Network/networkSecurityGroups/securityRules",
 "name": "[concat(parameters('networkSecurityGroups_PacktVM1_nsg_name'), '/', parameters('securityRules_default_allow_rdp_name'))]",
 "apiVersion": "2018-02-01",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "protocol": "TCP",
 "sourcePortRange": "*",
 "destinationPortRange": "3389",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Allow",
 "priority": 1000,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_PacktVM1_nsg_name'))]"
 ]
 },
{
 "type": "Microsoft.Network/virtualNetworks/subnets",
 "name": "[concat(parameters('virtualNetworks_PacktVNet_name'), '/', parameters('subnets_default_name'))]",
 "apiVersion": "2018-02-01",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.0.0/24",
 "serviceEndpoints": []
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_PacktVNet_name'))]"
 ]
 },
{
 "type": "Microsoft.Network/virtualNetworks/subnets",
 "name": "[concat(parameters('virtualNetworks_PacktVNet_name'), '/', parameters('subnets_DMZ_name'))]",
 "apiVersion": "2018-02-01",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.1.0/24",
 "serviceEndpoints": []
 },
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_PacktVNet_name'))]"
]
}
]
}

一旦我们在资源组中部署了多个资源，这将特别有帮助。使用这些模板，我们可以自动、快速且精准地配置相同的环境。手动重新部署资源组以重新创建环境可能会导致不一致和漏掉步骤。而使用 ARM 模板，每次都会产生相同的结果。

总结

我们已经覆盖了 Azure 网络的基本功能，包括虚拟网络、IP 地址类型和 NSG。这些关于 Azure 网络的基本知识将成为后续章节的基础。

理解 ARM 模板也非常重要，因为一旦我们的基础设施变得更复杂，它们将非常有帮助。

从这里开始，我们将深入探讨 Azure IaaS，它将使用 Azure 网络作为支撑，并且是将一切整合在一起的服务。我们将展示如何创建高级 VM 场景，这些场景将使用 Azure 网络，私有网络用于 VM 之间的通信，公共网络用于外部访问。我们将更详细地解释如何创建新的 Azure 虚拟机、可用性组以及在 Azure 中为 IaaS 提供高可用性的选项。

问题

哪些服务依赖于 Microsoft Azure 中的 Azure 网络？
1. IaaS
2. PaaS
3. 两者
什么定义了 Azure 中的 IP 地址范围？
1. 子网掩码
2. CIDR
3. RIP
服务端点用于将哪些服务连接到您的虚拟网络？
1. 虚拟机
2. PaaS
3. SaaS
Microsoft Azure 中的默认 DNS 服务是...?
1. Azure DNS
2. 公共 DNS
3. 自定义 DNS
什么时候可以添加服务端点？
1. 创建虚拟网络时
2. 创建虚拟网络后
3. 任何时候
Azure 中的私有 IP 地址可以是...?
1. 动态
2. 静态
3. 两者
Azure 中的公共 IP 地址可以是...?
1. 动态
2. 静态
3. 两者
NSG 是什么？
1. 定义流量流向的安全规则
2. 关于 IP 地址预留的规则
3. 两者
NSG 定义了什么？
1. 出站流量规则
2. 入站流量规则
3. 两者
NSG 不能分配给什么？
1. 虚拟网络
2. 网络接口卡（NIC）
3. 子网

第三章：基础设施即服务 - 云计算的第一层

在我们的云旅程中的下一步是利用 Azure 虚拟机作为 Azure IaaS 的一部分。这是将工作负载转移到云端的第一个逻辑步骤，因为管理 Azure 虚拟机与管理本地虚拟机并无多大不同。虽然我们不再访问虚拟化主机和硬件，但管理 Azure VM 与管理本地服务器或虚拟机没有任何区别。

我们将向您展示如何实现服务的高可用性以及如何扩展工作负载，这是 Microsoft Azure 提供的主要优势之一。

本章涵盖的领域包括：

创建 Azure 虚拟机
管理 Azure 虚拟机
创建 Azure 负载均衡器
配置 Azure 负载均衡器
创建 Azure 虚拟机规模集

技术要求

本章需要：

Azure 订阅

部署 Azure 虚拟机

任何 Azure 资源的部署都可以通过多种方式进行，Azure 虚拟机也不例外。我们可以使用 Azure 门户、ARM 模板、Azure PowerShell 或 Azure CLI。我们将讨论所有这些方法，但目前我们将专注于使用 Azure 门户，并偶尔使用 ARM 模板。这是为了更好地了解 Azure 服务以及每次部署创建了什么。其他工具在长远来看也会对我们有所帮助，特别是当我们谈论重新部署和自动化时，但这部分我们稍后再谈。

我们已经快速创建了一个 Azure VM，但这一次我们将更仔细地查看可用的选项，因为上次我们只考虑了 Azure 网络部分作为重点。

创建新的 Azure 虚拟机

要创建新的 Azure VM，我们需要选择新资源并选择新虚拟机。

第一步是为我们的 VM 选择操作系统。Windows 和 Linux 都有数百个可供选择的镜像。重要的是要提到，越来越多的 Linux VM 每天都被部署到 Azure 中。来自 2017 年底的信息告诉我们，超过 40% 的所有 Azure 虚拟机正在运行 Linux，而该百分比可能自那时以来已经增加。

Azure 中支持的 Windows Server 版本有：

Windows Server 2008 R2 SP1
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016

对于 Linux，有太多版本以至于无法一一列举，但支持的发行版包括：

Ubuntu
CentOS
RHEL
Kali
Oracle

所有镜像都可以选择最小安装或预配置安装额外软件。例如，我们可以选择默认设置的 Windows Server 2016 或选择已安装 SQL Server 并且准备好使用的镜像。对于 Linux，我们可以选择最小安装，或者选择已配置好软件如 Chef、Puppet、Jenkins 等的镜像。

还可以选择自定义映像，使用自己选择的配置和软件。这可以是上传到 Azure 的本地虚拟机映像，也可以是从另一个 Azure 虚拟机创建的映像。

选择操作系统后，我们将进入一个新的面板，指导我们完成三个阶段。

基本 Azure 虚拟机信息

第一步是为我们的虚拟机提供基本信息。Azure 中的任何资源都需要提供名称。最好根据过程和角色为资源命名，这将有助于后续管理。当虚拟机的名称能提示其用途时，管理起来会更方便。由于我打算将其用作 web 服务器，因此我会将其命名为WebSrv1。

VM 磁盘类型让我们可以在两种值之间选择——HDD 和 SSD。磁盘类型对虚拟机性能有重大影响，因此选择合适的磁盘类型对我们非常关键。由于磁盘类型也会影响虚拟机的价格，我们需要在预期工作负载的基础上找到平衡。若我们创建的是 web 服务器，选择 HDD 可能就足够了，但如果打算部署数据库服务器，推荐选择 SSD。

用户名选项不允许我们使用如 Admin、Administrator、SysAdmin 等常见服务器用户名。这是为了保护你的云资源。由于大多数带有公网 IP 地址的 Azure 虚拟机可以通过 RDP 访问，因此限制访问非常关键。我有多台虚拟机每天都受到攻击，最常见的攻击就是使用这些用户名。我们可以为虚拟机和用户名应用额外的安全措施，但这些将在后续章节中讨论。

与其他资源类似，我们需要提供虚拟机部署所在的订阅、资源组和位置等信息。这里可以看到一个基本信息的示例：

Azure 虚拟机规格

创建虚拟机的第二步是选择虚拟机的规格。虚拟机的规格将决定三项内容——CPU 数量、内存大小以及操作系统磁盘类型。由于在第一步中也选择了磁盘类型，这将缩小可用选项范围。虚拟机规格有三个不同的定价层级：

基础
标准
低优先级

基础层虚拟机用于开发/测试环境，尽管它们与标准层虚拟机在性能上相似，但有一些限制。它们的 IOPS 比标准层虚拟机低，并且不支持负载均衡或自动扩展。

标准层虚拟机用于生产环境，提供更好的 CPU 和 IOPS 性能。

低优先级虚拟机根据 Azure 数据中心中空闲和未使用的资源分配。它们价格较低，但可能随时不可用，因为微软 Azure 可能会回收这些资源以满足更高优先级的请求。它们主要用于批处理和随机任务。

但定价层级并不是唯一决定虚拟机价格的因素。每个层级都有不同的大小，提供一定数量的 CPU 和内存；数量越高，价格越高。

标准层根据虚拟机的用途有额外的类别：

一般用途
计算优化型
内存优化型
存储优化型
GPU
高性能计算

这些大部分都不难理解，一般用途虚拟机有平衡的 CPU 与内存比例，计算优化型有更多的 CPU，内存优化型有更多的内存，存储优化型有最佳的 IOPS。GPU 是专门用于重型图形渲染和视频编辑的虚拟机。高性能虚拟机至少有八个虚拟 CPU，并使用 DDR4 内存。

虚拟机的大小还决定了可以附加到虚拟机的网络接口卡（NIC）的数量。

这个数量从一个到八个不等，具体取决于用途和大小。

可以在以下截图中查看选择虚拟机大小的选项：

高级虚拟机选项

第三部分提供了配置许多额外设置的选项。在上一章中，我们只关注了网络部分，但这一次我们将更仔细地探索这些选项。

高可用性部分提供了两个选项——可用性区域和可用性集。

可用性区域决定了 Azure 数据中心内的区域。这些区域有独立的电源、网络和冷却系统，能够保护你的虚拟机免受数据中心内故障的影响。如果你有需要在多个虚拟机上运行的关键服务，你应该将这些虚拟机放置在不同的可用性区域中，这样如果数据中心级别发生故障，所有虚拟机受到影响的可能性就会减少。

可用性集在主机级别做类似的事情，确保你的虚拟机分布在多个物理服务器、计算机机架、存储单元和网络交换机上。如果发生硬件故障，所有虚拟机受到影响的可能性较小。

请注意，这些可用性选项在后续不能更改。在创建过程中需要定义可用性区域和可用性集。如果你计划设计高可用性解决方案和服务，这一点特别重要。

我将把这个虚拟机放入名为（new）WebSet 的可用性集，因为我打算稍后使用它。

存储选项允许我们选择磁盘类型和使用托管磁盘。磁盘类型选项与之前一样，我们可以选择 HDD 或 SSD。根据所选择的虚拟机大小，并非所有类型的磁盘都可以在此处选择。如果你想选择一个不可用的选项，你需要返回并选择一个不同的虚拟机大小。

使用托管磁盘可以让我们的工作变得更加轻松。这个选项自 2017 年 2 月起提供，在此之前，我们需要自己管理存储。创建一个磁盘实际上是创建一个存储账户，我们需要管理该存储。使用托管磁盘后，我们不必关心这些，所有的管理都会自动完成。虽然存储依然会被创建，但如果选择使用托管磁盘，一切都会在后台处理，无需用户操作。尤其是在扩展虚拟机（或虚拟机规模集）时，这个功能特别有用。托管磁盘还引入了一些非常实用的功能，如快照和备份。我强烈建议使用托管磁盘，因为它可以帮助你获得更好的性能，且管理更简便。

高可用性和磁盘设置可以在下面的截图中看到：

网络选项在前一章中已经讨论过，但我们快速回顾一下这里的选项。我们可以选择虚拟网络（VNet）、该 VNet 上的子网以及虚拟机的公共 IP 地址。最后一个网络选项是选择网络安全组（NSG）用于虚拟机。在下面的截图中，你可以看到我选择了 PacktVNet 和 DMZ（10.1.1.0/24）子网。由于我打算将其作为 Web 服务器使用，所以为我的新虚拟机创建了一个新的公共 IP 地址。由于我已经在 DMZ 子网上应用了 NSG 规则，我不想在虚拟机级别单独设置 NSG。这将帮助我简化管理，并保持所有虚拟机上的标准化规则，因此我会像下面这样保持 NSG 字段为空：

扩展功能使我们可以为虚拟机添加额外的功能。你可以从预设的软件中选择，或者执行自定义脚本来安装额外的软件或功能。

自动关机可以帮助你节省计算时长，如果你不需要虚拟机 24 小时运行。例如，如果这是一个dev环境，且下班后没有人使用它，你可以设置自动关机，每天在下午 5 点关机，这样你就不用为它支付夜间费用。当然，如果这是一个生产环境中的 Web 或数据库服务器，那就不建议使用这个选项。

监控可以启用启动诊断和客户操作系统监控。这是默认情况下提供的基本监控选项之外的功能。启用这两个选项需要一个存储账户来存储日志。避免使用虚拟机磁盘的存储，因为这可能导致性能问题。如果虚拟机在磁盘层面出现性能问题，这将生成更多日志，这些日志将进一步增加存储的负载。这会导致更多的磁盘问题，进入一个无法分辨问题是由磁盘还是日志引起的无限循环。

最后的选项是托管服务标识和备份。托管服务标识允许你使用 Azure Active Directory 来管理虚拟机，而备份将创建一个额外的备份服务（Azure 备份）。这两个服务将在后续章节中详细讨论。

以下截图显示了扩展、自动关机、监控、托管服务标识和备份的选项：

最后，我们可以开始部署，几分钟后便可以开始使用我们的虚拟机。如前所述，创建新虚拟机所需的时间可能取决于虚拟机的大小和 Azure 数据中心中的资源可用性。

管理 Azure 虚拟机

部署完成后，我们可以看到已经创建了四个不同的资源——虚拟机、磁盘、网络接口和公共 IP 地址。公共 IP 地址是可选的，如果你打算仅使用私有 IP 地址并通过 VPN 管理虚拟机，则不需要创建公共 IP 地址。如果没有选择托管磁盘，那么这里也会有一个存储账户，用来存放磁盘，如下所示：

每一个这些资源都有不同的管理选项。我们已经看过了 IP 地址和 NIC 的选项，稍后我们会探讨磁盘和存储的选项。目前，让我们集中关注虚拟机以及可用的管理选项。

虚拟机设置

在虚拟机刀片下，我们有多个选项，如设置、操作、监控和支持。在设置下，我们还有多个选项：网络、磁盘、大小、安全、扩展、可用性集和配置。属性、锁和自动化脚本也适用于所有其他 Azure 资源。请注意，我们这里还有“持续交付（预览）”。预览功能仍在开发中，不能用于生产环境。测试是可以的，但在这些功能正式发布之前，最好不要依赖它们。在这种情况下，持续交付（预览）允许我们连接到 VSTS 项目，并简化 CI/CD 流程。

这里的一些选项与虚拟机创建过程中的选项类似。大小允许我们随时打开刀片，选择不同的虚拟机大小。请注意，要完成此过程，虚拟机需要重启。扩展可以用来添加软件或执行自定义脚本，与之前一样。可用性集仅供参考，因为此设置需要在虚拟机创建时定义。安全性和配置将是我们接下来章节的重点，暂时我们将这些设置保留为默认值。

网络选项为我们提供了关于虚拟机所有网络信息的概览。我们可以看到网卡信息、与虚拟机关联的地址、与虚拟机关联的网络安全组以及所有的 NSG 规则。我们可以在此处附加额外的网卡，并添加额外的 NSG 规则。请注意，在下面的截图中，NSG 应用于子网级别。如果对 NSG 进行更改，这些更改将应用于该子网中的所有虚拟机，因此需要小心。例如，如果这个子网有多个虚拟机，并且我们想为其中的某一个虚拟机允许 RDP 访问，创建这个规则将导致所有虚拟机都可以通过 RDP 访问：

在磁盘刀片下，我们可以看到与虚拟机关联的所有磁盘。操作系统磁盘无法更改，但可以添加或移除数据磁盘。以下截图展示了磁盘刀片的示例：

Azure 虚拟机操作与监控

操作（OPERATIONS）和监控（MONITORING）为我们提供了更多的 Azure 虚拟机管理和操作选项。在操作（OPERATIONS）中，我们有自动关机、备份、灾难恢复、更新管理、清单、变更跟踪和运行命令。我们将现在解释自动关机和运行命令，但这些其他功能需要额外的服务，稍后我们会介绍。

我们在监控（MONITORING）方面有类似的情况，我们现在将介绍“指标”和“警报（经典）”，而其他服务将在后续章节中讲解。

自动关机选项使您可以安排在 Azure 中关闭虚拟机。如前所述，如果我们不需要虚拟机全天运行，这个选项可以帮助我们节省开销。此功能旨在用于 dev/test 环境，而不适用于生产环境。

然而，我也见过一些人将其用于只在工作时间需要的应用程序。在这种情况下，自动关机用于在特定时间关闭虚拟机，并使用 Azure 自动化在工作时间开始前启动虚拟机。除此之外，我们还可以在虚拟机关闭前发送通知，以告知使用该虚拟机的人员即将关闭。我们可以使用电子邮件或 Webhook 进行通知。以下截图展示了 run 脚本选项。我们可以使用各种预设脚本，如 EnableAdminAcount、SetRDPPort、ResetAccountPassword 等等，或者执行自定义脚本。脚本执行选项可以在以下截图中看到：

运行命令可以直接通过门户完成。这在我们无法以其他方式访问虚拟机时（例如，通过移动设备或没有 PowerShell 的机器）非常有用。以下截图展示了启用 PSRemoting 的脚本执行示例：

这里还有一个脚本，用于在 Azure 虚拟机上启用 PSRemote：

Enable-PSRemoting -Force
New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action Allow -Direction Inbound -LocalPort 5986 -Protocol TCP
$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername""; CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command

监控您的 Azure 资源在多个方面都很重要。它使您能够查看资源的消耗情况，并相应地规划定价层级。如果监控显示您的资源工作负载处于某个百分比以下，可能是时候降低资源层级了。如果情况相反，您的资源长期处于高负载，可能需要更高的层级。提供了许多不同的指标，但对于 CPU 和内存监控，您需要启用客户级别的监控。指标让我们可以根据不同的时间周期改变不同的度量值。下面的截图展示了一个示例，您可以看到过去一小时磁盘 读 和 写 操作的图表：

警报是 Azure 资源管理的重要组成部分，可以在关键时刻救命。在警报中，您可以创建自定义规则，如果激活了定义的触发条件，将通知您。例如，您可以设置警报，当 CPU 使用率在超过 5 分钟的时间段内达到 90% 时，会通知您。类似于自动关机，您可以通过电子邮件或 Webhook 发送通知。

以下截图展示了这个示例：

除了发送通知外，还可以通过使用运行手册或逻辑应用程序设置警报，以触发自定义操作。两者都是在需要时执行自定义操作的强大工具。逻辑应用程序通过工作流图使其易于使用，您可以拖放需要执行的操作，以进行一些维护任务或解决问题。运行手册需要一个 Azure 自动化帐户，并且可以根据预定义的计划或使用自定义脚本执行操作。大多数管理员发现运行手册更有用，因为它们允许您使用 PowerShell 执行任何类型的操作。依我看，两者都非常有用，但管理员更熟悉运行手册，因为他们可以使用 PowerShell，这是他们用于本地管理的工具：

如果我们选择通过运行手册执行某个操作，我们可以选择用户定义的操作或内置操作。使用用户定义的操作时，您需要选择一个自动化帐户，并在该帐户中选择要执行的自定义运行手册。这可以是任何类型的脚本，将在您的 Azure 虚拟机上执行。

内置操作提供了五个选项：重启虚拟机、停止虚拟机、扩展虚拟机、缩减虚拟机和移除虚拟机。以下是一个运行手册配置的示例，其中列出了内置运行手册：

这些操作大多数是显而易见的，但请注意你有扩展虚拟机和缩减虚拟机选项。这允许我们根据需求对资源进行扩展或缩减。云计算的一个好处就是按需付费。因此，如果我们的虚拟机在 90% 的时间里能够处理工作负载，但工作负载偶尔会有高峰，我们就应该避免仅为了满足高峰期而支付更多费用。如果我们为了应对高峰工作负载而永久性地扩展虚拟机，我们就需要支付更多费用，而此时的虚拟机并未充分利用，在 90% 的时间里可能一台价格较低的虚拟机就能应对所有工作负载。设置扩展虚拟机规则可以让你在 CPU 达到 90% 时将虚拟机大小调整到更高的等级，这样就能在阈值达到时应对工作负载并按需增加虚拟机大小。为了充分利用 Microsoft Azure 提供的功能，你需要在另一方向创建一个类似的规则，以便在工作负载减少时进行缩减。当只创建扩展规则时，虚拟机的费用会增加，你最终会支付更多费用。为了防止这种情况，你可以创建一个规则，当 CPU 低于 40% 时执行缩减虚拟机操作，并将虚拟机恢复到原始大小。通过这种方式，你只会在工作负载高峰时支付更多费用，而在工作负载不高时支付更少的费用。

支持 + 故障排除部分为我们提供了一些额外的选项。资源健康和新的支持请求是所有 Azure 资源都有的选项。第一个选项可以在 Azure 数据中心层面上提供有关虚拟机是否存在问题的信息，第二个选项则会将你带到提交 Azure 支持票据的表单。资源健康可以帮助你检查当资源的表现不如预期时的情况。这可以节省你故障排除的时间，避免你浪费精力去弄清楚发生了什么问题，实际上可能是数据中心层面出现了重大问题，而你无法采取任何行动。幸运的是，这种情况并不常见。

启动诊断功能允许你查看虚拟机当前的屏幕和串行日志。当虚拟机没有响应时，它可以非常有帮助，帮助你检查当前的状态。

使用重置密码选项，你可以重置虚拟机的密码，但前提是你知道正确的用户名。一旦你登录虚拟机后，还需要再次重置密码，因为这里使用的密码只是临时的。重置密码还提供了重置远程桌面服务配置的选项。

串行控制台（预览版）允许你通过浏览器访问 Windows 串行控制台。不过，这项功能仍处于预览阶段，所以你不应该过于依赖它。

重新部署是一个非常有趣的功能。如果你的虚拟机没有响应，且无法连接，你可以使用这个功能。重新部署虚拟机会将虚拟机迁移到 Azure 数据中心的另一台主机上，尝试解决你的问题。迁移会导致虚拟机重启，而虚拟机本来就没有响应，因此这并不算什么问题，且可能解决你遇到的问题。

这里列出的功能和选项是特定于 Azure 虚拟机的管理选项。虚拟机的管理将继续使用标准管理员工具。我们可以通过 RDP 连接到虚拟机并执行任何我们需要的任务。我们可以为虚拟机安装角色和功能，添加任何第三方软件或我们的自定义软件。其他管理工具，如远程服务器管理工具（RSAT）或 PowerShell，也是可选的。

Azure 负载均衡器

部署 Azure 虚拟机是第一步，但商业关键服务和应用程序怎么办呢？对于这些服务，我们可能希望设计高度可用的解决方案，确保服务级别协议（SLA）和运行时间达到最佳。

这一过程的第一步必须在创建虚拟机时完成，设置可用性区域和可用性集。接下来，我们将在解决方案中添加另一台虚拟机，并选择不同的可用性区域以及相同的可用性集。这将确保虚拟机被放置在 Azure 数据中心的不同区域，并且不依赖于相同的电源、网络和冷却设施。如果 Azure 数据中心出现问题，两个虚拟机受到影响的可能性较小。

设置相同的可用性集将确保虚拟机（VM）被放置在不同的物理服务器、计算机机架、存储单元和网络交换机上。如果发生硬件故障，两个虚拟机同时受到影响的可能性较小。可用性集还会确保微软永远不会进行同时影响两个虚拟机的维护。为了保持 Azure 数据中心的安全并确保最佳性能，必须定期执行维护任务，安装主机更新或升级硬件固件。将虚拟机放入可用性集意味着这些虚拟机是为了实现高可用性而设置的，维护将考虑到这一点，并确保不会同时影响所有虚拟机。

因此，为了实现高可用性，我们需要至少设置两台虚拟机。但流量该如何处理呢？我们如何确定流量是流向第一台还是第二台虚拟机？如果第一台虚拟机不可用，我们如何将流量引导到第二台虚拟机？

这就是 Azure 负载均衡器发挥作用的地方。这是 Azure 的一项网络服务，我们之前略过了它，稍后会在合适的时机进行解释。后续章节中也会有类似的情况。Azure 负载均衡器将前端流量分配到后端池实例。它们可以支持传入和传出场景，具有低延迟和高吞吐量。在这种场景下，传入流量会到达负载均衡器的 IP 地址，然后负载均衡器会将流量分配到配置在后端池中的虚拟机。Azure 负载均衡器可以是内部的或公共的，具体取决于我们需要分配哪种类型的流量。对于 Web 服务器角色，我们可能希望使用公共负载均衡器。但对于数据库服务器，我们可能希望使用内部负载均衡器，因为我们不希望数据库暴露在互联网上。

创建一个 Azure 负载均衡器

要创建一个新的 Azure 负载均衡器，我们需要选择创建一个新资源，并从列表中选择 Azure 负载均衡器。这将打开创建负载均衡器的界面，在此界面中我们需要提供基本信息。

所有资源共有的信息包括名称、订阅、资源组和位置。

Azure 负载均衡器特有的选项包括类型、SKU 和公共 IP 地址。

负载均衡器的类型可以是内部的或外部的，具体取决于您希望路由哪种类型的流量。公共类型必须配置公共 IP 地址，并且我建议您为该 IP 地址配置静态 IP。您还可以选择启用 Azure 负载均衡器的公共 IPv6，而公共 IPv4 是默认设置。

库存单位（SKU）可以是 Basic 或 Standard。Standard 提供更多的选项和功能，但其价格是基于负载均衡规则的数量来形成的。另一方面，Basic 是免费的，唯一的费用来自于预留公共 IP 地址和外发流量。

创建新的 Azure 负载均衡器所需信息的示例如下图所示：

大多数 Azure 网络功能的部署时间都在一分钟以内，Azure 负载均衡器也不例外，部署过程应该非常快速。

配置 Azure 负载均衡器

在 Azure 负载均衡器部署完成后，我们可以进入资源并查看不同的选项。设置项对我们最为重要，我们需要它来配置我们的负载均衡器。我们可以找到所有 Azure 资源共有的标准设置，如属性、锁定和自动化脚本。前端 IP 配置使我们能够管理与负载均衡器关联的 IP 地址，添加新的 IP 地址或移除现有的 IP 地址。其他设置将用于配置负载均衡器以分配传入流量，并配置该流量应该被定向到哪里。

首先，我们需要为负载均衡器配置后端池。我将选择将我的负载均衡器与一个可用性集关联。在本章前面，我创建了一台名为 WebSrv1 的虚拟机，并将其与名为 WebSet 的可用性集关联。然后，我添加了一个名为 WebSrv2 的相同虚拟机，并将其添加到相同的可用性集中。因此，我有两台相同的虚拟机在同一个可用性集中，并且将我的 Azure 负载均衡器与这个可用性集关联。最后，我们需要定义将要使用的网络 IP 配置，并设置它以使用该可用性集中这两台虚拟机。如果我们在此可用性集中有更多虚拟机，还可以设置更多的 IP 配置来进行目标选择。如何设置后端池的示例可以在这张截图中看到：

第二步是设置健康探测。我们需要定义协议、端口、间隔和不健康阈值。协议和端口将定义需要监控的内容。由于我打算使用 WebSrv1 和 WebSrv2 作为 Web 服务器，我将设置对 80 端口的监控。间隔将定义检查的频率，以确保服务器响应。阈值定义了多少个连续的检查未能成功联系到服务器时，将其声明为无响应。如何在 80 端口上设置健康探测的示例可以在这张截图中看到：

由于我想使用 Web 服务器角色，我将在 443 端口上重复相同的操作。在这里的截图中，我们可以看到两个探测都已创建，但“使用者”信息为空：

第三步是创建负载均衡规则。我们需要提供名称、IP 版本、前端 IP 地址、协议、前端端口、后端端口、后端池、健康探测、会话保持性和空闲超时（分钟）。名称和 IP 版本是显而易见的选项，因此我们直接跳到其他选项。

对于前端 IP 地址，你可以选择任何一个负载均衡器的 IP 地址，因为它可以与多个 IP 地址关联。根据选择的 IP 版本，存在一些关于可以选择的 IP 地址的限制。如果 IP 版本设置为 IPv4，则只能选择 IPV4 地址。如果选择了 IPv6，则只能选择与负载均衡器关联的同一版本的 IP 地址。

协议和端口已连接，通过此选项，你可以选择需要从定义的端口转发到定义的后端端口的协议。例如，TCP 协议的 80 端口应转发到 80 端口。

通过后端池，我们定义了流量的转发目标。由于在一个 Azure 负载均衡器中可以有多个后端池，你可以选择这些池中的任何一个。

必须选择健康探测，以便检查虚拟机的状态。你需要选择执行检查的探测器，检查你正在创建的规则中使用的后端端口。

会话保持和空闲超时（分钟）选项与客户端连接的处理方式相关。由于您的后端池中至少有两台虚拟机，因此您需要设置流量在一个会话期间由同一台虚拟机处理。如果您选择来自相同客户端 IP 地址、相同协议的流量，这将保持会话活动。只要会话处于活动状态，客户端将被定向到同一虚拟机。

空闲超时（分钟）决定如果没有采取任何操作，会话将保持活动多长时间。默认值为 4 分钟，但可以更改为最多 30 分钟。通过此设置，您可以确定如果客户端没有使用应用程序并且没有发送任何消息以保持会话活动，连接将保持多长时间。

浮动 IP（直接服务器返回）地址的选项默认情况下是禁用的，应该仅在 SQL AlwaysOn 可用性监听器中使用。

在此屏幕截图中，您可以看到设置负载均衡规则 HTTP 的选项：

我将为端口443创建另一个名为 HTTPS 的规则。请注意，在此屏幕截图中，之前创建的探测现在被负载均衡规则使用：

负载均衡器设置中的最后一个选项是入站 NAT 规则。它具有与负载均衡规则类似的选项，唯一的区别是，在这种情况下，流量不是转发到后端池，而是转发到单个虚拟机。在此屏幕截图中，您可以看到如何设置一个入站 NAT 规则，该规则将流量从端口 5589（WinRM）转发到 WebSrv1：

那么，让我们回顾一下通过设置负载均衡器和可用性集所取得的成果。我们在后端池中有两台虚拟机作为 Web 服务器。虚拟机被放置在不同的可用性区域和相同的可用性集中，以增加至少一台虚拟机运行的机会。健康探测会检查虚拟机是否在定义的端口上可用。如果任何一台虚拟机连续两次未响应，它将被标记为失败。已经设置了一个负载均衡规则，将通过负载均衡器公共 IP 地址传入的流量转发到后端池。如果后端池中的两台虚拟机都健康，流量将根据轮询规则转发。如果健康探测将任何虚拟机标记为未响应，所有流量将转发到健康状态的虚拟机。基于客户端 IP、协议和空闲超时，保持会话存活。来自相同 IP 地址的会话，只要每隔 4 分钟发送一次保持活动信号，将会被转发到相同的虚拟机。

这将确保我们的应用程序始终运行，即使某个虚拟机发生故障。故障可能是由于 Azure 数据中心的硬件或网络错误引起的（可用性区域和可用性集确保两个虚拟机不会受到影响）。将更多虚拟机放入可用性集和后端池可以增加至少一个虚拟机正常运行的机会。

Azure 负载均衡器 ARM 模板

这是创建一个新的 Azure 负载均衡器的 ARM 模板：

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"sku": {
"type": "string"
},
"publicIPAddressName": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2017-08-01",
"name": "[parameters('name')]",
"type": "Microsoft.Network/loadBalancers",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('sku')]"
},
"dependsOn": [
"[concat('Microsoft.Network/publicIPAddresses/', parameters('publicIPAddressName'))]"
],
"properties": {
"frontendIPConfigurations": [
{
"name": "LoadBalancerFrontEnd",
"properties": {
"publicIPAddress": {
"id": "[resourceId('test', 'Microsoft.Network/publicIPAddresses', parameters('publicIPAddressName'))]"
}
}
}
]
}
},
{
"apiVersion": "2017-08-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[parameters('publicIPAddressName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('sku')]"
},
"properties": {
"publicIPAllocationMethod": "Dynamic",
"publicIPAddressVersion": "IPv4"
}
}
]
}

Azure 虚拟机规模集

弹性是云计算的一大优势。我们可以根据工作负载和需求进行扩展和缩减。如果工作负载增加，我们就扩展；如果工作负载减少，我们就缩减。采用按需付费和按分钟计费的定价模式，这使我们能够节省成本。

我们已经解释了如何在 Microsoft Azure 中设置虚拟机的扩展和缩减。扩展和缩减是指将虚拟机的大小调整为更大或更小的实例。这被称为垂直扩展。这种方式非常有用，但也有一个后果——每次更改虚拟机大小时，都会发生重启。因此，垂直扩展可以增加虚拟机的大小以处理更多的工作负载，但它总会在虚拟机重启期间导致停机。

解决方案是横向扩展，对于 Azure 虚拟机，我们可以使用 Azure 虚拟机规模集。与其调整虚拟机的大小，规模集通过创建虚拟机的额外实例，并使用 Azure 负载均衡器将工作负载分配到这些实例上。这个过程称为横向扩展。该方法类似于高可用性场景，但不同之处在于，规模集不是在可用性集中创建多个虚拟机，而是根据工作负载启动虚拟机，并且仅在需要时启动它们。另一个区别是，在可用性集中，虚拟机是独立的，一个虚拟机的问题不会影响到其他虚拟机。而在规模集中，所有虚拟机都复制了主虚拟机，如果主虚拟机出现故障，问题将反映到整个规模集。我们需要指出，规模集并不是一个高可用性解决方案，而是基于工作负载的横向扩展。

创建一个 Azure 虚拟机规模集

让我们创建一个新的 Azure 虚拟机规模集，并在过程中解释所有细节。

要创建一个新的 Azure 虚拟机规模集，所有信息都在一个屏幕中提供。为了让它更加清晰可见，我将屏幕分为三张图片——基本信息和实例、自动缩放、以及网络配置。

规模集的基本信息与虚拟机的基本信息非常相似。这是合乎逻辑的，因为规模集首先创建一个主虚拟机，然后克隆该虚拟机以进行横向扩展。我们需要提供虚拟机规模集名称、操作系统磁盘映像、订阅、资源组、位置、用户名、密码，并可以选择添加可用性区域。

接下来，我们创建实例规则。这将决定规模集中的虚拟机（VM）的大小以及规模集允许创建的实例数量。对于 Azure 提供的操作系统镜像，允许的最大实例数为 1,000 个；对于自定义操作系统镜像，最大实例数为 300 个。如果应用程序出现问题，并且应用程序本身导致 CPU 或内存过高，这将导致规模集扩展并创建新的实例。由于新实例是主虚拟机的完全副本，因此问题将在这些虚拟机上持续存在，扩展将继续，直到达到最大实例数。重要的是要设置实例数量为您实际准备支付的数量，因为即使是短时间内启动 1,000 个虚拟机也可能带来巨大的财务影响。

将规模集虚拟机部署为低优先级虚拟机可以为您节省最多 80% 的费用。低优先级虚拟机使用 Azure 数据中心中分配的未使用资源创建，但这些资源可以被更高优先级的资源抢占，并且可能随时不可用。因此，尽管此选项可以帮助您节省大量费用，但资源在需要时可能无法提供。此选项不应用于需要随时可用的服务，或关键服务。建议仅将低优先级用于低优先级服务或批处理任务。

规模集创建了多个虚拟机实例，并且所有这些虚拟机都有各自的磁盘。在扩展过程中管理这些磁盘和存储账户，尤其是当我们启动 1,000 个实例时，可能会非常具有挑战性。我建议使用 Azure 自动管理的托管磁盘，这样您就不必担心这一部分。

基本设置和实例设置的示例如下图所示：

自动扩展创建了一组规则，定义了规模集如何进行扩展和收缩。我们需要设置规模集中的虚拟机最小和最大数量。最大数量会根据之前设置的实例数量自动收集，但不一定必须相同。实例数量决定了最初要创建多少虚拟机，而最大数量则决定了可以创建多少虚拟机。

我们创建了扩展和收缩规则，这些规则将增加和减少规模集中的虚拟机数量。例如，如果 CPU 使用率达到 75%，则会启动额外的虚拟机。如果使用率降到 25%以下，则会减少规模集中的虚拟机数量。将添加/移除的虚拟机数量可以单独设置。

假设我们将虚拟机的最小数量设置为 1，实例数量设置为 10，最大虚拟机数量设置为 100。当扩展集创建时，它将创建 10 个虚拟机副本并只启动其中一个副本，作为主副本。当触发扩展阈值时，它将向扩展集添加一个新的虚拟机。这个虚拟机是最初创建的 10 个虚拟机之一。如果利用率继续上升，它将继续添加新的虚拟机，直到达到 10 个虚拟机。如果最大虚拟机数量与实例数量不同，则将创建并启动新的虚拟机。前 10 个虚拟机和后续虚拟机的区别在于，最初的虚拟机已创建，只需要启动。额外的虚拟机需要先进行配置，再启动，这使得扩展过程变得较慢。然而，即使虚拟机未运行，初始虚拟机也会产生费用，因为即使虚拟机关闭，您也需要为磁盘付费。最好在初始虚拟机数量和最大虚拟机数量之间找到一个平衡。自动扩展（AUTOSCALE）在以下截图中展示：

网络（NETWORKING）部分让我们可以选择应用程序网关（Application Gateway）和负载均衡器（Load balancer）之间的选项。无论选择哪一个，它将作为您的用户的终端，并自动将流量分配到 Azure 虚拟机扩展集中。Azure 虚拟机的负载均衡器是免费的，而应用程序网关按小时计费，但支持许多附加功能。应用程序网关支持 SSL 终止、基于 URL 的路由、多站点路由、基于 cookie 的会话亲和性、Web 应用防火墙和可路由的 IP 地址。

使用负载均衡器时，应用于可用性集和扩展集的负载均衡器的区别在于，扩展集不需要额外的管理（您可以选择设置额外的规则和设置，但这不是必需的）。负载均衡规则和将虚拟机添加到后端池的操作是自动完成的，用户无需任何操作。以下是使用 Azure 负载均衡器的网络设置示例，见下图：

Azure 虚拟机扩展集的部署依赖于许多不同的参数。扩展集所需的网络服务必须在虚拟机之前部署，但这一过程非常快速。然后，虚拟机被部署，根据实例数量和虚拟机大小，这可能需要一些时间。部署少量大型实例可以相对快速完成，但如果部署数百个小虚拟机，可能需要长达一小时。

管理 Azure 虚拟机扩展集

部署完成后，会在我们的资源组中创建多个资源，我们可以看到虚拟机规模集以及一组与网络相关的资源。创建的网络资源包括负载均衡器、公共 IP 地址（由负载均衡器使用）、虚拟网络和网络安全组。NSG（网络安全组）应用于子网级别，并且 NSG 规则将对规模集中的所有虚拟机生效。这是合理的，因为所有虚拟机都是相同的，均由同一个应用程序使用，并且具有相同的用途。我们可以在这里的截图中看到为我们的规模集创建的所有资源：

由于我们已经讨论过所有涉及的网络功能，接下来我们将重点关注虚拟机规模集以及用于管理它的选项。许多选项与虚拟机设置相同，例如大小、持续交付（预览版）、配置、属性、锁定和自动化脚本。对规模集独有的设置包括实例、扩展、存储和操作系统。操作系统仅供参考，我们只能看到如用于创建规模集的映像和操作系统版本等信息。

存储设置还为我们提供了有关所使用存储类型和磁盘的信息，并且只有一个可供选择的选项——缓存。可用选项包括无、只读和读/写。

实例选项卡显示了规模集中的所有虚拟机及其状态。我们可以看到哪些虚拟机正在运行，并执行不同的操作，如启动、停止、取消分配和删除。特别有趣的选项是重新映像和升级。重新映像将重置选定虚拟机的所有设置，并将其恢复为默认版本。升级将手动将选定虚拟机升级到最新的更改。规模集中的所有虚拟机都是主虚拟机的完全复制品，如果主虚拟机发生更改，这些更改将及时复制到所有实例。升级选项使我们能够手动执行升级，并立即强制应用更改。当规模集中有大量虚拟机时，这非常有用，因为复制更改需要时间，而更改可能需要尽快应用。然而，重新映像和升级选项都会在过程中重启虚拟机，因此也需要考虑这一点。最后，Azure 虚拟机规模集中独有的选项是扩展，但详细解释这一选项还需要一些时间。

扩展选项卡向我们展示了所有有效的扩展规则，这些规则适用于我们的规模集。如果规则是在部署过程中创建的，它们将显示在此处，我们可以编辑或删除它们。也可以创建附加规则，我们可以监控多个参数。例如，我们可以为 CPU、内存和磁盘使用率创建单独的规则。如果触发任何这些规则，它将执行相应的扩展或收缩过程。创建更多的扩展规则能为我们提供更好的灵活性和性能，因为我们不再依赖于单一的点。如果我们只监控 CPU，但遇到内存问题，则无法扩展，性能也会下降。如果我们监控内存，但磁盘使用率很高，同样不会发生自动扩展，性能也会下降：

在讨论 Azure 虚拟机规模集时，有两点非常重要。规模集与可用性集是非常不同的。在可用性集中，我们保持一个固定数量的虚拟机，以提高至少一台虚拟机始终可用并实现高可用性的概率。规模集则监控工作负载，并根据需求增加虚拟机的数量，但所有虚拟机都是副本，任何问题都可能导致所有虚拟机都复制该问题。

另一个需要明确的事项是我们可以在什么场景下使用 Azure 虚拟机规模集。由于规模集中的所有虚拟机都是初始映像的副本，任何更改都会从初始映像同步到所有其他虚拟机。但这个过程是单向的，新增实例上的更改不会应用到其他地方。因此，Azure 虚拟机规模集不适合像 SQL Server 或 Exchange Server 这样的角色，这些角色要求更改必须应用到所有实例。相反，应将规模集用于应用场景，这些场景中的更改不是由用户会话引起的，且数据会随着时间的推移保持持久。

Azure 虚拟机规模集 ARM 模板

此外，以下是用于部署新 Azure 虚拟机规模集的 ARM 模板：

{
 "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "vmSku": {
 "type": "string",
 "defaultValue": "Standard_D1",
 "metadata": {
 "description": "Size of VMs in the VM Scale Set."
 }
 },
 "vmssName": {
 "type": "string",
 "metadata": {
 "description": "String used as a base for naming resources. Must be 3-61 characters in length and globally unique across Azure. A hash is prepended to this string for some resources, and resource-specific information is appended."
 },
 "maxLength": 61
 },
 "instanceCount": {
 "type": "int",
 "metadata": {
 "description": "Number of VM instances (100 or less)."
 },
 "defaultValue": 2,
 "maxValue": 100
 },
 "adminUsername": {
 "type": "string",
 "metadata": {
 "description": "Admin username on all VMs."
 }
 },
 "adminPassword": {
 "type": "securestring",
 "metadata": {
 "description": "Admin password on all VMs."
 }
 }
 },
 "variables": {
 "vnetName": "vnet",
 "subnetName": "subnet",
 "subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('vnetName'), variables('subnetName'))]",
 "publicIPAddressName": "pip",
 "loadBalancerName": "loadBalancer",
 "loadBalancerFrontEndName": "loadBalancerFrontEnd",
 "loadBalancerBackEndName": "loadBalancerBackEnd",
 "loadBalancerProbeName": "loadBalancerHttpProbe",
 "loadBalancerNatPoolName": "loadBalancerNatPool"
 },
 "resources": [
 {
 "type": "Microsoft.Compute/virtualMachineScaleSets",
 "name": "[parameters('vmssName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-03-30",
 "dependsOn": [
 "[concat('Microsoft.Network/virtualNetworks/', variables('vnetName'))]",
 "[resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName'))]"
 ],
 "sku": {
 "name": "[parameters('vmSku')]",
 "capacity": "[parameters('instanceCount')]"
 },
 "properties": {
 "overprovision": "true",
 "upgradePolicy": {
 "mode": "Manual"
 },
 "virtualMachineProfile": {
 "storageProfile": {
 "osDisk": {
 "createOption": "FromImage",
 "caching": "ReadWrite"
 },
 "imageReference": {
 "publisher": "MicrosoftWindowsServer",
 "offer": "WindowsServer",
 "sku": "2016-Datacenter",
 "version": "latest"
 }
 },
 "osProfile": {
 "computerNamePrefix": "[parameters('vmssName')]",
 "adminUsername": "[parameters('adminUsername')]",
 "adminPassword": "[parameters('adminPassword')]"
 },
 "networkProfile": {
 "networkInterfaceConfigurations": [
 {
 "name": "nic",
 "properties": {
 "primary": true,
 "ipConfigurations": [
 {
 "name": "ipconfig",
 "properties": {
 "subnet": {
 "id": "[variables('subnetRef')]"
 },
 "loadBalancerBackendAddressPools": [
 {
 "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('loadBalancerName'), '/backendAddressPools/', variables('loadBalancerBackEndName'))]"
 }
 ],
 "loadBalancerInboundNatPools": [
 {
 "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('loadBalancerName'), '/inboundNatPools/', variables('loadBalancerNatPoolName'))]"
 }
 ]
 }
 }
 ]
 }
 }
 ]
 }
 }
 }
 },
 {
 "type": "Microsoft.Network/virtualNetworks",
 "name": "[variables('vnetName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-04-01",
 "properties": {
 "addressSpace": {
 "addressPrefixes": [
 "10.0.0.0/16"
 ]
 },
 "subnets": [
 {
 "name": "[variables('subnetName')]",
 "properties": {
 "addressPrefix": "10.0.0.0/24"
 }
 }
 ]
 }
 },
 {
 "type": "Microsoft.Network/publicIPAddresses",
 "name": "[variables('publicIPAddressName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-04-01",
 "properties": {
 "publicIPAllocationMethod": "Dynamic",
 "dnsSettings": {
 "domainNameLabel": "[toLower(parameters('vmssName'))]"
 }
 }
 },
 {
 "type": "Microsoft.Network/loadBalancers",
 "name": "[variables('loadBalancerName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-04-01",
 "dependsOn": [
 "[concat('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]"
 ],
 "properties": {
 "frontendIPConfigurations": [
 {
 "name": "[variables('loadBalancerFrontEndName')]",
 "properties": {
 "publicIPAddress": {
 "id": "[resourceId('Microsoft.Network/publicIPAddresses', variables('publicIPAddressName'))]"
 }
 }
 }
 ],
 "backendAddressPools": [
 {
 "name": "[variables('loadBalancerBackendName')]"
 }
 ],
 "loadBalancingRules": [
 {
 "name": "roundRobinLBRule",
 "properties": {
 "frontendIPConfiguration": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/frontendIPConfigurations/', variables('loadBalancerFrontEndName'))]"
 },
 "backendAddressPool": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/backendAddressPools/', variables('loadBalancerBackendName'))]"
 },
 "protocol": "Tcp",
 "frontendPort": 80,
 "backendPort": 80,
 "enableFloatingIP": false,
 "idleTimeoutInMinutes": 5,
 "probe": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/probes/', variables('loadBalancerProbeName'))]"
 }
 }
 }
 ],
 "probes": [
 {
 "name": "[variables('loadBalancerProbeName')]",
 "properties": {
 "protocol": "Tcp",
 "port": 80,
 "intervalInSeconds": "5",
 "numberOfProbes": "2"
 }
 }
 ],
 "inboundNatPools": [
 {
 "name": "[variables('loadBalancerNatPoolName')]",
 "properties": {
 "frontendIPConfiguration": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/frontendIPConfigurations/', variables('loadBalancerFrontEndName'))]"
 },
 "protocol": "Tcp",
 "frontendPortRangeStart": 50000,
 "frontendPortRangeEnd": 50019,
 "backendPort": 3389
 }
 }
 ]
 }
 }
 ]
}

摘要

我们已经涵盖了基本的 IaaS 概念，以及如何设置 Azure 虚拟机。扩展 IaaS 场景的逻辑步骤是涵盖高可用性，我们通过 Azure 负载均衡器和可用性集成功地实现了这一目标。

云计算的一个关键概念是弹性和按需资源。我们展示了如何实现垂直扩展（通过警报和自定义操作）和水平扩展（通过 Azure 虚拟机规模集）。

在下一章中，我们将进入 PaaS 模型，并探索 Azure 应用服务，相比于 Azure 虚拟机，它提供了更抽象的模型。应用服务为我们提供了一些独特的选项，这些选项将帮助我们在云端之旅中取得进展，但相比虚拟机，它对基础设施的控制较少。我们将比较 IaaS 功能与 PaaS 的关系，并探索如何通过应用服务实现扩展和高可用性。

问题

支持 Azure 虚拟机的最旧版本 Windows Server 是哪个？
1. Windows Server 2003
2. Windows Server 2008 R2 SP1
3. Windows Server 2012 R2
基础层虚拟机支持什么？
1. 较低的 IOPS
2. 负载均衡器
3. 自动扩展
低优先级虚拟机的用途是什么？
1. 高可用性
2. 批处理
3. 平衡的工作负载
在 Azure 虚拟机刀片中设置大小用于...？
1. 向上扩展
2. 缩减规模
3. 两者
运行手册可以用于执行什么？
1. 维护任务
2. 虚拟机的横向和纵向扩展
3. 两者
Azure 负载均衡器用于...？
1. 在后端池中分配流量到虚拟机
2. 隔离流量并防止对虚拟机的攻击
3. 两者
将虚拟机放置在同一可用性集中将导致...？
1. 虚拟机将被创建在不同的 Azure 数据中心
2. 虚拟机将被放置在不同的机架上
3. 虚拟机将被放置在同一机架上
通过创建虚拟机的额外实例来扩展规模被称为...？
1. 向上扩展
2. 缩小规模
3. 横向扩展
横向扩展是...的例子？
1. 纵向扩展
2. 水平扩展
3. 对角线扩展
横向扩展 Azure 虚拟机我们使用...？
1. 可用性区域
2. 可用性集
3. 扩展集

第四章：Azure 应用服务 - 无服务器托管 Web 应用程序

我们云端之旅的下一步是 PaaS，我们将介绍 Azure 应用服务。Azure 应用服务是 Azure PaaS 最简单的例子，旨在托管 Web 应用程序。我们将了解在 IaaS 和 PaaS 中托管应用程序的区别。

本章将涵盖以下内容：

Azure 应用服务计划
Azure Web 应用
流量管理器
应用服务环境

技术要求

本章需要一个 Azure 订阅。

Azure 应用服务计划和 Azure Web 应用

Azure 中的 PaaS（或任何公共云中的 PaaS）比 IaaS 更抽象。理解 IaaS 模型很简单，因为它与本地环境没什么不同：我们创建虚拟机，按照我们的方式进行配置，安装我们需要的软件（当然，也受限于操作系统本身；我们不能安装一些无法在本地运行的东西）。

在我们创建 Azure 虚拟机后，我们对该虚拟机上的所有内容拥有完全的控制权。例如，在上一章创建的虚拟机旨在作为 web 服务器使用。我们可以连接到该虚拟机并安装所有所需的角色、功能和软件，以开始托管我们的应用程序。

那么，如果我们想用 PaaS 做类似的事情怎么办？

Azure 应用服务计划用于在 Azure 中托管我们的 web 应用程序。我们需要创建一个 Azure 应用服务计划，然后为我们的应用程序添加 Azure Web 应 s。一个应用服务计划可以托管多个 Azure Web 应用。如果我们在 web 服务器上安装 IIS，我们也可以托管多个应用。应用服务计划可以与 IIS 类比，但有一个重要区别：使用 IIS，我们可以完全控制配置，而使用应用服务计划，我们只能选择有限的选项。这本质上是 IaaS 和 PaaS 之间的区别。

控制权减少意味着维护工作也减少，因为许多在本地环境中需要执行的任务现在已经自动化，我们不需要担心它们。例如，在本地环境中必须定期安装更新，以确保一切保持最新并保持安全。而在 PaaS 中，我们不需要安装任何更新，因为这会在主机级别自动完成。

创建应用服务计划

我们从创建一个新的应用服务计划开始。与所有 Azure 资源类似，我们需要提供名称、订阅、资源组和位置。其他可用选项是操作系统和定价层。操作系统的选项有 Windows 和 Linux。以下截图展示了创建新应用服务计划所需的所有信息示例：

应用服务计划定价层的默认值是 S1 标准或标准 1。如果我们更改此值，将会打开一个新的面板，提供更多选项。以下截图展示了应用服务计划定价面板：

App Service 计划定价分为三个部分：

开发/测试
生产环境
隔离

开发/测试适用于开发/测试环境中的小型工作负载。它有不同的大小：F1、D1 和 Basic（B1、B2 和 B3）。F1 是免费的，基于共享基础设施，每天的计算时间有限，并且不支持自定义域名。D1 每天有更多的计算时间，并支持自定义域名。Basic 层有专用基础设施，并支持自定义域名、SSL 和手动扩展。

生产环境适用于更大工作负载的生产环境。它提供标准和高级层，每个层都有额外的大小（S1、S2、S3、P1、P2、P3、P1v2、P2v2 和 P3v2）。生产部分的所有大小都带有额外的功能，如自动扩展、插槽、备份和流量管理器支持。App Service 计划可用的资源量取决于大小，因为每个大小有不同的内存和核心数。即使 Basic 层不适用于生产环境，这也同样适用。标准层和高级层之间的主要区别在于磁盘类型，标准层使用标准存储（HDD），而高级层使用高级存储（SSD）。高级层还可以分为 v1 和 v2，其中 v2 使用不同的处理器类型并具有更多的内存。

在创建了 App Service 计划后，你可以开始添加 Web 应用。重要的是要说明，你可以将多个 Web 应用添加到单个 App Service 计划中。计费是在 App Service 计划级别进行的，你为整个 App Service 计划付费，而不是为每个单独的应用付费。每个 App Service 计划可以添加的应用数量取决于层和大小。

创建 Azure Web 应用

要创建一个新的 Azure Web 应用，需要提供的标准值包括应用名称、订阅、资源组和 Application Insights 位置。其他必需的值包括操作系统、App Service 计划/位置和 Application Insights。操作系统的可选值包括 Windows、Linux 和 Docker。具体值将取决于你要运行的应用类型。在 App Service 计划/位置中，你可以创建一个新的 App Service 计划或使用现有的。

App Service 计划/位置将决定你的 Web 应用的位置，因为它需要与关联的 App Service 计划位于相同的位置。最后，我鼓励启用 Application Insights，因为这将让你更好地监控和报告应用的使用情况和性能。

创建 Web 应用所需的所有信息示例如下图所示：

部署完成后，我们可以看到以下资源已创建：App Service 计划、App Service 和 Application Insights。这可能有些令人困惑，因为在创建资源时和资源实际创建后使用了不同的名称。App Service 计划在两种情况下都是 App Service 计划。

在 Web 应用程序的情况下，名称是不同的。当你想创建一个新的 Web 应用时，面板会显示 Web 应用的名称，但在创建后你会看到它作为应用服务。总结来说，应用服务计划被称为应用服务计划，而 Web 应用则被称为 Web 应用和应用服务：

管理 Azure Web 应用

资源部署完成后，我们需要进行配置。由于我们无法直接访问，也不能安装软件、角色或功能，我们有一组可编辑的预配置设置。相比虚拟机面板，应用服务面板中有更多的选项，但总体而言，由于无法进行直接配置，我们的选择会较少。

让我们从 Azure Web 应用程序开始，然后继续配置。

Azure Web 应用部署设置

Azure Web 应用的第一组选项是部署。快速入门为我们提供了指向各种文档和指南的链接。

我们可以设置用于部署和 FTP 访问的部署凭据：

部署插槽是一个非常有趣的功能，它允许我们为应用程序创建多个环境。插槽是独立的环境，但也可以用于交换应用程序版本。要创建一个新的插槽，我们选择“添加插槽”，然后提供名称和配置源。配置源可以是现有的插槽之一（选定插槽的配置将被克隆），或者我们可以选择不克隆并保留默认值。添加新插槽的示例如下图所示：

插槽的名称将由应用程序名称和插槽名称组成。例如，我创建了两个插槽：staging 和 test。如下图所示：

一个很棒的功能是交换槽位的选项。例如，我们可以运行一个生产槽，并将所有用户指向此槽位来使用应用程序。我们可以在不同的槽位上进行部署和测试，这不会影响用户当前使用的生产版本。一旦我们测试完毕，就可以将新版本部署到暂存槽。交换槽位的选项使我们能够在几秒钟内在旧的生产版本和新版本之间切换，且对用户的影响最小。当我们点击交换时，暂存中的一切将变成生产版本，旧的生产版本变为暂存。槽位之间的设置不会改变，因此，暂存槽可以使用与生产环境不同的数据库。例如，另一个很棒的功能是我们也可以进行反向交换。即使我们已经进行测试和验证，用户可能会在新版本的应用程序中遇到问题和错误。在这种情况下，我们只需切换回之前的生产版本，将其从暂存槽移动到生产槽，并将新版本从生产槽移到暂存槽。这将允许用户继续使用上一个稳定版本的应用程序，同时我们可以在暂存槽中检查和排查问题。一旦解决了问题，只需再次交换，新的版本就会回到生产环境。

以下截图展示了一个槽位交换的示例：

部署选项和部署中心（预览版）为您提供了连接到代码仓库的选项。最常见的仓库是默认选项，如 Visual Studio Team Services、GitHub 或 Bitbucket。像 OneDrive 或 Dropbox 这样的文件共享也是一个选项，您也可以链接到自定义的外部仓库，比如本地 Git 仓库或团队基础服务器。不同之处在于，除了连接仓库之外，部署中心（预览版）还为您提供了建立持续集成/持续交付管道的选项。以下截图展示了部署选项的源：

Azure Web App 一般设置

Azure Web 应用设置与其他 Azure 服务有一些相似功能，例如属性和锁定。此外，大多数 Azure 服务都有“扩展”（应用服务计划）和/或“扩展”（应用服务计划）选项。一些独特的设置包括应用设置、身份验证/授权、应用洞察、托管服务身份、备份、自定义域名、SSL 设置、网络、WebJobs、推送通知和 MySQL In App。网络选项允许我们将 Web 应用连接到 Azure VNet，甚至创建与本地环境的混合连接。WebJobs 允许我们创建可以按计划执行或由事件触发的后台进程。推送通知通常用于移动应用程序，以向正在运行应用程序的移动设备发送各种通知，例如新闻、更新等。MySQL In App 创建一个 MySQL 实例，供应用程序使用。

然而，这适用于小型工作负载，我不建议除了用于开发和测试之外使用它。以下截图显示了所有设置的列表：

常规设置提供了一组预配置的选项，允许我们更改框架版本和应用程序所需的其他设置。例如，我们可以在不同版本的 .NET、PHP、Python 或 Java 之间切换。我们还可以在 32 位和 64 位平台之间切换，打开或关闭 Websockets，设置托管管道版本为经典或集成等。

有一个非常重要的选项始终处于开启状态，我强烈建议您将其设置为开启。如果应用程序在一段时间内未使用，首次连接可能需要一些时间。例如，如果应用程序在工作时间内使用，早晨首次使用时可能需要一些时间才能连接，因为应用程序在晚上未使用。设置为始终开启会定期 ping 应用程序，保持其活跃。这样，无论何时用户尝试连接，应用程序都会准备就绪，不会有等待时间：

身份验证/授权选项允许我们为应用程序设置用户登录。默认选项为匿名访问，但我们可以设置 Azure Active Directory、Microsoft Live 账户、Facebook、Google 和 Twitter。托管服务身份允许应用程序在 Azure Active Directory 中注册，并使用该注册与 Azure Active Directory 中的其他应用程序进行通信。以下是身份验证/授权面板中显示的身份验证提供者列表：

备份选项允许我们为应用程序创建备份。我们需要提供存储设置（备份将存储在哪个存储账户）、备份计划和保留期。默认的保留期为 30 天，默认计划为每天一次，但您可以更改这些设置。如果您设置了与代码仓库的连接，则此选项并不真正必要，因为您可以随时重新部署应用程序，但如果您希望快速恢复，或者如果您没有使用代码仓库，它是一个有用的功能：

自定义域名、证书和扩展

自定义域名和 SSL 设置使我们能够自定义应用程序的 URL，并应用证书来加密连接并提高安全性。这些设置是直接关联的，因为没有自定义域名，您无法为 Web 应用应用有效的 SSL 证书。

默认情况下，Azure Web 应用的 URL 为 customname.azurewebsites.net（其中 customname 是您在创建 Web 应用时提供的名称）。为了简化访问，您可以使用已经拥有的自定义 URL，或者购买一个新的域名。甚至可以通过 Azure 门户购买新域名，但该服务并非由微软提供，而是由合作伙伴提供。如果您通过 Azure 门户购买新域名，这将被添加到您的 Azure 账单中。

为了设置自定义域名，需要验证域名所有权。通过在您的 DNS 中添加 CNAME（customname.azurewebsites.net）或记录（Azure Web 应用 IP 地址）来完成此验证，这将把您的自定义域名指向 Azure Web 应用。一旦验证完成，您只需确认是否希望使用该域名为您的 Azure Web 应用。此外，您还可以将网站设置为仅使用 HTTPS，以提高安全性，特别是当您使用 SSL 时。有关 CNAME 和需要添加的 IP 地址的信息，这些信息用于验证所有权，并在稍后指向您的网站，您可以在此页面找到：

SSL 配置允许我们重新设置为仅支持 HTTPS。我强烈建议在可能的情况下使用此选项。另一个安全选项是最低 TLS 版本，您可以在 1.0、1.1 和 1.2 之间进行选择。建议使用 TLS 1.2，因为如果不使用，可能会被报告为不安全。绑定选项允许您将自定义域名与可用证书配对。由于您可以让更多自定义域名指向同一个网站，因此所有启用 SSL 的域名将显示在列表中，如下所示：

SSL 设置下的证书部分允许您管理网站的证书。您可以选择导入应用服务证书或上传证书。应用服务证书是允许您通过 Azure 门户购买证书并将该证书用于您的应用程序的选项。此证书将对租户中的所有应用程序可用。上传证书选项允许您上传已有的证书，或上传您从外部来源购买的证书。证书会根据您上传或导入的证书类型显示在公共或私有列表中。您还可以根据需要请求客户端证书。所有证书选项如以下截图所示：

Azure Web 应用的自动缩放与虚拟机规模集（VMSS）类似。在“扩展”部分，您可以找到一个与 VMSS 中的扩展面板相同的面板。为了配置扩展规则，您需要设置扩展和缩减的参数。例如，您可以设置 Web 应用，当 CPU 超过 70% 时，添加一个额外实例；而当 CPU 降低到 25% 以下时，减少实例数量。您可以设置最小、最大和默认实例数。还可以添加更多扩展和缩减规则，根据不同的指标进行扩展或缩减。这将帮助您节省成本，并且仅运行所需的最少实例数量，避免性能问题。以下截图显示了扩展条件的示例：

Azure Web App 工具

Azure Web 应用有一些独特的工具，专门针对该服务：开发工具、移动和 API。

开发工具以“克隆应用”选项开始，该选项允许我们创建一个新的 Web 应用实例，该实例将与现有的应用程序完全相同。然而，此选项仅限于高级等级，如果您使用的是其他等级，则该选项不可用，除非您进行升级。控制台为您提供了对控制台的 Web 访问，您可以在其中浏览文件并执行命令行操作。

高级工具会打开一个额外的窗口，包含一些不同的选项，如调试控制台、进程资源管理器、资源浏览器以及用于调试和部署的不同信息。我们还可以向 Web 应用添加扩展，并从网站扩展部分选择数百种不同的扩展。

应用服务编辑器（预览）允许您访问代码编辑器，您可以在其中直接修改应用程序代码，无需任何额外工具。性能测试允许您对应用进行负载测试，查看它如何处理任意数量的并发用户。资源浏览器和扩展是我们讨论过的高级工具中的选项。

一个非常有趣的选项是生产环境中的测试。它需要使用插槽，并允许你将一定比例的用户重定向到不同的插槽进行用户测试。例如，我们将应用程序的新版本部署到暂存插槽。使用此功能，我们可以将 10% 的用户指向此插槽，以验证应用程序是否按预期工作。一旦确认 10% 的用户没有问题，我们可以将其增加到 25%，然后是 50%，最后将所有用户切换到新版本。以下是所有开发工具的列表：

其他可用的部分包括 MOBILE、API 和 MONITORING：

MOBILE：该部分有三个选项，旨在用于移动应用程序。这些选项包括 Easy tables、Easy APIs 和 Data connections。Data connections 定义了与 Azure SQL 数据库的连接，同时也是 Easy tables 和 Easy APIs 的要求。Easy tables 和 Easy APIs 都需要在 Web 应用上安装移动扩展。
API：API 部分包含 API 定义和 CORS。API 定义让你可以配置描述 API 的 Swagger 2.0 元数据的位置。这使得其他人能够轻松发现并使用你的 API。请注意，URL 可以是相对路径或绝对路径，但必须是公开可访问的。跨域资源共享（CORS）允许在外部主机上的浏览器中运行的 JavaScript 代码与你的后台进行交互。
MONITORING：这适用于其他资源，我们已经涵盖了其中大部分选项。监控选项包括 Alerts（经典）、诊断日志、日志流和进程资源管理器。在诊断日志中，你可以设置要保存的日志级别。日志流则提供了实时查看日志的选项。MOBILE、API 和 MONITORING 部分中的选项如下所示：

在 Azure 中监控 Web 应用

默认的 Azure Web 应用监控选项虽然有用，但它仅仅是 Web 应用监控选项的开始。如果你想要一个强大的工具来进行监控和告警，同时提供仪表盘和分析，Application Insights 是你想要使用的工具。可以在创建 Web 应用时或之后创建并将 Application Insights 链接到 Web 应用。

此外，你还可以使用单个 Application Insights 来监控多个 Azure Web 应用。值得注意的是，Application Insights 并不限于 Azure Web 应用，它可以与任何托管的应用程序一起使用，包括其他云提供商或本地数据中心。

Application Insights

初次查看应用程序洞察，你会看到几个仪表板，显示过去两小时内关于请求、响应时间和应用程序可用性的基本信息。这些仪表板可以根据不同的时间框架进行自定义，并显示不同的指标。以下是 App Insights 仪表板的示例：

在应用程序洞察下的第一个选项组位于调查（INVESTIGATE）部分。在此部分中，我们有多个指标选项，允许我们跟踪不同的性能计数器和依赖项。大多数这些选项可以编辑，我们可以提取特定信息，并创建自定义仪表板和警报。某些指标只有在应用程序中安装了应用程序洞察 SDK 时才能收集。调查部分下的所有选项列表如下所示：

这些警报的一个示例是可用性。我们可以创建一个测试，持续从不同的位置测试我们的应用程序，以确认应用程序是否可用。

我们可以编辑测试频率、测试位置、成功标准和警报。如果使用默认设置，应用程序将在五个不同的位置每 5 分钟进行一次 ping 操作。如果三个或更多位置无法联系到应用程序，将触发警报并发送通知。以下截图展示了一个可用性测试的示例：

使用情况（USAGE）部分包含有关用户、会话、事件和用户流程的各种信息。要在此部分获取指标，你需要使用应用程序洞察 JavaScript SDK 并将 JavaScript 代码片段添加到你的应用程序中。以下是用户部分下的所有选项列表：

以下是一个需要添加到应用程序中的代码片段示例，以便收集使用情况信息：

<!-- To collect end-user usage analytics about your application, insert the following script into each page you want to track. Place this code immediately before the closing </head> tag, and before any other scripts. Your first data will appear automatically in just a few seconds. --> <script type="text/javascript"> var appInsights=window.appInsights||function(a){ function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c={config:a},d=document,e=window;setTimeout(function(){var b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagName("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthenticatedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c"_"+f,i}}return c }({ instrumentationKey:"ebfab75c-e0ea-4d45-8aa9-ac11e656e644" }); window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView(); </script>

配置（CONFIGURE）部分包含许多已经包含在其他应用程序洞察设置（如智能检测设置）和 Azure Web 应用设置（如性能测试）中的设置。最有趣的功能是 API 访问（允许你管理 API 密钥，从而让其他应用程序访问你的 Azure Web 应用上的 API）和工作项（允许你连接到 Visual Studio Team Services 并将工作项直接链接到你的应用程序）。在应用程序洞察的配置部分下的设置列表如下所示：

APPLICATION INSIGHTS 记录了许多不同的指标。你可以在 Application Insights Analytics 中创建自定义查询，获取不同类型的信息。这些查询的结果可以以表格或图表的形式显示。以下是 Application Insight Analytics 的截图：

这是一个 Application Insights 查询的示例：

requests
| where timestamp >= ago(24h)
| summarize percentiles(duration, 50, 90, 95) by bin(timestamp, 1h)
| render timechart

Azure App Service Plan

在创建 Azure Web App 的过程中，我们需要创建一个 Azure App Service Plan。让我们回顾一下 Azure App Service Plan 中可用的设置。

在 SETTINGS 下，我们有一些在 Azure Web Apps 中可用的选项，如网络、扩展（App Service 计划）和扩展（App Service 计划）。还有属性、锁定和自动化脚本等选项，和所有其他 Azure 资源一样。请注意，一个 App Service Plan 可以托管多个 Azure Web Apps。计费是按 Azure App Service Plan 进行的；你不需要按 Web App 计费。因此，Azure Web App 的层级变化与 Azure App Service Plan 中的层级变化是直接相关的。在 Web App 刀片中进行的扩展/缩减和横向扩展/缩减操作将在此处显示，因为层级不会在 Azure Web App 中变化，而是在 Azure App Service Plan 中变化。

以下截图显示了 Azure App Service Plan 中的所有设置选项：

Azure App Service Plan 的一个不同和独特之处是应用程序。如前所述，可以在单一 Azure App Service Plan 上托管多个 Azure Web Apps。设置下的 Apps 选项列出了所有这些 Web Apps，以及在这些 Web Apps 下创建的任何槽位。以下是应用程序列表的示例：

另一个不同的选项是文件系统存储。每个 Azure App Service Plan 都有资源限制。在文件系统存储下，我们可以查看总空间和可用空间的信息。以下是文件系统存储的截图：

Azure Web App 高可用性

我们已经看过如何为 Azure Web Apps 设置自动扩展以及如何创建扩展和缩减规则。但是，扩展可以提高性能，并且在请求增加时保持应用程序正常运行，但并不能真正保证应用程序的高可用性。如果 Azure 数据中心出现问题，或者托管主机正在进行维护，应用程序将在单一位置托管时不可用。

为了实现高可用性，我们需要引入另一个 Azure 服务：Traffic Manager。Azure Traffic Manager 在 DNS 级别操作，根据自定义路由规则将传入请求定向到端点。

让我们从创建一个新的 Azure 流量管理器开始，并通过配置过程展示如何为 Azure Web 应用设置高可用性。

创建流量管理器

要创建一个新的 Azure 流量管理器，我们需要提供名称、路由方法、订阅资源组和位置。如果使用现有的资源组，位置将自动选择。流量管理器特有的选项是路由方法，提供的可选方法有性能、加权、优先级和地理。

性能选项用于当你希望根据响应时间、网络延迟等因素将用户指向提供最佳性能的地点时。

加权将根据权重规则均匀地分配请求。例如，默认规则会将请求均匀分配，如果我们定义了两个端点，则一半的请求会发送到一个端点，另一半会发送到第二个端点。但可以定义权重规则，使得一个端点接收 70%（或任何其他数值）的请求，其余请求则发送到第二个端点。当然，你可以定义多个端点（两个是最少的）并创建任何你想要的权重比例规则。

地理选项将引导用户到最近的地理位置。例如，我们可以有两个端点，一个位于西欧，另一个位于东美洲。如果使用地理路由方法，来自欧洲的用户将被引导到西欧的端点，而来自美国的用户将被引导到东美洲的端点。

最后，优先级路由方法通常在高可用性是目标时使用。一个端点将作为主端点，因此所有流量只会指向主端点。如果主端点不可用，所有流量将指向备用实例。当然，你可以定义多个端点，而不仅仅是两个。更多的端点确保至少有一个端点是可用的，从而提高高可用性的百分比。

在某些情况下，性能方法可以用来实现类似端点跟踪的目标，用户将被引导到在特定情况下表现最佳的端点。如果端点不可用，这将表现为性能下降，用户将被引导到另一个表现更好的端点。使用这种方法的问题是，性能下降的情况可能需要一些时间才能被检测到，用户在性能下降之前可能会遇到问题，直到端点的性能被确认下降并重新定向到其他端点。使用优先级方法时，端点的可用性被监控，问题被更快地检测到，用户将更快地被引导到健康的实例，并且遇到问题的可能性较小。

以下截图显示了一个用于创建新的 Azure 流量管理器的填写模板示例：

Traffic Manager 配置和设置

一旦创建了 Azure Traffic Manager，我们可以继续配置。Traffic Manager 特定的设置包括配置、实际用户度量、流量视图和端点。

实际用户度量和流量视图可以让你监控用户行为，查看用户的指向位置以及流量的流动情况。流量视图将为你提供有关请求来源的见解，使用地图并指示请求的地理来源。实际用户度量可以为你提供更多关于请求和流量的见解，但需要一个度量密钥和一个 JavaScript 代码片段嵌入到应用程序代码中：

Endpoint 选项允许你注册流量将被指向的端点。这些端点可以是 Azure 端点或外部端点。在外部端点的情况下，只允许使用完全限定域名（FQDN）。对于 Azure 端点，可以是云服务、应用服务、应用服务插槽或公共 IP 地址。这是另一个可能会引起混淆的命名示例。在这种情况下，应用服务和应用服务插槽实际上是 Web 应用和 Web 应用插槽。以下截图展示了如何添加一个 Azure Web 应用（应用服务）的示例：

只有一个端点实际上无法帮助我们实现高可用性，我们需要至少再添加一个端点。我建议第二个端点位于不同的区域，以解决单个数据中心可能出现的维护或服务问题。所有可用端点的列表位于端点下，显示名称、状态、类型和位置。以下截图展示了一个示例：

最后一步是在配置下创建规则。请注意，我们可以在这里更改路由方式，并且在创建 Traffic Manager 后，该选项仍然可以更改。这并非所有 Azure 资源的情况，某些设置一旦创建就无法更改。例如，Azure 中的任何资源都不能重命名：如果需要更改名称，唯一的选择是删除该资源并重新创建。你可以在端点监控设置下选择你希望监控的协议、端口和路径。

最后，需要配置快速端点故障切换设置。探测间隔可以设置为 10 或 30 秒，这决定了端点状态检查的频率。容忍的失败次数可以设置为 0-9，这决定了在端点被声明为失败之前，检查失败的次数。探测超时时间决定了探测超时之前所需的时间。这个值至少需要为 5，且小于探测间隔时间。这些设置的较低数字意味着问题会更快被检测到，并且故障切换会在用户发现问题之前发生。然而，您需要小心，因为比需要的更频繁地 ping 应用程序，并设置过少的容忍失败次数，可能会导致应用程序在实例之间切换得过于频繁，进而产生额外的问题。以下截图显示了一个示例配置：

在专用环境中运行 Azure Web 应用

Azure Web 应用使用公共端点，通常通过互联网访问，没有任何限制。在需要更隔离的访问情况下，还有另一个选择：Azure 应用服务环境（ASE）。Azure ASE 为高规模的安全应用程序提供完全隔离的专用环境。Azure ASE 通常用于需要非常高规模、隔离和安全网络访问以及高内存利用率的工作负载。由于 ASE 作为专用环境提供，这消除了“吵闹邻居”问题（可能由于另一个应用程序共享同一主机而导致的性能问题），并允许您充分利用所有资源。

Azure 应用服务计划可以连接到 Azure VNet，但这需要额外的工作。另一方面，ASE 会自动连接到 VNet，并且只能通过私有连接和私有 IP 地址进行访问。

总结

Azure 应用服务计划是 Microsoft Azure 中 PaaS 模式的最佳示例。它允许我们无需服务器和虚拟机即可托管应用程序。尽管管理选项被简化到最小化，但我们仍然有很多配置选项。传统支持几乎为零，但 PaaS 模式旨在为需要最新功能和框架的现代应用程序提供服务。如果您需要运行传统软件，IaaS 是最佳选择。

我们从应用角度介绍了 Azure 中的 IaaS 和 PaaS。但是，没有数据，应用就无从谈起。在下一章中，我们将讨论 Azure 中的数据平台，并展示如何在云端创建和管理数据库。

问题

Azure 应用服务是...
1. IaaS
2. PaaS
3. SaaS
与虚拟机相比，我们在应用服务计划中有多少控制权？
1. 更多
2. 更少
3. 相同
与虚拟机相比，我们在 Azure 应用服务计划中的管理权限有多少？
1. 更多
2. 更少
3. 相同
应用服务计划用于托管...
1. Web 应用
2. 数据库
3. 两者
插槽用于...
1. 托管应用程序的不同版本
2. 在不同区域托管应用程序
3. 处理增加的工作负载
Azure 应用服务计划的增加工作负载由...处理
1. 扩展
2. 横向扩展
3. WebJobs
最好的 Azure Web 应用监控工具是...
1. Splunk
2. 日志分析
3. 应用洞察
Azure Web 应用的高可用性通过...实现
1. 扩展
2. 横向扩展
3. 流量管理器
流量管理器支持...
1. Azure 终结点
2. 外部终结点
3. 两者
为 Azure Web 应用提供的隔离和专用环境是...
1. Azure 应用服务计划
2. Azure ASE
3. Azure 虚拟机

第五章：Azure 数据平台

任何 IT 系统中最重要的部分是数据。没有数据，应用程序和 IT 系统就没有意义。我们讨论了如何在 IaaS 和 PaaS 模型中设置应用程序，但我们如何设置数据库呢？

在本章中，我们将讨论数据库选项以及如何创建托管我们数据库的环境。

我们将涵盖以下主题：

Azure 虚拟机中的 SQL Server
数据库即服务（DaaS）
Azure SQL 数据库
Azure 数据和分析平台

技术要求

本章您需要以下内容：

一个 Azure 订阅
SQL Server 管理工作室

Azure 数据库选项

理解 Azure 中的数据库选项是我们云端旅程中的一个非常重要的部分。我们使用的所有服务最终都需要在某个地方存储信息。微软 Azure 提供了广泛的数据平台和多个服务，供我们存储数据。我们将从关系型数据库管理系统（RDBMS）开始，这是最传统的数据库模型，并将讨论 SQL Server 的云选项，作为微软的本地解决方案用于 RDBMS。

在 Azure 中运行 SQL Server 有两种不同的选项——IaaS 和 PaaS。PaaS 中的数据库通常被称为 DaaS。我们将解释这两种方法，并研究 Azure 数据平台中的其他服务。

SQL Server 作为 IaaS

将 SQL Server 作为 IaaS 运行需要创建一个 Azure 虚拟机来托管我们的 SQL Server。我们可以选择创建一个干净的虚拟机，并使用操作系统镜像自行安装 SQL Server，或者我们可以创建一个已包含 SQL Server 的虚拟机。在这两种情况下，管理数据库与在本地环境中管理数据库的方式没有太大区别。您将拥有完整版本的 SQL Server，包含您在本地版本中所有的选项。

让我们开始创建一个用于 SQL Server 的虚拟机，并解释所有细节。

创建一个包含 SQL 镜像的 Azure 虚拟机

如前所述，您可以选择创建一个虚拟机（VM）并稍后安装 SQL Server，或者选择一个已经包含 SQL Server 的镜像。在这种情况下，我将选择一个名为 SQL Server 2016 SP1 企业版的镜像，该镜像已经包含 SQL Server。这个虚拟机是基于 Windows Server 2016 的，这将是我们的操作系统。

大多数选项与我们在未包含 SQL Server 的镜像中创建虚拟机时的选项非常相似。我们从基本信息开始，需要提供名称、虚拟机磁盘类型、用户名、密码、订阅、资源组和位置。强烈建议您在创建将运行 SQL Server 的虚拟机时使用 SSD 作为虚拟机磁盘类型。

磁盘速度对 SQL Server 性能影响很大，选择更快的磁盘类型有助于获得最佳性能。以下是所有基本设置的列表和示例截图：

我们的下一步是选择虚拟机的大小。根据磁盘类型，列表将限制为仅支持所选磁盘类型的大小。在为运行 SQL Server 的虚拟机选择大小时，我建议选择更多的 CPU 和内存。SQL Server 需要大量资源，选择合适的大小有利于性能。幸运的是，如果你选择的大小过大或过小，可以稍后进行更改。这是云计算的一个优势，你不会被初始大小所束缚。基于 SSD 的虚拟机大小列表如下所示：

设置面板包含我们之前使用过的所有选项，并且我们可以为每个选项设置默认值。如果你打算为 SQL Server 设置高可用性，请确保现在选择可用性区域和可用性集，因为这些设置无法在后续进行。此外，请注意虚拟机将要连接的网络、子网和网络安全组。如果使用了多个子网，你可能不希望 SQL Server 最终出现在 DMZ 中。NSG 也是如此——你可能希望为 SQL Server 设置与 Web 服务器不同的安全设置。幸运的是，这些设置可以稍后更改。设置的示例如下图所示：

最后，我们有一组特定于包含 SQL Server 的镜像的设置，这些设置在创建不包含 SQL Server 的虚拟机时无法找到。在 SQL Server 设置中，我们可以配置 SQL 连接性、SQL 身份验证、存储配置、自动修补、自动备份、Azure 密钥保管库集成和 R 服务（高级分析）。

SQL 连接性允许我们设置连接级别和端口。对于连接级别，我们可以仅允许从虚拟机内连接 SQL Server：私有（来自虚拟网络）和公共（通过互联网）。我强烈建议不要使用公共访问 SQL Server，这将使你的数据库暴露在互联网上，任何人都可以尝试访问，且你暴露了数据库给暴力破解攻击。仅从虚拟机内访问 SQL Server 也可能不是一个选项，除非你在单一虚拟机上运行所有服务，并且打算在同一服务器上运行应用程序。最常见的情况是来自虚拟网络内的私有访问，允许同一网络上的其他虚拟机访问数据库。SQL Server 的默认端口是 1433，但可以根据需要进行更改。

SQL Server 的默认身份验证方式为 Windows 身份验证，但如果需要，可以启用 SQL 身份验证。如果启用了 SQL 身份验证，虚拟机使用的用户名和密码也将作为 SQL 登录凭据。

目前，存储配置不可用，且此设置将在虚拟机创建后使用。

自动补丁更新默认设置为每周日 2:00。你可以将此设置更改为其他时间，或者将其禁用。我建议不要禁用此功能，因为它将确保你的 SQL Server 始终是最新的并已安装最新的更新，包括安全更新。然而，在某些情况下，你需要在安装更新之前进行测试，这时你可以选择禁用它们。请注意，在这种情况下，你需要负责保持服务器的更新。

默认情况下，自动备份是禁用的。如果启用，你将有多个可用选项。你可以选择存储帐户来存放备份；默认保留期为 30 天，可以设置为较低的值（最小 1 天，最大 30 天）。备份加密可以设置为开启或关闭；如果需要，可以包括系统数据库的备份。最后一个选项是配置备份计划。默认设置的自动备份将每周执行一次备份操作。你可以将此设置更改为每天备份。你可以设置备份的时间以及频率。（可以配置为每 5 分钟备份一次，或者每天备份一次。）

最后两个选项是 Azure Key Vault 集成和 R 服务（高级分析），它们允许你在需要时启用这些功能。Azure Key Vault 将要求提供将使用的 Key Vault 信息，R 服务将简单地安装附加的分析功能。

以下是 SQL Server 设置的示例：

部署带有 SQL Server 的 Azure 虚拟机比部署没有 SQL Server 的类似虚拟机需要更长的时间。这是因为需要传递额外的信息并在虚拟机内配置 SQL Server 实例。

在 Azure 虚拟机中管理 SQL Server

一旦带有 SQL Server 的虚拟机部署完成，你可以找到与其他 Azure 虚拟机非常相似的设置。唯一的区别是可以在这里找到 SQL Server 配置。

在 SQL Server 配置下，新增了一个选项卡，它具有与创建带有 SQL Server 的新虚拟机步骤中的 SQL Server 设置相同的选项。

此选项卡中的第一个选项是存储；这是之前被禁用的选项。在这里你可以找到存储使用情况和性能。

接下来是 SQL 连接设置，你可以在其中更改访问级别和 SQL Server 端口，并启用 SQL 身份验证（如果之前已启用，则可以关闭）。

以下是显示存储和连接部分的屏幕截图：

在 SQL Server 配置下，其他可用的设置包括自动补丁更新、自动备份、Azure Key Vault 集成和 R 服务（高级分析）。这些功能的所有设置与创建虚拟机时的设置相同。以下是带有其他设置的屏幕截图：

我们可以连接到虚拟机并使用 SQL Server Management Studio 连接到 SQL Server。或者，如果 SQL Server 访问已设置为公开，您也可以从自己的计算机执行相同的操作。正如您所见，连接到 SQL Server 时，您可以使用所有本地 SQL Server 环境中可用的选项和功能。从此时起，在云中管理和维护数据库与在本地服务器或虚拟机中操作没有区别。

我们可以执行任何操作并进行任何更改，就像在本地环境中一样。以下截图显示了所有可用于本地 SQL Server 的选项也适用于 Azure 虚拟机中的 SQL Server：

管理和维护虚拟机本身与管理任何其他 Azure 虚拟机没有区别。所有设置完全相同；唯一的区别是带有 SQL 的虚拟机具有额外的功能，如 SQL Server 配置。

现在我们将转向 SQL Server 作为 PaaS，并尝试比较每个选项为我们提供的内容以及可用的选择。

Azure 虚拟机上的 SQL Server 高可用性

在 Azure 虚拟机中管理 SQL Server 与本地 SQL Server 没有太大区别。创建高可用性解决方案时也可以说类似的事情。

在 Azure 虚拟机中为 SQL Server 创建高可用性有几个选项：

Always On 故障转移集群实例
Always On 可用性组
数据库镜像
日志传输

请注意，为了创建这样的解决方案，虚拟机必须放置在可用区和/或可用性集内。

SQL Server 作为 PaaS

以 PaaS（平台即服务）或 DaaS（数据库即服务）形式运行数据库让我们可以利用 PaaS 的优势。这意味着我们可以使用更少的设置，但也有更少的维护需求。我们无法直接访问 SQL Server，也不能执行许多操作，但我们仍然可以通过可用的预配置选项进行管理。

让我们开始创建 Azure SQL 数据库并解释所有选项。

创建 Azure SQL 数据库

要创建一个新的 Azure SQL 数据库，我们需要提供一组标准信息，如数据库名称、订阅和资源组。额外的信息特定于 Azure SQL 数据库；我们需要选择源，提供服务器和定价层。还可以选择是否希望使用 SQL 弹性池？这个选项与定价层直接相关，稍后我们会详细介绍。对于数据库源，我们可以选择空白（空数据库）、样本（AdventureWorkLT，标准的微软样本数据库）或从备份（如果选择此选项，我们需要提供备份存储位置的信息）。

数据库的排序规则始终为 SQL_Latin1_General_CP1_CI_AS，并且无法更改。以下截图显示了设置列表：

数据库无法独立存在，必须有一个服务器，因此在创建 Azure SQL 数据库时，我们需要提供服务器。如果没有现有的服务器，我们需要创建一个新的服务器。我们需要提供一个名称（一个唯一的名称，将作为公共端点使用）、用户名、密码和位置。

Azure SQL 数据库的定价可能会让人感到困惑，因为有多种定价方式。第一种方式是单一数据库定价。在这种定价模式下，按数据库收费，服务器是免费的。您可以在单台或多台服务器上拥有多个数据库；价格是基于数据库数量，服务器数量不会影响定价。例如，我们可以拥有 10 个 Azure SQL 数据库。如果这些数据库位于同一台服务器或 10 台不同的服务器上，价格都是一样的。真正复杂的部分在于定价单位，数据库事务单位（DTU）。这是一个综合指标，衡量 CPU、内存、数据 I/O 和事务日志 I/O。传统上，在本地环境中，我们会监控 CPU、内存和磁盘 IOPS，然后将其转化为 DTU，但事情并不那么简单。幸运的是，我们有能力随时间调整选择的规格，如果我们确定数据库性能受影响或未能充分利用现有资源，可以进行更改。DTU 模型中的可用层级有 Basic、Standard 和 Premium，每个层级对应不同的 DTU 值。Basic 层提供 5 个 DTU，Premium P15 层最高可达 4000 个 DTU。可用空间也会受到层级的影响，从 Basic 层的 2 GB 到 P15 层的 4 TB 不等。以下是 DTU 层级选择的截图：

由于 DTU 模型过于复杂，微软最近决定引入一种基于 vCore 的新 Azure SQL 数据库定价模型。该模型允许您选择将分配给数据库的 vCore 数量以及可用的内存大小。vCore 的数量可以从 2 个到 80 个不等。内存大小取决于 vCore 的数量，范围从 5.5 GB 到 408 GB。以下是 vCore 层级选择的截图：

我们提到过，弹性池也是一个与定价相关的选项。这是基于资源池化的完全不同的模型。如果选择弹性池作为 Azure SQL 数据库的定价模型，则价格不由数据库数量决定，而是由池的大小决定。对于单个数据库的定价模型适用的两种定价模式也适用于弹性池，我们可以选择弹性池资源是基于 DTU 还是 vCore 来计算的。弹性池和单个数据库定价模型的区别在于，选择的资源数量是可供池使用的，并且池中的数据库共享这些资源。因此，如果我们为弹性池选择 4000 DTU，这些资源将由池中所有的数据库共享。如果所有数据库在同一时间高度利用，这种方式并不理想，此时应选择单个数据库定价模型。但如果你的数据库在一天中的不同时间有较高的工作负载，这就是理想的场景。

假设你正在为全球各地的客户托管应用程序。这将导致每个客户的数据库工作负载不同，且根据时区的不同，在不同的时间表现不同。一个数据库在欧洲的工作时间内将有较高的工作负载，而在美国的工作时间内工作负载较低。位于美国的客户的数据库在欧洲的工作时间内负载较低，但在美国的工作时间内负载较高。将这些数据库放置到弹性池中可以让你共享资源，数据库可以在不同时间段内使用更多可用资源。

Azure SQL 数据库的部署时间取决于层级和来源。来源决定了数据库的大小以及需要执行的操作类型。从逻辑上讲，创建一个空数据库的时间要比恢复一个包含数 GB 或 TB 数据的备份所需的时间短。

部署完成后，我们可以看到两个资源：SQL 服务器和 SQL 数据库：

管理 Azure SQL 数据库

管理 Azure SQL 数据库从防火墙设置开始。默认情况下，只有 Azure 服务可以连接到你的数据库。要允许其他连接，你需要设置一个防火墙规则，允许来自指定 IP 地址的连接。要添加你的 IP 地址，选择“添加客户端 IP”。Azure 门户会自动检测你当前的 IP 地址并添加防火墙规则。注意，执行更改时始终需要选择“保存”选项。如果你不保存新设置，添加新 IP 地址到防火墙规则中是没有意义的。

这种情况曾多次发生在我身上——我添加了一个新的 IP 地址，花了一些时间去弄清楚为什么无法连接，结果才意识到我忘了点击“保存”。防火墙设置如下图所示：

一旦添加了我们的 IP 地址，我们就可以使用SQL Server Management Studio（SSMS）连接到 Azure SQL Server。请注意，与本地 SQL Server 实例相比，我们可用的选项有限。除了数据库和安全性外，其他所有选项都已消失，我们不能像在本地环境中那样管理数据库。SQL Server 与 Azure SQL 之间的对比如下所示：

幸运的是，Azure 提供了许多管理数据库的选项，大多数功能都不会被错过。数据库的管理和维护在 Azure SQL 中变得前所未有的简单。

Azure SQL 的第一个独特选项是查询编辑器。这意味着我们不再需要 SSMS；可以直接通过浏览器运行任何查询。在 SSMS 中执行的一些任务也可以在 Azure 门户中完成。Web 查询编辑器的截图如下：

Azure SQL 数据库的 SETTINGS 包含常见选项，如属性、锁定和自动化脚本。配置也是 Azure 资源设置中常见的选项，但独特的选项包括地理复制、连接字符串、同步到其他数据库和添加 Azure 搜索。同步到其他数据库允许你创建同步组，并设置一组将自动同步的数据库。添加 Azure 搜索选项允许你将数据库连接到搜索服务，从而无需额外的编码或配置即可执行全文搜索。

SETTINGS 下的配置选项允许你更改数据库层级。这将打开一个新的面板，界面与创建数据库时选择数据库层级相同。数据库层级更改的截图如下：

连接字符串允许你为各种编程语言查找数据库的连接字符串。

以下是ADO.NET的连接字符串示例：

Server=tcp:packt.database.windows.net,1433;Initial Catalog=Demo;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

第六章：Azure Storage、备份和站点恢复 - 将数据迁移到 Azure

本章将重点讨论将数据迁移到 Azure。我们将从 Azure Storage 开始，因为它是 Azure 中最重要的服务之一。一切从 Storage 开始，了解它的使用非常重要。我们将讨论如何使用 Azure Storage 进行备份，以及如何将工作负载迁移到云端。此外，我们还将讨论如何使用Azure 备份和Azure 站点恢复（ASR）加快迁移过程，并将数据迁移到 Azure。

本章将涵盖以下主题：

Azure Storage
Azure 备份
Azure 站点恢复

创建高可用性的 Azure SQL 数据库

创建 SQL Server 高可用性解决方案可能会非常复杂，配置困难，维护和管理起来更是困难重重。而 Azure SQL 数据库的高可用性则容易得多，几乎不需要维护。

我们需要从 Geo-Replication 开始。地理复制刀片显示了世界地图，并标示了当前数据库所在的以及所有可供复制的数据中心。当前数据库所在的数据中心用蓝色标记。建议用于复制的数据中心用紫色标记（这是离当前数据中心最近的数据中心），其他所有可用数据中心用绿色标记。在地图上，您可以看到有关当前数据库的信息，该数据库将是我们的主数据库。以下是地理复制刀片的示意图：

要创建新的数据库副本，我们可以在地图上选择任何数据中心来启动新的刀片。将打开“创建辅助刀片”，在其中我们需要提供目标 SQL Server（如果选定位置没有该服务器，则创建新服务器）。数据库名称将与原始名称相同，并且数据库将处于只读模式。定价层次将与原始相同，但您可以将层次更改为另一个值。创建辅助数据库所需的设置示例如下所示：

部署完成后，地图会发生变化，显示主数据库和辅助数据库之间的连接。部署时间取决于数据库的大小。

在部署过程中，空数据库会在辅助数据中心创建，然后数据从主数据库复制到辅助数据库。以下是实施复制后的地图示例：

然而，请注意，这只是创建主数据库的可读副本。在灾难发生或主数据库不可用的情况下，辅助数据库必须手动从只读模式切换为读/写模式，并且所有连接字符串必须手动更改。这实际上并不能算作高可用性解决方案，因此我们需要通过创建故障切换组来采取额外的步骤。

在故障转移组面板中，我们需要提供主服务器、备用服务器、故障转移组名称、读/写故障转移策略以及读/写宽限期（小时）。故障转移组名称必须唯一，这将成为连接到数据库的新端点。连接到故障转移组名称时，只要主服务器可用，连接将自动指向主服务器。

如果主服务器不可用，所有指向故障转移组名称的连接将会自动指向备用服务器。所有故障转移和故障恢复过程都将自动进行，无需用户操作。这里展示了故障转移组选项的截图：

如您所见，创建 Azure SQL 数据库高可用性解决方案简单快捷。创建后无需用户操作，故障转移和故障恢复都会自动进行。如果您曾在本地环境中创建过类似的解决方案，您可能知道故障恢复过程有多复杂。

Azure SQL 数据库安全

对于数据而言，安全性非常重要（并非其他资源可以忽视安全性）。在 Azure SQL 数据库面板下，我们有一组与安全性相关的选项。安全选项包括高级威胁保护、审计、动态数据掩码和透明数据加密。高级威胁保护和审计可以在服务器级别（针对该服务器上的所有数据库）或单个数据库上应用。

高级威胁保护包含三个子部分：

数据发现与分类（预览）
漏洞评估
威胁检测

数据发现与分类（预览）功能仍处于测试阶段，但非常有用。数据库将进行扫描，并提供建议，指出哪些列应标记为分类数据。在考虑需要遵守通用数据保护条例（GDPR）时，这尤其有用。

漏洞评估将进行安全扫描，并为您的数据库提供安全建议。例如，建议跟踪防火墙规则或分类敏感数据。

威胁检测将机器学习应用于您的安全性。此功能分析正常行为，并提醒您任何异常操作。例如，如果某个 SQL 登录帐户通常只在工作时间访问数据库，而突然在其他时间尝试登录，您将收到警报。或者，如果某个登录帐户始终来自特定 IP 地址，但尝试从世界另一端访问数据库，系统也会检测到并提醒您。

这里展示了高级威胁保护的截图：

审计功能允许我们跟踪事件并将其记录到存储帐户中。我们可以定义日志保留期，以及是否在数据库或服务器级别记录事件。由于审计通常是许多组织的要求，特别是为了符合不同的标准，这个选项允许您满足这一要求。以下是审计日志的截图：

在继续进行动态数据屏蔽之前，让我们先运行一个简单的查询。在表 SalesLT.Customers 中选择前 100 行将返回该表中前 100 个客户的所有信息。这里有各种类型的数据，我们可能不希望所有有数据库访问权限的人都能看到这些信息。我们以电话号码为例。请注意，在以下截图中，我们可以看到运行查询会返回电话列：

动态数据屏蔽面板将提供有关当前应用的所有屏蔽规则的信息，并建议您可能想要考虑用于屏蔽的其他规则。请注意，SQL 管理员不受数据屏蔽影响，您可以添加额外的用户来排除在外。以下是动态数据屏蔽的截图：

要添加新的规则，我们需要提供架构、表、列和屏蔽字段格式。屏蔽字段格式将允许您控制查询结果中屏蔽数据的显示方式。下面是如何为数据屏蔽添加电话列的示例：

一旦应用了数据屏蔽规则，我们可以再次运行查询。如以下截图所示，应用屏蔽规则后，结果将会不同，电话列的所有值都会返回xxx：

使用动态数据屏蔽，我们可以控制用户对数据的访问，防止他们查看机密信息。例如，如果我们在同一张表中有账单信息和联系信息，我们可能希望为不同的用户提供对该表的访问权限，但允许他们查看不同的信息。我们可以允许销售部门查看电子邮件或电话号码，但希望防止他们查看信用卡信息。另一方面，我们不希望阻止所有人查看信用卡信息，并希望允许财务部门访问这些信息。动态数据屏蔽非常适合这种场景，其中用户可以访问相同的表格，但查看不同的信息集。

透明数据加密（TDE）用于加密处于静态状态的数据库。此功能适用于本地版本的 SQL Server，但实现起来并不简单。对于 Azure SQL 数据库，创建的新数据库会自动开启此功能。以前并非如此，对于旧数据库，可以通过简单地开启 TDE 选项来启用此功能。就是这么简单，数据库（以及所有备份）都会在静态状态下被加密。下面的截图展示了透明数据库加密的界面：

监控和故障排除 Azure SQL 数据库

Azure SQL 数据库的监控选项与其他 Azure 资源的选项非常相似。监控选项包括警报（经典）、度量（预览）和诊断设置。所有这些功能也适用于 Azure 虚拟机和 Azure Web 应用程序，这些内容在前几章中已有介绍。

支持 + 故障排除选项为我们提供了一些特定于 Azure SQL 数据库的功能。功能包括资源健康和新支持请求，和其他 Azure 资源类似。新功能包括性能概述、性能推荐、查询性能洞察和自动调优。

性能概述为我们提供了查询性能的概览。在这里，我们可以查看查询的资源消耗情况。概述为我们提供了按资源类型聚合的查询消耗情况。资源类型包括 DTU、CPU 和 IOPS。此聚合会显示消耗最大资源的查询，但由于这是聚合消耗，可能是查询频繁执行的结果，而不是单次执行时消耗大量资源。我们可以在“长时间运行的查询”选项卡下查看执行时间较长的查询列表。这些信息可以帮助我们提高性能，因为经常执行的查询和执行时间较长的查询消耗了大量资源。优化这些查询可以提高性能，并在长期内节省成本。以下图表展示了性能概述中 CPU 消耗的情况：

在性能列表下，我们可以看到根据数据库的性能历史记录提供的推荐事项。它会给出推荐的列表，并提供自动应用这些建议的选项。在性能推荐面板中，我们可以看到新的推荐事项以及已应用的推荐，如下所示：

查询性能洞察提供了与性能概览非常相似的选项。不同之处在于，你可以在查询性能洞察中自定义和编辑图表与仪表板。你可以更改显示的不同指标和时间段，帮助你在更长时间内观察性能。查询性能洞察的默认界面如下所示：

自动调优选项是所有数据库管理员的梦想成真。此选项将使用内置的智能，观察性能随时间的变化，并应用机器学习解决方案来提高数据库性能。此选项可以在服务器或订阅级别自动启用。此外，还可以为单个数据库启用或禁用该选项。自动调优可用的设置包括 FORCE PLAN、CREATE INDEX 和 DROP INDEX。如果启用，自动调优将分析性能并自动应用有助于提高性能的更改。以下是自动调优设置的示例：

Azure SQL 数据库备份

对任何数据库管理员来说，备份是非常重要的任务。此选项在 Azure SQL 数据库中默认启用。当创建新的数据库时，会在过程中创建地理冗余存储，并在此存储中执行备份。此功能是自动提供的，且免费。对于 Azure SQL 数据库，使用 SQL Server 备份技术来创建完整、差异和事务备份。事务备份每 12 小时执行一次，差异备份则根据数据库大小和活动，每 5 至 10 分钟执行一次。这使得我们能够通过恢复所选时间点之前的最后一次完整备份、完整备份和所选时间点之间的所有差异备份，最后还原最后一次差异备份和所选时间点之间的所有事务备份，从而实现时间点恢复。

备份的保留期限取决于数据库层级，可从 7 天至 35 天不等。还可以启用长期保留备份（LTRB）选项，保留备份最长可达 10 年。默认备份是提供的无额外费用的选项，但 LTRB 使用额外的存储，且需要额外收费。然而，在某些情况下，我们需要长时间保留备份，这时此选项非常有用。此外，存储费用较低，因此不会对账单产生较大的影响。

另一个与备份直接相关的选项是数据库导出。此功能允许你将数据库的额外副本保存在独立存储中。此备份可以用于在新服务器或另一个订阅中恢复数据库。导出将创建一个包含模式和数据的 BACPAC 文件。

Azure 中的其他数据服务

虚拟机中的 SQL Server 和 Azure SQL 数据库仅是 Azure 数据平台的一部分。

当我们谈论 IaaS 中的 RDBMS 时，其实我们没有任何限制。我们可以创建任何类型的虚拟机，安装多种不同的操作系统，安装任何我们想要的软件，比如 Oracle、MySQL、PostgreSQL 等。也有许多包含预装该软件的镜像。同样，NoSQL 数据库也是如此：我们可以在虚拟机上安装任何东西，或者选择一个已经包含 MongoDB、CouchDB 等的镜像。

当谈论 PaaS 模型中的 RDBMS 时，我们也有不同的选项，如 MySQL、PostgreSQL、SQL 数据仓库等。作为 PaaS 运行 NoSQL 也提供了不同的选项，包括 Azure Cosmos DB 或 MongoDB。

Azure 数据平台通过 Azure 的分析服务得到扩展，这些服务在 IaaS 或 PaaS 模型中都有多种选择。

总的来说，Microsoft Azure 为数据和分析提供了不同的选项，无论你是迁移现有解决方案还是构建新的云解决方案。你可以在不同的 IaaS 和 PaaS 服务之间进行选择，并结合它们为特定场景提供最佳的结果。

以下是显示 Azure 中一些数据库和分析选项的截图：

摘要

Azure 数据平台在选择同时使用 IaaS 和 PaaS 时提供了多种选项。在 IaaS 中运行数据库提供了更多的控制，但也需要更多的维护和管理。DaaS 具有许多使数据库管理员生活更轻松的功能，但它不支持运行某些功能和遗留应用程序。最重要的是，我们需要决定如何继续，并根据我们解决方案所需的选项以及不同数据服务提供的选项来评估理想的选择。

一旦数据进入云端，Azure 提供了许多分析选项，这些选项可以帮助我们扩展我们的解决方案。同样，我们可以在不同的 IaaS 和 PaaS 服务中进行选择，挑选最适合我们的服务。

在前几章中，我们讨论了如何在 Azure 中设置应用程序和数据。创建和设计新应用程序是很棒的，但并不总是可行的。在大多数情况下，旅程从将现有解决方案从本地迁移到云开始。在下一章中，我们将解释迁移现有应用程序和数据库到 Azure 的可用选项。

问题

在 Azure 中，数据库可以运行为...
1. IaaS
2. PaaS
3. 两者
带有 SQL 的 Azure 虚拟机与不带 SQL 的虚拟机不同，因为...
1. SQL 服务器配置
2. 内存和 CPU 的数量
3. 它的名称
Azure SQL 数据库也叫做...
1. 数据库即服务
2. SQL 即服务
3. 数据即服务
Azure SQL 数据库的层级可以以...来衡量
1. DTU
2. vCores
3. 两者
你可以在 Azure SQL 数据库上运行查询，使用...
1. SQL Server 管理工作室
2. Azure 门户中的查询编辑器
3. 两者
要连接到 Azure SQL 数据库，你需要...
1. 向防火墙规则添加 IP 地址
2. 在 VNet 中允许 IP
3. 在主数据库中允许 IP
要创建 Azure SQL 数据库副本，您可以使用...
1. 数据库备份
2. 数据库导出
3. 地理复制
要创建一个高度可用的 Azure SQL 数据库，您需要创建一个...
1. 故障切换组
2. 故障切换集群
3. 常开
要在 Azure SQL 数据库中遮蔽列，您可以使用...
1. 透明数据加密
2. 动态数据遮蔽
3. 数据分类
为了检测数据库的潜在威胁，您可以使用...
1. 漏洞评估
2. 高级威胁防护
3. 两者

技术要求

本章所需内容：

一个 Azure 订阅
一个运行 Windows Server 2012 R2 或更高版本的本地服务器
一个 Hyper-V 服务器
一个本地的 SQL Server 2012 或更高版本实例

Azure 存储

Azure 存储是 Microsoft Azure 中一个非常重要的服务。几乎所有 Azure 服务都以某种形式使用存储。在某些情况下，存储的使用是显而易见的，而在其他情况下，它则是一个我们未曾察觉、默默运行的后台服务。

例如，如果我们创建一个新的虚拟机，虚拟磁盘将在此过程中创建。这些磁盘会存储在 Azure 存储中。如果使用托管磁盘，存储会在后台创建且不可见。如果我们不使用托管磁盘，创建过程中产生的存储将显示在资源中，因为当没有使用托管磁盘时，存储的管理由我们负责。

类似地，当任何 PaaS 资源被创建时，存储会在后台创建。在大多数 PaaS 案例中，存储不可直接看到，但我们可以在资源面板中看到可用和使用的存储量。例如，Azure SQL 数据库或 Azure 应用服务计划会根据不同的层级提供一定数量的资源。我们没有直接访问存储管理的权限，但可以看到关于存储空间的信息。

但 Azure 存储也可以作为独立服务使用并进行独立管理。为了说明这个服务，我们先从创建一个新的 Azure 存储账户开始。

Azure 恢复服务

另一个帮助迁移到云的服务是 Azure 恢复服务。这个服务包含一些功能，能够帮助我们将数据迁移到云端：

Azure 备份
Azure 站点恢复

这两项服务不仅用于将数据迁移到云端，还用于保护 Azure 和本地资源。它们的主要目的是保护资源，但一旦我们将数据存储在云中，这些数据也可以用于迁移操作。

创建恢复服务保管库

为了开始使用 Azure 恢复服务，我们必须创建一个恢复服务保管库。需要提供所有常规参数：名称、订阅、资源组和位置。请注意，如果您想保护 Azure 资源，位置非常重要。您将无法保护与恢复服务保管库位于同一位置的资源。下面是一个示例截图，展示了恢复服务保管库的参数设置：

创建一个 Azure 存储账户

为了创建 Azure 存储账户，我们需要提供名称、部署模型、账户类型、位置、复制策略、性能、安全传输要求、订阅和资源组。订阅、位置和资源组是所有 Azure 资源所需的常见设置。

存储账户名称必须在 Azure 中唯一，因为它用于构建存储账户的 URL。URL 是通过将存储账户名称加在标准 DNS 后缀前面构成的。例如，将存储账户命名为 packtdemo 会创建 URL packtdemo.core.windows.net，因此存储账户名称必须唯一。

部署模型允许我们在资源管理器和经典模型之间进行选择。由于经典模型已过时，推荐使用资源管理器，因此每次创建新资源时，我建议你选择资源管理器。

性能选项让我们可以在标准存储和高级存储之间进行选择。这基本上是选择 HDD 和 SSD，但也会影响存储的价格。高级存储采用 SSD，提供显著更好的性能，但价格上涨同样显著。

安全传输要求让我们选择启用或禁用此选项。启用时，所有传入的请求都必须通过 HTTPS 完成，并自动阻止任何通过 HTTP 的请求。此功能类似于 Azure Web 应用中的“仅允许 HTTPS”。由于此功能与安全性相关，我建议启用此选项。

这里显示了一张带有 Azure 存储账户选项的截图：

接下来，我们将介绍一些仅与 Azure 存储账户相关的设置。尽管性能选项也直接与存储相关，我们还可以在其他服务中看到选择存储性能的选项，例如虚拟机或某些 PaaS 资源。仅与存储账户相关的选项有账户类型和复制策略。

账户类型 让我们在三种选项之间进行选择：

存储（通用目的 v1）
存储 V2（通用目的 v2）
Blob 存储

通用目的 v2 存储支持所有通用目的 v1 支持的功能，并带来了一些更新的功能。特别是如果你想使用最新的 API 和功能，比如访问层，推荐使用通用目的 v2 存储，这样你可以使用热存储和冷存储。

热存储和冷存储让你可以根据存储的数据选择你想要使用的访问层。热存储每 GB 存储的费用较高，但存储事务的费用较低。冷存储每 GB 存储的费用较低，但存储事务的费用较高。因此，冷存储更适合用于归档，而热存储则适用于活跃的存储。这个功能的优势在于，你可以随时在不同的访问层之间切换，进行更改。

从通用目的 v1 升级到通用目的 v2 可以在任何时候进行（但不能反向操作），如果您已经拥有 v1 存储帐户并希望受益于 v2 的功能。然而，在某些情况下，您需要使用 v1 作为唯一选项。例如，当需要经典部署时（通用目的 v2 仅在资源管理器中受支持），或者当您需要使用较旧的存储服务 REST API 时。

Blob 存储帐户在处理块 Blob 时，支持与通用目的 v2 相同的功能，但仅限于块 Blob，不支持页面 Blob。由于价格非常相似，建议使用通用目的 v2 存储，因为它具有相同的价格但更多的选项。

帐户类型的选项如下图所示：

复制有三种选项，这些选项与帐户类型相同。我们可以在以下选项中进行选择：

本地冗余存储（LRS）
地理冗余存储（GRS）
只读访问地理冗余存储（RA-GRS）

LRS 基于类似于虚拟机的可用性集和可用性区域的策略。数据的额外副本保存在 Azure 数据中心中，以在硬件故障或更新时提供持久性和冗余。它旨在提供 99.999999999%（11 个 9）的 SLA。所有数据都保存在单一的数据中心内，并且可能的故障切换会自动触发。

GRS 的设计方式与 LRS 非常相似，不同之处在于副本存储在不同的 Azure 数据中心，这些数据中心距离原始数据中心数千英里。由于这一点，增加了持久性，SLA 为 99.99999999999999%（16 个 9）。冗余副本仅在自动故障切换触发时可供访问。

RA-GRS 与 GRS 的设计方式相同，不同之处在于即使未激活故障切换，冗余副本也可以进行读取。

复制选项如下截图所示：

Azure 存储帐户的其他选项包括虚拟网络和数据湖存储 v2。

如果我们启用虚拟网络，我们可以选择现有的虚拟网络（或创建一个新网络）并选择子网。这样，我们的存储将加入到选定虚拟网络上的子网，并为我们的存储分配一个私有 IP 地址，允许我们通过私有网络而不是互联网访问存储。数据湖存储 v2 目前是预览版，仅在满足一些要求的情况下可以启用。我们需要选择通用目的 v2 存储，它仅在有限数量的 Azure 数据中心中可用，并且预览版必须经过预批准。以下截图展示了这些选项：

请注意，帐户类型、复制和性能会影响 Azure 存储的价格。位置也是一个因素，因为并非所有资源在所有 Azure 数据中心的费用相同，但这对价格的影响不如其他三个选项重要。

Azure 存储帐户的部署非常迅速，通常在一分钟内完成。

Azure 存储设置

创建 Azure 存储帐户后，我们可以使用不同的选项来管理它。一些选项与其他 Azure 资源的选项相似，因此我们将重点关注 Azure 存储帐户的独特选项。

设置中的第一个选项是访问密钥。访问密钥用于验证对 Azure 存储帐户的访问。它们通常用于启用应用程序访问，因此你可以在这里找到连接字符串和访问密钥。共有两个访问密钥，如果你认为原始密钥已被窃取或泄露，可以重新生成它们。

跨源资源共享（CORS）允许你定义受信任的域。Web 浏览器实施安全限制，防止应用程序调用来自不同域的 API。CORS 提供了原始域安全访问来自其他域的 API 的方式。

配置允许我们更改一些在创建存储帐户时可用的设置。在此选项下，我们可以将存储从通用目的 v1 升级到 v2，修改性能和复制设置，启用或禁用安全传输要求。

Azure 存储会自动加密并保护静态数据。自动加密使用 Microsoft 管理密钥对 Azure 的 Blob、表、文件和队列进行加密。然而，加密选项允许我们使用自定义密钥进行加密。

共享访问签名（SAS）提供了一个有限时长的访问密钥。我们可以使用这个密钥为存储提供临时访问，并定义访问持续的时间。密钥过期后，无法再次使用。

在防火墙和虚拟网络设置下，我们可以更改存储的网络和访问设置。我们可以将存储附加到虚拟网络（VNet）和子网，或者更改它所关联的虚拟网络。通过防火墙，我们可以阻止来自不受信任 IP 地址的存储访问。我们可以将本地 IP 地址或其他受信任的 IP 地址列入白名单，只允许这些地址访问 Azure 存储，并防止其他人访问。

属性、锁定和自动化脚本是所有 Azure 资源的可用选项。

下一组选项与 Blob 服务相关。这里有 Blobs、定制域、软删除、Azure CDN 和 Azure 搜索。

Blob 允许您查看存储帐户中当前的 Blob 列表，并执行如创建新 Blob 或删除现有 Blob 等操作。此外，您可以访问 Blob 并查看其中的文件列表，并对文件执行操作，如下载或删除。

自定义域名允许您为存储帐户使用自定义域名。您可以设置 CNAME 记录，将其指向您的存储帐户，从而开始使用自定义域名，而无需使用提供的 DNS。

软删除允许您为存储设置保留策略。如果启用，默认的保留策略是七天，但可以更改为最长 365 天。软删除使您能够恢复任何已删除的 Blob。这也适用于由于覆盖而删除的 Blob，因此您可以恢复已删除的 Blob 或 Blob 的旧版本。

Azure CDN 和 Azure 搜索是将这些 Azure 服务链接到您的存储帐户的选项。Azure CDN 用于缓存存储内容，从而提高性能并减少延迟。Azure 搜索是一个完全托管的云搜索服务，提供更好的用户体验。

以下选项允许我们管理文件服务、表服务和队列服务。对于这些服务中的每一个，我们可以看到存储帐户中现有文件服务的列表，并且可以执行不同的操作，如删除现有服务、创建新服务或设置访问策略。

将数据库迁移到云端

一旦我们拥有存储帐户，就可以开始加载数据。这可以是任何类型的文件，我们可以将存储用作暂存阶段，在此阶段我们准备上传的文件，之后这些文件将被实际使用，或者我们可以上传直接由应用程序使用的文件。

多年来，我看到许多组织使用 Azure 存储作为本地 SQL 数据库的备份位置。这是一种便捷的方式，可以让我们开始云端之旅，因为它提供了相对便宜、离线且加密的存储。

一旦数据库存储到云端，下一步将是使用备份恢复 Azure 中的数据库，并开始将其作为 IaaS 或 PaaS 使用。

让我们看看如何直接将数据库备份到 Azure 存储。

将数据库备份到存储

为了将数据库备份到 Azure 存储，首先需要打开SQL Server Management Studio（SSMS），选择要备份的数据库，然后选择任务 | 备份.... 第一步在此截图中显示：

新窗口将打开，提供选项以选择数据库（如果在第一步中选择了正确的数据库，则该选项已经被选中，但可以更改，或者我们可以选择多个数据库）、备份类型（通常推荐全量备份）以及最后的目标位置。默认选项是磁盘，我们需要将其更改为 URL。以下是这些选项的截图：

选择 URL 作为目标后，我们必须选择添加，以提供路径。这将打开一个新窗口，我们需要提供 Azure 帐户信息以访问 Azure 订阅。完成后，我们可以从 SSMS 访问 Azure 订阅，并选择存储账户和 Blob 来存储备份。由于备份是通过 共享访问签名（SAS）执行的，因此我们必须创建一个新的 SAS 并提供过期日期。设置备份目标的过程如以下截图所示：

最后，我们点击确定，执行备份。备份所需的时间取决于带宽、数据库大小和存储类型。在此案例中，存储类型通常是标准存储，因为将备份存储到高级存储是多余的，并且我们为存档付费的服务是高端的。备份完成后，我们可以在 Azure 门户中看到存储账户下所选 Blob 中的文件信息。以下是 Azure 门户中文件信息的示例：

备份完成后，我们可以使用该备份在 Azure 中恢复数据库。然而，完整备份只能恢复到运行在 Azure 虚拟机（IaaS）上的 SQL Server 中。为了在 Azure SQL 数据库（PaaS）中恢复备份，我们必须使用 BACPAC。BACPAC 包含 SQL 数据库的数据和元数据。将 BACPAC 备份到 Azure 存储的过程与创建数据库完整备份的过程类似。

将数据库迁移到 Azure SQL

创建备份并恢复并不是迁移数据库到 Azure 的唯一选项。此过程可以在不使用备份的情况下，直接将数据库迁移到 Azure。

为了实现这一目标，第一步是选择数据库，点击加粗的任务（Tasks）并选择在 SSMS 中将数据库部署到 Microsoft Azure SQL 数据库的选项。第一步如以下截图所示：

第二步是连接到你的 Azure SQL Server。为此，我们需要在选择第一步中的选项后，选择新窗口中的连接...。此窗口如以下截图所示：

为了连接到 Azure SQL 数据库，我们需要提供服务器 URL、用户名和密码。确保你的服务器的公共 IP 地址已添加到 Azure SQL Server 的防火墙规则中，否则将无法连接。以下是连接选项的示例：

连接建立后，我们回到上一步的窗口。最后，我们必须提供将用于迁移的 Azure SQL 数据库的数据库层（将创建一个新数据库）。以下是数据库大小选项的示例：

处理完成后，我们将收到关于任务成功的消息。完成迁移所需的时间可能会受到多个因素的影响，如数据库大小、带宽和 Azure SQL 数据库层级。请注意，选择过小的层级（如果我们迁移的是大型数据库）将导致错误，因为目标数据库的性能可能不足以处理迁移大型数据库所需的工作负载。成功迁移的截图如下所示：

迁移完成后，我们可以使用 SSMS 连接到 Azure SQL 服务器，并找到已迁移的数据库，如下所示：

在某些情况下，即使选择了正确的 Azure SQL 数据库层级，迁移仍然会失败。这是由于数据库与 Azure SQL 数据库不兼容。例如，在使用 Azure SQL 数据库时，需要有聚集索引（对于本地部署的数据库推荐）。如果迁移的数据库没有聚集索引，迁移将会失败。幸运的是，有一个工具可以帮助我们进行评估，告诉我们数据库中可能存在的问题和问题。

数据库评估

要创建我们数据库的评估并确保它准备好进行迁移，我们可以使用 Microsoft 数据迁移助手。这个工具是免费的，可以从 Microsoft 下载中心下载。

安装此工具后，您可以开始一个新项目。选择评估，提供项目名称，源服务器类型和目标服务器类型。对于源，选择 SQL Server，对于目标，选择 Azure SQL 数据库。新项目的示例如下所示：

第二步是选择评估选项。您可以选择检查兼容性和功能一致性。兼容性将检查您的数据库功能，并提供是否存在任何阻止迁移的问题或已弃用的功能。功能一致性将检查是否有任何不受支持的功能或功能。例如，Azure SQL 数据库不支持 SQL Server Reporting Service (SSRS)，因此如果您的应用程序正在使用 SSRS，这可能会导致问题。我建议选择这两个选项，如下所示：

选择要检查的内容后，我们需要提供将要检查的源。为了进行评估，工具需要访问数据库，因此我们必须提供 SQL Server、凭据和数据库。选定的数据库将与 SQL Server 版本一起显示在列表中，如下所示：

执行评估所需的时间取决于数据库的大小和复杂性，可能需要几分钟到几个小时不等。评估完成后，我们将收到两个报告。第一个报告是关于功能兼容性的，以下是示例：

第二个报告是关于数据库兼容性的。如果运气好，而且数据库的维护定期进行，你将得到以下示例中的报告，显示没有兼容性问题，允许你将数据库迁移到 Azure SQL 数据库：

可能的兼容性问题之一是聚集索引。建议为数据库中的每个表都有一个聚集索引，但在 Azure SQL 数据库中，这是一个要求。另一个例子是 CLR 函数，它在 Azure SQL 数据库中不被支持。

可以使用评估工具进行评估，不仅适用于迁移到 Azure SQL 数据库，还适用于其他版本的 SQL Server。所以，如果你计划将数据库迁移到新版 SQL Server（无论是在 Azure 还是本地部署），该工具也能对这些迁移进行评估。

Microsoft 数据迁移助手也可以用于执行数据库迁移。请注意，使用此迁移与通过 SSMS 迁移的区别在于，这里必须先创建 Azure SQL 数据库（空的 Azure SQL 数据库），然后才能进行迁移。

作为第三种迁移选项，Azure 数据库迁移服务也可以使用。实际上，这个迁移是一种数据同步选项，因为在运行此服务之前，必须先存在数据库和架构。Azure 数据库迁移服务允许你链接源数据库和目标数据库，将数据从源复制到目标，适用于整个数据库或选择的表。

启用 Azure 备份

一旦恢复服务库创建完成，我们就可以开始配置。如前所述，我们有两种不同的服务，且两种服务都可以用于保护 Azure 和本地资源。

让我们从在 Azure 资源上启用 Azure 备份开始。如果我们选择保护 Azure 中的工作负载，Azure 备份配置中可选的保护项有：虚拟机、Azure 文件共享（预览版）和 SQL Server 在 Azure VM 中（预览版）。我们选择虚拟机并继续。Azure 备份的 Azure 资源示例如下：

可用资源的列表将自动提供。选择虚拟机时，这将是一个包含 Azure 虚拟机的列表。如果选择的是 Azure 文件共享（预览版），那么将是一个包含文件共享的 Azure 存储帐户列表。我们选择要备份的虚拟机，如下截图所示：

启用备份后，我们可以在备份项下查看受保护虚拟机的列表。该列表还将显示状态、受保护资源的类型以及其他有用信息，如下所示：

备份本地资源

使用 Azure 备份保护本地资源需要多做一些工作。在 Azure 备份配置中选择本地资源后，我们会看到一个与选择 Azure 资源时不同的列表。我们可以选择文件和文件夹、Hyper-V 虚拟机、VMware 虚拟机、Microsoft SQL Server、Microsoft SharePoint、Microsoft Exchange、系统状态和裸机恢复。

在 Azure 门户进行配置后，我们需要安装恢复服务代理，它将允许我们在恢复服务库中注册本地资源。下面是恢复服务代理的截图：

为了继续注册，我们必须提供库凭证。库凭证以文件的形式提供，可以从恢复服务库下载。提供库凭证后，恢复服务代理将自动加载备份库信息，如下所示：

下一步是提供用于加密和解密备份的密码短语。密码短语必须至少包含 16 个字符，并将存储在您选择的位置。确保您知道密码短语存储的位置。否则，您将无法在需要时恢复任何备份。创建密码短语的过程如下所示：

一旦服务器在恢复服务库中注册，我们可以在目标服务器（也可以安装在客户端操作系统上）上使用 Microsoft Azure Backup 软件，配置备份的内容和时间。我们可以查看当前任务的状态并执行其他操作，如下所示：

要配置备份任务，我们需要提供备份的内容。我们可以选择整个驱动器，或选择特定的文件和文件夹，如下所示：

选择备份内容后，我们需要定义备份的时间和计划。我们可以选择每周或每天备份（最多一天三次）。以下是一个计划示例：

在设置了计划后，我们需要提供保留策略。保留策略定义了我们的备份将保持可用的时间，并可以按周、月和年进行配置。默认的保留策略如下所示：

最后的选项是配置初始备份将如何执行。由于初始备份通常意味着将备份大量数据，我们需要定义是通过网络直接执行备份（可能会产生过载），还是通过分阶段将数据部分复制到 Azure 存储，然后再复制到恢复库。下面显示了一个选项示例：

执行初始备份的时间取决于数据的大小和网络带宽。初始备份后，备份会以增量的形式执行（仅复制更改），并且完成时间不应很长。再次强调，保存密码短语非常重要，因为备份是加密的，如果没有用于加密的密码短语，您将无法恢复任何数据。

Azure 站点恢复

ASR 不是一个备份解决方案，而是一个灾难恢复（DR）站点，位于云中。拥有一个 DR 站点从未像在 Azure 中那样变得更容易且更便宜。大多数传统的 DR 站点涉及与受保护站点相同（或至少非常相似）的设备，成本约为原站点价格的 80%。另一方面，ASR 按受保护节点和存储数据的存储收费，因此非常便宜。如果在 Azure 中启用恢复，那么还会按虚拟机的计算价格收费。通过这种方式，您只需在发生故障转移时支付保护和计算费用。如果我们创建本地 DR 站点，我们即使在没有发生故障转移时，也必须支付用于运行 DR 所需的硬件费用，但仅作为保护使用。

ASR 还可以用于将虚拟机从本地迁移到云端。由于保护 Azure 虚拟机相对简单，我们将跳过保护 Azure 虚拟机的部分，直接演示如何保护本地虚拟机资源并使用 ASR 进行迁移。

配置 ASR 以保护本地资源

要开始在 Azure 中创建灾难恢复，我们必须首先在恢复服务库中配置 ASR。涉及三个步骤：

准备基础设施
复制应用程序
管理恢复计划

选择准备基础设施后，会打开一个新页面。在这里，我们有几个选项需要定义。首先，我们需要选择是否要保护 Azure 或本地资源。由于我想演示如何使用 ASR 进行迁移，我将选择本地资源。下一个选项是定义我们希望将资源复制到哪里，提供的选项是 Azure 或其他站点。

我们需要定义我们要保护的基础设施是否是虚拟化的，如果是，我们选择 Hyper-V 或 VMware。如果我们使用 Hyper-V，则需要定义是否使用 SC VMM。下面是保护目标页面的截图：

第二步将引导您进行部署规划。在此，我们可以下载工具来估算本地基础架构中 ASR 的要求。此步骤不是必须的，但建议执行，因为容量不足可能导致复制问题。可以直接从 Azure 门户下载部署规划工具，如下所示：

如果容量没问题，我们可以继续进行源准备。我们需要创建一个 Hyper-V 站点并注册一个应包含在复制中的 Hyper-V 服务器，如下所示：

在创建新站点后，我们需要在所有希望在该站点上保护的 Hyper-V 主机上下载并安装代理程序。此代理的安装类似于备份代理（我们需要从恢复服务保险库中下载的保险库凭据），完成安装后，Hyper-V 主机将显示在我们站点下。请注意，安装完成后，可能需要 15 到 30 分钟才能在 Azure 门户中看到 Hyper-V 主机。以下是成功注册的站点和主机的示例：

在设置完源环境后，我们还需要准备目标环境。我们需要选择 Azure 订阅和部署模型，并准备 Azure 基础架构。在基础架构下，我们需要为目标环境提供至少一个存储帐户和一个 VNet。存储帐户用于虚拟机磁盘，而 VNet 用于灾难恢复时，如果必须将虚拟机恢复到 Azure，虚拟机必须连接到 VNet。以下是目标配置的示例：

基础架构准备的最后一步是创建复制策略。我们需要定义频率、恢复点保留以及一些其他设置的规则。我建议保留所有默认设置，除了可能基于受保护服务器的角色更改的复制频率外。您还可以创建多个策略并根据需要应用它们。您可能不需要像数据库或文件服务器那样频繁地复制 Web 服务器，可以根据受保护服务器的角色使用不同的复制策略。以下是默认复制策略的示例：

基于前面的步骤，我们可以将多个源添加到单个密钥保险库。在同一个密钥保险库中，我们可以注册 Azure 资源、多个 Hyper-V 站点、VMware 站点或物理服务器。

在为 ASR 准备好基础架构后，我们需要定义要复制的内容及其时间。我们需要选择一个源（Azure 或本地）并选择在恢复服务保险库中注册的适当位置。以下是源选择的示例：

选择源后，我们还需要选择目标。必需的参数包括 Azure 订阅、资源组、部署模型、存储和网络设置。资源组将作为故障转移时虚拟机创建的位置。

虚拟网络也是如此，只有在发生故障转移并且需要在 Azure 中创建虚拟机时才会使用。存储用于放置虚拟机磁盘（VHD），即使没有故障转移，它也会被使用，因为即使虚拟机没有运行，数据也必须存储。目标设置的示例如下所示：

源和目标已经设置完毕，现在我们需要选择要保护的内容。这分为两步。第一步是选择我们希望保护的虚拟机，它们位于之前选择的站点中，如下所示：

在选择要保护的虚拟机后，我们必须为这些虚拟机提供其他设置。所需的设置包括虚拟机的操作系统和我们希望复制的磁盘。示例如下所示：

最后的步骤之一是选择要应用的复制策略。由于我们可以创建多个策略，因此可以分配一个最适合受保护虚拟机角色和设置的策略。复制设置的示例如下所示：

最后，一切就绪，点击“确定”后，我们可以启用复制并开始保护我们的虚拟机。最后一步如下所示：

使用 ASR 作为迁移工具

复制完成后，您可以在恢复服务保管库中的“受保护项”下查看已复制虚拟机的状态。您可以使用相同的面板来监视复制过程，并查看已复制项的百分比。完成初始复制所需的时间取决于网络带宽、存储设置和要复制的数据大小。成功复制的示例如下所示：

如果我们选择任何已复制项下的虚拟机，我们可以找到有关健康状态、事件以及故障转移选项（计划故障转移、故障转移和测试故障转移）的额外信息，如下所示：

不同的故障转移方式以及它们对主虚拟机的影响是不同的。例如，测试故障转移将在 Azure 中创建一个虚拟机实例，但不会对本地（主）虚拟机产生任何影响。另一方面，计划故障转移和故障转移会在 Azure 中创建一个新的虚拟机实例，将其声明为主虚拟机，甚至可以关闭本地虚拟机。

此窗格中还可以找到一个包含基础设施图的示意图，展示了在过程中涉及的所有组件如何连接。Hyper-V 站点的示意图如下所示：

故障切换和迁移虚拟机

由于我们复制虚拟机的目的是将其迁移到云端，让我们继续并展示如何执行此任务。

首先，我们需要执行虚拟机的故障切换。这里我们需要选择一个恢复点作为使用的恢复点，因为我们有多个恢复点。完成故障切换所需的时间取决于将要创建的虚拟机的大小、磁盘的数量以及这些磁盘上的数据大小。故障切换设置的示例如下所示：

故障切换完成后，虚拟机将会在 Azure 中运行，你可以像管理其他 Azure 虚拟机一样进行管理。请注意，这个虚拟机不会使用托管磁盘。这是因为 ASR 会将磁盘复制到存储中，并创建本地 VHD 的副本。当故障切换发生时，VHD 会用于我们的虚拟机并附加到虚拟机上，但因此这些磁盘没有托管。不过，您可以在需要时将迁移到托管磁盘。如果你计划完全迁移该虚拟机，我强烈建议执行迁移到托管磁盘。故障切换后的虚拟机如下所示：

完成故障切换后，虚拟机将在 Azure 中运行，但仍然与本地虚拟机相连。我们可以随时执行故障恢复操作，虚拟机会在恢复服务库中的复制项下列出。要完成迁移并仅在 Azure 中运行虚拟机，我们需要执行完整的迁移步骤。这将移除虚拟机与本地虚拟机以及恢复服务库的关联，如下所示：

其他选项

最终，我们的虚拟机已迁移到云端并在 Azure 中运行。使用 ASR 进行迁移可以最小化服务的停机时间，但这并不是唯一的选项。

AzCopy 也允许我们将数据从本地复制到云端，并可以作为所有类型文件的迁移工具。另一种选择是使用 PowerShell 将 VHD 上传到 Azure 并利用它们部署 Azure 虚拟机。

Azure 导入/导出作业用于将大量数据传输到 Azure。假设你有 4 TB 数据的磁盘，若通过互联网复制这些数据会耗费大量时间。使用 Azure 导入/导出作业，你可以在 Azure 中创建一个作业，将数据复制到物理磁盘上并将其运送到 Azure 数据中心。然后，磁盘将会在 Azure 门户中对你可用，你可以在云中使用这些数据。该过程也可以反向进行，你可以将数据从 Azure 导出并运送回自己。

总结

在我们介绍了基本的 Azure 服务，包括 IaaS 和 PaaS 后，我们讲解了将数据迁移到 Azure 的过程。微软提供了多种评估数据是否适合迁移到云端的选项，并且提供了多个工具来帮助将数据从本地迁移到 Azure。由于传入流量费用为 0，且只有从 Azure 输出的流量才会收费，因此我们可以看到微软希望数据去向何处。

Azure 之旅的下一步是混合云，它将帮助我们利用已有的本地资源，并结合云端的所有好处进行扩展。对于大多数公司来说，这种情形已经成为现实，因为大多数公司已经投资于本地资源。忽视现有资源并非一种选择，我们可以通过使用混合云扩展现有资源，从而利用 Azure 提供的服务。在第七章，《混合云与 Azure - 将本地工作负载扩展到云端》中，我们将讨论如何在 Azure 与本地基础设施之间创建安全连接，并将 Azure 用作混合云。

问题

Azure 存储帐户可以部署为...
1. 资源管理器
2. 经典
3. 两者
为了获得最佳的服务级别协议（SLA），存储帐户应为...
1. 本地冗余
2. 地理冗余
3. 两者
存储帐户层级可以是...
1. 标准
2. 高级
3. 两者
本地数据库能否备份到 Azure 存储帐户？
1. 是的
2. 不是
本地数据库能否直接部署到 Azure SQL 数据库？
1. 是的
2. 不是
要使用 ASR，您需要创建...
1. Azure 存储帐户
2. 恢复服务保管库
3. Azure 备份
使用 Azure 备份，您可以保护...
1. Azure 资源
2. 本地资源
3. 两者
使用 ASR，您可以保护...
1. Azure 虚拟机
2. 本地虚拟机
3. 两者
为了将受 ASR 保护的虚拟机迁移到云端，您必须...
1. 复制虚拟机
2. 执行故障转移
3. 启动 Azure 中的虚拟机
为了将大量数据迁移到 Azure，必须使用...
1. AzCopy
2. PowerShell
3. Azure 导入/导出作业

第七章：Azure 的混合云 - 将本地工作负载扩展到云端

混合云是云计算旅程中的一个重要组成部分，它帮助我们将 Azure（或任何其他云）与本地资源结合。在本章中，我们将讨论如何配置环境以及如何设置 Azure 和本地基础设施之间的连接，以便充分利用本地和云基础设施的优势。

本章将涵盖以下主题：

混合云
将虚拟网络连接到本地环境
本地数据网关
Azure Stack

技术要求

本章所需的内容：

一个 Azure 订阅
运行 Windows Server 2012 R2 或更高版本的本地服务器
支持 S2S 连接的 VPN（防火墙）设备

混合云

对于许多组织来说，完全迁移到云端并不是一个选择。尽管云提供了多种好处，但仍然有很多场景需要考虑。

例如，如果一家公司已经投资了本地基础设施，那么仅仅放弃所有投资并将所有内容迁移到云端是困难的。在创建本地数据中心时，我们需要投资服务器机房、网络、服务器、存储和软件许可证。没有商业理由放弃所有投资并开始在云上投资。

另一种场景是我们无法迁移特定服务的情况。在这种情况下，法律合规性可能会阻止我们将某些内容从本地数据中心迁移出去。例如，某些国家/地区不允许将用户的个人信息存储在该国之外。如果您所在地区没有 Azure 数据中心，这可能成为一个障碍，您可能需要将数据保留在本地数据中心。

在这两种情况下，当某些因素使我们无法使用云的所有服务时，我们可以通过设置混合云来利用云所提供的服务。这使我们能够将云服务与本地基础设施结合使用，创造出本地和云基础设施的最佳组合。

例如，我们可以在本地数据中心设置数据库（如果我们不能迁移数据库或有全新的数据库服务器），并设置会在后台使用本地数据库的云服务。这尤其适用于 Azure 数据分析平台，它提供多个强大的服务，可以为您提供快速的数据处理，并且仍然保留本地数据。

还有一种第三种场景，您可以使用来自多个云提供商的服务，并从每个提供商所提供的服务中受益。同样，我们需要设置混合云场景，以确保在您使用每个云中的服务之间的通信安全，并交换资源。

在混合云中设置安全性并确保数据安全的最佳方式是创建 Azure 与本地基础设施之间的直接连接。

连接本地网络和 Azure 虚拟网络

为了连接本地基础设施和 Azure，我们需要在本地网络和 Azure 虚拟网络之间创建一个连接。这个连接可以是点对站点（P2S）或者站点对站点（S2S）。由于 P2S 允许单个计算机访问 Azure 虚拟网络，它并不适合真正的混合云应用，更适合作为远程工作人员的访问点。

要建立真正的混合云，我们需要创建一个 S2S 连接，使得我们的本地网络和 Azure 虚拟网络之间可以进行全面的通信。通过这样做，我们将本地网络扩展到 Azure，并能够像访问本地环境中的资源一样访问 Azure 中的资源。

创建 S2S 连接有两种方式：使用 VPN 和使用 ExpressRoute。VPN 将提供两个网络之间的通信加密，而 ExpressRoute 更进一步，提供本地网络和 Azure 虚拟网络之间的专用连接。专用连接提供了更高的可靠性、更快的速度、更低的延迟和更高的安全性，但它必须作为由 ISP 提供的单独服务购买。

在本地网络和 Azure 虚拟网络之间建立连接是一个两步过程。首先，我们需要创建和配置 Azure 资源，第二步则需要配置我们的本地防火墙。在本地环境中，我们需要一个支持创建 S2S 连接并具备公网 IP 地址的 VPN（防火墙）设备。请注意，带有 S2S 选项的所有设备不都支持与 Azure 建立 S2S 连接。

创建 S2S 连接

要在 Azure 虚拟网络和本地网络之间创建 S2S 连接，首先我们必须创建两个 Azure 资源：虚拟网络网关和本地网络网关。

创建虚拟网络网关是在一个面板中完成的。我们需要提供的信息包括：名称、网关类型、VPN 类型、SKU、虚拟网络、网关子网地址范围、公网 IP 地址、订阅和位置。名称、订阅和位置是常规参数。

第一个选项是选择网关类型。可以选择 VPN 或 ExpressRoute（如前所述）。如果选择 VPN，则需要选择 VPN 类型是基于策略还是基于路由。（这个选项可能取决于您本地网络的设置。）下一步是选择一个 SKU，决定可用的带宽和连接数。可以启用或禁用活动-活动模式。此模式允许您创建冗余连接，从流量的角度来看，它们将被视为一个连接。换句话说，您需要在本地设备上创建两个 S2S 连接，这两个连接将流量路由到同一个虚拟网络。除非其中一个连接不可用，否则流量将通过两个连接路由，如果一个连接不可用，流量将通过仍然可用的 S2S 连接路由。

活动-活动模式不仅用于高可用性连接，还用于更好的性能。您需要选择一个可用的虚拟网络。可用的网络将取决于选择的订阅和位置。选择虚拟网络后，您需要为网关子网提供一个地址范围。如果该子网不存在，将自动创建（除非网络上没有空闲地址空间，否则该过程将失败）。请注意，不需要资源组。虚拟网络网关将在虚拟网络所在的同一资源组中创建。

接下来，您需要创建或选择一个现有的公共 IP 地址，该地址将用于连接。此 IP 地址用于与本地网络建立连接，并将在本地防火墙的配置中使用，以接受来自 Azure 的连接。我建议使用静态 IP 地址，以免 IP 地址发生变化时，您需要重新配置。

接下来是虚拟网络网关配置的示例：

创建虚拟网络网关需要 30 到 90 分钟。这是 Azure 中部署时间最长的资源之一。

Azure 虚拟网络网关部署的 ARM 模板在这里提供：

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"sku": {
"type": "string"
},
"gatewayType": {
"type": "string",
"defaultValue": "Vpn",
"allowedValues": [
"Vpn",
"ExpressRoute"
]
},
"vpnType": {
"type": "string",
"defaultValue": "RouteBased",
"allowedValues": [
"RouteBased",
"PolicyBased"
]
},
"existingVirtualNetworkName": {
"type": "string"
},
"newSubnetName": {
"type": "string"
},
"subnetAddressPrefix": {
"type": "string"
},
"newPublicIpAddressName": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2017-06-01",
"name": "[parameters('name')]",
"type": "Microsoft.Network/virtualNetworkGateways",
"location": "[parameters('location')]",
"dependsOn": [
"Microsoft.Network/virtualNetworks/PacktVnet/subnets/GatewaySubnet",
"[concat('Microsoft.Network/publicIPAddresses/', parameters('newPublicIpAddressName'))]"
],
"properties": {
"gatewayType": "[parameters('gatewayType')]",
"ipConfigurations": [
{
"name": "default",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"subnet": {
"id": "[resourceId('PacktIaaS', 'Microsoft.Network/virtualNetworks/subnets', parameters('existingVirtualNetworkName'), parameters('newSubnetName'))]"
},
"publicIpAddress": {
"id": "[resourceId('PacktIaaS', 'Microsoft.Network/publicIPAddresses', parameters('newPublicIpAddressName'))]"
}
}
}
],
"vpnType": "[parameters('vpnType')]",
"sku": {
"name": "[parameters('sku')]",
"tier": "[parameters('sku')]"
}
}
},
{
"apiVersion": "2018-04-01",
"type": "Microsoft.Network/virtualNetworks/subnets",
"name": "[concat(parameters('existingVirtualNetworkName'), '/', parameters('newSubnetName'))]",
"location": "[parameters('location')]",
"properties": {
"addressPrefix": "[parameters('subnetAddressPrefix')]"
}
},
{
"apiVersion": "2017-08-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[parameters('newPublicIpAddressName')]",
"location": "[parameters('location')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
}
}
]
}

在虚拟网络网关部署完成后，我们可以继续创建本地网络网关。本地网络网关用于输入本地防火墙和网络的信息。您需要提供本地防火墙的公共 IP 地址以及本地网络的地址空间（或者根据防火墙，提供本地网络的网关子网）。您还需要提供订阅、位置和资源组。位置应与虚拟网络网关和虚拟网络使用的相同。我建议将它们放在同一资源组中，以便于管理。以下是本地网络网关的示例设置：

本地网络网关部署的 ARM 模板在这里提供：

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"localNetworkGatewayName": {
"type": "string"
},
"location": {
"type": "string"
},
"gatewayIpAddress": {
"type": "string"
},
"addressPrefixes": {
"type": "array"
}
},
"resources": [
{
"name": "[parameters('localNetworkGatewayName')]",
"type": "Microsoft.Network/localNetworkGateways",
"apiVersion": "2017-06-01",
"location": "[parameters('location')]",
"properties": {
"localNetworkAddressSpace": {
"addressPrefixes": "[parameters('addressPrefixes')]"
},
"gatewayIpAddress": "[parameters('gatewayIpAddress')]"
}
}
]
}

与虚拟网络网关相比，部署本地网络网关相对较快，部署应在 5 分钟内完成。

配置 Azure 的 S2S 设置

在虚拟网络网关和本地网络网关创建后，我们可以继续进行配置。在虚拟网络网关中，我们在设置下选择连接类型选项。您将看到设置中有配置、连接和点对站点连接的选项。

由于我们将专注于 S2S 连接，因此我们只使用连接面板并添加一个新连接。我们需要像往常一样提供一个名称。虚拟网络网关、订阅、资源组和位置的选项是锁定的，无法更改，因为它们取决于用于创建连接的虚拟网络网关。我们需要提供的参数是连接类型和共享密钥（PSK）。连接类型的选项有 VNet 到 VNet、站点到站点（IPsec）和 ExpressRoute。由于我们希望连接到本地网络，因此选择站点到站点（IPsec）选项。对于共享密钥（PSK），我建议它尽可能复杂，因为安全性可能依赖于此。新连接的示例设置如下：

创建连接只是第一步；我们还需要为本地网络配置设置。在初步创建后，连接的状态将显示为未知，如下图所示：

配置本地防火墙以支持 S2S

本地防火墙的配置取决于供应商和设备类型。在已创建的连接下，有一个选项可以下载某些设备的配置。您可以选择不同的供应商（例如，Cisco 和 Juniper），并且还可以根据设备供应商、设备系列和固件版本下载特定的配置。只有少数设备可以直接从 Azure 门户下载。您可以在微软的文档中找到更多设备，有些供应商在其网站上有关于 Azure S2S 配置的部分。以下是配置下载过程的截图：

在双方配置完连接后，状态将更改为已连接，如下所示：

这将允许您通过安全的、私有的连接直接从本地网络连接到 Azure 虚拟网络中的任何资源。在某些情况下，您可能不希望将资源公开供公共访问，因此这是连接到资源的唯一方法。

在其他情况下，通常最常见的做法是服务公开访问，但管理是在私有网络上进行的。例如，允许通过互联网以 HTTP 或 HTTPS 访问网站，但仅允许通过私有网络访问数据库或 RDP 连接到虚拟机。

配置混合环境中的服务

一旦我们在本地网络和 Azure 之间建立了连接，我们就可以开始使用这两个环境中的服务，就像它们是一个单一站点或网络一样。然而，有一些事情需要我们牢记。

如果我们在本地环境中已设置了一个域，并希望在云端使用相同的域，那么在 Azure 虚拟网络中运行一个域控制器是一个不错的选择。即使我们已经建立了 S2S 连接，也可能会出现偶尔的连接中断。通过在云端运行一个 DC，我们可以确保 Azure 中的服务能够在中断发生时使用所有功能并独立运行。

当运行 SQL Server 并使用 Always On 可用性组时，你可以使用 Azure 扩展服务并在云端添加一个副本。如前所述，运行 Azure 有两种模式：资源管理器和经典模式。经典模式支持通过向导在 Azure 中添加副本，并且相对容易设置。

资源管理器需要使用 T-SQL 命令在 Azure 资源管理器模式下添加副本，但这稍微有些复杂。不过，由于资源管理器是推荐的模式，我建议使用资源管理器，因为经典模式迟早会被淘汰，最终你还是需要设置资源管理器。

另一个需要考虑的因素是 Azure 混合权益（Azure Hybrid Benefit），它允许你在 Azure 中使用现有的本地许可证。通过软件保证，你可以使用 Windows Server 和 SQL Server 的许可证，并以显著的折扣部署 Azure 资源。

在建立本地网络与 Azure 之间的连接时，数据中心的位置非常重要。如果你位于一个大陆，而 Azure 数据中心（虚拟网络部署所在的数据中心）位于另一个大陆，你将会遇到网络延迟和滞后。选择离你最近的地理位置是最佳的选择。

如果你遇到网络延迟和滞后问题或性能问题，可以考虑使用 ExpressRoute 服务。虽然这需要付费，但它提供了企业级的连接，具有最佳的可靠性、速度和安全性。

跨 Azure 连接虚拟网络

虚拟网络网关可用于连接不同的 Azure 虚拟网络。但因为你需要为虚拟网络网关付费，我建议采用另一种方法。要将 Azure 虚拟网络连接到另一个 Azure 虚拟网络，我们可以使用对等连接。通常，对等连接是将独立的网络互联以交换流量。对等连接的选项可以在虚拟网络面板的设置下找到。如果我们选择创建一个新的对等连接，需要提供一个名称，并选择是连接到资源管理器还是经典虚拟网络。由于推荐使用资源管理器，我们将在这里解释该过程。如果选择了资源管理器，我们可以提供一个资源 ID，或者使用下拉菜单选择我们的 Azure 订阅和要连接的虚拟网络。

如果需要，还可以提供一些额外的选项来转发流量和配置远程网关。以下截图展示了一个示例对等连接设置：

本地数据网关

在某些情况下，创建到 Azure 的 S2S 连接所需的所有要求未满足，但我们仍然需要连接到本地资源。例如，我们需要连接到本地数据库，但我们本地的 VPN 设备不支持与 Azure 的连接。

在这种情况下，我们可以使用本地数据网关，使 Azure 服务能够以安全的方式访问本地数据库。

本地数据网关充当桥梁，允许我们通过 Azure 服务访问本地数据。目前支持的服务包括 Power BI、Microsoft Flow、PowerApps、Azure 分析服务和 Azure Logic Apps。Logic Apps 也可以用来将数据传递到其他服务。

支持的连接器有：

BizTalk Server 2016
文件系统
IBM DB2
IBM Informix
IBM MQ
MySQL
Oracle Database
PostgreSQL
SAP 应用服务器
SAP Message Server
SharePoint Server
SQL Server
Teradata

设置本地数据网关是一个两步过程；我们需要先在本地安装代理，然后在 Azure 中配置网关。

本地安装

要开始安装过程，我们需要使用具有 Azure 订阅访问权限的账户进行登录。通常，要访问 Azure 订阅，您需要使用 Microsoft Live 账户或工作/学校/O365/AAD 账户。在此情况下，我们无法使用 Microsoft Live 账户，因为仅允许使用工作账户。登录表单如下所示：

在完成登录过程后，我们需要提供一个新的本地数据网关名称和一个恢复密钥（至少 8 个字符）。恢复密钥在您需要重启服务或更改其配置时使用：

部署完成后，您将看到一个状态页面和一些额外的配置。您可以更改服务设置、网络设置和连接器，或者如果遇到服务问题，可以启动诊断。为了再次访问这些设置，您需要使用恢复密钥：

云服务

本地服务器安装完成后，我们还需要在 Azure 中配置网关。我们需要提供的参数包括资源名称、订阅、资源组和位置。根据其他信息，可用的网关将可以在安装名称下选择：

部署完成后，我们可以使用本地数据网关将 Azure 与本地服务器连接。可以使用这种连接的服务数量有限，但我们可以使用逻辑应用扩展连接到其他服务。配置逻辑应用以使用本地数据网关，使我们能够在单个逻辑应用流程中扩展连接到其他服务，并访问相同的数据。连接虽然有限，但它能在 S2S 不是选项的某些场景下提供帮助。

Azure Stack

微软可能是唯一一个提供真正混合云选项的云服务商。大多数云服务商都提供某种形式的混合云，允许你将本地服务和云服务结合起来。在大多数情况下，通过 IaaS，我们可以轻松地将所有本地资源运行在云端，几乎不需要任何努力。将本地资源迁移到云端是每个云服务商都在提供的选项。

Azure Stack 是唯一一个允许你将云服务在本地数据中心运行的选项。使用 Azure Stack，你可以在自己的环境中运行 IaaS 甚至 PaaS。基本上，Azure Stack 是 Azure 在本地环境中的扩展，它使用与公有版 Azure 相同的架构，但规模要小得多。它以预配置的盒子形式提供，必须从授权供应商处购买，并使用与公有版 Azure 相同的“真实”架构。它支持与公有版 Azure 相同的模型和部署工具。在 Azure 中部署的所有应用和服务都可以在 Azure Stack 中运行，而在 Azure Stack 中部署的所有应用和服务也能在 Azure 中运行。该模型一次开发，随时可以部署到任何地方。

在一些场景中，Azure Stack 可能是一个值得考虑的选择。第一个场景是我们在讨论混合云选项时已经提到的：当我们有法规要求必须将数据保留在本地数据中心或本国境内时。即使是混合云，在这种情况下我们也必须使用 SQL Server。而使用 Azure Stack，这个问题就不存在了；我们可以使用 Azure SQL 数据库，并且即使将数据库保留在本地，也能享受 PaaS 的优势。

在处理大数据集时，延迟和连接性可能成为问题。Azure Stack 是一个解决方案，可以让我们在本地处理数据，然后将其聚合到 Azure 中进行进一步分析，同时在两者之间共享通用的应用逻辑。

另一个例子是那些断开连接或部分断开连接的系统，这些系统偶尔能连接到互联网。使用 Azure Stack，我们可以在飞机或船只等没有持续互联网连接的环境中提供云应用。航空公司可以为客户创建云应用，客户可以在飞机离线时访问该应用。一旦建立互联网连接，就可以进行数据同步，并更新所有内容。

在某些场景下，公司可能拥有多个位置，并且其中一些位置可能需要离线。在这种情况下，云应用程序之前无法作为选项，但通过 Azure Stack，即使在使用云的情况下，所有位置也可以使用相同的应用程序。有些位置可能使用公共 Azure 中的应用程序，而有些可能使用 Azure Stack，但它们具有相同的功能和能力。

Azure Stack 可能是微软合作伙伴的一个有趣选择，这些合作伙伴可能希望在他们的数据中心托管 Azure Stack，并在他们的国家提供 Azure 服务。如果公司或政府机构需要将数据保存在本国，托管服务提供商可以使用 Azure Stack 在该国为这些组织提供 Azure 服务。

架构、模型和部署工具不仅是 Azure 和 Azure Stack 共享的东西。Azure 门户也是两者非常相似的一项内容。Azure Stack 提供了两个版本的门户：用户版和管理版。用户版用于消耗和创建资源，类似于我们在公共 Azure 门户中看到的内容，之后用于配置配额和限制。门户的管理部分对于那些决定使用 Azure Stack 在本地托管 Azure 服务并将其提供给他人的人尤其重要，因为这将使他们能够控制每个客户的限制和支出。

您可以通过接下来的两个截图对比 Azure 和 Azure Stack 门户的设计，第一个是公共 Azure，第二个是Azure Stack。如您所见，设计非常相似，区别在于左上角的名称：

总结

如前所述，混合云已成为大多数组织的现实，无论是因为法规要求，还是投资于本地基础设施。我们已经讨论了如何迁移或将服务扩展到云，管理云中的身份是这一过程的一个非常重要部分。数据很重要，但管理谁可以访问这些数据同样重要。在将本地基础设施扩展到云时，我们可以设置域控制器的副本，并使用 Active Directory 来管理身份和委派访问权限，但这仅限于 IaaS。

要使用 PaaS 管理此项服务，我们必须使用 Azure Active Directory，通常称为身份即服务。在下一章中，我们将讨论 Azure Active Directory，如何使用它，甚至如何将本地身份扩展到 Azure Active Directory。

问题

混合云通常仅仅是一个选择，因为...
1. 法规
2. 投资
3. 两者
我们可以使用...连接本地网络和 Azure。
1. 站点到站点
2. ExpressRoute
3. 两者
为 S2S 所需的 Azure 资源...
1. 虚拟网络网关
2. 本地数据网关
3. 两者
本地网络网关包含...
1. 虚拟网络
2. 本地网络
3. 两者
VPN 设备配置可以从 Azure 门户下载。
1. 正确
2. 正确，但仅限少数设备
3. 错误
S2S 连接的推荐模式是...
1. 资源管理器
2. 经典版
3. 两者
为确保在混合云中可以使用本地身份，必须部署...
1. 灾难恢复中的域控制器
2. Azure 中的域控制器
3. 始终在线可用性组
本地数据网关可以与...
1. 所有 Azure 服务
2. 限量提供的 Azure 服务
3. 单一的 Azure 服务
Azure Stack 是...
1. 在本地数据中心扩展 Azure
2. Azure 中本地数据中心的扩展
3. 在另一个公共云中扩展 Azure
Azure Stack 提供...
1. IaaS
2. PaaS
3. 两者

第八章：Azure Active Directory - 云中的身份

我们已经在 Azure 中有了应用程序和数据，本地网络与 Azure 之间的连接也已建立。但是身份验证和授权怎么办？我们如何管理用户的权限和访问？所有这些问题的答案是 Azure Active Directory (AAD)，它允许我们设置基于云的身份认证，并且结合 Azure 基于角色的访问控制 (RBAC)，可以进行用户身份验证并允许他们访问特定资源。

本章将涵盖以下主题：

Azure Active Directory
将本地 AD 与 AAD 同步
在 AAD 中管理用户和应用程序

技术要求

本章需要以下内容：

一个 Azure 订阅
一台运行 Windows Server 2012 R2 或更高版本的本地服务器，已安装域控制器角色

Azure Active Directory

AAD 是一种基于云的目录和身份管理服务，提供应用访问管理和身份保护。它通常被称为 IaaS（基础设施即服务）。

我们已经提到过这个，但还是要再回顾一下。AAD 处于 Azure 管理链的最上层，并且直接与租户相关联。在租户下，我们可以拥有多个订阅，每个订阅下有多个资源组，每个资源组下有多个资源。

单个帐户可以访问多个租户，但每个租户都是隔离的。当用户登录时，会选择默认目录和租户。仅可访问该租户下订阅中的资源。若要管理其他租户中的资源，我们必须切换目录。

AAD 有四个版本：

Azure Active Directory 免费版
Azure Active Directory 基本版
Azure Active Directory Premium P1
Azure Active Directory Premium P2

Azure Active Directory 基本版提供基于云的应用访问和自助身份管理解决方案，包括基于组的访问管理、云应用的自助密码重置以及 AAD 应用代理。

高级版本提供了额外的功能和企业级管理工具，如动态组、自助组管理和 Microsoft 身份管理（P1），或身份保护和特权身份管理（P2）。Azure Active Directory Premium P2 包含所有 P1 的功能，并增加了身份保护和特权身份管理。

在这里，我们将重点关注由 Azure Active Directory 免费版提供的功能。免费版的目录对象数量限制为 500,000，支持的功能集较为有限，但允许进行用户/组管理、将本地目录同步到 Azure 以及基本的安全报告。它足以提供一般性的图像并介绍 AAD。涵盖所有 AAD 版本提供的功能可能会导致一本单独的书籍，且讨论 Azure 管理时会过于冗长。

创建新目录

即使 AAD 在 Azure 订阅存在的情况下可能已经存在，还是从创建一个新的 AAD（一个新的租户）开始吧。

要创建一个新目录，我们需要提供组织名称、初始域名和国家或地区。请注意，初始域名将用于创建一个初始域名，格式为yourdomain.onmicrosoft.com。域名必须是唯一的，之后可以为您的自定义域名进行自定义。以下截图显示了设置的示例：

创建一个新目录大约需要 1 分钟。新目录创建后，您需要切换目录才能进行管理。请注意，目录名称位于您的个人资料下方。要更改目录，请点击个人资料左侧的“目录”菜单，并从列表中选择目录；它将会打开，如下所示：

在切换目录后，您将进入一个新租户。如果您创建了一个新的目录，该租户将是空的，并且不会分配任何订阅。要开始创建 Azure 资源，您必须在此租户下创建一个新订阅。在空的租户中，您唯一可以管理的是 AAD。Azure Active Directory Free 的概览和管理选项如以下截图所示：

自定义您的域名

我们需要自定义的第一件事是域名。为了将自定义域添加到您的目录，您需要输入一个自定义域名，它实际上是您拥有的公共域名。例如，我将使用我的域名，azuresecurity.cloud：

在添加自定义域名后，需要验证该域名，或者更准确地说，需要验证域名的所有权。为了验证域名所有权，您需要在域名注册商中输入 TXT 或 MX 记录。TXT 记录的示例如下：

在输入记录并点击“验证”按钮后，您可能会收到错误。DNS 记录可能需要最多 72 小时才能传播更改。传播时间取决于您使用的 DNS，但通常不会超过 30 分钟。如果更改尚未传播，您将收到错误，如下图所示：

在变更传播并且验证通过后，您将收到一条消息，说明验证已通过。系统会提供两个额外选项——将此域设为主域，并下载 Azure AD Connect。我们现在忽略 Azure AD Connect，但我建议将自定义域设为主域。这样，自定义域将成为主域并成为首选域后缀。默认的用户名 username@yourdomain.onmicrosoft.com 将变成 username@yourdomain.com。如前面的示例所示，username@azuresecuritycloud.onmicrosoft.com 将变为 username@azuresecurity.cloud。下面是验证过的自定义域截图：

同步 AAD 与本地 AD

我们已经建立了一个新的目录，现在可以开始添加用户并为他们分配访问权限。但很可能我们已经在本地环境中有一个身份解决方案，并且用户已经有了一个身份。如果为用户提供额外的身份可能会导致问题和混淆。用户将遇到问题，无法确定何时使用哪个账户，如果创建了相同或相似的账户，用户会开始输入错误账户的密码……

幸运的是，通过 AAD，我们可以使用 Azure AD Connect，这将允许我们将账户从本地 AD 同步到 Azure，并让用户使用相同的账户进行一切操作。这将使每个人的工作变得更轻松；用户不必再考虑使用哪个账户（因为是同一个账户），管理员也会减少解决问题的数量（账户更少，用户因错误密码尝试而锁定账户的情况也减少）。

此外，通过 Azure AD Connect，我们可以实现单点登录（SSO），这样用户可以通过单次登录过程访问 Azure 和本地资源。用户只需输入一次凭据，相同的凭据就可以用来访问所有他们有权限访问的内容。

为了开始与本地 AD 同步，我们需要进入 Azure AD Connect 面板。在这里，我们可以查看当前的同步状态。如果同步尚未启用，您还会看到 Azure AD Connect 客户端的下载链接，正如您在这里所看到的：

安装 Azure AD Connect

Azure AD Connect 必须安装在本地环境中的一台服务器上。建议您使用一台没有域控制器角色但可以访问域控制器的服务器。安装 Azure AD Connect 的服务器必须能够连接互联网，因为它需要通过互联网同步本地 AD 和 AAD 之间的信息。所有通过 Azure AD Connect 传输的流量都是加密和安全的。

安装向导非常直观，并解释了每个步骤；您只需要按照指南操作（并理解本地 AD 结构）。以下截图展示了安装过程中的第一个屏幕，解释了工具将执行的操作：

您需要做出的第一个选择是是否使用快速设置或自定义设置。如果选择使用快速设置，所有功能都会预先确定。安装将使用默认的安装路径，安装 SQL Express，并使用默认的同步选项，如密码哈希同步、同步所有属性或跨 AD 林同步所有身份。

这里展示了 Azure AD Connect 快速设置的示例：

如果选择使用“自定义”选项，您可以设置一些功能，如安装路径、SQL Server 实例和同步组。例如，您可以使用现有的 SQL Server 实例，或选择只同步特定的用户组。另外，将为同步过程创建一个新的服务帐户，并使用快速设置；在自定义设置中，您可以选择使用现有的服务帐户。以下截图展示了自定义设置的示例：

选择设置后，您需要提供可以启用同步的帐户。首先，您需要提供具有全局管理权限的 AAD 凭据。建议为此创建一个单独的帐户，而不是将其与个人帐户绑定。如果管理员离职，该帐户很可能会被停用，导致同步停止。以下是输入 AAD 帐户的截图：

您需要提供的第二个帐户是 AD DS 企业管理员帐户。对于本地帐户和 Azure 帐户，情况相同：建议使用专门为此服务创建的服务帐户，而不是个人管理员帐户。输入 AD DS 帐户的截图如下所示：

最后，您将进入一个确认安装的屏幕。此屏幕将再次列出所有将要执行的操作，并允许您在配置完成后启用同步过程的启动。您可以在以下截图中看到确认屏幕：

安装完成后，系统会提供一个状态报告，并给出建议，告诉你还需要做些什么。例如，在我的域中，未启用 Active Directory 回收站。此过程将检测到这一设置，并建议你启用它，如下图所示：

在 Azure 门户中，在 Azure AD Connect 选项卡下，您将看到新的状态。Azure AD Connect 的链接消失了，您可以看到同步已启用，并且最后同步是不到 1 小时前。根据本地环境，您还可以配置联合身份验证、单点登录（SSO）和一些其他设置。以下截图展示了一个已同步目录的示例：

管理 AAD

同步完成后，所有同步的用户将出现在 AAD 中。在 AAD 中，帐户可以来自两个不同的来源：AAD 和 Windows 服务 AD。来自 Windows Server AD 来源的帐户是已从本地 Active Directory 同步的帐户。AAD 帐户仅存在于 AAD 中，这些帐户是在 Azure 中创建的。还有第三种类型的帐户，即 Microsoft 帐户。这些帐户实际上是 Microsoft Live 帐户，可以添加到您的 AAD 中。

AAD 中的用户类型可以是Member或Guest。成员是 AAD 中的帐户（带有您的域名），而访客是来自其他 AAD 或 Microsoft Live 帐户的帐户。唯一的例外是，当 Microsoft Live 帐户用于创建 AAD 时，该帐户可以是您的 AAD 成员。外部 AAD 帐户（来自您租户外部的 AAD 帐户）也是如此；这些帐户只能在用于创建新租户时具有成员身份。以下截图展示了一个成员列表的示例：

创建新用户

来自 AAD 来源的帐户是已在 Azure 中创建的帐户。我提到过，对于 Azure AD Connect，您应该使用服务帐户进行同步。请注意，该帐户必须具有全局管理员角色。以下是如何创建此类帐户的示例：

创建新 AAD 用户时，默认的用户角色是“用户”。在创建过程中或创建后，您可以将此选项更改为管理员。

管理用户选项和权限

创建用户后，您可以管理该用户并分配不同的角色和权限。除了管理选项外，您还可以在活动部分监视和审计用户的活动。以下截图展示了一个用户资料的示例：

最重要的管理选项之一是角色分配。在“目录角色”下，您可以选择可以分配给用户的多个预定义角色。每个角色都有相应的说明，如下所示：

用户可以被添加到组中以简化管理。例如，我们可以将多个角色分配给组，通过将用户分配给某个组，用户将自动获得该组中所有分配给该组的角色。组可以被分配并同步，类似于帐户。分配的组起源于 AAD，并通过 Windows Server AD 进行同步。以下是分配给 AAD 用户的组的示例：

在 AAD 中注册应用程序

为了使用 AAD 作为应用程序的认证方法，您需要在 AAD 中注册该应用程序。这将创建两个对象：一个应用程序对象和一个服务主体。

要注册一个新的应用程序，我们需要进入 AAD 面板中的应用程序注册，并选择“新建应用程序注册”。我们需要提供的信息包括应用程序名称、应用程序类型（Web 应用程序 / API 或本地应用）以及登录 URL（这里我使用本地主机作为示例）：

创建应用程序只是第一步，因为你还需要额外的配置才能使用这个注册。在应用程序创建后打开的第一个屏幕中，有两个非常重要的部分：应用程序 ID 和对象 ID。这些将在稍后用于通过 AAD 来识别应用程序。换句话说，应用程序使用 ID 来联系 AAD 并获取有关用户是否被授权访问该应用程序的信息。用于认证的 ID、应用程序或对象取决于认证方法。以下是一个示例：

为了为已注册的应用程序提供访问权限，我们需要配置权限和密钥。要为应用程序提供权限，我们必须在设置面板中的所需权限下设置所需的权限。在这里你需要非常小心，因为使用过多权限可能会让你陷入陷阱。

我常常看到人们给只需要基本认证的应用程序授予所有可能的权限。如果分配了太多权限，这可能会被利用，并且会带来很高的安全风险。以下截图展示了一个示例权限面板：

一旦我们拥有了 ID 和权限，最后缺少的是密钥。应用程序将使用 ID 和密钥来授权访问 AAD。要添加一个新的密钥，我们必须提供一个描述、过期时间（EXPIRES）和密钥的值（VALUE）。过期时间可以设为 1 年、2 年或永不过期。我强烈建议不要使用永不过期，因为这又是一个可能的安全风险。密钥的值并不是实际的密钥；该值将被加密，然后提供一个新的值。在输入所有值后，点击保存。以下是添加新密钥的示例：

保存后，将提供密钥的新值。确保复制此值，因为这是你唯一能获取它的时机。一旦离开这个控制面板，你将无法重新获取此值。以下截图显示了一个生成的密钥示例（请注意控制面板顶部的警告）：

使用在 AAD 中注册的 ID 和密钥的应用程序将能够与 AAD 进行通信。这些应用程序不必托管在 Azure 中；它们可以用于本地应用程序或其他云中的应用程序。

请注意，当使用 Azure Web 应用程序时，你可以通过在 Web 应用程序控制面板中使用身份验证/授权来实现类似的目标。这个选项会自动创建所有必要的对象，并为 Web 应用程序提供一个 ID 和密钥。会创建最小的权限，这是一件好事，但如果你需要为应用程序提供更多权限，则需要手动操作。

我们已经提到，在这个过程中将会创建两个对象：一个应用程序对象和一个服务主体。

现在是讨论多租户概念的好时机。多租户应用程序允许来自多个租户的用户使用相同的应用程序和资源。例如，我们可以为客户开发一个应用程序，并将其托管在我们的订阅中（以及我们的租户）。然后，我们可以为多个客户设置应用程序的访问权限，并允许他们使用自己的 AAD 进行身份验证和授权。在这个概念中，来自多个租户的用户使用相同的应用程序和相同的资源。如果使用多租户方法，应用程序将在主租户中拥有一个应用程序对象，并为每个目录提供多个服务主体。基本上，一个应用程序对象与应用程序之间是“一对一”的关系，与服务主体之间是“一对多”的关系。

基于角色的访问控制

我们已经提到过 RBAC 以及它如何帮助管理和维护云资源。RBAC 允许你使用 AAD 帐户在 Azure 租户的不同级别上设置不同的角色和权限。为了提供租户中的用户管理权限，我们必须使用 AAD 控制面板。这些权限不会被进一步传递。在租户下，我们可以有多个订阅，并且每个订阅的参与是单独进行的。

将用户分配为管理员（或其他角色）将自动为他们在该订阅下的所有资源组和资源提供相同的角色。如果我们在资源组级别为用户分配角色，该角色将自动为该资源组中的所有资源提供权限。将角色访问权限授予单个资源，将仅给予用户对该资源的访问权限。

在为这些级别（订阅、资源组、资源）分配权限的过程中，我们使用相同的选项：访问控制（IAM）。在这里，我们选择角色、分配类型和用户。您也可以使用组或服务主体代替用户。以下截图展示了如何将新贡献者添加到订阅/资源组/资源：

您可以选择多个预定义角色，创建自定义角色，或将用户分配到多个角色。如果用户被分配多个冲突的角色，将应用最高权限角色。

例如，Reader 角色只允许您查看资源的信息，不能进行任何更改。如果同时分配了 Reader 角色和 Contributor 角色（允许您进行更改），则将应用 Contributor 角色。

下面是可用角色的截图：

如前所述，组可以在任何级别分配角色。在这种情况下，所有属于该组的用户将自动被分配该角色。

服务主体通常用于为需要更改或创建某些内容的应用程序设置访问权限。例如，服务主体常用于允许 Azure DevOps 在发布过程中访问您的订阅，并创建或编辑部署所需的资源。

总结

AAD 提供 Azure 中的身份验证和授权。与 RBAC 一起，它允许您控制谁可以做什么以及在哪里做。这些工具是您管理和保护云资源时的第一道防线。

现在，我们将集中讨论在 Azure 中还需要保护哪些内容以及如何保护我们的数据和其他资源。保护 Azure 与保护我们本地基础设施不同，且需要不同的思维方式。在第九章 Azure 安全性与管理 中，我们将讨论如何加固 Azure 安全性以及有哪些可用的工具来保护我们。

问题

AAD 位于...
1. 租户
2. 订阅
3. 资源组
一个帐户可以属于多个租户：
1. 是的
2. 不是
AAD 可以包含 Microsoft Live 账户：
1. 是的
2. 不是
AAD 可以与 Windows Server AD 同步：
1. 是的
2. 不是
Azure Active Directory 免费版的限制为...
1. 5,000 个对象
2. 500,000 个对象
3. 5,000,000 个对象
要设置自定义域...
1. 您可以选择任何域
2. 您必须拥有该域
3. 您必须使用 .onmicrosoft.com
要验证您的自定义域，您必须使用...
1. MX 记录
2. TXT 记录
3. 任意
4. 两者
使用 RBAC，您可以为...分配角色
1. 订阅
2. 资源组
3. 一个资源
4. 上述所有内容
角色可以分配给...
1. 用户
2. 组
3. 两者
要从应用程序设置 AAD 登录，您必须...
1. 在 AAD 中注册应用程序
2. 为应用程序创建一个 AAD 组
3. 两者

第九章：Azure 安全性与管理

安全性常常是许多组织推迟迁移到云端的主要原因之一。原因在于存在太多未知因素；人们不理解安全性是如何设置的，且往往不信任任何人管理他们的数据。我常年听到的一句话是：“如果它离开了我们的数据中心，我就不知道它发生了什么。”

事实上，你的数据在 Azure 中可能比在本地数据中心更为安全。在本章中，我将尽力解释 Azure 安全性是如何设置的，并消除关于云安全的疑虑。

本章将涵盖以下主题：

Azure Active Directory 多重身份验证
Azure 网络安全
Azure 防火墙
数据加密
Azure 密钥保管库
Azure 安全中心
高级威胁防护
按需访问

技术要求

本章需要以下内容：

一个 Azure 订阅
PowerShell
Azure PowerShell

揭开云安全的面纱

那么，Azure 真的有多安全呢？我们可以从非常安全开始说起。

微软正在大力投资 Azure，特别是在 Azure 安全性方面。Azure 提供了广泛的合规性服务，包括 HIPAA、FFIEC、PCI DSS、ISO 9001 和 ISO 27001，仅举几例。

Azure 安全性始于物理安全。数据中心有专门的安全人员全天候值守；所有区域都被摄像头和报警系统覆盖，且有多个外围检查层级。

要进入 Azure 数据中心，你需要通过多个检查点并提供有效的身份验证和授权。身份验证采用多因素认证，除了提供 PIN 或密码外，你还必须通过生物识别和卡片读取器检查。

数据中心内的所有内容都经过加密和保护。所有数据在静态时都被加密，即便有人设法偷走了含有你数据的磁盘，它也是无法使用的。所有数据传输也都按照行业标准进行加密。

数据安全的另一个重要方面是冗余，以确保数据永远不会丢失。Azure 默认的冗余级别是 3（三个）。例如，当你创建一个新的资源，像是 Azure 虚拟机时，系统会创建一个有三个副本的磁盘。这保证了数据始终可用，即使其中一个磁盘发生故障，仍然有两个额外的副本。冗余 3 同样适用于备份发电机；如果一个发生故障，还有两个备份。

即使微软也深度参与了 Azure 安全性，但仅仅将数据放入 Azure 并不足以确保它的安全。与微软的合作负责安全的一部分，并提供各种工具和服务来帮助你保持安全。然而，如何实施这些工具并将它们投入使用，仍然由你负责。

保护你的身份

保护你的身份是 IT 安全中非常重要的一部分。大多数数据泄露是由于社会工程学或钓鱼攻击所致。因此，在大多数情况下，泄露的凭证是导致数据泄露的主要原因。

Azure Active Directory 提供了一些工具来提高安全性，其中最突出的一个是多重身份验证（MFA）。MFA 要求用户在登录后提供额外的安全身份验证。用户提供用户名和密码后，还需要进行额外的操作来证明身份。可以使用许多不同的工具进行附加检查，如生物识别读卡器或卡片读卡器，但最常用的工具是移动设备。登录后，用户会在移动设备上收到通知，并需要提供额外的确认。通知可以通过电话（用户需要在通话中提供代码）、短信（用户收到需要在登录时提供的代码）或应用程序（与用户账户连接，并需要确认用户正在尝试登录）进行。

启用 MFA 后，泄露的凭据不再那么令人担忧，因为窃取用户名和密码已不足以访问数据。需要访问用户的移动设备以授权你的登录尝试，这使得数据泄露变得更加困难。

启用多重身份验证

在 Azure Active Directory 中启用 MFA 非常简单和快速。在 Azure Active Directory 中，在用户管理下需要选择多重身份验证。截图中展示了一个示例：

一个新窗口会打开，在其中完成所有的 MFA 设置。你可以为单个用户设置个性化的设置，或者批量更新多个用户。在服务设置下，你还可以编辑 MFA 可用的选项，并选择电话、短信、移动应用或令牌。要启用单个用户的 MFA，选择该用户并在右侧的设置中点击启用，如下所示：

拥有全局管理员角色的用户可以免费使用 MFA。因此，对于管理员来说，没有理由不添加额外的安全层，因为泄露的管理员账户可能造成的损害远超过普通用户。然而，如果你想为所有用户启用 MFA，则需要额外的许可证。MFA 随 Azure Active Directory Premium 提供，但也可以按用户或每次登录为独立服务进行授权。

其他身份安全选项

Azure Active Directory 还提供其他可以帮助你增强安全性的服务。

其他服务如条件访问或特权身份管理可以帮助我们提高安全性并防止未经授权的访问。我们可以使用审计日志和风险性登录来查看谁尝试访问服务和数据以及何时访问。Azure Active Directory 提供了大量的日志，可以用于审计。大部分这些功能都需要 AAD Premium，并且在基础版或免费版许可证中不可用。

保护网络

保持安全的下一步是保护我们的网络资源。如果网络没有保护，可能会导致数据泄露或服务拒绝。即使 Azure 网络堆栈提供了许多安全功能，例如默认的 DDOS 保护或网络安全组，有时这些也不够，我们需要采取额外的措施。

Azure Firewall

Azure Firewall 是一个托管的、基于云的网络安全服务，保护 Azure 虚拟网络资源。它是一个作为服务提供的防火墙，内置高可用性和可扩展性。

使用 Azure Firewall，您可以创建、执行和记录应用程序及网络连接策略。为虚拟网络资源分配的静态公共 IP 地址可以让外部防火墙识别来自您的虚拟网络的流量。该服务与 Azure Monitor 集成，用于日志记录和分析。

准备环境

Azure Firewall 要求连接到一个名为 AzureFirewallSubnet 的子网。我们可以在创建新的 Azure Firewall 过程中创建一个新的 Azure VNet 和子网。但由于我已经有了想要使用的 VNet，我将向之前创建的PackVnet中添加一个新的子网。

以下截图展示了如何为 Azure Firewall 添加新子网的示例：

创建 Azure Firewall

要创建一个新的 Azure Firewall，我们需要提供订阅、资源组、名称和位置。此外，还需要提供虚拟网络和公共 IP 地址。在这两种情况下，我们可以选择使用现有资源或创建新资源。请注意，对于现有虚拟网络，必须存在AzureFirewallSubnet。示例参数如截图所示：

部署完成后，Azure Firewall 已准备好使用，我们可以开始配置。此时，请注意私有 IP 地址（记住它或写下来），因为我们将在接下来的几个步骤中使用它。

以下是 Azure Firewall 面板的截图：

我们也可以使用 ARM 模板来部署 Azure Firewall。

以下是部署新 Azure Firewall 的 ARM 模板：

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "type": "string"
        },
        "resourceGroup": {
           "type": "string"
        },
        "azureFirewallName": {
            "type": "string"
        },
        "vnetName": {
            "type": "string"
        },
        "vnetAddressSpace": {
            "type": "string"
        },
        "subnetAddressSpace": {
            "type": "string"
        },
        "publicIpAddressName": {
            "type": "string"
        },
        "subnetId": {
            "type": "string"
        }
    },
    "variables": {
        "networkApiVersion": "?api-version=2018-08-01"
    },
    "resources": [
        {
            "apiVersion": "2018-08-01",
            "type": "Microsoft.Network/publicIpAddresses",
            "name": "[parameters('publicIpAddressName')]",
            "location": "[parameters('location')]",
            "sku": {
                "name": "Standard"
            },
            "properties": {
                "publicIPAllocationMethod": "Static"
            },
            "tags": {}
        },
        {
            "apiVersion": "2018-07-01",
            "type": "Microsoft.Network/azureFirewalls",
            "name": "[parameters('azureFirewallName')]",
            "location": "[parameters('location')]",
            "dependsOn": [
                "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/publicIpAddresses', parameters('publicIpAddressName'))]"
            ],
            "properties": {
                "ipConfigurations": [
                    {
                        "name": "IpConf",
                        "properties": {
                            "subnet": {
                                "id": "[parameters('subnetId')]"
                            },
                            "publicIPAddress": {
                                "id": "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/publicIpAddresses', parameters('publicIpAddressName'))]"
                            }
                        }
                    }
                ]
            },
            "tags": {}
        }
    ]
}

Azure Route Table

现在我们要创建一个路由表，将所有流量通过 Azure Firewall。要创建一个新的 Azure 路由表，我们需要提供名称、订阅、资源组和位置。我们还可以选择启用或禁用 BGP 路由传播。以下截图展示了如何创建新的路由表：

在创建路由表后，我们需要将其与子网关联并创建路由。在路由表面板的子网选项下，选择“关联”，如图所示：

要将路由表与子网关联，我们需要提供虚拟网络和该网络中的子网。在以下示例中，选择了虚拟网络 PacktVnet，子网为默认子网：

最后，我们需要添加一条路由。我们需要提供路由名称、地址前缀、下一跳类型和下一跳地址。对于下一跳类型，我们需要选择虚拟设备。Azure 防火墙作为服务（Firewall as a Service），但仍属于这一类别。为了实现类似效果，我们可以使用任何虚拟设备，在其中使用 IaaS 模式的第三方防火墙。在下一跳地址下，我们输入 Azure 防火墙的私有 IP 地址（我之前提到过，您需要记住这个地址）。路由设置的示例如下所示：

来自PacktVnet虚拟网络默认子网的所有流量现在都被路由到我们的 Azure 防火墙。我们可以继续并创建规则，决定允许或拒绝的内容。

配置 Azure 防火墙

在 Azure 防火墙面板中的规则下，我们有三个选项：NAT 规则集合、网络规则集合和应用规则集合。根据我们的需求，可以使用 NAT 规则重写源地址。我们可以使用网络规则定义允许哪些源流量到达哪些目标，或者通过应用规则定义允许或拒绝的 FQDN。Azure 防火墙中规则面板的示例如下所示：

让我们创建一条规则，允许默认子网的流量访问 VSTS。首先，我们需要提供名称、优先级和动作（允许或拒绝）。然后，我们需要定义源地址、协议：端口和目标 FQDN。可选地，我们可以为规则添加标签。对于源地址，我将添加一个子网，因为我希望从子网中的任何地方都能访问 VSTS。如果您希望限制 FQDN 的访问来源，可以使用更小范围的 IP 地址。

协议将是 HTTP 和 HTTPS，目标 FQDN 为 *.visualstudio.com。新的应用规则示例如下所示：

请注意，您可以在一个集合中拥有多个规则，并且可以将适用于特定服务的所有规则创建在一个集合中。这使得管理和维护 Azure 防火墙规则变得更加容易。

如果一切配置正确，您可以进入位于默认子网中的虚拟机（VM），并打开任何浏览器。您应该能够访问任何 VSTS 集合，但其他任何内容都将被禁止访问。

其他网络安全选项

除了使用默认的 Azure 组件，如 NSG、路由表，甚至 Azure 防火墙之外，还有许多作为虚拟设备提供的第三方防火墙。虚拟设备作为 Azure 虚拟机（VM）设置，网络安全领域的大多数行业领导者都可以在 Azure 上使用。管理虚拟设备包括两个部分：管理 Azure 虚拟机和管理防火墙。我们已经讨论过如何管理 Azure 虚拟机，至于防火墙的管理则取决于制造商，和在本地管理这些防火墙没有什么不同。

除此之外，我们可以通过 Azure Monitor 和 Log Analytics 收集网络资源的日志，帮助我们审核和故障排除 Azure 网络。还有一个工具可以帮助我们监控 Azure 网络，它被称为 Network Watcher。Azure Network Watcher 提供了监控、诊断、查看指标并启用或禁用虚拟网络资源日志的工具。

使用 Azure Network Watcher，我们可以监控端点、网络流量、跳数、VPN 和其他一切与网络相关的内容。它是一个非常棒的工具，因为它允许我们以图形方式显示网络架构，并更轻松地定位问题。

加密

安全中的另一个重要步骤是加密。我们希望我们的数据始终保持加密——无论是在静态存储时还是在传输中。一切都具有冗余性，确保没有数据丢失，即使有三份加密的副本，我们也可以选择使用地理复制和其他设置来创建额外的冗余。

默认情况下，Azure 中的所有资源在静态存储时都会进行加密。但有时我们需要额外的安全性来确保数据得到更好的保护。例如，我们的 Azure 虚拟机磁盘在 Azure 数据中心内是加密的，即使磁盘未经授权访问，也没人能够读取磁盘上的数据。但如果磁盘被下载呢？在这种情况下，磁盘是可以被使用的。数据可以被读取或附加到另一个虚拟机，或者可以使用该磁盘创建一个虚拟机。

我们可以通过使用Azure Key Vault来应用额外的加密并使我们的资源更加安全。

Azure Key Vault

Azure Key Vault 用于存储机密、密钥和证书。它是一个集中式管理解决方案，用于保存、分发和控制机密、密钥和证书。在部署过程中可以调用 Azure Key Vault 中的机密，以防止密码以明文形式显示。密钥可以用来加密存储和磁盘。你可以在 Azure Key Vault 中使用证书，并在部署过程中将其分配给服务以保障 SSL 和 TLS 安全。

Azure Key Vault 大大减少了机密被意外泄露的可能性，通过使用密钥加密增加了资源静态存储时的安全性，并通过分配证书增加了传输过程中的安全性。

创建 Azure Key Vault

创建新的密钥库时，我们需要提供名称、订阅、资源组和位置。我们还可以选择更改定价层、分配访问策略，并提供虚拟网络访问。定价层有两个选项：标准和高级。唯一的区别是高级支持硬件安全模块（HSM）。默认分配的策略是授予创建密钥库的人员所有访问权限。您还可以在创建过程中或之后随时添加策略。虚拟网络访问默认授予您订阅中的所有网络，但您可以编辑此设置，只授予特定网络访问权限。这里显示了默认设置的示例：

创建 Azure 密钥库相对快速，应该在一分钟内完成。请注意 DNS 名称，因为稍后会用到它。以下截图显示了一个 Azure 密钥库页面的示例：

要部署 Azure 密钥库，您可以使用以下 ARM 模板：

{
    "$schema": "http://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "name": {
            "type": "String"
        },
        "location": {
            "type": "String"
        },
        "sku": {
            "defaultValue": "Standard",
            "allowedValues": [
                "Standard",
                "standard",
                "Premium",
                "premium"
            ],
            "type": "String",
            "metadata": {
                "description": "SKU for the vault"
            }
        },
        "accessPolicies": {
            "defaultValue": [],
            "type": "Array",
            "metadata": {
                "description": "The access policies defined for this vault."
            }
        },
        "tenant": {
            "type": "String"
        },
        "enabledForDeployment": {
            "type": "Bool"
        },
        "enabledForTemplateDeployment": {
            "type": "Bool"
        },
        "enabledForDiskEncryption": {
            "type": "Bool"
        },
        "networkAcls": {
            "type": "Object",
            "metadata": {
                "description": "The network firewall defined for this vault."
            }
        }
    },
    "resources": [
        {
            "type": "Microsoft.KeyVault/vaults",
            "name": "[parameters('name')]",
            "apiVersion": "2016-10-01",
            "location": "[parameters('location')]",
            "properties": {
                "enabledForDeployment": "[parameters('enabledForDeployment')]",
                "enabledForTemplateDeployment": "[parameters('enabledForTemplateDeployment')]",
                "enabledForDiskEncryption": "[parameters('enabledForDiskEncryption')]",
                "accessPolicies": "[parameters('accessPolicies')]",
                "tenantId": "[parameters('tenant')]",
                "sku": {
                    "name": "[parameters('sku')]",
                    "family": "A"
                },
                "networkAcls": "[parameters('networkAcls')]"
            }
        }
    ]
}

添加密钥和机密

密钥库创建完成后，我们可以添加机密和密钥。

首先，我们添加一个密钥，以便稍后用于加密。密钥可以生成、导入或从备份中恢复。如何添加新密钥的示例如下：

密钥库中的密钥可以用来提供创建资源时需要的密码。在使用 ARM 模板创建资源时，您需要提供密码。为了防止密码以明文显示，您可以使用密钥库中的机密提供密码的值，防止密码泄露。机密可以手动创建或从证书中导入。以下示例展示了如何手动添加新的机密：

与这两个示例类似，您可以添加证书。证书可以生成或导入。请注意，如果您想将这些证书用于公开的应用程序，必须使用由公认证机构颁发的有效证书。

加密存储账户

如前所述，大多数资源默认是加密的，Azure 存储账户也不例外。然而，您可以选择使用自己的密钥来加密存储。要使用自己的密钥，您必须选择“使用您自己的密钥”，这将允许您选择将用于加密的密钥库和密钥。以下截图显示了一个示例：

加密存储的时间取决于存储账户中的数据量。对于较小的存储，几秒钟就能完成，但对于大型存储账户，可能需要几个小时才能完成加密过程。如果您在生产环境中加密大型存储账户，请尽量在非工作时间进行，因为这可能会影响性能。

加密数据库

Azure SQL 数据库使用 TDE 进行加密。在创建新的 Azure SQL 数据库时，默认启用此选项。如果您有更早创建的数据库，可以将此选项更改为启用并保存。Azure SQL 数据库窗口中的透明数据库加密选项如下所示：

当 Azure SQL 数据库启用 TDE 时，数据和备份在静止状态下被加密。但如果您下载或导出备份，则情况会有所不同。为了确保数据库在离开 Azure 数据中心后仍然加密，我们可以使用自己的密钥进行加密。为此，我们需要使用 Azure PowerShell。

安装 Azure PowerShell

PowerShell 是基于 .NET Framework 的命令行外壳和脚本语言。系统管理员使用它来自动化任务和管理操作系统。

Azure PowerShell 是一个 PowerShell 模块，允许我们自动化和管理 Azure 资源。

要安装 Azure PowerShell，我们需要先安装 Windows PowerShell。幸运的是，Windows PowerShell 从 Windows 7（客户端操作系统）和 Windows Server 2012 R2（服务器操作系统）开始，微软的操作系统就已经预装了 Windows PowerShell。

要安装 Azure PowerShell，我们需要运行以下命令：

Install-Module -Name AzureRM

接下来，我们需要导入模块：

Import-Module AzureRM

如果模块已安装，我们可以使用以下命令更新它：

Update-Module -Name AzureRM

成功导入模块后，我们可以使用以下命令连接到 Azure：

Connect-AzureRmAccount

使用您自己的密钥进行 Azure SQL 数据库加密

要使用自己的密钥进行 Azure SQL 数据库 TDE，我们必须执行几个命令。

首先，我们需要将我们的 Azure Active Directory 身份登录到 Azure SQL 服务器：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$server = Set-AzureRmSqlServer -ResourceGroupName $dbRG -ServerName $dbServer -AssignIdentity

其次，我们必须授予服务器对 Key Vault 的权限：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$KeyVaultName = 'PacktKV';
Set-AzureRmKeyVaultAccessPolicy -VaultName $KeyVaultName -ObjectId $server.Identity.PrincipalId -PermissionsToKeys get, wrapKey, unwrapKey

第三，我们将 Key Vault 密钥添加到服务器并设置 TDE 保护级别：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$rgName = 'PacktKeyVault';
$KeyVaultName = 'PacktKV';
$keyEncryptionKeyName = 'MyKey';
$keyEncryptionKeyUrl = (Get-AzureKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;

<# Add the key from Key Vault to the server #>
Add-AzureRmSqlServerKeyVaultKey -ResourceGroupName $dbRG -ServerName $dbServer -KeyId $keyEncryptionKeyUrl
<# Set the key as the TDE protector for all resources under the server #>
Set-AzureRmSqlServerTransparentDataEncryptionProtector -ResourceGroupName $dbRG -ServerName $dbServer -Type AzureKeyVault -KeyId $keyEncryptionKeyUrl
<# To confirm that the TDE protector was configured as intended: #>
Get-AzureRmSqlServerTransparentDataEncryptionProtector -ResourceGroupName $dbRG -ServerName $dbServer

最后，我们启用 TDE：

$dbRG = 'PacktPaaSDB';
$dbServer = 'packt';
$dbName = 'Demo'
Set-AzureRMSqlDatabaseTransparentDataEncryption -ResourceGroupName $dbRG -ServerName $dbServer -DatabaseName $dbName -State "Enabled"

Azure PowerShell 脚本中的所有参数都可以编辑。要在任何 Azure SQL 数据库中使用任何 Key Vault 执行此操作，请相应地更改参数的名称。

加密虚拟机（VM）磁盘

同样的操作也适用于 Azure 虚拟机（VM）。磁盘默认加密，并且数据在静止状态下受到保护。但正如前面所提到的，当磁盘被导出或下载时，它将不再受到保护。通过使用 Key Vault，我们可以为 Azure VM 磁盘设置额外的加密保护，确保任何情况下的数据安全。如果我们查看任何 Azure VM 中的磁盘，我们会看到磁盘未加密，如下所示：

要启用磁盘加密，我们首先必须启用用于磁盘加密的 Key Vault：

Set-AzureRmKeyVaultAccessPolicy -VaultName 'PacktKV' -ResourceGroupName 'PacktKeyVault' -EnabledForDiskEncryption

现在我们可以启用磁盘加密：

$VMRG = 'PacktIaaS';
$VMname= 'DBserver';
$rgName = 'PacktKeyVault';
$KeyVaultName = 'PacktKV';
$KeyVault = Get-AzureRmKeyVault -VaultName $KeyVaultName -ResourceGroupName $rgname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;

 Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $VMRG -VMName $vmName -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId;

该命令将在 5 到 15 分钟内运行，具体时间取决于磁盘的大小。收到完成消息后，我们可以再次检查磁盘状态，查看加密是否已启用：

Azure 安全中心

Azure 安全中心提供了一个集中式的安全管理和高级威胁防护平台，涵盖 Azure 和混合云环境。通过安全中心，我们可以在工作负载中应用安全策略，限制对威胁的暴露，并检测和响应攻击。它分为两个层级：免费版和标准版。免费版默认启用，提供安全策略、持续的安全评估以及可操作的安全建议，以保护 Azure 资源。标准版扩展到私有或混合云工作负载，并增加了高级威胁检测。高级威胁检测使用内置的行为分析和机器学习技术来识别攻击和零日漏洞，减少暴露于任何类型的攻击。

Azure 安全中心概述

Azure 安全中心概览仪表板提供了您 Azure 和非 Azure 工作负载的安全状态的即时总结，使您能够发现并评估工作负载的安全性，识别和减轻风险。我们可以看到不同的指标，这些指标使我们能够立即识别任何安全风险，并根据最佳实践看到需要改进的推荐事项。Azure 安全中心中的概览仪表板示例如下图所示：

Azure 安全中心是一个功能复杂的服务，提供了很多选项。与许多其他服务一样，它值得一本专书，而很难在一个章节中涵盖所有选项。我们将专注于一些最重要的选项，这些选项将帮助您立即提升安全性。

Azure 安全中心推荐

Azure 安全中心分析您的安全设置并将其与最佳实践进行对比。基于此，您可以看到在安全中心 - 推荐中需要实施的建议变更。建议分为四类——计算与应用、数据与存储、网络、以及身份与访问（预览）。所有资源可以有三种状态：绿色、橙色和红色。绿色表示所有安全最佳实践已启用，并且资源是安全的；橙色表示应实施但不关键的建议；红色表示存在高安全风险的建议，应该立即实施。我们还可以看到基于已实施和待解决的内容，可能存在的安全风险的安全得分。安全中心 - 推荐仪表板如下图所示：

以“计算”部分为例。在这里，我们可以找到与计算资源（虚拟机和计算机、应用服务（预览）以及云服务）相关的所有安全问题列表。在这些推荐列表中，我们可以看到问题描述以及这些问题影响了多少资源。在此示例中，我们可以看到列表顶部列出，8 个虚拟机中有 10 个没有启用端点保护，并且被标记为红色：

启用端点保护

作为示例，让我们点击这个推荐并解决它。会打开一个新窗口，列出没有启用端点保护的虚拟机（VM）。我们可以选择特定的虚拟机或所有虚拟机，并选择安装端点保护。安装将开始，完成后我们会看到推荐已解决：

类似这样，我们可以解决大多数安全中心的推荐。我们点击推荐并按照步骤操作。然而，有些推荐无法通过这种方式解决，需要额外的步骤。在这种情况下，你将被引导到文档中，描述该问题并提供解决步骤。

Azure 安全中心警报

警报是 Azure 安全中心的另一部分；这些警报非常有用，可以帮助你检测潜在问题。安全警报部分可以让你追踪并查看何时有未授权访问你的资源的尝试。在 Azure 安全中心的警报概览中，你可以看到可能的资源攻击列表，并且能查看它们发生的时间，如下图所示：

如果我们选择任何警报，我们会看到更多信息，如日期、使用了什么凭证、登录尝试次数以及其他信息。在“地理和威胁情报信息”下，我们可以看到攻击发生的地点，提供了详细的地理位置信息。根据登录信息和地理位置，我们可以判断这是否是合法用户，还是对资源进行的暴力破解攻击。如果有一个有效用户在已知地点尝试了三次，我们可以推测这可能是用户忘记了密码。

如果我们有 50 次来自未知用户的登录尝试，且来自未知地点，我们可以推测这是一次暴力破解攻击。在“修复步骤”下，我们会有如何防止未来类似攻击的说明。这里展示了一个可疑的认证活动示例：

在底部，我们有两个附加操作——“调查”（Investigate）和“查看操作手册”（View playbooks）。调查允许我们查看事件的详细信息。查看操作手册允许我们创建（或使用现有的）逻辑应用程序，如果将来发生类似事件，它将采取相应措施。通过逻辑应用程序，我们可以设计步骤和操作来防止攻击。例如，如果尝试使用无效用户登录超过三次，它将添加一个 NSG 规则，阻止访问资源 48 小时。调查详情的示例如下所示：

即时访问

Azure 安全中心的最佳功能之一就是即时访问。即时访问可以防止访问 Azure 虚拟机，除非该访问已被特别请求。默认情况下，所有管理端口都被关闭，您需要从特定的 IP 地址请求访问，并且仅在短时间内启用此访问。

要在 Azure 虚拟机上设置即时访问，请进入安全中心的即时访问面板并从列表中选择一个或多个虚拟机，如下所示：

在选择要启用即时访问的虚拟机后，将会打开一个新面板。在这里，我们必须定义默认关闭且仅在请求时启用的端口。默认端口包括 SSH（22）、RDP（3389）和 WinRM（5985和5986），但您可以删除和添加任何您需要的端口。以下截图显示了默认设置的示例：

启用即时访问后，连接虚拟机的选项将不可用。要访问虚拟机，您必须在 Azure 安全中心请求访问。在这里，您需要定义要打开的端口、允许从哪些 IP 地址连接以及允许连接的时长（1 到 3 小时）。以下是请求面板的示例，您可以看到如何从当前 IP 地址打开 RDP 端口一小时：

通过即时访问（Just-in-Time access），您可以控制谁可以访问您的虚拟机（VM）、何时访问以及从哪里访问。未经授权的访问降到最低，您的虚拟机得到了保护。另一个令人惊叹的功能是，在标准层的 Azure 安全中心中，您可以注册并保护私有和混合云中的资源。此选项不仅仅限于 Azure 虚拟机，还可以为本地虚拟机启用。

总结

微软非常重视 Azure 安全。采取了许多步骤来确保您的资源在 Azure 中得到保护和安全。除此之外，微软还提供了许多额外的服务，帮助我们进一步提高安全性。为了确保安全并实现最大化保护，需要微软和我们的共同努力，我们需要利用 Azure 提供的安全服务，除了微软已经在保护我们的数据和服务之外。此外，除了被声明为安全服务的安全功能（例如密钥保管库或安全中心），还有很多服务内置的安全功能（例如 Azure SQL 防火墙或网络安全组）。

随着我们逐渐接近尾声，我们将回顾我们所学的内容。在最后一章，我们将讨论我们之前讨论过的服务以及使用它们的最佳实践。基础设施即代码（Infrastructure-as-Code）是云计算中非常重要的一部分，我们将讨论一些工具，这些工具可以通过自动化任务帮助我们与 Azure 进行工作。使用 Azure 门户是了解 Azure 的一个很好的方式，但如果你想充分利用它，基础设施即代码是你需要使用的工具。

问题

Azure 中的一切都是冗余的，拥有多少份副本？
1. 一
2. 两个
3. 三个
大多数数据泄露是由...引起的
1. 暴力破解攻击
2. 泄露的凭证
3. 病毒
MFA 代表...
1. 多因素认证
2. 多因素授权
3. 多因素激活
多因素认证（MFA）可以配置为使用：
1. 电话呼叫
2. 短信
3. 移动应用程序
4. 以上所有
Azure 防火墙是...
1. 基础设施即服务
2. 防火墙即服务
3. 两者
Azure 资源可以使用...进行加密
1. Azure 提供的密钥
2. 自定义密钥
3. 两者
要使用自定义密钥，我们必须使用...
1. Azure 安全中心
2. Azure 密钥保管库
3. 两者
Azure 安全中心提供...
1. 安全管理
2. 高级威胁防护
3. 两者
Azure 安全中心可以用于保护...
1. Azure 资源
2. 本地资源
3. 两者
即时访问提供...
1. 我们对虚拟机（VM）管理访问的控制
2. 实时监控虚拟机的访问
3. 两者

第十章：最佳实践

在这最后一章中，我们将回顾到目前为止所学到的内容，并强调一些最佳实践。一些简单的技巧可以帮助您从一开始就正确设置，并为以后节省大量麻烦。最佳实践将帮助您在管理和故障排除中更好地跟踪事物并注意到错误。我们将添加一些安全提示以及如何避免最常见的错误。我们将使用基础设施即代码（IaC）作为工具，帮助我们在 Azure 中的日常任务中取得成功。使用 Azure 门户简单且有助于学习，但要充分利用 Azure，我们必须使用 ARM 模板、Azure PowerShell 或 Azure CLI。最后，为了扩展 IaC，我们将讨论配置即代码，并介绍期望状态配置（DSC）和 Azure 自动化。

本章将涵盖以下主题：

Azure 最佳实践
基础设施即代码
ARM 模板
Azure PowerShell
Azure CLI
配置即代码
期望状态配置
Azure 自动化

技术要求

对于本章，您将需要以下内容：

Azure 订阅
PowerShell
Azure PowerShell
Azure CLI

Azure 最佳实践

有许多细小的事项需要注意，否则可能会在长期内出现问题。当您管理单个订阅和少量资源时，可能看起来很简单，不重要去创建一些基本规则。但随着订阅和资源数量的增加，您可能会遇到混乱，此时纠正错误可能为时已晚。在这些情况下，纠正错误和回到正确的轨道将会很困难。

命名约定

对于订阅、资源组和资源设置命名约定非常重要。您的第一个订阅可能会有类似Pay-as-you-go的名称。如果您只有一个订阅，这并不重要。但如果您最终拥有 5 个、10 个或 100 个订阅，并且它们都命名为Pay-as-you-go，情况将会变得混乱。这些订阅将具有不同的订阅 ID，您可以利用此信息对它们进行区分，但这可能会很困惑。订阅可以重新命名，您应该利用此选项。您可以以不同的方式组织订阅，具体取决于您的需求，如基于部门、应用程序、环境等等。

例如，您可以每个部门拥有多个订阅。这将帮助您分离成本和消耗，并查看每个部门在资源上的支出情况。在这种情况下，您可能希望将订阅重命名为类似HumanResources、Finances、IT等。如果每个部门都有不同的生产、测试和开发环境，您可以在订阅名称中添加环境，并类似于HumanResources-prod、HumanResources-test和HumanResources-dev。

你可以根据需求将类似的原则应用于资源组的命名。假设我们使用一个单一的订阅，并希望将部门、环境或应用程序添加到资源组的名称中。在这种情况下，资源组的名称可能是IT-helpdesk-prod。或者，如果我们为每个部门分配一个订阅，资源组的名称可能是helpdesk-prod。

但是，当你有多个订阅，并且所有订阅都列在资源组视图中时，如果一些资源有相似的名称，可能会造成混淆，因此最好在资源组名称中包含订阅名称。例如，你可能有Finance和HR两个订阅，它们各自都有一个名为Employees的应用程序。如果你只是使用产品和环境来命名资源组，那么这两个生产环境的资源组将会被命名为Employees-prod。它们虽然在不同的订阅中，但当所有订阅中的资源组列出时，可能会造成混乱。在这种情况下，将完整路径包含在资源组名称中，将订阅名称作为资源组名称的前缀，是一个有益的做法。

对于资源，最好也有一定的命名规范。设计可能依赖于不同的因素，但我建议使用所有可用的变量，以避免混淆。例如，假设我们的 IT 部门有自己的订阅，并使用一个名为helpdesk的应用程序。该应用程序需要两个虚拟机（Web 和数据库服务器），并且有生产、开发和测试环境。在这种情况下，我们会有六个虚拟机被同一个应用程序使用，用于不同的目的和环境。在这种情况下，使用诸如订阅、环境、产品、资源类型和资源用途等参数会很有帮助。因此，生产环境中的虚拟机名称可能是it-helpdesk-prod-VM-web和it-helpdesk-prod-VM-db。还有一种情况是你有多个虚拟机具有相同的角色，比如负载均衡器后面的多个 Web 服务器。在这种情况下，最好在名称中添加数字，像这样it-helpdesk-prod-VM-web-01、it-helpdesk-prod-VM-web-02，依此类推。

公共端点

通常，如果没有必要，避免暴露公共端点是一个好主意，尤其是当我们谈论管理和行政时。暴露你的 Web 应用的端点是你可能希望做的事情，但为什么要暴露数据库呢？这只会带来额外的安全风险，并增加你的数据被泄露的可能性。管理方面也是如此；应该避免暴露 RDP、SSH 或任何其他可以用来管理和行政资源的端口。

如果我们使用 IaaS 中的数据库，最佳实践是只允许通过端口 1433 在 Azure Vnet 内访问数据库，或者甚至限制访问到特定的子网。使用 NSG 和 应用程序安全组（ASG）来设置访问权限，并仅在需要时允许访问。例如，我们可以使用 NSG 和 ASG 设置对数据库的访问，但仅当流量来自特定子网（使用 NSG）并且来自属于 Web 服务器组的服务器时（使用 ASG）。这一方法不限于端口 1433 和 MS SQL Server；您可以将这种方法应用于 IaaS 中使用的任何其他数据库以及这些数据库使用的任何端口，如 Oracle 的 1521、IBM DB2 的 50000、MySQL 的 3306，或任何您定义的自定义端口。

PaaS 中的数据库、Azure SQL 数据库以及其他数据库 PaaS 选项提供了防火墙保护。通过防火墙保护，您可以限制能够连接到数据库的 IP 地址。请确保保持防火墙的更新，并移除任何不必要的 IP 地址。此外，Azure SQL 数据库防火墙中有一个选项可能会带来额外的风险。该选项允许 Azure 服务访问您的 Azure SQL 数据库，如下所示：

默认情况下，此选项是开启的，看起来似乎启用它是有道理的。大多数人会认为：“是的，我希望我的 Azure 服务能够连接到我的数据库。”但这个选项只检查连接是否来自 Azure；它并没有检查连接是否来自您的订阅或租户。如果保持此选项开启，就允许任何人创建一个 Azure 账户并尝试访问您的数据库，因为如果连接来自 Azure，则防火墙规则将不再适用。

连接到数据库仍然需要用户名和密码，但这为攻击者提供了机会。在这种情况下，微软要求在创建试用订阅时提供信用卡信息，这对于我们来说是非常有利的，因为任何账户都可以追踪到其所有者。如果有人通过这种方式成功访问数据库，那么该人是可以被追踪的，但您可能想要禁用此选项，以防止任何未经授权的访问。

对于其他不应公开暴露的后端服务，也可以采用类似的方法。这些服务可以是数据库、不同的连接器、业务逻辑以及各种 API 等。不要暴露任何不需要暴露的内容。在 IaaS 场景中，可以使用 NSG 和 ASG 来限制访问。当使用 PaaS 时，也有不同的策略可以采用。如我们之前提到过，Azure SQL 数据库具有防火墙。对于 Web 应用程序，我们可以使用隔离的应用服务计划，只允许通过 Azure 虚拟网络访问。类似地，大多数 PaaS 服务都可以连接到 Azure VNet，并且我们可以设置从 Azure 虚拟网络内部访问服务。然后，NSG 和 ASG 规则也可以应用于这些服务。

限制对 Azure 虚拟机管理端口的访问是我们需要注意的另一个事项。例如，公开 RDP 访问到虚拟机的互联网可能会带来严重后果。我测试了将默认的 RDP 端口开放，并通过 Azure 安全中心跟踪访问尝试。在一个月内，有超过 150,000 次未授权的访问尝试。这些尝试大部分使用的是管理员、admin、sysadmin 和 root（超过 80%的尝试使用了这四个用户名），所以幸运的是 Azure 虚拟机不允许使用这些名字。

有几种方法可以限制对 Azure 虚拟机管理的访问：

禁用管理端口的公共访问，并通过安全连接管理 Azure 虚拟机。这可以是 P2S、S2S 或 Azure ExpressRoute。通过使用安全连接，您将管理访问限制为来自可信位置的授权用户。
如果无法使用安全连接，限制对可信公共 IP 地址的访问。使用 NSG 来限制对仅能通过预先允许的 IP 地址访问的 Azure 虚拟机的访问。以下截图展示了如何使用 NSG 限制访问的示例：

使用即时访问（Just in Time Access）来访问 Azure 虚拟机。在 Azure 中设置即时访问简单快捷。启用此选项时，您需要创建一个来自预定 IP 地址并且只限于一段时间的访问请求。这样，除非创建了特定的请求来允许管理访问，否则访问将被阻止。以下是一个示例，展示了如何为用户当前的 IP 地址开放 RDP 端口一个小时的请求：

其他需要考虑的事项

除了命名标准或端点安全性，我们还需要注意很多细节：

尽可能使用 PaaS。Microsoft Azure 提供了多种选择，但 IaaS 通常会更昂贵。在某些情况下，您别无选择，但使用 PaaS 可以降低订阅成本。
使用监控和日志记录服务。每个 Azure 服务都有某种形式的日志记录、监控和警报功能。尝试通过 Azure Monitor、Azure Network Watcher 或 Log Analytics 等服务扩展这些功能。这些工具可以帮助你跟踪问题和性能变化。
使用 Azure Advisor 应用一些最佳实践。Azure Advisor 会分析订阅中的资源，比较设置与最佳实践，并提供需要实施的建议，以提高性能或降低成本。
类似于 Azure Advisor，Azure Security Center 提供增强资源安全性的建议。Security Center 会比较你当前的安全设置，并结合安全事件，生成增加安全性的建议。
加密数据。尽管大多数 Azure 服务默认启用了加密，但那是静态加密。为了在导出或备份后保护我们的数据，我们需要应用额外的加密。
加密连接并使用 HTTPS。如果数据在传输过程中暴露，那么安全性就没有意义，因此我们也需要考虑这一点。
如果遇到问题，检查 Azure 服务健康状态。这可以节省你数小时的故障排除时间。你将能够发现性能问题，或者查看某个服务是否不可用，并自动连接到 Azure 查看出什么问题。这可能是 Azure 在全球或数据中心级别的问题，作为第一步检查是否是这种情况，可以节省大量时间。
在可能的情况下配置自动扩展。Azure 提供的一个优势是你只需为实际使用的资源付费。如果正确设置，自动扩展可以在负载增加时增加实例的规模/数量，而在负载减少时减少规模。这可以随着时间的推移节省大量费用。
尽可能使用 Azure Active Directory 认证。大多数服务可以设置为使用不同的认证方式，或者仅为特定服务创建本地账户。这种方式很难审计或跟踪访问情况。使用 AAD 账户可以提供更多的洞察，并使跟踪变得更加容易。
启用服务的审计功能。一些服务，例如 Azure SQL，内置了审计功能。在可能的情况下启用此功能，或者使用 Log Analytics 记录所有内容。
尽可能设计为具有韧性。拥有冗余服务可能会花费大量资金，在某些情况下甚至会使我们的成本翻倍。然而，将冗余服务部署在另一个 Azure 数据中心可以提高服务的可用性。如果服务出现问题，不论是你的服务问题还是 Azure 数据中心级别的问题，你都可以切换到冗余副本。
始终为故障做好规划。这不仅仅是 Azure 或云相关的最佳实践——为故障做规划是 IT 的最佳实践。尝试预测不同的场景以及如果服务失败会发生什么。然后，尽量修复可能的问题并防止故障发生。
尝试启用多因素认证。由于这可能增加成本，因此并非总是可行，预算也可能会阻止你实现这一目标。在这种情况下，至少为管理员启用 MFA；管理员的 MFA 是免费的。
在 Azure 虚拟机上安装端点保护。端点保护将提供实时保护，防止恶意或不需要的软件被安装，并可能对你的系统造成损害。
安装 Azure 虚拟机的最新补丁。定期安装补丁有双重效果：安全补丁能提高安全性，其他更新可以提高性能。
定期分析性能。仅仅拥有自动扩展有时并不足够。尽量在可能的情况下手动监控资源的性能。你可以发现性能问题，或者看到某些服务没有被充分利用。你可以使你的服务表现得更好，并节省成本。

基础设施即代码

基础设施即代码（IaC）是 Azure 最佳实践中的一个非常重要的部分。使用 Azure 门户简单且非常适合创建单一资源并学习，但如果我们要创建复杂的环境，IaC 是我们想要使用的工具。例如，创建一个 Azure 虚拟机时，Azure 门户是一个不错的选择。只需 3-5 分钟即可完成新的虚拟机向导并完成所有步骤。但如果我们每天都需要创建新的虚拟机，或者创建数十个甚至数百个虚拟机呢？在这种情况下，我们可能希望使用某种自动化来简化工作，这正是 IaC 的作用所在。为了在 Azure 上工作，我们有几种可用的选项：

ARM 模板
Azure PowerShell
Azure CLI

我们已经提到过 ARM 模板。ARM 模板是存储 Azure 资源信息的 JSON 文件，可以用于部署（或编辑/更新现有资源）。

要回答 Azure PowerShell 是什么，我们首先需要回答 PowerShell 是什么。PowerShell 是一种基于 .NET 框架的任务驱动型命令行脚本语言。它用于自动化任务并通过命令行管理操作系统和进程。Azure PowerShell 是一个 PowerShell 模块，提供了一组 cmdlet（命令），允许我们管理 Azure 资源。

Azure CLI，或称 Azure 命令行界面 (CLI)，是微软的跨平台命令行工具，用于管理 Azure 资源。它支持 macOS、Linux 和 Windows，并且无论选择哪个平台，都能提供相同的体验。Azure CLI 1.0 的第一个版本也叫做 X-Plat CLI，是用 JavaScript 编写的。最初，它是为了支持 Azure 服务管理 API 而创建的，后来才添加了 Azure 资源管理支持。Azure CLI 2.0 从一开始就为 ARM 架构而构建，并且是用 Python 编写的。

安装工具

在本节中，我们将讨论各种工具，通过这些工具你可以开始不同的安装过程。

ARM 模板

ARM 模板实际上不需要任何特殊要求，但您可以使用各种工具来帮助管理它们。由于它们是 JSON 文件，您可以使用任何文本编辑器创建一个，但使用集成开发环境（IDE）会更方便。我的推荐是使用 Visual Studio 或 Visual Studio Code。通过使用 Visual Studio 或 Visual Studio Code，您可以连接到代码库并设置版本控制，从而跟踪模板随时间的变化。然而，我们也可以使用 ARM 模板进行部署，通过调用 API 或直接从 Azure 门户进行，无需任何额外的工具。

Azure PowerShell

要安装 Azure PowerShell，首先需要安装 Windows PowerShell。幸运的是，在客户端操作系统中，Windows 7 及更高版本已经预装了该工具，服务器操作系统则在 Windows Server 2008 R2 及更高版本中预装。因此，我们缺少的只是 Azure PowerShell 模块。要安装该模块，我们需要运行 PowerShell 并执行以下命令：

Install-Module -Name AzureRM

您将收到一条消息，要求您从PSGallery安装模块，选择“是”或“全部是”。安装模块后，我们需要使用以下命令导入它：

Import-Module AzureRM

最后，我们可以使用以下命令登录：

Connect-AzureRmAccount

这将打开一个窗口，您需要在其中输入凭据并授权访问我们的订阅。

由于 Azure PowerShell 每三周发布一个新版本，您需要保持它的更新。要安装最新版本，我们需要运行以下命令：

Update-Module -Name AzureRM

Azure CLI

安装 Azure CLI 取决于我们使用的平台。

对于 Windows，我们需要从aka.ms/installazurecliwindows下载安装程序，并像这样运行安装程序：

要在 macOS 上安装，我们需要运行以下命令：

brew update && brew install azure-cli

在 Linux 上的安装依赖于发行版。例如，在使用yum的发行版（如 RHEL 或 CentOS）上，我们需要运行三条命令。

首先，我们导入 Microsoft 仓库密钥：

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

其次，我们创建仓库信息：

sudo sh -c 'echo -e "[azure-cli]\nname=Azure CLI\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/azure-cli.repo'

最后，我们运行安装：

sudo yum install azure-cli

安装过程可能会依赖于平台，但完成安装过程后，在所有平台上运行 Azure CLI 命令是相同的。要使用 Azure CLI 登录 Azure，我们需要运行以下命令：

az login

这将显示一条消息（如下所示），并打开一个新的浏览器会话，您需要授权访问 Azure：

所有 Azure CLI 的命令都以az开头。要获取更多信息，可以运行以下命令：

az --help

您将看到以下输出：

您可以将--help与列表中的任何命令结合使用，以获取有关特定命令的更多信息。

使用基础设施即代码（IaC）创建 Azure 资源

为了更好地理解 ARM 模板、Azure PowerShell 和 Azure CLI 如何工作，我们来看一个简单的例子，并使用每个工具创建一个 Azure Web 应用。

使用 ARM 模板创建 Azure Web 应用

使用 ARM 模板，我们需要两个 JSON 文件。第一个文件定义了需要创建的内容，第二个文件包含在部署过程中定义的参数。因此，基本上，第一个文件包含了需要创建的内容（在我们的示例中是应用服务计划和 Web 应用），而第二个文件包含了服务的部署位置、大小、名称等信息。

这是模板文件：

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"webAppName": {
"type": "string",
"metadata": {
"description": "Base name of the resource such as web app name and app service plan "
},
"minLength": 2
},
"sku":{
"type": "string",
"defaultValue" : "S1",
"metadata": {
"description": "The SKU of App Service Plan, by defaut is standard S1"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"webAppPortalName": "[concat(parameters('webAppName'))]",
"appServicePlanName": "[concat( parameters('webAppName'),'-AppServicePlan')]"
},
"resources": [
{
"apiVersion": "2017-08-01",
"type": "Microsoft.Web/serverfarms",
"kind": "app",
"name": "[variables('appServicePlanName')]",
"location": "[parameters('location')]",
"comments": "This app service plan is used for the web app and slots.",
"properties": {},
"dependsOn": [],
"sku": {
"name": "[parameters('sku')]"
}
},
{
"apiVersion": "2016-08-01",
"type": "Microsoft.Web/sites",
"kind": "app",
"name": "[variables('webAppPortalName')]",
"location": "[parameters('location')]",
"comments": "This is the web app, also the default 'nameless' slot.",
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
]
}
]
}

这是参数文件：

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"webAppName": {
"value": "packt-demo-arm-webapp-01"
},
"sku": {
"value": "S1"
},
"location": {
"value": "[resourceGroup().location]"
}
}
}

保存这两个文件。现在，让我们创建一个资源组来进行部署。创建一个名为 packt-demo-arm 的新空资源组。打开模板部署并选择自定义模板。在编辑模板下，加载模板文件，在编辑参数下，加载参数文件。选择订阅和资源组 packt-demo-arm（如果您之前没有创建，您可以在此处创建）。所有其他字段应自动从参数文件加载，如此示例所示（记得接受条款和条件）：

部署完成后，您应该能找到应用服务计划和 Web 应用，如下图所示：

我们可以使用相同的 ARM 模板来部署新的 Web 应用，只需更改参数文件中的资源名称或层级；我们不需要在每次部署时都通过 Azure 门户的部署向导。这可以节省大量时间，特别是当我们需要部署多个 Web 应用时。

使用 Azure PowerShell 创建 Azure Web 应用

要使用 Azure PowerShell 创建相同的资源，我们需要执行一个脚本，该脚本将创建资源组、应用服务计划和 Web 应用。脚本以参数开始，然后执行三个 cmdlets 来创建我们所需的所有部署内容。请确保您已经连接到 Azure 的 Azure PowerShell：

$ResourceGroupName = "packt-demo-ps"
$webappname="packt-demo-ps-webapp-01"
$location="West Europe"
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $location
New-AzureRmAppServicePlan -Name $webappname -Location $location -ResourceGroupName $ResourceGroupName -Tier Free
New-AzureRmWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName $ResourceGroupName

执行脚本后，您应该会收到以下输出：

如果我们进入 Azure 门户，我们应该能找到一个新的资源组及其中的新项目：

要启动新的部署，我们只需更改参数值并再次执行。我们可以通过仅更改 Web 应用的名称并在同一资源组中部署站点来快速部署多个网站。例如，如果我需要在同一资源组中部署四个相同网站的实例，我可以仅更改 $webappname 的值，并将末尾的数字更改为 packt-demo-ps-webapp-01、packt-demo-ps-webapp-02、packt-demo-ps-webapp-03 和 packt-demo-ps-webapp-04。这样，我就可以通过修改一个值来运行脚本，而不需要每次都经过 Azure 门户的向导。

要清理部署，您可以执行一个命令，删除资源组及其中所有资源：

$ResourceGroupName = "packt-demo-ps"

Remove-AzureRmResourceGroup -Name $ResourceGroupName -Force

您应该会收到如下输出，并可以在 Azure 门户中验证资源组是否已经不存在：

使用 Azure CLI 创建 Azure Web 应用程序

现在，让我们使用 Azure CLI 重复相同的过程。您可以看到 Azure CLI 脚本结构与 Azure PowerShell 非常相似：

$webappname='packt-demo-cli-webapp-01'
$ResourceGroupName ='packt-demo-cli'
az group create --location westeurope --name $ResourceGroupName
az appservice plan create --name $webappname --resource-group $ResourceGroupName --sku Free
az webapp create --name $webappname --resource-group $ResourceGroupName --plan $webappname

执行脚本后，您应该会收到一个以此结尾的长输出：

如果我们转到 Azure 门户，应该会找到新的资源组及其中的新项：

与 Azure PowerShell 类似，要重新部署，只需编辑参数值。要清理部署，您可以执行一个命令，该命令将删除资源组以及资源组中的所有资源：

$ResourceGroupName ='packt-demo-cli'
az group delete --name $ResourceGroupName

您应该收到命令完成的输出消息，并在 Azure Portal 中验证资源组不再存在。

部署多个资源

每种部署方法都可以用来在单个脚本中部署多个资源。我个人最喜欢的工具肯定是 Azure PowerShell，但这可能是因为我的系统工程背景。多年来，我一直在使用 Windows PowerShell，并发现 Azure PowerShell 最易于使用。这并不意味着 ARM 模板或 Azure CLI 比 Azure PowerShell 落后，我认为开发人员会觉得这些其他工具更为熟悉。

例如，为了尽可能简单地部署多个资源，我将创建一个 Azure PowerShell 脚本，该脚本将在单次运行中部署多个网站。您也可以使用其他工具做类似的事情：

$ResourceGroupName = "packt-demo-ps-multiple"
$webappname="packt-demo-ps-webapp"
$location="West Europe"
$NumberOfWebApps= 4

New-AzureRmResourceGroup -Name $ResourceGroupName -Location $locationNew-AzureRmAppServicePlan -Name $webappname -Location $location -ResourceGroupName $ResourceGroupName -Tier Standard

$i=1

Do

{

New-AzureRmWebApp -Name $webappname'-0'$i -Location $location -AppServicePlan $webappname -ResourceGroupName $ResourceGroupName

} While (($i=$I+1) -le $NumberOfWebApps)

在上述输出中，您将收到每个创建的资源的消息，并且可以在 Azure 门户中验证部署。如果脚本执行成功，您应该能看到所有资源，如下所示：

要清理部署，您可以使用我们之前使用的相同命令：

$ResourceGroupName = "packt-demo-ps-multiple"
Remove-AzureRmResourceGroup -Name $ResourceGroupName -Force

我们可以在 Azure 中部署任何类型的资源时使用类似的方法；例如，我们可以部署多个 Azure VM。让我们执行一个类似的脚本，这次部署两台 Web 服务器：

$ResourceGroupName = "packt-demo"
$location = "westeurope"
$vmName = "packtdemoVM"
$NumberOfServers= 2

New-AzureRmResourceGroup -Name $ResourceGroupName -Location $location

$i=1

Do

{

New-AzureRmVm -ResourceGroupName $ResourceGroupName -Name $vmName"-0"$i -Location $location -VirtualNetworkName $vmName"-Vnet" -SubnetName $vmName"-subnet" -SecurityGroupName $vmName"-nsg" -PublicIpAddressName $vmName"-IP-"$i -OpenPorts 80,443,3389

} While (($i=$I+1) -le $NumberOfServers)

该脚本应该部署一个虚拟网络、一个子网和一个 NSG。这些资源将在 VM 之间共享。我们不希望创建不必要的资源，因为这将使 VM 能够通信。对于每个 VM，我们将创建一个 NIC 和一个磁盘。此处显示了脚本为两台服务器创建的资源示例：

现在，我们可以编辑此脚本以部署更多服务器，部署到新的资源组或新的子网，或更改任意数量的参数以影响部署结果。

因此，使用此脚本，我可以部署 1 到 100 台甚至更多服务器。现在，想象一下，您需要在 Azure Portal 中使用向导部署 100 个 VM。哪个任务需要更多时间？我认为我们可以认识到使用 IaC 进行部署具有多重好处，并且可以显著简化我们的工作。

代码配置

IaC 仅仅是自动化的第一步。在我们使用代码部署服务器后，仍然需要对其进行配置。手动配置服务器可能比部署它们还要花费更多时间。幸运的是，存在作为代码的配置选项，可以完成配置步骤。有很多不同的配置工具，但我们将探讨 Azure 自动化，作为 Azure 原生的配置即代码工具。

Azure 自动化可用于自动化和调度不同的任务。谈到作为代码的配置时，Azure 自动化使用 DSC。DSC 是 PowerShell 中的声明式管理平台，用于系统的配置、部署和管理。

使用 Azure 自动化应用 DSC

要创建一个新的 Azure 自动化帐户，我们需要提供帐户的名称、订阅、资源组和位置。另一种选择是创建“以管理员身份运行帐户”。以管理员身份运行帐户是一个服务主体，用于通过 Azure 自动化管理 Azure 资源时进行身份验证。我强烈建议您创建这个帐户，这样在有了帐户的情况下管理会更轻松。以下是创建 Azure 自动化帐户的示例：

使用 Azure 自动化，您可以执行各种操作、调度和运行脚本、管理资源等等。值得一提的是，您可以管理 Azure 和本地资源，以及其他云中的资源。在这里，我们将专注于将 DSC 应用于 Azure 虚拟机。

在 Azure 自动化中管理 DSC 是通过“状态配置（DSC）”来完成的。在这里，我们可以管理节点、配置、已编译的配置，并访问画廊。我们将会看到这些设置中的每一项，除了画廊。画廊包含一些可以使用或编辑的 DSC 脚本，您可以根据自己的需求进行修改。以下是状态配置（DSC）窗格的示例：

DSC 使用一个脚本，该脚本应用于选定的节点。节点可以是虚拟机（VM）或虚拟机组。这些虚拟机可以是 Azure 虚拟机或本地虚拟机。

要开始新的配置，我们需要一个 DSC 脚本。我们将使用的脚本确保服务器上安装了 IIS 角色。将脚本保存在本地，并确保文件名与配置的名称相同。在我们的示例中，名称应该是 webserverDSC：

configuration webserverDSC {
   Node WebServer {
      WindowsFeature IIS {
         Ensure = 'Present'
         Name = 'Web-Server'
         IncludeAllSubFeature = $true
      }
   }
}

在“配置”下，选择“新建配置”，并导入之前保存的脚本：

导入脚本后，需要编译它才能继续。选择已导入的脚本，新的窗口将会打开。选择“编译”，并等待编译完成。编译时间将取决于脚本的大小，但在这种情况下，应该不会超过 2-3 分钟。以下是配置窗格的示例：

在脚本编译完成后，我们可以继续并将配置应用到节点。进入节点页面，选择“新建”，将打开一个新的面板。在虚拟机列表中，我们可以选择希望应用 DSC 的虚拟机。我将选择我在本章中使用上一个脚本创建的虚拟机 packtdemoVM-01。

在注册页面下，我们可以选择几个选项。我们可以选择将使用哪个注册密钥、节点配置名称、刷新频率、配置模式频率、配置模式、是否允许模块覆盖或在需要时重新启动节点，以及重新启动后的操作。我将选择我们刚刚创建的新配置，并将其余设置保持为默认。以下是节点注册的示例：

注册完成后，我们需要等待初步检查并确保配置已应用到我们的服务器。这可能需要一些时间，具体取决于所选的频率以及我们想要应用的 DSC 配置的复杂性。如果你监控节点面板，添加的节点将从待处理状态变为进行中，直到最终达到合规状态。以下截图显示了一个已应用配置的节点：

在节点合规后，我们可以验证配置是否已应用。进入我们在节点注册时使用的虚拟机面板，找到公共 IP 地址。打开浏览器，尝试访问 http://'youripaddress'。你应该能看到默认的 IIS 页面，这将确认 IIS 已经在服务器上安装：

总结

微软 Azure 是一个拥有众多服务和选项的云平台。将这些服务结合在一起，产生了无限的可能性。我们提到了一些最佳实践，它们可以指导你创建高效且安全的云环境。基于这些，你可以根据自己的服务和需求扩展并创建你自己的规则和实践。

尽管我们已经完成了本书的内容，但我们所覆盖的仅仅是 Azure 提供的一小部分。涵盖所有可用的服务在一本书中几乎是不可能的，如果我们想要深入探讨每个服务，可能最终每个服务都会成为一本单独的书。本书旨在帮助你理解云设计、云服务以及云中的最佳实践，以便为你提供坚实的基础，帮助你开始云之旅，并在此基础上构建更多的知识。

学习 Azure 是一个持续的过程，因为每天都会添加新的服务和选项。我使用 Azure 已经很长时间了，几乎每次打开 Azure 门户时，我都会发现新的东西。但是，如果你掌握了云计算模式和最佳实践，理解新服务就不是问题。如果你理解了当前使用的服务，理解新功能和服务就不成问题，并且你会很快找到将它们运用到实际中的方法。

希望你喜欢这本书，并至少从中学到了一些知识！

问题

资源的名称应包含...
1. 尽可能多的信息
2. 尽可能少的信息
3. 基本信息
公共终端节点应当是...
1. 始终暴露于互联网访问
2. 仅在需要时暴露于互联网访问
3. 永不暴露于互联网访问
要控制对 Azure 虚拟机的管理访问权限，您可以使用...
1. 网络安全组（NSGs）
2. 随时访问权限
3. 两者
多因素认证是...
1. 所有用户免费
2. 管理员免费
3. 所有用户收费
4. 管理员收费
IaC 代表...
1. 基础设施即代码（IaC）
2. 基础设施即配置
3. 信息即代码
ARM 模板是一个...
1. 脚本
2. JSON 文件
3. TXT 文件
Azure 命令行工具是...
1. Azure PowerShell
2. Azure CLI
3. 两者
使用 IaC，我们可以...
1. 部署单个资源
2. 部署多个资源
3. 仅部署相同类型的资源
DSC 代表...
1. 所需状态配置（DSC）
2. 数字签名配置
3. 所需的扩展配置
在 Azure 自动化中应用 DSC 的步骤是...
1. 导入脚本、编译脚本并注册节点
2. 注册脚本、应用到节点并编译配置
3. 注册节点、编译脚本并应用配置

第十一章：评估

第一章：云计算的关键概念

哪种类型的云服务需要互联网连接，并允许任何人注册服务？

答案：公共云
哪种云服务模型允许我们对资源拥有最多的控制权？

答案：IaaS
哪种云服务模型需要最少的管理和维护？

答案：SaaS
哪种云服务模型始终为我们提供最新的功能和更新？

答案：PaaS
在 Azure 中，什么负责将客户端环境与其他客户端隔离？

答案：Azure 架构
Microsoft Azure 中的第一个访问层是什么？

答案：Azure 租户
在 Azure 中，您可以为资源分配的最低粒度是什么？

答案：Azure 资源
应该为 Azure 资源分配的推荐访问级别是什么？

答案：Azure 资源组
如何计算 Microsoft Azure 的定价？

答案：按分钟计费
ARM 模板属于什么？

答案：基础设施即代码（Infrastructure as Code）

第二章：Azure 网络——Azure IaaS 的基础

哪些服务依赖于 Microsoft Azure 中的 Azure 网络？

答案：两者皆是
什么定义了 Azure 中的 IP 地址范围？

答案：CIDR
服务端点用于将哪些服务连接到您的虚拟网络？

答案：PaaS
Microsoft Azure 中的默认 DNS 服务是...？

答案：Azure DNS
何时可以添加服务端点？

答案：任何时候
Azure 中的私有 IP 地址可以是...？

答案：两者皆是
Azure 中的公共 IP 地址可以是...？

答案：两者皆是
NSG 是...？

答案：定义流量流向的安全规则
NSG 定义了什么？

答案：两者皆是
NSG 不能分配给什么？

答案：虚拟网络

第三章：基础设施即服务——云计算的第一层

支持 Azure 虚拟机的最旧 Windows Server 版本是什么？

答案：Windows Server 2008 R2 SP1
基础层虚拟机可以支持什么？

答案：较低的 IOPS
低优先级虚拟机的用途是什么？

答案：批处理
在 Azure 虚拟机面板中的大小设置用于...？

答案：两者皆是
运行簿可用于执行什么？

答案：两者皆是
Azure 负载均衡器用于...？

答案：在后端池中分配流量到虚拟机
将虚拟机放入同一个可用性集将导致...？

答案：虚拟机将被放置在不同的机架上
通过创建额外的虚拟机实例来扩展称为...？

答案：扩展
扩展是...的一个例子？

答案：水平扩展
对于 Azure 虚拟机的扩展，我们使用...？

答案：规模集

第六章：Azure 存储、备份与站点恢复——将数据迁移到 Azure

Azure 存储账户可以作为...部署

答案：两者皆是
为了获得最大 SLA，存储账户应该是...

答案：地理冗余
存储账户层次可以是...

答案：两者皆是
本地数据库可以备份到 Azure 存储账户吗？

答案：是的
本地数据库可以直接部署到 Azure SQL 数据库吗？

答案：是的
要使用 ASR，您需要创建...

答案：恢复服务保险库
使用 Azure 备份，您可以保护...

答案：两者皆是
使用 ASR，您可以保护…

答案：两者
要将受 ASR 保护的 VM 迁移到云中，您必须…

答案：执行故障转移
要将大量数据迁移到 Azure，我们必须使用…

答案：Azure 导入/导出作业

第四章：Azure 应用服务 – 无服务器托管 Web 应用程序

Azure 应用服务是…

答案：PaaS
与虚拟机相比，应用服务计划给予我们多少控制？

答案：更少
与虚拟机相比，我们在 Azure 应用服务计划上的管理量是多少？

答案：更少
应用服务计划用于托管…

答案：Web 应用程序
插槽用于…

答案：托管应用程序的不同版本
Azure 应用服务计划的增加工作负载由…处理。

答案：横向扩展
Azure Web 应用的最佳监控工具是…

答案：应用程序洞察
Azure Web 应用的高可用性通过…实现。

答案：流量管理器
流量管理器支持…

答案：两者
为 Azure Web 应用提供隔离和专用环境的是一个…

答案：Azure ASE

第五章：Azure 数据平台

Azure 中的数据库可以作为…运行。

答案：两者
带 SQL 的 Azure 虚拟机与不带 SQL 的 VM 区别在于…

答案：SQL 服务器配置
Azure SQL 数据库也被称为…

答案：数据库即服务
Azure SQL 数据库层可以通过…来衡量。

答案：两者
您可以使用…在 Azure SQL 数据库上运行查询。

答案：两者
要连接到 Azure SQL 数据库，您需要…

答案：向防火墙规则中添加 IP 地址
要创建 Azure SQL 数据库副本，您可以使用…

答案：地理复制
要创建一个高可用的 Azure SQL 数据库，您需要创建一个…

答案：故障转移组
要在 Azure SQL 数据库中掩码列，您可以使用…

答案：动态数据掩码
要检测数据库潜在的威胁，您可以使用…

答案：高级威胁防护

第七章：Azure 混合云 – 将本地工作负载扩展到云端

混合云通常仅作为一个选项，因为…

答案：两者
我们可以通过使用…连接本地网络和 Azure。

答案：两者
S2S 所需的 Azure 资源…

答案：虚拟网络网关
本地网络网关保存…的配置。

答案：本地网络
可以从 Azure 门户下载 VPN 设备配置。

答案：正确，但对于有限数量的设备
S2S 连接的推荐模式是…

答案：资源管理器
为确保您可以在混合云中使用本地身份，您必须部署…

答案：Azure 中的域控制器
本地数据网关可以与…一起使用。

答案：有限数量的 Azure 服务
Azure Stack 是…

答案：Azure 在本地数据中心的扩展
Azure Stack 提供…

答案：两者

第八章：Azure Active Directory – 云中的身份

一个 AAD 位于一个…之上。

答案：租户
一个帐户可以属于多个租户：

答案：是
AAD 可以包含 Microsoft Live 帐户：

答案：是
AAD 可以与 Windows Server AD 同步：

答案：是
Azure Active Directory 免费版有一个限制...

答：500,000 个对象
要设置自定义域...

答：您必须拥有域名
要验证您的自定义域，您必须使用...

答：要么
使用 RBAC，您可以分配角色以...

答：以上所有
角色可以分配给...

答：两者都可以
要从应用程序设置 AAD 登录，您必须...

答：在 AAD 中注册应用程序

第九章：Azure 安全性与管理

Azure 中的所有内容都是冗余的，拥有多少份副本？

答：三种
大多数数据泄露是由...引起的

答：泄露的凭据
MFA 代表...

答：多因素认证
MFA 可以配置为使用：

答：以上所有
Azure 防火墙是...

答：作为服务的防火墙
Azure 资源可以使用...加密

答：两者都可以
要使用自定义密钥，我们必须使用...

答：Azure 密钥库
Azure 安全中心提供...

答：两者都可以
Azure 安全中心可用于保护...

答：两者都可以
即时访问提供...

答：控制对虚拟机的管理访问

第十章：最佳实践

资源的名称应该包含...

答：尽可能多的信息
公共端点应该是...

答：仅在需要时暴露于互联网访问
要控制对 Azure 虚拟机的管理访问，您可以使用...

答：两者都可以
多因素认证是...

答：管理员免费
IaC 代表...

答：基础设施即代码
一个 ARM 模板是...

答：JSON 文件
Azure 命令行工具是...

答：两者都可以
使用 IaC，我们可以...

答：部署多个资源
DSC 代表...

答：所需状态配置
在 Azure 自动化中应用 DSC 的步骤是...

答：导入脚本、编译脚本和注册节点

posted @ 2025-06-29 10:38 绝不原创的飞龙阅读(29) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

Azure-云管理实用指南-全-

Azure 云管理实用指南（全）

前言

本书的目标读者

为了充分利用本书

下载示例代码文件

下载彩色图像

使用的规范

联系我们

书评

第一章：云计算的关键概念

云计算概念

云计算的类型

Azure 的简要历史（从 ASM 到 ARM）

云服务模型

云服务模型的优缺点

云的其他好处

理解 Azure 订阅模型

Azure 订阅类型

在 IaaS 和 PaaS 之间做决定

了解 Azure 资源的定价

ARM 革命

总结

问题

第二章：Azure 网络 - Azure IaaS 的基础

技术要求

Azure 网络基础

在 Azure 中创建你的第一个虚拟网络

Azure 虚拟网络选项

连接的设备

创建 Azure 虚拟机

IP 地址类型

私有 IP 地址

网络安全组

公共 IP 地址

其他 Azure 网络服务

ARM 模板

总结

问题

第三章：基础设施即服务 - 云计算的第一层

技术要求

部署 Azure 虚拟机

创建新的 Azure 虚拟机

基本 Azure 虚拟机信息

Azure 虚拟机规格

高级虚拟机选项

管理 Azure 虚拟机

虚拟机设置

Azure 虚拟机操作与监控

Azure 负载均衡器

创建一个 Azure 负载均衡器

配置 Azure 负载均衡器

Azure 负载均衡器 ARM 模板

Azure 虚拟机规模集

创建一个 Azure 虚拟机规模集

管理 Azure 虚拟机扩展集

Azure 虚拟机规模集 ARM 模板

摘要

问题

第四章：Azure 应用服务 - 无服务器托管 Web 应用程序

技术要求

Azure 应用服务计划和 Azure Web 应用

创建应用服务计划

创建 Azure Web 应用

管理 Azure Web 应用

Azure Web 应用部署设置

Azure Web App 一般设置

自定义域名、证书和扩展

Azure Web App 工具

在 Azure 中监控 Web 应用

Application Insights

Azure App Service Plan

Azure Web App 高可用性

创建流量管理器

Traffic Manager 配置和设置

在专用环境中运行 Azure Web 应用

总结

问题