Is ansible worth learning to automate setting up servers?
Hello, I have recently been seeing a boom in people using ansible for automating setting up vps’s, services, …
Is it worth it to learn ansible to do also automate the way I setup everything, or is a bash script good enough ( I know some bash scripting but ansible seems like it could be more worth the time to learn )?
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 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.
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
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.
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:
Issue
Example
Most people write bash scripts without dependency checks
’Of course everyone will have gnu coreutils installed, it’s part of every Linux distro’ - someone runs the script on a Mac
We need to pass this action out to a command-line tool, that’s obvious
Fails if command-line tool isn’t available, no handling errors from tool if they aren’t exactly what’s expected
Of course people will realise that they need to run this from an environment prepared in this exact (undocumented) way
Someone runs the script in a different environment
Of course people will be running this on x86_64/AMD64, all these third party binaries are available for that
Someone runs it on ARM
Of course people will know what to do if the script fails midway through
People try to re-run the script when it fails mid-way through and it’s a mess
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
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.
I guess it depends what you’re in to but it doesn’t make much sense for me.
Most everything I do on servers now is in docker containers, and I back up the compose files and data from those so they can be deployed to a new server pretty easily.
Migrating between servers only happens once every several years. I feel like managing an ansible config would just be an additional layer of complexity rather than making it easier. Their isn’t much configuration outside of docker in my case anyway.
I tend to grow my fleet of servers every couple months, and that requires me to once again setup everything from the beginning, settings, sshd, update debian if old version, new user for ssh, docker/podman, …
Quite literally added new vps to my fleet yesterday and spent 4 hourson setting all that up, when it could have been a simple ansible script.
Then yes, learning Ansible is a good way to have base OS settings for your systems. I love that it’s agentless - works over SSH.
The ugly part is that they keep updating it in a backwards incompatible way. In one version the paramerer is called “file” and in another it’s “dest”, they pull shit like this and don’t provide a tool to update playbooks automatically.
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.
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 :)
You will hate Ansible if you are coming from Nix. I went the other way and Nix is 1000x cleaner.
Being able to actually reverse changes is trivial in Nix, but can be a headache in Ansible. Not to mention the advantages of writing in an actual language and not yaml full of template hacks. I personally don’t see much future for tools like Ansible, there is considerable inertia working in its favor right now and it is absolutely true that it is widely used, but the future of configuration management is for sure more aligned with how Nix works.
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.
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).
Sorry, but I fear not. Ansible has a good getting started out there, but I think you’ll learn the most just using it.
Maybe a broad roadmap… Try to add systems. Test them via Ansible-Ping. Change some configs (add file, add line-in-file). Add handlers to react to changes by restarting services. Add host variables and customize behavior per host. Add templates…
Add comment