230
雲上自動化資源架構和變更實踐
雲棲TechDay41期，阿裏雲高級技術專家董孝帶來雲上自動化資源架構和變更實踐。在業務轉型互聯網+或是+互聯網的時代，企業上雲已成定局。但上雲之後，如何管理雲計算基礎設施？如何實現雲原生架構的交付？本次以開源技術工具Terraform、Packer、Jenkins、Docker為例，分享一個Multi-Cloud下的基礎設施和應用自動化管理方案。
以下是精彩內容整理：
為什麼要上雲?
從技術人員的角度來說，上雲的因素包括價格、基礎設施啟動和運行時間、雲上具有良好的擴展性、雲上具有更好的安全性。
錢從自己家裏放到銀行一開始也需要建立 一個信任的過程，需要相應法律法規的完善，這樣大家才慢慢放心把錢從家裏放到銀行。而上雲同樣需要一個過程，大家一開始可能對敏感信息放到雲上是有擔心的，一方麵是技術上的問題，網速不夠快，想訪問的時候訪問不了，一方麵法律法規不健全，可能會導致我們的信息泄露。但是隨著技術進步和相應法律法規的完善，雲一定會像銀行一樣成為社會的基礎設施。
傳統模式下上線新業務基礎設施準備引發我們的思考，我們需要準備哪一些？我們要進行容量規劃，在容量規劃方麵我們不能隻考慮現在，如果業務發展很快的話，還要規劃擴容的準備，還要規劃測試用多少，應用用多少，服務要有多少，這是一個很困難的過程；容量規劃做完了，還要報采購計劃，還要準備機房、布置網絡等等，還要安裝軟硬件，準備相應的應用的構建部署工具；在開發應用上線之前，也要應對開發和測試運營之間因為環境一致性引發的各種爭論，比如開發人員說軟件已經開發好了，結果測試人員說在我的環境下就是運行不好，然後檢查發現是因為測試用的是重複的環境，不是一個幹淨環境，結果造成了數據汙染，造成了自己應用在測試的環境下跑不起來，這是環境引發的。在一個傳統的環境下我們會遇到各種各樣的問題，等到我們把這些問題都解決了，應用上線了，可能幾周甚至幾個月過去了，有時候可能商機就喪失了。
這些問題都解決後，如果說業務增長迅速需要擴容，或者說我們需要在新的地域來開展我們的業務，那麼所有過程又需要重新來一遍，而且這一部分基礎設施準備在傳統的環境下是不可避免的，流程難以自動化。
DevOps和基礎設施自動化
據數據統計，在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是一個開源的基礎設施編排工具。
1. 它具備廣泛的產品支持。Terraform集成了所有主要的阿裏巴巴雲服務，能夠覆蓋90%的需求，在AWS上Terraform更是比較成熟的，基本上所有AWS的服務Terraform都支持，而且穀歌某一項產品要提供雲的支持，這個產品如果不支持Terraform是不準發布的。
2. 我們也提供了豐富的示例。大家可能對Terraform不是很熟，也不知道怎麼樣去編寫Terraform的模板，這不是問題，因為我們在開源倉庫裏麵已經針對我們每一個提供的資源都提供了示例，總計有大於30以上的模板。
3. 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的模板完成。
在這個場景中間我們訪問一個外部服務，例如我們的ECS上要訪問GitHub，在傳統模式下，我們需要直接用不加密的方式放到ECS上，如果這樣你的ECS被攻破的話，那麼黑客就可以訪問你的GitHub了。但是在這種模式下，首先從阿裏雲的Keypair服務得到一個Keypair，然後使用KMS進行加密私池，加密後放到ECS上，然後通過KMS的RAMpolicy把RAMRole賦給ECS，當你需要去訪問Git的時候，它就會從KMS去解密你的私池，然後通過公池就能連接起來，這樣在整個過程中你的私池是被加密的，即使拿到加密的私池也無法訪問你的GitHub，整個複雜的場景我們也可以通過簡單的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，解決了對於線下來說非常難以解決的基礎設施自動化的問題。讓Dev Ops變得更簡單，更方便。
雲上DevOps工具提供了覆蓋Dev Ops的整個環節，從代碼的提交到應用發布的整個生命流程，我們可以有靈活的選擇開源工具和專業的產品。我們不僅僅能在同一供應商之間選擇，也可以在多個雲平台廠商之間進行選擇。
最後更新：2017-09-28 13:03:17