What's the real difference between a shell script and Ansible (and which should I use)?

Submitted ⁨⁨9⁩ ⁨months⁩ ago⁩ by ⁨hackysphere@lemmy.ca⁩ to ⁨selfhosted@lemmy.world⁩

I am wanting to finally make my VMs be able to be replicated “from scratch”. I have heard about using Ansible to do configuration, but it seems to me that it’s the same as a shell script, but with more (maybe unnecessary) details for each step. Is there something that I’m missing about Ansible, and should I take the time to learn it for use myself?

source

Comments

Sort:hotnew top

runiq@feddit.org ⁨9⁩ ⁨months⁩ ago
Depends. How many VMs do you have?

source
suswrkr@discuss.tchncs.de ⁨9⁩ ⁨months⁩ ago
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.

source
oji@lemmy.world ⁨9⁩ ⁨months⁩ ago
A built-in idempotence

source
rtxn@lemmy.world ⁨9⁩ ⁨months⁩ ago
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.

source
- ChapulinColorado@lemmy.world ⁨9⁩ ⁨months⁩ ago
  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.”
  
  source
beerclue@lemmy.world ⁨9⁩ ⁨months⁩ ago
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.

source