Rôle Ansible pour Garage

Ce rôle Ansible installe et configure Garage, un service de stockage d'objets distribué open-source conçu pour l'auto-hébergement.

Il télécharge une version binaire de Garage, crée un utilisateur système, configure les répertoires de données et de métadonnées, génère un fichier de configuration, et enfin, installe un service systemd pour faire fonctionner Garage.

Actuellement, ce rôle ne connecte pas automatiquement les nœuds entre eux, mais c'est une fonctionnalité prévue.

Installation

Ce rôle est disponible sur Ansible Galaxy.

Configuration de base

La configuration minimale requise est :

• un modèle pour le fichier de configuration de Garage
• quatre variables : garage_version, garage_local_template, garage_metadata_dir, garage_data_dir

Voici un exemple de playbook :

- 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"

Vous devez également créer un fichier templates/garage.toml.j2 à la racine de votre répertoire Ansible avec le contenu suivant :

# Géré par 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 }}"

Dans cet exemple, nous utilisons l'adresse IPv4 principale de chaque nœud comme adresse RPC. Si vos nœuds sont derrière un NAT, vous devrez définir rpc_public_addr sur l'adresse IP publique de chaque nœud. Si vous construisez un cluster IPv6, vous pouvez utiliser {{ ansible_default_ipv6.address }}.

De plus, cet exemple utilise deux variables personnalisées : my_rpc_secret et my_admin_token. N'hésitez pas à utiliser des variables personnalisées pour toute entrée de configuration que vous souhaitez gérer.

Bien que la nécessité de fournir un modèle soit contraignante, cela offre beaucoup de flexibilité. Référez-vous à la documentation officielle pour configurer Garage selon vos besoins.

Référence des variables

Toutes les variables du rôle sont listées ci-dessous, suivies d'une brève description. Certaines de ces variables sont obligatoires. Pour toutes les autres variables, nous indiquons la valeur par défaut.

garage_version (obligatoire)

Version de Garage à télécharger et à utiliser, sans le v initial. Exemple : 0.8.0.

garage_local_template (obligatoire)

Chemin local vers un modèle pour le fichier de configuration de Garage. Lorsque vous utilisez un chemin relatif, consultez la documentation des chemins de recherche d'Ansible.

garage_metadata_dir (obligatoire)

Emplacement où les métadonnées seront stockées par Garage. Le rôle créera ce répertoire avec les permissions appropriées.

garage_data_dir (obligatoire)

Emplacement où les données réelles seront stockées par Garage. Le rôle créera ce répertoire avec les permissions appropriées.

garage_config_file: /etc/garage.toml

Emplacement du fichier de configuration à générer sur l'hôte cible.

garage_systemd_service: garage

Nom du service systemd. Utile si vous prévoyez d'exécuter plusieurs démons Garage sur le même hôte.

garage_binaries_dir: /usr/local/bin

Répertoire dans lequel stocker les binaires de Garage téléchargés. Chaque fichier dans ce répertoire sera nommé avec la version comme suffixe, par exemple /usr/local/bin/garage-0.8.0.

garage_main_binary: /usr/local/bin/garage

Chemin vers le binaire principal utilisé par le service systemd. Ce sera un lien symbolique vers la version demandée de Garage.

garage_system_user: garage

Nom de l'utilisateur système à créer. Garage sera exécuté en tant que cet utilisateur, et tous les fichiers (tanto les données que les métadonnées) appartiendront à cet utilisateur.

garage_system_group: garage

Nom du groupe système à créer.

garage_logging: netapp=info,garage=info

Configuration de journalisation pour Garage, fournie via RUST_LOG. Voir la documentation de env_logger pour des détails sur la syntaxe.

garage_architecture: {{ansible_architecture}}

Architecture CPU pour le binaire téléchargé. Elle doit être automatiquement définie sur l'architecture correcte de l'hôte cible, mais vous pouvez toujours la remplacer en cas d'erreur (par exemple, si vous souhaitez exécuter le binaire i686).

Configuration avancée : plusieurs démons Garage

Supposons que vous souhaitiez exécuter plusieurs démons Garage sur la même machine. Par exemple, vous pourriez avoir plusieurs clusters avec certains nœuds qui se chevauchent.

Voici un exemple d'inventaire Ansible :

[cluster1]
host1
host2
host3

[cluster2]
host1
host2
host3
host4
host5

Vous pouvez gérer cette situation avec le playbook suivant :

- hosts: cluster1
  roles:
    - garage
  vars:
    garage_version: "0.8.0"
    garage_local_template: "garage.toml.j2"
    garage_config_file: /etc/garage-cluster1.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

Il est sûr de partager la même garage_version et garage_local_template. Vous pouvez également partager le même utilisateur et le même groupe, selon votre modèle de menace.

Notez que si vous souhaitez utiliser le CLI de Garage, vous devrez exécuter quelque chose comme garage-cluster1 -c /etc/garage-cluster1.toml status. De même, pour redémarrer le service : systemctl restart garage-cluster1.

Mise à niveau d'un cluster

Tout d'abord, assurez-vous de lire attentivement la documentation officielle sur les mises à niveau.

Mises à niveau simples

Pour une "mise à niveau simple" et en toute sécurité :

• lisez les notes de version
• augmentez garage_version
• ajoutez serial: 1 à votre playbook (voir la documentation Ansible)
• exécutez ansible-playbook avec --step
• après que chaque hôte ait terminé sa mise à niveau, vérifiez que tout fonctionne comme prévu, et dites à Ansible de (c)ontinuer.

Mises à niveau avancées

Pour les mises à niveau entre versions incompatibles, la stratégie exacte dépend de la version : veuillez vous référer à la documentation officielle et au guide de migration spécifique.

Si vous avez besoin de télécharger la nouvelle version de Garage sans toucher à la configuration existante, vous pouvez exécuter la tâche "download" seule et forcer la version :

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

Vous devriez désormais avoir le nouveau binaire sur vos hôtes, accessible via son chemin complet (par exemple /usr/local/bin/garage-0.9.0). Cela vous permet d'exécuter des migrations hors ligne.