自动化运维落实到位的三点基础及常用工具对比
Salt类似Ansible,因为它也是基于CLI的工具,采用了推送方法实现客户端通信。它可以通过Git或通过程序包管理系统安装到主服务器和客户端上,客户端会向主服务器提出请求,请求在主服务器上得到接受后,就可以控制该客户端了。这四款自动化运维工具网上的比较很多,但是很难说谁就一定比谁好很多,还是那句话,你的团队具有哪方面的人才就使用哪个,如果非要选出一个我个人推荐ansible,因为基于python实现,开发人员比较好找,同时社区资源活跃,相关的资源和组件也是比较丰富的。 第三种思路是采购市面上商用的自动化运维平台,这种思路对于很多甲方公司还是很现实的一种方案。对于这种思路,需要采购方切实梳理清楚自身的需求,整理出自己真实需要的自动化运维场景。这里的建议是,在选择商用自动化运维平台时和平台销售方协商好以下三件事,一是甲方结合实际工作中遇到的自动化运维场景,把需要马上满足的自动化运维场景梳理出来,作为第一个模块,即确定要完成的功能模块;二是要求平台销售方提供自动化运维工具的编写接口,并支持shell和python两种语言,这个要求是考虑到后续有些运维场景开始没有考虑到,或者新增了一些场景,自己的人员可以自行通过编写脚本在这个平台上实现;三是要求平台销售方对于产品层面积累的已有的运维场景实现要提供给采购方,并且支持后续当产品有新运维场景更新时,要免费提供给采购方使用。 五、云平台的自动化运维该是什么样的 目前云平台还是比较热的一个话题,最后这个章节主要来聊下私有云iaas和paas平台的自动化运维该是什么样的。先说iaas平台,iaas平台主要涉及计算、存储、网络、安全这四大块(图五)。 图五 计算资源应该是分为几种固定的规格(计算密集型/io密集型/内存密集型),这些规格由开发和运维团队协商定制。没有特殊情况下,无论是谁申请都不会新增新的机型,同时计算资源无论是开发人员自助申请,还是开发人员通过运维人员申请,申请完以后系统的初始化环境应该是已经自动完成的,这里的初始化环境包括并不限于IP地址、内核参数、文件目录结构、计算机名称、磁盘卷挂载等。 存储资源,要能够做到容量预警和扩容提醒,当触发容量预警需要扩容时能够通知到存储管理员,同时存储管理员提出扩容需求和方案后可以通过流程平台通知到存储采购人员,并进行采购动作。在存储资源的服务能力方面,最佳情况是同时具备块、文件和对象存储能力,这样才能满足云环境下的应用需求,尤其是对象存储现在越发受到重视,笔者举一个小例子,由于经过前面的标准化要求,每台云主机的文件目录结构都是统一的,那么当应用程序需要进行文件操作的时候,使用基于S3协议的对象存储就很方便,免去了通过nfs或者smba进行盘挂载的方式,使用nfs或者smba进行挂载的方式会额外增加运维人员的维护成本,并且差异化也是与自动化运维的标准化理念相违背的。实际情况是,笔者发现现在很多传统行业还是在使用nfs挂载的方式把文件提供给应用程序使用,其中的痛苦大家也都体会过,所以现在也开始逐步进行迁移改造工作。 网络资源,理想的iaas云平台网络资源首先要能够提供多种虚拟网络设备,例如路由器、交换机、4/7层防火墙、4/7层负载均衡和ip资源池管理等,其次这些虚拟网络设备不但要能够在管理界面创建,同时还要能够支持api调用,能够通过代码进行管理。 安全资源,云平台上的安全资源主要是指安全组能力(防火墙放在了网络资源里),通过安全组可以将不同租户的主机进行隔离,在小公司甚至可以通过安全组在一个云平台上隔离出来测试环境、预部署环境和生产环境,这样就大大降低了基础设施的成本。 在paas平台方面,根据笔者实际经验,目前主要是两块应用的比较多:一块是基于容器和ci/cd进行狭义的devops流程来适配当下很火爆的敏捷开发;另外一块是提前定制好一些中间件资源(这里主要是消息队列、缓存、分布式锁等),来供开发人员直接使用,这些中间件资源可以是基于虚拟机定制好的模板,也可以是基于容器技术制作好的镜像。无论是iaas平台的自动化运维还是paas平台的自动化运维,要想实现自动化,各个资源类型提供相应的api是必不可少的,只有提供了api,我们才能够将其代码化,从而自动化,否则很多场景还是摆脱不了人工手动处理的窘境,人工参与的场景越多,出错的概率也就越大,距离理想的自动化运维也就越远。 六、总结 本文从五个方面对自动化运维做了一个介绍,其中很多场景也是笔者根据实践经验对一线互联网公司和传统行业的做法进行了对比阐述。最后,我再强调一下我认为的自动化运维的理论内涵和外延:对于非业务的功能性需求,在提供端到端交付的过程中能够尽量的全自动化。 【编辑推荐】
点赞 0 (编辑:济南站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |