Docker的环境标准化答案

【问题标题】：Docker's standardization of environmentsDocker的环境标准化
【发布时间】：2018-09-09 06:42:25
【问题描述】：

我正在努力解决一个似乎没有人在 Internet 上详细回答的问题。

“跨整个管道的标准化服务基础架构允许每个团队成员在生产平价环境中工作”

这是 Docker 的一个关键优势：它允许每个人在类似生产的环境中进行开发、测试或任何事情。因为通过管道传递的容器总是相同的。我明白了。我知道这是必要的，而且 Docker 很容易做到这一点。但我不明白的是，为什么在 Docker 之前这么难？如果我有一台生产机器和一台测试机器，我构建一个安装正确依赖项的脚本不会有任何问题，不管机器是什么。所以我在库或框架方面的环境将是相同的。

对于整个环境相关的好处，我唯一理解的是，Docker 允许开发人员选择他的操作系统，而不必担心与平台相关的错误。我已经遇到了适用于 Windows 而不是 Mac 的功能。我认为最糟糕的错误。所以是的，如果我当时有 Docker，我就不会遇到这个问题。但我不明白为什么 Docker 对于其他与环境相关的东西来说是一个奇迹。

我认为我不理解这一点，因为我只从事过小型项目。也许我也没有意识到“环境”这个词的全部含义。

我在这里缺少什么？为什么容器是标准化环境的突破口，而脚本可以实现这一点？

【问题讨论】：

没关系，现在你看到了图片的一小部分。这不仅仅是编写脚本、处理依赖关系...... Docker 对团队合作的方式、应用程序的设计和实现方式以及我们如何使用基础设施带来了巨大的变化。阅读以下概念：单体应用程序与微服务，为什么部署时间很重要，水平与垂直扩展，无服务器。如果您阅读history，可以找到一些拼图。
要获得相同级别的环境隔离，每个服务都需要一台机器/VM。
@tgogos 是的，我非常了解微服务的好处，并且我了解 Docker 的所有其他好处。我爱码头工人。但我就是不明白这一点：为什么在容器之前的任何地方都很难拥有类似产品的环境？

标签： docker development-environment production-environment test-environments

【解决方案1】：

以下列表并不详尽，它仅代表了 docker 的三个重要优点。请注意，docker 并不是一个神奇的解决方案，可能无法适应特定的环境。

首先，使用容器依赖项之间没有冲突。

如果您有两个程序使用不同版本的同一个库，您必须在执行程序之前手动安装这两个版本并指定自定义环境变量。（例如LD_LIBRARY_PATH）。请注意，有一些工具可以解决这个问题，但仅限于特定情况（例如 python 中的虚拟环境）。

其次，使用容器你没有持久性。

例如，如果您编写了一个小 bash 脚本来安装基于 Nginx 和 PHP 的开发环境，并且我错误地安装了 Apache，即使您再次运行脚本，我的包仍然存在。问题是 Apache 有时会在 Nginx 之前启动并阻塞 80 端口，从而破坏您的开发环境。

总而言之，如果没有 docker，您将无法确定未跟踪元素的状态，并且它们可能会破坏您的环境。

第三，docker 可以让你缩小开发和生产之间的差距。

close 环境是“您的代码运行所需的一切”。例如库、配置文件、您的解释器（python、php、...）。 Docker 将应用程序与其封闭的环境打包在一起，这样您的应用程序所需的内容与您提供的环境之间就不会出现不匹配。

当您在开发期间更新依赖项并且可能忘记在生产中更新它们时，这一点尤其重要。

一个错误的论点是安全和隔离。安全流程从定义威胁模型开始，然后选择对策。添加 docker 是因为它增加了风险环境中的安全性是不够的（没有内核空间隔离），如果您不需要更多安全性而添加 docker 被称为妄想症。 Docker 添加了用户空间隔离和默认的 seccomp 配置文件，但这不是使用它的理由，除非它与您的威胁模型匹配。

【讨论】：