https://github.com/kiwenlau/kubernetes-shell
https://github.com/kiwenlau/kubernetes-supervisor
一般来说，Docker容器比较适合运行单个进程。例如，项目”使用多个Docker容器运行Kubernetes“，Kubernetes的各个组件分别运行在各个容器之中，每个容器只运行单个进程。

然而，很多时候我们需要在Docker容器中运行多个进程。例如，项目”使用单个Docker容器运行Kubernetes“，kubernetes的各个组件均运行在同一个容器中，该容器中运行了多个进程。那么，如何运行多进程Docker容器？

一种方法是使用Shell脚本，另一种方法是使用进程管理工具Supervisor。kiwenlau/kubernetes-shell和kiwenlau/kubernetes-supervisor分别采用了这两种方法，用于启动多个进程来运行Kubernetes的各个组件，从而实现”使用单个Docker容器运行Kubernetes“。下面我将分别介绍两种不同方法。

二. 使用Shell脚本运行多进程Docker容器
这个方法大家应该会比较熟悉，使用Shell脚本依次启动Kubernetes的各个组件即可。以下为start-kubernetes.sh

#!/bin/bash

start docker daemon

docker daemon > /var/log/docker.log 2>&1 &

start etcd

etcd –data-dir=/var/etcd/data > /var/log/etcd.log 2>&1 &

wait for ectd to setup

sleep 5

start apiserver

kube-apiserver –service-cluster-ip-range=10.0.0.1/24 –insecure-bind-address=0.0.0.0 –etcd_servers=http://127.0.0.1:4001 > /var/log/kube-apiserver.log 2>&1 &

wait for apiserver to setup

sleep 5

start controller manager, sheduler, kubelet and proxy

kube-controller-manager –master=http://0.0.0.0:8080 > /var/log/kube-controller-manager.log 2>&1 &
kube-scheduler –master=http://0.0.0.0:8080 > /var/log/kube-scheduler.log 2>&1 &
kubelet –api_servers=http://0.0.0.0:8080 –address=0.0.0.0 –cluster_dns=10.0.0.10 –cluster_domain=”kubernetes.local” –pod-infra-container-image=”kiwenlau/pause:0.8.0” > /var/log/kubelet.log 2>&1 &
kube-proxy –master=http://0.0.0.0:8080 > /var/log/kube-proxy.log 2>&1 &

just keep this script running

while [[ true ]]; do
sleep 1
done
然后在Dockerfile中，将start-kubernetes.sh指定为Docker容器默认执行的命令即可:

CMD [“start-kubernetes.sh”]
需要注意的一点在于，start-kubernetes.sh脚本将作为Docker容器的1号进程运行，必须始终保持运行。因为Docker容器仅在1号进程运行时保持运行，换言之，Docker容器将在1号进程退出后Exited。由于Kubernetes的各个组件都以后台进程方式执行，我在脚本末尾添加了死循环，以保持start-kubernetes.sh脚本始终处于运行状态。

just keep this script running

while [[ true ]]; do
sleep 1
done
三. 使用supervisor运行多进程Docker容器
Supervisor是进程管理工具。这时，需要编写supervisor的配置文件kubernetes.conf:

[supervisord]
nodaemon=true

[program:etcd]
command=etcd –data-dir=/var/etcd/data
autorestart=true
stdout_logfile=/var/log/etcd.stdout.log
stderr_logfile=/var/log/etcd.stderr.log

[program:kube-apiserver]
command=kube-apiserver –service-cluster-ip-range=10.0.0.1/24 –insecure-bind-address=0.0.0.0 –etcd_servers=http://127.0.0.1:4001
autorestart=true
stdout_logfile=/var/log/kube-apiserver.stdout.log
stderr_logfile=/var/log/kube-apiserver.stderr.log

[program:kube-controller-manager]
command=kube-controller-manager –master=http://0.0.0.0:8080
autorestart=true
stdout_logfile=/var/log/controller-manager.stdout.log
stderr_logfile=/var/log/controller-manager.stderr.log

[program:kube-scheduler]
command=kube-scheduler –master=http://0.0.0.0:8080
autorestart=true
stdout_logfile=/var/log/kube-scheduler.stdout.log
stderr_logfile=/var/log/kube-scheduler.stderr.log

[program:kubelet]
command=kubelet –api_servers=http://0.0.0.0:8080 –address=0.0.0.0 –cluster_dns=10.0.0.10 –cluster_domain=”kubernetes.local” –pod-infra-container-image=”kiwenlau/pause:0.8.0”
autorestart=true
stdout_logfile=/var/log/kubelet.stdout.log
stderr_logfile=/var/log/kubelet.stderr.log

