 |
VOOZH | about |
|
VOOZH | about |
一個產品服務的交付過程就像是在道路上行進，如果想要速度快，就需要有好的基礎和好的工具。接下來由我來給大家分享一下我在DevOps落地建設方面積累的一些經驗和教訓，即：如何基於雲服務打造一條DevOps持續交付高速公路，打通從代碼到服務的通道，讓我們的交付過程快速順暢，通過實現快速可靠的部署和發布，提升研發、運維各環節的效率和整體的交付效率和質量。希望能在這裡和大家一起討論，共同進步，如有不正確的地方懇請大家指正，避免誤導大家。
對於DevOps，大家都不陌生，最近一段時間國內認同度和關注度也在持續上升，在各個技術媒體上關於DevOps文章和討論非常之多，有很多非常好的從理論價值觀實踐層面討論的文章。DevOps最有標誌性的文章就是09年的」Ten Deploys A Day」，如果了解DevOps，這篇是一定要看的文章。DevOps和前些年的敏捷開發一樣，對企業來說非常重要，是支撐企業業務創新的核心能力。今天，又有了雲計算這個敏捷彈性自動化的IT基礎設施，讓DevOps平台的能力也有了一個巨大的飛躍。
本文將主要著重從雲環境下的落地和解決方案的角度討論，先和大家一起討論我們為什麼做DevOps，將要打造DevOps高速公路的目標具體化；然後介紹一種能夠在雲計算環境下用最少的工作量、時間和代價風險落地的方案，基於雲服務和雲管理平台打造強大的橫向縱向均全面覆蓋環境和應用自動化的DevOps平台，實現在公有雲、私有雲、混合雲以及傳統數據中心中的各種業務應用的持續快速可靠的部署和發布，以及高效的運維管理。
一、為什麼要做DevOps，DevOps要解決的問題首先，我們先一起明確一下我們為什麼做DevOps，DevOps要解決的問題，將DevOps建設目標收斂到符合SMART原則的具體的可達成目標。
從業務的層面，DevOps要解決的主要問題就是實現從開發到交付端到端的業務敏捷，加速業務創新，縮短交付周期，實現持續快速可靠的交付；請見下圖，來自於AWS官方資料，非常經典的一張圖，清晰地詮釋了DevOps的地位和作用。
具體到研發和運維的層面，DevOps要解決的問題就是的交付周期長，發布不可靠、低效問題。
下面我們來層層剝繭，導出DevOps解決方案要實現的具體目標。對於交付周期長，發布不可靠問題，有很多影響因素，這些因素中，其中一個非常主要的因素就是：交付過程各個階段中環境準備、部署發布環節手工操作多、速度慢、不可靠、沒有規範。(請看下圖)
(點擊放大圖像)
這張圖展示了一個產品版本的整個交付過程，這個過程實際上就是一個不斷修改代碼、創建配置準備環境、部署應用，驗證(獲取環境及應用信息，定位問題)的循環過程。這個過程包含四個階段，可以看到在每個階段都需要經過多次創建或配置準備環境，部署應用的環節。這裡的指的環境，不僅僅包含主機虛擬機、應用運行的作業系統環境，還包含中間件服務、防火牆、負載均衡配置、DNS配置等。
在這個過程中對於我們研發團隊面臨和要解決的問題為：
在這個過程中對於運維團隊突出面臨和要解決的問題為：
1.發布過程速度慢，不可控、壓力大，原因多由於：
2.運維過程效率低，特別當環境很多、機器數量很多、系統為分布式系統時，分布在多地域多個雲中時，需要經常擴容縮容時；
3.當運維團隊人數有限，有很多項目團隊申請資源時，給運維團隊帶來很多工作量，造成很多壓力。
對於以上的問題，基本可以通過環境和應用的自動化標準化解決，我們可以將要解決的主要問題具體到以下場景：
1.實現環境創建自動化自服務
2.實現應用部署自動化標準化
3.實現編排全棧自動化
針對以上的各個DevOps自動化場景，有很多實現的方式，包括基於容器的解決方案，由於容器技術當前還需要一段時間才能「飛入尋常企業家」，較大範圍的應用到生產環境，對當前的開發和運維管理習慣改變比較大，相關配套設施也要求比較多，所以這個後續再表。現在，先給大家介紹一種基於IaaS雲服務和雲管理平台的比較容易落地的DevOps平台解決方案，供大家參考。通過這個解決方案我們能夠以很小的代價，快速地基於公有雲私有雲服務實現開發測試以及運維中的各種環境和應用的自動化，能夠非常容易的落地，對應用的架構沒有限制及對現有代碼無侵入。從實現的代價工作量來看，根據對以往經驗，對於20個項目，平均一個項目4～5個組件，考慮項目的基礎條件不一樣，綜合平均下來每個組件的實現代價小於1.5人天。
(點擊放大圖像)
這個平台解決方案如圖示，主要由三大部分組成：一個是配置管理部分，一個是雲管理平台部分，一個是定製化應用部署工具部分。這個方案有幾個關鍵的選型和設計：
選擇了雲管理平台，原因如下：
由於雲管理平台本身集成了各個IaaS雲服務的API，相比於直接基於雲API開發自動化功能，或編寫環境自動化的模板文件，能夠讓我們免去大部分集成IaaS API的二次開發工作，降低了實現自動化的開發維護工作量和門檻，同時能夠充分發揮雲的自動化特性；
雲管理平台提供了業務角度的管理視圖，對虛擬機按照用途和環境類型進行分組，符合我們管理操作的習慣，可以可視化的一目了然在一個集中的視圖中，先按用途找到機器具體信息，然後再進行相關操作，讓我們不需要再採用之前使用Excel表手工維護管理環境信息；
雲管理平台提供了集群感知和編排的功能，能夠讓我們實現一鍵創建環境虛擬機並自動部署配置應用的功能，應用到開發測試過程中建立測試環境場景，以及諸多運維場景，如一鍵擴容縮容、自動故障恢復、備份恢復等等，還有包括公有雲、私有雲、虛擬化多種環境中；
雲管理平台提供了一體化的工具，涵蓋了環境管理、批量管理、代碼部署、監控告警等功能；
雲管理平台不同於PaaS，不對應用的運行環境進行限制，所以可以廣泛的用於實現各種架構的應用的自動化部署，而不僅僅限於Web類的應用；從管理對象上，雲管理平台不僅可以對接管理各個主流公有雲私有雲的虛擬機，而且還可以將傳統物理機和VMware虛擬機導入進行管理，既能夠管理各個遺留環境中應用，也能管理運行在IaaS上的應用，在遺留環境自動化部署後，還能夠實現應用的上雲遷移。
(點擊放大圖像)
應用自動化部署採用AWS CodeDeploy規範
AWS CodeDeploy源自Amazon內部一個非常成熟的規範，這個規範適用的範圍很廣，對應用的部署架構沒有限制和約束。而且非常易用易於掌握，便於落地和推廣。對於部署規範的選型非常重要，直接決定了是否易於推行實現和工作量。
(點擊放大圖像)
下面我們具體介紹一下各個部分，然後以提交代碼自動部署場景和一鍵自動創建虛擬機並部署代碼為例介紹DevOps場景的實現過程：
主要由版本控制系統、持續集成服務、製品庫服務組成。這部分的主要作用是，能夠將要部署的代碼自動編譯，並進行必要的單元測試和組件測試，將部署包上傳到製品庫並將版本信息註冊到雲管理平台，存儲並管理部署包，為後續的自動化部署提供可下載的部署包，方便實現自動化部署下載版本代碼，給自動化部署打下一個好的基礎。即便代碼存放的版本控制庫不一樣，所處的網絡不一樣，仍然可以用統一的HTTP方式下載，也方便同步部署包到各個不同地域網絡以保證下載速度。
這部分輸入為開發人員提交到指定分支的應用代碼，輸出為製品庫如Nexus上的應用版本部署包和雲管理平台上的應用版本信息。
中間的實現依賴於Jenkins和Maven，每個需要獨立部署的應用的代碼分支，在Jenkins上都對應一個Jenkins持續集成任務，當代碼提交後，那麼這個對應的Jenkins持續集成任務就開始同步分支最新代碼，並編譯，單元測試，通過後使用Maven進行打包並上傳到製品庫如Nexus，之後調用定製的Jenkins插件將部署包版本信息註冊到雲管理平台上。
雲管理平台在整個方案中的作用是：
在環境準備場景中，可集成各個主流公有雲私有雲API創建虛擬機，對通過集成雲API自動創建和納管，進行分組分類管理，提供業務維度的管理視圖；
在部署應用場景中，提供應用版本信息的管理，以及自動化部署引擎，支持符合AWS CodeDeloy規範的應用部署包的部署，實現部署的標準化自動化和可視化；
提供編排自動化、批量管理以及基礎設施感知功能，支持實現應用的各種場景下的自動化部署，如創建虛擬機時，提交代碼，手動觸發，執行編排部署任務、定時或基於監控的自動伸縮，備份恢復，自動故障處理等；
提供自服務IT功能，能夠讓研發人員在IT允許的範圍內自助獲取資源準備環境；這個能有效解決在獲取資源環節上研發和IT的協作問題，既減輕了IT的工作量和溝通成本，也提升了雙方的效率。
(點擊放大圖像)
這部分的主要作用是，遵循AWS Code Deploy規範，將依據規範實現的各個步驟的部署腳本與應用代碼打在一個包內，部署引擎下載應用版本代碼到要部署的主機後，會按照規範配置執行這個部署各個步驟的腳本，完成應用在主機上的自動化部署過程。
上面給大家介紹了DevOps平台解決方案的組成部分，下面以兩個典型的DevOps場景給大家介紹一下實現的原理：
代碼提交後自動部署DevOps場景實現過程：
一鍵創建環境主機並自動部署DevOps場景實現過程：
這裡有一點需要說明的是，自動化部署是持續交付里最基礎的第一步，做到這一步能夠大幅提高效率，但是要想實現持續交付，還需要有比較完備的自動化測試工具，實現各個層次階段的測試，包括持續集成階段的單元測試、組件測試，部署後的集成測試，運行期的實時監控。對於自動化測試的實現，通常是一個比較大的技術債務，最好在項目的研發過程中實現，否則最後很難有獲得專門的時間投入資源去做。
最後，總結一下，本文的要點有三：
通過這個方案：
-
精彩QA環節劉濤：發揮作用體現在兩個環節，一個是各個階段的自動化測試，一個是不能或暫時不適合自動化的人工測試。
對於自動化測試，在持續集成階段的貢獻為單元測試、組件測試，幫助快速完成新加功能的測試以及驗證是否影響已有功能；對於部署後的集成測試階段，完成必要的人工功能性測試保證上線的質量。
自動化測試越完備，對快速開發交付貢獻越大。
問：DevOps是以運維為主，還是開發為主,現在可以使用雲上提供的各種API，將來運維何去何從？
劉濤：我一直最大的感受是，從實現DevOps所做的雲服務至上的自動化工作上更多依賴於開發，而雲服務的穩定性維護和提供必要的支持和工具還依賴於運維。雲計算給運維工作帶來的改變是非常大的，提供了一個彈性自動化的基礎設施服務，運維將來的發展方向也會在這個基礎上越來越自動化，越來越智能化。
問：近來容器潮席捲技術社區，我想問下，老師怎麼看待DevOps與Docker 結合解決痛點？
劉濤：對於DevOps與Docker結合的痛點，我覺的主要在於網絡的方面，這個影響會具體會影響到應用的自動化的部署上。之所以有這麼多的容器解決方案，有這麼多的編排方案，網絡方案，都是要解決連接問題。
現實中非常多的應用的架構並不是一個簡單的架構，而是分布式的，要想讓適用於大多數分布是應用的部署，首先要解決網絡層的連接，然後是各個應用組件的連接配置。
問：跨雲管理與持續交付的難點在於哪裡？您今天分享的方案是否使用此類場景？
劉濤：這個問題非常好。
跨雲管理的難點在於管理的覆蓋面和編排上，可以從幾個維度上看。
一個是縱向的覆蓋面，需要既覆蓋基礎設施層，也覆蓋應用層，而基礎設施層需要覆蓋資源的類型又有很多種，要想做到比較全面的覆蓋是一個很有難度的事情。
一個是橫向的維度，這個橫向的維度就是跨雲、跨網的編排，要做到這一點需要處理非常多的異構情況，同時要想跨網，需要在管理的設計上做一些特殊的處理。
對於持續交付的難點上，我覺的最大的難點不在於自動化和部署上，最大的難點在於能否在做到自動化部署發布之後的測試上。
如果在整個開發過程中，能夠比較好的做到自動化測試，加上完備的手工測試，才能真正做到持續交付。一個極端的例子就是，雖然實現了自動化的部署，但是部署後，如果沒有比較好的自動化測試，仍然將不得不花費很長的時間進行驗證，才能真正完成部署上線。
關於作者劉濤，目前在FIT2CLOUD從事雲管理和DevOps平台的研發工作，曾在InfoQ和CSDN發表過《國內雲建設普遍缺失的一環：雲管理平台》，《剖析AWS CodeDeploy》，《亞馬遜AWS認證攻略》，《DevOps系統的變遷及其關鍵使能技術》等文章。職業生涯的主要角色基本都在研發，也常常負責自身研發的產品服務的運維管理，經歷過傳統物理環境下的大規模移動網際網路服務的研發運維，也經歷過雲環境混合雲下的研發和運維，深切地體會到雲計算給我們研發和運維工作方式帶來的改變，效率上的巨大提升。
感謝魏星對本文的策劃和審校。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），：InfoQChina）關注我們。
