“单服务器多个管理员”的配置管理

我们已经为小型关联设置了运行基础结构的服务器。到目前为止，我们已经尝试使用Ansible管理配置，但这并没有取得很大的成功。也许我们做错了。

原则上，这个想法是大多数时间该服务器将保持不动，人们会在一个蓝色的月亮中添加或更改事物。这使得至关重要的一点是，服务器上进行了任何配置和运行的文件都必须有据可查且清晰明了，因为不经常管理系统的人肯定会丢失概述（更不用说记住细节了）。此外，随着时间的推移，将管理此服务器的人员组的组成发生变化（当人们离开并加入“委员会”时）。

我们从全新安装开始，每当我们想要设置某些内容（nginx，phpfpm，postfix，防火墙，sftp，munin等）时，都会在ansible中添加角色。也许由于我们的经验不足，我们当然永远无法完全按照我们想要的方式来输入一组烦人的任务，这也是因为配置过程是一个反复试验的过程。这意味着实际上，我们通常会先配置要在服务器上运行的任何服务，然后转换为可完成的任务。您可以看到前进的方向。人们忘记了测试然后再测试任务，或者害怕这样做会破坏事物，甚至更糟：我们忘记或忽略将事情添加到ansible中。

如今，我们对Ansible配置实际上反映了服务器上配置的内容几乎没有信心。

目前，我看到三个主要问题：

很难（阅读：我们没有很好的方法）测试烦人的任务而又不会冒险破坏事情。
它首先要弄清楚所需的配置，然后弄清楚如何将其转换为可完成的任务，因此需要付出额外的工作。
（理想情况下）我们没有足够频繁地使用它来建立熟悉度和例行程序。

这里一个重要的考虑因素是，无论我们最终要做什么，新手都应该容易地学习绳索而无需大量实践。

是否有可行的替代方案仍然可以提供一些保证和检查（类似于将Ansible文件合并到某些文件master），而这些保证和检查却无法提供“配置事物并写下您所做的事情”？

编辑：我们已经考虑过提交/etc到git。有没有一种合理的方式来保护机密（私钥等），但是仍然可以以某种方式在服务器外部使用配置存储库？

ansible configuration-management

— 约斯特
source

Answers:

只需启动一个可用于验证更改的测试/临时VM。您当前首先手动执行更改的方法无可救药，并且注定要失败。您和您的团队需要致力于正确使用CM，其中一部分是要有一个可用的测试系统。即使是本地无用的虚拟机也足够了。

这不仅有助于测试新更改，而且还可以作为新员工（或一段时间内未使用该系统的老员工）熟悉您的烦人设置的测试平台。

关于将/ etc /保留在git中：不，不要这样做。该目录只是ansible所更改内容的一小部分，在那里安装git只会鼓励人们进行本地更改。

将您的ansible剧本保存在git中。考虑限制权限，以便只有您才能对实时服务器应用有效更改。其他人可以提交拉动请求及其更改，如果适当，您可以查看并合并到主请求中。

— 欧洲能源管理局
source

是的，这是理想的情况。我明白了。关键是，我们不是公司，也没有专职人员。也许我没有足够清楚地说明其范围。每增加一部分（例如vagrantfile）都会增加需要传递的复杂性，并运行两种配置（即一个测试系统，其中需要模拟letencrypt自动化）不助于简单。

— Joost，

好吧，您问如何解决您的问题，我给了我答案。以上正是我们在公司工作的方式，并且效果很好。是的，在测试所需的服务器空间和时间方面会产生额外的成本，但这是值得的，因为我们有很高的保证水平，即在几分钟内就可以根据需要重建任何服务器。

— EEAA

从根本上讲，这实际上是文化和资源问题，而不是技术问题。您尚未承诺使用配置管理。您是否是公司无关紧要。您正在寻求有关如何正确执行操作的帮助，而拥有暂存环境是其中的一部分。

— EEAA

恕我直言，是的，您应该致力于这一点。但是，是否可以说服同事是另一个问题。没有任何轻量级的方法可以做到这一点，而这不需要管理服务器的人员有一定的故意性。在现代CM系统中，ansible是迄今为止最容易实现的。您确实想跟踪服务器随时间的变化。可靠地做到这一点的唯一方法是使用CM。

— EEAA

@ThomWiggers因为您使用“我们”，所以我假设你们两个在同一个团队中。好的，您问如何正确执行此操作。我给了答案。您是否想要正确执行此操作，或者您不想这样做。正确地执行CM需要花费时间，金钱和故意。如果您有通过LE购买和部署证书的要求，则可以在Digital Ocean上使用每月5美元的虚拟机，并将其用于测试。哎呀，当您要测试更改然后取消它时，甚至可以按需部署它。

