• No results found

docs.rackspace.com/api

N/A
N/A
Protected

Academic year: 2021

Share "docs.rackspace.com/api"

Copied!
45
0
0

Loading.... (view fulltext now)

Full text

(1)
(2)

Rackspace Cloud Orchestration Templates Developer Guide

API v1.0 (2015-04-06)

©2015 Rackspace US, Inc.

This document is intended for software developers interested in developing templates for use with Rackspace Cloud Orchestration Services. The document is for informational purposes only and is provided “AS IS.”

RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE ACCURACY OR COM-PLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO MAKE CHANGES TO SPECIFICATIONS AND PROD-UCT/SERVICES DESCRIPTION AT ANY TIME WITHOUT NOTICE. RACKSPACE SERVICES OFFERINGS ARE SUBJECT TO CHANGE WITH-OUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF ANY SERVICES MENTIONED HEREIN. EXCEPT AS SET FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS AND/OR CLOUD TERMS OF SERVICE, RACKSPACE ASSUMES NO LIABILITY WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO ITS SERVICES INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.

Except as expressly provided in any written license agreement from Rackspace, the furnishing of this document does not give you any license to patents, trademarks, copyrights, or other intellectual property.

Rackspace®, Rackspace logo and Fanatical Support® are registered service marks of Rackspace US, Inc. All other product names and trademarks used in this document are for identification purposes only and are property of their respective owners.

(3)

Table of Contents

1. Overview ... 1

1.1. Intended audience ... 1

1.2. Document change history ... 3

1.3. Additional resources ... 3 2. Concepts ... 4 2.1. Template ... 4 2.2. Resource ... 4 2.3. Stack ... 4 3. Introduction to templates ... 5 3.1. What is a template? ... 5 3.2. Defining a template ... 5 3.2.1. Template version ... 6 3.2.2. Description ... 6 3.2.3. Parameter groups ... 7 3.2.4. Parameters ... 7 3.2.5. Parameter constraints ... 8 3.2.6. Resources ... 11 3.2.7. Outputs ... 12 3.2.8. Intrinsic functions ... 13

4. Simple template example ... 17

4.1. A most basic template ... 17

4.2. Template input parameters ... 17

4.2.1. Restricting user input ... 19

4.3. Providing template output ... 20

5. Intermediate template example ... 23

5.1. Intermediate template — version and description ... 26

5.2. Intermediate template — parameter groups ... 27

5.3. Intermediate template — parameters ... 27

5.4. Intermediate template — resources ... 29

5.4.1. ansible_tower resource ... 31

5.5. Intermediate template — outputs ... 37

5.6. Intermediate template — getting started with Ansible Tower ... 38

6. Environment ... 39

6.1. Usage examples ... 39

(4)

List of Examples

(5)

1. Overview

Rackspace Cloud Orchestration is a RESTful API Service that can be used to create and man-age cloud resources (for example: servers + software installation, databases, load balancers, and so forth) by declaring what you want deployed using a simple template language, as described in this guide. Cloud Orchestration is based on the OpenStack open source project named Heat. Rackspace Cloud Orchestration currently supports the HOT (Heat Orchestra-tion Template) syntax specificaOrchestra-tion of Heat.

How Cloud Orchestration works

• A Cloud Orchestration template describes the infrastructure for a cloud application in a YAML or JSON text file that is readable and writable by humans, and can be checked into version control, diffed, and so forth.

• Infrastructure resources that can be described include: servers, volumes, and so forth. • Cloud Orchestration also provides an autoscaling service that integrates with Rackspace

Cloud Auto Scale, so you can include a scaling group as a resource in a template.

• Templates can also specify the relationships between resources (for example this volume is connected to this server). This enables Cloud Orchestration to call out to the Rackspace APIs to create all of your infrastructure in the correct order to completely launch your ap-plication.

• Cloud Orchestration 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. Cloud Orchestration knows how to make the necessary changes. It will also delete all of the resources when you are finished with the application.

• Cloud Orchestration primarily manages infrastructure, but the templates integrate well with software configuration management tools such as Puppet and Chef.

Rackspace Cloud Orchestration Services are available to Rackspace Cloud customers. In-teractions with Rackspace Cloud Orchestration occur programmatically via the Rackspace Cloud Orchestration API as described in the Cloud Orchestration Developer Guide.

We welcome feedback and comments at our community forum: https:// community.rackspace.com/products/f/25/t/3476.

Issues and bug reports can be directed to your support team via ticket, chat, email, or phone.

1.1. Intended audience

This guide is intended to assist support teams, DevOps Engineers, and software developers who want to develop templates for use on the Cloud Orchestration Service. This service is intended to automate tasks in a manner that will speed deployment and provide a method that allows users to deploy a complete application instead of having to manually deploy in-dividual resources. This will remove barriers that have historically prevented customers from deploying resources in the Rackspace Cloud.

(6)

To use the information provided here, you should first have a general understanding of the Cloud Orchestration service. You should also be familiar with:

• Software deployments

• Software installations on server infrastructure

• Infrastructure components such as Cloud Load Balancers and Cloud Databases • JSON and/or YAML data serialization formats

(7)

1.2. Document change history

This version of the Developer Guide replaces and obsoletes all previous versions. The most recent changes are described in the table below:

Revision Date Summary of Changes

