Docker 无疑是过去十年中最具影响力的开发人员技术之一。容器为隔离应用程序、跨物理机扩展它们以及抽象环境之间的差异提供了一种解决方案。

许多采用 Docker 或相邻容器化技术的组织发现它提高了效率并加速了开发过程。不过，Docker 并不能神奇地改进每个系统。在本文中，我们将研究迁移到容器的一些场景，这些场景可能更多的是障碍而不是帮助。

当性能至关重要时

对于性能至关重要的系统，Docker 可能不是最佳选择。容器化的本质产生了在软件直接安装到主机上时不存在的开销。

当然，Docker 也可以帮助提高性能，特别是通过使水平扩展应用程序更容易。因此，重要的是要根据系统要求及其与底层操作系统的交互来做出此判断。

Docker 将使用比 VM 少得多的资源，但它仍然是另一个必须在主机上运行的进程。在资源受限的环境中，您可能会发现容器进程或 Docker 守护程序本身是 OS 内存不足杀手的目标，导致应用程序的各个部分被驱逐时出现级联故障。

大量持久数据

默认情况下，Docker 容器被设计为短暂的。通过使用卷来支持持久数据。它们被挂载到容器中，以将数据存储在主机的其他位置。
卷存储的性能因所选驱动程序和主机环境而异。即使在最好的情况下，与直接与主机的文件系统交互相比，也会有额外的开销。在有大量文件读取或写入的情况下，这可能很重要。

存储在卷中的数据可能难以管理和维护。您需要使用 Docker 命令与您的卷进行交互。最好通过获取容器的外壳并从内部枚举卷的内容来执行数据检查。

Docker 要求您考虑存储并选择自己的持久化策略。这与虚拟机和操作系统包安装不同，您可以在任何目录中安全地存储数据，而不必担心以后如何管理它。

开发本地工具和应用程序

当您构建具有您不想在每个环境中安装的依赖项的长期服务时，Docker 最有意义。一个常见的示例可能是在 NGINX Web 服务器后面运行的 PHP Web 应用程序：有多个组件，包括您希望从单个命令启动的后台服务器。

当您创建用于本地使用的工具（例如桌面程序和移动应用程序）时，Docker 增加的价值较少。这种软件开发往往会产生无法在容器中运行或通常不会被用户容器化的工件。
在这些情况下，您仍然可以从 Docker 中受益，方法是使用它来打包工具链，而不是最终输出。例如，您可以创建一个包含 Java 和 Android 平台工具的 Docker 映像，以使新开发人员不必将这些包添加到他们的机器中。

然而，这最终会增加由 Android Studio、Visual Studio 和 Xcode 等 IDE 驱动的学科的复杂性。开发人员习惯于安装 IDE 并让它配置他们的环境。因此，与可以将正确的解释器版本烘焙到映像中的解释语言相比，Docker 倾向于为编译语言工作流增加更少的价值。

安全是重中之重

Docker可以提高您的堆栈的安全性，但需要努力正确地加强您的安装。一个经常犯的错误是假设 Docker 的安全开箱即用。说白了：不是。

我们并不是说 Docker 的存在本身就是一种安全风险，因为事实也并非如此。尽管如此，重要的是要认识到 Docker 具有独特的风险，并且它们会根据您对技术的使用而有所不同。就像任何其他软件组件一样，您需要花时间了解这些风险、它们如何影响您遵守对您很重要的安全标准，以及您应该采取哪些措施来解决这些风险。

很容易听到“孤立的应用程序”的宣传并假设它扩展到沙盒级别的安全性。实际上，标准 Docker 安装运行容器进程，root并且容器突破可能会危及您的主机。

Docker 安全性是一个多方面的主题，需要您考虑主机环境、Docker 守护程序以及如何构建和维护映像。开发人员也可以通过最大限度地减少容器内运行的代码中的风险操作来发挥作用。
所有这一切意味着 Docker 可能不是安全关键设置的好选择。尽管 Docker 可以提供安全保护，但您需要拥有熟练的团队成员和具有安全意识的心态，以确保您解决它引入的新问题。

你的代码库是一个单体

