Ansible: Pure (only in its) pragmatism | Hacker News Reader

Ansible: Pure (only in its) pragmatism

andrejradovic.com

The fact that Ansible doesn't allow feedback when a task is running, or give you access to the output of the task [it does give the response, but in a urlencoded json field that is useful but not friendly), makes it incredibly difficult for me to write tasks for, and uncomfortable to use.

The fact that it makes a new connection for every command, even when just doing a loop, makes it slow as mollasses. To add insult to injury, the name Ansible means "a tool faster than light"!

The fact that there is no way to return in the middle of a task, means that I cannot use task files as functions - that is, I cannot just tell Ansible that a given file exists it should stop running this taskfile, it will stop the whole playbook or nothing.

And because I cannot add conditions to a block, that means that the best I can do is make deeply nested layers of playbooks - ie. not the Ansible way.

These are just off the top of my head - I use Ansible heavily, and curse it all the time!

Has Ansible solved the issue where some tasks (e.g. postgresql_user) require a Python module to be available, which you don't want to be installed in the global environment? Last I looked into it you could use a venv but had to monkey around with some envvars and it wasn't ergonomic in the least.

You can monkey with the Python primitives, containerize the runtime env, or probably something more involved

Would suggest the middle option: https://docs.ansible.com/ansible/latest/getting_started_ee/i...

One can use the primitives, but eventually you'll find conflict or drift. Config management becomes something else. Not worth the hassle considering inconsistent usage/placement of the 'become' keyword, the '-b' argument, and such.

EEs slot perfectly into AWX/AAP, the next logical step once you've grown tired of using the Ansible CLI.

Nope, the issue is still there, and not just for Postgres. You need `hvac` to use Hashicorp Vault-related stuff, for example.

There's a decent workaround, though, if you don't mind managing your Ansible install with `pipx` instead of your system package manager:

    $ pipx install ansible --include-deps
    $ pipx inject ansible psycopg2-binary --include-apps

I'd prefer to use `uv tool install` instead of `pipx`, but it's not there yet [1].

You can also containerize it w/ Podman or Docker and install the deps in the container. Maybe even add an alias.

[1]: https://github.com/astral-sh/uv/issues/6314

Just to clarify, for the reader, that ansible and python are only required for the deployment host, not it's targets.

being agentless and using ssh for transport, the target hosts need only have an ip address listed in the deployment hosts inventory, aka one can address target hosts directly after creating them, given ssh access.

much of ansibles python issues are just python issues.

ansible is a very flexible tool, and idempotent behavior is largely a factor of playbook design until it hits real world limits.

The managed nodes do indeed need Python, though the requirements tend to be lower.

The bulk of the modules essentially generate Python payloads for Ansible to ship/run/track. Most of the burden is on the controller. Not all.

The execution environment information I linked [in another comment] covers what this user points out

Not low enough, unfortunely.

Ran into this recently with Ansible 2.17 which can no longer fully run (dnf/yum modules don't work) on EL8 targets due to platform-python being 3.6.

2.16 still works but goes EOL in May, when the OS is supported until 2029.

Feels like a very deliberate attempt to get you paying for Red Hat's version. On one hand I can't blame them, but on the other, that's never going to happen at my company.

Definitely feels like a nudge. "Oh, you're on EL?"

More of an own-goal than anything. This'll just push more to Shuttleworth.

Reply on news.ycombinator.com