5 ms·

Chef 11 released

68 points by tphummel 14y ago

seyz 14y ago
Impossible for me to join the opscode website. Maybe HN has crashed the web server due to the number of users? :)
- chm 14y ago
  It works for me.
- dguaraglia 14y ago
  502, bad gateway. I think they might be having some issues with deployment :)
- esad 14y ago
  What's even worse is that the install script at https://www.opscode.com/chef/install.sh https://www.opscode.com/chef/install.sh is also unavailable, which is the default way of getting chef installed onto newly provisioned server.
  - chrislaco 14y ago
    Yeah. That's a fail. Pretty much killed my afternoon.
lifeisstillgood 14y ago
Can someone explain to me the benefits of moving to chef or puppet as opposed to say my current approach of writing deploy scripts in pythons fabric (basically ssh and file operations library) I have even used Puppet but I could not get over the feeling that it is more complex than I would imagine for small end users (I have managed upto 40 servers with my libraries - it seemed quite feasible to double that. Maybe it's me but 100 servers sounds a lot and is manageable (deployment wise) with controlled scripts.
- jvehent 14y ago
  Chef maintains a database of all the nodes in your environment. Nodes can search for neighbors and configure themselves accordingly. I wrote a firewall cookbook that takes advantages of Chef's search capabilities to dramatically reduce the maintenance of our firewalls, while keeping the rules ultra specific (inbound and outbound). Check it out: https://github.com/jvehent/AFW/ https://github.com/jvehent/AFW/ & http://jve.linuxwall.info/blog/index.php?post/2012/11/14/AFW http://jve.linuxwall.info/blog/index.php?post/2012/11/14/AFW
  - lifeisstillgood 14y ago
    I maintain a database of all the nodes (servers, Linux or BSD so not talking routers ) as well - one would go mad otherwise. And I feel that at certain scales one should tell hosts what to do, not rely on some auto discovery Process - especially if that process is not out and out cloning. Edit: just to clarify I am not attacking your choice here or your contribution to the state if the art in GitHub - we need more people making. But I would like to understand why a guy who is unlikely to run more than a couple dozen servers again needs to learn to debug and battle something like chef when the imperative scripting approach is simpler and more direct I suppose I am asking, at what scale does chef et al pay off compared to expect-like scripts (assuming the development time of a simple script is roughly equal in both)
    - jvehent 14y ago
      And I feel that at certain scales one should tell hosts what to do, not rely on some auto discovery Process - especially if that process is not out and out cloning. That's one thing, in Chef, that scares me. Access control on node attributes is inexistent. Even in private/hosted chef. So that a node can modify its own run_list, its own tags, etc... A frontend node that gets rooted can suddenly become a backend database. If the environment is configured to allow for automated configuration of everything, this can get ugly very quickly. Even with Chef, human approval of new nodes and roles is still mandatory.
      - 14y ago
pwelch 14y ago
I started with Chef around version 10.4. It's really amazing to see how far Chef and the community have come since then. Keep up the awesome work Opscode!
Tomino 14y ago
I haven't try Chef yet, but it seems like it has some advantages, I should give it a try!
druiid 14y ago
Congratulations to the Chef crew! Here's one thing I still am wondering though, being a relatively heavy Puppet user now. What are the big benefits to using Chef, or would it be mostly just admin choice here? When I was originally deciding upon a CM system I looked at Puppet, Chef and Salt and decided that Salt was too new (even though I know Python), Chef declared everything in Ruby and I had no intention of learning Ruby just to generate server configurations and then finally Puppet, which I found (personally) to be simple to use/learn and didn't require me to directly learn Ruby unless I need to extend the 'language' of Puppet.
- pjungwir 14y ago
  Theoretically you can use Chef without knowing Ruby, since if you're using pre-existing cookbooks you can just say what to install by listing the recipes in JSON format. But practically speaking I'd say Ruby is essential. It'd be a disaster trying to use others' cookbooks without being able to read the recipes, and almost certainly you'll want to do something they don't cover. On the other hand, perhaps Chef is an opportunity to learn Ruby? Certainly you can be productive with a very superficial understanding of the language, so you could get started pretty quickly. And a Chef recipe is about the flattest, simplest code imaginable.
  - druiid 14y ago
    Well, if you're using Chef and just using pre-existing cookbooks I'd say you take away 90% of the power of a CM system. So yeah, probably using Chef you have to know Ruby, full-stop. For admins whom have a history with Ruby that's not a huge request, but at the same time I question how useful it is to basically require an admin to code in a particular language to build system configurations (And that is the one thing that drew me to Puppet... that while it had a 'language' it wasn't REALLY a language, more a template syntax). I can certain agree with the idea of using Chef as an opportunity to learn Ruby and when the day comes I have some spare time to start then it might be a good place to begin using it. Really though beyond the language aspect, I was wondering what the feature-set that Chef offered over Puppet, things like structural decisions like how nodes are managed, node removal (kind of a sore spot in Puppet right now), etc.
