Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Puppet 3 Beginner's Guide

samzenpus posted about a year ago | from the read-all-about-it dept.

Books 81

sagecreek writes "If you are in charge of a small network with just a few servers, you may still be doing configuration management primarily by hand. And you may take particular pride in maintaining that 'artisan' role. After all, it's mostly up to you to set up new users and their machines, fix current problems, manage the servers and their software, create databases and their user accounts, and try to keep the network and user configurations as uniform as possible despite running several different brands--and vintages--of hardware and software. However, warns infrastructure consultant John Arundel, '[b]eyond ten or so servers, there simply isn't a choice. You can't manage an infrastructure like this by hand. If you're using a cloud computing architecture, where servers are created and destroyed minute-by-minute in response to changing demand, the artisan approach to server crafting just won't work.' In his new book, Puppet 3 Beginner's Guide, Arundel emphasizes: 'Manual configuration management is tedious and repetitive, it's error-prone, and it doesn't scale well. Puppet is a tool for automating this process.'" Read below for the rest of sagecreek's review.Actually, among "UNIX-like systems," there are at least three major configuration management (CM) packages — Puppet, Chef, and CFEngine — plus some other competitors, Arundel notes. He calls them "all great solutions to the CM problem...it's not very important which one you choose as long as you choose one." But he hopes, of course, you will check out Puppet and his new, well-written how-to book.

Puppet 3 Beginner's Guide is structured to help system administrators "start from scratch...and learn how to fully utilize Puppet through simple, practical examples."

Arundel's book places important emphasis on the rapidly closing "divide between 'devs,' who wrangle code, and 'ops,' who wrangle configurations. Traditionally, the skills sets of the two groups haven't overlapped much," he notes. "It was common until recently for system administrators not to write complex programs, and for developers to have little or no experience of building and managing servers."

Today, he points out, system admins are "facing the challenge of scaling systems to enormous size for the web, [and] have had to get smart about programming and automation." Meanwhile, "[d]evelopers, who now often build applications, services, and businesses by themselves, couldn't do what they do without knowing how to set up and fix servers."

Therefore, "[t]he term 'devops' has begun to be used to describe the growing overlap between these skill sets," Arundel emphasizes. "Devops write code, herd servers, build apps, scale systems, analyze outages, and fix bugs. With the advent of CM systems, devs and ops are now all just people who work with code."

Arundel's 184-page Puppet 3 Beginner's Guide has 10 chapters that are smoothly structured with numerous headings, subheadings, short paragraphs, code examples, and other illustrations. He has generated his code examples using the Ubuntu 12.04 LTS "Precise" distribution of Linux. But he explains how to load the software using "Red Hat Linux, CentOS, or another Linux distribution that uses the Yum package system," as well.

Chapter 1, "Introduction to Puppet," explains the software's basic architecture and shows how Puppet deals with large-scale configuration management problems.

In Chapter 2, "First Steps with Puppet," the author details how to install Puppet, create a simple manifest, and apply it to a machine. He also offers some basic Puppet language examples.

Chapter 3, "Packages, Files, and Services," focuses on "how to use these key resource types...and how they work together" and presents "a complete and useful example based on the Nginx web server."

In Chapter 4, "Managing Puppet with Git," Arundel shows "a simple and powerful way to connect machines together using Puppet, and to distribute your manifests and work on them together collaboratively using the version control system Git."

The emphasis in Chapter 5, "Managing Users," is on "good practices for user administration" and implementing them with Puppet. The chapter also covers "how to control access using SSH and manage user privileges using sudo."

The topics covered in Chapter 6, "Tasks and Templates," include using "Puppet's resource types to run commands, schedule regular tasks, and distribute large trees of files." Also covered: "how to insert values dynamically into files using templates."

In Chapter 7, "Definitions and Classes," Arundel explains "how to organize Puppet code into reusable modules and objects. We'll see how to create definitions and classes, and how to pass parameters to them."

Chapter 8, "Expressions and Logic," dives deeper into Puppet code. It "shows how to control flow using conditional statements and logical expressions, and how to build arithmetic and string expressions. It also covers operators, arrays, and hashes."

Chapter 9, "Reporting and Troubleshooting," deals with what the author terms "the practical side of working with Puppet," including diagnosing and solving common problems, debugging the software's operations, and understanding Puppet's error messages.

The final section, Chapter 10, "Moving on Up," wraps up with a range of topics, including how to make Puppet code "more elegant, more readable, and more maintainable." Arundel also offers "links and suggestions for further reading." And he describes nine projects to help you "improve your skills and your infrastructure at the same time." The projects, he says, "provide a series of stepping-stones from your first use of Puppet to a completely automated environment."

Puppet's maker, Puppet Labs, offers some virtual-machine options for learning the software. The choices are: (1) a VXM version recommended for VMware Fusion and VMware Workstation; and (2) an OVF version recommended for VirtualBox "and all other non-VMware virtualization software." Puppet Labs also offers a Puppet Enterprise version of its software that supports up to 10 nodes free.

Along with Linux, Puppet will run on other several platforms, including Windows and Macs,, but you will find little help for those in Arundel's book. You will need to use Puppet Lab's online Mac or Windows documentation. And Windows may not be the greatest of choices. As the documentation notes: "Windows nodes can't act as puppet masters or certificate authorities, and most of the ancillary Puppet subcommands aren't supported on Windows."

