Stockage objet avec MinIO dans un cluster Kubernetes

MinIO est une solution de stockage objet populaire. Souvent recommandé pour sa simplicité d’utilisation et d’installation, MinIO n’est pas seulement qu’un bon moyen pour débuter avec le stockage objet : il propose d’excellentes performances, le rendant adapté à la fois pour les débutants et pour la production.

MinIO implémente l’architecture de donnée du stockage objet ce qui le rend scalable et simple dans son implémentation et ses usages. Toutes les solutions de stockage objet sont fédérées sous le standard ouvert d’interface S3. Cela implique que les solutions de stockage S3 sont compatibles avec les applications utilisant le standard S3.

Notre présentation de l’architecture du stockage objet précise que les solutions de stockage ne sont pas limitées au Cloud : l’hébergement de ces solutions au sein d’un cluster local est possible. Héberger le stockage objet localement est un bon moyen pour en comprendre sa structure et son fonctionnement, que ce soit dans une optique de développement ou de test, ou encore pour déployer MinIO en production.

Cet article couvre l’installation de MinIO et son utilisation dans un cluster Kubernetes local. Il fait partie d’une série de trois articles :

Architecture du stockage objet et attributs du standard S3
Stockage objet avec MinIO dans un cluster Kubernetes
Stockage objet Ceph dans un cluster Kubernetes avec Rook

Dans cette série d’articles, le troisième article donne des indications sur l’hébergement du stockage objet à travers Ceph avec l’opérateur Rook. MinIO est simple d’utilisation et facile à installer. Pour comparer, Ceph est plus modulaire et peut également agir comme un système de fichier ou comme du stockage bloc.

Qu’est-ce que MinIO ?

MinIO est une solution open-source de stockage objet. Cette solution est facile à mettre en place et est compatible avec Kubernetes. Elle fonctionne à la fois sur des clusters de machines physiques et de machines virtuelles.

MinIO est communément déployé dans Kubernetes. Bien qu’il soit possible de l’installer sur la machine hôte, ce n’est pas une pratique usuelle, et de ce fait nous n’aborderons pas ce type de déploiement.

Pour le développement et le test, il est possible d’héberger un serveur autonome MinIO dans un conteneur, en montant les répertoires désirés. Ce serveur est une instance unique de ce que Kubernetes déploie en haute-disponibilité à l’échelle du cluster.

MinIO a deux composants :

Le Serveur MinIO, le cœur du stockage objet et le gestionnaire du stockage de données distribué et des services liés ;
Le Client MinIO, une invite de commandes S3 intégrée pour accéder au stockage et le tester, également compatible avec les autres stockages S3.

Sa compatibilité avec Kubernetes permet à MinIO d’utiliser les volumes persistants (PVs) et les revendications de volumes persistants (PVCs) pour stocker des données.

MinIO se conforme à l’architecture du stockage objet, dans laquelle les données sont divisées logiquement en buckets afin de préserver l’isolation des données. MinIO est déployé dans un cluster Kubernetes avec l’opérateur MinIO. L’opérateur MinIO supporte le principe de multi-tenant. Les tenants correspondent à un niveau de stockage supérieur aux buckets. Ils forment des groupes d’utilisateurs avec leurs propres buckets et leurs propres pods gérant le stockage.

Tout comme AWS et ses kits de développement (SDKs) disponibles avec plusieurs langages de programmation, MinIO offre son propre panel de kits de développement. Utiliser le SDK MinIO simplifie l’accès au stockage objet MinIO local. Il abstrait la complexité de configuration et de dépendances associée à l’utilisation des kits de développement AWS.

Le stockage objet avec MinIO dans un cluster Kubernetes

Comme indiqué précédemment, le serveur MinIO peut être déployé comme un conteneur autonome. Pour les installations avancées sur des machines physiques, il existe un répertoire principal de ressources, tandis qu’un répertoire séparé est dédié à l’opérateur Kubernetes MinIO pour le déploiement en cluster. Ce dernier permet d’obtenir aisément une instance MinIO distribuée, prête à l’emploi dans un cadre de développement ou de production, permettant un déploiement rapide et pratique pour ce tutoriel. L’opérateur automatise le déploiement de MinIO au sein du cluster et gère lui-même la configuration par défaut, comme la gestion des certificats.

