Ask Your Question

Performance improvements without updating to Puppet Server?

asked 2015-04-29 18:50:35 -0500

ramindk gravatar image

It will be some time before our system is ready to move to Puppet Server aka Puppet 4.0. However we would be interested in anything that gets us closer to the performance increase in Puppet Server without large changes. Also would be nice to have the changes isolated to the master and require no agent changes. What are our options?

edit retag flag offensive close merge delete


Puppet Server 1.0.x is compatible with the Puppet language 3.7.x, so you don't need to move to Puppet 4 to run Puppet Server.

rw gravatar imagerw ( 2015-06-24 17:02:37 -0500 )edit

That assumes end user is running Puppet 3.7.x, all internal code works on jruby, and any number of changes won't be a factor. In our case we're getting near PuppetServer performance without changing an entire stack that we already understand.

ramindk gravatar imageramindk ( 2015-06-25 00:06:44 -0500 )edit

That may be true, but the point stands that Puppet Server doesn't require Puppet 4.

rw gravatar imagerw ( 2015-06-25 00:54:23 -0500 )edit

I'd consider PuppetServer to be Puppet 4. Not sure why you think it isn't.

ramindk gravatar imageramindk ( 2015-06-25 01:31:55 -0500 )edit

As @rw stated, Puppet Server 1.x is intended for use with Puppet 3.x agents. Only Puppet Server 2.0 and greater require use of the new Puppet 4 compiler.

cprice404 gravatar imagecprice404 ( 2015-06-25 04:40:21 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2015-04-29 18:50:46 -0500

ramindk gravatar image

updated 2015-09-18 17:44:14 -0500

I have wanted to write this how-to forever. Unfortunately it's complicated and not easy to understand unless you've had experience with Ruby, rvm, Passenger, and gem installing your Puppet master. Now that Puppet Server has been released most people will install it and enjoy better performance than a Ruby 1.8.7 backed master. However many admins might not be in position to upgrade. This may be a good alternative to stretch the life of their existing Puppet install.

Explanation with Pros and Cons

The limiting factor of the Puppet master process is the speed of the Ruby virtual machine. Each major release of Ruby (1.9, 2.0, 2.1, etc) has supposedly increase the speed of the VM by 30% or better over the previous release. I won't make any speed claims, but any Ruby update will be noticeably faster than 1.8.7. Part of the reason Puppet Server moved to JRuby was to get access to the faster and more mature Java virtual machine.

In addition to performance the ability to control the version of Ruby you master runs within may make it easier to transition to new distro versions or even different OS. Ruby 1.9+ will preserve insert order for hashes which can make complicated config templates simpler.

The downsides of this method are few, but significant. All puppet commands that would be run on the master will need to be run as one user within the correct version of Ruby and reference the custom puppet.conf so the correct paths are used. Additionally the system may be harder to troubleshoot and understand. Security updates will also be harder to apply because the Puppet master will not be based on system packages, but locally compiled gems and Ruby binaries. example

ssh pmaster@puppetmaster01
puppet cert generate blah blah -f /etc/pmaster/puppet.conf

Create account for your master to use

I recommend installing your master into its own user so that it shares nothing with the local puppet agent user. Also you will need to run certain commands within the Ruby environment your master was built into. This is usually simpler if everything is encapsulated as one user.

sudo adduser pmaster
sudo mkdir /etc/pmaster 
sudo chown pmaster: /etc/pmaster

copy existing master files over

It's much simpler to take a working system and copy the file over to your new master. I HIGHLY recommend building a completely new master rather than re-purposing your existing Puppet master. You can generate new certs instead. If so just follow the standard Puppet tutorials adding a -f /etc/pmaster/puppet.conf or just copy them into place as below.

sudo mkdir -p /home/pmaster/puppet/var
sudo rsync -av /var/lib/puppet/ssl/ /home/pmaster/puppet/var/ssl/
sudo chown -R pmaster: /home/pmaster/puppet

install rvm, rbenv, or alternate ruby

I've always used RVM and it's not without it's problems. If you're more comfortable with rbenv or other ... (more)

edit flag offensive delete link more

answered 2015-06-25 04:47:15 -0500

cprice404 gravatar image

The Puppet Server 1.x series is targeted for use with Puppet 3.x agents (and uses the Puppet 3.x catalog compiler). The latest version of 1.x at the time of this writing is version 1.1.1, which should be available in the main Puppet Labs apt/yum repos:

You should be able to try this out in your current environment by simply (temporarily) stopping the service where you are running your Passenger-based Puppet Master, and installing the 'puppetserver' package. (Not a bad idea to try this in a test environment first, if you can... and if you are doing anything complicated with your Puppet CA you may need to take a few additional steps.)

If you try this and it doesn't work for you, you should be able to simply stop the 'puppetserver' service and restart your Passenger-based master.

The Puppet Server 2.x series is where we introduce support for Puppet 4.x agents and use the Puppet 4.x compiler. These packages (along with Puppet 4.x itself) are in the new 'Puppet Collections' repos:

Puppet Server 2.1.x and greater should still be able to handle requests from Puppet 3.x agents, but will use the Puppet 4.x compiler, so may require changes to your manifests.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-04-29 18:50:35 -0500

Seen: 830 times

Last updated: Sep 18 '15