文档章节

关于自动化配置还有什么好说的呢?

翟志军
 翟志军
发布于 2016/08/13 14:52
字数 1811
阅读 8652
收藏 80

最近我们团队正在将生产环境的配置进行自动化。简单地说就是使生产环境在任何地方都可以快速的搭建起来,比如程序员在自己的机器上,公司内部的机器上,还有云上。

本文就是想阐明为什么要自动化配置。

进行配置自动化的这个过程,我发现,问题不在于程序员懂不懂Ansible、Chef、Puppet这些自动化配置工具的使用。

问题在于对“配置”本身的理解。我甚至发现还有运维人员也不能理解为什么要将配置自动化。

配置是什么?

很多人都将搭建Tomcat、Nginx这类脚本理解成一个个“任务”。这类脚本还不能被称为“配置”。

而这类Tomcat、Nginx的安装脚本大概是这样:

apt-get install build-essential
apt-get install libtool
cd /usr/local/src
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.37.tar.gz
tar -zxvf pcre-8.37.tar.gz
cd pcre-8.34
./configure
make
make install
.....

脚本来自:http://www.nginx.cn/install

运行这类脚本时,大脑里的概念是:我要“安装”Tomcat、Nginx。这类脚本被当成“动词”存在。也就是说在面对一台机器时,我们的思维方式是:我要写一个if来判断Tomcat是不是已经安装,如果没有安装,就是执行apt-get install,blabla……

但是,现实的自动化配置工具Ansible、Chef、Puppet告诉我们,自动化配置的脚本更应当充当机器环境的状态的描述文档。也就是面对机器时,我们应该使用“形容”词。什么意思呢?来几个配置体会下:

Ansible:

    # ./ansible-nginx/tasks/install_nginx.yml
    # 使用这个7-0.el7版本的yum包 
    - name: NGINX | Installing NGINX repo rpm
       yum:
       name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

    # 当前机器的nginx的状态应该是最新版本
    - name: NGINX | Installing NGINX
       yum: 
       name: nginx  
       state: latest

    # 当前机器的nginx service的状态应该是已经启动的。至于如何确保nginx这个service是如何启动的,我们不需要关心。
    - name: NGINX | Starting NGINX
       service:
       name: nginx
       state: started
  

配置来自:https://www.nginx.com/blog/installing-nginx-nginx-plus-ansible/

篇幅有限,我们就只举Ansible的例子。

配置的本质

相信很多人看了上面的例子,还是一脸懵逼( ¯ □ ¯ ) ,下面来个现实例子。

现实中,我们组装一台台式电脑,你会这样对装机人员描述:我要4G内存,我要1T的SSD等等;而不是:我打开机箱,找到内存插槽,将4G内存插上,再把1T的SSD插入机架,接着把线接好 blabla。

我们作为需求方时,我们只需要描述需求。作为实现方时,我们需要根据需求执行相应的动作。

而配置更像是一份对目标机器(不论多少)的状态需求,我们作为需求方,只要在配置上写清楚目标机器的状态,至于这些状态最终是怎么达到的,由Ansible、Chef、Puppet这类自动化配置工具(实现方)实现。

也就是说,配置这个概念帮助我们程序员、运维人员更容易站在需求方的角色去思考问题,而不是实现方。

问题来了?那有什么用呢。

**配置解放了我们的双手,使我们有更多的时间去思考更高层的问题。**这是最大的好处。

其它好处还有:

  • 配置可以将配置和机器进行解耦,同一份配置可适配不同的操作系统。也就是拿着这份电脑配置清单,我们去不同的商家去对比价钱。内存可能来自A商家,SSD可能来自B商家。
  • 配置可以重复使用,这也就是为什么可以自动化的原因。新来的程序员很容易就可以搭建好一个与线上生产环境配置一样的开发环境,来节约培训成本。
  • 可对配置进行更好的版本控制。也就是当前机器的状态,由谁,什么时候修改的,完全可控。不会出现报怨:这是谁干的?什么时候加的这个脚本。
  • 可很轻松的查清当前机器的状态。哪些机器安装了什么,使用了什么nginx配置,一目了然。而不需要程序员专门跑去询问运维人员,当前生产环境是怎么配置的啊,我们在本地重现不了问题。

