Recherche de site Web

Comment déployer des applications Python WSGI en utilisant le serveur Web uWSGI avec Nginx

Introduction

Comme introduit dans notre article de comparaison des serveurs web Python, uWSGI est un vaste projet, capable de faire bien plus que de servir des applications web à lui seul. Cependant, sa vaste gamme de fonctionnalités, combinée à la facilité relative de sa configuration, en fait un excellent choix pour de nombreux besoins de déploiement – surtout lorsqu'il est couplé avec Nginx.

Dans cet article de DigitalOcean, nous avons pour objectif de discuter en profondeur de uWSGI et de passer en revue les étapes nécessaires non seulement pour installer le serveur, mais aussi pour déployer des applications Python basées sur divers cadres, en couvrant chaque étape importante pour des applications de petite, moyenne et même relativement grande taille pour la production.

Nous discuterons également de l'utilisation de Nginx (et pourquoi) avec cette configuration, car Nginx et uWSGI sont conçus nativement pour fonctionner ensemble, formant la pile parfaite pour la plupart des déploiements.

Glossaire

1. Comprendre uWSGI et utiliser Nginx

  1. uWSGI en Bref
  2. Déploiements d'applications Web avec Nginx
  3. Utiliser Nginx comme reverse-proxy avec uWSGI

2. Préparer votre Droplet pour la production

  1. Mise à jour du système d'exploitation par défaut
  2. Configuration de Python, pip et virtualenv
  3. Créer un environnement virtuel (Python)
  4. Télécharger et installer uWSGI
  5. Télécharger et installer Nginx

3. Servir des applications Python WSGI avec uWSGI

  1. WSGI
  2. Objet d'application WSGI (appelable) : wsgi.py
  3. Exécution du serveur
  4. Configurer uWSGI
  5. Configurations courantes pour uWSGI
  6. Gestion du serveur uWSGI et des processus avec des signaux

4. Configuration de Nginx

5. Configuration de uWSGI

6. Astuces, suggestions et configurations diverses pour le serveur de production

Comprendre uWSGI et utiliser Nginx

uWSGI est un projet ambitieux. Son ensemble d'outils vous permet de faire bien plus que simplement héberger des applications web. Puisqu'il fait le travail si bien, et de manière si performante, au fil des ans, il s'est révélé être un outil indispensable pour de nombreux administrateurs système et développeurs en ce qui concerne le déploiement de leurs applications.

Nginx, depuis la version 0.8.40, supporte le protocole uwsgi (celui de uWSGI). Cela permet aux applications WSGI fonctionnant sur uWSGI de communiquer de la meilleure manière possible avec Nginx. Ce que cela signifie pour vous, c'est la possibilité de déploiements très simples à configurer, qui sont hautement flexibles (et fonctionnels) et bénéficient de nombreuses optimisations en coulisses qui l'accompagnent. Dans l'ensemble, cela fait de uWSGI couplé avec Nginx un excellent choix pour de nombreux scénarios de déploiement.

uWSGI en Bref

Ce qui suit est un extrait de l'article de comparaison des serveurs Python de DigitalOcean mentionné ci-dessus :

« Malgré ses conventions de nommage très confuses, uWSGI est en réalité un vaste projet avec de nombreux composants, visant à fournir une pile logicielle complète pour la création de services d'hébergement. L'un de ces composants, le serveur uWSGI, exécute des applications Python WSGI. Il est capable d'utiliser divers protocoles, y compris son propre protocole de câblage uwsgi, qui est quasi-identique à SCGI. Afin de satisfaire la demande compréhensible d'utiliser des serveurs HTTP autonomes devant les serveurs d'application, les serveurs web NGINX et Cherokee sont modularisés pour prendre en charge le protocole uwsgi [propre] de uWSGI, offrant un contrôle direct sur ses processus. »

Points forts de uWSGI

  • uWSGI est livré avec un adaptateur WSGI et prend entièrement en charge les applications Python fonctionnant sur WSGI.

  • Il se connecte à libpython. Il charge le code de l'application au démarrage et agit comme un interpréteur Python. Il analyse les requêtes entrantes et invoque l'appelable Python.

  • Il est livré avec un support direct pour le serveur web NGINX populaire (ainsi que Cherokee+ et lighttpd).

  • C'est écrit en C.

  • Ses différents composants peuvent faire beaucoup plus que d'exécuter une application, ce qui peut être utile pour l'expansion.

  • Actuellement (à la fin de 2013), il est en développement actif et a des cycles de publication rapides.

  • Il dispose de divers moteurs pour exécuter des applications (asynchrones et synchrones).

  • Cela peut signifier un empreinte mémoire plus faible pour fonctionner.

