为容器选择一个合适的entrypoint

简介

简介
一个容器一个进程？
init 进程
管理孤儿/僵尸（zombie）进程
传递 SIGTERM 信号
进程管理工具的选择
- tini
- 自定义脚本
- runit
- systemd
- supervisor
其它
- Docker-friendliness image
- 和ssh的是是非非

在容器化早期，因为需要ssh访问容器等原因（尽量为开发提供与物理机一致的体验），需要一个容器内运行业务进程与ssh等进程。随着k8s pod 多容器的推进，一个容器内多进程的需求减弱，但业务进程直接作为 entrypoint 仍有很多问题，因此会寻求一些进程管理工具作为pid=1进程。

对于springboot项目，一开始是用java -jar 方式容器中启动，并作为容器的主进程。但在测试环境，经常代码逻辑可能有问题，java启动失败，进而触发k8s健康检查失败，进而不断重启容器。开发一直抱怨看不到“事故现场”。所以针对这种情况，直观的想法是不让java -jar 作为容器的主进程。

一个容器一个进程？

容器中运行多进程，跟 one process per container 的理念相悖，我们就得探寻下来龙去脉了。从业界来说，虽然一个容器一个进程是官方推荐，但好像并不被大厂所遵守，以至于阿里甚至专门搞了一个PouchContainer 出来，美团容器平台架构及容器技术实践

stack exchange Why it is recommended to run only one process in a container? 有一系列回答

Run Multiple Processes in a Container 也提了三个advantages

理由要找的话有很多，比较喜欢一个回答：As in most cases, it’s not all-or-nothing. The guidance of “one process per container” stems from the idea that containers should serve a distinct purpose. For example, a container should not be both a web application and a Redis server.

There are cases where it makes sense to run multiple processes in a single container, as long as both processes support a single, modular function.

从笔者的实践感受来说

除了业务进程，你有没有比较刚的需求运行其他进程？比如ssh 等。笔者在实践中，每个容器内还跑了一个监控进程，用来跟踪容器内的进程数据、以及执行一些异常诊断指令。
entrypoint 启动失败的可能性有多高，entrypoint 挂了会不停地重启，对集群带来的不良影响是否可控？

2020.11.1补充：并非每个容器内部都能包含一个操作系统容器单进程并不是指容器里只能运行”一个”进程而是指容器没有管理多进程的能力。这是因为容器里PID=1的进程就是应用本身，其他的进程都是PID=1进程的子进程。

init 进程

Linux 内核执行文件一般会放在 /boot 目录下，文件名类似 vmlinuz*。在内核完成了操作系统的各种初始化之后，这个程序需要执行的第一个用户态进程就是 init 进程。它直接或者间接创建了 Namespace 中的其他进程。

init/main.c
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
        ret = run_init_process(execute_command);
        if (!ret)
                return 0;
        panic("Requested init %s failed (error %d).",
                execute_command, ret);
}
if (!try_to_run_init_process("/sbin/init") ||
    !try_to_run_init_process("/etc/init") ||
    !try_to_run_init_process("/bin/init") ||
    !try_to_run_init_process("/bin/sh"))
        return 0;
panic("No working init found.  Try passing init= option to kernel. "
        "See Linux Documentation/admin-guide/init.rst for guidance.");

进程号	进程来源	作用
0	Docker daemon 进程	负责容器中进程的管理
1	可以被 Dockerfile 中的 ENTRYPOINT 或 CMD 指令所指明；也可以被 docker run 命令的启动参数所覆盖	负责启动业务进程

