Comment exécuter le stockage objet Garage compatible S3 sur du calcul décentralisé
Le stockage objet est partout. Les applications l’utilisent pour stocker des images, des sauvegardes, des documents, des ressources applicatives, des jeux de données et à peu près n’importe quel autre fichier qui doit résider quelque part en dehors de l’application elle-même.
Pour de nombreux développeurs, cela signifie se tourner vers un service de stockage compatible S3 hébergé dans le cloud.
Mais S3 est une interface, pas un lieu. Un stockage compatible S3 implémente la même API qu’Amazon S3 : les applications et outils conçus pour S3 peuvent donc interagir avec lui, où que soit hébergé le stockage sous-jacent. C’est important, car cela permet d’utiliser les outils S3 habituels tout en faisant tourner le stockage lui-même sur une infrastructure décentralisée.
Dans ce guide, vous allez déployer Garage, une solution de stockage objet open source compatible S3, sur le réseau décentralisé de Processors Acurast. Vous configurerez le déploiement, lancerez Garage avec Cargo, vous connecterez à l’endpoint compatible S3 obtenu et téléverserez votre premier fichier.
À la fin, vous disposerez d’une instance de stockage compatible S3 qui tourne sur un Processor Acurast.
Le stockage est aussi une charge de travail de calcul
Quand on pense au calcul décentralisé, le stockage n’est pas forcément la première charge de travail qui vient à l’esprit. Mais un serveur de stockage objet reste, au fond, un logiciel.
Il a besoin d’un environnement d’exécution, d’une connexion réseau, de ressources de calcul et d’un endroit où stocker ses données. Donnez-lui le bon environnement Linux, et il peut tourner à bien des endroits.
C’est là qu’intervient Codename Cargo.
Cargo étend Acurast au-delà de son ancien environnement d’exécution Node.js en permettant des charges de travail complètes basées sur Linux. Les développeurs peuvent déployer des applications écrites en Python, Go, Rust, C++ et d’autres technologies qui tournent sous Linux. Il devient ainsi possible de prendre des logiciels existants et de les faire tourner sur le réseau Acurast sans les reconstruire spécialement pour un environnement d’exécution contraint. Garage en est un bon exemple.
Plutôt que de créer un protocole de stockage sur mesure pour une infrastructure décentralisée, il est possible de déployer un logiciel qui implémente déjà l’API S3 bien connue.
Le résultat : un service de stockage objet avec lequel les outils et applications compatibles S3 existants peuvent communiquer.
Déployer Garage sur Acurast
Le dépôt Acurast Example Apps contient un exemple Garage dont la majeure partie de la configuration sous-jacente est déjà prise en charge. Les scripts de déploiement téléchargent Garage, configurent le service, établissent le tunnel nécessaire et exposent les informations dont vous aurez besoin pour vous connecter.
Il ne reste donc qu’une quantité relativement faible de configuration avant de pouvoir le lancer.
Étape 1 : ouvrir l’application d’exemple Garage
Commencez par récupérer le dépôt Acurast Example Apps.
Accédez au dossier App Cargo Garage.
Vous y trouverez tous les fichiers nécessaires au déploiement. La plupart sont des fichiers d’installation qu’il n’est pas nécessaire de modifier. Ils se chargent de tâches comme le téléchargement du binaire Garage, la préparation de l’environnement et l’établissement du tunnel qui rend le service accessible.
La principale configuration à modifier est le fichier d’environnement.
Étape 2 : configurer le déploiement
La première valeur nécessaire est une phrase mnémonique Acurast. Ce compte sert à autoriser et à payer le déploiement. Par sécurité, n’utilisez pas la phrase mnémonique associée à votre wallet principal. Générez plutôt une phrase mnémonique distincte dédiée aux déploiements et n’y transférez que les fonds nécessaires à la charge de travail. Les identifiants sensibles d’un wallet ne doivent jamais être exposés inutilement dans une configuration locale ou un environnement CLI.
Configurez ensuite l’URL de callback. Lorsqu’Acurast prépare le déploiement, il génère des URL uniques qui vous serviront à accéder à Garage. Ces URL doivent être livrées quelque part. L’exemple s’en charge en envoyant une requête POST à l’URL de callback que vous fournissez. Vous pouvez donc utiliser n’importe quel service capable de recevoir une requête POST et d’en afficher le contenu. Ce tutoriel utilise webhook.watch. Créez un endpoint personnel, copiez son URL et ajoutez-la à la configuration.
Une fois le déploiement prêt, vous verrez les informations du déploiement arriver sur cet endpoint.
Étape 3 : configurer SSH et le réseau
Vous configurerez aussi un mot de passe SSH. L’accès SSH n’est pas nécessaire en fonctionnement normal si tout se passe comme prévu. Il sert surtout de solution de repli si vous devez vous connecter directement au Processor pour le débogage ou le dépannage.
Utilisez un mot de passe sécurisé. Pour le réseau de déploiement, mainnet est l’option recommandée, car il donne accès à un plus grand nombre de Processors disponibles.
Vous verrez aussi un paramètre pour le suffixe de domaine. Au moment de la rédaction de ce tutoriel, vous devez fournir votre propre domaine et configurer les enregistrements DNS appropriés. Ce processus devrait s’automatiser davantage, et l’exigence exacte pourrait donc évoluer avec Cargo.
Enfin, configurez le nom du bucket. Pour un déploiement de base, vous pouvez simplement conserver la valeur par défaut.
Vérifier acurast.json
Avant de déployer, jetez un œil au fichier acurast.json. Il contient des paramètres supplémentaires qui contrôlent la manière dont la charge de travail s’exécute.
L’un des paramètres importants est la durée du déploiement. Dans cet exemple, Garage tourne pendant quatre heures. C’est suffisant pour des tests, mais vous pouvez augmenter la durée selon ce que vous construisez.
Vous pouvez aussi configurer le réseau ici, mais cet exemple reste sur mainnet. Veillez également à cibler la version d’Android requise. Les environnements de Processor plus anciens ne prennent pas forcément en charge toutes les fonctionnalités dont le déploiement Garage a besoin.
Cela fait, vous êtes prêt à lancer le service de stockage.
Lancer Garage
Depuis le dossier d’exemple Garage, exécutez : acurast deploy
La CLI Acurast vous guide tout au long du processus de déploiement. Avant de soumettre le déploiement, les frais associés vous sont présentés. Si les frais configurés sont plus élevés que nécessaire, vous pouvez utiliser la valeur suggérée à la place.
Confirmez le déploiement, et Acurast prend le relais. Le déploiement est enregistré, un Processor est préparé et les services nécessaires démarrent automatiquement.
Au bout de quelques minutes, vous devriez voir des requêtes arriver sur l’endpoint de callback configuré plus tôt.
Vérifier le déploiement
Les requêtes de callback donnent un aperçu utile de ce qui se passe sur le Processor. Vous verrez d’abord des journaux indiquant que l’environnement démarre.
Le Processor installe ensuite le serveur SSH, télécharge Garage et établit le tunnel.
Vous finirez par recevoir les informations attendues : les URL et identifiants générés nécessaires pour accéder au déploiement Garage.
Les journaux confirmeront ensuite que Garage est entièrement déployé et en ligne. Vous disposez désormais d’un service de stockage compatible S3 qui tourne sur un Processor Acurast.
Place à la connexion.
Se connecter à votre stockage compatible S3
Cet exemple utilise une interface simple créée pour démontrer la connexion.
Pour se connecter, quatre informations issues du déploiement sont nécessaires :
- L’URL de l’endpoint générée
- L’ID de la clé d’accès
- La clé d’accès secrète
- Le nom du bucket
Saisissez ces valeurs dans le client et cliquez sur Connect. Le client communique désormais avec l’instance Garage qui tourne sur votre Processor Acurast.
Comme Garage fournit une interface compatible S3, vous n’êtes pas limité à l’interface de démonstration. N’importe quel client S3 compatible peut être configuré pour interagir avec le déploiement à l’aide de l’endpoint et des identifiants appropriés.
Téléverser votre premier fichier
Vérifiez maintenant que le stockage fonctionne vraiment. Choisissez un fichier de test (une image fait très bien l’affaire) et téléversez-le via l’interface.
Une fois le téléversement terminé, le fichier apparaît dans le bucket. De là, vous pouvez récupérer son URL, le partager, le télécharger ou le supprimer. C’est une démonstration simple, mais c’est justement le but. Du point de vue du client, il s’agit d’un stockage objet compatible S3 tout ce qu’il y a de plus classique. Ce qui sort de l’ordinaire, c’est l’endroit où ce stockage tourne.
Au lieu de déployer le service sur une instance cloud traditionnelle, Garage tourne désormais sur un Processor Acurast.
Un seul Processor ne constitue pas une stratégie de sauvegarde
Il y a une limite importante à comprendre avant de considérer cette configuration comme un stockage de production.
Dans cet exemple, vos données résident sur un seul Processor. Si ce Processor devient indisponible, est effacé, ou si le déploiement Acurast expire, les données qui y sont stockées peuvent disparaître définitivement. Pour l’expérimentation, le développement et les tests, c’est parfaitement utile. Pour du stockage de production, ce n’est pas suffisant. Une architecture de production a besoin de redondance. Une approche consisterait à déployer plusieurs instances Garage sur différents Processors et à configurer la réplication entre elles. Ainsi, si un Processor se déconnecte, une autre copie des données reste disponible. Cette distinction est importante, car faire tourner une API compatible S3 et fournir un stockage objet durable sont deux problèmes différents.
L’exemple résout le premier. Une architecture de production doit aussi résoudre le second.
Pour l’avenir, Acurast étudie des solutions qui ne nécessiteraient plus de dépendre d’un seul Processor.
Plus qu’un serveur compatible S3
Garage illustre plus largement ce que Cargo apporte à Acurast. Il ne s’agit pas de créer un nouveau système de stockage spécialement pour le calcul décentralisé. Il s’agit de prendre des logiciels Linux existants et de leur offrir un nouvel endroit où tourner. C’est une distinction importante.
La compatibilité S3 signifie aussi que les applications n’ont pas forcément besoin de comprendre ce qui se passe en dessous. Elles peuvent continuer à interagir avec une API familière pendant que l’infrastructure sous-jacente change.
Et Garage n’est qu’un exemple. La même approche peut s’étendre aux bases de données, aux services backend, aux API, à l’infrastructure pour développeurs, aux serveurs de jeu, aux agents IA et à d’autres charges de travail Linux.
La question n’est plus seulement :
« Que peut-on construire pour une infrastructure décentralisée ? »
C’est de plus en plus :
« Quelle infrastructure existante peut-on y faire tourner ? »
Avec Cargo, cette liste s’allonge considérablement.
Regardez le tutoriel vidéo complet
Ce guide présente les principales étapes pour déployer Garage sur Acurast, mais la vidéo explicative qui l’accompagne montre le processus du début à la fin.
Vous verrez comment configurer l’application d’exemple Garage, la lancer avec la CLI Acurast, suivre les journaux du déploiement, récupérer les identifiants générés, connecter un client compatible S3 et téléverser un fichier.
C’est aussi une démonstration utile de l’idée plus large derrière Cargo : les applications Linux existantes n’ont pas forcément besoin d’une infrastructure cloud traditionnelle pour fonctionner.
Commencez par un bucket compatible S3. Puis voyez ce que vous pouvez migrer d’autre.
