OpenStack Heat 编排：用模板一键交付云业务，告别手动点页面

摘要：手动在 Horizon 界面一台台创建虚拟机、配置网络、挂载磁盘，重复劳动多还容易出错。Heat 作为 OpenStack 原生编排服务，通过 HOT 模板以声明式代码定义整套云资源，实现基础设施即代码 (IaC)。本文结合 Yoga 版本实操，讲解 Heat 定位、架构、HOT 模板语法、命令行实验与常见场景，带你理解 OpenStack 自动化编排。

一、为什么需要 Heat 编排服务？

日常使用 OpenStack，如果部署一套业务环境：需要创建虚拟机、配置网络子网、路由器、浮动 IP、安全组、挂载云硬盘。如果通过 Dashboard 界面一步步点击，部署多套相同业务环境时，需要重复操作，极易出现配置不一致，排错麻烦。

Heat 就是 OpenStack 的编排服务，核心思想：基础设施即代码。把所有云资源（计算、网络、存储、软件配置）写进 YAML 模板文件，执行模板即可批量、顺序创建整套资源；模板可以纳入版本控制，重复部署、修改、销毁整套环境。

Heat 最早出现在 Havana 版本，提供两套 API：

Heat API：OpenStack 原生 REST API
Heat‑cfn API：兼容 AWS CloudFormation 的 API，方便迁移 AWS 模板到 OpenStack

Heat不直接操作硬件资源，它只负责解析模板、处理资源依赖，然后调用 Nova、Neutron、Cinder、Glance 等组件 API 完成资源创建。

补充：OpenStack 生态还有 Mistral、Aodh 等编排相关组件，Heat 是专门面向基础设施资源编排的核心组件。

✅重点：Heat 本身不创建任何底层资源，是 "调度翻译层"，真正干活的是 Nova/Neutron/Cinder。 ⚠️易错：不要误以为 Heat 可以替代计算、网络服务；Heat 只是调用其他组件 API。

二、Heat 整体架构详解

Heat 采用分布式架构，主要包含三个核心服务组件：heat‑api、heat‑cfn‑api、heat‑engine，不存在 heat‑server 组件。

表格

组件	功能说明
heat‑api	OpenStack 原生 API 服务，接收 CLI/Horizon 发来 REST 请求，转发给 heat‑engine
heat‑cfn‑api	兼容 AWS CloudFormation 的 API 接口，适配 CFN 格式模板
heat‑engine	Heat 核心引擎，解析模板、处理资源依赖、调用各个 OpenStack 客户端，管理 Stack 生命周期

整体工作流程：

用户通过 Horizon 界面或者openstack命令行提交 HOT 模板；
heat‑api接收请求，通过消息队列 RabbitMQ 将任务下发给heat‑engine；
heat‑engine 解析模板，识别资源之间依赖关系（比如先创建网络，再创建虚拟机）；
调用 Nova、Neutron、Cinder 的 client，向对应服务发送 API 请求创建资源；
数据库记录 Stack、资源状态，返回执行结果给用户。

交互关系：Heat 依赖 Keystone 做身份认证；向上被 Horizon 调用，向下调用 Nova、Neutron、Cinder、Glance、Swift 等服务完成资源编排。

✅重点：heat‑engine是整个 Heat 的核心，所有模板解析、依赖处理、资源调度全部由它完成。 ⚠️易错 1（面试高频坑） ：Heat 没有heat‑server服务组件，选择题看到 heat‑server 直接排除。 ⚠️易错 2 ：heat‑api 只是网关，不做业务逻辑处理 ，业务逻辑全部交给 heat‑engine。 ⚠️易错 3 ：heat‑cfn‑api 只是兼容 AWS CloudFormation，不是 OpenStack 原生 HOT 模板必须使用的接口。

三、核心概念：HOT 模板与 Stack

3.1 HOT 模板是什么

HOT（Heat Orchestration Template） ，Heat 原生模板格式，文件格式为 YAML。YAML 依靠空格缩进区分层级，短横线代表列表，冒号代表键值对，对缩进非常敏感，缩进错误会直接导致模板执行失败。

HOT 模板完整结构（必选 + 可选字段）

复制代码

heat_template_version: 2016-10-14  #【必选】声明模板版本，决定支持的语法特性
description: 模板描述信息            #【可选】说明模板用途
parameters:                         #【可选】外部输入参数，部署时传入，实现模板复用
resources:                          #【必选】定义所有要创建的云资源，至少一个资源
outputs:                            #【可选】输出参数，部署完成后返回IP、地址等信息
conditions:                         #【可选】条件判断，根据参数决定是否创建某资源

✅重点：heat_template_version、resources是强制必写字段 ，缺少直接报错；其余字段全部可选。 ⚠️易错 1 ：YAML严禁使用 Tab 制表符缩进，只能用空格，绝大多数模板语法报错都是 Tab 导致。 ⚠️易错 2 ：冒号:后面必须加空格，例如 key: value，写成key:value直接解析失败。 ⚠️易错 3 ：版本号heat_template_version必须写 Heat 支持的合法日期，随便写数字会模板解析失败。

