---
title: Configurer un serveur NGINX
tags: backend, nginx, server
robots: noindex, nofollow
author: Julien Noyer
---
# Configurer un serveur NGINX
*Déployer une application Javascript avec un reverse-proxy*
> © [Julien Noyer](https://www.linkedin.com/in/julien-n-21219b28/) - All rights reserved for educational purposes only
---
## Introduction
NGINX est un logiciel libre de gestion de serveur Web ainsi qu'un proxy inverse écrit par Igor Sysoev, dont le développement a débuté en 2002 pour les besoins d'un site russe à très fort trafic. NGINX est un système asynchrone par opposition aux serveurs synchrones où chaque requête est traitée par un processus dédié.
Au lieu d'exploiter une architecture parallèle et un multiplexage temporel des tâches par le système d'exploitation, NGINX utilise les changements d'état pour gérer plusieurs connexions en même temps ; le traitement de chaque requête est découpé en de nombreuses mini-tâches et permet ainsi de réaliser un multiplexage efficace entre les connexions.
Afin de tirer parti des ordinateurs multiprocesseurs, plusieurs processus peuvent être démarrés. Ce choix d'architecture se traduit par des performances très élevées, mais également par une charge et une consommation de mémoire particulièrement faibles comparativement aux serveurs HTTP classiques, tels qu'Apache.
> Source Wikipedia, [en savoir plus](https://fr.wikipedia.org/wiki/NGINX)
## Solution d'hébergement
Les explications qui vont suivre sont basé sur l'utilisation des services [Digital Ocean](https://cloud.digitalocean.com) car ils présentent certaines options avantageuses au niveau de la gestion, comme la gestion de la montée en charge - la fameuse "scalabilité" - ou le fait de pouvoir sélectionner des serveurs européens qui permettent la mise en conformité avec la législation RGPD.
En revanche, il n'est pas obligatoire de choisir ce service pour suivre les explications de ce document, car elles définissent une mise en place classique qui est répercutable sur n'importe quel hébergeur.
---
# Configuration du Droplet (VPS) [Digital Ocean](https://cloud.digitalocean.com)
*Build Faster, Scale Easier. DigitalOcean's Optimized Droplets Saves Your Team Time*
## Sélection de l'offre Digital Ocean
L'outil proposé par [**Digital Ocean**](https://cloud.digitalocean.com) s'appelle un Droplet, il faut se rendre dans la section **Create > Droplet** du site qui permet de les configurer et de suivre les étapes. Pour ce tutorel la configuration suivante est utilsée :
- Distribution : Ubuntu 18.04.3 (LTS)x64
- Plan : 5 dollars/mo Standrad
- Datacenter : Amsterdam
- Authentication : One time passord
> Il est possible d'associer une clef SSH à votre [**VPS**](https://fr.wikipedia.org/wiki/Serveur_dédié_virtuel), nous conseillons de ne pas le faire pour pouvoir l'ajouter en ligne de commande pendant la configuration du serveur.
Une fois les étapes de configurations passées, un mail est envoyé par [**Digital Ocean**](https://cloud.digitalocean.com) contenant les informations pour se connecter au **Droplet** créé. Nous allons à présent utiliser ces identifiants pour nous connecter et configurer le **Droplet**.
## Première connexion au Droplet (VPS)
Comme dit précédemment peu importe l'hébergeur selectionner, les différentes commandes que nous allons utiliser sont applicables sur n'importe quel serveur [**Linux**](https://fr.wikipedia.org/wiki/Linux).
La connexion au serveur est faite en [**Secure Shell (SSH)**](https://fr.wikipedia.org/wiki/Secure_Shell) via un invite de commande avec la commande suivante :
```
ssh root@ip.du.droplet
```
Un message s'affiche alors dans le terminal vous demandant d'accepter la connexion au serveur :
```
The authenticity of host 'ip.du.droplet (ip.du.droplet)' can't be established.
ECDSA key fingerprint is SHA256:ucLbhJljBojqwF2c/py/GABOdltQo7c6N53B+VFL3ZU.
Are you sure you want to continue connecting (yes/no)?
```
Il faut accepter la connexion pour ensuite indiquer le mot de passe reçu par mail :
```
Warning: Permanently added 'ip.du.droplet' (ECDSA) to the list of known hosts.
root@ip.du.droplet's password:
```
À la première connexion sur le serveur avec l'identifiant **root**, il est demandé de changer le mot de passe. C'est une première étape de sécurité qui impose de ne pas garder le mot de passée généré par [**Digital Ocean**](https://cloud.digitalocean.com).
```
Changing password for root.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
```
> Les mots de passe ne s'affichent pas, il faut veiller à bien les renseigner.
Une fois la connexion établie sur le serveur il faut avant toute chose s'assurer qu'il est à jour en tapant les commandes suivantes :
```
sudo apt-get install software-properties-common
sudo apt-get update
apt-get upgrade
apt-get install
```
## Création du compte "admin"
Il va de soi que l'utilisation d'un compte nommé **root** est une faille de sécurité dans la mesure où il sera le premier à être testé dans le cadre d'une attaque. C'est pourquoi la première étape qu'il faut suivre dans la configuration d'un serveur distant et l'ajout d'un compte sudo et la suppression du compte **root**.
Pour créer un nouvel utilisateur, il faut taper les commandes suivantes :
```
adduser mainAdmin
usermod -aG sudo mainAdmin
su - mainAdmin
```
> C'est 3 commandes permettent de créer un profil, de l'ajouter au groupe `sudo` et de changer de profil utilisateur.
La dernière commande permettant de se changer de profil, il est à présent possible d'associer une clef [**SSH**](https://fr.wikipedia.org/wiki/Secure_Shell) au nouveau profil pour sécuriser la connexion au serveur avec cette utilisateur. Dans un premier temps il faut créer un dossier et un fichier pour enregister la clef sur le serveur :
```
mkdir ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
```
> La commande [**chmod**](https://fr.wikipedia.org/wiki/Chmod) permet de changer les droits en lectur/écriture sur un fichier ou un dossier.
La dernière commande ouvre l'éditeur [**Nano**](https://doc.ubuntu-fr.org/nano) dans lequel nous allons coller la clef [**SSH**](https://fr.wikipedia.org/wiki/Secure_Shell) de notre compte. Dans un autre invite de commande nous allons tous d'abord **créer une nouvelle clef si aucune n'est présente sur la machine** :
```
ssh-keygen -t rsa
```
> Surr Mac pout vérifier si une clef est présente sur une machine il faut téperr la commande `cat ~/.ssh/id_rsa.pub`.
Un message s'affiche demandant d'indiquer le chemin vers la clef `.../.ssh/id_rsa`, **attention car si une clef existe déjà elle sera remplacée**.
> L'ajout d'une `passphrase` est recommandé pour sécuriser la clef.
Nous pouvons maintenant copier la clef que nous venons de créer avec la commande suivante :
```
pbcopy < ~/.ssh/id_rsa.pub
```
Une fois la clef copiée il suffi de la coller dans la fenêtre [**Nano**](https://doc.ubuntu-fr.org/nano) ouverte précédemment pour l'associer au profil `mainAdmin` créé sur le serveur. Nous enregistrons le fichier puis nous modifions les permissions sur le dossier `.ssh` avec la commande suivante :
```
chmod 600 ~/.ssh/authorized_keys
```
> **NB** : les commandes présentées pour gérer les clefs SSH correspondent à l'OS Machintosh, si elles ne fonctionnent pas **pour Windows il est possbile d'utiliser [Putty](https://akril.net/cle-ssh-sous-windows-avec-putty/)**.
## Vérification du profil mainAdmin
Une fois l'utilisateur `mainAdmin` créé, il est primordial de s'assurer que la connexion SSH soit correctement configurer avant de passer aux étapes suivantes. **Tout en conservant la connexion avec le profil `root` actif**, nous ouvrons une nouvelle fenêtre d'invite de commande pour nous connecter à présent avec le profil `mainAdmin` :
```
ssh mainAdmin@ip.du.droplet
```
Lorsque la connexion est établie nous sommes à présent connecté au serveur avec le profil `mainAdmin`, nous testons à présent que nous sommes bien dans le groupe `sudo` avec la commande suivante :
```
sudo ls
```
Le mot de passe nous est demandé et une fois renseigné aucun message d'erreur ne n'affiche, la configuration est correct nous poouvons donc passer à l'étape suivante.
> **NB** : S'il y à un problème à l'une des étapes de vérification, il faut revoir soit vérifier la clef `ssh` soit le `chmod` du fichier `authorized_keys`.
## Gestion du profil root
Nous allons à présent bloquer la possibilité de s'identifier avec l'utilisateur `root` et nous allons imposer la connexion via clef SSH. Le fichier de configuration `sshd_config` nous permet de gérer les méthode de connexion :
```
sudo nano /etc/ssh/sshd_config
````
Dans ce fichier il faut changer les valeur de `PermitRootLogin` et `PasswordAuthentication` puis sauvegarder le fichier :
```
PermitRootLogin no
PasswordAuthentication no
```
Une fois la configuration modifier il faut redémarrer le service [**SSH**](https://fr.wikipedia.org/wiki/Secure_Shell) :
```
sudo service ssh restart
```
Il est à présent nécessaire de vérifier la configguration, il faut d'abord nous deconnecter pour ensuite relancer la connexion [**SSH**](https://fr.wikipedia.org/wiki/Secure_Shell) avec le nouveau compte :
```
ssh mainAdmin@ip.du.droplet
```
> **NB** : il ne faut surtout pas se déconnecter du profil `root` avant d'avoir vérifié la connexion `ssh` du profil `mainAdmin` au risque de ne plus pouvoir se reconnecter au serveur.
---
# Configuration du VPS pour NGINX
Une fois la problématique de connexion sur le [**VPS**](https://fr.wikipedia.org/wiki/Serveur_dédié_virtuel) passsée, nous pouvons à présent nous occuper d'installer les modules pour déployer notre site Internet ou notre application Web. Les dernières versions des **Droplets** [**Digital Ocean**](https://cloud.digitalocean.com) intégrent la commande [**Git**](https://git-scm.com), si ce n'est pas le cas, il faut l'installer aveec la commande :
```
sudo apt-get install git-all
```
> Cette commande vous permet également de mettre tous les outils [**Git**](https://git-scm.com) à jour.
## Installation et activation de NGINX
Avant d'installer NGINX nous devons nous assurer qu'aucune autre technologie serveur n'est installée sur le VPS, en l'occurence nous allons supprimer toute la configuration Apach2 en tapant les commmandes suivante :
```bash=
sudo service apache2 stop
sudo update-rc.d apache2 disable
sudo apt-get purge apache2
```
Afin d'utliser [**NGINX**](https://www.nginx.com) sur notre VPS, nous allons l'installer en tapant la commande suivante afin de configurer un [**reverse-proxy**](https://fr.wikipedia.org/wiki/NGINX) qui nous permettra de gérer les URLS de notre VPS :
```
sudo apt-get install nginx
```
Nous pouvons à présent activer [**NGINX**](https://www.nginx.com) et définir son comportement par defaut pour indiquer que nous redirigeons toutes les requêtes HTTP en HTTPS que nous configurerons plus tard avec [**LetsEncrypt**](https://letsencrypt.org/fr/).
Pour commencer nous ajoutons dans le fichier`default` la configuration de [**NGINX**](https://www.nginx.com) en l'ouvrant dans [**Nano**](https://doc.ubuntu-fr.org/nano) :
```
sudo nano /etc/nginx/sites-enabled/default
```
Une fois [**Nano**](https://doc.ubuntu-fr.org/nano) ouvert, nous remplaçons le code affiché par le suivant avant de fermer et d'enregistrer le fichier :
```
# HTTP — redirect all traffic to HTTPS
server {
listen 80;
listen [::]:80 default_server ipv6only=on;
return 301 https://$host$request_uri;
}
```
## Cryptage des requêtes HTTPS
Nous allons à présent crypter les requêtes grâce à la commande `dhparam` afin de gérer les reqêtes [**HTTPS**](https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure) :
```
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
```
Nous devons maintenant créer un fichier de configuration [**SSL**](https://fr.wikipedia.org/wiki/Transport_Layer_Security), afin de rendre les requêtes [**HTTPS**](https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure) valident. Pour cela nous crééons un fichier `ssl-params.conf` :
```
sudo nano /etc/nginx/snippets/ssl-params.conf
```
Et nous ajoutons le code suivant avant d'enregister le fichier :
```
# See https://cipherli.st/ for details on this configuration
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
# Add our strong Diffie-Hellman group
ssl_dhparam /etc/ssl/certs/dhparam.pem;
```
Pour finir la configuration de [**NGINX**](https://www.nginx.com) nous devons autoriser certains type de connexion avec les commandes suivantes :
```
sudo ufw allow OpenSSH
sudo ufw allow http
sudo ufw allow https
sudo ufw enable
```
## Valider la configuration NGINX
Nous pouvons à présent démarrer le service [**NGINX**](https://www.nginx.com) pour finir notre configuration, dans un premier temps nous devons redémarrer notre VPS :
```
sudo reboot
```
Il faut ensuite nous reconnecter pour lancer le service [**NGINX**](https://www.nginx.com) :
```
sudo systemctl start nginx
```
> La commande `sudo systemctl status nginx.service` permet de verifier le status de NGINX
---
# Publier un site ou une application statique
La configuration serveur que nous venons de réaliser permet d'héberger des fichiers statiques et de les rendre accessible via des URLs. Le projet que nous souhaitons publier n'est pas connecté à une base de données ni à un serveur NodeJS qui nous imposerait une configuration supplémentaire qui est définie plus bas dans ce document.
Nous considérons donc que vous disposez à cette étape d'un projet qui correspond à la définition ci-dessus, avant de continuer la lecture des étapes suivantes.
## Gestion des certificats [SSL](https://fr.wikipedia.org/wiki/Transport_Layer_Security)
Les certificats [**SSL**](https://fr.wikipedia.org/wiki/Transport_Layer_Security) nous permettent de configurer l'accés [**HTTPS**](https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure) à nos noms de domaines. Avant de commencer cette configuration sur le [**VPS**](https://fr.wikipedia.org/wiki/Serveur_dédié_virtuel) nous avons dans un premier temps acheté un nom dee domaine que nous avons fait pointé sur l'[**adresse IP**](https://fr.wikipedia.org/wiki/Adresse_IP) de notre **Droplet**.
Une fois le nom de domaine correctement configuré, nous devons dans un premier installer [**Certbot**](https://certbot.eff.org) pour générer les clef SSL :
```
sudo apt-get install certbot
sudo apt-get install python3-certbot-nginx
```
Puis nous lancons la commande qui permet de configurer une nouvelle URL en HTTPS :
```
sudo certbot certonly --standalone -d <nom.de.domaine>
```
> Nous pouvons renouveler les certificats à la main de cette façon `sudo certbot renew --nginx`.
Nous suivons les instruction de [**LetsEncrypt**](https://letsencrypt.org/fr/) pour nous identifier et une fois le nom de domaine enregistré un message de validation affiche l'endroit ou sont stockées les clef [**SSL**](https://fr.wikipedia.org/wiki/Transport_Layer_Security) :
```
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/<nom.de.domaine>/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/<nom.de.domaine>/privkey.pem
```
Les clef que nous venons de créer vont nous permettre à présent d'ajouter un fichier de configuration dans [**NGINX**](https://www.nginx.com) afin d'associer correctement les cleefs [**SSL**](https://fr.wikipedia.org/wiki/Transport_Layer_Security) à notre nom de domaine. Nous ouvons donc un nouuveau fichier dans [**Nano**](https://doc.ubuntu-fr.org/nano) :
```
sudo nano /etc/nginx/sites-enabled/<nom.de.domaine>
```
> Il est recommander de nommer le fichier par le nom de domaine.
Dans le fichier qui vient de s'ouvir nous collons le code suivant pour gérer les clef [**SSL**](https://fr.wikipedia.org/wiki/Transport_Layer_Security) pour ce nom de domaine :
```
# HTTPS proxy all requests to the Node app
server {
# Enable HTTP/2
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name <nom.de.domaine>;
# Use the LetsEncrypt certificates
ssl_certificate /etc/letsencrypt/live/<nom.de.domaine>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<nom.de.domaine>/privkey.pem;
# Include the SSL configuration from cipherli.st
include snippets/ssl-params.conf;
# Path to your static files
root /home/mainAdmin/project/project_name;
}
```
Nous prenons soins de bien modifier les informations pour qu'elles correspondent à notre configuration :
- **nom.de.domaine** : le domaine que nous avons fait poointer sur le serveur
Pour vérifier notre configuration [**NGINX**](https://www.nginx.com) nous tapons la commande `sudo nginx -t` qui noous affiche en résultat :
```
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
Notre configuration est à présent terminé, nous pouvons pour la finaliser et activer le nom de domaine sur notre VPS, redemmarer le service [**NGINX**](https://www.nginx.com) avec la commande suivante :
```
sudo systemctl start nginx.service
```
## Renouveler le certificat automatiquement avec [CertBot](https://certbot.eff.org)
Le certificat SSL que nous avons généré n'est valable que pour 90 jours, c'est à dire qu'il à besoin d'être renouveler avant la fin de cette prériode pour que notre nom de domaine conserve sa certification. Pour ne pas avoir à renouveler le certificat manuellement nous allons mettre en place un [CRON](https://fr.wikipedia.org/wiki/Cron) sur le serveur pour qu'il se renouvel automatiquement.
Pour gérer automatiquement la mise à jour des certificats, nous allons créer une tâche en CRON en tapant la commande suivante pour ouvrir le fichier `crontab` :
```
sudo crontab -e
```
> Il est demandé à cette étape de sélectionner un éditeur.
Puis nous ajoutons à la fin du fichier le code suivant :
```
# Certbot auto-renew
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 0 1 * * mainAdmin certbot -q renew --nginx
```
> Le code de renouvellement est exécuter le 1er de chaque mois.
Nous fermons et enregistrons le fichier `crontab` puis nous tapons la commande suivante pour testeer notre configuration :
```
sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/<nom.de.domaine>/cert.pem
```
Cette commande affiche la date du futur renouvellmement et nous pouvons a présent pour nous assurer que Nginx continue de fonctionner correctement en reedémarrant le service :
```
sudo systemctl restart nginx.service
```
## Déployer des fichiers statiques vers le VPS
La méthode la plus évidente pour déployer des fichiers d'une machine locale à un serveur distant, dans notre cas le VPS, est celle induite par la technologie serveur utilisée. Dans le cadre de notre VPS, nous avons configurer notre connexion via des cléfs SSH qui nous permet de sécuriser les échangent avec le serveur, nous allons donc utiliser le même principe pour déployer nos fichier.
## Déploiement via une répertoire Git
Si vous avez veillez à avoir un répertoire GitLab ou GitHub dans lequel se trouvent les fichiers que vous souhaitez déployer sur le VPS, il est possible de l'utiliser pour pourvoir directement faire un `pull` de la banche souhaitée depuis le VPS.
Il faut dans un premier temps créer le dossier dans lequel vous souhaitez déployer les fichiers sur le VPS, a l'adresse que nous avons défini dans le fichier de configuration du nom de domaine :
```
sudo mkdir /home/mainAdmin/project/project_name
```
Nous nous plaçons ensuite dans le dossier pour y configurer la gestion de Git :
```
cd /home/mainAdmin/project/project_name
sudo git init
sudo git remote add origin <URL_DU_REPO>
```
Une fois cette configuration terminée notre VPS est connecté à un répertoire Git distant, la mise à jour ce fait alors simplement avec la commande suite :
```
sudo git pull origin master
```
## Déploiement via un script sur la machine locale
Si vous avez utiliser un fichier `package.json` pour la configuration de votre projet (dans le cadre d'un développement avec un framework par exemple), vous pouvez y ajouter un script de déploiement afin de le faire directement en invite de commande.
Pour ce faire vous devez éditer le fichier `package.json` au niveau du tableau des scripts pour y ajouter le suivant :
```json=
"deploy": "scp -r ./path-to-project/ mainAdmin@<IP_DU_VPS>:/home/mainAdmin/project/project_name"
```
> Pensez à éditer `./path-to-project/` et `<IP_DU_VPS>` avant d'enregistrer le fichier.
Le déploiement ce fait alors simplememnt avec la commande suivante :
```bash=
npm run deploy
```
> Avant de déployer une nouvelle version vous devez d'abord supprimer le dossier `project_name` du VPS.
---
# Publier une application NodeJS
Nous allons aborder à présent la publication d'une application NodeJS sur notre VPS. Les principes sont différents de la publication d'un projet statique dans le mesure ou nous devons configurer la gestion d'un systeme d'information. En effet, un projet NodeJS s'oriente très souvent dans la mise en place d'une API connectée à une base de données NoSQL, c'est pourquoi les étapes qui vont suivre vous présente ces principes de bases que vous pourrez adapter à votre projet et que nous allons partir du principe que le système d'information choisi est [**MongoDB**](https://www.mongodb.com/fr).
## Installation des modules serveurs
Pour commencer nous allons installer les modules nous permettant d'utiliser un environement - [**Javascrip**](https://developer.mozilla.org/fr/docs/Web/JavaScript) sur notre serveur, à savoir [NodeJS](https://nodejs.org/en/) avec les commandes suivantes :
```
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -
sudo apt-get install nodejs
```
## Activation du service [MongoDB](https://www.mongodb.com/fr)
Nous allons à présent installer [**MongoDB**](https://www.mongodb.com/fr) qui nous permettra de gérer les données de notre application NodeJS :
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927
echo "deb http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list
sudo apt-get install -y mongodb
```
Pour configurer [**MongoDB**](https://www.mongodb.com/fr) en tant que service nous allons créer un fichier qui nous permettra de le configurer :
```
sudo nano /etc/systemd/system/mongodb.service
```
Nous allons coller le code suivant avant d'enrigistrer le fichier :
```
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
[Service]
User=mongodb
ExecStart=/usr/bin/mongod --quiet --config /etc/mongod.conf
[Install]
WantedBy=multi-user.target
```
Nous pouvons à présent lancer le service [**MongoDB**](https://www.mongodb.com/fr) avec la commande suivante :
```
sudo systemctl start mongodb
```
> Pour vérifier le statut du service il faut taper la commande `sudo systemctl status mongodb`.
## Déployer l'application NodeJS sur le VPS
Les méthodes de déploiement vers le VPS sont les mêmes que celles évoquées au point [Déploiement via une répertoire Git](#Déploiement-via-une-répertoire-Git), bien que vous êtes libre de créer un script de déploiement. Nous préférons utiliser cette méthode car elle nous permet de concerver la logique de Git sur le VPS, ce qui peut s'avérer utile pour réaliser des modifications directement sur le VPS.
Nous partons donc du principe que votre application NodeJS est présente dans le VPS dans le dossier que vous aurez défini pour l'héberger.
> Il est fortement déconseillé de placer l'application NodeJS dans le dossier `home`.
La différence majeur pour publier une application NodeJS se trouve dans la gestion du nom de domaine, car contrairement à un projet statique, une application NodeJS fonctionne sur le principe d'un serveur, c'est pourquoi la configuration du nom de domaine doit intégrer la gestion d'un port.
Pour ajouter un nom de domaine la commande CertBot reste la même :
```
sudo certbot --nginx -d <nom.de.domaine>
```
Mais pour configurer le nom de domaine, au lieu de configurer le dossier `root` il faut configurer la `location` de la manière suivante :
```
# HTTPS proxy all requests to the Node app
server {
# Enable HTTP/2
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name <nom.de.domaine>;
# Use the LetsEncrypt certificates
ssl_certificate /etc/letsencrypt/live/<nom.de.domaine>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<nom.de.domaine>/privkey.pem;
# Include the SSL configuration from cipherli.st
include snippets/ssl-params.conf;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://localhost:<port>/;
proxy_ssl_session_reuse off;
proxy_set_header Host $http_host;
proxy_cache_bypass $http_upgrade;
proxy_redirect off;
}
}
```
Nous prenons soins de bien modifier les informations pour qu'elles correspondent à notre configuration :
- **nom.de.domaine** : le domaine que nous avons fait poointer sur le serveur
- **port** : le port qui corrrespond à notre application
Pour vérifier notre configuration [**NGINX**](https://www.nginx.com) nous tapons la commande `sudo nginx -t` qui noous affiche en résultat :
```
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
## Activation du service [**PM2**](https://pm2.keymetrics.io)
Le module [**PM2**](https://pm2.keymetrics.io) permet d'écouter l'activité du VPS pour capter le moment ou il est relancé, ce qui arrive très souvent pour des raisons de maintenance par exemple. Nous allons donc utiliser `npm` que nous avons intallé plus haut pour installer ce module en global sur le VPS :
```
sudo npm i -g pm2
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
```
Nous allons à présent configurer [**PM2**](https://pm2.keymetrics.io) pour qu’il puisse redémarrer automatiquement nos application NodeJS en cas de redémarage du VPS :
```
pm2 startup systemd
```
Cette dernière commande permet d’afficher un code à taper pour valider la configuration qui ressemble au code suivant :
```
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u dws --hp /home/adminuser
```
Tout est prêt sur notre VPS pour configurer un nom de domaine en [**HTTPS**](https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure) qui pointee sur un port spécifique. Nous allons donc à présent utiliser [**PM2**](https://pm2.keymetrics.io) pour lancer notre application NodeJS en tapant la commande suivante dans le dossier racine de notre application :
```
pm2 start server.js --name APPname
```
---
## Ressources
> La liste ci-dessous contient les liens utiles cité dans ce document
- **Javascrip** https://developer.mozilla.org/fr/docs/Web/JavaScript
- **VPS** https://fr.wikipedia.org/wiki/Serveur_dédié_virtuel
- **Git** https://git-scm.com
- **GitHub** https://github.com
- **Commande sudo** https://fr.wikipedia.org/wiki/Sudo
- **Digital Ocean** https://cloud.digitalocean.com
- **GitHub Education** https://education.github.com
- **Linux** https://fr.wikipedia.org/wiki/Linux
- **Secure Shell (SSH)** https://fr.wikipedia.org/wiki/Secure_Shell
- **Nano** https://doc.ubuntu-fr.org/nano
- **PM2** https://pm2.keymetrics.io
- **LetsEncrypt** https://letsencrypt.org/fr/
- **Certbot** https://certbot.eff.org
- **MongoDB** https://www.mongodb.com/fr
- **Express.js** http://expressjs.com/fr/
- **Angular.io** https://angular.io/
- **Node.js** https://nodejs.org/en/docs/
- **NGINX** https://www.nginx.com
- **CRON** https://fr.wikipedia.org/wiki/Cron
- **reverse-proxy** https://fr.wikipedia.org/wiki/NGINX
- **HTTPS** https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure
- **SSL** https://fr.wikipedia.org/wiki/Transport_Layer_Security
- **Adresse IP** https://fr.wikipedia.org/wiki/Adresse_IP
- **Commande chmod** https://fr.wikipedia.org/wiki/Chmod
- **chmod** https://fr.wikipedia.org/wiki/Chmod
Sign in with Wallet
Connect another wallet