导出 docker container 运行时快照并从快照运行

之前讲 docker container 生命周期的时候, 看到 pause container 命令, 突然想到是否能够对一个正在运行的container 做个快照, 把全部文件和内存运行数据都dump出来, 之后根据快照随时继续运行呢?

于是 Google 了一把, 发现也有不少人有同样的疑问, 很多人的回答都提到了 docker commit, 不过这不是我想要的. docker commit 只是把改动的文件内容覆盖到原来的 image, 重新做了一个 image, 然而丢失了正在运行的进程的全部数据, 比如内存和寄存器里面的数据. 而我期望的是能保存这些进程的运行时信息, 等继续运行的时候, 能在进程应该继续执行的下一个指令的地方继续运行.

那么到底有没有神奇的方法, 能做到期望的行为呢? 其实 Docker 已经考虑了这个需求, 做为实验命令, 只是还没有正式发布, 那就是通过docker checkpoint 子命令. 官方链接.

它的主要过程就是: 当一个container 正在运行时, 通过 docker checkpoint create dump一个包含container文件系统和运行时内存数据的快照, 并把它保存到磁盘. 之后通过docker start --checkpoint checkpoint_id container_name 来继续运行. 由于我们保存快照到文件系统, 所以可以复制很多份, 之后可以随时启动它, 随时查看当时的状态.

下面是官方的一个例子:

  1. 安装 CRIU 依赖, Docker 其实是依赖这个包才能完成container冻结和恢复的.

    supra@suprabox:~$ sudo apt install criu -y
  2. 首先启动这个每隔一秒钟打印一个数字的container, 名字是cr

    supra@suprabox:~$ docker run --security-opt=seccomp:unconfined --name cr -d busybox /bin/sh -c 'i=0; while true; do echo $i; i=$(expr $i + 1); sleep 1; done'
    0e09ac6f369f965af18e429ec78fcab8875610fdfd69313d6c7ecb0b86e61d7
  3. 查看打印的数据

    supra@suprabox:~$ docker logs -f cr
    0
    1
    2
  4. 生成快照 --leave-running 表示快照生成完继续运行 --checkpoint-dir表示要保存的文件夹

    supra@suprabox:~$ docker checkpoint create cr checkpoint1 --leave-running --checkpoint-dir /tmp/
    checkpoint1
  5. 查看之前的container 还在运行, 查看我们保存快照的文件夹, 发现里面各种以 .img 结尾的文件

    supra@suprabox:~$ docker ps -l
    CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS     NAMES
    ecb0b86e61d7   busybox   "/bin/sh -c 'i=0; wh…"   10 minutes ago   Up 10 minutes             cr
    
    supra@suprabox:~$ sudo ls -alh /tmp/checkpoint1/
    total 224K
    drwx------  2 root root 4.0K Jan 28 18:40 .
    drwxrwxrwt 22 root root  12K Jan 28 18:42 ..
    -rw-r--r--  1 root root  356 Jan 28 18:40 cgroup.img
    -rw-r--r--  1 root root 1.8K Jan 28 18:40 core-1.img
    -rw-r--r--  1 root root 1.8K Jan 28 18:40 core-1034.img
    -rw-------  1 root root   45 Jan 28 18:40 descriptors.json
    -rw-r--r--  1 root root   44 Jan 28 18:40 fdinfo-2.img
    -rw-r--r--  1 root root   44 Jan 28 18:40 fdinfo-3.img
  6. 恢复运行 - 各种失败 - 没有达到预期
    去掉各种参数, 按照官方方法, 在 Ubuntu 22.04 上照样不能成功. 失败

    supra@suprabox:~$ docker start --checkpoint  checkpoint1 cr
    Error response from daemon: OCI runtime restore failed: criu failed: type NOTIFY errno 0
    log file: 
     
     /run/containerd/io.containerd.runtime.v2.task/moby/63263d8b31317dbe1f6cf19eac2198f3e078a12f9d872e4e134eae1a4f465d49/work/restore.log: unknown
    
    supra@suprabox:~$ sudo tail -f 
     
     /run/containerd/io.containerd.runtime.v2.task/moby/63263d8b31317dbe1f6cf19eac2198f3e078a12f9d872e4e134eae1a4f465d49/work/restore.log
    (00.274155) pie: 52:     mmap(0x7fffb69f7000 -> 0x7fffb69fb000, 0x3 0x32 -1)
    (00.274162) pie: 52:     mmap(0x7fffb69fb000 -> 0x7fffb69fd000, 0x7 0x32 -1)
    (00.274170) pie: 52: Preadv 0x1612000:8192... (3 iovs)
    (00.274193) pie: 52: `- returned 20480
    (00.274198) pie: 52:    `- skip pagemap
    (00.274203) pie: 52:    `- skip pagemap
    (00.274208) pie: 52:    `- skip pagemap
    (00.488504)      1: Error (criu/cr-restore.c:1480): 52 killed by signal 11: Segmentation fault
    (00.488867) mnt: Switching to new ns to clean ghosts
    (00.489104) Error (criu/cr-restore.c:2447): Restoring FAILED.

