LIFWEB TP5c - Déploiement Node js

Ce sujet va être amené à changer d’ici au 15/04

L’objectif de ce TP est de réaliser un serveur web Node.js minimaliste et de le déployer sur une machine virtuelle Linux. Ce TP met en œuvre les connaissances de LIFSE de L2 et fait écho à la partie Administration de LIFPCA (CM4, TD5 et TP6) qui a lieu à peu près en parallèle.

Machine cible

Vous disposez d’une VM Ubuntu Server 22.04 pré-installée avec Node.js, et Nginx monté en reverse proxy. Les informations de connexion sont dans Tomuss :

  • La colonne IP-VM donne le nom de votre VM au format 192.168.XX.YYY.
  • La colonne SSH-KEY contient une clef privée SSH pour l’utilisateur p${ID_ETU}.
  • La colonne SSH-CI contient une clef privée SSH pour un utilisateur gitlabci non-privilégié.

Par exemple, pour un⋅e étudiant⋅e dont le numéro ID_ETU=122001122, l’accès SSH pour l’utilisateur privilégié se fait comme suit :

# -o IdentitiesOnly=yes est utile si vous avez beaucoup de clefs dans votre ~/.ssh
ssh -o IdentitiesOnly=yes -i p22001122.pem p22001122@192.168.XX.YYY

⚠️ Attention ⚠️

Problèmes classiques que vous pourrez rencontrer.

  • Le compte utilisateur privilégié est la variante de votre numéro d’étudiant⋅e préfixé par p mais celui de la machine est préfixé par 1
  • Une clef SSH doit avoir des droits Unix 600 ou moins ;
  • Votre compte privilégié est sudoer sans mot de passe, ainsi :
    • toujours sauvegarder les fichiers systèmes avant de les modifier (cp file.conf file.conf.original) ;
    • avant de vous déconnecter de la session SSH, vérifier que vous arrivez toujours à ouvrir une autre session.
  • Les VMs ne sont pas routées sur Internet, il faut donc obligatoirement utiliser une IP UCBL :

Exercice 0 (PRÉPARATION) : accès à la VM

On prend en main l’environnement de travail.

  • Se connecter à votre VM et mettre à jour l’OS.
    • Redémarrer la VM si nécessaire.
  • Déterminer le nombre de CPUs et la quantité de RAM de la VM.
  • Relever les versions exactes et noter les commandes pour les obtenir :
    • Ubuntu
    • Node.js
    • Nginx
  • Quels sont les autres utilisateurs du système qui disposent d’un home directory ?
    • Parmi eux, lesquels sont sudoers ?

⚠️ Enregistrer ces informations dans un fichier au format Markdown si on devait les demander. ⚠️

Exercice 1 : Configuration Nginx

On étudie la configuration déjà fournie pour se l’approprier. Sauf précision contraire, on suppose qu’on exécute depuis la VM.

  • Faire une requête sur http://localhost/nginx/ de votre VM avec https://curl.se/ (curl -I url).
    • Quel code HTTP obtenez-vous ?
  • Maintenant avec un navigateur, depuis une autre machine, saisir l’IP de la VM à la place de localhost. Qu’obtenez vous ?
  • Consulter le fichier de configuration /etc/nginx/sites-available/default et identifier les lignes qui expliquent quel fichier est chargé lors des requêtes précédentes.

⚠️ Assurez-vous que toutes les étapes précédentes sont bien réalisées, sinon vous serez bloqués sur la suite des TPs. ⚠️

Exercice 2 : serveur Node.js

On crée un premier serveur Node.js qui va se connecter à la base de donnée et vérifier ainsi que toute la chaîne est fonctionnelle. On utilise l’API native node:http.

  • Téléverser votre projet dans un dossier ~/node/ sur votre VM.
    • Utiliser scp depuis votre station.
    • Ce sera pour la suite le dossier de travail courant (le retour de la commande pwd).
  • Installer le projet avec npm install dans le dossier de travail.
  • Créer un fichier .env à partir de l’exemple ci-dessous.
  • Lancer le serveur avec la commande npm start.
    • Quelles sont les différences entre le script start et le script prod du fichier package.json ?

