遠端伺服器部署應用(一)--傳統部署方式還是自動化運維工具部署？
接觸自動化運維工具也有半年了，就此做一個總結。如果有不妥之處，歡迎各位牛人批評指正。
到底該不該放棄傳統的伺服器指令碼部署或者手動部署方式，投入自動化運維工具的懷抱？
雖然現在使用自動化運維工具已經成為主流趨勢，但是對於一個之前都是採用傳統方式部署程式碼，又沒有相關專業運維人員的專案組而言，這確實是一個比較頭疼的問題。到底該不該轉身投入自動化運維工具的麾下？如果投靠，又該選擇哪個部落？如果投靠該部落，又該選用部落提供的哪項技能傍身？
首先，我們通常會選擇以下幾種傳統部署方式：
- 純手工 scp 或者用指令碼
- 純手工登入伺服器 git pull/svn update
- 純手工 ftp 上傳
- 開發提供壓縮包，rz 上傳，解壓
上述傳統部署方式缺點：
- 全程運維參與，佔用大量時間
（而小公司而言，一般都是開發人員開發完之後直接上傳部署，別問我為什麼知道。。。） - 上傳速度慢
- 人為失誤多，管理混亂
而且這種方式部署，一般只能是固定一個人來完成。如果換其他人，因為部署流程比較複雜，上手慢，而且綜合考慮，伺服器上的應用都是已經上線的產品，新人部署，不確定因素過多，主管一般都不太放心。所以我們就考慮能否有一個自動化的工具：
- 簡化部署流程：節省時間，就算人員變動也不妨礙程式碼部署。
- 學習成本低：太複雜的語法，學起來太耗時。
- 部署模式：最好不是C/S模式管理，便於擴充管理的伺服器。
- 遠端操作：暫時不考慮custom，預設batch吧.
- 後期維護：修完bug後，希望最快的速度部署到各臺伺服器上。
話說現在市場上的主流自動化運維工具確實很多，puppet、chef、ansible、saltstack。這裡做了一個簡單的比較：
從表格我們看出puppet、chef是出道時間比較久的王牌，使用老牌Ruby語言編寫，可以看出配置管理方面應該支援比較全面。相對而言，ansible、saltstack就比較年輕了，但是這兩個新秀都是目前的寵兒，論壇、開發社群都比較活躍，也是比較有前景的。最重要的是，我看到了ansible的閃光點：
紅圈圈有沒有看到！！no agent!!簡直大愛！！
Ansible呢是基於模組工作的，本身沒有批量部署的能力。真正具有批量部署的是ansible所執行的模組，ansible只是提供了一種框架。它的特性包括：
- no agents：不需要在被管控主機上安裝任何客戶端；
- no server：無伺服器端，使用時直接執行命令即可；
- modules in any languages：基於模組工作，可使用任意語言開發模組；
- SSH by default：基於SSH工作；
- 使用python編寫，維護更簡單，ruby語法過於複雜；
- 支援sudo：（這個真的很有必要，當你發現無論操作什麼都 要root許可權的時候，你會崩潰的，關於root許可權，各個公司為了安全著想，別想了，非相關人員，你是get不到的）
- 執行：並行執行任務。執行批量任務的時候可以寫成指令碼，而且不用分發到遠端就可以執行。
- 不佔master任何資源：沒有守護程序。
Ansible的特性完美解決了我們的問題，確實，針對中小型企業，如果只是管理幾十至幾百臺伺服器，並且不需要使用到太複雜的配置管理功能，這個足夠了。
具體的Ansible的介紹可以參考這裡：Ansible documentation 傳送門。
今天就到這兒了，下節，我會用例項給大家比較一下傳統用指令碼部署和Ansible部署的優劣。