使用 teamcity 将 dotnet 核心部署到 azure 应用服务 [英] dotnet core deployment to azure app service using teamcity

问题描述

我有一个 dotnet 核心应用程序.我正在teamcity中建立管道.一旦teamcity检测到源代码的变化，它就会下载源代码运行dotnet 还原dotnet 构建

I have a dotnet core app. I am building a pipeline in teamcity. and once the teamcity detects the change in the cource code, It downloads the source code runs dotnet restore dotnet build

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

and copies the content in the output folder to Azure app service.

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

I believe to run the app i need to run the command dotnet nameoftheprojectdll.dll

但是我怎样才能在应用服务上运行这个命令.我需要将此命令作为构建脚本的一部分运行.

but how can I run this command on the app service. and I need to run this command as part of a build script.

推荐答案

The Short Answer

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

The Short Answer

You need to use the dotnet publish command to package your application for IIS deployment, and copy that output (not the output from dotnet build) to the host. Your build infrastructure in TeamCity will never be responsible for hosting and/or running your application, so you do not need dotnet run *.dll anywhere in your build scripts. Rather, when your application is properly published to Azure Web Apps, IIS will read the web.config and automatically host your application (likely using the ASP.NET Core Module).

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

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

Before we discuss how to properly publish an ASP.NET Core application, it's important to understand at a high level how your application is hosted. ASP.NET Core, unlike classic ASP.NET, is "self hosted." What this means is that your web application is just a simple .NET Core Console Application, and can be started like any other .NET Core application with dotnet run webapp.dll. When your application runs, it starts up a web server, called Kestrel, in process.

在 Program.cs 的主要方法中，你可能有这样的东西:

In your main method in Program.cs, you probably have something like this:

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

host.Run();

在这里您可以看到您的应用正在启动 Kestrel 网络服务器以侦听传入请求并在您的应用中处理它们.当您dotnet 运行 webapp.dll 时，您将直接启动您的应用(和 Kestrel).

Here you can see that your app is starting up the Kestrel web server to listen to incoming requests and process them in your app. When you dotnet run webapp.dll, you're starting up your app (and Kestrel) directly.

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

However, Kestrel is not intended to be a public-facing web server. When you run your app in production, you should run it behind a production-ready web server like IIS. Azure Web Apps is simply using IIS to host your application. When an incoming request reaches your app in Azure Web Apps, IIS receives the request and proxies it to Kestrel, which then passes it off to your application for processing.

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

The ASP.NET Core Module, a native IIS module, is the component in IIS that is responsible for starting your application, keeping it alive (and restarting it if it crashes), and proxying requests to Kestrel. So, when running your app in Azure Web Apps, the dotnet run command is never used. Rather, the ASP.NET Core Module is used to run your application.

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

The ASP.NET Core Module is configured in your web.config file (and by the call to UseIISIntegration above):

<system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout" forwardWindowsAuthToken="false" />
  </system.webServer>

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

So, in order to run your application in IIS (like in Azure Web Apps), you must have a properly configured web.config file alongside the application package you deploy. More on that in a bit.

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

Before automating your build system in TeamCity, it's worthwhile to validate all the steps in your deployment process. Let's assume your application is in C:/MyApp/src/WebApp/.

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

First, as you noted, you need to restore all the dependencies for your application.

C:/MyApp/src/WebApp> dotnet restore

其次，您可以选择构建应用程序以确保没有编译错误.

Second, and optionally, you can build your application to make sure there are no compilation errors.

C:/MyApp/src/WebApp> dotnet build

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

As I mentioned, that last step is actually optional; the next step, dotnet publish, will also build for you, so it's unnecessary to use the build step in your automation.

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

Third, you need to publish your application. This was the crucial step you were missing in preparing your application. The dotnet publish command packs your application and all its dependencies into a folder that is suitable for deployment.

C:/MyApp/src/WebApp> dotnet publish

