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?

  • 2
    I wish I'd known Ansible (ansible.com/home) existed. Commented Jul 3, 2014 at 20:27
  • Some other alternatives if you're interested, saltstack.com and docker.com. Both look promising but I haven't had a chance to work with either.
    – beeplogic
    Commented Jul 3, 2014 at 21:33
  • 1
    I've been experimenting with capistrano-ash: github.com/augustash/capistrano-ash
    – pzirkind
    Commented Jul 4, 2014 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? Commented Jul 6, 2015 at 23:53

2 Answers 2


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

Source: https://gist.github.com/parhamr/6177160#file-2-deployment


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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