远程服务器部署应用(一)--传统部署方式还是自动化运维工具部署？

接触自动化运维工具也有半年了，就此做一个总结。如果有不妥之处，欢迎各位牛人批评指正。

到底该不该放弃传统的服务器脚本部署或者手动部署方式，投入自动化运维工具的怀抱？

虽然现在使用自动化运维工具已经成为主流趋势，但是对于一个之前都是采用传统方式部署代码，又没有相关专业运维人员的项目组而言，这确实是一个比较头疼的问题。到底该不该转身投入自动化运维工具的麾下？如果投靠，又该选择哪个部落？如果投靠该部落，又该选用部落提供的哪项技能傍身？

首先，我们通常会选择以下几种传统部署方式：

• 纯手工 scp 或者用脚本
• 纯手工登录服务器 git pull/svn update
• 纯手工 ftp 上传
• 开发提供压缩包，rz 上传，解压

上述传统部署方式缺点：

1. 全程运维参与，占用大量时间
   （而小公司而言，一般都是开发人员开发完之后直接上传部署，别问我为什么知道。。。）
2. 上传速度慢
3. 人为失误多，管理混乱

---

而且这种方式部署，一般只能是固定一个人来完成。如果换其他人，因为部署流程比较复杂，上手慢，而且综合考虑，服务器上的应用都是已经上线的产品，新人部署，不确定因素过多，主管一般都不太放心。所以我们就考虑能否有一个自动化的工具：

• 简化部署流程：节省时间，就算人员变动也不妨碍代码部署。
• 学习成本低：太复杂的语法，学起来太耗时。
• 部署模式：最好不是C/S模式管理，便于扩充管理的服务器。
• 远程操作：暂时不考虑custom，默认batch吧.
• 后期维护：修完bug后，希望最快的速度部署到各台服务器上。

话说现在市场上的主流自动化运维工具确实很多，puppet、chef、ansible、saltstack。这里做了一个简单的比较：

从表格我们看出puppet、chef是出道时间比较久的王牌，使用老牌Ruby语言编写，可以看出配置管理方面应该支持比较全面。相对而言，ansible、saltstack就比较年轻了，但是这两个新秀都是目前的宠儿，论坛、开发社区都比较活跃，也是比较有前景的。最重要的是，我看到了ansible的闪光点：
红圈圈有没有看到！！no agent!!简直大爱！！

Ansible呢是基于模块工作的，本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块，ansible只是提供了一种框架。它的特性包括：

1. no agents：不需要在被管控主机上安装任何客户端；
2. no server：无服务器端，使用时直接运行命令即可；
3. modules in any languages：基于模块工作，可使用任意语言开发模块；
4. SSH by default：基于SSH工作；
5. 使用python编写，维护更简单，ruby语法过于复杂；
6. 支持sudo：（这个真的很有必要，当你发现无论操作什么都 要root权限的时候，你会崩溃的，关于root权限，各个公司为了安全着想，别想了，非相关人员，你是get不到的）
7. 执行：并行执行任务。执行批量任务的时候可以写成脚本，而且不用分发到远程就可以执行。
8. 不占master任何资源：没有守护进程。

---

Ansible的特性完美解决了我们的问题，确实，针对中小型企业，如果只是管理几十至几百台服务器，并且不需要使用到太复杂的配置管理功能，这个足够了。
具体的Ansible的介绍可以参考这里：Ansible documentation 传送门。
今天就到这儿了，下节，我会用实例给大家比较一下传统用脚本部署和Ansible部署的优劣。