为什么没有人在docker工作？ （一体化容器/“黑匣子”）
我需要很多不同的Web应用程序和微服务。
此外，我需要做简单的备份/恢复，并在服务器/云提供商之间移动。
我开始为此研究Docker。 当我看到这样的build议时，我感到尴尬：“为您的应用程序创build第一个容器，为您的数据库创build第二个容器，并将它们连接在一起”。
但是，为什么我需要做独立的数据库容器？ 如果我理解正确，主要的信息是docker：“允许在孤立的环境中运行和移动具有所有这些依赖的应用程序”。 也就是说，据我所知，放置在容器应用程序及其所有的依赖关系（特别是如果它是一个小的应用程序没有要求有外部数据库）是适当的。
我如何看待在我的情况下使用Docker的最佳方式：
-
采取基本图像（例如phusion / baseimage）
-
基于这个（使用nginx，数据库和应用程序代码）构build我自己的图像。
-
公开与我的应用程序交互的端口。
-
在目标服务器上创build基于此映像的数据卷（用于存储应用程序数据，数据库，上载等）或从预备备份恢复数据卷。
-
运行这个容器，玩得开心。
优点：
- 易于备份/恢复/移动应用程序。 （仅移动数据卷，只需在新的服务器/环境中启动它）。
- 应用程序是“黑匣子”，没有头痛的外部依赖。
- 如果我需要将数据存储在外部数据库或使用数据forms – 没有任何东西阻止我这样做（但通常是不必要的）。 我更喜欢使用其他黑匣子的API来直接访问他们的数据库。
- 与所有容器的单个数据库的情况相比，隔离性和安全性更高。
缺点：
- 更大的RAM和磁盘空间消耗。
- 有点难以扩展。 （如果我需要每秒数千个请求的应用程序的几个实例 – 我可以将数据库移动到单独的容器中，并链接多个应用程序实例，但在极less数情况下需要）
为什么我找不到使用这种方法的build议？ 它出什么问题了？ 有什么我没有看到的陷阱？
首先，你需要理解一个Docker容器不是一个虚拟机，只是一个使用分层文件系统的内核包装chroot，cgroups和命名空间的包装，并且有自己的打包格式。 虚拟机通常是一个重量级的有状态的工件，具有关于主机上可用资源的广泛configuration选项，您可以在虚拟机内设置复杂的环境。
一个容器是一个轻量级的可抛出的运行时环境，build议尽可能使其处于无状态。 所有更改都将存储在只是图像正在运行的实例的容器中，并且在容器删除的情况下您将丢失所有差异。 当然，您可以将卷映射到更多的静态数据，但也可用于多容器体系结构。
如果将所有东西都打包到一个容器中，则无法相互独立地缩放组件，从而形成紧密的耦合。
有了这个紧密的耦合，你不能在你的应用configuration中实现故障转移，冗余和可伸缩性function。 最现代化的nosql数据库可以轻松扩展，而且当运行多个后备数据库实例时，数据冗余也是可能的。
另一方面，使用docker-compose来定义这个单一负责任的容器是很容易的，在这里你可以在一个简单的yml文件中声明它们。