Обзор Ansible для пользователей MariaDB

Ansible — это инструмент для автоматизации управления конфигурацией серверов. Он разработан компанией Red Hat и является открытым исходным кодом, выпущенным под лицензией GNU GPL.

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

Дополнительную информацию об установке Ansible см. в Руководстве по установке Ansible в документации Ansible.

Центры автоматизации

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

Red Hat предлагает коммерческую версию Ansible под названием Ansible Tower. Она состоит из REST API и веб-интерфейса, работающих в качестве центра, обрабатывающего все обычные операции Ansible.

Альтернативой является AWX. AWX — это проект с открытым исходным кодом, из которого первоначально разрабатываются многие функции Ansible Tower. AWX выпущен под лицензией Apache 2.0. Однако Red Hat не рекомендует использовать AWX в производственных средах.

Разработка AWX идет быстрыми темпами. У него есть несколько функций, которые могут или не могут попасть в Ansible Tower. Ansible Tower больше ориентирован на повышение надежности функций AWS, предоставляя стабильный инструмент для автоматизации производственных сред.

Принципы проектирования

Ansible позволяет нам создавать playbook'ы, описывающие, как должны быть настроены наши серверы. Playbook'ы — это списки задач.

Задачи обычно декларативные. Вы не объясняете как что-то сделать, а декларируете что должно быть выполнено.

Playbook'ы идемпотентны. При применении playbook'а задачи выполняются только при необходимости.

Вот пример задачи:

- name: Install Perl
  package:
    name: perl
    state: present

«Установить Perl» — это просто описание, которое будет отображаться на экране при применении задачи. Затем мы используем модуль package для объявления, что должен быть установлен пакет под названием «perl». При применении playbook'а, если Perl уже установлен, ничего не произойдет. В противном случае Ansible установит его.

При применении playbook'а последняя информация, отображаемая на экране, — это сводка, подобная следующей:

PLAY RECAP ***************************************************************************************************
mariadb-01        : ok=6    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Это означает, что шесть задач были уже применены (поэтому никаких действий не было), и две задачи были применены.

Как показывает приведенный выше пример, playbook'ы Ansible написаны на языке YAML.

Модули (например, package) могут быть написаны на любом языке, если они способны обрабатывать входной JSON и генерировать выходной JSON. Однако сообщество Ansible предпочитает писать их на языке Python, на котором написан и сам Ansible.

Концепции

Часть кода Ansible, которую можно применить к серверу, называется playbook.

Задача — это наименьший фрагмент кода в playbook'е. Однако это название немного вводит в заблуждение, потому что задачу Ansible не следует рассматривать как «действие». Вместо этого это минимальное описание компонента сервера. В примере выше мы видим задачу.

Задача использует один модуль, который является интерфейсом, используемым Ansible для взаимодействия со специфическим компонентом системы. В примере модуль — «package».

Задача также имеет атрибуты, описывающие, что должно быть сделано с этим модулем и как. В примере выше «name» и «state» — это атрибуты. Атрибут state существует для каждого модуля по соглашению (хотя могут быть исключения). Обычно он имеет по крайней мере состояние «present» и «absent» для указания, должен ли объект существовать или нет.

Другие важные концепции кода:

• Инвентаризация определяет, с какими хостами Ansible должен иметь возможность развертывания. Каждый хост может принадлежать одному или нескольким группам. Группы могут иметь дочерние группы, образуя иерархию. Это полезно, потому что позволяет развертывать на группе или назначать переменные группе.
• Роль описывает состояние хоста или группы хостов после развертывания.
• Игра связывает хосты или группы с их ролями. Каждая роль/группа может иметь более одной роли.
• Роль — это playbook, описывающий, как должны быть настроены определенные серверы на основе их логической роли в инфраструктуре. Серверы могут иметь несколько ролей, например, один и тот же сервер может иметь роль «mariadb» и «mydumper», что означает, что на нем запущен MariaDB и установлен mydumper (как показано позже).
• Задачи могут использовать переменные. Они могут повлиять на то, как выполняется задача (например, переменная может быть именем файла) или даже на то, выполняется ли задача. Переменные существуют на уровне роли, группы или хоста. Переменные также могут передаваться пользователем при применении игры.
• Факты — это данные, которые Ansible извлекает с удаленных хостов перед развертыванием. Это очень важный шаг, потому что факты могут определять, какие задачи выполняются или как они выполняются. Факты включают, например, семейство операционной системы или ее версию. Playbook рассматривает факты как предварительно заданные переменные.
• Модули реализуют действия, которые могут использовать задачи. Примеры действий — file (для объявления, что файлы и каталоги должны существовать) или mysql_variables (для объявления переменных MySQL/MariaDB, которые необходимо установить).

