Pour l’instant il n’y a que deux nœuds dans le bootstrap, celui de cgeek et le mien mais avec un mauvais peerid. J’ajouterai plus de nœuds bootstrap dans le prochain release pour avoir un découverte réseau plus fonctionnelle.
Le but d’utiliser nginx comme reverse proxy est de servir l’API RPC du miroir en https sur 443. Donc pas besoin d’écouter sur 9944 à l’extérieur, il suffit d’écouter à l’intérieur et de mettre le reverse proxy. Je ne suis pas très compétent sur le sujet, mais j’essayerai de détailler ce point.
Il faut que je regarde sur quoi pointe duniter-v2s-gdev:latest suite au travail de cgeek. Chez moi j’ai encore version 0.8.0-unknown
. On va justement travailler sur ces numéros de version pour s’y retrouver plus facilement.
Ça c’est parce qu’il n’a pas réussi à décoder la clé, c’est donc normal qu’il ne puisse pas donner le node id. Je ne sais pas ce qui se passe dans ce cas là.
Ça aussi je ne suis pas spécialiste, mais voici ce que j’ai compris :
- Si un service écoute sur 127.0.0.1, il n’écoute qu’en local. Si on veut le faire écouter sur l’extérieur, il faut soit
- Avec Docker binder le port d’écoute local sur un port qui écoute à l’extérieur.
- Avec Nginx faire un reverse proxy pour ajouter https.
- Si un service écoute sur 0.0.0.0, il écoute sur l’extérieur.
- S’il est dans un Docker, il faut de toute façon binder le port.
- S’il n’est pas dans un réseau local virtuel, il écoute vraiment sur l’extérieur et il faut ouvrir le pare-feu.
Quelques exemples de binding de port avec docker pour un service qui écouterait sur 8080 dans le docker :
ports:
# écoute uniquement en local sur 80
- 127.0.0.1:80:8080
# écoute sur l'extérieur sur 80
- 0.0.0.0:80:8080
# note : on peut omettre le 0.0.0.0, c'est le comportement par défaut
Donc ce que je fais si j’ai trois nœuds miroir, c’est 127:0.0.1:9944:9944
, 127:0.0.1:9945:9944
, 127:0.0.1:9946:9944
. Et ensuite trois reverse proxy https depuis 443 vers 9944, 9945, 9946 avec les noms de domaine noeud1.gdev.net
, noeud2.gdev.net
, noeud3.gdev.net
. Comme ça le endpoint est simplement de la forme wss://noeud1.gdev.net/
, où 443 est implicite. Par contre, le p2p, je le bind sur l’extérieur avec 30333:30333
, 30334:30333
, 30335:30333
, et j’écoute directement en tcp/udp sans passer par un proxy. Le dns sert alors uniquement à trouver l’ip, pas à identifier une ressource sur la machine. J’espère que ça clarifie les choses.
Ça c’était sur les anciennes versions de Duniter, depuis une mise à jour substrate (je ne sais plus laquelle), il n’y a plus que le 9944, http et ws étant sur le même endpoint, ce qui est plus logique et plus pratique. Les docs sont à jour normalement, mais je n’ai pas communiqué dessus dans des release notes parce que ça ferait beaucoup de travail en plus alors qu’on est encore assez tôt dans l’aventure.
Ça c’est étrange, si tu as bien dans ton compose
il devrait connaître la chaîne gdev. Et je suppose que le “no such file or directory” vient de là.
Non, c’est à nous de faire en sorte que ça fonctionne avec les version de docker que les gens auront, même si c’est improbable que ce soit lié à ça. Là je pencherais plutôt pour une histoire de dossier non créé, mais c’est surprenant, je regarderai en relisant la MR de cgeek.
Je pense au contraire que ça vient de là, je vais faire des tests.
Oui, j’ai été un peu optimiste ><
En général je travaille plutôt en semaine, donc le weekend du 29 et 30 j’ai un peu déconnecté (même si j’ai bien avancé sur Panneau pour visualiser les forgerons, mais c’est une autre histoire ). Comme je ne suis pas chez moi, je ne garantis rien avant dix jours
Au contraire, ça m’aide à m’y mettre ! Quand je me sens seul, j’ai tendance à avancer sur ce qui me plait le plus même si ce n’est pas le plus urgent, mais quand je vois que des gens attendent mes retours, ça me motive pour y répondre ! C’est ce que j’attendais dans la constitution de l’équipe forgeron et vos questions sont le plus beau cadeau que vous pouvez me faire (cf Objectif : 20 forgerons v2 pour mon anniversaire!).
PS : @matograine as tu vu Debian package for Duniter v2 ? On a aussi besoin de retour là dessus, et c’est plus facile, ça demande moins de configuration que docker. En gros l’idée pour l’instant c’est :
- docker est packagé pour le maximum de contrôle
- debian est packagé pour la simplicité
La doc est déjà à jour (Duniter | Run a mirror node) mais je compte faire une vidéo en français pour expliquer davantage les choix et donner des exemples.