introduction
Django est un framework Web puissant qui peut vous aider à lancer rapidement votre application ou site Web Python. Il comprend plusieurs fonctionnalités pratiques comme unobject-relational mapper, une API Python et une interface d'administration personnalisable pour votre application. Il inclut également uncaching framework et encourage la conception d'applications propres grâce à sesURL Dispatcher etTemplate system.
Django inclut dès le départ un serveur Web minimal pour les tests et le développement local, mais il devrait être associé à une infrastructure de service plus robuste pour les cas d'utilisation en production. Django est souvent déployé avec un serveur Web Nginx pour gérer les demandes de fichiers statiques et la redirection HTTPS, et un serveur WSGI deGunicornpour servir l'application.
Dans ce guide, nous allons augmenter cette configuration en déchargeant des fichiers statiques comme les feuilles de style Javascript et CSS vers DigitalOcean Spaces, et éventuellement en les livrant à l'aide d'un réseauContentDeliveryN, ou CDN, qui les stocke les fichiers plus proches des utilisateurs finaux pour réduire les temps de transfert. Nous utiliserons également un DigitalOceanManaged PostgreSQL database comme magasin de données pour simplifier la couche de données et éviter d'avoir à configurer manuellement une base de données PostgreSQL évolutive.
Conditions préalables
Avant de commencer avec ce guide, vous devez disposer des éléments suivants:
-
Une nouvelle instance de serveur Ubuntu 18.04 avec un pare-feu de base et un utilisateur non root avec les privilèges
sudoconfigurés. Vous pouvez apprendre comment configurer cela en parcourant lesInitial Server Setup with Ubuntu 18.04. -
Un cluster PostgreSQL géré par DigitalOcean. Pour savoir comment créer un cluster, consultez le DigitalOceanManaged Databases product documentation.
-
Un espace DigitalOcean pour stocker les fichiers statiques de votre projet Django et un ensemble de clés d’accès pour cet espace. Pour savoir comment créer un espace, consultez la documentation du produitHow to Create Spaces, et pour savoir comment créer des clés d'accès pour les espaces, consultezSharing Access to Spaces with Access Keys.
-
Nginx est installé, sécurisé et configuré sur votre serveur pour fonctionner avec un nom de domaine de votre choix. Pour plus d'informations sur la configuration des enregistrements A et la sécurisation de votre installation Nginx à l'aide deLet’s Encrypt, veuillez consulterHow To Secure Nginx with Let’s Encrypt on Ubuntu 18.04.
[[step-1 -—- Installing-packages-from-the-ubuntu-repositories]] == Étape 1 - Installation de packages à partir des référentiels Ubuntu
Pour commencer, nous allons télécharger et installer tous les éléments dont nous avons besoin à partir des référentiels Ubuntu. Nous utiliserons le gestionnaire de packages Pythonpip pour installer des composants supplémentaires un peu plus tard.
Nous devons d'abord mettre à jour l'index local des packagesapt, puis télécharger et installer les packages.
Dans ce guide, nous utiliserons Django avecPython 3. Pour installer les bibliothèques nécessaires, connectez-vous à votre serveur et tapez:
sudo apt update
sudo apt install python3-pip python3-dev libpq-dev curl postgresql-clientCela installerapip, les fichiers de développement Python nécessaires pour construire Gunicorn, les fichiers d'en-tête libpq nécessaires pour construire l'adaptateur PostgreSQL PythonPyscopg et le client de ligne de commande PostgreSQL.
Appuyez surY puis surENTER lorsque vous êtes invité à commencer le téléchargement et l'installation des packages.
Ensuite, nous allons configurer la base de données pour qu’elle fonctionne avec notre application Django.
[[step-2 -—- creation-the-postgresql-database-and-user]] == Étape 2 - Création de la base de données et de l'utilisateur PostgreSQL
Nous allons maintenant créer une base de données et un utilisateur de base de données pour notre application Django.
Pour commencer, récupérez lesConnection Parameters de votre cluster en accédant àDatabases à partir desCloud Control Panel et en cliquant dans votre base de données. Vous devriez voir une boîteConnection Details contenant quelques paramètres pour votre cluster. Notez ces bas.
De retour sur la ligne de commande, connectez-vous à votre cluster en utilisant ces informations d'identification et le client PostgreSQLpsql que nous venons d'installer:
psql -U username -h host -p port -d database -set=sslmode=requireLorsque vous y êtes invité, entrez le mot de passe affiché à côté du nom d'utilisateur Postgres et appuyez surENTER.
Vous recevrez une invite PostgreSQL à partir de laquelle vous pourrez gérer la base de données.
Tout d'abord, créez une base de données pour votre projet appeléepolls:
CREATE DATABASE polls;[.note] #Note: Chaque instruction Postgres doit se terminer par un point-virgule, assurez-vous donc que votre commande se termine par un si vous rencontrez des problèmes.
#
Nous pouvons maintenant basculer vers la base de donnéespolls:
\c polls;Ensuite, créez un utilisateur de base de données pour le projet. Assurez-vous de sélectionner un mot de passe sécurisé:
CREATE USER myprojectuser WITH PASSWORD 'password';Nous allons maintenant modifier quelques paramètres de connexion pour l'utilisateur que nous venons de créer. Cela accélérera les opérations de la base de données, de sorte qu'il ne sera plus nécessaire de rechercher les valeurs correctes et de les définir à chaque fois qu'une connexion sera établie.
Nous définissons l'encodage par défaut surUTF-8, ce que Django attend. Nous définissons également le schéma d'isolation de transaction par défaut sur «lecture validée», ce qui bloque les lectures des transactions non validées. Enfin, nous établissons le fuseau horaire. Par défaut, nos projets Django seront configurés pour utiliserUTC. Ce sont toutes les recommandations dethe Django project itself.
Entrez les commandes suivantes à l’invite de PostgreSQL:
ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
ALTER ROLE myprojectuser SET timezone TO 'UTC';Maintenant, nous pouvons donner à notre nouvel utilisateur un accès pour administrer notre nouvelle base de données:
GRANT ALL PRIVILEGES ON DATABASE polls TO myprojectuser;Lorsque vous avez terminé, quittez l'invite de PostgreSQL en tapant:
\qVotre application Django est maintenant prête à se connecter à cette base de données et à la gérer.
À l'étape suivante, nous installeronsvirtualenv et créerons un environnement virtuel Python pour notre projet Django.
[[step-3 -—- creation-a-python-virtual-environment-for-your-project]] == Étape 3 - Création d'un environnement virtuel Python pour votre projet
Maintenant que nous avons configuré notre base de données pour fonctionner avec notre application, nous allons créer un environnement virtuel Python qui isolera les dépendances de ce projet de l’installation Python globale du système.
Pour ce faire, nous devons d'abord accéder à la commandevirtualenv. Nous pouvons l'installer avecpip.
Mettez à niveaupip et installez le package en tapant:
sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenvAvecvirtualenv installé, nous pouvons créer un répertoire pour stocker nos environnements virtuels Python et en créer un à utiliser avec l'application Djangopolls.
Créez un répertoire appeléenvs et accédez-y:
mkdir envs
cd envsDans ce répertoire, créez un environnement virtuel Python appelépolls en tapant:
virtualenv pollsCela créera un répertoire appelépolls dans le répertoireenvs. À l'intérieur, il installera une version locale de Python et une version locale depip. Nous pouvons l'utiliser pour installer et configurer un environnement Python isolé pour notre projet.
Avant d’installer les exigences Python de notre projet, nous devons activer l’environnement virtuel. Vous pouvez le faire en tapant:
source polls/bin/activateVotre invite devrait changer pour indiquer que vous travaillez maintenant dans un environnement virtuel Python. Cela ressemblera à quelque chose comme ceci:(polls)user@host:~/envs$.
Avec votre environnement virtuel actif, installez Django, Gunicorn et l'adaptateur PostgreSQLpsycopg2 avec l'instance locale depip:
[.note] #Note: Lorsque l'environnement virtuel est activé (lorsque votre invite est précédée de(polls)), utilisezpip au lieu depip3, même si vous utilisez Python 3. La copie de l’environnement virtuel de l’outil est toujours nomméepip, quelle que soit la version de Python.
#
pip install django gunicorn psycopg2-binaryVous devriez maintenant avoir tous les logiciels dont vous avez besoin pour exécuter l'application Djangopolls. Dans la prochaine étape, nous allons créer un projet Django et installer cette application.
[[step-4 -—- creation-the-polls-django-application]] == Étape 4 - Création de l'application Polls Django
Nous pouvons maintenant configurer notre exemple d'application. Dans ce tutoriel, nous utiliserons l'application de démonstration Polls desDjango documentation. Il se compose d'un site public permettant aux utilisateurs de consulter les sondages et d'y voter, ainsi que d'un panneau de contrôle administratif permettant à l'administrateur de modifier, créer et supprimer des sondages.
Dans ce guide, nous passerons les étapes du didacticiel et clonerons simplement l'application finale à partir de DigitalOcean Communitydjango-polls repo.
Si vous souhaitez effectuer les étapes manuellement, créez un répertoire appelédjango-polls dans votre répertoire de base et accédez-y:
cd
mkdir django-polls
cd django-pollsDe là, vous pouvez suivre le tutoriel deWriting your first Django app de la documentation officielle de Django. Lorsque vous avez terminé, passez àStep 5.
Si vous souhaitez simplement cloner l'application terminée, accédez à votre répertoire personnel et utilisezgit pour cloner lesdjango-polls repo:
cd
git clone https://github.com/do-community/django-polls.gitcd dedans, et listez le contenu du répertoire:
cd django-polls
lsVous devriez voir les objets suivants:
OutputLICENSE README.md manage.py mysite polls templatesmanage.py est le principal utilitaire de ligne de commande utilisé pour manipuler l'application. polls contient le code de l'applicationpolls etmysite contient le code et les paramètres de la portée du projet. templates contient des fichiers de modèles personnalisés pour l'interface d'administration. Pour en savoir plus sur la structure et les fichiers du projet, consultezCreating a Project de la documentation officielle de Django.
Avant d'exécuter l'application, nous devons ajuster ses paramètres par défaut et la connecter à notre base de données.
[[step-5 -—- Adjusting-the-app-settings]] == Étape 5 - Réglage des paramètres de l'application
Au cours de cette étape, nous allons modifier la configuration par défaut du projet Django pour renforcer la sécurité, connecter Django à notre base de données et collecter les fichiers statiques dans un répertoire local.
Commencez par ouvrir le fichier de paramètres dans votre éditeur de texte:
nano ~/django-polls/mysite/settings.pyCommencez par localiser la directiveALLOWED_HOSTS. Ceci définit une liste d'adresses ou de noms de domaines que vous souhaitez utiliser pour vous connecter à l'instance de Django. Une demande entrante avec un en-têteHost ne figurant pas dans cette liste lèvera une exception. Django exige que vous définissiez ceci pour empêcher uncertain class of security vulnerability.
Entre les crochets, répertoriez les adresses IP ou les noms de domaine associés à votre serveur Django. Chaque élément doit être répertorié dans des citations avec des entrées séparées par une virgule. Votre liste comprendra égalementlocalhost, car vous effectuerez un proxy des connexions via une instance Nginx locale. Si vous souhaitez inclure des demandes pour un domaine entier et des sous-domaines, ajoutez une période au début de l'entrée.
Dans l'extrait ci-dessous, quelques exemples commentés montrent à quoi ces entrées devraient ressembler:
~/django-polls/mysite/settings.py
. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
. . .Ensuite, recherchez la section du fichier qui configure l'accès à la base de données. Il commencera parDATABASES. La configuration dans le fichier concerne une base de données SQLite. Nous avons déjà créé une base de données PostgreSQL pour notre projet, nous devons donc ajuster ces paramètres.
Nous dirons à Django d'utiliser l'adaptateur de base de donnéespsycopg2 que nous avons installé avecpip, au lieu du moteur SQLite par défaut. Nous réutiliserons également lesConnection Parameters référencés dansStep 2. Vous pouvez toujours trouver ces informations dans la section Bases de données gérées des DigitalOceanCloud Control Panel.
Mettez à jour le fichier avec les paramètres de votre base de données: le nom de la base de données (polls), le nom d'utilisateur de la base de données, le mot de passe de l'utilisateur de la base de données et les bases de donnéeshost etport. Assurez-vous de remplacer les valeurs spécifiques à la base de données par vos propres informations:
~/django-polls/mysite/settings.py
. . .
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'polls',
'USER': 'myprojectuser',
'PASSWORD': 'password',
'HOST': 'managed_db_host',
'PORT': 'managed_db_port',
}
}
. . .Ensuite, déplacez-vous vers le bas du fichier et ajoutez un paramètre indiquant l'emplacement des fichiers statiques. Cela est nécessaire pour que Nginx puisse gérer les demandes relatives à ces éléments. La ligne suivante indique à Django de les placer dans un répertoire appeléstatic dans le répertoire du projet de base:
~/django-polls/mysite/settings.py
. . .
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')Enregistrez et fermez le fichier lorsque vous avez terminé.
A ce stade, vous avez configuré les paramètres de base de données, de sécurité et de fichiers statiques du projet Django. Si vous avez suivi le tutoriel depolls depuis le début et que vous n'avez pas cloné le dépôt GitHub, vous pouvez passer àStep 6. Si vous avez cloné le rapport GitHub, il reste une étape supplémentaire.
Le fichier de paramètres Django contient une variableSECRET_KEY qui est utilisée pour créer des hachages pour divers objets Django. Il est important qu’elle soit définie sur une valeur unique et imprévisible. La variableSECRET_KEY a été nettoyée du référentiel GitHub, nous allons donc en créer une nouvelle en utilisant une fonction intégrée au package Pythondjango appeléeget_random_secret_key(). A partir de la ligne de commande, ouvrez un interpréteur Python:
pythonVous devriez voir le résultat et l'invite suivants:
OutputPython 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>Importez la fonctionget_random_secret_key du package Django, puis appelez la fonction:
from django.core.management.utils import get_random_secret_key
get_random_secret_key()Copiez la clé obtenue dans votre presse-papiers.
Quittez l'interpréteur Python en appuyant surCTRL+D.
Ensuite, ouvrez à nouveau le fichier de paramètres dans votre éditeur de texte:
nano ~/django-polls/mysite/settings.pyLocalisez la variableSECRET_KEY et collez la clé que vous venez de générer:
~/django-polls/mysite/settings.py
. . .
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'your_secret_key_here'
. . .Enregistrez et fermez le fichier.
Nous allons maintenant tester l’application localement en utilisant le serveur de développement Django pour nous assurer que tout a été correctement configuré.
[[step-6 -—- testing-the-app]] == Étape 6 - Test de l'application
Avant d'exécuter le serveur de développement Django, nous devons utiliser l'utilitairemanage.py pour créer le schéma de base de données et collecter les fichiers statiques dans le répertoireSTATIC_ROOT.
Accédez au répertoire de base du projet et créez le schéma de base de données initial dans notre base de données PostgreSQL à l’aide des commandesmakemigrations etmigrate:
cd django-polls
./manage.py makemigrations
./manage.py migratemakemigrations créera les migrations, ou les modifications de schéma de base de données, en fonction des modifications apportées aux modèles Django. migrate appliquera ces migrations au schéma de base de données. Pour en savoir plus sur les migrations dans Django, consultezMigrations de la documentation officielle de Django.
Créez un utilisateur administratif pour le projet en tapant:
./manage.py createsuperuserVous devrez sélectionner un nom d'utilisateur, fournir une adresse électronique, puis choisir et confirmer un mot de passe.
Nous pouvons collecter tout le contenu statique dans l’emplacement du répertoire que nous avons configuré en tapant:
./manage.py collectstaticLes fichiers statiques seront ensuite placés dans un répertoire appeléstatic dans le répertoire de votre projet.
Si vous avez suivi le guide de configuration initiale du serveur, vous devez disposer d’un pare-feu UFW protégeant votre serveur. Pour tester le serveur de développement, nous devons autoriser l’accès au port que nous allons utiliser.
Créez une exception pour le port8000 en tapant:
sudo ufw allow 8000Test de l'application à l'aide du serveur de développement Django
Enfin, vous pouvez tester votre projet en démarrant le serveur de développement Django avec cette commande:
./manage.py runserver 0.0.0.0:8000Dans votre navigateur Web, accédez au nom de domaine ou à l’adresse IP de votre serveur, suivi de:8000 et du cheminpolls:
http://server_domain_or_IP:8000/pollsVous devriez voir l'interface de l'application Polls:
Pour consulter l'interface d'administration, accédez au nom de domaine ou à l'adresse IP de votre serveur suivi de:8000 et du chemin de l'interface d'administration:
http://server_domain_or_IP:8000/adminLa fenêtre d'authentification de l'administrateur de l'application Polls devrait s'afficher:
Entrez le nom d'utilisateur et le mot de passe administratifs que vous avez créés avec la commandecreatesuperuser.
Après authentification, vous pouvez accéder à l'interface administrative de l'application Polls:
Lorsque vous avez terminé l'exploration, appuyez surCTRL-C dans la fenêtre du terminal pour arrêter le serveur de développement.
Test de l'application à l'aide de Gunicorn
La dernière chose que nous souhaitons faire avant de décharger des fichiers statiques est de tester Gunicorn pour s’assurer qu’il peut servir l’application. Nous pouvons le faire en entrant notre répertoire de projet et en utilisantgunicorn pour charger le module WSGI du projet:
gunicorn --bind 0.0.0.0:8000 mysite.wsgiCeci lancera Gunicorn sur la même interface que celle utilisée par le serveur de développement Django. Vous pouvez revenir en arrière et tester à nouveau l'application.
[.note] #Note: L'interface d'administration n'aura aucun style appliqué car Gunicorn ne sait pas comment trouver le contenu CSS statique responsable de cela.
#
Nous avons passé un module à Gunicorn en spécifiant le chemin du répertoire relatif au fichierwsgi.py de Django, le point d’entrée de notre application ,. Ce fichier définit une fonction appeléeapplication, qui communique avec l'application. Pour en savoir plus sur la spécification WSGI, cliquez surhere.
Lorsque vous avez terminé les tests, appuyez surCTRL-C dans la fenêtre du terminal pour arrêter Gunicorn.
Nous allons maintenant décharger les fichiers statiques de l’application sur DigitalOcean Spaces.
[[step-7 -—- offloading-static-files-to-digitalocean-spaces]] == Étape 7 - Déchargement de fichiers statiques vers des espaces DigitalOcean
À ce stade, Gunicorn peut servir notre application Django mais pas ses fichiers statiques. Habituellement, nous configurons Nginx pour servir ces fichiers, mais dans ce didacticiel, nous les déchargerons vers DigitalOcean Spaces à l'aide du plug-indjango-storages. Cela vous permet d’adapter facilement Django en centralisant son contenu statique et en libérant des ressources du serveur. En outre, vous pouvez fournir ce contenu statique à l'aide du CDN DigitalOcean Spaces.
Pour un guide complet sur le déchargement des fichiers statiques Django vers le stockage d'objets, consultezHow to Set Up Object Storage with Django.
Installation et configuration dedjango-storages
Nous allons commencer par installer le package Python dedjango-storages. Le packagedjango-storages fournit à Django le backend de stockage deS3Boto3Storage qui utilise la bibliothèqueboto3 pour télécharger des fichiers vers n'importe quel service de stockage d'objets compatible S3.
Pour commencer, installez les packages Python`django-storages` etboto3 en utilisantpip:
pip install django-storages boto3Ensuite, ouvrez à nouveau le fichier de paramètres Django de votre application:
nano ~/django-polls/mysite/settings.pyAccédez à la sectionINSTALLED_APPS du fichier et ajoutezstorages à la liste des applications installées:
~/django-polls/mysite/settings.py
. . .
INSTALLED_APPS = [
. . .
'django.contrib.staticfiles',
'storages',
]
. . .- Faites défiler le fichier vers le bas jusqu'aux
STATIC_URLque nous avons précédemment modifiés. Nous allons maintenant remplacer ces valeurs et ajouter de nouveaux paramètres de backendS3Boto3Storage. Supprimez le code que vous avez entré précédemment et ajoutez les blocs suivants, qui incluent les informations d'accès et de localisation de votre espace. N'oubliez pas de remplacer les valeurs surlignées ici par vos propres informations -
~/django-polls/mysite/settings.py
. . .
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.1/howto/static-files/
AWS_ACCESS_KEY_ID = 'your_spaces_access_key'
AWS_SECRET_ACCESS_KEY = 'your_spaces_secret_key'
AWS_STORAGE_BUCKET_NAME = 'your_space_name'
AWS_S3_ENDPOINT_URL = 'spaces_endpoint_URL'
AWS_S3_OBJECT_PARAMETERS = {
'CacheControl': 'max-age=86400',
}
AWS_LOCATION = 'static'
AWS_DEFAULT_ACL = 'public-read'
STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
STATIC_URL = '{}/{}/'.format(AWS_S3_ENDPOINT_URL, AWS_LOCATION)
STATIC_ROOT = 'static/'Nous définissons les éléments de configuration suivants:
-
AWS_ACCESS_KEY_ID: l'ID de clé d'accès pour l'espace, que vous avez créé dans les prérequis du didacticiel. Si vous n’avez pas créé d’ensemble de clés d’accès, consultezSharing Access to Spaces with Access Keys. -
AWS_SECRET_ACCESS_KEY: la clé secrète de l'espace DigitalOcean. -
AWS_STORAGE_BUCKET_NAME: le nom de votre espace DigitalOcean. -
AWS_S3_ENDPOINT_URL: l'URL du point de terminaison utilisée pour accéder au service de stockage d'objets. Pour DigitalOcean, ce sera quelque chose commehttps://nyc3.digitaloceanspaces.comselon la région de l'espace. -
AWS_S3_OBJECT_PARAMETERSDéfinit les en-têtes de contrôle du cache sur les fichiers statiques. -
AWS_LOCATION: définit un répertoire dans le compartiment de stockage d'objets dans lequel tous les fichiers statiques seront placés. -
AWS_DEFAULT_ACL: définit la liste de contrôle d'accès (ACL) pour les fichiers statiques. Le définir surpublic-readgarantit que les fichiers sont accessibles publiquement aux utilisateurs finaux. -
STATICFILES_STORAGE: définit le backend de stockage que Django utilisera pour décharger les fichiers statiques. Ce backend devrait fonctionner avec tout backend compatible S3, y compris les espaces DigitalOcean. -
STATIC_URL: spécifie l'URL de base que Django doit utiliser lors de la génération d'URL pour les fichiers statiques. Ici, nous combinons l'URL du noeud final et le sous-répertoire des fichiers statiques pour construire une URL de base pour les fichiers statiques. -
STATIC_ROOT: spécifie où collecter les fichiers statiques localement avant de les copier dans le stockage d'objets.
Enregistrez et fermez le fichier une fois l’édition terminée.
Désormais, lorsque vous exécutezcollectstatic, Django téléchargera les fichiers statiques de votre application dans l'espace. Lorsque vous démarrez Django, il commence à servir des éléments statiques tels que CSS et Javascript depuis cet espace.
Dans la section suivante, nous activerons le CDN pour cet espace et configurerons éventuellement un sous-domaine personnalisé pour le CDN Spaces. Cela accélérera la livraison des fichiers statiques de votre projet Django en les capturant via un réseau de serveurs Edge réparti géographiquement. Pour en savoir plus sur les CDN, consultezUsing a CDN to Speed Up Static Content Delivery. Si vous ne souhaitez pas activer Spaces CDN, passez directement àConfiguring CORS Headers.
Activation du CDN (facultatif)
Pour activer la livraison de fichiers statiques via le CDN DigitalOcean Spaces, commencez par activer le CDN pour votre espace DigitalOcean. Pour savoir comment procéder, consultezHow to Enable the Spaces CDN de la documentation du produit DigitalOcean.
Si vous souhaitez utiliser uncustom domain avec Spaces CDN, créez l'enregistrement CNAME du sous-domaine et les certificats SSL appropriés en suivantHow to Customize the Spaces CDN Endpoint with a Subdomain.
L'utilisation d'un domaine personnalisé avec Spaces CDN est fortement recommandée. Cela va considérablement améliorer l'optimisation du moteur de recherche (SEO) pour votre site en maintenant vos URL d'actifs déchargés similaires à celles de votre site Django. Pour utiliser un domaine personnalisé avec Spaces CDN, vous devez vous assurer d’abord d’ajouter votre domaine à votre compte DigitalOcean. Pour savoir comment procéder, consultezHow to Add Domains.
Une fois que vous avez activé le CDN pour votre espace et éventuellement créé un sous-domaine personnalisé pour celui-ci, accédez à votre espace à l'aide desCloud Control Panel. Vous devriez voir un nouveau lienEndpoints sous le nom de votre espace:
Ces points d'extrémité doivent contenir votre nom d'espace. Si vous avez créé un sous-domaine personnalisé pour Spaces CDN, cette liste contiendra un point de terminaison supplémentaire appeléSubdomain.
Le point de terminaison deEdge achemine les demandes d'objets Spaces via le CDN, les servant autant que possible à partir du cache périphérique. Notez ce point de terminaison deEdge, car nous allons l'utiliser pour configurer le plugindjango-storages. Si vous avez créé un sous-domaine pour Spaces CDN, le point de terminaisonSubdomain est un alias pour ce point de terminaisonEdge.
Ensuite, modifiez à nouveau le fichier de paramètres Django de votre application:
nano ~/django-polls/mysite/settings.pyAccédez à la section Fichiers statiques que nous avons récemment modifiée. Ajoutez le paramètreAWS_S3_CUSTOM_DOMAIN pour configurer le point de terminaison CDN du plug-indjango-storages et mettez à jour le paramètreSTATIC_URL pour utiliser ce nouveau point de terminaison CDN:
~/django-polls/mysite/settings.py
. . .
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.1/howto/static-files/
# Moving static assets to DigitalOcean Spaces as per:
# https://www.digitalocean.com/community/tutorials/how-to-set-up-object-storage-with-django
AWS_ACCESS_KEY_ID = 'your_spaces_access_key'
AWS_SECRET_ACCESS_KEY = 'your_spaces_secret_key'
AWS_STORAGE_BUCKET_NAME = 'your_space_name'
AWS_S3_ENDPOINT_URL = 'spaces_endpoint_URL'
AWS_S3_CUSTOM_DOMAIN = 'spaces_edge_endpoint_URL'
AWS_S3_OBJECT_PARAMETERS = {
'CacheControl': 'max-age=86400',
}
AWS_LOCATION = 'static'
AWS_DEFAULT_ACL = 'public-read'
STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
STATIC_URL = '{}/{}/'.format(AWS_S3_CUSTOM_DOMAIN, AWS_LOCATION)
STATIC_ROOT = 'static/'Ici, remplacez lesspaces_edge_endpoint_URL par le point de terminaison Edge que vous venez de noter, en tronquant le préfixehttps://. Par exemple, si l'URL du point de terminaison Edge esthttps://example.sfo2.cdn.digitaloceanspaces.com,AWS_S3_CUSTOM_DOMAIN doit être défini surexample.sfo2.cdn.digitaloceanspaces.com.
Si vous avez créé un sous-domaine personnalisé, remplacezspaces_edge_endpoint_URL par le point de terminaison du sous-domaine personnalisé, en tronquant le préfixehttps://. Par exemple, si l'URL du point de terminaison du sous-domaine esthttps://assets.example.com,AWS_S3_CUSTOM_DOMAIN doit être défini surassets.example.com.
Lorsque vous avez terminé, enregistrez et fermez le fichier.
Lorsque vous démarrez Django, il servira maintenant le contenu statique en utilisant le CDN de votre espace DigitalOcean.
Avant de tester que tout fonctionne correctement, nous devons configurer les en-têtesCross-Origin Resource Sharing (CORS) pour nos fichiers Spaces ou l'accès à certains actifs statiques peut être refusé par votre navigateur Web. Si vous utilisez un sous-domaine personnalisé avec Spaces CDN pour le même domaine utilisé par Django, vous pouvez passer directement àTesting Spaces Static File Delivery.
Configuration des en-têtes CORS
Les en-têtes CORS indiquent au navigateur Web qu'une application exécutée sur un domaine peut accéder à des scripts ou à des ressources situées sur un autre. Dans ce cas, nous devons autoriser le partage de ressources d’origine croisée pour le domaine de notre serveur Django afin que les requêtes de fichiers statiques dans l’espace ne soient pas refusées par le navigateur Web.
[.note] #Note: Cette étape n'est nécessaire que si vous utiliseznot un sous-domaine personnalisé avec Spaces CDN.
#
Pour commencer, accédez à la pageSettings de votre espace à l'aide du panneau de configuration Cloud:
Dans la sectionCORS Configurations, cliquez surAdd.
Ici, sousOrigin, entrez l'origine du caractère générique,*
[.warning] #Warning: Lorsque vous déployez votre application en production, veillez à remplacer cette valeur par votre domaine d'origine exact (y compris le protocolehttp:// ouhttps://). Le laisser comme origine générique n'est pas sûr, et nous le faisons ici uniquement à des fins de test car la définition de l'origine surhttp://example.com:8000 (en utilisant un port non standard) n'est actuellement pas prise en charge.
#
SousAllowed Methods, sélectionnezGET.
Cliquez surAdd Header, et dans la zone de texte qui apparaît, entrezAccess-Control-Allow-Origin.
DéfinissezAccess Control Max Age sur600 afin que l'en-tête que nous venons de créer expire toutes les 10 minutes.
Cliquez surSave Options.
À partir de maintenant, les objets de votre espace contiendront les en-têtes de réponseAccess-Control-Allow-Origin appropriés, permettant aux navigateurs Web sécurisés modernes de récupérer ces fichiers dans les domaines.
Tester la livraison de fichiers statiques d'espaces
Nous allons maintenant vérifier que Django sert correctement les fichiers statiques de notre espace DigitalOcean.
Accédez au répertoire de votre application Django:
cd ~/django-pollsÀ partir de là, exécutezcollectstatic pour collecter et télécharger des fichiers statiques sur votre espace DigitalOcean:
python manage.py collectstaticVous devriez voir la sortie suivante:
OutputYou have requested to collect static files at the destination
location as specified in your settings.
This will overwrite existing files!
Are you sure you want to do this?
Type 'yes' to continue, or 'no' to cancel:Tapezyes et appuyez surENTER pour confirmer.
Vous devriez alors voir une sortie comme celle-ci
Output121 static files copied.Cela confirme que Django a correctement téléchargé les fichiers statiques de l'applicationpolls sur votre espace. Vous pouvez accéder à votre espace en utilisant lesCloud Control Panel et inspecter les fichiers dans le répertoirestatic.
Ensuite, nous vérifierons que Django réécrit les URL appropriées.
Démarrez le serveur Gunicorn:
gunicorn --bind 0.0.0.0:8000 mysite.wsgiDans votre navigateur Web, accédez au nom de domaine ou à l’adresse IP de votre serveur, suivi de:8000 et/admin:
http://server_domain_or_IP:8000/adminVous devriez à nouveau voir la fenêtre d'authentification de l'administrateur de l'application Polls, cette fois avec un style correct.
Maintenant, utilisez les outils de développement de votre navigateur pour inspecter le contenu de la page et révéler les emplacements de stockage du fichier source.
Pour ce faire avec Google Chrome, cliquez avec le bouton droit de la souris sur la page et sélectionnezInspect.
Vous devriez voir la fenêtre suivante:
De là, cliquez surSources dans la barre d'outils. Dans la liste des fichiers source dans le volet de gauche, vous devriez voir/admin/login sous le domaine de votre serveur Django etstatic/admin sous le point de terminaison CDN de votre espace. Dansstatic/admin, vous devriez voir les répertoirescss etfonts.
Cela confirme que les feuilles de style et les polices CSS sont correctement servies à partir du CDN de votre espace.
Lorsque vous avez terminé les tests, appuyez surCTRL-C dans la fenêtre du terminal pour arrêter Gunicorn.
Vous pouvez désactiver votre environnement virtuel Python actif en entrantdeactivate:
deactivateVotre invite devrait revenir à la normale.
À ce stade, vous avez correctement déchargé des fichiers statiques de votre serveur Django et vous les fournissez à partir du stockage d’objets. Nous pouvons maintenant passer à la configuration de Gunicorn pour qu'il démarre automatiquement en tant que service système.
[[step-8 -—- creation-systemd-socket-and-service-files-for-gunicorn]] == Étape 8 - Création de sockets systemd et de fichiers de service pour Gunicorn
DansStep 6, nous avons testé que Gunicorn peut interagir avec notre application Django, mais nous devrions implémenter un moyen plus robuste de démarrer et d'arrêter le serveur d'application. Pour ce faire, nous allons créer des fichiers de service et de socket Systemd.
Le socket Gunicorn sera créé au démarrage et écoutera les connexions. Lorsqu'une connexion est établie, systemd lance automatiquement le processus Gunicorn pour gérer la connexion.
Commencez par créer et ouvrir un fichier socket systemd pour Gunicorn avec les privilègessudo:
sudo nano /etc/systemd/system/gunicorn.socketÀ l'intérieur, nous allons créer une section[Unit] pour décrire le socket, une section[Socket] pour définir l'emplacement du socket, et une section[Install] pour s'assurer que le socket est créé au bon moment. Ajoutez le code suivant au fichier:
/etc/systemd/system/gunicorn.socket
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.targetEnregistrez et fermez le fichier lorsque vous avez terminé.
Ensuite, créez et ouvrez un fichier de service systemd pour Gunicorn avec les privilègessudo dans votre éditeur de texte. Le nom de fichier du service doit correspondre au nom de fichier du socket, à l'exception de l'extension:
sudo nano /etc/systemd/system/gunicorn.serviceCommencez par la section[Unit], qui spécifie les métadonnées et les dépendances. Nous allons mettre ici une description de notre service et dire au système init de ne le démarrer que lorsque la cible réseau aura été atteinte. Comme notre service repose sur la socket du fichier socket, nous devons inclure une directiveRequires pour indiquer cette relation:
/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.targetEnsuite, nous allons ouvrir la section[Service]. Nous spécifierons l’utilisateur et le groupe sous lesquels nous voulons traiter. Nous allons donner à notre compte utilisateur habituel la propriété du processus puisqu'il possède tous les fichiers pertinents. Nous donnerons la propriété du groupe au groupewww-data afin que Nginx puisse communiquer facilement avec Gunicorn.
Nous allons ensuite mapper le répertoire de travail et spécifier la commande à utiliser pour démarrer le service. Dans ce cas, nous devrons spécifier le chemin complet de l’exécutable Gunicorn, qui est installé dans notre environnement virtuel. Nous lierons le processus au socket Unix que nous avons créé dans le répertoire/run afin que le processus puisse communiquer avec Nginx. Nous enregistrons toutes les données sur la sortie standard afin que le processusjournald puisse collecter les journaux Gunicorn. Nous pouvons également spécifier ici tous les réglages optionnels de Gunicorn, tels que le nombre de processus de travail. Ici, nous exécutons Gunicorn avec 3 processus de travail.
Ajoutez la section de service suivante au fichier. Assurez-vous de remplacer le nom d'utilisateur indiqué ici par votre propre nom d'utilisateur:
/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/django-polls
ExecStart=/home/sammy/envs/polls/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
mysite.wsgi:applicationEnfin, nous ajouterons une section[Install]. Cela indiquera à systemd à quoi lier ce service si nous lui permettons de démarrer au démarrage. Nous voulons que ce service démarre lorsque le système multi-utilisateurs normal est opérationnel:
/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/django-polls
ExecStart=/home/sammy/envs/polls/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
mysite.wsgi:application
[Install]
WantedBy=multi-user.targetAvec cela, notre fichier de service systemd est complet. Enregistrez et fermez-le maintenant.
Nous pouvons maintenant démarrer et activer le socket Gunicorn. Cela créera le fichier socket à/run/gunicorn.sock maintenant et au démarrage. Lorsqu'une connexion est établie à ce socket, systemd démarrera automatiquement lesgunicorn.service pour le gérer:
sudo systemctl start gunicorn.socket
sudo systemctl enable gunicorn.socketNous pouvons confirmer que l'opération a réussi en vérifiant le fichier de socket.
Vérification du fichier de socket Gunicorn
Vérifiez l'état du processus pour savoir s'il a bien démarré:
sudo systemctl status gunicorn.socketVous devriez voir la sortie suivante:
OutputFailed to dump process list, ignoring: No such file or directory
● gunicorn.socket - gunicorn socket
Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-03-05 19:19:16 UTC; 1h 22min ago
Listen: /run/gunicorn.sock (Stream)
CGroup: /system.slice/gunicorn.socket
Mar 05 19:19:16 django systemd[1]: Listening on gunicorn socket.Ensuite, vérifiez l'existence du fichiergunicorn.sock dans le répertoire/run:
file /run/gunicorn.sockOutput/run/gunicorn.sock: socketSi la commandesystemctl status indique qu’une erreur s’est produite, ou si vous ne trouvez pas le fichiergunicorn.sock dans le répertoire, cela indique que le socket Gunicorn n’a pas été créé correctement. Vérifiez les journaux de la prise Gunicorn en tapant:
sudo journalctl -u gunicorn.socketExaminez à nouveau votre fichier/etc/systemd/system/gunicorn.socket pour résoudre les problèmes avant de continuer.
Test de l'activation des sockets
Actuellement, si vous n'avez démarré que l'unitégunicorn.socket, lesgunicorn.service ne seront pas actifs, car le socket n'a pas encore reçu de connexion. Vous pouvez vérifier cela en tapant:
sudo systemctl status gunicornOutput● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
Active: inactive (dead)Pour tester le mécanisme d'activation du socket, nous pouvons envoyer une connexion au socket viacurl en tapant:
curl --unix-socket /run/gunicorn.sock localhostVous devriez voir la sortie HTML de votre application dans le terminal. Cela indique que Gunicorn a démarré et est en mesure de servir votre application Django. Vous pouvez vérifier que le service Gunicorn est en cours d'exécution en tapant:
sudo systemctl status gunicornOutput● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2019-03-05 20:43:56 UTC; 1s ago
Main PID: 19074 (gunicorn)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/gunicorn.service
├─19074 /home/sammy/envs/polls/bin/python3 /home/sammy/envs/polls/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock mysite.wsgi:application
├─19098 /home/sammy/envs/polls/bin/python3 /home/sammy/envs/polls/bin/gunicorn
. . .
Mar 05 20:43:56 django systemd[1]: Started gunicorn daemon.
Mar 05 20:43:56 django gunicorn[19074]: [2019-03-05 20:43:56 +0000] [19074] [INFO] Starting gunicorn 19.9.0
. . .
Mar 05 20:44:15 django gunicorn[19074]: - - [05/Mar/2019:20:44:15 +0000] "GET / HTTP/1.1" 301 0 "-" "curl/7.58.0"Si la sortie decurl ou la sortie desystemctl status indique qu'un problème est survenu, consultez les journaux pour plus de détails:
sudo journalctl -u gunicornVous pouvez également vérifier votre fichier/etc/systemd/system/gunicorn.service pour des problèmes. Si vous apportez des modifications à ce fichier, veillez à recharger le démon pour relire la définition de service et redémarrer le processus Gunicorn:
sudo systemctl daemon-reload
sudo systemctl restart gunicornAssurez-vous de résoudre tous les problèmes avant de continuer à configurer le serveur Nginx.
[[step-8 -—- configuring-nginx-https-and-gunicorn-proxy-pass]] == Étape 8 - Configurer Nginx HTTPS et Gunicorn Proxy Passing
Maintenant que Gunicorn est configuré de manière plus robuste, nous devons configurer Nginx pour chiffrer les connexions et transférer le trafic au processus Gunicorn.
Si vous avez suivi les prérequis et configuré Nginx avec Let’s Encrypt, vous devriez déjà disposer d’un fichier de blocage de serveur correspondant à votre domaine dans le répertoiresites-available de Nginx. Sinon, suivezHow To Secure Nginx with Let’s Encrypt on Ubuntu 18.04 et revenez à cette étape.
Avant de modifier ce fichier de bloc de serveurexample.com, nous allons d'abord supprimer le fichier de bloc de serveur dedefault qui est déployé par défaut après l'installation de Nginx:
sudo rm /etc/nginx/sites-enabled/defaultNous allons maintenant modifier le fichier de blocage du serveurexample.com pour transmettre le trafic à Gunicorn au lieu de la page par défautindex.html configurée à l'étape des prérequis.
Ouvrez le fichier de blocage du serveur correspondant à votre domaine dans votre éditeur:
sudo nano /etc/nginx/sites-available/example.comVous devriez voir quelque chose comme ce qui suit:
/etc/nginx/sites-available/example.com
server {
root /var/www/example.com/html;
index index.html index.htm index.nginx-debian.html;
server_name example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 404; # managed by Certbot
}Il s'agit d'une combinaison du fichier de blocage du serveur par défaut créé dansHow to Install Nginx on Ubuntu 18.04 ainsi que des ajouts ajoutés automatiquement par Let’s Encrypt. Nous allons supprimer le contenu de ce fichier et écrire une nouvelle configuration qui redirige le trafic HTTP vers HTTPS et transmet les demandes entrantes au socket Gunicorn que nous avons créé à l'étape précédente.
Si vous le souhaitez, vous pouvez effectuer une sauvegarde de ce fichier en utilisantcp. Quittez votre éditeur de texte et créez une sauvegarde appeléeexample.com.old:
sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.oldMaintenant, rouvrez le fichier et supprimez son contenu. Nous allons construire la nouvelle configuration bloc par bloc.
Commencez par coller le bloc suivant, qui redirige les requêtes HTTP au port80 vers HTTPS:
/etc/nginx/sites-available/example.com
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 301 https://example.com$request_uri;
}Ici, nous écoutons les requêtes HTTP IPv4 et IPv6 sur le port80 et envoyons un en-tête de réponse 301 pour rediriger la requête vers le port HTTPS443 en utilisant le domaineexample.com. Cela redirigera également les requêtes HTTP directes vers l’adresse IP du serveur.
Après ce bloc, ajoutez le bloc suivant de code de configuration qui gère les requêtes HTTPS pour le domaineexample.com:
/etc/nginx/sites-available/example.com
. . .
server {
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
server_name example.com www.example.com;
# Let's Encrypt parameters
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location = /favicon.ico { access_log off; log_not_found off; }
location / {
proxy_pass http://unix:/run/gunicorn.sock;
proxy_redirect off;
proxy_set_header Host $http_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-Proto https;
}
}Ici, nous écoutons d'abord sur le port443 les requêtes touchant les domainesexample.com etwww.example.com.
Ensuite, nous fournissons la même configuration Let’s Encrypt incluse dans le fichier de blocage du serveur par défaut, qui spécifie l’emplacement du certificat SSL et de la clé privée, ainsi que certains paramètres de sécurité supplémentaires.
La lignelocation = /favicon.ico indique à Nginx d'ignorer tout problème de recherche d'un favicon.
Le dernier bloclocation = / demande à Nginx de transmettre les requêtes au socket Gunicorn configuré dansStep 8. De plus, il ajoute des en-têtes pour informer le serveur Django en amont qu'une requête a été transmise et pour lui fournir diverses propriétés de requête.
Une fois que vous avez collé dans ces deux blocs de configuration, le fichier final devrait ressembler à ceci:
/etc/nginx/sites-available/example.com
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 301 https://example.com$request_uri;
}
server {
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
server_name example.com www.example.com;
# Let's Encrypt parameters
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location = /favicon.ico { access_log off; log_not_found off; }
location / {
proxy_pass http://unix:/run/gunicorn.sock;
proxy_redirect off;
proxy_set_header Host $http_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-Proto https;
}
}Enregistrez et fermez le fichier lorsque vous avez terminé.
Testez votre configuration Nginx pour les erreurs de syntaxe en tapant:
sudo nginx -tSi votre configuration est sans erreur, redémarrez Nginx en tapant:
sudo systemctl restart nginxVous devriez maintenant pouvoir visiter le domaine ou l’adresse IP de votre serveur pour voir votre application. Votre navigateur doit utiliser une connexion HTTPS sécurisée pour se connecter au backend Django.
Pour sécuriser complètement notre projet Django, nous devons ajouter quelques paramètres de sécurité à son fichiersettings.py. Rouvrez ce fichier dans votre éditeur:
nano ~/django-polls/mysite/settings.pyFaites défiler jusqu'au bas du fichier et ajoutez les paramètres suivants:
~/django-polls/mysite/settings.py
. . .
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_SSL_REDIRECT = TrueCes paramètres indiquent à Django que vous avez activé HTTPS sur votre serveur et lui demandez d’utiliser des cookies «sécurisés». Pour en savoir plus sur ces paramètres, consultez lesSSL/HTTPS section deSecurity in Django.
Lorsque vous avez terminé, enregistrez et fermez le fichier.
Enfin, redémarrez Gunicorn:
sudo systemctl restart gunicornÀ ce stade, vous avez configuré Nginx pour rediriger les requêtes HTTP et les transférer à Gunicorn. HTTPS devrait maintenant être complètement activé pour votre projet et votre application Django. Si vous rencontrez des erreurs, cette discussion surtroubleshooting Nginx and Gunicorn peut vous aider.
[.warning] #Warning: Si vous avez configurénot un sous-domaine personnalisé pour Spaces CDN, comme indiqué dansConfiguring CORS Headers, assurez-vous de changer lesOrigin du caractère générique* à votre nom de domaine (https://example.com dans ce guide) avant de rendre votre application accessible aux utilisateurs finaux.
#
Conclusion
Dans ce guide, vous avez configuré et configuré une application Django évolutive s'exécutant sur un serveur Ubuntu 18.04. Cette configuration peut être répliquée sur plusieurs serveurs pour créer une architecture hautement disponible. En outre, cette application et sa configuration peuvent être conteneurisées à l'aide deDocker ou d'un autre environnement d'exécution de conteneur pour faciliter le déploiement et la mise à l'échelle. Ces conteneurs peuvent ensuite être déployés dans un cluster de conteneurs commeKubernetes. Dans une prochaine série de didacticiels, nous explorerons comment conteneuriser et moderniser cette application Djangopollspour qu'elle puisse s'exécuter dans un cluster Kubernetes.
En plus des fichiers statiques, vous pouvez également souhaiter décharger vos fichiers Django Media sur le stockage d'objets. Pour savoir comment procéder, consultezUsing Amazon S3 to Store your Django Site’s Static and Media Files. Vous pouvez également envisager de compresser des fichiers statiques pour optimiser leur diffusion aux utilisateurs finaux. Pour ce faire, vous pouvez utiliser un plugin Django commeDjango compressor.