— EEAA

也许由于我们的经验不足，我们当然永远无法完全按照我们想要的方式来输入一组烦人的任务，这也是因为配置过程是一个反复试验的过程。这意味着实际上，我们通常会先配置要在服务器上运行的任何服务，然后转换为可完成的任务。

虽然有其他问题（如没有一个测试环境），你可以不这样做一个大的改善这个。

一个Ansible的核心设计目标是要幂等，这意味着运行你的剧本多次不应该改变什么（除非你已经改变了戏剧）。因此，当我配置新软件时，我的步骤是：

对Ansible任务进行更改。
运行剧本。
检查系统，如果不正确，请返回步骤1。
提交我的更改。

如果您认为您不会在Ansible中第一次编写正确的内容，则无论如何都要编写并对其进行迭代，直到它正确为止，就像其他任何代码一样。这极大地减少了忘记对所做的更改进行Ansiblize的机会，因为在开发过程中的某个时候，您所做的每项更改都已在Ansible中。

— 抵制Monica Cellio的SE
source

是的，这是很好的建议。这样做并确保始终可以将服务器恢复为已知良好状态非常容易-如果情况不妙，只需对服务器进行核对然后重新部署即可。

— EEAA

是的，我同意这是我们现在和现在应该之间的坚实基础。当然，这就是我们开始的方式。我想我们移至现在所在的主要原因是步骤2使整个周期花费了太长时间。可能是我们做的剧本有误。现在，我们已经更加精通编写Ansible任务，也许值得再次尝试。根据您的经验，一个完整的周期要花多长时间，一个周期要迭代一次？我意识到任何数字都将基于各种假设

— 。– Joost

当您编写一个进行更改的任务，对服务器进行更改，发现更改错误，更新任务并重新应用剧本时，我在此迭代过程中遇到的另一个问题发生了。现在，服务器包含两组更改的组合：来自任务第一次迭代的更改和来自第二次迭代的更改。通常，第二次迭代将覆盖第一次迭代，但不一定总是如此。是否有一种合理的方法来“清理”而不是1）手动SSH进入撤消操作，或2）每次从全新安装开始？

— Joost

此外，如果只有一台

— 容易的事

“根据您的经验，一个完整的周期要花多长时间，一个周期要迭代一次？-我在一月份开始使用Ansible；到六月左右，对于大多数任务，我要比手动完成整个流程要快得多。当然，具体时间取决于项目，范围从几分钟到几周（对于某些特别易变的软件）。如果您发现剧本本身的运行速度减慢了您的速度，则您可能希望研究使用标签仅在迭代循环中运行一个子集。

— Monica Cellio的抵制SE

Ansible在超出您之前的生产率水平之前就有一个准备时间，但是一旦您确定了系统状态，就很容易确定。您的做法似乎与最终目标不同步。使用CM工具集可以保持高水平的工作效率，同时保持扎实的工程实践，但是正确构造它需要时间。从本质上来说，您的交易效率高且易于实施，以实现稳定性和企业可伸缩性。与经验丰富的专业程序员不会编写丑陋的hack的方式完全相同，其结果总是大于收益。

对于初学者，您可能有太多厨师，没有明确的所有权，如果这样的话，您会想到公地的悲剧。每个业务优先级每次都会压倒系统工程问题，除非它被广泛地混淆并且剩下的内容直接反映给负责的工程师。

CM工具集无法由管理员进行设计，这就是我刚刚意识到的。他们可以重复使用现有工作，或者在稳固的基础上扩展，但是即使那样，也需要大量的实践执行。工程师可以做什么，根本不是管理员可以做什么。Ansible中的许多概念与代码库中的几乎相同，您可以教Admin python并期望获得令人满意的结果吗？不，最不肯定的是，我希望有一份黑客工作，因此您需要使任务结构化，以便可以接受黑客工作。

因此，您需要为成功做好准备，为不必要的管理点设计解决方案。用低级系统的复杂性来换取管理员实际上可以成功完成的事情。CM工具集不会使您免受体系结构或设计不匹配的困扰。

因此，顺序可能会发生变化，这显然是因为实现取决于对您当前状态的破坏最小的路径。

将所有与业务相关的工作流程相关的系统工作移至专用的梯级。
在盒子上拆分任务，您现在可能有两个或多个盒子。
以更结构化的方式重新实现CM，并遵循更好的ansible做法，即代表对象而非功能或角色的剧本。每个系统都应该一口气描述。

— 杰克·贝克尔
source