3P 你需要知道的事
站在运维自动化的角度看3P
希望你没有被标题吓到,这里说到的3P,并不是大家想象的那样.
在运维界的早期,有这么一种声音,掌握了3P,你就掌握了运维的全部.
好吧,说的有点夸张.
3P 是 指 PHP PERL PYTHON
我的3P发展史
从2012年正式入职运维行业以来,我所接触和自我感知的运维自动化概经历了以上的4个变化.bash->php->perl->python. bash并不需要多言,一入运维就必须要熟练掌握的基本语言.不是因为他是多么的高深,而是bash确实能够快速的解决一些基本的问题.备份/重启等对我们来说,也是信手拈来.其实bash能解决运维工作中的60%-80%的工作.要解决的问题越复杂,编写bash所花费的时间和代价太高,我有时候也想,为什么bash不能像其他的语言一样形成自己的独立模块,能写web,也能做其他语言也能做的事情?
PHP
我的php处女座之旅
2012年期间,国内那时候,什么公有云,私有云并没有正式进入市场.公司当时所有的产品全部托管在机房.那是在北京/天津/广州都有自己分属的机房,每个机房大概有70台服务器,当时的架构比较简单.通过DNS负载到不同地方的机房.
由于业务的发展,每隔1-3 个月可能要去机房上架机器,然后pxe安装系统,回到公司拿着execl一个个录入新装机器的基本信息,比如机柜位置,交换机信息,网络信息,硬件的基本信息等等.每次安装和核对,要耗费大量的时间和精力.当时我们使用的是传统的execl来记录这些机器信息,然后通过VSS(Visual SourceSafe)管理.
这是一款很老的版本管理工具,老程序员应该对这款工具比较熟悉,.我们用来作为团队协作管理各种文档信息,其中就包括机房的机器信息.
回归到正题上来,随着机器的数量增多以及机器信息的列内容越来越多.用execl来维护这些机器信息越来越不方便,不管是查找机器还是录入机器信息,都是非常的麻烦.基于以上的问题,生出很强烈的想要做把资产信息做成web和可视化.这样的话看起来应该高大上一些,同时管理资产信息也很方便.那时候并没有devops和cmdb的概念.同时我们部门就2 ~3 个人,大家也并不懂开发.于是这我就慢慢摸索踏入编码的不归之路.苦学html/js/css,然后接触php.最开始接触PHP是因为当时我们业务用到一款工具,名叫sugarcrm,这是一款客户关系管理,用php写的.当时经常帮开发修改配置,慢慢自己对它的套路也熟悉了,进而自研.
早期自己独立写的一款入门级别运维资产管理系统: https://gitee.com/lookingdreamer/AutomationManagement
大概长这样:
算是自学编程的处女座,现在回过头来看,代码规范什么写的很乱,只能将就着看了.多说一句作为运维开发的角度构建逻辑思维,再到构建代码框架,到调试静态页面,一步步过来确实能收获很多的感受.在接下来的几遍document我将分篇幅分享一下.重点说一下从运维的角度构建产品逻辑以及实践当中遇到的一些问题.
PERL
基于名字服务的自动化平台(perl)
先上代码:
基于名字服务的自动化平台 https://gitee.com/lookingdreamer/RexDeploy_v1
凡是做运维的,有点思维能力的同学.总是想着偷懒.凡是一件事情做了两次以上,你都可以通过自动化的手段来解决它.
所以就开始折腾开源工具,什么chef,Puppet,ansible……,才进入公司的时候.那时候采用的Puppet管理hosts文件等配置文件,并没有对它进入很深的研究.然后一不小心跌入perl语言的构建自动化的深坑,这其实是一个意外.大概是在2014年,正式接触了开源,也是通过红薯的(大家的)开源中国开始了解开源的一些事情,那时候有一些开源软件的录入,但是在运维自动化行业,甚至运维行业,确实难以找到可以借鉴的软件.那个时候,运维方面的突出的开源确实是少的可怜.无意中看到开源推送的一款基于perl语言的自动化框架,然后了解了一下,然后就一发不可收拾.
PYTHON
一站式运维全平台的开源解决方案
基于时间原因,代码暂不开放.
上一张Project图:
基于运维痛点的认知,基于工作当中或者运维当中可能遇到的常态问题自动化.所有的自动化的并不是盲目的去做去开展.只有真正的去嵌合你的业务发展,才是好的自动化.真正的做到效率的提升.
划重点、总结
PHP是最好的语言
O..0 我就随便说说,运维行业用的php来构建自动化的很少.不少行业,用它来直接构建前端,因为php的成熟高,我们在构建的运维自动化的时候,并不想花很多时间浪费在前端界面上面.php一开始就存在这个先天的优势.但是也还是有一些用php构建后台或者中间接口的.比如现在的腾讯云的API接口,腾讯开源的tars以及腾讯开源的蓝琼,linux-dash等. 不选用php作为运维自动化的估计很大的原因是因为安全问题,运维在很多的时候需要调用的底层的系统命令,一旦开放php的exec权限,风险也是大大的.二是性能问题,在处理的批量文本或者字符等在一般情况下的效率确实不是很完美.当然也有一些的很不错的php的替代方案,我这里也不做过多的阐释,纯自己的个人见解.
PERL 是落寞的过客
老骥伏枥 志在千里 烈士暮年 壮心不已
这也许是perl最真实的写照,曾经也许辉煌过,但如今早已沉浸在历史的长河里了。在python还么这么火,AI和机器学习还么兴起的时候.perl 有着最强大的模块库,精炼、复杂、表现力强.但是正是这些阻碍了它的发展,没有规范、可读性、整洁性和可维护性较差,导致它很难发展起来.也没有强大的社区去推进和改善.在国内估计也就在扶凯的博客能见到一些见解和教程.一门语言要想得到发展,在入门这一层级就被拦住了,更何况往前发展了.
PYTHON 人生苦短 我用PYTHON
时代在往前走,大的方向和前提下. AI、数据统计、机器学习…..使得PYTHON得到大力的发展.不可否认的是,PYTHON确实有它的很多优点.优雅规范、简洁明晰、易学易用、类库丰富……在运维行业也是如此,如ansible、saltstack等,基于此也衍生出很多的优秀的python写的运维工具或平台.强大的社区和文档,入门门槛也相对很低,所以它的发展也是很快的.(没有千千万万的人民群众支持,任何语言它也是发展不起来的)
PHP PERL PYTHON 做自己该擅长的事情
对于中小公司来说,如何快速的构建合适自己业务的自动化平台才是最重要的.至于使用什么样的语言,什么样的方案那都是仁者见仁智者见智了.还有大公司的解决方案和产品并不一定会适合你.你需要考量的会有很多,比如入手难易程度、业务规模、入手成本等,就是说你投入的产入和产出是不是相匹配的?再一个就是说中小公司一般的运维的人员不多,但是做的事情却很多很杂,既要对公司内部负责,也要对生产的运行环境负责.你既要合理的安排时间,也要合理的让自己的工作更加有效率化.
以下建议仅供参考
快速构建前端 首选PHP
快速的工具文化首选Perl 当然PYTHON也可以
构建大型的运维devops平台推荐PYTHON
开放 是一种声音
可能在几年前,很少有听见运维在发声.运维这个角色,很是默默无闻的.似乎感觉不到它的存在.反正就是没有存在感，有存在感的时候，反而是背锅侠的名称一直源远流长的(我总想起: 运维从删库到跑路 
为什么说开放?
这个词可能说得有点大,简单的说，一个人的见解毕竟是有限的，只有大家共同发声。一起分享和开放，行业整体才能更加的往前进步.守着自己的一亩三分地,永远也难以突破自己的局限.
想要做自己力所能及的改变
你是否有着一样的运维痛点？
运维的从事工作很泛，小到PC电脑，大到生产运维。工作中会遇到各种各样的问题，其实大家都可能会遇到一样的问题.既然你躺过坑了，其他的人又同样的在上面在踩过一样的坑.为什么没有一致的解决方案?
持续集成是突破点,但是作为中小公司我该选择谁？
相信很多中小公司的运维大部分的工作，都聚焦在版本的发布上面.同时版本发布也是打通的开发、测试、运维的桥梁.涉及到自动发布、流程管理等等各个方面.作为中小公司自研持续集成平台,不太现实.所以开源也许是你的最好选择,比如使用jenkins构建持续流水线、比如最近腾讯的开放的蓝鲸平台、比如walle的web部署系统……………………. 等等,还有很多很多的选择.选择一多，困扰我们的问题就来了，我们该如何选择？
很多相似的问题，为什么没有统一的开源解决方案？
从事运维无非会接触以下,为什么没有的一致的开源整套解决方案？
- 基础设施 (比如物理机、虚拟机(kvm/vmware/xen))
- 持续交互
- 流程管理
- 监控报警
- 各种云平台
- ………………
当然有一些厂商有一揽子的解决方案,奈何中小企业,比如创业公司,可能是开发人员顶替运维,公司的发展前期并不重视运维方面的问题.更不会投入很大的成本去做这些事情,为了快速的抢占市场,先把产品快速迭代出来才是王道.等到规模上来了,再去考虑稳定性等方面的问题.当然这也不是不行,如果在运维方面,有对应的标杆去快速实践，应该又是另一方面的景象.当然了,没有利益驱动的开源，很难以长久,这又是另一说了.你说运维不重要？应该么人会这么说？更加重要的的是,你说从事的运维技术是否真正的为你的业务产生了价值？
好了,暂时先到这儿吧! 继续码代码去了……