OpenShift 3如何震撼整个Docker容器世界

去年，OpenShift 2已经成为我个人最为喜爱的开源PaaS方案。那时候我曾经评论称，“OpenShift拥有极为惊人的易用性、易管理性与易安装性，而且对于那些熟知Git的开发人员以及了解Puppet的管理员而言，其几乎没有任何学习曲线。以自动化方式进行横向扩展简单地就像在应用配置当中进行设备检查一样。其默认启用设备自动闲置功能，而且允许用户以极高密度进行应用程序部署。另外，只需进行一次git push即可完成应用程序更新。无论是开发者还是运维人员，OpenShift都可谓满足了PaaS技术所做出的全部功能承诺。”

自那时开始，OpenShift一直在潜心闭关以完成面向Docker容器的应用程序部署能力转变，其进行了大规模重构而非单纯“cartridge”或者“gear”。从理论层面讲，这应该能够让OpenShift PaaS拥有更为出色的易用性并使其获得更为可观的编程语言与应用程序支持资源池，而这都要归功于Docker Hub当中现成可用的各类容器机制。不过从实践层面看，它的具体表现又是如何?下面就让我们一起探寻答案。

OpenShift 3架构

如图一所示，OpenShift 3仍然立足于红帽企业Linux基础之上。不过除此之外，其它的一切几乎都做出了调整。如今的运行单元已经不再是“gear”——而是“pod”，每个pod由一套或者多套Docker容器所构成，它们又共同运行在一个“node”之上。语言环境不再是“cartridge”，而转变成了Docker镜像，并利用一款“源代码到镜像”工具进行代码结合。顺带一提，node也就是RHEL当中应用程序的运行实例。

图一：OpenShift 3系统架构示意图。

调度、管理以及复制功能如此都成为主体组成部分，而主体则通过立足于RHEL的Kubernetes实现。其中一套服务层负责与底层虚拟或者物理硬件乃至公有或者私有云进行通信。另有一套路由层负责将各应用程序与互联网进行对接，如此一来它们就能够为运行在计算机或者移动设备上的客户端所使用。

开发人员可以利用oc命令行界面或者Web控制台在OpenShift 3上完成自助配置。目前一部分功能只适用于命令行界面，不过其将在未来的OpenShift 3.1版本当中为Web控制台所全面支持。

OpenShift SKU与安装

OpenShift目前拥有四套彼此独立但又密切相关的产品：OpenShift Origin、OpenShift Online、OpenShift Dedicated以及OpenShift Enterprise。

OpenShift Origin 3的主要卖点为开源与灵活性：大家可以将其自身作为容器加以运行、利用Ansible将其作为集群、或者利用Amazon Web Services或者Google Cloud Engine为其提供公有云运行环境。此版本属于上游代码，而且明确表现出了与OpenShift 2的差异之处。另外其还提供OpenShift Origin 3 Vagrant VirtualBox VM，大家能够在数分钟之内将其安装完成。

Online版本则需要托管于公有云之上，而且相当于直接从Origin代码当中剥离出的一部分。不过Online版本继续使用gear机制，这一点可以说已经与OpenShift 3完全脱离了。因此，我们可以认为Online仍然运行在OpenShift 2模式之下。

OpenShift Dedicated负责提供一套立足于公有云的专用、定制化且受管理应用平台，其被托管于Amazon Web Services内的任意可用区当中。这套版本由OpenShift 3 Enterprise提供支持并由红帽方面加以管理。

OpenShift Enterprise则是目前稳定性最出色且最为典型的安装选项。大家需要创建一套主节点、基础设施(包括注册表、路由器以及存储机制)以及至少两个节点，而且需要首先以RHEL启动，之后陆续添加Docker、Kubernetes以及OpenShift。在理想状态下，每个主机与节点将至少配备8 GB内存以供生产型使用。Enterprise版本与Pivotal CF以及Apprenda存在竞争关系，而且我个人利用由红帽公司提供的“巡演环境”对其进行了上手评测。

