我曾在一个组织中工作，我们使用puppet和ansible进行配置管理......但我总是想知道为什么他们会使用这两种工具...... Ansible不能做什么木偶呢？
我想到的唯一想法是： - Puppet用于检查系统是否定期处于所需状态;而Ansible用于部署一次性事物（代码，脚本，包等）
有人可以解释为什么组织会同时使用这两种工具吗？可以通过Ansible进行常规配置检查吗？
干杯
答案 0 :(得分：9)
为了充分披露，我是一个为Ansible贡献开发人员的上游社区，但我会尽力保持我的回应中立。
我认为这很大程度上是固执己见的，你会得到各种各样的结果，取决于你与谁交谈，但我有效地考虑这个：
Ansible是一种自动化工具，Puppet是一种配置管理工具。我不认为他们是直接的竞争对手他们似乎被科技记者比较，除了他们在配置管理工具中执行你想要的功能有一些重叠：服务/系统状态，配置文件模板，应用程序生命周期管理等。
我在完全不同的视角看到这些工具的主要地方是Ansible执行任务的自动化，这些任务可以是许多“类型”的东西之一，你真的没有想到的配置管理工具，如IaaS配置（AWS，GCE，Azure，RAX，Linode等），物理网络配置（Cisco IOS / ASA，JunOS，Arista，VyOS，Netscaler等），虚拟机创建/管理，物理负载均衡器配置（F5 BigIP），列表继续。实际上，Ansible是您的“自动化粘合剂”，用于创建和自动化您和您的团队可能需要手动完成的流程。它作为一个工具可以与Puppet，Chef和SaltStack等进行比较，因为您可以或多或少地自动化的许多“类型”任务中的一个加起来进行配置管理。
另一方面，虽然配置管理工具（如Puppet）通常在节点上运行守护程序，需要配置/引导（可能使用Ansible），这有其优点和缺点（我不会在这里讨论） ，这很大程度上超出范围）。守护进程为您提供的一件事是持续的最终一致性。您可以在Puppet Master上以权威方式设置配置管理，然后代理将在系统上维护该状态，并在必须更改可以连接到警报监视的内容时提供报告，以便在出现问题时通知您。虽然Ansible也会在需要更改时报告，但只有在运行Ansible Playbook时才会报告。它是推模型而不是拉模型（也不是一个连续运行的守护进程，它将强制执行系统状态）。这对于报告等具有优势。我会注意到像Ansible Tower / AWX这样的东西可以或多或少地模仿这个功能，但它不是一个“烘焙”功能。请记住一些事情。
最终，我认为这可以归结为对技术的熟悉程度，所需的功能集，以及是否有预先存在的投资（包括时间和金钱）到工具链中。如果你已经使用Puppet 5年了，那么当你可以使用Ansible来增强它（在Ansible中甚至有一个木偶模块）并且允许每个人彼此玩得很好时，没有真正的动力去叉车替换它。从两者中获取所需的功能。但是，如果你是从头开始，那么我认为你可能会考虑实际的优点/缺点或功能比较你真正想要的工具，以找出是否值得投资两个工具从头开始或找到一个可以满足您所有需求的产品，虽然我在这方面偏向Ansible，但最终的选择取决于那些将不得不使用该实用程序来维护基础设施的人。
我认为混合方法的一个很好的例子是我知道一些使用Puppet进行配置管理的公司，以及Ansible用于软件生命周期发布过程，其中其中一个任务在他们的剧本中字面上称为puppet模块带来所有系统进入配置一致性。这里的Ansible组件是在各种系统之间自动化/编排，过程的基本概要是：首先从负载均衡器中删除一组主机，确保数据库连接已停止，执行升级/迁移，运行puppet进行配置/状态一致性，然后以他们认为合适的顺序将事物重新联机。这一切都发生在一个命令（或点击Tower / AWX中的按钮）。
Anyhoo，我知道这有点啰嗦，但希望它很有帮助。