PaaS 及OpenShift架構(gòu)簡(jiǎn)介

來源：CSDN　瀏覽：917次　時(shí)間：2015-08-26

對(duì)PaaS的簡(jiǎn)單介紹

問題描述,。

一般我們傳統(tǒng)開發(fā)，折騰服務(wù)器在所難免,。選擇時(shí)得考慮CPU大小, 內(nèi)存多少,，帶寬如何,，以及有什么操作系統(tǒng); 然后還得在上面安裝自己需要的語言、框架,、服務(wù),，Web 服務(wù)器(雖然這一般都有默認(rèn)安裝)，應(yīng)用服務(wù)器,，以及其它中間件之類的,；再有就是登錄上去然后發(fā)布,、管理應(yīng)用，維護(hù)應(yīng)用和服務(wù)器本身,。

如果只有少量應(yīng)用或服務(wù)器,，而且應(yīng)用更新也不是很頻繁；或者我們有專門的服務(wù)器管理員/運(yùn)維人員(用專業(yè)的部署管理工具),，我們?cè)诜?wù)器上折騰也沒什么,。

但一旦場(chǎng)景復(fù)雜起來，比如虛擬機(jī)/應(yīng)用很多,，或者應(yīng)用本身更新比較頻繁,，重復(fù)操作就會(huì)增多，我們的人力成本就自然而然的提高,。

一種解決方案,。

在追求“簡(jiǎn)潔、快速,，自動(dòng)化”的今天,，選擇PaaS不失為一個(gè)很好的選擇。PaaS是Platform-as-a-Service的縮寫,，意思是平臺(tái)即服務(wù),。從最終開發(fā)者(用戶)的角度來說,，就是“把服務(wù)器交出來”,；而從供應(yīng)商的角度，就是“把平臺(tái)交出來“,。大多數(shù)用戶需要在服務(wù)器上運(yùn)行的操作,，供應(yīng)商都以服務(wù)的形式提供出來。

也就是說所有與服務(wù)器相關(guān)的操作,，基本上用戶都不必關(guān)心,，PaaS平臺(tái)都已經(jīng)幫我們想好了。平臺(tái)提供的運(yùn)行時(shí),、服務(wù)中間件,、開發(fā)工具等一般都能滿足我們的要求，用戶只專心編寫與應(yīng)用直接相關(guān)的應(yīng)用代碼就行了,。不用擔(dān)心負(fù)載均衡,、緩存、擴(kuò)展,，把系統(tǒng)管理和運(yùn)維忘了吧,！

----------------------------------------------------------------------

當(dāng)然了，任何事都有利有弊,，使用PaaS需要一定成本,。舉幾個(gè)例子：

1. 你需要熟悉你所使用的PaaS平臺(tái),。即使你永遠(yuǎn)不會(huì)對(duì)其進(jìn)行二次開發(fā)，但也不能對(duì)其完全不了解,，至少每個(gè)PaaS平臺(tái)所提供的開發(fā)工具你是要學(xué)會(huì)的,。畢竟PaaS平臺(tái)改變了用戶的編程習(xí)慣，而改變習(xí)慣有時(shí)成本是很高的,。

2. 一定程度信任你所使用的PaaS平臺(tái),。代碼、數(shù)據(jù),、應(yīng)用安全怎樣,，應(yīng)用規(guī)模比較大時(shí)性能能否滿足要求，平臺(tái)是否夠穩(wěn)定,，這都需要你自己體驗(yàn)之后才能知道,。再就是：你能否容忍將你的代碼托管在第三方，公司防火墻外,？

3. 被綁定的危險(xiǎn),。出于安全等因素，并不是所有PaaS平臺(tái)所提供的運(yùn)行時(shí),、服務(wù)中間件等都是標(biāo)準(zhǔn)的,，而是經(jīng)過修改的。即使不考慮這一點(diǎn),，對(duì)于應(yīng)用開發(fā)中常用的功能,，大多數(shù)PaaS平臺(tái)都喜歡以擴(kuò)展服務(wù)的方式提供給開發(fā)者選擇，而這些擴(kuò)展服務(wù)往往會(huì)導(dǎo)致PaaS平臺(tái)的專有性,，移植起來不容易,。無論是應(yīng)用的遷入、遷出,，還是更改另一PaaS供應(yīng)商,，你都免不了要更改代碼。

4. 另外就是沒有辦法安裝系統(tǒng)軟件,。例如Imagemagick等一些常用的包,，平臺(tái)提供你就能采用。但是如果你另外還需要些什么,，你將不得不對(duì)其進(jìn)行破解,，或者委曲求全。

