如何更好的手工编译安装Nginx

本文最后更新于2016年12月17日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

为了能在Nginx上使用一些额外的功能/模块,一般都是需要手工编译安装Nginx的,这对于专门研究Nginx或对此比较熟悉的人来说不算麻烦,但对于我这种新手来说就非常麻烦了——如果只是简单的设置「--prefix」、「--with-pcre」等几个编译选项的话,我也会一点,但如果考虑得不全面的话后期还需要重新编译,但该添加哪些选项我还真不清楚;还有就是如果完全重头开始编译Nginx的话,用户、组的创建,启动脚本的编写等都是需要自己来处理的,这也是我为什么一直都比较忌惮从头编译Nginx等系统软件的原因,需要考虑的问题太多了。

但今天在测试一个Nginx模块的时候学到了一个比较好的办法,自己实际在 CentOS 7 测试了一下,挺好用的。于是记录一下,方便以后参考。

正文:

参考解答:

完全从头开始指定Nginx的编译选项对我来说显然不现实,一个更好的办法是参照系统的编译选项,然后根据实际需要增加几个「--add-module」选项即可很好的结合二者的优点(方便快速&可定制):

&

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3077.html

《如何更好的手工编译安装Nginx》上有11条评论

  1. 如果在VPS上搭建了基于Nginx做WebServer的网站,最好将Nginx等服务设置成开机自启动:

    # CentOS 7
    # systemctl enable nginx
    # systemctl enable php-fpm
    # systemctl enable mysqld

    # CentOS 6
    # chkconfig --level 345 nginx on
    # chkconfig --level 345 php-fpm on
    # chkconfig --level 345 mysqld on

  2. Nginx最新模块—ngx_http_mirror_module分析
    https://mp.weixin.qq.com/s?__biz=MzIxNzg5ODE0OA==&mid=2247483708&idx=1&sn=90b0b1dccd9c337922a0588245277666
    http://nginx.org/en/CHANGES

    最近Nginx官网公布了Nginx 1.13.4最新的 ngx_http_mirror_module 模块,利用此模块,业务可以将线上实时访问流量拷贝至其他环境,基于这些流量可以做版本发布前的预先验证,进行流量放大后的压测等等。

    ngx_http_mirror_module 模块配置分为两部分,源地址(original)和镜像地址(mirror)配置。根据此文章的源码分析来看,在整个流程中,Nginx将请求转发送至original和mirror,然后等待响应,几乎不会对正常请求造成影响,整个处理过程是完全异步的。

  3. HTTP2简介和nginx中开启HTTP2
    https://www.ipcpu.com/2017/11/http2-nginx/

    在 Nginx 上 开启 HTTP/2 需要 Nginx 1.9.5 以上版本,并且需要 OpenSSL 版本在 1.0.2 以上。

    从Nginx 1.9.5 开始,http_v2_module 已经替换了ngx_http_spdy_module,全面支持HTTP/2协议。默认没有放进编译参数,需要编译参数 --with-http_v2_module 开启。

    可以用 nginx -V 查看。

    确保支持http2后,nginx配置作如下修改:
    server {
    listen 443 ssl http2;
    server_name ixyzero.com;

    验证/检测HTTP2是否开启:
    chrome://net-internals/#http2
    Chrome插件「HTTP/2 and SPDY indicator」
    Chrome控制台

  4. Nginx在用yum命令进行升级之后,相关目录的用户属主和权限就会重置(可能变得和自己设置的不太一样,比如从apache变成nginx),所以会导致一些比较诡异的状态:
    WordPress可以新增「小文章」,但不能添加「大文章」(涉及到临时目录的访问)

    # tail -f /var/log/nginx/error.log

    2018/02/11 16:51:41 [crit] 19581#0: *6 open() "/var/lib/nginx/tmp/client_body/0000000001" failed (13: Permission denied), client: 127.0.0.1, server: ixyzero.com, request: "POST /blog/wp-admin/admin-ajax.php HTTP/2.0", host: "ixyzero.com", referrer: "https://ixyzero.com/blog/wp-admin/post-new.php"

    # ps aux | grep nginx

    # ls -lt /var/log/nginx/
    # chown -R apache:apache /var/log/nginx/*.log

    # ls -lt /var/lib/nginx/
    # chown -R apache:apache /var/lib/nginx/

  5. Nginx请求处理流程你了解吗?
    https://mp.weixin.qq.com/s/otQIhuLABU3omOLtRfJnZQ

    nginx 11 个处理阶段
    1)NGX_HTTP_POST_READ_PHASE:
    接收到完整的HTTP头部后处理的阶段,它位于uri重写之前,实际上很少有模块会注册在该阶段,默认的情况下,该阶段被跳过。
    2)NGX_HTTP_SERVER_REWRITE_PHASE:
    URI与location匹配前,修改URI的阶段,用于重定向,也就是该阶段执行处于server块内,location块外的重写指令,在读取请求头的过程中nginx会根据host及端口找到对应的虚拟主机配置。
    3)NGX_HTTP_FIND_CONFIG_PHASE:
    根据URI寻找匹配的location块配置项阶段,该阶段使用重写之后的uri来查找对应的location,值得注意的是该阶段可能会被执行多次,因为也可能有location级别的重写指令。
    4)NGX_HTTP_REWRITE_PHASE:
    上一阶段找到location块后再修改URI,location级别的uri重写阶段,该阶段执行location基本的重写指令,也可能会被执行多次。
    5)NGX_HTTP_POST_REWRITE_PHASE:
    防止重写URL后导致的死循环,location级别重写的后一阶段,用来检查上阶段是否有uri重写,并根据结果跳转到合适的阶段。
    6)NGX_HTTP_PREACCESS_PHASE:
    下一阶段之前的准备,访问权限控制的前一阶段,该阶段在权限控制阶段之前,一般也用于访问控制,比如限制访问频率,链接数等。
    7)NGX_HTTP_ACCESS_PHASE:
    让HTTP模块判断是否允许这个请求进入Nginx服务器,访问权限控制阶段,比如基于ip黑白名单的权限控制,基于用户名密码的权限控制等。
    8)NGX_HTTP_POST_ACCESS_PHASE:
    访问权限控制的后一阶段,该阶段根据权限控制阶段的执行结果进行相应处理,向用户发送拒绝服务的错误码,用来响应上一阶段的拒绝。
    9)NGX_HTTP_TRY_FILES_PHASE:
    为访问静态文件资源而设置,try_files指令的处理阶段,如果没有配置try_files指令,则该阶段被跳过。
    10)NGX_HTTP_CONTENT_PHASE:
    处理HTTP请求内容的阶段,大部分HTTP模块介入这个阶段,内容生成阶段,该阶段产生响应,并发送到客户端。
    11)NGX_HTTP_LOG_PHASE:
    处理完请求后的日志记录阶段,该阶段记录访问日志。

    以上11个阶段中,HTTP无法介入的阶段有4个:
    3)NGX_HTTP_FIND_CONFIG_PHASE
    5)NGX_HTTP_POST_REWRITE_PHASE
    8)NGX_HTTP_POST_ACCESS_PHASE
    9)NGX_HTTP_TRY_FILES_PHASE
    剩余的7个阶段,HTTP模块均能介入,每个阶段可介入模块的个数也是没有限制的,多个HTTP模块可同时介入同一阶段并作用于同一请求。

发表评论

电子邮件地址不会被公开。 必填项已用*标注