If you’re a reader of my code or of this blog, it’s no secret that I hack on a lot of puppet and vagrant. Recently I’ve fooled around with a bit of docker, too. I realized that the vagrant, environments I built for puppet-gluster and puppet-ipa needed to be generalized, and they needed new features too. Therefore…
Introducing: Oh My Vagrant!
Oh My Vagrant is an attempt to provide an easy to use development environment so that you can be up and hacking quickly, and focusing on the real devops problems. The README explains my choice of project name.
Prerequisites:
I use a Fedora 20 laptop with vagrant-libvirt. Efforts are underway to create an RPM of vagrant-libvirt, but in the meantime you’ll have to read: Vagrant on Fedora with libvirt (reprise). This should work with other distributions too, but I don’t test them very often. Please step up and help test :)
The bits:
First clone the oh-my-vagrant repository and look inside:
git clone --recursive https://github.com/purpleidea/oh-my-vagrant cd oh-my-vagrant/vagrant/
The included Vagrantfile is the current heart of this project. You’re welcome to use it as a template and edit it directly, or you can use the facilities it provides. I’d recommend starting with the latter, which I’ll walk you through now.
Getting started:
Start by running vagrant status (vs) and taking a look at the vagrant.yaml file that appears.
james@computer:/oh-my-vagrant/vagrant$ ls Dockerfile puppet/ Vagrantfile james@computer:/oh-my-vagrant/vagrant$ vs Current machine states: template1 not created (libvirt) The Libvirt domain is not created. Run `vagrant up` to create it. james@computer:/oh-my-vagrant/vagrant$ cat vagrant.yaml --- :domain: example.com :network: 192.168.123.0/24 :image: centos-7.0 :sync: rsync :puppet: false :docker: false :cachier: false :vms: [] :namespace: template :count: 1 :username: '' :password: '' :poolid: [] :repos: [] james@computer:/oh-my-vagrant/vagrant$
Here you’ll see the list of resultant machines that vagrant thinks is defined (currently just template1), and a bunch of different settings in YAML format. The values of these settings help define the vagrant environment that you’ll be hacking in.
Changing settings:
The settings exist so that your vagrant environment is dynamic and can be changed quickly. You can change the settings by editing the vagrant.yaml file. They will be used by vagrant when it runs. You can also change them at runtime with --vagrant-foo flags. Running a vagrant status will show you how vagrant currently sees the environment. Let’s change the number of machines that are defined. Note the location of the --vagrant-count flag and how it doesn’t work when positioned incorrectly.
james@computer:/oh-my-vagrant/vagrant$ vagrant status --vagrant-count=4 An invalid option was specified. The help for this command is available below. Usage: vagrant status [name] -h, --help Print this help james@computer:/oh-my-vagrant/vagrant$ vagrant --vagrant-count=4 status Current machine states: template1 not created (libvirt) template2 not created (libvirt) template3 not created (libvirt) template4 not created (libvirt) This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`. james@computer:/oh-my-vagrant/vagrant$ cat vagrant.yaml --- :domain: example.com :network: 192.168.123.0/24 :image: centos-7.0 :sync: rsync :puppet: false :docker: false :cachier: false :vms: [] :namespace: template :count: 4 :username: '' :password: '' :poolid: [] :repos: [] james@computer:/oh-my-vagrant/vagrant$
As you can see in the above example, changing the count variable to 4, causes vagrant to see a possible four machines in the vagrant environment. You can change as many of these parameters at a time by using the --vagrant- flags, or you can edit the vagrant.yaml file. The latter is much easier and more expressive, in particular for expressing complex data types. The former is much more powerful when building one-liners, such as:
vagrant --vagrant-count=8 --vagrant-namespace=gluster up gluster{1..8}
which should bring up eight hosts in parallel, named gluster1 to gluster8.
Other VM’s:
Since one often wants to be more expressive in machine naming and heterogeneity of machine type, you can specify a list of machines to define in the vagrant.yaml file vms array. If you’d rather define these machines in the Vagrantfile itself, you can also set them up in the vms array defined there. It is empty by default, but it is easy to uncomment out one of the many examples. These will be used as the defaults if nothing else overrides the selection in the vagrant.yaml file. I’ve uncommented a few to show you this functionality:
james@computer:/oh-my-vagrant/vagrant$ grep example[124] Vagrantfile
{:name => 'example1', :docker => true, :puppet => true, }, # example1
{:name => 'example2', :docker => ['centos', 'fedora'], }, # example2
{:name => 'example4', :image => 'centos-6', :puppet => true, }, # example4
james@computer:/oh-my-vagrant/vagrant$ rm vagrant.yaml # note that I remove the old settings
james@computer:/oh-my-vagrant/vagrant$ vs
Current machine states:
template1 not created (libvirt)
example1 not created (libvirt)
example2 not created (libvirt)
example4 not created (libvirt)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
james@computer:/oh-my-vagrant/vagrant$ cat vagrant.yaml
---
:domain: example.com
:network: 192.168.123.0/24
:image: centos-7.0
:sync: rsync
:puppet: false
:docker: false
:cachier: false
:vms:
- :name: example1
:docker: true
:puppet: true
- :name: example2
:docker:
- centos
- fedora
- :name: example4
:image: centos-6
:puppet: true
:namespace: template
:count: 1
:username: ''
:password: ''
:poolid: []
:repos: []
james@computer:/oh-my-vagrant/vagrant$ vim vagrant.yaml # edit vagrant.yaml file...
james@computer:/oh-my-vagrant/vagrant$ cat vagrant.yaml
---
:domain: example.com
:network: 192.168.123.0/24
:image: centos-7.0
:sync: rsync
:puppet: false
:docker: false
:cachier: false
:vms:
- :name: example1
:docker: true
:puppet: true
- :name: example4
:image: centos-7.0
:puppet: true
:namespace: template
:count: 1
:username: ''
:password: ''
:poolid: []
:repos: []
james@computer:/oh-my-vagrant/vagrant$ vs
Current machine states:
template1 not created (libvirt)
example1 not created (libvirt)
example4 not created (libvirt)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
james@computer:/oh-my-vagrant/vagrant$
The above output might seem a little long, but if you try these steps out in your terminal, you should get a hang of it fairly quickly. If you poke around in the Vagrantfile, you should see the format of the vms array. Each element in the array should be a dictionary, where the keys correspond to the flags you wish to set. Look at the examples if you need help with the formatting.
Other settings:
As you saw, other settings are available. There are a few notable ones that are worth mentioning. This will also help explain some of the other features that this Vagrantfile provides.
- domain: This sets the domain part of each vm’s FQDN. The default is example.com, which should work for most environments, but you’re welcome to change this as you see fit.
- network: This sets the network that is used for the vm’s. You should pick a network/cidr that doesn’t conflict with any other networks on your machine. This is particularly useful when you have multiple vagrant environments hosted off of the same laptop.
- image: This is the default base image to use for each machine. It can be overridden per-machine in the vm’s list of dictionaries.
- sync: This is the sync type used for vagrant. rsync is the default and works in all environments. If you’d prefer to fight with the nfs mounts, or try out 9p, both those options are available too.
- puppet: This option enables or disables integration with puppet. It is possible to override this per machine. This functionality will be expanded in a future version of Oh My Vagrant.
- docker: This option enables and lists the docker images to set up per vm. It is possible to override this per machine. This functionality will be expanded in a future version of Oh My Vagrant.
- namespace: This sets the namespace that your Vagrantfile operates in. This value is used as a prefix for the numbered vm’s, as the libvirt network name, and as the primary puppet module to execute.
More on the docker option:
For now, if you specify a list of docker images, they will be automatically pulled into your vm environment. It is recommended that you pre-cache them in an existing base image to save bandwidth. Custom base vagrant images can be easily be built with vagrant-builder, but this process is currently undocumented.
I’ll try to write-up a post on this process if there are enough requests. To keep you busy in the meantime, I’ve published a CentOS 7 vagrant base image that includes docker images for CentOS and Fedora. It is being graciously hosted by the GlusterFS community.
What other magic does this all do?
There is a certain amount of magic glue that happens behind the scenes. Here’s a list of some of it:
- Idempotent /etc/hosts based DNS
- Easy docker base image installation
- IP address calculations and assignment with ipaddr
- Clever cleanup on ‘vagrant destroy‘
- Vagrant docker base image detection
- Integration with Puppet
If you don’t understand what all of those mean, and you don’t want to go source diving, don’t worry about it! I will explain them in greater detail when it’s important, and hopefully for now everything “just works” and stays out of your way.
Future work:
There’s still a lot more that I have planned, and some parts of the Vagrantfile need clean up, but I figured I’d try and release this early so that you can get hacking right away. If it’s useful to you, please leave a comment and let me know.
Happy hacking,
James
