我们已经为一家小型协会设置了一台运行基础设施的服务器。到目前为止，我们尝试使用 Ansible 管理配置，但效果并不理想。也许我们做错了。
原则上，我们的想法是，这个服务器大部分时间都是独立的，偶尔有人会添加或更改一些东西。因此，服务器上配置和运行的所有内容都必须有据可查且清晰明了，因为不经常管理系统的人肯定会失去对系统的了解（更不用说记住细节了）。此外，随着时间的推移，管理这个服务器的人员组成也会发生变化（因为有人离开并加入“委员会”）。
我们一开始安装得很干净，每次想要设置某些东西时，都会在 ansible 中添加角色（nginx、phpfpm、postfix、防火墙、sftp、munin 等）。也许由于我们缺乏经验，我们当然永远无法一次性完全按照需要输入一组 ansible 任务，也因为配置是一个反复试验的过程。这意味着在实践中，我们通常会首先配置我们想要运行的任何服务在服务器上，然后转换为 ansible 任务。您可以看到这是怎么回事。人们忘记测试任务，或者害怕这样做会破坏事物，或者更糟的是：我们忘记或忽略将事物添加到 ansible。
今天，我们几乎没有信心 ansible 配置实际上反映了服务器上的配置。
目前我发现三个主要问题：
- 很难（读作：我们没有好的方法来）测试 ansible 任务而不冒破坏事物的风险。
- 它增加了额外的工作，首先确定所需的配置，然后确定如何将其转换为 ansible 任务。
- （理想情况下），我们使用它的频率不够高，不足以建立熟悉度和常规性。
这里一个重要的考虑是，无论我们最终做什么，都应该简单的让新手无需大量练习就能掌握要领。
是否存在可行的替代方案，仍然可以提供一些保证和检查（类似于将 Ansible 文件合并到某些文件中master），而“配置事物并写下你所做的事情”无法提供？
编辑：我们考虑过提交/etc到 git。有没有一种合理的方法可以保护机密（私钥等），但仍然可以以某种方式在服务器外部使用配置存储库？
答案1
只需启动一个测试/暂存 VM，即可使用它来验证您的更改。您当前首先手动执行更改的方法完全是错误的，注定会失败。您和您的团队需要致力于正确使用 CM，其中一部分就是拥有一个可用的测试系统。即使只是一个本地 vagrant VM 也足够了。
这不仅有助于测试新的变化，而且还可以作为新员工（或一段时间没有使用该系统的老员工）熟悉您的 ansible 设置的测试平台。
关于将 /etc/ 保留在 git 中：不，不要这样做。该目录只是 ansible 更改的一小部分，将 git 放在那里只会鼓励人们进行本地更改。
将您的 ansible playbook 保存在 git 中。考虑限制权限，以便只有您可以将 ansible 更改应用于实时服务器。其他人可以提交包含其更改的拉取请求，您可以对其进行审核，并在适当的情况下将其合并到主服务器中。
答案2
也许是由于我们缺乏经验，我们当然永远无法一次性完全按照我们需要的方式输入一组 ansible 任务，也因为配置是一个反复试验的过程。这意味着在实践中，我们通常会先配置我们想要在服务器上运行的任何服务，然后将其转换为 ansible 任务。
虽然还存在其他问题（例如没有测试环境），但你可以通过不这样做来取得很大的进步这。
之一Ansible 的核心设计目标是幂等，这意味着多次运行你的剧本不会改变任何东西（除非你改变了剧本）。因此，当我配置一个新软件时，我的步骤是：
- 对 Ansible 任务进行更改。
- 运行剧本。
- 检查系统，如果不正确，则返回步骤 1。
- 提交我的更改。
如果你认为第一次在 Ansible 中写出的内容不正确，无论如何都要写并对其进行迭代，直到正确为止，就像任何其他代码一样。这大大降低了忘记对所做的某些更改进行 Ansiblize 的可能性，因为在开发过程中，您所做的每个更改都已在 Ansible 中。
答案3
Ansible 需要一定的时间才能超越之前的生产力水平，但一旦达到，您的系统状态就很容易保证了。您的实践似乎与您的最终目标不同步。您可以使用 CM 工具集提高生产力，同时保持可靠的工程实践，但需要时间来正确构建它。您实际上是在牺牲效率和易于实施性来换取稳定性和企业可扩展性。就像经验丰富的专业程序员不会编写丑陋的黑客程序一样，后果总是大于好处。
首先，你可能有太多的厨师，没有明确的所有权，如果这样，就会发生公地悲剧。每个业务优先事项每次都会压倒系统工程问题，除非它被广泛化解，剩下的问题直接反映在负责的工程师身上。
我刚刚意识到，CM 工具集无法由管理员设计。他们可以重复使用现有工作，或者可能在可靠的基础上进行扩展，但即便如此，也需要大量繁重的实践执行。工程师能做的事情，根本不是管理员能做的事情。Ansible 中的许多概念几乎与代码库中的概念相同，你能教管理员 Python 并期望得到称职的结果吗？不，绝对不行，我期望的是一份黑客工作，所以你需要让任务足够结构化，这样黑客工作才是可以忍受的。
因此，您需要为成功做好准备，为不必要的管理点设计解决方案。用低级系统复杂性换取管理员实际上可以成功完成的事情。CM 工具集不会让您免于架构或设计不匹配。
因此，顺序可能会被修改，显然是因为实施取决于哪条路径对您当前的状态的破坏最小。
将任何与业务相关的工作流相关系统工作转移到专用的运行平台。
将任务拆分到箱子上，你现在可能有两个或更多个箱子。
以更结构化的方式重新实现您的 CM，并遵循更好的 ansible 实践，剧本代表对象而不是功能或角色。每个系统都应在一个剧本中描述。