轉載本文需注明出處：微信公眾號EAWorld，違者必究。

前言：

近些年來，DevOps的理念已經逐漸深入人心，隨著容器、Docker、Kubernetes、OpenShift等概念不斷走進我們的視野，越來越多的企業開始在生產中運用這些技術。在這些技術和理念帶來的便利性不斷為軟件開發賦能的同時，有人可能會產生這樣的疑問，Kubernetes和OpenShift這樣的技術如何加入DevOps的工具鏈大家族，進一步提高生產效率和生產質量。

今天，讓我來帶大家一起探究一下DevOps如何與OpenShift結合達成1+1>2的效果。

容器是什么？

容器是一種內核輕量級的操作系統層虛擬化技術。

容器的本質，一句話解釋，就是一組受到資源限制，彼此間相互隔離的進程

Docker屬于容器服務的一種，是一個開源的應用容器引擎。

容器具有哪些特點？

1. 極其輕量：只打包了必要的Bin/Lib；

2. 秒級部署：根據鏡像的不同，容器的部署大概在毫秒與秒之間（比虛擬機強很多）；

3. 易于移植：一次構建，隨處部署；

4. 彈性伸縮：Kubernetes、Swam、Mesos這類開源、方便、易用的容器管理平臺有著非常強大的彈性管理能力。

使用容器化技術能帶來哪些好處？

在傳統的開發場景下，開發測試團隊和生產運維團隊使用的是不同的基礎設施，通常都會使用相同介質和不同的配置文件來區分環境，但是在環境的轉換過程中，還是會出現一些由于團隊協作或者環境依賴造成的問題。而容器化帶來的最大便利就在于，他能夠簡化團隊間的協作關系，容器鏡像的構建打包的也不僅是應用，而是應用運行所在的全部運行環境，這種方式屏蔽了由于環境不同帶來的問題。這樣以來，無論是在什么環境下運行，這個應用所需要的環境、依賴都是高度一致的。

當容器的數量達到一定量級的時候，如何對容器進行高效的維護和管理呢？

答案是使用Kubernetes容器管理工具。

什么是Kubernetes？

Kubernetes，是一個容器集群管理系統，可以實現容器集群的自動化部署、自動擴縮容、維護等功能，保證應用的高可用。

通過Kubernetes你可以：

1. 快速部署應用

2. 快速擴展應用，對應用進行擴容

3. 無縫對接新的應用功能

4. 節省資源，優化硬件資源的使用

Kubernetes具有哪些特點？

1. 可移植: 支持公有云，私有云，混合云，多重云

2. 可擴展: 模塊化, 插件化, 可掛載, 可組合

3. 自動化: 自動部署，自動重啟，自動復制，自動伸縮/擴展

OpenShift是什么？

OpenShift是一個基于主流的容器技術Docker和Kubernetes構建的云平臺，OpenShift底層以docker作為容器引擎驅動，以Kubernetes作為容器編排引擎組件，同時，OpenShift提供了開發語言、中間件、自動化流程工具及界面等元素，提供了一套完整的基于容器的應用云平臺。

你可以簡單的把OpenShift理解為Kubernetes PRO PLUS所以我們如果可以對接了OpenShift，那么也就相當于對接了Kubernetes。

為什么需要通過DevOps來管理OpenShift？

為了確保業務應用在測試環境預發環境生產環境表現的一致性，我們使用了一系列容器相關的工具，這些工具能夠幫助我們減少上線時因為介質、環境等不一致帶來的問題，可是隨著這些工具的深入使用，我們也會希望能夠進一步抽象，不論我們的業務應用是部署在云主機還是容器云上，我們都希望能使用同一種方式來進行部署，我們也希望能夠進一步簡化操作，真正實現一鍵部署，切實地提高生產效率和質量。

DevOps的核心價值就在于通過打通各個工具鏈來提高企業生產的效率以及質量，告別終日面對黑白相間的linux界面，友好的可視化界面能幾何倍數提升運維的操作體驗；不再因為部署環境發愁，一套DevOps就可以輕松管理多個環境；也不用被繁多的配置文件打亂思緒，我們可以通過大量的模板進行足夠靈活的自定義配置。

