Provisioning is the process of setting up the environment. It is the process of installing software along with setting up configurations. This is done upon execution of the ‘vagrant up’ process which starts and provisions the environment.
The default Vagrant boxes are usually generic and most likely lack the specific configuration our environment needs. One way to customize the environment is to ssh into the machine using ‘vagrant ssh’ and install the software adhoc. However the recommended way of provisioning the environment is to define a process that is repeatable, this way we can build environments that are automatically provisioned and also consistent.
Vagrant offers multiple options to provision the machine, this can be shell scripts that most Linux users/sysadmins prefer to industry standard configuration management environments not limited Ansible/Chef/Puppet/Salt/CFEngine etc.
When does Vagrant Provisioning happen?
Vagrant has a lifecycle where a virtual machine is created, sleeping, destroyed etc. The ‘vagrant up’ command is responsible to bringing the system up regardless of the state.
However Vagrant provisioning automatically happens the first time a ‘vagrant up’ command is executed. During this time vagrant checks for the existence of the box and also validates if there are any updates that need to be applied. The next step is apply the customization’s as defined in the configuration file and bring up the machine.
However since the same ‘vagrant up’ command can be used to wake up or booting a virtual machine that has already been created, vagrant must be informed if we desire to destroy and provision the machine again by using the ‘—provision’ flag.
Vagrant allows for customizing the behavior on the machine creation phase if we don’t want provisioning to happen. Issuing a ‘—no-provision’ flag will not provision the machine.
Vagrantfile describes the virtual machine and also how to configure and provision the machine. There is one Vagrantfile for each project and it is an asset that can and should be committed into source control. This file will then be available for the team members to download and create environments that are identical with each other.
Upon issuing a ‘vagrant up’ command it will setup the machine as described in the Vagrantfile. Vagrantfile uses the Ruby language for its definition, a working knowledge of Ruby is beneficial however it is not necessary as most changes require simple variable assignment changes.
Vagrantfile loading order – Loading & Merging
Like most environments Vagrant allows for variable definitions at different levels. These are loaded in a specific order and merged (aka overridden) along the way, allowing for varying levels of specificity at the project level and also define generic setting defined at the system level.
Vagrantfile – Describing your Virtual Machine
The following defines the order of loading of Vagrantfile, if a Vagrantfile is not defined in a specific location below Vagrant continues to the next step.
Vagrantfile from the gem directory
Vagrantfile that comes packaged with the box
Vagrantfile in the Vagrant home directory (~/.vagrant.d)
Vagrantfile from the project directory
Multi-machine overrides if defined. (Configurations where a single Vagrantfile defines multiple guest machines where the virtual machines work together or are associated with each other)
Provider-specific overrides if defined (Configuration options defined by providers to expose distinct functionality that is applicable to the provider)
Vagrant is a tool geared towards administering a consistent development environment workflow spanning various operating systems. Docker is a container management tool that can consistently run software provided that a containerization system is present.
There are benefits and drawbacks for each type of virtualized system. If one desires total isolation with guaranteed resources, a full VM would be the strategy to use. For those who only desire to isolate processes from each other and wish to operate a lot of them using a moderately sized host, then Docker/LXC/runC is definitely the strategy to use.
Technical Considerations
Vagrant is easier to understand and is easier to get up and running but can be very resource intensive (in terms of RAM and space).
Docker architecture is harder to understand and can be harder to get up and running but is much faster, uses much less CPU and RAM and potentially uses much less space than Vagrant VM’s.
How does Docker work?
Containerization
Docker makes use of containers that include your application as well as its dependencies, nevertheless it shares the kernel (operating system) with other containers. Containers run as isolated processes on the host operating system although they are not associated with any specific infrastructure (they are able to run on any computer). Containers are typically more lightweight than virtual machines, so starting and stopping containers is exceedingly fast. Usually development machines don’t have a containerization system built-in, and Docker makes use of a virtual machine with Linux installed to make it work.
Docker is a Linux-only virtual environment (VE) tool, as opposed to a VM tool. It builds on LxC (LinuX Containers), which utilizes the cgroups functionality to allow creation and running of multiple isolated Linux virtual environments (VE) on an individual control host. In contrast to a VM, a VE like Docker doesn’t create its own virtual computer with a distinct OS and processors and hardware emulation. A VE is VM-lite; it rides on the currently present kernel’s image of the underlying hardware, and merely creates a container in order to run one’s apps, and also recreate the OS if desired considering that the OS happens to be merely another application running on the kernel. It places just a little additional load on the system, so in contrast to the traditional VM there is very little overhead when using Docker. Due to the shared kernel, Docker’s isolation isn’t as good as a full VM’s, however it suits many scenarios just fine.
How does Vagrant work?
Virtualization
Vagrant uses virtual machines to run environments independent of the host machine. This is accomplished using what is referred to as virtualization using software like VirtualBox or VMware. Each environment possesses its own virtual machine and is configured by make use of a Vagrantfile. The Vagrantfile tells Vagrant how to set up the virtual machine along with what scripts ought to be run in order to provision the environment. The downside to this approach is that each virtual machine includes not only one’s application and all of its libraries but the entire guest operating system to boot, which can significantly add to the size of the image.
Vagrant lets one script and package the VM config along with the provisioning setup. It is engineered to run on top of nearly every VM tool however, default support is only included for VirtualBox (others are supported through plugins). Vagrant also does integrate with Configuration Management tools for instance Puppet and Chef to provision VM setups and configs.
Where will Docker and Vagrant Shine?
If one needs higher level of separation of hardware resources, then they should use Virtualization (i.e. VMs). Ideal use case can be public cloud solutions where they demand stringent resource separation between VMs running on the same hardware. The implications are that we are guaranteed resources at the hardware level, however at the cost of heavier image and longer startup times. We also get support for more OS platforms like Linux/Unix/Windows etc.
If one does not need strict resource separation and want their application to get bundled with its user-space dependencies then containers are ideal for that. The implications are faster startup times with very lightweight images with lesser isolation and no guaranteed resources at the hardware level. Also, the support for OS platforms is Linux only.
In Conclusion
Although Vagrant and Docker appear to be competitors with overlapping feature set, they can be used together in a fashion that their functionality complement one another. In such a scenario, Vagrant can be used to create a base VM, then when one desires to create different configs that all make use of this base VM, use Docker to provision and create different lightweight versions. In other words we can say that Vagrant abstracts the machine whereas Docker abstracts the application.
