Technical Preview: running Flying Circus managed components locally in Vagrant

We have been looking for a way to allow developers to run the Flying Circus managed components in local installations, so they can develop while being offline or before starting to run the application in our commercial environment.

Vagrant is one of the tools we have been using ourselves to create various almost-like-the-Flying-Circus environments based on Ubuntu images, using Puppet or Shell scripts – but this been only a make-shift approach.

Additionally we’ve been looking at NixOS for a while now and are preparing internally to move our platform away from Gentoo to NixOS. A switch like this is huge – but NixOS is a “DevOps-friendly” distribution and the community has a mind-set that is very much alike to the way we run the Flying Circus.

After a while of experimentation we found that we were able to provide a nice reliable way for us (and you!) to create Vagrant setups that today feel “close enough” like the Flying Circus platform so that we can run developer instances of applications that we manage (and of our own tools!).

Without further ado, here’s how you can get started with this. Make sure you have Vagrant installed, after that, open your terminal and run:

$ mkdir fc-local-box
$ vagrant init flyingcircus/nixos-14.12-i686
$ wget\~ctheune/vagrant-nixos-0.0.6.gem
$ vagrant plugin install ./vagrant-nixos-0.0.6.gem
$ cat > provision.nix
{ config, lib, pkgs, ... }: with config;
    flyingcircus.roles.haproxy.enable = true;
    flyingcircus.roles.nginx.enable = true;
    flyingcircus.roles.varnish.enable = true;
    flyingcircus.roles.mysql.enable = true;
$ vagrant up
$ vagrant ssh

Now you have a machine configured that has haproxy, nginx, varnish, and mysql that behaves almost like the installation upstream. Notable differences are that configuration is not applied running the usual “sudo” commands but by changing the configuration (where we have provided the “local” hooks) and then running “sudo nixos-rebuild switch” (inside) or running “vagrant provision” (outside). Also, you can experiment with custom NixOS configuration to install additional packages and configuration by adjusting the “provision.nix” file.

The NixOS configuration that we have built and the base box is available on bitbucket.

Note: the plugin download and installation is only needed once per host. Also, this isn’t the currently released version of this plugin as it contains fixes from us that haven’t been applied upstream, yet.

And finally, remember: this is a technical preview so we won’t guarantee this to be in a working condition, useful or won’t eat your dog.

Let me know what you think – contact me directly via email ( or Twitter (@flyingcircusio). If you need help to get started – we’re happy to show you how this works.

4 thoughts on “Technical Preview: running Flying Circus managed components locally in Vagrant

  1. Hi .. It looks like `vagrant up` fails to update VBoxGuestAdditions using the vagrant-vbguest plugin. The plugin doesn’t know nixos, and it’s looking for `/mnt` on the guest.

    I’m on Ubuntu 14.04.1 LTS, Vagrant 1.7.2, vagrant-vbguest 0.10.0:

    Bringing machine ‘default’ up with ‘virtualbox’ provider…
    ==> default: Box ‘flyingcircus/nixos-14.12-i686’ could not be found. Attempting to find and install…
    default: Box Provider: virtualbox
    default: Box Version: >= 0
    ==> default: Loading metadata for box ‘flyingcircus/nixos-14.12-i686’
    default: URL:
    ==> default: Adding box ‘flyingcircus/nixos-14.12-i686’ (v0.1) for provider: virtualbox
    default: Downloading:
    ==> default: Successfully added box ‘flyingcircus/nixos-14.12-i686’ (v0.1) for ‘virtualbox’!
    ==> default: Importing base box ‘flyingcircus/nixos-14.12-i686’…
    ==> default: Matching MAC address for NAT networking…
    ==> default: Checking if box ‘flyingcircus/nixos-14.12-i686’ is up to date…
    ==> default: Setting the name of the VM: flying-circus_default_1432875884029_81221
    ==> default: Clearing any previously set network interfaces…
    ==> default: Preparing network interfaces based on configuration…
    default: Adapter 1: nat
    ==> default: Forwarding ports…
    default: 22 => 2222 (adapter 1)
    ==> default: Booting VM…
    ==> default: Waiting for machine to boot. This may take a few minutes…
    default: SSH address:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying…
    ==> default: Machine booted and ready!
    GuestAdditions versions on your host (4.3.16) and guest (4.3.24) do not match.
    The guest’s platform is currently not supported, will try generic Linux method…
    Copy iso file /usr/share/virtualbox/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso
    mount: mount point /mnt does not exist
    ==> default: Checking for guest additions in VM…
    The following SSH command responded with a non-zero exit status.
    Vagrant assumes that this means the command failed!

    mount /tmp/VBoxGuestAdditions.iso -o loop /mnt

    Stdout from the command:

    Stderr from the command:

    mount: mount point /mnt does not exist


    1. Thanks. I think that’s a two-fold problem: vagrant plugins are global to your machine. And this specific plugin is a little dumb regarding machines where its not applicable or functional. I have copied your comment to the bitbucket issue tracker. We should follow this up there.


  2. Ah, this has developed already and isn’t that much up to date. I’ll ask my colleagues whether they would care to update this or our documentation. Thanks for the pointer!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s