It can take a bit of work to get Puppet installed and configured. But once you have it running in a Linux environment, John Arundel's new book can be a solid guide to helping you become both a proficient Puppet user and a more efficient, knowledgeable, and versatile system administrator.

You can purchase Puppet 3 Beginner's Guide from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

81 comments

Sorry! There are no comments related to the filter you selected.

Poor review (5, Insightful)

Score Whore (32328) | about a year ago | (#44094773)

That was a pretty poor review. Giving a summary of the table of contents isn't a review. Additionally it doesn't seem like they recognize that devops and duplicative administration don't fit with a lot of data processing models. There are many organizations that have servers that have a distinct purpose and it doesn't make sense to envision them as just another clone system in "the cloud".

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44094977)

The review should have the date of publishing. Is it from this decade?

How does the book compare to other Puppet books?

Does this book give a real process to handle hundreds of nodes with lots of subtle differences? Or is this like other books which only give trivial examples for one of two unique systems?

Puppet does have some good points (decent internal system authentication infrastructure), but doesn't really work well in large scale environments with lots of similar, but different systems with overlapping functionality.

Re:Poor review (-1)

Anonymous Coward | about a year ago | (#44095107)

Meat Puppet.

Re:Poor review (1)

Steve_Ussler (2941703) | about a year ago | (#44096123)

Publisher: Packt Publishing (April 17, 2013)

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44097371)

Fudge Packt Publishing.

Re:Poor review (1, Interesting)

Desler (1608317) | about a year ago | (#44095197)

Giving a summary of the table of contents isn't a review.

Yeah even by elementary school book review standards this would be pretty poor. This person apparently thought that "book review" means "synopsis".

Re:Poor review (5, Insightful)

Karzz1 (306015) | about a year ago | (#44095279)

Judging from account activity [slashdot.org] , I believe the submitter is a paid slashvertiser.

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44099597)

Reaching a "paid slashvertiser" belief based only on the poster's Slashdot "account activity" means you have just jumped to a conclusion. That's no different than shooting first and asking questions later. Got any actual and wider-ranging proof?

Re:Poor review (0)

Steve_Ussler (2941703) | about a year ago | (#44096117)

:::Giving a summary of the table of contents isn't a review. Since when :)

Re:Poor review (1)

steveb3210 (962811) | about a year ago | (#44096703)

That was a pretty poor review. Giving a summary of the table of contents isn't a review. Additionally it doesn't seem like they recognize that devops and duplicative administration don't fit with a lot of data processing models. There are many organizations that have servers that have a distinct purpose and it doesn't make sense to envision them as just another clone system in "the cloud".

This is why puppet has a very strong inheritance system... We have it broken down as generic server (2 factor/LDAP configs, nagios configs, etc) and then apache_servers which build out the basic web infrastructure and then more specialized configs for one-off speicalized servers... (admin server versus production web servers)



There is pretty much nothing you can do by hand that puppet can't also do - and often it takes just as much time to update a single puppet config file and run the puppet update process as it would be to ssh into the server and make the manual change.

Another advantage is what might go into traditional documentation is now just a puppet configuration.. Oh, fuck, this server crashed? Just roll another in 5 minutes... Who cares about the old one..

Re:Poor review (1)

Score Whore (32328) | about a year ago | (#44098159)

There is pretty much nothing you can do by hand that puppet can't also do - and often it takes just as much time to update a single puppet config file and run the puppet update process as it would be to ssh into the server and make the manual change.

Another advantage is what might go into traditional documentation is now just a puppet configuration.. Oh, fuck, this server crashed? Just roll another in 5 minutes... Who cares about the old one..

And this is the flaw in your argument. There seems to be some assumption that if it's not under control of Puppet or Chef then it's manual. This is completely untrue. Any competent admin automates their administration. I've been doing it for more than a decade.

Second it's not the host OS and host configuration that makes the servers distinct. It's the data. You can't automate ten years worth of data entry and workflow modules. I suppose it would be unfair of me to hold against you the fact that you don't know anything about my operations, but we're not an internet based company. We're doing stuff other than serving up a bunch of vanity gopro videos. We have several large data centers but we also have hundreds of offices around the world and those offices have their own IT infrastructure. Anyone can stand up a server in 10 minutes in their data center. How long will it take you to stand one up Chengdu given that your primary data centers are in the US and Europe and your network line to the remote facility is 512Kb/s?

The absurdity of the proponents of CFengine, Puppet, Chef, et. al. is that they assume no one has ever solved these problems before. What problems that I have are these products going to solve for me? The emphasis is on "problems that I have". It's not sufficient to tell me what a product does, it's whether it solves my problems.

Re:Poor review (2)

steveb3210 (962811) | about a year ago | (#44100653)

There is pretty much nothing you can do by hand that puppet can't also do - and often it takes just as much time to update a single puppet config file and run the puppet update process as it would be to ssh into the server and make the manual change.

Another advantage is what might go into traditional documentation is now just a puppet configuration.. Oh, fuck, this server crashed? Just roll another in 5 minutes... Who cares about the old one..

And this is the flaw in your argument. There seems to be some assumption that if it's not under control of Puppet or Chef then it's manual. This is completely untrue. Any competent admin automates their administration. I've been doing it for more than a decade.

Second it's not the host OS and host configuration that makes the servers distinct. It's the data. You can't automate ten years worth of data entry and workflow modules. I suppose it would be unfair of me to hold against you the fact that you don't know anything about my operations, but we're not an internet based company. We're doing stuff other than serving up a bunch of vanity gopro videos. We have several large data centers but we also have hundreds of offices around the world and those offices have their own IT infrastructure. Anyone can stand up a server in 10 minutes in their data center. How long will it take you to stand one up Chengdu given that your primary data centers are in the US and Europe and your network line to the remote facility is 512Kb/s?

The absurdity of the proponents of CFengine, Puppet, Chef, et. al. is that they assume no one has ever solved these problems before. What problems that I have are these products going to solve for me? The emphasis is on "problems that I have". It's not sufficient to tell me what a product does, it's whether it solves my problems.

You are right, there is nothing you can do with puppet that you can't do with SSH, and 10 years ago things like puppet didn't even exist so it makes total sense for you to be in the situation you're in and it wouldn't make alot of sense for you to switch just for the sake of using puppet.

But it's 2013, if you're starting off new - why would you roll your own when many solutions already exist that have been thoroughly tested and extended to have a rich feature set that you probally wouldn't have time to develop as a day-to-day dev op. Furthermore, Puppet allows for this idea of modules that people can write generic versions of "apache" or whatever and often times you don't even have to write configuration systems yourself but instead you can just clone it off github and customize it to your liking..

Your question about standing up servers is silly - why would a more manual solution be impacted differently than a puppet solution based on in-bound bandwidth? Puppet allows for client/server architecture and if bandwidth was your big concern, you could set up a local puppet machine in Chengdu and build servers in that data center based on that...

I worked in a largeish datacenter in 2002 and wrote alot of SSH scripts to manage those servers - it works but its tedious. The benefits of using something like puppet is enormous.. The company I work for now used to employ a full time sysadmin - now the devs just update puppet as we need and it hardly impacts our workloads given how easy it is for us to maintain...

Re:Poor review (1)

turbidostato (878842) | about a year ago | (#44138441)

"10 years ago things like puppet didn't even exist"

cfengine, anyone? (you know, it's about 20 years old, not just 10)

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44097333)

That was a pretty poor review. Giving a summary of the table of contents isn't a review. Additionally it doesn't seem like they recognize that devops and duplicative administration don't fit with a lot of data processing models. There are many organizations that have servers that have a distinct purpose and it doesn't make sense to envision them as just another clone system in "the cloud".

Um, Puppet may have been written in Ruby, but that hardly makes centralized configuration management a devops process.

Besides the applications sitting on top of your servers, which you swear are unique, what about
enabling/disabling services (and starting/stopping) /etc/issue
sshd_config
syslog.conf
ntp.conf
sudoers
limits.conf
nsswitch.conf
sssd.conf
nslcd.conf
ldap.conf
pam/system-auth
resolv.conf
yum repo configs
local service accounts (absence and presence)
cron jobs
hosts file entries
monitoring agents
remote file shares
in-house admin utilities

That's just some low hanging fruit, and Linux specific examples. We've got almost all of our hairy kickstart post-install script ported to idempotent Puppet-ese now too. Everybody has some one-time scripts that they wish could be enforced for the lifetime of a server, Puppet helps with that. For really complex "needs to be done by hand" stuff (say first time you roll out pam changes), you can use it to enforce assertions, when an admin manually clears the logjam, other steps can fall into place automatically.

These things are either managed or not... once you get configuration management, you'll wonder why anything ever goes into a datacenter without it, trust me.

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44097407)

Same AC here, wanted to add something

Once you get all those high value datacenter-wide sort of configs wrapped up in config mgmt, even if you don't see it now, you will eventually start to see the benefit of putting your one-off stuff in Puppet/Chef too.

It's just different than having a filesystem backup, it's more like finally going back and documenting all the little bit and details that make that system unique, except in an declarative, idempotent script that actually builds the server. Someday you'll have to upgrade or switch the OS on that thing, or build a clone for DR,QA, something, or a manager will get a bug up his butt and ask you to document what makes a particular server such a unique butterfly, and then you'll have justified the time spent Puppetizing it.

Re:Poor review (1)

Score Whore (32328) | about a year ago | (#44098315)

I spent a week in the headquarters of one of the vendors mentioned in these comments training on their product. What I discovered is they just can't recognize that a lot of companies are not technology companies. And those companies' IT organizations aren't in the business of standing up or rebuilding hundreds or thousands of servers per week. And those companies have mature IT organizations. And their servers are often not nicely concentrated in a handful of data centers. After about half the week had gone by and the trainer had spent a fair amount of time describing the data center of the future and we'll be getting our servers delivered a rack at a time and how storage will be all internal and we won't need our expensive SAN, I had a question. During his presentation of how we won't be restoring servers from tape, how we'll just build a new one with the config management tool, I asked at what point it was going to "build" the terabytes of data that the server that just failed contained? He was a bit nonplussed. Automatic application of configuration is easy, we don't need a third-party product for that. If systems are changing in ways that you don't expect then you have a bigger problem than can be solved by reapplying the configuration programmatically.

What I've come to suspect, is that the advocates of these tools have never learned how to do disciplined system administration. Your last comment suggests that unless a system has been subjected to Puppet, then it's some mysterious black box full of scorpions and sharp glass. If that's been your experience, then you've been doing it wrong.

I know you're going to have a bunch of responses to this but please first assume that I'm not a moron and that the organization that I'm part of isn't full of children solving childish problems. The company has over a billion dollars in the bank and you've probably never heard of us. We employ fifteen thousand people worldwide. Our IT organization is over eight hundred people, mostly developers and application support staff. The server administration group is about thirty people across DBA, unix and windows administration teams. We support over four thousand servers and ten thousand databases across our enterprise. But you bet your ass we use automation.

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44098979)

But you bet your ass we use automation.

Of course you are. You may not realise it but you're agreeing with the same people you're railing against: CM proponents aren't talking to you when they propose using Puppet & Chef, they're talking to the people out there who are not.

You're so wrapped up in showing everyone who amazingly smart you are because you automate but at the same time you're waving your arms in the air and beating your chest about how luxurious your neckbeard is because you did it years ago, before any of this configuration management lark came along[1], and you're solving real problems, not "childish" things like...well I'm not sure what, but whatever. I'm sure you're battling space aliens and auditors on a daily basis, Jason Bourne style. Or whatever.

[1]: Of course you probably didn't, because the original cfengine dates from the early-90's, and you probably wouldn't recognise the concept of "idempotent" if it bit you in the ass, but I digress.

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44113095)

I still agree with him though, I think what he's trying to say is, if you think Puppet/Chef are amazing gifts to I.T. then your problems aren't that big or you're not very competent. An optimisation in configuration management shouldn't be causing such a large impact, if it is, someone is doing something wrong. I've seen the hype surrounding it too and when you look into the details it's nothing that special, just another tool.
What industries, and their scenarios, has it actually been a god-send?

Re:Poor review (1)

turbidostato (878842) | about a year ago | (#44138581)

"An optimisation in configuration management shouldn't be causing such a large impact"

I remember that when Windows 95 came to the party I was using whatever window manager used HP-Ux back then, VUE, or something like that -and it was far from a fair comparation (and that's out of my generosity of not trying to remember when it was not Windows 95 but Windows 3.x the one to compare against). But Windows 95 brought that kind of interfaces to the masses and *that* made a big difference.

Puppet, Chef and the likes are bringing CM to the masses (and making obvious some inherent limitations of Microsoft Windows when compared to unix-like systems) and you can bet that *is* quite a large impact too.

Re:Poor review (1)

turbidostato (878842) | about a year ago | (#44138537)

"What I've come to suspect, is that the advocates of these tools have never learned how to do disciplined system administration."

It's quite like Sturgeon's law: 90% of everything is rubish, so you can bet 90% of those advocates are...

But don't fool yourself: infrastructure.org has been up, how much? 10/15 years? and the concepts are already there, so it's nothing fancy new.

"unless a system has been subjected to Puppet, then it's some mysterious black box full of scorpions and sharp glass."

I've been roughly 20 years in the field and well, the plural of anecdote is not statistics and all that, but yes, basically if they are not under CM, they usually are "mysterious black boxes full of scorpions and sharp glass". That I'm kindof an Indy Jones of system administration quite capable of managing mysterious black boxes full of scorpions and sharp glass doesn't change that reality.

"If that's been your experience, then you've been doing it wrong."

There are in the world about seven billions souls, so they outnumber me: most of my experience doesn't come from what I do, but what I see others do.

Using a strategy that depends on the people around you being well above average is usually a bad strategy. It happens that tools like puppet not only don't require people above average beyond the starting steep curve but even they tend to educate people on the proper way of doing these kinds of things -so eventually and ironically they end up being professionals above the average.

"But you bet your ass we use automation."

Of course you do. Now, your next step is doing automation without reinventing the wheel. Those days are already in the past.

Re:Poor review (0)

Anonymous Coward | about a year ago | (#44097429)

Giving a summary of the table of contents isn't a review.

Said no /. reviewer ever.

Re:Poor review (0)

MikeBabcock (65886) | about a year ago | (#44097927)

My thoughts exactly. Terrible review.

This isn't a book review... (2, Insightful)

Midnight_Falcon (2432802) | about a year ago | (#44094785)

This is a slashvertisement..first tells you why you want to learn Puppet and what it's used for, and then gets you to read a book to time invest in learning Puppet which will become your "goto" for all DevOps stuff going forward. The hope being that -- some point, you end up looking into Puppet Enterprise and get out of open source..or you get to the level where you need enterprise and not the open source version, yadda yadda, more people on puppet, the better for their business model, as eventually some will have to go with enterprise for some type of requirement (additional functionality and/or enterprisey support)

Slashvertisement my ass (0)

Tenebrousedge (1226584) | about a year ago | (#44096921)

Shut the fuck up.

What's your alternative? Hand rolling everything? God forbid that someone provide a useful, open-source utility and try to sell support services for it.

Yes, everything should be provided free of charge in all forms, relying only on donations, or just that good feeling of having provided something useful. No sarcasm, and yes, I have my money where my mouth is. I get paid for my time, not for the code I write, and I would consider it personally immoral to do otherwise. If you think that making money off of open source code is wrong, however, you have just put yourself in the category of "more of a zealot than RMS." In other words, you are so far off in looney land as to be utterly divorced from reality. You are so far gone that you're actually a counterexample to Poe's Law.

I can't construct a formal reductio ad absurdum to show that you're a backbiting assmonkey whose ideas hurt open source, but I will let the examples of Google, Red Hat, Canonical, Github, SourceForge, Intel, and the vast number of for-profit business entities that have made the Open Source movement a powerful force in the software market speak for themselves.

Re:Slashvertisement my ass (1)

murdocj (543661) | about a year ago | (#44097533)

Why would it be immoral to write code and then charge for it? Aren't you charging for the time of development, except that you are taking the risk that the software you write might not sell well? What's the difference between getting one or more customers to hire you to write code, and then writing the code, vs. writing the code, and then selling to one or more customers?

Re:Slashvertisement my ass (1)

Midnight_Falcon (2432802) | about a year ago | (#44097929)

It isn't. Puppet Labs' product is great, imho, actually. However, putting in advertisements for free-mium software masquerading as a "Book Review" is less than savory.

Re:Slashvertisement my ass (1)

sagecreek (2860541) | about a year ago | (#44101141)

Slashdot has specific guidelines for structuring and posting book reviews. Anyone is free to write a review and offer it for consideration by Slashdot's editorial staff. I tried out the "Puppet 3 Beginner's Guide" as a Puppet beginner. Then I offered my review as a guide for others who might be (1) considering Puppet and (2) curious about what the author has put inside his book--so they can decide if they want to spend money to buy it or not. You are free to think that somehow rises to the level of a dark, sinister "slashvertisement" conspiracy. And, likewise, I am free to LMAO.

Re:Slashvertisement my ass (1)

Midnight_Falcon (2432802) | about a year ago | (#44097917)

That is a massive straw man and I'm not sure where you got that from.

My comment was pointing out the fact that Slashdot used to have earnest, "Book Reviews", about books on topics like..HTML5, C#, etc...which actually reviewed the book.

Here, we get basically an advertisement for Puppet's functionality. This is going along with all the changes Dice has made to slashdot since its acquisition -- posting a lot of "news" and "book reviews" that's really "marketing." The site already has ads -- they're just trying to further monetize it, by driving down quality of content and mixing content with ads.

That's my gripe. Not any of the things you said. Also, I don't need to use elementary school-esque personal insults to illustrate my opinions.

Re:Slashvertisement my ass (1)

MikeBabcock (65886) | about a year ago | (#44097933)

LMAO you can't even argue the point that was made bu tyou cite latin. Jeez. The point was that the article isn't a review at all... Puppet may be the next best thing since sliced bread, but this review was supposed to be of the book and we all learned nothing about if its any good.

Re:Slashvertisement my ass (1)

Tenebrousedge (1226584) | about a year ago | (#44098543)

bad review != advertisement. Especially for a product that isn't commercial. Parent poster is talking about them hoping to eventually make money off of the attention. If that's an advertisement, so is everything on slashdot.

Re:Slashvertisement my ass (1)

MikeBabcock (65886) | about a year ago | (#44129079)

advertising has nothing to do with commercialization ...

Re:Slashvertisement my ass (1)

Tenebrousedge (1226584) | about a year ago | (#44132857)

Which brings us back to the other point, which is that commercialization is not inherently evil.

Re:Slashvertisement my ass (1)

MikeBabcock (65886) | about a year ago | (#44161683)

You have a real problem with following logical thoughts, don't you? I made no claim that this had anything to do with commercialization (quite the opposite) and you failed to reply to my comment being that this *is* advertising.

Re:This isn't a book review... (0)

Anonymous Coward | about a year ago | (#44116763)

And if you even dare to glance at the book, it will instantly fry your brain and hypnotize you into believing you are a puppet of...Puppet. Is that what you're trying to say?

Artisan? (0)

Anonymous Coward | about a year ago | (#44094907)

Sounds like an underhanded insult posing as grudging respect. Do I win the prize?

Grow up. We already have terms for this. You either configure your servers manually, or you automate it. There is a time and place for both methods, and no reason to permanently "side" with either one.

Re:Artisan? (1)

J.D. (74624) | about a year ago | (#44094991)

The part I find particularly offensive is "[b]eyond ten or so servers, there simply isn't a choice. You can't manage an infrastructure like this by hand."

My machine count is well in excess of 100 and I still have time to read slashdot.

Re:Artisan? (1)

Bigbutt (65939) | about a year ago | (#44095117)

Yea, same here. My team of 4 currently manage about 500 production and production lab (customer integration testing and pre-production testing) systems with another team member managing around 500 dev/sqa systems (we're merging in a few months). We're using OpenView to monitor just the production systems but that leaves production lab systems (which we're still responsible for) and soon the dev/sqa systems to be managed. I have a script framework which manages 15 or 20 scripts per system for data gathering and performance monitoring. I have php scripts I've written to parse the retrieved data and automatically update the inventory database.

It can be done. And it is automated.

[John]

Re:Artisan? (1)

xaxa (988988) | about a year ago | (#44096491)

The sysadmins at work manager the existing servers, but not as well as they could: a UAT environment has a different version of Java, a development server somehow gained a non-GNU tar, one of the two production web servers had a manual quick-fix applied and forgotten about. (They're the best sysadmins we can afford -- we're a charity in London, and it's difficult to compete with the salaries the financial industry can pay.)

By using Puppet, I hope we'll have standardised environments. So far nothing's in production, but already there's one good benefit: the Puppet scripts serve as some minimal documentation, and by version controlling them we can define a process (no changes except by Puppet from the VCS).

(There may be better options than Puppet. I've tried using it, and I very much like the principle, but Puppet itself seems pretty awkward to use seriously. The sysadmins say I'm doing it wrong, YMMV.)

Re:Artisan? (1)

El_Oscuro (1022477) | about a year ago | (#44097465)

Make sure you get the official documention from Ahttp://docs.puppetlabs.com/ [puppetlabs.com] . I haven't really seen any books or anything else that is as complete and accurate, especially the reference and learning puppet books.

I find the "puppet resource" command is one of the most useful. You can use it to generate a script for a given configuration and use it to duplicate it elsewhere.

Re:Artisan? (-1)

Anonymous Coward | about a year ago | (#44096683)

So what you're saying is you've got a thousand systems, you don't really know what all is running on all of them, and you manage their configuration on an ad-hoc basis, when HPOV tells you there's an issue?

Man, that sounds GREAT.

I bet your customers love it when they've been using 2 or 3 servers for 6 months now to develop merrily along, only to find out when they're about to roll into pre-prod testing that your lab is configured completely differently, and building the servers out properly will add a couple weeks to their schedule!

I bet they also love it when slightly-different versions of all their tools are on multiple systems, in slightly different locations!

And I bet they REALLY dig it when you tell them, I don't have time to help you upgrade that set of systems, I'm busy managing a thousand servers!

How do I sign up to work in YOUR environment? I mean, if there's 15 or 20 scripts per system pushing data back to a PHP-driven data store, I can't imagine ANYTHING getting out of sync anywhere along the way - sounds like a dream!

You're a sysadmin who doesn't appear to understand the value of proper configuration management. That is... in a word... horrifying.

Re:Artisan? (0)

Anonymous Coward | about a year ago | (#44098653)

How well does puppet really help in heterogeneous, custom environments? I have Windows and Linux servers. Can't get rid of either.

How much work will it reduce? From what I see many places are moving to "VM" platforms - so if you're going to deploy similar machines it's just a matter of deploying a clone and then changing a few things. While puppet can help with those few things, it becomes less important as there's plenty which can do the same thing (and is likely a built-in feature on some VM management stuff).

Re:Artisan? (1)

turbidostato (878842) | about a year ago | (#44138625)

"How well does puppet really help in heterogeneous, custom environments? I have Windows and Linux servers."

Quite fine. Of the tens of different systems you can support, there's only one -you see, one among tens, with poor support. That one is Windows.

But that doesn't come for a surprise: we all know Windows is impossible to be properly managed (and I say that from the standpoint of somebody that supports about 2000 windows servers, so I might know something about the issue).

"How much work will it reduce?"

It really depends. And then, tools like puppet are not only about how much work they can reduce, but how much assurance they can offer to your employer -even in a single server scenario. Properly used, puppet means that any server can be rebuilt at any time, and that's something that all your effort can't asure (if only, by the time you are in the company no more).

Re:Artisan? (1)

turbidostato (878842) | about a year ago | (#44138597)

"We're using OpenView [...] I have a script framework"

So, in the end, your point is that the poster is right: you require automation.

As Always (4, Informative)

Bigbutt (65939) | about a year ago | (#44094945)

It requires some agent to be installed on a target server which communicates back to the Puppet Master. It's the same problem I have with other such tools that have agents. Infosec doesn't permit such holes in the various firewalls (I have servers in many locations). So I fall back to what I always do. I write scripts that run on the host gathering data, retrieve the data nightly, and can push changes out on the fly or with a nightly scheduled action.

It's a hell of a way to manage around 1,000 unix servers, but it's the easiest way to get the info I need to manage not just production but lab systems as well.

I'll finish downloading the docs and reading up on it out of curiosity but I don't see this going anywhere for us.

[John]

Re:As Always (3, Informative)

Anonymous Coward | about a year ago | (#44095057)

SSH in, run puppet apply, done.

Re:As Always (4, Interesting)

kcbnac (854015) | about a year ago | (#44095059)

For situations where the agents can't talk back to the Puppet Master, you can push out the manifests (config files) to each host and apply them directly, locally. (As if it were a single, standalone machine)

Not sure if there is a way to push the results back to a Puppet Master for aggregation, but there may be a way to tackle that. (Or just back to a central logging server for parsing)

Re:As Always (3, Interesting)

xaoslaad (590527) | about a year ago | (#44095253)

reports can be sent via http. Use foreman if you want a pretty interface, run passenger, choose any port you want.

For that matter do the same with puppet. You can run it on port 80 or 443 using passenger. You'll just have to customize your client config to use the same... so I don't really know why this is any sort of big deal for you.

Anyway, with foreman you can easily see if systems are out of sync, if they're erroring, etc. Might be a little unusual to do it running the way described in the previous post, but should be manageable if you really really really can't get it to work through the existing firewall configs. I've heard of people doing it when they've hit walls scaling as well. And foreman can do a lot more, though it doesn't have to. We started out using it just for the reports portion and facts searching...

Re:As Always (1)

Anonymous Coward | about a year ago | (#44095065)

Ya, you don't need a puppetmaster to use puppet. Just use puppet in standalone mode...

Re:As Always (2)

Anonymous Coward | about a year ago | (#44095073)

Check out Ansible. Ansible does it all through SSH, and doesn't require an agent. It's also much easier to learn and use than the mess called Puppet.

The run masterlessly (5, Interesting)

FreeUser (11483) | about a year ago | (#44095127)

It requires some agent to be installed on a target server which communicates back to the Puppet Master.

You can run puppet in masterless mode, against a local copy of the manifests, either managed locally or checked out from a version control repository.

Likewise with salt (my preferred choice over puppet, but both work), you can run either with a master host, or masterlessly. With salt the nice thing is, you can use the same config for both, just invoke the command differently (salt-call --local vs salt).

Infosec is no reason not to automate, just don't automate with a master server if your policies don't permit it.

Re:As Always (1)

silas_moeckel (234313) | about a year ago | (#44095223)

So your info sec policy's allows your agent but not others? Allows a central server pushing out changes but not one that gets queried?

Config servers are the crown jewels of info sec no matter how they they work. Puppet gives you tripwire type function that also knows if it's a valid config change.

Re:As Always (1)

Bigbutt (65939) | about a year ago | (#44095677)

Actually just scripts running via SSH. No agents on the hosts listening on ports. SSH is on all systems. The scripts are run on the host, data is saved in a data directory. The central server scps the files to a local, server specific directory for later review and parsing.

[John]

Re:As Always (2)

silas_moeckel (234313) | about a year ago | (#44096313)

Puppet has no agents on ports either the agent grabs the config file every x amount of time and uses pre shared crypto keys to cross validate. If your sending data up from your servers for centralized processing that's probably not something puppet or any other config management bit does.

Re:As Always (1)

turbidostato (878842) | about a year ago | (#44138679)

"If your sending data up from your servers for centralized processing that's probably not something puppet or any other config management bit does."

Wrong. In the case of puppet that's the realm of exported resources, custom facts, ENC, hiera and/or some others.

Re:As Always (0)

Anonymous Coward | about a year ago | (#44099025)

The Puppet agents pulls. It isn't listening on a socket and does not receive any connections from anywhere. The same is also true of Chef.

Re:As Always (1)

Burning1 (204959) | about a year ago | (#44095935)

There's always Ansible; the remote agent is a SSH server. Communication model is push only. Configuration files are YAML.

There are a dozen different configuration management tools on the market right now. There is almost certainly an option that fits your needs.

Re:As Always (1)

TheGreatDonkey (779189) | about a year ago | (#44096383)

I'm passing PCI, SAE16, etc. audits without a problem and as a matter of fact use Puppet as part of my control framework, and a sound network topology around the various environments. Not knowing what "infosec doesn't permit such holes" means, the counter argument in a generalized sense is that trusting a host to gather its own data (audit itself) and then retrieving it nightly isn't exactly a stable methodology?

Re:As Always (0)

Anonymous Coward | about a year ago | (#44097457)

It's the same problem I have with other such tools that have agents. Infosec doesn't permit such holes in the various firewalls.... So I fall back to what I always do. I write agents that can push changes out through holes in the various firewalls.

FTFY.

Re:As Always (0)

Anonymous Coward | about a year ago | (#44099337)

Ansible might be a viable alternative as it doesn't require an agent install.

http://www.ansibleworks.com/

Cheaper Direct from the Publisher, and no DRM (4, Informative)

kcbnac (854015) | about a year ago | (#44094969)

http://www.packtpub.com/puppet-3-beginners-guide/book [packtpub.com]

(Currently) $23 USD for the eBook, and $45 USD for the Print + eBook access, and no Amazon-Kindle-DRM. (But you can still get it in a .mobi format for your Kindle, in addition to ePub and PDF)

Recommendation (0)

Anonymous Coward | about a year ago | (#44095153)

And to master the subject, might I recommend this book [amazon.com] .

Quite the leap (0)

Anonymous Coward | about a year ago | (#44095261)

The summary basically states if you don't have 10 individual servers, then you have a cloud with servers coming and going minute-by-minute. That's quite a big gap. Honestly, at all of the places I have worked the servers don't change that often, so managing 20-30 (as VMs) isn't that big of a deal. Assuming, of course, that you know what your doing.

Balderdash (0)

Culture20 (968837) | about a year ago | (#44095403)

[b]eyond ten or so servers, there simply isn't a choice. You can't manage an infrastructure like this by hand.

Poppycockery and blatherskitism! Eleven isn't some magic number where Puppet suddenly becomes useful. If you only have 11-20 servers, there's a good chance that they're heterogeneous in both hardware and software. Puppet might help with keeping UIDs/GIDs the same on all the servers, but it's overkill for such a small number of machines. Most of the other conf files will be unique to each individual computer.

Re: Balderdash (4, Insightful)

turbidostato (878842) | about a year ago | (#44095493)

It is overkill for you but, if your boss has any professional acumen (I know, most don't) it wouldn't be overkill for him. A commonly understated value of automated configuration management is that it allows the company to own the knowledge it paid to acquire instead of letting it live only in some employee's memories.

Re:Balderdash (1)

Burning1 (204959) | about a year ago | (#44095971)

I strongly disagree. I'd happily deploy configuration management tools or an inventory service in environments with 2 hosts. Configuration management isn't just automation; it's also build documentation and a handy gateway between your RCS and your systems.

Re:Balderdash (0)

Anonymous Coward | about a year ago | (#44096715)

Actually, one of Puppet's strenghts is dealing with heterogeneous environments.

Re:Balderdash (0)

Anonymous Coward | about a year ago | (#44096727)

Most of the other conf files will be unique to each individual computer.

And it's easier to manage those via a configuration management tool, than via hand-rolled, home-grown manual effort.

A CM tool becomes a viable and useful tool to help manage your servers when your servers reach any number >= 1.

The payoff may be slow for only 1 or 2 servers, but the history & configuration data afforded by a CM tool is generally worth the effort if you're doing anything "businessy" on the systems. You WILL have new systems, you WILL grow - having the infrastructure in place to easily support that is important.

Re:Balderdash (1)

MikeBabcock (65886) | about a year ago | (#44097945)

Agreed. Plus, I maintain dozens of servers with both consistent and independant user IDs. They belong to multiple companies and what with how I know BASH and git, I don't have any problems keeping it all straight either. Some people are incredibly underskilled at sysadmin life if they think 20 servers is hard to maintain.

Re:Balderdash (1)

turbidostato (878842) | about a year ago | (#44138689)

"Some people are incredibly underskilled at sysadmin life if they think 20 servers is hard to maintain."

Some people are incrediby underskilled at sysadmin life if they think the proper way is reinventing the wheel.

Re:Balderdash (1)

MikeBabcock (65886) | about a year ago | (#44161673)

We wouldn't have Linux at all without wheel reinvention, and I think that comment is generally silly. As to system management, installing and maintaining third party software adds trust and management and security issues that didn't exist in the first place, so its not all positive either. For hundreds of machines I can see the value. However, my point was for 20.

Puppet? It's called shell scripting, dumbass! (0)

Anonymous Coward | about a year ago | (#44095739)

A couple of hand-grown scripts are not only equivalent to "Puppet", but *vastly* superior and *much* simpler to adapt and automate.

THAT is professionals CALL "manual". Not actually typing it in by hand yourself! But writing small snippets of code. Do it once, automate from then on.

Overblow tools just cripple that ability of flexibility and power, and teach the admin not to think for himself, and not to actually know what he's doing.

Re:Puppet? It's called shell scripting, dumbass! (0)

Anonymous Coward | about a year ago | (#44096647)

Okay, pops, we'll get off your lawn now.

Alternative (1)

Anonymous Coward | about a year ago | (#44096353)

Those experimenting with puppet, chef ... should also try "ansible" (http://www.ansibleworks.com/) ... Much simpler and yet as powerful as puppet IMHO...

Re:Alternative (1)

PsyMan (2702529) | about a year ago | (#44097147)

looks good, thanks

Windows Management (1)

Jonah Hex (651948) | about a year ago | (#44097529)

I like the idea of Puppet (and the alternatives) but it's Windows support is way to basic to make it viable over on "my" side of the data center. Why not use one of the established config management programs designed for Windows? Because I hate them all, and I wish they would die, and I do a better job programming an AutoIt script to check configs, registry keys, security, etc, than the big names do in their management programs. - HEX

Re:Windows Management (0)

Anonymous Coward | about a year ago | (#44101313)

Check out Chef. They've recently made huge strides in making windows a first class citizen.

Re:Windows Management (1)

Jonah Hex (651948) | about a year ago | (#44101653)

Thank you, I definitely will! I'm making the rounds of the alternates mentioned in this discussion but I'll start there. - HEX

No mention of the price? (0)

Anonymous Coward | about a year ago | (#44097999)

We're currently using it to manage eight servers, and are soon adding another four so we have to pay for a license. We couldn't find the price anywhere on their web site, and they have answered any emails asking about the price. I was hoping someone here had their secret price list so I would know how bad this is going to hurt.

Re:No mention of the price? (0)

Anonymous Coward | about a year ago | (#44101689)

How can you buy if they won't tell you how much? I don't understand how that MBAism of not giving prices to customers ever became popular. Yes, it makes customers more invested in your product because they waste a lot of time to fight you over obtaining the price, but all it does to logical people(e.g. engineers) is piss them off. I went through this with Jaspersoft. I still don't know how much their reporting server costs even after attending a couple of local events.

Re:No mention of the price? (0)

Anonymous Coward | about a year ago | (#44113279)

If you're a sales person for one of these companies please read this and learn! I've got too many things to do then attend each and every fucking webinar of every solution I need to look before you'll let me in on the secret price of your solution only to realise it's out of our budget or was cheap enough to go ahead without the song and dance. Save my time and yours and get to the bloody point, especially if it's too expensive, because you can quack on about the functionality that justifies it as much as you like but if we can't afford it, we can't afford it! VARs are the worst in this regard...

When it needs a book (0)

allo (1728082) | about a year ago | (#44099365)

Then the software is too complicated and/or does not have good documentation.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>