这将打包您的应用程序以进行部署，将输出放入C:MyAppsrcWebAppinDebug etcoreapp1.1publish 等文件夹中.在生产构建自动化中执行此操作时，您希望使用 dotnet publish --configuration Release 在发布模式中构建，而不是调试模式.

This will package your application for deployment, putting the output in a folder like C:MyAppsrcWebAppinDebug etcoreapp1.1publish. When doing this in your production build automation, you want to use dotnet publish --configuration Release to build in Release, not Debug, mode.

此 /publish 文件夹中的输出是您需要部署到 Azure Web 应用程序的内容.这样做有很多选择，包括 FTP、Xcopy 或 Web 部署.

The output in this /publish folder is what you need to deploy to Azure Web Apps. There are many options for doing so, including FTP, Xcopy, or Web Deploy.

最后要注意的是，为 IIS 准备应用程序实际上还涉及一个步骤.publish-iis 工具应该用于配置 ASP.NET Core 模块.使用此工具可确保您的 web.config 为 IIS 正确配置.如果您从模板创建应用程序，您可能会看到它已在您的 project.json 中配置为在每次 dotnet 发布 后自动运行:

As a final note, there's actually one more step involved in preparing your app for IIS. The publish-iis tool should be used to configure the ASP.NET Core Module. Using this tool ensures that your web.config is properly configured for IIS. If you created your app from a template, you'll probably see that it has already been configured in your project.json to automatically run after every dotnet publish:

"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]

总而言之，发布应用只需要做三件事:

In summary, there are only really three things you need to do to publish your app:

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

构建 TeamCity 管道

听起来您已经有使用 TeamCity 的经验，因此我不会深入探讨如何设置必要的构建步骤.不过，概括地说，以下是您需要构建配置的步骤:

Building a TeamCity Pipeline

It sounds like you already have experience working with TeamCity, so I won't delve too deeply in how to do set up the necessary build steps. At a high level, though, here are the steps you'd need the build configuration:

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

1. Run dotnet restore
2. Run dotnet publish. I like to manually specify the output directory, like so: dotnet publish --configuration Release --output %teamcity.build.checkoutDir%.publish. This makes it really easy to add .publish as an artifact path on my build configuration so TeamCity keeps a permanent record of the output that was deployed.
3. Deploy the published output to Azure Web Apps. I'm guessing you're using FTP deployment, so you can use Team City's built-in FTP upload step.

关于使用 TeamCity 的几点总结:

A few closing thoughts about using TeamCity:

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

While all the .NET Core SDK commands (dotnet *) can be simply run with a Command Line build step, I use and highly recommend the TeamCity .NET Core Plugin: https://github.com/JetBrains/teamcity-dotnet-plugin This plugin, developed by JetBrains themselves, makes it super easy to run the dotnet commands against your app.

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

If you are using a file upload method (FTP/Xcopy) to deploy your app, I'd urge you to consider using Web Deploy. When you use Web Deploy (msdeploy.exe), the engine will do a diff and only deploy the files that have changed. This significantly speeds up your deployment process. It will also automatically create an app_offline.htm file for you while the deployment is happening, so IIS never serves requests while you're in the process of copying files to Azure.

最后，如果可以选择，将持续部署到 Azure Web 应用暂存槽，而不是直接部署到生产网站.这将使您能够在真实用户之前测试您的应用程序，并且您可以在将其切换到生产环境之前预热您的网站.

Finally, if you have the option, do your continuous deployments to an Azure Web Apps Staging Slot, instead of directly to your production website. This will let you test your application before real users do, and you can warm up your site before swapping it in to production.

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

I highly recommend reading through the ASP.NET docs (https://docs.microsoft.com/en-us/aspnet/core/); there's a lot of great stuff there.

• 发布到 IIS
• 部署到 Azure 应用服务
• dotnet-publish 命令
• IISIntegration 和 publish-iis 工具
• TeamCity DotNet 插件
• ASP.NET 核心模块
• 部署到 IIS 的参考应用

这篇关于使用 teamcity 将 dotnet 核心部署到 azure 应用服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！