A set of scripts to set up a vagrant machine using a standalone puppet specification.
There are three key stages to installation, each handled by a different provisioner:
- Install Puppet - Installs the latest release of Puppet onto the virtual machine, and links the
puppet/puppet.conf
file to replace the standardpuppet.conf
file. Puppet is not placed on the path and can only be called using a fully-qualified path. This uses thevagrant-setup/puppet-install.sh
script. - Install modules from forge - Installs modules from forge based on the
forge-modules
files inpuppet
andpuppet/environments/*
(where*
is the name of the current environment). The environment name is specified within theVagrantfile
. This uses thevagrant-setup/puppet-modules.sh
script. - Run
puppet apply
- Runs thepuppet apply
command for the current environment. After this has run the machine will be provisioned and ready to use. This uses thepuppet
directory.
This repository includes an example of the LAMP stack being installed in the development environment only. In a production environment then nothing will happen. To support this a forwarded port is also set. This can be safely removed.
When cloning the repository, ensure the --recursive
option is used to ensure the puppet scripts are available.
- Copy the
Vagrantfile
along with thevagrant-setup
andpuppet
directories into your repository. Instead of copyingvagrant-setup
,.gitmodules
can be copied instead (but this will add a submodule to your project). - Add the contents of the root
.gitignore
and.gitattributes
to your respective files. - Modify the
forge-modules
files to include a LF separated list of the modules needed from forge. - Modify the
manifests
andmodules
directories to suit your code. Follow the standard puppet documentation to do so.
To run, use the command vagrant up
to start the machine. Vagrant and a virtualization provider such as VirtualBox will need to be installed. To re-run puppet provisioning, run vagrant up --provision
which will boot the machine, if turned off and then puppet (as well as checking for updated modules from forge).
The solution in it's current form does restrict some behaviours for the sake of simplicity.
The contents of puppet/environments/*/modules
is not committed, meaning that any modules added in there do not form part of the code repository and instead must be specified within the forge-modules
files either globally or for that environment.
Manifests are unaffected by this so a practical workaround would be to place your own modules in puppet/modules
and then include them in the environment specific manifest.
This is not an issue as such but a point of different from how vagrant would normally behave with a puppet provisioner when not using environments. Be aware that there is no manifest file which is not environment specific (which will lead to the inevitable duplication of code, unless some very clever use of modules is employed).
To reduce the amount of applications installed outside of Puppet, the only application installed is puppet itself. As such, applications such as librarian-puppet are not used here, and the syntax of forge-modules
files does not allow a server to be specified. This only allows modules from the Puppet Labs maintained forge server to be installed. This could be overridden in either puppet.conf
or environment.conf
using the module_repository
setting.
This means that modules can only be installed from a single source, rather than multiple ones as other solutions, which require more dependencies, may permit.
The environment is hard coded into the Vagrantfile
and, as such, has to be changed manually. In cases where a single Vagrantfile
is used for multiple machines then care will be needed in modification to ensure that the correct environment name is used.