Comment configurer une application Django évolutive avec des bases de données et des espaces gérés par DigitalOcean

De Get Docs
Aller à :navigation, rechercher

Introduction

Django est un framework Web puissant qui peut vous aider à lancer rapidement votre application Python ou votre site Web. Il comprend plusieurs fonctionnalités pratiques comme un mappeur relationnel objet, une API Python et une interface d'administration personnalisable pour votre application. Il comprend également un cadre de mise en cache et encourage la conception d'applications propres grâce à son URL Dispatcher et Template system.

Prêt à l'emploi, Django inclut un serveur Web minimal pour les tests et le développement local, mais il doit ê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 Gunicorn pour servir l'application.

Dans ce guide, nous augmenterons cette configuration en déchargeant des fichiers statiques tels que les feuilles de style Javascript et CSS vers DigitalOcean Spaces, et éventuellement en les livrant à l'aide d'un Ccontenu Dlivraison N[X208X ]etwork, ou CDN, qui stocke ces fichiers plus près des utilisateurs finaux pour réduire les temps de transfert. Nous utiliserons également une base de données PostgreSQL gérée par DigitalOcean 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 sudo configurés. Vous pouvez apprendre à le configurer en parcourant la Configuration initiale du serveur avec Ubuntu 18.04.
  • Un cluster PostgreSQL géré par DigitalOcean. Pour savoir comment créer un cluster, consultez la documentation du produit DigitalOcean Managed Databases.
  • 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 produit Comment créer des espaces, et pour savoir comment créer des clés d'accès pour les espaces, consultez Partager l'accès aux espaces avec des clés d'accès.
  • Nginx 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 de Let's Encrypt, veuillez consulter Comment sécuriser Nginx avec Let's Encrypt sur Ubuntu 18.04.

É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 Python pip pour installer des composants supplémentaires un peu plus tard.

Nous devons d'abord mettre à jour l'index de package local apt, puis télécharger et installer les packages.

Dans ce guide, nous utiliserons Django avec Python 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-client

Cela installera pip, les fichiers de développement Python nécessaires pour construire Gunicorn, les fichiers d'en-tête libpq nécessaires pour construire l'adaptateur Python PostgreSQL Pyscopg et le client de ligne de commande PostgreSQL.

Appuyez sur Y puis sur ENTER 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.

Étape 2 - Création de la base de données PostgreSQL et de l'utilisateur

Nous allons maintenant créer une base de données et un utilisateur de base de données pour notre application Django.

Pour commencer, saisissez les Paramètres de connexion de votre cluster en accédant à Bases de données depuis le Panneau de configuration du cloud, puis en cliquant sur votre base de données. Vous devriez voir une boîte Connection Details contenant certains paramètres pour votre cluster. Notez-les.

De retour sur la ligne de commande, connectez-vous à votre cluster à l'aide de ces identifiants et du client PostgreSQL psql que nous venons d'installer :

psql -U username -h host -p port -d database -set=sslmode=require

Lorsque vous y êtes invité, saisissez le mot de passe affiché à côté du nom d'utilisateur Postgres et appuyez sur ENTER.

Vous recevrez une invite PostgreSQL à partir de laquelle vous pourrez gérer la base de données.

Commencez par créer une base de données pour votre projet appelée polls :

CREATE DATABASE polls;

Remarque : 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 passer à la base de données polls :

\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 base de données afin que les valeurs correctes n'aient pas à être interrogées et définies à chaque fois qu'une connexion est établie.

Nous définissons l'encodage par défaut sur UTF-8, ce que Django attend. Nous définissons également le schéma d'isolement des transactions par défaut sur « lecture validée », ce qui bloque les lectures à partir de transactions non validées. Enfin, nous définissons le fuseau horaire. Par défaut, nos projets Django seront configurés pour utiliser UTC. Ce sont toutes des recommandations de le projet Django lui-même.

Saisissez les commandes suivantes à l'invite 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';

Nous pouvons maintenant 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 PostgreSQL en tapant :

\q

Votre application Django est maintenant prête à se connecter et à gérer cette base de données.

Dans l'étape suivante, nous installerons virtualenv et créerons un environnement virtuel Python pour notre projet Django.

É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 commande virtualenv. Nous pouvons l'installer avec pip.

Mettez à niveau pip et installez le package en tapant :

sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenv

