Aide pour mapping des ports docker Duniter V2S

Support Duniter-v2
, , , ,
1

Bonjour,

Je voudrais mettre en place un noeud Duniter V2 pour GDev; j’ai lu pas mal de messages sur le forum et la documentation pour la mise en place d’un noeud duniter v2 (Duniter | Duniter v2) mais il reste un point qui n’est pas vraiment clair concernant les ports.

Pour le port 30333 - public p2p endpoint, c’est clair et je vois que l’on peut faire le mapping public avec la variable d’environnement DUNITER_PUBLIC_ADDR; qui devrais me permettre de le mapper vers un DNS spécifique avec port 443.

Pour le port 9615 - prometheus, je suppose qu’il ne devrait pas être exposé vers l’extérieur; si c’est bien le cas, je suggérerais de le préciser dans les docker-compose proposés et de restreindre par défaut à 127.0.0.1.

ports:
  # (private) prometheus telemetry to monitor resource use
  - 127.0.0.1:9615:9615

Pour le port 9944 - RPC API, je suppose que suivant le type de noeud Duniter, il faut l’exposer publiquement ?
Si oui, comment puis-je le faire via proxy nginx en https port 443 (je ne vois pas de variables d’environnement permettant de faire un mapping public avec DNS spécifique pour ce port) ?

Si ces questions avaient déjà une réponse quelque part, merci de m’indiquer les resources que je n’aurais pas encore trouvées :slight_smile:

Merci d’avance.

Nicolas

P.S. : Mon serveur est un Oracle always free resources avec architecture ARM et je remarque qu’il n’y a pas systématiquement d’image docker en linux/arm64/v8 pour duniter v2 gdev. La plus récente que j’ai trouvé est duniter/duniter-v2s-gdev-800:801-0.8.0. Est-ce que vous pensez qu’ils serait possible de systématiser la création des images ARM ?

1 Like
2

Le port 30333 p2p sert pour la connexion entre les nœuds via p2p. Donc, oui à exposé dans l’hôte et à ouvrir sur le net. Ça permet au nœud de rester synchronisé ! À noter que Substrate s’occupe d’ouvrir les ports avec UPnP.

Le port 9944 de RPC, permet aux clients de s’y connecter. À exposer au souhait. Dans le cas d’un nœud validateur/smith, généralement 9945, ne pas exposer ce port, car l’API permet d’effectuer des actions non sécurisées.

Le port 9615 de prometheus, permet de faire du monitoring. Si tu ne l’utilises pas il n’est pas nécessaire de le mapper et de l’exposer.

La configuration de ports dans le docker compose concerne le mapping des ports de l’intérieur du conteneur vers la machine hôte. Pour en plus les exposer sur le net, il faut ouvrir les ports dans le firewall et/ou mettre en place des redirections sur la box. Il est aussi possible de passer via un proxy tel Nginx.

La production automatisée d’images ARM a été enlevé dans cette MR.

3

Il y a une subtilité ici : le port 30333 permet d’ouvrir des connexion TCP directement, et accepte aussi des connexions HTTP pour ouvrir un websocket, mais uniquement pour les nœuds miroir, c’est désactivé pour les nœuds validateur d’après ce que j’ai compris. Je recommande donc de laisser établir une connexion directe TCP comme discuté dans ce sujet : Configuration réseau pour un bon fonctionnement pair à pair.

Peux-tu préciser ce que tu entends ici ? Je ne comprends pas comment upnp pourrait ouvrir des ports.

Bien vu, je pensais l’avoir fait, mais apparemment pas partout.

Effectivement, c’est ce qu’il faut faire pour qu’un nœud miroir puisse être utilisé depuis une application. Il s’agit de la dernière section “Expose the RPC API publicly” :link:. Il n’y a pas eu beaucoup de questions à ce sujet, mais c’est une portion de la documentation à retravailler je suis d’accord.

Effectivement, c’est un problème. J’ai rouvert #139. La cross compilation vers ARM ne fonctionne pas avec docker et pas toujours avec podman. Il faudrait la réparer mais actuellement plus personne ne travaille dessus. Si je ne me trompe pas, l’image que tu mentionnes devrait fonctionner, mais ce serait mieux de publier une image ARM sur la dernière version.

1 Like
4

Le protocole UPnP est utilisé par Duniter v1, Duniter v2 et par d’autres logiciels pour établir des connexions entrantes à partir de connexions sortantes sur les box. Je ne connais pas exactement le fonctionnement de ce protocole. L’« ouverture de port » ou l’établissement de la connexion entrante est le résultat de ce protocole. Je donne une piste. Après, à chacun d’aller creuser jusqu’au niveau de détail qui l’intéresse.

