you could use shell scripts, but that might get very complex very quick, thats where ansible comes in. you make a playbook with the tasks to get a server from vanilla OS to how you want it.

tasks can do anything from install a package (with yum or apt or dnf) to uploading files and everything else you might need, the docs are quite good and have good examples.

As a user for about 9 years, both homelab and work. It can be overwhelming at first, but then you start to see why its used so much.

ansible can seem like just a fancy way to run shell scripts with extra syntax, but the real power shows up when you start managing more than one machine or need repeatable, "idempotent" (i love this word) setups. ansible handles state rather than just running commands, so you can describe what you want instead of how to do it step by step. it's also easier to maintain over time, especially if your setup grows or changes. just add that new vm to the inventory list.

if you're already comfortable with shell scripts and just want to get a few vms going, you could totally get by without ansible. but if you're planning to do this more than once, or want to be able to rebuild things cleanly, it's worth it, imo. it could save you a lot of headaches later on.

i use it at work, i manage about 40 vms in our pre-production environment with ansible. if i need to install a new package on all, it's one line and one command (ran in a pipeline). if i need to change the settings for unattended-upgrades on the debian machines only, same thing.

however, our "production" environment is k8s and a handful of external services, and we use terraform to manage all that.

i guess it all depends on your needs.

Ansible is an abstraction layer over system utilities, shell, and other programs. You can specify what you want to happen, and it will figure out how to do it. For example, you can use the ansible.builtin.package module to specify which packages you want to be present, and Ansible will decide which specific package manager module should handle it and how.

Ansible tasks are also idempotent -- they are concerned with the end state instead of the action. Many of the modules (like the package module above) take a state parameter with the possible values of present or absent (instead of the more common "install" and "remove" actions). If the system's state satisfies the task's expected end state (e.g. the package is already present), the task will be skipped -- unlike a shell script, which would simply re-run the entire script every time.

Ansible also implements strict error checking. If a task fails, it won't run any subsequent tasks on the host since the end states would be unpredictable.

Great summary “a lot of common error checking has gone into it. It can be told what you want without specifics that would only potentially be applicable to 1 system type.”

A built-in idempotence

ansible has a learning curve but will save you a lot of time in long run over bash.

write playbooks rhat target groups of similar hosts instead of a playbook for each distinct host, target specific hosts with -l flag of ansible-playbook.

look into molecule for testing sooner than later. helps you be more confident your plays will work as expected vs running trial and error on a host and getting it into a bad state. i run on bare metal so more important for my workflow not to wipe a folder with a typo, etc.

Depends. How many VMs do you have?