在现实中,对于“自动化”,我听过最多的话是:我们机器才3台,没有必要使用这些自动化配置工具。我觉得这不能成为不自动化配置的借口,原因有:

  1. 生产/开发环境不可能只部署一次,身边出现过这样的例子,因为机器坏了,然后花3个人天搭建测试环境。
  2. 再少的机器也会涉及线上和线下的环境一致性问题。想想你是不是遇到过,在本地怎么测试都不出问题,但是一到线上就问题一大堆,后来才发现原来是线上使用的另一套配置。如果你觉得不是问题,那么想想,项目的历史包袱就是由类似这些“环境问题”的小问题一点点积累起来的。如果机器少时候,不开始做,今后可能就要花数倍的成本去弥补。
  3. 节约运维成本,因为你不需要那么依赖于运维人员了(恐怕很多运维的同学不同意)
  4. 当业务成长时,我们需要上云了。可是,我们没有一个人完全了解当前的环境的情况。因为所有的修改都没有版本控制,今天一个人登上生产环境apt-get install abc,明天一个人登上去 sudo chown user:group … 最终,你一定会为之前的“随意”买单。

这些问题,在我身边或多或少的发生了。我听得最多的也是:自动化配置解决了什么业务问题嘛,技术是为了业务服务的。我想说:前人犯的错,我们为什么又犯一次?所以,我会一开始就自动化。

在2012年,美暴雨致亚马逊数据中心断电 Netflix等中断,Instagram也是其中受害者,看看他们的总结,Instagram这个月就5岁了,创始人跟你说说它都经历了哪些大事儿 [来自虎嗅网]:

输入图片说明

另外,我们有时也需要扮演实现方,因为自动化配置工具无法满足需求,就需要自己的写工具的插件,更甚至实现自己的自动化配置工具。

总结

  • 只有理解了"配置"的概念,才能更好的理解为什么Ansible、Chef、Puppet要这样设计。
  • 配置解放了我们的双手,使我们有更多的时间去思考更高层的问题。
  • 自动化配置是为了提升团队工作效率。
  • 配置也是需要版本控制的。
  • 未雨绸缪胜过做救火leader。

这是我的个人观点,欢迎反驳。

© 著作权归作者所有

共有 人打赏支持
翟志军

翟志军

粉丝 347
博文 76
码字总数 79851
作品 2
深圳
程序员
私信 提问
加载中

评论(16)

夜苍狼
夜苍狼
我也不说好不好,我觉得至少100台以上的服务器,在用这个吧
laudukang
laudukang
2016年9月14日10:05:13
独孤影
独孤影

引用来自“陈绍榕”的评论

唉,说实话你非常多因素没考虑,所以才会这么单纯,最简单说一个,如果是你上面那么简单的需求,我写个py的时间可能还比你配置快的多,而且自己写会更加灵活,更易于处理各类异常情况;其他因素我就不说了,我这边不上关键在于他们觉得没必要无所谓,

引用来自“翟志军”的评论

对了,你写个py两句代码是很快。但是那是因为你没有把学习成本考虑进来,你想像下你花了多少时间学习python和bash?
我们做管理时,也需要把这些学习成本、培训成本、招人的成本考虑在内。所以,从这些角度来看,我不认为写个py比我使用yml来配置来得速度快。
你应该问谁不会py,谈不上精通,普通的脚本应该人人都会吧。
乌龟壳
乌龟壳
用Docker(等容器技术)不就好了嘛,不用自己发明轮子
chunquedong
chunquedong
这个和“声明式编程”的思想比较像
翟志军
翟志军

引用来自“LongRaindy”的评论

