这个问题类似于：
Setting up MySQL and importing dump within Dockerfile
但是这个问题的答案并没有解决我的用例。
我有一个MySQL数据库，在生产中有5TB的数据。对于Dev，我只需要大约500MB的数据。作为构建应用程序的一部分运行的集成测试需要访问MySQL DB。目前，正在Jenkins上创建数据库，并且构建过程正在将数据注入其中。这很慢。
我想用Docker替换这个过程的这一部分。我的想法是，我将拥有一个运行MySQL的Docker容器，并且已经将500MB数据放入容器中，而不是依赖于与容器启动时仅执行MySQL导入的MySQL Docker映像关联的标准进程。根据迄今为止的测试，标准过程需要4-5分钟，我希望将其缩短到几秒钟。
我原本以为这是一个常见的用例，但MySQL Docker容器中的预烘焙数据似乎不受欢迎，并且实际上没有任何指导。这种方法。
有没有人在这方面有任何经验？有没有一个很好的理由为什么不应该将数据预先烘焙到MySQL Docker容器中？
答案 0 :(得分：8)
根据我对此进行的调查，实际上不可能将数据包含在使用标准MySQL映像作为其基础的容器中。
我尝试通过从此基础部署容器并对其进行操作来解决此问题，然后再提交新映像。
然而，关于MySQL基本映像有一个关键的事情要理解。它的数据目录（/ var / lib / mysql /）和config目录（/ etc / mysql /）都设置为Docker卷，这意味着它们的内容映射到主机系统上的位置。
这些卷不会保存为提交的一部分，因此您无法操作和保存。此外，该图像具有阻止使用ENTRYPOINT例程操纵这些位置的功能。
所有这些都是设计的，因为设想该图像与持久或独立的数据集一起使用。如果有一个选项可以将数据包含在容器中，那将是很好的，但这看起来像开发人员真的不想娱乐。
要解决我的问题，我想回到基础Ubuntu映像，在其上构建我的数据库，并将其提交到新映像，这可以正常工作。容器大小稍微大一点，但作为构建作业的一部分，部署比等待基于MySQL的容器在启动时运行500MB导入要快得多。
答案 1 :(得分：1)
反对这一点的主要论点是，您的图像是某个时间点的数据和架构的快照 - 它会很快变得陈旧，并且您需要一个良好的流程来生成包含新数据的新图像很容易，使其有用而不需要昂贵的维护。
那就是说，我不会对此感到沮丧 - 我认为这对于非生产Docker镜像来说是一个特别好的用例。移动500MB图像非常便宜，因此您可以拥有大量图像 - 针对数据库模式的不同版本的标记版本，甚至包含针对不同测试场景的不同数据集的多个图像。
预加载的数据库容器应该在几秒钟内启动，因此您可以在运行集成测试之前轻松地将相关容器作为构建管道中的一个步骤运行。请注意维护开销 - 我会从一开始就考虑从实时，清理，收缩和打包中自动化数据提取。