[program:kube-proxy]
command=kube-proxy –master=http://0.0.0.0:8080
autorestart=true
stdout_logfile=/var/log/kube-proxy.stdout.log
stderr_logfile=/var/log/kube-proxy.stderr.log

[program:docker]
command=docker daemon
autorestart=true
stdout_logfile=/var/log/docker.stdout.log
stderr_logfile=/var/log/docker.stderr.log
可知，将Kubernetes的各个组件的启动命令设为command即可。autorestart参数设为true，意味着supervisor将负责重启意外退出的组件。stdout_logfile和stderr_logfile参数则可以用于设置命令的标准输出文件和标准错误输出文件。

然后在Dockerfile中，将supervisord指定为Docker容器默认执行的命令即可:

CMD [“supervisord”, “-c”, “/etc/supervisor/conf.d/kubernetes.conf”]
此时, supervisord是Docker容器中的1号进程，也需要始终保持运行状态。nodaemon设为true时，表示supervisor保持前台运行而非在后台运行。若supervisor在后台运行，则Docker容器也会在执行supervisord命令后立即Exited.

[supervisord]
nodaemon=true
四. 总结
使用Shell脚本运行多进程Docker容器，优势是大家比较熟悉。由于需要保持Docker容器的1号进程始终运行，这一点比较容易出错。若要实现进程意外退出后自动重启的话，使用shell脚本比较麻烦。

使用supervisor运行多进程Docker容器，非常方便。另外，保持1号进程保持运行，以及进程意外退出后自动重启，实现起来都很简单。

使用多个Docker容器运行Kubernetes
GitHub地址
https://github.com/kiwenlau/single-kubernetes-docker

https://docs.docker.com/config/containers/multi-service_container/

https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container

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

但容器中运行多进程，跟 one process per container 的理念相悖，我们就得探寻下来龙去脉了。

从业界来说，虽然一个容器一个进程是官方推荐，但好像并不被大厂所遵守，以至于阿里甚至专门搞了一个PouchContainer 出来，美团容器平台架构及容器技术实践

此外要注意的是，一个容器多进程 在k8s 的Pod 概念下，要相机做出一定的调整。

为什么推荐一个容器一个进程？
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.

一个容器多个进程有什么风险
理解Docker容器的进程管理

linux 对pid=1进程的要求

管理孤儿进程。当一个子进程终止后，它首先会变成一个“失效(defunct)”的进程，也称为“僵尸（zombie）”进程，等待父进程或系统收回（reap）。如果父进程已经结束了，那些依然在运行中的子进程会成为“孤儿（orphaned）”进程。在Linux中Init进程(PID1)作为所有进程的父进程，会维护进程树的状态，一旦有某个子进程成为了“孤儿”进程后，init就会负责接管这个子进程。当一个子进程成为“僵尸”进程之后，如果其父进程已经结束，init会收割这些“僵尸”，释放PID资源。
如果它没有提供某个信号的处理逻辑，那么发送给它的该信号都会被屏蔽。init 进程一般不处理 SIGTERM 信号，they’re built for hardware shutdowns instead. 原本是防止init进程被误杀。
docker stop 对PID1进程 的要求

支持管理运行过程中可能产生的僵尸/孤儿进程
容器的PID1进程需要能够正确的处理SIGTERM信号来支持优雅退出，如果容器中包含多个进程，需要PID1进程能够正确的传播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
一个容器多个进程的可能选择
自定义脚本
官方 Run multiple services in a container

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”]
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 工作原理

s6
Managing multiple processes in Docker containers

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
优雅的管理springboot 项目
回到文开始提到的问题：

phusion/baseimage-docker 的image 是基于ubuntu，笔者试着用alpine + runit + sshd 实现了一个简洁的base image，具体情况待实践一段时间再交流。

多进程方式，使得不管springboot 是否启动成功，容器都会启动成功
另外采取 措施监控 springboot 的健康状态，以决定是否 向该容器打入流量
runit 正常会尝试不断重启，实际上往往因为代码的原因，启动一次就行了。因此启动springboot 的时候，先检查下 有没有/etc/service/springboot/supervise（runsv将服务的状态保存服务对应在supervise目录中） 文件，若没有则是第一次启动。有则是第二次启动，写入/etc/service/springboot/down（down 告知runsv 停止该服务）

https://qiankunli.github.io/2018/11/06/multi_process_per_container.html