Déployer une application Django en production

Déployer une application Django en production

a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

J’ai commencé (dimanche 29 octobre 2017 à 12h32) la rédaction d’un tutoriel au doux nom de « Déployer une application Django en production » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Salut à tous,

Je vous propose ce nouveau tuto sur la mise en production d’une application Django avec Nginx, Supervisord et Gunicorn (assez classique donc). Il me reste quelques TODO encore à couvrir, plus la relecture et re-parcourir le tuto de A à Z pour être sur que tout est bon partout.

N’hésitez pas si vous avez des commentaires ;)

Anto59290

+0 -0

Super !

Si vos fichiers de settings sont dans un sous dossier il est possible de le préciser sous la forme module.sous_module.settings

De mon côté, au lieu d’avoir un fichier settings.py unique, j’ai l’arborescence suivante :

1
2
3
4
5
6
settings/
    __init__.py  # Comme ça 'settings' reste considéré comme un module python
    base.py      # Paramètres par défaut/communs à tous les profils (DEBUG à True)
    dev.py       # Un profil développeur
    test.py      # Un profil test unitaire (par exemple)
    prod.py      # Un profil prod où je mets DEBUG à False et où set les ALLOWED_HOSTS en conséquence

Tu penses quoi de cette configuration ?

Aussi, peut-être rappeler que SECRET_KEY a mieux fait d’être dans une variable d’environnement plutôt que dans le code en dur ? Ca peut aider ceux qui travaillent sur git et qui ont la mauvaise habitude d’avoir des clefs privées / mot de passe versionnés sur git (j’ai fait ce genre d’erreur, fut un temps).

+1 -0

Attention avec les trucs comme sudo apt-get install python-virualenv. Déjà il y a une petite typo (manque un t), et sous Debian par exemple, ça installe virtualenv pour Python 2, pas pour Python 3.

La directive listen permet d’indiquer sur quel port va écouter et répondre Nginx, ici le port 80 (HTTP). A noter que si vous souhaitez rendre votre site compatible HTTPS la configuration serait légèrement différente et l’écoute se ferait sur le port 443.

En général on met les deux, pour rediriger le HTTP vers HTTPS (et puis, qui n’utilise pas de HTTPS en 2017 ? :) )

1
# MUST BE after settings_prod import

Oh, s’il te plaît, enlève cette ligne, ça parle d’un hack pas beau de ZdS qui a causé des gros problèmes :)

(Autre petit détail: Je pense que ça serait bien de ne pas mettre www comme sous-domaine. Ça se fait de moins en moins.)

+0 -0

Salut,

Merci pour vos retours,

Tu penses quoi de cette configuration ?

Petite question, dans ce cas ton fichier init doit importer un fichier différents en fonction de l’environnement sur lequel tu es ?

Aussi, peut-être rappeler que SECRET_KEY a mieux fait d’être dans une variable d’environnement plutôt que dans le code en dur ?

Ge0

C’est pas bête, je vais rajouter quelques précisions sur ça en effet. En général je m’arrange pour que la clé soit dans un vault qui est comité chiffré. Je vais détailler un peu les différentes approches possibles

En général on met les deux, pour rediriger le HTTP vers HTTPS (et puis, qui n’utilise pas de HTTPS en 2017 ? :) )

Ouais, après je voulais pas trop rentrez dans les détails de HTTPS non plus. Mais je vais modifier pour prendre en compte le deux.

(Autre petit détail: Je pense que ça serait bien de ne pas mettre www comme sous-domaine. Ça se fait de moins en moins.)

motet-a

C’est vrai ;)

Merci pour vos retours, Anto

+0 -0

Petite question, dans ce cas ton fichier init doit importer un fichier différents en fonction de l’environnement sur lequel tu es ?

Non, surtout pas, on faisait ça sur ZdS et ça a causé des gros problèmes :)

En fait, il faut soit utiliser la variable d’environnement DJANGO_SETTINGS_MODULE soit l’option --settings du manage.py. Ça donne des choses comme ça :

1
$ ./manage.py runserver --settings monapp.settings.dev

Ou alors:

1
2
$ export DJANGO_SETTINGS_MODULE=monapp.settings.dev
$ ./manage.py runserver

Mais généralement, dans le manage.py, on fait en sorte que DJANGO_SETTINGS_MODULE soit égal à monapp.settings.dev par défaut, sinon ça serait trop pénible.

Bon, évidemment, il ne faut pas oublier de régler correctement ça quand on déploie :)

+0 -0

D’ailleurs, faut bien faire gaffe à modifier le environment=DJANGO_SETTINGS_MODULE='…' dans la config de supervisord. Normalement, ça doit être une valeur comme monapp.settings_prod ou monapp.settings.prod ou quelque chose du genre, en fonction de comment sont organisés et nommés les settings dans l’application.

+1 -0

Est-ce que tu pourrais expliquer comment avoir une adresse comme hello.com et pas hello.com:8010 ?

En prod, je ne m’attends pas à ce que les utilisateurs fassent confiance à une url si "bizarre", eux à qui on n’arrête pas de dire de faire attention au "cadenas vert", à l’url du site, etc.

Et en plus, c’est pas très beau.

+0 -0

Est-ce que tu pourrais expliquer comment avoir une adresse comme hello.com et pas hello.com:8010 ?

amael

Et préciser que le port HTTP par défaut, c’est 80, et pas 8000, 8080 ou 8010 ou même encore 13337 (oops)

Depuis que j’ai déjà posé la question en entretien, il me semble utile de faire une piqûre de rappel à ce sujet.

+0 -0

Ça marche je vais préciser tout ça. Je sais pas comment ça se passe en prod chez vous, mais chez nous l’application est sur le port 81 et le port 80 est réservé pour la couche de cache il me semble.

Anto59290

C’est indépendant du fait que quand tu tapes www.toto.com dans ta barre d’adresse (et pas www.toto.com:81) tu vas effectuer une connexion sur le port 80 sur le serveur cible.

+1 -0

Mais notez que de nos jours, il y a du HTTPS quasi partout sur les gros sites de l’internet “public” (si vous me permettez l’expression) et que par défaut c’est le port 443.

(En fait, le HTTP sur l’internet “public” c’est pratiquement déprécié, la plupart des navigateurs affichent des avertissement de plus en plus marqués à chaque fois qu’on est sur le point d’envoyer des informations personelles via HTTP)

+1 -0
Ce sujet est verrouillé.