Ce tutoriel nécessite :

Un cluster Kubernetes avec un plugin Container Network Interface (CNI) installé (par exemple, Calico) ;
Au moins 3 nœud travailleurs avec 3 GB de RAM ;
Des disques non formatés sur les nœuds travailleurs ou des partitions non formatées au sein de ces disques. Ils peuvent être physiques sur un cluster bare-metal ou virtuels sous des machines virtuelles.

Ce dépôt GitHub fournit un template permettant d’obtenir facilement un cluster répondant aux exigences de ce tutoriel.

Si vous souhaitez apprendre comment ajouter des disques virtuels sur un cluster Vagrant utilisant VirtualBox, cet article indique comment procéder.

Note : Pour un cluster en production, séparer les nœuds travailleurs des nœuds de stockage objet est une bonne pratique.

Avant de commencer l’installation

Premièrement, nous allons créer un namespace réservé à MinIO tenant. Les tenants sont les clients du stockage objet MinIO. Chaque namespace ne peut contenir plus d’un tenant.

kubectl create namespace minio-tenant-1

Ensuite, installons Krew. Krew est un installateur de plugin kubectl, qui permet d’installer les composants de MinIO. Nous pouvons l’installer comme suit :

# Installation de Krew
(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)
# Ajout de Krew au PATH
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
# Vérification de l'installation de Krew par mise à jour de l'index
kubectl krew update

Préparation des disques pour MinIO avec DirectPV

Avant d’initialiser l’opérateur MinIO, nous avons un prérequis à satisfaire. Comme mentionné précédemment, MinIO utilise les volumes persistants (PVs), qui doivent absolument être disponibles pour que MinIO crée ses revendications de volumes persistants dédiées. Le driver DirectPV de MinIO automatise le processus en détectant, formatant et montant les disques du cluster.

Installons le plugin DirectPV avec Krew, puis installons le driver lui-même :

kubectl krew install directpv
kubectl directpv install

Dans ce tutoriel, les disques sont sur les nœuds travailleurs. Cependant, dans un cluster en production utilisant le stockage objet, c’est une bonne pratique de séparer les nœuds travailleurs des nœuds dédiés au stockage. Cela se traduit par des taints sur les nœuds de stockage. Des tolérations de taints permettent ensuite à l’installation de DirectPV d’être autorisée pour ces nœuds.

Après avoir attendu que DirectPV soit initialisé, vérifions les disques détectés. Parmi les résultats, les disques dédiés au stockage apparaissent. Si vous souhaitez consulter les disques non-disponibles ou unavailable, l’option --all existe :

kubectl directpv drives ls

# DRIVE      CAPACITY  ALLOCATED  FILESYSTEM  VOLUMES  NODE            ACCESS-TIER  STATUS
# /dev/sda   20 GiB    -          -           -        demo-worker-01  -            Available
# /dev/sdb   20 GiB    -          -           -        demo-worker-01  -            Available
# /dev/sda   20 GiB    -          -           -        demo-worker-02  -            Available
# /dev/sdb   20 GiB    -          -           -        demo-worker-02  -            Available
# /dev/sda   20 GiB    -          -           -        demo-worker-03  -            Available
# /dev/sdb   20 GiB    -          -           -        demo-worker-03  -            Available

Les disques sans filesystem, disponibles pour le stockage objet, sont affichés sur cette liste.

Maintenant, sélectionnons les disques qui doivent être gérés et formatés par DirectPV. Ici, nous utilisons l’opérateur sd{a..f} afin de sélectionner tous les disques de sda à sdf pour les nœuds travailleurs nommés demo-worker-0{1...3}, allant de 1 à 3 :

# Modifiez la valeur des options en fonction de votre installation
kubectl directpv drives format --drives /dev/sd{a...f} --nodes demo-worker-0{1...3}

# Vérifions le succès du formatage
kubectl directpv drives ls

