web-dev-qa-db-fra.com

Exécuter Django avec Gunicorn - Meilleures pratiques

Il existe 3 façons d'exécuter une application Django avec gunicorn:

  1. Standard gunicorn + wsgi ( ref Django doc )

    gunicorn project.wsgi:application

  2. Utilisation de gunicorn Django integration (ref gunicorn doc and Django doc ):

    python manage.py run_gunicorn

  3. En utilisant gunicorn_Django commande (ref gunicorn doc )

    gunicorn_Django [OPTIONS] [SETTINGS_PATH]

La documentation de Django suggère d'utiliser 1., qui n'est même pas répertorié comme option dans la documentation de Gunicorn.

Existe-t-il une meilleure pratique sur la meilleure façon d'exécuter une application Django avec gunicorn, et quels sont les avantages/inconvénients prévisibles de ces différentes solutions?

En jetant un coup d'œil à code de gunicorn il semble qu'ils font à peu près tous la même chose: 2. semble créer une application wsgi en utilisant les internes de Django, et 3. utilise 2.

Si tel est le cas, je ne comprendrais même pas quelle est la raison de ne pas simplement utiliser "1". tout le temps, surtout depuis un wsgi.py le fichier est créé automatiquement pour vous depuis Django 1.4; si c'est vrai peut-être simplement une amélioration de la documentation devrait être suggérée ...

En outre, la meilleure pratique pour les paramètres gunicorn avec Django serait génial. En utilisant 1., est-il judicieux de définir des valeurs par défaut dans le fichier wsgi et d'éviter des paramètres supplémentaires?

Références:

  1. Dois-je utiliser l'intégration Django-gunicorn ou wsgi? ne concerne que les choix 1. et 3., il n'y a aucune indication pour les paramètres et la réponse ne donne aucune justification
  2. Deploying Django with gunicorn and nginx donne quelques informations plus larges mais n'est pas strictement lié ni répond à cette question
  3. Django Gunicorn wsgi à propos de la version "4", qui lance gunicorn -c configfile et configfile pointeront vers Django_settings vers Django
  4. Django WSGI et Gunicorn est juste un peu déroutant :) mélanger 1. et 3. Bien sûr wsgi.py est utilisé uniquement avec 1.
djangogunicorn
35
Stefano

Après avoir vérifié, je dirais que la meilleure façon d'utiliser gunicorn + wsgi

$ gunicorn project.wsgi:application

Il est maintenant confirmé dans les documents gunicorn: si vous exécutez Django 1.4 ou plus récent, il est fortement recommandé d'exécuter simplement votre application avec l'interface WSGI en utilisant la commande gunicorn et = Django comme lié ci-dessus .

Cela évite également d'ajouter gunicorn en tant qu'application installée, ce qui signifie qu'il n'est pas nécessaire d'installer gunicorn pour tester votre application, ce qui pourrait être utile de temps en temps.

À propos des paramètres

Le fichier de paramètres Django à utiliser peut être transmis via une variable ENV ou personnalisé dans le wsgi.py fichier. Je crée parfois plusieurs wsgi.py fichiers si j'ai plusieurs paramètres (par exemple, plusieurs sites Web) qui doivent s'exécuter à partir du même projet - Voir Django Doc pour plus d'informations.

Une solution à une ligne qui ne nécessite aucun nouveau fichier de commentaire de Carl :

Django_SETTINGS_MODULE=project.settings.prod gunicorn project.wsgi:application

sonne comme une manière plus agréable (bien que je finirai probablement par l'écrire dans certaines commandes Shell pour le rendre plus facile à "mémoriser").

Les paramètres Gunicorn peuvent être passés comme -c settings_file, mais j'explore d'autres moyens et j'essaierai de mettre à jour cette réponse si j'en trouve. L'utilisation de variables d'environnement semble une solution de contournement, mais uniquement pour des cas limités

En particulier, il serait bien d'obtenir/partager certains paramètres entre Django et gunicorn; la documentation de gunicorn dit:

Actuellement, seules les applications Paster ont accès à des paramètres spécifiques au framework. Si vous avez des idées pour fournir des paramètres aux applications WSGI ou pour extraire des informations des paramètres de Django, n'hésitez pas à ouvrir un problème pour nous le faire savoir.

( Mise à jour : je n'ai trouvé aucun moyen plus intelligent, mais après tout, les variables env suffisent pour mes cas les plus courants).

35
Stefano

Je suppose qu'en utilisant run_gunicorn est le chemin à parcourir, c'est aussi le moyen le plus simple de l'utiliser.

C'est fondamentalement la même chose que usign gunicorn project.wsgi:application mais il faut ajouter gunicorn à INSTALLED_APPS pour que Django reconnaît le run_gunicorn, donc ce n'est probablement pas la façon par défaut ...

En utilisant gunicorn_Django est plus ou moins obsolète, comme l'indique également la documentation ici ...

3
Bernhard Vallant

Trouvé une solution qui fonctionne à la fois pour manage.py (sur la machine locale) et avec gunicorn

créer un fichier qui contient toutes les informations

# mysite/settings/set_env.py

import os

_environment = os.getenv('environment', None)
if _environment == "production":
    os.environ.setdefault("Django_SETTINGS_MODULE", "mysite.settings.production")
Elif _environment == "development":
    os.environ.setdefault("Django_SETTINGS_MODULE", "mysite.settings.development")
else:
    os.environ.setdefault("Django_SETTINGS_MODULE", "mysite.settings.local")

et importez ce fichier dans vos fichiers manage.py et wsgi.py, pas besoin de changer quoi que ce soit d'autre dans l'exécution de gunicorn

0
Yarh