Le système de fichiers virtuel S3 permet de manipuler des documents stockés dans un cloud Amazon S3 comme s'il s'agissait de fichiers locaux dans une application Adélia cloud. Il est basé sur une implémentation d'un système de fichiers Java NIO implémentant l'ensemble des fonctions de base d'un système de fichiers.
Le système de fichiers est notamment compatible Minio ( https://min.io/ ) ce qui permet de déclarer l'accès à un stockage de type cloud privé.
Déclaration d'un système de fichiers S3
Le système de fichiers virtuel S3 est implémenté par la classe Java " com.hardis.wagon.s3.vfs.WagonS3FileSystem". Il est déclaré de façon classique dans le fichier "wagon.xml".
Nota : il est possible de spécifier la racine du serveur comme chemin root ( rootPath ="/"). Dans ce cas, seuls les buckets appartenant explicitement à l'utilisateur seront visibles et ils seront traités comme des répertoires.
Exemple de déclaration d'un VFS S3 sur le bucket "data" :
|
L'ensemble des paramètres de configuration standard d'un VFS est applicable. Les paramètres de connexion spécifiques au VFS S3 sont les suivants :
endpoint | Adresse du serveur sous la forme " hote:port ". Par exemple : " myminio: 9000" |
region | Région S3. |
accessKey | Clé d'accès de l'application ou id utilisateur. |
secretKey | Clé secrète de l'application ou mot de passe de l'utilisateur. |
| |
connectionTimeout | Timeout de connexion en millisecondes, optionnel. |
protocol | Protocole de connexion (http ou https). Par défaut : http. |
trustStore | Permet de spécifier un truststore alternatif pour les connexions sécurisées. Par défaut : non renseigné, utilise le truststore de la JVM. |
trustStoreType | Type du truststore. Par défaut : jks. |
trustStorePassword | Mot de passe du truststore. Par défaut : changeit. |
keyStore | Permet de spécifier un keystore alternatif pour les connexions sécurisées. Par défaut : non renseigné, utilise le keystore de la JVM. |
keyStoreType | Type du keystore. Par défaut : jks. |
keyStorePassword | Mot de passe du keystore. Par défaut : changeit. |
keyPassword | Mot de passe de la clé. Par défaut : changeit. |
| |
overrideWritePermission | Le VFS utilise les ACLs S3 pour déterminer si un objet est accessible en écriture. Dans certains cas (Minio quand on n'est pas propriétaire du bucket, droits insuffisants), il n'est pas possible de lire les ACLs.
Dans ce cas, ce paramètre permet d'indiquer que, par défaut, on assume que les objets sont accessibles en écriture. Ce paramètre est optionnel et ne doit être utilisé qu'en cas de nécessité.
Valeurs possibles : true, false, false par défaut. |
Limitations du système de fichiers S3
Le VFS S3 émule de façon transparente un système de fichiers "normal". Pour maximiser l'interopérabilité, ce système de fichiers utilise le même séparateur que le système de fichiers natif (soit "\" sur Windows, "/" sur les plateformes Unix).
Le VFS respecte la norme POSIX pour les fichiers cachés : un fichier dont le nom commence par un "." n'est pas visible aux fonctions de recherche de fichier (" VaToolBxFindFirst ", " VaToolBxFindNext ", explorateur de fichiers), mais peut être accédé directement par les fonctions de gestion (création, suppression, lecture et modification).
Il y a néanmoins certaines limitations dont il est nécessaire d'être conscient.
Gestion des accès aux fichiers en lecture et en écriture
L'accès aux fichiers via les opérations de lecture ou d'écriture s'effectue en téléchargeant de façon transparente le contenu du fichier à l'ouverture quand cela est nécessaire, et en cas d'ouverture en écriture, en le téléchargeant sur le serveur lors de sa fermeture. Toutes les opérations intermédiaires se font sur une copie du fichier dans le répertoire temporaire de la machine.
Cela implique les limitations suivantes :
Il n'est pas possible de gérer des accès concurrents ou de verrouiller un fichier : deux personnes peuvent ouvrir concurremment un même fichier, et en cas de modification, ce sera le dernier qui a fermé le fichier qui définira son contenu.
Les performances peuvent être dégradées sur les fichiers de grande taille par le temps des opérations de téléchargement.
Du fait du téléchargement, et du fait que dans certains cas il est impossible de déterminer correctement les droits en écriture sur un fichier, la fermeture du fichier peut échouer (ce qui est rarement le cas sur un système de fichiers classique).
Il est par conséquent nécessaire de porter attention au résultat de l'appel de la méthode " VaToolBxCloseFile " dans le cas des fichiers ouverts en modification.
Le VFS n'implémente pas le multi- upload , ce qui limite la taille des fichiers pouvant être écrits à 5G B, et ne supporte pas le stockage GLACIER.
Gestion des droits d'accès aux fichiers
Le VFS S3 utilise les ACLs S3 pour déterminer le droit d'écriture sur un objet ou un bucket . Toutefois, cette méthode n'est que partiellement implémentée par " Minio " - la lecture des ACL ne fonctionne pas si l'on n'est pas le propriétaire de l'objet, et il est de plus possible que S3 ne soit pas configuré pour permettre la lecture des ACLs .
Pour autoriser l'accès en écriture dans ce cas, le VFS définit un paramètre permettant de forcer le droit en écriture par défaut si la lecture des ACL n'est pas supportée ou configurée ( overrideWritePermission , voir plus haut). Si ce paramètre est configuré à tort, il est possible que le VFS autorise l'ouverture d'un fichier en écriture, mais que la fermeture du fichier échoue avec une erreur "accès refusé".
D'autre part, la modification des ACL n'est pas supportée. Les fonctions " VaToolBxSetReadOnly " et " VaToolBxSetWritable " ne sont pas supportées par le VFS S3. ↑ Haut de page
Gestion des fichiers temporaires
Bien que le VFS S3 autorise la création de fichiers temporaires , cet usage est déconseillé. Le stockage Cloud doit être vu comme un support de stockage à long terme, les fichiers temporaires devraient être créés dans un répertoire local, de préférence dans le répertoire temporaire de l'utilisateur ou du système.
De même, il est déconseillé de créer des fichiers de type "logs" (qui restent ouverts pendant une longue période de temps et qui ne sont fermés qu'en fin de session) dans un VFS S3.
Gestion des répertoires
Dans la réalité, S3 est un système de fichiers plat qui ne possède pas la notion de répertoire. Les répertoires n'existent que virtuellement dès l'instant où ils contiennent des fichiers. Si tous les fichiers présents dans un répertoire sont supprimés (en réalité tous les objets dont le nom est préfixé par le nom du répertoire), le répertoire lui-même n'existe plus.
Par exemple, un objet S3 nommé "data/logs/wagon.log" sera interprété comme le fichier "wagon.log" dans le sous-répertoire "logs" du répertoire "data".
Pour simplifier et rendre transparente la gestion des répertoires, le VFS S3 crée automatiquement un fichier caché de nom " nom_repertoire /. virtual_folder " lorsque vous créez un répertoire, ce fichier étant masqué. De même, le VFS considérera un répertoire comme "vide" (et donc pouvant être supprimé par " VaToolBxRemoveDirectory ") quand il ne contiendra QUE ce fichier ". virtual_folder ".
Lorsque le VFS est créé à partir de la racine, il affiche les buckets appartenant à l'utilisateur connecté (paramètres accessKey et secretKey de la configuration du VFS) comme des répertoires. Dans ce cas :
Il est possible de créer un répertoire à la racine (création d'un bucket ), mais ce répertoire devra respecter le standard de nommage S3 (caractères alphanumériques et chiffres en minuscules, pas d'espaces ni de caractère de soulignement).
Le gestionnaire de fichier Adélia notamment ne peut pas créer un dossier à la racine d'un S3 car le nom "Nouveau dossier" ne respecte pas le standard de nommage.
Il n'est pas possible de créer un fichier à la racine : un fichier doit forcément être dans un bucket .
Un bucket accessible à l'utilisateur mais dont il n'est pas propriétaire n'apparaîtra pas dans l'explorateur de fichiers ni dans les listes de répertoires. Il est néanmoins possible d'accéder aux objets de ce bucket si l'on fournit un chemin complet.