Comment by pixelmonkey | Hacker News Reader

Comment by pixelmonkey | Hacker News Reader

Parent Full thread

We switched from hand-configured boxes and a long, "full stack local" setup document to chef + vagrant at my current company (http://parse.ly).

Though it caused some kicking & screaming on the development team, the end result is that every developer has the same development environment, which pretty much matches our deployment environment (in Rackspace Cloud). I also just kicked off our summer intern class, and the interns were able to get productive with our codebase in 1 day despite not having much experience with modern Python web development, because pretty much every local setup step was automated.

I consider the tool invaluable. I don't even install any databases or tools directly on my laptop any longer. With its handy port forwarding feature, you can put all your DBs on a VM, yet still connect w/ CLI clients via your host machine. Then when you do "vagrant halt", all your DBs shut down at once and you free all those resources / memory / etc.

Also, one suggestion -- look into the debug logging level that you can set with an environmental variable. The only thing I found frustrating about Vagrant were situations where it would hang/fail but it wouldn't be clear why. It turns out their debug logging is quite good.

Here's how:

    $ VAGRANT_LOG=[debug, info, warn, or error] vagrant up

https://github.com/mitchellh/vagrant/blob/master/lib/vagrant...

How have you found Chef to be and what alternatives did you consider? We are evaluating Chef and Ansible right now.

I'm not the OP, but:

These systems are broadly the same. If you're writing your configuration from scratch, they're all fairly pleasant, and it's mostly a matter of preference. They share most of the same concepts (although the terminology differs) and features. In my experience, their differences are primarily in feel and community.

For feel: Chef gives you Ruby pretending to be declarative. Puppet and Ansible give you something more declarative at the expense of some expressivity. Puppet has its own syntax, and Ansible shoe-horns some procedural aspects into YAML syntax. I prefer Chef here. (Chef also provides a web UI that lets you edit things, but I strongly advise against using it except for managing nodes. Everything else should be code/JSON.)

For community: With configuration management, one of the things you'll want is good community involvement. You don't want to write every cookbook/playbook/module from scratch. From what I've seen, Chef and Puppet have a large head start in this department.

That said, you should be prepared to customize the community offerings. People generally implement precisely what they need, in precisely the way they need it, and your needs will not always align. Fork all of the community offerings so you can modify them while still pulling from upstream. Managing this is decidedly difficult, but there's no better choice. It's one of the areas where git submodules would be really great, if only they were nicer to use. If you're going to use Chef, consider also using Berkshelf for managing your cookbooks.

If you do not have configuration management in place, pick one of the major ones, learn the hell out of it, and get to automating your operations. Having your infrastructure as code that you can run whenever you want, that you can review to see exactly how something is configured, is life changing. Once you get to doing it, you will never want to go back to the bad old days.

Chef and Puppet are quite different, in my opinion.

Based on my exposure, Chef ultimately boils down to being a complex remote execution framework. Puppet makes detect-and-correct more central to its model.

http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...

Interesting comparison, but shoukd be mentioned that Dell, AWS, and others, are leveraging knowledge around Chef.

And Citrix, Rackspace and Oracle are using Puppet ("leveraging knowledge"? pls no).

Appeals to authority don't tell us anything about the technology except that somebody we've heard of is using it.

Dell and Amazon leveraged chef to help build Crowbar and Opsworks respectively. Crowbar ... leveraging ... get it?

In any case, noting Opsworks is based on Chef is not an "appeal to authority".[1] That knowing Chef means you have a head start on AWS's official devops tooling, seems a relevant data point for a comparison. (The officially supported devops tooling leveraging a particular CM system is different from simply being able to be managed by a CM system.)

As for Rackspace, here's the CM category of their dev blog:

  http://developer.rackspace.com/blog/categories/configuration-management/

And here's "How Rackspace Uses Chef to Deploy OpenStack in the Private Cloud":

  http://developer.rackspace.com/blog/cooking-with-chef4.html

Quoting a different Rackspace article from Feb 2013:

The Rackspace Private Cloud Certification team sought out and tested a number of bare metal provisioning tools. While there are a number of excellent tools on the market, none seemed to fit quite well. On one hand, some tools were all-encompassing in scope and would try to provide an end-to-end solution. On the other hand, tools were too narrow in scope and provided a solution for a specific operating system or did not provide an appropriate amount of flexibility.

Eventually, we picked a deployment model consisting of a combination of tools that would provide the right balance of features and flexibility. We chose the Razor provisioning engine, combined with the OpsCode Chef configuration management tool.

1. http://plover.net/~bonds/bdksucks.html

Just curious - why is Puppet not on your shortlist?

It's on the list, too, but I (possibly incorrectly) see Chef and Ansible having a more similar philosophy and workflow to each other than to Puppet so I am hoping to eliminate one of them.

How are you reloading your Python application on code changes? Are you just working inside the VM? I've tried VirtualBox shared folders and NFS, and never had any luck getting file change events to propagate from my host to the VM.

Shared folders work well for me & everyone else on me team. Perhaps you should file a ticket for your issue?

Also, if you use port forwarding for all your databases etc. then you could technically just run Python code on your host computer. Indeed, I do this myself usually -- I treat the Vagrant box more like a "deployment target" that just happens to also run the DBs I can use for local testing.

I, too, have had problems. In my case it's an OSX host, Ubuntu client.

Most of my python work isn't webdev so I've never had an issue with it in python but other daemons that do this sort of thing -- Brunch for example -- have given me intermittent trouble. I never did figure it out.

Django automatic code reloading is working fine on my environment (osx host, Ubuntu vm). Are you working on windows host?

@pixelmonkey i recently implemented a chef/vagrant deployment to the rackspace cloud. I'm extremely curious how you managed to share the setup between rackspace cloud and local vagrant boxes. I used the vagrant-rackspace plugin, and it seemed like I would need a separate vagrantfile for local vs remote deployments.

What is chef mate?

I'm replying because terms like "chef", "knife" and "recipe" sometime yield funny results on Google.

Keeping the long story short - it's a configuration management system. Have a look at http://www.opscode.com/chef/

When performing searches for chef resources, it's best to use "opscode chef".

Reply on news.ycombinator.com