使用 Microsoft Azure 作为 Docker 容器构建和部署 ASP.NET Core Web 应用程序 - 第 3 部分

引言

这是关于使用 Microsoft Azure 构建 ASP.NET Core Web 应用程序并将其作为 Docker 容器部署的系列文章的最后一部分。在这里，我们将设置一个 Microsoft Azure DevOps 发布管道，以自动化我们将应用程序作为容器部署到 Azure Web App Service 的过程。

如果您一直关注，您应该已经有了

• 一个带有 ASP.NET Core (或类似) Web 应用程序的 GitHub 存储库
• 一个用于构建应用程序镜像的 Dockerfile
• Azure DevOps Pipelines 与 GitHub 集成，以自动触发生成
• Azure DevOps 中的持续集成管道，用于构建 Docker 镜像并将其推送到 Docker Hub

该系列文章的三部分

• 开发一个 ASP.NET Core Web 应用程序并使用 Docker 对其进行容器化
• 使用 Microsoft Azure DevOps Pipeline 和 GitHub 设置持续集成
• 设置持续部署管道，将应用程序作为 Docker 容器部署到 Azure Web App Service

手动部署到 Azure Web App Service

在我们进行任何自动化之前，让我们先手动部署应用程序并看看它是否正常工作。为此，请转到 Microsoft Azure 门户并提供登录详细信息。

从导航面板中，选择“App Services”，然后选择“添加”。在接下来的窗口中

• 为您的应用程序提供名称
• 选择订阅
• 您可以创建一个新的资源组或使用现有的资源组
• 选择所需的操作系统
• 对于“发布”，选择“Docker 镜像”

下一步是选择“配置容器”并提供有关您要用于应用程序的 Docker 镜像的详细信息。默认情况下，“单个容器”处于活动状态。选择“Docker Hub”作为镜像注册表，或任何适用的注册表。选择您的注册表是私有的还是公开的，然后提供您的 Docker 镜像的名称。

单击“应用”后，您将被重定向到上一个页面。单击“创建”，部署将在进行一些短暂验证后开始。

部署完成后，您将收到一条通知。之后，如果您刷新“App Services”页面，新创建的应用将出现在列表中。

恭喜！！您已成功将应用程序作为 Docker 容器部署到 Microsoft Azure App Services。

测试应用程序

现在是时候检查您的应用程序是否真正正常工作了。从“App Services”页面，选择您的应用。然后，从概述窗格的右上角，获取应用程序的 URL。

在您喜欢的浏览器中打开该 URL，您应该会看到您的应用程序正在运行。这是我的

如果应用程序未正常工作，您首先要检查的是日志。为此，请转到“设置 > 容器设置”，您将看到日志。看起来是这样的

添加服务连接

为了让发布管道能够自动将您的应用程序部署到 Azure App Services，它需要访问 Azure 资源。

为了授予访问权限，请转到“项目属性 > 服务连接”，然后选择“新建服务连接”。

从列表中，选择“Azure Resource Manager”并填写接下来的模态窗口中的详细信息。选择“订阅”作为范围级别，然后选择您的订阅。之后，选择您为应用程序创建 App Service 的资源组。

Azure DevOps 发布管道

好的！现在是时候通过在 Azure 中创建发布管道来自动化我们的下一个发布了。转到 Azure DevOps，选择您的组织和项目。

在“Pipelines”下，选择“Releases”，然后单击“New pipeline”。让我们首先使用顶部的文本字段为您的管道命名。

添加生成构件

现在，让我们向管道添加一个构件。单击“Add an artifact”并选择“Docker Hub”作为源类型。从下拉列表中，选择我们在上一篇文章中设置的 Docker Hub 服务连接。

选择您希望为应用程序设置的命名空间和存储库。对于“默认版本”，您可以选择“Latest”或“Specify at the time of release creation”。这取决于您的需求。

如果您选择“Latest”，则必须确保在生成管道中始终将 Docker 镜像标记为“latest”。我更喜欢使用另一个选项。

向管道添加任务

现在我们需要向发布管道添加一个阶段。单击“Add a stage”并选择“Azure Web App on Container Deploy”并为其命名。然后切换到“Tasks”选项卡。

任务列表中的第一个条目是代理设置，我们将选择“Hosted Ubuntu 1604”作为代理池。其余的可以保留原样。

现在，选择第二个任务，在“Azure subscription”下，选择我们之前步骤中设置的服务连接。之后，它会为您提供可供选择的应用列表。最重要的是镜像名称。因此，请确保它与您在生成管道中设置的完全相同。

我们在这里差不多完成了。但是，还有一件事缺失了。我们还没有启用发布管道的自动触发器。现在让我们来做。

回到“Pipeline”选项卡。如果现在单击构件右上角的闪电符号，它将允许您启用持续部署触发器。所以，继续吧。

如果您愿意，还可以为触发器添加某些过滤器。但现在，我将保持简单。最后，保存发布管道。

测试 CI/CD 管道（端到端测试）

最后，是时候测试我们迄今为止所做的一切了。为此

• 更改应用程序中的某些内容
• 将更改推送到 master 分支
• 生成管道启动并将新镜像推送到 Docker Hub
• 推送到 Docker Hub 会触发发布管道
• 您应用程序的最新更改现在已可见

花点时间更改一些您可以用来验证一切是否正常的内容。事实上，您也可以查看 Azure App Service 的日志，以验证当前正在运行的是哪个 Docker 镜像标签。

例如，在上图的日志中，请注意用绿色方块突出显示的日志。这表明我设置的 Azure DevOps Pipelines 正在工作。

非常非常祝贺！！我们成功地实现了目标。

结论

首先，我们开发了一个基于 ASP.NET Core 的 Web 应用程序，并将代码放在 GitHub 存储库中。之后，我们设置了一个生成管道来自动构建我们应用程序的 Docker 镜像，然后将其推送到 Docker Hub。接下来，在本文中，我们创建了一个发布管道，以将我们的应用程序作为 Docker 容器自动部署到 Azure Web App 服务。

我希望您也一切顺利，但是，如果您在本系列文章的任何部分遇到问题，我将非常乐意为您提供帮助。

历史

• 2019 年 9 月 10 日：初始版本