快速掌握Nginx(三) —— Nginx+Systemd托管netcore应用

  以前dotnet web应用程序开发完成后,我们都是使用IIS部署在Windows Server上,如今netcore技术发展迅速,因为其跨平台的特性,将dotnet web应用程序部署在更方便部署和更廉价的Linux服务器上日益流行。这里简单介绍如何使用Nginx/Systemd/Kestrel将netcore web应用程序部署在Centos系统上。将会涉及两个概念:反向代理和负载均衡。

1.Nginx/Systemd/Kestrel托管netcore应用

1.1 准备netcore web应用

  首先创建一个netcore mvc项目,修改 Startup.cs,添加了加粗部分代码,如下:

public class Startup
    {
        public Startup(IConfiguration configuration)
        {
          
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            
            services.Configure<CookiePolicyOptions>(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });
            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
        }
        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }
            //转接头中间件
            app.UseForwardedHeaders(new ForwardedHeadersOptions
            {
                ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
            });

            app.UseStaticFiles();
            app.UseCookiePolicy();

            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");
            });
        }
    }

修改Program.cs,如下:

    public class Program
    {
        public static void Main(string[] args)
        {

            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args)
        {
            //添加额外的配置
            var cfg = new ConfigurationBuilder().SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("appsettings.json")
                .AddJsonFile("hosting.json")
                .Build();

            return WebHost.CreateDefaultBuilder(args)
                .UseConfiguration(cfg)
                .UseStartup<Startup>();
        }
    }

hosting.json主要是为了设置部署的端口,内容如下

{ "server.urls": "http://0.0.0.0:1111"}

