StackOverflow: Docker vs. Vagrant, with project authors’ comments

There is this discussion over at StackOverflow: Should I use Vagrant or Docker for creating an isolated environment? It attracted the attention of the authors of both projects (as well as many other smart people).  Read the whole thing for interesting insights into what’s there now and what’s coming.  If you’d rather have a summary, here it is:

The short answer is that if you want to manage machines, you should use Vagrant. And if you want to build and run applications environments, you should use Docker.

Serverlessconf 2016 – New York City: a personal report

Serverlessconf 2016 – New York City: a personal report – is a fascinating read.  Let me get you hooked:

This event left me with the impression (or the confirmation) that there are two paces and speeds at which people are moving.

There is the so called “legacy” pace. This is often characterized by the notion of VMs and virtualization. This market is typically on-prem, owned by VMware and where the majority of workloads (as of today) are running. Very steady.

The second “industry block” is the “new stuff” and this is a truly moving target. #Serverless is yet another model that we are seeing emerging in the last few years. We have moved from Cloud (i.e. IaaS) to opinionated PaaS, to un-opinionated PaaS, to DIY Containers, to CaaS (Containers as a Service) to now #Serverless. There is no way this is going to be the end of it as it’s a frenetic moving target and in every iteration more and more people will be left behind.

This time around was all about the DevOps people being “industry dinosaurs”. So if you are a DevOps persona, know you are legacy already.

Sometimes I feel like I am leaving on a different planet.  All these people are so close, yet so far away …

Packer – a tool for creating VM and container images

With the recent explosion in the virtualization and container technologies, one is often left disoriented.  Questions like “should I use virtual machines or containers?”, “which technology should I use”, and “can I migrate from one to another later?” are just some of those that will need answering.

Here is an open source tool that helps to avoid a few of those questions – Packer (by HashiCorp):

Packer is a tool for creating machine and container images for multiple platforms from a single source configuration.

Have a look at the supported platforms:

  • Amazon EC2 (AMI). Both EBS-backed and instance-store AMIs within EC2, optionally distributed to multiple regions.
  • DigitalOcean. Snapshots for DigitalOcean that can be used to start a pre-configured DigitalOcean instance of any size.
  • Docker. Snapshots for Docker that can be used to start a pre-configured Docker instance.
  • Google Compute Engine. Snapshots for Google Compute Engine that can be used to start a pre-configured Google Compute Engine instance.
  • OpenStack. Images for OpenStack that can be used to start pre-configured OpenStack servers.
  • Parallels (PVM). Exported virtual machines for Parallels, including virtual machine metadata such as RAM, CPUs, etc. These virtual machines are portable and can be started on any platform Parallels runs on.
  • QEMU. Images for KVM or Xen that can be used to start pre-configured KVM or Xen instances.
  • VirtualBox (OVF). Exported virtual machines for VirtualBox, including virtual machine metadata such as RAM, CPUs, etc. These virtual machines are portable and can be started on any platform VirtualBox runs on.
  • VMware (VMX). Exported virtual machines for VMware that can be run within any desktop products such as Fusion, Player, or Workstation, as well as server products such as vSphere.

The only question remaining now, it seems, is “why wouldn’t you use it?”. :)

Vagrant adventures on Fedora 21

I spent a large chunk of yesterday experimenting with Vagrant on my Fedora 21 laptop.  I’ve used it before of course, but a friend asked for help with something I was planning to play with for a long time, so it unexpectedly lead me into a journey.

Let’s start simple.  If you want the least possible amount of hassle with running Vagrant on Fedora, you should use it with Oracle VirtualBox provider (sometimes also called hypervisor).   It works great!  The only troubles with this approach is that VirtualBox relies on a kernel module (kmod-VirtualBox RPM), which has to match your current running kernel version to a digit.  This kernel module is NOT part of the official Fedora repositories, and, instead, can be found in the RPM Fusion yum repository (rpmfusion-free-updates).  This means that sometimes, when Fedora releases a kernel update, it might take a few days for the RPM Fusion repository to catch up with the kmod-VirtualBox updates.  And this, of course, might result in your Vagrant setup being broken.

The easiest way to protect against that is to disable automatic kernel, kernel module and VirtualBox updates.  To do so, add the following line to the [main] section of your /etc/yum.conf file, right after your VirtualBox/vagrant setup started to work:

exclude=kernel* kmod-* VirtualBox*

Now, if you forgot to do that a few times got pissed off with this situation (or don’t like Oracle for some reason), you might consider alternatives.  Which are a few.  Vagrant supports a variety of hypervisors.   One of the common alternatives is to use libvirt, which is shipped with Fedora distribution.

Installing libvirt is simple (thanks to this blog post).  Here’s pretty much all you have to do:

yum install libvirt libvirt-daemon libvirt-daemon-qemu virt-manager
service libvirtd restart

The problem that you might realize now is that libvirt is not the most popular provider for boxes in the Vagrant world.  Most people seem to prefer VirtualBox.  But if your choices are satisfied, I’m glad for you.  If they are not, however, there is a work around that you might go for – vagrant mutate plugin.  This plugin converts vagrant boxes from one hypervisor to another.

In order to install this plugin on Fedora 21 you’ll need a few development tools first (this StackOverflow thread definitely helped with the weird g++ error):

yum install ruby-devel gcc-c++ make

Once you have those, install the vagrant plugin with your regular user (the one who will run vagrant VMs):

vagrant plugin install vagrant-mutate

Now you can mutate Vagrant boxes.  Unfortunately, you might find that mutate plugin doesn’t like boxes with slash in their names (like chef/centos-6.5).  The suggested workaround is to either use box names without slashes, or to provide mutate plugin with the box URLs, rather than names.  The official boxes directory doesn’t give you URLs though, so you might be stack with random GitHub repositories or with an alternative directory, like Vagrantbox.es.

My adventures with this aren’t over yet.   Feel free to send suggestions my way.  From my side, here are a couple of other useful links on this subject:

One last bit of advise from me is that until you are absolutely sure that your Vagrant setup works perfectly, stick to 32-bit box images.  There’s nothing like ripping your hair out for three hours only to learn that your host hardware is 32-bit while you are trying to boot into a 64-bit operating system.

spoon.net – run any desktop application on deman

spoon.net – run any desktop application on deman

I haven’t tried it myself yet, but a few people mentioned to me that this is mighty useful for cross-browser testing during web development and design.