From c74547b95aa2907c4f8801e276d9093bbb069148 Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Wed, 14 Oct 2026 04:27:08 +0000 Subject: [PATCH] docs: repair non-native French wording in content/fr Correct mistranslations, terminology, agreement, and French typography on translated pages, and finish mixed English/French pages. Leave fully English locale pages and other languages unchanged. Co-authored-by: RustFS --- content/fr/administration/data/s3-tables.md | 46 ++--- content/fr/administration/index.md | 18 +- content/fr/administration/protocols/swift.md | 24 +-- content/fr/developer/integration/ai/index.md | 6 +- .../fr/developer/integration/backup/restic.md | 30 +-- .../developer/integration/big-data/flink.md | 52 ++--- .../developer/integration/big-data/iceberg.md | 94 ++++----- .../developer/integration/big-data/index.md | 8 +- .../developer/integration/big-data/meta.json | 2 +- .../integration/big-data/pyiceberg.md | 22 +-- .../developer/integration/big-data/spark.md | 50 ++--- .../developer/integration/database/duckdb.md | 68 +++---- .../integration/database/influxdb.md | 72 +++---- .../developer/integration/database/trino.md | 62 +++--- .../fr/developer/integration/devops/index.md | 6 +- content/fr/developer/integration/index.md | 26 +-- content/fr/developer/integration/meta.json | 2 +- .../integration/observability/index.md | 6 +- .../integration/observability/loki.md | 66 +++---- .../integration/observability/openobserve.md | 96 ++++----- .../integration/observability/tempo.md | 60 +++--- .../fr/developer/integration/others/capo.md | 20 +- .../fr/developer/integration/others/index.md | 12 +- .../developer/integration/registry/harbor.md | 72 +++---- .../developer/integration/registry/index.md | 8 +- content/fr/index.mdx | 2 +- .../linux/prerequisites-and-service.md | 182 +++++++++--------- content/fr/reference/s3-compatibility.md | 10 +- .../fr/security-compliance/iam/policies.md | 136 ++++++------- .../fr/security-compliance/oidc/keycloak.md | 144 +++++++------- 30 files changed, 701 insertions(+), 701 deletions(-) diff --git a/content/fr/administration/data/s3-tables.md b/content/fr/administration/data/s3-tables.md index b0fdc2a18..345ac3c25 100644 --- a/content/fr/administration/data/s3-tables.md +++ b/content/fr/administration/data/s3-tables.md @@ -5,11 +5,11 @@ description: "Activez un compartiment de tables RustFS et connectez des clients RustFS S3 Tables gère les tables **Apache Iceberg** au moyen d’un catalogue REST intégré. Les données des tables, les manifestes et les métadonnées Iceberg restent stockés sous forme d’objets S3 dans RustFS. Ce guide explique comment activer un compartiment de tables dédié, connecter les clients et prendre en compte les autorisations et les limites de maintenance. -:::note[Préversion et versions concernées] +:::note[Préversion (preview) et versions concernées] -S3 Tables est une fonctionnalité en préversion ; la compatibilité des clients se limite aux workflows indiqués ci-dessous. Cette page s’appuie sur le commit RustFS [`7e0c6711`](https://github.com/rustfs/rustfs/commit/7e0c67111b97703d47e23719b0264a739c8acea8), vérifié le 8 septembre 2026. Consultez la [matrice de prise en charge](https://github.com/rustfs/rustfs/blob/7e0c67111b97703d47e23719b0264a739c8acea8/docs/architecture/s3-tables-support-matrix.md) et votre version avant d’utiliser d’autres opérations de catalogue ou clients. +S3 Tables est une fonctionnalité en préversion (preview) ; la compatibilité des clients se limite aux workflows indiqués ci-dessous. Cette page s’appuie sur le commit RustFS [`7e0c6711`](https://github.com/rustfs/rustfs/commit/7e0c67111b97703d47e23719b0264a739c8acea8), vérifié le 8 septembre 2026. Consultez la [matrice de prise en charge](https://github.com/rustfs/rustfs/blob/7e0c67111b97703d47e23719b0264a739c8acea8/docs/architecture/s3-tables-support-matrix.md) et votre version avant d’utiliser d’autres opérations de catalogue ou clients. -::: +:: : ## Fonctionnement @@ -24,11 +24,11 @@ flowchart TB | Ressource | Rôle | | --- | --- | -| Compartiment de tables | Un compartiment S3 existant activé pour le catalogue ; son nom correspond au paramètre `warehouse` du client. | +| Compartiment de tables | Un compartiment S3 existant activé pour le catalogue ; son nom correspond au paramètre `warehouse` du client. | | Espace de noms | Un groupe logique de tables au sein de cet entrepôt. | | Table | Un schéma Iceberg, des instantanés et un emplacement courant des métadonnées géré par le catalogue. | -L’activation d’un compartiment de tables n’enregistre pas automatiquement les fichiers Parquet existants comme tables Iceberg. Créez ou enregistrez les tables avec un client Iceberg. Sans `location` explicite, RustFS attribue un emplacement de stockage ; un emplacement personnalisé doit se trouver dans le même compartiment. Les clients devraient utiliser l’emplacement renvoyé. +L’activation d’un compartiment de tables n’enregistre pas automatiquement les fichiers Parquet existants comme tables Iceberg. Créez ou enregistrez les tables avec un client Iceberg. Sans `location` explicite, RustFS attribue un emplacement de stockage ; un emplacement personnalisé doit se trouver dans le même compartiment. Les clients devraient utiliser l’emplacement renvoyé. Le backend de catalogue par défaut, `object`, conserve durablement l’état du catalogue dans le stockage objet RustFS. Un commit de table vérifie les métadonnées de départ et les objets référencés avant de mettre à jour, sous condition, le pointeur vers les métadonnées courantes. En cas de conflit d’écriture, le client doit recharger la table et résoudre le conflit. La transaction porte sur une seule table. @@ -37,7 +37,7 @@ Le backend de catalogue par défaut, `object`, conserve durablement l’état du - Démarrez un déploiement RustFS disposant des points de terminaison S3 Tables décrits ci-dessus. Consultez [Installation](/installation). - Installez l’[AWS CLI](/developer/examples/aws-cli) et `curl` 7.76 ou une version ultérieure, avec prise en charge de `--aws-sigv4` et `--fail-with-body`. - Créez un compartiment dédié à ce tutoriel. L’exemple utilise `my-bucket`. -- Utilisez un compte d’administration existant autorisé à effectuer les opérations de catalogue et à accéder aux objets S3. La politique intégrée `consoleAdmin` couvre ce tutoriel ; configurez des politiques plus restreintes pour les applications. +- Utilisez un compte d’administration existant autorisé à effectuer les opérations de catalogue et à accéder aux objets S3. La politique intégrée `consoleAdmin` couvre ce tutoriel ; configurez des politiques plus restreintes pour les applications. Les exemples utilisent `http://localhost:9000`. Remplacez cette adresse par le point de terminaison de votre serveur et utilisez [TLS](/integration/tls-configured) avec vérification des certificats en dehors d’un environnement de test local. @@ -45,11 +45,11 @@ Les exemples utilisent `http://localhost:9000`. Remplacez cette adresse par le p Les compartiments de tables sont exclus du traitement d’expiration habituel du cycle de vie des compartiments. Activer ce mode sur un compartiment existant modifie l’application de ses règles d’expiration. Utilisez une maintenance de catalogue qui tient compte des références Iceberg pour faire expirer les instantanés et nettoyer les fichiers des tables. -::: +:: : ## 1. Créer un compartiment -Définissez le point de terminaison et les informations d’identification des clients d’exemple : +Définissez le point de terminaison et les identifiants des clients d’exemple : ```bash export RUSTFS_ENDPOINT="http://localhost:9000" @@ -58,7 +58,7 @@ export AWS_SECRET_ACCESS_KEY="" export AWS_DEFAULT_REGION="us-east-1" ``` -Créez le compartiment dédié : +Créez le compartiment dédié : ```bash aws --endpoint-url "$RUSTFS_ENDPOINT" s3api create-bucket --bucket my-bucket @@ -68,7 +68,7 @@ Ces exemples utilisent une clé d’accès et une clé d’accès secrète, sans ## 2. Activer le compartiment de tables -Envoyez une requête au corps vide, signée avec SigV4, au point de terminaison du compartiment de tables : +Envoyez une requête au corps vide, signée avec SigV4, au point de terminaison du compartiment de tables : ```bash curl --fail-with-body --silent --show-error \ @@ -78,7 +78,7 @@ curl --fail-with-body --silent --show-error \ --request PUT "$RUSTFS_ENDPOINT/iceberg/v1/buckets/my-bucket" ``` -Relisez son état avec les mêmes informations d’identification : +Relisez son état avec les mêmes identifiants : ```bash curl --fail-with-body --silent --show-error \ @@ -88,7 +88,7 @@ curl --fail-with-body --silent --show-error \ "$RUSTFS_ENDPOINT/iceberg/v1/buckets/my-bucket" ``` -Les deux requêtes renvoient HTTP `200` en cas de réussite. Vérifiez que la réponse contient les valeurs suivantes : +Les deux requêtes renvoient HTTP `200` en cas de réussite. Vérifiez que la réponse contient les valeurs suivantes : ```json { @@ -100,11 +100,11 @@ Les deux requêtes renvoient HTTP `200` en cas de réussite. Vérifiez que la r } ``` -Il s’agit d’un extrait de réponse. La valeur `catalog-uri` renvoyée est une route propre au compartiment ; utilisez l’URI de base de la section suivante pour configurer un client REST Iceberg. +Il s’agit d’un extrait de réponse. La valeur `catalog-uri` renvoyée est une route propre au compartiment ; utilisez l’URI de base de la section suivante pour configurer un client REST Iceberg. ## 3. Connecter un client Iceberg -Utilisez les paramètres suivants pour le point de terminaison RustFS de l’exemple : +Utilisez les paramètres suivants pour le point de terminaison RustFS de l’exemple : | Paramètre | Valeur | | --- | --- | @@ -118,32 +118,32 @@ Le client ajoute `/v1` à l’URI du catalogue. L’entrepôt est un nom de comp Si vous exploitez déjà un catalogue REST Iceberg séparé, consultez l’[intégration Apache Iceberg](/developer/integration/big-data/iceberg) pour le modèle de déploiement avec catalogue externe. -## Autorisations et informations d’identification +## Autorisations et identifiants -L’activation d’un compartiment de tables nécessite `admin:SetTableBucket` ; la consultation de son état nécessite `admin:GetTableBucket`. La découverte du catalogue utilise `admin:GetTableCatalog`. Les opérations sur les espaces de noms et les tables possèdent leurs propres actions d’administration RustFS, notamment `admin:SetTableNamespace`, `admin:CreateTable`, `admin:GetTableMetadata` et `admin:CommitTable`. +L’activation d’un compartiment de tables nécessite `admin:SetTableBucket` ; la consultation de son état nécessite `admin:GetTableBucket`. La découverte du catalogue utilise `admin:GetTableCatalog`. Les opérations sur les espaces de noms et les tables possèdent leurs propres actions d’administration RustFS, notamment `admin:SetTableNamespace`, `admin:CreateTable`, `admin:GetTableMetadata` et `admin:CommitTable`. -La lecture et l’écriture des fichiers de tables nécessitent aussi les autorisations S3 ordinaires. RustFS vérifie les autorisations de table sur les chemins des objets de l’entrepôt : les lectures nécessitent l’autorisation `admin:GetTableMetadata` correspondante, et les écritures `admin:SetTableMetadata`. Une autorisation de commit de catalogue ne suffit pas à autoriser les écritures de fichiers S3 qui le précèdent. Configurez les [politiques IAM](/security-compliance/iam/policies) pour les deux interfaces. +La lecture et l’écriture des fichiers de tables nécessitent aussi les autorisations S3 ordinaires. RustFS vérifie les autorisations de table sur les chemins des objets de l’entrepôt : les lectures nécessitent l’autorisation `admin:GetTableMetadata` correspondante, et les écritures `admin:SetTableMetadata`. Une autorisation de commit de catalogue ne suffit pas à autoriser les écritures de fichiers S3 qui le précèdent. Configurez les [politiques IAM](/security-compliance/iam/policies) pour les deux interfaces. -La fourniture d’informations d’identification par le catalogue est désactivée par défaut. Lorsqu’elle est activée, un client compatible doit négocier `X-Iceberg-Access-Delegation: vended-credentials`, et l’appelant doit être autorisé à demander des informations d’identification de table. L’accès initial au catalogue nécessite toujours une identité autorisée. Le tutoriel PyIceberg associé utilise des informations d’identification configurées explicitement. +La délégation d’identifiants (vended credentials) par le catalogue est désactivée par défaut. Lorsqu’elle est activée, un client compatible doit négocier `X-Iceberg-Access-Delegation: vended-credentials`, et l’appelant doit être autorisé à demander des identifiants de table. L’accès initial au catalogue nécessite toujours une identité autorisée. Le tutoriel PyIceberg associé utilise des identifiants configurés explicitement. ## Maintenance et protection des données -La suppression des métadonnées et la maintenance en arrière-plan sont désactivées par défaut. RustFS expose des opérations explicites de planification, d’exécution de l’ordonnanceur et d’exécution des workers ; il n’exécute pas d’ordonnanceur intégré de maintenance périodique. Examinez le plan de maintenance et les références qu’il conserve avant d’activer la suppression. +La suppression des métadonnées et la maintenance en arrière-plan sont désactivées par défaut. RustFS expose des opérations explicites de planification, d’exécution de l’ordonnanceur et d’exécution des workers ; il n’exécute pas d’ordonnanceur intégré de maintenance périodique. Examinez le plan de maintenance et les références qu’il conserve avant d’activer la suppression. -Supprimer une table retire son entrée du catalogue tout en conservant les objets sous-jacents. Effectuez les opérations de maintenance nécessaires avant de retirer la table du catalogue ; ensuite, elles ne pourront plus la trouver. Le nettoyage des objets conservés exige un plan distinct tenant compte de toutes les références restantes. Ne supprimez pas récursivement des chemins S3 que des instantanés ou d’autres métadonnées pourraient encore référencer. +Supprimer une table retire son entrée du catalogue tout en conservant les objets sous-jacents. Effectuez les opérations de maintenance nécessaires avant de retirer la table du catalogue ; ensuite, elles ne pourront plus la trouver. Le nettoyage des objets conservés exige un plan distinct tenant compte de toutes les références restantes. Ne supprimez pas récursivement des chemins S3 que des instantanés ou d’autres métadonnées pourraient encore référencer. Conservez le backend de catalogue par défaut pour ce tutoriel. Le passage d’un déploiement existant à `durable-strong` nécessite la [procédure de bascule du catalogue](https://github.com/rustfs/rustfs/blob/7e0c67111b97703d47e23719b0264a739c8acea8/docs/operations/s3-tables-cutover-runbook.md), notamment les vérifications préalables à la migration et le blocage coordonné des clients en écriture. ## Compatibilité des clients et limites -Le dépôt source maintient le périmètre de validation suivant : +Le dépôt source maintient le périmètre de validation suivant : | Client | Périmètre de validation | | --- | --- | | PyIceberg | Vérifications automatisées de création, d’ajout, de rechargement, de lecture des lignes et d’opérations de catalogue. | | DuckDB Iceberg 1.5.5 | Vérifications automatisées du catalogue REST générique pour la lecture, l’écriture et les modifications de schéma sur une seule table. | -| Spark | Un banc de test sur service actif, à activer explicitement ; validez les versions exactes de Spark et d’Iceberg que vous déployez. | -| Trino | Un test manuel en lecture seule ; la compatibilité en écriture n’est pas revendiquée. | +| Spark | Un banc de test sur service actif, à activer explicitement ; validez les versions exactes de Spark et d’Iceberg que vous déployez. | +| Trino | Un test manuel en lecture seule ; la compatibilité en écriture n’est pas revendiquée. | Les formats Iceberg v1 et v2 sont pris en charge, avec v2 par défaut. La création de tables en mode différé, la purge lors de la suppression et le format Iceberg v3 ne sont pas pris en charge. diff --git a/content/fr/administration/index.md b/content/fr/administration/index.md index 83121bd2f..6aa81a6c9 100644 --- a/content/fr/administration/index.md +++ b/content/fr/administration/index.md @@ -1,17 +1,17 @@ --- title: "Administration" -description: "Administer RustFS data, access protocols, and browser-based management." +description: "Administrez les données RustFS, les protocoles d’accès et la gestion dans le navigateur." --- -Use this section to manage RustFS through the Console, administer buckets and objects, and configure access protocols. +Utilisez cette section pour gérer RustFS via la Console, administrer les compartiments et les objets, et configurer les protocoles d’accès. -## Administration areas +## Domaines d’administration -- [Console](./console/index.md) covers browser-based administration and sign-in methods. -- [Data Management](./data/object/object-lock.md) covers buckets, objects, lifecycle behavior, and data protection features. +- [Console](./console/index.md) couvre l’administration via le navigateur et les modes de connexion. +- [Gestion des données](./data/object/object-lock.md) couvre les compartiments, les objets, le cycle de vie et les fonctions de protection des données. - [S3 Tables](/administration/data/s3-tables) présente les compartiments de tables et le catalogue REST Iceberg intégré. -- [Protocol Support](./protocols/s3.md) covers S3, WebDAV, FTPS, and SFTP access. -- [CORS Configuration](./cors/index.md) covers cross-origin access to RustFS services. -- [Virtual-Host Access](/integration/virtual) covers domain-based S3 addressing. +- [Protocoles](./protocols/s3.md) couvre l’accès S3, WebDAV, FTPS et SFTP. +- [Configuration CORS](./cors/index.md) couvre l’accès entre origines (cross-origin) aux services RustFS. +- [Accès par hôte virtuel](/integration/virtual) couvre l’adressage S3 fondé sur le nom de domaine. -For identity, encryption, transport security, and auditing, continue with [Security & Compliance](/security-compliance). +Pour l’identité, le chiffrement, la sécurité du transport et l’audit, poursuivez avec [Sécurité et conformité](/security-compliance). diff --git a/content/fr/administration/protocols/swift.md b/content/fr/administration/protocols/swift.md index 980f4d8a8..d038c42fc 100644 --- a/content/fr/administration/protocols/swift.md +++ b/content/fr/administration/protocols/swift.md @@ -9,11 +9,11 @@ RustFS peut exposer une API compatible avec OpenStack Swift sur le même point d La prise en charge de Swift est facultative et ne couvre pas tous les comportements d’OpenStack Swift. Les requêtes `HEAD` au niveau du compte et les formats de liste autres que JSON ne sont pas implémentés. Validez le fonctionnement de votre client avant d’utiliser cette API en production. -::: +:: : ## Correspondance entre Swift et RustFS -Les requêtes Swift utilisent le chemin `/v1/AUTH_/...` sur le point de terminaison de l’API S3 de RustFS : +Les requêtes Swift utilisent le chemin `/v1/AUTH_/...` sur le point de terminaison de l’API S3 de RustFS : | Ressource Swift | Chemin de requête | Correspondance RustFS | | --- | --- | --- | @@ -23,17 +23,17 @@ Les requêtes Swift utilisent le chemin `/v1/AUTH_/...` sur le point L’ID de projet dans l’URL doit correspondre à celui du jeton Keystone validé. RustFS accepte le jeton dans `X-Auth-Token` ou `X-Storage-Token`. -Les opérations principales confirmées sont les suivantes : +Les opérations principales confirmées sont les suivantes : | Portée | Opérations | | --- | --- | | Compte | Répertorier les conteneurs, mettre à jour les métadonnées du compte | | Conteneur | Créer, répertorier, inspecter, mettre à jour les métadonnées, supprimer | -| Objet | Charger, télécharger, télécharger une plage, inspecter, mettre à jour les métadonnées, copier, supprimer | +| Objet | Charger (upload), télécharger, télécharger une plage, inspecter, mettre à jour les métadonnées, copier, supprimer | ## Compiler avec la prise en charge de Swift -Swift ne fait pas partie des fonctionnalités RustFS activées par défaut. Compilez-la explicitement depuis le dépôt `rustfs/rustfs` : +Swift ne fait pas partie des fonctionnalités RustFS activées par défaut. Compilez-la explicitement depuis le dépôt `rustfs/rustfs` : ```bash cargo build --release --features swift @@ -43,7 +43,7 @@ Le binaire obtenu sert les chemins Swift sur l’adresse configurée pour l’AP ## Configurer Keystone -Activez Keystone et définissez son point de terminaison d’authentification avant de démarrer RustFS : +Activez Keystone et définissez son point de terminaison d’authentification avant de démarrer RustFS : ```bash export RUSTFS_KEYSTONE_ENABLE=true @@ -55,18 +55,18 @@ export RUSTFS_KEYSTONE_VERIFY_SSL=true | Variable | Rôle | Valeur par défaut | | --- | --- | --- | | `RUSTFS_KEYSTONE_ENABLE` | Active la validation des jetons Keystone. | `false` | -| `RUSTFS_KEYSTONE_AUTH_URL` | Définit le point de terminaison d’authentification Keystone ; obligatoire lorsque Keystone est activé. | Non définie | +| `RUSTFS_KEYSTONE_AUTH_URL` | Définit le point de terminaison d’authentification Keystone ; obligatoire lorsque Keystone est activé. | Non définie | | `RUSTFS_KEYSTONE_VERSION` | Sélectionne la version de l’API Keystone. | `v3` | | `RUSTFS_KEYSTONE_VERIFY_SSL` | Vérifie le certificat TLS de Keystone. | `true` | | `RUSTFS_KEYSTONE_CACHE_SIZE` | Définit le nombre maximal d’entrées du cache de jetons. | `10000` | | `RUSTFS_KEYSTONE_CACHE_TTL` | Définit la durée de vie du cache de jetons en secondes. | `300` | | `RUSTFS_KEYSTONE_TIMEOUT` | Définit le délai d’expiration des requêtes Keystone en secondes. | `30` | -Nous recommandons de conserver la vérification TLS. Lorsque Keystone rejette un jeton fourni, RustFS renvoie `401 Unauthorized` et n’utilise pas les informations d’identification locales pour cette requête. +Nous recommandons de conserver la vérification TLS. Lorsque Keystone rejette un jeton fourni, RustFS renvoie `401 Unauthorized` et n’utilise pas les identifiants locaux pour cette requête. ## Vérifier l’API -Obtenez auprès de Keystone un jeton limité à un projet et l’ID de ce projet, puis définissez les variables shell suivantes : +Obtenez auprès de Keystone un jeton limité à un projet et l’ID de ce projet, puis définissez les variables shell suivantes : ```bash export SWIFT_TOKEN='' @@ -74,7 +74,7 @@ export SWIFT_ACCOUNT='AUTH_' export SWIFT_URL="http://localhost:9000/v1/${SWIFT_ACCOUNT}" ``` -Répertoriez les conteneurs visibles par le projet : +Répertoriez les conteneurs visibles par le projet : ```bash curl --fail-with-body \ @@ -82,7 +82,7 @@ curl --fail-with-body \ "${SWIFT_URL}" ``` -Créez `my-bucket`, chargez `hello.txt`, puis téléchargez l’objet : +Créez `my-bucket`, chargez `hello.txt`, puis téléchargez l’objet : ```bash curl --fail-with-body --request PUT \ @@ -104,5 +104,5 @@ Une requête vers un compte `AUTH_` qui ne correspond pas au projet ## Étapes suivantes - [Consulter la matrice de compatibilité S3](/fr/reference/s3-compatibility) -- [Gérer les informations d’identification RustFS](/fr/operations/credentials) +- [Gérer les identifiants RustFS](/fr/operations/credentials) - [Configurer TLS pour RustFS](/fr/integration/tls-configured) diff --git a/content/fr/developer/integration/ai/index.md b/content/fr/developer/integration/ai/index.md index 687eca06e..61a950e15 100644 --- a/content/fr/developer/integration/ai/index.md +++ b/content/fr/developer/integration/ai/index.md @@ -1,9 +1,9 @@ --- title: "IA" -description: "Connectez les plateformes d'IA à RustFS via des interfaces de stockage objet compatibles S3." +description: "Connectez les plateformes d’IA à RustFS via des interfaces de stockage objet compatibles S3." --- -Utilisez **RustFS** comme couche de stockage objet pour les plateformes d'IA et de machine learning qui prennent en charge un point de terminaison compatible S3. +Utilisez **RustFS** comme couche de stockage objet pour les plateformes d’IA et de machine learning qui prennent en charge un point de terminaison compatible S3. ## Plateformes @@ -11,4 +11,4 @@ Utilisez **RustFS** comme couche de stockage objet pour les plateformes d'IA et - [Ray](./ray.md) - [vLLM](./vllm.md) -Conservez les jeux de données et les checkpoints dans des buckets dédiés et limitez les identifiants aux opérations de bucket requises. +Conservez les jeux de données et les checkpoints dans des compartiments dédiés et limitez les identifiants aux opérations de compartiment requises. diff --git a/content/fr/developer/integration/backup/restic.md b/content/fr/developer/integration/backup/restic.md index c70ac3d25..7ae46c797 100644 --- a/content/fr/developer/integration/backup/restic.md +++ b/content/fr/developer/integration/backup/restic.md @@ -5,15 +5,15 @@ description: "Sauvegardez des données locales vers RustFS avec Restic et restau Restic est un outil de sauvegarde en ligne de commande qui stocke les snapshots dans un dépôt. Cette page montre comment pointer Restic vers RustFS, sauvegarder un répertoire local, restaurer un snapshot et vérifier les objets stockés dans RustFS. -Vous avez besoin d'une instance RustFS en cours d'exécution, d'un compartiment comme `my-bucket`, de Restic installé, de clés d'accès pour le compartiment et d'un mot de passe pour le dépôt Restic. +Vous avez besoin d’une instance RustFS en cours d’exécution, d’un compartiment comme `my-bucket`, de Restic installé, de clés d’accès pour le compartiment et d’un mot de passe pour le dépôt Restic. :::note[Adressage de type chemin] -Le backend S3 de Restic doit utiliser l'adressage de type chemin avec RustFS. Cette page définit `-o s3.bucket-lookup=path` et utilise le nom du compartiment dans l'URL du dépôt. +Le backend S3 de Restic doit utiliser l’adressage de type chemin avec RustFS. Cette page définit `-o s3.bucket-lookup=path` et utilise le nom du compartiment dans l’URL du dépôt. -::: +:: : -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -22,19 +22,19 @@ flowchart LR RustFS --> Bucket["my-bucket/restic"] ``` -Restic écrit les métadonnées du dépôt et les snapshots de sauvegarde dans RustFS via l'API S3. Le préfixe du dépôt dans cette page est `restic`, et le compartiment est `my-bucket`. +Restic écrit les métadonnées du dépôt et les snapshots de sauvegarde dans RustFS via l’API S3. Le préfixe du dépôt dans cette page est `restic`, et le compartiment est `my-bucket`. ## 1. Préparer le compartiment -Ouvrez la Console RustFS à l'adresse `http://localhost:9001` et créez `my-bucket`, ou choisissez un compartiment existant dédié aux sauvegardes. +Ouvrez la Console RustFS à l’adresse `http://localhost:9001` et créez `my-bucket`, ou choisissez un compartiment existant dédié aux sauvegardes. ![Console RustFS affichant la liste des compartiments avec le compartiment de sauvegarde `my-bucket` sélectionné](./images/restic-console.png) -Utilisez un compartiment dédié pour chaque tâche de sauvegarde. La capture d'écran montre la Console en anglais et en thème clair. +Utilisez un compartiment dédié pour chaque tâche de sauvegarde. La capture d’écran montre la Console en anglais et en thème clair. ## 2. Initialiser le dépôt Restic -Définissez les identifiants, la région, le mot de passe du dépôt et l'emplacement du dépôt : +Définissez les identifiants, la région, le mot de passe du dépôt et l’emplacement du dépôt : ```bash export AWS_ACCESS_KEY_ID= @@ -44,17 +44,17 @@ export RESTIC_PASSWORD= export RESTIC_REPOSITORY=s3:http://localhost:9000/my-bucket/restic ``` -Exécutez `restic init` avec la sélection de compartiment en mode chemin : +Exécutez `restic init` avec la sélection de compartiment en mode chemin : ```bash restic -o s3.bucket-lookup=path init ``` -Le mot de passe du dépôt protège les données des snapshots. Conservez-le séparément des clés d'accès RustFS. +Le mot de passe du dépôt protège les données des snapshots. Conservez-le séparément des clés d’accès RustFS. ## 3. Sauvegarder des données -Créez un petit répertoire de test et sauvegardez-le : +Créez un petit répertoire de test et sauvegardez-le : ```bash mkdir -p ~/Documents/restic-demo @@ -62,11 +62,11 @@ printf 'hello from RustFS\n' > ~/Documents/restic-demo/hello.txt restic -o s3.bucket-lookup=path backup ~/Documents/restic-demo ``` -Restic affiche l'ID du snapshot une fois la sauvegarde terminée. Relancez la commande après avoir modifié un fichier pour créer un second snapshot. +Restic affiche l’ID du snapshot une fois la sauvegarde terminée. Relancez la commande après avoir modifié un fichier pour créer un second snapshot. ## 4. Restaurer un snapshot -Restaurez le snapshot le plus récent dans un répertoire séparé : +Restaurez le snapshot le plus récent dans un répertoire séparé : ```bash mkdir -p ~/Documents/restic-restore @@ -79,7 +79,7 @@ Vous pouvez aussi restaurer un ID de snapshot précis si vous devez récupérer Ouvrez `my-bucket` dans la Console RustFS et vérifiez que Restic a créé des objets de dépôt sous le préfixe `restic/`. -Vous pouvez aussi lancer une vérification du dépôt : +Vous pouvez aussi lancer une vérification du dépôt : ```bash restic -o s3.bucket-lookup=path check @@ -88,4 +88,4 @@ restic -o s3.bucket-lookup=path check ## Étapes suivantes - [CLI Client (rc)](/operations/rc) pour créer des compartiments et inspecter les objets depuis la ligne de commande. -- [Configuration TLS](/integration/tls-configured) si vous exposez RustFS hors d'un réseau de confiance. \ No newline at end of file +- [Configuration TLS](/integration/tls-configured) si vous exposez RustFS hors d’un réseau de confiance. \ No newline at end of file diff --git a/content/fr/developer/integration/big-data/flink.md b/content/fr/developer/integration/big-data/flink.md index 998bd66ad..dfa4c5fc9 100644 --- a/content/fr/developer/integration/big-data/flink.md +++ b/content/fr/developer/integration/big-data/flink.md @@ -3,11 +3,11 @@ title: "Apache Flink" description: "Lisez et écrivez des données CSV stockées dans le stockage objet RustFS avec Apache Flink et son plugin S3 filesystem." --- -Ce guide connecte [Apache Flink](https://github.com/apache/flink) à **RustFS** via le plugin S3 filesystem de Flink (`flink-s3-fs-hadoop`). Vous allez démarrer un cluster de session avec Docker Compose, écrire un résultat borné dans le bucket en mode batch, puis le relire via Flink SQL. Le flux a été validé avec `flink:1.20` et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide connecte [Apache Flink](https://github.com/apache/flink) à **RustFS** via le plugin S3 filesystem de Flink (`flink-s3-fs-hadoop`). Vous allez démarrer un cluster de session avec Docker Compose, écrire un résultat borné dans le compartiment en mode batch, puis le relire via Flink SQL. Le flux a été validé avec `flink:1.20` et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -Le plugin `flink-s3-fs-hadoop` enregistre le schéma `s3://` pour le connecteur filesystem de Flink. Le point de terminaison, l'adressage path-style, HTTP simple et les identifiants sont configurés via les propriétés `s3.*` de `flink-conf.yaml` (passées par `FLINK_PROPERTIES`). +Le plugin `flink-s3-fs-hadoop` enregistre le schéma `s3://` pour le connecteur filesystem de Flink. Le point de terminaison, l’adressage de type chemin (path-style), HTTP non chiffré et les identifiants sont configurés via les propriétés `s3.*` de `flink-conf.yaml` (passées par `FLINK_PROPERTIES`). ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-flink cd rustfs-flink ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Le plugin S3 est embarqué dans l'image sous `/opt/flink/opt/` et doit être copié vers `/opt/flink/plugins/s3fs/` pour être chargé. Préparez un répertoire local : +Le plugin S3 est embarqué dans l’image sous `/opt/flink/opt/` et doit être copié vers `/opt/flink/plugins/s3fs/` pour être chargé. Préparez un répertoire local : ```bash mkdir -p s3fs @@ -45,7 +45,7 @@ docker cp flink-tmp:/opt/flink/opt/flink-s3-fs-hadoop-1.20.5.jar s3fs/ docker rm flink-tmp ``` -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -144,13 +144,13 @@ Les propriétés `s3.access-key`, `s3.secret-key`, `s3.endpoint` et `s3.path-sty ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d @@ -159,7 +159,7 @@ docker compose ps -a ## 3. Écrire un résultat dans RustFS -Créez le job SQL — mode batch avec le sink filesystem : +Créez le job SQL — mode batch avec le sink filesystem : ```yaml title="batch.sql" SET 'execution.runtime-mode' = 'batch'; @@ -177,7 +177,7 @@ INSERT INTO sink VALUES (1, 'alpha'), (2, 'bravo'), (3, 'charlie'), (4, 'delta'), (5, 'echo'); ``` -Soumettez-le via le client SQL dans le JobManager : +Soumettez-le via le client SQL dans le JobManager : ```bash docker compose exec jobmanager bash -c "/opt/flink/bin/sql-client.sh embedded -f /dev/stdin" < batch.sql @@ -187,7 +187,7 @@ Le job se termine une fois toutes les lignes écrites. ## 4. Relire les données -Créez la requête de lecture — le connecteur filesystem scanne le préfixe : +Créez la requête de lecture — le connecteur filesystem scanne le préfixe : ```yaml title="read.sql" CREATE TABLE readings ( @@ -222,7 +222,7 @@ docker compose exec jobmanager bash -c "/opt/flink/bin/sql-client.sh embedded -f ## 5. Vérifier les objets dans RustFS -Listez le préfixe via l'image d'initialisation du bucket : +Listez le préfixe via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ @@ -233,25 +233,25 @@ docker compose run --rm --entrypoint /bin/sh create-bucket -c \ [2026-09-21 01:34:52] 41 B flink-out/part-f759f9e8-3d1b-46a1-a92e-53e9b727e831-task-0-file-0 ``` -Vous pouvez également parcourir le préfixe dans la console RustFS : +Vous pouvez également parcourir le préfixe dans la Console RustFS : -![Le fichier de sortie Flink stocké dans la console RustFS](./images/rustfs-flink-objects.png) +![Le fichier de sortie Flink stocké dans la Console RustFS](./images/rustfs-flink-objects.png) ## 6. Utiliser RustFS S3 Tables -RustFS S3 Tables fournit un catalogue REST Apache Iceberg intégré, permettant à Flink de traiter un table bucket comme un entrepôt Iceberg géré tandis que les données restent dans RustFS. Activez un table bucket et orientez le catalogue REST du connecteur Iceberg de Flink vers RustFS comme décrit dans [S3 Tables](/administration/data/s3-tables) : l'URI du catalogue REST est `http://:9000/iceberg`, le warehouse est le nom du bucket, et les requêtes de catalogue (AWS Signature Version 4, nom de signature `s3`) comme l'accès aux fichiers S3 utilisent l'adressage path-style. +RustFS S3 Tables fournit un catalogue REST Apache Iceberg intégré, permettant à Flink de traiter un compartiment de tables (table bucket) comme un entrepôt Iceberg géré tandis que les données restent dans RustFS. Activez un compartiment de tables et orientez le catalogue REST du connecteur Iceberg de Flink vers RustFS comme décrit dans [S3 Tables](/administration/data/s3-tables) : l’URI du catalogue REST est `http://:9000/iceberg`, le warehouse est le nom du compartiment, et les requêtes de catalogue (AWS Signature Version 4, nom de signature `s3`) comme l’accès aux fichiers S3 utilisent l’adressage de type chemin (path-style). -Selon la matrice de support S3 Tables, validez les versions exactes de Flink et d'Iceberg que vous déployez par rapport au catalogue avant d'adopter ce chemin en production. +Selon la matrice de prise en charge S3 Tables, validez les versions exactes de Flink et d’Iceberg que vous déployez par rapport au catalogue avant d’adopter ce chemin en production. ## 7. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les fichiers stockés et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les fichiers stockés et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -267,12 +267,12 @@ Le plugin S3 lit ses identifiants depuis les propriétés `s3.*` de `flink-conf. Tous les conteneurs Flink et RustFS doivent partager un réseau Compose. Si RustFS est attaché à un réseau externe, connectez également les conteneurs Flink à ce réseau avant de soumettre le job. -### Une écriture streaming échoue avec "Stream closed" après un échec +### Une écriture streaming échoue avec « Stream closed » après un échec -La reprise d'un upload S3 en cours après un échec peut laisser le writer dans un état irrécupérable. Supprimez le préfixe de sortie du job dans le bucket et soumettez à nouveau, ou utilisez le mode batch comme dans ce guide pour les écritures ponctuelles. +La reprise d’un chargement S3 (upload) en cours après un échec peut laisser le writer dans un état irrécupérable. Supprimez le préfixe de sortie du job dans le compartiment et soumettez à nouveau, ou utilisez le mode batch comme dans ce guide pour les écritures ponctuelles. -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). - Suivez la [documentation Apache Flink](https://nightlies.apache.org/flink/flink-docs-stable/) pour les options du connecteur filesystem telles que le partitionnement et la compaction. diff --git a/content/fr/developer/integration/big-data/iceberg.md b/content/fr/developer/integration/big-data/iceberg.md index 0b0ad517c..5b1899b89 100644 --- a/content/fr/developer/integration/big-data/iceberg.md +++ b/content/fr/developer/integration/big-data/iceberg.md @@ -1,21 +1,21 @@ --- title: "Apache Iceberg" -description: "Run Apache Iceberg with Spark, a REST catalog, and RustFS object storage using Docker Compose." +description: "Exécutez Apache Iceberg avec Spark, un catalogue REST et le stockage objet RustFS, à l’aide de Docker Compose." --- -This guide runs **Apache Iceberg** with Spark, an Iceberg REST catalog, and **RustFS** as the S3-compatible warehouse. You will create an Iceberg table, write rows, query them, and verify that the table files are stored in RustFS. +Ce guide exécute **Apache Iceberg** avec Spark, un catalogue REST Iceberg et **RustFS** comme entrepôt compatible avec S3. Vous allez créer une table Iceberg, écrire des lignes, les interroger et vérifier que les fichiers de la table sont stockés dans RustFS. -Pour utiliser le catalogue REST intégré à RustFS, suivez la [configuration de S3 Tables](/administration/data/s3-tables) et le [guide PyIceberg](/developer/integration/big-data/pyiceberg). Le déploiement ci-dessous exécute un service de catalogue séparé. +Pour utiliser le catalogue REST intégré à RustFS, suivez la [configuration de S3 Tables](/administration/data/s3-tables) et le [guide PyIceberg](/developer/integration/big-data/pyiceberg). Le déploiement ci-dessous exécute un service de catalogue distinct. -You need Docker with the Compose plugin and enough local resources to run four containers. This deployment is intended for local integration testing, not production. +Vous avez besoin de Docker avec le plugin Compose et de ressources locales suffisantes pour quatre conteneurs. Ce déploiement est destiné à un test d’intégration local, pas à la production. -:::note[Upstream status] +:::note[État en amont] -Apache Iceberg [PR #14928](https://github.com/apache/iceberg/pull/14928) demonstrated the same Spark, REST catalog, `S3FileIO`, and RustFS workflow, including table creation and writes. The pull request was closed without merging, and the current [Spark quickstart](https://iceberg.apache.org/spark-quickstart/#docker-compose) still uses another S3-compatible store. The configuration below therefore documents a RustFS integration rather than an Apache Iceberg default. +La [demande d’intégration n° 14928](https://github.com/apache/iceberg/pull/14928) d’Apache Iceberg a démontré le même flux Spark, catalogue REST, `S3FileIO` et RustFS, y compris la création de table et les écritures. Cette demande a été fermée sans être fusionnée, et le [guide de démarrage Spark](https://iceberg.apache.org/spark-quickstart/#docker-compose) actuel utilise encore un autre stockage compatible avec S3. La configuration ci-dessous documente donc une intégration RustFS, et non un réglage par défaut d’Apache Iceberg. -::: +:: : -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -25,27 +25,27 @@ flowchart LR Init["Bucket initializer"] -->|Create my-bucket| RustFS ``` -Spark uses the REST service for catalog operations. Both Spark and the REST catalog receive the RustFS endpoint, region, credentials, and path-style setting so they can access metadata and data files in `s3://my-bucket/warehouse`. +Spark utilise le service REST pour les opérations de catalogue. Spark et le catalogue REST reçoivent le point de terminaison RustFS, la région, les identifiants et le réglage d’adressage de type chemin, afin d’accéder aux fichiers de métadonnées et de données dans `s3://my-bucket/warehouse`. -## 1. Create the project files +## 1. Créer les fichiers du projet -Create a working directory: +Créez un répertoire de travail : ```bash mkdir rustfs-iceberg cd rustfs-iceberg ``` -Create an environment file and replace both credential placeholders: +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use dedicated credentials for the warehouse bucket. Do not commit `.env` to source control. +Utilisez des identifiants dédiés pour le compartiment de l’entrepôt. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Create the Spark catalog configuration: +Créez la configuration du catalogue Spark : ```ini title="spark-defaults.conf" spark.sql.extensions org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions @@ -60,9 +60,9 @@ spark.sql.defaultCatalog demo spark.sql.catalogImplementation in-memory ``` -Path-style access is required for this container-network endpoint. The hostname `rustfs` is resolvable only inside the Compose network; clients running on the host use `http://localhost:9000` instead. +L’adressage de type chemin est requis pour ce point de terminaison du réseau de conteneurs. Le nom d’hôte `rustfs` n’est résolu qu’à l’intérieur du réseau Compose ; les clients exécutés sur l’hôte utilisent `http://localhost:9000`. -Create the Compose file: +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -148,46 +148,46 @@ volumes: rustfs-data: ``` -The [`rc` image](https://github.com/rustfs/cli) provides the official RustFS command-line client. The initializer checks for `my-bucket` before creating it, so repeated starts do not delete existing warehouse data. The RustFS volume preserves warehouse objects across container recreation. +L’[image `rc`](https://github.com/rustfs/cli) fournit le client en ligne de commande officiel de RustFS. L’initialiseur vérifie l’existence de `my-bucket` avant de le créer, afin que des redémarrages répétés ne suppriment pas les données d’entrepôt existantes. Le volume RustFS conserve les objets de l’entrepôt lorsque les conteneurs sont recréés. -:::warning[Image versions] +:::warning[Versions d’images] -The Apache Iceberg quickstart images are published without stable version tags in the upstream example. Before using this pattern beyond local testing, pin every image to a tested tag or digest and validate the Spark, Iceberg runtime, and REST catalog versions together. +Les images du guide de démarrage Apache Iceberg sont publiées sans étiquettes de version stables dans l’exemple en amont. Avant d’utiliser ce modèle au-delà d’un test local, épinglez chaque image sur une étiquette ou une empreinte testée, et validez ensemble les versions de Spark, du moteur Iceberg et du catalogue REST. -::: +:: : -## 2. Validate and start the deployment +## 2. Valider et démarrer le déploiement -Resolve the Compose file before starting containers: +Résolvez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Start the services and wait for the bucket initializer to finish: +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -The `create-bucket` service should show an exit code of `0`. Check its logs if it does not complete: +Le service `create-bucket` devrait afficher un code de sortie `0`. Consultez ses journaux s’il ne se termine pas : ```bash docker compose logs create-bucket ``` -Open the RustFS Console at `http://localhost:9001`. The REST catalog is available at `http://localhost:8181`, and the Spark notebook server is available at `http://localhost:8888`. +Ouvrez la Console RustFS à l’adresse `http://localhost:9001`. Le catalogue REST est disponible à l’adresse `http://localhost:8181`, et le serveur de notebooks Spark à l’adresse `http://localhost:8888`. -## 3. Create and query an Iceberg table +## 3. Créer une table Iceberg et l’interroger -Start Spark SQL: +Démarrez Spark SQL : ```bash docker compose exec spark-iceberg spark-sql ``` -Create a namespace and a partitioned table: +Créez un espace de noms et une table partitionnée : ```sql CREATE NAMESPACE IF NOT EXISTS demo.nyc; @@ -203,7 +203,7 @@ CREATE TABLE demo.nyc.taxis PARTITIONED BY (vendor_id); ``` -Insert and query sample rows: +Insérez des lignes d’exemple, puis interrogez-les : ```sql INSERT INTO demo.nyc.taxis @@ -216,7 +216,7 @@ VALUES SELECT * FROM demo.nyc.taxis ORDER BY trip_id; ``` -The query should return four rows: +La requête devrait renvoyer quatre lignes : ```text 1 1000371 1.8 15.32 N @@ -225,51 +225,51 @@ The query should return four rows: 1 1000374 8.4 42.13 Y ``` -## 4. Verify objects in RustFS +## 4. Vérifier les objets dans RustFS -List the warehouse from the bucket-initializer image: +Listez l’entrepôt depuis l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ '/usr/bin/rc alias set rustfs http://rustfs:9000 "$RUSTFS_ACCESS_KEY" "$RUSTFS_SECRET_KEY" >/dev/null && /usr/bin/rc find rustfs/my-bucket/warehouse' ``` -The output should include Iceberg metadata and data objects below the `warehouse/nyc/taxis` prefix. You can also inspect the `my-bucket` bucket in the RustFS Console. +La sortie devrait inclure des objets de métadonnées et de données Iceberg sous le préfixe `warehouse/nyc/taxis`. Vous pouvez aussi inspecter le compartiment `my-bucket` dans la Console RustFS. -## 5. Stop or reset the stack +## 5. Arrêter ou réinitialiser la pile -Stop the containers while keeping the RustFS data volume: +Arrêtez les conteneurs tout en conservant le volume de données RustFS : ```bash docker compose down ``` -To delete the local warehouse and start from an empty RustFS volume, explicitly include `--volumes`: +Pour supprimer l’entrepôt local et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes ``` -## Troubleshooting +## Dépannage -### Spark cannot reach RustFS +### Spark n’atteint pas RustFS -Use `http://rustfs:9000` inside Compose. `http://localhost:9000` refers to the Spark container itself when used in `spark-defaults.conf`. +Dans Compose, utilisez `http://rustfs:9000`. Dans `spark-defaults.conf`, `http://localhost:9000` désigne le conteneur Spark lui-même. -Confirm that `spark.sql.catalog.demo.s3.path-style-access` is `true`. Virtual-hosted requests require additional RustFS domain and DNS configuration. +Vérifiez que `spark.sql.catalog.demo.s3.path-style-access` vaut `true`. Les requêtes en adressage de type hôte virtuel exigent une configuration de domaine et de DNS RustFS supplémentaire. -### The catalog returns an S3 error +### Le catalogue renvoie une erreur S3 -Check that the credentials in `.env` match the RustFS credentials and that the `create-bucket` service completed successfully: +Vérifiez que les identifiants de `.env` correspondent aux identifiants RustFS et que le service `create-bucket` s’est terminé avec succès : ```bash docker compose logs create-bucket rest ``` -The REST catalog property uses doubled underscores in `CATALOG_IO__IMPL` and `CATALOG_S3_PATH__STYLE__ACCESS`; the fixture converts them to the dotted and hyphenated Iceberg property names. +La propriété du catalogue REST utilise des doubles traits de soulignement dans `CATALOG_IO__IMPL` et `CATALOG_S3_PATH__STYLE__ACCESS` ; l’image de test les convertit en noms de propriétés Iceberg à points et à traits d’union. -## Next steps +## Étapes suivantes -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Iceberg operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Apache Iceberg Spark documentation](https://iceberg.apache.org/docs/latest/spark-getting-started/) to configure your existing Spark environment. \ No newline at end of file +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations Iceberg. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). +- Suivez la [documentation Spark d’Apache Iceberg](https://iceberg.apache.org/docs/latest/spark-getting-started/) pour configurer votre environnement Spark existant. \ No newline at end of file diff --git a/content/fr/developer/integration/big-data/index.md b/content/fr/developer/integration/big-data/index.md index 244d06f5d..1e5949a8c 100644 --- a/content/fr/developer/integration/big-data/index.md +++ b/content/fr/developer/integration/big-data/index.md @@ -1,11 +1,11 @@ --- title: "Analyse de données" -description: "Connect big data systems to RustFS through S3-compatible object storage interfaces." +description: "Connectez des systèmes d’analyse de données à RustFS via des interfaces de stockage objet compatibles avec S3." --- -Use **RustFS** as the object storage layer for data analytics systems that support an S3-compatible endpoint. +Utilisez **RustFS** comme couche de stockage objet pour les systèmes d’analyse de données qui prennent en charge un point de terminaison compatible avec S3. -## Systems +## Systèmes - [Airflow](./airflow.md) - [Delta Lake](./delta-lake.md) @@ -22,4 +22,4 @@ Use **RustFS** as the object storage layer for data analytics systems that suppo - [Hive](./hive.md) - [Zeppelin](./zeppelin.md) -Keep big data workload data in a dedicated bucket and prefix, and use credentials scoped to the required bucket operations. +Conservez les données de ces charges de travail dans un compartiment et un préfixe dédiés, et utilisez des identifiants limités aux opérations de compartiment requises. diff --git a/content/fr/developer/integration/big-data/meta.json b/content/fr/developer/integration/big-data/meta.json index 834b14a48..a158e1478 100644 --- a/content/fr/developer/integration/big-data/meta.json +++ b/content/fr/developer/integration/big-data/meta.json @@ -1,5 +1,5 @@ { - "title": "Big Data", + "title": "Analyse de données", "pages": [ "airflow", "dolphinscheduler", diff --git a/content/fr/developer/integration/big-data/pyiceberg.md b/content/fr/developer/integration/big-data/pyiceberg.md index d597ee960..77e963ecd 100644 --- a/content/fr/developer/integration/big-data/pyiceberg.md +++ b/content/fr/developer/integration/big-data/pyiceberg.md @@ -3,16 +3,16 @@ title: "PyIceberg" description: "Créez, écrivez et lisez une table Iceberg avec PyIceberg via le catalogue REST de RustFS S3 Tables." --- -Utilisez **PyIceberg** pour créer un espace de noms et une table dans le catalogue RustFS S3 Tables, ajouter deux lignes et vérifier les données après avoir rechargé la table. Ce tutoriel utilise PyIceberg `0.10.0` et Python `3.12`, avec des informations d’identification configurées explicitement. +Utilisez **PyIceberg** pour créer un espace de noms et une table dans le catalogue RustFS S3 Tables, ajouter deux lignes et vérifier les données après avoir rechargé la table. Ce tutoriel utilise PyIceberg `0.10.0` et Python `3.12`, avec des identifiants configurés explicitement. ## Prérequis -- Terminez la [configuration de S3 Tables](/administration/data/s3-tables) : créez et activez `my-bucket` et respectez les exigences relatives au compte et à TLS. +- Terminez la [configuration de S3 Tables](/administration/data/s3-tables) : créez et activez `my-bucket` et respectez les exigences relatives au compte et à TLS. - Conservez les variables `RUSTFS_ENDPOINT`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` et `AWS_DEFAULT_REGION` définies dans ce guide. ## 1. Installer le client -Créez un répertoire et un environnement Python isolé : +Créez un répertoire et un environnement Python isolé : ```bash mkdir rustfs-s3-tables @@ -90,15 +90,15 @@ catalog = RustFSRestCatalog( L’adaptateur redéfinit le hook `_init_sigv4` de PyIceberg afin que la découverte soit signée avant la fin du constructeur du catalogue. Conservez la version PyIceberg fixée pour ce module et réexécutez tout le tutoriel avant d’en changer. -::: +:: : ## 3. Créer et lire une table -L’exemple crée l’espace de noms `analytics` et la table `events` et s’arrête si l’une de ces ressources existe déjà. Chaque segment d’espace de noms et chaque nom de table doit comporter 1–64 caractères ASCII : lettres minuscules, chiffres, `_` ou `-`, avec une lettre ou un chiffre à chaque extrémité. L’espace de noms complet est limité à 512 caractères, points compris. +L’exemple crée l’espace de noms `analytics` et la table `events` et s’arrête si l’une de ces ressources existe déjà. Chaque segment d’espace de noms et chaque nom de table doit comporter 1–64 caractères ASCII : lettres minuscules, chiffres, `_` ou `-`, avec une lettre ou un chiffre à chaque extrémité. L’espace de noms complet est limité à 512 caractères, points compris. Pour utiliser d’autres noms, modifiez `identifier` dans `example.py` ainsi que les noms dans les commandes d’inspection et de suppression ci-dessous. -Enregistrez le programme suivant dans le même répertoire : +Enregistrez le programme suivant dans le même répertoire : ```python title="example.py" import json @@ -128,13 +128,13 @@ print("rows:", json.dumps(actual)) print("metadata:", loaded.metadata_location) ``` -Exécutez-le : +Exécutez-le : ```bash python example.py ``` -La sortie contient les deux lignes complètes et l’URI S3 de l’objet de métadonnées courant : +La sortie contient les deux lignes complètes et l’URI S3 de l’objet de métadonnées courant : ```text rows: [{"id": 1, "payload": "alpha"}, {"id": 2, "payload": "beta"}] @@ -145,7 +145,7 @@ La clé générée pour l’objet de métadonnées varie. Une vérification réu ## 4. Inspecter l’exemple ou le retirer du catalogue -Listez la table dans un nouveau processus Python avec le même module de connexion : +Listez la table dans un nouveau processus Python avec le même module de connexion : ```bash python - <<'PY' @@ -159,9 +159,9 @@ Le résultat devrait contenir `("analytics", "events")`. :::note[Suppression des entrées du catalogue uniquement] -Les commandes suivantes retirent l’entrée de table de ce tutoriel et son espace de noms devenu vide. Le compartiment et les objets sous-jacents sont conservés. Planifiez tout nettoyage de données avant de continuer : après `drop_table`, la maintenance ne peut plus trouver la table. Consultez la [maintenance et la protection des données](/administration/data/s3-tables). +Les commandes suivantes retirent l’entrée de table de ce tutoriel et son espace de noms devenu vide. Le compartiment et les objets sous-jacents sont conservés. Planifiez tout nettoyage de données avant de continuer : après `drop_table`, la maintenance ne peut plus trouver la table. Consultez la [maintenance et la protection des données](/administration/data/s3-tables). -::: +:: : ```bash python - <<'PY' diff --git a/content/fr/developer/integration/big-data/spark.md b/content/fr/developer/integration/big-data/spark.md index ff275aabf..856ce857f 100644 --- a/content/fr/developer/integration/big-data/spark.md +++ b/content/fr/developer/integration/big-data/spark.md @@ -3,11 +3,11 @@ title: "Apache Spark" description: "Lisez et écrivez des données Parquet stockées dans le stockage objet RustFS avec Apache Spark via le connecteur s3a." --- -Ce guide connecte [Apache Spark](https://github.com/apache/spark) à **RustFS** via le connecteur `s3a`. Vous allez démarrer RustFS avec Docker Compose, exécuter un job Spark qui écrit un dataset Parquet dans le bucket, le relire, puis vérifier les objets dans RustFS. Le flux a été validé avec `apache/spark:3.5.6` (Hadoop 3.3.4 via `hadoop-aws`) et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide connecte [Apache Spark](https://github.com/apache/spark) à **RustFS** via le connecteur `s3a`. Vous allez démarrer RustFS avec Docker Compose, exécuter un job Spark qui écrit un jeu de données Parquet dans le compartiment, le relire, puis vérifier les objets dans RustFS. Le flux a été validé avec `apache/spark:3.5.6` (Hadoop 3.3.4 via `hadoop-aws`) et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -15,27 +15,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -Spark communique avec RustFS via le système de fichiers S3A de `hadoop-aws`. Les réglages du connecteur — point de terminaison, adressage path-style, HTTP simple et identifiants — sont passés en propriétés `spark.hadoop.fs.s3a.*`. +Spark communique avec RustFS via le système de fichiers S3A de `hadoop-aws`. Les réglages du connecteur — point de terminaison, adressage de type chemin (path-style), HTTP non chiffré et identifiants — sont passés en propriétés `spark.hadoop.fs.s3a.*`. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-spark cd rustfs-spark ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez le job Spark : +Créez le job Spark : ```python title="job.py" from pyspark.sql import SparkSession @@ -51,7 +51,7 @@ print("ROWS_READ_BACK:", back.count()) spark.stop() ``` -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -134,18 +134,18 @@ volumes: rustfs-data: ``` -`--packages org.apache.hadoop:hadoop-aws:3.3.4` télécharge le connecteur S3 au lancement ; il doit correspondre à la version de Hadoop embarquée dans l'image Spark. `spark.jars.ivy=/tmp/.ivy2` déplace le cache de téléchargement vers un répertoire inscriptible. +`--packages org.apache.hadoop:hadoop-aws:3.3.4` télécharge le connecteur S3 au lancement ; il doit correspondre à la version de Hadoop embarquée dans l’image Spark. `spark.jars.ivy=/tmp/.ivy2` déplace le cache de téléchargement vers un répertoire inscriptible. ## 2. Démarrer le stockage et exécuter le job -Démarrez les services de stockage : +Démarrez les services de stockage : ```bash docker compose up -d docker compose ps -a ``` -Exécutez le job Spark : +Exécutez le job Spark : ```bash docker compose run --rm spark @@ -157,7 +157,7 @@ ROWS_READ_BACK: 1000 ## 3. Vérifier les objets dans RustFS -Listez le dataset via l'image d'initialisation du bucket : +Listez le jeu de données via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ @@ -171,25 +171,25 @@ docker compose run --rm --entrypoint /bin/sh create-bucket -c \ [2026-09-21 00:58:21] 1.46 KiB spark-demo/events/part-00002-...-c000.snappy.parquet ``` -Vous pouvez également parcourir le préfixe dans la console RustFS : +Vous pouvez également parcourir le préfixe dans la Console RustFS : -![Sortie Parquet de Spark stockée dans la console RustFS](./images/rustfs-spark-objects.png) +![Sortie Parquet de Spark stockée dans la Console RustFS](./images/rustfs-spark-objects.png) ## 4. Utiliser RustFS S3 Tables -RustFS S3 Tables fournit un catalogue REST Apache Iceberg intégré, permettant à Spark de traiter un table bucket comme un entrepôt Iceberg géré tandis que les données restent dans RustFS. Activez un table bucket et connectez le catalogue REST Iceberg de Spark comme décrit dans [S3 Tables](/administration/data/s3-tables) : l'URI du catalogue REST est `http://:9000/iceberg`, le warehouse est le nom du bucket, et les requêtes de catalogue (AWS Signature Version 4, nom de signature `s3`) comme l'accès aux fichiers S3 utilisent l'adressage path-style. +RustFS S3 Tables fournit un catalogue REST Apache Iceberg intégré, permettant à Spark de traiter un compartiment de tables (table bucket) comme un entrepôt Iceberg géré tandis que les données restent dans RustFS. Activez un compartiment de tables et connectez le catalogue REST Iceberg de Spark comme décrit dans [S3 Tables](/administration/data/s3-tables) : l’URI du catalogue REST est `http://:9000/iceberg`, le warehouse est le nom du compartiment, et les requêtes de catalogue (AWS Signature Version 4, nom de signature `s3`) comme l’accès aux fichiers S3 utilisent l’adressage de type chemin (path-style). -Selon la matrice de support S3 Tables, validez les versions exactes de Spark et d'Iceberg que vous déployez par rapport au catalogue avant d'adopter ce chemin en production. +Selon la matrice de prise en charge S3 Tables, validez les versions exactes de Spark et d’Iceberg que vous déployez par rapport au catalogue avant d’adopter ce chemin en production. ## 5. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer le dataset et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer le jeu de données et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -199,22 +199,22 @@ docker compose down --volumes ### NumberFormatException: For input string: "60s" -La version de `hadoop-aws` ne correspond pas à la version de Hadoop embarquée dans l'image Spark. Les images Spark 4.x nécessitent `hadoop-aws` 3.4.x ; ce guide épingle `apache/spark:3.5.6` avec `hadoop-aws:3.3.4`. +La version de `hadoop-aws` ne correspond pas à la version de Hadoop embarquée dans l’image Spark. Les images Spark 4.x nécessitent `hadoop-aws` 3.4.x ; ce guide épingle `apache/spark:3.5.6` avec `hadoop-aws:3.3.4`. ### Échecs de connexion à `rustfs:9000` -`fs.s3a.endpoint` est résolu à l'intérieur du réseau Compose. Pour un processus Spark exécuté sur l'hôte, utilisez `http://localhost:9000`. +`fs.s3a.endpoint` est résolu à l’intérieur du réseau Compose. Pour un processus Spark exécuté sur l’hôte, utilisez `http://localhost:9000`. ### Réponses AccessDenied ou 403 -Vérifiez que les réglages du connecteur correspondent aux identifiants RustFS et que la tâche `create-bucket` s'est terminée avec succès : +Vérifiez que les réglages du connecteur correspondent aux identifiants RustFS et que la tâche `create-bucket` s’est terminée avec succès : ```bash docker compose logs create-bucket ``` -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). - Suivez la [documentation Spark](https://spark.apache.org/docs/latest/) pour le structured streaming et les options de sources de données. diff --git a/content/fr/developer/integration/database/duckdb.md b/content/fr/developer/integration/database/duckdb.md index ba5a31dda..655effa7f 100644 --- a/content/fr/developer/integration/database/duckdb.md +++ b/content/fr/developer/integration/database/duckdb.md @@ -1,13 +1,13 @@ --- title: "DuckDB" -description: "Interrogez et écrivez des fichiers Parquet stockés dans le stockage objet RustFS avec DuckDB et son extension httpfs, déployés avec Docker Compose." +description: "Interrogez et écrivez des fichiers Parquet stockés dans le stockage objet RustFS avec DuckDB et son extension httpfs, le tout déployé avec Docker Compose." --- -Ce guide exécute **DuckDB** avec **RustFS** comme stockage compatible S3. Vous allez démarrer les deux services avec Docker Compose, configurer l'extension `httpfs` de DuckDB pour le point de terminaison RustFS, écrire des résultats de requête dans le bucket au format Parquet, les relire, puis vérifier les objets dans RustFS. Le flux a été validé avec l'image `duckdb/duckdb:latest` (v1.5.5) et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide exécute **DuckDB** avec **RustFS** comme stockage compatible S3. Vous allez démarrer les deux services avec Docker Compose, configurer l’extension `httpfs` de DuckDB pour le point de terminaison RustFS, écrire des résultats de requête dans le compartiment au format Parquet, les relire, puis vérifier les objets dans RustFS. Le flux a été validé avec l’image `duckdb/duckdb:latest` (v1.5.5) et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -DuckDB lit et écrit les objets via son [extension `httpfs`](https://duckdb.org/docs/stable/extensions/httpfs/overview), qui implémente l'API S3. Un secret S3 contient le point de terminaison RustFS, les identifiants, l'adressage path-style et le réglage HTTP simple ; les fichiers Parquet se chargent alors depuis et vers des chemins `s3://my-bucket/...` comme des fichiers locaux. +DuckDB lit et écrit les objets via son [extension `httpfs`](https://duckdb.org/docs/stable/extensions/httpfs/overview), qui implémente l’API S3. Un secret S3 contient le point de terminaison RustFS, les identifiants, l’adressage de type chemin (path-style) et le réglage HTTP non chiffré ; les fichiers Parquet se chargent alors depuis et vers des chemins `s3://my-bucket/...` comme des fichiers locaux. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-duckdb cd rustfs-duckdb ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -99,34 +99,34 @@ volumes: rustfs-data: ``` -L'[image `rc`](https://github.com/rustfs/cli) fournit le client en ligne de commande officiel de RustFS. L'initialiseur vérifie l'existence de `my-bucket` avant de le créer, afin que des redémarrages répétés ne suppriment pas les données existantes. L'image `duckdb/duckdb` ne contient que le binaire `/duckdb`, sans shell ; le service définit donc `entrypoint: ["/duckdb"]`. +L’[image `rc`](https://github.com/rustfs/cli) fournit le client en ligne de commande officiel de RustFS. L’initialiseur vérifie l’existence de `my-bucket` avant de le créer, afin que des redémarrages répétés ne suppriment pas les données existantes. L’image `duckdb/duckdb` ne contient que le binaire `/duckdb`, sans shell ; le service définit donc `entrypoint: ["/duckdb"]`. ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -Le service `create-bucket` doit afficher un code de sortie `0`. La console RustFS est disponible à l'adresse `http://localhost:9001/rustfs/console/` pour inspecter le bucket à tout moment. +Le service `create-bucket` doit afficher un code de sortie `0`. La Console RustFS est disponible à l’adresse `http://localhost:9001/rustfs/console/` pour inspecter le compartiment à tout moment. ## 3. Configurer le secret S3 dans DuckDB -Démarrez une session DuckDB interactive : +Démarrez une session DuckDB interactive : ```bash docker compose run --rm duckdb ``` -Installez l'extension et enregistrez le point de terminaison RustFS : +Installez l’extension et enregistrez le point de terminaison RustFS : ```sql INSTALL httpfs; @@ -142,11 +142,11 @@ CREATE SECRET rustfs ( ); ``` -Le point de terminaison est donné sous la forme `host:port` sans schéma. `USE_SSL FALSE` sélectionne HTTP simple à l'intérieur du réseau Compose, et `URL_STYLE 'path'` sélectionne l'adressage path-style, attendu par RustFS. Les secrets ne vivent que le temps de la session — recréez le secret à chaque nouvelle session. +Le point de terminaison est donné sous la forme `host:port` sans schéma. `USE_SSL FALSE` sélectionne HTTP non chiffré à l’intérieur du réseau Compose, et `URL_STYLE 'path'` sélectionne l’adressage de type chemin (path-style), attendu par RustFS. Les secrets ne vivent que le temps de la session — recréez le secret à chaque nouvelle session. ## 4. Écrire des résultats de requête dans RustFS -Écrivez une petite table au format Parquet dans le bucket : +Écrivez une petite table au format Parquet dans le compartiment : ```sql COPY @@ -166,7 +166,7 @@ COPY ## 5. Relire le Parquet depuis RustFS -Interrogez l'objet que vous venez d'écrire comme s'il s'agissait d'un fichier local : +Interrogez l’objet que vous venez d’écrire comme s’il s’agissait d’un fichier local : ```sql SELECT count(*) AS rows, min(id) AS min_id, max(id) AS max_id @@ -182,11 +182,11 @@ FROM read_parquet('s3://my-bucket/duckdb-demo/events.parquet'); └───────┴────────┴────────┘ ``` -Tout objet Parquet du bucket peut être interrogé de cette manière, y compris les fichiers écrits par d'autres systèmes comme OpenObserve, Spark ou Iceberg. +Tout objet Parquet du compartiment peut être interrogé de cette manière, y compris les fichiers écrits par d’autres systèmes comme OpenObserve, Spark ou Iceberg. ## 6. Vérifier les objets dans RustFS -Listez le préfixe via l'image d'initialisation du bucket : +Listez le préfixe via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ @@ -197,19 +197,19 @@ docker compose run --rm --entrypoint /bin/sh create-bucket -c \ [2026-09-20 06:52:45] 5.32 KiB duckdb-demo/events.parquet ``` -Vous pouvez également inspecter le préfixe `duckdb-demo` dans la console RustFS : +Vous pouvez également inspecter le préfixe `duckdb-demo` dans la Console RustFS : -![Le préfixe duckdb-demo dans la console RustFS](./images/rustfs-duckdb-objects.png) +![Le préfixe duckdb-demo dans la Console RustFS](./images/rustfs-duckdb-objects.png) ## 7. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les objets locaux et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les objets locaux et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -217,28 +217,28 @@ docker compose down --volumes ## Dépannage -### DuckDB n'atteint pas RustFS +### DuckDB n’atteint pas RustFS -À l'intérieur du réseau Compose, le point de terminaison est `rustfs:9000`. Pour un processus DuckDB exécuté sur l'hôte, utilisez `localhost:9000` et publiez le port `9000` comme dans le fichier Compose. +À l’intérieur du réseau Compose, le point de terminaison est `rustfs:9000`. Pour un processus DuckDB exécuté sur l’hôte, utilisez `localhost:9000` et publiez le port `9000` comme dans le fichier Compose. -### Erreurs SSL ou de connexion avec un point de terminaison HTTP simple +### Erreurs SSL ou de connexion avec un point de terminaison HTTP non chiffré -`ENDPOINT` ne prend pas de schéma. Si RustFS fonctionne sans TLS, `USE_SSL FALSE` doit être défini dans le secret ; sinon `httpfs` tente HTTPS et échoue avec une erreur de connexion ou de certificat. +`ENDPOINT` ne prend pas de schéma. Si RustFS fonctionne sans TLS, `USE_SSL FALSE` doit être défini dans le secret ; sinon `httpfs` tente HTTPS et échoue avec une erreur de connexion ou de certificat. ### Réponses AccessDenied -Vérifiez que les identifiants du secret correspondent aux identifiants RustFS et que l'initialisation du bucket s'est terminée avec succès : +Vérifiez que les identifiants du secret correspondent aux identifiants RustFS et que l’initialisation du compartiment s’est terminée avec succès : ```bash docker compose logs create-bucket ``` -### Requêtes virtual-host style +### Requêtes en adressage de type hôte virtuel -`URL_STYLE 'path'` est requis pour le point de terminaison du réseau de conteneurs. Les requêtes virtual-host nécessitent une configuration de domaine RustFS (`RUSTFS_SERVER_DOMAINS`) et des enregistrements DNS correspondants, et ne sont pas nécessaires ici. +`URL_STYLE 'path'` est requis pour le point de terminaison du réseau de conteneurs. Les requêtes en adressage de type hôte virtuel nécessitent une configuration de domaine RustFS (`RUSTFS_SERVER_DOMAINS`) et des enregistrements DNS correspondants, et ne sont pas nécessaires ici. -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). - Suivez la [documentation httpfs de DuckDB](https://duckdb.org/docs/stable/extensions/httpfs/overview) pour les options avancées telles que les remplacements de région et les limites de connexion. diff --git a/content/fr/developer/integration/database/influxdb.md b/content/fr/developer/integration/database/influxdb.md index 48a8f6864..3829dcf23 100644 --- a/content/fr/developer/integration/database/influxdb.md +++ b/content/fr/developer/integration/database/influxdb.md @@ -1,13 +1,13 @@ --- title: "InfluxDB" -description: "Exécutez InfluxDB 3 Core avec RustFS comme magasin d'objets S3, déployé avec Docker Compose." +description: "Exécutez InfluxDB 3 Core avec RustFS comme magasin d’objets S3, déployé avec Docker Compose." --- -Ce guide exécute [InfluxDB](https://github.com/influxdata/influxdb) — plus précisément **InfluxDB 3 Core**, la base de données temporelle écrite en Rust avec un moteur de stockage Parquet — avec **RustFS** comme magasin d'objets. Vous allez démarrer InfluxDB avec Docker Compose, écrire du line protocol via l'API HTTP, l'interroger en SQL, vérifier les objets persistés dans RustFS et confirmer que les données survivent à un redémarrage d'InfluxDB. Le flux a été validé avec `influxdb:3-core` (v3.11.5) et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide exécute [InfluxDB](https://github.com/influxdata/influxdb) — plus précisément **InfluxDB 3 Core**, la base de données temporelle écrite en Rust avec un moteur de stockage Parquet — avec **RustFS** comme magasin d’objets. Vous allez démarrer InfluxDB avec Docker Compose, écrire du line protocol via l’API HTTP, l’interroger en SQL, vérifier les objets persistés dans RustFS et confirmer que les données survivent à un redémarrage d’InfluxDB. Le flux a été validé avec `influxdb:3-core` (v3.11.5) et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -InfluxDB 3 Core conserve son catalogue, son journal d'écriture anticipée (WAL) et ses fichiers de données Parquet dans le magasin d'objets configuré. Les écritures arrivent d'abord dans le WAL et sont persistées vers RustFS, de sorte que chaque écriture survit à un redémarrage avant même que la compaction ne produise des fichiers Parquet. Le serveur utilise par défaut un adressage path-style vers le point de terminaison configuré. +InfluxDB 3 Core conserve son catalogue, son journal d’écriture anticipée (WAL) et ses fichiers de données Parquet dans le magasin d’objets configuré. Les écritures arrivent d’abord dans le WAL et sont persistées vers RustFS, de sorte que chaque écriture survit à un redémarrage avant même que la compaction ne produise des fichiers Parquet. Le serveur utilise par défaut un adressage de type chemin (path-style) vers le point de terminaison configuré. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-influxdb cd rustfs-influxdb ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -115,26 +115,26 @@ volumes: rustfs-data: ``` -`--object-store s3` avec `--aws-endpoint` route toutes les écritures de catalogue, de WAL et de Parquet vers RustFS. InfluxDB utilise par défaut un adressage path-style vers le point de terminaison, et `--aws-allow-http` autorise HTTP simple à l'intérieur du réseau Compose. +`--object-store s3` avec `--aws-endpoint` route toutes les écritures de catalogue, de WAL et de Parquet vers RustFS. InfluxDB utilise par défaut un adressage de type chemin (path-style) vers le point de terminaison, et `--aws-allow-http` autorise HTTP non chiffré à l’intérieur du réseau Compose. ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -## 3. Créer le token d'administration +## 3. Créer le token d’administration -InfluxDB 3 Core protège chaque requête API avec un token porteur. Créez le token d'administration une fois après le premier démarrage et conservez la valeur affichée : +InfluxDB 3 Core protège chaque requête API avec un token porteur. Créez le token d’administration une fois après le premier démarrage et conservez la valeur affichée : ```bash docker compose exec influxdb3 influxdb3 create token --admin @@ -146,13 +146,13 @@ Token: :::note[Création du token] -La valeur du token n'est affichée qu'une seule fois et ne peut pas être récupérée ultérieurement. Si le nom du token existe déjà (HTTP 409), le nœud possède des métadonnées — repartez d'un préfixe de bucket neuf ou supprimez le préfixe du nœud dans le bucket avant de réessayer. +La valeur du token n’est affichée qu’une seule fois et ne peut pas être récupérée ultérieurement. Si le nom du token existe déjà (HTTP 409), le nœud possède des métadonnées — repartez d’un préfixe de compartiment neuf ou supprimez le préfixe du nœud dans le compartiment avant de réessayer. -::: +:: : ## 4. Écrire du line protocol -Envoyez un lot de mesures CPU en line protocol vers la base `rustfs_demo` : +Envoyez un lot de mesures CPU en line protocol vers la base `rustfs_demo` : ```bash python3 - <<'PY' @@ -182,7 +182,7 @@ write: 204 ## 5. Interroger en SQL -Interrogez la mesure via l'API SQL : +Interrogez la mesure via l’API SQL : ```bash curl -sG "http://localhost:8181/api/v3/query_sql" \ @@ -198,14 +198,14 @@ curl -sG "http://localhost:8181/api/v3/query_sql" \ ## 6. Vérifier les objets dans RustFS -Listez le préfixe du nœud via l'image d'initialisation du bucket : +Listez le préfixe du nœud via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ '/usr/bin/rc alias set rustfs http://rustfs:9000 "$RUSTFS_ACCESS_KEY" "$RUSTFS_SECRET_KEY" >/dev/null && /usr/bin/rc ls rustfs/my-bucket/influxdb-demo --recursive' ``` -Le catalogue, le WAL et ensuite les fichiers de données Parquet résident sous le préfixe identifiant le nœud : +Le catalogue, le WAL et ensuite les fichiers de données Parquet résident sous le préfixe identifiant le nœud : ```text [2026-09-20 23:18:28] 105 B influxdb-demo/catalog/v3/snapshot @@ -213,13 +213,13 @@ Le catalogue, le WAL et ensuite les fichiers de données Parquet résident sous [2026-09-20 23:20:19] 31 B influxdb-demo/table-index-conversion-completed ``` -Vous pouvez également parcourir le préfixe dans la console RustFS : +Vous pouvez également parcourir le préfixe dans la Console RustFS : -![Le préfixe du nœud InfluxDB stocké dans la console RustFS](./images/rustfs-influxdb-objects.png) +![Le préfixe du nœud InfluxDB stocké dans la Console RustFS](./images/rustfs-influxdb-objects.png) ## 7. Confirmer la persistance après un redémarrage -Redémarrez InfluxDB et répétez la requête SQL : +Redémarrez InfluxDB et répétez la requête SQL : ```bash docker compose restart influxdb @@ -234,17 +234,17 @@ curl -sG "http://localhost:8181/api/v3/query_sql" \ [{"cnt":30}] ``` -Le compteur est inchangé car le catalogue et le WAL ont été rejoués depuis RustFS — le magasin d'objets est la couche de persistance, exactement comme dans les topologies de production. +Le compteur est inchangé car le catalogue et le WAL ont été rejoués depuis RustFS — le magasin d’objets est la couche de persistance, exactement comme dans les topologies de production. ## 8. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les données stockées et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les données stockées et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -252,17 +252,17 @@ docker compose down --volumes ## Dépannage -### "the request was not authenticated" sur chaque requête +### « the request was not authenticated » sur chaque requête -InfluxDB 3 Core exige le token porteur d'administration sur les requêtes API. Créez-le une fois avec `influxdb3 create token --admin` et envoyez-le sous la forme `Authorization: Bearer `. +InfluxDB 3 Core exige le token porteur d’administration sur les requêtes API. Créez-le une fois avec `influxdb3 create token --admin` et envoyez-le sous la forme `Authorization: Bearer `. -### "token name already exists" lors de la création du token d'administration +### « token name already exists » lors de la création du token d’administration -Le nœud possède déjà un token d'administration, et la valeur ne peut pas être récupérée. Supprimez le préfixe du nœud dans le bucket (par exemple `influxdb-demo/`) pendant que le conteneur est arrêté, redémarrez-le, puis créez un nouveau token. +Le nœud possède déjà un token d’administration, et la valeur ne peut pas être récupérée. Supprimez le préfixe du nœud dans le compartiment (par exemple `influxdb-demo/`) pendant que le conteneur est arrêté, redémarrez-le, puis créez un nouveau token. ### Réponses AccessDenied ou 403 -Vérifiez que les identifiants du fichier Compose correspondent aux identifiants RustFS et que la tâche `create-bucket` s'est terminée avec succès : +Vérifiez que les identifiants du fichier Compose correspondent aux identifiants RustFS et que la tâche `create-bucket` s’est terminée avec succès : ```bash docker compose logs create-bucket @@ -270,10 +270,10 @@ docker compose logs create-bucket ### Erreurs de connexion ou de certificat -`--aws-endpoint` prend une URL complète ; `--aws-allow-http` autorise HTTP simple pour le point de terminaison du réseau de conteneurs. À l'intérieur du réseau Compose, utilisez `http://rustfs:9000` ; depuis l'hôte, `http://localhost:9000`. +`--aws-endpoint` prend une URL complète ; `--aws-allow-http` autorise HTTP non chiffré pour le point de terminaison du réseau de conteneurs. À l’intérieur du réseau Compose, utilisez `http://rustfs:9000` ; depuis l’hôte, `http://localhost:9000`. -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). -- Suivez la [documentation InfluxDB 3 Core](https://docs.influxdata.com/influxdb3/core/) pour connecter telegraf ou les API d'écriture comme producteurs de données. +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). +- Suivez la [documentation InfluxDB 3 Core](https://docs.influxdata.com/influxdb3/core/) pour connecter telegraf ou les API d’écriture comme producteurs de données. diff --git a/content/fr/developer/integration/database/trino.md b/content/fr/developer/integration/database/trino.md index 9e04da2ac..3291f567f 100644 --- a/content/fr/developer/integration/database/trino.md +++ b/content/fr/developer/integration/database/trino.md @@ -1,13 +1,13 @@ --- title: "Trino" -description: "Interrogez des données CSV et Parquet stockées dans le stockage objet RustFS avec Trino et le file metastore du connecteur hive." +description: "Interrogez des données CSV et Parquet stockées dans le stockage objet RustFS avec Trino et le metastore fichier du connecteur Hive." --- -Ce guide connecte [Trino](https://github.com/trinodb/trino) — le moteur de requêtes SQL distribué — à **RustFS** via le connecteur hive avec son metastore basé sur les fichiers et le système de fichiers S3 natif. Vous allez créer un schéma et une table, insérer des lignes, les relire, puis vérifier les objets dans RustFS. Les métadonnées et les fichiers de données résident tous deux dans RustFS. Le flux a été validé avec `trinodb/trino:435` et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide connecte [Trino](https://github.com/trinodb/trino) — le moteur de requêtes SQL distribué — à **RustFS** via le connecteur Hive avec son metastore basé sur les fichiers et le système de fichiers S3 natif. Vous allez créer un schéma et une table, insérer des lignes, les relire, puis vérifier les objets dans RustFS. Les métadonnées et les fichiers de données résident tous deux dans RustFS. Le flux a été validé avec `trinodb/trino:435` et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -17,27 +17,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -Le connecteur hive avec `hive.metastore=file` conserve les métadonnées de schémas et de tables sous forme d'objets JSON sous le répertoire du catalogue, et le système de fichiers S3 natif (`fs.s3.enabled`) stocke les métadonnées et les données dans RustFS avec un adressage path-style en HTTP simple. +Le connecteur Hive avec `hive.metastore=file` conserve les métadonnées de schémas et de tables sous forme d’objets JSON sous le répertoire du catalogue, et le système de fichiers S3 natif (`fs.s3.enabled`) stocke les métadonnées et les données dans RustFS avec un adressage de type chemin (path-style) en HTTP non chiffré. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-trino cd rustfs-trino ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez la configuration du catalogue pour Trino : +Créez la configuration du catalogue pour Trino : ```ini title="hive.properties" connector.name=hive @@ -51,9 +51,9 @@ s3.aws-access-key= s3.aws-secret-key= ``` -`hive.metastore.catalog.dir` pointe le file metastore dans le bucket : métadonnées et données résident donc dans RustFS. `fs.s3.enabled` active le système de fichiers S3 natif ; `s3.path-style-access` est requis pour le point de terminaison du réseau de conteneurs. +`hive.metastore.catalog.dir` place le metastore fichier dans le compartiment : les métadonnées et les données résident donc dans RustFS. `fs.s3.enabled` active le système de fichiers S3 natif ; `s3.path-style-access` est requis pour le point de terminaison du réseau de conteneurs. -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -121,20 +121,20 @@ volumes: ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -Trino est démarré quand le journal du serveur indique `SERVER STARTED`. Le conteneur s'exécute sous l'utilisateur `trino` (uid 1000) ; assurez-vous que le volume du metastore est inscriptible : +Trino est démarré quand le journal du serveur indique `SERVER STARTED`. Le conteneur s’exécute sous l’utilisateur `trino` (uid 1000) ; assurez-vous que le volume du metastore est inscriptible : ```bash docker compose exec trino id @@ -143,14 +143,14 @@ docker compose exec trino ls -la /data/metastore ## 3. Créer un schéma et une table -Créez le schéma sans location explicite — Trino le place sous le répertoire du catalogue dans RustFS : +Créez le schéma sans emplacement explicite — Trino le place sous le répertoire du catalogue dans RustFS : ```bash docker compose exec trino trino --execute \ "CREATE SCHEMA hive.demo" ``` -Créez une table et insérez cinq lignes : +Créez une table et insérez cinq lignes : ```bash docker compose exec trino trino --execute \ @@ -166,7 +166,7 @@ INSERT: 5 rows ## 4. Interroger les données -Relisez les lignes : +Relisez les lignes : ```bash docker compose exec trino trino --execute \ @@ -183,7 +183,7 @@ docker compose exec trino trino --execute \ ## 5. Vérifier les objets dans RustFS -Listez le préfixe du metastore via l'image d'initialisation du bucket : +Listez le préfixe du metastore via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ @@ -197,25 +197,25 @@ docker compose run --rm --entrypoint /bin/sh create-bucket -c \ [2026-09-21 01:55:25] 432 B trino-metastore/demo/events/20260921_..._cb761cec-...parquet ``` -Vous pouvez également parcourir le préfixe dans la console RustFS : +Vous pouvez également parcourir le préfixe dans la Console RustFS : -![Les objets de métadonnées et de données Trino stockés dans la console RustFS](./images/rustfs-trino-objects.png) +![Les objets de métadonnées et de données Trino stockés dans la Console RustFS](./images/rustfs-trino-objects.png) ## 6. Utiliser RustFS S3 Tables -RustFS S3 Tables fournit un catalogue REST Apache Iceberg intégré, permettant à Trino de traiter un table bucket comme un entrepôt Iceberg géré tandis que les données restent dans RustFS. Activez un table bucket et connectez le connecteur Iceberg de Trino au catalogue REST comme décrit dans [S3 Tables](/administration/data/s3-tables) : l'URI du catalogue REST est `http://:9000/iceberg`, le warehouse est le nom du bucket, et les requêtes de catalogue (AWS Signature Version 4, nom de signature `s3`) comme l'accès aux fichiers S3 utilisent l'adressage path-style. +RustFS S3 Tables fournit un catalogue REST Apache Iceberg intégré, permettant à Trino de traiter un compartiment de tables (table bucket) comme un entrepôt Iceberg géré tandis que les données restent dans RustFS. Activez un compartiment de tables et connectez le connecteur Iceberg de Trino au catalogue REST comme décrit dans [S3 Tables](/administration/data/s3-tables) : l’URI du catalogue REST est `http://:9000/iceberg`, le warehouse est le nom du compartiment, et les requêtes de catalogue (AWS Signature Version 4, nom de signature `s3`) comme l’accès aux fichiers S3 utilisent l’adressage de type chemin (path-style). -Selon la matrice de support S3 Tables, Trino a fait l'objet d'une sonde en lecture seule contre le catalogue ; validez la compatibilité en écriture et la version exacte de Trino que vous déployez avant d'adopter ce chemin en production. +Selon la matrice de prise en charge S3 Tables, Trino a fait l’objet d’une vérification en lecture seule face au catalogue ; validez la compatibilité en écriture et la version exacte de Trino que vous déployez avant d’adopter ce chemin en production. ## 7. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les métadonnées et données stockées et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les métadonnées et données stockées et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -225,11 +225,11 @@ docker compose down --volumes ### Erreurs de configuration pour `fs.native-s3.enabled` ou `fs.s3.enabled` -Le nom de la propriété du système de fichiers S3 natif a changé selon les versions de Trino : Trino 435 utilise `fs.native-s3.enabled`, les versions plus récentes `fs.s3.enabled`. Ce guide épingle `trinodb/trino:435`, utilisez donc `fs.native-s3.enabled`. +Le nom de la propriété du système de fichiers S3 natif a changé selon les versions de Trino : Trino 435 utilise `fs.native-s3.enabled`, les versions plus récentes `fs.s3.enabled`. Ce guide épingle `trinodb/trino:435`, utilisez donc `fs.native-s3.enabled`. -### "Table directory must be ..." lors de la création d'une table +### « Table directory must be ... » lors de la création d’une table -Avec le file metastore, les locations de tables doivent rester sous `hive.metastore.catalog.dir`. Créez le schéma sans location explicite, ou pointez la location du schéma vers un répertoire du même préfixe de bucket. +Avec le metastore fichier, les emplacements des tables doivent rester sous `hive.metastore.catalog.dir`. Créez le schéma sans emplacement explicite, ou pointez l’emplacement du schéma vers un répertoire du même préfixe de compartiment. ### Hive CSV storage format only supports VARCHAR @@ -237,14 +237,14 @@ Le format CSV rejette les colonnes non textuelles. Utilisez `format = 'parquet'` ### Réponses AccessDenied ou 403 -Vérifiez que les identifiants de `hive.properties` correspondent aux identifiants RustFS et que la tâche `create-bucket` s'est terminée avec succès : +Vérifiez que les identifiants de `hive.properties` correspondent aux identifiants RustFS et que la tâche `create-bucket` s’est terminée avec succès : ```bash docker compose logs create-bucket ``` -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). - Suivez la [documentation Trino](https://trino.io/docs/current/) pour connecter des outils BI et ajouter des catalogues de stockage objet. diff --git a/content/fr/developer/integration/devops/index.md b/content/fr/developer/integration/devops/index.md index 7ca9dbaf0..1d4714875 100644 --- a/content/fr/developer/integration/devops/index.md +++ b/content/fr/developer/integration/devops/index.md @@ -1,9 +1,9 @@ --- title: "DevOps" -description: "Connectez les plateformes DevOps et l'outillage d'infrastructure à RustFS via des interfaces de stockage objet compatibles S3." +description: "Connectez les plateformes DevOps et l’outillage d’infrastructure à RustFS via des interfaces de stockage objet compatibles S3." --- -Utilisez **RustFS** comme couche de stockage objet pour les plateformes DevOps et l'outillage d'infrastructure qui prennent en charge un point de terminaison compatible S3. +Utilisez **RustFS** comme couche de stockage objet pour les plateformes DevOps et l’outillage d’infrastructure qui prennent en charge un point de terminaison compatible S3. ## Plateformes et outils @@ -13,4 +13,4 @@ Utilisez **RustFS** comme couche de stockage objet pour les plateformes DevOps e - [Jenkins](./jenkins.md) - [Terraform](./terraform.md) -Conservez les artefacts, l'état et les données de télémétrie dans des buckets dédiés et limitez les identifiants aux opérations de bucket requises. +Conservez les artefacts, l’état et les données de télémétrie dans des compartiments dédiés et limitez les identifiants aux opérations de compartiment requises. diff --git a/content/fr/developer/integration/index.md b/content/fr/developer/integration/index.md index 303dfb7fb..d4d45de6b 100644 --- a/content/fr/developer/integration/index.md +++ b/content/fr/developer/integration/index.md @@ -1,22 +1,22 @@ --- -title: "Integration" -description: "Intégrez RustFS avec des reverse proxies, des outils de sauvegarde, des systèmes d'analyse de données, des plateformes d'IA et cloud native, des plateformes d'observabilité, des registries de conteneurs et des outils DevOps." +title: "Intégrations" +description: "Intégrez RustFS à des reverse proxies, des outils de sauvegarde, des systèmes d’analyse de données, des plateformes d’IA et cloud native, des plateformes d’observabilité, des registres de conteneurs et des outils DevOps." --- -Utilisez cette section pour connecter **RustFS** à des plateformes d'infrastructure et d'applications via son API compatible S3. +Utilisez cette section pour connecter **RustFS** à des plateformes d’infrastructure et d’applications via son API compatible avec S3. -## Integration categories +## Catégories d’intégration -- [Reverse Proxy](./reverse-proxy/index.md) couvre Nginx, Traefik, Caddy, HAProxy et Envoy. -- [Backup](./backup/index.md) couvre Kopia, Longhorn, Restic et Velero. -- [IA](./ai/index.md) couvre les plateformes d'IA incluant Ray et vLLM. -- [Database](./database/index.md) covers ClickHouse, Databend, Doris, DuckDB, InfluxDB, LanceDB, Milvus, Trino, and Vitess. -- [Big Data](./big-data/index.md) covers Airflow, AutoMQ, Delta Lake, DolphinScheduler, Flink, Hive, Hudi, Iceberg, Kafka, Paimon, PyIceberg, SeaTunnel, Spark, and Zeppelin. -- [Storage](./storage/index.md) covers Alluxio, lakeFS, OpenDAL, SFTPGo, s3fs, and ZeroFS. -- [Cloud Native](./cloud-native/index.md) couvre Cortex, Flux et celld. -- [Observabilité](./observability/index.md) couvre les systèmes de télémétrie incluant Fluentd, GreptimeDB, Loki, OpenObserve, OpenTelemetry, Tempo, Thanos et VictoriaMetrics. +- [Proxy inverse](./reverse-proxy/index.md) couvre Nginx, Traefik, Caddy, HAProxy et Envoy. +- [Sauvegarde](./backup/index.md) couvre Kopia, Longhorn, Restic et Velero. +- [IA](./ai/index.md) couvre les plateformes d’IA, notamment MLflow, Ray et vLLM. +- [Bases de données](./database/index.md) couvre ClickHouse, Databend, Doris, DuckDB, InfluxDB, LanceDB, Milvus, Trino et Vitess. +- [Analyse de données](./big-data/index.md) couvre Airflow, AutoMQ, Delta Lake, DolphinScheduler, Flink, Hive, Hudi, Iceberg, Kafka, Paimon, PyIceberg, SeaTunnel, Spark et Zeppelin. +- [Stockage](./storage/index.md) couvre Alluxio, lakeFS, OpenDAL, SFTPGo, s3fs et ZeroFS. +- [Cloud native](./cloud-native/index.md) couvre Cortex, Flux et celld. +- [Observabilité](./observability/index.md) couvre les systèmes de télémétrie, notamment Fluentd, GreptimeDB, Loki, OpenObserve, OpenTelemetry, Tempo, Thanos et VictoriaMetrics. - [Autres](./others/index.md) couvre le SDK capo, rclone, JuiceFS, Nextcloud et tusd. - [Registre](./registry/index.md) couvre Docker Registry et Harbor. - [DevOps](./devops/index.md) couvre Elasticsearch, Gitea, Jenkins, OpenSearch et Terraform. -Chaque guide indique le point de terminaison RustFS et les exigences d'adressage à utiliser lors de la configuration du système intégré. \ No newline at end of file +Chaque guide indique le point de terminaison RustFS et les exigences d’adressage à utiliser lors de la configuration du système intégré. diff --git a/content/fr/developer/integration/meta.json b/content/fr/developer/integration/meta.json index 19173e046..1887ee4c0 100644 --- a/content/fr/developer/integration/meta.json +++ b/content/fr/developer/integration/meta.json @@ -1,5 +1,5 @@ { - "title": "Integration", + "title": "Intégrations", "pages": [ "reverse-proxy", "backup", diff --git a/content/fr/developer/integration/observability/index.md b/content/fr/developer/integration/observability/index.md index f798d27a5..f7abc4879 100644 --- a/content/fr/developer/integration/observability/index.md +++ b/content/fr/developer/integration/observability/index.md @@ -1,9 +1,9 @@ --- title: "Observabilité" -description: "Connectez les plateformes d'observabilité à RustFS via des interfaces de stockage objet compatibles S3." +description: "Connectez les plateformes d’observabilité à RustFS via des interfaces de stockage objet compatibles S3." --- -Utilisez **RustFS** comme couche de stockage objet pour les plateformes d'observabilité qui prennent en charge un point de terminaison compatible S3. +Utilisez **RustFS** comme couche de stockage objet pour les plateformes d’observabilité qui prennent en charge un point de terminaison compatible S3. ## Plateformes @@ -16,4 +16,4 @@ Utilisez **RustFS** comme couche de stockage objet pour les plateformes d'observ - [Thanos](./thanos.md) - [VictoriaMetrics](./victoriametrics.md) -Conservez les données de télémétrie dans un bucket dédié et limitez les identifiants aux opérations de bucket requises. +Conservez les données de télémétrie dans un compartiment dédié et limitez les identifiants aux opérations de compartiment requises. diff --git a/content/fr/developer/integration/observability/loki.md b/content/fr/developer/integration/observability/loki.md index 644603762..228e9b8b6 100644 --- a/content/fr/developer/integration/observability/loki.md +++ b/content/fr/developer/integration/observability/loki.md @@ -3,11 +3,11 @@ title: "Loki" description: "Exécutez Grafana Loki avec RustFS comme backend de stockage objet S3, déployé avec Docker Compose." --- -Ce guide exécute [Grafana Loki](https://github.com/grafana/loki) — le système d'agrégation de journaux de Grafana Labs — avec **RustFS** comme backend de stockage objet. Vous allez démarrer un Loki single-binary avec Docker Compose, pousser des flux de journaux via l'API HTTP, les interroger, puis vérifier que les chunks de journaux sont stockés comme objets dans RustFS. Le flux a été validé avec `grafana/loki:latest` (v3.7.8) et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide exécute [Grafana Loki](https://github.com/grafana/loki) — le système d’agrégation de journaux de Grafana Labs — avec **RustFS** comme backend de stockage objet. Vous allez démarrer Loki en mode binaire unique (single-binary) avec Docker Compose, pousser des flux de journaux via l’API HTTP, les interroger, puis vérifier que les chunks de journaux sont stockés comme objets dans RustFS. Le flux a été validé avec `grafana/loki:latest` (v3.7.8) et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -Loki ingère les flux de journaux dans un chunk en mémoire et un journal d'écriture anticipée, transfère les chunks compressés vers le stockage objet dès qu'un flux devient inactif, et envoie les fichiers d'index TSDB vers le même bucket. Les requêtes localisent les chunks via l'index et les lisent depuis le stockage objet. +Loki ingère les flux de journaux dans un chunk en mémoire et un journal d’écriture anticipée, transfère les chunks compressés vers le stockage objet dès qu’un flux devient inactif, et envoie les fichiers d’index TSDB vers le même compartiment. Les requêtes localisent les chunks via l’index et les lisent depuis le stockage objet. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-loki cd rustfs-loki ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez la configuration Loki — un déploiement single-binary avec le schéma TSDB et le backend S3 pointant vers RustFS : +Créez la configuration Loki — un déploiement en binaire unique (single-binary) avec le schéma TSDB et le backend S3 pointant vers RustFS : ```yaml title="loki.yml" auth_enabled: false @@ -78,9 +78,9 @@ ruler: alertmanager_url: http://localhost:9093 ``` -`s3forcepathstyle: true` et `insecure: true` sélectionnent l'adressage path-style en HTTP simple, attendu par RustFS pour le point de terminaison du réseau de conteneurs. `chunk_idle_period` et `max_chunk_age` sont réduits pour qu'une exécution de vérification n'attende pas les 30 minutes par défaut avant le transfert des chunks. +`s3forcepathstyle: true` et `insecure: true` sélectionnent l’adressage de type chemin (path-style) en HTTP non chiffré, attendu par RustFS pour le point de terminaison du réseau de conteneurs. `chunk_idle_period` et `max_chunk_age` sont réduits pour qu’une exécution de vérification n’attende pas les 30 minutes par défaut avant le transfert des chunks. -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -149,20 +149,20 @@ volumes: ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -Loki est prêt quand le point de terminaison de readiness répond : +Loki est prêt quand le point de terminaison de readiness répond : ```bash curl -s http://localhost:3100/ready @@ -174,7 +174,7 @@ ready ## 3. Pousser des flux de journaux -Envoyez un lot d'entrées de journaux via l'API de push : +Envoyez un lot d’entrées de journaux via l’API de push : ```bash python3 - <<'PY' @@ -212,7 +212,7 @@ push: 204 ## 4. Interroger les journaux -Interrogez le flux via l'API de requête par plage : +Interrogez le flux via l’API de requête par plage : ```bash curl -sG "http://localhost:3100/loki/api/v1/query_range" \ @@ -222,7 +222,7 @@ curl -sG "http://localhost:3100/loki/api/v1/query_range" \ | python3 -m json.tool | head -20 ``` -La réponse contient les lignes poussées : +La réponse contient les lignes poussées : ```text "values": [ @@ -234,33 +234,33 @@ La réponse contient les lignes poussées : ## 5. Vérifier les chunks dans RustFS -Avec `chunk_idle_period: 30s`, l'ingester transfère le flux vers le stockage objet environ une minute après la dernière ligne. Listez le préfixe du tenant via l'image d'initialisation du bucket : +Avec `chunk_idle_period: 30s`, l’ingester transfère le flux vers le stockage objet environ une minute après la dernière ligne. Listez le préfixe du tenant via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ '/usr/bin/rc alias set rustfs http://rustfs:9000 "$RUSTFS_ACCESS_KEY" "$RUSTFS_SECRET_KEY" >/dev/null && /usr/bin/rc ls rustfs/my-bucket/fake --recursive' ``` -`fake` est le tenant utilisé par Loki quand `auth_enabled` vaut `false` ; chaque objet est un chunk de journal compressé : +`fake` est le tenant utilisé par Loki quand `auth_enabled` vaut `false` ; chaque objet est un chunk de journal compressé : ```text [2026-09-20 14:48:57] 398 B fake/51610c9b43452db8/1a0bf49f028:1a0bf49f028:f0ed52f7 [2026-09-20 14:49:33] 670 B fake/cd916b27d004a688/1a0bf4a03ca:1a0bf4a4e03:1376b308 ``` -Vous pouvez également parcourir le préfixe dans la console RustFS : +Vous pouvez également parcourir le préfixe dans la Console RustFS : -![Chunks de journaux Loki stockés dans la console RustFS](./images/rustfs-loki-chunks.png) +![Chunks de journaux Loki stockés dans la Console RustFS](./images/rustfs-loki-chunks.png) ## 6. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les journaux stockés et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les journaux stockés et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -268,28 +268,28 @@ docker compose down --volumes ## Dépannage -### Loki bride les écritures et signale "disk usage exceeded threshold" +### Loki bride les écritures et signale « disk usage exceeded threshold » -Loki surveille le disque qui héberge son journal d'écriture anticipée et bride l'ingester lorsque l'utilisation dépasse 90 pour cent. Assurez-vous que le volume derrière `path_prefix` dispose de suffisamment d'espace libre, ou exécutez le conteneur avec un tmpfs pour le WAL lorsque la machine est par ailleurs saine. +Loki surveille le disque qui héberge son journal d’écriture anticipée et bride l’ingester lorsque l’utilisation dépasse 90 pour cent. Assurez-vous que le volume derrière `path_prefix` dispose de suffisamment d’espace libre, ou exécutez le conteneur avec un tmpfs pour le WAL lorsque la machine est par ailleurs saine. -### L'anneau signale des erreurs de connexion au port 8500 +### L’anneau signale des erreurs de connexion au port 8500 -Le magasin clé-valeur par défaut de l'anneau est Consul. Pour un single-binary, définissez `common.ring.kvstore.store: inmemory`, comme montré dans la configuration ci-dessus. +Le magasin clé-valeur par défaut de l’anneau est Consul. Pour un déploiement en binaire unique (single-binary), définissez `common.ring.kvstore.store: inmemory`, comme montré dans la configuration ci-dessus. -### Les requêtes de push échouent avec "Ingester is shutting down" +### Les requêtes de push échouent avec « Ingester is shutting down » -L'ingester n'a jamais atteint un état en cours d'exécution — généralement un conteneur restant d'un démarrage antérieur en échec. Supprimez le conteneur avec `docker compose down` et redémarrez-le, ou consultez les journaux pour identifier l'erreur de stockage sous-jacente. +L’ingester n’a jamais atteint un état en cours d’exécution — généralement un conteneur restant d’un démarrage antérieur en échec. Supprimez le conteneur avec `docker compose down` et redémarrez-le, ou consultez les journaux pour identifier l’erreur de stockage sous-jacente. ### Réponses AccessDenied ou 403 -Vérifiez que les identifiants de `loki.yml` correspondent aux identifiants RustFS et que la tâche `create-bucket` s'est terminée avec succès : +Vérifiez que les identifiants de `loki.yml` correspondent aux identifiants RustFS et que la tâche `create-bucket` s’est terminée avec succès : ```bash docker compose logs create-bucket ``` -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). -- Suivez la [documentation Grafana Loki](https://grafana.com/docs/loki/latest/) pour connecter Promtail, Alloy ou l'OpenTelemetry Collector comme producteurs de journaux. +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). +- Suivez la [documentation Grafana Loki](https://grafana.com/docs/loki/latest/) pour connecter Promtail, Alloy ou l’OpenTelemetry Collector comme producteurs de journaux. diff --git a/content/fr/developer/integration/observability/openobserve.md b/content/fr/developer/integration/observability/openobserve.md index 8f1cc0687..b2defd4a6 100644 --- a/content/fr/developer/integration/observability/openobserve.md +++ b/content/fr/developer/integration/observability/openobserve.md @@ -1,25 +1,25 @@ --- title: "OpenObserve" -description: "Exécutez OpenObserve avec RustFS comme backend de stockage objet compatible S3 via Docker Compose, et vérifiez l'ingestion, le stockage et la recherche de journaux." +description: "Exécutez OpenObserve avec RustFS comme backend de stockage objet compatible S3 via Docker Compose, et vérifiez l’ingestion, le stockage et la recherche de journaux." --- -Ce guide exécute **OpenObserve** avec **RustFS** comme backend de stockage objet. Vous allez démarrer les deux services avec Docker Compose, ingérer des enregistrements de journaux dans OpenObserve, les transférer vers le stockage objet, vérifier les fichiers Parquet résultants dans RustFS, puis les interroger à nouveau via l'interface OpenObserve et l'API de recherche. +Ce guide exécute **OpenObserve** avec **RustFS** comme backend de stockage objet. Vous allez démarrer les deux services avec Docker Compose, ingérer des enregistrements de journaux dans OpenObserve, les transférer vers le stockage objet, vérifier les fichiers Parquet résultants dans RustFS, puis les interroger à nouveau via l’interface OpenObserve et l’API de recherche. -Vous avez besoin de Docker avec le plugin Compose et d'une machine capable d'exécuter trois conteneurs. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose et d’une machine capable d’exécuter trois conteneurs. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. ## Présentation du produit ### OpenObserve -[OpenObserve](https://openobserve.ai/) est une plateforme d'observabilité open source pour les journaux, les métriques, les traces et le suivi des utilisateurs réels. Elle sépare le stockage du calcul : les données ingérées arrivent d'abord dans un journal d'écriture anticipée (WAL) local, puis sont converties en fichiers Parquet avec index plein texte et téléversées vers le stockage objet, qui constitue la seule couche de données persistante. Les requêtes localisent les fichiers Parquet distants via les métadonnées de liste de fichiers et les téléchargent à la demande dans un cache local. +[OpenObserve](https://openobserve.ai/) est une plateforme d’observabilité open source pour les journaux, les métriques, les traces et le suivi des utilisateurs réels. Elle sépare le stockage du calcul : les données ingérées arrivent d’abord dans un journal d’écriture anticipée (WAL) local, puis sont converties en fichiers Parquet avec index plein texte et téléversées vers le stockage objet, qui constitue la seule couche de données persistante. Les requêtes localisent les fichiers Parquet distants via les métadonnées de liste de fichiers et les téléchargent à la demande dans un cache local. -OpenObserve accède au stockage objet via le client Rust `object_store`. Par défaut, il utilise des requêtes **path-style** avec signature SigV4, de sorte que tout point de terminaison compatible S3 fonctionne — y compris RustFS — dès lors que vous fournissez l'URL du point de terminaison, la région, les identifiants et le nom du bucket. +OpenObserve accède au stockage objet via le client Rust `object_store`. Par défaut, il utilise des requêtes en adressage de type chemin (**path-style**) avec signature SigV4, de sorte que tout point de terminaison compatible S3 fonctionne — y compris RustFS — dès lors que vous fournissez l’URL du point de terminaison, la région, les identifiants et le nom du compartiment. ### RustFS -RustFS est un système de stockage objet distribué écrit en Rust. Il implémente l'API Amazon S3, y compris la signature SigV4, l'adressage path-style et virtual-host, ainsi que les téléversements en plusieurs parties, et il est livré avec une console web et un IAM multi-locataires. RustFS fonctionne d'un nœud unique jusqu'à des clusters multi-nœuds et couvre les opérations S3 dont OpenObserve a besoin pour ses données de télémétrie. +RustFS est un système de stockage objet distribué écrit en Rust. Il implémente l’API Amazon S3, y compris la signature SigV4, l’adressage de type chemin (path-style) et de type hôte virtuel (virtual-host), ainsi que les chargements partitionnés, et il est livré avec une console web et un IAM multi-locataires. RustFS fonctionne d’un nœud unique jusqu’à des clusters multi-nœuds et couvre les opérations S3 dont OpenObserve a besoin pour ses données de télémétrie. -### Fonctionnement de l'intégration +### Fonctionnement de l’intégration ```mermaid flowchart LR @@ -30,21 +30,21 @@ flowchart LR Init["init-bucket job"] -->|create my-bucket| RustFS ``` -- **Chemin d'écriture** : lorsque les données atteignent un seuil de taille ou `ZO_MAX_FILE_RETENTION_TIME` (600 secondes par défaut), OpenObserve fusionne les enregistrements du WAL en fichiers Parquet, les téléverse sous le préfixe `files/` du bucket et les enregistre dans sa liste de fichiers. -- **Chemin de requête** : l'API de recherche résout les fichiers pour la plage de temps demandée, les télécharge depuis RustFS dans le cache local, puis exécute la requête. +- **Chemin d’écriture** : lorsque les données atteignent un seuil de taille ou `ZO_MAX_FILE_RETENTION_TIME` (600 secondes par défaut), OpenObserve fusionne les enregistrements du WAL en fichiers Parquet, les téléverse sous le préfixe `files/` du compartiment et les enregistre dans sa liste de fichiers. +- **Chemin de requête** : l’API de recherche résout les fichiers pour la plage de temps demandée, les télécharge depuis RustFS dans le cache local, puis exécute la requête. -## Étapes d'intégration +## Étapes d’intégration ### 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-openobserve cd rustfs-openobserve ``` -Créez un fichier d'environnement et remplacez les espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= @@ -54,13 +54,13 @@ ZO_ROOT_USER_EMAIL=root@example.com ZO_ROOT_USER_PASSWORD=Complexpass#123 ``` -:::note[Identifiants OpenObserve d'exemple] +:::note[Identifiants OpenObserve d’exemple] -`root@example.com` et `Complexpass#123` sont les valeurs d'exemple de la documentation OpenObserve. OpenObserve v1.0.x applique une politique de mot de passe de 8 à 128 caractères avec majuscules, minuscules, chiffres et caractères spéciaux. Modifiez ces deux valeurs pour tout déploiement réel et ne commettez pas `.env` dans le contrôle de version. +`root@example.com` et `Complexpass#123` sont les valeurs d’exemple de la documentation OpenObserve. OpenObserve v1.0.x applique une politique de mot de passe de 8 à 128 caractères avec majuscules, minuscules, chiffres et caractères spéciaux. Modifiez ces deux valeurs pour tout déploiement réel et ne commettez pas `.env` dans le contrôle de version. -::: +:: : -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -146,11 +146,11 @@ volumes: oo-data: ``` -`ZO_LOCAL_MODE_STORAGE=s3` est obligatoire : en mode nœud unique, OpenObserve stocke sinon les fichiers Parquet sur le disque local et ignore les variables `ZO_S3_*`. La tâche `init-bucket` utilise l'[image `rc`](https://github.com/rustfs/cli) pour créer `my-bucket` une fois que RustFS réussit son healthcheck, et elle ignore la création si le bucket existe déjà. +`ZO_LOCAL_MODE_STORAGE=s3` est obligatoire : en mode nœud unique, OpenObserve stocke sinon les fichiers Parquet sur le disque local et ignore les variables `ZO_S3_*`. La tâche `init-bucket` utilise l'[image `rc`](https://github.com/rustfs/cli) pour créer `my-bucket` une fois que RustFS réussit son healthcheck, et elle ignore la création si le compartiment existe déjà. ### 2. Démarrer le déploiement -Vérifiez puis démarrez la pile Compose : +Vérifiez puis démarrez la pile Compose : ```bash docker compose config @@ -158,17 +158,17 @@ docker compose up -d docker compose ps ``` -Le service `init-bucket` doit se terminer avec le code de sortie `0` après avoir créé le bucket : +Le service `init-bucket` doit se terminer avec le code de sortie `0` après avoir créé le compartiment : ```text ✓ Bucket 'rustfs/my-bucket' created successfully. ``` -Ouvrez l'interface OpenObserve à l'adresse `http://localhost:5080` et connectez-vous avec les valeurs `ZO_ROOT_USER_EMAIL` et `ZO_ROOT_USER_PASSWORD` de `.env`. La console RustFS est disponible à l'adresse `http://localhost:9001/rustfs/console/`. +Ouvrez l’interface OpenObserve à l’adresse `http://localhost:5080` et connectez-vous avec les valeurs `ZO_ROOT_USER_EMAIL` et `ZO_ROOT_USER_PASSWORD` de `.env`. La Console RustFS est disponible à l’adresse `http://localhost:9001/rustfs/console/`. ### 3. Confirmer la connexion entre OpenObserve et RustFS -Consultez le journal de démarrage d'OpenObserve pour voir la configuration de stockage : +Consultez le journal de démarrage d’OpenObserve pour voir la configuration de stockage : ```bash docker compose logs openobserve | grep "s3 init config" @@ -178,11 +178,11 @@ docker compose logs openobserve | grep "s3 init config" INFO infra::storage::remote: s3 init config: StorageConfig { name: "default", provider: "s3", server_url: "http://rustfs:9000", region_name: "us-east-1", access_key: "", secret_key: "", bucket_name: "my-bucket", bucket_prefix: "" } ``` -Au démarrage, OpenObserve exécute également une sonde de stockage : il écrit le fichier `o2_test/check.txt` dans le bucket puis le relit. Voir ce fichier dans RustFS confirme que le chemin d'écriture fonctionne. +Au démarrage, OpenObserve exécute également un contrôle du stockage : il écrit le fichier `o2_test/check.txt` dans le compartiment puis le relit. Voir ce fichier dans RustFS confirme que le chemin d’écriture fonctionne. ### 4. Ingérer des enregistrements de journaux -Envoyez un lot d'enregistrements à l'API d'ingestion JSON de l'organisation `default` et du flux `rustfs_test` : +Envoyez un lot d’enregistrements à l’API d’ingestion JSON de l’organisation `default` et du flux `rustfs_test` : ```bash curl -u "root@example.com:Complexpass#123" \ @@ -202,26 +202,26 @@ curl -u "root@example.com:Complexpass#123" \ ### 5. Transférer les données vers le stockage objet -Déclenchez le point de terminaison de flush au niveau du nœud pour que les enregistrements quittent le WAL : +Déclenchez le point de terminaison de vidage (flush) au niveau du nœud pour que les enregistrements quittent le WAL : ```bash curl -s -u "root@example.com:Complexpass#123" -X PUT "http://localhost:5080/node/flush" ``` -L'ingester convertit les enregistrements du WAL en fichier Parquet et le téléverse vers RustFS en arrière-plan dès que le fichier est plus ancien que `ZO_MAX_FILE_RETENTION_TIME` (60 secondes dans ce fichier Compose, 600 secondes par défaut). +L’ingester convertit les enregistrements du WAL en fichier Parquet et le téléverse vers RustFS en arrière-plan dès que le fichier est plus ancien que `ZO_MAX_FILE_RETENTION_TIME` (60 secondes dans ce fichier Compose, 600 secondes par défaut). ## Vérification ### Vérifier les objets dans RustFS -Listez le bucket via l'image d'initialisation du bucket : +Listez le compartiment via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh init-bucket -c \ '/usr/bin/rc alias set rustfs http://rustfs:9000 "$RUSTFS_ACCESS_KEY" "$RUSTFS_SECRET_KEY" >/dev/null && /usr/bin/rc ls rustfs/my-bucket --recursive' ``` -La sortie doit inclure le fichier sonde et la sortie de l'ingester sous le préfixe `files/` : +La sortie doit inclure le fichier de contrôle et la sortie de l’ingester sous le préfixe `files/` : ```text 19 B o2_test/check.txt @@ -229,21 +229,21 @@ La sortie doit inclure le fichier sonde et la sortie de l'ingester sous le préf 6.5 KiB files/default/index/rustfs_test_logs/2026/09/20/02/75072592621841940484907.ttv ``` -Vous pouvez également inspecter le bucket dans la console RustFS à l'adresse `http://localhost:9001/rustfs/console/` : +Vous pouvez également inspecter le compartiment dans la Console RustFS à l’adresse `http://localhost:9001/rustfs/console/` : -![Le bucket my-bucket dans la console RustFS](./images/rustfs-bucket-list.png) +![Le compartiment my-bucket dans la Console RustFS](./images/rustfs-bucket-list.png) -OpenObserve stocke les fichiers de données Parquet sous `files////` et les fichiers d'index plein texte sous `files//index/` : +OpenObserve stocke les fichiers de données Parquet sous `files////` et les fichiers d’index plein texte sous `files//index/` : -![Fichier de données Parquet écrit par OpenObserve dans la console RustFS](./images/rustfs-parquet-objects.png) +![Fichier de données Parquet écrit par OpenObserve dans la Console RustFS](./images/rustfs-parquet-objects.png) ### Interroger les journaux dans OpenObserve -Dans l'interface OpenObserve, ouvrez **Logs**, sélectionnez le flux `rustfs_test` et exécutez une requête. Les enregistrements ingérés apparaissent dans le tableau de résultats : +Dans l’interface OpenObserve, ouvrez **Logs**, sélectionnez le flux `rustfs_test` et exécutez une requête. Les enregistrements ingérés apparaissent dans le tableau de résultats : ![Recherche de journaux OpenObserve renvoyant les enregistrements ingérés](./images/openobserve-log-search.jpg) -La même requête via l'API de recherche. Notez que `start_time` et `end_time` sont en **microsecondes** : +La même requête via l’API de recherche. Notez que `start_time` et `end_time` sont en **microsecondes** : ```bash curl -s -u "root@example.com:Complexpass#123" \ @@ -258,13 +258,13 @@ curl -s -u "root@example.com:Complexpass#123" \ ### Consulter les statistiques du flux -La page **Data → Streams** affiche le nombre d'événements, les tailles ingérée et compressée, ainsi que la taille d'index pour `rustfs_test` : +La page **Data → Streams** affiche le nombre d’événements, les tailles ingérée et compressée, ainsi que la taille d’index pour `rustfs_test` : ![Statistiques du flux rustfs_test dans OpenObserve](./images/openobserve-streams.jpg) ### Vérifier que les données survivent sans cache local -Pour confirmer que RustFS est la couche persistante et non le disque local, supprimez le répertoire de cache d'OpenObserve, redémarrez le conteneur, puis interrogez à nouveau. L'image OpenObserve ne contient pas de shell ; utilisez donc `busybox` pour supprimer les fichiers : +Pour confirmer que RustFS est la couche persistante et non le disque local, supprimez le répertoire de cache d’OpenObserve, redémarrez le conteneur, puis interrogez à nouveau. L’image OpenObserve ne contient pas de shell ; utilisez donc `busybox` pour supprimer les fichiers : ```bash docker compose stop openobserve @@ -272,7 +272,7 @@ docker run --rm -v rustfs-openobserve_oo-data:/data busybox rm -rf /data/cache docker compose start openobserve ``` -Attendez que l'interface revienne, puis répétez la requête de recherche ci-dessus. Les mêmes enregistrements reviennent, car OpenObserve retélécharge les fichiers Parquet depuis RustFS. Le nom du répertoire du projet (`rustfs-openobserve`) devient le préfixe du nom du volume ; exécutez `docker volume ls` si vous avez utilisé un autre répertoire. +Attendez que l’interface revienne, puis répétez la requête de recherche ci-dessus. Les mêmes enregistrements reviennent, car OpenObserve retélécharge les fichiers Parquet depuis RustFS. Le nom du répertoire du projet (`rustfs-openobserve`) devient le préfixe du nom du volume ; exécutez `docker volume ls` si vous avez utilisé un autre répertoire. ## Dépannage @@ -280,32 +280,32 @@ Attendez que l'interface revienne, puis répétez la requête de recherche ci-de En mode nœud unique (`ZO_LOCAL_MODE=true`), le backend de stockage est `disk` par défaut. Sans `ZO_LOCAL_MODE_STORAGE=s3`, OpenObserve ignore les variables `ZO_S3_*` et conserve les fichiers Parquet sous `/data/wal/files/`. -### Aucun fichier Parquet n'apparaît dans le bucket après le flush +### Aucun fichier Parquet n’apparaît dans le compartiment après le vidage -Le téléverseur s'exécute en arrière-plan et ne téléverse un fichier Parquet que lorsqu'il est plus ancien que `ZO_MAX_FILE_RETENTION_TIME` — 600 secondes par défaut. Ce guide fixe la valeur à 60 secondes. Si des fichiers manquent toujours, consultez les journaux de l'ingester : +Le processus de téléversement s’exécute en arrière-plan et ne téléverse un fichier Parquet que lorsqu’il est plus ancien que `ZO_MAX_FILE_RETENTION_TIME` — 600 secondes par défaut. Ce guide fixe la valeur à 60 secondes. Si des fichiers manquent toujours, consultez les journaux de l’ingester : ```bash docker compose logs openobserve | grep "INGESTER:JOB" ``` -### L'API de recherche ne renvoie aucun résultat +### L’API de recherche ne renvoie aucun résultat -`start_time` et `end_time` de l'API de recherche sont en microsecondes. Un horodatage en millisecondes comme `1789869600000` sélectionne une plage en 1970 ; multipliez-le par 1000. +`start_time` et `end_time` de l’API de recherche sont en microsecondes. Un horodatage en millisecondes comme `1789869600000` sélectionne une plage en 1970 ; multipliez-le par 1000. ### OpenObserve redémarre avec une erreur de mot de passe faible OpenObserve v1.0.x rejette les valeurs de `ZO_ROOT_USER_PASSWORD` qui ne contiennent pas au moins une majuscule, une minuscule, un chiffre et un caractère spécial. -### La console RustFS ne s'ouvre pas +### La Console RustFS ne s’ouvre pas -Dans RustFS v2.x, la console est servie sous le préfixe de chemin `/rustfs/console/`. Une requête vers le chemin racine du port `9001` renvoie une réponse XML de refus d'accès de type S3, ce qui est attendu. +Dans RustFS v2.x, la console est servie sous le préfixe de chemin `/rustfs/console/`. Une requête vers le chemin racine du port `9001` renvoie une réponse XML de refus d’accès de type S3, ce qui est attendu. -### RustFS ne démarre pas avec une erreur d'autorisation +### RustFS ne démarre pas avec une erreur d’autorisation -L'image RustFS s'exécute avec l'utilisateur et le groupe `10001`. Si vous montez un répertoire hôte au lieu du volume nommé de ce guide, exécutez d'abord `chown -R 10001:10001 `. +L’image RustFS s’exécute avec l’utilisateur et le groupe `10001`. Si vous montez un répertoire hôte au lieu du volume nommé de ce guide, exécutez d’abord `chown -R 10001:10001 `. -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). -- Suivez la [documentation OpenObserve](https://openobserve.ai/docs/) pour connecter de vrais producteurs de journaux tels que Fluent Bit ou l'OpenTelemetry Collector. +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). +- Suivez la [documentation OpenObserve](https://openobserve.ai/docs/) pour connecter de vrais producteurs de journaux tels que Fluent Bit ou l’OpenTelemetry Collector. diff --git a/content/fr/developer/integration/observability/tempo.md b/content/fr/developer/integration/observability/tempo.md index a2a33e8ae..aa484b080 100644 --- a/content/fr/developer/integration/observability/tempo.md +++ b/content/fr/developer/integration/observability/tempo.md @@ -3,11 +3,11 @@ title: "Tempo" description: "Exécutez Grafana Tempo avec RustFS comme backend de stockage S3 pour les traces, déployé avec Docker Compose." --- -Ce guide exécute [Grafana Tempo](https://github.com/grafana/tempo) — le backend de traçage distribué de Grafana Labs — avec **RustFS** comme stockage de traces. Vous allez démarrer un Tempo single-binary avec Docker Compose, pousser une trace via le récepteur compatible Zipkin, l'interroger via l'API de recherche, puis vérifier que le bloc de trace est stocké comme objet Parquet dans RustFS. Le flux a été validé avec `grafana/tempo:2.9.5` et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide exécute [Grafana Tempo](https://github.com/grafana/tempo) — le backend de traçage distribué de Grafana Labs — avec **RustFS** comme stockage de traces. Vous allez démarrer Tempo en mode binaire unique (single-binary) avec Docker Compose, pousser une trace via le récepteur compatible Zipkin, l’interroger via l’API de recherche, puis vérifier que le bloc de trace est stocké comme objet Parquet dans RustFS. Le flux a été validé avec `grafana/tempo:2.9.5` et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -Tempo accepte les spans depuis un point de terminaison compatible Zipkin, les met en mémoire tampon dans un bloc, puis transfère les blocs terminés vers le stockage objet sous forme de fichiers Parquet. Les recherches analysent l'index des blocs et lisent les données depuis le stockage objet, de sorte que chaque trace survit à un redémarrage de Tempo. +Tempo accepte les spans depuis un point de terminaison compatible Zipkin, les met en mémoire tampon dans un bloc, puis transfère les blocs terminés vers le stockage objet sous forme de fichiers Parquet. Les recherches analysent l’index des blocs et lisent les données depuis le stockage objet, de sorte que chaque trace survit à un redémarrage de Tempo. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-tempo cd rustfs-tempo ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez la configuration Tempo — un déploiement single-binary avec le backend S3 pointant vers RustFS et une durée de bloc courte pour ne pas attendre les 30 minutes par défaut : +Créez la configuration Tempo — un déploiement en binaire unique (single-binary) avec le backend S3 pointant vers RustFS et une durée de bloc courte pour ne pas attendre les 30 minutes par défaut : ```yaml title="tempo.yml" server: @@ -69,9 +69,9 @@ storage: blocklist_poll: 30s ``` -`forcepathstyle: true` et `insecure: true` sélectionnent l'adressage path-style en HTTP simple, attendu par RustFS pour le point de terminaison du réseau de conteneurs. `max_block_duration: 1m` et `blocklist_poll: 30s` accélèrent le cycle de transfert et de découverte pour les tests. +`forcepathstyle: true` et `insecure: true` sélectionnent l’adressage de type chemin (path-style) en HTTP non chiffré, attendu par RustFS pour le point de terminaison du réseau de conteneurs. `max_block_duration: 1m` et `blocklist_poll: 30s` accélèrent le cycle de transfert et de découverte pour les tests. -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -141,20 +141,20 @@ volumes: ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -Tempo est démarré quand le point de terminaison de statut répond : +Tempo est démarré quand le point de terminaison de statut répond : ```bash curl -s http://localhost:3200/status | head -c 120 @@ -162,7 +162,7 @@ curl -s http://localhost:3200/status | head -c 120 ## 3. Pousser une trace -Publiez une petite trace Zipkin de cinq spans vers le récepteur compatible Zipkin : +Publiez une petite trace Zipkin de cinq spans vers le récepteur compatible Zipkin : ```bash python3 - <<'PY' @@ -205,7 +205,7 @@ push: 202 ## 4. Rechercher et lire la trace -Après environ une minute, l'ingester transfère le bloc terminé vers RustFS et le compacteur le découvre. Recherchez par tag : +Après environ une minute, l’ingester transfère le bloc terminé vers RustFS et le compacteur le découvre. Recherchez par tag : ```bash curl -s "http://localhost:3200/api/search?tags=job=rustfs-integration" @@ -215,7 +215,7 @@ curl -s "http://localhost:3200/api/search?tags=job=rustfs-integration" {"traces":[{"traceID":"5354809288c0d1a3de0e09ce74d06987","rootServiceName":"rustfs-tempo-demo","rootTraceName":"rustfs-tempo-span-0",...}]} ``` -Récupérez la trace par son ID avec l'ID affiché par le script de push : +Récupérez la trace par son ID avec l’ID affiché par le script de push : ```bash curl -s "http://localhost:3200/api/traces/" -o /dev/null -w "%{http_code}\n" @@ -227,34 +227,34 @@ curl -s "http://localhost:3200/api/traces/" -o /dev/null -w "%{ht ## 5. Vérifier le bloc de trace dans RustFS -Listez le préfixe du tenant via l'image d'initialisation du bucket : +Listez le préfixe du tenant via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ '/usr/bin/rc alias set rustfs http://rustfs:9000 "$RUSTFS_ACCESS_KEY" "$RUSTFS_SECRET_KEY" >/dev/null && /usr/bin/rc ls rustfs/my-bucket/single-tenant --recursive' ``` -`single-tenant` est le tenant utilisé par Tempo quand `multitenancy_enabled` vaut `false`. Chaque bloc de trace terminé est un objet Parquet : +`single-tenant` est le tenant utilisé par Tempo quand `multitenancy_enabled` vaut `false`. Chaque bloc de trace terminé est un objet Parquet : ```text [2026-09-20 15:03:54] 25.16 KiB single-tenant/619118dc-a512-4ca6-90f5-e8b15bc9013f/data.parquet ``` -Vous pouvez également parcourir le préfixe dans la console RustFS : +Vous pouvez également parcourir le préfixe dans la Console RustFS : -![Le bloc de trace Tempo stocké dans la console RustFS](./images/rustfs-tempo-blocks.png) +![Le bloc de trace Tempo stocké dans la Console RustFS](./images/rustfs-tempo-blocks.png) Le bloc résidant dans RustFS, la trace reste consultable après un redémarrage de Tempo — redémarrez le conteneur et répétez la recherche pour le confirmer. ## 6. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les traces stockées et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les traces stockées et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -262,13 +262,13 @@ docker compose down --volumes ## Dépannage -### Le fichier de configuration est rejeté avec "field ingester not found" +### Le fichier de configuration est rejeté avec « field ingester not found » Tempo 3.x a modifié la structure de configuration. Ce guide épingle `grafana/tempo:2.9.5`, dont la configuration correspond aux blocs classiques `ingester`/`compactor` présentés ci-dessus. ### La recherche ne renvoie aucune trace juste après le push -L'ingester transfère un bloc terminé après `max_block_duration` (une minute dans ce guide), et le querier découvre les nouveaux blocs à chaque `blocklist_poll` (30 secondes). Attendez le transfert et recherchez à nouveau, puis consultez les journaux de Tempo : +L’ingester transfère un bloc terminé après `max_block_duration` (une minute dans ce guide), et le querier découvre les nouveaux blocs à chaque `blocklist_poll` (30 secondes). Attendez le transfert et recherchez à nouveau, puis consultez les journaux de Tempo : ```bash docker compose logs tempo @@ -276,7 +276,7 @@ docker compose logs tempo ### Réponses AccessDenied ou 403 -Vérifiez que les identifiants de `tempo.yml` correspondent aux identifiants RustFS et que la tâche `create-bucket` s'est terminée avec succès : +Vérifiez que les identifiants de `tempo.yml` correspondent aux identifiants RustFS et que la tâche `create-bucket` s’est terminée avec succès : ```bash docker compose logs create-bucket @@ -284,10 +284,10 @@ docker compose logs create-bucket ### Erreurs de connexion ou de certificat -`endpoint` ne prend pas de schéma ; `insecure: true` sélectionne HTTP simple et `forcepathstyle: true` l'adressage path-style pour le point de terminaison du réseau de conteneurs. À l'intérieur du réseau Compose, utilisez `rustfs:9000` ; depuis l'hôte, `localhost:9000`. +`endpoint` ne prend pas de schéma ; `insecure: true` sélectionne HTTP non chiffré et `forcepathstyle: true` l’adressage de type chemin (path-style) pour le point de terminaison du réseau de conteneurs. À l’intérieur du réseau Compose, utilisez `rustfs:9000` ; depuis l’hôte, `localhost:9000`. -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). -- Suivez la [documentation Grafana Tempo](https://grafana.com/docs/tempo/latest/) pour connecter l'OpenTelemetry Collector ou des applications instrumentées comme producteurs de traces. +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). +- Suivez la [documentation Grafana Tempo](https://grafana.com/docs/tempo/latest/) pour connecter l’OpenTelemetry Collector ou des applications instrumentées comme producteurs de traces. diff --git a/content/fr/developer/integration/others/capo.md b/content/fr/developer/integration/others/capo.md index b7364b72a..9470978b3 100644 --- a/content/fr/developer/integration/others/capo.md +++ b/content/fr/developer/integration/others/capo.md @@ -3,11 +3,11 @@ title: "capo (Python)" description: "Connectez capo à RustFS et effectuez des opérations objet de base depuis Python avec des clients synchrones ou asynchrones." --- -[capo](https://github.com/kap-sh/capo) est un SDK AWS pour Python développé par la communauté, qui propose des clients entièrement typés avec prise en charge synchrone et asynchrone dès l'installation. Le client S3 est distribué dans le paquet [`capo-s3`](https://pypi.org/project/capo-s3/) et se connecte à RustFS via un point de terminaison personnalisé. +[capo](https://github.com/kap-sh/capo) est un SDK AWS pour Python développé par la communauté, qui propose des clients entièrement typés avec prise en charge synchrone et asynchrone dès l’installation. Le client S3 est distribué dans le paquet [`capo-s3`](https://pypi.org/project/capo-s3/) et se connecte à RustFS via un point de terminaison personnalisé. ## Installation -capo nécessite Python 3.10 ou ultérieur : +capo nécessite Python 3.10 ou ultérieur : ```bash pip install capo-s3 @@ -15,7 +15,7 @@ pip install capo-s3 ## Configuration -Pointez le client vers votre point de terminaison RustFS. Remplacez `http://localhost:9000` par l'adresse de votre serveur et utilisez vos propres [clés d'accès](../../../security-compliance/iam/access-token.md). RustFS exige l'adressage de type chemin, que capo active nativement via `force_path_style` : +Pointez le client vers votre point de terminaison RustFS. Remplacez `http://localhost:9000` par l’adresse de votre serveur et utilisez vos propres [clés d’accès](../../../security-compliance/iam/access-token.md). RustFS exige l’adressage de type chemin, que capo active nativement via `force_path_style` : ```python from capo_s3 import Credentials, S3Client @@ -33,7 +33,7 @@ s3 = S3Client( ## Vérification -Créez un compartiment, téléversez un objet et listez le contenu du compartiment : +Créez un compartiment, chargez (téléversez) un objet et listez le contenu du compartiment : ```python s3.create_bucket(bucket="my-bucket") @@ -44,13 +44,13 @@ for obj in s3.list_objects_v2(bucket="my-bucket").get("contents", []): print(obj["key"], obj["size"]) ``` -Sortie attendue : +Sortie attendue : ```text hello.txt 13 ``` -Pour relire l'objet, `get_object` renvoie une réponse en flux, à utiliser comme gestionnaire de contexte : +Pour relire l’objet, `get_object` renvoie une réponse en flux, à utiliser comme gestionnaire de contexte : ```python with s3.get_object(bucket="my-bucket", key="hello.txt") as response: @@ -59,7 +59,7 @@ with s3.get_object(bucket="my-bucket", key="hello.txt") as response: print(content.decode()) ``` -Vous pouvez également générer des URL présignées qui accordent un accès limité dans le temps sans identifiants : +Vous pouvez également générer des URL présignées qui accordent un accès limité dans le temps sans identifiants : ```python url = s3.presigned_get_object(bucket="my-bucket", key="hello.txt", expire_in=3600) @@ -68,7 +68,7 @@ print(url) ## Client asynchrone -Le client asynchrone accepte les mêmes arguments et propose les mêmes opérations. Utilisez `await` pour chaque appel ainsi que des gestionnaires de contexte asynchrones pour le client et pour les réponses en flux : +Le client asynchrone accepte les mêmes arguments et propose les mêmes opérations. Utilisez `await` pour chaque appel ainsi que des gestionnaires de contexte asynchrones pour le client et pour les réponses en flux : ```python import asyncio @@ -103,6 +103,6 @@ async def main() -> None: asyncio.run(main()) ``` -## Prochaines étapes +## Étapes suivantes -Le listage paginé suit la même convention — `iter_list_objects_v2` itère sur les résultats. Pour l'alternative officielle du SDK AWS, voir [boto3 (Python)](../../examples/boto3.md) ; la [présentation des SDK S3](../../sdk/index.md) répertorie les autres langages. +Le listage paginé suit la même convention — `iter_list_objects_v2` itère sur les résultats. Pour l’alternative officielle du SDK AWS, voir [boto3 (Python)](../../examples/boto3.md) ; la [présentation des SDK S3](../../sdk/index.md) répertorie les autres langages. diff --git a/content/fr/developer/integration/others/index.md b/content/fr/developer/integration/others/index.md index 10cf9eeb6..ab8c3d181 100644 --- a/content/fr/developer/integration/others/index.md +++ b/content/fr/developer/integration/others/index.md @@ -1,14 +1,14 @@ --- title: "Autres" -description: "Autres intégrations RustFS, actuellement le SDK communautaire capo pour Python." +description: "Cette page présente d’autres intégrations RustFS, actuellement le SDK communautaire capo pour Python." --- -Guides d'intégration qui ne correspondent pas aux autres catégories. +Guides d’intégration qui ne correspondent pas aux autres catégories. ## Guides - [capo (Python)](./capo.md) — connectez le SDK communautaire capo à RustFS avec des clients synchrones ou asynchrones. -rclone](./rclone.md) — sync, mount, and serve RustFS buckets from the command line. -- [tusd](./tusd.md) — receive resumable uploads into a RustFS bucket over the tus protocol. -- [JuiceFS](./juicefs.md) — mount a POSIX filesystem backed by a RustFS bucket. -- [Nextcloud](./nextcloud.md) — use RustFS as S3 external storage for Nextcloud files. +- [rclone](./rclone.md) — synchronisez, montez et servez des compartiments RustFS depuis la ligne de commande. +- [tusd](./tusd.md) — recevez des chargements reprenables dans un compartiment RustFS via le protocole tus. +- [JuiceFS](./juicefs.md) — montez un système de fichiers POSIX adossé à un compartiment RustFS. +- [Nextcloud](./nextcloud.md) — utilisez RustFS comme stockage S3 externe pour les fichiers Nextcloud. diff --git a/content/fr/developer/integration/registry/harbor.md b/content/fr/developer/integration/registry/harbor.md index fbcc6202b..1419d7bf9 100644 --- a/content/fr/developer/integration/registry/harbor.md +++ b/content/fr/developer/integration/registry/harbor.md @@ -1,13 +1,13 @@ --- title: "Harbor" -description: "Stockez les images de conteneurs poussées vers Harbor dans le stockage objet RustFS via le pilote de stockage S3 de la registry, déployés avec Docker Compose." +description: "Stockez dans le stockage objet RustFS les images de conteneurs poussées vers Harbor, via le pilote de stockage S3 de la registry, le tout déployé avec Docker Compose." --- -Ce guide connecte [Harbor](https://github.com/goharbor/harbor) — le registre cloud native gradué de la CNCF — à **RustFS**. Harbor persiste les couches d'images, les manifestes et les autres artefacts OCI via son composant de registry intégré, qui implémente le pilote de stockage S3 du projet [distribution](https://distribution.github.io/distribution/). Vous allez exécuter ce composant de registry contre RustFS avec Docker Compose, pousser une image, la retirer, puis vérifier les objets dans RustFS. Les mêmes réglages de stockage s'appliquent à un déploiement Harbor complet. Le flux a été validé avec `goharbor/registry-photon:v2.12.2` et `rustfs/rustfs-x86-musl:v2.3.1`. +Ce guide connecte [Harbor](https://github.com/goharbor/harbor) — le registre cloud native diplômé (graduated) de la CNCF — à **RustFS**. Harbor persiste les couches d’images, les manifestes et les autres artefacts OCI via son composant de registry intégré, qui implémente le pilote de stockage S3 du projet [distribution](https://distribution.github.io/distribution/). Vous allez exécuter ce composant de registry face à RustFS avec Docker Compose, pousser une image, la tirer (pull), puis vérifier les objets dans RustFS. Les mêmes réglages de stockage s’appliquent à un déploiement Harbor complet. Le flux a été validé avec `goharbor/registry-photon:v2.12.2` et `rustfs/rustfs-x86-musl:v2.3.1`. -Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d'intégration locaux, pas à la production. +Vous avez besoin de Docker avec le plugin Compose. Ce déploiement est destiné aux tests d’intégration locaux, pas à la production. -## Architecture +## Schéma d’architecture ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -La registry stocke chaque blob, manifeste et lien de dépôt sous `docker/registry/v2/` dans le bucket via le pilote de stockage S3. Les réglages `regionendpoint`, `secure: false` et `skipverify: true` orientent le client AWS S3 utilisé par le pilote vers le point de terminaison RustFS, avec un adressage path-style en HTTP simple. +La registry stocke chaque blob, manifeste et lien de dépôt sous `docker/registry/v2/` dans le compartiment via le pilote de stockage S3. Les réglages `regionendpoint`, `secure: false` et `skipverify: true` orientent le client AWS S3 utilisé par le pilote vers le point de terminaison RustFS, avec un adressage de type chemin (path-style) en HTTP non chiffré. ## 1. Créer les fichiers du projet -Créez un répertoire de travail : +Créez un répertoire de travail : ```bash mkdir rustfs-harbor cd rustfs-harbor ``` -Créez un fichier d'environnement et remplacez les deux espaces réservés d'identifiants : +Créez un fichier d’environnement et remplacez les deux valeurs d’identifiants indicatives : ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Utilisez des identifiants dédiés pour le bucket. Ne commettez pas `.env` dans le contrôle de version. +Utilisez des identifiants dédiés pour le compartiment. N’ajoutez pas le fichier `.env` au dépôt (ne le versionnez pas). -Créez la configuration de registry qu'Harbor utilise pour son composant de registry : +Créez la configuration de registry qu’Harbor utilise pour son composant de registry : ```yaml title="config.yml" version: 0.1 @@ -64,9 +64,9 @@ health: threshold: 3 ``` -`regionendpoint` dirige le pilote vers RustFS plutôt que vers AWS, `secure: false` sélectionne HTTP simple à l'intérieur du réseau Compose, et `redirect.disable: true` fait servir les blobs par la registry elle-même — Harbor définit la même option pour les backends sans prise en charge de la redirection. +`regionendpoint` dirige le pilote vers RustFS plutôt que vers AWS, `secure: false` sélectionne HTTP non chiffré à l’intérieur du réseau Compose, et `redirect.disable: true` fait servir les blobs par la registry elle-même — Harbor définit la même option pour les backends sans prise en charge de la redirection. -Créez le fichier Compose : +Créez le fichier Compose : ```yaml title="compose.yaml" services: @@ -132,24 +132,24 @@ volumes: rustfs-data: ``` -L'[image `rc`](https://github.com/rustfs/cli) fournit le client en ligne de commande officiel de RustFS. L'initialiseur vérifie l'existence de `my-bucket` avant de le créer, afin que des redémarrages répétés ne suppriment pas les artefacts existants. +L’[image `rc`](https://github.com/rustfs/cli) fournit le client en ligne de commande officiel de RustFS. L’initialiseur vérifie l’existence de `my-bucket` avant de le créer, afin que des redémarrages répétés ne suppriment pas les artefacts existants. ## 2. Démarrer le déploiement -Vérifiez le fichier Compose avant de démarrer les conteneurs : +Vérifiez le fichier Compose avant de démarrer les conteneurs : ```bash docker compose config ``` -Démarrez les services et attendez la fin de l'initialisation du bucket : +Démarrez les services et attendez la fin de l’initialisation du compartiment : ```bash docker compose up -d docker compose ps -a ``` -L'API de la registry doit répondre avec un catalogue vide : +L’API de la registry doit répondre avec un catalogue vide : ```bash curl -s http://localhost:5000/v2/_catalog @@ -161,7 +161,7 @@ curl -s http://localhost:5000/v2/_catalog ## 3. Pousser une image -Retirez une petite image, retaguez-la pour la registry locale, puis poussez-la : +Tirez une petite image, retaguez-la pour la registry locale, puis poussez-la : ```bash docker pull busybox:latest @@ -173,9 +173,9 @@ docker push localhost:5000/demo/app:v1 v1: digest: sha256:1cfa4e2b09e127b9c4ed43578d3f3c18e7d44ea47b9ea98475c0cbe9086525f8 size: 527 ``` -## 4. Retirer l'image +## 4. Tirer l’image -Supprimez les tags locaux, puis retirez l'image depuis la registry — les couches proviennent désormais de RustFS : +Supprimez les balises locales, puis tirez l’image depuis la registry — les couches proviennent désormais de RustFS : ```bash docker rmi localhost:5000/demo/app:v1 @@ -188,7 +188,7 @@ localhost:5000/demo/app:v1 ## 5. Vérifier les objets dans RustFS -Listez le préfixe du dépôt via l'image d'initialisation du bucket : +Listez le préfixe du dépôt via l’image d’initialisation du compartiment : ```bash docker compose run --rm --entrypoint /bin/sh create-bucket -c \ @@ -203,15 +203,15 @@ docker compose run --rm --entrypoint /bin/sh create-bucket -c \ [2026-09-20 12:11:25] 71 B docker/registry/v2/repositories/demo/app/_manifests/tags/v1/index/sha256/1cfa4e2b09e127b9c4ed43578d3f3c18e7d44ea47b9ea98475c0cbe9086525f8/link ``` -Les blobs eux-mêmes se trouvent sous `docker/registry/v2/blobs/`. Vous pouvez également parcourir le préfixe dans la console RustFS à l'adresse `http://localhost:9001/rustfs/console/` : +Les blobs eux-mêmes se trouvent sous `docker/registry/v2/blobs/`. Vous pouvez également parcourir le préfixe dans la Console RustFS à l’adresse `http://localhost:9001/rustfs/console/` : -![Les métadonnées du dépôt de l'image poussée dans la console RustFS](./images/rustfs-harbor-objects.png) +![Les métadonnées du dépôt de l’image poussée dans la Console RustFS](./images/rustfs-harbor-objects.png) ## 6. Utiliser RustFS dans un déploiement Harbor complet -Le composant de registry validé ci-dessus est le même que celui qu'exécute un déploiement Harbor complet ; les réglages de stockage se reportent donc directement. +Le composant de registry validé ci-dessus est le même que celui qu’exécute un déploiement Harbor complet ; les réglages de stockage se reportent donc directement. -Pour le chart Helm, définissez les options S3 sous `persistence.imageChartStorage` : +Pour le chart Helm, définissez les options S3 sous `persistence.imageChartStorage` : ```yaml title="values.yaml" persistence: @@ -228,17 +228,17 @@ persistence: skipverify: true ``` -Pour l'installateur Harbor piloté par un fichier `harbor.yml`, placez les mêmes clés du pilote sous `storage_service.s3`. Les deux fichiers acceptent les options du pilote de stockage documentées par le [projet distribution](https://distribution.github.io/distribution/about/configuration/) — c'est précisément la surface de configuration validée dans ce guide. +Pour l’installateur Harbor piloté par un fichier `harbor.yml`, placez les mêmes clés du pilote sous `storage_service.s3`. Les deux fichiers acceptent les options du pilote de stockage documentées par le [projet distribution](https://distribution.github.io/distribution/about/configuration/) — c’est précisément la surface de configuration validée dans ce guide. ## 7. Arrêter ou réinitialiser la pile -Arrêtez les conteneurs en conservant le volume de données RustFS : +Arrêtez les conteneurs en conservant le volume de données RustFS : ```bash docker compose down ``` -Pour supprimer les artefacts stockés et repartir d'un volume RustFS vide, ajoutez explicitement `--volumes` : +Pour supprimer les artefacts stockés et repartir d’un volume RustFS vide, ajoutez explicitement `--volumes` : ```bash docker compose down --volumes @@ -248,32 +248,32 @@ docker compose down --volumes ### La registry ne démarre pas ou signale une erreur de stockage -Consultez les journaux de la registry pour les messages du pilote S3 : +Consultez les journaux de la registry pour les messages du pilote S3 : ```bash docker compose logs registry ``` -`regionendpoint` doit être joignable depuis le conteneur de la registry. À l'intérieur du réseau Compose, utilisez `http://rustfs:9000` ; depuis un processus sur l'hôte, `http://localhost:9000`. +`regionendpoint` doit être joignable depuis le conteneur de la registry. À l’intérieur du réseau Compose, utilisez `http://rustfs:9000` ; depuis un processus sur l’hôte, `http://localhost:9000`. -### Erreurs TLS ou de certificat avec un point de terminaison HTTP simple +### Erreurs TLS ou de certificat avec un point de terminaison HTTP non chiffré -`secure: false` sélectionne HTTP simple pour le point de terminaison RustFS. Sans cela, le pilote tente HTTPS et échoue avec une erreur de connexion ou de certificat. Pour un point de terminaison TLS avec un certificat auto-signé, conservez `secure: true`, définissez `skipverify: true` et fournissez le bundle CA via l'option `ca_bundle` qu'Harbor expose dans `harbor.yml`. +`secure: false` sélectionne HTTP non chiffré pour le point de terminaison RustFS. Sans cela, le pilote tente HTTPS et échoue avec une erreur de connexion ou de certificat. Pour un point de terminaison TLS avec un certificat auto-signé, conservez `secure: true`, définissez `skipverify: true` et fournissez le bundle CA via l’option `ca_bundle` qu’Harbor expose dans `harbor.yml`. ### Réponses AccessDenied ou 403 -Vérifiez que les identifiants de `config.yml` correspondent aux identifiants RustFS et que la tâche `create-bucket` s'est terminée avec succès : +Vérifiez que les identifiants de `config.yml` correspondent aux identifiants RustFS et que la tâche `create-bucket` s’est terminée avec succès : ```bash docker compose logs create-bucket ``` -### Le push réussit mais les objets n'apparaissent pas dans le préfixe attendu +### Le push réussit mais les objets n’apparaissent pas dans le préfixe attendu -Le pilote écrit sous `docker/registry/v2/` dans le bucket. Listez tout le bucket de manière récursive pour localiser l'arborescence du dépôt avant de supposer un problème de configuration. +Le pilote écrit sous `docker/registry/v2/` dans le compartiment. Listez tout le compartiment de manière récursive pour localiser l’arborescence du dépôt avant de supposer un problème de configuration. -## Prochaines étapes +## Étapes suivantes -- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d'adopter d'autres opérations S3. -- Créez des identifiants de production dédiés avec la [gestion des clés d'accès](/security-compliance/iam/access-token). +- Consultez les [notes de compatibilité S3](/administration/protocols/s3) avant d’adopter d’autres opérations S3. +- Créez des identifiants de production dédiés avec la [gestion des clés d’accès](/security-compliance/iam/access-token). - Suivez la [documentation Harbor](https://goharbor.io/docs/) pour configurer un déploiement Harbor complet avec réplication, scan de vulnérabilités et RBAC. diff --git a/content/fr/developer/integration/registry/index.md b/content/fr/developer/integration/registry/index.md index 0a50a8053..8616a8fa7 100644 --- a/content/fr/developer/integration/registry/index.md +++ b/content/fr/developer/integration/registry/index.md @@ -1,13 +1,13 @@ --- title: "Registre" -description: "Connectez les registries de conteneurs à RustFS via des interfaces de stockage objet compatibles S3." +description: "Connectez les registres de conteneurs à RustFS via des interfaces de stockage objet compatibles S3." --- -Utilisez **RustFS** comme couche de stockage objet pour les registries de conteneurs disposant d'un pilote de stockage compatible S3. +Utilisez **RustFS** comme couche de stockage objet pour les registries de conteneurs disposant d’un pilote de stockage compatible S3. -## Registries +## Registres - [Harbor](./harbor.md) - [Docker Registry](./docker-registry.md) -Conservez les artefacts d'images dans un bucket dédié et limitez les identifiants aux opérations de bucket requises. +Conservez les artefacts d’images dans un compartiment dédié et limitez les identifiants aux opérations de compartiment requises. diff --git a/content/fr/index.mdx b/content/fr/index.mdx index a81ccf64c..35b8cb902 100644 --- a/content/fr/index.mdx +++ b/content/fr/index.mdx @@ -1,5 +1,5 @@ --- -title: "Documentation de RustFS" +title: "Documentation RustFS" description: "Installez RustFS sous Linux, dans des conteneurs, sur Kubernetes, macOS ou Windows." --- diff --git a/content/fr/installation/linux/prerequisites-and-service.md b/content/fr/installation/linux/prerequisites-and-service.md index 313c6f995..3b0c104fb 100644 --- a/content/fr/installation/linux/prerequisites-and-service.md +++ b/content/fr/installation/linux/prerequisites-and-service.md @@ -1,30 +1,30 @@ --- -title: "Linux Prerequisites and Service Setup" -description: "Common prerequisites, disk preparation, binary installation, and systemd service setup shared by all RustFS Linux deployment modes." +title: "Prérequis Linux et configuration du service" +description: "Cette page décrit les prérequis communs, la préparation des disques, l’installation du binaire et la configuration du service systemd partagés par tous les modes de déploiement Linux de RustFS." --- -This page contains the prerequisites and service setup steps shared by all three Linux deployment modes — [SNSD](./single-node-single-disk.md), [SNMD](./single-node-multiple-disk.md), and [MNMD](./multiple-node-multiple-disk.md). Complete these steps first, then return to your mode page to configure the environment file and start the service. +Cette page regroupe les prérequis et la configuration du service communs aux trois modes de déploiement Linux — [SNSD](./single-node-single-disk.md), [SNMD](./single-node-multiple-disk.md) et [MNMD](./multiple-node-multiple-disk.md). Terminez d’abord ces étapes, puis revenez à la page de votre mode pour configurer le fichier d’environnement et démarrer le service. -## Operating System Version +## Version du système d’exploitation -We recommend Linux kernel version 4.x or later; versions 5.x/6.x achieve better I/O throughput and network performance. Ubuntu 22.04 and RHEL 8.x are both suitable for installing RustFS. +Nous recommandons un noyau Linux 4.x ou ultérieur ; les versions 5.x et 6.x offrent un meilleur débit d’E/S et de meilleures performances réseau. Ubuntu 22.04 et RHEL 8.x conviennent tous deux à l’installation de RustFS. -## Firewall +## Pare-feu -Linux systems have firewalls enabled by default. Check the firewall status with: +Les systèmes Linux ont un pare-feu activé par défaut. Vérifiez son état avec : ```bash systemctl status firewalld ``` -If your firewall status is "active", you can disable the firewall: +Si l’état du pare-feu est « active », vous pouvez le désactiver : ```bash systemctl stop firewalld systemctl disable firewalld ``` -Or allow the RustFS S3 port (9000) and console port (9001): +Ou autorisez le port S3 de RustFS (9000) et le port de la Console (9001) : ```bash firewall-cmd --zone=public --add-port=9000/tcp --permanent @@ -32,36 +32,36 @@ firewall-cmd --zone=public --add-port=9001/tcp --permanent firewall-cmd --reload ``` -All RustFS servers in a deployment **must** use the same listening port. If you use port 9000, every other server must also use port 9000. +Tous les serveurs RustFS d’un déploiement **doivent** utiliser le même port d’écoute. Si vous utilisez le port 9000, chaque autre serveur doit aussi utiliser le port 9000. -## Memory Requirements +## Exigences de mémoire -RustFS requires at least 2 GB of memory for a test environment; production environments require a minimum of 128 GB of memory. +RustFS exige au moins 2 Go de mémoire pour un environnement de test ; un environnement de production exige au minimum 128 Go. -## Time Synchronization +## Synchronisation de l’heure -Tous les nœuds d'un déploiement distribué RustFS **doivent** maintenir des horloges synchronisées. RustFS s'appuie sur les horodatages pour la signature des requêtes, le versionnement des objets, le verrouillage distribué et la réplication. Une dérive significative de l'horloge entre les nœuds peut provoquer : +Tous les nœuds d’un déploiement distribué RustFS **doivent** maintenir des horloges synchronisées. RustFS s’appuie sur les horodatages pour la signature des requêtes, la gestion des versions des objets, le verrouillage distribué et la réplication. Une dérive significative de l’horloge entre les nœuds peut provoquer : -- **Échecs de signature de requête** — La vérification des signatures S3 dépend d'horodatages précis. -- **Problèmes de réplication et de cohérence** — Un décalage d'horloge peut entraîner des versions d'objets obsolètes ou conflictuelles. -- **Problèmes de contention de verrouillage** — Les verrous distribués utilisent des horodatages pour l'expiration des baux. -- **Échecs de démarrage du service** — RustFS refuse de démarrer si le décalage d'horloge entre les nœuds dépasse les seuils de sécurité. +- **Échecs de signature de requête** — La vérification des signatures S3 dépend d’horodatages précis. +- **Problèmes de réplication et de cohérence** — Un décalage d’horloge peut entraîner des versions d’objets obsolètes ou conflictuelles. +- **Problèmes de contention de verrouillage** — Les verrous distribués utilisent des horodatages pour l’expiration des baux. +- **Échecs de démarrage du service** — RustFS refuse de démarrer si le décalage d’horloge entre les nœuds dépasse les seuils de sécurité. :::warning -La dérive d'horloge entre deux nœuds ne doit pas dépasser **15 minutes**. Pour les environnements de production, nous recommandons de maintenir la dérive en dessous d'**1 seconde**. +La dérive d’horloge entre deux nœuds ne doit pas dépasser **15 minutes**. Pour les environnements de production, nous recommandons de maintenir la dérive en dessous d'**1 seconde**. -::: +:: : ### Outils NTP recommandés -Utilisez l'un des services de synchronisation temporelle suivants sur **chaque nœud**. Choisissez un outil et configurez-le de manière cohérente sur l'ensemble du déploiement. +Utilisez l’un des services de synchronisation temporelle suivants sur **chaque nœud**. Choisissez un outil et configurez-le de manière cohérente sur l’ensemble du déploiement. -#### chrony (Recommandé) +#### chrony (recommandé) -`chrony` est l'implémentation NTP préférée pour les distributions Linux modernes. Il synchronise plus rapidement et gère mieux la connectivité réseau intermittente que l'ancien `ntpd`. +`chrony` est l’implémentation NTP préférée pour les distributions Linux modernes. Il synchronise plus rapidement et gère mieux la connectivité réseau intermittente que l’ancien `ntpd`. -Installer chrony : +Installez chrony : ```bash # RHEL / CentOS / Rocky Linux @@ -71,7 +71,7 @@ sudo dnf install chrony -y sudo apt install chrony -y ``` -Modifiez le fichier de configuration `/etc/chrony.conf` (RHEL) ou `/etc/chrony/chrony.conf` (Debian/Ubuntu) pour pointer vers vos serveurs NTP préférés : +Modifiez le fichier de configuration `/etc/chrony.conf` (RHEL) ou `/etc/chrony/chrony.conf` (Debian/Ubuntu) pour pointer vers vos serveurs NTP préférés : ```ini server time1.google.com iburst @@ -80,9 +80,9 @@ server time3.google.com iburst server time4.google.com iburst ``` -> Remplacez les adresses serveur par les serveurs NTP internes de votre organisation, si disponibles. L'utilisation d'`iburst` accélère la synchronisation initiale. +> Remplacez les adresses serveur par les serveurs NTP internes de votre organisation, si disponibles. L’option `iburst` accélère la synchronisation initiale. -Activer et démarrer le service : +Activez et démarrez le service : ```bash sudo systemctl enable chronyd @@ -91,9 +91,9 @@ sudo systemctl start chronyd #### systemd-timesyncd -`systemd-timesyncd` est un client SNTP léger intégré aux distributions basées sur systemd. Il convient aux environnements où un démon NTP complet n'est pas nécessaire. +`systemd-timesyncd` est un client SNTP léger intégré aux distributions basées sur systemd. Il convient aux environnements où un démon NTP complet n’est pas nécessaire. -Modifiez `/etc/systemd/timesyncd.conf` pour configurer les serveurs NTP : +Modifiez `/etc/systemd/timesyncd.conf` pour configurer les serveurs NTP : ```ini [Time] @@ -101,7 +101,7 @@ NTP=time1.google.com time2.google.com time3.google.com time4.google.com FallbackNTP=0.pool.ntp.org 1.pool.ntp.org ``` -Activer et démarrer le service : +Activez et démarrez le service : ```bash sudo timedatectl set-ntp true @@ -109,9 +109,9 @@ sudo systemctl enable systemd-timesyncd sudo systemctl start systemd-timesyncd ``` -#### ntpd (Ancien) +#### ntpd (ancien) -Le classique `ntpd` de l'implémentation de référence NTP est toujours largement disponible. Utilisez `chrony` à la place, sauf si votre environnement nécessite spécifiquement `ntpd`. +Le classique `ntpd` de l’implémentation de référence NTP est toujours largement disponible. Utilisez `chrony` à la place, sauf si votre environnement nécessite spécifiquement `ntpd`. ```bash # RHEL / CentOS / Rocky Linux @@ -121,7 +121,7 @@ sudo dnf install ntp -y sudo apt install ntp -y ``` -Modifiez `/etc/ntp.conf` pour définir vos serveurs NTP, puis activez et démarrez : +Modifiez `/etc/ntp.conf` pour définir vos serveurs NTP, puis activez et démarrez : ```bash sudo systemctl enable ntpd @@ -130,9 +130,9 @@ sudo systemctl start ntpd ### Vérification de la synchronisation temporelle -Après avoir configuré le service NTP, vérifiez l'état de la synchronisation sur chaque nœud. +Après avoir configuré le service NTP, vérifiez l’état de la synchronisation sur chaque nœud. -Vérifier l'état de l'horloge système : +Vérifiez l’état de l’horloge système : ```bash timedatectl status @@ -140,32 +140,32 @@ timedatectl status La sortie doit afficher `System clock synchronized: yes` et `NTP service: active`. -Pour `chrony`, utilisez la commande suivante pour un état détaillé de la synchronisation : +Pour `chrony`, utilisez la commande suivante pour un état détaillé de la synchronisation : ```bash chronyc tracking ``` -Champs clés à vérifier : +Champs clés à vérifier : - **Leap status** — Doit être `Normal` (pas `Not synchronised`). - **System time** — Le décalage par rapport au serveur de référence. Doit être proche de `0.000000000 seconds`. - **Root delay** — Temps aller-retour vers le serveur de référence. -Lister les sources NTP actuelles et leur statut : +Listez les sources NTP actuelles et leur état : ```bash chronyc sources -v ``` -Colonnes à surveiller : +Colonnes à surveiller : - **`*`** — La source de synchronisation actuellement sélectionnée. - **`+`** — Autres sources acceptables. -- **`-`** — Sources rejetées par l'algorithme de sélection. +- **`-`** — Sources rejetées par l’algorithme de sélection. - **`?`** — Sources dont la connectivité est incertaine. -Pour `ntpd` : +Pour `ntpd` : ```bash ntpq -p @@ -173,14 +173,14 @@ ntpq -p ### Vérification de la cohérence inter-nœuds -Après la synchronisation de tous les nœuds, vérifiez que les horloges sont cohérentes dans tout le cluster. Comparez les horodatages sur chaque nœud : +Après la synchronisation de tous les nœuds, vérifiez que les horloges sont cohérentes dans tout le cluster. Comparez les horodatages sur chaque nœud : ```bash # Run on each node and compare the output date -u '+%Y-%m-%d %H:%M:%S' ``` -Pour une comparaison plus précise, installez `sshpass` et exécutez : +Pour une comparaison plus précise, installez `sshpass` et exécutez : ```bash for host in node1 node2 node3 node4; do @@ -191,43 +191,43 @@ done Dans un environnement correctement configuré, la différence entre deux nœuds doit être négligeable (inférieure à 1 milliseconde). -## Capacity Planning +## Planification de la capacité -When planning object storage capacity, we recommend considering: +Pour planifier la capacité de stockage objet, nous recommandons de prendre en compte : -- Initial data volume: How much data do you plan to migrate or store at once? (e.g., 500 TB) -- Data growth volume: Daily/weekly/monthly data growth capacity -- Planning cycle: How long should this hardware planning last? (recommended: 3 years) -- Your company's hardware iteration and update cycles. +- Volume initial : quelle quantité de données prévoyez-vous de migrer ou de stocker en une fois ? (par exemple, 500 To) +- Croissance : capacité de croissance quotidienne, hebdomadaire ou mensuelle +- Horizon : combien de temps cette planification matérielle doit-elle couvrir ? (recommandation : 3 ans) +- Cycles de renouvellement matériel de votre organisation. -Review [EC Configuration](../requirement/ec-configuration.md) to calculate usable capacity, understand the automatic parity defaults, and validate any explicit parity or erasure-set width before deployment. +Consultez la [configuration EC](../requirement/ec-configuration.md) pour calculer la capacité utile, comprendre les valeurs de parité automatiques et valider toute parité explicite ou largeur d’ensemble d’effacement avant le déploiement. -## Disk Planning +## Planification des disques -Because NFS generates phantom writes and lock issues under high I/O, **NFS is prohibited** as the underlying storage medium for RustFS. We strongly recommend **JBOD (Just a Bunch of Disks)** mode: expose physical disks directly and independently to the operating system, and let the RustFS software layer handle data redundancy and protection. +NFS produit des écritures fantômes et des problèmes de verrouillage sous forte charge d’E/S. **NFS est interdit** comme support de stockage sous-jacent pour RustFS. Nous recommandons vivement le mode **JBOD (Just a Bunch of Disks)** : exposez les disques physiques directement et individuellement au système d’exploitation, et laissez la couche logicielle RustFS assurer la redondance et la protection des données. -The reasons are as follows: +Les raisons sont les suivantes : -- **Better Performance:** RustFS's Erasure Coding engine is highly optimized and reads/writes multiple disks concurrently, achieving higher throughput than hardware RAID controllers. Hardware RAID becomes a performance bottleneck. -- **Lower Cost:** No expensive RAID cards needed, reducing hardware procurement costs. -- **Simpler Management:** RustFS manages disks uniformly, simplifying storage layer operations and maintenance. -- **Faster Fault Recovery:** The RustFS healing process is faster than a traditional RAID rebuild and has less impact on cluster performance. +- **Performances.** Le moteur de codage d’effacement de RustFS est fortement optimisé et lit ou écrit plusieurs disques en parallèle, avec un débit supérieur à celui des contrôleurs RAID matériels. Le RAID matériel devient un goulet d’étranglement. +- **Coût.** Aucune carte RAID coûteuse n’est nécessaire, ce qui réduit le coût d’acquisition. +- **Exploitation.** RustFS gère les disques de façon uniforme, ce qui simplifie l’exploitation de la couche de stockage. +- **Reprise après incident.** Le processus de réparation des données (healing) de RustFS est plus rapide qu’une reconstruction RAID classique et affecte moins les performances du cluster. -We recommend NVMe SSDs as the storage medium for higher performance and throughput. +Nous recommandons des SSD NVMe comme support de stockage, pour de meilleures performances et un meilleur débit. -## File System Selection +## Choix du système de fichiers -RustFS strongly recommends formatting all storage disks with the XFS file system. RustFS development and testing are based on XFS, ensuring optimal performance and stability. Avoid other file systems such as ext4, BTRFS, or ZFS, as they may cause performance degradation or unpredictable issues. +Nous recommandons vivement de formater tous les disques de stockage en XFS. Le développement et les tests de RustFS s’appuient sur XFS, ce qui assure les meilleures performances et la meilleure stabilité. Évitez les autres systèmes de fichiers tels que ext4, BTRFS ou ZFS : ils peuvent dégrader les performances ou provoquer des comportements imprévisibles. -XFS suits RustFS's workload for three reasons: +XFS convient à la charge de RustFS pour trois raisons : -- **High-concurrency I/O:** XFS was designed for high performance and scalability. Its internal journaling and data structures (such as B+ trees) efficiently handle large numbers of parallel read/write requests, matching how RustFS shards large objects and reads/writes multiple disks in an erasure set in parallel. -- **Massive files and large file sizes:** XFS is a 64-bit file system supporting extremely large files (up to 8 EB). Its metadata management stays efficient even with millions of files in a single directory — important because RustFS stores each object (or object version) as an independent file. -- **Space reservation:** XFS provides an efficient `fallocate` API. RustFS uses it to reserve contiguous disk space before writing objects, avoiding the overhead of dynamic expansion and metadata updates during writes and minimizing file fragmentation. +- **E/S fortement concurrentes.** XFS a été conçu pour la performance et le passage à l’échelle. Sa journalisation et ses structures internes (notamment les arbres B+) traitent efficacement un grand nombre de lectures et d’écritures parallèles, ce qui correspond à la façon dont RustFS découpe les objets volumineux et lit ou écrit plusieurs disques d’un ensemble d’effacement en parallèle. +- **Fichiers très nombreux et très volumineux.** XFS est un système de fichiers 64 bits qui prend en charge des fichiers extrêmement volumineux (jusqu’à 8 Eo). Sa gestion des métadonnées reste efficace même avec des millions de fichiers dans un seul répertoire, ce qui compte parce que RustFS stocke chaque objet (ou version d’objet) comme un fichier indépendant sur le disque. +- **Réservation d’espace.** XFS fournit une API `fallocate` efficace. RustFS l’utilise pour réserver un espace disque contigu avant d’écrire les objets, ce qui évite le coût de l’extension dynamique et des mises à jour de métadonnées pendant l’écriture, et limite la fragmentation. -For better disk discovery, we recommend using **Label** tags when formatting XFS file systems. +Pour faciliter la découverte des disques, nous recommandons d’utiliser des étiquettes **Label** lors du formatage des systèmes de fichiers XFS. -First, check the disk layout: +Vérifiez d’abord la disposition des disques : ```bash sudo lsblk @@ -241,19 +241,19 @@ nvme1n1 8:32 0 3.7T 0 disk <-- if this is our format new disk nvme2n1 8:48 0 3.7T 0 disk ``` -Format each data disk: +Formatez chaque disque de données : ```bash sudo mkfs.xfs -i size=512 -n ftype=1 -L RUSTFS0 /dev/sdb ``` -Formatting options: +Options de formatage : -- `-L