Devops tools for workstations

Posted on April 06, 2015 in ConfigPorn • 4 min read

There is a growing interest in devops tools, such as Docker, Puppet / Ansible / Puppet / Chef to set up continuous integration, have the same working environment during development, testing, staging and production, and to manage thousands of servers in the cloud. However, I recently thought that some of these technologies could have a real interest as well for a few machines, for personal workstations. These are just some scenarios and use cases that happened to me, I did not test all of them and they may be irrelevant, feel free to let me know :)

Scenario 1: I want a particular dev environment, without breaking everything

First scenario is the most widely discussed around the web: I want my dev environment to be identical to production, but I do not want to break my system (python 2 vs 3, ruby stuff, …). For this purpose, one can use containers (e.g. Docker). I will not elaborate much on this one.

Note: I recently discovered that systemd had similar features through systemd-nspawn. In particular, see the articles on Systemd from Lennart Poettering to know more about this and systemd features.

Scenario 2: I use many different operating systems

Note: I did not tried this scenario.

If you use many different operating systems on the same machine (say Windows and Linux for instance), then why not considering using virtualization? And not some palliative stuff like Virtualbox, but real hypervisors such as KVM or Xen. These are widely used on servers to run multiple VMs, but why not using them at home, on your personal computer?

CPUs today have a lot of virtualization-specific technologies, even on your workstation, and they are powerful enough to handle it. You will benefit from many advantages, starting from easy maintenance of your system (as it is just a VM, it is easier to backup / restore, isolate etc) and things like hot-switching between operating systems.

One problem may be left: handling the graphics card, which may not be easily shared by multiple VMs.

Scenario 3: You want easy backup mechanism

On important point I previously discussed is the ability to recover from any problem, hardware fault for example. It is important on a server, as downtime is a real problem, especially if you have few servers, but it is also a major concern on workstation. Especially as your laptop may fail at anytime: it can experience basic hardware failure, it may fall and break, it may be stolen…

Then, it is important to be able to recover a fully working system fast. One often talk about data backup, and this is indeed the most important as you cannot recover lost data contrary to a lost configuration (set of packages, state of configuration files, …). But this is not all. Reinstalling a system is a time-consuming task, and it is not really interesting.

Devops have came up with tools to deploy a given configuration on many servers, across the cloud. Those are Ansible, Puppet, Chef, Salt and so on. So, why not using them to deploy your computer configuration? If correctly managed, installing your laptop could be as easy as: partitioning the drive, bootstrapping the system (install base packages and set up an SSH access) and running Ansible (which is the most basic and fitted to this particular need) to reinstall everything else. Almost everything would be done automatically, perfect!

However, this requires to maintain a list of installed packages and associated files for Ansible to use, which can be a bit heavy on the run. Then, it could be interesting to have some way to ”blueprint” your system, to generate configuration descriptions from your existing system (as it is easier to install stuff on your system, tweak it and blueprint it after, than it is to do it tweaking Ansible configuration description and running it each time).

To achieve easy blueprinting, another solution is to use etckeeper to store all your files under /etc (as these are the only supposed to be modified by you, as /usr is the domain of your distribution and should not be modified) in a Git repository and keep a track of every changes in them. Restoring from etckeeper and list of installed packages (obtained with pacman) is quite easy and can even be done without Ansible.

On this particular subject of blueprinting, I wrote some Python script for Arch Linux (basically just a wrapper around good pacman commands), available here. It may not be perfect, but will give you a basis to blueprint your system.

Scenario 4: Sync multiple computers

One last scenario is the following: I have three computers on which I work on an almost daily basis (my laptop, my desktop and another computer). Syncing files between them is quite easy (or at least achievable), but syncing configurations between them is much more difficult. In particular as the whole configuration should not be synced, as there is some device-specific configuration (fstab, LVM configuration, SSH host keys and stuff like that). But this problem is exactly the same as syncing multiple servers in the cloud, and is handled very well by Ansible. Plus Ansible let you define task and replicate only some of them on some machines and so on. Then, it is quite easy to synchronize completely multple computers to have the same work environment on all of them.