Avec @elois@Pini et @vit nous venons de faire fonctionner ce type de docker-compose, configuré pour lancer un noeud g1 test qui va se synchroniser au réseau:
Elois a fait un gros boulo pour faire en sorte de pouvoir passer en variables d’environnements les données utilisateurs nécessaires aux fonctionnement de Duniter
Pour lancer plusieurs nœuds sur une seul machine, il vous suffit d’incrémenter les ports de la colonne de gauche (10902,10903, ect …) et de régler votre reverse proxy sur ces ports, seulement si vous désirez que votre nœud soit accessible via url.
Par defaut ce sont ici des volumes virtuels qui sont créés, docker les gères très bien tout seul.
Vous pouvez accéder à ces volumes depuis le host ici: /var/lib/docker/volumes/duniter-test1_data/_data/duniter_default/data/
Vous pouvez utiliser docker exec -it pour executer des choses dans les container. Notamment, @elois vous dira un mot sur la nécessité de parfois utiliser dex ou d’autres choses dans les containers, lors de certaines mises à jours notamment.
Vous pouvez configurer ce docker-compose comme bon vous semble, tout est possible
Nous avons besoin de beaucoup de noeuds !
Nous avons besoin qu’un maximum de personnes passent leur noeuds gtest sur duniter1.9-dev, c’est à dire sur le model de ce compose.
Avec une 20n de noeuds gtest, on va enfin pouvoir commencer à tester le réseau via GVA.
J’ai déjà 3 noeuds configurés sur ce compose qui tournent sur une VM de mon infra, sync remote ok, semblent stables depuis 2 jours.
Voici la liste des noeuds gtest 1.9-dev connus actuellement:
Attention chaque fois que la structure d’une DB change (toutes les semaines en ce moment) vous aller devoir faire des manips spécifiques que je vous dirai, qui peuvent être différents à chaque fois. Faire tourner un nœud de dev demande beaucoup plus de rigueur et de suivi qu’un nœud en version stable.
Si vous souhaitez nous rejoindre dans ces tests, indiquez-le-moi (en MP ou en public ici selon votre préférence) et je vous dirai si je pense que vous avez le niveau pour ça ou pas.
Svp ne vous forcez pas, si vous n’avez pas le niveau ou pas le temps de suivre votre nœud de près votre participation pourrait être contre-productive !
Merci de votre compréhension
De mon côté j’ai 2 nœuds membres dans 2 conteneurs docker sur une même VM:
Je fais des essais de synchro en boucle depuis plusieurs jours, et je vois toujours les 5 mêmes endpoints au démarrage de la synchro lorsque je référence g1-test.duniter.org. Dernier essai de cet après-midi :
2021-05-14T14:06:03+00:00 - info: Downloading Blockchain...
2021-05-14T14:06:03+00:00 - info: Connecting to address g1-test.duniter.org :443...
2021-05-14T14:06:03+00:00 - info: Connecting to address gt.moul.re :10902...
2021-05-14T14:06:03+00:00 - info: Connecting to address g1-test.pini.fr :443...
2021-05-14T14:06:03+00:00 - info: Connecting to address gtest.jytou.fr :443...
2021-05-14T14:06:03+00:00 - info: Connecting to address g1-test.duniter.org :10900...
2021-05-14T14:06:05+00:00 - info: Getting chunck #0/3020 from 0 to 249 on peer g1-test.duniter.org
J’ai bien compris. Mais ce serait utile d’avoir quelques endpoints BMA en plus pour faciliter la synchro. Est-ce que ça poserait un souci d’activer BMA en plus ?
Comme ma question est tournée, j’intuite que ça veut plutôt dire “oui, ça pose un problème, mais on va pas t’expliquer parce qu’on a autre chose à faire là, tu comprends, on teste GVA”
Non pas encore, là je développe les préparatifs indispensables pour pouvoir commencer à migrer la sync. Je dois notamment d’abord migrer la db des peers, tout est lié
Je me rends compte qu’il n’est pas possible de finaliser la synchronisation de mon nœud sur la branche dev sur la Ğ1-test. Je ne sais pas si c’est le cas avec v1.8.1. Je ne trouve plus le post qui disait que c’était un problème de manque de points d’accès BMA.
