隨著云計算的應用和普及,IaaS層、SaaS層、PaaS層的服務也不斷涌現,而國內云端的自動化運維還屬于初探階段。阿里云資源編排(Resource Orchestration,以下簡稱ROS)服務即是填補了這部分空缺。
ROS的理念是“基礎設施即代碼”,一方面是用代碼思維的版本管理來記錄基礎設施的變化,另一方面我們都知道計算機世界用代碼實現了各種系統、無所不能,ROS秉承這樣的理念,通過代碼實現自動化運維,并且簡化編寫代碼的復雜度,只需通過模板描述多個云計算資源的依賴關系、配置等。
通俗地理解,ROS的資源就像樂高游戲中的小積木,基于每個小資源可以搭建上層的無數種可能。
ROS目前支持了阿里云12款主要云產品、40多個資源類型,后續還會不斷增加。雖然模板簡化了編碼的復雜度,但通過靈活應用可以滿足各種自動化運維的需求。
本系列共分為四篇文章,通過不同的維度介紹幾個典型的應用場景,也是希望借助此系列能打開各個運維人員、開發者的腦洞,增強云端自動化運維的能力。
本文為第一篇“入門篇”。目前云計算領域使用最多的是云服務器,因此本文會圍繞云服務器自身的普遍需求展開介紹,其余幾篇會介紹和其他服務或工具結合的場景。
在經過很多的用戶回訪,我們發現針對于云服務器大家使用最多的場景是基于云服務器“此刻的狀態”再創建1-N臺云服務器,新創建的云服務器系統盤和數據盤都是“此刻的狀態”,本文將根據此場景來講述通過ROS如何實現。
我們以一個網站服務為例,一般運維工程師會在系統盤或數據盤中安裝一些應用,如:Tomcat、Jenkins、MySql、網站自身的數據/文件等等。如果需要再創建一臺云服務器與目前已有云服務器的系統或數據狀態保持一致,可以將系統盤做成自定義鏡像,數據盤做成快照,然后再新購買云服務器時鏡像選擇該自定義鏡像,數據盤的快照選擇該快照,安全組的規則配置與原云服務器一致的規則,就可以創建一臺基于原云服務器“此刻狀態”的新云服務器。
如果只需創建這一臺云服務器,并且不需要記錄歷史狀態,上述方法是比較合適的。但實際情況往往不是這樣的,可能會頻繁的創建/釋放云服務器,或者生成鏡像的操作人員與購買云服務器的人員不是同一個人,一但購買選項沒有選正確,新購的這臺云服務器就不能投入業務中,按量的需要再釋放,包年包月的需要等到到期釋放,或者做數據遷移,勢必會帶來一定的損失。
另外如果想記錄或跟蹤云服務器的歷史演變,如安全組配置的變化、基礎鏡像等信息,需要單獨記錄。
面對上述問題,運維人員可以使用ROS的模板作為交付物,將資源的固定參數在模板資源中定義,將可變的參數在模板參數中定義,方便運行時輸入實際參數。這樣在頻繁創建云服務器時,只需要輸入可變參數中的內容即可,如鏡像ID、快照ID,或者克隆原云服務器,或者沒有可變參數,將所有定義都在資源中描述,可以根據實際業務要求靈活變通模板編寫。
并且,模板可以存放在Github中,可以像管理代碼一樣跟蹤模板歷史,也可以基于模板之上創建適合于企業內部的運維工具,實現自動化運維,以“基礎設施即代碼”的理念代替“重復勞動”。
要了解ROS模板的詳細解釋,可以深入閱讀資源編排模板詳解
下面以“網站服務運維”這個場景為例,講一下模板定義中的關鍵要素:
1. 鏡像和快照ID可以放在模板參數中定義:
"Parameters": {
"ImageId": {
"Description": "鏡像文件ID, 表示啟動實例時選擇的鏡像資源",
"Type": "String"
},
"DiskName": {
"Type": "String"
},
"DiskSize": {
"Default": 40,
"Type": "Number"
},
"SnapshotId": {
"Type": "String"
}
}
2. 定義云服務器的鏡像和快照資源。
鏡像資源定義如下,引用參數中的鏡像ID:
"ImageId": {
"Ref": "ImageId"
}
快照資源定義如下,引用參數中的磁盤名稱、大小、快照ID:
"DiskMappings": [
{
"DiskName": {
"Ref": "DiskName"
},
"Size": {
"Ref": "DiskSize"
},
"SnapshotId": {
"Ref": "SnapshotId"
}
}
]
3. 指定創建的云服務器數量,最大支持100臺,可以是按量的也可以是包年包月的,包年包月的資源定義詳見一鍵創建包年包月ECS實例
4. 其他如IO優化、磁盤大小、安全組等可以根據實際情況定義,此場景的詳細例子可以參考官方提供的例子指定鏡像、磁盤快照創建ECS
本文是通過一個實例講解通過自定義鏡像和快照生成新云服務器,針對于云服務器的運維遠不止于此。
所以接下來,我們將會在[進階篇]教你“如何利用ROS實現彈性伸縮”,通過ROS能力每個人都能成為運維高手、架構師。