IMO, Puppet isn't quite the right fit for application deployments in a lot
of situations. In Drupal-speak - if you have multiple Drupal frontends
with a shared MySQL backend, Puppet doesn't fit for deployments very well.
What you need in that case is an orchestration tool.
Why? Puppet cares about state, but it's not the best thing for applying
states to machines at a certain time in a certain order. Often times with
Drupal, you have a workflow to complete as part of a deployment: 1) Put up
the maintenance page 2) Upgrade the application server code 3) Upgrade the
db. If the DB gets upgraded before all the appservers are running the
latest code, fun ensues.
There's all kinds of tools that are more ideal for that - Jenkins,
Capistrano, MCollective, and Rundeck are a few.
We use Puppet to initially setup a machine to participate in the cluster.
When provisioned, it will have the same revision of code as everything
else. However, for coordinated deployments of already deployed
applications, we rely upon other tools.
HTH,
Justin
On Thursday, April 19, 2012 10:05:01 PM UTC-5, Will S. G. wrote:
I'm trying to convince my company to use puppet as the release management
engine to publish the bits for Drupal to the web servers. The reason why I
want this is to cut off the developers from production, but also create a
process and procedure for code release to the stage and production
environments. While this is possible, my question is, do you use puppet in
such manner?
Thanks.
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/O9ktBPgbcPoJ.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.