# DRIVE      CAPACITY  ALLOCATED  FILESYSTEM  VOLUMES  NODE            ACCESS-TIER  STATUS
# /dev/sda   20 GiB    -          xfs         -        demo-worker-01  -            Ready
# /dev/sdb   20 GiB    -          xfs         -        demo-worker-01  -            Ready
# /dev/sda   20 GiB    -          xfs         -        demo-worker-02  -            Ready
# /dev/sdb   20 GiB    -          xfs         -        demo-worker-02  -            Ready
# /dev/sda   20 GiB    -          xfs         -        demo-worker-03  -            Ready
# /dev/sdb   20 GiB    -          xfs         -        demo-worker-03  -            Ready

Les disques du cluster sont maintenant configurés pour utiliser automatiquement les PVs et les PVCs avec MinIO.

Installer l’opérateur MinIO

Il existe deux manières pour installer l’opérateur MinIO :

En utilisant Krew et le plugin minio
En utilisant Helm et en déployant la charte Helm de l’opérateur MinIO, nous permettant de configurer automatiquement l’opérateur MinIO et le tenant depuis des fichiers de configuration YAML

Les deux installations se valent : leur résultat final est identique.

Krew est déjà installé, puisque nous l’avons utilisé précédemment pour l’installation de DirectPV. C’est une installation pratique pour comprendre les mécanismes qui régissent MinIO. Le processus se décompose en plusieurs commandes.

Helm permet également d’installer l’opérateur MinIO. Seules deux commandes sont nécessaires au déploiement de l’opérateur et du tenant. En suivant la philosophie de Helm, cette installation permet une configuration déclarative et automatisée.

Opérateur MinIO avec Krew

Poursuivons l’installation du plugin Krew minio et initialisons l’opérateur :

kubectl krew install minio
kubectl minio init

Attendons jusqu’à ce que les pods de l’opérateur soient en route (Running) et vérifions que ce soit le cas avec kubectl get pods -n minio-operator.

Avec l’opérateur en route, un tenant doit maintenant être créé. Cette création est possible soit avec la console MinIO comme montré ici, soit au travers de l’invite de commandes. La console MinIO est accessible temporairement en faisant un suivi de ports de la machine hôte au pod de la console. Ouvrez un terminal séparé connecté au nœud maître et exécutez la commande suivante, suivant le port jusqu’à interruption :

kubectl minio proxy -n minio-operator

# Suivi de port pour la console

# Connectez vous au navigateur à l'adresse http://localhost:9090

# JWT pour s'authentifier : <JTW_TOKEN>

Ouvrons un navigateur web. L’adresse pour se connecter à la console change si :

il n’y a pas de contrôleur Ingress dans votre cluster, dans ce cas faites usage de l’IP du control-plane plutôt que de localhost, par exemple : http://192.168.56.10:9090 pour le cluster fourni dans les prérequis ;
un contrôleur Ingress existe dans le cluster, faisant que l’utilisation du proxy n’est pas possible sans configuration supplémentaire. Afin de gérer les Ingress avec MinIO, il est recommandé d’installer l’opérateur MinIO avec la charte Helm et d’activer l’Ingress dans le fichier values.yaml.

Une fois l’accès à la console de l’opérateur établi, utilisons le jeton JWT pour s’authentifier.

Si un écran blanc se présente après cette étape, cela signifie que le navigateur ne peut pas faire confiance à l’autorité fournissant les certificats TLS. Changer de navigateur web aide à résoudre ce problème. Pour plus ample assistance, suivez ces instructions.

Après authentification, cliquons sur le bouton en haut à droite Create Tenant. Une page de configuration s’ouvre alors.

Les champs configurables sont documentés sur le paramètrage du tenant MinIO. Pour notre test, nous allons remplir les champs comme suit, avec la total size paramétrée avec une valeur correspondant à la capacité totale des disques formatés précédemment :

Name : tenant-1 ;
Namespace : minio-tenant-1 ;
Storage Class : directpv-min-io ;
Number of Servers : 3 ;
Drives per Server : 2 ;
Total Size : 60 Gi.

Il est également utile pour ce tutoriel de désactiver le TLS dans la fenêtre Security, ce qui permettra par la suite d’utiliser le Client MinIO sans gérer les certificats.

Après la création, nous récupérons les identifiants S3. Notons-les ou sauvegardons-les sur notre ordinateur temporairement pour les réutiliser durant les tests.