Avec virtualenv installé, nous pouvons créer un répertoire pour stocker nos environnements virtuels Python et en créer un à utiliser avec l'application Django polls.

Créez un répertoire appelé envs et naviguez-y :

mkdir envs
cd envs

Dans ce répertoire, créez un environnement virtuel Python appelé polls en tapant :

virtualenv polls

Cela créera un répertoire appelé polls dans le répertoire envs. À l'intérieur, il installera une version locale de Python et une version locale de pip. 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/activate

Votre invite devrait changer pour indiquer que vous travaillez maintenant dans un environnement virtuel Python. Cela ressemblera à ceci : (polls)[email protected]:~/envs$.

Avec votre environnement virtuel actif, installez Django, Gunicorn et l'adaptateur PostgreSQL psycopg2 avec l'instance locale de pip :

Remarque : Lorsque l'environnement virtuel est activé (lorsque votre invite est précédée de (polls)), utilisez pip au lieu de pip3, même si vous utilisez Python 3. La copie de l'environnement virtuel de l'outil est toujours nommée pip, quelle que soit la version de Python.


pip install django gunicorn psycopg2-binary

Vous devriez maintenant avoir tous les logiciels dont vous avez besoin pour exécuter l'application Django polls. Dans l'étape suivante, nous allons créer un projet Django et installer cette application.

Étape 4 - Création de l'application Polls Django

Nous pouvons maintenant configurer notre exemple d'application. Dans ce didacticiel, nous utiliserons l'application de démonstration Polls de la Documentation Django. Il se compose d'un site public qui permet aux utilisateurs d'afficher les sondages et d'y voter, et d'un panneau de contrôle administratif qui permet à l'administrateur de modifier, créer et supprimer des sondages.

Dans ce guide, nous allons ignorer les étapes du didacticiel et cloner simplement l'application finale à partir de la communauté DigitalOcean django-polls repo.

Si vous souhaitez effectuer les étapes manuellement, créez un répertoire appelé django-polls dans votre répertoire personnel et accédez-y :

cd
mkdir django-polls
cd django-polls

À partir de là, vous pouvez suivre le tutoriel Writing your first Django app de la documentation officielle de Django. Lorsque vous avez terminé, passez à Étape 5.

Si vous souhaitez simplement cloner l'application terminée, accédez à votre répertoire personnel et utilisez git pour cloner le dépôt django-polls :

cd
git clone https://github.com/do-community/django-polls.git

cd dedans, et listez le contenu du répertoire :

cd django-polls
ls

Vous devriez voir les objets suivants :

OutputLICENSE  README.md  manage.py  mysite  polls  templates

manage.py est le principal utilitaire de ligne de commande utilisé pour manipuler l'application. polls contient le code d'application polls et mysite contient le code et les paramètres de 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, consultez Creating a Project dans 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.

Étape 5 - Réglage des paramètres de l'application

Dans cette étape, nous allons modifier la configuration par défaut du projet Django pour augmenter 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.py

Commencez par localiser la directive ALLOWED_HOSTS. Cela définit une liste des adresses ou des noms de domaine que vous souhaitez utiliser pour vous connecter à l'instance Django. Une requête entrante avec un en-tête Host ne figurant pas dans cette liste déclenchera une exception. Django exige que vous définissiez ceci pour empêcher une certaine classe de vulnérabilité de sécurité.

Entre crochets, indiquez les adresses IP ou les noms de domaine associés à votre serveur Django. Chaque élément doit être répertorié entre guillemets avec des entrées séparées par une virgule. Votre liste inclura également localhost, puisque vous utiliserez des connexions proxy via une instance Nginx locale. Si vous souhaitez inclure des demandes pour un domaine entier et des sous-domaines, ajoutez un point au début de l'entrée.

Dans l'extrait ci-dessous, il y a quelques exemples commentés qui montrent à quoi ces entrées devraient ressembler :

~/django-polls/monsite/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 par DATABASES. La configuration dans le fichier est pour 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ées psycopg2 que nous avons installé avec pip, au lieu du moteur SQLite par défaut. Nous réutiliserons également les Paramètres de connexion référencés à l'Étape 2. Vous pouvez toujours trouver ces informations dans la section Bases de données gérées du DigitalOcean Cloud Control Panel.

Mettez à jour le fichier avec vos paramètres de 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 la base de données host et port. Assurez-vous de remplacer les valeurs spécifiques à la base de données par vos propres informations :

