加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码网 (https://www.900php.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 搭建环境 > Windows > 正文

自动化运维落实到位的三点基础及常用工具对比

发布时间:2019-03-13 17:34:41 所属栏目:Windows 来源:王洋
导读:副标题#e# 当你把自动化运维这个话题抛给不同的角色,他们的反应也一定是不一样的,程序员眼中的自动化运维可能是可以自助申请资源,可以点点点的进行应用发布;应用运维人员眼中的自动化运维可能是自动的监控每个应用的状态有简单的问题就按照约定的动作去

这一部分,我们来聊下自动化运维与流程管控的关系。我们知道,运维工作中的任何一个需求的执行都是有相应的流程在进行管控的。如果自动化运维的动作没有流程来进行管理,那么自动化做了哪些运维工作,为什么要做这些运维工作,是谁做了这些运维工作,对于管理员来说如果都不知道或者不可查,那就太恐怖了。ITIL的规范里面也对流程管控有很详细的描述,但是根据笔者了解到的情况,在实际企业中,尤其是业务变化比较快的企业能够完全按照ITIL流程来的还真是少只又少,ITIL流程还是比较重的,针对ITIL流程做裁剪来适合企业自身情况这才是正确的方式。在流程管控方面,传统行业无论是用了ITIL还是没有用的,目前都存在以下几个问题:

一是流程不完善,即流程还是欠缺的不能完全覆盖所有场景;

二是流程完善了,但是没有全部系统化;

三是流程完善了,系统化也有了但是流程没有串起来,还都是一些孤立的点。

以上三种场景都很难对流程做出较强的管控,好的流程管控,应该这样做:

第一步结合工作的实际情况梳理出我们需要做流程的场景,这一步可以首先让每位同事把自己认为需要做流程管控的场景梳理出来,作为总的一个需求池,然后通过开会讨论的方式将需求进行合并或者是去重,经过这样一个过程,产出物是一个需要做流程管控的文档;

第二步针对第一步梳理出来的文档,标注出每一个流程中最关键的点,这个点称之为要素点。例如新购机器上架这个流程里,包括送达机房,签收,上架前准备,上架并加电,更新已上架设备信息等几步,在这个流程中,上架并加电是最核心也是对后续实际使用最有影响的一步,那么这一步就成为要素点;

第三步就是针对第一步梳理出的流程,找到流程之间的衔接点,这也是为了解决流程孤岛的问题。在这一步中如果发现有不能连接在一起而断层的流程,就需要在这一步解决。

第四步就是系统实现了,这一步无论是自研实现还是外包实现,都需要考虑的一点是如何与现有的自动化运维系统以及资源管理系统进行对接,因为流程的管控过程肯定会涉及资源的生命周期管理,这里的资源可以是实实在在的物理资源,例如服务器、防火墙、路由器和交换机等,也可以是软件资源,例如安全策略,4/7层的负载均衡等,这样的流程管控平台就涉及到与cmdb、云平台和容器平台等的对接工作,这一步一般是比较消耗精力的,倒不是说这里的技术难度有多难,而是这里一般都涉及接口的调试工作,如果这些系统都是自研的系统,那对接起来的难度可能还低些,毕竟都是自己公司的团队,如果涉及到与外购系统的对接,这里的时间周期就很难控制了,根据笔者经验,这里如果是与外购系统对接,每个系统最好预留1个月的时间。

第五步就是流程管控平台上线后的与自动化运维平台磨合和优化的阶段了。在这个阶段,要留意观察自动化运维平台、资源平台与流程管控平台的数据交互是否正常,这里可以引入敏捷迭代的方式来及时处理问题(图四)。

图四

四、实现自动化运维常用的工具对比分析

各位看官,在这个阶段我主要介绍下实现自动化运维工具的三种理念,为了严谨期间说明下这个环节说的自动化运维工具是要是指x86服务器层面。实现自动化运维工具的三种理念:

第一种是完全自研,例如阿里巴巴集团的所有物理机上都安装有一个久经考验并且功能强大的代理staragent,阿里巴巴集团所有物理机在系统初始化的时候就安装了这个staragent,直到生命周期结束,这个startagent才会被卸载。这里有个问题就是,不是所有的公司都能像阿里巴巴一样自研一个功能非常强大的agent,因此就有了第二种和第三种理念。

第二种理念是使用市面上已有的自动化运维工具,并基于这些工具做成自动化运维平台。目前市面上常见的自动化运维工具主要有以下几种,Puppet、Chef、Ansible和Salt,下面对四种产品做一个对比介绍:

Puppet应该是市面上使用最多的,就操作、模块、界面而言,它是最全面的,Puppet呈现了数据中心协调的全貌,为各大操作系统提供了深入的工具,初始设置简单,只是需要加以管理的每个系统上安装客户端代理软件,CLI简单直观,允许通过puppet命令下载和安装模块,你可以对配置文件进行需要的修改,让模块适合所需的任务,接到指令的客户端与主服务器联系时,会更改配置文件,也可以是客户端主动与服务端通信来获取到最新的配置文件,还有一些模块可以提供和配置云服务器实例和虚拟服务器实例,所有模块和配置都使用基于Ruby的Puppet专属语言或者Ruby本身构建而成,因而除了系统管理技能外,还需要编程专业知识。

Chef的总体概念类似Puppet,因为在被管理的节点上安装代理软件,但实际部署又不一样。除了主服务器外,安装的Chef环境还需要工作站来控制主服务器。代理软件可以借助使用SSH来部署的knife工具从工作站加以安装,减轻了安装负担。被管理的节点通过使用证书,完成与主服务器之间的验证。与Puppet一样,Chef得益于一大批的模块和配置菜谱,那些模块和配置菜谱又高度依赖Ruby。由于这个原因,Chef非常适合注重开发的基础设施。

Ansible极其类似Salt,而不太类似Puppet或Chef,Ansible关注的重点是力求精简和快速,而且不需要在节点上安装代理软件也可以选择安装。Ansible能通过SSH执行所有功能,Ansible基于Python开发对于熟悉python的人而言是一大福音,并且是由红帽进行运营。Ansible可以从命令行来运行,不需要使用配置文件。至于比较复杂的任务,Ansible配置通过名为Playbook的配置文件中的YAML语法来加以处理。Playbook还可以使用模板来扩展其功能,目前playbook的模板还是非常丰富的。

(编辑:源码网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读