<a target="_blank"></a>
在過去的幾十年裡，為了按時傳遞軟體産品和服務，大家越來越意識到，對于傳統把開發和營運割裂開的做法，不适合現代産品和服務開發的需求。于是，把 開發和營運作為整體來看待的devops工程思想逐漸深入人心，随之也逐漸有了對devops系統的需求，希望能有個平台或工具來統一支援開發和營運的交 付工作及之後的環境管理工作，即需要一系列的持續內建，持續傳遞，自動化部署，自動化測試監控，自動化伸縮，自動化恢複系統，以提升開發測試營運過程中的 部署效率，簡化開發測試運維過程的管理，降低傳遞風險，降低溝通成本及營運成本。
開發營運統一的devops系統
從廣義來講，不管是雲管理平台工具(比如rightscale)，還是各種paas平台(cloudfoundry，heroku etc.)，還是自動化部署工具比如chef、puppet和ansible等，其本質上都是devops系統的一部分，都是為了解決在開發過程的傳遞環 節問題和傳遞後的營運管理問題，即
在開發和測試過程中，幫助開發測試人員搭建和管理環境，以便在變更後部署變更以測試;
在營運和支援過程中，幫助營運支援人員更新系統，擴充重建恢複系統，在更新後能夠持續地掌握系統整體和各個棧的狀态，從各個層面監控系統，伸縮系統，恢複系統。
這些年，随着雲計算和容器技術的進步，以及産品業務對it能力的需求推動，devops系統發展越來越快，其角色和概念也越來越清晰和獨立。回顧其 發展的路徑和變遷的過程，我們認為基本可以分為三代：基于實體機或獨立虛拟機的部署時代，基于iaas可程式設計資源的部署時代和基于容器的部署時代。随着這 三代的改進，devops系統的整體能力越來越強。下面我們首先看一下各代devops系統的特點和能力，之後再對devops系統進行更進一步的分類， 以幫助我們選擇合适的devops系統。
這是第一代devops系統，特點是靜态配置 + 人工協調 + 僅應用部分自動部署。
在搭建整個應用系統的過程中，首先需要在devops系統外建立運作應用所需的資源環境(如主機，網絡，存儲等)，devops系統對這部分沒有控 制，隻負責在資源環境搭建好後自動化部署應用，資源環境的搭建與之後的應用部署過程是割裂開來的，需要人為的手工協調控制，即等資源環境搭建好後，由人控 制時機，等待資源環境準備好後再手工修改配置（如各種主機ip位址，登陸密碼key資訊），然後手工運作自動化腳本工具，如 shell，python，ruby腳本，進行應用的安裝部署更新，而且之後當增加或減少節點後，也由人來手工運作自動化腳本來配置系統，不能實作包括資 源環境建立或節點變更到應用部署的整個過程的一鍵部署，即叢集感覺 + 自動協調控制 + 動态配置 + 全棧自動化。
第一代devops系統
目前，可以說大多數的devops系統仍然停留在這個階段，由于devops系統沒有實作資源環境建立的自動化與基于叢集感覺的協調自動化，那麼這個階段的devops系統的能力會造成以下幾個影響和後果:
建立系統資源環境效率低、耗時、風險高，特别是建立複雜的系統元件多結構複雜時;
建立系統資源環境過程需要專門的網絡工程師、系統工程師，不能夠實作開發測試運維人員自助服務，系統越複雜，溝通成本越大，開發運維過程管理也越複雜;
建立整個系統需要網絡工程師，系統工程師，開發人員的共同參與和合作，系統元件越多結構越複雜，溝通成本越大，開發運維過程管理也越複雜，費時費力，協調麻煩，風險高且易出錯;
當系統資源環境變更時，如在增加減少主機後，由人來手工協調控制，人為手工靜态配置部署更新所需ip，登陸密碼或key等資訊，造成變更過程風險高且效率低，特别是系統龐大和複雜時;
傳遞過程風險高，開發測試産品各個環境不統一，經常出現在一個環境裡運作正常，另外一個環境不正常的現象
這裡需要提的一點就是，盡管很多組織已經在使用iaas（如阿裡雲）建立虛拟機搭建應用系統所需資源環境，但是并沒有實作叢集感覺，系統整套環境創 建的自動化，仍然停留在半自動化的階段（例如，先啟動一組包年包月虛拟機後，然後手工配置部署腳本所需ip位址，登陸密碼，登陸密鑰等資訊，然後手工運作 自動化腳本部署），是以這種方式仍然屬于第一代的devops系統。同時，這也是國内大多數組織devops的現狀，其自動化和效率的改進空間巨大。
這是第二代devops系統，特點是叢集感覺 + 自動協調控制 + 動态配置 + 全棧自動化。
借助于雲計算iaas資源的可程式設計特性，這一代的devops系統實作了叢集感覺，自動協調控制，動态配置，全棧自動化，即實作了從建立環境到部署 安裝應用元件整個過程的一鍵建立和部署，并且在建立後的階段，能夠實作叢集感覺(cluster-aware)，即自動根據環境的變更，自動部署和配置系 統。舉個例子，某網站業務量增長需要擴容時，當人為添加web計算節點後，能夠自動在新添加web虛拟機啟動後安裝web元件，并将各個虛拟機web服務 注冊配置到負載均衡服務中，當收縮時，自動移除，這個過程不需要人為的協調控制，devops系統能夠根據叢集的變化自動地配置叢集。
第二代devops系統
目前，做到這個層面devops系統還是比較少的，由于這個階段的devops系統自動化管理覆寫了環境的建立變更，應用元件部署自動化，以及環境 建立，叢集感覺和應用元件部署的各個過程自動化協調控制，那麼這個階段的devops系統相比第一代會給開發和運維工作帶來以下非常巨大的改進:
開發測試運維人員能夠自助建立環境和部署系統，系統越複雜，溝通成本減少越多，開發運維過程管理複雜性風險減少越多，比如隻能由有專門知識的工程師做，如果工程師在需要的時候不可用，就很麻煩;
建立環境和部署效率高，自動化，快速，所需時間少，風險低;
當系統資源環境變更時，如伸縮時，在增加減少主機後，能夠實作叢集感覺，動态配置叢集，提高變更過程效率且降低風險，特别是系統元件多龐大和複雜時;
能夠按需快速建立環境滿足各種測試，示範，上線擴容需要
能夠按需建立啟動關閉開發測試環境，節約成本
能夠提高開發測試和傳遞的效率
這是第三代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系統和工具就會相 對容易和明确一些。
由于iaas系統的建立，本身就是基于實體機建立的，是以對于這類的系統，其适用的devops系統或工具就是shell，chef， puppet及iaas服務提供商自身開發的自動化運維管理系統，隻能選用第一代的基于實體機的devops系統。
如果一個paas不是部署在iaas之上，從本質上說這不是一個paas，因為其不具備彈性和自動伸縮。真正的paas系統是部署在iaas上，為 開發測試運維人員來提供服務，那麼其适用的devops工具就可以選用 rightscale，scalr，cloudformation，opsworks和fit2cloud這類第二代基于iaas可程式設計資源的 devops系統，當然也可以選擇第三代基于容器的devops系統，隻是第三代的目前還在發展中，還不如第二代成熟。
對于簡單的web應用系統，突出的特點就是應用的結構簡單，比如隻包含一個web元件及資料庫，緩存，或一些常見的中間件服務等，沒有包含非常多的 分布式元件，那麼對于這類的系統可以選擇容器類的傳統paas，即cloudfoundry，heroku，openshift等。
對于複雜的分布式應用系統，無法使用容器類paas來管理，隻能通過自定義的devops工具或系統，或者使用雲管理 rightscale，scalr，cloudformation，opsworks，fit2cloud這類工具的某種或某種組合，即第二代基于 iaas可程式設計資源的devops系統，也可以選擇第三代基于容器的devops系統。因為這類工具給使用者提供了對iaas主機更大的控制權，且提供了各 個部署過程中的回調接口，實作了叢集感覺及各個部署過程的自動協調控制，即全棧自動化。
原文釋出時間：2014-12-23
本文來自雲栖合作夥伴“linux中國”