1

We're deploying a multi-node PHP environment using chef.

I've written a couple of cookbooks for specific server roles, that install certain packages (mostly using the package manager) the application uses.

Now, what I would like is for chef to keep the packages on these nodes up-to-date. We have two environments: development and production. When, say, a new version of PHP comes out, I would like to test this new version on our development environment and then roll it out to production. My package definitions in the recipe for installing PHP looks like this:

package 'php' do
  action :install
  version '5.3.27'
end

What steps do I take when version 5.3.28 is released?

1

The best practice for chef is to always start with the same "going in" state. If you're deploying to the cloud, I would create an entirely new VM and deploy PHP from scratch.

If you don't have that luxury, then you're in a situation where you must maintain two known starting states. (1) No PHP is installed and (2) Old version of PHP is installed.

You can't chain them together where you always install 5.3.27 first, because that ruins the idempotency of that resource.

I would recommend a manual step where you uninstall 5.3.27 and start clean with a 5.3.28 chef install.

Lastly, I would recommend avoiding use of chef roles as much as possible. They cannot be versioned and make it difficult to update when you have both a development and production system sharing the same role (i.e. how do I change the role without effecting both environments?) Instead, consider using a parent cookbook to orchestrate.

|improve this answer|||||
  • The thing with this specific environment is that it's a scaling environment. The number of nodes scale up on a daily basis, but I want these packages to be at the same version at all times. Are you suggesting to replace every node after a version bump in one of my cookbooks? What's the difference between top-down EC2 user-data scripts and using chef then (other than the syntax)? I was under the impression that chef would be able to actively "manage" configuration on my nodes. – Jaap Haagmans Nov 21 '13 at 14:11
  • Your comment on using chef roles is intriguing, by the way, although I don't really understand the issue. Isn't this what the environment cookbook version constraints are for? – Jaap Haagmans Nov 21 '13 at 14:30
  • It is possible to run chef-client as a daemon process to update your machine regularly, but I wouldn't recommend. A forgetful developer could make changes to an unversioned role. This configuration would be pushed to every VM in your cluster, dev & prod! You have choice in using baked AMIs and raw AMIs. A baked AMI will scale much faster, whereas a raw AMI needs to be configured everytime. We use a hybrid model, where we bake inf like jdk in and at boot time we configure VM with latest jars and any environment config using a startup script. Regardless, use auto scaling groups. – scubadev Nov 21 '13 at 14:36
  • If you have chef-server web ui up, take a look at it. Roles exist outside of cookbooks. If you're using a role to exclusively touch a single cookbook, that might be ok. The problem arises when you have a role called 'web_vm' that depends on the php, nginx, etc cookbooks. How do I insert into this unversioned role a call to the apache cookbook without impacting all users of this role? The practice we've adopted is to create a top-level orchestration cookbook that can be versioned. That way prod can run 1.0.0 of the web-vm cookbook and dev can run 2.0.0. – scubadev Nov 21 '13 at 14:48
  • 1
    I was at the aws conference in vegas last week, definitely check out the videos when they're available. There are several good sessions on the use of chef, cloud formation, and auto scaling. Also, to clarify. You should still use chef to bake the infrastructure into your AMIs. Consider using a two phase approach, where the boot script grabs the validation pems (etc) from an S3 bucket, hits chef-server again, and installs the latest software & environment config. Also, use cloud formation to setup your AWS configuration (auto scale groups, etc) – scubadev Nov 21 '13 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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