Je montre dans ce post, que des ports sont ouverts sur ma box via UPnP pour le protocole p2p.

5

Merci pour vos réponses.

Dans ce cas là, de quelle manière peut on fournir l’URL d’accès (uniquement configurée dans mon Nginx proxy manager) pour les applications ?
Ou bien est-ce que c’est plutôt prévu pour être uniquement utilisé “en local” par des applications installées dans le même serveur ?

J’ai remarqué que les serveurs de @Pini ont une adresse xx/tcp/443; c’est pour ça que je me disais que ça dois pouvoir fonctionner correctement si je configure un proxy host (nginx) pour cet accès la, et ne pas exposer 30333 directement.

1 Like
6

Oui c’est parfaitement possible en utilisant un reverse-proxy. J’utilise le combo nginx-proxy + acme-companion qui marche très très bien. Ça permet d’avoir uniquement les ports 80 et 443 ouverts sur le serveur, et aussi de faire cohabiter plusieurs services sans qu’ils ne se marchent sur les pieds.

Note : jusqu’à il y a peu j’avais un fork perso de ces outils pour permettre le binding de plusieurs ports par conteneur (ce qui est le cas de duniter), mais les toutes dernières versions upstream ont maintenant cette fonctionnalité.

7

Bonne question. Dans Duniter v1, il existait un mécanisme p2p pour partager les endpoints. En faire un pour Duniter v2 a été discuté dans le sujet Liste des endpoints, mais en attendant le dépôt networks assure cette tâche, il faut ajouter son endpoint dans le fichier gdev.json. C’est une bonne remarque, je vais l’ajouter à la documentation [edit c’est maintenant fait ici].

1 Like
8

J’ai l’impression de me répéter mais il n’y aucunement besoin d’ouvrir les ports 30333 grâce au hole pushing de libp2p: Le nœud forgeron de moul n’est pas à l’heure - #21 by poka

Pour preuve, sur mes infra proxmox, où j’ai des VM contenant des noeud forgerons et miroir Duniter v1 et v2, je n’ai jamais ouvert le moindre port. Idem pour mon noeud gdev actuellement chez moi derrière ma box, aucun NAT.

1 Like
9

Au risque de me répéter également, avec ceci seul ton nœud pourra initier des connexions, les autres ne pourront pas te contacter. Vu les paramètres par défaut du nombre de connexions entrantes et sortantes, ton nœud sera moins bien connecté (cf Configuration réseau pour un bon fonctionnement pair à pair).

poka-archive a 12 pairs, poka-smith a 10 pairs, contre 28 pour hugo-coindufeu-archive qui a les mêmes réglages et est également en auto-hébergement à la maison mais avec une box qui redirige tout le trafic entrant sur ma machine.

Et je ne peux pas faire depuis l’extérieur :

ipfs swarm connect /dns/pokahome.p2p.legal/tcp/30333/p2p/12D3KooWGzfuKHDEPzwUomSzJnUZ9fQ38V2RBHwTYR46ZggNwZaA

(j’utilise IPFS pour tester simplement en ligne de commande la connectivité p2p mais c’est indépendant du protocole qu’on utilise par dessus la connexion)

Donc oui, ça va fonctionner, mais si une trop grande proportion du réseau fait ça, on peut avoir des problèmes de connectivité. Par exemple, tu ne peux pas bootstrap un réseau comme ça parce que personne ne pourra contacter ton nœud de bootstrap s’il n’est pas sur ton réseau local.

Dans ce sujet Nicolas80 essaye de faire les choses bien et de comprendre comment ça marche, donc je lui donne les informations. Ça n’est pas très utile de lui dire “mais non, t’inquiète pas t’as rien à faire, la magie du holepunching-p2p-substrate-upnp apporte la gloire, la fortune, et le succès dans la recherche de l’être aimé”.

3 Likes
10

Bon argument, je n’avais pas pensé à ce problème à l’échelle du réseau. Si tout le monde n’expose pas le port p2p, tous les nœuds du réseau ne devraient pas pouvoir se connecter les uns les autres, car ils ne peuvent pas établir de connexion entre nœuds derrière UPnP. À tester :slight_smile: À l’échelle individuelle, il est possible d’utiliser uniquement UPnP-NAT (network address traversal), à condition que tout le monde ne le fasse pas, ce qui est généralement pas le cas.

