Publiez votre application Django sur Amazon Linux + Apache + mod_wsgi

À propos de cet article

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.

Environnement / version à utiliser

Conditions préalables

Connaissances préalables requises pour les lecteurs

Processus de déploiement de l'application Django

De là, nous expliquerons la procédure pour mettre réellement l'application Web créée dans l'environnement de production et la publier.

0. Structure des répertoires / fichiers dans le serveur

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

1. Téléchargez l'application Django locale sur Github

Créer un référentiel local / distant pour git

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]

Création d'un fichier de paramètres (local_settings.py) à exclure de la gestion git

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

Push vers le référentiel distant

Maintenant que vous êtes prêt à pousser, téléchargeons le code source dans un référentiel distant.

$ git push origin master

2. Créer un environnement Python dans une instance EC2

Installation de 3 séries Python

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

Créer un environnement virtuel

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.

3. Placez l'application Django sur le serveur

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.

4. Mise à niveau de sqlite3

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

Référence: Que faire si une erreur SQLite3 se produit lors du démarrage du serveur de développement dans Django 2.2

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é)

5. Paramètres de liaison entre Apache et mod_wsgi

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!

6. Publication de fichiers statiques (css, js, img)

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.

Mécanisme de publication de fichiers statiques

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

Ajout de settings.py

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".

Collecte de fichiers statiques

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

Ajout de paramètres côté Apache

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.

Redémarrage Apache

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

Publiez votre application Django sur Amazon Linux + Apache + mod_wsgi
[Note] Exécutez Django sur Amazon Linux 2
Django + Apache avec mod_wsgi sur Windows Server 2016
Installez Python3 et Django sur Amazon Linux (EC2) et exécutez le serveur Web
Exécutez une application django sur Windows + Apache + mod_wsgi + service.
Initialiser l'application Django
Installer Linux sur Chromebox
Mettez jenv dans Amazon Linux
Installez Django sur Mac
Installez tomcat 5.5 sur Amazon Linux.
Django - Déploiement de l'hôte virtuel mod_wsgi Apache
Installation de Homebrew sur Amazon Linux 2
Installez Python Pillow sur Amazon Linux
Installer Oracle Java8 sur Amazon Linux2
Essayez d'installer OpenAM sur Amazon Linux
Déployer l'application Django sur Heroku
Implémenter l'application Django sur Hy
Page DJango publiée sur heroku: Practice
[Note] Installez Imagick sur Amzon Linux2
Présentation de l'environnement Python 3.5.2 sur Amazon Linux
Exécutez cron sur Amazon Linux (défini sur Linux)
Créez une application Django sur Docker et déployez-la sur AWS Fargate
Comment afficher correctement les fichiers statiques Django sous l'environnement Amazon Linux2 + Apache
L'histoire de l'exécution de l'application asp.net core 3.1 sur la version arm64 Amazon Linux 2
Jusqu'à ce que l'application Django (+ MySQL) soit publiée sur AWS EC2 (+ RDS (+ S3))
J'installe Ruby sur EC2 (Amazon Linux2) 2020
Utilisez Numpy, Scipy, scikit-learn sur Amazon Linux
Django / Apache / mod_wsgi: aucun module nommé importlib
Déployer l'application Django sur Heroku [Partie 2]
Réagir → Ajax → Django sur les notes d'implémentation Linux
Déployer l'application Django sur Heroku [Partie 1]
Comment mettre à jour PHP sur Amazon Linux 2
Découvrez sshd_config et allowed_keys (pour Amazon Linux 2)
CentOS8 + Apache2.4 + pyenv + mod_wsgi + Déploiement de projet Django
CentOS 6.4, Python 2.7.3, Apache, mod_wsgi, Django
5 raisons d'installer Linux sur votre ordinateur portable.
Dockerfile: installer Docker sur un serveur Linux
Création de la première application avec Django startproject
Publiez votre site Web avec responder + Gunicorn + Apache
Installez Python 3.8, Pip 3.8 sur EC2 (Amazon Linux 2)
Publication du projet django développé dans Cloud9 sur heroku
Intégrons Django et apache (httpd) sur Mac! !!
Installez PHP série 7 sur Amazon Linux 2 avec Amazon Linux Extras