MinIO essaye alors de déployer les pods du tenant. Nous pouvons vérifier leur status dans l’onglet Pods de la console de l’opérateur, ou avec kubectl get pods -n minio-tenant-1. Quand le stockage object est prêt, le voyant à côté du statut du tenant est vert sur la console.

Si ces pods n’arrivent pas à être créés, la console de l’opérateur propose des outils de surveillance pour mêner l’enquête. L’onglet Events indique tous les évènements sur le namespace du tenant. Dans l’onglet Pods, cliquer sur un pod donne l’accès à son onglet Logs correspondant.

Opérateur MinIO avec la charte Helm

Cette partie couvre les étapes servant à une installation alternative et plus avancée. Sautez jusqu’au test de l’instance de stockage objet si cette installation n’est pas nécessaire dans votre cas.

Krew suit une approche étape-par-étape pour installer MinIO et créer un tenant. Or, l’automatisation de la configuration de manière déclarative vient par la suite remplacer l’accès manuel à la console de l’opérateur. C’est là où l’intérêt de la charte Helm de l’opérateur MinIO et de la charte Helm du tenant MinIO est mis en évidence.

Helm gère le déploiement d’applications Kubernetes et leur configuration. Ces déploiements, appelés chartes ou “charts” en anglais, sont souvent accompagnés de fichiers de configuration YAML. Utiliser ces manifestes pour la configuration permet une installation déclarative et flexible.

Pour débuter l’installation, installons Helm :

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
sudo chmod 0700 get_helm.sh
./get_helm.sh

Par la suite, téléchargeons le fichier values pour l’opérateur et optionellement, le fichier values pour le tenant :

curl -fsSL -o operator-values.yaml https://raw.githubusercontent.com/minio/operator/master/helm/operator/values.yaml
curl -fsSL -o tenant-values.yaml https://raw.githubusercontent.com/minio/operator/master/helm/tenant/values.yaml

Dans ce cas, l’opérateur MinIO et le tenant sont configurés grâce à leur fichier values respectif. Commencer avec les valeurs par défaut est recommandé. Changeons les valeurs des manifestes comme indiqué plus haut avec un éditeur de texte tel que nano : nano operator-values.yaml et nano tenant-values.yaml.

Les champs les plus importants pour la configuration de MinIO se trouvent dans le fichier values du tenant :

tenant.pools.servers permet de contrôler le nombre de pods qui hébergent les instances serveur de MinIO. Comme ce tutoriel est fait pour 3 nœuds, la valeur appropriée est 3 ;
tenant.pools.volumesPerServer doit correspondre au nombre de disques par nœud. Le nombre final de volumes de stockage objet est le nombre de volumes par serveur multiplié par le nombre de serveurs. Il est bon de noter que des volumes supplémentaires apparaissent lorsque les logs ou les métriques sont activés ;
tenant.pools.storageClassName doit valoir directpv-min-io pour que MinIO utilise les volumes de DirectPV ;
Attribuer false à tenant.certificate.requestAutoCert désactive le TLS pour MinIO pour ce tutoriel, permettant au Client MinIO de se connecter au stockage objet sans certificats.

Les deux champs suivants sont optionnels :

tenant.pools.tolerations permet à MinIO d’ignorer les taints lors de l’utilisation de nœuds dédiés au stockage ;
tenant.ingress.api.enabled et tenant.ingress.console.enabled nécessitent d’être mis à true si vous utilisez un contrôleur ingress au sein du cluster. Entrez le paramètre ingressClassName en fonction de la classe de votre contrôleur Ingress, et remplissez les champs host avec les noms de domaine que vous souhaitez exposer comme minio.example.com et minio-console.example.com respectivement.

Les valeurs de l’opérateur sont plus succintes : seuls les champs ingress et toleration sont à modifier si votre cluster les nécessitent.

Il est bon de noter qu’il n’est pas obligatoire d’installer le tenant avec Helm. Il est possible de le créer manuellement à travers la console de l’opérateur sur votre navigateur comme lors de la partie précédente. Cependant, l’installation fournie par Helm incorpore chaque composant et inclut la création d’Ingress associé à chaque service MinIO.

