Ubuntu系统Docker运行gunicorn镜像报entrypoint.sh找不到gunicorn错误求助

• 镜像版本不匹配：修改requirements.txt添加gunicorn依赖后，未重新构建并推送最新的gunicorn镜像到仓库，服务器拉取的仍是未安装gunicorn的旧版本镜像，是该问题最高发的原因。
• 架构不兼容：如果在ARM架构设备（如M1/M2系列Mac）上构建镜像，默认生成的是arm64架构镜像，而Digital Ocean的Ubuntu 20.04服务器为x86_64架构，跨架构运行时pip安装的gunicorn可执行文件无法被系统识别，会触发not found报错。
• 环境变量PATH缺失：pip安装的gunicorn可执行文件默认路径未被纳入容器内的系统PATH，执行命令时无法找到对应二进制文件。
• 入口脚本干扰：容器内置的entrypoint.sh脚本修改了运行环境的PATH，或存在执行逻辑错误，导致无法定位gunicorn。

1. 优先验证镜像内容
   在服务器上执行以下命令，确认镜像内是否存在gunicorn可执行文件：

docker run --rm link_to_built_gunicorn_image which gunicorn

如果命令无输出，说明镜像内确实未正确安装gunicorn。

2. 重新构建推送最新镜像
   本地构建镜像时添加--no-cache参数，避免旧缓存层导致依赖未更新，构建完成后重新推送到镜像仓库：

# 本地构建
docker build --no-cache -t link_to_built_gunicorn_image .
# 推送到镜像仓库
docker push link_to_built_gunicorn_image
# 服务器拉取最新镜像
docker pull link_to_built_gunicorn_image

再执行docker-compose up验证是否恢复正常。

3. 适配x86架构构建
   如果是在ARM设备上构建镜像，指定x86_64架构构建：

docker buildx build --platform linux/amd64 --no-cache -t link_to_built_gunicorn_image --push .

4. 修复PATH或指定绝对路径
   如果验证gunicorn存在但仍报错，可以直接在docker-compose中指定gunicorn的绝对路径，比如之前which命令输出为/usr/local/bin/gunicorn，则修改command配置：

command: /usr/local/bin/gunicorn --bind 0.0.0.0:8000 wsgi:app

也可以在gunicorn的Dockerfile中添加PATH环境变量声明：

ENV PATH="/usr/local/bin:$PATH"

5. 覆盖默认入口脚本
   如果是entrypoint.sh干扰导致的问题，在docker-compose的gunicorn服务配置中添加一行覆盖入口：

entrypoint: ""

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