Preparing Virtual Images with the Agent

So that Roboconf can deploy Software components on remote hosts (VMs, devices…), there need to be a Roboconf agent deployed on this host. The agent will be in charge of receiving orders from the Deployment Manager and applying them. It is also responsible of notifying the DM of changes on the host.

So, the prerequisite is to have this agent deployed on the remote hosts.
On devices or self-hosted machines, the agent has to be deployed manually. This can be made automatic with SSH and some scripts, or by using other deployment solutions. In the cloud, deploying the agent is achieved by creating and storing a virtual image. When a VM will be instantiated from this image, the agent will already be there.

We plan to create system packages (.deb, .rpm) for both the DM and the agent.
For agents, it will simplify the creation of the virtual images.

The creation of a virtual image depends on the IaaS you use.
You may also define virtual appliances with OVF or solutions like UShareSoft or Kameleon.

Although we generally test Roboconf with Ubuntu systems, there is no reason it does not work on other systems.
However, we recommend using Linux systems.

In any case, you must have:

Eventually, you need to have the agent installed somewhere on the system.
Until we have system packages, the agent must be deployed by hand and configured to start with the machine and/or VM.

Grab the agent’s ZIP file and unzip it somewhere on the file system.
Make sure the agent will start with the system. A simple way can be to call it from from the the rc.local file.

sudo nano /etc/rc.local

Put at the end of this file, before exit 0

cd /path/to/roboconf/agent
./start.sh
cd

Obviously, you can also create an init.d script.

It is important that the agent runs in ROOT mode.
Otherwise, agent plug-ins may not work correctly and encounter permission issues.

Once you have a VM running with all of this, you can create a snapshot and save it as a virtual image. The image ID will be referenced in the iaas.properties. When a VM will be created by Roboconf, it will create it from this template.

You may wonder if the agent needs parameters at startup.
Most of the time, the DM passes information to agents through mechanisms that are available in cloud infrastructures (through user data). However, since Roboconf can deploy on other machines than just VMs, other solutions are available to pass data to agents.

Here is a short table to indicate the parameters to give.

IaaS / Platform Parameters and Comments
Amazon Web Services No argument. Information will be transmitted by the DM through AWS mechanisms.
Microsoft Azure Two arguments are required. Use startup.sh platform azure
OpenStack No argument. Information will be transmitted by the DM through OpenStack mechanisms.
VMWare No argument. Information will be transmitted by the DM through VMWare mechanisms.
“Embedded” You will need to pass 6 arguments to the startup script. See comments at beginning of the startup.sh script.
“In-Memory” It makes no sense for this, since the agent is created by the DM and runs in-memory.