April 6, 2015 • Added references to list of supported resources ( http://orchestration.rackspace.com/rax-dox/index.html).

March 5, 2015 • Updated references to Rackspace Cloud Control Panel.

February 27, 2015 • Added description for an intermediate level template in Chapter 5, “Intermediate template example” [23].

February 16, 2015 • Replaced the deprecated 1 GB Performance (and the 2/4/8 GB Performance flavors),

with the corresponding 1 GB General Purpose v1 (and the 2/4/8 GB General Purpose

v1) flavors.

February 10, 2015 • Updated image names as needed.

December 17, 2014 • Updated templates to have latest template version:

heat_template_version: 2014-10-16

October 7, 2014 • Updated doc for initial Unlimited Availability (UA) release.

September 25, 2014 • Updated link to repository with current Rackspace orchestration templates. Refer to Sec-tion 1.3, “Additional resources” [3] for details.

March 21, 2014 • Updated information for parameters (Section 3.2.4, “Parameters” [7]), parameter con-straints (Section 3.2.5, “Parameter constraints” [8]), and resources (Section 3.2.6, “Re-sources” [11]).

• Added (Section 3.2.6.1, “Resource dependencies” [12]). • Replaced standard flavors with performance flavors. • Updated Section 6.1, “Usage examples” [39].

March 13, 2014 • Updated references to CentOS from version 6.4 to 6.5 (since 6.4 is no longer supported). March 12, 2014 • Added link to the community forum in Chapter 1, “Overview” [1].

March 11, 2014 • Initial release.

1.3. Additional resources

You can download the most current versions of templates from https://github.com/ rackspace-orchestration-templates.

You can find information about resources to use in your templates at http:// orchestration.rackspace.com/raxdox/index.html.

For information about Rackspace Cloud products, refer to http://www.rackspace.com/ cloud/.

(8)

2. Concepts

To use Cloud Orchestration effectively, you should understand several key concepts:

2.1. Template

A Cloud Orchestration template is a portable file, written in a user-readable language, that describes how a set of resources should be assembled and what software should be in-stalled in order to produce a working deployment. The template specifies what resources should be used, what attributes can be set, and other parameters that are critical to the successful, repeatable automation of a specific application deployment.

2.2. Resource

A resource is a template artifact that represents some component of your desired architec-ture (a Cloud Server, a group of scaled Cloud Servers, a load balancer, some configuration management system, and so forth).

2.3. Stack

A stack is a group of resources (servers, load balancers, databases, and so forth) combined to fulfill a useful purpose. Based on a template, Heat orchestration engine creates an in-stantiated set of resources (a stack) to run the application framework or component spec-ified (in the template). A stack is a running instance of a template. The result of creating a stack is a deployment of the application framework or component.

(9)

3. Introduction to templates

3.1. What is a template?

A Cloud Orchestration template is a portable file that describes how to configure a set of resources and install the appropriate applications. It describes the best practices for a par-ticular type of deployment.

The template author (Cloud Orchestration architect) makes decisions about the resources required for a deployment and describes how the resources should be configured using YAML or JSON. In the template, the author defines several important pieces of information that drive the installation, such as parameters, resources, and relationships among the re-sources.

Once you have created a template, you can check it into your local github repository if desired. If you would rather not start from scratch, browse the OpenStack github reposi-tory (https://github.com/openstack/heat-templates) or Cloud Orchestration github repos-itory (https://github.com/rackspace-orchestration-templates) for a template that closely matches your needs, clone it to a local repository, and then modify it for your unique archi-tecture.

3.2. Defining a template

Templates are composed of 6 possible sections, some of which are optional as noted. Tem-plates are defined in YAML and follow the structure outlined below:

heat_template_version: 2014-10-16 description:

# a description of the template # optional

parameter_groups:

# a declaration of input parameter groups and order # optional

parameters:

# declaration of input parameters # optional

resources:

# declaration of template resources outputs:

# declaration of output parameters # optional

The description for each section follows below:

heat_template_version This key with value 2014-10-16 indicates that the YAML doc-ument is an Orchestration template of the specified version. description This optional section allows for giving a description of the template, or the

(10)

is optional, it is good practice to provide a brief description for the tem-plate.

parameter_groups This section allows for specifying how the input parameters should be grouped and the order in which to provide the parameters. This section is optional and can be omitted when necessary.

parameters This section allows for specifying input parameters that have to be pro-vided when instantiating the template. The section is optional and can be omitted when no input is required.

resources This section contains the declaration of the resources of the template. This section is mandatory and at least one resource must be defined in any Or-chestration template.

outputs This section allows for specifying output parameters available to users once the template has been instantiated. This section is optional and can be omitted when no output values are required.

These sections are independent from each other and can be arranged in any order, except as described in the following sections. Each section name must be followed immediately by a colon.

Rules for template formatting

• Main template sections (heat_template_version, description, pa-rameter groups, parameters, resources, and outputs) must begin in column 1.

• Sub-sections within a main section must be indented using TAB or spaces to maintain correct indentation to indicate the nesting level.

• The template must be valid YAML.

3.2.1. Template version

The heat_template_version with value 2014-10-16 indicates that the YAML docu-ment is a Cloud Orchestration template of the specified version.

heat_template_version: 2014-10-16

3.2.2. Description

The description section specifies the description of the template and is optional. The value is a collection of YAML strings up to a maximum total length of 4K. This value must be a literal and cannot be defined as the result of a function call or parameter evaluation. An example valid description declaration is:

description: >

Hello world HOT template that just defines a single compute instance. Contains just base features to verify base HOT support.

Note that the right angle bracket (>) after description: allows the description to be continued over multiple lines.

(11)

3.2.3. Parameter groups

The parameter_groups section allows for specifying how the input parameters should be grouped and the order in which to provide the parameters. These groups are typically used to describe expected behavior for downstream user interfaces.

These groups are specified in a list with each group containing a list of associated param-eters. The lists are used to denote the expected order of the paramparam-eters. Each parameter should be associated to a specific group only once using the parameter name to bind it to a defined parameter in the parameters section.

parameter_groups:

- label: <human-readable label of parameter group> description: <description of the parameter group> parameters:

- <param name> - <param name>

label A human-readable label that defines the associated group of parameters. description This attribute allows for giving a human-readable description of the

pa-rameter group.

parameters A list of parameters associated with this parameter group.

param name The name of the parameter that is defined in the associated parame-ters section.

3.2.4. Parameters

The parameters section allows for specifying input parameters that must be provided when instantiating the template. Such parameters are typically used to customize each de-ployment, for example by setting custom user names or passwords or for binding to envi-ronment-specifics like certain images.

Each parameter is specified in a separated nested block with the name of the parameter defined in the first line and additional attributes such as type or default defined as nest-ed elements.

parameters: <param name>:

type: <string | number | json | comma_delimited_list> label: <human-readable name of the parameter>

description: <description of the parameter> default: <default value for parameter> hidden: <true | false>

constraints:

<parameter constraints>

The param name and type attributes are required for each parameter. Other attributes are optional.

(12)

type This attribute specifies the type of parameter. Currently supported types are string, number, comma_delimited_list, or json.

label This optional attribute allows for giving the parameter a human readable name.

description This optional attribute allows for giving a human readable description of the parameter.

default This optional attribute allows for defining a default value for the param-eters that will be used in the case when the parameter is not specified by the user during deployment.

hidden This optional attribute allows for specifying whether the parameters should be hidden when showing information about a stack created from the template at runtime (for example to support hiding passwords that were specified as parameters). If not specified, the default value false will be used.

constraints This optional block allows for specifying additional constraints on the pa-rameter, such as minimum or maximum values for numeric parameters. The following example shows a simple definition of two parameters: user_name and port_number. Note that the description is actually optional, but it is good practice to pro-vide a useful description for each parameter.

parameters: user_name: type: string label: User Name

description: User name to be configured for the application port_number:

type: number label: Port Number

description: Port number to be configured for the web server

3.2.5. Parameter constraints

The constraints block of a parameter definition allows for defining additional validation constraints that apply to the value of the parameter. At instantiation time of the template, user-provided parameter values are validated against those constraints to make sure the values provided match the requirements specified by the template author. Constraints are defined in the form of a bulleted list according to the following syntax:

constraints:

- <constraint type>: <constraint definition> description: <constraint description>

constraint type The constraint type specifies the kind of constraint defined in the current bulleted list item (marked by the dash '-' in the example).

constraint definition This value defines the actual constraint, depending on the constraint type.

(13)

description This optional attribute allows for specifying a concrete description of the current constraint. This text will be presented to the user, for example, when the provided input value for a parameter violates the constraint. If omitted, a default validation message will be presented to the user.

The following example shows the definition of a string parameter with two constraints. Note that while the descriptions for each constraint are optional, it is good practice to pro-vide concrete descriptions so useful messages can be presented to the user at deployment time.

parameters: user_name: type: string label: User Name

description: User name to be configured for the application constraints:

- length: { min: 6, max: 8 }

description: User name must be between 6 and 8 characters - allowed_pattern: "[A-Z]+[a-zA-Z0-9]*"

description: User name must start with an uppercase character The following sections list the supported types of parameter constraints, along with the concrete syntax for each type.

length The length constraint applies to parameters of type string and allows for defining a lower and upper limit for the length of the string value. The syntax for the length constraint is:

length: { min: <lower limit>, max: <upper limit> } It is possible to define a length constraint with only a lower lim-it or an upper limlim-it, however, at least one of min or max must be specified.

range The range constraint applies to parameters of type number and allows for defining a lower and upper limit for the numeric value of the parameter. The syntax of the range constraint is:

range: { min: <lower limit>, max: <upper limit> } It is possible to define a range constraint with only a lower limit or an upper limit, however, at least one of min or max must be specified. The minimum or maximum boundaries are included in the range. For example, the following range constraint would al-low for all numeric values between 0 and 10:

range: { min: 0, max: 10 }

allowed_values The allowed_values constraint applies to parameters of type string or number and allows for specifying a set of possible val-ues for a parameter. At deployment time, the user-provided value for the respective parameter must match one of the elements of the specified list. The syntax of the allowed_values constraint is:

(14)

allowed_values: [ <value>, <value>, ... ]

Alternatively, the YAML bulleted list notation can be used: allowed_values: - <value> - <value> - ... For example: parameters: instance_type: type: string

label: Instance Type

description: Instance type for compute instances constraints:

allowed_values:

- 1 GB General Purpose v1 - 2 GB General Purpose v1 - 4 GB General Purpose v1

allowed_pattern The allowed_pattern constraint applies to parameters of type string and allows for specifying a regular expression that a us-er-provided parameter value must match at deployment. The syn-tax of the allowed_pattern constraint is:

allowed_pattern: <regular expression> For example:

parameters: user_name: type: string label: User Name

description: User name to be configured for the application

constraints:

- allowed_pattern: "[A-Z]+[a-zA-Z0-9]*" description: User name must start with an uppercase character

custom_constraint The custom_constraint constraint adds an extra step of vali-dation, generally to check that the specified resource exists in the backend. Custom constraints get implemented by plug-ins and can provide any kind of advanced constraint validation logic. The syntax of the allowed_pattern constraint is:

custom_constraint: <name> For example:

parameters: key_name type: string

description: SSH key pair constraints:

(15)

3.2.6. Resources

In the resources section, the templates for actual resources that will make up a stack de-ployed from the Orchestration template (for example compute instances, networks, stor-age volumes) are defined. Each resource is defined as a separate block in the resources sec-tion according to the syntax below:

resources: <resource ID>:

type: <resource type> properties:

<property name>: <property value> metadata:

<resource specific metadata>

depends_on: <resource ID or list of ID> update_policy: <update policy>

deletion_policy: <deletion policy>

resource ID A resource block is headed by the resource ID, which must be unique within the resource section of a template.

type This attribute specifies the type of resource, such as OS::Nova::Server.

Note

To find the various types of supported template re-sources, you can either look up the information at http://orchestration.rackspace.com/raxdox/index.html, or use the List resource types API operation (GET / resource_types). The cURL command for this operation is (make sure to use the correct values for your X-Auth-Token and tenant_id):

curl -i -X GET -H 'X-Auth-Token: xxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' https://dfw.orchestration. rackspacecloud.com/v1/<tenant_id>/resource_types To find the properties for a resource type, use the Show resource data API operation.

properties This optional section contains a list of resource-specific properties. The property value can be provided in place, or can be provided via a function (see Section 3.2.8, “Intrinsic functions” [13]). Depend-ing on the type of resource, the resource block might include more resource-specific metadata. Below is an example of a simple com-pute resource definition with some property values fixed:

resources: my_instance:

type: OS::Nova::Server properties:

(16)

image: CentOS 6 (PV)

metadata This optional section contains resource type specific metadata. depends_on This optional attribute allows for specifying dependencies of the

current resource on one or more other resources. Refer to Sec-tion 3.2.6.1, “Resource dependencies” [12] for details.

update_policy This optional attribute allows for specifying an update policy for the resource in the form of a nested dictionary (name-value pairs). Whether update policies are supported and what the exact seman-tics are depends on the type of the current resource.

deletion_policy This optional attribute allows for specifying a deletion policy for the resource (one of the values Delete, Retain, or Snapshot). The type of deletion policy supported depends on the type of the current resource.

3.2.6.1. Resource dependencies

Using the depends_on attribute within a resource section, it is possible to define a depen-dency between a resource and one or more other resources. This dependepen-dency means that the dependent resource must wait for another resource (or resources) to be created before being created itself.

If a resource depends on just one other resource, the ID of the other resource is specified as value of the depends_on attribute as shown in the following example:

resources: server1: type: OS::Nova::Server depends_on: server2 server2: type: OS::Nova::Server

If a resource depends on more than one other resource, the value of the depends_on at-tribute is specified as a list of resource IDs as shown in the following example:

resources: server1:

type: OS::Nova::Server

depends_on: [ server2, server3 ] server2:

type: OS::Nova::Server server3:

type: OS::Nova::Server

3.2.7. Outputs

In the outputs section, any output parameters that should be available to the user can be defined. Typically, this would be parameters such as IP addresses of deployed instances, or URLs of web applications deployed as part of a stack. Each output parameter is defined as a separate block within the outputs section according to the following syntax:

(17)

<parameter name>:

description: <description> value: <parameter value>

parameter name An output parameter block is headed by the output parameter name, which must be unique within the outputs section of a template. description This element gives a short description of the output parameter. value This element specifies the parameter value of the output

parame-ter. Typically, this will be resolved by means of a function, for example by getting an attribute value of one of the stack's resources (see also Section 3.2.8, “Intrinsic functions” [13]).

The example below shows how the IP address of a compute resource can be defined as an output parameter.

outputs: instance_ip:

description: IP address of the deployed compute instance value: { get_attr: [my_instance, accessIPv4] }

You will be able to view the value for the output parameter defined above when you view the response received from calling the API operation Get stack data. Refer to "Step 8. Show Stack Details" in the Getting Started Guide for an example.

3.2.8. Intrinsic functions

Cloud Orchestration provides a set of intrinsic functions that can be used inside Cloud Or-chestration templates to perform specific tasks, such as getting the value of a resource at-tribute at runtime. A definition of all intrinsic functions available in Cloud Orchestration is given below.

3.2.8.1. get_param

The get_param function allows for referencing an input parameter of a template from anywhere within a template. At runtime, it will be resolved to the value provided for this in-put parameter. The syntax of the get_param function is as follows:

get_param: <parameter name>

The parameter name of the input parameter to be resolved is given as a single param-eter to this function. A sample use of this function in context of a resource definition is shown below:

parameters: instance_type: type: string

description: Instance type to be used. resources:

my_instance:

type: OS::Nova::Server properties:

(18)

3.2.8.2. get_attr

The get_attr function allows for referencing an attribute of a resource. At runtime, it will be resolved to the value of an attribute of a resource instance created from the respective resource definition of the template. The syntax of the get_attr function is as follows: get_attr: [ <resource ID>, <attribute name> ]

resource ID This parameter specifies the resource the attribute of which shall be resolved. This resource must be defined within the resources section of the template (see Section 3.2.6, “Resources” [11]).

attribute name This parameter specifies the attribute to be resolved.

An example of using the get_attr function is shown below to set value to the acces-sIPv4 address of the my_instance resource:

resources: my_instance: type: OS::Nova::Server # ... outputs: instance_ip:

description: IP address of the deployed compute instance value: { get_attr: [my_instance, accessIPv4] }

3.2.8.3. get_resource

The get_resource function allows for referencing another resource within the same tem-plate. At runtime, it will be resolved to the reference ID of the resource, which is resource type specific. For example, a reference to a floating IP resource will return the respective IP address at runtime. The syntax of the get_resource function is as follows:

get_resource: <resource ID>

resource ID The resource ID of the referenced resources as used in the current template is specified as the single parameter to the get_resource func-tion.

An example of using the get_attr function is shown below to set the handle property to the value of the wait_condition_handle resource:

wait_condition:

type: "OS::Heat::SwiftSignal" properties:

handle: { get_resource: wait_condition_handle } timeout: 1800

wait_condition_handle:

type: "OS::Heat::SwiftSignalHandle"

3.2.8.4. str_replace

The str_replace function allows for dynamically constructing strings by providing a tem-plate string with placeholders and a list of mappings to assign values to those placeholders

(19)

at runtime. The placeholders are replaced with mapping values wherever a mapping key exactly matches a placeholder. The syntax of the str_replace function is as follows: str_replace:

template: <template string> params: <parameter mappings>

template The template argument defines the template string that contains placehold-ers which will be substituted at runtime.

params The params argument provides parameter mappings in the form of a dictio-nary that will be used for placeholder substitution in the template string at runtime. Within parameter mappings one can make use of other func-tions (for example get_attr to use resource attribute values) for template substitution.

The example below shows a simple use of the str_replace function in the outputs section of a template to build a URL for logging into a deployed ap-plication:

resources: my_instance:

type: OS::Nova::Server

# general metadata and properties ... outputs:

Login_URL:

description: The URL to log into the deployed application value:

str_replace:

template: http://host/MyApplication params:

host: { get_attr: [ my_instance, accessIPv4 ] }

The str_replace works like a simple substitution. It uses the params sec-tion to replace corresponding strings in the template secsec-tion. So in the ex-ample above, the host portion of the URL (http://host/MyApplication) is re-placed by value returned from calling the get_attr function, which is the IP address (accessIPv4) of the server instance (my_instance).

The str_replace function can also be used for constructing bigger chunks of text such as scripts for initializing compute instances, as shown in the exam-ple below:

parameters: DBRootPassword: type: string

description: Root password for MySQL hidden: true resources: my_instance: type: OS::Nova::Server properties: # general properties ... user_data: str_replace: template: |

(20)

#!/bin/bash

echo "Hello world"

echo "Setting MySQL root password"

mysqladmin -u root password $db_rootpassword # do more things ...

params:

$db_rootpassword: { get_param: DBRootPassword } In the example above, assume that MySQL is being configured on a compute instance and the root password is going to be set based on a user-provided parameter. The script for doing this is provided as user_data to the com-pute instance, leveraging the str_replace function.

(21)

4. Simple template example

This chapter gives an introduction on how to write HOT (Heat Orchestration Template) templates, starting from very basic steps and then going into more and more detail by means of examples. A detailed specification of HOT can be found in Chapter 3, “Introduc-tion to templates” [5].

4.1. A most basic template

The most basic template possible may contain only a single resource definition using only predefined properties (along with the mandatory Heat template version tag). For example, the template below could be used to simply deploy a single compute instance:

heat_template_version: 2014-10-16

description: Simple template to deploy a single compute instance resources: my_instance: type: OS::Nova::Server properties: key_name: my_key image: CentOS 6 (PV)

flavor: 1 GB General Purpose v1

Each HOT template has to include the heat_template_version key with value

'2014-10-16' (the current version of HOT). While the description is optional, it is good prac-tice to include some useful text that describes what users can do with the template. In case you want to provide a longer description that does not fit on a single line, you can provide multi-line text in YAML, for example:

description: >

This is how you can provide a longer description of your template that goes over several lines.

The resources section is required and must contain at least one resource definition. In the example above, a compute instance is defined with hard-coded values for the key_name, image, and flavor parameters.

Note that all those elements – a key-pair with the given name, the image, and the flavor – must exist in the environment where the template is used. Typically a template is made more easily reusable, however, by defining a set of input parameters rather than hard-cod-ing such values.

4.2. Template input parameters

Input parameters defined in the parameters section of an Cloud Orchestration template allow users to customize a template during deployment (see also Section 3.2.4, “Parame-ters” [7]). For example, this allows for providing custom key-pair names or image IDs to be used for a deployment. From a template author's perspective, this helps to make a tem-plate more easily reusable by avoiding hard-coded assumptions.

(22)

Continuing with the example used above, it makes sense to allow users to provide their cus-tom key-pairs, to provide their own image, and to select a flavor for the compute instance. This can be achieved by extending the initial template as follows:

heat_template_version: 2014-10-16

description: Simple template to deploy a single compute instance parameters:

key_name: type: string

description: Name of key-pair to be used for compute instance image_id:

type: string

description: Image to be used for compute instance instance_type:

type: string

description: Type of instance (flavor) to be used resources:

my_instance:

type: OS::Nova::Server properties:

key_name: { get_param: key_name } image: { get_param: image_id }

flavor: { get_param: instance_type }

In the example above, three input parameters have been defined that must be provid-ed by the user at deployment. The fixprovid-ed values for the respective resource properties have been replaced by references to the corresponding input parameters by means of the get_param function (see also Section 3.2.8, “Intrinsic functions” [13]).

You can also define default values for input parameters which will be used in case the us-er does not provide the respective parametus-er during deployment. For example, the follow-ing definition for the instance_type parameter would select the 1 GB General Pur-pose v1 flavor by default unless specified otherwise by the user:

parameters: instance_type: type: string

description: Type of instance (flavor) to be used default: 1 GB General Purpose v1

Another option that can be specified for a parameter is to hide its value when users request information about a stack deployed from a template. This is achieved by the hidden at-tribute and useful, for example, when requesting passwords as user input:

parameters:

database_password: type: string

description: Password to be used for database hidden: true

This extends our example as follows: heat_template_version: 2014-10-16

(23)

parameters: key_name: type: string

description: Name of key-pair to be used for compute instance image_id:

type: string

description: Image to be used for compute instance instance_type:

type: string

description: Type of instance (flavor) to be used default: 1 GB General Purpose v1

database_password:

type: string

description: Password to be used for database hidden: true

resources: my_instance:

type: OS::Nova::Server properties:

key_name: { get_param: key_name } image: { get_param: image_id }

flavor: { get_param: instance_type }

4.2.1. Restricting user input

In some cases you might want to restrict the values of input parameters that users can sup-ply. For example, you might know that the software running in a compute instance needs a certain amount of resources, so you might want to restrict the instance_type parameter in-troduced above. Parameters in HOT templates can be restricted by adding a constraints sec-tion (see also Section 3.2.5, “Parameter constraints” [8]). For example, the following would allow only three values to be provided as input for the instance_type parameter:

parameters: instance_type: type: string

description: Type of instance (flavor) to be used default: 1 GB General Purpose v1

constraints:

- allowed_values: [ 1 GB General Purpose v1, 2 GB General Purpose v1, 4 GB General Purpose v1 ]

description: Value must be one of 1 GB General Purpose v1, 2 GB General Purpose v1, or 4 GB General Purpose v1.

The constraints section allows for defining a list of constraints that must all be fulfilled by user input. For example, the following list of constraints could be used to clearly specify format requirements on a password to be provided by users:

parameters:

database_password: type: string

description: Password to be used for database hidden: true

constraints:

- length: { min: 6, max: 8 }

description: Password length must be between 6 and 8 characters. - allowed_pattern: "[a-zA-Z0-9]+"

(24)

description: Password must consist of characters and numbers only. - allowed_pattern: "[A-Z]+[a-zA-Z0-9]*"

description: Password must start with an uppercase character. This now extends our example as shown below:

heat_template_version: 2014-10-16

description: Simple template to deploy a single compute instance parameters:

key_name: type: string

description: Name of key-pair to be used for compute instance image_id:

type: string

description: Image to be used for compute instance instance_type:

type: string

description: Type of instance (flavor) to be used default: 1 GB General Purpose v1

constraints:

- allowed_values: [ 1 GB General Purpose v1, 2 GB General Purpose v1, 4 GB General Purpose v1 ]

description: Value must be one of 1 GB General Purpose v1, 2 GB General Purpose v1, or 4 GB General Purpose v1.

database_password: type: string

description: Password to be used for database hidden: true

constraints:

- length: { min: 6, max: 8 }

description: Password length must be between 6 and 8 characters. - allowed_pattern: "[a-zA-Z0-9]+"

description: Password must consist of characters and numbers only. - allowed_pattern: "[A-Z]+[a-zA-Z0-9]*"

description: Password must start with an uppercase character.

resources: my_instance:

type: OS::Nova::Server properties:

key_name: { get_param: key_name } image: { get_param: image_id }

flavor: { get_param: instance_type }

Note that you can define multiple constraints of the same type. Especially in the case of al-lowed patterns this not only allows for keeping regular expressions simple and maintain-able, but also for keeping error messages to be presented to users precise.

4.3. Providing template output

In addition to template customization through input parameters, you will typically want to provide outputs to users, which can be done in the outputs section of a template (see al-so Section 3.2.7, “Outputs” [12]).

For example, the IP address by which the instance defined in the example above can be ac-cessed (instance_ip) should be provided to users. Otherwise, users would have to look

(25)

it up themselves. The definition for providing the IP address of the compute instance as an output is shown below:

outputs: instance_ip:

description: The IP address of the deployed instance value: { get_attr: [my_instance, accessIPv4] }

Output values are typically resolved using intrinsic function such as the get_attr function in the example above (see also Section 3.2.8, “Intrinsic functions” [13]).

You can look up the names for the supported attributes for resources (for example ac-cessIPv4 in the example above) here: http://docs.openstack.org/developer/heat/ template_guide/index.html.

Outputs can be viewed using the Get stack data API call (GET /stacks{/stack_name}{/ stack_id}) after the stack is created. Refer to http://docs.rackspace.com/orchestration/api/ v1/orchestration-getting-started/content/Show_Stack_Details.html for an example.

Our completed simple template example is shown below: heat_template_version: 2014-10-16

description: Simple template to deploy a single compute instance parameters:

key_name: type: string

description: Name of key-pair to be used for compute instance image_id:

type: string

description: Image to be used for compute instance instance_type:

type: string

description: Type of instance (flavor) to be used default: 1 GB General Purpose v1

constraints:

- allowed_values: [ 1 GB General Purpose v1, 2 GB General Purpose v1, 4 GB General Purpose v1 ]

description: Value must be one of 1 GB General Purpose v1, 2 GB General Purpose v1, or 4 GB General Purpose v1.

database_password: type: string

description: Password to be used for database hidden: true

constraints:

- length: { min: 6, max: 8 }

description: Password length must be between 6 and 8 characters. - allowed_pattern: "[a-zA-Z0-9]+"

description: Password must consist of characters and numbers only. - allowed_pattern: "[A-Z]+[a-zA-Z0-9]*"

description: Password must start with an uppercase character. resources:

my_instance:

type: OS::Nova::Server properties:

key_name: { get_param: key_name } image: { get_param: image_id }

(26)

flavor: { get_param: instance_type }

outputs: instance_ip:

description: The IP address of the deployed instance value: { get_attr: [my_instance, accessIPv4] }

(27)

5. Intermediate template example

This chapter describes how to write a more complex, intermediate level HOT (Heat Orches-tration Template) template. This template deploys the free version of Ansible Tower onto a single Linux server.

The entire intermediate template is shown below.

This template can be used as a standalone template for creating a stack. The file is named ansible-tower.yaml template and can be found in the repo directory at https://github.com/ rackspace-orchestration-templates/ansible-tower. You will also find other files in the

repo directory that are used to support the template in the Rackspace Cloud Control Panel framework. (Navigate to https://mycloud.rackspace.com/cloud/<account_Id>/ servers#stacks/create, where account_Id is your Rackspace Cloud Account number.)

Example 5.1. Intermediate level template that deploys Ansible Tower

heat_template_version: 2014-10-16 description: |

A template that deploys Ansible Tower onto a single Linux server. parameter_groups:

- label: Server Settings parameters:

- flavor - image

- label: rax-dev-params

# These are parameters that will not be displayed in the portal. The purpose # of these parameters is for users who are developing or testing newer or # different setups. If any of these parameters are changed, there is a good # chance this stack will fail to properly deploy.

parameters:

- ansible_tower_tarball - server_name

parameters: flavor:

label: Server Size description: |

Nova Cloud Server flavor to use. The size is based on the amount of RAM for the provisioned server.

type: string

default: 1 GB General Purpose v1 constraints: - allowed_values: - 1 GB General Purpose v1 - 2 GB General Purpose v1 - 4 GB General Purpose v1 - 8 GB General Purpose v1 - 15 GB I/O v1 - 30 GB I/O v1 - 1GB Standard Instance - 2GB Standard Instance

(28)

- 4GB Standard Instance - 8GB Standard Instance - 15GB Standard Instance - 30GB Standard Instance

description: must be a valid Nova Cloud Server flavor. image:

label: Operating System description: |

Server image used for all servers that are created as a part of this deployment

type: string

default: Ubuntu 14.04 LTS (Trusty Tahr) (PV) constraints:

- allowed_values:

- Ubuntu 12.04 LTS (Precise Pangolin) (PVHVM) - Ubuntu 14.04 LTS (Trusty Tahr) (PV)

description: Must be a supported operating system. server_name:

label: Server Hostname

description: The instance name type: string

default: ansible-tower ansible_tower_tarball: label: Ansible Tarball

description: Location of the Ansible Tower installer type: string default: | http://releases.ansible.com/ansible-tower/setup/ansible-tower-setup-latest.tar.gz resources: wait_condition: type: "OS::Heat::SwiftSignal" properties:

handle: { get_resource: wait_condition_handle } timeout: 1800 wait_condition_handle: type: "OS::Heat::SwiftSignalHandle" ssh_key: type: "OS::Nova::KeyPair" properties:

name: { get_param: "OS::stack_id" } save_private_key: true

# Random password generation ansible_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits postgres_admin_pass: type: "OS::Heat::RandomString" properties:

(29)

length: 16 sequence: lettersdigits redis_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits munin_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits ansible_tower: type: "OS::Nova::Server" properties:

config_drive: "true" # required for wait_condition user_data_format: RAW # required for wait_condition key_name: { get_resource: ssh_key }

flavor: { get_param: flavor } image: { get_param: image } name: { get_param: server_name } metadata:

rax-heat: { get_param: "OS::stack_id" } user_data: str_replace: template: | #!/bin/bash -v set -e # Install dependencies apt-get update

apt-get install dev yaml paramiko python-jinja2 python-pip -y

pip install ansible

# Pull and extract the installer wget -ct0 %ansible_tower_tarball%

tar xzf ansible-tower-setup-latest.tar.gz cd ansible-tower*

# Write out options file

echo "admin_password: %ansible_admin_pass% database: internal

munin_password: %munin_admin_pass% pg_password: %postgres_admin_pass% primary_machine: localhost

redis_password: %redis_admin_pass%" > tower_setup_conf.yml # Write out the inventory file

echo "[primary] localhost [all:children] primary" > inventory

# Copy everything to working directory and install ./setup.sh

ufw allow 443

wc_notify --data-binary '{"status": "SUCCESS"}'

params:

(30)

"%ansible_admin_pass%": { get_attr: [ansible_admin_pass, value] } "%postgres_admin_pass%": { get_attr: [postgres_admin_pass,

value] }

"%redis_admin_pass%": { get_attr: [redis_admin_pass, value] } "%munin_admin_pass%": { get_attr: [munin_admin_pass, value] } "%server_name%": { get_param: server_name }

wc_notify: { get_attr: ['wait_condition_handle', 'curl_cli'] } outputs:

private_key:

description: SSH Private Key

value: { get_attr: [ssh_key, private_key] } ansible_url:

value:

str_replace:

template: "https://%server_ip%" params:

"%server_ip%": { get_attr: [ ansible_tower, accessIPv4 ] } description: Tower URL

server_ip:

value: { get_attr: [ ansible_tower, accessIPv4 ] } description: Server IP

ansible_username: value: admin

description: Admin Username ansible_password:

value: { get_attr: [ansible_admin_pass, value] } description: Admin Password

5.1. Intermediate template — version and

descrip-tion

Each HOT template must include the heat_template_version key with value 2014-10-16 (the current version of HOT is recommended). A detailed specification of HOT can be found in Chapter 3, “Introduction to templates” [5].

While the description is optional, it is good practice to include some useful text that de-scribes what users can do with the template.

heat_template_version: 2014-10-16 description: |

A template that deploys Ansible Tower onto a single Linux server.

The vertical bar (|) that begins the description shown in the previous example enables you to use multi-line text in the description. The vertical bar (|) syntax preserves the newlines that are entered in the description text.

As an alternative, you can provide multi-line text in YAML for the description by using the greater than character (>), for example:

(31)

description: >

This is how you can provide a longer description of your template that goes over several lines.

The greater than character (>) syntax turns newlines in the description text into spaces. This installation deploys the free version of Ansible Tower, and is limited to 10 machines.

5.2. Intermediate template — parameter groups

The template then defines two parameter groups: parameter_groups:

- label: Server Settings parameters:

- flavor - image

- label: rax-dev-params

# These are parameters that will not be displayed in the portal. The purpose # of these parameters is for users who are developing or testing newer or # different setups. If any of these parameters are changed, there is a good # chance this stack will fail to properly deploy.

parameters:

- ansible_tower_tarball - server_name

The optional parameter_groups section allows for specifying how the input parameters should be grouped and the order in which to provide the parameters.

The first parameter group has the label Server Settings, which will be displayed in the GUI (such as the Rackspace Cloud Control Panel), if the template is used in a portal or com-mand line interface. Two parameters are defined in the Server Settings group: fla-vor and image. Flavor specifies the combination of cpu time and memory allocated for the server and image specifies the operating system for the server.

The second parameter group has the label rax-dev-params. This label is used for param-eters that are controlled by the Cloud Control Panel. None of these paramparam-eters will be dis-played in the Cloud Control Panel.

The second parameter group defines two parameters. The parameter

ansible_tower_tarball is used to store the URL for the Ansible install tar file. The sec-ond parameter server_name is the name of the server where you install Ansible.

The parameters listed in these two groups are defined in the parameters section, which is described next.

5.3. Intermediate template — parameters

The template then defines parameters.

parameters: flavor:

label: Server Size description: |

(32)

Nova Cloud Server flavor to use. The size is based on the amount of RAM for the provisioned server.

type: string

default: 1 GB General Purpose v1 constraints: - allowed_values: - 1 GB General Purpose v1 - 2 GB General Purpose v1 - 4 GB General Purpose v1 - 8 GB General Purpose v1 - 15 GB I/O v1 - 30 GB I/O v1 - 1GB Standard Instance - 2GB Standard Instance - 4GB Standard Instance - 8GB Standard Instance - 15GB Standard Instance - 30GB Standard Instance

description: must be a valid Rackspace Cloud Server flavor. image:

label: Operating System description: |

Server image used for all servers that are created as a part of this deployment

type: string

default: Ubuntu 14.04 LTS (Trusty Tahr) (PV) constraints:

- allowed_values:

- Ubuntu 12.04 LTS (Precise Pangolin) (PVHVM) - Ubuntu 14.04 LTS (Trusty Tahr) (PV)

description: Must be a supported operating system. server_name:

label: Server Hostname

description: The instance name type: string

default: ansible-tower ansible_tower_tarball: label: Ansible Tarball

description: Location of the Ansible Tower installer type: string

default: |

http://releases.ansible.com/ansible-tower/setup/ansible-tower-setup-latest.tar.gz

•flavor

A flavor is a hardware configuration for a server. Each flavor is a unique combination of disk space and memory capacity. The flavor label is Server Size and a description is provided. The type of a flavor is string. A default is provided (1 GB General Purpose v1) so the template can be run without a GUI, in which case, the default is used.

The constraints section lists the valid allowed values for flavors, from which the GUI user can choose. A description is provided for the allowed values.

(33)

The image is the Operating System image to install on the server. The image label is Operating System and a description is provided. The type of an image is string. A default is provided (Ubuntu 14.04 LTS (Trusty Tahr) (PV)) so the template can be run without a GUI, in which case, the default is used.

The constraints section lists the valid allowed values for images, from which the GUI user can choose. A description is provided for the allowed values.

•server_name

The server_name is the hostname of the server. The label is Server Hostname and a description is provided. The type of the parameter is string. A default is provid-ed (ansible-tower) so the template can be run without a GUI, in which case, the de-fault is used.

•ansible_tower_tarball

The ansible_tower_tarball specifies the URL for the Ansible Tower installer. The label is Ansible Tarball and a description is provided. The type of the parameter is string. A default is provided (ansible-tower) so the template can be run without a GUI, in which case, the default is used.

5.4. Intermediate template — resources

The resources section is required and must contain at least one resource definition. resources:

wait_condition:

type: "OS::Heat::SwiftSignal" properties:

handle: { get_resource: wait_condition_handle } timeout: 1800 wait_condition_handle: type: "OS::Heat::SwiftSignalHandle" ssh_key: type: "OS::Nova::KeyPair" properties:

name: { get_param: "OS::stack_id" } save_private_key: true

# Random password generation ansible_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits postgres_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits

(34)

redis_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits munin_admin_pass: type: "OS::Heat::RandomString" properties: length: 16 sequence: lettersdigits . . .

Note

The ansible_tower resource is described in Section 5.4.1, “ansible_tower re-source” [31].

The template defines the following resources. •wait_condition

This resource signals completion and optionally uploads data for an event. The type of the resource is OS::Heat::SwiftSignal.

This resource has the following properties. •handle

The value of the handle is set by calling the get_resource function on the wait_condition_handle resource.

•timeout

The timeout is set to 1800 and represents the maximum number of seconds to wait for the resource to signal completion. Once the timeout is reached, creation of the sig-nal resource will fail.

•wait_condition_handle

This resource specifies where to upload data for an event. The type of the resource is OS::Heat::SwiftSignalHandle.

•ssh_key

This resource enables you to create Nova key pairs. The type of the resource is OS::Nova::KeyPair. The resource has two properties.

•name

This property is initialized by calling the function get_param to get the value of the parameter OS::stack_id.

(35)

This property is set to true to have the system remember a generated private key. •ansible_admin_pass

This property stores the Ansible Administrator password.

The type of the resource is OS::Heat::RandomString. The resource has two proper-ties.

•length

This property specifies the length of the string (16). •sequence

This property specifies the sequence of characters allowed in the strings (in this case, both letters and digits).

The following resources share the same length and sequence properties. •postgres_admin_pass

The PostgreSQL Administrator password. •redis_admin_pass

The Redis Administrator password. •munin_admin_pass

The Munin Administrator password.

The password used by Tower superusers to access the Munin-based monitoring of your Tower server.

The previous Admin passwords are used internally to Ansible Tower and not needed by the Administrator at runtime. Therefore, they are normally autogenerated as a random value (OS::Heat::RandomString).

5.4.1. 

ansible_tower

resource

Since the ansible_tower resource does much of the work for this template, it is de-scribed in this separate section.

. . . ansible_tower: type: "OS::Nova::Server" properties:

config_drive: "true" # required for wait_condition user_data_format: RAW # required for wait_condition key_name: { get_resource: ssh_key }

(36)

flavor: { get_param: flavor } image: { get_param: image } name: { get_param: server_name } metadata:

rax-heat: { get_param: "OS::stack_id" } user_data: str_replace: template: | #!/bin/bash -v set -e # Install dependencies apt-get update

apt-get install dev yaml paramiko python-jinja2 python-pip -y

pip install ansible

# Pull and extract the installer wget -ct0 %ansible_tower_tarball%

tar xzf ansible-tower-setup-latest.tar.gz cd ansible-tower*

# Write out options file

echo "admin_password: %ansible_admin_pass% database: internal

munin_password: %munin_admin_pass% pg_password: %postgres_admin_pass% primary_machine: localhost

redis_password: %redis_admin_pass%" > tower_setup_conf.yml # Write out the inventory file

echo "[primary] localhost [all:children] primary" > inventory

# Copy everything to working directory and install ./setup.sh

ufw allow 443

wc_notify --data-binary '{"status": "SUCCESS"}'

params:

"%ansible_tower_tarball%": { get_param: ansible_tower_tarball } "%ansible_admin_pass%": { get_attr: [ansible_admin_pass, value] } "%postgres_admin_pass%": { get_attr: [postgres_admin_pass,

value] }

"%redis_admin_pass%": { get_attr: [redis_admin_pass, value] } "%munin_admin_pass%": { get_attr: [munin_admin_pass, value] } "%server_name%": { get_param: server_name }

wc_notify: { get_attr: ['wait_condition_handle', 'curl_cli'] } The resource type is OS::Nova::Server, which provides a Nova Cloud Server for in-stalling Ansible Tower.

The properties for the resource are as follows: •config_drive

When set to True, this property enables the configuration drive on the server.

This setting enables OpenStack to write metadata to a special configuration drive that attaches to the instance when it boots. The instance can mount this drive and read files from it to get information that is normally available through the metadata service.

(37)

•user_data_format

This property specifies how the user_data should be formatted for the server. Setting the property to RAW passes the user_data to Nova unmodified.

•key_name

This property specifies the name of the keypair to inject into the server.

The value is set by calling the get_resource function on the ssh_key resource. •flavor

This property represents a hardware configuration for a server. Each flavor is a unique combination of disk space and memory capacity.

The value is set by calling the get_param function on the flavor parameter. •image

This property represents the Operating System image to install on the server. The value is set by calling the get_param function on the image parameter. •name

This property represents the hostname of the server.

The value is set by calling the get_param function on the server_name parameter. •metadata

This property sets arbitrary key/value metadata to store for this server.

The value for the rax-heat metadata key is set by calling the get_param function on the OS::stack_id parameter to store the stack ID in the metadata.

•user_data

This property sets a user data bash script to be executed by cloud-init. This property en-ables a user to configure the new server as desired by providing this script to be run by cloud-init when the server is being initialized. For information and examples for using cloud-init, see http://cloudinit.readthedocs.org/en/latest/topics/capabilities.html.

The str_replace function enables dynamically constructing strings by providing a tem-plate string with placeholders and a list of mappings (specified by params) to assign val-ues to those placeholders at runtime. This is used to dynamically configure the user da-ta script. For more information about the str_replace function, see Section 3.2.8.4, “str_replace” [14].

The script performs the following: •#!/bin/bash -v

This comment causes the script to be executed by the bash shell with the verbose flag set.

(38)

•set -e

This shell command causes the script to exit immediately if a command exits with a non-zero status.

•# Install dependencies

Comment that package dependencies will be installed (in the next line). •apt-get update

Downloads the package lists from the repositories and "updates" the lists with informa-tion on the newest versions of packages and their dependencies.

•apt-get install dev yaml paramiko python-jinja2 python-pip -y

Installs the package dependencies for Ansible Tower. •pip install ansible

Use pip to install Ansible.

•# Pull and extract the installer

Comment that the Ansible installer will be downloaded and extracted (in the next lines).

•wget -ct0 %ansible_tower_tarball%

Downloads the Ansible installer (whose location is specified by the parm %ansible_tower_tarball%).

The %variable% notation is used here because of the string replace function explained earlier. Variables are wrapped with %% to have a higher probability that the variable name being replaced doesn't accidentally appear in other places. For example, if a vari-able were named "test" instead of "%test%", the word "test" would be acted on in the string replace if it appeared anywhere in the script.

•tar xzf ansible-tower-setup-latest.tar.gz Extract the Ansible installer.

•cd ansible-tower*

Change directory to the ansible-tower* directory. •# Write out options file

Comment to write out the options file (in the next lines). •echo "admin_password: %ansible_admin_pass%

(39)

Begin writing out the values for the options file, starting with the ansible_admin_pass (Ansible Administrator Password), set to the value of the %ansible_admin_pass% param.

•database: internal

Set the database option to be internal. •munin_password: %munin_admin_pass%

Set the munin_password option to the value of the %munin_admin_pass% param. •pg_password: %postgres_admin_pass%

Set the pg_password option to the value of the %postgres_admin_pass% param. •primary_machine: localhost

Set the primary_machine option to the value localhost.

•redis_password: %redis_admin_pass%" > tower_setup_conf.yml Set the redis_password option to the value of the %redis_admin_pass% re-source, and write the options to the tower_setup_conf.yml configuration file. •# Write out the inventory file

Comment to write out the inventory file.

This is an inventory file required by the Ansible Tower installer. The Ansible Tower in-staller runs a series of Ansible playbooks, and the inventory file determines the host where those scripts run. The template writes out this file manually using the multi-line echo command, as follows:

•echo "[primary] •localhost

•[all:children]

•primary" > inventory

This completes writing out the inventory file.

•# Copy everything to working directory and install Comment to copy and install in the next line

•./setup.sh

Execute the setup script to copy and install Ansible Tower. •ufw allow 443

(40)

Tells the firewall to allow port 443 (since SSL is enabled for our clients' security). •wc_notify --data-binary '{"status": "SUCCESS"}'

Signals success by adding the option --data-binary '{"status": "SUC-CESS"}'.

This success message tells the Swift Signal handler resource to complete successful-ly, allowing the stack to successfully complete and the stack_status field to show CREATE_COMPLETE.

If the script reached this line without exiting, the script succeeded. Notice that wc_notify is a param that is replaced in the script (see the params section below) by calling the get_attr function on the wait_condition_handle resource, spec-ifying the curl_cli attribute. The curl_cli attribute provides the curl CLI com-mand prefix, which is then used for signalling handle completion using the –da-ta-binary ‘{“status”: “SUCCESS”}’ option. Otherwise, the script did not exe-cute this line because it exited and was not successful.

The params section specifies the values for each of the replacement mappings in the template section for str_replace:

•"%ansible_tower_tarball%": { get_param: ansible_tower_tarball } Sets the value for the %ansible_tower_tarball% placeholder to the value re-turned from calling the function get_parm on the ansible_tower_tarball pa-rameter.

•"%ansible_admin_pass%": { get_attr: [ansible_admin_pass, val-ue] }

Sets the value for the %ansible_admin_pass% placeholder to the value returned from calling the function get_attr to get the value of the ansible_admin_pass attribute.

•"%postgres_admin_pass%": { get_attr: [postgres_admin_pass, val-ue] }

Sets the value for the %postgres_admin_pass% placeholder to the val-ue returned from calling the function get_attr to get the valval-ue of the postgres_admin_pass attribute.

•"%redis_admin_pass%": { get_attr: [redis_admin_pass, value] } Sets the value for the %redis_admin_pass% placeholder to the value returned from calling the function get_attr to get the value of the redis_admin_pass at-tribute.

•"%munin_admin_pass%": { get_attr: [munin_admin_pass, value] } Sets the value for the %munin_admin_pass% placeholder to the value returned from calling the function get_attr to get the value of the munin_admin_pass

References

Related documents

How Many Breeding Females are Needed to Produce 40 Male Homozygotes per Week Using a Heterozygous Female x Heterozygous Male Breeding Scheme With 15% Non-Productive Breeders.

•  Apply social network analysis in practice by analysing online communities using a social network analysis tool called Condor.. •  Work in globally distributed multi-disciplinary

The work for the project will include a project proposal presentation, project discussion with teaching staff, five interim checkpoint reviews, a final project. presentation, and

Property Data Type yearNames structure stockNames structure stockReturn matrix (double) S&amp;PReturns array (double) Probabilities array (double) MinReturnLowerBound

A subgrid-scale model is presented for the scalar dissipation rate in nonpremixed turbulent reacting flows.. Inputs to the model are the filtered density, the Favre-

Where participants will have the opportunity to solve pre-defined cases of various physic, likes: Potential flow, Simple fluid flows, Heat Transfer including natural

Model Demand FESA D-EXPANSE EconA BLUE-MLP EEA HESA/UK+ HAPSO Treatment of uncertainty Structural uncertainty around cost-optimisation; Parametric uncertainty

Timber structures are analysed using elastic structural analysis techniques in ultimate &amp; serviceability limit states. Thus whilst the ULS loading is adopted as per EC5,