关闭

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

标签: Ansible远程部署应用传统部署方式自动化运维工具部署适用场景
1700人阅读 评论(2) 收藏 举报
分类:

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

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

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

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

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

上述传统部署方式缺点:

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

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

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

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

从表格我们看出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部署的优劣。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:8181次
    • 积分:121
    • 等级:
    • 排名:千里之外
    • 原创:3篇
    • 转载:0篇
    • 译文:0篇
    • 评论:6条
    文章分类
    最新评论