官方 CRIU 最新版本是 3.17.1, 我本地版本是 3.16.1-2 不知道是不是有问题.

upra@suprabox:~$ apt show criu
Package: criu
Version: 3.16.1-2

但是这篇 blog 在2015年当时已经成功了: https://kubernetes.io/blog/2015/07/how-did-quake-demo-from-dockercon-work/

不论如何, 想要做快照, 并且从快照恢复一个进程, 已经有很多研究了, 更多看这里: https://criu.org/

http 客户端常见的三种 timeout

微服务的开发部署方式已经在业界广泛被采用, 许多微小的服务共同组成一个完整的软件系统, 对外提供有价值的商业服务. 一个完整的系统组合起来, 离不开内部各个微服务之间的依赖调用, 于是微服务之间形成了一个密集的调用网. 因此我们在微服务的代码中看到许多的 http 客户端到服务端的调用, 而且当应用出问题时候, 我们经常看到各种 http client 相关的各种问题. 这些问题当中, 尤其与 timeout 相关的问题特别多, 本系列的几篇文章将以典型的 Liunx 上 Java 的 http client 为例, 来详细讨论常见的 http 客户端的3种timeout 问题.

connect timeout 和 read timeout

首先, 我们看一个最简单的服务间的调用过程:

  1. 客户端发起 tcp 连接, 服务端应答, tcp 连接建立;
  2. 客户端发出 http request;
  3. 服务端收到请求, 处理请求, 发回 http response;
  4. 客户端收到应答, 关闭 tcp 连接(open issue)

在上面的过程中, 客户端可能会面临2种timeout.

  1. 在上面的第(1)步建立 tcp 连接的过程中, 如果客户端发出 syn, 迟迟收不到服务端的应答, 会产生 connect timeout;
  2. 在上面的过程中, 如果客户端发出了请求, 迟迟收不到 http response, 或收不到完整的response, 则可能产生 read timeout;

从连接池租借连接 timeout

如果某个服务调用的频率非常高, 那么按照上面的流程, 每次都新建一个 tcp 连接就显得非常消耗系统资源和时间. 于是一个可以优化的选项就是在客户端建立连接池, 每次需要发送请求的时候, 从连接池租借出一个连接. 若连接池有现成的连接, 则可以立即借来用. 若没有, 才去新建. 当连接用完之后, 不是关闭连接, 而是返还给连接池以备下次使用. 一般情况下, 连接池不可能有无限的连接, 通常设置一个最大值, 当被借出的连接达到最大值之后, 后续的请求通常要等待空闲的连接可用 (这里介绍的连接池是一个比较简单的模型, 查看专门的书籍去查看更多关于连接的模型和策略).
所以, 从连接池去租借一个可用的连接, 并不一定每次都能立即拿到, 所以有可能迟迟拿不到连接, 所以这里会出现从连接池租借连接的等待 timeout.

所以, 一个客户端的请求会出现3种可能的timeout. 如下图:
timeouts.png

针对上面的3种timeout, 在我们常见的代码中, 它们的默认值是什么呢? 我们应该如何设置这些值呢? 如果设置不合理, 又可能出现那些问题呢?

docker container 的生命周期

当我们创建一个 container 的时候, 它的生命过程中都会经历哪几个阶段呢? 有时候明明一个 container 已经死了, 我们去创建一个同名 container 的时候, 它竟然说有一个同名的 container 存在? 明白了 container 的生命周期, 就能理解了.

container 的生命阶段

一个 docker container 从创建到彻底消亡, 可能会经过的阶段:
docker_container_lifecycle.png

  1. created: container 被创建, 但是没有被启动
  2. running: container 被启动, 里面的进程在运行
  3. paused: container 里的所有进程被挂起, 暂停运行
  4. stopped: container 里面的进程被杀死, container 还存在
  5. deleted: container 被彻底删除

下面我们就以 nginx 做container 为例来说明这个过程.

create 创建 container

