Premiere relecture de déploiment.

source/part-2-deployment/00-main.adoc

@@ -1,16 +1,16 @@
 = 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].
+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 en production devra sans doute supporter plus qu'un seul utilisateur à la base de donnée SQLite venant par défaut avec Django : une application Web risque rapidement d'engendrer des erreurs de base de données verrouillée pour écriture par un autre processus. Il est donc nécessaire de passer sur quelque chose de plus robuste. https://docs.djangoproject.com/fr/3.0/howto/deployment/[Déploiement].
 
-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 à 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 basique. En bref, vous avez quelque chose qui fonctionne, mais qui ne ressemble pas à ce que vous souhaitez 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. On risque d'oublié une partie des désidératas ou une fonctionnalité essentielle, de passer beaucoup de temps à adapter les sources pour qu'elles fonctionnent sur un environnement en particulier ou d'être déconnecter de l'utilisateur réelle de votre application.
 
-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 maintenant permet également de rédiger dès le début les procédures d'installation, de mise à jour et de sauvegardes. Déployer 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.
 
-Dans cette partie, on abordera les points suivants:
+Dans cette partie, les points suivants seront abordés :
 
-* La définition de l'infrastructure nécessaire à notre application
+* 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.
 * Une partie sur la sécurité et la sécurisation de l'hôte.
@@ -18,7 +18,7 @@ Dans cette partie, on abordera les points suivants:
 Si on schématise l'infrastructure et le chemin parcouru par une éventuelle requête, on devrait arriver à quelque chose de synthéthique:
 
 * Au niveau de l'infrastructure, 
-    . l'utilisateur fait une requête via son navigateur (Firefox ou Chrome) 
+    . l'utilisateur fait une requête via son navigateur (Firefox, 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)
@@ -39,7 +39,7 @@ image::images/diagrams/django-process.png[]
 
 == 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, ...
+Comme abordé 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 ainsi possible de commencer 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, ...
 
 Pour une mise ne production, le standard *de facto* est le suivant:
 

source/part-2-deployment/database.adoc

@@ -1,7 +1,6 @@
 == Bases de données
 
-On l'a déjà vu, Django se base sur un pattern type https://www.martinfowler.com/eaaCatalog/activeRecord.html[ActiveRecords] pour la gestion de la persistance des données et supporte les principaux moteurs de bases de données connus: 
-
+Pour rappel, Django se base sur un pattern type https://www.martinfowler.com/eaaCatalog/activeRecord.html[ActiveRecords] pour la gestion de la persistance des données et supporte les principaux moteurs de bases de données connus :
 * SQLite (en natif, mais Django 3.0 exige une version du moteur supérieure ou égale à la 3.8)
 * MariaDB (en natif depuis Django 3.0), 
 * PostgreSQL au travers de psycopg2 (en natif aussi), 
@@ -16,7 +15,7 @@ Ci-dessous, quelques procédures d'installation pour mettre un serveur à dispos
 
 On commence par installer PostgreSQL.
 
-Par exemple, dans le cas de debian, on exécute la commande suivante:
+Par exemple, dans le cas de debian (?? Je pourrais rajouter les informations pour Mac ??), on exécute la commande suivante:
 
 [source,bash]
 ----