Ansible provides a self-documenting way of deploying both the software and database content—coupled with a tool such as AWX, it ensures you have an audit trail of who made what changes and when.
Create the configuration file as a template and deploy it using the template across all servers. Where configurations are split across multiple files, either ensure that all files are managed by Ansible or remove the include statement from the files to ensure parameters cannot be accidentally overridden.
Ansible performs all its operations on the database machine using SSH—hence, there is no need to open your database server to the network to manage it.
You would use the shell module when the native module you need cannot perform the operation you require. For example, older versions of Ansible could do most things on PostgreSQL, but couldn't perform a full vacuum. This has now been rectified but serves as an example - the shell module is your solution when you either do not have a native Ansible module that addresses your requirements, or where one exists but the task you are performing is outside its capabilities.
Ansible, especially when coupled with AWX, provides an audit trail and ensures that you can track what operations were performed and when. You can also schedule routine operations in AWX.
You would create a role or playbook and use the shell module to call one of the native PostgreSQL backup tools such as pg_basebackup or pg_dump.
mysql_user.
PostgreSQL has more native modules supporting it in Ansible than any other database platform.
