Créer une application Django et Gunicorn avec Docker sur Ubuntu

Django est un framework web open-source de haut niveau Python qui peut vous aider à créer rapidement votre application Python. Il encourage un développement rapide et une conception propre et pragmatique en suivant le modèle d'architecture modèle-gabarit-vue. Prêt à l'emploi, le framework est fourni avec les composants d'application modernes nécessaires tels que l'authentification des utilisateurs, le framework de mise en cache, le mappeur objet-relationnel, le répartiteur d'URL, le système de gabarits, et une interface d'administration personnalisable.

Gunicorn ‘Green Unicorn’ est un serveur HTTP WSGI Python pour les systèmes UNIX. Le serveur Gunicorn est compatible avec divers frameworks web, offre d'excellentes performances et consomme peu de ressources serveur. Docker est une plateforme de conteneurs open-source qui existe depuis un certain temps, rendant le développement d'applications rapide, efficace et prévisible.

Dans ce tutoriel, vous acquerrez des compétences dans le développement et le déploiement d'applications web Django conteneurisées et évolutives. Nous utiliserons une application Django Polls créée en suivant les guides d'introduction à Django. Au moment de la rédaction de ce tutoriel, nous l'avons basé sur Django 3.2 pris en charge par Python 3.6 ou version ultérieure. Nous déploierons l'application sous forme de conteneur avec Docker et la servirons avec le serveur Gunicorn. Bien entendu, avant de déployer l'application Django dans un conteneur, vous devrez apporter quelques modifications au code du projet pour gérer des aspects tels que la journalisation vers les flux de sortie standard et l'utilisation des variables d'environnement. Les fichiers statiques tels que le CSS, le JavaScript et les images peuvent être déportés vers des services de stockage d'objets pour permettre une gestion facile des fichiers depuis un emplacement unique dans un environnement multi-conteneurs.

Nous vous montrerons comment implémenter ces modifications en vous basant sur la méthodologie bien définie twelve-factor pour créer des applications web évolutives. Une fois les modifications terminées, vous construirez une image Docker de l'application et déploieriez l'application conteneurisée avec Docker. Nous vous recommandons de suivre les étapes décrites dans le tutoriel pour en acquérir une compréhension complète.

Prérequis

S'agissant d'un tutoriel pratique, nous vous encourageons à disposer de la configuration ci-dessous pour vous aider à le suivre :

• Un serveur Ubuntu 20.04. Vous pouvez suivre les étapes 1 à 4 de ce tutoriel étape par étape pour vous aider à configurer votre serveur Ubuntu sur CloudSigma.

• Assurez-vous d'ajouter un utilisateur avec des privilèges sudo sur les deux nœuds que nous utiliserons pour exécuter les commandes comme décrit dans le tutoriel ci-dessus.

• Installez Docker sur le serveur. Vous pouvez suivre les étapes 1, 2 et 3 de notre tutoriel sur l'installation et l'utilisation de Docker. N'oubliez pas d'ajouter l'utilisateur sudo créé ci-dessus au groupe Docker.

• Un espace de stockage d'objets compatible. Django prend en charge plusieurs services de stockage, comme indiqué dans la documentation de django-storages. Vous pouvez choisir celui que vous préférez et suivre la documentation pour le configurer. Pour ce tutoriel, nous utiliserons MinIO qui est un service de stockage cloud compatible S3.

• Une instance de base de données SQL. Django prend en charge plusieurs bases de données SQL que vous êtes libre de choisir. Pour ce tutoriel, nous utiliserons PostgreSQL. La base de données PostgreSQL ne sera pas déployée dans un conteneur. Nous allons configurer un serveur Ubuntu distinct pour héberger l'instance PostgreSQL afin de garantir notre configuration multi-conteneurs ainsi que la persistance des données. Vous pouvez créer une autre instance Ubuntu 20.04 et suivre ce tutoriel pour Configurer une instance de base de données PostgreSQL sur Ubuntu. N'oubliez pas d'ajouter un rôle dans la base de données PostgreSQL pour votre utilisateur sudo comme expliqué dans les étapes 2 et 3. Ce rôle vous permettra de vous connecter à la base de données à partir des autres serveurs hébergeant vos conteneurs.

Conformément à ces prérequis, vous devriez avoir deux instances de serveur Ubuntu. Une instance exécutera votre conteneur Docker, et l'autre instance exécutera l'instance PostgreSQL. Commençons !

Étape 1 : Configuration de l'instance de base de données PostgreSQL

Dans cette section, nous allons modifier les configurations de Postgres sur le serveur Ubuntu exécutant l'instance Postgres. Cela permettra les connexions à partir d'une adresse IP externe. Une fois connecté, nous pourrons créer une base de données et un rôle d'utilisateur, spécifiques à l'application Django Polls que nous déployons.

Tout d'abord, si vous aviez configuré votre environnement conformément aux Prérequis, vous devriez avoir un rôle dans votre base de données PostgreSQL pour votre utilisateur sudo. Ensuite, nous devons définir un mot de passe pour ce rôle. Tout en étant sur le serveur exécutant PostgreSQL, connectez-vous au terminal Postgres avec la commande suivante :

Une fois sur le terminal Postgres, exécutez la commande \password pour modifier le mot de passe d'un utilisateur. La syntaxe de la commande \password est \password <username>. Dans notre cas, la commande :

Saisissez le mot de passe et confirmez-le. Enregistrez ce mot de passe dans un endroit sûr car vous l'utiliserez plus tard pour vous authentifier depuis l'autre serveur Ubuntu. Après cela, tapez exit et appuyez sur Entrée pour quitter le terminal Postgres.

Si vous aviez activé le pare-feu (ufw) sur l'instance du serveur PostgreSQL, vous devrez autoriser le trafic vers le port par défaut de Postgres 5432. Vous pouvez restreindre le trafic pour qu'il provienne uniquement d'une adresse IP spécifique de votre autre serveur Ubuntu qui exécutera le conteneur Docker. Exécutez la commande suivante pour ajouter la règle ufw, en remplaçant votre adresse IP là où elle est mise en évidence :