resources 资源段核心关键字：

复制代码

resources:
  vm1:                    #资源ID，自定义名称
    type: OS::Nova::Server #资源类型，代表Nova虚拟机
    properties:           #资源属性，镜像、规格、密钥对
      image: cirros
      flavor: m1.tiny
      key_name: mykey
    depends_on: ["net1"]  #显式声明依赖，先创建net1网络，再创建虚拟机

type：资源类型，OS::Nova::Server代表虚拟机；OS::Neutron::Net代表网络；可以命令行查询所有支持资源类型。

查询支持的资源类型命令：

复制代码

#列出全部资源类型
openstack orchestration resource type list
#查看某个资源的详细参数
openstack orchestration resource type show OS::Nova::Server

✅重点：depends_on用于显式强制资源依赖 ；Heat 也可以自动推导部分依赖关系，复杂模板建议手动写 depends_on。 ⚠️易错：depends_on的值是数组列表 ，多个依赖要用[]包裹，单依赖也建议数组格式。

Hello World 极简模板（创建一台虚拟机）

复制代码

heat_template_version: 2015-04-30
description: 简单模板，部署一台cirros测试虚拟机
resources:
  my_vm:
    type: OS::Nova::Server
    properties:
      key_name: my_key
      image: cirros-0.5.2
      flavor: m1.small

3.2 Stack 堆栈

Stack 是 Heat 管理资源的最小单元。一个 Stack 对应一套 HOT 模板，包含模板定义的全部资源。用户对编排的操作本质就是对 Stack 生命周期管理：创建、查看、更新、删除。

支持嵌套 Stack：模板内部可以引用其他子模板，实现复杂环境拆分，大型业务常用嵌套模板拆分网络层、计算层、存储层。

✅重点：嵌套 Stack 可以实现模板模块化，大环境拆成多个小 yaml，便于维护。 ⚠️易错：删除 Stack 的时候，默认会把该 Stack 创建的所有资源全部删除 ，谨慎执行stack delete。

Stack 常用 CLI 命令：

复制代码

#查看堆栈列表
openstack stack list
#创建堆栈，指定模板，传入参数
openstack stack create --parameter image=cirros --template vm.yaml my_stack
#查看堆栈详情
openstack stack show my_stack
#查看堆栈内部资源
openstack stack resource list my_stack
#查看堆栈执行事件，排错看事件【重点排错命令】
openstack stack event list my_stack
#删除整套堆栈（销毁模板创建全部资源）
openstack stack delete my_stack

✅重点排错命令 ：openstack stack event list 堆栈名，排查创建失败第一优先执行。 ⚠️易错：堆栈状态CREATE_IN_PROGRESS正在创建；CREATE_COMPLETE成功；CREATE_FAILED创建失败，不要只看 list 的状态，一定要看 event 事件。

四、Heat 典型编排场景

Heat 不仅仅可以创建基础虚拟机，覆盖从基础设施、软件部署、高级运维、第三方工具集成多个场景。

场景 1：基础 IaaS 资源编排（最常用）

一次性编排网络、子网、路由器、虚拟机、云硬盘、浮动 IP、安全组。不再手动依次创建网络再创建虚机，HOT 模板描述资源依赖关系，Heat 自动按正确顺序完成创建。

✅重点：可以一次性编排完整业务环境，网络、存储、计算一站式定义。

场景 2：虚拟机内部软件配置部署

仅仅创建虚拟机镜像，系统里面没有业务软件。Heat 提供OS::Heat::SoftwareConfig、OS::Heat::SoftwareDeployment资源。

SoftwareConfig：定义脚本、软件配置内容
SoftwareDeployment：把配置下发到虚拟机内部执行

虚拟机内部依赖os‑collect‑config代理接收 Heat 下发脚本，自动执行，实现虚拟机创建完自动安装 Nginx、修改配置文件，实现 "创建即业务就绪"。

✅重点：虚拟机内部必须安装os‑collect‑config代理，否则脚本无法执行。 ⚠️易错：很多同学写了 SoftwareConfig 但是虚拟机没有安装代理，脚本永远不会运行，不会直接报堆栈失败，但是业务脚本不生效。

场景 3：高级运维：自动伸缩与负载均衡

自动伸缩 AutoScaling OS::Heat::AutoScalingGroup伸缩组 + OS::Heat::ScalingPolicy伸缩策略，结合 Ceilometer 监控告警。当 CPU 负载高自动新增虚拟机；负载下降自动销毁虚拟机，实现弹性伸缩。
负载均衡 调用 Neutron LBaaS 资源OS::Neutron::LoadBalancer，自动创建负载均衡池、监控，把伸缩组的虚拟机加入后端池。

⚠️易错：自动伸缩依赖 Ceilometer 监控服务，如果 Ceilometer 异常，伸缩告警不会触发。

场景 4：对接第三方配置管理工具

