I've been looking into various configuration management/automated deployment tools lately. At OpenX we used slack, but I wanted something with a bit more functionality than that (although I'm not badmouthing slack by any means -- it can definitely be bent to your will to do pretty much whatever you need in terms of automating your deployments).
From what I see, there are 2 types of configuration management tools:
- The first type I call 'pull', which means that the servers pull their configurations and their marching orders in terms of applying those configurations from a centralized location -- both slack and Puppet are in this category. I think this is great for initial configuration of a server. As I described in another post, you can have a server bootstrap itself by installing Puppet (or slack) and then 'call home' to the central Puppet master (or slack repository) and get all the information it needs to configure itself
- The second type I call 'push', which means that you send configurations and commands to a list of servers from a centralized location -- Fabric is in this category. I think this is a more appropriate mode for application-specific deployments, where you might want to deploy first to a subset of servers, then push it to all servers.
So, as a rule of thumb, I think it makes sense to use a tool like Puppet for the initial configuration of the OS and of the packages required by your application (things like MySQL, Apache, Tomcat, Tornado, Nginx, or whatever your application relies on). When it comes time to deploy your application, I think a tool like Fabric is more appropriate, since it gives you more immediate and finer-grained control over what you want to do.
I also like the categorization of these tools done by the people at ControlTier. Check out their blog post on Achieving Fully Automated Provisioning (which also links to a white paper PDF) for a nice diagram of hierarchy of deployment tools:
- at the bottom you have tools that install or launch the initial OS on physical servers (via Kickstart/Jumpstart/Cobbler) or on virtual machines/cloud instances (via various vendor tools, or by rolling your own)
- in the middle you have what they call 'system configuration' tools, such as Puppet/Chef/SmartFrog/cfengine/bcfg2
- at the top you have what they call 'application service deployment' tools, such as Fabric/Capistrano/Func -- and of course their own ControlTier tool
In a comment on one of my posts, Damon Edwards from ControlTier calls Fabric a "command dispatching tool", as opposed to Puppet, which he calls a "configuration management tool". I think this relates to the 2 types of tools I described above, where you 'push' or 'dispatch' commands with Fabric, and you 'pull' configurations and actions with Puppet.
New Whitepaper: Achieving Fully Automated Provisioning
What we are proposing is an outline of an open source toolchain for fully automated provisioning.
What's the criteria for "fully automated provisioning"?
That details are in the whitepaper but here's the list we came up with:
- Be able to automatically provision an entire environment -- from "bare-metal" to running business services -- completely from specification
- No direct management of individual boxes
- Be able to revert to a "previously known good" state at any time
- It's easier to re-provision than it is to repair
- Anyone on your team with minimal domain specific knowledge can deploy or update an environment
Here's the proposed open source toolchain (with ControlTier and Puppet highlighted):
Great post.
I found it interesting that you would directly compare a command dispatching tool like Fabric to a configuration management tool like Puppet.
We did a whitepaper on how these different types of tools can be used as an open source toolchain to achieve fully automated provisioning (going from bare metal all the way to running multitier applications)
The whitepaper is written about a specific ControlTier and Puppet implementation but the toolchain and the general concepts hold for tools like Chef, Fabric, Cobbler, Capistrano, etc.
Here's the link:
http://blog.controltier.com/2009/04/new-whitepaper-achieving-fully.html
Damon -- I guess my intention wasn't clear. I didn't mean to compare Fabric to Puppet as an apples-to-apples comparison. I was merely wishing that a Puppet-like configuration management tool existed in Python. I know about bcfg2, I haven't played with it though.
Thanks for the pointer to your white paper.
Grig
Ah got it. You know, that does touch on an excellent subject... when you build a toolchain of management tools, what kind of overhead are you adding because of differing languages or configuration methods? It begs the question, is it easier to bend (or some would say abuse) one tool to do most of everything that you want or should use a toolchain that lets each tool do what its supposed to be good at?
______________________________________________________________
|
|
I'm new to Puppet and while I've been using *nix systems for many years, I've never worked as a sysadmin or in ops.
I'm currently writing Puppet manifests for hosting a set of (PHP/MySQL/MongoDB, code in git) web applications. Clearly Puppet needs to have some knowledge of the actual applications because I'll set up a virtual host for each one, but I'm not sure whether Puppet should be managing things like code deployment and database creation.
Is Puppet an appropriate tool for application deployment? If not, can you recommend a more appropriate tool?
|
|
asked Mar 22 '12 at 22:03
|
|
|
|
|
|
You'll have better control over how the deployment happens with these two tools.
|
|
|
answered Mar 23 '12 at 2:40
|
|
|
|
|
|
Puppet is used for deployments in many large organizations, but it's not always perfect. Much of it depends on your deployment methodology. Are you deploying to lots of machines at once? Do you do rolling deployments?
Some organizations use Puppet by building packages of their deployments and then having puppet enforce policy to be at the right version of that package. Because puppet has the concept of environments included, you can use environments to do deployments in stages (dev, test, prod for example).
Other organizations use puppet to orchestrate deployment by either firing off an rsync, git checkout or some recursively file copies using puppet (though that is rather slow).
There are other pretty good tools available for deployment too. I have used Whiskey Disk in the past (a simple ruby tool) and liked it a lot.
(Disclaimer, I work at Puppet Labs)
|
|
answered Mar 23 '12 at 0:25
|
|
|
|
__________________________________________________________
Issues with MCollective as Deployment Orchestrator
https://groups.google.com/forum/#!msg/mcollective-users/624ZMIOcNf0/0nHwcZ2FVqgJ