Cela garantira que seul votre serveur peut se connecter à l'instance PostgreSQL. Bien que cela autorise le trafic à travers le pare-feu, vous devez également modifier les fichiers de configuration de PostgreSQL pour permettre la connexion depuis l'adresse IP distante. Par défaut, la configuration n'autorise que la connexion depuis localhost. Les fichiers de configuration de PostgreSQL se trouvent dans le répertoire /etc/postgresql/12/main. 12, dans ce cas, est la version de PostgreSQL que nous avons installée pour ce tutoriel. Vous avez peut-être installé une version différente. Ainsi, vous pouvez vous déplacer dans le répertoire /etc/postgresql/ et lister le contenu pour trouver le numéro de version du PostgreSQL que vous avez installé.

Utilisez nano pour modifier le fichier de configuration :

Trouvez cette ligne ci-dessous, décommentez-la et configurez-la pour autoriser les connexions depuis toutes les adresses IP :

Enregistrez et fermez le fichier. Ensuite, vous devez également modifier le fichier pg_hba.conf aussi, il se trouve dans le même répertoire que le postgresql.conf. Le pg_hba.conf vous permet de définir depuis quels ordinateurs vous pouvez vous connecter à l'instance PostgreSQL ainsi que la méthode d'authentification. Ouvrez le fichier avec nano :

Veuillez lire les commentaires dans ce fichier pour comprendre les mots-clés. La section que nous recherchons est celle-ci :

Nous nous concentrerons sur la deuxième ligne, vous voulez qu'elle ressemble à la ligne ci-dessous après l'avoir décommentée :

Veuillez remplacer la partie en surbrillance par l'adresse IP de votre serveur Ubuntu pour lui permettre de se connecter à l'instance PostgreSQL. Enregistrez le fichier une fois que vous êtes prêt. Redémarrez la base de données PostgreSQL pour que les modifications prennent effet :

Notre autre serveur Ubuntu avec l'adresse IP spécifiée devrait pouvoir se connecter à l'instance Postgres.

Étape 2 : Connexion à l'instance du serveur PostgreSQL et création d'une base de données et d'un utilisateur

Dans cette étape, nous allons essayer de nous assurer que l' instance Ubuntu hébergeant notre conteneur Docker peut se connecter à l'autre serveur exécutant l' instance PostgreSQL. Connectez-vous à l'instance Ubuntu qui contient Docker et installez le paquet postgresql-client dans la machine hôte Ubuntu (pas encore dans le conteneur).

En règle générale, mettez d'abord à jour le paquet apt, puis installez le paquet avec les commandes suivantes :

Le paquet installé ci-dessus vous aidera à créer une base de données et un utilisateur pour votre application. Ensuite, nous devons nous connecter à l'instance PostgreSQL en transmettant les paramètres de connexion au client PostgreSQL.

Les paramètres de connexion suivent cette syntaxe :

Dans cette commande, le username est l'utilisateur/rôle que vous avez ajouté à votre base de données PostgreSQL. host est l'adresse IP de l'instance Ubuntu exécutant votre base de données PostgreSQL. port est le port par défaut sur lequel Postgres écoute les connexions entrantes, c'est-à-dire 5432. À la place de la database, nous utiliserons la base de données par défaut appelée postgres fournie avec l'installation de PostgreSQL. Remplacez vos valeurs dans les parties surlignées de manière appropriée et appuyez sur Entrée. Lorsque vous y êtes invité, saisissez le mot de passe que vous aviez défini. Cela vous connecte à l'invite Postgres où vous pouvez gérer la base de données.

Vous vous êtes connecté avec succès à l'instance PostgreSQL. Vous pouvez maintenant créer une base de données pour l'application de sondages Django. Appelons-la django_polls:

Assurez-vous que votre instruction se termine par un point-virgule pour éviter les erreurs. Ensuite, basculez vers la base de données django_polls avec la commande :

Ensuite, créez un utilisateur de base de données spécifique à ce projet. Nommons l'utilisateur django_user:

Choisissez un mot de passe sécurisé pour votre utilisateur. Une fois cela fait, nous devons modifier les paramètres de connexion pour l'utilisateur que nous venons de créer. Cela permet d'accélérer les opérations de base de données en garantissant que les valeurs correctes ne sont pas interrogées et définies à chaque fois qu'une connexion est établie.

Définissez l'encodage par défaut attendu par Django sur UTF-8 :

Ensuite, définissez le schéma d'isolation des transactions par défaut sur « read committed », ce qui bloque les lectures des transactions non validées :

Définissez votre fuseau horaire. Pour que le tutoriel reste universel, nous utiliserons le UTC:

Enfin, accordez les privilèges d'administration de la base de données au nouvel utilisateur :

Quittez l'invite PostgreSQL lorsque vous êtes prêt :

C'est tout pour cette étape. Une fois que vous aurez correctement configuré votre application Django, elle devrait être capable de gérer votre base de données.

Étape 3 : Récupération de l'application depuis un dépôt Git et définition des dépendances

Dans cette étape, nous allons cloner le dépôt de l'application Django-polls. Ce dépôt contient le code pour Django le tutoriel d'écriture de votre première application Django.

Connectez-vous au serveur Ubuntu exécutant Docker, créez un répertoire appelé django_project et accédez-y :

Ensuite, clonez le dépôt dans le répertoire avec la commande suivante :

Accédez au répertoire et listez le contenu :

Listez le contenu du répertoire :

Notez les éléments suivants :

• manage.py : ce fichier est l'entrée de l'utilitaire en ligne de commande fourni par Django pour gérer votre application.

• mysite : un répertoire contenant la portée du projet Django et les paramètres du code.

