最大的优势是它的跨平台能力。如果只需要在环境中部署 ASP.NET CORE 应用程序,IIS 也是一个不错的选择。 ASP.NET CORE 应用程序有两种 IIS 部署模式,这两种模式都依赖于 ASP.NET CORE Core 的 IIS 扩展模块。本文提供的示例演示已同步到《ASP.NET Core 6 – 实例演示版》)
一、ASP.NET CORE 核心
二、@ > 部署中模式
三、部署外模式
四、配置
一、ASP。 NET CORE 核心
IIS实际上是根据管道来处理请求的,但是IIS管道和ASP.NET CORE中间件管道有本质的区别。对于部署在 IIS 中的 Web 应用程序,处理流程被细分为从最初收到请求到最终发送响应的一系列固定步骤,每个步骤都有一个或两个(pre + post 设置)对应的事件或回调我们可以使用自定义注册的事件或回调在适当的时候接管请求并按照我们想要的方式处理它。
IIS提供了一系列(),我们也可以使用任何.NET语言编写托管,这个集成了IIS和ASP.NET CORE的ASP.NET CORE Core就是。它使用注册的事件来拦截来自 IIS 管道的请求,并将其转发到 ASP.NET CORE 管道进行处理。对应的安装包可以从这里下载。
二、@>部署中模式
ASP.NET CORE 有两种部署模式:In-和Out-of-under IIS。 In-mode ASP.NET CORE 应用程序在 IIS 工作进程 w3wp.exe 中运行(如果使用 IIS,则工作进程为 .exe)。如图18-7所示,该模式下ASP.NET CORE应用程序使用的服务器类型为,上面的ASP.NET CORE Core会将原来的请求转发给这个服务器,后者会产生响应并转发给 IIS 服务器回复。
图一部署模式
in-是默认的部署方式,所以我们不需要对此做任何设置,接下来我们将演示具体的部署方式。我们创建一个以 IIS 的默认站点(Web Site)命名的应用程序,并将映射的物理路径设置为“C:App”。然后我们创建一个空的 ASP.NET CORE 程序,编写如下演示程序,以当前进程名作为响应内容。
using System.Diagnostics;
var app = WebApplication.Create(args);
app.Run(context => context.Response.WriteAsync(Process.GetCurrentProcess().ProcessName));
app.Run();
然后我们在解决方案视图中右击项目,在弹出的菜单中选择“()”选项,并创建一个指向“C:App”的指针,然后执行这个就完成了发布工作。应用程序发布也可以通过执行命令行“”来完成。应用部署完成后,我们使用浏览器使用地址“”访问部署的应用。从图 2 所示的输出中,我们可以看到 ASP.NET CORE 应用程序实际上是在 IIS 工作进程中运行的。
图2 In-mode中的进程名称
如果我此时查看部署目录(“C:App”),将找到生成的程序集和配置文件。由于应用部署在 IIS 中,具体配置自然在 web.xml 中定义。该文件的内容如下所示。我们会发现所有请求(path=”*” verb=”*”)都映射到””,也就是上面介绍的ASP.NET CORE Core。至于这个,如果你启动ASP.NET CORE管道并与之交互,它是由后面的配置部分控制的,你可以看到它将代表部署模式的属性设置为“”。
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".App.dll" stdoutLogEnabled="false" stdoutLogFile=".logsstdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration>
In-mode 会注册以下内容,对应的配置选项定义在 .如果需要同步读写请求和响应正文内容,我们需要将属性(默认为False)设置为True。如果 ion 属性返回 True(默认值),则经过身份验证的用户将自动分配给上下文的 User 属性。我们可以使用 Size(默认为 1,048,57二、0@> 和 (默认为 30,000,00二、1@>)来设置接收请求体的缓冲区的容量,以及最大字节数请求正文。
二、2@>
二、3@>
目标注册在接口的如下扩展方法中实现。由于该方法没有提供委托参数对的配置选项设置,所以我们只好使用原来的来设置。由于该方法是由接口ults扩展方法在内部调用的,我们不需要为此做额外的工作。
二、4@ >
三、部署外模式
ASP.NET CORE 应用程序也可以在 IIS 中以 Out-of-Mode 方式部署,如图 3 所示,在这种部署下,所使用的 ASP.NET CORE 应用程序运行在单独的 .exe 进程中。当 IIS 收到对目标应用程序的请求时,如果目标应用程序所在的进程没有启动,ASP.NET CORE Core 也负责执行命令来激活这个进程,相当于充当 WAS ( )。
二、6@>
图 3 部署外模式
在激活 ASP.NET CORE 托管进程之前,ASP.NET CORE Core 会选择一个可用的端口号,该端口号和当前应用程序的路径(该路径将用于 ASP.NET CORE 应用程序)是写入环境变量,对应的环境变量名是“”和“”。在 Out-of-mode 中部署的 ASP.NET CORE 应用程序将只接收 IIS 转发给它的请求。为了过滤来自其他来源的请求,ASP.NET CORE Core 会生成一个 Token 并写入环境变量“”。后续转发的请求会使用一个“MS–TOKEN”来传递这个Token,ASP.NET CORE应用会检查是否匹配之前生成的Token。
ASP.NET CORE Core 也使用环境变量来传递一些其他的设置,认证方案写入环境变量“UTH”,另外一个“”环境变量用于设置对web的支持状态。由于这些环境变量名称的前缀都是“”,所以它们将被用作默认配置源。最终将绑定到基于该端口的本地端点(“”)进行侦听。由于监听地址是由 ASP.NET CORE Core 控制的,所以只需要将请求转发到这个地址,最后将收到的响应发送给 IIS 进行返回。由于这涉及到本地环回网络()的访问,其性能自然不如In-模式。
二、7@>
上面我们演示了In-的方法,现在我们直接修改配置文件web.,按照上面的方式设置配置节的属性为“”,应用自动切换到Out-of-。此时,以同样的方式再次访问已部署的应用程序,我们会发现浏览器上显示的进程名已经变成了“”。
二、8@>
图 4 Out-of-mode 中的进程名称
部署模式可以直接在项目文件中定义,如果如下通过设置el属性为””,web中的部署模式的设置。发布后生成的会相应改变。该属性的默认值为“”,我们也可以显式设置。
二、9@>
为了进一步验证上述一系列环境变量的存在,下图演示程序将响应环境变量以“”为前缀的内容输出。除此之外,进程名称、请求和“MS–TOKEN”标头作为响应输出。
using System.Diagnostics; using System.Text; var app = WebApplication.Create(args); app.Run(HandleAsync); app.Run(); Task HandleAsync(HttpContext httpContext) { var request = httpContext.Request; var configuration = httpContext.RequestServices.GetRequiredService(); var builder = new StringBuilder(); builder.AppendLine($"Process: {Process.GetCurrentProcess().ProcessName}"); builder.AppendLine($"MS-ASPNETCORE-TOKEN: {request.Headers["MS-ASPNETCORE-TOKEN"]}"); builder.AppendLine($"PathBase: {request.PathBase}"); builder.AppendLine("Environment Variables"); foreach (string key in Environment.GetEnvironmentVariables().Keys) { if (key.StartsWith("ASPNETCORE_")) { builder.AppendLine($"t{key}={Environment.GetEnvironmentVariable(key)}"); } } return httpContext.Response.WriteAsync(builder.ToString()); }
应用重新发布后,再次使用浏览器访问,得到如图5所示的结果。我们可以从这里找到上述环境变量。请求中携带的“MS–TOKEN”头与对应环境变量的值完全相同。 IIS中应用的虚拟目录作为应用路径写入环境变量,成为请求。如果站点提供 HTTPS 端点,它的端口也会写入“_PORT”环境变量,该变量旨在实现 HTTPS 端点的重定向。
图 5 Out-of-mode 中的环境变量
Out-of-的大部分实现都是由下面的中间件来完成的,也就是对应的配置选项。中间件完成对“ Token”的非IIS转发请求的认证和过滤。如果配置选项的 cate 属性返回 True(默认值),则此中间件从请求头“MS–”中提取客户端证书并将其保存在 e 属性中。中间件还将对应于当前帐户的对象附加到上下文的特征集中。如果配置选项的 ion 属性返回 True(默认值),则该对象将直接分配给上下文的 User 属性。
public class IISMiddleware { public IISMiddleware(RequestDelegate next, ILoggerFactory loggerFactory, IOptions options, string pairingToken, IAuthenticationSchemeProvider authentication, IHostApplicationLifetime applicationLifetime); public IISMiddleware(RequestDelegate next, ILoggerFactory loggerFactory, IOptions options, string pairingToken, bool isWebsocketsSupported, IAuthenticationSchemeProvider authentication, IHostApplicationLifetime applicationLifetime); public Task Invoke(HttpContext httpContext); public Task Invoke(HttpContext httpContext) }
public class IISOptions { public bool AutomaticAuthentication { get; set; } public string? AuthenticationDisplayName { get; set; } public bool ForwardClientCertificate { get; set; } }
IIS 使用 WAS 根据请求激活工作进程 w3wp.exe。如果站点长时间未访问,它还会自动关闭工作进程。如果工作进程全部关闭,则托管 ASP.NET CORE 应用程序的 .exe 进程也应关闭。为了关闭应用托管进程,ASP.NET CORE Core 会发送一个特殊的请求,该请求带有一个值为“”的“MS–EVENT”头,中间件在接收到该请求时会使用注入的时间对象关闭请求当前的应用程序。如果不支持,中间件也会去掉表示“可升级到双向通信”的特性。根据请求设置应用程序路径也是由这个中间件完成的。由于中间件所做的实际上是初始化上下文,所以必须先执行它才有意义。为了把这个中间件放在流水线的前端,定义如下来完成中间件的注册。
internal class IISSetupFilter : IStartupFilter { internal IISSetupFilter(string pairingToken, PathString pathBase, bool isWebsocketsSupported); public Action Configure(Action next); }
最终通过接口的如下扩展方法注册。该方法还负责从当前配置和环境变量中提取端口号,完成监听地址的注册。由于默认选择了注册到服务器的端点,所以该方法会使用配置将ure特性的属性设置为True,这里设置的监听地址就会生效。该方法还会根据当前IIS站点的设置进行相应的设置。由于接口ults扩展方法内部也调用了这个方法,所以我们不需要为此做额外的工作。
public static class WebHostBuilderIISExtensions { public static IWebHostBuilder UseIISIntegration(this IWebHostBuilder hostBuilder); }
四、配置
无论采用何种部署方式,相关配置都定义在部署目录中。 web. 文件提供了 ASP.NET CORE Core 的映射,使我们能够在 IIS 中部署 ASP.NET CORE 应用程序。在web.中,与ASP.NET CORE应用部署相关的配置在配置部分定义。
<aspNetCore processPath = "dotnet" arguments = ".App.dll" stdoutLogEnabled = "false" stdoutLogFile = ".logsstdout" hostingModel = "outofprocess" forwardWindowsAuthToken = "true" processesPerApplication = "10" rapidFailsPerMinute = "5" requestTimeout = "00:02:00" shutdownTimeLimit = "60" startupRetryCount = "3" startupTimeLimit = "60"> <environmentVariables> <environmentVariable name = "ASPNETCORE_ENVIRONMENT" value = "Development"/> </environmentVariables> <handlerSettings> <handlerSetting name = "stackSize" value = "2097152" /> <handlerSetting name = "debugFile" value = ".logsaspnetcore-debug.log" /> <handlerSetting name = "debugLevel" value = "FILE,TRACE" /> </handlerSettings> </aspNetCore>
上面的 XML 片段包含完整的配置属性,下表简要描述了这些属性。设置文件可以采用绝对路径和相对于部署目录的相对路径(用“.”表示)。
属性
意义
ASP.NET CORE应用启动命令所在路径,必填。
ASP.NET CORE应用启动时传入的参数,可选。
是否输出到属性指定的文件,默认为False。
日志文件作为输出,默认为“-”。
部署模式,“/”或“/”(默认)。
肯
是否转发认证令牌,默认为True。
离子
承载 ASP.NET CORE 应用程序的进程数( ),默认为 1。此配置对 In-mode 没有影响。
ASP.NET CORE 应用宿主进程( )每分钟允许崩溃的次数,默认为 10 次,超过后不再尝试重启。
请求处理超时,默认2分钟。
启动ASP.NET CORE应用托管进程的重试次数,默认为2次。
ASP.NET CORE 应用托管进程启动超时时间(以秒为单位),默认为 120 秒。
设置环境变量。
为 ASP.NET CORE Core 提供额外的配置。
暂无评论内容