Ansible-Rolle für Garage

Diese Ansible-Rolle installiert und konfiguriert Garage, einen Open-Source, verteilten Objektspeicherdienst, der für das Selbsthosten geeignet ist.

Sie lädt eine binäre Version von Garage herunter, erstellt einen Systembenutzer, richtet Daten- und Metadatenverzeichnisse ein, generiert eine Konfigurationsdatei und installiert schließlich einen Systemd-Dienst, um Garage auszuführen.

Derzeit verbindet diese Rolle die Knoten nicht automatisch miteinander, aber das ist eine geplante Funktion.

Installation

Diese Rolle ist auf Ansible Galaxy verfügbar.

Grundkonfiguration

Die minimal erforderliche Konfiguration ist:

• eine Vorlage für die Konfigurationsdatei von Garage
• vier Variablen: garage_version, garage_local_template, garage_metadata_dir, garage_data_dir

Hier ein Beispiel-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"

Sie müssen auch eine Datei templates/garage.toml.j2 im Wurzelverzeichnis Ihres Ansible-Verzeichnisses mit folgendem Inhalt erstellen:

# Verwaltet von 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 }}"

In diesem Beispiel verwenden wir die Haupt-IP-Adresse (IPv4) jedes Knotens als RPC-Adresse. Wenn Ihre Knoten hinter einem NAT stehen, müssen Sie rpc_public_addr auf die öffentliche IP-Adresse jedes Knotens setzen. Wenn Sie ein IPv6-Cluster aufbauen, könnten Sie {{ ansible_default_ipv6.address }} verwenden.

Außerdem verwendet dieses Beispiel zwei benutzerdefinierte Variablen: my_rpc_secret und my_admin_token. Fühlen Sie sich frei, benutzerdefinierte Variablen für jede Konfigurationseintragung zu verwenden, die Sie verwalten möchten.

Es ist umständlich, eine Vorlage bereitzustellen, aber es bietet viel Flexibilität. Siehe die offizielle Dokumentation, um Garage nach Ihren Anforderungen zu konfigurieren.

Variablenreferenz

Alle Variablen der Rolle sind nachfolgend aufgeführt, gefolgt von einer kurzen Beschreibung. Einige dieser Variablen sind obligatorisch. Für alle anderen Variablen geben wir den Standardwert an.

• garage_version (obligatorisch): Version von Garage, die heruntergeladen und verwendet werden soll, ohne das anfängliche v. Beispiel: 0.8.0.

• garage_local_template (obligatorisch): Lokaler Pfad zur Vorlage für die Konfigurationsdatei von Garage. Bei der Verwendung eines relativen Pfades siehe Ansible-Suchpfad-Dokumentation.

• garage_metadata_dir (obligatorisch): Wo die Metadaten von Garage gespeichert werden. Die Rolle wird dieses Verzeichnis mit den entsprechenden Berechtigungen erstellen.

• garage_data_dir (obligatorisch): Wo die tatsächlichen Daten von Garage gespeichert werden. Die Rolle wird dieses Verzeichnis mit den entsprechenden Berechtigungen erstellen.

• garage_config_file: /etc/garage.toml: Speicherort der zu generierenden Konfigurationsdatei auf dem Zielhost.

• garage_systemd_service: garage: Name des systemd-Dienstes. Nützlich, wenn Sie mehrere Garage-Daemons auf demselben Host ausführen möchten.

• garage_binaries_dir: /usr/local/bin: Verzeichnis, in dem die heruntergeladenen Garage-Binaries gespeichert werden. Jede Datei in diesem Verzeichnis wird mit der Version als Suffix benannt, z.B. /usr/local/bin/garage-0.8.0.

• garage_main_binary: /usr/local/bin/garage: Pfad zur Hauptbinary, die vom systemd-Dienst verwendet wird. Dies wird ein Symlink zur angeforderten Version von Garage sein.

• garage_system_user: garage: Name des zu erstellenden Systembenutzers. Garage wird unter diesem Benutzer ausgeführt, und alle Dateien (sowohl Daten als auch Metadaten) gehören diesem Benutzer.

• garage_system_group: garage: Name der zu erstellenden Systemgruppe.

• garage_logging: netapp=info,garage=info: Logging-Konfiguration für Garage, bereitgestellt über RUST_LOG. Siehe env_logger-Dokumentation für Details zur Syntax.

• garage_architecture: {{ansible_architecture}}: CPU-Architektur für die heruntergeladene Binary. Sie sollte automatisch auf die richtige Architektur des Zielhosts gesetzt werden, aber Sie können dies überschreiben, falls es falsch ist (z.B. wenn Sie die i686-Binary ausführen möchten).

Erweiterte Einrichtung: mehrere Garage-Daemons

Angenommen, Sie möchten mehrere Garage-Daemons auf demselben Computer ausführen. Zum Beispiel könnten Sie mehrere Cluster mit einigen überlappenden Knoten haben.

Hier ein Beispiel für ein Ansible-Inventar:

[cluster1]
host1
host2
host3

[cluster2]
host1
host2
host3
host4
host5

Sie können diese Situation mit folgendem Playbook verwalten:

- 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

Es ist sicher, dieselbe garage_version und garage_local_template zu teilen. Je nach Bedrohungsmodell können Sie auch denselben Benutzer und dieselbe Gruppe teilen.

Bitte beachten Sie, dass, wenn Sie die Garage-CLI verwenden möchten, Sie etwas wie garage-cluster1 -c /etc/garage-cluster1.toml status eingeben müssten. Um den Dienst neu zu starten, verwenden Sie: systemctl restart garage-cluster1.

Upgrade eines Clusters

Stellen Sie zuerst sicher, dass Sie die offizielle Upgrade-Dokumentation sorgfältig gelesen haben.

Einfache Upgrades

Für ein sicheres "einfaches Upgrade":

• Lesen Sie die Versionshinweise.
• Erhöhen Sie garage_version.
• Fügen Sie serial: 1 zu Ihrem Playbook hinzu (siehe Ansible-Dokumentation).
• Führen Sie ansible-playbook mit --step aus.
• Nachdem jeder Host mit dem Upgrade fertig ist, überprüfen Sie, dass alles wie erwartet funktioniert, und sagen Sie Ansible, es soll (c)ontinue.

Erweiterte Upgrades

Für Upgrades zwischen inkonsistenten Versionen hängt die genaue Strategie von der Version ab: Bitte beziehen Sie sich auf die offizielle Dokumentation und spezifische Migrationsanleitungen.

Wenn Sie die neue Version von Garage herunterladen müssen, ohne die bestehende Einrichtung zu berühren, können Sie die "download"-Aufgabe alleine ausführen und die Version erzwingen:

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

Sie sollten jetzt die neue Binary auf Ihren Hosts haben, die über ihren vollen Pfad (z.B. /usr/local/bin/garage-0.9.0) zugänglich ist. Dies ermöglicht es Ihnen, Offline-Migrationen durchzuführen.