跳转到： 导航, 搜索

Heat/DSL

仅提案

请注意，这只是一个建议的 DSL，供开发考虑。此规范尚未实现。

正在尝试进一步简化此 DSL 的演进版本位于 Heat/DSL2，以及使用真实模板的进一步演进版本位于 gist-5408410，以及在 etherpad 中的开放问题。

参见

概述

这是一个与 HEAT 一起使用的 DSL，用于允许一个简单的 REST API 来暴露更丰富的功能集。它的设计目的是声明性的，这意味着它将标识要部署和编排的内容，而不是明确地说明如何部署或编排它。语法旨在简单易懂。

  1. 任何人，但通常是主题专家 (SME)，都会编写一个 Heat 蓝图，说明如何部署应用程序。
  2. Heat 蓝图包含 组件、这些组件之间的 关系，以及关于应用程序工作方式的 选项 和 约束。
  3. 用户定义 环境，他们希望在其中部署应用程序（例如，笔记本电脑、OpenStack 云、Rackspace US 云帐户）。
  4. 用户选择一个蓝图（例如，可扩展的 WordPress 蓝图）并将其部署到他们选择的环境中。这是一个 部署，结果是一个完全构建并运行的多组件应用程序。
  5. Heat 知道如何添加/删除服务器（扩展）并可以验证应用程序是否正在运行并执行故障排除（配置管理）。


以下是蓝图各个部分的视觉概述。

笔记

  • 并非所有可能的关系都显示出来。
  • 此图表仅作为指南，不作为规范参考。
Heat blueprint.png

角色

  • 云服务提供商 - 在 OpenStack 或其他云技术上提供托管云服务的服务实体。也称为供应商。
  • SME - 负责创建 Heat 蓝图的人。他/她根据对该系统组件的深入了解和专业知识，编码系统的逻辑和约束。
  • 租户 - 云服务提供商的单个客户
  • 用户 - 部署最终用户 - 使用 Heat 启动编排的人

DSL 设计目标

  • 简单性 对于最终用户应该优先于所有其他设计目标。使其易于阅读、故障排除、调试等。
  • 灵活性 应该允许 DSL 用于各种合理的用例，但不应旨在支持 *所有* 可能的用例。

术语

DSL

DSL 是领域特定语言的首字母缩写。这是用于表达配置或指令以通过其 API 行使系统功能的语法，同时保持 API 本身的最简状态。

Heat 编排模板 (HOT)

Heat 编排模板 是一个编排文档，详细说明了执行编排所需的一切。可以将它视为 AWS CloudFormation 模板的功能等效物。它以 YAML 格式表示。注意：JSON 是 YAML 的子集。任何 YAML 解析器也将接受 JSON。HOT 可以在多个租户的不同云服务提供商之间共享。它们可以包含用于启动特定服务或应用程序的所有供应商无关的规范。例如，Rackspace 可以发布一个“Best Practice WordPress by Rackspace”模板，供任何云服务提供商的任何租户使用。该模板由主题专家创建。请参阅：Heat 蓝图

环境

环境 是部署的逻辑目标。它对给定的用户来说是唯一的，但独立于区域、单元、云等。用户可以为 生产 指定一个环境，为 暂存 指定另一个环境，也许为 开发/测试 指定另一个环境。可以指定任意数量的环境。给定的环境可以混合来自不同云服务提供商的组件，例如，计算服务来自本地 OpenStack 云，但备份发生在 Rackspace 云上。请参阅：环境

部署

部署 由 Heat 蓝图、环境和任何输入组成。部署可以捆绑在一个 YAML 文件中，该文件包含这些工件的显式定义或引用。通常，用户会引用他们引用的现有环境和 Heat 蓝图。请参阅：部署

组件

组件 是云服务提供的功能或服务的抽象表示。将在公共存储库中创建通用组件标识符的通用目录，类似于 Juju Charms 和 OpsCode cookbooks。请参阅：组件

资源