• polls : un répertoire contenant le code de l'application polls .

• templates : contient des fichiers de modèles personnalisés pour les pages d'administration.

Pour en savoir plus sur la façon dont nous avons réellement créé le projet, veuillez consulter le tutoriel Écrire votre première application Django de la documentation officielle. À l'intérieur de django-polls répertoire, nous voulons que nos dépendances Python soient définies dans un fichier texte. Nous l'appellerons requirements.txt. Ouvrez le fichier avec votre éditeur préféré :

Collez les lignes suivantes à l'intérieur du fichier pour déclarer les dépendances :

Dans ce fichier, nous avons défini les dépendances Python avec leurs versions exactes qui doivent être installées lors de la construction de l'application. Certaines d'entre elles incluent Django, django-storages pour interagir avec les compartiments de stockage d'objets, l'adaptateur psycopg2 pour PostgreSQL, le serveur WSGI gunicorn, et d'autres dépendances supplémentaires. Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 4 : Configuration des variables d'environnement pour une application Django

La méthodologie twelve-factor app recommande d'extraire les configurations codées en dur de la base de code de votre application. Ce faisant, vous obtenez la liberté de modifier le comportement de l'application au moment de l'exécution en modifiant les variables d'environnement sans toucher à la base de code. Docker fonctionne avec cette configuration, nous allons donc modifier le fichier de paramètres pour qu'il fonctionne avec des variables d'environnement. Kubernetes fonctionne également avec cette configuration. Nous partagerons un autre tutoriel sur le déploiement avec Kubernetes sur le blog de CloudSigma.

Le fichier settings.py est le fichier de paramètres principal pour un projet Django. Il s'agit d'un module Python qui utilise des structures de données natives pour configurer l'application. Pour notre application, le fichier se trouve à l'emplacement django-polls/mysite/settings.py. La plupart de ses valeurs sont codées en dur. Cela vous obligera à modifier le fichier de configuration dans la base de code si vous changez le comportement de l'application. Nous voulons changer cela. Heureusement, Python propose la fonction getenv fonction dans le module os . Nous pouvons l'utiliser pour configurer Django afin qu'il lise les paramètres de configuration à partir des variables d'environnement locales à la place.

Continuons en modifiant le fichier django-polls/mysite/settings.py pour remplacer les valeurs codées en dur des variables que nous pourrions vouloir mettre à jour au moment de l'exécution par un appel à os.getenv. Cette fonction lit la valeur définie dans le nom de la variable d'environnement fourni. En option, vous pouvez fournir un deuxième paramètre qui est une valeur par défaut qui sera utilisée si la variable d'environnement n'est pas définie.

Voici un exemple :

Dans la ligne ci-dessus, nous demandons à Django de récupérer la clé secrète à partir de la variable d'environnement. Nous ne fournissons pas de valeur de secours car nous fournirons la clé en externe. Si elle n'existe pas, l'application ne devrait pas démarrer. Tout en fournissant la clé secrète en externe, nous voulons également nous assurer que toutes nos copies conteneurisées de l'application utilisent la même clé sur les différents serveurs. Cela évite les problèmes potentiels qui surviennent lorsque les différentes copies de l'application utilisent des clés différentes.

Voici un autre exemple avec une option par défaut :

Dans cette ligne, nous définissons une variable d'environnement DEBUG qui doit être lue. Cependant, si elle n'est pas définie, nous avons fourni un deuxième paramètre qui sera transmis à la variable de configuration DEBUG. DEBUG est définie sur False pour s'assurer que des informations sensibles ne soient pas transmises au frontend en cas de problème avec l'application. Cependant, si nous sommes en mode développement, nous voulons qu'elle soit définie sur True pour nous permettre de voir les informations d'erreur afin de nous faciliter la correction des erreurs.

Maintenant que vous connaissez l'importance des variables d'environnement, ouvrez le fichier django_project/django-polls/settings.py dans votre éditeur. Tout d'abord, importez le module os en ajoutant cette ligne en haut du fichier settings.py :

Ensuite, trouvez ces variables et mettez-les à jour comme suit :

Dans le ALLOWED_HOSTS paramètre, nous spécifions qu'il doit obtenir la valeur à partir de la variable d'environnement DJANGO_ALLOWED_HOSTS, et la diviser en une liste Python en utilisant la virgule ( ,) comme séparateur. Si la variable est manquante, ALLOWED_HOSTS est défini sur 127.0.0.1.

Ensuite, faites défiler le fichier et trouvez la section DATABASES, configurez-la pour qu'elle lise également à partir des variables d'environnement :

Notez que nous avons ajouté le module json.loads. Vous devez également ajouter un import de ce module en haut du fichier settings.py :

La fonction json.loads désérialise un objet JSON transmis dans DATABASES['default']['OPTIONS'] à partir de la variable d'environnement DB_OPTIONS. Spécifier cette option nous permet de passer une structure de données arbitraire pour définir la configuration de la base de données. Un moteur de base de données comprend un ensemble d'options valides qui lui sont applicables. L'option JSON nous donne la flexibilité d'encoder un objet JSON avec les paramètres appropriés pour le moteur de base de données que nous utilisons à ce moment-là.

Le paramètre DATABASES['default']['NAME'] spécifie le nom de la base de données dans le système de gestion de base de données relationnelle que nous avons configuré. Dans le cas de l'utilisation d'une base de données SQLite, vous devez spécifier le chemin d'accès au fichier de base de données.

Notez que Python propose plusieurs méthodes pour lire les variables d'environnement externes. Nous n'en avons utilisé qu'une seule. Vous êtes libre de faire des recherches et d'utiliser d'autres méthodes. Dans cette étape, vous avez appris à travailler avec des variables d'environnement externes. Cela vous donne la flexibilité de modifier les variables et d'altérer le comportement de l'application s'exécutant dans des conteneurs. Dans l'étape suivante, vous apprendrez à travailler avec des services de stockage d'objets.

