The heart of the control repository is the Puppetfile. The Puppetfile acts as a list of Puppet modules to be imported on each run of r10k and deployed into a Puppet environment matching the branch name of the control repository. It allows us to bring in modules from two places: the Puppet Forge and remote Git repositories.

Pulling modules from the Puppet Forge can be written in shorthand, and at the very top of the file you can select a location to search for Forge modules. By default, the control repository will direct us to https://forge.puppet.com, which allows us to write the module we want to bring in in shorthand. Entering mod "puppetlabs/ntp" in the Puppetfile will pull in the latest version. By simply adding a version, such as mod "puppetlabs/ntp", "7.1.1", r10k will ensure that only a specific version from the Forge is deployed to an environment. It is generally considered a best practice to always include a version with Forge modules, so as to not deploy a new major version into an environment unexpectedly.

Additionally, we can point directly to Git repositories. The most common use of this is for Puppet modules developed internally by a user or an organization. Like the Forge, we can specifically target a version of a Git repository and deploy it into an environment. The following is an example of this:

mod 'ourapp',
  :git => '[email protected]:ourapp.git',
  :ref => '1.2.2',

Each line of this entry into the Puppetfile actually signifies something to r10k. The first line, mod 'ourapp', tells r10k to deploy this repository under the name 'ourapp', and will deploy the module as that name. This name must match the namespace of the module, and, in this case, config.pp would need to contain class ourapp::config.

The :git reference tells r10k where to go to retrieve the code. r10k must have SSH keys available to reach this repository, unless the repository allows for anonymous cloning. The ref tag will actually search for commits, git tags, and branches, until it finds one that matches the reference. If this repository contained a git tag named 1.2.2, r10k would use that particular version of code. Note that this method of calling the repository can be troublesome if there is a branch named 1.2.2 and a tag named 1.2.2. ref is a shorthand that allows you to call a tag, branch, or commit, but they can also be directly called by the :tag, :branch, or :commit lines, respectively.

The following code is an example of a Puppetfile that provides the following:

• Sets the Forge to the HTTPS version of forge.puppet.com
• Includes the latest puppetlabs/ntp
• Includes puppetlabs/stdlib version 4.25.1
• Includes puppetlabs/nginx version 0.11.0
• Includes three internal applications, called by branch, tag, or commit

forge "https://forge.puppet.com"

# Forge Modules
# Always take latest version of NTP, notice no version listed
mod "puppetlabs/ntp"

# Specific versions of stdlib and nginx.
mod "puppetlabs/stdlib", "4.25.1"
mod "puppetlabs/nginx", "0.11.0"

# Modules from Git

# Pointing to Master Branch
mod 'ourapp',
  :git    => '[email protected]:ourapp.git',
  :branch => 'master',

# Pointing to the 1.2.2 tag
mod 'ourapp2',
  :git => '[email protected]:ourapp2.git',
  :tag => '1.2.2',

# pointing to an explicit git commit
mod 'ourapp3',
  :git    => '[email protected]:ourapp3.git',
  :commit => '0b1ae47d7ff83489299bb7c9da3ab7f4ce7e49a4',