[TUTO] Tester la version de développement de Duniter dans docker

Si vous avez déjà un noeud g1-test

  1. Ajoutez l’utilisateur de ce noeud g1-test au groupe docker

    sudo usermod -aG docker $USER
    sudo newgrp docker

Pour la suite, utilisez cet utilisateur (par exemple avec la commande sudo su - $USER ).

  1. Vérifiez que votre utilisateur peut utiliser docker

    docker run hello-world

  2. Donnez les droits 1111:1111 à votre dossier contenant les données utilisateurs de Duniter :

    chown -R 1111:1111 ~/.config/duniter

  3. Créez et lancez le conteneur

docker run -d -p127.0.0.1:9330:9220 -p10900:10901 -p20900:20901 -v $HOME/.config/duniter:/var/lib/duniter --name duniter registry.duniter.org/nodes/typescript/duniter:dev

  1. Vérifiez dans les log que tout semble bien se passer

    docker logs duniter

  2. Connectez vous a votre web-ui : rendez vous sur https://localhost:9330

Vous êtes sur un serveur dédié ? Qu’a cela ne tienne, utilisez un pont ssh :

ssh -L 9330:localhost:9330 user@host

NB: Par convention personnelle, j’utilise le port 9330 au lieu de 9220 quand il s’agit d’un noeud de test, vous pouvez bien sur faire autrement tant que vous vous y retrouvez :slight_smile:

Si vous n’avez pas encore de noeud g1-test

  1. Créez un user dédié a votre futur noeud g1-test et ajoutez le au groupe docker

    sudo useradd $USER
    sudo usermod -aG docker $USER
    sudo newgrp docker

Pour la suite, utilisez cet utilisateur (par exemple avec la commande sudo su - $USER).

  1. Vérifiez que votre utilisateur peut utiliser docker

    docker run hello-world

  2. Donnez les droits 1111:1111 à votre dossier contenant les données utilisateurs de Duniter :

    mkdir -p ~/.config/duniter
    chown -R 1111:1111 ~/.config/duniter

  3. Donnez les droits 1111:1111 à votre dossier contenant la configuration de Duniter :

    mkdir -p /etc/duniter
    chown -R 1111:1111 /etc/duniter

  4. Créez et lancez le conteneur avec la commande de sync en mode interactif (pour voir la progression de la sync):

docker run -it -p127.0.0.1:9330:9220 -p10900:10901 -p20900:20901 -v $HOME/.config/duniter:/var/lib/duniter -v /etc/duniter:/etc/duniter --name duniter duniter/duniter:dev sync PEER_HOST:PEER_PORT

  1. Quand la sync est terminée, redémarrez votre conteneur

    docker stop duniter
    docker start duniter

  2. Vérifiez dans les log que tout semble bien se passer

    docker logs duniter

  3. Connectez vous a votre web-ui : rendez vous sur https://localhost:9330

Vous êtes sur un serveur dédié ? Qu’a cela ne tienne, utilisez un pont ssh :

ssh -L 9330:localhost:9330 user@host

NB: Par convention personnelle, j’utilise le port 9330 au lieu de 9220 quand il s’agit d’un noeud de test, vous pouvez bien sur faire autrement tant que vous vous y retrouvez :slight_smile:

1 Like

Désormais mon noeud g1-test ts.gt.librelois.fr (Elois-2) tourne dans docker selon cette procédure, pour l’instant tout semble fonctionner parfaitement :slight_smile:

Pour maintenir automatiquement a jours votre conteneur duniter, vous pouvez utiliser watchtower.

Pour mettre à jours ponctuellement votre conteneur duniter :

docker run --rm \
 -v /var/run/docker.sock:/var/run/docker.sock \
containrrr/watchtower \
--run-once \
duniter

Remplacez « duniter » par le nom que vous avez donné a votre conteneur.

Je viens de mettre à jours mon noeud g1-test ts.gt.librelois.fr avec la commande ci-dessus, et « it’s just work » :smiley:

Mieux encore, vous pouvez laisser tourner watchtower en permanence pour qu’il mette automatiquement à jours votre conteneur Duniter dès qu’une nouvelle version du tag de l’image est pushée :

$ docker run -d \
    --name watchtower \
    -v /var/run/docker.sock:/var/run/docker.sock \
    containrrr/watchtower
    duniter

Avec cette commande, watchtower vas checker toutes les 5 minutes si une nouvelle version de l’image est dispo, et si oui il va mettre à jours votre conteneur.

Cela permettrait par exemple aux alpha-testeurs d’avoir toujours la dernière version de dev :slight_smile:

Je viens de réussir, après une journée de tâtonnement. Le tuto ne fonctionne pas. à partir de la création du container.

La commande de synchro a bien fait la synchro, mais le container n’est pas utilisable.

Ce qui a fonctionné pour moi pour la création d’un container avec un serveur lancé :

docker run -it --rm --detach -p127.0.0.1:9220:9220 -p10901:10901 -p20901:20901 -v $HOME/.config/duniter:/var/lib/duniter --name duniter registry.duniter.org/nodes/typescript/duniter:test-image direct_webstart

Là le container reste actif…

Après il suffit de lancer les commandes duniter ainsi :

docker exec duniter duniter -h

docker exec duniter duniter status

docker exec duniter duniter logs

Ensuite, comme cette machine est un serveur non graphique, j’ai fait un tunnel ssh comme conseillé (lapin compris pourquoi la commande du tunnel me log sur le serveur… mais ça marche!).

Du coup j’accède à l’interface d’admin via http://ip_du_serveur:9220.

Là il faut en premier mettre votre ip publique dans l’interface réseau. C’est possible pour WS2P, mais pas pour BMA (@tykayn, tu pourrais ajouter la possibilité de mettre à la main l’ip publique pour BMA ?).

Pour BMA, j’édite le fichier de config conf.json (en superuser de ouf, puisque seul l’utilisateur 1111 du container a les droits).

Je modifie le forwarding de ma box pour natter les ports vers le bon serveur…

J’espère que le monde extérieur va me voir… Hoé je suis là !

A suivre…

je peux tenter de faire un coup de bash pour ça, mais au risque de faire des bêtises je vais d’abord me renseigner sur ce que BMA veut dire :smiley:

Bon, après avoir fait un test en mode network host, je suis revenu en mode bridge.

  • Je suis bien vu en ws2p public par cesium.
  • Je calcul des blocs comme un malade. Je pense donc que l’oxydation fonctionne.
  • J’accède à BMA depuis mon réseau en utilisant mon ip publique.
  • Duniterpy accède à WS2P publique depuis mon réseau en utilisant mon ip publique.

Seul bémol, les logs montre des problèmes de connexions avec les pairs.

2020-04-08T11:30:43+00:00 - info: WS2P: Could not connect to peer 5B8iMAzq using `WS2P gt.moul.re 443: WS2P connection timeout`
2020-04-08T11:30:43+00:00 - info: WS2P: Could not connect to peer D1Fk2X5w using `WS2P 82.64.191.57 20900: WS2P connection timeout`
2020-04-08T11:30:43+00:00 - info: WS2P: Could not connect to peer 3dnbnYY9 using `WS2P 82.64.200.156 20900: WS2P connection timeout`
2020-04-08T11:30:43+00:00 - info: WS2P: Could not connect to peer 238pNfpk using `WS2P g1-test.duniter.org 20902: WS2P connection timeout`
2020-04-08T11:30:43+00:00 - info: WS2P: init: bundle of peers 2/2
2020-04-08T11:30:43+00:00 - error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE
2020-04-08T11:30:43+00:00 - error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE

Et de réponse à une connexion entrante :

2020-04-08T17:08:22+00:00 - info: WS2P HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb: new incoming connection from 82.64.191.57:60244!
2020-04-08T17:08:37+00:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout

La config réseau docker :

        "Networks": {
            "bridge": {
                "IPAMConfig": null,
                "Links": null,
                "Aliases": null,
                "NetworkID": "xxx",
                "EndpointID": "xxx",
                "Gateway": "172.17.0.1",
                "IPAddress": "172.17.0.2",

La config réseau de duniter :

 "ws2p": {
  "uuid": "c4df202c",
  "privateAccess": true,
  "publicAccess": true,
  "preferedOnly": false,
  "privilegedOnly": false,
  "upnp": false,
  "remotehost": "80.67.176.219",
  "host": "172.17.0.2",
  "port": 20901,
  "remoteport": 20901,
  "maxPublic": 10,
  "maxPrivate": 10,
  "remotepath": ""
 },
 "proxiesConf": {
  "reachingClearEp": "clear",
  "forceTor": false
 },
 "sigStock": 100,
 "sigWindow": 1051920,
 "idtyWindow": 1051920,
 "msWindow": 1051920,
 "rootoffset": 0,
 "udTime0": 1496527200,
 "udReevalTime0": 1496570400,
 "storage": {
  "transactions": false,
  "wotwizard": false
 },
 "remoteport": 10901,
 "ipv4": "172.17.0.2",
 "port": 10901,
 "remoteipv4": "80.67.176.219"