Étape 5 : Travailler avec des services de stockage d'objets externes

Un avantage majeur de la conteneurisation de votre application est de la rendre portable pour un déploiement facile de plusieurs copies de l'application lorsque le trafic augmente. Cela permet ainsi une mise à l'échelle. Cependant, cela pose le problème du maintien des versions des fichiers statiques et des ressources à travers les différents conteneurs. Grâce aux améliorations de la technologie cloud, vous pouvez décharger ces éléments statiques partagés vers un stockage externe. Ensuite, vous pouvez rendre les fichiers accessibles via un réseau à tous vos conteneurs en cours d'exécution. Au lieu d'essayer de synchroniser les fichiers entre les différents conteneurs en cours d'exécution, vous disposez d'un emplacement centralisé pour les gérer.

Le concept que nous essayons d'expliquer ci-dessus est l'utilisation de services de stockage d'objets cloud, ou Simple Storage Services (S3). Django dispose d'un package appelé django-storages qui vous permet de travailler avec des backends de stockage distants. Django-storages fonctionne avec la plupart des services de stockage d'objets compatibles S3 tels que FTP, SFTP, AWS S3 d'Amazon, Google Cloud Storage, Dropbox et Azure Storage, entre autres. Dans ce tutoriel, nous utiliserons MinIO. N'hésitez pas à utiliser n'importe quel autre service de stockage d'objets compatible S3. MinIO offre un stockage d'objets haute performance et compatible S3. Avec MinIO, vous pouvez créer une infrastructure de données compatible S3 sur n'importe quel cloud.

Nous allons vous montrer comment configurer un service de stockage MinIO sur la plateforme CloudSigma. Veuillez suivre ces étapes :

• Commencez par créer un compte sur CloudSigma. Si vous rencontrez des problèmes lors de la création du stockage MinIO, veuillez contacter le support par chat en direct gratuit 24h/24 et 7j/7 de CloudSigma, et ils vous aideront.

• Ajoutez vos informations de facturation.

• Ensuite, demandez votre bucket accessible publiquement d'ici : https://blog.cloudsigma.com/xxxx. Vous devrez contacter le support par chat en direct pour obtenir vos identifiants d'accès au compte.

• Une fois votre environnement de stockage d'objets MinIO créé, vous recevrez des identifiants d'accès et d'autres instructions pour y accéder. Les identifiants doivent inclure votre MINI_ACCESS_KEY, MINIO_SECRET_KEY, et MINIO_URL. Vous utiliserez ces clés dans les instructions ci-dessous.

Apportons quelques modifications supplémentaires au fichier mysite/settings.py que nous avons modifié à l'étape précédente. Dans le fichier, ajoutez l'application storages à la liste INSTALLED_APPS:

L'application storages est installée via django-storages comme défini dans le fichier requirements.txt. Faites défiler vers le bas du fichier et remplacez la variable STATIC_URL par le fragment de code suivant :

Notez que certaines variables de configuration sont codées en dur :

• STATICFILES_STORAGE : définit le backend de stockage que Django utilisera pour gérer les fichiers statiques. Dans notre guide, nous utilisons le stockage MinIO, mais vous pouvez utiliser n'importe quel backend compatible S3 comme expliqué dans la documentation de Django Storages.

• AWS_S3_OBJECT_PARAMETERS : définit les en-têtes de contrôle de cache.

• AWS_LOCATION : nous l'utilisons pour définir un répertoire dans le bucket de stockage où tous les fichiers statiques seront stockés. Vous êtes libre de choisir un nom différent.

• AWS_DEFAULT_ACL : définit la liste de contrôle d'accès (ACL) pour les fichiers statiques. Définir la valeur sur ‘ public-Read’ rendra les fichiers accessibles à tous les utilisateurs publics.

• STATIC_URL : Django utilise l'URL de base définie dans cette variable pour générer les URL des fichiers statiques. L'URL de base dans ce cas est obtenue en combinant l'URL du point de terminaison et le sous-répertoire des fichiers statiques.

• STATIC_ROOT : définit l'emplacement où collecter localement les fichiers statiques avant de les copier vers le stockage d'objets distant.

Nous avons également des variables d'environnement définies en externe pour maintenir la flexibilité et la portabilité :

• AWS_STORAGE_BUCKET_NAME : définit le nom du compartiment de stockage (bucket) vers lequel Django téléchargera les ressources.

• AWS_S3_ENDPOINT_URL : définit l'URL du point de terminaison (endpoint) utilisée pour accéder au service de stockage d'objets. Ce sera l'URL mappée sur le serveur hébergeant votre service MinIO.

Enregistrez et fermez le fichier lorsque vous avez terminé l'édition.

Une fois que vous avez mis en place ces paramètres et installé les dépendances Python déclarées, vous pouvez exécuter la commande Django manage.py collectstatic à tout moment pour rassembler les fichiers statiques de votre projet et les charger sur le backend de stockage d'objets distant :

Cependant, nous n'avons pas encore configuré le fichier env avec les configurations, donc cela va probablement échouer.

Lorsque vous exécutez la commande, la copie de vos ressources vers le stockage cloud MinIO prend un certain temps en fonction de leur taille et de votre vitesse de connexion Internet.

C'est tout pour cette étape. Voyons comment nous pouvons gérer l'envoi des journaux Django vers le moteur Docker afin que vous puissiez les visualiser à l'aide de la commande docker logs à l'étape suivante.

Étape 6 : Configuration de la journalisation dans une application Django

En mode Debug, lorsque l'option DEBUG est définie sur True, Django enregistre les informations sur la sortie standard et l'erreur standard. Les informations de journalisation s'affichent généralement sur le terminal à partir duquel vous avez lancé le serveur HTTP de développement.