资源代表正在运行的部署的工件，分为两种类型

  • 静态资源 是一种编排工件，可以由蓝图作者预先定义，并用于自定义蓝图的各个方面。一个很好的例子是定义一个共享的安全密钥对，该密钥对将在蓝图中的所有资源之间创建和共享。它们可以表示为任意键：值对，并在 Heat 蓝图中定义。静态资源由系统处理，并在配置期间生成共享的 部署资源。
  • 部署资源 是一种编排工件，代表作为正在运行的 部署 的一部分组件的实例化，例如计算节点、软件工件或负载均衡器。请参阅：提供者 和 部署

选项和输入

选项可以由 Heat 蓝图和组件公开。选项是用户可以选择的值的定义，可以为 Heat 蓝图或组件提供。

在启动部署时，为选项选择的值存储为部署中的输入，位于“inputs”键下。输入可以应用于部署层次结构的各个范围，如下所示

  • 全局输入（适用于所有内容）
    • inputs: domain: mydomain.com
  • Heat 蓝图输入（适用于 Heat 蓝图上的设置）
  • 服务输入（适用于蓝图中的特定服务）
    • inputs: services: "backend": use_encryption: true
  • 提供者输入（适用于提供者及其提供的任何资源）
    • inputs: providers: 'legacy': region: dallas
  • 资源类型输入。这些可以应用于服务或提供者，如下所示
    • inputs: services: "backend": 'database': 'memory': 512 Mb providers: 'nova': 'compute': 'operating-system': Ubuntu 12.04 LTS

可以使用约束将选项与一个或多个选项关联起来。示例

blueprint:
    options: 
        "my_setting": 
            default: 1 
            constrains: [{service: web, resource_type: compute, setting: foo}]

上述设置将应用于蓝图的“web”服务中的“compute”资源下的任何名为“foo”的设置。更精确的范围选项将覆盖更广泛的选项。例如，服务或提供者选项将覆盖全局选项。

DSL 基础概念

组件

组件等效于 Chef 菜谱或 Juju charm。它们是应用程序部署的原始构建块。这些可以作为部署的一部分提供，也可以从服务器中查找。

示例组件

# Definitions of components used (similar to Juju charm syntax)
components:
- &wordpress_reference_id
  id: wordpress
  revision: 3
  summary: "A popular blog engine"
  provides:
    url:
      interface: http
  requires:
    db:
     interface: mysql
    server:
      relation: host
      interface: linux
  options:
    url:
      type: String
      default: wp.test.local
      description: the url to use to host your blog on

- &mysql.1
  id: mysql
  revision: 1
  summary: "A popular database. Note, this is a cloud database and therefore does not need a host"
  provides:
    db: mysql
  • name - 一个简短的描述性字符串，用于让人识别组件。示例：mssql（不是 Microsoft SQL Server）。
  • role - 允许一个组件在多个角色中起作用（例如，主服务器、从服务器）。
  • version - 表示此组件版本的字符串。示例：1.0.0
  • description - 组件的简短描述。示例：Microsoft SQL Server
  • is - 描述基于 OpenStack 原语的封闭列表的资源类型（计算、数据库、负载均衡器、应用程序，...）。
  • requires 此资源需要什么才能正常运行。需求可以是具体的或通用的。通用的是任何具有 mysql 接口的（对于 WordPress）。具体的是“我需要一个主机计算资源，该资源是 Ubuntu 12.04 或更高版本的机器”。
“requires”语法的两种选项（短格式和长格式）
短格式
语法：type: interface
示例
requires:
 database: mysql
长格式
语法：requirement_key: value
“我需要一个主机计算资源，该资源是 Ubuntu 12.04 或更高版本的机器”的示例
requires:
  host:  # this is a user-supplied identifier
    type: compute
    interface: linux
    distro: debian
    relation: host
请注意，requirement_keys 可以是任意的，以标记需求。来自上述示例的需求
type: 所需资源的类型
interface: 资源的通用接口要求（应该是 Linux 的一种变体）
distro: 一个任意键，说明满足此需求的合格组件必须提供 distro:debian
relation: host（这表示我托管在此资源上。没有它我就无法存在。它关闭时我也关闭）。“host”是一个关键字。
constraint: - 'os': ['debian', 'redhat'] 名称+键/值语法允许需要相同资源的多个资源（例如，日志和数据 mysql 数据库），以及添加其他约束等...
  • options - 用于列出我可以在此组件上设置的可选设置。

