配置管理的声明式与命令式模型哪个更好？

作为一组概念，DevOps 融合了几个突出的主题，包括持续软件交付、自动化和配置管理 (CM)。这些不可或缺的部分通常构成组织 DevOps 工作的支柱，即使其他更大的部分（如总体最佳实践和指南）仍在尝试和测试中。由于 DevOps 是一种相对较新的范式 - 运动 - 方法论 - [在此处插入您自己的标签]，围绕它的标准尚未被编纂并一成不变。组织需要确定最适合其用例的工具和方法，并且会根据其成功程度对它们发誓或贬低它们。

就 CM 而言，一种特定的方法可能适用于一家公司，但不适用于另一家公司，这是一个假设。然而，很少有不同的方法会像 CM 的声明式和命令式模型那样产生如此多的异议。关于谁更胜一筹的反复辩论已经赢得了双方的坚定支持者，值得仔细研究。

定义声明式和命令式模型

声明式和命令式模型之间的差异可以用一句话来概括：命令式侧重于如何，而声明式侧重于什么。在软件工程上下文中，声明式编程意味着编写代码来描述程序应该做什么，而不是它应该如何做。一个描述需要发生的事情；让它如此的细节留给系统。相比之下，命令式编程涉及编写遵循明确步骤来解决问题、完成任务或达到预期结果的代码。它具体告诉系统如何做某事，以期达到预期的结果。

命令式/声明式构造也延续到 IT 领域，例如 CM。事实上，一个特定的 CM 工具的方法很大程度上受其构建的基础语言的影响（反过来，它本质上是命令式的或声明式的）。

例如，Puppet 是声明性的：系统管理员描述了所需的最终状态，并且工具会尝试达到它。它的领域特定语言 (DSL) 用于创建所需服务器状态的高级描述，而不是要执行的指令和操作。清单——包含配置信息的 Puppet 文件——可以多次使用以达到相同的结果。如果已达到所需的最终状态，Puppet 会简单地忽略相关项目。用户只需担心要配置的系统所需的最终状态，而不是到达那里所需的步骤顺序。

该条目描述了一个结束状态，其中包含一个名为 /tmp/test123 的文件，其内容为“这是一个测试”。如果在目标系统上找到匹配的文件（和内容），Puppet 假定已经达到所需的结束状态。随后，无需担心 Manifest 会多次执行此部分。

相比之下，Chef（Puppet 的宿敌）势在必行。用户在称为食谱的配置指令中定义命令及其执行顺序，这些指令又可以组织成食谱，以便于管理。

此配方检查目标节点上的 JDK 7——如果存在，Chef 将安装 OpenJDK 7。如果不存在，则会发出警告。请注意，Chef Recipes 的结构是顺序的命令列表，而不是 Puppet Manifests，后者仅包含对所需最终状态的描述。

CM 供应商的一个增长趋势是让他们的产品对任一模型开放，从而赢得两个阵营的心。即使是像 Chef 这样本质上必不可少的工具也可以以声明方式设置。

与前面的示例相比，上述配方描述了所需的结束状态，而不是列出要执行的一系列命令。

那么哪个型号更适合CM呢？要解决这个问题，需要有资格获得谁和什么。此外，考虑到 DevOps 的当前流行程度和采用率，专家们的复杂程度不断提高也就不足为奇了：围绕 DevOps 的对话已经从它是什么发展到如何去做。怎么做取决于你问的是谁。

因此，让我们从三个角度分析这场争论：程序员、系统管理员和全栈开发人员。

热衷于编写高效、结构化和易于理解的代码的程序员并不是采用笨拙抽象的声明性模型的最大粉丝。他习惯于用 for 循环、条件语句、变量等来规定事情应该如何发生。他所从事的软件的业务逻辑本质上是必不可少的。

最适合：像 Chef 这样的命令式 CM 工具

系统管理员 喜欢经营一家紧凑的商店，这是有充分理由的：如果基础设施出现故障，公司就会急刹车。他是一个 Bash 向导，精通 Python 和 Perl，并且更喜欢使用它们而不是学习像 Ruby 这样的新语言。他更喜欢声明式而不是命令式模型，但他意识到前者在管理动态云基础架构方面所面临的挑战。

最适合： 混合 CM 工具，如 Ansible 或 SaltStack

全栈开发人员 可以轻松地遍历堆栈，并且喜欢将基础架构抽象为代码的想法。Ruby/RoR 忍者，她是 Chef 和 Puppet 的粉丝。她可以欣赏每个模型的优点；对她来说，任何一种工具都可以让她更快、更高效、更不容易出错地持续构建和发布高质量的软件。

最适合：任一型号。Puppet、Chef 和 SaltStack 是可行的选择。

请注意，我们的程序员很可能是 Python 专业人士，因此非常精通 Ansible（其模块是用 Python 编写的）。无论如何，将组织的 IT 技能构成与适当的模型/工具相匹配是确定哪个更合适的实用方法。如果一家公司从事由程序员掌舵的传统软件开发，那么命令式工具可能是最合适的。一个按计划持续推出的快速发展的 SaaS 将欣赏一个实施良好的声明式 CM 解决方案的灵活性和可扩展性。一个对 Ruby 发誓并拥有专业知识的商店可能会选择使用某些工具“烹饪”，从而完全推翻模型辩论。

要记住的关键点是声明式和命令式模型都是易错的：前者需要相信已达到所需状态（几乎没有验证手段），而后者则需要在出现问题时进行复杂的故障排除。在某些边缘场景中，这两种模型都可能存在问题；随后，无论采用哪种方法，都不应将单个工具实施为 CM 的全部和最终目标。所选择的解决方案应该只包含 CM 工具链的一部分，而另一个将其作为监督工具，确保所有 CM 和自动化工具都按预期执行。

服务于这个目的：通过强大的扫描、监控和比较功能提供全面的系统可见性，我们的平台弥合了期望您的系统/环境以某种方式与实际验证它是否满足这些期望之间的关键差距。

简而言之，争夺思想和市场份额的竞争供应商将热情地拥护他们的产品各自的方法。尽管围绕声明式/命令式模型的辩论在商业 CM 领域呈现出新的强度和热情，但事实是，许多工具兼具两者的品质——尽管它们可能更多地基于一种模式。因此，将声明式和命令式模型视为一系列可能性，各自的解决方案更接近任一端，这可能更有用。