☰

频繁关机的 Ansible 管理

tag-icon • tag-icon linux ansible
频繁关机的 Ansible 管理

我想使用 Ansible 来管理大约十几个 Linux 工作站的配置。问题是，作为人们使用的物理机器，它们经常处于关闭状态。因此，我需要一个解决方案来确保当我更改集中配置时，它不仅会推送到正在运行的机器，而且最终会推送到几周后启动的机器。

我曾经有过的想法，并且我愿意接受更好的想法，就是让一个 cron 作业运行 @reboot 以 SSH 进入服务器并请求剧本针对其自身运行。

这似乎意味着我需要：

  • 创建一个部署服务器上的用户（deploy@server）
  • 创建一个部署每个工作站上的用户（deploy@ws）并授予他们 sudo 权限。
  • 将 deploy@server 的公钥添加到 deploy@ws 的 authorized_keys 中
  • 为 deploy@ws 生成一个新的 SSH 密钥，并将新生成的 SSH 密钥添加到 deploy@server 的 authorized_keys 中
  • 设置工作站 cron 作业，以 deploy@ws 身份运行，通过 SSH 进入服务器，并使用相关工作站的 --limit 运行 ansible-playbook。该作业以 deploy@server 身份运行，然后以 deploy@ws 身份通过 SSH 重新进入服务器，以实际进行配置。

这感觉有点复杂。有没有一些更直接的解决方案可以解决这个问题？

答案1

无需代理到中央服务器并返回。在托管节点上安装 Python 和 Ansible，并在本地主机上运行游戏。这会将 Ansible 从推送更改为拉取。

ansible-pull是此类脚本最著名的示例。它假设可以从源代码控制存储库中检索剧本。虽然不是最优雅的，但肯定是使用临时清单编写 ansible-playbook 脚本的一个有用示例。也就是说，它默认将主机模式限制为 localhostplus socket.getfqdn()，因此您可以提供完整的清单，但它只为自己运行。

如果脚本在计划任务中以 root 身份运行，这种拉模型的一个优点是可能消除对特权远程用户的需求。

缺点是，这在可以运行 Ansible 的主机上运行起来更容易，因此 POSIX 操作系统，而不是 Windows 或网络设备。在拉动模型中跟踪库存并不容易，请考虑通过打开回调插件来实现某种报告。

答案2

请查看ansible-pull。我感觉你正准备尝试重新创建它。

相关内容