下面创建一个 nginx container, 并使用 ps -l (--latest) 来查看, 状态是 Created.

supra@suprabox:~$ docker create --name nginxServer nginx
ac301e1f4f3f3ba5631ff5d7f3276d1544610229a9e3727dac6d5f66181bfe05

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS    PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   1 minutes ago   Created             nginxServer

start 启动 container

通过start子命令启动 container, 然后通过ps子命令查看状态. 通过exec子命令写一句话到/text.txt文件, 并且查看写入内容.

supra@suprabox:~$ docker start nginxServer
nginxServer

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS         PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   25 minutes ago   Up 5 seconds   80/tcp    nginxServer

supra@suprabox:~$ docker exec nginxServer bash -c 'echo "this is a test" > /test.txt'
supra@suprabox:~$ docker exec nginxServer cat  /test.txt
this is a test

pause 暂停 container

可以看到经过 pause 之后, 状态变为 Paused. 如果尝试进入这个 container exec, 这个时候会报错.

supra@suprabox:~$ docker pause nginxServer
nginxServer

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS                  PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   29 minutes ago   Up 4 minutes (Paused)   80/tcp    nginxServer

supra@suprabox:~$ docker exec -it nginxServer bash
Error response from daemon: Container nginxServer is paused, unpause the container before exec

unpause 继续 container

supra@suprabox:~$ docker unpause nginxServer
nginxServer

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED             STATUS          PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   About an hour ago   Up 44 minutes   80/tcp    nginxServer

stop 停止 container

stop 之后, 通过docker ps -l 可以看到状态变为 Exited, 这个时候通过docker logs 仍旧能看到之前的log, 并且可以看到主进程被杀死的日志. 但是通过docker exec 已经无法进入 container.

supra@suprabox:~$ docker stop nginxServer
nginxServer

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED             STATUS                     PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   About an hour ago   Exited (0) 8 seconds ago             nginxServer

supra@suprabox:~$ docker logs -f nginxServer
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
...
2023/01/27 13:35:52 [notice] 1#1: signal 17 (SIGCHLD) received from 32
2023/01/27 13:35:52 [notice] 1#1: worker process 32 exited with code 0
2023/01/27 13:35:52 [notice] 1#1: worker process 37 exited with code 0
2023/01/27 13:35:52 [notice] 1#1: exit

supra@suprabox:~$ docker exec -it nginxServer bash
Error response from daemon: Container ac301e1f4f3f3ba5631ff5d7f3276d1544610229a9e3727dac6d5f66181bfe05 is not running

start 重新启动 stop 的 container

通过 start 子命令, 可以重新启动 stop 的container, 通过docker ps -l 可以看到它的状态是刚起来4秒. 这时候去查看之前写入的 /test.txt 文件, 内容还在. 但是这时候里面的进程都是新启动的, 不说 stop 之前的那个(批)进程了.

supra@suprabox:~$ docker start nginxServer
nginxServer

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED             STATUS         PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   About an hour ago   Up 4 seconds   80/tcp    nginxServer

supra@suprabox:~$ docker exec nginxServer cat  /test.txt
this is a test

rm 彻底删除container

可以通过rm子命令删除任何状态的container. 如果一个container 是 stopped 或 created 状态的, 可以直接rm, 否则就必须通过 -f 强制删除.

docker rm nginxServer
docker rm -f nginxServer

run 创建同时启动container

可以通过 run 子命令, 在创建container的同时, 启动container, 相当于同时执行了createstart.

supra@suprabox:~$ docker run --name nginxServer1 --rm  nginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

kill 杀掉一个运行的container

通过kill 杀掉一个运行的container 之后, container 进入 stopped 的状态.

supra@suprabox:~$ docker kill nginxServer
nginxServer

supra@suprabox:~$ docker ps -l
CONTAINER ID   IMAGE     COMMAND                  CREATED       STATUS                        PORTS     NAMES
ac301e1f4f3f   nginx     "/docker-entrypoint.…"   2 hours ago   Exited (137) 18 seconds ago             nginxServer

虚拟以太网卡 veth

这是一块真实的台式机网卡, 左边是一个插网线的接口, 右边是电路板, 电路板上哪些金色的地方就插入主板的接口. 于是外部流量就通过网线, 进入网卡, 然后流入计算机, 计算机内部数据则通过相反的方向流出到外部.
网卡.png