~/django-polls/monsite/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, descendez au bas du fichier et ajoutez un paramètre indiquant où les fichiers statiques doivent être placés. Cela est nécessaire pour que Nginx puisse gérer les demandes de ces éléments. La ligne suivante indique à Django de les placer dans un répertoire nommé static dans le répertoire de base du projet :

~/django-polls/monsite/settings.py

. . .

STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

Enregistrez et fermez le fichier lorsque vous avez terminé.

À 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 polls depuis le début et que vous n'avez pas cloné le référentiel GitHub, vous pouvez passer à Étape 6. Si vous avez cloné le référentiel GitHub, il reste une étape supplémentaire.

Le fichier de paramètres Django contient une variable SECRET_KEY qui est utilisée pour créer des hachages pour divers objets Django. Il est important qu'il soit défini sur une valeur unique et imprévisible. La variable SECRET_KEY a été supprimée du référentiel GitHub, nous allons donc en créer une nouvelle à l'aide d'une fonction intégrée au package Python django appelée get_random_secret_key(). Depuis la ligne de commande, ouvrez un interpréteur Python :

python

Vous devriez voir la sortie et l'invite suivantes :

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 fonction get_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é résultante dans votre presse-papiers.

Quittez l'interpréteur Python en appuyant sur CTRL+D.

Ensuite, ouvrez à nouveau le fichier de paramètres dans votre éditeur de texte :

nano ~/django-polls/mysite/settings.py

Localisez la variable SECRET_KEY et collez la clé que vous venez de générer :

~/django-polls/monsite/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 à l'aide du serveur de développement Django pour nous assurer que tout a été correctement configuré.

Étape 6 - Test de l'application

Avant d'exécuter le serveur de développement Django, nous devons utiliser l'utilitaire manage.py pour créer le schéma de la base de données et collecter les fichiers statiques dans le répertoire STATIC_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 commandes makemigrations et migrate :

cd django-polls
./manage.py makemigrations
./manage.py migrate

makemigrations 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, consultez Migrations dans la documentation officielle de Django.

Créez un utilisateur administratif pour le projet en tapant :

./manage.py createsuperuser

Vous devrez sélectionner un nom d'utilisateur, fournir une adresse e-mail, 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 collectstatic

Les fichiers statiques seront ensuite placés dans un répertoire appelé static dans votre répertoire de projet.

Si vous avez suivi le guide de configuration initiale du serveur, vous devriez avoir un pare-feu UFW protégeant votre serveur. Afin de tester le serveur de développement, nous devrons autoriser l'accès au port que nous utiliserons.

Créez une exception pour le port 8000 en tapant :

sudo ufw allow 8000

Test 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:8000

Dans votre navigateur Web, visitez le nom de domaine ou l'adresse IP de votre serveur suivi de :8000 et du chemin polls :

http://server_domain_or_IP:8000/polls

Vous devriez voir l'interface de l'application Polls :

Pour vérifier l'interface d'administration, visitez le 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/admin

Vous devriez voir la fenêtre d'authentification de l'administrateur de l'application Polls :

Saisissez le nom d'utilisateur et le mot de passe d'administration que vous avez créés avec la commande createsuperuser.

Une fois authentifié, vous pouvez accéder à l'interface d'administration de l'application Polls :

Lorsque vous avez terminé d'explorer, appuyez sur CTRL-C dans la fenêtre du terminal pour arrêter le serveur de développement.

Tester l'application avec Gunicorn

La dernière chose que nous voulons faire avant de décharger les fichiers statiques est de tester Gunicorn pour nous assurer qu'il peut servir l'application. Nous pouvons le faire en entrant dans notre répertoire de projet et en utilisant gunicorn pour charger le module WSGI du projet :

gunicorn --bind 0.0.0.0:8000 mysite.wsgi

Cela démarrera Gunicorn sur la même interface que celle sur laquelle le serveur de développement Django fonctionnait. Vous pouvez revenir en arrière et tester à nouveau l'application.

Remarque : 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 relatif du répertoire vers le fichier wsgi.py de Django, le point d'entrée de notre application. Ce fichier définit une fonction appelée application, qui communique avec l'application. Pour en savoir plus sur la spécification WSGI, cliquez ici.

Lorsque vous avez terminé les tests, appuyez sur CTRL-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.

