Docker容器内的数据库引擎是否会复用主机端的对应数据库？以MongoDB为例

默认配置下，Docker容器内部署的数据库引擎不会主动调用、复用主机侧已安装的同类型数据库服务。以容器内运行MongoDB的场景为例，默认状态下容器会运行完全独立的专属MongoDB实例，和主机侧的MongoDB实例处于完全隔离状态，不存在自动建立通信、复用主机服务能力的逻辑。

默认隔离的核心底层逻辑 #

• 文件系统层面隔离
  Docker默认使用联合文件系统实现容器的文件空间隔离，容器内运行的MongoDB程序二进制、配置文件、数据存储路径，全部打包在容器镜像内部，运行时读写的是容器专属的可读写存储层，既不会主动读取主机路径下安装的MongoDB程序文件，也不会默认访问主机上MongoDB实例存储的数据目录，从程序加载、数据存储的根源上就没有复用主机服务的基础。
• 网络层面隔离
  Docker默认采用bridge桥接网络模式，每个容器拥有独立的网络命名空间，和主机的网络栈完全分离。主机侧运行的MongoDB实例默认绑定在主机网卡的27017端口上，容器在没有特殊网络配置的前提下，根本感知不到主机上这个服务的存在，自然不可能主动发起连接、调用主机实例的服务能力。

容易产生“复用错觉”的特殊配置场景 #

很多时候大家误以为容器复用了主机的数据库能力，本质是手动修改了Docker的默认隔离规则，这些配置都不是容器运行的默认行为：

• 若启动容器时指定--network host网络参数，容器会直接共享主机的网络命名空间，这时候容器内的进程可以直接通过localhost:27017访问到主机上运行的MongoDB实例，但这只是打通了网络通路，不代表容器内运行的MongoDB服务本身复用了主机的能力——容器内的MongoDB进程如果正常启动，依然是独立运行的实例，只是你可以选择连接主机的实例而已。
• 若启动容器时手动把主机上MongoDB的数据目录，挂载到容器内MongoDB对应的默认数据路径下，会出现容器和主机实例读写同一份物理文件的情况，但这是人为配置的目录映射结果，并非Docker的自动复用逻辑，甚至这种操作很容易因为MongoDB的文件锁机制出现双实例争抢数据的故障，生产环境一般不会采用。
• 如果你尝试把容器内MongoDB的27017端口映射到主机的27017端口，而主机上已经运行了一个监听该端口的MongoDB实例，Docker会直接抛出端口占用的错误，容器根本无法正常启动，更不存在所谓的服务复用。

MongoDB具体部署的实际表现 #

使用官方MongoDB镜像正常启动容器的流程中，镜像自带的MongoDB程序和主机环境完全解耦：哪怕主机上根本没有安装任何MongoDB相关程序，容器内的MongoDB依然可以正常初始化、提供服务；同理，容器销毁、删除的操作，也不会对主机上独立运行的MongoDB实例、存储的数据产生任何影响。

内容的提问来源于stack exchange，提问作者Jonggyu Park