它们采用一般形式

<option-name>: 
 default: <value> 
 required: < optional | required | auto-generated> (default: optional) 
 type: < string | integer | boolean | url> (default: string)

示例

username: 
 default: root 
 required: required
 type: string
  • provides - 资源_类型：接口条目的数组或哈希
注意：数组可以用破折线作为前缀在 YAML 中表示。
例如，假设我们获得了一个提供“网站”资源的托管 API。网站可以提供

示例

components:
- &website_reference_id
  id: website
  provides:
    - database: mysql
    - application:
      name: php
      version: [5.0, 5.5, 6.3-BETA]

静态资源和部署资源

静态资源 是一种可以由蓝图作者预先定义并用于自定义蓝图各个方面的工件。一个很好的例子是定义一个共享的安全密钥对，该密钥对将在蓝图中的所有资源之间创建和共享。它们可以表示为任意键：值对，并在 Heat 蓝图中定义。静态资源由系统处理，并在配置期间生成共享的 部署资源。

示例

 resources:
   sync-keys:
     type: key-pair
     constrains:
     - setting: private_sync_key
       resource_type: application
       service: drupal
       attribute: private_key
     - setting: public_sync_key
       service: drupal
       resource_type: application
       attribute: public_key_ssh

提供者

提供者是 Heat 的一个插件，它了解如何通过一个或多个 组件 实现来实例化和管理 部署资源。例如，Rackspace Compute 提供者知道如何与 Rackspace Open Cloud 交互以创建计算资源。OpsCode Chef 提供者知道如何操作 Chef 并应用 Cookbooks。注意：提供者 != 云服务提供商。

字段

  • vendor - 标识提供者来源的简短字符串。示例：openstack
  • provides - 以键：值对列表的形式提供的内容
  • constraints - 关于如何提供此提供者的约束列表。表示为键：值对列表


示例

providers:
- id: nova
  vendor: openstack
  provides:
  - compute: linux
  - compute: windows
  constraints:
  - region: ORD

在 环境 的上下文中示例

environment:
  providers:
    - id: chef-solo
      vendor: opscode


行动项目

  • 提供者可能具有算法或用户创建的映射文件，以将 Heat 命名空间中的项目映射到提供者特定的命名空间。例如，wordpress/database/db_user 用于 OpsCode Chef。这可以用于动态生成组件定义，我们需要能够在它们流经 Heat 后将它们映射回去。

提供者 API

GET /providers
GET /tenant_id/environments/environment_id/providers/provider_id/catalog/

返回按资源类型分组的组件列表

另请参阅：Heat/Open_API

环境

环境提供了一个“上下文”和可选的约束，以及提供者列表。例如，如果我有一个环境，其中云数据库提供者“约束”为区域 LON，而云数据库在该区域没有 32GB 实例，那么目录将不会有 32GB 实例。

  • id - 客户端（或用户）提供的唯一标识符。
  • name - 用于方便识别环境的字符串
  • providers - 预定义的键是提供者提供的功能名称。提供者在 Heat 中基于 id 和 vendor 字段进行标识。


prod_compute

 id: nova: 
 vendor: rackspace

上述结果导致 Heat 动态加载 heat.providers.rackspace.nova（最后两个是 vendor.id）

chef:
    id: chef-solo
    vendor: opscode 
database: 
    id: database
    vendor: rackspace 
    constraints:
    - region: DFW
    catalog: ...

关于 constraints：可以在提供者级别应用可选约束，例如以下示例，以将区域限制为“DFW”。语法遵循正常的约束语法，但可以缩短为键：值简写。对于正常的语法，一个“value”定义了约束的评估结果。

关于 catalog：- 一种将目录注入提供者的方法（有两个用途#1 测试，#2 仅想显示 1GB 实例）。因此，如果提供了目录，提供者将使用它。否则，它可以登录并查询底层服务（列出镜像、列出风味、获取 cookbooks 等...）。您将在 app.yaml 中看到这一点。

环境将根据环境提供者和约束定义其外观。如果环境无法提供所需的资源或满足声明或继承的约束，则蓝图可能与环境不兼容。

