編者按：從軟件工程初期發(fā)展的獨立主義到90年代開始強調了軟件工程化到今天完全進化成為一個產業(yè)鏈，這就是我們現(xiàn)在談的DevOps。本文從DevOps的起源和發(fā)展歷程，到DevOps的變遷及其關鍵使能技術，以及如何選擇適合自己的DevOps系統(tǒng)等三個方面詳解了系統(tǒng)的變遷過程。作者微博是：@fit2cloud，如果有對DevOps感興趣的朋友可以跟進行討論。

一、DevOps的起源和發(fā)展歷程

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

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

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

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

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

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

這是第一代DevOps系統(tǒng)，特點是靜態(tài)配置 + 人工協(xié)調 + 僅應用部分自動部署。

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

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

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

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

2. 基于IaaS的部署時代

這是第二代DevOps系統(tǒng)，特點是集群感知 + 自動協(xié)調控制 + 動態(tài)配置 + 全棧自動化。

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

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

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

3. 基于容器的部署時代

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

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

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

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

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

三、如何選擇適合自己的DevOps系統(tǒng)？

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

1. IaaS服務系統(tǒng)

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

2. PaaS服務系統(tǒng)

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

3. 簡單的Web應用系統(tǒng)

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

4. 復雜的分布式應用系統(tǒng)

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

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