【51CTO.com快譯】紅帽打造出的這款強大、易于使用且極具可擴展能力的PaaS方案如今已經正式登陸Docker——不過其尚存在一些暫時性局限。

去年，OpenShift 2已經成為我個人最為喜愛的開源PaaS方案。那時候我曾經評論稱，“OpenShift擁有極為驚人的易用性、易管理性與易安裝性，而且對于那些熟知Git的開發人員以及了解Puppet的管理員而言，其幾乎沒有任何學習曲線。以自動化方式進行橫向擴展簡單地就像在應用配置當中進行設備檢查一樣。其默認啟用設備自動閑置功能，而且允許用戶以極高密度進行應用程序部署。另外，只需進行一次git push即可完成應用程序更新。無論是開發者還是運維人員，OpenShift都可謂滿足了PaaS技術所做出的全部功能承諾。”

自那時開始，OpenShift一直在潛心閉關以完成面向Docker容器的應用程序部署能力轉變，其進行了大規模重構而非單純“cartridge”或者“gear”。從理論層面講，這應該能夠讓OpenShift PaaS擁有更為出色的易用性并使其獲得更為可觀的編程語言與應用程序支持資源池，而這都要歸功于Docker Hub當中現成可用的各類容器機制。不過從實踐層面看，它的具體表現又是如何?下面就讓我們一起探尋答案。

OpenShift 3架構

如圖一所示，OpenShift 3仍然立足于紅帽企業Linux基礎之上。不過除此之外，其它的一切幾乎都做出了調整。如今的運行單元已經不再是“gear”——而是“pod”，每個pod由一套或者多套Docker容器所構成，它們又共同運行在一個“node”之上。語言環境不再是“cartridge”，而轉變成了Docker鏡像，并利用一款“源代碼到鏡像”工具進行代碼結合。順帶一提，node也就是RHEL當中應用程序的運行實例。

　　圖一：OpenShift 3系統架構示意圖。

調度、管理以及復制功能如此都成為主體組成部分，而主體則通過立足于RHEL的Kubernetes實現。其中一套服務層負責與底層虛擬或者物理硬件乃至公有或者私有云進行通信。另有一套路由層負責將各應用程序與互聯網進行對接，如此一來它們就能夠為運行在計算機或者移動設備上的客戶端所使用。

開發人員可以利用oc命令行界面或者Web控制臺在OpenShift 3上完成自助配置。目前一部分功能只適用于命令行界面，不過其將在未來的OpenShift 3.1版本當中為Web控制臺所全面支持。

OpenShift SKU與安裝

OpenShift目前擁有四套彼此獨立但又密切相關的產品：OpenShift Origin、OpenShift Online、OpenShift Dedicated以及OpenShift Enterprise。

OpenShift Origin 3的主要賣點為開源與靈活性：大家可以將其自身作為容器加以運行、利用Ansible將其作為集群、或者利用Amazon Web Services或者Google Cloud Engine為其提供公有云運行環境。此版本屬于上游代碼，而且明確表現出了與OpenShift 2的差異之處。另外其還提供OpenShift Origin 3 Vagrant VirtualBox VM，大家能夠在數分鐘之內將其安裝完成。

Online版本則需要托管于公有云之上，而且相當于直接從Origin代碼當中剝離出的一部分。不過Online版本繼續使用gear機制，這一點可以說已經與OpenShift 3完全脫離了。因此，我們可以認為Online仍然運行在OpenShift 2模式之下。

OpenShift Dedicated負責提供一套立足于公有云的專用、定制化且受管理應用平臺，其被托管于Amazon Web Services內的任意可用區當中。這套版本由OpenShift 3 Enterprise提供支持并由紅帽方面加以管理。

OpenShift Enterprise則是目前穩定性最出色且最為典型的安裝選項。大家需要創建一套主節點、基礎設施(包括注冊表、路由器以及存儲機制)以及至少兩個節點，而且需要首先以RHEL啟動，之后陸續添加Docker、Kubernetes以及OpenShift。在理想狀態下，每個主機與節點將至少配備8 GB內存以供生產型使用。Enterprise版本與Pivotal CF以及Apprenda存在競爭關系，而且我個人利用由紅帽公司提供的“巡演環境”對其進行了上手評測。