请注意，在部署中定义环境是可选的，并且系统将默认考虑所有提供者及其目录，以满足蓝图请求的组件。冲突解决是进一步讨论和设计的一个领域，应该影响部署 api 端点的请求和响应周期。

示例环境

# Environment
environment: &environment_1000_stag
  name: Rackspace Cloud US - staging
  providers:
    nova:
      id: nova
      vendor: rackspace
      provides:
      - compute: linux
      - compute: windows
      constraints:
      - region: ORD
    lb:
      id: load-balancer
      vendor: rackspace
      provides:
      - loadbalancer: http
    database:
      id: database
      vendor: rackspace
      provides:
      - database: mysql
    chef:
      id: chef-server
      vendor: opscode
      provides:
      - application: http  # see catalog for list of apps like wordpress, drupal, etc...
      - database: mysql  # this is mysql installed on a host

Heat 编排模板 (HOT)

这些定义了应用程序的架构。模板描述了运行应用程序所需的资源以及要连接的组件。HOTs 可以具有选项，这些选项决定最终的部署拓扑以及输入到各个组件选项中的值。SME 确定要公开哪些选项以及要应用于可用选项的约束。

应用程序是提供有用功能的组件集合。应用程序与基础设施不同。HOT 描述了一种设计，该设计为应用程序提供某些“ilities”（可扩展性、可用性等）。它定义了组件、它们之间的关系以及必须满足的组件和关系的各种约束，以便应用程序按指定方式工作。

在表达服务时，Heat Orchestration Templates 包含

  • 一个或多个服务（全部在一个“services”条目下）
  • 服务 ID 的任意名称（每个服务都有自己的 ID）
  • 每个服务一个或多个组件，预计我们将来可以将嵌套模板（通过包含或引用）作为组件引入。
  • 服务之间的关系

属性

  • id - 用户/客户端提供的唯一标识符
  • name - 命名服务的短字符串
  • description：服务的更详细描述
  • services - 类似于层级，但不受层级概念的限制。当前，每个服务定义了一个组件。

示例 HOT

name: Simple Wordpress
services:
  blog:
    requires:
    - compute:
      type: linux
      constraints:
        os: {option: linuxdistribution}
        flavor: {option: instancetype}
    components:
      wordpress:
        requires:
        - application:
            name: wordpress
            role: web
        relations:
        - blog: db
      db:
        requires:
        - database:
            type: mysql
            constraints:
                name: { option: dbname }
                username: { option: dbusername }
                password: { option: dbpassword }
                rootpw: { option: dbrootpassword }
options:
  instancetype:
    description: Webserver instance type
    type: string
    default: m1.large
    constraints:
    - in:
      values:
      - m1.large
      - m1.xlarge
      - m2.large
      - m2.xlarge
      message: "Must be one of m1.large, m1.xlarge, m2.large, m2.xlarge"
  dbname:
    description: The wordpress database name
    type: string
    default: wordpress
    constraints:
    - len:
      min: 1
      max: 64
      message: Must be between 1 and 64 characters
    - matches: 
      expr: [a-zA-Z][a-zA-Z0-9]*
      message: must begin with a letter and contain only alphanumeric characters
  dbusername:
    description: The wordpress database admin account username
    type: string
    default: admin
    constraints:
    - len:
      min: 1
      max: 16
      message: must be between 1 and 16 characters
    - matches:
      expr: [a-zA-Z0-9]*
      message: must contain only alphanumeric characters
  dbpassword:
    description: The WordPress database admin account password
    type: password
    default: admin
    constraints:
    - len:
      min: 1
      max: 41
      message: must be between 1 and 41 characters
    - matches:
      expr: [a-zA-Z0-9]*
      message: must contain only alphanumeric characters
  dbrootpassword:
    description: Root password for MySQL
    type: password
    default: admin
    constraints:
    - len:
      min: 1
      max: 41
      message: must be between 1 and 41 characters
    - matches:
      expr: [a-zA-Z0-9]*
      message: must contain only alphanumeric characters
  linuxdistribution:
    description: Distribution of choice
    type: string
    default: F17
    constraints:
    - in
      values:
      - F18
      - F17
      - U10
      - RHEL-6.1
      - RHEL-6.2
      - RHEL-6.3

