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
|
