Hacker News Reader

Comment by newhouseb | Hacker News Reader

Wow, I have that sinking feeling that this OpsWorks stuff may have turned what was a coin flip decision we made between Chef and Puppet (in which we chose Puppet) to a one heavily weighted towards Chef, but hard to say without reading more.

My immediate question is how easy it would be to keep your Chef recipes in source control somewhere and have equally easy one click deployment to both AWS and to a local Vagrant development box. We currently have a similar environment set up with puppet and it makes testing sysadmin stuff pretty awesome.

Edit: already finding holes - can't deploy to cluster compute instances (a deal breaker) and deployment seems rather slow (15 minutes to deploy from scratch versus about 8 with normal puppet) :(

View on HN

There's a vanilla Chef repo you can clone to store cookbooks, roles, and data bags in source control [0].

For testing on local VMs there's Opscode's bento [1], which automates creating Vagrant baseboxes and running recipes. You can specify using Chef Solo to do this, which speeds up testing significantly as it removes chatting to remote Chef or Hosted Chef servers.

[0] https://github.com/opscode/chef-repo

[1] https://github.com/opscode/bento

Previously been in your position. I chose Chef.

I think you shouldn't worry, I wouldn't be surprised if they will support BOTH Chef and Puppet in the future - it's their best interest to support both.

Why would OpsWorks' choice of configuration and deployment management software affect your own choice, unless you want some sort of hybrid?

I think this will be a boon to AWS users who are currently deploying manually, but I don't think very many people who already use deployment/config management software will want to switch and rely on AWS.

I don't think it's a puppet/cfengine/ansible/salt killer,

I think the big advantage here is really just how much you just get out of the box without sacrificing flexibility -- if you're deploying on AWS in the first place. This seems like it would also save us from writing a bunch of management scripts (around scaling, etc) which would be tied to AWS anyway (read: no inherent disadvantage since any solution in-house or not would require the AWS platform). I'm always looking for ways for us to reduce our code/services footprint and this would seem to do so without a huge amount of vendor lock-in.

I don't think it is.

Basically if you get your car from the dealership (AWS is great esp for EC2 and S3), you don't have to buy the tires from them too.

What I saw from the video does look interesting, but in the end, if you are going to have to edit your configuration management recipes in git, and then you're going to have the same choices to make about what tool is best for you. Whether that's Chef or something like http://ansible.cc -- this is what you are going to pick because it's what you're going to spend most of your automation time in.

I also suspect Amazon will feel that people may want to bring their own tools and will add more options over time.

We also decided to use Puppet, but I'm afraid this could generally change the configuration management world towards Chef.

it's easy, but also a bit hacky... because opsworks triggers multiple lifecyle events and also distributes the chef config if you solve the config problem, maybe with a static example you're pretty much done

Reply on news.ycombinator.com