對PaaS的簡單介紹
問題描述。
一般我們傳統(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è)的部署管理工具)，我們在服務(wù)器上折騰也沒什么,。
但一旦場景復(fù)雜起來,，比如虛擬機(jī)/應(yīng)用很多，或者應(yīng)用本身更新比較頻繁,，重復(fù)操作就會增多,，我們的人力成本就自然而然的提高。
一種解決方案,。
在追求“簡潔,、快速，自動(dòng)化”的今天,，選擇PaaS不失為一個(gè)很好的選擇,。PaaS是Platform-as-a-Service的縮寫，意思是平臺即服務(wù),。從最終開發(fā)者(用戶)的角度來說,，就是“把服務(wù)器交出來”；而從供應(yīng)商的角度,，就是“把平臺交出來“,。大多數(shù)用戶需要在服務(wù)器上運(yùn)行的操作，供應(yīng)商都以服務(wù)的形式提供出來,。
也就是說所有與服務(wù)器相關(guān)的操作,，基本上用戶都不必關(guān)心，PaaS平臺都已經(jīng)幫我們想好了,。平臺提供的運(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平臺,。即使你永遠(yuǎn)不會對其進(jìn)行二次開發(fā),，但也不能對其完全不了解，至少每個(gè)PaaS平臺所提供的開發(fā)工具你是要學(xué)會的,。畢竟PaaS平臺改變了用戶的編程習(xí)慣,，而改變習(xí)慣有時(shí)成本是很高的。
2. 一定程度信任你所使用的PaaS平臺,。代碼,、數(shù)據(jù)、應(yīng)用安全怎樣,，應(yīng)用規(guī)模比較大時(shí)性能能否滿足要求,，平臺是否夠穩(wěn)定，這都需要你自己體驗(yàn)之后才能知道,。再就是：你能否容忍將你的代碼托管在第三方,，公司防火墻外？
3. 被綁定的危險(xiǎn),。出于安全等因素,，并不是所有PaaS平臺所提供的運(yùn)行時(shí)、服務(wù)中間件等都是標(biāo)準(zhǔn)的,，而是經(jīng)過修改的,。即使不考慮這一點(diǎn)，對于應(yīng)用開發(fā)中常用的功能,，大多數(shù)PaaS平臺都喜歡以擴(kuò)展服務(wù)的方式提供給開發(fā)者選擇,，而這些擴(kuò)展服務(wù)往往會導(dǎo)致PaaS平臺的專有性，移植起來不容易,。無論是應(yīng)用的遷入,、遷出，還是更改另一PaaS供應(yīng)商,，你都免不了要更改代碼,。
4. 另外就是沒有辦法安裝系統(tǒng)軟件。例如Imagemagick等一些常用的包,，平臺提供你就能采用,。但是如果你另外還需要些什么，你將不得不對其進(jìn)行破解,，或者委曲求全,。
5. 不成熟。
對于用戶來說,，服務(wù)器不可見,，提供方便的同時(shí)也帶來了限制,。按照供應(yīng)商服提供的平臺“規(guī)范”來做，你確實(shí)可以減少很多繁瑣,、重復(fù)的工作,，但一旦你想按自己的特定需求、不按“規(guī)矩”辦事,，那無疑你會遇到很大的阻力,，畢竟服務(wù)器對你來說不可見了，你不能在上面進(jìn)行任何操作,。
對OpenShift簡單介紹
Openshift.com 是紅帽線上的PaaS平臺,。OpenShift允許個(gè)人開發(fā)者或開發(fā)團(tuán)隊(duì)在此平臺上創(chuàng)建、測試,、部署以及運(yùn)行應(yīng)用,。
從代碼上，OpenShift 平臺主要涉及五個(gè)項(xiàng)目:
* rhc 訪問基于 OpenShift 的 PaaS平臺的命令工具,。
* origin-server 最核心的項(xiàng)目,，包括了 Broker, Node 和各種不同功能的插件(比如：DNS, 通信，驗(yàn)證),。它還包含了一些不可或缺的 cartridges, 在部署OpenShift時(shí)會自動(dòng)安裝,。
* origin-community-cartridges 社區(qū)開發(fā)的 cartridges。
* origin-dev-tools在本地或 EC2 上部署OpenShift所需的打包&測試工具,。
* puppet-openshift_origin 配置 OpenShift平臺的 puppet 腳本,。
從邏輯上，OpenShift平臺有兩類結(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),。
在針對各個(gè)組件進(jìn)行分析前，我們先來看一張OpenShift的架構(gòu)圖,。對比著看,，有利于你的理解：
一. Broker
Broker結(jié)點(diǎn)是什么？
橋梁,，連接 用戶請求 <==> Node 的橋梁,；
控制中心,，通過它可以配置和管理平臺,。
能做什么？
配置
1. 配置 Broker結(jié)點(diǎn)(甚至是整個(gè)PaaS平臺)
----------------------------------------------------------------
管理
2. 負(fù)責(zé)記錄自定義域名/解析外部請求(主要是通過瀏覽器)的 DNS、BIND
3. 檢查 Broker結(jié)點(diǎn),，檢查整個(gè)PaaS平臺
4. 作為管家,，管理著整個(gè)PaaS平臺(應(yīng)用、用戶,、destrict,、domain等)
5. 對整個(gè)PaaS平臺統(tǒng)計(jì)，報(bào)表功能
6. 對整個(gè)平臺軟硬件資源的使用情況分配
管理執(zhí)行者是PaaS平臺本身 或者 PaaS平臺管理員,，開發(fā)者和最終用戶的操作與 Broker組件管理這部分無關(guān),。
――――――――――――――――――――――――――――――――
補(bǔ)充：
現(xiàn)在的broker結(jié)點(diǎn)單點(diǎn)對外，用戶通過Web控制臺,、CLI工具或JBoss 工具通過 REST API 與它交互,。
Broker組件本身是無狀態(tài)的，所有的狀態(tài)都通過MongoID ORM持久化到MongoDB里,。
與其它組件的聯(lián)系,？
會調(diào)用controller組件 里的 models/ 里的方法。
特別說明：注意broker結(jié)點(diǎn)和broker組件的區(qū)別,。
OpenShift目前有兩類結(jié)點(diǎn),，其中之一是broker，而恰好又有一個(gè)組件也叫 broker,。上面提到的“能做什么”,，是針對 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è)賬號，擁有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í)都會占用一個(gè)或多個(gè)端口,，并且還會擁有一些與之相關(guān)的環(huán)境變量(供cartridge之間通信或者用戶使用),。
三. Controller
controller 組件本身是一個(gè) Rails 項(xiàng)目(之前的 Broker 組件也一樣)，知道這一點(diǎn)對你理解代碼很有幫助,，但它們都不是完整的,。
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 組件對外暴露 REST API,，因?yàn)槭?Rails 項(xiàng)目,，所以你通過閱讀 config/routes.rb源代碼文件 即可知道有哪些接口。
根據(jù)：外部請求 --> REST API --> controllers -->models,，可知 controller組件 主要是針對數(shù)據(jù)庫的 CRUD 操作,，與數(shù)據(jù)庫關(guān)系最親密(雖然 broker組件&node組件也有對數(shù)據(jù)庫也有一些操作，但相比來說很少),。這也是它的局限性：功能上,，只處理/實(shí)現(xiàn)“與數(shù)據(jù)庫相關(guān)”的操作。
這里把它涉及的操作資源列一下：
應(yīng)用容器代理,；
認(rèn)證服務(wù),；
賬單服務(wù)(新增功能)；
數(shù)據(jù)存儲,；
分布式相關(guān),；
DNS 服務(wù)；
異常處理,；
審計(jì)日志,；
用戶行為跟蹤日志。
四. Node
是什么
Node也就是放應(yīng)用的地方(不必區(qū)分物理機(jī)還是虛擬機(jī)),。用戶應(yīng)用被分隔在不同的容器里,，一個(gè) Node 可以有多個(gè)容器。系統(tǒng)管理員可以同時(shí)對多個(gè) Node 進(jìn)行操作,。
―――――――――――――――――――――――――――――――――――――――――――――――
Node 從實(shí)現(xiàn)上來說分為兩部分,。
第一部分
對自定義域名,、應(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)本身以及對軟硬件等資源的配置
這部分，主要是對 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í)，會使用默認(rèn)的cgroup配置來限制/隔離他可用的資源,。
l unix_user 權(quán)限,、資源分配限制
l PAM – 后文介紹
＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 我是分隔線 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
第二部分
這部分我寫細(xì)一些，方便與第一部分區(qū)別,。
對 Node 組件的自我健康檢查
自行管理 gears 里的app及其狀態(tài)
將多個(gè)請求合并為一個(gè)請求,，發(fā)送給 apache
初始化配額
最后一次訪問 & 訪問列表，用戶“可用的端口”列表
設(shè)置 Node 結(jié)點(diǎn)
和第一部分對比,，我們不難發(fā)現(xiàn)：這部分,，普通用戶一般不可感知、不可操作(初始化配額,，設(shè)置 Node 結(jié)點(diǎn)等對用戶來說顯然是透明的),。由平臺自行完成或平臺管理員觸發(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 想必大家對 MVC 模型都比較熟悉，common 組件本質(zhì)就是從 Broker/Controller & Node 這兩個(gè)組件里的 model層里的"通用的,、不太重要的方法"抽取單獨(dú)存放出來,。
二. console 也就是 Web控制臺。對應(yīng)用的一些基本操作,，比如創(chuàng)建,、刪除。最終開發(fā)者往往不喜歡用命令行,，通過瀏覽器操作反而更加直觀,、高效，反正都是調(diào)用 RESTAPI ,。
直接在瀏覽器上操作,，與操作系統(tǒng)無關(guān)，不用安裝,，不用擔(dān)心升級,。不用記憶命令行。
三. msg-common用 .ddl 文件來對描述消息的輸入&輸出,，包括類型,、校驗(yàn)等。
四. pam_openshiftpam_openshift 設(shè)置默認(rèn)安全上下文的PAM模,。簡單點(diǎn)說,，pam_openshift為執(zhí)行下一條命令設(shè)置好默認(rèn)的安全上下文。 如果你在使用了pam_openshift 的應(yīng)用中打開一個(gè)會話,，那么在些會話中運(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
對整個(gè)PaaS平臺(包括Broder 和 Node 結(jié)點(diǎn))的健康檢查,。
對所依賴的操作系統(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.
這里給出一張簡單的步驟圖:
| 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ū)分。
對OpenShift的簡單介紹,，到此先告一段落,。由于上面提到的內(nèi)容可以過多，一下子難以了解它們之間的關(guān)系及消化,。我做了下面的架構(gòu)圖,，供你參考。
回顧PaaS與OpenShift
上面對 PaaS 和 OpenShift 都做了簡單的介紹,，下面我們來回顧一下 PaaS 中要解決哪些問題,，并看看OpenShift 做得如何。
一. 一個(gè)好的,、成熟的 PaaS 平臺可能涉及以下幾點(diǎn)：
用戶身份驗(yàn)證&授權(quán),、普通用戶操作、管理員管理用戶及平臺
應(yīng)用的打包編譯,、健康檢查,、水平垂直擴(kuò)展
提供更多的擴(kuò)展服務(wù)
資源的限制、隔離(主要是容器技術(shù))
消息組件的選擇
提供 Web控制臺
提供(控制中心) REST API 中心
安裝部署(小規(guī)模的開發(fā),、測試,，大規(guī)模的生產(chǎn)環(huán)境；與IaaS的集成),，提供云開發(fā)測試環(huán)境防
DooS 等攻擊,、反向代理,、負(fù)載均衡
平臺管理
用戶文檔、開發(fā)文檔,、代碼注釋
命令行客戶端
統(tǒng)計(jì)、靈活的計(jì)費(fèi)方式(報(bào)表)
健康檢查(性能,、日志,、監(jiān)控)
低耦合、插件化,、SOA
可靠性：冗余和快速故障轉(zhuǎn)移
一定程序上幫助糟糕的用戶優(yōu)化他們的應(yīng)用,，或者監(jiān)控到性能不好，告訴他們,。
二. 一個(gè)好的,、成熟的PaaS 平臺至少應(yīng)該做好以下幾點(diǎn)：
1. 不綁定用戶。也就是說用戶不會依賴單一的PaaS平臺環(huán)境,，在不同的PaaS平臺之間應(yīng)用可以輕松切換,。
2. 在安全、性能,、監(jiān)控(計(jì)費(fèi)) 等方面至少能讓人接受的方案
3. 盡可能少的改變用戶編程習(xí)慣,。對于用戶來說，不再與服務(wù)器打交道,，而是使用供應(yīng)商提供的平臺,。
4. 增強(qiáng) IaaS,SaaS 的競爭力?？梢越壎ㄔ?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è)特性也很贊,。讓用戶完全拋棄對服務(wù)器的操作并不都是好的，用戶的需求是永遠(yuǎn)無法滿足,，OpenShift 甚至其它 PaaS 平臺提供“標(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
