4 ms·
I agree: bash scripts should always be the first step what people should try. Usually, the build.sh finds its way into a project to structurally build the syste
by milanaleksic 5y ago
I agree: bash scripts should always be the first step what people should try. Usually, the build.sh finds its way into a project to structurally build the system on the pipeline, or a cron running shell to delete some temporary files and so on.
But, it simply doesn't work if you have more than one server. Each one becomes a so called "snowflake", with diverging configuration, installed packages and so on.
A book I really liked is "UNIX&Linux System Administration Handbook" which explains exactly this evolution in thinking that most people need to go through at some point if they want to automate things.
Ansible is not the only approach: I can see a lot of other things popping up in recent years:
- Nix is really cool
- Salt is an alternative for Ansible (but I didn't get it, although one of my former employers moved from Puppet to Salt so it's probably a really good thing for complex setup)
- Terraform/Packer (if everything is on VMs or in the cloud)
- K8s (ubiquitous, omni-potent, but I had enough of it tbh: I need to learn each year new tools and good practices and frameworks are changing constantly, it's like "frontend frameworks of infra" ;))
- tkiolp4 5y agoIn general I agree, first try bash scripts and then, if needed, something like Ansible. More often than not, though, the bash scripts I produce are buggy, non-idempotent, and really difficult to maintain. One could argue “know your tools!”, and while I agree with the sentiment, somehow for me at least, it’s way easier to write maintainable, less buggy, and idempotent Ansible plays than to do the same with bash.
- phillu 5y agoYou are not the only one. Anecdotal, but I have seen far more unmaintainable, half-assed, 1000-line build.sh scripts than Ansible scripts.