在docker中，在容器之间共享数据库，有哪些最佳实践？
在docker中，在容器之间共享数据库，有哪些最佳实践？
有谁知道Docker中共享数据库的最佳实践吗？
我的意思是我想在Docker中创建多个容器。然后，这些容器将使用相同的身份对同一个数据库执行CRUD操作。
到目前为止，我有两个想法。一个是创建一个单独的容器仅用于运行数据库。另一个是直接在安装了Docker的主机上安装数据库。
哪个更好？或者，还有其他最佳实践满足此要求吗？
谢谢
admin 更改状态以发布 2023年5月22日
很难回答“最佳实践”的问题，因为这是一个观点问题。而且在Stack Overflow上，观点是不适合讨论的。
因此，我将举一个具体的例子，说明我在一个严肃的部署中所做的事情。
我正在运行ELK（Elasticsearch、Logstash、Kibana）。它是容器化的。
对于我的数据存储，我有存储容器。这些存储容器包含本地文件系统传递：
docker create -v /elasticsearch_data:/elasticsearch_data --name ${HOST}-es-data base_image /bin/true
我还在使用etcd和confd，动态重新配置指向数据库的服务。etcd让我存储键值，所以在简单的级别上：
CONTAINER_ID=`docker run -d --volumes-from ${HOST}-es-data elasticsearch-thing`
ES_IP=`docker inspect $CONTAINER_ID | jq -r .[0].NetworkSettings.Networks.dockernet.IPAddress`
etcdctl set /mynet/elasticsearch/${HOST}-es-0
因为我们在etcd中注册它，所以我们可以使用confd来监视键值存储库，监视它的变化，并重新编写和重启其他容器服务。
有时我会使用haproxy，需要一些更复杂的时候我会使用nginx。这两者都可以指定要“发送”流量的主机集，并具有一些基本的可用性/负载平衡机制。
这意味着我可以非常懒惰地重新启动/移动/添加elasticsearch节点，因为注册过程会更新整个环境。类似于这样的机制是openshift所使用的。
因此，为了明确回答你的问题：
- DB被打包在容器中，原因与其他元素相同。
- DB存储的卷是通过本地文件系统传递的存储容器。
- 通过
etcd在父主机上“找到”数据库，但其他方面我尽量减少了安装占用的空间。（我有一个通用的“安装”模板，用于docker主机，并尽可能避免添加其他任何东西）
我认为如果你依赖于本地主机具有（特定的）数据库实例，那么docker的优势将大大减弱，因为你将不再能够进行打包测试部署，或在几分钟内“启动”新系统。
（上述示例-我在十分钟内重新构建了整个系统，其中大部分是docker pull传输镜像）