關於自動化配置還有什麼好說的呢？

最近咱們團隊正在將生產環境的配置進行自動化。簡單地說就是使生產環境在任何地方均可以快速的搭建起來，好比程序員在本身的機器上，公司內部的機器上，還有云上。

本文就是想闡明爲何要自動化配置。

進行配置自動化的這個過程，我發現，問題不在於程序員懂不懂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。

這是個人我的觀點，歡迎反駁。