5 ms·
My experience is that Ansible becomes exponentially more difficult with the difficulty of your workflows, where programmatic tends to be logarithmic. For low c
by everforward 4y ago
My experience is that Ansible becomes exponentially more difficult with the difficulty of your workflows, where programmatic tends to be logarithmic. For low complexity tasks, Ansible is simpler and for high complexity tasks it gets more complicated.
Just as a random example, for complex group structures you have to know/remember that although Ansible allows nesting groups, groups are actually a flat structure. If you have prod.webservers and uat.webservers, the 'webservers' group will include members of both.
That's not hard to work around, but it can easily lead to situations where you end up deploying to prod even though you only intended to deploy to UAT.
Variables are kind of a mess too. Assuming the docs are authoritative, there are 22 different places that variables can come from and which one is used will depend on the precedence. At some point, a 'switch' or series of 'if-elif' statements start to sound much simpler.
- candiddevmike 4y agoRE: variables, I'm a heathen and set `hash_behaviour = merge`. This forces nested dict values to be merged instead of overwritten (lists cannot be merged, unlike Salt...). For whatever reason Ansible encourages users to not use this [1], which makes variable usage far more difficult than it should be IMO and leads to situations like you describe where folks have various top level variables for overrides (ssh:, ssh_local:, ssh_global:, etc to combine values). [1] https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-hash-behaviour https://docs.ansible.com/ansible/latest/reference_appendices...
- KAMSPioneer 4y agoOh wow, I've been working with ansible for a few years now, how have I not seen this before? I've even searched for it, but I didn't know what it was called, so... Do you know if this behavior can be enabled per-role, or even better, per-task?