11

@poka Effectivement, je ne conaissais pas les détails de libp2p; j’ai pu aller lire la doc et c’est bien intéressant :slight_smile:

Mais comme dis @HugoTrentesaux ici mon but est de voir quelle est la meilleure configuration possible pour mon setup tout en restant suffisament sécurisé.

Du coup, en regardant les infos dans les logs docker et en me connectant à mon node via polkadot.js; je vois que je n’ai que 11 peers; et il semblerait que @HugoTrentesaux mentionnait qu’il y aurait donc un soucis à régler si on a que 11 peers - mais je ne vois pas lequel.

Le lien polkadot.js de mon noeud: ici

Ci dessous, mes configurations pour le compose.yaml et NGinx:

services:
  duniter-v2s-mirror:
    # Issue to have linux/arm64/v8 images; not present in all docker hub tags !
    image: duniter/duniter-v2s-gdev-800:801-0.8.0
    platform: linux/arm64/v8
    container_name: duniter-v2s-gdev
    restart: unless-stopped
    ports:
      # (Private) Prometheus (for monitoring)
      # can't seem to add it as a data source in grafana :-/
      - 127.0.0.1:9615:9615
      # (Public) RPC access (only for MIRROR nodes)
      # Exposed in NGinx under https://v2mirror-rpc.g1.brussels.ovh
      - 127.0.0.1:9944:9944
      # (Public) P2P access (using libp2p which can work without port forwardings)
      # Exposed in NGinx under https://v2mirror.g1.brussels.ovh
      - 127.0.0.1:30333:30333
    volumes:
      - data-mirror:/var/lib/duniter/
    environment:
      # gdev, gtest or g1
      - DUNITER_CHAIN_NAME=gdev
      # Only a MIRROR node (default is false)
      - DUNITER_VALIDATOR=false
      - DUNITER_NODE_NAME=v2mirror_g1_brussels_ovh
      # To configure the (Public) P2P access
      - DUNITER_PUBLIC_ADDR=/dns/v2mirror.g1.brussels.ovh/tcp/443
      # Non validator nodes have extra "/ws" to force P2P end point in websocket
      - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws
    networks:
      dockge_dockge_net: null
volumes:
  data-mirror: null
networks:
  dockge_dockge_net:
    external: true

Et dans le même réseau docker, mon NGinx configuré avec ces proxy host rules:
https://v2mirror-rpc.g1.brussels.ovh => http://duniter-v2s-gdev:9944
https://v2mirror.g1.brussels.ovh => http://duniter-v2s-gdev:30333

Outre le fait que je n’ai que 11 peers; j’ai remarqué 2 choses étranges dans les logs du duniter pendant le démarrage:

duniter-v2s-gdev  | 2024-11-15 12:01:24 💔 The bootnode you want to connect to at `/dns/gdev.coinduf.eu/tcp/30333/p2p/12D3KooWFseA3B66eBzj4NY5ng3Lb2U3VPnKCi3iXYGYUSAahEw7` provided a different peer ID `12D3KooWHW1JXJNTVLRqtXmu6R7W9ohpRHcJGHNmw6wpVTukNAgZ` than the one you expect `12D3KooWFseA3B66eBzj4NY5ng3Lb2U3VPnKCi3iXYGYUSAahEw7`.

=> Peut-être est-ce dû au fait que je ne peux pas utiliser la dernière image docker et le bootstrap n’est pas totalement correct (j’utilise la seule disponible en ARM) ?

duniter-v2s-gdev  | 2024-11-15 12:01:24 🔍 Discovered new external address for our node: /ip4/141.145.210.46/tcp/30333/ws/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH

=> Pour celui là, je ne comprend pas comment il peut décrouvrir un accès qui est bloqué par Docker même (port 30333 uniquement mappé vers 127.0.0.1 dans mon cas) - mais c’est sans doute sans conséquence. Ou bien c’est libp2p qui le “trouve” - auquel cas le terme “external address” est mal choisi car pas réellement exposé publiquement…

12

Ok, j’ai ajouté wss://v2mirror-rpc.g1.brussels.ovh au fichier gdev.json.

Effectivement, dans l’image que tu as, il y a deux bootstraps : celui de cgeek qui est correct, et le mien qui a changé de peer id entre temps. Il faudrait réparer le build ARM pour avoir les bons nœuds bootstraps qui sont maintenant plus nombreux.

Effectivement, c’est étrange, je ne sais pas comment fonctionne ce protocole de découverte, il ne devrait pas donner des infos qui sont clairement fausses.