Пример

Давайте опишем гипотетическую инфраструктуру, чтобы понять, как эти концепции могут применяться к MariaDB.

Инвентаризация может определить следующие группы:

• «db-main» для кластера, используемого нашим веб-сайтом. Все узлы принадлежат этой группе.
• «db-analytics» для наших реплик, используемых аналитиками данных.
• «dump» для одного или нескольких серверов, которые берут дампы с реплик.
• «proxysql» для одного или нескольких хостов, на которых запущен ProxySQL.

Затем нам понадобятся следующие узлы:

• «mariadb-node» для узлов в «db-main». Эта роль описывает, как настроить узлы кластера с использованием Galera.
• «mariadb-replica» для членов «db-analytics». Она описывает работающую реплику и включает задачи, необходимые для подготовки узла, если каталог данных пуст при применении playbook'а. Имя хоста первичного сервера определено в переменной.
• «mariadb». Упомянутые выше «mariadb-node» и «mariadb-replica» могут быть дочерними элементами этой группы. У них много общего (файловая система для каталога данных, некоторые базовые настройки MariaDB, некоторые установленные инструменты...), поэтому имеет смысл избежать дублирования и описать общие черты в супер-роли.
• Роль «mariabackup» для создания резервных копий с помощью Mariabackup, выполняющая задачи ночью. Мы можем ассоциировать эту роль с группой «db-main», или можем создать дочернюю группу для серверов, которые будут создавать резервные копии.
• «mariadb-dump» для сервера, который создает дампы с помощью mariadb-dump. Обратите внимание, что мы можем решить создать дампы на реплике, поэтому один и тот же хост может принадлежать «db-analytics» и «mariadb-dump».
• «proxysql» для одноименной группы.

Архитектура

Архитектура Ansible очень проста. Ansible может работать на любом хосте. Для применения playbook'ов он подключается к целевым хостам и выполняет системные команды. По умолчанию подключение происходит через ssh, хотя можно разрабатывать плагины подключений для использования других методов. Применение playbook'ов локально без установления подключения также возможно.

Модули могут быть написаны на любом языке, но Python является наиболее распространенным выбором в сообществе Ansible. Модули получают JSON-«запросы» и факты из ядра Ansible, они должны выполнять полезные команды на целевом хосте, а затем возвращать информацию в формате JSON. Выходные данные информируют Ansible о том, изменилось ли что-то на удаленном сервере и были ли операции выполнены успешно.

Ansible не является централизованным. Он может работать на любом хосте, и для команды часто используется несколько ноутбуков. Однако для упрощения и повышения безопасности может быть желательно запустить его с выделенного хоста. Пользователи будут подключаться к этому хосту и применять Ansible playbook'ы.

Ресурсы и ссылки по Ansible

• Ansible.com
• AWX
• Ansible Tower
• Ansible Galaxy
• Ansible на Википедии
• Канал Ansible Automation Platform на YouTube
• Ansible: Начало работы
• Развертывание и управление MariaDB с помощью Ansible (видео)

Дополнительную информацию о концепциях, обсуждаемых на этой странице, можно найти в документации Ansible:

• Основные концепции.
• Словарь терминов.

Контент первоначально предоставлен компанией Vettabase Ltd.