Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Why use Ansible for infrastructure as code?

04 Jun 2025 🔖 devops
💬 EN

Table of Contents

Q: Why use frameworks like Ansible for infrastructure as code (“IaC”) efforts? Why are there ever situations when people use it instead of just writing shell scripts like Bash or PowerShell?

Advantages over shell scripts

A: Here’s where VM OS shell scripting can potentially fall short as far as staff productivity, and where frameworks like Ansible get pretty Terraform-like (and indeed Terraform/OpenTofu arguably should simply be used where possible, but for certain operations within already-running VM operating systems, like creating OS users and granting them access to filesystem folders, or altering Java Virtual Machine memory allocation settings, that’s simply not what Terraform does):

  1. Auto-short-circuit/noop if running a given script wouldn’t actually change anything, and say so in the output report.  That kind of short-circuiting and reporting would have to be manually thought of when authoring a shell script.
  2. Offer rich, structured “whatif”-style reporting about exactly what system configurations & would/wouldn’t change if a given script were to be run.  Ditto after actually running it for real.  That level of detail and structure in reporting would have to be manually thought of when authoring a shell script.
  3. Handle common errors gracefully, in ways that would have to be manually thought of when authoring a shell script.
  4. Resume where things were left off if there was an error midway through a sequence of scripts.
  5. Parallel orchestration of execution of the scripts on multiple targets at a time.
  6. Perhaps some level of OS nuance abstraction in many of the modules?  (e.g. being able to just “create user” or “set user’s folder access to read only” without having to get into details about exactly what the shell command syntax is for that on the underlying OS)
  7. Readable semi-declarative scripting syntax, because of how much of the “batteries included” detail above the framework is handling.

Ansible advantages over its competitors

Ansible seems have an edge over similar frameworks like Chef/Puppet/etc. by many teams because:

  1. Word on the street is that its overhead of setup & its syntax are quick to learn & easy to get started trying.
  2. Target systems don’t need any special agents installed onto them to accept commands – just a Python runtime & the ability to SSH in.
    • This is also why vendor modules are also often written with Ansible – they can quickly do a demo against any target that’s just got SSH & Python.
  3. Big money = big community = big set of modules.

Or go fully declarative

That said … there are always containers when it comes to getting out of the prescriptive/imperative VM configuration business altogether!

But then you’re writing Helm instead of shell scripts or Ansible/Chef/Puppet, etc., so take that with a grain of salt.

Or shell script

And finally, there are a lot of small odd jobs where a shell script is a great idea. PowerShell 7, run in an Azure Automation Account runbook attached to a hybrid runbook worker, can do an awful lot of great stuff, and licensing is probably a heck of a lot cheaper than Ansible licensing.

Try it just for testing

A nice way to dip a toe in the water and see if Ansible feels like a headache or a helper might be to start out coding it only to validate whether or not your target systems are in the state you think they’re in.

You could write an Ansible codebase that doesn’t actually have any code in it that does things. 100% of your Ansible codebase could be unit test definitions.

  • Tip: As with all unit test authoring, don’t boil the ocean.

Just start with your next configuration upgrade/fix you end up needing to do on the target system. Write a handful of Ansible unit tests to validate that your manual fix worked, and then call it a day.

Here are some fix types to look out for, and the corresponding Ansible unit tests you might want to write so as to validate that you got the target system configured the way you hoped:

  1. JVM parameter tuning: Is the correct JVM flag present and set correctly in the JVM configuration?
  2. thread pool adjustment: Does the thread pool match what’s expected?
  3. application deployment: Does your .war file exist? Is the application in question running?
  4. service state: Is the service in question running / enabled?
  5. permission fix: Does the directory / file have the correct owner? Correct permissions?
  6. software version patch: Does the installed version number match the one that should now be installed?
--- ---