Of course! I wouldn't expect otherwise
Yes, ansible must be installed on at least the executing machine - it is agentless (requires python) if you are pushing it out to other machines.
I think for most users we can expect that it will be executed locally on a single machine in 98% of cases though, so ansible must be installed.
I did a bit of reading because this question has to have been asked many times before.
This quote from Reddit seemed to put it most succinctly, but assumes programming knowledge:
...BASH is imperative; Ansible is declarative.
In bash you tell your script each little thing that you need to do, you have to write your system information gathering functions, build your error handlers, parse your files etc etc.
In ansible, system information gathering is already included as part of the connection process and immediately available to you in variables eg you'll notice that I use the variable "{{ansible_env.SUDO_USER}}" to make sure I'm executing as the user not as root on occasion. There's no work to discover this
Similarly I can get all operating system parameters, distro, major/minor versions etc.
The value in Ansible is that system interaction is generally done through quite bulletproof "modules" - an interface built for interacting with a component or area of your system with ansible. For debian packages, there is the apt module - I say what state a certain package or list of packages should be in on the system (installed/absent/latest/specific version etc), and that is all covered in a succinct and easily read stanza - eg
- name: install supercollider packages
apt:
state: present
update_cache: yes
install_recommends: no
name: [ 'supercollider',
'sc3-plugins',
'sc3-plugins-language',
'sc3-plugins-server',
'zlib1g-dev' ]
But you could just write sudo apt-get install supercollider...etc
? Yes - but this stanza handles being re-run and monitors state (idempotency) - if these things are already installed, the step is skipped and I'm notified in the output. The idea is that you aim to run the playbook against a system any number of times and always wind up with the same state.
Similarly for templating files, startup.scd for example - I use the template module to push the file out, take a backup, and have a jinja stanza in my template definition to insert 0 or more samples folders if they're provided in the playbook chosen.
Does ansible assume devops knowledge? Not for a user - they can just run the command. If you are going to develop it, then you need at least some sysadmin knowledge and ansible will tend to encourage you down a devops path by design.
If you are not using the ansible modules, and have to resort to a significant number of shell commands then ansible loses some of it's value. I've had to do this with the cabal handling, and the superdirt installation in sclang - but for the rest of the tasks, ansible is doing a lot of the heavy lifting you've had to do manually in your script.
It's easily read, self-documenting, modular (I've built it so that if someone wants to take my small sections (roles) and include them in their own ansible setup they want) and well supported.
As a side note, I live in bash scripts most of my day (I maintain a custom in-house linux distro as part of my role at work), but even my head is starting to explode at the branching conditions I'd have to be considering when I look at what you're attempting with your bootstrap script.
In ansible, I'd just make modular os specific roles (and potentially os version specific tasks), based on conditionals pulled from the information gathering process ansible builds in - in my head, this moves from exploding, to mild irritation
Here's a tiny subset as an example of what the information gathering looks like - all of this can be referenced by variables in the tasks/playbooks:
"ansible_distribution": "Ubuntu",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "20",
"ansible_distribution_release": "focal",
"ansible_distribution_version": "20.04",
The entire set of info it pulls on a random laptop I've setup is here:
https://paste.ubuntu.com/p/YFyc7mGy2B/
Can it work on mac? Yes - I have no experience with it though - here's a relatively modern article:
Can it run on windows? Yes - I have some exposure through a shared SOE role I use at work for keeping our SOE in sync (eg browser versions across platforms). I believe it's far fiddlier to setup though, and far less complete than either of the above os'
So I don't know if this answers your question, I've got the benefit of a few years ansible experience under my belt (and my early experiments weren't very good), so I have a bias. But I do have a lot of experience bash scripting as well, so I can at least compare the two with some similar level of detailed knowledge.