É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 sur DigitalOcean Spaces à l'aide du plugin django-storages. Cela vous permet de faire facilement évoluer Django en centralisant son contenu statique et en libérant des ressources serveur. De plus, vous pouvez diffuser ce contenu statique à l'aide du CDN DigitalOcean Spaces.

Pour un guide complet sur le déchargement des fichiers statiques de Django vers le stockage d'objets, consultez Comment configurer le stockage d'objets avec Django.

Installation et configuration de django-storages

Nous allons commencer par installer le package Python django-storages. Le package django-storages fournit à Django le backend de stockage S3Boto3Storage qui utilise la bibliothèque boto3 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 et boto3 en utilisant pip :

pip install django-storages boto3

Ensuite, ouvrez à nouveau le fichier de paramètres Django de votre application :

nano ~/django-polls/mysite/settings.py

Accédez à la section INSTALLED_APPS du fichier et ajoutez storages à la liste des applications installées :

~/django-polls/monsite/settings.py

. . .

INSTALLED_APPS = [
    . . .
    'django.contrib.staticfiles',
    'storages',
]

. . .

Faites défiler le fichier plus bas jusqu'au STATIC_URL que nous avons précédemment modifié. Nous allons maintenant écraser ces valeurs et ajouter de nouveaux paramètres de backend S3Boto3Storage. Supprimez le code que vous avez saisi 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/monsite/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 : 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, consultez Partager l'accès aux espaces avec des clés d'accès.
  • 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 comme https://nyc3.digitaloceanspaces.com selon la région spatiale.
  • AWS_S3_OBJECT_PARAMETERS Dé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 où 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 sur public-read garantit que les fichiers sont publiquement accessibles 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 n'importe quel backend compatible S3, y compris DigitalOcean Spaces.
  • 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 point de terminaison 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 lorsque vous avez terminé l'édition.

À partir de maintenant, lorsque vous exécuterez collectstatic, Django téléchargera les fichiers statiques de votre application dans l'espace. Lorsque vous démarrez Django, il commence à diffuser des actifs statiques tels que CSS et Javascript à partir de cet espace.

Dans la section suivante, nous allons activer le CDN pour cet espace et éventuellement configurer un sous-domaine personnalisé pour le CDN Spaces. Cela accélérera la livraison des fichiers statiques de votre projet Django en les mettant en cache sur un réseau géographiquement distribué de serveurs périphériques. Pour en savoir plus sur les CDN, consultez Utiliser un CDN pour accélérer la diffusion de contenu statique. Si vous ne souhaitez pas activer Spaces CDN, passez directement à Configuration des en-têtes CORS.

Activation du CDN (facultatif)

Pour activer la livraison de fichiers statiques via le CDN DigitalOcean Spaces, commencez par activer le CDN pour votre DigitalOcean Space. Pour savoir comment procéder, consultez Comment activer le CDN Spaces dans la documentation du produit DigitalOcean.

Si vous souhaitez utiliser un domaine personnalisé avec Spaces CDN, créez l'enregistrement CNAME du sous-domaine et les certificats SSL appropriés en suivant Comment personnaliser le point de terminaison Spaces CDN avec un sous-domaine.

L'utilisation d'un domaine personnalisé avec Spaces CDN est fortement recommandée. Cela améliorera considérablement l'optimisation des moteurs de recherche (SEO) pour votre site en gardant les URL de vos actifs déchargés similaires aux URL de votre site Django. Pour utiliser un domaine personnalisé avec Spaces CDN, vous devez d'abord vous assurer d'ajouter votre domaine à votre compte DigitalOcean. Pour savoir comment procéder, consultez Comment ajouter des domaines.

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 du Panneau de configuration cloud. Vous devriez voir un nouveau lien Endpoints sous le nom de votre espace :

Ces points de terminaison doivent contenir le nom de votre 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 Edge achemine les demandes d'objets Spaces via le CDN, en les servant autant que possible depuis le cache périphérique. Notez ce point de terminaison Edge, car nous l'utiliserons pour configurer le plugin django-storages. Si vous avez créé un sous-domaine pour Spaces CDN, le point de terminaison Subdomain est un alias pour ce point de terminaison Edge.

Ensuite, modifiez à nouveau le fichier de paramètres Django de votre application :

nano ~/django-polls/mysite/settings.py

