Роль Ansible для Garage

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

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

В настоящее время эта роль не соединяет узлы автоматически, но это функция, которая планируется в будущем.

Установка

Эта роль доступна на Ansible Galaxy

Основная настройка

Минимальная необходимая конфигурация включает:

• шаблон для конфигурационного файла Garage
• четыре переменные: garage_version, garage_local_template, garage_metadata_dir, garage_data_dir

Вот пример плейбука:

- hosts: mycluster
  roles:
    - garage
  vars:
    garage_version: "0.8.0"
    garage_local_template: "garage.toml.j2"
    garage_metadata_dir: "/var/lib/garage"
    garage_data_dir: "/mnt/data"
    my_rpc_secret: "130458bfce56b518db49e5f72029070b5e0fcbe514052c108036d361a087643f"
    my_admin_token: "7b3e91b552089363ab94eb95f62324fb4138c9a6d71a69daefae0c5047b33bb7"

Также нужно создать файл templates/garage.toml.j2 в корневом каталоге вашей директории Ansible со следующим содержимым:

# Сгенерировано Ansible

metadata_dir = "{{ garage_metadata_dir }}"
data_dir = "{{ garage_data_dir }}"
db_engine = "lmdb"

replication_mode = "3"
block_size = 1048576
compression_level = 1

rpc_bind_addr = "{{ ansible_default_ipv4.address }}:3901"
rpc_public_addr = "{{ ansible_default_ipv4.address }}:3901"
rpc_secret = "{{ my_rpc_secret }}"

bootstrap_peers = []

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
root_domain = ".s3.garage.localhost"

[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.garage.localhost"
index = "index.html"

[admin]
api_bind_addr = "[::1]:3903"
admin_token = "{{ my_admin_token }}"

В этом примере мы используем основной IPv4 адрес каждого узла в качестве адреса RPC. Если ваши узлы находятся за NAT, вам нужно установить rpc_public_addr на публичный IP-адрес каждого узла. Если вы создаете кластер IPv6, вы можете использовать {{ ansible_default_ipv6.address }}.

Кроме того, в этом примере используются две пользовательские переменные: my_rpc_secret и my_admin_token. Не стесняйтесь использовать пользовательские переменные для любого элемента конфигурации, который вы хотите управлять.

Предоставление шаблона — это утомительно, но оно дает много возможностей. Обратитесь к официальной документации для настройки Garage в соответствии с вашими требованиями.

Справочник по переменным

Все переменные роли перечислены ниже с коротким описанием. Некоторые из этих переменных обязательны. Для всех остальных переменных мы указываем значение по умолчанию.

garage_version (обязательно)

Версия Garage для загрузки и использования, без начального v. Пример: 0.8.0.

garage_local_template (обязательно)

Локальный путь к шаблону для конфигурационного файла Garage. При использовании относительного пути, смотрите документацию по путям поиска Ansible.

garage_metadata_dir (обязательно)

Где будут храниться метаданные Garage. Роль создаст эту директорию с соответствующими правами.

garage_data_dir (обязательно)

Где будут храниться фактические данные Garage. Роль создаст эту директорию с соответствующими правами.

garage_config_file: /etc/garage.toml

Место расположения конфигурационного файла, который будет сгенерирован на целевом узле.

garage_systemd_service: garage

Название сервиса systemd. Полезно, если вы планируете запускать несколько демонов Garage на одном и том же хосте.

garage_binaries_dir: /usr/local/bin

Директория для хранения загруженных бинарных файлов Garage. Каждый файл в этой директории будет называться с суффиксом версии, например, /usr/local/bin/garage-0.8.0.

garage_main_binary: /usr/local/bin/garage

Путь к основному бинарному файлу, используемому сервисом systemd. Это будет символическая ссылка на запрашиваемую версию Garage.

garage_system_user: garage

Имя системного пользователя, которого нужно создать. Garage будет работать от имени этого пользователя, и все файлы (как данные, так и метаданные) будут принадлежать этому пользователю.

garage_system_group: garage

Имя системной группы, которую нужно создать.

garage_logging: netapp=info,garage=info

Конфигурация ведения журнала для Garage, предоставленная через RUST_LOG. Смотрите документацию env_logger для получения информации о синтаксисе.

garage_architecture: {{ansible_architecture}}

Архитектура CPU для загружаемого бинарника. Она будет установлена автоматически в соответствии с архитектурой целевого узла, но вы все равно можете переопределить ее, если она неправильная (например, если хотите запустить бинарник i686).

Расширенная настройка: несколько демонов Garage

Предположим, вы хотите запустить несколько демонов Garage на одной машине. Например, у вас может быть несколько кластеров с некоторыми общими узлами.

Вот пример инвентаря Ansible:

[cluster1]
host1
host2
host3

[cluster2]
host1
host2
host3
host4
host5

Вы можете управлять этой ситуацией с помощью следующего плейбука:

- hosts: cluster1
  roles:
    - garage
  vars:
    garage_version: "0.8.0"
    garage_local_template: "garage.toml.j2"
    garage_config_file: /etc/garage-cluster2.toml
    garage_metadata_dir: "/var/lib/garage/cluster1"
    garage_data_dir: "/mnt/data/cluster1"
    garage_systemd_service: garage-cluster1
    garage_main_binary: /usr/local/bin/garage-cluster1
    garage_system_user: garage-cluster1
    garage_system_group: garage-cluster1

- hosts: cluster2
  roles:
    - garage
  vars:
    garage_version: "0.8.1"
    garage_local_template: "garage.toml.j2"
    garage_metadata_dir: "/var/lib/garage/cluster2"
    garage_data_dir: "/mnt/data/cluster2"
    garage_config_file: /etc/garage-cluster2.toml
    garage_systemd_service: garage-cluster2
    garage_main_binary: /usr/local/bin/garage-cluster2
    garage_system_user: garage-cluster1
    garage_system_group: garage-cluster1

Безопасно использовать одну и ту же garage_version и garage_local_template. Вы также можете использовать одного и того же пользователя и группу, в зависимости от вашей модели угроз.

Обратите внимание, что если вы хотите использовать CLI Garage, вам нужно будет выполнить что-то вроде garage-cluster1 -c /etc/garage-cluster1.toml status. Аналогично, чтобы перезапустить сервис: systemctl restart garage-cluster1.

Обновление кластера

Сначала убедитесь, что вы внимательно прочитали официальную документацию по обновлению

Простые обновления

Для безопасного "простого обновления":

• прочитайте заметки о релизе
• увеличьте garage_version
• добавьте serial: 1 в ваш плейбук (см. документацию Ansible)
• запустите ansible-playbook с --step
• после завершения обновления каждого узла проверьте, что все работает как ожидается, и укажите Ansible продолжить ((c)ontinue)

Расширенные обновления

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

Если вам нужно загрузить новую версию Garage, не касаясь существующей настройки, вы можете запустить задачу "download" в одиночку и принудительно указать версию:

ansible-playbook garage.yaml -e garage_version=0.9.0 --tags download

Теперь у вас должен быть новый бинарный файл на ваших узлах, доступный по его полному пути (например, /usr/local/bin/garage-0.9.0). Это позволит вам выполнять офлайн-миграции.