Magento Stack Exchange is a question and answer site for users of the Magento e-Commerce platform. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking into chef to automate Magento deployments — both into standard Magento hosting options as well as environments like EC2. I've googled around and I see numerous recipes, but none really strikes me as a canonical one. Is there's a particular chef script that's better/the best? Also, if you've done chef deployments with PHP before, what's one thing you wish you'd know when you were starting out?

share|improve this question
I wish I'd known Ansible ( existed. – Reid Blomquist Jul 3 '14 at 20:27
Some other alternatives if you're interested, and Both look promising but I haven't had a chance to work with either. – beeplogic Jul 3 '14 at 21:33
I've been experimenting with capistrano-ash: – pzirkind Jul 4 '14 at 0:24
I think Reid's onto something, Alan re: Ansible. It doesn't require an agent (works with ssh + keys) to be installed on clients, it's a declarative system so it's idempotent and in general I've found that using it leaves me with the "do one thing, do it simply, and do it well" unix-like feeling compared to more robust systems like chef, puppet, and salt. It's been while since you posted this originally, any updates on your thoughts after working with chef a while? – Bryan 'BJ' Hoffpauir Jul 6 '15 at 23:53
up vote 6 down vote accepted

It’s nearly impossible to have a one-size-fits-all set of routines. I’ve had success writing a Bash script that executes chef-client runs on lists of hosts provided by knife search. The procedures look like this…

Open source Chef Server 10.18.2 on Ubuntu 12.04 LTS

  1. Initialize variables
  2. Get the latest revision hash from GitHub for $branch
  3. Disable availability monitoring to prevent alerts over HTTP 503 status
  4. Switch all web and utility hosts to maintenance mode
  5. Deploy utility
    1. Stop Magento’s cron and all Resque workers
    2. Address filesystem dependencies
    3. Chef checks out the defined revision as a new release
    4. Address Magento dependencies (packages, modules, filesystem, permissions)
    5. Update all cron tasks and scripts for automation
    6. Deploy all modules (composer)
    7. Clear cache with n98-magerun.phar
    8. Run any migrations with n98-magerun.phar
    9. Re-enable Magento cron
    10. Start Resque workers
  6. Deploy the first web host
    1. Address filesystem dependencies
    2. Chef checks out the defined $revision as a new release
    3. Address Magento dependencies
    4. Deploy all Magento modules
  7. Mark a new deployment in New Relic
  8. Enable availability monitoring services
  9. Disable load balancer services to all other web hosts
  10. Continue deployments on web hosts, sequentially bringing them online
  11. Perform Chef routines for the search hosts


share|improve this answer

This is how I've approached this area while wearing the wanna be sysadmin/devops role. Most the following will be just general principles I try to follow and not Chef specific.

I ended up going with Puppet because I found there to be more resources at the time and felt easier to pick up for me.

I looked at the various pre-built modules available for things like apache, php5, etc. Many of them seemed to do way more than I needed and being so unfamiliar with the platform I didn't trust what was going on. I decided it was going to be simpler for me to just identify what I needed done on each node type.

I started the process by provisioning the team's local development environment (vargrant + virtual box). For each service/component I created a module: php5, apache2, redis, mysql, etc.

Once the dev environment was stable/working I began building out the QA environment. I defined generic node types for web servers, redis, varnish, etc. which reused the same modules as dev. Once this was done Staging and Production needed minimal changes were needed to get up and running.

As you're going through and writing your recipes/templates you should consider how if could be reused/generalized. Don't hard code things like paths or user/groups that could change between distros/projects/environments. Since you're looking at a generalized approach I would guess a large hurdle will be dealing with differences between *nix distributions.

Most importantly, keep is simple. Automate/standardize the most important/time consuming parts of the environment. Iterate, evolve.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.