On Mar 11, 2010, at 12:53 PM, Julian Simpson wrote:
> They're two distinct areas of 'deployment'. Puppet is more like,
systems
> deployment, cap is app or content deployment in my eyes.
Yes, I want to change that observation.
I use Puppet for deploying my blog. It's a WordPress distro with a
bunch of plugins, etc. It was too slow. I ended up inelegantly
using rsync from puppet to push out the distro instead, which was
insanely fast. Even that didn't come for free as I'm not using a
Puppetmaster at the moment, and paths got annoying. (I do accept
that's probably my issue, however).
Anyway, my point is that Puppet needs to give you a way to deploy a
tree of files, fast. If the new type mentioned above starts to give
you that, so much the better: it gets tedious to push files to your
version control system, ensure that your puppetmaster is up to date,
and then invoke puppet on the node that you're deploying to.
What's appealing about some developer-style deploy tools is that you
can push exactly what you're working on to one or more nodes and
test it. My experiences with Puppet suggest that it's not so
convenient. My 6 years as a build and release manager tell me that
it's generally a poor idea to use two application deployment tools.
Hmmm.
I essentially agree on both sides: Puppet isn't yet that great at
solving this problem, but using two tools sucks.
We're basically still in the formative stage of what we're going to do
here, but we've got some pretty good ideas. Mostly, it builds around
a much more powerful data model in the catalog, combined with a
centralized system that tracks inter-node dependencies.
Keeping in mind that this is all still a bit vague:
We'll be extending the data model to support service state
dependencies and simple state machines, along with (probably) some
kind of fill-in-the-value (which Markus insists on calling 'futures')
catalog. This, I think, gets us most of the way to what we need on a
single machine:
If you have two services, where one service specifies that it being in
a 'running' state requires that the other service must also be in a
'running' state, when you got to restart the required service then the
requiring service can automatically be brought down first.
If you have a single composite service (e.g., a "web app" composed of
a db and apache), then you could have a specification that defines how
it should behave depending on whether it should be running or not, and
then external data that defines which value you want in a given case.
Once we start tracking resource collection as a dependency (because
one host's configuration is now dependent on another's), plus a
centralized database containing all compiled catalogs, we've basically
got builtin node-order dependencies, all emergent rather than
declared. You could get dependencies through declaration, I think,
but it doesn't scale as well.
The 'external_resource' module I sent in last week[1] is a good
example of what the first bit will look like, but it has a lot of
"here be dragons" associated with it. To make it supportable in the
long term, you need to add builtin interfaces for checking service
state (probably with central correlation rather than direct
connectivity) plus the inter-node dependency system needs to recognize
this as a dependency.
Obviously, this is 80% theory, 15% plan, and 5% bs, but we do have
ideas for how it'll work, and we're making baby steps toward getting
some of it actually done.
In the meantime, I'd appreciate any results from people testing this
external resource stuff.
1 - http://github.com/reductivelabs/puppet-external-resource
--
The Internet, of course, is more than just a place to find pictures of
people having sex with dogs. -- Time Magazine, 3 July 1995
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@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.
