十、部署到 AWS 和 Azure

在上一章中,我们研究了容器和 Docker 平台。通过简化开发生命周期并帮助减少部署过程中出错的机会,容器是提高生产率的一个好方法。我们研究了流行的 Docker 框架,并提供了一些实际示例。

在本章中,我们将提供一些在两个领先的云提供商Amazon Web ServicesAWS)和 Azure 上托管 ASP.NET 解决方案的示例。这两个提供商都提供了一个复杂的服务器和基础设施网络,分布在全球各地,用于托管您的解决方案。这比听起来容易,因为两家提供商都提供工具、软件开发工具包SDK和扩展来支持您。

我们的目的是支持那些不熟悉云提供商及其托管服务的人。但我们希望不仅仅重复现有的教程和文档。因此,对于某些步骤,我们将指导您使用云服务提供商自己编写和提供的文档。

本章将介绍以下主题:

  • 云计算概述
  • 负载平衡器与网站健康
  • 使用 Visual Studio 发布到 AWS
  • 使用 Visual Studio 发布到 Azure

对于许多刚接触 AWS 和 Azure 的用户来说,入门是一项挑战。这些门户网站旨在帮助新用户,并提供支持文档和教程。在本章末尾的进一步阅读一节中,我们将重点介绍一些我们认为特别有用的内容。

在本章结束时,您将对 AWS 和 Azure 有一些熟悉。您将有一些使用 Visual Studio 扩展部署 ASP.NET 应用的实际经验。您还将拥有在 AWS 控制台和 Azure 门户中查看已部署应用的经验。本章介绍云提供商,我们将在第 13 章云原生中详细介绍云解决方案的开发。

技术要求

本章包括简短的代码片段,以演示所解释的概念。需要以下软件才能使其正常工作:

确保下载 SDK,而不仅仅是运行时。您可以通过打开命令提示符并运行dotnet --info来验证安装,如图 10.1所示:

Figure 10.1 – Verifying the installation of .NET

图 10.1–验证.NET 的安装

作为本章的一部分,我们将使用 VisualStudio 中的扩展来处理 AWS 和 Azure。

请访问以下链接查看 CiA 视频:https://bit.ly/3qDiqYY

与 AWS 合作

AWS 账户需要执行发布到 AWS部分中的步骤。本节中的步骤旨在通过使用免费层的服务,为新的 AWS 账户收取少量或不收取费用。如果使用指定服务以外的服务,可能会产生费用。

要创建新的 AWS 帐户,请使用 AWS 门户网站上的创建 AWS 帐户按钮:https://aws.amazon.com/ 。本章末尾的进一步阅读一节中引用了有关该过程的其他信息。

我们将使用 AWS 工具包扩展,在 Visual Studio 中使用管理扩展,如图 10.2所示:

Figure 10.2 – Manage Extensions

图 10.2–管理扩展

可通过搜索短语AWS Toolkit找到 AWS 工具包,并可在图 10.3中看到:

Figure 10.3 – AWS Toolkit extension

图 10.3–AWS 工具包扩展

有关安装 AWS Visual Studio 工具包的其他信息,请访问https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/welcome.html

与 Azure 合作

需要 Azure 帐户来执行发布到 Azure部分中的步骤。本节中的步骤旨在确保每月 200 美元的信用额度涵盖使用费,从而使新 Azure 帐户不收取任何费用。此积分适用于所有新 Azure 帐户。如果使用规定以外的服务,可能会产生费用。

要创建新的 Azure 帐户,请使用 Azure 网站上的免费启动按钮:https://azure.microsoft.com/en-us/free/ 。本章末尾的进一步阅读一节中引用了有关该过程的其他信息。

Azure 扩展是作为 Visual Studio 2019 的一部分安装的。这可以使用 Visual Studio 安装程序通过选择修改选项来完成,如图 10.4所示:

Figure 10.4 – Visual Studio Installer

图 10.4–Visual Studio 安装程序

应选择Azure 开发包在 Visual Studio 中添加 Azure 支持,如图 10.5所示:

Figure 10.5 – Azure development

图 10.5–Azure 开发

通过选择Azure 开发包,可以获得与 Azure 相关的 SDK、工具和示例项目。

GitHub 源代码

本章的源代码位于 GitHub 存储库中的https://github.com/PacktPublishing/ASP.NET-Core-5-for-Beginners/tree/master/Chapter%2010

云计算概述

