关于这个问题有很多讨论，所以我想再补充一个我没有立即看到上面列出的:

If the full path to the entrypoint for the container is known (or discoverable via inspection) it can be copied in and out of the stopped container using 'docker cp'. This means you can copy the original out of the container, edit a copy of it to start a bash shell (or a long sleep timer) instead of whatever it was doing, and then restart the container. The running container can now be further edited with the bash shell to correct any problems. When finished editing another docker cp of the original entrypoint back into the container and a re-restart should do the trick.

我曾经用它来纠正一个“快速修复”，我黄油手指，不再能够运行正常入口点的容器，直到它被纠正。

我也同意应该有一种更好的方式通过docker来做到这一点:也许可以选择“docker restart”来允许另一个入口点?嘿，也许这已经适用于“——entrypoint”?不确定，没有尝试过，留给读者练习，如果有用请告诉我。：）

在Entrypoint脚本的顶部添加一个检查

Docker确实需要将其作为一个新特性来实现，但这里有另一个变通选项，用于你有一个在成功或失败后终止的Entrypoint，这可能会使调试变得困难。

如果您还没有Entrypoint脚本，请创建一个可以运行容器所需的任何命令的脚本。然后，在这个文件的顶部，将这些行添加到entrypoint.sh:

# Run once, hold otherwise
if [ -f "already_ran" ]; then
    echo "Already ran the Entrypoint once. Holding indefinitely for debugging."
    cat
fi
touch already_ran

# Do your main things down here

为了确保cat保持连接，您可能需要提供一个TTY。我用我的入口点脚本运行容器，就像这样:

docker run -t --entrypoint entrypoint.sh image_name

这将导致脚本运行一次，创建一个文件，表明脚本已经运行过(在容器的虚拟文件系统中)。然后你可以重新启动容器来执行调试:

docker start container_name

当您重新启动容器时，将找到already_ran文件，导致Entrypoint脚本使用cat暂停(它只是永远等待永远不会到来的输入，但保持容器处于活动状态)。然后你可以执行一个调试bash会话:

docker exec -i container_name bash

在容器运行时，如果需要以这种方式调试，还可以删除already_ran并手动执行entrypoint.sh脚本以重新运行它。

关于这个问题有很多讨论，所以我想再补充一个我没有立即看到上面列出的:

If the full path to the entrypoint for the container is known (or discoverable via inspection) it can be copied in and out of the stopped container using 'docker cp'. This means you can copy the original out of the container, edit a copy of it to start a bash shell (or a long sleep timer) instead of whatever it was doing, and then restart the container. The running container can now be further edited with the bash shell to correct any problems. When finished editing another docker cp of the original entrypoint back into the container and a re-restart should do the trick.

我曾经用它来纠正一个“快速修复”，我黄油手指，不再能够运行正常入口点的容器，直到它被纠正。

我也同意应该有一种更好的方式通过docker来做到这一点:也许可以选择“docker restart”来允许另一个入口点?嘿，也许这已经适用于“——entrypoint”?不确定，没有尝试过，留给读者练习，如果有用请告诉我。：）

找到停止的容器id

docker ps -a

提交停止的容器:

该命令将修改后的容器状态保存到名为user/test_image的新映像中:

docker commit $CONTAINER_ID user/test_image

使用不同的入口点启动/运行:

docker run -ti --entrypoint=sh user/test_image

入口点参数描述:

https://docs.docker.com/engine/reference/run/#/entrypoint-default-command-to-execute-at-runtime

注意:

上面的步骤只是启动一个具有相同文件系统状态的已停止容器。这对快速调查很有帮助;但是环境变量、网络配置、附加卷和其他东西不是继承的。您应该显式地指定所有这些参数。

启动一个停止的容器的步骤已经从这里借来:(最后的评论)https://github.com/docker/docker/issues/18078

我的问题:

我用docker run <IMAGE_NAME>启动了一个容器 然后将一些文件添加到这个容器中 然后我关闭了容器，并尝试使用与上面相同的命令再次启动它。 但当我检查新文件时，它们不见了 当我运行docker ps -a时，我可以看到两个容器。 这意味着每次我运行docker run <IMAGE_NAME>命令时，都会创建新的映像

解决方案: 要在最初创建的容器上运行，请执行以下步骤

Docker ps获取你的容器的容器 docker容器start <CONTAINER_ID>启动现有容器 然后你可以从你离开的地方继续。例如:docker exec -它<CONTAINER_ID> /bin/bash 然后，您可以决定从中创建一个新映像

这并不是你所要求的，但是如果你想要的只是检查文件，你可以在一个停止的容器上使用docker export。

mkdir $TARGET_DIR
docker export $CONTAINER_ID | tar -x -C $TARGET_DIR