用saltssh替换ansible

2020-10-22 22:34:12

直到最近,我还一直使用Ansible来管理这台机器(或机器)。我想要在该机器上进行配置管理,这样,如果某个磁盘、VM或整个主机提供商消失,我会有一个神奇的按钮,可以从无到有开始重建,抓起一杯咖啡,然后让一切恢复原样。我想要Ansible来完成这项任务,因为它相当容易和容易接近,只需要从主机系统访问SSH就可以了,而且是用Python编写的。不像Pupet、Chef、CFEngine和SaltStack-或者我是这么认为的--我想要Ansible来完成这项任务,只需要从主机系统访问SSH就可以了,而且是用Python编写的。不像Pupet、Chef、CFEngine和SaltStack-或者我是这么认为的。

随着使用Ansible的时间的推移,我注意到当我对剧本进行更改时,我反复面临着相同的挑战:要么我运行整个剧本并等待许多事实上的无操作任务,要么我投资于使用标签进行注释,节省了一些运行时间,但需要解决标签在Ansible中存在的缺点。

Ansible中的标记有两个困扰我的问题。首先,您需要手动将相同的标记传播到所有依赖项任务,特别是在When-Condition中引用的任务,否则您将遇到未定义变量的问题,因为应注册该变量的任务尚未执行。因此,这是我必须手动处理的问题。

其次,标签和循环在Ansible中不能很好地协同工作。我想做的是将迭代项用作标签,如下所示:

-hosts:所有任务:-name:安装发行版软件包Package:name:";{{item}}";state:Present with_list:-git-htop标记:#NOTE NOT WORK!#GETS OUT OUT:ERROR!';Item';未定义-";{{Item}}";

不幸的是,这会导致错误!';项目';未定义,因为标签不支持Ansible中那样的循环。撇开引入新变量不谈,从概念上讲,我唯一的选择是将项目列表复制到标签中:

-hosts:所有任务:-name:安装发行版软件包:name:";{{item}}";state:Present with_list:-git-htop标记:#works,但不是Cool-git-htop。

如果我现在请求这些标记中的任何一个,我也需要允许整个循环运行,这意味着在没有任何附加值的情况下等待。我正在请求Ansible安装大约20个软件包,所以这里在运行时会有相当大的浪费。

我不想在大多数时间里解决标签的这些缺点,所以我在那段时间里开始了多任务处理,执行了整个剧本,当有结果的时候,我又回到了它的位置上。

然而,我很难接受另一件事:当我连续两次运行剧本时,对于第二次运行,Ansible将需要大约4分钟的时间来确认所有的工作都已经完成。为什么?我必须接受它是那么慢吗?

所以我开始寻找提高Ansible速度的方法,以及SSH流水线,禁用事实收集,Mitgen有所帮助,但不会使运行时间低于3分钟,所以我不是很高兴。顺便说一句,Mitogen在撰写本文时不支持Ansible>;=2.10,因此速度的提高将以在过去使用Ansible 2.9的时间更长为代价,这也不是很理想。(这也不是很理想)。

所以我接受了3分钟作为该攻略的最短运行时间,并开始考虑到其他地方寻找。

也许Salt有办法摆脱那些奴才、主人、守护程序和代理,这些似乎是我几年前在上一份工作中与SaltStack做过的事情。让我高兴的是,这一次我确实发现了salssh。saltssh是在2013-09-26发布的Salt 0.17.0中引入的,它实际上并不是新的。

我可以把我现有的Ansible攻略移植到Salt-ssh上吗?它会有趣并且工作得很好吗?当它实际上不需要做任何事情的时候,它会比3分钟更快吗?

为基于Caddy的SSL反向代理创建特定的Docker网络以与网站容器对话。

配置并激活DNF-Automatic,以便在Tracer检测到需要时自动更新软件包、重新启动过时的服务并重新启动虚拟机

调整systemd解析的配置以不再向世界公开LLMNR端口5355,而无需。

通过调整内核命令行并重新创建GRUB配置以使更改生效,将Docker的cgroup降级为v1。

克隆一些包含docker-compose网站项目的Git存储库,并使它们与上游保持最新。

启动多个基于docker-compose的服务,并在其底层Git克隆更改时让它们进行重建和重新启动。

我开始阅读官方的无代理Salt:入门指南,但很快就卡住了。我想以非特权用户的身份执行,但是尽管详细遵守了教程,我还是收到了无法写入/var/cache/的错误-出于很好的原因-如下所示:

#salt-ssh';*';test.ping[错误]无法呈现花名册文件:traceback(最近一次调用):[..]。权限错误:[错误13]权限被拒绝:';/var/cache/salt/master/roots/mtime_map';

虽然文档使用的是绝对路径,如/home/volant/salt-ssh/Everywhere,但我希望在任何地方都能与Git存储库一起使用的相对路径,更不用说教程中的log_file需要是ssh_log_file。

过了一段时间之后,所有这些都解决了,这个最小的设置就满足了所有这些要求:以非特权用户身份执行、在root_dir:.帮助下的相对路径、通过state_output_diff:true显著降低噪音的输出,以及开始添加类似剧本的内容的位置。鸟瞰:

#树。├──Master├──Column│:├──data.sls│:└──top.sls├──花名册├──SALT│:└──setup.sls└──saltfile。

有了它作为基础,我现在可以将剧本移植到一个新文件salt/setup.sls中。

例如,让调整Open SSH服务器配置以了解我的公钥(我将存储在salt/ssh/files/Authorized-key-root.txt),禁用基于密码的登录(以防止暴力登录尝试),并确保服务器使用调整后的配置:

Ssh-daemon:#为根ssh_auth.Present设置SSH公钥:-user:root-source:salt://ssh/files/Authorized-key-root.txt#禁用基于密码的SSH文件登录。keyvalue:-name:/etc/ssh/sshd_config-key:PasswordAuthentication-value:";no";-分隔符:";";-unComment:";#";-要求:-ssh_auth:ssh-daemon#重新启动sshd服务以应用配置服务中的更改。运行:-name:sshd-reload:true-watch:-file:ssh-daemon。

#sal.ssh';*';test.ping#salt-ssh';*';grains.item#salt-ssh';*';state.Apply setup test=True#salt-ssh';*';state.Apply setup。

我大概花了一天半的时间把整本剧本搬到盐湖,并对结果充满信心。它给我带来了什么?

显著缩短运行时间:从使用Ansible的3-4分钟降至使用salt-ssh的约1分钟。

在状态依赖关系和执行顺序方面有更大的灵活性(但也有一定的责任

能够在攻略(状态文件)中正确使用JJJA模板,这与Ansible不同。

我认为这是公平的说,我现在认为我自己是一个盐-ssh的皈依者:新的设置不再是我所能接受的,而是salt-ssh。

我真正希望的是SaltStack在修复错误方面做得更好。我在3001.1版本中遇到的所有问题和限制都与我认为足够主流的功能有关,考虑到社区的规模,我甚至不应该看到这些功能。

我希望这些不是SaltStack结构性问题的迹象。VMware在2020年9月收购了SaltStack,所以我希望这会是最好的结果。一旦我确信我不会浪费时间,我很高兴能帮上忙。

有关使用Salt-ssh取代Ansible的更多信息,您可能会对Duncan Mac-Vicar P.;的文章“像Ansible一样使用Salt”感兴趣。