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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
