A few weeks ago, I gave a presentation on Practical Database Administration with Ansible at PerconaLive ONLINE 2021.

I had some pretty good questions come out of that session. One of my favorites was “Why use Ansible over custom scripts?”

So today I answer that question by providing 3 reasons to use Ansible over custom scripts.

Why use Ansible over custom scripts?

During my presentation at PerconaLive 2021, one person asked a really great question.

The question was what is the greatest benefit of using Ansible over custom scripts?

I really liked this question because I’ve been there.

When I first started with Ansible, I had years of home-grown automation in the form of custom bash scripts to handle database tasks.

Any time a new task came up that needed to be solved, my first inclination was to create a new bash script.

I admit to preferring bash over Python, because it required less dependencies to be installed.

So I’ll answer the question by providing 3 reasons I now default to using Ansible when faced with automating a new database task.

I will present these reasons in reverse order, but they build on each other.

Reason 3: Common framework with minimal dependencies

The third reason I like Ansible over custom scripts is that Ansible provides a common framework for solving tasks.

I don’t have to duplicate code for creating functions for things like logging and error handling. Or couple my script to some other library that provides that capability.

And the playbooks I write for database tasks can sit nicely next to the plays other teams write for application scaling and other systems administration tasks.

Ansible has a really easy to understand configuration language using YAML. So its basically self- commenting.

Also, with Ansible, you don’t have to install a lot of dependencies to get it working. Just install ansible and the python library to connect to your database, and you should be good to go!

Reason 2: Flexibility to scale

The second reason to use Ansible over custom scripts is because it allows you to scale your automation with your environment.

Spinning up a new machine required copying my scripts over so they could be used to provision the database.

In my early years as a Database Administrator, I would often find different versions of a script on different machines. Keeping those in sync was a chore.

Ansible by default provides one location where the scripts are, and it works by pushing the tasks to the servers you are automating.

And if you find yourself with too many servers for a push-model to work on, there is an ansible-pull script to switch to a pull model. This will help remove any issues with scale.

And its all built-in. I don’t have to create the logic to do this.

So Ansible offers the flexibility needed to scale.

Reason 1: Community contribution of modules

And the number 1 reason I default to Ansible instead of custom scripts is the large library of available modules provided by Ansible and its community.

Modules in Ansible are basically Python functions that handle a specific task, like adding a database user.

These modules handle validation checks and provide error handling. So you avoid making unintended changes all without having to write your own functions.

And because Ansible is open-source, you can review what the module is doing. This also means there can be trust that it is well-tested by the community.

And if there is a task you want to accomplish that doesn’t have an existing module, you can always create your own and contribute it back to the Ansible community!

Conclusion

So if you are starting a new automation task for your database, I recommend you consider using Ansible over yet another custom script.

If it is your first venture into using Ansible, it will take some getting used to.

But the common framework, the ability to scale with flexibility, and the large library of community-provided modules makes Ansible the best choice for most of your database automation tasks.