The Ultimate Guide to High Availability with MariaDB

Comparisons Between Automation Systems

You are viewing an old version of this article. View the current version here.

This page is meant to compare the automation systems that are covered by this section of the MariaDB KnowledgeBase. More information about these systems are presented in the relevant pages, and more systems may be added in the future.

Code Structure Differences

Different automation systems provide different ways to describe our infrastructure. Understanding how they work is the first step to evaluate them and choose one for our organisation.

Ansible Code Structure

Ansible code consists of the following components:

  • An inventory determines which hosts Ansible should be able to deploy. Each host may belong to one or more groups. Groups may have children, forming a hierarchy. This is useful because it allows us to deploy on a group, or to assign variables to a group.
  • A role describes the state that a host, or group of hosts, should reach after a deploy.
  • A play associates hosts or groups to their roles. Each role/group can have more than one role.
  • A role consists of a list of tasks. Despite its name a task is not necessarily something to do, but something that must exist in a certain state.
  • Tasks can use variables. They can affect how a task is executed (for example a variables could be a file name), or even wether a task is executed or not. Variables exist at role, group or host level. Variables can also be passed by the user when a play is applied.
  • Playbooks are the code that is used to define tasks and variables.
  • Facts are data that Ansible retrieves from remote hosts before deploying. This is a very important steps, because facts may determine which tasks are executed or how they are executed. Facts include, for example, the operating system family or its version.
  • Modules implement actions that tasks can use. Action examples are file (to declare that files and directories must exist) or mysql_variables (to declare MySQL/MariaDB variables that need to be set).

Example

Let's describe a hypothetical infrastructure to find out how these concepts can apply to MariaDB.

The inventory could define the following groups:

  • "db-main" for the cluster used by our website. All nodes belong to this group.
  • "db-analytics" for our replicas used by data analysts.
  • "dump" for one or more server that takes dumps from the replicas.
  • "proxysql" for one or more hosts that run ProxySQL.

Then we'll need the following nodes:

  • "mariadb-node" for the nodes in "db-main". This role describes how to setup nodes of a cluster using Galera.
  • "mariadb-replica" for the members of "db-analytics". It describes a running replica, and it includes the tasks that are necessary to provision the node if the data directory is empty when the playbook is applied. The hostname of the primary server is defined in a variable.
  • A "mariabackup" role to take backups with Mariabackup, running jobs during the night. We can associate this role to the "db-main" group, or we could create a child group for servers that will take the backups.
  • "mariadb-dump" for the server that takes dumps with mariadb-dump. Note that we may decide to take dumps on a replica, so the same host may belong to "db-analytics" and "mariadb-dump".
  • "proxysql" for the homonym group.

Puppet Code Structure

TO-DO

Architectural Differences

The architecture of the various systems is different. Their architectures determine how a deploy physically works, and what is needed to be able to deploy.

Ansible Architecture

Ansible architecture is simple. Ansible can run from any host, and can apply its playbooks on remote hosts. To do this, it runs commands via SSH. In practice, in most cases the commands will be run as superuser via sudo, though this is not always necessary.

Inventories can be dynamic. In this case, when we apply a playbook Ansible connects to remote services to discover hosts.

Ansible playbooks are applied via the ansible-playbook binary. Changes to playbooks are only applied when we perform this operation.

To recap, Ansible does not need to be installed on the server is administers. It needs an SSH access, and normally its user needs to be able to run sudo. It is also possible to configure a dynamic inventory, and a remote service to be used for this purpose.

Puppet Architecture

TO-DO

Content initially contributed by Vettabase Ltd.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.