Hacker News Reader

Comment by muxneo | Hacker News Reader

try chef, puppet or saltstack

"Operational simplicity" would like to have a word with you.

If I remember correctly puppet required installing an agent. To add to the injury it wasn't available on the RHEL (clone) ISO and right now it's also missing from Fedora EPEL.

You could give Puppet Bolt a try, which is like a blend of an Ansible agentless method with declarative Puppet manifests.

https://cinc.sh/ a good (FOSS) replacement for chef.

Err, they aren't simple. They're equivalent to ansible in terms of difficulty (I'd say Puppet even more of a headache) having worked with all of them.

I'm moving thinking that Ansible is simpler for simple things, but complex for complex things, I find it more and more often in our servers configuration to have "configuration drift" due to fact Ansible encourages to managing by parts, not as whole system. And very rare is run automatically over all nodes say every 15 minutes.

Isn't that the point of things like cloud-init, and other system tools. Ansible may not be great at deploying, but the whole purpose would be to catch the drift using Ansible.

I'm not sure what you mean by parts and not a whole system. It's defined via hosts inventories which, by defintion are a whole system. You obviously include roles and further tasks for those definitions.

You'd use cloud-init, as the other poster mentions, to initalise, or use ansible in SSH mode with the inventory coming from your cloud provider or just an ini/YAML list curated by yourself, then run it regularly from something Jenkins/Rundeck/Cron whatever, in which case cloud-init configures your ansible run user and ssh keys so you can kick it off from the main box and perhaps register the node, or use tags in cloud provider, loads of ways.

> I'm not sure what you mean by parts and not a whole system. From what I see around, work with Ansible is organized via multiple playbooks i.e. * playbooks/nginx.yaml * playbooks/kafka.yaml * playbooks/monitoring.yaml

each of them configuring only subpart of the whole system. Some of them may have intercrossing functions, like changing sysctls. Thus, it's enforcing state of subset of services, and if, for example after Nginx playbook you logically need to run Monitoring playbook, it can be forgotten/skipped -> configuration drift grows.

Hope it clarifies.

Reply on news.ycombinator.com