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