［Openshift Origin 3］OpenShift 3 : 基于Docker的私有PaaS平台

转自：http://dockone.io/article/564

OpenShift 3 : 基于Docker的私有PaaS平台

【编者的话】OpenShift是一个非常有前途的私用PaaS解决方案，它可以减少从项目开始到自动构建应用和部署的时间，它支持绝大多数的Web架构，将成为基于Docker的私有PaaS平台领域的参照。

OpenShift是一个私有的PaaS（Platform-as-a-Service）解决方案，主要用来在容器中搭建、部署以及运行应用程序。它是基于Apache 2.0许可的开源软件， 并且发行了两个版本， 一个是社区版， 一个是企业版。

第三版的起源

从2014年7月开始，OpenShift就己经着力于研究一个非常出色的项目，该项目是将技术架构和与Docker、Kubernetes整合到一起（现在这是一件很常见的事）。

一年前启动这个项目对于OpenShift来说是一个大胆而且充满风险的的决策。确实如此，当时云平台的竞争处于白热化的巅峰时期，而此时OpenShift就决定冒着风险启动这样一个非常重要的重建项目，这个风险主要来自于他们需要停止新特性的开发并妥协旧版本之间的兼容性问题。但是现在，我们相信他们作了一个正确的决定。

到目前为止，社区版本联合了86名GitHub上（GitHub是红帽上10个最活跃项目之一）的开发志愿者。在12个月中己经进行了16次的迭代，并且刚刚发行了第一版。

尽管这个方案主要是由红帽在推动，但它非常依赖Kubernetes（来源于Google）。由此引发了到底由谁来支配和主导的问题，该问题依赖于两个公司之间的协作和版本基准，Google开发出新特性后会发生什么？他们会关注Kubernetes还是OpenShift？很显然，这个问题还没有答案。

但是，Google的技术支持部门己经确认，由两家公司同时主导只会给OpenShift带来更多益处。它将成为比Docker企业版更具竟争力的产品（机器、组建和群）。

自动构建和部署应用：这怎么实现

OpenShift V3提供了3种来自动构建应用的方法。

1. Docker-File模式：通过向OpenShift提供指向Docker-File以及其依附关系的源码管理器的URI来自动构建一个Docker容器。
2. Source-To-Image模式（STI）：允许通过提交应用的源码到OpenShift来自动构建一个应用。（就像Heroku中的buildpacks）。

3. 自定义构建模式：允许提供自己的应用来构建逻辑，这是通过提供一个OpenShift Docker的镜像实现的。
   

   当注册表有新的应用映像版本发布或者应用配置有了更新时，OpenShift 3还允许定义一个自动的部署策略。
   

为了完成这些构建和部署特性，OpenShift 3提供了把它自己的应用蓝图定义成用JSON或Yaml格式的模板文件的功能。这些蓝图描述了应用的架构拓扑和容器的部署策略。
下面的图表描述了在OpenShit中，如何为3层应用将模板的不同组件进行组合的。

在“模板”中组合组件，一定程度上继承了Kubernetes的概念，需要记住以下主要的对象。
一个“POD”是一个Docker容器的运行环境（如果需要共享本地的资源， 我们将在单独的POD中部署两种类别的容器）
一个“服务”是一个入口，抽象出一个均衡访问负载到一组相同的容器，理论上，最少是一个服务对应一个架构层。
一个“服务部署者”或“部署配置”是一个对象，用来描述基于触发器的容器的部署策略。（比如，当Docker注册表中有新版本的映象时，需重新部署）。
一个“复制控制器”是一个技术组件，主要负责POD的弹性。
一个“路由”是用来显露一个应用的入口（域名解析，主机名或VIP）

通过它的多重部署机制和设置自身“蓝图”的能力，OpenShift第三版适用于大多数的复杂应用架构。

引擎盖下的优雅架构

OpenShift 3的架构可以作为单机模式部署（使用Docker镜像“openshift/origin”），也可以作为分布式模式部署。在随后的案例当中，用了两种服务器角色，主服务器和节点。

“主服务器”节点的功能是：

1. 处理来自于命令行或Web界面的API请求。
2. 构建映象和部署容器。
3. 确保POD复制的弹性。

“主服务器”依赖于基于etcd的分布式目录，主要用来提供配置共享和服务发现。

“节点”主要用来作为PODS的宿主和运行容器（应用和注册表）。

架构是分布式的、可扩展的和具有弹性的。但是平台自身暂时还不支持自动扩展能力：目前可提供的和底层服务器的容量计划只能通过手动调整。

可通过自身的REST API、CLI、Web portal来访问和管理平台。

OCTO的观点

OpenShift 3在介于“平台即服务”和“容器即服务”的世界间架起了一个有趣的桥，红帽提出了一个大胆的解决方案和一个最先进的架构，我们非常感谢“蓝图”的规格格式，来定义架构的需求格式和部署的编排。

在Beta 3版本中，OpenShift平台并没有强烈关注平台的可操作性，暂时并不建议将它应用在生产环境中，但是用户的各种问题是可以在路线图中找到的。

• 用ElasticSearch–Logstash–Kibana或Fluentd实现日志聚合。
• 用Heapster进行监控。
• 易实现集群部署。

我们相信在OpenShift 3中建模一个应用将会是一份新的工作，它需要新的技能，以便可以提出适当的问题，比如：如何组织容器？是否应该使用路由或服务？如何处理数据（一致性、复制、备份）？如何管理多重租用？如何集成开发和部署软件工厂？

总而言之，OpenShift是一个非常有前途的私用PaaS解决方案，它可以减少从项目开始到自动构建应用和部署的时间，它支持绝大多数复杂的Web架构，即使是数据的管理和外部服务的集成还没有得到完全应用。

我们相信OpenShift 3对一切都尽在掌握，它将成为基于Docker的私有PaaS平台领域的参照。