WEB应用

Haproxy进阶管理:命令行控制后端节点上下线

很多业务系统都用到了Haproxy这个高性能反向代理负载均衡器。在日常运维当中,Haproxy后端节点的上(接入)、下(剔除)线操作绝对是家常便饭,而且人工重启的时候经常有胆颤心惊的感觉。 下面分享一种命令行操作Haproxy后端节点平滑上下线的技巧。 一、新增配置 Haproxy自带了一个非常实用的管理页面,我们可以在harpxoy.cfg新增如下配置,开启Haproxy监控管理页面功能: 配置后,重启Haproxy,访问 http://ipaddress:8080/admin,使用admin/admin登陆之后就能看到管理页面了: 二、管理功能 因为我们还配置了管理功能,所以在各个backend都能看到如下管理功能: 我们在左侧勾选好对应的后端节点,选择需要转换的状态点击Apply就能完成后端节点的状态切换。 三、平滑发布 对于平滑发布来说,这里用得比较多的2个选项是READY(就绪状态)和MAINT(维护状态)。 READY 表示被勾选的节点已经完成维护,Apply进入就绪状态后,Haproxy会自动发起健康检查,如果检查通过,这些节点将进入映射状态,接受映射请求了。 MAINT 表示被勾选的节点需要进行维护,Apply进入维护状态后,Haproxy将会停止往这些节点转发请求,并等待已有的请求结束连接。 通过这个功能,我们就能对业务进行从容发布了,比如我们有一个业务有2个节点,我们可以先将其中一个节点改为MAINT状态,刷新Haproxy管理页面,当看到Session里面的Cur(当前连接)为0个时,我们就可以从容的对这个节点进行发布、重启等维护操作,完成维护后我们在将这个节点改为READY状态即可。接着,我们同样操作剩下节点即可(节点剔除后带来的性能下降问题,这里就不展开了讨论了)。 四、命令行操作 很明显,这个功能非常实用,但是并不方便,因为需要手工操作,没法嵌入到自动化发布流程当中。不过通过分析POST请求,可以得出curl命令行操作方法: s 表示后端标签名 action 表示状态 b 表示backend标签名 通过测试,得出curl发起请求格式如下: 比如,如果Haproxy有一个后端如下配置: 那么,业务系统发布之前,我们将192.168.1.1这个节点改为维护状态,则如下发起请求即可: Ps:要注意的是,这个POST参数必须URL转码,比如存在冒号【:】,需要转换为 %3A才行。 业务系统发布之后,我们再发起node1上线请求: 后面我们只需要重复操作node2节点的上下线即可完成无损发布了。这一整套动作就可以整合到自动化发布流程当中,不再需要人工介入。 五、小结 本文介绍了Haproxy开启管理功能的配置方法以及命令行操作后端上下线的技巧,为程序平滑部署、系统自动化运维提供了一种更加简单的解决方案。 拓展:在复杂的业务场景中,可能用到了etcd+confd + haproxy的统一配置管理方案,原理是通过更改Haproxy配置,然后热重启Haproxy(-st 指令)来上下线节点,是非常不错的方案!不过,根据我个人经验,在高频业务场景中,剔除后端节点再热重启Haproxy,可能出现业务请求异常问题。
阅读全文
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管理方案,这个有待继续研究实现,敬请期待!
阅读全文
操作系统

解决Linux修改密码报PAM authentication failed错误