本节仅提供云计算的简要概述,因为我们将在第 13 章云原生中更详细地介绍内部部署和云计算模型。本节的目的是提供有关云计算的上下文以及两个选定云提供商的一些背景。您可能希望阅读发布到 AWS发布到 Azure部分,但仅执行其中一个提供商的步骤。

云计算可以被认为是通过互联网提供计算基础设施和服务。在云计算普及之前,组织选择从自己运行的数据中心托管服务。我们将这些数据中心称为本地,因为它们通常托管在组织自身的本地。

在本章中,我们将所需的基础设施和托管服务作为资源。这些资源包括范围广泛的东西,包括虚拟机虚拟机)、数据库、人工智能服务AI)以及处理大量数据的服务。随着市场的不断发展,资源范围不断扩大。这些资源可供公众使用,但需要订阅才能访问。

云计算模型

这些资源被分为以下大类。我们在这里强调它们,因为您经常听到人们以这种方式引用资源组:

  • 基础设施即服务IaaS):此类别指解决方案所基于的 IT 基础设施。将这一类别视为您租用给应用的网络、计算和数据存储资源。IaaS 的一个例子是 VM 以及 VM 使用的磁盘和网络。
  • 平台即服务PaaS):这些资源通常是对 IaaS 资源的抽象,使开发和管理应用更加容易。这些资源消除了组织管理和提供底层资源的需要,这允许组织更轻松地构建和维护应用。这种平台的一个例子是托管数据库,其中托管的详细信息(例如,运行数据库所需的 VM 和磁盘)由云提供商处理。
  • 软件即服务SaaS):该类别包含由云提供商或第三方构建和管理的产品和服务。SaaS 的一个例子是电子邮件服务。

云计算提供商

有许多公司提供云计算服务,我们将关注两个领先的云提供商:AWS 和 Azure。我们选择它们有几个原因:

  • 它们都为托管 ASP.NET Core 解决方案提供了强大的支持。
  • 这两个云提供商都提供 IaaS 资源,包括 Linux 和 Windows 虚拟机的配置,可用于托管 web 应用。
  • 它们还提供了几个 PaaS 产品,简化了 ASP.NET Core 解决方案的托管。

我们将在本章后面介绍 AWS Elastic Beanstalk 和 Azure 应用服务。这些 PaaS 产品是一个很好的例子,它简化了基础架构的细节,使您能够专注于构建解决方案。

亚马逊网络服务

AWS 成立于 2006 年,当时最大的零售公司之一亚马逊(Amazon)提供了供组织使用的 IT 基础设施。这一最初的产品已成长为全球最大的云服务提供商,从全球数据中心提供数百种不同的资源。2020 年 7 月,据估计 AWS 拥有 31%的云计算市场份额。

弹性豆茎

发布到 AWS部分,我们将关注 AWS 弹性豆茎。此 PaaS 产品通过简化托管 web 应用的细节,使托管 ASP.NET Core web 应用变得简单。我们选择此产品是因为它非常常用于托管 web 应用,并且弹性 Beanstalk 的部署集成到 Visual Studio 中。

我们应该解释的一件事是应用和环境之间的区别。将应用视为环境的集合。这些环境是相关的,但它们有单独的配置。将它们视为同一网站的不同版本。每个环境都有自己的 URL。

一个常见的场景是有一个开发环境,其中新的更改由开发团队测试,以及一个客户使用的生产环境。开发环境可能被配置为使用不同的数据库,并且只运行一个实例。生产环境可能使用不同的数据库,并具有多个实例。

蔚蓝色的

Azure 于 2010 年发布,与 AWS 一样,它已经稳步增长,包括来自世界各地数据中心的数百种产品。2020 年 7 月,Azure 估计拥有 20%的云计算市场份额。

Azure 应用服务

发布到 Azure部分中,我们将使用 Azure 应用服务托管我们发布到 AWS 的相同 ASP.NET Core web 应用。与 AWS Elastic Beanstalk 一样,此 PaaS 产品还简化了 ASP.NET Core web 应用的托管,Azure 应用服务的部署与 Visual Studio 集成。

创建 ASP.NET Core web 应用示例

在本章中,我们将使用一个简单的 ASP.NET web 应用来说明 AWS 和 Azure 的一些功能。示例应用一直保持简单,因为我们希望将重点放在部署到云上。我们将添加一个返回应用运行状况的新端点。这将被云平台使用,以确定应用是否健康。