Accédez à la section Fichiers statiques que nous avons récemment modifiée. Ajoutez le paramètre AWS_S3_CUSTOM_DOMAIN pour configurer le point de terminaison CDN du plug-in django-storages et mettez à jour le paramètre STATIC_URL pour utiliser ce nouveau point de terminaison CDN :

~/django-polls/monsite/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:
# 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 spaces_edge_endpoint_URL par le point de terminaison Edge que vous venez de noter, en tronquant le préfixe https://. Par exemple, si l'URL du point de terminaison Edge est https://example.sfo2.cdn.digitaloceanspaces.com, AWS_S3_CUSTOM_DOMAIN doit être défini sur example.sfo2.cdn.digitaloceanspaces.com.

Si vous avez créé un sous-domaine personnalisé, remplacez spaces_edge_endpoint_URL par le point de terminaison du sous-domaine personnalisé, en tronquant le préfixe https://. Par exemple, si l'URL du point de terminaison du sous-domaine est https://assets.example.com, AWS_S3_CUSTOM_DOMAIN doit être défini sur assets.example.com.

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Lorsque vous démarrez Django, il servira désormais du contenu statique en utilisant le CDN pour votre espace DigitalOcean.

Avant de tester que tout cela fonctionne correctement, nous devons configurer les en-têtes Cross-Origin Resource Sharing (CORS) pour nos fichiers Spaces ou l'accès à certaines ressources 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 à Tester la livraison de fichiers statiques Spaces.

Configuration des en-têtes CORS

Les en-têtes CORS indiquent au navigateur Web qu'une application exécutée dans un domaine peut accéder à des scripts ou à des ressources situés dans un autre. Dans ce cas, nous devons autoriser le partage de ressources cross-origin pour le domaine de notre serveur Django afin que les demandes de fichiers statiques dans l'espace ne soient pas refusées par le navigateur Web.

Remarque : Cette étape n'est nécessaire que si vous n'utilisez pas un sous-domaine personnalisé avec Spaces CDN.


Pour commencer, accédez à la page Paramètres de votre espace à l'aide du panneau de configuration cloud :

Dans la section Configurations CORS, cliquez sur Ajouter.

Ici, sous Origine, entrez l'origine générique, *

Avertissement : Lorsque vous déployez votre application en production, assurez-vous de remplacer cette valeur par votre domaine d'origine exact (y compris le protocole http:// ou https://). Laisser cela comme origine générique n'est pas sécurisé, et nous le faisons ici uniquement à des fins de test, car la définition de l'origine sur http://example.com:8000 (en utilisant un port non standard) n'est actuellement pas prise en charge.


Sous Méthodes autorisées, sélectionnez GET.

Cliquez sur Ajouter un en-tête, et dans la zone de texte qui apparaît, saisissez Access-Control-Allow-Origin.

Définissez Access Control Max Age sur 600 afin que l'en-tête que nous venons de créer expire toutes les 10 minutes.

Cliquez sur Enregistrer les options.

À partir de maintenant, les objets de votre espace contiendront les en-têtes de réponse Access-Control-Allow-Origin appropriés, permettant aux navigateurs Web sécurisés modernes de récupérer ces fichiers sur plusieurs domaines.

Test de la livraison de fichiers statiques Spaces

Nous allons maintenant tester 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écutez collectstatic pour collecter et télécharger des fichiers statiques sur votre espace DigitalOcean :

python manage.py collectstatic

Vous 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: 

Tapez yes et appuyez sur ENTER pour confirmer.

Vous devriez alors voir une sortie comme celle-ci

Output121 static files copied.

Cela confirme que Django a téléchargé avec succès les fichiers statiques de l'application polls sur votre espace. Vous pouvez accéder à votre espace à l'aide du Panneau de configuration cloud et inspecter les fichiers dans le répertoire static.

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

Dans votre navigateur Web, visitez le nom de domaine ou l'adresse IP de votre serveur suivi de :8000 et /admin :

http://server_domain_or_IP:8000/admin

Vous 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 des fichiers source.

Pour ce faire à l'aide de Google Chrome, cliquez avec le bouton droit sur la page et sélectionnez Inspecter.

Vous devriez voir la fenêtre suivante :

À partir de là, cliquez sur Sources 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 et static/admin sous le point de terminaison CDN de votre Space. Dans static/admin, vous devriez voir les répertoires css et fonts.

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 sur CTRL-C dans la fenêtre du terminal pour arrêter Gunicorn.

