Merci beaucoup pour cette information!
1 « J'aime »
Et pour ceux que ça intéresse, un début de packaging yunohost est disponible ici : tobias/garage_ynh - garage_ynh - Gitea
4 « J'aime »
Est-ce que ce ne serait pas intéressant de prévoir aussi un atelier lors du camp CHATONS pour les personnes présentes ? si oui, merci de l’ajouter sur camp-chatons-2022 - Libreto
Oui, carrément. Je l’ai ajouté sur le libreto.
Et donc je me réveille un peu tard sur ce sujet qui m’intéresse beaucoup.
Je peux dédier à l’expérimentation 4 VM avec chacune une partition de 256Go en SSD, hébergées localement sur 4 machines physiques distinctes, derrière une connexion Fibre.
Et on doit aussi pouvoir allouer une petite VM ou deux sur notre deuxième infra qui est chez Hetzner en Finlande. Il y a quelques To (en HDD) non encore utilisés sur les deux serveurs que nous avons là bas.
1 « J'aime »
Je vais tenter de participer à la réunion du 16 Août à 13h. Je devrais être disponible ce jour là.
1 « J'aime »
Super ta synthèse @oiseauroch
En la lisant, voilà quelques points qui me sont venus à l’esprit.
# LE PORT DOIT ÊTRE LE MÊME SUR TOUS LES NOEUDS (port interne)
rpc_bind_addr = "[::]:__PORT__"
Non pas forcément ! Par exemple on a un script de test pour spawn un cluster de 3 noeuds sur la meme machine sans container, on a alors 3 instances de Garage sur localhost sur :3900, :3901 et :3902.
https://git.deuxfleurs.fr/Deuxfleurs/garage/src/branch/main/script/dev-cluster.sh#L24-L50
Il faut par contre bien préciser le port quand tu fais un connect plus tard, et faire correspondre avec ce que tu annonces sur rpc_public_addr.
bootstrap_peers = [
__SERVER_AMI__",
]
Pour info, garage a 3 mécanismes de découvertes : soit avec bootstrap_peers directement dans le fichier de conf, soit avec la commande garage connect, soit avec un outil de service discovery comme Consul ou celui de Kubernetes. Un seul à la fois est nécessaire, ils devraient en théorie se combiner sans peine. Passer la première connexion, Garage garde en mémoire de toute manières les paires qu’il connait.
# Pas sûr de la commande : montre l'ID de la clé et son secret,
# nécessaire pour lire/écrire dans le stockage via le protocole S3
garage key info <key_name>
Si c’est bon, la commande est correcte !
Autoriser
rpc_public_addrà faire référence à un nom de domaine et pas seulement un IP : utile pour DynDNS, box nomade et autres…
C’est vrai qu’on pourrait accepter des NDD dans rpc_public_addr et bootstrap_peers.
J’ai créé un ticket ici pour tracker l’idée : https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/353
Ceci dit, en l’état tu peux quand même faire fonctionner un cluster Garage avec des IP dynamiques. La technique ? Tu ne mets pas de rpc_public_addr, tu laisses bootstrap_peers vide également. Tu fais les garage connect une première fois à la main, et tant que tous tes noeuds ne changent pas d’IP en même temps c’est bon. En effet, si tu as des noeuds A, B et C de connecté et que C change d’IP, il va réessayer de se connecter à A par exemple, qui va apprendre sa nouvelle IP et la partager avec le reste du cluster, B ici. Nouvelle IP qui sera persistée dans les données internes de tous les membres du cluster. Plus tard, A et B pourront changer d’IP tant que C n’en change pas, C sera alors le nouveau point de RDV, etc.
Rendre optionnel
s3_web
Je ne m’étais pas rendu compte que s3_web était obligatoire.
J’ai créé un ticket pour tracker le sujet également : https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/354
Aussi suite à notre première réunion où on se disait que ce serait bien d’avoir un cluster démonstrateur pour le camps CHATONS, j’ai mis en place un noeud Garage v0.7.2.1 en IPv6 avec Caddy en frontal qui n’attend que de se connecter à d’autres personnes, le noeud sera un peu lent par contre car derrière une connexion 4G - je n’ai que ça pour le moment mais ça devrait suffire.
Voilà le fichier /etc/garage.toml :
metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
replication_mode = "3"
rpc_bind_addr = "[::]:3901"
rpc_public_addr = "[2a06:a004:304c::2]:3901"
rpc_secret = "<redacted>"
bootstrap_peers = []
[s3_api]
s3_region = "garage"
api_bind_addr = "[::1]:3900"
root_domain = ".s3.bckp.chatons.deuxfleurs.fr"
[s3_web]
bind_addr = "[::1]:3902"
root_domain = ".web.bckp.chatons.deuxfleurs.fr"
index = "index.html"
[admin]
api_bind_addr = "[::1]:3903"
metrics_token = "<redacted>"
admin_token = "<redacted>"
Et le fichier /etc/caddy/Caddyfile :
s3.bckp.chatons.deuxfleurs.fr, *.s3.bckp.chatons.deuxfleurs.fr {
reverse_proxy localhost:3900
}
*.web.bckp.chatons.deuxfleurs.fr {
reverse_proxy localhost:3902
}
admin.bckp.chatons.deuxfleurs.fr {
reverse_proxy localhost:3903
}
Pour la configuration du layout, je suis parti sur le poids = 10x le nombre de Go alloué. Avec 200Go, j’ai donc mis 20 :
==== HEALTHY NODES ====
ID Hostname Address Tags Zone Capacity
92ccd4e54071cb3d debian [2a06:a004:304c::2]:3901 (pending)
==== STAGED ROLE CHANGES ====
ID Tags Zone Capacity
92ccd4e54071cb3d lte,slow rennes 20
Please use `garage layout show` to check the proposed new layout and apply it.
Je peux vous envoyer le node id et le rpc_secret par message privé, signalez-vous simplement par MP. Si vous n’avez jamais déployé garage et que vous souhaitez vous lancer, on peut discuter de faire ça ensemble en MP, voire si on est beaucoup, se planifier un moment.
Je propose de transférer ce repo dans l’orga YunoHost-Apps et de donner les droits de maintenance à qui en a besoin. Les apps qui se trouvent dans YunoHost-Apps font plus facilement l’objet de révision par ericg, yalh ou titus…
Je propose de transférer ce repo dans l’orga YunoHost-Apps et de donner les droits de maintenance à qui en a besoin. Les apps qui se trouvent dans YunoHost-Apps font plus facilement l’objet de révision par ericg, yalh ou titus…
Je comptais le faire une fois le repo à peu près fonctionnel.
Comme tu veux 
En tout cas c’est cool ce paquet.
De mon côté j’ai pu faire quelques tests ces derniers jours, j’ai ouvert un cluster entre 3 machines avec des config différentes:
- un serveur dédié Debian 11 temporairement loué pour l’occasion (Hetzner, Finlande), garage géré par docker
- un LXC Debian 11 sur mon infra clawd.fr (Hetzner Allemagne), derrière un NAT+reverse proxy, garage géré par systemd
- un serveur dédié Debian 10 (Hetzner Allemagne) privé et hors-chatons dont je suis le seul admin, garage géré par systemd
J’ai pris des notes sur tout le process et j’ai rencontré quelques pépins mineurs (1) mais là j’en suis à tenter d’utiliser restic dessus, sans succès pour l’instant. Je partagerai mes notes quand j’aurai eu le temps d’en retirer les quelques info sensibles qu’elles contiennent, ou par MP si quelqu’un les veut avant.
Si quelqu’un veut un accès à ce cluster je partage volontiers, même si je suis pas certain à l’heure actuelle qu’il fonctionne correctement puisque j’ai encore rien réussi à y stocker (j’ai pas encore beaucoup essayé pour être honnête).
(1) d’ailleurs @quentin j’en profite pour signaler ce qui me semble être une petite coquille dans les tutos:
j’ai suivi ce tuto https://garagehq.deuxfleurs.fr/documentation/cookbook/real-world/ ; dans la commande docker run d’exemple, le nom du repo ne correspond pas à celui donné plus haut dans l’article: lxpz/garage_amd64 au lieu de dxflrs/amd64_garage
En suivant les tutos, je n’ai pas compris qu’on pouvait « définir » la valeur de ce poids, et dans les tutos on parle de 100Go par unité, est-ce qu’il y a plus d’info là dessus quelque part?
Étant donné que mon cluster a l’air de fonctionner mais que je ne parviens pas à utiliser restic dessus, je veux bien un accès pour voir si j’aurais le même message d’erreur sur le tiens.
On devrait peut-être lancer une conversation privée pour ne pas saturer ce thread, ou bien peut-être négocier une section privée pour les groupes de travail? 
1 « J'aime »
Ça devient de plus en plus une question en effet… Il y a vraiment besoin d’un groupe privé ?
Moi j’aimerais bien pouvoir continuer de suivre les conversation même quand je ne suis pas directement impliqué en ce moment. Il y a déjà des mécanismes pour être plus ou moins informé d’un fil sur le forum, il faudrait mieux laisser ça ici.
2 « J'aime »
Dites, j’avais entendu jeudi (à la réunion mensuel) qu’il y avait une réunion d’avancement ce soir du groupe backup.
Je reprend la discussion en peu en route mais le sujet m’intéresse.
Pourrais-je me joindre à vous avant les discussions au Camp ?
D’après la discussion, j’avais noté 13h pour la réunion aujourd’hui.
On peut se retrouver sur le galène d’immae si ça vous dit : Galène.
vous mettez le login de votre choix et vous laissez le mot de passe libre
1 « J'aime »
Hello tout le monde ! 
Voici une petite synthèse de la réunion d’aujourd’hui (je n’ai pas fait relire, n’hésitez pas à corriger).
Trois ateliers autour des sauvegardes seront proposés au camp CHATONS.
L’intention générale est de proposer une solution technique et organisationnelle pour que chaque chaton puisse faire des sauvegardes résilientes.
1. Gérer ses backups avec Restic
Tour d’horizon et démonstration des fonctionnalités de Restic pour les sauvegardes à travers un retour d’expérience de Picasoft. Présentation des avantages par rapport aux solutions « maison » : chiffrement, vérification de l’intégrité, minimisation de l’espace disque utilisé, diversité des cibles de stockage…
Intentions :
- Donner aux chatons présent les billes pour mettre en place des sauvegardes locales avec Restic;
- Montrer que ces sauvegardes pourront être rendues résilientes sans effort après le travail des ateliers qui suivent.
2. Sauvegardes solidaires et résilientes entres chatons
Présentation haut niveau des avancées du groupe de travail. Des chatons s’associent pour créer des îlots de machines éloignées géographiquement disposant d’espace de stockage. Chaque îlot est une cible de sauvegarde potentielle pour les autres chatons (cf atelier 1). À travers l’exemple de Garage, le logiciel qui tourne sur les îlots, on montrera que ces sauvegardes sont par exemple résistantes aux pannes et compatibles avec les alimentations intermittentes.
Intentions :
- Vulgariser, notamment pour les personnes non techniques, le fonctionnement d’un îlot de sauvegarde;
- Donner confiance dans les outils et l’organisation proposés par le groupe de travail - si ce n’est pas compréhensible et appropriable, c’est contraire à l’esprit chatons.
3. Créer un îlot de sauvegarde avec Garage
Atelier technique collaboratif en petits groupes. Un groupe correspond à un îlot, c’est-à-dire un regroupement de chatons prêts à collaborer pour proposer aux autres un espace de sauvegarde commun. Un îlot = au moins 3 machines, idéalement au moins 2 chatons. Chaque îlot sera accompagné par une personne avec un peu d’expérience dans l’installation de Garage (~5 personnes déjà formées).
Intentions :
- Finir le camp avec plusieurs îlots de sauvegarde utilisables par d’autres chatons;
- Créer du lien long terme entre chatons.
À très vite. 
3 « J'aime »
Voilà les notes que j’ai prises pendant mes tests, ça pourra peut-être servir!
Je les ai remises un peu en forme mais je garantis pas l’absence d’erreurs 
Pour faire suite à l’atelier pratique au camp chatons, je vous propose qu’on commence à monter des îlots. Le tableur qui est sur le nextcloud a l’air d’être suffisant au moins pour déclarer des nœuds, le reste peut se faire par messages entre nous.
Concernant l’espace de stockage, je me dis qu’on pourrait commencer par déclarer des volumes associés à des lieux, parce qu’on pourra peut-être croiser ces données pour monter tout de suite plusieurs îlots homogènes ou en tout cas géographiquement bien répartis.
Dans mon cas j’ai une machine avec pas mal d’espace (1TB actuellement, possible d’y mettre plus) en Allemagne chez Hetzner (FSN1-DC1). Si on a rien d’autre sur ce lieu il peut être intéressant que cette machine serve deux nœuds pour deux îlots différents. Si on a d’autres volumes à cet endroit alors elle sera un nœud dans un seul îlot.
Le sujet a été vaguement abordé pendant l’atelier mais pas tranché: quid des machines « privées »?
Est-ce qu’on s’autorise à utiliser des nœuds qui sont en dehors d’une infra « officielle » de chatons? Si oui, sous quelles conditions, et dans des îlots mixtes ou distincts?
À vous les charagistes!
Nous avons 2 serveurs chez Hetzner en Finlande qui ont pas mal de place libre. On doit pouvoir y allouer 1To (en HDD).
Et en local sur Le Vigan j’ai 3 sites avec connexion fibre. Sur le premier j’ai un petit cluster proxmox de 4 serveurs sur lequel on peut allouer 256 Go par machine (en SSD). Sur les deux autres sites je n’ai actuellement rien qui y tourne avec suffisamment de place libre mais j’ai deux odroid HC4 que je peux y déployer si je trouve des disques inutilisés dans mes cartons.
Pour ma part je suis un peu pris avec Freedom Not Fear qui arrive mais la semaine prochaine on prévoit de publier une version 0.7.3 de Garage qui fonctionne correctement sur ARM - le build actuel a un bug, et au passage corriger la version retournée par l’outil en ligne de commande. Je pense pouvoir m’impliquer après cette release du coup. À très vite.