Hacker News new | ask | show | jobs
by bryogenic 2038 days ago
Anyone who thinks that any tool will make systems administration and automation "simple" has drank the kool-aide of some sales pitch.

Systems administration and automation is complex.

That being said I've found Ansible to be the most useful tool for the job. It does the things I need it to and new modules are usually easy to incorporate into my work if I need specific tasks done. It has its shortcomings but it hasn't blown up into an unmaintainable mess like many of the other solutions I've poured hundreds of hours into.

YAML is not fun, but it's been good enough for the task of pushing parameters around.

2 comments

As a long time puppet user, I started forcing myself to use ansible for my homelab so I can learn it's intricacies and limitations.

Recently I had a use-case where I wanted to re-use some data from a defined variable (list of objects) in a second module, but the format had to be different. In python I would have done something like new_var=[{a:i['a'], b:i['b']} for i in old_var], but apparently that is impossible in ansible. The best solution I was able to find after lots of searching was to to pass new_var to a jinja2 template which would render new_var as text, then run that through a json interpreter and set that as new_var. Absolutely rediculous.

It astounds me that a tool BUILT on python lacks any semblance of python's biggest feature, list comprehension.

Modules are where the python lives. Really well written, idempotent, and battle tested python.

But "writing" Ansible playbooks is definitely not python. It's its own dsl bastardized between yaml, jinja2 and reserved/special keywords. This is the worst thing I can say about the whole toolkit.

Unfortunately, I'm really productive with it and when I return to work I've written 3+ years ago:

A) It still runs

2) I can read and understand the intent of my playbooks

It's not that it's YAML so much as it's yaml-trying-to-be-a-PL. At that point why not go the hashicorp route an just use a programming language DSL?
If you don't try throwing tons of logic in the YAML (and build a module or plugin where needed to keep that logic out of the YAML), then your playbooks are 99% of the time simple YAML lists and dicts.

The hardest thing for some people seems to be whitespace issues, but that can be resolved easily enough by integrating a linter into your environment, or minimally showing whitespace characters in your editor.

Whitespace issues plague careless people in general, but ansible's choice to run jinja2 using its default delimiters of `{` was the million dollar mistake since it forces quoting to start a scalar with that character and it's quoting issues in yaml which compromise a significant portion of the SO questions I triage

Even allowing a playbook to opt out of the default delimiters in the same way one can in a template file[1] would allow a transition out of that mess

    #jinja2:variable_start_string:'<%', variable_end_string:'%>'
    - debug:
        msg: <% my_var %> needs no quoting!
1 = https://docs.ansible.com/ansible/2.10/collections/ansible/bu...
> then your playbooks are 99% of the time simple YAML lists and dicts.

But really, that's not the problem. The problem is when you inherit someone else's playbook that is itself trying to do a hackjob around a community playbook.

When you inherit any code, it's always a mess, at least that's my experience. Sometimes a working mess, but it's rare to inherit nice code in any system.

I could be biased since I've worked mostly with Python, Ruby, PHP, and Java.

of course, but debugging ansible YAML is exceptionally hard on account of the difficulty of decoding its quasi-declarative, quasi-imperative nature, the difficulty of knowing what the variables to be interpolated are (they could have been changed by other playbooks!), etc. You'll want at the very least a sane set of debug tools to figure things out when they go wrong.

The other alternative is to just give up and rewrite the ansible script, which has been what I had to do on several occasions.