Docker镜像启动崩溃问题求助：为何将pip install poetry移至COPY指令前可解决问题？

大家好，最近我在优化一个基于Python的Docker镜像时碰到了一个棘手的问题：当我把pip install poetry这条命令放在COPY项目文件之后执行时，镜像虽然能成功构建，但启动后会直接崩溃并返回错误码；而把这条命令移到所有COPY指令之前，镜像就能正常运行了。我试过好几种配置，只有这一个改动能解决问题，想请大家帮忙分析下背后的原因。

问题重现的初始配置 #

我的初始Dockerfile是这样的：

FROM python:3.13-bookworm

ARG POETRY_VERSION=2.0.1

WORKDIR /app

RUN touch README.md
COPY poetry.lock pyproject.toml ./
COPY mymodule ./mymodule

RUN pip install poetry==$POETRY_VERSION
RUN poetry install

启动崩溃的日志 #

镜像构建成功后，启动时会输出以下日志然后退出：

Attaching to signal-api-1, signal-bot-1
signal-api-1  | + set -e
signal-api-1  | + [ -z /home/.local/share/signal-cli ]
signal-api-1  | + usermod -u 1000 signal-api
signal-api-1  | usermod: no changes
signal-api-1  | + groupmod -o -g 1000 signal-api
signal-api-1  | + chown 1000:1000 -R /home/.local/share/signal-cli
signal-api-1  | + cat
signal-api-1  | + cap_prefix=-cap_
signal-api-1  | + cat /proc/sys/kernel/cap_last_cap
signal-api-1  | + seq -s ,-cap_ 0 40
signal-api-1  | + caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40
signal-api-1  | + [ json-rpc = json-rpc ]
signal-api-1  | + /usr/bin/jsonrpc2-helper
signal-api-1  | time="2025-01-31T12:14:27Z" level=info msg="Updated jsonrpc2.yml"
signal-api-1  | + [ -n  ]
signal-api-1  | + service supervisor start
signal-api-1  | Starting supervisor: 
signal-api-1 exited with code 1
signal-bot-1 exited with code 144

解决问题的改动 #

我只做了一个关键改动：把pip install poetry移到所有COPY指令之前，修改后的Dockerfile如下：

FROM python:3.13-bookworm

ARG POETRY_VERSION=2.0.1

WORKDIR /app

RUN pip install poetry==$POETRY_VERSION

RUN touch README.md
COPY poetry.lock pyproject.toml ./
COPY mymodule ./mymodule

RUN poetry install

正常启动的日志 #

修改后，镜像启动就能正常运行了，日志如下：

Attaching to signal-api-1, signal-bot-1
signal-api-1  | + set -e
signal-api-1  | + [ -z /home/.local/share/signal-cli ]
signal-api-1  | + usermod -u 1000 signal-api
signal-api-1  | usermod: no changes
signal-api-1  | + groupmod -o -g 1000 signal-api
signal-api-1  | + chown 1000:1000 -R /home/.local/share/signal-cli
signal-api-1  | + cat
signal-api-1  | + cap_prefix=-cap_
signal-api-1  | + cat /proc/sys/kernel/cap_last_cap
signal-api-1  | + seq -s ,-cap_ 0 40
signal-api-1  | + caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40
signal-api-1  | + [ json-rpc = json-rpc ]
signal-api-1  | + /usr/bin/jsonrpc2-helper
signal-api-1  | time="2025-01-31T12:32:28Z" level=info msg="Updated jsonrpc2.yml"
signal-api-1  | + [ -n  ]
signal-api-1  | + service supervisor start
signal-api-1  | Unlinking stale socket /var/run/supervisor.sock
signal-api-1  | Starting supervisor:  ERROR.
signal-api-1  | + supervisorctl start all
signal-api-1  | + hostname -I
signal-api-1  | + awk {print $1}
signal-api-1  | + export HOST_IP=192.168.32.2
signal-api-1  | + exec setpriv --reuid=1000 --regid=1000 --init-groups --inh-caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
signal-api-1  | time="2025-01-31T12:32:29Z" level=info msg="Started Signal Messenger REST API"
signal-bot-1  | WARNING:root:[Bot] Could not initialize Redis. In-memory storage will be used. Restarting will delete the storage!
signal-api-1  | [GIN] 2025/01/31 - 12:32:33 | 200 |  1.303127316s |    192.168.32.3 | GET      "/v1/groups/+REDACTED"

我的疑惑 #

虽然问题解决了，但我还是搞不懂两个关键点：

1. 为什么pip install poetry的执行位置会影响镜像的启动逻辑？按道理这只是安装一个依赖管理工具，不该和后续的容器启动流程挂钩才对。
2. 我构建的是signal-bot镜像，而启动时的错误其实来自一个预构建的signal相关镜像，为什么我自己的Dockerfile构建步骤会影响到这个预构建镜像的运行呢？

备注：内容来源于stack exchange，提问作者sven2388