Rework deployment
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
3c5055a46e
commit
cf1a7f2c1a
File diff suppressed because it is too large
Load Diff
|
|
@ -1,21 +1,27 @@
|
|||
= Déploiement
|
||||
|
||||
On va déjà parler de déploiement. Le serveur que django met à notre disposition est prévu uniquement pour le développement: inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ...). De même, la base de donnée doit supporter plus qu'un seul utilisateur: SQLite fonctionne très bien dès lors qu'on se limite à un seul utilisateur... Sur une application Web, il est plus que probable que vous rencontriez rapidement des erreurs de base de données verrouillée pour écriture par un autre processus. Il est donc plus que bénéfique de passer sur quelque chose de plus solide. https://docs.djangoproject.com/fr/3.0/howto/deployment/[Déploiement].
|
||||
On va déjà parler de déploiement.
|
||||
Le serveur que django met à notre disposition _via_ la commande `runserver` est prévu uniquement pour le développement: en production, il est inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ...).
|
||||
De même, la base de donnée doit être capable de supporter plusieurs utilisateurs et connexions simultanément: SQLite fonctionne très bien dès lors qu'on se limite à un seul utilisateur... Mais sur une application Web, il est plus que probable que vous rencontriez rapidement des erreurs de verrou parce qu'un autre processus a déjà pris la main pour écrire ses données.
|
||||
Il est donc plus que bénéfique de passer sur quelque chose de plus solide.
|
||||
|
||||
Si vous avez suivi les étapes jusqu'ici, vous devriez à peine disposer d'un espace de travail proprement configuré, d'un modèle relativement basique et d'une configuration avec une base de données simpliste. En bref, vous avez quelque chose qui fonctionne, mais qui ressemble de très loin à ce que vous souhaitez au final.
|
||||
Si vous avez suivi les étapes jusqu'ici, vous devriez disposer d'un espace de travail proprement configuré, d'un modèle relativement basique et d'une configuration avec une base de données type SQLite.
|
||||
En bref, vous avez quelque chose qui fonctionne, mais qui ressemble de très loin à ce dont vous aurez besoin au final.
|
||||
|
||||
Il y a une raison très simple à aborder le déploiement dès maintenant: à trop attendre et à peaufiner son développement en local, on en oublie que sa finalité sera de se retrouver exposé sur un serveur. On risque d'avoir oublié une partie des désidérata, d'avoir zappé une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles fonctionnent sur un environnement en particulier.
|
||||
Il y a une raison très simple à aborder le déploiement dès maintenant: à trop attendre et à peaufiner son développement en local, on en oublie que sa finalité sera de se retrouver exposé sur un serveur.
|
||||
Il est du coup probable d'oublier une partie des désidérata, de zapper une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles fonctionnent sur un environnement en particulier.
|
||||
|
||||
Aborder le déploiement maintenant permet également de rédiger dès le début les procédures d'installation, de mise à jour et de sauvegardes. Déploier une nouvelle version sera aussi simple que de récupérer la dernière archive depuis le dépôt, la placer dans le bon répertoire, appliquer des actions spécifiques (et souvent identiques entre deux versions), puis redémarrer les services adéquats.
|
||||
Aborder le déploiement dès le début permet également de rédiger dès le début les procédures d'installation, de mises à jour et de sauvegardes.
|
||||
Déploier une nouvelle version sera aussi simple que de récupérer la dernière archive depuis le dépôt, la placer dans le bon répertoire, appliquer des actions spécifiques (et souvent identiques entre deux versions), puis redémarrer les services adéquats, et la procédure complète se résumera à quelques lignes d'un script bash.
|
||||
|
||||
Dans cette partie, on abordera les points suivants:
|
||||
Dans cette partie, nous aborderons les points suivants:
|
||||
|
||||
* La définition de l'infrastructure nécessaire à notre application
|
||||
* La configuration de l'hôte, qui hébergera l'application: dans une machine physique, virtuelle ou dans un container. On abordera aussi rapidement les déploiements via Ansible, Chef, Puppet ou Salt.
|
||||
* Les différentes méthodes de supervision de l'application: comment analyser les fichiers de logs et comment intercepter correctement une erreur si elle se présente et comment remonter l'information.
|
||||
* La définition de l'infrastructure nécessaire à notre application,
|
||||
* La configuration de l'hôte, qui hébergera l'application: dans une machine physique, virtuelle ou dans un container. Nous aborderons aussi les déploiements via Ansible et Salt.
|
||||
* Les différentes méthodes de supervision de l'application: comment analyser les fichiers de logs, comment intercepter correctement une erreur si elle se présente et comment remonter l'information.
|
||||
* Une partie sur la sécurité et la sécurisation de l'hôte.
|
||||
|
||||
Si on schématise l'infrastructure et le chemin parcouru par une éventuelle requête, on devrait arriver à quelque chose de synthéthique:
|
||||
Si on schématise l'infrastructure et le chemin parcouru par une éventuelle requête, nous devrions arriver à quelque chose de synthéthique:
|
||||
|
||||
* Au niveau de l'infrastructure,
|
||||
. l'utilisateur fait une requête via son navigateur (Firefox ou Chrome)
|
||||
|
|
@ -35,36 +41,46 @@ image::images/diagrams/architecture.png[]
|
|||
. effectuer le rendu ou la conversion des données,
|
||||
. et renvoyer une réponse à l'utilisateur.
|
||||
|
||||
image::images/diagrams/django-process.png[]
|
||||
Comme nous l'avons vu dans la première partie, Django est un framework complet, intégrant tous les mécanismes nécessaires à la bonne évolution d'une application.
|
||||
Il est possible de démarrer petit, et de suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, d'ajouter un mécanisme de mise en cache, des logiciels de suivi, ...
|
||||
|
||||
== Définition de l'infrastructure
|
||||
|
||||
Comme on l'a vu dans la première partie, Django est un framework complet, intégrant tous les mécanismes nécessaires à la bonne évolution d'une application. On peut ainsi commencer petit, et suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, ajouter un mécanisme de mise en cache, des logiciels de suivi, ...
|
||||
|
||||
Pour une mise ne production, le standard *de facto* est le suivant:
|
||||
Pour une mise ne production, le standard _de facto_ est le suivant:
|
||||
|
||||
* Nginx comme reverse proxy
|
||||
* Gunicorn ou Uvicorn comme serveur d'application
|
||||
* Supervisorctl pour le monitoring
|
||||
* PostgreSQL ou MariaDB comme base de données.
|
||||
* Celery et RabbitMQ pour l'exécution de tâches asynchrones
|
||||
* Redis / Memcache pour la mise à en cache (et pour les sessions ? A vérifier).
|
||||
|
||||
En mode _containers_, on passera plutôt par Docker et Traefik.
|
||||
Nous allons détailler ci-dessous trois méthodes de déploiement:
|
||||
|
||||
C'est celle-ci que nous allons décrire ci-dessous.
|
||||
* Sur une machine hôte, en embarquant tous les composants sur un même serveur. Ce ne sera pas idéal, puisqu'il ne sera pas possible de configurer un _load balancer_, de routeur plusieurs basées de données, mais ce sera le premier cas de figure.
|
||||
* Dans des containers, avec Docker-Compose.
|
||||
* Sur une *Plateforme en tant que Service* (ou plus simplement, *PaaS*), pour faire abstraction de toute la couche de configuration du serveur.
|
||||
|
||||
=== Configuration et sécurisation de la machine hôte
|
||||
== Sur une machine hôte
|
||||
|
||||
Supervisor, nginx, gunicorn, utilisateurs, groupes, ...
|
||||
La première étape pour la configuration de notre hôte consiste à définir les utilisateurs et groupes de droits. Il est faut absolument éviter de faire tourner une application en tant qu'utilisateur *root*, car la moindre faille pourrait avoir des conséquences catastrophiques.
|
||||
|
||||
[plantuml]
|
||||
--
|
||||
entity Nginx
|
||||
entity "Gunicorn (sockets/HTTP)" as gunicorn
|
||||
database PGSQL
|
||||
--
|
||||
Une fois que ces utilisateurs seront configurés, nous pourrons passer à l'étape de configuration, qui consistera à:
|
||||
|
||||
Aussi : Docker, Heroku, Digital Ocean, Scaleway, OVH, Ansible, Puppet, Chef, ... Bref, sur Debian et CentOS pour avoir un panel assez large. On oublie Windows: rien que Gunicorn et Nginx n'y tournent pas.
|
||||
1. Déployer les sources
|
||||
2. Démarrer un serveur implémentant une interface WSGI (**Web Server Gateway Interface**), qui sera chargé de créer autant de [.line-through]#petits lutins# travailleurs que nous le désirerons.
|
||||
3. Démarrer un superviseur, qui se chargera de veiller à la bonne santé de nos petits travailleurs, et en créer de nouveaux s'il le juge nécessaire
|
||||
4. Configurer un proxy inverse, qui s'occupera d'envoyer les requêtes d'un utilisateur externe à la machine hôte vers notre serveur applicatif, qui la communiquera à l'un des travailleurs.
|
||||
|
||||
La machine hôte peut être louée chez Digital Ocean, Scaleway, OVH, Vultr, ... Il existe des dizaines d'hébergements typés VPS (**Virtual Private Server**). A vous de choisir celui qui vous convient footnote:[Personnellement, j'ai un petit faible pour Hetzner Cloud].
|
||||
|
||||
include::centos+debian.adoc[]
|
||||
|
||||
== Via Ansible & Salt
|
||||
|
||||
|
||||
== Sur Heroku
|
||||
|
||||
|
||||
== Docker-Compose
|
||||
|
||||
|
||||
=== Mise à jour
|
||||
|
|
@ -99,8 +115,7 @@ include::infrastructure.adoc[]
|
|||
|
||||
include::database.adoc[]
|
||||
|
||||
include::centos+debian.adoc[]
|
||||
|
||||
== Ressources
|
||||
|
||||
https://zestedesavoir.com/tutoriels/2213/deployer-une-application-django-en-production/
|
||||
* https://zestedesavoir.com/tutoriels/2213/deployer-une-application-django-en-production/
|
||||
* https://docs.djangoproject.com/fr/3.0/howto/deployment/[Déploiement].
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
== Déploiement sur CentOS
|
||||
=== Déploiement sur CentOS
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -16,7 +16,7 @@ chown gwift:webapps /home/gwift <5>
|
|||
<5> On pourrait sans doute fusioner les étapes 3, 4 et 5.
|
||||
|
||||
|
||||
=== Installation des dépendances systèmes
|
||||
==== Installation des dépendances systèmes
|
||||
|
||||
La version 3.6 de Python se trouve dans les dépôts officiels de CentOS.
|
||||
Si vous souhaitez utiliser une version ultérieure, il suffit de l'installer en parallèle de la version officiellement supportée par votre distribution.
|
||||
|
|
@ -47,7 +47,7 @@ sudo make altinstall <1>
|
|||
----
|
||||
<1> *Attention !* Le paramètre `altinstall` est primordial. Sans lui, vous écraserez l'interpréteur initialement supporté par la distribution, et cela pourrait avoir des effets de bord non souhaités.
|
||||
|
||||
=== Préparation de l'environnement utilisateur
|
||||
==== Préparation de l'environnement utilisateur
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -80,7 +80,7 @@ cd webapps/gwift
|
|||
gunicorn config.wsgi:application --bind localhost:3000 --settings=config.settings_production
|
||||
----
|
||||
|
||||
=== Configuration de l'application
|
||||
==== Configuration de l'application
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -92,14 +92,14 @@ DATABASE= <2>
|
|||
<1> La variable `SECRET_KEY` est notamment utilisée pour le chiffrement des sessions.
|
||||
<2> On fait confiance à django_environ pour traduire la chaîne de connexion à la base de données.
|
||||
|
||||
=== Création des répertoires de logs
|
||||
==== Création des répertoires de logs
|
||||
|
||||
[source,text]
|
||||
----
|
||||
mkdir -p /var/www/gwift/static
|
||||
----
|
||||
|
||||
=== Création du répertoire pour le socket
|
||||
==== Création du répertoire pour le socket
|
||||
|
||||
Dans le fichier `/etc/tmpfiles.d/gwift.conf`:
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ Suivi de la création par systemd :
|
|||
systemd-tmpfiles --create
|
||||
----
|
||||
|
||||
=== Gunicorn
|
||||
==== Gunicorn
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -147,7 +147,7 @@ exec gunicorn ${DJANGO_WSGI_MODULE}:application \
|
|||
--log-file=-
|
||||
----
|
||||
|
||||
=== Supervision, keep-alive et autoreload
|
||||
==== Supervision, keep-alive et autoreload
|
||||
|
||||
Pour la supervision, on passe par Supervisor. Il existe d'autres superviseurs,
|
||||
|
||||
|
|
@ -218,7 +218,7 @@ gwift: started
|
|||
----
|
||||
|
||||
|
||||
=== Ouverture des ports
|
||||
==== Ouverture des ports
|
||||
|
||||
et 443 (HTTPS).
|
||||
|
||||
|
|
@ -231,7 +231,7 @@ firewall-cmd --reload
|
|||
<1> On ouvre le port 80, uniquement pour autoriser une connexion HTTP, mais qui sera immédiatement redirigée vers HTTPS
|
||||
<2> Et le port 443 (forcément).
|
||||
|
||||
=== Installation d'Nginx
|
||||
==== Installation d'Nginx
|
||||
|
||||
[source]
|
||||
----
|
||||
|
|
@ -283,7 +283,30 @@ server {
|
|||
<2> Ce répertoire sera complété par la commande `collectstatic` que l'on verra plus tard. L'objectif est que les fichiers ne demandant aucune intelligence soit directement servis par Nginx. Cela évite d'avoir un processus Python (relativement lent) qui doive être instancié pour servir un simple fichier statique.
|
||||
<3> Afin d'éviter que Django ne reçoive uniquement des requêtes provenant de 127.0.0.1
|
||||
|
||||
=== Configuration des sauvegardes
|
||||
|
||||
|
||||
=== Déploiement sur Debian
|
||||
|
||||
==== Installation des dépendances systèmes
|
||||
|
||||
==== Préparation de l'environnement utilisateur
|
||||
|
||||
==== Configuration de l'application
|
||||
|
||||
==== Création des répertoires de logs
|
||||
|
||||
==== Création du répertoire pour le socket
|
||||
|
||||
==== Gunicorn
|
||||
|
||||
==== Supervision, keep-alive et autoreload
|
||||
|
||||
==== Ouverture des ports
|
||||
|
||||
==== Installation d'Nginx
|
||||
|
||||
|
||||
== Configuration des sauvegardes
|
||||
|
||||
Les sauvegardes ont été configurées avec borg: `yum install borgbackup`.
|
||||
|
||||
|
|
@ -303,7 +326,7 @@ Et dans le fichier crontab :
|
|||
----
|
||||
|
||||
|
||||
=== Rotation des jounaux
|
||||
== Rotation des jounaux
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
|
|||
Loading…
Reference in New Issue