对PaaS的简单介绍
问题描述。
一般我们传统开发，折腾服务器在所难免。选择时得考虑CPU大小, 内存多少，带宽如何，以及有什么操作系统; 然后还得在上面安装自己需要的语言、框架、服务，Web 服务器(虽然这一般都有默认安装)，应用服务器，以及其它中间件之类的；再有就是登录上去然后发布、管理应用，维护应用和服务器本身。
如果只有少量应用或服务器，而且应用更新也不是很频繁；或者我们有专门的服务器管理员/运维人员(用专业的部署管理工具)，我们在服务器上折腾也没什么。
但一旦场景复杂起来，比如虚拟机/应用很多，或者应用本身更新比较频繁，重复操作就会增多，我们的人力成本就自然而然的提高。
一种解决方案。
在追求“简洁、快速，自动化”的今天，选择PaaS不失为一个很好的选择。PaaS是Platform-as-a-Service的缩写，意思是平台即服务。从最终开发者(用户)的角度来说，就是“把服务器交出来”；而从供应商的角度，就是“把平台交出来“。大多数用户需要在服务器上运行的操作，供应商都以服务的形式提供出来。
也就是说所有与服务器相关的操作，基本上用户都不必关心，PaaS平台都已经帮我们想好了。平台提供的运行时、服务中间件、开发工具等一般都能满足我们的要求，用户只专心编写与应用直接相关的应用代码就行了。不用担心负载均衡、缓存、扩展，把系统管理和运维忘了吧！
----------------------------------------------------------------------
当然了，任何事都有利有弊，使用PaaS需要一定成本。举几个例子：
1. 你需要熟悉你所使用的PaaS平台。即使你永远不会对其进行二次开发，但也不能对其完全不了解，至少每个PaaS平台所提供的开发工具你是要学会的。毕竟PaaS平台改变了用户的编程习惯，而改变习惯有时成本是很高的。
2. 一定程度信任你所使用的PaaS平台。代码、数据、应用安全怎样，应用规模比较大时性能能否满足要求，平台是否够稳定，这都需要你自己体验之后才能知道。再就是：你能否容忍将你的代码托管在第三方，公司防火墙外？
3. 被绑定的危险。出于安全等因素，并不是所有PaaS平台所提供的运行时、服务中间件等都是标准的，而是经过修改的。即使不考虑这一点，对于应用开发中常用的功能，大多数PaaS平台都喜欢以扩展服务的方式提供给开发者选择，而这些扩展服务往往会导致PaaS平台的专有性，移植起来不容易。无论是应用的迁入、迁出，还是更改另一PaaS供应商，你都免不了要更改代码。
4. 另外就是没有办法安装系统软件。例如Imagemagick等一些常用的包，平台提供你就能采用。但是如果你另外还需要些什么，你将不得不对其进行破解，或者委曲求全。
5. 不成熟。
对于用户来说，服务器不可见，提供方便的同时也带来了限制。按照供应商服提供的平台“规范”来做，你确实可以减少很多繁琐、重复的工作，但一旦你想按自己的特定需求、不按“规矩”办事，那无疑你会遇到很大的阻力，毕竟服务器对你来说不可见了，你不能在上面进行任何操作。
对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平台)
----------------------------------------------------------------
管理
2. 负责记录自定义域名/解析外部请求(主要是通过浏览器)的 DNS、BIND
3. 检查 Broker结点，检查整个PaaS平台
4. 作为管家，管理着整个PaaS平台(应用、用户、destrict、domain等)
5. 对整个PaaS平台统计，报表功能
6. 对整个平台软硬件资源的使用情况分配
管理执行者是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。
Cartridges 就是服务。
“服务”这个概念比较笼统，阅读下文后你再回来理解吧^_^。
l 通用可以打包的功能，或者插件。
l 目前 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 结点本身以及对软硬件等资源的配置
这部分，主要是对 FrontendHttpServer，ApplicationContaine，Node三者的操作。
这部分，用户可感知、可操作。
也就是说开发人员通过浏览器、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.
其它
一. common 想必大家对 MVC 模型都比较熟悉，common 组件本质就是从 Broker/Controller & Node 这两个组件里的 model层里的"通用的、不太重要的方法"抽取单独存放出来。
二. console 也就是 Web控制台。对应用的一些基本操作，比如创建、删除。最终开发者往往不喜欢用命令行，通过浏览器操作反而更加直观、高效，反正都是调用 RESTAPI 。
直接在浏览器上操作，与操作系统无关，不用安装，不用担心升级。不用记忆命令行。
三. msg-common用 .ddl 文件来对描述消息的输入&输出，包括类型、校验等。
四. pam_openshiftpam_openshift 设置默认安全上下文的PAM模。简单点说，pam_openshift为执行下一条命令设置好默认的安全上下文。 如果你在使用了pam_openshift 的应用中打开一个会话，那么在些会话中运行的脚本就默认在一个特定的上下文中运行。
五. plugins
1. auth 提供三种用户认证机制：
• kerberos
• mongo (默认)
• remote-user
2. dns
• bind 顾名思义，实现 BIND服务务。
• nsupdate 用nsupdate 实现 DNS更改服务。
• route53 允许OpenShift 使用 AWS Route53 DNS 服务来发布应。
• Avahi(新增功能)实现 DNS更改服务的另一方式。
3. msg-broker
4. msg-node
六. utiloo-diagnostics
对整个PaaS平台(包括Broder 和 Node 结点)的健康检查。
对所依赖的操作系统、rpm包、gem包、DNS、enterpris、selinux，到 Broker、Node结点的健康检查，几乎各个层面/各个组件都有被作用到。
七. node-proxy为 Node 提供"路由代理"。也就是 web proxy, 用的是node.js 编程语言编写。
和大部分代理服务器一样，它有缓存、防火墙，节省IP、加快响应速度等作用。
八. 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 做得如何。
一. 一个好的、成熟的 PaaS 平台可能涉及以下几点：
用户身份验证&授权、普通用户操作、管理员管理用户及平台
应用的打包编译、健康检查、水平垂直扩展
提供更多的扩展服务
资源的限制、隔离(主要是容器技术)
消息组件的选择
提供 Web控制台
提供(控制中心) REST API 中心
安装部署(小规模的开发、测试，大规模的生产环境；与IaaS的集成)，提供云开发测试环境防
DooS 等攻击、反向代理、负载均衡
平台管理
用户文档、开发文档、代码注释
命令行客户端
统计、灵活的计费方式(报表)
健康检查(性能、日志、监控)
低耦合、插件化、SOA
可靠性：冗余和快速故障转移
一定程序上帮助糟糕的用户优化他们的应用，或者监控到性能不好，告诉他们。
二. 一个好的、成熟的PaaS 平台至少应该做好以下几点：
1. 不绑定用户。也就是说用户不会依赖单一的PaaS平台环境，在不同的PaaS平台之间应用可以轻松切换。
2. 在安全、性能、监控(计费) 等方面至少能让人接受的方案
3. 尽可能少的改变用户编程习惯。对于用户来说，不再与服务器打交道，而是使用供应商提供的平台。
4. 增强 IaaS,SaaS 的竞争力。可以绑定在 IaaS 上面，或者提供 SaaS 服务。 PaaS的出现可以加快 SaaS 应用的开发速度。
-------------------------------------------------------------------
OpenShift 的开放性，以及代码实现上的优雅我很看好。另外可以 DIY (OpenShift 允许你SSH 登录到你的应用到进行必要的操作，这就像是提供给一个小型的 VPS)这个特性也很赞。让用户完全抛弃对服务器的操作并不都是好的，用户的需求是永远无法满足，OpenShift 甚至其它 PaaS 平台提供“标准解决方案”的同时，也应提供“灵活的解决方案”，我认为 OpenShift的这个特性让它有了一定的灵活 性。 —— ——
OpenShift 可以 SSH 登录的功能，以及开源开放的程度，是CloudFoundry所欠缺的。
[本文墙外地址：http://leekelby.blogspot.com/2013/03/paas-and-openshift.html]
原文链接：http://blog.csdn.net/restkuan/article/details/8691660
