OpenStack Orchestration¶ ↑
The mission of the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds.
Heat¶ ↑
Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. A native Heat template format is evolving, but Heat also endeavours to provide compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an OpenStack-native ReST API and a CloudFormation-compatible Query API.
Why ‘Heat’? It makes the clouds rise!
How it works
-
A Heat template describes the infrastructure for a cloud application in a text file that is readable and writable by humans, and can be checked into version control, diffed, &c.
-
Infrastructure resources that can be described include: servers, floating ips, volumes, security groups, users, etc.
-
Heat also provides an autoscaling service that integrates with Ceilometer, so you can include a scaling group as a resource in a template.
-
Templates can also specify the relationships between resources (e.g. this volume is connected to this server). This enables Heat to call out to the OpenStack APIs to create all of your infrastructure in the correct order to completely launch your application.
-
Heat manages the whole lifecycle of the application - when you need to change your infrastructure, simply modify the template and use it to update your existing stack. Heat knows how to make the necessary changes. It will delete all of the resources when you are finished with the application, too.
-
Heat primarily manages infrastructure, but the templates integrate well with software configuration management tools such as Puppet and Chef. The Heat team is working on providing even better integration between infrastructure and software.
Source: OpenStack Wiki
Rackspace Orchestration (Heat) Client¶ ↑
Full Rackspace Orchestration/Heat API Docs
Orchestration Service¶ ↑
Get a handle on the Orchestration service:
irb:
We will use this service
to interact with the Orchestration
resources, stack
, event
, resource
,
and template
Stacks¶ ↑
Get a list of stacks you own:
irb:
Create a new stack
with a Heat
Template (HOT). Here we are using Rackspace's HOT for a
single redis server:
redis_template = File.read("spec/support/redis_template.yml") ===
We get back a JSON blob filled with info about our new stack:
===> {"id"=>"73e0f38a-a9fb-4a4e-8196-2b63039ef31f", "links"=>[{"href"=>"https://iad.orchestration.api.rackspacecloud.com/v1/TENANT_ID/stacks/a_redis_stack/73e0f38a-a9fb-4a4e-8196-2b63039ef31f", "rel"=>"self"}]}
Now that we have the id
of our new stack, we can get a
reference to it using the stack's name
and
id
:
irb:
A stack knows about related events
:
irb:
A stack knows about related resources
:
irb:
You can list, limit, sort stacks based on certain keywords:
** Available keywords:**
-
status
-
name
-
limit
-
marker
-
sort_keys
-
sort_dir
irb:
You can get a stack's template
irb:
You can abandon a stack – essentially, it will delete the stack, but keep the resources around for potential further use:
irb:
You can preview a stack:
irb:
Of course, you can just delete a stack. This deletes associated
resources
(as opposed to abandon
):
irb:
Reload any object by calling reload
on it:
irb:
You can get build information:
irb:
Events¶ ↑
Events
are indexable and can be scoped by stack
:
irb:
Events
can be sorted, limited, etc by passing an hash like so:
service.events.all(stack, limit: 1)
** Available keys: **
-
resource_action
-
resource_status
-
resource_name
-
resource_type
-
limit
-
marker
-
sort_keys
-
sort_dir
They are getable:
irb:
An event
knows about its associated stack
:
irb:
You can list, limit, sort events based on certain keywords:
irb:
An event
has an associated resource
:
irb:
Resource¶ ↑
resources
are indexable:
irb:
A resource
knows about its associated stack
:
irb:
Resource metadata is visible:
irb:
A resource's
template is visible (if one exists)
irb:
Validation¶ ↑
You can validate a Heat template (HOT) before using it:
irb: