OpenShift 容器雲提供了衆多基礎設施和工具，承載了衆多功能和特性，幫助用戶通過這個平臺提升企業 IT 的效率和敏捷度。 縱觀 OpenShift 容器雲項目，其中最重要的核心流程是將應用從靜態的源代碼變成動態的應用服務的過程 。
1、應用構建
第 1 步，部署應用。流程的開始是用戶通過 OpenShift 的 Web 控制檯或命令行 oc new- app 創建應用。根據用戶提供的源代碼倉庫地址及 Builder 鏡像，平臺將生成構建配置(BuildConfig)、部署配置(DeploymentConfig)、 Service 及 Route 等對象。
第 2 步，觸發構建。應用相關的對象創建完畢後平臺將觸發一次 S2I 構建。
第 3 步，實例化構建。平臺依據應用的 Build Config 實例化一次構建，生成一個 Build 對象。 Build對象生成後，平臺將執行具體的構建操作，包括下載源代碼、實例化Builder鏡像、 執行編譯和構建腳本等。
第 4 步，生成鏡像。構建成功後將生成一個可供部署的應用容器鏡像。平臺將把此鏡像推送到內部的鏡像倉庫組件 Registry 中 。
第 5 步，更新 Image Stream。 鏡像推送至內部的倉庫後，平臺將創建或更新應用的 Image Stream 的鏡像信息，使之指向最新的鏡像 。
2、應用部署
第 6 步，觸發鏡像部署。當 Image Stream 的鏡像信息更新後，將觸發平臺部署 S2I 構建生成的鏡像 。
第 7 步，實例化鏡像部署。 Deployment Config 對象記錄了部署的定義，平臺將依據此配置實例化一次部署，生成一個 Deploy 對象跟蹤當次部署的狀態 。
第 8步，生成 Replication Controller。平臺部署將實例化一個 Replication Controller, 用以調度應用容器的部署。
第 9步，部署容器。通過 Replication Controller, OpenShift 將 Pod 及應用容器部署到集羣的計算節點中。
3、請求處理
第 10 步，用戶訪問。 用戶通過瀏覽器訪問 Route 對象中定義的應用域名 。
第 11 步，請求處理並返回。 請求到 Router 組件後，Router 根據 Route 定義的規則，找到請求所含域名相關聯的 Service 的容器，並將請求轉發給容器實例。容器實例除了請求後返回數據，還會通過 Router 將數據返回給調用的客戶端。
4、應用更新
在應用更新時，平臺將重複上述流程的第 1 步至第 9 步 。 平臺將用下載更新後的代碼構建應用，生成新的鏡像，並將鏡像部署至集羣中。值得注意的是，OpenShift 支持滾動更新。在第 9步時，平臺將通過滾動更新的方式，保證應用在新老實例交替時服務不間斷。
Learn More
1、服務部署
1.1 單個微服務的部署：通過deployment config定義部署容器的行爲特性。
1.2 多個微服務的部署：通過template爲不同的微服務定義各自的Deployment Config、 Service 及Route等資源對象。（通過 oc export 命令，可以導出 OpenShift中指定的對象 。 加上 --as-template 參數使導出的內容以模板的形式展現）
2、服務發現
當容器啓動時，Openshift會根據當前項目的Service信息自動生成一些環境變量，比如Service_Host和Service_Port，並注入到容器內部。所以我們在容器內部可以直接根據這些環境變量進行服務發現。
使用命令：oc rsh <pod-name> 進入到容器內部。然後使用命令：env | grep SERVICE 來查看跟Service有關的環境變量。
服務目錄與鏈接：在 OpenShift 的項目路線圖中，將會實現 Service Catalog (服務目錄) 和 Service Linking (服務鏈接)功能，進一步加強集羣內 Service 的發現和調用。簡單來說，通過 Service Catalog 實現全局的服務目錄，可以在這個全局的目錄發佈服務和選取服務。通過 Service Linking功能，可以將需要的服務和容器應用對接 。
3、健康檢查
因爲每個微服務必須爲它自身的狀態負責，所以每個微服務都應提供一個健康檢查的接口。 通過調用這個健康檢查接口，外界可以判斷這個服務當前的狀態。一般情況下，並不是容器啓動後容器中的應用就馬上就緒了，應用一般還有一個啓動或初始化的過程。因此，必須有一種手段讓平臺檢查微服務應用的就緒狀態 。
- Readiness Probe：檢查應用是否已經就緒。OpenShift通過檢查 Readiness Probe 接口，只有在確認服務就緒後，纔會將外界的流量轉發至服務。
- Liveness Probe：檢查容器是否在正常運行。如果一個服務的 Liveness Probe 探測結果返回失敗，平臺就會判定這個容器實例出現了問題，相應的容器會被停止 。
健康檢查類型：
- HTTP Get請求：通過調用用戶指定的URL判別容器應用的狀態。如果返回200或399，則表示成功，否則認爲失敗。
- 執行容器命令：用戶可以通過執行容器中的某個命令來確認容器的狀態。如果程序的返回值爲0則表示成功，否則爲失敗。
- TCP socket：TCP socket檢查訪問容器的某一個TCP端口，如果成功建立連接則認爲檢查成功。
4、更新發布
如上一篇文章所訴，deploy類型有兩種：rolling update和recreate。Openshift入門：基本概念解析
發佈回滾：通過oc rollback 命令進行發佈回滾
灰度發佈/藍綠髮布/AB測試：根據容器/Router的label和標籤選擇器實現。
5、服務治理
大家對微服務的一個很大的關注點在於微服務的治理。 用戶希望能夠清晰地掌握微服務的性能、調用分析及依賴關係等數據。這些數據的獲取一般有兩種方式:
- 通過設置API網關（API gateway）進行微服務訪問的轉發，實現對調用的度量統計、流量控制和安全管控。
- 藉助微服務框架，在應用服務的代碼或運行環境中加入探針，進行度量收集和行爲控制。