Il faut bien le reconnaitre l’arrivée du Cloud a popularisé pas mal de nouvelles technologies. Parmi elles, une doit vous revenir assez rapidement en tête: l’Object Storage. Popularisé par le service S3 d’AWS, cela permet de stocker des objets dans un espace normalisé au travers d’une API. D’ailleurs il est intéressant de voir qu’aujourd’hui cette technologie est tellement populaire que la plupart des Cloud Provider proposent des services d’Object Storage compatibles avec la technologie S3 d’AWS.
En général les Buckets (espace de stockage d’objets), sont utilisés pour beaucoup de besoins divers. Globalement ils sont utilisés pour stocker des fichiers durant un traitement, ou directement des assets web (ce blog est d’ailleurs entièrement hébergé dessus). Au-delà de ces usages plutôt classiques, des personnes ont eu une idée originale: créer un système de fichiers qui utilise les buckets comme base pour le stockage ! Je vous propose donc dans cet article de tester la mise en place de cette solution et de voir ce que cela donne dans la pratique.
Tutoriel : Installons tout ça
Mise en place du lab
Je vais faire cet exemple sur AWS (avec Terraform), car c’est un Cloud que je connais bien, néanmoins il est tout à fait possible de le faire chez d’autres Cloud Provider en adaptant un peu. Pour ce test nous avons besoin de certaines ressources: nous allons donc commencer par les créer. Je ne rentrerai pas dans les détails concernant cette partie, mais je vais quand même revenir sur deux ou trois points qui me semblent importants.
Le code Terraform du lab est disponible de manière complète sur Github: Projet Github
On commence par créer notre instance, rien de particulier a signaler ici. J’utilise l’image officielle (AMI) de Debian 11 sur AWS. Les plus attentifs auront tout de même remarqué que je créai aussi un rôle IAM que j’attache à l’instance. Ce rôle donnera le droit à mon instance et tout programmes s’exécutant dessus d’utiliser le S3, notamment FuseFS ce qui nous intéresse dans notre cas. C’est une bonne pratique de sécurité d’utiliser cette fonctionnalité plutôt que des tokens dans des fichiers, cela réduit les possibilités de fuite de token.
data "aws_iam_policy_document" "bucket_access" {
statement {
effect = "Allow"
actions = [
"s3:*"
]
resources = [aws_s3_bucket.this.arn]
}
}
On continue ensuite avec le bucket S3 des plus classiques, on note tout de même que l’on bloque les droits de publication d’objets publiquement afin d’éviter toute erreur et de réduire les risques de fuite encore une fois.
resource "aws_s3_bucket" "this" {
bucket = var.bucket_name
acl = "private"
}
resource "aws_s3_bucket_public_access_block" "this" {
bucket = aws_s3_bucket.this.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
A noter que ce blocage peut-être fait au niveau du compte AWS, ce qui permet de bloquer tous les buckets du compte. C’est une option à considérer sérieusement en entreprise sur les comptes qui n’ont pas à exposer de donnés publiquement pour éviter encore une fois les fuites.
Installation et configuration de FuseFS
Nous allons donc installer et configurer S3 FS, vous allez voir c’est très simple. Le package est disponible sur les dépôts standards de la distribution, ici Debian donc un simple apt -y install s3fs
suffit. Après l’installation, il nous suffit d’ajouter notre nouveau FS dans le fichier /etc/fstab
et de faire un petit mount -a
. Nous ajoutons donc la ligne suivante :
NOM_BUCKET PATH_POINT_MONTAGE fuse.s3fs _netdev,allow_other,iam_role=NOM_DE_VOTRE_ROLE,url=https://s3-eu-west-1.amazonaws.com,use_cache=/tmp 0 0
Décomposition là ensemble, pour comprendre les différentes options :
- _netdev : permet de préciser au système (
systemd.mount
) qu’il s’agit d’un volume réseau. - allow_other : permet d’autoriser d’autres utilisateurs que l’utilisateur ayant monté le volume (en général root).
- iam_role : permet de définir le rôle IAM à utiliser, celui-ci étant créé et attaché au point précédent.
- url : définit l’endpoint à contacter, ici nous paramétrons eu-west-1 car nous avons installé notre lab en Irlande.
- use_cache : comme vous l’avez compris, nous utilisons directement un bucket en backend, donc chaque action sur le FS se traduit par un appel API, ce qui provoque de la latence. Néanmoins on peut définir un espace de cache afin de stocker les fichiers localement et donc limiter l’impact.
Si jamais vous rencontrez des soucis, voici quelques pistes pour debug :
- Vérifier que vous avez le bon rôle (sensible à la casse) :
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/NOM_DE_VOTRE_ROLE
- Montez le directement avec l’utilitaire, sans passer par
fstab
:s3fs -o iam_role=NOM_DE_VOTRE_ROLE -o url=”https://s3-eu-west-1.amazonaws.com" -o endpoint=eu-west-1 -o curldbg -o allow_other NOM_BUCKET PATH_POINT_MONTAGE
- Passez en mode debug :
s3fs -o iam_role=NOM_DE_VOTRE_ROLE -o url=”https://s3-eu-west-1.amazonaws.com" -o dbglevel=info -o endpoint=eu-west-1 -o curldbg -o allow_other NOM_BUCKET PATH_POINT_MONTAGE
On peut maintenant tester notre installation, en jouant avec des fichiers sur ce nouveau FS !
Que penser de fuseFS (et de l’utilisation de S3 en tant que fs)
Comme vous l’avez vu, l’installation et la configuration sont assez triviales, ça fonctionne plutôt bien, malgré quelques problèmes de droits qui peuvent arriver. Comme je le laissais entendre, il y a bien évidemment des performances bien en dessous de ce que l’ont peut avoir avec du stockage classique (EBS par exemple). N’y espérez donc pas y stocker de gros fichiers, ou dans ce cas armez-vous de patience.
On peut se demander à quoi cela peut-il servir du coup. Clairement pas à tout le monde, mais dans pas mal de petits besoins cela peut s’avérer très simple et efficace. Par exemple si vous souhaitez garder de côté pour traiter des fichiers d’une instance en autoscaling, cela peut-être moins lourds qu’un EBS. Néanmoins, au vu des performances et des quelques soucis de droits que j’ai pu voir, je déconseille de l’utiliser pour des besoins sensibles.
Au-delà du stockage, on pourrai aussi imaginer l’intégrer dans des workflows simples, par exemple en backend de stockage à un petit serveur FTP. Quand la personne upload un fichier, qui va dans S3 on pourrait déclencher automatiquement et nativement une action pour informer par mail ou chat de l’ajout d’un fichier.
Ce n’est donc pas un logiciel qui va changer le monde et qui sera utilisé à toutes les sauces, mais une bonne solution à garder sous le coude.
Head photo by Luca Bravo on Unsplash