Une fois la configuration voulue paramétrée dans les fichiers de valeurs, installons les charts de l’opérateur et du tenant :

helm repo add minio https://operator.min.io/
helm upgrade --install --namespace minio-operator --create-namespace minio-operator minio/operator --values operator-values.yaml
helm upgrade --install --namespace minio-tenant-1 --create-namespace minio-tenant-1 minio/tenant --values tenant-values.yaml

L’accès temporaire à la console de l’opérateur MinIO depuis l’ordinateur hôte est établi avec la commande suivante :

kubectl port-forward --address 0.0.0.0 -n minio-operator service/console 9090:9090

Accédez à l’adresse du plan de contrôle Kubernetes au port 9090 depuis un navigateur web pour accéder à la console. Pour le cluster de demo fourni, l’adresse correcte est http://192.168.56.10:9090. Le JWT pour s’authentifier est obtenu grâce à la commande suivante depuis un autre terminal :

kubectl -n minio-operator  get secret console-sa-secret -o jsonpath="{.data.token}" | base64 --decode

Test de l’instance de stockage objet

Le tenant étant actif et en bonne santé (indiquée par le point vert dans la console de l’opérateur), il est dorénavant possible de tester notre instance de stockage objet S3 depuis la console de l’opérateur. Depuis la liste des tenants, cliquons sur le tenant puis cliquons sur le bouton Console en haut à droite, qui nous redirige directement vers la console de gestion du tenant.

Ce tenant est vide, nous devons créer un bucket, e.g my-bucket. Envoyons un fichier d’example grâce au bouton Upload en haut à droite. Une fois que le fichier est envoyé, il apparaît comme suit :

Cliquer sur le fichier nous permet de le télécharger, afin de s’assurer que l’hébergement du stockage objet fonctionne bel et bien !

L’accès au bucket est accordé librement par la console de l’opérateur, il est également fourni à travers les identifiants S3 générés lors de la création du tenant.

Utiliser le client MinIO pour accéder au stockage objet

Le serveur MinIO permettant le stockage objet est maintenant établi, y accéder sans passer par la console MinIO est faisable en passant par la programmation avec les kits de développement tels que le MinIO JavaScript SDK sur npm, ou à travers les invites de commandes S3 comme le client MinIO, mc.

Les actions autorisées pour les utilisateurs du stockage objet sont définies par des politiques ou “policies” en anglais, comme MinIO utilise un gestionnaire d’accès basé sur la politique ou “Policy-Based Access Control” (PBAC). Ces politiques concernent un large spectre d’actions, de readonly à consoleAdmin, et sont paramétrés soit depuis la console MinIO, soit depuis la commande mc admin policy du client MinIO.

Installons mc :

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc

Ensuite :

Récupèrons la clé d’accès S3 et la clé secrète. Elles sont requises afin de se connecter à n’importe quel stockage S3. Lors de l’installation avec Krew, ceux-ci ont été sauvegardés précédemment. Sinon, générer de nouveaux identifiants est expliqué plus bas ;
Le point d’accès S3 est également requis. Les configurations avec des Ingress et des load-balancers l’affichent dans l’onglet Summary du tenant. Sinon, le point d’accès doit être port-forwardé pour être accessible dans la VM utilisant mc. Comme le port-forward bloque le terminal, exécutons cette commande dans une autre fenêtre connectée au nœud maître :

kubectl port-forward -n minio-tenant-1 service/minio 8080:80

Le point d’accès en résultant est http://127.0.0.1:8080

Si vous souhaitez utiliser différents identifiants, ou si la création du tenant ne les a pas généré, il est possible de créer une nouvelle clé d’accès et secret S3 depuis la console du tenant. Pour ce faire :

Dans la console de l’opérateur, accédez au tenant, puis à la console associée en cliquant sur le bouton Console en haut à droite, étendez l’onglet Identity et naviguez vers les Users ;
Cliquez sur Create User et fournissez le nom et le mot de passe qui fonctionne comme une paire de clé d’accès / clé secrète ;
Activez la politique readwrite pour cet utilisateur.

La commande suivante crée un alias sur la configuration S3 dans mc :

./mc alias set my-minio-server <MINIO-ENDPOINT> <ACCESS-KEY> <SECRET-KEY>

