SaltStack安装与配置

介绍

本来已经在虚拟机中安装好了 Salt。不想测试时无意运行了 salt ‘*’ pip.install salt,可能与原来用脚本安装 Salt 起了冲突。导致 Salt 命令各种报错。不得不重装 Salt,顺带记录下相关的步骤。

安装

下载安装 SALT MASTER(包含了 MINION)

curl -L https://bootstrap.saltstack.com -o install_salt.sh
sudo sh install_salt.sh -P -M

下载安装 SALT MINION

curl -L https://bootstrap.saltstack.com -o install_salt.sh
sudo sh install_salt.sh -P

配置

配置文件位置:/etc/salt/master 和 /etc/salt/minion

通过 KEY 建立 MASTER 和 MINION 的连接

salt-key -F master

复制 master.pub 对应的内容(指纹)。粘贴到 minion 配置文件的 master_finger的值,重启 minion。

查看所有的 key

salt-key -L

确认后接受 key

salt-key -A
salt-key -L

验证

假设 minion 为 alpha,

# salt alpha test.ping
alpha:
    True

如果结果不对重点检查 master_finger 的值有没有复制错了????。

补充:Salt Restful api 接口配置

安装 salt-api

yum install salt-api

创建用户

为了做权限控制(pam),创建用户 saltdev,并设置密码

adduser saltdev
passwd saltdev

配置和启动

增加 master 相关配置

rest_cherrypy:
  port: 8000
  disable_ssl: True
#  ssl_crt: /etc/pki/tls/certs/localhost.crt
#  ssl_key: /etc/pki/tls/certs/localhost.key

external_auth:
  pam:
    saltdev:
      - .*
      - '@runner'
      - '@wheel'

重启 master,启动 salt-api。

验证

访问相应 ip 的 8000 端口,例如 localhost:8000,查看是否有返回结果。

salt-minion和salt-master之间如何重新认证

随心笔记,如有错误 欢迎指正。

  • salt minion 和salt master之间重新建立认证

  • 修改了minion端的id之后 比如修改了hostname之后,

  • minion端会将minion的id 存放在/etc/salt/minion_id

文件中,重启不会改变。所以要重新认证就需要以下2步:

1、清空minion_id

>/etc/salt/minion_id

2.删除minion存放masterkey的文件pki文件夹下所以的东西

