資源編排最佳實踐之入門篇：雲伺服器如何從1到N？

随着雲計算的應用和普及，iaas層、saas層、paas層的服務也不斷湧現，而國内雲端的自動化運維還屬于初探階段。阿裡雲資源編排(resource orchestration，以下簡稱ros)服務即是填補了這部分空缺。

ros的理念是“基礎設施即代碼”，一方面是用代碼思維的版本管理來記錄基礎設施的變化，另一方面我們都知道計算機世界用代碼實作了各種系統、無所不能，ros秉承這樣的理念，通過代碼實作自動化運維，并且簡化編寫代碼的複雜度，隻需通過模闆描述多個雲計算資源的依賴關系、配置等。

通俗地了解，ros的資源就像樂高遊戲中的小積木，基于每個小資源可以搭建上層的無數種可能。

ros目前支援了阿裡雲12款主要雲産品、40多個資源類型，後續還會不斷增加。雖然模闆簡化了編碼的複雜度，但通過靈活應用可以滿足各種自動化運維的需求。

本系列共分為四篇文章，通過不同的次元介紹幾個典型的應用場景，也是希望借助此系列能打開各個運維人員、開發者的腦洞，增強雲端自動化運維的能力。

本文為第一篇“入門篇”。目前雲計算領域使用最多的是雲伺服器，是以本文會圍繞雲伺服器自身的普遍需求展開介紹，其餘幾篇會介紹和其他服務或工具結合的場景。

在經過很多的使用者回訪，我們發現針對于雲伺服器大家使用最多的場景是基于雲伺服器“此刻的狀态”再建立1-n台雲伺服器，新建立的雲伺服器系統盤和資料盤都是“此刻的狀态”，本文将根據此場景來講述通過ros如何實作。

我們以一個網站服務為例，一般運維工程師會在系統盤或資料盤中安裝一些應用，如：tomcat、jenkins、mysql、網站自身的資料/檔案等等。如果需要再建立一台雲伺服器與目前已有雲伺服器的系統或資料狀态保持一緻，可以将系統盤做成自定義鏡像，資料盤做成快照，然後再新購買雲伺服器時鏡像選擇該自定義鏡像，資料盤的快照選擇該快照，安全組的規則配置與原雲伺服器一緻的規則，就可以建立一台基于原雲伺服器“此刻狀态”的新雲伺服器。

如果隻需建立這一台雲伺服器，并且不需要記錄曆史狀态，上述方法是比較合适的。但實際情況往往不是這樣的，可能會頻繁的建立/釋放雲伺服器，或者生成鏡像的操作人員與購買雲伺服器的人員不是同一個人，一但購買選項沒有選正确，新購的這台雲伺服器就不能投入業務中，按量的需要再釋放，包年包月的需要等到到期釋放，或者做資料遷移，勢必會帶來一定的損失。

另外如果想記錄或跟蹤雲伺服器的曆史演變，如安全組配置的變化、基礎鏡像等資訊，需要單獨記錄。

面對上述問題，運維人員可以使用ros的模闆作為傳遞物，将資源的固定參數在模闆資源中定義，将可變的參數在模闆參數中定義，友善運作時輸入實際參數。這樣在頻繁建立雲伺服器時，隻需要輸入可變參數中的内容即可，如鏡像id、快照id，或者克隆原雲伺服器，或者沒有可變參數，将所有定義都在資源中描述，可以根據實際業務要求靈活變通模闆編寫。

并且，模闆可以存放在github中，可以像管理代碼一樣跟蹤模闆曆史，也可以基于模闆之上建立适合于企業内部的運維工具，實作自動化運維，以“基礎設施即代碼”的理念代替“重複勞動”。

要了解ros模闆的詳細解釋，可以深入閱讀資源編排模闆詳解

下面以“網站服務運維”這個場景為例，講一下模闆定義中的關鍵要素：

鏡像和快照id可以放在模闆參數中定義：

定義雲伺服器的鏡像和快照資源。

鏡像資源定義如下，引用參數中的鏡像id：

快照資源定義如下，引用參數中的磁盤名稱、大小、快照id：

指定建立的雲伺服器數量，最大支援100台，可以是按量的也可以是包年包月的，包年包月的資源定義詳見一鍵建立包年包月ecs執行個體

其他如io優化、磁盤大小、安全組等可以根據實際情況定義，此場景的詳細例子可以參考官方提供的例子指定鏡像、磁盤快照建立ecs

本文是通過一個執行個體講解通過自定義鏡像和快照生成新雲伺服器，針對于雲伺服器的運維遠不止于此。

是以接下來，我們将會在[進階篇]教你“如何利用ros實作彈性伸縮”，通過ros能力每個人都能成為運維高手、架構師。

本文轉自d1net（轉載）