（点击上方公众号，可快速关注）
来源：翟志军
链接：my.oschina.net/zjzhai/blog/732120
最近我们团队正在将生产环境的配置进行自动化。简单地说就是使生产环境在任何地方都可以快速的搭建起来，比如程序员在自己的机器上，公司内部的机器上，还有云上。
本文就是想阐明为什么要自动化配置。
进行配置自动化的这个过程，我发现，问题不在于程序员懂不懂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台，没有必要使用这些自动化配置工具。我觉得这不能成为不自动化配置的借口，原因有：
生产/开发环境不可能只部署一次，身边出现过这样的例子，因为机器坏了，然后花3个人天搭建测试环境。
再少的机器也会涉及线上和线下的环境一致性问题。想想你是不是遇到过，在本地怎么测试都不出问题，但是一到线上就问题一大堆，后来才发现原来是线上使用的另一套配置。如果你觉得不是问题，那么想想，项目的历史包袱就是由类似这些“环境问题”的小问题一点点积累起来的。如果机器少时候，不开始做，今后可能就要花数倍的成本去弥补。
节约运维成本，因为你不需要那么依赖于运维人员了（恐怕很多运维的同学不同意）
当业务成长时，我们需要上云了。可是，我们没有一个人完全了解当前的环境的情况。因为所有的修改都没有版本控制，今天一个人登上生产环境apt-get install abc，明天一个人登上去 sudo chown user:group … 最终，你一定会为之前的“随意”买单。
这些问题，在我身边或多或少的发生了。我听得最多的也是：自动化配置解决了什么业务问题嘛，技术是为了业务服务的。我想说：前人犯的错，我们为什么又犯一次？所以，我会一开始就自动化。
在2012年，美暴雨致亚马逊数据中心断电 Netflix等中断，Instagram也是其中受害者，看看他们的总结，Instagram这个月就5岁了，创始人跟你说说它都经历了哪些大事儿 [来自虎嗅网]：
![]()
另外，我们有时也需要扮演实现方，因为自动化配置工具无法满足需求，就需要自己的写工具的插件，更甚至实现自己的自动化配置工具。
总结
这是我的个人观点，欢迎反驳。
关注「数据库开发」
看更多精选技术文章
↓↓↓
![]()
