Dockerfile构建容器时服务重启与管理的实现方式有哪些

容器从设计上就不内置传统操作系统的init服务托管逻辑，单容器单进程是标准实践——容器的1号主进程就是你对外提供服务的业务进程，不存在物理机/虚拟机里systemd、sysvinit托管一堆后台服务的场景。
你碰到的service、systemctl命令能用的镜像，本质是打包了完整init系统的重型镜像，属于反实践的做法；Alpine这类精简镜像找不到这类命令才是正常状态，完全没必要额外安装initscripts之类的组件，纯属画蛇添足。

一共两种通用方案，覆盖所有合规的容器镜像：

• 方案1：直接重启整个容器（最推荐，零适配成本）
  不管你用的什么基础镜像、服务启动逻辑多复杂，只要镜像的默认启动命令是正确拉起目标服务的，改完配置后直接在宿主机执行docker restart <你的容器ID/容器名>即可。服务会随着容器启动流程重新读取所有配置，完全不需要进入容器执行任何操作，对所有镜像通用。
• 方案2：针对支持热重载的服务，直接发业务层的重载指令
  如果你的服务本身支持不重启进程重载配置（比如Nginx的nginx -s reload、Apache的httpd -k graceful），可以在宿主机通过docker exec <容器ID/容器名> <服务自带的重载命令>触发热加载，不需要重启整个容器。注意这里用的是服务本身自带的命令，和service/systemctl这类init工具没有任何关系。

避坑提醒：绝对不要为了用service restart之类的命令特意在镜像里装init系统，不仅会让镜像体积暴涨数倍，还会出现进程托管不一致、孤儿进程残留、容器退出状态异常、日志采集丢失等一堆问题，完全违背容器的设计初衷。

你提到的基于JBoss7这类现有基础镜像做二次构建的场景，完全不需要特意去翻基础镜像的Dockerfile找服务重启命令，只要遵守两个原则就不会出问题：

• 所有配置修改尽量放在Dockerfile构建阶段完成，用COPY、RUN指令把配置改好再构建镜像，不要等容器跑起来之后进容器手动改配置，避免容器重建后配置丢失，符合不可变基础设施的最佳实践。
• 如果确实需要在容器运行时调整配置，改完直接按前面说的方式重启容器即可。只要基础镜像的ENTRYPOINT/CMD是正确启动服务的，重启容器就等价于重启服务，不需要额外在容器内单独拉起服务进程——单独手动拉起的进程不会被容器1号进程托管，很容易出现进程异常退出没人管、资源无法回收的问题。

内容的提问来源于stack exchange，提问作者Akhil