在上面的示例中，在 blog 服务中定义的组件将与系统已知可以满足的任何组件匹配

application:
    name: wordpress
    role: web

前提是没有对组件施加其他要求。此要求可以转换为“我需要一个可以提供名为 wordpress 的应用程序并且可以满足 web 角色的组件实现”。

  • relations：指定与其他服务和/或组件的连接。示例：- wordpress 应用程序到 mysql 数据库 - 负载均衡器到 webhead。
  • options - 模板的这一部分标识了在配置时可以提供的参数。它遵循类似于组件选项的语法，但没有约束。有关更多信息，请参阅 HOT Options 部分。

有关表达更复杂逻辑（例如大于、小于等）的语法，请参阅 options 部分。

  • resources - 在规划时创建并在蓝图之间共享的静态资源。例如，用户和密钥
my_key: 
    type: key-pair

注意：在部署工作流约束之前，将创建私钥/公钥对

service: my_database_thang 
    setting: key 
    attribute: private_key

上面的示例将从生成的密钥中获取 private_key 值，并将其作为 my_database_thang 组件中“key”的值应用。

Heat Blueprint Options

您可以在 Heat Blueprints 上指定 options 和 inputs。支持的选项字段在此处详细介绍。

字段
  • label - 在向用户显示选项时使用的简短标签。description：此选项的完整描述（它是什么）
  • meta-data - 您可以在此处放置其他信息，例如使用的模式版本，或子系统所需的其他任意数据。
    • schema-version - 标识此 Heat Blueprint 中使用的模式版本。示例：0.7

示例

 meta-data:
   schema-version: 1.0
   application-name: "Drupal"
   blueprint-type: "Application"
   flavor: "Single Server"
  • help - 此选项的详细帮助（如何使用它）
  • sample - 数据将如何显示的一个示例。这可以显示为文本控件的背景。
  • display-hints - 映射（键、值对），用于提示如何相对于其他选项对该选项进行排序和显示....
  • group - 用于将选项分组的组名。示例提示 Horizon
    • deployment：这是一个部署选项，显示在部署名称下方
    • application：这是一个应用程序选项，显示在选项的第一个屏幕上
    • compute：这是一个应该显示在计算服务器选项部分下的选项
    • load-balancer：这是一个应该显示在负载均衡器选项部分下的选项
    • database：这是一个应该显示在数据库选项部分下的选项
    • dns：这是一个应该显示在 dns 选项部分下的选项
  • order - 指示该选项在其组内的相对顺序（整数）
  • list-type - 列表中条目的类型。用于标识它是否应该成为特定的资源类型和列表或属性。格式为 resource-type.list，其中 resource-type 是已知的 Heat 资源类型（compute、database 等），list 是提供程序中的列表之一 [TODO：在 DSL 或模式中更精确地定义这些列表。现在，它们仅存在于提供程序目录中]。示例（以及我们将最初支持的内容）
    • compute.memory - 可用计算镜像大小的列表
    • _compute.os - 可用计算操作系统的列表
    • load-balancer.algorithm - 可用负载均衡器算法的列表
      • encrypted-protocols - 应该加密的协议子集，以便我们知道何时显示 ssl 证书控件。例如：[https, pop3s]
      • always-accept-certificates - 如果蓝图始终接受并处理证书（尤其是在以自由形式输入 url 支持任何协议时）
  • default - 选项的默认值。


注意：YAML 会假定数字是整数，因此最好将字符串括在“引号”中。此处的特殊值是 =generate_password()，它将在服务器上生成随机密码。TODO：考虑添加参数以生成密码，以便 Heat Blueprint 作者可以使生成的密码与他们的（或他们的应用程序的）要求匹配。这将由蓝图作者与约束（如下）结合使用，以进行客户端验证。

  • type - 此选项的数据类型。有效类型是：string、integer、boolean、password、url、region 和 text（多行字符串）。稍后将介绍 url 类型的描述，它具有一些特殊属性。
  • choice - 要从中选择的条目列表（用于显示下拉菜单）。条目是纯字符串或具有 value 和 name 条目的映射，其中 value 是传递给 Heat 的内容，name 是显示给用户的的内容。注意：不应用验证。如果需要验证，请在约束中使用。这仅用于显示。示例
