Month: March 2021

自己动手生成一个僵尸进程

创建一个 python 程序

#!/usr/bin/env python3
import subprocess
import time
import os
print(os.getpid())
p = subprocess.Popen(['/bin/sleep', '1'])
time.sleep(1000000)

在这个程序中，主进程会启动一个 sleep 子进程，这个 sleep 在1秒之后就执行结束了，此时，它会进入等待被回收的状态

但是主进程此时进入了 sleep（1000000），在阻塞过程中并没有对子进程进行回收，所以并没有对 子进程 进行回收

6701 主进程，6702 子进程变成了僵尸

也就是说只要满足两个条件就可以轻松的获得一个僵尸进程

1. 父进程阻塞（sleep）
2. 子进程结束执行，等待回收

根据以上两种条件，我们尝试一下docker的情况

1. 我们先创建一个 sleep 的 ubuntu 容器，这个容器的 1号进程是一个 阻塞进程，也就是说它不会回收任何子进程
2. 我们使用 bash创建了几个 bash 进程

接下来，让我们 kill 27号进程，这样30号进程的父进程就会变成 1号进程（也就是sleep进程）

此时，30号进程的父进程就变成了对它不管不顾的 sleep 进程

因为 27号进程已经被 24号进程回收了，所以宿主机中没有 僵尸进程

我们kill掉 没人管的 30号进程

这样我们就成功的创建了一个僵尸进程

容器内 PID 30，宿主机上 PID 7132

把容器停掉的话，僵尸进程会被宿主机回收

综上所述，当

1. Docker容器的主进程因为某种原因处于阻塞状态
2. 主进程创建了一些子进程
3. 这些 子进程 的 父进程一旦变为 阻塞中的容器主进程 ，它们在运行结束后，将成为无法被回收的 僵尸进程

1.11 之前的情况

Docker的1.11版本是一个大改变，

首先是从单一模块拆分成了4个独立模块，engine、containerd、runc、containerd-shim

containerd-shim代替了原来的1号进程，用来回收孤儿进程

containerd 用来管理容器的生命周期，

runc 用来运行容器

这种改变在2017年的时候使其更贴合容器标准化

为了安装1.11之前的版本，我尝试了几乎4个小时才成功

主要是apt的安装包几乎都已经离线了

想尝试的同学可以按照以下步骤

下载deb离线包，然后使用 ubuntu16来安装，18和20不能兼容

http://archive.ubuntu.com/ubuntu/pool/universe/d/docker.io/docker.io_1.10.3-0ubuntu6_amd64.deb

启动一个ubuntu镜像，让它的1号进程阻塞，参考 自己动手生成一个僵尸进程

杀死 42号进程，这样45号进程的父进程会变成容器的1号进程

接着杀死 45号进程，此时容器的1号进程应该无法回收它

然后我们就得到了一个无法被回收的僵尸进程

僵尸进程的由来

要想了解如何避免僵尸进程，首先我们需要知道这个问题从何而来

Linux 系统 进程号的最大值是 32768

当PID总数达到这个值之后，系统将无法创建新的进程，这是一个很严重的问题

我曾经遇到一个系统bug就是由于调用外部系统的时候，外部系统没有返回，进程不会被释放而一直等待，最终导致了 PID 耗尽的bug

关于Linux进程树等问题这里不想再多重复，

正常情况下，进程退出时 PID 将会被 父进程 回收，具体做法是

1. 子进程结束时，系统向其父进程发送SIGCHILD信号
2. 父进程调用wait函数后阻塞
3. 父进程被SIGCHILD信号唤醒然后去回收僵尸子进程

这里存在一个特殊情况是，父进程 早于 子进程结束的情况，例如父进程被 kill

这种情况 子进程的 父进程 会被指向到 init （也就是1号进程），这样1号进程会负责回收

早期的 Linux系统中的init进程非常轻量，叫做 sysinit

但是，在现代的Linux环境中，这个init进程一般会是systemd或者upstartd等重量级的进程，它们会做很多额外的工作。

（实际上这个问题带来了很多争论，部分开发人员认为，使用更重的 init 进程弊大于利）

通过不断的调用 bash，可以得到一个标准的进程树

我们可以看到 3099号进程的 父进程是 3093，它的子进程包括 3105、3111、3117、3123

这里如果 kill 掉 3099号进程，会发现它的直接子进程 3105的父进程确实变成了

/lib/systemd/systemd –user （PID 1634）

虽然确实是 systemd 但是说好的 1号 进程呢？

1号进程是 /sbin/init auto noprompt

想知道为什么？在 Ubuntu18 之后 （我当前是ubuntu20），

/sbin/init 就是 /lib/system/systemd 的一个软链接

在上面这种正常的 Linux 系统上，即使我们 kill 掉了 3105的父进程，它也不会变成僵尸，此时使用 ps -ef | grep defunct 是找不到任何僵尸进程的

来看Docker 的情况

杀死 21号 进程之后， 24号进程会被托管给 docker的1号进程

Docker 的 1号 进程实际上只是一个普通的 bash 进程

僵尸进程

这个话题由来已久，早在2013年就经常被提起，但是每次重提，几乎都会遇到一些新问题

Docker-compose networks

之前我们在 容器互联 那一节里重点说到过 如何通过

共享同一个第三容器的 网络，

来使用localhost访问其他容器的endpoint，其主要原理是 Linux network 的 namespace