您可能已经读过容器与微服务齐头并进。这种心态描述了将系统雕刻成可以轻松容器化的独立组件的过程。拆分服务后，可以单独扩展它们，并且可以替换部分而不影响其他部分。

当您的应用程序是单体应用时，您将无法看到这些好处。但是按原样将单体系统容器化可​​能是错误的方法。大型遗留应用程序往往会获得大量依赖项和漫长的构建过程，这可能会快速膨胀您的 Docker 映像。这导致映像构建期间令人沮丧的等待时间以及过多的存储和带宽成本。

不过，像往常一样，这枚硬币有两个方面：容器化单体应用通常是实现堆栈现代化并将其分解为更小的服务的第一步。这是您将代码库与其绑定的环境分开的地方。

然而，如果您正在容器化而不打算在未来继续重构，那么最好重新考虑您的动机。包含多个功能组件的大型容器映像是一个很好的指标，表明您没有满足容器最佳实践。随着时间的推移，您可能会发现这种方法实际上阻碍了您并成为问题的一部分。

您正在尝试降低复杂性

试图降低复杂性？认为容器化将为开发和部署带来新的简单性？这又是一个“视情况而定”的时刻，但我们警告不要以简单为主要动机加入 Docker 潮流。
Docker 需要转变思维方式并熟悉新工具和概念。您的开发人员会对此感到满意吗？它将如何影响您的招聘流程？这些问题很容易被忽视，但应该尽早考虑。

尽管 Docker 消除了许多形式的复杂性，但它往往会以不同的形式重新出现。您需要编写、记录、维护和构建 Docker 映像，可以在开发人员机器上本地或作为 CI 管道的一部分。开发人员需要学习 Docker CLI、容器的基础知识，以及在准备容器化应用程序时需要注意的潜在问题。

如果您计划在生产环境中运行容器，您也会有更多的考虑。网络流量将如何路由到容器？如果容器意外停止，系统将如何响应？

“Docker 很简单”的支持者往往只关注您可以轻松地轻松启动已有的镜像实例。诚然，如果您想在笔记本电脑上安装一个新的 MySQL 数据库，那离您很docker run -d mysql:8遥远。然而，如果您要成功地使用 Docker构建和运行您自己的软件，同时满足最佳实践并避免常见的陷阱，那么还有很多东西需要学习。

你不确定为什么要容器化

容器无处不在；阅读几篇有关软件开发的文章时，您会遇到它们，而且支持者们直言不讳，热情洋溢。这种流行的吸引力可能会产生压力，让他们接受 Docker 作为其他人认为有用的“现代”工具。

这不是容器化的好理由。您需要一个更具体的目标，例如“开发人员应该能够在本地精确复制生产”或“我们需要能够水平扩展我们服务的副本”。如果您对 Docker 的用例不满意，并且对当前的工作流程感到满意，那么最好的选择可能是坚持使用有效的方法。这似乎是一个无聊的选择，但 Docker 并不是无可挑剔的变革力量，也不能保证成功采用。
将 Docker 添加到您的流程中可能需要大量的前期投资。您可能需要重构代码库、编写和测试 Dockerfile，给开发人员时间学习，并完成安全评估。当产生的好处不明确时——而且你还没有确定成功的样子——这种努力可能是一种负担，会减损你系统上的生产性工作。

结论

Docker 是一项当之无愧的流行技术：对于许多团队和开发人员来说，它提供了易用性、灵活性和性能之间的理想平衡，使其能够简化现实世界的开发过程。不过 Docker 并不神奇：根据您现有的技术、流程和思维方式，在某些情况下它无法运行，而在许多其他情况下它无法运行。

即使 Docker 不适合您今天的项目，您仍然可以通过逐步采用它来获得一些好处。确定您的流程中的挑战是什么，然后评估 Docker 是否可以在这些特定领域提供帮助。例如，如果开发人员花费太多时间来构建 API 的暂存实例，那么即使您无法在生产环境中运行容器，Docker 化堆栈的这一部分也可以解决瓶颈。

容器的全部意义在于能够将应用程序的一部分打包为独立运行的独立组件。这并不自动意味着您需要将每个组件打包为一个容器。保持客观，寻找机会在有意义的地方进行容器化，但要准备好识别 Docker 不会为现有工作流程增加价值的情况。