涯余的博客

TC 的一些有趣功能

hang.yan@hotmail.com (涯余) — Sat, 18 Dec 2021 19:29:35 +0800

最近在看 TC 和 eBPF 相关的一些介绍。TC 本身的概念比较复杂，想要理清并不容易。加上 eBPF 的引入就更复杂了。本文用来记录与此相关的一些发现。

clsact

clsact 即是用来给 TC + eBPF 是使用的一个 qdisc. qdisc 可以简单理解为使用某种算法(FIFO)的 Queue. clsact 的特点是:

不用排队
主要就是为了 attach ebpf 用的
在 ingress/egress 都提供了 hook
lock free

ingress 与 egress 的不同

不太确定直接的原因是啥，目前的 qdisc 只在 egress 方向上有。一般的 rate-limiting 都是在 egress 上实现， ingress上的比较困难。一个原因是难以对源头进行限速。

multiple qdisc

多个 qdisc 在 egress 上是很常见的。加了 clasact 之后就更常见了。那么 clsact 和他们什么关系？

这是我从另一个 Topic 摘过来的图。可以看出来， clsact 是在普通的 qdisc 之前的。

direct-action mode

请参考: Understanding tc “direct action” mode for BPF

简单来说，传统的 TC 使用需要 filter 和 action 两个 module. 但是因为 bpf 本身的功能比较丰富，可以将二者合二为一。这就是 direct-action mode.

EDT Solution

egress 的 rate-limiting 方案可以优化的地方很多，涉及到 lock, cpu scheudler, 不同的 qdisc 算法等等。字节有一篇文章详细列举了几种常见的方案:

Linux 内核 | 网络流量限速方案大 PK

其中最有的意思就是最后的 EDT 方案。这个也是目前 Cilium 在用的 bandwidth 方案。CNI的参考实现里用了 IFB 方案（支持ingress)。

tcng

代表 traffic control next generation. 可以用 code/config 的方式来设置 TC 的相关功能。具体可参考: http://tcng.sourceforge.net/

TC Flower

针对 openvswitch hardware offload 的方案. TC 的可扩展性很强，可以接入不同的 classifier ( 上面的 bpf 也算一例). Openflow 规则也可以映射成 TC 规则。

OpenVSwitch 硬件加速浅谈

Cilium 的 Host Firewall 功能

hang.yan@hotmail.com (涯余) — Fri, 10 Dec 2021 22:29:53 +0800

Cilium CNI 之前一直看文档，功能大概了解，eBPF也大略看过。但一直没有深入从代码角度去研究。它的 bpf 相关代码做的比较全，而且比较老，跟现在网上的 BCC, CO-RW 还不太一样，而且代码量又大，所以读起来并不容易。这次借着 Host Firewall 功能的探究，深入看下。不可能面面俱到，但尽量多涉及一些。这篇文章在后面可能会继续更新，如果有新的发现的话。

一些基本概念

Endpoint: 可以理解为跟 device 挂钩的概念(host, pod 等等)，还有特殊的 health endpoint等等。Endpoint有ID,也有对应的 Identity 和自己的 Policy. Endpoint 是 Node Scope 的概念。
Identity: 跟 label 挂钩。同一个deploy的两个Pod, 有不同的endpoint,但有同样的 identity. K8s Node共用同样的 Identity. Cilium 的 NetworkPolicy 即是针对于 Identity的。这个很好理解，二者主要都是使用 label 来做 filter. 跟 Endpoint 不同， Identity 是 Cluster Scope 的概念(label当然跟node无关)。
KV Store: 用来存储一些映射关系。Labels, Identity, Address, Node等这些元素之间的各种映射关系。Cilium 要实现 NetworkPolicy, 那么就需要这些映射关系。比如 Address -> Identity 等等。

不同的 CNI 在架构方面的差别还是挺大的。比如 KV Store 的需求，有的 CNI 就完全不需要。对 Cilium 来说，当有新的 NetworkPolicy时, agent 来计算 NetworkPolicy,如果发现自己所在的 Node 上有 Endpoint 受影响，那么就需要对此 Endpoint 做一些 Update (Regenerate BPF Programs等等)，其他的 Node 则不需要。不同的 agent 则依赖于 KV Store 来互相交换一些数据。引用一篇架构图所示:

(图片来自于: https://arthurchiao.art)

Cilium 选择使用 Identity 跟它的架构有关。因为使用 agent 来计算 NetworkPolicy. 如果没有 Identity, 那么每次新增加一个 Pod, 所有的 Pod 都需要计算一下 Policy. Identity 是基于 Labels, 相同的 Labels 的 Pod(比如一个 Workload 下的)共享一个 Identity, 那么在很多新增 Pod 的场景下 Policy 没有变更，减少了 agent 的工作量。那么如果从 Identity 获取 Pod 的 address 呢？就要用到上面所说的 KVStore.。所以上面图中的每个 Node 都需要 watch kvstore 中的数据。

Host Firewall 是什么

K8s 的 Network Policy 以及各个 CNI 的 Network Policy, 主要都是针对于 Pod/Service/Remote 的，最开始都不涉及到 Host相关的。我理解一般这块都有现成的其他工具在做。但将其纳入 NetworkPolicy 之内，也是自然发展趋势。这样方便用户。我们看一个 Cilium NetworkPolicy 的例子:

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
 name: "demo-host-policy"
spec:
 description: ""
 nodeSelector:
 matchLabels:
 node-access: ssh
 ingress:
 - fromEntities:
 - cluster
 - toPorts:
 - ports:
 - port: "22"
 protocol: TCP

nodeSelector 即指定了此 Policy 所涉及到的 Node. 其他部分跟一般的 Pod NetworkPolicy 差别并不大。其他的 fromEntities 字段没考证过是否是 Host Policy 所独有，其取值取值范围如下:

cluster: 当前集群的所有 Endpoint (Endpoint的概念需另外细讲)
host: local host 以及当前 host 上所有使用 host network 的 pod
remote-node: cluster 减去 host 的内容
health: cilium 管理的 health endpoint
…

可以看到，其 target 是针对 Endpoint 这个概念的。Endpoint 可以理解包含了 Pod, Host, 以及一些特殊的 Endpoint 的概念。我们可以通过下面的 Output 看下。这是一个 2 Nodes 的 Cilium 集群:

# exec it in worker node's cilium pod:
# cilium endpoint list

ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS
 ENFORCEMENT ENFORCEMENT
456 Disabled Disabled 4 reserved:health 10.0.0.68 ready
972 Disabled Disabled 63615 k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=kube-system 10.0.0.69 ready
 k8s:io.cilium.k8s.policy.cluster=default
 k8s:io.cilium.k8s.policy.serviceaccount=coredns
 k8s:io.kubernetes.pod.namespace=kube-system
 k8s:k8s-app=kube-dns
1307 Disabled Disabled 63615 k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=kube-system 10.0.0.135 ready
 k8s:io.cilium.k8s.policy.cluster=default
 k8s:io.cilium.k8s.policy.serviceaccount=coredns
 k8s:io.kubernetes.pod.namespace=kube-system
 k8s:k8s-app=kube-dns
1723 Disabled Disabled 1380 k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default 10.0.0.220 ready
 k8s:io.cilium.k8s.policy.cluster=default
 k8s:io.cilium.k8s.policy.serviceaccount=default
 k8s:io.kubernetes.pod.namespace=default
 k8s:run=nginx
3015 Disabled Disabled 1 reserved:host ready

这是 Worker Node 上的输出，可以看到如下内容:

包含了Pod,Host,Health. 其中Host,Health都是reserverd的label
每个 Endpoint 都有一个 ID, 并且都有一个 ID. 这个 ID 如其名，在很多地方用来做 Policy 决策。

Master Node 上的数据如下:

# exec it on master node's cilium pod

ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS
 ENFORCEMENT ENFORCEMENT
386 Disabled (Audit) Disabled 1 k8s:node-access=ssh ready
 k8s:node-role.kubernetes.io/control-plane
 k8s:node-role.kubernetes.io/master
 k8s:node.kubernetes.io/exclude-from-external-load-balancers
 reserved:host
565 Disabled Disabled 4 reserved:health 10.0.1.230 ready

Master Node 上一般没有 Workload, 所以只有 health 和 node 两个 Endpoint.

Cilium 主要通过 TC bpf 来实现其 datapath, 我们可以在 host 上的 device 里看到 tc bpf prog list:

# cmd: tc filter show dev eth0 ingress
filter protocol all pref 1 bpf chain 0
filter protocol all pref 1 bpf chain 0 handle 0x1 bpf_netdev_eth0.o:[from-netdev] direct-action not_in_hw id 510 tag ec099af6e42d92d6 jited

from-netdev 就是这个 bpf object 的 entrypoint. 实现 Host Firewall 这个功能，对 Cilium 来说，相当于只是在 Policy 决断的时候加了一些规则，整体的 datapth 还是不变的。下面将对 golang code 以及 bpf code 做一个简要的 walkthrough.

Golang 相关代码

注：参考的代码版本为 v1.11

Golang 部分的代码会比 BPF 相关的代码多很多，此处尽量挑最相关的说。真正在阅读此类代码时，结合着 DEBUG LOG 是比较好的策略。我们的场景是：Add NetworkPolicy, 这部分最开始的处理跟其他的 Operator 方式一样，Controller Watch CRD + Handler.

policyAdd

File: daemon/cmd/policy.go

Cilium 中大量地用到了 EventQueue. Add NetworkPolicy 的事件，最终在 RepositoryChangeQueue 里增加了一个 Event, 并且交由 policyAdd 处理。其工作如下:

处理 CIDR 相关的 Rule. 本例中没有用到
根据 Rules 选出需要 Update 的 Endpoint.代码中一般叫 Regeneration (其中涉及到重新生成 eBPF 程序).

选出相应的 Endpoints 之后，生成另一个 Event 中，并 Push 到 RuleReactionQueue 中。

reactToRuleUpdates

File: daemon/cmd/policy.go

此函数便是 RuleReactionQueue 的最终 Handler. 主要任务就是 Regenerat 相关的 Endpoint. 方法仍然是通过 EventQueue.

EndpointRegenerationEvent.Handle

File: pkg/endpoint/events.go

regenerate endpoint. 涉及到一些本地文件操作(/var/run/cilium),生成新的 BPF Program 并 attch 上去。这部分涵盖的内容很多，最好结合DEBUG日志看下，此处不再细说。

eBPF Loop

hang.yan@hotmail.com (涯余) — Fri, 03 Dec 2021 15:54:37 +0800

eBPF Loop 是个老大难问题，只要实际开发大概率都会遇到。Kernel 版本越高，loop 的支持也越多。最近在 LWN 上又看到一篇关于 bpf loop 的新实现，如果能合并进去，那么就有三种 loop 得方式了:

bounded loop: 跟传统编程模式很像，但loop的count必须是已知的
map iterator: 针对 bpf map 的迭代器，可以用来遍历 map
bpf_loop 函数: 最新的提议，能让 verifier 处理的更快

目前的 verifier 的策略是比较激进的，因为它没法验证所有的场景，所以有可能会对一些实际正确的程序验证不通过。bpf_loop 主要就是从这个角度来考虑问题，相当于对最开始的 bounded loop 做的一个优化。下面将详细介绍。

Bounded Loop

Kernel 5.3 之前, eBPF 不支持 loop. 要想实现类似功能，而且前提是明确 loop 的次数，那么基本上只能靠 unroll 来实现。示例如下:

#pragma clang loop unroll(full)
 for (i = 0; i < 4; i++) {
 /* Do stuff ... */
 }

相当于把 loop 展开。5.3 及之后，就不用这样了。

MAP Iterator

Bounded Loop 只能解决一部分的问题。总会有 unbounded loop 的场景。5.13 引入了 map iterator, 支持对 bpf map做遍历。考虑到 bpf map 在 eBPF 程序中的普遍性，算是一个比较好的解决方案了.

具体可参考: https://lwn.net/Articles/826058/

bpf_loop

bpf_loop 仍然是 bounded loop 范畴。但从 verifier 的角度考虑，大大简化了 verify 的逻辑。相当于把 loop 从普通的函数流程里抽取了出来，单独用一个 bpf 函数来实现:

 long bpf_loop(u32 iterations, long (*loop_fn)(u32 index, void *ctx),
 void *ctx, u64 flags);

这个 patch 还没合并。

Links:

eBPF Timeline

hang.yan@hotmail.com (涯余) — Tue, 21 Sep 2021 10:42:52 +0800

bcc 的文档已经做了很多详细的介绍，关于 kernel 中 eBPF 的变化: https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md. 本文记录的是我在测试过程中发现的几个比较重要的节点。

5.2

这块没找到详细描述，是根据程序实测出来的。在运行包含 map 的 eBPF 程序时，有如下错误:

failed to load objects: field Ingress: program _ingress: map .rodata: map create: read- and write-only maps not supported (requires >= v5.2)

错误信息提示的比较清楚，5.2内核及以上的就可以。不太确定为啥用上了 read/write only的 maps, 猜测是 libbpf 内部的实现机制导致的。因为这个问题，我目前将我测试的 eBPF 程序支撑的最低内核设定为 5.2 了。这点挺可惜的，因为 4.x 的内核对 eBPF 的很多支持已经很完善了， ubuntu 18.04 就是 4.18 的内核。

5.8

kernel 默认带了 BTF 文件。这个 5.8 是不准确的，但确实没查到具体在哪个 kernel 版本默认带的。ubuntu 20.04 没有， 20.10 有了，暂且将其作为开始版本。kernel 对 BTF 的支持从 4.x 就有了，只不过最开始不是默认带的，如果需要，需要自己打开开关并重新编译内核。如果考虑生产环境，这个其实挺麻烦的。如果设定为只支持自带 BTF 文件的版本，那就省事多了。

5.13

5.13 开始支持 map 的遍历了。最开始的 eBPF 是不支持 loop 之类的操作的，防止 crash kernel等等。但是因为程序开发离不了这个，后面又加入了 bounded loop, 但仍然是不够用的。因为很多复杂程序是没法提前知道需要 loop 多少次的。5.13 才开始支持了 map iterator. 不过要注意以下两点:

这里所说的支持只是指 kernel space. 用户态的很早就支持了
因为 libbpf 有了自己单独 sync 出来的代码库。所以也是可以在较老的 kernel 是链接 5.13+ 的 libbpf 来使用此功能。

Links:

Crash because of TUN/TAP do not support ebpf

eBPF, iptables, nftables

hang.yan@hotmail.com (涯余) — Mon, 20 Sep 2021 19:56:17 +0800

把它们三个列在一起，是因为确实有错综复杂的关系。我也想理一理他们在网络方面的前景,比较侧重于 K8s 和 CNI 方面.

iptables: kube-proxy最开始基于 iptables 来实现了 service 的负载均衡，只支持随机算法。因为 iptables 本身的局限性，目前提供了 ipvs 模式.
nftables: 可以说是 iptables 的替代品，更好的API及性能，但是因为 iptables 的遗留使用率太高，暂时难以看到全面替代的可能。
eBPF: 影响越来越多，有可能会在很多场景下替代 iptables

这是简要的说明。下面将根据不同侧面来详细分析一下。

iptables

两个主要问题:

规则数量线性增长
更新规则需要整个替换掉，无法保证原子性。更新规则的效率也很低。

ipset

ipset 是 iptables 的一个扩展，主要解决的问题是 iptables 的线性增长问题。考虑到 iptables 的现实中的普及性以及大家求稳的心态， ipset 在很多场景下仍是一个不错的选择。其基本思想是用 hash 等数据结构来替代原来的线性匹配，这种设计我们在很多地方都可以见到，比如 ovs, eBPF等等。

nftables 作为 iptables 的继任者，很多设计已经了 ipset 里的设计。二者有一定的相似性。

ipvs

没找到太好的深入介绍的资料，但根据网上找的测试数据，比 iptables 好很多.

Service 数量少时不明显，数量很大时差距就出来了。

kube-proxy

eBPF, iptables, nftables,ipvs, ipset这些东西，最终在 k8s 上的落脚点都是 kube-proxy. kube-proxy实现了各种 Service 的功能，底层用什么，是可能会变的，从最开始的 iptables 到现在的 ipvs, 以后真用其他的东西也说不准. 除了 iptables 和 ipvs, 我们也能找到其他方面的尝试:

ipset: ipvs就是基于 ipset的，所以已经算是用上了。iptables + ipset 也有可能，比如这个 issue: https://github.com/kubernetes/kubernetes/issues/54203
nftables: https://github.com/sbezverk/nfproxy 有一个示例的项目了。

这其实也导致了一个问题，就是假设我们扩展 kube-proxy，因为流程上的问题，会非常慢。所以各个 CNI 都在致力于开发自己的 proxy, 以取代 kube-proxy. 这时候各个 CNI 就完全可以基于自己的 dataplane 来实现 kube-proxy的功能，虽然麻烦了些，但好处也是巨大的。cilium不用说了，一开始就是完全基于 eBPF 来做的，calico 也有自己的基于 eBPF 的 Service 实现，等等。

eBPF

eBPF发展下去，很有可能会成为所有 CNI 的 dataplane的选择之一。除了 cilium, 其他 CNI 都有可能需要发展出一个 plugin 架构，用来支持多种 dataplane. 这里面最典型的例子就是 calico, 已经在这样做了。所以参考的价值也比较大。如果想引入 eBPF，切入点其实并不好找。如果想直接开始实现整个 dataplane, 工作量巨大，而且不一定比原有的 dataplane 有太大的性能及功能优势。那只能从小到大，慢慢来。就像 calico 现在做的那样，非常深入研究。

eBPF 和 iptables 还有一层关系就是内核有尝试在保留 iptables API 的同时，用 eBPF 来实现底层逻辑。目前只是在 POC阶段，争议也不小。一个主要的原因还是这样做不一定值得。iptables API 是否还应该被续命？或者说应该把精力放在推广 nftables, 反正需要考虑的因素比较多。不过在 CNI 层面上，eBPF 对 iptables 的优势会越来越明显。

这其实引入了另一个问题。既然大家都有了类似的需求，都是做 CNI 的，都想基于 eBPF 做一个 dataplane, 不管是主要的还是 optional 的，那么这块能否共享呢？ cilium 做的很早很全，但现在没法说单把这块拉出来让大家公用。calico 也在做，但这块也不能直接说被第三方引用。这有点像搜索引擎面临的类似的问题，大家底层的逻辑都是类似的，都需要用爬虫抓来数据，具体怎么用，不同的搜索引擎不一样。在 CNI + eBPF 里面也是，dataplane 可以类似，但上层的差异化能做的东西是很多的。

也有可能等 eBPF 非常成熟之后，官方下场开始自己做，也是有可能的。不过在这之前，只能自己做了。

CNI Notes: IPAM

hang.yan@hotmail.com (涯余) — Fri, 17 Sep 2021 14:05:47 +0800

CNI相关笔记，本文主要记录下 IPAM 功能相关。

CNI的职责包括给 Container 分配网络设备，并且分配IP. IPAM(IP Address Management)就是指IP分配相关的功能和规范。

CNI本身只是一个规范，不同的实现在 IPAM 方面的功能集也不尽相同。下面将首先尝试说明下不同 CNI在这块的实现。

CNI实现

Calico

calico开发的IPAM组件叫 calico-ipam, 它使用 calico 的 IP pool resource来管理 IP. 它的主要优势就是可以将 pool 分割成小的 block, 并且可以动态对分配给不同的 node. node 上的 ip 利用率会更高，并且可扩展性也很好。calico 目前也支持给不同的 namespace分配不同的 ip pool. 从大的方面来看，其实最终各个CNI 实现要解决的问题都是类似的，一般区别只是 dataplane 以及具体的 CRD的设计不太一样。所以这些功能很可能(已经有了或者以后会有)出现在其他的 CNI 上面。

下面看一个实际的例子:

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
 name: external-pool
spec:
 cidr: 172.16.0.0/26
 blockSize: 29
 ipipMode: Always
 natOutgoing: true

---


apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
 name: internal-pool
spec:
 cidr: 192.169.0.0/24
 blockSize: 29
 ipipMode: Always
 natOutgoing: true

这里面可以创建两个 IPPool, 并且可以通过给 NS 打 label 的方式，分配给不同的 NS.

Host-local IPAM

host-local 算是比较简单的一个实现，可以根据静态文件配置来实现ip分配。flannel 默认用的就是 host-local ipam. 示例配置:

{
 "name": "cni0",
 "ipam": {
 "type": "host-local",
 "subnet": "10.244.0.0/24",
 "dataDir": "/var/lib/cni/networks"
 }
}

Cilium

cilium 本身支持多种 ipam (calico也是，既支持calico-ipam, 也支持host-local)：

cluster scope: 这种比较有意思的地方它用一个自定义的 Node 资源，v2.CilumNode来管理 CIDR. 虽然没有看到详细的文档说具体有什么特别的功能，但这样做的好处很明显: 自定义程度比较高，不再受限于官方的 Node 资源。相当于把这部分功能完全拿到 CNI 来控制了。
CRD-backed: 提供了一个 CRD 来记录 ip 的使用。这样可以允许第三方的组件来管理 ip.

Antrea

Antrea目前用的也是 host-local ipam. 在一些 host-local 不可用的场景下，它也支持在内部启用这块相关的 controller 代码来启用相同的功能。

总结

本文只是概要总结，涉及的并不深入。总体趋势是 CNI 实现会趋向于使用 plugin-in的架构，以便于支持多种IPAM机制。一般会包括 host-local, CRD based等等。从功能上来说，会有单个 Node 多个 IP Range的需求，以及不同 Namespace 使用不同 ip pool的需求。

Rebuild Kernel 生成 BTF 文件

hang.yan@hotmail.com (涯余) — Wed, 01 Sep 2021 11:42:02 +0800

在测试 golang + libbpf + ebpf 的时候发现一个问题，load ebpf object时，报错说找不到 BTF 文件。这个很奇怪，我已经 include 了 vmlinux.h, 按说不应该再依赖于 BTF 文件。看了下 libbpf 的代码,大概出错的地方在:


/*
 * Probe few well-known locations for vmlinux kernel image and try to load BTF
 * data out of it to use for target BTF.
 */
struct btf *btf__load_vmlinux_btf(void)
{
 struct {
 const char *path_fmt;
 bool raw_btf;
 } locations[] = {
 /* try canonical vmlinux BTF through sysfs first */
 { "/sys/kernel/btf/vmlinux", true /* raw BTF */ },
 /* fall back to trying to find vmlinux ELF on disk otherwise */
 { "/boot/vmlinux-%1$s" },
 { "/lib/modules/%1$s/vmlinux-%1$s" },
 { "/lib/modules/%1$s/build/vmlinux" },
 { "/usr/lib/modules/%1$s/kernel/vmlinux" },
 { "/usr/lib/debug/boot/vmlinux-%1$s" },
 { "/usr/lib/debug/boot/vmlinux-%1$s.debug" },
 { "/usr/lib/debug/lib/modules/%1$s/vmlinux" },
 };
 char path[PATH_MAX + 1];
 struct utsname buf;
 struct btf *btf;
 int i, err;

 uname(&buf);

 for (i = 0; i < ARRAY_SIZE(locations); i++) {
 snprintf(path, PATH_MAX, locations[i].path_fmt, buf.release);

 if (access(path, R_OK))
 continue;

 if (locations[i].raw_btf)
 btf = btf__parse_raw(path);
 else
 btf = btf__parse_elf(path, NULL);
 err = libbpf_get_error(btf);
 pr_debug("loading kernel BTF '%s': %d\n", path, err);
 if (err)
 continue;

 return btf;
 }

 pr_warn("failed to find valid kernel BTF\n");
 return libbpf_err_ptr(-ESRCH);
}

猜测是用到了 CO-RE 相关的功能，走到了这块逻辑。奇怪的是我已经通过 ddeb repo安装了相关的 vmlinux 文件。但还是不行。这个后续还是要查查，比较快的解决方案就是 rebuild kernel 带上 BTF 先跑通。

ubuntu 的话算是比较容易了，官方的方法是:

从 src repo 里 download source
copy old config, 加上 BTF 开关
fakeroot build 成 deb 包
install deb package 即可。重启。

还是比较简单的，但是有个问题。第三步骤依赖于 pahole 这个 binary. 如果用 fakeroot 就找不到了，也没看到相关文档说怎么在fakeroot的时候配置 PATH. 所以我的方法就是去掉了 fakeroot, 大概步骤代码如下

# 1. comment out deb-src repo in /etc/apt/source.list
# 2. update repo
apt update
# 3. download kernel source package
apt-get source linux-image-unsigned-$(uname -r)

# 4. 下载完之后已经自动解压好了
cd <linux-source-dir>
# 5. copy old config
cp /boot/config-`uname -r` .config
# 6. 搜索BTF,打开开关
# 7. 开始编译，大概需要一个多小时，20-30G左右的磁盘
make -j `getconf _NPROCESSORS_ONLN` deb-pkg
# 8. install debpackages
# 9. reboot
reboot

Links:

如何生成 vmlinux.h

hang.yan@hotmail.com (涯余) — Wed, 25 Aug 2021 13:28:21 +0800

eBPF 的一些开发方案里涉及到 vmlinux.h, 它包含了kernel里所有用到的data structure等等。有了它可以方便地替代其他一大堆杂七杂八的头文件。网上基本上都提到了如何用 vmlinux 来生成 vmlinux.h, 但最开始的 vmlinux 怎么来的并没有找到比较明确的文档。本来将提供一个比较全面的如何生成 vmlinux.h 的文档.

环境说明

OS: ubuntu 20.04.1
Kernel: 5.4.0-70

安装 vmlinux

需要添加 ddeb 的源

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
echo -e "deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse\ndeb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list

repo key相关的

sudo apt install ubuntu-dbgsym-keyring

安装

apt-get update
sudo apt-get install linux-image-$(uname -r)-dbgsym

最后安装好的文件在 /usr/lib/debug/boot/ 目录下。

注意 /boot 下面有类似的文件，但那是压缩过的，不能直接用。所以最好还是按上述方法直接下载。

安装 bpftool

bpftool 需要从 kernel source code里生成,或者直接从repo里安装.

# 自己 download 相应version的kernel或者用git仓库
cd linu
cd tools/bpf/bpftool/
make install

如果从 repo 里安装

apt install linux-tools-common

生成 vmlinux.h

可能是我从source里build出来的bpftool有问题，这一步只是用repo里安装的bpftool成功了

bpftool btf dump file <vmlinux-path> format c > vmlinux.h

libbpf提供了一些功能，可以保证vmlinux.h在不同kernel version之间的兼容性.

卸载UOS

hang.yan@hotmail.com (涯余) — Tue, 25 May 2021 10:34:33 +0800

用了大半年，最近卸载了。整体来说，不如最开始的期待。优点仍在，但缺点对于重度使用者来说，难以忍受。

将常见应用做到开箱即用，这是个很大的贡献，也是目前所有 Linux 发行版里做的最好的一个，这点不可抹杀。但正如其他的一些本地化分支一样，稳定性都相比于 Debian/Ubuntu 大幅度降低了。这点在长期使用中会逐渐暴露出来，并且抵消掉前者带来的优势。如果UOS想继续好好做下去，后面的着力点也应该是这个。

就我的体验来说，问题主要是以下几个：

电脑发热明显，最开始是非夏天用的感觉还不明显，到了夏天非常严重。而换了ubuntu之后好转。
移除了添加repo的一些命令，让开发者很难受
界面稳定性差，基本上难以做到经常不关机

这里面部分是 Deepin 的问题，部分是 UOS 的问题了。其他的国内的发行版总体来说都是更差。

从产品角度来说，用户想要什么以及该怎么做其实是很明显的。既然有这个人力物力了，就应该定好优先级，把这些核心的问题解决好，这样才能普及开来。

另外从美观程度上来讲，不算差，但也不算太好。很多方面也不如 Ubuntu 的 Unity. 如何用统一美观的设计语言去做出一个美观好用的界面，应该就是下一阶段的重点了。

《老友记》的人物塑造

hang.yan@hotmail.com (涯余) — Thu, 25 Feb 2021 13:42:00 +0800

我平时基本上把《老友记》当相声了，作为室内的背景音。因为看了好几篇，听的次数也很多。感受也跟刚看差别比较大。网上也经常看到对此剧的分析与评论。毫无疑问，这是一部极其优秀的室内情景喜剧，好于《生活大爆炸》等后来者。除了演员的精彩演绎之外，编剧的能力也极为突出，很多笑点都极为巧妙，并且能多次触发，互相呼应。而社交平台上对于剧中人物的喜好会讨论的更多一些，因为此类电视剧一般都是多主角并存，场景有限，所以人物的塑造极其重要。而《老友记》在此方面暴露出来了一个致命的问题就是：很多观众会讨厌剧中的某个人物。

这个现象听起来很合理。但并不常见，拿《BBT》，《硅谷》，《破产姐妹》等剧情来讲，虽然剧集的质量参差不齐，而且剧中各个人物的性格特点都千差万别，但基本上不会有人说特别讨厌摸个剧中人物。《BBT》中 Sheldon 的性格可能最招人厌，极端的自我，但真正对他厌恶的人是很少的。因为他是的角色设定很自洽，他的“令人不喜欢的”性格特征是有原因的，并且是在朋友的帮助下，他也逐渐的变得更通人情世故。《破产姐妹》的剧质量一般，但里面的角色设定也是比较出色，没有说哪个角色让人生厌。而《老友记》不同，有的人很讨厌Ross, 有的人很讨厌 Rachel等。一个可能的因素是《老友记》最贴近日常，大家容易代入。当然主要的原因还是人物角色设定的失败。

讨厌 Ross 的人，觉得他渣男，不负责任。

Kubernetes 的 Server-Side Apply

hang.yan@hotmail.com (涯余) — Thu, 18 Feb 2021 15:25:47 +0800

从 Kubernetes 1.18 开始,可以看到一个明显的变化就是资源的 YAML 在 metadata 部分多了很多信息:

apiVersion: v1
kind: Namespace
metadata:
 creationTimestamp: "2021-02-18T03:03:40Z"
 managedFields:
 - apiVersion: v1
 fieldsType: FieldsV1
 fieldsV1:
 f:status:
 f:phase: {}
 manager: kube-apiserver
 operation: Update
 time: "2021-02-18T03:03:40Z"
 name: default
 resourceVersion: "199"
 uid: 2f4536b5-7302-4dc1-9620-052a567c917c
spec:
 finalizers:
 - kubernetes
status:
 phase: Active

比如这个 NS 的例子, 其中大部分都是 mangedFields部分.简单来讲,managedFields 字段是用来声明一个资源的各个字段的具体的管理者是谁.我们可以参考一个有点类似的案例, Node 的 conditions 字段:

 conditions:
 - lastHeartbeatTime: "2021-02-18T03:05:25Z"
 lastTransitionTime: "2021-02-18T03:05:25Z"
 message: Flannel is running on this node
 reason: FlannelIsUp
 status: "False"
 type: NetworkUnavailable
 - lastHeartbeatTime: "2021-02-18T07:34:05Z"
 lastTransitionTime: "2021-02-18T03:03:36Z"
 message: kubelet has sufficient memory available
 reason: KubeletHasSufficientMemory
 status: "False"
 type: MemoryPressure

Contaions 是一个列表,不同的 Component 负责上报自己所观察到的信息,最终汇总到 Node 的 Status 下面.然后再合并汇总出一个整体的 Ready 状态. mangedFieds 也是有点类似的思路, 一个资源的不同部分是由不同组件/人负责维护的,显式的声明这种维护关系有助于各方协同地维护一个资源完整的状态.更直观的,我们可以看一个 Deployment 的例子. 首先,我们使用如下的 deployment 文件来创建

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
 app: nginx
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.14.2

创建命令是:

# -n 后面是希望使用的 namespace, 非关键信息
kubectl apply -f d.yaml -n ssa

最终生成的 deployment 如下所示(部分信息):

apiVersion: apps/v1
kind: Deployment
metadata:
 annotations:
 deployment.kubernetes.io/revision: "1"
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"ssa"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"nginx"}},"template":{"metadata":{"labels":{"app":"nginx"}},"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx"}]}}}} 
 creationTimestamp: "2021-02-18T07:41:40Z"
 generation: 1
 labels:
 app: nginx
 managedFields:
 - apiVersion: apps/v1
 fieldsType: FieldsV1
 fieldsV1:
 f:metadata:
 f:annotations:
 .: {}
 f:kubectl.kubernetes.io/last-applied-configuration: {}
 f:labels:
 .: {}
 f:app: {}
 f:spec:
 f:progressDeadlineSeconds: {}
 f:replicas: {}
 f:revisionHistoryLimit: {}
 f:selector: {}
 f:strategy:
 f:rollingUpdate:
 .: {}
 f:maxSurge: {}
 f:maxUnavailable: {}
 f:type: {}
 f:template:
 f:metadata:
 f:labels:
 .: {}
 f:app: {}
 f:spec:
 f:containers:
 k:{"name":"nginx"}:
 .: {}
 f:image: {}
 f:imagePullPolicy: {}
 f:name: {}
 f:resources: {}
 f:terminationMessagePath: {}
 f:terminationMessagePolicy: {}
 f:dnsPolicy: {}
 f:restartPolicy: {}
 f:schedulerName: {}
 f:securityContext: {}
 f:terminationGracePeriodSeconds: {}
 manager: kubectl-client-side-apply
 operation: Update
 time: "2021-02-18T07:41:40Z"
 - apiVersion: apps/v1
 fieldsType: FieldsV1
 fieldsV1:
 f:metadata:
 f:annotations:
 f:deployment.kubernetes.io/revision: {}
 f:status:
 f:availableReplicas: {}
 f:conditions:
 .: {}
 k:{"type":"Available"}:
 .: {}
 f:lastTransitionTime: {}
 f:lastUpdateTime: {}
 f:message: {}
 f:reason: {}
 f:status: {}
 f:type: {}
 k:{"type":"Progressing"}:
 .: {}
 f:lastTransitionTime: {}
 f:lastUpdateTime: {}
 f:message: {}
 f:reason: {}
 f:status: {}
 f:type: {}
 f:observedGeneration: {}
 f:readyReplicas: {}
 f:replicas: {}
 f:updatedReplicas: {}
 manager: kube-controller-manager
 operation: Update
 time: "2021-02-18T07:41:42Z"
 name: nginx-deployment

其中 f 后面跟的是 field 的名字,其他部分都比较直观.可以看到 managedFieds 包含两个 item:

第一个manager 是 kubectl-client-side-apply.因为这个 deploy 是我直接用 kubectl apply 创建的. 默认 kubectl apply 使用的是 Client-Side Apply 而不是 Server-Side Apply.
第二个manager 是 kube-controller-manager, 比较直观.对比两个 manager 所管理的字段列表来看, kube-controller-manager管理的都是我们通常看到的由 系统 自动填充的信息, 比如 conditions, .status.repliacs等.而kubectl-client-side-apply 则是管理那些用户自己输入的信息.

如上所展示的 manager 机制即是 Server-Side Apply的核心, 下面将详述细节.

kubectl apply

首先我们需要大概了解 kubectl apply做了什么,分为如下几步:

GET 查询目标 Object
如果 Object 不存在,则提交到API创建,并且将用户提供的 input 信息放到新创建的 Object 的 annotations里(key 为 kubectl.kubernetes.io/last-applied-configuration)
如果 Object 已存在, 先读取到旧的 Object 的 kubectl.kubernetes.io/last-applied-configuration 的值, 然后与当前的做对比, 生成一个 diff (strategic merge patch), 用 PATCH 发给 API Server. 其中 diff 里面也会附带上最新的 kubectl.kubernetes.io/last-applied-configuration.

其中, strategic merge patch 需要单独提一下,它的主要特点就是对于 list 的 update 提供了 patchStrategy 以便对不同的字段做不同的处理.比如我们常见的 Pod 的 containers 列表:

type PodSpec struct {
 ...
 Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`

举个例子.最初始的 Pod Template 如下:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: patch-demo
spec:
 replicas: 2
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: patch-demo-ctr
 image: nginx
 tolerations:
 - effect: NoSchedule
 key: dedicated
 value: test-team

假设想用如下的 yaml PATCH 这个 deploy

spec:
 template:
 spec:
 containers:
 - name: patch-demo-ctr-2
 image: redis

kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"

依赖于上面的 containers patch 策略的声明,我们能得到如下的最终结果:

containers:
- image: redis
 imagePullPolicy: Always
 name: patch-demo-ctr-2
 ...
- image: nginx
 imagePullPolicy: Always
 name: patch-demo-ctr
 ...

这样更符合用户的期望.而其他的一些字段,如果没有声明 patchStrategy, 那么默认操作是 replace.

何为 Service-Side Apply

Server-Side Apply 可以字面地理解为将 kubectl apply的工作迁移到 Server 端来进行, 准确地可以定义为一种新的Merge算法.它的好处如下:

--dry-run如果是在 client 端进行,那么因为 Server 端存在各种 webhook以及 injector,很难模拟真实的情况.如果 –dry-run 放在服务端, 如果出错了,可以通过新加的 mangedFields 机制给用户更明确的提示
如果不用 kubectl 而是 API 开发则很难利用到 kubectl 提供的功能
比 kubectl apply 使用的 kubectl.kubernetes.io/last-applied-configuration 更加声明式一些.用户发送一个资源的manifest,其中包含了自己关心的字段的期待状态.
防止用户误修改一些字段
多个组件/用户对资源的协作管理
其他一些在 Server 端实现起来更简单的地方

Server-Side Apply 利用 managedFields 字段,追踪了各个字段的归属,并且能在更新的时候提供冲突检测(manager不匹配),并提供更为准确的提示.

managedFields 详解

现在我们可以详细看下 managedFields的内容:

 - apiVersion: apps/v1
 fieldsType: FieldsV1
 fieldsV1:
 f:metadata:
 f:annotations:
 .: {}
 f:deployment.kubernetes.io/revision: {}
 f:status:
 f:availableReplicas: {}
 f:conditions:
 .: {}
 k:{"type":"Available"}:
 .: {}
 f:lastTransitionTime: {}
 f:lastUpdateTime: {}
 f:message: {}
 f:reason: {}
 f:status: {}
 f:type: {}
 k:{"type":"Progressing"}:
 .: {}
 f:lastTransitionTime: {}
 f:lastUpdateTime: {}
 f:message: {}
 f:reason: {}
 f:status: {}
 f:type: {}
 f:observedGeneration: {}
 f:readyReplicas: {}
 f:replicas: {}
 f:updatedReplicas: {}
 manager: kube-controller-manager
 operation: Update
 time: "2021-02-18T04:58:50Z"

其中:

f: 代表字段名
v: 代表 value, 字段的值
k: 代表 key, map object, 包含 f/v
i: index, 数组的索引

k 不太好理解, 对应的资源字段示例如下:

status:
 availableReplicas: 3
 conditions:
 - lastTransitionTime: "2021-02-18T04:58:50Z"
 lastUpdateTime: "2021-02-18T04:58:50Z"
 message: Deployment has minimum availability.
 reason: MinimumReplicasAvailable
 status: "True"
 type: Available
 - lastTransitionTime: "2021-02-18T04:56:00Z"
 lastUpdateTime: "2021-02-18T04:58:50Z"
 message: ReplicaSet "nginx-deployment-877f48f6d" has successfully progressed.
 reason: NewReplicaSetAvailable
 status: "True"
 type: Progressing
 observedGeneration: 1
 readyReplicas: 3
 replicas: 3
 updatedReplicas: 3

另外:

manager: 操作主体
operator: 动作
time: 操作时间

如下所示,我们将上面用到的 deployment 修改一下,然后用不同的 manager 去 apply 一下试试:

➜ server-side-apply git:(master) ✗ kubectl apply -f d.yaml --server-side --field-manager='test1'
error: Apply failed with 1 conflict: conflict with "kubectl-client-side-apply" using apps/v1: .spec.replicas
Please review the fields above--they currently have other managers. Here
are the ways you can resolve this warning:
* If you intend to manage all of these fields, please re-run the apply
 command with the `--force-conflicts` flag.
* If you do not intend to manage all of the fields, please edit your
 manifest to remove references to the fields that should keep their
 current managers.
* You may co-own fields by updating your manifest to match the existing
 value; in this case, you'll become the manager if the other manager(s)
 stop managing the field (remove it from their configuration).
See http://k8s.io/docs/reference/using-api/api-concepts/#conflicts

上面的错误提示也展示了在冲突时可能的几种解决办法:

覆盖: 如果确定是要修改,可以使用foce参数,强制覆盖,并且将其manager变更为自己
忽略: 如果本身并不关心这个字段的值,可以将其从自己的 manifest 中移除然后重试
共享: 将冲突字段改为原来的值,这种情况下更新后将与原来的manager共享管理.

同时需要注意的时,通常的两种更新操作对 manager 的处理也不同:

PATCH: content type 为 application/apply-patch+yaml, 冲突逻辑如上所示
UPDATE: 其他更新方式,完全忽略冲突

Controller 的使用

目前常用的对 resource 的操作基本上都遵循一个 READ-UPDATE 的步骤,因为 resourceVersion 的冲突问题. Service-Side Apply 有望能去掉 READ 这步,直接进行 UPDATE 操作.

一般也推荐 controller 在遇到冲突的时候执行 force 操作.

现状

功能仍有缺陷, 接口复杂,未到 stable 状态,尽量不用使用.

LB系列1 - Bandaid

hang.yan@hotmail.com (涯余) — Mon, 18 Jan 2021 13:33:12 +0800

很多大厂的LB都是自研的，而且设计考量都不相同。本文介绍 Dropbox自研的LB，名字叫 Bandaid.参考链接: Meet Bandaid, the Dropbox service proxy.

Queue设计

Bandaid 处理 Queue 中的 Request 的思路是后近先出(Last in, First out)。当系统负载不高的时候，Queue中的数据其实不多，那么先进后出或者后进先出其实区别不大。如果负载过高，考虑到先进的排队太久，可能很快就timeout了，还不如优先处理后进来的 request.

User Space的 Read Queue

Read Requests 会被放到一个用户态的 Queue 中，而不是 kernel 里的 queue中。这样做的原因是，可以在用户态提前关闭已经被 client close的 request, 而不是等到真正的request经由 kernel, 然后 application 在处理的时候才发现 request 已经 close 了。尤其是 client 一般还带有重试，很容易把 Kernel queue打满。User Space 的 Queue 能够通过处理只把正常的 request 传给后面。

权重以及 Route划分

精细程度可以做到按照 Route 将一个 Service 的重要的 Route 以及不重要的 Route 按权重定向到不同的 Backend上。不同的 Queue 可以有不同的权重，rate limit, 并发度。

算法笔记(1): 链表及其应用

hang.yan@hotmail.com (涯余) — Thu, 03 Dec 2020 16:27:39 +0800

最近准备系统的过一遍算法。一是因为看的很多项目最终多多少少都会涉及到算法，如果提前了解好会理解的更深入。二是之前也没有系统的看过，最近想定一个比较长久的学习计划。看文章的话网上质量参差不齐，有些东西只能这样弄，自己花时间慢慢找，总结，记录。算法这类前两天想看 LevelDB, 然后又得先看 LSM Tree, 然后发现还是得看红黑树。然后在网上找，发现文章一大堆，但写的都不行。我觉得想要了解红黑树的基本上肯定都会有一个疑惑“为啥要两种颜色”，可惜基本上没几篇文章能把这个东西讲清楚，知其然而不知其所以然。所以最终决定第一次在网上买了一个电子课，因为发现能讲的清楚的一篇文章是从这门课里摘录的。

所以后面会尝试更新一个持续的算法系列，笔记性质的。记录一些感兴趣的点。然后才是其他的一些感兴趣的项目和技术。本身作为第一篇，跳过了一些更基础的，直接从链表开始了。

链表本身也比较简单，基本原理都清楚。我觉得从应用层来看更有意思一点。主要就是两个

约瑟夫问题
LRU等算法

约瑟夫问题

阿橋问题（有时也称为约瑟夫斯置换），是一个出现在计算机科学和数学中的问题。在计算机编程的算法中，类似问题又称为约瑟夫环。

人们站在一个等待被处决的圈子里。计数从圆圈中的指定点开始，并沿指定方向围绕圆圈进行。在跳过指定数量的人之后，处刑下一个人。对剩下的人重复该过程，从下一个人开始，朝同一方向跳过相同数量的人，直到只剩下一个人，并被释放。

问题即，给定人数、起点、方向和要跳过的数字，选择初始圆圈中的位置以避免被处决。

或者更加数学的问法: 已知 n 个人（以编号1，2，3…n分别表示）围坐在一张圆桌周围。从编号为 k 的人开始报数，数到 m 的那个人出圈；他的下一个人又从 1 开始报数，数到 m 的那个人又出圈；依此规律重复下去，直到剩余最后一个胜利者。

这个问题可能是与单项循环链表最贴近的一个问题模型了。每个人都是一个节点，然后出局的人可以用操作指针的方法将其从链表中移除即可，最后剩下一个人的时候就是答案。下面是C代码

#include <stdio.h>
#include <stdlib.h>

/*声明一个链表节点*/
typedef struct node
{
 int number;//数据域，存储编号数值
 struct node *next;//指针域，指向下一个节点
}Node;

/*创建链表节点的函数*/
Node* CreatNode(int x)
{
 Node *p;
 p = (Node*)malloc(sizeof(Node));
 p->number = x;//将链表节点的数据域赋值为编号
 p->next = NULL;
 return p;
}

/*创建环形链表，存放整数1到n*/
Node* CreatJoseph(int n)
{
 Node *head,*p,*q;
 int i;
 for(i = 1; i <= n; i++)
 {
 p = CreatNode(i);//创建链表节点，并完成赋值
 if(i == 1)//如果是头结点
 head = p;
 else//不是头结点，则指向下一个节点
 q->next = p;
 q = p;
 }
 q->next = head;//末尾节点指向头结点，构成循环链表
 return head;
}

/*模拟运行约瑟夫环，每数到一个数，将它从环形链表中删除，并打印出来*/
void RunJoseph(int n,int m)
{
 Node *p,*q;
 p = CreatJoseph(n);//创建循环链表形式的约瑟夫环
 int i;
 while(p->next != p)//循环条件，当前链表数目大于1
 {
 for(i = 1; i < m-1; i++)//开始计数
 {
 p = p->next;
 }
 //第m个人出圈
 q = p->next;
 p->next = q->next;
 p = p->next;
 printf("%d--",q->number);//输出出圈的序号
 free(q);
 }
 printf("n最后剩下的数为：%dn",p->number);
}

int main()
{
 int n,m;
 scanf("%d %d",&n,&m);
 RunJoseph(n,m);
 return 0;
}

LRU算法

不考虑各种优化算法的话，LRU场景本身也是很适合用来链表实现。需求描述如下:

如果此数据之前已经在缓存中，需要找到它，并且把它挪到表头
如果数据尚不在缓存中
1. 缓存未满，直接插入表头即可
2. 缓存已满，将表尾节点删除，将新数据插入表头

当然如果基于单向链表来实现的话，访问的时间复杂度都是O(n)。不过本文暂不涉及优化方式，后续再说。下面是一个示例的 go 实现

package main

import "fmt"

// LRU缓存淘汰策略的demo

// 这是一个单向链表的节点
type Node struct {
 Next *Node
 Value interface{}
}


// 缓存模型
type Memory struct {
 Head *Node // 头节点
 Max int32 // 链表的最大长度
}

// 向内存中插入变量的指针，若链表为空，则插入头节点
func (m *Memory) Insert(newNode interface{}) {
 if m.Head == nil {
 m.Head = &Node {
 Next: nil,
 Value: newNode,
 }
 return
 }

 var pre *Node // 前节点的指针
 current := m.Head // 当前节点位置
 var i int32 = 1 // 计数，第一个节点

 n := &Node {
 Next: m.Head,
 Value: newNode,
 }

 for {
 // 若该记录在内存中存在，则将其在链表相应位置删除，并插入链表的头部，若已在头部，则不变
 if current.Value == newNode {
 if pre != nil {
 pre.Next = current.Next
 m.Head = n
 }
 break
 }

 // 若当前节点是尾节点，则将变量指针插入链表头部，若长度超出了链表长度，则将链表最后一个节点删除
 if current.Next == nil {
 if i >= m.Max {
 pre.Next = nil
 m.Head = n
 } else {
 m.Head = n
 }
 break
 }

 pre = current
 current = current.Next
 i++
 }
}

func main() {
 m := &Memory{
 Max: 10,
 }
 for i := 0; i <= 11; i ++ {
 v := i
 m.Insert(&v)
 fmt.Printf("==========\n")
 fmt.Printf("head is %+v\n", m.Head)
 fmt.Printf("head value is %v\n", *m.Head.Value.(*int))
 fmt.Printf("==========\n")
 }
}

io_uring 介绍

hang.yan@hotmail.com (涯余) — Fri, 27 Nov 2020 11:18:00 +0800

这几年内核带来了很多革命性的新特性。一个是 ebpf, 现在主要被广泛应用于网络处理，性能分析等领域。另一个是 io_uring, 带来了真正的全异步IO。本文将对 io_uring 做简要介绍。

总览

在 io_uring 之前，只有 aio 这个异步框架。为什么要重新弄一套，是因为 aio 自身限制比较多，比如:

只支持 direct_io.而O_DIRECT要求bypass缓存和size对齐等，直接影响了很多场景的使用。而对buffered IO，其表现为同步。
即使满足了所有异步IO的约束，有时候还是可能会被阻塞，例如，等待元数据IO，或者存储设备的请求槽位都正在使用等等。
存在额外的开销，每个IO提交需要拷贝64+8字节，每个IO完成需要拷贝32字节，这在某些场景下影响很可观。在使用完成event的时候需要非常小心，否则容易丢事件。IO总是需要至少2个系统调用（submit + wait-for-completion)，在spectre/meltdown开启下性能下降非常严重。

aio本身扩展性也很差，很多基于aio的开发也经常需要用dirty hack的方式来满足自己的需求。Linux 自己对它的评价也不好:

So I think this is ridiculously ugly.

AIO is a horrible ad-hoc design, with the main excuse being “other, less gifted people, made that design, and we are implementing it for compatibility because database people — who seldom have any shred of taste — actually use it”.

还有一个需要注意的地方是上面提到的spectre/meltdown 攻击，为了应对这两个问题，一方面内核不再在用户态和内核间共享地址页表，每次异常、IO、系统调用，都要把内核页表重新装进来。另一方面，如果为了安全起见，指令预测也得关掉，性能能直接下降10%。这个因为导致系统调用的成本比之前更高。

所以，高效的异步io基本上就是如下几个思路:

少做或者不做系统调用
zero copy
lock free

io_uring在这几方面做的都比较好，对应的它分别用了以下几个技术:

ring_buffer. 将内核和userspace分别想象为生产者/消费者,通过两个ring_buffer通信
mmap
内存屏障

SQ/CQ

用到的两个ring_buffer分别叫 submission queue 和 completion queue.SQ是 application 生产，内核消费，CQ相反。这两个 ring_buffer 通过 mmap 在用户/内核态都可以访问。

用户程序往SQ里推送的数据叫SQE(submission queue entry).假设我们现在想读取一个文件，其内容大致如下:

opcode: 选定我们要执行的系统调用，readv, 对应一个 opcode叫 IORING_OP_READV
flags: 参数,可以用来调整 io_uring 的各种行为
fd: 涉及到的文件
address: 对于读取文件来说，这里指的是读取到的数据将要存放的目标地址
length: 数据的长度
user data: 一个用户将 SQE 和 CQE(completion queue entry)关联起来的标识符。因为异步IO事件是无序的，我们需要某种方式将二者关联起来。

对CQE来说，包含如下内容:

user data: 如上所介绍
result: readv 的返回结果

上图画出了一个大致的示意图。需要注意的是 SQ 与 CQ 有些区别。SQE并不是直接存放在 SQ中，而是存了其 index 到 SQ种，这样能给用户 appilcation 更高的自由度。下面用伪代码的方式展示了 SQ 和 CQ 的处理操作:

SQ:

struct io_uring_sqe *sqe;
unsigned tail, index;
tail = sqring→tail;
index = tail & (*sqring→ring_mask);
sqe = &sqring→sqes[index];
/* this call fills in the sqe entries for this IO */
init_io(sqe);
/* fill the sqe index into the SQ ring array */
sqring→array[index] = index;
tail++;
write_barrier();
sqring→tail = tail;
write_barrier();

CQ:

unsigned head;
head = cqring→head;
read_barrier();
if (head != cqring→tail) {
struct io_uring_cqe *cqe;
unsigned index;
index = head & (cqring→mask);
cqe = &cqring→cqes[index];
/* process completed cqe here */
...
/* we've now consumed this entry */
head++;
}
cqring→head = head;
write_barrier();

注意其中内存屏障的使用。

系统调用

io_uring 一共提供了 3 个系统调用：io_uring_setup()，io_uring_enter()，以及io_uring_register()，位于 fs/io_uring.c。

/**
 * io_uring_setup - setup a context for performing asynchronous I/O
 */
int io_uring_setup(u32 entries, struct io_uring_params *p);
/**
 * io_uring_enter - initiate and/or complete asynchronous I/O
 */
int io_uring_enter(int fd, unsigned int to_submit, unsigned int min_complete,
 unsigned int flags, sigset_t *sig)

/**
 * io_uring_register - register files or user buffers for asynchronous I/O
 */
int io_uring_register(int fd, unsigned int opcode, void *arg,
 unsigned int nr_args)

io_uring_setup

初始化uring.两个参数分别是:

entries：这个io_uring包含的 entry 数量
params: io_uring的参数，userspace/kernel都可以读写。

函数返回一个关于 io_uring 的 fd

io_uring_enter

提交IO请求:

fd: u_ring的fd
to_submit：要提交多少个请求
min_complete: 函数要返回的话需要等待多少个CQ

to_submit 和 min_complete 意味着这个函数既可以用来提交，也可以等待，或者二者皆可。

Polled Mode

对于很多应用来说，比如延迟敏感型或者高IOPS型，如果继续用中断的方式处理IO, 数据来的时候，driver 通知 kernel 来处理，过于低效了。这种情况下用主动的 poll 效果会更好，io_uring 提供了两种方式

userspace 的 poll: io_uring_setup的时候使用 IORING_SETUP_IOPOLL, 然后在 io_uring_enter 的时候使用 IORING_ENTER_GETEVENTS参数
kernel-side polling: 当前应用更新 SQ ring 并填充一个新的 sqe，内核线程 sqthread 会自动完成提交，这样应用无需每次调用 io_uring_enter() 系统调用来提交 IO。应用可通过 IORING_SETUP_SQ_AFF 和 sq_thread_cpu 绑定特定的 CPU。同时，为了节省无 IO 场景的 CPU 开销，该内核线程会在一段时间空闲后自动睡眠。应用在下发新的 IO 时，通过 IORING_ENTER_SQ_WAKEUP 唤醒该内核线程，用户态可以通过 sqring 的 flags 变量获取 SQ 线程的状态。

在 kernel-side polling的情况下，IO不需要系统调用。

SPDK相关

因为近几年的硬件性能的持续提升，尤其比如网卡和SSD等，旧有的很多IO优化逻辑可能已经不适用了。比如我们看下面的一个对比图:

这是 Intel 的 Optane SSD做的测试。我们可以看见在中间那一列，Storage with Optane SSD，随机读取的硬件延迟已经接近操作系统和文件系统带来的延迟，甚至 Linux VFS 本身会变成 CPU 瓶颈。其实背后的原因也很简单，过去由于 VFS 本身在 CPU 上的开销（比如锁）相比过去的 IO 来说太小了，但是现在这些新硬件本身的 IO 延迟已经低到让文件系统本身开销的比例不容忽视了。

网卡方面也是，现在主流的数据中心基本上开始提供 10GbE 甚至 25GbE 的网络。万兆网卡的吞吐差不多每秒 1488 万帧，处理一个包的时间在百纳秒的级别，基本相当于一个 L2 Cache Miss 的时间。所以如何减小内核协议栈处理带来的内核-用户态频繁内存拷贝的开销，成为一个很重要的课题。新硬件的提升，基本上在软件层的优化都是 kenrel bypass.比如网络方面的DPDK:

数据包直接从网卡到了 DPDK，绕过了操作系统的内核驱动、协议栈和 Socket Library。DPDK 内部维护了一个叫做 UIO Framework 的用户态驱动 (PMD)，通过 ring queue 等技术实现内核到用户态的 zero-copy 数据交换，避免了 Syscall 和内核切换带来的 cache miss，而且在多核架构上通过多线程和绑核，极大提升了报文处理效率.

而对于SSD存储来说，Intel 的开发套件: SPDK, 也是采用类似的优化方式。首先，将设备驱动代码运行在用户态，避免内核上下文切换和中断将会节省大量的处理开销，允许更多的时钟周期被用来做实际的数据存储。无论存储算法（去冗，加密，压缩，空白块存储）多么复杂，浪费更少的时钟周期总是意味着更好的性能和时延。在传统的I/O模型中，应用程序提交读写请求后进入睡眠状态，一旦I/O完成，中断就会将其唤醒。轮询的工作方式则不同，应用程序提交读写请求后继续执行其他工作，以一定的时间间隔回头检查I/O是否已经完成。这种方式避免了中断带来的延迟和开销，并使得应用程序提高了I/O效率。在机械硬盘时代，中断开销只占整个I/O时间的很小的百分比，因此给系统带来了巨大的效率提升。然而，在固态设备时代，持续引入更低时延的持久化设备，中断开销成为了整个I/O时间中不可忽视的部分。这个问题在更低时延的设备上只会越来越严重。系统已经能够每秒处理数百万个I/O，所以消除数百万个事务的这种开销，能够快速地复制到多个core中。数据包和数据块被立即分发，因为等待花费的时间变小，使得时延更低，一致性时延更多（抖动更少），吞吐量也得到了提高。

而内核当然也不是说跟不上时代，XDP及 io_uring 便是对应的解决方案。下面是一个 io_uring 与 SPDK 的性能对比:

(测试环境：神龙裸金属实例，96 CPU 503 G，本地盘为三星 PM963。)

io_uring 在开启 iopoll 后与 SPDK 接近，甚至在 queue depth 较高时性能更好。当然可能跟 intel 的 Optane SSD还是有点就差距，但对普通硬件来说，io_uring 已经能带来相当大的性能提升了。

其他高级功能

Fixed Files

IORING_REGISTER_FILES / IORING_REGISTER_FILES_UPDATE / IORING_UNREGISTER_FILES，通过 io_uring_register() 系统调用提前注册一组 file，缓解每次 IO 操作因 fget() / fput() 带来的开销。

Fixed Buffers

IORING_REGISTER_BUFFERS / IORING_UNREGISTER_BUFFERS，通过 io_uring_register() 系统调用注册一组固定的 IO buffers，当应用重用这些 IO buffers 时，只需要 map / unmap 一次即可，而不是每次 IO 都要去做，减少get_user_pages() / put_page() 带来的开销。

Linked SQE

IOSQE_IO_LINK，建立 sqe 序列之间的关联，这在诸如 copy 之类的操作中非常有用。使用 linked sqe 后，copy 操作的写请求链接在读请求之后，应用程序无需等待读请求数据返回后再下发写请求，而是共享了同一个 buffer，避免了上下文切换的开销。

与 epoll 的对比

epoll 通常的编程模型如下：

struct epoll_event ev;

/* for accept(2) */
ev.events = EPOLLIN;
ev.data.fd = sock_listen_fd;
epoll_ctl(epollfd, EPOLL_CTL_ADD, sock_listen_fd, &ev);

/* for recv(2) */
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = sock_conn_fd;
epoll_ctl(epollfd, EPOLL_CTL_ADD, sock_conn_fd, &ev);

new_events = epoll_wait(epollfd, events, MAX_EVENTS, -1);
for (i = 0; i < new_events; ++i) {
 /* process every events */
 ...
}

将fd通过epoll_ctl进行注册，当该fd上有事件ready, 在epoll_wait返回时可以获知完成的事件，然后依次调用每个事件的handler, 每个handler里调用recv(2), send(2)等进行消息收发。

io_uring的编程模型如下(这里用到了liburing提供的一些接口):

/* 用sqe对一次recv操作进行描述 */
struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
io_uring_prep_recv(sqe, fd, bufs[fd], size, 0);

/* 提交该sqe, 也就是提交recv操作 */
io_uring_submit(&ring);

/* 等待完成的事件 */
io_uring_submit_and_wait(&ring, 1);
cqe_count = io_uring_peek_batch_cqe(&ring, cqes, sizeof(cqes) / sizeof(cqes[0]));
for (i = 0; i < cqe_count; ++i) {
 struct io_uring_cqe *cqe = cqes[i];
 /* 依次处理reap每一个io请求，然后可以调用请求对应的handler */
 ...
}

阿里做过一些关于二者性能数据的一些对比(echo_server场景)

(在meltdown和spectre漏洞修复场景下测试)

)

可以看到:

io_uring可以极大的减少用户态到内核态的切换次数，在连接数超过300时，io_uring用户态到内核态的切换次数基本可以忽略不计
连接数1000及以上时，io_uring的性能优势开始体现，io_uring的极限性能单core在24万qps左右，而epoll单core只能达到20万qps左右，收益在20%左右

参考项目

KV系列1 - LMDB

hang.yan@hotmail.com (涯余) — Thu, 26 Nov 2020 14:41:44 +0800

注: 本文仅为笔记，不怎么通顺和严谨。

KV系列属于一个大规模场景的必备品，而且通常很多公司会选择自研，一方面是各种不同产品均有局限，而大家的需求都有差别。另一方面社区已经有一些比较好的 building blocks，可以方便地进行组装和修改。最常见的情境是，分布式KV的开发 = 选一个底层kv存储 + 一个分布式协议。比如TiDB,ETCD等等。最近看 cloudflare 的 blog, 也是类似的场景。他们选的是 LMDB + 自研的分布式策略(称不上算法，比较简单)，也很好的满足了自己的需求。

LMDB

全称是 Lightning Memory-Mapped Database, 使用内存映射文件，读写性能比较高。

LMDB的一些特性:

支持APPEND模式，提高写操作的性能
支持多进程/线程同时访问。这种场景下读性能可以随着实例数增加而线性提升。
单独写不block读, 读也不 block 写。
不需要 transcation log, 提高了写性能。

实现上来讲，利用内存映射是一大特色。通常的文件读取操作，通过read系统调用，要先把数据从硬盘 copy 到内核，然后再拷贝到用户空间。而 mmap，不直接进行数据拷贝，而是在缺页中断时进行处理。而且是直接拷贝到用户态，所以会比 read 效率高些。另外，这种内存映射是只读的，也避免了程序错误破坏存储结构。写操作则是通过 write 系统调用完成，由系统来保证数据一致性。其他细节：

使用 B+ tree.
LMDB只允许单个写，性能有所降低，但是不再需要WAL日志，以及其他种种并发控制的冲突及代价。
LMDB中，数据的基本操作单元是页，COW也是以页为单位。
如果写操作比较多，那么数据版本也会很多，旧数据会占用大量空间。LMDB会将旧的页插入到一棵B+tree当中，然后等没有事物再用到它之后就可以重复利用。这样省去了定期清理操作，但是无法保证数据可以恢复到任意时刻了。
数据访问可以直接返回内存指针，避免内存拷贝。
COW保证存储结构一直是合法的。系统崩溃不会导致数据库处于一个不一致的状态。最坏的情况只是丢失了一些未提交的数据。根据一些学界的研究，尚没有发现因为使用 LMDB 导致数据损坏的案例。

LMDB中事物的实现思路如下:

Atom（A）: LMDB中通过txn数据结构和cursor数据结构的控制，通过将脏页列表放入 dirtylist中，当txn进行提交时再一次性统一刷新到磁盘中或者abort时都不提交保证事务要不全成功、要不全失败。对于长事务，若页面spill到磁盘，因为COW技术，这些页面未与整棵B-Tree的rootpage产生关联，因此后续的事务还是不能访问到这些页面，同样保证了事务的原子性。
Consistency(C): 有如上的操作,保证其数据就是一致的，不存在因为多线程同时写数据导致数据产生错误的情况。
Isolation（I）：事务隔离通过锁控制（MUTEX），LMDB支持的锁互斥是进程级别/线程级别，支持的隔离方式为锁表支持，读读之间不锁，写等待读完成之后开始，读等待写完成后开始.
Duration（D）:LMDB中，没有使用WAL、undo/redo log等技术来保证系统崩溃时数据库的可用性，其保证数据持续可用的技术是COW技术和只有一线程写技术。假如LMDB或者系统崩溃时，只有读操作，那么数据本来就没有发生变化，因此数据将不可能遭到破坏。假如崩溃时，有一个线程在进行写操作，则只需要判断最后的页面号与成功提交到数据库中的页面号是否一致，若不一致则说明写操作没有完成，则最后一个事务写失败，数据在最后一个成功的页面前的是正确的，后续的属于崩溃事务的，不能用，这样就保证了数据只要序列化到磁盘则一定可用，要不其就是还没有遵循ACI原则序列化到磁盘

总结来看，LMDB是一个极为优秀的产品。即使作者声称它主要是为了读场景而不是写场景，但实测的结果都不错。BUG少，稳定性强。

Cloudflare 的实践

Cloudflare 需要一个分布式的 KV Storage 来存储用户配置信息，当用户做了改动之后，能很快地分发到所有的数据中心。最开始用的是Kyoto Tycoon datastore, 在使用过程中发现了不少问题，最终切换到了 LMDB.

需求整理:

用户可以修改他们的配置数据，然后cloudflare会下发这些配置数据到每个区域的每个机器上。它期望的是每个数据中心即使与中控服务断了连接仍然可以独立服务。结构大致如下所示：

由中控节点先下发到各个数据中心的 Management Node, 然后再下发到各个work node 上。每个 work node 都依赖于下发的 config store 来做决断。

最开始，使用的就是 KT(Kyoto Tycoon datastore)。然后发现了的问题如下:

读写并发时，读性能下降的很快。排查发现是 flush to disk 的时候 block了。之前的解决办法只能是 disbale fsync, 只在 process shutdown的时候同步数据，代价就是数据损坏的可能性大大加大。数据量太大的情况下，shutdown 也会变得很慢，容易被 systemd kill 了。
跟上一条相关，数据一致性的问题。如果无法正常的 shutdown, 那么数据库容易损坏数据，尤其是在关闭 fsync 的情况下。KT 自带了一个修复的功能，但数据量大的情况下效率太低。所以 cloudflare 采取的策略是不修复，直接从健康的 node 上复制数据，代价就是运维成本大大增加了。
数据同步的问题。机器从 management node 获取的 transaction log 可能是不全的，因为中间有一些被GC了而无法找回。
不支持多进程同事访问一个数据库文件。这导致无法无缝升级。

这些问题无法通过运维手段来改善之后，cloudflare 就计划换 storage engine, 其考虑因为主要有如下几个：

支持运行时的 snapshot.LMDB 的架构做 snapshot 比较容易
读比写更频繁。
支出多进程并发访问
数据一致性好

LMDB在这几个方面支持的都比较好。但 LMDB 本身并不是一个分布式存储系统，还是需要 cloudflare 自己再其之上封装一层来达到其目的。首先就是复制协议上的改善，不再是KT那种基于时间戳的，而是基于递增数字:

< 0023 SET “hello” “world”
< 0024 SET “lorem” “ipsum”
< 0025 DEL “42”…

这样更容易确保数据一致性。另外因为写不频繁，可以由单一的数据中心来执行写操作，而且尽量使用 batch.其他方面的改进有:

transaction log(就是上面的同步协议里的内容) 也存在LMDB中
大 value 数据由程序切片和组装
支持 kv的 checksum
snappy 压缩 transcation log.
每个节点配置一些 primary server 和 secondary server. 前者用来同步数据。如果前者数据太老或者有问题，那么从后者同步。secondary server的数据一般会保留的更久。
升级时在client支持retry.并通过hand off sockets来执行新老程序交接。

C语言中的 strtok 函数

hang.yan@hotmail.com (涯余) — Tue, 24 Nov 2020 13:22:33 +0800

在看一个项目的代码时，发现了它用到了strtok 这个API, 它的作用是 split 一个字符串。这个功能在各个语言都很常见，而且接口也大同小异，比如 Golang:

s := strings.Split("a,b,c", ",")
fmt.Println(s)
// Output: [a b c]

Python:

txt = "hello, my name is Peter, I am 26 years old"

x = txt.split(", ")

print(x)

而 strtok 的接口就比较奇怪了，看一个例子:

Live Demo

#include <string.h>
#include <stdio.h>

int main () {
 char str[80] = "This is - www.tutorialspoint.com - website";
 const char s[2] = "-";
 char *token;

 /* get the first token */
 token = strtok(str, s);

 /* walk through other tokens */
 while( token != NULL ) {
 printf( " %s\n", token );

 token = strtok(NULL, s);
 }

 return(0);
}

输出为:

This is
 www.tutorialspoint.com
 website

也是同样的作用。但是它的实现上，第一次调用，看起来很正常，返回结果是第一个token.之后的循环调用，只用传分隔符，不断地拿剩下的 token。 man page 里的说明是:

The strtok() function is used to isolate sequential tokens in a null-terminated string, str. These tokens are separated in the string by at least one of the characters in sep. The first time that strtok() is called, str should be specified; subsequent calls, wishing to obtain further tokens from the same string, should pass a null pointer instead. The separator string, sep, must be supplied each time, and may change between calls.

这里是一个示例的 strtok 实现:


char *
strtok(s, delim)
 char *s; /* string to search for tokens */
 const char *delim; /* delimiting characters */
{
 static char *lasts;
 register int ch;

 if (s == 0)
 s = lasts;
 do {
 if ((ch = *s++) == '\0')
 return 0;
 } while (strchr(delim, ch));
 --s;
 lasts = s + strcspn(s, delim);
 if (*lasts != 0)
 *lasts++ = 0;
 return s;
}

它在内部用了一个 static 变量来记录上一次的信息，所以也是不可重入的,也不是线程安全的。这函数应该是比较老了，当时线程的library可能还不存在，可重入性也没那么重要。另外，它也修改了传入的 str。所以有些地方建议在token之前，copy一份数据再调用strtok:

char *token;
const char *path = getenv("PATH");
/* PATH is something like "/usr/bin:/bin:/usr/sbin:/sbin" */

char *copy = (char *)malloc(strlen(path) + 1);
if (copy == NULL) {
 /* Handle error */
}
strcpy(copy, path);
token = strtok(copy, ":");
puts(token);

while (token = strtok(0, ":")) {
 puts(token);
}

free(copy);
copy = NULL;

printf("PATH: %s\n", path);
/* PATH is still "/usr/bin:/bin:/usr/sbin:/sbin" */

所以有些地方也建议不要用这个函数:

Never use this function. This function modifies its first argument. The identity of the delimiting character is lost. This function cannot be used on constant strings.

(The Linux Programmer’s Manual (man) page on strtok(3))

只能感叹说 C/C++的很多 library 设计真是太古老了。

OpenKruise 简介

hang.yan@hotmail.com (涯余) — Sat, 21 Nov 2020 10:51:37 +0800

Kubernetes 作为一个 building blocks 来说，已经逐渐趋于稳定。大家对于其功能的增强，已经逐渐开始以 CRD + Controller Pattern 为主。另一方面，仍然有不少尝试是针对像 Deployment/StatefulSet/DaemonSet 这样的原始功能的。OpenKruise项目就是专注于此。原生的三种 Workload 能满足于日常的需求，但并不完善。在 OpenKruise 项目中，我们可以看到，多种 Workload 之间提供的功能是有很多共性的，我们可以提炼出他们的一些共同的功能模块, 比如:

分批升级
灰度更新
原地升级
SideCar管理
PVC管理
Pod 固定名字
…

这些原子功能有些原生的 workload 已经具有，有些没有。OpenKruise项目通过将这些原子功能排列组合，提供了一些功能增强型的 workload.下面将一一介绍。

SidecarSet

SidecarSet 定义了一些 sidecar 模板，然后通过 webhook 的方式注入到通过标签匹配的 Pod 中，这和 istio 等的方式比较像。它比较有用的地方在于，假设你希望给很多 Pod 注入一些通用的附加功能，比如 log, metrics或者init等功能，那么通过 SidecarSet 是一种比较好的方式。下面是一个 yaml 示例:

# sidecarset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
 name: test-sidecarset
spec:
 selector:
 matchLabels:
 app: nginx
 strategy:
 rollingUpdate:
 maxUnavailable: 2
 containers:
 - name: sidecar1
 image: centos:6.7
 command: ["sleep", "999d"] # do nothing at all
 volumeMounts:
 - name: log-volume
 mountPath: /var/log
 volumes: # this field will be merged into pod.spec.volumes
 - name: log-volume
 emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
 labels:
 app: nginx # matches the SidecarSet's selector
 name: test-pod
spec:
 containers:
 - name: app
 image: nginx:1.15.1

这个示例给 test-pod 注入了一个 sidecar1, 同时也加入了一个 log-volume. 另外，依据对 SidecarSet 不同字段的更新，相应的 Pod 有两种更新方式

更新 image: 被注入的 Pod 会被原地升级
更新其他字段： Pod 被重建时才会被更新

BroadcastJob

类似于 DaemonSet, 但它是一次性的 Job, 适合做一些基础软件升级,巡检等周期性的任务.

CloneSet

CloneSet 是对 Deployment 的一个功能增强,提供了如下能力:

PVC模板: 从 StatefulSet 借鉴的功能, 也做了一些优化
可以指定删除特定的 Pod 来缩容,通过在 spec 里指定名字的方式
原地升级功能. 如果只是更新了 image 或者 pod 的 metadata, 支持原地升级
分批灰度, 从 StatefulSet 的 partition 功能借鉴而来, 可以只更新部分 Pod

其他功能及详细说明可参考: CloneSet

Advanced StatefulSet

Advanced StatefulSet 是对普通的 StatefulSet 的一个功能增强，提供了如下功能:

MaxUnavailable 策略: StatefulSet 的升级策略是 one-by-one, MaxUnavailable 提供了并行升级的策略。
原地升级: 如果更新的是镜像或者 metadata信息，那么可以支持原地升级
无序升级: 不按 order 的升级，而是按预定义的优先级

具体细节不再详述，可参考: Advanced StatefulSet

Advanced DaemonSet

Advanced Daemonset 是对 DaemonSet 的一个增强。提供了如下功能:

升级方式： DamonSet 的升级方式是先删除旧的再起新的，Advanced DaemonSet 提供了另一种方式，先起新的，再删旧的(参考Deployment的滚动升级)。也可以设置 MaxSurge.
灰度升级: 通过标签选择，只升级部分节点上的 Pod
分批灰度升级: 只更新部分数量的 Pod (参考 StatefulSet 的功能)

可以看到,通过从其他的 workload 借来的一些功能， DaemonSet 的适用范围被大大增强了。

更详细的信息可参考: Advanced DaemonSet

UnitedDeployment

UnitedDeployment 于 pod 的分布策略有关。这里先介绍下 Kubernetes 提供的 Pod 拓扑分布概念。AWS提供了像AZ这样的功能，其他的公有云和私有云也多多少少有类似的概念，当我们在部署 Pod 的时候，希望能将 Pod 均衡地部署到不同的AZ之中以保证可用性。如下示例的 Pod:

kind: Pod
apiVersion: v1
metadata:
 name: mypod
 labels:
 foo: bar
spec:
 topologySpreadConstraints:
 - maxSkew: 1
 topologyKey: zone
 whenUnsatisfiable: DoNotSchedule
 labelSelector:
 matchLabels:
 foo: bar
 containers:
 - name: pause
 image: k8s.gcr.io/pause:3.1

其中 topologySpredConstraints 表达了如下意图:

以Node上的key为 zone 的标签为准划分Node为不同的Zone
labelSelector 选定的 Pod 作为同一类 Pod (同理 workload 的 pod 选择机制)
不同 Zone 之间的同类 Pod 的数量差距最多为1
如果发现 Pod 找不到符合 topology 要求的机器,那么不调度

我们也可以在 Scheduler 层面给一个集群定一个统一的 topology 策略,如下所示:

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration

profiles:
 - pluginConfig:
 - name: PodTopologySpread
 args:
 defaultConstraints:
 - maxSkew: 1
 topologyKey: topology.kubernetes.io/zone
 whenUnsatisfiable: ScheduleAnyway

而 UnitedDeployment 使用另一种方式来处理这个问题,它给不同的 Zone 分配不同的 workload, 彼此共用一套 workload 模板. 每个 UnitedDeployment 下每个区域的 workload 被称为 subset，有一个期望的 replicas Pod 数量。目前 subset 支持使用 StatefulSet 和 Advanced StatefulSet.

下面看一个例子:

apiVersion: apps.kruise.io/v1alpha1
kind: UnitedDeployment
metadata:
 name: sample-ud
spec:
 replicas: 6
 revisionHistoryLimit: 10
 selector:
 matchLabels:
 app: sample
 template:
 statefulSetTemplate:
 metadata:
 labels:
 app: sample
 spec:
 selector:
 matchLabels:
 app: sample
 template:
 metadata:
 labels:
 app: sample
 spec:
 containers:
 - image: nginx:alpine
 name: nginx
 topology:
 subsets:
 - name: subset-a
 nodeSelectorTerm:
 matchExpressions:
 - key: node
 operator: In
 values:
 - zone-a
 replicas: 1
 - name: subset-b
 nodeSelectorTerm:
 matchExpressions:
 - key: node
 operator: In
 values:
 - zone-b
 replicas: 50%
 - name: subset-c
 nodeSelectorTerm:
 matchExpressions:
 - key: node
 operator: In
 values:
 - zone-c
 updateStrategy:
 manualUpdate:
 partitions:
 subset-a: 0
 subset-b: 0
 subset-c: 0
 type: Manual
...

这个例子中, 最终有六个 Pod, 分成了三个StatefulSet, 同样是以标签匹配来划分不同的 Zone. 注意 subset 的 repliacs 可以用百分比的形式表示.

这个功能扩展开来,还可以支持多集群的场景.比如使用下面的 spec 定义:

type Topology struct {
 // ClusterRegistryQuerySpec is used to find the all the clusters that
 // the workload may be deployed to. 
 ClusterRegistry *ClusterRegistryQuerySpec
 // Contains the details of each subset including the target cluster name and
 // the node selector in target cluster.
 Subsets []Subset
}

type ClusterRegistryQuerySpec struct {
 // Namespaces that the cluster objects reside.
 // If not specified, default namespace is used.
 Namespaces []string
 // Selector is the label matcher to find all qualified clusters.
 Selector map[string]string
 // Describe the kind and APIversion of the cluster object.
 ClusterType metav1.TypeMeta
}

type Subset struct {
 Name string

 // The name of target cluster. The controller will validate that
 // the TargetCluster exits based on Topology.ClusterRegistry.
 TargetCluster *TargetCluster

 // Indicate the node select strategy in the Subset.TargetCluster.
 // If Subset.TargetCluster is not set, node selector strategy refers to
 // current cluster.
 NodeSelector corev1.NodeSelector

 Replicas *intstr.IntOrString 
}

type TargetCluster struct {
 // Namespace of the target cluster CRD
 Namespace string
 // Target cluster name
 Name string
}

利用了 kubernetes 的 clusterregistry API, 在 subset 里指定集群信息.

eBPF系列2 - XDP

hang.yan@hotmail.com (涯余) — Tue, 17 Nov 2020 23:16:48 +0800

XDP是指 eXpress data path, 基于 ebpf 技术上的高性能 data path. 其主要的意图是在网络 packet 处理的早期(网卡驱动处, 在数据包到达RX queue之后, 用hook的方式)，让用户可以编写 ebpf 程序来进行一些决策。这个hook的位置早于所有的内存分配时期(sk_buffer)，也没有上下文切换,系统调用等开销, 所以对于性能的提升是很明显的。测试数据表明，在普通的硬件上， XDP 可以 dop 大概 2600w packets per cpu.

一个网络包的处理流程大致如下:

网络包到达网卡
从 NIC queue 拷贝到内存(DMA-backed ring buffer)中
网卡驱动使用 NAPI look 触发 soft IRQs
per cpu 特定线程处理网络包
分配 socket_buffer(sk_buffer), 作为网络包的基本数据结构
kernel 填充 metadata, clone sk_buffer 并且交给上层网络处理层
IP layer 做校验, netfilter hook 处理
如果 netfilter 未 drop 此包,交给更上层网络层处理
….
最终数据被 copy 到 userspace (recv,read,poll等网络调用获取)

其中, XDP hook 在数据到达 NIC RX queue 之后即触发(上面第二步之后).而 iptables 等的处理(上面第八步之后)非常靠后, 需要分配大量资源来处理网络包.

XDP 程序 attch 到一个网卡的时候，有如下三种模式:

Native XDP: 网卡驱动支持 XDP, 性能比较高
Offloaded XDP: 网卡直接加载 XDP 程序，处理过程中不需要CPU参与。这个也需要网卡支持
Generic XDP: 最通用的模式，加载到内核中作为正常网络路径的一部分

插入的 ebpf 程序可以修改 packet data, 当程序返回时，可以决定这个 packet 后续的处理路径:

XDP_PASS: 继续按原有路径处理
XDP_DROP: 丢弃.这个可以用来在早期处理DOS攻击，userspace的程序可以分析网络pattern并且不断更新处理策略。性能与易用性兼得。
XDP_ABORTED: 丢弃并抛出异常
XDP_TX：返回到收到这个 packet 的 NIC 上
XDP_REDIRECT: 重定向到另一个NIC或者到 user space 的 socket (AF_XDP address family，绕过了正常的网络栈）

Python 示例程序

这个示例程序将发往 port 7999的包改为 7998

main.py

#!/usr/bin/env python3

from bcc import BPF
import time

device = "lo"
b = BPF(src_file="filter.c")
fn = b.load_func("udpfilter", BPF.XDP)
b.attach_xdp(device, fn, 0)

try:
 b.trace_print()
except KeyboardInterrupt:
 pass

b.remove_xdp(device, 0)

说明:

python 文件用于加载 bpf 程序，真正的 bpf 程序实在 filter.c 中。
BPF 程序被 attch 到了 lookback 接口上
trace_print 打印出 bpf 程序处理过程中的输出
remove_xdp发生在程序退出时，用户从 lookback 接口上移除加载的 xdp 程序

filter.c:

#define KBUILD_MODNAME "filter"
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/in.h>
#include <linux/udp.h>

int udpfilter(struct xdp_md *ctx) {
 bpf_trace_printk("got a packet\n");
 void *data = (void *)(long)ctx->data;
 void *data_end = (void *)(long)ctx->data_end;
 struct ethhdr *eth = data;
 if ((void*)eth + sizeof(*eth) <= data_end) {
 struct iphdr *ip = data + sizeof(*eth);
 if ((void*)ip + sizeof(*ip) <= data_end) {
 if (ip->protocol == IPPROTO_UDP) {
 struct udphdr *udp = (void*)ip + sizeof(*ip);
 if ((void*)udp + sizeof(*udp) <= data_end) {
 if (udp->dest == ntohs(7999)) {
 bpf_trace_printk("udp port 7999\n");
 udp->dest = ntohs(7998);
 }
 }
 }
 }
 }
 return XDP_PASS;
}

说明:

xdp_md结构体中包含了 packet data
bpf_trace_printk 的输出会在 main.py 里的 trace_print 中反应出来
指针方式确保了我们时原地修改了 packet data

AF_XDP

上面提到了 AF_XDP，他可以让XDP 程序可以将一个 packet 重定向到 user space 的内存空间里.

有一个比较接近的案例是 AF_PACKET/DPDK, 他们是通过在kernel和userspace共享内存来提高性能。而AF_XDP直能绕过很多 kernel stack 的步骤, 用最快的方式将 packet 传到 userspace.另外，它也提供了一些 zero-copy等功能。

具体实现上来说，有一些比较独特的数据结构来的达成此目的。创建的时候，仍然是用 socket API, 使用 AF_XDP address family. 然后在 userspace的内存中创建一个叫 UMEM 的 array, 它是一块连续的内存空间，被分成相等的 frames ，每一个 frame 都可以用来存储一个 packet.

每个 frame 的 index 被叫做 descriptor, 程序创建一个叫 fill queue 的 circular buffer, 并通过 mmap 映射到 userspace. 之后程序可以要求 kernel 将一个 packet 放到一个指定的 frame中(将 frame 的 descriptor 放到 fill queue 中)

receive queue: 类似 fill Q 的创建和映射方式。当一个 packet 被放到一个 frame 之后，他的 descriptor 会被放到 receive queue 中，poll 这样的API就是 wait 的 receive queue.

上面是接收端的情况。发送端的情况类似。一个 transmit queue, 通过将 descriptor 放到 tranmit queue表示要发送，complete queue 用于存放已经发送完的 packet .

通过这个数据结构，就实现了userspace 和 kernel 的 zero-copy. UMEM 数组还可以被多个进程共享，fill queue 和 compeltion queue 只能有一个，但 receive queue 和 tranmit queue 每个进程都需要有自己的，

AF_XDP最终的目的就是让user space code 可以高效地处理 packet, 尽量少的 kernel overhead.

Linkerd系列1 - Linkerd2-proxy

hang.yan@hotmail.com (涯余) — Tue, 17 Nov 2020 18:48:42 +0800

ServiceMesh这块属于 k8s 的一个大热门，但据我所知，落地的并不是太多。看文章大概理解为 overhead 以及部署都比较重，对一般的企业来讲，要考虑的东西比较多，所以落地难度比较大。有的建议是说，先上 envoy，其他的先搁置，这也是个思路。envoy 轻量级一些，可以先作为一个 proxy 去体验一下 ServiceMesh 架构下的 proxy 设计。然后再逐步看看怎么引入 ServiceMesh.

另一个方面，Istio vs Linkerd 应该还没完全分出胜负，对于企业的选型来说，仍然是个难点。好处是，我们可以去对比二者在各个功能点上的设计思路差异，然后加深理解。在 ServiceMesh 的组件中，毫无疑问 proxy 是核心组件之一。linkderd 的 linkderd2-proxy 也是一个经过深思熟虑并且设计良好的组件，可以作为切入点研究下 linkderd 的整体设计。

语言选型

envoy 是 C++ 写的，而 linkderd2-proxy 是 Rust. 语言的选型不仅对于实现者来说很重要，对于用户来说也是。想一下 marathon 用的 scala 以及它的失败就知道了。为什么选 Rust, 这跟它最开始的目标有关

资源占用低。因为 ServiceMesh 场景下的 proxy, 经常是以 sidecar 方式挂载在业务组件的 Pod 里，所以一定不能有太多的资源占用。
延迟低。因为要转发所有的请求，不能有太多的 overhead.
安全。同上，因为要转发所有的请求，如果 proxy 本身有安全漏洞，那就影响太大了。

因为 linkderd2-proxy 主要的设计思路是简单，只定义为 ServiceMesh 场景，那么上面几个条件几乎都是硬性的，符合上面几个条件的语言基本上就只有 Rust了。因为上面几个条件意味着:

不能有GC. GC会带来 worst case tail latency。Go/Java不符合
不能太重了。JVM再经过调优也不符合。linkderd2-proxy第一版就是用 Scala 写的，被抛弃了。
有内存安全保障。C/C++不符合。历史经验表明，很多组件一大半的安全漏洞都是跟内存安全有关的。

自动协议检测及 mTLS

这点跟 envoy 的差别也比较大。envoy 的配置文件上来一看还是挺吓人的，虽然可维护性更好。而linkderd2-proxy的设计思路是尽可能的少配置，基本上能做到插入即用，不需要额外配置什么。

当 proxy 收到一个请求的时候，先做一下 protocol detection, 比如:

是一个 http 请求吗
是一个 TLS Client Hello 请求吗

如果是 TSL Client Hello 请求，查一下 SNI 的值，如果是此 proxy 注入的 app, 那么就转发过去。如果是其他未知的http或者tcp请求，proxy 会直接转发。

mTLS 是指双向的 TLS 检查。一般我们场景都是检查 Server的，比如浏览器。但是像这种 client 如果是有已知合集的话，可以做双向的检测。比如 ServiceMesh场景下， Proxy-Proxy 的流量就可以做 mTLS. linkderd2实现了自动的 mTLS, 程序无感知。

每个 proxy 都会收到 control panel 下发的证书，24小时轮替。proxy的时候用不用 mTLS，很大程度上也是 control-panel 来帮助决策，这里不过多涉及。

另外，在proxy-proxy的场景下，还可以将 HTTP/1.X 自动升级为 HTTP/2, 以利用其多路复用的能力。在 dest 端再自动降为 HTTP/1.X.

负载均衡算法

转发请求的时候，control panel协助找到 endpoints列表。那么需要 proxy 选定一种负载均衡算法转发。这其实是一个分布式的负载均衡场景了，因为每个proxy都是一个LB.与单个LB的场景相比，常用的算法可能效果不好或者计算起来太过复杂。比如最小负载或者轮询。而 linkderd2-proxy 提供了一种实测性能更优秀的算法:

Power of Two Choices: 简称为P2C, 转发时，随机从backend里选择两个实例，并选择其中负载最小的一个，然后转发。这种算法实现起来比较简单，而且实际效果也很好。有一种群体智慧的感觉。

至于如何计算实例的负载，使用的是EWMA: exponentially weighted moving averages。通过测算每个实例的一段时间内的RTT, 并且通过加权算法给予最近的数据更高的权重来判断每个实例哪个更快一些。

上图展示了单个LB场景下EWMA的实测数据，一般来说比Round Robin 和 Least Loaded 的更好

etcd 的 clock diff 问题

hang.yan@hotmail.com (涯余) — Tue, 17 Nov 2020 15:19:38 +0800

最近碰到一个客户问题，最初始的现象是一个resource的处理逻辑一直不生效，看 k8s apiserver 的日志如下:

这里面没有 call webhook 相关的日志。主要的错误有两类，一是超时，暂时不清楚为啥。另一类是 object conflict, 这个比较奇怪。因为一般 obejct conflict 不会这么普遍，而且一般 controller 都会对此种情况做特殊处理，会自动恢复。从这个日志中能看出来的问题不多，继续排查一下业务相关的 contrller看看线索:

也是大量的 object conflict,非常异常的场景。而且还有一个 invalid object。到这只能怀疑是不是 etcd 出问题了，因为正常的 controller/apiserver 逻辑不太会触发这么多的此类错误。看 etcd 的日志:

大量的 clock diff 日志，日志意思应该是有一台节点的时间不同步。盲猜可能会导致数据存储的异常，修复时间问题后重启了 apiserver以及相应的 contorller 之后问题修复。看官方提到的 issue 里: Is there any other side effects when the system clock differs on each node, 只说了会影响设置有 TTL 的 object，目前看起来影响远远大于这个。

这个问题的警示是，ETCD的作用太核心了，基于 Kubernetes 的容器平台在监控层面应该尽可能收集多的 etcd 的 metrics 信息，以供管理员决策和提供告警。如果日志不好收集，apiserver 的错误码应该也能提供不少信息。

另一方面，NTP等服务应该作为默认部署的组件，以确保 master 节点在进行调整，维护，扩容或者新增 master 节点的时候，保证时间同步。而不是一次性地校准一次就不管了。

笔记: Postgresql里的事务实现

hang.yan@hotmail.com (涯余) — Tue, 27 Oct 2020 15:33:02 +0800

虽然日常工作需要涉及到数据库的底层部分并不多，但Postgresql作为一个数据库实现的范本是很值得研究的。可以通过它的实现来探索很多通用的数据库设计以及系统设计的理念。本文主要关注于事物设计方面。

MVCC

pg底层使用MVCC，修改数据时会直接创建新版本，而不是直接修改旧数据。这部分有一点需要注意的是在pg中，所有的语句都是在事物中执行的，不管是不是明确地用了BEGIN/COMMIT。

Transactions, tuples, and snapshots

先看一下 Transaction 的主要数据结构:

typedef struct PGXACT
{
 TransactionId xid; /* id of top-level transaction currently being
 * executed by this proc, if running and XID
 * is assigned; else InvalidTransactionId */

 TransactionId xmin; /* minimal running XID as it was when we were
 * starting our xact, excluding LAZY VACUUM:
 * vacuum must not remove tuples deleted by
 * xid >= xmin ! */

 ...
} PGXACT;

事物以xid作为标识.pg针对它做了很多优化，仅在真正开始写数据的时候才分配xid,如果是只读的事物就完全不分配。 xmin表示当这个事物开始的时候仍然处在运行中的事物列表中最小的那个xid

表中的 record，pg中称之为tuples.下面是 tuples 相关的一些数据结构:

typedef struct HeapTupleData
{
 uint32 t_len; /* length of *t_data */
 ItemPointerData t_self; /* SelfItemPointer */
 Oid t_tableOid; /* table the tuple came from */
 HeapTupleHeader t_data; /* -> tuple header and data */
} HeapTupleData;

/* referenced by HeapTupleData */
struct HeapTupleHeaderData
{
 HeapTupleFields t_heap;

 ...
}
/* referenced by HeapTupleHeaderData */
typedef struct HeapTupleFields
{
 TransactionId t_xmin; /* inserting xact ID */
 TransactionId t_xmax; /* deleting or locking xact ID */

 ...
} HeapTupleFields;

上面的 HeapTupleFields 里面也记录了如事物一样的xmin之类的字段。Tuples 通过这种方式也记录了与自身相关联的事物信息。xmin是tuple数据第一次对外可见，就是执行插入操作的事物。xmax是tuple数据最后一次对外可见的事物id,也就是指删除这个tuple的操作。下面的图示会更清楚些:

最终，我们来看看 Snapshot 的数据结构:

typedef struct SnapshotData
{
 /*
 * The remaining fields are used only for MVCC snapshots, and are normally
 * just zeroes in special snapshots. (But xmin and xmax are used
 * specially by HeapTupleSatisfiesDirty.)
 *
 * An MVCC snapshot can never see the effects of XIDs >= xmax. It can see
 * the effects of all older XIDs except those listed in the snapshot. xmin
 * is stored as an optimization to avoid needing to search the XID arrays
 * for most tuples.
 */
 TransactionId xmin; /* all XID < xmin are visible to me */
 TransactionId xmax; /* all XID >= xmax are invisible to me */

 /*
 * For normal MVCC snapshot this contains the all xact IDs that are in
 * progress, unless the snapshot was taken during recovery in which case
 * it's empty. For historic MVCC snapshots, the meaning is inverted, i.e.
 * it contains *committed* transactions between xmin and xmax.
 *
 * note: all ids in xip[] satisfy xmin <= xip[i] < xmax
 */
 TransactionId *xip;
 uint32 xcnt; /* # of xact ids in xip[] */

 ...
}

这里的 xmin 跟事物的 xmin 计算方法类似。当一个 snapshot 被创建的时候，xid是正在运行的事物的最小的xid.xid < xmin 的事物创建的tuples对于此 snapshot 都是可见的。

xmax等于最后提交的一个事物的xid+1.xid >= xmax 的事物所做的修改对于对于这个 snapshot 都是不可见的。 xip 是snapshot创建时所有正在运行的事物的id列表。一些比xmin大的xid可能在snapshot创建时已经commited,所以只靠xmin来判断也不靠谱。

事物处理

当一个事物开始执行语句时，会触发生成 snapshot 的操作:

static void
exec_simple_query(const char *query_string)
{
 ...

 /*
 * Set up a snapshot if parse analysis/planning will need one.
 */
 if (analyze_requires_snapshot(parsetree))
 {
 PushActiveSnapshot(GetTransactionSnapshot());
 snapshot_set = true;
 }

 ...
}

Snapshot
GetSnapshotData(Snapshot snapshot)
{
 /* xmax is always latestCompletedXid + 1 */
 xmax = ShmemVariableCache->latestCompletedXid;
 Assert(TransactionIdIsNormal(xmax));
 TransactionIdAdvance(xmax);

 ...

 snapshot->xmax = xmax;
}

上面GetSnapshotData 里的代码设置了xmax的值。下面的片段设置了xmin 和 xip:

/*
 * Spin over procArray checking xid, xmin, and subxids. The goal is
 * to gather all active xids, find the lowest xmin, and try to record
 * subxids.
 */
for (index = 0; index < numProcs; index++)
{
 volatile PGXACT *pgxact = &allPgXact[pgprocno];
 TransactionId xid;
 xid = pgxact->xmin; /* fetch just once */

 /*
 * If the transaction has no XID assigned, we can skip it; it
 * won't have sub-XIDs either. If the XID is >= xmax, we can also
 * skip it; such transactions will be treated as running anyway
 * (and any sub-XIDs will also be >= xmax).
 */
 if (!TransactionIdIsNormal(xid)
 || !NormalTransactionIdPrecedes(xid, xmax))
 continue;

 if (NormalTransactionIdPrecedes(xid, xmin))
 xmin = xid;

 /* Add XID to snapshot. */
 snapshot->xip[count++] = xid;

 ...
}

当事务提交的时候:

static void
CommitTransaction(void)
{
 ...

 /*
 * We need to mark our XIDs as committed in pg_xact. This is where we
 * durably commit.
 */
 latestXid = RecordTransactionCommit();

 /*
 * Let others know about no transaction in progress by me. Note that this
 * must be done _before_ releasing locks we hold and _after_
 * RecordTransactionCommit.
 */
 ProcArrayEndTransaction(MyProc, latestXid);

 ...
}
static TransactionId
RecordTransactionCommit(void)
{
 bool markXidCommitted = TransactionIdIsValid(xid);

 /*
 * If we haven't been assigned an XID yet, we neither can, nor do we want
 * to write a COMMIT record.
 */
 if (!markXidCommitted)
 {
 ...
 } else {
 XactLogCommitRecord(xactStopTimestamp,
 nchildren, children, nrels, rels,
 nmsgs, invalMessages,
 RelcacheInitFileInval, forceSyncCommit,
 MyXactFlags,
 InvalidTransactionId /* plain commit */ );

 ....
 }

 if ((wrote_xlog && markXidCommitted &&
 synchronous_commit > SYNCHRONOUS_COMMIT_OFF) ||
 forceSyncCommit || nrels > 0)
 {
 XLogFlush(XactLastRecEnd);

 /*
 * Now we may update the CLOG, if we wrote a COMMIT record above
 */
 if (markXidCommitted)
 TransactionIdCommitTree(xid, nchildren, children);
 }

 ...
}

这里的 xlog 是指 WAL.如果发生故障，pg可以通过WAL里面的内容来恢复数据。先写WAL，然后TranscationIdCommitTree再把事务的状态更新到clog中(commit log).如果一个事物没有xid,比如只读的，WAL和clog就没必要写入了。如果一个事物被中止，状态仍然会被同步到WAL和clog中，但数据不会被立即写入到磁盘中。因为即使crash了，也不会丢失信息。

当事物完成后，需要通知整个系统:

void
ProcArrayEndTransaction(PGPROC *proc, TransactionId latestXid)
{
 /*
 * We must lock ProcArrayLock while clearing our advertised XID, so
 * that we do not exit the set of "running" transactions while someone
 * else is taking a snapshot. See discussion in
 * src/backend/access/transam/README.
 */
 if (LWLockConditionalAcquire(ProcArrayLock, LW_EXCLUSIVE))
 {
 ProcArrayEndTransactionInternal(proc, pgxact, latestXid);
 LWLockRelease(ProcArrayLock);
 }

 ...
}

static inline void
ProcArrayEndTransactionInternal(PGPROC *proc, PGXACT *pgxact,
 TransactionId latestXid)
{
 ...

 /* Also advance global latestCompletedXid while holding the lock */
 if (TransactionIdPrecedes(ShmemVariableCache->latestCompletedXid,
 latestXid))
 ShmemVariableCache->latestCompletedXid = latestXid;
}

这里我们通过锁的方式独占地更新 latestCompletedXid的值，snapshot 创建的需要获取其值以设置 xmax.

关于 OAM 与云原生应用

hang.yan@hotmail.com (涯余) — Thu, 22 Oct 2020 11:34:13 +0800

OAM 是指阿里开源的一个应用模型，主要是云原生场景。年初的时候出来到现在，断断续续地了解过一些，之前一直没有特别想清楚，其实现在也是，但多多少少有一点点感悟，在这里记录一下.

云原生应用的现状

这里主要就是说围绕 kubernetes 生态的应用现状，基本上就是一团糟。没有标准，没有好的开源产品，没有社区来推动这个事情。先看看目前有啥:

Helm: 适合作为rpm/apt类似的东西，不适合直接给 end user 用
Application CRD: 社区不活跃，结构定义也不好
Operator: 过于复杂，目前仅有的统一规范是 ocp 弄的 operator framework. 尚未推广开来
其他林林总总的各种 ad-hoc 方案

这就导致云厂商要么是完全自己做一套新的应用模型，要么是用上面这一类现成的，但功能受限，扩展不易。且用户需要有一定的前置知识才能用好。

OAM 的主要优点

目前看来其最主要的优点是角色分离。Kubernetes YAML 的一个主要问题就是，它是一个大而全的 cofig 方案，不宜手写，只适合运维方向。如果想要做成用户友好的模型，OAM提供了一种可能性: 将大的 config 按角色分拆开，开发人员写一部分，运维人员写一部分，各自只关心各自的部分，最终再合并成一个整体的 config. 细节问题比如具体分成几个角色，谁来合并，可以再迭代改进。但这个分离的设计可以认为是走在一个正确的方向上。

其他的几个重要的方面有：

跨平台性。从设计上来讲，一开始设计成跨平台的思路当然是对的。但实际上可能还是90%以上的人主要是用在 k8s 上，所以 spec 设计时比较贴近于 k8s 的设计。其他平台的实现估计会花不少时间，这也是导致目前没有其他平台实现的主要原因
插件系统。OAM 提供的 traits 能力，可以理解为对应用的一个插件系统。之前国内有厂商做过类似的东西，是一个非常好的尝试。以插件形式给应用附加能力，是一种非常自然和方便的用户体验，traits可以用来提供类似的能力。

用户体验

即使做了职责分离，OAM 看起来仍然是非常难以直接 edit 的东西。这也是之前我一直比较纠结的一个点。因为它更像一个面向开发者的 spec, 而不是一个对 end user 的产品。我们如何让用户方便地使用这个功能呢，有下面几种可能:

纯 UI 封装。这里需要 UI 设计的比较好，能够隐藏比较多的细节，不要暴露太多的底层名词给用户，不然用户就要去理解 OAM 是个什么东西了。而我们理想的形式就是让用户不去学习新概念。一个可能的点就是我上面说的，把 traits 叫做 插件等等。这里需要考虑的一个点是API怎么设计，因为一般UI/API都是必须的产品。如果直接把 OAM 用 API 暴露出来也不怎么友好，这就涉及到下面的第二点
我们能否再设计一层 spec, 简单一点的，能提供便捷的API,UI也方便？这个诱惑力比较大，但其实又回到了远点，因为又回到了老的大的 config 上? 假设我们想做的更简单一些，那势必又无法全面覆盖 OAM 的能力。似乎唯一的可能性就是，我们换了一种 spec 格式，让用户更容易理解，但可以和 OAM 一一对应。

因为之前有厂商放出了一些 OAM UI 的截图，比如:

这基本上是照本宣科的一个实现，并没怎么考虑用户体验。可以说设计一个好的UI的难度不低于设计这个spec, 设计一个简易的 spec 也是.

Compose

Compose 社区也在做类似的事情，而且有很多地方是很像的，比如 spec 与实现的分离。 spec 里分为 core/extension等几个部分，不同实现可以自己做一些调整。Compose 有一个很大的优点就是，到目前为止，它一直是用户体验最好的一个，YAML格式易于理解，易于书写，对API/UI也很友好。所以即使现在用的人不算太多，但仍然是一个非常有参考价值的应用模型。甚至，我们可以把 compose 架在 OAM 之上，这也是一种可能性。

应用 Catalog

在可预见的一段时间之内，即使加了 OAM 之后，多种应用模型仍会是一个并存的场景，容器云厂商也需要尽可能多地给用户选择，尤其是在流水线方面。有的用户可能会用 chart 来部署 redis, 用 OAM 来部署自己的一些应用，用 Operator 来部署一个 kafka. 所以我们需要有这么一个统一入口，给用户以选择。流水线也需要保持一种可扩展性，让用户自己选择打包和 deploy 的格式. ocp 目前就有类似的产品设计:

总之，前景未明，OAM 看起来很有希望。不过工业界什么东西会流行，牵扯的因素比较多，大公司，媒体，开发人员等等。不管结果怎么样，平台的责任就是尽量少发明新概念，尽量提供多的选择。

ARM指针的一些安全功能

hang.yan@hotmail.com (涯余) — Mon, 19 Oct 2020 13:12:59 +0800

伴随着 ARM 平台的越来越普及，Linux 内核对其的支持也逐渐丰富。而且 ARM 的设计也有很多独特的优点，本文将介绍在 ARM 平台关于指针操作的一些安全方面的设计。

Pointer Authentication

很多攻击都是通过骇客设计的不安全指针进行的。比如 buffer-overflow 和 return-oriented programming, 都是通过在返回地址放置一个指针来进行的。内核已经针对这个问题做了很多改善，ARM 提供了 pointer authentication 来检测和拒绝这种插入的非法指针。

简单来说，就是在指针上附加一个签名，要想使用一个指针，先得签名验证通过。如果是外部的攻击者，它没法伪造这种签名，那么自己就不能制造指针来进行攻击了。

目前一般指针都是64位，但一般都不是所有bit都是用了。ARM64的系统，如果是三级页表，那么只有低位的40bit用来存放地址，那么其他的bit就可以用来干其他事情。签名一般是通过以下几个参数确定:

pointer 本身
process context 里的一个 secret key, kernel生成这个肯定是攻击者无法获取到的
current stack pointer。防止签名过的pointer泄露被复用

使用的话，需要先重新计算一下签名，确保二者对的上，然后把签名部署的数据清理掉，这时候就是一个正常的指针了。不然的话，就认为其非法。

Memory Tagging

Memory Tagging的做法与Pointer Authentication类似，都是利用指针里未利用的 bits 去存储一些信息。Memory Tagging 是利用 4bit 的信息存储了一个 key, 同时在 pointer 指向的内存地址里也存储了同样的 key. 当对指针进行解引用操作时，需要对比 pointer 里的 key 与实际内存地址里的 key 是否一致。如果不一致将会报错。这个功能有以下用处：

被释放的内存可以修改其 key, 防止被二次引用
每个 stack frame 分配一个 key, 越界访问也会报错
野指针也能检测到
….

这些 keys 可以用应用层来管理，也可以用 CPU 来随机生成。当用应用层来管理的时候，可以提前检测出内存方便的 bug.

总结

上面两个功能是可以一起协同工作的，因为他们都分别占用了 pointer 里不用的一些 bits, 只要规划好分给各自的部分就好。如果 glibc 等相关部分的工作完善好，理论上应用层是不需要做任何改动就能享受到这些好处了。

Semantic Web

hang.yan@hotmail.com (涯余) — Sat, 17 Oct 2020 11:56:20 +0800

最近开始关注Semantic Web的原因是Abstract Wikipedia项目的发展．作为一个很老的互联网课题，大家的愿景都是很清楚的：想要一个语义更加清晰，更方便机器处理的互联网，然后构建一个真正的互联网．但是市场的行为总是与技术理想有很大偏差，想要用后期的技术来补救，其成功的概率是很低的．Abstract Wikipedia 的让人期待的地方在于，它成功的可能性更高，带来的改善也可能不止局限于Wikipedia.

先说什么是 Abstract Wikipedia, 首先目前维基百科的内容结构大家基本上也都了解:不同语言分别维护，体量差异巨大．从一个程序设计的结构来讲，这种模式是很糟糕的，因为它抽象的程度太低，大量的内容无法复用，造成的 interface 对很多用户不友好: 不同语言内容差别大，同步不及时，维护工作繁重等等．之前的低地苏格兰语被一个美国小哥勤奋地填充了大量的错误内容就是一例．

如何解决? 按程序设计的思路来看，需要分清数据和算法两部分，数据是什么，是语言无关的抽象知识，用抽象符号来表述知识．算法是什么？怎么来组织这些数据，让他们构成合理的语句．最后可能再需要一个Render层，将结果最终呈现给用户．这基本上就是一个MVC结构了．

Abstract Wikipedia就是想做这个事情.数据部分，由wikidata维护，大致如下所示的模式: 可以打开这个Hawaii State Public Library System的链接看下实际的数据是什么样子的．这部分的内容跟RDF的结构很像,可以预见的是，以后wikidata的内容越来越多，也能促进Semantic Web本身的发展．

算法部分，由wikilambda维护，这部分暂时还没有现成的实现，但是已经有初步的概要设计．一个完整的示例如下: 假设原始语句为:

San Francisco is the cultural, commercial, and financial center of Northern California. It is the fourth-most populous
city in California, after Los Angeles, San Diego and San Jose

我们想把这个语句专为通用的结构化内容,那么数据部分如下: (这部分数据完全可以用 RDF 表示出来) 注意上面的 Q62等，就代表着它们目前在wikidata中的链接.有了这些数据，那么我们可以通过一个简单的函数把它们拼接成一句英语: 这是个比较简单的示例，真实的情况肯定会比目前复杂一些．但是理论上都可以通过更丰富的数据和算法来组合出所有目前常用的句式．

对维基百科来说，这是一条看起来很有希望的路．期待的场景是人类的大部分的知识，都能通过这样的方式，以不同的语言展示给读者．当然，也不会局限于此．稍微展望一下，我们就可以发现它带来的变革几乎是无限的．我们能用它来做各种各样的事:

知识图谱．有了维基百科的数据，我们可以更方便地构建各种知识图谱
wikidata和wikilambda的内容可以以各种方式直接给其他系统集成，提供各种编程语言的 binding.
机器学习系统以及学术界可以利用维基百科的内容做各种数据研究
….

期望这个美好的愿景能实现吧．

Kubernetes Webhook Cert 方案

hang.yan@hotmail.com (涯余) — Fri, 16 Oct 2020 16:53:17 +0800

Kubernetes 里的 Cert 数据是挺零散的一块，而 Webhook 中又强制要求必须是 HTTPS, 在实际使用的过程中尝试了几种方案，发现各有优劣，也都有不少问题．下面将分别详述一下:

Cert Manager

Cert Manager 可能是最成熟的方案了，使用 Let’s Encrypt 来签发证书．只需要配置好响应的 CR (Issuer, Cert…等), Cert Manager会自动生成证书，比较方便．

缺点也很多，首先是引入了一个比较重的依赖，Cert Manager本身的稳定性也是一个问题．实际用的时候经常发现它的 apiservice Not Ready等问题．假设本来环境中已经有 Cert Manager,那么直接用它是一个比较好的选项，否则并不建议使用．

脚本 + CSR Resource

这种方式是利用 Kubernetes 内置的 CSR 资源来管理证书，最终 caBundle 就可以直接用　Kubernetes 集群自带的 cert 数据，但 Server CRT 和 Server KEY 需要自己用脚本生成．Github 上有现成的项目演示了这种用法: k8s-webhook-cert-manager.

其基本使用方式如下:

./generate_certificate.sh --service ${WEBHOOK_SERVICE_NAME} --webhook
${WEBHOOK_NAME} --secret ${SECRET_NAME} --namespace ${WEBHOOK_NAMESPACE}

我们需要提供SVC的名字和NS以生成cert数据．脚本也可以根據自己需求進行適當裁剪.当数据生成之后，使用的 CSR 资源我们还可以通过集群看到(一段时间后会被GC):

[core@bastion ~]$ kubectl get csr
NAME AGE REQUESTOR CONDITION
csr-w6ldh 5m56s system:node:master3 Approved,Issued

需要注意的细节如下:

生成证书默认的有效时间是一年，可以通过 controller-manager 的参数调节
webhook caBundle　里的数据默认可以从 POD 挂在的 default token里获取到 (/run/secrets/kubernetes.io/serviceaccount), 也可以从系统的一个 ConfigMap 里读取到　(kubectl get cm -n kube-system extension-apiserver-authentication)

这种方式是比较忙简单的，而且利用了原生 k8s 的一些功能，是比较理想的一些形式．它的不足之处如下:

一般需要用一个 initContainer 之类的方式来提前生成 cert 数据，并且在webhook主程序中手工读取数据，整体流程比较原始，容易出错．
多实例的 webhook 程序其 initContainer里脚本的数据冲突也是个问题，需要单独处理．

另外，对原生 k8s 来说，这是一种比较理想的形式，但是对于一些特定的发行版来说，可能会遇到其他问题，下面举两个例子

AWS

AWS的特殊之处在于，它的 extension-apiserver-authentication 与Pod里挂载的默认的 CA 数据不是一个．所以在 AWS 中，caBundle的数据只能从默认token里读取．这样的问题主要原因在于缺乏明确的文档说明，一旦默认其一致，难以DEBUG.

OpenShift

OpenShift的默认token里的CA数据是一个证书链，而且如果用上述方式生成，由CSR请求到的 CERT 数据也无法被kube-apiserver认证．目前此问题暂无特别好的方法，只能通过下面使用自签名的证书的方式绕开．

自签名证书

这种方式是完全用 cli 程序生成自签名的证书，不使用k8s CSR的方式．好处就是能避开像上面的依赖于标准 k8s 的行为，防止未知的错误．如何部署自己的webhook admission这篇文章讲了大致的流程，将其脚本化并且做成镜像应该也比较简单．

它使用的工具并不是 openssl, 而是新的工具．我觉得一个原因就是 openssl 应该算是常用软件里使用非常不友好的一个工具了，基本上都不知道怎么用，网上也没多少好的介绍文章．新的工具至少能改善一下这方面的体验．

VSCode 和 Emacs

hang.yan@hotmail.com (涯余) — Sun, 27 Sep 2020 12:28:55 +0800

除了 Emacs 和 Vim 之外的 Editor 战争，现在看起来 VSCode 已经赢了。

先不说现存的一些 Editor 的现状和对比，我们直接猜想一下一个比较完美的 editor 应该是什么样子的

modern look. 就是好看，让人想用.
易上手: 不需要学太多才能才能用好
易扩展: 就是 plugin 多到满足常用需求
跨平台，方便配置

这几点就差不多了，能做到这几点基本上就能做到广受欢迎了。下面一个一个细拆开讲讲.

决定特性

Modern Look

这点最成功的案例就是 JetBrains 的一系列产品，单是其 Darcula theme 就让多少人愿意试一试。Atom 和 VSCode, LightTable， Sublime 做的也都不错， Vim 和 Emacs 做的不行，太古老了。虽然可以配置好的好看，但默认配置太劝退了。

易上手

这点 vim 和 Emacs 还是做的最差，虽然最终效率最高，但学习曲线太漫长了。VSCode 和 Atom 比较像，做的都不错。

易扩展

但从扩展性上来讲，Atom/VSCode/Vim/Emacs都差不多，该有的插件都有，安装也不难。不过前两个明显使用起来更方便些，是真正的易扩展,直接在 UI上就可以点点安装 plugin。也有方便的介绍和使用说明。LightTable 插件太少，半死不活的。Sublime 插件也不算多。

跨平台

跨平台的能力不难做，前面提到的几个都能做到。难的是尽量保证一致性的体验和性能。这里面 VSCode 做的最好， Atom 是在哪个平台性能都不咋样.Emacs在Linux下性能最好，Mac下 UI 效果一般, Windows 下配置着更麻烦。Vim 主要是 Terminal 领域了。

综合来看，VSCode 还是当之无愧的最受欢迎的 Editor, 每个方面都做的不错。Atom 算是因为性能等原因被击败。LightTable 差不多死了， Sublime 也是被老大老二打架的时候弄死了(自己还收费), Vim 和 Emacs 比较特殊，因为本身历史比较久，不可替代性比较强，属于不在一个竞争层面上的。因为单从 Editor 的设计来讲，VSCode 之类的根本没法和 Vim/Emacs 比，前者是属于产品层面的胜利，不是属于技术方面的胜利。

Emacs 比较特殊一点，我自己一直在用。社区最近也一直在讨论如何让其现代化一点，能吸引到更多用户，其中的策略就是内置一个比较好的 Theme, 多加一些 intro 或者默认比较好的配置之类的，不出上面提到的几个关键点。这点本身也算是 Emacs 被开源社区的模式坑了，Fork 的版本在那瞎改不往回 contribute, 一部分人不希望改变 Emacs 的现状等等。但 Emacs 的存在的一个很重要的意义仍然在于告诉我们 ,VSCode 仍然是有巨大缺陷的产品，我们离最终的完美的 Editor 还差的很远。后面肯定会有更优秀的产品出现。不只好用，还厉害。

eBPF系列1 - 介绍

hang.yan@hotmail.com (涯余) — Tue, 22 Sep 2020 22:39:41 +0800

一直想写(整理)一些关于 eBPF 的文章。在我眼中，它是 未来技术 之一。最近零零碎碎看了一些，感觉信息太多，怕是永远也看不完，索性开始一遍看一边记笔记吧。这一篇是介绍。

eBPF 是什么

先介绍下 eBPF 的前身: BPF -> Berkeley Packet Filter. 看名字就知道，主要是用于网络 packet 的过滤用的。过滤程序是运行于基于寄存器的虚拟机之上．　BPF 展示了在内核中运行用户程序的良好开端．但它的缺点也很明显，虚拟机的设计以及指令集都比较落后，跟不上现代处理器的发展(尤其是多核方面)，也无法利用现在的 64bit 寄存器．

eBPF extend 了 BPF, 将其机制大大地泛化，不止用于网络数据包的处理，而是可以 hook 在任意的系统调用上, 这样它就变成了一个几乎具有无限功能的系统。在硬件上，它跟现代的处理器的指令集更为贴近,并且能充分利用现在数量众多的 64bit 寄存器．这样就使 JIT 编译器的产生变为了可能，大大提升了性能.

在没有　eBPF 只之前，如果我们想对内核行为进行修改，基本上就是往内核里添加代码或者通过 kernel modules 进行．这二者的门槛都不低，所以影响有限．eBPF 提供了一种新的可能性，通过普通的编程方式，去控制内核的行为，同时保证了高性能．这就是它之所以独特和具有极大潜力的主要原因．

程序校验

当 eBPF 程序被加载进内核之后，要先做一些程序校验工作, 比如:

权限是否具备。加载 eBPF 的程序是否有权限加载.一般来讲，程序必须得是 root 用户运行的或者有 CAP_BPF 权限才能加载。如果开启了 unprivileged eBPF, 那么普通程序也可以加载一些功能受限的 eBPF 程序(比如不允许指针操作)。
eBPF 程序是否有可能 crash
在每次指令执行前后都需要校验虚拟机的状态，保证寄存器和栈的状态都是有效的. 校验器不会检查程序的每条路径，它能够知道程序的当前状态是否是已经检查过的程序的子集。由于前面的所有路径都必须是有效的(否则程序会加载失败)，当前的路径也必须是有效的，因此允许验证器“修剪”当前分支并跳过其模拟阶段。
不能访问未初始化的变量或者越界访问
程序大小有 limit.
复杂程度有 limit. 检查程序会估算所有的执行路径以评估其复杂程度。
eBPF 是否会无法终止运行(比如 loop forever)
不同类型的 eBPF 程序只能访问特定类型的系统调用

之所以有这么多检查，就是因为它能做的事情太多了，也太有可能造成破坏了，所以在校验阶段就尽量多做一些。

数据结构

bpf()

使用bpf()系统调用和BPF_PROG_LOAD命令加载程序。该系统调用的原型为：

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

其中 attr 用于在 user space 和 kernel 之间传递数据 , size 是 bpf_attr 的大小.

eBPF MAP

上述的 cmd 支持如下类型:

BPF_MAP_CREATE
Create a map and return a file descriptor that refers to the
map. The close-on-exec file descriptor flag (see fcntl(2)) is
automatically enabled for the new file descriptor.
BPF_MAP_LOOKUP_ELEM
Look up an element by key in a specified map and return its
value.
BPF_MAP_UPDATE_ELEM
Create or update an element (key/value pair) in a specified
map.
BPF_MAP_DELETE_ELEM
Look up and delete an element by key in a specified map.
BPF_MAP_GET_NEXT_KEY
Look up an element by key in a specified map and return the
key of the next element.
BPF_PROG_LOAD
Verify and load an eBPF program, returning a new file descrip‐
tor associated with the program. The close-on-exec file
descriptor flag (see fcntl(2)) is automatically enabled for
the new file descriptor.

attr 主要是 eBPF MAP. MAP 是 eBPF 程序中最为重要的数据结构，依赖于它来存取状态。

使用bpf()系统调用创建和管理map。当成功创建一个map后，会返回与该map关联的文件描述符。关闭相应的文件描述符的同时会销毁map。每个map定义了4个值：类型，元素最大数目，数值的字节大小，以及key的字节大小。eBPF提供了不同的map类型，不同类型的map提供了不同的特性。

BPF_MAP_TYPE_HASH: a hash table
BPF_MAP_TYPE_ARRAY: an array map, optimized for fast lookup speeds, often used for counters
BPF_MAP_TYPE_PROG_ARRAY: an array of file descriptors corresponding to eBPF programs; used to implement jump tables and sub-programs to handle specific packet protocols
BPF_MAP_TYPE_PERCPU_ARRAY: a per-CPU array, used to implement histograms of latency
BPF_MAP_TYPE_PERF_EVENT_ARRAY: stores pointers to struct perf_event, used to read and store perf event counters
BPF_MAP_TYPE_CGROUP_ARRAY: stores pointers to control groups
BPF_MAP_TYPE_PERCPU_HASH: a per-CPU hash table
BPF_MAP_TYPE_LRU_HASH: a hash table that only retains the most recently used items
BPF_MAP_TYPE_LRU_PERCPU_HASH: a per-CPU hash table that only retains the most recently used items
BPF_MAP_TYPE_LPM_TRIE: a longest-prefix match trie, good for matching IP addresses to a range
BPF_MAP_TYPE_STACK_TRACE: stores stack traces
BPF_MAP_TYPE_ARRAY_OF_MAPS: a map-in-map data structure
BPF_MAP_TYPE_HASH_OF_MAPS: a map-in-map data structure
BPF_MAP_TYPE_DEVICE_MAP: for storing and looking up network device references
BPF_MAP_TYPE_SOCKET_MAP: stores and looks up sockets and allows socket redirection with BPF helper functions

eBPF 程序类型

使用BPF_PROG_LOAD加载的程序类型确定了四件事：附加的程序的位置，验证器允许调用的内核辅助函数，是否可以直接访问网络数据报文，以及传递给程序的第一个参数对象的类型。实际上，程序类型本质上定义了一个API。创建新的程序类型甚至纯粹是为了区分不同的可调用函数列表(例如，BPF_PROG_TYPE_CGROUP_SKB 和BPF_PROG_TYPE_SOCKET_FILTER)。目前内核支持的程序类型有:

BPF_PROG_TYPE_SOCKET_FILTER: a network packet filter
BPF_PROG_TYPE_KPROBE: determine whether a kprobe should fire or not
BPF_PROG_TYPE_SCHED_CLS: a network traffic-control classifier
BPF_PROG_TYPE_SCHED_ACT: a network traffic-control action
BPF_PROG_TYPE_TRACEPOINT: determine whether a tracepoint should fire or not
BPF_PROG_TYPE_XDP: a network packet filter run from the device-driver receive path
BPF_PROG_TYPE_PERF_EVENT: determine whether a perf event handler should fire or not
BPF_PROG_TYPE_CGROUP_SKB: a network packet filter for control groups
BPF_PROG_TYPE_CGROUP_SOCK: a network packet filter for control groups that is allowed to modify socket options
BPF_PROG_TYPE_LWT_*: a network packet filter for lightweight tunnels
BPF_PROG_TYPE_SOCK_OPS: a program for setting socket parameters
BPF_PROG_TYPE_SK_SKB: a network packet filter for forwarding packets between sockets
BPF_PROG_CGROUP_DEVICE: determine if a device operation should be permitted or not

如何开发 eBPF 程序

通过 llvm 等工具，可以使用各种高级语言的 package 或者 binding 来开发 eBPF 程序.

bcc

bpftrace

language library

Hugo 的优点

hang.yan@hotmail.com (涯余) — Sat, 12 Sep 2020 12:30:28 +0800

经历了 N 次在各个不同的环境里初始化 Hexo 的环境失败之后，我终于换了 Hugo.

从 Jekyll -> Hexo -> Hugo 我算是发现了，依赖不好处理的平台根本不适合做 static blog generator.想在一个新的环境里部署好一个这样的软件，而且你又没有这个语言的比较多的经验的时候，大量的时间会被浪费在配置环境上。这时候，像 hugo 这样的 static binary 就是一个 killer feature, 我根本不用看它有什么优缺点，就直接切换过来了。

事实上也是，从互联网的内容检索上来看，大部分的迁移路线基本上就是 Jekyll,Hexo -> Hugo, 基本上没有反着来的。先不说 Golang 语言设计的怎么样，但说能如此方便地 build 出来一个 cross-platform 的 static binary, 简直是造福程序员。

曾经，我以为 Hexo 的 theme 与 content 分离已经很优秀了。没想到它还是个垃圾。

统信 UOS 究竟咋样

hang.yan@hotmail.com (涯余) — Thu, 10 Sep 2020 16:01:54 +0000

统信 UOS 是今年国产化浪潮中比较出风头的一个做国产操作系统的公司。这几天换掉了我的 Manjaro 装上了 UOS 体验了一下。总体来说，可以打七八十分吧。

单说这个分数可能不是很好度量它究竟是个什么水平。可以横向对比一下，分两个方面。一个是底座上，linux 发行版里, Deepin 团队做的很出色，现在基本上是排名第十左右的发行版(按流行程度)。UOS 是基于 Deepin 改的，底座上有了不错的保证。

再跟国内这一众国产操作系统比的话，那简直是碾压。红旗之类的不用说，之前中国软件的麒麟，基于 Ubuntu 来改的( Deepin 的底座也是Ubuntu), 做了这么多年，了解 Linux 的基本上没啥好感，还不如 Ubuntu。因为国产操作系统向来上先往政企方面推，像麒麟这种大概率是拿到之后用户基本上就闲置不用了，继续用 Windows了。UOS 终于让人看到一点希望，至少，看起来让人有想尝试一直用用的念头了。

国产操作系统怎么做的问题，其实就是 Linux 桌面版怎么做的问题，虽然我们也自有国情在此。从操作系统内核来讲， Linux 比 Windows/MAC 并不差，问题全出在软件生态上。主要原因有以下几个:

非商业模式。只要商业公司才能做出像 Adobe / Oracle 这样的软件。有赚钱的目标，合理的分工及 KPI, 再卖出去软件形成一个正向循环。Linux 生态里有点像现在各家的 Andriod, 还更差，基本上连个统一付钱买软件的地方都没有，再说 Linux 用户普遍还没有养成这样的习惯
开发者太容易分散人力开发类似的项目了。大家对项目有了争议，可以立马基于当前版本重新立一个新项目，分开开发。这就导致现在 Linux 已经有了几百个发行版，N 个桌面系统，每一类软件都有 N 个不同的产品。除了个别的项目之外，大部分都不好用。
没有领导，群龙无首。跟上面说的两个问题相关。内核发展的好，是因为有强有力的领导。但桌面系统，基本上就是百家争鸣，谁也不服谁

这些问题杂糅起来，就形成了一个恶性循环。 Linux 桌面不好用 -> 用的人少 -> Linux 桌面发展缓慢，程序员各自魔改 -> 用的人更少。所以导致现在的局面就是，你想要一个方便使用的 Linux 桌面，如果没有一点编程背景，总会有一天栽在一个无法解决的最基本的硬件问题上。蓝牙坏了，网络连不上，显示器连不上，显卡配置不好等等在 MAC/WIN 上很少碰到的问题上。

假设硬件的问题解决了，那么更难的来了: 软件。国内因为更加封闭的互联网生态这个问题更加严重。让用户苹果/Wechat 二选一，大部分人会放弃苹果，Linux 也类似，没有微信这些软件，没有正常用户会喜欢用 Linux。问题摆在这，那么国产操作系统怎么做的答案也就呼之欲出了:

一定要有一个内置了常见应用的应用商店，后期还要支持付费购买软件。
系统内置基本的常用应用
用户装上能适配所有的基本硬件: 显示器，网络，蓝牙，甚至打印机等等
界面好看

看起来就这么简单，做起来非常难，至少看起来麒麟一个也没做成。统信至少这几个方面都尝试了

跟大量国内软件厂商去适配软件。像微信这种腾讯自己不做的，用社区现有的开源方案(Windows兼容层)做好放到商店里。
比较可圈可点的就是做了一个内置的类似 MAC 的图库应用(应该是 Linux 平台第一个)
跟大量硬件厂商去一个一个适配，也做了打印机方面的适配。当然基于国产化的考虑也适配了国内基本上所有的芯片（龙芯等）
Deepin 本来界面就挺不错，基于它继续优化即可。

做到现在，当然问题还有，BUG 也不少，稳定性也有不少问题。但可以肯定的讲，统信走的路线非常对的，取得的成就也是国产操作系统里最大的一个了(用户桌面领域)。虽然说操作系统领域是最不可能被卡脖子的领域之一，但能取得这样的成绩，还是非常值得肯定的。对我个人来讲，完全愿意将其作为自己主要的日常使用环境了。

最后，还说说说不好的地方；

做了一个垃圾的内置浏览器。这东西完全不用自己做，直接基于 chromium/firefox 自己定制就行
Deepin 的一些老问题，N卡和外接显示器不兼容，这个没解决好。网络链接不稳定也是。
App Store 用起来稳定性比较差

希望继续努力吧。

Docker 私有 Registry 的镜像 GC 问题

hang.yan@hotmail.com (涯余) — Mon, 07 Sep 2020 18:13:47 +0000

需求

一个轻量级的 docker registry

方案讨论

Harbor 的功能丰富，但是过于重量级了，与其他平台集成并不方便。Portus 类似。这一类产品都比较侧重 UI 和认证，一般都带有数据库，与K8S 的集成也比较麻烦。最终看起来还是 registry 最合适，不过就是功能太简陋了。需要考虑的东西很多:

HTTPS
暴露方式 -> Ingress/NodePort. 最好的方式当然是 Ingress, 但虽然 registry 支持 SubPath, 但docker client 不支持。所以只能退而求其次用 NodePort. 对外地址的暴露只能设计 CR 来做了
GC -> 这块看起来都受限于 registry 本身的能力。它提供了命令行工具能手工清除 blob, 但其他的 metadata 没删完。导致做完 GC 还得重启下 registry. 同时还得保持 GC 时 readonly.

这里面最繁琐的就是 GC, 目前提供的工具非常的原始。harbor 集成了 gc 的功能，应该是在 admin 页面提供了按钮来手动触发。那么在 K8S + registry 的限定范围内应该怎么做，目前想好的流程是：

在 registry 的 deployment 里加一个 container 来处理 GC，这样的好处是可以共享配置，存储和 PID
gc container 和 registry container 共用同样的镜像，但 CMD 不一样
gc container 的 CMD 是一个 while 循环，用来周期性地跑 GC 命令
跑完 GC 之后，如果确实清理了一些 blob, 还需要重启 registry. 不然因为其他一些 metadata 没有清理，直接 push 和 pull 会出错。

这样就组成了一个低成本的可用的 GC 方案。缺点就是没法方便地将 registry 置为 readonly. 理论上来讲, gc 的周期设置长一点，问题不大.

遇到的问题

主要的一个问题就是 registry 的 gc 命令有 bug, 在配置识别上做的不好，默认配置好了 registry data 的地址还是一直扫描不到。不得已用了 docker-distribution-pruner这个库，它做的事情跟 gc 比较类似，只是 outpout 更易读一些。算是能解决 registry gc command 的配置识别问题，但它自己也是因为比较 alpha 的成熟度，也有 bug. 比如目前发现 registry 里没有内容的时候直接就抛异常了，但这个问题不大。因为我们是 loop gc的，等到有数据了自然就正常了。再不济 fork 代码,很容易 fix.

配置示例

首先 gc container 所用镜像的 Dockerfile

FROM registry:2.7.1

ADD docker-distribution-pruner /
ADD run.sh /run.sh

RUN chmod a+x /run.sh

CMD ["/bin/sh", "-c", "/run.sh"]%

#!/bin/sh

while true
do
 # run gc, if delete something, restart registry process
 sleep 120
 EXPERIMENTAL=true /docker-distribution-pruner -config=/etc/docker/registry/config.yml -delete 2>&1 | grep -w "DELETE" && pkill /bin/registry
 sleep $GC_PERIOD
done%

逻辑上就是不断地调用 docker-distribution-pruner 来做清理，如果发现有清理的数据，则 kill 掉 registry的进程。k8s 会自动重启。因为我们默认是用 hostpath. 如果直接是用重新调度 pod 的方式会重启，数据直接就没了。所以还是倾向于尽量原地重启。

 containers:
 - name: gc
 image: docker-registry-pruner:v1.0
 imagePullPolicy: IfNotPresent
 volumeMounts:
 - name: "RELEASE-NAME-docker-registry-config"
 mountPath: "/etc/docker/registry"
 - name: data
 mountPath: /var/lib/registry/
 env:
 - name: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
 value: "/var/lib/registry"
 - name: GC_PERIOD
 value: "604800"

这部分就是 gc container 在 Deployment 里的配置。它挂在的 volume 与 registry 的 Container 是类似的。关于默认 registry 的配置，使用的是 helm 官方的 chart.

BlueTrace与健康码

hang.yan@hotmail.com (涯余) — Thu, 23 Jul 2020 16:32:10 +0000

疫情之下，各国都在不断地调整自己的防疫政策。中国的模式已经证明了其可能是最有效的方式之一，但因为种种原因大部分国家难以效仿和接受。从技术层面来讲，基于支付宝/微信等国民APP之上的健康码模式也是如此:有效，但是别国难以效仿。新加坡最开始使用BlueTrace协议并开发出了相应App让国民下载使用,部分其他国家也开始效仿，甚至有望能成为一种国际通用的防疫标准。

隐私保护是 BlueTrace 所考虑的最主要特点之一。其手段包括如下方面:

尽可能少的收集用户信息，卫生部门唯一收集的信息是手机号
本地存储用户接触记录，只有当被感染者愿意分享此数据时卫生部分才能获取
第三方无法通过此协议一直追踪用户。因为相关标识ID会一直更换
…

所以在对用户的标识方面，主要是通过算法生成的 UserID 和 TempID 来进行。当用户用手机号进行注册时,后台服务会生成一个 UserID, 而用户在互相接触需要通过蓝牙交换信息时，则通过 TempID 进行。TempID的大概结构如下:

可以看到其有如下特点:

加密。只有卫生部门才有密钥能解密数据
过期时间。TempID有过期时间，一般在15m左右.这样可以尽量减少恶意攻击或者伪造假数据

TempID的生成需要联网(加密啥的)，所以为了考虑到用户不联网的情况，所以TempID可以一次性尽量生成多个，在联网的时候一次性发给用户以备用。

当装有相应APP的用户相遇时，设备会通过 Bluetooth Low Energy (BLE)协议进行通信并交换信息，其数据流程如图所示:

这里面两个 Device 分别有一个角色定位，一个叫 Central ，一个叫 Peripheral。Central 主动扫描 Peripheral 并读取其信息，然后返回一些额外信息。一个手机一般是按一定时间比率轮换在两个角色之间切换。其交换的数据大概如下所示:

{
 "id": "FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==", // TempID
 "md": "iPhone X", // Device model
 "rc": -60, // Signal strength
 "o": "IJ_HAI", // Health authority identifier
 "v": 2 // Protocol version
}

这里面需要注意的是:

rc. 信号强度，用来评估距离之类的。由 Central 发送给 Peripheral
o: 本国卫生部门。 _ 前面是国别，后面是部门简称。这样支持不同国家之间，一个国家不同部门之间的数据互通。

但有人感染时，这时候就需要人力介入，通过手机存储的相关数据分析，结合对被感染者的询问来综合筛选可能受感染的人群。所以整体来看，这是一个半人工的解决方案。对很多国家来说，可能综合来看是一个比较好的方案。但对于人流密集的大城市或者像美国这样目前处于大规模感染的国家，这样的APP估计能起的作用也非常有限。

外界对于健康码的担忧也不无道理，毕竟是一个未公开的技术方案。网上也很难找到有用的技术背景信息介绍。从长远来看，这次疫情会促使我们思考，如果再遇到下一次类似的灾难，我们如何通过技术手段来自救？不止是瘟疫，甚至于地震，洪涝灾害之类的。我们可能需要一个针对于灾难的公开的技术 protocol, 利用现存的各种信号传输方式来筛查，帮助其他人。

给 Kubernetes Lens AppImage 添加 Desktop Entry

hang.yan@hotmail.com (涯余) — Wed, 29 Apr 2020 22:13:02 +0000

本文记录如何为 Kuberntes Lens 的 Linux 版本的 AppImage 手动创建一个 Desktop Entry 以及生成 Icon

手动创建 Desktop Entry

创建一个 desktop 文件，任意位置均可。假设名字为 lens.desktop:

[Desktop Entry]
Name=Lens
Comment=A full-featured Kubernetes IDE
Exec="/home/yayu/Soft/AppImage/Lens-3.3.1.AppImage" %U
Terminal=false
Type=Application
Icon=kube-lens
StartupWMClass=Lens
X-AppImage-Version=1.4.1.271
Categories=Network;
X-AppImage-BuildId=1N3OgzauYTeCvM55WzKgL7MIQe0
X-Desktop-File-Install-Version=0.24
X-AppImage-Comment=Create By HangYan
TryExec=/home/yayu/Soft/AppImage/Lens-3.3.1.AppImage

其中 Exec 以及 TryExec 是 AppImage 的位置，应相应更改

生成 ICON

这里我下载了一个黑色的 Kubernetes ICON, 背景透明，webp 格式

这里我已经转为 png 格式，转换命令为:

dwebp <origin>.webp -o kube.png

然后，生成相应的 Icon, 并安装到系统中

xdg-icon-resource install --theme Moka --size 48 kube.png kube-lens

安装的 icon 可以在 ~/.icons 目录中看到。

其中:

theme: 即将此 icon 安装到哪个 themes 中. Linux Desktop 基本上都有可以设置 icon themes 的地方
size: 一般是 panel 上 icon 的 size, 这个在一般的 panel 的设置里也能看到
kube-lens: 即最终生成的 icon 的名字，也就是上面 desktop 文件中引用的 icon 名字

安装 Desktop Entry

# 先做一下校验
desktop-file-validate lens.desktop

desktop-file-install lens.desktop --dir=~/.local/share/applications

# 更新 desktop entry
update-desktop-database ~/.local/share/applications

最终效果如图:

Linux 桌面的失败

hang.yan@hotmail.com (涯余) — Sat, 04 Apr 2020 21:29:54 +0000

之所以说它失败，是指从功利的角度来看。不管是市场占有率，还是软件的可用性，用户友好性，以及生态上，都是失败的。直到2020的今天，以 Ubuntu 为代表的厂商在不断地向竞争对手学习，但仍然不足以和后者相提并论。当然，从自由以及民主的角度来看，它是有成功之处的，开源软件的流行，对于用户隐私以及自由的尊重，这一切的努力都值得我们敬重。

从表面上看，如果我们细数其失败的现象，很容易列出以下几点:

生态太差，没有多少厂商愿意开发 Linux 平台的软件。而进一步的原因则是用户基数少，以及开源社区天然对商业软件的不支持态度
用户不友好。偏技术化，普通用户难以方便地使用。

造成这种现状的原因很多，不一而足。其中人和制度自然是重点因素。

从 Linux 桌面的相关开发人员来看，有相当一部分人是满足于现状，并且不愿意 Linux 桌面朝着 Mac OSX 和 Windows 的方面演进，因为它是 Linux, 是自由软件的核心，似乎不应该走那样的路。这一部分人满足于目前 Linux 的生态，并沉迷于从技术角度去使用和解读 Linux，同时和普通用户区分开来。另一部分人，在努力地丰富 Linux 应用的生态，但却走入了一个怪圈。到今天，我们有几百个发行版，几十个桌面系统，几十个文件管理器，Terminal应用，音乐播放器，数种不同的 GUI SDK 框架。他们共享了一个 Kernel, 使用起来功能也大同小异，一样的不如商业软件好用。但所有人都似乎相信自己所选择的框架/方向是对的，至少相对于其他选择是有一定优势的。假设这些精力能集中起来，会不会更好？

没有假设，因为没有这个可能。与当世的民主制度一样，开源软件的开发流程大体上遵循了同样的模式，也遵循了同样的制度性缺陷。它防止了最大的恶(隐私，对自由的侵犯)，但却受制于其极低的效率。作为一个开发人员，你发现了一个应用的 BUG，或者有了一个新的 Idea 或者非常好的 Feature 想要合并进去，可能目前这个项目的 Owner 太慢了没时间处理，或者暂时不认可你的想法，那么你要么搁置你的 idea 或者 bugfix, 要么狠心下来自己 fork 一个新的版本。或者你直接掠过沟通这一步，直接开始自己的新项目。这就是 Linux 应用生态的开源项目的常态。

这个怪圈有没有逃出的方法，有，而且很成功。只是，他的价值观显的不那么普世罢了。这样的例子很多。GNU/Linux 二者的创始人便是。可惜的是，后面的一票人都走偏了。这个方式现在有一个专业的词汇，叫终身仁慈独裁者(Benevolent Dictator For Life).

我们很熟悉日常新闻上的 Linux 本人，经常骂这个骂那个，言辞粗暴，但其地位和声誉却未受影响。因为:

他本身水平之高有目共睹，是 Linux Kernel 和 Git 的创始人.
他领导下的 Linux Kernel 项目发展顺利，效率高，质量好

就这，就足够了。就是这个仁慈独裁者，能保证一个产品拥有稳定的内部结构，统一的 interface, 和高效率的产出节奏。而 Linux 应用层恰恰缺少这么一个人，来决定大方向和开发流程，造成了现在的局面。

当然，应用层本身的特点也不太可能推选出一位仁慈独裁者。这时候，开源世界历史上最为成功的项目之一–Kubernetes(它的仁慈独裁者是 Google) 所采用的 SIG GROUP 方式就值得借鉴了。在应用层划分若干个领域，每个领域再推选领导。由他来决定开发方向和领导开发流程。这样，才能防止应用层的开发力量进一步分化，而陷入无休止的 fork 和重复造轮子中。

当然，文化对人的思维定性影响之大，除非经历重大的变革，这样的改变是不太可能发生的。甚至曾经有过这样的惨烈教训: systemd. 它让作者收到了很多死亡恐吓信，让 Debian 的领导层因此产生了分裂。一个远远优秀于 Linux 现存各种 init 系统的替代品，其面临的如此遭遇充分昭示了开源项目本身所面临的非技术层面的文化问题。

如此看来，UOS 反倒有可能成为一个强有力的改变。结果如何，不得而知，但就方式而言，相较于过去的发行版，或许真的可以拿各国的抗疫政策以及结果来做对比。

Kubernetes in 2020: Let's Forget About Kubernetes

hang.yan@hotmail.com (涯余) — Fri, 03 Jan 2020 16:07:42 +0000

犹记得 Docker 横空出世的时候，像明星一般，吸引了无数的人去研究它，使用它，推广他。技术的狂热让我们隐隐约约觉得它似乎解决了无数的业内问题，即使它实际上只是适用于单机环境的一个容器实现。没关系，我们有 Mesos / Marathon, 或者其他类似的东西来弥补它的不足, Docker 仍然是我们关注和研究的核心，其他的都是陪衬。

Kubernetes 的出现改变了这一切，与 Docker 一样，从一开始它就拥有了极好的架构基础。在它的逐步成长中，Mesos/Marathon的先天不足逐渐被显露出来，并且逐渐被推至边缘地带，Docker 也渐渐地回到了它应有的位置上，成了软件行业中，无数层级抽象中的一环，在 Linux Kernel 之上，在 Kubernetes 之下，默默工作，只有在出问题时才会被人们想起。Kubernetes 成了新的核心。

而过去一年，我们看着 Kubernets 也在逐渐成熟，性能更好，功能更完善，一切都在向着更稳定的方向迈进，也在紧随着 Docker 走过的路。我们永远需要一个 Platform, 这个 Platform 是谁则是在不断变化的。因为 Platform 的稳定，所以它应该被遗忘，因为我们在思考更高层级的东西。在这整个链条中，我们知道了起点是二进制，终点是人的需求，中间的路，我们走到了 Kubernetes 这里。那么 Kubernetes 的上面是什么？这可能是我们在今后的一年或者很多年里探索的答案。

过年的一年已经给了我们很多零碎的拼图: ServiceMesh, DevOps, GitOps, Application, Helm, Servrveless, Cloud Native…. 这些名词如雨后春笋般冒了出来，让人眼花撩乱。它们并不能总是解决所有的问题，但却给我们指明了一定的方向。

从代码自动到产品，这一个长久而又清晰的诉求，在 DevOps 提了这么多年的情况下，依然在被呼吁，说明我们仍未达成目标，因为它本身需要的前置条件太多, 我们需要良好的 CI/CD, 能够适配各种 VCS;我们需要简明清晰的语法，来描述出了流水线的 Steps;我们需要统一的 Artifact Storage, 用来存储诸如 Test Coverage Output, Docker Image, Binary…等各种各样的文件;我们需要完善的 Unit Test, Integration Test, 来保证能尽量自动化地检测产品的质量，我们需要蓝绿发布，滚动更新，自动的故障恢复…等等。即使这其中的每一步都有了优质的候选技术，将他们真正地串联起来成为真正的 GitOps, 才是更难的地方。因为成功的 GitOps 也需要达到像 Docker / Kubernetes 那样既是一个稳定的核心，也是一个扩展性良好的平台。而这正是开源社区的弱项，人们更容易被技术的偏好分心而不断 fork 分裂，而不像公司那样能有一个稳定的目标和节奏。Docker 和 Kubernetes 的成功历史都证明，公司 + 开源的模式才是最有效的。期待在新的一年里在此方面能有大的突破。

GitOps 的两端，处于源头的Git 的地位确定无疑，而产品如何描述也是一个我们需要重新考虑的问题。我们从 Monolith走到了 Micro Service, 结果发现带来的问题更多。Micro Service 不是最终的目的，构建于 Service Mesh 之上的 Application 才是。我们把 Monolith 打散成了 Micro Service, 又通过 Service Mesh把他们拼在了一起，变成了从内到外，纤毫毕现的 Application, 因为我们有了 OpenTracing, 有 Monitor, 有拓扑，像是X光下的人体结构一样清晰。遗憾的是，不管是 Service Mesh 还是 Application, 社区仍未统一好发展的方向。大家都扔处于摸索之中。

Service Mesh 作为一个相当底层的 Building Blocks, 我们既希望它能稳定，性能好，无感知，同时我们也希望它能以一个高层次的蓝图形式展现给用户，让用户能够在需要的时候概览全局，定位问题。这样高的要求，自然不能一蹴而就，Service Mesh 正处于一个相当早期的阶段，标准未定，开发方向分化，过于重量级而让用户无法忽略它存在的成本等等。抛开开源社区本身的局限性以及厂商力量的介入，Service Mesh 本身仍然是在茁壮成长着，并且在 Kubernetes 的上方站稳了脚跟。

Application作为一个更为古老的概念，在 Kubernetes 的语境下需要我们更多的重新思考。我们如何用这个概念来表达出用户的需求？如何尽可能地屏蔽掉底层的细节而让用户不用被迫去学习更多的概念。当 Docker 兴起，用户需要了解 Container, Image, Registry, 当 Kubernetes 兴起，用户需要了解 Deployment, Service, Secret….这其中哪些是必须的？哪些又是不必的呢？过去一年，我们已经见到了无数的工具在尝试在用户面前屏蔽掉像 Deployment/Pod 这样的概念，而代之于一个更为上层的 Application。Helm，Kustomize, Application CRD…都在尝试达成这个目标，却都有各自的缺陷。抑或是 OAM，CNAB, 这样的 Spec, 也不可避免地涉及到厂商的偏向。Service Mesh 难在技术，而 Application 则难在交互。难到在如今众多的想要用 YAML 来表述应用的概念的尝试中，仍然没有能超越 Docker 最初的 compose 语法的简洁性的，不管其初衷是想提供多么强大的特性。Kubernetes 摧毁了 Docker Compose, 却仍然未能发展出一个合适的替代品。失去功能，失去很多。失去简洁，则失去一切。当然，这些尝试以及未来的可能的尝试仍然是非常值得鼓励的。

总的来说，过去一年，我们开始逐渐关注 Kubernetes 之上的东西，而对 Kubernetes 本身的注意力则越来越少，新的一年更是如此。GitOps + Service Mesh + Application 在某种程度上代表了 Kubernetes 的上一层，也许他们就是全部，也许他们并不对，毕竟，他们还不是一个词。往下看，可以肯定的是，Kubernetes 仍在默默地支持着这些技术名词，在即将功成名就之际，还留下了 kubebuilder 这个强大的建造者，这也在某种程度上也减轻了上层技术的分裂，给了我们在新的一年里往更高层级的抽象迈步时坚实的基础。毕竟，万物基于CRD。

Git 与 GitOps

hang.yan@hotmail.com (涯余) — Thu, 12 Sep 2019 13:02:41 +0000

伴随着 GitOps 的盛行， Git 本身的影响力也在逐渐增大。从最开始只是为了管理 linux kernel, 到支撑起了 Github 这个最大的软件社区，Git 本身的应用范畴早已超出了 vcs 本身，我们还用它来存储配置文件，文档，制作电子书，维护 blog (由 Github 等平台展示)等等。在 GitOps 的范畴内，它更是成为了 the single source of truth。

但 Git 最初的设计目标只是针对于 linux source code，大量的小文件，而伴随着 git 应用范围的增多，明个明显的问题便显现出来

大文件的管理：大文件通常都是难以 diff 的二进制文件，跟 git 本身的设计理念完全背道而驰
大仓库的管理: 像 Google 的 Single Repo 以及微软的 windows 等巨型仓库，在使用 git 时都都会遇到非常多的性能问题。

对于前者来讲，目前的主流的解决方案都是 LFS, 主流的托管平台都支持。但在 GitOps 的大前提下，这个问题仍然算是未解决，因为在企业场景下又多了一个 Git 大文件管理的 dashboard，而 GitOps 得了理念是为了减少 dashboard, 将所有的一切都统一起来。一个可能的选项是用Cloud Native Artifact Registries的理念，用distribution 作为 LFS Server。

大仓库的管理微软的贡献比较显著些。像 Windows 这样的巨型项目，他们必须提前做很多改善才能把 Windows的代码放到一个仓库里。最终的实现原理跟 Google 类似: 与普通的 Git 仓库不同，他们使用一个 virtual filesystem 来作为底层存储，当用户使用 git 时，只有那些被访问的文件才会被实时从 Server pull 下来。这种方式带来的一个附带好处是也解决了大文件的管理问题。

期待 GitOps + CNAR + DevOps 完全成熟落地的那一天。

参考链接:

GitOps

hang.yan@hotmail.com (涯余) — Wed, 11 Sep 2019 16:44:26 +0000

Kubernetes 确定了统治地位之后，Service Mesh 和 GitOps 也渐渐火热起来。Service Mesh 领域内 , Istio 已经逐渐占了上风，但 GitOps 扔未有统治性的工具出现，尚处于早期阶段。

相较而言, Service Mesh 本身技术性更强一些，而 GitOps 涉及的面比较广。对企业来说，会有很多额外因素需要考虑，一方面要考虑旧有系统的兼容性，另一方面要考虑所采用工具的可占有性(是否可以自己部署，维护，开发？)。所以即使现在社区有功能比较完善的 GitOps 工具，也很难被企业所采用。

但就理念而言， GitOps 本身的前景非常广阔，最直观的改善就是对于研发人员效率的提升以及产品 Deploy 效率的提升。这些优点是以如下特性/流程为基础的:

让工具去处理杂事
研发人员使用熟悉的 Git ，专注于产品研发
使用声明式语法描述环境目标状态，类似于 kubernetes
使用 Pull Request 进行 Review
流水线集成 lint /test, 进行较为基本的自动化 check
PR 通过即可直接上线
通过线上故障来总结反馈并修正自动化 check

这个流程的效率非常高，事实上很多企业会在改善自身研发流程的过程中多多少少都实行了类似的模式，但问题就在于很多使用了 ad-hoc 或者无法产品化的手段。如何解决社区标准化的产品与企业应用场景之间的鸿沟，是 GitOps 亟待解决的问题之一。

Raft 协议笔记

hang.yan@hotmail.com (涯余) — Tue, 10 Sep 2019 14:51:05 +0000

关注于 Raft 可能更多是因为 kubernetes/etcd 的原因，二者似乎变成了 raft 最大的客户，时不时地重新理解一下这个协议还是很有必要的。

之所以这样讲，是因为分布式协议本身就很难理解。即使 raft 论文中一再声称它的主要目的之一便是容易理解，比 paxos 更好懂，但对于一般从业者来说，要想完整地理解它还是有困难的。所以经常需要温故而知新。并且，在网上一搜，关于 raft 协议的 blog 也是汗牛充栋，每个人都在试着理解，记录。可能后续还需要参考下别人的笔记，互相印证。

论文地址: In Search of an Understandable Consensus Algorithm

基本知识

leader 的概念是核心之一。raft 作为一个分布式系统，各个 server 通过固定的算法选举出 leader , 然后 leader 负责状态的维护，处理 client 的请求，维护整个集群的状态等等。跟民主制度里面多党选举有点像，一旦大多数投票通过，总统就拥有至高权力。

除了 leader 之外，还有另外两个角色是 follower以及candidate。选举状态下，大家都是candidate,正常工作情况下，就分成了leader和follower。

Raft 并没有使用系统时钟来作为同步机制，因为太不可靠了，而且维护起来很麻烦。raft 使用了一个 term 的概念来代表时序。

Leader election

一般的流程如下所示:

server 启动时，成为 follower
如果 follower 在 election timeout 的时间内，没有收到 leader 发来的 heartbeat，那么它就假定没有 leader, 准备开始选举
follower 将自己变为 candidate，然后给自己投一票，然后发信息给其他 server 问其他 server 是否可以给自己投票。结果要么是大多数投了它，它成为 leader, 或者另外一个 candidate 成为了 leader, 或者没有 leader (splite vote,没有 server 获取到大多数 vote)，那么就进行一下次投票。
在 election 的过程中，有可能其他的 candidate 已经成为了 leader, 并给当前的 candidate 发来了同步数据的请求。这时候就可以通过 term 的比较来判定，如果发过来的 term 数不小于自己的，那么就承认发送者的 leader 地位，并且把自己切换回 follower 状态。否则的话拒绝请求并且继续选举。

这里面有一个问题，所有人都在给所有人发请求要求 vote 自己，怎么能达到有一个 candidate 获取到大多数 vote 呢? raft 采用了 randomized election timeout 来解决这个问题。不同 server 的 lection timout 不一样，避免了大部分情况下的 splite vote 情况。如果发生 splite vote, 重来一次。这种机制跟 TCP 的拥塞控制有些类似。

Log replication

log replication 有几个概念，如下图所示:

Entry 代表了一次操作，一条记录，每个 term 可能包含一条或者多条 entry, entry分为 commited entries 和非 commited entries. commited entries 是 leader 确定那些可以提交到 state machines 里的 entries。这些 entries 能确保一直可用(比如 leader crash)，并且被大部分的 server 同步。Entry 有个前置性推断， commited entries 之前的 entries 也是 commited entries。

可以理解， raft 系统的目的就是尽量保证所有的 server 有相同的 entry 序列。这中间要经历选主，leader crash, follower crash ,各种 timeout 等等。在 raft 中，如果 follower 与 leader 的 entries 有不一致的地方，会用 leader 的来覆盖 follower 的。而 leader 自己的 log, 不会覆盖也不会删除。这个逻辑是挺简单的，但实现起来略微繁琐。 leader 需要找到各个 follower 与自己一致的地方，删除之后follower 中错误的数据，并且把自己发过去进行覆盖。在这个过程中，leader 给每个 follower 维护了一个 nextIndex 序列，用做要发给各个 follower 的数据的指示。如果被 follower 拒绝了，那么就继续往回找，直到找到二者的相同序列。

Log compaction

如果没有 compaction, server 的 log entries 就会无限制的增长。所以一般需要某种 snapshot 技术来压缩已经 commited 的 entries。如下图所示:

每个 server 各自做各自的 snapshots., 并且添加一些 index 来指明位置。同时增加了 leader 向 follower 同步 snapshot 的功能。

Client 交互

因为所有的情况下 client 的请求都由 leader 处理，但 client 又知道 leader 是谁。所以会随机发给一个 server，由 server 告知 client leader 相关信息。网络请求都要考虑重试以及可重入性的情况。假设 leader处理了一个请求，在 response 发出去之前 crash 了，那么client 会重试，这个操作就又会被执行第二遍。解决办法是给每个 client 的每个 command 一个序列号， raft 追踪下每个 client已经执行过的最新的序列号,如果发现新发过来的已经执行过，就跳过了。

普通的 read 操作也会有问题，虽然不涉及到数据改动，但可能会读取到 stale data。有可能在读的时候有了新的 leader 并且当前数据已经过期了，所以 raft 在返回 read-only 的操作的 response 之前又增加了一个 leader exchange heartbeat 步骤来同步 leader 状态。

Oberon操作系统

hang.yan@hotmail.com (涯余) — Wed, 04 Sep 2019 21:25:35 +0000

文章链接: Oberon – The Overlooked Jewel

很多行业以及技术在早期都呈现出了一种百花争鸣的态势，然后到了成熟期一般都只是几家公司或者技术在互相竞争。操作系统也是如此，目前的主流 OS 里基本上就是 Mac/Linux/Windows 三家。但是在互联网早期，出现了很多设计里面差别很大的操作系统，从 GNU 的 Hurd，到 Lisp Machine，还有 Oberon 等。他们之所以消失，并不是说本身技术方面不占优势，而是从商业以及用户习惯上来讲，最终使用的人数太少而逐渐销声匿迹而已。而且从设计里面上来说，相当一部分的 OS 设计是因为理念太过超前而违背了当时用户的使用习惯而被舍弃。所以即使从今日来看，探究一下这些老旧的操作系统的设计理念仍然是大有益处的。

Oberon 的作者也是 Pascal 的作者。他自己对 Pascal 是很矛盾的感情。Pascal 本身只是他的一个作品之一，他本身的能力是非常强的，先后设计了很多完整的操作系统，编译器等等。但是外界对他的期待都在 Pascal 上。他也一直拖着不去更新，而是专注于自己感兴趣的领域。Pascal 渐渐式微，Oberon 也淡出大众视野。他沉浸于自己的创造乐趣之中，也给后世留下了无数珍宝。

文章提到了几个 Oberon 操作系统的特点，让人都非常印象深刻。

系统级 GC

GC 在我们一贯看来都是属于高级语言的概念，操作系统很少有人会用 GC 来做资源管理。Oberon 实现了系统级别的 GC：进程使用文件，不需要显式地自己去关闭文件句柄等。现在操作系统的应用程序因为系统没有 GC,不管是操作系统本身还是应用程序都需要许多额外的处理此类细节的代码逻辑。而且需要设置各种文件句柄的上限等等。Oberon 所采取的策略对未来的操作系统来说很是很值得借鉴的。

更少的对话框

对话框这个东西，自操作系统有了图形界面不久就一直存在。软件用它来给用户提供编辑，确认等操作。但是对话框并不是一个好的设计，因为它需要会打断用户的思路，强行让用户分散注意力去关注于一个全新的界面。现代的操作系统仍然有很多的这样的或无奈或多余的设计, 比如：

Mac OSX 在关机的时候，因为平时开的软件比较多。经常就是需要一个一个地点各个软件弹出的确认退出的对话框。系统并没有一个默认的忽略选项，即使用户完全不在意各个软件是否需要保存当前状态。Mac OSX 为此做了一个 Force Quit的功能，用户需要一个一个地强制退出可以忽略的软件
文件的更名操作既可以弹出对话框，也可以直接按 Enter 去修改。后者就比前者简单好用的多
Mac 安装软件的一步拖动方式就比 Windwos 的在对话框中一直点下一步好很多

Oberon 在设计之处就考虑到了这个问题，尽量在用户界面少使用对话框。比如它的文件另存为操作，就可以直接点击文件名，输入一个新的，然后点击保存命令即可。这比现在常用的弹出一个对话框让用户输入再确认好的多。

校园合作

这是最让我震惊的一点。 Oberon 操作系统在作者所在的学校里，所有的人都在用这种操作系统。它发源于本校，主要的开发者都在本校工作或者退休了，使用同一种编程语言: Oberon，有足够用的应用程序。这样一种操作系统对学生来说，在教学上拥有无与伦比的优势：详尽的文档，近在咫尺的开发者，你可以从头到尾了解一个操作系统的实现细节，学习它，研究它，改造它，提升它的性能，给它开发应用程序。所有的这一切，都会被记录下来，作为一个学校的令人自豪的存在，被后来的追随者延续它的生命。

这几乎就是所有的大学的计算机系最理想的教育模式。由最富有经验的教授或者学生开发，从操作系统，数据库，到一切课本上需要学习的东西，由自己创造出来，让学生参与进来，代代相传，生生不息。不同学校之间还可以经常性地举办各种同类软件之间的竞赛(性能，设计等等)。

失败博物馆 - Hadoop

hang.yan@hotmail.com (涯余) — Sat, 31 Aug 2019 13:35:37 +0000

Hadoop 严格来说并不算完全失败了，不像 Mesos 那样，而是人们期待它成为一个大象，而它却变成了一只兔子。

我刚毕业就开始接触Hadoop, 当时它基本上就是大数据的代名词。在这个光辉的表象之下，研发人原面临的是一个非常不透明，UI丑陋，运行缓慢的系统。当然，技术的狂热周期会让人放弃自己的疑虑，专心地去这座 shit mountain 扒拉东西。另外，也没得选。

同样的情况也发生在 Jenkins, Mesos 身上，当没有对比的时候，人们很难意识到自己面对的东西的优缺点是什么。时至今日，在吃尽了很多苦头之外，我们可以回过头来想想，为什么有的软件成功了？为什么有的失败了？

成功的特性几乎是不言自明的，我们可以列举如下：

模块化 / 可扩展性好
接口用户友好 (页面，编程语言，API)
文档全面

这些就够了。而失败软件在每一方面，几乎都没做好。Hadoop 也是如此。

同时因为这些因素存在，人们从最初的狂热清醒下来之后，便开始想尽一切办法找寻可能的替代品。在数据量不大的时候尽量选择其他工具(pandas, unix tools等等)， Spark, Hive, Pig…. 甚至连 Hadoop 第二代的 YARN 都被 Kubernetes 无意打残了。当然，这个现状有一个比较好的词叫生态圈，但它和 Kuberentes 的生态圈还是很不同的。前者是因为太难用，被肢解，被不断替代。后者是根系稳固，枝叶繁茂。（没写完，待补。）

科大讯飞

hang.yan@hotmail.com (涯余) — Sat, 31 Aug 2019 13:01:56 +0000

讯飞并不是一个很坏的企业，它只是太懒了。

国内的互联网巨头基本上没有干净的，无不是带着一身罪恶爬到了现在的位置。讯飞是一个巨头，因为他在语音行业是老大，规模也不小。但它也不是，因为它身处合肥，似乎互联网的新潮跟它都没什么关系，也很难在新闻上见到它的身影。可以概括地来讲，它是成也合肥，败也合肥。

之所以说是成也合肥，一是中科大保证了它的研发能力不弱，而是与政府互相依赖，保证了他政府方面的合作优势。败也合肥，则是因为在这么一个三线城市了，所有人都想过着朝九晚五的生活，并不想像去参与北上广的发展竞赛。再加上公司的营收严重依赖于国企的订单，它自身也变得越来越像一个国企。

机器学习大火之后，语音识别技术变得更加简单和常用。所有的大厂都可以投入人力物力去研发自己的语音识别技术，并且与讯飞的差距逐渐缩小，进一步去蚕食其本身的市场。在可以预见的未来里，它的日子并不会好过。

还有一个更明显的问题是，它太不会营销了。虽然说酒香不怕巷子深，但是当别人都在拼命地宣传自己的产品，而消费者又不是很在意这之间的细微差距，那么累积起来的用户习惯是很怕的。纵观互联网的历史，有太多产品好却死去的案例了。

还是希望它能好好正视下自己现在的困境，好好发展下去。

Rick and Morty

hang.yan@hotmail.com (涯余) — Thu, 29 Aug 2019 11:06:59 +0000

我给很多人推荐过这部动画片。可能也是唯一一个我一直在不遗余力地给很多人推荐的艺术作品。

曾经我也跟很多人一样，在追《马男》，看似颓废却又奋进，真是一部优秀的剧集。后来偶然接触到了《Rick and Morty》，再去回看《马男》，不是它不好了，只是相比来说，它太平庸了。

很多喜好的东西都太过个人化了，即使你再爱，也知道你没法总给别人讲。但《Rick and Morty》不同，它是一个流行于全世界的东西，是文化本身，也是文化的反面本身。

很多美国的青少年如此痴迷，以至于在现实中做出种种奇怪的举动。川香酱的疯狂正是一个绝妙的对于这个剧的呼应。而对于中国的青少年来说，这个美国文化里衍生出来的动画片，包含了太多反美国文化的东西，以至于每一个大洋彼岸的年轻人都被它深刻地吸引，感同身受。它成了一个跨域东方与西方，跨越资本主义与社会主义，跨域文化的东西。

从内容上来说，抛开表面的光怪陆离，看似蹩脚的宇宙设定，下面隐藏的是每一个人一生都要遇到的问题：父母，子女，家庭，婚姻，种族，文化，梦想，自我的哲学思考等等。同样是表面的虚无主义，底层的复杂深刻。不同的人看会有不同的感受，但每个人都会沉浸其中。

《马男》的失败在于，同样是在探讨这些问题，但是太根植于美国文化，让其他地方的人总觉得有隔阂，且太过肤浅，没有悲剧式的深刻。《Rick and Morty》里最为痛苦的设定在于，Rick 知晓自己是一个动画角色，这种痛苦一直伴随着他，自杀而不能。

同样无法摆脱这种可能的我们，可能为了规避这样的痛苦而不敢去想这个问题。

KARL, ASLR, KASLR

hang.yan@hotmail.com (涯余) — Tue, 27 Aug 2019 11:11:23 +0000

前段时间在零星地看一些关于 unikerel 的文章。里面提到的一些安全相关的技术非常有趣，就又开始转向 kernel 安全这部分。本文主要探讨的是 KARL, KASLR 以及 ASLR 相关的技术。

安全相关的实现技术很多，但想了想，大体的分类可以归为以下几类：

RWX 权限检查
随机化: 尽量不用确定性的内存地址
暴露最少的信息: 日志，输出里尽量不暴露相关信息

KARL, KASLR 以及 ASLR 都属于第二类。尽量让应用程序以及内核在内存中的地址随机化，这样攻击者就难以猜出相关的地址。

简单来讲， ASLR(Address-space layout randomization) 主要是指内存中用户层的地址随机化，KASLR 是指内存中内核的地址随机化，而 KARL(kernel adress randomized link)是指内核本身的地址随机化。ASLR出现的时间更早一些，更成熟一些。

注意有一个区别，三者中都有一个 L，但意义不一样。 ASLR/KASLR 中的 L 是指 layout，是说内存中的布局。你不可能要求大量的应用程序自己去考虑随机化，而是在应用程序无感知的情况下，由内核来选择一个随机的位置来运行应用程序。而 KARL 中的 L 是指 link ，是在链接阶段就做好了地址的随机化处理，这样就不需要再内存中在做了。

ASLR

ASLR 理解起来相对更为简单，本身不需要再重复介绍。

RNG

不管是 KARL / ASLR / KASLR，其核心都是一个随机的概念。明显它依赖于随机数的生成算法。当然随机程度越高越安全，但是又要考内核的性能。这个平衡很难掌握，选择哪个 RNG(random number generation) 也经过了很多讨论。

一开始用的是 get_random_int(),一个性能比较好但安全性不够好的方法，后来有人提出用 get_random_bytes(),安全性大大提高，但是性能下降也比较多。再后来 Linux 自己对get_random_int()做了一些改进, 增加了一些噪音进去，在不影响性能的情况下改进了随机性。这也是目前在用的方法。

但是，这仍然是一个不够完美的选择。get_random_int内部用了half_md4_transform，一个更弱化版本的MD4算法，现在 MD4/MD5 的碰撞都很容易了。后来有人换成 SHA1做 benchmark,性能下降 50%左右，对内核的人来说也是基本上不可接受。所以目前只能是这样了。再说，现在SHA1的碰撞也已经被发现了。

KARL

在 KARL 之前， kernel 里面的 boostrap代码，汇编语言 runtime 代码(locore.S)，以及其他 c 代码之间的位置都是固定的。一般都是 locore.S 在前，然后是各种 c 文件。引入 KARL 之后，locore 被分成两部分，一部分是最开始的 boostrap, 然后是汇编语言 runtime 以及其他的 c 文件，不过后者的放置是随机的了。这样每一个新的内核都是独一无二的，代码以及数据之间的偏移量也是不固定的。当然 boostrap 的代码还是固定的。但是内核可以在启动之后清理掉相关信息。

这样就有个问题，虽然内核以及做了 KARL，但你不能编译好一次之后重复去用，不然还是不安全。最好的方式是在每次启动时重新 link,相当于生成一个新的内核。通过各种优化手段，这个过程可以做到耗时很短。

KASLR

KASLR 与 ASLR 类似，但是是针对于 kernel 的。与 ASLR 不同，KASLR 有几个问题

如果用户在暴力破解找 kernel 的位置，会直接导致机器 crash
与电脑的休眠机制不兼容。
有很多其他的模块需要或者依赖于知道 kernel 的位置，这些都需要谨慎处理。

第三条设计的面比较广，一个例子是 SIDT 指令，它不是特权指令，并且能够拿到IDT(interrupt descriptro table)的地址，进而能够推断出内核的地址。所以需要解除 IDT 的位置与内核位置的关联，将其放置其他地方，并且设置为只读。

另外一个例子是 INET_DIAG socket API, 它用了内核地址作为 handler。虽然对上层应用透明，但是仍然是个安全隐患。可以通过数据混淆解决这个问题。

当然，除了这些已知的状况，还应该通过各种方式来限制其他模块使用内核地址，并且尽量不泄露给用户,比如:

开启kptr_restrict 系统调用防止内核地址泄露到用户空间
使用dmesg_restrict 防止 dmesg 泄露内核地址
/var/log/messages 应该设置为只有 root 用户能访问.

对于一般的用户来说，比如个人电脑， KASLR 的意义不是很大。但是对于现在的容器化环境(包括container 以及浏览器的 sandbox )来说，有很多安全场景需要考虑(从容器侵入宿主机内核) , KASLR就更有价值了。

链接

Cloud Native Artifact Registries

hang.yan@hotmail.com (涯余) — Mon, 26 Aug 2019 13:46:42 +0000

Helm3 的 design proposal 里面介绍了对于Chart Repo 融合到 Distribution 的提议。目前已经有了实验的 demo，理论上并没有什么问题。因为 Distribution的设计里并不是只能存镜像，而是一个开放的协议。我们可以想下目前企业在 DevOps 场景下，除了代码之外，有哪些文件需要存储

构建产物
二进制程序
Helm Charts
镜像仓库
测试报告
代码分析报告
Kustomize 文件

等等。为数众多，而且都是存储于不同系统的。构建的产物一般都暂存于构建系统内部，有失效时间。镜像在 Docker Hub 或者 Harbor 中，Helm Charts 在官方仓库或者 chartmusuem 这样的仓库中。基本上每一项都需要单独维护存储设施，分别要使用不同的客户端。Helm3 的这个迁移的决定，不止对 Helm 本身有很大的意义，对于其他的产品也具有很大的启发意义。Docker公司本身也在做这方面的整合， Docker app 既可以用来分发 docker-compose 文件还有 CNAB 格式的应用。在可以遇见的将来，所有的 Artifacts 共用一个存储和客户端是可能的。

这有一另外的一个好处是，这是一个独立于云提供商的平台。不管是在 AWS/GCE/AZURE 还是其他云平台，不管是用 S3 还是其他存储，Distribution 这样的平台可以提供统一的接口。

另一方面，Kubernetes 平台上应用的分发格式也处于激烈的竞争阶段，目前常用的就有以下几个:

Docker App
Docker Compose
CNAB
Helm
Kustomize

Distribution 这样的平台能帮助用户减少很多使用负担和迁移成本。预测来看，Helm/Kustomize 最终的赢面大些，docker 可能只能继续专注于更底层的业务。

链接

失败博物馆 - Mesos/Marathon

hang.yan@hotmail.com (涯余) — Fri, 23 Aug 2019 10:28:40 +0000

Mesos/Marathon 的失败，怎么说，太过典型了。如教科书一般，清晰的不能再清晰。

首先，它流行的时候，是因为大家没得选。一个还在蹒跚学步阶段的 Kubernetes 就开始将它打的节节败退。到了现在，连Mesosphere 已经转向了 Kubernetes。

从一开始，这就是一个学术界的产品。由一堆并不擅长编写工业化软件的研究室的学生和老师写出。这导致了 Mesos / Marathon 的致命缺陷

首先，用 C++ 写 Mesos， C++可以说是学术界和工业界态度差别最大的编程语言了。对学术界来说，这是一个可以用来探究编程语言极限的编程语言，数不清的高级设计，数不清的语言学设计，你再任何其他语言里都见不到这么博大精深的体系。但对工业界来说，这是一种灾难级的编程语言。Linux 都在天天骂它，难学难用难调试，市场占有率也一直不断下滑。Mesos 选择了 C++之后，极大地减少了开源社区去贡献代码的可能性，彻底沦为了创世的开发团队自己的作品。

更灾难的是，Marathon 用了 Scala，一个除了 C++之外第二复杂的语言。其同样程度的撕裂性，对研发人员的折磨，让人都开始怀疑为什么当初要选择编程这份工作。语言设计者一旦觉得自己过于聪明，会趋向出设计出来大众难以理解的东西。这并不怪大众，而是怪语言设计者。两个世界上最复杂的语言，组合起来，成了一个大部分研发人员都不愿意碰的黑盒子。然而，它又不是稳定到不出什么问题，总会有出故障需要排查的时候。这便是让所有人都痛苦的时刻。所以即使今天大家发现 Kubernetes 已经非常复杂难以理解了，但没有人会抱怨太多，因为只要你肯花点时间，分析分析代码，总能慢慢理解。而对于 Mesos/Marathon,如果你发现了一个问题，想去阅读代码，大部分时间你都在纠结：这个语法什么意思？这个语法又是什么意思？

另外一种研究室出来的代码的问题在于，很少有人会考虑到架构的可扩展性。有了一个 idea,实现出来，发个 paper，大部分就完了。等到真正开始用户多的时候已经来不及了。而工业界的产品不一样，从一开始可扩展性就是所有系统在设计之初必须考虑的一个问题。所以我们看到，Mesos/Marathon 自发布之后，后续的功能扩充是极其微弱的，难以有任何实质性的功能增强。而 Kubernetes 在发布之后，新功能如井喷一般。当然这里面也有编程语言本身的功能。Golang 问题再多，简单易用本身就足够让很多人开始使用了。

失败博物馆 - Jenkins

hang.yan@hotmail.com (涯余) — Thu, 22 Aug 2019 17:02:37 +0000

我想记录一下工作中使用过的软件里的一些在设计上比较失败的。因为它们，工作中多了很多痛苦。

Jenkins 便是其中之一。跟很多软件一样，Jenkins 在商业上是成功的，成功的原因就是用户并没有什么选择。对 Jenkins 非常了解的人来说，能很容易列举出非常多的详细的jenkins 的问题。从一个普通使用者的角度来看，最直观的两个感觉就是: Jenkinsfile 难写，流水线很慢。

对我来讲，Jenkinsfile 就是最大的设计败笔。从工作中的反馈来看，即使看了文档，也没人知道怎么去写一个正确的 Jenkinsfile。用户想描述好一些流水线步骤，最直观的想法应该就是贴近于 Makefile, 每个步骤几条命令，清清楚楚。再加上其他一些并发控制，产出物管理即可。用 YAML 或者 TOML 这样的配置文件即可。

几乎除了 Jenkins 之外的所有 CI/CD 工具，都选择了用YAML。而 Jenkins 使用了 Jenkinsfile, Groovy 语言，意味着用户需要首先了解 Groovy，在学习 jenkins的语法，才能写好 Jenkinsfile。一些自作聪明的开发人员在类似的设计问题时，会有一种炫技的想法，总想用 DSL 来解决问题。结果通常是不好的，既给用户带来了沉重的负担，也让系统变得难以理解。基于 JVM 的很多语言都是如此命运。

即使你费劲千辛万苦，终于写出了一个能跑通的 Jenkinsfile,这时候你会发现，在 Jenkins 的流水线里面，有很多复杂的难以理解的东西。为什么多出来很多莫名其妙的步骤？系统日志和构建日志怎么这么杂乱无章地堆在一块？为什么速度总是这么慢？界面为什么这么丑？不一而足。

想深刻地理解这些问题在哪，当然可以去好好探究一下它的架构，然后了解这些问题的根源。但这是在没有必要了，对于一个将死的系统来说。作为用户来讲，在已经有了替代品之后，赶快逃离就是了。

数据库与操作系统

hang.yan@hotmail.com (涯余) — Thu, 22 Aug 2019 11:21:52 +0000

数据库一般认为是一种系统软件。而操作系统处于更底层的位置。这是一种通常的认知。

Unix 的一切皆文件的设计思想，从一定程度上来讲，表明了操作系统内部不同组件之间有一定的结构上的一致性。比如网络接口和文件接口，都有如下的操作

Rread
Write
Close/Open
permission

等等。进程和内存管理也是类似的逻辑。所以我们现在可以看到 Linux 系统中有很多类似的尝试，用文件的形式来来作为很多内部组件对外的接口。

这是 Linux 一直在被夸赞的地方。一个听起来优美的设计哲学，吸引了很多人从奇怪的，程序员不友好的 Windows 逃离过来，并花费大量的精力来学习和理解这个设计之下隐藏的诸多肮脏的细节。

工作越久，越来越多的人发现。相比较而言，平时还是 Mac 和 Linux 用起来更方便。即使是爱折腾的程序员，也大多不愿再去浪费时间去折腾 Linux，去折腾 VIM/Emacs。不是因为年纪大了，而是因为这些东西确实用户不友好，而且有设计缺陷。

几十年前，已经很清楚地点评了 Linux/Unix 上的诸多问题。然而它并没有推动 Linux/Unix 去改变和解决这些问题。开源是一面美好的大旗，但它也蒙蔽了跟着的人。

Linux 桌面的失败简直惨不忍睹。自由的 fork, Client-Server 的架构，无尽的口水仗。最终活下来了两个无法合作的 KDE/Gnome。Windows 自然也有很多设计的问题，但注册表现在看来相对于 Linux 的配置文件来说简直是太优秀了。多年人，有些人会想到：

不同 cmd 的 input 和 ouput 的格式都不一样，增加了很多研发的负担
能否用一种统一的数据格式来表达配置以及输入输出？比如 json

也有人尝试过，但从来不会真正影响到社区。即使成功了，systemd 的经历也历历在目。

虽然能将操作系统的诸多概念简化成文件，但文件仍然是一个相对复杂的抽象概念。除了文件系统，没有哪个其他模块能够与文件如此对齐。就数据本身而言，打开文件之后，读写数据，本质上简化为两个结构: list 和 dict，组合起来就是一个 table。

读写文件，基本上就是不断地对这个 table 做修改，增加，删除，修改行。CSV 格式的文件更是可以直接直接对应于一张表。所有其他的内部模块,其操作也是类似的；

创建进程：往进程列表里添加一个元素
销毁进程: 从进程列表里删除一个元素
添加设备: 往设备列表里增加一个元素
配置设备: 修改设备的属性

不只是 Linux，所有操作系统面临的都是同样的问题，使用的都是同样的的机制: 不听地对Table 做各种操作。现状是，所有的操作系统在不同模块的管理上都是有差别的，因为没有统一数据模型的支持，每个模块都在不断地用不同的形式做类似的操作，其提供给用户的功能也因此而受限。

从 Table 的角度来看，数据库成了计算机的中心。数据库理论经过这么多年的发展，已经完成了对 Table 的几近完善的研究，如何操作，如何连接表，查询，并发，安全控制，性能优化、、、所有这一切，在操作系统的各个模块都有非常类似的但是极其拙劣的实现。文件的 RWX 权限，目录的设计, /proc 的映射、、、重复的劳动，同时带来了无尽的安全漏洞与性能问题。

从数据库的视角去重新想象操作系统的设计，几乎充满了无尽的可能性。一个在底层拥有完全一致的数据模型，安全机制的系统，文件系统、设备，进程都是同一个数据库里的一部分，可以互相连接。SQL 虽然不够优先，但可以成为一种统一的查询语言，所有的用户工具都可以用机器简单地方式重新设计出来，而且天生就使用同样的数据格式。相比于困难以及实现的难度，这样的可能性太值得去尝试了。

链接

What is Helm Doing Wrong and How a Helm3 Controller Can Fix It

hang.yan@hotmail.com (涯余) — Sat, 03 Aug 2019 11:26:30 +0000

Helm is big success for sure, it’s nearly the standard application package format in kubernetes.You only need to provide some metadata about your application’s name, version, description….Helm can help you package up and upload to a central or custom chart repo.Just like npm,rpm,docker image, or whatever other package management system.

About a year ago, Helm3 was drafted. Since it’s still on the proposal stage, most users are still using helm2, include us. The journey we spent with helm was not a very pleasant one, we struggled very hard to make it work. In the end, we decided to create a kubernetes controller based on Helm3 proposal, it works well and we open source it on github: captain.

This articles will describe what problem we have encountered when we are using helm2 and how we fix it in captain.

Why is There a Tiller Server?

I remembered reading a article about a helm3 intro talk, when the speaker is showing the slide about removing tiller in helm3, the audience is so exited they applause for a very long time. Ah, awaked moment…Yes, everyone hates Tiller.

So, back to the beginning. From the helm doc:

Tiller is the in-cluster component of Helm. It interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It also stores the objects that represent releases.

Seems promising. But in the real scenario, it introduced tons of problems:

complicates RBAC since it’s not using the RBAC of the user or pod running the helm commands to read/write kubernetes resources.
all releases should have a unique name within a tiller. If you are using a global tiller(yes, a cluster can have multiple tillers…), means that all your release name must be unique across all namespaces, even when the actual release info is stored in a namespace based secret or configmap.Often you have to choose long names and it cause a lot of problems in kubernetes service discovery.
can cause lots of version conflicts between helm clients + tiller versions

So, before the helm3 can be production ready, users in the community have to lives with it, enormous issues has been reported on this topic:

I believe a lot of people who just want to install a chart have stuck at the first place: let tiller running normally!

And, even this is harder, but there is still some solutions to avoid it when using helm2:

Since helm3 remove tiller and the core helm code is in it’s alpha stage, we choose to create a kubernetes controller using helm code as a library(also a proposal in helm3). Of course the helm3 code is not production ready, and we have to do some modification to make the controller working properly, but the result is promising. The workflow around helm also changed, from a helm install command with various command line args to a HelmRequest CRD, this also brought some advantages:

The controller can automatic retry install/upgrade if failed
Since HelmRequest CRD is a simple yaml file, it can be saved to the source code repo
store common configs in a configmap or secret allow multiple HelmRequest resource to ref to
…

Resource Conflicts

The helm v3 proposal does’t seems to mention this at all, but i believe it’s a much worse problem than Tiller. You want to install a chart, some resources already exist, it failed. you upgrade it, somehow it failed again, you delete it and reinstall it again, it failed. I believe most of the users have encountered this kind of problem.

In fact, this problem drives us crazy, just because we have a few charts which contains dozens of resources and a few of crds. Constantly, it fails when we deploy these charts. This is the directly reason why we make the effort to create captain, the helm controller.

There is no need to paste github issues or stackoverflow questions on this topic, just search ‘helm install failure’ or ‘helm upgrade failure’ in google. you will find numerous results on this topic. The underlying reason is simple: the developer of helm didn’t think this is problem. Why? doesn’t matter now, the consequences has prove that this is a totally wrong deceision no matter what .

Just when i’m writing this, we have encounter a problem liks this:

Error: UPGRADE FAILED: no resource with the name “anything_goes” found

Yes, we want to upgarde a release, but it reported this error message. It’s very confusing, and i’m tired of tracing these kind of issues, let me quote one of the responses from this github issue:

Let’s see how kubectl handle this problem, it has a kubectl create command, and also a kubectl apply command, it’s logic is very simple:

if the resource not exist, create
if it exist, update it

I think kubectl apply is one of the most heavily used command in kubectl. Since helm3 does not intend to fix this issue, we have fix it in captain, by adding anther resource handle layer on top of helm3. It’s not perfect, but it works well.

Hook Management

Hooks is a very powerful tool, if only you used it correctly. Helm’s hook is bit of odd and confusing, I think it’s happens a lot when you use helm. It’s hard to guess what helm does under the hood.

For example, the crd-install hook. It’s can be used to ensure helm install these CRDs first, so the upcoming CRs can be installed correctly (the apiserver need sometime to update it’s discovery info). But, if you add crd-install hook to a CRD, the CRD is not a normal resource to helm anymore. If you delete the release, the CRD will not be deleted. Next time you install the same chart again, boom, the install will failed. Why? because it already exist. Even worse, it seems sometimes you cannot upgrade a crd with crd-install hook:

crd-install hook is not working on upgrade

We have encountered this problem once, we don’t know what to do. We have to delete the CRD, just like Thanos doing his finger snap.. a lot of related resource was gone….

Helm also provide an alternative solution: put all your CRDs in a single chart. Install it first, and then install other charts later. This actually is not helpful in many circumstances. Usually wen we hit this problem, we already have a first version of the charts’s structure. If we move the crds around, we will have to do a upgrade(migration), again, either the upgrade failed, or the same resource conflicts problem occurs as described above.

In captain, since we choose an apply logic when create/update resource , none of this will happens again.

The Default Release Name

If you install a helm chart, and does not specific a release name, helm will generate a random one for you, in the same format when docker create containers, such as listening-rodent,mortal-kudu.

Docker choose this name format, because they assign each container a uuid and users often use this uuid, so the names often doest not matter. But in helm release, this name is important, you need use this name to upgrade and delete a release, and helm generated this crap for you.

So, wen we design the HelmRequest CRD, the obvious and most simple choice is : If use supply a release name, use it, If not, use the HelmRequest’s name. Since HelmRequest is namespace based, there is no need to worry about name conflicts any more.

For example, a origin resource description is :

kind: HelmRequest
apiVersion: app.alauda.io/v1alpha1
metadata:
 name: nginx-ingress
spec:
 chart: stable/nginx-ingress

Turns to after created:

apiVersion: app.alauda.io/v1alpha1
kind: HelmRequest
metadata:
 finalizers:
 - captain.alauda.io
 name: nginx-ingress
 namespace: default
spec:
 chart: stable/nginx-ingress
 namespace: default
 releaseName: nginx-ingress
 clusterName: ""
 installToAllClusters: false

Conclusion

This list can go on and go on, different users may suffer from different issues. The helm3 proposal seems quite promising, and it brought a lot of new awesome features, and we are very looking forward to it to become production ready.

Again, weclome to check the captain project out, all suggestions and PRs are welcome.

Sinfonia: a new paradigm for building scalable distributed systems

hang.yan@hotmail.com (涯余) — Wed, 24 Jul 2019 17:22:10 +0000

论文链接: Sinfonia: a new paradigm for building scalable distributed systems

Sinfornia 像是一个构建分布式系统的 SDK 。目前的市面上分布式系统已经非常多了，比如 etcd, zookeeper, ceph 等等。但他们都是分别实现的，彼此之间的代码并无太多借鉴。Sinfonia 的实践是很难得的，可以说比大部分的分布式软件都更有指导价值一些。

这个图中展示了 Sinfonia 中关键的几部分

user library: SDK 部分，隐藏了分布式系统处理内部细节的 SDK。用户基于 user library 来开发分布式应用
minitranscations: Sinfonia 的核心概念。一个分布式的事物机制
application node: 应用节点
memory node: 维持分布式系统内部状态的节点。

图中没有画出的有

管理节点: 用于执行一些定期的 recover 任务
directory node: Application Node 访问 Memory Node 使用的是逻辑 id, directory node 记录了逻辑 id 与真实地址的映射。

Memory Node

Memory Node 存储了应用的状态数据，根据不同情况，可能是存在 RAM 中，也可能是在磁盘上。 user library 封装了操作 Memory Node 中数据的方式。Application Node 可以与 Memory Node 是同台机器也可以是不同机器(有些 Application 出于性能考虑会需要 Applicaiton Node 与 Memory Node 为同台机器，Sinfonia 会告知 Application 此种情况以便让其尽量把数据写在本机)。

Sinfonia 的一个特点是，它的数据结构可以理解为都是字节数组，目的是为了解耦。每个 Memory Node 都只负责管理字节数组，并且可以通过 (memory-node-id, address) 这样的序列来定位具体的数据。user library 即封装了操纵 Memory Node 上这些字节数组的细节。

Memory Node是多个，出于数据 locality 的考虑，Sinafonia 并不提供负责均衡策略，而是让 Application 自己选择 Memory Node。Sinfonia 给 Application 提供了 Memory Node 的 load 信息供其参考。

Minitranscation

Minitranscation 可以说是 Sinfonia 的核心了。Application 可以通过它来访问和修改 Memory Node，并且保证一致性，持久性，隔离性以及可靠性。它有如下优点:

允许用户将多次操作放到一个 batch 里面
可以直接在 commit protocol 里执行?
minitransactions can execute in parallel with a replication scheme ?

一个 Minitranscation 包含三类操作, 按执行顺序如下所示:

compare items: 对比发送的数据与已经存储的数据。如果对比不相等，或者出错，那么整个 transcation 中断。
read items: 比较成功(相等), 读取数据
write items: 比较成功(相等), 写入数据

这几个 items 的组合能够实现我们普遍需要的一些原子语义:

swap: read -> write
compare-and-swap: compare -> write
acquire-lease: compare 0 -> write id

两阶段提交

标准的 two-phase commit 里，如果 coordinator 崩溃，整个系统需等待其恢复后才可用。在 Sinfonia 中，coodinator 就在 application node, 如果它不可用，系统并不会阻塞。而是阻塞在出问题的 Meomory Node 上（因为 Memory Node 保存了系统的核心数据，并且 Memory Node 有 replicate 机制来保证高可用性coodinator 的作用减轻了，它并不需要维持状态。只要在 Meomory Node 处理失败时重试即可。

需要注意的是，在 phase 1, participant 在获取锁后，首先对 compare items 进行比较，如果成功，vote commit, 然后读取 read items ，记录 transcations(redo-log，只包含 write items).否则就 vote abort,释放锁并反悔了。

在 phase 2, coordinator 汇总结果，告知 participants 是 commit 还是 abort。如果是 commit, partcipants 开始写入 write items。

Cache

cache 放置在 Application 层，而不是在 Memory Node 上。这样做的好处有:

灵活性更好
Application 对于 cache 的利用率比较高
Sinfonia 的架构更为简单，从 Sinfonia 获取到的数据永远都是最新的

Minitranscations 提供的 compare 机制可以让 Application 方便地校验其本地的 cache 是否有效。

容错

Sinfonia 使用四种机制来提供 Meomory Node 容错功能:

disk images: 保存 memory node 的数据的 copy。异步写，数据可能会比较老。reply repo-log 可以再 memory 数据丢失的时候进行恢复。
logging: 同步写，保存最近的数据更新
replication: 一个 stand-by 的 node。同步更新
backup: 数据备份。如果 disk images 数据丢失，可以尝试从 backup 恢复。

上面说到 coordinator 的作用在 two-phase commit 中的作用被削弱，因为其不保存状态。在其 crash 时，会使一些 transcation 陷入不确定状态。 Sinfonia 引入了一个 recovery coordinator 来解决这个问题。首先，每个 Momory Node 会记录其处理的一些 transcations 的状态，如下图所示:

recovery coordinator 会循环执行，读取 Memory Node 的记录，从 in-doubt list 中读取那些未提交的 transcations 并尝试恢复。首先，在 phase 1, recovery coordinator 要求所有的 participants vote abort。如果一个 participants 已经 vote 过了，那么就使用之前的 vote ，否则就 vote abort。phase 2 就跟普通的流程一样。所以假设之前的 participants 都 vote 了 commit ，然后 coordinator 不可用，那么 recovery coordinator 就能将这个 transcations commit 了。否则就是 abort 。

如果一个 Memory Node crash, 上图中的 decided list 可以辅助 disk-image 用来恢复 Meomory Node 的内存数据。因为它也是异步写的，会有一些 transcations 存在于 redo-log 但不在 decided 中。这种情况下需要联系其他 particants 看他们的 vote 结果来判定这个 transcations 是否需要 replay。(参与某个 transcations 的particants都记录在 redo-log 中)

如果大部分或者所有 Memory Node crash, 管理节点会启动程序来尝试恢复。关于管理节点，论文中并未着重介绍。目前提到的就两个地方，一个是用于recovery coordinator,一个便是恢复整个系统的。所以看起来更像是一个救火的，并不是常驻服务。在此种情况下，每个 Meomory Node 都会用上面所说的方式进行自我恢复。但是可以通过主动向其他 Meomory Node 发送自己的最近的 transcations 来避免像上面那样的主动询问(交互量上的优化)。

垃圾回收

redo-log以及其他 log 随着时间的增长肯定是不断增加的，所以需要进行定期的垃圾回收。对于已经 aborted 的 transcation, 可以直接回收。对于已经 commited 的 transcation, 需要确保每个参与的 momory node 都将数据落地了。(因为会有 Node crash 的情况)。其他的 list 也会随着 redo-log 的清理同步回收一些 transcations。

forced-abort list 的回收要复杂些。因为 Sinfonia 允许 origin 和 recovery 两个 coordinator 同时运行。如果直接回收，会导致正在运行的 coordinator 出错(它仍想处理这个 transcation)。 Sinfornia 加了一个 epoch number 来处理这种情况。epoch number 与时间相关，由participants 定义并返回给 coordinator。每个 transcation 都与一个 epoch number 绑定。partipants 可以拒绝 stale 的 epoch（大于等于两个 epoch 的差距）。那么 forced-abort 中早期的 trancations 都可以被回收掉，因为如果要重试肯定会被 abort 掉。

数据备份

transication -> redo-log -> disk-image -> backup 。当然 disk-image 只会更新已经 commited 的 transcations， backup 可以从 disk-image 做整个 copy 或者 snapshot。

这个论文引用次数还挺多。但是感觉设计的还是挺零碎的，一些核心概念可以借鉴，但作为一个整体还是感觉不太可靠。另外，不是很懂它是如何做到小部分 Memory Node 不可用时仍然保证系统可用的?

链接

论文笔记：[SOSP 2007] Sinfonia: a new paradigm for building scalable distributed systems

Golang FAQ

hang.yan@hotmail.com (涯余) — Fri, 19 Jul 2019 00:11:33 +0000

Golang FAQ 是一篇比较好的关于 Golang 设计的文档。比较琐碎，但是解释了很多 Golang 设计的权衡之处。没有语言是完美的，从工业界来看，Golang 是一种流行的，成功的编程语言。从语言设计来看，当然仍有欠缺与不足之处。许式伟是前者的角度，王垠是后者的角度。当然除了宏观层面，FAQ 文档仍然提供了很多有趣的细节。

文档的可得性

所有的语言都知道支持文档。但可得性是一个更重要的维度。 Python 有 PEP 系列详细解释了语言设计的细节，有 read the docs 系统为各种 library 提供用户文档。 Golang有 godoc 工具以及 Golang blog, 还有像 FAQ 这样的设计 detail 解释。二者在此方面都是做的比较优秀的，也在一定程度上促进了语言的流行。

语言设计细节

可读性

可读性一方面是要考虑尽量贴近大部分程序员的背景以及知识结构，另一个方面语言的设定要尽量 common, 不会让人需要额外思考来确定一个语法的语义。Golang 对于大部分具有 c / python 等背景的程序员来说非常易懂，也尽量控制新的语法的数量，所以能够迅速的大范围的流行起来。

另一方面，为了语言的可维护性，去掉一些便捷的语法糖也是一个重要的考量。Golang 去掉了 ?: , 隐式类型转换，指针操作，Goroutine 的内部结构不对外暴露等等。虽然代码不会像 python 那样简短，但在可维护性以及稳定性上都有了改善。

Generic types

泛型的缺乏是 Golang 广受批评的一个点。Golang 在初期为了语言的可读性以及可维护性舍弃了泛型，而且从使用角度来看，范型并不是缺少了就无法写出拥有良好结构的代码。当然现在语言发展到成熟期，泛型的加入仍是值得考虑的。

Error 与 Exception

这两个东西只能说目前都没有完美的实现，各有各的问题。 Golang 选择了贴近于 C 语言的 error 形态，也一定程度上是为了语言结构的清晰性。

assertions

在语言层面去掉 assert 是比较好的，因为它的使用场景主要是程序员的偷懒。但是在 test 部分仍然不提供 assert 有点说不过去。目前有很多第三方的实现。

static link

虽然产生的 binary size 比较大，但是却正好和 Docker 成了好搭档。什么依赖都不需要 os 干涉，甚至直接从一个空的 base image 添加 go binary 也是可以执行的。

Tips

unused imports

尤其是在使用 Goland 的 auto-format 之类的特性时，再加上 import 时，因为名称冲突必须使用 alias 的场景下，有时候加入一个 import 语句是一件挺麻烦的事。这种情况下，在代码修改或者重构时保留那些 unused imports 还是挺有用的，用如下的代码可以保留住这些 imports:

import "unused"

// This declaration marks the import as used by referencing an
// item from the package.
var _ = unused.Item // TODO: Delete before committing!

func main() {
 debugData := debug.Profile()
 _ = debugData // Used only during debugging.
 ....
}

Common Index

hang.yan@hotmail.com (涯余) — Tue, 16 Jul 2019 16:20:10 +0000

这几天在重温《疑犯追踪》，作为一个近科幻的代表作，其描绘的社会是如此地贴近现实，让人想到时都会有一种无力感。在技术社区的种种讨论中，总会有零星的关于此话题的讨论以及解决之道。去中心化网络作为其中一个核心概念，已经有很多落地的实验性产品，虽然仍然无法撼动如今的网络结构，但总是一些希望之火。另外一个最近引起热门讨论的技术便是 Common Index。搜索引擎发展了这么多年，在给人们带来了很多便利的同时，也带来了无数的负面影响。Common Index 是一种解决途径，虽然如去中心化网络一样，看起来都很遥不可及，但仍然是值得期待的。

搜索引擎是一种商业产品，其背后的公司依靠大部分依靠广告牟利。这是一种非常容易理解的商业模式，但是却造成了以下后果:

Too Big To Fail: 搜索引擎技术随着互联网规模的发展，会形成越来越高的技术壁垒。没有任何新公司能进入到这个市场。Google 目前占据着绝对主流，其他几家只占有微量的比例:
搜索引擎公司可以通过一些看似 公平的策略来调整不同网页的权重，从而来影响互联网的发展。比如 Google 一直在提高支持移动互联网网页的比重。这样的行为不能说是很坏，但是否应该由一家公司来做这些决定呢？
搜索引擎公司可以通过人为调整搜索结果顺序来牟利。比如毫无底线的百度。

信息时代人们对于信息检索的需求是非常庞大的，而且或许正如某些人所说，它不再是一个普通的商品，而是成为类似于水电一样的基础设施，每个人的生存都依赖于这些东西。在这种情况下，搜索技术再由某些垄断公司提供是不合适的，尤其是公司容易受到地缘政治的影响。Common Index 对此的提议是将搜索技术分为两层: 底层是通用的 index 技术，上层是各个公司的定制部分。

这里OWI 指 Open Web Index, 即本文一直说的 Common Index。Common Index 作为基础设施，提供基本的互联网索引，不同的商业机构可以基于此添加自己的特定的索引，并提供不同的界面以及功能。比如我可以实现一个专门搜书的搜索引擎，或者一个专门用来搜索特定某个人的公开信息的搜索引擎等等。Common Index 让新公司加入搜索引擎这个市场变得可能，并且可以通过差异化的服务来获取用户。有了这个基础，搜索引擎市场便有可能成为一个良性竞争的市场。

要想这个设想变成可能，操作起来是很麻烦的，所以很多类似的设想都只停留在设想阶段。我能想到两个问题便是:

谁来承担 Common Index 的成本？理论上可以应该让参与这个市场的公司来共同承担，想扶持本国在此方面有所发展的国家可以资助本国公司去参与这个市场。
如何打破现有市场的格局? 最理想的情况是，在未来的某一个天，通过反垄断法将 Google 拆分，分离出其部分index 技术作为 Common Index 的基础。

当然，希望在未来讨论这些问题的时候，百度已经不在了。

代码与注释

hang.yan@hotmail.com (涯余) — Sun, 14 Jul 2019 21:14:49 +0000

代码应该拥有良好的注释一直是业界共识，毕竟，在可预见的未来里，阅读代码的主要还是人。所有的语言都支持注释，有的拥有额外的注释提取工具及格式规范。但总体来说，大部分语言在这块做的都比较一般。Python有一些约定俗称的规范以及 Sphinx 这样的工具， Golang 的规范比较简单，但内置了 godoc 工具。Lisp 算是做的比较好的，示例如下：

(defun small-prime-number-p (n)
 "Return T if N, an integer, is a prime number. Otherwise, return NIL."
 (cond ((or (< n 2))
 nil)
 ((= n 2)
 t)
 ((divisorp 2 n)
 nil)
 (t
 (loop for i from 3 upto (sqrt n) by 2
 never (divisorp i n)))))

其独特之处在于，不同于一般语言注释位于函数体之外，而是将其放置于函数 body 开始处。这样开发者更容易将其当作函数定义的一部分，也有助于养成良好的注释习惯。

Golang 虽然在注释方面做的普通，但是在官方 library 以及最佳实践方面成功地鼓励了人们尽可能地写非常详细的注释，具体到一个 struct 的各个字段上。尤其是在 kubernetes 社区里面, 其Space Shuttle style 的 Code 对于社区的蓬勃发展可以说是一个极大的背后功臣，从如下的代码便可一窥其风格：

// Adapts a ConfigMap into a projected volume.
//
// The contents of the target ConfigMap's Data field will be presented in a
// projected volume as files using the keys in the Data field as the file names,
// unless the items element is populated with specific mappings of keys to paths.
// Note that this is identical to a configmap volume source without the default
// mode.
type ConfigMapProjection struct {
 LocalObjectReference
 // If unspecified, each key-value pair in the Data field of the referenced
 // ConfigMap will be projected into the volume as a file whose name is the
 // key and content is the value. If specified, the listed keys will be
 // projected into the specified paths, and unlisted keys will not be
 // present. If a key is specified which is not present in the ConfigMap,
 // the volume setup will error unless it is marked optional. Paths must be
 // relative and may not contain the '..' path or start with '..'.
 // +optional
 Items []KeyToPath
 // Specify whether the ConfigMap or it's keys must be defined
 // +optional
 Optional *bool
}

可读性越好的代码越容易流行。Golang 在这方面做的很好。

Knuth 曾经发明过一种将注释发挥到极致的语言风格: Literate Programming。结构很类似于 Tex 和 Markdown, 代码穿插于文档之中，工具可以分别提取出其中的文档与源代码。

\section{Hello world}

Today I awoke and decided to write
some code, so I started to write Hello World in \textsf C.

<<hello.c>>=
/*
 <<license>>
*/
#include <stdio.h>

int main(int argc, char *argv[]) {
 printf("Hello World!\n");
 return 0;
}
@
\noindent \ldots then I did the same in PHP.

<<hello.php>>=
<?php
 /*
 <<license>>
 */
 echo "Hello world!\n";
?>
@
\section{License}
Later the same day some lawyer reminded me about licenses.
So, here it is:

<<license>>=
This work is placed in the public domain.

虽然听起来跟普通语言差别不大，但是从如上的示例上看，其观感与普通的语言的差别非常之大。文档与代码拥有了同样的重要性。整个文件更像是作者一个思路的记录与阐释。这样的好处自然是在代码的可读性性上有一些独特的优势。但缺点也同样明显，已经有无数的人从各种角度对其进行了批评。最为显著的一个问题便是，作者选定了一种顺序方式来书写代码，但是人们阅读代码的顺序与习惯则是多种多样的。有的人想要完整地阅读代码，有的只想阅读某一个片段，不同的阅读顺序，频繁地跳转，都需要语言本身的支持。而 lierateing programming 并没有在这些方面有很好的方案。也许作为简短的代码说明是一个比较适合的场景。

Golang 1.9 Release Note

hang.yan@hotmail.com (涯余) — Mon, 27 May 2019 22:28:38 +0000

今天在翻存在 Pocket 里的文章，翻到一篇 Golang 1.9 的 Release Note。不得不说，Golang 在文档化上做的相当不错。对比其他语言来说，人们关注于每个版本的更新也会更多。不过这样的对比样本比较少，可能也不是很公正。Python 因为 2/3 版本的分离，可能很多人都不太关心 3 版本的更新。C/CPP 的文档一直比较欠缺，差距太大，而且版本之间迭代的也比较慢（历史包袱也多）。

现在 Golang 的版本已经到 1.13 了大概，2 的 design 也应该有不少文档。这样追下去应该有不少发现。利用语言的新特性来优化代码也是一件很有乐趣的事情。

1.9 新特性介绍

sync.Map

之前知道有这么个东西，但是自己在写代码的时候仍然没有将他作为一个默认的选项来考虑，仍然是自己加了 lock 手工实现，不得不说是一件很拙劣的事情。

type a struct {
 lock sync.RWMutex
 data map[string]interface{}
}

再加上一些自己实现的get/set函数。现在用一个普通的sync.Map即可。注释上说了它有自己的适用场景：

value 只写一次但是多次读
不同 goroutines 读写的数据不重合

即使这样，适用的场景还是挺多的。更少的代码，更好的性能，值得考虑。

Test

Golang 的 Test 包也包含了很多比较少见的的功能。借助 1.9 的 Release Note 看了下，也都是很实用的。

test.Helper()

在测试中我们经常需要写一些 helper function,这些函数是服务于真正的测试函数。如果它们出错并且打印出来，只能显示到 helper function 的文件名和行号。比如我们自己实现一个 assert 函数，查看错误就很不方便。而test.Helper()就是为了解决这个问题，当在 helper function 中打印具体的错误时，会显示的是调用者的文件名和行号，如下面例子所示:

package helper

import "testing"

func TestHelper(t *testing.T) {
 a := &asserter{T: t}
 a.Equal(1, 1)
 a.Equal(1, 2)
 a.Equal(1, 3)
}

type asserter struct {
 T *testing.T
}

func (m *asserter) Equal(a, b interface{}) {
 m.T.Helper()
 if a != b {
 m.T.Errorf("expected %#v (%T) was %#v (%T)", a, a, b, b)
 }
}

输出如下:

=== RUN TestHelper
--- FAIL: TestHelper (0.00s)
 run_test.go:8: expected 1 (int) was 2 (int)
 run_test.go:9: expected 1 (int) was 3 (int)
FAIL
exit status 1
FAIL github.com/tobstarr/gohelper 0.001s

Benchmark

Benchmark 类的测试在业务上可能用处不是很大，一般来说更适用于自定义的数据结构，比如 Golang 的标准包里的那些，需要严格测试其性能。在业务上，一般来说测试的都是具体业务逻辑，很多地方都是 mock，也没法直接测试性能，可能直接用集成测试更好。但是一旦有自定义的类似于标准包里的那些数据结构，还是挺合适的。

Examples

有点类似于简化版的 tests，但是可以用于 godoc 的展示。也是一个一般业务上不太用到的功能。

Subtests

应该推广的 table driven tests。基本上在一个 test 函数内需要多次对比结果的都应该这样写，在测试结果的输出上也更加清晰。不一定非要写成 for 循环的格式。

func TestFoo(t *testing.T) {
 // <setup code>
 t.Run("A=1", func(t *testing.T) { ... })
 t.Run("A=2", func(t *testing.T) { ... })
 t.Run("B=1", func(t *testing.T) { ... })
 // <tear-down code>
}

作为公共组件的 apiserver

hang.yan@hotmail.com (涯余) — Fri, 24 May 2019 15:54:47 +0000

PDF 文件在此: apiserver

起因是因为一个要做一个新的项目，在综合考量 kubernetes 的各个库之后，发现 kubernetes 已经从主项目中把很多可以复用的项目都单独移出来了。而且包含了很多通用性很强的代码。作为以 Golang + Kubernetes 为核心的架构，这些代码基本上可以充当公司内部的公共组件，省去了很多重复工作。

大部分公司都很少有这个意识，去尽量做好公共组件这块。业务需求本身占用了太多时间，这种属于内部架构的问题基本都是靠零星时间来改善。Kubernetes 这些项目不是说多好，而是它作为一个极其其庞大的项目，在开发的过程中自己造的轮子一般的公司都会有类似的需求。研究，拆解，复用这些公共代码，能够很大程度弥补上公司里公共技术这块的缺失。

公共代码越多，项目的相似程度也越高，维护及使用也越简单方便。

在 Kubernetes 中安装 Gitlab

hang.yan@hotmail.com (涯余) — Wed, 08 May 2019 13:36:33 +0000

现在很少写这种安装类的博客了。之前在公司部署了一个 Gitlab 作为日常使用，因为步骤比较繁琐。在此把零零散散的资料汇聚一下，记录一个比较完整的安装过程

环境

Kubernetes 1.13.1 三个高可用节点
每个节点上一个空余磁盘

步骤

安装 Rook

Rook 提供了基于 Ceph 的分布式存储，我们利用每个节点上的空余磁盘来支撑 Kubernetes 里的 PV/StorageClass 等

Helm 安装

首先，初始化磁盘

mkfs.ext4 /dev/vdb
mount /dev/vdb /var/lib/rook
mkdir /var/lib/rook
# TODO: add to /etc/fstab

然后通过 Helm 安装 Rook

helm repo add rook-stable https://charts.rook.io/stable
helm install --namespace rook-ceph-system rook-stable/rook-ceph

部署完成后可以看到rook-ceph-system Namespace 下运行的 Resource:

创建 CephCluster

#################################################################################
# This example first defines some necessary namespace and RBAC security objects.
# The actual Ceph Cluster CRD example can be found at the bottom of this example.
#################################################################################
apiVersion: v1
kind: Namespace
metadata:
 name: rook-ceph
---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: rook-ceph-osd
 namespace: rook-ceph
---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: rook-ceph-mgr
 namespace: rook-ceph
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-osd
 namespace: rook-ceph
rules:
- apiGroups: [""]
 resources: ["configmaps"]
 verbs: [ "get", "list", "watch", "create", "update", "delete" ]
---
# Aspects of ceph-mgr that require access to the system namespace
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr-system
 namespace: rook-ceph
rules:
- apiGroups:
 - ""
 resources:
 - configmaps
 verbs:
 - get
 - list
 - watch
---
# Aspects of ceph-mgr that operate within the cluster's namespace
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr
 namespace: rook-ceph
rules:
- apiGroups:
 - ""
 resources:
 - pods
 - services
 verbs:
 - get
 - list
 - watch
- apiGroups:
 - batch
 resources:
 - jobs
 verbs:
 - get
 - list
 - watch
 - create
 - update
 - delete
- apiGroups:
 - ceph.rook.io
 resources:
 - "*"
 verbs:
 - "*"
---
# Allow the operator to create resources in this cluster's namespace
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-cluster-mgmt
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: rook-ceph-cluster-mgmt
subjects:
- kind: ServiceAccount
 name: rook-ceph-system
 namespace: rook-ceph-system
---
# Allow the osd pods in this namespace to work with configmaps
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-osd
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: Role
 name: rook-ceph-osd
subjects:
- kind: ServiceAccount
 name: rook-ceph-osd
 namespace: rook-ceph
---
# Allow the ceph mgr to access the cluster-specific resources necessary for the mgr modules
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: Role
 name: rook-ceph-mgr
subjects:
- kind: ServiceAccount
 name: rook-ceph-mgr
 namespace: rook-ceph
---
# Allow the ceph mgr to access the rook system resources necessary for the mgr modules
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr-system
 namespace: rook-ceph-system
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: Role
 name: rook-ceph-mgr-system
subjects:
- kind: ServiceAccount
 name: rook-ceph-mgr
 namespace: rook-ceph
---
# Allow the ceph mgr to access cluster-wide resources necessary for the mgr modules
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr-cluster
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: rook-ceph-mgr-cluster
subjects:
- kind: ServiceAccount
 name: rook-ceph-mgr
 namespace: rook-ceph
---
#################################################################################
# The Ceph Cluster CRD example
#################################################################################
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
 name: rook-ceph
 namespace: rook-ceph
spec:
 cephVersion:
 # For the latest ceph images, see https://hub.docker.com/r/ceph/ceph/tags
 image: ceph/ceph:v13.2.2-20181023
 dataDirHostPath: /var/lib/rook
 mon:
 count: 3
 allowMultiplePerNode: true
 dashboard:
 enabled: true
 storage:
 useAllNodes: true
 useAllDevices: false
 config:
 databaseSizeMB: "1024"
 journalSizeMB: "1024"

这个 yaml 列表包含了如下的 Resource:

ns/rook-ceph
sa/rook-ceph/rook-ceph-mgr
role/rook-ceph/rook-ceph-osd
role/rook-ceph/rook-ceph-mgr-system
role/rook-ceph/rook-ceph-mgr
rolebinding/rook-ceph/rook-ceph-cluster-mgmt
rolebinding/rook-ceph/rook-ceph-osd
rolebinding/rook-ceph/rook-ceph-mgr-system
rolebinding/rook-ceph/rook-ceph-mgr-cluster
cephecluster/rook-ceph/rook-ceph

Helm Rook 里已经定义好了相关的 CRD,我们再这里就是要创建一个 CephCluster 的资源，可以看到它的 YAML 里指定了之前我们初始化好的/var/lib/rook目录。

kubectl create -f cluster.yaml

创建 StorageClass

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
 name: replicapool
 namespace: rook-ceph
spec:
 failureDomain: host
 replicated:
 size: 3
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: rook-ceph-block
provisioner: ceph.rook.io/block
parameters:
 blockPool: replicapool
 # The value of "clusterNamespace" MUST be the same as the one in which your rook cluster exist
 clusterNamespace: rook-ceph
 # Specify the filesystem type of the volume. If not specified, it will use `ext4`.
 fstype: xfs
# Optional, default reclaimPolicy is "Delete". Other options are: "Retain", "Recycle" as documented in https://kubernetes.io/docs/concepts/storage/storage-classes/
reclaimPolicy: Retain

页面

Rook 自带了一个 UI，我们可以通过 Ingress 配置的地址来访问和管理 Ceph 集群:

安装 Cert Manager

我们后面需要通过 HTTPS 访问 Gitlab/Rook 等，Cert Manager 与 Ingress 一起提供这个功能。

Helm 安装

wget https://github.com/helm/charts/blob/master/stable/cert-manager/cert-manager-v0.6.0-dev.5.tgz
helm install --name=cert-manager --namespace=kube-system ./cert-manager-v0.6.0-dev.5.tgz

创建 ClusterIssuer

ClusterIssuer 是 Cert Manager 提供的 CRD

apiVersion: v1
items:
- apiVersion: certmanager.k8s.io/v1alpha1
 kind: ClusterIssuer
 metadata:
 creationTimestamp: 2018-12-24T07:30:04Z
 generation: 1
 name: letsencrypt-prod
 namespace: ""
 resourceVersion: "2346374"
 selfLink: /apis/certmanager.k8s.io/v1alpha1/clusterissuers/letsencrypt-prod
 uid: bb17c08d-074d-11e9-9e39-525400f36999
 spec:
 acme:
 email: <your-email>
 http01: {}
 privateKeySecretRef:
 key: ""
 name: letsencrypt-prod
 server: https://acme-v02.api.letsencrypt.org/directory
 status:
 acme:
 uri: https://acme-v02.api.letsencrypt.org/acme/acct/48274855
 conditions:
 - lastTransitionTime: 2018-12-24T07:30:09Z
 message: The ACME account was registered with the ACME server
 reason: ACMEAccountRegistered
 status: "True"
 type: Ready
kind: List
metadata:
 resourceVersion: ""
 selfLink: ""

中间的<you-email>需要替换成具体的 Email。

安装 Gitlab

Helm 安装

Gitlab 也是需要通过 Helm 安装，但是需要自定义的变量比较多。

以下是 values 自定义的部分

redisImage: redis:3.2.10
redisDedicatedStorage: true
redisStorageSize: 5Gi
postgresImage: postgres:9.6.3
postgresStorageSize: 30Gi
gitlabRailsStorageSize: 70Gi
gitlabRegistryStorageSize: 70Gi
gitlabConfigStorageSize: 1Gi
baseDomain: <domain>
baseIP: <ip>
legoEmail: <your-email>
gitlabConfigStorageClass: rook-ceph-block
gitlabDataStorageClass: rook-ceph-block
gitlabRegistryStorageClass: rook-ceph-block
postgresStorageClass: rook-ceph-block
redisStorageClass: rook-ceph-block
gitlab: CE
gitlabCEImage: gitlab/gitlab-ce:11.6.5-ce.0
gitlabRunnerImage: gitlab/gitlab-runner:alpine-v11.6.1
runners:
 privileged: true
gitlab-runner:
 image: gitlab/gitlab-runner:alpine-v11.6.1

说明:

baseDomain/baseIP/legoEmail: 这几个需要根据具体情况替换
*Size: 这些变量的值就是我们安装的 Gitlab 所需要使用的空间，当然都是越大越好

Helm 安装:

helm install --name gitlab -f values.yaml gitlab/gitlab-omnibus --namespace=gitlab

修改 Ingress

之前已经安装了 Cert Manger,我们可以通过给 Gitlab 的 Ingress 添加如下的 Annotation 来支持 HTTPS

# kubectl edit ingress gitlab-gitlab -n gitlab
'certmanager.k8s.io/cluster-issuer: letsencrypt-prod'

我们可以通过 Ingress 看到，有以下四个域名可用了：

gitlab.aks.myalauda.cn: 主页面
registry.aks.myalauda.cn: 镜像仓库
mattermost.aks.myalauda.cn: 一个团队协作工具
prometheus.aks.myalauda.cn: 监控信息

权限相关

kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
 name: gitlab-cluster-admin
 subjects:
 - kind: ServiceAccount
 name: gitlab
 namespace: gitlab
 roleRef:
 kind: ClusterRole
 name: cluster-admin
 apiGroup: rbac.authorization.k8s.io

增加 Gitlab 的权限，不然可能会有未知的访问问题

Gitlab Runner 配置

让 Gitlab Runner 支持 docker-in-doker

cat >> /etc/gitlab-runner/config.toml << EOF
 [[runners.kubernetes.volumes.host_path]]
 name = "docker"
 path = "/var/run/docker.sock"
 mount_path = "/var/run/docker.sock"
 read_only = false
 EOF

这个是通过修改 configmaps/gitlab/gitlab-gitlab-runner 实现:

安装 SonarQube

SonarQube 可以提供对多种语言的代码静态分析，它自身是一个 Server，带页面，也支持各种插件。与 Gitlab 的集成是通过 Gitlab Account 以及 Token 等方式实现。

YAML 安装

以下是相关 YAML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: sonar-data
spec:
 accessModes:
 - ReadWriteOnce
 storageClassName: rook-ceph-block
 resources:
 requests:
 storage: 10Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: sonar-extensions
spec:
 accessModes:
 - ReadWriteOnce
 storageClassName: rook-ceph-block
 resources:
 requests:
 storage: 1Gi
---
apiVersion: v1
kind: Secret
metadata:
 name: postgres
type: Opaque
data:
 password: NDl1ZjNtenMxcWR6NXZnbw==
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 labels:
 app: sonarqube
 name: sonarqube
spec:
 replicas: 1
 template:
 metadata:
 labels:
 app: sonarqube
 spec:
 containers:
 - name: sonarqube
 image: sonarqube:7.1
 resources:
 requests:
 cpu: 500m
 memory: 1024Mi
 limits:
 cpu: 2000m
 memory: 2048Mi
 volumeMounts:
 - mountPath: "/opt/sonarqube/data/"
 name: sonar-data
 - mountPath: "/opt/sonarqube/extensions/"
 name: sonar-extensions
 env:
 - name: "SONARQUBE_JDBC_USERNAME"
 value: "gitlab"
 - name: "SONARQUBE_JDBC_URL"
 value: "jdbc:postgresql://gitlab-gitlab-postgresql.gitlab/sonar"
 - name: "SONARQUBE_JDBC_PASSWORD"
 valueFrom:
 secretKeyRef:
 name: postgres
 key: password
 ports:
 - containerPort: 9000
 protocol: TCP
 volumes:
 - name: sonar-data
 persistentVolumeClaim:
 claimName: sonar-data
 - name: sonar-extensions
 persistentVolumeClaim:
 claimName: sonar-extensions
---
apiVersion: v1
kind: Service
metadata:
 labels:
 app: sonarqube
 name: sonarqube
spec:
 ports:
 - name: sonar
 port: 80
 protocol: TCP
 targetPort: 9000
 selector:
 app: sonarqube
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 annotations:
 certmanager.k8s.io/cluster-issuer: letsencrypt-prod
 kubernetes.io/ingress.class: nginx
 kubernetes.io/tls-acme: "true"
 name: sq
spec:
 rules:
 - host: <sonarqube-host>
 http:
 paths:
 - backend:
 serviceName: sonarqube
 servicePort: 80
 tls:
 - hosts:
 -  <sonarqube-host>
 secretName: sonar
status:
 loadBalancer:
 ingress:
 - {}

包含如下资源:

两个 PVC 分别用于存放 SonarQube 自身的数据以及插件的数据
Service/Ingress: 这部分类似于 Gitlab 自身的配置

需要注意的是，因为 SonarQube 自身需要 DB,而我们在 Gitlab 安装的时候已经部署了 DB,所以可以继续复用

以上资源最好也都单独放在一个 NS 下面，比如

kubectl apply -f sq.yaml -n sq

结果如图所示：

DB 配置

在 Gitlab 的 DB 中创建 sonar DB

CREATE DATABASE sonar WITH OWNER gitlab;

数据库的名字需要与上面 SonarQube 的 Deployment YAML 中的 JDBC 地址一致。

安装插件

需要安装一下几个插件

bitbucket oauth: 用于支持 Bitbucket 登录
git: git 支持
go: Golang 语言的分析支持
gitlab: 与 Gitlab 集成

我们可以通过 SonarQube 的页面安装，也可以直接用 wget 下载到相应的目录中。如下的两个 Gitlab 插件就只能通过下载安装：

# kubectl exec to sonarqube pod
wget https://github.com/gabrie-allaigre/sonar-auth-gitlab-plugin/releases/download/1.0.0/sonar-auth-gitlab-plugin-1.0.0.jar
wget https://github.com/gabrie-allaigre/sonar-gitlab-plugin/releases/download/4.0.0/sonar-gitlab-plugin-4.0.0.jar

设置 Bitbucket 登录

之前已经配置过 Bitbucket 的 OAuth 信息，这里可以复用。需要在 SonarQube 配置好以下参数:

sonar.core.serverBaseURL

集成

Bitbucket

通过 OAuth 的方式与 Bitbucket 集成，首先需要在 Bitbucket 的页面配置相关的 id/secret 等，然后更新 gitlab-gitlab 的 Deployment:

gitlab_rails['omniauth_providers'] = [{"name" => "bitbucket","app_id" => "<id>", "app_secret" => "<token>","url" => "https://bitbucket.org/"}]

如图所示，Gitlab 将大部分配置存储于其 Deployment 的一个 ENV 中，各种自定义配置都可以通过修改这个环境变量实现。

SonarQube

用户配置

我们需要在 Gitlab 添加一个 SonarQube 的用户，并赋予相应的权限，这样他可以在 MR 上添加分析的结果。同时也要在 SonarQube 上添加一个 Gitlab 用户，用于上报分析结果给 SonarQube。

项目配置

在实际的项目中，我们需要有一个配置文件，主要用来指明一些具体的分析规则，如下是一个示例

sonar.projectKey=<project_name>
sonar.projectName=<project_name>
sonar.projectVersion=0.1
sonar.login=<username>
sonar.password=<token>
sonar.scm.provider=git
# GoLint report path, default value is report.xml
# TODO: add back
# sonar.golint.reportPath=report.xml
# Cobertura like coverage report path, default value is coverage.xml
sonar.typescript.lcov.reportPaths=lcov.info
# if you want disabled the DTD verification for a proxy problem for example, true by default
sonar.coverage.dtdVerification=false
# JUnit like test report, default value is test.xml
sonar.test.reportPath=test-reports/junit.xml
sonar.sources=.
sonar.test=.
sonar.test.inclusions=./**/*_test.go
sonar.test.exclusions=./vendor/**
sonar.go.coverage.reportPaths=coverage.out
# Ignore duplicating string literal issue
sonar.issue.ignore.multicriteria=e1
sonar.issue.ignore.multicriteria.e1.ruleKey=go:S1192

需要注意的地方:

project_name: 这个需要在 SonarQube 的页面预先创建好对应的项目
username/token: 配置的用于访问 SonarQube 的用户和 Token

CI 配置

在 CI 中，我们可以专门增加一个 Stage 用于代码分析:

sonarqube:
 only:
 - merge_requests
 stage: analysis
 image: ciricihq/gitlab-sonar-scanner
 dependencies:
 - unit-test
 variables:
 SONAR_URL: <url>
 SONAR_ANALYSIS_MODE: preview
 SONAR_GITLAB_PROJECT_ID: <project_id>
 script:
 - gitlab-sonar-scanner

sonarqube-reports:
 only:
 - master
 stage: analysis
 image: ciricihq/gitlab-sonar-scanner
 variables:
 SONAR_URL: <url>
 SONAR_ANALYSIS_MODE: publish
 script:
 - gitlab-sonar-scanner

其中url指 SonarQube 的访问地址, project_id指 Gitlab 项目的 ID，一般用 <group>/<project>即可。上面的两个 Job 作用不同，sonarqube用于分析并且添加 Comment, sonarqube-reports用于分析并且上报结果到 SonarQube。

最终效果如下:

如果有错误，Comment 中也会详细列出来并可以跳转到具体的 SonarQube 页面查看。

邮箱

Gitlab 发送邮箱的部分也是需要自己配置，和上面对 Bitbucket 的 OAuth 配置一样，直接 edit 其 Deployment 即可。示例配置如下：

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.office365.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "<email>"
gitlab_rails['smtp_password'] = "<password>"
gitlab_rails['smtp_domain'] = "<domain>"
gitlab_rails['gitlab_email_from'] = '<email>'
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

JIRA

Gitlab 目前与 Jira 的关联还比较弱，我们可以在 Gitlab 的 Service Templates 里配置好具体的 JIRA 地址，然后在 Commit Message 里关联上相关的 JIRA ID。这里也需要在 JIRA 上创建相应的 Gitlab 用户，这样我们提交的 MR 与 JIRA 的关联就可以在 JIRA 的页面自动展示出来。

当然另一方面，我们也可以利用 Webhook + JIRA SDK，来实现一个 WebHook，通过在 Commit Message 里增加相应的动作来驱动 JIRA 状态的变更，这个可以根据具体的业务情况用 Python 脚本很容地实现。

Danger

请见本站关于 Danger 与 Gitlab 的集成相关的文章

TODO: 增加 Link

使用

LGTM

Gitlab CE 因为砍掉了很多 EE 版本的功能，没有像 GITHUB 那样的通过 /lgtm或者LGTM这样的关键词来自动合并 MR。这个也可以通过部署一个简单的 Server 来作为 Webhook 实现。再通过增加一个MergeBot用户来执行合并的动作，能够极大地简化我们的代码合并流程。

CI/CD

敏感信息

CI/CD 中要使用很多 password/token 等敏感信息，直接放在 CI 文件中并且保存在 Git 仓库中是非常不安全的，Gitlab 的 CI 提供了 Pipeline 的环境配置信息，将敏感信息存储在 Gitlab，可以在 ci 文件中直接引用:

Badges

Badges 的配置是在项目上的，不用在项目的 Readme 等文件中插入什么信息。这点是比较好的。目前 CE 版本支持 Build 状态以及单元测试覆盖率等，一般情况下是够用的。也可以增加第三方的 Badge 地址.

CLI 直接创建 MR

Gitlab CE 的比较新的版本里已经支持从命令行 Push 的时候直接创建 Merge Request 了，这也是一个非常好用的功能。最简单的方式就是在 Push 后面增加参数:

git push origin <branch> -o merge_request.create

其他的参数可参考官方文档使用。

升级

因为 Gitlab 的功能更新比较频繁，我们可以经常性地更新 Gitlab 的版本，也是通过直接 edit deployment，更新镜像版本字段即可。当然因为是单实例的服务，会有几分钟的服务中断，影响也不大。需要注意的是 runner 的版本也需要同步更新。

在 Gitlab 中使用 Danger

hang.yan@hotmail.com (涯余) — Tue, 07 May 2019 23:23:52 +0000

Gitlab 社区版的 CI 功能非常好用，能够很方便的地做到代码的 lint/build/test/等等。不过社区版在多人协作上(比如 Merge Request)上阉割了不少功能，比如将 MR assign 给多人等。通常来说，在代码合并这块，CI/CD 一般包括两部分: 代码本身以及 MR/PR 本身。Danger 这个工具正好可以补足 Gitlab 在后者的不足。

功能

Gitlab CI 的关注点在于提交的代码本身，而 Danger 的关注点在于 Merge Request 本身，当然也可以做到很多 Gitlab CI 能做到的事情，各种第三方插件也能极大地扩种 Danger 自身的能力。目前我觉得几个非常有用的功能是：

检查 Commit Message 的格式。这个功能是很基本的，但是很多 CI 系统本身都不支持。
检查与 jira 的关联。强制让每一个 MR 都关联一个 jira,方便项目管理
检查 MR 是否打标签。在 MR 非常多的时候用于给 MR 归类，在 Github 上的大项目上我们经常见到
检查 MR 的大小。改动太大的 MR 是不推荐的，因为 Review 起来难度太大，推荐分裂成比较小的 MR
检查是否 rebase 过了目标分支,保持一个干净的提交记录。

安装

因为 MR 本身属于 Git 系统的一个功能，所以 Danger 的一个主要能力在于与各大平台的集成性上,目前主流的 Gitlab/Github/都支持。也很容易部署。下面简要介绍与 Gitlab 的集成方法

创建用户

创建一个新的用户，给予目标 Group 的 Reporter 权限
生成一个具有 API 访问权限的 TOKEN，并且在目标项目的 CI/CD 配置里加到环境变量里: DANGER_GITLAB_API_TOKEN

添加 Danger 到 Gitlab CI 文件中

一个示例如下：

danger:
 only:
 - merge_requests
 stage: pre
 image: hangyan/danger
 script:
 - danger --fail-on-errors=true

将其放在一个单独的 stage 中，一般在 MR 最开始的时候运行。hangyan/danger镜像的 Dockerfile 如下:

FROM ruby:2.4.1
MAINTAINER hangyan <hangyan@hotmail.com>

RUN gem install danger-gitlab danger-jira danger-commit_lint

RUN danger --version

ENTRYPOINT ["danger"]

内容比较简单，安装了三个包

danger-gitlab: danger 本身
danger-jira: 检查与 jira 的关联
danger-commit_lint: 检查 Commit Message

添加 Dangerfile

Dangerfile 本身是一个 ruby 文件，作为配置文件来说有一定的学习成本，但一般的简单配置官网都可以找到示例。下面是一个 Example Config:

# check milestone
has_milestone = gitlab.mr_json["milestone"] != nil
warn("This MR does not refer to an existing milestone", sticky: true) unless has_milestone

# check label
failure "Please add labels to this MR" if gitlab.mr_labels.empty?


# check jira
jira.check(
 key: ["DEV", "INCI"],
 url: "http://jira.alaudatech.com/browse",
 search_title: true,
 search_commits: true,
 fail_on_warning: true,
 report_missing: true,
 skippable: true
)


# Ensure a clean commits history
if git.commits.any? { |c| c.message =~ /^Merge branch/ }
 fail('Please rebase to get rid of the merge commits in this PR')
end


# Warn when there is a big PR
warn("Big PR, try to keep changes smaller if you can") if git.lines_of_code > 500


# commit message
commit_lint.check

每一部分都有响应的注释。

效果

少有人用的 debugger

hang.yan@hotmail.com (涯余) — Mon, 06 May 2019 11:32:22 +0000

不知道别人是怎么认为的，我之前一直认为，Debugger 应该是一个正统的解决软件问题的方式。我们应该尽力地去多用这种方式，通过各种其他的 print 等方式是一种原始的，偷懒的，笨拙的方法。

我也总是去尝试学习各种 debugger 以及在工作中去使用它们，但都是很难进行下去。真实的工作场景中也鲜有人用 debugger。是大家都在逃避问题，投机取巧吗？

今天看的几篇文章让我明白了，debugger 并不是什么正统，而是一种适用范围非常狭窄，应该尽量少用的方式。用 print 之类的笨办法是应该的，值得推荐的。

Linux 在邮件列表里表达的对于在内核开发中使用 debugger 的看法也很适用于通用软件的场景:

It's partly "source vs binary", but it's more than that. It's not that you
have to look at the sources (of course you have to - and any good debugger
will make that _easy_). It's that you have to look at the level _above_
sources. At the meaning of things. Without a debugger, you basically have
to go the next step: understand what the program does. Not just that
particular line.

相对来说，debugger 本身更像是对问题的逃避，我们放弃对于问题以及代码更为细致的观察与思索，直接交给程序来一行一行校验代码的正确性。而在没有 debugger 的场景下，我们需要花费更多的时间来思考整个程序的设计，自上而下地考量整个问题以及解决的方式对不对，最终的困惑可以通过 print/system tools 等工具结合起来去校验。通过这种方式，最终对问题的解决可能并不是对于现有某些代码的修改，而是对于代码整体的重构与调整。

从开发的趋势来看，软件会变得越来越复杂，多线程、多核，分布式、微服务等等架构会越来越占据主流。这些新的软件架构在出现问题时所要求的 debug 工具是多种多样的，从最基本的代码加 print，利用监控系统, 生成火焰图等等。我们需要的是一种福尔摩斯式的纯思维逻辑的推理: 问题在哪？有哪些可能的地方引起的? 怎么去验证每一个可能？用什么工具最合适？在解决完错误之后，我们需要额外地去思考: 软件的设计是否合理？是否需要加更多的 trace 信息? 日志够不够？等等。而 debugger 在这其中扮演的角色只会越来越狭窄, 因为它在这些方面几乎没有可扩展性。

另一个问题在于语言本身。对于 C/CPP 社区来说，有 GDB 这样强大的工具可用。而对于像 Python/Golang 以及其他新兴的语言来说，并没有如此强大的 debugger。即使已经开发出了不少新的替代品，但他们无法在程序员心中有同样的地位。任何功能的缺失都无法让开发者信任这样的软件。

对于开发者来说，我觉得可以忘掉有 debugger 这个东西存在，除了本身的逻辑思维能力以及经验累积等方面的提升之外，我觉得可以关注以下的工具:

service mesh
监控系统
日志系统
系统工具的组合利用
火焰图
opentrace
…

jekyll 的问题

hang.yan@hotmail.com (涯余) — Sun, 05 May 2019 13:14:29 +0000

考虑良久，决定将 Blog 迁移到 hexo。整个过程比想象的简单很多，也看了下二者的异同。相对于来讲，我觉得 hexo 在设计上比 jekyll 更为优良一些，更适合作为一个静态博客生成器。那么，jekyll 的问题在哪?

目录结构

jekyll 的目录结构是 posts/themes/settings 等杂糅在一起，初看起来更好理解，但使用起来是很痛苦的。尤其是在更换 theme 的时候，需要小心翼翼地甄别哪些目录需要更换而哪些不需要。而 hexo 的目录结构更加清晰，每个 themes 的内容都包含在一个单独的目录中，与其他部分互不干扰。想要更换 theme 直接 clone 一个新的改一个配置参数即可。

更换 theme 的次数越多，jekyll 的目录结构会越来越乱，分不清哪些文件是当前必须的。而 hexo 没这个问题。

默认主题

jekyll 没有默认主题。或者说有，但大家不这样用。通常的用法都是找一个现成的第三方 blog clone 下来，然后按自己的需求改。这样有个问题就是，总会有一种不适配的感觉。因为主题都是别人为自己的使用配置的。而 hexo 提供了默认的主题，它是这个软件自带的一部分，是理所应当的属于我们自身的。而且这个默认的主题已经足够好用，同时第三方的next主题也占据了相当大的份额。不是说选择少，而是在 hexo 上能够更快地完成theme配置这一环而专注于内容。

功能

jekyll 各个 theme 的功能丰富程度差别很大，分页、评论、TAG 等等。不同主题想要添加新功能的方式不同，遇到问题处理的简易程度也不一样。而这种情况也往往导致用户会选择更换主题，然后继续恶性循环。hexo 的默认主题提供了对大多数常用功能的支持，而扩充起来也比较方便，不同主题在这块的差别也比较小。

内容发布

这块 jekyll 完全没做，必须得自己手动创建 md，添加头部的 attribute,之前还借鉴了其他人的 shell 脚本来根据模板自动生成这些内容。而 hexo 提供了new命令来创建新的 post,自动补上头部的内容，这样学习成本基本上就只剩 markdown 了。

目前静态博客软件的内容发布还是太偏程序员化了，可以参考 wordpress 的地方还有很多。目前已经有一些 admin 页面的项目流行起来，但还没有达到能让普通用户无学习成本使用的程度。

其他

目前静态博客的分化是好事，但有点像 linux distros 那样，最终也带来了很多恶性循环。大家不关注易用性去普及用户，而更关注彼此设计理念的不同。一堆程序员圈地自嗨，最终可能只是落得自娱自乐罢了。

如何防止代码变成 SHIT

hang.yan@hotmail.com (涯余) — Wed, 01 May 2019 19:03:04 +0000

最近发现之前写过的很多项目，不管是 python/go/cpp 的，最终回看起来代码都变的很难看，尤其是多人合作的时候。这是一个很头疼的问题。自己平时很在意这个，但是代码最终确都变成了 shit。

问题

当一个人开发的时候，问题主要在于一个人的自律性不够强，不管是代码注释等都是随意写的，即使偶尔意识到了问题，但也难以保证能一直坚持下去。而当人多的时候，问题经常处在多人风格的不同上。如果没有工具来强制大家遵守一定的规则，那么大家每个人自己的风格放在一起的时候，就成了垃圾代码。避免代码变成 shit 的唯一方法，就是让大家写的代码看起来都一个样。而这个工作除了由开发人员的 Code Review 之外，还需要工具来约束。

解决方法

CI/CD

最开始接触 CI/CD，我只是认为它主要是用于部署方面的一个工具。现在发现，它对于代码质量的改进也是意义巨大的。所有代码通用规范上的约束，静态分析，复杂度分析等都可以通过自动化工具来执行。一方面，我们可以组合尽可能多的代码静态分析工具，来约束提交代码的错误，提供代码改进的建议，形成统一的代码风格。另一方面，最于 Code Review 来说，不再需要关注基本的代码风格以及基础部分，而只用关注于具体的业务以及代码架构层面的问题。

静态分析

Python 这样的代码，在多人合作的大型项目上，如果没有非常严格的代码约束，最终出来的项目时非常难以维护的。可能经常部署出来的代码连跑都跑不起来。相对来说，静态类型语言在这方面的优势是巨大的，编译器在编译代码阶段能发现大多数比较明显的问题，最终线上的问题一般都是需要人来参与分析的。

代码的静态分析是一个非常古老但是重视程度不够的技术。静态类型语言的代码分析技术能够极大地减少代码中可能存在的 bug,并给出很多的建议。以 Golang 为例，目前已经有几十款静态分析工具。而像golangci-lint这样的工具，可以将多种分析工具结合起来，在各个层面给出代码改进的建议。比如：

代码的简化写法
可能的 bug
Dead Code
未使用的或者被覆盖的变量
…

SonarQube 其实是类似的产品，只不过是 Client/Server 的架构，提供了诸如复杂度分析，单元测试覆盖率等指标。良好的 UI，以及插件式的架构，与普通的 cli 工具结合起来之后，对于代码质量的提高是非常有益的。

总之，工具能处理的事情越多，人的精力就更多的能去关注更上的层面和业务层面。

Code Review

Code Review 虽然成为一个共识，但真正的效率确实难以保证的。莫名其妙的改动，形式化的 approve,现有工具的局限等等问题都造成了参与的人在这方面的低效率。所以总是需要有各种规范来指导人们如何进行 Code Review。一般来讲，我们可以将代码的改动拆分为三个问题

Why? 为什么要做这个改动
How? 怎么做这个改动
What? 具体做了哪些改动。

这几个问题，工具能参与的只是What的一部分。其他的部分都需要人来 review。一般的 Code Review 提交的模板也都要求提交 PR 的人尽量说清楚 Why,通过文档 link 或者文字等形式。具体的 How 以及 What，则需要具体的人来参与 review。

单元测试

曾经我对于单元测试是非常反感的,现在的仍然觉得它的作用有限，只是我们没有其他选择，只能继续用它。它的作用主要在于：当我们添加代码时，能保证我们的代码不 break 已有的逻辑。为了这个目标，付出的代码是巨大的，庞大的单元测试框架以及体系，高昂的维护成本，以及可能对现有代码的侵入性，换来的是一种非常被动的 protection。

当然单元测试对于代码的反向的结构优化也是有意义的。在让代码结构变得可单元测试的过程中，代码也变得更加易维护以及模块化。希望以后有更简单的方式来达成这个目的而不用承受目前单元测试框架的沉重负担。

人的因素

上面说了那么多，其实都只是为了保证代码的烂有一个下限，但代码仍然可能是 shit。问题的核心，不是技术，而是政治学(说的通俗点的就是管理问题。) 代码质量好的项目，这么几十年来，经验告诉我们，只有两种: 仁慈的独裁者(比如 Guido)和骂人的独裁者(比如 Linux)。这样最终多人的协作问题最终就变成了一个 leader 自身的品味问题。品味好的人虽然很少，但不是没有。

Linux 的脾气以及 RMS 的偏执，初看起来都很不近人情，但他们都在维护问题的核心:代码的质量以及软件的自由，任何其他的因素不管听起来多么冠冕堂皇，都是次要的，不应凌驾于核心之上。

这很像民主制度一样面临的问题。它防止了最坏的恶，但因为没法保证每个人都是精英，所以在协作的产出上总是低效和质量差的。而专制制度在牺牲了大多数的自由之后，如果有一个良好的领导者，则是目前已知的最有效的政治制度。毕竟，结果最重要。

JFFS3 文件系统

hang.yan@hotmail.com (涯余) — Sat, 20 Apr 2019 22:35:17 +0800

看完了闪存,继续看文件系统。网上搜了一圈，发现都是讲 Andriod 的目录结构的，讲文件系统本身的少。目前能确认的是历史上曾经用过 ext4,yaffs,yaffs2 等。估计目前主流的应该是 ext4。不过在搜索的时候先发现了一篇讲 jffs3 的，它在嵌入式系统上应用比较广泛，也是针对 Flash 存储特定设计的文件系统。不太确定现在的使用范围，但是拿出来研究下还是不错的。

闪存对文件系统的影响

闪存跟磁盘有很多不同的地方，在设计文件系统的时候，二者有很多不同的考量。简单的对比表格如下

	闪存	磁盘
最小寻址单位(读)	字节	扇区
最小寻址单位(写)	NOR FLASH 是字节，NAND FLASH 是页，擦除是块	扇区
寿命	由擦写块的最大可擦写次数	机械故障

闪存的这些特性，导致我们在设计文件系统的时候，必须考虑以下的问题：

out of place update: 对于磁盘来讲，我们更新数据可以直接原地更新。但是闪存不行，因为无法将 bit 位从 0 -> 1。所以对于闪存的数据更新只能是在另外一个地方写入数据，然后将原数据标记为 dirty,再通过 GC 来定期回收.
wear leveling: 磨损平衡。闪存的使用寿命是由擦写块的最大可擦写次数来决定的。超过了最大可擦写次数，这个擦写块就成为坏块(bad block)了。因此为了避免某个擦写块被过度擦写，以至于它先于其他的擦写块达到最大可擦写次数，我们应该在尽量小的影响性能的前提下，使擦写操作均匀的分布在每个擦写块上

闪存转换层

为了能让普通的文件系统(磁盘上的)能够在闪存上正常运行，需要有一个转换层：Flash Translation Layer（FTL）。它的功能就是将底层的闪存模拟成一个具有 512 字节扇区大小的标准块设备(block device)。对于文件系统来说，就像工作在一个普通的块设备上一样，没有任何的差别。

基本的实现思路就是对磁盘的扇区和闪存的块做映射。当上层的文件系统要写一个块设备的扇区时，闪存转换层要做下面的操作来完成这个写请求：

将这个扇区所在擦写块地数据读到内存中，放在缓存(buffer)中
将缓存中与这个扇区对应的内容用新的内容替换掉
对该擦写块执行擦写操作
将缓冲中的数据写回该擦写块

这种实现方式的缺点是很明显的：

效率低，对一个扇区的更新要重写整个擦写块上的数据，造成数据带宽很大的浪费。
没有提供磨损平衡，那些被频繁更新的数据所在擦写块将首先变成坏块。
非常不安全，很容易引起数据的丢失。如果在上面的第三步和第四步之间发生了突然掉电(power loss)，那么整个擦写块中的数据就全部丢失了。这在突然掉电经常发生的嵌入式系统中是不能接受的。

当然，实际的 FTL 肯定不是这么简单，需要对这种模式做很多的优化。但不论怎么优化，性能以及可靠性上都不算很好。最终还是需要专门针对闪存的文件系统。

JFFS3

JFFS 的全称是Journalling Flash File System，有 JFFS3 肯定也有 JFFS2 以及 JFFS，只不过不是本文关注的重点。JFFS3 的存在本来也是为了解决 JFFS2 的一些问题，所以肯定也会附带介绍到。从其名字可以看出，重点是journal。JFFS 文件系统整体可以看作一个大的日志(跟 LSM 有点像),根源就是上面所说的out of place update, 更新和新加数据都是不断地 append -> mark dirty -> gc 的过程。

JFFS2 的问题

对于文件系统来说,index都是非常重要的一环。index 能让我们更快地定位到文件和数据，其维护和更新也是文件系统设计的核心。JFFS2 将 index 放在了 RAM 中，很特殊，有很多优势,也是它很多问题的根源。在比较小的闪存上，它的吞度量和性能很好，因为 index 的更新都是在内存中。但是闪存的容量越来越大，问题也就越来越凸显了:

挂载时，JFFS2 需要扫描整个闪存来建立 index, O(S)的复杂度，闪存容量越大，挂载越慢
同样的，闪存越大，index 越大，内存占用越大。同样是 O(S)

除开这些缺点，其优势也是很多的

index 不占用闪存空间
吞吐量高
磨损平衡好,因为更新比较频繁的 index 都在内存中了
…

Index 的存储

JFFS3 的解决方式将 index 从 RAM 放回到闪存上，相当于基本上是重新设计了。这样就解决了 JFFS2 挂载慢的问题,因为不用每次重新在内存中 build index 了。index 放到闪存上面临的第一个问题就是更新数据时引起的 index 的连锁更新，如下图所示:

index 以一个树的结构存在，leaf node 存储最终的数据。假设我们要更新 H,需要在一个新地方写一个 H1,那么指向 H 的 F 以及指向 F 的 A（root）都需要更新，他们的更新也是在一个新地方写数据。JFFS2 因为是在 RAM 中存储了 index,可以原地更新，所以没有这个问题。一旦放到闪存中，这种连锁更新就很难避免了。这种实现方式有个名字叫Wandering tree。

显而易见，树的 level 越多，这种方式的效果就越不好。用 B+树来实现是一个非常自然的选择。JFFS3 中所有的对象都是存在一个大 B+树上，index、数据、文件、目录、属性等等。每一个对象都有一个 key，查询的时候就用这个 key 来查询。

leaf node 存储了真正的数据，其他的 index node 存储的都是 index 信息。

The Journal

Wandering tree 的代价还是挺大的。JFFS3 在设计时参考了 JFFS2 的思路在内存中实现了一种cache来尽量避免这种高频次的更新。这种方式叫做journal（名字起的很不好）

在闪存上预留一些 block 作为 journal eraseblock,当有数据更新时，数据更新到这些 block 上，但是 index 在内存中更新，暂时不修改闪存上的 index。当有读取请求时，先看下内存中的 index(叫The journal tree),如果有那就用，没有的话就去闪存的 index 查。the journal tree 可以在合适的时机同步到闪存的 index 中。这样做的好处很多:

避免了 wandering tree 的昂贵开销，因为可以合并很多 index update
平衡损耗也很好。JFFS3 可以用比较好的算法来自己挑选 journal eraseblock

坏处也有，跟 JFFS2 一样，挂载的时候，如果想提前尽可能多的生成 the journal tree 来提升性能，势必会增加挂载时间，一个权衡的问题。

Garbage collection

跟 JFFS2 一样，整体思路都是将有效数据挪到别的地方，然后更新 index。JFFS3 因为 index 在闪存上，实现起来更为复杂些。而且会碰到一个尴尬的问题，因为更新 index 也需要写新的数据，有可能在 GC 的过程中产生的垃圾数据比回收的更多。。。

如上图所示，为了回收 1 中的一块数据，最终产生了 2 中三倍的垃圾数据。原论文直接跳过了这个问题，说是仍在开发中，没有特别好的解决方案。暂时也没有找到引用比较高的研究这个问题的论文。

Superblock

superblock 也是文件系统很重要的一环，可以说是 metadata 的 metadata。JFFS3 将 superblock 分为了两部分:

static superblock: 固定不变的基本信息，放在第一个 eraseblock 中
superblock: 经常更新的信息

superblock 的位置是不固定的，原因也是因为不能原地更新。JFFS3 在这块的设计也是相当的复杂:

anchor area 的位置是固定的，就是 JFFS3 的第 2,3 个 earseblock,其他的 chain earblock 和 super eraseblock 都是会一直更新的。通过这个链条可以就可以找到 superblock。真正的 superblock 数据只占一个 sector，所有的指针也只占一个 sector，每个 eraseblock 包含 N 个 sector，每一次的闪存数据更新,superblock 都会更新, N 次 superblock 更新会导致上一个 chain eraseblock 更新，依次类推一直到 anchor area 的更新。

这里就有一个必须解决的问题: 在可擦除的次数用尽之前，ancher area 必须比 data area 能用的时间更长。不然到某个时刻数据更新时会发现 ancher area 已经无法更新了。这个问题涉及到了几个变量:

每个 eraseblock 包含的 selector 数量 N
chain 的长度 m
闪存可用的 eraseblock 的数量 M

具体这几个参数怎么设置来保证这个基本原则论文中已经有详细介绍，本文不再赘述。但可能简单推理这几个变量的变化对于结果的影响。

N 越大，这样 ancher area 的变动频率越低
m 越大，ancher area 的变动频率越低

举个例子，目前 N=64, m=3 已经能支撑 128G 的闪存了。更大的容量需要更大的 N,m 参数。

闪存

hang.yan@hotmail.com (涯余) — Thu, 18 Apr 2019 21:01:13 +0800

本来看华为新弄了 FS 和编译器，想学习下。但是目前似乎放出来的技术资料并不多，就先做下技术储备。先研究下他们做这个优化的历史背景。一路看下来发现链路太长，EXT4、更早的文件系统、最后到了闪存。大学课堂上学过，但到现在真要考我，估计也说不出个所以然，所以先记录下闪存相关的笔记。

基本定义

ROM 的一种，虽然看着是read only，但是闪存属于的细分类别已经可以允许重写数据(EEPROM)。比较接近的两种细分类别对比来看：

EPROM: 需要用紫外线照射才能重写数据(注定要被淘汰的技术)
EEPROM: 多的一个E便是Electrically，可以用电擦除数据

自然 EEPROM 的应用更加广泛。目前手机上的存储主要就是闪存（EEPROM)。闪存用于手机等移动设备的一些原因如下:

动态抗震性好(没有机械部件)
极端环境下也比较可靠(手机三防)
在擦除数据时比一般的 EEPROM 效率更高(区块对字节)

NOR / NAND

两种 flash 的类型，直接上一个比较简单的表格对比：

	NOR	NAND
抹写速度	慢	快
抹写次数	低	高 (10x)
存取方式	随机	区块
成本	高	低
面积	大	小
适用场景	微处理器	普通存储
实际使用	BIOS/机顶盒	U 盘/SSD

写/擦除

这也是一个容易忽略但是细究起来很容易让人迷惑的东西。为什么闪存有擦除的概念? 简单来讲，由于闪存特殊的物理构造，可以理解为写操作只能写入0,擦除操作相当于写入1。手机闪存和固态硬盘为什么擦除多了会损坏？这篇文章提供了具体的电路图示意：

这个是写操作，控制栅加正电压，将电子（带负电）吸入浮动栅。在此后，由于浮动栅上下的二氧化硅材料并不导电，这些电子被囚禁（Trap）在浮动栅之中，出不去了。这样无论今后控制栅电压有否，这个状态都会保持下去，所以闪存可以掉电保存数据。注意写操作完毕后，该闪存单元存储的是 0。

这个是擦除操作。在源极加正电压利用浮空栅与漏极之间的隧道效应，将注入到浮空栅的负电荷吸引到源极，排空浮动栅的电子。这时读取的状态是 1。

具体为什么分别对应于 0/1 以及读取的逻辑，可参考链接的文章，这里不再赘述。这里重点要说下擦除的逻辑，理论上来说，闪存可以每个单元来单独擦除和编程。但是为了节省成本，实际上作用在控制栅上的擦除电压是整个块（Block）连接在一起的，所以实际的擦除要以块为单位了。这里出现了一种不对称：可以单一字节的方式读或写入，但是擦除一定是一整个区块。举个例子，有一小区块的值已抹除为 1111，然后写入 1110 的消息。接下来这个区块还可以依序写入 1010、0010，最后则是 0000。不能说从 0010 直接写为 0011 了，必须整个擦除为 1111 之后重写。实际上很少有算法可以从这种连续写入兼容性得到好处，一般来说还是整块抹除再重写。

这个限制也会极大地影响闪存之上的文件系统的设计。

eMMC / UFS

华为 P10 将这两个东西带到大众视野面前。可以说 UFS/eMMC 是一种内嵌式存储器的标准规格（基于闪存介质的基础上集成主控芯片，而且拥有标准接口）

还是表格对比

	eMMC	UFS
全拼	embedded MultiMedia Card	Universal Flash Storage
读写速度	50MB/S - 600MB/S	780MB/S - 1.5GB/S
价格(仅作对比)	67 - 145RMB	285RMB
工作模式	半双工	全双工模式

视频测试

hang.yan@hotmail.com (涯余) — Mon, 15 Apr 2019 10:44:44 +0800

Google 的经验

hang.yan@hotmail.com (涯余) — Sun, 14 Apr 2019 11:30:07 +0800

看了一篇讲谷歌公司内部的软件管理的论文，虽然对很多东西已经很熟悉了，但还是觉得有了一些新的启发。

业内对 Google 其实大多数都是一种追随者的态度。单说最近这些年的几大热门产业，大数据由 Google 的三篇论文起始，云计算由 Kubernetes 引领热潮， Alphago 在 AI 领域让人震撼。Google 比其他公司更早面临了很多技术发展的瓶颈之处，解决之后在某个时机将部分成果开源出来共享给业内。技术问题大家很容易采纳学习，但能解决这些问题的软件工程模式，则不是那么容易学习的。

Single Repo

Google 在公开这种模式之后，大部分人的态度是震惊的。因为这跟大部分人的使用模式差别很大。不管是大公司小公司，不同功能的 Repo 对应不同的功能，非常便于维护，便于划清职责。Google 的单一 Repo 模式，尤其在其规模之上，初看起来是非常难以理解的。上 Tb 的仓库数据，每天上万次的 Commit,它是如何管理的呢?

问题的答案自然是一套更为复杂的 CI/CD 系统，每一次的提交，自动化的构建、自动化的测试、自动化的 Review Check 等等，有了这些之后，代码的基本质量就有了保证，其他的就靠更为严格，精确的 Code Review 流程了。之所以大部分公司无法这样做，因为基础的 CI/CD 系统从来都不是一个公司在成长过程中优先考虑的问题，功能 -> 性能 -> Bug, 这些问题解决的差不多了，才有考虑其他的空闲。而往往此时，开发模式已经固定下来，没有了往 Single Repo 迁移的动力。

另一方面，Single Repo 带来的优势初看起来也是比较模糊的。它更多的不是一个技术上的问题，而是一个管理模式,或者企业文化上的问题。

是否能允许员工查看几乎所有的源码 Repo
如何在 Single Repo 中划分各个项目的职责边界

对 Google 来讲，去掉这个边界是必须的。他希望员工能够熟悉整个系统，不受限于自己所主要维护的组件的束缚，保持一个开放的心态。每个人都有创造的天性，当他发现有一个其他项目的问题或者优化他很想修复，或者有更好的解决方式，没有了项目的边界，他很自然地认为可以这样做也应该这样做。这种开放的模式保证了 Google 的所有项目能受惠于公司所有人的才智,也造就了 Google 在技术和商业上的成功。

Personal Time

这也是人人熟知，但几乎没有任何经常自称有 Google 背景的管理人员愿意尝试的模式。给员工留一些时间，让他做自己想做他任何想做的事。对于 Google 来说，有很多项目和改善都是来自于员工在这个时间的 Side Project。

联想起最近比较火的996,更是一种莫大的讽刺。在资本家眼里，开发人员不是一个个有创造性地个体，而是一个个贡献时间的螺丝钉。

软件行业的特殊性在于，技术本身迭代的速度太快，开发人员必须每天有专门的时间来 Catch Up。但这个 Catch Up 的效率和稳定性，每个开发人员都不一样。对于国内的资本家来说，他选择放弃信任自己的开发人员，让他们把这块时间共享给公司，虽然效率极低，但是对老板有安慰剂效应。而经历了资本主义黑暗时代的资本家和工人，达成了一种更为合理的制衡模式:互相有一定的信任基础,让人能均衡工作和生活的时间。

人性自有其很暗之处，心存侥幸，只会反噬于自身。

Github 与编程语言

hang.yan@hotmail.com (涯余) — Fri, 12 Apr 2019 15:22:54 +0800

一个语言的流行程度与多种因素相关,语法的简易性，package 的数量，性能，适用的场景等等。Perl 因为语法的怪异而逐渐无人问津，ROR因性能等问题也用的人越来越少。一向处于主流地位的 C/CPP 在这几年也比不上 JavaScript 以及 Golang 的热度。在 Github 上，我们可以看到热门的项目中，JS 以及 Golang 等热门语言占据了相当瞩目的位置。语言之间的较量从来就不是在单纯的语言层面本身，而是整个生态系统的对比。而不知不觉间，Github 也成了每个语言生态体系的一部分。

当代的主流程序员中，大多数都有 C/CPP 的语言背景。但在大部分的工作选择上，python 与 Golang 的数量越来越多，也越来越占主流。究其原因，一方面是在语法层面上，采用了与 C 相似而更简单的表达方式。但更重要的是，从一开始，他们就考虑到了包管理系统的重要性，因为它是语言生态系统的发动机，而 C/CPP 等语言到现在仍未有一个内建的实现。

对 Python 而言，在 Github 流行之前，pip 已经非常成熟。这让他成为了一个在任何需求面前都是被优先选择的语言之一。http 请求、web 框架、爬虫、图片解析等等，只要你想要的任何功能，都可以在 pip 里找到已经有的实现。有了 Github 之后，python 的 package 的数量的扩充进一步加快。代码在 github,二进制包在 pip,文档在 readthedocs,这是一个非常完善而让人信任的体系。

对于 Golang 来说，它就是生于 Github,流行于 Github 的。从一开始 docker/kubernetes 项目的流行，以及整个容器生态的成熟，给了 golang 一个良好的开端。go 内置的对于 github 上代码仓库的支持，即使有很多小问题，但总体来讲，这让 golang 以极快的速度建立起来了超越于 c/cpp 甚至能赶上 python/pip 的生态体系。在常规的开发场景以及业务需求上，golang 以及没有短板了。

而反观 c/cpp，在 github 之前，假设我们想要去找一个 package，只能借助于搜索引擎。也许在某些奇怪的网站上，能找到一个实现方案。但是相比于 golang/github 模式，这样的方式有明显的缺陷:

你不知道这个 package 的真正质量怎么样。而在 github，你可以通过 star/issues/PR 数量来推断
不能像 github 那样可以直接的方便地看到源码的结构,licence 等等信息
不能像 github 那样，一旦发现原有的 package 有需要修改的地方，直接提 PR 去调整。
…

这些问题导致了 c/cpp 社区倾向于不依赖于第三方实现，而是自己造轮子。或者是只能用 Boost 这样的库。整个社区就像是一个一个的孤岛，无法连接而壮大。如何做出来一个类似 pip 或者 go get 的系统，是整个社区亟需解决的问题。

目前来看，社区已经开始了尝试，各种 package manager 已经开始小范围使用，但是离进入语言标准还有很大距离。期待能在不远的将来看到 c/cpp 借助 github 重新崛起的一天。

而与此同时，许多新语言的产生也大多都是无疾而终，如何参照现有语言的成功模式以及借助 github 的力量，也是各个语言设计者需要考虑的问题。

The useless web

hang.yan@hotmail.com (涯余) — Wed, 10 Apr 2019 18:41:54 +0800

早期互联网的美妙之处在于，它真的是万维网,由无数的由个人或者公司搭建的互联网。没有如此大公司固定平台的限制，这些网站充满了无数的可能性。

之前工作无聊时发现的一个the useless web, 它给了我们一个magit button,每次点击都可以打开一个新的神奇的无聊网站：

有最神奇的可以随鼠标晃动的东西:

一个向下拉有无限长的腿的马:

一个不知道什么的隐喻：

被偷了 bucket 的海象…

这是一个几乎无限长的例子。几乎也是自由互联网的意义所在。很像<Rick and Morty>里他们看的宇宙电台一样，无穷无尽的稀奇古怪的电视节目。

无尽的无趣，比有限的伪装要好太多了。

Docker BuildKit 介绍

hang.yan@hotmail.com (涯余) — Mon, 08 Apr 2019 16:22:48 +0800

对于 Docker 和 Kubernetes 来说，在自身发展的壮大过程中，都会经历一个因为功能不断增加导致的软件结构庞杂的问题。对于 Kubernetes 来说，出于架构上的考量，kubectl 等项目的代码都会逐渐从主项目中移除。对于 Docker 来说，事情更为复杂，它既要考虑开源，又要考虑自己的商业化，所以有了 moby 以及 *kit 等一系列项目。下图清晰地展示出了 Docker 对于相关项目的一个架构规划:

总体来说，Docker 希望将容器技术与容器产品分离开，核心技术是开源的，可扩展的，这样允许有其他人来基于同样的技术来构建类似于 Docker CE/Docker EE 这样的产品。 BuildKit 自 2017 年年底便已经实现，但似乎关注度不是很高(在国内)，在 CI/CD 系统中的应用也不是很广泛。本文是关于 BuildKit 的一个相关介绍。

为什么需要 BuildKit

除了上面说的商业以及架构上的考量，本身在构建这一块，Dockerfile 以及相应的机制也面临着一些问题

并发程度不够好

很多步骤都是可以并行执行的，比如两部构建中的两次 pull 镜像，以及各种 run 命令
对 cache 的支持不好

像 golang 这样的语言，每次构建都要从头开始，没法复用缓存
对 secret 的支持不好

难以支持在 dockerfile 中通过 username-password/ssl key 等方式获取一些加密信息
可扩展性不够好
…

这些问题并不是说在现有的代码基础之上实现不了，而是综合来看，工作量比较大，而且到了一种必须审视现有架构的时机了。有了 moby 与 containerd 之后更是如此，这并不是一个孤立的问题，而是每个 docker 子功能(command)都会面临的机遇与挑战。

BuildKit 长什么样子

通常来讲，我们将 Dockerfile 当做一个项目里的一个用于部署的配置文件。但从某种角度来说，Dockerfile 就是一种编程语言，他有自己特定的语法，有编译器（docker）,有最终的产出(image)。这样来看，docker build 做的就是编译器的工作。关于编译器的结构与性能，我们已经有了在各个语言方面的实现以及优化经验，完全可以应用于 dockerfile。

从最初的 buildkit 的 proposal来看，也正是采用这样的视角。在架构上像 LLVM 一样，采用模块化的结构，每一个部分都是可以单独扩展的，只需要保正彼此之间的接口兼容性。

BuiltKit 主要分为以下几个部分

frontends: build 的描述定义，比如 Dockerfile,面向用户
solver/low level builder: 负责语法解析，生成中间结构，cache 管理
exporter: 生成物导出,比如现在的 image

有了抽象的 frontends 和 exporter，BuildKit 已经不再单单是针对 dockerfile 的一个优化，而是一个通用的构建系统。像 LLVM 一样，它可以支持多语言: Dockerfile,BuildPack,以及各种可能的自定义语言。在输出端，镜像也不再是唯一的输出格式，还可以是文件，目录，plugin，其他的镜像格式等等。

而最核心的，自然是 solver 部分。类似编译器的最核心部分:将源代码专程成目标结果。

LLB

LLB 指 low level builder,也即 solver。上层语言转成一些中间指令之后，形成一个DAG,它负责找到一种最有效的方式来执行指令并且管理 cache。它的主要目标有：

1.能够复用相同的步骤 2.结果相同的 instruction 能够复用结果 3.尽量并行化

不管 Dockerfile 里支持多少指令，frontend 支持多少种语言，对于 LLB 来说，核心的操作都是类似的：在一个 snapshot 中做一些操作，记录结果。其伪代码定义大概如下所示：

type Input struct {
 Base Op
 Index int
}

type Op struct {
 Deps []Input
 Outs []snapshot.Snapshot
}

type ExecOp struct {
 Op
 Meta ExecMeta
 Mounts []Mount // mapping for inputs to paths
}

type CopyOp struct {
 Op
 Sources []string
 Dest string
}

type SourceOp struct {
 Op
 Identifier string
}

type ExecMeta struct {
 Args []string
 Env []string
 User string
 Wd string
 Tty bool
 // DisableNetworking bool
}

ExecMeta部分定义了构建过程中所需要的尽量少的环境信息。SourceOp定义了构建开始时的初始数据，在 dockerfile 中就是我们常见的 FROM 语句，当然 BuildKit 并不限于此，而是也可以使用其他的 git 仓库，本地文件/目录等数据。

有用的新功能

启用了 BuildKit 之后，除了性能上的改善，我们现在就可以在 Dockerfile 中体验到一些非常有用的新功能。比如 mount 操作,其语法格式如下所示：

RUN --mount=type=<bind|cache|secret|tempfs|ssh>

这几种类型就解决了开始所说的一些问题

cache: 各语言 package managers 所使用的 cache
secret: 用于一些需要登录才能获取的资源，在最终的生成物中也不会保留这些敏感信息
ssh: 直接使用本地的 ssh-agent 去做登陆认证。

更安全的 DNS

hang.yan@hotmail.com (涯余) — Thu, 04 Apr 2019 20:56:03 +0800

HTTPS 已经越来越普及了，包括 Github Pages 都可以很方便的集成。浏览器也开始通过各种手段来促进网站都尽量使用 HTTPS。相比来说， DNS 的安全性受重视的程度就没那么高。Firefox 写了一个一篇非常好的介绍文章(见最后 Links)，系统性地介绍了当前的问题以及解决方案。在这里整理一下。

主要问题

DNS 协议主要交流的信息就两个：ip 和 domain, 这两个东西一般来说，很不起眼，但是漏洞(非安全协议)摆在这，总会有各种不法分子来作恶。目前我能想到的比较明显的两个就是

运营商劫持：一个不靠谱的运营商，在各个网站插入各种恶心的广告, 重定向网址等
不安全的公共网络: 比如公共场所的 wifi, 可以伪造各种网站，收集用户的上网记录等等

火狐也在文章中写出了 dns 查询过程中可能出现的安全漏洞：

主要有三个

不可靠的本地 dns 服务器
中间人攻击
一些根域名服务器能追踪你的解析记录。

解决方法

这几个问题，火狐都列出了解决方法。

使用受信任的 DNS 解析服务器

一般用户，包括互联网从业者，都不太关心本地配置的 dns 服务器是什么,一般都是运营商默认的。一般人也没有精力(能力)在出问题的时候去根运营商协调解决。火狐的思路是在用户使用浏览器的时候（不干涉其他程序），选择火狐信任的 dns 服务器来进行 dns 查询（可配置为失败时 fallback 到机器默认的）。目前火狐是和 cloudflare 合作，由 cloudflare 来提供域名解析服务，未来应该会有更多的提供商。

目前的 Firefox 66 版本已经支持了此选项（不一定是最早支持版本）,可以在 about:config 里面搜索 trr 查询到:

mode 设为 2 即是 fallback 模式，火狐会首先尝试用自己信任的 dns server 来解析域名，失败时用用户系统的。

这是一个比较好的思路，首先对大部分用户来说，常见的上网操作都是浏览器提供的，能解决大部分人大多数的问题。第二，cloudflare 这样的厂商属于比较有责任感的，愿意提供一些非常有益于公众的技术服务。未来火狐能接入更多的厂商，那么在可靠性和中立性上都有了很大的保障

DoH

Doh 的全称是 DNS over HTTPS, 是用来解决上面所属的第二个问题。HTTPS 已经在其他方面获得了很广泛的使用，用在这里也是非常自然的一个解决方案。火狐在选择受信任的 dns 解析服务商时，DoH也是一个基本要求。互联网的很多网络技术都存在了很多年，有提升的空间，但要考虑到对现有网络的兼容性，所以技术的改进是非常缓慢的。如果要有所有的 ISP 都支持 DoH 也是不现实的。但现在火狐的解决方法避免了这个问题，因为只要火狐在向 cloudflare 发送查询的时候使用 https 就行了，用户只需信任浏览器就好。这是一个非常难得的对现有互联网环境的改善。

QNAME minimization

第三个问题的主要原因就是，在现有的 dns 查询方式上，每次查询，我们都需要将完整的域名发送出去。我们知道 dns 的查询方式基本上是一个递归查询, 比如 en.wikipedia.org, 这个域名, 其查询的流程如下：

Root DNS: Root DNS 会告知在哪可以查询到 .org 相关的信息
Top Level Domain: 也叫 TLD。这个 TLD 知道所有的以 org 结尾的域名。比如 wikipedia.org,但再往下的子域名就不知道了
Authoritative Server: wikipedia 的域名服务器。他知道 wikipedia.org 下面的子域名的详细信息

目前的实现中，每一次的查询都需要把整个 en.wikipedia.org 发送到相应的服务器上。但从逻辑上来讲，其实每次只发相应的部分就可以了。比如发给 Root DNS的信息是 org, 发给 TLD 的是 wikipedia,发给 Authoritative Server 的是 en 即可。这样做的好处有；

减少数据传输量
中间人和 DNS Server 能够 track 的信息都减少了

目前的 DNS 协议规范里也并没有强制要求每次的查询必须发全量的名字。所以目前来看是一个非常有吸引力的优化方案。

一个已知的问题是 zone cut, 虽然没找到具体的定义。但是通过下面的例子可以很容易理解这个问题。因为客户端(本地的 resolver)现在承担了分解域名的责任，那么下面一个域名

www.foo.bar.exmaple

在发送给 example 查询的数据的时候，有两种可能

bar.example
foo.bar.example

因为 resolver 不知道具体的 zone cut 信息，所以它很可能会需要多查询一次。不过本地 resolver 一般都会维护 cache 信息，所以性能上还是可以接受的。

其他问题

还有一个问题就是，即使我们在上面用了种种措施来进行了安全的 dns 解析，查询到了 ip ,在请求真实的 server 时，我们仍然需要发送完全的域名给 server。因为服务器有可能同时 host 了多个 domain（virtual hosting）。这个请求是不加密的，因为 TLS 建立连接的时候需要这个名字（先有鸡还是先有蛋的问题，具体的解释请查询SNI）。

这个薄弱的一环暂时还没有什么特别好的方法来解决，但是可以通过其他的技术来减少这样的请求

HTTP2: http2 可以链接复用。同一个 host 上，只要与其中一个 server 建立了链接，其他的就不需要再发送这个请求了
CDN: 越来越多的网站开始使用 CDN(github pages 的模式也很类似于这个)。只要与其中一个站点建立链接，其他的都不需要了

Emacs is drugs

hang.yan@hotmail.com (涯余) — Thu, 28 Mar 2019 21:06:19 +0800

每个程序员都会遇到这一天，他要做一个决定，vim 还是 emacs,还是 IDE。

近来一直主要用 Golang, 早已不再年轻的我自然是选择功能强大的 Goland, 日常工作无压力。即使没有免费的注册码了，我也毫不犹豫地买了正版。只是，它太慢了，太卡了，16GB 内存的 Mac 跑起来都不轻松。

在无数次的痛苦的等待中，我终于决定换一个 Editor 试一试。Atom 也慢，Code 看起来都很不错，插件多，界面舒服，速度也快，但我面对它总有一种无所适从的感觉。我偶尔会用它来做些零碎的工作，但从来没法把它当作一个主要的开发工具。

这几天偶然翻起来一直装在电脑里确很久没有打开的 Emacs, 才明白了 Code 的问题在哪。

Code 是一个优秀的 Editor, 但也仅此而以。我们用它来写代码，代码和 Editor 是两个东西。我们要学习怎么去使用这个软件，这个学习的过程和写代码是两套系统。它像 PS,像 Word，是一个精巧的软件，是编程的产物。

而 Emacs 不同，它是一个 Editor, 但又和任何的 Editor 不同。它即是一个精巧的软件，也是一个操作系统，也是编程本身。

首先，它基于 Elisp 编写，是 lisp 到今天少有的面向大众的软件产品。他的所有扩展也都是 lisp 代码。lisp 良好的可读性能让人很容易理解一个扩展是怎么写出来的，你可以如何修改它，照着它写一个新的。你在用它的时候，能明确地感觉到你在写的代码和编辑器不是分离的两个东西。它不是一个服务于你的黑盒子，而是一个对你透明的软体。你可以随时打开它看看他的内在，修改它，调整它，让他的形态更适用于你的需求。在很多人使用 emacs 的时候，会经常发现，你打开的文件列表经常会有 lisp 代码。好像他们属于一个项目似的。

elisp 主要的功能都是面向文本编辑的，所以它比普通的 editor 有更多的概念: 缓冲区/ring buffer/minibuf/mode-line 等等。这些概念加起来，造就了最为精准丰富的文本处理和表现系统。无数在其他 editor 无法实现或者很难实现的功能，在这里都可以很容地用代码写出来。是的，就是用 elisp 代码。最终，是 elisp 代码组成了 emacs, 而对其他的 editor 来说，组成他们的是基本功能 + 扩展。

Editor/IDE 的分化，是因为用常规的软件设计思路，无法作出一个满足以下功能的开发工具:

支持所有语言
对特定语言做特定的优化支持
使用简单

IDE 选择了 2，3, 对 1 的支持非常有限，而且必须还是以一两个主要语言为主要支持对象。Code/Atom 这样的 Editor 通过插件选择了 1，部分达到 2，但无法做到 3。觉得使用他们简单的，背后是长时间的不那么愉快的使用，记忆。

Emacs 的独特之处在于，它像 Code,通过插件支持 1,2。然后 3 就看个人的兴趣，如果能跨过 lisp 这一关，一切都非常简单了。

为什么？因为在一个 Editor 中，我们最常需要记忆的几部分是: 快捷键/功能/变量。在其他的 Editor/IDE 中，这些都是需要分别记忆的东西。而且功能越庞杂，要记忆的东西也越多，但在 emacs 中，他们都是 lisp 表达式。lisp 也只有表达式。你需要记录的只是三个快捷键

查询一个函数(表达式)的作用
查询一个快捷键绑定了什么函数(表达式)
查询一个变量的值(表达式)

比如下面的例子，我想知道 f5 这个快捷键是用来干嘛的, 然后输入 C-h k f5

Emacs 告诉了我如下信息:

这个快捷键绑定了哪个表达式
这个表达式的源码所在的文件，可以点击跳转
这个表达式的文档，在 lisp , 文档是表达式(函数)的一部分
哪些地方引用了这个表达式
开启 debug/trace 的方式
表达式的源代码

具体来说，这个快捷键(f5)的作用是打开一个当前项目的文件树：

这些信息告诉我们的不只是某个快捷键是干嘛的，而是所有的一切。代码，文档，快捷键，关联，一切都联系在一起，你不用刻意去记忆。因为你会在无数的地方将他们关联起来。关联本身就是记忆。

再比如, 很多时候，我们确实想执行一个功能，比如我想查看当前 json 文件的结构，你不一定给他绑了快捷键，你也不知道具体的函数名是什么，那么这时候我可以通过json进行模糊搜索，来找到可能的表达式:

(如果没有，可以直接用安装 package 的命令来安装相关的 package)

找到了后执行即可，如果它已经绑定了快捷键，Emacs 会在之后给你提示。

在使用 Emacs 的一开始，你记住这几个 help 的命令，之后的一切都顺其自然，无需太过费劲心力了。

写几行代码，改几行 lisp。

玩一局俄罗斯方块，煮一杯咖啡。

写几封邮件，读几篇新闻。

下班。

istio

hang.yan@hotmail.com (涯余) — Mon, 25 Mar 2019 19:16:44 +0800

整个容器化浪潮诞生了三个胜利者,分别是 docker, kubernetes, istio。一个额外的胜利者是 golang。

Docker

docker 的作用是：

用标准语法描述出一个服务的静态/运行时环境，无关语言与操作系统
资源隔离

被打死的是 lxc, 它有资源隔离的功能，但是缺点太明显：

没有上面的 docker 提供的第一个功能
架构不如 docker 的 cli/server 的简洁明了，易于学习

受威胁的是 VM

太慢了
性能损耗大
无法 API 化

Kubernetes

真正的 DCOS，核心优势:

统一资源模型
统一 API 模型 (引导业务 API 向其靠拢)
Node 横向扩展
插件化

被打死的是 Mesos/Marathon，缺点

两层架构的低效率 (仁慈独裁与低效民主)
C++
C++ 导致的难以 debug
难以扩展以增加新功能

另一个被打死的是 swarm/compose, 缺点

架构不清晰
自下而上地缓慢地堆功能

受威胁的是 YARN, 不如 kubernetes 通用性强

Istio

微服务相比于单体服务的一切问题都应该在这层解决, trace, 限流, metrics 等等

不需要修改业务代码
比手工的实现更完善，功能更强

受影响的：微服务业务代码

Golang

可读性最好之一
性能好到不用自己刻意关注

Namecoin

hang.yan@hotmail.com (涯余) — Tue, 22 Aug 2017 00:00:00 +0000

互联网到今日已经越来越趋向于中心化，用户的隐私安全以及大公司的行为也日渐引起担忧。去中心化网络是一个应对此问题的重要思想，blockchian,bitcoin,tor 等都是一些具体的技术探索，很多已经有了越来越大的影响力。Namecoin 也是其中的一个。

Namecoin 想要解决的是目前 DNS 存在的一些问题。中央机构控制的 DNS 很容易因为各种原因受到干扰，用户的利益和隐私容易受到侵犯。Namecoin 借助于 bitcoin 的思想，构建了一个去中心化的 DNS 系统。

Zooko’s triangle

类似于分布式系统中的 CAP 理论。类似 DNS 这样的协议，我们期望它具有的三个特性很难满足: 安全,可读性好,去中心化。目前的最常用的 DNS 系统不满足去中心化。DNSSec 对现有的 DNS 做了一些安全性的增强，但仍然是中心化的。.onion和bitcoin是去中心化的和安全的，但是可读性很差等等。

Namecoin 是满足上面要求的一个系统。（Aaron Swartz曾经提出过这样的设计思路)

Namecoin

Namecoin 基于 BitCoin,本身就是在 Bitcoin 的代码上实现的(大概做了 400 多行改动)。挖矿的方式跟 bitcoin 一样，只是用的是不同的 block chain.二者的目的不同,bitcoin 主要还是为了成为一种货币系统，Namecoin 是为了成为一种命名系统。所以二者的关注点不同，blockchain 分开也是最合理的。二者有一些不同的规则：

namecoin 要求名字的唯一性(域名)，而 bitcoin 不要求
经济交易以及域名注册使用的货币大小不一样，block size 设的不一样更好
通货膨胀对 bitcoin 的影响很大，namecoin 则不一样。
namcoin 中，注册域名需要花钱,但这些货币会被销毁(0.01NMC).因为是去中心化的系统，没有收费的中央系统。

Namecoin 里的数据主要分为两种 domain name 和 NameID

Domain

Domain 的格式类似于:

{
 "name" : "d/opennic",
 "value" : "what you want",
 "expires_in" : 10227
}

value的示例:

{
 "ip" : "192.168.1.1",
 "ip6" : "2001:4860:0:1001::68",
 "tor" : "eqt5g4fuenphqinx.onion",
 "email" : "hostmaster@example.bit",
 "info" : "Example & Sons Co.",
 "service" : [ ["smtp", "tcp", 10, 0, 25, "mail"] ],
 "tls": {
 "tcp":
 {
 "443": [ [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1] ],
 "25": [ [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1] ]
 }
 },
 "map":
 {
 "www" : { "alias": "" },
 "ftp" : { "ip": ["10.2.3.4", "10.4.3.2"] },
 "mail": { "ns": ["ns1.host.net", "ns12.host.net"] }
 }
}

其中d/是一个 namespace,主要是为了应用层的区分，表示这个数据是一个 domain.

name: d/开头，后面的字符串应该遵守 domain name 的 regex
value: json string.关于此 domain 的一些属性。最大长度 520 bytes.

Identity

用来管理网上的个人身份标识信息。namespace 为 id/。 testnet 这里可以看到一些在线的信息。

REF

Kubernetes 笔记

hang.yan@hotmail.com (涯余) — Fri, 18 Aug 2017 00:00:00 +0000

API

声明式的 API

声明式：结果是什么命令式: 做什么

声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，隐藏实现的细节的同时，也就保留了系统未来持续优化的可能性

kubernetes 里的 API 都是声明式,我们描述好自己想要的 resource object,kubernetes 就会不断尝试去保证这个 resource object 按我们期望的方式存在.

API Response

一般包含三部分

metadata: 元数据
- annotations: 一些元信息.给第工具用来存储和解析原信息用的.
- labels: act as filter
- namespace: resource 所处的 namespace
- name: resource 名字
- uuid: 唯一标识
- creationTimestamp: 创建时间
- deletionTimestamp: 计划删除的时间(graceful deletion)
- resourceVersion: 每个 resource 的内部版本,可以用来确定是否发生了变化.也用于做并发控制
- generation
spec: 具体描述,不同 resource 的属性不同。spec 里通过声明式的方式表明了期望的目标状态
status: resource 的当前状态

下面以展示一下 kubernetes node api 的 metadata 作为样例:

metadata:

metadata:
 annotations:
 flannel.alpha.coreos.com/backend-data: '{"VtepMAC":"9a:98:da:a1:b9:5d"}'
 flannel.alpha.coreos.com/backend-type: vxlan
 flannel.alpha.coreos.com/kube-subnet-manager: "true"
 flannel.alpha.coreos.com/public-ip: 172.18.0.4
 scheduler.alpha.kubernetes.io/taints: '[]'
 volumes.kubernetes.io/controller-managed-attach-detach: "true"
 creationTimestamp: 2017-07-13T09:45:11Z
 labels:
 beta.kubernetes.io/arch: amd64
 beta.kubernetes.io/os: linux
 ip: 172.18.0.4
 kubeadm.alpha.kubernetes.io/role: master
 kubernetes.io/hostname: 172.18.0.4
 name: 172.18.0.4
 resourceVersion: "3785002"
 selfLink: /api/v1/nodes172.18.0.4
 uid: f6fc3022-67af-11e7-b171-0017fa013946

可以看到 flannel 用它来存储了一些自己需要的信息.

这种区分几乎适用于 REST 架构中的大多数 resource.好处:

比一整个大的 body 结构清晰
模块化,每个部分的更新迭代不会影响整个 body 的结构
展示及处理方便

错误处理

kubernetes 的错误情况下的 response 也遵循上面相同的结构.示例如下:

{
 "kind": "Status",
 "apiVersion": "v1",
 "metadata": {},
 "status": "Failure",
 "message": "pods \"grafana\" not found",
 "reason": "NotFound",
 "details": {
 "name": "grafana",
 "kind": "pods"
 },
 "code": 404
}

其特点是同时提供了机器可读(reason)以及人类可读(message)的消息. reason是对 http status code 的一种细化.

Resource Version

上面所说 metadata 中的resourceVersion字段被 Kubernets 用来做并发控制,在更新一个 object 前,会去检查它的 resourceVersion 的值与之前存的值是否匹配,如果不匹配,则会抛出一个StatusConflict(http 409).

Version

一般来说 REST API 都会要求有一个版本的概念,这样在架构迭代以及功能升级时可以用不同的版本来区分,保证语义及结构清晰.Kubernetes 做的更多,它也会用 version 来区分功能的成熟度(alpha,beta…)

alpha
- 可能包含 bug,默认关闭,不保证兼容性,适合测试使用
beta
- 大方向不会变,细节上可能会有修改.如果有不兼容的改动发生,会提供升级方式
stable
- 可稳定使用

API Group

API 分组,一般 API 都会分为核心的对 Resource 进行操作的 API 以及其他零碎的 API.

一般 URL 格式为: GROUP/VERSION.GROUP 的名字建议的格式为 domin name 的格式,比如: widget.mycompany.com

Runtime config

kubernets 支持非常多的参数(已经有很多人在网上吐槽了..),结合上面的版本以及分组,kube-api 有很多参数可以用来调控这些.比如禁掉一些 Group,禁掉一些 Version 的 API.一个完全可插拔的 API Server.

REGEX

详细定义好各个 resource name 的REGEX要求,比如namespace,service中不能有点(.),只能小写(DNS 兼容).

字段格式

像 date,timestamp 等这种字段要保证在所有 API 中使用用一种格式

PATCH 与 PUT

一般来说 PUT 应该发送 resource 的整个描述去 replace.PATCH 只发送需要更新的部分.但一般的场景中遵循此规则的应该不多,大多是只用一个 PUT,即用于整个更新也用于部分更新.

kubernetes 做的更多,在 PATCH 操作,它支持几种不同的操作语义

Json Patch: Content-Type: application/json-patch+json
- 定义了需要做的操作,示例如下:
  - {"op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ]}
Merge Patch: Content-Type: application/merge-patch+jso
- objects 类的是合并,lists 类的是 replace
Strategic Merge Patch: Content-Type: application/strategic-merge-patch+json
- 支持各种自定义操作的 patch

Events

时间也是系统设计里非常重要的一环.发生了上面,什么时间,谁操作的,结果是什么,不仅可以用系统内部问题的排查,也可以作为产品提供给其他用户.

Kubernetes 对一些重复性的时间做了累积,原本需要重复显示 N 次的事件现在用一个计数器来代替.这样可以减少数据存储和系统负载.

交互

输出

Unix 有一个非常出名的设计哲学:“一切皆文件”,其优势在于，利用管道及其他工具，无数的小工具(find,grep,awk)等可以方便地协作以完成非常复杂的任务。各个工具均支持plain text作为输入以及输出。当然一切皆文件也有一个坏处，开源软件由不同的人写就，没有文本格式的约束，不同的工具均需要一定的文本格式的要求。工具越多，格式也越杂乱，需要人为记忆的东西也越多。例如很多 service 类工具的配置文件格式的差异，不同命令输出的差异等等

kubernetes 由很多组件构成，提供 API 的服务，命令行的访问工具(kubetctl)等等。类似于docker cli及docker daemon，kubectl也是从kube-api-server来读取信息展示给用户。我觉得 kubetcl 做的比较好的一点就是，它将数据的内部结构和展示二者分开了。示例如下:

获取节点的简单信息，不加任何参数:

[root@172 alauda]# kubectl get no
NAME STATUS AGE
172.18.0.4 Ready,master 38d
[root@172 alauda]#

指定输出 yaml 格式的详情

...
spec:
 externalID: 172.18.0.4
 podCIDR: 10.1.0.0/24
 providerID: azure:////2882C846-5C01-BE47-B19A-4C5DB5F26348
status:
 addresses:
 - address: 172.18.0.4
 type: LegacyHostIP
 - address: 172.18.0.4
 type: InternalIP
 - address: 172.18.0.4
 type: Hostname
 allocatable:
 alpha.kubernetes.io/nvidia-gpu: "0"
 cpu: "16"
 memory: 57710432Ki
 pods: "110"
...

指定输出 json 格式的详情

{
 "apiVersion": "v1",
 "kind": "Node",
 "metadata": {
 "annotations": {
 "flannel.alpha.coreos.com/backend-data": "{\"VtepMAC\":\"9a:98:da:a1:b9:5d\"}",
 "flannel.alpha.coreos.com/backend-type": "vxlan",
 "flannel.alpha.coreos.com/kube-subnet-manager": "true",
 "flannel.alpha.coreos.com/public-ip": "172.18.0.4",
 "scheduler.alpha.kubernetes.io/taints": "[]",
 "volumes.kubernetes.io/controller-managed-attach-detach": "true"
 },
 "creationTimestamp": "2017-07-13T09:45:11Z",
 "labels": {
 "beta.kubernetes.io/arch": "amd64",
 "beta.kubernetes.io/os": "linux",
 "ip": "172.18.0.4",
 "kubeadm.alpha.kubernetes.io/role": "master",
 "kubernetes.io/hostname": "172.18.0.4"
 },
 "name": "172.18.0.4",
 "resourceVersion": "3785243",
 "selfLink": "/api/v1/nodes172.18.0.4",
 "uid": "f6fc3022-67af-11e7-b171-0017fa013946"
 },
 "spec": {
 "externalID": "172.18.0.4",
 "podCIDR": "10.1.0.0/24",
 "providerID": "azure:////2882C846-5C01-BE47-B19A-4C5DB5F26348"
 },
 "....": "...."
}

默认的输出格式比较类似于 linux 上ls的默认输出。但也可以通过指定参数获取 json 或 yaml 格式的信息。前者适用于展示，后者适用于处理(管道).ls的输出目前既用于展示，也会用于输出。鉴于 json 目前的流行程度及简洁性，设想 plan9 上这些小工具均内置于对 json 或者 yaml 的支持，那么在利用管道及其他工具做数据处理的时候会大为简便，并且不易出错。

输入

kubectl 支持从一个描述文件里创建一个 resource(yaml 或 json 格式).因为 API 结构的一致,kubernetes 里面几乎所有的资源都可以通过一个kubectl create -f来创建出来. 因为每种 resource 都有大体相同的结构: Kind,Version,Spec 等等

Blockchain

hang.yan@hotmail.com (涯余) — Sat, 12 Aug 2017 21:37:39 +0800

介绍

区块链是由一串使用密码学方法产生的数据块组成的，每一个区块都包含了上一个区块的哈希值(hash),从创始区块(genesis block)开始连接到当前区块，形成块链(类似数据结构中的链表).每一个区块都确保按照时间顺序在上一个区块之后产生，否则前一个区块的哈希值是未知的。

其优势在于:

完全分布式的，无中心节点(单点故障)
任何节点都可以创建交易。在经过一段时间的确认之后，就可以合理地确认该交易是否有效。
修改交易记录的成本非常高

区块链也是比特币等技术的基础。它也是一种非常重要的新思想，促使人们对现有的网络,社会,经济等进行重新思考。

区块结构

头结构

大小(bytes)	字段	描述
4	版本	版本号
32	父区块哈希值	引用区块链中父区块的哈希值
32	merkle 根	该区块交易的 merkle 树根的哈希值
4	时间戳	该区块产生的近似时间(精确到秒的 unix 时间戳)
4	难度目标	该区块工作量证明算法的难度目标
4	Nonce	用于工作量证明算法的计数器

区块结构

大小(bytes)	字段	描述
4	区块大小	该字段之后的区块大小
80	区块头	区块头结构 (上面的大小之和)
1-9	可变整交易计数器	交易的数量
可变	交易	记录在区块里的交易信息

创世区块

比特币区块链的第一个区块，创建于 2009 年，我们称之为创世区块。它是比特币区块链里所有区块的共同祖先，这意味着你从任一区块，循链向后回溯，最终都将到达创世区块。每一个节点都“知道”创世区块的哈希值、结构、被创建的时间和里面的一个交易。因此，每个节点都把该区块作为区块链的首区块，从而构建了一个安全的、可信的区块链的根。

创世区块的哈希值为

分叉

对于区块链中的任意一个区块，到达创世块的路径只有一条。然而，从创世块开始，会有分叉的情况出现。当创建两个区块的时间差只有几秒时，经常会创建出一个分叉区块。这时候不同的客户端可能接收到的区块不一样,然后各自在这个基础上继续拓展新的区块,直到有一个较长的出现,则作为主链条.其他的视为无效.

如上图所示，绿色区块为创世区块。黑色区块为主区块(主链条),紫色的称为 orphan blocks. 主链条的累积工作量是最大的，并不总是区块长度(高度)最长的。

Proof-of-work(工作量证明)

区块链从第一个区块开始，依赖于旷工们去拓展链条的长度。矿工们都进行一些数学计算，谁先算出一个合法的目标数值就可以宣称自己挖到了一个新的 Block.这种检验的方式可以成为“工作量证明"（以下简称为 POW).POW 在 blockchain 之前就已存在，应用于垃圾邮件过滤以及防范拒绝服务攻击扥等。其基本原理都是相同的，但不同的系统会应用不同的 hash 算法以及进行不同长度的难度调整。下面以垃圾邮件的过滤为例来简要说明一下:

基本原理: 发送邮件的人需要在邮件的 Header 里加一条，里面是一个字符串，字符串里包含了发送的时间，接受者邮件，以及一个随机数等。这个字符串的哈希值必须符合一定的条件(前置 N 位为 0).有了这样的要求，发送者必须经过暴力破解方式来尝试出一个合法的值,需要消耗一定的计算量。对于接受者来说，它可以很快地检验出来这个字符串是否满足要求(hash 函数的单项特性).对于前者来说，增加 N 之后计算难度会成指数级增长，而对于后者来说校验时间是固定的。对于普通的邮件接收来说，这两个时间都是可以忽略不计(通常在 s 级之内)的。但对于垃圾邮件的发送者来说，因为他需要发送大量的邮件，这个时间累积起来就很可观了。所以可以有效地进行垃圾邮件的过滤。

Header 格式如下

X-Hashcash: 1:20:1303030600:adam@cypherspace.org::McMybZIhxKXu57jd:ckvi

1 : Hashcash 版本
20 : hash 值的前置 0 的个数
1303030600 : 发送邮件的时间
adam@cypherspace.org: 接收者
（ext): 扩展(Version 1 里忽略)
McMybZIhxKXu57jd : 随机数的 base64
ckvi: 计数器的 base64

上面包含了接受者，所以对不于不同的邮件接收人，哈希值都要重新计算。

对于发送者来说:

Header 中包含了接受者，所以对不于不同的邮件接收人，哈希值都要重新计算。
首先设一个初始化的 Header(包含一个初始的随机数),然后开始计算 160 位的SHA-1 hash 值。如果前 20 位为 0,那么成功生成一个合法的 Header.如果不成功，增加计数器继续计算。平均下来每次大概需要2^20次计算能得到一个合法的值。

对于接收者来说:

根据 Header 内容计算哈希值,判断前二十位是否为 0.这是有一个耗时固定的操作,而且远比发送者所耗资源要少
检查发送时间及邮件是否正确
将 hash 值入库,如果已经存在,则视为非法

在 Linux/Mac 上可以用openssl的命令来进行一个简单地校验:

echo -n 1:52:380119:calvin@comics.net:::9B760005E92F0DAE | openssl sha1
0000000000000756af69e2ffbdb930261873cd71

(注意 52 是要求二进制的 0,上面的结果是 13 位 10 进制的)

Bitcoin

挖矿的流程与上面非常类似,只是具体的变量不同. 挖矿的公式可以概括为如下所示:

SHA256(SHA256(version + prev_hash + merkle_root + ntime + nbits + x )) < TARGET

目的就是找到一个合适的 x(0~2^32)

SHA256: hash 算法
versio: block 的版本
prev_hash: 上一个 block 的 hash 值
merkle_root: 需要写入的交易记录的 hash 树的值
ntime: 更新时间
nbits: 当前难度

TARGET 越小，解出 x 的难度就越大(类比于前面的邮件的例子就是前置的 0 越多,计算的次数越多).

一旦你找到了 x，你就可以广播一个新的 block，其他客户端会验证你的 block 是否合法。如果你的 block 被接受，由于每个 block 中的第一笔交易必须是将新产生 25 个比特币发送到某个地址(public key)，当然你会把这个地址设为你所拥有的地址来得到这 25 个比特币。

REF

Shard

hang.yan@hotmail.com (涯余) — Fri, 11 Aug 2017 21:37:39 +0800

介绍

Shard 指对数据的水平切分,每一个切分的部分都可以叫做一个shard,它们拥有相同的 schema,但却拥有不同的数据集。对数据库来说，是指对数据库的表按行进行切分(与按列的垂直切分对应)，不同的 shard 可能位于不同的数据库服务器或者物理机器上。它的优势体现在以下几点:

表的大小减少,索引体积减小,提升查询性能(某些方面)
如果数据本身有比较明显的分区(比如国家,地区等),那么做 shard 很容易并且查询很大程度上都能落在一个 shard 上。
水平扩展性好，可以通过添加新节点来扩充

劣势有以下几点:

查询需要跨多个 shard 时会增加 latency
因为 shard 经常只能做到某一位维度。所以在这一维度的查询的性能可能提高，但其他维度的查询的性能则可能会下降。
跨 shard 的数据一致性和可用性也更加复杂和难以保障

shard 本身的问题让他成为一个迫不得已的选择。尽量在没有其他优化方式的情况下选择 shard.理想情况下，应该有底层框架来处理 shard 而让应用层做到对 shard 无感知，不然还不如不用。

分片策略

如果将数据集进行 shard,有很多策略可以选择，常见的有

The Lookup strategy

用 shard key 做一个映射表，包含不同 shard key 的请求会转发到相应的 shard 上。这种情况下，不同 shard key 的数据可能会落在同一个 shard 上，但相同 shard key 的数据则一定在同一个 shard 上.shard 与物理地址的映射也不能是一对一的，可以用类似于 consistent hashing 里面的那种 virtual node 的方式，设置一些virtual shard，几个 virtual shard 可以对应于同样的物理位置(reblancing 的时候对上层代码的影响很小)。

The Range strategy

适用于需要获取区间连续数据的场景。与第一种策略类似，用 shard key 做分区，但 shard key 是按顺序排列的，每个 shard 内部的数据也经是有序的.(通常有一个 row key 用来在内部排序).

The Hash strategy

为了分散数据和请求，也可以用 hash 函数对数据做分片。上面两种策略避免不了的一个问题是,假如有一些数据是热点数据，那么他们很可能是位于少量的几个 shard 上，这样就造成了负载的不均衡。而利用 hash 函数则能尽量将热点数据分散开，必要时还可以加入一些随机元素来提高随机性.

一点 python 的经验

hang.yan@hotmail.com (涯余) — Tue, 10 Nov 2015 21:37:39 +0800

工作中总结的一些 python 的小经验，分享一下~

返回值

当 python 项目越来越庞大的时候,返回值的不一致就成为了一个越来越严重的问题。有的返回 None,有的返回一个 Object，有的返回一个 dict,有的抛出异常….有些函数我们可以从名字上猜出它可能的返回值，有的必须要有健全的文档才能厘清。不一致的返回类型导致上层调用者必须维护各种各样的判断逻辑，还要考虑到以后可能的改动，确实是一件非常头疼的事。

所以可以考虑对所有函数的返回值进行一个封装，对上层调用者提供一个统一的判断逻辑。下面是一个示例:

def fail(msg, err_code=error.ERR_DATA_NOT_EXIST):
 return {
 'suc': False,
 'errmsg': msg,
 'code': err_code
 }


def suc(data=None):
 return {
 'suc': True,
 'data': data
 }

函数调用者在拿到返回值后只需判断 result['suc']的真假即可知道函数执行的情况。对于fail来说，有一个错误信息和一个错误码，即可用于日志信息显示，也可以判断错误类型。对于suc来说,数据存在data字段中，而大多数情况下仅需根据函数名字即可判断出 data是否为None。

异常

使用异常还是错误码，一直都是见仁见智的问题。但是如果两者混用，就会带来很多额外的麻烦。尤其是在使用第三方库的时候，有的使用异常，有的不抛出异常，如果直接使用，调用代码会显得非常混乱。使用上面的suc/fail封装后，可以将所有的异常捕获并以错误码的形式返回，上层代码会显得更加具有一致性,示例如下:

def _do_req(self, module, action, params):
 try:
 service = Api(module, self.config)
 url = service.generateUrl(action, params)
 LOG.debug("API http request url. | url=%s", url)
 resp = service.call(action, params)
 if resp['code'] != 0:
 return fail(resp['message'], err_code=error.ERR_REMOTE_FAILED)
 return suc(resp)
 except Exception, e:
 return fail(e.message, err_code=error.ERR_NETWORK_EXCEPTION)

这段代码需要处理两种情况,一种是网络异常,通过fail将其转化为错误码和错误信息。另一种是成功调用但是 response 里面也有错误码,也可以用fail自己进行处理。调用者只需判断返回值中的suc字段即可知道该如何处理返回值。

日志

很多时候我们希望既能返回错误信息也能同时将其打印到日志中,最简单的方式如下:

msg = "error message"
LOG.error(msg)
return fail(msg, error_code)

这样写有点累赘，可以将其写成一个单独的函数:

def log_fail(logger, msg, err_code=error.ERR_DATA_NOT_EXIST):
 logger.error(msg)
 return fail(msg, err_code=err_code)

这样每次只用将logger实例和msg传给log_fail即可。

Update: 这种方式并不是很好，最终显示调用 logger 的位置是不对的，需要一点 hack 才能正确地显示打日志的位置:

class CallerLog(logging.Logger):
 def _error(self, msg, fn, lno, func, *args, **kwargs):
 if self.isEnabledFor(logging.ERROR):
 self.__log(logging.ERROR, msg, fn, lno, func, args, **kwargs)

 def __log(self, level, msg, fn, lno, func, args, exc_info=None, extra=None):
 if exc_info:
 if not isinstance(exc_info, tuple):
 exc_info = sys.exc_info()
 record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info,
 func, extra)
 self.handle(record)

 def _trace(self, msg, *args, **kwargs):
 self.critical(msg, *args, **kwargs)

logging.setLoggerClass(CallerLog)

def log_fail(msg, code=ERR_DATA_NOT_EXIST):
 """Log as caller function and return fail.

 Common scenario is a function want to log and return the same error message.

 Args:
 msg(str): error message
 code(str): error code
 """
 caller = getframeinfo(stack()[1][0])
 module_name = caller.filename[len(settings.BASE_DIR) + 1:].replace('.py', '').replace('/', '.')
 log = logging.getLogger(module_name)
 log._error(msg, caller.filename, caller.lineno, caller.function)
 return fail(msg, code=code)

日志打印

日志基本上使我们平时调试线上问题最重要的工具了。良好的日志分级，格式能够帮助我们很快地定位问题所在，但是不像 python 语言本身有很多规范去约束代码，日志打印经常会出现各种各样的问题影响我们的查看,比如:

数量不够。导致看不出代码的执行逻辑
格式混乱。看起来费力
日志级别错误。有些人喜欢将自己觉得重要的信息打在ERROR里，这是非常不好的一个习惯。
没有高亮。日志通常没有高亮显示功能,看起来非常费力。

下面是一些改善的方式:

书写习惯

这个就跟 git 的commit message一样，怎么写都行，但一定要只维持一种习惯。比如首字母要大写都大写，要小写都小写，混用的话眼睛看起来会比较累。其他如标点符号，使用词汇等都是非常细节的问题，但如果能保持一致，会让日志的可读性提高不少。

这是我之前写的一个简单地一些日志规范,可以参考: 日志打印规范

日志信息描述中比较重要的一点是描述信息和实际数据的格式。当然我们使用格式化字符串将变量的值嵌入到描述语句中，我个人比较偏爱的一种方式是:

这样统一将描述放在前面，将数据放在后面，可读性会更好一点。golang有一个日志库(logrus)就支持此种方式的打印:

logrus做的更好，能够将数据统一向右对齐。可惜 python 没有这样的库。

高亮支持

高亮支持一般是对于终端显示用的,写在文件里就不是很合适，因为有好多颜色控制字符。有一种折衷的办法就是同时往两个文件打印日志，一个是普通的，一个是可以高亮的。这样当使用cat或者tail这样的工具时可以查看带高亮的日志，其他的情况查看普通的日志。

python 有一个colorlog库支持带高亮的日志，下面是一个示例的配置:

formatters:

'formatters': {
 'standard': {
 'format': '%(asctime)s [%(levelname)s][%(threadName)s]' +
 '[%(name)s.%(funcName)s():%(lineno)d] %(message)s'
 },
 'color': {
 '()': 'util.log.SplitColoredFormatter',
 'format': "%(asctime)s " +
 "%(log_color)s%(bold)s[%(levelname)s]%(reset)s" +
 "[%(threadName)s][%(name)s.%(funcName)s():%(lineno)d] " +
 "%(blue)s%(message)s"
 }
},

handlers:

 'color': {
 'level': 'DEBUG',
 'class': 'logging.handlers.RotatingFileHandler',
 'filename': LOG_PATH + '.color.log',
 'maxBytes': 1024 * 1024 * 1024,
 'backupCount': 5,
 'formatter': 'color',
 },

其中SplitColoredformatter是我自己重写的一个formatter,用来支持我上面所说的描述和数据分离的格式:

class SplitColoredFormatter(ColoredFormatter):
 def format(self, record):
 """Format a message from a record object."""
 record = ColoredRecord(record)
 record.log_color = self.color(self.log_colors, record.levelname)

 # Set secondary log colors
 if self.secondary_log_colors:
 for name, log_colors in self.secondary_log_colors.items():
 color = self.color(log_colors, record.levelname)
 setattr(record, name + '_log_color', color)

 # Format the message
 if sys.version_info > (2, 7):
 message = super(ColoredFormatter, self).format(record)
 else:
 message = logging.Formatter.format(self, record)

 # Add a reset code to the end of the message
 # (if it wasn't explicitly added in format str)
 if self.reset and not message.endswith(escape_codes['reset']):
 message += escape_codes['reset']

 parts = message.split('|')
 if len(parts) != 1:
 desc = parts[0] + escape_codes['reset']
 data = escape_codes['green'] + parts[1]
 message = desc + '|' + data

 return message

最终出来的效果如下图所示:

Scala 笔记: 函数和闭包

hang.yan@hotmail.com (涯余) — Mon, 31 Aug 2015 21:37:39 +0800

Local functions

在函数式语言里，函数是最基本的功能块。通常为了模块清晰起见，我们需要很多 Help Function，但是这些辅助函数很容易有名字冲突，暴露给外部的时候也容易引起很多问题。 Java 的主要解决方式是通过private method,scala 也支持这种。但是 scala 也提供了函数式风格的解决方式: 在函数内部定义函数(Local functions.),就像局部变量一样,其作用域仅限于外部函数内部。

import scala.io.Source

object LongLines {

 def processFile(filename: String, width: Int) {

 def processLine(line: String) {
 if (line.length > width)
 print(filename +": "+ line)
 }

 val source = Source.fromFile(filename)
 for (line <- source.getLines)
 processLine(line)
 }
}

内部函数的一个便利之处就是它可以直接访问外部函数的变量(参数)。

First-class functions

函数式语言与命令式语言之间最大的区别之一便是其数据和代码的一致性。在 C/JAVA 这样的语言里,变量、类、函数、语句等时候严格区分的，但在 Lisp 这样的语言里，所有的表达式都有值，都是数据，都可以当做变量传给函数。

scala 里有function literal和function value两个概念，有点像是class和 object之间的区别，前者都是在代码层级上而言，后者是运行时的概念。例如:

(x: Int) => x + 1

这是一个fucntion literal。你可以把它赋给一个变量并且调用它:

var increase = (x: Int) => x + 1
increase(10)
increase = (x: Int) => x + 9999
increase(10)

简单的函数一行即可描述，多行的用{}包起来即可。

scala 标准库里有一个常用的foreach函数，它就是以一个函数为参数并且将其应用到 collections的各个元素之上的:

val someNumbers = List(-11, -10, -5, 0, 5, 10)
someNumbers.foreach((x: Int) => println(x))

foreach函数的参数即事一个fcuntion literal

语法糖

scala 代码看起来难懂就在于它提供了好多简化代码的方式，就拿常用于 collections 上的 filter函数来说(用法与 foreach 类似),因为既然是作用于collections,scala 有能力自己推导出function literal的参数类型,比如在一个List[String]上操作，那么类型自然就是String。简化过后可以写作:

scala> val someNumbers = List(-11, -10, -5, 0, 5, 10)
someNumbers: List[Int] = List(-11, -10, -5, 0, 5, 10)
scala> someNumbers.filter((x) => x > 0)
res5: List[Int] = List(5, 10)

再进一步，我们可以将参数外面的括号去掉，因为外面已经有一层括号了，里面这个就显得有点多余了:

scala> someNumbers.filter(x => x > 0)
res6: List[Int] = List(5, 10)

Placeholder

继续简化。上例中的x只用了一次，完全可以省略掉，只要能表示出有一个从 List 中取出的数来参与比较即可:

scala> someNumbers.filter(_ > 0)
res7: List[Int] = List(5, 10)

这种占位符(Placeholder)语法在很多语言中都出现过，比如python。再看下面一个用法:

someNumbers.foreach(println _)

它和下面这种形式的含义完全一样:

someNumbers.foreach(x => println(x))

注意在这里占位符其实代替了整个参数列表，因为它不会有引起任何混淆。

Partially applied functions

Partially applied functions 也是函数式编程中常见的一个概念,在 C++中也提供了一定的支持。以一个具有多个参数的函数来蓝本，我们可以通过提供不同数量的部分参数来创造出不同的函数。示例如下:

scala> def sum(a: Int, b: Int, c: Int) = a + b + c
sum: (a: Int,b: Int,c: Int)Int

scala> sum(1, 2, 3)
res10: Int = 6

这是正常函数的调用流程。如果我们提供给 sum 两个个参数，我们就创造出了一个只需要一个个参数的 sum 函数:

scala> val b = sum(1, _: Int, 3)
b: (Int) => Int = <function1>

scala> b(2)
res13: Int = 6

Closures

闭包(Closures)的概念理解起来并不很难，但是你不把它放在函数式编程的范畴内就很难理解它的作用。在 C 这样的语言里，闭包看起来是没什么用的。但在函数式语言里，函数经常会表现的像一个变量，会被当做参数传来穿去。对于模块性非常好的函数——内部处理逻辑与外部无关，只与参数有关——我们很容易理解其逻辑。但是对于需要引用到外部变量的函数，就容易引起混淆了。这就是闭包的作用所在：它能将函数创建时的一部分环境封装起来，将函数所需要的外部变量和其绑定在一起，以便其内部使用。看一个例子:

scala> var more = 1
more: Int = 1
scala> val addMore = (x: Int) => x + more
addMore: (Int) => Int = <function1>
scala> addMore(10)
res17: Int = 11
scala> more = 9999
more: Int = 9999
scala> addMore(10)
res18: Int = 10009

addMore 的执行需要一个外部的more变量，它会自动在其外部环境里找到这个变量并使用。需要注意的是，more的值改变时，函数是可以感知到其变化的。

函数的特殊形式

Repeated parameters

直接看例子:

scala> def echo(args: String*) =
 for (arg <- args) println(arg)
echo: (args: String*)Unit
scala> echo()

scala> echo("one")
one

scala> echo("hello", "world!")
hello
world!

函数的最后一个参数可以是变长的一个参数列表,使用时将其当做一个列表处理即可。需要注意的是，函数调用时不能直接传一个列表过去，必须是将列表中的元素一个一个传进去:

scala> val arr = Array("What's", "up", "doc?")
arr: Array[java.lang.String] = Array(What's, up, doc?)

scala> echo(arr)
<console>:7: error: type mismatch;
found : Array[java.lang.String]
required: String
 echo(arr)

scala> echo(arr: _*)
What's
up
doc?

Named arguments and Default parameter values

很多语言里都有这些概念，使用命名参数可以不必按照参数声明的顺序来调用。与普通参数混用时要把普通的参数写在前面。

默认参数和命名参数经常是结合起来使用的:

def printTime2(out: java.io.PrintStream = Console.out,
 divisor: Int = 1) =
 out.println("time = "+ System.currentTimeMillis()/divisor)

printTime2(out = Console.err)
printTime2(divisor = 1000)

如果没有命名参数，想要在第一个参数为默认而第二个参数明确指定基本上是做不到的。

尾递归

在命令式语言中，像while循环这种结构，在函数式语言里一般只能通过递归来实现。看起来更加优雅简单，但是会带来性能的损耗。尾递归便是对其的一种优化，使其能达到和 while循环等类似结构同样的性能.

def approximate(guess: Double): Double =
 if (isGoodEnough(guess)) guess
 else approximate(improve(guess))

def approximateLoop(initialGuess: Double): Double = {
 var guess = initialGuess
 while (!isGoodEnough(guess))
 guess = improve(guess)
 guess
}

注意上面的递归函数是在函数的最后一行调用自身，编译器可以将这种调用直接跳回到函数开始处（更新参数后），省去存储各层函数堆栈的麻烦。最终编译器会对两种形式生成同样的底层代码。

Docker 1.7 介绍

hang.yan@hotmail.com (涯余) — Sun, 12 Jul 2015 21:37:39 +0800

实验特性

很多软件在发布的时候都会分为开发板和稳定版，稳定版可以供生产环境使用，开发版是让感兴趣的用户使用，体验新特性，并报告 BUG 以助于官方改进。现在 Docker 在提供稳定版的同时，也提供了集成了很多新特性的开发版供下载使用。

正式版的安装方式是用 https://get.docker.com/上的脚本，开发版的安装类似，只不过用的脚本不一样 : https://experimental.docker.com/，二者最终会启用不一样的软件源。目前开发版的版本是:1.8.0-dev,如下图所示:

注意其中的Experimental字段为TRUE。

下面我就先来看看开发版里的比较重要的更新，以便了解 Docker 后续的发展状况:

插件支持

在介绍插件之前，我们首先回顾一下 Docker 本身的架构发展。Docker 从一开始就是 REST API + JSON 的架构，这是整个 Docker 生态体系能迅速壮大的原因之一。但就 Docker Server 端的后台 Engine 来说，仍然是好多功能交织在一块,过于复杂。所以在 Docker 的后续版本中，对 Engine 进行模块化重构一直是重中之重。从最初分离出来的 libcontainer,到 libtrust,然后现在的libnetwork,libkv，越来越多的子模块被独立出来，既简化了架构，也增强了 Docker 对各个异构系统的适应能力。很多模块在使用上都有点类似于最早的 GraphDriver这一块，Docker 只提供一个通用的 Driver接口，各个文件系统 (aufs,overlay等)自己实现这些接口即可。如今的插件机制便是对这一功能的扩充。

如今的插件机制只支持 volume plugin和network driver plugins，后续肯定也会支持其他的插件。如果你想现在自己尝试编写一个插件，请参考以下文档: Experimental: Docker Plugin API

官方文档里也列出了几个现存的插件，如下所示:

Flocker plugin volume plugin,是数据卷可在多个主机间无缝迁移。
Weave plugin netwrok driver plugin,提供虚拟的多主机间的容器网络环境
Calico plugin network driver plugin, 提供多主机间基于 BGP 的虚拟网络

网络和服务

大家期待已久的关于网络和服务的特性终于在这一版里有了重大更新。如今network和 server都已经成了Docker里面的一等公民，像Image和Container一样,在命令行里试一下:

注意,直接输入docker命令后的的帮助信息里并没有这两个子命令，估计是还没有同步更新。

除了这些之外，也增加到了对不同主机间的容器网络的支持。在这之上，Docker 原生的服务发现功能也成为了可能。如果对 Docker 在网络方面的发展感兴趣，可关注一下 libnetwork项目。

下面将开始介绍稳定版里的新功能:

资源管理

CPU CFS quota

CFS指Completely Fair Scheduler，完全公平调度器。在 cgroups 里可以用 cpu.cfs_period_us和cpu.cfs_quota_us来限制该组中的所有进程在单位时间里可以使用各 CPU 时间。其中前者是时间周期，默认为 100ms,后者是在这时间内可使用的 CPU 时间，默认为-1,即无限制。此次在docker run中增加了--cpu-quota参数可用来调节后者的值。

磁盘 IO 限制

Docker 为进程提供了一个隔离的运行环境，但这个隔离并不是很完全，在很多资源的限制方面都未实现。在 1.7 之前，一直没有对磁盘 IO 进行限制的功能，此次增加了 --blkio-weight参数正是为了解决这个问题。

ZFS

现在在实际中常用的两个graph driver是aufs和devicemapper,分别在ubuntu系和 redhat系上用的最多。从源码上来看，推荐的使用顺序依次是 aufs,btrfs,zfs,devicemapper,overlay,vfs,可见zfs犹在 devicemapper之前，此次增加对ZFS的支持，也为大家以后选择文件系统提供了更多的选择。

容器

Logs

logs 方面的重大更新是在 1.6 版本，此次只是增加了--since参数用于截取自某个时间段之后的日志。

Exec

之前的版本中，使用docker exec时，新的进程都会用 root 权限运行，这会带来很多安全隐患。此次增加了--user参数，提升了容器的安全性。

命名空间

Docker 将容器与宿主机隔离起来，但在有些场景下，我们也需要在某些方面让容器和主机共享资源。比如我们知道--net=host参数，通过使用主机网络，可以避免虚拟网络的性能损耗， --pid参数可以用来选择 PID 的命名空间。此次增加了UTS(hostname)命名空间共享的支持，给用户在使用上带来了更多的选择。

userland-proxy

userland proxy一直以来的作用是通过0.0.0.0地址对容器映射出来的端口进行访问，在很多场景下，这个功能并不是必须的，而且docker-proxy所占用的资源过多也一直被诟病，所以在此版本增加了--userland-proxy选项，让用户来选择是否开启这个功能。

参考链接

docker 容器内多进程的管理方案

hang.yan@hotmail.com (涯余) — Fri, 08 May 2015 21:37:39 +0800

容器生来适合的是以单进程为主的独立的微服务架构，而很多传统的组件则是体积庞大，多个进程（组件）之间难以拆分到不同的容器中，所以在单个容器内部署多个组件便成了一种暂时的折衷方案。这便引入了一个问题：如何在容器内管理多个进程？

总的来说，至少有三种方案可选:

通过romote api 进行远程attach。通过http的方式来远程执行命令
使用一个init程序作为容器的主进程，所有组件都作为此程序的子进程
不虚拟PID的namespace

这几种方式各有优劣，下面将分别进行详述。

Remote Attach

Docker Remote API提供了两种进行Remote Attach的方式，一是通过POST的方式,另一种是通过Websocket协议。Websocket是构建于HTTP之上的一种协议，比较适合于双向通信。可惜的是，二者的文档都很少，很难完整地实现一个可靠的客户端，不过相对来说,Websocket要比POST方便很多,这里有一个简单的客户端实现 docker-ws-client,可以远程发送命令并执行。

这个程序只能用来进行简单的演示，在生产环境几乎是不可用的。主要面临的问题如下:

要想命令被执行，容器内必须有一个 Bash 程序存在，生产环境用的容器很少会需要在里面放一个 Bash 程序
对于一些命令输出为交互式的来说(比如top)，在执行了这些程序之后，会干扰到后续命令的执行，一般只能通过重启容器解决。
远程发送命令的执行结果会和其他容器内程序的输出相混淆。这就意味着docker logs的输出里会混杂每次远程命令执行的结果,远程命令的结果里也会混杂着其他的程序的输出，导致无法获取精确的信息
返回结果里附带了一行命令提示符，这是 Bash 的正常表现，但在远程执行时经常不需要这个功能。

Docker自身在实现Websocket Server时选用的是一个比较简陋的库 : code.google.com/p/go.net/websocket/, 所提供的 API 很少，无法对双向通信提供精确的控制。而且按照Docker自身的规划来说,这个功能并不是需要重点支持的，因为 Docker 适用的是微服务（单进程），常用的远程 API 都是针对容器级别的，对容器内部的操纵只能算是一些“小众”需求，社区不太会花太多时间在这块的改进上，所以不建议花时间在这方面构建什么东西。

多进程管理程序

这也是 Docker 官方比较推荐的一种方式,有两篇官方博文介绍:Process Management with CFEngine 和Using Supervisor with Docker。思路其实很明确 : 将多进程转为单进程(管理程序,容器的init程序),这个init程序的生命周期和容器是一样的，由它来管理其他进程。就符合了单进程的模型，虽然可能不是那么轻量级。

这也是最适合生产环境中的一种方式。当然长期来说，能将各种传统服务转为微服务架构最好，但在这个过渡期，或者对一些转换代价比较大的服务来说，这是最为稳定和可控的一种方式。其主要优点如下:

不用再写脚本。脚本是容器内启动多个进程最为简单也是问题最多的一种方式。信号传递、进程监控、容易引起僵尸进程、后台程序的处理……引发的问题非常多。
管理进程的通用性。Supervisor这类开源组件已经说明管理进程完全可以做的非常通用，通过配置文件的定制，这个程序完全可以跑在所有需要多进程的容器内。
复用性。如果要自己开发这个程序，完全可以用到很多已有的经验，毕竟容器内的环境非常类似于物理机上。已有平台的监控方式，在容器里几乎是一样的，这能大大减少开发难度。

总之，对于简单的使用案例，可以尝试Supervisor这类开源组件。而对于有能力的公司，则推荐在已有经验上开发一个新的管理程序。

Host PID Namespace

这种情况不再对容器内的 PID 进行虚拟，即docker top 和在容器内执行top命令看到的都是进程的实际 PID。这样做的好处是原有的监控方案可以直接拿过来用，部门功能如状态查看、杀死进程等能正常工作，不好的地方就是如果需要拉起的话则是在容器外做不到的，因为拉起一般都是通过可执行文件的路径来做的，而容器的文件系统是虚拟的，所以基本上无法实现。

这种方式也是不推荐的。我们使用容器，最终也是为了虚拟化，所以在不影响性能的情况下，应该进行将各部分都虚拟出来，这样最不容易出问题。如果虚拟网络性能不好，我们可以先不用虚拟网络，但是其他的部分如果不是因为性能原因，还是尽量通过其他可能的途径去解决问题，而不是破坏虚拟化环境的一致性。

docker 容器的一些概念辨析

hang.yan@hotmail.com (涯余) — Thu, 16 Apr 2015 21:37:39 +0800

本篇的主要内容是为了澄清 docker 容器的一些容易混淆的概念，主要分两部分，一是容器端口的publish和expose,二是 Dockerfile 中ENTRYPOINT和CMD的区分。

Expose or Publish

expose的作用是为了容器间通信，也就是说 expose 的端口只能被其他容器访问，但是不能被 docker 之外访问，而publish的端口即可用于容器间通信也可被外界访问。所以从逻辑上来说,publish包含了expose。

有这样的区分主要是为了可移植性。我们知道在Dockerfile文件中只有Expose命令, expose暴露的端口只能用于容器间通信，不会跟主机上的端口冲突。如果在 Dockerfile中加入了publish，在其他的机器上构建时就有可能导致端口冲突。

在命令行里使用这两个参数时，二者是可以混用的，不会冲突。同时指定--expose和 --publish与单独使用--publish的效果一样。

ENTRYPOINT or CMD

Docker 提供了一个默认的ENTRYPOINT:/bin/sh -c,但是没有默认的CMD。比如当我们在命令行里执行docker run -it ubuntu bash的时候,entrypoint 就是/bin/sh -c， command 就是bash。

在命令行里,所有镜像名字之后的参数都是作为 command 传给了 entrypoint。在Dockerfile 中，我们可以指定默认的ENTRYPOINT和CMD。比如我们执行docker run -it ubuntu的时候，效果和docker run -it ubuntu bash是一样的，因为 ubuntu 的 Dockerfile 里指定了 CMD为bash.

二者的分离主要也是应用在 Dockerfile 中,通过灵活的设置，我们可以做出来一些有趣的，很方便使用的镜像。比如将ENTRYPOINT设为[/bin/cat],那么在执行docker run　catimg /etc/password的时候就相当于在执行/bin/cat /etc/password,整个镜像此时变成了一个二进制程序。这个例子可能显得有点无聊，但是既然任意程序都可以用做 ENTRYPOINT,自然是只有想不到，没有做不到了。如果将一个 redis 镜像的ENTRYPOINT设为["redis", "-H", "something", "-u", "toto"],那么在执行docker run redisimg get key就相当于docker run redisimg redis -H something -u toto get key,这就是一个简单明了的 redis 客户端，也不用输那么多参数了。

Dockerfile 中与此相关的命令还有一个RUN，相关细节较为琐碎，下面将详细叙述：

RUN

RUN用来在上一层 layer 的基础上执行一些系统命令并且创建新的一层，可以说是 Dockerfile 中最为常见的命令了，主要有两种形式

RUN <command> 通过/bin/sh -c执行
RUN ["executable", "param1", "param2"] (exec 形式)

exec 形式可以避免 shell 对参数的一些处理并且可以用在一些没有/bin/sh的基本镜像上，如果想使用别的 shell，也可以使用此种方式,比如RUN ["/bin/bash", "-c", "echo hello"]。注意事项:

exec 形式是以 json 数组的形式来解析的，所以各参数必须用双引号""，不能用单引号''。
exec 形式下如果不明确制定是不会调用 shell 的，也就意味着一些环境变量是无法解析的，

比如RUN [ "echo", "$HOME" ]，如果需要必须自己明确指定所用的 shell

CMD

CMD主要是为容器提供默认的运行程序，有三种形式:

CMD ["executable","param1","param2"] (exec 形式)
CMD ["param1","param2"] (将参数传给ENTRYPOINT)
CMD command param1 param2 (shell 形式,/bin/sh -c执行)

一个 Dockerfile 中只能有一个CMD，如果指定了多个，只有最后一个起作用。运行时的参数会覆盖 Dockerfile 中CMD。

注意事项可参考RUN的注意事项

ENTRYPOINT

ENTRYPOINT有两种形式:

ENTRYPOINT ["executable", "param1", "param2"] (exec 形式)
ENTRYPOINT command param1 param2 (shell 形式)

类似于CMD,如果指定了多个ENTRYPOINT，只有最后一个起作用。docker run --entrypoint可覆盖 Dockerfile 中的设置。

exec 形式是最常用的，shell 形式会阻止任何CMD或者run的参数的执行(因为已经在 ENTRYPOINT 中指定了执行程序),但是不能传递信号。

##　参考链接

docker 源码分析(6) -- 镜像删除

hang.yan@hotmail.com (涯余) — Fri, 03 Apr 2015 21:37:39 +0800

本篇的主要内容是关于如何删除镜像的.听起来是挺简单的一件事,但是docker本身的删除策略定义并不清除，而且在实际的使用过程中,似乎总是与我们预计的结果不符,比如磁盘空间并没有被释放.所以在此单列一篇,详细解析镜像删除的过程.

简介

上篇已经介绍过很多关于镜像相关的源码,本篇就不在重复,着重分析与删除相关的部分

子命令执行

首先仍然是subcommand的执行部分,镜像删除的子命令式rmi,与之对应的函数便是 CmdRmi.

docker rmi接受两个参数:

github.com/docker/docker/api/client/commands.go#CmdRmi:

var (
 cmd = cli.Subcmd("rmi", "IMAGE [IMAGE...]", "Remove one or more images")
 force = cmd.Bool([]string{"f", "-force"}, false, "Force removal of the image")
 noprune = cmd.Bool([]string{"-no-prune"}, false, "Do not delete untagged parents")
)

force用来决定是否在有容器使用了此镜像时(非运行状态)强制删除,noprune指定不删除没有tag的parent layers.

for _, name := range cmd.Args() {
 body, _, err := readBody(cli.call("DELETE", "/images/"+name+"?"+v.Encode(), nil, false))
 if err != nil {
 fmt.Fprintf(cli.err, "%s\n", err)
 encounteredError = fmt.Errorf("Error: failed to remove one or more images")
 }

docker rmi可以接受多个参数,可以从上面代码看到,实际执行时是对每一个image都执行一个DELETE请求并处理返回结果.

服务端的handler为:

github.com/docker/docker/api/server/server.go#createRouter:

"DELETE": {
 "/containers/{name:.*}": deleteContainers,
 "/images/{name:.*}": deleteImages,
},

请求处理

deleteImages的主要工作仍是job环境的设置以及参数的传递:

func deleteImages(eng *engine.Engine, version version.Version, w http.ResponseWriter, r *http.Request, vars map[string]string) error {
 if err := parseForm(r); err != nil {
 return err
 }
 if vars == nil {
 return fmt.Errorf("Missing parameter")
 }
 var job = eng.Job("image_delete", vars["name"])
 streamJSON(job, w, false)
 job.Setenv("force", r.Form.Get("force"))
 job.Setenv("noprune", r.Form.Get("noprune"))

 return job.Run()
}

image_delete对应的handler暂时定义在daemon包中,后续可能也会移到graph包中:

镜像删除

func (daemon *Daemon) ImageDelete(job *engine.Job) engine.Status {
 if n := len(job.Args); n != 1 {
 return job.Errorf("Usage: %s IMAGE", job.Name)
 }
 imgs := engine.NewTable("", 0)
 if err := daemon.DeleteImage(job.Eng, job.Args[0], imgs, true, job.GetenvBool("force"), job.GetenvBool("noprune")); err != nil {
 return job.Error(err)
 }
 if len(imgs.Data) == 0 {
 return job.Errorf("Conflict, %s wasn't deleted", job.Args[0])
 }
 if _, err := imgs.WriteListTo(job.Stdout); err != nil {
 return job.Error(err)
 }
 return engine.StatusOK
}

可以看到，主要的删除是通过daemon.DeleteImage函数进行，而Table结构体则是用来记录删除的结果:

type Table struct {
 Data []*Env
 sortKey string
 Chan chan *Env
}

func NewTable(sortKey string, sizeHint int) *Table {
 return &Table{
 make([]*Env, 0, sizeHint),
 sortKey,
 make(chan *Env),
 }
}

镜像查找

要删除镜像，就要先获取到关于这个镜像的一些详细信息：名称，tag,父子关系等。而输入既可能是镜像 ID，也可能是名字:

github.com/docker/docker/daemon/image_delete.go#DeleteImage:

// 解析名字和 tag.repoName 有可能是镜像 ID
repoName, tag = parsers.ParseRepositoryTag(name)
if tag == "" {
 tag = graph.DEFAULTTAG
}

// 查找镜像，先从 TagStore 里面找，找不到就当成镜像 ID 从 Graph 中找.`Get(repoName)`似乎
// 显得有点多余，因为 LookupImage 里面已经包含了所有步骤。
img, err := daemon.Repositories().LookupImage(name)
if err != nil {
 if r, _ := daemon.Repositories().Get(repoName); r != nil {
 return fmt.Errorf("No such image: %s:%s", repoName, tag)
 }
 return fmt.Errorf("No such image: %s", name)
}

// 如果输入的是镜像 ID，repoName 和 tag 置为空.
if strings.Contains(img.ID, name) {
 repoName = ""
 tag = ""
}

父子关系查找

docker 的镜像存储是一个树形结构，每个镜像只有一个父节点（镜像），但可以有多个子节点（镜像）。Graph并没有提供多少相应的数据结构来进行节点查找，所以只能是遍历查询：

byParents, err := daemon.Graph().ByParent()
if err != nil {
 return err
}

ByParent返回了所有镜像与其子镜像(可为多个)之间的映射关系.

github.com/docker/docker/graph/graph.go:

func (graph *Graph) ByParent() (map[string][]*image.Image, error) {
 byParent := make(map[string][]*image.Image)
 err := graph.walkAll(func(img *image.Image) {
 parent, err := graph.Get(img.Parent)
 if err != nil {
 return
 }
 if children, exists := byParent[parent.ID]; exists {
 byParent[parent.ID] = append(children, img)
 } else {
 byParent[parent.ID] = []*image.Image{img}
 }
 })
 return byParent, err
}

镜像名称与 ID 关系

镜像 ID 与名称并不是一一映射的关系。比如说我们用docker tag命令给一个镜像赋予了一个新的名字，旧的名字是不会被取代的.所以经常会发现不同的镜像名称对应的 ID 都是同一个:

当我们删除镜像时，不管是指定名字还是 ID，这样的映射关系也需要提前找出来:

repos := daemon.Repositories().ByID()[img.ID]

github.com/docker/docker/graph/tags.go:

func (store *TagStore) LookupImage(name string) (*image.Image, error) {
 // FIXME: standardize on returning nil when the image doesn't exist, and err for everything else
 // (so we can pass all errors here)
 repos, tag := parsers.ParseRepositoryTag(name)
 if tag == "" {
 tag = DEFAULTTAG
 }
 img, err := store.GetImage(repos, tag)
 store.Lock()
 defer store.Unlock()
 if err != nil {
 return nil, err
 } else if img == nil {
 if img, err = store.graph.Get(name); err != nil {
 return nil, err
 }
 }
 return img, nil
}

最终repos的值就是一个名称:tag 列表.

如果repos是多个，那么删除的情况就比较复杂.综述如下:

首先有两个基本原则:

要删除的镜像必须没有子节点（没有被别的镜像使用） ,不然最多只会去掉tag信息,不会删除实际数据
删除是沿着镜像的树形结构向上删除，会删除所有没有被使用的所有父节点,直到找到一个正在被别的镜像使用的镜像为止.

有点类似于 Linux 上的各种包管理软件对依赖关系的处理.具体的情况如下:

docker rmi <image id>
- 对应单个name:tag 最简单情况，直接删除,
- 对应同一个name,多个tag 直接删除
- 对应多个name，不加force参数会报错，加上之后会将第一个name对应的tag 信息都删掉,但镜像不会删除
docker rmi name:[tag]
- 与image id一一对应直接删除
- 与其他的tag(name相同)对应同一个image id 只会去掉这个name:[tag]信息, 不删除数据
- 与不同的name:[tag]共享一个image id 只会去掉这个name:[tag]信息，不删除实际数据

情况复杂，但是分析起来，其实都是很容易理解的。

github.com/docker/docker/daemon/image_delete.go#DeleteImage:

if repoName == "" {
 for _, repoAndTag := range repos {
 parsedRepo, parsedTag := parsers.ParseRepositoryTag(repoAndTag)
 if repoName == "" || repoName == parsedRepo {
 repoName = parsedRepo
 if parsedTag != "" {
 tags = append(tags, parsedTag)
 }
 } else if repoName != parsedRepo && !force {
 // the id belongs to multiple repos, like base:latest and user:test,
 // in that case return conflict
 return fmt.Errorf("Conflict, cannot delete image %s because it is tagged in multiple repositories, use -f to force", name)
 }
 }
} else {
 tags = append(tags, tag)
}

从上面代码可以看到，当输入为image id时,如果name:[tag]有多个，只会将第一个的信息清除掉, 其他的都跳过了，未做处理。

删除

真正在删除镜像之前，还需要考虑容器。如果要删除的镜像还有容器在使用(不论是否正在运行)它，则不能删除.从上面总结的种种情况来看,真正会删除实际数据的情况不多，所以只用考虑这几种情况即可:

github.com/docker/docker/daemon/image_delete.go#DeleteImage:

if len(repos) <= 1 {
 if err := daemon.canDeleteImage(img.ID, force); err != nil {
 return err
 }
}

func (daemon *Daemon) canDeleteImage(imgID string, force bool) error {
 // 返回容器列表
 for _, container := range daemon.List() {
 parent, err := daemon.Repositories().LookupImage(container.ImageID)
 if err != nil {
 if daemon.Graph().IsNotExist(err, container.ImageID) {
 return nil
 }
 return err
 }

 if err := parent.WalkHistory(func(p *image.Image) error {
 if imgID == p.ID {
 if container.IsRunning() {
 if force {
 return fmt.Errorf("Conflict, cannot force delete %s because the running container %s is using it, stop it and retry", stringid.TruncateID(imgID), stringid.TruncateID(container.ID))
 }
 return fmt.Errorf("Conflict, cannot delete %s because the running container %s is using it, stop it and use -f to force", stringid.TruncateID(imgID), stringid.TruncateID(container.ID))
 } else if !force {
 return fmt.Errorf("Conflict, cannot delete %s because the container %s is using it, use -f to force", stringid.TruncateID(imgID), stringid.TruncateID(container.ID))
 }
 }
 return nil
 }); err != nil {
 return err
 }
 }
 return nil
}

从上面也可以看到force参数的作用:当有容器在使用这个镜像但并未运行时，force可以强制删除镜像。

需要注意的上，上面对repos长度的判断并未覆盖全部的情况：当一个镜像 ID 对应对个一个name的多个tag时，此时用docker rmi <iamge id>就绕过了与容器相关的检查, 详见issue 12135.

真正的删除分两步。第一步：untag,删除相关tag信息:

for _, tag := range tags {
 tagDeleted, err := daemon.Repositories().Delete(repoName, tag)
 if err != nil {
 return err
 }
 if tagDeleted {
 out := &engine.Env{}
 out.Set("Untagged", repoName+":"+tag)
 imgs.Add(out)
 eng.Job("log", "untag", img.ID, "").Run()
 }
}

daemon.Repositories().Delete即是从TagStore中删除相关信息.

第二步：删除实际镜像数据，这一步并不一定会执行。

tags = daemon.Repositories().ByID()[img.ID]
if (len(tags) <= 1 && repoName == "") || len(tags) == 0 {
 if len(byParents[img.ID]) == 0 {
 if err := daemon.Repositories().DeleteAll(img.ID); err != nil {
 return err
 }
 if err := daemon.Graph().Delete(img.ID); err != nil {
 return err
 }
 out := &engine.Env{}
 out.Set("Deleted", img.ID)
 imgs.Add(out)
 eng.Job("log", "delete", img.ID, "").Run()
 if img.Parent != "" && !noprune {
 err := daemon.DeleteImage(eng, img.Parent, imgs, false, force, noprune)
 if first {
 return err
 }

 }

 }
}

这时候的tags已经是清楚过一个repo之后的了，有可能为空，也有可能有其他的值（这时候就不能删除镜像数据）。len(tags) <= 1 && repoName == ""是应对原本就没有 tag的镜像，比如我们在用docker build时生成的很多中间镜像。

真正的数据删除是在daemon.Graph().Delete():

github.com/docker/docker/graph/graph.go:

func (graph *Graph) Delete(name string) error {
 id, err := graph.idIndex.Get(name)
 if err != nil {
 return err
 }
 tmp, err := graph.Mktemp("")
 graph.idIndex.Delete(id)
 if err == nil {
 err = os.Rename(graph.ImageRoot(id), tmp)
 // On err make tmp point to old dir and cleanup unused tmp dir
 if err != nil {
 os.RemoveAll(tmp)
 tmp = graph.ImageRoot(id)
 }
 } else {
 // On err make tmp point to old dir for cleanup
 tmp = graph.ImageRoot(id)
 }
 // Remove rootfs data from the driver
 graph.driver.Remove(id)
 // Remove the trashed image directory
 return os.RemoveAll(tmp)
}

/var/lib/docker/graph和/var/lib/docker/aufs/下的相关目录都会被清除.

总结

在明晰了镜像删除的原理之后，自己如果确实想要释放磁盘空间，可以人工对相应目录里的数据进行删除。

docker 源码分析(5) -- 镜像拉取及存储

hang.yan@hotmail.com (涯余) — Mon, 30 Mar 2015 21:37:39 +0800

本篇的内容主要是关于docker镜像的。在我们安装好docker之后，要想使用它，第一步就是要下载一些镜像。本文将依据此流程分析docker中镜像的拉取、存储等相关内容。

简介

docker中几乎所有的操作都是通过WEB API的方式执行的，所以当我们在命令行下敲下 docker pull或者通过Docker Remote API来拉取镜像时，docker便准备好各项参数，开始向内部的web server发送http请求，最终由提前注册好的Handlers来执行相关操作。我们将按照这个步骤来逐步分析与镜像拉取,存储相关的源码。

子命令执行

我们仍从docker的main函数入口处开始。在 docker 主程序分析中里面我已经提到，如果没有-d参数，最终便当作client对待并且将参数当作子命令来解析执行,代码如下:

if err := cli.Cmd(flag.Args()...); err != nil {
 if sterr, ok := err.(*utils.StatusError); ok {
 if sterr.Status != "" {
 log.Println(sterr.Status)
 }
 os.Exit(sterr.StatusCode)
 }
 log.Fatal(err)
}

比如我在命令行下敲下docker pull ubuntu这个命令，那么在Cmd函数中，首先要做的便是找到与pull相对应的handler.在这里并不是像一般的做法那样通过提前注册好的 map来查找，而是直接进行一些字符串转换，比如pull对应的叫CmdPull,push对应的叫CmdPush,规则就是首字母大写并且加上一个Cmd前缀.

github.com/docker/docker/api/client/cli.go:

func (cli *DockerCli) getMethod(args ...string) (func(...string) error, bool) {
 camelArgs := make([]string, len(args))
 for i, s := range args {
 if len(s) == 0 {
 return nil, false
 }
 camelArgs[i] = strings.ToUpper(s[:1]) + strings.ToLower(s[1:])
 }
 methodName := "Cmd" + strings.Join(camelArgs, "")
 method := reflect.ValueOf(cli).MethodByName(methodName)
 if !method.IsValid() {
 return nil, false
 }
 return method.Interface().(func(...string) error), true
}

所以我们可以在github.com/docker/docker/api/client/commands.go文件中见到很多个这样的函数:

发送请求

找到了执行函数，下面就是将其他参数传进去并开始执行，我们来看下CmdPull的流程:

我们在拉取镜像时,参数中的image name可以是多种多样的，有以下几类：

只有名字比如ubuntu
名字和 tag 比如ubuntu:14.04
命名空间,名字,(tag) 比如tutum/redis或者后面加个tag
前面有私有仓库地址比如 127.0.0.1:5000/ubuntu:14.04 …

所以我们既要检测参数中是否包含非法字符，也要对这各种情况解析出正确的host地址和name,tag.不过了解了其结构之后，解析的代码就显得简单多了，不再具体分析.

taglessRemote, tag := parsers.ParseRepositoryTag(remote)
if tag == "" && !*allTags {
 newRemote = taglessRemote + ":" + graph.DEFAULTTAG
}

if tag != "" && *allTags {
 return fmt.Errorf("tag can't be used with --all-tags/-a")
}

注意其中的DEFAULTTAG，其值为latest,所以如果我们pull镜像时没有指定tag并且 --all-tags为false，则只会拉取tag为latest的镜像。

参数中的hostname部分需要单独解析出来，因为有安全认证的考虑.需要读取相关的配置文件，并解析参数，最终要作为http header中的参数发送出去.

hostname, _, err := registry.ResolveRepositoryName(taglessRemote)
if err != nil {
 return err
}

cli.LoadConfigFile()

authConfig := cli.configFile.ResolveAuthConfig(hostname)

需要注意的是,如果参数中没有指定hostname，则默认是从官方仓库拉取镜像,其值由变量 INDEXSERVER定义: https://index.docker.io/v1/。

参数解析好之后，便可以执行http请求了。docker pull所发起的是POST请求,地址为 /iamges/create:

v = url.Values{}

v.Set("fromImage", newRemote)

pull := func(authConfig registry.AuthConfig) error {
 buf, err := json.Marshal(authConfig)
 if err != nil {
 return err
 }
 registryAuthHeader := []string{
 base64.URLEncoding.EncodeToString(buf),
 }

 return cli.stream("POST", "/images/create?"+v.Encode(), nil, cli.out, map[string][]string{
 "X-Registry-Auth": registryAuthHeader,
 })
}

if err := pull(authConfig); err != nil {
 ...
}

在web server端，我们可以查到/images/create所对应的handler名称。

github.com/docker/docker/api/server/server.go :

所以下面我们就开始分析postImageCreate的执行流程.

请求处理

之前提到过，daemon将各种操作统一为job的形式，镜像的创建也不例外。所以postImageCreate 的主要工作即是进行job的相关环境的设定：

image = r.Form.Get("fromImage")
repo = r.Form.Get("repo")
tag = r.Form.Get("tag")


if image != "" { //pull
 if tag == "" {
 image, tag = parsers.ParseRepositoryTag(image)
 }
 metaHeaders := map[string][]string{}
 for k, v := range r.Header {
 if strings.HasPrefix(k, "X-Meta-") {
 metaHeaders[k] = v
 }
 }
 job = eng.Job("pull", image, tag)
 job.SetenvBool("parallel", version.GreaterThan("1.3"))
 job.SetenvJson("metaHeaders", metaHeaders)
 job.SetenvJson("authConfig", authConfig)
}

需要注意的是,postImageCreate对应了两个subcommand，分别是pull和import,都是用来创建镜像的，所以它们post的地址一样。二者通过传递不同的参数来区分创建不同的job,具体就是fromImage这个参数.在CmdPull中，我们设置了这个参数，但是在CmdImport 中，则设置了其他的参数,二者流程类似，所以本文只对pull的流程做深入解析.

我们可以从github.com/docker/docker/graph/service.go文件中查到名字为pull的 job对应的handler:

到了这个CmdPull（不要与前面的CmdPull搞混),才真正开始镜像拉取的过程。

镜像拉取

冲突检测

大家可能有过这样的经验，在一个终端下执行docker pull,时间太长，也不确定是不是成功了，就Ctrl-C掉,然后重开一个终端重新执行，这时候就会提示已经有一个client在拉取了，需要等待。这就是CmdPull最开始做的事情：确保只有一个client在拉取同一个镜像:

c, err := s.poolAdd("pull", localName+":"+tag)
if err != nil {
 if c != nil {
 job.Stdout.Write(sf.FormatStatus("", "Repository %s already being pulled by another client. Waiting.", localName))
 <-c
 return engine.StatusOK
 }
 return job.Error(err)
}
defer s.poolRemove("pull", localName+":"+tag)

pollAdd可以对pull和push两个过程进行检测(通过第一个参数),然后通过一个map 确认是否已经有client在拉取第二个参数标识的镜像。

名称解析

CmdPull传入的参数有两个:image和tag。image是包含仓库地址的，我们需要在拉取之前将其解析出来，建立连接,并对镜像名做进一步规范化处理:

hostname, remoteName, err := registry.ResolveRepositoryName(localName)

endpoint, err := registry.NewEndpoint(hostname, s.insecureRegistries)

r, err := registry.NewSession(authConfig, registry.HTTPRequestFactory(metaHeaders), endpoint, true)

if endpoint.VersionString(1) == registry.IndexServerAddress() {
 localName = remoteName

 isOfficial = isOfficialName(remoteName)
 if isOfficial && strings.IndexRune(remoteName, '/') == -1 {
 remoteName = "library/" + remoteName
 }

 mirrors = s.mirrors
}

注意remoteName和localName的区别。我们在拉取镜像时会发现有的镜像没有命名空间, 其实它是有一个默认值library。remote就是带了命名空间的规范化镜像名称.

Registry API 版本

if len(mirrors) == 0 && (isOfficial || endpoint.Version == registry.APIVersion2) {
 j := job.Eng.Job("trust_update_base")
 if err = j.Run(); err != nil {
 return job.Errorf("error updating trust base graph: %s", err)
 }

 if err := s.pullV2Repository(job.Eng, r, job.Stdout, localName, remoteName, tag, sf, job.GetenvBool("parallel")); err == nil {
 if err = job.Eng.Job("log", "pull", logName, "").Run(); err != nil {
 log.Errorf("Error logging event 'pull' for %s: %s", logName, err)
 }
 return engine.StatusOK
 } else if err != registry.ErrDoesNotExist {
 log.Errorf("Error from V2 registry: %s", err)
 }
}

if err = s.pullRepository(r, job.Stdout, localName, remoteName, tag, sf, job.GetenvBool("parallel"), mirrors); err != nil {
 return job.Error(err)
}

从代码中可以看到有两种拉取，分别对应于仓库的两个 API（V1 和 V2)版本。V2 是一种较新的架构，改动较大,具体可见本文后面的链接。下面简要介绍一下官方仓库的拉取流程(示例):

docker client从官方 Index(“index.docker.io/v1”)查询镜像(“samalba/busybox”)的位置
Index 回复:
- samalba/busybox在Registry A上
- samalba/busybox的校验码
- token
docker client 连接Registry A表示自己要获取samalba/busybox
Registry A 询问Index 这个客户端(token/user)是否有权限下载镜像
Index回复是否可以下载
下载镜像的所有layers

V1 和 V2 的区分即是再registry这一层。我们使用私有仓库的时候，都要在拉取的时候指定仓库的 URL,这时候的流程与官方相比就少了Index服务这一层，所以安全性就不高。而且因为没有了校验码，即使镜像损坏，也无法检测到。V2 的设计就是想统一各个仓库之间的不一致,规范其安全性和可靠性等。

具体再使用上,两者的区分现在主要是在官方镜像和非官方镜像之间(isOfficial参数),如果是官方镜像 (ubuntun,library/ubuntu),则是从V2拉取,否则是从v1拉取。下面就以 V2 为中心分析拉取流程。

在拉取之前,有一个叫trust_update_base的job先执行了，从名字上便知是与安全相关的，也是 V2 引入的安全机制之一。docker为此创建了一个新的 libtrust项目,感兴趣的可以自行参考一下。 trust_update_base对应的job在github.com/docker/docker/trust包中,不再详述。

Tag 处理

镜像拉取首先要确定的是tag,分两种情况,一种是指定了--all-tags，需要获取所有 tag的信息,另外就是单个的tag，不管是自己指定的还是默认的latest。

github.com/docker/docker/graph/pull.go#pullV2Repository:

tags, err := r.GetV2RemoteTags(remoteName, nil)
if err != nil {
 return err
}
for _, t := range tags {
 if downloaded, err := s.pullV2Tag(eng, r, out, localName, remoteName, t, sf, parallel); err != nil {
 return err
 } else if downloaded {
 layersDownloaded = true
 }
}

上面代码展示的便是要拉取所有tag的情况，用的仍是标准的REST API,GetV2RemoteTags便是一个标准的 go 语言的GET方法实现，不在详述。我们可以直接从日志中查看到相关信息(docker pull -a centos):

也可以自己再命令行下用curl或httpie工具直接获取:

返回的结果就是一个tags的string列表。有了tags列表，下面要做的就是遍历列表一个一个地下载。

Manifest

要下载一个镜像，我们要先知道它的一些关键信息，比如校验码，层级,各层的联系以及其他各种细节。所以首先要下载的便是这些manifest数据:

先看下MainfestData的定义:

type ManifestData struct {
 Name string `json:"name"`
 Tag string `json:"tag"`
 Architecture string `json:"architecture"`
 FSLayers []*FSLayer `json:"fsLayers"`
 History []*ManifestHistory `json:"history"`
 SchemaVersion int `json:"schemaVersion"`
}

在命令行下之下用httpie获取centos:5的manifest信息如下:

(1). fslayers

各层的checksum信息

(2). History

各层的详细信息,json格式:

(3). 签名及其他

github.com/docker/docker/graph/pull.go#pullV2Tag:

log.Debugf("Pulling tag from V2 registry: %q", tag)
manifestBytes, err := r.GetV2ImageManifest(remoteName, tag, nil)
// 验证各项信息是否正确
manifest, verified, err := s.verifyManifest(eng, manifestBytes)

downloads := make([]downloadInfo, len(manifest.FSLayers))

type downloadInfo struct {
 imgJSON []byte
 img *image.Image
 tmpFile *os.File
 length int64
 downloaded bool
 err chan error
}

downloadInfo里最主要的信息便是镜像的json描述文件,也是从ManifestData中获取的。tmpFile的类型为*os.File,表明真正的下载要开始了。

for i := len(manifest.FSLayers) - 1; i >= 0; i-- {
 var (
 sumStr = manifest.FSLayers[i].BlobSum
 imgJSON = []byte(manifest.History[i].V1Compatibility)
 )

 img, err := image.NewImgJSON(imgJSON)
 if err != nil {
 return false, fmt.Errorf("failed to parse json: %s", err)
 }
 downloads[i].img = img

下载

整个下载流程大概分为以下几步:

(1). 确认此镜像(layer)的ID是否已经存在:

if s.graph.Exists(img.ID) {
 log.Debugf("Image already exists: %s", img.ID)
 continue
}

如果已经存在，表示本地已有此镜像，跳过。

(2). 冲突检测之前提到过在镜像拉取之前有冲突检测，那个是针对指定的镜像名的(比如ubuntu),而此处的冲突主要是针对指定镜像名的各个layer之间的。我们知道很多镜像底层的layer都是共享的，所以如果我们同时在拉取两个不同的镜像，其各自的layers可能会有重叠的部分，所以在每层layer拉取之前都要检测:

if c, err := s.poolAdd("pull", "img:"+img.ID); err != nil {
 if c != nil {
 out.Write(sf.FormatProgress(utils.TruncateID(img.ID), "Layer already being pulled by another client. Waiting.", nil))
 <-c
 out.Write(sf.FormatProgress(utils.TruncateID(img.ID), "Download complete", nil))
 } else {
 log.Debugf("Image (id: %s) pull is already running, skipping: %v", img.ID, err)
 }
}

(3). 下载

// 本地文件名
tmpFile, err := ioutil.TempFile("", "GetV2ImageBlob")
if err != nil {
 return err
}

// 下载
r, l, err := r.GetV2ImageBlobReader(remoteName, sumType, checksum, nil)
if err != nil {
 return err
}
defer r.Close()
io.Copy(tmpFile, utils.ProgressReader(r, int(l), out, sf, false, utils.TruncateID(img.ID), "Downloading"))

docker有自己的临时目录，一般是/var/lib/docker/tmp/，里面都是这种 GetV2RemoteTags开头的文件。GetV2ImageBlobReader仍是执行GET请求,我们可以从日志里看到其URL的格式:

下载地址主要是由Manifest中的blobSum字段组成，在浏览器里粘贴就可以下载这个文件（最终重定向到 AWS)。

在之前的CmdPull job中,有一个parallel的参数,它用来控制下载时各layer之间是否是并行下载:

if parallel {
 downloads[i].err = make(chan error)
 go func(di *downloadInfo) {
 di.err <- downloadFunc(di)
 }(&downloads[i])
} else {
 err := downloadFunc(&downloads[i])
 if err != nil {
 return false, err
 }
}

docker版本1.3以上的都是并行下载。

镜像存储

在docker的使用过程中,本地缓存的镜像会越来越多，我们需要有一个组件来管理这些镜像及其之间的关系，在 Daemon 启动流程中我们提到的graph就是起这个作用。daemon启动时会创建一个Graph实例用来管理镜像,我们新下载的镜像也需要向其“报到”，以纳入整个镜像关系网(树)中。

if d.tmpFile != nil {
 err = s.graph.Register(d.img,
 utils.ProgressReader(d.tmpFile, int(d.length), out, sf, false, utils.TruncateID(d.img.ID), "Extracting"))
 if err != nil {
 return false, err
 }
}

所以我们需要先探究以下Graph的具体构造。

Graph

type Graph struct {
 Root string
 idIndex *truncindex.TruncIndex
 driver graphdriver.Driver
}

三个字段:根目录,索引,底层driver.TruncIndex的作用是使我们可以用长 ID 的前缀来检索镜像:

type TruncIndex struct {
 sync.RWMutex
 trie *patricia.Trie
 ids map[string]struct{}
}

patricia是一个基数树的golang实现。具体可参见go-patricia.

Dirver 则定义了一组抽象的文件系统接口:

type Driver interface {
 ProtoDriver
 // Diff produces an archive of the changes between the specified
 // layer and its parent layer which may be "".
 Diff(id, parent string) (archive.Archive, error)
 // Changes produces a list of changes between the specified layer
 // and its parent layer. If parent is "", then all changes will be ADD changes.
 Changes(id, parent string) ([]archive.Change, error)
 // ApplyDiff extracts the changeset from the given diff into the
 // layer with the specified id and parent, returning the size of the
 // new layer in bytes.
 ApplyDiff(id, parent string, diff archive.ArchiveReader) (bytes int64, err error)
 // DiffSize calculates the changes between the specified id
 // and its parent and returns the size in bytes of the changes
 // relative to its base filesystem directory.
 DiffSize(id, parent string) (bytes int64, err error)
}

PhotoDriver则定义了一个driver的基本功能集：

type ProtoDriver interface {
 // String returns a string representation of this driver.
 String() string
 // Create creates a new, empty, filesystem layer with the
 // specified id and parent. Parent may be "".
 Create(id, parent string) error
 // Remove attempts to remove the filesystem layer with this id.
 Remove(id string) error
 // Get returns the mountpoint for the layered filesystem referred
 // to by this id. You can optionally specify a mountLabel or "".
 // Returns the absolute path to the mounted layered filesystem.
 Get(id, mountLabel string) (dir string, err error)
 // Put releases the system resources for the specified id,
 // e.g, unmounting layered filesystem.
 Put(id string)
 // Exists returns whether a filesystem layer with the specified
 // ID exists on this driver.
 Exists(id string) bool
 // Status returns a set of key-value pairs which give low
 // level diagnostic status about this driver.
 Status() [][2]string
 // Cleanup performs necessary tasks to release resources
 // held by the driver, e.g., unmounting all layered filesystems
 // known to this driver.
 Cleanup() error
}

在daemon启动时，调用了NewGraph接口，如果本身没有镜像的话，那么这个函数所做的基本上只是一些变量的初始化,如果本身已经有镜像存在，则需要重新读取并建立它们之间的联系。

Register

一个新的镜像(layer)向Graph注册主要有以下流程:

1. ID 验证

if err := utils.ValidateID(img.ID); err != nil {
 return err
}

用正则表达式检验其是否包含非法字符,规则是只能包含英语字母和数字

2. 检查是否已经存在

if graph.Exists(img.ID) {
 return fmt.Errorf("Image %s already exists", img.ID)
}

if err := os.RemoveAll(graph.ImageRoot(img.ID)); err != nil && !os.IsNotExist(err) {
 return err
}

graph.driver.Remove(img.ID)

之所以要这么多步删除是为了应对一些特殊情况，比如切换graph driver等，这时候就可能信息不一致的地方。

3. 创建`image rootfs`

到这一步就牵扯到了具体的graph driver实现了，ubuntu上现在都是aufs,下面就以 aufs为例探讨。

if err := graph.driver.Create(img.ID, img.Parent); err != nil {
 return fmt.Errorf("Driver %s failed to create image rootfs %s: %s", graph.driver, img.ID, err)
}

首先，创建mnt和diff两个目录(在/var/lib/docker/aufs下):

github.com/docker/docker/daemon/graphdriver/aufs/aufs.go#Create:

if err := a.createDirsFor(id); err != nil {
 return err
}

github.com/docker/docker/daemon/graphdriver/aufs/aufs.go#createDirsFor:

func (a *Driver) createDirsFor(id string) error {
 paths := []string{
 "mnt",
 "diff",
 }

 for _, p := range paths {
 if err := os.MkdirAll(path.Join(a.rootPath(), p, id), 0755); err != nil {
 return err
 }
 }
 return nil
}

然后，创建layers目录，里面记录了镜像之间的层级关系:

github.com/docker/docker/daemon/graphdriver/aufs/aufs.go#Create:

f, err := os.Create(path.Join(a.rootPath(), "layers", id))
if err != nil {
 return err
}

if parent != "" {
 ids, err := getParentIds(a.rootPath(), parent)
 if err != nil {
 return err
 }

 if _, err := fmt.Fprintln(f, parent); err != nil {
 return err
 }
 for _, i := range ids {
 if _, err := fmt.Fprintln(f, i); err != nil {
 return err
 }
 }
}

我们可以在/var/lib/docker/aufs/layers目录下找一个文件看一下其中的内容:

每一行代表一个镜像，每一行都是上一行的parent镜像。可以猜想大多数的最后一行都一样，即来自于同一个基本镜像 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158。

4. 解压数据,计算 layersize

github.com/docker/docker/graph/graph.go#Register:

img.SetGraph(graph)
if err := image.StoreImage(img, layerData, tmp); err != nil {
 return err
}

tmp即是/var/lib/docker/graph/_tmp，用来暂时存储数据。

首先，解压数据，并存入/var/lib/docker/diff中:

github.com/docker/docker/image/image.go#StoreImage:

layerDataDecompressed, err := archive.DecompressStream(layerData)

if layerTarSum, err = tarsum.NewTarSum(layerDataDecompressed, true, tarsum.VersionDev); err != nil {
 return err
}

if size, err = driver.ApplyDiff(img.ID, img.Parent, layerTarSum); err != nil {
 return err
}

实际的数据解压存储实在driver.ApplyDiff中执行的,aufs的实现中是不需要parent image id的，所以较为简单,只用简单地解压数据并计算大小即可:

github.com/docker/daemon/graphdriver/aufs/aufs.go:

func (a *Driver) ApplyDiff(id, parent string, diff archive.ArchiveReader) (bytes int64, err error) {
 // AUFS doesn't need the parent id to apply the diff.
 if err = a.applyDiff(id, diff); err != nil {
 return
 }

 return a.DiffSize(id, parent)
}

// 解压数据
func (a *Driver) applyDiff(id string, diff archive.ArchiveReader) error {
 return chrootarchive.Untar(diff, path.Join(a.rootPath(), "diff", id), nil)
}

// 遍历目录计算大小
func (a *Driver) DiffSize(id, parent string) (bytes int64, err error) {
 // AUFS doesn't need the parent layer to calculate the diff size.
 return utils.TreeSize(path.Join(a.rootPath(), "diff", id))
}

计算好的大小会暂时存在/var/lib/docker/graph/_tmp/<ID>/layersize文件中:

github.com/docker/docker/image/image.go#StoreImage:

img.Size = size
if err := img.SaveSize(root); err != nil {
 return err
}

同样的,json描述文件也会暂时存在/var/lib/docker/graph/_tmp/<ID>/json中:

f, err := os.OpenFile(jsonPath(root), os.O_CREATE|os.O_WRONLY|os.O_TRUNC, os.FileMode(0600))
if err != nil {
 return err
}

defer f.Close()

return json.NewEncoder(f).Encode(img)

在整个流程中也包含了校验码的对比验证:

github.com/docker/docker/image/image.go#StoreImage:

checksum := layerTarSum.Sum(nil)

if img.Checksum != "" && img.Checksum != checksum {
 log.Warnf("image layer checksum mismatch: computed %q, expected %q", checksum, img.Checksum)
}

image.StoreImage结束后，将_tmp下的数据移到正式的目录里面:

github.com/docker/docker/graph/graph.go#Register:

if err := os.Rename(tmp, graph.ImageRoot(img.ID)); err != nil {
 return err
}

5. 将镜像 ID 加入索引

github.com/docker/docker/graph/graph.go#Register:

graph.idIndex.Add(img.ID)

即前面所说的TruncIndex中。

TagStore

Graph结构存储了各个镜像的元数据及其之间的关系，但仍有一个维度的数据它没有建立关联：名字。我们需要一个能够将镜像名字和tag(ubuntu：14.04)与其镜像 ID(d0955f21bf24)关联起来的数据结构，这就是TagStore：

github.com/docker/docker/graph/tags.go

type TagStore struct {
 path string
 graph *Graph
 mirrors []string
 insecureRegistries []string
 Repositories map[string]Repository
 sync.Mutex
 // FIXME: move push/pull-related fields
 // to a helper type
 pullingPool map[string]chan struct{}
 pushingPool map[string]chan struct{}
}

type Repository map[string]string

在Daemon 启动流程中中已经提到,TagStore的数据存在/var/lib/docker/graph/repositories-<driver-name>中，对aufs来说，就是 repositories-aufs,里面记录了镜像名与镜像 ID 之间的映射：

在镜像向Graph注册之后，我们也需要向TagStore注册:

github.com/docker/docker/graph/pull.go#pullV2Tag:

if err = s.Set(localName, tag, downloads[0].img.ID, true); err != nil {
 return false, err
}

localname是没有进行过命名空间规整的镜像名（即不会有额外的library/）。 downloadds[0].img.ID即是与镜像名相关联的镜像 ID（在Manifest数据中的 History列表中的第一位）。

首先获取这个镜像的Image对象:

github.com/docker/docker/graph/tags.go#Set:

img, err := store.LookupImage(imageName)
store.Lock()
defer store.Unlock()
if err != nil {
 return err
}

如果在TagStore中找不到的话会到Graph中寻找: github.com/docker/docker/graph/tags.go#LookupImage:

img, err := store.GetImage(repos, tag)
store.Lock()
defer store.Unlock()
if err != nil {
 return nil, err
} else if img == nil {
 if img, err = store.graph.Get(name); err != nil {
 return nil, err
 }
}
return img,nil

之后便是对repoName和tag的校验,最后将相关信息写入TagStore的 Repositories(map)中。

if err := store.reload(); err != nil {
 return err
}
var repo Repository
if r, exists := store.Repositories[repoName]; exists {
 repo = r
 if old, exists := store.Repositories[repoName][tag]; exists && !force {
 return fmt.Errorf("Conflict: Tag %s is already set to image %s, if you want to replace it, please use -f option", tag, old)
 }
} else {
 repo = make(map[string]string)
 store.Repositories[repoName] = repo
}
repo[tag] = img.ID
return store.save()

总结

镜像的拉取和存储主要与/var/lib/docker/下面的四个目录有关:

./aufs 镜像实际数据,layer 关系
./graph 镜像 json 描述文件,layersize
./tmp 镜像临时下载目录
./trust 认证相关

所以能实际结合这几个目录下的数据来分析源码,一定会事半功倍.

参考链接

docker 源码分析(4) -- 网络设置

hang.yan@hotmail.com (涯余) — Mon, 16 Feb 2015 21:37:39 +0800

本篇的主要内容是关于docker daemon启动时网络设置的相关部分，在上一篇中已经简要提到(Docker daemon 启动流程) 。主要内容集中在InitDriver函数的解析上。

简介

InitDriver函数位于github.com/docker/docker/daemon/networkdriver/bridge/driver.go中。主要包含参数解析,docker0的创建,iptables的设置等。

网桥设置

确定好将要使用的网桥后,便需要对其 IP 地址进行相关设定。首先看能不能获取到其 IP 地址:

addr, err := networkdriver.GetIfaceAddr(bridgeIface)

docker服务停止后docker0网桥并不删掉，所以如果不是第一次使用，都能成功获取到ip。我们来看下首次创建docker0的情况:

if !usingDefaultBridge {
 return job.Error(err)
}

if err := configureBridge(bridgeIP); err != nil {
 return job.Error(err)
}

addr, err = networkdriver.GetIfaceAddr(bridgeIface)
if err != nil {
 return job.Error(err)
}
network = addr.(*net.IPNet)

如果要使用自己指定的网桥而且获取不到 IP，那就只能当成错误返回了。如果是使用 docker0且获取不到 IP，则就创建并且赋给它 IP，configureBridge参数为bridgeIp，即命令行里的-bip,一般都没有指定，默认值为空。

addrs = []string{
 "172.17.42.1/16",
 "10.0.42.1/16",
 "10.1.42.1/16",
 "10.42.42.1/16",
 "172.16.42.1/24",
 "172.16.43.1/24",
 "172.16.44.1/24",
 "10.0.42.1/24",
 "10.0.43.1/24",
 "192.168.42.1/24",
 "192.168.43.1/24",
 "192.168.44.1/24",
}

for _, addr := range addrs {
 _, dockerNetwork, err := net.ParseCIDR(addr)
 if err != nil {
 return err
 }
 if err := networkdriver.CheckNameserverOverlaps(nameservers, dockerNetwork); err == nil {
 if err := networkdriver.CheckRouteOverlaps(dockerNetwork); err == nil {
 ifaceAddr = addr
 break
 } else {
 log.Debugf("%s %s", addr, err)
 }
 }
}

每次给docker0分配 IP，都会从addrs一个一个地尝试，所以我们一般看到的运行中的 docker0的 IP 都是172.17.42.1/16。对addrs中的 IP,要检测其与nameservers和路由表是否有重叠。nameservers即是从系统的/etc/resolv.conf中读取到的列表,路由表是类似于如下图的结果中的第一列:

有了 IP 之后，再次调用GetIfaceAddr,将获取到的地址赋给addr,后面的IP Tables的设置要用到这个地址。

IPTables 设置

if enableIPTables {
 if err := setupIPTables(addr, icc, ipMasq); err != nil {
 return job.Error(err)
 }
}

下面的重点部分就是介绍setupIPTables函数的流程。因为所涉及到IPTables部分较多，单看代码难以理顺，所以将主要结合程序运行时的日志信息来进行介绍。

IP Masquerade

关于IP Masquerade的介绍,因为个人英语水平有限，怕翻译的不准确，感兴趣可以先看下这个简单的介绍What is IP Masquerade?。简单来说就是用来做对包的源地址做地址转换(NAT)

如果ipmasq参数为真，则插入一条相应的 rule(先检查是否存在，不存在则插入)


natArgs := []string{"POSTROUTING", "-t", "nat", "-s", addr.String(), "!", "-o", bridgeIface, "-j", "MASQUERADE"}

if !iptables.Exists(natArgs...) {
 if output, err := iptables.Raw(append([]string{"-I"}, natArgs...)...); err != nil {
 return fmt.Errorf("Unable to enable network bridge NAT: %s", err)
 } else if len(output) != 0 {
 return &iptables.ChainError{Chain: "POSTROUTING", Output: output}
 }
}

从日志中我们可以看到实际运行的命令是：

这条 rules 的作用是对于 container 向外发出的包做源地址转换操作.

Package Forward

Inter-Container Communitaion

如果启用 Inter-Container Communitaion (icc为真),则实际执行的结果如下:

确保container之间包的转发的target为ACCEPT。

iptables.Raw(append([]string{"-D"}, dropArgs...)...)
if !iptables.Exists(acceptArgs...) {
 log.Debugf("Enable inter-container communication")
 if output, err := iptables.Raw(append([]string{"-I"}, acceptArgs...)...); err != nil {
 return fmt.Errorf("Unable to allow intercontainer communication: %s", err)
 } else if len(output) != 0 {
 return fmt.Errorf("Error enabling intercontainer communication: %s", output)
 }
}

Non-Intercontainer Outgoing Packets

对于non-intercontainer outgoing packets,也将其target设为ACCEPT:

outgoingArgs := []string{"FORWARD", "-i", bridgeIface, "!", "-o", bridgeIface, "-j", "ACCEPT"}
if !iptables.Exists(outgoingArgs...) {
 if output, err := iptables.Raw(append([]string{"-I"}, outgoingArgs...)...); err != nil {
 return fmt.Errorf("Unable to allow outgoing packets: %s", err)
 } else if len(output) != 0 {
 return &iptables.ChainError{Chain: "FORWARD outgoing", Output: output}
 }
}

实际执行的命令为: /sbin/iptables --wait -C FORWARD -i docker0 ! -o docker0 -j ACCEPT

iptables的参数中,-C代表检查,-D删除,-I插入。一般设置都是先检查，没有的话再插入，所以一般日志中见到的都只有-C

Incoming Packets for Existing Connecting

Accept incoming packets for existing connections

existingArgs := []string{"FORWARD", "-o", bridgeIface, "-m", "conntrack", "--ctstate", "RELATED,ESTABLISHED", "-j", "ACCEPT"}

if !iptables.Exists(existingArgs...) {
 if output, err := iptables.Raw(append([]string{"-I"}, existingArgs...)...); err != nil {
 return fmt.Errorf("Unable to allow incoming packets: %s", err)
 } else if len(output) != 0 {
 return &iptables.ChainError{Chain: "FORWARD incoming", Output: output}
 }
}

实际执行的命令为: /sbin/iptables --wait -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEP

Docker Chain

以上两部分就是setIPTables的流程,主要是一些基本的网络设置。除此之外,还有一些针对NAT表中docker chain的设置。

先从日志中看看实际执行的命令是什么:

(-F 删除一条chain中的所有规则,-X删除一条用户自定义的chain,-N创建一条用户自定义的chain,-A在一条chain后面添加一条规则.)

首先是尝试删除docker chain中的规则及其本身:

if err := iptables.RemoveExistingChain("DOCKER"); err != nil {
 return job.Error(err)
}

然后添加新的空的docker chain：

if enableIPTables {
 chain, err := iptables.NewChain("DOCKER", bridgeIface)
 if err != nil {
 return job.Error(err)
 }
 portmapper.SetIptablesChain(chain)
}

最终的nat的表的结果如下图所示:

当有container的端口暴露时，我们就可以看到其中会有新的rules添加进来:

Handlers

网络设置的最后一部分是一些handler的注册，具体见下面列表:

Name	Funciton	Description
allocate_interface	Allocate	Allocate a network interface
release_interface	Release	Release an interface for a select ip
allocate_port	AllocatePort	Allocate an external port and map it to the interface
link	LinkContainers

docker 源码分析(3) -- daemon 启动流程

hang.yan@hotmail.com (涯余) — Thu, 05 Feb 2015 21:37:39 +0800

本篇的主要内容是关于docker daemon的启动流程。其主要内容均包含在 github.com/docker/docker/docker/daemon.go文件中的mainDaemon函数中，本文即按其执行流程分析源码。因为所涉源码较多，所以所涉部分多是点到为止，详细分析会在后续分专篇讲述。

Engine

在mainDaemon的开始处，在确认参数解析无误后,首先便生成了一个Engine的实例:

eng := engine.New()
signal.Trap(eng.Shutdown)

Engine可以说是docker的核心。它用来执行docker的各种操作(统一为job的形式)，管理container的存储。其结构定义为：

type Engine struct {
 handlers map[string]Handler
 catchall Handler
 hack Hack // data for temporary hackery (see hack.go)
 id string
 Stdout io.Writer
 Stderr io.Writer
 Stdin io.Reader
 Logging bool
 tasks sync.WaitGroup
 l sync.RWMutex // lock for shutdown
 shutdown bool
 onShutdown []func() // shutdown handlers
}

大部分均可见名知意，下面对部分字段进行详细解析。

Handler

Engine结构体中中最关键的便是handlers映射表，docker daemon启动时会向其中注册各种功能的handler，比如关于网络设置的、web server、版本等等，然后就可以通过名字调用进行初始化:

type Handler func(*Job) Status

各个模块在初始化时只要设置好相应环境变量并注册一个job即可。统一的函数接口能够让docker内部各组件在代码结构和执行流程上更加清晰一致。

Job

job是Engine最为基本的执行单元。所有的docker操作，比如启动一个 container,在container内部执行一个程序，从网络pull一个镜像等等，都可以用 job来表示。

type Job struct {
 Eng *Engine
 Name string
 Args []string
 env *Env
 Stdout *Output
 Stderr *Output
 Stdin *Input
 handler Handler
 status Status
 end time.Time
 closeIO bool
}

const (
 StatusOK Status = 0
 StatusErr Status = 1
 StatusNotFound Status = 127
)

从结构体的定义来看，job与unix上的进程的结构表示非常类似：名字、参数、环境变量、标准输入输出、退出状态(0 表示成功，其他表示错误)……我们完全可以将其当作像进程一样的概念来看待。

Initializes

New函数用来初始化一个Engine,基本上只是对各变量进行简单的初始化:

func New() *Engine {
 eng := &Engine{
 handlers: make(map[string]Handler),
 id: utils.RandomString(),
 Stdout: os.Stdout,
 Stderr: os.Stderr,
 Stdin: os.Stdin,
 Logging: true,
 }
 eng.Register("commands", func(job *Job) Status {
 for _, name := range eng.commands() {
 job.Printf("%s\n", name)
 }
 return StatusOK
 })
 // Copy existing global handlers
 for k, v := range globalHandlers {
 eng.handlers[k] = v
 }
 return eng
}

注意点:

Engine id是一个随机字符串
注册了一个commands的handler，用来返回Engine所支持的commands(handlers表中的key)列表。
如果已经有预定义好的globalHandlers，也添加到Engine的handlers表中.

Shutdown

Engine关闭的流程大概如下:

不再接受新的执行job的请求
等待所有正在执行中的job结束
并发调用已经注册的各个shutdown handlers
所有handlers结束或者等待 15 秒后返回

具体可参考github.com/docker/docker/engine/engine.go#Shutdown()。

上面mainDaemon中Trap的设置可以让Engine像大多数unix程序一样在接收到信号时做一些指定的操作:

SIGINT 或者 SIGTERM, 直接调用eng.Shutdown,然后程序结束
SIGINT 或者 SIGTERM 在eng.Shutdown执行完成之前重复了 3 次,那么就直接停止执行并且直接结束程序
如果DEBUG环境变量被设置，SIGQUIT会直接让程序退出而不调用eng.Shutdown

Builtins

if err := builtins.Register(eng); err != nil {
 log.Fatal(err)
}

builtins包主要用来给Engine注册一些内部使用的handlers : 网络设置、 apiserver、Events设置和version信息 :

func Register(eng *engine.Engine) error {
 if err := daemon(eng); err != nil {
 return err
 }
 if err := remote(eng); err != nil {
 return err
 }
 if err := events.New().Install(eng); err != nil {
 return err
 }
 if err := eng.Register("version", dockerVersion); err != nil {
 return err
 }

 return nil
}

因为只是注册,具体的执行还在后面，所以这里暂时不深入探讨各个handler的详细内容，等分析到实际执行的时候再结合运行时信息详细探讨，理解起来应该更容易一些。这里只列出注册的handlers映射信息:

Name	Handler
init_networkdriver	bridge.InitDriver
serveapi	apiserver.ServeApi
acceptconnections	apiserver.AcceptConnections
version	dockerVersion

Version

因为dockerVersion的实现比较简单，所以就直接写在了 github.com/docker/docker/builtins/builtins.go里面:

func dockerVersion(job *engine.Job) engine.Status {
 v := &engine.Env{}
 v.SetJson("Version", dockerversion.VERSION)
 v.SetJson("ApiVersion", api.APIVERSION)
 v.SetJson("GitCommit", dockerversion.GITCOMMIT)
 v.Set("GoVersion", runtime.Version())
 v.Set("Os", runtime.GOOS)
 v.Set("Arch", runtime.GOARCH)
 if kernelVersion, err := kernel.GetKernelVersion(); err == nil {
 v.Set("KernelVersion", kernelVersion.String())
 }
 if _, err := v.WriteTo(job.Stdout); err != nil {
 return job.Error(err)
 }
 return engine.StatusOK
}

我们可以直接通过执行docker version命令来查看其大概效果:

Events

我们可以先通过docker events命令来看看docker中Events是干嘛用的。如图，启动一个 container：

在另一个窗口的docker events命令显示结果:

可见Events是类似于 log 的一种东西，不过是一种结构化的记录方式，而且只记录特定的运行时信息。

const eventsLimit = 64

type listener chan<- *utils.JSONMessage

type Events struct {
 mu sync.RWMutex
 events []*utils.JSONMessage
 subscribers []listener
}

func New() *Events {
 return &Events{
 events: make([]*utils.JSONMessage, 0, eventsLimit),
 }
}

而前面提到的events.New().Install(eng)也是向Engine注册了一些handlers:

func (e *Events) Install(eng *engine.Engine) error {
 // Here you should describe public interface
 jobs := map[string]engine.Handler{
 "events": e.Get,
 "log": e.Log,
 "subscribers_count": e.SubscribersCount,
 }
 for name, job := range jobs {
 if err := eng.Register(name, job); err != nil {
 return err
 }
 }
 return nil
}

具体的函数实现则不再赘述。

Registry

if err := registry.NewService(daemonCfg.InsecureRegistries).Install(eng); err != nil {
 log.Fatal(err)
}

registry主要是给Engine提供认证和搜索官方(dockerhub)镜像的能力：

func (s *Service) Install(eng *engine.Engine) error {
 eng.Register("auth", s.Auth)
 eng.Register("search", s.Search)
 return nil
}

如代码所示，Registry注册了auth和search两个handler。

Daemon

经过前面的那么多设置,Engine算是配置的差不多了，下面就是对daemon进行各项配置的时候了:

go func() {
 d, err := daemon.NewDaemon(daemonCfg, eng)
 if err != nil {
 log.Fatal(err)
 }

 log.Infof("docker daemon: %s %s; execdriver: %s; graphdriver: %s",
 dockerversion.VERSION,
 dockerversion.GITCOMMIT,
 d.ExecutionDriver().Name(),
 d.GraphDriver().String(),
 )

 if err := d.Install(eng); err != nil {
 log.Fatal(err)
 }

 b := &builder.BuilderJob{eng, d}
 b.Install()

 if err := eng.Job("acceptconnections").Run(); err != nil {
 log.Fatal(err)
 }
}()

主要内容如下:

daemon各个模块的设置，创建daemon。这部分内容非常长，下面将详述。
打印一些关键日志信息。如下图所示:
向Engine注册daemon所提供的各种handlers,主要就是docker client各种命令的后台实现:
docker build的后台handler实现。因为这个命令实现比较复杂，所以单列。
在daemon设置完成后即启动api server准备接受请求。

Config

Config定义了docker daemon的各项配置:

type Config struct {
 Pidfile string
 Root string
 AutoRestart bool
 Dns []string
 DnsSearch []string
 Mirrors []string
 EnableIptables bool
 EnableIpForward bool
 EnableIpMasq bool
 DefaultIp net.IP
 BridgeIface string
 BridgeIP string
 FixedCIDR string
 InsecureRegistries []string
 InterContainerCommunication bool
 GraphDriver string
 GraphOptions []string
 ExecDriver string
 Mtu int
 DisableNetwork bool
 EnableSelinuxSupport bool
 Context map[string][]string
 TrustKeyPath string
 Labels []string
}

type Daemon struct {
 ID string
 repository string
 sysInitPath string
 containers *contStore
 execCommands *execStore
 graph *graph.Graph
 repositories *graph.TagStore
 idIndex *truncindex.TruncIndex
 sysInfo *sysinfo.SysInfo
 volumes *volumes.Repository
 eng *engine.Engine
 config *Config
 containerGraph *graphdb.Database
 driver graphdriver.Driver
 execDriver execdriver.Driver
 trustStore *trust.TrustStore
}

从这些配置项也可以看出，很多都是与docker启动时的参数一一对应的。NewDaemon函数即通过这些参数来进行daemon的各项设置:

Settings

从上面Config和Daemon的定义也可以看出，二者包含了docker运行时需要关注的绝大部分内容及组件。而具体的设置由 github.com/docker/docker/daemon/daemon.go#NewDaemonFromDirectory完成，因为比较琐碎，所以将其归为以下几类介绍:

network args

因为网络参数比较多，有的还有冲突，所有还要进行一定的检测。关于网络的设置主要由以下几项:

MTU,容器网络的最大传输单元。未指定则使用默认值: 1500。如果网络环境的自定义程度较高，则MTU需要小心设置，不然可能因为额外的封包解包过程导致包大小超过MTU而被丢弃。
--bridge 和 --bip 参数不能同时指定。因为bridge是用来创建自定义的 bridge网络，而--bip是用来给默认的docker0指定其他地址和掩码的。
--iptables=false 和 --icc=false不能同时指定。因为ICC依赖于iptables

…

system

pidfile的创建和管理

if config.Pidfile != "" {
 if err := utils.CreatePidFile(config.Pidfile); err != nil {
 return nil, err
 }
 eng.OnShutdown(func() {
 // Always release the pidfile last, just in case
 utils.RemovePidFile(config.Pidfile)
 })
}

使用pid文件可以说是linux上大多数daemon服务的一种通用模式了: 没有则创建，并且在程序退出时删除(通过shutdown handler来处理)。

操作系统及内核版本检测,要求 linux 3.8 以上的 kernel.

if runtime.GOOS != "linux" {
 return nil, fmt.Errorf("The Docker daemon is only supported on linux")
}

if err := checkKernelAndArch(); err != nil {
 return nil, err
}

权限检测,docker需要root权限运行

if os.Geteuid() != 0 {
 return nil, fmt.Errorf("The Docker daemon needs to be run as root")
}

TempDir设置

这里的TempDir是相对于docker的目录而言的,并不是指系统的/tmp目录。从参数设置上可以看到默认的根目录为/var/lib/docker:

flag.StringVar(&config.Root, []string{"g", "-graph"}, "/var/lib/docker", "Path to use as the root of the Docker runtime")

如果使用默认值，则TempDir为/var/lib/docker/tmp：

func TempDir(rootDir string) (string, error) {
 var tmpDir string
 if tmpDir = os.Getenv("DOCKER_TMPDIR"); tmpDir == "" {
 tmpDir = filepath.Join(rootDir, "tmp")
 }
 err := os.MkdirAll(tmpDir, 0700)
 return tmpDir, err
}

SELinux

检测是否开启SELinux支持。SELinux和Apparmor是 docker 支持的两种安全机制，SELinux功能强大，架构也比较复杂，AppArmor则相反。

if !config.EnableSelinuxSupport {
 selinuxSetDisabled()
}

Docker root directory

Docker所有文件存储的根目录，默认为/var/lib/docker。

graphdriver

graph driver是主要用来管理容器文件系统及镜像存储的组件,与宿主机对各文件系统的支持相关。比如ubuntu上默认使用的是AUFS,Centos上是devicemapper,Coreos上则是btrfs。 graph driver定义了一个统一的、抽象的接口,以一种可扩展的方式对各文件系统提供了支持。


// Set the default driver
graphdriver.DefaultDriver = config.GraphDriver

// Load storage driver
driver, err := graphdriver.New(config.Root, config.GraphOptions)
if err != nil {
 return nil, err
}
log.Debugf("Using graph driver %s", driver)

因为config.GraphDriver并没有设置(没有供用户指定的参数选项)，所以graphDriver会从其支持的文件系统列表中一个一个检测系统是否支持,找到一个支持的即设为要用的 driver :

for _, name := range priority {
 driver, err = GetDriver(name, root, options)
 if err != nil {
 if err == ErrNotSupported || err == ErrPrerequisites || err == ErrIncompatibleFS {
 continue
 }
 return nil, err
 }
 return driver, nil
}

priority列表为:

priority = []string{
 "aufs",
 "btrfs",
 "devicemapper",
 "vfs",
 // experimental, has to be enabled manually for now
 "overlay",
}

如果使用的是btrfs,因为其与SELinux的不兼容，所以还要进行一些检测:

if selinuxEnabled() && config.EnableSelinuxSupport && driver.String() == "btrfs" {
 return nil, fmt.Errorf("SELinux is not supported with the BTRFS graph driver!")
}

之后检测/var/lib/docker/containers目录是否存在，不存在则创建。我们来看看 containers目录下的内容：

每个container创建的时候，与网络有关的配置文件 (/etc/hosts,/etc/resolv.conf等)与其他文件的处理是不同的,他们是通过挂载的方式供container使用的，有点类似于docker container本身的存储方式: 一个只读的层，加上一些可写的层。containers目录就是用来存储这些信息的。

graph

g, err := graph.NewGraph(path.Join(config.Root, "graph"), driver)
if err != nil {
 return nil, err
}

Graph是用来存储标记的文件系统镜像以及他们之间的关系的组件:

type Graph struct {
 Root string
 idIndex *truncindex.TruncIndex
 driver graphdriver.Driver
}

其中idIndex的作用是使我们可以使用长 id 的前缀来检索镜像,Root为Graph的根目录，一般为/var/lib/docker/graph。NewGraph即是用此目录下的文件来重建镜像索引。我们可以查看此目录下的目录的结构:

每一个镜像一个目录，下面包含一个描述镜像信息的 json 文件，也包含了记录镜像大小的 layersize文件。我们用一些实例来对比查看一下,下图是docker images --tree的部分结果:

我们选取487e08镜像来对照,json 文件记录了其parent image的 id、创建时间、大小等等信息。这个大小与 layersize 文件中的相一致。

volumes

Volumes是一种特殊的目录，其数据可以被一个或多个container共享,它和创建它的 container的生命周期分离开来，在container被删去之后能继续存在。在实现上，使用的依然是只读层和读写层结合(union file system)的方式。

volumesDriver, err := graphdriver.GetDriver("vfs", config.Root, config.GraphOptions)
if err != nil {
 return nil, err
}

volumes, err := volumes.NewRepository(path.Join(config.Root, "volumes"), volumesDriver)
if err != nil {
 return nil, err
}

VFS是一个中间层,下面是个各种文件系统实现，对外提供的则是统一的访问接口,这非常类似我们之前提到的GraphDriver的机制。刚开始看这段代码很难知道它是干嘛用的，但我们还可以仿照之前Graph部分先对/var/lib/docker/volumes目录进行一番探究。

我们先用官方的例子创建一个包含Volumes的container：

然后通过docker inspect查看与Volumes相关的信息:

到获取到的目录去看下:

里面什么也没有。我们进到 container 内部在/webapp目录下创建一个文件看看:

可以确定，/var/lib/docker/vfs目录下的目录是用来存储Volumes中实际数据的。我们再来看看/var/lib/docker/volumes目录下的内容:

可以看到，这个目录只用来存储关于Volumes的关键信息的。

明白了这些之后，就会发现上面的代码和之前的与Graph有关的代码是非常类似的 : 初始化driver，然后从相应目录里读取原有的关于image或者container的信息并加载。

repository

repositories, err := graph.NewTagStore(path.Join(config.Root, "repositories-"+driver.String()), g, config.Mirrors, config.InsecureRegistries)
if err != nil {
 return nil, fmt.Errorf("Couldn't create Tag store: %s", err)
}

我们依然先来查看下相关的文件: /var/lib/docker/repositories-aufs :

整个 json 文件记录了所有的镜像的不同的 tag 及其对应的 id.从函数名NewTagStore上也可以看出，tag信息的记录是其主要功能之一。

type TagStore struct {
 path string
 graph *Graph
 mirrors []string
 insecureRegistries []string
 Repositories map[string]Repository
 sync.Mutex
 // FIXME: move push/pull-related fields
 // to a helper type
 pullingPool map[string]chan struct{}
 pushingPool map[string]chan struct{}
}

pullingPool记录有哪些镜像正在被下载，若某一个镜像正在被下载，则驳回其他Docker Client发起下载该镜像的请求。pushingPool记录有哪些镜像正在被上传，若某一个镜像正在被上传，则驳回其他Docker Client发起上传该镜像的请求；

trust

trustDir := path.Join(config.Root, "trust")
if err := os.MkdirAll(trustDir, 0700); err != nil && !os.IsExist(err) {
 return nil, err
}
t, err := trust.NewTrustStore(trustDir)
if err != nil {
 return nil, fmt.Errorf("could not create trust store: %s", err)
}

还是先看/var/lib/docker/trust下的内容:

跟认证签名有关的一些信息。这个文件是从下面这个地方获取到的:

var baseEndpoints = map[string]string{"official": "https://dvjy3tqbc323p.cloudfront.net/trust/official.json"}

然后用其中的内容来初始化TrustStore:

type TrustStore struct {
 path string
 caPool *x509.CertPool
 graph trustgraph.TrustGraph
 expiration time.Time
 fetcher *time.Timer
 fetchTime time.Duration
 autofetch bool
 httpClient *http.Client
 baseEndpoints map[string]*url.URL

 sync.RWMutex
}

init_networkdriver

if !config.DisableNetwork {
 job := eng.Job("init_networkdriver")

 job.SetenvBool("EnableIptables", config.EnableIptables)
 job.SetenvBool("InterContainerCommunication", config.InterContainerCommunication)
 job.SetenvBool("EnableIpForward", config.EnableIpForward)
 job.SetenvBool("EnableIpMasq", config.EnableIpMasq)
 job.Setenv("BridgeIface", config.BridgeIface)
 job.Setenv("BridgeIP", config.BridgeIP)
 job.Setenv("FixedCIDR", config.FixedCIDR)
 job.Setenv("DefaultBindingIP", config.DefaultIp.String())

 if err := job.Run(); err != nil {
 return nil, err
 }
}

前面提到在Builtins里注册了这个handler，这里就利用启动参数进行了相关环境变量的设置并真正开始启动这个 Job。主要内容如下:

bridge及其 ip 设置，一般都是使用默认的docker0。

iptables及ipforward设置。
fixed cidr 设置。这个可以用来限制contaienr从docker0获取到的ip地址的范围。
注册了一些供以后进行各个容器的网络设置的handlers:

for name, f := range map[string]engine.Handler{
 "allocate_interface": Allocate,
 "release_interface": Release,
 "allocate_port": AllocatePort,
 "link": LinkContainers,
} {
 if err := job.Eng.Register(name, f); err != nil {
 return job.Error(err)
 }
}

linkgraph.db

graphdbPath := path.Join(config.Root, "linkgraph.db")
graph, err := graphdb.NewSqliteConn(graphdbPath)
if err != nil {
 return nil, err
}

/var/lib/docker/linkgraph.db是一个 SQLITE3 的数据库文件。里面有两个表: edge 和 entity(两个图理论中常用的概念)。查看其内容:

edge里存储了容器的名字和 id,entity只存储了容器的 id。daemon通过这个数据库来重建容器名称与 id 的关联。

execdriver

sysInfo := sysinfo.New(false)
ed, err := execdrivers.NewDriver(config.ExecDriver, config.Root, sysInitPath, sysInfo)
if err != nil {
 return nil, err
}

docker最开始使用的是linux的lxc作为其底层的容器执行引擎，后来自己开发了 libcontainer，用来替代lxc，所以我们现在看到docker info里显示的Excution Driver是native:

sysinfo是cgroup相关的一些系统信息，lxc exec driver初始化时需要从其中获取关于系统中apparmor的一些信息，但native exec driver不需要。

type SysInfo struct {
 MemoryLimit bool
 SwapLimit bool
 IPv4ForwardingDisabled bool
 AppArmor bool
}

func NewDriver(name, root, initPath string, sysInfo *sysinfo.SysInfo) (execdriver.Driver, error) {
 switch name {
 case "lxc":
 return lxc.NewDriver(root, initPath, sysInfo.AppArmor)
 case "native":
 return native.NewDriver(path.Join(root, "execdriver", "native"), initPath)
 }
 return nil, fmt.Errorf("unknown exec driver %s", name)
}

看看代码中提到的目录/var/lib/docker/execdriver/native:

又是一堆container或者镜像的id,既然是执行引擎了，多半是关于container的一些运行时信息，挑一个进去查看一下:

state.json主要描述了此container所在cgroup的相关目录，网络状态,以及主进程的 pid及启动时间。container.json包含信息较多，部分截图如下:

各个设备的访问权限,主要是/dev下面那些
一些特殊文件的信息。比如/etc/hosts,Volumes,/etc/resolv.conf等等
网络详细信息
capabilites
namespaces
环境变量

Restore

经过前面各个组件的设置及初始化，终于到了daemon的创建了：

daemon := &Daemon{
 ID: trustKey.PublicKey().KeyID(),
 repository: daemonRepo,
 containers: &contStore{s: make(map[string]*Container)},
 execCommands: newExecStore(),
 graph: g,
 repositories: repositories,
 idIndex: truncindex.NewTruncIndex([]string{}),
 sysInfo: sysInfo,
 volumes: volumes,
 config: config,
 containerGraph: graph,
 driver: driver,
 sysInitPath: sysInitPath,
 execDriver: ed,
 eng: eng,
 trustStore: t,
}
if err := daemon.restore(); err != nil {
 return nil, err
}

基本上用到了我们前面设置好的各个组件。之后的restore便开始加载原有的container，将设为自启动的container启动。

Shutdown

前面提到过Engine在关闭时会调用各个注册好的handlers,这里便是一个:

eng.OnShutdown(func() {
 if err := daemon.shutdown(); err != nil {
 log.Errorf("daemon.shutdown(): %s", err)
 }
 if err := portallocator.ReleaseAll(); err != nil {
 log.Errorf("portallocator.ReleaseAll(): %s", err)
 }
 if err := daemon.driver.Cleanup(); err != nil {
 log.Errorf("daemon.driver.Cleanup(): %s", err.Error())
 }
 if err := daemon.containerGraph.Close(); err != nil {
 log.Errorf("daemon.containerGraph.Close(): %s", err.Error())
 }
})

主要进行daemon自身的清理工作，端口的释放，挂载点的卸载,与graphdb连接的关闭。

ServeApi

job := eng.Job("serveapi", flHosts...)
job.SetenvBool("Logging", true)
job.SetenvBool("EnableCors", *flEnableCors)
job.Setenv("Version", dockerversion.VERSION)
job.Setenv("SocketGroup", *flSocketGroup)

job.SetenvBool("Tls", *flTls)
job.SetenvBool("TlsVerify", *flTlsVerify)
job.Setenv("TlsCa", *flCa)
job.Setenv("TlsCert", *flCert)
job.Setenv("TlsKey", *flKey)
job.SetenvBool("BufferRequests", true)
if err := job.Run(); err != nil {
 log.Fatal(err)
}

查看之前在Builtins中注册的handlers表，可知serveapi对应的是 apiserver.ServeApi函数。ServeApi即开始监听参数中指定的各种协议和端口，并准备开始处理http请求了(docker client 与 daemon 的交互都是通过REST API来进行的)。

参考链接

IOPS 介绍

hang.yan@hotmail.com (涯余) — Wed, 04 Feb 2015 21:37:39 +0800

依旧是自己不甚清楚的一个概念，希望通过自己的整理来加深印象，也希望这篇介绍能帮助到其他人。

概念

IOPS,即Input/Output Operations Per Second,每秒钟执行 IO 请求的次数,一般即指读写数据操作，是衡量存储性能的主要指标之一。Throughput(吞吐量)表示的是每秒数据的传输总量，是另一个主要指标。二者关注点不同，对于小 I/O，且传输 I/O 数量比较大的情况下，以 IOPS 衡量为宜，比如 OLTP(On-Line Transcation Processing)系统、小文件存储、邮件服务器等。而对于经常传输大量连续数据的系统，以吞吐量衡量为宜，比如视频点播、视频编辑等。

IO 时间

机械磁盘

机械磁盘完成一次 I/O 请求所花费的时间由寻道时间、旋转延迟和数据传输时间三部分构成：

寻道时间

将读写磁头移动至正确的磁道上所需的时间。目前磁盘的平均寻道时间一般在 3-15ms.
旋转延迟

盘片旋转将请求数据所在扇区移至读写磁头下方所需时间。旋转延迟取决于磁盘转速，通常使用磁盘旋转一周所需时间的 1/2 表示。比如 7200 rpm (每分钟 7200 转)的磁盘，其平均旋转延迟约为 60*1000/7200/2 = 4.17ms。
传输时间

完成传输所请求的数据所需要的时间，它取决于数据传输率，其值等于数据大小除以数据传输率。目前 IDE/ATA 能达到 133MB/s，SATA II 可达到 300MB/s 的接口数据传输率，数据传输时间通常远小于前两部分。

因此，如果忽略数据传输时间，就可以计算出机械磁盘的最大 IOPS.假设磁盘平均物理寻道时间为 3ms, 磁盘转速为 7200,10K,15K rpm，则磁盘 IOPS 理论最大值分别为:

 IOPS = 1000 / (3 + 60000/7200/2) = 140
IOPS = 1000 / (3 + 60000/10000/2) = 167
IOPS = 1000 / (3 + 60000/15000/2) = 200

固态硬盘

固态硬盘 SSD 是一种电子装置，避免了传统磁盘在寻道和旋转上的时间花费，存储单元寻址开销大大降低，因此 IOPS 可以非常高，能够达到数万甚至数十万。

指标

实际测量中，IOPS 数值会受到很多因素的影响，包括 I/O 负载特征(读写比例，顺序和随机，工作线程数，队列深度，数据记录大小)、系统配置、操作系统、磁盘驱动等等。因此对比测量磁盘 IOPS 时，必须在同样的测试基准下进行，即便如何也会产生一定的随机不确定性。通常情况下，IOPS 可细分为如下几个指标：

Toatal IOPS，混合读写和顺序随机 I/O 负载情况下的磁盘 IOPS，这个与实际 I/O 情况最为相符，大多数应用关注此指标。
Random Read IOPS，100%随机读负载情况下的 IOPS.
Random Write IOPS，100%随机写负载情况下的 IOPS。
Sequential Read IOPS，100%顺序负载读情况下的 IOPS。
Sequential Write IOPS，100%顺序写负载情况下的 IOPS。

对于 HDDs 和类似的机械存储设备,random IOPS的时间主要取决于寻道时间，但是对于 SSD 或类似的固态存储设备，则主要取决于存储设备内部的控制器以及memeory interface speeds. 在两种设备上，Sequential IOPS(尤其是使用大的数据块的时候)一般都指示了存储设备的最大带宽:

 IOPS * TransferSizeInBytes = BytesPerSec

参考链接

docker 源码分析(2) -- 主程序及命令行参数解析

hang.yan@hotmail.com (涯余) — Fri, 30 Jan 2015 21:37:39 +0800

研究一个大项目的源码，最好是从main函数入口，一步一步与实际程序相结合，将实际代码与相应相印证。所以本篇的主要内容就是 docker 主程序的启动流程以及命令行参数解析的过程。

程序入口

docker 的main函数位于github.com/docker/docker/docker/docker.go文件中。代码不是很长，逻辑也比较简单，主要的内容便是解析命令行参数并且进行各项设定，启动 daemon等。下面将详述各个部分。

命令行参数解析

支持命令行参数几乎是所有 cmd 程序所必备的功能，先不看 docker 的代码，依据我们过去的经验，应该不难理出命令行参数解析的一般流程 :

设定好程序所支持的命令行参数列表，长选项、短选项、数据类型、默认值、描述信息……等
一个一个解析实际输入的参数，获取实际值。其中要考虑短选项的组合、错误的参数、出错的提示信息……

在 docker 的main函数中，命令行参数解析的功能主要由mflag包提供，而在main里只需要这一句调用 :

import (
 flag "github.com/docker/docker/pkg/mflag"
 ...
)

flag.Parse()

看函数名的意思，应该就是直接开始解析了。那解析前的设定在哪呢？

init 设定

在 golang 中,main并不总是最早开始执行的代码。在执行一个package中的代码的时候，需要先初始化其package-level的变量以及执行init函数，如果有的话。如果导入了其他的包，也要先对其进行初始化。在docker中,命令行参数的初始化设定即是通过包内的变量及 init函数来进行的。

github.com/docker/docker/docker/flags.go:

flVersion = flag.Bool([]string{"v", "-version"}, false, "Print version information and quit")
flDaemon = flag.Bool([]string{"d", "-daemon"}, false, "Enable daemon mode")
flDebug = flag.Bool([]string{"D", "-debug"}, false, "Enable debug mode")
...
flLogLevel = flag.String([]string{"l", "-log-level"}, "info", "Set the logging level")

在命令行里输入docker看下:

可以看到结果和代码是一一对应的。

各个参数的设定都是类似的，长/短选项，默认值,描述信息。进入其中一个函数看看：

github.com/docker/docker/pkg/mflag/flag.go:

 func Bool(names []string, value bool, usage string) *bool {
 return CommandLine.Bool(names, value, usage)
 }

各个参数依其数据类型分类,我们先看看CommandLine是什么 :

github.com/docker/docker/pkg/mflag/flag.go :

 var CommandLine = NewFlagSet(os.Args[0], ExitOnError)

 func NewFlagSet(name string, errorHandling ErrorHandling) *FlagSet {
 f := &FlagSet{
 name: name,
 errorHandling: errorHandling,
 }
 return f
 }

CommandLine属于package-level的变量，在被 docker 的main包导入时就已经初始化好了。CommandLine就是我们预设命令行参数的存储地方，其类型为FlagSet。

FlagSet

Flagset存储了我们预先设定好的所支持的命令行参数信息，并且在解析过程中动态更新 :

github.com/docker/docker/pkg/mflag/flag.go :

 type FlagSet struct {
 Usage func()
 name string
 parsed bool
 actual map[string]*Flag
 formal map[string]*Flag
 args []string
 errorHandling ErrorHandling
 output io.Writer
}

Usage : 见名知意，可知是用来输出help信息的。一般是在没输入参数或者参数出错的时候使用
name : CommandLine将其设为docker(os.Args[0]).
parsed : 是否已经解析完成
actual : 实际解析出来的命令行参数结果.
formal : 存储预先定义好的所支持的命令行参数信息。
args : 输入的命令行参数列表
errorHandling : 解析遇到错误时的处理方式。

每一个命令行参数所对应的结构体为Flag,其定义为 :

github.com/docker/docker/pkg/mflag/flag.go :

 type Flag struct {
 Names []string // name as it appears on command line
 Usage string // help message
 Value Value // value as set
 DefValue string // default value (as text); for usage message
 }

定义简单明了，Names为string列表是因为很多参数既有长类型也有短类型，两个名字都存下来。还有一些个别的情况时将要废弃的参数形式，比如:

 flEnableCors = flag.Bool([]string{"#api-enable-cors", "-api-enable-cors"}, false, "Enable CORS headers in the remote API")

其名字前有一个#符号。在解析时如果遇到这类参数，会输出一些警告信息 :

github.com/docker/docker/pkg/mflag/flag.go#parseOne() :

for i, n := range flag.Names {
 if n == fmt.Sprintf("#%s", name) {
 replacement := ""
 for j := i; j < len(flag.Names); j++ {
 if flag.Names[j][0] != '#' {
 replacement = flag.Names[j]
 break
 }
 }
 if replacement != "" { // 内容过长，省略部分。
 fmt.Fprintf(f.out(), "Warning: '-%s' is deprecated, ...)
 } else {
 fmt.Fprintf(f.out(), "Warning: '-%s' is deprecated, ...)
 }
 }
}

效果如下图所示 :

设置过程

这里说的设置过程是指在package初始化时所设定的支持的命令行参数的过程，以前面提到过的daemon参数为例。

 flDaemon = flag.Bool([]string{"d", "-daemon"}, false, "Enable daemon mode")

前面已经提到过，flag大部分的操作都由CommandLine变量执行,调用结果为:

func (f *FlagSet) Bool(names []string, value bool, usage string) *bool {
 p := new(bool)
 f.BoolVar(p, names, value, usage)
 return p
}

基本上还是向下传递参数，只不过多了一个p,p是一个指针，flDaemon和p指向同一个地址，即参数的值。前面说过在解析过程中会动态更新参数的值，用指针既可保证 flDaemon指向的是最后实际解析出来的值。

func BoolVar(p *bool, names []string, value bool, usage string) {
 CommandLine.Var(newBoolValue(value, p), names, usage)
}

type boolValue bool

func newBoolValue(val bool, p *bool) *boolValue {
 *p = val
 return (*boolValue)(p)
}

type 定义了一个新的类型boolValue,可以猜想处理string会有stringValue,处理in会有intValue…它们都实现了Value接口:

type Value interface {
 String() string
 Set(string) error
}

Value是用于动态存储位于Flag中的值的接口.想想看,在最开始解析命令行参数时,我们需要对不同的类型作分别处理,有了统一的Value接口, 后续的处理就可以统一进行,不用对每种类型都定义处理函数.

以int为例,其intValue各接口定义如下:

type intValue int

func newIntValue(val int, p *int) *intValue {
 *p = val
 return (*intValue)(p)
}

func (i *intValue) Set(s string) error {
 v, err := strconv.ParseInt(s, 0, 64)
 *i = intValue(v)
 return err
}

func (i *intValue) Get() interface{} { return int(*i) }

func (i *intValue) String() string { return fmt.Sprintf("%v", *i) }

其他类型与此类似，稍有不同的是bool类型。因为bool类型的参数通常并不需要明确地指明其值，只要参数出现，即可认为为true。比如-d参数,并不需要写-d=true。针对这种情况,boolValue提供了额外的IsBoolFlag()函数和boolFlag interface.

func (b *boolValue) IsBoolFlag() bool { return true }

type boolFlag interface {
 Value
 IsBoolFlag() bool
}

再回到原来的处理流程，看看最终的Var函数的实现 :

func (f *FlagSet) Var(value Value, names []string, usage string) {
 flag := &Flag{names, usage, value, value.String()}
 for _, name := range names {
 name = strings.TrimPrefix(name, "#")
 _, alreadythere := f.formal[name]
 if alreadythere {
 var msg string
 if f.name == "" {
 msg = fmt.Sprintf("flag redefined: %s", name)
 } else {
 msg = fmt.Sprintf("%s flag redefined: %s", f.name, name)
 }
 fmt.Fprintln(f.out(), msg)
 panic(msg)
 }
 if f.formal == nil {
 f.formal = make(map[string]*Flag)
 }
 f.formal[name] = flag
 }
}

整个逻辑比较简单，先生成相应的Flag变量，然后建立各个参数名(长短名，将要废弃的名字)对其的映射。各个参数均以此流程设置，最后都存储在FlagSet的formal映射表中，后续的解析便可以对照着处理了。

解析过程

func Parse() {
 CommandLine.Parse(os.Args[1:])
}

解析过程和设定过程一样都是由CommandLine变量来执行的，Parse直接读取全部参数 (除Args[0]即docker外)进行处理 :

首先将parsed置为true,然后将所有参数存入CommandLine的args,之后便是逐个处理参数，在for循环内一直调用parseOne，处理出错的参数，依据errorHandling的设置来决定是继续还是退出等等。我们先看看parseOne的实现,因为函数代码过长，分段详述:

先判断是不是一个 flag

if len(f.args) == 0 {
 return false, "", nil
}
s := f.args[0]
if len(s) == 0 || s[0] != '-' || len(s) == 1 {
 return false, "", nil
}
if s[1] == '-' && len(s) == 2 { // "--" terminates the flags
 f.args = f.args[1:]
 return false, "", nil
}
name := s[1:]
if len(name) == 0 || name[0] == '=' {
 return false, "", f.failf("bad flag syntax: %s", s)
}

len(f.args) == 0 一般代表解析的终止,没有更多的参数了，结合上述Parse函数中的判断，此时就会跳出for循环，正常结束解析流程。其他的几种args[0]情况也会导致相同结果:

长度为 0 或 1
不以-开头
值为 --
格式错误，比如-=之类的。

如果确定args[0]是一个 flag,其会从f.args去除，以便下一次处理的args[0]是下一个参数。如果args[0]是形如--debug=false的格式，便需从中取出相应的name和 value：

f.args = f.args[1:]
has_value := false
value := ""
if i := strings.Index(name, "="); i != -1 {
 value = trimQuotes(name[i+1:])
 has_value = true
 name = name[:i]
}

有了name和value后，便可以与之前存在f.formal中的参数列表相对照,看其是否属于程序所支持的参数:

flag, alreadythere := m[name] // BUG
if !alreadythere {
 if name == "-help" || name == "help" || name == "h" {
 f.usage()
 return false, "", ErrHelp
 }
 if len(name) > 0 && name[0] == '-' {
 return false, "", f.failf("flag provided but not defined: -%s", name)
 }
 return false, name, ErrRetry
}

前面提到过CommandLine的errorHandling是ErrorOnExit，碰到错误会直接退出。如果没有在formal表中找到相应的记录,有三种情况，一种是需要查看帮助信息，系统就在打印好帮助信息后退出，另一种是程序不支持的参数，打印错误信息退出。最后一种是短参数写在了一起，比如-dD,代表--daemon --debug,这种情况需要返回上层继续处理，我们也可以看到在Parse函数中对ErrRetry作了单独处理,将参数字符串分割为单个字母，然后分别解析。

之后需要对bool类型的参数做特殊处理，原因前已详述:

if fv, ok := flag.Value.(boolFlag); ok && fv.IsBoolFlag() {
 if has_value {
 if err := fv.Set(value); err != nil {
 return false, "", f.failf("invalid boolean value %q for -%s: %v", value, name, err)
 }
 } else {
 fv.Set("true") //默认为 true
 }
}

对于其他的类型，则必须解析到其值:

else {
 // It must have a value, which might be the next argument.
 if !has_value && len(f.args) > 0 {
 // value is the next arg
 has_value = true
 value, f.args = f.args[0], f.args[1:]
 }
 if !has_value {
 return false, "", f.failf("flag needs an argument: -%s", name)
 }
 if err := flag.Value.Set(value); err != nil {
 return false, "", f.failf("invalid value %q for flag -%s: %v", value, name, err)
 }
}

一般情况下都是以args列表中的下一个字符串为其值。至此，一个参数解析流程将结束，后面只要不断重复此过程即可，除了需要对将要废弃的参数打印一些警告信息。当处理结束时,CommandLine的formal映射表中包含了所有预设的参数及更新的值，actual表中只包含了程序运行时实际使用的参数及其信息。

后续设定

除了参数解析，整个main函数的其他部分就是比较简单地用解析到的值设置各个组件，理解了前者之后，后面的部分就没有什么难点了。

版本号

if *flVersion {
 showVersion()
 return
}

代码其实没什么好说的，这里主要想提及的是docker里设置版本号的方式。在docker根目录下会有一个VERSION文件，里面记录了程序的版本号，然后在编译脚本中会读取其内容来进行设置:

github.com/docker/docker/hack/make.sh :

VERSION=$(cat ./VERSION)

日志级别

if *flLogLevel != "" {
 lvl, err := log.ParseLevel(*flLogLevel)
 if err != nil {
 log.Fatalf("Unable to parse logging level: %s", *flLogLevel)
 }
 initLogging(lvl)
} else {
 initLogging(log.InfoLevel)
}

if *flDebug {
 os.Setenv("DEBUG", "1")
 initLogging(log.DebugLevel)
}

有两个设置日志的参数 : --log-level 和 --debug，后者只是为了方便使用，且优先级更高。

sockets

if len(flHosts) == 0 {
 defaultHost := os.Getenv("DOCKER_HOST")
 if defaultHost == "" || *flDaemon {
 // If we do not have a host, default to unix socket
 defaultHost = fmt.Sprintf("unix://%s", api.DEFAULTUNIXSOCKET)
 }
 defaultHost, err := api.ValidateHost(defaultHost)
 if err != nil {
 log.Fatal(err)
 }
 flHosts = append(flHosts, defaultHost)
}

docker daemon可以监听三种类型的socket :

unix

由上面代码可知，这是默认的形式，位于 /var/run/docker.sock。
tcp

远程访问(web api)需要开启tcp socket,默认是不加密和无需认证的。如果需要监听所有interface,可以设为-H tcp://0.0.0.0:2375,或者可以自己指定特定的 IP。
fd

基于systemd的系统可以用到，便于其他服务通过systemd socket activation与 docker daemon交互。详见:sockert activation。

flHosts是一个列表，可以多次指定-H参数。

daemon

if *flDaemon {
 mainDaemon()
 return
}

docker并不像redis等程序那样分为server和client程序，区别即在这里。如果有-d参数，就以daemon方式启动，没有，就当做是client.,然后继续解析子命令及其参数进行处理。后面介绍的流程就是只针对client而言。

TLS 认证

即使对 TLS 的原理不是很了解，通过下面的代码，也很容易理解docker的认证过程:

与此相关的主要有四个参数 :

如果--tlsverify或者--tls为true,则启用 TLS 认证。通过指定的三个 PEM 文件，生成一个tls.Config,用于后面的docker client与docker daemon的连接。

DockerCli


protoAddrParts := strings.SplitN(flHosts[0], "://", 2)

if *flTls || *flTlsVerify {
 cli = client.NewDockerCli(os.Stdin, os.Stdout, os.Stderr, nil, protoAddrParts[0], protoAddrParts[1], &tlsConfig)
} else {
 cli = client.NewDockerCli(os.Stdin, os.Stdout, os.Stderr, nil, protoAddrParts[0], protoAddrParts[1], nil)
}

子命令

最后一部分便是docker client子命令的解析与执行，比如doker ps,docker stop <id>等等。具体细节就留待以后解析了。

if err := cli.Cmd(flag.Args()...); err != nil {
 if sterr, ok := err.(*utils.StatusError); ok {
 if sterr.Status != "" {
 log.Println(sterr.Status)
 }
 os.Exit(sterr.StatusCode)
 }
 log.Fatal(err)
}

现代化的开发人员实用工具

hang.yan@hotmail.com (涯余) — Fri, 30 Jan 2015 21:37:39 +0800

常年混迹于 linux，对命令行程序情有独钟，平时也喜欢搜集各种实用的小工具。github流行以来，越来越多的新的实用的开发工具开源出来，有的可以用来替代一些老的工具，有的则是全新的。本文整理一些实用的工具，希望大家能在实际开发中用到。

httppie

website / github

一个命令行版的http客户端,github上的 star 数已经超过 13000。可以用非常自然的语法来发送 http 请求，并且彩色化输出结果。可以用来测试，调试，与web server交互等。官网上有详细的文档以及示例，很容易上手.

在用 docker 的时候用httpie代替curl与web server交互就非常方便,比如搜索镜像,用curl:

用httpie:

icdiff

website / github

意为Improved colored diff,可以用来替代原生的diff。

slap

github

类似sublime text的命令行版的编辑器，感觉在服务器上使用会很方便。

VS 前项目经理开发的新一代 IDE : Light Table。

Github 发布的 Atom :

jq

website / github

命令行版的json处理工具,经常用来排版输出。

在没有jq的情况下，可以使用python -mjson.tool来处理，不过没有着色功能了。

cheat

github

man的补充。经常想使用一个命令，但是却不知道用什么参数，man命令常常的英文又不想看,这时候就可以用到cheat了。cheat不提供全面的解释，但是给出了不少常用的使用示例，让你很快就知道用法。

gource

website

打不开的话，github的 fork 地址为: https://github.com/acaudwell/Gource。

Software version control visualization。可视化代码提交历史，可以用于各种分布式代码管理系统。

可以制作成非常酷炫的视频用于展示。youtube和优酷上应该有很多演示视频，感兴趣的可以自行查看。我们有一次发布会就用的这个工具制作了一部分视频。

finalterm

website / github

是一个 terminal 工具，linux 上的 terminal 工具多如牛毛，常见的有 KDE 的konsole,GNOME 的gnome-terminal，XFCE 的Terminal,以及古老但非常强大的xterm，urxvt。这个算起来是较新的一个,UI 不错。

机械领域的两大美学趋向便是蒸汽朋克与赛博朋克。如果上面的finalterm属于赛博朋克流派的话，下面的两个便是蒸汽朋克风格的经典之作:

cool-retro-term :

vinterm :

q

website / github

在 CSV 或者 TSV 文件上执行 SQL 查询。

textql,功能类似，golang 写的:

ranger

website / github

比较老的一个软件了，命令行下的文件管理器,类似 VI 的键绑定。可扩展性很强，支持很多种文件类型的预览。

cv

github

显示 cp,rm,dd…等命令的进展：

oh-my-zsh

website / github

zsh 的配置文件，在 github 上的 star 数超过 21000，可想而知它是多么的火。作为 bash 的替代品,zsh提供了极强的可扩展能力。智能的自动补全，历史命令查询复用,丰富的 PS1 定制…… 通过一些简单的配置，能够大幅度提高你的工作效率。

另一个优秀的bash替代品是 fish-shell,相对于 zsh 的优点是无需配置便提供了非常丰富的功能:

babun

github

windows 下的一个非常优秀的terminal工具。

impress.js

website / github

github 上 star 数目最多的列表中第一页就可以看到，用来做非常酷炫的 PPT.Demo 链接 :Demo

ungit

github

使用 git 的便捷工具,有非常漂亮的 UI，github 集成。

stackedit

website / github

浏览器里的markdown编辑器,功能丰富,支持与多个云存储平台的同步:

cmdlinefu

github

最后是一个网站，有很多人分享的非常实用的命令:

docker 源码分析(1) -- 开发环境准备

hang.yan@hotmail.com (涯余) — Thu, 29 Jan 2015 21:37:39 +0800

之前看过一遍docker的代码，但比较粗略。第二遍准备详细过一遍并且用博客的方式将其整理一下。目前为止docker的稳定版本为1.4.1,所以就以此版本的代码为基础进行阅读，分析。

本篇内容

一个大项目的源码阅读当然是从主程序入口开始最好, 一步一步，结合实际程序进行测试分析。本来准备一起介绍相关环境设置以及源码中关于启动部分的，但前者内容较多，所以单列一篇进行介绍。

源码编译 docker

构建

ubuntu的docker源有 1.4.1 版本的 docker，可以直接用来与代码进行对照测试。但是能自己手动编译一遍还是很有好处的。docker 官网上关于开发环境设置的博客 (Setting Up a Dev Environment) ，里面已经讲的很清楚了,下面仅作简要描述，详细内容请参考官方文档。

首先看一下 docker 源码的目录结构 :

下面有一个makefile文件和一个Dockerfile。直接执行make，会根据Dockerfile创建镜像，里面包含特定版本的golang(由源码编译)以及其他编译 docker 所需的依赖，当前目录的 docker 源码也会被整个拷贝进镜像里用于编译。最后根据生成的镜像创建container用于实际的编译并生成可执行程序。注意最后生成的可执行程序是位于container内部的，所以如果要使用所编译的程序，应该使用如下命令 :

 sudo make binary

最终生成的程序位于./bundles/<version>-dev/binary/,如果没有看到这些文件，一般都是因为BINDDIR环境变量有问题，此时可以执行如下命令 :

 sudo make BINDDIR=. binary

可以用生成的程序替换系统程序来方便测试 :

 sudo service docker stop ; sudo cp $(which docker) $(which docker)_ ; sudo cp ./bundles/<version>-dev/binary/docker-<version>-dev $(which docker);sudo service docker start

注意事项

第一次构建过程会很长，因为需要从源码构建golang,llvm以及 clone 一些依赖项目。后续再次构建时会复用之前生成的中间镜像，所以会很快。
在墙内的话，一般第一次编译都会失败，因为有两个所需的网站被墙。。。第一个是 golang的下载网站，这个很好解决,因为有好多网站对它做了镜像。docker v1.4.1 所用的 golang 版本为 1.3.3，Dockerfile 中可以看到文件名 :
```
 RUN curl -sSL https://golang.org/dl/go1.3.3.src.tar.gz | tar -v -C /usr/local -xz
```
在谷歌用 Index of 搜索此文件 :
```
 "Index of" go1.3.3.src.tar.gz
```
找一个可用的网站替换 Dockerfile 中的 URL 即可，下面是一个可用的 : http://pkgs.fedoraproject.org/repo/pkgs/golang/go1.3.3.src.tar.gz/2cdbad6baefcf1007f3cf54a5bc878b7/go1.3.3.src.tar.gz

另一个被墙的便是golang.org,解决办法是从 github 上从 github 上下载其 fork 版本,并且用软连接或者直接拷贝到相应目录即可。具体步骤是 :
- Dockerfile 构建镜像会有好多中间镜像，找到最后成功构建的那一个,用其创建一个 container来进行操作
- 从 github 上下载相关项目。我自己 fork 了一个，可以直接使用 https://github.com/hangyan/golang.org
- 做 link 或者 copy :
```
 mkdir -p /go/src/golang.org/ && ln -sf
/go/src/github.com/hangyan/golang.org/x /go/src/golang.org/x
```
- 提交镜像，修改 Dockerfile，将其作为新的 baseimage。中间已经成功的很多步骤也可以删掉了。
Dockerfile 中将GOPATH 设了两个目录,如下所示 :
```
 ENV GOPATH /go:/go/src/github.com/docker/docker/vendor
```
原因是由于 docker 依赖项目较多，所以大部分依赖都已经在 vendor目录下提供，编译时将其设为GOPATH即可使用。

开发环境

IDE

刚开始用golang的时候，好多 IDE 还在初级阶段,缺少很多必须的功能，所以就一直用 Emacs 了。IDE 基本不用配置，上手简单，嫌麻烦的可以直接使用。下面是一个常用 IDE 的列表及链接。

LiteIDE : sourceforge.

感觉界面不好看。
Zeus IDE : zeus

windows 上的，没用过.
Go IDE : go-ide

基于 Intellij IDEA 做的一个 IDE,功能比较简单。
Golang Komodo : Komodo

是一个 Komodo 平台的插件。

Emacs

有很多关于 Golang 的插件可以使用，下面是我在使用的一些插件及配置 :

go-mode

除了基本的语法高亮及自动对齐之外，还提供了如下功能 :

gofmt 集成，保存时自动排版代码
godoc 集成,
import 管理
godef 代码跳转

依赖code.google.com/p/rog-go/exp/cmd/godef项目，依旧被墙。可以从 github 上 fork 的项目来 build,地址为godef
flymake 集成，实施检查代码语法错误。

Emacs 配置示例：

 (require 'go-mode)
(add-hook 'before-save-hook 'gofmt-before-save)

gocode

提供代码自动补全功能，依赖于autocomplete或company。这个项目在 github 上的 star 数已经超过 2000,可见其流行程度。其主页上已经有关于 Emacs 的配置，此处不再详述。

xcscope

xcscope 可以作为godef的一个补充项，它可以将一个目录下的代码包含的 symbols 和文件建成一个索引数据库，然后从其中查询。原生的 xcscope 并不支持 go 语言，需要修改其索引脚本。我现在使用的脚本链接为 cscope-indexer 。

ecb

浏览代码神器，可以自己定制各窗口大小，内容 :

helm

Emacs 原生M-x增强工具，功能极多，还可以用来浏览当前文件的代码结构及跳转到相应函数或变量定义。

主要的插件就这几个，如果有兴趣，可以参考我的 Emacs 配置 : Emacs。

RAID 介绍

hang.yan@hotmail.com (涯余) — Sun, 25 Jan 2015 21:37:39 +0800

RAID 是一个我们经常能见到的名词。但却因为很少能在实际环境中体验,所以很难对其原理能有很清楚的认识和掌握。本文将对 RAID 技术进行介绍和总结，以期能尽量阐明其概念。

RAID 全称为独立磁盘冗余阵列(Redundant Array of Independent Disks),基本思想就是把多个相对便宜的硬盘组合起来，成为一个硬盘阵列组，使性能达到甚至超过一个价格昂贵、容量巨大的硬盘。RAID 通常被用在服务器电脑上，使用完全相同的硬盘组成一个逻辑扇区, 因此操作系统只会把它当做一个硬盘。

RAID 分为不同的等级，各个不同的等级均在数据可靠性及读写性能上做了不同的权衡。在实际应用中，可以依据自己的实际需求选择不同的 RAID 方案。

标准 RAID

RAID 0

RAID0 称为条带化(Striping)存储,将数据分段存储于各个磁盘中，读写均可以并行处理。因此其读写速率为单个磁盘的 N 倍(N 为组成 RAID0 的磁盘个数)，但是却没有数据冗余，单个磁盘的损坏会导致数据的不可修复。

大多数striping的实现允许管理者通过调节两个关键的参数来定义数据分段及写入磁盘的方式,这两个参数对 RAID0 的性能有很重要的影响。

stripe width

stripe width是指可被并行写入的 stripe 的个数,即等于磁盘阵列中磁盘的个数。

stripe size

也可称为 block size(chunk size,stripe length,granularity)，指写入每个磁盘的数据块大小。以块分段的 RAID 通常可允许选择的块大小从 2KB 到 512KB 不等，也有更高的，但一定要是 2 的指数倍。以字节分段的(比如 RAID3)一般的stripe size为 1 字节或者 512 字节，并且用户不能调整。

stripe size对性能的影响是很难简单估量的，最好在实际应用中依自己需求多多调整并观察其影响。通常来说，减少stripe size,文件会被分成更小的块，传输数据会更快，但是却需要更多的磁盘来保存,增加positioning performance,反之则相反。应该说，没有一个理论上的最优的值。很多时候，也要考虑磁盘控制器的策略,比如有的磁盘控制器会等等到一定数据量才开始往磁盘写入。

RAID 1

镜像存储(mirroring)，没有数据校验。数据被同等地写入两个或多个磁盘中，可想而知，写入速度会比较慢，但读取速度会比较快。读取速度可以接近所有磁盘吞吐量的总和,写入速度受限于最慢的磁盘。

RAID1 也是磁盘利用率最低的一个。如果用两个不同大小的磁盘建立 RAID1,可以用空间较小的那一个，较大的磁盘多出来的部分可以作他用，不会浪费。

RAID 2

RAID0 的改良版，加入了汉明码(Hanmming Code)错误校验。

汉明码能够检测最多两个同时发生的比特错误，并且能够更正单一比特的错误。汉明码的位数与数据的位数有一个不等式关系，即:

2^P ≥ P + D +1

P 代表汉明码的个数，D 代表数据位的个数,比如 4 位数据需要 3 位汉明码，7 位数据需要 4 位汉明码，64 位数据时就需要 7 位汉明码。RAID2 是按 1bit 来分割数据写入的，而 P:D 就代表了数据盘与校验盘的个数。所以如果数据位宽越大，用于校验的盘的比例就越小。由于汉明码能够纠正单一比特的错误，所以当单个磁盘损坏时，汉明码便能够纠正数据。

RAID 2 因为每次读写都需要全组磁盘联动，所以为了最大化其性能，最好保证每块磁盘主轴同步，使同一时刻每块磁盘磁头所处的扇区逻辑编号都一致，并存并取，达到最佳性能。如果不能同步，则会产生等待，影响速度。

与 RAID0 相比，RAID2 的传输率更好。因为 RAID0 一般stripe size 相对于 RAID2 的 1bit 来说实在太大，并不能保证每次都是多磁盘并行。而 RAID2 每次 IO 都能保证是多磁盘并行，为了发挥这个优势，磁盘的寻道时间一定要减少(寻道时间比数据传输时间要大几个数量级),所以 RAID2 适合于连续 IO,大块 IO(比如视频流服务)的情况。

RAID 3

类似于 RAID2,数据条带化(stripe)存储于不同的硬盘,数据以字节为单位，只是 RAID3 使用单块磁盘存储简单的奇偶校验信息，所以最终磁盘数量为 N+1。当这 N+1 个硬盘中的其中一个硬盘出现故障时，从其它 N 个硬盘中的数据也可以恢复原始数据,当更换一个新硬盘后，系统可以重新恢复完整的校验容错信息。

由于在一个硬盘阵列中，多于一个硬盘同时出现故障率的几率很小，所以一般情况下，使用 RAID3，安全性是可以得到保障的。RAID 3 会把数据的写入操作分散到多个磁盘上进行，不管是向哪一个数据盘写入数据，都需要同时重写校验盘中的相关信息。因此，对于那些经常需要执行大量写入操作的应用来说，校验盘的负载将会很大，无法满足程序的运行速度，从而导致整个 RAID 系统性能的下降。鉴于这种原因，RAID 3 更加适合应用于那些写入操作较少，读取操作较多的应用环境，例如数据库和 WEB 服务器等。

RAID 4

与 RAID3 类似，但 RAID4 是按块(扇区)存取。无须像 RAID3 那样，哪怕每一次小 I/O 操作也要涉及全组，只需涉及组中两块硬盘（一块数据盘，一块校验盘）即可，从而提高了小量数据 I/O 速度。

RAID 5

奇偶校验(XOR)，数据以块分段条带化存储。校验信息交叉地存储在所有的数据盘上。

RAID5 把数据和相对应的奇偶校验信息存储到组成 RAID5 的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上，其中任意 N-1 块磁盘上都存储完整的数据，也就是说有相当于一块磁盘容量的空间用于存储奇偶校验信息。因此当 RAID5 的一个磁盘发生损坏后，不会影响数据的完整性，从而保证了数据安全。当损坏的磁盘被替换后，RAID 还会自动利用剩下奇偶校验信息去重建此磁盘上的数据，来保持 RAID5 的高可靠性。

RAID 5 可以理解为是 RAID 0 和 RAID 1 的折衷方案。RAID 5 可以为系统提供数据安全保障，但保障程度要比镜像低而磁盘空间利用率要比镜像高。RAID 5 具有和 RAID 0 相近似的数据读取速度，只是因为多了一个奇偶校验信息，写入数据的速度相对单独写入一块硬盘的速度略慢。

RAID 6

类似 RAID5,但是增加了第二个独立的奇偶校验信息块，两个独立的奇偶系统使用不同的算法，数据的可靠性非常高，即使两块磁盘同时失效也不会影响数据的使用。但 RAID 6 需要分配给奇偶校验信息更大的磁盘空间，相对于 RAID 5 有更大的“写损失”，因此“写性能”非常差。

由图所知，每个硬盘上除了都有同级数据 XOR 校验区外，还有一个针对每个数据块的 XOR 校验区。当然，当前盘数据块的校验数据不可能存在当前盘而是交错存储的。从数学角度来说，RAID 5 使用一个方程式解出一个未知变量，而 RAID 6 则能通过两个独立的线性方程构成方程组，从而恢复两个未知数据。

伴随着硬盘容量的增长,RAID6 已经变得越来越重要。TB 级别的硬盘上更容易造成数据丢失，数据重建过程(比如 RAID5，只允许一块硬盘损坏)也越来越长，甚至到数周，这是完全不可接受的。而 RAID6 允许两块硬盘同时发生故障，所以渐渐受到人们的青睐。

伴随 CD，DVD 和蓝光光盘的问世，存储介质出现了擦除码技术，即使媒介表面出现划痕，仍然可以播放，大多数常见的擦除码算法已经演变为上世纪 60 年代麻省理工学院林肯实验室开发的 Reed-Solomon 码。实际情况中，多数 RAID6 实现都采用了标准的 RAID5 教校验比特和Reed-Solomon码。而纯擦除码算法的使用使得 RAID 6 阵列可以失效两块以上的硬盘,保护力度更强,有些实现方法提供了多种级别的保护，甚至允许用户(或存储管理员)指定保护级别。

混合 RAID

RAID 01

顾名思义，是 RAID0 和 RAID1 的结合。先做条带(0),再做镜像(1)。

RAID 10

同上，但是先做镜像(1)，再做条带(0)

RAID01 和 RAID10 非常相似，二者在读写性能上没有什么差别。但是在安全性上 RAID10 要好于 RAID01。如图中所示，假设 DISK0 损坏，在 RAID10 中，在剩下的 3 块盘中，只有当 DISK1 故障，整个 RAID 才会失效。但在 RAID01 中，DISK0 损坏后，左边的条带将无法读取，在剩下的 3 快盘中,只要 DISK2 或 DISK3 两个盘中任何一个损坏,都会导致 RAID 失效。

RAID10 和 RAID5 也是经常用来比较的两种方案，二者都在生产实践中得到了广泛的应用。 RAID10 安全性更高，但是空间利用率低。至于读写性能，与 cache 有很大关联，最好根据实际情况测试比较选择。

非标准 RAID

DRFS

DRFS,即DistributedRaidFileSystem,是一种尝试将 RAID 与 Hadoop 的 DFS 结合起来的技术。通常的 HDFS 在实践中需要将replication factor设为 3 以保证数据完整性，而如果利用 RAID 的stripe和partity(奇偶校验)技术,将数据分为多个块，并且存储各个块的校验信息(XOR 或擦除码)。有了这些措施，块的副本数就可以降低并且保证同样的数据可靠性，就能节省相当一部分的存储空间。

DRFS 包含以下几个组件：

DRFS client : 提供应用程序访问 DRFS 的接口，在发现读取到的文件有损坏时修复,整个操作对应用程序透明
RaidNode : 创建，维护检验文件的daemon
BlockFixer : 周期性地检查文件,重新计算校验和,修复文件.
RaidShell : 类似于hadoop shell.
ErasureCode : 即 DRFS 所使用的生成校验码的算法，可为 XOR 或者 Reed-Solomon算法。 XOR 仅能创建一个校验字节，而Reed-Solomon则可以创建无数位(位数越多，能恢复的数据也越多),如果使用Reed-Solomon,replication甚至可以降为 1，缺点是降低了数据读写的并行程度(只能从单机读写)。

实现

软件实现

现在很都操作系统都提供了 RAID 的软件实现,主要由以下几个方面:

由软件在多个设备上创建 RAID，比如 linux 上的mdadm工具.具体使用方法可查看参考链接中的例子。
LVM或者 Veritas,虚拟卷管理工具.
文件系统实现 : btrfs,ZFS,GPFS.这些文件都可以直接管理多个设备上的数据，实现了类似各级 RAID 的功能。
在已有文件系统之上提供数据校验功能的 RAID 系统(RAID-F)

固件/驱动实现

软件实现并总是与系统的启动进程兼容，硬件实现(RAID 控制器)总是太贵并且都是厂商专有的技术，所以有了一中混合的实现:系统启动时，由固件(firmware)来实现 RAID，系统启动的差不多了，由驱动来管理 RAID。当然，这需要操作系统对这种驱动提供支持。

参考链接

bash 各配置文件浅析

hang.yan@hotmail.com (涯余) — Fri, 23 Jan 2015 21:37:39 +0800

与 bash 相关的配置文件非常之多,用户目录下的.bashrc,.profile,.bash_profile，系统级的/etc/profile等。我们也经常会发现，在某个文件里设置好了环境变量之后，并不能总是能在使用 bash 时正确加载。下面将对这个问题进行深入剖析，以解除疑惑。

首先要明晰的两个概念便是login shell与non-login shell :

login shell

login shell是指直接以bash命令登入系统，比如远程 ssh 或者在文本终端登入系统。一般来说服务器都是这种方式，但是桌面系统不是，因为桌面系统启动时最开始的命令都不是 bash。但桌面系统的 tty1-tty6等的登入是login shell.
non-login shell

non-login shell是指在登入系统之后打开的 shell,比如在桌面系统启动后打开的 terminal,或者是在 bash 内部再次输入 bash 打开的 shell.

其实二者有一个很简单的判定方法，在命令提示符下输入 ps -f 查看结果，示例 :

 UID PID PPID C STIME TTY TIME CMD
root 37993 37901 0 21:11 pts/7 00:00:00 -bash
root 38109 37993 0 21:28 pts/7 00:00:00 ps -f

如果显示的为-bash则是login shell,否则便是 non-login shell，比如在这个终端下再次输入 bash之后查看 :

 UID PID PPID C STIME TTY TIME CMD
root 37993 37901 0 21:11 pts/7 00:00:00 -bash
root 38111 37993 0 21:31 pts/7 00:00:00 bash
root 38119 38111 0 21:31 pts/7 00:00:00 ps -f

新的 bash 的 CMD 只是 bash,为 non-login shell。

配置文件加载

各文件加载顺序为 :

如果 /etc/profile 存在，加载.

此文件的内容各个发行版均不相同，且均会加载不同的其他文件。
~/.bash_profile
~/.bashr_login
~/.profile

2，3，4 按顺序寻找，找到第一个存在并且可读的加载。在ubuntu上，一般默认只有 .profile存在，并且里面加载了.bashrc;在slackware上，三个都不存在;在 coreos上，只有.bash_profile

在退出时,如果存在 ~/.bash_logout,执行其中命令后退出

如果 /etc/bash.bashrc 和 ~/.bashrc 存在，加载。

总结

为了统一配置文件的加载，方便用户，很多发行版都会在这些配置文件中互相调用其他的文件，以便用户的设置在两种 shell 中都能得到执行。比如ubuntu,在 login shell的设置中将 non-login shell的设置都加载了。但最好还是能够清楚地区分其中的区别。

CoreOS 安装及配置

hang.yan@hotmail.com (涯余) — Thu, 22 Jan 2015 21:37:39 +0800

本文所遵照的步骤是官网的 Installing to disk 方法,即刻录 ISO 镜像 -> 启动 Coreos Live CD -> 安装到硬盘的步骤，与一般的桌面 Linux 安装非常类似。但 coreos 安装时也有一些需要注意的地方:

cloud-config.yml

这是 coreos 用来统一配置系统的地方，系统在每次启动时都会加载这个文件的配置，比如系统服务、网络设定、文件修改、用户设定等。这样做的好处是在部署集群的时候可以方便地使用相同的配置。在安装 coreos 时，需要指定好这个配置文件。实际操作时，可以提前将这个文件写好放在别的机器上，然后用 scp / wget (利用下面的 web server) 下载到 coreos 的 Live CD 即可，或者直接存在 Live CD 里更方便。
GFW

coreos 安装时需要从官网下载镜像，但网站被墙，所以实际安装的时候可能需要用代理来解决，缺点是速度慢。更方便的方法是提前下载好需要的文件并放在局域网内并搭建一个 web server，然后修改安装脚本的 server 即可。具体方法在后面详述。

刻录 ISO 镜像

下载 ISO : Go to Download Page
刻录 : U 盘的话在 linux 上直接用 dd 命令即可。

安装

网络配置

因为安装过程中需要联网，所以需要配置 Live CD 内部的 coreos 系统的网络。coreos 使用 systemd 来管理系统服务，所以写一个 unit file 并启动即可。

在 /etc/systemd/network 目录下创建 static.network文件,示例内容如下:

[Match]
Name=eno1
[Network]
DNS=114.114.114.114
Address=192.168.200.12/24
Gateway=192.168.200.11

Name为网卡名，Address为静态 IP 地址,依自己情况设置即可。

执行如下命令生效:

sudo systemctl restart systemd-networkd

cloud-config

一个基本的 cloud-config.yml 示例文件如下：

#cloud-config
hostname: coreos-12
manage_etc_hosts: localhost
coreos:
etcd:
discovery: https://discovery.etcd.io/<your-own-uuid>
addr: 192.168.200.12:4001
peer-addr: 192.168.200.12:7001
units:
- name: etcd.service
command: start
- name: fleet.service
command: start
- name: 00-eno1.network
runtime: true
content: |
[Match]
Name=eno1
[Network]
DNS=114.114.114.114
Address=192.168.200.12/24
Gateway=192.168.200.11
users:
- name: core
ssh-authorized-keys:
- ssh-rsa ...
- groups:
- sudo
- docker

配置文件的语法很简单，很多部分都可以见名知意，具体文件格式定义请参见:Using Cloud-Config 如果配置中有错误，如果不影响启动，会在启动完成后显示错误信息。官方文档中提示 coreos-cloudinit -validate 命令可以用来检查此配置文件中是否有语法错误，但是在实际安装的时候发现并没有这个参数(V0.10.9),还好官网提供一个在线的检测页面可供检查 : Cloud-Config Validator

此文件中有几个点应注意 :

#cloud-config 为必备部分
如果没有添加 manage_etc_hosts选项,在 /etc/hosts 文件中将不会有 localhost的记录
如果只是部署单机环境, etcd 中的 discovery 字段可以先省略，此字段是用来做服务发现的(供多个 etcd 通信).具体请参见CoreOS Cluster Discovery
units 部分的设置会转换为相应的 systemd unit. etcd,fleet 等都是已定义好的，配置为开机启动即可。fleet为systemd提供了在集群内部调度systemd unit的能力。
users 部分的ssh-authorized-keys是用来设置需要登入这台 coreos 的 key 的,可为多个。因为 Coreos 安装默认是core和root两个用户，都没有密码,只能通过远程ssh 登陆来操作。选择好以后将用来登陆 coreos 的机器之后，将其 ssh key 粘贴到这即可，可添加多台机器的 key.如果需要，也可以生成为 core 用户生成密码，但没多大必要，具体可参见相关文档。
安装完成之后, cloud-config.yml的内容会保存在 /var/lib/coreos-install/user_data文件中，后续机器重启均会加载此文件。后续的更改也应该在这里进行。

内网环境

之前提过因为墙的原因很难下到安装时所需的镜像。下面介绍内网部署的方法:

下载安装脚本 : https://raw.githubusercontent.com/coreos/init/master/bin/coreos-install, 添加可执行权限。
查看 BASE_URL 变量所指向的地址,如下所示 :
```
 BASE_URL="http://${CHANNEL_ID}.release.core-os.net/amd64-usr/${VERSION_ID}"
```
其中CHANNEL_ID是在下载 ISO 的时候就选择好的，一般都是stable,VERSION_ID为 LIVE CD 的版本号,在 /etc/os-release中。
在上面的地址中下载如下文件 :
1. coreos_production_image.bin.bz2
2. coreos_production_image.bin.bz2.DIGESTS
3. coreos_production_image.bin.bz2.DIGESTS.asc
4. coreos_production_image.bin.bz2.DIGESTS.sig
5. coreos_production_image.bin.bz2.sig
这个看自己能力了。如果实在下不下来，可以到百度网盘里搜一下,应该已经有人在里面存有。
在另外一台机器上部署web server,不嫌麻烦的可以用 apache,更简单的方法如下 : 在文件所在的目录下执行 :
```
 python -m SimpleHTTPSever
```
默认监听端口为 8000.
修改 coreos-install 文件中的 BASE_URL 变量,改为自己的目录位置即可。

最终安装

安装命令就一个 :

coreos-install -d /dev/sda -C stable -c ~/cloud-config.yaml

注意点 :

/dev/sda 为所要安装到的硬盘。安装有可能会出现 “Device Or Resource Busy “之类的问题，一般重启下机器即可。
安装之后如果发现有问题并且进不去系统,比如网络故障，可以用 Live CD 来修复,将有问题的系统挂在到 Live CD 上修改user_data即可。命令如下 :
```
 mount -o subvol=root /dev/sda9 /mnt/
```

关于

hang.yan@hotmail.com (涯余) — Mon, 01 Jan 0001 00:00:00 +0000

技术博客，主要记录 Kubernetes、容器、数据库和网络相关的笔记。

GitHub: hangyan
Email: hang.yan@hotmail.com
RSS 订阅: index.xml

涯余的博客

TC 的一些有趣功能

clsact

ingress 与 egress 的不同

multiple qdisc

direct-action mode

EDT Solution

tcng

TC Flower

Links

Cilium 的 Host Firewall 功能

一些基本概念

Host Firewall 是什么

Golang 相关代码

policyAdd

reactToRuleUpdates

EndpointRegenerationEvent.Handle

相关 BPF 代码

from-netdev

handle_netdev

do_netdev

tail_handle_ipv4

handle_ipv4

Links

eBPF Loop

Bounded Loop

MAP Iterator

bpf_loop

eBPF Timeline

5.2

5.8

5.13

eBPF, iptables, nftables

iptables

ipset

ipvs

kube-proxy

eBPF

Links

CNI Notes: IPAM

CNI实现

Calico

Host-local IPAM

Cilium

Antrea

总结

Links

Rebuild Kernel 生成 BTF 文件

如何生成 vmlinux.h

环境说明

安装 vmlinux

安装 bpftool

生成 vmlinux.h

Links

卸载UOS

《老友记》的人物塑造

Kubernetes 的 Server-Side Apply

kubectl apply

何为 Service-Side Apply

managedFields 详解

Controller 的使用

现状

Links

LB系列1 - Bandaid

Queue设计

User Space的 Read Queue

权重以及 Route划分

算法笔记(1): 链表及其应用

约瑟夫问题

LRU算法

Links

io_uring 介绍

总览

SQ/CQ

系统调用

io_uring_setup

io_uring_enter

Polled Mode

SPDK相关

其他高级功能