| layout | bt_wiki |
|---|---|
| title | Bash Plugin |
| category | Plugins |
| publish | true |
| abstract | Cloudify bash plugin description and configuration |
| pageord | 100 |
| yaml_link | http://getcloudify.org/spec/bash-plugin/1.0/plugin.yaml |
{%summary%} The bash plugin can be used to map node life cycle operations to bash shell scripts that are included in your blueprint. {%endsummary%}
There are 2 modes for working with this plugin.
- In the first mode, the nodes in the blueprint will derive from one of the predefined bash types.
- In the second mode, you have a node that is not derived from a bash type and you map a specific interface operation to a bash shell script.
The plugin definition and predefined types can be found at:
The predefined types are:
cloudify.types.bash.app_modulecloudify.types.bash.app_servercloudify.types.bash.db_servercloudify.types.bash.message_bus_servercloudify.types.bash.web_server
{% highlight yaml %} imports: - {{page.yaml_link}}
blueprint: name: example nodes: - name: example_web_server type: cloudify.types.bash.web_server properties: scripts: create: scripts/create.sh configure: scripts/configure.sh start: scripts/start.sh stop: scripts/stop.sh delete: scripts/delete.sh {%endhighlight%}
In this example, it is assumed that the blueprint folder has a scripts folder in it.
Here, we map the create, configure, start, stop, delete of the cloudify.interfaces.lifecycle node interface to a matching script.
The mapping itself is done under the scripts property of the node.
{%note title=Note%}
It is not mandatory to map all operations to scripts. It is perfectly valid, for example, to only map the start operation to a script.
{%endnote%}
If you have already have a node in your blueprint, and this node does not derive from one of the predefined bash types, you can directly map an interface operation to a script.
{% highlight yaml %} imports: - {{page.yaml_link}}
types: my_custom_type: derived_from: cloudify.types.web_server interfaces: cloudify.interfaces.lifecycle: - start: bash_runner.tasks.run properties: - scripts
blueprint: name: example nodes: - name: example_web_server type: my_custom_type properties: scripts: start: scripts/start.sh {%endhighlight%}
In this example, we define a custom type my_custom_type and map its cloudify.interfaces.lifecycle.start operation to the bash plugin's single operation: bash_runner.tasks.run.
Next, we add the property scripts to the type schema so that script mapping can be configured by nodes using this type.
Finally, we map the start operation to a script located in scripts/start.sh of the blueprint folder. Similar to the way we would have done it using one of the predefined types as described in Types.
{%note title=Note%}
The property name under the scripts property of the node should be the same as the interface operation name, start, in the case of the example above.
{%endnote%}
The node properties are flattened as enviroment variables when the scripts are executed.
Say the node properties are: {% highlight yaml %} blueprint: name: example nodes: - name: some node type: some_type properties: some_prop: some_value some_map: prop1: value1 prop2: value2 {%endhighlight%}
The following properties will be available to scripts:
{% highlight bash %}
echo "some_prop is
Output: {% highlight bash %} some_prop is some_value some_map_prop1 is value1 some_map_prop2 is value2 {%endhighlight%}
In addition, the following environment variables are also available:
CLOUDIFY_NODE_IDThe node instance id for which this script is run forCLOUDIFY_BLUEPRINT_IDThe blueprint idCLOUDIFY_DEPLOYMENT_IDThe deployment idCLOUDIFY_MANAGER_IPThe manager management network ip addressCLOUDIFY_EXECUTION_IDThe current workflow execution idCLOUDIFY_LOGGINGPath to helper logging functions (see below)CLOUDIFY_FILE_SERVERPath to helper blueprint resource access functions (see below)CLOUDIFY_FILE_SERVER_BLUEPRINT_ROOTBase URI to the blueprint folder resources on the management file server
You can source the CLOUDIFY_LOGGING environment variable in your script.
{% highlight bash %}
source ${CLOUDIFY_LOGGING}
{%endhighlight%}
This will put into scope the functions cfy_info and cfy_error that can be used to send output to be managed and accessed later.
Using them is pretty straightforward
{% highlight bash %}
cfy_info "This is some info message. The blueprint id is
You can source the CLOUDIFY_FILE_SERVER environment variable in your script.
{% highlight bash %}
source ${CLOUDIFY_FILE_SERVER}
{%endhighlight%}
This will put into scope the function cfy_download_resource which can be used to download resources that were included in the blueprint folder.
Say we have a folder named images in our blueprint folder and in it, a file named flower.png.
We can download this file to the current working directory, like this: {% highlight bash %} cfy_download_resource "images/flower.png" {%endhighlight%}
If you want more control over the downloaded resource, you can get your resource URL by appending it to the CLOUDIFY_FILE_SERVER_BLUEPRINT_ROOT environment variable: ${CLOUDIFY_FILE_SERVER_BLUEPRINT_ROOT}/images/flower.png.
In fact, this is exactly what cfy_download_resource does.
{% highlight bash %}
function cfy_download_resource()
{
# This only serves as an example. The actual implementation might be different.
wget