hickey/puppet_workflow repository overview

In addition is can be used to create Puppet environments specifically suited for deploying dynamic environments.

⁠Building the Puppet Workflow Container

If no changes have been made and the container just needs to be build, then the following command can be used to build it.

        rake build

In the event that modifications were made and the container needs to be updated, then one needs to bump the version according to normal semantic versioning rules. Using rake, one can bump the version but should insure that the VERSION file gets committed back to the repo.

        0:0 ᐅ rake -T
        rake build               # Create the puppet_workflow container
        rake version             # Show the current version
        rake version:bump:major  # Bump the major version
        rake version:bump:minor  # Bump the minor version
        rake version:bump:patch  # Bump the patch version
        rake version:set[value]  # Set the version (rake "version:set[1.2.3]")

Once the version has been bumped, the build can be accomplished using the docker build command listed above. Again, don't forget to commit the VERSION file back to the repo with your changes so that future builds can be versioned correctly.

⁠Modes of the Container

The container has different modes of operation to assist in automating the typical Puppet workflow. These modes provide testing and building the Puppet module. In addition, the container will build a complete Puppet environment that is ready to replicate to Puppet masters.

The mode of operation is controlled by a command keyword given after the container name on the Docker run command line. The following commands are currently understood.

• module-test
• module-build
• environment-build

In addition there are a couple of meta commands that provide documentation and inforamtion about the container. They are as follows:

• help / info / readme / README
• version

⁠Command: module-test

The module-test command will execute the puppet-unittest-workflow from the puppet-ci-testing gem. This mode will first run syntax checks against a whole host of file types. If all the syntax checks complete successfully, then Puppet lint will then be run against the Puppet module. Puppet linting has been customized to avoid the most annoying failures and can be further customized by providing an alternative puppet_unittest_workflow.conf. The final phase of testing will execute any included Puppet-RSpec test code.

⁠Command: module-build

Assuming all the test pass, the module-build would be the next command to execute to generate a proper Puppet forge module. The forge module to distribute will be left in the pkg subdirectory of the module directory.

⁠Command: environment-build

The environmental builds are performed using the r10k utility.

⁠Command: help / info / readme / README

Any of the given commands will display this README file that describes how to execute and use the container to automate the Puppet workflow.

⁠Command: version

The version command will simply display the current version of the container at the time of the build.

⁠Starting the Docker Container

docker run -t <VOLUME MOUNTS> <ENV DEFS> puppet_workflow <MODE COMMAND> <MODE ARGS>

⁠Environmental Variables Used

PUPPET_MODULE: Name of the Puppet module to test or build. It is expected to be mounted as /puppet/ when the container starts. If this variable is not set, then the module-test and modsule-build commands expect to have the module name as the first parameter after the command.

PUPPET_CI_CONF: The location of the puppet_unittest_workflow config file. The default location is /usr/local/etc/puppet_unittest_workflow.yaml. If a file is mounted in this location, then the variable need be specified.