Hello, We are web app startup that is attempting to embrace the "devops" paradigm. We have a mixture of redhat and centos ESX VMs spread across dev/QA/ prod environments. We are currently using nagios for monitoring. Our servers consist of apache, tomcat and mysql. We are looking for open sourced software (we are a startup so we are broke! but commercial support could be an option once we get big). We are looking for a tool that will not only allow us to automate our complex server builds and web app deployments but will assist our devs with getting their builds ready to deploy. Monitoring, integration of Tomcat, mysql etc would be nice as well since configuring nagios is a pain. Can puppet do all of these things? Does it sound right for us? We are also considering CFengine and Chef. Would puppet be a better fit over these two? If so why? Thank you. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 07 Dec 2011, at 10:22 PM, Luke wrote:> We are web app startup that is attempting to embrace the "devops" > paradigm. > > We have a mixture of redhat and centos ESX VMs spread across dev/QA/ > prod environments. We are currently using nagios for monitoring. Our > servers consist of apache, tomcat and mysql. We are looking for open > sourced software (we are a startup so we are broke! but commercial > support could be an option once we get big). > > We are looking for a tool that will not only allow us to automate our > complex server builds and web app deployments but will assist our devs > with getting their builds ready to deploy. Monitoring, integration of > Tomcat, mysql etc would be nice as well since configuring nagios is a > pain. > > Can puppet do all of these things? Does it sound right for us? > > We are also considering CFengine and Chef. Would puppet be a better > fit over these two? If so why?When we (a large media company facing the same problem) built our platform, we were Redhat based, and so initially chose RPM as a deployment mechanism, with RPMs rolled using maven (even the non Java ones). What that meant was that our applications and our configs were rolled into proper RPMs, deployed to yum repositories, and deployed using the same tooling that already existed on the OS. This had a number of advantages: - Developers were expected to integrate their own packages and deliver them as RPMs. This is immensely powerful - no longer do developers and integration teams play tennis with code lobbed over a wall, now it''s purely the developers in control of the code. Apart from the initial resistance from developers (what? more work?), they soon realised the upsides (what? you mean it deployed somewhere else and just worked without anyone messing with my code?). If something went wrong, it was almost always the developer''s fault, and the developer could just deploy the RPM to a sandbox and debug it. When something is clearly one person''s fault, they just get on with fixing it, no fighting necessary. - Deployments were simple - deploy the RPM, done. This took discipline, as ops had to refuse complicated install instructions (anything beyond "deploy RPM; restart service" was rejected), but the advantage was that once the code was deployed to one environment, it could be deployed to the next and we''d know it would work. Because deployments were effectively all the same, they were quick to do, and didn''t require any specialised training over and above that an ops person already knew about managing the system. This saved a fortune. - Rollbacks were both possible and simple - if something didn''t work, you rolled back to the previous RPM, done. Suddenly deployments were far less risky, and downtime was negligible. Deployments were an office hours affair, and that saved a lot of money on staff. - Deployments were repeatable - If you deployed an RPM to a testing environment and it worked, you could deploy the RPM to a live environment and be assured that it would work without worrying that some 20 step process wasn''t followed correctly. - Whatever you could do, you could undo - If you wanted to uninstall an application or website, you uninstalled the RPM, done. If you wanted to know what package owned a particular file on the machine, you asked RPM, it would tell you. - Documentation evaporated, and this is a Good Thing(TM). If everything works the same way, you don''t need to document it beyond documenting the expected way to do things for the first RPM. There were some downsides though: - Configuration was deployed by RPM too, and for complex configurations (such as those of a whole class of webserver) this made sense and was a huge help, but for simple configurations this was a curse, as you had to release a new RPM for every change. - External config such as digital certificates were handled manually, and wasn''t ideal. - Despite the protection provided by RPM, developers still found new and interesting ways to subvert the RPM process to break things. Fortunately this was the exception, not the rule. To solve this, we introduced puppet to complement the RPM based stuff above, and by and large it has been successful, but there have been downsides. - It is very tempting for someone who knows puppet to just "do it in puppet", and we ended up with some configs done in RPM, and others in puppet. Complex configurations in puppet are big, unwieldy, slow to run, and difficult to understand, and cannot be uninstalled from the affected machines. - RPM includes the concept of versioning natively, but puppet expects you to apply your own versioning scheme outside of puppet, and in our case we just didn''t. Sure, the puppet config was in source control, but there was no functionality to branch or tag, nor was there a way to deploy or roll back atomic changes. We no longer had the certainty of "it worked in test so it will definitely work in live", and this was a step backwards. - When puppet touches or deploys a file, there is no way to reverse it - you cannot ask "who owns or is responsible for this file". This meant machines slowly filled with cruft over time, leading to the situation where you start being too scared to touch machines. In summary, I think a combination of puppet + RPM is the way to go, if you follow the following rules: - Put your code into RPM, and keep configuration separate. - Put configuration into RPM, except for the most basic of details, which you control with puppet. - Apply discipline, without discipline, none of this works. Regards, Graham -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Dec 7, 2011 at 12:22, Luke <lutaylor@gmail.com> wrote:> > to automate our complex server buildsWell, that''s Puppets core skill.> and web app deployments but will assist our devs with getting their builds > ready to deployDepends on how you deploy your webapps and your builds, it could, but it might not be the best solution. I use puppet to run my web servers, but I use it in more of an "Apache, create websites X, Y & Z" fashion. Part of that process does create all the requisite folders and setup an rsync from the "web master" share to all the web servers. So, in effect puppet is controlling it all, but really it is up to the devs to not screw up deploying their code to the share.> . Monitoring, integration of > Tomcat, mysql etc would be nice as well since configuring nagios is a > pain. >Integrating Nagios has been done before, so you shouldn''t have trouble finding examples. But Puppet isn''t going to "monitor" itself, of course. Can puppet do all of these things? Does it sound right for us?> > We are also considering CFengine and Chef. Would puppet be a better > fit over these two? If so why? > >I think all 3 options are fairly similar (I just recently went digging for automation tools myself, and settled on Puppet). Each one has their strengths and weaknesses. -- Jon [[User:ShakataGaNai]] / KJ6FNQ http://snowulf.com/ http://www.linkedin.com/in/shakataganai <http://twitter.com/shakataganai> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks guys. I should have pointed out that the developers do have builds mostly automated using ant we were just wondering we could have a solution that we could all use to try to standardize things. So I take it that we should probably just stick with that and perhaps look to puppet for our server builds? On Dec 7, 6:29 pm, Jon Davis <j...@snowulf.com> wrote:> On Wed, Dec 7, 2011 at 12:22, Luke <lutay...@gmail.com> wrote: > > > to automate our complex server builds > > Well, that''s Puppets core skill. > > > and web app deployments but will assist our devs with getting their builds > > ready to deploy > > Depends on how you deploy your webapps and your builds, it could, but it > might not be the best solution. I use puppet to run my web servers, but I > use it in more of an "Apache, create websites X, Y & Z" fashion. Part of > that process does create all the requisite folders and setup an rsync from > the "web master" share to all the web servers. So, in effect puppet is > controlling it all, but really it is up to the devs to not screw up > deploying their code to the share. > > > . Monitoring, integration of > > Tomcat, mysql etc would be nice as well since configuring nagios is a > > pain. > > Integrating Nagios has been done before, so you shouldn''t have trouble > finding examples. But Puppet isn''t going to "monitor" itself, of course. > > Can puppet do all of these things? Does it sound right for us? > > > We are also considering CFengine and Chef. Would puppet be a better > > fit over these two? If so why? > > I think all 3 options are fairly similar (I just recently went digging for > automation tools myself, and settled on Puppet). Each one has their > strengths and weaknesses. > > -- > Jon > [[User:ShakataGaNai]] / KJ6FNQhttp://snowulf.com/http://www.linkedin.com/in/shakataganai<http://twitter.com/shakataganai>-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ok a better way to word this can puppet allow us to isolate down the environment so that dev can make changes to their own environment but not QA, Prod etc. I am struggling with comparing these products because I don''t think any one of them really does a good job of explaining what they do or how they go about doing it. On Dec 8, 1:16 pm, Luke <lutay...@gmail.com> wrote:> Thanks guys. > > I should have pointed out that the developers do have builds mostly > automated using ant we were just wondering we could have a solution > that we could all use to try to standardize things. So I take it that > we should probably just stick with that and perhaps look to puppet for > our server builds? > > On Dec 7, 6:29 pm, Jon Davis <j...@snowulf.com> wrote: > > > > > > > > > On Wed, Dec 7, 2011 at 12:22, Luke <lutay...@gmail.com> wrote: > > > > to automate our complex server builds > > > Well, that''s Puppets core skill. > > > > and web app deployments but will assist our devs with getting their builds > > > ready to deploy > > > Depends on how you deploy your webapps and your builds, it could, but it > > might not be the best solution. I use puppet to run my web servers, but I > > use it in more of an "Apache, create websites X, Y & Z" fashion. Part of > > that process does create all the requisite folders and setup an rsync from > > the "web master" share to all the web servers. So, in effect puppet is > > controlling it all, but really it is up to the devs to not screw up > > deploying their code to the share. > > > > . Monitoring, integration of > > > Tomcat, mysql etc would be nice as well since configuring nagios is a > > > pain. > > > Integrating Nagios has been done before, so you shouldn''t have trouble > > finding examples. But Puppet isn''t going to "monitor" itself, of course. > > > Can puppet do all of these things? Does it sound right for us? > > > > We are also considering CFengine and Chef. Would puppet be a better > > > fit over these two? If so why? > > > I think all 3 options are fairly similar (I just recently went digging for > > automation tools myself, and settled on Puppet). Each one has their > > strengths and weaknesses. > > > -- > > Jon > > [[User:ShakataGaNai]] / KJ6FNQhttp://snowulf.com/http://www.linkedin.com/in/shakataganai<http://twitter.com/shakataganai>-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Dec 8, 2011 at 9:29 AM, Luke <lutaylor@gmail.com> wrote:> Ok a better way to word this can puppet allow us to isolate down the > environment so that dev can make changes to their own environment but > not QA, Prod etc. >Yes. In Puppet these are called "environments" :) http://docs.puppetlabs.com/guides/environment.html The standard way of achieving your goal is to set up your master to synchronize different branches in your version control system to different environments, and then set up ACLs on your version control such that only approved folks can commit to each branch. A particularly common pattern is to have environments for "dev", "test" and "prod", where developers can only commit to dev, and ops are responsible for propagating changes into "test" and then into "prod".> > I am struggling with comparing these products because I don''t think > any one of them really does a good job of explaining what they do or > how they go about doing it. > > > On Dec 8, 1:16 pm, Luke <lutay...@gmail.com> wrote: > > Thanks guys. > > > > I should have pointed out that the developers do have builds mostly > > automated using ant we were just wondering we could have a solution > > that we could all use to try to standardize things. So I take it that > > we should probably just stick with that and perhaps look to puppet for > > our server builds? > > > > On Dec 7, 6:29 pm, Jon Davis <j...@snowulf.com> wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 7, 2011 at 12:22, Luke <lutay...@gmail.com> wrote: > > > > > > to automate our complex server builds > > > > > Well, that''s Puppets core skill. > > > > > > and web app deployments but will assist our devs with getting their > builds > > > > ready to deploy > > > > > Depends on how you deploy your webapps and your builds, it could, but > it > > > might not be the best solution. I use puppet to run my web servers, > but I > > > use it in more of an "Apache, create websites X, Y & Z" fashion. Part > of > > > that process does create all the requisite folders and setup an rsync > from > > > the "web master" share to all the web servers. So, in effect puppet is > > > controlling it all, but really it is up to the devs to not screw up > > > deploying their code to the share. > > > > > > . Monitoring, integration of > > > > Tomcat, mysql etc would be nice as well since configuring nagios is a > > > > pain. > > > > > Integrating Nagios has been done before, so you shouldn''t have trouble > > > finding examples. But Puppet isn''t going to "monitor" itself, of > course. > > > > > Can puppet do all of these things? Does it sound right for us? > > > > > > We are also considering CFengine and Chef. Would puppet be a better > > > > fit over these two? If so why? > > > > > I think all 3 options are fairly similar (I just recently went digging > for > > > automation tools myself, and settled on Puppet). Each one has their > > > strengths and weaknesses. > > > > > -- > > > Jon > > > [[User:ShakataGaNai]] / KJ6FNQhttp:// > snowulf.com/http://www.linkedin.com/in/shakataganai< > http://twitter.com/shakataganai> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, 8 Dec 2011 09:48:51 -0800, Nigel Kersten wrote:> On Thu, Dec 8, 2011 at 9:29 AM, Luke wrote: > >> Ok a better way to word this can puppet allow us to isolate down > the >> environment so that dev can make changes to their own environment >> but >> not QA, Prod etc. > > Yes. In Puppet these are called "environments" :) > > http://docs.puppetlabs.com/guides/environment.html [10] > > The standard way of achieving your goal is to set up your master to > synchronize different branches in your version control system to > different environments, and then set up ACLs on your version control > such that only approved folks can commit to each branch. > > A particularly common pattern is to have environments for "dev", > "test" and "prod", where developers can only commit to dev, and ops > are responsible for propagating changes into "test" and then into > "prod".I''m going to wave a flag here for having different puppetmasters rather than different environments. This means that no matter what, we''re not breaking the production puppetmaster if we fiddle with our puppetmaster module. Obviously this is cheaper for those of us blessed with large virtualization platforms.>> I am struggling with comparing these products because I don''t think >> any one of them really does a good job of explaining what they do >> or >> how they go about doing it. >> >> On Dec 8, 1:16 pm, Luke wrote: >> > Thanks guys. >> > >> > I should have pointed out that the developers do have builds >> mostly >> > automated using ant we were just wondering we could have a >> solution >> > that we could all use to try to standardize things. So I take it >> that >> > we should probably just stick with that and perhaps look to >> puppet for >> > our server builds? >> > >> > On Dec 7, 6:29 pm, Jon Davis wrote: >> > >> > >> > >> > >> > >> > >> > >> > > On Wed, Dec 7, 2011 at 12:22, Luke wrote: >> > >> > > > to automate our complex server builds >> > >> > > Well, that''s Puppets core skill. >> > >> > > > and web app deployments but will assist our devs with >> getting their builds >> > > > ready to deploy >> > >> > > Depends on how you deploy your webapps and your builds, it >> could, but it >> > > might not be the best solution. I use puppet to run my web >> servers, but I >> > > use it in more of an "Apache, create websites X, Y & Z" >> fashion. Part of >> > > that process does create all the requisite folders and setup >> an rsync from >> > > the "web master" share to all the web servers. So, in effect >> puppet is >> > > controlling it all, but really it is up to the devs to not >> screw up >> > > deploying their code to the share. >> > >> > > > . Monitoring, integration of >> > > > Tomcat, mysql etc would be nice as well since configuring >> nagios is a >> > > > pain. >> > >> > > Integrating Nagios has been done before, so you shouldn''t have >> trouble >> > > finding examples. But Puppet isn''t going to "monitor" >> itself, of course. >> > >> > > Can puppet do all of these things? Does it sound right for us? >> > >> > > > We are also considering CFengine and Chef. Would puppet be a >> better >> > > > fit over these two? If so why? >> > >> > > I think all 3 options are fairly similar (I just recently went >> digging for >> > > automation tools myself, and settled on Puppet). Each one >> has their >> > > strengths and weaknesses. >> > >> > > -- >> > > Jon >> > > [[User:ShakataGaNai]] / >> KJ6FNQhttp://snowulf.com/http://www.linkedin.com/in/shakataganai > [4] >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com >> [6]. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com [7]. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en [8]. > > -- > Nigel Kersten > Product Manager, Puppet Labs > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > > Links: > ------ > [1] mailto:lutay...@gmail.com > [2] mailto:j...@snowulf.com > [3] mailto:lutay...@gmail.com > [4] http://snowulf.com/http://www.linkedin.com/in/shakataganai > [5] http://twitter.com/shakataganai > [6] mailto:puppet-users@googlegroups.com > [7] mailto:puppet-users%2Bunsubscribe@googlegroups.com > [8] http://groups.google.com/group/puppet-users?hl=en > [9] mailto:lutaylor@gmail.com > [10] http://docs.puppetlabs.com/guides/environment.html-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thank you for the reply. I am having difficulty choosing between CFengine, Chef and puppet. Which one would suit us the best as a small web app startup with heavy reliance on mysql/tomcat/nagios.We are entirely virtualized with ESX, want to be scalable and want a product that would work well in the cloud if we ended up making the transition. I mean would we fit into the typical user base of puppet as opposed to those of CFengine/Chef. Can you tell me what features of Puppet out do those in CFengine/ Puppet? On Dec 8, 1:48 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:> On Thu, Dec 8, 2011 at 9:29 AM, Luke <lutay...@gmail.com> wrote: > > Ok a better way to word this can puppet allow us to isolate down the > > environment so that dev can make changes to their own environment but > > not QA, Prod etc. > > Yes. In Puppet these are called "environments" :) > > http://docs.puppetlabs.com/guides/environment.html > > The standard way of achieving your goal is to set up your master to > synchronize different branches in your version control system to different > environments, and then set up ACLs on your version control such that only > approved folks can commit to each branch. > > A particularly common pattern is to have environments for "dev", "test" and > "prod", where developers can only commit to dev, and ops are responsible > for propagating changes into "test" and then into "prod". > > > > > > > > > > > > > I am struggling with comparing these products because I don''t think > > any one of them really does a good job of explaining what they do or > > how they go about doing it. > > > On Dec 8, 1:16 pm, Luke <lutay...@gmail.com> wrote: > > > Thanks guys. > > > > I should have pointed out that the developers do have builds mostly > > > automated using ant we were just wondering we could have a solution > > > that we could all use to try to standardize things. So I take it that > > > we should probably just stick with that and perhaps look to puppet for > > > our server builds? > > > > On Dec 7, 6:29 pm, Jon Davis <j...@snowulf.com> wrote: > > > > > On Wed, Dec 7, 2011 at 12:22, Luke <lutay...@gmail.com> wrote: > > > > > > to automate our complex server builds > > > > > Well, that''s Puppets core skill. > > > > > > and web app deployments but will assist our devs with getting their > > builds > > > > > ready to deploy > > > > > Depends on how you deploy your webapps and your builds, it could, but > > it > > > > might not be the best solution. I use puppet to run my web servers, > > but I > > > > use it in more of an "Apache, create websites X, Y & Z" fashion. Part > > of > > > > that process does create all the requisite folders and setup an rsync > > from > > > > the "web master" share to all the web servers. So, in effect puppet is > > > > controlling it all, but really it is up to the devs to not screw up > > > > deploying their code to the share. > > > > > > . Monitoring, integration of > > > > > Tomcat, mysql etc would be nice as well since configuring nagios is a > > > > > pain. > > > > > Integrating Nagios has been done before, so you shouldn''t have trouble > > > > finding examples. But Puppet isn''t going to "monitor" itself, of > > course. > > > > > Can puppet do all of these things? Does it sound right for us? > > > > > > We are also considering CFengine and Chef. Would puppet be a better > > > > > fit over these two? If so why? > > > > > I think all 3 options are fairly similar (I just recently went digging > > for > > > > automation tools myself, and settled on Puppet). Each one has their > > > > strengths and weaknesses. > > > > > -- > > > > Jon > > > > [[User:ShakataGaNai]] / KJ6FNQhttp:// > > snowulf.com/http://www.linkedin.com/in/shakataganai< > >http://twitter.com/shakataganai> > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- > Nigel Kersten > Product Manager, Puppet Labs-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Dec 8, 2011 at 10:36, Luke <lutaylor@gmail.com> wrote:> I am having difficulty choosing between CFengine, Chef and puppet. > Which one would suit us the best as a small web app startup with heavy > reliance on mysql/tomcat/nagios.We are entirely virtualized with ESX, > want to be scalable and want a product that would work well in the > cloud if we ended up making the transition. I mean would we fit into > the typical user base of puppet as opposed to those of CFengine/Chef.Would you fit into the typical user base of Puppet, CFEngine, or Chef? Yes - for all of them. None of those products are inappropriate at your scale, or for the purposes you have named.> Can you tell me what features of Puppet out do those in CFengine/Puppet?If you are looking for the "one killer feature" you probably have the wrong approach to the problem: what you are describing as your problem space is a pretty simple deployment scenario, and any of the three tools should do a fine job managing it. Unless there is some unique point in your environment, or in your needs, that you can articulate then you can''t find a single feature check-box to let you decide between the three. Instead, I suggest you focus on your ability to learn the concrete use of the tool, and on how effectively you can solve problems with them; doing a small trial of each - solve the same mid-sized problem three times, giving each a day or two - and see what you think works best for your company and culture. There is no silver bullet. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I should also add that a very important consideration is to take in mind _who_ will be working with this. Are they developers, sysadmins, QA? Will the people working on it be spending a lot of time with Puppet/Chef/CFengine, or just a little? Are you planning on writing a bunch of custom modules, or relying on the community? What languages does your team work on primarily? For example, folks that work with Ruby a lot would probably do better with Puppet and Chef. As a sysadmin, I often see developers get distracted by arguments about what''s "best" or the most technically advanced. Often they forget that in the end the real answer is often which tool gets the job done the quickest, with the least amount of labor, and is the most supportable. Jeffrey. On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman <daniel@puppetlabs.com>wrote:> > Instead, I suggest you focus on your ability to learn the concrete use > of the tool, and on how effectively you can solve problems with them; > doing a small trial of each - solve the same mid-sized problem three > times, giving each a day or two - and see what you think works best > for your company and culture. > > There is no silver bullet. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
This tool will be used by primarily system admins to automate server builds app installs, configurations etc. The devs will use it in their own environment to help automate some of their tasks. I don''t think we have too much Ruby expertise since we are mostly a Java shop. In terms of performance I have read that CFengine uses much less memory and can be faster than puppet. Can anyone comment on the agent and server memory usage? I have read that the puppet agent can use 85mb and the server upwards to 1GB after 20-30agents. Is that accurate? I guess which tool would you consider to be the quickest, easy to implement etc? From what I am seeing the community here seems to be much more active than the others. I have yet to get a response on the other forums. On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote:> I should also add that a very important consideration is to take in mind > _who_ will be working with this. Are they developers, sysadmins, QA? Will > the people working on it be spending a lot of time with > Puppet/Chef/CFengine, or just a little? Are you planning on writing a > bunch of custom modules, or relying on the community? What languages does > your team work on primarily? For example, folks that work with Ruby a lot > would probably do better with Puppet and Chef. > > As a sysadmin, I often see developers get distracted by arguments about > what''s "best" or the most technically advanced. Often they forget that in > the end the real answer is often which tool gets the job done the quickest, > with the least amount of labor, and is the most supportable. > > Jeffrey. > > On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman <dan...@puppetlabs.com>wrote: > > > > > > > > > > > Instead, I suggest you focus on your ability to learn the concrete use > > of the tool, and on how effectively you can solve problems with them; > > doing a small trial of each - solve the same mid-sized problem three > > times, giving each a day or two - and see what you think works best > > for your company and culture. > > > There is no silver bullet.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Dec 8, 2011 at 12:59, Luke <lutaylor@gmail.com> wrote:> This tool will be used by primarily system admins to automate server > builds app installs, configurations etc. The devs will use it in their > own environment to help automate some of their tasks. I don''t think we > have too much Ruby expertise since we are mostly a Java shop.On that front, CFEngine or Puppet are probably nicer than Chef, since they have a less demanding new language to learn. OTOH, if you want to pick up Ruby skills Chef will force you to deal with that more directly.> In terms of performance I have read that CFengine uses much less > memory and can be faster than puppet. Can anyone comment on the agent > and server memory usage? I have read that the puppet agent can use > 85mb and the server upwards to 1GB after 20-30agents. Is that > accurate?The server is between 80 and 100MB for each concurrent compiler instance; you can work out the system load based on the degree of concurrency you want. (eg: 24 agents, each checking in once a day, you need one concurrent instance, and ~ 100MB. It scales from there the obvious, and linear, way.)> I guess which tool would you consider to be the quickest, easy to > implement etc? From what I am seeing the community here seems to be > much more active than the others. I have yet to get a response on the > other forums.That is a very, very hard question to answer, because it depends on your team. Would you get started quicker with something that gave you very few tools, or lots of them? With a simple language, or a full blown programming language? With a declarative, procedural, or dependency-driven input language? With high or low levels of abstraction? I would certainly say that community, published books, and Internet posts talking about the tool significantly influence the ease of getting started. Everyone gets stuck, and being able to get answers makes a huge difference there. If you have a local expert, whatever they know is totally the best choice - you get much higher bandwidth on answers, and can learn from the mistakes someone else made. ;) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I''ve found Puppet to be unreliable running as a daemon - I suspect due to older versions of ruby floating around. So I switched to running it from cron, and it works a lot better. Memory usage doesn''t seem to be an issue, and the agent only runs for a few seconds. Use Puppet Dasboard (or something like it) and/or use Nagios to make sure those cron jobs run. I use both. The main thing is to have Puppet managing itself and the cron job. I have ours set up to run the cron job twice an hour, using the concatenated IP address modulo 30 and modulo 30 + 30 as the times (to keep the clients from hammering the Puppetmaster all at once). Let me know if you go with Puppet and I''ll show you how I did it. Part of the reason we chose Puppet was the quantity of documentation and working examples and the helpfulness of the community. I support (and implement) our Puppet environment here at my job. I would highly recommend Mr Turnbull''s Pro Puppet book. It is VERY sysadmin focused and will save you a lot of time. The sections on environments, modules, and Dashboard were really helpful. Jeffrey Sent from my iPad On Dec 8, 2011, at 2:59 PM, Luke <lutaylor@gmail.com> wrote:> This tool will be used by primarily system admins to automate server > builds app installs, configurations etc. The devs will use it in their > own environment to help automate some of their tasks. I don''t think we > have too much Ruby expertise since we are mostly a Java shop. > > In terms of performance I have read that CFengine uses much less > memory and can be faster than puppet. Can anyone comment on the agent > and server memory usage? I have read that the puppet agent can use > 85mb and the server upwards to 1GB after 20-30agents. Is that > accurate? > > I guess which tool would you consider to be the quickest, easy to > implement etc? From what I am seeing the community here seems to be > much more active than the others. I have yet to get a response on the > other forums. > > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: >> I should also add that a very important consideration is to take in mind >> _who_ will be working with this. Are they developers, sysadmins, QA? Will >> the people working on it be spending a lot of time with >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a >> bunch of custom modules, or relying on the community? What languages does >> your team work on primarily? For example, folks that work with Ruby a lot >> would probably do better with Puppet and Chef. >> >> As a sysadmin, I often see developers get distracted by arguments about >> what''s "best" or the most technically advanced. Often they forget that in >> the end the real answer is often which tool gets the job done the quickest, >> with the least amount of labor, and is the most supportable. >> >> Jeffrey. >> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman <dan...@puppetlabs.com>wrote: >> >> >> >> >> >> >> >> >> >>> Instead, I suggest you focus on your ability to learn the concrete use >>> of the tool, and on how effectively you can solve problems with them; >>> doing a small trial of each - solve the same mid-sized problem three >>> times, giving each a day or two - and see what you think works best >>> for your company and culture. >> >>> There is no silver bullet. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Let me emphasize the beauty of running Puppet out of cron. Not only do you not end up with resource leaks (or just simple consumption when you don''t need it), but you also get much more reliable load on your puppet masters. Further, if you are wiling to make a trivial effort to write a site-specific fqdn_rand() work-alike function, you can even arrange to be sure that updates roll across related servers in a reliable way. On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts <jeffrey.w.watts@gmail.com>wrote:> I''ve found Puppet to be unreliable running as a daemon - I suspect due to > older versions of ruby floating around. So I switched to running it from > cron, and it works a lot better. Memory usage doesn''t seem to be an issue, > and the agent only runs for a few seconds. Use Puppet Dasboard (or > something like it) and/or use Nagios to make sure those cron jobs run. I > use both. > > The main thing is to have Puppet managing itself and the cron job. I have > ours set up to run the cron job twice an hour, using the concatenated IP > address modulo 30 and modulo 30 + 30 as the times (to keep the clients from > hammering the Puppetmaster all at once). Let me know if you go with Puppet > and I''ll show you how I did it. > > Part of the reason we chose Puppet was the quantity of documentation and > working examples and the helpfulness of the community. I support (and > implement) our Puppet environment here at my job. I would highly recommend > Mr Turnbull''s Pro Puppet book. It is VERY sysadmin focused and will save > you a lot of time. The sections on environments, modules, and Dashboard > were really helpful. > > Jeffrey > Sent from my iPad > > On Dec 8, 2011, at 2:59 PM, Luke <lutaylor@gmail.com> wrote: > > > This tool will be used by primarily system admins to automate server > > builds app installs, configurations etc. The devs will use it in their > > own environment to help automate some of their tasks. I don''t think we > > have too much Ruby expertise since we are mostly a Java shop. > > > > In terms of performance I have read that CFengine uses much less > > memory and can be faster than puppet. Can anyone comment on the agent > > and server memory usage? I have read that the puppet agent can use > > 85mb and the server upwards to 1GB after 20-30agents. Is that > > accurate? > > > > I guess which tool would you consider to be the quickest, easy to > > implement etc? From what I am seeing the community here seems to be > > much more active than the others. I have yet to get a response on the > > other forums. > > > > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: > >> I should also add that a very important consideration is to take in mind > >> _who_ will be working with this. Are they developers, sysadmins, QA? > Will > >> the people working on it be spending a lot of time with > >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a > >> bunch of custom modules, or relying on the community? What languages > does > >> your team work on primarily? For example, folks that work with Ruby a > lot > >> would probably do better with Puppet and Chef. > >> > >> As a sysadmin, I often see developers get distracted by arguments about > >> what''s "best" or the most technically advanced. Often they forget that > in > >> the end the real answer is often which tool gets the job done the > quickest, > >> with the least amount of labor, and is the most supportable. > >> > >> Jeffrey. > >> > >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman <dan...@puppetlabs.com > >wrote: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>> Instead, I suggest you focus on your ability to learn the concrete use > >>> of the tool, and on how effectively you can solve problems with them; > >>> doing a small trial of each - solve the same mid-sized problem three > >>> times, giving each a day or two - and see what you think works best > >>> for your company and culture. > >> > >>> There is no silver bullet. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I would consider the following a small list of pros and cons for the three tools: Pros: Cfengine: Not written in Ruby, so currently is more efficient with system resources. Puppet: IMHO has the most approachable syntax of the three (for sysadmins), and the strongest community. It also has the widest platform support, with a lot of preexisting code and code examples out there. Chef: Configs are written in Ruby, and somewhat modeled on Rails development patterns, so it is relatively easy for Ruby/Rails devs to pick up. Also, Chef was designed from the ground up for the cloud, so is focused on things like dynamically spinning up cloud instances. (Check out knife and databags) If you don''t want to manage your own Chef server you can get it as a preconfigured service. Cons: Cfengine: Can be a bit challenging to learn, especially the promise theory. Puppet: Particularly with older versions of Ruby can have memory usage issues. Variable scoping is not ideal. These issues are manageable though. Chef: No true dependency graphing, (implicit execution order) Setting up a chef server is a bit on the challenging side, since it has a number of requirements that don''t fall into very common use. (Erlang based CouchDB, and Solr). Learning Ruby is mandatory. None of these tools are perfect and each have their warts, but any one of them would make your life a lot easier. I''d say though that I prefer Puppet over cfengine in almost all cases (except maybe a case where I am managing only machines that have very tight resource constraints). Chef vs Puppet it depends. If I was working entirely in the cloud and I had a very dynamic environment, or was a Ruby shop, Chef would probably be my choice. In almost all other cases I would go with Puppet. That said, the Puppet community is working to address the Cloud deployment differences, so if the cloud is in the future but not a now thing, I wouldn''t let that effect your decision. (And puppet does work in the cloud today, just the support is relatively new and not yet as robust as Chef''s) All in all, for the reason of community and ecosystem alone, I''d say go with Puppet. Here are some random syntax examples: cfengine: http://www.sysadmin.hep.ac.uk/wiki/Cfengine:_Installing_Xrootd_with_cfengine puppet: http://people.redhat.com/dlutter/puppet-app.html chef: https://github.com/opscode/cookbooks/blob/master/apache2/recipes/default.rb Cheers, Brian P.S. - Another tool to look at, that I have *heard* good things about is bcfg2, but it isn''t nearly as popular as the others. -- <http://aws.amazon.com/solutions/solution-providers/brandorr/> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I would totally recommend Puppet Commander in place of that, if you have the time to get it running: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/ToolPuppetcommander It uses mcollective and is pretty much awesome. Daniel On Thu, Dec 8, 2011 at 21:22, Brian Gallew <geek@gallew.org> wrote:> Let me emphasize the beauty of running Puppet out of cron. Not only do you > not end up with resource leaks (or just simple consumption when you don''t > need it), but you also get much more reliable load on your puppet masters. > Further, if you are wiling to make a trivial effort to write a > site-specific fqdn_rand() work-alike function, you can even arrange to be > sure that updates roll across related servers in a reliable way. > > > On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts <jeffrey.w.watts@gmail.com> > wrote: >> >> I''ve found Puppet to be unreliable running as a daemon - I suspect due to >> older versions of ruby floating around. So I switched to running it from >> cron, and it works a lot better. Memory usage doesn''t seem to be an issue, >> and the agent only runs for a few seconds. Use Puppet Dasboard (or >> something like it) and/or use Nagios to make sure those cron jobs run. I >> use both. >> >> The main thing is to have Puppet managing itself and the cron job. I have >> ours set up to run the cron job twice an hour, using the concatenated IP >> address modulo 30 and modulo 30 + 30 as the times (to keep the clients from >> hammering the Puppetmaster all at once). Let me know if you go with Puppet >> and I''ll show you how I did it. >> >> Part of the reason we chose Puppet was the quantity of documentation and >> working examples and the helpfulness of the community. I support (and >> implement) our Puppet environment here at my job. I would highly recommend >> Mr Turnbull''s Pro Puppet book. It is VERY sysadmin focused and will save you >> a lot of time. The sections on environments, modules, and Dashboard were >> really helpful. >> >> Jeffrey >> Sent from my iPad >> >> On Dec 8, 2011, at 2:59 PM, Luke <lutaylor@gmail.com> wrote: >> >> > This tool will be used by primarily system admins to automate server >> > builds app installs, configurations etc. The devs will use it in their >> > own environment to help automate some of their tasks. I don''t think we >> > have too much Ruby expertise since we are mostly a Java shop. >> > >> > In terms of performance I have read that CFengine uses much less >> > memory and can be faster than puppet. Can anyone comment on the agent >> > and server memory usage? I have read that the puppet agent can use >> > 85mb and the server upwards to 1GB after 20-30agents. Is that >> > accurate? >> > >> > I guess which tool would you consider to be the quickest, easy to >> > implement etc? From what I am seeing the community here seems to be >> > much more active than the others. I have yet to get a response on the >> > other forums. >> > >> > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: >> >> I should also add that a very important consideration is to take in >> >> mind >> >> _who_ will be working with this. Are they developers, sysadmins, QA? >> >> Will >> >> the people working on it be spending a lot of time with >> >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a >> >> bunch of custom modules, or relying on the community? What languages >> >> does >> >> your team work on primarily? For example, folks that work with Ruby a >> >> lot >> >> would probably do better with Puppet and Chef. >> >> >> >> As a sysadmin, I often see developers get distracted by arguments about >> >> what''s "best" or the most technically advanced. Often they forget that >> >> in >> >> the end the real answer is often which tool gets the job done the >> >> quickest, >> >> with the least amount of labor, and is the most supportable. >> >> >> >> Jeffrey. >> >> >> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman >> >> <dan...@puppetlabs.com>wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> Instead, I suggest you focus on your ability to learn the concrete use >> >>> of the tool, and on how effectively you can solve problems with them; >> >>> doing a small trial of each - solve the same mid-sized problem three >> >>> times, giving each a day or two - and see what you think works best >> >>> for your company and culture. >> >> >> >>> There is no silver bullet. >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Puppet Users" group. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.-- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thank you for the messages everyone. You have definitely given me some information to go back to the team with. On Dec 9, 3:33 am, Daniel Pittman <dan...@puppetlabs.com> wrote:> I would totally recommend Puppet Commander in place of that, if you > have the time to get it running: > > http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Tool... > > It uses mcollective and is pretty much awesome. > > Daniel > > > > > > > > > > On Thu, Dec 8, 2011 at 21:22, Brian Gallew <g...@gallew.org> wrote: > > Let me emphasize the beauty of running Puppet out of cron. Not only do you > > not end up with resource leaks (or just simple consumption when you don''t > > need it), but you also get much more reliable load on your puppet masters. > > Further, if you are wiling to make a trivial effort to write a > > site-specific fqdn_rand() work-alike function, you can even arrange to be > > sure that updates roll across related servers in a reliable way. > > > On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts <jeffrey.w.wa...@gmail.com> > > wrote: > > >> I''ve found Puppet to be unreliable running as a daemon - I suspect due to > >> older versions of ruby floating around. So I switched to running it from > >> cron, and it works a lot better. Memory usage doesn''t seem to be an issue, > >> and the agent only runs for a few seconds. Use Puppet Dasboard (or > >> something like it) and/or use Nagios to make sure those cron jobs run. I > >> use both. > > >> The main thing is to have Puppet managing itself and the cron job. I have > >> ours set up to run the cron job twice an hour, using the concatenated IP > >> address modulo 30 and modulo 30 + 30 as the times (to keep the clients from > >> hammering the Puppetmaster all at once). Let me know if you go with Puppet > >> and I''ll show you how I did it. > > >> Part of the reason we chose Puppet was the quantity of documentation and > >> working examples and the helpfulness of the community. I support (and > >> implement) our Puppet environment here at my job. I would highly recommend > >> Mr Turnbull''s Pro Puppet book. It is VERY sysadmin focused and will save you > >> a lot of time. The sections on environments, modules, and Dashboard were > >> really helpful. > > >> Jeffrey > >> Sent from my iPad > > >> On Dec 8, 2011, at 2:59 PM, Luke <lutay...@gmail.com> wrote: > > >> > This tool will be used by primarily system admins to automate server > >> > builds app installs, configurations etc. The devs will use it in their > >> > own environment to help automate some of their tasks. I don''t think we > >> > have too much Ruby expertise since we are mostly a Java shop. > > >> > In terms of performance I have read that CFengine uses much less > >> > memory and can be faster than puppet. Can anyone comment on the agent > >> > and server memory usage? I have read that the puppet agent can use > >> > 85mb and the server upwards to 1GB after 20-30agents. Is that > >> > accurate? > > >> > I guess which tool would you consider to be the quickest, easy to > >> > implement etc? From what I am seeing the community here seems to be > >> > much more active than the others. I have yet to get a response on the > >> > other forums. > > >> > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: > >> >> I should also add that a very important consideration is to take in > >> >> mind > >> >> _who_ will be working with this. Are they developers, sysadmins, QA? > >> >> Will > >> >> the people working on it be spending a lot of time with > >> >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a > >> >> bunch of custom modules, or relying on the community? What languages > >> >> does > >> >> your team work on primarily? For example, folks that work with Ruby a > >> >> lot > >> >> would probably do better with Puppet and Chef. > > >> >> As a sysadmin, I often see developers get distracted by arguments about > >> >> what''s "best" or the most technically advanced. Often they forget that > >> >> in > >> >> the end the real answer is often which tool gets the job done the > >> >> quickest, > >> >> with the least amount of labor, and is the most supportable. > > >> >> Jeffrey. > > >> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman > >> >> <dan...@puppetlabs.com>wrote: > > >> >>> Instead, I suggest you focus on your ability to learn the concrete use > >> >>> of the tool, and on how effectively you can solve problems with them; > >> >>> doing a small trial of each - solve the same mid-sized problem three > >> >>> times, giving each a day or two - and see what you think works best > >> >>> for your company and culture. > > >> >>> There is no silver bullet. > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Puppet Users" group. > >> > To post to this group, send email to puppet-users@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > puppet-users+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> >http://groups.google.com/group/puppet-users?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Puppet Users" group. > >> To post to this group, send email to puppet-users@googlegroups.com. > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >>http://groups.google.com/group/puppet-users?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- > ⎋ Puppet Labs Developer –http://puppetlabs.com > ♲ Made with 100 percent post-consumer electrons-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
No worries. Feel free to come back with other questions, if they come up, and we will see what we can do to help out with them. :) Daniel On Fri, Dec 9, 2011 at 04:38, Luke <lutaylor@gmail.com> wrote:> Thank you for the messages everyone. You have definitely given me some > information to go back to the team with. > > On Dec 9, 3:33 am, Daniel Pittman <dan...@puppetlabs.com> wrote: >> I would totally recommend Puppet Commander in place of that, if you >> have the time to get it running: >> >> http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Tool... >> >> It uses mcollective and is pretty much awesome. >> >> Daniel >> >> >> >> >> >> >> >> >> >> On Thu, Dec 8, 2011 at 21:22, Brian Gallew <g...@gallew.org> wrote: >> > Let me emphasize the beauty of running Puppet out of cron. Not only do you >> > not end up with resource leaks (or just simple consumption when you don''t >> > need it), but you also get much more reliable load on your puppet masters. >> > Further, if you are wiling to make a trivial effort to write a >> > site-specific fqdn_rand() work-alike function, you can even arrange to be >> > sure that updates roll across related servers in a reliable way. >> >> > On Thu, Dec 8, 2011 at 6:08 PM, Jeffrey Watts <jeffrey.w.wa...@gmail.com> >> > wrote: >> >> >> I''ve found Puppet to be unreliable running as a daemon - I suspect due to >> >> older versions of ruby floating around. So I switched to running it from >> >> cron, and it works a lot better. Memory usage doesn''t seem to be an issue, >> >> and the agent only runs for a few seconds. Use Puppet Dasboard (or >> >> something like it) and/or use Nagios to make sure those cron jobs run. I >> >> use both. >> >> >> The main thing is to have Puppet managing itself and the cron job. I have >> >> ours set up to run the cron job twice an hour, using the concatenated IP >> >> address modulo 30 and modulo 30 + 30 as the times (to keep the clients from >> >> hammering the Puppetmaster all at once). Let me know if you go with Puppet >> >> and I''ll show you how I did it. >> >> >> Part of the reason we chose Puppet was the quantity of documentation and >> >> working examples and the helpfulness of the community. I support (and >> >> implement) our Puppet environment here at my job. I would highly recommend >> >> Mr Turnbull''s Pro Puppet book. It is VERY sysadmin focused and will save you >> >> a lot of time. The sections on environments, modules, and Dashboard were >> >> really helpful. >> >> >> Jeffrey >> >> Sent from my iPad >> >> >> On Dec 8, 2011, at 2:59 PM, Luke <lutay...@gmail.com> wrote: >> >> >> > This tool will be used by primarily system admins to automate server >> >> > builds app installs, configurations etc. The devs will use it in their >> >> > own environment to help automate some of their tasks. I don''t think we >> >> > have too much Ruby expertise since we are mostly a Java shop. >> >> >> > In terms of performance I have read that CFengine uses much less >> >> > memory and can be faster than puppet. Can anyone comment on the agent >> >> > and server memory usage? I have read that the puppet agent can use >> >> > 85mb and the server upwards to 1GB after 20-30agents. Is that >> >> > accurate? >> >> >> > I guess which tool would you consider to be the quickest, easy to >> >> > implement etc? From what I am seeing the community here seems to be >> >> > much more active than the others. I have yet to get a response on the >> >> > other forums. >> >> >> > On Dec 8, 4:39 pm, Jeffrey Watts <jeffrey.w.wa...@gmail.com> wrote: >> >> >> I should also add that a very important consideration is to take in >> >> >> mind >> >> >> _who_ will be working with this. Are they developers, sysadmins, QA? >> >> >> Will >> >> >> the people working on it be spending a lot of time with >> >> >> Puppet/Chef/CFengine, or just a little? Are you planning on writing a >> >> >> bunch of custom modules, or relying on the community? What languages >> >> >> does >> >> >> your team work on primarily? For example, folks that work with Ruby a >> >> >> lot >> >> >> would probably do better with Puppet and Chef. >> >> >> >> As a sysadmin, I often see developers get distracted by arguments about >> >> >> what''s "best" or the most technically advanced. Often they forget that >> >> >> in >> >> >> the end the real answer is often which tool gets the job done the >> >> >> quickest, >> >> >> with the least amount of labor, and is the most supportable. >> >> >> >> Jeffrey. >> >> >> >> On Thu, Dec 8, 2011 at 12:44 PM, Daniel Pittman >> >> >> <dan...@puppetlabs.com>wrote: >> >> >> >>> Instead, I suggest you focus on your ability to learn the concrete use >> >> >>> of the tool, and on how effectively you can solve problems with them; >> >> >>> doing a small trial of each - solve the same mid-sized problem three >> >> >>> times, giving each a day or two - and see what you think works best >> >> >>> for your company and culture. >> >> >> >>> There is no silver bullet. >> >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "Puppet Users" group. >> >> > To post to this group, send email to puppet-users@googlegroups.com. >> >> > To unsubscribe from this group, send email to >> >> > puppet-users+unsubscribe@googlegroups.com. >> >> > For more options, visit this group at >> >> >http://groups.google.com/group/puppet-users?hl=en. >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "Puppet Users" group. >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscribe@googlegroups.com. >> >> For more options, visit this group at >> >>http://groups.google.com/group/puppet-users?hl=en. >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Puppet Users" group. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> >http://groups.google.com/group/puppet-users?hl=en. >> >> -- >> ⎋ Puppet Labs Developer –http://puppetlabs.com >> ♲ Made with 100 percent post-consumer electrons > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Is there anything like chef knife in puppet. I want to install the specific module on the plain ubuntu machine using puppet scripts. Thanks in advance, Sateesh B. On Dec 9 2011, 10:22 am, Brian Gupta <brian.gu...@brandorr.com> wrote:> I would consider the following a small list of pros and cons for the three > tools: > > Pros: > Cfengine: Not written in Ruby, so currently is more efficient with system > resources. > Puppet: IMHO has the most approachable syntax of the three (for sysadmins), > and the strongest community. It also has the widest platform support, with > a lot of preexisting code and code examples out there. > Chef: Configs are written in Ruby, and somewhat modeled on Rails > development patterns, so it is relatively easy for Ruby/Rails devs to pick > up. Also, Chef was designed from the ground up for the cloud, so is focused > on things like dynamically spinning up cloud instances. (Check out knife > and databags) If you don''t want to manage your own Chef server you can get > it as a preconfigured service. > > Cons: > Cfengine: Can be a bit challenging to learn, especially the promise theory. > Puppet: Particularly with older versions of Ruby can have memory usage > issues. Variable scoping is not ideal. These issues are manageable though. > Chef: No true dependency graphing, (implicit execution order) Setting up a > chef server is a bit on the challenging side, since it has a number of > requirements that don''t fall into very common use. (Erlang based CouchDB, > and Solr). Learning Ruby is mandatory. > > None of these tools are perfect and each have their warts, but any one of > them would make your life a lot easier. I''d say though that I prefer Puppet > over cfengine in almost all cases (except maybe a case where I am managing > only machines that have very tight resource constraints). Chef vs Puppet it > depends. If I was working entirely in the cloud and I had a very dynamic > environment, or was a Ruby shop, Chef would probably be my choice. In > almost all other cases I would go with Puppet. That said, the Puppet > community is working to address the Cloud deployment differences, so if the > cloud is in the future but not a now thing, I wouldn''t let that effect your > decision. (And puppet does work in the cloud today, just the support is > relatively new and not yet as robust as Chef''s) > > All in all, for the reason of community and ecosystem alone, I''d say go > with Puppet. > > Here are some random syntax examples: > cfengine:http://www.sysadmin.hep.ac.uk/wiki/Cfengine:_Installing_Xrootd_with_c... > puppet:http://people.redhat.com/dlutter/puppet-app.html > chef:https://github.com/opscode/cookbooks/blob/master/apache2/recipes/defa... > > Cheers, > Brian > > P.S. - Another tool to look at, that I have *heard* good things about is > bcfg2, but it isn''t nearly as popular as the others. > > -- > <http://aws.amazon.com/solutions/solution-providers/brandorr/>-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
https://github.com/puppetlabs/puppet-module-tool We are working to integrate that better with the rest of the product, so it ships by default, but the external version will work for now. On Tue, Jan 31, 2012 at 04:58, sateesh <bbalasateesh@gmail.com> wrote:> > Is there anything like chef knife in puppet. I want to install the > specific module on the plain ubuntu machine using puppet scripts. > > Thanks in advance, > Sateesh B. > > On Dec 9 2011, 10:22 am, Brian Gupta <brian.gu...@brandorr.com> wrote: >> I would consider the following a small list of pros and cons for the three >> tools: >> >> Pros: >> Cfengine: Not written in Ruby, so currently is more efficient with system >> resources. >> Puppet: IMHO has the most approachable syntax of the three (for sysadmins), >> and the strongest community. It also has the widest platform support, with >> a lot of preexisting code and code examples out there. >> Chef: Configs are written in Ruby, and somewhat modeled on Rails >> development patterns, so it is relatively easy for Ruby/Rails devs to pick >> up. Also, Chef was designed from the ground up for the cloud, so is focused >> on things like dynamically spinning up cloud instances. (Check out knife >> and databags) If you don''t want to manage your own Chef server you can get >> it as a preconfigured service. >> >> Cons: >> Cfengine: Can be a bit challenging to learn, especially the promise theory. >> Puppet: Particularly with older versions of Ruby can have memory usage >> issues. Variable scoping is not ideal. These issues are manageable though. >> Chef: No true dependency graphing, (implicit execution order) Setting up a >> chef server is a bit on the challenging side, since it has a number of >> requirements that don''t fall into very common use. (Erlang based CouchDB, >> and Solr). Learning Ruby is mandatory. >> >> None of these tools are perfect and each have their warts, but any one of >> them would make your life a lot easier. I''d say though that I prefer Puppet >> over cfengine in almost all cases (except maybe a case where I am managing >> only machines that have very tight resource constraints). Chef vs Puppet it >> depends. If I was working entirely in the cloud and I had a very dynamic >> environment, or was a Ruby shop, Chef would probably be my choice. In >> almost all other cases I would go with Puppet. That said, the Puppet >> community is working to address the Cloud deployment differences, so if the >> cloud is in the future but not a now thing, I wouldn''t let that effect your >> decision. (And puppet does work in the cloud today, just the support is >> relatively new and not yet as robust as Chef''s) >> >> All in all, for the reason of community and ecosystem alone, I''d say go >> with Puppet. >> >> Here are some random syntax examples: >> cfengine:http://www.sysadmin.hep.ac.uk/wiki/Cfengine:_Installing_Xrootd_with_c... >> puppet:http://people.redhat.com/dlutter/puppet-app.html >> chef:https://github.com/opscode/cookbooks/blob/master/apache2/recipes/defa... >> >> Cheers, >> Brian >> >> P.S. - Another tool to look at, that I have *heard* good things about is >> bcfg2, but it isn''t nearly as popular as the others. >> >> -- >> <http://aws.amazon.com/solutions/solution-providers/brandorr/> > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Jan 31, 2012 at 4:58 AM, sateesh <bbalasateesh@gmail.com> wrote:> > Is there anything like chef knife in puppet. I want to install the > specific module on the plain ubuntu machine using puppet scripts.Puppet Cloud Provisioner [1] and [2] also can provision a plain ubuntu machine for you in the cloud. [1] http://forge.puppetlabs.com/puppetlabs/cloud_provisioner [2] https://github.com/puppetlabs/puppetlabs-cloud-provisioner -- Jeff McCune -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks Jeff for your response. But I hope the URL''s that you provided require Amazon account. But I need to do this in a provate cloud. I need to install the Openstack on newly created VM in our Private cloud. In chef we have a command with knife where we can provide the IP address of our newly created VM, credentials and the module that need to be installed on that plain Ubuntu VM. The chef server will install the specified module on that VM. Is there any way to do this using puppet? Thanks in advance, Sateesh B. On Feb 1, 3:02 am, Jeff McCune <j...@puppetlabs.com> wrote:> On Tue, Jan 31, 2012 at 4:58 AM, sateesh <bbalasate...@gmail.com> wrote: > > > Is there anything like chef knife in puppet. I want to install the > > specific module on the plain ubuntu machine using puppet scripts. > > Puppet Cloud Provisioner [1] and [2] also can provision a plain ubuntu > machine for you in the cloud. > > [1]http://forge.puppetlabs.com/puppetlabs/cloud_provisioner > [2]https://github.com/puppetlabs/puppetlabs-cloud-provisioner > > -- > Jeff McCune-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Jan 31, 2012 at 9:08 PM, sateesh <bbalasateesh@gmail.com> wrote:> Thanks Jeff for your response. > > But I hope the URL''s that you provided require Amazon account. But I > need to do this in a provate cloud. I need to install the Openstack on > newly created VM in our Private cloud. In chef we have a command with > knife where we can provide the IP address of our newly created VM, > credentials and the module that need to be installed on that plain > Ubuntu VM. The chef server will install the specified module on that > VM. Is there any way to do this using puppet?Yes, but a slight customization to cloud provisioner is necessary. The `puppet node install` command accepts an IP address and will install Puppet or Puppet Enterprise onto the system with that IP address. Cloud Provisioner uses SSH to log into the remote system and install Puppet. We stop there though. None of the installation scripts [1] are able to download a module and run Puppet using that module. You could take the puppet-community script [2] and copy it to a new name in the same directory. If you add the commands required to install the puppet module and run puppet against a manifest inside the module then this will accomplish your goal. For example: cat puppet-community-localcopy.erb #!/bin/bash ... provision_puppet # Install the Puppet Module tool gem install puppet-module # Install a module from the Forge cd /etc/puppetlabs/modules puppet-module install puppetlabs-stdlib puppet-module install puppetlabs-ntp # Do a puppet configuration run with the NTP class included in the configuration catalog puppet apply -v -e ''include ntp'' With this custom script template you can install on the targ Hope this helps [1] https://github.com/puppetlabs/puppetlabs-cloud-provisioner/tree/master/lib/puppet/cloudpack/scripts [2] https://github.com/puppetlabs/puppetlabs-cloud-provisioner/blob/master/lib/puppet/cloudpack/scripts/puppet-community.erb -- Jeff McCune -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thank you Jeff. This is what I am looking for. But is there any other tool where we can install on a private cloud rather than Amazon EC2. Thanks in advance, Sateesh B. Jeff McCune wrote:> On Tue, Jan 31, 2012 at 9:08 PM, sateesh <bbalasateesh@gmail.com> wrote: > > Thanks Jeff for your response. > > > > But I hope the URL''s that you provided require Amazon account. But I > > need to do this in a provate cloud. I need to install the Openstack on > > newly created VM in our Private cloud. In chef we have a command with > > knife where we can provide the IP address of our newly created VM, > > credentials and the module that need to be installed on that plain > > Ubuntu VM. The chef server will install the specified module on that > > VM. Is there any way to do this using puppet? > > Yes, but a slight customization to cloud provisioner is necessary. > > The `puppet node install` command accepts an IP address and will > install Puppet or Puppet Enterprise onto the system with that IP > address. Cloud Provisioner uses SSH to log into the remote system and > install Puppet. > > We stop there though. None of the installation scripts [1] are able > to download a module and run Puppet using that module. > > You could take the puppet-community script [2] and copy it to a new > name in the same directory. If you add the commands required to > install the puppet module and run puppet against a manifest inside the > module then this will accomplish your goal. > > For example: > > cat puppet-community-localcopy.erb > #!/bin/bash > ... > provision_puppet > # Install the Puppet Module tool > gem install puppet-module > # Install a module from the Forge > cd /etc/puppetlabs/modules > puppet-module install puppetlabs-stdlib > puppet-module install puppetlabs-ntp > # Do a puppet configuration run with the NTP class included in the > configuration catalog > puppet apply -v -e ''include ntp'' > > > With this custom script template you can install on the targ > > Hope this helps > > [1] https://github.com/puppetlabs/puppetlabs-cloud-provisioner/tree/master/lib/puppet/cloudpack/scripts > [2] https://github.com/puppetlabs/puppetlabs-cloud-provisioner/blob/master/lib/puppet/cloudpack/scripts/puppet-community.erb > > -- > Jeff McCune-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.