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.conffile to replace the standardpuppet.conffile. Puppet is not placed on the path and can only be called using a fully-qualified path. This uses thevagrant-setup/puppet-install.shscript. - Install modules from forge - Installs modules from forge based on the
forge-modulesfiles inpuppetandpuppet/environments/*(where*is the name of the current environment). The environment name is specified within theVagrantfile. This uses thevagrant-setup/puppet-modules.shscript. - Run
puppet apply- Runs thepuppet applycommand for the current environment. After this has run the machine will be provisioned and ready to use. This uses thepuppetdirectory.
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
Vagrantfilealong with thevagrant-setupandpuppetdirectories into your repository. Instead of copyingvagrant-setup,.gitmodulescan be copied instead (but this will add a submodule to your project). - Add the contents of the root
.gitignoreand.gitattributesto your respective files. - Modify the
forge-modulesfiles to include a LF separated list of the modules needed from forge. - Modify the
manifestsandmodulesdirectories 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.