Nginx二进制文件中已经指定了Nginx包含了哪些模块,所有模块有独立的配置,但遵循相同的配置语法。
有些指令块可以有参数(跟在指令块名后面),有些指令块不能有参数,具体是由提供指令块的Nginx模块来决定的。
Nginx命令行和大多Linux命令是类似的,格式是nginx -参数 参数值
,常用的参数:
默认情况下,Nginx会去使用conf
目录里的配置文件,这里-c
则是去人为指定要使用的配置文件。
指定配置指令-g
的功能是去覆盖conf
下的一些命令行指令。
指定运行目录-p
的意思是,Nginx的运行中有很多子目录(如modules),这里指定了运行目录会使用指定的目录。
发送信号-s
是Nginx提供的操作运行时进程的方法,比如既可以用Linux通用的kill
将Nginx进程关掉,也可以用这种发送信号的方式。
测试配置文件语法错误-t
也是一个重要的功能,因为新写好的配置文件可能会有错,用这种方式测试语法无误之后再发布到线上。
查看版本信息可以用-v
,而-V
还能看到编译Nginx时,configure过程所加的所有的参数以及编译器信息:
在演示前开启Nginx服务(直接运行二进制文件即可):
例如现在要修改Nginx配置文件conf/nginx.conf
,将原本处于注释状态的tcp_nopush
这个配置项打开:
将其取消注释后保存此配置文件,接着在不停止Nginx服务的情况下重新载入配置文件:
./sbin/nginx -s reload
这样也就启用了刚刚打开的新的配置项。
热部署一般指在Nginx运行状态,去更换一个更新版本的Nginx。先备份旧的Nginx二进制文件:
cp ./sbin/nginx ./sbin/nginx.old
下载新的Nginx:
wget http://nginx.org/download/nginx-1.16.1.tar.gz
解压:
tar -zxf nginx-1.16.1.tar.gz
编译:
cd nginx-1.16.1
./configure --prefix=/home/software/nginx
make
接下来要开始做热部署对Nginx升级了,先看一下升级前的进程情况:
可以看到老的master进程号是1944,并带有一个worker进程号是1969(worker进程实际可以不止一个)。
接下来拷贝并覆盖二进制文件,替换掉正在运行的Nginx进程所使用的二进制文件:
cp -rf objs/nginx ../nginx/sbin/
这时再看一下进程:
和刚刚比没有变化,因为这些进程已经跑起来。不过文件确实已经替换掉了,可以看下时间和字节数都是不一样的:
接下来先给正在运行的Nginx的master进程发送一个USR2信号,告知要开始做热部署了:
kill -USR2 1944
这时候它会新启动一个Nginx的master进程(而且也带着自己的worker),使用的是刚刚拷贝替换过来的Nginx二进制文件:
老的Nginx也在运行,但这个状态下会将新的请求平滑过渡到新的Nginx进程中去。老的worker进程不再监听80或者443这样的端口了,新的请求新的连接只会进入到新的Nginx进程中。
接下来,向老的Nginx进程发送WINCH信号,优雅(还是没太理解这个词)关闭其所有的worker进程。
kill -WINCH 1944
一段时间后,老的worker进程已经退出了,但是老的master进程还在:
这表明,所有的请求已经全部切换到升级好的Nginx中了,但是使用时如果出现问题可能需要把新版本退回到老版本,所以这个老的master进程还留着,可以向其发送reload命令让它把自己的worker进程再启动起来,然后再把新版本关掉,也就是允许用来做版本回退。
日志切割是在Nginx运行时备份日志文件,并将当前日志文件清空的操作。以备份error.log
为例,备份前的大小:
将其重命名(改了名字文件的i节点不会改变,至此日志还是往这个文件中写入):
mv error.log bak.log
接着执行reopen命令以重新开始记录日志文件:
../sbin/nginx -s reopen
这时会重新生成缺失的日志文件,并重新开始记录:
至于之前的日志记录,已经备份到bak.log
中去了。
在实际应用中可能是每天或者每周执行一次日志切割,这样就不能手动来做了(不方便也不准时)。可以写成shell脚本,脚本中将日志文件移动到备份目录中,然后执行-s reopen
或者发送-USR1
信号重启日志记录,然后将脚本放在crontab中形成定时任务就可以了。