如何在含ENTRYPOINT的Docker镜像CMD执行前运行自定义脚本？

方案1：修改CMD执行多命令的弊端 #

你提到的第一种方案操作确实简单，但存在几个关键问题：

• PID 1 信号处理异常：原镜像的entrypoint脚本最后用exec "$@"让业务进程（比如postgres）成为容器的PID 1，这样容器收到停止信号（如docker stop的SIGTERM）时，信号能直接传递给业务进程，保证优雅退出。但改成CMD sh /before-cmd.sh ; postgres后，实际执行的是shell进程作为PID 1，它会忽略部分信号，导致业务进程无法正确响应停止指令，最终容器可能被强制杀死，而非优雅关闭。
• 错误无感知：如果before-cmd.sh执行失败（返回非0状态码），shell会继续执行后续的postgres命令，导致业务进程在前置脚本出错的情况下依然启动，埋下运行隐患。
• 执行逻辑变味：原镜像的ENTRYPOINT和CMD是配合工作的（比如Postgres的ENTRYPOINT会先做初始化、权限配置等关键操作），修改CMD为多命令串后，ENTRYPOINT会把整个命令串当作参数执行，最终启动的是shell而非直接的业务进程，间接改变了原有的执行链路。

方案2：修改原Entrypoint脚本的隐患 #

第二种方案通过sed注入逻辑，能保证前置脚本在exec "$@"前执行，看似贴合原流程，但最大问题是依赖原entrypoint的代码格式。如果原镜像升级（比如Postgres官方镜像更新了docker-entrypoint.sh的内容），你的sed匹配规则可能失效，导致镜像构建失败，或者注入逻辑不生效，引发未知问题。这种方案的维护成本会随着原镜像的更新而升高。

更优的第三种方案：自定义Entrypoint脚本 #

最稳妥的方式是编写一个自定义的entrypoint脚本，作为原entrypoint的“包装层”，具体步骤如下：

1. 编写自定义entrypoint脚本custom-entrypoint.sh：

#!/bin/sh
# 开启错误终止模式：如果前置脚本执行失败，直接退出
set -e
# 执行你的前置脚本
. /before-cmd.sh
# 调用原镜像的entrypoint脚本，并传递所有参数
exec /docker-entrypoint.sh "$@"

2. 在Dockerfile中配置：

# 复制前置脚本和自定义entrypoint
COPY before-cmd.sh /
COPY custom-entrypoint.sh /
# 添加执行权限
RUN chmod +x /before-cmd.sh /custom-entrypoint.sh
# 替换为自定义entrypoint，保留原CMD
ENTRYPOINT ["/custom-entrypoint.sh"]
CMD ["postgres"]

这种方案的优势很明显：

• 完全保留原镜像entrypoint的所有初始化逻辑，不会因为原镜像更新而失效（只要原entrypoint的路径不变）
• 通过set -e可以实现前置脚本失败即终止，避免业务进程错误启动
• 最终业务进程依然会成为PID 1，信号处理完全符合原镜像的优雅退出逻辑
• 逻辑清晰，代码可维护性高，不需要依赖原entrypoint的内部实现细节

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