Murano easily installs and configures necessary software on new virtual machines. Murano agent is one of the main participants of these processes.
Usually, it is enough to execute a single script to install a simple application. A more complex installation requires a deep script result analysis. For example, we have a cross-platform application. The first script determines the operation system and the second one calls an appropriate installation script. Note, that installation script may be written in different languages (the shell for Linux and PowerShell for Windows). Murano agent can easily handle this situation and even more complicated ones.
So murano agent operates not with scripts, but with execution plans, which are minimum units of the installation workflow.
Murano-agent on a new VM¶
Earlier most of the application deployments were possible only on images with pre-installed murano agent. You can refer to corresponding documentation on building an image with murano-agent.
Currently murano-agent can be automatically installed by cloud-init. To deploy an application on an image with pre-installed cloud-init you should mark the image with Murano specific metadata. More information about preparing images can be found here. This type of installation has some limitations. The image has to have pre-installed python. Murano-agent is installed from PyPi so the instance should have connectivity with the Internet. Also it requires an installation of some python packages, e.g. python3-pip, python3-dev, python3-setuptools, python3-virtualenv, which are also installed by cloud-init.
Interaction with murano-engine¶
First of all, communication between murano-agent and murano engine should be established. The communication is performed through AMQP protocol. This type of communication is preferable (for example, compared to SSH) because it is:
To establish the connection, there is no need to wait until the instance is spawned. Murano-agent, on its turn, does not need to wait for a murano-engine task.
Messages can be sent to RabbitMQ asynchronously.
The connection does not depend on network issues. And moreover, there is no way to physically connect to the virtual machine if floating IP is not set.
It is possible to reload the instance and change network parameters during the deployment.
If one instance of murano-engine fails in the middle of the deployment, another one picks up the messages from the queue and continue the deployment.
Right after application author calls the deploy method of the class, inherited from
io.murano.resources.Instance, new murano-agent configuration file starts
forming in accordance with the values specified in the
configuration file section. A script that runs through cloud-init copies a
new file to the right place during the instance booting.
Execution plans and execution plan templates¶
It was already mentioned that murano-agent recognizes execution plans. These instructions contain scripts with all the required parameters The application package author provides the execution plan templates together with scripts code. During the deployment it is complemented with all required parameters (including user-input).
For more information on execution plan templates, refer to Execution plan template.
Take a look at the muranoPL code snippet. The``EtcdAddMember`` template expects name and ip parameters. The first line shows that these parameters are passed to the template, and the second one shows that the template is sent to the agent:
- $template: $resources.yaml('EtcdAddMember.template').bind(dict(
name => $.instance.name,
ip => $.getIp()
- $clusterConfig: $._cluster.masterNode.instance.agent.call($template, $resources)
Beside the simple agent call, there is a method that enables sending an already
prepared execution plan (not a template). The main difference between template
and full execution plan is in the
files section. Prepared execution plan contains
file contents and name by which they are reachable. So it is not required to
provide the resources argument:
Also, there are
instance.agent.call($template, $resources) and
..instance.agent.sendRaw($plan) methods which have the same meaning but
indicate the engine not to wait for the script execution result. The default
agent call response time (with the corresponding method call) is set in
murano configuration file and equals to one hour. Take a look at the
# Time for waiting for a response from murano-agent during the
# deployment (integer value)
agent_timeout = 3600
Murano-agent is able to run different types of scripts,
such as powershell, python, bash, chef, and puppets. Moreover, it has
a mechanism for extending supported formats and that is why murano
agent is called
To use puppet a deployment workflow, configure an execution plan as follows:
Set correct version of format:
FormatVersion >=2.1.0. Previous formats does not support puppet execution.
Use corresponding type
In the script section, script item should have
Provide entry-point class
Use puppet syntax
You can use scripts directly from git or svn repositories:
- mysql: https://github.com/nanliu/puppet-staging.git
A script output is available in the murano-agent log file. This file is located
on the spawned instance at
/etc/murano/agent.conf on a Linux-based
C:\Murano\Agent\agent.conf on a Windows-based machine.
You can also refer to murano-agent log if there is no connectivity with
murano-engine (check if RabbitMQ settings are updated) or to track