以 Docker Container 为例，容器创建后，默认情况下是不会共享宿主机的 PID Namespace，它会自己创建一个 PID Namespace，这个 PID Namespace 的1号/init进程就是我们创建容器时指定的entrypoint。
由于 1 号进程的特殊性，Linux 内核为他做了特殊处理（无法在容器中使用 kill -9 杀死 1 号进程，主机上是可以的）。如果它没有提供某个信号的处理逻辑，那么与其在同一个 PID 名空间下的进程发送给它的该信号都会被屏蔽。这个功能的主要作用是防止 init 进程被误杀。
docker 提供了两个命令 docker stop 和 docker kill 来向容器中的PID1进程发送信号
1. docker stop：docker 会首先向容器的 PID 1 进程发送一个 SIGTERM 信号，用于容器内程序的退出。如果容器在收到 SIGTERM 后没有结束，那么 Docker Daemon 会在等待一段时间（默认是10s）后，再向容器发送 SIGKILL 信号，将容器杀死变为退出状态。也就是说如果我在 1 号进程实现了 SIGTERM(15) 信号处理，就实现了优雅停止。
2. docker kill：可以向容器内 PID 1 进程发送任何信号，缺省是发送 SIGKILL 信号来强制退出应用（这里在宿主机上对 1 号进程下发的 kill）。

管理孤儿/僵尸（zombie）进程

一个正常的进程退出流程是这样的：子进程退出后，给父进程发送一个SIGCHLD的信号，父进程收到这个信号后，会通过wait系统调用来回收子进程。
如果父进程已经结束了，那些依然在运行中的子进程会成为“孤儿（orphaned）”进程。在Linux中Init进程(PID1)作为所有进程的父进程，会维护进程树的状态，一旦有某个子进程成为了“孤儿”进程后，init就会负责接管这个子进程。当一个子进程成为“僵尸”进程之后，如果其父进程已经结束，init会收割这些“僵尸”，释放PID资源。
僵尸进程（内存文件等都已释放，只留了一个stask_struct instance）如果不清理，就会消耗系统中的进程号资源，最坏会导致创建新进程。

如果僵尸进程是在容器内产生的，就更好不处理了。

根据linux进程回收的原理，孤儿进程都会被init进程接管，并由init进程来回收。那在docker容器自己创建出来的 PID Namespace 中，孤儿进程的父进程都会变成 entrypoint 进程。很多entrypoint都不具备主动回收僵尸进程的能力，那一个会产生僵尸进程的容器，里面的僵尸进程就一直得不到回收。
知道了原理，预防方式就比较简单：让具备僵尸进程回收能力的进程充当容器的init进程。

容器产生僵尸进程值得细读，提到containerd-shim 和 pid=0 的关系问题。

传递 SIGTERM 信号

linux 信号机制

进程在收到信号后，可以选择
1. 忽略，对这个信号不做任何处理，但对特权信号 SIGKILL 和 SIGSTOP 例外，不能忽略和捕获（注册signal handler 也会报错），只能采取默认行为——终止。
2. 捕获，用户进程可以注册自己针对这个信号的 handler
3. Default，，Linux 为每个信号都定义了一个默认的行为，包含终止、忽略等，SIGKILL 和 SIGSTOP 的默认行为都是终止。
SIGTERM 是kill 默认发出的 kill pid = kill -SIGTERM pid
init 进程的特殊性，在每个 Namespace 的 init 进程建立的时候，就会打上 SIGNAL_UNKILLABLE 这个标签，1 号进程永远不会响应 SIGKILL 和 SIGSTOP 这两个特权信号。对于其他的信号，如果用户自己注册了 handler，1 号进程可以响应。

理解Docker容器的进程管理docker stop 对PID1进程的要求

支持管理运行过程中可能产生的僵尸/孤儿进程
容器的PID=1进程需要能够正确的处理SIGTERM信号来支持优雅退出，如果容器中包含多个进程，需要PID=1进程能够正确的传播SIGTERM信号来结束所有的子进程之后再退出。

综上，如果一个容器有多个进程，可选的实践方式为：

多个进程关系对等，由一个init 进程管理，比如supervisor、systemd
一个进程（A）作为主进程，拉起另一个进程（B）
- A 先挂，因为容器的生命周期与主进程一致，则进程B 也会被kill 结束
- B 先挂，则要看A 是否具备僵尸进程的处理能力（大部分不具备）。若A 不具备，B 成为僵尸进程，容器存续期间，僵尸进程一致存在。
- A 通常不支持 SIGTERM