大家可以在笔记本电脑上安装并运行OpenShift Enterprise，而这也正是OpenShift Enterprise首席技术营销经理Erik Jacobs在首次为我进行演示时选择的方式。Jacobs将其称为“一套三虚拟机”配置，其中利用一套虚拟机作为主节点与基础设施主机(包括注册表与路由器)，而另两个节点则负责托管应用程序。

利用OpenShift 3进行开发

为了理解如今的OpenShift Enterprise如何与用户的开发需求相匹配，我放弃了自己原先经常使用的随机PaaS评测方式，而选择了采用红帽方面提供的“九实验室”机制。Lab 1基本上包含oc，即命令行界面工具的安装与运行。需要注意的是，虽然在实验室流程中的某些具体步骤方面有所区别，但OpenShift Enterprise当中的oc版本与OpenShift Origin其实并没有多大不同。

Lab 2则要求我们运行一套Smoke Test项目，了解如何使用oc并学习Web控制台的使用技巧，如图二所示。

图二：OpenShift中Web控制台 Smoke Test应用概述。右侧的细节描述解释了与pod、服务以及部署相关的信息。

在图二右侧，大家可以看到项目概述屏幕中的细节面板所提供的帮助性定义信息。以下为其具体内容：

每个pod当中包含一套或者多套Docker容器，其共同运行于一个node当中，承载着应用程序的全部代码。

一个服务组通过pod提供一个通用DNS名称外加一个用于访问的可选负载均衡式IP地址。

一套部署相当于应用程序的一套更新，由镜像或者配置信息变更而触发。

在图二左侧，大家可以看到底部所示为当前正在运行的两个pod，顶部则为该服务URL。Smoke Test基本上属于一款“hello, world” Web应用。其全部源代码如下所示：

echo "Welcome to the OpenShift 3 Roadshow Smoke Test Application"; 

图三所示为两个正在运行的Smoke Test pod与一个已经完成的Build pod。

图三：OpenShift 3 Web控制台中的Smoke Test应用Pod视图。其中两个pod负责容纳正在运行的应用程序;第三个pod则显示已成功build。

Lab 3的作用是引导大家从Docker Hub当中获取一套镜像，即Kubernetes Guestbook应用程序，并将该镜像部署至OpenShift Enterprise当中以创建一个运行pod及服务。在这一流程当中，大家将查看到以下提示信息：

注意：需要强调的是，出于安全性考量，OpenShift 3在默认情况下不允许将Docker镜像部署作为root加以运行。如果大家希望或者需要允许OpenShift用户部署Docker镜像并将其作为root运行(或者只针对特定用户)，则必须对相关配置稍加变更。

换句话来说，大家无法在正常的安全设置之下在OpenShift当中运行任意随机Docker镜像。根据我了解到的情况，OpenShift Enterprise在未来的版本——有可能是3.1.1版本——当中，将会面向特定用户为Docker镜像提供沙箱环境：当前运行中的镜像将在该沙箱之内拥有root权限，但在其它OpenShift Enterprise环境下则不会以root方式运行。

Lab 4指导大家如何为自己的服务创建路由机制，从而允许其与外界进行通信。Lab 5则负责引导各位利用如下命令行对应用程序进行规模伸缩：

$ oc scale --replicas=3 rc guestbook-1 

以上命令会在复制控制器(简称rc)当中将guestbook-1控制器的必要复制pod数量设定为3。在此之后，该rc将检查当前服务当中的实际pod数量，如果当前数量为1，则创建另外2个pod。如果大家关闭了其中一个pod，也许是因为其停止响应并需要重建，那么该复制控制器将以几乎即时的方式快速创建1个新pod。

Lab 6负责为大家讲解s2i(即源代码到镜像)，这项“magic”服务(属于免费开源项目)能够“通过将源代码直接转化为Docker镜像的方式为用户提供可直接使用的镜像，且该新Docker镜像当中囊括了builder镜像以及build源代码。”在这一步骤当中，大家可以尝试在GitHub上fork一套JBoss应用库并以自己的repo为基础利用s2i与JBoss EAP镜像实现应用程序的创建、构建并运行：

$ oc new-app jboss-eap6-openshift~https://github.com//openshift3mlbparks.git 