zem 14y ago
the combination of erlang backbone + ruby nodes is a wonderful way to write distributed systems. i've put in my time rolling my own when a single-node system needed to go distributed, and today i'd pay the up-front cost of integrating either erlang or a message queue as soon as i added the second node; these things invariably have to scale up more than you'd expect, and your homegrown system will almost as invariably fall over and die when you can least afford it.
makerbreaker 14y ago
Another thing I think helps to explain how beneficial a good configuration management system is, especially if you have a good deal of systems, is to think of the servers as part of a botnet, and chef as the command and control.
tszming 14y ago
My overall experience with Chef isn't that great, because seems to me their team didn't response to users'issue seriously. E.g. I have reported a bug [1] half year ago that the chef-server failed to start automatically when your server restart, still mark as `Unresolved` and no official answer from chef. I think when your server startup script failed to work on a major distribution like Ubuntu, it should be considered as critical, right? [1] http://tickets.opscode.com/browse/CHEF-3204 http://tickets.opscode.com/browse/CHEF-3204
- gchpaco 14y ago
  Depressingly their competitors are no better. I've been monitoring a bug in puppet that's been open for the better part of three years for adding options like "--enablerepo" to yum invocations. This is not technically difficult to do but they keep dithering on design issues "because it's not cross platform". (Really? Because Ubuntu and RedHat totally agree on how to name packages, where system files live, which init.d to use, and those are both Linuxes; it gets even stupider with Solaris, BSD and Windows)
- btmspox 14y ago
  I'm sorry you feel that you didn't have a good experience. As one of the original Chef contributors before Opscode, and then becoming one of the lead people working with the open source community for Opscode, the vitality of the open source Chef project is very important to me. However, Opscode's support for all of our open source projects also hinges on the company being successful enough to continue to do so. Thus, a balance must be struck. Opscode doesn't respond to every ticket on that open source tracker, just like we don't write all of the code in the open source project. I personally try to at least see every issue, but with over 1.8 million installs of the Chef gem alone, there are a lot of users out there. If you want a guaranteed response, we do have various paid support plans which will provide you with that, but it doesn't come for free because we have to pay the people who research and write those responses. There are multiple ways to install the Chef 10 Server and many ways to start the processes. We have tried to support the most popular, and I think most people have found success. We're proud that we can do things like release our rewrite of the Chef Server in erlang back to open source. We want it to be easy for people to use Chef. We initially wrote it to make our lives easier, and we want your lives to be easier too. That's why the Chef 11 Server ships in our Omnibus packaging, which provides a running Chef Server in three commands or less.

Chef 11 released

68 points by tphummel 14y ago

seyz 14y ago

Impossible for me to join the opscode website. Maybe HN has crashed the web server due to the number of users? :)

chm 14y ago
It works for me.
dguaraglia 14y ago
502, bad gateway. I think they might be having some issues with deployment :)
esad 14y ago
What's even worse is that the install script at https://www.opscode.com/chef/install.sh https://www.opscode.com/chef/install.sh is also unavailable, which is the default way of getting chef installed onto newly provisioned server.
- chrislaco 14y ago
  Yeah. That's a fail. Pretty much killed my afternoon.

lifeisstillgood 14y ago