所以第二种方案通常不可取，对于第一种方案，则有init 进程的选型问题

	僵尸进程回收	处理SIGTERM信号	alpine 安装大小	专用镜像	备注
sh/bash	支持	不支持	0m		脚本中可以使用exec 顶替掉sh/bash 自身
Supervisor	待确认	支持	79m	要求管理的进程为前台进程，后台进程管不了
runit	待确认	支持	31m	phusion/baseimage-docker	要求管理的进程为前台进程，后台进程管不了
s6			33m
Systemd	支持	支持	alpine没有Systemd		systemd跑不跑前台只是说的systemctl能不能控制，那些不被控制的，关闭过程systemd也会负责回收的对系统特权有要求不会透传环境变量

进程管理工具的选择

tini

bash 是自带僵尸进程回收能力的，但bash 不会将收到的信号传递给它的子进程，它只管自己接收就完事了。
容器的一般使用专用的init 进程（注册并实现非SIGKILL 和 SIGSTOP 信号的处理函数），负责转发信号到所有的子进程，并且回收僵尸进程。 docker原生提供的init进程为tini。使用 Tini 清理 Docker 容器僵死进程

# 启动容器的时候带上个 --init 参数，docker 就会用它自带的 init 进程作为容器的1号进程
docker run -d --init ubuntu:14.04 bash -c "cd /home/ && sleep 100
oot@24cc26039c4d:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 2 14:50 ? 00:00:00 /sbin/docker-init -- bash -c cd /home/ && sleep 100
root 6 1 0 14:50 ? 00:00:00 bash -c cd /home/ && sleep 100
root 7 6 0 14:50 ? 00:00:00 sleep 100