choice:
- name: Ubuntu 12.04
  value: q340958723409587230459872345
- name: Ubuntu 12.10
  value: 2384729387w0tw9879t87ywt3y42
  • constrains - 用于设置或限制蓝图各个方面（使用该选项的值（或部分））的映射列表。
  • required - 布尔值。如果用户必须提供此选项，则设置为 true。
  • constraints - 约束语法中映射数组。支持的约束是
    • 大于
    • 小于
    • 大于或等于
    • 小于或等于
    • min-length - 对于字符串
    • max-length - 对于字符串
    • allowed-chars - 示例：“ABCDEFGabcdefg01234565789!&@” - TODO：查看是否可以使用正则表达式
    • required-chars - 示例：“ABCDEFG” - TODO：查看是否可以使用正则表达式
    • in - 可接受的值列表（这些也可以由客户端用于显示下拉菜单）
    • protocols - 用于 URL 类型。这列出了 URL 中允许的协议。
    • regex - 不要使用前瞻/后瞻。保持简单，以便在 javascript（客户端）和 python（服务器）中支持。虽然上述许多内容也可以写成正则表达式规则，但两者都可供 Heat Blueprint 作者使用最适合他们的规则。
  • constraints: message - 您可以将 message 键/值对添加到任何约束中。我们建议为正则表达式约束添加消息，以便在审查时易于理解它们的作用，并且客户端/服务器可以生成有用的错误消息，并且阅读蓝图的人不必破译正则表达式。例如：“必须有 8-16 个字符”

浏览器客户端可以解析约束并应用验证规则。良好的做法是拥有多个简单的正则表达式约束，以便浏览器客户端可以为用户可能违反的每个规则提供清晰有用的反馈。例如，将密码的下划线、大写和数字要求作为三个带有唯一消息的约束列出。

带有 Options 的示例 Heat Blueprint

blueprint:
  options:
    database_name:
      label:  Database Name
      sample: db1
      display-hints:
        order: 1
        group: database
     default: wp_db
     description: "This is the name of the database that will be created to host your application's data"
     type: string
     constraints:
     - regex: ^(?=.*).{2,15}$
       message: must be between 2 and 15 characters long
     - regex: ^[A-Za-z0-9]*$
       message: can only contain alphanumeric characters
    database_password:
      label:  Database Password
      display-hints:
        order: 2
        group: database
     description: "This is the password to use to access the database that will host your application's data"
     type: password
     constraints:
     - regex: ^(?=.*).{8,15}$
       message: must be between 8 and 15 characters long
     - regex: ^(?=.*\d)
       message: must contain a digit
     - regex: ^(?=.*[a-z])
       message: must contain a lower case letter
     - regex: ^(?=.*[A-Z])
       message: must contain an upper case letter
常见类型
URL 类型

url 类型的选项为处理常见的 url 用例提供了一些高级处理。该选项可以简单地用作接受 url 的字符串。在这种情况下，将类型设置为 url 的唯一好处是客户端应用程序可以执行某些验证以确保提供的值是有效的 URL（根据 RFC 3986）。

示例

option:
  my_web_site:
    type: url

然而，能够单独处理 URL 的不同部分（即方案或协议、域、路径、端口、用户名、密码等）是有用的。它们可以独立验证（例如，确保协议仅为 http 或 https）。这些部分可以使用约束连接到蓝图的不同部分（例如，使用域部分进行 dns 设置）。支持的方法是 url 类型具有可以在 Heat Blueprint 或 Heat 的其他部分中访问的属性。

