Il s'agit de passer du fonctionnement local de l'application à un fonctionnement dans le cloud.
À faire
On dispose alors de deux sites statiques Gatsby
Les deux communiquent avec le même serveur apollo et la même base neo4j sur le droplet.
L'OS est Fedora 33 localement et sur le droplet Digital Ocean
Pour les outils suivants, il faut de placer dans le répertoire de base de neo4j qui est : /var/lib/neo4j
Outils
neo4j-admin
par l'utilisateur neo4j
: en particulier pour dump
et load
.cypher-shell
pour communiquer avec la base en ligne de commandeLe fichier de configuration est /etc/neo4j/neo4j.conf
.
On crée un sous-répertoire backups/maquisdoc
dans le dossier de base de neo4j (comme utilisateur neo4j). On copie la dernière version "dumpée" dela base v1-2.dump
avec scp
. Il faut faire une petite salade d'utilisateurs entre remy
, root
et neo4j
et utiliser chown
.
L'utilisateur neo4j de la base est muni d'un vrai mot de passe.
On édite /etc/neo4j/neo4j.com
avec nano
qui est le nouvel éditeur par défaut de fedora. Les lignes suivantes sont modifiées
dbms.default_listen_address=0.0.0.0
dbms.default_advertised_address=*****
pour écouter toutes les adresses IP et indiquer l'IP du droplet.
Si ça ne marche pas en non local, il est possible que le firewall du serveur bloque les ports (par exemple le port 7474 pour le browser). C'est ce qui se passe dans mon cas. Le test du port avec nmap
répond qu'il est dans l'état filtered
ce qui traduit un bloquage par le firewall.
Bien que le serveur soit sous fedora 33, le firewall est encore géré par le service iptables
et non par firewalld
. Après avoir examiné les règles en vigueur j'en ajoute deux (en position 7 et 8) autorisant le passage pour les protocoles http et bolt:
sudo iptables -I INPUT 7 -p tcp --dport 7474 -j ACCEPT
sudo iptables -I INPUT 8 -p tcp --dport 7687 -j ACCEPT
L'agencement des services est identique, le serveur apollo et la base neo4j fonctionnent sur la même machine: localement sur mon ordinateur (développement) ou sur le droplet Digital Ocean (production).
On change le nom du fichier principal de index.js
à maquisdoc-apollo.js
.
On utilise github pour transférer le code du serveur node du local au droplet. Comme ce code est lisible par tout le monde, il ne faut pas y écrire le nom d'utilisateur et mot de passe de connection à la base neo4j.
maquisdoc-apollo.js
, variables d'environnement.On utilise le module process
de node.js pour passer les données de connection avec des variables d'environnement.
const neo4j_url = "bolt://localhost:7687"
const neo4j_pw = process.env.NEO4J_PASSWORD
const neo4j_username = process.env.NEO4J_USERNAME
const driver = neo4j.driver(
neo4j_url,
neo4j.auth.basic(neo4j_username,neo4j_pw)
);
Pour affecter une valeur à une variable d'environnement, on insère
export VARNAME=value
à la fin du fichier ~/.bashrc
avec nano
(référence).
On utilise PM2
qui est un manager de processus pour les applications node.js (référence).
Installation avec npm install pm2@latest -g
et non avec dnf
.
On lance le serveur avec pm2 start maquisdoc-apollo.js
dans le bon répertoire.
Remarque. L'utilisation de variable d'environnement permet de garder le même code bien que les bases neo4j aient des mots de passe distincts localement et sur le droplet
Installation sur le droplet
sudo iptables -I INPUT 8 -p tcp --dport 7687 -j ACCEPT
export NEO4J_PASSWORD = ***
dans le ./bashrc
.pm2 start ecosystem.config.js
Le lancement direct par pm2 start maquisdoc-appolo.js
conduit à une erreur d'authentification sur neo4j due à un mauvais passage des variables d'environnement. Le passage se fait bien par l'intermédiare de ecosystem.config.js
module.exports = {
apps : [{
name: "maquisdoc-apollo",
script: './maquisdoc-apollo.js',
}],
}
Il faut modifier les paramètres du plugin gatsby-source-graphql
pour qu'il interroge le serveur sur le droplet.
Ici encore, on pourrait utiliser des variables d'environnement pour garder le même code localement (développement) et sur le droplet (production) mais il y a un problème avec le passage des variables d'environnement sur l'application Digital Ocean.
automatique lorsque le projet sur GitHub est mis à jour. OK sauf pour la variable d'environnement.
Initialement, je pensais implémenter le service GraphQL apollo dans le cadre des applications digital ocean mais ce n'est pas gratuit. Je l'ai donc implanté sur le droplet.
Je souhaite passer à une architecture comme une application web sur la plateforme digital ocean avec des conteneurs mais je le ferai quand je n'utiliserai plus le serveur historique de Imingo.
L'architecture actuelle des versions de développement et de production est la suivante.
Développement.
L'application Gatsby lit les fichiers locaux dans le dossier local src/pages
de ma macine de travail. En jouant sur l'url du plugin gatsby-source-graphql
elle se connecte au serveur local apollo (connecté à la base locale) ou à celui du droplet (connecté à la base sur le droplet)
Production: site statique Digital Ocean.
L'application lit les fichiers dans le dossier src/pages
du projet sur GitHub. Elle se connecte aux serveur apollo puis à la base neo4j du droplet.