Vous pouvez désactiver votre environnement virtuel Python actif en saisissant deactivate :

deactivate

Votre invite devrait revenir à la normale.

À ce stade, vous avez réussi à décharger les fichiers statiques de votre serveur Django et vous les servez à 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.

Étape 8 - Création de fichiers de socket et de service systemd pour Gunicorn

Dans Étape 6, nous avons testé que Gunicorn peut interagir avec notre application Django, mais nous devrions implémenter une manière 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 se produit, systemd démarre automatiquement le processus Gunicorn pour gérer la connexion.

Commencez par créer et ouvrir un fichier socket systemd pour Gunicorn avec les privilèges sudo :

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 nous 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.target

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, créez et ouvrez un fichier de service systemd pour Gunicorn avec les privilèges sudo dans votre éditeur de texte. Le nom du fichier de service doit correspondre au nom du fichier socket à l'exception de l'extension :

sudo nano /etc/systemd/system/gunicorn.service

Commencez par la section [Unit], qui spécifie les métadonnées et les dépendances. Nous allons mettre une description de notre service ici et dire au système d'initialisation de ne le démarrer qu'une fois que la cible de mise en réseau a été atteinte. Étant donné que notre service repose sur le socket du fichier socket, nous devons inclure une directive Requires pour indiquer cette relation :

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

Ensuite, nous ouvrirons la section [Service]. Nous allons spécifier l'utilisateur et le groupe sous lesquels nous voulons traiter. Nous donnerons à notre compte d'utilisateur habituel la propriété du processus puisqu'il possède tous les fichiers pertinents. Nous donnerons la propriété du groupe au groupe www-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 vers l'exécutable Gunicorn, qui est installé dans notre environnement virtuel. Nous allons lier 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 processus journald puisse collecter les journaux Gunicorn. Nous pouvons également spécifier ici tous les ajustements facultatifs de Gunicorn, comme le nombre de processus de travail. Ici, nous exécutons Gunicorn avec 3 processus de travail.

Ajoutez la section 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:application

Enfin, nous ajouterons une section [Install]. Cela indiquera à systemd à quoi lier ce service si nous lui permettons de démarrer au démarrage. Nous souhaitons que ce service démarre lorsque le système multi-utilisateurs habituel 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.target

Avec cela, notre fichier de service systemd est terminé. Enregistrez et fermez-le maintenant.

Nous pouvons maintenant démarrer et activer le socket Gunicorn. Cela créera le fichier socket sur /run/gunicorn.sock maintenant et au démarrage. Lorsqu'une connexion est établie avec ce socket, systemd démarre automatiquement le gunicorn.service pour le gérer :

sudo systemctl start gunicorn.socket
sudo systemctl enable gunicorn.socket

Nous pouvons confirmer que l'opération a réussi en vérifiant le fichier socket.

Vérification du fichier Gunicorn Socket

Vérifiez l'état du processus pour savoir s'il a démarré avec succès :

sudo systemctl status gunicorn.socket

Vous 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 fichier gunicorn.sock dans le répertoire /run :

file /run/gunicorn.sock
Output/run/gunicorn.sock: socket

Si la commande systemctl status indique qu'une erreur s'est produite, ou si vous ne trouvez pas le fichier gunicorn.sock dans le répertoire, c'est une indication que le socket Gunicorn n'a pas été créé correctement. Vérifiez les logs du socket Gunicorn en tapant :

sudo journalctl -u gunicorn.socket

Examinez à nouveau votre fichier /etc/systemd/system/gunicorn.socket pour résoudre tout problème avant de continuer.

Test de l'activation du socket

Actuellement, si vous n'avez démarré que l'unité gunicorn.socket, la gunicorn.service ne sera pas active, car la prise n'a encore reçu aucune connexion. Vous pouvez le vérifier en tapant :

sudo systemctl status gunicorn
Output● 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 via curl en tapant :

curl --unix-socket /run/gunicorn.sock localhost

Vous 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 gunicorn
Output● 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 de curl ou la sortie de systemctl status indique qu'un problème s'est produit, consultez les journaux pour plus de détails :

sudo journalctl -u gunicorn

Vous pouvez également vérifier votre fichier /etc/systemd/system/gunicorn.service pour les problèmes. Si vous apportez des modifications à ce fichier, assurez-vous de recharger le démon pour relire la définition du service et redémarrer le processus Gunicorn :

