It has been a while since the PuppetConf 2014 ended in San Francisco and there are lot of news that came out of it as usual. But, the biggest news is during the keynote that Luke Kanies, CEO of PuppetLabs announced there will be a new Puppet Server. A new Puppet Server? Yup. A Puppet Server and its not the same as our current Puppet Master. Curious on what this means I decided to check out the preview. All my opinions stated below are my own and does not reflect any of OlinData or PuppetLabs.
Language
When Luke announced the new Puppet Server in PuppetConf 2014 here, what caught my eye was they are rewriting it in Clojure and using JVM. I'm not a big fan of JVM but they have their own reservation about it. I'm not going to say I'm an expert on Clojure or JVM but Puppetlabs has been using it for a while now with PuppetDB. PuppetDB has been excellent on that premise but yet I wonder why the language change? In their blog post here where Chris Price lays out the details of Trapperkeeper, the Clojure framework used in Puppetlabs. There are a lot of interesting comments on how it would work with Puppet. Our CEO Walter Heck also wrote a blog post here on what he thought about Clojure and Trapperkeeper. As stable as Clojure and JVM has been proven with PuppetDB, I'm just not a fan where it takes a while for the process to startup. When starting or restarting the service, it'll be at least 30 seconds before you can connect to the service. 30 seconds is a long time for a service to start.
Performance
The first thing that I would test for the Puppet Server is the performance. As I mentioned earlier, PuppetDB is also built on top of JVM and Clojure and it has performed remarkably which got me thinking how would the new Puppet Server perform? Comparing both Puppet Master and Puppet Server setup where an agent is classified with a heavy duty Puppet module, I'd say that the Puppet Server performs a lot faster compared to the Puppet Master. It can be just a couple seconds faster but hey, it is an improvement nevertheless! Especially when multiplied with hundreds or thousands of agents. I have yet to test it under a full load though. With that said, if it can improve the performance that much even being a preview version, I can't help to wonder how the final release would turn out to be. Judging based on all the Puppet releases, I'd dare say it will improve the performance tremendously. Something to look forward to!
Configuration
Seeing how Puppet Server is intended to be a drop-in replacement for the Puppet Master, another quirk(s) that I have is the configuration folders. Quoted from the Puppet Server's Github documentation:
Puppet Server honors almost all settings in puppet.conf, and should pick them up automatically. It does introduce new settings for some "Puppet Server"-specific things, though
This statement got me confused for a moment, almost all and not all ? It was made clear to me after I've setup the Puppet Server. There are now 2 folders where you can configure your Puppet Master/Server. One in the usual path of /etc/puppet/ and the other in /etc/puppetserver/. So now we have 2 configuration folders and let's just say while Puppet Server's configuration is more extensive, it gets pretty messy as you have so many configuration files for various purposes and on top of that you are still using the legacy puppet.conf. I wonder what is the rationale where Puppetlabs does not make use of the existing configuration file or setup instead of introducing a whole new set?
Puppet Components
Now, in this section I'd share with you my findings on Puppet's components itself. As part of being a drop-in replacement for the current Puppet Master, Puppetlabs is removing the need for Apache and Passenger in favor of a built in webserver (Trapperkeeper). Kudos to this as now we do not really have to rely on an external component/application to get Puppet Master/Server running in an optimal condition. However, what if we do not want to run it as a webserver but as a daemon instead? How do I decouple all the components of Puppet (CA, daemon, etc)?
Guess this is where the configuration comes in handy. Although I expressed my opinion on how bloated the configuration became, it also gave me a simple way to enable or disable a specific Puppet component on the server. I can have CA or the Puppet Server process running on the server simply by commenting or uncommenting specific lines in the configuration files.
Secondly, what of the custom written modules which usually contains custom plugins, facts, providers, type, and etc? They are written in Ruby and how does Puppet Server handles backward compatibility? Chris Price gave a brief explanation on what is under the hood for the new Puppet Server here but what caught my eye was this line:
Thanks to the excellent JRuby project, we’re able to run portions of the existing Puppet Ruby code from inside of our Clojure application. To achieve this, during initialization, we create a pool of several JRuby interpreters. You can think of these as embedded Ruby virtual machines in which we can execute portions of the existing Puppet Ruby code.
Now, I guess my questions are answered. Puppet Server is backward compatible and I suppose we can still write our modules' providers, types, facts, and etc in Ruby. Extension points are being introduced and metrics are now introduced to provide a more robust insight on what is happening within Puppet. It also allows us to keep writing custom codes with Ruby instead of using Clojure. With more extension points opened up, we can definitely develop more custom components for Pupppet. This got me interested even more as OlinData has just released OpsTheatre not long ago and I would love to see the integration between the both of them.
Puppet Apps
Together, both Luke and Chris introduced the new concept of Puppet Apps with the preview release of Puppet Server. Puppet Apps is where PuppetLabs now separate the core application from the features. This allows PuppetLabs to continue development on the existing core product without affecting the features. Another plus point here. This meant that any new development or new features integrated with the application's core will not break the overall application and allows developers to build more features.
The first app built is the Puppet Node Manager which is only available on the Puppet Enterprise allows node classification based on rules. Nifty! Too bad it is not released for Open Source or I might've missed the announcement somewhere on that.
Final Word
Puppet Server is just at a release preview state and there are more to come. As many quirks I have and there are also a lot of improvements that comes with it. It is still too early to say whether Puppet Server replacing Puppet Master is a progressive or regressive improvement for PuppetLabs and configuration management field in general. For now I'll just sit back and watch the spectacle to unfold before me.