使用一个容器管理多个应用服务进程？还是每个服务进程创建一个容器？
各区别是？
像marathon可以调度容器化服务的工具，有healthcheck功能，假如php-fpm挂了，healthcheck检查的是php-fpm端口，maraton会杀掉这个容器，重新起一个instance。
假如所有进程都放一个容器里，虽然可以建立多个health，但是healthcheak之间or的关系，假如nginx和php-fpm都挂了，healthcheck还是通过的。
也可以一个healthcheck通过nginx访问一个php页面，这样两个服务进程都检查到了。但是如果其中一个挂了了，对容器进程重启代价挺大的。
docker中的业务怎么拆，拆多细，实际上是个见仁见智的事情。
例如gogs的docker容器，启动了如下几个东西：
s6-svscan-+-s6-supervise
|-s6-supervise---gogs
|-s6-supervise---sshd
`-s6-supervise---syslogd 解释一下，一般容器启动如下东西：
1. PID=1的init进程，一般用supervisord，有些人用s6，例如上文中提到的gogs。此进程主要用于进程保活，进程重启。
2. agent，一般用于监控，某些agent还有可能会被用于执行命令等，例如有些公司会在java容器内安插一个agent，在异常的时候可以执行jmap等操作。
3. 业务进程，一般附属于init进程。很少见到有直接把业务进程当做主进程（init进程）的情况。因为主进程（init进程）跪掉，docker就跪了。
4. 其他附属进程，例如上文中提到的gogs，会附属启动一个sshd。有些还会附属启动其他服务，例如syslogd。 对于个人：
举个栗子，gitlab
对于个人，完全可以为了方便，把gitlab的所需要的所有服务，都放进同一个docker。
包括：
1. nginx
2. sshd
3. mysql
4. gitlab（unicorn） 但是实际上，生产环境中，不能这么做。
至少，即便mysql不能托管给DBA，也不要放到同一个docker里，最次，也得做关联容器，mysql放在一个篮子里，gitlab放在另一个篮子里。
从业务上来说，已经不是同一个东西了。
从稳定性上来说，也不建议。
这是使用docker的最底线的节操，不能再低了。
别人怎么拆解gitlab的业务
比如一个应该有一个web应用, 和一个数据库组件,
在web经常更新的情况下应该把两个分开, 如果稳定版, 可以用几年不更新的就放一起吧.