8722 sujets

Développement web côté serveur, CMS

Bonjour,

cette question rejoint un peu une question que j'avais déjà posé dans le forum Javascript mais en fait elle est plutôt ciblée coté serveur..

J'ai un petit serveur écrit en node.js que je lance sur une machine de mon réseau et qui écoute sur un port (8080)
Je lance le serveur dans un terminal avec une commande node db, avec un ficher node.js de ce style

const dotenv = require("dotenv")
dotenv.config()
const mongodb = require("mongodb")

mongodb.connect(process.env.CONNECTIONSTRING, { useNewUrlParser: true, useUnifiedTopology: true }, function(err, client) {
  if (err) {
    console.log(err)
  }
  module.exports = client
  const app = require("./app")
  app.listen(process.env.PORT)
})


si la machine du serveur a une adresse IP 192.168.1.10 je peux accéder mon serveur à partir du réseau en ciblant le port avec 192.168.1.10:8080 par exemple, et une application client en node + express ou React peut accéder à des données à partir du serveur 192.168.1.10 ...


Donc ça marche ... maintenant ma question c'est , dans le cadre d'une entreprise par exemple est ce que ça peut être suffisant et fiable de procéder comme ceci, ou bien il existe d'autres solutions pour le déploiement et je rappelle que ici je veux rester dans le cadre d'un Intranet local...
Modérateur
Bonjour,

En matière de sécurité, le sujet est vaste.

Ton intranet n'est de toute façon pas visible de l'extérieur (les ip 192.168.1.xxx). Par contre, les machines du réseaux ont probablement accès à l'extérieur. La sécurité à mettre en place me semble être du même genre que pour une machine posée sur la table de ton salon (une box internet que tout le monde a à la maison crée en quelque sorte un réseau local).

Après, il y a la sécurité en interne. Il ne faudrait pas que n'importe qui rentre dans l'entreprise avec un portable puisse accéder au réseau interne. Là aussi, c'est de la sécurité de base qui ne concerne pas spécialement ton ou tes applications.

Tu peux aussi rajouter une identification/authentification pour pouvoir accéder aux applications.

Enfin, en ce qui concerne la fiabilité, bah, ça dépend surtout de ton code, et de la manière dont est configuré le serveur.

Amicalement,
merci @parsimonhi

La vraie question que je me pose c'est comment faire tourner le serveur en production?

un simple 'node mon-fichier.js' exécuté dans le terminal ou bien faut il procéder autrement?
Modérateur
lionel_css3 a écrit :
merci @parsimonhi

La vraie question que je me pose c'est comment faire tourner le serveur en production?

un simple 'node mon-fichier.js' exécuté dans le terminal ou bien faut il procéder autrement?


Et l'eau,

Il me semble avoir donné la solution.....

- ouvrir un service (daemon) avec systemD ou init.d (à moins que tu préfères la config apache en utilisant le mod_proxy et pm2 ==> j'ai pas testé) . Pour la déclaration du service, utiliser node et non nodemon. nodemon est surtout intéressant en developpement il me semble. Si tu utilises la commande nodemon pour initialiser ton deamon, tu vas avoir des comportements étranges.
- dans le html, pointer sur l'ip que node renvoie 192.168.5.55:8080 (enfin, tout dépend de l'outil utilisé). Là je parle de socket.io

Pour la sécurité, tout dépend de ce que tu utilises. Par exemple, avec Express, l'utilisation d'Helmet ne devrait pas être déconnant.
Modifié par niuxe (05 Nov 2020 - 08:58)
niuxe a écrit :


Et l'eau,

Il me semble avoir donné la solution.....

- ouvrir un service (daemon) avec systemD ou init.d (à moins que tu préfères la config apache en utilisant le mod_proxy et pm2 ==> j'ai pas testé) . Pour la déclaration du service, utiliser node et non nodemon. nodemon est surtout intéressant en developpement il me semble. Si tu utilises la commande nodemon pour initialiser ton deamon, tu vas avoir des comportements étranges.
- dans le html, pointer sur l'ip que node renvoie 192.168.5.55:8080 (enfin, tout dépend de l'outil utilisé). Là je parle de socket.io

Pour la sécurité, tout dépend de ce que tu utilises. Par exemple, avec Express, l'utilisation d'Helmet ne devrait pas être déconnant.


euh... j'y comprends rien....
Modérateur
Bonjour,

L'idée est d'utiliser ce qu'on appelle un démon, c'est à dire un programme qui tourne en permanence, et qui va démarrer (ou re-démarrer) ton script node.js lorsque c'est nécessaire.

Si tu trouves ça trop compliqué (de créer toi-même un démon, avec "systemD" ou "init.d"), tu peux essayer d'utiliser l'outil "forever" qui fera tout ça pour toi. Tu trouveras ci-joint la manière de l'installer et de le démarrer :
https://www.npmjs.com/package/forever

Une fois que c'est démarré, tu n'as plus à te préoccuper de ton script. S'il est arrêté pour une raison ou pour une autre, il sera re-démarré automatiquement. C'est l'idée principale. Et tu n'as pas besoin de laisser un terminal ouvert.

Après, y a tout un tas d'options et de commandes additionnelles qui te permettent de gérer l'ensemble (arrêter le script bien sûr, mais aussi consulter une log, etc.).

L'outil "pm2" suggéré par niuxe fait la même chose (comme niuxe, je ne le connais pas).

Amicalement,
De mémoire, le truc c'est que le serveur node de base est un serveur de test mais n'est pas assez robuste pour la prod'. C'est pour cela qu'en principe les dev's utilisent ngnix ou autre en prod' pour le web.
Modérateur
Olivier C a écrit :
De mémoire, le truc c'est que le serveur node de base est un serveur de test mais n'est pas assez robuste pour la prod'. C'est pour cela qu'en principe les dev's utilisent ngnix ou autre en prod' pour le web.


Non pas d'accord. Facebook / rbnb sont des exemples Smiley cligne Par contre, tu es quasiment obligé de cumuler avec apache ou nginx. Enfin tout dépend de ce que tu veux mettre en place.
Modifié par niuxe (07 Nov 2020 - 13:12)