是否可以重新进入已关闭的已发布docker容器？

背景：

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

我需要开发一个Dockerfile

但在此之前，我想选择一个基础映像，并在此基础映像上启动一个容器基础

容器启动后，我想尝试安装一些软件包，并修改我的服务的一些配置。如果手动操作一切正常，最后我可以将所有这些步骤移到Dockerfile中：package install&configure settings（包安装和配置设置）（通过手动尝试证明是有效的）

问题：

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

有时，在我尝试了许多正确的步骤之后，然后进行了错误的配置。更糟糕的是，我停止容器并再次启动容器，以证明启动脚本是否正常

但不幸的是，容器已经无法启动，因为容器中配置了错误的应用程序

事实上，我想尝试在容器中进行其他配置，然后也许一切都会好起来，但我再也没有机会进入容器了。我不想重新设置一个新的容器，因为我已经在旧容器中做了很多手动操作（因为我处于开发阶段，所以没有将正确的步骤移动到Dockerfile，我想在证明一切正常后再做）

接下来是展示我的案例的最小示例：

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

Dockerfile:

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

docker entrypoint.sh:

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

我将如何处理上述内容：

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

将docker entrypoint.sh更改为下一步：

#!/bin/sh

exit 0
touch /tmp/app.log
tail -f /tmp/app.log

然后：

现在，我知道退出0可能是错误的命令或错误的配置，我想用其他东西再试一次，但没有机会

再次，要注意的是：

我不想重置容器，因为我已经在旧容器中手动执行了许多操作，而不仅仅是退出0

而且，

supervisord

也不是我在开发生命周期中所需要的，我只是想让事情变得简单。类似于更改已有容器的入口点（似乎只适用于

docker run

）

---

有什么建议可以让我放松我的开发阶段吗？

很有趣。基本上，您现在有了一个容器，它运行一个立即退出的脚本。然而，你想保存它

不妨尝试以下方法：

将容器作为另一个映像提交

docker提交我/快照：v001

使用图像运行bash

docker run-it--name me2 me/snap:v001 bash

修复入口点代码

---

只要写你的Dockerfile。编辑，运行docker build，重复

Dockerfile没有什么特别神奇的。如果您采取您的方法，但决定在文本文件中做详细记录：我想从某个基本图像开始

，然后
运行某个命令，
复制中的某些文件，以及
运行其他命令：这是Dockerfile。它的优点是始终从清洁的环境开始，并且始终是可复制的

例如，假设您试图手工编译某个包，但没有正确的配置选项

FROM ubuntu:18.04
RUN apt-get update && apt-get install build-essential
WORKDIR /package
COPY some-package.tar.gz ./
RUN tar xzf some-package.tar.gz
WORKDIR /package/some-package
RUN ./config --wrong-option
RUN make
RUN make install
CMD ["some-command"]

现在，您可以运行
docker build.
，它将运行这一系列命令。当它到达
RUN./config
时，可能会失败（因为脚本实际上名为
/configure
）。您可以编辑docker文件并重新运行
docker build
，docker将在以前失败的地方重新启动。类似地，当您发现
--error选项
错误时，您可以对其进行更改，并且
docker build
将从更改的行重新启动

如果您需要在中断的阶段上进行进一步调试（可能是
--错误选项
完成了配置步骤，但构建失败），
docker build
输出包括每个层的图像ID，您可以
docker运行--rm-it 0123456789ab sh
在出现问题的步骤之前获取部分图像的外壳

有一些优化，比如将
RUN
行组合在一起以及多阶段构建，这些都很有用，但您可以将它们保存到最后

docker exec
并不是您与docker交互的主要方式。您将遇到与您所遇到的问题完全相同的问题：您所做的事情没有持久的记录，它不是特别可复制的，如果容器被删除，您将丢失所有的工作。
是的，
docker exec
不是与docker交互的主要方式，但通过这种方式，我可以很快知道应该在
dockerfile
中放什么，因为我的短期记忆可以让我这么做。我的意思是运行时问题（在CMD或Entrypoint之后），而不是构建中的问题（运行或其他）相同的答案：编写脚本，
将其复制到图像中，
docker build
，
docker RUN
，重复。我不会在这里依赖交互式shell。