使用Docker快速创建.Net Core2.0 Nginx负载均衡节点

服务器
ASP.NET Core 的运行环境由新开发的 Kestrel Server 负责,IIS 退回到 HTTP 的侦听器的角色,微软也特别为了这个需求开发了 IIS Platform Handler,以处理 HTTP 与运行环境之间的信息转发工作,微软官方推荐在Linux服务器上使用Nginx,Haproxy等代理Kestrel Server。

一.Self-Host Kestrel

1. 在vs2017中新建dotnet core2.0 webapi项目 ApiService

2. 参照官方文档,https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction?tabs=aspnetcore2x 在Startup中增加

  1. app.UseForwardedHeaders(new ForwardedHeadersOptions 
  2. ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto 
  3. }); 

配置运行Url, 在Program.cs中

[[204746]]

3. 发布项目文件,通过FTP上传到linux服务器。 一个core2.0 webapi新项目发布后只有几百kb

4. 切换目录,dotnet ApiService.dll

5. 运行成功,开放服务器端口,不过目前是运行于Kestrel 的selfhost 状态。

二. 需要一个代理

ASP.NET Core 的运行环境由新开发的 Kestrel Server 负责,IIS 退回到 HTTP 的侦听器的角色,微软也特别为了这个需求开发了 IIS Platform Handler,以处理 HTTP 与运行环境之间的信息转发工作,微软官方推荐在Linux服务器上使用Nginx,Haproxy等代理Kestrel Server。

理解dotnet core host最重要的一点是,它独立运行。不在IIS中运行,也不需要IIS运行。它拥有独立的自宿主Web Server,在内部使用self-host server处理请求。

然而,你依然可以把IIS放在self-host server前面,作为一个前端代理,因为Kestrel是一个只拥有原始功能的web server,它并没有像iis那样完整的web server 功能,比如Kestrel不支持单个ip上,多个应用绑定80端口,IIS还可以提供静态文件服务,gzip压缩,静态文件缓存等其他高级功能,IIS在处理请求时效率非常好,,所以有必要利用这一点,您可以让iis处理它真正擅长的任务,并将动态任务传递到core应用程序。所以说在windows上,iis依然继续扮演着非常重要的角色。

在传统经典的Asp.Net应用中,所有内容都托管在iis工作进程中(w3wp.exe),这就是我们常说的应用程序池。并且应用由IIS内置托管功能加载实例化,经过工作者进程加载aspnet_isapi.dll,在用aspnet_isapi加载.Net运行时。IIS工作者进程中的应用程序池加载应用程序域。一系列工作结束后,由ISAPIRuntime对象调用PR方法,封装HttpWorkerRequest对象,传递给HttpRuntime 创建HttpApplication实例, 然后一系列HttpApplication初始化和管道事件执行。当然加载运行时,应用程序域等都只是***个请求到达后做的事儿。

在dotnet core中很不同的是,core不会在iis工作进程中运行,而是在自己的Kestrel组件中。通过一个叫做AspNetCoreModule的原生的IIS module,执行外部的应用。Kestrel是一款针对吞吐量性能做了大量优化的dotnet web server的实现,它将网络请求快速传递给你的应用,但它仅仅是一个原始的web server,没有IIS那样全面的Web管理服务。

虽然IIS站点依然需要应用程序池,但是应该设置为无托管代码,由于应用程序池只作为转发请求的代理,因此不需要实例化.net 运行时。所以在linux上也一样,我们需要一个self-host的前端代理,在这里参考文档使用nginx。

三.nginx做代理

