生产中的 Docker Volumes - 以 Wordpress 为例

问题描述

这个问题不一定是针对 wordpress 的,但我认为这是理解生产网站中概念的一个很好的例子。

我正在尝试了解在生产中使用 Docker Volumes 的正确方法。 我将讨论 3 个方面以了解最佳做法和最佳性能(如果可能)。

数据库
如果我为数据库创建一个命名卷,我可以公开一个端口来访问数据库。这将为我自己提供最佳的性能和便利。为了安全起见,我将端口更改为 127.0.0.1:xxxx 以使其无法从服务器外部访问。

wp-content/主题
我将管理这个目录,我对网站所做的任何更改都将来自我的子主题。 如果我将它存储在一个卷中,我很难上传更改,但大多数指南建议不要在生产环境中使用绑定安装。

wp-内容/上传
这是一个完全由 Web 服务器管理的目录。如果我对整个 Web 服务器文件系统使用一个卷,那么上传新卷将覆盖上传目录,并且我将丢失 Web 服务器所做的任何更改。

正如我所说,这不是 Worpdress 特有的,任何 CMS 系统都可以用作示例。主要问题是,当您有要管理的目录和 Web 服务器应该管理的目录时,如何在生产中处理 Docker?

解决方法

我认为您在这里忽略了要点:容器本质上是短暂的。 任何应该在容器中存活的数据都应该在一个卷中,而不管应用程序的使用情况或管理职责(无论是服务器还是系统管理员)。

在您带来的示例中,上传和主题(或与此相关的整个 wp 内容)应该是卷,提供它们的人也应该填充它们的内容,无论是通过使用第二个容器或简单地在容器启动之前将数据复制到卷。

至于数据库,容器无需绑定到主机网络即可使用。他们可以加入一个私有网络并将彼此之间的所有通信保持在那里,而无需暴露(这可以像将其绑定到 127.0.0.1 一样安全)。有关更多信息,请查看 docker network docs 和一些编排工具(docker-compose、kubernetes 等)。

tl;dr 尽可能多地使用卷,以保持容器之间的非临时数据处于活动状态。它们是您保持数据完整的唯一工具,以防您的容器消失。