Docker/DB-在主机和DB容器之间设置共享目录不是更好吗?
#database #mysql #docker #db

开发后,我在应用程序维护期间提出了一个想法。

“在主机和DB容器之间共享目录不是更好吗?”

例如:

docker-compose.yml

  mysql:
    image: mysql:8.0.29
    container_name: mysql
    environment:
      MYSQL_DATABASE: myapp01
      MYSQL_USER: user
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: password
    ports:
      - "3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql
      - ./shared_db:/shared_db  # set share directory between host and db container

原因是在午餐后,使从生产环境中的本地环境中导入转储文件。

例如,有很多情况您想用与生产相同的环境数据测试,因为该错误不能在本地环境中复制,而是在特定的情况下重现。

在这种情况下,您必须导入已从生产环境或定期批次导出的转储文件。

但是,有时此任务可能非常烦人和复杂。

最近,通常允许用户使用多种操作系统,例如Mac,Windows或Linux而不指定开发机器进行开发。
此外,像Docker这样的虚拟机技术可以帮助我们实现它。

在这种情况下,要在容器(mySQL,postgressql或其他db)中执行导入命令,有必要将转储文件存储在可以从容器中引用的地方。

(可能有更好的方法在主机中指定转储文件,我找不到它。)

如果您在主机和容器之间共享文件,则需要准备一些协议或使用两者都可以参考的共享存储。

其他方法是在主机中执行导入命令,但是主机中的Shell会使您发疯。

尤其是,Powershell在许多方面都很特别。例如,您不能使用字符“ <”,因为它是保留的单词。
因此,您可以找到避免此问题的方法。
(当我解决问题时,有必要将文件存储在容器中以引用。这是浪费时间。)

其他方法是使用DB客户端应用程序,例如MySQL Workbench。但是,每个操作系统都有差异,即使在同一应用中,操作也有所不同。然后,与您的团队分享此信息很烦人。

从一开始,甚至认为我们正在使用诸如Docker之类的虚拟化软件,使我们忽略每个开发人员的主机环境,这不是根据每个开发人员的OS进行不同操作的有效方法。

另外,如果您成功执行导入命令,则在与角色代码有关的错误中挣扎之后。

我写了有关研究的文章,包括失败的例子。

MySQL/Windows/Docker - How to import a dump file to MySQL container

清晰的解决方案是 “设置主机和DB容器之间的共享目录” 我在开始时建议。

这使您的解释清晰,并在您需要教开发人员如何在本地环境中导入转储文件时短。
您只能告诉他们“将文件存储在DB容器和主机之间的共享目录中,并从容器内部执行导入命令。”

我相信这是最好的方法。它不会受到外壳差异或主机OS的影响。

此外,无论开发人员有多少编辑docker-compose.yml,它只会影响其本地环境。
它可以解决,而不会对生产或分期环境产生任何负面影响。

但是,我从未见过有人要求像我这样的东西,如果我将上述设置放在docker-compose.yml中,我会被问到:“这是什么用途?” ,
因此,我决定将其发布在此博客上,因为我想解释它是如何有用的以及当我不包括这些设置时遇到的问题。