En production, vous utilisez probablement un serveur HTTP différent, et l'option DEBUG est définie sur False. Django utilisera une méthode de journalisation différente dans ce cas. Django envoie les journaux de priorité ERROR ou CRITICAL à un compte de messagerie d'administration que vous définissez. Cela fonctionne très bien dans de nombreuses situations.

Dans les configurations conteneurisées et Kubernetes, la journalisation sur la sortie standard et l'erreur standard est fortement recommandée. Les messages de journal sont collectés dans un seul répertoire sur le système de fichiers du nœud et sont facilement accessibles à l'aide des commandes kubectl et docker . Avec un point de journalisation centralisé sur le système de fichiers du nœud, l'équipe des opérations peut facilement exécuter des processus sur chaque nœud pour surveiller et transférer les journaux. Par conséquent, nous devons configurer notre application pour écrire les journaux dans cette configuration standard.

Vous serez heureux d'apprendre que Django s'appuie sur le module logging hautement personnalisable de la bibliothèque standard de Python. Cela vous permet de définir un dictionnaire qui passe par logging.config.dictConfig pour définir les sorties et le formatage souhaités. Voici un excellent article sur Django Logging, The Right Way qui peut vous aider à maîtriser les techniques de journalisation de Django.

Ouvrez le fichier django-polls/mysite/settings.py  dans votre éditeur. Ajoutez un import pour la bibliothèque Python logging.config en haut du fichier :

Jusqu'à présent, avec tous les imports que nous avons ajoutés, votre section d'importations dans settings.py devrait ressembler à ceci :

La bibliothèque logging.config accepte un dictionnaire de nouvelle configuration de journalisation via la fonction dictConfig pour remplacer le comportement de journalisation par défaut de Django.

Faites défiler vers le bas du fichier et ajoutez l'extrait de code de configuration de journalisation suivant :

LOGGING_CONFIG est défini sur None pour désactiver/effacer les configurations de journalisation par défaut définies par Django. LOGLEVEL est défini par la DJANGO_LOGLEVEL variable d'environnement. Cependant, si elle n'existe pas, nous voulons qu'elle soit définie sur ‘ info’.

Le logging.config module que nous avons importé en haut fournit une fonction dictConfig qui est utilisée pour définir un nouveau dictionnaire de configuration. Le dictionnaire définit le formatage du texte à l'aide de la clé formatters key. La sortie est définie avec la clé handlers key, et enfin, la clé loggers définit quel message doit être envoyé à quel gestionnaire.

Une fois ces paramètres définis, Docker exposera les journaux via la commande docker logs . De même, dans un autre tutoriel que nous ferons pour Kubernetes, vous pourrez afficher les journaux avec la commande kubectl logs . Commençons maintenant le processus de conteneurisation à l'étape suivante.

Étape 7 : Définir le Dockerfile de l'application

Dans cette étape, nous définissons la configuration pour démarrer l'image de conteneur qui exécutera l'application Django servie par le serveur WSGI Guincorn. Nous définirons l'environnement d'exécution pour construire une image de conteneur, installerons l'application et ses dépendances, et effectuerons quelques configurations finales.

• L'image parente pour une application Django

Décider de l'image de base sur laquelle baser votre conteneur est la toute première décision que vous prendrez lors du déploiement de conteneurs. Bien sûr, vous avez la possibilité de construire vos images de conteneur à partir de SCRATCH, c'est-à-dire un système de fichiers vide, ou de les baser sur une image de conteneur existante. Comme nous ne voulons pas réinventer la roue, nous allons construire notre image à partir d'une image de base. Il existe de nombreuses images de conteneurs open-source disponibles sur le dépôt d'images de conteneurs officiel de Docker. À moins que vous ne construisiez votre image à partir de zéro, il est fortement recommandé d'utiliser une image du hub officiel de Docker. En effet, Docker vérifie que les images respectent les meilleures pratiques et garantit la mise en place de mises à jour régulières et de correctifs de sécurité.

Comme Django est un framework Python, nous allons tirer parti d'une image avec un environnement Python standard qui contient déjà les outils et les bibliothèques dont nous avons besoin. Depuis la page officielle des images Python sur le Docker Hub, vous pouvez trouver une image basée sur Python pour différentes versions de Python.

À travers nos différents tutoriels basés sur Docker, vous remarquerez que nous utilisons des images basées sur Alpine Linux. Alpine Linux offre un environnement de système d'exploitation robuste mais léger pour exécuter des applications conteneurisées. Bien que son système de fichiers soit de petite taille, il est extensible et est livré avec un système complet de gestion de paquets offrant la possibilité d'ajouter des fonctionnalités.

Lors du choix d'une image de base sur le Docker Hub, vous remarquerez peut-être que plusieurs tags sont disponibles pour chaque image. Pour ce qui est de Python, nous avons 3-alpine, qui pointe vers la dernière version de l'image Python 3 de la dernière version d'Alpine. Cela signifie que si votre projet fonctionne avec une version d'image plus ancienne, il risque de ne plus fonctionner lorsque les responsables de l'image Docker feront une mise à jour. Pour éviter de tels scénarios à l'avenir, il est toujours recommandé de choisir les tags les plus spécifiques pour l'image que vous souhaitez utiliser.

Dans ce tutoriel, nous utiliserons l'image 3.8.12-alpine3.15 comme image de base pour notre application Django. Ce tag spécifique sera spécifié dans le Dockerfile en utilisant l'instruction FROM. Le Dockerfile se trouvera dans le répertoire principal du projet : django_project.

Commencez par sortir du répertoire Django-polls pour revenir dans le répertoire django_project :

Une fois dans le répertoire, utilisez votre éditeur préféré pour ouvrir un fichier nommé Dockerfile :

Ensuite, collez la ligne suivante pour définir la base de votre image :

Le mot-clé FROM  définit le point de départ d'une image Docker personnalisée. Cela étant défini, nous pouvons continuer à ajouter des instructions pour configurer les applications. Ces instructions installeront les dépendances nécessaires, copieront les fichiers de l'application et configureront l'environnement d'exécution.

