问题描述
有关Docker运行数据库的讨论一直存在争议。其中一个观点是，可以将数据库软件放在Docker容器中，并将数据作为卷（bind volume）挂载。另一个观点是，应该只将Docker用于无状态应用程序，如微服务和AWS Lambda风格的应用。本问题的背后问题是：数据库是否适用于“Cattle”理念（将服务器视为可替换的资源，而非特定的个体）？
解决方案
Docker在数据库领域的使用一直存在争议。一些人认为将数据库放入Docker容器中是一种好做法，而另一些人则持相反观点。以下是关于在Docker中不应该用于数据库的几个原因。
容器化数据库的挑战
虽然可以将数据库软件放入Docker容器中，但是容器化数据库仍然存在一些挑战：
数据持久性和容器生命周期不匹配： 容器是短暂的，它们可以随时启动、停止和删除。这与数据库需要长时间稳定运行的特性不符。当容器停止或删除时，容器中的数据也会丢失，这对数据库是不可接受的。
数据一致性问题： 在容器中运行的数据库面临数据一致性和持久性的问题。即使使用卷挂载数据，也无法完全保证数据的一致性和完整性。例如，在容器崩溃或重新启动时，可能会导致数据损坏或不一致。
性能和资源隔离： 数据库通常需要专用的资源和性能保障，以确保其正常运行。容器化数据库可能会受到性能限制，因为容器共享主机的资源。
复杂性和支持问题： 在生产环境中，许多数据库提供商可能不支持将其数据库产品直接部署在Docker容器中。这意味着如果出现问题，可能无法得到官方支持。另外，容器化数据库可能增加运维的复杂性，需要更多的管理和监控。
数据库容器化的适用场景
虽然存在上述挑战，但在某些情况下，将数据库放入Docker容器中仍然是可行的：
开发和测试环境： 在开发和测试环境中，容器化数据库可以带来便利。开发人员可以轻松地在不同的开发环境中部署相同版本的数据库。
临时性任务： 如果只需要临时性的数据库，容器化可能是一个快速启动、使用完即丢弃的选择。
轻量级应用： 对于轻量级的应用，容器化数据库可能是一个简单的解决方案，前提是不需要高度的性能和数据稳定性。
学习和实验： 对于学习和实验目的，容器化数据库可以帮助快速构建环境。
其他注意事项
如果决定将数据库容器化，以下注意事项需要考虑：
数据备份和恢复： 确保有可靠的数据备份和恢复策略，以防止数据丢失。
容器管理： 了解如何管理容器的生命周期，包括启动、停止和监控。
资源和性能： 针对数据库容器，配置适当的资源限制和性能参数，以确保稳定运行。
支持和维护： 确保了解数据库提供商对容器化部署的支持政策，以及如何解决可能出现的问题。
最佳实践
对于生产环境中的重要数据库，容器化可能并不是最佳选择。最好的做法是使用专门设计的解决方案，如云提供商提供的托管数据库服务。这些服务通常具有高可用性、备份恢复和性能保障等特性，适用于生产工作负载。
参考链接
- Databases in Containers: What, Why, and How
- Is there evidence to suggest that the Docker/HashiCorp ecosystem requires a high level of DevOps maturity to avoid chaos?
- Measuring Docker IO overhead
- What is the runtime performance cost of a Docker container
总结
将数据库放入Docker容器中可能存在一些挑战，特别是在生产环境中。数据持久性、一致性、性能和支持问题是需要考虑的重要因素。在某些情况下，如开发、测试和临时任务，容器化数据库可能是一个方便的解决方案。最佳实践是根据具体需求选择合适的部署方式，对于生产关键的数据库，建议使用专门的数据库解决方案或托管服务。