为什么没有人不在码头工作？ （一体化容器/＆＃34;黑匣子＆＃34;）

Question

我需要很多各种Web应用程序和微服务。

此外，我需要轻松备份/恢复并在服务器/云提供商之间移动。

我开始研究Docker。当我看到这样的建议时，我感到很尴尬：＆＃34;为您的应用创建第一个容器，为您的数据库创建第二个容器并将它们链接在一起＆＃34;。

但为什么我需要为数据库做单独的容器？如果我理解正确，主要消息就是docker：＆＃34;允许运行并移动所有这些依赖项的应用程序环境＆＃34 ;.也就是说，据我所知，放置在容器应用程序及其所有依赖项中是合适的（特别是如果它是一个小应用程序而不需要外部数据库）。

在我的案例中，我如何看待使用Docker的最佳方式：

1. 采用baseimage（例如phusion / baseimage）

2. 基于此构建我自己的图像（使用nginx，数据库和 应用程序代码）。

3. 公开端口以便与我的应用程序进行交互。

4. 在目标服务器上创建基于此图像的数据量（用于商店应用程序数据，数据库，上传等）或从普通备份恢复数据量。

5. 运行此容器并享受乐趣。

优点：

1. 易于备份/恢复/移动应用程序。 （仅移动数据卷，只需在新服务器/环境中启动它。）
2. 应用程序是＆＃34;黑匣子＆＃34;，没有令人头痛的外部依赖。
3. 如果我需要将数据存储在外部数据库中或使用数据形式 - 没有什么能阻止我这样做（但通常不需要）。我更喜欢使用其他黑盒子的API而不是直接访问他们的数据库。
4. 与所有容器的单个数据库相比，具有很多隔离和安全性。

缺点：

1. 更多地消耗RAM和磁盘空间。
2. 有点难以扩展。 （如果我需要多个应用程序实例来响应每秒数千个请求 - 我可以将数据库移动到单独的容器中并链接其上的几个应用程序实例。但在极少数情况下需要它）

为什么我没有找到使用这种方法的建议？它有什么问题？我还没有看到什么陷阱？

Answer 1

首先，你需要了解一个Docker容器不是一个虚拟机，只是一个包含内核功能chroot，cgroups和名称空间的包装器，使用分层文件系统，具有自己的包装格式。虚拟机通常是一个重量级的有状态工件，具有与主机上可用资源相关的大量配置选项，您可以在VM中设置复杂的环境。

容器是一个轻量级，可抛出的运行时环境，建议尽可能使其无状态。所有更改都存储在容器中，该容器只是图像的运行实例，如果容器被删除，您将丢失所有差异。当然，您可以映射卷以获取更多静态数据，但这也适用于多容器体系结构。

如果将所有东西装入一个容器中，则会失去相互独立地扩展组件的能力，并形成紧密耦合。

通过紧密耦合，您无法在应用配置中实现故障转移，冗余和可扩展性功能。最现代的nosql数据库是为了轻松扩展而构建的，当您运行多个后备数据库实例时，数据冗余也是可能的。

另一方面，使用docker-compose定义这个单一负责的容器很容易，你可以在一个简单的yml文件中声明它们。