轉(zhuǎn)載本文需注明出處：微信公眾號(hào)EAWorld，違者必究。

前言：

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

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

容器是什么？

容器是一種內(nèi)核輕量級(jí)的操作系統(tǒng)層虛擬化技術(shù)。

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

Docker屬于容器服務(wù)的一種，是一個(gè)開源的應(yīng)用容器引擎。

容器具有哪些特點(diǎn)？

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

2. 秒級(jí)部署：根據(jù)鏡像的不同，容器的部署大概在毫秒與秒之間（比虛擬機(jī)強(qiáng)很多）；

3. 易于移植：一次構(gòu)建，隨處部署；

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

使用容器化技術(shù)能帶來哪些好處？

在傳統(tǒng)的開發(fā)場景下，開發(fā)測試團(tuán)隊(duì)和生產(chǎn)運(yùn)維團(tuán)隊(duì)使用的是不同的基礎(chǔ)設(shè)施，通常都會(huì)使用相同介質(zhì)和不同的配置文件來區(qū)分環(huán)境，但是在環(huán)境的轉(zhuǎn)換過程中，還是會(huì)出現(xiàn)一些由于團(tuán)隊(duì)協(xié)作或者環(huán)境依賴造成的問題。而容器化帶來的最大便利就在于，他能夠簡化團(tuán)隊(duì)間的協(xié)作關(guān)系，容器鏡像的構(gòu)建打包的也不僅是應(yīng)用，而是應(yīng)用運(yùn)行所在的全部運(yùn)行環(huán)境，這種方式屏蔽了由于環(huán)境不同帶來的問題。這樣以來，無論是在什么環(huán)境下運(yùn)行，這個(gè)應(yīng)用所需要的環(huán)境、依賴都是高度一致的。

當(dāng)容器的數(shù)量達(dá)到一定量級(jí)的時(shí)候，如何對(duì)容器進(jìn)行高效的維護(hù)和管理呢？

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

什么是Kubernetes？

Kubernetes，是一個(gè)容器集群管理系統(tǒng)，可以實(shí)現(xiàn)容器集群的自動(dòng)化部署、自動(dòng)擴(kuò)縮容、維護(hù)等功能，保證應(yīng)用的高可用。

通過Kubernetes你可以：

1. 快速部署應(yīng)用

2. 快速擴(kuò)展應(yīng)用，對(duì)應(yīng)用進(jìn)行擴(kuò)容

3. 無縫對(duì)接新的應(yīng)用功能

4. 節(jié)省資源，優(yōu)化硬件資源的使用

Kubernetes具有哪些特點(diǎn)？

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

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

3. 自動(dòng)化: 自動(dòng)部署，自動(dòng)重啟，自動(dòng)復(fù)制，自動(dòng)伸縮/擴(kuò)展

OpenShift是什么？

OpenShift是一個(gè)基于主流的容器技術(shù)Docker和Kubernetes構(gòu)建的云平臺(tái)，OpenShift底層以docker作為容器引擎驅(qū)動(dòng)，以Kubernetes作為容器編排引擎組件，同時(shí)，OpenShift提供了開發(fā)語言、中間件、自動(dòng)化流程工具及界面等元素，提供了一套完整的基于容器的應(yīng)用云平臺(tái)。

你可以簡單的把OpenShift理解為Kubernetes PRO PLUS所以我們?nèi)绻梢詫?duì)接了OpenShift，那么也就相當(dāng)于對(duì)接了Kubernetes。

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

為了確保業(yè)務(wù)應(yīng)用在測試環(huán)境預(yù)發(fā)環(huán)境生產(chǎn)環(huán)境表現(xiàn)的一致性，我們使用了一系列容器相關(guān)的工具，這些工具能夠幫助我們減少上線時(shí)因?yàn)榻橘|(zhì)、環(huán)境等不一致帶來的問題，可是隨著這些工具的深入使用，我們也會(huì)希望能夠進(jìn)一步抽象，不論我們的業(yè)務(wù)應(yīng)用是部署在云主機(jī)還是容器云上，我們都希望能使用同一種方式來進(jìn)行部署，我們也希望能夠進(jìn)一步簡化操作，真正實(shí)現(xiàn)一鍵部署，切實(shí)地提高生產(chǎn)效率和質(zhì)量。