5. 不成熟,。

對(duì)于用戶來說,，服務(wù)器不可見，提供方便的同時(shí)也帶來了限制。按照供應(yīng)商服提供的平臺(tái)“規(guī)范”來做,，你確實(shí)可以減少很多繁瑣,、重復(fù)的工作，但一旦你想按自己的特定需求,、不按“規(guī)矩”辦事,，那無疑你會(huì)遇到很大的阻力，畢竟服務(wù)器對(duì)你來說不可見了,，你不能在上面進(jìn)行任何操作,。

對(duì)OpenShift簡(jiǎn)單介紹

Openshift.com 是紅帽線上的PaaS平臺(tái)。OpenShift允許個(gè)人開發(fā)者或開發(fā)團(tuán)隊(duì)在此平臺(tái)上創(chuàng)建,、測(cè)試,、部署以及運(yùn)行應(yīng)用。

從代碼上,，OpenShift 平臺(tái)主要涉及五個(gè)項(xiàng)目:

* rhc 訪問基于 OpenShift 的 PaaS平臺(tái)的命令工具,。

* origin-server 最核心的項(xiàng)目，包括了 Broker, Node 和各種不同功能的插件(比如：DNS, 通信,，驗(yàn)證),。它還包含了一些不可或缺的 cartridges, 在部署OpenShift時(shí)會(huì)自動(dòng)安裝。

* origin-community-cartridges 社區(qū)開發(fā)的 cartridges,。

* origin-dev-tools在本地或 EC2 上部署OpenShift所需的打包&測(cè)試工具,。

* puppet-openshift_origin 配置 OpenShift平臺(tái)的 puppet 腳本。

從邏輯上,，OpenShift平臺(tái)有兩類結(jié)點(diǎn)：一個(gè)broker結(jié)點(diǎn),，一個(gè)或多個(gè)node結(jié)點(diǎn)。

Broker 包括了創(chuàng)建和管理用戶應(yīng)用,，比如通過驗(yàn)證服務(wù)來給用戶驗(yàn)證,，通過通信機(jī)制與 node 通信,。Node 上面有許多被稱為 gear 的容器,，用戶的應(yīng)用在此容器上運(yùn)行。Broker結(jié)點(diǎn)通過消息服務(wù)可以選擇和一定程序上控制Node結(jié)點(diǎn),。

在針對(duì)各個(gè)組件進(jìn)行分析前,，我們先來看一張OpenShift的架構(gòu)圖。對(duì)比著看,，有利于你的理解：

一. Broker

Broker結(jié)點(diǎn)是什么,？

橋梁，連接用戶請(qǐng)求 <==> Node 的橋梁,；

控制中心,，通過它可以配置和管理平臺(tái)。

能做什么？

配置

1. 配置 Broker結(jié)點(diǎn)(甚至是整個(gè)PaaS平臺(tái))

----------------------------------------------------------------

管理

2. 負(fù)責(zé)記錄自定義域名/解析外部請(qǐng)求(主要是通過瀏覽器)的 DNS,、BIND

3. 檢查 Broker結(jié)點(diǎn),，檢查整個(gè)PaaS平臺(tái)

4. 作為管家，管理著整個(gè)PaaS平臺(tái)(應(yīng)用,、用戶,、destrict、domain等)

5. 對(duì)整個(gè)PaaS平臺(tái)統(tǒng)計(jì),，報(bào)表功能

6. 對(duì)整個(gè)平臺(tái)軟硬件資源的使用情況分配

管理執(zhí)行者是PaaS平臺(tái)本身或者 PaaS平臺(tái)管理員,，開發(fā)者和最終用戶的操作與 Broker組件管理這部分無關(guān)。

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

補(bǔ)充：

現(xiàn)在的broker結(jié)點(diǎn)單點(diǎn)對(duì)外,，用戶通過Web控制臺(tái),、CLI工具或JBoss 工具通過 REST API 與它交互。

Broker組件本身是無狀態(tài)的,，所有的狀態(tài)都通過MongoID ORM持久化到MongoDB里,。

與其它組件的聯(lián)系？

會(huì)調(diào)用controller組件里的 models/ 里的方法,。

特別說明：注意broker結(jié)點(diǎn)和broker組件的區(qū)別,。

OpenShift目前有兩類結(jié)點(diǎn)，其中之一是broker,，而恰好又有一個(gè)組件也叫 broker,。上面提到的“能做什么”，是針對(duì) broker結(jié)點(diǎn),，而不是 broker組件,，因?yàn)閎roker結(jié)點(diǎn)組成部分還有下文提到的controller組件。

