SSH or Agent的技术选型？

Question

背景

目前项目中会使用了Iaas中的vm，所有操作都是通过ssh连上去的。pm表示要不要写个agent在里面用，现在每次操作都ssh一下都很恶心。

谈谈我认为使用ssh的好处：

• 代码集中在一处，不需要分发
• 不需要维护agent这么一个进程的生命周期，以及检测它的心跳

缺点：

• 不支持异步

我想问的问题

• ssh的开销大吗？在我看来似乎和写一个基于web server 的agent差不多
• 大家一般是如何选型的？为什么这么选？

Answer 1

背景
目前项目中会使用了Iaas中的vm，所有操作都是通过ssh连上去的。pm表示要不要写个agent在里面用，现在每次操作都ssh一下都很恶心。

谈谈我认为使用ssh的好处：
代码集中在一处，不需要分发
不需要维护agent这么一个进程的生命周期，以及检测它的心跳
缺点：

不支持异步
我想问的问题
ssh的开销大吗？在我看来似乎和写一个基于web server 的agent差不多
大家一般是如何选型的？为什么这么选？

这个东西以前做过类似的，也有过反思，甚至设计的原型和你说的一模一样。

例如，我为什么要用基于web server的agent呢，我干嘛不用tcp长连接到服务端，这样执行的结果可以流式传输到调用方，他那边显示起来比较平滑，不用每个命令执行完等结果。
但是我这样搞的话，中控端流量和日志存储就成了问题了啊。
如果我的业务都在云上，如果不同机房网络不互通的话，我又要蛋疼地搞点兼容的事情……
例如，agent的生命周期，为什么我要检测她的心跳呢？机器上万台的话，任何可能的事情都会发生啊，修复起来太蛋疼了。但是我不处理的话……所以后面我会考虑用ssh来修复agent啊。

我假设你所有的机器都是linux，发行版为同一种。

SSH：

1. 依赖于ssh的速度，一旦网络抖动，ssh操作便会失败。（低概率/风险）
2. 依赖于key，如果你安全策略不够严谨，或者管理比不严格的话，那么必然会造成root key的泛滥。（安全风险高）
3. 开源技术很成熟，你很容易就能用几行python包装出一个比较完善的脚本，或者写出一个ansible的配置。（用起来简单）

AGENT：

1. 依赖于中控端。如果你不打算搞个中控端，那和ssh没本质区别。
2. 其实和SSH一样，依赖于网络，一旦抖动也会出问题。
3. 保活。如果你的公司稍微大点的话，会有各种乱七八糟的原因能让你的agent不起作用，甚至被kill。虽然处理起来没啥问题，但是这个活总得有人来干。（低风险）
4. 维护。（成本中等）
5. agent其实可以不用中间代码，因为一方面工作量比较大，一方面教育成本和学习成本也比较高。只是向agent下发shell脚本、python脚本等也可以完成相同的功能，没问题的。

大公司有各种审计、安全方面的需求，会把这种事情统一到某个地方，搞个中控端，所有的批量操作必须通过中控端。模式也不一样，有些用agent，有些用ssh，只有中控端才是必须要有的。

再说的直白点，
你是个小公司，小于30台机器或者小于50台机器的话，不建议考虑agent模式。
没那个需求，投入的成本大而收效低。
基于各种第三方框架包装一个就好了嘛，嫌麻烦就ansible用起。

Answer 2

• 如果管理的OS都是同一类的，比如Linux，那么用ssh最简单了。
• 如果还有其他的OS，那SSH可能就不好使了，而agent可以一定程度上屏蔽掉OS之间的差异。比如puppet这类解决方案，实际下发的操作指令并不是实实在在在机器上执行的指令，而是一种中间代码，由agent将中间代码翻译成当前OS实际该执行的本地命令。