开篇
今天，我听到一个建议，建议将postgresql 打到docker中进行部署。
如果有年度笑话，这条建议可以入选。
屎山分类下秉持谨慎入选的原则，本文将是第一篇。提这个建议的人，可以说既不懂数据库，对容器化部署也是一知半解。
那么为什么数据库不能放到容器里进行部署呢？
臣妾做不到的原因
1.数据的安全性无法保证
- Docker volumes 的设计围绕 Union FS 镜像层提供持久存储，但它仍然缺乏保证。
- 使用当前的存储驱动程序，Docker 仍然存在不可靠的风险。 如果容器崩溃并数据库未正确关闭，则可能会损坏数据。
- 事实上，docker的设计是为了方便计算类型的服务进行部署，对于存储服务，尤其是关系型数据库的事务而言，docker部署缺乏保证。
2. 数据库的环境需求不达标
- 数据库（特别是关系型数据库）对 IO 的要求较高。一般数据库引擎为了避免并发资源竞争而使用专用环境。
- 如果将你的数据库放在容器中，那么将浪费你的项目的资源。容器化至少将会损耗20%的性能，这个指标在数据库容器上还要被放大，需要更多的资源启动容器实例。
3. 网络问题
- 要理解 Docker 网络，您必须对网络虚拟化有深入的了解。也必须准备应付好意外情况。你可能需要在没有支持或没有额外工具的情况下，进行 bug 修复。
- 网络对于数据库复制是至关重要的，其中需要主从数据库间 24/7 的稳定连接
- 与其浪费时间在docker或者k8s虚拟网络间排查问题，不如把时间放在数据库本身上。
4. 状态
- 在 Docker 中打包无状态服务是很酷的，可以实现编排容器并解决单点故障问题
- 但是数据库明显是有状态服务，如果将数据库一同放入镜像，系统排障的范围将会更大，应用程序崩溃，连带影响数据库服务。
5. 数据库不适合使用主要的 Docker 功能
- 先来看看docker官方给自己下的定义:
Docker 是为开发人员和系统管理员构建，分发和运行分布式应用程序的开放平台。 Docker 包括 Docker Engine（便携式，轻量级运行时和打包工具）以及 Docker Hub（用于共享应用程序和自动化工作流的云服务），Docker 使应用程序能够以组件快速组装，并消除开发，QA 和生产环境之间的不同。 因此，IT 可以更快地分发程序，并在笔记本电脑，数据中心虚拟机和任何云上运行相同的应用程序。
非常遗憾的是，数据库部署没有一项可以用到上面提到的好处。
6. 额外的隔离对数据库是不利的
- 我们拥有的隔离级别越多，我们获得的资源开销就越多
- 相比专用环境而言，容易水平伸缩可以使我们得到更多的好处。这是容器化的好处
- 然而，在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。
- 我们没有看到任何针对数据库的隔离功能，那为什么我们应该把它放在容器中？你会把监听和数据计算，存储，分离吗？
最后提一句，凡事必称容器化，是一种病，这些人往往是神棍，而不是真的懂这项技术。