阿裡雲自動化部署和運維的最佳實踐-基于YAML的編排

  運維，是從IT誕生起就一直存在的重要角色，為軟硬體系統的整體穩定性、效率、安全等名額負責。最近幾年，伴随着雲計算和DevOps的廣泛應用，運維更是成了舞台中央最亮眼的主角之一。

  值得關注的是，雲時代的運維，正在颠覆傳統的運維。傳統的運維，需要能夠手動操作來自衆多廠家的計算、網絡、存儲等軟硬體，并為此學習傳統“大廠”的衆多認證，例如，資料庫運維要學Oracle的認證，系統運維要學IBM的認證，虛拟化運維要學VMware的認證，等等。但企業上雲之後，雲廠商将計算、存儲、網絡的操作全部抽象成了軟體定義的API接口，并用統一風格的SDK、指令行進行封裝，進而大幅降低了運維操作的門檻。雲上的運維人員不再需要感覺底層基礎設施的細節，更不需要考取高難度的認證。

  當然，雲時代也對運維人員提出了新的要求和挑戰。首當其沖的，就是DevOps，強調高度的自動化，要求運維人員具備一定的開發技能。以國内最大的雲廠商阿裡雲為例，運維人員需要學習并掌握阿裡雲主流雲産品（雲伺服器，雲資料庫，對象存儲，專有網絡等等）的API，才能從容的根據自己企業的實際運維需要，開發實作自動化運維系統。這樣一來，運維操作工程師，就更新成了運維開發工程師。

  既然談到了運維開發，就離不開程式設計語言和開發平台。運維開發與普通軟體開發不同，對于快速開發的要求應該是第一位的，因為運維開發的需求變化更頻繁，開發周期更短，人力也更為緊張。阿裡雲提供的JavaPythonGo等語言的SDK，雖然能力強大，但是能力過于“原子”。若沒有平台的支援，要運維人員自己從頭搭建一個自動化運維系統，并保證其高效穩定持續運作，難度和投入都很大。為了保證生産系統的穩定，創造了一個運維系統，那麼，誰來保證這個運維系統的穩定呢？這是一個悖論。

  為了進一步的提升運維開發人員的開發效率，降低開發的難度，阿裡雲推出了資源編排（Resource Orchestration Service，簡稱ROS），和運維編排Operation Orchestration Service，簡稱OOS）這兩個編排平台。作為平台級的産品，阿裡雲會負責保證其穩定可靠，使用者隻需要按照平台的規則制定自己的運維邏輯。那麼什麼是編排呢？編排來源于交響樂，是指通過編曲，把各種不同樂器的演奏，和諧的融合在一起。運維開發人員，就像交響樂作曲家，通過編寫YAML格式的編排模闆，把各種不同的資源、配置、動作，串聯在一起。

  先來說資源編排ROS。假設一個場景，在阿裡雲上搭建一個經典的三層線上服務：前面是SLB負載均衡，中間是若幹台ECS作為一個服務叢集，後面再挂接一套RDS資料庫。當然，你還需為這三層分别各自建立一個VPC，通過安全組設定安全規則。在業務初期你可能隻需要兩台ECS，但很快會擴大到3台、4台。按照傳統的運維思維，需要給系統下達原子的指令：今天建立一台，明天再建立一台。但是按照ROS聲明式的文法，運維開發人員隻需要指定自己目前的資源需要。比如把MaxAmount值從3改成5（見如下例子），ROS會自動建立兩台ECS。再比如把MaxAmount從3改成2，ROS會自動釋放其中一台ECS。我們把這種全自動的管理資源的生命周期的方式，叫做“基礎設施即代碼”。

Resources:
  InstanceGroup:
    Type: 'ALIYUN::ECS::InstanceGroup'
    Properties:
      MaxAmount: 3
      InstanceType:
        Ref: InstanceType
      ImageId:
        Ref: ImageId
      SecurityGroupId:
        Ref: SecurityGroupId
      VSwitchId:
        Ref: VSwitchId           

  運維是一個非常廣泛的概念，資源的生命周期管理，隻是其中一小部分。運維，還涉及到了監控、故障處理、持續釋出、資源分組、審計等等各種需求。為了滿足普适的運維需要，阿裡雲推出了運維編排（OOS）産品。同樣是基于YAML的編排，但是與ROS不同的是，OOS編排的是一個個的原子動作（API）。幾乎所有阿裡雲控制台上的操作，都可以通過OpenAPI來完成，而幾乎所有的API動作，都可以通過OOS來完成，是以，我們可以說，所有的阿裡雲上的運維動作，都可以通過OOS來自動化完成。不僅如此，阿裡雲OOS還内置了三個強大的運維功能：定時任務、事件觸發器和雲助手指令。定時任務很容易了解，使用者隻需要編寫cron表達式，OOS就會精确地定時觸發，例如，每天早晨八點開啟伺服器。事件觸發器可以跟雲監控的事件（或者告警）相結合，實作“事件驅動”的自動化運維，尤其是自動化的故障恢複，運維人員無需關心事件的具體接收過程。雲助手指令則可以讓開發人員，在無需開啟SSH接口的情況下，遠端在linux裡面執行系統指令。我們舉一個事件驅動和雲助手結合的例子，當60秒的平均CPU使用率超過90%的時候，重新開機tomcat服務，OOS模闆的示例（節選）如下：

Tasks:
  - Name: alarmTrigger
    Action: 'ACS::AlarmTrigger'
    Properties:
      Namespace: acs_ecs_dashboard
      MetricName: cpu_total
      Statistics: Average
      ComparisonOperator: GreaterThanThreshold
      Threshold: '90'
      Resources: '[{"instanceId":"{{ instanceId }}"}]'
      Period: 60
  - Name: runcommnd
    Action: ACS::ECS::RunCommand
    Properties:
      commandContent: 'service tomcat restart'
      instanceId: '{{ instanceId }}'
      commandType: RunShellScript           

  通過上面的例子，我們可以看出，ROS和OOS，可以幫助運維開發人員，以最快的速度和最少的代碼，實作常見運維任務的自動化。阿裡雲官方，為ROS和OOS提供了一系列的公共模闆，開源在github上，感興趣的運維同學們可以閱讀學習，或者基于這些現有的模闆随意進行二次開發。 

ROS公共模闆：

https://github.com/aliyun/ros-templates

OOS公共模闆：

https://github.com/aliyun/oos-templates

  運維同學可能會想到，能否将ROS和OOS結合使用呢？答案是肯定的。可以在OOS模闆裡，對ROS進行API調用。具體的實作，還希望聰明的運維同學們參考ROS和OOS的官方幫助文檔，自己嘗試一下。 

ROS首頁：

https://www.aliyun.com/product/ros

    OOS首頁：

https://www.aliyun.com/product/oos

  阿裡雲正在籌辦“彈性計算自動化運維模闆挑戰賽”。也歡迎運維開發同學們積極參與，獎勵豐厚。如有問題，歡迎加入釘釘群咨詢。 

ROS支援群群号：11783495   

OOS支援群群号 : 23330931