Methods of installing Puppet are covered in the documentation. This is the stuff that isn’t covered.
Before installation, you need to decide which major version to stabilise on. Most importantly, 2.7 is not backwards-compatible with 2.6 due to protocol differences. Specifically, 2.7 agents cannot connect to 2.6 masters, as the latter do not support the new RESTful API. (Vice-versa should work according to Puppetlabs standard upgrade advice, but don’t count on it.) This is a critical consideration if you need to run a multi-platform environment, even if it only differs across OS versions.
Whether you use 2.6 or 2.7 (0.25 is out of the running for all intents and purposes here; 2.6 RPMs are even available for EL4), it is critical that you pick one and plan to deploy it uniformly across all your nodes, including the masters. That means confirming that the version you choose is readily available across all your platforms. For example, if you use Ubuntu 11.10 and install the Puppet agent via apt, your Puppet master had better be running 2.7 as well. Which may be a problem if the rest of your infrastructure is already using 2.6.
In addition, think ahead and plan your future upgrade strategy, because it is quite possible that one or more of your existing install sources will be orphaned.
Your installation choices, assuming you aren’t paying for Puppet Enterprise, are:
- Puppetlabs repo
-
Pros: Always up to date; contains all dependencies.
Cons: Only supports common Linux distros; dependencies may conflict with other repos, including the base OS ones (e.g. ruby, augeas packages). - Vendor distro
-
Pros: You already have it; guaranteed compatibility with rest of distro.
Cons: May not be latest version (e.g. EPEL on 2.6); may be out of sync with repos for other platforms. - Third party repo
-
Pros: May be more up to date than vendor distro; may retain older versions
for compatibility.
Cons: You’re at the mercy of the third party. - Gem
-
Pros: Works anywhere; install any version; supports non-Linux platforms.
Cons: Not recommended by Puppetlabs; not integrated with vendor packaging; may not use normal file paths.
As an example, my current strategy is:
- Puppet 2.6.
- EPEL packages on EL5/6 releases (which are thankfully currently in step).
- Dag Wieers 2.6 RPM on legacy EL4 installs (or use 0.25 from EPEL 4 and keep manifests backwards-compatible, which principally means avoiding parameterised classes).
- Solaris 10: Use Ruby 1.8 SVR pkg from Sun Web Stack 1.5 and install Puppet/Facter from Gems. Web Stack was a good thing, so obviously Oracle discontinued it. Failing that, my only suggestion would be something like Blastwave.
- Solaris 11/OpenIndiana: Surprisingly, Gems. Wot no distro package yet?
- Manually install older 2.6 package from archive on Ubuntu 11 (will not be an option going forward). Fortunately, this isn’t (yet) in general use.
My update strategy to 2.7 presumes these sources will continue to be available (except EL4, which will probably become unsupported by our Puppet install), providing both EPEL repos remain compatible. (Although EPEL5 staying on 2.6 while EPEL6 moves ahead would be nasty, as we’d have to update all our Puppet masters.) (Ideally, Red Hat would also update or backport critical fixes to the version of Ruby they currently ship in EL5.)
Bizarrely, we actually rely on the Puppetlabs repo for MCollective with RabbitMQ, since EPEL doesn’t contain all the necessary packages. Although even the Labs repo is missing rabbitmq-plugin-amqp. We’re not using MCollective outside of Linux platforms, so this is workable.
Other bubbles
- Michael Stahnke’s proposed strategy to ‘fix’ Puppet in EPEL.