Castle on a Cloud

在上述的測試中, 都是在controller node上創造heat stack, 然而, 這樣的架構需要存取controller node, 並不符合public cloud的自動化處理與安全性架構, 若是我們想要從遠方創造一個heat stack, 或是更新heat stack, 我們該怎麼做呢? [root@blade02 ~(cr)]# heat stack-create second_stack -f first.yaml -P "key=test" +----------------------------+--------------+--------------------+----------------------+ | id                         | stack_name   | stack_status       | creation_time        | +----------------------------+--------------+--------------------+----------------------+ |****-44ae-93b7-de8e61e79007 | second_stack | CREATE_IN_PROGRESS | 2016-07-19T04:35:10Z | +----------------------------+--------------+--------------------+----------------------+

在上一篇文章中 ( 這裡 ), 我們跟隨官網上的範例, 寫了一個簡單的template, 然而, 我們回顧一下在nova上開啟虛擬機的程序, 包括: 指定虛擬機映象檔, 選擇虛擬機樣板 (flavor), 選擇登入金鑰 (key), 同時, 還要選擇虛擬機網路與防火牆規則, 在上一篇template中, 並不包括網路與防火牆部分, 因此, 若是直接採用上一篇的template, 會得到以下的結果: | stack_status         | CREATE_FAILED                                                    | | stack_status_reason  | Resource CREATE failed: BadRequest: Multiple possible            | |                      | networks found, use a Network ID to be more specific.            | |                      | (HTTP 400) (Request-ID: req-                                     | |                      | 545827a4-ada9-4873-8337-d7b0f4627d59)                            | 錯誤訊息是指有多於一個以上的網路選擇, 所以heat不知道要在哪一個網路下開啟虛擬機. 因此, 我們找了一下其他資源, 並實作一個可行的template,

在OpenStack的架構中, Scaling是由heat project完成的, 在heat project中, 每一個由虛擬機組成的群組稱為stack, 而stack中的創建甚至動態擴充機制, 則有賴於HOT (Heat Orchestration Template) template的設定, 我們先來看一個最簡單的template範例: heat_template_version: 2015-04-30 description: Simple template to deploy a single compute instance resources:   my_instance:     type: OS::Nova::Server     properties:       key_name: my_key       image: ubuntu-trusty-x86_64       flavor: m1.small