Ajoutez l'extrait de code suivant à l'intérieur du Dockerfile :

Dans cet extrait de code, nous demandons à Docker de copier le fichier requirements.txt  vers /app/requirements.txt pour s'assurer que les dépendances de l'application sont disponibles sur le système de fichiers de l'image. Les exigences incluent tous les packages Python requis pour exécuter l'application. Les dépendances sont copiées en premier afin que Docker puisse mettre en cache la couche d'image. C'est parce que Docker met en cache chaque étape du Dockerfile. La première construction de l'image est généralement plus longue. Docker téléchargera les dépendances, puis les mettra en cache. Si le fichier requirements.txt ne change pas, Docker construira à partir du cache, rendant ainsi les constructions ultérieures plus rapides.

L'étape suivante contient l'instruction RUN qui exécute une liste de commandes Linux, enchaînées avec l'opérateur Linux &&. Les commandes effectuent les actions suivantes :

• Utiliser l'outil de gestion de paquets apk d'Alpine pour installer les fichiers de développement PostgreSQL et les dépendances de construction de base.

• Créer un environnement virtuel Python.

• Installer les dépendances Python telles que définies dans le fichier requirements.txt en utilisant pip.

• Compiler les packages d'exécution nécessaires en analysant les exigences des packages Python installés.

• Supprimer toutes les dépendances de construction qui ne sont plus nécessaires.

La raison pour laquelle les commandes sont enchaînées dans l'étape RUN est de réduire les couches d'image. Docker crée une nouvelle couche d'image au-dessus du système de fichiers existant chaque fois qu'il rencontre ADD, COPY, ou RUN instruction dans le Dockerfile. Compresser les commandes lorsque cela est possible minimisera le nombre de couches d'image créées.

Les éléments ajoutés aux couches d'image ne peuvent pas être supprimés dans une couche ultérieure. Vous devez déclarer des instructions pour supprimer les éléments indésirables avant de passer à l'instruction suivante. Cela est nécessaire pour réduire la taille de l'image. Vous devriez remarquer que nous avons ajouté la commande apk del à la fin de la commande RUN . Cela a été fait pour supprimer les dépendances de build après les avoir utilisées pour compiler les packages de l'application.

Ensuite, nous avons une autre instruction ADD que nous utilisons pour copier le code de l'application dans le répertoire /app . Ensuite, nous utiliserons l'instruction WORKDIR pour définir le répertoire de travail de l'image sur le répertoire /app , qui contient maintenant le code de l'application.

Ensuite, nous avons les instructions ENV que nous utilisons pour définir deux variables d'environnement que l'image rendra disponibles pour les conteneurs en cours d'exécution. Tout d'abord, nous définissons la variable VIRTUAL_ENV sur /env. Deuxièmement, nous définissons la variable PATH pour inclure le répertoire /env/bin . Dans ces deux lignes, nous sourçons le script /env/bin/activate , ce qui est la façon dont nous activons un environnement virtuel dans un environnement Linux. Vous pouvez en savoir plus sur l'utilisation des environnements virtuels en Python sur d'autres systèmes d'exploitation. La dernière instruction est la commande EXPOSE qui définit le port 8000 sur lequel le conteneur écoutera lors de l'exécution.

À ce stade, votre Dockerfile est presque complet, à l'exception de la commande par défaut qui s'exécutera au démarrage des conteneurs. Définissons-la dans la section suivante.

• Comprendre la commande par défaut de l'image Docker

Lors du démarrage d'un conteneur Docker, vous pouvez fournir une commande à exécuter. Cependant, si vous ne fournissez pas de commande, la commande par défaut de l'image Docker déterminera ce qui se passera au démarrage du conteneur. Nous utilisons les instructions ENTRYPOINT ou CMD individuellement ou ensemble pour définir une commande par défaut dans le Dockerfile.

Si vous choisissez de définir à la fois ENTRYPOINT et CMD, dans l'instruction ENTRYPOINT, vous définissez l'exécutable qui sera exécuté par le conteneur. Dans l'instruction CMD, définissez la liste d'arguments par défaut pour la commande exécutable. Vous pouvez remplacer la liste d'arguments par défaut en ajoutant des arguments alternatifs sur la ligne de commande lors du lancement du conteneur au format :

Ce format empêche les développeurs de remplacer facilement la commande ENTRYPOINT. La commande ENTRYPOINT est définie pour appeler un script qui configurera l'environnement et effectuera différentes actions en fonction de la liste d'arguments fournie.

Vous pouvez utiliser l'instruction ENTRYPOINT seule pour configurer l'exécutable du conteneur. Cependant, ce format ne permet pas de définir une liste d'arguments par défaut. Vous pouvez fournir des arguments lorsque vous exécutez le conteneur avec la commande docker run .

Si vous choisissez d'utiliser uniquement CMD , Docker l'interprète comme la commande et la liste d'arguments par défaut, que vous pouvez remplacer lors de l'exécution. Vous trouverez plus d'informations sur la documentation de référence officielle du Dockerfile.

Voyons comment nous pouvons appliquer les informations que vous avez apprises sur les commandes par défaut à notre exemple de conteneur. Nous voulons servir l'application par défaut en utilisant le serveur gunicorn . Bien que la liste d'arguments passée au serveur gunicorn ne doive pas nécessairement être configurable lors de l'exécution, nous voulons la flexibilité d'exécuter d'autres commandes à des fins telles que le débogage ou la gestion des configurations (initialisation de la base de données, collecte des fichiers statiques, etc.). Comme vous pouvez le voir, il est dans notre intérêt d'utiliser CMD pour définir une commande par défaut qui nous permettra de la remplacer chaque fois que nécessaire.

Voici quelques syntaxes que vous pouvez utiliser pour définir la commande CMD :

