Hacker News Reader

Comment by tootie | Hacker News Reader

I feel like the entire configruation management movement has passed me by. I still don't understand what value there is in chef/puppet/salt/ansible/docker vs bash or even Perl for that matter. Someone care to set me straight?

View on HN

When you're managing more than a handful of servers, you very quickly start wanting to be able to run the same command on multiple machines - "upgrade all my API boxes to the not-vulnerable nginx", for instance, or "push this binary out to all my database servers". These sorts of services make that straightforward, and generally provide a large library of prewritten modules to do moderately-complicated things without having to write a lot of boilerplate or read somebody else's Bash scripts or Perl.

Well, I've done that just using remote shell commands. And I'd have an easier time reading someone else's bash than I would their ansible whatevers. Is it actually more concise?

When written correctly, it's idempotent. I've done a lot of server management with bash and it's a lot easier to achieve idempotency with something like Chef.

What if you have to upgrade a software package and add a new config file that is different on every server. I guess you can do that via a horrible sed command, but having native template support with variables is pretty nice.

Same for things like "tune the amount of worker processes depending on the amount of CPU cores the machine in question has".

Things like Ansible/Salt and similar tools cut out a lot of the boilerplate. There are also plenty of modules you can reuse without having to roll your own. You can achieve the same results using Bash/Perl/Python but a lot more effort is needed.

It's usually more concise because idempotency comes by default. Instead of saying "create this file" (which might throw a 'file already exists' error the 2nd time you run the setup script), you say "ensure this file exists".

Some bash commands are idempotent too (e.g. apt-get install), but it's not something you can rely upon, and you often have to code the idempotency in yourself.

The primary wins are:

* Your servers are all kept in a known state that is described by your code. If you don't have configuration management, you have to remember that postgres is installed on X server and has Y configuration. Which is ok for simple configurations but quickly becomes a total mess for semi-complex configurations.

* You can go from a clean server to a fully fledged working server (or set of servers) in a single, repeatable step.

* You can remove repetition from your code base and decouple your server configurations. Database password needs to be used in six different places? No problem. Specify it in one centralized configuration file and then just use template variables to make it appear wherever it needs to be upon deployment.

Reply on news.ycombinator.com