我正在尝试掌握单独的数据卷容器的想法.在很多地方,我发现被主张是有益的(例如in this question),但是对于简单的一个数据库堆栈,使用单独的数据容器并没有任何意义.
我知道：
>它解耦了我的数据库容器-但是我为什么要那样？我不会更改数据库映像,因为我不在这里开发数据库.
>它允许我共享数据-但同样,我没有人可以共享数据,只有一个容器可以使用它
>它可以防止我意外删除一个容器-确实吗？我的单个多合一容器绝对无法防止删除
>我可以轻松备份它-就像可以备份我唯一的容器中的数据一样,对吗？
当以某种方式共享数据时,我清楚地看到了这种方法在不同设置中的好处,但是作为“容器作为数据库”问题的解决方案,对我而言似乎只是另外的麻烦.
我想念什么？
- it decouples my database container – but why would I want that? I won’t change database image,as I’m not developing a database here.
- it prevents me from accidentally deleting a container – does it really? It’s in no way more protected from deletion that my single all-in-one container is
说您或下一个维护此系统的家伙,稍后再出现,并希望升级您的postgres版本(或任何sql堆栈).您决定为新版本的新docker容器/映像创建新的docker容器/映像,将其分层放置在旧容器/映像之上会更容易.如果您的单个Docker容器上既有数据又有软件,则没有该选项.当然,您仍然可以搞乱数据量,但是不能通过解耦的服务器容器搞乱数据.
- it allows me to share the data – but again,I have nobody to share it with,just one container using it
您可能现在不共享它；您可能永远也没有人可以分享.但这并不意味着您就不想在系统,应用程序,服务器等之间共享它.
- I can easily back it up – just like I can back up the data inside my only container,right?
可以,但是,如果要备份整个容器,则每次都在备份软件和数据,这是不必要的.如果要将数据从容器中转储出来,那么您实际上并没有考虑使用容器.
我看到具有分离的数据量的一个明显优势是在环境之间移动数据.假设您想要一个新的数据快照以在舞台环境中进行测试.只需获取产品容器备份并将其复制下来即可.如果您想截断旧数据或整理某些表以使其易于管理,可以很容易地想到一个构建代理程序启动一个连接到该备份的服务器容器并运行一些脚本或存储过程(您可能不想在其中使用您的产品容器出于安全原因).
您甚至可以拥有一个最小的数据容器,该容器上仅具有用于开发和测试的存根表架构.您可以为此使用一个单独的多合一容器,但是当您需要更新数据库版本时,必须更新多个容器,而不是创建一个已更新/新的容器并让它为您修改数据量.