以上是DevOps實施時的系統架構部署圖。通常我們的部署都會分為開發環境、測試環境、生產環境這樣不同的部署區，這些不同部署區之間的資源都是相互隔離的，保證不會對彼此產生影響。

在我們的開發測試流水線中，首先，由開發人員提交代碼，觸發持續集成流水線，構建服務器會自動拉取代碼、對代碼進行質量掃描，然后編譯產物，最后將產物上傳到介質倉庫。我們支持配置介質倉庫的同步策略，如不同環境的介質倉庫定時同步、定時推送或者拉取，這樣能夠保證不同環境部署介質的一致性。對于鏡像來說，鏡像也是部署介質的一種類型，鏡像在完成構建和上傳之后，也支持同步到不同環境的鏡像倉庫。當觸發持續部署流程時，部署服務器將介質部署到應用部署機或者容器云環境，對于應用部署機來說，介質從介質倉庫服務器獲取，對于容器云來說，鏡像來源于鏡像倉庫。

我們是如何進行設計和落地的？

我們進行持續集成與持續部署的總體設計思路是，在DevOps中進行設計，然后通過Jenkins執行，最后通過OpenShift進行部署。我們在DevOps中定義多個原子任務串成流水線，之后進行構建定義或部署架構的設計，生成Jenkins的Pipeline Job的配置文件；然后Jenkins根據這個動態生成的配置文件創建并執行Pipeline Job；在部署完成后，DevOps通過調用Jenkins的Rest API跟蹤執行進度和結果，通過OpenShift的Rest API獲取應用容器的實例狀態以及對應用容器進行運維操作。

鏡像構建和上傳

在部署之前，我們需要準備好介質，DevOps提供了一系列任務能夠幫助我們輕松完成鏡像的構建和上傳，對于Kubernetes和OpenShift來說，部署介質就是鏡像，這意味著，無論是部署到Kubernetes還是部署到OpenShift，只要我們打通到鏡像倉庫的網絡，就可以兼容不同類型的容器云。

DevOps提供了多種鏡像構建任務，支持通過指定一個基礎鏡像進行構建，也支持通過DockerFile進行構建，使用方式上非常靈活。通常來說，企業都會在內網環境搭建私有鏡像倉庫，在構建之后，我們需要把鏡像push到已授信的鏡像倉庫。

組件類型拓展

我們添加了OpenShift類型的組件進行擴展，組件是部署的最小單元，其中包含了部署介質的各種信息，向前可以對生產介質的代碼、分支、構建流水號進行追溯，向后可以對部署之后的應用以及應用狀態變更如升級、回滾等操作進行跟蹤。組件還包含了它在各個環境中的部署信息以及實例的運行情況如訪問地址、運行狀態等。

資源類型拓展

我們添加了OpenShift類型的部署資源，資源擁有和介質完全獨立互斥的屬性，他描述了我們的介質（鏡像）需要部署到哪個環境（容器云），部署到該容器云的哪一個命名空間中去，資源還描述了訪問容器云所需要的其他信息如用戶名密碼或者APIToken以及容器云服務器的證書等信息。

部署原子任務拓展

DevOps具有強大的拓展能力，可以通過在數據庫添加OpenShift部署任務的原子任務以及原子任務的屬性參數進行拓展，例如：鏡像的名稱及鏡像版本、部署使用的yaml或者yaml模板、部署用到的OpenShift資源，拉取鏡像所用的鏡像倉庫等。

這種方式有什么好處？

DevOps流水線設計的優勢顯而易見，CICD可以減少大量開發、測試、部署過程中的重復性工作，同時減少了手工的錯誤，大大提高了功能驗證的頻率。開發測試人員能夠更早的獲取變更，更早的進入測試，更早的發現問題，縮短了開發周期，極大的降低了解決問題的成本。在這個過程中，開發人員能夠更早發現錯誤，并且減少解決錯誤所需的工作量，如果在部署環節發現錯誤可以回退到上一版本，保證交付物始終有一個可用的版本。

OpenShift Client插件介紹以及排坑

我們用到了Jenkins Plugin中的OpenShift Client用于對OpenShift進行操作，這個插件擁有簡潔、全面、可讀性強的特點，并且提供了流暢的Jenkins Pipeline語法與OpenShift服務器進行交互，接下來我將對使用這個插件遇到的一些問題進行排坑。