这里只是演示部署,HomeController和Index的逻辑很简单,仅仅展示X-Forwarded-For和Host主机:

 //HomeController  
    public class HomeController : Controller
    {
        public IActionResult Index()
        {
       //X-Forwarded-For可用于获取真实的客户端IP,格式为IP1,IP2...,其中第一个IP就是客户端IP,中间的为代理服务器IP ViewBag.xfor = Request.Headers["X-Forwarded-For"]; ViewBag.host = Request.Headers["Host"]; return View(); } } //Index View
<div class="text-center"> <h1 style="background-color:aquamarine" class="display-4">欢迎来到 Site1 </h1> <h3> X-Forwarded-For: @ViewBag.xfor</h3><br /> <h3> Host: @ViewBag.host</h3> <br /> </div>

  发布项目,将发布文件传输到Centos的/var/www/MySite1目录下(也可以放在其他地方),到/var/www/MySit1目录下,执行cli命令 dotnet MySite.dll ,如果可以成功启动表示编码没问题,到这里准备工作就结束了。

1.2 Systemd托管dotnet web应用

  在Windows上部署时,如果不使用IIS进行部署的话,我们一般把netcore应用部署成window服务,因为部署成服务可以实现开机自启,也比较稳定。在Linux部署时也最好部署成服务(守护进程),这里采用Systemd将dotnet web应用部署成服务,本篇的底部有Systemd简单介绍,如果不了解的园友可以看一下。首先  cd /usr/lib/systemd/system/ 到Unit配置文件目录下,创建一个配置文件,名字为 kestrel-mysite1.service,内容如下:

[Unit]
#简单描述
Description=run MySite on Centos

[Service]
#工作目录
WorkingDirectory=/var/www/MySite1
#开启时执行的命令
ExecStart=/usr/bin/dotnet /var/www/MySite1/MySite.dll
#只有出错时重启,Restart=always表示无论什么原因造成服务停止都会重启
Restart=on-failure#服务崩溃时,十秒钟重启一次
RestartSec=10
#用户
User=wyy

[Install]
#该服务所在的target
#这里符号链接放在/usr/lib/systemd/system/multi-user.target.wants目录下
WantedBy=multi-user.target

  然后通过命令 systemctl daemon-reload 重新加载配置文件,使用 systemctl start kestrel-mysite1 启动服务。通过命令启动服务不一定成功,使用 systemctl status kestrel-mysite1 查看服务运行情况,效果如下:

  到这里我们已经将netcore项目部署成一个服务了,dotnet web应用运行在Kestrel服务器上(我们安装netcore环境时会自动安装kestrel服务器),接下来使用Nginx实现反向代理和负载均衡。

1.3 Nginx实现反向代理

  首先介绍一下反向代理的概念。有反向代理就有前向代理,前向代理作为客户端的代理,将从互联网上获取的资源返回给一个或多个的客户端,服务端(如Web服务器)只知道代理的IP地址而不知道客户端的IP地址;而反向代理是作为服务器端(如Web服务器)的代理使用,而不是客户端,客户端知道代理服务器IP地址而不知道具体后台服务器的IP地址。简单的讲,我们在公司通过代理服务器访问外网,这里代理服务器属于前向代理服务器,而客户通过代理服务器从外网访问我们公司的服务器,这里的代理服务器就是反向代理服务器。Nginx实现反向代理很简单,使用一个proxy_pass指令将请求转发给指定的后台服务器即可。

  通过 vim /usr/local/nginx/conf/nginx.conf 编辑nginx配置,修改nginx配置如下:

worker_processes 2;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    sendfile      on;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    server{
        listen     80  ;
        server_name default_server;
        location /{
                root html;
                index index.html;
                }


        }

#加载vhosts目录下所有配置
include vhosts/* ;
}

通过 vim /usr/local/nginx/conf/vhosts/www.mysite.com 编辑www.mysite.com配置文件如下, proxy_pass http://192.168.70.99:1111 表示将请求交给192.168.70.99:1111处理,就是将请求交给上边部署的kestrel-mysite1服务处理:

server {
    listen        80;
    server_name   mysite.com *.mysite.com;
    access_log  logs/mysite_access.log  main;
    location / {
        proxy_pass         http://192.168.70.99:1111;
        proxy_http_version 1.1;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

  然后使用命令 nginx -s reload 重新加载nginx配置 。为了演示方便我们在自己的电脑上添加一个本机DNS,到C:\Windows\System32\drivers\etc目录下,在host文件下添加DNS: 192.168.70.99 www.mysite.com 。到这里反向代理就配置完成了,在浏览器上输入www.mysite.com显示如下:

  反向代理的基本流程:我们在浏览器输入www.mysite.com,首先通过DNS解析找到访问的主机IP为192.168.70.99,请求发送后被IP为192.168.70.99虚拟机的80端口监听到,location匹配后通过proxy指令将请求交给192.168.70.99:1111服务去处理,处理完成后将结果返回Nginx,再由Nginx返回给客户端。192.168.70.99:1111部署的就是运行在kestrel上的netcore web应用。

1.4 Nginx实现负载均衡

  考虑一个问题:如果我们的web应用并发量比较大,一台服务器不满足需求,我们多部署了几台服务器,那么怎么让Nginx将请求转发给多台服务器呢?简单的说,将请求转发给多台服务器可以叫做负载均衡,同一个location下不能写多个proxy指令,upstream指令可以实现将请求转发给多个不同的服务器。实现负载均衡的步骤也十分简单。

  我们修改示例项目的hosting.json配置文件,内容为 { "server.urls": "http://0.0.0.0:2222"} ,即部署端口设置为2222,将发布文件放在/var/www/MySite2目录下(为了便于区分,部署在2222端口的界面显示【欢迎来到Site2】);然后通过Systemd添加一个kestrel-mysite2服务,添加过程和kestrel-mysite1服务一样,配置文件如下:

[Unit]
#简单描述
Description=run MySite on Centos

[Service]
#工作目录
WorkingDirectory=/var/www/MySite2
#开启时执行的命令
ExecStart=/usr/bin/dotnet /var/www/MySite2/MySite.dll
#出错造成服务停止时重启,Restart=always表示无论什么原因造成服务未运行都重启
Restart=on-failure
#服务崩溃时,十秒钟重启一次
RestartSec=10
#用户
User=wyy

[Install]
#该服务所在的target
#这里符号链接放在/usr/lib/systemd/system/multi-user.target.wants目录下
WantedBy=multi-user.target

接下来修改/usr/local/nginx/vhosts/www.mysite.com配置文件,修改如下:

upstream mysite_hosts{
        server 192.168.70.99:1111 weight=1 max_fails=2 fail_timeout=30s;
        server 192.168.70.99:2222 weight=3 max_fails=2 fail_timeout=30s;
}


server {
    listen        80;
    server_name   mysite.com *.mysite.com;
    access_log  logs/mysite_access.log  main;
    location / {
        proxy_pass         http://mysite_hosts;
        proxy_http_version 1.1;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}
  upstrem节点下  server 192.168.70.99:1111 weight=1 max_fails=2 fail_timeout=30s 中weight表示权重,权重越大转发的几率就越高;max_fails=2,最多失败两次,失败两次后就不再向这个服务器转发请求;fail_timeout=30s表示超时时间为30s。这里为了方便,部署在同一虚拟机的两个端口上,也可以部署在不同的设备上,
部署在不同的设备上时,修改一下IP即可。
  最后我们打开浏览器,输入www.mysite.com,不停的刷新,会出现两种界面如下,且出现第二种界面的概率更大,如果我们故意关掉其中的一个服务器,另一台服务器并不会受到影响,网站也可以正常运行:

到这里我们已经通过Nginx实现了负载均衡,负载均衡还有其他的形式,在下一篇会介绍。

补充2 Systemd

2.1 Systemd简单认识

  Systemd即为system daemon,是linux的一种init软件,用来启动和管理守护进程(类似于windows下的NSSM),它替代initd成为系统的第一个进程(PID=1)。管理后台服务的软件还有python开发的supervisor等。

  Systemd管理系统资源时,所有的资源统称为Unit(单元)。每一个Unit都有一个配置文件,用于告诉Systemd怎么启动这个Unit。开机时Systemd 从目录/etc/systemd/system/读取配置文件,该目录里面存放的大部分文件都是符号链接,指向目录/usr/lib/systemd/system/,真正的配置文件存放在/usr/lib/systemd/system/目录下。

  看一下Systemd管理防火墙的命令: systemctl enable firewalld  这条命令的作用是让防火墙开机自启,执行这条命令时会在/etc/systemd/system/添加一个符号链接,指向/usr/lib/systemd/system下的firewalld.service。开机时只会执行/etc/systemd/system/目录下的配置文件,通过防火墙配置文件的符号链接,执行/usr/lib/systemd/system下的firewalld.service。相对的 systemctl disable firewalld 用于让防火墙开机不自启,实质上就是撤销/etc/systemd/system/目录下的符号链接。

  我们可以通过 systemctl list-unit-files 查看配置文件,如下所示:

  绿色的enabled表示开机启动,红色的disabled表示开机不启动,static表示不能执行,只能作为其他配置文件的依赖,masked表示禁止执行。

2.2 Unit配置文件

  我们知道Unit配置文件存放在 /usr/lib/systemd/system/目录中,所以当添加后台进程来托管netcore应用时,首先要在该目录下添加一个配置文件。

  看一下上边的Unit配置文件:

[Unit]
#简单描述
Description=run MySite on Centos

[Service]
#工作目录
WorkingDirectory=/var/www/MySite
#开启时执行的命令
ExecStart=/usr/bin/dotnet /var/www/MySite1/MySite1.dll
#出错造成服务停止时重启
Restart=on-failure#服务崩溃时,十秒钟重启一次
RestartSec=10
#用户
User=wyy

[Install]
#该服务所在的target
#这里符号链接放在/usr/lib/systemd/system/multi-user.target.wants目录下
WantedBy=multi-user.target

[Unit]区块通常是配置文件的第一个区块,用来定义 Unit 的元数据,以及配置与其他 Unit 的关系。它的主要字段如下:

Description:简短描述
Documentation:文档地址
Requires:当前 Unit 依赖的其他 Unit,如果它们没有运行,当前 Unit 会启动失败
Wants:与当前 Unit 配合的其他 Unit,如果它们没有运行,当前 Unit 不会启动失败
BindsTo:与Requires类似,它指定的 Unit 如果退出,会导致当前 Unit 停止运行
Before:如果该字段指定的 Unit 也要启动,那么必须在当前 Unit 之后启动
After:如果该字段指定的 Unit 也要启动,那么必须在当前 Unit 之前启动
Conflicts:这里指定的 Unit 不能与当前 Unit 同时运行
Condition...:当前 Unit 运行必须满足的条件,否则不会运行
Assert...:当前 Unit 运行必须满足的条件,否则会报启动失败

[Install]通常是配置文件的最后一个区块,用来定义如何启动,以及是否开机启动。它的主要字段如下:

WantedBy:它的值是一个或多个 Target,当前 Unit 激活时(enable)符号链接会放入/etc/systemd/system目录下面以 Target 名 + .wants后缀构成的子目录中
RequiredBy:它的值是一个或多个 Target,当前 Unit 激活时,符号链接会放入/etc/systemd/system目录下面以 Target 名 + .required后缀构成的子目录中
Alias:当前 Unit 可用于启动的别名
Also:当前 Unit 激活(enable)时,会被同时激活的其他 Unit

补充:Target 就是一个 Unit 组,包含许多相关的 Unit 。启动某个 Target 的时候,Systemd 就会启动里面所有的 Unit。从这个意义上说,Target 这个概念类似于"状态点",启动某个 Target 就好比启动到某种状态。

[Service]区块用来 Service 的配置,只有 Service 类型的 Unit 才有这个区块。它的主要字段如下。

Type:定义启动时的进程行为。它有以下几种值。
Type=simple:默认值,执行ExecStart指定的命令,启动主进程
Type=forking:以 fork 方式从父进程创建子进程,创建后父进程会立即退出
Type=oneshot:一次性进程,Systemd 会等当前服务退出,再继续往下执行
Type=dbus:当前服务通过D-Bus启动
Type=notify:当前服务启动完毕,会通知Systemd,再继续往下执行
Type=idle:若有其他任务执行完毕,当前服务才会运行
ExecStart:启动当前服务的命令
ExecStartPre:启动当前服务之前执行的命令
ExecStartPost:启动当前服务之后执行的命令
ExecReload:重启当前服务时执行的命令
ExecStop:停止当前服务时执行的命令
ExecStopPost:停止当其服务之后执行的命令
RestartSec:自动重启当前服务间隔的秒数
Restart:定义何种情况 Systemd 会自动重启当前服务,可能的值包括always(总是重启)、on-success、on-failure、on-abnormal、on-abort、on-watchdog
TimeoutSec:定义 Systemd 停止当前服务之前等待的秒数
Environment:指定环境变量
注意:一旦修改配置文件,就要让 Systemd重新加载配置文件,然后重新启动,否则修改不会生效,命令如下:
sudo systemctl daemon-reload  
sudo systemctl restart xxx.service
Systemctl是Systemd的主命令,我们经常用到的命令并不多,简单总结如下:
# 立即启动一个服务
$ sudo systemctl start firewalld.service

# 立即停止一个服务
$ sudo systemctl stop firewalld.service

# 重启一个服务
$ sudo systemctl restart firewalld.service

# 杀死一个服务的所有子进程
$ sudo systemctl kill firewalld.service

# 重新加载一个服务的配置文件
$ sudo systemctl reload firewalld.service

# 重载所有修改过的配置文件
$ sudo systemctl daemon-reload

# 显示某个 Unit 的所有底层参数
$ systemctl show firewalld.service

 参考文章:

【1】http://www.ruanyifeng.com/blog/2016/03/systemd-tutorial-part-two.html

【2】https://docs.microsoft.com/zh-cn/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-2.2

 

posted @ 2019-04-11 20:22  捞月亮的猴子  阅读(2389)  评论(0编辑  收藏  举报