云的基礎架構已經(jīng)開(kāi)始成形，如何在 OpenStack 上為各種應用程序提供更好的調度環(huán)境？
澳大利亞悉尼當地時(shí)間11月6號上午9點(diǎn)，第16屆OpenStack峰會(huì )在悉尼國際會(huì )議中心盛大開(kāi)幕，來(lái)自全球52個(gè)國家2300余名與會(huì )者，將就以OpenStack為核心的開(kāi)放基礎架構相關(guān)技術(shù)和商業(yè)實(shí)踐展開(kāi)為期三天的討論，本文為第二天的討論內容之一。
在2017年4月的 OpenStack 使用者調查中，可以看見(jiàn)，OpenStack 除了被當作是基礎設施服務(wù)外，也有許多使用于架構測試與持續集成、數據庫、網(wǎng)絡(luò )服務(wù)、大數據等。加上最近當紅的邊緣計算（Edge Computing）、物聯(lián)網(wǎng)也有不少以 OpenStack 作為開(kāi)發(fā)研究平臺的。
圖片源自 OpenStack 官方網(wǎng)站
在上次峰會(huì )，由正式增加一個(gè) OpenStack 政策開(kāi)始，告知 OpenStack 必須重視應用程序需求（https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html ），接著(zhù)在悉尼峰會(huì )，各個(gè)討論與需求在許多專(zhuān)案內開(kāi)始發(fā)酵。我們繼續在這應用程序之路上深入討論。
架構變革
為達成應用程序需求，從上次峰會(huì )就開(kāi)始進(jìn)行 Application Credentials 的設計規劃，讓?xiě)贸绦蚩梢允褂糜蒏eystone （驗證程序） 取得運行 OpenStack 服務(wù)的權限，應用程序能通過(guò)此權限操作 OpenStack 服務(wù)，但僅限于該權限允許的范疇。因此并不會(huì )破壞權限管理。
在Denver PTG 時(shí)，已經(jīng)有過(guò)技術(shù)上的細節討論（https://etherpad.openstack.org/p/queens-PTG-vmbm ），在峰會(huì )上 “ Application Credentials Feedback ” 技術(shù)議程主要報告目前所制訂的規格，并收集回饋。
此功能能讓?xiě)贸绦蚴褂貌糠?OpenStack 服務(wù)，而且不需要使用使用者信息作認證，直接將Application Credential 傳給被調用服務(wù)就可以使用該服務(wù)，能使用的服務(wù)范圍則是在A(yíng)pplication Credential 創(chuàng )建時(shí)會(huì )被設定。
針對 PTG 時(shí)討論的修改，回饋都是正面的，一般來(lái)說(shuō) Credential 不會(huì )被用來(lái)重新創(chuàng )建其他 Application Credential 。但針對像是編排專(zhuān)案需求（例如當自動(dòng)擴容時(shí)， Heat 需要有權限創(chuàng )建新擴容資源，像是目前使用 trusts 機制一樣 ）。
為什么筆者將此功能放在架構變革區塊？其實(shí)上次峰會(huì )所做的報道也有提到，讓人驚訝的，權限架構是目前社區認為最前哨的變革點(diǎn)，因為只有權限開(kāi)通，才能讓其他服務(wù)開(kāi)始計劃后續提供給應用程序的設計。
另一個(gè)變革，則屬于 “ Cloud-Native Design/Refactoring Across OpenStack （Part II） ” 技術(shù)議程所帶來(lái)的議題。
Cloud Native， 雖然詞匯一直存在，但變成變革則算是在 CNCF （ Cloud Native Computing Foundation ） 與容器化開(kāi)始興起完善容器架構，而 OpenStack 成熟后帶來(lái)的穩定的云架構。兩者合并后才開(kāi)始被重視。對于新開(kāi)發(fā)的應用程序來(lái)說(shuō)，直接讓?xiě)贸绦蚴褂迷瓶蚣芘c容器架構上的服務(wù)（例如自動(dòng)擴容，監測，紀錄，修復等）。
議程中檢視 OpenStack 現有設計，討論如何讓 OpenStack 架構更具有云架構的優(yōu)勢。無(wú)疑對于應用程序來(lái)說(shuō)，后續可行的設計并不會(huì )破壞現有程序的使用（ OpenStack 跨版本的相容性向來(lái)是一大優(yōu)勢）。
因此第一刀就落在狀態(tài)監控，整個(gè)技術(shù)議程討論的重點(diǎn)在于如何建立符合云架構的狀態(tài)收集（https://etherpad.openstack.org/p/sydney-cloud-native-partii） 。
設計重點(diǎn)在于提供所有專(zhuān)案一個(gè)可以將本身資源狀態(tài)上傳的一個(gè)平臺。通過(guò)計劃在 OSLO.Middleware 內建立狀態(tài)回報工具。讓所有專(zhuān)案可以通過(guò)該工具將所有想丟到狀態(tài)列表的資源送到統一的地點(diǎn)。
后續再由各個(gè)服務(wù)自行選擇要如何判別這些狀態(tài)。會(huì )有這樣的設計是為了提供一個(gè)可以縱觀(guān)整體 OpenStack 狀態(tài)的平臺，讓資源狀態(tài)不在零散，也不再需要各別服務(wù)獨立開(kāi)發(fā)資源狀態(tài)監控的。相較效率與統一性會(huì )高很多。而這也就是此環(huán)節為第一刀的重點(diǎn)。目前還未有相關(guān)實(shí)踐，但是后續一定看好此功能。此為實(shí)際針對資源監控大方向大問(wèn)題進(jìn)行改善的好的開(kāi)發(fā)方針。
編排：應用程序的自動(dòng)化之路
自動(dòng)化是許多使用者的需求，需要一下環(huán)節互動(dòng)而成：生成資源-》監控資源-》信號觸發(fā)事件-》修復-》持續監控。只要能滿(mǎn)足上面的環(huán)。就能達成自動(dòng)化。最大的問(wèn)題是各個(gè)環(huán)節應該用那些服務(wù)，服務(wù)間有無(wú)好的串連方式以達成最高效的自動(dòng)化系統。
自動(dòng)擴容 （ Auto-Scaling ） 在 OpenStack 環(huán)境并非新技術(shù)，操作成熟度也相當高。因此在峰會(huì )以使用者分享居多。而自動(dòng)修復在峰會(huì )上是這次的一個(gè)小焦點(diǎn)之一，在技術(shù)議程 “ Self-healing and optimization SIG ” 里，第一次在峰會(huì )集合相關(guān)技術(shù)專(zhuān)家討論目前的修復功能與如何優(yōu)化。
目前在社群上 Heat 就有為自動(dòng)修復做過(guò)深入調研，也提供方式供使用者參考
（https://github.com/openstack/heat-templates/tree/master/hot/autohealing）。
當然我們更希望我們能提供給使用者的自動(dòng)化是更全方面的，因此這個(gè) SIG 小組的任務(wù)才剛開(kāi)始，相當多的人參加，也有很多自愿者愿意一起推動(dòng)。
目前已經(jīng)決議成立此小組。后續也會(huì )有專(zhuān)有的IRC 頻道與會(huì )議，更重要的是，通過(guò)小組旗幟，號昭與收集更多使用者需求（https://etherpad.openstack.org/p/self-healing-rocky -forum）。
自動(dòng)化流程也具有其他的標準協(xié)議像是IFTTT。值得一提，在實(shí)踐修復環(huán)節時(shí)，建議可以考慮 Mistral 服務(wù)，套用 OpenStack 在自動(dòng)化流程時(shí) Mistral 提供 流程管理服務(wù)，讓運行時(shí)可以按照實(shí)際狀況流程行動(dòng)。
考慮使用 Heat 作為資源管理，而 Mistral 作為管理時(shí)的運營(yíng)時(shí)的流程管理，在許多實(shí)際使用案例來(lái)看是一個(gè)不錯的架構。在議程 “Mistral - Project Update”內，Mistral PTL 介紹 Mistral 的現況與未來(lái)開(kāi)發(fā)。
在上面的自動(dòng)化流程與應用程序管理中，編排是簡(jiǎn)化使用者端操作復雜度的方式。往往應用程序都是數個(gè)服務(wù)所組成，在多數實(shí)際運營(yíng)環(huán)境中，應用程序可能必須調度在上百臺節點(diǎn)上。因此更需要統一管理的機制，增加管理強度，加快調度流程，減少失誤。在峰會(huì )上筆者有幸負責編排專(zhuān)案的幾個(gè)社區技術(shù)議程。
峰會(huì )第一天早上，即有編排專(zhuān)案的 Onboarding 技術(shù)議程。提供專(zhuān)案介紹、框架、腳本解說(shuō)、調試方法與貢獻方式。讓開(kāi)發(fā)者與操作者能夠更緊密與社區接軌。為了協(xié)助應用程序接軌，內容使用自動(dòng)修復與擴容腳本，與軟件設定編排（ Software Config ）腳本作為解說(shuō)方向。讓撰寫(xiě)腳本的操作者能更快速為應用程序制定 Cloud Native 環(huán)境。
在專(zhuān)案更新部分介紹幾個(gè)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）。其他提及功能包含，專(zhuān)案本身已支持python3，支持編排根據實(shí)況更新，新增 Heat-Agents 子專(zhuān)案，更完善的分布式服務(wù)。
其中可以觀(guān)察到 Zaqar 資源的更新為了完善應用程序管理自動(dòng)化中信號觸發(fā)事件環(huán)節的串連。
另外 “ OS：：Mistral：：ExternalResource ” 可以允許使用 Mistral 的工作流程來(lái)分別定義資源的每個(gè)獨立動(dòng)作（例如創(chuàng )建，更新，刪除等）。針對應用程序擁有非屬于 OpenStack 的資源嘗試使用 OpenStack 架構作為調度平臺時(shí)，此資源可以大幅協(xié)助相關(guān)流程簡(jiǎn)化與編排托管。當然即使沒(méi)有 Mistral 你一樣可以通過(guò)新增 Python 源碼或是注冊新資源的方式將定制化的資源放入 Heat 腳本內。因此你可以根據應用程序需求來(lái)選擇方式。
從峰會(huì )的議程來(lái)看不只是筆者所接觸到的這幾個(gè)議程，其他跟應用程序與應用程序編排相關(guān)的議程，在整體 OpenStack 議程來(lái)說(shuō)不在少數。許多網(wǎng)絡(luò )調度程序或是容器服務(wù)需求等應用實(shí)際案例分享也不再少數。 OpenStack 對于協(xié)助應用程序的力量與開(kāi)發(fā)需求看來(lái)不在少數。服務(wù)的重點(diǎn)是貼近使用者需求，在峰會(huì )的第一天開(kāi)始，就已經(jīng)可見(jiàn)到社區的確是朝著(zhù)這方向邁進(jìn)。
至于使用者們是否也對于架構應用程序充滿(mǎn)期待與信心呢？以下筆者給各位一個(gè)參考。
在議程 “ Future science on Future OpenStack ” 上要讓大家知道 SKA 組織已經(jīng)決定要跟 CERN 合作，計劃創(chuàng )建世界最大的科學(xué)研究的云環(huán)境。
這堆龐大的應用程序當然是即將要建立在 OpenStack 之上。后來(lái)跟幾位講者私聊，他們相信在計劃開(kāi)始時(shí)，OpenStack 作為底層平臺，對于應用程序的的支持度一定能達到極高可用性與可靠性。
這次峰會(huì )，OpenStack 對于應用程序的目標，更加專(zhuān)精。比起早期發(fā)散且眾多的開(kāi)發(fā)項目，現狀的穩定，更容易讓開(kāi)發(fā)者們互相合作。其他社區的崛起，反而讓 OpenStack 社區看到更多機會(huì )，的確能帶著(zhù)應用程序邁向成功之路。