不用自动化的人总能找到不自动化的理由,使用自动化的人也总能找到一定要自动化的理由。
问题不在于双方都有理由,而在于理由站不站得住脚 。
LongRaindy
LongRaindy
不用自动化的人总能找到不自动化的理由,使用自动化的人也总能找到一定要自动化的理由。
lanmingle
lanmingle
autoconfig jks shell 旧,autoconfig tc/jks docker 新
jeffsui
jeffsui
挺好,至少有人去思考自动化到底给我们 带来什么?期待有更深入的探讨。
陈绍榕
陈绍榕
解释一下,我并没有系统的学习过py,系统的学习也是这几天开始的,因为很多出名的开源项目都是Python写的,至少要能读的懂源码 架构;还有就是要跟上时代了,py国内还是非常多公司用的
即将三十,我不敢说我精通任何一项技术

超级奶爸 图片来源:http://www.imdb.com/title/tt0395699/ 回顾自己的技术成长之路,具体技术真心没有一样敢说精通,对于一个像我这样工作6、7年的人来说,实在有些难以启齿。 现在中国整个...

翟志军
2017/05/10
0
0
linux 运维管理平台 Ansible

ansible是个什么东西呢?官方的title是“Ansible is Simple IT Automation”——简单的自动化IT工具。这个工具的目标有这么几项:让我们自动化部署APP;自动化管理配置项;自动化的持续交付;...

kylin007
2016/09/29
39
0
当CMDB遇上Zabbix,工程师的幸福感提升?

本文来自OneOaaS微信公众号,http://url.cn/2HSrHMj 在Zabbix的使用过程中,自动发现(network discovery & low level discovery)堪称监控的运维利器。配置一个发现规则,即可将所有的机器纳入...

it你好
2016/09/29
0
0
学习自动化测试的一些总结

1.什么是自动化测试 自动化测试是测试思想的一个延伸,为测试工程师提供了一个“触须”,其行为可以看成一个工具,但是本质上自动化测试还是一种思想。 顺便提一句,狭义上的自动化测试指的就...

白一客
2017/05/18
69
0
如何在半小时搭建一个简单的日志分析平台?

人们常常说数据如金,可是,能被利用起的数据,才是“金”。而互联网的数据,常常以日志的媒介的形式存在,并需要从中提取其中的"数据"。 从这些数据中,我们可以做用户画像(每个用户都点了...

翟志军
2016/09/25
10.2K
11

没有更多内容

加载失败,请刷新页面

加载更多

微服务分布式事务实现

https://www.processon.com/view/link/5b2144d7e4b001a14d3d2d30

WALK_MAN
今天
2
0
《大漠烟尘》读书笔记及读后感文章3700字

《大漠烟尘》读书笔记及读后感文章3700字: 在这个浮躁的社会里,你有多久没有好好读完一本书了? 我们总觉得自己和别人不一样,所以当看到别人身上的问题时,很少有“反求诸己”,反思自己。...

原创小博客
今天
4
0
大数据教程(9.5)用MR实现sql中的jion逻辑

上一篇博客讲解了使用jar -jar的方式来运行提交MR程序,以及通过修改YarnRunner的源码来实现MR的windows开发环境提交到集群的方式。本篇博主将分享sql中常见的join操作。 一、需求 订单数据表...

em_aaron
今天
3
0
十万个为什么之什么是resultful规范

起源 越来越多的人开始意识到,网站即软件,而且是一种新型的软件。这种"互联网软件"采用客户端/服务器模式,建立在分布式体系上,通过互联网通信,具有高延时(high latency)、高并发等特点...

尾生
今天
3
0
Terraform配置文件(Terraform configuration)

Terraform配置文件 翻译自Terraform Configuration Terraform用文本文件来描述设备、设置变量。这些文件被称为Terraform配置文件,以.tf结尾。这一部分将讲述Terraform配置文件的加载与格式。...

buddie
今天
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部