Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chef to be acquired by Progress

blog.chef.io

Post reply on HN
Print view View original

91–100 of 146 posts

Re: Chef to be acquired by Progress

#91

Post by stevekemp »

Riverheart wrote: post #87
stevekemp wrote: post #63

Earlier quoted context omitted.

Halting development of the open source dashboard really hurt me, so I setup my own little alternative: https://github.com/skx/puppet-summary/ Simple to deploy, configure, and use. Although I always felt I should perhaps have based my work against the puppetdb to get a more dynamic "dashboard" it certainly replaced the old dashboard, and being only a single binary it is simple to install & manage.

Foreman too heavy for the use case? https://www.theforeman.org/

I suspect that I didn't know about that project back in 2017 when I started my own hasty reimplementation.

(Though I don't know if it supported puppet at that time.)

Re: Chef to be acquired by Progress

#92

Post by zimbatm »

hardwaresofton wrote: post #78
user5994461 wrote: post #55

My 2 cents on Chef is that's it's long dead. The handful of people I know who used chef professionally all gave strong negative feedback about it and moved away to ansible. While I can't comment on the exact problems because I didn't use it personally, there was a recurring mentions of losing states, seemingly destroying systems and configurations instead of setting things up. People were adamant that moving away fro…

While I'm not a proper sysadmin, Ansible is what I gravitated towards (and use for my own projects) and always seemed like the best choice out of Chef, Puppet, and Saltstack. Ansible is/was straight forward to use and understand, very F/OSS, relatively easy to orchestrate (even without tower), and had a nice ecosystem. Ansible always won for me because it was simple, and had just enough (though I always felt that the…

Another approach that we have been exploring with Terraform is to treat the machine configuration as resources[1]. It works pretty well when most of the system is vanilla with a few additions to it (like installing Docker).

[1]: https://github.com/numtide/terraform-provider-linuxbox

Re: Chef to be acquired by Progress

#93

Post by carlosf »

geerlingguy wrote: post #83
TinyRick wrote: post #60

Earlier quoted context omitted.

I disagree that it's "long dead". Keep in mind that Chef (the company) has several different products too...Chef Infra (traditional configuration management) has fallen out of favor and Ansible seems to be the popular choice these days, but there are still a lot of big Chef Infra shops (e.g. Facebook [0]) that have invested heavily into configuring their environments using Chef Infra, which would require a good bit o…

The fact that I've never heard of Habitat or InSpec means either they're extremely niche and not as popular as I think Chef would've hoped, or I'm completely out of touch with both app packaging and sec tooling. I'm hoping it's the former, but I wouldn't be too surprised if the latter since the 'enterprise' ecosystem of cloud tooling has grown exponentially in the past decade.

You're not out of touch, Terraform + Containers + People realizing that building immutable things is much better than managing state pretty much killed Chef and Puppet.

Re: Chef to be acquired by Progress

#95

Post by ultimoo »

I fondly remember learning and using Chef back in '10 when it was all the rage. Seemed to work really well given the basic AWS architecture (no containers & microservices) that we had at the time. Also notable was the thriving and friendly community that Chef had going for itself back in the day.

Re: Chef to be acquired by Progress

#97

Post by joseph »

user5994461 wrote: post #59
PaulHoule wrote: post #5

What's a good alternative to Chef?

The alternative is ansible. Everybody I know moved away from Chef to Ansible and never looked back. Historically there were 4 main configuration management tools: puppet/chef/ansible/salt. The first two faded away. They're unarguably not the most usable and require to program in ruby. The next generation ansible/salt came out and arguably did better on every aspect. I think it's fair to say that ansible is the safe s…

Ansible doesn't necessarily need ssh or a central control node, just a place to store roles as artifacts, such as Artifactory or a storage bucket.

Pass all of your variables and dependencies (role artifact urls, python requirements.txt, etc) to machines through user data and have the machine download the dependencies and run ansible-playbook to configure itself. Optionally, add a systemd timer to run it on a schedule and you have an "agent".

I've done it this way a large percentage of the time using ansible. The other way is by baking images and using ansible as the provisioner (using ssh but only during the image build).

Re: Chef to be acquired by Progress

#98

Post by user5994461 »

carlosf wrote: post #93
geerlingguy wrote: post #83

Earlier quoted context omitted.

The fact that I've never heard of Habitat or InSpec means either they're extremely niche and not as popular as I think Chef would've hoped, or I'm completely out of touch with both app packaging and sec tooling. I'm hoping it's the former, but I wouldn't be too surprised if the latter since the 'enterprise' ecosystem of cloud tooling has grown exponentially in the past decade.

You're not out of touch, Terraform + Containers + People realizing that building immutable things is much better than managing state pretty much killed Chef and Puppet.

People still have to manage quite a bit of setup for kubernetes/containers though... and that configuration usually happens with ansible, not chef. I think it's fair to say that Chef has failed to hold their market.

Re: Chef to be acquired by Progress

#99

Post by xorcist »

joaquin2020 wrote: post #81
xorcist wrote: post #68

Earlier quoted context omitted.

Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML. There is less buzz around those tools now however, and people tend to gravitate to other tools which are easier to get started with. They may end up "silent heroes" (much like Ruby itself, I would say) or they may end up replaced by other tools. The concept of state as text in version control is a timeless con…

> Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML. I am not sure what complex config state management solution brings to the table for immutable containers. The state is immutable, so there's nothing to manage after deployment. It's like using an atom bomb to take out a zit. Puppet/Chef in their glory days, pre-cloud pre-container, excelled at managing desir…

An application running as a container bascially carries the same configuration as one running without the container bits would. That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration.

The deployment side also carries configuration, including things like desired amount of instances, request routing and filtering, log destinations, log retention, persistent volume sizes and location, backup rules, metrics and monitoring rules etc.

If anything, application deployments today carry more configuration, not less. Fifteen years ago, half of the above didn't even exist. Perhaps you pointed you application to a syslog server and that was it.

All of this configuration exists in disparate tools (JSON files, YAML files, firewalls, metrics dashboards, cloud providers proprietary APIs) and will over time slowly turn into a sprawling mess. Bringing control over this into a central repository is a good thing.

Not sure about expensive, as the aim is maintainability and reduced complexity, but these tools do tend to get cumbersome. After all, they want to do everything. It's a fundamental problem. It's not surprising that has led to a surge in less capable tools.

Re: Chef to be acquired by Progress

#100

Post by [deleted] »

zimbatm wrote: post #92
hardwaresofton wrote: post #78

Earlier quoted context omitted.

While I'm not a proper sysadmin, Ansible is what I gravitated towards (and use for my own projects) and always seemed like the best choice out of Chef, Puppet, and Saltstack. Ansible is/was straight forward to use and understand, very F/OSS, relatively easy to orchestrate (even without tower), and had a nice ecosystem. Ansible always won for me because it was simple, and had just enough (though I always felt that the…

Another approach that we have been exploring with Terraform is to treat the machine configuration as resources[1]. It works pretty well when most of the system is vanilla with a few additions to it (like installing Docker). [1]: https://github.com/numtide/terraform-provider-linuxbox

[deleted]
Post reply on HN