Author Archives: admin

placeholder 2016年10月欧洲之行

6月办签证,因为英国当时在闹脱欧,签证审批速度大大降低,耽误了办理申根,连瑞航机票都耽误了。所以决定10月辞职后再去。 临辞职,拿了在职证明去办法国申根,但忘记提前买好英法之间欧洲之星国际列车的票,后来多花了好多钱 走之前没查时区,10天行程调了5次时区,痛不欲生 不喜欢法国的繁复建筑物,但很爱她的博物馆们;塞纳河左岸下午照不到太阳,是酸臭文人吹捧起来的地方。 英国很有沉淀感 国际标准时间曾经是巴黎天文台,但英国人解决精度问题之后,标准时间变成了“比我巴黎时间晚9分9秒的‘那个时间’”

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

django database router是个好东西

今天给sentry加了MySQL读写分离机制,记录一下: DATABASES里,(sentry的脾气比较怪)保留名为default的配置,写master数据库的参数;新增一个名为slave的配置,使用只读用户名密码,或开启服务器端read only 然后增加一个类,带四个函数: class DatabaseRWSplitRouter(object): def db_for_read(self, model, **hints): return ‘slave’ def db_for_write(self, model, **hints): return ‘default’ def allow_relation(self, model1, model2, **hints): return True def allow_migrate(self, db, app_label, model_name=None, **hints): if db == ‘slave’: return None else: return True … Continue reading

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

内训教程释出:from CGI to WSGI

古代时,读过MSDN里的《from C++ to COM》受益匪浅。后来学习Python,自己也写了一篇 from CGI to WSGI 的教程,用于内部培训。 http://julyclyde.org/pyCGIWSGI.pdf

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

给rq添加了RedisCluster支持