sudo systemctl daemon-reload
sudo systemctl restart gunicorn

Assurez-vous de résoudre tous les problèmes avant de poursuivre la configuration du serveur Nginx.

Étape 8 - Configuration de Nginx HTTPS et du passage de proxy Gunicorn

Maintenant que Gunicorn est configuré de manière plus robuste, nous devons configurer Nginx pour chiffrer les connexions et transférer le trafic vers le 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épertoire sites-available de Nginx. Sinon, suivez Comment sécuriser Nginx avec Let's Encrypt sur Ubuntu 18.04 et revenez à cette étape.

Avant de modifier ce fichier de bloc de serveur example.com, nous allons d'abord supprimer le fichier de bloc de serveur default qui est déployé par défaut après l'installation de Nginx :

sudo rm /etc/nginx/sites-enabled/default

Nous allons maintenant modifier le fichier de blocage du serveur example.com pour transmettre le trafic à Gunicorn au lieu de la page par défaut index.html configurée à l'étape préalable.

Ouvrez le fichier de blocage du serveur correspondant à votre domaine dans votre éditeur :

sudo nano /etc/nginx/sites-available/example.com

Vous 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 bloc de serveur par défaut créé dans Comment installer Nginx sur 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 requêtes entrantes au socket Gunicorn que nous avons créé à l'étape précédente.

Si vous le souhaitez, vous pouvez faire une sauvegarde de ce fichier en utilisant cp. Quittez votre éditeur de texte et créez une sauvegarde appelée example.com.old :

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.old

Maintenant, 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 port 80 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 port 80 et envoyons un en-tête de réponse 301 pour rediriger la requête vers le port HTTPS 443 en utilisant le domaine example.com. Cela redirigera également les requêtes HTTP directes vers l'adresse IP du serveur.

Après ce bloc, ajoutez le bloc de code de configuration suivant qui gère les requêtes HTTPS pour le domaine example.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 port 443 les requêtes atteignant les domaines example.com et www.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 ligne location = /favicon.ico indique à Nginx d'ignorer tout problème lié à la recherche d'un favicon.

Le dernier bloc location = / demande à Nginx de transmettre les requêtes au socket Gunicorn configuré à l'Étape 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.

Après avoir collé 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 -t

Si votre configuration est sans erreur, redémarrez Nginx en tapant :

sudo systemctl restart nginx

Vous devriez maintenant pouvoir accéder au domaine ou à l'adresse IP de votre serveur pour afficher 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 fichier settings.py. Rouvrez ce fichier dans votre éditeur :

nano ~/django-polls/mysite/settings.py

Faites défiler le fichier jusqu'en bas et ajoutez les paramètres suivants :

~/django-polls/monsite/settings.py

. . .

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_SSL_REDIRECT = True

Ces paramètres indiquent à Django que vous avez activé HTTPS sur votre serveur et lui demandent d'utiliser des cookies "sécurisés". Pour en savoir plus sur ces paramètres, consultez la section SSL/HTTPS de Security 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 transmettre ces requêtes à Gunicorn. HTTPS devrait maintenant être entièrement activé pour votre projet et votre application Django. Si vous rencontrez des erreurs, cette discussion sur le dépannage de Nginx et Gunicorn peut vous aider.

Avertissement : Si vous n'avez pas configuré un sous-domaine personnalisé pour Spaces CDN, comme indiqué dans Configuration des en-têtes CORS, veillez à modifier l'Origine[X167X ] du domaine 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 installé et configuré une application Django évolutive exécutée sur un serveur Ubuntu 18.04. Cette configuration peut être répliquée sur plusieurs serveurs pour créer une architecture hautement disponible. De plus, cette application et sa configuration peuvent être conteneurisées à l'aide de Docker ou d'un autre runtime 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 tel que Kubernetes. Dans une prochaine série de didacticiels, nous explorerons comment conteneuriser et moderniser cette application Django polls afin 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 vers le stockage objet. Pour savoir comment procéder, consultez Utilisation d'Amazon S3 pour stocker les fichiers statiques et multimédias de votre site Django. Vous pouvez également envisager de compresser les fichiers statiques pour optimiser davantage leur diffusion aux utilisateurs finaux. Pour ce faire, vous pouvez utiliser un plugin Django comme Compresseur Django.