Dans cet article, je vais vous présenter le flux de déploiement réel (= publication sur un serveur web) d'une application web créée avec Django dans un environnement de production.
python manage.py runserver, on suppose que vous avez déjà terminé l'opération sur localhost: 8000 sans aucun problème.De là, nous expliquerons la procédure pour mettre réellement l'application Web créée dans l'environnement de production et la publier.
Cette fois, nous visons à placer les fichiers de répertoire comme suit. (Remarque: certaines parties non pertinentes sont omises cette fois)
/
├─var
│ └─www
│ └─html #racine du document Apache
├─etc
│ └─httpd
│ ├─conf
│ │ └─httpd.conf #fichier de configuration apache
│ └─conf.d
│ └─django.conf #Fichier de configuration supplémentaire pour exécuter Django
└─home
└─ec2-user #Voici le premier répertoire pour ssh se connecter à l'instance
└─Django
├─env #Environnement virtuel utilisé pour exécuter les applications Django
└─project #Projet Django
│ manage.py
├─static
├─project
│ │ settings.py
│ │ local_settings.py
│ └─ wsgi.py
└─app
├─templates
└─static
Cette fois, je vais apporter l'application Django dans le serveur via le référentiel distant de Github. Tout d'abord, créez un référentiel distant sur le site Web de Github. Après cela, utilisez la commande suivante directement sous le projet Django pour créer un référentiel local lié au référentiel distant créé.
$ git init
$ git remote add origin [Adresse du référentiel distant]
Voici quelque chose que vous devez faire avant de pousser le contenu de votre référentiel local à distance.
L'application Django a des paramètres qui doivent être modifiés entre l'environnement local et l'environnement distant. Par exemple, dans project / settings.py, il existe une variable appelée DEBUG.
(local)project/settings.py
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
S'il est vrai, il affichera l'emplacement d'erreur détaillé sur le navigateur en cas d'erreur http. Cependant, si cette option est activée dans l'environnement de production, des informations détaillées sur le serveur seront divulguées à un tiers, ce n'est donc pas bon. Par conséquent, il est recommandé de conserver la valeur False dans l'environnement de production.
De plus, il existe une variable appelée SECRET_KEY dans project / settings.py.
(local)project/settings.py
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'pej^q2ql$$#bzg#crh6k_9(p=%p)&6x(kwh@nos&=!$ej&60fh' #example
Cela spécifie la clé privée utilisée pour le chiffrement et le hachage, elle ne doit donc pas être exposée en dehors du projet. En d'autres termes, ne poussez pas le fichier de configuration avec cette valeur vers un référentiel distant sur Github.
Donc,
Placez les informations dans un fichier différent du projet normal / settings.py et excluez-le de la gestion git.
Dans le fichier projet, créez un nouveau fichier appelé local_settings.py et entrez les paramètres que vous ne souhaitez pas gérer avec git.
(local)project/local_settings.py
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'pej^q2ql$$#bzg#crh6k_9(p=%p)&6x(kwh@nos&=!$ej&60fh' #example
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
Après cela, supprimez les informations décrites dans local_settings.py du fichier project / settings.py. Ensuite, ajoutez la ligne suivante en haut pour lire les informations dans local_settings.py.
from .local_settings import *
Le fichier de configuration est maintenant parfait. Ensuite, faisons gérer le git local_settings.py créé.
(local)project/settings.py
$ vi .gitignore
#Écrivez ce qui suit
local_settings.py
Maintenant que vous êtes prêt à pousser, téléchargeons le code source dans un référentiel distant.
$ git push origin master
Python inclus par défaut dans Amazon Linux est 2 séries, vous devez donc installer 3 séries manuellement. Cette fois, installez Python 3.6 et l'outil de développement correspondant avec la commande yum.
$ sudo yum install python36 python36-devel
En faisant cela, 3 séries Python seront placées dans le serveur.
Notez que si vous appuyez simplement sur la commande python, le système par défaut 2 sera utilisé. La commande pour utiliser la série 3 qui vient d'être installée est la commande python3.
$ python -V
Python 2.7.16
$ python3 -V
Python 3.6.8
Cette fois, je placerai l'application Django dans le dossier / home / ec2-user / Django /. Par conséquent, créez un 3e environnement virtuel Python nommé env dans ce dossier Django.
$ cd /home/ec2-user/Django/
$ python3 -m venv env
Vous venez de créer un environnement virtuel. Allez dans cet environnement et utilisez pip pour installer Django et mod_wsgi.
$ source env/bin/activate
$ pip install django mod_wsgi
Si vous utilisez d'autres bibliothèques de framework dans votre application Django (par exemple Django Rest Fremework), assurez-vous de les installer également. Ci-dessous, on suppose que vous travaillerez dans cet environnement virtuel.
Apportez l'application Django du référentiel distant Github préparé en 1. Clonez le référentiel distant dans le dossier / home / ec2-user / Django /.
$ git clone [Adresse du référentiel distant]
Vous avez maintenant correctement importé l'application sur votre serveur. Cependant, comme il existe un paramètre enregistré dans local_settings.py plus tôt, je créerai manuellement local_settings.py sur le serveur.
$ vi /project/project/local_settings.py
#Écrivez ce qui suit
SECRET_KEY = 'pej^q2ql$$#bzg#crh6k_9(p=%p)&6x(kwh@nos&=!$ej&60fh' #Donnez-lui la même valeur que local
DEBUG = False #Puisqu'il s'agit d'un environnement de production, définissez-le sur False.
Maintenant, vérifions avec python manage.py runserver pour voir si Django fonctionne correctement dans l'environnement à l'intérieur du serveur.
À ce stade, si vous pouvez démarrer sans problème, sautez 4 et passez à 5.
À ce stade, vous pouvez obtenir une erreur de version de sqlite3.
$ python manage.py runserver
(réduction)
django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is required (found 3.7.17).
Dans ce cas, vous devez installer sqlite3 avec 3.8.3 ou version ultérieure.
Il y avait des informations selon lesquelles cela ne fonctionnerait pas avec yum, alors j'ai décidé de continuer avec wget.
(Source: [django] Erreur de version SQLite)
#Obtenez la nouvelle version de sqlite3 source
$ wget https://www.sqlite.org/2019/sqlite-autoconf-3300100.tar.gz
$ tar xzf ./sqlite-autoconf-3300100.tar.gz
$ rm -f ./sqlite-autoconf-3300100.tar.gz
#Construire et installer
$ cd ./sqlite-autoconf-3300100/
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
Vérifiez si l'installation a réussi.
#Confirmation de la destination de l'installation
$ sudo find /usr/ -name sqlite3
/usr/lib64/python2.6/sqlite3
/usr/lib64/python3.6/sqlite3
/usr/lib64/python2.7/sqlite3
/usr/bin/sqlite3
/usr/local/bin/sqlite3
#Confirmation de version
$ /usr/bin/sqlite3 --version
3.30.0 2019-10-10 20:19:45 18db032d058f1436ce3dea84081f4ee5a0f2259ad97301d43c426bc7f3df1b0b
J'ai réussi à obtenir sqlite3 avec 3.8.3 ou version ultérieure. Renommez l'ancien sqlite → créez un lien symbolique pour le nouveau sqlite afin que la commande sqlite3 utilise la nouvelle version.
$ sudo mv /usr/bin/sqlite3 /usr/bin/sqlite3_old
$ sudo ln -s /usr/local/bin/sqlite3 /usr/bin/sqlite3
Passez également le chemin pour ajouter la nouvelle version installée de sqlite3 à la bibliothèque partagée.
$ vi /etc/ld.so.conf.d/sqlite3-x86_64.conf
#Écrivez ce qui suit
/usr/local/lib
Une façon de transmettre le chemin d'accès à la bibliothèque partagée consiste à mettre à jour la variable d'environnement LD_LIBRARY_PATH, mais même si vous définissez le paramètre LD_LIBRARY_PATH à un mauvais endroit, il ne sera pas reflété. J'ai donc tranquillement défini le chemin dans ld.so.conf.d. Référence: Cela peut ne pas être reflété même si LD_LIBRARY_PATH est défini
(Articles référencés ci-dessus a écrit le paramètre LD_LIBRARY_PATH dans ~ / .bashrc, mais cela n'a pas fonctionné)
Une fois que vous avez vérifié que Django peut être lancé avec succès sur votre serveur, il est temps de se préparer à le publier sur Apache.
D'abord, utilisez la commande find pour vérifier le chemin où se trouve le mod_wsgi que vous avez entré précédemment.
$ find -name 'mod_*.so'
./env/lib/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so
Ce mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so est le corps principal de mod_wsgi. Notez le chemin que vous venez de vérifier pour une utilisation ultérieure.
Ensuite, ajoutez les paramètres à Apache. Créez un nouveau fichier de configuration qui décrit mod_wsgi avec la commande suivante.
$ sudo vi /etc/httpd/conf.d/django.conf
Cela lancera vi et vous permettra de modifier le fichier. Ici, entrez les paramètres suivants.
/etc/httpd/conf.d/django.conf
LoadModule wsgi_module /home/ec2-user/Django/env/lib64/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so
WSGIScriptAlias / /home/ec2-user/Django/project/project/wsgi.py
WSGIPythonPath /home/ec2-user/Django/env/lib/python3.6/site-packages
WSGIPythonHome /home/ec2-user/Django/env
<Directory /home/ec2-user/Django/project/project>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
La signification du paramètre est la suivante.
--LoadModule: l'emplacement du fichier corps mod_wsgi. --WSGIScriptAlias: paramètre de transfert vers le deuxième script wsgi lors de l'accès à la première URL. Ici, la requête qui parvient à la racine d'Apache est ignorée dans wsgi.py dans le projet Django. --WSGIPythonPath: chemin à passer à Python lors de l'exécution. --WSGIPythonHome: répertoire de base Python pour Apache à utiliser. --Directory ~ Ci-dessous: accorde des autorisations Apache sur le répertoire spécifié.
Référence: Document officiel Comment utiliser Django avec Apache et mod_wsgi
Après avoir rempli, redémarrez Apache.
$ sudo service httpd restart
Si vous accédez à votre site depuis votre navigateur et que le projet que vous avez créé avec Django s'affiche avec succès, vous avez réussi!
Cependant, je pense que mon projet actuellement affiché dans le navigateur est dans un état où css et js ne fonctionnent pas / les images ne sont pas affichées. Cela est dû à la gestion différente des fichiers statiques entre l'environnement de développement et l'environnement de production.
En général, lors du développement d'une application avec Django, les fichiers statiques doivent souvent être stockés dans des dossiers statiques au sein de chaque application.
project
│ manage.py
├─project
│ │ settings.py
│ │ local_settings.py
│ └─ wsgi.py
├─app1
│ ├─templates
│ └─static #Fichier statique utilisé par app1
└─app2
├─templates
└─static #Fichier statique utilisé par app2
Cependant, dans l'environnement de production (= DEBUG est False dans le paramètre), tous les fichiers statiques sont rassemblés au même endroit (généralement directement sous le projet), et le serveur Web (Apache) l'utilise. Par conséquent, il ne reconnaît pas quand statique est distribué pour chaque application comme au moment du développement. Référence: Document officiel Deploy static files Gestion des fichiers statiques dans Django
Django dispose d'un mécanisme qui vous permet de le faire avec une seule commande, sans avoir à créer manuellement un répertoire de fichiers statiques pour votre environnement de production. À partir de là, utilisons-le pour ajouter des paramètres de collecte de fichiers statiques directement sous le projet.
Assurez-vous que vous disposez des paramètres suivants dans project / settings.py:
project/settings.py
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.2/howto/static-files/
STATIC_URL = '/static/'
Ce paramètre doit être présent par défaut. La signification de chacun est la suivante.
--BASE_DIR: chemin de la racine du document de projet (= répertoire principal du projet). --STATIC_URL: URL de distribution de fichiers statiques.
Une fois que cela est confirmé, ajoutez les paramètres suivants à settings.py.
project/settings.py
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
STATIC_ROOT est un paramètre où collecter des fichiers statiques pour l'environnement de production. Ici, le paramètre est "Créer un dossier appelé statique directement sous le projet".
Si vous pouvez le faire, vous êtes prêt à partir. Utilisons des commandes pour collecter les fichiers statiques dispersés pour chaque application à l'emplacement de STATIC_ROOT. Allez directement sous le projet (où manage.py peut être exécuté) et exécutez la commande suivante.
$ python manage.py collectstatic
En exécutant cette commande, un fichier statique sera automatiquement généré directement sous le projet, et tous les fichiers statiques utilisés par l'application y seront stockés.
project
│ manage.py
├─static #Nouveau répertoire
├─project
│ │ settings.py
│ │ local_settings.py
│ └─ wsgi.py
├─app1
│ ├─templates
│ └─static
└─app2
├─templates
└─static
Ensuite, laissez Apache reconnaître le répertoire des fichiers statiques rassemblés en un seul endroit. Ajoutez les paramètres suivants au fichier /etc/httpd/conf.d/django.conf.
/etc/httpd/conf.d/django.conf
Alias /static/ /home/ec2-user/Django/project/static/
<Directory /home/ec2-user/Django/project/static>
Require all granted
</Directory>
La signification de chacun est la suivante.
--Alias: lorsque la première URL est accédée, elle sera transférée vers le deuxième répertoire. Ici, quand on accède à (nom de domaine) / statique (STATIC_ROOT défini dans settings.py), il est ignoré dans le fichier statique de l'environnement de production créé précédemment avec la commande collect static.
--Directory et ci-dessous: accordez des autorisations Apache aux fichiers statiques pour les environnements de production.
Maintenant que vous êtes prêt, redémarrez Apache.
$ sudo service httpd restart
Si vous pouvez accéder à votre domaine depuis votre navigateur et voir votre site avec des fichiers statiques, c'est une belle réussite!
Recommended Posts