Nginx的搭建与核心配置
- 1、IO模型
- 1.1I/O 模型相关概念
- 1.2网络I/O模型
- 1.2.1阻塞型I/O模型
- 1.2.2非阻塞型I/O模型
- 1.2.3多路复用I/O型
- 1.2.4信号驱动式I/O模型
- 1.2.5异步I/O模型
- 2、Nginx概述
- 2.1Nginx功能介绍
- 2.2基础特性
- 2.3Web服务相关的功能
- 2.4Nginx进程结构
- 2.4Nginx模块
- 2.5Nginx三大作用:反向代理、负载均衡、动静分离
- 3、Nginx和Apache的差异
- 4、编译安装Nginx
- 5、Nginx的平滑升级与信号使用
- 5.1信号
- 5.1.1显示版本号
- 5.1.2发送信号
- 5.2日志分割
- 5.3升级nginx
- 5.3.1操作流程
- 5.3.2平滑升级
- 5.3.3退回旧版本(回滚)
1、IO模型
I/O在计算机中指Input/Output, IOPS即每秒的输入输出量(或读写次数),是衡量磁盘性能的主要指标之一。简单说I/O就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。
LINUX的I/O
- 磁盘I/O
磁盘I/O是进程向内核发起系统调用,请求磁盘上的某个资源比如是html 文件或者图片,然后内核通过相应的驱动程序将目标文件加载到内核的内存空间,加载完成之后把数据从内核内存再复制给进程内存,如果是比较大的数据也需要等待时间 - 网络I/O
一切皆文件,本质为对socket文件的读写 网络通信就是网络协议栈到用户空间进程的IO就是网络IO
1.客户端发起请求 先发送到网卡
2.网卡收到的报文复制到内核空间
3.内核空间再复制到用户空间的应用程序空间
4.nginx 分析得到一个磁盘页面文件
5.再将需求反馈给内核空间,应为应用程序没有权限从磁盘上直接读取文件,需要依靠内核
6.内核去磁盘上找到所需要的文件,加载到内核空间
7.加载后再复制到用户空间
8.用户空间构建响应报文,交给内核空间,内核空间再复制给网卡,返回给用户 整个过程会来回切换 用户空间,内核空间 那么我们可以再次基础上做优化处理
1.1I/O 模型相关概念
同步/异步(消息反馈机制):关注的是消息通信机制,即调用者在等待一件事情的处理结果时,被调用者是否提供完成状态的通知。
- 同步:synchronous,被调用者并不提供事件的处理结果相关的通知消息,需要调用者主动询问事情是否处理完成
- 异步:asynchronous,被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态
阻塞/非阻塞:关注调用者在等待结果返回之前所处的状态 - 阻塞:blocking,指IO操作需要彻底完成后才返回到用户空间,调用结果返回之前,调用者被挂起,干不了别的事情。
- 非阻塞:nonblocking,指IO操作被调用后立即返回给用户一个状态值,而无需等到IO操作彻底完成,在最终的调用结果返回之前,调用者不会被挂起,可以去做别的事情。
1.2网络I/O模型
阻塞型、非阻塞型、复用型、信号驱动型、异步
1.2.1阻塞型I/O模型
同步阻塞:程序向内核发送I/O请求后一直等待内核响应,如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求,并由进程轮训查看I/O是否完成,完成后进程将I/O结果返回给Client,在IO没有返回期间进程不能接受其他客户的请求,而且是有进程自己去查看I/O是否完成,这种方式简单,但是比较慢,用的比较少。
- 优点:程序简单,在阻塞等待数据期间进程/线程挂起,基本不会占用 CPU 资源
- 缺点:每个连接需要独立的进程/线程单独处理,当并发请求量大时为了维护程序,内存、线程切换开销较大,apache 的preforck使用的是这种模式。
1.2.2非阻塞型I/O模型
非阻塞:程序向内核发送请I/O求后一直等待内核响应,如果内核处理请求的IO操作不能立即返回IO结果,进程将不再等待,而且继续处理其他请求,但是仍然需要进程隔一段时间就要查看内核I/O是否完成。
1.2.3多路复用I/O型
I/O multiplexing
主要包括:select,poll,epoll三种系统调用,select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket,当某个socket有数据到达了,就通知用户进程。当用户进程调用了select,那么整个进程会被block,而同时,kernel会“监视”所有select负责的socket,当任何一个socket中的数据准备好了,select就会返回。这个时候用户进程再调用read操作,将数据从kernel拷贝到用户进程。Apache
prefork是此模式的select,work是poll模式。
1.2.4信号驱动式I/O模型
信号驱动I/O的意思就是我们现在不用傻等着了,也不用去轮询。而是让内核在数据就绪时,发送信号通知我们。
调用的步骤是,通过系统调用 sigaction ,并注册一个信号处理的回调函数,该调用会立即返回,然后主程序可以继续向下执行,当有I/O操作准备就绪,即内核数据就绪时,内核会为该进程产生一个SIGIO 信号,并回调注册的信号回调函数,这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进程所需要的数据从内核空间拷贝到用户空间。
此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行,只要等待来自信号处理函数的通知。
- 优点:线程并没有在等待数据时被阻塞,内核直接返回调用接收信号,不影响进程继续处理其他请求因此可以提高资源的利用率
- 缺点:信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
1.2.5异步I/O模型
异步I/O 与
信号驱动I/O最大区别在于,信号驱动是内核通知我们何时开始一个I/O操作,而异步I/O是由内核通知我们I/O操作何时完成,两者有本质区别,相当于不用去饭店场吃饭,直接点个外卖,把等待上菜的时间也给省了。所有事情都交给内核处理。
Nginx支持在多种不同的操作系统实现不同的事件驱动模型,但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同,主要有以下实现方式:
1、select: select库是在linux和windows平台都基本支持的 事件驱动模型库,并且在接口的定义也基本相同,只是部分参数的含义略有差异,最大并发限制1024,是最早期的事件驱动模型。
2、poll: 在Linux 的基本驱动模型,windows不支持此驱动模型,是select的升级版,取消了最大的并发限制,在编译nginx的时候可以使用–with-poll_module和–without-poll_module这两个指定是否编译select
库。
3、epoll: epoll是库是Nginx服务器支持的最高性能的事件驱动库之一,是公认的非常优秀的事件驱动模型,它和select和poll有很大的区别,epoll是poll的升级版,但是与poll有很大的区别.epoll的处理方式是创建一个待处理的事件列表,然后把这个列表发给内核,返回的时候在去轮训检查这个表,以判断事件是否发生,epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数,同时epoll库的I/O效率不随描述符数目增加而线性下降,因为它只会对内核上报的“活跃”的描述符进行操作。
4、rtsig:不是一个常用事件驱动,最大队列1024,不是很常用
5、kqueue: 用于支持BSD系列平台的高校事件驱动模型,主要用在FreeBSD4.1及以上版本,OpenBSD 2.0级以上版 本,NetBSD级以上版本及Mac OS X 平台上,该模型也是poll库的变种,因此和epoll没有本质上的区别, 都是通过避免轮训操作提供效率。
6、/dev/poll: 用于支持unix衍生平台的高效事件驱动模型,主要在Solaris 平台、HP/UX,该模型是sun公司在开发Solaris系列平台的时候提出的用于完成事件驱动机制的方案,它使用了虚拟的/dev/poll设备,开发人员将要见识的文件描述符加入这个设备,然后通过ioctl()调用来获取事件通知,因此运行在以上系列平台的时候请使用/dev/poll事件驱动机制。
7、eventport:
该方案也是sun公司在开发Solaris的时候提出的事件驱动库,只是Solaris 10以上的版本,该驱动库看防 止内核崩溃等情况的发生。
8、Iocp: Windows系统上的实现方式,对应第5种(异步I/O)模型。
Select: POSIX所规定,目前几乎在所有的平台上支持,其良好跨平台支持也是它的一个优点,本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。缺点:单个进程能够监视的文件描述符的数量存在最大限制,在Linux上一般为1024,可以通过修改宏定义FD_SETSIZE,再重新编译内核实现,但是这样也会造成效率的降低单个进程可监视的fd数量被限制,默认是1024,修改此值需要重新编译内核 对socket是线性扫描,即采用轮询的方法,效率较低 select采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间,这样一个用来存放大量fd的数据jjie构,这样会使得用户空间和内核空间在传递该结构时复制开销大
poll: 本质上和select没有区别,它将用户传入的数组拷贝到内核空间,然后查询每个fd对应的设备状态。其没有最大连接数的限制,原因是它是基于链表来存储的 大量的fd的数组被整体复制于用户态和内核地址空间之间,而不管这样的复制是不是有意义。
poll特点是“水平触发”,如果报告了fd后,没有被处理,那么下次poll时会再次报告该fd select是边缘触发即只通知一次
epoll: 在Linux 2.6内核中提出的select和poll的增强版本
支持水平触发LT和边缘触发ET,最大的特点在于边缘触发,它只告诉进程哪些fd刚刚变为就需态,并且只会 通知一次
使用“事件”的就绪通知方式,通过epoll_ctl注册fd,一旦该fd就绪,内核就会采用类似callback的回调机制来激活该fd,epoll_wait便可以收到通知
优点:没有最大并发连接的限制:能打开的FD的上限远大于1024(1G的内存能监听约10万个端口),具体查看/proc/sys/fs/file-max,此值和系统内存大小相关效率提升:非轮询的方式,不会随着FD数目的增加而效率下降;只有活跃可用的FD才会调用callback函数, 即epoll最大的优点就在于它只管理“活跃”的连接,而跟连接总数无关 内存拷贝,利用mmap
(MemoryMapping)加速与内核空间的消息传递;即epoll使用mmap减少复制开销
2、Nginx概述
2.1Nginx功能介绍
- 静态的web资源服务器html,图片,js,css,txt等静态资源
- http/https协议的反向代理 7层
- 结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求
- tcp/udp协议的请求转发(反向代理) 4层
2.2基础特性
- 模块化设计,较好的扩展性
- 高可靠性
- 支持热部署:不停机更新配置文件,升级版本,更换日志文件
- 低内存消耗:10000个keep-alive连接模式下的非活动连接,仅需2.5M内存
- event-driven,aio,mmap,sendfile
2.3Web服务相关的功能
- 虚拟主机(server)
- 支持 keep-alive 和管道连接(利用一个连接做多次请求)
- 访问日志(支持基于日志缓冲提高其性能)
- url rewirte
- 路径别名
- 基于IP及用户的访问控制
- 支持速率限制及并发数限制
- 重新配置和在线升级而无须中断客户的工作进程
2.4Nginx进程结构
web请求处理机制
- 多进程方式:服务器每接收到一个客户端请求就有服务器的主进程生成一个子进程响应客户端,直到用户关闭连接,这样的优势是处理速度快,子进程之间相互独立,但是如果访问过大会导致服务器资源耗尽而无法提供请求。
- 多线程方式:与多进程方式类似,但是每收到一个客户端请求会有服务进程派生出一个线程来个客户方进行交互,一个线程的开销远远小于一个进程,因此多线程方式在很大程度减轻了web服务器对系统资源的要求,但是多线程也有自己的缺点,即当多个线程位于同一个进程内工作的时候,可以相互访问同样的内存地址空间,所以他们相互影响,一旦主进程挂掉则所有子线程都不能工作了,IIS服务器使用了多线程的方式,需要间隔一段时间就重启一次才能稳定。
主进程(master process)的功能:
对外接口:接收外部的操作(信号) 对内转发:根据外部的操作的不同,通过信号管理 Worker 监控:监控 worker
进程的运行状态,worker 进程异常终止后,自动重启 worker 进程 读取Nginx 配置文件并验证其有效性和正确性
建立、绑定和关闭socket连接 按照配置生成、管理和结束工作进程 接受外界指令,比如重启、升级及退出服务器等指令
不中断服务,实现平滑升级,重启服务并应用新的配置 开启日志文件,获取文件描述符 不中断服务,实现平滑升级,升级失败进行回滚处理
编译和处理perl脚本
工作进程(worker process)的功能:
所有 Worker 进程都是平等的 实际处理:网络请求,由 Worker 进程处理
Worker进程数量:一般设置为核心数,充分利用CPU资源,同时避免进程数量过多,导致进程竞争CPU资源, 增加上下文切换的损耗
接受处理客户的请求 将请求依次送入各个功能模块进行处理 I/O调用,获取响应数据 与后端服务器通信,接收后端服务器的处理结果
缓存数据,访问缓存索引,查询和调用缓存数据 发送请求结果,响应客户的请求 接收主程序指令,比如重启、升级和退出等
2.4Nginx模块
- 核心模块:是 Nginx 服务器正常运行必不可少的模块,提供错误日志记录 、配置文件解析 、事件驱动机制 、进程管理等核心功能
- 标准HTTP模块:提供 HTTP 协议解析相关的功能,比如: 端口配置 、 网页编码设置 、 HTTP响应头设置 等等
- 可选HTTP模块:主要用于扩展标准的 HTTP 功能,让 Nginx 能处理一些特殊的服务,比如:Flash 多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
- 邮件服务模块:主要用于支持 Nginx 的 邮件服务 ,包括对 POP3 协议、 IMAP 协议和 SMTP协议的支持
- Stream服务模块: 实现反向代理功能,包括TCP协议代理
- 第三方模块:是为了扩展 Nginx 服务器应用,完成开发者自定义功能,比如: Json 支持、 Lua 支持等
2.5Nginx三大作用:反向代理、负载均衡、动静分离
反向代理:在服务端 配置,客户端 访问服务器A ,服务器A 为代理服务器 ,将客户服务再转发到服务器B
作用:
1、缓存,将服务器的响应缓存在自己的内存中,减少服务器压力;
2、负载均衡,将用户请求分配给多个服务器;
3、访问控制
正向代理:在客户端 配置,配置完了再去访问具体服务,即代理服务器 代理了客户端 ,再去和目标服务器进行交互
作用:
1、提高访问速度
2、隐藏客户端真实IP地址
**负载均衡:**分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务
nginx七层负载均衡调度算法(六种)
1、轮询(默认调度算法)
特点:每个请求按时间顺序逐一分配到不同的后端服务器处理。
适用业务场景:后端服务器硬件性能配置完全一致,业务无特殊要求时使用。
upstream backendserver {
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
2、加权轮询
特点:指定轮询几率,weight值(权重)和访问比例成正比,用户请求按权重比例分配。
适用业务场景:用于后端服务器硬件性处理能力不平均的情形。
upstream backendserver {
server 192.168.0.14:80 weight=5 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 weight=10 max_fails=2 fail_timeout=10s;
}
3、ip_hash(IP哈希)
特点:每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session会话保持问题。
适用业务场景:适用于需要账号登录的系统,会话连接保持的业务。
upstream backendserver {
ip_hash;
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
4、最少连接数 least_conn
特点:按nginx反向代理与后端服务器之间的连接数,连接数最少的优先分配。
适用业务场景:适用于客户端与后端服务器需要保持长连接的业务。
upstream backendserver {
least_conn; server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
5、响应时间 fair(需编译安装第三方模块 ngx_http_upstream_fair_module)
特点:按后端服务器的响应时间来分配请求,响应时间短的优先分配。
适用业务场景:对访问响应速度有一定要求的业务。
upstream backendserver {
fair;
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}
6、url_hash(URL分配 )(需编译安装第三方模块 ngx_http_upstream_hash_module)
特点:按访问url的hash结果来分配请求,使同一个url访问到同一个后端服务器。
适用业务场景:适用于后端服务器为缓存服务器时比较有效。
upstream backendserver {
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
hash $request_uri;
}
**动静分离:**采用代理的方式,在server{}段中加入带正则匹配的location来指定匹配项针对PHP的动静分离:静态页面交给Nginx处理,动态页面交给PHP-FPM模块或Apache处理。
在Nginx的配置中,是通过location配置段配合正则匹配实现静态与动态页面的不同处理方式,通过使用Nginx提高网站的响应速度,优化用户体验
3、Nginx和Apache的差异
Apache:同步多进程模型:一个连接对应一个进程(高稳定)
- 1.rewrite更强大(rewrite主要功能是实现统一资源定位符URL的跳转)
- 2.模块多,基本想到的都可以找到
- 3.少bug,更加稳定(nginx相对较多)
- 4.PHP支持比较简单(nginx需要配合其他后端用)
- 5.处理动态请求更有优势(nginx更适合静态与反向)
Nginx:异步非阻塞模型:多个连接(万级别)对应一个进程(高性能)
- 1.轻量级,采用C编写,占用更少的内存与资源
- 2.抗并发/高并发,以epoll and kqueue 作为开发模型,负载能力高,高并发下能够保持 低资源低消耗高性能(apache在PHP处理慢或前端压力很大时,容易出现进程数飙升 从而拒绝服务)
- 3.处理静态文件好,静态处理性能比apache高三倍以上
- 4.设计高度模块化,编写模块相对简单
- 5.配置简洁,正则配置更简单,且更改完可以使用 -t 测试(apache配置复杂,重启时发 现出错,会很崩溃)
- 6.作为负载均衡服务器,支持七层负载均衡,可以有效防止ddos攻击
- 7.本身是一个反向代理服务器,也可以作为邮件代理服务器使用
- 8.支持热部署,支持在线升级
4、编译安装Nginx
源码包内的文件:
- contrib:vim 格式文件,修改nginx配置文件的格式,高亮 cp -r /opt/nginx-1.18.0/contrib/vim/* /usr/share/vim/vimfiles/
- conf:配置文件
- man:man帮助 man man/nginx.8 不加路径看不了 nginx.8 文件
- src:源码包 点c 点h 结尾的文件 find src -type f |xargs cat |wc -l 193678
关闭防火墙
systemctl stop firewalld //关闭防火墙
setenforce 0
yum -y install gcc pcre-devel openssl-devel zlib-devel openssl openssl-devel
//安装依赖环境
useradd -M -s /sbin/nologin nginx //新建nginx用户便于管理
cd /data/ //切换到data目录下
wget http://nginx.org/download/nginx-1.18.0.tar.gz //官网下载安装包
[root@localhost data]#
[root@localhost data]# ls
nginx-1.18.0.tar.gz
[root@localhost data]#
[root@localhost data]#
[root@localhost data]# tar xf nginx-1.18.0.tar.gz
[root@localhost data]#
[root@localhost data]#
[root@localhost data]# ls
nginx-1.18.0 nginx-1.18.0.tar.gz
[root@localhost data]#
mkdir -p /apps/nginx //递归创建文件夹用来存放编译安装的nginx
cd nginx-1.18.0/ //切换到刚才解压过的nginx包中./configure --prefix=/apps/nginx \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-pcre \
--with-stream \
--with-stream_ssl_module \
--with-stream_realip_module
//配置编译环境,选择要添加的功能模块
make -j2 && make install
[root@localhost nginx-1.18.0]#
[root@localhost nginx-1.18.0]# chown -R nginx.nginx /apps/nginx
[root@localhost nginx-1.18.0]#
[root@localhost nginx-1.18.0]#
[root@localhost nginx-1.18.0]#
[root@localhost nginx-1.18.0]# ll /apps/nginx/
总用量 4
drwxr-xr-x. 2 nginx nginx 4096 8月 26 18:57 conf
drwxr-xr-x. 2 nginx nginx 40 8月 26 18:57 html
drwxr-xr-x. 2 nginx nginx 6 8月 26 18:57 logs
drwxr-xr-x. 2 nginx nginx 19 8月 26 18:57 sbin
ln -s /apps/nginx/sbin/nginx /usr/sbin/
//设置软连接
vim /usr/lib/systemd/system/nginx.service
//#建立.service文件
将下面的内容添加进去
[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=forking
PIDFile=/apps/nginx/logs/nginx.pid
#注意文件位置,如果不对 启动不了
ExecStart=/apps/nginx/sbin/nginx -c /apps/nginx/conf/nginx.conf
#注意启动文件位置
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
[Install]
WantedBy=multi-user.targetsystemctl daemon-reload //重新加载配置
systemctl enable --now nginx //开机自启并立即启动
###如果需要修改pid文件可以执行以下操作#################
mkdir /apps/nginx/run/
//创建目录
vim /apps/nginx/conf/nginx.conf
//修改配置文件
pid /apps/nginx/run/nginx.pid;
//找到 pid的位置修改
5、Nginx的平滑升级与信号使用
5.1信号
- nginx 命令支持向其发送信号,实现不同功能
#基本格式
nginx -s 信号
- nginx 当做单独命令使用有以下选项
[root@node2 ~]#nginx -h-v : show version and exit-V : show version and configure options then exit-t : test configuration and exit-T : test configuration, dump it and exit-q : suppress non-error messages during configuration testing-s signal : send signal to a master process: stop, quit, reopen, reload-p prefix : set prefix path (default: /etc/nginx/)-e filename : set error log file (default: /var/log/nginx/error.log)-c filename : set configuration file (default: /etc/nginx/nginx.conf)-g directives : set global directives out of configuration file
5.1.1显示版本号
[root@localhost ~]# nginx -v
nginx version: nginx/1.18.0
5.1.2发送信号
kill -l //看信号大全
nginx -h //可以看到的信号较少
可以使用man手册来查看详细的信号 如果没安装,去源码包里找到man文件
man 路径/nginx.8 不加路径打不开man帮助
stop SIGTERM 直接停止
quit SIGQUIT 优雅的退出:有人在访问不会结束进程
reopen SIGUSR1 分割日志
reload SIGHUP 重新加载配置文件SIGHUP Reload configuration, start the new worker process with a new configuration, andgracefully shut down old worker processes.SIGQUIT Shut down gracefully. 优雅的关闭:有人在访问不会结束进程SIGUSR1 Reopen log files. 重新分割日志SIGUSR2 Upgrade the nginx executable on the fly. 运行中升级SIGWINCH Shut down worker processes gracefully. 优雅的关闭worker进程,work进程负责处理请求,还有请求不会关闭
5.2日志分割
cd /apps/nginx/logs #移动到日志所在目录下,此目录为指定安装目录,默认目录为/var/log/nginxmv access.log access.log.bak #备份日志文件
touch access.log #建空的日志文件cat /apps/nginx/logs/nginx.pid#查看nginx的pid
kill -s USR1 pid
5.3升级nginx
5.3.1操作流程
- 将旧Nginx文件换成新Nginx文件(注意备份)
- 向master进程发送USR2信号
- master进程修改pid文件名,加后缀.oldbin
- master进程用新Nginx文件启动新master进程,系统中将有新旧两个Nginx主进程共同提供Web服务
- 向旧的Nginx服务进程发送WINCH信号,使旧的Nginx worker进程平滑停止,并删除Nginx.pid.oldbin文件
- 向旧master进程发送QUIT信号,关闭老master
- 如果发现升级有问题,可以回滚向老master发送HUP,向新master发送QUIT
5.3.2平滑升级
- 首先关闭防火墙,并查看nginx当前的状态,若处于关闭状态需要先开启nginx
systemctl stop firewalld
setenforce 0
//关闭防火墙
systemctl status nginx.service
//查看nginx当前的状态
- 下载安装包到src目录
cd /usr/local/src/
//切换到src目录下
wget https://nginx.org/download/nginx-1.20.2.tar.gz
//去官网下载指定的安装包
- 解压安装包
tar xf nginx-1.20.2.tar.gz
- 切换到解压后的包中,并查看包内的文件
[root@localhost src]# cd nginx-1.20.2
[root@localhost nginx-1.20.2]# ls
auto CHANGES CHANGES.ru conf configure contrib html LICENSE man README src
- 重新编译安装
./configure --prefix=/apps/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module
- 安装
make -j2 && make install
- 查看版本
nginx -V
- 查看nginx当前状态
systemctl status nginx.service
- 更改旧版本nginx的名称,并拷入新版本
mv /apps/nginx/sbin/nginx /apps/nginx/sbin/nginx.bak
#将低版本的nginx主程序改名
cp /usr/local/src/nginx-1.20.2/objs/nginx /apps/nginx/sbin
#将新版本 拷入进去
/apps/nginx/sbin/nginx -t
#语法检查
- 查看旧版本的pid号
cat /apps/nginx/logs/nginx.pid
- 生成新的master进程
kill -USR2 1129
ps auxf|grep nginx
- 创建一个无用的填充文件,用于让测试客户端下载
dd if=/dev/zero of=/apps/nginx/html/m.img bs=1G count=10cd /apps/nginx/html;ls
- 在pc2上下载
wget --limit-rate=1M http://192.168.190.200/m.img
- 返回pc1查看master process pid文件路径
ls /apps/nginx/logs/
cat /apps/nginx/logs/nginx.pid #1.20.2版本的cat /apps/nginx/logs/nginx.pid.oldbin #1.18版本的pstree -p |grep nginx
- 优雅关闭旧版本的master process
kill -WINCH `cat /apps/nginx/logs/nginx.pid.oldbin`
- 开启新的客户机,从服务端获取测试包
wget --limit-rate=1M http://192.168.2.100/m.img
- 返回服务端查看是否使用新进程
ss -natp | grep 80
- 查看一下旧版本还在运行吗
pstree -p |grep nginx
旧版本不再工作,升级成功
5.3.3退回旧版本(回滚)
//唤起旧版本的主进程
kill -HUP `cat /apps/nginx/logs/nginx.pid.oldbin`
//观察进程
ps aux|grep nginx
//结束新版本的master进程
kill -QUIT `cat /apps/nginx/logs/nginx.pid`ps aux | grep nginx
curl -I 127.1
//通过 curl 发送一个 HEAD 请求到本地服务器并返回响应头信息
回滚到1.18.0,回滚成功