Press "Enter" to skip to content

PaaS and OpenShift

一般我们传统开发,折腾服务器在所难免。选择时得考虑CPU大小,内存多少,带宽如何,以及有什么操作系统; 然后还得在上面安装自己需要的语言、框架、服务,Web 服务器(虽然这一般都有默认安装),应用服务器,以及其它中间件之类的;再有就是登录上去然后发布、管理应用,维护应用和服务器本身。

如果只有少量应用或服务器,而且应用更新也不是很频繁;或者我们有专门的服务器管理员/运维人员(用专业的部署管理工具),我们在服务器上折腾也没什么。

但一旦场景复杂起来,比如虚拟机/应用很多,或者应用本身更新比较频繁,重复操作就会增多,我们的人力成本就自然而然的提高。

一种解决方案。

在追求“简洁、快速,自动化”的今天,选择PaaS不失为一个很好的选择。PaaS是Platform-as-a-Service的缩写,意思是平台即服务。从最终开发者(用户)的角度来说,就是“把服务器交出来”;而从供应商的角度,就是“把平台交出来“。

也就是说所有与服务器相关的操作,基本上用户都不必关心,PaaS平台都已经帮我们想好了。平台提供的运行时、服务中间件、开发工具等一般都能满足我们的要求,用户只专心编写与应用直接相关的应用代码就行了。不用担心负载均衡、缓存、扩展,把系统管理和运维忘了吧!

—————————————————————–

当然了,任何事都有利有弊,使用PaaS需要一定成本。举几个例子:

  1. 你需要熟悉你所使用的PaaS平台。即使你永远不会对其进行二次开发,但也不能对其完全不了解,至少每个PaaS平台所提供的开发工具你是要学会的。毕竟PaaS平台改变了用户的编程习惯,而改变习惯有时成本是很高的。
  1. 一定程度信任你所使用的PaaS平台。代码、数据、应用安全怎样,应用规模比较大时性能能否满足要求,平台是否够稳定,这都需要你自己体验之后才能知道。
  1. 被绑定的危险。出于安全等因素,并不是所有PaaS平台所提供的运行时、服务中间件等都是标准的,而是经过修改的。即使不考虑这一点,对于应用开发中常用的功能,大多数PaaS平台都喜欢以扩展服务的方式提供给开发者选择,而这些扩展服务往往会导致PaaS平台的专有性,移植起来不容易。无论是应用的迁入、迁出,还是更改另一PaaS供应商,你都免不了要更改代码。
  1. 和上面的有点重复。你能否容忍将你的代码托管在第三方,公司防火墙外?
  1. 不成熟。

对于用户来说,服务器不可见,提供方便的同时也带来了限制。按照供应商服提供的平台“规范”来做,你确实可以减少很多繁琐、重复的工作,但一旦你想按自己的特定需求、不按“规矩”办事,那无疑你会遇到很大的阻力,毕竟服务器对你来说不可见了,你不能在上面进行任何操作。

对OpenShift简单介绍

Openshift.com 是红帽线上的 PaaS 平台。OpenShift 允许个人开发者或开发团队在此平台上创建、测试、部署以及运行应用。

从代码上,OpenShift 平台主要涉及五个项目:

* rhc 访问基于 OpenShift 的 PaaS平台 的命令工具。

* origin-server核心的项目,包括了 Broker, Node 和各种不同功能的插件(比如:DNS, 通信,验证)。它还包含了一些不可或缺的cartridges, 在部署OpenShift时会自动安装。

* origin-community-cartridges 社区开发的 cartridges。

* origin-dev-tools 在本地或 EC2 上部署OpenShift所需的打包&测试工具。

* puppet-openshift_origin 配置 OpenShift平台 的 puppet 脚本。

从逻辑上,OpenShift 平台有两类结点:一个broker结点,一个或多个node结点。