我们建议您从 GitHub 存储库中的源代码开始,因为本章更多地是关于 Visual Studio 扩展,而不是 ASP.NET Core 应用。我们将为那些希望自己构建应用的人描述构建示例的步骤:

  1. First, we created the sample application by using the dotnet new mvc command in a folder named Chapter 10 Final. This is shown in Figure 10.6:

    Figure 10.6 – dotnet new mvc command

    图 10.6–dotnet 新 mvc 命令

  2. To make sure the application restored, we used the dotnet run command as shown Figure 10.7:

    Figure 10.7 – dotnet run command

    图 10.7–dotnet 运行命令

  3. 然后我们使用浏览器验证应用返回的主页没有错误,如图 10.8所示:

Figure 10.8 – Sample application

图 10.8–示例应用

这表明基本应用已恢复,没有问题。现在,我们将添加检查应用运行状况的功能。

检查运行状况终结点

许多应用都是为支持健康端点而设计的。当应用实例按预期运行时,此端点被设计为返回健康状态。还记得我们谈到云计算的好处之一是可伸缩性吗?当应用有多个实例共同处理发送到网站的请求时,运行状况端点非常有用。使用健康端点,应用实例可以在其未处于能够成功处理请求的状态时进行报告。

让我们假设你有一个 Web 应用,有时发送给应用的消息太多,无法处理。我们有两个选择。我们可以增加运行 web 应用的资源的大小。这称为放大。我们还可以添加额外的资源(称为实例)来处理消息。这被称为向外扩展。在云中,添加应用的额外实例很容易,而且通常比增加资源的大小更具成本效益。

让我们用图 10.9更详细地讨论一下:

Figure 10.9 – Load balancer with two applications

图 10.9-具有两个应用的负载平衡器

上图显示了两个 web 应用和一个负载平衡器。在本例中,我们有一个由两个应用组成的单一环境。负载平衡器用于将请求分发到两个应用之间的环境。在某些情况下,消息的数量可能会增加到两个应用无法处理的程度。当发生这种情况时,可以增加应用的数量,如图 10.10所示:

Figure 10.10 – Load balancer with four applications

图 10.10–具有四种应用的负载平衡器

现在,我们有四个 web 应用位于负载平衡器后面。因为负载平衡器将请求分布到所有应用中,所以环境可以处理增加的请求数。

即使将应用添加到环境中,应用也可能需要一些时间来准备接收请求。可能应用需要先将信息加载到内存中,或者在准备就绪之前执行一些处理。或者,在某个时刻,应用可能检测到所需的资源不可用。虽然应用无法成功处理请求,但它可以通过返回不正常的响应让负载平衡器知道。这将使负载平衡器知道不向应用发送请求。如图 10.11所示:

Figure 10.11 – Load balancer with an unhealthy application

图 10.11-具有不正常应用的负载平衡器

在上图中,App3正在向负载平衡器返回一个不正常的响应。然后,负载平衡器将停止向应用实例发送请求。

现在,让我们看看这是如何做到的。

响应状态代码

约定是创建一个通常称为“健康”的端点。这应该表明系统健康或不健康。这是通过返回状态代码为200 (OK)的响应或状态代码为5xx的响应来完成的。

笔记

5xx表示500-599范围内的任何状态代码。约定返回503(服务不可用)。

为了使这一点有意义,我们需要更详细地了解消息的外观。为此,让我们使用浏览器的开发工具。我将使用 Edge,但在 Firefox 或 Chrome 中的体验也将类似。在浏览器中,按F12启动开发者工具。Edge 的显影工具如图 10.12所示:

Figure 10.12 – Developer tools for Edge

图 10.12–Edge 的开发者工具

您将看到几个选项卡,我们感兴趣的选项卡称为网络。继续并选择此选项卡。

笔记

我们将在第 11 章调试和单元测试中详细讨论开发工具。

现在网络选项卡已打开,请刷新我们网站的主页。您应该看到类似于我们在图 10.13中看到的内容:

Figure 10.13 – Developer tools Network tab

图 10.13–开发人员工具网络选项卡

将列出对服务器的每个请求,并包括请求类型、大小以及接收响应所用的时间等信息。我们感兴趣的栏目是状态。在上图中,您可以看到每个请求的状态为200。这意味着每个响应都包含一个状态代码200,表示响应处理无误。

现在,让我们尝试导航到一个不存在的端点。我们可以通过将/unknown放在 URL 的末尾来实现这一点。现在看看图 10.14中的响应代码:

Figure 10.14 – Network log with failed response

图 10.14–响应失败的网络日志

服务器现在的响应状态为404,这意味着未找到请求的页面。在我们的示例应用中,我们将使用状态代码503进行响应,这意味着应用不健康。

