Start a blog, please
Less of these promotional devops articles please. Either pay for advertising or start a blog.
QA's Kat McIvor will be taking to the stage at Continuous Lifecycle London to talk about automating security. But her skills don't end there. If config management's your thing, here's Kat's take on getting started with Puppet. Puppet is another configuration management tool available as part of the DevOps toolbox. It uses a …
Why "importantly"?
Actually, the distro I work with is openSUSE which has Puppet in one of the repos. The easiest way to install for SLES and openSUSE is to add the repo for Puppet according to your version from https://software.opensuse.org/package/puppet (I used the 1-click install).
I was then working along with the video at https://www.youtube.com/watch?v=kBITFtHI8_U but bear in mind that the version shown is for openSUSE 11.4 so some of this will not be applicable; for example restarting the puppetmaster needs to be done via... hack, spit... systemd and systemctl, and some of the files have changed since then too, but it does work.
As for RHEL and direct relatives, Puppetlabs have a fairly comprehensive installation and usage quide for you. https://yum.puppetlabs.com/
But it's a real pain to use and a massive drag on development.
I disagreee. I've found Puppet very useful, quite simple[1], and very useful for accelerating rollout[2].
As with all these technologies, a little time up-front spent learning the tool goes a very long way...
Vic.
[1] I did fail to get a single rule working to remove the "Addr=127.0.0.1" line in the standard RHEL senmdail.mc line, then rebuild the config and restart the server. But I'm sure someone more skillful than I could do it.
[2] I run the manifest against a designated staging machine first, to do tests is a "production" environment. Then, once that's proven, it's just a case of changing the manifest file on the real server to do a rollout. That really does prevent finger trouble on release day...
I've got about 1000 nodes running puppet here, and it is handy as a way to easily get packages on and off and do simple configuration, but for 90% of services there comes a point where you end up just creating a puppet File resource to deliver a bash script and then an Exec resource to run it, because the native ruby-like manifest language is such a bloody pain to actually write complex conditionals in.
I like Puppet. Massively prefer it to Chef, having found Chef Server to be so incredibly flaky on RHEL. Puppet just works. Throw in Passenger and it's quick enough in a 400 node environment. Start getting into loads of exported resources though and it starts bogging.
Most of the time I find using Puppet modules to be a complete PITA, making something as simple as an Apache configuration across 50 web servers turn into 10 separate layers of Puppet/Ruby manifests and inheritance. An haproxy configuration, ~700 lines using the Puppet module with the config structure almost unreadable, or a simple config file of half the size that you can read and compare against the haproxy docs. I hate abstracting this stuff into Puppet/Ruby and moving it away from the project's docs. Most of the time I find it easier to just dump some config files and have a service subscription on that, still conditional on facts etc.
Also there's so much snobbery in the Puppet community, "IT SHOULD BE DONE THIS WAY AND I REFUSE TO ANSWER YOUR QUESTION UNTIL..."
How to use puppet in a two page article? It may be the cynic in me, but I half expected the author to be touting puppet enterprise by the end.
But, for devops, puppet ain't that useful for day to day deployments, even less so if you are not paying for enterprise, it's only really good for building out environments.
Another comment here mentioned salt stack, which IMHO is much easier to use and offers more
But, for devops, puppet ain't that useful for day to day deployments, even less so if you are not paying for enterprise, it's only really good for building out environments.
I really disagree with ths.
For build-out, kickstart or similar will do a fine job. Puppet is more about *maintaining* the config in spite of devops...
Vic.