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

Question

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

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

Answer 1

一般来说,服务器安装的普遍看法是它们应该尽可能地被剥离.这有一些动机,但它们并不真正直接适用于您关于编译器的问题:

• 最大限度地减少资源使用.GCC可能占用一些额外的磁盘空间,但可能不够重要 - 并且它不会在大多数时间运行,因此CPU /内存使用不是一个大问题.
• 尽量减少复杂性.在您的服务器上构建可能会为您的构建过程添加一些失败模式(如果您在其他地方构建,那么至少在您搞乱生产服务器之前会发现错误),但除此之外,它不会妨碍.
• 最小化攻击面.正如其他人所指出的,当攻击者可以使用编译器时,你可能已经搞砸了......

在我的公司,我们一般不会太在意,如果编译器在我们的服务器上安装,但我们也从来没有运行pip在我们的服务器上,一个相当不同的原因.我们并不关心构建软件包的位置,而是关注软件包的下载时间和方式.

我们中间特别偏执的人会注意到pip(和easy_install)会愉快地从PYPI安装包而不需要任何形式的身份验证(没有SSL,没有包签名,......).此外,其中许多实际上并未在PYPI上托管; pip和easy_install遵循重定向.所以,这里有两个问题:

• 如果pypi - 或托管您的依赖项的任何其他站点 - 发生故障,那么您的构建过程将失败
• 如果攻击者以某种方式设法对您的服务器执行中间人攻击,因为它正在尝试下载依赖包,那么他将能够将恶意代码插入到下载中

因此,我们在首次添加依赖项时下载软件包,尽最大努力确保源代码是真实的(这不是万无一失的),并将它们添加到我们自己的版本控制系统中.我们实际上是在一个单独的构建服务器上构建我们的软件包,但这不是那么重要; 我们发现有一个二进制包我们可以快速部署到多个实例.