上游版 Ansible 功能强大，但并非“免费”这是为什么

上游版 Ansible 没有前期软件成本，因此似乎比 Ansible 自动化平台更具成本效益。然而，现实更为复杂。从个人用户级别转向完整的IT企业时，为业务环境维护上游版 Ansible 所需的费用可能远超 Ansible 自动化平台的订阅费用。

这要追溯到每个项目是如何开发的，每个项目是为谁设计的。

与其说上游版 Ansible 是一个项目，不如说它是由 20 多个独立的相关项目拼凑而成，其中包含数十种用途各异的不同工具。虽然这些项目对个人而言可能很强大，比如，允许用户使用可重用且易于人类理解的 playbook取代 bash 和 Python 脚本，但它们并未针对 IT 企业的任务关键型需求进行整体设计。

另一方面，Ansible 自动化平台在一个安装程序中测试、集成和捆多个开源项目，形成一个随时可用的解决方案。它还对开源项目的不同集合进行认证，以便您确切知道它们的工作方式和适用场景。然后，这个解决方案被打包为一体，以便用户安装到多个不同的环境中，包括裸机、虚拟机、容器，或许多主流的云平台，如AWS、Google Cloud和 Microsoft Azure 等。

这并不是说上游版 Ansible 在企业自动化方面表现不好;而是说这些功能往往一开始就不存在。对于通过东拼西凑构建的单独项目而言，它们通常甚至不在考虑范围内。

最终用户负责将各个部分拼凑在一起，得出满足自己需求的解决方案，但前提是他们能够高效做到这点。

打个比方，想象一下用一套工具造一辆汽车。虽然一些热衷于此的业余爱好者会享受这样的机会，而且有相当多的时间和方法可供使用，但对于那些只需要可靠的交通工具上下班、看医生、陪家人或接送孩子上学的人来说，这并不是一种合适的选择。无论是否具备专业知识，问题都在于是否值得花费时间和资源。

自己造车最初可能比从信赖的制造商那里购买预制的汽车便宜，但成功上路行驶和随后维护所需要投入的时间和资源，让其更像是一个有趣的项目，而不是切实可行的通勤用车方案。

选择上游版 Ansible 还是红帽 Ansible 自动化平台进行战略性企业级自动化是与此类似的取舍问题。

如果企业采用上游版 Ansiple，他们将需要在没有红帽支持的情况下管理和维护不同 Ansible 项目的零碎要素，这不仅成本高、耗时长，而且会造成重大的未来安全风险。最终，企业总体力量的很大一部分将用于管理自动化解决方案，而不是朝着开展创新和满足客户需求的核心目标前进。

免责声明：我们尊重知识产权、数据隐私，只做内容的收集、整理及分享，报告内容来源于网络,报告版权归原撰写发布机构所有，通过公开合法渠道获得，如涉及侵权，请及时联系我们删除，如对报告内容存疑，请与撰写、发布机构联系