添加健康端点

在本节中,我们将修改应用以支持健康端点。该终点将返回健康或不健康的反应。我们将随机地这样做;大多数情况下,响应是健康的,但偶尔端点会以不健康的响应进行响应。

在 ASP.NET Core 中,Microsoft.Extensions.Diagnostics.HealthChecks库中有健康检查中间件来支持这一点。有关此中间件的更多信息,请参阅进一步阅读部分。

首先,我们需要创建一个类来实现 IHealthCheck 接口。我们称之为健康检查。创建类后,添加: IHealthCheck,如图 10.15所示:

图 10.15–IHealthCheck 界面

IHealthCheck 下出现红色扭曲的原因是 VisualStudio 不知道该界面是什么。您通过为Microsoft.Extensions.Diagnostics.HealthChecks添加using Health Checks Middleware语句而离开 Visual Studio。如果您将鼠标悬停在 IHealthCheck 上,您可以选择添加此项,如图 10.16所示:

Figure 10.16 – Diagnostics HealthChecks

图 10.16–诊断健康检查

IHealthCheck 仍然会有一个红色的曲线,因为现在 VisualStudio 已经知道了接口,它告诉我们需要实现匹配的方法。同样,您可以通过选择实现接口进行添加,如图 10.17所示:

Figure 10.17 – Implementing the IHealthCheck interface

图 10.17–实施 IHealthCheck 接口

实现接口选项将为CheckHealthAsync生成一个方法。我们将用以下代码行替换throw语句:

var random = new Random();var isHealthy = random.Next(10) != 1;if (isHealthy){    return Task.FromResult(HealthCheckResult.Healthy());}else {    return Task.FromResult(HealthCheckResult.Unhealthy());}

此代码段的第一部分使用Random类生成一个介于09之间的随机值。在1上,我们将布尔值isHealthy设置为false;否则设置为true。片段的第二部分将在IsHealthytrue时返回HealthCheckResult健康状态,或者在false时返回false不健康状态。

笔记

我们之所以使用Task.FromResult(),是因为接口方法是异步的,因此需要返回类型Task

现在我们已经实现了HealthCheck,我们需要连接中间件。为此,我们将更新Startup类。在Status.csConfigureServices方式中,增加以下行:

services.AddHealthChecks().AddCheck<HealthCheck>("web");

这将添加我们的HealthCheck实现作为HealthChecks中间件中的检查。图 10.18显示完成的ConfigureServices方法:

Figure 10.18 – ConfigureServices method

图 10.18–配置服务方法

下一步是添加HealthCheck作为端点。我们将把这张支票放在/health,因为这是惯例。为此,在Configure方法中添加以下端点:

endpoints.MapHealthChecks("health");

图 10.19显示了完成的方法,并突出显示了我们插入的行:

Figure 10.19 – Configure method

图 10.19–配置方法

此更改仅公开了/health处的运行状况检查。

继续并运行解决方案,以查看此操作。一旦应用启动,通过向 URL 添加/health导航到健康端点,如图 10.20所示:

Figure 10.20 – Health endpoint

图 10.20–健康终点

尝试按 refresh,您将看到大约 10 次中的 1 次Unhealthy响应。图 10.21显示了开发者工具中的响应:

Figure 10.21 – Network log with an unhealthy response

图 10.21–响应不正常的网络日志

注意,第三个响应的状态为503。这表示有Unhealthy响应。

笔记

在开发人员工具中,使用保留日志选项将以前的响应保留在日志中。

现在我们已经准备好了示例应用,让我们将其发布到 AWS 和 Azure!

发布到 AWS

在本节中,我们将向 AWS Elastic Beanstalk 发布我们的应用。此时,您应该创建一个 AWS 帐户。有几种方法可以部署到 AWS Elastic Beanstalk。一种方法是直接在 AWS 控制台中。相反,我们将使用 AWS 工具包,因为它简化了部署过程。要使用 AWS 工具包进行部署,我们需要向 VisualStudio 添加所需的凭据。

创建用于从 Visual Studio 发布的用户

