DevOps系統的變遷

一、DevOps的起源和發展歷程

在過去的幾十年里，為了按時交付軟件產品和服務，大家越來越意識到，對于傳統把開發和運營割裂開的做法，不適合現代產品和服務開發的需求。于是，把 開發和運營作為整體來看待的DevOps工程思想逐步深入人心，隨之也逐步有了對DevOps系統的需求，希望能有個平臺或工具來統一支持開發和運營的交 付工作及之后的環境管理工作，即需要一系列的持續集成，持續交付，自動化部署，自動化測試監控，自動化伸縮，自動化恢復系統，以提升開發測試運營過程中的 部署效率，簡化開發測試運維過程的管理，降低交付風險，降低溝通成本及運營成本。

從廣義來講，不管是云管理平臺工具(比如RightScale)，還是各種PaaS平臺(CloudFoundry，Heroku etc.)，還是自動化部署工具比如Chef、Puppet和Ansible等，其本質上都是DevOps系統的一部分，都是為了解決在開發過程的交付環 節問題和交付后的運營管理問題，即

• 在開發和測試過程中，幫助開發測試人員搭建和管理環境，以便在變更后部署變更以測試;
• 在運營和支持過程中，幫助運營支持人員升級系統，擴展重建恢復系統，在升級后能夠持續地掌握系統整體和各個棧的狀態，從各個層面監控系統，伸縮系統，恢復系統。

這些年，隨著云計算和容器技術的進步，以及產品業務對IT能力的需求推動，DevOps系統發展越來越快，其角色和概念也越來越清晰和獨立。回顧其 發展的路徑和變遷的過程，我們認為基本可以分為三代：基于物理機或獨立虛擬機的部署時代，基于IaaS可編程資源的部署時代和基于容器的部署時代。隨著這 三代的改進，DevOps系統的整體能力越來越強。下面我們首先看一下各代DevOps系統的特點和能力，之后再對DevOps系統進行更進一步的分類， 以幫助我們選擇合適的DevOps系統。

二、DevOps的變遷及其關鍵使能技術

1. 基于物理機/獨立虛機的部署時代

這是第一代DevOps系統，特點是靜態配置 + 人工協調 + 僅應用部分自動部署。

在搭建整個應用系統的過程中，首先需要在DevOps系統外創建運行應用所需的資源環境(如主機，網絡，存儲等)，DevOps系統對這部分沒有控 制，只負責在資源環境搭建好后自動化部署應用，資源環境的搭建與之后的應用部署過程是割裂開來的，需要人為的手工協調控制，即等資源環境搭建好后，由人控 制時機，等待資源環境準備好后再手工修改配置（如各種主機IP地址，登陸密碼Key信息），然后手工運行自動化腳本工具，如 Shell，Python，Ruby腳本，進行應用的安裝部署升級，而且之后當增加或減少節點后，也由人來手工運行自動化腳本來配置系統，不能實現包括資 源環境創建或節點變更到應用部署的整個過程的一鍵部署，即集群感知 + 自動協調控制 + 動態配置 + 全棧自動化。

目前，可以說大多數的DevOps系統仍然停留在這個階段，由于DevOps系統沒有實現資源環境創建的自動化與基于集群感知的協調自動化，那么這個階段的DevOps系統的能力會造成以下幾個影響和后果:

• 創建系統資源環境效率低、耗時、風險高，特別是創建復雜的系統組件多結構復雜時;
• 創建系統資源環境過程需要專門的網絡工程師、系統工程師，不能夠實現開發測試運維人員自助服務，系統越復雜，溝通成本越大，開發運維過程管理也越復雜;
• 創建整個系統需要網絡工程師，系統工程師，開發人員的共同參與和合作，系統組件越多結構越復雜，溝通成本越大，開發運維過程管理也越復雜，費時費力，協調麻煩，風險高且易出錯;
• 當系統資源環境變更時，如在增加減少主機后，由人來手工協調控制，人為手工靜態配置部署升級所需IP，登陸密碼或Key等信息，造成變更過程風險高且效率低，特別是系統龐大和復雜時;
• 交付過程風險高，開發測試產品各個環境不統一，經常出現在一個環境里運行正常，另外一個環境不正常的現象

