【2014年1月3日 51CTO外電頭條】平臺即服務（簡稱PaaS）是一種專門針對應用程序開發所設計的云基礎托管環境，目的是在無需部署昂貴內部基礎設施的前提下提供功能全面的開發、分期以及生產環境。

PaaS的其它優勢還包括配置快捷、便于協作以及自動負載平衡能力。

我們對紅帽的PaaS OpenShift Online與開源版本OpenShift Origin兩個版本進行了測試。紅帽方面還另外提供了OpenShift企業版本，但我們并沒有進行測試。總體來說，相較于OpenShift Origin來說、我們更偏愛OpenShift Online版本，因為后者的設置更簡單、而且令人意外的是性能表現也更出色。兩款產品在協作方面的表現同時勝出，都很搶眼。在協作環境下，團隊中的開發者們可以輕松從所處的不同位置向OpenShift提交變更。其實這一點正是PaaS真正的便捷性所在、也是它能引發廣泛關注的主要原因。

OpenShift Online既可以作為免費方案使用，也可以作為"Premium Silver方案"（我們測試的是免費版本）使用。OpenShift的所有版本全部基于RHEL（即紅帽企業Linux）或者Fedora的OpenShift Origin版本。在開發方面，OpenShift支持多種編程語言、框架以及工具，其中包括PHP、Ruby、JBoss以及Python，外加數據庫選項（例如MySQL、MariaDB以及PostreSQL等等）與一套DIY模式。OpenShift由兩大主要單元構成：Broker，用于管理登錄、DNS以及應用程序狀態；以及Cartridges，負責為各類工具、數據庫以及應用程序提供提供"插件"功能。應用程序可以通過命令行或者圖形用戶界面工具進行創建。紅帽公司承諾，如果一款應用程序可以運行在紅帽企業Linux 64位版本上，那么它就一定可以運行在OpenShift環境下。

OpenShift Online

我們首先測試的是OpenShift Online，大家只需在OpenShift Online管理控制臺中設置一個賬戶即可輕松開始訪問。基于Web的管理控制臺界面非常友好，同時提供非常實用的"工具提示"信息，能夠幫助用戶在幾分鐘之內創建自己的賬戶并準備好投入應用程序開發。在完成了賬戶設置并通過導航在門戶頁面中轉了一圈之后，我們開始將著眼點轉移到底層架構方面。OpenShift利用紅帽所謂"gear"來實現資源分配，分配方案分為兩種--小型與中型。小型gear提供單一單元，配備512MB內存與1GB存儲空間；中型gear則分別擁有1GB的內存與存儲空間。免費版本允許我們將最多三套gear結合起來，從而實現總體1.5GB內存與3GB磁盤空間。OpenShift Online Silver方案提供更為強大的性能，可同時支持最多16套中型gear。要升級到Silver版本，我們需要每個月為平臺支付20美元的使用費，并在兩個版本免費提供的三套小型gear之外為每套gear每小時再額外掏出3、10或者13美分使用費。

管理門戶允許用戶限制一款應用程序所能使用的gear數量，同時也控制著應用程序是否可以自動實現擴展。擴展工作由一套位于應用程序與公共互聯網之間的負載平衡cartridge所控制。HAProxy cartridge會與應用程序一道運行在首套gear當中，而當應用程序擴展至三套gear以上時、首套gear中的應用將被關閉，從而保證HAProxy能夠使用該gear中的所有可用資源。

產品評測：

為了判斷何時需要添加新gear，HAProxy會整理往來數據流量以確保各gear之上的負載能夠平衡。紅帽公司為每套gear分配了十六條連接，一旦應用程序運行所使用的資源達到整體資源的九成，新gear將立即加入進來。在Silver版本中，我們進行了計算：如果用戶每月三十天、每天二十四小時不間斷使用資源，那么一個月的出去大約在一千美元左右。不過由于大部分應用程序都存在峰值時段，因此我們不太可能遇到十六套gear全部長時間滿載的狀況。

在服務器上完成賬戶設置之后，下一步就是配置客戶端工具。雖然OpenShift應用能夠直接通過紅帽的RHC命令行程序加以管理，但我們仍然選擇了Eclipse以及方便快捷的JBoss GUI--除了實際效果拔群之外，這樣的處理方式還不會給我們部署好的應用帶來任何額外開銷。為了進一步保護我們的GUI工具，大家還需要使用調試功能、從而更輕松地實現對潛在問題的追蹤。

Eclipse要求用戶提前安裝Java JDK或者JRE，而通過Eclipse向OpenShift發布則需要用到一款插件--不過別擔心，大家可以從Eclipse MartketPlace網站上輕松完成安裝。不過，需要提醒大家的是這些先決條件只來源于本地Eclipse開發平臺；如果大家利用RHC命令行工具來管理應用程序，那么完全可以不理會上述組件。OpenSift應用的全部源代碼都由GIT庫負責管理，其運作方式可本地可遠程、而且能夠在客戶端與服務器之間實現同步。

我們參照的是紅帽公司官方網站上的說明，其內容非常詳盡，但事實證明這些指導信息有點陳舊--而且直接導致配置成果無法正常起效。這類狀況在開源文檔當中經常發生，因為這種失誤往往源自不斷涌現的產品及開發工具新版本。在進行了一系列深層研究后，我們意識到雖然已經安裝了Eclipse最新版本（即Kepler），但JBoss工具說明中所提到的其實是另一個推出時間更晚的修正版本；因此我們需要安裝這套更新版本，從而使開發環境正常運行。

