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

问题描述

我有一个dotnet核心应用程序。我正在建立团队合作的渠道。并且一旦teamcity在库仑代码中检测到更改，它就会下载源代码并运行
dotnet恢复
dotnet构建

并将其内容复制到

我相信要运行该应用程序，我需要运行命令
dotnet nameofprojectproject.dll

但是我如何在应用程序服务上运行此命令。并且我需要在构建脚本中运行该命令。

解决方案

简短答案

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

---

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

ASP.NET Core托管模型

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

在您的 Program.cs ，您可能会有这样的内容：

  var host = new WebHostBuilder（）
 .UseContentRoot（ Directory.GetCurrentDirectory（））
 .UseIISIntegration（）
 .UseKestrel（）
 .UseStartup< Startup>（）
 .Build（）; 
 
 host.Run（）; 
  

在这里您可以看到您的应用正在启动Kestrel Web服务器以侦听传入的请求并进行处理他们在您的应用程序。当您时，您是在直接启动应用程序（和Kestrel）。

但是，Kestrel不能用作面向公众的Web服务器。在生产环境中运行应用程序时，应在IIS等可生产环境的Web服务器上运行它。 Azure Web Apps只是使用IIS托管应用程序。当传入的请求到达您在Azure Web Apps中的应用程序时，IIS接收到该请求并将其代理到Kestrel，然后将其传递给您的应用程序进行处理。

ASP .NET Core模块是本机IIS模块，是IIS中的组件，负责启动您的应用程序，使其保持活动状态（并在崩溃时重新启动）以及将请求代理到Kestrel。因此，在Azure Web Apps中运行应用程序时，永远不会使用 dotnet run 命令。而是使用ASP.NET Core模块运行您的应用程序。

ASP.NET Core模块是在 web.config <中配置的/ code>文件（以及通过上面的 UseIISIntegration 的调用）：

 < system.webServer> 
< handlers> 
<添加名称= aspNetCore path = *动词= * modules = AspNetCoreModule resourceType =未指定 /> 
< / handlers> 
< aspNetCore processPath =％LAUNCHER_PATH％ arguments =％LAUNCHER_ARGS％ stdoutLogEnabled = false stdoutLogFile =。\logs\stdout forwardWindowsAuthToken = false /> 
< /system.webServer> 
  

因此，要在IIS中运行应用程序（例如在Azure Web Apps中），正确配置的 web.config 文件以及您部署的应用程序包。

发布ASP.NET Core应用程序

在以下版本中自动化构建系统之前TeamCity，值得验证您部署过程中的所有步骤。假设您的应用程序位于 C：/ MyApp / src / WebApp / 中。

首先，如您所述，您需要恢复应用程序的所有依赖关系。

  C：/ MyApp / src / WebApp> dotnet restore 
  

第二，您可以选择构建您的应用程序以确保没有编译错误。

  C：/ MyApp / src / WebApp>正如我所提到的，最后一步实际上是可选的；如前所述，dotnet构建
  

下一步， dotnet发布也将为您构建，因此不必要在自动化中使用构建步骤。

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

  C：/ MyApp / src / WebApp> dotnet publish 
  

这将打包您的应用程序以进行部署，并将输出放置在<$ c $之类的文件夹中c> C：\MyApp\src\WebApp\bin\Debug\netcoreapp1.1\发布。在生产构建自动化中执行此操作时，您要使用 dotnet publish --configuration Release 来以Release（而非调试）模式进行构建。

此 / publish 文件夹中的输出是您需要部署到Azure Web Apps的输出。这样做有很多选择，包括FTP，Xcopy或Web Deploy。

最后一点，实际上，为IIS准备应用程序还需要再走一步。 publish-iis 工具应用于配置ASP.NET Core模块。使用此工具可确保为IIS正确配置 web.config 。如果您是通过模板创建的应用程序，则可能会发现它已在 project.json 中配置为在每个 dotnet之后自动运行发布：

 发布后：[[dotnet publish-iis --publish-folder％publish ：OutputPath％--framework％publish：FullTargetFramework％] 
  

总的来说，实际上只有三个发布应用程序所需要做的事情：

1. dotnet恢复


2. dotnet发布-配置发布


3. 将发布输出复制到Azure Web Apps

构建TeamCity管道

听起来您已经有使用TeamCity的经验，所以我不会太深入地研究如何设置必要的构建步骤。不过，在较高的层次上，这是您需要进行构建配置的步骤：

1. 运行 dotnet restore


2. 运行 dotnet发布。我喜欢手动指定输出目录，如下所示： 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 命令变得非常容易。 / p>

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

最后，如果可以选择的话，请连续部署到Azure Web Apps Staging插槽，而不是直接部署到生产网站。这样一来，您就可以在实际用户之前测试您的应用程序，并且可以在将站点换成生产版之前对其进行热身。

---

< h2>资源

我强烈建议您阅读ASP.NET文档（ https://docs.microsoft.com/en-us/aspnet/core/ ）；

• 发布到IIS


• 部署到Azure应用服务


• dotnet发布命令


• IISIntegration和publish-iis工具


• TeamCity DotNet插件
  
• ASP.NET核心模块


• 要部署到IIS的参考应用程序

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

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

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

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).

---

For the remainder of this answer, I'm going to assume that your application is an ASP.NET Core application running on .NET Core.

ASP.NET Core Hosting Model

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.

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();

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.

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.

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.

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=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>

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.

Publishing an ASP.NET Core Application

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

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.

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

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

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.

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. Copy publish output to Azure Web Apps

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. 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.

A few closing thoughts about using TeamCity:

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.

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.

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.

---

Resources

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.

• Publishing to IIS
• Deploying to Azure App Service
• dotnet-publish command
• IISIntegration and the publish-iis tool
• TeamCity DotNet Plugin
• ASP.NET Core Module
• Reference application to deploy to IIS

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