One place for hosting & domains

      Production

      Comment configurer un cluster Mesosphere prêt pour la production sur Ubuntu 14.04


      Introduction

      Mesosphere est un système qui combine un certain nombre de composants afin de gérer efficacement la création de clusters des serveurs et des déploiements hautement disponibles au-dessus d’une couche de système d’exploitation existante. Contrairement aux systèmes comme CoreOS, Mesosphere n’est pas un système d’exploitation spécialisé mais plutôt un ensemble de paquets.

      Dans ce guide, nous allons découvrir comment configurer un cluster hautement disponible dans Mesosphere. Cette configuration nous permettra de nous doter d’une fonctionnalité de basculement dans le cas où l’un de nos nœuds maîtres tomberait en panne, ainsi qu’un pool de serveurs esclaves qui gère les tâches planifiées.

      Au cours de ce guide, nous utiliserons des serveurs Ubuntu 14.04.

      Conditions prélables et objectifs

      Avant de suivre ce guide, il est fortement recommandé de revoir notre introduction à Mesosphere. Il s’agit d’un excellent moyen pour vous de vous familiariser avec les composants dont le système est composé et de vous aider à identifier de quoi chaque unité est responsable.

      Au cours de ce tutoriel, nous utiliserons six serveurs Ubuntu. Cela satisfait à la recommandation Apache Mesos qui préconise l’utilisation d’au moins trois maîtres dans un environnement de production. Cela permet également d’avoir un pool de trois serveurs de travail ou esclaves, qui se verront attribués du travail lorsque les tâches seront envoyées au cluster.

      Les six serveurs avec lesquels nous travaillerons utiliserons zookeeper pour suivre le serveur maître leader actuel. La couche Mesos, intégré au-dessus, offrira une synchronisation et une manipulation des ressources distribuées Elle est responsable de la gestion du cluster. Marathon, le système d’init distribué du cluster, est utilisé pour planifier des tâches et travailler manuellement sur les serveurs esclaves.

      Dans le cas de ce guide, nous supposerons que nos machines ont la configuration suivante :

      Nom d’hôte Fonction adresse IP
      maître1 Maître Mesos 192.0.2.1
      maître2 Maître Mesos 192.0.2.2
      maître3 Maître Mesos 192.0.2.3
      esclave1 Esclave Mesos 192.0.2.51
      esclave2 Esclave Mesos 192.0.2.52
      esclave3 Esclave Mesos 192.0.2.53

      Ubuntu 14.04 devrait être installé sur chacune de ces machines. Vous devriez compléter les éléments de configuration de base répertoriés dans notre guide de configuration du serveur initial Ubuntu 14.04.

      Une fois que vous aurez terminé les deux étapes ci-dessus, poursuivez la lecture de ce guide.

      Installer Mesosphere sur les serveurs

      La première étape pour faire fonctionner votre cluser consiste à installer le logiciel. Heureusement, le projet Mesosphere conserve un dépôt Ubuntu avec des packages à jour faciles à installer.

      Ajouter les dépôts Mesosphere à vos hôtes

      Sur tous les hôtes (maîtres et esclaves), suivez les étapes suivantes.

      Tout d’abord, ajoutez le dépôt Mesosphere à votre liste de sources. Pour suivre ce processus, la clé du projet Mesosphere devra être téléchargée à partir du serveur de clés Ubuntu, puis l’URL applicable de notre version Ubuntu développée. Le projet vous offre un moyen pratique de le faire :

      sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
      DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]')
      CODENAME=$(lsb_release -cs)
      echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
      

      Installer les composants nécessaires

      Une fois le dépôt Mesosphere ajouté à votre système, vous devez mettre à jour votre cache de package local pour avoir accès à votre nouveau composant :

      sudo apt-get -y update
      

      Ensuite, vous devez installer les packages nécessaires. Les composants dont vous avez besoin dépendront du rôle de l’hôte.

      Pour vos hôtes maîtres, vous avez besoin du package de méta mesosphere. Cela inclut les applications zookeeper, mesos, marathon et chronos :

      sudo apt-get install mesosphere
      

      Pour vos hôtes slave, vous avez uniquement besoin du package mesos, qui extrait également zookeeper comme dépendance :

      sudo apt-get install mesos
      

      Configurer les informations de connexion de Zookeeper pour Mesos

      Dans un premier temps, nous allons configurer nos informations de connexion à zookeeper. Il s’agit de la couche sous-jacente qui permet à tous vos hôtes de se connecter aux bons serveurs maîtres, c’est pourquoi il est logique de commencer ici.

      Nos serveurs maîtres seront les seuls membres de notre cluster zookeeper, mais l’intégralité de nos serveurs devront être configurés pour pouvoir communiquer en utilisant le protocole. Le fichier qui définit cela est le suivant /etc/mesos/zk.

      Sur tous vos hôtes, procédez à l’étape suivante. Ouvrez le fichier avec les privilèges root :

      sudo nano /etc/mesos/zk
      

      À l’intérieur, vous trouverez l’URL de connexion configurée par défaut pour accéder à une instance locale. Cela ressemble à ce qui suit :

      zk://localhost:2181/mesos
      

      Vous devez la modifier afin qu’elle pointe vers nos trois serveurs maîtres. Pour cela, vous devez remplacer localhost par l’adresse IP de notre premier maître Mesos. Nous pouvons ensuite ajouter une virgule après la spécification du port et reproduire le format pour ajouter nos deuxième et troisième maîtres à la liste.

      Dans notre guide, les adresses IP de nos maîtres sont les suivantes : 192.0.2.1, 192.168.2.2 et 192.168.2.3. En utilisant ces valeurs, notre fichier ressemblera à ce qui suit :

      zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/mesos
      

      La ligne doit commencer par zk:// et se terminer par /mesos. Entre deux sont spécifiées les adresses IP de vos serveurs maîtres et les ports zookeeper (2181 par défaut).

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Utilisez cette même saisie dans chacun de vos maîtres et esclaves. Cela aidera chaque serveur individuel à se connecter aux bons serveurs maîtres et pouvoir ainsi communiquer avec le cluster.

      Paramétrer la configuration de Zookeeper des serveurs maîtres

      Sur vos serveurs master, nous devrons procéder à une configuration supplémentaire de zookeeper.

      La première étape consiste à configurer un numéro d’identification unique, de 1 à 255 pour chacun de vos serveurs maîtres. Il se trouve dans le fichier /etc/zookeeper/conf/myid. Maintenant, ouvrez-le :

      sudo nano /etc/zookeeper/conf/myid
      

      Supprimez toutes les informations qui se trouvent dans ce fichier et remplacez-les par un seul numéro, de 1 à 255. Le numéro attribué à chacun de vos serveurs maîtres doit être unique. Par souci de simplicité, il est plus facile de commencer par 1 et de progresser. Dans notre guide, nous utiliserons 1, 2 et 3.

      Notre premier serveur contiendra uniquement ce qui suit dans le fichier :

      1
      

      Enregistrez et fermez le fichier lorsque vous avez terminé. Procédez ainsi sur chacun de vos serveurs maîtres.

      Ensuite, nous devons modifier notre fichier de configuration zookeeper pour cartographier nos ID zookeeper sur les hôtes en tant que tel. Vous aurez ainsi la garantie que le service est bien en capacité de résoudre correctement chaque hôte à partir du système d’ID qu’il utilise.

      Maintenant, ouvrez le fichier de configuration zookeeper :

      sudo nano /etc/zookeeper/conf/zoo.cfg
      

      Dans ce fichier, vous devrez cartographier chaque ID sur un hôte. La spécification de l’hôte inclura deux ports. Le premier servira à communiquer avec le leader. Le second se chargera des élections au moment où un nouveau leader sera nécessaire. Les serveurs zookeeper sont identifiés par le terme « server » suivi d’un point et de leur numéro d’ID.

      Dans notre guide, nous utiliserons les ports par défaut pour chaque fonction et nos ID vont de 1 à 3. Notre fichier ressemblera à ce qui suit :

      server.1=192.168.2.1:2888:3888
      server.2=192.168.2.2:2888:3888
      server.3=192.168.2.3:2888:3888
      

      Ajoutez ces mêmes cartographies dans chacun des fichiers de configuration de vos serveurs maîtres. Enregistrez et fermez chaque fichier lorsque vous avez terminé.

      Avec cela, notre configuration zookeeper est achevée. Nous pouvons commencer à nous concentrer sur Mesos et Marathon.

      Configurer Mesos sur les serveurs maîtres

      Ensuite, nous allons configurer Mesos sur les trois serveurs maîtres. Suivez ces étapes sur chacun de vos serveurs maîtres.

      Modifier le Quorum pour refléter la taille de votre cluster

      Tout d’abord, nous devons ajuster le quorum nécessaire à la prise de décision. Il déterminera le nombre d’hôtes nécessaires pour que le cluster soit en état de fonctionnement.

      Le quorum doit être configuré de manière à ce que plus de 50 pour cent des membres maîtres soient présents pour prendre des décisions. Cependant, il nous faut également établir une certaine tolérance de défaillance dans le cas où, si tous nos maîtres ne sont pas présents, le cluster puisse toujours fonctionner.

      Nous disposons de trois maîtres. Par conséquent, le seul réglage qui satisfait à ces deux exigences est un quorum de deux. Étant donné que la configuration initiale suppose un réglage de serveur unique, le quorum est actuellement défini à un.

      Ouvrez le fichier de configuration du quorum :

      sudo nano /etc/mesos-master/quorum
      

      Remplacez la valeur par « 2 » :

      2
      

      Enregistrez et fermez le fichier. Procédez ainsi sur chacun de vos serveurs maîtres.

      Configurer le nom d’hôte et l’adresse IP

      Nous allons ensuite spécifier le nom de l’hôte et l’adresse IP de chacun de nos serveurs maîtres. Pour le nom de l’hôte, nous utiliserons l’adresse IP afin que nos instances n’aient pas de difficultés à se résoudre correctement.

      Pour nos serveurs maîtres, l’adresse IP doit être placée dans ces fichiers :

      • /etc/mesos-master/ip
      • /etc/mesos-master/hostname

      Tout d’abord, ajoutez l’adresse IP individuelle de chaque nœud maître dans le fichier /etc/mesos-master/ip. N’oubliez pas de la modifier sur chaque serveur afin qu’elle corresponde à la valeur applicable :

      echo 192.168.2.1 | sudo tee /etc/mesos-master/ip
      

      Maintenant, nous pouvons copier cette valeur sur le fichier du nom de l’hôte :

      sudo cp /etc/mesos-master/ip /etc/mesos-master/hostname
      

      Procédez ainsi sur chacun de vos serveurs maîtres.

      Configurer Marathon sur les serveurs maîtres

      Maintenant que Mesos est configuré, nous pouvons procéder à la configuration de l’implémentation du système init en cluster de Mesosphere.

      Marathon s’exécutera sur chacun de nos hôtes maîtres. Cependant, seul le serveur maître principal pourra planifier des tâches. Les autres instances de Marathon transmettront les requêtes de manière transparente sur le serveur maîtres.

      Tout d’abord, nous devons à nouveau configurer le nom de l’hôte pour l’instance de Marathon de chaque serveur. Encore une fois, nous utiliserons l’adresse IP dont nous disposons déjà dans un fichier. Nous pouvons la copier dans l’emplacement du fichier dont nous avons besoin.

      Cependant, la structure du répertoire de configuration de Marathon dont nous avons besoin n’est pas automatiquement créée. Nous allons devoir créer le répertoire pour pouvoir ensuite y copier le fichier :

      sudo mkdir -p /etc/marathon/conf
      sudo cp /etc/mesos-master/hostname /etc/marathon/conf
      

      Ensuite, nous devons définir la liste des maîtres zookeeper auxquels Marathon se connectera pour obtenir des informations et une planification. Il s’agit de la même chaîne de connexion zookeeper que nous avons utilisée pour Mesos afin que nous puissions tout simplement y copier le fichier. Nous devons le placer dans un fichier appelé master :

      sudo cp /etc/mesos/zk /etc/marathon/conf/master
      

      Notre service Marathon pourra ainsi se connecter au cluster Mesos. Cependant, nous souhaitons également que Marathon stocke ses propres informations dans zookeeper. Pour cela, nous utiliserons l’autre fichier de connexion zookeeper comme base et modifierons tout simplement le point final.

      Tout d’abord, copiez le fichier dans l’emplacement zookeeper de Marathon :

      sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk
      

      Ensuite, ouvrez le fichier dans votre éditeur :

      sudo nano /etc/marathon/conf/zk
      

      Le point final est la seule partie que nous ayons besoin de modifier. Nous allons remplacer /mesos par /marathon :

      zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/marathon
      

      C’est tout ce qu’il faut faire pour configurer Marathon.

      Configurer les règles d’init des services et redémarrer les services

      Ensuite, nous allons redémarrer les services de serveurs maîtres pour utiliser les paramètres qui nous avons configurés.

      Tout d’abord, nous allons nous assurer que nos serveurs maîtres exécutent uniquement le processus maître Mesos et non pas le processus esclave. Nous pouvons arrêter tout processus esclave actuellement en cours d’exécution (cela peut échouer mais ce n’est pas un problème car il s’agit uniquement de vérifier que le processus est arrêté). Nous pouvons également que le serveur ne commence pas avec le processus esclave au démarrage en créant un fichier de remplacement :

      sudo stop mesos-slave
      echo manual | sudo tee /etc/init/mesos-slave.override
      

      Maintenant, il ne reste plus qu’à redémarrer zookeeper, qui configurera nos élections maîtresses. Nous pouvons ensuite démarrer nos processus Mesos maître et Marathon :

      sudo restart zookeeper
      sudo start mesos-master
      sudo start marathon
      

      Pour obtenir un pic dans ce que vous venez juste de configurer, consultez l’un de nos serveurs maîtres notre navigateur web au port 5050 :

      http://192.168.2.1:5050
      

      Vous devriez voir l’interface principale de Mesos. Vous serez éventuellement informé que vous êtes redirigé vers le master actif en fonction de si vous vous êtes connecté au leader ou pas. Dans tous les cas, l’écran ressemblera à ce qui suit :

      Principale interface de Mesos

      Il s’agit d’une vue de votre cluster actuel. Vous n’y voyez pas grand-chose car il n’y a aucun nœud esclave disponible et aucune tâche a été démarrée.

      Nous avons également configuré Marathon, le contrôleur de tâches longue durée de Mesosphere. Il sera disponible sur le port 8080 sur l’un de vos maîtres :

      Interface principale de Marathon

      Nous allons brièvement voir comment utiliser ces interfaces une fois que nous avons configuré nos esclaves.

      Configurer les serveurs esclaves

      Maintenant que nous avons configuré nos serveurs maîtres, nous pouvons commencer à configurer nos serveurs esclaves.

      Nous avons déjà configuré nos esclaves avec les informations de connexion zookeeper de nos serveurs maîtres. Les esclaves eux-mêmes n’exécutent pas leurs propres instances zookeeper.

      Nous pouvons arrêter tout processus zookeeper qui fonctionne actuellement sur nos nœuds esclaves et créer un fichier de remplacement afin qu’il ne démarre pas automatiquement lorsque le serveur redémarre :

      sudo stop zookeeper
      echo manual | sudo tee /etc/init/zookeeper.override
      

      Ensuite, nous voulons créer un autre fichier de remplacement pour s’assurer que le processus maître Mesos ne commence pas sur nos serveurs esclaves. Nous allons également nous assurer qu’il est actuellement arrêté (il se peut que cette commande échoue si le processus est déjà arrêté. Ceci n’est pas un problème) :

      echo manual | sudo tee /etc/init/mesos-master.override
      sudo stop mesos-master
      

      Ensuite, nous devons configurer l’adresse IP et le nom de l’hôte, tout comme nous l’avons fait pour nos serveurs maîtres. Cela implique la mise en place de l’adresse IP de chaque nœud dans un fichier, cette fois sous le répertoire /etc/mesos-slave. Nous utiliserons également le nom de l’hôte pour accéder facilement aux services via l’interface web :

      echo 192.168.2.51 | sudo tee /etc/mesos-slave/ip
      sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname
      

      Encore une fois, utilisez l’adresse IP de chaque serveur esclave pour la première commande. Cela garantira qu’elle est bien liée à la bonne interface.

      Maintenant, nous avons tous les éléments pour démarrer nos esclaves Mesos. Il nous suffit juste d’activer le service :

      sudo start mesos-slave
      

      Procédez ainsi sur chacune de vos machines esclaves.

      Pour voir si vos esclaves s’enregistrent avec succès dans votre cluster, revenez à l’un de vos serveurs maîtres au port 5050 :

      http://192.168.2.1:5050
      

      Maintenant, vous devriez voir le nombre d’esclaves actifs afficher « 3 » dans l’interface :

      Trois esclaves Mesos

      Vous pouvez également voir que les ressources disponibles dans l’interface ont été mises à jour pour refléter les ressources pooled dans vos machines esclaves :

      Ressources Mesos

      Pour obtenir de plus amples informations sur chacune de vos machines, vous pouvez cliquer sur le lien « Slaves » en haut de l’interface. Ceci nous donnera un aperçu de la contribution en ressources de chaque machine, ainsi que les liens vers une page de chaque esclave :

      Page des esclaves Mesos

      Démarrer des services sur Mesos et Marathon

      Marathon est l’utilitaire Mesosphere permettant de planifier les tâches de longue durée. Il est facile de penser que Marathon est le système init pour un cluster Mesosphere car il prend en charge les services de démarrage et d’arrêt, tout en planifiant les tâches et en s’assurant que les applications remontent si elles descendent.

      Vous pouvez également ajouter des services et des tâches à Marathon de quelques manières différentes. Nous allons uniquement couvrir les services de base. Les conteneurs Docker seront traités dans un prochain guide.

      Démarrer un service via l’interface Web

      La manière la plus directe de lancer un service rapidement sur le cluster consiste à ajouter une application par le biais de l’interface Web Marathon.

      Tout d’abord, consultez l’interface Web de Marathon sur l’un de vos serveurs maîtres. N’oubliez pas que l’interface de Marathon se trouve sur le port 8080 :

      http://192.168.2.1:8080
      

      À partir de là, vous pouvez cliquer sur le bouton « New App » dans le coin supérieur droit. Cela fera apparaître une superposition dans laquelle vous pouvez ajouter des informaions sur votre nouvelle application :

      Nouvelle application Marathon

      Complétez les champs avec les exigences de votre application. Seules les champs suivants sont obligatoires

      • ID : un ID unique que l’utilisateur choisi pour identifier un processus. Vous pouvez utiliser ce que vous voulez, mais il doit être unique.
      • Command : il s’agit de la commande réelle que Marathon exécutera réellement. Il s’agit du processus qui sera surveillé et redémarré en cas d’échec.

      En utilisant ces informations, vous pouvez configurer un service simple qui imprime simplement « hello » et se met en veille pendant 10 secondes. Nous allons appeler ce « hello » :

      Application simple de Marathon

      Une fois que vous reviendrez à l’interface, le service passera de « Deploying » à « Running » :

      Application Marathon en cours d'exécution

      Environ toutes les 10 secondes, l’élément « Tasks/Instances » passera de « 1/1 » à « 0/1 » au fur et à mesure que la quantité de mise en veille passe et le service s’arrête. Ensuite, Marathon redémarre automatiquement la tâche. Nous pouvons voir ce processus plus clairement dans l’interface Web de Mesos sur le port 5050 :

      http://192.168.2.1:5050
      

      Ici, vous pouvez voir le processus se terminer et être redémarré :

      Tâche de redémarrage de Mesos

      En cliquant sur « Sandbox » et que « stdout » d’une des tâches, vous pouvez voir la sortie « hello » en cours de production :

      Sortie Mesos

      Démarrage d’un service via l’API

      Nous pouvons également soumettre des services via l’API Marathon. Pour cela, il vous faudra y transmettre un objet JSON contenant tous les champs que la superposition contenait.

      Il s’agit d’un processus relativement simple. Encore une fois, les seuls champs requis sont id pour l’identificateur de processus et cmd qui contient la commande réelle à exécuter.

      Donc, nous devons créer un fichier JSON appelé hello.json avec ces informations :

      nano hello.json
      

      À l’intérieur, la spécification minimum devrait ressembler à ce qui suit :

      {
        "id": "hello2",
        "cmd": "echo hello; sleep 10"
      }
      

      Ce service fonctionnera correctement. Cependant, si nous souhaitons réellement émuler le service que nous avons créé dans l’IU web, nous devons ajouter quelques champs supplémentaires. Ces valeurs seront configurées par défaut dans l’IU web et nous pouvons les répliquer ici :

      {
        "id": "hello2",
        "cmd": "echo hello; sleep 10",
        "mem": 16,
        "cpus": 0.1,
        "instances": 1,
        "disk": 0.0,
        "ports": [0]
      }
      

      Sauvegardez et fermez le fichier JSON une fois que vous aurez fini.

      Ensuite, nous pouvons le soumettre en utilisant l’API Marathon. La cible est l’un de nos services maître de Marathon sur le port 8080 et le point de terminaison est /v2/apps. La charge de données de notre fichier, que nous nous pouvons y lire curl en utilisant la balise -d avec la balsise @ pour indiquer un fichier.

      La commande ressemblera à ceci :

      curl -i -H 'Content-Type: application/json' -d@hello2.json 192.168.2.1:8080/v2/apps
      

      Si nous regardons l’interface Marathon, nous pouvons voir que l’ajout à bien été effectué. Il semble avoir exactement les mêmes propriétés que notre premier service :

      Deux services Marathon

      Vous pouvez surveiller et accéder au nouveau service exactement de la même manière que le premier service.

      Conclusion

      À ce stade, vous devriez avoir un cluster Mesosphere qui fonctionne. Pour le moment, nous avons uniquement abordé la configuration de base. Vous devriez cependant être en mesure de voir les possibilités qu’offre le système Mesosphere.

      Dans les futurs guides, nous allons voir comment déployer des conteneurs Docker sur votre cluster et utiliser certains outils plus en profondeur.



      Source link

      How To Harden the Security of Your Production Django Project


      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Developing a Django application can be a quick and clean experience, because its approach is flexible and scalable. Django also offers a variety of security-oriented settings that can help you seamlessly prepare your project for production. However, when it comes to production deployment, there are several ways to further secure your project. Restructuring your project by breaking up your settings will allow you to easily set up different configurations based on the environment. Leveraging dotenv for hiding environment variables or confidential settings will ensure you don’t release any details about your project that may compromise it.

      While implementing these different strategies and features might seem time-consuming at first, developing a practical workflow will allow you to deploy releases of your project without compromising on security, or your productivity.

      In this tutorial, you will leverage a security-oriented workflow for your Django development by implementing and configuring environment-based settings, dotenv, and Django’s built-in security settings. These features all complement each other and will result in a version of your Django project that is ready for different approaches you may take to deployment.

      Prerequisites

      Before you begin this guide you’ll need the following:

      Note: If you’re using an existing Django project, you may have different requirements. This tutorial suggests a particular project structure, however, you can also use each of the sections of this tutorial individually as needed.

      Step 1 — Restructuring Django’s Settings

      In this first step, you’ll start by rearranging your settings.py file into environment-specific configurations. This is a good practice when you need to move a project between different environments, for example, development and production. This arrangement will mean less reconfiguration for different environments; instead, you’ll use an environment variable to switch between configurations, which we’ll discuss later in the tutorial.

      Create a new directory called settings in your project’s sub-directory:

      • mkdir testsite/testsite/settings

      (As per the prerequisites we’re using testsite, but you can substitute your project’s name in here.)

      This directory will replace your current settings.py configuration file; all of your environment-based settings will be in separate files contained in this folder.

      In your new settings folder, create three Python files:

      • cd testsite/testsite/settings
      • touch base.py development.py production.py

      The development.py file will contain settings you’ll normally use during development. And production.py will contain settings for use on a production server. You should keep these separate because the production configuration will use settings that will not work in a development environment; for example, forcing the use of HTTPS, adding headers, and using a production database.

      The base.py settings file will contain settings that development.py and production.py will inherit from. This is to reduce redundancy and to help keep your code cleaner. These Python files will be replacing settings.py, so you’ll now remove settings.py to avoid confusing Django.

      While still in your settings directory, rename settings.py to base.py with the following command:

      • mv ../settings.py base.py

      You’ve just completed the outline of your new environment-based settings directory. Your project won’t understand your new configuration yet, so next, you’ll fix this.

      Step 2 — Using python-dotenv

      Currently Django will not recognize your new settings directory or its internal files. So, before you continue working with your environment-based settings, you need to make Django work with python-dotenv. This is a dependency that loads environment variables from a .env file. This means that Django will look inside a .env file in your project’s root directory to determine which settings configuration it will use.

      Go to your project’s root directory:

      Install python-dotenv:

      • pip install python-dotenv

      Now you need to configure Django to use dotenv. You’ll edit two files to do this: manage.py, for development, and wsgi.py, for production.

      Let’s start by editing manage.py:

      Add the following code:

      testsite/manage.py

      import os
      import sys
      import dotenv
      
      def main():
          os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'testsite.settings.development')
      
          if os.getenv('DJANGO_SETTINGS_MODULE'):
          os.environ['DJANGO_SETTINGS_MODULE'] = os.getenv('DJANGO_SETTINGS_MODULE')
      
          try:
              from django.core.management import execute_from_command_line
          except ImportError as exc:
              raise ImportError(
                  "Couldn't import Django. Are you sure it's installed and "
                  "available on your PYTHONPATH environment variable? Did you "
                  "forget to activate a virtual environment?"
              ) from exc
          execute_from_command_line(sys.argv)
      
      
      if __name__ == '__main__':
          main()
      
      dotenv.load_dotenv(
          os.path.join(os.path.dirname(__file__), '.env')
      )
      

      Save and close manage.py and then open wsgi.py for editing:

      Add the following highlighted lines:

      testsite/testsite/wsgi.py

      
      import os
      import dotenv
      
      from django.core.wsgi import get_wsgi_application
      
      dotenv.load_dotenv(
          os.path.join(os.path.dirname(os.path.dirname(__file__)), '.env')
      )
      
      os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'testsite.settings.development')
      
      if os.getenv('DJANGO_SETTINGS_MODULE'):
       os.environ['DJANGO_SETTINGS_MODULE'] = os.getenv('DJANGO_SETTINGS_MODULE')
      
      application = get_wsgi_application()
      

      The code you’ve added to both of these files does two things. First, whenever Django runs—manage.py for running development, wsgi.py for production—you’re telling it to look for your .env file. If the file exists, you instruct Django to use the settings file that .env recommends, otherwise you use the development configuration by default.

      Save and close the file.

      Finally, let’s create a .env in your project’s root directory:

      Now add in the following line to set the environment to development:

      testsite/.env

      DJANGO_SETTINGS_MODULE="testsite.settings.development"
      

      Note: Add .env to your .gitignore file so it is never included in your commits; you’ll use this file to contain data such as passwords and API keys that you do not want visible publicly. Every environment your project is running on will have its own .env with settings for that specific environment.

      It is recommended to create a .env.example to include in your project so you can easily create a new .env wherever you need one.

      So, by default Django will use testsite.settings.development, but if you change DJANGO_SETTINGS_MODULE to testsite.settings.production for example, it will start using your production configuration. Next, you’ll populate your development.py and production.py settings configurations.

      Step 3 — Creating Development and Production Settings

      Next you’ll open your base.py and add the configuration you want to modify for each environment in the separate development.py and production.py files. The production.py will need to use your production database credentials, so ensure you have those available.

      Note: It is up to you to determine which settings you need to configure, based on environment. This tutorial will only cover a common example for production and development settings (that is, security settings and separate database configurations).

      In this tutorial we’re using the Django project from the prerequisite tutorial as the example project. We’ll move settings from from base.py to development.py. Begin by opening development.py:

      • nano testsite/settings/development.py

      First, you will import from base.py—this file inherits settings from base.py. Then you’ll transfer the settings you want to modify for the development environment:

      testsite/testsite/settings/development.py

      from .base import *
      
      DEBUG = True
      
      DATABASES = {
          'default': {
              'ENGINE': 'django.db.backends.sqlite3',
              'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
          }
      }
      

      In this case, the settings specific to development are: DEBUG, you need this True in development, but not in production; and DATABASES, a local database instead of a production database. You’re using an SQLite database here for development.

      Note: For security purposes, Django’s DEBUG output will never display any settings that may contain the strings: API, KEY, PASS, SECRET, SIGNATURE, or TOKEN.

      This is to ensure secrets will not be revealed, if you accidentally deploy a project to production with DEBUG still enabled.

      With that being said, never deploy a project publicly with DEBUG enabled. It will only ever put the security of your project at risk.

      Next, let’s add to production.py:

      • nano testsite/settings/production.py

      Production will be similar to development.py, but with a different database configuration and DEBUG set to False:

      testsite/testsite/settings/production.py

      from .base import *
      
      DEBUG = False
      
      ALLOWED_HOSTS = []
      
      DATABASES = {
          'default': {
              'ENGINE': os.environ.get('SQL_ENGINE', 'django.db.backends.sqlite3'),
              'NAME': os.environ.get('SQL_DATABASE', os.path.join(BASE_DIR, 'db.sqlite3')),
              'USER': os.environ.get('SQL_USER', 'user'),
              'PASSWORD': os.environ.get('SQL_PASSWORD', 'password'),
              'HOST': os.environ.get('SQL_HOST', 'localhost'),
              'PORT': os.environ.get('SQL_PORT', ''),
          }
      }
      

      For the example database configuration given, you can use dotenv to configure each of the given credentials, with defaults included. Assuming you’ve already set up a database for the production version of your project, please use your configuration instead of the example provided.

      You have now configured your project to use different settings based on DJANGO_SETTINGS_MODULE in .env. Given the example settings you’ve used, when you set your project to use production settings, DEBUG becomes False, ALLOWED_HOSTS is defined, and you start using a different database that you’ve (already) configured on your server.

      Step 4 — Working with Django’s Security Settings

      Django includes security settings ready for you to add to your project. In this step, you’ll add security settings to your project that are considered essential for any production project. These settings are intended for use when your project is available to the public. It’s not recommended to use any of these settings in your development environment; hence, in this step you’re limiting these settings to the production.py configuration.

      For the most part these settings are going to enforce the use of HTTPS for various web features, such as session cookies, CSRF cookies, upgrading HTTP to HTTPS, and so on. Therefore, if you haven’t already set up your server with a domain pointing to it, hold off on this section for now. If you need to set up your server ready for deployment, check out the Conclusion for suggested articles on this.

      First open production.py:

      In your file, add the highlighted settings that work for your project, according to the explanations following the code:

      testsite/testsite/settings/production.py

      from .base import *
      
      DEBUG = False
      
      ALLOWED_HOSTS = ['your_domain', 'www.your_domain']
      
      DATABASES = {
          'default': {
              'ENGINE': os.environ.get('SQL_ENGINE', 'django.db.backends.sqlite3'),
              'NAME': os.environ.get('SQL_DATABASE', os.path.join(BASE_DIR, 'db.sqlite3')),
              'USER': os.environ.get('SQL_USER', 'user'),
              'PASSWORD': os.environ.get('SQL_PASSWORD', 'password'),
              'HOST': os.environ.get('SQL_HOST', 'localhost'),
              'PORT': os.environ.get('SQL_PORT', ''),
          }
      }
      
      SECURE_SSL_REDIRECT = True
      
      SESSION_COOKIE_SECURE = True
      
      CSRF_COOKIE_SECURE = True
      
      SECURE_BROWSER_XSS_FILTER = True
      
      • SECURE_SSL_REDIRECT redirects all HTTP requests to HTTPS (unless exempt). This means your project will always try to use an encrypted connection. You will need to have SSL configured on your server for this to work. Note that if you have Nginx or Apache configured to do this already, this setting will be redundant.
      • SESSION_COOKIE_SECURE tells the browser that cookies can only be handled over HTTPS. This means cookies your project produces for activities, such as logins, will only work over an encrypted connection.
      • CSRF_COOKIE_SECURE is the same as SESSION_COOKIE_SECURE but applies to your CSRF token. CSRF tokens protect against Cross-Site Request Forgery. Django CSRF protection does this by ensuring any forms submitted (for logins, signups, and so on) to your project were created by your project and not a third party.
      • SECURE_BROWSER_XSS_FILTER sets the X-XSS-Protection: 1; mode=block header on all responses that do not already have it. This ensures third parties cannot inject scripts into your project. For example, if a user stores a script in your database using a public field, when that script is retrieved and displayed to other users it will not run.

      If you would like to read more about the different security settings available within Django, check out their documentation.

      Warning: Django’s documentation states you shouldn’t rely completely on SECURE_BROWSER_XSS_FILTER. Never forget to validate and sanitize input.

      Additional Settings

      The following settings are for supporting HTTP Strict Transport Security (HSTS)—this means that your entire site must use SSL at all times.

      • SECURE_HSTS_SECONDS is the amount of time in seconds HSTS is set for. If you set this for an hour (in seconds), every time you visit a web page on your website, it tells your browser that for the next hour HTTPS is the only way you can visit the site. If during that hour you visit an insecure part of your website, the browser will show an error and the insecure page will be inaccessible.
      • SECURE_HSTS_PRELOAD only works if SECURE_HSTS_SECONDS is set. This header instructs the browser to preload your site. This means that your website will be added to a hardcoded list, which is implemented in popular browsers, like Firefox and Chrome. This requires that your website is always encrypted. It is important to be careful with this header. If at anytime you decide to not use encryption for your project, it can take weeks to be manually removed from the HSTS Preload list.
      • SECURE_HSTS_INCLUDE_SUBDOMAINS applies the HSTS header to all subdomains. Enabling this header, means that both your_domain and unsecure.your_domain will require encryption even if unsecure.your_domain is not related to this Django project.

      Warning: Incorrectly configuring these additional settings can break your site for a significant amount of time.

      Please read the Django documentation on HSTS before implementing these settings.

      It is necessary to consider how these settings will work with your own Django project; overall the settings discussed here are a good foundation for most Django projects. Next you’ll review some further usage of dotENV.

      Step 5 — Using python-dotenv for Secrets

      The final part of this tutorial will help you leverage python-dotenv. This will allow you to hide certain information such as your project’s SECRET_KEY or the admin’s login URL. This is a great idea if you intend to publish your code on platforms like GitHub or GitLab since these secrets won’t be published. Instead, whenever you initially set up your project on a local environment or a server, you can create a new .env file and define those secret variables.

      You must hide your SECRET_KEY so you’ll start working on that in this section.

      Open your .env file:

      And add the following line:

      testsite/.env

      DJANGO_SETTINGS_MODULE="django_hardening.settings.development"
      SECRET_KEY="your_secret_key"
      

      And in your base.py:

      • nano testsite/settings/base.py

      Let’s update the SECRET_KEY variable like so:

      testsite/testsite/settings/base.py

      . . .
      SECRET_KEY = os.getenv('SECRET_KEY')
      . . .
      

      Your project will now use the SECRET_KEY located in .env.

      Lastly, you’ll hide your admin URL by adding a long string of random characters to it. This will ensure bots can’t brute force the login fields and strangers can’t try guessing the login.

      Open .env again:

      And add a SECRET_ADMIN_URL variable:

      testsite/.env

      DJANGO_SETTINGS_MODULE="django_hardening.settings.development"
      SECRET_KEY="your_secret_key"
      SECRET_ADMIN_URL="very_secret_url"
      

      Now let’s tell Django to hide your admin URL with SECRET_ADMIN_URL:

      Note: Don’t forget to replace your_secret_key and very_secret_url with your own secret strings. Also don’t forget to replace very_secret_url with your own secret URL.

      If you want to use random strings for these variables, Python provides a fantastic secrets.py library for generating such strings. The examples they give are great ways to create small Python programs for generating secure random strings.

      Edit the admin URL like so:

      testsite/testsite/urls.py

      import os
      from django.contrib import admin
      from django.urls import path
      
      urlpatterns = [
          path(os.getenv('SECRET_ADMIN_URL') + '/admin/', admin.site.urls),
      ]
      

      You can now find the admin login page at very_secret_url/admin/ instead of just /admin/.

      Conclusion

      In this tutorial you have configured your current Django project for easy use with different environments. Your project now leverages python-dotenv for handling secrets and settings. And your production settings now have Django’s built-in security features enabled.

      If you’ve enabled all the recommended security components and re-implemented settings as directed, your project has these key features:

      • SSL/HTTPS for all communications (for example, subdomains, cookies, CSRF).
      • XSS (cross-site scripting) attacks prevention.
      • CSRF (cross-site request forgery) attacks prevention.
      • Concealed project secret key.
      • Concealed admin login URL preventing brute-force attacks.
      • Separate settings for development and production.

      If you are interested in learning more about Django, check out our tutorial series on Django development.

      Also, if you haven’t already put your project into production, here is a tutorial on How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 20.04. You can also check out our Django topic page for further tutorials.

      And, of course, please read over Django’s settings documentation, for further information.



      Source link

      Comment mettre en place une application Node.js pour la production sur Ubuntu 20.04


      Introduction

      Node.js est un environnement d’exécution JavaScript open-source pour la création d’applications côté serveur et de réseau. La plate-forme fonctionne sous Linux, macOS, FreeBSD et Windows. Bien que vous puissiez exécuter les applications Node.js en ligne de commande, ce tutoriel se concentre sur leur exécution en tant que service. Cela signifie qu’ils redémarreront au redémarrage ou en cas d’échec et qu’ils peuvent être utilisés en toute sécurité dans un environnement de production.

      Dans ce tutoriel, vous allez mettre en place un environnement Node.js prêt pour la production sur un seul serveur Ubuntu 20.04. Ce serveur exécutera une application Node.js gérée par PM2, et fournira aux utilisateurs un accès sécurisé à l’application via un proxy inverse Nginx. Le serveur Nginx offrira le HTTPS en utilisant un certificat gratuit fourni par Let’s Encrypt. 

      Conditions préalables

      Ce guide suppose que vous disposez des éléments suivants :

      Lorsque vous aurez rempli les conditions préalables, vous disposerez d’un serveur desservant la page par défaut de votre domaine à l’adresse https://example.com/. 

      Étape 1 — Installation de Node.js

      Commençons par installer la dernière version LTS de Node.js, en utilisant les archives des packages NodeSource.

      Tout d’abord, installez le NodeSource PPA afin d’avoir accès à son contenu. Assurez-vous que vous êtes dans votre répertoire d’origine et utilisez curl pour récupérer le script d’installation de la version LTS la plus récente de Node.js dans ses archives.

      • cd ~
      • curl -sL https://deb.nodesource.com/setup_14.x -o nodesource_setup.sh

      Vous pouvez inspecter le contenu de ce script avec nano ou votre éditeur de texte préféré :

      Lorsque vous avez fini d’inspecter le script, lancez le sous sudo: 

      • sudo bash nodesource_setup.sh

      Le PPA sera ajouté à votre configuration et le cache local de votre package sera automatiquement mis à jour. Après avoir exécuté le script d’installation à partir de Nodesource, vous pouvez installer le paquet Node.js :

      Pour vérifier quelle version de Node.js vous avez installée après ces premières étapes, tapez :

      Output

      v14.4.0

      Note : Lors de l’installation à partir du PPA NodeSource, l’exécutable Node.js est appelé nodejs, plutôt que node.

      Le paquet nodejs contient le binaire nodejs ainsi que npm, un gestionnaire de packages pour les modules Node, de sorte que vous n’avez pas besoin d’installer npm séparément.

      npm utilise un fichier de configuration dans votre répertoire de base pour suivre les mises à jour. Il sera créé la première fois que vous utiliserez npm. Exécutez cette commande pour vérifier que npm est installé et pour créer le fichier de configuration :

      Output

      6.14.5

      Pour que certains packages npm fonctionnent (par exemple, ceux qui nécessitent la compilation du code source), vous devrez installer le package build-essential :

      • sudo apt install build-essential

      Vous disposez maintenant des outils nécessaires pour travailler avec les packages npm qui nécessitent de compiler du code source.

      Une fois le runtime Node.js installé, passons à l’écriture d’une application Node.js.

      Étape 2 — Création d’une application Node.js

      Écrivons une application Hello World qui renvoie « Hello World » à toute demande HTTP. Cet exemple de demande vous aidera à mettre en place Node.js. Vous pouvez le remplacer par votre propre application : assurez-vous simplement de modifier votre application pour écouter sur les adresses IP et les ports appropriés.

      Tout d’abord, créons un exemple de demande appelée hello.js: 

      Ajoutez le code suivant dans le fichier :

      ~/hello.js

      const http = require('http');
      
      const hostname="localhost";
      const port = 3000;
      
      const server = http.createServer((req, res) => {
        res.statusCode = 200;
        res.setHeader('Content-Type', 'text/plain');
        res.end('Hello World!n');
      });
      
      server.listen(port, hostname, () => {
        console.log(`Server running at http://${hostname}:${port}/`);
      });
      

      Enregistrez le fichier et quittez l’éditeur.

      Cette application Node.js écoute sur l’adresse (localhost) et le port (3000) spécifiés, et renvoie « Hello World ! » avec un code de réussite de 200 HTTP.  Comme nous sommes à l’écoute sur localhost, les clients distants ne pourront pas se connecter à notre application.

      Pour tester votre demande, tapez :

      Vous recevrez le résultat suivant :

      Output

      Server running at http://localhost:3000/

      Note : L’exécution d’une application Node.js de cette manière bloquera les commandes supplémentaires jusqu’à ce que l’application soit tuée en appuyant sur CTRL+C.

      Pour tester l’application, ouvrez une autre session de terminal sur votre serveur, et connectez-vous à localhost avec curl :

      • curl http://localhost:3000

      Si vous obtenez le résultat suivant, l’application fonctionne correctement et écoute à la bonne adresse et sur le bon port :

      Output

      Hello World!

      Si vous n’obtenez pas le résultat attendu, assurez-vous que votre application Node.js est en cours d’exécution et configurée pour écouter sur l’adresse et le port appropriés.

      Une fois que vous êtes sûr que cela fonctionne, arrêtez l’application (si ce n’est pas déjà fait) en appuyant sur CTRL+C.

      Étape 3 — Installer PM2

      Ensuite, nous allons installer PM2, un gestionnaire de processus pour les applications Node.js. PM2 permet de démoniser les applications afin qu’elles s’exécutent en arrière-plan comme un service.

      Utilisez npm pour installer la dernière version de PM2 sur votre serveur :

      • sudo npm install pm2@latest -g

      L’option -g indique à npm d’installer le module dans le monde entier, afin qu’il soit disponible dans tout le système.

      Commençons par utiliser la commande pm2 start​​​1​​​ pour exécuter votre application, hello.js, en arrière-plan :

      Cela ajoute également votre demande à la liste de processus de PM2, qui est produite chaque fois que vous lancez une demande :

      Output

      ... [PM2] Spawning PM2 daemon with pm2_home=/home/sammy/.pm2 [PM2] PM2 Successfully daemonized [PM2] Starting /home/sammy/hello.js in fork_mode (1 instance) [PM2] Done. ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐ │ id │ name │ mode │ ↺ │ status │ cpu │ memory │ ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤ │ 0 │ hello │ fork │ 0 │ online │ 0% │ 25.2mb │ └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

      Comme indiqué ci-dessus, PM2 attribue automatiquement un nom d'application (basé sur le nom de fichier, sans l’extension .js) et un identifiant PM2. PM2 conserve également d’autres informations, telles que le PID du processus, son état actuel et l’utilisation de la mémoire.

      Les applications qui tournent sous PM2 seront redémarrées automatiquement si l’application crashe ou est arrêtée, mais nous pouvons prendre une mesure supplémentaire pour que l’application soit lancée au démarrage du système en utilisant la sous-commande startup.  Cette sous-commande génère et configure un script de démarrage pour lancer PM2 et ses processus gérés aux démarrages du serveur :

      La dernière ligne de la sortie résultante comprendra une commande à exécuter avec les privilèges de superuser afin de configurer PM2 pour qu’il démarre au démarrage :

      Output

      [PM2] Init System found: systemd sammy [PM2] To setup the Startup Script, copy/paste the following command: sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u sammy --hp /home/sammy

      Exécutez la commande à partir de la sortie, avec votre nom d’utilisateur à la place de sammy : 

      • sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u sammy --hp /home/sammy

      Comme étape supplémentaire, nous pouvons sauvegarder la liste des processus PM2 et les environnements correspondants :

      Vous avez maintenant créé une unité systemd qui exécute pm2 pour votre utilisateur au démarrage. Cette instance pm2, à son tour, lance hello.js.

      Démarrer le service avec systemctl: 

      • sudo systemctl start pm2-sammy

      Si, à ce stade, un message d’erreur s’affiche, vous devrez peut-être redémarrer, ce que vous pouvez faire avec sudo reboot. 

      Vérifiez l’état de l’unité systemd :

      • systemctl status pm2-sammy

      Pour un aperçu détaillé de systemd, veuillez consulter Les Fondamentaux de Systemd : Travailler avec les services, les unités et le journal. 

      En plus de celles que nous avons couvertes, PM2 fournit de nombreuses sous-commandes qui vous permettent de gérer ou de rechercher des informations sur vos demandes.

      Arrêtez une application avec cette commande (spécifiez le nom ou l’identifiant de l’application PM2) :

      Redémarrer une application :

      • pm2 restart app_name_or_id

      Liste des applications actuellement gérées par PM2 :

      Obtenez des informations sur une application spécifique en utilisant son Nom d'application: 

      Le moniteur du processus PM2 peut être remonté avec la sous-commande monit.  Il affiche l’état de l’application, l’unité centrale et l’utilisation de la mémoire :

      Notez que l’exécution de pm2 sans aucun argument affichera également une page d’aide avec des exemples d’utilisation.

      Maintenant que votre application Node.js est exécutée et gérée par PM2, mettons en place le proxy inverse.

      Étape 4 — Configurer Nginx en tant que serveur proxy inverse

      Votre application fonctionne et écoute sur localhost, mais vous devez mettre en place un moyen pour que vos utilisateurs y accèdent. Pour cela, nous allons mettre en place le serveur web Nginx comme proxy inverse.

      Dans le tutoriel inclus dans les conditions préalables, vous configurez votre Nginx dans le fichier /etc/nginx/sites available/example.com. Ouvrez ce fichier pour le modifier :

      • sudo nano /etc/nginx/sites-available/example.com

      Dans le bloc de serveurs, vous devez avoir un location/bloc existant. Remplacez le contenu de ce bloc par la configuration suivante. Si votre application est configurée pour écouter sur un port différent, mettez à jour la partie en surbrillance avec le numéro de port correct :

      /etc/nginx/sites-available/example.com

      server {
      ...
          location / {
              proxy_pass http://localhost:3000;
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection 'upgrade';
              proxy_set_header Host $host;
              proxy_cache_bypass $http_upgrade;
          }
      ...
      }
      

      Cela permet de configurer le serveur pour qu’il réponde aux demandes à son root. En supposant que notre serveur soit disponible à l’adresse example.com, l’accès à https://example.com/ via un navigateur web enverrait la demande à hello.js, en écoute sur le port 3000 de localhost.

      Vous pouvez ajouter des blocs d’location supplémentaires au même bloc de serveur pour permettre l’accès à d’autres applications sur le même serveur. Par exemple, si vous exécutez également une autre application Node.js sur le port 3001, vous pourriez ajouter ce bloc de localisation pour y accéder via https://example.com/app2 :

      /etc/nginx/sites-available/example.com — Optional

      server {
      ...
          location /app2 {
              proxy_pass http://localhost:3001;
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection 'upgrade';
              proxy_set_header Host $host;
              proxy_cache_bypass $http_upgrade;
          }
      ...
      }
      

      Une fois que vous avez fini d’ajouter les blocs de localisation pour vos applications, enregistrez le fichier et quittez votre éditeur.

      Assurez-vous que vous n’avez pas introduit d’erreurs de syntaxe en tapant :

      Redémarrez Nginx :

      • sudo systemctl restart nginx

      En supposant que votre application Node.js fonctionne, et que votre application et les configurations Nginx sont correctes, vous devriez maintenant pouvoir accéder à votre application via le proxy inverse Nginx. Essayez-le en accédant à l’URL de votre serveur (son adresse IP publique ou son nom de domaine).

      Conclusion

      Félicitations. Vous avez maintenant votre application Node.js fonctionnant derrière un proxy inverse Nginx sur un serveur Ubuntu 20.04. Cette configuration de proxy inverse est suffisamment souple pour permettre à vos utilisateurs d’accéder à d’autres applications ou à du contenu web statique que vous souhaitez partager.



      Source link