Stockage objet

Kuploy met à disposition un stockage objet infogéré : des buckets compatibles S3 pour les fichiers que produit votre application — fichiers envoyés par vos utilisateurs, images, vidéos, ressources générées, exports. Comme une base de données, un bucket est une ressource que vous créez dans votre projet et que vous reliez à votre application ; la plateforme le provisionne et vous injecte les identifiants, si bien que vous n'avez jamais à coller une clé.

Quand l'utiliser

Pensez au bucket dès que votre application stocke des fichiers qui doivent survivre à un redéploiement et être partagés entre les réplicas — autrement dit tout ce que vous mettriez sinon sur le disque local, qui est éphémère et propre à chaque pod. Comme il parle l'API S3, n'importe quel client convient : boto3, les SDK AWS, aws-cli, mc, rclone, ainsi que les adaptateurs de stockage de fichiers de la plupart des frameworks.

Créer un bucket

Ouvrez l'environnement de votre projet.
Cliquez sur Create Service → Bucket (catégorie Storage).
Renseignez :
- Name — un libellé pour le bucket (par exemple media) ;
- Quota (GiB) — la capacité maximale du bucket. 0 signifie illimité.
Cliquez sur Create. Le bucket existe désormais comme service, mais sans stockage ni clés : il apparaît comme Stopped, et sa page explique qu'il n'est pas provisionné.
Cliquez sur Provision. Cela crée le bucket sur le stockage partagé et génère sa clé d'accès dédiée.

Le provisionnement prend quelques secondes. Une fois terminé, la page du bucket affiche son endpoint, son nom de bucket, sa région, sa clé d'accès et sa clé secrète — cette dernière masquée jusqu'à ce que vous l'affichiez, chaque valeur étant copiable d'un clic.

Relier un bucket à votre application

Ne recopiez pas les identifiants à la main : Kuploy les injecte sous forme de variables d'environnement. Il y a deux façons de câbler un bucket à une application, et le choix dépend de la présence ou non d'une stack :

	Rattacher (sans stack)	Relier (dans une stack)
