上一文中講述瞭如何在AWS下搭建OpenShift集羣。這篇文章將目光轉向如何在OpenShift中實現CI/CD以及產品環境的部署。node
持續交付
若是要打造一個持續交付的流水線，首先要考慮多環境的問題。通常一個應用程序會有多個環境，好比開發環境、集成測試環境、系統測試環境、用戶驗收測試環境、類生產環境、生產環境。如何在OpenShift中隔離並創建對這些環境的部署流程有多種方案能夠選擇。git
- 同一個project中使用label和惟一名稱來區分不一樣的環境；
- 集羣中的不一樣project來隔離環境；
- 跨集羣來隔離環境。
咱們以第二種方式爲例，演示下多環境管理問題。bash
在上圖中，咱們有一個build project。build project包含了一組相互依賴性比較強的應用，每一個應用對應一個build config，產生的Image Stream存放在image register中。而每一個環境各對應一個project，其中包含了該應用的deployment config，其鏡像輸入是build config產生的Image Stream。之因此這樣作，有如下幾點考慮：架構
不一樣的環境分佈在不一樣的project中，能夠很好的藉助project的特性進行環境隔離。好比sys project的容器只能部署在label爲sys的node上，prod project的容器只能部署在label爲prod的node上。app
不一樣的project能夠分別定義權限訪問和控制。好比只有QA才能操做sys project中的資源，運維工程師才能操做prod project中的資源。運維
不一樣的環境共用一個Image Stream，保證了應用程序鏡像在不一樣環境中的是徹底一致的，防止因爲測試環境和生產環境不一致而引入缺陷。工具
那麼你們共用同一個Image Stream，如何實現應用的promotion那？解決方案就是使用tag。測試
如上圖所示，一個image stream裏面有多個版本的鏡像，而OpenShift能夠爲版本添加自定義tag。在不一樣的project裏面，咱們配置image的來源爲」ImageStreamTag」，名稱爲」applicationName:environmentName」。好比sys project的鏡像名爲」App1:sys」，prod project的鏡像爲」App1:prod」。若是想將version 3的鏡像推送到sys環境，只須要簡單的給version 3的鏡像打上sys的tag，這樣部署sys環境時就會自動使用version 3的鏡像。ui
1
|
oc tag App1:latest App1:sys |
若是在Deployment Config裏面配置了自動監聽tag的變更的操做，那麼一旦你修改了ImageStream的tag，就會自動觸發對應環境的部署。spa
因爲應用程序鏡像在不一樣的環境中是一致的，那麼變更的部分都被抽取到了外部配置中。如何根據不一樣的環境來加載對應的外部配置那？實現方式有不少種，這裏介紹了使用Spring Cloud Config的方案。
首先咱們將針對不一樣環境的配置放置在一個git倉中，而後經過Spring Cloud Config Server將其轉換爲http服務。而咱們在應用中嵌入Spring Cloud Config Client，其會接收一個環境變量來拉取指定環境的配置。而該環境變量能夠經過Deployment Config來進行注入。
1
|
oc env dc/sys PROFILE=sys |
使用Spring Cloud Config給予了咱們更多的靈活性。咱們能夠選擇在應用程序第一次啓動的時候拉取配置，也能夠設置每隔一段時間自動更新配置，從而實現熱更新。
OpenShift雖然提供了構建和部署的能力，咱們有時也須要使用Jenkins之類的工具來可視化以及編排整個流水線。
既然OpenShift是個容器化的管理平臺，那麼咱們徹底也能夠將Jenkins做爲一個應用歸入到OpenShift中來託管，這樣Jenkins的Master和Slave都是容器化的。OpenShift官方提供了一個Jenkins2.0的鏡像，其預裝了OpenShift pipeline插件，能夠很方便地進行構建、部署等操做。
生產環境的部署
OpenShift在產品環境的部署默認是rolling的方式。
每次部署時，它會啓動一個新的Replica Controller，部署一個pod，而後削減舊的Replica Controller的pod，如此往復，直到舊的Replica Controller中的全部pod都被銷燬，新的Replica Controller的全部pod都在線。整個過程保證了服務不宕機以及流量平滑切換，對用戶是無感知的。
而有的時候部署場景要負責些，好比咱們想在產品環境對新版本作了充分的PVT（product version testing）才切換到新版本。那麼就可使用藍綠部署的方式。
藍綠部署方案的關鍵點在於一個Router對應兩個Service。而Route做爲向外界暴露的服務端口是不變的，兩個Service分別對應咱們的生產藍環境和生產綠環境。同時只有一個Service能接入Router對外服務，另外一個Service用來進行PVT測試。切換能夠簡單的修改Router的配置便可。
1 2 3 4 5 |
port: targetPort: app-blue-http to: kind: Service name: app-blue |
結語
OpenShift在應用的構建以及部署方面爲咱們提供了大量開箱即用的功能和解決方案,因此實現持續交付再也不那麼艱難。咱們能夠將更多的精力花費在提高應用程序質量以及架構方面，交付更好的產品。