火箭仍是飛機？——DevOps 的兩種模式

文章來自 | JFrog傑蛙DevOps微信公衆號。

做者 | 高欣，JFrog架構師。2019年6月21-23日，GIAC大會DevOps工具鏈專場講師，他將爲你們分享《Kubernetes上的DevSecOps ——JFrog的Kubernetes之旅》的話題，點擊此處便可獲取大會PPT。

背景

在當下的軟件應用開發領域中，愈來愈多的敏捷化企業但願本身的軟件開發過程能以超音速、甚至於星際穿梭的速度，來快速響應各類變化，但同時還要保證安全性。DevOps 流水線無疑爲這一目標提供了最佳實踐。

可是，要徹底知足這樣的需求，咱們應該如何去創建合適的 DevOps 流水線呢？有沒有一種很好的方式，可以幫助咱們去理解 DevOps 流水線當中 CI/CD 過程，以及容器技術，如 Docker 和 Kubernetes，在其中的角色和影響呢？

其實，DevOps 流水線的建設能夠類比爲兩種模式：火箭式或飛機式。從衆多客戶的應用實踐來看，要想運行一個完善的、可靠的 DevOps 流水線，火箭式的建設是遠遠不夠的，實際遇到的困難要大得多。

火箭發射模式

咱們一般把 DevOps 流水線理解爲一個簡單的、從左到右的線性過程：編寫代碼、提交、構建、測試、部署，以及做爲產品發佈。建立出來的軟件在流水線當中就像被裝船運送同樣，有着清晰定義的去向。

在這種模式下，建立一個應用程序就像發射登錄火星的火箭同樣。在容許登錄任務繼續進行以前，必需要計劃、審批、測試，以及驗證全部的工做。爲了準備發射，全部團隊必須緊密地協同工做。咱們只有一次機會去發射這個火箭，並且火箭一旦發射，就再沒有機會進行修改和更新。從發射臺到最終到達火星，火箭的功能是固定的、不可修改的。

火箭發射是一次性的。每一次測試都須要建立一個新的火箭，而這會帶來一些未知的風險。新的火箭須要在確認全部系統都準備好了以後才能發射，以完成承擔的任務。

這是一個清晰的、經典的工程模型。可是，這不是 DevOps 應有的工做方式。

航班運行模式

上述火箭模式中比較好的 DevOps 實踐是在建立和運行服務時，開發和運維團隊在研發生命週期的各個階段都緊密地合做。

然而，DevOps 並非像高風險火箭發射那樣簡單的從左到右的線性過程。相反，它是一個頻繁觸發且不會終止的循環過程，並且每一次觸發都會引入一些新的的風險。因此，DevOps更像是現代的航空系統。在任什麼時候間，全球的航空公司都頻繁地，事實上是連續地，發送着航班，運載着上百萬對其充滿信任的旅客。

航空公司管理其飛機和航線的流程，和 DevOps 流水線保證應用發佈時效性和可靠性的方法是十分相像的。和軟件企業同樣，航空公司同樣要緊跟技術的發展、快速響應安全問題，以及適應客戶需求的變化，同時還要保證整個系統不中斷地運行。在平常運營中，航空公司持續對每架飛機進行檢查（測試）、維護（打補丁），以及安排運營時間。這個過程和 DevOps 中應用的持續集成、更新和交付過程很是相似的。

和火箭發射的一次性不一樣，飛機可以反覆地執行起飛和降低，最終執行航線任務的和最初經過測試飛行的都是同一架飛機，這充分代表了兩種模式的差別性。那麼，怎樣才能保證 DevOps 流水線運轉得更像是一個航空公司，而不是一名火箭兵呢？

起飛前的清理工做

火箭和飛機都是由許多資源組成的產品，不一樣的生產部門分別負責結構、機械和控制系統等各個部分，並且是由不一樣的供應商提供大部分的組件，從最基本的如門鎖、座椅、地毯等，直到複雜的如導航系統等。

相似的，每個軟件應用也是由組織內的多個團隊共同建立的，並且應用運行的大部分代碼，例如操做系統和語言框架等，都是以企業外部的遠程倉庫爲來源的。

開發人員能夠控制將本身開發代碼的哪些部分加入構建。可是，對於從公共倉庫下載的外部依賴包，如 npm 或 maven 等，又該如何控制呢？那些包可能會不按期的進行修改，而這是你沒法控制的。

若是你的 DevOps 流水線像發射火箭同樣，那麼針對測試或發佈的每次新構建，都會成爲偷渡者潛入火箭的機會。若是沒法作到持續監控，那些計劃以外的東西就可能進入新的構建，從而致使每次構建都不能得到徹底相同的結果。

