先决条件
升级共享框架后,可随时重启服务器托管的ASP.NETCore应用。
通过应用发布和复制
配置应用以进行依赖框架的布署。
倘若应用在本地运行,且未配置为完善安全联接(HTTPS),则采用以下任一方式:
在开发环境中运行dotnetpublishlinux软件工程师,将应用打包到可在服务器上运行的目录中(比如bin/Release/{TARGETFRAMEWORKMONIKER}/publish,其中{TARGETFRAMEWORKMONIKER}占位符表示目标框架名子对象/TFM):
.NETCLI
dotnet publish --configuration Release
倘若不希望维护服务器上的.NETCore运行时,还可将应用发布为独立布署。
使用集成到组织工作流的工具(比如SCP、SFTP)将ASP.NETCore应用复制到服务器。一般可在var目录(比如var/www/helloapp)下找到Web应用。
备注
在生产布署方案中,持续集成工作流会执行发布应用并将资产复制到服务器的工作。
测试应用:
在命令行中运行应用:dotnet.dll。在浏览器中,导航到:
以确认应用在Linux本地正常运行。配置反向代理服务器
反向代理是为动态Web应用提供服务的常见设置。反向代理中止HTTP恳求,并将其转发到ASP.NETCore应用。
使用反向代理服务器
Kestrel特别适宜从ASP.NETCore提供动态内容。并且,Web服务功能不像服务器(如IIS、Apache或Nginx)那样功能丰富。反向代理服务器可以卸载HTTP服务器的工作负载,如提供静态内容、缓存恳求、压缩恳求和HTTPS终端。反向代理服务器可能留驻在专用计算机上,也可能与HTTP服务器一起布署。
鉴于此手册的目的,使用Nginx的单个实例。它与HTTP服务器一起运行在同一服务器上。按照要求,可以选择不同的设置。
因为恳求通过反向代理转发,因而使用Microsoft.AspNetCore.HttpOverrides包中的转接头中间件。此中间件使用X-Forwarded-Proto焦段来更新Request.Scheme,使重定向URI和其他安全策略才能正常工作。
转接头中间件应在其他中间件之前运行。此次序可确保依赖于转接头信息的中间件可以使用康泰时值进行处理。若要在确诊和错误处理中间件后运行转接头中间件,请参阅转接头中间件次序。
调用其他中间件之前,请先在Startup.Configure的基础上调用UseForwardedHeaders技巧。配置中间件以转接X-Forwarded-For和X-Forwarded-Proto焦段:
C#
using Microsoft.AspNetCore.HttpOverrides;
...
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
app.UseAuthentication();
假如没有为中间件指定ForwardedHeadersOptions,则要转接的默认康泰时为None。
默认情况下linux服务器安全,在环回地址(127.0.0.0/8,[::1])(包括标准localhost地址(127.0.0.1))上运行的代理受信任。假如组织内的其他受信任代理或网路处理Internet与Web服务器之间的恳求,请使用ForwardedHeadersOptions将其添加到KnownProxies或KnownNetworks的列表。以下示例会将IP地址为10.0.0.100的受信任代理服务器添加到Startup.ConfigureServices中的转接头中间件KnownProxies:
C#
using System.Net;
...
services.Configure(options =>
{
options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});
有关详尽信息,请参阅配置ASP.NETCore以使用代理服务器和负载均衡器。
安装Nginx
使用apt-get安装Nginx。安装程序将创建一个systemdinit脚本,该脚本运行Nginx,作为系统启动时的守护程序。根据以下网站上的Ubuntu安装说明操作:Nginx:官方Debian/Ubuntu包。
备注
假如须要可选Nginx模块,则可能须要从源代码生成Nginx。
由于是首次安装Nginx,通过运行以下命令显式启动:
Bash
sudo service nginx start
确认浏览器显示Nginx的默认登录页。可在/index.nginx-debian.html访问登入页面。
配置Nginx
若要将Nginx配置为反向代理以将HTTP恳求转发到ASP.NETCore应用程序,请更改/etc/nginx/sites-available/default。在文本编辑器中打开它,并将内容替换为以下代码片断:
nginx
server {
listen 80;
server_name example.com *.example.com;
location / {
proxy_pass http://127.0.0.1:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
倘若应用是SignalR或BlazorServer应用,请分别参阅SignalRASP.NETCore生产托管和缩放和托管和布署ASP.NETCoreBlazorServer以了解详尽信息。
当没有匹配的server_name时,Nginx使用默认服务器。假如没有定义默认服务器,则配置文件中的第一台服务器是默认服务器。最佳做法是,添加一个特定的默认服务器,它会在配置文件中返回状态代码444。默认的服务器配置示例是:
nginx
server {
listen 80 default_server;
# listen [::]:80 default_server deferred;
return 444;
}
使用上述配置文件和默认服务器,Nginx接受主机康泰时或*.端口80上的公共流量。与这种主机不匹配的恳求不会转发到Kestrel。Nginx将匹配的恳求转发到:5000中的Kestrel。有关详尽信息,请参阅nginx怎样处理恳求。要修改Kestrel的IP/端口,请参阅Kestrel:终结点配置。
警告
无法指定正确的server_name指令会公开应用的安全漏洞。假如可控制整个父域(区别于易受功击的*.com),则子域键值绑定(比如,*.)不具有此安全风险。
完成配置Nginx后,运行sudonginx-t来验证配置文件的句型。假如配置文件测试成功,可以通过运行sudonginx-sreload强制Nginx选定修改。
要直接在服务器上运行应用:
请导航到应用目录。运行应用:dotnet,其中app_assembly.dll是应用的程序集文件名。
倘若应用在服务器上运行,但未能通过Internet响应,请检测服务器的防火墙,确认端口80已打开。假如使用AzureUbuntuVM,请添加启用入站端口80流量的网路安全组(NSG)规则。不须要启用出站端口80规则,由于启用入站规则后会手动许可出站流量。
完成应用测试后,请在命令提示符处按Ctrl+C关掉应用。
监视应用
服务器设置为将对:80发起的恳求转发到在:5000中的Kestrel上运行的ASP.NETCore应用。并且,未将Nginx设置为管理Kestrel进程。systemd可用于创建服务文件以启动和监视基础Web应用。systemd是一个初始系统,可以提供启动、停止和管理进程的许多强悍的功能。
创建服务文件
创建服务定义文件:
Bash
sudo nano /etc/systemd/system/kestrel-helloapp.service
以下示例是应用的服务文件:
ini
[Unit]
Description=Example .NET Web API App running on Ubuntu
[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
[Install]
WantedBy=multi-user.target
在上面的示例中,管理服务的用户由User选项指定。用户(www-data)必须存在而且拥有正确应用文件的所有权。
使用TimeoutStopSec配置在收到初始中断讯号后等待应用程序关掉的持续时间。倘若应用程序在此时间段内未关掉,则将发出SIGKILL以中止该应用程序。提供作为无单位秒数的值(比如,150)、时间跨径值(比如北京linux培训,2min30s)或infinity以禁用超时。TimeoutStopSec默认为管理器配置文件(systemd-system.conf,system.conf.d,systemd-user.conf,user.conf.d)中DefaultTimeoutStopSec的值。大多数分发版的默认超时时间为90秒。
# The default value is 90 seconds for most distributions.
TimeoutStopSec=90
Linux具有分辨大小写的文件系统。将ASPNETCORE_ENVIRONMENT设置为Production时,将搜索配置文件appsettings.Production.json,而不搜索appsettings.production.json。
必须通配符个别值(比如,SQL联接字符串)以供配置提供程序读取环境变量。使用以下命令生成适当的通配符值以供在配置文件中使用:
控制台
systemd-escape ""
环境变量名不支持逗号(:)分隔符。使用双顿号(__)取代逗号。环境变量读入配置时,环境变量配置提供程序将双顿号转换为逗号。以下示例中,联接字符串秘钥ConnectionStrings:DefaultConnection以ConnectionStrings__DefaultConnection方式设置到服务定义文件中:
Environment=ConnectionStrings__DefaultConnection={Connection String}
保存该文件并启用该服务。
Bash
sudo systemctl enable kestrel-helloapp.service
启用该服务,并确认它正在运行。
sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service
◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
CGroup: /system.slice/kestrel-helloapp.service
└─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
在配置了反向代理并通过systemd管理Kestrel后,Web应用现已完全配置,并能在本地计算机上的浏览器中从进行访问。也可以从远程计算机进行访问,同时限制可能进行制止的任何防火墙。检测响应康泰时,Server康泰时显示由Kestrel所提供的ASP.NETCore应用。
text
HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
查看日志
使用Kestrel的Web应用是通过systemd进行管理的linux服务器安全,因而所有风波和进程都被记录到集中日志。并且,此日志包含由systemd管理的所有服务和进程的全部条目。若要查看特定于kestrel-helloapp.service的项,请使用以下命令:
Bash
sudo journalctl -fu kestrel-helloapp.service
有关进一步筛选,使用时间选项(如--sincetoday、--until1hourago)或那些选项的组合可以降低返回的条目数。
Bash
sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"
数据保护
ASP.NETCore数据保护堆栈由多个ASP.NETCore中间件(包括cookie中间件等身分验证中间件)和跨站点恳求伪造(CSRF)保护使用。虽然用户代码不调用数据保护API,也应当配置数据保护,以创建持久的加密秘钥储存。倘若不配置数据保护,则秘钥储存在显存中。重启应用时,秘钥会被遗弃。
假如秘钥环储存于显存中,则在应用重启时:
若要配置数据保护以持久保存并加密秘钥环,请参阅:
较长的恳求康泰时数组
代理服务器默认设置一般将恳求康泰时数组限制为4K或8K,具体取决于平台。个别应用可能须要超过默认值的数组(比如,使用AzureActiveDirectory的应用)。假如须要更长的数组,则代理服务器的默认设置须要进行调整。要应用的值具体取决于方案。有关详尽信息,请参见服务器文档。
警告
除非必要,否则不要提升代理缓冲区的默认值。增强这种值将降低缓冲区溢出的风险和恶意用户的拒绝服务(DoS)功击风险。
保护应用启用AppArmor
Linux安全模块(LSM)是一个框架,它是自Linux2.6后的Linuxkernel的一部份。LSM支持安全模块的不同实现。AppArmor是实现强制访问控制系统的LSM,它容许将程序限制在一组有限的资源内。确保已启用并成功配置AppArmor。
配置防火墙
关掉所有未使用的外部端口。通过为配置防火墙提供CLI,不复杂的防火墙(ufw)为iptables提供了后端。
警告
假如未正确配置,防火墙将制止对整个系统的访问。在使用SSH进行联接时,无法指定正确的SSH端口最终会将你关在系统之外。默认端口为22。
安装ufw,并将其配置为容许所需任何端口上的流量。
Bash
sudo apt-get install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
保护Nginx修改Nginx响应名称