DevOps的核心價(jià)值就在于通過打通各個(gè)工具鏈來提高企業(yè)生產(chǎn)的效率以及質(zhì)量，告別終日面對(duì)黑白相間的linux界面，友好的可視化界面能幾何倍數(shù)提升運(yùn)維的操作體驗(yàn)；不再因?yàn)椴渴瓠h(huán)境發(fā)愁，一套DevOps就可以輕松管理多個(gè)環(huán)境；也不用被繁多的配置文件打亂思緒，我們可以通過大量的模板進(jìn)行足夠靈活的自定義配置。

以上是DevOps實(shí)施時(shí)的系統(tǒng)架構(gòu)部署圖。通常我們的部署都會(huì)分為開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境這樣不同的部署區(qū)，這些不同部署區(qū)之間的資源都是相互隔離的，保證不會(huì)對(duì)彼此產(chǎn)生影響。

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

我們是如何進(jìn)行設(shè)計(jì)和落地的？

我們進(jìn)行持續(xù)集成與持續(xù)部署的總體設(shè)計(jì)思路是，在DevOps中進(jìn)行設(shè)計(jì)，然后通過Jenkins執(zhí)行，最后通過OpenShift進(jìn)行部署。我們?cè)贒evOps中定義多個(gè)原子任務(wù)串成流水線，之后進(jìn)行構(gòu)建定義或部署架構(gòu)的設(shè)計(jì)，生成Jenkins的Pipeline Job的配置文件；然后Jenkins根據(jù)這個(gè)動(dòng)態(tài)生成的配置文件創(chuàng)建并執(zhí)行Pipeline Job；在部署完成后，DevOps通過調(diào)用Jenkins的Rest API跟蹤執(zhí)行進(jìn)度和結(jié)果，通過OpenShift的Rest API獲取應(yīng)用容器的實(shí)例狀態(tài)以及對(duì)應(yīng)用容器進(jìn)行運(yùn)維操作。

鏡像構(gòu)建和上傳

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

DevOps提供了多種鏡像構(gòu)建任務(wù)，支持通過指定一個(gè)基礎(chǔ)鏡像進(jìn)行構(gòu)建，也支持通過DockerFile進(jìn)行構(gòu)建，使用方式上非常靈活。通常來說，企業(yè)都會(huì)在內(nèi)網(wǎng)環(huán)境搭建私有鏡像倉庫，在構(gòu)建之后，我們需要把鏡像push到已授信的鏡像倉庫。

組件類型拓展

我們添加了OpenShift類型的組件進(jìn)行擴(kuò)展，組件是部署的最小單元，其中包含了部署介質(zhì)的各種信息，向前可以對(duì)生產(chǎn)介質(zhì)的代碼、分支、構(gòu)建流水號(hào)進(jìn)行追溯，向后可以對(duì)部署之后的應(yīng)用以及應(yīng)用狀態(tài)變更如升級(jí)、回滾等操作進(jìn)行跟蹤。組件還包含了它在各個(gè)環(huán)境中的部署信息以及實(shí)例的運(yùn)行情況如訪問地址、運(yùn)行狀態(tài)等。

資源類型拓展

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

部署原子任務(wù)拓展

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

這種方式有什么好處？

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

OpenShift Client插件介紹以及排坑

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

該插件利用了OpenShift命令行工具（oc），該腳本必須在執(zhí)行腳本的節(jié)點(diǎn)上可用，所以要求我們的Jenkins Master和Node節(jié)點(diǎn)安裝oc命令，并且配置環(huán)境變量，同時(shí)還要保證打通到我們要管理的OpenShift的網(wǎng)絡(luò)。

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

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命令行的使用習(xí)慣，學(xué)習(xí)難度很低，因此熟悉kubectl或者oc命令的運(yùn)維人員能夠在很短時(shí)間內(nèi)掌握。

例如以下三行命令：

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

可以簡單寫成

