WEB应用

Nginx在线服务状态下平滑升级或新增模块的详细操作记录

今天,产品那边发来需求,说有个APP的IOS版本下载包需要新增https协议,在景安购买了免费的SSL证书。当我往nginx上新增ssl时,发现服务器上的nginx居然没编译SSL模块! 看了下旧版本nginx的configure选项: 可能是出于最小化安装的考虑,就只有一个prefix参数,而版本也挺低的,干脆就升级一下好了!由于服务器处于在线服务状态,为了避免升级带来的不良影响,我决定给nginx来个平滑升级,结果发现还真是如丝般顺滑。。。 下面记录一下平滑升级和新增模块的过程。 一、半自动平滑升级 所谓半自动,其实就是在最后迁移的时候使用源码自带的升级命令:make upgrade来自动完成。 ①、按需编译新版本的nginx 根据需求,常规编译新版本nginx,不过只要执行到make就打住,不要make install! ②、重命名nginx旧版本二进制文件,即sbin目录下的nginx(期间nginx并不会停止服务!): ③、然后拷贝一份新编译的二进制文件: ④、在源码目录执行make upgrade开始升级: 完成后,最后确认一下 nginx -V : 正常了,平滑升级成功! 二、纯手动平滑升级 纯手动模式,指的是在最后做迁移的时候,全部使用手动命令来搞定,避免编译可能存在不一致的参数啥的。 实际上,在make之后,我们可以查看nginx源码目录下的Makefile内容如下: 所以,说白了纯手动就是执行upgrade标签下的命令行而已,实际上只要确认Makefile下的命令路径都是正确的,用命令自动迁移是没有任何问题的。 总是有人会不放心的,喜欢手动一步一步的搞定,我也来整理下纯手动步骤: ①~③和半自动一样,按常规步骤先编译nginx,不过只执行到make就打住,然后将旧的sbin下的nginx文件移走,再将编译得到的objs目录下的nginx文件放到原来的sbin目录。 ④、测试新版本的nginx是否正常: ⑤、给旧nginx发送平滑迁移信号(若不清楚pid路径就用可用命令(2)): Ps:后面其实就是旧nginx的pid,所以先用ps aux找到正在运行的nginx主进程pid,再执行 kill -USR2 PID值亦可。 ⑥、等待旧版本Nginx的pid变为oldbin(执行如下命令查看是否生成) ⑦、  从容关闭旧版本的Nginx进程 此时,旧的工作进程就都会慢慢随着任务执行完毕而退出,新版的Nginx的工作进程会逐渐取代旧版工作进程。 ⑧、此时,不重载配置启动旧工作进程(个人感觉是为了将任务完全切换到新的nginx上) ⑨、结束工作进程,完成此次升级操作: ⑩、最后,验证nginx是否升级成功: 特意测试了下纯手动的做法,下面是我的操作记录,仅供参考: 为了验证平滑升级确实不影响在线业务,我特意在升级的时候,利用ab命令一直在发送请求: 直到升级完成,使用ctrl +C 终止并查看ab结果,可以发现几十万次的请求全部成功,没有失败!证明平滑升级的可行性!可惜忘记了截图,感兴趣的童鞋可以自行测试下! 好了,关于nginx的平滑升级和在线新增模块的操作记录就到这里结束了,希望对你有所帮助。
阅读全文
脚本编程

nginx日志切割及7天前的历史日志删除脚本

上次写到《服务器日志备份超节省空间的思路》,压缩后磁盘占用由93%降到了62%,效果还是不错的!为什么不直接删除呢?其实是因为这些日志涉及到支付等重要业务,保存半年以上也算是保守的做法。 今早,又发现几例磁盘空间报警,占用率都在90%+,关键居然是根分区!这要是日志突然暴涨,把根分区撑爆了,那就可以体验到“菊花一紧”的快感了吧? 索性利用CRT的全局命令把磁盘空间占用率超过75%的服务器筛选出来,打算继续进行清理磁盘空间这个枯燥的工作。结果,发现好几台nginx方向代理服务器的日志居然还没做分割处理,一个access.log居然近200G大小!真是I 服了 U 于是,就有了下面这个日志切割脚本,按日期切割nginx日志,并自动删除7天前的日志(日志均已同步至专用日志存储服务器,可放心删除历史日志。) 将这个脚本添加到计划任务,每天执行一次即可: 此方法,网上一搜一大把,因此本文仅作为个人工作记录,并非教程,随便看看就行,别太在意。
阅读全文