我试图理解单独的数据卷容器的想法。在许多地方,我发现提倡这种做法是有益的(例如 in this question ),但是我认为使用单独的数据容器来实现简单的单一数据库堆栈没有任何意义。 我知道:
- 它解耦了我的数据库容器 - 但我为什么要这样呢?我不会更改数据库镜像,因为我不在这里开发数据库。
- 它允许我共享数据 - 但同样,我没有人可以共享它,只有一个容器使用它
- 它可以防止我意外删除容器 - 真的吗?它绝不比我的单一一体式容器更能防止删除
- 我可以轻松备份它 - 就像我可以备份我唯一的容器内的数据一样,对吗?
当数据以某种方式共享时,我清楚地看到这种方法在不同设置中的好处,但作为“容器作为数据库”问题的解决方案,这对我来说似乎只是额外的麻烦。
我错过了什么?
最佳答案
将数据与实际数据库软件本身解耦所获得的最大好处是,您可以轻松更新数据库软件。
对于数据库容器外部的数据,您可以简单地使用较新版本的软件构建新镜像,删除旧的数据库容器,然后启动新的数据库容器。您无需担心以某种方式导出和导入数据。数据库镜像本身是完全无状态的。
将数据保留在容器外部的另一个好处是,如果数据库的存储需求变得很大,您可以相当轻松地转而使用主机卷而不是仅数据容器,而无需重新配置存储所有容器。
相反,如果您将数据存储在数据库容器中,您的升级路径将是以下之一:
将容器视为虚拟机。
登录容器,执行某种包升级,然后重新启动数据库服务。这可行,但可维护性较差,因为您的镜像不再直接从 Dockerfile 生成:因为您进行了手动更改,所以不再有一个清晰的自动化过程将镜像重建到相同状态。
<将数据复制到新容器中。
这实际上只是额外的工作。此模型的一个好处是,它为您提供了一种机制,您可以通过该机制回滚到数据库软件的早期版本和数据库内容的早期版本。
里>
关于docker - 在Docker中使用Data Volume Container作为单数据库 "backend"有什么好处?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28969428/