這里需要提的一點就是，盡管很多組織已經在使用IaaS（如阿里云）創建虛擬機搭建應用系統所需資源環境，但是并沒有實現集群感知，系統整套環境創 建的自動化，仍然停留在半自動化的階段（例如，先啟動一組包年包月虛擬機后，然后手工配置部署腳本所需IP地址，登陸密碼，登陸密鑰等信息，然后手工運行 自動化腳本部署），所以這種方式仍然屬于第一代的DevOps系統。同時，這也是國內大多數組織DevOps的現狀，其自動化和效率的改進空間巨大。

2. 基于IaaS的部署時代

這是第二代DevOps系統，特點是集群感知 + 自動協調控制 + 動態配置 + 全棧自動化。

借助于云計算IaaS資源的可編程特性，這一代的DevOps系統實現了集群感知，自動協調控制，動態配置，全棧自動化，即實現了從創建環境到部署 安裝應用組件整個過程的一鍵創建和部署，并且在創建后的階段，能夠實現集群感知(Cluster-Aware)，即自動根據環境的變更，自動部署和配置系 統。舉個例子，某網站業務量增長需要擴容時，當人為添加Web計算節點后，能夠自動在新添加Web虛擬機啟動后安裝Web組件，并將各個虛擬機Web服務 注冊配置到負載均衡服務中，當收縮時，自動移除，這個過程不需要人為的協調控制，DevOps系統能夠根據集群的變化自動地配置集群。

目前，做到這個層面DevOps系統還是比較少的，由于這個階段的DevOps系統自動化管理覆蓋了環境的創建變更，應用組件部署自動化，以及環境 創建，集群感知和應用組件部署的各個過程自動化協調控制，那么這個階段的DevOps系統相比第一代會給開發和運維工作帶來以下非常巨大的改進:

• 開發測試運維人員能夠自助創建環境和部署系統，系統越復雜，溝通成本減少越多，開發運維過程管理復雜性風險減少越多，比如只能由有專門知識的工程師做，如果工程師在需要的時候不可用，就很麻煩;
• 創建環境和部署效率高，自動化，快速，所需時間少，風險低;
• 當系統資源環境變更時，如伸縮時，在增加減少主機后，能夠實現集群感知，動態配置集群，提高變更過程效率且降低風險，特別是系統組件多龐大和復雜時;
• 能夠按需快速創建環境滿足各種測試，演示，上線擴容需要
• 能夠按需創建啟動關閉開發測試環境，節約成本
• 能夠提高開發測試和交付的效率

3. 基于容器的部署時代

這是第三代DevOps系統，特點是在第二代基礎上，又增加了應用跨云可遷移性。(基于容器技術)。

借助于云計算IaaS資源的可編程特性以及Linux容器技術，不僅實現了集群感知，自動化協調，動態配置和全棧自動化，而且實現了應用跨云可遷移 性和彈性伸縮，消除了開發，測試，生產環境的不一致，使應用不會被鎖定在某個IaaS上，讓所有的基礎設施服務IaaS及物理機都變成通用的資源池，還可 以提高資源利用率，這給IT的開發建設和運營帶來了更多更大的想象空間，這也是Docker，Kubernetes現在很火的原因。

舉個例子: 如果我們想把一套服務從AWS遷移到Azure上，那么，我們將不得不從頭開始創建一組虛擬機鏡像及虛擬機，并配置安裝系統或應用的組件，如果系統復雜龐 大的話，這個過程仍然會耗費很多的時間和人工，并且依賴于某些具備這個知識的工程師，但是如果有容器技術及相關容器工具的支持，那么這個過程會變成一個非 常快速簡單的過程，變成在目標云如Azure上自動啟動需要的標準虛擬機，然后下載容器鏡像，配置啟動容器，配置相關DNS等，真正實現方便的跨云遷移， 和彈性動態的伸縮服務。