然而这个问题到了 docker compose 中又不一样了

通过以下脚本启动两个容器，并且配置它们共享一个名为 unetwork的网络

version: '3'
services:
  utest1:
    image: nginx
    networks:
      - unetwork

  utest2:
    image:  ubuntu
    command: sleep infinity
    networks:
      - unetwork

networks:
  unetwork:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.100.0/24

可以看到

1. 容器无法通过localhost访问，也就是说它们没有共享一个network namespace
2. 检查 /etc/hosts 发现其中也没有像 link 那样把container name 写进 dns
3. curl utest1:80 访问到了 nginx

docker compose 可以使用的网络多种多样

具体请参考

https://docs.docker.com/engine/reference/commandline/network_create/

如果没有特殊指定的话，这里生成的是 bridge 模式

Docker-compose

关于安装

到以下地址查询最新的安装版本

https://github.com/docker/compose/releases

然后可以下面的脚本

sudo curl -L "https://github.com/docker/compose/releases/download/1.28.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
docker-compose --version

Docker 容器共享网络（localhost）

因为不同容器之间的 network namespace 隔离，所以各个容器的 localhost 回环地址也只能指向自己

不过在 k8s 下，同一 pod 内的容器之间，实际上是可以使用 localhost来互相访问的，这是为什么呢？

k8s 的 pod 中会默认运行一个名字叫pause的容器，其他的容器就挂到这个 pause 上面，也就是使用了 docker run –net container

docker run -i -t --name pause busybox sleep infinity
docker run -i -t --name nginx --net container:pause nginx
docker run -i -t --name watcher --net container:pause ubuntu sleep infinity
docker exec -i -t watcher /bin/bash

容器内
apt update
apt install curl
curl localhost:80

Docker –link

Docker link 实际上已经被标注为 过时 了，但是仍然有一些传统应用在使用它

最典型的是链接 web 应用和 数据库

例如要启动一个 WordPress 就可以

docker run --name wp_mysql -p 3306:3306 -v /data/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123 -d mysql:5.7

docker run --name wp_web --link wp_mysql:mysql -v /data/wordpress:/var/www/html -p 80:80 -p 443:443 -d wordpress:5.6.0

使用了 –link 的 WordPress docker 部署，是不需要再配置 mysql 数据库连接就可以直接连上 数据库 的。

这里主要想讨论， link 到底 link 了什么

首先，这里需要明确两个概念，上面的 mysql 是 源容器，是被连接容器，WordPress 是目标容器，是接收容器

为了进行下面的测试，我们启动两个 busybox 容器，把它们连接在一起

docker run -i -t --name source -p 3001:3001 -p 3002:3002 -e source_env_1=123 -e source_env_2=456 busybox sleep infinity
docker run -i -t --name target -p 3003:3003 -p 3004:3004 -e target_env_1=123 -e target_env_2=456 --link source:mysource busybox sleep infinity

1. 别名

–link wp_mysql:mysql

对于 WordPress 容器而言，wp_mysql 和 mysql 是一个容器，有着同样的 containerid

–link source:mysource

对于 target 容器而言，source 和 mysource 是一个容器

2. DNS

3. 环境变量

上面WordPress之所以直接可以连接数据库，实际上是使用了环境变量

WordPress的镜像默认会从 mysql 这个别名来读取 数据库 配置，所以这里如果写成 –link wp_mysql:test_mysql ，WordPress是无法识别到数据库的，可以理解成这是一个约定

Target 容器会得到 如下环境变量

4. 如果 source 容器的 ip 发生变化 的情况

删除source容器之后，我创建一个 Nginx容器，占用原来source容器的

172.17.0.2 ip 可以看到 新的ip 是 172.17.0.4

此时，在target容器中，没有任何信息被更新

启动一个target2 容器，就可以看到 dns 和 env 都换成新的了

容器互联

Volume的使用

对于需要在容器外持久化的数据，需要使用 mount

早期的docker只能挂载本地磁盘路径，也就是下面的第一种方式

第一种方式 直接挂载本地路径

docker run -d -it --name=nginx1 -p 8001:80 -v ~/tmp:/usr/share/nginx/html nginx

这种方式下，docker不会覆盖本地路径下的任何文件内容

也就是说，如果本地路径 tmp 中没有文件，那么挂载之后，容器在挂载的路径下，也会 没有任何文件

这是一种， 使用本地内容 覆盖 容器对应路径内容 的方式

第二种方式 创建由docker管理的volume

docker volume create tmpvol
docker run -d -it --name=nginx2 -p 8002:80 -v tmpvol:/usr/share/nginx/html nginx

这种方式的方便之处在于，它在持久化数据的同时，还可以继续使用容器内自带的内容

这是一种，仍然使用容器内容 存储到 指定的 volume 的方式

在Linux上，想要直接从宿主机访问这个路径非常容易

路径如下

在MacOS上就相对复杂一些，因为MacOS的 docker desktop 也是基于虚拟机实现的

旧版本的docker desktop 使用下面的命令附着到 tty之后，可以访问上面和 linux类似的路径

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty

然而在 3.1.0 的版本中，我没有找到这个tty文件

实际上是，这个操作反而变得比以前简单了

注意到右上角的 CLI 图标了么？

只不过这种方式不是在宿主机上，而是 docker exec 提供的 sh