該插件利用了OpenShift命令行工具（oc），該腳本必須在執行腳本的節點上可用，所以要求我們的Jenkins Master和Node節點安裝oc命令，并且配置環境變量，同時還要保證打通到我們要管理的OpenShift的網絡。

插件要求我們配置OpenShift的證書和ApiToken，證書我們可以直接從OpenShift服務器的安裝目錄/etc/origin/master/ca.crt拷貝。關于ApiToken的獲取，我總結了以下兩種方式：

1.通過命令行

oc login -u -p
oc whoami -t

2.通過命令行

curl -u admin:abc123 -kv -H "X-CSRF-Token: xxx" 'https://master.example.com:8443/oauth/authorize?client_id=OpenShift-challenging-client&response_type=token'

從返回的Response Header中獲取。

從插件的使用上來說，他的Groovy語法糖非常契合OpenShift命令行的使用習慣，學習難度很低，因此熟悉kubectl或者oc命令的運維人員能夠在很短時間內掌握。

例如以下三行命令：

oc create -f templateYaml  
oc describe deploymentconfig test-demo
oc scale deploymentconfig test-demo --replicas=5

可以簡單寫成

應用容器的部署、升級、停止、擴容操作都可以用簡明清晰的語法操作，以下是代碼示例：

鏡像部署到OpenShift之后， DevOps會自動創建好對應的應用，同時，通過Jenkins回調DevOps返回的數據，我們可以獲取應用的一些基礎信息。可是對于應用的監控和運維來說，這些信息不夠有效，于是我們封裝了OpenShift提供的RestApi，提供了OpenShift應用運維常用的幾個接口。

當我們通過DevOps將構建好的鏡像成功部署到OpenShift之后，只做到這一步是遠遠不夠的，從某種方面來說，我們還沒有完全解放運維人員的壓力，對于應用部署之后漫長的運維周期，運維人員為了解決應用問題仍然需要面對黑白相間的linux控制臺以及敲入各種復雜的命令。

DevOps在OpenShift的應用運維方面做了哪些工作？

鏡像部署到OpenShift之后， DevOps會自動創建好對應的應用，同時，通過Jenkins回調DevOps返回的數據，我們可以獲取應用的一些基礎信息?？墒菍τ趹玫谋O控和運維來說，這些信息不夠有效，于是我們封裝了OpenShift提供的RestApi，提供了OpenShift應用運維常用的幾個接口，通過這些接口我們可以獲取應用容器的pods，events，logs，應用訪問地址以及端口等詳細信息。

那么在軟件開發前期，開發測試人員能夠通過DevOps快速構建出應用進行部署并且能很方便的獲取到訪問地址進行功能驗證，這樣可以大幅縮短功能驗證的周期，提高生產效率。

同時，DevOps在應用的界面提供了應用運維的一些基本能力，如應用的伸縮擴容、啟動、停止、回滾，查看POD日志等。運維人員通過界面就能夠獲取到當前應用的詳細信息，也可以很方便的進行應用的運維操作，這樣可以大大減輕運維的壓力。

總結和展望

DevOps和OpenShift結合能夠產生巨大的動能，在提升效率的同時可以提高交付的質量，自動化程度的提升可以幾何倍提升對業務需求變動帶來的相應能力。

伴隨互聯網的發展與賦能，行業競爭日益激烈，越來越多的企業開始技術創新和戰略轉型，經營模式從“以產品為中心”轉向“以用戶為中心”，營銷模式從“粗放營銷”轉向“精準營銷”，服務模式從“標準化服務”轉向“個性化服務”，基于此，每個企業都有自己的理念和方法來運用容器云等工具，而所有新技術的加持都要基于企業能夠融合創新并適應市場、優化業務流程以及改善用戶體驗。

但目前，企業在創新型業務交付的過程中，從收集和明確用戶需求、開發代碼和測試到最終生產上線交付業務，存在浪費時間和成本的問題從而影響交付速度的問題，而DevOps恰恰是為企業提高交付速度進一步優化用戶體驗的最佳解決方案。

關于作者：臉盆，普元研發工程師，擅長微服務、容器、DevOps等相關領域技術，目前負責DevOps容器云相關的設計和開發。算法定義軟件，數據驅動產品，技術改變未來。

關于EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。