二. Gear, Cartridges

Gear 就是擁有一系列軟硬資源的容器(沙箱/沙盒),，應(yīng)用在這個(gè)容器里運(yùn)行,。

每個(gè)gear所擁有的資源是受到限制的，而且彼此之間相互隔離的,，也就是說你在這個(gè)gear上所使用的資源多少并不影響其它gear,，除非你人為的讓它們相連。

現(xiàn)在默認(rèn)openshift.com上每個(gè)賬號(hào),，擁有3個(gè)免費(fèi)gear,。

Cartridges 就是服務(wù)。

“服務(wù)”這個(gè)概念比較籠統(tǒng),，閱讀下文后你再回來理解吧^_^,。

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 一般有很多命令和控制機(jī)制提供給應(yīng)用,。

l 許多 cartridge 提供服務(wù)時(shí)都會(huì)占用一個(gè)或多個(gè)端口,，并且還會(huì)擁有一些與之相關(guān)的環(huán)境變量(供cartridge之間通信或者用戶使用)。

三. Controller

controller 組件本身是一個(gè) Rails 項(xiàng)目(之前的 Broker 組件也一樣),，知道這一點(diǎn)對(duì)你理解代碼很有幫助,，但它們都不是完整的。

Broker組件 + controller組件才是一個(gè)完整的 Rails 項(xiàng)目,。Broker程序主要用于配置作用,，所有的邏輯都實(shí)現(xiàn)于Controller組件。也就是說Controller組件沒有 config目錄,、沒有配置應(yīng)用服務(wù)器,、也沒有配置Web服務(wù)器，controller組件本身是不可運(yùn)行的,。

因?yàn)閼?yīng)用服務(wù)器與Web服務(wù)器配置部分在 broker組件,，而且它們所位于的結(jié)點(diǎn)類型又叫做 Broker，所以在心里我們無形中把controller的功勞歸為broker了,。

作用

controller 組件對(duì)外暴露 REST API,，因?yàn)槭?Rails 項(xiàng)目，所以你通過閱讀 config/routes.rb源代碼文件即可知道有哪些接口,。

根據(jù)：外部請(qǐng)求 --> REST API --> controllers -->models,，可知 controller組件主要是針對(duì)數(shù)據(jù)庫(kù)的 CRUD 操作，與數(shù)據(jù)庫(kù)關(guān)系最親密(雖然 broker組件&node組件也有對(duì)數(shù)據(jù)庫(kù)也有一些操作,，但相比來說很少),。這也是它的局限性：功能上，只處理/實(shí)現(xiàn)“與數(shù)據(jù)庫(kù)相關(guān)”的操作,。

這里把它涉及的操作資源列一下：

應(yīng)用容器代理,；

認(rèn)證服務(wù)；

賬單服務(wù)(新增功能),；

數(shù)據(jù)存儲(chǔ),；

分布式相關(guān)；

DNS 服務(wù),；

異常處理,；

審計(jì)日志；

用戶行為跟蹤日志,。

四. Node

是什么

Node也就是放應(yīng)用的地方(不必區(qū)分物理機(jī)還是虛擬機(jī))。用戶應(yīng)用被分隔在不同的容器里,，一個(gè) Node 可以有多個(gè)容器,。系統(tǒng)管理員可以同時(shí)對(duì)多個(gè) Node 進(jìn)行操作。

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

Node 從實(shí)現(xiàn)上來說分為兩部分。

第一部分

對(duì)自定義域名,、應(yīng)用,、ssh-key、環(huán)境變量等的增刪查改,。

啟動(dòng),、停止應(yīng)用，更改應(yīng)用或?qū)ζ溥M(jìn)行控制,，更改namespace等,。

自定義控制 gear

Node

cartridge 的信息查詢

quota 查詢配額、設(shè)置配額

Node 結(jié)點(diǎn)本身以及對(duì)軟硬件等資源的配置

這部分,，主要是對(duì) FrontendHttpServer,，ApplicationContaine，Node三者的操作,。

這部分,，用戶可感知、可操作,。

也就是說開發(fā)人員通過瀏覽器,、CLI 所進(jìn)行的大部分操作，都和這部分(FrontendHttpServer,，ApplicationContaine,，Node)有關(guān)。

涉及主要技術(shù)

l cgroups

Cgroups 為每一個(gè) node 結(jié)點(diǎn)上的用戶提供資源限制和隔離,。

Node 結(jié)點(diǎn)啟動(dòng)時(shí),，就得確保所有用戶的cgroup配置都是有效的。

