Tag Archives: 规范化

Reproducible builds 果然是很重要的

去年10月17日公司出了个事故,“幸好有我“,力挽狂澜。我觉得还是把具体内容脱敏,记录一下吧,免得将来忘了。 早晨test环境某个自研产品组件build成功,但是运行时错误日志里一堆“Broker hostname updated”等等,仿佛孔乙己说的话,让人听不懂。我刚开始没把这个当回事,请Kafka管理员去检查,几个小时都没查出原因来。 到了午后,各自研组件纷纷开始更新Live环境的版本,发布的都是前几天在Test环境已经测试定稿的版本,居然也出现了类似的问题。更狠的是,回滚居然也无效! 最终查实,有不少自研产品的build脚本里,使用wget下载master版本的librdkafka然后编译使用。而librdkafka恰在前一天(10月16日)被提交了很多修改。当时紧急解决的方法是使用librdkafka的上一个被明确标记了tag的v1.2.1版本代替master版本。 事后复盘处理过程,觉得当时的处理过程也有问题:所谓回滚其实并非直接使用旧版本编译出来的docker image,而是重新build了旧版本,而且编译时指定的是branch名字,而不是精确的commit id,这样的问题是无论外部代码(master版本的librdkafka)还是自研代码(注意branch有可能move forward哦),都不一定是原来的版本,这个行为其实并不能称作回滚,而是带有主观回滚意向的一次重新构建。 在这种情况下,讨论自研代码和外部库的质量,都是缺乏讨论基础的。这种讨论应该基于确定的版本。 说实话,我以前对于传说中的“Google把自研代码、外部库和工具链”全都纳入版本化管理,是有点嗤之以鼻的。当时我觉得这种做法,在处理多个自研软件的外部依赖相互冲突时,会带来额外的行政成本,在国内企业的KPI风格下,会导致相互推诿。经过这次力挽狂澜之后,觉得相互推诿其实是KPI至上主义导致的,而不是把所有代码都管起来导致的;不过是否真的要管这么大范围,尚有待商榷。

Posted in 默认分类 | Tagged , | Leave a comment

经典错误——使用/etc/security/limits.conf配置文件 和 ulimit -n命令

很多以讹传讹的半桶水文章,都教人修改/etc/security/limits.conf配置文件来放宽“打开的文件数量”限制,如果可以再多一滴水的话,还会加一句“重启后生效”。 其实,使用这个配置文件,和使用ulimit -n命令一样,属于很经典的错误。 设置或放宽“打开的文件数量“限制,其本质是调用了setrlimit()函数,设置了RLIMIT_NOFILE资源。在有特权的程序中调用这个函数,可以提高上限(放宽限制),而普通权限的程序只能自己勒死自己和新生的子进程。 而/etc/security/limits.conf这个配置文件是怎么生效的呢?其实用dpkg -S或rpm -qf查一下就很容易知道,这个文件是pam_limits.so的配置文件,而pam_limits.so是在/etc/pam.d/中被login和sshd等多个配置文件声明将要被调用的。 系统开机的时候,1号进程init“自然而然”是root身份运行,其下属的getty/login和sshd进程,也都是root身份。这些程序都可以随意调用setrlimit。当身份认证(部分工作由PAM来做,所以可以读shadow文件)完成之后,login和sshd的子进程会为用户准备好session(网络登录调用pam_mkhomdir建设HOME目录、pam_limits模块设置rlimit、pam_env模块读取/etc/environment设置环境变量,甚至显示motd这种功能也是PAM模块实现的)并将自己降级到登录的用户身份,再启动一个shell给用户使用。 /etc/security/limits.conf 只对“调用过pam_limits.so“的登录过程有效。但并不是所有场景都经过这个过程的。而ulimit命令呢,它本身只是shell是一个内部命令而已,只对“该shell进程”及随后新产生的子进程有效。 但是需要放宽rlimit的程序,往往不是在shell中由用户手工运行的程序,而是提供大规模网络服务的后台进程。它们所需的rlimit,要在init脚本、service unit文件中设置;支持从root身份启动的服务,一般都有自行设置rlimit的能力。 如果不理解上面的内容,就容易引发一些莫名其妙的故障。比如之前我在FreeWheel工作的时候,前辈为后台服务写的的init脚本里没有调用ulimit -n命令,而在root用户的~/.bash_profile里有这个命令。造成的后果,就是开机自动启动该服务的时候,启动的是一个打开文件数量受限,以至于无法保持很多socket的网络服务,而当运维人员登录进去手工重启服务之后,又莫名其妙变好了,以至于没法检查这个故障到底是怎么发生的。

