Chef Server: Strategies for setting up development Environments

Question

I am starting to get comfortable with Berkshelf (which was a great way to learn chef by the way) and now I am wondering how I should go about managing / rolling out development environments for our PHP developers that I want to provide local/VM environments that are provisioned from Chef cookbooks.

I want to figure out what the ideal environment would be for both Chef developers, and the application developers (PHP devs in my case). I need repeatable local (or VM) environments for PHP developers that use my Cookbooks.

I was thinking to use Vagrantfile so the developer could configure a chef server with his or her certs, provision it, and start using the environment. What I am unsure about: should each developer have his or her own Vagrant node listed in Chef Server for each application? Or is there a way to use the Chef client provisioner without registering the vagrant node?

Basically, I don't really care about the nodes on local machines, but it would be awesome if the developer could provision with Vagrant from the Chef server so it matches other environments.

Secondly, all my Berkshelf-generated repos are using the Chef Client to provision. Is that good practice, or should I use chef-solo only for developing/testing cookbooks as a dev ops?

Answer 1

Totally an opinion type question, so I'll give my opinion based answer. Hopefully some of the other guys will chime in, as many of them have more experience than I do.

For App Developers

We use a combination of test-kitchen and supermarket, and it works great. We have a repo that contains a Gemfile, .kitchen.yml, and Berksfile. Ideally it would also have a one command setup script that will setup a supermarket user, knife.rb, install Vagrant, etc. This repo also contains all of the primitives used by chef-local (roles, environments, etc).

Eventually, it will have a Rakefile that will wrap all of that up nicely.

rake setup # installs any non-gem stuff, sets up users, berks install, etc.
rake standup # stands up our primary app and dependencies (involves multiple VMs playing together)
rake standup:standalone # stands up the primary app and dependencies all on one box
rake standup:otherApp # you get the idea

Each rake task can then call as many kitchen converge operations as it needs.

For Chef Developers

First, chef-solo is falling out of favor as chef-zero (aka local mode) becomes more and more popular. Solo will never go away, but I don't see a reason for it in your use case.

Second, most Chef's I've seen seem to have moved away from Vagrantfile and toward test-kitchen. Kitchen uses Vagrant under the covers by default, and like Vagrant is also able to use various other systems (Docker, AWS, Rackspace, VMware, etc). It's just a little more Chef centric. And would work really well for what you describe as it your "development environment" is going to need a testing framework anyway. So why use Vagrant with a test framework on top, when you can use test-kitchen and get two birds with one stone.

Third, Chef-zero is your friend. Don't make each developer spin up a VM with chef-server. Just have a git repo with your environments, roles, and data_bags. Then let them run Test-Kitchen with the chef-zero provisioner, or chef-local (which runs chef-zero) pointed at the git repo. It is far lighter weight this way, and allows all developers to share common objects.

Fourth, checkout ChefDK. It's pretty much got all of the above baked in, and is likely to become the "normal" way of doing things.

Fifth, if you're staring from scratch anyway, I'd recommend getting supermarket and chef-guard setup alongside your production chef-server. Chef-guard will make managing changes to roles, environments, and data bags 1000% easier to deal with. Supermarket integrates nicely with Berkshelf to give you full control over the cookbook versions used in your environment.