不在实时服务器上托管编译器的原因是什么？答案

【问题标题】：What are the reasons for not hosting a compiler on a live server?不在实时服务器上托管编译器的原因是什么？
【发布时间】：2012-04-30 20:15:12
【问题描述】：

在我目前工作的地方，我们就将 Python 代码部署到生产服务器进行了一场小型辩论。我投票决定在服务器本身上构建二进制依赖项（如 python mysql 驱动程序），只使用pip install -r requirements.txt。这很快被否决了，没有更好的解释“我们不会将编译器放在实时服务器上”。因此，我们的部署过程变得复杂和过度设计，只是为了避免这个编译步骤。

我的问题是：这些天来避免在实时服务器上安装编译器的原因是什么？

【问题讨论】：

您不需要安装这些依赖项才能在生产环境中运行吗？
@DeaconDesperado，是的，但它们不需要建立在它们最终将驻留的盒子上。
我知道 PIP 会在下载软件包后构建它们，但我从来没有听说过这会被认为是部署环境的“破坏交易”，尤其是因为它只需要执行一次。 pip freeze 结合fabric 和virtualenv 几乎是我所熟悉的唯一部署方法。我和你在一起，菲尔，对我来说听起来像是不必要的过度复杂化，至少在 PIP 和 python 的情况下。

标签： python deployment compiler-construction pip binaries

【解决方案1】：

一般来说，关于服务器安装的普遍看法是，它们应该尽可能地精简。这样做有一些动机，但它们并没有真正将所有这些直接应用于您关于编译器的问题：

尽量减少资源使用。 GCC 可能会占用一点额外的磁盘空间，但可能还不够重要 - 而且它大部分时间都不会运行，因此 CPU/内存使用量不是很大担心。
尽量减少复杂性。在您的服务器上构建可能会在您的构建过程中添加更多故障模式（如果您在其他地方构建，那么至少您会在弄乱生产服务器之前发现一些错误），但除此之外，它不会碍事。
最小化attack surface。正如其他人指出的那样，当攻击者可以利用编译器时，您可能已经被搞砸了..

在我的公司，我们通常不太关心我们的服务器上是否安装了编译器，但我们也从不在我们的服务器上运行pip，原因完全不同。我们并不关心包在哪里构建，而是何时以及如何下载它们。

我们当中特别偏执的人会注意到 pip（和 easy_install）会很高兴地从 PYPI 安装包，而无需任何形式的身份验证（没有 SSL，没有包签名，...）。此外，其中许多实际上并未托管在 PYPI 上。 pip 和 easy_install 遵循重定向。所以，这里有两个问题：

如果 pypi（或托管您的依赖项的任何其他站点）出现故障，那么您的构建过程将失败
如果攻击者在尝试下载依赖包时设法对您的服务器执行中间人攻击，那么他将能够在下载中插入恶意代码

所以，我们在第一次添加依赖时下载包，尽最大努力确保源是真实的（这不是万无一失的），并将它们添加到我们自己的版本控制系统中。我们确实在单独的构建服务器上构建我们的包，但这并不重要；我们只是发现拥有一个可以快速部署到多个实例的二进制包很有用。

【讨论】：

【解决方案2】：

我建议参考这个serverfault post。

避免漏洞被远程编译是有意义的

对我来说，就安全性而言，与使用编译器相比，它只会使劫持者的任务更加困难，但这并不完美。

【讨论】：

如果有人有权在您的系统上运行任意命令，那么您已经完蛋了。（正如链接的帖子所说）

【解决方案3】：

这会给服务器带来很大的压力吗？

【讨论】：

偶尔编译一些东西应该不会产生太大的负载。
CPU 密集型系统的一个好点，但这些是简单的应用服务器，在这种情况下，开销可以忽略不计。
@MrD 没错，但我没有遇到任何 Python 包在编译时付出了巨大的努力。