最稳妥的容器初始化方式是使用自定义ENTRYPOINT脚本：以#!/bin/sh开头、chmod +x、执行初始化后用exec "$@"启动主进程，确保PID 1信号处理正常；可配合wait-for-it.sh做依赖等待，并注意绝对路径、命令存在性、set -e防错。
容器创建时通过传递启动脚本初始化环境，核心是让脚本在容器真正运行主进程前执行，且不破坏 PID 1 的信号处理能力。最稳妥、生产推荐的方式是用自定义 ENTRYPOINT 脚本，而不是靠 CMD 或临时挂载后手动执行。
用 ENTRYPOINT 脚本接管启动流程
这是最可控的方法：把初始化逻辑写进一个 shell 脚本，设为容器入口点，执行完再用 exec "$@" 启动原命令。
- 脚本开头必须写
#!/bin/sh（或#!/bin/bash），并赋予可执行权限：chmod +x entrypoint.sh - 初始化操作放中间，比如改配置：
sed -i "s/DB_HOST/$DB_HOST/" /app/config.yml，或生成密钥、设置目录权限等 - 最后必须以
exec "$@"结尾，确保 CMD 或运行时传入的命令成为 PID 1，能正常接收 SIGTERM 等信号 - Dockerfile 中写：
COPY entrypoint.sh /entrypoint.sh和ENTRYPOINT ["/entrypoint.sh"]
运行时动态挂载脚本（适合调试或临时场景）
不修改镜像也能初始化，适用于测试、CI 或需灵活替换逻辑的情况。
- 把本地脚本映射进容器：
docker run -v $(pwd)/init.sh:/init.sh ... myimage - 容器内需有解释器支持（如
/bin/sh），并在启动命令中调用：docker run -v $(pwd)/init.sh:/init.sh myimage /bin/sh /init.sh && exec "$@" - 注意：这种方式绕过镜像原有 ENTRYPOINT/CMD，容易出错；建议仅用于验证逻辑，不用于生产
配合 docker-compose 做依赖等待和多步初始化
单容器初始化简单，但真实场景常需等数据库、Redis 等依赖就绪。这时不能只靠脚本顺序执行，得加重试机制。
- 在 entrypoint.sh 里嵌入等待逻辑，例如：
until nc -z db 5432; do sleep 2; done - 更健壮的做法是引入
wait-for-it.sh这类轻量工具，它支持超时、退出码判断，避免无限等待 - 若初始化步骤复杂（如先建库、再导入 SQL、再跑迁移），建议拆成多个小脚本，在 entrypoint.sh 中按顺序调用，并检查每步返回值：
./init-db.sh || exit 1
避免踩坑的关键细节
很多初始化失败不是逻辑问题，而是执行环境或权限导致的。
- 路径必须用绝对路径，容器里没有默认工作目录保障
- 所有外部命令（如
mysql、pg_isready）要确认已安装，或提前打包进镜像 - 脚本中加
set -e，任意命令失败立即退出，防止跳过关键步骤 - 不要在后台启动服务（如
service nginx start &），否则主进程可能提前结束，容器退出
