Pourquoi sortir les fichiers du disque applicatif
Les containers applicatifs devraient être sans état afin de pouvoir être redéployés, scalés et annulés sans perdre les uploads des utilisateurs. Quand avatars, photos de produits, factures et vidéos sont écrits sur le système de fichiers du container, chaque redémarrage risque une perte de données et chaque réplica a un ensemble de fichiers différent. Object Storage résout cela en donnant à tous les réplicas un seul emplacement partagé et durable pour lire et écrire. Votre application reste jetable pendant que les données vivent de façon indépendante.
Réellement compatible S3, pas une simple imitation
Le service parle l'API S3, si bien que les outils que vous utilisez déjà continuent de fonctionner : l'aws-cli, boto3, l'AWS SDK for JavaScript, les pilotes de système de fichiers S3 de Laravel et Symfony, rclone, et s3cmd communiquent tous avec lui une fois que vous configurez l'URL du endpoint et la paire de clés. Les uploads multipart pour les gros fichiers, les métadonnées d'objet et la gestion du content-type se comportent comme les développeurs S3 s'y attendent. Cela signifie que migrer une application qui utilise déjà S3 est généralement un changement de configuration plutôt qu'une réécriture de code.
Buckets, access keys et rayon d'impact
Vous organisez les données en buckets et contrôlez l'accès avec des paires access key ID et secret key que vous pouvez régénérer ou révoquer à tout moment. Garder une clé par application ou par bucket limite le rayon d'impact : si une clé fuite dans un log ou un bundle client, vous révoquez cette seule paire et en générez une nouvelle sans toucher aux autres services. Le panneau liste les clés existantes afin que vous puissiez auditer et retirer celles qui ne sont plus utilisées.
Stockage et CDN fonctionnant comme un seul système
Comme Object Storage et le CDN edge font partie de la même plateforme, vous pouvez servir les objets du bucket via le cache sans câbler une origine séparée. Un bucket public ou une route edge signée devient un chemin de téléchargement rapide où les fichiers populaires sont mis en cache près des utilisateurs et ne sollicitent jamais le stockage de façon répétée. Quand vous remplacez un fichier sous une clé existante, une purge ciblée depuis le panneau ou cdnctl rafraîchit l'edge afin que personne ne reçoive une copie obsolète.
Lier le stockage aux applications containerisées
Au lieu de coller des identifiants dans votre Dockerfile ou de les versionner dans un dépôt, vous liez un bucket à une Container App et la plateforme livre le endpoint et les clés sous forme de variables d'environnement, éventuellement sous un préfixe afin que plusieurs buckets restent distincts. Votre code lit des noms d'env standards au runtime, les secrets n'apparaissent jamais dans l'image, et régénérer une clé met à jour le binding plutôt que de forcer un rebuild. Cela préserve la séparation douze-facteurs entre configuration et code.
Sauvegardes et données froides
Object Storage est un emplacement naturel pour les dumps de base de données, les sauvegardes applicatives et les exports d'archivage que vous voulez sortir du serveur principal tout en pouvant les restaurer rapidement. Comme l'accès est basé sur des clés et à portée limitée, une tâche de sauvegarde peut détenir une clé de workflow en écriture seule, distincte des clés utilisées par votre application en production. Scripté via cdnctl dans une tâche nocturne, les uploads et les nettoyages de rétention s'exécutent sans surveillance, et vous gardez une limite d'usage sur le bucket afin que les archives ne grossissent pas sans que personne ne le remarque.
Comment le configurer, étape par étape
Créer un bucket
Dans le panneau, ouvrez Object Storage et choisissez Create Bucket. Donnez-lui un nom compatible DNS (lettres minuscules, chiffres et tirets) et décidez si les objets doivent être privés par défaut ou lisibles publiquement. Le mode privé est le bon choix pour les sauvegardes et les originaux que vous signerez ou proxifierez ; le mode public read convient aux assets que vous comptez servir directement via le CDN.
Générer une paire d'access keys
Ouvrez l'onglet Access Keys et générez une clé. Vous obtenez un access key ID et une secret key ; la secret key n'est affichée qu'une seule fois, copiez-la donc immédiatement dans votre gestionnaire de secrets. Limitez la portée de la clé au bucket dont elle a besoin plutôt que de réutiliser une clé maître unique sur tous vos projets, afin qu'une fuite puisse être contenue en révoquant une seule paire.
Pointer un client S3 vers le endpoint
Configurez n'importe quel SDK S3 ou l'aws-cli avec l'URL du endpoint cdn.com.tr affichée sur la page du bucket, l'adressage path-style, et votre paire de clés. Par exemple : aws --endpoint-url <endpoint> s3 cp ./poster.jpg s3://my-media/posters/. Aucun client personnalisé n'est nécessaire car l'API parle le protocole S3.
Lier le bucket à une application containerisée
Sur une Container App, choisissez Bind Object Storage et sélectionnez le bucket. La plateforme injecte le endpoint, la région, l'access key et la secret key sous forme de variables d'environnement (avec un préfixe optionnel comme ASSETS_) afin que votre code les lise depuis l'environnement au lieu de coder les identifiants en dur dans l'image ou le dépôt.
Placer le tout derrière le CDN
Attachez un domaine ou utilisez la route edge du bucket afin que les objets soient servis depuis le cache aux points de présence edge. Définissez des en-têtes de cache lors de l'upload, et utilisez la purge depuis le panneau ou cdnctl lorsque vous écrasez un fichier sous la même clé pour que les visiteurs récupèrent la nouvelle version.
Définir des limites et automatiser avec cdnctl
Appliquez une limite d'usage sur le bucket pour vous prémunir contre une croissance incontrôlée, et scriptez les tâches routinières avec cdnctl afin que les uploads de sauvegarde et les nettoyages s'exécutent depuis la CI sans ouvrir le panneau. Régénérez les clés périodiquement depuis le même onglet Access Keys.
Exemples de scénarios
Un site e-commerce stocke chaque image produit et chaque upload original dans un bucket, sert les dérivés via le CDN, et garde les containers applicatifs sans état afin que les déploiements ne touchent jamais aux fichiers utilisateur.
Une application containerisée scalée sur plusieurs réplicas écrit les uploads utilisateur dans un seul bucket, si bien que chaque instance lit les mêmes fichiers et qu'un redémarrage ou un événement de scaling ne perd jamais de données.
Une tâche cron ou CI utilise une clé à portée limitée et cdnctl pour pousser des dumps de base de données compressés dans un bucket privé chaque nuit, avec une limite d'usage et un nettoyage de rétention gardant le coût prévisible.
Une équipe déjà sur AWS S3 repointe l'endpoint et les clés de son SDK vers cdn.com.tr, utilise rclone pour copier les objets, et livre sans réécrire le code de stockage.
Questions fréquentes
Quels outils et SDK S3 fonctionnent réellement avec lui ?
Les plus courants : aws-cli, boto3, l'AWS SDK for JavaScript, rclone, s3cmd, et les pilotes de système de fichiers S3 de Laravel et Symfony. Configurez l'URL du endpoint depuis la page du bucket, utilisez l'adressage path-style, et fournissez votre access key et votre secret key. Les uploads multipart pour les gros objets sont pris en charge.
Puis-je servir des fichiers du bucket directement au public via le CDN ?
Oui. Rendez le bucket ou l'objet lisible publiquement, ou utilisez la route edge du bucket, et attachez un domaine. Les objets sont alors mis en cache aux points de présence edge afin que les téléchargements répétés soient servis depuis le cache plutôt que de solliciter le stockage à chaque fois.
Que se passe-t-il quand j'écrase un fichier sous la même clé ?
Le stockage prend en compte le nouvel objet immédiatement, mais l'edge peut encore conserver la version précédente jusqu'à expiration de son cache. Lancez une purge pour ce chemin depuis le panneau ou avec cdnctl juste après l'upload afin que les visiteurs reçoivent le fichier à jour.
Si une access key fuite, que dois-je faire ?
Révoquez cette paire de clés depuis l'onglet Access Keys et générez-en une nouvelle. Comme vous devriez limiter la portée des clés par bucket ou par application, révoquer une seule paire ne perturbe pas vos autres services. Mettez à jour le binding ou votre gestionnaire de secrets avec la nouvelle secret key.
Dois-je coder mes identifiants en dur dans mon image de container ?
Non, et vous ne devriez pas. Liez le bucket à la Container App et le endpoint, la région, l'access key et la secret key arrivent sous forme de variables d'environnement, éventuellement sous un préfixe. Votre code les lit au runtime, si bien que les secrets restent hors de l'image et du dépôt.
Comment empêcher le stockage de croître sans limite ?
Définissez une limite d'usage sur le bucket afin qu'il ne puisse pas gonfler sans que vous le remarquiez, et pour les buckets de sauvegarde, scriptez un nettoyage de rétention avec cdnctl afin que les vieux dumps soient élagués selon un planning. Le panneau affiche l'usage actuel par bucket afin que vous puissiez le suivre.