Существующие модули и роли Ansible для MariaDB

На этой странице содержатся ссылки на модули и роли Ansible, которые можно использовать для автоматизации развертывания и настройки MariaDB. Список не претендует на полноту. Используйте его в качестве отправной точки, но затем, пожалуйста, проведите собственное исследование.

Модули

На момент написания этой статьи в Ansible Galaxy нет специфичных для MariaDB модулей. Можно использовать модули MySQL. Попытка использовать функции, специфичные для MySQL, может привести к ошибкам или непредсказуемому поведению. Однако то же самое относится и к попытке использовать функцию, не поддерживаемую используемой версией MySQL.

В настоящее время коллекция MySQL в Ansible Galaxy содержит, как минимум, следующие модули:

• mysql_db: управляет базами данных MySQL.
• mysql_info: собирает информацию о сервере MySQL.
• mysql_query: выполняет SQL-запросы к MySQL.
• mysql_replication: настраивает и управляет асинхронной репликацией.
• mysql_user: создаёт, изменяет и удаляет пользователей MySQL.
• mysql_variables: управляет конфигурацией MySQL.

Обратите внимание, что некоторые модули существуют только в виде сокращений, и можно использовать mysql_query вместо них. Однако важно отметить, что mysql_query не является идемпотентным. Ansible не понимает запросы MySQL, поэтому не может проверить, нужно ли выполнять запрос или нет.

Чтобы установить эту коллекцию локально:

ansible-galaxy collection install community.mysql

MariaDB Corporation поддерживает платформу ColumnStore на GitHub.

Другие полезные модули

Давайте рассмотрим другие модули, полезные для управления серверами MariaDB.

shell и command

Модули, такие как shell и command, позволяют запускать системные команды.

Для развертывания на Windows можно использовать win_shell и win_command.

В частности, можно использовать один из этих модулей для выполнения запросов MariaDB:

- name: Make the server read-only
  # become root to log into MariaDB with UNIX_SOCKET plugin
  become: yes
  shell: $( which mysql ) -e "SET GLOBAL read_only = 1;"

Основным недостатком этих модулей является то, что они не идемпотентны, поскольку предназначены для выполнения произвольных системных команд, которые Ansible не понимает. Они всё равно полезны в различных случаях:

• Для выполнения запросов, так как mysql_query также не является идемпотентным.
• В тех случаях, когда другие модули не позволяют использовать необходимые аргументы, мы можем достичь наших целей, написав собственные оболочки команд.
• Для выполнения пользовательских скриптов, реализующих нетривиальную логику. Реализация сложной логики в задачах Ansible возможна, но может быть сложной и неэффективной.
• Для вызова инструментов командной строки. Для некоторых наиболее распространённых инструментов могут быть определённые роли, но большинство раз чаще их использование является излишним усложнением.

copy и template

Важной частью управления конфигурацией является копирование файлов конфигурации на удалённые сервера.

Модуль copy позволяет копировать файлы на целевые узлы. Это удобно для статических файлов, которые мы хотим копировать точно так, как они есть. Пример задачи:

- name: Copy my.cnf
  copy:
    src: ./files/my.cnf.1
    dest: /etc/mysql/my.cnf

Как видите, локальное имя и имя на удалённом узле необязательно должны совпадать. Это удобно, так как упрощает использование разных файлов конфигурации с разными серверами. По умолчанию файлы для копирования находятся в подкаталоге files в роли.

Однако, как правило, содержимое файла конфигурации должно изменяться в зависимости от целевого узла, группы и различных переменных. Для этого можно использовать модуль template, который компилирует и копирует шаблоны, написанные на языке Jinja.

Простая задача шаблонирования:

- name: Compile and copy my.cnf
  copy:
    src: ./templates/my.cnf.j2
    dest: /etc/mysql/my.cnf

Снова, локальные и удалённые имена не обязательно должны совпадать. По умолчанию шаблоны Jinja находятся в подкаталоге templates в роли и, как правило, имеют расширение .j2. Это связано с тем, что Ansible использует Jinja версию 2 для шаблонирования на момент написания.

Простой пример шаблона:

## WARNING: DO NOT EDIT THIS FILE MANUALLY !!
## IF YOU DO, THIS FILE WILL BE OVERWRITTEN BY ANSIBLE

[mysqld]
innodb_buffer_pool_size = {{ innodb_buffer_pool_size }}

{% if use_connect sameas true %}
connect_work_size = {{ connect_work_size }}
{% endif %}

Другие распространённые модули

Следующие модули также часто используются для серверов баз данных:

• package, apt или yum. Модуль package не зависит от менеджера пакетов. Используйте их для установки, удаления и обновления пакетов.
• user, полезен для создания системного пользователя и группы, которые запускают бинарный файл MariaDB.
• file может использоваться для обеспечения существования и правильных разрешений каталогов MariaDB (таких как каталог данных). Его также можно использовать для загрузки статических файлов.
• template позволяет создавать файлы конфигурации (например, my.cnf) более динамично, используя язык шаблонов Jinja.
• service полезен после установки MariaDB как службы, для запуска, перезапуска или остановки её.

Роли

В Ansible Galaxy существуют отдельные роли для MariaDB. Их использование для MariaDB предпочтительнее, чтобы избежать несовместимостей и, возможно, использовать некоторые специфичные для MariaDB функции. Однако использование ролей MySQL или Percona Server тоже возможно. Это, вероятно, имеет смысл для пользователей, которые также администрируют экземпляры MySQL и Percona Server.

Чтобы найти подходящие роли, проверьте страницу поиска Ansible Galaxy. Большинство ролей также доступны на GitHub.

Вы также можете искать роли с помощью инструмента ansible-galaxy:

ansible-galaxy search mariadb

См. также

• Развертывание и администрирование MariaDB с помощью Ansible (видео)

Содержание первоначально предоставлено Vettabase Ltd.