Docker中容器之间共享数据库的最佳实践是什么？

Question

有没有人知道Docker中容器之间共享数据库的最佳实践是什么？

我的意思是我想在Docker中创建多个容器。然后，这些容器将以相同的身份在相同的数据库上执行CRUD。

到目前为止，我有两个想法。一种是创建一个单独的容器来运行数据库。另一种方法是直接在安装Docker的主机上安装数据库。

Answer 1

很难回答一个“最佳实践”的问题，因为这是一个意见问题。而对堆栈溢出的看法也偏离了主题。

所以我将给出一个具体的例子，说明我在一个严肃的部署中所做的事情。

我正在运行ELK（Elasticsearch,Logstash,Kibana）。集装箱装的。

docker create -v /elasticsearch_data:/elasticsearch_data --name ${HOST}-es-data base_image /bin/true

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的优势就会大大减弱，因为您不再能够在几分钟内打包、测试、部署或“旋转”一个新系统。

（上面的示例--我在10分钟内重建了整个系统，其中大部分是Docker Pull传输图像）