Integrate IaaS

source/main.adoc

@@ -70,8 +70,6 @@ footnote:[Avec même un peu d'https://www.xkcd.com[XKCD] et de Calvin & Hobbes d
 
 === Let's keep in touch
 
-
-
 include::part-1-workspace/_main.adoc[]
 
 include::part-2-deployment/_main.adoc[]
@@ -85,6 +83,8 @@ include::part-9-resources/_index.adoc[]
 [glossary]
 = Glossaire
 
+IaaS:: _Infrastructure as a Service_, où un tiers vous fournit des machines (généralement virtuelles) que vous devrez ensuite gérer en bon père de famille. L'IaaS propose souvent une API, qui vous permet d'intégrer la durée de vie de chaque machine dans vos flux - en créant, augmentant, détruisant une machine lorsque cela s'avère nécessaire.
+
 ORM:: _Object Relational Mapper_, où une instance est directement (ou à proximité) liée à un mode de persistance de données.
 
 PaaS:: _Platform as a Service_, qui consiste à proposer les composants d'une plateforme (Redis, PostgreSQL, ...) en libre service et disponibles à la demande (quoiqu'après avoir communiqué son numéro de carte de crédit...).
@@ -93,4 +93,4 @@ PaaS:: _Platform as a Service_, qui consiste à proposer les composants d'une pl
 == Index
 
 == Bibliographie
-bibliography::[]
+bibliography::[]

source/part-2-deployment/_main.adoc

@@ -8,9 +8,9 @@ Unfortunately, deployment strategy is seldom considered during initial developme
 This leads to architectures that may be make the system easy to develop, but leave it very difficult to deploy.
 
 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 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 fonctionnent sur un environnement en particulier.
+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
@@ -20,9 +20,29 @@ Aborder le déploiement dès le début permet également de rédiger dès le dé
 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...
+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, mais qui ressemble de très loin à ce dont vous aurez besoin au final.
+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.
+
+.L'infrastructure en tant que service, cc. _RedHat Cloud Computing_
+[link=https://www.redhat.com/fr/topics/cloud-computing/what-is-iaas]
+image::images/deployment/iaas_focus-paas-saas-diagram.png[]
+
+Ainsi, on trouve:
+
+1. Le déploiment _on-premises_ ou _on-site_
+2. Les _Infrastructures as a service_ ou _((IaaS))_
+3. Les _Platforms as a service_ ou _((PaaS))_
+4. 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:
 
@@ -39,7 +59,7 @@ Pour une mise ne production, le standard _de facto_ est le suivant:
  * 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.
+ * 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
@@ -133,7 +153,7 @@ 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 *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