Volumes
Un disque qui survit à une copie. D'où il vient, ce à quoi il survit, comment le parcourir et le sauvegarder.
Tout ce qu'une copie en cours d'exécution écrit dans son propre système de fichiers est perdu quand cette copie redémarre. Un volume est un répertoire qui est conservé.
Sur ISOGrid, vous ne créez pas de volumes à la main. Ils viennent avec ce que vous déployez. Cette page explique d'où ils viennent, ce à quoi chacun survit, et ce que vous pouvez en faire.
Volume ou espace de stockage
Un volume est un répertoire. Utilisez-le pour un logiciel qui attend des fichiers sur disque et que vous ne pouvez pas modifier : un CMS avec un dossier de téléversements, un outil qui lit ses extensions depuis un chemin.
Un espace de stockage est accessible par le réseau en S3, par autant d'applications que vous voulez, depuis n'importe où. Utilisez-le quand vous écrivez le code vous-même. C'est le meilleur endroit pour des fichiers servis par plusieurs copies, et pour des fichiers qui doivent être accessibles en dehors de l'application. Voir Stockage objet.
Les lignes vont dans une base de données, ni dans l'un ni dans l'autre.
D'où vient un volume
Le disque d'une application vient avec sa taille. Certains types d'instance
incluent du disque, affiché en Go à côté du CPU et de la mémoire. Choisissez-en
un et l'application reçoit un seul répertoire, monté sur /data. C'est la seule
façon d'en obtenir un. Vous ne pouvez pas en ajouter un second, ni choisir le
chemin, et les volumes d'un fichier stack ou compose ne sont pas créés.
L'import vous le dit plutôt que de les ignorer en silence.
Les fichiers d'une solution viennent avec la solution. WordPress, Odoo, n8n et les autres solutions prêtes à l'emploi conservent vos propres fichiers sur un volume créé avec elles : thèmes, extensions, téléversements, modules, workflows.
Les bases de données et les services managés conservent eux aussi leurs données sur disque, mais ce disque est celui du moteur : ce n'est pas à vous de l'ouvrir. Il n'est pas listé.
Ce à quoi il survit
Le disque d'une application est conservé quand l'application redémarre, est redéployée, change d'échelle ou passe sur une autre machine. Chaque copie de l'application voit le même répertoire.
Trois limites vont avec :
- Rien n'arbitre entre les copies. Deux copies qui écrivent le même fichier au même moment l'abîmeront. Un fichier de base de données embarquée sur un disque partagé exige exactement une copie.
- Le disque est conservé à un seul endroit de la région et n'est pas répliqué. Davantage de copies protègent l'application, pas ses fichiers. Tant que le stockage est indisponible, l'application ne peut pas les lire.
- La taille est une limite stricte. Quand le disque est plein, les écritures échouent.
Passer à un type d'instance avec plus de disque l'agrandit au déploiement suivant et conserve ce qui s'y trouve. Il ne rétrécit pas : ne faites pas passer une application qui contient des fichiers sur un type d'instance avec moins de disque.
Le stockage des applications se met en place par région. Là où une région ne
l'a pas encore, l'application se déploie quand même, sans le disque, et le
journal de déploiement le dit. Lisez cette ligne avant de confier quoi que ce
soit à /data.
Les fichiers d'une solution se trouvent sur la machine où la solution a été créée, et la solution reste sur cette machine. Ils sont conservés lors d'un redémarrage, d'un arrêt suivi d'un démarrage, d'un redimensionnement et d'un redéploiement. Si cette machine est arrêtée, la solution l'est aussi jusqu'à son retour.
Regarder à l'intérieur
La page Volumes liste les volumes qu'utilisent vos applications en cours d'exécution, avec l'application et le chemin sur lequel chacun est monté. La page d'une application montre la même chose pour cette application, et une solution a une vue de ses fichiers.
La navigation est en lecture seule. Vous pouvez lister des répertoires et ouvrir des fichiers. Vous ne pouvez ni téléverser, ni modifier, ni renommer, ni supprimer, que ce soit dans la console ou par l'API. Modifiez les fichiers à travers l'application elle-même.
À quoi vous attendre :
- Seul ce qui tourne est listé. Une application arrêtée n'a aucune copie depuis laquelle lire.
- Un fichier est affiché jusqu'à ses 512 premiers Ko, et un répertoire jusqu'à ses 1 000 premières entrées. La page indique quand elle s'est arrêtée avant la fin.
- Un fichier qui n'est pas du texte est affiché sous forme d'aperçu approximatif, pas de son contenu.
- Pour une solution, seuls vos propres fichiers sont affichés. Les données du moteur sont conservées ailleurs et ne peuvent pas être atteintes en les nommant.
Sauvegardes
Les fichiers d'une solution se sauvegardent depuis sa vue Sauvegardes. Une sauvegarde est une copie du répertoire entier, faite ailleurs. Elle est désactivée par défaut.
- À la demande. « Sauvegarder maintenant » fait une copie et ne lance aucune planification.
- Planifiée. Toutes les heures, tous les jours, toutes les semaines ou tous les mois. Pour tout sauf l'horaire, vous choisissez l'heure, en UTC. Une sauvegarde mensuelle se règle au plus tard le 28, pour qu'elle s'exécute aussi en février.
- Conservée trois jours au plus. C'est un plafond, pas une valeur par défaut que vous pourriez augmenter. La copie d'un répertoire entier est un filet de sécurité contre une mauvaise extension ou une suppression par erreur, pas une archive. Téléchargez la copie que vous voulez garder plus longtemps.
- Désactiver la planification ne supprime rien. Les copies déjà faites restent jusqu'à leur expiration.
Une sauvegarde copie ce répertoire et rien d'autre. Une base de données qu'utilise la solution n'en fait pas partie.
Une copie faite pendant que la solution tourne peut être accompagnée d'une note indiquant que des fichiers ont changé pendant leur lecture. Elle reste utilisable, mais c'est un instant légèrement flou plutôt qu'un instant exact.
La restauration est destructive. Le répertoire est vidé et la copie est mise à sa place. Tout ce qui a été écrit depuis cette copie est perdu. Arrêtez d'abord la solution : une restauration est refusée tant qu'elle tourne, car restaurer sous un site en cours d'exécution le laisse pour moitié sur la copie et pour moitié sur ce qui était là.
Pour le disque d'une application, la console ne propose que la navigation. Si ses fichiers comptent, gardez-en une seconde copie à un endroit où votre application écrit, par exemple un espace de stockage.
Supprimer
Il n'y a pas de suppression séparée pour un volume. Il part avec ce qui le possède.
Supprimer une application supprime son disque et tous les fichiers qu'il contient. Un redéploiement, un redémarrage ou un changement d'échelle ne le fait jamais.
Supprimer une solution supprime ses fichiers et sa base de données. Il n'y a pas de retour en arrière.
Téléchargez toute sauvegarde que vous voulez garder avant de supprimer. Ne comptez pas sur des copies qui survivraient à ce dont elles ont été tirées.
Cas particuliers à connaître avant d'y être confronté
La page Volumes est vide. Rien de ce qui a un volume ne tourne. Démarrez l'application et regardez à nouveau.
Une image déclare son propre volume. Il apparaît dans la liste tant que l'application tourne, mais il appartient à une seule copie et n'est pas conservé : une nouvelle copie démarre avec un volume vide. Seul le disque qui vient avec le type d'instance est conservé.
Une ligne est marquée comme montage lié. C'est un chemin sur la machine et non un volume. Il est listé et ne peut pas être ouvert.
L'application a écrit un fichier et vous ne le retrouvez pas. Il a été écrit
en dehors de /data, dans le système de fichiers propre à la copie, et il est
parti avec elle.
Pour continuer
- Stockage objet pour des fichiers partagés en S3.
- Déployer une application
- Quand ça ne va pas