Split S3 files storage from PaaS deployment

book/deployment/files-storage.adoc

@@ -0,0 +1,14 @@
+== Stockage de fichiers
+
+Nous avons pris comme parti dans le chapitre précédent d'héberger nos fichiers sur le serveur où est déployée notre application.
+En cas de nécessité de déplacer ou redéployer le serveur, nous créons _de facto_ une dépendance supplémentaire.
+La solution consiste à externaliser l'hébergement des fichiers statiques et utilisateurs vers un espace de stockage décentralisé (de notre application).
+
+Il existe plusieurs manières de réaliser ceci ; le tout est de s'accorder sur une solution :
+
+* Pour une architecture déployée sur site - sur un réseau privé ou autre -, un point de montage en CIFS ou NFS peut être largement suffisant,
+* Dès que votre application dépassera les murs de votre réseau privé, les _buckets compatibles S3_ constituent une très bonne solution - et sont disponibles chez pratiquement tous les hébergeurs connus (Amazon, Scaleway ou OVH, pour ne citer qu'eux).
+
+Heroku (((Heroku))) - que nous verrons au prochain chapitre - propose des espaces de déploiements, mais pas d’espace de stockage.
+Il est possible d’y envoyer des fichiers utilisateurs (typiquement, des media personnalisés), mais ceux-ci seront perdus lors du redémarrage du container.
+Il est donc primordial de configurer correctement l’hébergement des fichiers média, de préférences sur un stockage compatible S3 (((S3))).

book/deployment/paas.adoc

@@ -1,7 +1,6 @@
 == _Platform as a Service_
 
-Les _Plateform As A Service_ , où vous choisissez le _service ou le composant_ dont vous avez besoin (une base de données, un service de cache, un service applicatif, ...), vous lui
-envoyer les paramètres nécessaires et le tout démarre gentiment sans que vous ne deviez superviser l’hôte.
+Les _Plateform As A Service_ , où vous choisissez le _service ou le composant_ dont vous avez besoin (une base de données, un service de cache, un service applicatif, ...), vous lui envoyer les paramètres nécessaires et le tout démarre gentiment sans que vous ne deviez superviser l’hôte.
 En pratique, ce mode démarrage se conforme aux 12 facteurs dont nous avons déjà parlé plus tôt - modifier un paramètre reviendra à couper l'instance actuelle pour en déployer une nouvelle.
 
 [NOTE]
@@ -10,22 +9,23 @@ Dans la suite, nous prendrons Heroku, mais il existe d’autres plateformes simi
 Le fonctionnement de ces différentes plateformes est généralement similaire (si pas identique...), et consiste généralement à respecter certaines conventions de configuration et à suivre certaines étapes spécifiques pour la mise à disposition.
 ====
 
-=== Heroku
-
-Pour un projet de type "hobby" et pour l’exemple de déploiement ci-dessous, il est tout à fait possible de s’en sortir sans dépenser un kopek, afin de tester nos quelques idées ou mettre rapidement un _Most Valuable Product_ en place.
-La seule contrainte consistera à pouvoir héberger des fichiers envoyés par vos utilisateurs - ceci pourra être
-fait en configurant un _bucket compatible S3_, par exemple chez Amazon, Scaleway ou OVH.
-
 [DANGER]
 ====
-Par la suite, il conviendra d’investir un minimum : sur le _tiers_ par défaut, des bases de données sont disponibles, mais montrent rapidement leurs limites.
-Les 10 000 enregistrements "_offerts_" sont une limite *très* rapidement atteinte, tandis qu’aucun mécanisme de migration n’est prévu.
-Ceci signifie qu’après avoir démarré un projet en mode "hobby", il vous sera nécessaire de gérer vous-même la migration de vos données, dans la mesure où aucun processus automatique n’existe entre instances de deux niveaux différents.
+Anciemmenent, Heroku proposait des projets de type "hobby", gratuits, à condition de respecter quelques contraintes.
+Ces contraintes étaient faciles à respecter, sous réserve de ne vouloir mettre qu'une simple application à disposition de quelques utilisateurs seulement, ou pour rapidement mettre un _Most Valuable Product_ (((MVP, Most Valuable Product))) en place.
+
+Par la suite, il convenait d’investir un minimum : sur le _tiers_ par défaut, des bases de données étaient disponibles, mais montraient rapidement leurs limites.
+Les 10 000 enregistrements "_offerts_" étaient une limite *très* rapidement atteinte, tandis qu’aucun mécanisme de migration n’était prévu.
+
+Ceci signifiait qu’après avoir démarré un projet en mode "hobby", il vous était nécessaire de gérer vous-même la migration de vos données, dans la mesure où aucun processus automatique n’existait entre instances de deux niveaux différents.
+
+A présent, ces instances ont disparu et il est nécessaire de passer au minimum sur le premier tiers payant.
 ====
 
 Le fonctionnement est relativement simple : pour chaque application, Heroku crée un dépôt Git qui lui est associé.
-Il suffit donc d’envoyer les sources de votre application vers ce dépôt pour qu’Heroku les interprête comme étant une nouvelle version, déploie les nouvelles fonctionnalités - sous réserve que tous les tests passent correctement - et les  mettent à disposition.
-Dans un fonctionnement plutôt manuel, chaque déploiement est initié par le développeur ou par un membre de l’équipe. Dans une version plus automatisée, chacun de ces déploiements peut être placé en fin de _pipeline_, lorsque tous les tests unitaires et d’intégration auront été réalisés.
+Il suffit donc d’envoyer les sources de votre application vers ce dépôt pour qu’Heroku les interprête comme étant une nouvelle version, déploie les nouvelles fonctionnalités - sous réserve que tous les tests passent correctement - et les mettent à disposition après avoir exécuté un ou plusieurs scripts de migration.
+Dans un fonctionnement plutôt manuel, chaque déploiement est initié par le développeur ou par un membre de l’équipe.
+Dans une version plus automatisée, chacun de ces déploiements peut être placé en fin de _pipeline_, lorsque tous les tests unitaires et d’intégration auront été réalisés.
 
 Au travers de la commande `heroku create`, vous associez donc une nouvelle référence à votre code source, comme le montre le contenu du fichier `.git/config` ci-dessous :
 
@@ -53,25 +53,18 @@ $ cat .git/config
 Pour définir de quel type d'application il s'agit, Heroku nécessite un minimum de configuration.
 Celle-ci se limite aux deux fichiers suivants :
 
-* Déclarer un fichier `Procfile` qui va simplement décrire le fichier à passer au protocole WSGI
-* Déclarer un fichier `requirements.txt` (qui va éventuellement chercher ses propres dépendances dans un sous-répertoire, avec l'option `-r`)
+* Déclarer un fichier `Procfile` qui va simplement décrire le fichier à exécuter au travers du protocole WSGI (((WSGI))),
+* Déclarer un fichier `requirements.txt`, qui ira éventuellement chercher ses propres dépendances dans un sous-répertoire, avec l'option `-r`.
 
-Après ce paramétrage, il suffit de pousser les changements vers ce nouveau dépôt grâce à la commande `+git push heroku main+`.
+Après ce paramétrage, il suffit de pousser les changements vers ce nouveau dépôt grâce à la commande `git push heroku main`.
 
 [WARNING]
 ====
-Puisque nous avons précedemment proposé d’utiliser Poetry, la commande `+export+` pourra être utilisée pour générer le fichier `+requirements.txt+`, comme exigé par Heroku.
+Puisqu'Heroku exige un fichier `requirements.txt` placé à la racine du projet, et puisque nous avons précédemment proposer d'utiliser Poetry, il sera nécessaire d'inclure la commande `export` afin de le fichier `requirements.txt`, comme exigé par Heroku.
 ====
 
-Heroku propose des espaces de déploiements, mais pas d’espace de
-stockage. Il est possible d’y envoyer des fichiers utilisateurs
-(typiquement, des media personnalisés), mais ceux-ci seront perdus lors
-du redémarrage du container. Il est donc primordial de configurer
-correctement l’hébergement des fichiers média, de préférences sur un
-stockage compatible S3. s3
-
-Prêt à vous lancer ? Commencez par créer un compte :
-https://signup.heroku.com/python.
+Prêt à vous lancer ?
+Commencez par créer un compte : https://signup.heroku.com/python.
 
 === Configuration du compte
 
@@ -83,7 +76,7 @@ première application; heureusement, la documentation est super bien
 faite:
 
 .Heroku: Commencer à travailler avec un langage
-image::images/deployment/heroku-new-app.png[images/deployment/heroku-new-app]
+image::deployment/heroku/new-app.png[align="center"]
 
 Installez ensuite la CLI (_Command Line Interface_) en suivant
 https://devcenter.heroku.com/articles/heroku-cli[la documentation
@@ -93,29 +86,27 @@ Au besoin, cette CLI existe pour :
 
 . macOS, _via_ ‘brew ‘
 . Windows, grâce à un
-https://cli-assets.heroku.com/heroku-x64.exe[binaire x64] (la version 32
-bits existe aussi, mais il est peu probable que vous en ayez besoin)
+https://cli-assets.heroku.com/heroku-x64.exe[binaire x64],
 . GNU/Linux, via un script Shell
-`+curl https://cli-assets.heroku.com/install.sh  sh+` ou sur
+`curl https://cli-assets.heroku.com/install.sh  sh+` ou sur
 https://snapcraft.io/heroku[SnapCraft].
 
 Une fois installée, connectez-vous :
 
-....
-    $ heroku login
-....
+```bash
+$ heroku login
+```
 
 Et créer votre application :
 
-....
-    $ heroku create
-    Creating app... done, -> young-temple-86098
-    https://young-temple-86098.herokuapp.com/ | https://git.heroku.com/young-
-    temple-86098.git
-....
+```bash
+$ heroku create
+Creating app... done, -> young-temple-86098
+https://young-temple-86098.herokuapp.com/ | https://git.heroku.com/young-temple-86098.git
+```
 
 .Notre application est à présent configurée!
-image::images/deployment/heroku-app-created.png[images/deployment/heroku-app-created]
+image::deployment/heroku/app-created.png[align="center"]
 
 Ajoutons lui une base de données, que nous sauvegarderons à intervalle
 régulier :

deployment.asc

@@ -114,6 +114,8 @@ include::book/deployment/logs.adoc[]
 
 include::book/deployment/native.adoc[]
 
+include::book/deployment/files-storage.adoc[]
+
 include::book/deployment/paas.adoc[]
 
 include::book/deployment/cloud-native.adoc[]