En réutilisant les containers existants cela fonctionne. Intéressant.
En revanche, je n’ai pas encore compris comment fonctionne le paramétrage de l’oracle de distance. J’ai lu les quelques fils que j’ai pu trouvé sur le forum. Je n’ai pas trouvé cela super limpide. J’ai fait quelques essais, j’ai à chaque fois une erreur de connexion RPC.
Je verrais demain si j’arrive à libérer un peu de temps.
Y a-t-il une doc quelque part qui référence les paramètres avec leurs descriptions ?
Cette documentation donne un exemple de docker compose qui inclut un 2ème service pour l’Oracle.
2 points important:
distance-oracle il faut donner le bon nom DNS vers le service du noeud SMITH (duniter-smith) au sein du réseau docker; a renseigner dans variable d’environnement:ORACLE_RPC_URL: ws://duniter-smith:9944
(En général j’hardcode un container_name dans mes services; et j’utilise celui la comme DNS au sein du même réseau Docker - mais je suppos que s’il n’y a pas de container_name il prend le nom du service directement)
duniter-smith et distance-oracleAutre chose, tant que le nouveau runtime n’est pas déployé; le distance-oracle ne fera pas grand chose; voir mon message dans l’autre post: Appel à installer Duniter 0.9.1 - #12 by Nicolas80
J’ai découvert docker avec la June. Comment voir/utiliser le fqdn du noeud smith. Un docker exec avec le container du noeud smith et cat du /etc/hosts ne donne rien de probant.
docker exec v2s-latest-duniter-smith-1 cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.18.0.2 3ca3a4ea3b26
le nsswitch contient ceci :
docker exec v2s-latest-duniter-smith-1 cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: files
group: files
shadow: files
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
J’ai regardé comme je pouvais (limitation des binaires disponibles dans l’image), je n’ai pas l’impression qu’un service named/bind tourne sur le noeud.
J’ai aussi utilisé le name du container (v2s-latest-duniter-smith-1) comme affiché ici :
docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
63b96d0f5cb8 pinidh/acme-companion:latest "/bin/bash /app/entr…" 2 minutes ago Up 2 minutes letsencrypt
f11be291019d nicolas80/duniter-v2s-gdev-800:900-0.9.1 "docker-distance-ent…" 2 minutes ago Up 2 minutes 9615/tcp, 9944/tcp, 30333/tcp distance-oracle
af8f450398e4 pinidh/nginx-proxy:latest "/app/docker-entrypo…" 2 minutes ago Up 2 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp reverse_proxy
e450df8f6261 nicolas80/duniter-v2s-gdev-800:900-0.9.1 "docker-entrypoint" 2 minutes ago Up 2 minutes 9615/tcp, 30333/tcp, 127.0.0.1:9944->9944/tcp v2s-latest-duniter-smith-1
Quelque chose doit être devant le bout de mon nez que je ne vois pas.
Où puis-je checker quel est le FQDN qui est utilisé ? Celui est nécessairement différent du FQDN externe (exposé sur Internet) si j’ai bien compris tes explications.
Je ne suis pas un expert docker non plus.
Ce lien explique que Docker a un DNS intégré
Et comme expliqué, il faut que les containers soient sur le même réseau docker.
Si tu as plusieurs services dans un même docker compose, et que tu ne précise rien pour le network, ils seront par défaut dans le même network “default” pour ce “projet”/compose
Et comme je disais, pour avoir un nom dns (interne au réseau docker) simple, il suffit de préciser une valeur unique pour “container_name” dans chaque service (au même niveau que “image”)
Pour tester la résolution du dns, tu peux démarrer un shell dans un container qui tourne et faire un “ping [valeur du container_name]” par exemple.
Edit: quand ping n’est pas dans l’image; faire getent hosts [valeur du container_name]
Je peux donner mon docker compose.yaml en exemple.
services:
duniter-v2s-validator:
image: nicolas80/duniter-v2s-gdev-800:latest
platform: linux/arm64/v8
container_name: duniter-v2s-gdev-validator
restart: unless-stopped
ports:
# (Private) Prometheus (for monitoring)
# can't seem to add it as a data source in grafana :-/
- 127.0.0.1:9616:9615
- 127.0.0.1:9945:9944
- 127.0.0.1:30334:30333
#- 0.0.0.0:30334:30333
volumes:
- data-validator:/var/lib/duniter/
environment:
# gdev, gtest or g1
- DUNITER_CHAIN_NAME=gdev
- DUNITER_VALIDATOR=true
- DUNITER_PRUNING_PROFILE=light # <--- stays light
- DUNITER_NODE_NAME=Nicolas80-GDev-smith
# exposing through NGinx reverse proxy as WSS WebSocketSecured
- DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/443/wss
- DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws
# Alternative to directly expose port 30334 (in that case; need change ports to have "0.0.0.0:30334:30333" instead of "127.0.0.1:30334:30333")
#- DUNITER_PUBLIC_ADDR=/dns/smith.gdev.brussels.ovh/tcp/30334
#- DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
networks:
dockge_dockge_net: null
distance-oracle:
image: nicolas80/duniter-v2s-gdev-800:latest
container_name: distance-oracle
entrypoint: docker-distance-entrypoint # other entrypoint
environment:
ORACLE_RPC_URL: ws://duniter-v2s-gdev-validator:9944 # container_name from SMITH node above
ORACLE_RESULT_DIR: /var/lib/duniter/chains/gdev/distance/ # should match network
ORACLE_EXECUTION_INTERVAL: 200 # <--- should be adjusted based on network
volumes:
- data-validator:/var/lib/duniter/ # use same volume
networks:
dockge_dockge_net: null
volumes:
data-validator: null
networks:
dockge_dockge_net:
external: true
Dans celui-ci, j’utilise un même “external” docker network dockge_dockge_net sur lequel j’ai plusieurs docker compose connectés; notament mon “NGinx Proxy Manager” qui me permet de mapper des DNS externes vers du DNS docker interne spécifique + port
Exemple concret de l’usage du DNS interne docker:
Depuis le docker compose SMITH + Oracle (il faut donner le nom de service pour les commandes compose)
docker compose exec duniter-v2s-validator /bin/bash
# ip/ifconfig pas disponible dans les images => hostname -I
hostname -I
172.21.0.12
# Changement de shell pour celui de l'Oracle
docker compose exec distance-oracle /bin/bash
hostname -I
172.21.0.16
# On arrive bien à résourdre le DNS vers le SMITH
# Ping n'est pas disponible dans les images => getent hosts <container_name>
getent hosts duniter-v2s-gdev-validator
172.21.0.12 duniter-v2s-gdev-validator
Depuis mon docker compose de NGinx Proxy Manager (configuré sur le même Docker network dockge_dockge_net)
docker compose exec nginx-proxy-manager /bin/bash
hostname -I
172.21.0.4
getent hosts nginx-proxy-manager
172.21.0.4 nginx-proxy-manager
getent hosts duniter-v2s-gdev-validator
172.21.0.12 duniter-v2s-gdev-validator
getent hosts distance-oracle
172.21.0.16 distance-oracle
Et pour terminer mon exemple; dans mon NGinx Proxy Manager, je peux donc faire un Proxy pour mapper l’url et dns public “https://smith.gdev.brussels.ovh/” vers l’url et Dns interne docker + port http://duniter-v2s-gdev-validator:30333/
Note : Je me permets de déplacer cette section de discussion dans un sujet qui facilitera sa découverte par de futurs lecteurs.
Effectivement, l’oracle de distance demande pour l’instant un peu de connaissance de docker. On a des pistes pour gérer ça directement depuis Duniter pour simplifier, mais pour l’instant il faut faire avec.
Il y a aussi cette page qui propose d’avoir l’oracle dans un autre compose, et dans laquelle je parle du nom de réseau et du nom de service.
Moi aussi. J’étais assez réticent au début, mais j’ai appris beaucoup de choses notamment grâce à @Pini (tout ce qui touche aux volumes et réseaux) et @aya (tout ce qui touche aux layers). Donc je vous encourage à continuer à vous entre-aider, c’est vraiment comme ça qu’on apprend et qu’on se forme tous ensemble pour faire marcher notre réseau de manière autonome !
Pour l’instant je constate que les gens qui utilisent l’oracle via docker sont confrontés à des problèmes qui me semblent infiniment plus compliqués que ceux qui peuvent survenir sans, que ça apporte de la confusion sur les options et sur la doc disponible, qu’il n’est pas possible (ou pas évident) de bidouiller en changeant les commandes à chaud, et que je ne suis pas capable d’aider (ni la volonté, pour les raisons précédentes).
Je comprends que docker puisse faciliter la config de Duniter, mais pour l’oracle ça semble juste tout compliquer. L’oracle fonctionne avec tout simplement un service systemd dont la commande est dans la doc (/docs/user/distance.md).
Serait-il possible de faire tourner Duniter dans docker, et l’oracle hors de docker ? Enfin s’il y a des problèmes de système de fichiers et de connexions réseau ça ne réglera probablement rien…
Après la lecture des docs qu’à pointé @Nicolas80 et les quelques docs de docker, j’ai trouvé une solution simple (enfin que je comprends, il est possible qu’il y ait une redondance avec des paramètres par défaut, néanmoins je pense qu’avec un paramétrage explicite cela facilite la compréhension).
La log distance-oracle montre que cela a fonctionné :
INFO [distance_oracle] Nothing to do: Pool does not exist
Waiting 1800 seconds before next execution...
Voici les étapes que j’ai suivi :
Ajout d’un nom pour le container (utile pour la résolution de noms)
et création d’un réseau de type bridge pour ce container.
paramètres: container_name et networks
services:
duniter-smith:
#image: duniter/duniter-v2s-gdev:latest
#image: duniter/duniter-v2s-gdev-800:latest
image: nicolas80/duniter-v2s-gdev-800:900-0.9.1
restart: unless-stopped
container_name: daigongen-g1
networks:
- duniter-gdev
La même chose doit être faite dans le service distance-oracle (paramètres container_name + networks)
# distance oracle
distance-oracle:
container_name: distance-oracle
# choose the version of the image here
image: nicolas80/duniter-v2s-gdev-800:900-0.9.1
networks:
- duniter-gdev
Ne pas oublier le paramétrage du RPC dans le service distance-oracle (le host doit matcher le container name défini dans le service “duniter-smith” :
environment:
ORACLE_RPC_URL: ws://daigongen-g1:9944
et enfin la définition du réseau en fin de fichier :
networks:
duniter-gdev:
driver: bridge
attachable: true
Pour compléter ce retour, j’ai oublié de préciser quelque chose d’important à faire pendant les tests.
Le container distance-oracle démarre plus vite que le container smith (check de parité de la base), il est donc normal qu’une première erreur RPC soit générée.
Pour éviter d’attendre la prochaine itération, il possible de redémarrer le container distance-oracle :
docker container restart distance-oracle