WEB应用

Haproxy安装部署文档及多配置文件管理方案

最近我在负责一个统一接入层的建设项目,涉及到Haproxy和ospf的运维部署,本文分享一下我在部署Haproxy之后整理的运维部署规范,并实现了Haproxy的多配置文件管理方案。 一、部署安装 1、下载源码包 最新stable版本下载地址:http://www.haproxy.org/download/1.7/src/haproxy-1.7.9.tar.gz 2、编译安装 3、创建目录 二、软件配置 熟悉Nginx和Apache的朋友都知道,这两个Webservice都支持include加载多个配置文件的语法,但是Haproxy并不支持!如果现网映射规则非常多,那么haproxy.cfg这个配置文件就跟臭袜子一样,又臭又长! 因此,我也是翻遍了国外的各种论坛帖子,终于发现一种变相实现Haproxy多配置文件的方案。其实,Hparoxy是支持多配置文件的,但是不是include语法,而是在启动的时候多次使用-f 拼接配置文件,比如: 因此,我们可以在配置文件目录以及启动脚本上做点改变,让Haproxy支持多配置文件。 1、路径约定: 待上线的 tcp 映射规则存放目录:/usr/local/haproxy/conf/ready/tcp 待上线的 http 映射规则存放目录:/usr/local/haproxy/conf/ready/http 已上线的 tcp 映射规则存放目录:/usr/local/haproxy/conf/enabled/tcp 已上线的 http 映射规则存放目录:/usr/local/haproxy/conf/enabled/http Ps:本文为多配置模式,enabled 里面的配置为软链接形式,软链接至ready对应配置文件,方便管理。 2、配置模板 ①、主配置:haproxy.cfg ②、http 扩展配置文件模板 ③、tcp 扩展配置文件模板 Ps:多配置模式中,多个frontend必须绑定不同的IP或者端口,否则数据会串,导致映射到不同的后端而报错。因此,同一个IP+端口下的映射务必配置到同一个frontend模块内。 三、系统服务 1、服务脚本 对比已有的Haproxy脚本,我编写的时候新增了如下实用功能: 支持配置文件语法测试 支持进程的监控(自拉起)功能 重启之前会先检测配置语法,规避因配置错误导致重启后进程挂掉 支持多配置文件模式(按照前文约定目录存放拓展配置,脚本将自动识别) 下面是服务脚本代码: 保存为 /usr/local/haproxy/sbin/ctrl.sh,赋可执行权限,如下注册系统服务: 服务控制: 2、配置自拉起 全部完成后,最终目录结构如下: 四、日志配置 配置rsyslog 五、小结 以上内容就是我对Haproxy部署规范的整理,并通过拼接方式变相实现了Haproxy的多配置文件管理。当然,略遗憾的是未能实现Haproxy的WEB管理方案,这个有待继续研究实现,敬请期待!
阅读全文
WEB应用

libmemcached编译安装报错解决记录

我负责的几个公司内部网站,仅集成了php原生memcache组件,不支持memcached分片存储的自动容灾方案,近期出现过几例因memcache服务器故障引起WEB爆卡的尴尬事,所以接到了一个给现网php集成memcached模块的需求。 内部的个别系统有多老、多难用我就不吐槽了,slackware、suse用过的人都知道。。。不说了,总之老老实实的编译安装吧。 memcached这个php模块依赖于libmemcached,所以集成前先要编译安装libmemcached。 按照常规编译方法,对libmemcached进行编译安装,结果如下报错: error: cinttypes: No such file or directory 查了下资料,发现是因为gcc版本过低,看了下系统当前的gcc版本,是4.1.2,决定升级之。 简单记录下gcc编译过程: 1、安装gmp 2、安装mpfr 4、安装mpc 5、安装gcc 对于这种老掉牙的服务器、程序,编译安装gcc的时候也不敢直接全局覆盖安装(编译不指定路径),于是将gcc-4.5.1安装到/usr/local/gcc-4.5.1 Ps:更多可选参数请参考官方文档。gcc编译安装必须注意依赖包的顺序,可谓环环相扣。 编译安装后,由于是指定的安装路径,所以系统用的依然是原来的gcc,所以为了本次编译libmemcached,需要将新版本软链过去,暂时使用(简单方案) 进入libmemcached源码目录继续编译,结果如下报错: error: bits/c++0x_warning.h: No such file or directory error: cstdint: No such file or directory error: tr1_impl/cinttypes: No such file or directory 真是醉人,明明都升级了还报错!没办法,继续耐着性子看信息,发现libmemcached在configure之后有如下统计信息: 赫然发现了图中还有个c++显示是4.1.2的老版本!!!于是,原来把c++给漏了,顺手补之: 再去编译安装,就行云流水,再无报错!后面编译memcached就不多说了,不会的可以参考前文教程。最后,记得取消gcc和c++的软链接,还原到4.1.2版本即可(当然,若无异常也可以继续保留)。
阅读全文
WEB应用