Posted in 默认分类 | Tagged , | Leave a comment

配置管理 vs provisioning 及配置管理工具的几点随想

关于“怎么构建一个确定的运行环境”这件事,有多个流派,其中一个是配置管理,另一个是provision流。 配置管理流派,适合于物理服务器、虚拟机等等,有机会长期存活的环境。因为它们有机会长期存活,在其生命周期里需要使用技术手段去维持一个有序可控的状态,排除软件运行时累计的旧日志和临时数据、手工操作带来的计划外变更等等影响。 而provision流派,直接从模版构建一个(容器或虚拟机)实例起来运行,用完就扔,基本上没有重新调整的价值。这种东西往往依赖于服务注册与发现机制,因为在它真正起来运行之前,网络通信方面的参数无法被外界预知,外界不知道如何跟它通信;对于日志和数据,也提倡使用显式远程的方式去访问。   再说说配置管理工具的几点随想: 我最近一年在给下属的一个公司做一些产品运维工作,其中遇到把设备投放到客户的网络环境去运行这种情况。考虑到网络通信的问题,我只好选择了“反向连接”的saltstack软件。在通信的角度来考虑,配置管理工具可以分为:master主动连接minion(ansible等)、minion主动连接master(puppet、saltstack等) 今天听师兄说他的一个同事因为认知问题,把一批机器glibc给删掉了。尝试恢复的时候,他发现ansible无法正常运行(我猜想sshd启动python的时候因为缺glibc而失败了),只好改用saltstack。因为saltstack的salt-minion是长期运行的,一旦启动之后,外部依赖较少,才能在glibc被删除这么极端的条件下苟活。在“有没有agent”的角度考虑,配置管理工具可以分为:有agent(saltstack、puppet、cfengine等)和无agent(ansible等) 另外,其实还有一个分类角度,就是主动和被动。saltstack和ansible是主动式的,运维工程师可有更多的主动权,可以用手工指定minion,或者指定批次规模分批执行等手段,控制变更的节奏;cfengine、puppet等是agent定时刷新式的(虽然听说也可以主动?不过我经验较少还没用过),得按定时器来,这种情况下就得运维工程师多看监控了,一不小心,死都不知道怎么死的。

Posted in 默认分类 | Tagged | Leave a comment

为什么有些系统是动作式的而非描述式的?

接手一个旧系统,上线发布是“拷贝文件过去,替换掉,重启服务”这样的,而不是“把编译好的东西打包,发上去安装,包的scripts部分带有重启动作”。 是否打包、包里包含什么,很有讲究: 查询当前版本号:XXX -v vs rpm -qi XXX 重启服务:killall XXX && sleep 30 && XXX vs /sbin/service XXX restart 删除软件:rm -fr XXX vs rpm -e XXX 安装依赖: ldd XXX |xargs -n1 yum provides |xargs yum -y install vs rpm -i XXX … Continue reading

Posted in 默认分类 | Tagged | Leave a comment

Sentry整理杂记

本讨论均基于Sentry 7.7版本 插件机制 自带插件 src/sentry/plugins/ 每插件一个目录 自带插件loader:src/sentry/conf/server.py 里的 INSTALLED_APPS tuple 外装插件loader:utils/runner.py 里的 install_plugins()函数,对iter_entry_points()遍历并将其加入 INSTALLED_APPS tuple 中 外装插件注册:插件的 setup.py 里执行注册 entry_points 的过程: 例:https://github.com/getsentry/sentry-groveio/blob/master/setup.py 参考资料:https://pythonhosted.org/setuptools/pkg_resources.html #!/usr/bin/env python import pkg_resources for ep in pkg_resources.iter_entry_points(‘sentry.apps’): print str(ep) for ep in pkg_resources.iter_entry_points(‘sentry.plugins’): print str(ep) sentry-jira … Continue reading

Posted in 默认分类 | Tagged , | Leave a comment

Python import语句一处文档和行为不一致的问题

话说,我团运维组曾一度极为昌盛,可惜后来公司里有人搞政治,好好的一个组被拆成了好几个,后来竟分属不同大部门,工作关系也开始形同陌路。考虑到丰富经验,换换方向,今年7月,我转岗到了运维开发组,开始真正把Python作为职业。 无奈,基础差,还得学,8月18日,这么吉利的一天,我第n次在看Python的文档,看着看着,注意到一些标准库的名字是带点的,比如os.path,再比如logging.config等。然后就开始help各个模块,发现os.path的名字居然不叫path而是posixpath!!再看,logging是个package,但os居然是个module!! 于是,问题就来了: Python语言里对 import A.B.C 这种形式是这么规定的: when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module or a package but can’t be a class or function … Continue reading