À partir de là, vous pouvez vérifier depuis une machine cliente autre que la VM (par exemple, celle depuis laquelle vous vous êtes connectés en SSH), via navigateur ou ligne de commande, que les routes suivantes sont accessibles, où ${VM} désigne l’adresse IP de la VM serveur (de la forme 192.168.XX.YYY) :

  • GET http://${VM}/
  • GET http://${VM}/health
  • GET http://${VM}/api avec les différentes routes vues au TP5a.

Ensuite, fermer la connexion SSH qui a lancé l’application sur la VM. Sauf à avoir suivi d’autres étapes que celles demandées, votre application ne devrait plus être en cours d’exécution. Pourquoi ? Le vérifier.

Exemple de fichier .env

à personnaliser avec votre IP :

PORT=3000
HOST=localhost
URI=http://192.168.XXX.YYY

Vous aurez quelques changements à faire dans votre code :

  • Dans server.js, insérez ligne 21 le code suivant uri: process.env.URI, pour rendre disponible l’IP de votre VM au programme node. Cela vous permettra d’envoyer la bonne adresse de retour du POST.
  • Dans server.js, mettre le niveau de logging à “info” au lieu de “warn” (cela permettra le traçage à l’exo 3).
  • Dans public/javascripts/app.js, mettre l’IP de votre VM à la place de localhost.

Et vous devrez modifier la configuration de nginx :

  • Editer le fichier /etc/nginx/sites-available/default (cela demande un sudo) et modifier la ligne qui pointe vers les fichiers clients, elle ne devrait pas pointer vers l’utilisateur ubuntu mais vers le dossier public de votre projet.
  • Vérifier que le dossier public est accessible et lisible par ‘other’, changer les droits d’accès pour permettre à nginx de traverser les dossiers et lire les fichiers.

Exercice 3 : déploiement daemon

L’utilisateur nommé gitlabci est non privilégié dans votre VM. Il dispose d’un compte déjà configuré et de sa propre clef SSH (colonne Tomuss SSH-CI).

C’est avec ses droits que l’application Node.js doit être exécuté en tâche de fond (daemon).

  • S’authentifier en tant que gitlabci, tester les deux façons :
    • Directement avec sa clef SSH.
    • Depuis le compte privilégié, avec sudo -u gitlabci -i.
  • Installer votre application dans le dossier /home/gitlabci/node comme dans l’exercice précédent.
  • Vérifier qu’elle fonctionne.

Créer un service systemd pour que votre serveur soit exécuté en mode daemon, pour cela en root ou via sudo :

  • Copier le fichier node.service dans le dossier /etc/systemd/system/.
  • Relancer le gestionnaire avec systemctl daemon-reload et vérifier que le service existe bien avec systemctl status node.service.
    • Le service doit être inactif.
  • Lancer le service avec systemctl start node.service (vérifier avec systemctl status), activez-le par défaut pour qu’il soit relancé automatiquement après reboot avec systemctl enable node.service.
  • Vérifier que vous avez accès aux logs avec journalctl --unit node.service.
    • Pour un affichage live du journal, utiliser l’option --follow.
  • Depuis un autre utilisateur, faites une requête HTTP sur votre serveur.
  • Vérifier que cette requête a bien généré une trace dans le journal.
  • Déconnectez-vous et vérifier que le service est toujours disponible.
  • Reconnectez-vous et redémarrez la machine avec reboot.
  • Attendez un peu que la machine redémarre et vérifiez à nouveau la disponibilité du service.

À ce stade, vous êtes capable de déployer une application Node.js en mode résidant sur un serveur distant avec un compte non-privilégié.