3 ms·

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 t

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

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