| 平台即服务（简称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等少数应用属于例外。 |
