【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中的所有可用资源。
产品评测：
| 产品 | OpenShift Online与OpenShift Origin |
| 公司 | 红帽 |
| 优势 | 安装、配置、应用程序部署以及协作都非常简便。强大的工具与友善的用户在线管理控制台值得称赞。说明文档与背景帮助信息非常出色。前期成本投入很低甚至无需成本。 |
| 缺点 | 应用程序推送速度有可能比较慢。Origin版本中的DNS配置难度较大。在Online版本中，使用成本会随着自动扩展的进行而迅速飙升。对托管环境的控制比较有限。 |
为了判断何时需要添加新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