Nginx内容替换模块http_substitutions_filter_module及实用案例分享

说到Nginx的内容替换功能,大部分人应该都听说过Nginx内置的的subs_filter替换模块,但是这个模块有个缺憾,就是只能替换一次,而且还不支持正则表达式,这就有些鸡肋了。 不过,我们可以集成一个第三方的替换模块:ngx_http_substitutions_filter_module,来实现我们的各种需求。 经过测试,这个模块至少有如下实用功能: ①、支持多次替换 ②、支持正则替换 ③、支持中文替换 Ps:略有遗憾的是,这个替换不能使用到 if 判断模块内,否则就超神了。。。 下面,简单介绍下 ngx_http_substitutions_filter_module 的安装实用以及一些实用案例。 一、编译集成 和所有Nginx非内置模块一样,添加模块需要在编译的时候指定模块源码包来集成。当然,Tengine可以使用动态模块加载的功能,这里就不细说了。 ①、下载模块源码包并解压,最后列出目录位置备用 github手动下载地址:https://github.com/yaoweibin/ngx_http_substitutions_filter_module/ ②、在服务器上执行 nginx -V 查看当前  Nginx 编译参数,比如: ③、加上模块参数,重新编译Nginx 找到服务器上原来安装时留下的 Nginx 源码目录(如果没有请重新下载并解压,此处不赘述),进入目录后,在第②步中的参数基础上新增集成替换模块(请注意前面需要加上  ./configure ): ./configure --add-module=/root/ngx_http_substitutions_filter_module-master/ 例如: 再往后,则是make以及平滑升级,请参考之前的文章完成: Nginx在线服务状态下平滑升级或新增模块的详细操作记录 正确完成后,Nginx就具备内容替换功能了。 二、使用说明 模块的github主页其实已经有了很详细的说明了,这里就简单的做下搬运工。 使用示例: 从github给出的使用示例来看,这个模块涉及2个指令: * subs_filter_types subs_filter_types 语法: subs_filter_types mime-type 默认: subs_filter_types text/html 适用: http, server, location subs_filter_types 是用来指定替换文件类型的 默认仅仅替换text/html类型的文件。   * subs_filter subs_filter 语法: subs_filter source_str destination_str 默认: none 适用: http,server,location subs_filter 是用来替换文本的,可以使用正则 g(默认):替换匹配项。 i  :区分大小写的匹配 o : 只匹配发现的第一个。 r  : 正则匹配。 三、案例分享 ①、全站https 有了这个功能,要实现全站https也就是非常简单了,只要把本站的http://协议代码全部替换成https即可。当然,替换时要注意匹配范围,免得把不支持https的外链也一起替换了。。。 比如,将如下代码添加到网站Nginx配置内即可完成替换 ②、CDN域名替换 这个模块在CDN方面同样简单实用!比如,我们网站要用到七牛CDN,不管是纯代码还是插件,那都是靠PHP代码来进行替换的,性能肯定就不如Nginx直接替换来的简单粗暴了。 Ps:经测试,在使用正则模式时,不能使用nginx内置变量,比如:$host,否则会出现如下报错: nginx: match part cannot contain variable during regex mode in *** ③、解决前台暴露管理员账号风险 前段时间,看到有博客在说 WordPress 会在前台暴露管理员登陆账户的问题,然后给出了较为复杂的解决办法:通过修改 WordPress 内核函数来隐藏账户名。 修改内核函数,一般是非常无奈,没有其他解决方法的时候才会用到,所以,我看到这个问题第一件时间想到的办法就是替换。 使用PHP替换是非常简单的,参考博客之前分享的文章即可搞定:...
阅读全文
WEB应用