rm -rf /etc/salt/pki/*

3.重启minion

service salt-minion restart

在master端:

删除pki文件之后,重启即可:

rm -rf /etc/salt/pki/*

service salt-master restart

之后就可以salt-key看到新的minion id了。

lsyncd实时同步搭建指南——取代rsync+inotify

一、几大实时同步工具比较

1、inotify + rsync

最近一直在寻求生产服务服务器上的同步替代方案,原先使用的是inotify + rsync,但随着文件数量的增大到100W+,目录下的文件列表就达20M,在网络状况不佳或者限速的情况下,变更的文件可能10来个才几M,却因此要发送的文件列表就达20M,严重减低的带宽的使用效率以及同步效率;更为要紧的是,加入inotifywait在5s内监控到10个小文件发生变化,便会触发10个rsync同步操作,结果就是真正需要传输的才2-3M的文件,比对的文件列表就达200M。使用这两个组合的好处在于,它们都是最基本的软件,可以通过不同选项做到很精确的控制,比如排除同步的目录,同步多个模块或同步到多个主机。

搭建过程参考 Linux下同步工具inotify+rsync使用详解(https://segmentfault.com/a/1190000002427568) 或 这里(http://seanlook.com/2014/12/12/rsync_inotify_setup/)。

2、sersync

后来听同事说 sersync 这么个工具可以提高同步的性能,也解决了同步大文件时出现异常的问题,所以就尝试了一下。sersync是国内的一个开发者开源出来的,使用c++编写,采用多线程的方式进行同步,失败后还有重传机制,对临时文件过滤,自带crontab定时同步功能。网上看到有人说性能还不错,说一下我的观点:

  • 国产开源,文档不是很全,在2011年之后就没更新了(googlecode都要快关闭了,其实可以转交其他人维护),网上关于它的使用和讨论都止于10年了
  • 采用xml配置文件的方式,可读性比较好,但是有些原生的有些功能没有实现就没法使用了
  • 无法实现多目录同步,只能通过多个配置文件启动多个进程
  • 文件排除功能太弱。这个要看需求,不是每个人都需要排除子目录。而对于我的环境中,这个功能很重要,而且排除的规则较多
  • 虽然提供插件的功能,但很鸡肋,因为软件本身没有持续更新,也没有看到贡献有其它插件出现(可能是我知识面不够,还用不到里面的refreshCDN plugin)。

虽然不懂c++,但大致看了下源码 FileSynchronize,拼接rsync命令大概在273行左右,最后一个函数就是排除选项,简单一点可以将–exclude=改成–eclude-from来灵活控制。有机会再改吧。

另外,在作者的文章 Sersync服务器同步程序 项目简介与设计框架 评论中,说能解决上面 rsync + inotify中所描述的问题。阅读了下源码,这个应该是没有解决,因为在拼接rsync命令时,后面的目的地址始终是针对module的,只要执行rsync命令,就会对整个目录进行遍历,发送要比对的文件列表,然后再发送变化的文件。sersync只是减少了监听的事件,减少了rsync的次数——这已经是很大的改进,但每次rsync没办法改变。(如有其它看法可与我讨论)

其实我们也不能要求每一个软件功能都十分健全,关键是看能否满足我们当下的特定的需求。所谓好的架构不是设计出来的,而是进化来的。目前使用sersync2没什么问题,而且看了它的设计思路应该是比较科学的,特别是过滤队列的设计。双向同步看起来也是可以实现。

3、lsyncd

废话说这么多,本文就是介绍它了。有些博客说lsyncd是谷歌开源的,实际不是了,只是托管在了googlecode上而已,幸运的是已经迁移到github了:https://github.com/axkibe/lsyncd 。

Lysncd 实际上是lua语言封装了 inotify 和 rsync 工具,采用了 Linux 内核(2.6.13 及以后)里的 inotify 触发机制,然后通过rsync去差异同步,达到实时的效果。我认为它最令人称道的特性是,完美解决了 inotify + rsync海量文件同步带来的文件频繁发送文件列表的问题 —— 通过时间延迟或累计触发事件次数实现。另外,它的配置方式很简单,lua本身就是一种配置语言,可读性非常强。lsyncd也有多种工作模式可以选择,本地目录cp,本地目录rsync,远程目录rsyncssh。

实现简单高效的本地目录同步备份(网络存储挂载也当作本地目录),一个命令搞定。

二、使用 lsyncd 本地目录实时备份

这一节实现的功能是,本地目录source实时同步到另一个目录target,而在source下有大量的文件,并且有部分目录和临时文件不需要同步。

1、安装lsyncd

安装lsyncd极为简单,已经收录在ubuntu的官方镜像源里,直接通过apt-get install lsyncd就可以。
在Redhat系(我的环境是CentOS 6.2 x86_64 ),可以手动去下载 lsyncd-2.1.5-6.fc21.x86_64.rpm,但首先你得安装两个依赖yum install lua lua-devel。也可以通过在线安装,需要epel-release扩展包:

# rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# yum install lsyncd

源码编译安装

从源码编译安装可以使用最新版的lsyncd程序,但必须要相应的依赖库文件和编译工具:yum install lua lua-devel asciidoc cmake。

从 googlecode lsyncd 上下载的lsyncd-2.1.5.tar.gz,直接./configure、make && make install就可以了。

从github上下载lsyncd-master.zip 的2.1.5版本使用的是 cmake 编译工具,无法./configure:

# uzip lsyncd-master.zip
# cd lsyncd-master
# cmake -DCMAKE_INSTALL_PREFIX=/usr/local/lsyncd-2.1.5
# make && make install

我这个版本编译时有个小bug,如果按照INSTALL在build目录中make,会提示:

[100%] Generating doc/lsyncd.1
Updating the manpage
a2x: failed: source file not found: doc/lsyncd.1.txt
make[2]: *** [doc/lsyncd.1] Error 1
make[1]: *** [CMakeFiles/manpage.dir/all] Error 2
make: *** [all] Error 2

解决办法是要么直接在解压目录下cmake,不要mkdir build,要么在CMakeList.txt中搜索doc字符串,在前面加上${PROJECT_SOURCE_DIR}。

2、lsyncd.conf

下面都是在编译安装的情况下操作。

2.1 lsyncd同步配置

# cd /usr/local/lsyncd-2.1.5
# mkdir etc var
# vi etc/lsyncd.conf
settings {
    logfile      ="/usr/local/lsyncd-2.1.5/var/lsyncd.log",
    statusFile   ="/usr/local/lsyncd-2.1.5/var/lsyncd.status",
    inotifyMode  = "CloseWrite",
    maxProcesses = 7,
    -- nodaemon =true,
    }

sync {
    default.rsync,
    source    = "/tmp/src",
    target    = "/tmp/dest",
    -- excludeFrom = "/etc/rsyncd.d/rsync_exclude.lst",
    rsync     = {
        binary    = "/usr/bin/rsync",
        archive   = true,
        compress  = true,
        verbose   = true
        }
    }

到这启动 lsycnd 就可以完成实时同步了,默认的许多参数可以满足绝大部分需求,非常简单。

2.2 lsyncd.conf配置选项说明

settings

里面是全局设置,–开头表示注释,下面是几个常用选项说明:

  • logfile 定义日志文件
  • stausFile 定义状态文件
  • nodaemon=true 表示不启用守护模式,默认
  • statusInterval 将lsyncd的状态写入上面的statusFile的间隔,默认10秒
  • inotifyMode 指定inotify监控的事件,默认是CloseWrite,还可以是Modify或CloseWrite or Modify
  • maxProcesses 同步进程的最大个数。假如同时有20个文件需要同步,而maxProcesses = 8,则最大能看到有8个rysnc进程
  • maxDelays 累计到多少所监控的事件激活一次同步,即使后面的delay延迟时间还未到

sync

里面是定义同步参数,可以继续使用maxDelays来重写settings的全局变量。一般第一个参数指定lsyncd以什么模式运行:rsync、rsyncssh、direct三种模式:

  • default.rsync :本地目录间同步,使用rsync,也可以达到使用ssh形式的远程rsync效果,或daemon方式连接远程rsyncd进程;
  • default.direct :本地目录间同步,使用cp、rm等命令完成差异文件备份;
  • default.rsyncssh :同步到远程主机目录,rsync的ssh模式,需要使用key来认证

  • source 同步的源目录,使用绝对路径。

  • target 定义目的地址.对应不同的模式有几种写法:

    • /tmp/dest :本地目录同步,可用于direct和rsync模式
    • 172.29.88.223:/tmp/dest :同步到远程服务器目录,可用于rsync和rsyncssh模式,拼接的命令类似于/usr/bin/rsync -ltsd –delete –include-from=- –exclude=* SOURCE TARGET,剩下的就是rsync的内容了,比如指定username,免密码同步
    • 172.29.88.223::module :同步到远程服务器目录,用于rsync模式

三种模式的示例会在后面给出。

  • init 这是一个优化选项,当init = false,只同步进程启动以后发生改动事件的文件,原有的目录即使有差异也不会同步。默认是true

  • delay 累计事件,等待rsync同步延时时间,默认15秒(最大累计到1000个不可合并的事件)。也就是15s内监控目录下发生的改动,会累积到一次rsync同步,避免过于频繁的同步。(可合并的意思是,15s内两次修改了同一文件,最后只同步最新的文件)

  • excludeFrom 排除选项,后面指定排除的列表文件,如excludeFrom = “/etc/lsyncd.exclude”,如果是简单的排除,可以使用exclude = LIST。
    这里的排除规则写法与原生rsync有点不同,更为简单:

    • 监控路径里的任何部分匹配到一个文本,都会被排除,例如/bin/foo/bar可以匹配规则foo
    • 如果规则以斜线/开头,则从头开始要匹配全部
    • 如果规则以/结尾,则要匹配监控路径的末尾
    • ?匹配任何字符,但不包括/
    • *匹配0或多个字符,但不包括/
    • **匹配0或多个字符,可以是/
  • delete 为了保持target与souce完全同步,Lsyncd默认会delete = true来允许同步删除。它除了false,还有startup、running值,请参考 Lsyncd 2.1.x ‖ Layer 4 Config ‖ Default Behavior。

rsync

(提示一下,delete和exclude本来都是rsync的选项,上面是配置在sync中的,我想这样做的原因是为了减少rsync的开销)

  • bwlimit 限速,单位kb/s,与rsync相同(这么重要的选项在文档里竟然没有标出)
  • compress 压缩传输默认为true。在带宽与cpu负载之间权衡,本地目录同步可以考虑把它设为false
  • perms 默认保留文件权限。
  • 其它rsync的选项

其它还有rsyncssh模式独有的配置项,如host、targetdir、rsync_path、password_file,见后文示例。rsyncOps={“-avz”,”–delete”}这样的写法在2.1.*版本已经不支持。

lsyncd.conf可以有多个sync,各自的source,各自的target,各自的模式,互不影响。

3、启动lsyncd

使用命令加载配置文件,启动守护进程,自动同步目录操作。

lsyncd -log Exec /usr/local/lsyncd-2.1.5/etc/lsyncd.conf

4、lsyncd.conf其它模式示例

以下配置本人都已经过验证可行,必须根据实际需要裁剪配置:

settings {
    logfile ="/usr/local/lsyncd-2.1.5/var/lsyncd.log",
    statusFile ="/usr/local/lsyncd-2.1.5/var/lsyncd.status",
    inotifyMode = "CloseWrite",
    maxProcesses = 8,
    }


-- I. 本地目录同步,direct:cp/rm/mv。 适用:500+万文件,变动不大
sync {
    default.direct,
    source    = "/tmp/src",
    target    = "/tmp/dest",
    delay = 1
    maxProcesses = 1
    }

-- II. 本地目录同步,rsync模式:rsync
sync {
    default.rsync,
    source    = "/tmp/src",
    target    = "/tmp/dest1",
    excludeFrom = "/etc/rsyncd.d/rsync_exclude.lst",
    rsync     = {
        binary = "/usr/bin/rsync",
        archive = true,
        compress = true,
        bwlimit   = 2000
        } 
    }

-- III. 远程目录同步,rsync模式 + rsyncd daemon
sync {
    default.rsync,
    source    = "/tmp/src",
    target    = "[email protected]::module1",
    delete="running",
    exclude = { ".*", ".tmp" },
    delay = 30,
    init = false,
    rsync     = {
        binary = "/usr/bin/rsync",
        archive = true,
        compress = true,
        verbose   = true,
        password_file = "/etc/rsyncd.d/rsync.pwd",
        _extra    = {"--bwlimit=200"}
        }
    }

-- IV. 远程目录同步,rsync模式 + ssh shell
sync {
    default.rsync,
    source    = "/tmp/src",
    target    = "172.29.88.223:/tmp/dest",
    -- target    = "[email protected]:/remote/dest",
    -- 上面target,注意如果是普通用户,必须拥有写权限
    maxDelays = 5,
    delay = 30,
    -- init = true,
    rsync     = {
        binary = "/usr/bin/rsync",
        archive = true,
        compress = true,
        bwlimit   = 2000
        -- rsh = "/usr/bin/ssh -p 22 -o StrictHostKeyChecking=no"
        -- 如果要指定其它端口,请用上面的rsh
        }
    }

-- V. 远程目录同步,rsync模式 + rsyncssh,效果与上面相同
sync {
    default.rsyncssh,
    source    = "/tmp/src2",
    host      = "172.29.88.223",
    targetdir = "/remote/dir",
    excludeFrom = "/etc/rsyncd.d/rsync_exclude.lst",
    -- maxDelays = 5,
    delay = 0,
    -- init = false,
    rsync    = {
        binary = "/usr/bin/rsync",
        archive = true,
        compress = true,
        verbose   = true,
        _extra = {"--bwlimit=2000"},
        },
    ssh      = {
        port  =  1234
        }
    }

上面的内容几乎涵盖了所有同步的模式,其中第III个要求像rsync一样配置rsyncd服务端,见本文开头。第IV、V配置ssh方式同步,达到的效果相同,但实际同步时你会发现每次同步都会提示输入ssh的密码,可以通过以下方法解决:

在远端被同步的服务器上开启ssh无密码登录,请注意用户身份:

user$ ssh-keygen -t rsa
一路回车...
user$ cd ~/.ssh
user$ cat id_rsa.pub >> authorized_keys

把id_rsa私钥拷贝到执行lsyncd的机器上

user$ chmod 600 ~/.ssh/id_rsa
测试能否无密码登录
user$ ssh [email protected]

三、lsyncd的其它功能

lsyncd的功能不仅仅是同步,官方手册 Lsyncd 2.1.x ‖ Layer 2 Config ‖ Advanced onAction 高级功能提到,还可以监控某个目录下的文件,根据触发的事件自己定义要执行的命令,example是监控某个某个目录,只要是有jpg、gif、png格式的文件参数,就把它们转成pdf,然后同步到另一个目录。正好在我运维的一个项目中有这个需求,现在都是在java代码里转换,还容易出现异常,通过lsyncd可以代替这样的功能。但,门槛在于要会一点点lua语言(根据官方example还是可以写出来)。

另外偶然想到个问题,同时设置了maxDelays和delay,当监控目录一直没有文件变化了,也会发生同步操作,虽然没有可rsync的文件。

TO-DO:

  • 其它同步工具:csync2,clsync,btsync,drdb 。
  • lsyncd双向同步:GlusterFS

php-fpm性能优化实例分析

导言

Web服务器的CPU指标和MEM指标异常,不稳定?可能是PHP-FPM进程重启机制的问题导致的,一同和百度外卖探索下如何优化吧。

摘要

通过优化PHP-FPM进程重启机制,改善线上服务器CPU_IDLE和MEM_USED波动的问题,使服务器资源利用率更加平滑可靠。

未分类

背景

外卖交易服务集群报出在监控图上CPU_IDLE波动剧烈,如图所示。

事实上一直以来,不仅PU_IDLE存在一定的波动,MEM_USED的周期性断崖式下降再回升也早已司空见惯。那么CPU_IDLE与MEM_UESD的波动是否存在关联,追溯这种现象产生的原因,我们就必须理解PHP-FPM进程管理器的机制。

原理

在PHP5.3.3版本中,PHP-FPM正式被官方收编,作为FastCGI管理器,支持平滑停止启动进程、slow-log、动态进程、运行状态等特性。

PHP-FPM进程管理支持三种方式:static、dynamic、ondemand。我们选用的是static方式,即PHP-FPM生成固定数量的FastCGI进程,这种方式比较简单,避免了频繁开启关闭进程的开销。(在线下虚拟机环境中,进程管理可以配置成ondemand,既降低了内存需求又避免了进程数量不够用)

回到面临的问题上,CPU_IDLE和MEM_USED的周期性波动是如何产生的。首先这是一种所有的集群都存在的现象,然后交易服务集群表现尤为突出。在排查了应用程序(比如日志采集程序、定时脚本)的影响后,思路落在了PHP-FPM的一个关键参数上:max_requests。

max_requests这个参数使FastCGI进程在处理一定数量的请求后自动重启,以此避免第三方扩展内存泄漏产生破坏性影响。打开线上配置,发现外卖交易服务集群中配置该参数过小,为1000,这便造成了在请求高峰期,FastCGI频繁重启,对CPU产生了负担。于是将max_requests参数调整为10000后,CPU_IDLE表现得到了改善,如图。

未分类

但是经过观察发现,CPU_IDLE和MEM_USED周期性波动的问题并没有根除,效果如图。

未分类

这很好理解,我们调大max_requests参数,但是FastCGI重启机制依然生效,每个请求都会计数,当计数到达max_request之后,cgi进程会执行 fcgi_finish_request退出进程,子进程退出,fpm-master进程会收到SIGCHLD信号,运行fpm_children_bury重启进程,重启的方式是fork一个子进程。

FastCGI进程通过unix socket承接Nginx请求,负载较为均衡,生产环境流量大,PHP进程数配置较大,数以百计的FastCGI会在同一时间到达 max_requests上限而进行重启,这便造成了CPU_IDLE和MEM_USED周期性波动。

优化

max_requests的初衷是为了避免第三方扩展引起的内存泄漏问题,虽然线上环境使用的扩展经过分析和测试,并没有严重的内存泄漏问题,但是由于扩展内部使用的第三方库太多,并无法完全避免内存泄漏问题,同时max_requests机制很适合FastCGI多进程环境,以较小的代价,换取内存泄漏的长治久安。

为了避免CPU_IDLE和MEM_USED周期波动,同时保持max_requests机制,需要在PHP-FPM源码上稍作修改。FastCGI进程在启动时,设置max_requests,此时只要将max_requests配置参数散列开,使FastCGI进程分别配置不同的值,即可达到效果。

具体代码在sapi/fpm/fpm/fpm.c,修改如下:

php_mt_srand(GENERATE_SEED()); *max_requests=fpm_globals.max_requests+php_mt_rand()&8191;

总结

经过修改上线,对比效果见下图

未分类

至此CPU_IDLE和MEM_USED已经告别了周期性波动,避免了CPU计算资源产生浪涌效果,内存占用数据也更加真实可靠。

php-fpm启动、关闭、重启

在对php-fpm进行操作之前,我们需要首先对php-fpm.conf文件进行配置(完整配置见[这里]),将pid指向安装目录的var/run/php-fpm.pid文件,只有这样fpm的进程才会被写入这个文件/usr/local/php-7.0.4/var/run/php-fpm.pid。

查看进程:

ps -ef |grep php-fpm

关闭:

kill -INT `cat /usr/local/php-7.0.4/var/run/php-fpm.pid`

或者:pkill php-fpm

启动:

/usr/local/php-7.0.4/sbin/php-fpm

为OpenResty项目编写自定义Nginx C模块

有些时候,我们需要通过 Lua 代码操作 Nginx 里面的某些状态,但是想要的 API 并不存在于 OpenResty 之内。这时候,可以选择编写一个 Nginx C 模块,然后暴露出可供 Lua 调用的接口。

本文中,我们会分别探讨,如何通过 Nginx 变量或 FFI 的方式去提供 Lua 调用得到的接口。

文中的示例代码可以在 ngx_http_example_or_module 找到。

通过 Nginx 变量提供接口

ngx.var.variable= 在调用的时候,会先查找变量 variable 对应的 handler(一个在 Nginx 内注册的 C 函数),如果 handler 存在,会去调用该 handler。
这意味着,如果我们定义了一个 Nginx 变量和对应的 handler,我们就可以通过在 Lua 代码里调用 ngx.var.variable= 来触发该 handler。

空说无益,先上示例。

在 Nginx 里面我们可以通过 limit_rate 和 limit_rate_after 两个指令来限制响应给客户端的速率。前者决定了限速的多少,后者决定了从什么时候开始限速。当然更多的时候我们需要动态去调整这两个指标。

limit_rate 对应有一个 Nginx 内置的变量, $limit_rate,我们可以修改该变量来达到动态调整的目的。相关的 Lua 代码是 ngx.var.limit_rate = limit_rate。但是并不存在 $limit_rate_after 这样一个变量。

不用担心。因为我们可以自己加上。

// ngx_http_example_or_module.c
// 定义变量和它的 getter/setter
static ngx_http_variable_t  ngx_http_example_or_variables[] = {
    { ngx_string("limit_rate_after"), ngx_http_variable_request_set_size,
      ngx_http_variable_request_get_limit_rate_after,
      offsetof(ngx_http_request_t, limit_rate_after),
      NGX_HTTP_VAR_CHANGEABLE|NGX_HTTP_VAR_NOCACHEABLE, 0 },
    { ngx_null_string, NULL, NULL, 0, 0, 0 }
};

// getter 和 setter 的实现在 GitHub 上的示例代码里有,这里就不贴上了。

通过 FFI 提供接口

不过在大多数情况下,我们并不需要借助变量来间接调用 Nginx C 函数。我们完全可以借助 LuaJIT 的 FFI,直接调用 Nginx C 函数。

lua-resty-murmurhash2 就是一个现成的例子。

下面让我们再看另外一个例子,通过 Lua 代码来获取当前的 Nginx 错误日志等级。

在开发中,我们有时需要在测试环境中通过日志来记录某个 table 的值,比如 ngx.log(ngx.INFO, cjson.encode(res))。

在生产环境里,我们会设置日志等级为 error,这样就不会输出 table 的值。但是日志等级无论是多少,cjson.encode 都是必然会被调用的。

不幸的是,这行代码所在的路径非常热,我们需要避免无谓的 json encode 操作。如果能获取实际的日志等级,判断是否为 error,来决定是否调用 cjson.encode,就能省下这一笔开销。

要实现这一功能,仅需加个获取当前配置的日志等级的 Nginx C 函数和对应的 Lua 接口。

我们可以像这样提供一个 Lua 接口:

-- lib/example_or.lua
...

if not pcall(ffi.typeof, "ngx_http_request_t") then
    ffi.cdef[[
        struct ngx_http_request_s;
        typedef struct ngx_http_request_s  ngx_http_request_t;
    ]]
end

ffi.cdef[[
int ngx_http_example_or_ffi_get_error_log_level(ngx_http_request_t *r);
]]

function _M.get_error_log_level()
    local r = getfenv(0).__ngx_req
    return tonumber(C.ngx_http_example_or_ffi_get_error_log_level(r))
end

对应的 Nginx C 函数很简单:

int
ngx_http_example_or_ffi_get_error_log_level(ngx_http_request_t *r)
{
    ngx_log_t                   *log;
    int                          log_level;

    if (r && r->connection && r->connection->log) {
        log = r->connection->log;

    } else {
        log = ngx_cycle->log;
    }

    log_level = log->log_level;
    if (log_level == NGX_LOG_DEBUG_ALL) {
        log_level = NGX_LOG_DEBUG;
    }

    return log_level;
}

使用时直接拿它跟特定的 Nginx 日志等级常量比较即可:

-- config.lua
-- 目前 Nginx 不支持动态变更日志等级,所以可以把日志等级缓存起来
local example_or = require "lib.example_or"
_M.log_leve = example_or.get_error_log_level()


-- in other file
local config = require "common.config"
local log_level = config.log_level
if log_level >= ngx.WARN then
    -- 错误日志等级是 warn 或者 info 一类
    ngx.log(ngx.WARN, "log a warning event")
else
    -- 错误日志等级是 error 一类
    ngx.log(ngx.WARN, "do not log another warning event")
end

OpenResty lua优化 – 避免全局变量的使用

lua-variable-scope

在代码中导入模块时应注意一些细节,推介使用如下格式:

local xxx = require('xxx')

而非:

require('xxx')

理由如下:从设计上讲,全局环境的生命周期和一个Nginx的请求的生命周期是相同的。为了做到会话隔离,每个请求都有自己的Lua全局变量环境。Lua模块在第一次请求打到服务器上的时候被加载起来,通过package.loaded表内建的require()完成缓存,为后续代码复用。并且一些Lua模块内的module()存在边际问题,对加载完成的模块设置成全局表变量,但是这个全局变量在请求处理最后将被清空,并且每个后续请求都拥有自己(干净)的全局空间。所以它将因为访问nil值收到Lua异常。

一般来说,在ngx_lua的上下文中使用Lua全局变量真的不是什么好主意:

  • 滥用全局变量的副作用会对并发场景产生副作用,比如当使用者把这些变量看作是本地变量的时候;

  • Lua的全局变量需要向上查找一个全局环境(只是一个Lua表),代价比较高;

  • 一些Lua的全局变量引用只是拼写错误,这会导致出错很难排查。

所以,我们极力推介在使用变量的时候总是使用local来定义以限定起生效范围是有理由的。

使用工具(lua-releng tool)[https://github.com/openresty/nginx-devel-utils/blob/master/lua-releng]查找你的Lua源文件:

$ lua-releng     
Checking use of Lua global variables in file lib/foo/bar.lua ...  
    1       [1489]  SETGLOBAL       7 -1    ; contains
    55      [1506]  GETGLOBAL       7 -3    ; setvar
    3       [1545]  GETGLOBAL       3 -4    ; varexpand

上述输出说明文件lib/foo/bar.lua的1489行写入一个名为contains的全局变量,1506行读取一个名为setvar的全局变量,1545行读取一个名为varexpand的全局变量,

这个工具能保证Lua模块中的局部变量全部是用local关键字定义过的,否则将会抛出一个运行时库。这样能阻止类似变量这样的资源的竞争。理由请参考(Data Sharing within an Nginx Worker)[http://wiki.nginx.org/HttpLuaModule#Data_Sharing_within_an_Nginx_Worker]

通过指定编译参数缩小Nginx编译的大小

默认的nginx编译选项里居然是用debug模式(-g)的,debug模式会插入很多跟踪和ASSERT之类,造成编译以后一个nginx有好几兆。

百度之后有以下两种方法:

  • 方法一 :

去掉nginx的debug模式编译,编译以后只有375K(nginx-0.5.33, gcc4)。

在 auto/cc/gcc,最后几行有:

# debug
CFLAGS=”$CFLAGS -g”

注释掉或删掉这几行,重新编译即可。

  • 方法二 :

一般来说,默认./configure 生成的makefile文件都将带上-g选项,这对于利用gdb调试nginx是非常必要的,但会debug模式会插入很多跟踪和ASSERT之类,造成编译的nginx文件很大。

编辑去掉objs/Makefile文件中下面这一行的 -g

CFLAGS = -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g

使用Shell统计分析Nginx网站日志自动屏蔽频繁访问的IP

近来总感觉网站被恶意访问,造成宽带和服务器拖慢,于是决定研究一下之前看到关于分析 Nginx 网站日志,获取频繁访问的 IP 进行自动屏蔽的 Shell 脚本。

一、工作原理

Nginx 配置中,可以通过 allow , deny ip 来进行权限屏蔽。因此,需要创建一个 blockip.conf ,将屏蔽的 IP 保存在里面,并加载至 Nginx 配置中。例子:

allow 1.1.1.1; 
allow 1.1.1.2;
deny all;

全站屏蔽:include blockip.conf; 放到 http {} 语句块。

单站屏蔽:include blockip.conf; 放到对应网站 server{} 语句块。

二、Shell 脚本

注意:相关参数需要自行配置。脚本示例的环境配置是根据 LNMP 安装包而定。

#!/bin/bash
nginxPath=/usr/local/nginx/
wwwPath=/home/wwwlogs/
tail -n50000 $wwwPath/access.log |awk '{print $1,$12}' |grep -i -v -E "google|yahoo|baidu|msnbot|FeedSky|sogou" |awk '{print $1}'|sort|uniq -c|sort -rn |awk '{if($1>1000) print "deny "$2 ";"}' >> $nginxPath/conf/blockip.conf
sort $nginxPath/conf/blockip.conf | uniq -c |awk '{print "deny "$3}' > $nginxPath/conf/blockip.conf
/etc/init.d/nginx reload

三、定时任务

把 Shell 脚本改变权限并添加到定时计划中。

# 比如 Shell 脚本名为 blockip.sh 所在目录为 /root/ 定时任务为每天晚上11点30分执行
30 23 * * * /root/blockip.sh

nginx安装配置naxsi waf防火墙

Naxsi 是第三方 nginx 模块 ,它和 Modsecurity 都是开源 WAF ,但是它们的防御模式不同。 Naxsi 不依赖像防病毒软件这样的签名库,因此不会被“未知”攻击模式所规避(就像我们平常说的主动防御)。Naxsi 和其他 WAF 之间的另一个主要区别就是仅过滤 GET 和 POST 请求。

未分类

我之前一直在用 modsecurity ,效果还不错,但是它对 nginx 支持真的不太好~.~ 。经常会产生大量错误日志,不过这个并不影响它的正常功能,只是看着揪心。让我想更换它的主要原因是 Modsecurity 经常在处理某个请求(正常或不正常)时,会突然导致 CPU 99.9% 以上,这是最不能忍受的。

我们先来简单对比下 Naxsi 和 Modsecurity :

未分类

在日常使用中,可以发现 Modsecurity 具有非常严格的防御规则(误报挺多的),并且规则支持较好(有强大的后台?)。如果你使用 Apache 服务器,推荐使用 Modsecurity WAF。如果你使用的是 Nginx 服务器,建议先尝试使用 Naxsi 。

下面就来在 Centos 下编译安装 Nginx + Naxsi WAF 。Modsecurity 的编译安装在这里(http://www.wuedc.com/nginx-installed-configuration-modsecurity-waf/)。

编译 Nginx + Naxsi

首先先运行:

nginx -V

然后可以看到现有的模块,复制保存一下备用。

configure arguments: --prefix=/usr/local/nginx --user=www --group=www --with-http_stub_status_module --with-http_v2_module --with-http_ssl_module --with-ipv6 --with-http_gzip_static_module --with-http_realip_module --with-http_flv_module --with-openssl=../openssl-1.0.2h --with-pcre=../pcre-8.38 --with-pcre-jit --with-ld-opt=-ljemalloc

下载 Nginx 和 Naxsi

Naxsi 应该使用所有高于 0.8.X 的 Nginx 版本。 Naxsi 版本可以在 https://github.com/nbs-system/naxsi 这里,选择 Branch –> Tags 查看版本号。

下载 Nginx 和 Naxsi ,并解压,然后进入解压后的 Nginx 目录:

wget http://nginx.org/download/nginx-x.x.xx.tar.gz
wget https://github.com/nbs-system/naxsi/archive/x.xx.x.tar.gz
tar xvzf nginx-x.x.xx.tar.gz 
tar xvzf naxsi-x.xx.tar.gz
cd nginx-x.x.xx/

Naxsi 不要求任何特定的依赖,它需要的 libpcre ,libssl ,zlib ,gzip 这些 Nginx 已经集成了。

然后编译(记得在 ./configure 后面加上 –add-module=../naxsi-x.xx/naxsi_src/ 和你之前备份的模块):

./configure --conf-path=/etc/nginx/nginx.conf --add-module=../naxsi-x.xx/naxsi_src/ 
--error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body 
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log 
--http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock 
--pid-path=/var/run/nginx.pid --with-http_ssl_module 
--without-mail_pop3_module --without-mail_smtp_module 
--without-mail_imap_module --without-http_uwsgi_module 
--without-http_scgi_module --with-ipv6 --prefix=/usr
make
make install

等待编译完成。Naxsi 安装完成。

nginx/naxsi 基本配置

首先将 naxsi 目录下的 naxsi_core.rules 拷贝至 nginx.conf 所在目录。

http 部分配置

打开 nginx.conf 在 http 部分配置:

http {
 include naxsi_core.rules;  #导入 naxsi 核心规则
 ...
}

server 部分配置

在 nginx.conf 的 server 部分配置:

location / {
   #开启 naxsi
   SecRulesEnabled;
   #开启学习模式
   LearningMode;
   #定义阻止请求的位置
   DeniedUrl "/50x.html"; 
   #CheckRules, 确定 naxsi 何时采取行动
   CheckRule "$SQL >= 8" BLOCK;
   CheckRule "$RFI >= 8" BLOCK;
   CheckRule "$TRAVERSAL >= 4" BLOCK;
   CheckRule "$EVADE >= 4" BLOCK;
   CheckRule "$XSS >= 8" BLOCK;
   #naxsi 日志文件
   error_log /.../foo.log;
   ...
  }
  error_page   500 502 503 504  /50x.html;
  #This is where the blocked requests are going
  location = /50x.html {
  return 418; #I'm a teapot o/
  }

server 完整示例配置

server {
listen 80 default;
access_log /wwwlogs/access_nginx.log combined;
root /www/site;
index index.html index.htm index.php;
location ~ [^/].php(/|$) {        
    SecRulesEnabled; 
    #LearningMode;     
    DeniedUrl "/RequestDenied";
    CheckRule "$SQL >= 8" BLOCK;
    CheckRule "$RFI >= 8" BLOCK;
    CheckRule "$TRAVERSAL >= 4" BLOCK;
    CheckRule "$EVADE >= 4" BLOCK;
    CheckRule "$XSS >= 8" BLOCK;    
    error_log /wwwlogs/foo.log;   
    fastcgi_pass unix:/dev/shm/php-cgi.sock;
    fastcgi_index index.php;
    include fastcgi.conf;
}
location /RequestDenied {
    return 403;
}    
location ~ .*.(gif|jpg|jpeg|png|bmp|swf|flv|ico)$ {
    expires 30d;
    access_log off;
    }
location ~ .*.(js|css)?$ {
    expires 7d;
    access_log off;
    }
}

测试

测试 nginx 配置

/nginx/sbin/nginx -t
nginx: the configuration file /nginx/conf/nginx.conf syntax is ok
nginx: configuration file /nginx/conf/nginx.conf test is successful

重启 nginx

service nginx reload

防御测试

浏览器中打开 http://www.test.com/?a=<>‘ ,出现 403 错误,并且在 foo.log 中出现 NAXSI_FMT 开头的日志。恭喜你 Naxsi 启用成功。

白名单规则

Naxsi 社区提供了一些常用的白名单规则,例如 wordpress 。可以在 https://github.com/nbs-system/naxsi-rules 下载白名单规则。

然后将规则 include 到 server 内的 location 中。重启 nginx 即可。不过目前这些白名单最近的修改日期显示是1年前~.~ ,可根据自身需要添加白名单规则。

详细的白名单规则以及 Naxsi 其他支持,可参考 Naxsi WIKI。