生产环境的数据库是否要跟项目一起放 docker 里，使用 docker-compose 一起管理？

[NeverBelieveMe]

我看很多开源的项目都是这么搞的。但是自己工作中遇到的情况都是数据库是单独部署在服务器中的，只有测试环境一类的会自己这么搞着玩。
想问一下这么做的优势和劣势分别是什么。

[lm930129]

开源项目这样搞是为了方便你启动开发环境。。。。生产环境可以用 docker ，但是大部分应该都不是开源项目的 docker-compose 那样写的，比如你启动的 MySQL ，密码一般不直接写在 docker-compose 里面。
总结下就是，可以用 docker 部署，一般和开发环境会有一定的区别。分开部署是为了避免一锅端。

[hidemyself]

数据库应该不放在 docker 里面吧

[NeverBelieveMe]

@hidemyself #2 我看了很多说数据库要不要放 docker 里面的文章，一开始也是这么觉得得，但是反对的声音越来越多，太坚定了。。。

[NeverBelieveMe]

@lm930129 #1 生产数据使用 docker 部署要注意哪些方面，方便说一下吗。

[NeverBelieveMe]

@NeverBelieveMe #3 上面打错了，最后是不太坚定了

[lm930129]

我觉得是可以的，但是我不是专业的 dba ，其实不太有发言权。我觉得可能看项目规模吧，不大的也没啥影响。说是可能会有点性能问题吧。我经历的一些中小型项目，都是直接 docker 的，但是这个不能说明用 docker 就真没有问题。

[yinmin]

数据库放容器里，要把配置文件和数据库文件都放宿主机上，做到容器无状态，可以做到任意摧毁/重建容器。对于容器的 cpu 和内存限制，数据库配置文件限制和 docker 限制要内外匹配。

[yinmin]

另外，数据库应该是单独的 compose 管理，要和应用的 compose 分开。

[anubu]

不要被生产环境四个字迷惑了，不同公司的生产环境的差异很大。没什么负载的项目，是用 Docker 跑数据库，做好数据持久化和备份，一般也没什么问题。重负载的项目，整个 DBA 团队恨不得调优再调优，你让他们再套一层容器也不太现实，除非真的有什么运维管理上的特别收益。

[cexll]

我们都知道虚拟化，容器化 会损耗一定性能，但是容器相比前者损耗很小，但是在 io 处理上，你将数据库的文件映射到本地，其中的映射 io 消耗自己需要测试一下到底大不大，其二就是数据安全隔离，容器大多数都是运行无状态的服务，容器更新 回滚 不用担心自己还有挂载了一个数据在本地 导致数据错乱的问题

[Worldispow]

docker 跑 mysql 启动很简单，但调优什么的就很麻烦，有时调到一半甚至发现原来的 docker 封装方式有问题，不支持某个参数调整，还需要重新写 dockerfile 。。。。

[shimc]

生产环境的话，我们公司目前都是 docker 容器无状态，集群中随便一台机器都可以启动。 数据库单独部署，或者云服务商的

[me1onsoda]

我认为，数据库玩意就应该单独部一台，很多 io 型应用比如 es, kafka ，数据库，一台宿主机一锅炖，就是互相拖累

[chendy]

看场景看需求，如果对性能不敏感，对稳定性不敏感，虽然怎么整都行
容器化的好处是快速部署动态扩缩，数据库对这个特性要求不是很高
反倒是数据库对 IO 和内存有要求，和应用放一起互相抢资源抢的不亦乐乎…

[MeteorCat]

没见过 MySQL 放 docker ，正式应该都是买单独部署云服务吧

[kkanwo]

小项目与测试可 docker ，其它则 RDS 或者物理机。

[ZeroDu]

mysql 放到 docker 里面，数据挂载出来。之前遇到过，移动目录后跑不起来了的情况

[billzhuang]

“ 很多开源的项目都是这么搞”，能否举几个例子

[eDeeraiD0thei6Oh]

我的生产环境就是 这样。唯一不满意的地方就是 DB 数据大，想换机器麻烦。不过一部分在 aws 上的没问题

[studyrun]

数据库基本都是单独的机器，上云基本都是买的服务商的数据库实例，主从分离和扩容直接给你弄好了。测试环境是不是 docker 无所谓，docker 升级数据库版本更方便，但绝不是 docker-compose 管理。开源的项目这么搞是为了方便一键部署，不是非得用他提供的 docker-compose.yml ，完全可以自己修改