5 ms·

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

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

pearkes 13y ago
Here's how: $ VAGRANT_LOG=[debug, info, warn, or error] vagrant up https://github.com/mitchellh/vagrant/blob/master/lib/vagrant.rb#L31 https://github.com/mitchellh/vagrant/blob/master/lib/vagrant...
nu2ycombinator 13y ago
What is chef mate?
- rytis 13y ago
  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/ http://www.opscode.com/chef/
  - mross462 13y ago
    When performing searches for chef resources, it's best to use "opscode chef".
1123581321 13y ago
How have you found Chef to be and what alternatives did you consider? We are evaluating Chef and Ansible right now.
- rytis 13y ago
  Just curious - why is Puppet not on your shortlist?
  - 1123581321 13y ago
    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.
- spoondan 13y ago
  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.
spoondan 13y ago
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.
- pixelmonkey 13y ago
  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.
- neurostimulant 13y ago
  Django automatic code reloading is working fine on my environment (osx host, Ubuntu vm). Are you working on windows host?
- encoderer 13y ago
  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.
apolzon 13y ago
@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.

pearkes 13y ago

Here's how: $ VAGRANT_LOG=[debug, info, warn, or error] vagrant up https://github.com/mitchellh/vagrant/blob/master/lib/vagrant.rb#L31 https://github.com/mitchellh/vagrant/blob/master/lib/vagrant...

nu2ycombinator 13y ago

What is chef mate?

rytis 13y ago
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/ http://www.opscode.com/chef/
- mross462 13y ago
  When performing searches for chef resources, it's best to use "opscode chef".

1123581321 13y ago

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

rytis 13y ago
Just curious - why is Puppet not on your shortlist?
- 1123581321 13y ago
  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.
spoondan 13y ago
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.

spoondan 13y ago

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.

pixelmonkey 13y ago
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.
neurostimulant 13y ago
Django automatic code reloading is working fine on my environment (osx host, Ubuntu vm). Are you working on windows host?
encoderer 13y ago
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.

apolzon 13y ago

@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.