虚拟以太网卡, 就是一个通过软件模拟的网卡设备, 它能模拟网卡的功能把数据传出去, 接收进来的数据, 在操作系统看来, 它就是一块功能完备的网卡. 这个虚拟的网卡一头连着操作系统的kernel, 另外一头呢? 它有没有网线可以插拔, 所以它只能连向另外一个网卡, 所以虚拟出来的网卡都是成对出现的, 它们不能插网线, 所以只能2个网卡之间相互通信, 就好比2个机器之间通过一条直连的网线连在了一起. 就好比下图这样:
vethPair.png

但是这个 veth0 和 veth1 对必然在同一台机器上, 不可能跨域两台机器还能连着. 不过 veth0 和 veth1 可以属于同一台机器上的不同VM, container 或者不同的 netns.

下面演示如何创建虚拟网卡:

# 新建之前查看已有的
$ ip link show

$ sudo ip link add  name veth1 type veth #新建link

$ ip link show # 再次查看
1994: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether fe:99:a3:6e:f7:b0 brd ff:ff:ff:ff:ff:ff
1995: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 56:64:02:ac:de:26 brd ff:ff:ff:ff:ff:ff

可以看到新加出来的 veth0 和 veth1 这对. 我们给的veth 的名字是 veth1, 而系统默认给出了配对的名字是 veth0. 最前面的数字 1994 和 1995 是系统的一个索引值, 称之为 IDX. @后面的名字是成对的另外一边点名字. <> 里面是支持的一些功能, 后边是一些相关参数, 这些参数可以在新建时设置, 也可以使用默认值. 下面一行代表 link 类型: ether(以太网), link 层地址(MAC 地址) 和 广播地址.

当然, 我们可以新建的时候, 直接给出这一对的名字, 比如:

$ sudo ip link add  name veth2 type veth peer name veth3

$ ip link show
1996: veth3@veth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 12:39:5b:12:84:49 brd ff:ff:ff:ff:ff:ff
1997: veth2@veth3: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8a:f0:21:23:20:52 brd ff:ff:ff:ff:ff:ff

因为它们是默认一对出现的, 如果一方下线(down) 则另外一方默认就下线了:

$ sudo ip link set veth3  down

$ ip link
1996: veth3@veth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 12:39:5b:12:84:49 brd ff:ff:ff:ff:ff:ff
1997: veth2@veth3: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8a:f0:21:23:20:52 brd ff:ff:ff:ff:ff:ff

可以看到, 我们这里新建的 veth 都只有link 层地址, 没有 IP 地址, 我们可以给它们赋予IP 地址.

$ ip addr show #设置 IP 地址之前先查看一下

$ sudo ip address add 192.168.88.1/16 dev veth3
$ sudo ip address add 192.168.88.2/16 dev veth2

$ ip addr show #设置完再次查看 
1996: veth3@veth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 12:39:5b:12:84:49 brd ff:ff:ff:ff:ff:ff
    inet 192.168.88.1/16 scope global veth3
       valid_lft forever preferred_lft forever
1997: veth2@veth3: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 8a:f0:21:23:20:52 brd ff:ff:ff:ff:ff:ff
    inet 192.168.88.2/16 scope global veth2
       valid_lft forever preferred_lft forever

$ sudo ip link set veth3 up #up

tcpdump 里面的数据只有特定方向的

最近在诊断一个问题的时候, 当时有件奇怪的事情: 所有的流量都是流向一个IP的, 再也没有其它流量.
为了查出为什么会连接timeout, 于是去抓包, 因为知道连接肯定是443 或 80, 于是使用下面的命令:

$ tcpdump port 80 or port 443 -w /tmp/tcpdump.pcap

可是抓到的结果却全是流向这个IP 的, 并且没有返回traffic:
tcpdump.png

最后发现, 这个机器上有2个接口: tunl0 和 eth0, 抓包时候, tcpdump 默认使用了 tunl0 接口:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.147.64.197/32 scope global tunl0
       valid_lft forever preferred_lft forever
22: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e2:99:0b:96:46:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.147.166.192/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e099:bff:fe96:46a0/64 scope link
       valid_lft forever preferred_lft forever

$ tcpdump port 80 or 443 -w /tmp/tcpdump.pcap
tcpdump: listening on tunl0, link-type RAW (Raw IP), capture size 262144 bytes
^C2 packets captured
16 packets received by filter
0 packets dropped by kernel

从上面ip a 的结果看, 除了 lo 之外, 它存在一个隧道接口和一个eth 端口, 可是使用 tcpdump 时候, 它默认使用了 tunl0 接口.

如果要抓取所有接口的流量, 可以使用

$ tcpdump -i any port 80 or port 443 -w /tmp/tcpdump.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes