postgresql - Docker容器的可靠性

Question

我的问题旨在验证并可能纠正我对 Docker 容器可靠性的看法。我阅读了 Docker 文档和几篇关于 Dockerfile 中的 VOLUME 和 --v 的文章，作为在运行容器时将数据持久保存在 Docker 容器外的方法的参数。无论是在数据容器中还是在主机系统上。为了使设置的复杂性保持简单，我宁愿不到处复制/保存/存储数据，而是将其保存在 Docker 容器本身中。

我通过几个案例发现了 Docker 容器的行为。我想知道我是否错过了容器可能 100% 无意丢失的场景，即不执行 $ docker rm -f mycontainer

1. 用于暂停、停止和终止容器的 docker 命令-> 可通过 $ docker restart mycontainer 或 $ docker run mycontainer

重新启动

2. 主机系统重启-> docker 容器以 0 或 255 退出

3. 主机系统意外断电-> 会发生什么？

4. 应用异常-> docker 容器以 -1 退出

5. 更新或重启 docker(正如 Greg 所指出的)-> 预期行为:就像系统重启时一样 (?)

在所有这些情况下，docker 容器最终仍然存在。那么是否有任何其他情况会导致 docker 容器丢失，例如 $ docker rm -f mycontainer？

背景是，我阅读了很多有关 Postgres 主机系统上挂载卷和外部数据存储的内容，但我想尽可能避免将数据存储在主机系统上的容器之外。另一方面，我不想一觉醒来发现所有数据都丢失了。 (我确实执行常规的 SQL 转储，但我不想每 5 分钟执行一次)。如果 docker 容器本身对于持久数据不可靠，我不明白为什么我应该创建第二个容器来保存第一个容器的数据并通过添加一个新容器来增加我的系统的复杂性但没有获得任何东西可靠性。

编辑:Docker userguide on Volumes中有两点它没有明确解释预期的行为，因此让我质疑这些概念是否提供了额外的可靠性:

1. 更新数据卷时不会包含对数据卷的更改图片-> 这是否意味着他们迷路了或卷的内容不会更改？

2. 卷一直存在，直到没有容器使用它们-> “使用”的定义是什么？只要容器不被停止、杀死、删除？这是否意味着 Docker 在主机系统上创建的卷将被删除？还是卷只是指 Docker 内部目录与主机系统目录之间的虚拟桥？

Answer 1

如果你把你所有的数据都存储在容器里，当你需要更新镜像的时候你打算怎么办？镜像的更新通常通过更改 Dockerfile 和重建镜像来完成。如果我的数据与我的容器分开，我可以启动一个新版本的图像，使用 --volumes-from 或 -v 挂载数据并杀死旧的容器。在您的情况下，您必须保持容器运行并尝试使用 puppet 之类的东西进行修补。

此外，我不确定您认为自己节省了什么。如果您运行官方 postgres 图像，它将在 Dockerfile 中声明卷。无论您是否使用 -v 运行容器，这些卷都作为主机系统上的普通目录存在。即使您的 Dockerfile 没有卷，显然 UFS 无论如何都存储在您的主机上。

一般来说，您应该将容器视为临时的和无状态的。虽然您不必这样做，但您会发现大多数工具和支持服务都是围绕这个习语设计的。

关于您的场景，您缺少一些:

• 一个错误可能导致无法重新启动已停止的容器
• 上述更新问题
• 如果您想更改存储驱动程序。这会导致很多问题，因为您需要迁移图像。

为了清楚起见，docker start 将重新启动已停止或退出的容器，docker unpause 将取消暂停暂停的容器。