云的基礎架構(gòu)已經(jīng)開始成形，如何在 OpenStack 上為各種應用程序提供更好的調(diào)度環(huán)境？

　　澳大利亞悉尼當?shù)貢r間11月6號上午9點，第16屆OpenStack峰會在悉尼國際會議中心盛大開幕，來自全球52個國家2300余名與會者，將就以OpenStack為核心的開放基礎架構(gòu)相關技術和商業(yè)實踐展開為期三天的討論，本文為第二天的討論內(nèi)容之一。

　　在2017年4月的 OpenStack 使用者調(diào)查中，可以看見，OpenStack 除了被當作是基礎設施服務外，也有許多使用于架構(gòu)測試與持續(xù)集成、數(shù)據(jù)庫、網(wǎng)絡服務、大數(shù)據(jù)等。加上最近當紅的邊緣計算（Edge Computing）、物聯(lián)網(wǎng)也有不少以 OpenStack 作為開發(fā)研究平臺的。

　　在上次峰會，由正式增加一個 OpenStack 政策開始，告知 OpenStack 必須重視應用程序需求（https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html  ），接著在悉尼峰會，各個討論與需求在許多專案內(nèi)開始發(fā)酵。我們繼續(xù)在這應用程序之路上深入討論。

　　為達成應用程序需求，從上次峰會就開始進行 Application Credentials 的設計規(guī)劃，讓應用程序可以使用由Keystone （驗證程序） 取得運行 OpenStack 服務的權(quán)限，應用程序能通過此權(quán)限操作 OpenStack 服務，但僅限于該權(quán)限允許的范疇。因此并不會破壞權(quán)限管理。

　　在Denver PTG 時，已經(jīng)有過技術上的細節(jié)討論（https://etherpad.openstack.org/p/queens-PTG-vmbm ），在峰會上 “ Application Credentials Feedback ” 技術議程主要報告目前所制訂的規(guī)格，并收集回饋。

　　此功能能讓應用程序使用部分 OpenStack 服務，而且不需要使用使用者信息作認證，直接將Application Credential 傳給被調(diào)用服務就可以使用該服務，能使用的服務范圍則是在Application Credential 創(chuàng)建時會被設定。

　　針對 PTG 時討論的修改，回饋都是正面的，一般來說 Credential 不會被用來重新創(chuàng)建其他 Application Credential 。但針對像是編排專案需求（例如當自動擴容時， Heat 需要有權(quán)限創(chuàng)建新擴容資源，像是目前使用 trusts 機制一樣 ）。

　　為什么筆者將此功能放在架構(gòu)變革區(qū)塊？其實上次峰會所做的報道也有提到，讓人驚訝的，權(quán)限架構(gòu)是目前社區(qū)認為最前哨的變革點，因為只有權(quán)限開通，才能讓其他服務開始計劃后續(xù)提供給應用程序的設計。

　　另一個變革，則屬于 “ Cloud-Native Design/Refactoring Across OpenStack （Part II） ” 技術議程所帶來的議題。

　　Cloud Native， 雖然詞匯一直存在，但變成變革則算是在 CNCF （ Cloud Native Computing Foundation ） 與容器化開始興起完善容器架構(gòu)，而 OpenStack 成熟后帶來的穩(wěn)定的云架構(gòu)。兩者合并后才開始被重視。對于新開發(fā)的應用程序來說，直接讓應用程序使用云框架與容器架構(gòu)上的服務（例如自動擴容，監(jiān)測，紀錄，修復等）。

　　議程中檢視 OpenStack 現(xiàn)有設計，討論如何讓 OpenStack 架構(gòu)更具有云架構(gòu)的優(yōu)勢。無疑對于應用程序來說，后續(xù)可行的設計并不會破壞現(xiàn)有程序的使用（ OpenStack 跨版本的相容性向來是一大優(yōu)勢）。

　　因此第一刀就落在狀態(tài)監(jiān)控，整個技術議程討論的重點在于如何建立符合云架構(gòu)的狀態(tài)收集（https://etherpad.openstack.org/p/sydney-cloud-native-partii） 。

　　設計重點在于提供所有專案一個可以將本身資源狀態(tài)上傳的一個平臺。通過計劃在 OSLO.Middleware 內(nèi)建立狀態(tài)回報工具。讓所有專案可以通過該工具將所有想丟到狀態(tài)列表的資源送到統(tǒng)一的地點。

　　后續(xù)再由各個服務自行選擇要如何判別這些狀態(tài)。會有這樣的設計是為了提供一個可以縱觀整體 OpenStack 狀態(tài)的平臺，讓資源狀態(tài)不在零散，也不再需要各別服務獨立開發(fā)資源狀態(tài)監(jiān)控的。相較效率與統(tǒng)一性會高很多。而這也就是此環(huán)節(jié)為第一刀的重點。目前還未有相關實踐，但是后續(xù)一定看好此功能。此為實際針對資源監(jiān)控大方向大問題進行改善的好的開發(fā)方針。

　　自動化是許多使用者的需求，需要一下環(huán)節(jié)互動而成：生成資源-》監(jiān)控資源-》信號觸發(fā)事件-》修復-》持續(xù)監(jiān)控。只要能滿足上面的環(huán)。就能達成自動化。最大的問題是各個環(huán)節(jié)應該用那些服務，服務間有無好的串連方式以達成最高效的自動化系統(tǒng)。