解决Nginx配置http2不生效,谷歌浏览器仍然采用http1.1协议问题

昨天一个网友通过QQ联系我,说按照我博客之前分享的http2配置教程不能生效,想请我帮忙看看。 经过测试,使用谷歌浏览器访问他的测试站点,确实没有开启http2,但他的配置和编译参数都正确的,这有点奇怪了。 不过昨天太忙就没有继续帮他分析,他只好将服务器账号和密码都留言给了我。今天中午我抽空在他服务器重新编译测试了一把,才发现原来是这么一个梗! 他在编译Nginx之前,使用的是yum安装的openssl,可能是他的yum源太陈旧,或者没配置EPEL导致yum安装的openssl版本过低!而他在编译Nginx的时候并没有使用--with-openssl=DIR的选项来静态编译,所以他编出来的Nginx用的系统低版本的openssl,导致谷歌访问时并不会开启http2! 找了段专业解释如下: Chrome 在最近的更新中放弃了对 NPN 的支持,如果想要继续在 Chrome 上支持 HTTP/2 ,则需要安装最新 1.0.2 版的 OpenSSL,并且用 1.0.2 的 OpenSSL 重新编译 Nginx。 参考资料: 新版Chrome下滚回HTTP/1.1 Supporting HTTP/2 for Google Chrome Users 所以,解决方法就非常简单了,从openssl官网下载最新源码包,然后新增如下参数重新编译即可: --with-openssl=源码包解压目录 比如: 当然,我们也可以先更新yum源,比如改用EPEL源,使用 yum update openssl 升级后重新编译。这里我个人建议使用源码静态编译。 重新编译安装后,再利用谷歌浏览器访问如下网址: 测试他的网站已经成功开启http2了: 事后突然想起,其实自己之前折腾网站的时候其实遇到过同样的问题,就因为没有记录导致重复造轮子。所以这次记录分享一下,权当是备忘吧!
阅读全文
WEB应用

修改Apache的超时设置,解决长连接请求超时问题

某日,组内后台开发找到我,问我们的WEB服务器超时设置是多少。他反馈的问题是,有一个VLAN切换任务cgi接口经常返回504网关超时错误,要我分析解决下。 我问了一下,得知这个请求遇到网络设备对象较多的时候,需要小半个小时才能完成,也就是要用到长连接才行。 老规矩,从开发那拿到接口地址,得到接入层服务器IP,是一台Haproxy代理,看了一下Haproxy的超时设置: 各种1小时超时,所以排除Haproxy的影响,继续往下看。 Haproxy 代理的是2台Apache,也就是部署了cgi接口的服务器。第一时间查看了 httpd.conf 和 httpd-vhost.conf 中的配置,居然没找到超时设置。 于是,搜索了下相关教程,发现原来藏在了 httpd-default.conf 当中: 看了下,这些是Apache的默认配置,Apache也没有include到httpd.conf当中。因此,编辑 httpd.conf,找到如下参数: 去掉注释,保存文件。然后再编辑 /usr/local/apache2/conf/extra/httpd-default.conf 文件,将Timeout的值修改为符合生产环境要求的1800秒,最后执行Apache平滑重启命令即可: Ps:我之前一直以为只有Nginx有一个平滑reload命令,后面才知道Apache、Haproxy都支持平滑重启名称,这个非常棒! 重载之后,就不会出现504网关超时设置了。
阅读全文
WEB应用

WordPress启用memcached动态缓存以及报错解决

