12 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.
Clean Architecture
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é et accessible depuis 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 puissent être mises à disposition sur un environnement en particulier, une fois que leur développement aura été finalisé, testé et validé. 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. A la fin de chaque intervalle de développement, les fonctionnalités auront dû avoir été intégrées, testées, fonctionnelles et un code propre, démontrable dans un environnement similaire à un environnement de production, et créées à partir d’un tronc commun au développement cite:{devops_handbook}.
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.
Because value is created only when our services are running into production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and disruptions such as service outages, service impairments, or security or compliance failures.
Introduction
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és.
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, qui répond à un besoin, mais qui va attirer la grogne de ses utilisateurs pour des problèmes de latences, pour des erreurs de verrou ou simplement parce que le serveur répondra trop lentement.
L’objectif de cette partie est de parcourir les différentes possibilités qui s’offrent à nous en termes de déploiement, tout en faisant en sorte que le code soit le moins couplé possible à sa destination de production. L’objectif est donc de faire en sorte qu’une même application puisse être hébergées par plusieurs hôtes sans avoir à subir de modifications. Nous vous renvoyons vers les 12-facteurs dont nous avons déjà parlé et qui vous énormément nous aider, puisque ce sont des variables d’environnement qui vont réellement piloter le câblage entre l’application, ses composants et son hébergeur.
RedHat proposait récemment un article intitulé *What Is IaaS*, qui présentait les principales différences entre types d’hébergement.
Ainsi, on trouve:
-
Le déploiment on-premises ou on-site
-
Les Infrastructures as a service ou IaaS
-
Les Platforms as a service ou PaaS
-
Les Softwares as a service ou SaaS, ce dernier point nous concernant moins, puisque c’est nous qui développons le logiciel.
Dans cette partie, nous aborderons les points suivants:
-
Définir l’infrastructure et les composants nécessaires à notre application
-
Configurer l’hôte qui hébergera l’application et y déployer notre application: dans une machine physique, virtuelle ou dans un container. Nous aborderons aussi les déploiements via Ansible et Salt. A ce stade, nous aurons déjà une application disponible.
-
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 correctement l’information.
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 MySQL/MariaDB comme bases 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).
-
Sentry, pour le suivi des bugs
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
Logs
Unresolved directive in <stdin> - include::logging.adoc[]
Sentry ! :-D
SENTRY_DSN = env("SENTRY_DSN", default=None)
if SENTRY_DSN is not None:
import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration
sentry_sdk.init(
dsn=SENTRY_DSN,
integrations=[DjangoIntegration()],
# Set traces_sample_rate to 1.0 to capture 100%
# of transactions for performance monitoring.
# We recommend adjusting this value in production.
traces_sample_rate=1.0,
# If you wish to associate users to errors (assuming you are using
# django.contrib.auth) you may enable sending PII data.
send_default_pii=True,
ca_certs=<path_to_pem_file>,
)Logging
-
Sentry via sentry_sdk
-
Nagios
-
LibreNMS
-
Zabbix
Il existe également Munin, Logstash, ElasticSearch et Kibana (ELK-Stack) ou Fluentd.
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.
Autres outils
Voir aussi devpi, circus, uswgi, statsd.