Can someone explain to me the benefits of moving to chef or puppet as opposed to say my current approach of writing deploy scripts in pythons fabric (basically ssh and file operations library) I have even used Puppet but I could not get over the feeling that it is more complex than I would imagine for small end users (I have managed upto 40 servers with my libraries - it seemed quite feasible to double that. Maybe it's me but 100 servers sounds a lot and is manageable (deployment wise) with controlled scripts.

jvehent 14y ago
Chef maintains a database of all the nodes in your environment. Nodes can search for neighbors and configure themselves accordingly. I wrote a firewall cookbook that takes advantages of Chef's search capabilities to dramatically reduce the maintenance of our firewalls, while keeping the rules ultra specific (inbound and outbound). Check it out: https://github.com/jvehent/AFW/ https://github.com/jvehent/AFW/ & http://jve.linuxwall.info/blog/index.php?post/2012/11/14/AFW http://jve.linuxwall.info/blog/index.php?post/2012/11/14/AFW
- lifeisstillgood 14y ago
  I maintain a database of all the nodes (servers, Linux or BSD so not talking routers ) as well - one would go mad otherwise. And I feel that at certain scales one should tell hosts what to do, not rely on some auto discovery Process - especially if that process is not out and out cloning. Edit: just to clarify I am not attacking your choice here or your contribution to the state if the art in GitHub - we need more people making. But I would like to understand why a guy who is unlikely to run more than a couple dozen servers again needs to learn to debug and battle something like chef when the imperative scripting approach is simpler and more direct I suppose I am asking, at what scale does chef et al pay off compared to expect-like scripts (assuming the development time of a simple script is roughly equal in both)
  - jvehent 14y ago
    And I feel that at certain scales one should tell hosts what to do, not rely on some auto discovery Process - especially if that process is not out and out cloning. That's one thing, in Chef, that scares me. Access control on node attributes is inexistent. Even in private/hosted chef. So that a node can modify its own run_list, its own tags, etc... A frontend node that gets rooted can suddenly become a backend database. If the environment is configured to allow for automated configuration of everything, this can get ugly very quickly. Even with Chef, human approval of new nodes and roles is still mandatory.
    - 14y ago

pwelch 14y ago

I started with Chef around version 10.4. It's really amazing to see how far Chef and the community have come since then. Keep up the awesome work Opscode!

Tomino 14y ago

I haven't try Chef yet, but it seems like it has some advantages, I should give it a try!

druiid 14y ago

Congratulations to the Chef crew! Here's one thing I still am wondering though, being a relatively heavy Puppet user now. What are the big benefits to using Chef, or would it be mostly just admin choice here? When I was originally deciding upon a CM system I looked at Puppet, Chef and Salt and decided that Salt was too new (even though I know Python), Chef declared everything in Ruby and I had no intention of learning Ruby just to generate server configurations and then finally Puppet, which I found (personally) to be simple to use/learn and didn't require me to directly learn Ruby unless I need to extend the 'language' of Puppet.

pjungwir 14y ago
Theoretically you can use Chef without knowing Ruby, since if you're using pre-existing cookbooks you can just say what to install by listing the recipes in JSON format. But practically speaking I'd say Ruby is essential. It'd be a disaster trying to use others' cookbooks without being able to read the recipes, and almost certainly you'll want to do something they don't cover. On the other hand, perhaps Chef is an opportunity to learn Ruby? Certainly you can be productive with a very superficial understanding of the language, so you could get started pretty quickly. And a Chef recipe is about the flattest, simplest code imaginable.
- druiid 14y ago
  Well, if you're using Chef and just using pre-existing cookbooks I'd say you take away 90% of the power of a CM system. So yeah, probably using Chef you have to know Ruby, full-stop. For admins whom have a history with Ruby that's not a huge request, but at the same time I question how useful it is to basically require an admin to code in a particular language to build system configurations (And that is the one thing that drew me to Puppet... that while it had a 'language' it wasn't REALLY a language, more a template syntax). I can certain agree with the idea of using Chef as an opportunity to learn Ruby and when the day comes I have some spare time to start then it might be a good place to begin using it. Really though beyond the language aspect, I was wondering what the feature-set that Chef offered over Puppet, things like structural decisions like how nodes are managed, node removal (kind of a sore spot in Puppet right now), etc.

zem 14y ago

the combination of erlang backbone + ruby nodes is a wonderful way to write distributed systems. i've put in my time rolling my own when a single-node system needed to go distributed, and today i'd pay the up-front cost of integrating either erlang or a message queue as soon as i added the second node; these things invariably have to scale up more than you'd expect, and your homegrown system will almost as invariably fall over and die when you can least afford it.

makerbreaker 14y ago

Another thing I think helps to explain how beneficial a good configuration management system is, especially if you have a good deal of systems, is to think of the servers as part of a botnet, and chef as the command and control.

tszming 14y ago

My overall experience with Chef isn't that great, because seems to me their team didn't response to users'issue seriously. E.g. I have reported a bug [1] half year ago that the chef-server failed to start automatically when your server restart, still mark as `Unresolved` and no official answer from chef. I think when your server startup script failed to work on a major distribution like Ubuntu, it should be considered as critical, right? [1] http://tickets.opscode.com/browse/CHEF-3204 http://tickets.opscode.com/browse/CHEF-3204

gchpaco 14y ago
Depressingly their competitors are no better. I've been monitoring a bug in puppet that's been open for the better part of three years for adding options like "--enablerepo" to yum invocations. This is not technically difficult to do but they keep dithering on design issues "because it's not cross platform". (Really? Because Ubuntu and RedHat totally agree on how to name packages, where system files live, which init.d to use, and those are both Linuxes; it gets even stupider with Solaris, BSD and Windows)
btmspox 14y ago
I'm sorry you feel that you didn't have a good experience. As one of the original Chef contributors before Opscode, and then becoming one of the lead people working with the open source community for Opscode, the vitality of the open source Chef project is very important to me. However, Opscode's support for all of our open source projects also hinges on the company being successful enough to continue to do so. Thus, a balance must be struck. Opscode doesn't respond to every ticket on that open source tracker, just like we don't write all of the code in the open source project. I personally try to at least see every issue, but with over 1.8 million installs of the Chef gem alone, there are a lot of users out there. If you want a guaranteed response, we do have various paid support plans which will provide you with that, but it doesn't come for free because we have to pay the people who research and write those responses. There are multiple ways to install the Chef 10 Server and many ways to start the processes. We have tried to support the most popular, and I think most people have found success. We're proud that we can do things like release our rewrite of the Chef Server in erlang back to open source. We want it to be easy for people to use Chef. We initially wrote it to make our lives easier, and we want your lives to be easier too. That's why the Chef 11 Server ships in our Omnibus packaging, which provides a running Chef Server in three commands or less.