为了获得我们需要的凭证,我们将在 AWS 中创建一个用户。这是在 AWS 控制台中完成的。继续并登录:

  1. The service we are interested in deals with identity and access. To find this service, use the Services dropdown and type iam as shown in Figure 10.22:

    Figure 10.22 – IAM service

    图 10.22–IAM 服务

  2. After selecting this service, select Users under Access management as shown in Figure 10.23:

    Figure 10.23 – Identity and Access Management (IAM)

    图 10.23–身份和访问管理(IAM)

  3. We want to add a user, so select the Add user button. This will start a wizard. The first step sets the user's details. We will add a new user with the name VisualStudioUser. This user will be getting programmatic access as shown here Figure 10.24:

    Figure 10.24 – Add user – step 1

    图 10.24–添加用户–步骤 1

  4. Next, we want to add some permissions. We'll do this by adding the required permissions to a group and then adding the user to a group. This is a great way of configuring combinations of permissions so that they can be given to multiple users consistently. Select the Create group button as shown in Figure 10.25:

    Figure 10.25 – Add user – step 2

    图 10.25–添加用户–步骤 2

  5. We will now create a group named VisualStudioPublisherGroup, and we will add two permissions. The first is access to IAM. This can be seen in Figure 10.26:

    Figure 10.26 – Create group – IAMFullAccess

    图 10.26–创建组–IAMFullAccess

    所需的第二个权限是访问 AWS Elastic Beanstalk,如图 10.27所示:

    Figure 10.27 – Create group – AWSElasticBeanstalkFullAccess

    图 10.27–创建组–AWSElasticBeanstalkFullAccess

  6. After you have these permissions selected, proceed to the next step by pressing the Create Group button.

    笔记

    AWS 权限的详细信息不在本章的范围内。在进一步阅读部分,我们将提供与 AWS 相关的资源。

    图 10.28显示用户将被添加到新组:

    Figure 10.28 – Add user – review

    图 10.28–添加用户–审查

  7. For our purposes, we do not need to define any tags, so we can skip the Tags step. Figure 10.29 shows a summary of the user:

    Figure 10.29 – Add user – step 4

    图 10.29–添加用户–步骤 4

  8. 点击创建用户按钮后,我们会看到一个动作摘要,如图 10.30所示:

Figure 10.30 – Add user – step 5

图 10.30–添加用户–步骤 5

继续并使用下载.csv按钮下载凭证。这些是我们将加载到 VisualStudio 中的凭据。

理解 AWS 中的区域

在这一点上,我们应该突出区域。云提供商将世界划分为多个区域。这些对应于地理位置相近的数据中心集合。AWS 资源既可以是区域性的,也可以是全球性的。例如,我们的用户是全球性的。我们将要部署的 web 应用将是区域性的。

判断资源是否为全局资源的一个简单方法是查看 AWS 控制台的右上角。选择 IAM 时,如图 10.31所示:

Figure 10.31 – AWS global resource

图 10.31–AWS 全球资源

现在,继续使用图 10.32所示的服务下拉列表查找AWS Elastic Beanstalk

Figure 10.32 – AWS Elastic Beanstalk

图 10.32–AWS 弹性豆茎

您将现在看到,默认情况下,与您最近的区域已被选中。在本例中,选择了悉尼地区,如图 10.33所示:

Figure 10.33 – AWS Elastic Beanstalk Regions

图 10.33–AWS 弹性豆茎区域

我们将将我们的应用部署到一个地区。您可以选择一个或另一个默认区域。

AWS 发布