Broker 包括了创建和管理用户应用,比如通过验证服务来给用户验证,通过通信机制与 node 通信。 Node 上面有许多被称为 gear 的容器,用户的应用在此容器上运行。 Broker结点通过消息服务可以选择和一定程序上控制Node结点。

对OpenShift各个组件分别介绍之前先来看一张图:

一. Broker

Broker结点是什么?

桥梁,连接 用户请求 <==> Node 的桥梁;

控制中心,通过它可以配置和管理平台。

能做什么?

配置

  1. 配置 Broker结点(甚至是整个PaaS平台)

—————————————————————-

管理

  1. 2. 负责记录自定义域名/解析外部请求(主要是通过浏览器)的DNS、BIND
  2. 检查 Broker结点,检查整个PaaS平台
  3. 4. 作为管家,管理着整个PaaS平台(应用、用户、destrict、domain等)
  4. 5. 对整个PaaS平台统计,报表功能
  5. 对整个平台软硬件资源的使用情况分配

管理的执行者是 PaaS平台本身 或者 PaaS平台管理,开发者和最终用户的操作与 Broker组件管理这部分无关

―――――――――――――――――――――――――――――――

补充:

现在的broker结点单点对外,用户通过Web控制台、CLI工具或JBoss工具通过 REST API 与它交互。

Broker组件本身是无状态的,所有的状态都通过MongoID ORM持久化到MongoDB里。

与其它组件的联系?

会调用 controller组件 里的 models/ 里的方法。

特别说明:注意broker结点和broker组件的区别。

OpenShift目前有两类结点,其中之一是broker,而恰好又有一个组件也叫 broker。上面提到的“能做什么”,是针对 broker结点,而不是broker组件,因为broker结点组成部分还有下文提到的 controller组件。

二. Gear, Cartridges

Gear 就是拥有一系列软硬资源的容器(沙箱/沙盒),应用在这个容器里运行。

每个gear所拥有的资源是受到限制的,而且彼此之间相互隔离的,也就是说你在这个gear上所使用的资源多少并不影响其它gear,除非你人为的让它们相连。

现在默认openshift.com上每个账号,拥有3个免费gear。
特别说明一点:创建gear时会同时创建一个相应的unix user,至于有什么好处,你懂的。

Cartridges 就是服务。“服务”这个概念比较笼统,阅读下文后你再回来理解吧^_^。通用可以打包的功能,或者插件。目前 cartridges 可以分为以下几类:Service, domain_scope, web_proxy, web_framework, ci, ci_builder等。

l  OpenShift 目前有许多 language cartridges 比如: JBoss, PHP, Ruby(Rails)等,也有许多的 DB cartridges 比如:Postgres, Mysql, Mongo等。

l  Cartridges 一般有很多命令和控制机制提供给应用。

l  许多 cartridge 提供服务时都会占用一个或多个端口,并且还会拥有一些与之相关的环境变量(供cartridge之间通信或者用户使用)。

三.  Controller

controller 组件本身是一个 Rails 项目(之前的 Broker 组件也一样),知道这一点对你理解代码很有帮助,但它们都不是完整的。

Broker组件 + controller组件 才是一个完整的 Rails 项目。Broker程序主要用于配置作用,所有的逻辑都实现于Controller组件。也就是说Controller组件没有 config目录、没有配置应用服务器、也没有配置Web服务器,controller组件本身是不可运行的。

因为应用服务器与Web服务器配置部分在 broker组件,而且它们所位于的结点类型又叫做 Broker,所以在心里我们无形中把controller的功劳归为broker了。

作用

controller 组件对外暴露 REST API,因为是 Rails 项目,所以你通过阅读 config/routes.rb源代码文件 即可知道有哪些接口。

根据:外部请求 –> REST API –> controllers –> models,可知controller组件 主要是针对数据库的 CRUD 操作,与数据库关系最亲密(虽然 broker组件&node组件 也有对数据库也有一些操作,但相比来说很少)。这也是它的局限性:功能上,只处理/实现“与数据库相关”的操作。

