在 MySQL Docker 容器中包含数据

Question

这个问题类似于：

Setting up MySQL and importing dump within Dockerfile

但该问题的答案并没有解决我的用例。

我有一个 MySQL 数据库，其中包含 5TB 的生产数据。对于开发，我只需要大约 500MB 的数据。作为我的应用程序构建的一部分运行的集成测试需要访问 MySQL 数据库。目前，该数据库正在 Jenkins 上创建，并且数据正在通过构建过程注入其中。这很慢。

我想用 Docker 替换这个过程的这一部分。我的想法是，我将拥有一个运行 MySQL 的 Docker 容器，并且已经将我的 500MB 数据烘焙到容器中，而不是依赖与 MySQL Docker 映像相关联的标准流程，即仅在容器启动时执行 MySQL 导入。根据迄今为止的测试，标准过程需要 4 到 5 分钟，而我希望将其缩短到几秒钟。

我原以为这是一个常见的用例，但 MySQL Docker 容器中的预烘焙数据似乎不受欢迎，并且没有关于此方法的任何指导。

有没有人有这方面的经验？是否有充分的理由不应该将数据预烘焙到 MySQL Docker 容器中？

Answer 1

根据我对此进行的调查，实际上不可能将数据包含在使用标准 MySQL 映像作为其基础的容器中。

我试图通过从这个基础部署一个容器并对其进行操作来解决这个问题，然后再提交一个新图像。

但是，关于 MySQL 基础映像，有一个关键点需要了解。它的数据目录 (/var/lib/mysql/) 和配置目录 (/etc/mysql/) 都设置为 Docker 卷，这意味着它们的内容映射到主机系统上的位置。

像这样的卷不会保存为提交的一部分，因此您无法操作和保存。此外，图像具有防止使用 ENTRYPOINT 例程对这些位置进行操作的功能。

所有这些都是设计使然，因为设想此图像可用于持久或独立数据集。如果有一个选项可以将数据包含在容器中，那就太好了，但这看起来开发人员真的不想接受。

为了解决我的问题，我想回到一个基本的 Ubuntu 映像，在其上构建我的数据库，并将其提交给一个新的映像，它工作正常。容器大小有点大，但作为我们构建作业的一部分进行部署比等待基于 MySQL 的容器在启动时运行 500MB 导入要快得多。

Answer 2

反对这一点的主要论据是，您的图像是某个时间点的数据和架构的快照 - 它会很快变得陈旧，您需要一个良好的流程来轻松地使用新数据生成新图像，使其有用且维护成本不高。

也就是说，我不会对此皱眉 - 我认为这是一个非生产 Docker 映像的特别好的用例。一个 500MB 的图像移动起来非常便宜，因此您可以拥有很多它们 - 为不同版本的数据库架构标记的版本，甚至是用于不同测试场景的具有不同数据集的多个图像。

预加载的数据库容器应在几秒钟内启动，因此您可以在运行集成测试之前轻松运行相关容器作为构建管道中的一个步骤。请注意维护开销 - 我会从一开始就考虑从实时、清理、收缩和打包中自动提取数据。