Je poursuis la mise en place d’outils pour déployer facilement un cluster de nodes Duniter V2.
Après le billet précédent qui permet de déployer un cluster de VMs, voici un dépôt Ansible pour déployer des nodes via l’image Docker sur une ou plusieurs machines (VM ou machine physique).
J’ai en fait implémenté sous Ansible la réplique du docker-compose disponible ici :
Ça fonctionne sans erreurs, mais je ne suis pas certain que le second node soit connecté au premier.
J’attends vos retours, pour ceux qui veulent tester.
Merci @vit , base-toi plutôt sur le compose live-template.docker-compose.yml qui est beaucoup plus à jour et réaliste pour un vrai réseau.
Il faut que je supprime gdem-local2…
J’ai également créé récemment ce script pour lancer un live network (lancer une monnaie quoi), ça peut probablement t’aider de le lire, mais il requiert encore une compilation manuelle pour le moment (se quelqu’un veut bien faire une Pr pour améliorer ça c’est bienvenu ):
J’essaie de créer le fichier raw des specs de la chaîne à partir du json d’exemple fourni dans le dépôt.
Ceci en lançant un container à partir de l’image docker.
J’ai échoué une première fois avec un champ manquant dans le json source. (ce qui me montre que le fichier json est bien lu et parsé…). Corrigé en mettant à jour l’image docker.
J’échoue maintenant avec un problème de permission, alors que duniter doit sortir le raw dans la console…
Je n’arrive pas à reproduire ton erreur en local (chez moi ça fonctionne).
Mais de toute façon tu n’as pas besoin de générer les chain spec, cela doit être fait une seule fois par le créateur du bloc genesis.
Une fois la ğdev lancée, j’intègrerai les chain spec directement dans le binaire (comme le font tous les vrais projets basés sur substrate), et il suffira de lancer duniter avec le flag --chain gdev.
Seules les autorités présentes dès le genesis devront récupérer le fichier json des raw spec et utiliser l’option --chain path/to/gdev-raw.json
Pour tes tests tu peux générer le raw file en dehors de docker, ou je peux t’en fournir un, mais il faut qu’il indique des sessions keys dont tu possèdes les clés privées.
Il faut alors copier la valeur hexa du champ « Session Keys » dans le json de configuration du genesis
Ça injecte directement les clés privées dans le « keystore » dans le chemin indiqué suivi de chains/local. Il faut alors renommer « local » par le nom du futur réseau que tu bootstrap, c’est ce que fait le script ligne 62.
Je fais ça car je veux que la recette Ansible soit versatile, et maîtriser l’image docker.
J’ai sûrement un problème de permissions sur un dossier (même si je ne sais pas ce que duniter veut écrire ni où…). Je vais continuer à chercher…
De toute façon j’aurai aussi le problème quand je voudrais générer des sessions keys. Je n’ai pas encore bien cerner si ces clefs privées sont nécessaires à lancer un nœud forgeron, mais si c’est le cas alors je dois pouvoir le faire par la recette Ansible.
EDIT: ouvrir les permissions sur le dossier où se trouve le json source fonctionne ! Je poursuis donc mon apprentissage…
Elles ne sont nécessaires que pour les nœuds forgeron indiqués comme autorité active dès le genesis dans la configuration de ce dernier.
La méthode de génération que j’ai indiqué ci-dessus n’est nécessaire que pour les membres forgerons déclarés dans le bloc genesis comme autorité active dès le genesis (ce qui n’est pas obligatoire).
Pour tous ceux qui rejoindront les autorités après le genesis, donc pour quasiment tout le monde, on lance le nœud duniter-v2s sans renseigner de session keys, puis on appelle la méthode RPC author_rotateKeys de son nœud, comme je l’avais montré en vidéo
):