結合Ansible在AWS雲計算平臺上實現運維自動化

  

  剛剛看了金山樑曉聰的"在AWS上的運維自動化實踐分享"，發現技術都是相通的，你們都是用最好的技術。咱們的業務平臺主要也是AWS雲計算平臺，嘗試了許多自動化運維/配置工具，最後仍是選終了Ansible。下一步在公司運維自動化DevOps要作的工做：增大Ansible在系統中的應用比重，真正跟AWS結合起來。選擇Ansible主要由於豐富的相關支持，包括不少現有的組件和模塊和開源的Ansible部署和腳本。筆者也嘗試了市面上全部自動化運維和自動化配置工具，發現Ansible是對AWS支持得最好的一個。Ansible的開發過程是寫大量 Playbooks。如今Ansible支持的有251個模塊，特別是對於雲服務的支持。像AWS、Docker、OpenStack，部署腳本都放在一個子目錄下。這就意味着把別人寫的腳本拿過來，或者把別人寫定義的Playbook拿過來很是容易。如今關於Ansible的開源腳本數量龐大，3000多個項目，我相信這個數字只會愈來愈多，這意味着之後的不少DevOps工做會愈來愈簡單容易。

  找到 Ansible 的過程（套用下雲巴張虎的原話，由於咱們的過程很相似）

       最先咱們用 SSH 寫不少腳本，要用 SSH 連過去，也是在某一臺機器上執行，不用在目標機上登錄。這種作法在至關一段時間內是咱們實際使用的手段，它實際上比 Puppet 有效。可是它有一些問題：管理成本高、腳本會愈來愈多。部署的過程有不少的基礎部件須要反覆部署，幾乎是無法管理。後來咱們用了 RunDeck，它有界面、有必定的管理能力。咱們還用過 Fabric，即批量執行命令，能作到相似部署的事情。可是，目標機規模大了以後僅有管理的能力是不夠的。後來咱們又調研過 Salt，不認爲有太大的差異。選擇 Ansible 主要由於豐富的相關支持，包括不少現有的組件和模塊和開源的 Ansible 部署和腳本。咱們的團隊不喜歡糾結。咱們發現 Ansible 沒有太本質的區別，就開始用起來。若是沒有明確理由，咱們就憑感受選一個用。

       Ansible 是經過 SSH 鏈接到目標服務器，上面這兩個東西是我想了好久，我但願去擁有的特性。一個是完整的集羣，只須要有一個 inventory 去定義，寫出清單就能夠定義集羣。每個角色的具體功能有若干 playbooks 來定義。