Suite à Les datapods partent en prod et aux annonces faites dans Terminer Duniter v2 -- priorisation des tâches, j’ai entrepris de stabiliser les datapods pour les mettre en prod facilement et sans risque de devoir faire des actions manuelles compliquées pour mettre à jour. Je me suis un peu arraché les cheveux sur mon code vraiment très expérimental, et suis en train d’arriver à quelque chose qui plante moins. J’ai particulièrement galéré pour que la synchro avec les pairs ne vienne pas surpasser les capacités de traitement et entraîne des comportements erratiques des connexions avec ipfs. J’y suis allé comme un bourrin pour que ça stabilise quitte à brider les performances, je vais tester ça prochainement en live, mais les aventureux peuvent déjà essayer la dernière version des images docker, ce qui rendra la synchro plus intéressante.
Voici une série de deux longues vidéo qui sont un pré-tutoriel à l’installation de datapods encore très expérimentaux.
sommaire
00:00 bonjour, intro de rentrée
00:15 lien de la vidéo Ğ1ntada Ğ1ntada 2024 - Conférence Hugo et Kapis - P2Tube
00:18 programme : installation des datapods v2 expérimentaux
01:10 prérequis serveur debian avec docker
01:50 création du dossier docker/datapod
02:32 dépôt avec docker-compose.yml d’exemple nodes / Duniter Datapod · GitLab
03:17 explication du docker-compose.yml
08:11 récupération du fichier .env d’exemple
11:48 docker compose pull
12:23 docker compose up -d && docker compose logs -f datapod
13:17 examen des logs du datapod
14:18 problème de résolution IPNS
15:16 démo de l’admin du noeud IPFS
17:10 configuration DNS CNAME
20:12 démonstration d’une publication pubsub
21:46 récupération du peer id webtransport
23:36 datapods settings dans duniter panel
26:44 démonstration des trois connections p2p dans chromium
27:16 démonstration des connections webtransports dans firefox
27:49 petit bug de duniter connect qui ne charge pas les comptes
28:10 édition du profil datapod via duniter panel
28:40 découverte du bug d’initialisation d’un datapod vide et dépôt de ticket gitlab associé
31:39 changement du endpoint graphql datapod dans duniter panel
32:14 programme de la suite de cette vidéo et de la vidéo suivante
33:10 présentation des clés IPNS
34:50 présentation de l’arbre d’indexation des datapods
36:12 démonstration des requêtes graphql dans le datapod
36:33 résilience des systèmes distribués
37:55 présentation des logs pubsub
38:29 conclusion de la première partie
sommaire
00:00 regardez la partie 1 d’abord
00:50 examen des logs quand un datapod se synchronise
04:04 [passage d’une voiture bruyante dans la rue]
04:44 connection directe à la console hasura (via pont ssh)
05:40 souscription graphql sur le dernier arbre indexé
06:10 souscription graphql pour voir le nombre de profils indexé
07:14 souscription aux derniers profile indexés sur les datapods
09:36 mise à jour du pair dans duniter panel
11:11 publication d’un nouveau profil sur les datapods
18:56 config nginx pour l’api graphql des datapods
21:06 génération du certificat avec certbot
22:26 ça marche du premier coup 
23:18 modification du endpoint graphql datapod dans duniter panel
27:17 vérification que l’indexation a bien eu lieu en base de donnée
27:42 examen des configuration hardcodés dans les datapods
28:45 ajout de gyroi.de dans la config hardcodée
32:32 un peu de contexte sur les mécanismes de peering datapods dans ipfs
34:14 exemple sur l’avatar récupéré sur plusieurs passerelles ipfs
36:00 configuration du https sur la passerelle http ipfs
36:20 découverte d’un nouveau bug d’indexation :‘(
40:04 test de la récupération de l’avatar sur la nouvelle passerelle
41:32 différence entre passerelle ipfs et passerelle à sous-domaine
43:43 découverte d’un nouveau bug d’indexation :’(
44:44 conclusion sur le duo de vidéo
Il y a un problème de transcodage sur la deuxième, @poka si tu as le temps de regarder les logs peertube je suis preneur.
Petit retour suite à la première vidéo, sans obligation de réponse, je vais attendre que la seconde video soit dispo si jamais mon souci vient d’un mauvais réglage de mon reverse proxy …
Vu que j’ai mes Id IPFS, vais tenter plus tard dans la soirée, d’ajouter ce Datapod via le Panel… Je ferai un EDIT de ce post de l’avancée de ce test de mise en place Datapod.
Dans tous les cas merci @HugoTrentesaux pour ce petit Tuto en DirectDev’ 
Logs et Divers
- Lors des essais de connections via tunnel SSH
http://127.0.0.1:5002/ipfs/bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige/#/
ssh -NL 5002:datapod.g1.rendall.fr:5001 root@g1.rendall.fr
root@g1.rendall.fr's password:
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused
...etc .... a chaque essai de connection via le navigateur
- Logs de Démarrage
✨ starting
🌴 self root key is k51qzi5uqu5dh3cd2y6bkg95s6ifne8wgie5gc991x7pjm3svlmpmac832q60s
🔨 starting from scratch: bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige
🌱 adding empty node to ipfs
initialize history to dd_tamt_hist
🛢 latest indexed cid bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige
🔌 connected to http://kubo:5001
👂 listening on topic ddd
👌 already at bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige
🔄 syncing from peer /ipns/k51qzi5uqu5dip97g90ww9dxql8jc7t7sd0qi1fxx8g0rfr56vbt41tk17xnoe
🔄 syncing from peer /ipns/k51qzi5uqu5djid2dlwsjecuri0yluo1yy1lzqkdvlthjljiaff28b38gf2399
🔄 syncing from peer /ipns/k51qzi5uqu5dic5o2c15iw5k06witnddyrroln4qhblq8lkqp7yq7zj6uql03u
+++ pubsub error +++
1726674971718
🔌 connected to http://kubo:5001
👂 listening on topic ddd
+++ pubsub error +++
1726675271767
🔌 connected to http://kubo:5001
👂 listening on topic ddd
🔄 syncing from peer /ipns/k51qzi5uqu5dip97g90ww9dxql8jc7t7sd0qi1fxx8g0rfr56vbt41tk17xnoe
🔄 syncing from peer /ipns/k51qzi5uqu5djid2dlwsjecuri0yluo1yy1lzqkdvlthjljiaff28b38gf2399
🔄 syncing from peer /ipns/k51qzi5uqu5dic5o2c15iw5k06witnddyrroln4qhblq8lkqp7yq7zj6uql03u
+++ pubsub error +++
1726675572029
🔌 connected to http://kubo:5001
👂 listening on topic ddd
🔄 syncing from peer /ipns/k51qzi5uqu5dip97g90ww9dxql8jc7t7sd0qi1fxx8g0rfr56vbt41tk17xnoe
🔄 syncing from peer /ipns/k51qzi5uqu5djid2dlwsjecuri0yluo1yy1lzqkdvlthjljiaff28b38gf2399
🔄 syncing from peer /ipns/k51qzi5uqu5dic5o2c15iw5k06witnddyrroln4qhblq8lkqp7yq7zj6uql03u
+++ pubsub error +++
1726675872403
🔌 connected to http://kubo:5001
👂 listening on topic ddd
-
Reglages DNS
-
KUBO logs
Initializing daemon...
Kubo version: 0.30.0-846c5cc
Repo version: 16
System version: amd64/linux
Golang version: go1.22.7
PeerID: 12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE
2024/09/18 18:14:36 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
Swarm listening on 127.0.0.1:4001 (TCP+UDP)
Swarm listening on 172.19.0.8:4001 (TCP+UDP)
Run 'ipfs id' to inspect announced and discovered multiaddrs of this node.
RPC API server listening on /ip4/0.0.0.0/tcp/5001
WebUI: http://0.0.0.0:5001/webui
Gateway server listening on /ip4/0.0.0.0/tcp/8080
Routing V1 API exposed at http://0.0.0.0:8080/routing/v1
Daemon is ready
- Gateway Logs
Listening on http://127.0.0.1:3000
- Hasura Logs
INF detail={"http_info":{"content_encoding":null,"http_version":"HTTP/1.1","ip":"127.0.0.1","method":"GET","status":200,"url":"/healthz"},"operation":{"query":{"type":null},"request_id":"b1426711-8498-4b43-8ebb-477dc716cbd9","request_mode":"non-graphql","response_size":2,"uncompressed_response_size":2},"request_id":"b1426711-8498-4b43-8ebb-477dc716cbd9"} timestamp=2024-09-18T18:23:44.353+0000 type=http-log
INF detail={"http_info":{"content_encoding":null,"http_version":"HTTP/1.1","ip":"127.0.0.1","method":"GET","status":200,"url":"/healthz"},"operation":{"query":{"type":null},"request_id":"24d01126-3351-445a-8b30-6f8d624f8537","request_mode":"non-graphql","response_size":2,"uncompressed_response_size":2},"request_id":"24d01126-3351-445a-8b30-6f8d624f8537"} timestamp=2024-09-18T18:24:14.391+0000 type=http-log
- PostGres Logs
2024-09-18 18:14:35.273 UTC [1] LOG: starting PostgreSQL 16.4 (Debian 16.4-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-09-18 18:14:35.275 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-09-18 18:14:35.275 UTC [1] LOG: listening on IPv6 address "::", port 5432
2024-09-18 18:14:35.279 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-09-18 18:14:35.291 UTC [29] LOG: database system was shut down at 2024-09-18 18:14:22 UTC
2024-09-18 18:14:35.309 UTC [1] LOG: database system is ready to accept connections
2024-09-18 18:19:35.379 UTC [27] LOG: checkpoint starting: time
2024-09-18 18:19:35.913 UTC [27] LOG: checkpoint complete: wrote 8 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.517 s, sync=0.006 s, total=0.535 s; sync files=7, longest=0.003 s, average=0.001 s; distance=8 kB, estimate=8 kB; lsn=0/15C1388, redo lsn=0/15C1350
- PubSub Logs
No log line matching the '' filter