That way I could create branches based on this master branch for little proof of concepts like for example an ELK stack.
Virtualization of the machines should be hybrid for both virtualbox and lxc containers depending on the --provider parameter. Default this would be virtualbox.
OS & Virtualization
Based on CentOS I tested both centos 6.x and 7.x using the virtualbox and lxc provider. The boxes used are:
- Vagrant 1.7.2
vagrant plugins ($ vagrant plugin install vagrant-x):
- virtualbox 4.3.26-3
- virtualbox-ext-oracle 4.3.26-5
- vagrant-lxc plugin
If you use virtualbox as virtualization solution the ip addresses of the nodes are staticly been configured in the Vagrantfile. Adopt to your needs if necessary.
For the lxc provider vagrant will locate an ip address provided by the dhcp service you have configured for your lxc setup.
Using the vagrant-hostmanager plugin the hosts file on your local machine as well as those on the vm's are being updated automatically with the new addresses located through vagrant. That way you could use dns names instead of ip addresses.
To have the ability to change the configuration on your local machine using your favorite editor I configured shared folders for the hiera data and puppet-modules in the production environment through rsync. I had to use the rsync provider since the lxc provider doesn't support the ownership/group parameters of the default shared folders of vagrant.
Adding an extra module to the modules directory or changing hiera data on your local machine which you want to be synced to the VM is rather easy. You adapt the hiera yaml file or clone the module to the puppet/environments/production/modules/ directory and perform a manual vagrant rsync.
You could instead of manually sync your changes every now and then also enable the rsync-auto daemon.
I wrote some small tests using serverspec to test if the functionality of the different machines is working as it supposed to be.
To benefit those tests you could install the serverspec gem and run a rake command:
$ gem install serverspec $ rake spec
Initialize your local environment
$ git clone email@example.com:visibilityspots/vagrant-puppet.git $ git clean -d -f -f $ git submodule update --init --recursive
Bringing up the puppetmaster
$ vagrant up puppetmaster
Bringing up a node against the puppetmaster
$ vagrant up client
Bring up everything
Or your could immediatly bring up both nodes by
$ vagrant up --no-parallel
To test the functionality you can run the serverspec tests
$ rake spec
Using the different branches to spin up different proof of concepts
You have to checkout the branch you want to test:
$ vagrant destroy -f $ git checkout puppetboard $ git clean -d -f -f $ git submodule update --init --recursive $ vagrant up puppetmaster $ vagrant up client
When going back to the master branch you will notice that the puppet/environments/production/modules is messed up with the feature branches submodules. You can easily clean this up with
$ git clean -d -f -f
according to the docs:
-d Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory. -f, --force If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to delete files or directories unless given -f, -n or -i. Git will refuse to delete directories with .git sub directory or file unless a second -f is given. This affects also git submodules where the storage area of the removed submodule under .git/modules/ is not removed until -f is given twice.