Puppet environment and module deployment
r10k provides a general purpose toolset for deploying Puppet environments and modules. It implements the Puppetfile format and provides a native implementation of Puppet dynamic environments.
r10k supports the following Ruby versions:
- 1.8.7 (POSIX minimum version)
- 1.9.3 (Windows minimum version)
- 2.0.0
- 2.1.0
For general use, you should install r10k from Ruby gems:
gem install r10k
r10k help
If you have more specific needs or plan on modifying r10k you can run it out of a git repository using Bundler for dependencies:
git clone git://github.com/adrienthebo/r10k
cd r10k
bundle install
bundle exec r10k help
Puppet Enterprise uses its own Ruby, so you need to use the correct version of gem when installing r10k.
/opt/puppet/bin/gem install r10k
r10k help
r10k deploy environment -p
r10k deploy environment
r10k deploy environment your_env -p
r10k deploy environment your_env
r10k deploy display
r10k deploy display -p
r10k can operate on a Puppetfile using the same syntax as librarian-puppet uses. Puppetfiles are a simple Ruby based DSL that specifies a list of modules to install, what version to install, and where to fetch them from. Unlike librarian-puppet dependency resolution is not yet implemented but is on the roadmap.
Puppetfile based commands are under the r10k puppetfile subcommand.
Puppet modules can be installed from any valid git repository:
mod 'rsyslog', :git => 'git://github.com/puppetlabs-operations/puppet-rsyslog.git'
You can deploy a module from a specific branch, tag, or git ref. By default r10k
will track master and will assume that you want to keep the module up to date.
If you want to track a specific branch, then
Examples:
# track master
mod 'filemapper',
:git => 'git://github.com/adrienthebo/puppet-filemapper.git'
# Install the filemapper module and track the 1.1.x branch
mod 'filemapper',
:git => 'git://github.com/adrienthebo/puppet-filemapper.git',
:ref => '1.1.x'
# Install filemapper and use the 1.1.1 tag
mod 'filemapper',
:git => 'git://github.com/adrienthebo/puppet-filemapper.git',
:ref => '1.1.1'
# Install filemapper and use a specific git commit
mod 'filemapper',
:git => 'git://github.com/adrienthebo/puppet-filemapper.git',
:ref => 'ec2a06d287f744e324cca4e4c8dd65c38bc996e2'
Puppet modules can be installed from the forge using the Puppet module tool.
# This is currently a noop but will be supported in the future.
forge 'forge.puppetlabs.com'
# Install puppetlabs-stdlib from the Forge
mod 'puppetlabs/stdlib', '2.5.1'
r10k supports Dynamic Environments (see below), but simple environment structures are also supported.
The basic structure of an environment that uses a Puppetfile to install modules is
.
|-- manifests
|-- site.pp
|-- Puppetfile
|-- .gitignore
site.pp would contain your node definitions, and the Puppetfile would specify the modules to be installed. r10k automatically creates the 'modules' directory when it applies the Puppetfile.
It's important to put the modules directory in .gitignore so that git doesn't accidentally put it into the repo.
modules/
r10k implements the dynamic environment workflow. Given a git repository with multiple branches r10k can create an environment for each branch. This means that you can use git with the normal branch-develop-merge workflow, and easily test your changes as you work.
Deployment commands are implemented under the r10k deploy subcommand.
r10k makes the assumption that Puppet modules are stored in subdirectories of the Git repository. These directories are all loaded into the Puppet master with the modulepath directive.
For example, your Git repository would have a structure something like this:
.
├── Puppetfile # An optional Puppetfile
├── dist # Internally developed generic modules
└── site # Modules for deploying custom services
In order to use dynamic environments, your Puppet masters will need to be configured to load manifests and modules relative to the requested environment:
[master]
modulepath = /etc/puppet/environments/$environment/modules:/etc/puppet/environments/$environment/dist
# If you use a top level manifest dir
manifestdir = /etc/puppet/environments/$environment/manifests
# If you use a specific site wide manifest
manifest = /etc/puppet/environments/$environment/manifests/nodes.pp
Note that these settings go into the [master] section; you don't need to
explicitly configure an environment section for each environment you want to
use. (But you can if you want.)
r10k can implement a hybrid workflow with dynamic environments and Puppetfiles.
If a Puppetfile is available at the root of a deployed environment, r10k can
create and manage the modules directory within your Git repository.
It's recommended that you add /modules to your project .gitignore.
A deployed environment with a Puppetfile will look something like this:
.
├── Puppetfile # An optional Puppetfile
├── dist # Internally developed generic modules
├── modules # Puppet modules deployed by r10k
└── site # Modules for deploying custom services
It is also possible to set an alternate name/location for your Puppetfile and
modules directory. This is useful if you want to control multiple environments
and have a single location for your Puppetfile.
Example:
PUPPETFILE=/etc/r10k.d/Puppetfile.production \
PUPPETFILE_DIR=/etc/puppet/modules/production \
/usr/bin/r10k puppetfile install
r10k uses a yaml based configuration file when handling deployments. The default location is in /etc/r10k.yaml and can be specified on the command line.
# The location to use for storing cached Git repos
:cachedir: '/var/cache/r10k'
# A list of git repositories to create
:sources:
# This will clone the git repository and instantiate an environment per
# branch in /etc/puppet/environments
:plops:
remote: 'git@github.com:my-org/org-shared-modules'
basedir: '/etc/puppet/environments'
Multiple git repositories can be specified, which is handy if environments are broken up by application. Application 1 could have its own environment repository with app1_dev, app1_tst, and app1_prd branches while Application 2 could have its own environment repository with app2_dev, app2_tst, app2_prd branches.
You might want to take this approach if your environments vary greatly. If you often find yourself making changes to your Application 1 environments that don't belong in your Application 2 environments, merging changes can become difficult if all of your environment branches are in a single repository.
This approach also makes security easier as teams can be given access to control their application's environments without being able to accidentally impact other groups.
# The location to use for storing cached Git repos
:cachedir: '/var/cache/r10k'
# A list of git repositories to create
:sources:
# This will clone the git repository and instantiate an environment per
# branch in /etc/puppet/environments
:app1:
remote: 'git@github.com:my-org/app1-environments'
basedir: '/etc/puppet/environments'
:app2:
remote: 'git@github.com:my-org/app2-environments'
basedir: '/etc/puppet/environments'
The original impetus for r10k is explained at http://somethingsinistral.net/blog/rethinking-puppet-deployment/
Please see the CHANGELOG for a listing of the (very awesome) contributors.