One place for hosting & domains

      serveur

      Comment utiliser SSH pour se connecter à un serveur distant


      Introduction

      L’un des outils essentiels à maîtriser en tant qu’administrateur système est le SSH.

      SSH, ou Secure Shell, est un protocole utilisé pour se connecter en toute sécurité à des systèmes distants. C’est le moyen le plus courant d’accéder à des serveurs Linux distants.

      Dans ce guide, nous verrons comment utiliser SSH pour se connecter à un système distant.

      Syntaxe de base

      Pour se connecter à un système distant utilisant SSH, nous utiliserons la commande ssh.  La forme la plus élémentaire de la commande est :

      Le remote_host dans cet exemple est l'adresse IP ou le nom de domaine auquel vous essayez de vous connecter.

      Cette commande suppose que votre nom d'utilisateur sur le système distant est le même que votre nom d'utilisateur sur votre système local.

      Si votre nom d'utilisateur est différent sur le système distant, vous pouvez le spécifier en utilisant cette syntaxe :

      • ssh remote_username@remote_host

      Une fois que vous vous êtes connecté au serveur, il peut vous être demandé de vérifier votre identité en fournissant un mot de passe. Plus tard, nous verrons comment générer des clés à utiliser à la place des mots de passe.

      Pour quitter la session ssh et revenir dans votre session shell locale, tapez :

      SSH fonctionne en connectant un programme client à un serveur ssh, appelé sshd.

      Dans la section précédente, ssh était le programme client. Le serveur ssh fonctionne déjà sur le remote_host que nous avons spécifié.

      Sur votre serveur, le sshd devrait déjà fonctionner. Si ce n'est pas le cas, vous devrez peut-être accéder à votre serveur via une console Web ou une console série locale.

      Le processus nécessaire pour démarrer un serveur ssh dépend de la distribution de Linux que vous utilisez.

      Sur Ubuntu, vous pouvez démarrer le serveur ssh en tapant :

      Cela devrait démarrer le serveur sshd et vous pourrez alors vous connecter à distance.

      Lorsque vous modifiez la configuration de SSH, vous modifiez les paramètres du serveur sshd.

      Dans Ubuntu, le fichier de configuration principal de sshd se trouve à /etc/ssh/sshd_config.

      Sauvegardez la version actuelle de ce fichier avant de l'éditer :

      • sudo cp /etc/ssh/sshd_config{,.bak}

      Ouvrez-le avec un éditeur de texte :

      • sudo nano /etc/ssh/sshd_config

      Il est préférable de laisser de côté la plupart des options de ce dossier. Cependant, il y en a quelques-uns que vous voudrez peut-être examiner :

      /etc/ssh/sshd_config

      Port 22
      

      La déclaration de port précise sur quel port le serveur sshd écoutera les connexions. Par défaut, il s'agit de 22. Vous devriez probablement ne pas toucher à ce paramètre, à moins que vous n'ayez des raisons spécifiques de faire autrement. Si vous **changez de port, nous vous montrerons comment vous connecter au nouveau port par la suite.

      /etc/ssh/sshd_config

      HostKey /etc/ssh/ssh_host_rsa_key
      HostKey /etc/ssh/ssh_host_dsa_key
      HostKey /etc/ssh/ssh_host_ecdsa_key
      

      Les déclarations de clés d'hôtes précisent où chercher les clés d'hôtes globales. Nous discuterons plus tard de ce qu'est une clé d'hôte.

      /etc/ssh/sshd_config

      SyslogFacility AUTH
      LogLevel INFO
      

      Ces deux éléments indiquent le niveau connexion qui devrait avoir lieu.

      Si vous avez des difficultés avec SSH, augmenter le nombre de connexions peut être un bon moyen de découvrir quel est le problème.

      /etc/ssh/sshd_config

      LoginGraceTime 120
      PermitRootLogin yes
      StrictModes yes
      

      Ces paramètres précisent certaines des informations de connexion.

      LoginGraceTime précise combien de secondes pour maintenir la connexion active sans se connecter avec succès.

      Il peut être judicieux de fixer ce temps juste un peu plus élevé que le temps qu'il vous faut pour vous connecter normalement.

      PermitRootLogin sélectionne si le root user est autorisé à se connecter.

      Dans la plupart des cas, il faut passer à no lorsque vous avez créé un compte d'utilisateur qui a accès à des privilèges élevés (via su ou sudo) et peut se connecter via ssh.

      strictModes est un garde de sécurité qui refusera une tentative de connexion si les fichiers d'authentification sont lisibles par tous.

      Cela permet d'éviter les tentatives de connexion lorsque les fichiers de configuration ne sont pas sécurisés.

      /etc/ssh/sshd_config

      X11Forwarding yes
      X11DisplayOffset 10
      

      Ces paramètres configurent une capacité appelée X11 Forwarding. Cela vous permet de visualiser l'environnement graphique (GUI) d'un système distant sur le système local.

      Cette option doit être activée sur le serveur et donnée avec le client SSH lors de la connexion avec l'option -X.

      Après avoir effectué vos modifications, enregistrez et fermez le fichier en tapant CTRL+X et Y, puis ENTER.

      Si vous avez modifié des paramètres dans /etc/ssh/sshd_config, veillez à recharger votre serveur sshd afin de mettre en œuvre vos modifications :

      • sudo systemctl reload ssh

      Vous devez tester vos changements de manière approfondie pour vous assurer qu'ils fonctionnent comme prévu.

      Il peut être judicieux d'avoir quelques séances actives lorsque vous effectuez des changements. Cela vous permettra de revenir sur la configuration si nécessaire.

      S'il est utile de pouvoir se connecter à un système à distance à l'aide de mots de passe, il est bien plus judicieux de mettre en place une authentification par clé.

      L'authentification par clé fonctionne en créant une paire de clés : une clé privée et une clé publique.

      La clé privée se trouve sur la machine du client et est sécurisée et gardée secrète.

      La clé publique peut être donnée à n'importe qui ou placée sur n'importe quel serveur auquel vous souhaitez accéder.

      Lorsque vous tentez de vous connecter à l'aide d'une paire de clés, le serveur utilise la clé publique pour créer un message pour l'ordinateur client qui ne peut être lu qu'avec la clé privée.

      L'ordinateur client renvoie alors la réponse appropriée au serveur et celui-ci saura que le client est légitime.

      Tout ce processus se fait automatiquement après l'installation des clés.

      Les clés SSH doivent être générées sur l'ordinateur duquel vous souhaitez vous connecter**. Il s'agit généralement de votre machine locale.

      Entrez ce qui suit dans la ligne de commande :

      Appuyez sur la touche Entrée pour accepter les valeurs par défaut. Vos clés seront créées à l'adresse ~/.ssh/id_rsa.pub et ~/.ssh/id_rsa.

      Passez dans le répertoire .ssh en tapant :

      Regardez les autorisations des fichiers :

      Output

      -rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys -rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa -rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub

      Comme vous pouvez le voir, le fichier id_rsa est lisible et accessible en écriture uniquement au propriétaire.  C'est pour cela qu'il doit être gardé secret.

      Le fichier id_rsa.pub, cependant, peut être partagé et dispose de permissions appropriées pour cette activité.

      Si vous avez actuellement un accès par mot de passe à un serveur, vous pouvez y copier votre clé publique en émettant cette commande :

      Cela permettra de démarrer une session SSH. Après que vous ayez entré votre mot de passe, il copiera votre clé publique dans le fichier des clés autorisées du serveur, ce qui vous permettra de vous connecter sans mot de passe la prochaine fois.

      Options côté client

      Il existe un certain nombre d'indicateurs optionnels que vous pouvez sélectionner lorsque vous vous connectez via SSH.

      Certains d'entre eux peuvent être nécessaires pour correspondre aux paramètres de la configuration sshd de l'hôte distant.

      Par exemple, si vous avez changé le numéro de port dans votre sshd, vous devrez faire correspondre ce port côté client en tapant :

      • ssh -p port_number remote_host

      Si vous ne souhaitez exécuter qu'une seule commande sur un système distant, vous pouvez la spécifier après l'hôte comme cela :

      • ssh remote_host command_to_run

      Vous vous connecterez à la machine distante, vous vous authentifierez, et la commande sera exécutée.

      Comme nous l'avons déjà dit, si la transmission X11 est activée sur les deux ordinateurs, vous pouvez accéder à cette fonctionnalité en tapant :

      Si vous disposez des outils appropriés sur votre ordinateur, les programmes de l'environnement graphique que vous utilisez sur le système distant ouvriront désormais leur fenêtre sur votre système local.

      Désactiver l'authentification par mot de passe

      Si vous avez créé des clés SSH, vous pouvez renforcer la sécurité de votre serveur en désactivant l'authentification uniquement par mot de passe. En dehors de la console, la seule façon de se connecter à votre serveur est d'utiliser la clé privée qui se couple avec la clé publique que vous avez installée sur le serveur.

      Avertissement : Avant de procéder à cette étape, assurez-vous que vous avez installé une clé publique pour votre serveur. Sinon, vous serez bloqué à l'extérieur !

      En tant que root ou utilisateur avec des privilèges sudo, ouvrez le fichier de configuration sshd :

      • sudo nano /etc/ssh/sshd_config

      Localisez la ligne qui indique Password Authenticationet la décommenter en supprimant le premier #. Vous pouvez alors changer sa valeur à no :

      /etc/ssh/sshd_config

      PasswordAuthentication no
      

      Deux autres paramètres qui ne devraient pas avoir à être modifiés (à condition que vous n'ayez pas modifié ce fichier auparavant) sont PubkeyAuthentification et ChallengeResponseAuthentification. Elles sont définies par défaut et doivent se lire comme suit :

      /etc/ssh/sshd_config

      PubkeyAuthentication yes
      ChallengeResponseAuthentication no
      

      Après avoir effectué vos modifications, enregistrez et fermez le fichier.

      Vous pouvez maintenant recharger le démon SSH :

      • sudo systemctl reload ssh

      L'authentification par mot de passe devrait maintenant être désactivée, et votre serveur ne devrait être accessible que via l'authentification par clé SSH.

      Conclusion

      Apprendre à s'orienter au sein de SSH en vaut la peine, ne serait-ce que parce c'est un processus de routine.

      Au fur et à mesure que vous utiliserez les différentes options, vous découvrirez des fonctionnalités plus avancées qui peuvent vous faciliter la vie. SSH est resté populaire parce qu'il est sûr, léger et utile dans diverses situations.



      Source link

      Comment utiliser SFTP pour transférer des fichiers en toute sécurité avec un serveur distant


      Introduction

      FTP, ou « File Transfer Protocol » (protocole de transfert de fichiers) était une méthode non cryptée populaire utilisée pour transérer des fichiers entre deux systèmes distants.

      SFTP, qui signifie SSH File Transfer Protocol (protocole de transfert de fichiers SSH ou protocole de transfert de fichiers sécurisé) est un protocole distinct intégrant SSH, qui fonctionne de manière similaire mais via une connexion sécurisée. Il présente l’avantage de pouvoir tirer parti d’une connexion sécurisée pour transférer des fichiers et traverser le système de fichiers à la fois sur le système local et sur le système distant.

      Dans la plupart des cas, il est préférable d’utiliser le SFTP au lieu du FTP, en raison de ses fonctionnalités de sécurité sous-jacentes et de sa capacité à se greffer sur une connexion SSH. FTP est un protocole non sécurisé qui ne doit être utilisé que dans certains cas ou sur des réseaux de confiance.

      Bien que le SFTP soit intégré à de nombreux outils graphiques, ce guide vous expliquera de quelle manière l’utiliser via son interface de ligne de commande interactive.

      SFTP utilise le protocole SSH par défaut pour s’authentifier et établir une connexion sécurisée. Pour cette raison, les mêmes méthodes d’authentification que celles présentes dans SSH sont mises à disposition.

      Bien que les mots de passe soient faciles à utiliser et configurés par défaut, nous vous recommandons de créer des clés SSH et de transférer votre clé publique à tous les systèmes auxquels vous devez accéder. Cette méthode est bien plus sécurisée et vous permet de gagner du temps sur le long terme.

      Veuillez vous reporter à ce guide pour configurer des clés SSH et accéder ainsi à votre serveur, si vous ne l’avez pas encore fait.

      Si vous arrivez à vous connecter à la machine en utilisant SSH, cela signifie que vous avez rempli toutes les conditions requises pour gérer les fichiers à l’aide de SFTP. Testez l’accès à SSH à l’aide de la commande suivante :

      • ssh sammy@your_server_ip_or_remote_hostname

      Si cela fonctionne, ressortez en saisissant :

      Désormais, nous pouvons établir une session SFTP en émettant la commande suivante :

      • sftp sammy@your_server_ip_or_remote_hostname

      Votre connexion au système distant sera établie et votre invite se transformera en une invite SFTP.

      Si vous travaillez sur un port SSH personnalisé (et non pas sur le port 22 par défaut), vous pouvez alors ouvrir une session SFTP de la manière suivante  :

      • sftp -oPort=custom_port sammy@your_server_ip_or_remote_hostname

      Ceci établira votre connexion au système distant via le port que vous avez spécifié.

      Obtenir de l'aide dans SFTP

      La commande la plus utile que vous devez apprendre à utiliser en premier est la commande d'aide. Elle vous permet d'accéder à un résumé de l'aide de SFTP. Vous pouvez l'appeler en saisissant l'une ou l'autre des options suivantes dans l'invite :

      ou

      Une liste des commandes disponibles s'affichera :

      Output

      Available commands: bye Quit sftp cd path Change remote directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' df [-hi] [path] Display statistics for current directory or filesystem containing 'path' exit Quit sftp get [-Ppr] remote [local] Download file help Display this help text lcd path Change local directory to 'path' . . .

      Nous allons explorer certaines des commandes que vous allez aborder dans les sections suivantes.

      Un certain nombre de commandes qui fonctionnement de la même manière que leurs homologues shell nous permettent de naviguer dans la hiérarchie de fichiers du système distant.

      Tout d'abord, cherchons à savoir dans quel répertoire du système distant nous nous trouvons actuellement. Tout comme dans une session shell type, nous pouvons saisir ce qui suit pour obtenir le répertoire actuel :

      Output

      Remote working directory: /home/demouser

      Nous pouvons consulter le contenu du répertoire actuel du système distant à l'aide d'une autre commande commune :

      Output

      Summary.txt info.html temp.txt testDirectory

      Notez que les commandes de l'interface SFTP ne sont pas similaires aux commandes shell normales et ne sont pas aussi riches en fonctionnalités. Elles permettent cependant d'implémenter certaines des balises optionnelles les plus importantes :

      Output

      drwxr-xr-x 5 demouser demouser 4096 Aug 13 15:11 . drwxr-xr-x 3 root root 4096 Aug 13 15:02 .. -rw------- 1 demouser demouser 5 Aug 13 15:04 .bash_history -rw-r--r-- 1 demouser demouser 220 Aug 13 15:02 .bash_logout -rw-r--r-- 1 demouser demouser 3486 Aug 13 15:02 .bashrc drwx------ 2 demouser demouser 4096 Aug 13 15:04 .cache -rw-r--r-- 1 demouser demouser 675 Aug 13 15:02 .profile . . .

      Pour accéder à un autre répertoire, nous pouvons lancer la commande suivante :

      Maintenant que nous pouvons traverser le système de fichiers distant, qu'en est-il si nous devons accéder à notre système de fichiers local ? Nous pouvons diriger les commandes vers le système de fichiers local en les faisant précéder d'un l pour local.

      Toutes les commandes abordées jusqu'à maintenant disposent d'équivalents en local. Nous pouvons imprimer le répertoire de travail local :

      Output

      Local working directory: /Users/demouser

      Nous pouvons lister le contenu du répertoire actuel sur la machine locale :

      Output

      Desktop local.txt test.html Documents analysis.rtf zebra.html

      Nous pouvons également changer le répertoire avec lequel nous souhaitons interagir sur le système local :

      Transférer des fichiers avec SFTP

      L'utilité de la navigation dans les systèmes de fichiers distants et locaux reste limitée si nous ne pouvons pas transférer des fichiers entre les deux.

      Transférer des fichiers distants vers le système local

      Pour télécharger des fichiers à partir de notre hébergement local, vous pouvez passer la commande suivante :

      Output

      Fetching /home/demouser/remoteFile to remoteFile /home/demouser/remoteFile 100% 37KB 36.8KB/s 00:01

      Comme vous pouvez le voir, par défaut, la commande get télécharge un fichier distant vers un fichier qui porte le même nom sur le système de fichiers local.

      Nous pouvons copier le fichier distant en utilisant un autre nom, en spécifiant le nom par la suite :

      La commande get prend également en charge quelques balises d'option. Par exemple, nous pouvons copier un répertoire et l'intégralité de son contenu en spécifiant l'option récursive suivante :

      Nous pouvons dire au SFTP de maintenir les autorisations et les temps d'accès appropriés en utilisant la balise -P ou -p :

      Transférer des fichiers locaux vers le système distant

      Il est tout aussi facile de transférer des fichiers vers le système distant en utilisant la commande qui s'appelle, à juste titre, « put » :

      Output

      Uploading localFile to /home/demouser/localFile localFile 100% 7607 7.4KB/s 00:00

      Les mêmes balises que celles qui fonctionnent avec get s'appliquent à put. Donc, si vous souhaitez copier un répertoire local entier, vous pouvez lancer la commande suivante :

      Remarque: il existe actuellement un bogue dans les versions d'OpenSSH intégrant les versions actuelles d'Ubuntu (au moins 14.04 à 15.10), ce qui empêche la commande ci-dessus de fonctionner correctement. Une fois la commande ci-dessus lancée pour transférer le contenu vers un serveur en utilisant la version avec bogue d'OpenSSH, l'erreur suivante apparaîtra : Couldn't canonicalise: No such file or directory (Impossible à canonicaliser : pas de fichier ou de répertoire de ce type).

      Pour résoudre ce problème, créez le répertoire de destination tout d'abord du côté distant en saisissant mkdir localDirectory. Ensuite, la commande ci-dessus devrait s'exécuter sans erreur.

      La commande df est un outil pratique, communément utilisé pour télécharger et envoyer des fichiers. Elle fonctionne de la même manière que la version avec ligne de commande. Grâce à elle, vous pouvez vérifier si vous disposez d'assez d'espace pour procéder aux transferts que vous souhaitez effectuer :

      Output

      Size Used Avail (root) %Capacity 19.9GB 1016MB 17.9GB 18.9GB 4%

      Notez qu'il n'existe pas de variation locale de cette commande, mais nous pouvons contourner cela en émettant la commande ! .

      La commande ! nous amène dans un shell local, où nous pouvons exécuter toute commande disponible sur notre système local. Nous pouvons vérifier l'utilisation du disque en saisissant :

      et puis

      Output

      Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 595Gi 52Gi 544Gi 9% / devfs 181Ki 181Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home

      Toute autre commande locale fonctionnera comme prévu. Pour revenir à votre session SFTP, saisissez :

      Maintenant, vous devriez voir apparaître l'invite SFTP.

      Manipulations simples de fichiers avec SFTP

      SFTP vous permet d'effectuer le type de maintenance de base sur les fichiers qui vous est utile lorsque vous travaillez avec des hiérarchies de fichiers.

      Par exemple, vous pouvez modifier le propriétaire d'un fichier sur le système distant en utilisant :

      À la différence de la commande chmod du système, vous remarquerez que la commande SFTP n'accepte pas les noms d'utilisateur, mais utilise des UID à la place. Malheureusement, il n'existe aucun moyen facile de connaître l'UID correspondant à partir de l'interface SFTP.

      Vous pourriez contourner le problème avec :

      • get /etc/passwd
      • !less passwd

      Output

      root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh . . .

      Notez qu'au lieu d'utiliser la commande ! proprement dite, nous l'avons utilisée comme préfixe pour une commande shell locale. Cette méthode fonctionne pour exécuter toute commande disponible sur notre machine locale, et aurait pu être utilisée avec la commande df locale que nous avons abordée précédemment.

      L'UID se trouvera dans la troisième colonne du fichier, délimitée par des deux-points.

      De la même façon, nous pouvons modifier le propriétaire de groupe d'un fichier en utilisant :

      Encore une fois, il n'existe aucun moyen facile d'obtenir une liste des groupes du système distant. Nous pouvons le faire avec la commande suivante :

      • get /etc/group
      • !less group

      Output

      root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . .

      La troisième colonne contient l'ID du groupe associé au nom de la première colonne. C'est ce que nous voulons.

      Heureusement, la commande chmod fonctionne comme prévu sur le système de fichiers distant :

      Output

      Changing mode on /home/demouser/publicFile

      Il n'existe aucune commande pour manipuler les autorisations des fichiers locaux, mais vous pouvez configurer l'umask local de manière à ce que tous les fichiers copiés sur le système local disposent des autorisations correspondantes.

      Pour cela, vous pouvez utiliser la commande lumask :

      Output

      Local umask: 022

      Maintenant, tous les fichiers réguliers téléchargés (sous réserve que la balise -p ne soit pas utilisée) auront 644 autorisations.

      SFTP vous permet de créer des répertoires sur des systèmes locaux et distants avec lmkdir et mkdir, respectivement. Ces commandes fonctionnent comme prévu.

      Le reste des commandes de fichier cible uniquement le système de fichiers distant :

      Ces commandes répliquent le comportement de base des versions shell. Si vous devez effectuer ces actions sur le système de fichiers local, n'oubliez pas que vous pouvez vous connecter à un shell en lançant la commande suivante :

      Ou exécutez une seule commande sur le système local en faisant précédant la commande d'un ! comme suit :

      Une fois que vous en aurez terminé avec votre session SFTP, utilisez exit ou bye pour mettre fin à la connexion.

      Conclusion

      Bien que SFTP soit un outil simple, il est très utile pour gérer des serveurs et transférer des fichiers entre eux.

      Par exemple, vous pouvez utiliser SFTP pour permettre à certains utilisateurs de transférer des fichiers sans accès SSH. Pour de plus amples informations sur ce processus, veuillez consulter notre tutoriel How To Enable SFTP Without Shell Access (Comment activer le SFTP sans accès au shell).

      Si vous avez l'habitude d'utiliser FTP ou SCP pour effectuer vos transferts, SFTP est un bon compromis pour pouvoir tirer parti des avantages que les deux ont à offrir. Bien qu'il ne soit pas adapté à toute situation, c'est un outil flexible à avoir dans votre répertoire.



      Source link

      Comment activer le rendu côté serveur d’une app React


      Introduction

      Le rendu côté serveur (SSR) est une technique couramment utilisée pour obtenir un rendu d’une application simple page (SPA) côté client sur le serveur et que cette page soit renvoyée au client avec un rendu complet. Cette technique permet de présenter les composants dynamiques sous forme de balise HTML.

      Cette approche peut vous être utile dans le cadre de l’optimisation des moteurs de recherche (SEO) lorsque l’indexation ne traite pas correctement JavaScript. Elle peut également s’avérer être très pratique si la lenteur du réseau vient altérer le téléchargement d’un grand paquet JavaScript.

      Au cours de ce tutoriel, vous allez initialiser une app React en utilisant Create React App. Ensuite, vous modifierez le projet pour activer le rendu côté serveur.

      À la fin de ce tutoriel, vous disposerez d’un projet actif avec une application React côté client et une application Express côté serveur.

      Remarque : vous pouvez également envisager d’utiliser l’approche moderne proposée par Next.js qui vous permet de créer des applications statiques et serveurs développées avec React.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Les vérifications effectuées sur ce tutoriel ont été réalisées avec Node v14.4.0 et npm v6.14.5.

      Étape 1 — Création de l’app React et modification du composant de l’app

      Dans un premier lieu, nous allons utiliser npx pour lancer une nouvelle app React en utilisant la dernière version de Create React App.

      Appelons notre app my-ssr-app :

      • npx create-react-app@3.4.1 my-ssr-app

      Ensuite, nous la copions (cd) dans le nouveau répertoire :

      cd my-ssr-app
      

      Pour finir, nous pouvons lancer notre nouvelle app côté client afin d’en vérifier l’installation :

      Vous devriez voir apparaître un exemple d'affichage de l'app React dans la fenêtre de votre navigateur.

      Maintenant, créons un composant <Home> :

      Ensuite, ajoutons le code suivant au fichier Home.js :

      src/Home.js

      import React from 'react';
      
      export default props => {
        return <h1>Hello {props.name}!</h1>;
      };
      

      Cela créera un titre <h1> accompagné d'un message « Bonjour » adressé à un nom.

      Ensuite, nous allons permettre le rendu de <Home> dans le composant <App>. Ouvrez le fichier App.js :

      Maintenant, remplacez les lignes de code existantes par les nouvelles lignes de code suivantes :

      src/App.js

      import React from 'react';
      import Home from './Home';
      
      export default () => {
        return <Home name="Sammy" />;
      };
      

      Cela transmet un name au composant <Home> de manière à ce que le message suivant s'affiche  :« Bonjour Sammy ! ».

      Dans le fichier index.js de notre app, nous allons utiliser la méthode d’hydratation de ReactDOM au lieu du rendu. Nous indiquons ainsi au moteur de rendu DOM que nous allons réhydrater l'app une fois qu'un rendu sera obtenu côté serveur.

      Ouvrez le fichier index.js :

      Ensuite, remplacez le contenu du fichier index.js par le code suivant :

      index.js

      import React from 'react';
      import ReactDOM from 'react-dom';
      import App from './App';
      
      ReactDOM.hydrate(<App />, document.getElementById('root'));
      

      Vous venez de terminer la configuration côté client. Nous pouvons maintenant passer à celle du côté serveur.

      Étape 2 — Création d'un serveur Express et rendu du composant de l'app

      Maintenant que notre app est installée, créons un serveur qui enverra une version rendue. Nous utiliserons Express for our server. Ajoutez-le au projet en saisissant la commande suivante dans la fenêtre de votre terminal :

      • npm install express@4.17.1

      Ou, en utilisant yarn :

      Maintenant, créez un répertoire server à côté du répertoire src de l'app :

      Créez un nouveau fichier index.js qui contiendra le code du serveur Express :

      Ajoutez les importations nécessaires et définissez les quelques constantes suivantes :

      server/index.js

      import path from 'path';
      import fs from 'fs';
      
      import React from 'react';
      import express from 'express';
      import ReactDOMServer from 'react-dom/server';
      
      import App from '../src/App';
      
      const PORT = process.env.PORT || 3006;
      const app = express();
      

      Ensuite, ajoutez le code du serveur avec un traitement des erreurs :

      server/index.js

      // ...
      
      app.get('/', (req, res) => {
        const app = ReactDOMServer.renderToString(<App />);
      
        const indexFile = path.resolve('./build/index.html');
        fs.readFile(indexFile, 'utf8', (err, data) => {
          if (err) {
            console.error('Something went wrong:', err);
            return res.status(500).send('Oops, better luck next time!');
          }
      
          return res.send(
            data.replace('<div id="root"></div>', `<div id="root">${app}</div>`)
          );
        });
      });
      
      app.use(express.static('./build'));
      
      app.listen(PORT, () => {
        console.log(`Server is listening on port ${PORT}`);
      });
      

      Comme vous le voyez, nous pouvons importer notre composant <App> de l'app client directement depuis le serveur.

      Il se passe trois choses importantes à ce stade :

      • Nous indiquons à Express de desservir le contenu du répertoire build sous forme de fichiers statiques.
      • Nous utilisons une méthode de ReactDOMServer, renderToString pour obtenir un rendu de notre app sur une chaîne HTML statique.
      • Ensuite, nous lisons le fichier statique index.html de l'app client créée, nous injectons le contenu statique de notre app dans le <div> avec un id « root » et envoyons cela sous forme de réponse à la requête.

      Étape 3 — Configuration des scripts Webpack, Babel et npm

      Pour que notre code serveur fonctionne, nous devons le grouper et le transposer, en utilisant Webpack et Babel. Pour ce faire, ajoutez les dépendances de dév. au projet en saisissant la commande suivante dans la fenêtre de votre terminal :

      • npm install webpack@4.42.0 webpack-cli@3.3.12 webpack-node-externals@1.7.2 @babel/core@7.10.4 babel-loader@8.1.0 @babel/preset-env@7.10.4 @babel/preset-react@7.10.4 --save-dev

      Ou, en utilisant yarn :

      • yarn add webpack@4.42.0 webpack-cli@3.3.12 webpack-node-externals@1.7.2 @babel/core@7.10.4 babel-loader@8.1.0 @babel/preset-env@7.10.4 @babel/preset-react@7.10.4 --dev

      Remarque : une version antérieure de ce tutoriel était dédiée à l'installation de babel-core, babel-preset-env et babel-preset-react-app. Depuis, ces paquets ont été archivés et remplacés par des versions mono repo.

      Ensuite, créez un fichier de configuration Babel :

      Puis, ajoutez les préréglages de env et react-app :

      .babelrc.json

      {
        "presets": [
          "@babel/preset-env",
          "@babel/preset-react"
        ]
      }
      

      Remarque : dans une version antérieure de ce tutoriel, on utilisait un fichier .babelrc (aucune extension de fichier .json). Il s'agissait d'un fichier de configuration pour Babel 6, mais ce n'est plus le cas pour Babel 7.

      Maintenant, nous allons créer un Webpack de configuration pour le serveur qui utilise Babel Loader et pourvoir ainsi transposer le code. Commencez par créer le fichier :

      Maintenant, ajoutez les paramètres suivants au fichier webpack.server.js :

      webpack.server.js

      const path = require('path');
      const nodeExternals = require('webpack-node-externals');
      
      module.exports = {
        entry: './server/index.js',
      
        target: 'node',
      
        externals: [nodeExternals()],
      
        output: {
          path: path.resolve('server-build'),
          filename: 'index.js'
        },
      
        module: {
          rules: [
            {
              test: /.js$/,
              use: 'babel-loader'
            }
          ]
        }
      };
      

      Une fois cette configuration faite, notre bundle serveur transposé sera généré dans le dossier server-build situé dans le fichier index.js.

      Notez que l'on utilise target: 'node' et externals: [nodeExternals()] de webpack-node-externals. Cela permettra d'omettre les fichiers node_modules qui se trouvent dans le paquet et au serveur d'accéder directement à ces fichiers.

      Ceci achève l'installation de la dépendance et la configuration du Webpack et de Babel.

      Maintenant, retournons à paquet.json pour ajouter les scripts npm d'aide :

      Nous allons ajouter les scripts dev:build-server, dev:start et dev au fichier package.json pour développer et desservir facilement notre application SSR :

      package.json

      "scripts": {
        "dev:build-server": "NODE_ENV=development webpack --config webpack.server.js --mode=development -w",
        "dev:start": "nodemon ./server-build/index.js",
        "dev": "npm-run-all --parallel build dev:*",
        ...
      },
      

      Lorsque nous apportons des modifications au serveur, nous utilisons nodemon pour le redémarrer. De son côté, npm-run-all permet d'exécuter plusieurs commandes en parallèle.

      Vous pouvez maintenant procéder à l'installation de ces paquets en saisissant les commandes suivantes dans la fenêtre de votre terminal :

      • npm install nodemon@2.0.4 npm-run-all@4.1.5 --save-dev

      Ou, en utilisant yarn :

      • yarn add nodemon@2.0.4 npm-run-all@4.1.5 --dev

      Une fois que tout cela est en place, vous pouvez exécuter les éléments suivants pour développer l'app côté client, regrouper et transposer le code du serveur et lancer le serveur en utilisant :3006 :

      Ou, en utilisant yarn :

      En configurant ainsi le Webpack de notre serveur, les changements seront surveillés et le serveur redémarré à chaque fois que des modifications seront apportées. Cependant, du côté de l'app client, il faudra en créer une à chaque changement. Il s'agit ici d'un problème qui n'a pas encore été résolu.

      Maintenant, ouvrez http://localhost:3006/ dans votre navigateur web. Vous verrez que votre app est rendue côté serveur.

      Auparavant, le code source révélait ce qui suit :

      Output

      <div id="root"></div>

      Mais maintenant, avec les changements que vous avez apportés, le code source révèle ceci :

      Output

      <div id="root"><h1 data-reactroot="">Hello <!-- -->Sammy<!-- -->!</h1></div>

      Le rendu côté serveur a réussi à convertir le composant <App> en HTML.

      Conclusion

      Au cours de ce tutoriel, vous avez initialisé une application React et activé le rendu côté serveur.

      Cependant, cet article n'aborde qu'une infime partie de ce qu'il est possible de faire. Les choses ont tendance à devenir un peu plus compliquées lorsque le rendu d'une app côté serveur implique un routage, la récupération de données ou Redux.

      L'un des principaux avantages de l'utilisation de SSR est que le contenu d'une app peut être analysé, même par les robots d'exploration qui n'exécutent pas de code JavaScript. Cela peut s'avérer être très pratique pour optimiser les moteurs de recherche (SEO) et alimenter les canaux des médias sociaux en métadonnées.

      Souvent, SSR pourra également vous aider à optimiser votre performance car l'app lancée sera entièrement chargée à partir du serveur à la première requête. Pour les apps non triviales, le parcours peut être quelque peu différent. En effet, la configuration de SSR peut s'avérer un peu compliquée et crée une plus grande charge sur le serveur. La décision d'utiliser un rendu côté serveur de votre app React dépend de vos besoins spécifiques et des compromis les plus pertinents pour votre utilisation.

      Si vous souhaitez en savoir plus sur React, consultez notre série Comment coder dans React.js ou consultez notre page thématique React pour des exercices et des projets de programmation.



      Source link