應(yīng)用容器的部署、升級(jí)、停止、擴(kuò)容操作都可以用簡明清晰的語法操作，以下是代碼示例：

鏡像部署到OpenShift之后， DevOps會(huì)自動(dòng)創(chuàng)建好對(duì)應(yīng)的應(yīng)用，同時(shí)，通過Jenkins回調(diào)DevOps返回的數(shù)據(jù)，我們可以獲取應(yīng)用的一些基礎(chǔ)信息。可是對(duì)于應(yīng)用的監(jiān)控和運(yùn)維來說，這些信息不夠有效，于是我們封裝了OpenShift提供的RestApi，提供了OpenShift應(yīng)用運(yùn)維常用的幾個(gè)接口。

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

DevOps在OpenShift的應(yīng)用運(yùn)維方面做了哪些工作？

鏡像部署到OpenShift之后， DevOps會(huì)自動(dòng)創(chuàng)建好對(duì)應(yīng)的應(yīng)用，同時(shí)，通過Jenkins回調(diào)DevOps返回的數(shù)據(jù)，我們可以獲取應(yīng)用的一些基礎(chǔ)信息?？墒菍?duì)于應(yīng)用的監(jiān)控和運(yùn)維來說，這些信息不夠有效，于是我們封裝了OpenShift提供的RestApi，提供了OpenShift應(yīng)用運(yùn)維常用的幾個(gè)接口，通過這些接口我們可以獲取應(yīng)用容器的pods，events，logs，應(yīng)用訪問地址以及端口等詳細(xì)信息。

那么在軟件開發(fā)前期，開發(fā)測試人員能夠通過DevOps快速構(gòu)建出應(yīng)用進(jìn)行部署并且能很方便的獲取到訪問地址進(jìn)行功能驗(yàn)證，這樣可以大幅縮短功能驗(yàn)證的周期，提高生產(chǎn)效率。

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

總結(jié)和展望

DevOps和OpenShift結(jié)合能夠產(chǎn)生巨大的動(dòng)能，在提升效率的同時(shí)可以提高交付的質(zhì)量，自動(dòng)化程度的提升可以幾何倍提升對(duì)業(yè)務(wù)需求變動(dòng)帶來的相應(yīng)能力。

伴隨互聯(lián)網(wǎng)的發(fā)展與賦能，行業(yè)競爭日益激烈，越來越多的企業(yè)開始技術(shù)創(chuàng)新和戰(zhàn)略轉(zhuǎn)型，經(jīng)營模式從“以產(chǎn)品為中心”轉(zhuǎn)向“以用戶為中心”，營銷模式從“粗放營銷”轉(zhuǎn)向“精準(zhǔn)營銷”，服務(wù)模式從“標(biāo)準(zhǔn)化服務(wù)”轉(zhuǎn)向“個(gè)性化服務(wù)”，基于此，每個(gè)企業(yè)都有自己的理念和方法來運(yùn)用容器云等工具，而所有新技術(shù)的加持都要基于企業(yè)能夠融合創(chuàng)新并適應(yīng)市場、優(yōu)化業(yè)務(wù)流程以及改善用戶體驗(yàn)。

但目前，企業(yè)在創(chuàng)新型業(yè)務(wù)交付的過程中，從收集和明確用戶需求、開發(fā)代碼和測試到最終生產(chǎn)上線交付業(yè)務(wù)，存在浪費(fèi)時(shí)間和成本的問題從而影響交付速度的問題，而DevOps恰恰是為企業(yè)提高交付速度進(jìn)一步優(yōu)化用戶體驗(yàn)的最佳解決方案。

關(guān)于作者：臉盆，普元研發(fā)工程師，擅長微服務(wù)、容器、DevOps等相關(guān)領(lǐng)域技術(shù)，目前負(fù)責(zé)DevOps容器云相關(guān)的設(shè)計(jì)和開發(fā)。算法定義軟件，數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品，技術(shù)改變未來。

關(guān)于EAWorld：微服務(wù)，DevOps，數(shù)據(jù)治理，移動(dòng)架構(gòu)原創(chuàng)技術(shù)分享。