OpenShift中的持續(xù)交付
持續(xù)交付
如果要打造一個(gè)持續(xù)交付的流水線，首先要考慮多環(huán)境的問題。一般一個(gè)應(yīng)用程序會(huì)有多個(gè)環(huán)境，比如開發(fā)環(huán)境、集成測(cè)試環(huán)境、系統(tǒng)測(cè)試環(huán)境、用戶驗(yàn)收測(cè)試環(huán)境、類生產(chǎn)環(huán)境、生產(chǎn)環(huán)境。如何在OpenShift中隔離并建立對(duì)這些環(huán)境的部署流程有多種方案可以選擇。
- 同一個(gè)project中使用label和***名稱來區(qū)分不同的環(huán)境;
- 集群中的不同project來隔離環(huán)境;
- 跨集群來隔離環(huán)境。
我們以第二種方式為例，演示下多環(huán)境管理問題。
在上圖中，我們有一個(gè)build project。build project包含了一組相互依賴性比較強(qiáng)的應(yīng)用，每個(gè)應(yīng)用對(duì)應(yīng)一個(gè)build config，產(chǎn)生的Image Stream存放在image register中。而每個(gè)環(huán)境各對(duì)應(yīng)一個(gè)project，其中包含了該應(yīng)用的deployment config，其鏡像輸入是build config產(chǎn)生的Image Stream。之所以這樣做，有以下幾點(diǎn)考慮：
- 不同的環(huán)境分布在不同的project中，可以很好的借助project的特性進(jìn)行環(huán)境隔離。比如sys project的容器只能部署在label為sys的node上，prod project的容器只能部署在label為prod的node上。
- 不同的project可以分別定義權(quán)限訪問和控制。比如只有QA才能操作sys project中的資源，運(yùn)維工程師才能操作prod project中的資源。
- 不同的環(huán)境共用一個(gè)Image Stream，保證了應(yīng)用程序鏡像在不同環(huán)境中的是完全一致的，防止由于測(cè)試環(huán)境和生產(chǎn)環(huán)境不一致而引入缺陷。
那么大家共用同一個(gè)Image Stream，如何實(shí)現(xiàn)應(yīng)用的promotion呢?解決方案就是使用tag。
如上圖所示，一個(gè)image stream里面有多個(gè)版本的鏡像，而OpenShift可以為版本添加自定義tag。在不同的project里面，我們配置image的來源為”ImageStreamTag”，名稱為”applicationName:environmentName”。比如sys project的鏡像名為”App1:sys”，prod project的鏡像為”App1:prod”。如果想將version 3的鏡像推送到sys環(huán)境，只需要簡(jiǎn)單的給version 3的鏡像打上sys的tag，這樣部署sys環(huán)境時(shí)就會(huì)自動(dòng)使用version 3的鏡像。
- oc tag App1:latest App1:sys
如果在Deployment Config里面配置了自動(dòng)監(jiān)聽tag的變動(dòng)的操作，那么一旦你修改了ImageStream的tag，就會(huì)自動(dòng)觸發(fā)對(duì)應(yīng)環(huán)境的部署。
由于應(yīng)用程序鏡像在不同的環(huán)境中是一致的，那么變動(dòng)的部分都被抽取到了外部配置中。如何根據(jù)不同的環(huán)境來加載對(duì)應(yīng)的外部配置呢?實(shí)現(xiàn)方式有很多種，這里介紹了使用Spring Cloud Config的方案。
首先我們將針對(duì)不同環(huán)境的配置放置在一個(gè)git倉中，然后通過Spring Cloud Config Server將其轉(zhuǎn)換為http服務(wù)。而我們?cè)趹?yīng)用中嵌入Spring Cloud Config Client，其會(huì)接收一個(gè)環(huán)境變量來拉取指定環(huán)境的配置。而該環(huán)境變量可以通過Deployment Config來進(jìn)行注入。
- oc env dc/sys PROFILE=sys
使用Spring Cloud Config給予了我們更多的靈活性。我們可以選擇在應(yīng)用程序***次啟動(dòng)的時(shí)候拉取配置，也可以設(shè)置每隔一段時(shí)間自動(dòng)更新配置，從而實(shí)現(xiàn)熱更新。
OpenShift雖然提供了構(gòu)建和部署的能力，我們有時(shí)也需要使用Jenkins之類的工具來可視化以及編排整個(gè)流水線。
既然OpenShift是個(gè)容器化的管理平臺(tái)，那么我們完全也可以將Jenkins作為一個(gè)應(yīng)用納入到OpenShift中來托管，這樣Jenkins的Master和Slave都是容器化的。OpenShift官方提供了一個(gè)Jenkins2.0的鏡像，其預(yù)裝了OpenShift pipeline插件，可以很方便地進(jìn)行構(gòu)建、部署等操作。
生產(chǎn)環(huán)境的部署
OpenShift在產(chǎn)品環(huán)境的部署默認(rèn)是rolling的方式。
每次部署時(shí)，它會(huì)啟動(dòng)一個(gè)新的Replica Controller，部署一個(gè)pod，然后削減舊的Replica Controller的pod，如此往復(fù)，直到舊的Replica Controller中的所有pod都被銷毀，新的Replica Controller的所有pod都在線。整個(gè)過程保證了服務(wù)不宕機(jī)以及流量平滑切換，對(duì)用戶是無感知的。
而有的時(shí)候部署場(chǎng)景要負(fù)責(zé)些，比如我們想在產(chǎn)品環(huán)境對(duì)新版本做了充分的PVT(product version testing)才切換到新版本。那么就可以使用藍(lán)綠部署的方式。
藍(lán)綠部署方案的關(guān)鍵點(diǎn)在于一個(gè)Router對(duì)應(yīng)兩個(gè)Service。而Route作為向外界暴露的服務(wù)端口是不變的，兩個(gè)Service分別對(duì)應(yīng)我們的生產(chǎn)藍(lán)環(huán)境和生產(chǎn)綠環(huán)境。同時(shí)只有一個(gè)Service能接入Router對(duì)外服務(wù)，另一個(gè)Service用來進(jìn)行PVT測(cè)試。切換可以簡(jiǎn)單的修改Router的配置即可。
- port:
- targetPort: app-blue-http
- to:
- kind: Service
- name: app-blue
結(jié)語
OpenShift在應(yīng)用的構(gòu)建以及部署方面為我們提供了大量開箱即用的功能和解決方案,所以實(shí)現(xiàn)持續(xù)交付不再那么艱難。我們可以將更多的精力花費(fèi)在提升應(yīng)用程序質(zhì)量以及架構(gòu)方面，交付更好的產(chǎn)品。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