J’arrive bien à me connecter à ton nœud avec cette commande :

ipfs swarm connect /dns/v2mirror.g1.brussels.ovh/tcp/443/wss/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH

Donc je suppose qu’il te suffit de changer cette ligne :

en :

- DUNITER_PUBLIC_ADDR=/dns/v2mirror.g1.brussels.ovh/tcp/443/wss/

Le “wss” à la fin permet d’indiquer que le protocole à utiliser sur tcp est websocket, et non simplement un tcp “nu”.

1 Like
13

Tu peux aussi construire l’image ARM directement sur ta machine ARM, pour avoir la dernière version.

14

Je n’ai encore jamais utilisé ipfs et ce n’est pas un package disponible directement dans Ubuntu ou … En cherchant rapidement de vois une mention de IPFS Kubo qui en est une implémentation; mais est-ce que j’ai besoin de ça pour faire des tests de connections ?

Est-ce qu’il y aurait un sujet ou une doc spécifique à comment tester la connectivité des noeuds duniters v2s déployés ?

Effectivement, je pourrais tenter ça (j’imagine que c’est ce repo duniter-v2s). Est-ce qu’il y a des branches spécifiques pour la gdev du coup ?
Comment on sait quelle est la dernière version valide que l’on peut tenter de builder et démarrer en gdev ?

15

Kubo est installé sur mon système parce que je l’utilise par ailleurs et il se trouve qu’il est pratique pour tester les connexions libp2p. Ce n’est pas nécessaire, mais je ne connais pas d’autre outil qui rende le même service, il faudrait chercher un outil plus minimal.

C’est un sujet que j’ai découvert récemment, j’ai donc une mauvaise vision d’ensemble et je bricole avec les outils que je connais. Il faudrait fouiller la doc et les tutoriels substrate pour trouver ce genre d’information.

Oui, il y a une branche par réseau. Le réseau gdev actuel correspond à la branche network/gdev-800. Pour contourner une limitation de notre CI, il y a également des branches network/gdev-80*, mais c’était juste pour publier un runtime. Le ticket #239 vise à améliorer ça.

C’est une question difficile. Normalement toutes les versions du client devraient permettre de se connecter à la gdev si on leur donne les bonnes chainspecs (bootnodes et genesis, incluant le runtime du genesis). Mais le plus simple, et pour ne pas avoir besoin de fournir les chainspecs indépendamment, est d’utiliser une version qui inclut les chainspecs dans l’exécutable. C’est le but des branches de réseau comme network/gdev-800. À noter que le nom “gdev-800” correspond au réseau gdev qui a dans son genesis le runtime gdev 800.

1 Like
16

@Moul, @HugoTrentesaux J’ai récupéré le repo git duniter-v2s sur ma machine Oracle Ubuntu ARM, je suis passé sur la branche network/gdev-800 et j’ai fais cette commande pour créer une image docker locale:

#Depuis le root du repo git:
docker build -t duniter-v2s-gdev-800-arm-20241116 -f docker/Dockerfile .

Du coup j’ai adapté mon noeud v2mirror pour utiliser cette image et je l’ai relancé

docker compose ps
NAME               IMAGE                                      COMMAND               SERVICE              CREATED          STATUS          PORTS
duniter-v2s-gdev   duniter-v2s-gdev-800-arm-20241116:latest   "docker-entrypoint"   duniter-v2s-mirror   36 minutes ago   Up 36 minutes   127.0.0.1:9615->9615/tcp, 127.0.0.1:9944->9944/tcp, 127.0.0.1:30333->30333/tcp

J’avais également adapté la config pour l’adresse publique comme @HugoTrentesaux l’avait suggéré en ajoutant “/wss” pour DUNITER_PUBLIC_ADDR :

    environment:
      # ...
      - DUNITER_PUBLIC_ADDR=/dns/v2mirror.g1.brussels.ovh/tcp/443/wss
      - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws

Mais je ne vois toujours que peu de peers connectés (actuellement 8).

Du coup est-ce cela veut dire que j’ai toujours un soucis à régler ?

https://polkadot.js.org/apps/?rpc=wss://v2mirror-rpc.g1.brussels.ovh/ws#/

17

Surement que le port libp2p n’est pas accessible sur le net.

Tu peux essayer avec kubo, après l’avoir installé, lance le daemon :

ipfs daemon

Récupère la clé de ton nœud. C’est affiché au démarrage du nœud. Le redémarrer permet de la récupérer. Je ne sais pas si préciser la bonne clé est nécessaire pour s’y connecter.

