J’aimerais mettre au clair le processus de bootstrap. Dans ma vision des choses, voilà le jeu de poupées russes :
Donc il faut
- compiler le runtime avec srtool
- choisir le genesis state
- écrire les raw chainspec sans bootnode, y injecter le runtime de l’étape (1.), et y écrire les session keys du premier noeud (générées à l’avance)
- compiler un client en mode release avec ces chainspecs
- publier une image docker basée sur ce client
- démarrer un premier noeud en utilisant l’image docker
- ajouter ce noeud aux bootnodes des chainspec
- publier une nouvelle image docker identique à l’exception du bootnode
- démarrer d’autre noeuds avec cette nouvelle image docker
Est-ce valide ? (les étapes 7, 8, 9 sont optionnelles, on pourrait tout à fait publier un docker compose qui contient les bootnodes en command line arguments)
Ça me permettra de compléter
en contextualisant un peu. Parce qu’avec tous les détails techniques :
- binaire duniter degub/release
- CI GitLab
- scripts bash
- xtasks
- compilation avec le docker srtool
- publication du runtime
- appels docker
je m’y perds un peu. J’aimerais bien réécrire cette doc en faisant apparaître la théorie dans la structure, et la pratique dans le contenu. Pour l’instant tout est un peu mélangé je trouve.
Par ailleurs, le fait d’utiliser des commandes docker dans ce processus nécessite d’avoir publié des images au préalable, ce qui complique la démarche. Pour moi docker ne devrait être utilisé que pour faciliter le déploiement sur un serveur, pas pour exécuter des commandes Duniter en local (sauf srtool).
Pas tout à fait d’accord avec ça. Plus c’est compréhensible, plus facilement on peut faire rentrer des devs dans ce processus qui permet de comprendre comment fonctionne substrate. De plus il y a une différence entre bootstraper un réseau de dev et un réseau de prod. Dans un réseau de dev on peut :
- ne pas rotate les session keys, ce qui permet de renseigner le bootnode dès le début et d’éviter d’avoir à publier une deuxième image
- (ou) ne pas renseigner de bootnode et attendre des autres participants du réseau de dev qu’ils l’ajoutent dans leur docker-compose
Des réseaux de dev on peut vouloir en monter pour différentes raisons, c’est mieux si c’est simple et rapide. Effectivement dans un réseau de prod il faut prendre des précautions de sécurité supplémentaires qu’il faut documenter, et pas forcément chercher à rendre accessible.