* scheme - this is the first part of the URL
* protocol - this is the first part of the URL as well (an alias to scheme)
* netloc - the dns name or address part
* port - this is the port if specified (e.g. the port in https://:8080 is 8080)
* path - the path of the resource or file
* private_key - the private_key of a certificate to use if the protocol is an encrypted one
* public_key - the public_key of a certificate to use if the protocol is an encrypted one
* intermediate_key - the intermediate key chain of a certificate to use if the protocol is an encrypted one

这些属性可以在约束中指定

options:
  my_url:
    label: Site Address
    type: url
    constraints:
    - protocols: [http, https]
    constrains:
    - type: load-balancer
      service: lb
      attribute: protocol  # This picks out the 'http' or 'https' part of the URL
      setting: protocol
    - type: compute
      service: web
      attribute: "private_key"  # This picks out the cert
      setting: ssl_certificate
    - type: compute
      service: web
      attribute: "intermediate_key"  # This picks up the intermediate cert
      setting: ssl_intermediate_certificate

您可以使用 protocols 约束来约束协议列表。

options:
 my_url:
    label: Site Address
    type: url
    constraints:
    - protocols: [http, https]

并且有用于帮助客户端渲染和验证 url 的特殊 display-hints，这些在约束中记录为 encrypted-protocols 和 always-accept-certificates。

在作为输入提供 url 的值时，它可以作为字符串或具有属性的映射提供。

作为字符串，它将是 my_site_address: https://mydomain.com/blog。

作为映射，它将如下所示

inputs:
  my_url:
    url: https://domain.com/path  # 'url' is a special shortcut - see note below
    private_key: |
      -----  BEGIN ...
    intermediate_key: |
      -----  BEGIN ...
    public_key: |
      -----  BEGIN ...

注意：一个常见的用例是提供 url 和密钥。有一个快捷方式，可以接受名为 url 的键，该键可用于提供 url，而无需提供 url 的所有组件。

Heat Blueprint 示例

启动单个服务器的最小 Heat Blueprint

blueprint:
  services:
    "server":
      component:
        resource-type: compute
environment:
  providers:
   - id: nova:
     vendor: openstack

Hello World Heat Blueprint

blueprint:
  name: "Hello World"
  services:
    "my_server":
      component:
        resource-type: compute
        interface: linux
  options: #Options are used by the user interface, but they are not required for a truly minimal blueprint
    memory:
      label: Server Size
      default: 512
      type: integer
      constrains:
      - resource_type: compute
        setting: memory
    os:
      label: Operating System
      default: Ubuntu 12.04
      type: string
      constrains:
      - resource_type: compute
        setting: os
    region:
      type: string
environment:    
  id: rackspace-open-cloud
  name: Rackspace Open Cloud
  providers:
   - id: nova:
     vendor: openstack

这是使用 options、蓝图 meta-data 和模式版本控制的 Heat Blueprint 的片段。

blueprint:
  id: 0255a076c7cf4fd38c69b6727f0b37ea
  name: WordPress w/ MySQL on VMs
  meta-data:
    schema-version: 0.7
  services:
    lb:
      component:
        interface: vip
        type: load-balancer
      relations:
        web:
          service: web
          interface: http
          attributes:
            inbound: https/443
            algorithm: least_connections
  options:
    url:
      label: Site Address
      description: 'The domain you wish to host your blog on. (ex: example.com)'
      type: url
      required: true
      default: http://example.com/
      display-hints:
        group: application
        order: 1
        encrypted-protocols: [https]
        sample: http://example.com/
      constraints:
      - protocols: [http, https]
      - regex: '^([a-zA-Z]{2,}?\:\/\/[a-zA-Z0-9\-]+(?:\.[a-zA-Z0-9\-]+)*\.[a-zA-Z]{2,6}(?:\/?|(?:\/[\w\-]+)*)(?:\/?|\/\w+\.[a-zA-Z]{2,4}(?:\?[\w]+\=[\w\-]+)?)?(?:\&[\w]+\=[\w\-]+)*)$'
        message: must be a valid web address
      constrains:
      - setting: allow_insecure
        service: lb
        resource_type: load-balancer
        value: true  # turn on HTTP if protocol is HTTPS (provider handles it)
  resources:
    sync-keys:
      type: key-pair
      constrains:
      - setting: private_sync_key
        resource_type: application
        service: master
        attribute: private_key
...

用于部署 WordPress 的 HA 安装的 Heat Blueprint 片段

# A WordPress architecture template
blueprint: &wp
  id: "6fcc7f31-08f8-4664-90e3-58fffc71f773"
  name: Multi-server Wordpress
  services:
    lb:
      component: *loadbalancer
      relations:
        web: #arbitrary name for relationship
          service: web
          interface: http
          attributes:
            inbound: https/443
            algorithm: least_connections
    web:
      component: *wordpress_reference_id  # wordpress component above
      relations: {backend: mysql}
    backend:
      component: *mysql
  options:
    instance_count:
      type: number
      label: Number of Instances
      description: The number of instances for the specified task.
      default: 2
      constrains:
      - {service: web, resource_type: compute, setting: count}
      constraints:
      - greater-than: 1 # this is an HA config
...

部署

部署定义并指向正在运行的应用程序及其运行的基础设施。基本上，它说“我拿了蓝图 X 并将其部署到环境 Y，使用了以下选项”。它将蓝图、部署资源的环境以及此部署的任何其他输入结合起来。

一般形式

  • id - 用户定义的字符串 id
  • name：标识部署的短字符串
  • blueprint：可以是引用（YAML），但现在是 Heat Blueprint 的完整副本。我们将在以后使用 URI 支持引用（git、本地引用等）。
  • environment：与蓝图相同 - 现在我们创建完整副本
  • inputs：- 这些用于设置杠杆和拨号... 有不同的范围：全局、蓝图、服务和提供程序范围。因此，您可以在提供程序级别设置内存大小（即所有服务器都应为 1GB）。或者，服务 X 中的所有服务器应为 1GB，服务 Y 中的所有服务器应为 2GB。
option_foo: bar

使用输入的热蓝图示例

blueprint: 
    blueprint_input_foo: bar 
services: 
    my_db_thang: 
        service_input_foo: baz 
        compute: (filter by resource type!)
        service_resource_input_foo: boo 
   providers: 
       'nova': 
           compute: 
               os: ubuntu

注意：更具体的输入会覆盖更通用的输入（请参阅部署中的 get_setting 代码）

行动项目

  • 确定全局输入的需求。我们真的需要它们吗？或者至少将它们放在“globals”类别中
  • 定义如何在部署中引用蓝图和环境，而无需包含完整副本。引用 UUID？指向 git 或本地引用的文件中的 URL？等等
  • 改进指示生成的值或删除它的语法，并让生成的值成为默认值。或者创建系统，以便将代码包含在蓝图中，用于生成、验证值。请参阅 app.yaml 中的 artifacts 原型。

部署示例

 deployment:
   blueprint:
       name: Simple Wordpress
       wordpress:
         config: *wordpress  # points to wordpress component
         relations: {db: mysql}
   environment:
         name: rackcloudtech-test
         providers:
         - compute:
           vendor: rackspace
           constraints:
           - region: ORD
         - loadbalancer: &rax-lbaas
         - database: &rax-dbaas
         - common:
           vendor: rackspace
           credentials:
           - rackspace:
             ...

在组件和提供程序中带有 provides 和 requires 键的示例部署

 deployment:
   environment:
     providers:
       nova:
         provides:
         - compute
         vendor: rackspace

示例部署

# Actual running app and the parameters supplied when deploying it
deployment:
  blueprint: *wp
  environment: *environment_1000_stag
  inputs:
    instance_count: 4
  resources:
    '0':
      type: server
      provider: nova
      status: up
      service: web
      instance:
        id: 2098383
        flavor: 1
        image: 119
        private_ip: 10.10.1.1
        public_ip: 2.2.2.18
      dns-name: srv1.stabletransit.com
      relations:
        web-backend:
          state: up
    '1':
      type: server
      status: up
      service: web
      provider: nova
      instance:
        id: 2098387
        flavor: 1
        image: 119
        private_ip: 10.10.1.8
        public_ip: 2.2.2.22
      dns-name: srv2.stabletransit.com
      relations:
        web-backend:
          state: up
    '2':
      type: load-balancer
      service: lb
      dns-name: CMDEP32ea304-lb1.rackcloudtech.com
      instance:
        id: 8668444
      relations:
        lb-web:
          state: up
    '3':
      type: database
      service: backend
      provider: databases
      dns-name: CMDEP32ea304-db1.rackcloudtech.com
      instance:
        id: 99958744
        flavor: 1
        disk: 2

与 CFN 术语的比较

已移动到 Heat/Vocabulary

API

另请参阅：Heat/Open_API 以支持此开放 DSL。

从 "https://wiki.openstack.org/w/index.php?title=Heat/DSL&oldid=21554" 检索