在这一节中,我们将从 Visual Studio 发布到 AWS。让我们开始:

  1. Back in Visual Studio, right-click on the project and select the Publish to AWS Elastic Beanstalk… option as seen in Figure 10.34:

    Figure 10.34 – Publish to AWS Elastic Beanstalk…

    图 10.34–发布到 AWS Elastic Beanstalk…

  2. Next, we need to add our credentials. You do this by clicking the image of the person with a plus symbol. This is indicated in Figure 10.35:

    Figure 10.35 – Adding a profile

    图 10.35–添加配置文件

  3. This will present you with a dialog where you can specify the profile name as well as loading the credentials we downloaded Figure 10.36:

    Figure 10.36 – Visual Studio AWS profile

    图 10.36–Visual Studio AWS 配置文件

    在上图中,我们提供了一个名称VisualStudioPublisher并使用从 csv 文件导入…按钮导入了我们的凭证。我们保留了标准 AWS 账户的默认设置,点击确定

  4. Now that we have loaded our credentials, we can specify the Region we want to deploy to as shown in Figure 10.37:

    Figure 10.37 – AWS publish wizard step 1

    图 10.37–AWS 发布向导步骤 1

    由于这是一个新的应用环境,我们只能选择新建应用环境。继续并单击下一步

  5. In the next step, we specify the name of the application and environment. We also construct the URL of the website we are creating as shown in Figure 10.38:

    Figure 10.38 – AWS publish wizard step 2

    图 10.38–AWS 发布向导步骤 2

    在上图中,我们将应用命名为Chatper10Final,并选择了开发环境。您可能会发现您需要更改 URL,直到找到一个免费名称,您可以使用检查可用性按钮查看 URL 是否免费。此 URL 将是全局的,因此它必须是唯一的。

    继续并按下下一步

  6. The next page provides some details about the environment. Elastic Beanstalk will be hosted on an EC2 VM. We don't have to worry about many of the details, but we do have to consider the type and size Figure 10.39:

    图 10.39–AWS EC2 类型和尺寸

    在上图中,我们选择了 Windows Server 核心版本,因为我们需要最新的.NET 版本。我们的应用不需要大型 VM,因此我们选择了t3a.micro,因为它位于 AWS 自由层。

    笔记

    并非所有 AWS Elastic Beanstalk 类型都支持 ASP.NET Core 5。要了解什么环境将支持部署,请使用 AWS Elastic Beanstalk 发行说明:https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/relnotes.html

    另一个必填字段是密钥对,它允许我们在部署后访问环境,如图10.40所示:

    Figure 10.40 – AWS key pair

    图 10.40–AWS 密钥对

    在前面的截图中,我们将密钥对命名为vs_key_pair

  7. The next parameter to note is Single instance environment. When clicked, the application can only have one instance. But when unselected, the application will be provisioned with a load balancer and will allow more than one instance. It will be initially provisioned with one instance.

    要显示如何设置健康端点,请取消选择单实例环境,如图 10.41所示:

    Figure 10.41 – Load balancer type

    图 10.41–负载平衡器类型

    默认的负载平衡器就是我们想要的。这将使用 HTTP 请求并使用响应状态代码来确定运行状况。继续下一页,如图 10.42所示:

    Figure 10.42 – AWS publish wizard permissions step

    图 10.42–AWS 发布向导权限步骤

    此页面允许您设置应用权限。出于我们的目的,默认值是合适的。继续下一页,如图 10.43所示:

    Figure 10.43 – AWS publish wizard options step

    图 10.43–AWS 发布向导选项步骤

  8. 列出了几个选项,但为了简单起见,我们只对默认值进行两次更改。第一个是设置启用增强健康报告。这是一项免费服务,提供有关我们正在运行的服务的附加信息。第二个是健康检查 URL。只有在未启用单实例环境时,您才会看到这一点。我们将此设置为健康检查端点/health

  9. After clicking Finish, your options are presented for review as shown in Figure 10.44:

    Figure 10.44 – Review

    图 10.44–审查

  10. When you click Deploy, the deployment will begin. This will take time, so be patient.

    您可以在输出窗口中看到部署的状态,如图 10.45所示:

Figure 10.45 – Output

图 10.45——产出

显示 AWS 应用的窗口也将显示在图 10.46中:

Figure 10.46 – Environment window

图 10.46–环境窗口

这是了解应用的一个很好的工具。花点时间来探索它的一些特性。

由于我们已经启用了健康端点,请密切关注环境的健康:

Figure 10.47 – Events

图 10.47–事件

如上图所示,当健康端点返回不健康响应时,503状态代码作为警告,AWS 会进行报告。

AWS 的下一步

AWS Elastic Beanstalk 是托管 ASP.NET Core 应用的优秀 PaaS 服务,尤其是与其他 AWS 资源(如数据库和存储)结合使用时。我们提供了一个非常简单的示例来帮助您开始。接下来的步骤将是探索 AWS 提供的一些资源。这些可在 AWS 的以下位置找到:

我们研究了如何使用部署向导,但还有许多其他方法可以部署到 Elastic Beanstalk。例如在第 12 章与 CI/CD的集成中,我们将考虑直接从 GitHub 部署解决方案。为了找到最适合您和您的团队的方法,探索一种技术是很好的。

接下来,我们将了解 Azure 应用服务是如何工作的。

发布到 Azure

在部分中,我们将向 Azure 应用服务发布应用。此时,您应该创建了一个 Azure 帐户。有几种方法可以部署到 Azure web 应用,与我们的 AWS 示例一样,我们将使用 Visual Studio 中提供的功能。

在 Azure 中使用发布向导

在我们的解决方案中,我们将使用发布向导部署到 Azure 应用服务。

您可以右键单击项目启动向导,如图 10.48 所示:

Figure 10.48 – Publish…

图 10.48–发布…

