掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
編者按:從軟件工程初期發(fā)展的獨立主義到90年代開始強調(diào)了軟件工程化到今天完全進化成為一個產(chǎn)業(yè)鏈,這就是我們現(xiàn)在談的DevOps。本文從DevOps的起源和發(fā)展歷程,到DevOps的變遷及其關(guān)鍵使能技術(shù),以及如何選擇適合自己的DevOps系統(tǒng)等三個方面詳解了系統(tǒng)的變遷過程。作者微博是:@fit2cloud,如果有對DevOps感興趣的朋友可以跟進行討論。

成都創(chuàng)新互聯(lián)公司咨詢電話:18982081108,為您提供成都網(wǎng)站建設(shè)網(wǎng)頁設(shè)計及定制高端網(wǎng)站建設(shè)服務(wù),成都創(chuàng)新互聯(lián)公司網(wǎng)頁制作領(lǐng)域10年,包括宣傳片制作等多個行業(yè)擁有豐富的網(wǎng)站營銷經(jīng)驗,選擇成都創(chuàng)新互聯(lián)公司,為網(wǎng)站錦上添花!
在過去的幾十年里,為了按時交付軟件產(chǎn)品和服務(wù),大家越來越意識到,對于傳統(tǒng)把開發(fā)和運營割裂開的做法,不適合現(xiàn)代產(chǎn)品和服務(wù)開發(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等,其本質(zhì)上都是DevOps系統(tǒng)的一部分,都是為了解決在開發(fā)過程的交付環(huán)節(jié)問題和交付后的運營管理問題,即
這些年,隨著云計算和容器技術(shù)的進步,以及產(chǎn)品業(yè)務(wù)對IT能力的需求推動,DevOps系統(tǒng)發(fā)展越來越快,其角色和概念也越來越清晰和獨立?;仡櫰浒l(fā)展的路徑和變遷的過程,我們認為基本可以分為三代:基于物理機或獨立虛擬機的部署時代,基于IaaS可編程資源的部署時代和基于容器的部署時代。隨著這三代的改進,DevOps系統(tǒng)的整體能力越來越強。下面我們首先看一下各代DevOps系統(tǒng)的特點和能力,之后再對DevOps系統(tǒng)進行更進一步的分類,以幫助我們選擇合適的DevOps系統(tǒng)。
這是第一代DevOps系統(tǒng),特點是靜態(tài)配置 + 人工協(xié)調(diào) + 僅應(yīng)用部分自動部署。
在搭建整個應(yīng)用系統(tǒng)的過程中,首先需要在DevOps系統(tǒng)外創(chuàng)建運行應(yīng)用所需的資源環(huán)境(如主機,網(wǎng)絡(luò),存儲等),DevOps系統(tǒng)對這部分沒有控制,只負責在資源環(huán)境搭建好后自動化部署應(yīng)用,資源環(huán)境的搭建與之后的應(yīng)用部署過程是割裂開來的,需要人為的手工協(xié)調(diào)控制,即等資源環(huán)境搭建好后,由人控制時機,等待資源環(huán)境準備好后再手工修改配置(如各種主機IP地址,登陸密碼Key信息),然后手工運行自動化腳本工具,如Shell,Python,Ruby腳本,進行應(yīng)用的安裝部署升級,而且之后當增加或減少節(jié)點后,也由人來手工運行自動化腳本來配置系統(tǒng),不能實現(xiàn)包括資源環(huán)境創(chuàng)建或節(jié)點變更到應(yīng)用部署的整個過程的一鍵部署,即集群感知 + 自動協(xié)調(diào)控制 + 動態(tài)配置 + 全棧自動化。
目前,可以說大多數(shù)的DevOps系統(tǒng)仍然停留在這個階段,由于DevOps系統(tǒng)沒有實現(xiàn)資源環(huán)境創(chuàng)建的自動化與基于集群感知的協(xié)調(diào)自動化,那么這個階段的DevOps系統(tǒng)的能力會造成以下幾個影響和后果:
這里需要提的一點就是,盡管很多組織已經(jīng)在使用IaaS(如阿里云)創(chuàng)建虛擬機搭建應(yīng)用系統(tǒng)所需資源環(huán)境,但是并沒有實現(xiàn)集群感知,系統(tǒng)整套環(huán)境創(chuàng)建的自動化,仍然停留在半自動化的階段(例如,先啟動一組包年包月虛擬機后,然后手工配置部署腳本所需IP地址,登陸密碼,登陸密鑰等信息,然后手工運行自動化腳本部署),所以這種方式仍然屬于第一代的DevOps系統(tǒng)。同時,這也是國內(nèi)大多數(shù)組織DevOps的現(xiàn)狀,其自動化和效率的改進空間巨大。
這是第二代DevOps系統(tǒng),特點是集群感知 + 自動協(xié)調(diào)控制 + 動態(tài)配置 + 全棧自動化。
借助于云計算IaaS資源的可編程特性,這一代的DevOps系統(tǒng)實現(xiàn)了集群感知,自動協(xié)調(diào)控制,動態(tài)配置,全棧自動化,即實現(xiàn)了從創(chuàng)建環(huán)境到部署安裝應(yīng)用組件整個過程的一鍵創(chuàng)建和部署,并且在創(chuàng)建后的階段,能夠?qū)崿F(xiàn)集群感知(Cluster-Aware),即自動根據(jù)環(huán)境的變更,自動部署和配置系統(tǒng)。舉個例子,某網(wǎng)站業(yè)務(wù)量增長需要擴容時,當人為添加Web計算節(jié)點后,能夠自動在新添加Web虛擬機啟動后安裝Web組件,并將各個虛擬機Web服務(wù)注冊配置到負載均衡服務(wù)中,當收縮時,自動移除,這個過程不需要人為的協(xié)調(diào)控制,DevOps系統(tǒng)能夠根據(jù)集群的變化自動地配置集群。
目前,做到這個層面DevOps系統(tǒng)還是比較少的,由于這個階段的DevOps系統(tǒng)自動化管理覆蓋了環(huán)境的創(chuàng)建變更,應(yīng)用組件部署自動化,以及環(huán)境創(chuàng)建,集群感知和應(yīng)用組件部署的各個過程自動化協(xié)調(diào)控制,那么這個階段的DevOps系統(tǒng)相比第一代會給開發(fā)和運維工作帶來以下非常巨大的改進:
這是第三代DevOps系統(tǒng),特點是在第二代基礎(chǔ)上,又增加了應(yīng)用跨云可遷移性。(基于容器技術(shù))。
借助于云計算IaaS資源的可編程特性以及Linux容器技術(shù),不僅實現(xiàn)了集群感知,自動化協(xié)調(diào),動態(tài)配置和全棧自動化,而且實現(xiàn)了應(yīng)用跨云可遷移性和彈性伸縮,消除了開發(fā),測試,生產(chǎn)環(huán)境的不一致,使應(yīng)用不會被鎖定在某個IaaS上,讓所有的基礎(chǔ)設(shè)施服務(wù)IaaS及物理機都變成通用的資源池,還可以提高資源利用率,這給IT的開發(fā)建設(shè)和運營帶來了更多更大的想象空間,這也是Docker,Kubernetes現(xiàn)在很火的原因。
舉個例子: 如果我們想把一套服務(wù)從AWS遷移到Azure上,那么,我們將不得不從頭開始創(chuàng)建一組虛擬機鏡像及虛擬機,并配置安裝系統(tǒng)或應(yīng)用的組件,如果系統(tǒng)復雜龐大的話,這個過程仍然會耗費很多的時間和人工,并且依賴于某些具備這個知識的工程師,但是如果有容器技術(shù)及相關(guān)容器工具的支持,那么這個過程會變成一個非??焖俸唵蔚倪^程,變成在目標云如Azure上自動啟動需要的標準虛擬機,然后下載容器鏡像,配置啟動容器,配置相關(guān)DNS等,真正實現(xiàn)方便的跨云遷移,和彈性動態(tài)的伸縮服務(wù)。
再舉個例子,目前Google開源的容器管理系統(tǒng)Kubernetes可以說得到了工業(yè)界的廣泛認同和支持,當我們已經(jīng)做好應(yīng)用系統(tǒng)的Docker images后,那么只要在各個不同的IaaS上有支持Docker的環(huán)境,如Kubernetes集群,那么我們就能在不同的IaaS上快速方便的遷移應(yīng)用系統(tǒng),或者擴容,下圖展示了基于FIT2CLOUD的跨云部署和管理解決方案,我們希望未來用戶可以使用FIT2CLOUD在多個不同的IaaS上創(chuàng)建Kubernetes集群,通過Kubernetes管理和部署應(yīng)用系統(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)呢? 這里我們建議一種基于目標系統(tǒng)分類的選擇方法。我們根據(jù)要管理的目標應(yīng)用或系統(tǒng)類型來分類,對于目標系統(tǒng),我們可以將其首先分為三大類,即IaaS服務(wù)系統(tǒng),PaaS服務(wù)系統(tǒng),應(yīng)用系統(tǒng),應(yīng)用系統(tǒng)又可以分為簡單的Web應(yīng)用系統(tǒng),復雜的分布式系統(tǒng),那么有了這個分類,我們選擇DevOps系統(tǒng)和工具就會相對容易和明確一些。
由于IaaS系統(tǒng)的創(chuàng)建,本身就是基于物理機創(chuàng)建的,所以對于這類的系統(tǒng),其適用的DevOps系統(tǒng)或工具就是Shell,Chef, Puppet及IaaS服務(wù)提供商自身開發(fā)的自動化運維管理系統(tǒng),只能選用第一代的基于物理機的DevOps系統(tǒng)。
如果一個PaaS不是部署在IaaS之上,從本質(zhì)上說這不是一個PaaS,因為其不具備彈性和自動伸縮。真正的PaaS系統(tǒng)是部署在IaaS上,為開發(fā)測試運維人員來提供服務(wù),那么其適用的DevOps工具就可以選用RightScale,Scalr,Cloudformation,Opsworks和FIT2CLOUD這類第二代基于IaaS可編程資源的DevOps系統(tǒng),當然也可以選擇第三代基于容器的DevOps系統(tǒng),只是第三代的目前還在發(fā)展中,還不如第二代成熟。
對于簡單的Web應(yīng)用系統(tǒng),突出的特點就是應(yīng)用的結(jié)構(gòu)簡單,比如只包含一個Web組件及數(shù)據(jù)庫,緩存,或一些常見的中間件服務(wù)等,沒有包含非常多的分布式組件,那么對于這類的系統(tǒng)可以選擇容器類的傳統(tǒng)PaaS,即CloudFoundry,Heroku,OpenShift等。
對于復雜的分布式應(yīng)用系統(tǒng),無法使用容器類PaaS來管理,只能通過自定義的DevOps工具或系統(tǒng),或者使用云管理RightScale,Scalr,Cloudformation,Opsworks,F(xiàn)IT2CLOUD這類工具的某種或某種組合,即第二代基于IaaS可編程資源的DevOps系統(tǒng),也可以選擇第三代基于容器的DevOps系統(tǒng)。因為這類工具給用戶提供了對IaaS主機更大的控制權(quán),且提供了各個部署過程中的回調(diào)接口,實現(xiàn)了集群感知及各個部署過程的自動協(xié)調(diào)控制,即全棧自動化。
本文出自:http://blog.fit2cloud.com/2014/12/14/devops-system-evolution.html

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流