當(dāng)創(chuàng)建用戶時(shí),，會(huì)使用默認(rèn)的cgroup配置來限制/隔離他可用的資源,。

l unix_user 權(quán)限、資源分配限制

l PAM – 后文介紹

＝＝＝＝＝＝＝＝＝＝＝＝＝＝我是分隔線＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

第二部分

這部分我寫細(xì)一些,，方便與第一部分區(qū)別,。

對(duì) Node 組件的自我健康檢查

自行管理 gears 里的app及其狀態(tài)

將多個(gè)請(qǐng)求合并為一個(gè)請(qǐng)求，發(fā)送給 apache

初始化配額

最后一次訪問 & 訪問列表,，用戶“可用的端口”列表

設(shè)置 Node 結(jié)點(diǎn)

和第一部分對(duì)比,，我們不難發(fā)現(xiàn)：這部分，普通用戶一般不可感知,、不可操作(初始化配額,，設(shè)置 Node 結(jié)點(diǎn)等對(duì)用戶來說顯然是透明的)。由平臺(tái)自行完成或平臺(tái)管理員觸發(fā),。

當(dāng)然了,，Node 的這兩部分區(qū)分有時(shí)也不太明顯,，但我們沒有必要糾結(jié)于這個(gè)。

只在很少的幾種情況下,，Node才需要與 broker 交互,。

最常見的情況有：

* haproxy添加/移除 gear.

* jenkins啟動(dòng)/停止 app.

還有就是 node結(jié)點(diǎn) 向外提供了接口，broker 可以通過接口控制某個(gè) gear 甚至 gear 里的 cartridge.

其它

一. common 想必大家對(duì) MVC 模型都比較熟悉,，common 組件本質(zhì)就是從 Broker/Controller & Node 這兩個(gè)組件里的 model層里的"通用的,、不太重要的方法"抽取單獨(dú)存放出來。

二. console 也就是 Web控制臺(tái),。對(duì)應(yīng)用的一些基本操作,，比如創(chuàng)建、刪除,。最終開發(fā)者往往不喜歡用命令行,，通過瀏覽器操作反而更加直觀、高效,，反正都是調(diào)用 RESTAPI ,。

直接在瀏覽器上操作，與操作系統(tǒng)無關(guān),，不用安裝,，不用擔(dān)心升級(jí)。不用記憶命令行,。

三. msg-common用 .ddl 文件來對(duì)描述消息的輸入&輸出,，包括類型、校驗(yàn)等,。

四. pam_openshiftpam_openshift 設(shè)置默認(rèn)安全上下文的PAM模,。簡(jiǎn)單點(diǎn)說，pam_openshift為執(zhí)行下一條命令設(shè)置好默認(rèn)的安全上下文,。如果你在使用了pam_openshift 的應(yīng)用中打開一個(gè)會(huì)話,，那么在些會(huì)話中運(yùn)行的腳本就默認(rèn)在一個(gè)特定的上下文中運(yùn)行。

五. plugins

1. auth 提供三種用戶認(rèn)證機(jī)制：

? kerberos

? mongo (默認(rèn))

? remote-user

2. dns

? bind 顧名思義,，實(shí)現(xiàn) BIND服務(wù)務(wù),。

? nsupdate 用nsupdate 實(shí)現(xiàn) DNS更改服務(wù)。

? route53 允許OpenShift 使用 AWS Route53 DNS 服務(wù)來發(fā)布應(yīng),。

? Avahi(新增功能)實(shí)現(xiàn) DNS更改服務(wù)的另一方式,。

3. msg-broker

4. msg-node

六. utiloo-diagnostics

對(duì)整個(gè)PaaS平臺(tái)(包括Broder 和 Node 結(jié)點(diǎn))的健康檢查。

對(duì)所依賴的操作系統(tǒng),、rpm包,、gem包、DNS,、enterpris,、selinux,，到 Broker,、Node結(jié)點(diǎn)的健康檢查,，幾乎各個(gè)層面/各個(gè)組件都有被作用到。

七. node-proxy為 Node 提供"路由代理",。也就是 web proxy, 用的是node.js 編程語言編寫,。

和大部分代理服務(wù)器一樣，它有緩存,、防火墻,，節(jié)省IP、加快響應(yīng)速度等作用,。

八. port-proxy配置HAProxy 以便可以在內(nèi)網(wǎng) --> 外網(wǎng),，或者gear ?àgear 之間實(shí)現(xiàn)“端口轉(zhuǎn)發(fā)”

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

