看紅帽最高深的武功OpenShift

世上高手大約有兩種：

第一種，一輩子縱橫江湖數十載，所學武功實用有效，招數簡明而力道雄厚，善於「簡單粗暴」迅速解決問題。在TA心中：能用黑虎掏心解決的問題，幹啥非要耍一套袈裟伏魔功？能用虛擬化RHV/vSphere解決的問題，憑啥上OpenStack？vLAN能解決的問題，上啥SDN？

另一種所練武藝精妙無比，招數變化層出不窮，出招變化莫測，隨著對武功理解的深入，漸入以無招勝有招的境界，加以深厚的內力，使將出來，天下無敵。這是什麼武功？大名鼎鼎的OpenShift。

OpenShift最核心的內功心法

OpenShift到底是個啥？

• 從架構角度，用一句話來形容OpenShift，那它就是企業版的Kuberrnetes

• 從功能角度，用一句話來說OpenShift，那它就是下一代應用承載平台

• 從面向對象角度，用一句話來說OpenShift，那它是「同時面向運維和開發的企業級PaaS平台「。面向運維體現的是容器雲，面向開發體現的是DevOps

Gartner說，容器的四大應用場景主要有：DevOps、PaaS、微服務、批量運算。在這四種場景裡面，筆者至少看到了OpenShift在前三個場景中的真實實用案例。

接下來我們先看OpenShift各個組件的功能：

OpenShift內部幾大組件： Master節點、Node節點、RoutingLayer、Service Layer、持久存儲、Registry。

• master是OpenShift集群的管理節點，它包含管理組件，如API Server，controller manager server, 和etcd。Master節點通過Node節點上的服務管理Node節點，管理Node節點的健康狀態。

• Node節點提供容器的運行環境。每個Node節點都被Master管理。Node節點可以是物理機，也可以是虛擬機（當然需要安裝RHEL），甚至可以是雲環境。

• Service Layer負責不同Service之間通訊的。Service是Openshift中的一個客戶應用，如Tomcat。

• Routing layer：提供對外網服務。把外部的請求，路由到內部Pod IP。

• 持久存儲：為容器的數據盤提供持久存儲。

• Registry：企業內部鏡像庫。有兩類：集成的庫和本地庫。前者存放dev階段的build好的鏡像（172網段）；後者存放企業內可以共享的基礎鏡像。

接下來，詳細分析Openshift內部架構：下圖中，白色框是Kuberrnetes自有組件，黃色框是紅帽OpenShift增加的部分。

在幾個核心組件，比較難理解的主要有：Build Config（bc）、Deployment Config（dc）、Image Stream。我們主要介紹這幾個組件，其他組件參照筆者上一小節列出的文章鏈接，可以理解清楚。

bc：bc是一中靜態配置，它的配置中有很多信息：如源代碼在哪、build的時候拉哪一個分支的代碼、基礎鏡像在哪、生成的應用鏡像推送到哪個倉庫等等。bc會觸發build，生成的是包含應用的鏡像。

dc：參數是可以動態變化的，變化以後，會出發一次新的部署。定義了部署的是哪一個應用的鏡像、鏡像的相關信息、需要掛載的volume。

所以說，我們部署一個應用，通常而言，它可以沒有bc，但一定有dc。

image stream：用於跟蹤、記錄bc所生成的鏡像。裡面會記錄會把bc的結果存到哪個registry中。is存在的一個重要的意義，是實現了bc的解耦（例如不必關注後端具體的registry）。

在Openshift，部署應用的方法，通常有幾個（有但不限於）：

• 通過docker image部署：這種通常直接部署已經包含應用的打包好的鏡像，因此通常沒有bc。

• 通過S2I 部署：通過選擇building image和指定code。指定完以後，code 先進行build，build成功，會將它push到內部的鏡像庫，然後部署一個新的pod。因此S2I通常會觸發build和deploy。

• 通過模板部署：模板是可以把和一套應用相關的配置，都寫在一起，然後通過這個模板部署應用。使用模板部署最大的好處在於，他可以加快應用的部署速度。模板是由實現寫好的yaml或json文件創建的。

下面列出三種常見部署方式的關鍵步驟截圖：

1.通過docker image部署：

部署一個位於docker.io上已經有用image：

點擊create後，觀察日誌。很快pod就創建完了：

查看pod的狀態：

將應用expose出去，以便外網訪問：

通過瀏覽器範文，可以看到應用，這是一個地圖：

在地圖上找到僑福芳草地大廈（紅帽辦公室）：

通過S2I 部署：

登錄openshift圖形化界面（cli同理），選擇登錄用戶下的一個項目：

選擇給項目增加應用「Add to project」

搜索並選擇building image：

然後輸入代碼所在的git，點擊create。

接下來，就出發了build，查看build狀態：

觀察build的過程中產生的日誌：

首先下載鏡像：

code下載完畢，開始build，過了一會build完成：

build完成以後，image會被push到內部的registry中:

鏡像push到內部庫以後，dc會觸發一次deploy部署一個pod，過一會，pod部署成功

在實驗環境中，查看一個bc：

那麼這個bc是做什麼的呢？通過命令行進行查看：

通過上面的這個截圖，我們可以很清楚的看出：這個bc觸發的build操作，實際上是通過java s2i的building image，加上source code （https://github.com/openshift-roadshow/nationalparks.git）把code和images放在一起進行代碼構建，然後生成一個包含應用的image（打上latest標籤），這個image先被push到intergrated 的registry中。

通過模板部署：

首先創建一個模板,筆者用一個json的文件創建一個模板。

查看創建成功的模板：

至於json中的配置信息，我們截取一部分進行查看：

在OpenShift界面中可以搜到剛剛創建好的模板，通過選擇這個模板，就可以創建應用了。

給容器增加監控

給容器增加的通常有兩類：監控容器可提供服務、監控容器是否是活著的。如果openshift檢測到容器有問題或者不能提供服務，會將現有的容器kill掉，然後新建容器。

添加監控的方法如下，選擇add health checks：

列出兩個屬性：

分別添加，輸入設置的參數：

OpenShift實現CI/CD

CI/CD Pipeline

CI/CD流程如下，因為比較好理解，就不再進行中文翻譯工作了。

CI/CD與devops的一個顯著的區別是上面的第六步，也就是dev階段build好的image，需要在經過相關人員批准以後，才會在生產上部署。

在openshift中，jenkins也實現了容器化。在實驗中，先部署一個Jenkins，用於和S2I做對接。

設置參數：

過一會，jenkins部署成功：

通過routes訪問jenkins：

接下來，創建pipeline的pod：

在pipeline中，觸發build（手工或者自動的情況都存在）以後，會繼續觸發dev中的部署和測試，然後在向生產中deploy之前，pending住：

點擊input request後，鏈接到jenkines,點擊繼續：

觸發在生產中，部署完成：

查看pod，有個新的deploy動作，說明從dev階段傳過來的新版本的image，已經在生產商重新deploy。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！