Posted in 默认分类 | Tagged , , | Leave a comment

墨菲定律之多处保存必然会出现不一致——谈Linux上的时区问题

技术部的工作日报,原本是早晨9点发,脚本换了一台服务器运行之后变成17点了。算算时差也知道是时区问题。 检查了一下, /etc/timezone 内容误为 Etc/UTC,而 /etc/localtime 是从 /usr/share/zoneinfo/Asia/Shanghai 复制过来的,二者不一致。date命令使用 /etc/localtime 而 cron 按 /etc/timezone 文件执行,于是造成了执行时间不对的问题 另外需要注意的是,cron 只在开始运行时读取一次该文件,而每分钟唤醒时不再读取,所以改过文件之后还得重启该服务;又得注意的是,service cron stop 似乎并不会终止cron进程,所以……你懂的 以上就是墨菲定律之:多处保存,必然会出现不一致

Posted in 默认分类 | Tagged , | Leave a comment

MySQL 备份、版本兼容性二三事

最近几天在筹备多做一个 slave 数据库,所以就用 InnoDB Hot Backup 工具把原来的 slave 库备份了一份,拷贝过来,执行了一段 binlog 之后卡住了,然后发现上述工具对 ARCHIVE 存储引擎的表没有考虑,没把数据文件复制过来。于是改用 Percona 出品的 xtrabackup 工具,其 innobackupex 脚本考虑的比较周全。这样总算搞到一份相对完整的备份。 搞到备份数据之后,我又想尝鲜,于是装了 Percona Server (即 MySQL 的一个增强 fork)的 5.5 版本,结果发现无法操作上述 ARCHIVE 存储引擎的表。查了查 MySQL 5.1 的文档,说从 5.0 到 5.1 之间,ARCHIVE存储引擎变了存储格式,不可能兼容,要求 dump/restore 操作。服了…… 考虑到 … Continue reading

Posted in 默认分类 | Tagged , , , , , , | Leave a comment

不能念叨啊,一念叨就出事——兼谈xen的network-bridge脚本问题

昨晚还说呢,如果今天一天没事,这周就算安全过去了,@sgub 和@chifeng 都告诫我说不能念叨这事,今天果然! 下午,同事远程关闭错了机器。重新开机之后,发现 xenbr0 网桥没有了。看了一下,是 /etc/xen/scripts/network-bridge 没成功运行造成的。这个脚本用默认路由所在的网卡做一个网桥,然后把虚拟机接在这个网桥上,以便使虚拟机能直接上网。但我们的服务器却有俩公网IP和俩默认路由,就把那个脚本搞糊涂了。 其实这俩默认路由是路由器上的同一个接口的两个 IP 地址,连 MAC 都一样的。我删除掉其中一个默认路由,再运行network-bridge 脚本,就成功了。

Posted in 默认分类 | Tagged , , , | Leave a comment

有人忘记在 ifcfg 里写 NETMASK 了,结果……

我的好兄弟、大学同学谢某人,在虚拟机里玩 RHEL+Oracle 的时候,遇到一个诡异的事情,就是 RHEL 开机后 IP 地址会自动变化。我原以为是他装 Oracle 的时候某个开机自动执行的命令更改了地址,所以就在开机的各 rc 脚本之间夹带执行一次 ifconfig 命令,发现在开机过程中 IP 地址始终都是没有变化的。持续 ping 该机器,发现在出现登录提示符后才 ping 不通,并且提示符后还出现了 iscsi-initiator 关于断开和 target 的网络连接的错误提示信息。 没办法,看日志吧。/var/log/messages 日志明明白白的写着:NetworkManger 认为长度为零的 IP prefix 是无效的,因此接管了该网卡,并按 Auto eth0 设置了该网卡。看了看 ifcfg 文件,里面果然是没写掩码。此时谢同学不服气的嚷嚷,说另一个虚拟机也是这么写的,就不会自动变 IP。过去看了一下,发现那边没启动 NetworkManager 服务。哈哈…… 不过有个问题,ifconfig 命令对于不带掩码的 IP … Continue reading

Posted in 默认分类 | Tagged , , , , | Leave a comment