SaltSack自动化运维（13）——ssh模块（免客户端方式的部署和实施）

1.Salt SSH 介绍

在之前我们一直围绕着需要在受控端安装 Minion 的前提下进行架构扩展
那么如果在实际的环境中，由于某些限制无法在受控端服务器安装 Minion 客户端，该怎么办呢？
Salt 在版本 0.17.0 当中，引入了新的传输系统，它支持通过 SSH 通道来实现 Salt 的通信
通过这种方式，我们可以直接通过 SSH 通道在远程主机上执行使用 SaltStack
而不需要在远程主机上运行 Salt Minion ，同时又能支持 SaltStack 的大部分功能，而且 Salt Master 也不需要运行了
这样，也就实现了免客户端方式的部署和实施
但是由于无客户端本身的局限性 Salt SSH 并不能完全取代标准的 Salt 通信方式，只是简单地提供了一个基于 SSH 通道的可选方式
这种方式不需要 ZeroMQ 和远程 Agent 的支持；整体的工作流程和基于客户端架构大致相同
但必须意识到，通过 Salt SSH 的执行速度会远远低于 ZeroMQ 支持的标准的 Salt 通信方式
因为在实际的生产环境当中，如果只有个别主机不能安装minion，没有必要再部署ansible，这样saltstack和ansible就重叠了
这个时候就可以使用saltstack的ssh了

2.具体的实现过程如下

（1）关闭server2上面的minion服务

（2）在server1上安装 salt-ssh

传统的 Master 和 Minion 的架构中，Minion 会主动连接 Master，所以 Master 不需要手工配置目标系统的信息。
但是使用 Salt SSH，控制服务器就需要这些。SaltStack 使用 Rosters 来管理这些数据。
Roster 系统为可插拔设计，可以非常方便地加入到已有的系统中，用于 Salt SSH 获取需要连接的服务器信息
默认情况下 Roster 文件本地路径为：/etc/salt/roster
Roster 系统编译了一个内部数据结构，称为 Targets
Targets 是一个目标系统和关于如何连接到系统属性的列表
对于一个在 Salt 中的 Roster 模块来说，唯一要求是返回 Targets 数据结构
（3）进行ssh配置

写入server2主机的信息

（4）测试：saltstcak可以使用ssh模块来远程控制没有安装minion的主机
第一次运行 Salt SSH 会提示进行 salt-ssh key 的部署，需要在 Rosters 中配置用户的密码，即可进行 Key 的部署
当部署过 Key 之后，后期再执行 Salt SSH 就会通过密钥认证，不需要用户再输入密码了


（5）为了接下来的实验，我们再将minion开启

总结一下
在实际的生产使用中，建议将传统的 Master、Minion 和 salt-ssh 一起使用
比如我们可以使用 salt-ssh 来进行 Salt Minion 的升级，可以使用 salt-minion 来实现 salt-ssh 的自动化部署等
这里我们来介绍如何基于现有的 Master、Minion 架构自动构建 Salt SSH 环境
经过上面对 Salt SSH 的介绍，相信大家已经知道要实现 Salt SSH 架构需要两个重要的步骤
（1）生成 Rosters 配置文件。
（2）把密钥放置到 Salt Minion 上。

针对这两个需求，我们可以使用下面的方法进行实现。
使用 salt-mine 实现 Salt Rosters 文件的自动生成。
使用 Salt 的文件状态模块管理 Minion 上的 authorized_keys。
本质是将 ssh-key（注：第一次执行 salt-ssh 添加主机时会生成，默认存放在 /etc/salt/pki/master/ssh/salt-ssh.rsa.pub 的公钥）
写入到用户主目录 .ssh/authorized_keys 文件中。