2024-11-16 16:22:23 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full    
2024-11-16 16:22:27 Local node identity is: 12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx    
2024-11-16 16:22:27 Running litep2p network backend

Puis, dans une autre console tu peux tester avec tes hosts (domain, ip). Par exemple :

> ipfs swarm connect /dns/gdev.moul.re/tcp/30333/p2p/12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx
connect 12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx success

> ipfs swarm connect /ip4/188.23.44.109/tcp/30333/p2p/12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx
connect 12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx success

> ipfs swarm connect /ip6/2001:871:261:d2c7:de01:4670:5bd7:c021/tcp/30333/p2p/12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx
connect 12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx success

J’ai eu des connexions avec succès, mais j’ai testé depuis mon réseau local, pas depuis l’extérieur de mon réseau :wink: Donc, à tester avec une machine à l’extérieur du réseau local.

2 Likes
18

@Moul J’ai installé Kubo

ipfs init

# que je laisse tourner dans un autre terminal
ipfs daemon 

# fait depuis mon propre réseau, séparé du serveur Oracle (et VPN coupé)
ipfs swarm connect /dns/v2mirror.g1.brussels.ovh/tcp/443/wss/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH
connect 12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH success

Pour info, le serveur duniter-v2s mentionne l’url complète pendant le démarrage:

🔍 Discovered new external address for our node: /dns/v2mirror.g1.brussels.ovh/tcp/443/wss/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH

Donc la connection semble correcte…

2 Likes
19

J’arrive aussi à m’y connecter !

1 Like
20

Juste pour vérifier que le ProxyHost NGinx n’est pas en cause; je viens d’adapter pour exposer directement le port 30333:

    ports:
      #...
      #- 127.0.0.1:30333:30333
      # Testing exposing raw port 30333
      - 0.0.0.0:30333:30333
    environment:
      #...
      #- DUNITER_PUBLIC_ADDR=/dns/v2mirror.g1.brussels.ovh/tcp/443/wss
      # Testing exposing raw port 30333 as ws
      - DUNITER_PUBLIC_ADDR=/dns/v2mirror.g1.brussels.ovh/tcp/30333/ws
      - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws

Le port est bien adapté:

docker compose ps
NAME               IMAGE                                      COMMAND               SERVICE              CREATED              STATUS              PORTS
duniter-v2s-gdev   duniter-v2s-gdev-800-arm-20241116:latest   "docker-entrypoint"   duniter-v2s-mirror   About a minute ago   Up About a minute   127.0.0.1:9615->9615/tcp, 127.0.0.1:9944->9944/tcp, 0.0.0.0:30333->30333/tcp

Le redémarrage du serveur détecte bien ce que j’ai demandé, et également mon proxyHost NGinx qui est toujours en place

🔍 Discovered new external address for our node: /dns/v2mirror.g1.brussels.ovh/tcp/30333/ws/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH
...
🔍 Discovered new external address for our node: /dns/v2mirror.g1.brussels.ovh/tcp/443/wss/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH

Les 2 adresses fonctionnent bien depuis chez moi:

ipfs swarm connect /dns/v2mirror.g1.brussels.ovh/tcp/30333/ws/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH 
connect 12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH success

ipfs swarm connect /dns/v2mirror.g1.brussels.ovh/tcp/443/wss/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH
connect 12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH success

Edit: Il découvre également l’adresse ip4 pour le port exposé 30333; mais également une adresse sans la partie “p2p” qui est étrange; et ne fonctionne pas avec ipfs:

docker compose logs | grep "Discovered"
duniter-v2s-gdev  | 2024-11-17 08:58:17 🔍 Discovered new external address for our node: /dns/v2mirror.g1.brussels.ovh/tcp/30333/ws/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH    
duniter-v2s-gdev  | 2024-11-17 08:58:26 🔍 Discovered new external address for our node: /ip4/141.145.210.46/tcp/30333/ws/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH    
duniter-v2s-gdev  | 2024-11-17 08:58:38 🔍 Discovered new external address for our node: /dns/v2mirror.g1.brussels.ovh/tcp/443/wss/p2p/12D3KooWCEiqfwVDkqHWUhUh9iz2QukTiDnmXRdAC23RwkM5inSH    
duniter-v2s-gdev  | 2024-11-17 09:04:44 🔍 Discovered new external address for our node: /ip4/141.145.210.46/tcp/30333/ws

Par contre toujours bloqué à 9-10 peers…

2 Likes