5 ms·

2013 called and wants its favorite infrastructure as code (IaC) tool back.

bigstrat2003 2y ago
Tools don't stop being useful just because they aren't trendy. I still use Chef, and I love it. I much prefer it to Ansible or Puppet.
- eltondegeneres 2y ago
  IMO Ansible is easier to get started with, but less powerful than Chef.
- yjftsjthsd-h 2y ago
  I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.
  - bigstrat2003 2y ago
    The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.
    - hnlmorg 2y ago
      Ansible can work that way too. In fact every time I’ve migrated to Ansible (each time from Puppet), we’ve built the infrastructure so Ansible pulled its configuration.
    - esseph 2y ago
      https://docs.ansible.com/ansible/latest/cli/ansible-pull.html https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...
      - doubled112 2y ago
        I use this to keep my (too many) Linux desktops configured. A systemd service runs ansible-pull about 2 minutes after boot. It does its thing. It has some annoyances, but it works fine. I don't think about it anymore. The git repo is the source of truth.
    - closeparen 2y ago
      To me a deployment of new code or config is a workflow. The ordering and timing of its progress of the fleet is very important. You want to be able to plan it, watch it, and pause or reverse it from that perspective. SSH is inadequate because this process should be much slower than the life of anyone's terminal window. You could approximate it with cronjob pulls if each node's schedule is a little offset from the previous. But you probably also want different rollout schedules available for different scenarios.
  - fooqux 2y ago
    Different use cases, probably. I use Ansible personally when I'm dealing with a server or two. I use Puppet professionally when I am dealing with tens of thousands of servers and trying to keep them all in some kind of unity.
  - escape_velocity 2y ago
    You do indeed need to upload cookbook changes with knife; but if you keep your cookbooks in Git you can set up CI/CD pipelines that spawn a container that runs the knife upload steps for you (and even do validation via cookstyle before). Then all you need to do after changing your cookbooks and/or recipes is to commit those changes to your Git repo and watch the CI/CD pipeline do it's thing.
  - eltondegeneres 2y ago
    You could use Chef in local mode and pull down the cookbooks from s3 or something.
  - sofixa 2y ago
    > the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying It also has tons of advantages, notably around scale (Ansible id very slow when working with thousands of machines) and ensuring that there is no drift. Also e.g. SaltStack (RIP) has cool features such as reactor to react to events on the machine which are only possible because there's an agent
- curun1r 2y ago
  All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues. And I think that's where the comment you're responding to is coming from. Once you've experienced Docker/K8s and, to a lesser extent, IaC tools like Terraform, it's hard to see yourself ever going back to tools like Chef in the same way that tools like Chef made it hard to see going back to a world where we configured servers manually.
  - bigstrat2003 2y ago
    Docker, k8s, Terraform etc are nice. I make extensive use of them too. But in my opinion they can't be used for everything, because mutable infrastructure is a reality of the world that must be accounted for at some point. For example, at my employer we have on-prem k3s clusters running on bare metal servers. Chef is a perfect tool to manage those, because they are by their nature not something we can treat as stateless, immutable configurations. It seems to me that this is kind of like abstraction levels in programming. If you can use a high level language with lots of powerful tools, you do. But some people have to live in the world of C or even assembly, because (as James Mickens said) you can't just place a Lisp book on top of an x86 chip and hope it learns about lambda calculus by osmosis. I view IaC tools in the same way: if you can use Terraform or Docker, great! But someone has to use lower level tools to provide the environment in which those things exist. And that's why people shouldn't look at Chef (or other similar tools) as outdated, any more than assembly is outdated just because Lisp exists. They still very much have a strong use case that won't ever go away.
dsr_ 2y ago
UNIX: 1973 vi: 1976 BSD UNIX: 1978 x86 instruction set: 1978 UNIX System V R4.2 1983 Linux: 1991. Kids these days.
nunez 2y ago
Chef is still popular in the enterprise. It's a good tool.
- jonathaneunice 2y ago
  It's an okayish tool. After using it for a few years, accumulated enough quirks to significantly diminish my initial enthusiasm. The concurrency gotchas, the utter lack of debugging and profiling tools, the weak management of today's most common deployment models (e.g. Docker/containers and cloud services)...it's not "good" by 2025 standards. I'm sure enterprises still do use it. But they also still use RPG, PL/I, and IMS. So...