Où	Page du bucket → onglet Applications → Attach application	Plan de travail de la stack → tirer un fil du bucket vers l'application
Noms des variables	Imposés : `S3_ENDPOINT`, `S3_BUCKET`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION`	Vous les choisissez, un par champ
Buckets par application	Un seul	Autant que vous voulez (vous nommez les variables)
Bucket non provisionné	Refusé — provisionnez d'abord	Accepté ; Deploy stack le provisionne avant l'application
Apparaît comme	Attached services sur la page de l'environnement, et un nœud en pointillés sur toute stack contenant l'application	Un composant de la stack, avec son fil

Les deux maintiennent l'application à jour : reprovisionner le bucket renouvelle ses clés et réécrit les variables de toutes les applications rattachées comme reliées ; détacher ou déconnecter les retire. Dans les deux cas, l'effet se produit au prochain déploiement de l'application.

Rattacher (sans stack)

Ouvrez le bucket, allez dans l'onglet Applications, cliquez sur Attach application et choisissez une application du même environnement. Son onglet Environment reçoit les cinq variables ci-dessus, dans un bloc géré (marqué do not edit) ; elles prennent effet à son prochain déploiement. Le détachement se fait depuis le même onglet.

Un rattachement est refusé, avec la raison, lorsque le bucket n'est pas encore provisionné, lorsque l'application a déjà un autre bucket rattaché (les noms de variables étant imposés, le second écraserait le premier — passez par une connexion de stack si une application a besoin de deux buckets), ou lorsque le bucket atteint déjà cette application par une connexion de stack (un seul écrivain par application : supprimez d'abord la connexion, ou continuez de l'utiliser).

Relier (dans une stack)

Dans une stack, tirez une connexion du bucket vers votre application et associez chaque champ à la variable d'environnement que votre application attend :

Champ du bucket	De quoi il s'agit	Variable habituelle
`endpoint`	Le point d'accès de l'API S3 (privé à votre cluster)	`S3_ENDPOINT` / `AWS_ENDPOINT_URL`
`bucket`	Le nom du bucket provisionné	`S3_BUCKET`
`accessKey`	L'identifiant de la clé d'accès	`AWS_ACCESS_KEY_ID`
`secretKey`	La clé secrète	`AWS_SECRET_ACCESS_KEY`
`region`	La région (arbitraire, mais exigée par la plupart des SDK)	`AWS_REGION`

Dans une stack, un bucket est un composant, et non un service rattaché : il figure aux côtés de votre application et de votre base, et c'est cette appartenance qui permet à Deploy stack de le provisionner avant l'application qui lira ses identifiants. Un bucket peut être les deux à la fois : membre d'une stack et rattaché à des applications extérieures. La seule chose qu'il ne peut pas faire, c'est atteindre la même application par les deux chemins.

Les valeurs résolues arrivent dans l'onglet Environment de votre application, dans un bloc géré (marqué do not edit), et se mettent à jour toutes seules : si vous renouvelez les clés ou reprovisionnez le bucket, les applications reliées reprennent les nouvelles valeurs à leur prochain déploiement.

astuce

La connexion est unidirectionnelle et côté serveur : les identifiants sont résolus dans l'environnement du consommateur au moment du déploiement et ne sont jamais exposés au navigateur. Gardez-les côté serveur dans votre application également — ne les transmettez pas au code exécuté dans le navigateur.

Exemple (Python / boto3)

Avec les variables ci-dessus injectées, aucun identifiant n'apparaît dans votre code :

import boto3, os

s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["S3_ENDPOINT"],
    aws_access_key_id=os.environ["AWS_ACCESS_KEY_ID"],
    aws_secret_access_key=os.environ["AWS_SECRET_ACCESS_KEY"],
    region_name=os.environ["AWS_REGION"],
)
s3.upload_file("vignette.png", os.environ["S3_BUCKET"], "cours/1/vignette.png")

Quotas

Chaque bucket a sa propre limite de capacité. Lorsqu'un bucket atteint son quota, les envois vers ce bucket échouent avec une erreur de quota — les autres buckets et les autres services ne sont pas affectés. Mettez 0 pour un stockage illimité.

Choisissez le quota à la création du bucket

La limite est appliquée au stockage sous-jacent au moment du provisionnement, et la console n'offre aucun réglage pour la modifier ensuite : le chiffre affiché sur la page du bucket et dans Organization storage est celui avec lequel il a été provisionné. Pour changer le quota d'un bucket, il faut le reprovisionner, ce qui réapplique la limite mais renouvelle aussi ses clés (voir ci-dessous).

Reprovisionner

Re-provision relance le provisionnement auprès du stockage sous-jacent. L'opération est sans danger pour vos données — le bucket et son contenu sont conservés — mais elle génère une nouvelle clé d'accès et une nouvelle clé secrète, et réapplique le quota défini à ce moment-là.

Les applications reliées sont mises à jour pour vous : les nouveaux identifiants sont résolus dans leur environnement, et elles les utilisent dès leur prochain déploiement. Les identifiants que vous avez recopiés à la main, eux, ne sont pas mis à jour et commenceront à échouer sur une erreur d'authentification — une raison de plus de relier plutôt que de coller.

Suivre la consommation

Une fois le bucket provisionné, sa page de détail affiche un panneau Storage usage, avec des chiffres en direct lus auprès du stockage :

Objects — le nombre d'objets que contient le bucket ;
Total size — le volume stocké ;
Quota fill — une barre indiquant le remplissage par rapport au quota (masquée lorsque le quota vaut 0, c'est-à-dire illimité) ;
une pastille Reachable / Unreachable pour le stockage partagé : s'il est injoignable, la pastille en donne la raison plutôt que d'afficher des zéros en silence.

Pour une vue d'ensemble de tous les buckets de votre organisation, ouvrez Settings → Organization storage (réservé aux administrateurs de l'organisation). On y trouve le total des objets, le volume total et la somme des quotas, avec un détail par bucket et la joignabilité de chacun — la façon la plus rapide de voir où part votre stockage sans ouvrir les buckets un par un.

Accès et isolation

Chaque bucket reçoit sa propre clé d'accès, valable pour lui seul : les identifiants d'un bucket ne peuvent ni lire ni écrire dans un autre. Le point d'accès n'est joignable que depuis l'intérieur de votre cluster, par vos autres services, et non depuis l'internet public : les objets envoyés sont donc servis à travers votre application plutôt qu'exposés directement.

Supprimer un bucket

La suppression se fait depuis la page de détail du bucket ; son nom vous sera demandé pour confirmer. Elle retire définitivement le bucket, tout ce qu'il contient et sa clé d'accès. Il n'y a pas de retour en arrière : téléchargez d'abord ce dont vous avez besoin.

Bonnes pratiques

Reliez, ne collez pas — câblez le bucket à votre application pour que les identifiants s'injectent tout seuls et se renouvellent proprement.
Un bucket par usage — séparez par exemple les médias publics des exports privés ; chacun a sa clé et son quota.
Fixez un quota — plafonnez la croissance pour qu'une fonctionnalité emballée ne remplisse pas le bucket à votre insu.
Gardez les clés côté serveur — n'exposez jamais les variables AWS_* injectées au code du navigateur ; servez ou relayez les fichiers via votre application.
Stockez le chemin, pas le fichier — conservez les clés d'objets dans votre base de données et servez le contenu depuis le bucket à la demande.

Quand l'utiliser​

Créer un bucket​

Relier un bucket à votre application​

Rattacher (sans stack)​

Relier (dans une stack)​

Exemple (Python / boto3)​

Quotas​

Reprovisionner​

Suivre la consommation​

Accès et isolation​

Supprimer un bucket​

Bonnes pratiques​