最近一直在和前同事Puff潘、RainSun吕合作,做一些给使用redis的软件增加redis cluster或者redis sentinel支持功能的工作。 传统上,做sharding工作有三种做法: 客户端支持,比如redis cluster客户端需要支持KeySlot计算(我报告的bug: https://github.com/Grokzen/redis-py-cluster/issues/153) 代理层支持:twemproxy、codis等 服务器端支持:比如MySQL partition table之类 我比较推崇的是第二种,但redis的cluster和sentinel都属于第一种,客户端需要有明确的能力和知识去处理连接多个服务器的问题,而这方面,各常见客户端库做的并不好。另外还有个问题是用Python语言写的各应用软件,往往直接写死了用redis库,而不是用rediscluster库或者运行期动态决定,导致根本不具备使用cluster的能力。 近期在看rq的时候,发现rq支持custom worker class,于是我就改了改,让它也支持custom connection class,并说服了作者merge进来。 https://github.com/nvie/rq/pull/741 不过其实我觉得还是略别扭。主要是因为生成connection对象的时候套了两层函数,为了补全function signature,并尽量减少其它代码的修改,不得不在两层都使用参数默认值,显得多余。尽管如此,还是很为自己能为基础软件做出贡献而感到高兴的。

Posted in 默认分类 | Leave a comment

kube-proxy –proxy-mode=iptables 与 rp_filter 冲突

2015年12月16日,朱鹏安装了新版kubernetes master版本(比1.1新,为1.2alpha**),然后发现,访问 clusterIP:clusterPort 会发生无法连接的故障。 从集群内Node上访问 分别在Node rz-ep19和container里执行curl访问,发现container里curl可以成功访问,但Node上一般不行(偶尔成功,几率很低)。查看iptables规则,发现新版kube-proxy已经不再将请求REDIRECT到本机kube-proxy端口,而是: 先把PREROUTING、OUTPUT无条件指向KUBE-SERVICES链;如匹配不上KUBE-SERVICES链,则再尝试匹配发给docker0 在KUBE-SERVICES链里匹配clusterIP:clusterPort条件,然后发到KUBE-SVC-***链 在KUBE-SVC-***链中,用-m statistic –mode random –probability这样的条件将流量按等比例分给多个KUBE-SEP-***链 然后再在KUBE-SEP-***链中,将数据包DNAT给endpoint 为了减少干扰,我们缩减了kube-system/elasticsearch-logging 10.16.59.73:9200服务的规模,到只有一个endpoint 172.16.86.48:9200运行在rz-ep10上;rz-ep19 10.16.49.16作为运行curl的客户端 在rz-ep19的flannel接口上抓包,抓到了 10.16.49.16->172.17.86.48的TCP SYN,但没有收到回应。 在rz-ep10(endpoint Pod所在的Node)的flannel接口上抓包,抓到了和上述相同的包,也没有收到回应。 在rz-ep10的docker0接口上抓包,没有抓到 由此判断,rz-ep10的内核在转发时主动丢弃掉了 10.16.49.16->172.17.86.48的SYN,以至于无法建立TCP连接。查看/proc/sys/net/ipv4/conf/{all,flannel.7890}/rp_filter,发现flannel.7890/rp_filter内容为1,即在此网卡上执行“根据回溯路由检查数据包是否为伪造”的检查。因为源IP 10.16.49.16在rz-ep10看来理应出现自eth0而非flannel.7890接口,所以被判定为假造包,丢弃。 将此参数改为0,再去docker0上抓包,可以收到172.17.86.48发回10.16.49.16 SYNACK包;但rz-ep19上curl仍显示无法建立连接。 在rz-ep10的角度考虑,这个172.17.86.48->10.16.49.16的包应该从eth0发出,也就是在rz-ep19的eth0上收到。而在rz-ep19的角度考虑,源IP 172.16.86.48不应来自eth0,也会被rp_filter参数影响,丢弃掉,所以无法建立连接。把rz-ep19的eth0/rp_filter参数改为0,终于可以正常访问了。     从集群外访问 从办公区我的笔记本电脑 172.30.26.169 访问 10.16.59.67:80 服务,该虚IP被手工绑在rz-ep01上,ping可以通,但访问不通。 … Continue reading

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

Kubernetes内的网络通信问题

首先复习一下Kubernetes内的对象类型 Node:运行kubelet(古代叫minion)的计算机 Pod:最小调度单位,包含一个pause容器、至少一个运行应用的容器 RC:复本控制器,用于保持同类Pod的并行运行的数量 Svc:暴露服务的可访问通信接口   对象之间的通信关系 客户端 服务器 访问方式 master kubelet Node的10250/TCP端口。Node报到后,Master得知Node的IP地址 kubelet & kube_proxy apiserver master:8080/TCP HTTP 配置文件写明master地址 kubectl命令行 apiserver localhost:8080/TCP或命令行参数指定 other ALL apiserver ClusterIP_of_kubernetes:443/TCP HTTPS 上述IP和端口号通过环境变量通知到容器 需要出示身份信息 kubernetes是一个ClusterIP模式的Service。参见下面详述 pod pod 跨Node的多个pod相互通信,需要通过overlay network,下面详述 ALL service 三种模式,下面详述   overlay … Continue reading

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

Docker in docker的一些故障检查过程

术语约定: Host:外层运行操作系统的机器 外层daemon:Host上的docker daemon 外层容器:外层daemon下辖的container,镜像启动时加–privileged参数。这个镜像的准备步骤是从docker下载当前1.9.1版安装(并固化到镜像里)CMD是一个脚本,先启动带debug选项的docker daemon 并放后台运行,然后pull并运行centos:7 一次,最后开启一个不停ping的命令,保持容器持续运行。通过docker exec 进入另行执行docker run命令测试内层是否可以正常启动 内层daemon:外层容器里的docker daemon 内层容器:内层daemon下辖的container   宋传义最近几周在尝试docker in docker,报告过几个问题,我在这里简要记录一下。因为在此docker in docker研究过程中我只是顾问的身份,并非主研人员,所以记述内容难免有缺乏背景介绍、阶段靠后等问题。宋传义报告的大量现象都是“最后一句错误信息”,但我的工作方式是从“第一条错误信息开始看”。 启动内层docker daemon时报告缺cgroup mount 宋传义报告在1.9上可以成功的在外层容器里运行内层的docker daemon,但1.7的报告缺cgroup mount。检查发现,Docker 1.7 并不会给内层容器 mount /sys/fs/cgroup/* 目录。只需要手工补mount即可混过去,满足启动docker daemon的需求。 在Docker 1.8.0的changelog里 Runtime 小节记述了这个变动: Add cgroup bind mount … Continue reading

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

Sentry新版SSO Provider讲解

从GH-1372 issue完成时开始,Sentry 7.x转向使用自家定义的SSO Provider,逐渐抛弃django-social-auth结构。因为缺乏文档,我在此事上消耗了大量的时间。现在写这篇Wiki用于记录: 基类:sentry/auth/provider.py 中的 Provider 虚基类 样例:sentry/auth/providers/ 目录下的dummy.py和oauth2.py 两个,以及sentry-sso-google 基于Sentry自带的OAuth2Provider   基本执行流程: 通过django机制加载app,在初始化时调用sentry.auth.manager的register方法,注册自己的名字和class 管理员在 Organization 的Auth页开启SSO时,会生成上述类的一个实例。Sentry的helper.py负责此流程,先调用get_auth_pipeline()函数,取得一个成员为多个 AuthView的超类 的list,然后对着这个list依次执行成员的 dispatch()函数 每个步骤按照pipeline的顺序执行一个AuthView.dispatch(self,request,helper)函数,其中request可以读到当前的django request内容。因为URL都为/auth/sso/ 所以需要根据querystring来判断执行到哪一步了,并收集本步的信息,调用 helper.bind_state() 保存起来,然后return help.next_step()跳到下一步执行 最后build_identify()会被执行,需要返回一个至少包含id、email、name的dict,此dict被Sentry用来构造用户信息。

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

sentry-公司内IM插件

这插件被大家催了很久了,到1月底终于决定动手做。 准备知识 公众号Pub服务API(内网wiki,链接已删除) 签名请求规范(内网wiki,链接已删除) New Forms of Authentication 插件组成 setup.py 安装脚本。插件注册发现机制请参见 sentry_IM/__init__.py 确保这个目录是python package的文件。顺便查询一下VERSION供引用 sentry_IM/requests_APISign.py 上述New Forms of Authentication文档里提到的requests auth class,提供公司的Authencation验证header sentry_IM/send_IM.py 发消息用的Class sentry_IM/plugin.py 插件本身 程序讲解 插件本身继承自sentry.plugins.bases.notify.NotificationPlugin类,需要实现其notify(self, notification)方法。因基类里notify()调用了notify_users(),所以pylint会有提示。 参数notification为一个对象,可以从中取得event,然后从event取得所属的group以及group所属的project。根据project可以取得要通知的人员列表。(这里抄袭了MailPlugin的发送列表)因为这个函数得到的人员列表是Sentry里的User id,所以还需要再根据id查询到User,然后从其Email字段中取得localpart 最后,根据上述project.name、event.message、group.get_absolute_url() 组装其通知消息文本(URL在IM客户端渲染时才变成超链接,我这里只发URL本身),生成send_IM.py 的实例,对着上述人员列表发送消息文本。 IM插件所需的四个参数,在总的配置文件中列出,由插件生成send_IM实例时传递,然后由其传递给requests_APISign的实例,完成对HTTP请求的签名 配置是否开启 本来是想像MailPlugin那样直接在Account/Notification页做个列表供勾选。但阅读代码发现,这个功能并不是MailPlugin自己的功能,而是sentry做了特殊处理,先获得用户订阅的projects_list,然后循环生成ProjectEmailOptionsForm的list,随后再执行从各插件获取的ext_forms[]配置表单。ext_forms里每一个插件配置表单的初始化参数只有plugin、user和prefix,要想表达“所有可订阅的projects”这个概念会相当啰嗦。因此,最终确定为:表单里只勾选per-User 级别是否开启;而用户是否属于具体某个event/project的发送目标,则直接共用MailPlugin那边的选择,然后再用上述per-User级别开关做一遍过滤。这里两个插件之间略有粘连,主要是由于User-Project之间只有单向对应关系,逆向查询太罗嗦导致的。 最终发送效果 Github地址 https://github.com/julyclyde/sentry-IM

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

Sentry 新版插件基类讲解

根据 sentry/plugins/bases/__init__.py 的说明,新版插件分类四类,其中常见的: NotificationPlugin 比如sentry_mail、sentry_webhook插件 NotificationPlugin的基类定义参见 sentry/plugins/bases/notify.py

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