OpenStack Heat 如何來實現和支援編排
OpenStack Heat 介紹
Heat 是一個基於模板來編排複合雲應用的服務。 它目前支援亞馬遜的 CloudFormation 模板格式，也支援 Heat 自有的 Hot 模板格式。模板的使用簡化了複雜基礎設施，服務和應用的定義和部署。模板支援豐富的資源型別，不僅覆蓋了常用的基礎架構，包括計算、網路、儲存、映象，還覆蓋了像 Ceilometer 的警報、Sahara 的叢集、Trove 的例項等高階資源。
圖 1. Heat 和其它模組的關係
Heat Architecture
Heat 服務包含以下重要的元件：
- Heat-api 元件實現 OpenStack 天然支援的 REST API。該元件通過把 API 請求經由 AMQP 傳送給 Heat engine 來處理 API 請求。
- Heat-api-cfn 元件提供相容 AWS CloudFormation 的 API，同時也會把 API 請求通過 AMQP 轉發給 heat engine。
- Heat-engine 元件提供 Heat 最主要的協作功能。
使用者在 Horizon 中或者命令列中提交包含模板和引數輸入的請求，Horizon 或者命令列工具會把請求轉化為 REST 格式的 API 呼叫，然後呼叫 Heat-api 或者是 Heat-api-cfn。Heat-api 和 Heat-api-cfn 會驗證模板的正確性，然後通過 AMQP 非同步傳遞給 Heat Engine 來處理請求。
圖 2. Heat 架構
當 Heat Engine 拿到請求後，會把請求解析為各種型別的資源，每種資源都對應 OpenStack 其它的服務客戶端，然後通過傳送 REST 的請求給其它服務。通過如此的解析和協作，最終完成請求的處理。
Heat Engine 在這裡的作用分為三層： 第一層處理 Heat 層面的請求，就是根據模板和輸入引數來建立 Stack，這裡的 Stack 是由各種資源組合而成。 第二層解析 Stack 裡各種資源的依賴關係，Stack 和巢狀 Stack 的關係。第三層就是根據解析出來的關係，依次呼叫各種服務客戶段來建立各種資源。
圖 3. Heat Engine 結構
編排
編排，顧名思義，就是按照一定的目的依次排列。在 IT 的世界裡頭，一個完整的編排一般包括設定伺服器上機器、安裝 CPU、記憶體、硬碟、通電、插入網路介面、安裝作業系統、配置作業系統、安裝中介軟體、配置中介軟體、安裝應用程式、配置應用釋出程式。對於複雜的需要部署在多臺伺服器上的應用，需要重複這個過程，而且需要協調各個應用模組的配置，比如配置前面的應用伺服器連上後面的資料庫伺服器。下圖顯示了一個典型應用需要編排的專案。
圖 4. 編排
在雲端計算的世界裡，機器這層就變為了虛擬的 VM 或者是容器。管理 VM 所需要的各個資源要素和作業系統本身就成了 IaaS 這層編排的重點。作業系統本身安裝完後的配置也是 IaaS 編排所覆蓋的範圍。除此之外，提供能夠接入 PaaS 和 SaaS 編排的框架也是 IaaS 編排的範圍。
Heat 編排
OpenStack 從最開始就提供了命令列和 Horizon 來供使用者管理資源。然而靠敲一行行的命令和在瀏覽器中的點選相當費時費力。即使把命令列儲存為指令碼，在輸入輸出，相互依賴之間要寫額外的指令碼來進行維護，而且不易於擴充套件。使用者或者直接通過 REST API 編寫程式，這裡會引入額外的複雜性，同樣不易於維護和擴充套件。 這都不利於使用者使用 Openstack 來進行大批量的管理，更不利於使用 OpenStack 來編排各種資源以支撐 IT 應用。
Heat 在這種情況下應運而生。Heat 採用了業界流行使用的模板方式來設計或者定義編排。使用者只需要開啟文字編輯器，編寫一段基於 Key-Value 的模板，就能夠方便地得到想要的編排。為了方便使用者的使用，Heat 提供了大量的模板例子，大多數時候使用者只需要選擇想要的編排，通過拷貝-貼上的方式來完成模板的編寫。
Heat 從四個方面來支援編排。首先是 OpenStack 自己提供的基礎架構資源，包括計算，網路和儲存等資源。通過編排這些資源，使用者就可以得到最基本的 VM。值得提及的是，在編排 VM 的過程中，使用者可以提供一些簡單的指令碼，以便對 VM 做一些簡單的配置。然後使用者可以通過 Heat 提供的 Software Configuration 和 Software Deployment 等對 VM 進行復雜的配置，比如安裝軟體、配置軟體。接著如果使用者有一些高階的功能需求，比如需要一組能夠根據負荷自動伸縮的 VM 組，或者需要一組負載均衡的 VM，Heat 提供了 AutoScaling 和 Load Balance 等進行支援。如果要使用者自己單獨程式設計來完成這些功能，所花費的時間和編寫的程式碼都是不菲的。現在通過 Heat，只需要一段長度的 Template，就可以實現這些複雜的應用。Heat 對諸如 AutoScaling 和 Load Blance 等複雜應用的支援已經非常成熟，有各種各樣的模板供參考。最後如果使用者的應用足夠複雜，或者說使用者的應用已經有了一些基於流行配置管理工具的部署，比如說已經基於 Chef 有了 Cookbook，那麼可以通過整合 Chef 來複用這些 Cookbook，這樣就能夠節省大量的開發時間或者是遷移時間。本文稍後會分別對這四個方面做一些介紹。
圖 5. Heat 編排
Heat 模板
Heat 目前支援兩種格式的模板，一種是基於 JSON 格式的 CFN 模板；另外一種是基於 YAML 格式的 HOT 模板。CFN 模板主要是為了保持對 AWS 的相容性。HOT 模板是 Heat 自有的，資源型別更加豐富，更能體現出 Heat 特點的模板。
一個典型的 HOT 模板由下列元素構成：
- 模板版本：必填欄位，指定所對應的模板版本，Heat 會根據版本進行檢驗。
- 引數列表：選填，指輸入引數列表。
- 資源列表：必填，指生成的 Stack 所包含的各種資源。可以定義資源間的依賴關係，比如說生成 Port，然後再用 port 來生成 VM。
- 輸出列表：選填，指生成的 Stack 暴露出來的資訊，可以用來給使用者使用，也可以用來作為輸入提供給其它的 Stack。
對於 CFN 模板和 HOT 模板的不同，包括所支援的資源型別的不同，不在本文的討論範圍內。本文會主要用 HOT 模板。HOT 模板的全稱是 Heat Orchestration Template，是 Heat 發展的重心。
Heat 對基礎架構的編排
對於不同的資源，Heat 都提供了對應的資源型別。比如對於 VM，Heat 提供了 OS::Nova::Server。OS::Nova::Server 有一些引數，比如 key、image、flavor 等，這些引數可以直接指定，可以由客戶在建立 Stack 時提供，也可以由上下文其它的引數獲得。
清單 1. 建立一個 VM
resources:
server:
type: OS::Nova::Server
properties:
key_name: { get_param: key_name }
image: { get_param: image }
flavor: { get_param: flavor }
user_data: |
#!/bin/bash
echo “10.10.10.10 testvm” >> /etc/hosts在上面建立 VM 的例子中，我們選擇從輸入引數獲得 OS::Nova::Server 所需的值。其中利用 user_data 做了一些簡單的配置。
Heat 對軟體配置和部署的編排
Heat 提供了多種資源型別來支援對於軟體配置和部署的編排，如下所列：
- OS::Heat::CloudConfig： VM 載入程式啟動時的配置，由 OS::Nova::Server 引用
- OS::Heat::SoftwareConfig：描述軟體配置
- OS::Heat::SoftwareDeployment：執行軟體部署
- OS::Heat::SoftwareDeploymentGroup：對一組 VM 執行軟體部署
- OS::Heat::SoftwareComponent：針對軟體的不同生命週期部分，對應描述軟體配置
- OS::Heat::StructuredConfig：和 OS::Heat::SoftwareConfig 類似，但是用 Map 來表述配置
- OS::Heat::StructuredDeployment：執行 OS::Heat::StructuredConfig 對應的配置
- OS::Heat::StructuredDeploymentsGroup：對一組 VM 執行 OS::Heat::StructuredConfig 對應的配置
其中最常用的是 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment。
OS::Heat::SoftwareConfig
下面是 OS::Heat::SoftwareConfig 的用法，它指定了配置細節。
清單 2. 最常見的 OS::Heat::SoftwareConfig 用法
resources:
install_db_sofwareconfig
type: OS::Heat::SoftwareConfig
properties:
group: script
outputs:
- name: result
config: |
#!/bin/bash -v
yum -y install mariadb mariadb-server httpd wordpress
touch /var/log/mariadb/mariadb.log
chown mysql.mysql /var/log/mariadb/mariadb.log
systemctl start mariadb.serviceOS::Heat::SoftwareDeployment
下面是 OS::Heat::SoftwareDeployment 的用法，它指定了在哪臺伺服器上做哪項配置。另外 SofwareDeployment 也指定了以何種訊號傳輸型別來和 Heat 進行通訊。
清單 3. OS::Heat::SoftwareDeployment 樣例
sw_deployment:
type: OS::Heat::SoftwareDeployment
properties:
config: { get_resource: install_db_sofwareconfig }
server: { get_resource: server }
signal_transport: HEAT_SIGNAL
OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 流程
OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 協同工作，需要一系列 Heat 工具的自持。這些工具都是 OpenStack 的子專案。
首先，os-collect-config 呼叫 Heat API 拿到對應 VM 的 metadata。
當 metadata 更新完畢後，os-refresh-config 開始工作了，它主要是執行下面目錄所包含的指令碼：
- /opt/stack/os-config-refresh/pre-configure.d
- /opt/stack/os-config-refresh/configure.d
- /opt/stack/os-config-refresh/post-configure.d
- /opt/stack/os-config-refresh/migration.d
- /opt/stack/os-config-refresh/error.d
每個資料夾都應對了軟體不同的階段，比如預先配置階段、配置階段、後配置階段和遷移階段。如果任一階段的指令碼執行出現問題，它會執行 error.d 目錄裡的錯誤處理指令碼。os-refresh-config 在配置階段會呼叫一定預先定義的工具，比如 heat-config，這樣就觸發了 heat-config 的應用，呼叫完 heat-config 後，又會呼叫 os-apply-config。存在在 heat-config 或者 os-apply-config 裡的都是一些指令碼，也叫鉤子。Heat 對於各種不同的工具提供了不同的鉤子指令碼。使用者也可以自己定義這樣的指令碼。
等一切呼叫完成無誤後，heat-config-notify 會被呼叫，它用來發訊號給 Heat，告訴這個軟體部署的工作已經完成。
當 Heat 收到 heat-config-notify 發來的訊號後，它會把 OS::Heat::SoftwareConfig 對應資源的狀態改為 Complete。如果有任何錯誤發生，就會改為 CREATE_FAILED 狀態。
圖 6. OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 流程圖
Heat 對資源自動伸縮的編排
基礎架構的自動伸縮是一個很高階的功能。Heat 提供自動伸縮組 OS::Heat::AutoScalingGroup 和伸縮策略 OS::Heat::ScalingPolicy，結合基於 Ceilometer 的 OS::Ceilometer::Alarm 實現了可以根據各種條件，比如負載，進行資源自動伸縮的功能。
圖 7. Heat 自動伸縮的流程圖
清單 4. 定義自動伸縮組
auto_scale_group:
type: OS::Heat::AutoScalingGroup
properties:
min_size: 1
max_size: 4清單 5. 定義伸縮規則
server_scaleup_policy:
type: OS::Heat::ScalingPolicy
properties:
adjustment_type: change_in_capacity
auto_scaling_group_id: {get_resource: auto_scale_group}
cooldown: 60
scaling_adjustment: 1
清單 6. 定義警報
cpu_alarm_high:
type: OS::Ceilometer::Alarm
properties:
description: Scale-up if the average CPU > 50% for 1 minute
meter_name: cpu_util
statistic: avg
period: 60
evaluation_periods: 1
threshold: 50
alarm_actions:
- {get_attr: [server_scaleup_policy，alarm_url]}
matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}
comparison_operator: gt
Heat 對負載均衡的編排
負載均衡也是一個很高階應用，它也是由一組不同的資源型別來實現的。資源型別包括：
- OS::Neutron::Pool：定義資源池，一般可以由 VM 組成
- OS::Neutron::PoolMember：定義資源池的成員
- OS::Neutron::HealthMonitor：定義健康監視器，根據自定的協議，比如 TCP 來監控資源的狀態，並提供給 OS::Neutron::Pool 來調整請求分發
- OS::Neutron::LoadBalancer：關聯資源池以定義整個負載均衡。
圖 8. Heat 負載均衡
清單 7. Monitor 的定義
monitor:
type: OS::Neutron::HealthMonitor
properties:
type: TCP
delay: 3
max_retries: 5
timeout: 3清單 8. Pool 成員的定義
member:
type: OS::Neutron::PoolMember
properties:
pool_id: {get_resource: pool}
address: {get_attr: [my_server，first_address]}
protocol_port: 80
other_member:
type: OS::Neutron::PoolMember
properties:
pool_id: {get_resource: pool}
address: {get_attr: [my_other_server，first_address]}
protocol_port: 80清單 9. Pool 的定義
pool:
type: OS::Neutron::Pool
properties:
protocol: HTTP
monitors: [{get_resource: monitor}]
subnet_id: {get_param: network_subnet_lb_pool}
lb_method: ROUND_ROBIN
vip:
protocol_port: 80清單 10. LoadBalancer 的定義
lb:
type: OS::Neutron::LoadBalancer
properties:
protocol_port: 80
pool_id: {get_resource: pool}Heat 和配置管理工具整合
隨著 DevOps 的流行，大量配置管理的工具應運而生，比如 Chef、Puppet 和 Ansible。各種工具除了提供一個平臺框架外，更是針對大量的中介軟體和軟體部署提供了可以靈活配置和引用的指令碼。以 Chef 為例，它提供了大量針對開源軟體的 cookbook。各大廠商也給自己的中介軟體編寫了 cookbook，比如說 IBM 給 DB2 提供了 cookbook。有了這些 cookbook，使用者就可以通過簡單的配置和應用來部署複雜的中介軟體或者軟體應用。
Heat 在基於 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 的協同使用上，提供了對這些配置管理工具的支援。
首先，對於 OS::Heat::SoftwareConfig 而言，需要其 group 定義為對應的型別。比如有 ansible、puppet、docker-compose 和 salt 等。
清單 11. group: ansible 的 OS::Heat::SoftwareConfig
config:
type: OS::Heat::SoftwareConfig
properties:
group: ansible
inputs:
- name: foo
- name: bar
outputs:
- name: result
config:
get_file: config-scripts/example-ansible-template.ansible然後再 OS::Heat::SoftwareDeployment 引用 OS::Heat::SoftwareConfig。
清單 12. 引用 OS::Heat::SoftwareConfig 的 OS::Heat::SoftwareDeployment
other_deployment:
type: OS::Heat::SoftwareDeployment
properties:
config:
get_resource: config
server:
get_resource: server
input_values:
foo: fu
bar: barmy這樣在軟體部署的時候，就會呼叫對應的指令碼鉤子 heat-config-ansible 來執行對應的軟體配置。
圖 9. group:ansible 的 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 流程
Heat 和 IBM UCDP/UCD 的整合
隨著雲端計算的逐步興起，各種基於雲端計算的的部署編排工具開始出現了。從目前來看，主要有跨平臺，視覺化，強大的配置管理功能等幾個方面。其中 IBM 的 UrbanCode Deploy with Patterns（UCDP）和 UrbanCode Deploy（UCD）是一種強大的平臺，具備上述的特性。
UCDP 是全棧的環境管理和部署解決方案，支援使用者為多種雲設計、部署和更新全棧環境。該平臺可整合 UCD，基於 Heat 來實現對 OpenStack 基礎架構自動化來優化持續的交付吞吐量。它具備視覺化的操作介面。通過拖拽圖示來建立和編輯跨雲平臺的模板。
UCD 將應用、中介軟體配置以及資料庫的變更進行編排並自動部署到開發環境、測試環境和生產環境中。它能讓使用者通過自助服務方式，根據需要或按照計劃進行部署。在 UCD 中，能夠按照配置（configuration-only）或者傳統的程式碼和配置（code-and-configuration）來分拆複雜的應用配置進行逐步定義。
通過藉助於 UCDP 強大的 Pattern 設計能力，我們可以通過拖拽的方式製作一個複雜的模板。其中用到兩種型別的資源，一種是雲端計算資源，比如說網路、安全組、映象等，另外是定義於 UCD 中的元件，比如其中的 Jke.db、MySQL Server、jke.war 和 WebSphere Liberty Profile.
圖 10. UCDP 強大的 Pattern 設計能力
通過藉助 UCDP/UCP 和 Heat 的整合，可以很方便的點選按鈕來生成對應的環境(UCDP/UCD 用語)或者 Stack(Heat 用語)。
首先，UCDP 把設計好的模板發給 Heat。然後 Heat 會呼叫 UCD 擴充套件外掛來解釋模板並翻譯為 Heat 能夠認識的模板，這個過程有可能需要訪問 UCD 得到更為細節的解釋。接著 Heat 去生成相應的資源，一般肯定有 VM，並在 VM 上安裝 UCD agent，並啟動 agent。Agent 會呼叫 UCD 拿到具體元件，比如 WebSphere Liberty Profile 的部署定義細節，然後執行。最終完成 Stack 的生成。
圖 11. UCDP/UCD 和 Heat 的整合
結束語
本文介紹了 OpenStack 和 OpenStack Heat，特別是 Heat 的架構。然後介紹了什麼是編排，Heat 在編排的位置，以及 Heat 模板。接著本文逐一介紹了 Heat 是如何來實現和支援編排，分別從基礎架構，軟體配置和部署，自動資源伸縮和負載均衡等角度進行了敘述。本文最後介紹了 Heat 和配置管理工具的整合，以及 Heat 和 IBM UCDP/UCD 的整合。
隨著雲端計算的日益流行，各種雲端計算平臺大量興起。誰最終能被行業和使用者接受，一定是取決於誰能夠高效支援使用者複雜應用的編排。Heat 對編排的全方位支援將有力地支援 OpenStack 在雲端計算，特別是在 IaaS 中領導地位。對此，我們拭目以待。