Bonjour à tous,
L’application Cesium hébergée http://cesium.duniter.fr a connue des perturbations depuis hier matin.
Des erreurs du type Node not available ou Nœud non joignable.
La situation est rétablie.
il s’agissait d’un problème de configuration du serveur web frontal.
Nœud Duniter virtuel en mode “fail over”
Pour les personnes les plus techniques : voici un point sur la configuration mise en place.
Les serveurs web comme Nginx permettent de configurer plusieurs serveurs derrière une même adresse web, pour gérer une répartition de charge (ou load balancing) mais encore pour assurer la bonne continuité de service (fail-over) : si un serveur ne répond plus, un autre prend le relais.
Lorsque des applications telle que Cesium sont accessibles en ligne, beaucoup d’utilisateurs gardent la configuration par défaut, notamment la configuration du nœud par défaut (Paramètres > Adresse du nœud Duniter).
La stabilité de l’application se trouve ainsi lié à un seul nœud Duniter. Bien que la monnaie en elle-même ne soit pas directement dépendante de ce nœud.
À terme, l’application Cesium évoluera pour gérer le basculement (côté client / navigateur web)
vers un nœud joignable, si la connexion au nœud par défaut était perdue. Cependant, ce basculement nécessitera sans doute le choix d’un nouveau nœud de confiance par l’utilisateur (par exemple dans une liste).
Je suis cependant d’avis d’éviter au maximum ce type d’action, notamment pour ne pas décourager un utilisateur débutant.
Le problème est le même pour les synchronisations, à l’initialisation d’un nœud : les nœuds proposés par défaut doivent être aussi stables que possible.
Configuration d’un nœud virtuel sous Nginx
Pour disposer d’un nœud virtuel (à haute disponibilité), suivez les étapes suivantes :
- Éditer le fichier de configuration Nginx. Par défaut dans
/etc/nginx/sites-available/default - Définissez votre
poolde nœuds Duniter :- Ici on utilisera deux nœuds, respectivement accessible sur le réseau local comme
192.168.0.10:8998et192.168.0.10:8999 - L’option
weight=3est optionnelle, et permet à nginx de prioriser les accès vers cette machine, lorsqu’elle est accessible.
- Ici on utilisera deux nœuds, respectivement accessible sur le réseau local comme
upstream duniter-nodes-pool {
least_conn;
server 192.168.0.10:8998 weight=3;
server 192.168.0.10:8999;
}
- Définissez un serveur virtuel, comme suit :
- Choisissez le port d’écoute de votre nœud virtuel. Ici :
9201 - Choisissez le nom DNS du serveur virtuel. Ici,
test-net.duniter.fr
- Choisissez le port d’écoute de votre nœud virtuel. Ici :
server {
listen 9201;
listen [::]:9201;
server_name test-net.duniter.fr;
location / {
proxy_pass http://duniter-nodes-pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
}
}
Voila, vous disposez d’un nœud virtuel ! 
Comme vous pouvez le constater, il sagit d’une définition “classique” d’un reverse proxy sous Nginx, avec cependant quelques différences notables :
- Le paramètre
proxy_passrenvoi vers le pool de nœuds duniter, et non vers un nœud en particulier. - L’ajout des directives
add_header, pour autoriser les navigateurs à accéder à ces nœuds depuis une application (comme Cesium) hébergées ailleurs que sur votre domaine. Si vous omettez ces directives, vous obtiendrez des erreurs JavaScript de type “same origin policy” (voir le ticket #177) qui bloqueront les accès à votre nœud virtuel.
Docs :
!
