配置管理 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

在嵌入式开发板上使用蓝牙耳机

简单记录一下:

  • 安装 bluez pulseaudio-module-bluetooth 软件包
  • pulseaudio是用户级后台服务,视情况可能需要手工-D启动之
  • bluetoothctl命令进入交互式界面,先scan on 等看到蓝牙耳机之后,pair和connect到蓝牙耳机的MAC地址,看到连接成功之后scan off并退出bluetoothctl
  • pactl list sinks查看设备,看看它支持哪些profile,有可能需要通过pactl set-card-profile将其切换到a2dp
  • aplay -Dpulse 指定pulse虚拟设备播放文件

还没搞定录音。看起来话务耳机在handfree等模式似乎需要特殊步骤激活录音模式?

Posted in 默认分类 | Tagged , | Comments Off on 在嵌入式开发板上使用蓝牙耳机

hostname和dnsdomainname命令

先讲结论:

忽略已经过时的NIS/YP相关内容(/sbin/sysctl kernel.domainname、/bin/domainname、/bin/nisdomainname、/bin/ypdomainname等)

/bin/hostname、/sbin/sysctl kernel.hostname 和 /bin/uname -n 是一码事,都是本机的主机名

/bin/dnsdomainname 命令会把上述主机名按“第一个点”分成两端,输出后一段。这是简单的字符串处理的结果,在内核和DNS层面均无正式意义。

/etc/resolv.conf文件里的search或domain指令,用于从本机访问外部短主机名时,补充域名的后缀部分。

 

hostname命令:

通过gethostname(2)函数读到本机的主机名。在glibc的情况下,gethostname(2)不是syscall而是标准库函数,转而调用uname(2) (我不太确认调用的是glibc uname还是syscall uname)。根据 https://github.com/torvalds/linux/blob/master/Documentation/sysctl/kernel.txt#L285 的说法,/proc/sys/kernel/hostname、sysctl hostname 和hostname命令应该是功能相同的。

hostname -d 或者 dnsdomainname 命令:

根据/etc/host.conf指定的顺序,先尝试/etc/hosts然后尝试DNS,查找自己的主机名。如果能找到,把第一段去掉之后,输出剩下的部分。这个输出不具备内核意义,只是主机名经过字符串处理之后的派生结果

hostname –fqdn命令:

getaddrinfo()函数查询到的ai_canonname

strace观察到的行为是去DNS查一下主机名(如果主机名是短形式,按需补充/etc/resolv.conf里声明的search/domain后缀)对应的A记录,只要能查到,即使返回的IP地址不是本机的也不管,就以这个主机名作为结果。

hostname –all-fqdn命令:

拿自己的IP地址们循环调用getnameinfo()函数(strace/tcpdump观察到的具体行为是去DNS查PTR记录),并全部输出

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

……不胜枚举

描述式的好处是可以由机器自动评估效果,而动作式的效果需要人工评估。

描述式的好处的携带的信息(比如依赖关系)更丰富,而动作式的有可能在一开始就没收集齐足够的信息。

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

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

再把这个注册进去

DATABASE_ROUTERS = (DatabaseRWSplitRouter(), )

