8.7 KiB
Déploiement
To be effective, a software system must be deployable. The higher the cost of deployements, the less useful the system is. A goal of a software architecture, then, should be to make a system that can be easily deployed with a single action. Unfortunately, deployment strategy is seldom considered during initial development. This leads to architectures that may be make the system easy to develop, but leave it very difficult to deploy. -- Robert C. Martin, Clean Architecture, Chapitre 15, page 137
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. Un bon déploiement ne doit pas dépendre de dizaines de petits scripts éparpillés sur le disque. L’objectif est qu’il soit rapide et fiable. Ceci peut être atteint au travers d’un partitionnement correct, incluant le fait que le composant principal s’assure que chaque sous-composant est correctement démarré intégré et supervisé.
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.
Le serveur que django met à notre disposition via la commande runserver est extrêmement pratique, mais il est uniquement prévu pour la phase 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, Django propose par défaut une base de données SQLite, qui fonctionne parfaitement dès lors que l’on connait ses limites et que l’on se limite à un utilisateur à la fois. En production, il est légitime que la base de donnée soit capable de supporter plusieurs utilisateurs et connexions simultanément…
En restant avec les paramètres par défaut, 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.
En bref, vous avez quelque chose qui fonctionne, mais qui ressemble de très loin à ce dont vous aurez besoin au final.
Dans cette partie, nous aborderons les points suivants:
-
Définir l’infrastructure nécessaire à notre application et configurer 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.
-
Déployer notre code source
-
Configurer les outils nécessaires à la bonne exécution de ce code et de ses fonctionnalités: 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.
-
Rendre notre application accessible depuis l’extérieur.
Infrastructure & composants
Pour une mise ne production, le standard de facto est le suivant:
-
Nginx comme reverse proxy
-
HAProxy pour la distribution de charge
-
Gunicorn ou Uvicorn comme serveur d’application
-
Supervisor 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).
Si nous schématisons l’infrastructure et le chemin parcouru par une requête, nous pourrions arriver à la synthèse suivante:
-
L’utilisateur fait une requête via son navigateur (Firefox ou Chrome)
-
Le navigateur envoie une requête http, sa version, un verbe (GET, POST, …), un port et éventuellement du contenu
-
Le firewall du serveur (Debian GNU/Linux, CentOS, …) vérifie si la requête peut être prise en compte
-
La requête est transmise à l’application qui écoute sur le port (probablement 80 ou 443; et a priori Nginx)
-
Elle est ensuite transmise par socket et est prise en compte par un des workers (= un processus Python) instancié par Gunicorn. Si l’un de ces travailleurs venait à planter, il serait automatiquement réinstancié par Supervisord.
-
Qui la transmet ensuite à l’un de ses workers (= un processus Python).
-
Après exécution, une réponse est renvoyée à l’utilisateur.
Reverse proxy
Le principe du proxy inverse est de pouvoir rediriger du trafic entrant vers une application hébergée sur le système. Il serait tout à fait possible de rendre notre application directement accessible depuis l’extérieur, mais le proxy a aussi l’intérêt de pouvoir élever la sécurité du serveur (SSL) et décharger le serveur applicatif grâce à un mécanisme de cache ou en compressant certains résultats [1]
Load balancer
Workers
Supervision des processus
Base de données
Tâches asynchrones
Mise en cache
Code source
Au niveau logiciel (la partie mise en subrillance ci-dessus), la requête arrive dans les mains du processus Python, qui doit encore
-
effectuer le routage des données,
-
trouver la bonne fonction à exécuter,
-
récupérer les données depuis la base de données,
-
effectuer le rendu ou la conversion des données,
-
et renvoyer une réponse à l’utilisateur.
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, …
Outils de supervision et de mise à disposition
Méthode de déploiement
Nous allons détailler ci-dessous trois méthodes de déploiement:
-
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.
Sur une machine hôte
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.
Une fois que ces utilisateurs seront configurés, nous pourrons passer à l’étape de configuration, qui consistera à:
-
Déployer les sources
-
Démarrer un serveur implémentant une interface WSGI (Web Server Gateway Interface), qui sera chargé de créer autant de petits lutins travailleurs que nous le désirerons.
-
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
-
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 [2].
Unresolved directive in <stdin> - include::debian.adoc[]
Unresolved directive in <stdin> - include::heroku.adoc[]
Unresolved directive in <stdin> - include::docker.adoc[]
|
Warning
|
le serveur de déploiement ne doit avoir qu’un accès en lecture au dépôt source. |
On peut aussi passer par fabric, ansible, chef ou puppet.
Supervision
Qu’est-ce qu’on fait des logs après ? :-)
-
Sentry via sentry_sdk
-
Nagios
-
LibreNMS
-
Zabbix
Il existe également Munin, Logstash, ElasticSearch et Kibana (ELK-Stack) ou Fluentd.
Autres outils
Voir aussi devpi, circus, uswgi, statsd.