A separate lifecycle for Puppet modules in Satellite 6

Since it's initial release in September of 2014, Satellite 6 has offered
a complete systems management solution that includes Puppet for configuration
management. The built-in Puppet master on the Satellite can service hundreds of
clients. When scaling out is required, adding additional capsules allows you
to easily bring up the number of clients your Satellite infrastructure can
service.

Content Views

As part of its content management functionality, Satellite offers a built-in
mechanism to distribute content to its Capsules when scaling out. For RPMs, content views are used to to filter an RPM repository before synchronizing it between Satellite and Capsules. For Puppet modules, content views can do the exact same thing.

You can create a content view with Puppet modules, just like you would do with
RPMs. Based on that content view, Satellite creates a special directory on the
filesystem. This directory is called a 'Puppet environment' and it's where the Puppet master looks for Puppet modules.

If you have created a content view with RPMs and a content view with Puppet
modules, the choice then becomes how to assign that Puppet module content view to your systems. You basically have two options, composite content views and Puppet only content views.

Option 1: Composite Content Views

You can combine the RPM content
view and the Puppet module content view into something called a composite content
view. A composite content view is simply a content view built out of specific
versions of other content views instead of individual repositories.

The composite content view, or CCV as they are often called, is then assigned to hosts through
a hostgroup. All members of that hostgroup get access to the RPMs in the CCV as
well as any Puppet modules that are in there.

As an example, the image below shows a composite content view, consisting of an
RPM based content view called "cv_rhel7_base" and a Puppet module content view
called "cv_puppet3_modules".¹

Shown in this next image is the hostgroup configuration, where a CCV called
"CCV_RHEL7_GENERIC" has been assigned to the hostgroup. As you can see, Satellite
has pre-populated the Puppet Environment field with the Puppet environment that
was created based on CCV_RHEL7_GENERIC.²

Option 2: Using a Content View as a Puppet Environment directly

The other option is to make use of the fact that Satellite creates a Puppet
environment from the Puppet module content view the moment you publish it.

Each host and each hostgroup in Satellite 6 has a configurable option to set
the Puppet environment it is associated with. As shown searlier, by default
this is set to the Puppet environment based on the main content view for that
host or hostgroup.

You can, however, associate the host or hostgroup with whatever Puppet
environment you want, including the one created for the Puppet module content
view we created earlier.

The example image below shows another hostgroup configuration. This time the Puppet Environment setting has been changed to use the Puppet environment
Satellite created based on the cv_puppet3_modules content view.

Which one to pick?

Both ways of managing Puppet modules have their advantages and disadvantages.
The main advantage, and the reason it is mentioned in the so-called 10 Steps
document, is that using the CCV allows you to promote all of your content (RPMs
and Puppet modules) as a single entity. This means that the combination of RPMs and Puppet modules that was tested together can be moved into production as a whole.

The downside is that for every change in the Puppet module content view, you
have to publish and promote the whole CCV, which also means publishing and
promoting thousands of RPMs.

This makes it useful for slower moving, mature code bases of Puppet code, or
very critical environments that require very rigorous testing. The more CCVs
you need to maintain that share the same modules, the more attractive the
second option, the Puppet environment, becomes.

Using a Puppet module content view as a Puppet Environment directly makes it
easy to iterate quickly during development of your Puppet modules. Especially
during the initial stages of implementing Puppet in your environment, this can
be very useful.

However, your RPMs and Puppet modules are no longer published and promoted
through your lifecycle environments as a single entity. In how far that is
important, differs from infrastructure to infrastructure.

Further reading

A while back, I wrote a blog on this page about using r10k as part of your
Puppet development workflow with Satellite 6. If you prefer to use r10k, take
a look at that blog here.

Last July, at Red Hat Summit, Rich Jerrido, Chris Milsted and myself talked about migrating an existing Puppet environment into Satellite 6. One of the topics we covered during that talk, was the separate Puppet module content view. You can find a recording of that talk on Youtube.