Garage

Garage est un outil développé par deuxfleurs un camarade chaton français depuis quelques années. Il s’agit d’un système de stockage de données réparties permettant d’exposer une API S3 (de l’object storage, techno originalement par Amazon mais implémentée par plein d’autres acteurs depuis).

Le principe est simple. garage server démarre un nœud garage à l’aide d’un simple fichier de configuration. Ce nœud peut communiquer avec d’autres nœuds faisant partie du même cluster, dont l’organisation est décrite par un layout. Celui-ci indique pour chaque nœud du cluster

• son id (qui sera unique entre plusieurs exécutions)
• où il se trouve physiquement
• combien d’espace il expose (la capacité)
• comment y accéder

Lorsque des données sont ajoutées au cluster, garage duplique n fois la donnée (n configurable mais souvent 2 ou 3) puis cherche à répartir les n copies au travers des différents nœuds. Cela se fait proportionnellement à leur capacité annoncée en privilégiant les zones physiques différentes.

On peut ensuite interagir avec le stockage du cluster par l’intermédiaire de buckets S3

Garage est actuellement mis en place à Picasoft sur [pica02]. Cela présente l’avantage de stocker les données sur Bob, qui possède plus de disques durs et qui est physiquement séparé d’Alice et Caribou.

Il s’agit d’un simple service docker compose, décrit par ce fichier. Le service n’a rien de très original, si ce n’est qu’il ne passe pas par Traefik car le protocole utilisé par Garage (RPC) n’a pas l’air de supporter de passer par du HTTPS redirigé. Du moment qu’un autre service ne souhaite pas accéder au port 3901, ça ne devrait pas poser de problèmes pour autant.

Lors du premier lancement du service, notre nœud se connecte au cluster à l’aide de ses bootstrap_peers. Dans notre cas il s’agit du nœud g1.garage.rhizome-fait.net.

On peut alors faire un garage status pour vérifier que la connexion s’est bien faite, ce qui devrait ressembler à :

==== HEALTHY NODES ====
ID                Hostname  Address              Tags                   Zone               Capacity   DataAvail
xxxxxxxxxxxxxxxx  g1        xxx.xxx.xxx.xxx:xxxx [g1.rhizome]           rhz_dc             XXXXXX GB  XXXXXX GB (XXXX%)
... AUTRES NŒUDS ...
xxxxxxxxxxxxxxxx  pica02    xxx.xxx.xxx.xxx:xxxx NO ROLE ASSIGNED

La partie NO ROLE ASSIGNED est normale. Il faut auparavant ajouter notre nœud au layout.

Pour ce faire, on peut utiliser une commande tel que garage layout assign xxxxxxxxxxxxxxxx -z picasoft_toulouse -c 1T -t garage.picasoft.net où xxxxxxxxxxxxxxxx est l’ID de notre nœud tel qu’indiqué par la commande garage status. Après avoir vérifié que tout as l’air ok avec garage layout show, on peut confirmer le nouveau layout avec la commande garage layout apply --version XXX avec XXX le numéro de la nouvelle version (qui est à incrémenter à chaque fois, mais garage layout show devrait indiqué le chiffre à rentrer).

On devrait alors obtenir un status de la forme :

==== HEALTHY NODES ====
ID                Hostname  Address              Tags                   Zone               Capacity   DataAvail
xxxxxxxxxxxxxxxx  g1        xxx.xxx.xxx.xxx:xxxx [g1.rhizome]           rhz_dc             XXXXXX GB  XXXXXX GB (XXXX%)
... AUTRES NŒUDS ...
xxxxxxxxxxxxxxxx  pica02    xxx.xxx.xxx.xxx:xxxx [garage.picasoft.net]  picasoft_toulouse  1000.0 GB  XXXXXX GB (XXXX%)

Afin d’exposer notre cluster à restic, il faut d’abord créer un bucket et une clé associée à l’aide des commandes suivantes, tirées de la doc garage:

garage bucket create picasoft-backups
garage key create picasoft-backups-key
garage bucket allow --read --write --owner picasoft-backups --key picasoft-backups-key

Ce qui nous donne les informations nécessaires pour se connecter au bucket.