OpenStack Heat 如何来实现和支持编排

admin · 发表于 2017-11-6 18:28:08

OpenStack 简介

[size=1.0625]OpenStack 是一个云计算操作平台，可以大规模地协调云，管理计算资源、存储资源、网络资源等基础架构。OpenStack 是由 Rackspace Cloud 和 NASA 在 2010 年发起的。自成立以来，OpenStack 已经获得业界广泛认可，目前，它的支持者包括许多业内最大的组织。它目前的白金会员包括 IBM、Rackspace、Red Hat 和 SUSE 等。

OpenStack Heat 介绍

[size=1.0625]Heat 是一个基于模板来编排复合云应用的服务。它目前支持亚马逊的 CloudFormation 模板格式，也支持 Heat 自有的 Hot 模板格式。模板的使用简化了复杂基础设施，服务和应用的定义和部署。模板支持丰富的资源类型，不仅覆盖了常用的基础架构，包括计算、网络、存储、镜像，还覆盖了像 Ceilometer 的警报、Sahara 的集群、Trove 的实例等高级资源。

图 1. Heat 和其它模块的关系

Heat Architecture

[size=1.0625]Heat 服务包含以下重要的组件：

Heat-api 组件实现 OpenStack 天然支持的 REST API。该组件通过把 API 请求经由 AMQP 传送给 Heat engine 来处理 API 请求。
Heat-api-cfn 组件提供兼容 AWS CloudFormation 的 API，同时也会把 API 请求通过 AMQP 转发给 heat engine。
Heat-engine 组件提供 Heat 最主要的协作功能。
4 P7 @ u T* ~1 _7 E% M

[size=1.0625]用户在 Horizon 中或者命令行中提交包含模板和参数输入的请求，Horizon 或者命令行工具会把请求转化为 REST 格式的 API 调用，然后调用 Heat-api 或者是 Heat-api-cfn。Heat-api 和 Heat-api-cfn 会验证模板的正确性，然后通过 AMQP 异步传递给 Heat Engine 来处理请求。

图 2. Heat 架构

[size=1.0625]当 Heat Engine 拿到请求后，会把请求解析为各种类型的资源，每种资源都对应 OpenStack 其它的服务客户端，然后通过发送 REST 的请求给其它服务。通过如此的解析和协作，最终完成请求的处理。

[size=1.0625]Heat Engine 在这里的作用分为三层：第一层处理 Heat 层面的请求，就是根据模板和输入参数来创建 Stack，这里的 Stack 是由各种资源组合而成。第二层解析 Stack 里各种资源的依赖关系，Stack 和嵌套 Stack 的关系。第三层就是根据解析出来的关系，依次调用各种服务客户段来创建各种资源。

图 3. Heat Engine 结构

编排

[size=1.0625]编排，顾名思义，就是按照一定的目的依次排列。在 IT 的世界里头，一个完整的编排一般包括设置服务器上机器、安装 CPU、内存、硬盘、通电、插入网络接口、安装操作系统、配置操作系统、安装中间件、配置中间件、安装应用程序、配置应用发布程序。对于复杂的需要部署在多台服务器上的应用，需要重复这个过程，而且需要协调各个应用模块的配置，比如配置前面的应用服务器连上后面的数据库服务器。下图显示了一个典型应用需要编排的项目。

图 4. 编排

[size=1.0625]在云计算的世界里，机器这层就变为了虚拟的 VM 或者是容器。管理 VM 所需要的各个资源要素和操作系统本身就成了 IaaS 这层编排的重点。操作系统本身安装完后的配置也是 IaaS 编排所覆盖的范围。除此之外，提供能够接入 PaaS 和 SaaS 编排的框架也是 IaaS 编排的范围。

Heat 编排

[size=1.0625]OpenStack 从最开始就提供了命令行和 Horizon 来供用户管理资源。然而靠敲一行行的命令和在浏览器中的点击相当费时费力。即使把命令行保存为脚本，在输入输出，相互依赖之间要写额外的脚本来进行维护，而且不易于扩展。用户或者直接通过 REST API 编写程序，这里会引入额外的复杂性，同样不易于维护和扩展。这都不利于用户使用 Openstack 来进行大批量的管理，更不利于使用 OpenStack 来编排各种资源以支撑 IT 应用。

[size=1.0625]Heat 在这种情况下应运而生。Heat 采用了业界流行使用的模板方式来设计或者定义编排。用户只需要打开文本编辑器，编写一段基于 Key-Value 的模板，就能够方便地得到想要的编排。为了方便用户的使用，Heat 提供了大量的模板例子，大多数时候用户只需要选择想要的编排，通过拷贝-粘贴的方式来完成模板的编写。

