DevOps with DebOps

     Special Thanks: This article was made possible by support from Linux Professional Institute

Enterprise-grade automation solutions like Puppet and Chef are very powerful, but they require a huge amount of learning. Ansible has gained popularity as an alternative to Puppet and the other similar enterprise automation tools. The strict but simple Ansible syntax lets you define roles that are essentially self-documenting (Figure 1), which makes access far easier and ensures that you can integrate your existing knowledge faster.

Figure 1: Ansible relies on Yaml and takes an approach that forces playbooks to document themselves.

Even though Ansible is simpler than Puppet or Chef, writing your own roles takes time. Wouldn’t it be great if you had a library of prebuilt Ansible recipes for standard services that you could install in seconds by pressing a button?

DebOps [1] is a huge collection of prebuilt Ansible roles that you can use on fresh Debian systems.

What Is DebOps?

The collection of prebuilt Ansible roles currently totals more than 110 roles. The authors also provide userland tools composed in Python for these roles. A tool called debops is part of the collection; you call debops with the appropriate parameters to launch an Ansible playbook for the desired effect.

DebOps helps you with the installation and the maintenance of your DebOps Ansible roles, thanks to the debops-init and debops-update commands. debops-defaults helps to find the right configuration for your own system. debops-padlock makes it possible to encrypt and store sensitive passwords, and debops-tasks supports processing multiple tasks.

The best way to approach DebOps is quite simply learning by doing. But be careful: The solution may make your life easier, but it comes with some pitfalls that you need to avoid at all costs.

DebOps – Hands On

To get started, you’ll need at least two Debian systems that are newly installed and are still plain vanilla. In theory, this example would also work with a single host, but that would not be very relevant to real-world IT practice – tools like Ansible are typically used to automate the configuration of multiple systems. This example is based on the assumption that Ansible is running on a central automation host, which logs on to other systems via SSH.

DebOps is designed for Debian, but it is also supposed to work with the Debian-based Ubuntu. (Most of the packages on both systems are similar and many system tools have the same name.) Our tests revealed some issues with the Ubuntu support at various points, although other tasks completed successfully on both Debian and Ubuntu systems.

The first step is to install Ansible. It is included with the latest Debian and Ubuntu versions, but the the default versions are naturally a bit outdated. It is better to pick up a suitable packages [2] from Ansible upstream to make sure you have the latest version for your own system. You can normally install the packages using your own package management system.

Once you have set up Ansible, you can move on to installing DebOps. A prebuilt DebOps package exists for Debian, but it is only in the experimental branch and it is a fairly ancient. The DebOps developers recommend installing DebOps using the pip Python package tool [3]. The command is:

pip install debops

This command puts DebOps in /usr/local/bin/debops , where it is now ready for use.

The next step largely depends on whether you supervise your hosts in a team with other administrators or whether you work on your own. If you set up DebOps as a normal user, all the configuration files will end up in your home directory. If you want co-workers to also benefit from DebOps, define the following parameters in the /etc/debops.cfg file, which you might also need to create:

[paths]
data-home: /usr/local/debops

If you only work as a root, you can alternatively use the path below /root .

Speaking of root: You now need to run the debops-update command as the superuser. The command downloads all the Debops-playbooks available on Github for Ansible and stores them in the previously configured directory. This is followed by a debops-init with a parameter containing the destination directory for the Ansible configuration.

The Ansible configuration is not in the data-home directory in DebOps. If you work as root anyway, you can call debops-init local-setup command below /root . The rest of the path is the typical folder structure that Ansible expects (Figure 2).

Figure 2: Laying the foundations for your automation with debops-init.

As the administrator, you will want to pass many configuration parameters in to DebOps along the way. DebOps is a wrapper around Ansible, and it ultimately calls ansible with the correct parameters. Ansible expects an ansible.cfg , which DebOps generated previously from the available configuration values.

Make sure you do not change anything in the generated ansible.cfg file, because DebOps will overwrite any changes later on. Instead, /etc/debops.cfg or (preferably) .debops.cfg are available for configuration in the directory previously created by debops-init .