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
Implémentation à Picasoft
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.
Création du Layout
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%)
Création des buckets
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.