The amount of testing that can be done locally is as follows:
bundle install- To get the necessary gems to run tests locally, if you're unfamiliar with Ruby development you may want to use RVM to create an isolated Ruby environment
./check- Will run the rspec-puppet unit tests and the puppet-lint style validation. If you intend to run the rspec-puppet over and over, use
rake spec_standaloneto avoid re-initializing the Puppet module fixtures every time.
- Import your SSH public key into a key
us-west-2region. We have an AMI in us-west-2 that has Ubuntu 12.04, Puppet and a Docker-capable kernel installed for testing
- Make sure your
defaultsecurity group allows SSH (port 22) from the outside world.
- Run the
./vagrant-bootstrapscript locally to make sure your local environment is prepared for Vagranting
Running server spec tests
- Install Vagrant
- Install Vagrant plugins:
vagrant plugin install vagrant-aws vagrant-serverspec
To launch a test instance,
vagrant up ROLE where
ROLE is one of the defined roles.
You can rerun puppet and execute tests with
vagrant provision ROLE repeatedly while the VM is up and running.
To just rerun serverspect without puppet,
vagrant provision --provision-with serverspec ROLE.
When it's all done, deprovision the instance via
vagrant destroy ROLE.
For reasons that Tyler will hopefully clarify at some point, this module maintains
the list of Puppet module dependencies in
need to be kept in sync. When you modify them, you can have the local environment
reflect changes by running
bundle exec rake resolve.
The default branch of this repository is
staging which is where pull requests
should be applied to by default.
+----------------+ | pull-request-1 | +-----------x----+ \ \ (review and merge, runs acceptance tests) staging \ |---------------o--x--x--x----------------> \ \ (manual merge, auto-deploys to prod hosts) production \ |----------------------------o------------->
The branching model is a little different than what you might be familiar with.
We merge pull requests into a special branch called
staging where we can run
Puppet acceptance tests from. Once somebody has code reviewed a pull request it
can be merged into
When a infra project team member is happy with the code in
staging they can
create a merge from
production. Once something has been merged
to production, it will be automatically deployed to production hosts.
For installing agents refer to the installing agents section of the PuppetLabs documentation.
Adding a new branch/environment
"Dynamic environments" are in a bit of flux for the current version (3.7) of Puppet Enterprise that we're using. An unfortunate side-effect of this is that creating a branch in this repository is not sufficient to create a dynamic environment that can be used via the Puppet master.
The enable an environment, add a file on the Puppet master:
modulepath = ./dist:./modules:/opt/puppet/share/puppet/modules manifest = ./manifests/site.pp