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

原创
2016/08/13 14:52
阅读数 1.8W

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

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

进行配置自动化的这个过程,我发现,问题不在于程序员懂不懂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。

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

展开阅读全文
打赏
8
80 收藏
分享
加载中
我也不说好不好,我觉得至少100台以上的服务器,在用这个吧
2016/12/17 21:42
回复
举报
2016年9月14日10:05:13
2016/09/14 10:05
回复
举报

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

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

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

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

引用来自“LongRaindy”的评论

不用自动化的人总能找到不自动化的理由,使用自动化的人也总能找到一定要自动化的理由。
问题不在于双方都有理由,而在于理由站不站得住脚 。
2016/08/16 09:52
回复
举报
不用自动化的人总能找到不自动化的理由,使用自动化的人也总能找到一定要自动化的理由。
2016/08/16 09:42
回复
举报
autoconfig jks shell 旧,autoconfig tc/jks docker 新
2016/08/15 14:41
回复
举报
挺好,至少有人去思考自动化到底给我们 带来什么?期待有更深入的探讨。
2016/08/15 13:17
回复
举报
解释一下,我并没有系统的学习过py,系统的学习也是这几天开始的,因为很多出名的开源项目都是Python写的,至少要能读的懂源码 架构;还有就是要跟上时代了,py国内还是非常多公司用的
2016/08/14 16:30
回复
举报
更多评论
打赏
16 评论
80 收藏
8
分享
返回顶部
顶部