在Docker中使用Data Volume Container作为单一数据库“后端”有什么好处？
我正试图把握独立数据量容器的想法。 在许多地方，我发现被提倡的是有益的（就像这个问题一样 ），但是我没有看到使用单独的数据容器进行简单的一个数据库堆栈的任何意义。 我知道：
- 它解耦我的数据库容器 – 但为什么要这样？ 我不会更改数据库映像，因为我没有在这里开发数据库。
- 它允许我分享数据 – 但是，我没有人分享，只有一个使用它的容器
- 它可以防止我意外地删除一个容器 – 这是真的吗？它没有被更多的删除保护，我单一的一体化容器是
- 我可以轻松地备份 – 就像我可以在我唯一的容器里备份数据一样，对吗？
我清楚地看到这种方法在不同设置中的好处，当数据要以某种方式共享时，但是作为“容器作为数据库”的问题的解决scheme，对我来说似乎只是更多的麻烦。
我错过了什么？
我仍然在Docker开发的边缘，所以这只是教育猜测我从读/听到。 回应你的问题：
- 它解耦我的数据库容器 – 但为什么要这样？ 我不会更改数据库映像，因为我没有在这里开发数据库。
- 它可以防止我意外删除一个容器 – 是否真的吗？ 我的单一的一体化容器是没有被删除保护的
说你或者下一个维护这个系统的家伙，在稍后的某个时候出现，并且想升级你的postgres版本（或者你的SQL堆栈）。 您决定将新版本的Docker容器/图像放置在旧版本的Docker容器/图像上，将会更容易。 如果您的一个docker集装箱同时拥有数据和软件，则不具备该选项。 当然，你仍然可以搞砸你的数据量，但是你不能用一个分离的服务器容器搞砸你的数据。
- 它允许我分享数据 – 但是，我没有人分享，只有一个使用它的容器
你现在可能不会分享它; 你可能永远没有人分享。 但是这并不意味着你不想在系统，应用程序，服务器等之间共享它。
- 我可以轻松地备份 – 就像我可以在我唯一的容器里备份数据一样，对吗？
当然，但是如果您要备份整个容器，则每次都要随软件一起备份软件，这是不必要的。 如果你将数据从你的容器中倒出来，那么你实际上并没有考虑容器。
我所看到的具有分离数据量的一个明显优势是在环境之间移动数据。 假设您想要在舞台环境中进行数据testing的全新快照。 只需抓住一个prod容器备份并将其复制下来。 如果要截断旧数据或修剪某些表以使其易于pipe理，可以想象构build代理会启动连接到此备份的服务器容器并运行一些脚本或存储过程（您可能不希望这样做）您的prod容器出于安全原因）。
你甚至可以有一个最小的数据容器，它只有存根表模式，用于开发和testing。 您可以有一个单独的一体化容器，但是当您需要更新您的数据库版本时，您必须更新多个容器，而不是创build一个更新的/新的容器，并让它为您修改数据量。
将数据从实际的数据库软件本身解耦出来的最大好处是可以轻松地更新数据库软件。
使用数据库容器外部的数据，只需使用较新版本的软件构build新映像，删除旧数据库容器，然后启动新容器。 您不必担心导出和导入数据。 数据库映像本身是完全无状态的。
将数据保存在容器外部的另一个好处是，如果数据库的存储需求变大，则可以非常容易地转而使用主机卷而不是数据专用容器，而无需为所有容器重新configuration存储。
相比之下，如果您要将数据存储在数据库容器中，则升级path将是以下之一：
-
像容器一样对待容器。
login容器，执行某种程序包升级，然后重新启动数据库服务。 这种方式很有效，但不易维护，因为您的映像不再直接从Dockerfile生成：因为您已经做了手动更改，不再有一个清晰的自动化过程来将映像重build为相同的状态。
-
将数据复制到一个新的容器中。
这真的只是额外的工作。 这种模式的一个好处是它为您提供了一种机制，通过这种机制，您可以回滚到早期版本的数据库软件和早期版本的数据库内容。