Petit retour d’expérience suite au redémarrage de la ĞDev réalisé aujourd’hui, notamment pour essayer de projeter le temps d’indisponibilité lors de la migration de la Ğ1 sur Duniter V2S.
Détail de la procédure
Je reprends point par point les étapes que j’ai dû exécuter pour rebooter la ĞDev de zéro avec les données actuelles de la Ğ1.
1. Dumper la Ğ1 avec py-g1-migrator
Environ 1 minute.
Ce processus est assez rapide, mais manuel. Je lance un script chez moi qui copie à chaud les fichiers suivants de Duniter v1 :
- Répertoire
data/ - Répertoire
g1/ - Fichier
txs.db
Le tout est zippé et mis à disposition sur https://dl.cgeek.fr/public/backup-g1-duniter-1.8.7.tgz
2. Créer la release
Environ 11 minutes.
Consiste à :
- pusher le branche de release (ex.
release/runtime-700ici) - actionner le bouton sur le job
create_releaselorsque celui-ci devient disponible
3. Mettre à jour les raw-specs
Environ 1 minute.
Consiste à :
- lancer la commande
cargo xtask update-raw-specs runtime-700 - commiter et pusher les fichiers de specs qui ont été mis à jour par la commande précédente
4. Créer l’image Docker du client
Consiste à :
- actionner le bouton sur le job
g1_docker_deploylorsque celui-ci devient disponible - attendre la fin du build
5. Lancer le réseau
1 minute
Consiste à :
- lancer le conteneur Docker
Suppose d’avoir préparé en amont la clé du nœud et les clés de session compatibles avec la spec Ğ1.
Conclusion
Cela fait donc un total de ~25 minutes de blocage de la Ğ1 en l’état actuel du processus. Il est sûrement possible de descendre aux environs de 10 minutes en optimisant.
Il faut bien noter que ces temps s’obtiennent en ayant préparé les étapes 2 et 5.
Cela dit, je ne suis pas sûr qu’il soit souhaitable de trop mettre d’énergie dans des optimisations : 25 minutes me semble déjà tout à fait acceptable. Je vous laisse juger.