Avahi 是Zeroconf規(guī)范的開源實(shí)現(xiàn)，包含了一整套多播DNS(multicastDNS)/DNS-SD網(wǎng)絡(luò)服務(wù)的實(shí)現(xiàn),。允許程序在不需要進(jìn)行手動(dòng)網(wǎng)絡(luò)配置的情況下,，在一個(gè)本地網(wǎng)絡(luò)中發(fā)布和獲知各種服務(wù)和主機(jī)。

十．彈性伸縮

想知道OpenShift如何實(shí)現(xiàn)伸縮,，第一步就是牢記它實(shí)現(xiàn)上用到了haproxy,。

Haproxy cartridge - haproxy is a FOSS load balancing solution.

這里給出一張簡(jiǎn)單的步驟圖:

| Browser |

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

| haproxy |

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

本圖上只用到了一個(gè) gear, 但如果用到了多個(gè)gear，可以根據(jù)它們不同的 short_uuid 和high_port 來區(qū)分,。

對(duì)OpenShift的簡(jiǎn)單介紹,，到此先告一段落。由于上面提到的內(nèi)容可以過多,，一下子難以了解它們之間的關(guān)系及消化,。我做了下面的架構(gòu)圖，供你參考,。

回顧PaaS與OpenShift

上面對(duì) PaaS 和 OpenShift 都做了簡(jiǎn)單的介紹,，下面我們來回顧一下 PaaS 中要解決哪些問題，并看看OpenShift 做得如何,。

一. 一個(gè)好的,、成熟的 PaaS 平臺(tái)可能涉及以下幾點(diǎn)：

用戶身份驗(yàn)證&授權(quán),、普通用戶操作,、管理員管理用戶及平臺(tái)

應(yīng)用的打包編譯,、健康檢查,、水平垂直擴(kuò)展

提供更多的擴(kuò)展服務(wù)

資源的限制,、隔離(主要是容器技術(shù))

消息組件的選擇

提供 Web控制臺(tái)

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

安裝部署(小規(guī)模的開發(fā),、測(cè)試,，大規(guī)模的生產(chǎn)環(huán)境,；與IaaS的集成),，提供云開發(fā)測(cè)試環(huán)境防

DooS 等攻擊,、反向代理,、負(fù)載均衡

平臺(tái)管理

用戶文檔、開發(fā)文檔,、代碼注釋

命令行客戶端

統(tǒng)計(jì),、靈活的計(jì)費(fèi)方式(報(bào)表)

健康檢查(性能、日志,、監(jiān)控)

低耦合,、插件化、SOA

可靠性：冗余和快速故障轉(zhuǎn)移

一定程序上幫助糟糕的用戶優(yōu)化他們的應(yīng)用,，或者監(jiān)控到性能不好,，告訴他們。

二. 一個(gè)好的,、成熟的PaaS 平臺(tái)至少應(yīng)該做好以下幾點(diǎn)：

1. 不綁定用戶,。也就是說用戶不會(huì)依賴單一的PaaS平臺(tái)環(huán)境，在不同的PaaS平臺(tái)之間應(yīng)用可以輕松切換,。

2. 在安全,、性能、監(jiān)控(計(jì)費(fèi)) 等方面至少能讓人接受的方案

3. 盡可能少的改變用戶編程習(xí)慣,。對(duì)于用戶來說,，不再與服務(wù)器打交道，而是使用供應(yīng)商提供的平臺(tái),。

4. 增強(qiáng) IaaS,SaaS 的競(jìng)爭(zhēng)力,。可以綁定在 IaaS 上面,，或者提供 SaaS 服務(wù),。 PaaS的出現(xiàn)可以加快 SaaS 應(yīng)用的開發(fā)速度。

-------------------------------------------------------------------

OpenShift 的開放性,，以及代碼實(shí)現(xiàn)上的優(yōu)雅我很看好,。另外可以 DIY (OpenShift 允許你SSH 登錄到你的應(yīng)用到進(jìn)行必要的操作，這就像是提供給一個(gè)小型的 VPS)這個(gè)特性也很贊,。讓用戶完全拋棄對(duì)服務(wù)器的操作并不都是好的,，用戶的需求是永遠(yuǎn)無法滿足，OpenShift 甚至其它 PaaS 平臺(tái)提供“標(biāo)準(zhǔn)解決方案”的同時(shí),，也應(yīng)提供“靈活的解決方案”,，我認(rèn)為 OpenShift的這個(gè)特性讓它有了一定的靈活性。 —— ——

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

[本文墻外地址：http://leekelby.blogspot.com/2013/03/paas-and-openshift.html]

原文鏈接：http://blog.csdn.net/restkuan/article/details/8691660