阿裡雲進階技術專家董孝在雲栖TechDay41期帶來了雲上自動化資源架構和變更實踐，本文整理字TechDay41期的沙龍内容。在業務轉型網際網路+或是+網際網路的時代，企業上雲已成定局。但上雲之後，如何管理雲計算基礎設施？如何實作雲原生架構的傳遞？
本次以開源技術工具Terraform、Packer、Jenkins、Docker為例，分享一個Multi-Cloud下的基礎設施和應用自動化管理方案。
從技術人員的角度來說，上雲的因素包括價格、基礎設施啟動和運作時間、雲上具有良好的擴充性、雲上具有更好的安全性。
錢從自己家裡放到銀行一開始也需要建立 一個信任的過程，需要相應法律法規的完善，這樣大家才慢慢放心把錢從家裡放到銀行。而上雲同樣需要一個過程，大家一開始可能對敏感資訊放到雲上是有擔心的，一方面是技術上的問題，網速不夠快，想通路的時候通路不了，一方面法律法規不健全，可能會導緻我們的資訊洩露。但是随着技術進步和相應法律法規的完善，雲一定會像銀行一樣成為社會的基礎設施。
傳統模式下上線新業務基礎設施準備引發我們的思考，我們需要準備哪一些？我們要進行容量規劃，在容量規劃方面我們不能隻考慮現在，如果業務發展很快的話，還要規劃擴容的準備，還要規劃測試用多少，應用用多少，服務要有多少，這是一個很困難的過程；容量規劃做完了，還要報采購計劃，還要準備機房、布置網絡等等，還要安裝軟硬體，準備相應的應用的建構部署工具；在開發應用上線之前，也要應對開發和測試營運之間因為環境一緻性引發的各種争論，比如開發人員說軟體已經開發好了，結果測試人員說在我的環境下就是運作不好，然後檢查發現是因為測試用的是重複的環境，不是一個幹淨環境，結果造成了資料污染，造成了自己應用在測試的環境下跑不起來，這是環境引發的。在一個傳統的環境下我們會遇到各種各樣的問題，等到我們把這些問題都解決了，應用上線了，可能幾周甚至幾個月過去了，有時候可能商機就喪失了。
這些問題都解決後，如果說業務增長迅速需要擴容，或者說我們需要在新的地域來開展我們的業務，那麼所有過程又需要重新來一遍，而且這一部分基礎設施準備在傳統的環境下是不可避免的，流程難以自動化。
據資料統計，在2015年DevOps的被采納率是66%，而到了2016年就達到了74%，在這短短的一年間增加了8%，對于現在的企業來說，是否采用DevOps，使用得好不好，不僅僅是企業運作的好壞問題，而是生與死的問題。
什麼是DevOps？有人說采用靈活開發，追求最小的可傳遞價值，快速的開發靈活是Dev Ops；也有人說建立良好的監控體系能夠自動迅速的回報提高傳遞品質就是DevOps；也或者是建立良好的組織和文化，建立企業之間各個部門之間互相良好的溝通方式，以快速傳遞軟體的價值為目的，就是DevOps；還有說DevOps就是打破開發和營運之間的壁壘。那麼這些是DevOps嗎？
依我看來，DevOps是能夠加速從需求收到最後應用和服務傳遞的一切流程和方法。隻有我們采用靈活的方法，始終追求一個目标，然後建立快速的監控和回報體系，來提高我們傳遞的品質，建立企業之間各個部門之間溝通信任的交流環境，以最快的傳遞服務應用為目的的企業文化，然後基于自動化的工具和服務作為基礎來實作目标的快速傳遞，隻有這幾個部分有機的組合，才能取得DevOps最大效益。
雲上DevOps有哪些優勢呢？主要有以下三點：
它能夠覆寫DevOps整個環節，從送出代碼到最後營運監控的整個環節。
我們來看一看在“IaaS”層可以使用Terraform、ROS、ANSIBLE、CHEF和Parker，在傳統中我們的基礎設施是用配管等等之類的工具來維護的，存在資訊更新等等方式的問題，而且使用起來也比較麻煩，而使用IaaS到模式的話，我們建立基礎設施也像建立代碼一樣，比如說我們要建立一個VPC叢集，裡面要包含哪些機器，要配置一個什麼樣的網絡，怎麼樣設計安全組規則，在傳統模式下需要人去操作，然後通過配管工具來記錄的。
而我們首先像寫代碼一樣寫出我們的這些需求，寫出我們的模闆然後直接應用，會在雲上建立出各種資源，而且它也會把這些建立資源的結果記錄到狀态檔案裡面，我們就知道目前有哪一些檔案，哪一些資源，而且在建立資源的時候，有的時候需要維護一個狀态，假設我們需要六台虛拟機，如果已經有了三台虛拟機，使用傳統模式我們相對要建立三台，而在IaC模式下，使用Terraform模闆的話，我們就隻需要指定需要六台虛拟機，它就會在雲上看目前有多少台，然後産生新的三台，如果到了六台發現業務量下降了，我們隻需要兩台，那我們就寫最終目的是兩台，我們不用去計算我們現在有六台，我們要達到兩台的目的我們還要減少四台，我們隻需要寫最終要保留兩台，那麼它就會自動給我們銷毀另外的四台。這樣就避免了我們在寫代碼腳本維護時容易發生的各種錯誤。而像ANSIBLE、CHEF這些都是大家常用的運維工具，現在在雲上也提供了相應的功能，而ROS是阿裡提供的跟Terraform相對應的專有産品，能夠自動化的一鍵建立我們的基礎設施。Packer是一個建立鏡像的IaC工具。
如果大家對于基礎設施這一塊建立好之後，那麼有的企業不關心怎麼樣去使用基礎設施，這個時候我們就可以選擇PaaS平台，使用couldfundry，或者說我們使用容器服務來釋出我們的應用，用像ContainerService這種。那麼當Paas平台都準備好了之後，我的代碼怎麼樣能快速釋出到雲上？這個時候就有我們的産品CodePipeline可以直接送出代碼，然後自動建構，按照我們的指令部署到ContainerService或者我們的ECS上，在這一塊CodePipeline在阿裡雲也提供。這些工具怎麼樣來支撐完成DevOps的完整流程呢？
從一個Develop送出代碼到Github裡面去，這個時候webhook就會通知CI Server有代碼變化了，你需要去建構。那麼CIServer就會從Git上拉起代碼，按照事先的指令進行建構，如果建構的過程中發生了錯誤，它就會通知開發者有錯誤需要去修正。如果成功之後，對于喜歡使用新技術的人，可能會把建構完的建構物打包成Docker鏡像push到Docker Registry裡面去，然後進行測試和産品環境的部署，從Docker Registry上pull它的鏡像，在各個環節上進行分發。
對于一些企業來說，他們不習慣采用Docker，或者應用已經采用傳統實體機，這個時候我們可以将建構物上傳到OSS裡面去，然後我們的CDServer會将我們的部署物按照我們指定的指令部署到相應的ECS上，或者是實體機上。
在這個過程中，CI、CD我們可以采用Codepipeline來實作，而容器的釋出運作環境可以使用容器服務。當我們部署到ECS上的時候，Terraform能夠幫助我們快速的一鍵生成我們所需要的環境。
我們可以自由的選擇開源工具和專有的産品，現在廣泛使用的DevOps和服務都是支援多雲平台的。
靈活性構成的工具裡面既有我們自己提供的産品，像ROS、ContainerService、Codepipeline，也有衆多的開源産品，是不是我們使用了專有産品就被阿裡雲綁定了呢？不是的，因為好的服務，其實各個雲平台場上都提供了。比如ROS功能在AWS是由CloudFormation來提供的，而ContainerService在AWS也提供了ECS，是以我們采用這些工具并不會被某一雲平台鎖定，而對于開源部分更是天生就是跨雲平台支援的，是以它有良好的适應性，我們并不擔心使用這些工具會讓我們綁定在某一平台上。
Terraform是什麼呢？
Terraform是一個開源的基礎設施編排工具。
它具備廣泛的産品支援。Terraform內建了所有主要的阿裡巴巴雲服務，能夠覆寫90%的需求，在AWS上Terraform更是比較成熟的，基本上所有AWS的服務Terraform都支援，而且谷歌某一項産品要提供雲的支援，這個産品如果不支援Terraform是不準釋出的。
我們也提供了豐富的示例。大家可能對Terraform不是很熟，也不知道怎麼樣去編寫Terraform的模闆，這不是問題，因為我們在開源倉庫裡面已經針對我們每一個提供的資源都提供了示例，總計有大于30以上的模闆。
Terraform是多雲支援的，能夠很友善的管理阿裡雲、AWS、AZure等主流雲平台的基礎設施。使用Terraform一鍵打通了阿裡雲所有的主流産品，使用Terraform能很友善的管理阿裡雲上的所有主流資源。‘
我們要建立一個VPC叢集，我們有哪一些服務呢？我們有ECS服務，我們要建立兩台ECS，要在不斷的子網中間有統一的安全組，然後設計了通過NET網管進行對外通路，有SNET、DNET來提供網絡通路，同時SLB提供負載均衡的服務，health check來檢查SLB的健康狀況。
大家在使用頁面的時候，如果一個兩個資源大家都會覺得很簡單，按幾個button就建立完了，但如果建立一個複雜的環境，使用Terraform可能編寫一個模闆，然後使用一個簡單的指令，這樣一個叢集就建立好了。如果你需要建立一個新的，隻要再執行一次指令就可以重建叢集，如果我覺得這個叢集現在不用了，Terrafor執行destroy指令，那麼整個叢集就被銷毀了，所有的資源都被釋放了，這是很友善的，而且我可以很友善的去查有哪一些資源，從它生成的狀态檔案裡面，我就可以很友善的查到，可以建立哪一些資源組，有哪一些ECS，網絡的IP是什麼等等，所有的叢集資訊都在這個狀态檔案裡面。
在我們倉庫裡面，已經對常用場景提供了模闆，大家隻要拿下來複制，簡單的去修修改改就可以滿足你的日常需求了。這樣就把我們一個很複雜的基礎設計建立過程變成一個簡單的指令執行過程。
如果通路一系列服務的時候，我們很關心密碼怎麼樣，比如說我現在作為阿裡雲上的一個ECS裡面的APP，我要通路OSS，在以前我是需要在應用裡面放上我通路ECS的AKD的，這是一個不安全的行為，因為如果突破了ECS，那麼就有可能會擷取到AKD，而現在通過RAM，我們在建立ECS的時候，把相應的RAMROLE綁定到相應的ECS上，那麼從這台ECS上去通路我們指定的ECS時候，我們的應用就不需要OSS的密碼了，這台機器綁定相應的Role也可以通過一個Terraform的模闆完成。
使用Terraform能夠友善的幫助我們一鍵建立整個基礎設施，而且這種建立是可以重用的，比如說我在北京Region建立的基礎設施，然後我的業務擴大了，到海外或者其他的省份建立這種基礎設施的話，我們隻需要修改Region名字然後pipeline，就可以快速一鍵複制我們的整個基礎設施。而我們的容器服務提供了服務編排，服務發現，自動伸縮，失敗排程等等功能，它是無縫的阿裡雲服務支援，降低客戶建立和使用服務的成本。我也可以簡單的自己搭建一個容器叢集，但是要達到一個生産級的容器服務，然後友善使用相關的各種各樣技術還是有一定的門檻的，而容器服務能降低這種門檻。我們自己的CodePipeline裡面也使用了我們自己建立的容器服務，在我們build的時候，我們的CodePipeline是一個SaaS服務，怎麼樣能最大化的實作在建構時候的資源共享？
這個時候我們使用了自己的Container服務來根據需要來動态配置設定資源完成建構任務，建構結束後，而如果我們要部署到容器也就可以部署到ContainerServers，也可以部署到ECS，我們自己在建立CodePipeline産品的時候，我們的基礎裝置準備也是為使用Terraform模闆來準備的，這樣當我們要國際化的時候我們可以很友善的使用Terraform模闆來複制我們的基礎結構，同時對于部署到ECS的時候，我們可以用Terraform、ROS來建立測試Staging production所需要的各種各樣環境。
在CodePipeline服務中，我們的建構是運作在容器中間的，當然容器建構完成的時候，我們就會釋放資源，供其他的JOB來使用。
那麼以下問題怎麼樣來解決呢？
通過雲服務實作容量規劃：因為在雲上我們可以快速以分鐘級建立資源，并不需要過多的考慮怎麼樣擴容。我們是按需來規劃，我們目前需要多少就規劃多少，那麼就把一個拍腦袋來規劃容量的事情變成目前可及的事情。
雲産品的采購計劃也相對簡單，不需要準備機房、布置網絡、安裝軟硬體這些工作，如果我們采用Packer的模闆來建立基礎設施，也可以一鍵來準備這些東西，将一個幾小時或者幾周時間變成分鐘級的任務。
如果采用CodePipeline等類似的SaaS服務，我們也不需要準備應用的建構和部署工具。因為我們可以很友善的去派生一套新的環境，如果我們需要一套幹淨的環境時候，我們就可以很快在分鐘級來建立這些資源。不用應對開發和測試營運之間因為環境一緻性引發的各種争論，業務如果要增長要擴容，對于雲上也是Terraform一個簡單的指令能完成的事情，是以在雲上基礎設施自動化DevOps，解決了對于線下來說非常難以解決的基礎設施自動化的問題。讓DevOps變得更簡單、更友善。
雲上DevOps工具提供了覆寫DevOps的整個環節，從代碼的送出到應用釋出的整個生命流程，我們可以有靈活的選擇開源工具和專業的産品。我們不僅僅能在同一供應商之間選擇，也可以在多個雲平台廠商之間進行選擇。