• CMD ["command", "argument 1", "argument 2", . . . ,"argument n"] : Le format exec (format recommandé) prend une commande et une liste d'arguments. Il exécute la commande directement sans traitement par le shell.
• CMD command "argument 1" "argument 2" . . . "argument n": Le format shell définit une commande et une liste d'arguments. Il transmet la liste des commandes au shell pour traitement. Vous pouvez trouver cela utile si vous souhaitez substituer des variables d'environnement dans une commande, cependant, ce n'est pas entièrement prévisible.
• CMD ["argument 1", "argument 2", . . . ,"argument n"]: Le format de liste d'arguments, il définit uniquement la liste d'arguments par défaut et est utilisé conjointement avec une ENTRYPOINT instruction.

Nous utiliserons le format exec pour définir notre instruction finale dans le Dockerfile. Ajoutez la ligne suivante à la fin de votre Dockerfile:

Vous pouvez maintenant enregistrer et fermer le Dockerfile.

Lorsque vous lancez des conteneurs à l'aide de cette image, ils exécuteront gunicorn lié au port localhost 8000 avec 3 workers, et appelleront la fonction application dans le fichier wsgi.py situé dans le répertoire mysite . Vous pouvez choisir de fournir une commande différente pour remplacer la commande par défaut lors de l'exécution et exécuter un processus différent au lieu de gunicorn. Vous souhaiterez peut-être en savoir plus sur les workers Gunicorn.

Votre Dockerfile est maintenant prêt et vous pouvez utiliser docker build pour créer l'image de l'application. Vous pouvez utiliser docker run pour lancer le conteneur sur votre machine de développement locale.

• Construction de l'image Docker

La commande docker build recherchera par défaut un Dockerfile dans le répertoire actuel pour trouver ses instructions de construction. Elle envoie également le « contexte » de construction au démon Docker. Un contexte de construction est un ensemble de fichiers qui doivent être disponibles pendant le processus de construction. Par défaut, le répertoire actuel dans lequel vous exécutez la commande docker build est défini comme contexte de construction.

Tout en étant dans le même répertoire qui contient votre Dockerfile, exécutez la commande docker build. Fournissez une image et un tag avec le drapeau -t, et définissez le répertoire actuel comme contexte de construction en utilisant le point ( .) à la fin de la commande :

Dans cette commande, nous avons nommé l'image django-polls et le tag v1. Notez le point à la fin de la commande, nous l'utilisons pour désigner le répertoire actuel comme contexte de construction.

Lorsque le docker build est terminé, vous devriez voir une sortie similaire à la suivante :

Votre image Docker est maintenant prête. Si nous n'avions pas déporté certaines configurations dans des variables d'environnement externes, vous pourriez facilement exécuter votre conteneur avec la commande docker run. Cependant, comme nous n'avons pas configuré les variables d'environnement externes que nous avons définies dans le fichier settings.py, l'exécution échouera. Finalisons cela à l'étape suivante.

Étape 8 : Configuration de l'environnement d'exécution et test de l'application

Nous approchons de la fin de ce tutoriel. Dans cette étape, nous allons configurer les variables d'environnement dans le fichier env . Avec les variables du fichier env en place, nous pouvons créer le schéma de base de données, générer et téléverser les fichiers statiques vers le service de stockage d'objets externe, et enfin tester l'application.

Docker propose plusieurs méthodes que vous pouvez utiliser pour fournir des variables d'environnement au conteneur. Dans notre cas, nous voulons fournir une liste de variables d'environnement via un fichier. Par conséquent, nous utiliserons la méthode --env-file.

À l'aide de votre éditeur préféré, créez un fichier nommé env dans le répertoire django_project :

Collez la liste de variables suivante :

Les variables de la liste sont celles que vous avez définies dans les étapes précédentes :

• DJANGO_SECRET_KEY: Générez une valeur unique et imprévisible comme expliqué dans la documentation de Django. Vous pouvez utiliser cette commande pour générer une chaîne aléatoire et l'affecter à la variable :

• DEBUG: Nous avons défini cette valeur sur True, mais pour un déploiement en production, n'oubliez pas de la définir sur False en la laissant vide.

• DJANGO_LOGLEVEL: nous avons défini cela sur info, n'hésitez pas à l'ajuster au niveau souhaité.

• DJANGO_ALLOWED_HOSTS: définissez cette valeur sur l'adresse IP du serveur Ubuntu exécutant vos conteneurs Docker. Facultativement, définissez-la sur *, un caractère générique correspondant à tous les hôtes si vous êtes en mode développement.

• DB_DATABASE: si vous avez utilisé un nom de base de données différent, définissez-le ici de manière appropriée.

• DB_USERNAME: définissez cette valeur sur le nom d'utilisateur que vous avez choisi pour votre base de données.

• DB_PASSWORD: définissez cette valeur sur le mot de passe que vous avez choisi pour votre base de données.

• DB_HOST: définissez cette valeur sur l'hôte exécutant votre instance de base de données tel que vous l'avez configuré à l'Étape un.

• DB_PORT: définissez cette valeur sur le port de votre base de données.

• STATIC_MINIO_BUCKET_NAME: définissez cette valeur sur le nom du bucket que vous avez créé dans votre compte de stockage cloud MinIO.

Enregistrez et fermez le fichier lorsque vous avez terminé l'édition.

Les configurations d'environnement sont maintenant prêtes. Nous devons exécuter le conteneur en passant des arguments pour remplacer la commande CMD par défaut et créer le schéma de base de données à l'aide des commandes manage.py makemigrations et manage.py migrate.

Voici la commande :

Dans cette commande, nous exécutons l'image de conteneur django-polls:v1, en utilisant le drapeau –env-file pour transmettre le fichier de variables d'environnement. Nous remplaçons également la commande CMD par défaut par sh -c "python manage.py makemigrations && python manage.py migrate" Lorsque cette commande est exécutée pour démarrer le conteneur, elle crée le schéma de base de données tel que défini dans le code de l'application.

