Vagrant Provisioning – Setting up the Environment

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.


Official Provisioning Documentation:


Vagrantfile – Defining the Virtual Machines

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)

Official documentation –