Déploiements d'applications Web avec Nginx

Nginx est un serveur web/proxy (inverse) très performant. Il a gagné en popularité grâce à sa légèreté, sa relative facilité d'utilisation et sa simplicité d'extension (avec des modules complémentaires/plug-ins). Grâce à son architecture, il est capable de gérer beaucoup de requêtes (pratiquement illimitées), ce qui, en fonction de la charge de votre application ou site web, pourrait être vraiment difficile à gérer avec certaines autres alternatives plus anciennes.

Rappelez-vous : “Gérer” les connexions signifie techniquement ne pas les abandonner et être capable de les servir avec quelque chose. Vous devez toujours avoir votre application et votre base de données fonctionnant correctement afin que Nginx puisse servir des réponses aux clients qui ne sont pas des messages d'erreur.

Utiliser Nginx comme reverse-proxy avec uWSGI

De nombreux frameworks et serveurs d'application peuvent servir des fichiers statiques (par exemple, javascript, css, images, etc.) en même temps que les réponses des applications réelles. Cependant, il est préférable de laisser un serveur (proxy inverse) tel que Nginx s'occuper de la gestion de ces fichiers et des connexions (demandes). Cela soulage une grande partie de la charge des serveurs d'application, vous offrant ainsi une performance globale bien meilleure.

À mesure que votre application se développe, vous souhaiterez l'optimiser et, quand viendra le moment, la distribuer sur des serveurs (VPS) afin de pouvoir gérer plus de connexions simultanément et avoir une architecture généralement plus robuste. Avoir un reverse-proxy devant vos serveurs d'application vous aide avec cela dès le début.

