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