IMHO Ansible isn’t much different than a bash script… it has the advantage of being “declarative” (in quotes because it’s not actually declarative at all: it just has higher-level abstractions that aggregate common sysadmin CLI operations/patterns in “declarative-sounding” tasks), but it also has the disadvantage of becoming extremely convoluted the moment you need any custom logic whatsoever (yes, you can write a python extension, but you can do the same starting with a bash script too).

Also, you basically can’t use ansible unless your target system has python (technically you can, but in practice all the useful stuff needs python), meaning that if you use a distro that doesn’t come with python per default (eg. alpine) you’ll have to manually install it or write some sort of pythonless prelude to your ansible script that does that for you, and that if your target can’t run python (eg. openwrt on your very much resource-constrained wifi APs) ansible is out of the question (technically you can use it, but it’s much more complex than not using it).

My two cents about configuration management for the homelab:

• whatever you use, make sure it’s something you re-read often: it will become complex and you will forget everything about it
• keep in mind that you’ll have to re-test/update your scripts at least everytime your distro version changes (eg. if you upgrade from ubuntu 22.04 to 24.04) and ideally every time one of your configured services changes (because the format of their config files may in theory change too)
• if you can cope with a rolling-style distro, take a look at nix instead of “traditional” configuration management: nixos configuration is declarative and (in theory) guarantees that you won’t ever need to recheck or update your config when updating (in reality, you’ll occasionally have to edit your config, but the OS will tell you so it’s not like you can unknowingly break stuff).

BTW, nixos is also not beginner-friendly in the least and all in all badly documented (documentation is extensive but unfriendly and somewhat disorganized)… good luck with that :)

Coming from what looks to me like a different perspective to many of the commenters here (Disclosure I am a professional platform engineer):

If you are already scripting your setups then yes you should absolutely learn/use Ansible. The key reasons are that it is robust, explicit, and repeatable- doesn’t matter whether that’s the same host multiple times or multiple hosts. I have lost count of the number of pet Bash scripts I have encountered in various shops, many of them created by quite talented people. They all had problems. Some typical ones:

The thing about Ansible is that it can be modular (if you want) and you can use other people’s code but fundamentally it runs one step at a time. You will know for each step:

• Are dependencies met?
• Did that step succeed or fail (in realtime!)?
• (If it failed) what was the error?
• (Assuming you have written sane Ansible) you can re-run your playbook at any time to get the ‘same’ result. No worries about being left in an indeterminate state
• (To an extent) It is self-documenting
• Host architecture doesn’t really matter
• Target architecture/OS is specified and clear

I think it is a great way to document what you have done too. Especially with larger setups this can be quite time-intensive.

Then add that you may want to dynamically reconfigure your systems to interact with each other and then Ansibles template-rendering comes in really handy.

Finally, it is standardized - so other peopke can work with it too (relevant in work context).

Configuration management and build automation are definitely worth the time and effort of learning. It doesn’t have to be ansible, find which tool suits your needs.

if tech is your career then yes.