大家可以在筆記本電腦上安裝并運行OpenShift Enterprise，而這也正是OpenShift Enterprise首席技術營銷經理Erik Jacobs在首次為我進行演示時選擇的方式。Jacobs將其稱為“一套三虛擬機”配置，其中利用一套虛擬機作為主節點與基礎設施主機(包括注冊表與路由器)，而另兩個節點則負責托管應用程序。

利用OpenShift 3進行開發

為了理解如今的OpenShift Enterprise如何與用戶的開發需求相匹配，我放棄了自己原先經常使用的隨機PaaS評測方式，而選擇了采用紅帽方面提供的“九實驗室”機制。Lab 1基本上包含oc，即命令行界面工具的安裝與運行。需要注意的是，雖然在實驗室流程中的某些具體步驟方面有所區別，但OpenShift Enterprise當中的oc版本與OpenShift Origin其實并沒有多大不同。

Lab 2則要求我們運行一套Smoke Test項目，了解如何使用oc并學習Web控制臺的使用技巧，如圖二所示。

圖二：OpenShift中Web控制臺 Smoke Test應用概述。右側的細節描述解釋了與pod、服務以及部署相關的信息。

在圖二右側，大家可以看到項目概述屏幕中的細節面板所提供的幫助性定義信息。以下為其具體內容：

每個pod當中包含一套或者多套Docker容器，其共同運行于一個node當中，承載著應用程序的全部代碼。

一個服務組通過pod提供一個通用DNS名稱外加一個用于訪問的可選負載均衡式IP地址。

一套部署相當于應用程序的一套更新，由鏡像或者配置信息變更而觸發。

在圖二左側，大家可以看到底部所示為當前正在運行的兩個pod，頂部則為該服務URL。Smoke Test基本上屬于一款“hello, world” Web應用。其全部源代碼如下所示：

echo "Welcome to the OpenShift 3 Roadshow Smoke Test Application";

圖三所示為兩個正在運行的Smoke Test pod與一個已經完成的Build pod。

圖三：OpenShift 3 Web控制臺中的Smoke Test應用Pod視圖。其中兩個pod負責容納正在運行的應用程序;第三個pod則顯示已成功build。

Lab 3的作用是引導大家從Docker Hub當中獲取一套鏡像，即Kubernetes Guestbook應用程序，并將該鏡像部署至OpenShift Enterprise當中以創建一個運行pod及服務。在這一流程當中，大家將查看到以下提示信息：

注意：需要強調的是，出于安全性考量，OpenShift 3在默認情況下不允許將Docker鏡像部署作為root加以運行。如果大家希望或者需要允許OpenShift用戶部署Docker鏡像并將其作為root運行(或者只針對特定用戶)，則必須對相關配置稍加變更。

換句話來說，大家無法在正常的安全設置之下在OpenShift當中運行任意隨機Docker鏡像。根據我了解到的情況，OpenShift Enterprise在未來的版本——有可能是3.1.1版本——當中，將會面向特定用戶為Docker鏡像提供沙箱環境：當前運行中的鏡像將在該沙箱之內擁有root權限，但在其它OpenShift Enterprise環境下則不會以root方式運行。

Lab 4指導大家如何為自己的服務創建路由機制，從而允許其與外界進行通信。Lab 5則負責引導各位利用如下命令行對應用程序進行規模伸縮：

$ oc scale --replicas=3 rc guestbook-1

以上命令會在復制控制器(簡稱rc)當中將guestbook-1控制器的必要復制pod數量設定為3。在此之后，該rc將檢查當前服務當中的實際pod數量，如果當前數量為1，則創建另外2個pod。如果大家關閉了其中一個pod，也許是因為其停止響應并需要重建，那么該復制控制器將以幾乎即時的方式快速創建1個新pod。

Lab 6負責為大家講解s2i(即源代碼到鏡像)，這項“magic”服務(屬于免費開源項目)能夠“通過將源代碼直接轉化為Docker鏡像的方式為用戶提供可直接使用的鏡像，且該新Docker鏡像當中囊括了builder鏡像以及build源代碼。”在這一步驟當中，大家可以嘗試在GitHub上fork一套JBoss應用庫并以自己的repo為基礎利用s2i與JBoss EAP鏡像實現應用程序的創建、構建并運行：

$ oc new-app jboss-eap6-openshift~https://github.com//openshift3mlbparks.git

一旦其構建完成并開始運行，我們就能夠通過將該服務與互聯網對接創建對應路由：