L'extensibilité d'Nginx (par exemple, la mise en cache native ainsi que le basculement et d'autres mécanismes) est également un grand atout qui profite aux applications web contrairement aux serveurs d'applications (plus simples).

Exemple d'une architecture de serveur de base :

Client Request ----> Nginx (Reverse-Proxy)
                        |
                       /|\                           
                      | | `-> App. Server I.   127.0.0.1:8081
                      |  `--> App. Server II.  127.0.0.1:8082
                       `----> App. Server III. 127.0.0.1:8083

Remarque : Lorsqu'une application est configurée pour écouter les connexions entrantes sur 127.0.0.1, il ne sera possible de l'accéder qu'en local. Si vous utilisez 0.0.0.0, en revanche, elle acceptera également les connexions de l'extérieur.

Préparer votre Droplet pour la production

Dans cette section, nous allons préparer notre serveur virtuel pour la production (c'est-à-dire pour déployer notre application).

Nous commencerons par :

  • mise à jour du système d'exploitation par défaut

  • télécharger et installer des outils Python courants (c'est-à-dire pip, virtualenv)

  • créer un environnement virtuel pour contenir l'application (à l'intérieur duquel résident ses dépendances telles que uWSGI)

Remarque : Les instructions fournies ici sont brèves. Pour en savoir plus, consultez notre article explicatif sur pip et virtualenv : Outils Python courants : Utiliser virtualenv, Installer avec Pip et Gérer les paquets.

Mise à jour du système d'exploitation par défaut

Remarque : Nous allons effectuer la configuration et les préparations suivantes sur un nouveau VPS, en utilisant des versions récentes des systèmes d'exploitation. En théorie, vous ne devriez pas rencontrer de problèmes en les essayant sur votre serveur. Cependant, si vous l'utilisez déjà activement, nous vous recommandons vivement de passer à un nouveau système avant de faire des essais.

Pour nous assurer que nous avons les dernières versions disponibles des applications par défaut, nous devons mettre à jour notre système.

Pour les systèmes basés sur Debian (c'est-à-dire Ubuntu, Debian), exécutez ce qui suit :

aptitude    update
aptitude -y upgrade

Pour les systèmes basés sur RHEL (c'est-à-dire CentOS), exécutez ce qui suit :

yum -y update

Configuration de Python, pip et virtualenv

Remarque pour les utilisateurs de CentOS/RHEL :

CentOS/RHEL, par défaut, arrive comme un serveur très léger. Son ensemble d'outils, qui est susceptible d'être obsolète pour vos besoins, n'est pas là pour exécuter vos applications mais pour alimenter les outils système du serveur (par exemple YUM).

Afin de préparer votre système CentOS, Python doit être configuré (c'est-à-dire compilé à partir des sources) et pip/virtualenv doivent être installés en utilisant cet interpréteur.

Pour en savoir plus sur Comment configurer Python 2.7.6 et 3.3.3 sur CentOS 6.4 et 5.8, avec pip et virtualenv, veuillez vous référer à : Comment configurer Python 2.7.6 et 3.3.3 sur CentOS.

Sur Ubuntu et Debian, une version récente de l'interpréteur Python que vous pouvez utiliser est fournie par défaut. Cela ne nous laisse qu'un nombre limité de packages supplémentaires à installer :

  • python-dev (outils de développement)

  • pip (pour gérer les paquets)

  • virtualenv (pour créer des environnements virtuels isolés)

python-dev :

python-dev est un package au niveau du système d'exploitation qui contient des outils de développement étendus pour construire des modules Python.

Exécutez la commande suivante pour installer python-dev en utilisant aptitude :

aptitude install python-dev

pip :

pip est un gestionnaire de paquets qui nous aidera à installer les paquets d'application dont nous avons besoin.

Exécutez les commandes suivantes pour installer pip :

curl https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py | python -
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python -
export PATH="/usr/local/bin:$PATH"

Vous pourriez avoir besoin de privilèges sudo.

virtualenv :

Il est préférable de contenir une application Python dans son propre environnement ainsi que toutes ses dépendances. Un environnement peut être décrit (en termes simples) comme un emplacement isolé (un répertoire) où tout réside. À cette fin, un outil appelé virtualenv est utilisé.

Exécutez ce qui suit pour installer virtualenv en utilisant pip :

sudo pip install virtualenv

Créer un environnement virtuel autonome (Python)

Ayant tous les outils nécessaires à notre disposition, nous pouvons créer un environnement pour déployer notre application.

Rappelle-toi : Si tu n'as pas de virtualenv sur ta machine de développement (locale) pour ton projet, tu devrais envisager d'en créer un et de déplacer ton application (ainsi que ses dépendances) à l'intérieur.

Commençons par créer un dossier qui contiendra à la fois l'environnement virtuel et votre module d'application :

Vous pouvez utiliser n'importe quel nom ici pour répondre à vos besoins.

mkdir my_app

Nous pouvons continuer en entrant dans ce dossier et en créant un nouvel environnement virtuel à l'intérieur :

Vous pouvez également choisir le nom que vous voulez pour votre environnement virtuel.

cd my_app
virtualenv my_app_venv

Créons un nouveau dossier là-bas pour contenir également votre module d'application Python :

Ceci est le dossier où votre module d'application résidera.

mkdir app

Et activez l'interpréteur à l'intérieur de l'environnement virtuel pour l'utiliser :

Veuillez vous assurer d'utiliser le nom que vous avez choisi pour votre environnement virtuel si vous avez choisi quelque chose d'autre que « my_app_venv ».

source my_app_venv/bin/activate

En fin de compte, c'est ainsi que votre répertoire principal de déploiement d'application devrait se présenter :

my_app              # Main Folder to Contain Everything Together
  |
  |=== my_app_venv  # V. Env. folder with the Python Int.
  |=== app          # Your application module
  |..
  |.

Télécharger et installer uWSGI

Il est toujours recommandé de regrouper autant que possible tous les éléments liés à l'application à l'intérieur de l'environnement virtuel. Nous allons donc télécharger et installer uWSGI en conséquence.

Si vous ne travaillez pas dans un environnement, uWSGI sera installé globalement (c'est-à-dire disponible à l'échelle du système). Ce n'est pas recommandé. Optez toujours pour l'utilisation de virtualenv.

Pour installer uWSGI en utilisant pip, exécutez ce qui suit :

pip install uwsgi

Rappelez-vous : Pour en savoir plus sur pip, son utilisation et sa fonctionnalité, consultez l'article suivant sur les Outils Python Courants : Utilisation de virtualenv, Installation avec Pip, et Gestion des Paquets.

Télécharger et installer Nginx

Remarque pour les utilisateurs de CentOS/RHEL :

Les instructions ci-dessous ne fonctionneront pas sur les systèmes CentOS. Veuillez consulter les instructions ici pour CentOS.

Exécutez la commande suivante pour utiliser le gestionnaire de paquets par défaut du système aptitude pour installer Nginx :

sudo aptitude install nginx

Pour exécuter Nginx, vous pouvez utiliser ce qui suit :

sudo service nginx start

Pour arrêter Nginx, vous pouvez utiliser ce qui suit :

sudo service nginx stop

Pour redémarrer Nginx, vous pouvez utiliser ce qui suit :

Après chaque reconfiguration de Nginx, un redémarrage ou un rechargement est nécessaire pour que les nouveaux paramètres prennent effet.

sudo service nginx restart

Remarque : Pour en savoir plus sur Nginx sur Ubuntu, veuillez consulter notre article : Comment installer Nginx sur Ubuntu 12.04.

Servir des applications Python WSGI avec uWSGI

Dans cette section, nous verrons comment une application Python WSGI fonctionne avec le serveur web uWSGI. Travailler avec uWSGI pour servir des applications Python WSGI n'est pas très différent des autres conteneurs d'applications. Ce dont uWSGI a besoin, tout comme d'autres serveurs, c'est que votre application lui fournisse un point d'entrée (un callable). Lors du lancement, ce callable, avec les variables de configuration, est passé à uWSGI et il commence à faire son travail. Lorsqu'une requête arrive, il la traite et la transmet au contrôleur de votre application pour le traitement.

Architecture :

........
      /|\                           
     | | `-> App. Server I.   127.0.0.1:8080  <--> Application
     |  `--> App. Server II.  127.0.0.1:8081  <--> Application
      .....

WSGI

WSGI en un mot est une interface entre un serveur web et l'application elle-même. Elle existe pour assurer un moyen standardisé entre divers serveurs et applications (frameworks) afin de travailler ensemble, permettant une interopérabilité lorsque cela est nécessaire (par exemple, passer d'un environnement de développement à un environnement de production), ce qui est un besoin indispensable de nos jours.

Remarque : Si vous êtes intéressé à en savoir plus sur WSGI et les serveurs web Python, consultez notre article : Une comparaison des serveurs web pour les applications web basées sur Python.

Objet d'application WSGI (appelable) : « wsgi.py »

Comme mentionné ci-dessus, les serveurs web fonctionnant sur WSGI ont besoin d'un objet application (c'est-à-dire de votre application).

Avec la plupart des frameworks et applications, cela consiste en un wsgi.py pour contenir et fournir un objet application (ou callable) à utiliser par le serveur.

Nous allons commencer par créer un fichier wsgi.py exemplaire qui sera ensuite importé et utilisé par uWSGI pour exécuter l'application.

Vous pouvez choisir n'importe quel nom à la place de wsgi.py. Cependant, voici ceux qui sont couramment utilisés (par exemple par Django).

Commençons par créer un fichier wsgi.py pour contenir une application WSGI de base.

Exécutez la commande suivante pour créer un wsgi.py à l'aide de l'éditeur de texte nano :

nano wsgi.py

Et continuons en déplaçant (copier/coller) le code de base de l'application WSGI à l'intérieur (qui devrait être remplacé par l'appelable de votre propre application pour la production):

def application(env, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    return ["Hello!"]

Ceci est le fichier qui est inclus par le serveur et chaque fois qu'une requête arrive, le serveur utilise cette application callable pour exécuter les gestionnaires de requêtes de l'application (c'est-à-dire contrôleurs) lors de l'analyse de l'URL (par exemple, mysite.tld/controller/method/variable).

Après avoir placé le code de l'application, appuyez sur CTRL+X puis confirmez avec Y pour enregistrer ce fichier dans le dossier « my_app » aux côtés de l'environnement virtuel et du module d'application contenant votre application réelle.

Remarque : Cette application WSGI est l'exemple le plus basique de son genre. Vous devrez remplacer ce bloc de code par votre propre objet d'application provenant du module d'application.

Une fois que nous avons terminé, voici à quoi devrait ressembler votre répertoire principal de déploiement de l'application :

my_app              # Main Folder to Contain Everything Together
  |
  |=== my_app_venv  # V. Env. folder with the Python Int.
  |=== app          # Your application module
  |
  |--- wsgi.py      # File containing application callable
  |..
  |.

Exécution du serveur

uWSGI a beaucoup d'options et de configurations avec plusieurs manières possibles de les utiliser grâce à sa flexibilité. Sans compliquer les choses dès le départ, nous commencerons par l'utiliser de la manière la plus simple possible et poursuivrons ensuite avec des méthodes plus avancées.

Exemple d'utilisation simple :

uwsgi [option] [option 2] .. -w [wsgi file with app. callable]

Pour simplement exécuter uWSGI afin de commencer à servir l'application à partir de wsgi.py, exécutez la commande suivante :

uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi

Cela fera fonctionner le serveur au premier plan. Si vous souhaitez l'arrêter, appuyez sur CTRL+C.

Pour exécuter le serveur en arrière-plan, exécutez ce qui suit :

uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi &

[!] Important: Lorsque vous exécutez le serveur pour travailler avec Nginx en utilisant la configuration de la section Configurer Nginx, assurez-vous de supprimer --protocol=http de la chaîne d'arguments, sinon Nginx et uWSGI ne pourront pas communiquer entre eux.

Lorsque vous exécutez une application en arrière-plan, vous devrez utiliser un gestionnaire de processus (par exemple, htop) pour la tuer (ou l'arrêter). Voir la section ci-dessous pour plus de détails.

Gestion du serveur uWSGI et des processus avec des signaux

La gestion de uWSGI consiste en des actions effectuées pendant l'exécution. Il existe diverses commandes définies pour cette tâche afin de manipuler le processus :

  • SIGHUP -HUP recharge gracieusement les travailleurs et l'application

  • SIGTERM -TERM “recharge brutalement”

  • SIGINT -INT et SIGQUIT -QUIT tuent tous les travailleurs immédiatement.

  • SIGUSR1 -USR1 imprime des statistiques (stdout)

  • SIGUSR2 -USR2 affiche l'état des travailleurs

  • SIGURG -URG restaure un instantané

  • SIGTSTP -TSTP met en pause, suspend ou reprend une instance

  • SIGWINCH -WINCH réveille un travailleur bloqué dans un syscall

Gestion des exemples avec des signaux :

Redémarrage du serveur avec SIGHUP

Cette commande redémarre le serveur avec aisance. Ce que cela signifie, c'est qu'elle attend que le travail des travailleurs en cours soit terminé, puis elle les termine avant de les relancer en héritant de leurs paramètres.

Utilisation : kill -HUP [PID]

Si vous ne souhaitez pas spécifier le PID, vous pouvez utiliser l'option pidfile pour que uWSGI l'écrive dans un fichier, que vous pouvez ensuite utiliser pour gérer les processus.

Arrêt du serveur avec SIGINT

Pour arrêter le serveur et ses processus, vous devez utiliser le signal -INT. Cela mettra fin à tout ce qui est en arrière-plan.

Exemple : kill -INT [PID]

Configurer Nginx

Après avoir configuré uWSGI pour exécuter notre application, nous devons maintenant faire de même avec Nginx pour qu'il communique avec le(s) serveur(s) uWSGI. Pour cela, nous devons modifier le fichier de configuration de Nginx : nginx.conf

Exécutez la commande suivante pour ouvrir nginx.conf et l'éditer en utilisant l'éditeur de texte nano :

sudo nano /etc/nginx/nginx.conf

Ensuite, vous pouvez remplacer le fichier par l'exemple de configuration suivant afin de faire fonctionner Nginx en tant que reverse-proxy, communiquant avec votre application.

Remarque : Pour en savoir plus sur l'intégration du support SSL, veuillez lire d'abord cet article : Créer un certificat SSL sur Nginx.

Exemple de configuration pour des applications web :

worker_processes 1;

events {

    worker_connections 1024;

}

http {

    sendfile on;
    
    gzip              on;
    gzip_http_version 1.0;
    gzip_proxied      any;
    gzip_min_length   500;
    gzip_disable      "MSIE [1-6]\.";
    gzip_types        text/plain text/xml text/css
                      text/comma-separated-values
                      text/javascript
                      application/x-javascript
                      application/atom+xml;

    # Configuration containing list of application servers
    upstream uwsgicluster {
    
        server 127.0.0.1:8080;
        # server 127.0.0.1:8081;
        # ..
        # .
    
    }

    # Configuration for Nginx
    server {
    
        # Running port
        listen 80;

        # Settings to by-pass for static files 
        location ^~ /static/  {
        
            # Example:
            # root /full/path/to/application/static/file/dir;
            root /app/static/;
        
        }
        
        # Serve a static file (ex. favico) outside static dir.
        location = /favico.ico  {
        
            root /app/favico.ico;
        
        }

        # Proxying connections to application servers
        location / {
        
            include            uwsgi_params;
            uwsgi_pass         uwsgicluster;

            proxy_redirect     off;
            proxy_set_header   Host $host;
            proxy_set_header   X-Real-IP $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Host $server_name;
        
        }
    }
}

Lorsque vous avez terminé de modifier la configuration, appuyez sur CTRL+X et confirmez par Y pour sauvegarder et quitter. Vous devrez redémarrer Nginx pour que les modifications prennent effet.

Exécutez ce qui suit pour redémarrer Nginx :

sudo service nginx stop
sudo service nginx start

Remarque : Pour en savoir plus sur Nginx, veuillez consulter notre article : Comment configurer un serveur Web Nginx sur un VPS.

Configurer uWSGI

Lors du lancement de uWSGI pour servir des applications, il existe plusieurs façons de lui fournir les configurations nécessaires telles que le socket sur lequel exécuter, le nombre de processus, les paramètres du processus maître, etc. Dans cette section, nous allons parler de trois d'entre eux :

  • Passage de configurations en tant qu'arguments

  • Utilisation de fichiers .ini pour les configurations

  • Utiliser des fichiers .json pour les configurations

Remarque : uWSGI prend en charge divers protocoles et méthodes pour récupérer ces fichiers de configuration tels que stdin et HTTP.

Option n°1 : Passer des configurations en tant qu'arguments :

Bien qu'il puisse devenir facilement confus et difficile à gérer par moments, la manière la plus basique de faire fonctionner uWSGI est tout simplement comme n'importe quel autre script shell : en lui fournissant les configurations nécessaires en tant qu'arguments.

Exemple d'utilisation :

uwsgi [option] [option 2] .. -w [wsgi.py with application callable]

Simple server running *wsgi*
uwsgi --socket 127.0.0.1:8080 -w wsgi

Running Pyramid (Paster) applications
uwsgi --ini-paste production.ini

Running web2py applications
uwsgi --pythonpath /path/to/app --module wsgihandler

Running WSGI application with specific module / callable names
uwsgi --module wsgi_module_name --callable application_callable_name
uwsgi -w wsgi_module_name:application_callable_name

Pour plus d'exemples sur la façon d'exécuter uWSGI, envisagez de visiter sa documentation pour des exemples de configurations.

Option #2 : Utilisation de fichiers .ini pour les configurations

Une autre (et probablement) meilleure façon de fournir des configurations à uWSGI est d'utiliser des fichiers .ini. Ces fichiers ont une structure simple (voir l'exemple ci-dessous) et doivent être passés explicitement chaque fois que le script de lancement d'uWSGI est exécuté.

Exemple de structure .ini (example_config.ini):

[uwsgi]
-------------
Settings:
key = value
Comments >> #
-------------

socket = [addr:port]
socket = 127.0.0.1:8080

Base application directory
chdir = /full/path
chdir  = /my_app

WSGI module and callable
module = [wsgi_module_name]:[application_callable_name]
module = app:application

master = [master process (true of false)]
master = true

processes = [number of processes]
processes = 5

..

Exemple d'utilisation :

uwsgi --ini example_config.ini

Option #3 : Utilisation de fichiers .json pour les configurations

Travailler avec des fichiers .json est, à part la structure, similaire aux exemples montrés ci-dessus.

Exemple de structure .json (example_config.json):

{
    "uwsgi": {
        "socket": ["127.0.0.1:8080"],
        "module": "my_app:app",
        "master": true,
        "processes": 5,
    }
}

Exemple d'utilisation :

uwsgi --json example_config.json

Pour en savoir plus sur la configuration de uWSGI, envisagez de lire sa documentation sur la configuration.

Configurations courantes pour uWSGI

Par défaut, ce serveur est conçu pour être agnostique par rapport aux frameworks/applications/plateformes. Bien qu'il prenne probablement en charge tout ce dont vous pourriez avoir besoin, certaines options devront être définies explicitement pour répondre à vos exigences.

Comme indiqué dans sa propre documentation, le nombre de façons possibles de configurer uWSGI est presque infini. Dans cette section, nous allons essayer de passer en revue les options les plus couramment utilisées ou critiques et d'expliquer leur mise en œuvre, ce qui, combiné à la section précédente, vous permettra d'exécuter uWSGI exactement comme vous en avez besoin.

Pour les optimisations, veuillez vous référer à la section suivante après celle-ci.

La syntaxe utilisée dans les exemples ci-dessous est destinée aux fichiers .ini. Vous pouvez les modifier pour répondre à vos besoins spécifiques comme vous le souhaitez (par exemple, pour des configurations basées sur .json, comme expliqué dans la section précédente).

Prises

socket-http

Configure uWSGI pour qu'il soit lié à une certaine socket HTTP.

Exemple : http-socket=:8080

prise

Configure uWSGI pour être lié au socket spécifié en utilisant le protocole par défaut.

Exemple : socket=127.0.0.1:8080

processus (travailleurs)

Les deux termes peuvent être utilisés pour désigner la même chose : le nombre de processus générés pour accepter les demandes.

Exemple : processus=5

protocole

Par défaut, uWSGI fonctionne avec son propre protocole uwsgi. Cette propriété vous permet de le changer.

Exemple : protocole=http

Gestion

maître

Cette option est utilisée pour activer ou désactiver un processus maître uWSGI. Ces processus sont utilisés pour gérer les travailleurs qui acceptent et traitent les requêtes entrantes. Les avantages sont nombreux, y compris le redémarrage en douceur des travailleurs sans toucher aux sockets, ce qui vous permet d'effectuer des mises à jour sans temps d'arrêt.

Exemple : maître=vrai

max-demandes

Si vous êtes inquiet au sujet des fuites de mémoire et que vous ne pouvez pas penser à un moyen plus solide de les gérer, cette option vous permettra de redémarrer vos processus automatiquement après avoir traité le nombre défini de requêtes spécifié.

Exemple : max-requests=1001

fils

Paramètres pour exécuter chaque processus avec le nombre spécifié de threads en mode de restructuration. Il est possible de combiner cette option avec processus afin d'obtenir une concurrence à des degrés variés.

Exemple : threads=2

Journalisation

désactiver-l'enregistrement

Utilisé pour désactiver la fonctionnalité de journalisation.

Exemple : désactiver-enregistrement=vrai

processus uWSGI

nom de la procédure

Vous permet de définir le nom du processus selon votre choix.

Exemple : procname=Mon Application

uid

Définissez l'utilisateur du serveur uWSGI sur le uid spécifié.

Exemple : uid=1001

gid

Définissez le serveur uWSGI gid sur celui spécifié.

Exemple : gid=555

aspirateur

Supprime tous les fichiers pid/sockets générés lors de la sortie.

démoniser

Ce paramètre daemonise uWSGI et écrit des messages dans le fichier de log fourni.

Exemple : daemonize=/tmp/uwsgi_daemonize.log

fichier PID

Configurez uWSGI pour écrire le PID du processus dans un fichier spécifié par l'option. Cette option est très utile pour la gestion des processus uWSGI en cours d'exécution (voir la section Gestion d'uWSGI pour plus d'informations).

Exemple : pidfile=/tmp/proj_pid.pid

Divers

harakiri

Ce paramètre est utilisé pour définir la durée maximale pendant laquelle un processus est autorisé à accomplir sa tâche avant d'être tué et recyclé à des fins de mémoire/gestion.

Exemple: harakiri=30

Pour tout savoir sur des centaines de configurations disponibles, vous devriez consulter la liste complète située dans la documentation officielle des options de configuration.

Conseils et suggestions divers

Pare-feu :

  • Configurer un pare-feu en utilisant IP Tables

Securiser SSH:

  • Comment protéger SSH avec fail2ban sur Ubuntu
  • Comment protéger SSH avec fail2ban sur CentOS 6

Créer des alertes :

  • Comment envoyer des alertes par e-mail sur un VPS CentOS pour la surveillance système

Surveiller et vérifier les journaux d'accès du serveur quotidiennement :

  • Comment installer et utiliser Logwatch, l'outil d'analyse et de rapport de logs

Soumis par : O.S. Tezer