对于我们管理的主机，我的老板有一个通过版本化软件包（在我们的特定情况下，fpm 构建的 debian 软件包）进行配置管理的愿景。这是为了：
- 主机部署更轻松
- 更容易跟踪本地更改
- 使错误跟踪更容易，因为在大多数情况下，我们可以将软件版本标记为错误，无论是功能错误还是配置错误。
另一种选择是通过 Ansible 进行配置管理，其推荐布局如我们当前正在使用的手册中所示。我们安装版本化的软件包（几乎所有 Web 服务），它们将负责其自己的特定于包的配置，并将 Ansible 留给系统范围的配置。更新主机软件只需增加版本号并重新运行脚本即可。我们严重依赖 Ansible 的“var_prompts”功能来确保我们将敏感信息与配置分开。
在“通过版本化包进行配置管理”的情况下：
对于部署，我们只需启动一个最小的服务器（代理等）并使用包管理器（在我们的例子中是 apt）来安装单个伞包，这将安装所有依赖包。对任何依赖包进行更改只会提升最顶层的包版本，从而更容易更新现有部署。
对于配置，每个软件包都有一个附带的“config”包，仅允许更改配置。每个包都有独立的配置文件，以防止当我们验证主机上的本地更改时包之间发生冲突。我们不会运行生成配置的命令，而是确保将生成的文件作为包的一部分，但仍然允许通过安装前/安装后脚本运行命令。 AFAIK，在很多情况下，我们的软件包都将依赖于相同的配置文件，但如果是这种情况（系统配置就是这种情况），我们将有另一个软件包，该软件包将具有对两者的依赖。我可以看到这种特殊情况已经失控，但这可以通过始终确保独立的配置文件来控制。最后，每个主机都会有自己独特的配置包。显然，所有这些文件都将受到源代码控制，我们可以启动自己的简单模板系统，这样我们也可以拥有 Ansible 角色的灵活性。
我很好奇为什么我找不到有关此类配置和部署主机的工作流程的任何信息/分析。与现有的配置管理工具相比，我是否错过了这种方法的根本缺陷？
答案1
由于以下几个原因，包管理器对于配置管理并不是真正有效：
- 大多数软件包在安装时都包含配置，因此您必须创建将它们删除的自定义软件包。
- 包管理器的工作假设是包安装了可以在系统内更改的基本配置。因此，如果重新安装/升级软件包，它通常会提示用户如何处理修改后的文件（这对于配置管理器来说不是理想的行为）。
- 包管理器通常不会根据包内容测试系统，尽管有些有该选项，但效率不高，因为它不是经常使用的功能。
- 包生命周期比大多数自动化配置工具更复杂、更长，因此维护这样的设置需要更多工作。
- 包管理器不关心安装顺序，因此如果您存在包依赖性
a->b->c并且已经安装了包 c 并且您安装了包 a，则包 c 将不会重新安装，并且包 a 和/或 b 可能会覆盖 c 的配置。
如果您坚持使用包管理器来维护配置，我建议您检查使用独立配置管理系统（如 puppet 或 Chef）的选项，在其独立模式下使用包进行配置，这样您就可以拥有所有您的配置在单个版本化的包中，但不需要包管理器管理磁盘上的配置，这可能会导致我列出的问题以及可能更多的问题。
澄清一下，应该可以按照您的计划进行，只是包管理器不是执行此操作的理想工具。