前往跑道

Docker 鏡像就像是飛行器，不論是火箭仍是飛機，經過構建而成，並封裝了應用要執行的全部功能。從發射到着陸，Docker 鏡像的能力保持不變。

Docker 引擎，結合鏡像倉庫，把鏡像轉換爲容器，就像把這些飛行器推送到發射平臺。而像 Kubernetes 這樣的編排工具就進一步把這些容器發射到航線上去。

若是像處理火箭同樣，每次發射一個新的，那在開發、測試，或發佈階段構建的每一個 Docker 鏡像，都有可能和前一個有一些不一樣。

而若是像飛機同樣處理，就意味着對發射到空中的內容有更大的肯定性。航空公司不會爲每次起飛都製造一架新的飛機。他們只是測試飛機，而後在航線上可靠地運行飛機，直到飛機須要更換爲止。

構建一個 Docker 鏡像，而後在測試到發佈的流水線上進行升級，而不是從新構建，可以確保這個鏡像帶上航線的都能每次、準時、安全地飛翔。

地面控制

正如上述分析的，真正的 DevOps 流水線不是簡單的從左到右的線性過程，而是設計、分解和重構的複雜、迭代、網絡化的過程。

爲了使 DevOps 流水線運轉得更像是航空公司， Artifactory 能夠做爲地勤人員，來保證一切都按計劃、平穩地運行。Artifactory 使得開發人員可以控制從代碼構建而來的 Docker 鏡像，並經過老是在航線中運行同一架飛機來保證可靠性和速度。

首先，Artifactory 解決了一個開發人員面對的關鍵挑戰，那就是利用如 npm 或 maven 這樣的外部依賴，也能進行持久、肯定的構建。利用 Artifactory，開發人員可以維護外部倉庫的本地緩存，從而保證外部代碼的變化在沒有確承認用以前不會被引入到構建當中。並且，保證外部依賴的本地訪問，也能幫助加速構建，提高生產力。

利用 Artifactory 做爲 Docker 鏡像中心，可使得 DevOps 流水線中從測試到發佈的各個階段之間升級實不可變的構建產出變得更加容易，而不須要每次都從新構建。一樣能夠根據須要，利用 Artifactory 爲每次構建存儲的詳盡信息，來建立新的肯定性的構建。

飛機飛行須要燃料，而航空公司，就像全部現代化企業同樣，基於數據進行運維。航空公司對他們的飛機、客戶和工做人員瞭解得越多，就越能幫助他們最大限度地提升投資回報率。

Artifactory 做爲 Kubernetes 的 Docker 鏡像中心，能夠提供簡化、安全實施運維工做所需的數據。除了容器、鏡像的列表以外，Artifactory 還能夠可視化地展現容器裏都有什麼，以及這些內容是如何進入容器的。

若是再增長利用 JFrog Xray 對鏡像進行掃描，就能夠得到更多有關鏡像當中代碼真實安全性的信息，進一步保護企業和應用。

翱翔天空

不只僅像本文說的，真正的 DevOps 流水線就像是現代化的航空公司，DevOps 已成爲大多數航空公司自身運營的關鍵實踐。聯合航空公司、西南航空公司、阿拉斯加航空公司和捷藍航空公司就是衆多航空公司的表明，它們已經爲 DevOps 和 CI/CD 作了大量的投資，在網絡和移動平臺上爲其客戶提供購票、值機、登機等各類服務。這些航空公司不少都引入了 Artifactory，得到了在全球範圍發展 DevOps 的巨大收益。

正如這些高風險企業所展現的，僅僅將 Docker 容器推上跑道，對於真正的 DevOps 是不夠的，須要利用 Artifactory 爲 CI/CD 提供的支持，來確保它們在天空中安全地飛翔。

GIAC大會

高欣將於6月21-23日，做爲本屆GIAC全球互聯網架構大會講師爲咱們分享《Kubernetes上的DevSecOps ——JFrog的Kubernetes之旅》的話題，具體議題可戳圖片瞭解。

第五屆GIAC大會將於6月21-23日在深圳博林聖海倫酒店再度強勢來襲。

本屆大會，組委會邀請到了105位來自Google、微軟、Oracle、eBay、百度、阿里、騰訊、商湯、圖森、字節跳動、新浪、美團點評等一線互聯網大廠嘉賓出席，圍繞AI、大中臺、Cloud-Native、IoT、混沌工程、Fintech、數據及商業智能、工程文化及管理、經典架構等專題分享他們的實踐經驗、遇到的問題及解決方案。如下爲本屆峯會精選案例：