bigstrat2003 2y ago

Tools don't stop being useful just because they aren't trendy. I still use Chef, and I love it. I much prefer it to Ansible or Puppet.

eltondegeneres 2y ago
IMO Ansible is easier to get started with, but less powerful than Chef.
yjftsjthsd-h 2y ago
I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.
- bigstrat2003 2y ago
  The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.
  - hnlmorg 2y ago
    Ansible can work that way too. In fact every time I’ve migrated to Ansible (each time from Puppet), we’ve built the infrastructure so Ansible pulled its configuration.
  - esseph 2y ago
    https://docs.ansible.com/ansible/latest/cli/ansible-pull.html https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...
    - doubled112 2y ago
      I use this to keep my (too many) Linux desktops configured. A systemd service runs ansible-pull about 2 minutes after boot. It does its thing. It has some annoyances, but it works fine. I don't think about it anymore. The git repo is the source of truth.
  - closeparen 2y ago
    To me a deployment of new code or config is a workflow. The ordering and timing of its progress of the fleet is very important. You want to be able to plan it, watch it, and pause or reverse it from that perspective. SSH is inadequate because this process should be much slower than the life of anyone's terminal window. You could approximate it with cronjob pulls if each node's schedule is a little offset from the previous. But you probably also want different rollout schedules available for different scenarios.
- fooqux 2y ago
  Different use cases, probably. I use Ansible personally when I'm dealing with a server or two. I use Puppet professionally when I am dealing with tens of thousands of servers and trying to keep them all in some kind of unity.
- escape_velocity 2y ago
  You do indeed need to upload cookbook changes with knife; but if you keep your cookbooks in Git you can set up CI/CD pipelines that spawn a container that runs the knife upload steps for you (and even do validation via cookstyle before). Then all you need to do after changing your cookbooks and/or recipes is to commit those changes to your Git repo and watch the CI/CD pipeline do it's thing.
- eltondegeneres 2y ago
  You could use Chef in local mode and pull down the cookbooks from s3 or something.
- sofixa 2y ago
  > the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying It also has tons of advantages, notably around scale (Ansible id very slow when working with thousands of machines) and ensuring that there is no drift. Also e.g. SaltStack (RIP) has cool features such as reactor to react to events on the machine which are only possible because there's an agent
curun1r 2y ago
All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues. And I think that's where the comment you're responding to is coming from. Once you've experienced Docker/K8s and, to a lesser extent, IaC tools like Terraform, it's hard to see yourself ever going back to tools like Chef in the same way that tools like Chef made it hard to see going back to a world where we configured servers manually.
- bigstrat2003 2y ago
  Docker, k8s, Terraform etc are nice. I make extensive use of them too. But in my opinion they can't be used for everything, because mutable infrastructure is a reality of the world that must be accounted for at some point. For example, at my employer we have on-prem k3s clusters running on bare metal servers. Chef is a perfect tool to manage those, because they are by their nature not something we can treat as stateless, immutable configurations. It seems to me that this is kind of like abstraction levels in programming. If you can use a high level language with lots of powerful tools, you do. But some people have to live in the world of C or even assembly, because (as James Mickens said) you can't just place a Lisp book on top of an x86 chip and hope it learns about lambda calculus by osmosis. I view IaC tools in the same way: if you can use Terraform or Docker, great! But someone has to use lower level tools to provide the environment in which those things exist. And that's why people shouldn't look at Chef (or other similar tools) as outdated, any more than assembly is outdated just because Lisp exists. They still very much have a strong use case that won't ever go away.

dsr_ 2y ago

UNIX: 1973 vi: 1976 BSD UNIX: 1978 x86 instruction set: 1978 UNIX System V R4.2 1983 Linux: 1991. Kids these days.

nunez 2y ago

Chef is still popular in the enterprise. It's a good tool.

jonathaneunice 2y ago
It's an okayish tool. After using it for a few years, accumulated enough quirks to significantly diminish my initial enthusiasm. The concurrency gotchas, the utter lack of debugging and profiling tools, the weak management of today's most common deployment models (e.g. Docker/containers and cloud services)...it's not "good" by 2025 standards. I'm sure enterprises still do use it. But they also still use RPG, PL/I, and IMS. So...