$ oc expose service openshift3mlbparks

該服務的作用是顯示北美區域地圖，但不包含任何球場位置。

在Lab 7當中，我們要做的是向該服務中添加一個MongoDB pod，同時向數據庫憑證提供各類環境變量。接下來，大家需要在部署控制器(簡稱dc)當中設定同樣的環境變量;OpenShift會立即檢測到已變更環境，獲取該dc版本并進行重新部署。與此同時，應用程序會與該數據庫相對接，這樣就能保證各球場位置皆可正常顯示。圖四所示為各重新部署的pod。

圖四：Openshift 3 mlbparks應用各pod。這款應用負責顯示各主要聯盟球場位置。第一個pod用于運行MongoDB數據庫，第二個用于運行Java應用，第三個則為已經完成的build。

在Lab 8當中，大家需要在自己的GitHub repo當中設置一個Web鉤子，其會在檢測到有代碼推送至當前repo時向OpenShift Enterprise部署控制器發出通知。接下來，各位要做的是對Web頁面的源代碼進行修改、檢查并將成果提交至GitHub。OpenShift會檢查發來的通知信息，做出對應變更，進行應用程序重構，而后成功構建該dc的增量版本并重新加以部署。圖五所示為經過數次登記之后該openshift3mlbparks應用的運行效果。

圖五：運行在OpenShift之上的美國棒球大聯盟球場應用。該應用依靠Java代碼實現并與一套MongoDB數據庫加以配合。標題當中的“InfoWorld”與“mod2”來自我在源代碼庫中添加的部分，旨在觸發Web鉤子來實現OpenShift對該應用的重構與重新部署。

Lab 9負責指導大家如何利用應用程序模板來加快部署流程。其并不會實際教授大家如何創建模板，這部分內容可以點擊此處查看開發者指南中的對應說明(英文原文)。

OpenShift Enterprise 2中的幾項功能如今在OpenShift Enterprise 3當中已經被舍棄。其中比較重要的一項就是gear閑置：OpenShift Enterprise 3目前無法對未獲取到任何流量的pod進行閑置。也許這一功能缺失將在OpenShift Enterprise 3.2當中得到解決。同樣的，OpenShift Enterprise 3也無法以自動方式在負載提升或者下降時進行pod規模伸縮;但可以肯定這個問題在后續版本中必然得到修正。

而在另一方面，OpenShift Enterprise 3能夠支持藍/綠部署。立足于存在問題的“綠”部署進行回滾可謂非常簡單：

$ oc edit route/blue

另外，OpenShift Enterprise 3并不像我想象的那樣能夠面向多種鏡像實現Docker容器切換，據說這是出于安全性方面的考量。而一旦OpenShift Enterprise的下個版本迎來了沙箱機制，各類鏡像將都能夠以root方式運行，而這個問題也將自然得到解決。

總體而言，我對于OpenShift 3的評價還是非常積極的。而且在這里我可以嚴肅地向大家保證，“對于開發人員與運維工作者，OpenShift實現了PaaS技術所做出的全部承諾。”

整體概述

OpenShift Enterprise 3已經經過全面重寫以對接Docker容器技術。盡管目前尚有一部分必要功能存在缺失，但將在下個版本當中得到妥善解決，而這套PaaS方案具備著毋庸置疑的強大性、易用性以及出色的可擴展能力。

OpenShift Origin:免費; OpenShift Enterprise起步價格為每年4000美元，具體取決于配置情況(核心/虛擬機或者插槽數量)。 OpenShift Online目前仍然處于版本2階段，因此并不在本評測的涵蓋范疇之內。OpenShift Dedicated目前為早期開放使用階段，已升級至版本3且運行在任意AWS可用區當中。

優勢

擁有廣泛的容器、語言、Web框架、數據庫以及應用程序堆?？捎眯耘c支持能力。

易于使用且可快速自助部署。

在源代碼層面實現Git集成。

可運行在任意支持紅帽企業Linux系統的硬件、云或者虛擬機當中。

能夠運行任意滿足安全要求的Linux Docker容器系統。

缺點

不少常見Docker容器無法滿足其嚴苛的安全要求。

目前尚不提供等同于“gear閑置”的新版本功能。

目前尚不支持Windows Docker容器。

目前只允許通過手動方式在命令行界面當中進行pod規模伸縮調節。