此向导将引导您完成一系列步骤,它支持不同类型的发布,包括 Azure、Docker 容器注册表和 IIS。我们将这些步骤分解为指定要部署的内容,然后指定要部署到的位置。

发布到 Azure 应用服务

我们将发布到Azure,所以选择此选项,如图 10.49所示:

Figure 10.49 – Publishing to Azure

图 10.49–发布到 Azure

该向导支持发布到不同类型的 Azure 资源。我们将部署到运行在 Windows 上的 Azure 应用服务。我们也可以部署到运行 Linux 的应用服务。我们还可以将 Docker 映像部署到 Azure 容器注册表,并选择在 Azure 应用服务中运行 Docker 映像。还支持部署到 Azure VM 的选项。

我们将部署到运行在 Windows 上的 Azure 应用服务,因此在此页面上选择第一个选项,如图 10.50所示:

Figure 10.50 – Azure App Service (Windows)

图 10.50–Azure 应用服务(Windows)

既然向导知道我们要部署什么,我们需要指定要部署到哪里。

笔记

根据与 Azure 帐户关联的电子邮件与与与 Visual Studio 关联的电子邮件是否匹配,以下页面可能会有所不同。以下截图来自帐户不匹配和/或您需要使用 Azure 进行身份验证时的截图。

创建新的 Azure 应用服务实例

接下来的系列步骤将使用您先前创建的 Azure 帐户创建一个新的 Azure 应用服务实例。第一步是使用登录链接对 Azure 帐户进行身份验证。图 10.51显示下的链接已经有账户了?标签:

Figure 10.51 – Sign In

图 10.51–登录

使用 Azure 帐户验证 Visual Studio 后,将向您显示一个与您正在创建的资源类型匹配的现有资源列表。由于这是我们的第一个资源,您将看到(未找到资源),如图 10.52所示:

图 10.52–资源组视图

当您在上图所示的页面上时,选择创建新的 Azure 应用服务链接以使用新的托管计划定义新的资源组。

让我们花些时间来定义这些术语。Azure 中的资源被分组为资源组。这允许将逻辑上相似的资源分组在一起,并提供一种同时管理资源组中所有资源的方法。例如当您准备删除一个网站时,您可以同时删除整个资源组及其所有资源。

在此页面,我们将创建一个新的资源组,如图 10.53所示:

Figure 10.53 – New resource group name

图 10.53–新资源组名称

笔记

您使用的名称并不重要,但如果您希望遵循命名约定,我们建议您使用以下指南:https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging

下一步是创建托管计划。托管计划确定区域以及应用服务的所有实例使用的计算资源的大小。与 AWS Elastic Beanstalk 一样,选择您附近的区域。应用服务的大小将决定每月的费用,范围从免费到高级定价。如图 10.54 所示,如果您有免费托管计划,请选择该计划:

Figure 10.54 – Creating a new hosting plan

图 10.54–创建新的托管计划

在上图中,我们保留了默认名称并选择了悉尼数据中心。我们还选择了Standard 1的尺寸。在您的情况下,您应该可以访问自由大小。

定义了区域和大小之后,我们就可以创建托管计划了。使用创建按钮开始创建托管计划,如图 10.55所示:

Figure 10.55 – Creating a new resource group and hosting plan

图 10.55–创建新的资源组和托管计划

创建托管计划后,您将看到您的资源组和应用服务,如图 10.56所示:

Figure 10.56 – App service defined

图 10.56–已定义的应用服务

继续,点击完成进入下一步。

我们的发布配置文件现已完成。我们现在看到的页面如图 10.57所示:

Figure 10.57 – App ready to publish

图 10.57–准备发布的应用

这将向我们显示将使用的发布配置文件,包括将生成的 URL 和资源组。所有的默认值都是我们想要的,所以请继续并按发布

输出窗口中,您可以查看构建和发布的进度,如图 10.59所示:

Figure 10.58 – Output

图 10.58——产出

另一个需要注意的窗口是网络发布活动。这将提供有关发布活动的更多详细信息,如图 10.59所示:

Figure 10.59 – Web Publish Activity

图 10.59–网络发布活动

发布完成后,将使用网站 URL 启动默认浏览器。一旦网站加载到浏览器中,导航到健康端点,如图 10.60所示:

Figure 10.60 – Azure App Service health endpoint

图 10.60–Azure 应用服务运行状况端点

上图中显示的端点表明我们的网站是健康的。多次按下刷新按钮。你应该会看到很多健康的反应,但也有一些不健康的反应。这表明我们的健康端点正在按预期工作。

