I am a little new to managing large numbers of CentOS/RHEL servers and was wondering what you experienced sysadmins prefer, Spacewalk or Puppet? Thanks, Dan Burkland -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20091103/de975d32/attachment-0004.html>
> I am a little new to managing large numbers of CentOS/RHEL servers and was > wondering what you experienced sysadmins prefer, Spacewalk or Puppet? >If you look at recent posts, you'll know my opinion of Spacewalk (not high, for large values of "not", and small values of "high"). mark
On 03/11/09 19:23, Dan Burkland wrote:> I am a little new to managing large numbers of CentOS/RHEL servers and > was wondering what you experienced sysadmins prefer, Spacewalk or Puppet?They are not really the same thing - puppet tends to be more policy and role centric while spacewalk is more state centric. Which tool one should use depends a lot on what and how they define 'management' of machines. If building-from-bare-metal is not going to be a concern, I would recommend skipping spacewalk at the initial steps and move to evaluate the config and policy management tools [1], see what fits the requirements better. Then as a second step, consider spacewalk as a tool that can be brought in later to do more of state-management. Also, I would ignore the comments about spacewalk being a waste of time - at ver 0.6 its very usable today. Just needs a bit of thinking about its layout and policies and it *does* need a significant investment in time. Much more so than. as an example puppet would need to start with. Anyway, my point really being that spacewalk and puppet are not competing components that can be compared on a fair platform. - KB [1]: puppet / chef / bcfg2 : all worth looking at, cfengine is now mostly a waste of time and only worth considering if you already have skill and/or legacy to support.
Karanbir Singh wrote:> On 03/11/09 21:13, Ray Van Dolson wrote: > >> Also, I believe cobbler functionality is being included in Spacewalk. >> > > spacewalk 0.6 is able to deploy machines with cobbler and do initial > snippet management too. >At that point I pass it over to puppet personally. Used to use cfengine, but there are aspects I prefer when it comes to puppet; your mileage may of course vary. -- Corey / KB1JWQ
On Tue, Nov 3, 2009 at 11:23 AM, Dan Burkland <dburklan at nmdp.org> wrote:> I am a little new to managing large numbers of CentOS/RHEL servers and > was wondering what you experienced sysadmins prefer, Spacewalk or Puppet? >Chef showed up on my radar this morning. Have you seen it or used it. Looks pretty promising. Tracy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20091103/609188fd/attachment-0004.html>
On 11/04/2009 12:47 AM, Tracy Phillips wrote:> Chef showed up on my radar this morning. Have you seen it or used it. > Looks pretty promising.I use Chef as well, and it is quite interesting in that it allows you to essentially have a systems management object in a proper language ( Ruby in this case ) rather than a DSL ( like puppet ). And while this is its strength, its also - imho - a massive weakness. If you have a few machines, and dont mind getting into installing and managing a boat load of associated code, Chef is worth looking into. If you are a large scale enterprise or a business where employing sysadmins who are also expected to be moderately fluent in Ruby. I'd give Chef a miss for the time being. There are a few wrappers being developed around chef, none of which look mature enough to use. Wait for something to come through those lines first. -- Karanbir Singh London, UK | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc
Hi.>> At that point I pass it over to puppet personally. ?Used to use >> cfengine, but there are aspects I prefer when it comes to puppet; your >> mileage may of course vary. > > well, refer back to my initial email on the subject. Its how you split > state and policy - puppet isnt all that great at state management but > does a great job of policy management and enforcement for that state. > > But then again it depends on how you play your setup, and exactly how > you define what 'management' really is.I am personally not that big fan of Puppet, as things are getting quite complex in large scenarios and as Puppet does not scale well (this has been improved in the latest version if you are using passenger instead of webrick). If you are willed to set up complex configurations with depends and variables, Puppet may be a good choice. In addition of Cobbler or TheForeman you will get provisioning functionality, too. IMHO you should also be familiar with Ruby, too. Spacewalk is one single tool for all Lifecycle Management task. It is capable of bare provisioning (using Cobbler integration), re-provisioning (using Koan), configuration management, errata generation and package management. It also scales quite well if you are using Oracle Standalone instead of XE. With PostgreSQL, a free database backend will be integrated in the near future. We are using Satellite/Spacewalk to manage about 2500 Clients and Servers. Best Regards Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.centos.org/pipermail/centos/attachments/20091104/865ab43d/attachment-0004.p7s>
Marcus Moeller wrote:> Hi. > >>> At that point I pass it over to puppet personally. Used to use >>> cfengine, but there are aspects I prefer when it comes to puppet; your >>> mileage may of course vary. >> >> well, refer back to my initial email on the subject. Its how you split >> state and policy - puppet isnt all that great at state management but >> does a great job of policy management and enforcement for that state. >> >> But then again it depends on how you play your setup, and exactly how >> you define what 'management' really is. > > I am personally not that big fan of Puppet, as things are getting quite > complex in large scenarios and as Puppet does not scale well (this has > been improved in the latest version if you are using passenger instead > of webrick). > > If you are willed to set up complex configurations with depends and > variables, Puppet may be a good choice. In addition of Cobbler or > TheForeman you will get provisioning functionality, too. IMHO you should > also be familiar with Ruby, too. > > Spacewalk is one single tool for all Lifecycle Management task. It is > capable of bare provisioning (using Cobbler integration), > re-provisioning (using Koan), configuration management, errata > generation and package management. It also scales quite well if you are > using Oracle Standalone instead of XE. With PostgreSQL, a free database > backend will be integrated in the near future. > > We are using Satellite/Spacewalk to manage about 2500 Clients and Servers.How well do any of these tools work when the hosts are widely distributed or distributed with groups in different locations? And how do they handle IP assignment on multiple NICs? Do you need DHCP capability on all segments or do you need to know all the MAC addresses and the cable connectivity starting out? Also, do they provide a version-controlled history with a way to easily find when a change was made and undo it? -- Les Mikesell lesmikesell at gmail.com
On 11/04/2009 12:15 PM, Marcus Moeller wrote:> I am personally not that big fan of Puppet, as things are getting quite > complex in large scenarios and as Puppet does not scale well (this has > been improved in the latest version if you are using passenger instead > of webrick).Puppet is actually easier to scale beyond a few nodes than spacewalk is. Remember that the client->server model for puppet is optional. eg. One set of people I introduced puppet to use git as a policy distribution layer and run ~ 12k instances using puppet, with average delivery time being less than 4 minutes from released, with less than 10 min guaranteed for role/policy implementation on the designated nodes ( its a large hosing setup, we did these calculations just last weekend ).> If you are willed to set up complex configurations with depends and > variables, Puppet may be a good choice. In addition of Cobbler or > TheForeman you will get provisioning functionality, too. IMHO you should > also be familiar with Ruby, too.I dont agree with either of the two, puppet is one package with ruby on the machine, how many dozens of thigns do you need to install for spacewalk ? What is the stability and maintenance loop like for each component ? And how many hoops do you need to jump through in order to get your app rollout linked into state management with spacewalk ? Try the same for puppet or even bcfg2 /chef/cfengine - its just a case of comparing apples and oranges. They dont do the same thing and they are both good to have, you just need to make up your mind what level you want to abstract at and how you want to split roles. Eg. Spacewalks's config policy management capabilities are about 3 generations behind what puppet is able to give you today.> Spacewalk is one single tool for all Lifecycle Management task. It is > capable of bare provisioning (using Cobbler integration), > re-provisioning (using Koan), configuration management, errata > generation and package management. It also scales quite well if you are > using Oracle Standalone instead of XE. With PostgreSQL, a free database > backend will be integrated in the near future.I think you highlighted the main issues yourself - spacewalk does a fair bit of different things than puppet - the only real overlap is on config management ( which I prefer to call policy - since its a case of policy that defines the role of a specific box ). And at that puppet is way ahead of the capabilities of spacewalk. The other massive win you can get from an integrated spacewalk/puppet deployment is the ability to stop running ssh and any remote access to a machine. Which in turn means that your spacewalk setup will have ( almost by force ) a good representation of the platform and the puppet manifests give you a fantastic view of the entire policy deployment across the entire infrastructure - just this is worth a lot when you have employee churn and/or need to consider platform re-factoring. And with a vcs to back up the puppet manifests, you get all the audit, track and management around that policy that you need. btw, I also dont agree with the idea that using puppet needs knowledge of ruby - its like saying using cfengine needs knowledge of 'C' or using OpenOffice needs intricate knowledge of Java. On the other hand, Chef aims to be closely associated within ruby - and if you said that Chef needed a fair ruby mindset, I'd agree :) - KB PS: Your email client is broken. Its not preserving thread sanity. -- Karanbir Singh London, UK | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc
If you guys would be so kind would you mind emailing some examples of some puppet policies? It would really be beneficial to me :) Thanks again for the all replies! Dan Burkland -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Karanbir Singh Sent: Wednesday, November 04, 2009 8:34 AM To: CentOS mailing list Subject: Re: [CentOS] Spacewalk or Puppet? On 11/04/2009 02:18 PM, Marcus Moeller wrote:> We had massive performance issues with Puppet< 0.25 and Mogrel/Webrick.Right, I dont think that the default out of the box setup with Webrick is meant to scale much beyond 100 or so machines, but its trivial to setup nginx based proxy in front of multiple mongrels and have that handle the load. Anything > 500 nodes needs specific consideration, but then at that level you have both the time and the interest to fix the specific issues.> Concerning Ruby you should at least be familiar with quoting/escaping > and scopes.I think the puppet DSL is slightly different from ruby in that way. Just working with the language guide for puppet is enough to keep things going. Its only when you get down to lower level embedded templates with erb that it might help knowing a bit of ruby, but I do honestly think most people can do almost everything on puppet without any ruby experience.> There are not so may packages that needs to be installed on client > side (about 10)How about the server side? puppet is still a single package on that end too.> but in conclusion you will get functionalities like > remote-commands through osad and monitoring. The package upgrades > could be handled with errata and update management easily.with puppet you get the ability to carry role based nagios definitions in sync with the role definition - which almost means zero nagios configuration. So what that means is that when I define what my webserver-type1 should look like and what configs its needs and what policy it needs to implement I can also define, at the same place, what sort of monitoring would be needed against those components. Then when I apply webserver-type1 to any specific machine, I get the nagios configs for free. And the fact that puppet runs in a definite manner, it can make for a reactive monitoring system in itself ( although I prefer to use tools like monit / god for that - specially for time critical services ).>> PS: Your email client is broken. Its not preserving thread sanity. > Not a problem here.Interestingly for your email : Message-ID: <g1m1yig5etitfc1rxzjezwJv4X.penango at mail.gmail.com> The headers contain no References or in-reply-to headers on the copy that came through to me ( your most recent one does have References set ). So not sure what mailclient you are using, but its a bit random on its headers. - KB -- Karanbir Singh London, UK | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos
hi Dan, Firstly - you are more than welcome on the list - but be polite to everyone else around and take a minute to atleat trim posts and be a good mailing lists person! On 04/11/09 19:04, Dan Burkland wrote:> If you guys would be so kind would you mind emailing some examples of some puppet policies? It would really be beneficial to me :) >start by looking at the puppet wiki - there are quite a few snippets of code, including some tutorials to get you started. They also have a very active irc channel at #puppet at irc.freenode.net and mailing lists. - KB