这里把它涉及的操作资源列一下:

应用容器代理;

认证服务;

账单服务(新增功能);

数据存储;

分布式相关;

DNS 服务;

异常处理;

审计日志;

用户行为跟踪日志。

四. Node

是什么

Node 也就是放应用的地方(不必区分物理机还是虚拟机)。用户应用被分隔在不同的容器里,一个 Node 可以有多个容器。系统管理员可以同时对多个 Node 进行操作。

――――――――――――――――――――――――――――――――――――――――

Node 从实现上来说分为两部分。

第一部分

对自定义域名、应用、ssh-key、环境变量等的增删查改。

启动、停止应用,更改应用或对其进行控制,更改namespace等。

自定义控制 gear

Node

cartridge 的信息查询

quota 查询配额、设置配额

Node 结点本身以及对软硬件等资源的配置

部分,主要是FrontendHttpServerApplicationContaineNode 三者的操作。

部分,用可感知、可操作。

也就是说开发人员通过浏览器、CLI 所进行的大部分操作,都和这部分(FrontendHttpServer,ApplicationContaine,Node)有关。

涉及主要技术

l  cgroups

Cgroups 为每一个 node 结点上的用户提供资源限制和隔离。

Node 结点启动时,就得确保所有用户的cgroup配置都是有效的。

当创建用户时,会使用默认的cgroup配置来限制/隔离他可用的资源。

l  unix_user 权限、资源分配限制

l  PAM – 后文介绍

============ 我是分隔线 ============

第二部分

这部分我写细一些,方便与第一部分区别。

对 Node 组件的自我健康检查

自行管理 gears 里的app及其状态

将多个请求合并为一个请求,发送给 apache

初始化配额

最后一次访问 & 访问列表,用户“可用的端口”列表

设置 Node 结点

和第一部分对比,我们不难发现:部分,普通一般不可感知、不可操作(初始化配额设置 Node 结点等对用户来说显然是透明的)由平台自行完成或平台管理员触发。

当然了,Node 的这两部分区分有时也不太明显,但我们没有必要纠结于这个。

只在很少的几种情况下,Node才需要与 broker 交互。

最常见的情况有:

* haproxy 添加/移除 gear.

* jenkins 启动/停止 app.

还有就是 node结点 向外提供了接口,broker 可以通过接口控制某个gear 甚至 gear 里的 cartridge.

其它

  1. 一. common 想必大家对 MVC 模型都比较熟悉,common  组件本质就是从 Broker/Controller & Node 这两个组件里的 model 层里的”通用的、不太重要的方法”抽取单独存放出来。
  1. 二. console 也就是 Web控制台。对应用的一些基本操作,比如创建、删除。最终开发者往往不喜欢用命令行,通过浏览器操作反而更加直观、高效,反正都是调用 REST API 。

直接在浏览器上操作,与操作系统无关,不用安装,不用担心升级。不用记忆命令行。

  1. 三. msg-common 用 .ddl 文件来对描述 消息的输入&输出,包括类型、校验等。
  1. 四. pam_openshift pam_openshift 设置默认安全上下文的 PAM模。 简单点说,pam_openshift 为执行下一条命令设置好默认的安全上下文。 如果你在使用了 pam_openshift 的应用中打开一个会话,那么在些会话中运行的脚本就默认在一个特定的上下文中运行。
  1. 五. plugins
  1. auth 提供三种用户认证机制:
  • kerberos
  • mongo (默认)
  • remote-user
  1. dns
  • bind 顾名思义,实现 BIND服务务。
  • nsupdate 用 nsupdate 实现 DNS更改服务。
  • route53 允许 OpenShift 使用 AWS Route53 DNS 服务来发布应。
  • Avahi(新增功能) 实现 DNS更改服务的另一方式。
  1. msg-broker
  2. msg-node
  1. 六. util oo-diagnostics

对整个PaaS平台(包括 Broder 和 Node 结点)的健康检查。

