Docker容器的可靠性
我的问题旨在validation并纠正我对Docker容器可靠性的想法。 我在Docker文件中读取了Docker文档和一些关于VOLUME文章，而在运行容器时将-v作为参数读取，以便将数据保存在Docker容器之外。 放在数据容器或主机系统上。 为了保持设置的复杂性，我不希望复制/保存/存储数据，而是将其保存在Docker容器中。
有几种情况我通过它发现了Docker容器的行为。 我想知道如果我错过了一个容器可以100％丢失的场景，即不做$ docker rm -f mycontainer
-
docker命令暂停，停止和杀死一个容器 – >可重新启动
$ docker restart mycontainer或者$ docker run mycontainer -
主机系统重启 – > docker容器退出0或255
-
主机系统意外断电 – >会发生什么情况？
-
应用程序exception – > docker容器以-1退出
-
更新或重新启动docker（正如Greg指出的那样） – >期望的行为：就像在系统重启（？）
在所有这些情况下，docker集装箱依然存在。 那么是否还有其他一些可能导致$ docker rm -f mycontainer容器丢失的情况，如$ docker rm -f mycontainer ？
背景是，我读了很多关于在Postgres的主机系统上安装的卷和外部数据存储，但我想避免在我的容器之外的数据存储在主机系统上，如果可能的话。 另一方面，我不想醒来，所有的数据都丢失了。 （我确实执行了常规的SQL转储，但是我不想每5分钟做一次）。 如果Docker容器本身对于持久性数据不可靠，我不明白为什么要创build第二个容器来保存第一个容器的数据，并通过添加一个新的容器来增加系统的复杂性，但却无法获得任何的可靠性。
编辑： 在Volumes上的Docker用户指南中有两点没有明确地解释期望的行为，因此让我质疑这些概念是否提供了额外的可靠性：
-
更新图像时不会包含对数据量的更改 – >这是否意味着它们会丢失或者卷的内容不会被更改？
-
卷持续存在，直到没有容器使用它们 – > “使用”的定义是什么？ 只要一个集装箱不停，杀死，拆除？ 这是否意味着在主机系统上创build的卷Docker将被删除？ 或者，卷只是指Docker内部的目录与主机系统之间的虚拟桥？
如果将所有数据存储在容器中，则当您需要更新映像时，您将要做什么？ 通常通过更改Dockerfile并重build映像来更新映像。 如果我的数据与我的容器保持独立，则可以启动新版本的映像，使用--volumes-from或-v装入数据并杀死旧容器。 在你的情况下，你必须保持容器运行，并尝试用木偶等东西补丁。
另外，我不确定你认为你在保存什么。 如果你运行官方的postgres映像，它将在Dockerfile中声明卷。 这些卷作为主机系统上的普通目录存在，无论您是否使用-v运行容器。 即使你的Dockerfile没有卷，显然UFS仍然存储在你的主机上。
一般来说，你应该认为集装箱是暂时的，无国籍的。 虽然你不必这样做，你会发现大多数的工具和支持服务是围绕这个习惯用法devise的。
关于你的情况，有几个你想念：
- 一个错误可能会导致无法重新启动已停止的容器
- 上面提到的更新问题
- 如果你想更改存储驱动程序。 这将导致很多问题，因为你需要迁移你的图像。
只是为了清楚的命令， docker start将重新启动停止或退出容器和docker unpause将取消暂停容器。