最近接到一个运维开发任务,需要开发一个帐号管理系统,对手头三千多台Linux服务器的root帐号进行批量系统的管理,实现定期修改root为随机密码并加密存储,并向运维管理WEB前台提供密码查询解密接口等功能。 刚开始,我基于php+ssh2_exec开发了一套雏形。基本功能都实现了,结果老大说这里的运维就我稍微会点php,后面可不好维护。本来也被我说服了,因为写都写好了,难道要重构? 后面线上测试发现,公司有部分系系统接入了ldap鉴权,php的ssh2_exec就无法工作了,返回登陆失败的错误。 不得已,最后苦逼的用python将这个系统重构了一遍,并实现了多线程模式,因为不太会python的cgi框架,就用php搭的api接口,到此为止,基本全部搞定了。 在线上测试了几天后,发现总是有一台服务器要卡半天,登陆校验日志倒是成功的,但总是卡在修改密码那一步。 于是,print一下过程,发现chpasswd改密码这一步报错了!导致expect卡住了。 看了下错误信息是: chpasswd: PAM authentication failed 实际登陆这台机器,执行chpasswd,发现也是报这个错误。 试着执行passwd,也报错了: passwd: pam_start() failed, error 26 搜了半天,也看了半天的洋文案例,都没找到一个贴切的解决办法。最终,我看到有一篇类似的案例,他是通过检查 /var/log/secure 日志文件找到的错误。 于是,我也试着碰碰运气,发现还真有记录! 在 /var/log/secure 中,发现我在执行chpasswd命令是会提示找不到/etc/pam.conf文件。于是到其他系统上去看有没有这个文件,发现也没有的。 最终,我无奈之下,对比了2个系统的/etc目录,让我发现了猫腻!不知道哪个无聊的人把这个系统的/etc/pam.d给重命名为pam.d_bak了!!我去你XXX,浪费我半天时间。 直接 mv pam.d_bak pam.d,然后就能够执行 echo 'root:newpassword'|chpasswd 来修改密码了。 这种奇葩的原因并不多见,所以出了问题不一定能在搜索引擎得到答案。 不过,我写这篇文章的时候,特意把pam.d再一次重命名,chpasswd还是报一样的错,但是passwd报错却变成了: passwd: Permission denied 罗里吧嗦说了半天,主要分享一下这个奇葩的案例和解决过程。当搜索引擎都找不到的时候,那么恭喜你成为了第一个吃螃蟹的人,有了造福互联网的机会,赶紧解决问题再分享吧。。。 目前我开发的帐号管理系统运行良好,后续有时间再整理分享一下,也许有人需要,敬请期待!
阅读全文
操作系统

Linux系统编译安装Redis以及主从复制配置小记

Redis的安装配置很简单,而且很早之前就装过Redis,可这几天再次安装时居然又遗忘了一些细节,看来好记性不如烂笔头,还是在博客记录一下比较好,至少不用总是抱度娘大腿了。 今天编译安装了几次,发现居然没在prefix指定目录生成文件??看了半天结果发现PREFIX我用了小写字母。。。 看来还是得记录一次正确的操作步骤,免得再次出现这种窘迫。 一、选择版本 前往官方网站:http://www.redis.io/download 选择一个适合的稳定版本,比如最新的redis-3.0稳定版(stable),获得下载地址: http://download.redis.io/releases/redis-3.0.0.tar.gz 二、编译安装 安装完成后,redis目录结构如下: 三、注册服务 ①、编写服务控制脚本 vi /etc/init.d/redis ②、注册服务与启动 四、主从配置 ①、配置 在从机上按照上面的步骤安装redis,然后在从机的redis.conf里面新增如下配置项目: 保存后启动redis即可完成简单的主从配置。  ②、测试 测试很简单,先在主机上通过客户端 redis-cli 执行新增键值命令: 然后,登录从机上同样执行 redis-cli 执行查询命令: 很明显主机上新增的键值已经自动同步到了从机,主从同步成功! 本文只是记录一下基本的编译安装和主从配置,当然,redis还有其可以继续进行自定义设置或优化的项目,后续有机会再继续整理补充一下。
阅读全文
脚本编程

zabbix agentd客户端插件Shell一键自动安装脚本

