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.

Bash scripts will only get you so far and I can wholly recommend Ansible for automation.

Basically the main advantage of Ansible is that its builtin tasks are “idempotent” which means you can re-run them and end up with the same result. Of course it is possible to do the same with bash scripts, but you may require more checks in place.

The other advantage of Ansible is that there are hundreds of modules for configuring a lot of different things on your system(s) and most are clear and easy to understand.

Ansible is most useful if you have a large volume of systems. It’s a great tool for what it does but imo, it not worth learning if you’re not going to be needing it frequently.

Yes it is absolutely worth it. I’m personally using SaltStack because I already knew some but if I were starting anew I’d go with Ansible. I completely disagree with the opinion that it’s similar to Bash but I don’t have the energy to go into detail for why. From user’s perspective, config management code is much clearer to read and write, much less error prone than bash scripts and it’s easy to reuse other people’s battle tested code (often in production) to deploy things for yourself. Personally I find it way easier to read Salt code I forgot everything about than Bash.

If you haven’t used any configuration management before it would definitely be valuable to learn.

However I would also recommend trying Nix and NixOS. The provide much better reproducibility. For example using Ansible-like tools I would always have issues where I create a file, then remove the code to create the file but the file still exists or the server is still running. I wrote a post going into more detail about the difference a while ago https://kevincox.ca/2015/12/13/nixos-managed-system/. However this is more involved. If you already have a running server it will be a big shift, instead of just slowly starting to manage things via Ansible.

But I would definitely consider using something. Having configuration managed and versioned with history is super valuable.

Ansible is the way to go

Do we prefer Ansible over Terraform?

I think others have covered the main points, but I found it hard going for 1 device (ie a Ras Pi, VM, etc), but then it was effortless when I wanted to add a 2nd (or more…), so at first pick the sensible uses, then consider ansible for that one-off device a little later…

I like a few specific utils (tmux, nmon, htop) on all my devices: ansible script

I want to update all the Ras Pis in the house: ansible script

You get the picture…

I have been setting it up on my home, still not done but I can already see some benefits from it, e.g. I’m about to build a new server and migrate a lot of stuff to it, with ansible it will be very easy to just move some configs around and setup the server in no time at all. It also is encouraging me to keep a standard on how I do things which is great, and after setting up some initial things now adding new services is quite straightforward.

Overall I think there are a lot of positives about it, especially if you have multiple machines to manage. But even for a single one the fact that you can recreate everything from scratch in just one command is quite awesome considering the amount of times I’ve redone my server from 0 for different reasons over the past years.

Look to other orchestrations solution too, like SALT. If you need to manage a lot of servers it is live saver. Setting up is only first step.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

3 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.

[Thread #731 for this sub, first seen 1st May 2024, 10:25] [FAQ] [Full list] [Contact] [Source code]