4

Is it good practice to version control the nodes and roles when using chef? If so, what is a good way to do it?

It looks likes one should be able to take a tree of JSON files created using chef_server_backup.rb and simply check it into VC. Are there better alternatives?

Update

It turns out that checking in the JSON produced by chef_server_backup.rb is not a good solution. The problem is that the JSON produced by the script is not stable. Each time the hashes come out in a different order and the resulting files are totally different to the previous versions ... even though they means the same thing when parsed as JSON. I would be better of just saving compress tarballs.

(But if I could canonicalize the JSON files by ordering the attributes ... )

1 Answer 1

4

I try and keep as much of my configuration as possible as JSON files and update chef-server with knife [noun] from file name.json. I started with the repository at https://github.com/opscode/chef-repo and I keep all of JSON files in the appropriate directories. You can do the same with YAML or Ruby files too. Use the show command, like knife role show apache2 -Fj > roles/apache2.json to create files from existing data already on a chef-server.

Some of the benefits of a "from file"-based approach are:

  • Relatively easy to move between Hosted Chef and Private Chef
  • You can test with chef-solo using existing role files, data_bag items, etc
  • Track deltas between changes via git diff, and view history of more than just cookbook versions
  • Redundancy of data: if your Private Chef server or Hosted Chef is unavailable, you still have all of your infrastructure configuration

The only thing not in opscode/chef-repo are node files. You can export/import nodes from files too, but it's generally not recommended because nodes should be disposable. I like how Nathen Harvey once said: "think of nodes as cattle, not pets."

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .