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

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

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

OpenShift 3架構(gòu)

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

圖一：OpenShift 3系統(tǒng)架構(gòu)示意圖。

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

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

OpenShift SKU與安裝

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

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

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

OpenShift Dedicated負(fù)責(zé)提供一套立足于公有云的專用、定制化且受管理應(yīng)用平臺，其被托管于Amazon Web Services內(nèi)的任意可用區(qū)當(dāng)中。這套版本由OpenShift 3 Enterprise提供支持并由紅帽方面加以管理。

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

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

利用OpenShift 3進行開發(fā)

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

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

圖二：OpenShift中Web控制臺 Smoke Test應(yīng)用概述。右側(cè)的細(xì)節(jié)描述解釋了與pod、服務(wù)以及部署相關(guān)的信息。

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

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

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

一套部署相當(dāng)于應(yīng)用程序的一套更新，由鏡像或者配置信息變更而觸發(fā)。

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

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

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

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

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

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

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

#p#

Lab 4指導(dǎo)大家如何為自己的服務(wù)創(chuàng)建路由機制，從而允許其與外界進行通信。Lab 5則負(fù)責(zé)引導(dǎo)各位利用如下命令行對應(yīng)用程序進行規(guī)模伸縮：

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

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

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

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

一旦其構(gòu)建完成并開始運行，我們就能夠通過將該服務(wù)與互聯(lián)網(wǎng)對接創(chuàng)建對應(yīng)路由：

$ oc expose service openshift3mlbparks 

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

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

圖四：Openshift 3 mlbparks應(yīng)用各pod。這款應(yīng)用負(fù)責(zé)顯示各主要聯(lián)盟球場位置。第一個pod用于運行MongoDB數(shù)據(jù)庫，第二個用于運行Java應(yīng)用，第三個則為已經(jīng)完成的build。

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

[[157280]]

圖五：運行在OpenShift之上的美國棒球大聯(lián)盟球場應(yīng)用。該應(yīng)用依靠Java代碼實現(xiàn)并與一套MongoDB數(shù)據(jù)庫加以配合。標(biāo)題當(dāng)中的“InfoWorld”與“mod2”來自我在源代碼庫中添加的部分，旨在觸發(fā)Web鉤子來實現(xiàn)OpenShift對該應(yīng)用的重構(gòu)與重新部署。

Lab 9負(fù)責(zé)指導(dǎo)大家如何利用應(yīng)用程序模板來加快部署流程。其并不會實際教授大家如何創(chuàng)建模板，這部分內(nèi)容可以點擊此處查看開發(fā)者指南中的對應(yīng)說明(英文原文)。

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

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

$ oc edit route/blue 

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

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

整體概述

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

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

優(yōu)勢

• 擁有廣泛的容器、語言、Web框架、數(shù)據(jù)庫以及應(yīng)用程序堆?？捎眯耘c支持能力。
• 易于使用且可快速自助部署。
• 在源代碼層面實現(xiàn)Git集成。
• 可運行在任意支持紅帽企業(yè)Linux系統(tǒng)的硬件、云或者虛擬機當(dāng)中。
• 能夠運行任意滿足安全要求的Linux Docker容器系統(tǒng)。

缺點

• 不少常見Docker容器無法滿足其嚴(yán)苛的安全要求。
• 目前尚不提供等同于“gear閑置”的新版本功能。
• 目前尚不支持Windows Docker容器。
• 目前只允許通過手動方式在命令行界面當(dāng)中進行pod規(guī)模伸縮調(diào)節(jié)。

原文標(biāo)題：Review: OpenShift 3 rocks Docker containers

【51CTO.com獨家譯稿，合作站點轉(zhuǎn)載請注明出處】