Imagine you're explaining this to a total vagrant n00b…because you are.
5 thoughts on “Can someone please explain what provisioning is in the context of vagrant?”
Provisioning is setting up your environment. When you first start, if there is no provisioning you have just a bare Linux box. You can set up your provisioning to install node, set up apache, install whatever packages you need, set up databases, etc. This is how you go from a base box to one customized to you
Vagrant (and all the Hashi Corp stuff) is about automation.
Provisioning here boils down to running a script that sets up all the things you need so that you can start developing/working immediately when ‘vagrant up’ completes.
Think of Vagrant creating an empty apartment space. You go in there and it’s just a floor, walls, doors & windows and a ceiling. You COULD go in there, throw a beanbag down and call it a home. But, most often you do not wish to do that.
What you want is furniture and a functional layout. You CAN do it by hand, but then you’d need to waste time on it yourself and also you cannot quickly repeat it or send the schematic to your friends.
This is where provisioning comes in. It’s a way for you to “explain” how you want it setup and it will do it for you. Vagrant sets up the walls&floor part, provisioning goes in and makes it a home, as many times as you need, in whichever “building complex”.
Provisioning is everything that happens between “Creating a fresh new virtual machine” and “Virtual machine is ready for use”.
For example, if you want to create a VM for a Ruby on Rails project, the provisioning would involve installing Ruby and the Rails gem.
In Vagrant, the simplest way to handle provisioning is to write a shell script to perform the tasks and use the [shell provisioner](https://docs.vagrantup.com/v2/provisioning/shell.html). Most people prefer one of the more complex and powerful provisioners, though. (Usually, they pick whatever their company also uses to provision their production servers.)
I’ll give you an example. This Vagrantfile sets up a Ruby on Rails server in a virtual machine for development.
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = “hashicorp/precise32”
config.vm.synced_folder “~/DEV/twatter”, “/var/twatter”, type: “nfs”
config.vm.provision :shell, path: “install-rvm.sh”
config.vm.network “forwarded_port”, guest: 3000, host: 4567
config.vm.network “forwarded_port”, guest: 4000, host: 5567
config.vm.network “forwarded_port”, guest: 5432, host: 5432
config.vm.hostname = “Railsvr”
config.vm.post_up_message = “This VM was provisioned by Vagrant and contains a preconfigured Rails web server, forwarded from 127.0.0.1:4567”
config.vm.provider :libvirt do |libvirt|
libvirt.driver = “kvm”
libvirt.connect_via_ssh = false
libvirt.username = “myname”
libvirt.storage_pool_name = “vmlib”
end
end
So basically, I am telling Vagrant to feed instructions into my hypervisor (Libvirt, the library that controls Linux Kernel Virtualization)…I’m telling it to download and use the default ubuntu (precise32) “box” from hashicorp.
By default, Vagrant shares the folder that your Vagrantfile is located in, mapping it to /vagrant on a linux box for instance. It does this using Rsync by default, which just copies the folder at the time you run vagrant up. That config.vm.synced_folder defines an additional one using NFS, which is the folder in which my current rails project is located (on the host machine). This allows me to make changes to the project folder without having to push them to the server using git or a manual file copy – I change something on my laptop, it is also changed on the virtual rails server, because it is a shared folder (rather than a copy of a folder that only changes when you first boot the VM).
Third line tells it to run a script called install-rvm.sh, which contains the following code:
This essentially preconfigures a Ruby on Rails development environment, using curl to download RVM, rvm to setup ruby and rails, setup user permissions, install node.js for the java runtime
Next three lines in the vagrantfile are port forwards – one for my Rails dev server, one for a rails server that I map to the reference implementation of above mentioned rails tutorial, and port 5432 for postgreSQL connections.
You can combine it with a config management tool (puppet, chef, Ansible, Salt, etc) to simplify some of what I did above there, but that’s an example of how you use Vagrantfile for provisioning. I just point my CLI at the folder containing that vagrantfile and script, run
vagrant up
machine spins up
vagrant ssh
to connect and issue commands, and I have a fully functional Ruby on Rails server, with my app already installed. You could set that bash script to
cd /var/appdir && rails server -dp 3000 && cd /var/referenceApp && rails server -dp 4000
to prestart the rails servers I use, if I wanted to improve it a little.
Provisioning is setting up your environment. When you first start, if there is no provisioning you have just a bare Linux box. You can set up your provisioning to install node, set up apache, install whatever packages you need, set up databases, etc. This is how you go from a base box to one customized to you
Vagrant (and all the Hashi Corp stuff) is about automation.
Provisioning here boils down to running a script that sets up all the things you need so that you can start developing/working immediately when ‘vagrant up’ completes.
Think of Vagrant creating an empty apartment space. You go in there and it’s just a floor, walls, doors & windows and a ceiling. You COULD go in there, throw a beanbag down and call it a home. But, most often you do not wish to do that.
What you want is furniture and a functional layout. You CAN do it by hand, but then you’d need to waste time on it yourself and also you cannot quickly repeat it or send the schematic to your friends.
This is where provisioning comes in. It’s a way for you to “explain” how you want it setup and it will do it for you. Vagrant sets up the walls&floor part, provisioning goes in and makes it a home, as many times as you need, in whichever “building complex”.
Provisioning is everything that happens between “Creating a fresh new virtual machine” and “Virtual machine is ready for use”.
For example, if you want to create a VM for a Ruby on Rails project, the provisioning would involve installing Ruby and the Rails gem.
In Vagrant, the simplest way to handle provisioning is to write a shell script to perform the tasks and use the [shell provisioner](https://docs.vagrantup.com/v2/provisioning/shell.html). Most people prefer one of the more complex and powerful provisioners, though. (Usually, they pick whatever their company also uses to provision their production servers.)
I’ll give you an example. This Vagrantfile sets up a Ruby on Rails server in a virtual machine for development.
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = “hashicorp/precise32”
config.vm.synced_folder “~/DEV/twatter”, “/var/twatter”, type: “nfs”
config.vm.provision :shell, path: “install-rvm.sh”
config.vm.network “forwarded_port”, guest: 3000, host: 4567
config.vm.network “forwarded_port”, guest: 4000, host: 5567
config.vm.network “forwarded_port”, guest: 5432, host: 5432
config.vm.hostname = “Railsvr”
config.vm.post_up_message = “This VM was provisioned by Vagrant and contains a preconfigured Rails web server, forwarded from 127.0.0.1:4567”
config.vm.provider :libvirt do |libvirt|
libvirt.driver = “kvm”
libvirt.connect_via_ssh = false
libvirt.username = “myname”
libvirt.storage_pool_name = “vmlib”
end
end
So basically, I am telling Vagrant to feed instructions into my hypervisor (Libvirt, the library that controls Linux Kernel Virtualization)…I’m telling it to download and use the default ubuntu (precise32) “box” from hashicorp.
By default, Vagrant shares the folder that your Vagrantfile is located in, mapping it to /vagrant on a linux box for instance. It does this using Rsync by default, which just copies the folder at the time you run vagrant up. That config.vm.synced_folder defines an additional one using NFS, which is the folder in which my current rails project is located (on the host machine). This allows me to make changes to the project folder without having to push them to the server using git or a manual file copy – I change something on my laptop, it is also changed on the virtual rails server, because it is a shared folder (rather than a copy of a folder that only changes when you first boot the VM).
Third line tells it to run a script called install-rvm.sh, which contains the following code:
#!/usr/bin/env bash
gpg –keyserver hkp://keys.gnupg.net –recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
sudo apt-get install -y curl
\curl -sSL https://get.rvm.io | bash -s stable –ruby=2.1.5 –with-gems=”rails 4.2.0″
sudo usermod -a vagrant -G rvm
source /etc/profile.d/rvm.sh
rvm cleanup all
rvm use [email protected] –create –default
echo “gem: –no-rdoc –no-ri” >> ~/.gemrc
sudo apt-get update
sudo apt-get install -y nodejs
This essentially preconfigures a Ruby on Rails development environment, using curl to download RVM, rvm to setup ruby and rails, setup user permissions, install node.js for the java runtime
Next three lines in the vagrantfile are port forwards – one for my Rails dev server, one for a rails server that I map to the reference implementation of above mentioned rails tutorial, and port 5432 for postgreSQL connections.
You can combine it with a config management tool (puppet, chef, Ansible, Salt, etc) to simplify some of what I did above there, but that’s an example of how you use Vagrantfile for provisioning. I just point my CLI at the folder containing that vagrantfile and script, run
vagrant up
machine spins up
vagrant ssh
to connect and issue commands, and I have a fully functional Ruby on Rails server, with my app already installed. You could set that bash script to
cd /var/appdir && rails server -dp 3000 && cd /var/referenceApp && rails server -dp 4000
to prestart the rails servers I use, if I wanted to improve it a little.
Hope that helps.