　　自動擴容 （ Auto-Scaling ） 在 OpenStack 環(huán)境并非新技術，操作成熟度也相當高。因此在峰會以使用者分享居多。而自動修復在峰會上是這次的一個小焦點之一，在技術議程 “ Self-healing and optimization SIG ” 里，第一次在峰會集合相關技術專家討論目前的修復功能與如何優(yōu)化。

　　目前在社群上 Heat 就有為自動修復做過深入調(diào)研，也提供方式供使用者參考

　�。╤ttps://github.com/openstack/heat-templates/tree/master/hot/autohealing）。

　　當然我們更希望我們能提供給使用者的自動化是更全方面的，因此這個 SIG 小組的任務才剛開始，相當多的人參加，也有很多自愿者愿意一起推動。

　　目前已經(jīng)決議成立此小組。后續(xù)也會有專有的IRC 頻道與會議，更重要的是，通過小組旗幟，號昭與收集更多使用者需求（https://etherpad.openstack.org/p/self-healing-rocky -forum）。

　　自動化流程也具有其他的標準協(xié)議像是IFTTT。值得一提，在實踐修復環(huán)節(jié)時，建議可以考慮 Mistral 服務，套用 OpenStack 在自動化流程時 Mistral 提供 流程管理服務，讓運行時可以按照實際狀況流程行動。

　　考慮使用 Heat 作為資源管理，而 Mistral 作為管理時的運營時的流程管理，在許多實際使用案例來看是一個不錯的架構(gòu)。在議程 “Mistral - Project Update”內(nèi)，Mistral PTL 介紹 Mistral 的現(xiàn)況與未來開發(fā)。

　　在上面的自動化流程與應用程序管理中，編排是簡化使用者端操作復雜度的方式。往往應用程序都是數(shù)個服務所組成，在多數(shù)實際運營環(huán)境中，應用程序可能必須調(diào)度在上百臺節(jié)點上。因此更需要統(tǒng)一管理的機制，增加管理強度，加快調(diào)度流程，減少失誤。在峰會上筆者有幸負責編排專案的幾個社區(qū)技術議程。

　　峰會第一天早上，即有編排專案的 Onboarding 技術議程。提供專案介紹、框架、腳本解說、調(diào)試方法與貢獻方式。讓開發(fā)者與操作者能夠更緊密與社區(qū)接軌。為了協(xié)助應用程序接軌，內(nèi)容使用自動修復與擴容腳本，與軟件設定編排（ Software Config ）腳本作為解說方向。讓撰寫腳本的操作者能更快速為應用程序制定 Cloud Native 環(huán)境。

　　在專案更新部分介紹幾個Pike 版本的新腳本功能（list_concat_unique， contains， make_url）與新資源（包含： OS：：Neutron：：Trunk， OS：：Neutron：：Segment， OS：：Zaqar：：Subscription， OS：：Zaqar：：MistralTrigger， OS：：Magnum：：Cluster， OS：：Magnum：：ClusterTemplate， OS：：Mistral：：ExternalResource， OS：：Zun：：Container）。其他提及功能包含，專案本身已支持python3，支持編排根據(jù)實況更新，新增 Heat-Agents 子專案，更完善的分布式服務。

　　其中可以觀察到 Zaqar 資源的更新為了完善應用程序管理自動化中信號觸發(fā)事件環(huán)節(jié)的串連。

　　另外 “ OS：：Mistral：：ExternalResource ” 可以允許使用 Mistral 的工作流程來分別定義資源的每個獨立動作（例如創(chuàng)建，更新，刪除等）。針對應用程序擁有非屬于 OpenStack 的資源嘗試使用 OpenStack 架構(gòu)作為調(diào)度平臺時，此資源可以大幅協(xié)助相關流程簡化與編排托管。當然即使沒有 Mistral 你一樣可以通過新增 Python 源碼或是注冊新資源的方式將定制化的資源放入 Heat 腳本內(nèi)。因此你可以根據(jù)應用程序需求來選擇方式。

　　從峰會的議程來看不只是筆者所接觸到的這幾個議程，其他跟應用程序與應用程序編排相關的議程，在整體 OpenStack 議程來說不在少數(shù)。許多網(wǎng)絡調(diào)度程序或是容器服務需求等應用實際案例分享也不再少數(shù)。 OpenStack 對于協(xié)助應用程序的力量與開發(fā)需求看來不在少數(shù)。服務的重點是貼近使用者需求，在峰會的第一天開始，就已經(jīng)可見到社區(qū)的確是朝著這方向邁進。

　　至于使用者們是否也對于架構(gòu)應用程序充滿期待與信心呢？以下筆者給各位一個參考。

　　在議程 “ Future science on Future OpenStack ” 上要讓大家知道 SKA 組織已經(jīng)決定要跟 CERN 合作，計劃創(chuàng)建世界最大的科學研究的云環(huán)境。

　　這堆龐大的應用程序當然是即將要建立在 OpenStack 之上。后來跟幾位講者私聊，他們相信在計劃開始時，OpenStack 作為底層平臺，對于應用程序的的支持度一定能達到極高可用性與可靠性。

　　這次峰會，OpenStack 對于應用程序的目標，更加專精。比起早期發(fā)散且眾多的開發(fā)項目，現(xiàn)狀的穩(wěn)定，更容易讓開發(fā)者們互相合作。其他社區(qū)的崛起，反而讓 OpenStack 社區(qū)看到更多機會，的確能帶著應用程序邁向成功之路。