再舉個例子，目前Google開源的容器管理系統Kubernetes可以說得到了工業界的廣泛認同和支持，當我們已經做好應用系統的Docker images后，那么只要在各個不同的IaaS上有支持Docker的環境，如Kubernetes集群，那么我們就能在不同的IaaS上快速方便的遷移 應用系統，或者擴容，下圖展示了基于FIT2CLOUD的跨云部署和管理解決方案，我們希望未來用戶可以使用FIT2CLOUD在多個不同的IaaS上創 建Kubernetes集群，通過Kubernetes管理和部署應用系統。之后，我們會有新文章來分享FIT2CLOUD是如何創建和運維 Kunerbetes集群的。

上面這一節中我們介紹了不同時代的DevOps系統的特點和能力，那么是不是我們直接選擇能力最強的第三代DevOps系統就可以了嗎? 是不是選一種DevOps系統就通殺了呢? 答案是否定的，每種DevOps系統都不是銀彈，都需要我們根據要管理的系統的需求來選擇合適的DevOps系統或工具，在接下來的一節，我們來回答這個 問題。

三、如何選擇適合自己的DevOps系統？

目前DevOps系統可以說五花八門非常多，功能上差別大，適用場景也不同，那么我們究竟該如何選擇合適的DevOps系統呢? 這里我們建議一種基于目標系統分類的選擇方法。我們根據要管理的目標應用或系統類型來分類，對于目標系統，我們可以將其首先分為三大類，即IaaS服務系 統，PaaS服務系統，應用系統，應用系統又可以分為簡單的Web應用系統，復雜的分布式系統，那么有了這個分類，我們選擇DevOps系統和工具就會相 對容易和明確一些。

1. IaaS服務系統

由于IaaS系統的創建，本身就是基于物理機創建的，所以對于這類的系統，其適用的DevOps系統或工具就是Shell，Chef， Puppet及IaaS服務提供商自身開發的自動化運維管理系統，只能選用第一代的基于物理機的DevOps系統。

2. PaaS服務系統

如果一個PaaS不是部署在IaaS之上，從本質上說這不是一個PaaS，因為其不具備彈性和自動伸縮。真正的PaaS系統是部署在IaaS上，為 開發測試運維人員來提供服務，那么其適用的DevOps工具就可以選用 RightScale，Scalr，Cloudformation，Opsworks和FIT2CLOUD這類第二代基于IaaS可編程資源的 DevOps系統，當然也可以選擇第三代基于容器的DevOps系統，只是第三代的目前還在發展中，還不如第二代成熟。

3. 簡單的Web應用系統

對于簡單的Web應用系統，突出的特點就是應用的結構簡單，比如只包含一個Web組件及數據庫，緩存，或一些常見的中間件服務等，沒有包含非常多的 分布式組件，那么對于這類的系統可以選擇容器類的傳統PaaS，即CloudFoundry，Heroku，OpenShift等。

4. 復雜的分布式應用系統

對于復雜的分布式應用系統，無法使用容器類PaaS來管理，只能通過自定義的DevOps工具或系統，或者使用云管理 RightScale，Scalr，Cloudformation，Opsworks，FIT2CLOUD這類工具的某種或某種組合，即第二代基于 IaaS可編程資源的DevOps系統，也可以選擇第三代基于容器的DevOps系統。因為這類工具給用戶提供了對IaaS主機更大的控制權，且提供了各 個部署過程中的回調接口，實現了集群感知及各個部署過程的自動協調控制，即全棧自動化。

以上是我們對DevOps系統變遷的一些思考，大家通過微博和我們進行討論，我們的微博是：@fit2cloud。

來自：http://blog.fit2cloud.com/2014/12/14/devops-system-evolution.html