graymon jschwinger233

.

发现 docker cp 的实现跟屎一样.

一开始发现的问题是 docker-ce/components/client 里的 CopyToContainer 这个 interface, 签名是这样的:

CopyToContainer(ctx context.Context, container, path string, content io.Reader, options types.CopyToContainerOptions) error

我注意到的问题是里面 path 必须是 dirname, 比如说你想 docker cp ./a.txt $CONTAINER_ID:/etc/b.txt, 那么 path 必须是 /etc, 否则直接报错.

工程上的问题就是复杂多变, 今天我死活都运行不了 calicoctl, 硬着头皮还是找到了问题, 重新总结 calico sdn 的思路.

症状: host1 不能 ping host2 上的容器 c1

直接检查 host1 的 ip r
1. 有通往 c1 的路由说明 felix + bgp 都正常;
2. 如果宿主机的网络配置复杂难以肉眼判断, 那么可以通过 birdcl show route for [c1 ip] 看结果;
3. 留意 host1 和 host2 之间的网络环境, 如果宿主鸡 L2 不可达那么(在无 switch 支持的情况下) route 应该是要通过 ipip 隧道的;
4. 如果没有路由, 那么是 bgp / felix / wep 的锅.
如果有路由, 直接怀疑 iptables, 直接在 host1 / host2 / c1 namespace 三处同时抓包, 最明显的临床症状是 host1 + host2 能抓包但是 c1 network namespace 里抓不到, 那就实锤.

Q1: 多次处理 stdout

比如我要先判断 stdout 里是否匹配某模式, 匹配则对 stdout 做进一步处理.

无脑一点, 我们可以把 stdout 写到临时文件里:

tmpfile=$(mktemp)
cmd | tee $tmpfile | inspect $pattern && process $tmpfile
rm -f $tmpfile

协助排查了一次容器内进程的性能问题

症状: 平台上容器内的 redis cluster 进程用 redis-benchmark 测试能稳定复现 spike, 但是同宿主机上的 redis 没有问题

首先怀疑 SDN, 因为没问题的 redis 是 host 网络. 理论上这很难查, 但是在部署了一个 SDN 网络的 redis 后发现依然没有问题, 我比较有把握不是网络问题, 不过也不是特别确定, 因为 redis cluster 的节点跨主机, 说不清楚会发生什么.
建立最小可复现问题的现场. 我们应该从几乎一模一样的环境(相同的容器里)重建一个拥有相同节点, 相同配置, 相同数据, 只是监听不同端口的集群, 理论上这个集群应该是能复现问题的.
然后一点点缩小问题的范围, 看到那一步就突然不能复现
1. 摘掉所有的 slave nodes
2. 把进程放到宿主机裸跑
把集群放到同一个宿主机

比放说我想确认一个进程是否连接了 unix:///var/run/docker.sock, 对于 TCP 来说 lsof -p$PID | grep $PORT 立刻就能查到, 对于 Unix Socket 来说就不行了.

做法应该是这样的:

	# init

	systemctl stop iptables
	apt update -y

	# etcd

	curl -OL https://github.com/etcd-io/etcd/releases/download/v3.3.10/etcd-v3.3.10-linux-amd64.tar.gz
	tar xf etcd-v3.3.10-linux-amd64.tar.gz
	cp -f /root/etcd-v3.3.10-linux-amd64/{etcd,etcdctl} /usr/bin/