mc donne accès à différentes commandes afin d’effectuer des actions communes sur les fichiers telles que ls, cp, mv, et possède également des fonctionnalités spécifiques telles que créer des buckets ou effectuer des requêtes SQL sur des objets. Pour obtenir la liste complète de ces commandes, l’option -h est accessible : ./mc -h.

Mettre un fichier dans MinIO (ou dans n’importe quel autre stockage objet S3) se fait au travers de la commande cp, retrouvable sur la majorité des clients S3. Créons un bucket de test, mettons un fichier texte d’example dans le stockage S3 et récupèrons-le de manière à illustrer notre propos à travers son usage :

echo Hello, S3 Storage > /tmp/test-file.txt
./mc mb my-minio-server/test-bucket
./mc cp /tmp/test-file.txt my-minio-server/test-bucket
./mc cp my-minio-server/test-bucket/test-file.txt /tmp/test-file-from-s3.txt
cat /tmp/test-file-from-s3.txt
# Hello, S3 Storage

La commande mc cp supporte les globs.

Il est bon de noter que le fichier test-file.txt existe dorénavant dans le stockage objet et est accessible depuis la console MinIO dans le nouveau bucket.

Nœuds de stockage dédiés

Dans l’installation que nous fournissons, les nœuds travailleurs s’occupent des périphériques de stockage, mais il est possible d’utiliser les taints et tolerations de Kubernetes afin d’utiliser des nœuds de stockage dédiés. Les taints empêchent les opérations externes au stockage d’avoir lieu sur ces nœuds ayant moins de RAM ; les tolérations donnent à MinIO l’autorisation d’utiliser ces nœuds pour le stockage de données.

Si ce type d’installation est désiré, appliquer ces tolérations est nécessaire dans l’installation de DirectPV :

kubectl directpv install --node-selector 'storage-node=true' --tolerations 'storage-node=true:NoSchedule'

Les tolérations doivent aussi être renseignées lors de la création d’un tenant MinIO, dans l’onglet Pod Placement de la console de l’opérateur. Dans le cadre de l’installation par Helm, ces tolérations sont à spécifier dans un champ du fichier de valeurs de la charte Helm de l’opérateur.

Pourquoi MinIO plutôt Ceph ?

Ceph est une autre solution de stockage proposant trois architectures de données, proposant du stockage objet aux côtés de systèmes de fichier et du stockage bloc. Nous couvrons ses composants et son installation dans le prochain article de la série. Voici la comparaison de leurs points clés :

Avantages :

MinIO est plus simple à déployer dans un cluster que Ceph, même si Rook aide grandement à simplifier ce processus ;
MinIO a plus d’outils à sa disposition pour rendre la consommation d’objets S3 aisée, avec les kits de développement dédiés à MinIO et un client MinIO compatible avec n’importe quelle solution de stockage objet.

Inconvénients :

Au niveau de la documentation, celle de MinIO n’est pas aussi claire que celle de Ceph ou de Rook, avec de nombreux détails manquants et une possible confusion générale ;
La console de l’opérateur MinIO n’est pas parfaite et souffre de quelques bugs.

Conclusion

Le stockage objet est une architecture de données adaptée aux scénarios du Big Data, et déployer une solution locale de stockage objet permet de comprendre son fonctionnement et son utilisation avec des applications utilisant ces données.

MinIO offre les avantages d’être déployable rapidement et d’être configuré avec une relative aisance pour une installation basique, tout en permettant d’avoir des paramètres de configuration avancés pour des scénarios en production ou pour l’intégration à d’autres services. Étant une solution de stockage objet compatible S3, elle est compatible avec tous les clients S3.

Nous avons couvert l’utilisation du client MinIO mc pour accéder au stockage objet, et l’utilisation d’autres invites de commandes S3 n’en diffère pas significativement. Pour l’utiliser dans vos programmes, les SDKs AWS ou MinIO sont des kits de développement nécessitant une configuration minime pour fonctionner avec votre stockage objet local.

Des configurations plus complexes pour le stockage objet avec MinIO permettent la réplication de données à travers de multiples buckets. Les étapes permettant cette configuration sont données dans la documentation officielle.

Partagez cet article