在開發環境被正確配置完成之后，接下來要做的就是利用Apache Tomcat作為Web服務器、以PostgreSQL數據庫為后端Web內容安裝第一款應用程序了。為了初步驗證概念，我們的第一基進在網頁中顯示一條簡單消息、其內容則提取自數據庫。

在創建發安全密鑰之后，我們又相繼完成了數據庫設置、連接字符串與網頁構建，現在是時候開發并部署新應用程序了。對于首次創建來說，這個過程相當耗費時間，不過后續開發（增量式開發）的過程則相當快捷。在經過調整之后我們的"Hello World"頁面終于如預期般通過遠程瀏覽器顯示在混合OpenShift/用戶分配域名之上，而且整個過程無需涉及DNS。聽起來很簡單，總體來說也確實不難，但剛剛接角OpenShift的開發人員需要在應用程序被"推送"至服務器時多加注意。

當接收所推送的變更時，Openshift會在默認情況下中止對應應用程序、對其進行重建而后重啟該應用。這一過程耗時很長，而且會給生產型應用程序帶來我們不希望看到的停機時間。為了解決停機問題，OpenShift提供一套熱部署選項，允許開發人員在無需重啟應用程序的前提下實現變更推送。大部分應用程序類型都能夠利用熱部門機制實現推送，只有Jenkins以及HAProxy等少數應用屬于例外。

OpenShift Origin

在OpenShift Online上成功建立并測試了幾款應用程序之后，我們決定轉而嘗試OpenShift Origin。OpenShift Origin的源文件可以作為虛擬機（可用于KVM、VMware或者VirtualBox）從GitHub上下載，也可以直接下載源代碼并通過Puppet以及RPM創建屬于自己的版本。為了節省時間，我們選擇了VirtualBox虛擬機。在紅帽在線說明的指引下，我們以最低要求運行了mDNS（一種備選、組播主機名稱解析服務），從而快速完成了部署工作。

在OpenShift Origin的導入部署指南當中，我們發現其描述方式"詳盡到令人發指"的程度--是的，我們敢保證事實正是如此。不過這只是種委婉的贊揚，絕不屬于批評。這份指南非常出色，而且在我們看來完全應該成為其它開源產品說明文檔的執行標準。

紅帽公司推薦使用mDNS，它能夠幫助我們擺脫對DHCP的依賴。不過無論是否使用mDNS，DNS配置對于我們來說都是場艱難卓絕的斗爭。我們的服務器已經運行有DHCP，因此我們希望能讓它在測試當中發揮作用。最后，我們通過主機IP與OpenShift中分配的FQDN（即完全限定域名）實現了測試應用的訪問。這其實算是一種小瑕疵，因此我們在利用專有DNS服務器的生產環境中不可能實際采用這種形式。

性能表現的問題就更嚴重了。在我們的測試服務器上，OpenShift管理控制臺的響應速度相當緩慢--即使我們為其分配為4GB內存（相較于最低配置要求高出3GB）并采用了多核心服務器級設備。我們原本以為本地方案在運行速度上會優于在線版本，但事實卻恰恰相反。我們猜測，這可能是由前面提到的DNS問題所引發。

在Eclipse方面，即使是在閱讀了非常詳盡的安全密鑰管理與本地主機新密鑰分配說明之后，我們發現自己仍然需要一套額外的獨立Eclipse設置--因為OpenShift Origin無法與我們的安全密鑰正常對接。在這里我們再次作出小小妥協，同絕大多數開發人員一樣單獨選擇了OpenShift Online版本或者OpenShift Origin版本，而沒有將二者加以結合。

最后，我們成功在自己的本地OpenShift Origin主機上開發并部署了幾種類型的應用程序，并用到了一系更設置與數據庫方案。這臺主機設備曾經有幾次崩潰及卡死的狀況出現，我們不得不對其進行冷啟動。開發過程沒有出現問題，不過我們意識到在實際生產環境中仍然可能遇上問題--舉例來說，將OpenShift Origin用于托管那些擁有與互聯網托管應用類似的服務水平協議的企業內網應用。

出于測試的目的，我們最終將勝者頭銜頒發給了速度更快、使用更簡單的OpenShift Online--它徹底消除了DNS帶來的麻煩，單從這個角度講就比我們的OpenShift Origin本地版本好上太多了。不過它仍然要求使用安全密鑰。安全密鑰的管理同樣令人抓狂，但總體來說我們對于能在開源產品中看到這樣的安全改進而感到振奮，由此可見如今的技術行業終于開始對一直困擾著開源方案的安全缺陷著手改進了，非常好！不過話雖如此，要滿足安全最初實踐要求，我們仍然建議大家通過購買供應商技術支持與服務水平協議來保證生產環境中的云計算產品能擁有更為完善的保護機制。

最典型的例子就是，紅帽公司幾乎沒有為OpenShift Online以及OpenShift Origin提供任何擔保承諾，并特別聲明稱該公司不會對大部分與托管相關的重要運營項目提供保障，其中包括運行時間、備份以及恢復等。

即使在Silver版本當中，對于服務水平感到不滿的客戶也無法獲得任何與自身支出相符的承諾。其實這種"誰用誰負責"的論調在開源產品當中極為常見，因為越來越多的廠商開始將開源方案視為發掘潛在客戶的重要手段--他們只在乎能領先商業競爭對手一步奪取客戶，而根本沒有充分評估產品的誠意。但這并不能影響我們對開源的支持熱情，畢竟其真正優勢不可忽視，即能夠自由且充分地對產品進行評估、并從架構及核心的深度加以研究。不過在實際使用開源代碼的時候，請大家務必認真提前考慮到現實問題、并為其準備一套健康的實測環境。

原文鏈接：http://www.networkworld.com/reviews/2013/120213-red-hat-openshift-test-276332.html?page=1