Si l'opération réussit, vous devriez voir une sortie similaire à celle ci-dessous :

La sortie indique que le schéma de base de données a été créé avec succès.

L'étape suivante consiste à créer un utilisateur administrateur pour l'application Django. Nous allons démarrer le conteneur et lancer un shell interactif à l'intérieur avec la commande suivante :

La commande démarre le conteneur avec une invite de shell que vous pouvez utiliser pour interagir avec le shell Python. Créons un utilisateur :

Suivez les invites pour fournir un nom d'utilisateur, une adresse e-mail, un mot de passe, retapez le mot de passe et appuyez sur Entrée pour créer l'utilisateur. Quittez le shell et arrêtez le conteneur en appuyant sur CTRL+D.

Ensuite, nous devons exécuter à nouveau le conteneur, en remplaçant la commande par défaut par la commande Django collectstatic pour générer les fichiers statiques de l'application et les télécharger sur votre service de stockage cloud MinIO :

Une fois l'opération terminée, vous devriez voir une sortie similaire à celle ci-dessous, indiquant que votre conteneur s'est connecté avec succès au service de stockage MinIO et a téléchargé les fichiers statiques :

Notre bucket de stockage ressemble maintenant à ceci, avec les répertoires créés par Django :

Enfin, nous pouvons maintenant exécuter l'application avec la commande :

Voici la sortie :

Lorsque vous exécutez la commande ci-dessus, elle lance la commande CMD par défaut dans votre image et expose le port 8000 comme défini. Maintenant, Ubuntu sur le port 80 est mappé sur le port 8000 du conteneur django-polls:v1.

Nous pouvons maintenant tester l'application dans le navigateur. Accédez à l'adresse IP publique de votre serveur dans le navigateur : http://your_server_public_ip.

Attendez-vous à trouver une erreur 404 Page non trouvée, car conformément au Tutoriel Django, nous n'avons pas défini de route pour le chemin / :

Nous avons la variable DEBUG définie sur True, c'est pourquoi nous voyons cette page d'erreur avec beaucoup d'informations cruciales. Désactivons la variable DEBUG. Tout d'abord, vous devrez arrêter le conteneur en cours d'exécution avec CTRL+C. Ensuite, ouvrez le fichier env :

Ensuite, trouvez la variable DEBUG et désactivez-la, ou laissez-la vide. Nous la laissons vide car la fonction getenv interprète False comme une chaîne de caractères, retournant ainsi vrai :

Enregistrez le fichier et lancez à nouveau le conteneur avec la commande :

Si vous visitez ce http://your_server_public_ip dans votre navigateur, vous devriez voir la page 404 par défaut :

Vous avez vu comment vous pouvez manipuler le comportement d'exécution de votre application Django à l'aide de variables d'environnement, sans modifier le code source.

Naviguez vers http://your_server_public_ip/polls pour voir la page d'accueil des sondages :

Nous n'avons pas de sondages puisque nous venons de déployer l'application.

Naviguez vers l'interface d'administration : http://your_server_public_ip/admin pour afficher la fenêtre d'authentification de l'administrateur :

Fournissez les identifiants que vous aviez définis avec la commande createsuperuser pour vous connecter. Vous devriez maintenant être sur l'interface de la page d'administration :

Notez que tous les fichiers statiques sont servis à partir du service de stockage externe que nous avions configuré. Vous pouvez faire un clic droit dans la fenêtre de votre navigateur et sélectionner Afficher le code source de la page:

Vous pouvez ajouter des questions et des choix et tester les performances globales de l'application :

Retournez à l'index des sondages http://your_server_public_ip/polls et essayez de voter sur la question :

Après avoir testé et confirmé que tout fonctionne comme prévu, vous pouvez arrêter le conteneur.

Conclusion

Vous avez configuré avec succès une application web Django pour qu'elle fonctionne correctement dans un environnement basé sur des conteneurs. Cela a impliqué d'adapter l'application pour qu'elle fonctionne avec des variables d'environnement externes, de configurer l'application pour qu'elle utilise un service de stockage cloud pour les fichiers statiques, et de créer un Dockerfile pour l'image du conteneur. Vous pouvez voir les modifications que nous avons apportées pour dockeriser l'application sur la branche django-polls-docker du dépôt GitHub django-polls.

À partir de là, les possibilités ne sont limitées que par votre imagination. Vous pouvez configurer un proxy inverse Nginx pour s'interposer entre les clients et le serveur Gunicorn. Vous pouvez également ajouter Certbot pour obtenir des certificats TLS afin de sécuriser votre serveur Nginx. Nous vous recommandons d'ajouter un proxy HTTP pour mettre en mémoire tampon les clients lents et protéger votre serveur Gunicorn contre les attaques par déni de service.

Bien que nous ayons défini 3 workers dans la commande de démarrage du Dockerfile, vous pouvez définir le nombre de votre choix en fonction des ressources disponibles sur votre serveur. Vous trouverez plus d'informations sur les documents de conception officiels de Gunicorn. Si vous le souhaitez, vous pouvez pousser l'image Docker que vous avez créée vers Docker Hub et essayer de la déployer sur plusieurs environnements où Docker est installé. Si vous souhaitez en savoir plus, continuez à consulter notre blog de tutoriels car nous ferons un tutoriel de suivi pour sécuriser l'application Django avec Nginx et Let's Encrypt.

Enfin, voici d'autres ressources qui vous aideront à utiliser Docker :

• Comment héberger un dépôt d'images Docker et créer des images Docker avec une instance GitLab auto-gérée sur Ubuntu 20.04
• Travailler avec les volumes de données Docker sur Ubuntu 20.04
• Créer et déployer une application Flask avec Docker sur Ubuntu 20.04
• Comment déployer WordPress avec des conteneurs Docker sur Ubuntu 20.04

Bonne programmation !