在文件更改时重建Docker容器

在文件更改时重建Docker容器

经过一些研究和测试，我发现我对Docker容器的生命存在一些误解。在此期间重建映像时，仅重新启动容器并不会使Docker使用新映像。相反，Docker仅
在 创建容器 之前 获取映像。因此，运行容器后的状态是持久的。

为什么需要删除

因此，仅重建和重新启动是不够的。我认为容器就像服务一样工作：停止服务，进行更改，重新启动它，它们将适用。那是我最大的错误。

由于容器是永久性的，因此您必须先使用容器将其删除

docker rm <ContainerName>

。删除容器后，您不能简单地通过来启动它

dockerstart

。必须使用来完成此 *** 作

docker run

，本身使用最新的图像来创建新的容器实例。

容器应尽可能独立

有了这些知识，就可以理解为什么将数据存储在容器中被视为不良做法，而Docker建议改为使用数据卷/挂载主机目录：由于必须销毁容器来更新应用程序，因此内部存储的数据也将丢失。这会导致额外的工作来关闭服务，备份数据等。

因此，将这些数据完全从容器中排除是一个明智的解决方案：当数据安全地存储在主机上并且容器仅包含应用程序本身时，我们不必担心我们的数据。

为什么

-rf

不能真正帮助您

该

docker run

命令有一个名为的 清理
开关

-rf

。它将停止永久保留docker容器的行为。使用

-rf

，Docker将在退出容器后销毁该容器。但是此开关有两个问题：

1. Docker还删除了没有与容器相关联的名称的卷，这可能会杀死您的数据
2. 使用此选项，将无法使用

   -d

   switch 在后台运行容器

虽然该

-rf

开关是节省开发过程中的工作以进行快速测试的不错选择，但它不适用于生产环境。特别是由于缺少在后台运行容器的选项，因此通常需要这样做。

如何取出容器

我们可以通过简单地删除容器来绕过这些限制：

docker rm --force <ContainerName>

的

--force

（或

-f

其中使用SIGKILL上运行的容器）开关。相反，您也可以在以下之前停止容器：

docker stop <ContainerName>docker rm <ContainerName>

两者相等。

dockerstop

也正在使用SIGTERM。但是，使用

--force

switch会缩短脚本，尤其是在使用CI服务器时：

dockerstop

如果容器未运行，则会引发错误。这将导致Jenkins和许多其他CI服务器错误地认为构建失败。要解决此问题，您必须首先检查容器是否正在按问题中的方式运行（请参阅

containerRunning

变量）。

用于重建Docker容器的完整脚本

根据这一新知识，我通过以下方式修复了脚本：

#!/bin/bashimageName=xx:my-imagecontainerName=my-containerdocker build -t $imageName -f Dockerfile  .echo Delete old container...docker rm -f $containerNameecho Run new container...docker run -d -p 5000:5000 --name $containerName $imageName

这完美地工作:)