Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:adminsys:backup:garage [2023/11/04 19:09] – Création limaanto
+++ technique:adminsys:backup:garage [2023/11/04 19:45] – ajout principe garage limaanto
@@ Ligne 1: / Ligne 1: @@
 # Garage
-## Concepts et rappels
+[Garage](https://garagehq.deuxfleurs.fr) est un outil développé par [deuxfleurs](https://deuxfleurs.fr/) 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](https://garagehq.deuxfleurs.fr/documentation/quick-start/#generating-a-first-configuration-file). 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*
-TODO
 ## Implémentation à Picasoft
@@ Ligne 10: / Ligne 20: @@
 Il s'agit d'un simple service docker compose, décrit par [ce fichier](https://gitlab.utc.fr/picasoft/projets/services/garage/-/blob/main/docker-compose.yml). 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](https://wiki.rhizome-fai.net/bookstack/link/11#bkmrk-g1.garage.rhizome-fa).
+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%)
+```