注意这个注册,可以写字符串形式的dotted_path也可以是一个对象,我偷懒就直接写了一个对象。

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工作有三种做法:

  1. 客户端支持,比如redis cluster客户端需要支持KeySlot计算(我报告的bug: https://github.com/Grokzen/redis-py-cluster/issues/153)
  2. 代理层支持:twemproxy、codis等
  3. 服务器端支持:比如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端口,而是:

  1. 先把PREROUTING、OUTPUT无条件指向KUBE-SERVICES链;如匹配不上KUBE-SERVICES链,则再尝试匹配发给docker0
  2. 在KUBE-SERVICES链里匹配clusterIP:clusterPort条件,然后发到KUBE-SVC-***链
  3. 在KUBE-SVC-***链中,用-m statistic –mode random –probability这样的条件将流量按等比例分给多个KUBE-SEP-***链
  4. 然后再在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,终于可以正常访问了。

 

plantuml9098040596798137974

 

从集群外访问

从办公区我的笔记本电脑 172.30.26.169 访问 10.16.59.67:80 服务,该虚IP被手工绑在rz-ep01上,ping可以通,但访问不通。

在笔记本电脑上抓包,发现只有从本机发往clusterIP的SYN包,没有返回,所以无法建立TCP连接。

改以Pod IP为过滤条件,发现Pod IP直接发回 SYN_ACK给我的笔记本电脑,但因为笔记本电脑这边没有发起对Pod的SYN,所以直接回复RST给Pod了。

改用iptables模式之后,由于不对称路径的问题,这种访问基本上无法以以前“把clusterIP绑在Node上”的做法实现

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

Kubernetes内的网络通信问题

首先复习一下Kubernetes内的对象类型

  1. Node:运行kubelet(古代叫minion)的计算机
  2. Pod:最小调度单位,包含一个pause容器、至少一个运行应用的容器
  3. RC:复本控制器,用于保持同类Pod的并行运行的数量
  4. 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 network

kubernetes不提供pod之间通信的功能,需要装额外的软件来配合。我选的是出自CoreOS的flannel软件:

flannel是专门为docker跨Host通信而设计的overlay network软件,从ETCd获取配置,提供对docker网络参数进行配置的脚本,使用UDP、VXLAN等多种协议承载流量。

经实验,flannel在办公云(新)上会导致kernel panic

flannel配置

在/etc/sysconfig/flanneld 配置文件中写好etcd的地址

用etcdctl mk /coreos.com/network/config 命令将下列配置写入etcd:

{
"Network": "172.17.0.0/16",
"SubnetLen": 24,
"Backend": {
    "Type": "vxlan",
     "VNI": 7890
 }
 }

Network代表flannel管理的总的网络范围;SubnetLen是其中每个节点的子网掩码长度;Backend规定了各节点之间交换数据的底层承载协议。

再各Node执行 systemctl start flanneld 启动服务。

 

flannel对docker作用的原理

flannel 并非“神奇地”对docker产生作用。

查看/usr/lib/systemd/system/flanneld.service配置文件可知,在flanneld启动成功之后,systemd还会去执行一次/usr/libexec/flannel/mk-docker-opts.sh脚本,生成/run/flannel/docker环境变量文件。

flannel的RPM中包含的 /usr/lib/systemd/system/docker.service.d/flannel.conf  ,作为docker服务的配置片段,引用了上述环境变量文件 /run/flannel/docker ,故 flannel 必须在 docker 之前启动,如果在docker已经运行的情况下启动flannel,则docker也必须重启才能生效。。通过 systemctl status docker 可以看到

# systemctl status docker
docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
  Drop-In: /usr/lib/systemd/system/docker.service.d
           └─flannel.conf
   Active: active (running) since 一 2015-12-14 15:53:06 CST; 19h ago
     Docs: http://docs.docker.com
 Main PID: 149365 (docker)
   CGroup: /system.slice/docker.service
           └─149365 /usr/bin/docker daemon --selinux-enabled -s btrfs --bip=172.17.33.1/24 --mtu=1450 --insecure-registry docker.sankuai.com

flannel作用于docker,最终表现为设置了其–bip 参数,也就是 docker0 设备的IP地址。如重启时失败,可以用ip addr命令删除docker0上的IP然后再重新启动docker服务。

另外,flannel会在各节点上生成一个名为flannel.7890的虚拟接口(其中7890就是上面配置文件里的VNI号码)其掩码为/16,但IP和docker0的IP地址相近。这种配置生成的路由表如下:

即:与172.17.33.0/24 通信,通过docker0;与172.17.0.0/16 通信(不含172.17.33.0/24),通过flannel.7890 发往overlay network

Docker和容器的网络

用ip link add vethX peer name vethY命令添加一对虚拟以太网接口。

veth和普通eth接口的区别在于:veth一次就要配置一对,这一对veth接口有背对背的隐含连接关系,可以通过tcpdump和ping来验证。

然后把其中一个网卡移到容器的namespace里,另一个加入docker0 bridge,即完成将容器连接到docker0 bridge的工作。

查看namespace内情况的方法,请参见https://gist.github.com/vishvananda/5834761

Kubernetes Pod的网络配置

一个Pod最少包含两个容器,其中一个叫pause,它什么都不敢,只“持有”IP地址。通过docker inspect可以看到:

[
{
    "Id": "2b36d6cb2f2d822473aa69cacb99d8c21e0d593a3e89df6c273eec1d706e5be8",
    "NetworkSettings": {
        "Bridge": "",
        "EndpointID": "2c1e17f3fd076816d651e62a4c9f072abcc1676402fb5eebe3a8f84548600db0",
        "Gateway": "172.17.33.1",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "HairpinMode": false,
        "IPAddress": "172.17.33.2",
        "IPPrefixLen": 24,
        "IPv6Gateway": "",
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "MacAddress": "02:42:ac:11:21:02",
        "NetworkID": "6a23154bd393b4c806259ffc15f5b719ca2cd891502a1f9854261ccb17011b07",
        "PortMapping": null,
        "Ports": {},
        "SandboxKey": "/var/run/docker/netns/2b36d6cb2f2d",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null
    },
    "HostConfig": {
        "NetworkMode": "default",
        "IpcMode": "",
    }
]

而真正运行应用的那个容器,网络配置则是这样:

[
{
    "Id": "eba0d3c4816fd67b10bcf078fb93f68743f57fa7a8d32c731a6dc000db5fafe8",
    "NetworkSettings": {
        "Bridge": "",
        "EndpointID": "",
        "Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "HairpinMode": false,
        "IPAddress": "",
        "IPPrefixLen": 0,
        "IPv6Gateway": "",
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "MacAddress": "",
        "NetworkID": "",
        "PortMapping": null,
        "Ports": null,
        "SandboxKey": "",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null
    },
    "HostConfig": {
        "NetworkMode": "container:2b36d6cb2f2d822473aa69cacb99d8c21e0d593a3e89df6c273eec1d706e5be8",
        "IpcMode": "container:2b36d6cb2f2d822473aa69cacb99d8c21e0d593a3e89df6c273eec1d706e5be8",
    }
]

注意对比NetworkMode和IpcMode的值,后者的NetworkMode和IpcMode的值为前者的Id。

Kubernetes这种设计,是为了实现单个Pod里的多个容器共享同一个IP的目的。除了IP以外,Volume也是在Pod粒度由多个容器共用的。

Kube-Proxy服务

kubernetes各节点的kube-proxy服务启动后,会从apiserver拉回数据,然后设置所在机器的iptables规则。

对于如下的svc:

# kubectl describe svc/mysql
Name: mysql
Namespace: default
Labels: name=mysql
Selector: name=newdeploy
Type: ClusterIP
IP: 10.16.59.77
Port: <unnamed> 3306/TCP
Endpoints: 172.17.29.35:3306
Session Affinity: None
No events.

生成的iptables规则如下:

-A PREROUTING -m comment –comment “handle ClusterIPs; NOTE: this must be before the NodePort rules” -j KUBE-PORTALS-CONTAINER
-A PREROUTING -m addrtype –dst-type LOCAL -m comment –comment “handle service NodePorts; NOTE: this must be the last rule in the chain” -j KUBE-NODEPORT-CONTAINER
-A OUTPUT -m comment –comment “handle ClusterIPs; NOTE: this must be before the NodePort rules” -j KUBE-PORTALS-HOST
-A OUTPUT -m addrtype –dst-type LOCAL -m comment –comment “handle service NodePorts; NOTE: this must be the last rule in the chain” -j KUBE-NODEPORT-HOST

-A KUBE-PORTALS-CONTAINER -d 10.16.59.77/32 -p tcp -m comment –comment “default/mysql:” -m tcp –dport 3306 -j REDIRECT –to-ports 53407
-A KUBE-PORTALS-HOST -d 10.16.59.77/32 -p tcp -m comment –comment “default/mysql:” -m tcp –dport 3306 -j DNAT –to-destination 10.16.59.13:53407

(之所以在PREROUTING和OUTPUT设置相同的规则,是为了匹配从外部来的访问和发自本机的访问两种情况)

上述规则把访问 10.16.59.77:3306/TCP的请求,转到了本机的53407端口。用lsof检查可以发现该端口为kube-proxy进程。kube-proxy在各机器上会选择不同的端口以避免冲突。kube-proxy收到请求后,会转发给Service里定义的Endpoints

1.1版本开始,新增–proxy-mode=iptables模式,直接按相同比例把请求DNAT到指定的endpoint去。

Kubernetes Service的三种模式

  1. ClusterIP模式
  2. NodePort模式
  3. LoadBalancer模式

ClusterIP模式

生成一个 只在本cluster内有效的IP:port 组合,也就是仅对内暴露该服务。生成的IP范围由apiserver的–service-cluster-ip-range参数规定。

将生成的IP绑在一台运行着kube-proxy的机器上时,也可以对外提供服务。1.1版本的kube-proxy –proxy-mode=iptables时不能支持将clusterIP绑在Node上对外服务的做法。

NodePort模式

在所有Node上,用相同的端口号暴露服务。如Node的IP对cluster以外可见,则外部也可以访问该服务。

LoadBalancer模式

通知外部LoadBalancer生成 外部IP:port组合 ,并将请求转发进来,发给NodeIP:NodePort们。该行为听起来会把数据转发很多次。

该功能需要外部环境支持。目前GCE/GKE、AWS、OpenStack有插件支持该模式。

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