int reap_zombies(const pid_t child_pid, int* const child_exitcode_ptr) {
  pid_t current_pid;
  int current_status;
  while (1) { 
    current_pid = waitpid(-1, &current_status, WNOHANG);
    switch (current_pid) {
      case -1:
        if (errno == ECHILD) {
          PRINT_TRACE("No child to wait");
          break;
        }
…

tini 并不能回收所有的僵尸进程

对于tini ==> entrypoint ==> 进程1 ==> 进程2，当进程1挂掉后，进程2会成为孤儿进程，被 tini 接管并回收
对于tini ==> entrypoint ==> 进程1，如果 entrypoint 产生的子进程变成了僵尸进程，那 tini 是回收不了的。因为要让进程1被 tini 接管，就必须把它的父进程 entrypoint 杀掉，因为僵尸进程能被 tini 回收的前提条件是，僵尸进程的父进程挂掉了。而杀掉 entrypoint 也就意味着容器需要被重启。所以，这种情况下的僵尸进程 tini 是处理不了的，此时只能通过重启容器来清理僵尸进程。

自定义脚本

官方 Run multiple services in a container

runit

Run Multiple Processes in a Container

A fully powered Linux environment typically includes an init process that spawns and supervises other processes, such as system daemons. The command defined in the CMD instruction of the Dockerfile is the only process launched inside the Docker container, so system daemons do not start automatically, even if properly installed.

runit - a UNIX init scheme with service supervision

Dockerfile

FROM phusion/passenger-­ruby22
...
#install custom bootstrap script as runit service
COPY myapp/start.sh /etc/service/myapp/run

#// myapp/start.sh
#!/bin/sh
exec command

在这个Dockerfile 中，CMD 继承自 base image。将myapp/start.sh 拷贝到容器的 /etc/service/myapp/run 文件中即可被runit 管理，runit 会管理 /etc/service/ 下的应用（目录可配置），即 Each service is associated with a service directory

这里要注意：记得通过exec 方式执行 command，这涉及到 shell，exec，source执行脚本的区别

Using runit for maintaining services

runit：进程管理工具runit

	作用	备注
runit-init	runit-init is the first process the kernel starts. If runit-init is started as process no 1, it runs and replaces itself with runit
runsvdir	starts and monitors a collection of runsv processes	当runsvdir检查到`/etc/service`目录下包含一个新的目录时，runsvdir会启动一个runsv进程来执行和监控run脚本。
runsvchdir	change services directory of runsvdir
sv	control and manage services monitored by runsv	`sv status /etc/service/test` `sv stop /etc/service/test` `sv restart /etc/service/test`
runsv	starts and monitors a service and optionally an appendant log service
chpst	runs a program with a changed process state	run脚本默认被root用户执行，通过chpst可以将run配置为普通用户来执行。
utmpset	logout a line from utmp and wtmp file
svlogd	runit’s service logging daemon

runit 工作原理

systemd

CHAPTER 3. USING SYSTEMD WITH CONTAINERS

Running Docker Containers with Systemd

Do you need to execute more than one process per container?

supervisor

官方 Run multiple services in a container

Admatic Tech Blog: Starting Multiple Services inside a Container with Supervisord

使用

supervisord.conf

[supervisord]
nodaemon=true
logfile=/dev/stdout
loglevel=debug
logfile_maxbytes=0

[program:pinggoogle]
command=ping admatic.in
autostart=true
autorestart=true
startsecs=5
stdout_logfile=NONE
stderr_logfile=NONE

Dockerfile

FROM ubuntu
...
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
...
CMD ["/usr/bin/supervisord"]

其它

Docker-friendliness image

与其在init 进程工具的选型上挣扎，是否有更有魄力的工具呢？

docker 原生支持多进程，比如阿里的 pouch
原生支持多进程的镜像

github 有一个 phusion/baseimage-docker 笔者2018.11.7 看到时，有6848个star。该镜像有几个优点：

Modifications for Docker-friendliness.
Administration tools that are especially useful in the context of Docker.
Mechanisms for easily running multiple processes, without violating the Docker philosophy. 具体的说，The Docker developers advocate running a single logical service inside a single container. But we are not disputing that. Baseimage-docker advocates running multiple OS processes inside a single container, and a single logical service can consist of multiple OS processes.

什么叫 ubuntu 对 Docker-friendliness？（待体会）

multi-user
multi-process

和ssh的是是非非

随着web console 工具（底层由kubectl exec支持）不及，ssh 渐渐没有必要了。K8S 故障排错新手段：kubectl debug实战

ssh连接远程主机执行脚本的环境变量问题

背景：

容器启动时会运行sshd，所以可以ssh 到容器
镜像dockerfile中包含ENV PATH=${PATH}:/usr/local/jdk/bin
docker exec -it container bash 可以看到 PATH 环境变量中包含 /usr/local/jdk/bin
ssh root@xxx 到容器内，观察 PATH 环境变量，则不包含 /usr/local/jdk/bin

这个问题涉及到 bash的四种模式

通过ssh登陆到远程主机属于bash 模式的一种：login + interactive
不同的模式，启动shell时会去查找并加载不同而配置文件，比如/etc/bash.bashrc、~/.bashrc 、/etc/profile 等
login + interactive 模式启动shell时会第一加载/etc/profile
/etc/profile 文件内容默认有一句 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

所以 docker exec 可以看到正确的PATH 环境变量值，而ssh 到容器不可以，解决方法之一就是制作镜像时向/etc/profile 追加一个export 命令

技术

生活

架构

产品

标签

Container 23

Concurrency 14

Life 41

Tool 8

Algorithm 8

JVM 10

Go 21

Kubernetes 65

Other 5

Network 15

Python 7

Java 20

Spring 17

Netty 10

Storage 24

Distribute 9

MQ 8

WEB 5

Linux 11

Scala 1

Code 9

MachineLearning 74

Practice 16

RPC 6

Compute 11

Architecture 20

DDD 6

Reactive 5

Basic 13

Product 3

Monitor 7

CPP 2

Mesh 12