Heat 原生支持集成 Ansible、Puppet、Chef。在SoftwareConfig指定group:ansible，直接执行 ansible‑playbook，复用企业已有的 Ansible 脚本，不用重新写 shell 脚本。

✅重点：group 参数指定执行器，group: ansible代表使用 ansible 执行配置。

五、实操实验：命令行完成 Heat 模板部署

实验环境：Packstack 部署 OpenStack Yoga 版本，控制节点 192.168.108.10，实验参考官方实验手册编排章节。

实验前置条件

OpenStack 环境正常，heat 相关服务状态为 up；
导入 admin 环境变量：

source keystonerc_admin
已有 cirros 镜像、密钥对 my_key。

✅重点：执行 heat 命令必须先 source 环境变量文件 ，否则认证失败。 ⚠️易错：忘记 source keystonerc_admin，报认证鉴权错误，很多初学者踩坑。

步骤 1：编写简单 hot 模板 `demo_vm.yaml`

复制代码

heat_template_version: 2015-04-30
description: Heat实验：创建测试虚拟机
parameters:
  vm_image:
    type: string
    description: 虚拟机镜像名称
    default: cirros-0.5.2
resources:
  testvm:
    type: OS::Nova::Server
    properties:
      image: { get_param: vm_image }
      flavor: m1.tiny
      key_name: my_key
outputs:
  vm_uuid:
    value: {get_attr: [testvm, uuid]}
    description: 输出虚拟机UUID

✅重点：get_param读取 parameters 输入参数；get_attr获取已经创建资源的属性。 ⚠️易错：get_attr语法 [资源ID, 属性名]，中括号顺序不能颠倒。

步骤 2：创建堆栈

复制代码

openstack stack create -t demo_vm.yaml --parameter "vm_image=cirros-0.5.2" demo_stack

✅重点：‑t指定模板文件；‑‑parameter传入参数，覆盖模板内部 default 值。

步骤 3：查看堆栈状态

复制代码

openstack stack list
openstack stack show demo_stack
openstack stack resource list demo_stack

观察状态，如果是CREATE_COMPLETE代表部署成功；如果失败，用openstack stack event list demo_stack查看报错。

步骤 4：销毁整套资源

复制代码

openstack stack delete demo_stack

执行 delete 会自动删除模板创建所有资源，不会手动一个个删虚拟机、网络。

拓展：嵌套模板实验

把网络、计算拆分成两个 yaml 子模板，主模板调用子模板，适合大型复杂环境。 ⚠️易错：嵌套模板子模板路径必须正确，找不到子模板直接堆栈失败。

六、常见排错思路

堆栈状态 CREATE_FAILED 优先执行openstack stack event list <堆栈名>，看报错事件。 ✅重点：排错第一步永远看 event 事件，不要反复重新创建堆栈。 ⚠️易错：常见原因：镜像名称写错、flavor 不存在、密钥对不存在、网络资源名称错误、YAML 缩进错误。
模板 YAML 语法报错 HOT 模板对空格缩进严格，不能用 Tab，必须使用空格 ；列表‑冒号后面必须带空格。 ✅小技巧：写模板可以用 yaml 校验工具，提前校验语法。
资源依赖顺序错误 资源创建顺序不对，可以手动增加depends_on字段显式指定依赖关系。 ⚠️易错：仅靠自动推导依赖在复杂模板会失效，建议关键资源手动写 depends_on。
查看 heat 服务日志，日志路径/var/log/heat/，包含heat‑api.log、heat‑engine.log。 ✅重点：event 看不到详细错误时，去看 heat‑engine.log。

七、Heat 的现实思考与总结

Heat 核心价值：基础设施即代码 IaC。把云环境变成 YAML 代码，可复用、可版本管理，避免人工界面操作带来不一致问题。
组件分工：heat‑api 接收请求，heat‑engine 是核心调度引擎，没有 heat‑server 组件（高频考点）。
HOT 模板：YAML 格式，heat_template_version必选，resources 是核心；parameters 实现模板参数化复用，outputs 输出部署结果。
Stack 是 Heat 的操作单元，一次 create 创建整套资源，一次 delete 全部回收资源，极大提升批量环境部署效率。
使用场景：基础资源编排、虚拟机内部脚本部署、弹性伸缩、负载均衡，支持对接 Ansible/Puppet 第三方运维工具。

小提示：生产环境中，很多企业也会使用 Terraform 对接 OpenStack；Heat 是 OpenStack 原生，不需要额外安装组件，适合 OpenStack 私有云内部自动化；Terraform 属于跨多云编排工具，两者可以对比学习。

✅重点区分：Heat=OpenStack 原生私有云编排；Terraform = 多云跨平台编排。

思考题（面试高频）

Q：下面哪一个不属于 Heat 组件？ A. heat‑api B. heat‑server C. heat‑engine D. heat‑cfn‑api 答案：B，没有 heat‑server 组件。 ⚠️易错坑：很多人会记混 heat‑server，实际不存在该服务。

OpenStack Heat 编排：用模板一键交付云业务，告别手动点页面