这次生产环境上线了多台Linux服务器,需要全部纳入Zabbix监控范畴,一台一台的去装Zabbix Agentd插件那就太苦逼了,所幸Zabbix客户端插件是支持绿色安装的,就写了个简单的一键安装脚本,然后配合 Secure CRT 的多窗口交互命令一次性就可以搞定了。 正常启动Zabbix客户端服务其实只需要2个文件: zabbix_agentd 和 zabbix_agentd.conf,需要特别说明的是:zabbix_agentd 最好是和 Zabbix_Server 一同编译所得,保证版本和配置文件的路径是一致的,否则可能无法使用Linux系统的 service 服务启动模式。 一、准备工作 Zabbix 主机肯定搭建了WEB服务,所以正好可以将所需放置到WEB目录,方便下载。 客户端插件 zabbix_agentd 位于 Zabbix 安装目录下的 sbin 目录,比如:/usr/local/zabbix/sbin/zabbix_agentd 服务控制脚本 zabbix_agentd 位于 zabbix 源码编译目录下的 misc/init.d/fedora/core/zabbix_agentd 我们要做的就是将这些文件拷贝到 WEB目录即可,比如 /var/www/html/zabbix_agent/ ,根据系统版本的不同,我们可以准备64和32位的 zabbix_agentd,方便后续不同系统下的安装。 拷贝后,手工验证下文件是否可以下载: 客户端插件:http://192.168.1.40/zabbix_agent/64/zabbix_agentd 服务控制脚本:http://192.168.1.40/zabbix_agent/init.d/zabbix_agentd 二、编写脚本 ①、将以下代码保存为 zabbix_agentd.sh ,上传到第一步中的 zabbix_agent 目录。 ②、Service 服务控制脚本 为了方便没找到 zabbix agent 服务控制脚本的朋友,额外提供服务控制代码。将代码保存为zabbix_agentd,上传到第一步的 zabbixz_agent/init.d/ 目录备用。 三、使用方法 登录到客户端系统,运行如下命令即可一键安装: ①、使用默认 zabbix_server 的IP地址: ②、后面添加IP参数可指定到其他 zabbix_server 或 zabbix_proxy: Secure CRT多会话交互执行: 其他说明:此脚本中的 zabbix_agentd 编译路径(prefix)为 /usr/local/zabbix,如果编译的时候不是这个路径,则需要根据实际情况修改脚本里面相关路径,否则注册的zabbix_agentd服务将无法启动,就只能通过命令行启动了!
阅读全文
操作系统

linux/scp命令报“bash: scp: command not found lost connection”错误的解决办法

这两天接到的任务是给JAVA开发项目组部署【JAVA+MySQL主从+Redis主从】运行环境。部署过程中大问题倒没有,小问题却不少,因此也涨了不少经验值。后续有时间我会一一整理记录下来,沉淀而不忘分享。 今天,装完一台redis,并配置好redis.conf后,想偷懒直接用scp传到另一台redis,省去全部重新编辑的麻烦。结果一执行就出现下面这个错误: 所有机器我都是最小化安装,所以很多组件没装也是情理之中,所以用yum装一下scp: 装完后,继续执行之前的命令,结果出现如下错误: 我擦,这就诡异了!明明装了为毛提示不存在呢? 而且还提示输入密码了,用whereis也能找到scp,没办法从man中找到一个DEBUG参数 -v,于是如下增加 -v 参数执行试试: 原来是因为目标主机也没装scp,倒是我大意了!登陆后再次执行如下命令安装scp: 回到之前的服务器上,执行最初的命令,果然毫无意外成功了: 网站搜索这个故障,大部分经验都是告知要安装scp,然后给出一个 yum 在线安装 scp 的命令。实际上,明明已经提示要输入密码了,说明 scp 是正常安装的!还继续报找不到命令,我们就只能从 scp 的执行过程来分析了,因此就借助到了scp的debug参数(-v),很清楚的看到了整个执行过程,从而得知真正的原因是对方主机没有安装scp,而且还可以清楚的看到 scp 的工作流程。 中午时间有限,就写这么多了,希望遇到这个问题的人,看到此文能少走点弯路。
阅读全文