[size=1.0625]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 模板

[size=1.0625]Heat 目前支持两种格式的模板，一种是基于 JSON 格式的 CFN 模板；另外一种是基于 YAML 格式的 HOT 模板。CFN 模板主要是为了保持对 AWS 的兼容性。HOT 模板是 Heat 自有的，资源类型更加丰富，更能体现出 Heat 特点的模板。

[size=1.0625]一个典型的 HOT 模板由下列元素构成：

模板版本：必填字段，指定所对应的模板版本，Heat 会根据版本进行检验。
参数列表：选填，指输入参数列表。
资源列表：必填，指生成的 Stack 所包含的各种资源。可以定义资源间的依赖关系，比如说生成 Port，然后再用 port 来生成 VM。
输出列表：选填，指生成的 Stack 暴露出来的信息，可以用来给用户使用，也可以用来作为输入提供给其它的 Stack。
0 D" f) V+ s" A: Y( d1 l

[size=1.0625]对于 CFN 模板和 HOT 模板的不同，包括所支持的资源类型的不同，不在本文的讨论范围内。本文会主要用 HOT 模板。HOT 模板的全称是 Heat Orchestration Template，是 Heat 发展的重心。

Heat 对基础架构的编排

[size=1.0625]对于不同的资源，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

[size=1.0625]在上面创建 VM 的例子中，我们选择从输入参数获得 OS::Nova::Server 所需的值。其中利用 user_data 做了一些简单的配置。

Heat 对软件配置和部署的编排

[size=1.0625]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 对应的配置
. ~/ H1 j% P @

[size=1.0625]其中最常用的是 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment。

OS::Heat::SoftwareConfig

[size=1.0625]下面是 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.service

OS::Heat::SoftwareDeployment

[size=1.0625]下面是 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 流程

[size=1.0625]OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 协同工作，需要一系列 Heat 工具的自持。这些工具都是 OpenStack 的子项目。

[size=1.0625]首先，os-collect-config 调用 Heat API 拿到对应 VM 的 metadata。

[size=1.0625]当 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/ \ u$ V* @1 f/ q! q4 X( n- E

[size=1.0625]每个文件夹都应对了软件不同的阶段，比如预先配置阶段、配置阶段、后配置阶段和迁移阶段。如果任一阶段的脚本执行出现问题，它会运行 error.d 目录里的错误处理脚本。os-refresh-config 在配置阶段会调用一定预先定义的工具，比如 heat-config，这样就触发了 heat-config 的应用，调用完 heat-config 后，又会调用 os-apply-config。存在在 heat-config 或者 os-apply-config 里的都是一些脚本，也叫钩子。Heat 对于各种不同的工具提供了不同的钩子脚本。用户也可以自己定义这样的脚本。

[size=1.0625]等一切调用完成无误后，heat-config-notify 会被调用，它用来发信号给 Heat，告诉这个软件部署的工作已经完成。

[size=1.0625]当 Heat 收到 heat-config-notify 发来的信号后，它会把 OS::Heat::SoftwareConfig 对应资源的状态改为 Complete。如果有任何错误发生，就会改为 CREATE_FAILED 状态。

图 6. OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 流程图

Heat 对资源自动伸缩的编排

[size=1.0625]基础架构的自动伸缩是一个很高级的功能。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 对负载均衡的编排

[size=1.0625]负载均衡也是一个很高级应用，它也是由一组不同的资源类型来实现的。资源类型包括：

OS::Neutron::Pool：定义资源池，一般可以由 VM 组成
OS::Neutron::PoolMember：定义资源池的成员
OS::Neutron::HealthMonitor：定义健康监视器，根据自定的协议，比如 TCP 来监控资源的状态，并提供给 OS::Neutron::Pool 来调整请求分发
OS::Neutron::LoadBalancer：关联资源池以定义整个负载均衡。
; z* e; f2 L2 `1 A6 \" m

图 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 (PoolMember)
properties:
pool_id: {get_resource: pool} (pool)
address: {get_attr: [my_server，first_address]}
protocol_port: 80
other_member:
type: OS::Neutron::PoolMember (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 (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 (LoadBalancer)
properties:
protocol_port: 80
pool_id: {get_resource: pool}

Heat 和配置管理工具集成

[size=1.0625]随着 DevOps 的流行，大量配置管理的工具应运而生，比如 Chef、Puppet 和 Ansible。各种工具除了提供一个平台框架外，更是针对大量的中间件和软件部署提供了可以灵活配置和引用的脚本。以 Chef 为例，它提供了大量针对开源软件的 cookbook。各大厂商也给自己的中间件编写了 cookbook，比如说 IBM 给 DB2 提供了 cookbook。有了这些 cookbook，用户就可以通过简单的配置和应用来部署复杂的中间件或者软件应用。

[size=1.0625]Heat 在基于 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 的协同使用上，提供了对这些配置管理工具的支持。

[size=1.0625]首先，对于 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

[size=1.0625]然后再 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

[size=1.0625]这样在软件部署的时候，就会调用对应的脚本钩子 heat-config-ansible 来执行对应的软件配置。

图 9. group:ansible 的 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 流程

Heat 和 IBM UCDP/UCD 的集成

[size=1.0625]随着云计算的逐步兴起，各种基于云计算的的部署编排工具开始出现了。从目前来看，主要有跨平台，可视化，强大的配置管理功能等几个方面。其中 IBM 的 UrbanCode Deploy with Patterns（UCDP）和 UrbanCode Deploy（UCD）是一种强大的平台，具备上述的特性。

[size=1.0625]UCDP 是全栈的环境管理和部署解决方案，支持用户为多种云设计、部署和更新全栈环境。该平台可集成 UCD，基于 Heat 来实现对 OpenStack 基础架构自动化来优化持续的交付吞吐量。它具备可视化的操作界面。通过拖拽图标来创建和编辑跨云平台的模板。

[size=1.0625]UCD 将应用、中间件配置以及数据库的变更进行编排并自动部署到开发环境、测试环境和生产环境中。它能让用户通过自助服务方式，根据需要或按照计划进行部署。在 UCD 中，能够按照配置（configuration-only）或者传统的代码和配置（code-and-configuration）来分拆复杂的应用配置进行逐步定义。

[size=1.0625]通过借助于 UCDP 强大的 Pattern 设计能力，我们可以通过拖拽的方式制作一个复杂的模板。其中用到两种类型的资源，一种是云计算资源，比如说网络、安全组、镜像等，另外是定义于 UCD 中的组件，比如其中的 Jke.db、MySQL Server、jke.war 和 WebSphere Liberty Profile.

图 10. UCDP 强大的 Pattern 设计能力

[size=1.0625]通过借助 UCDP/UCP 和 Heat 的集成，可以很方便的点击按钮来生成对应的环境(UCDP/UCD 用语)或者 Stack(Heat 用语)。

[size=1.0625]首先，UCDP 把设计好的模板发给 Heat。然后 Heat 会调用 UCD 扩展插件来解释模板并翻译为 Heat 能够认识的模板，这个过程有可能需要访问 UCD 得到更为细节的解释。接着 Heat 去生成相应的资源，一般肯定有 VM，并在 VM 上安装 UCD agent，并启动 agent。Agent 会调用 UCD 拿到具体组件，比如 WebSphere Liberty Profile 的部署定义细节，然后执行。最终完成 Stack 的生成。

图 11. UCDP/UCD 和 Heat 的集成

结束语

[size=1.0625]本文介绍了 OpenStack 和 OpenStack Heat，特别是 Heat 的架构。然后介绍了什么是编排，Heat 在编排的位置，以及 Heat 模板。接着本文逐一介绍了 Heat 是如何来实现和支持编排，分别从基础架构，软件配置和部署，自动资源伸缩和负载均衡等角度进行了叙述。本文最后介绍了 Heat 和配置管理工具的集成，以及 Heat 和 IBM UCDP/UCD 的集成。

[size=1.0625]随着云计算的日益流行，各种云计算平台大量兴起。谁最终能被行业和用户接受，一定是取决于谁能够高效支持用户复杂应用的编排。Heat 对编排的全方位支持将有力地支持 OpenStack 在云计算，特别是在 IaaS 中领导地位。对此，我们拭目以待。

admin · 发表于 2017-11-10 21:54:22

heat_template_version: 2015-04-30
description: >
  A template showing how to create a Nova instance, a Cinder volume and attach
  the volume to the instance. The template uses only Heat OpenStack native
  resource types.
parameters:
  key_name:
type: string
default: linux_key
description:
   Name of an existing key pair to enable SSH access to the instance.
  instance_type:
type: string
description: Type of the instance to be created.
default: m1.small
constraints:
   - allowed_values: [m1.small, m1.medium, m1.large]
      description:
      Value must be one of 'm1.small', 'm1.medium' or 'm1.large'.
  image_id:
type: string
description: ID of the image to use for the instance to be created.
default: linux_img
constraints:
   - allowed_values: [ linux_img ]
      description:
      Image ID must be linux_img
  availability_zone:
type: string
description: The Availability Zone to launch the instance.
default: nova
  volume_size:
type: number
description: Size of the volume to be created.
default: 1
constraints:
   - range: { min: 1, max: 1024 }
      description: must be between 1 and 1024 Gb.
resources:
  avoltest:
type: OS::Nova::Server
properties:
   availability_zone: { get_param: availability_zone }
   image: { get_param: image_id }
   flavor: { get_param: instance_type }
   key_name: { get_param: key_name }
   user_data_format: RAW
   user_data:
      str_replace:
      params:
         $LOGFILE: /tmp/installlog.log
         $VOLSIZE: { get_param: volume_size }
      template: |
         #!/bin/bash -v
            die() {
            _WC-NOTIFY_ --data-binary '{"status": "FAILURE"}'
            exit 1
            }
         yum install -y lvm2 >> $LOGFILE 2>&1 || die
         pvcreate /dev/sdb >> $LOGFILE 2>&1 || die
         vgcreate volgroup01 /dev/sdb >> $LOGFILE 2>&1 || die
         lvcreate -l+100%FREE -n lvol01 volgroup01 >> $LOGFILE 2>&1 || die
         mkfs.ext4 -F /dev/mapper/volgroup01-lvol01 >> $LOGFILE 2>&1 || die
         mkdir /data
         echo "/dev/mapper/volgroup01-lvol01 /data ext4 defaults 0 0" >> /etc/fstab
         mount -a
         df -ah >> $LOGFILE 2>&1 || die
  cinder_volume:
type: OS::Cinder::Volume
properties:
   size: { get_param: volume_size }
   availability_zone: { get_param: availability_zone }
  volume_attachment:
type: OS::Cinder::VolumeAttachment
properties:
   volume_id: { get_resource: cinder_volume }
   instance_uuid: { get_resource: avoltest }
   mountpoint: /dev/sdb
outputs:
  instance_ip:
description: Public IP address of the newly created Nova instance.
value: { get_attr: [avoltest, first_address] }

admin · 发表于 2017-11-10 21:55:19

heat_template_version: 2013-05-23

description: >
  This template demonstrates a minimal SoftwareDeployment example
parameters:
  key_name:
type: string
default: stack_key
  flavor:
type: string
default: m1.small
  image:
type: string

resources:
  sc:
type: OS::Heat::SoftwareConfig
properties:
   inputs:
      - name: message
      default: 'NONE'
   outputs:
      - name: file_content
   group: script
   config: |
      #!/bin/sh
      echo "${message}" > /hello
      cat /hello > ${heat_outputs_path}.file_content
  sd:
type: OS::Heat::SoftwareDeployment
properties:
   config: {get_resource: sc}
   server: {get_resource: server}
   signal_transport: HEAT_SIGNAL
   input_values:
      message: 'Hello, world!'

  server:
type: OS::Nova::Server
properties:
   image: {get_param: image}
   flavor: {get_param: flavor}
   key_name: {get_param: key_name}
   user_data_format: SOFTWARE_CONFIG
   software_config_transport: POLL_SERVER_HEAT

outputs:
  deploy_output:
value:
   get_attr: [sd, file_content]

admin · 发表于 2017-11-10 21:58:05

Hi, I want to create heat template that serve the following purpose:

Launch Instance from image
Create Cinder Volume
Attach the Volume to the instance
Configure the volume on the instance as LVM, format the LVM as ext4, and finally mount it
So i create something like this:

heat_template_version: 2015-04-30
description: >
  A template showing how to create a Nova instance, a Cinder volume and attach
  the volume to the instance. The template uses only Heat OpenStack native
  resource types.
parameters:
  key_name:
type: string
default: linux_key
description:
   Name of an existing key pair to enable SSH access to the instance.
  instance_type:
type: string
description: Type of the instance to be created.
default: m1.small
constraints:
   - allowed_values: [m1.small, m1.medium, m1.large]
      description:
      Value must be one of 'm1.small', 'm1.medium' or 'm1.large'.
  image_id:
type: string
description: ID of the image to use for the instance to be created.
default: linux_img
constraints:
   - allowed_values: [ linux_img ]
      description:
      Image ID must be linux_img
  availability_zone:
type: string
description: The Availability Zone to launch the instance.
default: nova
  volume_size:
type: number
description: Size of the volume to be created.
default: 1
constraints:
   - range: { min: 1, max: 1024 }
      description: must be between 1 and 1024 Gb.
resources:
  avoltest:
type: OS::Nova::Server
properties:
   availability_zone: { get_param: availability_zone }
   image: { get_param: image_id }
   flavor: { get_param: instance_type }
   key_name: { get_param: key_name }
   user_data_format: RAW
   user_data:
      str_replace:
      params:
         $LOGFILE: /tmp/installlog.log
         $VOLSIZE: { get_param: volume_size }
      template: |
         #!/bin/bash -v
            die() {
            _WC-NOTIFY_ --data-binary '{"status": "FAILURE"}'
            exit 1
            }
         yum install -y lvm2 >> $LOGFILE 2>&1 || die
         pvcreate /dev/sdb >> $LOGFILE 2>&1 || die
         vgcreate volgroup01 /dev/sdb >> $LOGFILE 2>&1 || die
         lvcreate -l+100%FREE -n lvol01 volgroup01 >> $LOGFILE 2>&1 || die
         mkfs.ext4 -F /dev/mapper/volgroup01-lvol01 >> $LOGFILE 2>&1 || die
         mkdir /data
         echo "/dev/mapper/volgroup01-lvol01 /data ext4 defaults 0 0" >> /etc/fstab
         mount -a
         df -ah >> $LOGFILE 2>&1 || die
  cinder_volume:
type: OS::Cinder::Volume
properties:
   size: { get_param: volume_size }
   availability_zone: { get_param: availability_zone }
  volume_attachment:
type: OS::Cinder::VolumeAttachment
properties:
   volume_id: { get_resource: cinder_volume }
   instance_uuid: { get_resource: avoltest }
   mountpoint: /dev/sdb
outputs:
  instance_ip:
description: Public IP address of the newly created Nova instance.
value: { get_attr: [avoltest, first_address] }
but with that template, the bash command for creating the lvm (pvcreate and so on) is executed first before the volume is being attached to the instance, so it failed.

Anyone have idea how to make it in order so that the bash commands on the instance will be executed after the volume is attached? Thank you
add a comment
2 answers Sort by » oldestnewestmost voted
0
answered May 4 '17
kcd gravatar image
kcd
1
There need to be more examples on how to do this, it is non-trivial

Here's mine

  config_mount_volume:
type: OS::Heat::SoftwareConfig
properties:
   group: ungrouped
   config:
      str_replace:
      template: |
         #!/bin/bash
         set -e
         voldata_id=PARAM_voldata_id
         mount_dir=PARAM_voldata_mount/
         echo "Mount volume ${voldata_id} to ${mount_dir}"
         voldata_dev="/dev/disk/by-id/virtio-$(echo ${voldata_id} | cut -c -20)"
         partition_dev="${voldata_dev}-part1"

         while [ ! -e ${voldata_dev} ]; do echo Waiting for volume ${voldata_id} to attach; sleep 1; done

         if [[ ! $(ls ${voldata_dev}-part*) ]]; then
            echo "No partitions found, create ${partition_dev}"
            echo ",+," | sfdisk ${voldata_dev}
         fi

         if [[ ! $(file -sL ${partition_dev} | grep ext4) ]]; then
            echo "Partitions not formated, format it as ext4"
            # yes /dev/disk/by-id/, partprobe and hdparm show it is there, but no it is is not ready
            sleep 1
            mkfs.ext4 ${partition_dev}
            file -sL /dev/disk/by-id/*
         fi
         mkdir -pv ${mount_dir}
         # mount on reboot
         echo "${partition_dev} ${mount_dir} ext4 defaults,nofail 0 0" >> /etc/fstab
         # mount now
         mount ${mount_dir}
      params:
         PARAM_voldata_id: { get_param: data_volume }
         PARAM_voldata_mount: { get_param: data_dir }
link
add a comment
0
answered Nov 23 '15
jayaprakash gravatar image
jayaprakash flag of India
171 ●2 ●4 ●11 https://in.linkedin.co...
Hi boniamd,

In your case instead of executing custom script as part of User-Data on launching a VM, it can be executed by defining a separate resource software-config/deploy and make it as dependency to volume attachment task so that the script execution will be done only after volume is attached.

Please refer cirros-hello-world.yaml heat template on how to define a software config resource to execute shell script.

		自动登录	找回密码
密码			注册