对所依赖的操作系统、rpm包、gem包、DNS、enterpris、selinux,到 Broker、Node 结点的健康检查,几乎各个层面/各个组件都有被作用到。

  1. 七. node-proxy 为 Node 提供”路由代理”。也就是 web proxy, 用的是js 编程语言编写。

和大部分代理服务器一样,它有缓存、防火墙,节省IP、加快响应速度等作用。

  1. 八. port-proxy 配置HAProxy 以便可以在内网 –> 外网,或者 gearßà gear 之间实现“端口转发”

九.Avahi-cname-manager(新增功能)

Avahi 是Zeroconf规范的开源实现,包含了一整套多播DNS(multicastDNS)/DNS-SD网络服务的实现。允许程序在不需要进行手动网络配置的情况下,在一个本地网络中发布和获知各种服务和主机。

十.弹性伸缩

想知道OpenShift如何实现伸缩,第一步就是牢记它实现上用到了haproxy。

Haproxy cartridge – haproxy is a FOSS load balancing solution.

这里给出一张简单的步骤图:

| Browser |

|

| system httpd | (http://myapp-mydomain.rhcloud.com/)

|

| haproxy |

|

| gear | (http://$short_uuid-mydomain.rhcloud.com:$high_port)

本图上只用到了一个 gear, 但如果用到了多个 gear,可以根据它们不同的 short_uuid 和 high_port 来区分。

对OpenShift的简单介绍,到此先告一段落。由于上面提到的内容可以过多,一下子难以了解它们之间的关系及消化。我做了下面的架构图,供你参考。

回顾PaaS与OpenShift

上面对 PaaS 和 OpenShift 都做了简单的介绍,下面我们来回顾一下PaaS 中要解决哪些问题,并看看 OpenShift 做得如何。

  1. 一. 一个好的、成熟的 PaaS 平台可能涉及以下几点:

用户身份验证&授权、普通用户操作、管理员管理用户及平台

应用的打包编译、健康检查、水平垂直扩展

提供更多的扩展服务

资源的限制、隔离(主要是容器技术)

消息组件的选择

提供 Web控制台

提供(控制中心) REST API 中心

安装部署(小规模的开发、测试,大规模的生产环境;与IaaS的集成),提供云开发测试环境 防

DooS 等攻击、反向代理、负载均衡

平台管理

用户文档、开发文档、代码注释

命令行客户端

统计、灵活的计费方式(报表)

健康检查(性能、日志、监控)

低耦合、插件化、SOA

可靠性:冗余和快速故障转移

一定程序上帮助糟糕的用户优化他们的应用,或者监控到性能不好,告诉他们。

  1. 二. 一个好的、成熟的 PaaS 平台至少应该做好以下几点:
  1. 不绑定用户。也就是说用户不会依赖单一的PaaS平台环境,在不同的PaaS平台之间应用可以轻松切换。
  2. 在安全、性能、监控(计费) 等方面至少能让人接受的方案
  3. 尽可能少的改变用户编程习惯。对于用户来说,不再与服务器打交道,而是使用供应商提供的平台。
  4. 增强 IaaS, SaaS 的竞争力。可以绑定在 IaaS 上面,或者提供SaaS 服务。 PaaS的出现可以加快 SaaS 应用的开发速度。

————————————————————–

OpenShift 的开放性,以及代码实现上的优雅我很看好。另外可以DIY (OpenShift 允许你SSH 登录到你的应用到进行必要的操作,这就像是提供给一个小型的 VPS)这个特性也很赞。让用户完全抛弃对服务器的操作并不都是好的,用户的需求是永远无法满足,OpenShift 甚至其它 PaaS 平台提供“标准解决方案”的同时,也应提供“灵活的解决方案”,我认为 OpenShift 的这个特性让它有了一定的灵活性。                                                                                                                            —— ——

OpenShift 可以 SSH 登录的功能,以及开源开放的程度,是CloudFoundry所欠缺的。

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *