使用Data Volume Container作为单一数据库"后端"在Docker?

时间:2015-03-10 16:45:56

标签: docker

我试图掌握单独的数据卷容器的想法。在很多地方我发现被提倡是有益的(比如in this question),但是我没有看到使用单独的数据容器用于简单的一个数据库堆栈的任何意义。 我知道:

  • 它解耦了我的数据库容器 - 但为什么我要这样呢?我不会改变数据库图像,因为我没有在这里开发数据库。
  • 它允许我分享数据 - 但同样,我没有人与之分享,只有一个容器使用它
  • 它可以防止我意外地删除一个容器 - 它真的吗?我的单一多功能一体容器无法更好地防止删除
  • 我可以轻松备份它 - 就像我可以在我唯一的容器中备份数据一样,对吗?

我清楚地看到这种方法在不同设置中的好处,当数据以某种方式共享时,但作为解决容器作为数据库的问题"对我来说似乎只是另外一件事。

我错过了什么?

2 个答案:

答案 0 :(得分:3)

将数据与实际数据库软件本身分离所带来的巨大好处是,您可以轻松更新数据库软件。

使用数据库容器外部的数据,您只需使用较新版本的软件构建新映像,删除旧数据库容器,然后启动新数据库容器。您无需担心以某种方式导出和导入数据。数据库图像本身是完全无状态的。

将数据保存在容器外部的另一个好处是,如果数据库的存储需求变大,您可以相当轻松地转移到使用主机卷而不是仅数据容器而无需为所有你的容器。

相反,如果要将数据存储在数据库容器中,则升级路径将是以下之一:

  • 像vm一样对待容器。

    登录容器,执行某种程序包升级,然后重新启动数据库服务。这样可以工作,但不太可维护,因为您的图像不再直接从Dockerfile生成:因为您已经进行了手动更改,所以不再需要一个清晰的自动化过程来将图像重建为相同的状态。

  • 将您的数据复制到新容器中。

    这实际上只是额外的工作。此模型的一个好处是它为您提供了一种机制,通过该机制,您可以回滚到早期版本的数据库软件早期版本的数据库内容。

    < / LI>

答案 1 :(得分:0)

我仍然处于Docker开发的边缘,所以这只是从我读过/听到的内容中猜测出来的。无序地回应你的观点:

  
      
  • 它解耦了我的数据库容器 - 但为什么我要这样呢?我不会更改数据库图像,因为我这里没有开发数据库。
  •   
  • 它可以防止我意外删除容器 - 真的吗?我的单一多功能一体容器
  • 绝不会被删除   

说你,或者下一个维护这个系统的人,稍后会来,想要升级你的postgres版本(或者你的SQL堆栈)。您决定为新版本启用新的docker容器/图像会更容易,而新版本将其置于旧版本之上。如果您的单个docker容器上同时包含数据和软件,则表示您没有该选项。当然,你仍然可以搞砸你的数据量,但你不能通过解密的服务器容器搞砸数据。

  
      
  • 它允许我分享数据 - 但同样,我没有人与之分享,只有一个容器使用它
  •   

您现在可能不会分享它;你可能没有任何人可以与之分享。但这并不意味着您不希望在系统,应用程序,服务器等之间共享它。

  
      
  • 我可以轻松备份它 - 就像我可以在我唯一的容器中备份数据一样,对吗?
  •   

当然,但是如果你要备份整个容器,那么每次都要备份软件和数据,这是不必要的。如果你要从容器中转储数据,那么你并不是真的想用容器。

我认为拥有解耦数据量的一个明显优势是在环境之间移动数据。假设您需要一个全新的数据快照,以便在舞台环境中进行测试。只需抓住prod容器备份并将其复制下来。如果要截断旧数据或修剪某些表以使其易于管理,可以很容易地想象构建代理启动连接到此备份的服务器容器并运行某些脚本或存储过程(您可能不希望这样做)出于安全原因你的prod容器。)

你甚至可以拥有一个最小的数据容器,它只有你用于开发和测试的存根表模式。您可以拥有一个单独的一体化容器,但是当您需要更新数据库版本时,您必须更新多个容器,而不是制作一个更新的/新容器并让它为您修改数据量。 / p>