张戈博客目前用的是Nginx的fastcgi缓存方案,属于纯净态缓存模式,所以前台登录态什么的基本都没了。如果要兼顾前台登录态,又想速度快,有没有解决方案? 之前在分享张戈博客优化方案时提到,要实现网站轻度缓存,方案还是有的,比如 DB Cache Reloaded、Redis、memcached等。 最近恰好遇到一个数据缓存需求,因此尝试了下memcached方案,下面简单分享下我的环境部署以及报错解决过程。 一、d还是不d php有memcached和memcache两个类似组件,百度搜出来的文章,大部分是教你如何安装memcache(d),却步解释二者的区别。 比如这位博客仁兄的经验分享: 为什么他选第二个不行?其实php的这2个组件还是有点区别的: 简单来说: memcache 是 pecl 扩展库版本,原生支持php,出现更早,是老前辈; memcached 是 libmemcached 版本,出现较后,是新一代,因此也更加完善,推荐使用。 Ps:如果想更深入了解,可以搜索下 memcache vs memcached 其实,我们这种小网站的话,二选一即可,这点QPS还不至于纠结。不过一旦选择了,安装的时候就要注意区分,一对一配套安装,别搞的牛头不对马嘴,出现上面那位仁兄的困惑(后文有相关说明)。 这里,我果断选择了带d的,继续分享。 二、部署memcached 1、安装memcached Ps:这里的memcached是指Mencached的服务端,用来处理缓存数据,名字也是容易混淆。 下面2种安装方式任选其一: ①、在线安装 ②、编译安装 相比在线安装,很多时候编译安装更加灵活,非常类似Windows平台的自定义安装或绿色安装,推荐熟悉 Linux 系统的朋友使用: 至此memcached的服务端就安装好了。 2、集成php-memcached拓展 ①、先安装libmemcached 提前分享一个问题,如果直接按照网上的教程安装php-memcached可能会报如下错误: configure: error: no, sasl.h is not available. Run configure with --disable-memcached-sasl to disable this check 大部分教程会使用 --disable-memcached-sasl 参数来禁用这个功能,作为一个强迫症,我还是从国外的论坛扒到了解决方法,很简单,在编译libmemcached之前,先安装cyrus-sasl-devel即可解决 接着开始编译安装libmemcached: ②、安装php-memcached组件 下载和解压这步,我们要区分下是php7还是之前的版本: I、如果当前环境是php7 : II、如果是旧的的php版本: 接下来开始编译: 编辑php.ini文件,在最后插入如下参数 Ps:如果不知道php.ini在哪个位置 ? 执行命令:php --ini 即可找到。 保存后,执行如下命令看看是否加载成功: 如果输出memcached则表示成功。 最后,如果是Nginx就 service php-fpm reload ,如果是Apache就重启Apache完成安装。 ③、测试缓存 将上述代码保存为 test.php,然后执行 php -f test.php,如果能输出100表示安装成功。 三、WordPress缓存 做完上述所有步骤,系统环境就已经支持memcached缓存了。下面分享如何应用到WordPress 1、安装插件 访问github项目页面下载插件包: https://github.com/tollmanz/wordpress-pecl-memcached-object-cache 下载并解压得到的 object-cache.php,上传到 wp-content 目录即可开启memcached缓存。 值得说明的是,这里还有一个大坑等着你来踩: WordPress官网上的object-cache.php虽然也号称Memcached 插件,然而它只支持Memcache,不支持新版的,所以不能使用。如果错误地将object-cache.php和Memcached混用的话,则会出现WordPress打不开,前台后台页面一片空白的现象。 这也就是经常有站长反馈WordPress启用memcached功能后,页面空白的错误原因了。不巧,张戈在测试的时候也踩坑了,所以特别提出来,希望大家了解错误的原因,规避掉!   2、查看效果 做完第2步之后,你可以去网站前台刷新几次,产生缓存,然后从官方下载探针: http://pecl.php.net/get/memcache-3.0.8.tgz 解压后,里面有一个memcache.php文件,编辑并找到如下代码: 修改如下:...
阅读全文