Testing Puppet modules in development is always an interesting task. While Beaker exists it's not always the easiest thing to start working with, so a lightweight environment to be able to freely play around with Puppet modules in development is strongly desirable. This project covers some of the approaches I've used in testing my own modules.
Our environment for doing module testing will consist of a few components:
Together these tools make it significantly simpler to pull multiple dependent modules, develop different modules concurrently with different requirements, and create a simple, easy-to-understand workflow.
The workshop repository will be what you are deploying with r10k later. Its sole job is to create a bootstrapping environment within the Docker image you'll be using. It will lay out the prerequisites, invoke your module, and otherwise perform all the work it takes to make your module in development function. Later when documenting how your module is designed to work you can easily reference this repository to see how intricate or simplistic it is, making your life much easier after you get it working. It does not matter what you actually name your repository but for this documentation it will be referred to as the workshop.
Create your workshop repository.
It is strongly recommended to construct its layout with a "roles and profiles" pattern. If you want an example, please feel free to clone puppet-roles-profiles.
To begin your module work, checkout a new branch named modulebranch and change to it.
In that new branch update the Puppetfile to add your module's repository and any other dependencies.
mod 'puppetlabs/stdlib'mod 'yourmodule', :git => 'https://gitlab.com/youruser/puppet-yourmodule'
Installing r10k is very straightforward and you'll likely want to follow the documentation already created, here. However, it is more simply summarized as:
/opt/puppetlabs/puppet/bin/gem install r10k
Create /etc/puppetlabs/r10k/r10k.yaml according to example in documentation.
Edit /etc/puppetlabs/r10k/r10k.yaml to point sources: at your workshop repo.
Edit /etc/puppetlabs/puppet/hiera.yaml to point the :datadir at /etc/puppetlabs/code/hieradata or wherever is desired.
Garethr has a fabulous set of Docker images already built for Puppet with the Puppet Agent installation. One of the most useful for this task will be the puppet-agent image. It is set up by default to run Puppet when invoked, so mounting your logic and hieradata configuration is what you'll want to be doing.
FrozenFOXX's docker-puppet image is not as advanced as Gareth's but does allow you to run a shell by default. If you encounter strange behavior with Puppet or want to specially set up the system beforehand these images are built with these scenarios in mind.
Commit code in your module.
If necessary, update code for invocation of your module in the workshop repository branch, modulebranch.
Redeploy changes locally with r10k (/opt/puppetlabs/puppet/bin/r10k deploy environment -p).
Run the container of your choice.
This is the basic workflow for rapidly testing your module. Depending on how you wish to work with Docker you have a couple different ways to proceed on the final step.
If you're using the puppet-agent image above then Puppet is automatically invoked when you start the container.
If you use the FrozenFOXX docker-puppet image you'll need to manually invoke Puppet once the Docker image is running. Starting the container will be familiar:
docker run -it \ -v /etc/puppetlabs/code/environments/[modulebranch]:/etc/puppetlabs/code/environments/production \ frozenfoxx/docker-puppet \ /bin/bash
At this point you will have a shell in a container which has the Puppet Agent and the codebase already mounted in the default branch location (production) that puppet agent looks for. Running Puppet in this case is as simple as: