Docker容器启动多指令需按串行或并行逻辑组织：串行推荐sh -c加exec或独立startup.sh；并行需wait+后台任务或交由编排层；构建并行属BuildKit范畴，与运行时无关。
在 docker 容器启动时执行多条指令，关键不在于“容器本身支持并行”，而在于**如何组织命令逻辑**——串行是默认行为，并行需主动设计。实际场景中，绝大多数需求是“串行执行多个准备动作后启动主进程”，少数场景（如构建、预热、健康检查）才需要真正并行。下面从原理和实操两个层面说清楚。
串行执行：用 shell 脚本或分号连接最稳妥
容器的 entrypoint 或 command 只能指定一个主进程，但这个进程可以是 sh、bash 等 shell，从而顺序执行多条命令。这是最常用、最可靠的方式。
- 使用
sh -c连接多条命令（推荐）：command: ["sh", "-c", "echo 'step1'; sleep 2; echo 'step2'; exec myapp"]
注意最后用exec替换当前 shell 进程，确保myapp成为 PID 1，能正常接收 SIGTERM。 - 写成独立启动脚本（更清晰）：
在镜像中放入/startup.sh，内容含初始化逻辑 +exec "$@"，然后设ENTRYPOINT ["/startup.sh"]，CMD ["myapp"]。这样既可复用，又避免信号丢失问题。 - 避免直接用
&&做强依赖链（如cmd1 && cmd2 && app）：一旦中间命令失败（返回非零），后续全跳过，可能掩盖问题；更适合做条件判断而非流程控制。
并行执行：必须靠外部工具或拆分成多个容器
Docker 单个容器的启动命令本身不提供原生并行机制。所谓“并行”，本质是让多个进程在容器内同时运行——但这会带来管理复杂度和信号处理风险。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 用
wait+ 后台任务模拟简单并行：["sh", "-c", "cmd1 & cmd2 & cmd3 & wait; exec myapp"]
适合轻量级、无交互、生命周期短的辅助任务（如预热缓存、上报就绪状态）。注意后台进程不能是孤儿，否则可能被 init 回收。 - 不建议在单容器内长期运行多个长进程：
违反“一个容器一个关注点”原则；PID 1 不再是主应用，导致优雅退出失效；日志混杂、故障难定位。 - 真正健壮的并行应交给编排层：
用 Docker Compose 的depends_on+ 多 service 拆分，或 Kubernetes 中用 InitContainer 做前置并行准备，主容器只负责核心业务。例如：一个 InitContainer 下载配置，另一个校验证书，都完成后主应用才启动。
构建阶段的并行：和运行时无关，但常被混淆
很多人提到“Docker 并行”实际是指 镜像构建过程，这和容器启动完全不是一回事。
- BuildKit 默认启用 DAG 调度，对无依赖的
FROM ... RUN阶段（如多阶段构建中的 builder-a 和 builder-b）可自动并行执行，加快构建速度。 - 但这发生在
docker build阶段，生成的是静态镜像；运行时容器启动仍是单 entrypoint 流程。 - 构建并行不影响容器内进程模型，也不解决运行时多命令调度问题。
特别注意信号与 PID 1 的关系
无论串行还是并行，只要主进程不是 PID 1，容器收到 SIGTERM 时无法传递给业务进程，导致强制 kill（退出码 137）。所以：
- 所有 shell 封装方案，结尾必须用
exec替换当前进程； - 避免
bash startup.sh && myapp这类写法——bash占据 PID 1，myapp是子进程，收不到信号； - Kubernetes 中若用
postStart执行额外逻辑，它和主容器进程是并发的，但不共享生命周期，不能替代启动脚本。
