技术开发 频道

红帽OpenShift让应用程序部署更快捷

  【IT168 评论】平台即服务(简称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等少数应用属于例外。

0
相关文章