使用 teamcity 将 dotnet core 部署到 azure 应用程序服务

won*_*all 1 teamcity continuous-deployment .net-core azure-web-app-service

我有一个 dotnet 核心应用程序。我正在 teamcity 中构建管道。一旦 teamcity 检测到源代码中的更改,它就会下载源代码并运行 dotnet Restore dotnet build

并将输出文件夹中的内容复制到 Azure 应用服务。

我相信要运行应用程序,我需要运行命令 dotnet nameoftheprojectdll.dll

但我如何在应用程序服务上运行此命令。我需要将此命令作为构建脚本的一部分运行。

Rya*_*ann 5

简短的回答

您需要使用该dotnet publish命令打包应用程序以进行 IIS 部署,并将该输出(而不是 的输出dotnet build)复制到主机。TeamCity 中的构建基础架构永远不会负责托管和/或运行您的应用程序,因此您不需要dotnet run *.dll构建脚本中的任何位置。相反,当您的应用程序正确发布到 Azure Web Apps 时,IIS 将读取web.config并自动托管您的应用程序(可能使用 ASP.NET Core 模块)。


对于本答案的其余部分,我将假设您的应用程序是在 .NET Core 上运行的 ASP.NET Core 应用程序。

ASP.NET Core 托管模型

在我们讨论如何正确发布 ASP.NET Core 应用程序之前,重要的是要从高层次了解应用程序的托管方式。与经典 ASP.NET 不同,ASP.NET Core 是“自托管”的。这意味着您的 Web 应用程序只是一个简单的 .NET Core 控制台应用程序,并且可以像任何其他使用 .NET Core 应用程序一样启动dotnet run webapp.dll。当您的应用程序运行时,它会启动一个名为 Kestrel 的 Web 服务器。

在你的 main 方法中Program.cs,你可能有这样的东西:

var host = new WebHostBuilder()
   .UseContentRoot(Directory.GetCurrentDirectory())
   .UseIISIntegration()
   .UseKestrel()
   .UseStartup<Startup>()
   .Build();

host.Run();
Run Code Online (Sandbox Code Playgroud)

在这里您可以看到您的应用程序正在启动 Kestrel Web 服务器来侦听传入请求并在您的应用程序中处理它们。当您 时dotnet run webapp.dll,您将直接启动您的应用程序(和 Kestrel)。

然而,Kestrel 无意成为面向公众的 Web 服务器。当您在生产中运行应用程序时,您应该在生产就绪的 Web 服务器(例如 IIS)后面运行它。Azure Web Apps 只是使用 IIS 来托管您的应用程序。当传入请求到达 Azure Web Apps 中的应用程序时,IIS 会接收该请求并将其代理到 Kestrel,然后 Kestrel 将其传递给您的应用程序进行处理。

ASP.NET Core 模块是一个本机 IIS 模块,是 IIS 中的组件,负责启动应用程序、使其保持活动状态(如果崩溃则重新启动它)以及将请求代理到 Kestrel。因此,在 Azure Web Apps 中运行应用程序时,dotnet run永远不会使用该命令。相反,ASP.NET Core 模块用于运行您的应用程序。

ASP.NET Core 模块在您的web.config文件中进行配置(并通过上面的调用UseIISIntegration):

<system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
Run Code Online (Sandbox Code Playgroud)

因此,为了在 IIS 中运行应用程序(如在 Azure Web Apps 中),您必须在web.config部署的应用程序包旁边有一个正确配置的文件。稍后会详细介绍。

发布 ASP.NET Core 应用程序

在 TeamCity 中自动化构建系统之前,有必要验证部署过程中的所有步骤。我们假设您的应用程序位于C:/MyApp/src/WebApp/.

首先,正如您所指出的,您需要恢复应用程序的所有依赖项。

C:/MyApp/src/WebApp> dotnet restore
Run Code Online (Sandbox Code Playgroud)

其次,您可以选择构建应用程序以确保不存在编译错误。

C:/MyApp/src/WebApp> dotnet build
Run Code Online (Sandbox Code Playgroud)

正如我提到的,最后一步实际上是可选的;下一步,dotnet publish也将为您构建,因此无需在自动化中使用构建步骤。

第三,您需要发布您的申请。这是您在准备申请时缺少的关键步骤。该dotnet publish命令将您的应用程序及其所有依赖项打包到适合部署的文件夹中。

C:/MyApp/src/WebApp> dotnet publish
Run Code Online (Sandbox Code Playgroud)

这将打包您的应用程序以进行部署,并将输出放入诸如C:\MyApp\src\WebApp\bin\Debug\netcoreapp1.1\publish. 在生产构建自动化中执行此操作时,您希望使用dotnet publish --configuration Release“发布”模式而不是“调试”模式进行构建。

此文件夹中的输出/publish是部署到 Azure Web Apps 所需的内容。有许多选项可以实现此目的,包括 FTP、Xcopy 或 Web Deploy。

最后一点,为 IIS 准备应用程序实际上还涉及一个步骤。该publish-iis工具应用于配置 ASP.NET Core 模块。使用此工具可确保您的web.configIIS 已正确配置。如果您从模板创建应用程序,您可能会发现它已在您的应用程序中配置project.json为在以下时间后自动运行dotnet publish

"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
Run Code Online (Sandbox Code Playgroud)

总之,发布应用程序实际上只需要执行三件事:

  1. dotnet restore
  2. dotnet publish --configuration Release
  3. 将发布输出复制到 Azure Web Apps

构建 TeamCity 管道

听起来您已经拥有使用 TeamCity 的经验,因此我不会深入研究如何设置必要的构建步骤。不过,在较高层面上,以下是您需要构建配置的步骤:

  1. 跑步dotnet restore
  2. 跑步dotnet publish。我喜欢手动指定输出目录,如下所示:dotnet publish --configuration Release --output %teamcity.build.checkoutDir%\.publish. 这使得.publish在我的构建配置上添加工件路径变得非常容易,因此 TeamCity 可以永久记录已部署的输出。
  3. 将发布的输出部署到 Azure Web Apps。我猜您正在使用 FTP 部署,因此您可以使用 Team City 的内置 FTP 上传步骤。

关于使用 TeamCity 的一些总结性想法:

虽然所有 .NET Core SDK 命令 ( dotnet *) 都可以通过命令行构建步骤简单地运行,但我使用并强烈推荐 TeamCity .NET Core 插件: https: //github.com/JetBrains/teamcity-dotnet-plugin 此插件由 JetBrains 自己开发,使针对您的应用程序运行dotnet命令变得非常容易。

如果您使用文件上传方法(FTP/Xcopy)来部署您的应用程序,我强烈建议您考虑使用 Web Deploy。当您使用 Web 部署 (msdeploy.exe) 时,引擎将进行比较并仅部署已更改的文件。这显着加快了您的部署过程。它还会app_offline.htm在部署过程中自动为您创建一个文件,因此当您将文件复制到 Azure 的过程中,IIS 绝不会处理请求。

最后,如果可以选择,请将持续部署到 Azure Web Apps Staging Slot,而不是直接部署到生产网站。这将使您可以在真正的用户之前测试您的应用程序,并且您可以在将其切换到生产环境之前预热您的站点。


资源

我强烈建议阅读 ASP.NET 文档 ( https://learn.microsoft.com/en-us/aspnet/core/ );那里有很多很棒的东西。