找到/etc/nginx配置nginx.conf

  1. server { 
  2.     listen 80; 
  3.     location / { 
  4.         proxy_pass http://localhost:5000; 
  5.         proxy_http_version 1.1; 
  6.         proxy_set_header Upgrade $http_upgrade; 
  7.         proxy_set_header Connection keep-alive; 
  8.         proxy_set_header Host $host; 
  9.         proxy_cache_bypass $http_upgrade; 
  10.     } 

我将nginx 的user改为root 5000改成自己的10000

创建service file

nano /etc/systemd/system/apiservice.service

service file的内容,官方示例:

  1. 1 [Unit] 
  2.  2 Description=Example .NET Web API Application running on Ubuntu 
  3.  3  
  4.  4 [Service] 
  5.  5 WorkingDirectory=/var/aspnetcore/hellomvc 
  6.  6 ExecStart=/usr/bin/dotnet /var/aspnetcore/hellomvc/hellomvc.dll 
  7.  7 Restart=always 
  8.  8 RestartSec=10  # Restart service after 10 seconds if dotnet service crashes 
  9.  9 SyslogIdentifier=dotnet-example 
  10. 10 User=www-data 
  11. 11 Environment=ASPNETCORE_ENVIRONMENT=Production  
  12. 12  
  13. 13 [Install] 
  14. 14 WantedBy=multi-user.target 

修改了 User为root。还修改了工作目录 就是我项目文件ftp上传后的目录,ExecStart的 dotnet这个目录不要修改 dll目录,改成目标要执行的dll的目录

然后enable service

执行 systemctl enable kestrel-hellomvc.service

start并验证service的状态

systemctl start kestrel-hellomvc.service

systemctl status kestrel-hellomvc.service

访问监听中的80端口,证明服务成功。

四.做负载均衡

按照相同的方式 我们再部署一个10001,修改nginx,配置负载均衡。

访问证明我们配置成功。

五.创建Docker Image

官方提供的dotnet core镜像位 microsoft/dotnet。docker基础命令就不提了,刚开始用也是边学边记。下面基于microsoft/dotnet image创建自己的image。以便快速运行多个docker image,配置更多的负载均衡,而无需手动copy到各个服务器上再配置环境,也就是说无论我们创建几十个甚至上百个,有我们自己的docker hub的话,创建起来是很快的,也不会出现在这台服务器上可用,在另一台服务器上搞出什么其他问题。

下面只是一个学习过程中自己的范例,离***实践方式还差得很远,希望能对看随笔的朋友有所帮助。

由于还要在每个image的apiService前面 放置nginx,所以 core application在各个容器中都是使用self-host的形式,在Kestrel上运行。在前端通过nginx 对docker暴露出的端口号进行代理。

在发布的网站目录下 创建Dockerfile。

保存后 执行docker构建 使用当前目录的Dockerfile创建镜像。docker build -t image/apiservice-v3 . 注意结尾有个 . (使用当前目录)

docker images 查看镜像

我们可以发现 刚创建的docker image 比我们FROM的microsoft/dotnet 大小大一点。

下面运行下看看 四行命令 运行了四个我们刚创建的image

docker run -d -p :81:20000 image/apiservice-v3


 

docker ps -a 查看下运行中的image进程

下面配置nginx负载均衡然后service nginx reload,实验完成。

下面使用docker kill对docker container逐一停止,停止后访问,确认负载均衡成功。当四个container都停止后,nginx返回 502 error.

责任编辑:武晓燕 来源: 博客园
相关推荐

2011-01-07 11:14:17

Nginx负载均衡负载均衡

2020-07-28 15:10:34

Nginx反向代理负载均衡

2023-01-10 08:37:45

Docker开发架构

2013-04-22 11:29:14

Nginx

2012-07-31 09:25:42

nginx负载均衡反向代理

2020-01-14 09:40:00

Nginx负载均衡正向代理

2012-02-14 10:10:35

NginxKeepalived负载均衡

2015-09-06 09:53:41

DockerWeave

2011-12-02 22:51:46

Nginx负载均衡

2014-07-28 11:37:49

NginxTomcat

2010-05-07 12:23:23

nginx负载均衡

2010-05-06 10:01:26

nginx负载均衡

2011-09-01 10:23:47

Nginx负载均衡器负载均衡

2021-03-01 06:15:53

nginx

2013-08-27 13:48:12

Nginx stickNginx负载均衡

2017-12-18 12:04:02

Nginx代理均衡

2010-05-07 12:27:53

nginx负载均衡

2010-03-25 18:52:15

Nginx负载均衡

2019-06-24 15:58:53

TCPUDPNginx

2019-11-04 15:35:53

Nginx反向代理负载均衡
点赞
收藏

51CTO技术栈公众号