Introduction

eDeploy is a new generation tool to manage baremetal deployments, virtual image creations and upgrades of Linux based systems in general. Upgrades have been the main focus with the possibility to rollback upgrades if needed.
For those in a hurry wanting to see the source code, eDeploy is released under the Apache release at https://github.com/enovance/edeploy.
In this article, we focus on the way to build roles to be deployed by eDeploy. For a description of eDeploy, consult the following article.
eDeploy roles are trees of files corresponding to full systems (operating system + applications) that will be used to install or upgrade physical or virtual machines. Roles must be complete after installation and must not need to add new pieces afterward. This is an important thing to keep in mind to be able to take advantage of the upgrade mechanism built in eDeploy.
Another important design decision is to separate the duties between eDeploy and configuration management tools. eDeploy is in charge of managing what is present on a system usually using the underlying packaging system at build time. Configuration tools like Puppet are in charge of managing the configuration of the system at run time meaning changing configuration files and services but no package management and no addition or deletion of files.

What are eDeploy roles

eDeploy roles are chroot trees of files. Roles are built in a hierarchical way to avoid duplicating the shared steps between roles. For example, the following hierarchy of roles is available in the edeploy and edeploy-roles git modules on Github:

-- base
  |--ceph
  |-- chef-server
  |-- cloud
  |-- devstack
  |-- docker
  |-- health-check
  |-- mysql
  |-- openstack-common
     |-- openstack-full
  |-- puppet-master
  |-- pxe

base is the root of the hierarchy and probably the most complex role to build as it setups the operating system. The other roles are basically adding to the base role their needed packages. The provided roles can be built for the following Linux operating systems:

1. CentOS 6
2. Debian Wheezy
3. Red Hat Enterprise Linux 6
4. Ubuntu 12.04 LTS

You can of course build your roles for your favorite Linux distributions. The only requirement is to have grub (version 1 or 2) installed in your tree.

Building an eDeploy role

You can build the roles the way you want using the tools of your choice. Here is how we do it using the set of shell scripts available in our modules on Github. Each role has a corresponding file named <role>.install. For example the mysql role could be like this:

#!/bin/bash
src="$1"
dir="$2"
version="$3"
ROLE=mysql
ORIG=$(cd $(dirname $0); pwd)
PACKAGES="mysql-server"
. ${ORIG}/functions
update_repositories $dir
install_packages $dir "$PACKAGES"
clear_packages_cache $dir

This script takes 3 arguments:

1. the directory where the base role is installed
2. the target directory where to create the mysql role
3. the version of the role

The functions file that is sourced at the beginning of the file is in charge of copying the base tree to the new mysql tree and to provide a set of functions that can be used independently of the Linux distributions like update_repositories to update the list of available packages, install_packages to install packages using the package manager of the operating system and clear_packages_cache to suppress the downloaded packages to save space.
The functions file is also in charge of setting up the chroot to look like a normal system to packages by mounting /proc, making sure /dev is conform to the host, copying /etc/resolv.conf from the host to have the host resolution working and this kind of things.
At the end of the script, an exit handler is in charge of cleaning the added mount points and everything that has been setup at the beginning of the script. This handler is also in charge of creating a compressed archive in the form of a compressed tar archive under the following name <role>-<version>.edeploy. This archive is created to ease eDeploy roles management from the build systems to the deployment servers.

Building your own eDeploy roles

The fastest way to build your own roles is to create a new directory copying the Makefile and the functions files from the edeploy-roles github repository. You will also need to clone the edeploy git repository under /srv to have the included shell functions sourced properly from the /srv/edeploy/build directory.
Then, you can create your .install files to build your roles and edit the Makefile file to add your new targets.

Creating a VM image from an eDeploy role

The process to create eDeploy roles can be extended to create VM images to be used by the Glance service in OpenStack or by the virtualization system of your choice.
By pointing the VIRTUALIZED environment variable to a <role>.virt file. This file can contain the following settings to configure your VM image:

• IMAGE_FORMAT to configure the format of your VM image (by default qcow2).
• ROOT_FS_SIZE to configure the size in MB of you virtual disk. If unset, the minimal size will be computed.
• NETWORK_CONFIG to enable the auto-configuration of the eth0 ethernet controller. If you don’t want this feature, set it to no.

The generated VM image has been designed to be compliant with OpenStack and virtualization systems in general by following the rules described in the OpenStack Virtual Image Guide
Don’t forget to add the cloud-init package in your role if you want to take advantage of the resizing feature according to the flavor of your Cloud system.

Conclusion

At eNovance, we use eDeploy roles to deploy and upgrade complex OpenStack setups and to build VM images to be used inside OpenStack. Let us know how you use eDeploy roles!