一旦其构建完成并开始运行，我们就能够通过将该服务与互联网对接创建对应路由：

$ oc expose service openshift3mlbparks 

该服务的作用是显示北美区域地图，但不包含任何球场位置。

在Lab 7当中，我们要做的是向该服务中添加一个MongoDB pod，同时向数据库凭证提供各类环境变量。接下来，大家需要在部署控制器(简称dc)当中设定同样的环境变量;OpenShift会立即检测到已变更环境，获取该dc版本并进行重新部署。与此同时，应用程序会与该数据库相对接，这样就能保证各球场位置皆可正常显示。图四所示为各重新部署的pod。

图四：Openshift 3 mlbparks应用各pod。这款应用负责显示各主要联盟球场位置。第一个pod用于运行MongoDB数据库，第二个用于运行Java应用，第三个则为已经完成的build。

在Lab 8当中，大家需要在自己的GitHub repo当中设置一个Web钩子，其会在检测到有代码推送至当前repo时向OpenShift Enterprise部署控制器发出通知。接下来，各位要做的是对Web页面的源代码进行修改、检查并将成果提交至GitHub。OpenShift会检查发来的通知信息，做出对应变更，进行应用程序重构，而后成功构建该dc的增量版本并重新加以部署。图五所示为经过数次登记之后该openshift3mlbparks应用的运行效果。

图五：运行在OpenShift之上的美国棒球大联盟球场应用。该应用依靠Java代码实现并与一套MongoDB数据库加以配合。标题当中的“InfoWorld”与“mod2”来自我在源代码库中添加的部分，旨在触发Web钩子来实现OpenShift对该应用的重构与重新部署。

Lab 9负责指导大家如何利用应用程序模板来加快部署流程。其并不会实际教授大家如何创建模板，这部分内容可以点击此处查看开发者指南中的对应说明(英文原文)。

OpenShift Enterprise 2中的几项功能如今在OpenShift Enterprise 3当中已经被舍弃。其中比较重要的一项就是gear闲置：OpenShift Enterprise 3目前无法对未获取到任何流量的pod进行闲置。也许这一功能缺失将在OpenShift Enterprise 3.2当中得到解决。同样的，OpenShift Enterprise 3也无法以自动方式在负载提升或者下降时进行pod规模伸缩;但可以肯定这个问题在后续版本中必然得到修正。

而在另一方面，OpenShift Enterprise 3能够支持蓝/绿部署。立足于存在问题的“绿”部署进行回滚可谓非常简单：

$ oc edit route/blue 

另外，OpenShift Enterprise 3并不像我想象的那样能够面向多种镜像实现Docker容器切换，据说这是出于安全性方面的考量。而一旦OpenShift Enterprise的下个版本迎来了沙箱机制，各类镜像将都能够以root方式运行，而这个问题也将自然得到解决。

总体而言，我对于OpenShift 3的评价还是非常积极的。而且在这里我可以严肃地向大家保证，“对于开发人员与运维工作者，OpenShift实现了PaaS技术所做出的全部承诺。”

整体概述

OpenShift Enterprise 3已经经过全面重写以对接Docker容器技术。尽管目前尚有一部分必要功能存在缺失，但将在下个版本当中得到妥善解决，而这套PaaS方案具备着毋庸置疑的强大性、易用性以及出色的可扩展能力。

OpenShift Origin:免费; OpenShift Enterprise起步价格为每年4000美元，具体取决于配置情况(核心/虚拟机或者插槽数量)。 OpenShift Online目前仍然处于版本2阶段，因此并不在本评测的涵盖范畴之内。OpenShift Dedicated目前为早期开放使用阶段，已升级至版本3且运行在任意AWS可用区当中。

优势

• 拥有广泛的容器、语言、Web框架、数据库以及应用程序堆栈可用性与支持能力。
• 易于使用且可快速自助部署。
• 在源代码层面实现Git集成。
• 可运行在任意支持红帽企业Linux系统的硬件、云或者虚拟机当中。
• 能够运行任意满足安全要求的Linux Docker容器系统。