笔记

与 AWS Elastic Beanstalk 类似,在处理这些示例时,不知道对 ASP.NET 的支持是什么。根据可用的版本,您可能必须针对较旧版本的框架。这是一个方便的地图,显示.NET 与 Azure 应用服务的兼容性:https://aspnetcoreon.azurewebsites.NET/#.NET%20Core%20SDK

现在我们已经部署了解决方案,让我们看看 Azure 如何支持健康端点。

健康检查

要查看运行中的健康端点,我们需要在 Azure 门户中查看它。与 AWS 一样,Azure 意识到第一次查看门户可能会让人望而生畏。有很多信息需要了解。与 AWS 一样,Azure 也有一项功能可以帮助您追踪资源—搜索。

在页面顶部,有一个搜索栏。使用此功能时,门户将过滤所有服务、资源和文档。我们输入了chapter,如图 10.61所示:

Figure 10.61 – Azure portal search

图 10.61–Azure 门户搜索

这将显示与输入值匹配的应用服务和应用服务计划的方式。选择您发布的应用服务。

在所选应用服务的左侧,您将看到菜单选项。我们想要的选项在监控部分,称为健康检查(预览)。您可以在图 10.62中看到:

Figure 10.62 – Health check menu

图 10.62–健康检查菜单

上图显示了此选项,在撰写本文时,此功能处于预览状态,如图所示。

当您选择健康检查选项时,您将能够启用该功能,并且您可以定义到端点的路径,如图 10.63所示:

Figure 10.63 – Health check path

图 10.63–健康检查路径

上图显示了使用我们定义的/health路径启用的健康检查。另外,请注意顶部显示的信息,这些信息清楚地表明,如果实例不健康,Azure 将采取什么措施。在我们的例子中,我们只运行一个实例,因此 Azure 只会在实例不健康时提醒我们。如果我们有多个实例在运行,那么不健康的资源将被删除,一个新的资源将被联机以替换它。

启用健康检查后,导航到度量选项。这也在监控部分,如图 10.64所示:

Figure 10.64 – Metrics

图 10.64——指标

我们感兴趣的指标是健康检查状态。继续添加此指标,如图 10.65所示:

Figure 10.65 – Adding Health check status

图 10.65–添加健康检查状态

让度量运行一段时间,以查看应用的运行状况随时间的变化。您应该得到一个应用基本正常的图形。图 10.66是我们的指标如何出现的示例:

Figure 10.66 – Metrics

图 10.66——指标

花一点时间探索其他可用的指标。这是一种简单而有效的监控应用服务的方法。

Azure 下一步行动

Azure 应用服务是托管 ASP.NET Core 应用的优秀 PaaS 服务。像 AWSElastic Beanstalk 一样,应用服务可以与 Azure 中托管的其他服务、其他云提供商甚至本地服务集成。我们提供了一个非常简单的示例来帮助您开始。接下来的步骤将是探索 Azure 提供的一些资源。这些可以在 Azure 中的以下位置找到:

总结

在本章中,我们介绍了如何使用 AWS 和 Azure 托管我们的 ASP.NET Core 应用。我们简要介绍了云计算,包括如何将资源分类为 IaaS、PaaS 和 SaaS。使用这些分类有助于讨论 AWS 和 Azure 提供的不同产品和服务。我们还讨论了如何使用负载平衡器将流量定向到网站的多个实例。我们研究了网站如何使用健康端点对负载平衡器的健康状态做出响应。

然后,我们看到了将示例 ASP.NET Core 应用部署到 AWS 和 Azure 的两个实际示例。对于这两个示例,我们使用了 VisualStudio 中支持的功能来简化部署过程。我们鼓励您查看这两个云提供商的后续步骤以及进一步阅读部分中的链接。这将提供更多关于这些云提供商提供什么以及不同部署类型的上下文。

下一章将介绍调试和单元测试的基本主题。本文将介绍 ASP.NET Core 和 Visual Studio 用于记录应用活动的一些功能。我们还将重点介绍 VisualStudio 中调试的一些最有用的功能。本章还将介绍构建单元测试,包括 VisualStudio 提供的一些重要功能。

问题

  1. 虚拟网络允许您定义设备和其他网络之间的路径或路由。这个资源是什么云计算模型的一个例子?
  2. 运行状况端点是否仅适用于 AWS?
  3. Azure 是否仅在 Visual Studio 中受支持?
  4. 哪个云提供商更好:AWS 还是 Azure?

进一步阅读