From 0c5749d8718a1294030d2f6a8a9019ddb5490a4b Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Mon, 19 Oct 2026 11:13:28 +0000 Subject: [PATCH] docs: translate the Japanese locale Translate the remaining English pages under content/ja into technical Japanese, record the locale terminology, and point internal links at /ja/. Co-authored-by: hector --- .../localize-rustfs-docs/references/ja.md | 18 +- content/ja/administration/console/index.md | 66 ++-- content/ja/administration/cors/index.md | 34 +- .../ja/administration/data/bucket/creation.md | 36 +-- .../ja/administration/data/bucket/deletion.md | 44 +-- .../ja/administration/data/bucket/policy.md | 114 +++---- .../ja/administration/data/bucket/quota.md | 130 ++++---- .../administration/data/bucket/replication.md | 242 +++++++------- .../data/lifecycle-management.md | 68 ++-- .../ja/administration/data/object/creation.md | 58 ++-- .../ja/administration/data/object/deletion.md | 38 +-- .../data/object/multipart-upload.md | 106 +++---- .../administration/data/object/object-lock.md | 92 +++--- .../ja/administration/data/object/scanner.md | 36 +-- .../administration/data/object/versioning.md | 106 +++---- content/ja/administration/data/s3-tables.md | 14 +- .../ja/administration/data/tiered-storage.md | 152 ++++----- content/ja/administration/index.md | 6 +- content/ja/administration/protocols/ftps.md | 182 +++++------ content/ja/administration/protocols/s3.md | 148 ++++----- content/ja/administration/protocols/sftp.md | 150 ++++----- content/ja/administration/protocols/webdav.md | 132 ++++---- content/ja/developer/examples/aws-cli.md | 28 +- content/ja/developer/examples/aws-sdk-go.md | 16 +- content/ja/developer/examples/aws-sdk-js.md | 16 +- content/ja/developer/examples/boto3.md | 22 +- content/ja/developer/examples/rclone.md | 24 +- content/ja/developer/examples/s3cmd.md | 20 +- content/ja/developer/examples/terraform.md | 14 +- content/ja/developer/index.md | 16 +- content/ja/developer/integration/ai/mlflow.md | 82 ++--- content/ja/developer/integration/ai/ray.md | 50 +-- content/ja/developer/integration/ai/vllm.md | 66 ++-- .../ja/developer/integration/backup/kopia.md | 52 +-- .../developer/integration/backup/longhorn.md | 82 ++--- .../ja/developer/integration/backup/restic.md | 4 +- .../ja/developer/integration/backup/velero.md | 66 ++-- .../developer/integration/big-data/airflow.md | 68 ++-- .../developer/integration/big-data/automq.md | 54 ++-- .../integration/big-data/delta-lake.md | 58 ++-- .../integration/big-data/dolphinscheduler.md | 54 ++-- .../developer/integration/big-data/flink.md | 6 +- .../ja/developer/integration/big-data/hive.md | 58 ++-- .../ja/developer/integration/big-data/hudi.md | 48 +-- .../developer/integration/big-data/iceberg.md | 6 +- .../developer/integration/big-data/kafka.md | 74 ++--- .../developer/integration/big-data/paimon.md | 48 +-- .../integration/big-data/pyiceberg.md | 6 +- .../integration/big-data/seatunnel.md | 50 +-- .../developer/integration/big-data/spark.md | 6 +- .../integration/big-data/zeppelin.md | 56 ++-- .../integration/cloud-native/celld.md | 62 ++-- .../integration/cloud-native/cortex.md | 62 ++-- .../integration/cloud-native/flux.md | 62 ++-- .../integration/database/clickhouse.md | 60 ++-- .../integration/database/databend.md | 62 ++-- .../developer/integration/database/doris.md | 72 ++--- .../developer/integration/database/duckdb.md | 4 +- .../developer/integration/database/index.md | 10 +- .../integration/database/influxdb.md | 4 +- .../developer/integration/database/lancedb.md | 58 ++-- .../developer/integration/database/milvus.md | 106 +++---- .../developer/integration/database/trino.md | 6 +- .../developer/integration/database/vitess.md | 70 ++--- .../integration/devops/elasticsearch.md | 86 ++--- .../ja/developer/integration/devops/gitea.md | 88 +++--- .../developer/integration/devops/jenkins.md | 88 +++--- .../integration/devops/opensearch.md | 74 ++--- .../developer/integration/devops/terraform.md | 68 ++-- .../integration/observability/fluentd.md | 62 ++-- .../integration/observability/greptimedb.md | 62 ++-- .../integration/observability/loki.md | 4 +- .../integration/observability/openobserve.md | 4 +- .../observability/opentelemetry.md | 60 ++-- .../integration/observability/tempo.md | 4 +- .../integration/observability/thanos.md | 88 +++--- .../observability/victoriametrics.md | 68 ++-- .../developer/integration/others/juicefs.md | 60 ++-- .../developer/integration/others/nextcloud.md | 60 ++-- .../ja/developer/integration/others/rclone.md | 70 ++--- .../ja/developer/integration/others/tusd.md | 70 ++--- .../integration/registry/docker-registry.md | 54 ++-- .../developer/integration/registry/harbor.md | 4 +- .../integration/reverse-proxy/caddy.md | 68 ++-- .../integration/reverse-proxy/envoy.md | 72 ++--- .../integration/reverse-proxy/haproxy.md | 76 ++--- .../integration/reverse-proxy/httpd.md | 158 +++++----- .../integration/reverse-proxy/index.md | 14 +- .../integration/reverse-proxy/nginx.md | 72 ++--- .../integration/reverse-proxy/traefik.md | 68 ++-- .../developer/integration/storage/alluxio.md | 58 ++-- .../ja/developer/integration/storage/index.md | 10 +- .../developer/integration/storage/lakefs.md | 60 ++-- .../developer/integration/storage/opendal.md | 52 +-- .../ja/developer/integration/storage/s3fs.md | 54 ++-- .../developer/integration/storage/sftpgo.md | 54 ++-- .../developer/integration/storage/zerofs.md | 72 ++--- content/ja/developer/license.md | 269 +++++----------- content/ja/developer/mcp.md | 154 ++++----- content/ja/developer/sdk/go.md | 48 +-- content/ja/developer/sdk/index.md | 40 ++- content/ja/developer/sdk/java.md | 102 +++--- content/ja/developer/sdk/javascript.md | 82 ++--- content/ja/developer/sdk/other.md | 68 ++-- content/ja/developer/sdk/python.md | 100 +++--- content/ja/developer/sdk/rust.md | 50 +-- content/ja/developer/sdk/typescript.md | 42 +-- .../cloud-native/helm-chart/cert-manager.md | 32 +- .../cloud-native/helm-chart/index.md | 24 +- .../cloud-native/helm-chart/installation.mdx | 86 ++--- .../cloud-native/helm-chart/mtls.md | 32 +- content/ja/installation/cloud-native/index.md | 130 ++++---- .../cloud-native/operator/index.md | 32 +- .../cloud-native/operator/installation.md | 52 +-- .../installation/cloud-native/operator/kms.md | 36 +-- .../cloud-native/operator/pool-expansion.md | 24 +- .../cloud-native/operator/tenant.md | 28 +- content/ja/installation/container/docker.md | 76 ++--- content/ja/installation/container/index.md | 20 +- content/ja/installation/container/podman.md | 36 +-- content/ja/installation/index.md | 44 +-- content/ja/installation/linux/index.md | 32 +- .../linux/multiple-node-multiple-disk.md | 62 ++-- .../linux/prerequisites-and-service.md | 2 +- content/ja/installation/linux/quick-start.md | 65 ++-- .../linux/single-node-multiple-disk.md | 48 +-- .../linux/single-node-single-disk.md | 46 +-- content/ja/installation/macos/index.md | 210 ++++++------- .../checklists/hardware-checklists.md | 172 +++++----- .../checklists/hardware-selection.md | 60 ++-- .../requirement/checklists/index.md | 24 +- .../checklists/network-checklists.md | 108 +++---- .../checklists/security-checklists.md | 94 +++--- .../checklists/software-checklists.md | 68 ++-- .../requirement/disk-preparation.md | 48 +-- .../requirement/ec-configuration.md | 94 +++--- content/ja/installation/windows/index.md | 174 +++++----- content/ja/integration/tls-configured.md | 34 +- content/ja/integration/virtual.md | 51 +-- content/ja/operations/cluster-lifecycle.md | 246 +++++++-------- content/ja/operations/credentials.md | 84 ++--- content/ja/operations/event-notifications.md | 116 +++---- .../ja/operations/high-availability/index.md | 8 +- .../high-availability/node-healing.md | 192 ++++++------ .../high-availability/site-replication.md | 158 +++++----- content/ja/operations/index.md | 22 +- content/ja/operations/observability.md | 244 +++++++-------- content/ja/operations/rc.mdx | 68 ++-- .../ja/operations/scaling/data-rebalancing.md | 72 ++--- content/ja/operations/scaling/index.md | 12 +- .../scaling/storage-pool-decommission.md | 96 +++--- .../scaling/storage-pool-expansion.md | 86 ++--- content/ja/operations/status-check.md | 92 +++--- content/ja/operations/upgrade/binary/index.md | 26 +- .../ja/operations/upgrade/container/index.md | 66 ++-- content/ja/operations/upgrade/index.md | 16 +- .../ja/operations/upgrade/kubernetes/index.md | 82 ++--- content/ja/reference/cli.md | 108 +++---- content/ja/reference/environment-variables.md | 296 +++++++++--------- content/ja/reference/index.md | 12 +- content/ja/security-compliance/audit-logs.md | 104 +++--- .../security-compliance/encryption/index.md | 16 +- .../ja/security-compliance/encryption/kms.md | 102 +++--- .../security-compliance/encryption/sse-c.md | 56 ++-- .../security-compliance/encryption/sse-s.md | 46 +-- .../security-compliance/iam/access-token.md | 36 +-- content/ja/security-compliance/iam/index.md | 66 ++-- .../ja/security-compliance/iam/policies.md | 4 +- content/ja/security-compliance/iam/sts.md | 90 +++--- content/ja/security-compliance/index.md | 20 +- content/ja/security-compliance/oidc/gitlab.md | 138 ++++---- content/ja/security-compliance/oidc/index.md | 48 +-- .../ja/security-compliance/oidc/keycloak.md | 2 +- content/ja/troubleshooting/driver.md | 91 +++--- content/ja/troubleshooting/index.md | 13 +- content/ja/troubleshooting/node.md | 84 ++--- 176 files changed, 5829 insertions(+), 5910 deletions(-) diff --git a/.agents/skills/localize-rustfs-docs/references/ja.md b/.agents/skills/localize-rustfs-docs/references/ja.md index ae5fa255f..c8b375339 100644 --- a/.agents/skills/localize-rustfs-docs/references/ja.md +++ b/.agents/skills/localize-rustfs-docs/references/ja.md @@ -54,8 +54,22 @@ Treat RustFS source code, APIs, and exact Console labels as authoritative for pr | multipart upload | マルチパートアップロード | Preserve API actions such as `CreateMultipartUpload`. | | server-side encryption | サーバー側の暗号化 | Keep SSE-S3, SSE-KMS, and SSE-C unchanged. | | presigned URL | 署名付き URL | Keep URL uppercase and preserve API names. | -| path-style addressing | パス形式のアドレス指定 | Preserve SDK option names. | -| virtual-hosted-style addressing | 仮想ホスト形式のアドレス指定 | Relate it to `RUSTFS_SERVER_DOMAINS` when relevant. | +| path-style addressing | パススタイルアクセス | Preserve SDK option names such as `forcePathStyle`. Do not use パス形式のアドレス指定. | +| virtual-hosted-style addressing | 仮想ホスト形式 | バーチャルホストスタイル is acceptable. Relate it to `RUSTFS_SERVER_DOMAINS` when relevant. Preserve SDK option names. | +| cluster | クラスター | Keep the long vowel. Do not write クラスタ. | +| deployment | デプロイ | Prefer this over デプロイメント. | +| interface | インターフェース | Do not write インターフェイス. | +| matrix | マトリックス | Do not write マトリクス. | +| compatibility gate | 互換性検証（ゲート） | Explain the gate on first use. | +| executable test list | 実行対象のテストリスト | Do not write 実行可能なテストリスト. | +| Planned (status) | 未実装（予定） | Do not use 予定 alone. | +| round-trip | 往復検証 | A parenthetical round-trip is optional. | +| credential vending | 認証情報ベンディング / 一時認証情報の発行 | Do not write 認証情報の払い出し. | +| authorized principal | 認可されたプリンシパル | Do not write 認可済みの主体. | +| backend | バックエンド | Do not leave the English word in prose. | +| repository | リポジトリ | Do not leave Repository in prose. | +| Next steps | 次のステップ | Do not write 次の手順. | +| overview / product introduction | 概要 | Do not use 製品紹介 for a technical introduction. | | health check | ヘルスチェック | Preserve endpoint paths and probe names. | | readiness | Readiness / 準備完了状態 | Preserve `/health/ready` and Kubernetes field names. | | observability | オブザーバビリティ | Keep OpenTelemetry and OTLP unchanged. | diff --git a/content/ja/administration/console/index.md b/content/ja/administration/console/index.md index e8af749ff..8e6933116 100644 --- a/content/ja/administration/console/index.md +++ b/content/ja/administration/console/index.md @@ -1,13 +1,13 @@ --- -title: "Console" -description: "Enable the RustFS Console, connect it to a server, and sign in securely." +title: "コンソール" +description: "RustFS Console を有効にし、サーバーへ接続して、安全にサインインします。" --- -The **RustFS Console** is the web administration interface for RustFS. Use this page to enable the Console, open the login page, and choose the appropriate sign-in method. Detailed procedures for buckets, objects, and identity management are covered in their respective documentation sections. +**RustFS Console** は、RustFS の Web 管理インターフェースです。このページでは、Console の有効化、ログインページを開く手順、適切なサインイン方法の選択を説明します。バケット、オブジェクト、アイデンティティ管理の詳しい手順は、それぞれのドキュメントで扱います。 -## Enable the Console +## Console を有効にする -The Console is enabled by default and listens on port `9001`, separately from the S3 API on port `9000`. You can set the behavior explicitly with the following environment variables: +Console は既定で有効であり、ポート `9000` の S3 API とは別に、ポート `9001` で待ち受けます。次の環境変数で、動作を明示的に設定できます。 ```ini title="/etc/default/rustfs" RUSTFS_ADDRESS=":9000" @@ -17,56 +17,56 @@ RUSTFS_OBS_LOGGER_LEVEL=error RUSTFS_OBS_LOG_DIRECTORY="/var/log/rustfs/" ``` -Restart RustFS after changing these values. Set `RUSTFS_CONSOLE_ENABLE=false` when the Console must not run. +これらの値を変更したあとは、RustFS を再起動します。Console を実行してはならない場合は、`RUSTFS_CONSOLE_ENABLE=false` を設定します。 -The equivalent command-line options are `--console-enable` and `--console-address`. See the [CLI reference](/reference/cli) and [environment variable reference](/reference/environment-variables) for the complete server configuration. +同等のコマンドラインオプションは `--console-enable` と `--console-address` です。サーバー設定の全体は、[CLI リファレンス](/ja/reference/cli) と [環境変数リファレンス](/ja/reference/environment-variables) を参照します。 -## Open the Console +## Console を開く -Open the following address, replacing `` with the RustFS server address: +`` を RustFS サーバーのアドレスに置き換えて、次のアドレスを開きます。 ```text http://:9001 ``` -![RustFS Console login page with key, STS, and OIDC sign-in options](./images/rustfs-console-login.png) +![キー、STS、OIDC のサインイン方法を示す RustFS Console のログインページ](./images/rustfs-console-login.png) -For a local deployment, use `http://localhost:9001`. Windows and macOS desktop launchers use port `7001` instead. +Windows および macOS のデスクトップランチャーを含むローカルデプロイでは、`http://localhost:9001` を開きます。S3 API はポート `9000` で待ち受けます。 -If the login page cannot reach the target RustFS service, select **Server Configuration** or open `/config`. Enter the externally reachable RustFS service address and save it after the health check succeeds. **Reset** clears the saved address; **Skip** returns to login without changing it. +ログインページから対象の RustFS サービスへ到達できない場合は、**Server Configuration**（サーバー設定）を選ぶか、`/config` を開きます。外部から到達できる RustFS サービスのアドレスを入力し、ヘルスチェックが成功してから保存します。**Reset**（リセット）は、保存したアドレスを消去します。**Skip**（スキップ）は、アドレスを変更せずにログインへ戻ります。 -## Log in +## ログイン -The login methods shown depend on the deployment configuration: +表示されるログイン方法は、デプロイの設定によって異なります。 -- **Key Login** uses the access key and secret key configured for the RustFS deployment. This is the standard login method for a local administrator. -- **STS Login** uses temporary Security Token Service (STS) credentials. Use it only when your identity workflow has issued a valid session token. -- **OIDC Login** appears when an OpenID Connect (OIDC) provider is configured. Select the provider and complete authentication with the identity provider. +- **Key Login**（キーによるログイン）は、RustFS デプロイに設定したアクセスキーとシークレットキーを使います。ローカル管理者の標準的なログイン方法です。 +- **STS Login**（STS ログイン）は、一時的な Security Token Service（STS）の認証情報を使います。アイデンティティのワークフローが有効なセッショントークンを発行している場合にだけ使います。 +- **OIDC Login**（OIDC ログイン）は、OpenID Connect（OIDC）プロバイダーを設定しているときに表示されます。プロバイダーを選び、アイデンティティプロバイダーで認証を完了します。 -After login, the Console opens the first page your account can access. Menus and actions vary by account policy and enabled platform capabilities; a missing menu does not necessarily indicate a Console error. +ログインすると、Console はそのアカウントがアクセスできる最初のページを開きます。メニューと操作は、アカウントのポリシーと、有効になっているプラットフォーム機能によって異なります。メニューが表示されないことは、必ずしも Console のエラーを意味しません。 -If login fails, verify the selected login method, credentials, target server address, and account status before retrying. +ログインに失敗した場合は、再試行する前に、選択したログイン方法、認証情報、対象サーバーのアドレス、アカウントの状態を確認します。 -:::warning[Do not expose default credentials] +:::warning[既定の認証情報を公開しない] -RustFS falls back to `rustfsadmin` / `rustfsadmin` when custom credentials are not configured. Use these defaults only for a throwaway local test. Configure a unique access key and a strong secret key before making the Console reachable by other users. +カスタムの認証情報を設定していない場合、RustFS は `rustfsadmin` / `rustfsadmin` にフォールバックします。これらの既定値は、使い捨てるローカルテストにだけ使います。ほかのユーザーから Console へ到達できるようにする前に、固有のアクセスキーと強いシークレットキーを設定します。 ::: -## Operational notes +## 運用上の注意 -- Use [TLS](/integration/tls-configured) before exposing the Console outside a trusted network. -- Restrict network access to the Console listener and configure [Console CORS](/administration/cors) only when cross-origin access is required. -- The Console session inherits the permissions of the signed-in identity. Use a least-privilege account for routine work. -- Signing out or an expired session returns you to the login page. Do not store administrator credentials in shared browsers. +- 信頼できるネットワークの外へ Console を公開する前に、[TLS](/ja/integration/tls-configured) を使います。 +- Console のリスナーへのネットワークアクセスを制限し、クロスオリジンアクセスが必要な場合にだけ [Console の CORS](/ja/administration/cors) を設定します。 +- Console のセッションは、サインインしたアイデンティティの権限を継承します。日常の作業には、最小権限のアカウントを使います。 +- サインアウトしたとき、またはセッションの有効期限が切れたときは、ログインページに戻ります。共有ブラウザに管理者の認証情報を保存してはなりません。 -## Management workflows +## 管理ワークフロー -- [Create and manage buckets](/administration/data/bucket/creation) -- [Upload and manage objects](/administration/data/object/creation) -- [Manage access keys](/security-compliance/iam/access-token) -- [Configure identity and access management](/security-compliance/iam) +- [バケットを作成して管理する](/ja/administration/data/bucket/creation) +- [オブジェクトをアップロードして管理する](/ja/administration/data/object/creation) +- [アクセスキーを管理する](/ja/security-compliance/iam/access-token) +- [アイデンティティとアクセス管理を設定する](/ja/security-compliance/iam) -## Next steps +## 次のステップ -Review the [security checklist](/installation/requirement/checklists/security-checklists) before exposing the Console outside a trusted network. For OIDC-based login, continue with the [OIDC configuration guide](/security-compliance/oidc). +信頼できるネットワークの外へ Console を公開する前に、[セキュリティチェックリスト](/ja/installation/requirement/checklists/security-checklists) を確認します。OIDC によるログインは、[OIDC 設定ガイド](/ja/security-compliance/oidc) に進みます。 diff --git a/content/ja/administration/cors/index.md b/content/ja/administration/cors/index.md index d4e52db44..20ed547f1 100644 --- a/content/ja/administration/cors/index.md +++ b/content/ja/administration/cors/index.md @@ -1,41 +1,41 @@ --- -title: "CORS Configuration" -description: "Configure allowed browser origins for the RustFS S3 API and Console." +title: "CORS の設定" +description: "RustFS の S3 API と Console について、ブラウザから許可するオリジンを設定します。" --- -Cross-Origin Resource Sharing (CORS) controls which browser origins can access the RustFS S3 API and Console. Configure each listener separately, then restart RustFS to apply the environment changes. +Cross-Origin Resource Sharing（CORS）は、どのブラウザオリジンが RustFS の S3 API と Console にアクセスできるかを制御します。リスナーごとに設定したあと、環境変数の変更を反映するために RustFS を再起動します。 -## S3 API origins +## S3 API のオリジン -Set `RUSTFS_CORS_ALLOWED_ORIGINS` to a comma-separated list of trusted origins: +`RUSTFS_CORS_ALLOWED_ORIGINS` に、信頼できるオリジンをカンマ区切りで設定します。 ```ini title="/etc/default/rustfs" RUSTFS_CORS_ALLOWED_ORIGINS="https://app.example.com,https://admin.example.com" ``` -When this variable is unset or empty, the S3 endpoint does not add generic CORS response headers. A list of explicit origins allows credentialed browser requests from matching origins. +この変数が未設定または空のとき、S3 エンドポイントは汎用の CORS 応答ヘッダーを付加しません。明示したオリジンの一覧を設定すると、一致するオリジンからの、認証情報を伴うブラウザリクエストが許可されます。 -You can set the value to `*` to allow requests from any origin. Wildcard mode does not allow browser credentials. +任意のオリジンからのリクエストを許可するには、値を `*` にできます。ワイルドカードモードでは、ブラウザの認証情報は許可されません。 -:::warning[Use explicit origins in production] +:::warning[本番では明示したオリジンを使う] -Use a comma-separated allowlist for applications that send credentials. Reserve `*` for public resources that do not require credentialed browser requests. +認証情報を送信するアプリケーションには、カンマ区切りの許可リストを使います。認証情報を伴うブラウザリクエストが不要な公開リソースに限り、`*` を使います。 ::: -## Console origins +## Console のオリジン -The Console uses a separate variable: +Console は、別の変数を使います。 ```ini title="/etc/default/rustfs" RUSTFS_CONSOLE_CORS_ALLOWED_ORIGINS="https://admin.example.com" ``` -Use a comma-separated list when more than one browser origin must access the Console. Set `*` only when any origin must be allowed. +複数のブラウザオリジンが Console にアクセスする必要がある場合は、カンマ区切りの一覧を使います。任意のオリジンを許可する必要がある場合にだけ、`*` を設定します。 -## Verify the response +## 応答を確認する -Send a request with an `Origin` header and inspect the CORS response headers: +`Origin` ヘッダーを付けてリクエストを送り、CORS の応答ヘッダーを確認します。 ```bash curl -i \ @@ -43,8 +43,8 @@ curl -i \ http://localhost:9000/ ``` -Confirm that `Access-Control-Allow-Origin` contains the expected origin. Repeat the check with an unlisted origin and confirm that it is not allowed. +`Access-Control-Allow-Origin` に、想定したオリジンが含まれていることを確認します。一覧にないオリジンでも確認を繰り返し、許可されていないことを確認します。 -## Next steps +## 次のステップ -See the [environment variable reference](/reference/environment-variables#cors) for the verified defaults and configuration formats. \ No newline at end of file +検証済みの既定値と設定形式は、[環境変数リファレンス](/ja/reference/environment-variables#cors) を参照します。 diff --git a/content/ja/administration/data/bucket/creation.md b/content/ja/administration/data/bucket/creation.md index 46804ffcf..414a508f1 100644 --- a/content/ja/administration/data/bucket/creation.md +++ b/content/ja/administration/data/bucket/creation.md @@ -1,28 +1,28 @@ --- -title: "RustFS Bucket Creation" -description: "Create buckets using the RustFS UI, rc, or the S3 API." +title: "バケットの作成" +description: "RustFS の UI、rc、または S3 API を使ってバケットを作成します。" --- -This guide explains how to create buckets using the RustFS UI, `rc`, or the S3 API. +このガイドでは、RustFS の UI、`rc`、または S3 API を使ってバケットを作成する方法を説明します。 -## Requirements +## 要件 -- A running RustFS instance (see [Installation Guide](../../../installation/index.md)). -- [`rc`](/operations/rc) installed and configured with an alias for the command-line workflow. +- 稼働中の RustFS インスタンス（[インストールガイド](../../../installation/index.md) を参照）。 +- コマンドラインの手順では、[`rc`](/ja/operations/rc) をインストールし、エイリアスを設定します。 -## Using the RustFS UI +## RustFS Console を使う -1. Log in to the RustFS Console. -2. On the Buckets page, in the top right corner, select **Create Bucket**. -3. Enter the bucket name and click **Create** to complete bucket creation. +1. RustFS Console にログインします。 +2. **Buckets**（バケット）のページで、右上の **Create Bucket**（バケットを作成）を選びます。 +3. バケット名を入力し、**Create**（作成）を選びます。 -![bucket creation](images/bucket-creation-by-ui.png) +![バケットの作成](images/bucket-creation-by-ui.png) -## Using `rc` +## `rc` を使う -See the [`rc` guide](/operations/rc) for installation and alias configuration. +インストールとエイリアスの設定は、[`rc` ガイド](/ja/operations/rc) を参照します。 -Create a bucket: +バケットを作成します。 ```bash rc bucket create rustfs/my-bucket @@ -33,15 +33,15 @@ rc bucket list rustfs/ ✓ Bucket 'rustfs/my-bucket' created successfully. ``` -## Using the API +## API を使う -Create a bucket via API: +API でバケットを作成します。 ```http PUT /{bucketName} HTTP/1.1 ``` -S3 requests must be signed with AWS Signature V4, so use an S3 client rather than hand-crafting headers. With the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) configured for your access keys: +S3 リクエストは、AWS 署名バージョン 4 で署名する必要があります。ヘッダーを手作業で組み立てず、S3 クライアントを使います。アクセスキーを設定した [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) では、次のように実行します。 ```bash aws s3api create-bucket \ @@ -49,4 +49,4 @@ aws s3api create-bucket \ --endpoint-url http://localhost:9000 ``` -Verify the bucket creation in the RustFS Console. +RustFS Console に、そのバケットが表示されることを確認します。 diff --git a/content/ja/administration/data/bucket/deletion.md b/content/ja/administration/data/bucket/deletion.md index b2234a810..5400a7b27 100644 --- a/content/ja/administration/data/bucket/deletion.md +++ b/content/ja/administration/data/bucket/deletion.md @@ -1,31 +1,35 @@ --- -title: "RustFS Bucket Deletion" -description: "Delete buckets using the RustFS UI, rc, or the S3 API." +title: "バケットの削除" +description: "RustFS の UI、rc、または S3 API を使ってバケットを削除します。" --- -This guide explains how to delete buckets using the RustFS UI, `rc`, or the S3 API. +このガイドでは、RustFS の UI、`rc`、または S3 API を使ってバケットを削除する方法を説明します。 -## Requirements +## 要件 -- Install and configure [`rc`](/operations/rc) before using the command-line workflow. -- Empty the target bucket before deleting it, or use `--force` only after reviewing the objects that will be removed. +- コマンドラインの手順を使う前に、[`rc`](/ja/operations/rc) をインストールして設定します。 +- 削除する前に対象のバケットを空にするか、削除されるオブジェクトを確認したうえでだけ `--force` を使います。 -**Warning**: Deleting a bucket is irreversible and may break applications relying on it. Ensure you have backed up any necessary data before proceeding. +:::warning[削除は元に戻せません] -## Using the RustFS UI +バケットの削除は取り消せず、そのバケットに依存するアプリケーションが動作しなくなることがあります。続行する前に、必要なデータをバックアップします。 -1. Log in to the RustFS Console. -2. On the homepage, select the bucket you want to delete. -3. On the far right, select the **Delete** button. -4. In the popup dialog, click **Confirm** to complete bucket deletion. +::: -![bucket deletion](images/bucket-deletion-on-ui.png) +## RustFS UI を使う -## Using `rc` +1. RustFS Console にログインします。 +2. ホームページで、削除するバケットを選びます。 +3. 右端の **Delete**（削除）を選びます。 +4. 確認ダイアログで **Confirm**（確認）を選びます。 -See the [`rc` guide](/operations/rc) for installation and alias configuration. +![バケットの削除](images/bucket-deletion-on-ui.png) -Delete a bucket: +## `rc` を使う + +インストールとエイリアスの設定は、[`rc` ガイド](/ja/operations/rc) を参照します。 + +バケットを削除します。 ```bash rc bucket remove rustfs/my-bucket @@ -35,15 +39,15 @@ rc bucket remove rustfs/my-bucket ✓ Bucket 'rustfs/my-bucket' removed successfully. ``` -## Using the API +## API を使う -Delete a bucket via API: +API でバケットを削除します。 ```http DELETE /{bucketName} HTTP/1.1 ``` -S3 requests must be signed with AWS Signature V4, so use an S3 client rather than hand-crafting headers. With the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) configured for your access keys: +S3 リクエストは、AWS 署名バージョン 4 で署名する必要があります。ヘッダーを手作業で組み立てず、S3 クライアントを使います。アクセスキーを設定した [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) では、次のように実行します。 ```bash aws s3api delete-bucket \ @@ -51,4 +55,4 @@ aws s3api delete-bucket \ --endpoint-url http://localhost:9000 ``` -Verify the bucket deletion in the RustFS Console. +RustFS Console で、バケットが削除されたことを確認します。 diff --git a/content/ja/administration/data/bucket/policy.md b/content/ja/administration/data/bucket/policy.md index c13c11b50..c335549bb 100644 --- a/content/ja/administration/data/bucket/policy.md +++ b/content/ja/administration/data/bucket/policy.md @@ -1,58 +1,58 @@ --- -title: "Bucket Policy" -description: "Create, apply, inspect, and verify RustFS bucket policies with the S3 API." +title: "バケットポリシー" +description: "S3 API を使い、RustFS のバケットポリシーを作成、適用、確認、検証します。" --- -RustFS bucket policies are S3-compatible resource policies attached directly to a bucket. Use them to grant or deny access to the bucket and its objects, including controlled anonymous access for public downloads. +RustFS のバケットポリシーは、バケットに直接付与する S3 互換のリソースポリシーです。バケットとそのオブジェクトへのアクセスを許可または拒否するために使います。公開ダウンロード向けに、許可範囲を定めた匿名アクセスも含められます。 -## Overview +## 概要 -A bucket policy contains one or more statements that match a principal, action, resource, and optional conditions. RustFS evaluates the policy for requests to the bucket before allowing the storage operation. +バケットポリシーは、プリンシパル、アクション、リソース、任意の条件に一致する 1 つ以上のステートメントを含みます。RustFS は、ストレージ操作を許可する前に、そのバケットへのリクエストに対してポリシーを評価します。 -Bucket policies and IAM policies serve different purposes: +バケットポリシーと IAM ポリシーは、目的が異なります。 -| Policy type | Attached to | Typical use | +| ポリシーの種類 | 付与先 | 典型的な用途 | | --- | --- | --- | -| Bucket policy | A bucket | Grant public access, add resource-level restrictions, or authorize access to one bucket. | -| IAM policy | A user or group | Define what an authenticated identity can do across one or more resources. | +| バケットポリシー | バケット | 公開アクセスの許可、リソース単位の制限の追加、または 1 つのバケットへのアクセス認可。 | +| IAM ポリシー | ユーザーまたはグループ | 認証済みアイデンティティが、1 つ以上のリソースに対して実行できる操作の定義。 | -An explicit `Deny` takes precedence over an `Allow`. Bucket owners remain able to get, replace, or delete the bucket policy so that a deny statement cannot permanently lock policy administration. +明示的な `Deny` は `Allow` より優先されます。バケット所有者は、バケットポリシーの取得、置換、削除を引き続き実行できます。拒否ステートメントによって、ポリシー管理が恒久的にロックされることはありません。 -RustFS implements the standard S3 operations `PutBucketPolicy`, `GetBucketPolicy`, `GetBucketPolicyStatus`, and `DeleteBucketPolicy`. +RustFS は、標準の S3 操作である `PutBucketPolicy`、`GetBucketPolicy`、`GetBucketPolicyStatus`、`DeleteBucketPolicy` を実装しています。 -:::warning[Public policies] +:::warning[公開ポリシー] -A statement with `"Principal": "*"` can grant access without authentication. Keep the action and resource scope as narrow as possible, and verify the result anonymously before using the policy in production. +`"Principal": "*"` を含むステートメントは、認証なしのアクセスを許可できます。アクションとリソースの範囲はできる限り狭く保ち、本番で使う前に、認証しないリクエストで結果を確認します。 ::: -## Configuration +## 設定 -### Requirements +### 要件 -- Create the target bucket before applying a policy. -- Configure the AWS CLI with a RustFS credential and region `us-east-1`. -- Use a credential allowed to perform the required policy-management action. +- ポリシーを適用する前に、対象のバケットを作成します。 +- AWS CLI に、RustFS の認証情報とリージョン `us-east-1` を設定します。 +- 必要なポリシー管理アクションを許可された認証情報を使います。 -Set reusable variables: +再利用する変数を設定します。 ```bash export RUSTFS_ENDPOINT=http://localhost:9000 export BUCKET_NAME=my-bucket ``` -Policy management requires these actions: +ポリシー管理には、次のアクションが必要です。 -| Operation | Required action | +| 操作 | 必要なアクション | | --- | --- | -| Apply or replace a policy | `s3:PutBucketPolicy` | -| Read a policy | `s3:GetBucketPolicy` | -| Read public status | `s3:GetBucketPolicyStatus` | -| Remove a policy | `s3:DeleteBucketPolicy` | +| ポリシーの適用または置換 | `s3:PutBucketPolicy` | +| ポリシーの読み取り | `s3:GetBucketPolicy` | +| 公開状態の読み取り | `s3:GetBucketPolicyStatus` | +| ポリシーの削除 | `s3:DeleteBucketPolicy` | -### Policy document structure +### ポリシードキュメントの構造 -A bucket policy uses version `2012-10-17` and a `Statement` array: +バケットポリシーは、バージョン `2012-10-17` と `Statement` 配列を使います。 ```json { @@ -69,26 +69,26 @@ A bucket policy uses version `2012-10-17` and a `Statement` array: } ``` -The bucket ARN and object ARN are different: +バケットの ARN とオブジェクトの ARN は異なります。 -| Resource | ARN format | Example actions | +| リソース | ARN の形式 | アクションの例 | | --- | --- | --- | -| Bucket | `arn:aws:s3:::my-bucket` | `s3:ListBucket`, `s3:GetBucketLocation` | -| Objects | `arn:aws:s3:::my-bucket/*` | `s3:GetObject`, `s3:PutObject`, `s3:DeleteObject` | +| バケット | `arn:aws:s3:::my-bucket` | `s3:ListBucket`、`s3:GetBucketLocation` | +| オブジェクト | `arn:aws:s3:::my-bucket/*` | `s3:GetObject`、`s3:PutObject`、`s3:DeleteObject` | -Use a prefix in the object ARN, such as `arn:aws:s3:::my-bucket/public/*`, to limit access to part of the bucket. For the complete statement format and supported condition operators, see [Users, Groups, and Policies](/security-compliance/iam/policies#policy-document-format). +オブジェクト ARN に `arn:aws:s3:::my-bucket/public/*` のようなプレフィックスを使い、バケットの一部へアクセスを限定します。ステートメント形式の全体と、対応している条件演算子は、[ユーザー、グループ、ポリシー](/ja/security-compliance/iam/policies#policy-document-format) を参照します。 -### Public Access Block +### パブリックアクセスブロック -If the bucket's Public Access Block configuration has `BlockPublicPolicy` enabled, RustFS rejects a new policy containing an `Allow` statement with a wildcard principal. Keep this protection enabled unless anonymous access is intentional. +バケットのパブリックアクセスブロック設定で `BlockPublicPolicy` が有効な場合、RustFS は、ワイルドカードのプリンシパルを持つ `Allow` ステートメントを含む新しいポリシーを拒否します。匿名アクセスが意図的である場合を除き、この保護は有効なままにします。 -Public Access Block does not replace careful policy review. An existing explicit `Deny` still overrides allows, and authenticated requests continue to be evaluated against IAM and bucket policies. +パブリックアクセスブロックは、慎重なポリシー確認の代わりにはなりません。既存の明示的な `Deny` は引き続き許可より優先され、認証済みリクエストは引き続き IAM ポリシーとバケットポリシーに照らして評価されます。 -## Usage +## 使い方 -### Create a public-read policy +### 公開読み取りポリシーを作成する -Create a policy that allows anonymous downloads only from the `public/` prefix: +`public/` プレフィックスからの匿名ダウンロードだけを許可するポリシーを作成します。 ```bash cat > /tmp/my-bucket-policy.json <<'EOF' @@ -107,9 +107,9 @@ cat > /tmp/my-bucket-policy.json <<'EOF' EOF ``` -This policy does not allow anonymous bucket listing, uploads, overwrites, or deletes. +このポリシーは、匿名でのバケット一覧、アップロード、上書き、削除を許可しません。 -### Apply the policy +### ポリシーを適用する ```bash aws s3api put-bucket-policy \ @@ -118,9 +118,9 @@ aws s3api put-bucket-policy \ --endpoint-url "$RUSTFS_ENDPOINT" ``` -Applying another policy replaces the complete existing policy. Retrieve and review the current document before updating it; statements are not merged automatically. +別のポリシーを適用すると、既存のポリシー全体が置き換わります。更新する前に、現在のドキュメントを取得して確認します。ステートメントは自動ではマージされません。 -### Read the policy +### ポリシーを読み取る ```bash aws s3api get-bucket-policy \ @@ -130,9 +130,9 @@ aws s3api get-bucket-policy \ --output text ``` -RustFS preserves the submitted policy JSON. If no policy exists, the API returns `NoSuchBucketPolicy`. +RustFS は、送信されたポリシー JSON をそのまま保持します。ポリシーが存在しない場合、API は `NoSuchBucketPolicy` を返します。 -### Check public status +### 公開状態を確認する ```bash aws s3api get-bucket-policy-status \ @@ -140,7 +140,7 @@ aws s3api get-bucket-policy-status \ --endpoint-url "$RUSTFS_ENDPOINT" ``` -The response contains a high-level public-access status: +応答には、概要レベルの公開アクセス状態が含まれます。 ```json { @@ -150,9 +150,9 @@ The response contains a high-level public-access status: } ``` -The current status check detects anonymous bucket listing (`s3:ListBucket`) and uploads (`s3:PutObject`). A policy that exposes only object downloads, such as the `public/` example above, can still report `false`. Always test the exact anonymous action, object prefix, and conditions instead of treating this status as a complete access analysis. +現在の状態確認が検出するのは、匿名のバケット一覧（`s3:ListBucket`）とアップロード（`s3:PutObject`）です。上の `public/` の例のように、オブジェクトのダウンロードだけを公開するポリシーでも、`false` と報告されることがあります。この状態を網羅的なアクセス分析として扱わず、匿名で行う具体的なアクション、オブジェクトのプレフィックス、条件を必ずテストします。 -### Remove the policy +### ポリシーを削除する ```bash aws s3api delete-bucket-policy \ @@ -160,11 +160,11 @@ aws s3api delete-bucket-policy \ --endpoint-url "$RUSTFS_ENDPOINT" ``` -Deleting a bucket policy removes only that resource policy. IAM policies attached to users and groups remain unchanged. +バケットポリシーを削除しても、取り除かれるのはそのリソースポリシーだけです。ユーザーとグループにアタッチされた IAM ポリシーは変わりません。 -## Verification +## 検証 -Upload a test object with an authenticated credential: +認証済みの認証情報で、テスト用オブジェクトをアップロードします。 ```bash printf 'hello from RustFS\n' > /tmp/hello.txt @@ -176,14 +176,14 @@ aws s3api put-object \ --endpoint-url "$RUSTFS_ENDPOINT" ``` -Verify that the allowed object can be downloaded without credentials: +許可されたオブジェクトを、認証情報なしでダウンロードできることを確認します。 ```bash curl --fail-with-body \ "${RUSTFS_ENDPOINT}/${BUCKET_NAME}/public/hello.txt" ``` -Then verify that an object outside the allowed prefix is not public: +次に、許可されたプレフィックスの外にあるオブジェクトが公開されていないことを確認します。 ```bash aws s3api put-object \ @@ -196,10 +196,10 @@ curl --fail-with-body \ "${RUSTFS_ENDPOINT}/${BUCKET_NAME}/private/hello.txt" ``` -The second `curl` request should fail with `AccessDenied`. Also test each authenticated user role that relies on the policy, especially when the document contains conditions or explicit deny statements. +2 回目の `curl` リクエストは、`AccessDenied` で失敗するはずです。ポリシーに依存する認証済みユーザーの役割も、それぞれテストします。ドキュメントに条件や明示的な拒否ステートメントが含まれる場合は、特に確認します。 -## Next steps +## 次のステップ -- [Manage IAM policies](/security-compliance/iam/policies) -- [Manage credentials](/operations/credentials) -- [Configure audit logs](/security-compliance/audit-logs) \ No newline at end of file +- [IAM ポリシーを管理する](/ja/security-compliance/iam/policies) +- [認証情報を管理する](/ja/operations/credentials) +- [監査ログを設定する](/ja/security-compliance/audit-logs) diff --git a/content/ja/administration/data/bucket/quota.md b/content/ja/administration/data/bucket/quota.md index ef975aac0..4959d795a 100644 --- a/content/ja/administration/data/bucket/quota.md +++ b/content/ja/administration/data/bucket/quota.md @@ -1,47 +1,47 @@ --- -title: "Bucket Quota" -description: "Configure, inspect, and verify hard storage quotas for individual RustFS buckets." +title: "バケットクォータ" +description: "個々の RustFS バケットに、ハードなストレージクォータを設定、確認、検証します。" --- -RustFS bucket quotas limit the total object data stored in an individual bucket. Use a quota to prevent one workload from consuming more than its assigned capacity while allowing other buckets to use the remaining storage. +RustFS のバケットクォータは、個々のバケットに保存するオブジェクトデータの合計を制限します。クォータを使うと、1 つのワークロードが割り当てられた容量を超えて消費することを防ぎ、ほかのバケットは残りのストレージを使えます。 -## Overview +## 概要 -RustFS currently supports hard, byte-based quotas. Before accepting a write, RustFS compares the bucket's current usage plus the requested object size with the configured limit. A write that would exceed the limit is rejected with `InvalidRequest` and a `Bucket quota exceeded` message. +RustFS が現在サポートするのは、バイト単位のハードクォータです。書き込みを受け付ける前に、RustFS は、バケットの現在の使用量に要求されたオブジェクトサイズを加えた値と、設定された上限を比較します。上限を超える書き込みは、`InvalidRequest` とメッセージ `Bucket quota exceeded` で拒否されます。 -Quota checks cover these operations: +クォータの確認は、次の操作を対象とします。 -| Operation | Quota behavior | +| 操作 | クォータの動作 | | --- | --- | -| Upload an object | Rejects the upload when current usage plus the object size exceeds the limit. | -| Complete a multipart upload | Checks the completed object size before committing the upload. | -| Copy an object into the bucket | Checks the source object size against the destination bucket quota. | -| Delete an object | Always allowed so that you can recover capacity. | +| オブジェクトのアップロード | 現在の使用量にオブジェクトサイズを加えた値が上限を超える場合、アップロードを拒否します。 | +| マルチパートアップロードの完了 | アップロードを確定する前に、完了したオブジェクトのサイズを確認します。 | +| バケットへのオブジェクトのコピー | コピー元オブジェクトのサイズを、コピー先バケットのクォータと照合します。 | +| オブジェクトの削除 | 容量を回復できるよう、常に許可されます。 | -The quota applies to object data, not the number of objects or request rate. A bucket without a configured limit is unlimited. +クォータの対象はオブジェクトデータです。オブジェクト数やリクエストレートは対象ではありません。上限を設定していないバケットは、無制限です。 -:::note[Replacement uploads] +:::note[置き換えアップロード] -The quota check reserves the full incoming object size against the bucket's current usage. Replacing an existing key can therefore require enough headroom for the complete replacement object. +クォータの確認では、受信するオブジェクトのサイズ全体を、バケットの現在の使用量に対して確保します。そのため、既存のキーを置き換えるには、置き換え後のオブジェクト全体が入る空きが必要になることがあります。 ::: -## Configure in the Console +## Console で設定する -1. Sign in to the RustFS Console and open **Browser**. -2. Find the bucket and select **Settings**. -3. Under **Capacity & Metadata**, find **Bucket Quota** and select **Edit**. -4. Enable **Bucket Quota**. -5. Enter the quota size and select **MiB**, **GiB**, **TiB**, or **PiB**. -6. Select **Save Quota**. +1. RustFS Console にサインインし、**Browser**（ブラウザー）を開きます。 +2. バケットを見つけ、**Settings**（設定）を選びます。 +3. **Capacity & Metadata**（容量とメタデータ）で **Bucket Quota**（バケットクォータ）を見つけ、**Edit**（編集）を選びます。 +4. **Bucket Quota** を有効にします。 +5. クォータサイズを入力し、**MiB**、**GiB**、**TiB**、**PiB** のいずれかを選びます。 +6. **Save Quota**（クォータを保存）を選びます。 -![Set Bucket Quota dialog with quota size and unit controls](./images/bucket-quota-console.png) +![クォータサイズと単位のコントロールがある Set Bucket Quota ダイアログ](./images/bucket-quota-console.png) -To remove the limit, open the dialog again, disable **Bucket Quota**, and save the change. +上限を外すには、ダイアログを再び開き、**Bucket Quota** を無効にして、変更を保存します。 -## Use rc +## rc を使う -Configure an alias for your RustFS deployment: +RustFS デプロイ向けのエイリアスを設定します。 ```bash rc alias set rustfs http://localhost:9000 \ @@ -49,29 +49,29 @@ rc alias set rustfs http://localhost:9000 \ --region us-east-1 --bucket-lookup path ``` -Replace `localhost` with the RustFS server address when `rc` runs on another host. +`rc` を別のホストで実行する場合は、`localhost` を RustFS サーバーのアドレスに置き換えます。 -### Permissions +### 権限 -Quota operations require these policy actions: +クォータの操作には、次のポリシーアクションが必要です。 -| Operation | Required action | +| 操作 | 必要なアクション | | --- | --- | -| Set or clear a quota | `admin:SetBucketQuota` | -| Read quota configuration or statistics | `s3:GetBucketQuota` | -| Check whether a proposed operation fits | `s3:GetBucketQuota` | +| クォータの設定または解除 | `admin:SetBucketQuota` | +| クォータ設定または統計の読み取り | `s3:GetBucketQuota` | +| 提案された操作が収まるかどうかの確認 | `s3:GetBucketQuota` | -The root credential has these permissions. For delegated administration, attach only the actions needed for the workflow. +ルート認証情報には、これらの権限があります。管理を委任する場合は、そのワークフローに必要なアクションだけを付与します。 -### Set a quota +### クォータを設定する -Set a 1 GiB hard quota. `rc` accepts byte values or units such as `1G`, `500M`, and `10KB`: +1 GiB のハードクォータを設定します。`rc` は、バイト値、または `1G`、`500M`、`10KB` のような単位を受け付けます。 ```bash rc bucket quota set rustfs/my-bucket 1G ``` -The response includes the configured limit and current usage: +応答には、設定した上限と現在の使用量が含まれます。 ```text Bucket: my-bucket @@ -80,42 +80,42 @@ Usage: 0 B Type: HARD ``` -### Read the quota +### クォータを読み取る ```bash rc bucket quota info rustfs/my-bucket ``` -Use `--json` when another tool needs to process the result: +別のツールが結果を処理する必要がある場合は、`--json` を使います。 ```bash rc bucket quota info rustfs/my-bucket --json ``` -When no limit is configured, the human-readable output reports `Quota: unlimited`. +上限が設定されていない場合、人が読める形式の出力は `Quota: unlimited` と報告します。 -:::note[Configuration propagation] +:::note[設定の反映] -A query issued immediately after setting or clearing a quota can briefly return the previous state. Query the quota again and confirm the expected value before starting the verification workflow. +クォータを設定または解除した直後の照会は、短時間、以前の状態を返すことがあります。検証の手順を始める前に、クォータを再度照会し、想定した値であることを確認します。 ::: -### Clear a quota +### クォータを解除する -Remove the limit without deleting objects: +オブジェクトを削除せずに、上限を外します。 ```bash rc bucket quota clear rustfs/my-bucket rc bucket quota info rustfs/my-bucket ``` -The bucket becomes unlimited after the configuration change is applied. +設定の変更が適用されると、バケットは無制限になります。 -## Advanced quota checks +## 高度なクォータ確認 -`rc 0.1.29` does not expose commands for detailed usage statistics or advisory checks for proposed writes. Use the RustFS Admin API for these operations. Requests must use AWS Signature Version 4 with an active RustFS credential. +`rc 0.1.29` には、詳細な使用量統計や、提案された書き込みの事前確認を行うコマンドがありません。これらの操作には、RustFS の Admin API を使います。リクエストは、有効な RustFS 認証情報を使い、AWS 署名バージョン 4 で署名する必要があります。 -The examples use these shell variables: +例では、次のシェル変数を使います。 ```bash export RUSTFS_ENDPOINT=http://localhost:9000 @@ -124,15 +124,15 @@ export RUSTFS_SECRET_KEY= export BUCKET_NAME=my-bucket ``` -:::warning[Protect credentials] +:::warning[認証情報を保護する] -Environment variables are convenient for local testing but may be visible to processes running as the same operating-system user. Use your platform's secret manager or a restricted credentials file in production. +環境変数はローカルテストには便利ですが、同じオペレーティングシステムユーザーで動作するプロセスから見えることがあります。本番では、プラットフォームのシークレットマネージャー、またはアクセスを制限した認証情報ファイルを使います。 ::: -### Read detailed usage statistics +### 詳細な使用量統計を読み取る -Use the statistics endpoint to retrieve the limit, current usage, remaining bytes, and percentage used: +統計エンドポイントを使い、上限、現在の使用量、残りのバイト数、使用率を取得します。 ```bash curl --fail-with-body \ @@ -151,11 +151,11 @@ curl --fail-with-body \ } ``` -Usage values come from RustFS data-usage accounting. Allow time for that view to reflect very recent changes before using the statistics response for external billing or orchestration. +使用量の値は、RustFS のデータ使用量集計から得られます。統計の応答を外部の課金やオーケストレーションに使う前に、ごく最近の変更がそのビューへ反映される時間を取ります。 -### Check a proposed upload +### 提案されたアップロードを確認する -Check whether a 64 MiB upload would fit without writing an object: +オブジェクトを書き込まずに、64 MiB のアップロードが収まるかを確認します。 ```bash curl --fail-with-body \ @@ -167,11 +167,11 @@ curl --fail-with-body \ "${RUSTFS_ENDPOINT}/rustfs/admin/v3/quota-check/${BUCKET_NAME}" ``` -The `allowed` field reports the decision. This check is advisory: another write can consume capacity before the planned upload starts, so the actual upload remains authoritative. +`allowed` フィールドが、その判定を示します。この確認は参考情報です。計画したアップロードが始まる前に、別の書き込みが容量を消費することがあるため、最終的な判定は実際のアップロードの結果です。 -## Verification +## 検証 -Set a small test quota, upload an object that fits, and then attempt to upload an object that exceeds the remaining capacity: +小さなテスト用クォータを設定し、収まるオブジェクトをアップロードしたあと、残りの容量を超えるオブジェクトのアップロードを試みます。 ```bash rc bucket quota set rustfs/my-bucket 1M @@ -183,9 +183,9 @@ rc object copy /tmp/quota-small.bin rustfs/my-bucket/hello.bin rc object copy /tmp/quota-large.bin rustfs/my-bucket/too-large.bin ``` -The 256 KiB object succeeds. The 2 MiB object exceeds the 1 MiB bucket quota, so `rc` exits with an error and RustFS does not create `too-large.bin`. +256 KiB のオブジェクトは成功します。2 MiB のオブジェクトは 1 MiB のバケットクォータを超えるため、`rc` はエラーで終了し、RustFS は `too-large.bin` を作成しません。 -Delete the first object and clear the test quota: +最初のオブジェクトを削除し、テスト用クォータを解除します。 ```bash rc object remove rustfs/my-bucket/hello.bin --force @@ -193,12 +193,12 @@ rc bucket quota clear rustfs/my-bucket rc bucket quota info rustfs/my-bucket ``` -Confirm that the final query reports `Quota: unlimited`. +最後の照会が `Quota: unlimited` と報告することを確認します。 -If quota enforcement cannot read or parse its internal configuration, RustFS logs `Bucket quota check degraded to allow` and permits the write. Monitor for this warning because it means quota enforcement is temporarily unavailable. +クォータの適用処理が内部設定を読み取れない、または解析できない場合、RustFS は `Bucket quota check degraded to allow` をログに記録し、書き込みを許可します。この警告は、クォータの適用が一時的に利用できないことを意味するため、監視します。 -## Next steps +## 次のステップ -- [Create a bucket](./creation.md) -- [Manage lifecycle rules](../lifecycle-management.md) -- [Configure observability](/operations/observability) \ No newline at end of file +- [バケットを作成する](./creation.md) +- [ライフサイクルルールを管理する](../lifecycle-management.md) +- [オブザーバビリティを設定する](/ja/operations/observability) diff --git a/content/ja/administration/data/bucket/replication.md b/content/ja/administration/data/bucket/replication.md index 37642ae90..036690d7d 100644 --- a/content/ja/administration/data/bucket/replication.md +++ b/content/ja/administration/data/bucket/replication.md @@ -1,46 +1,46 @@ --- -title: "Bucket Replication" -description: "Configure, validate, and monitor asynchronous replication between versioned RustFS buckets." +title: "バケットレプリケーション" +description: "バージョニングを有効にした RustFS バケット間で、非同期レプリケーションを設定、検証、監視します。" --- -RustFS bucket replication copies selected object versions from a source bucket to a target bucket. Use it to maintain a remote copy of bucket data, distribute objects between deployments, or prepare a secondary copy for recovery workflows. +RustFS のバケットレプリケーションは、選択したオブジェクトバージョンを、ソースバケットからターゲットバケットへコピーします。バケットデータのリモートコピーの維持、デプロイ間でのオブジェクトの配布、復旧手順で使う二次コピーの準備に使います。 -## Overview +## 概要 -Bucket replication has two configuration layers: +バケットレプリケーションには、2 層の設定があります。 -1. A **remote target** stores the target endpoint, bucket, credentials, and generated target ARN. -2. An S3 **replication configuration** attaches rules to the source bucket and references that target ARN. +1. **リモートターゲット**は、ターゲットのエンドポイント、バケット、認証情報、生成されたターゲット ARN を保持します。 +2. S3 の **レプリケーション設定**は、ルールをソースバケットに付与し、そのターゲット ARN を参照します。 -Both the source and target buckets must have versioning enabled. RustFS verifies the target connection and target-bucket versioning when you register the remote target. It rejects a replication configuration whose enabled rules reference an unknown or stale target ARN. +ソースバケットとターゲットバケットの両方で、バージョニングを有効にする必要があります。リモートターゲットを登録するとき、RustFS はターゲットへの接続と、ターゲットバケットのバージョニングを確認します。RustFS は、有効なルールが未知の、または古くなったターゲット ARN を参照するレプリケーション設定を拒否します。 -Replication is asynchronous by default. A successful source upload means RustFS accepted the source object; it does not mean the target copy is already complete. +レプリケーションは、既定で非同期です。ソースへのアップロードが成功したことは、RustFS がソースオブジェクトを受け付けたことを意味します。ターゲット側のコピーがすでに完了していることにはなりません。 -Rules can select objects by prefix or object tags and control these behaviors: +ルールでは、プレフィックスまたはオブジェクトタグでオブジェクトを選べます。制御できる動作は次のとおりです。 -| Rule setting | Behavior | +| ルールの設定 | 動作 | | --- | --- | -| `Status` | Enables or disables the rule. | -| `Filter` | Restricts replication by key prefix, object tags, or both. | -| `ExistingObjectReplication` | Includes objects that existed before the rule when set to `Enabled`. | -| `DeleteMarkerReplication` | Replicates delete markers when set to `Enabled`. | -| `DeleteReplication` | Replicates deletion of a specific object version when set to `Enabled`. | -| `Destination` | Identifies the registered remote target by ARN. | +| `Status` | ルールを有効または無効にします。 | +| `Filter` | キーのプレフィックス、オブジェクトタグ、またはその両方によって、レプリケーション対象を制限します。 | +| `ExistingObjectReplication` | `Enabled` のとき、ルールの作成より前からあったオブジェクトを含めます。 | +| `DeleteMarkerReplication` | `Enabled` のとき、削除マーカーをレプリケートします。 | +| `DeleteReplication` | `Enabled` のとき、特定のオブジェクトバージョンの削除をレプリケートします。 | +| `Destination` | 登録済みのリモートターゲットを、ARN で指定します。 | -Bucket replication is directional. Configure a separate target and rule in the opposite direction if both buckets must accept writes and replicate them to each other. Do not confuse bucket replication with [site replication](/operations/high-availability/site-replication), which synchronizes broader site configuration and identity data. +バケットレプリケーションには方向があります。両方のバケットが書き込みを受け付け、互いの変更をレプリケートする必要がある場合は、逆方向にも別のターゲットとルールを設定します。より広いサイト設定とアイデンティティデータを同期する [サイトレプリケーション](/ja/operations/high-availability/site-replication) と、バケットレプリケーションを混同してはなりません。 -## Configuration +## 設定 -### Requirements +### 要件 -- A source RustFS deployment and a reachable target S3-compatible deployment. -- A source bucket and target bucket with versioning enabled. -- A dedicated target credential that can inspect the target bucket's versioning and write replicated object versions and delete markers. -- A source administrator allowed to manage remote targets and replication configuration. -- Network access from every source node that can run replication work to the target endpoint. -- The RustFS [`rc`](/operations/rc) client installed on an administration host. +- ソースの RustFS デプロイと、到達できるターゲットの S3 互換デプロイ。 +- バージョニングを有効にした、ソースバケットとターゲットバケット。 +- ターゲットバケットのバージョニングを検査でき、レプリケートされたオブジェクトバージョンと削除マーカーを書き込める、専用のターゲット認証情報。 +- リモートターゲットとレプリケーション設定を管理できる、ソース側の管理者。 +- レプリケーション処理を実行できるすべてのソースノードから、ターゲットエンドポイントへのネットワーク到達性。 +- 管理用ホストにインストールした、RustFS の [`rc`](/ja/operations/rc) クライアント。 -Configure one `rc` alias for each deployment. Use dedicated credentials and replace the example endpoints before running the commands: +デプロイごとに、`rc` のエイリアスを 1 つ設定します。専用の認証情報を使い、コマンドを実行する前に、例のエンドポイントを置き換えます。 ```bash rc alias set source https://source.example.com:9000 \ @@ -54,43 +54,43 @@ rc alias set target https://target.example.com:9000 \ rc alias list ``` -The source deployment uses the target alias credentials when it registers the remote target. `rc alias list` displays endpoints but does not print secret keys. +ソースデプロイは、リモートターゲットを登録するとき、ターゲットエイリアスの認証情報を使います。`rc alias list` はエンドポイントを表示しますが、シークレットキーは表示しません。 -:::warning[Protect target credentials] +:::warning[ターゲットの認証情報を保護する] -RustFS stores the target credential as part of the source bucket's remote-target configuration. Use a dedicated credential with access limited to the target bucket and do not reuse a root credential. +RustFS は、ターゲットの認証情報を、ソースバケットのリモートターゲット設定の一部として保存します。ターゲットバケットへのアクセスに限定した専用の認証情報を使い、ルート認証情報は再利用してはなりません。 ::: -### Permissions +### 権限 -Source-side administration uses these policy actions: +ソース側の管理では、次のポリシーアクションを使います。 -| Operation | Required action | +| 操作 | 必要なアクション | | --- | --- | -| Register, update, or remove a remote target | `admin:SetBucketTarget` | -| List remote targets | `admin:GetBucketTarget` | -| Read replication metrics | `admin:GetReplicationMetrics` | -| Apply or delete replication configuration | `s3:PutReplicationConfiguration` | -| Read replication configuration | `s3:GetReplicationConfiguration` | +| リモートターゲットの登録、更新、削除 | `admin:SetBucketTarget` | +| リモートターゲットの一覧 | `admin:GetBucketTarget` | +| レプリケーションメトリクスの読み取り | `admin:GetReplicationMetrics` | +| レプリケーション設定の適用または削除 | `s3:PutReplicationConfiguration` | +| レプリケーション設定の読み取り | `s3:GetReplicationConfiguration` | -The target credential must pass RustFS target validation, which checks bucket access, versioning, replicated-object writes, replicated delete markers, and object-version deletion. When Object Lock is enabled on the source bucket, the target must have compatible Object Lock support. +ターゲットの認証情報は、RustFS のターゲット検証に合格する必要があります。検証では、バケットへのアクセス、バージョニング、レプリケートされたオブジェクトの書き込み、レプリケートされた削除マーカー、オブジェクトバージョンの削除を確認します。ソースバケットでオブジェクトロックが有効な場合、ターゲットは互換性のあるオブジェクトロックに対応している必要があります。 -### Create and version the buckets +### バケットの作成とバージョニング -Create the source bucket: +ソースバケットを作成します。 ```bash rc bucket create source/my-bucket ``` -Create the target bucket: +ターゲットバケットを作成します。 ```bash rc bucket create target/my-bucket-replica ``` -Enable versioning on both buckets: +両方のバケットでバージョニングを有効にします。 ```bash rc bucket version enable source/my-bucket @@ -100,53 +100,53 @@ rc bucket version info source/my-bucket rc bucket version info target/my-bucket-replica ``` -Do not suspend source-bucket versioning while replication is configured. +レプリケーションを設定しているあいだは、ソースバケットのバージョニングを停止してはなりません。 -## Usage +## 使い方 -### Configure replication in the Console +### Console でレプリケーションを設定する -The RustFS Console combines remote-target registration and replication-rule configuration in one form. +RustFS Console では、リモートターゲットの登録とレプリケーションルールの設定を、1 つのフォームで行います。 -1. Sign in to the source deployment's Console. -2. Open **Buckets**, locate the source bucket, and select **Settings**. -3. Under **Data Protection**, enable **Versioning** if it is disabled. -4. Under **Automation**, select **Open Bucket Replication**. -5. Select **Add Replication Rule**. -6. Configure the destination and rule: +1. ソースデプロイの Console にサインインします。 +2. **Buckets**（バケット）を開き、ソースバケットを見つけて **Settings**（設定）を選びます。 +3. **Data Protection**（データ保護）で、無効なら **Versioning**（バージョニング）を有効にします。 +4. **Automation**（自動化）で **Open Bucket Replication**（バケットレプリケーションを開く）を選びます。 +5. **Add Replication Rule**（レプリケーションルールを追加）を選びます。 +6. 宛先とルールを設定します。 -| Console field | Value | +| Console のフィールド | 値 | | --- | --- | -| **Priority** | Rule evaluation priority. The initial value is `1`. | -| **Mode** | Select **Asynchronous** or **Synchronous**. Asynchronous is selected by default. | -| **Endpoint** | Target S3 API address as `host:port`, without a URL scheme. | -| **Bucket** | Versioned destination bucket name. | -| **Access Key** and **Secret Key** | Dedicated credentials authorized to replicate into the destination bucket. | -| **Region** | Target region. The initial value is `us-east-1`. | -| **Storage Class** | Storage class applied at the destination. The initial value is `STANDARD`. | -| **Prefix** | Optional key prefix used to limit matching objects. | -| **Tags** | Optional object-tag name and value filters. Select **Add Tag** for additional filters. | -| **Use TLS** | Enables HTTPS for the destination connection. | -| **Replicate Existing Objects** | Includes objects created before the rule. Enabled by default. | -| **Replicate Delete Markers** | Copies delete markers to the destination. Enabled by default. | -| **Replicate Delete** | Copies deletion of a specific object version. Enabled by default. | -| **Health Check Interval** | Target health-check interval in seconds. The initial value is `60`. | -| **Bandwidth Limit** | Per-target transfer limit, selectable in KiB/s, MiB/s, or GiB/s. | - -7. Select **Save**. RustFS validates the source bucket, target connection, target credentials, and target-bucket versioning before accepting the rule. -8. Return to **Bucket Replication** to review the rule or select **Refresh** to update its displayed state. - -:::warning[Enable versioning on both deployments] - -The source and destination buckets must both have versioning enabled before you save the rule. Sign in to the target deployment's Console and enable versioning under **Buckets** → **Settings** → **Data Protection** when needed. +| **Priority**（優先度） | ルール評価の優先度です。初期値は `1` です。 | +| **Mode**（モード） | **Asynchronous**（非同期）または **Synchronous**（同期）を選びます。既定では非同期が選ばれています。 | +| **Endpoint**（エンドポイント） | ターゲットの S3 API アドレスを、URL スキームなしの `host:port` で指定します。 | +| **Bucket**（バケット） | バージョニング済みの宛先バケット名です。 | +| **Access Key**（アクセスキー）と **Secret Key**（シークレットキー） | 宛先バケットへのレプリケーションを認可された、専用の認証情報です。 | +| **Region**（リージョン） | ターゲットのリージョンです。初期値は `us-east-1` です。 | +| **Storage Class**（ストレージクラス） | 宛先で適用するストレージクラスです。初期値は `STANDARD` です。 | +| **Prefix**（プレフィックス） | 一致するオブジェクトを限定する、任意のキープレフィックスです。 | +| **Tags**（タグ） | 任意のオブジェクトタグについて、名前と値のフィルターです。フィルターを追加するには **Add Tag**（タグを追加）を選びます。 | +| **Use TLS**（TLS を使う） | 宛先への接続で HTTPS を有効にします。 | +| **Replicate Existing Objects**（既存オブジェクトをレプリケート） | ルールより前に作成されたオブジェクトを含めます。既定で有効です。 | +| **Replicate Delete Markers**（削除マーカーをレプリケート） | 削除マーカーを宛先へコピーします。既定で有効です。 | +| **Replicate Delete**（削除をレプリケート） | 特定のオブジェクトバージョンの削除をコピーします。既定で有効です。 | +| **Health Check Interval**（ヘルスチェック間隔） | ターゲットのヘルスチェック間隔（秒）です。初期値は `60` です。 | +| **Bandwidth Limit**（帯域幅の上限） | ターゲットごとの転送上限です。単位は KiB/s、MiB/s、GiB/s から選べます。 | + +7. **Save**（保存）を選びます。RustFS は、ルールを受け付ける前に、ソースバケット、ターゲットへの接続、ターゲットの認証情報、ターゲットバケットのバージョニングを検証します。 +8. **Bucket Replication**（バケットレプリケーション）に戻り、ルールを確認します。表示されている状態を更新するには、**Refresh**（再読み込み）を選びます。 + +:::warning[両方のデプロイでバージョニングを有効にする] + +ルールを保存する前に、ソースと宛先の両方のバケットでバージョニングを有効にする必要があります。必要な場合は、ターゲットデプロイの Console にサインインし、**Buckets** → **Settings** → **Data Protection** でバージョニングを有効にします。 ::: -For repeatable automation or configuration management, use the `rc` workflow below. +繰り返し実行する自動化や、構成管理には、以下の `rc` の手順を使います。 -### Add a replication rule with rc +### rc でレプリケーションルールを追加する -Create an asynchronous rule that copies new and existing objects and propagates delete markers and explicit version deletions: +新規オブジェクトと既存オブジェクトをコピーし、削除マーカーと明示的なバージョン削除を伝播する、非同期ルールを作成します。 ```bash rc bucket replication add source/my-bucket \ @@ -156,9 +156,9 @@ rc bucket replication add source/my-bucket \ --replicate delete,delete-marker,existing-objects ``` -`rc` registers the target, obtains its generated ARN, and applies the replication rule in one operation. Omit `--replicate` flags for behaviors you do not want. Add `--sync` only when writes must wait for synchronous replication. +`rc` は、ターゲットの登録、生成された ARN の取得、レプリケーションルールの適用を、1 回の操作で行います。不要な動作については、`--replicate` のフラグを省きます。書き込みが同期レプリケーションの完了を待つ必要がある場合にだけ、`--sync` を付けます。 -To limit replication to a prefix, add `--prefix`: +レプリケーションをプレフィックスに限定するには、`--prefix` を追加します。 ```bash rc bucket replication add source/my-bucket \ @@ -169,18 +169,18 @@ rc bucket replication add source/my-bucket \ --replicate delete-marker,existing-objects ``` -Objects that do not match an enabled rule remain only in the source bucket. Use `--bandwidth` to set a byte-per-second limit, `--healthcheck-seconds` to change the target health-check interval, and `--storage-class` to override the destination storage class. +有効なルールに一致しないオブジェクトは、ソースバケットにだけ残ります。1 秒あたりのバイト数の上限は `--bandwidth`、ターゲットのヘルスチェック間隔の変更は `--healthcheck-seconds`、宛先ストレージクラスの上書きは `--storage-class` で指定します。 -### List and update rules +### ルールの一覧と更新 -List the active rules: +有効なルールを一覧します。 ```bash rc bucket replication list source/my-bucket rc bucket replication list source/my-bucket --json ``` -Update a rule by its ID. Only supplied settings are changed: +ルールは ID を指定して更新します。変更されるのは、指定した設定だけです。 ```bash rc bucket replication update source/my-bucket \ @@ -190,25 +190,25 @@ rc bucket replication update source/my-bucket \ --healthcheck-seconds 60 ``` -Use `--status Enabled|Disabled` to enable or disable a rule and `--sync true|false` to change its replication mode. +ルールの有効化と無効化は `--status Enabled|Disabled`、レプリケーションモードの変更は `--sync true|false` で指定します。 -### Export and import configuration +### 設定のエクスポートとインポート -Export the complete replication configuration for review or backup: +確認またはバックアップのため、レプリケーション設定の全体をエクスポートします。 ```bash rc bucket replication export source/my-bucket --json > replication.json ``` -The export includes remote-target metadata and the target Access Key, although the Secret Key is omitted. Protect the file as sensitive configuration. +エクスポートには、リモートターゲットのメタデータと、ターゲットのアクセスキーが含まれます。シークレットキーは含まれません。このファイルは、機密の設定として保護します。 -Import a previously exported configuration: +以前にエクスポートした設定をインポートします。 ```bash rc bucket replication import source/my-bucket replication.json ``` -### Delete replication configuration +### レプリケーション設定を削除する ```bash rc bucket replication remove source/my-bucket --id replicate-all @@ -217,49 +217,49 @@ rc bucket replication remove source/my-bucket --id replicate-all rc bucket replication remove source/my-bucket --all ``` -RustFS also removes replication remote targets referenced by the deleted configuration. It does not delete objects or versions already copied to the target bucket. Remove or retain those objects according to the target bucket's lifecycle and retention requirements. +RustFS は、削除した設定が参照していたレプリケーションのリモートターゲットも削除します。ターゲットバケットへすでにコピーされたオブジェクトやバージョンは、削除しません。それらのオブジェクトは、ターゲットバケットのライフサイクルと保持の要件に従って、削除するか保持します。 -:::note[rc 0.1.29 removal response] +:::note[rc 0.1.29 の削除応答] -After RustFS removes the replication configuration and its targets, `rc 0.1.29` can report `Remote target not found` while attempting a second target cleanup. Run `rc bucket replication list source/my-bucket --json`; an empty `rules` array confirms that the configuration was removed. +RustFS がレプリケーション設定とそのターゲットを削除したあと、`rc 0.1.29` は 2 回目のターゲット削除を試みるときに、`Remote target not found` と報告することがあります。`rc bucket replication list source/my-bucket --json` を実行します。`rules` 配列が空であれば、設定が削除されたことを確認できます。 ::: -## Verification +## 検証 -### Check target readiness +### ターゲットの準備状況を確認する -`rc bucket replication add` checks source access, target connectivity, target credentials, and bucket versioning before it creates the rule. Confirm the resulting destination and rule settings: +`rc bucket replication add` は、ルールを作成する前に、ソースへのアクセス、ターゲットへの接続、ターゲットの認証情報、バケットのバージョニングを確認します。作成された宛先とルールの設定を確認します。 ```bash rc bucket replication list source/my-bucket --json ``` -### Replicate an object +### オブジェクトをレプリケートする -Upload a test object to the source: +ソースへテスト用オブジェクトをアップロードします。 ```bash printf 'hello from RustFS replication\n' > /tmp/hello.txt rc object copy /tmp/hello.txt source/my-bucket/hello.txt ``` -Inspect the source object: +ソースオブジェクトを確認します。 ```bash rc object stat source/my-bucket/hello.txt --json ``` -Because replication is asynchronous by default, the target object might not appear immediately. Repeat this command until it succeeds: +レプリケーションは既定で非同期であるため、ターゲットオブジェクトは直ちには表示されないことがあります。成功するまで、次のコマンドを繰り返します。 ```bash rc object stat target/my-bucket-replica/hello.txt --json rc object show target/my-bucket-replica/hello.txt ``` -Compare the source and target `etag` and `size_bytes` values, then confirm that `object show` returns the expected content. +ソースとターゲットの `etag` および `size_bytes` を比較し、`object show` が想定した内容を返すことを確認します。 -To verify delete-marker replication, delete the source object and list versions on both buckets: +削除マーカーのレプリケーションを確認するには、ソースオブジェクトを削除し、両方のバケットでバージョンを一覧します。 ```bash rc object remove source/my-bucket/hello.txt --force @@ -268,31 +268,31 @@ rc bucket version list source/my-bucket/hello.txt --json rc bucket version list target/my-bucket-replica/hello.txt --json ``` -When delete-marker replication succeeds, the latest entry on both buckets has `is_delete_marker: true`. +削除マーカーのレプリケーションが成功すると、両方のバケットの最新エントリは `is_delete_marker: true` になります。 -### Inspect replication metrics +### レプリケーションメトリクスを確認する ```bash rc bucket replication status source/my-bucket rc bucket replication status source/my-bucket --json ``` -The command returns the source node's current in-memory replication statistics. Metrics can remain zero even after an object reaches the destination, so use them together with target-object and version checks rather than as the only verification signal. +このコマンドは、ソースノードが現在メモリ上に持つレプリケーション統計を返します。オブジェクトが宛先に到達したあとでも、メトリクスはゼロのままであることがあります。メトリクスだけを検証の根拠にせず、ターゲットオブジェクトとバージョンの確認とあわせて使います。 -### Troubleshoot failures +### 障害を調査する -| Symptom | Check | +| 症状 | 確認項目 | | --- | --- | -| `bucket versioning must be enabled` | Enable versioning on the source bucket. | -| Target registration reports `not versioned` | Enable versioning on the target bucket. | -| `replication target configuration not found` | Recheck the target alias, credentials, and destination bucket, then rerun `replication add`. | -| Rule reports a stale target | Refresh the rule list and retry `replication add`; if it persists, remove the failed configuration and recreate the target. | -| Target object does not appear | Check target reachability, credentials, target quota, and `rc bucket replication status`. | -| Replication fails | Inspect source-node logs for the target ARN and object key. | -| Target removal is disallowed | Delete or replace the replication configuration before removing a referenced target. | - -## Next steps - -- [Manage bucket lifecycle](../lifecycle-management.md) -- [Configure bucket quotas](./quota.md) -- [Configure observability](/operations/observability) \ No newline at end of file +| `bucket versioning must be enabled` | ソースバケットのバージョニングを有効にします。 | +| ターゲットの登録が `not versioned` と報告する | ターゲットバケットのバージョニングを有効にします。 | +| `replication target configuration not found` | ターゲットのエイリアス、認証情報、宛先バケットを再確認し、`replication add` を再実行します。 | +| ルールが古くなったターゲットを報告する | ルールの一覧を更新し、`replication add` を再試行します。解消しない場合は、失敗した設定を削除してターゲットを作り直します。 | +| ターゲットオブジェクトが表示されない | ターゲットへの到達性、認証情報、ターゲットのクォータ、`rc bucket replication status` を確認します。 | +| レプリケーションが失敗する | ターゲット ARN とオブジェクトキーについて、ソースノードのログを確認します。 | +| ターゲットの削除が拒否される | 参照されているターゲットを削除する前に、レプリケーション設定を削除または置き換えます。 | + +## 次のステップ + +- [バケットのライフサイクルを管理する](../lifecycle-management.md) +- [バケットクォータを設定する](./quota.md) +- [オブザーバビリティを設定する](/ja/operations/observability) diff --git a/content/ja/administration/data/lifecycle-management.md b/content/ja/administration/data/lifecycle-management.md index 9cc05f875..746e2d310 100644 --- a/content/ja/administration/data/lifecycle-management.md +++ b/content/ja/administration/data/lifecycle-management.md @@ -1,21 +1,21 @@ --- -title: "Lifecycle Management" -description: "Configure, inspect, and maintain RustFS object lifecycle rules with the rc command-line client." +title: "ライフサイクル管理" +description: "rc コマンドラインクライアントを使い、RustFS のオブジェクトライフサイクルルールを設定、確認、維持します。" --- -RustFS lifecycle management applies expiration and transition rules to objects in a bucket. This page shows how to manage those rules with `rc`, verify a transition, and restore a temporary local copy of transitioned data. +RustFS のライフサイクル管理は、バケット内のオブジェクトに有効期限と移行のルールを適用します。このページでは、`rc` でそれらのルールを管理し、移行を確認し、移行済みデータの一時的なローカルコピーを復元する方法を示します。 -Before you begin, [install `rc`](/operations/rc), configure an alias named `local`, and create `my-bucket`. To transition objects, first register the target in [Tiered Storage](/administration/data/tiered-storage) and note its uppercase tier name. +始める前に、[`rc` をインストール](/ja/operations/rc)し、`local` という名前のエイリアスを設定し、`my-bucket` を作成します。オブジェクトを移行するには、先に [階層化ストレージ](/ja/administration/data/tiered-storage) でターゲットを登録し、大文字の階層名を控えます。 -:::note[Asynchronous evaluation] +:::note[非同期の評価] -Lifecycle rules do not process every eligible object immediately. The [Object Scanner](/administration/data/object/scanner) evaluates lifecycle work in the background. +ライフサイクルルールは、対象となるすべてのオブジェクトを直ちに処理するわけではありません。[オブジェクトスキャナー](/ja/administration/data/object/scanner) が、バックグラウンドでライフサイクル処理を評価します。 ::: -## Add an expiration rule +## 有効期限のルールを追加する -Expire objects under the `logs/` prefix 30 days after creation: +作成から 30 日後に、`logs/` プレフィックス配下のオブジェクトを期限切れにします。 ```bash rc bucket lifecycle rule add local/my-bucket \ @@ -23,11 +23,11 @@ rc bucket lifecycle rule add local/my-bucket \ --expiry-days 30 ``` -The command creates an enabled rule and returns its generated rule ID. Record that ID when you need to edit or remove this specific rule. +このコマンドは、有効なルールを作成し、生成されたルール ID を返します。このルールを編集または削除する必要がある場合は、その ID を記録します。 -## Add a transition rule +## 移行ルールを追加する -Move object data to the registered `COLDTIER` tier after 90 days: +90 日後に、オブジェクトデータを登録済みの `COLDTIER` 階層へ移します。 ```bash rc bucket lifecycle rule add local/my-bucket \ @@ -35,9 +35,9 @@ rc bucket lifecycle rule add local/my-bucket \ --storage-class COLDTIER ``` -`--storage-class` must match a registered tier name. Adding the rule does not create the tier or validate an AWS storage-class label as a RustFS tier. +`--storage-class` は、登録済みの階層名と一致する必要があります。ルールを追加しても階層は作成されず、AWS のストレージクラス名が RustFS の階層として有効かどうかも検証されません。 -You can combine expiration and transition options in one rule. Use the noncurrent-version options only for a versioned bucket: +有効期限と移行のオプションは、1 つのルールに組み合わせられます。非現行バージョンのオプションは、バージョニングを有効にしたバケットにだけ使います。 ```bash rc bucket lifecycle rule add local/my-bucket \ @@ -46,15 +46,15 @@ rc bucket lifecycle rule add local/my-bucket \ --noncurrent-expiry-days 365 ``` -## Inspect and update rules +## ルールの確認と更新 -List the current rules and note the ID of the rule you want to change: +現在のルールを一覧し、変更するルールの ID を控えます。 ```bash rc bucket lifecycle rule list local/my-bucket ``` -Change a rule's expiration period or disable it without deleting it: +ルールを削除せずに、有効期限を変更するか、ルールを無効にします。 ```bash rc bucket lifecycle rule edit local/my-bucket \ @@ -65,30 +65,30 @@ rc bucket lifecycle rule edit local/my-bucket \ --disable true ``` -Remove one rule by ID. Use `--all` only when you intend to remove the bucket's complete lifecycle configuration: +ID を指定して、1 つのルールを削除します。バケットのライフサイクル設定全体を削除する意図がある場合にだけ、`--all` を使います。 ```bash rc bucket lifecycle rule remove local/my-bucket --id rc bucket lifecycle rule remove local/my-bucket --all ``` -## Export and import rules +## ルールのエクスポートとインポート -Export the bucket's lifecycle configuration before a bulk change: +一括変更の前に、バケットのライフサイクル設定をエクスポートします。 ```bash rc bucket lifecycle rule export local/my-bucket > lifecycle.json ``` -Importing a file replaces the lifecycle configuration sent to the bucket. Review the JSON before applying it: +ファイルをインポートすると、バケットへ送信するライフサイクル設定が置き換わります。適用する前に JSON を確認します。 ```bash rc bucket lifecycle rule import local/my-bucket lifecycle.json ``` -## Confirm a lifecycle transition +## ライフサイクル移行を確認する -After an object becomes eligible under its lifecycle rule, inspect it on the source cluster: +オブジェクトがライフサイクルルールの対象になったあと、ソースクラスター上でそのオブジェクトを調べます。 ```bash aws s3api head-object \ @@ -97,7 +97,7 @@ aws s3api head-object \ --endpoint-url http://localhost:9000 ``` -After the transition completes, the response reports the registered tier name as the storage class: +移行が完了すると、応答は登録済みの階層名をストレージクラスとして報告します。 ```json { @@ -105,9 +105,9 @@ After the transition completes, the response reports the registered tier name as } ``` -The response can contain additional object metadata. Before the transition completes, `StorageClass` may be absent or may not yet report `COLDTIER`. +応答には、追加のオブジェクトメタデータが含まれることがあります。移行が完了する前は、`StorageClass` が存在しないことや、まだ `COLDTIER` を報告しないことがあります。 -Read the object through the source RustFS endpoint as usual: +通常どおり、ソースの RustFS エンドポイントを通してオブジェクトを読み取ります。 ```bash aws s3 cp \ @@ -116,23 +116,23 @@ aws s3 cp \ --endpoint-url http://localhost:9000 ``` -RustFS reads transitioned data through the source bucket and object key. Applications do not need to address the target bucket directly. +RustFS は、ソースのバケットとオブジェクトキーを通して、移行済みのデータを読み取ります。アプリケーションが、ターゲットバケットを直接指定する必要はありません。 -## Restore a local copy +## ローカルコピーを復元する -Request a temporary local copy of a transitioned object and retain it for seven days: +移行済みオブジェクトの一時的なローカルコピーを要求し、7 日間保持します。 ```bash rc bucket lifecycle restore local/my-bucket/hello.txt --days 7 ``` -While the copy-back is running, `HEAD` reports `x-amz-restore: ongoing-request="true"`. After completion, it reports `ongoing-request="false"` with an expiry date. A second restore submitted while one is running returns `RestoreAlreadyInProgress`. +ローカルへの書き戻しの実行中、`HEAD` は `x-amz-restore: ongoing-request="true"` を報告します。完了後は、`ongoing-request="false"` と有効期限を報告します。実行中にもう一度復元を要求すると、`RestoreAlreadyInProgress` が返されます。 -When the restore period expires, RustFS removes the local restored copy and its restore metadata. The transitioned object remains available from the remote tier. +復元期間が終了すると、RustFS は復元されたローカルコピーと、その復元メタデータを削除します。移行済みオブジェクトは、リモート階層から引き続き利用できます。 -## Command compatibility +## コマンドの互換性 -The latest `rc` also accepts `rc ilm` as a compatibility alias. We recommend the noun-first `rc bucket lifecycle` form for new commands and scripts: +最新の `rc` は、互換性のためのエイリアスとして `rc ilm` も受け付けます。新しいコマンドとスクリプトでは、名詞を先頭にした `rc bucket lifecycle` 形式を推奨します。 ```bash rc bucket lifecycle --help @@ -140,6 +140,6 @@ rc bucket lifecycle rule --help rc bucket lifecycle tier --help ``` -## Next steps +## 次のステップ -Review [Tiered Storage](/administration/data/tiered-storage) to monitor or maintain remote tiers, and use [object creation](/administration/data/object/creation) to create test objects for a lifecycle rule. +リモート階層の監視と保守は [階層化ストレージ](/ja/administration/data/tiered-storage) を参照します。ライフサイクルルールのテスト用オブジェクトを作るには、[オブジェクトの作成](/ja/administration/data/object/creation) を使います。 diff --git a/content/ja/administration/data/object/creation.md b/content/ja/administration/data/object/creation.md index b0c5ca07b..85084632b 100644 --- a/content/ja/administration/data/object/creation.md +++ b/content/ja/administration/data/object/creation.md @@ -1,53 +1,53 @@ --- -title: "Object Creation" -description: "Create objects using the RustFS UI, rc, or the S3 API." +title: "オブジェクトの作成" +description: "RustFS UI、rc、または S3 API を使ってオブジェクトを作成する方法を説明します。" --- -Objects are the fundamental storage units in RustFS, containing data, metadata, and a unique key. This guide covers object creation (upload). +オブジェクトは RustFS の基本的な保存単位であり、データ、メタデータ、一意のキーを含みます。このガイドでは、オブジェクトの作成（アップロード）を扱います。 -## Requirements +## 要件 -- A running RustFS instance (see [Installation Guide](../../../installation/index.md)). -- [`rc`](/operations/rc) installed and configured with an alias for the command-line workflow. -- A target bucket. Create one by following [Bucket Creation](../bucket/creation.md). +- 稼働中の RustFS インスタンス（[インストールガイド](../../../installation/index.md)を参照）。 +- コマンドラインの手順を使う前に、[`rc`](/ja/operations/rc) をインストールし、エイリアスを設定します。 +- 保存先のバケット。[バケットの作成](../bucket/creation.md)に従って作成します。 -## Creating Objects +## オブジェクトの作成 -### Using the RustFS UI +### RustFS UI を使う -1. Log in to the RustFS Console. -2. Select the target bucket. -3. On the bucket page, in the top right corner, select **New Directory**, **New File**, or **Upload File/Folder**. -4. To upload from your local machine, click **Upload File/Folder**, select the files, and click **Start Upload**. +1. RustFS Console にログインします。 +2. 対象のバケットを選択します。 +3. バケットページの右上で、**New Directory**（新しいディレクトリ）、**New File**（新しいファイル）、または **Upload File/Folder**（ファイルまたはフォルダーのアップロード）を選択します。 +4. ローカルマシンからアップロードする場合は、**Upload File/Folder** をクリックし、ファイルを選択して **Start Upload**（アップロード開始）をクリックします。 -![object creation from ui](images/upload_file_from_ui.png) +![Console からのオブジェクト作成](images/upload_file_from_ui.png) -Click on an object to view its details. +オブジェクトを選択すると、詳細を表示できます。 -![object details info](images/object_details_info.png) +![オブジェクトの詳細情報](images/object_details_info.png) -### Using `rc` +### `rc` を使う -See the [`rc` guide](/operations/rc) for installation and alias configuration. +インストールとエイリアスの設定は、[`rc` ガイド](/ja/operations/rc)を参照します。 -Upload a file: +ファイルをアップロードします。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt rc object list rustfs/my-bucket ``` -Verify the upload in the RustFS Console. +RustFS Console でアップロードを確認します。 -### Using the API +### API を使う -Upload a file via API: +API でファイルをアップロードします。 ```http PUT /{bucketName}/{objectName} HTTP/1.1 ``` -S3 requests must be signed with AWS Signature V4, so use an S3 client rather than hand-crafting headers. With the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) configured for your access keys: +S3 リクエストは AWS Signature V4 で署名する必要があります。ヘッダーを手作業で組み立てず、S3 クライアントを使います。アクセスキーを設定した [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) では、次のように実行します。 ```bash aws s3api put-object \ @@ -57,19 +57,19 @@ aws s3api put-object \ --endpoint-url http://localhost:9000 ``` -Verify the upload in the RustFS Console. +RustFS Console でアップロードを確認します。 -## Deleting Objects +## オブジェクトの削除 -See [Object Deletion](./deletion.md). +[オブジェクトの削除](./deletion.md)を参照します。 -Use the following API for file deletion: +S3 API でオブジェクトを削除するには、次を使います。 ```http DELETE /{bucketName}/{objectName} HTTP/1.1 ``` -Request example: +リクエストの例です。 ```bash aws s3api delete-object \ @@ -78,4 +78,4 @@ aws s3api delete-object \ --endpoint-url http://localhost:9000 ``` -You can confirm the file has been deleted on the RustFS UI. +RustFS Console で、そのオブジェクトが表示されなくなったことを確認します。 diff --git a/content/ja/administration/data/object/deletion.md b/content/ja/administration/data/object/deletion.md index 5e3106239..6798c5352 100644 --- a/content/ja/administration/data/object/deletion.md +++ b/content/ja/administration/data/object/deletion.md @@ -1,27 +1,27 @@ --- -title: "Object Deletion" -description: "Delete objects using the RustFS UI, rc, or the S3 API." +title: "オブジェクトの削除" +description: "RustFS UI、rc、または S3 API を使ってオブジェクトを削除する方法を説明します。" --- -This guide covers object deletion. +このガイドでは、オブジェクトの削除を扱います。 -## Requirements +## 要件 -- Install and configure [`rc`](/operations/rc) before using the command-line workflow. -- Confirm the alias, bucket, and object key before deleting an object. +- コマンドラインの手順を使う前に、[`rc`](/ja/operations/rc) をインストールして設定します。 +- オブジェクトを削除する前に、エイリアス、バケット、オブジェクトキーを確認します。 -## Using the RustFS UI +## RustFS UI を使う -1. Log in to the RustFS Console. -2. Select the bucket containing the file to be deleted. -3. On the bucket page, select the file to be deleted. -4. Click **Delete Selected Items** in the upper right corner, then click **Confirm** in the popup dialog. +1. RustFS Console にログインします。 +2. 削除するオブジェクトが含まれるバケットを選択します。 +3. バケットページで、削除するオブジェクトを選択します。 +4. 右上の **Delete Selected Items**（選択項目の削除）を選び、続けて **Confirm**（確認）を選択します。 -![object deletion from ui](images/delete_file_from_ui.png) +![Console からのオブジェクト削除](images/delete_file_from_ui.png) -## Using `rc` +## `rc` を使う -Delete a file: +オブジェクトを削除します。 ```bash rc object remove rustfs/my-bucket/hello.txt @@ -33,17 +33,17 @@ Removed: rustfs/my-bucket/hello.txt ✓ Removed 1 object(s). ``` -Verify the deletion in the RustFS Console. +RustFS Console で削除を確認します。 -## Using the API +## API を使う -Delete a file via API: +API でオブジェクトを削除します。 ```http DELETE /{bucketName}/{objectName} HTTP/1.1 ``` -S3 requests must be signed with AWS Signature V4, so use an S3 client rather than hand-crafting headers. With the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) configured for your access keys: +S3 リクエストは AWS Signature V4 で署名する必要があります。ヘッダーを手作業で組み立てず、S3 クライアントを使います。アクセスキーを設定した [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) では、次のように実行します。 ```bash aws s3api delete-object \ @@ -52,4 +52,4 @@ aws s3api delete-object \ --endpoint-url http://localhost:9000 ``` -Verify the deletion in the RustFS Console. +RustFS Console で削除を確認します。 diff --git a/content/ja/administration/data/object/multipart-upload.md b/content/ja/administration/data/object/multipart-upload.md index d4a6af66e..cb61775f0 100644 --- a/content/ja/administration/data/object/multipart-upload.md +++ b/content/ja/administration/data/object/multipart-upload.md @@ -1,79 +1,79 @@ --- -title: "Multipart Upload" -description: "Upload large objects in parts, monitor Console upload tasks, and verify completed objects with rc." +title: "マルチパートアップロード" +description: "大きなオブジェクトをパートに分けてアップロードし、Console のアップロードタスクを監視し、完了したオブジェクトを rc で検証する方法を説明します。" --- -Multipart upload splits one object into independently uploaded parts and assembles them on the server. Use it for large objects, retryable transfers, and browser uploads that need progress and cancellation controls. +マルチパートアップロードは、1 つのオブジェクトを個別にアップロードするパートに分割し、サーバー上で組み立てます。大きなオブジェクト、再試行できる転送、進捗とキャンセルの制御が必要なブラウザーアップロードに使います。 -## Overview +## 概要 -The S3 multipart workflow has three required phases: +S3 のマルチパート手順には、必須の 3 段階があります。 -1. **CreateMultipartUpload** returns an upload ID. -2. **UploadPart** uploads numbered parts and returns an ETag for each part. -3. **CompleteMultipartUpload** submits the ordered part numbers and ETags to create the final object. +1. **CreateMultipartUpload** がアップロード ID を返します。 +2. **UploadPart** が番号付きのパートをアップロードし、各パートの ETag を返します。 +3. **CompleteMultipartUpload** が、順序付けされたパート番号と ETag を送信し、最終的なオブジェクトを作成します。 -Abort an unfinished upload with **AbortMultipartUpload** so temporary parts do not continue consuming storage. +未完了のアップロードは **AbortMultipartUpload** で中止し、一時パートがストレージを消費し続けないようにします。 -RustFS accepts part numbers from `1` through `10000`. `ListParts` and `ListMultipartUploads` return at most 1,000 entries per response and use markers for pagination. The completed object appears only after the completion request succeeds. +RustFS が受け付けるパート番号は `1` から `10000` までです。`ListParts` と `ListMultipartUploads` は、1 回の応答で最大 1,000 件を返し、ページネーションにはマーカーを使います。完了したオブジェクトは、完了リクエストが成功したあとにだけ現れます。 -## Upload in the Console +## Console でアップロードする -1. Sign in to the RustFS Console and open the destination bucket. -2. Select **Upload File/Folder**. -3. Optionally enter a **Current Prefix**. -4. Select **Select File** or **Select Folder**, then choose the content to upload. -5. Review the selected names and sizes, then select **Start Upload**. +1. RustFS Console にサインインし、保存先のバケットを開きます。 +2. **Upload File/Folder**（ファイルまたはフォルダーのアップロード）を選択します。 +3. 必要に応じて **Current Prefix**（現在のプレフィックス）を入力します。 +4. **Select File**（ファイルを選択）または **Select Folder**（フォルダーを選択）を選び、アップロードする内容を指定します。 +5. 選択した名前とサイズを確認し、**Start Upload**（アップロード開始）を選択します。 -![Console upload dialog with a selected large file](./images/multipart-upload-console.png) +![大きなファイルを選択した Console のアップロードダイアログ](./images/multipart-upload-console.png) -The observed Console upload dialog supports up to 10,000 selected files and reports a 512 GB maximum for a single file. These are Console upload limits; S3 clients can have different local limits. +Console のアップロードダイアログは最大 10,000 ファイルに対応し、単一ファイルの上限として 512 GB を表示します。これらは Console のアップロード上限です。S3 クライアントには、これとは異なるローカル上限がある場合があります。 -After upload starts, **Task Management** groups tasks into Pending, Processing, Completed, Failed, and Canceled states. Each processing task shows progress and a **Cancel** action. Canceling an active multipart task aborts the current part request and marks the task as canceled. +アップロードを開始すると、**Task Management**（タスク管理）がタスクを Pending（保留）、Processing（処理中）、Completed（完了）、Failed（失敗）、Canceled（キャンセル済み）の状態に分けます。処理中の各タスクには、進捗と **Cancel**（キャンセル）操作が表示されます。実行中のマルチパートタスクをキャンセルすると、進行中のパートリクエストが中止され、タスクはキャンセル済みになります。 -Refresh the bucket after completion and confirm the object size and modification time. +完了後にバケットの表示を更新し、オブジェクトのサイズと更新時刻を確認します。 -## Use rc +## rc を使う -Upload and verify an object with `rc`: +`rc` でオブジェクトをアップロードし、検証します。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt rc object stat rustfs/my-bucket/hello.txt --json ``` -:::note[rc 0.1.29 multipart boundary] +:::note[rc 0.1.29 におけるマルチパートの制限] -`rc 0.1.29` does not expose create, upload-part, complete, list-parts, or abort multipart commands. A validated 20 MiB `rc object copy` used a single `PutObject` request rather than multipart upload. Use the Console or an S3 SDK when explicit multipart behavior is required; use `rc object stat` to verify the completed object. +`rc 0.1.29` は、マルチパートの create、upload-part、complete、list-parts、abort コマンドを公開していません。検証済みの 20 MiB の `rc object copy` は、マルチパートアップロードではなく、単一の `PutObject` リクエストを使っていました。明示的なマルチパート動作が必要な場合は Console または S3 SDK を使い、完了したオブジェクトの検証には `rc object stat` を使います。 ::: -For a versioned bucket, list the version created by a completed multipart upload: +バージョニングが有効なバケットでは、完了したマルチパートアップロードが作成したバージョンを一覧します。 ```bash rc bucket version list rustfs/my-bucket/hello.txt --json ``` -RustFS returns a version ID when multipart completion succeeds in a versioned bucket. +バージョニングが有効なバケットでマルチパートの完了が成功すると、RustFS はバージョン ID を返します。 -## S3 multipart operations +## S3 のマルチパート操作 -Use an S3 SDK that supports these standard operations: +次の標準操作に対応した S3 SDK を使います。 -| Phase | S3 operation | Required values | +| 段階 | S3 操作 | 必要な値 | | --- | --- | --- | -| Initiate | `CreateMultipartUpload` | Bucket, key, metadata, encryption, and optional Object Lock settings. | -| Upload | `UploadPart` | Bucket, key, upload ID, part number, and body. Save the returned ETag. | -| Inspect | `ListParts` | Bucket, key, and upload ID. Paginate when needed. | -| Complete | `CompleteMultipartUpload` | Ordered part numbers and their exact ETags. | -| Cancel | `AbortMultipartUpload` | Bucket, key, and upload ID. | -| Discover | `ListMultipartUploads` | Bucket and optional prefix. Paginate when needed. | +| 開始 | `CreateMultipartUpload` | バケット、キー、メタデータ、暗号化、および任意のオブジェクトロック設定。 | +| アップロード | `UploadPart` | バケット、キー、アップロード ID、パート番号、本文。返された ETag を保存します。 | +| 検査 | `ListParts` | バケット、キー、アップロード ID。必要に応じてページネーションします。 | +| 完了 | `CompleteMultipartUpload` | 順序付けされたパート番号と、それぞれの正確な ETag。 | +| キャンセル | `AbortMultipartUpload` | バケット、キー、アップロード ID。 | +| 検出 | `ListMultipartUploads` | バケットと任意のプレフィックス。必要に応じてページネーションします。 | -Do not reuse an upload ID for a different key. Submit completed parts in ascending part-number order and preserve each ETag exactly as returned. +別のキーに対してアップロード ID を再利用しないでください。完了したパートはパート番号の昇順で送信し、各 ETag は返された値をそのまま保持します。 -## Verification +## 検証 -After completion: +完了後に、次を実行します。 ```bash rc object stat rustfs/my-bucket/hello.txt --json @@ -81,21 +81,21 @@ rc object show rustfs/my-bucket/hello.txt > /tmp/hello-downloaded.txt cmp /path/to/hello.txt /tmp/hello-downloaded.txt ``` -Confirm that `size_bytes` matches the local file and that `cmp` exits successfully. For a versioned bucket, also confirm that `rc bucket version list` returns a version ID. +`size_bytes` がローカルファイルと一致し、`cmp` が正常終了することを確認します。バージョニングが有効なバケットでは、`rc bucket version list` がバージョン ID を返すことも確認します。 -## Troubleshooting +## トラブルシューティング -| Symptom | Check | +| 現象 | 確認すること | | --- | --- | -| Upload remains in Processing | Check browser connectivity and keep the Console tab open; cancel and retry when the connection is interrupted. | -| A part request fails | Retry that part with the same upload ID and part number, then use the latest returned ETag. | -| Completion reports an invalid part | Verify the submitted part numbers, ordering, and ETags against `ListParts`. | -| Object is absent after uploading parts | Send `CompleteMultipartUpload`; uploaded parts alone do not create the object. | -| Temporary storage continues growing | List incomplete uploads and abort those that are no longer needed. | -| Completion fails on a locked key | Check Object Lock retention or Legal Hold on the current destination version. | - -## Next steps - -- [Create and inspect objects](./creation.md) -- [Manage object versions](./versioning.md) -- [Protect objects with Object Lock](./object-lock.md) \ No newline at end of file +| アップロードが Processing のままになる | ブラウザーの接続を確認し、Console のタブは開いたままにします。接続が中断した場合は、キャンセルして再試行します。 | +| パートリクエストが失敗する | 同じアップロード ID とパート番号でそのパートを再試行し、最後に返された ETag を使います。 | +| 完了時に無効なパートが報告される | 送信したパート番号、順序、ETag を `ListParts` と照合します。 | +| パートをアップロードしたあともオブジェクトがない | `CompleteMultipartUpload` を送信します。アップロードしたパートだけでは、オブジェクトは作成されません。 | +| 一時ストレージが増え続ける | 未完了のアップロードを一覧し、不要なものを中止します。 | +| ロックされたキーで完了が失敗する | 現在の宛先バージョンに対するオブジェクトロックの保持、またはリーガルホールドを確認します。 | + +## 次のステップ + +- [オブジェクトを作成して確認する](./creation.md) +- [オブジェクトのバージョンを管理する](./versioning.md) +- [オブジェクトロックでオブジェクトを保護する](./object-lock.md) diff --git a/content/ja/administration/data/object/object-lock.md b/content/ja/administration/data/object/object-lock.md index 5db3468a1..ddea654c6 100644 --- a/content/ja/administration/data/object/object-lock.md +++ b/content/ja/administration/data/object/object-lock.md @@ -1,46 +1,46 @@ --- -title: "Object Lock" -description: "Protect versioned objects from deletion with retention periods and legal holds." +title: "オブジェクトロック" +description: "保持期間とリーガルホールドで、バージョニングされたオブジェクトを削除から保護する方法を説明します。" --- -RustFS Object Lock applies write-once, read-many protection to individual object versions. Use retention periods for time-bound protection and Legal Hold for protection without a predefined expiration date. +RustFS のオブジェクトロックは、個々のオブジェクトバージョンに、書き込みは 1 回・読み取りは複数回（WORM）の保護を適用します。期限のある保護には保持期間を、あらかじめ有効期限を定めない保護にはリーガルホールドを使います。 -## Overview +## 概要 -Object Lock requires bucket versioning. You can enable it when creating a bucket or use the S3 `PutObjectLockConfiguration` API on an existing bucket whose versioning is enabled. Each overwrite creates a new version; retention and Legal Hold protect a specific version rather than the object key as a whole. +オブジェクトロックには、バケットのバージョニングが必要です。バケットの作成時に有効にするか、バージョニングが有効な既存バケットに対して S3 の `PutObjectLockConfiguration` API を使います。上書きのたびに新しいバージョンが作成されます。保持とリーガルホールドが保護するのは、オブジェクトキー全体ではなく、特定のバージョンです。 -| Protection | Behavior | +| 保護 | 動作 | | --- | --- | -| `GOVERNANCE` retention | Blocks deletion and retention shortening unless the caller has bypass permission and explicitly requests a bypass. Retention can be extended without bypass. | -| `COMPLIANCE` retention | Blocks deletion even with governance bypass. The date can be extended but not shortened. | -| Legal Hold | Blocks deletion until the hold is set to `OFF`. It has no expiration date and governance bypass does not override it. | +| `GOVERNANCE` 保持 | 呼び出し元がバイパス権限を持ち、バイパスを明示的に要求した場合を除き、削除と保持期間の短縮を拒否します。保持期間は、バイパスなしで延長できます。 | +| `COMPLIANCE` 保持 | ガバナンスバイパスがあっても削除を拒否します。日付は延長できますが、短縮はできません。 | +| リーガルホールド | ホールドが `OFF` に設定されるまで削除を拒否します。有効期限はなく、ガバナンスバイパスでは解除されません。 | -Deleting a key without a version ID creates a delete marker. The protected version remains stored and can still be retrieved by version ID. +バージョン ID を指定せずにキーを削除すると、削除マーカーが作成されます。保護されたバージョンは保存されたままで、バージョン ID を指定すれば引き続き取得できます。 -:::danger[Plan retention before enabling it] +:::danger[有効にする前に保持を計画する] -COMPLIANCE retention cannot be bypassed or shortened before its retain-until date. Test policies in a non-production bucket and verify time synchronization, permissions, lifecycle rules, replication, and backup procedures before protecting production data. +COMPLIANCE 保持は、保持期限（retain-until）の日時より前にバイパスすることも、短縮することもできません。本番データを保護する前に、非本番のバケットでポリシーを試し、時刻同期、権限、ライフサイクルルール、レプリケーション、バックアップ手順を確認します。 ::: -## Configure in the Console +## Console で設定する -1. Sign in to the RustFS Console and open **Buckets**. -2. Select **Create Bucket** and enter the bucket name. -3. Enable **Object Lock**. The Console also enables **Version** because Object Lock requires versioning. -4. To apply retention automatically to new object versions, enable **Retention**. -5. Select **COMPLIANCE** or **GOVERNANCE**, enter the validity, and select **Day** or **Year**. -6. Select **Create**. +1. RustFS Console にサインインし、**Buckets**（バケット）を開きます。 +2. **Create Bucket**（バケットの作成）を選択し、バケット名を入力します。 +3. **Object Lock**（オブジェクトロック）を有効にします。オブジェクトロックにはバージョニングが必要なため、Console は **Version**（バージョン）も有効にします。 +4. 新しいオブジェクトバージョンへ保持を自動適用する場合は、**Retention**（保持）を有効にします。 +5. **COMPLIANCE**（コンプライアンス）または **GOVERNANCE**（ガバナンス）を選択し、保持期間を入力して、**Day**（日）または **Year**（年）を選択します。 +6. **Create**（作成）を選択します。 -![Create Bucket dialog with versioning, Object Lock, and default retention enabled](./images/object-lock-create-bucket.png) +![バージョニング、オブジェクトロック、既定の保持を有効にしたバケット作成ダイアログ](./images/object-lock-create-bucket.png) -The Console initially displays `180` days when default retention is enabled. Replace it with the period required by your retention policy; it is a UI initial value, not a general recommendation. +既定の保持を有効にすると、Console は最初に `180` 日を表示します。保持ポリシーで必要な期間に置き換えます。これは UI の初期値であり、一般的な推奨値ではありません。 -To inspect a protected object, open the bucket, select the object name, and use the **Versions** and **Info** tabs. The Info tab exposes **Legal Hold** and **RetentionPolicy** fields. +保護されたオブジェクトを確認するには、バケットを開き、オブジェクト名を選択して、**Versions**（バージョン）タブと **Info**（情報）タブを使います。Info タブには、**Legal Hold**（リーガルホールド）と **RetentionPolicy**（保持ポリシー）のフィールドがあります。 -## Use rc +## rc を使う -Configure an alias before running these examples: +これらの例を実行する前に、エイリアスを設定します。 ```bash rc alias set rustfs http://localhost:9000 \ @@ -48,13 +48,13 @@ rc alias set rustfs http://localhost:9000 \ --region us-east-1 --bucket-lookup path ``` -:::note[rc 0.1.29 bucket creation boundary] +:::note[rc 0.1.29 におけるバケット作成の制限] -`rc bucket create --with-lock` and `--with-versioning` appear in the `rc 0.1.29` help output but return `not implemented` when executed. Create the Object Lock bucket in the Console. The upload headers shown below are supported and were validated against RustFS. +`rc bucket create --with-lock` と `--with-versioning` は `rc 0.1.29` のヘルプ出力に表示されますが、実行すると `not implemented` を返します。オブジェクトロックのバケットは Console で作成します。以下に示すアップロードヘッダーはサポートされており、RustFS に対して検証済みです。 ::: -Upload an object version with GOVERNANCE retention. Supply both retention headers together and use an RFC 3339 UTC timestamp in the future: +GOVERNANCE 保持付きのオブジェクトバージョンをアップロードします。保持ヘッダーは 2 つとも同時に指定し、未来の RFC 3339 UTC タイムスタンプを使います。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt \ @@ -62,14 +62,14 @@ rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt \ -H "x-amz-object-lock-retain-until-date:2027-01-01T00:00:00Z" ``` -Upload an object version with Legal Hold enabled: +リーガルホールドを有効にしたオブジェクトバージョンをアップロードします。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/legal-hold.txt \ -H "x-amz-object-lock-legal-hold:ON" ``` -List the protected versions and inspect a specific version: +保護されたバージョンを一覧し、特定のバージョンを確認します。 ```bash rc bucket version list rustfs/my-bucket --json @@ -77,27 +77,27 @@ rc object stat rustfs/my-bucket/hello.txt \ --version-id --json ``` -`rc 0.1.29` does not provide commands to change retention or switch an existing Legal Hold between `ON` and `OFF`. Use the Console or an S3 SDK for those operations. +`rc 0.1.29` には、保持を変更するコマンドや、既存のリーガルホールドを `ON` と `OFF` の間で切り替えるコマンドはありません。これらの操作には、Console または S3 SDK を使います。 -## Verify protection +## 保護を検証する -1. Upload a test object with GOVERNANCE retention or Legal Hold. -2. Record its version ID with `rc bucket version list`. -3. Attempt to delete that exact version through an S3 client without bypass. RustFS must return `AccessDenied` while protection is active. -4. Confirm the version remains visible in the Console and through `rc object stat --version-id`. +1. GOVERNANCE 保持またはリーガルホールドを付けて、テストオブジェクトをアップロードします。 +2. `rc bucket version list` で、そのバージョン ID を記録します。 +3. バイパスなしで、そのバージョンを S3 クライアントから削除しようとします。保護が有効な間、RustFS は `AccessDenied` を返す必要があります。 +4. Console と `rc object stat --version-id` で、そのバージョンが引き続き表示されることを確認します。 -For GOVERNANCE retention, test bypass only with a dedicated administrative identity that has `s3:BypassGovernanceRetention`. COMPLIANCE retention and Legal Hold remain protected from governance bypass. +GOVERNANCE 保持のバイパスは、`s3:BypassGovernanceRetention` を持つ専用の管理アイデンティティだけで試します。COMPLIANCE 保持とリーガルホールドは、ガバナンスバイパスからは保護されたままです。 -## Operational considerations +## 運用上の考慮事項 -- Default bucket retention is calculated when a new object version or multipart upload is initiated. -- Copying an object creates a new destination version; destination retention policy applies independently. -- Suspending versioning is not appropriate for an Object Lock bucket. -- Lifecycle expiration cannot remove a version while retention or Legal Hold blocks deletion. -- Replication targets for locked objects must support compatible Object Lock behavior. +- バケットの既定保持は、新しいオブジェクトバージョン、またはマルチパートアップロードを開始した時点で計算されます。 +- オブジェクトをコピーすると、宛先に新しいバージョンが作成されます。宛先の保持ポリシーは、独立して適用されます。 +- オブジェクトロックのバケットでバージョニングを一時停止するのは、適切ではありません。 +- 保持またはリーガルホールドが削除を拒否している間、ライフサイクルの有効期限ではそのバージョンを削除できません。 +- ロックされたオブジェクトのレプリケーション先は、互換性のあるオブジェクトロックの動作に対応している必要があります。 -## Next steps +## 次のステップ -- [Manage object versions](./versioning.md) -- [Configure bucket replication](../bucket/replication.md) -- [Review the security checklist](/installation/requirement/checklists/security-checklists) \ No newline at end of file +- [オブジェクトのバージョンを管理する](./versioning.md) +- [バケットレプリケーションを設定する](../bucket/replication.md) +- [セキュリティチェックリストを確認する](/ja/installation/requirement/checklists/security-checklists) diff --git a/content/ja/administration/data/object/scanner.md b/content/ja/administration/data/object/scanner.md index 6330c38f6..ce88bf6bc 100644 --- a/content/ja/administration/data/object/scanner.md +++ b/content/ja/administration/data/object/scanner.md @@ -1,32 +1,32 @@ --- -title: "Object Scanning" -description: "Guide to the RustFS object scanner, including design, implementation, and monitoring." +title: "オブジェクトスキャン" +description: "RustFS のオブジェクトスキャナーについて、設計、実装、監視を説明します。" --- -This guide covers the design and implementation of the RustFS object scanner, including its integration with Erasure Coding, Scrub & Repair mechanisms, scheduling strategies, monitoring metrics, and troubleshooting. +このガイドでは、RustFS オブジェクトスキャナーの設計と実装を扱います。イレイジャーコーディングとの連携、スクラブと修復、スケジュール、メトリクス、トラブルシューティングを含みます。 -## Overview +## 概要 -The RustFS object scanner is built into the storage engine and is responsible for periodically checking object integrity and executing scheduled operations. -Scanning tasks include disk usage statistics, lifecycle management rule evaluation, object replication execution, and triggering corrupted object self-healing. +RustFS のオブジェクトスキャナーはストレージエンジンに組み込まれ、オブジェクトの整合性を定期的に確認し、スケジュールされた操作を実行します。 +スキャナーはディスク使用量の統計を収集し、ライフサイクルルールを評価し、オブジェクトのレプリケーションを実行し、破損したオブジェクトのデータ修復を開始します。 -## Architecture and Design Principles +## アーキテクチャと設計原則 -### Scanner Architecture +### スキャナーのアーキテクチャ -The RustFS scanner uses a hash sampling mechanism, selecting one out of every 1024 objects for inspection based on object name hashing to minimize performance impact. -The scanner is deeply integrated with the Erasure Coding module, utilizing redundant shards for online reconstruction when detecting lost or corrupted shards, ensuring high data availability and consistency. +RustFS のスキャナーはハッシュサンプリングを使い、性能への影響を抑えるため、オブジェクト名のハッシュに基づいて 1024 個につき 1 個を検査対象に選びます。 +スキャナーはイレイジャーコーディング層と連携します。欠損または破損したシャードを検出すると、残りの冗長シャードからそのシャードをオンラインで再構築します。 -## Data Verification and Recovery +## データの検証と復旧 -The RustFS data verification mechanism checks metadata consistency and performs bit-by-bit reading and verification to discover hidden bad blocks. The object scanner detects issues like bit rot and triggers repair processes when necessary. +RustFS のデータ検証は、メタデータの整合性を確認し、データを読み取って検証することで、潜在的な不良セクタを検出します。オブジェクトスキャナーはビットロットなどの問題を検出し、必要に応じて修復処理を開始します。 -## Scanning Modes and Scheduling +## スキャンモードとスケジュール -RustFS supports three scanning modes: online scanning during reads, background periodic scanning, and manual full scanning, balancing performance and reliability. -Similar to the `osd_scrub_begin_hour` configuration in Ceph, administrators can set scanning start times and frequency. For example, light verification is set to once daily by default. +RustFS は、性能と信頼性のバランスを取る 3 つのスキャンモードに対応しています。読み取り時のインライン検査、定期的なバックグラウンドスキャン、手動のフルスキャンです。 +Ceph の `osd_scrub_begin_hour` 設定と同様に、管理者はスキャンの開始時刻と頻度を設定できます。たとえば、軽量チェックは既定で 1 日に 1 回実行されます。 -## Monitoring and Metrics +## 監視とメトリクス -Scanner statistics include total task count, failure count, and time distribution, exposing metrics through the Prometheus data model such as `rustfs_scanner_jobs_total`, `rustfs_scanner_failures_total`, and `rustfs_scanner_duration_seconds`. -Combined with monitoring systems, alerts can be set based on scanning failure rates and duration to promptly discover and locate potential issues at the storage or network levels. \ No newline at end of file +スキャナーは、タスクの総数、失敗数、所要時間の分布を Prometheus メトリクスとして報告します。例として `rustfs_scanner_jobs_total`、`rustfs_scanner_failures_total`、`rustfs_scanner_duration_seconds` があります。 +スキャンの失敗率と所要時間にアラートを設定すると、ストレージやネットワークの問題を早期に検出して診断できます。 diff --git a/content/ja/administration/data/object/versioning.md b/content/ja/administration/data/object/versioning.md index b891c7567..b46cb8299 100644 --- a/content/ja/administration/data/object/versioning.md +++ b/content/ja/administration/data/object/versioning.md @@ -1,48 +1,48 @@ --- -title: "Versioning" -description: "Enable bucket versioning, recover earlier object versions, and manage delete markers with rc and the Console." +title: "バージョニング" +description: "バケットのバージョニングを有効にし、以前のオブジェクトバージョンを復元し、削除マーカーを rc と Console で管理する方法を説明します。" --- -RustFS bucket versioning preserves multiple versions of the same object key. Use it to recover from accidental overwrites and deletes and to satisfy prerequisites for Object Lock and bucket replication. +RustFS のバケットバージョニングは、同じオブジェクトキーの複数のバージョンを保持します。誤った上書きや削除からの復元と、オブジェクトロックおよびバケットレプリケーションの前提を満たすために使います。 -## Overview +## 概要 -When versioning is enabled: +バージョニングが有効な場合の動作は、次のとおりです。 -- Each upload or copy to an existing key creates a new version ID. -- A normal delete creates a delete marker instead of removing older versions. -- Reading the key without a version ID returns the latest visible version, or `NotFound` when the latest entry is a delete marker. -- Reading or deleting a specific version requires its version ID. +- 既存のキーへのアップロードまたはコピーのたびに、新しいバージョン ID が作成されます。 +- 通常の削除では、古いバージョンを消さずに削除マーカーが作成されます。 +- バージョン ID を指定せずにキーを読み取ると、最新の可視バージョンが返されます。最新のエントリが削除マーカーの場合は、`NotFound` が返されます。 +- 特定のバージョンを読み取る、または削除するには、そのバージョン ID が必要です。 -Suspending versioning stops normal creation of new version IDs but preserves existing versions and delete markers. Suspension is not the same as disabling or removing version history. +バージョニングを一時停止すると、新しいバージョン ID の通常の作成は止まりますが、既存のバージョンと削除マーカーは保持されます。一時停止は、無効化やバージョン履歴の削除とは異なります。 -## Configure in the Console +## Console で設定する -### Enable at bucket creation +### バケット作成時に有効にする -1. Open **Buckets** and select **Create Bucket**. -2. Enter the bucket name. -3. Enable **Version**. -4. Select **Create**. +1. **Buckets**（バケット）を開き、**Create Bucket**（バケットの作成）を選択します。 +2. バケット名を入力します。 +3. **Version**（バージョン）を有効にします。 +4. **Create**（作成）を選択します。 -### Enable or suspend an existing bucket +### 既存バケットのバージョニングを有効または一時停止する -1. Open **Buckets**, locate the bucket, and select **Settings**. -2. Under **Data Protection**, locate **Versioning**. -3. Enable versioning or suspend it as required. +1. **Buckets** を開き、対象のバケットを見つけて **Settings**（設定）を選択します。 +2. **Data Protection**（データ保護）で **Versioning**（バージョニング）を見つけます。 +3. 必要に応じて、バージョニングを有効にするか、一時停止します。 -The settings page reports `Enabled`, `Suspended`, or `Disabled`. It also notes that suspension preserves existing versions. +設定ページには `Enabled`、`Suspended`、または `Disabled` が表示されます。一時停止しても既存のバージョンは保持されることも示されます。 -### Browse and recover versions +### バージョンを参照して復元する -1. Open the bucket and enable **Show Deleted Objects** when you need to see keys hidden by delete markers. -2. Select an object name to open **Object Details**. -3. Select **Versions** to inspect available versions and delete markers. -4. Download the required version and upload it again to make its content the latest version. +1. バケットを開き、削除マーカーで隠れたキーを確認する必要がある場合は、**Show Deleted Objects**（削除済みオブジェクトを表示）を有効にします。 +2. オブジェクト名を選択して、**Object Details**（オブジェクトの詳細）を開きます。 +3. **Versions**（バージョン）を選択し、利用できるバージョンと削除マーカーを確認します。 +4. 必要なバージョンをダウンロードし、再度アップロードして、その内容を最新バージョンにします。 -## Use rc +## rc を使う -Create a bucket and enable versioning: +バケットを作成し、バージョニングを有効にします。 ```bash rc bucket create rustfs/my-bucket @@ -50,7 +50,7 @@ rc bucket version enable rustfs/my-bucket rc bucket version info rustfs/my-bucket ``` -Upload two versions of the same key: +同じキーの 2 つのバージョンをアップロードします。 ```bash printf 'version one\n' > /tmp/hello.txt @@ -60,7 +60,7 @@ printf 'version two\n' > /tmp/hello.txt rc object copy /tmp/hello.txt rustfs/my-bucket/hello.txt --overwrite ``` -List versions and record the version ID you want to recover: +バージョンを一覧し、復元するバージョン ID を記録します。 ```bash rc bucket version list rustfs/my-bucket/hello.txt --json @@ -68,7 +68,7 @@ rc object stat rustfs/my-bucket/hello.txt \ --version-id --json ``` -Restore an earlier version by downloading its body and uploading it as a new latest version: +以前のバージョンの本文をダウンロードし、新しい最新バージョンとしてアップロードして復元します。 ```bash rc object show rustfs/my-bucket/hello.txt \ @@ -78,48 +78,48 @@ rc object copy /tmp/hello-restored.txt \ rustfs/my-bucket/hello.txt --overwrite ``` -Delete the current key to create a delete marker, then inspect it: +現在のキーを削除して削除マーカーを作成し、結果を確認します。 ```bash rc object remove rustfs/my-bucket/hello.txt --force rc bucket version list rustfs/my-bucket/hello.txt --json ``` -The latest entry should show `is_delete_marker: true`. The earlier versions remain available by version ID. +最新のエントリには `is_delete_marker: true` が表示されるはずです。それより前のバージョンは、バージョン ID を指定すれば引き続き利用できます。 -Suspend versioning when you no longer want normal writes to create new numbered versions: +通常の書き込みで新しい番号付きバージョンを作成しないようにするには、バージョニングを一時停止します。 ```bash rc bucket version suspend rustfs/my-bucket rc bucket version info rustfs/my-bucket ``` -:::warning[rc 0.1.29 version deletion boundary] +:::warning[rc 0.1.29 におけるバージョン削除の制限] -`rc object remove --versions` is listed in the `rc 0.1.29` help output but returns `not implemented`. Use the Console or an S3 SDK to permanently delete selected version IDs. Do not remove an entire version history unless you have verified retention, replication, and recovery requirements. +`rc object remove --versions` は `rc 0.1.29` のヘルプ出力に記載されていますが、`not implemented` を返します。選択したバージョン ID を完全に削除するには、Console または S3 SDK を使います。保持、レプリケーション、復旧の要件を確認するまで、バージョン履歴全体は削除しないでください。 ::: -## Verification +## 検証 -After enabling versioning: +バージョニングを有効にしたあと、次を確認します。 -1. Upload the same key twice with different content. -2. Run `rc bucket version list` and confirm that both entries have distinct version IDs. -3. Retrieve each version with `rc object show --version-id` and compare its content. -4. Delete the key without a version ID and confirm that a delete marker appears. -5. Retrieve an older version by version ID to confirm it remains recoverable. +1. 内容の異なる同じキーを、2 回アップロードします。 +2. `rc bucket version list` を実行し、両方のエントリのバージョン ID が異なることを確認します。 +3. `rc object show --version-id` で各バージョンを取得し、内容を比較します。 +4. バージョン ID を指定せずにキーを削除し、削除マーカーが現れることを確認します。 +5. 古いバージョンをバージョン ID で取得し、復元できることを確認します。 -## Operational considerations +## 運用上の考慮事項 -- Versioning increases storage use because overwrites and deletes retain older data. -- Configure lifecycle rules for noncurrent versions only after defining recovery and retention periods. -- Bucket replication requires versioning on both source and destination buckets. -- Object Lock depends on versioning and protects individual versions. -- Multipart completion creates one new object version in a versioned bucket. +- 上書きと削除が古いデータを残すため、バージョニングによってストレージ使用量が増えます。 +- 非現行バージョンのライフサイクルルールは、復旧期間と保持期間を定義したあとにだけ設定します。 +- バケットレプリケーションには、ソースと宛先の両方のバケットでバージョニングが必要です。 +- オブジェクトロックはバージョニングに依存し、個々のバージョンを保護します。 +- マルチパートの完了は、バージョニングが有効なバケットに、新しいオブジェクトバージョンを 1 つ作成します。 -## Next steps +## 次のステップ -- [Protect versions with Object Lock](./object-lock.md) -- [Upload large objects](./multipart-upload.md) -- [Manage bucket lifecycle](../lifecycle-management.md) \ No newline at end of file +- [オブジェクトロックでバージョンを保護する](./object-lock.md) +- [大きなオブジェクトをアップロードする](./multipart-upload.md) +- [バケットのライフサイクルを管理する](../lifecycle-management.md) diff --git a/content/ja/administration/data/s3-tables.md b/content/ja/administration/data/s3-tables.md index 0db824403..80d78dd78 100644 --- a/content/ja/administration/data/s3-tables.md +++ b/content/ja/administration/data/s3-tables.md @@ -34,12 +34,12 @@ flowchart TB ## 前提条件 -- 上記の S3 Tables エンドポイントを備えた RustFS を起動します。[インストール](/installation)を参照してください。 -- [AWS CLI](/developer/examples/aws-cli) と、`--aws-sigv4` および `--fail-with-body` をサポートする `curl` 7.76 以降をインストールします。 +- 上記の S3 Tables エンドポイントを備えた RustFS を起動します。[インストール](/ja/installation)を参照してください。 +- [AWS CLI](/ja/developer/examples/aws-cli) と、`--aws-sigv4` および `--fail-with-body` をサポートする `curl` 7.76 以降をインストールします。 - このチュートリアル専用の新しいバケットを用意します。例では `my-bucket` を使用します。 - カタログ操作と S3 オブジェクトの両方にアクセスできる既存の管理者アカウントを使用します。組み込みの `consoleAdmin` ポリシーは、このチュートリアルの操作をカバーします。アプリケーションには、範囲を絞ったポリシーを設定してください。 -例では `http://localhost:9000` を使用します。サーバーのエンドポイントに置き換え、ローカルテスト環境以外では証明書の検証を有効にした [TLS](/integration/tls-configured) を使用してください。 +例では `http://localhost:9000` を使用します。サーバーのエンドポイントに置き換え、ローカルテスト環境以外では証明書の検証を有効にした [TLS](/ja/integration/tls-configured) を使用してください。 :::warning[テーブルバケットのライフサイクル動作] @@ -116,13 +116,13 @@ curl --fail-with-body --silent --show-error \ クライアントはカタログ URI に `/v1` を追加します。ウェアハウスには S3 URI や AWS S3 Tables ARN ではなく、バケット名を指定します。同じアカウントを使用する場合でも、REST リクエストの署名と S3 ファイルアクセスの両方を設定します。 -別の Iceberg REST カタログをすでに運用している場合は、[Apache Iceberg 連携](/developer/integration/big-data/iceberg)の外部カタログを使用する構成を参照してください。 +別の Iceberg REST カタログをすでに運用している場合は、[Apache Iceberg 連携](/ja/developer/integration/big-data/iceberg)の外部カタログを使用する構成を参照してください。 ## 権限と認証情報 テーブルバケットの有効化には `admin:SetTableBucket`、状態の確認には `admin:GetTableBucket` が必要です。カタログの検出には `admin:GetTableCatalog` を使用します。名前空間とテーブルの操作には、それぞれ `admin:SetTableNamespace`、`admin:CreateTable`、`admin:GetTableMetadata`、`admin:CommitTable` などの RustFS 管理アクションがあります。 -テーブルファイルの読み書きには、通常の S3 権限も必要です。RustFS はウェアハウス内のオブジェクトパスに対してテーブル権限を確認します。読み取りには対応する `admin:GetTableMetadata` の認可、書き込みには `admin:SetTableMetadata` の認可が必要です。カタログのコミット権限だけでは、その前に行う S3 ファイルの書き込みは許可されません。両方のインターフェースに対して [IAM ポリシー](/security-compliance/iam/policies)を設定してください。 +テーブルファイルの読み書きには、通常の S3 権限も必要です。RustFS はウェアハウス内のオブジェクトパスに対してテーブル権限を確認します。読み取りには対応する `admin:GetTableMetadata` の認可、書き込みには `admin:SetTableMetadata` の認可が必要です。カタログのコミット権限だけでは、その前に行う S3 ファイルの書き込みは許可されません。両方のインターフェースに対して [IAM ポリシー](/ja/security-compliance/iam/policies)を設定してください。 カタログの認証情報ベンディング（vended credentials）は、デフォルトで無効です。有効にした場合、対応するクライアントは `X-Iceberg-Access-Delegation: vended-credentials` を使ってネゴシエーションし、呼び出し元にはテーブル用の認証情報を要求する権限が必要です。カタログへの初回接続にも、認可されたプリンシパル（主体）が必要です。リンク先の PyIceberg チュートリアルでは、明示的に設定した認証情報を使用します。 @@ -151,6 +151,6 @@ RustFS S3 Tables は、SQL 実行エンジン、複数テーブルにまたが ## 次のステップ -- [PyIceberg チュートリアル](/developer/integration/big-data/pyiceberg)を実行します。 -- アプリケーションへのアクセスを許可する前に、[IAM ポリシー](/security-compliance/iam/policies)を確認します。 +- [PyIceberg チュートリアル](/ja/developer/integration/big-data/pyiceberg)を実行します。 +- アプリケーションへのアクセスを許可する前に、[IAM ポリシー](/ja/security-compliance/iam/policies)を確認します。 - リポジトリの[クライアント適合性チェック](https://github.com/rustfs/rustfs/blob/7e0c67111b97703d47e23719b0264a739c8acea8/scripts/table-catalog/README.md)を使用して、ほかのクライアントバージョンを検証します。 diff --git a/content/ja/administration/data/tiered-storage.md b/content/ja/administration/data/tiered-storage.md index d36257683..c2103fe2e 100644 --- a/content/ja/administration/data/tiered-storage.md +++ b/content/ja/administration/data/tiered-storage.md @@ -1,11 +1,11 @@ --- -title: "Tiered Storage" -description: "Configure lifecycle-driven object transitions from RustFS to a remote storage tier." +title: "階層化ストレージ" +description: "ライフサイクルに基づき、RustFS のオブジェクトをリモートのストレージ階層へ移行する設定を説明します。" --- -RustFS tiered storage moves objects from local storage to a configured remote backend. This page explains the supported targets and shows how to add and maintain a RustFS tier in the Console. +RustFS の階層化ストレージは、ローカルストレージ上のオブジェクトを、設定したリモートバックエンドへ移します。このページでは、対応しているターゲットを説明し、Console で RustFS の階層を追加して維持する方法を示します。 -Tiering is asynchronous. RustFS keeps the object metadata locally, transfers the object data to the remote tier, and continues to serve S3 reads through the original bucket and object key. +階層化は非同期です。RustFS はオブジェクトのメタデータをローカルに保持し、オブジェクトデータをリモート階層へ転送し、元のバケットとオブジェクトキーを通じた S3 の読み取りを継続して提供します。 ```mermaid flowchart LR @@ -14,87 +14,87 @@ flowchart LR H -->|Read transitioned object| T ``` -:::note[Tier names are not AWS storage classes] +:::note[階層名は AWS のストレージクラスではない] -Lifecycle rules refer to a registered tier by its uppercase name, such as `COLDTIER`. Do not substitute AWS class labels such as `INTELLIGENT_TIERING`, `GLACIER`, or `DEEP_ARCHIVE` unless you have registered a RustFS tier with that exact valid name and verified the target behavior. +ライフサイクルルールは、`COLDTIER` のような大文字の名前で、登録済みの階層を参照します。その文字列と完全に一致する有効な名前で RustFS の階層を登録し、ターゲットの動作を確認していない限り、`INTELLIGENT_TIERING`、`GLACIER`、`DEEP_ARCHIVE` のような AWS のクラスラベルで代用してはなりません。 ::: -## Supported backends +## 対応しているバックエンド -The RustFS source defines warm-backend implementations for these target types: +RustFS のソースは、次のターゲット種別について、ウォームバックエンドの実装を定義しています。 -| Type | Configuration key | Typical target | +| 種別 | 設定キー | 典型的なターゲット | | --- | --- | --- | -| RustFS | `rustfs` | Another RustFS deployment | -| S3 | `s3` | Amazon S3 or an S3 endpoint supported by this backend | -| Wasabi | `wasabi` | Wasabi object storage | -| MinIO | `minio` | A MinIO deployment | -| Aliyun | `aliyun` | Alibaba Cloud Object Storage Service (OSS) | -| Tencent | `tencent` | Tencent Cloud Object Storage (COS) | -| Huaweicloud | `huaweicloud` | Huawei Cloud Object Storage Service (OBS) | +| RustFS | `rustfs` | 別の RustFS デプロイ | +| S3 | `s3` | Amazon S3、またはこのバックエンドが対応する S3 エンドポイント | +| Wasabi | `wasabi` | Wasabi のオブジェクトストレージ | +| MinIO | `minio` | MinIO デプロイ | +| Aliyun | `aliyun` | Alibaba Cloud Object Storage Service（OSS） | +| Tencent | `tencent` | Tencent Cloud Object Storage（COS） | +| Huaweicloud | `huaweicloud` | Huawei Cloud Object Storage Service（OBS） | | Azure | `azure` | Azure Blob Storage | | GCS | `gcs` | Google Cloud Storage | | R2 | `r2` | Cloudflare R2 | -Provider payloads and credential requirements differ. The complete workflow below uses the RustFS backend because the RustFS source includes an end-to-end hot-cluster-to-cold-cluster test for this path. +プロバイダーごとのペイロードと、認証情報の要件は異なります。以下の一連の手順では RustFS バックエンドを使います。RustFS のソースに、この経路のホットクラスターからコールドクラスターまでのエンドツーエンドテストが含まれているためです。 -## Before you begin +## 始める前に -Prepare the following: +次を準備します。 -- A source RustFS deployment that stores the hot data. -- A separate target RustFS deployment and an existing target bucket. This example uses `my-bucket` on the target. -- Target credentials with permission to put, get, list, and delete objects in that bucket. -- Access to the source deployment's RustFS Console. +- ホットデータを格納する、ソースの RustFS デプロイ。 +- ソースとは別のターゲット RustFS デプロイと、既存のターゲットバケット。この例では、ターゲット上の `my-bucket` を使います。 +- そのバケットでオブジェクトの書き込み、取得、一覧表示、削除ができる、ターゲットの認証情報。 +- ソースデプロイの RustFS Console へのアクセス。 -Use TLS for both deployments in production. Restrict the target credentials to the dedicated tier bucket and prefix. +本番では、両方のデプロイに TLS を使います。ターゲットの認証情報は、階層専用のバケットとプレフィックスに制限します。 -## 1. Open Tiered Storage +## 1. 階層化ストレージを開く -Sign in to the source deployment's RustFS Console. In the left navigation, select **Tiered Storage**, then select **Add Tier** in the upper-right corner. +ソースデプロイの RustFS Console にサインインします。左のナビゲーションで **Tiered Storage**（階層化ストレージ）を選び、右上の **Add Tier**（階層を追加）を選びます。 -## 2. Select the target +## 2. ターゲットを選択する -Select the target provider. This example uses **RustFS** to connect the source deployment to another RustFS deployment. +ターゲットのプロバイダーを選びます。この例では **RustFS** を選び、ソースデプロイを別の RustFS デプロイへ接続します。 -## 3. Enter the target details +## 3. ターゲットの詳細を入力する -Complete the form: +フォームに入力します。 -| Field | Value | +| フィールド | 値 | | --- | --- | -| **Name (A-Z,0-9,_)** | Enter a unique uppercase tier name, such as `COLDTIER`. | -| **Endpoint** | Enter the target RustFS S3 endpoint. | -| **Access Key** | Enter the access key for the target deployment. | -| **Secret Key** | Enter the secret key for the target deployment. | -| **Bucket** | Enter the existing target bucket name, such as `my-bucket`. | -| **Prefix (Optional)** | Optionally enter a prefix dedicated to tiered objects. | -| **Region** | Optionally enter the target region, such as `us-east-1`. | +| **Name (A-Z,0-9,_)**（名前。A-Z、0-9、_） | `COLDTIER` のような、一意で大文字の階層名を入力します。 | +| **Endpoint**（エンドポイント） | ターゲットとなる RustFS の S3 エンドポイントを入力します。 | +| **Access Key**（アクセスキー） | ターゲットデプロイのアクセスキーを入力します。 | +| **Secret Key**（シークレットキー） | ターゲットデプロイのシークレットキーを入力します。 | +| **Bucket**（バケット） | `my-bucket` のような、既存のターゲットバケット名を入力します。 | +| **Prefix (Optional)**（プレフィックス。任意） | 階層へ移すオブジェクト専用のプレフィックスを、必要に応じて入力します。 | +| **Region**（リージョン） | `us-east-1` のようなターゲットのリージョンを、必要に応じて入力します。 | -Leave **Storage Class** at its default unless the target backend requires a different supported storage class. +ターゲットバックエンドが、別の対応ストレージクラスを要求する場合を除き、**Storage Class**（ストレージクラス）は既定のままにします。 -:::warning[Protect tier credentials] +:::warning[階層の認証情報を保護する] -The form contains a secret key. Use credentials restricted to the target bucket and prefix. Do not expose the key in screenshots, tickets, or logs. +フォームにはシークレットキーが含まれます。ターゲットのバケットとプレフィックスに制限した認証情報を使います。スクリーンショット、チケット、ログにキーを出してはなりません。 ::: -## 4. Save the tier +## 4. 階層を保存する -Select **Save**. RustFS validates the backend and probes it by writing, reading, and removing a small object. Saving fails when the endpoint, credentials, bucket permissions, or backend configuration cannot complete that probe. +**Save**（保存）を選びます。RustFS はバックエンドを検証し、小さなオブジェクトの書き込み、読み取り、削除によって疎通を確認します。エンドポイント、認証情報、バケットの権限、またはバックエンド設定がその確認を完了できない場合、保存は失敗します。 -After the tier appears in the **Tiers** list, configure a transition rule in [Lifecycle Management](/administration/data/lifecycle-management). A registered tier does not move objects until a lifecycle rule references its name. +**Tiers**（階層）の一覧に階層が表示されたあと、[ライフサイクル管理](/ja/administration/data/lifecycle-management) で移行ルールを設定します。登録しただけではオブジェクトは移動しません。ライフサイクルルールがその階層名を参照して初めて移動します。 -## Manage tiers with `rc` +## `rc` で階層を管理する -Install and configure [`rc`](/operations/rc), then list the tiers registered on the source deployment: +[`rc`](/ja/operations/rc) をインストールして設定し、ソースデプロイに登録された階層を一覧します。 ```bash rc bucket lifecycle tier list local ``` -Add a RustFS tier with the same settings described in the Console workflow: +Console の手順で説明したのと同じ設定で、RustFS の階層を追加します。 ```bash rc bucket lifecycle tier add rustfs COLDTIER local \ @@ -105,13 +105,13 @@ rc bucket lifecycle tier add rustfs COLDTIER local \ --region us-east-1 ``` -Inspect the tier configuration and available statistics: +階層の設定と、取得できる統計を確認します。 ```bash rc bucket lifecycle tier info COLDTIER local ``` -The remaining tier commands update credentials or remove a tier: +残りの階層コマンドは、認証情報の更新と、階層の削除です。 ```bash rc bucket lifecycle tier edit COLDTIER local \ @@ -120,60 +120,60 @@ rc bucket lifecycle tier edit COLDTIER local \ rc bucket lifecycle tier remove COLDTIER local ``` -See [Lifecycle Management](/administration/data/lifecycle-management) to create transition rules, confirm transitions, and restore local copies. Run `rc bucket lifecycle tier --help` to inspect provider-specific options before changing a tier. +移行ルールの作成、移行の確認、ローカルコピーの復元は、[ライフサイクル管理](/ja/administration/data/lifecycle-management) を参照します。階層を変更する前に `rc bucket lifecycle tier --help` を実行し、プロバイダー固有のオプションを確認します。 -## Monitor tier activity +## 階層の稼働状況を監視する -Use the tier statistics endpoint with a SigV4-signed request and `admin:ListTier` permission: +SigV4 で署名したリクエストと、`admin:ListTier` 権限を使い、階層の統計エンドポイントを呼び出します。 ```http GET /rustfs/admin/v3/tier-stats?tier=COLDTIER HTTP/1.1 Host: ``` -Monitor transition failures together with source-cluster capacity and target-side availability. A configured tier adds the target service and network path to the read path for objects that do not have a restored local copy. +移行の失敗は、ソースクラスターの容量と、ターゲット側の可用性とともに監視します。階層を設定すると、復元済みのローカルコピーがないオブジェクトの読み取り経路に、ターゲットのサービスとネットワーク経路が加わります。 -## Change or remove a tier +## 階層を変更または削除する -The Admin API exposes these mutation routes, all requiring `admin:SetTier`: +Admin API は、次の変更用ルートを公開しています。いずれも `admin:SetTier` が必要です。 -| Operation | Route | +| 操作 | ルート | | --- | --- | -| Edit a tier | `POST /rustfs/admin/v3/tier/{tiername}` | -| Remove a tier | `DELETE /rustfs/admin/v3/tier/{tiername}` | -| Clear all tiers | `POST /rustfs/admin/v3/tier/clear` | +| 階層を編集する | `POST /rustfs/admin/v3/tier/{tiername}` | +| 階層を削除する | `DELETE /rustfs/admin/v3/tier/{tiername}` | +| すべての階層を消去する | `POST /rustfs/admin/v3/tier/clear` | -Before editing or removing a tier: +階層を編集または削除する前に、次を行います。 -1. Disable lifecycle rules that reference the tier. -2. Confirm that no transition jobs are still using it. -3. Confirm that no source objects depend on data stored in its target bucket or prefix. -4. Back up the tier configuration and record the target location. +1. その階層を参照するライフサイクルルールを無効にします。 +2. 移行ジョブが、その階層をまだ使っていないことを確認します。 +3. ソースのオブジェクトが、そのターゲットバケットまたはプレフィックスに保存されたデータに依存していないことを確認します。 +4. 階層の設定をバックアップし、ターゲットの場所を記録します。 -Normal tier mutations check backend usage and protect non-empty targets. Do not use a `force` option to bypass those checks unless you have independently proved that every transitioned object remains recoverable. Removing configuration for an active tier can make transitioned objects unreadable from the source cluster. +通常の階層の変更では、バックエンドの使用状況を確認し、空でないターゲットを保護します。移行済みオブジェクトがすべて回復できることを独自に証明していない限り、それらの確認を迂回する `force` オプションを使ってはなりません。使用中の階層の設定を削除すると、ソースクラスターから移行済みオブジェクトを読み取れなくなることがあります。 -:::warning[Do not modify tier objects directly] +:::warning[階層上のオブジェクトを直接変更しない] -Do not rename, overwrite, or delete generated objects in the target bucket. Manage source objects through the hot RustFS cluster so RustFS can keep local transition metadata and remote data consistent. +ターゲットバケット内で生成されたオブジェクトの名前変更、上書き、削除をしてはなりません。ローカルの移行メタデータとリモートデータの整合を RustFS が保てるよう、ソースオブジェクトはホット側の RustFS クラスターを通して管理します。 ::: -## Admin API reference +## Admin API リファレンス -The current RustFS source registers these tier routes: +現在の RustFS ソースは、次の階層用ルートを登録しています。 -| Method | Route | Permission | +| メソッド | ルート | 権限 | | --- | --- | --- | | `PUT` | `/rustfs/admin/v3/tier` | `admin:SetTier` | | `POST` | `/rustfs/admin/v3/tier/{tiername}` | `admin:SetTier` | | `DELETE` | `/rustfs/admin/v3/tier/{tiername}` | `admin:SetTier` | | `POST` | `/rustfs/admin/v3/tier/clear` | `admin:SetTier` | -| `GET` | `/rustfs/admin/v3/tier` (list configurations) | `admin:ListTier` | -| `GET` | `/rustfs/admin/v3/tier/{tier}` (verify connectivity) | `admin:ListTier` | -| `GET` | `/rustfs/admin/v3/tier-stats` (read statistics) | `admin:ListTier` | +| `GET` | `/rustfs/admin/v3/tier`（設定の一覧） | `admin:ListTier` | +| `GET` | `/rustfs/admin/v3/tier/{tier}`（接続の確認） | `admin:ListTier` | +| `GET` | `/rustfs/admin/v3/tier-stats`（統計の読み取り） | `admin:ListTier` | -All Admin API requests require SigV4 authentication. These routes are an administrative interface, not ordinary S3 bucket operations. +Admin API のリクエストには、すべて SigV4 認証が必要です。これらのルートは管理用インターフェースであり、通常の S3 バケット操作ではありません。 -## Next steps +## 次のステップ -Review [lifecycle management](/administration/data/lifecycle-management) and configure [access policies](/security-compliance/iam/policies) for the administrators and service credentials used by tiered storage. \ No newline at end of file +[ライフサイクル管理](/ja/administration/data/lifecycle-management) を確認し、階層化ストレージで使う管理者とサービス認証情報に [アクセスポリシー](/ja/security-compliance/iam/policies) を設定します。 diff --git a/content/ja/administration/index.md b/content/ja/administration/index.md index 930e9cd1a..2526fb38f 100644 --- a/content/ja/administration/index.md +++ b/content/ja/administration/index.md @@ -9,9 +9,9 @@ description: "RustFS のデータ、アクセスプロトコル、ブラウザ - [コンソール](./console/index.md)では、ブラウザからの管理とサインイン方法を説明します。 - [データ管理](./data/object/object-lock.md)では、バケット、オブジェクト、ライフサイクルの動作、データ保護機能を説明します。 -- [S3 Tables](/administration/data/s3-tables)では、テーブルバケットと組み込みの Iceberg REST カタログを説明します。 +- [S3 Tables](/ja/administration/data/s3-tables)では、テーブルバケットと組み込みの Iceberg REST カタログを説明します。 - [プロトコル](./protocols/s3.md)では、S3、WebDAV、FTPS、SFTP によるアクセスを説明します。 - [CORS の設定](./cors/index.md)では、RustFS サービスへのクロスオリジンアクセスを説明します。 -- [仮想ホスト形式のアクセス](/integration/virtual)では、ドメインに基づく S3 のアドレス指定を説明します。 +- [仮想ホスト形式のアクセス](/ja/integration/virtual)では、ドメインに基づく S3 のアドレス指定を説明します。 -ID、暗号化、通信の保護、監査については、[セキュリティとコンプライアンス](/security-compliance)に進んでください。 +ID、暗号化、通信の保護、監査については、[セキュリティとコンプライアンス](/ja/security-compliance)に進んでください。 diff --git a/content/ja/administration/protocols/ftps.md b/content/ja/administration/protocols/ftps.md index e7031a026..3ef7cddc2 100644 --- a/content/ja/administration/protocols/ftps.md +++ b/content/ja/administration/protocols/ftps.md @@ -1,83 +1,83 @@ --- title: "FTP(S)" -description: "Configure the RustFS FTP or FTPS gateway and manage buckets and objects with FTP clients." +description: "RustFS の FTP または FTPS ゲートウェイを設定し、FTP クライアントでバケットとオブジェクトを管理する方法を説明します。" --- -RustFS includes an FTP gateway that exposes buckets and objects to standard FTP clients. You can run it as unencrypted FTP for isolated local testing or as explicit FTP over TLS (FTPS) for encrypted connections. RustFS authenticates each session against Identity and Access Management (IAM) and applies the user's S3 policies to storage operations. +RustFS には、バケットとオブジェクトを標準の FTP クライアントへ公開する FTP ゲートウェイが含まれます。隔離したローカルテストでは暗号化しない FTP として、暗号化接続では明示的な FTP over TLS（FTPS）として実行できます。RustFS は各セッションをアイデンティティとアクセス管理（IAM）に対して認証し、そのユーザーの S3 ポリシーをストレージ操作へ適用します。 -FTP and FTPS support is compiled into the standard RustFS binary, but both listeners are disabled at runtime by default. Enable only the listener you intend to use. +FTP と FTPS のサポートは標準の RustFS バイナリにコンパイルされていますが、両方のリスナーは実行時に既定で無効です。使う予定のリスナーだけを有効にします。 -## Overview +## 概要 -The gateway maps FTP paths to RustFS resources: +ゲートウェイは、FTP のパスを RustFS のリソースへ対応付けます。 -| FTP path | RustFS resource | +| FTP パス | RustFS のリソース | | --- | --- | -| `/` | All buckets visible to the authenticated user | -| `/my-bucket/` | The `my-bucket` bucket | -| `/my-bucket/hello.txt` | The `hello.txt` object in `my-bucket` | +| `/` | 認証されたユーザーから見えるすべてのバケット | +| `/my-bucket/` | `my-bucket` バケット | +| `/my-bucket/hello.txt` | `my-bucket` 内の `hello.txt` オブジェクト | -The following FTP operations are supported: +次の FTP 操作に対応しています。 -| FTP command | Operation | +| FTP コマンド | 操作 | | --- | --- | -| `LIST` | List buckets at the root or objects and prefixes in a bucket | -| `MKD` | Create a bucket | -| `CWD` | Enter a bucket | -| `STOR` | Upload an object | -| `RETR` | Download an object | -| `DELE` | Delete an object | -| `RMD` | Recursively delete a bucket and its objects | +| `LIST` | ルートのバケット、またはバケット内のオブジェクトとプレフィックスを一覧します | +| `MKD` | バケットを作成します | +| `CWD` | バケットに入ります | +| `STOR` | オブジェクトをアップロードします | +| `RETR` | オブジェクトをダウンロードします | +| `DELE` | オブジェクトを削除します | +| `RMD` | バケットとそのオブジェクトを再帰的に削除します | -RustFS does not currently support FTP rename operations or uploads that append to an existing object. Because S3 storage has no native working-directory or POSIX directory model, some client-specific filesystem operations may not behave like a traditional FTP server. +RustFS は現時点では、FTP の名前変更と、既存オブジェクトへ追記するアップロードには対応していません。S3 ストレージにはネイティブな作業ディレクトリや POSIX のディレクトリモデルがないため、クライアント固有のファイルシステム操作は、従来の FTP サーバーと同じようには動作しない場合があります。 -Enter a RustFS access key as the FTP username and its secret key as the password. Invalid usernames and passwords both return `530 Not logged in`. After login, RustFS checks the IAM user's S3 permissions for each operation. +FTP のユーザー名には RustFS のアクセスキーを、パスワードにはそのシークレットキーを入力します。無効なユーザー名とパスワードは、いずれも `530 Not logged in` を返します。ログイン後、RustFS は操作ごとに IAM ユーザーの S3 権限を確認します。 -:::danger[Plain FTP exposes credentials] +:::danger[平文の FTP は認証情報を露出します] -FTP sends credentials and data without encryption. Bind plain FTP to a loopback or isolated test network only. Use FTPS for every remote or production connection. +FTP は、認証情報とデータを暗号化せずに送信します。平文の FTP は、ループバックまたは隔離したテストネットワークにだけバインドします。リモート接続と本番接続では、すべて FTPS を使います。 ::: -:::warning[Bucket deletion is recursive] +:::warning[バケットの削除は再帰的です] -The current `RMD` implementation deletes the objects in the target bucket before deleting the bucket. Confirm the path before running `rmdir` in an FTP client. +現在の `RMD` の実装は、バケットを削除する前に、対象バケット内のオブジェクトを削除します。FTP クライアントで `rmdir` を実行する前に、パスを確認します。 ::: -## Configuration +## 設定 -FTP and FTPS use separate listeners and environment variables. +FTP と FTPS は、別々のリスナーと環境変数を使います。 -### FTP variables +### FTP の変数 -| Variable | Description | Default | +| 変数 | 説明 | 既定値 | | --- | --- | --- | -| `RUSTFS_FTP_ENABLE` | Enables the unencrypted FTP listener. | `false` | -| `RUSTFS_FTP_ADDRESS` | Bind address for FTP control connections. | `0.0.0.0:8021` | -| `RUSTFS_FTP_PASSIVE_PORTS` | Inclusive passive data port range in `start-end` format. | `40000-50000` | -| `RUSTFS_FTP_EXTERNAL_IP` | Public IP or hostname advertised to passive clients when RustFS is behind NAT. | Not set | +| `RUSTFS_FTP_ENABLE` | 暗号化しない FTP リスナーを有効にします。 | `false` | +| `RUSTFS_FTP_ADDRESS` | FTP 制御接続のバインドアドレスです。 | `0.0.0.0:8021` | +| `RUSTFS_FTP_PASSIVE_PORTS` | `start-end` 形式の、両端を含むパッシブデータポートの範囲です。 | `40000-50000` | +| `RUSTFS_FTP_EXTERNAL_IP` | RustFS が NAT の背後にあるとき、パッシブクライアントへ通知する公開 IP またはホスト名です。 | 未設定 | -### FTPS variables +### FTPS の変数 -| Variable | Description | Default | +| 変数 | 説明 | 既定値 | | --- | --- | --- | -| `RUSTFS_FTPS_ENABLE` | Enables the explicit FTPS listener. | `false` | -| `RUSTFS_FTPS_ADDRESS` | Bind address for FTPS control connections. | `0.0.0.0:8022` | -| `RUSTFS_FTPS_TLS_ENABLED` | Enables TLS on the FTPS listener. Keep this enabled for FTPS. | `true` | -| `RUSTFS_FTPS_CERTS_DIR` | Directory containing the FTPS certificate and private key. Required for FTPS. | Not set | -| `RUSTFS_FTPS_PASSIVE_PORTS` | Inclusive passive data port range in `start-end` format. | `40000-50000` | -| `RUSTFS_FTPS_EXTERNAL_IP` | Public IP or hostname advertised to passive clients when RustFS is behind NAT. | Not set | +| `RUSTFS_FTPS_ENABLE` | 明示的な FTPS リスナーを有効にします。 | `false` | +| `RUSTFS_FTPS_ADDRESS` | FTPS 制御接続のバインドアドレスです。 | `0.0.0.0:8022` | +| `RUSTFS_FTPS_TLS_ENABLED` | FTPS リスナーで TLS を有効にします。FTPS では有効のままにします。 | `true` | +| `RUSTFS_FTPS_CERTS_DIR` | FTPS の証明書と秘密鍵を含むディレクトリです。FTPS では必須です。 | 未設定 | +| `RUSTFS_FTPS_PASSIVE_PORTS` | `start-end` 形式の、両端を含むパッシブデータポートの範囲です。 | `40000-50000` | +| `RUSTFS_FTPS_EXTERNAL_IP` | RustFS が NAT の背後にあるとき、パッシブクライアントへ通知する公開 IP またはホスト名です。 | 未設定 | -The standard RustFS build enables the `ftps` compile-time feature, which provides both FTP and FTPS. If you build RustFS with `--no-default-features`, include the feature explicitly: +標準の RustFS ビルドでは、FTP と FTPS の両方を提供するコンパイル時機能 `ftps` が有効です。`--no-default-features` で RustFS をビルドする場合は、この機能を明示的に含めます。 ```bash cargo build --release --features ftps ``` -### Local testing with FTP +### FTP でのローカルテスト -Start an unencrypted FTP listener on the loopback interface: +ループバックインターフェースで、暗号化しない FTP リスナーを起動します。 ```bash export RUSTFS_FTP_ENABLE=true @@ -89,11 +89,11 @@ export RUSTFS_SECRET_KEY= rustfs /path/to/data ``` -Binding to `127.0.0.1` prevents remote hosts from connecting to the unencrypted listener. +`127.0.0.1` にバインドすると、リモートホストは暗号化されていないリスナーへ接続できません。 -### Prepare a test certificate +### テスト用証明書を用意する -FTPS expects `rustfs_cert.pem` and `rustfs_key.pem` in the certificate directory. For local testing, create a short-lived self-signed certificate: +FTPS は、証明書ディレクトリに `rustfs_cert.pem` と `rustfs_key.pem` があることを前提とします。ローカルテストでは、有効期間の短い自己署名証明書を作成します。 ```bash mkdir -p /path/to/ftps-certs @@ -106,11 +106,11 @@ openssl req -x509 -newkey rsa:2048 -nodes \ -addext "subjectAltName=DNS:localhost,IP:127.0.0.1" ``` -Use a certificate issued by a trusted certificate authority in production. Protect `rustfs_key.pem` from unauthorized access and ensure the certificate subject alternative names match the host clients use. +本番では、信頼できる認証局が発行した証明書を使います。`rustfs_key.pem` を不正なアクセスから保護し、証明書のサブジェクト代替名が、クライアントの使うホストと一致するようにします。 -### Start FTPS +### FTPS を起動する -Configure an explicit FTPS listener: +明示的な FTPS リスナーを設定します。 ```bash export RUSTFS_FTPS_ENABLE=true @@ -122,44 +122,44 @@ export RUSTFS_FTPS_PASSIVE_PORTS=40000-50000 rustfs /path/to/data ``` -RustFS requires TLS on both the FTPS control and data channels. Configure clients for **explicit FTP over TLS**, sometimes labeled **FTPES** or **Require explicit FTP over TLS**. Implicit FTPS is not the mode implemented by this listener. +RustFS は、FTPS の制御チャネルとデータチャネルの両方で TLS を必須とします。クライアントは **explicit FTP over TLS**（明示的な FTP over TLS）に設定します。**FTPES**、または **Require explicit FTP over TLS**（明示的な FTP over TLS を必須にする）と表示される場合もあります。暗黙的 FTPS は、このリスナーが実装する方式ではありません。 -If the certificate directory is missing, does not exist, or does not contain a usable certificate and key, FTPS initialization fails. See [Configure TLS](/integration/tls-configured) for general certificate guidance. +証明書ディレクトリが未指定である、存在しない、または使える証明書と鍵を含まない場合、FTPS の初期化は失敗します。証明書全般の手順は、[TLS を設定する](/ja/integration/tls-configured)を参照します。 -### Configure passive connections +### パッシブ接続を設定する -FTP uses the control port for commands and a separate data connection for listings and file transfers. For passive mode: +FTP はコマンドに制御ポートを使い、一覧とファイル転送には別のデータ接続を使います。パッシブモードでは、次のようにします。 -1. Allow inbound TCP traffic to the configured control port. -2. Allow inbound TCP traffic to every port in the configured passive range. -3. Set `RUSTFS_FTP_EXTERNAL_IP` or `RUSTFS_FTPS_EXTERNAL_IP` when clients connect through NAT or a load balancer. +1. 設定した制御ポートへの受信 TCP トラフィックを許可します。 +2. 設定したパッシブ範囲のすべてのポートへの受信 TCP トラフィックを許可します。 +3. クライアントが NAT またはロードバランサー経由で接続する場合は、`RUSTFS_FTP_EXTERNAL_IP` または `RUSTFS_FTPS_EXTERNAL_IP` を設定します。 -For example, an FTPS server behind NAT can advertise its public hostname: +たとえば、NAT の背後にある FTPS サーバーは、公開ホスト名を通知できます。 ```bash export RUSTFS_FTPS_EXTERNAL_IP=storage.example.com export RUSTFS_FTPS_PASSIVE_PORTS=40000-40100 ``` -Use the corresponding FTP-prefixed variables for the plain FTP listener. RustFS supports both active and passive transfer modes, but passive mode is generally easier to operate through client firewalls. +平文の FTP リスナーには、対応する FTP 接頭辞の変数を使います。RustFS はアクティブとパッシブの両方の転送モードに対応しますが、クライアントのファイアウォール越しでは、一般にパッシブモードの方が運用しやすいです。 -## Usage +## 使い方 -The examples use [`lftp`](https://lftp.yar.ru/) and the canonical `my-bucket` and `hello.txt` names. The IAM user must have the S3 permissions required for each operation. +例では [`lftp`](https://lftp.yar.ru/) と、標準の名前である `my-bucket` および `hello.txt` を使います。IAM ユーザーには、各操作に必要な S3 権限が必要です。 -### Connect with FTP +### FTP で接続する -Use plain FTP only with the loopback test listener: +平文の FTP は、ループバックのテストリスナーだけで使います。 ```bash lftp -u ftp://127.0.0.1:8021 ``` -Enter the secret key when `lftp` prompts for a password. +`lftp` がパスワードを求めたら、シークレットキーを入力します。 -### Connect with FTPS +### FTPS で接続する -Connect to the explicit FTPS listener and require encryption for control and data connections: +明示的な FTPS リスナーへ接続し、制御接続とデータ接続の暗号化を必須にします。 ```bash lftp -u -e ' @@ -169,9 +169,9 @@ lftp -u -e ' ' ``` -Enter the secret key when prompted. Keep certificate verification enabled in production. +求められたらシークレットキーを入力します。本番では、証明書の検証を有効なままにします。 -For the self-signed local test certificate only, connect to `localhost` and disable certificate verification for that session: +自己署名のローカルテスト証明書に限って、`localhost` へ接続し、そのセッションでは証明書の検証を無効にします。 ```bash lftp -u -e ' @@ -184,13 +184,13 @@ lftp -u -e ' :::warning -Do not disable certificate verification in production. Install the issuing CA in the client trust store instead. +本番では、証明書の検証を無効にしないでください。代わりに、発行元の CA をクライアントの信頼ストアへインストールします。 ::: -### List buckets and create a bucket +### バケットを一覧し、バケットを作成する -At the `lftp` prompt, list the visible buckets and create `my-bucket`: +`lftp` のプロンプトで、見えるバケットを一覧し、`my-bucket` を作成します。 ```text lftp> cls -1 / @@ -198,11 +198,11 @@ lftp> mkdir my-bucket lftp> cd my-bucket ``` -Bucket names must follow the same naming rules as buckets created through the S3 API. +バケット名は、S3 API で作成するバケットと同じ命名規則に従う必要があります。 -### Upload and download an object +### オブジェクトをアップロードおよびダウンロードする -Upload `/path/to/hello.txt`, list the bucket, and download the object: +`/path/to/hello.txt` をアップロードし、バケットを一覧して、オブジェクトをダウンロードします。 ```text lftp> put /path/to/hello.txt -o hello.txt @@ -210,11 +210,11 @@ lftp> ls lftp> get hello.txt -o hello.txt ``` -The upload replaces an object with the same key. Appending to an existing object is not supported. +アップロードは、同じキーのオブジェクトを置き換えます。既存オブジェクトへの追記には対応していません。 -### Delete an object and bucket +### オブジェクトとバケットを削除する -Delete the object, return to the root, and delete the bucket: +オブジェクトを削除し、ルートに戻って、バケットを削除します。 ```text lftp> rm hello.txt @@ -222,25 +222,25 @@ lftp> cd / lftp> rmdir my-bucket ``` -Remember that `rmdir` recursively removes remaining objects from the bucket before deleting it. +`rmdir` は、バケットを削除する前に、残っているオブジェクトを再帰的に削除します。 -### Connect other clients +### ほかのクライアントから接続する -Use these settings in graphical FTP clients such as FileZilla or Cyberduck: +FileZilla や Cyberduck などのグラフィカルな FTP クライアントでは、次の設定を使います。 -| Setting | FTP test listener | FTPS listener | +| 設定 | FTP テストリスナー | FTPS リスナー | | --- | --- | --- | -| Protocol | FTP | FTP over TLS (explicit) | -| Host | `127.0.0.1` | Your FTPS hostname | -| Port | `8021` | `8022` | -| Username | RustFS access key | RustFS access key | -| Password | RustFS secret key | RustFS secret key | -| Transfer mode | Passive | Passive | +| プロトコル | FTP | FTP over TLS（explicit） | +| ホスト | `127.0.0.1` | 使用する FTPS のホスト名 | +| ポート | `8021` | `8022` | +| ユーザー名 | RustFS のアクセスキー | RustFS のアクセスキー | +| パスワード | RustFS のシークレットキー | RustFS のシークレットキー | +| 転送モード | パッシブ | パッシブ | -If login succeeds but directory listings or transfers time out, check the passive port firewall rules and external IP setting first. +ログインには成功しても、ディレクトリ一覧や転送がタイムアウトする場合は、まずパッシブポートのファイアウォール規則と外部 IP の設定を確認します。 -## Next steps +## 次のステップ -- [Manage credentials](/operations/credentials) -- [Configure TLS](/integration/tls-configured) -- [Check service status](/operations/status-check) \ No newline at end of file +- [認証情報を管理する](/ja/operations/credentials) +- [TLS を設定する](/ja/integration/tls-configured) +- [サービスの状態を確認する](/ja/operations/status-check) diff --git a/content/ja/administration/protocols/s3.md b/content/ja/administration/protocols/s3.md index 0148cd28b..9b6bed22d 100644 --- a/content/ja/administration/protocols/s3.md +++ b/content/ja/administration/protocols/s3.md @@ -1,111 +1,111 @@ --- title: "S3" -description: "Configure and use the RustFS S3-compatible API with AWS CLI, AWS SDKs, and other S3 clients." +description: "AWS CLI、AWS SDK、その他の S3 クライアントで、RustFS の S3 互換 API を設定して使う方法を説明します。" --- -RustFS exposes an S3-compatible REST API for common object-storage workloads. It supports AWS Signature Version 4 (SigV4) and works with AWS CLI, AWS SDKs, and other S3 clients when you configure the RustFS endpoint, region, credentials, and addressing style. +RustFS は、一般的なオブジェクトストレージのワークロード向けに、S3 互換の REST API を公開します。AWS Signature Version 4（SigV4）に対応しており、RustFS のエンドポイント、リージョン、認証情報、アドレス指定方式を設定すれば、AWS CLI、AWS SDK、その他の S3 クライアントから利用できます。 -## Overview +## 概要 -S3 organizes data into buckets and objects. With the default path-style addressing, a RustFS URL maps to storage as follows: +S3 はデータをバケットとオブジェクトに整理します。既定のパススタイルアクセスでは、RustFS の URL は次のようにストレージへ対応します。 ```text http://localhost:9000/my-bucket/path/to/hello.txt | bucket | |---- object key ----| ``` -RustFS covers the common S3 data plane used by applications, backup tools, and SDKs: +RustFS は、アプリケーション、バックアップツール、SDK が使う一般的な S3 データプレーンを対象とします。 -| Area | Supported workflows | +| 領域 | 対応するワークフロー | | --- | --- | -| Buckets | Create, delete, list, inspect, and retrieve location | -| Objects | Put, get, head, copy, delete, multi-delete, range reads, conditional requests, and user metadata | -| Listing | `ListObjects`, `ListObjectsV2`, prefixes, delimiters, markers, and pagination | -| Large objects | Create, upload, copy, list, complete, and abort multipart uploads | -| Data management | Versioning, lifecycle rules, bucket and object tags, checksums, and object lock | -| Access control | IAM credentials and policies, bucket policies, public access block, and presigned GET/PUT URLs | -| Integration | CORS, bucket notifications, replication configuration, and server-side encryption workflows | +| バケット | 作成、削除、一覧、検査、ロケーションの取得 | +| オブジェクト | Put、Get、Head、コピー、削除、一括削除、範囲読み取り、条件付きリクエスト、ユーザーメタデータ | +| 一覧 | `ListObjects`、`ListObjectsV2`、プレフィックス、デリミタ、マーカー、ページネーション | +| 大きなオブジェクト | マルチパートアップロードの作成、アップロード、コピー、一覧、完了、中止 | +| データ管理 | バージョニング、ライフサイクルルール、バケットとオブジェクトのタグ、チェックサム、オブジェクトロック | +| アクセス制御 | IAM の認証情報とポリシー、バケットポリシー、パブリックアクセスブロック、署名付きの GET/PUT URL | +| 連携 | CORS、バケット通知、レプリケーション設定、サーバー側の暗号化のワークフロー | -Authenticated clients sign requests with an access key and secret key. Anonymous requests are evaluated against the applicable bucket policy. +認証されたクライアントは、アクセスキーとシークレットキーでリクエストに署名します。匿名リクエストは、適用されるバケットポリシーに対して評価されます。 -:::note[Compatibility scope] +:::note[互換性の範囲] -RustFS provides broad S3 API compatibility for supported features, but it is not identical to every AWS S3 or MinIO API. Review [Known compatibility differences](#known-compatibility-differences) before depending on advanced or vendor-specific behavior, and validate it against your target RustFS release. +RustFS は、サポートする機能について広い範囲の S3 API 互換を提供しますが、すべての AWS S3 API や MinIO API と同一ではありません。高度な動作やベンダー固有の動作に依存する前に、[既知の互換性の違い](#known-compatibility-differences)を確認し、対象の RustFS リリースに対して検証します。 ::: -## Configuration +## 設定 -The S3 API is enabled on the main RustFS listener. It does not require a separate protocol switch. +S3 API は、RustFS のメインリスナーで有効です。別のプロトコル切り替えは不要です。 -| Variable | Purpose | Default | +| 変数 | 用途 | 既定値 | | --- | --- | --- | -| `RUSTFS_ADDRESS` | S3 API bind address | `:9000` | -| `RUSTFS_REGION` | Region used for request signing and region-aware clients | `us-east-1` | -| `RUSTFS_ACCESS_KEY` | Root access key | Installation-specific | -| `RUSTFS_SECRET_KEY` | Root secret key | Installation-specific | -| `RUSTFS_SERVER_DOMAINS` | Comma-separated domains for virtual-hosted-style requests | Not set | -| `RUSTFS_TLS_PATH` | Directory containing `rustfs_cert.pem` and `rustfs_key.pem` | Not set | +| `RUSTFS_ADDRESS` | S3 API のバインドアドレス | `:9000` | +| `RUSTFS_REGION` | リクエストの署名と、リージョンを認識するクライアントが使うリージョン | `us-east-1` | +| `RUSTFS_ACCESS_KEY` | ルートアクセスキー | インストールごとに異なる | +| `RUSTFS_SECRET_KEY` | ルートシークレットキー | インストールごとに異なる | +| `RUSTFS_SERVER_DOMAINS` | 仮想ホスト形式のリクエストに使う、カンマ区切りのドメイン | 未設定 | +| `RUSTFS_TLS_PATH` | `rustfs_cert.pem` と `rustfs_key.pem` を含むディレクトリ | 未設定 | -Use IAM users or service accounts instead of root credentials for applications, and grant only the required S3 actions. +アプリケーションにはルート認証情報ではなく、IAM ユーザーまたはサービスアカウントを使い、必要な S3 アクションだけを許可します。 -### Path-style addressing +### パススタイルアクセス -Path-style addressing is the default and requires no DNS configuration. The bucket name is the first component of the request path: +パススタイルアクセスが既定であり、DNS の設定は不要です。バケット名は、リクエストパスの先頭の要素です。 ```text http://localhost:9000/my-bucket/hello.txt ``` -Configure clients with: +クライアントには、次を設定します。 -- Endpoint: `http://localhost:9000` -- Region: `us-east-1` -- Access key: `` -- Secret key: `` -- Addressing style: path-style +- エンドポイント: `http://localhost:9000` +- リージョン: `us-east-1` +- アクセスキー: `` +- シークレットキー: `` +- アドレス指定方式: パススタイルアクセス -Some clients default to virtual-hosted-style requests. Enable their path-style option, such as `force_path_style=true` in AWS SDK configuration or `s3_use_path_style = true` in Terraform. +一部のクライアントは、既定で仮想ホスト形式のリクエストを使います。パススタイルのオプションを有効にします。例として、AWS SDK の設定では `force_path_style=true`、Terraform では `s3_use_path_style = true` があります。 -### Virtual-hosted-style addressing +### 仮想ホスト形式 -Virtual-hosted-style addressing places the bucket name in the hostname. Set `RUSTFS_SERVER_DOMAINS` to each base domain that RustFS should recognize: +仮想ホスト形式では、バケット名をホスト名に含めます。RustFS に認識させるベースドメインを、それぞれ `RUSTFS_SERVER_DOMAINS` に設定します。 ```bash export RUSTFS_SERVER_DOMAINS="s3.example.com" ``` -The same object is then addressed as: +同じオブジェクトは、次のアドレスになります。 ```text https://my-bucket.s3.example.com/hello.txt ``` -Configure wildcard DNS, such as `*.s3.example.com`, to resolve to the RustFS endpoint. For HTTPS, the certificate must also cover the bucket hostnames. Bucket names containing dots may require explicit certificate names because a single-label wildcard does not span multiple labels. +`*.s3.example.com` のようなワイルドカード DNS が、RustFS のエンドポイントへ解決するよう設定します。HTTPS では、証明書がバケットのホスト名もカバーする必要があります。ドットを含むバケット名では、単一ラベルのワイルドカードが複数ラベルにまたがらないため、証明書名を明示する必要がある場合があります。 -:::warning[Configure the server domain] +:::warning[サーバードメインを設定する] -Do not send virtual-hosted-style requests unless `RUSTFS_SERVER_DOMAINS` is configured. RustFS otherwise treats requests as path-style and cannot derive the bucket from the hostname. +`RUSTFS_SERVER_DOMAINS` を設定していない限り、仮想ホスト形式のリクエストを送らないでください。未設定の場合、RustFS はリクエストをパススタイルアクセスとして扱い、ホスト名からバケットを特定できません。 ::: -### TLS and network access +### TLS とネットワークアクセス -For production, set `RUSTFS_TLS_PATH` to a directory containing `rustfs_cert.pem` and `rustfs_key.pem`, then use an `https://` endpoint. Ensure clients trust the issuing certificate authority. +本番では、`rustfs_cert.pem` と `rustfs_key.pem` を含むディレクトリを `RUSTFS_TLS_PATH` に設定し、`https://` のエンドポイントを使います。クライアントが、発行元の認証局を信頼するようにします。 -Allow the configured S3 API port through host firewalls and load balancers. The default is TCP port `9000`; this listener also carries RustFS administrative and internode traffic, so do not expose it anonymously without appropriate network and IAM controls. +設定した S3 API のポートを、ホストのファイアウォールとロードバランサーで許可します。既定は TCP ポート `9000` です。このリスナーは RustFS の管理トラフィックとノード間トラフィックも運ぶため、適切なネットワーク制御と IAM 制御がないまま、制限なく公開しないでください。 -## Usage +## 使い方 -The following examples use AWS CLI with the canonical local endpoint. Install and configure [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) before continuing. +次の例では、標準のローカルエンドポイントとともに AWS CLI を使います。続ける前に、[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) をインストールして設定します。 -### Configure AWS CLI +### AWS CLI を設定する ```bash aws configure ``` -Enter these values when prompted: +求められたら、次の値を入力します。 ```text AWS Access Key ID [None]: @@ -114,13 +114,13 @@ Default region name [None]: us-east-1 Default output format [None]: json ``` -Pass the RustFS endpoint to every command. The custom endpoint keeps these examples on RustFS instead of AWS S3. +すべてのコマンドに RustFS のエンドポイントを渡します。カスタムエンドポイントにより、これらの例は AWS S3 ではなく RustFS を対象にします。 ```bash export RUSTFS_ENDPOINT="http://localhost:9000" ``` -### Create and list buckets +### バケットを作成して一覧する ```bash aws --endpoint-url "$RUSTFS_ENDPOINT" s3api create-bucket \ @@ -129,7 +129,7 @@ aws --endpoint-url "$RUSTFS_ENDPOINT" s3api create-bucket \ aws --endpoint-url "$RUSTFS_ENDPOINT" s3api list-buckets ``` -### Upload and list objects +### オブジェクトをアップロードして一覧する ```bash printf 'Hello from RustFS\n' > hello.txt @@ -141,9 +141,9 @@ aws --endpoint-url "$RUSTFS_ENDPOINT" s3 ls \ s3://my-bucket/path/to/ ``` -AWS CLI automatically uses multipart upload when its transfer configuration selects it for a large object. RustFS supports the standard multipart create, upload-part, complete, list, and abort workflows. +AWS CLI は、転送設定が大きなオブジェクトに対してマルチパートを選んだ場合、自動的にマルチパートアップロードを使います。RustFS は、標準のマルチパートの create、upload-part、complete、list、abort の各ワークフローに対応しています。 -### Download and inspect an object +### オブジェクトをダウンロードして確認する ```bash aws --endpoint-url "$RUSTFS_ENDPOINT" s3 cp \ @@ -154,9 +154,9 @@ aws --endpoint-url "$RUSTFS_ENDPOINT" s3api head-object \ --key path/to/hello.txt ``` -### Create a presigned URL +### 署名付き URL を作成する -Generate a time-limited URL that can download an object without exposing credentials: +認証情報を公開せずにオブジェクトをダウンロードできる、有効期限付きの URL を生成します。 ```bash aws --endpoint-url "$RUSTFS_ENDPOINT" s3 presign \ @@ -164,9 +164,9 @@ aws --endpoint-url "$RUSTFS_ENDPOINT" s3 presign \ --expires-in 3600 ``` -The hostname, scheme, port, region, and object path used by the recipient must match the values used to sign the URL. Use the externally reachable endpoint when generating URLs for another machine. +受け取り側が使うホスト名、スキーム、ポート、リージョン、オブジェクトパスは、URL の署名に使った値と一致する必要があります。別のマシン向けの URL を生成するときは、外部から到達できるエンドポイントを使います。 -### Delete objects and buckets +### オブジェクトとバケットを削除する ```bash aws --endpoint-url "$RUSTFS_ENDPOINT" s3 rm \ @@ -176,25 +176,27 @@ aws --endpoint-url "$RUSTFS_ENDPOINT" s3api delete-bucket \ --bucket my-bucket ``` -An S3 bucket must be empty before it can be deleted. +S3 バケットは、削除する前に空である必要があります。 -## Known compatibility differences + -Current RustFS compatibility tests cover the common workflows described above. The following areas are not equivalent to AWS S3 or MinIO: +## 既知の互換性の違い -- Bucket access logging and bucket ownership controls are planned rather than complete. -- ACL authorization is intentionally unsupported. Canned ACL headers have partial compatibility, while XML grant policies return `NotImplemented`. Prefer IAM and bucket policies. -- POST Object form uploads are implemented, but checksum handling for that workflow is not complete. -- Some multipart upload listing and part-lookup edge cases are outside the default compatibility gate. -- S3 Select currently accepts only uncompressed input. -- Access Point and Outposts copy-source forms are not implemented. -- MinIO administrative APIs are a separate compatibility surface and should not be inferred from S3 data-plane support. +現在の RustFS の互換性テストは、上で説明した一般的なワークフローを対象としています。次の領域は、AWS S3 または MinIO と同等ではありません。 -Client behavior can also differ when a tool assumes AWS-specific services, storage classes, account ownership controls, or endpoint discovery. Always set the RustFS endpoint explicitly and test the exact operations your application uses. +- バケットアクセスログとバケット所有者コントロールは、完成した機能ではなく、未実装（予定）です。 +- ACL による認可は、意図的にサポートしていません。既定 ACL のヘッダーには部分的な互換がありますが、XML の grant ポリシーは `NotImplemented` を返します。IAM とバケットポリシーを優先することを推奨します。 +- POST Object のフォームアップロードは実装されていますが、そのワークフローのチェックサム処理は完了していません。 +- マルチパートアップロードの一覧とパート検索における一部の境界条件は、既定の互換性検証（ゲート）の対象外です。 +- S3 Select は、現時点では非圧縮の入力だけを受け付けます。 +- Access Point と Outposts のコピーソース形式は、実装されていません。 +- MinIO の管理 API は別の互換範囲であり、S3 データプレーンの対応から推測しないでください。 -## Next steps +ツールが AWS 固有のサービス、ストレージクラス、アカウントの所有権制御、エンドポイント検出を前提としている場合、クライアントの動作が異なることもあります。RustFS のエンドポイントは常に明示して設定し、アプリケーションが使う操作そのものをテストします。 -- Follow the complete [AWS CLI example](/developer/examples/aws-cli). -- Choose an [S3 SDK](/developer/sdk) for application integration. -- Configure [credentials and access policies](/operations/credentials). -- Enable [TLS](/integration/tls-configured) before exposing the endpoint outside a trusted network. +## 次のステップ + +- 一連の手順は、[AWS CLI の例](/ja/developer/examples/aws-cli)に従います。 +- アプリケーション連携には、[S3 SDK](/ja/developer/sdk)を選びます。 +- [認証情報とアクセスポリシー](/ja/operations/credentials)を設定します。 +- 信頼できるネットワークの外へエンドポイントを公開する前に、[TLS](/ja/integration/tls-configured)を有効にします。 diff --git a/content/ja/administration/protocols/sftp.md b/content/ja/administration/protocols/sftp.md index 3579364fd..986aebaf6 100644 --- a/content/ja/administration/protocols/sftp.md +++ b/content/ja/administration/protocols/sftp.md @@ -1,74 +1,74 @@ --- title: "SFTP" -description: "Build, configure, and use the RustFS SFTP gateway to access buckets and objects with SFTP clients." +description: "RustFS の SFTP ゲートウェイをビルドして設定し、SFTP クライアントでバケットとオブジェクトへアクセスする方法を説明します。" --- -RustFS includes an SSH File Transfer Protocol (SFTP) gateway that exposes buckets and objects to SFTP clients over an encrypted SSH connection. You can list and create buckets and upload, download, rename, or delete objects while RustFS enforces the permissions of the authenticated Identity and Access Management (IAM) user. +RustFS には、暗号化された SSH 接続でバケットとオブジェクトを SFTP クライアントへ公開する SSH File Transfer Protocol（SFTP）ゲートウェイが含まれます。バケットの一覧と作成、オブジェクトのアップロード、ダウンロード、名前変更、削除ができます。RustFS は、認証されたアイデンティティとアクセス管理（IAM）ユーザーの権限を各操作に適用します。 -SFTP is an optional compile-time feature and is not included in the default RustFS build. Build RustFS with the `sftp` or `full` feature before enabling the listener. The listener is disabled at runtime by default. +SFTP は任意のコンパイル時機能であり、既定の RustFS ビルドには含まれません。リスナーを有効にする前に、`sftp` または `full` 機能を付けて RustFS をビルドします。リスナーは実行時に既定で無効です。 -## Overview +## 概要 -The gateway maps SFTP paths to RustFS resources: +ゲートウェイは、SFTP のパスを RustFS のリソースへ対応付けます。 -| SFTP path | RustFS resource | +| SFTP パス | RustFS のリソース | | --- | --- | -| `/` | All buckets visible to the authenticated user | -| `/my-bucket/` | The `my-bucket` bucket | -| `/my-bucket/hello.txt` | The `hello.txt` object in `my-bucket` | -| `/my-bucket/docs/hello.txt` | The `docs/hello.txt` object in `my-bucket` | +| `/` | 認証されたユーザーから見えるすべてのバケット | +| `/my-bucket/` | `my-bucket` バケット | +| `/my-bucket/hello.txt` | `my-bucket` 内の `hello.txt` オブジェクト | +| `/my-bucket/docs/hello.txt` | `my-bucket` 内の `docs/hello.txt` オブジェクト | -Creating or removing a directory directly below `/` creates or removes a bucket. Directories below a bucket map to object key prefixes and do not exist as independent filesystem directories. +`/` の直下でディレクトリを作成または削除すると、バケットが作成または削除されます。バケットより下のディレクトリはオブジェクトキーのプレフィックスに対応し、独立したファイルシステムディレクトリとしては存在しません。 -RustFS supports the following operations through the SFTP gateway: +RustFS は、SFTP ゲートウェイ経由で次の操作に対応しています。 -| SFTP operation | RustFS operation | +| SFTP 操作 | RustFS の操作 | | --- | --- | -| List `/` | List visible buckets | -| List a bucket or prefix | List objects and prefixes | -| `mkdir` at `/` | Create a bucket | -| `put` | Upload an object | -| `get` | Download an object | -| `rename` | Copy an object and then delete the source | -| `rm` | Delete an object | -| `rmdir` at `/` | Delete an empty bucket | +| `/` の一覧 | 見えるバケットを一覧します | +| バケットまたはプレフィックスの一覧 | オブジェクトとプレフィックスを一覧します | +| `/` での `mkdir` | バケットを作成します | +| `put` | オブジェクトをアップロードします | +| `get` | オブジェクトをダウンロードします | +| `rename` | オブジェクトをコピーしたあと、ソースを削除します | +| `rm` | オブジェクトを削除します | +| `/` での `rmdir` | 空のバケットを削除します | -Enter a RustFS access key as the SFTP username and its secret key as the password. RustFS checks the IAM user's S3 policies for every operation. +SFTP のユーザー名には RustFS のアクセスキーを、パスワードにはそのシークレットキーを入力します。RustFS は、すべての操作について IAM ユーザーの S3 ポリシーを確認します。 -:::warning[Password authentication only] +:::warning[パスワード認証のみ] -The SFTP gateway does not support client public-key authentication or anonymous access. SSH host keys identify the server; they do not authenticate clients. Do not configure an `authorized_keys` file for RustFS SFTP. +SFTP ゲートウェイは、クライアントの公開鍵認証と匿名アクセスには対応していません。SSH ホストキーはサーバーを識別するものであり、クライアントを認証しません。RustFS の SFTP 向けに `authorized_keys` ファイルを設定しないでください。 ::: -## Configuration +## 設定 -### Build with SFTP support +### SFTP 対応でビルドする -Build RustFS with the SFTP feature: +SFTP 機能を付けて RustFS をビルドします。 ```bash cargo build --release --features sftp ``` -To enable all optional RustFS features, including SFTP, use `--features full` instead. Setting `RUSTFS_SFTP_ENABLE=true` has no effect in a binary built without the `sftp` feature. +SFTP を含むすべての任意機能を有効にするには、代わりに `--features full` を使います。`sftp` 機能なしでビルドしたバイナリでは、`RUSTFS_SFTP_ENABLE=true` を設定しても効果はありません。 -### SFTP variables +### SFTP の変数 -| Variable | Description | Default | +| 変数 | 説明 | 既定値 | | --- | --- | --- | -| `RUSTFS_SFTP_ENABLE` | Enables the SFTP listener. | `false` | -| `RUSTFS_SFTP_ADDRESS` | Bind address for SFTP connections. | `0.0.0.0:2222` | -| `RUSTFS_SFTP_HOST_KEY_DIR` | Directory containing at least one unencrypted SSH private host key. Required when SFTP is enabled. | Not set | -| `RUSTFS_SFTP_READ_ONLY` | Rejects operations that modify buckets or objects. | `false` | -| `RUSTFS_SFTP_IDLE_TIMEOUT` | SSH inactivity timeout in seconds. Must be greater than zero. | `600` | -| `RUSTFS_SFTP_PART_SIZE` | Multipart upload part size in bytes. | `16777216` (16 MiB) | +| `RUSTFS_SFTP_ENABLE` | SFTP リスナーを有効にします。 | `false` | +| `RUSTFS_SFTP_ADDRESS` | SFTP 接続のバインドアドレスです。 | `0.0.0.0:2222` | +| `RUSTFS_SFTP_HOST_KEY_DIR` | 暗号化されていない SSH の秘密ホストキーを 1 つ以上含むディレクトリです。SFTP を有効にする場合は必須です。 | 未設定 | +| `RUSTFS_SFTP_READ_ONLY` | バケットまたはオブジェクトを変更する操作を拒否します。 | `false` | +| `RUSTFS_SFTP_IDLE_TIMEOUT` | SSH の無操作タイムアウト（秒）です。ゼロより大きい必要があります。 | `600` | +| `RUSTFS_SFTP_PART_SIZE` | マルチパートアップロードのパートサイズ（バイト）です。 | `16777216`（16 MiB） | -The default port `2222` avoids the privileged SSH port `22`. The address can use IPv4 or IPv6 syntax, for example `127.0.0.1:2222` or `[::]:2222`. +既定のポート `2222` は、特権が必要な SSH ポート `22` を避けます。アドレスには IPv4 または IPv6 の構文を使えます。たとえば `127.0.0.1:2222` や `[::]:2222` です。 -### Prepare a host key +### ホストキーを用意する -Create a persistent host-key directory and generate an Ed25519 host key: +永続的なホストキーのディレクトリを作成し、Ed25519 のホストキーを生成します。 ```bash mkdir -p /path/to/sftp-keys @@ -78,19 +78,19 @@ ssh-keygen -t ed25519 \ chmod 600 /path/to/sftp-keys/ssh_host_ed25519_key* ``` -The host key must not use a passphrase. RustFS also accepts decodable ECDSA and RSA private host keys. +ホストキーにパスフレーズを設定してはいけません。RustFS は、復号できる ECDSA と RSA の秘密ホストキーも受け付けます。 -On Unix, every regular file in the host-key directory must be accessible only by its owner. The `ssh-keygen` command also creates a `.pub` file; either keep it with owner-only permissions as shown or remove it because RustFS does not read it. RustFS refuses to start if the directory is missing, contains no usable private key, or contains a regular file with group or other permission bits set. +Unix では、ホストキーディレクトリ内のすべての通常ファイルを、所有者だけがアクセスできるようにする必要があります。`ssh-keygen` コマンドは `.pub` ファイルも作成します。表示のとおり所有者だけの権限で残すか、削除します。RustFS はこのファイルを読みません。ディレクトリがない、使える秘密鍵がない、またはグループやその他の権限ビットが立った通常ファイルがある場合、RustFS は起動を拒否します。 -:::warning[Protect the host key] +:::warning[ホストキーを保護する] -Keep the same host key across restarts so clients can verify the server identity. Restrict access to the account that runs RustFS and back up the key securely. A changed host key causes clients to display a possible man-in-the-middle warning. +再起動をまたいで同じホストキーを維持し、クライアントがサーバーの識別情報を検証できるようにします。アクセスは RustFS を実行するアカウントに限定し、鍵を安全にバックアップします。ホストキーが変わると、クライアントは中間者攻撃の可能性があるという警告を表示します。 ::: -### Start the SFTP listener +### SFTP リスナーを起動する -The following example starts SFTP on the loopback interface for local testing: +次の例は、ローカルテスト用にループバックインターフェースで SFTP を起動します。 ```bash export RUSTFS_SFTP_ENABLE=true @@ -102,23 +102,23 @@ export RUSTFS_SECRET_KEY= rustfs /path/to/data ``` -For remote connections, bind to an appropriate network interface and allow inbound TCP traffic to the configured SFTP port. This listener is separate from the S3 API and Console listeners. +リモート接続では、適切なネットワークインターフェースにバインドし、設定した SFTP ポートへの受信 TCP トラフィックを許可します。このリスナーは、S3 API と Console のリスナーとは別です。 -## Usage +## 使い方 -The following examples use the OpenSSH `sftp` client, the canonical `my-bucket` and `hello.txt` names, and a local listener on port `2222`. +次の例では、OpenSSH の `sftp` クライアント、標準の名前である `my-bucket` と `hello.txt`、ポート `2222` のローカルリスナーを使います。 -### Connect +### 接続する ```bash sftp -P 2222 @127.0.0.1 ``` -Enter the RustFS secret key when prompted for the password. On the first connection, verify the displayed host-key fingerprint before accepting it. +パスワードを求められたら、RustFS のシークレットキーを入力します。初回接続では、表示されたホストキーのフィンガープリントを確認してから受け入れます。 -### List and create buckets +### バケットを一覧して作成する -At the `sftp` prompt, list the buckets visible to the IAM user and create `my-bucket`: +`sftp` のプロンプトで、IAM ユーザーから見えるバケットを一覧し、`my-bucket` を作成します。 ```text sftp> ls / @@ -126,11 +126,11 @@ sftp> mkdir /my-bucket sftp> cd /my-bucket ``` -Bucket names must follow the same naming rules as buckets created through the S3 API. Files cannot be created directly under `/`. +バケット名は、S3 API で作成するバケットと同じ命名規則に従う必要があります。`/` の直下にファイルを作成することはできません。 -### Upload and download an object +### オブジェクトをアップロードおよびダウンロードする -Upload `/path/to/hello.txt`, list the bucket, and download the object: +`/path/to/hello.txt` をアップロードし、バケットを一覧して、オブジェクトをダウンロードします。 ```text sftp> put /path/to/hello.txt /my-bucket/hello.txt @@ -138,44 +138,44 @@ sftp> ls /my-bucket sftp> get /my-bucket/hello.txt hello.txt ``` -Uploads must be sequential from the beginning of the file. Resume, append, in-place edits, and segmented multi-connection uploads of one object are not supported. +アップロードは、ファイルの先頭から順に行う必要があります。再開、追記、その場での編集、1 つのオブジェクトを分割した複数接続アップロードには対応していません。 -### Rename an object +### オブジェクトの名前を変更する ```text sftp> rename /my-bucket/hello.txt /my-bucket/greeting.txt ``` -RustFS implements rename as a server-side copy followed by deletion of the source. The operation is not atomic, and renaming a bucket is not supported. The IAM user needs permission to read and delete the source and to write the destination. +RustFS は名前変更を、サーバー側のコピーと、そのあとのソース削除として実装します。この操作はアトミックではなく、バケットの名前変更には対応していません。IAM ユーザーには、ソースの読み取りと削除、および宛先への書き込みの権限が必要です。 -### Delete an object and bucket +### オブジェクトとバケットを削除する -Delete the object and then remove the empty bucket: +オブジェクトを削除し、そのあと空のバケットを削除します。 ```text sftp> rm /my-bucket/greeting.txt sftp> rmdir /my-bucket ``` -RustFS does not recursively delete a non-empty bucket through SFTP. +RustFS は、SFTP 経由で空でないバケットを再帰的に削除しません。 -### Connect a desktop client +### デスクトップクライアントから接続する -Use these settings in graphical clients such as FileZilla, Cyberduck, or WinSCP: +FileZilla、Cyberduck、WinSCP などのグラフィカルクライアントでは、次の設定を使います。 -| Setting | Value | +| 設定 | 値 | | --- | --- | -| Protocol | SFTP (SSH File Transfer Protocol) | -| Host | Your RustFS SFTP hostname | -| Port | `2222`, or the port in `RUSTFS_SFTP_ADDRESS` | -| Username | RustFS access key | -| Password | RustFS secret key | -| Authentication | Password | +| プロトコル | SFTP（SSH File Transfer Protocol） | +| ホスト | 使用する RustFS の SFTP ホスト名 | +| ポート | `2222`、または `RUSTFS_SFTP_ADDRESS` のポート | +| ユーザー名 | RustFS のアクセスキー | +| パスワード | RustFS のシークレットキー | +| 認証 | パスワード | -Configure the client for whole-file, single-connection uploads. Symbolic links and POSIX ownership, permission, or timestamp changes are not supported because the gateway maps SFTP operations to object storage. +クライアントは、ファイル全体を単一接続でアップロードする設定にします。ゲートウェイは SFTP 操作をオブジェクトストレージへ対応付けるため、シンボリックリンクや、POSIX の所有者、権限、タイムスタンプの変更には対応していません。 -## Next steps +## 次のステップ -- [Manage credentials](/operations/credentials) -- [Check service status](/operations/status-check) -- [Configure lifecycle management](/administration/data/lifecycle-management) \ No newline at end of file +- [認証情報を管理する](/ja/operations/credentials) +- [サービスの状態を確認する](/ja/operations/status-check) +- [ライフサイクル管理を設定する](/ja/administration/data/lifecycle-management) diff --git a/content/ja/administration/protocols/webdav.md b/content/ja/administration/protocols/webdav.md index ab6a80ff7..f945dc45a 100644 --- a/content/ja/administration/protocols/webdav.md +++ b/content/ja/administration/protocols/webdav.md @@ -1,66 +1,66 @@ --- title: "WebDAV" -description: "Configure the RustFS WebDAV gateway and access buckets and objects with WebDAV clients." +description: "RustFS の WebDAV ゲートウェイを設定し、WebDAV クライアントでバケットとオブジェクトへアクセスする方法を説明します。" --- -RustFS includes a Web Distributed Authoring and Versioning (WebDAV) gateway that exposes buckets and objects to WebDAV clients over HTTP or HTTPS. You can browse buckets, create collections, and upload, download, rename, or delete objects while RustFS enforces the permissions of the authenticated Identity and Access Management (IAM) user. +RustFS には、HTTP または HTTPS でバケットとオブジェクトを WebDAV クライアントへ公開する Web Distributed Authoring and Versioning（WebDAV）ゲートウェイが含まれます。バケットの参照、コレクションの作成、オブジェクトのアップロード、ダウンロード、名前変更、削除ができます。RustFS は、認証されたアイデンティティとアクセス管理（IAM）ユーザーの権限を各操作に適用します。 -WebDAV support is compiled into the standard RustFS binary, but the gateway is disabled at runtime by default. You must enable and configure it before connecting a client. +WebDAV のサポートは標準の RustFS バイナリにコンパイルされていますが、ゲートウェイは実行時に既定で無効です。クライアントを接続する前に、有効にして設定する必要があります。 -## Overview +## 概要 -The gateway maps WebDAV paths to RustFS resources: +ゲートウェイは、WebDAV のパスを RustFS のリソースへ対応付けます。 -| WebDAV path | RustFS resource | +| WebDAV パス | RustFS のリソース | | --- | --- | -| `/` | All buckets visible to the authenticated user | -| `/my-bucket/` | The `my-bucket` bucket | -| `/my-bucket/hello.txt` | The `hello.txt` object in `my-bucket` | -| `/my-bucket/docs/hello.txt` | The `docs/hello.txt` object in `my-bucket` | +| `/` | 認証されたユーザーから見えるすべてのバケット | +| `/my-bucket/` | `my-bucket` バケット | +| `/my-bucket/hello.txt` | `my-bucket` 内の `hello.txt` オブジェクト | +| `/my-bucket/docs/hello.txt` | `my-bucket` 内の `docs/hello.txt` オブジェクト | -RustFS supports the following operations through the gateway: +RustFS は、ゲートウェイ経由で次の操作に対応しています。 -| Method | Operation | +| メソッド | 操作 | | --- | --- | -| `PROPFIND` | List buckets or objects and read metadata | -| `MKCOL` | Create a bucket or a directory prefix | -| `PUT` | Upload an object | -| `GET` | Download an object | -| `HEAD` | Read object metadata | -| `MOVE` | Rename or move an object or directory | -| `DELETE` | Delete an object, directory, or bucket | +| `PROPFIND` | バケットまたはオブジェクトを一覧し、メタデータを読み取ります | +| `MKCOL` | バケット、またはディレクトリのプレフィックスを作成します | +| `PUT` | オブジェクトをアップロードします | +| `GET` | オブジェクトをダウンロードします | +| `HEAD` | オブジェクトのメタデータを読み取ります | +| `MOVE` | オブジェクトまたはディレクトリの名前を変更するか、移動します | +| `DELETE` | オブジェクト、ディレクトリ、またはバケットを削除します | -Use `PROPFIND`, not `GET`, to list a collection. The current gateway returns `405 Method Not Allowed` for `GET` requests to directories. +コレクションの一覧には、`GET` ではなく `PROPFIND` を使います。現在のゲートウェイは、ディレクトリへの `GET` リクエストに対して `405 Method Not Allowed` を返します。 -WebDAV uses HTTP Basic authentication. Enter a RustFS access key as the username and its secret key as the password. The gateway authenticates the credentials against RustFS IAM and applies the user's S3 policies to each operation. +WebDAV は HTTP Basic 認証を使います。ユーザー名には RustFS のアクセスキーを、パスワードにはそのシークレットキーを入力します。ゲートウェイは認証情報を RustFS の IAM に対して認証し、各操作にそのユーザーの S3 ポリシーを適用します。 -:::warning[Protect credentials] +:::warning[認証情報を保護する] -Basic authentication does not encrypt credentials. Disable TLS only for isolated local testing. Use HTTPS for every remote or production connection. +Basic 認証は、認証情報を暗号化しません。TLS を無効にするのは、隔離したローカルテストだけにします。リモート接続と本番接続では、すべて HTTPS を使います。 ::: -## Configuration +## 設定 -Configure the gateway with environment variables before starting RustFS: +RustFS を起動する前に、環境変数でゲートウェイを設定します。 -| Variable | Description | Default | +| 変数 | 説明 | 既定値 | | --- | --- | --- | -| `RUSTFS_WEBDAV_ENABLE` | Enables the WebDAV gateway. | `false` | -| `RUSTFS_WEBDAV_ADDRESS` | Bind address for WebDAV connections. | `0.0.0.0:8080` | -| `RUSTFS_WEBDAV_TLS_ENABLED` | Enables TLS for the WebDAV listener. | `true` | -| `RUSTFS_WEBDAV_CERTS_DIR` | Certificate directory used by the RustFS TLS runtime. Required when TLS is enabled. | Not set | -| `RUSTFS_WEBDAV_MAX_BODY_SIZE` | Maximum request body size in bytes. Must be greater than zero. | `5368709120` (5 GiB) | +| `RUSTFS_WEBDAV_ENABLE` | WebDAV ゲートウェイを有効にします。 | `false` | +| `RUSTFS_WEBDAV_ADDRESS` | WebDAV 接続のバインドアドレスです。 | `0.0.0.0:8080` | +| `RUSTFS_WEBDAV_TLS_ENABLED` | WebDAV リスナーの TLS を有効にします。 | `true` | +| `RUSTFS_WEBDAV_CERTS_DIR` | RustFS の TLS ランタイムが使う証明書ディレクトリです。TLS を有効にする場合は必須です。 | 未設定 | +| `RUSTFS_WEBDAV_MAX_BODY_SIZE` | リクエスト本文の最大サイズ（バイト）です。ゼロより大きい必要があります。 | `5368709120`（5 GiB） | -The standard RustFS build enables the WebDAV compile-time feature. If you build RustFS with `--no-default-features`, include the feature explicitly: +標準の RustFS ビルドでは、WebDAV のコンパイル時機能が有効です。`--no-default-features` で RustFS をビルドする場合は、この機能を明示的に含めます。 ```bash cargo build --release --features webdav ``` -### Local testing without TLS +### TLS なしのローカルテスト -The following example starts RustFS with an HTTP WebDAV listener on port `8080`: +次の例は、ポート `8080` で HTTP の WebDAV リスナーを付けて RustFS を起動します。 ```bash export RUSTFS_WEBDAV_ENABLE=true @@ -72,11 +72,11 @@ export RUSTFS_SECRET_KEY= rustfs /path/to/data ``` -Binding to `127.0.0.1` prevents other hosts from connecting to the unencrypted test endpoint. +`127.0.0.1` にバインドすると、ほかのホストは暗号化されていないテストエンドポイントへ接続できません。 ### HTTPS -For a remote or production connection, enable TLS and provide a certificate directory: +リモート接続または本番接続では、TLS を有効にし、証明書ディレクトリを指定します。 ```bash export RUSTFS_WEBDAV_ENABLE=true @@ -87,15 +87,15 @@ export RUSTFS_WEBDAV_CERTS_DIR=/path/to/certs rustfs /path/to/data ``` -If TLS is enabled without `RUSTFS_WEBDAV_CERTS_DIR`, or the directory does not exist, WebDAV initialization fails. See [Configure TLS](/integration/tls-configured) for certificate preparation guidance. +TLS を有効にしているのに `RUSTFS_WEBDAV_CERTS_DIR` がない場合、またはディレクトリが存在しない場合、WebDAV の初期化は失敗します。証明書の準備は、[TLS を設定する](/ja/integration/tls-configured)を参照します。 -Allow inbound TCP traffic to the configured WebDAV port. This listener is separate from the S3 API and Console listeners. +設定した WebDAV ポートへの受信 TCP トラフィックを許可します。このリスナーは、S3 API と Console のリスナーとは別です。 -## Usage +## 使い方 -The following commands use an HTTP endpoint for local testing. Replace the endpoint and credentials with your HTTPS WebDAV endpoint and an IAM user that has the required bucket and object permissions. +次のコマンドは、ローカルテスト用の HTTP エンドポイントを使います。エンドポイントと認証情報は、自分の HTTPS WebDAV エンドポイントと、必要なバケットおよびオブジェクトの権限を持つ IAM ユーザーに置き換えます。 -Set reusable shell variables without placing the secret directly in each command: +シークレットを各コマンドへ直接書かずに、再利用できるシェル変数を設定します。 ```bash export WEBDAV_URL=http://127.0.0.1:8080 @@ -104,9 +104,9 @@ read -s WEBDAV_PASSWORD export WEBDAV_PASSWORD ``` -### List buckets +### バケットを一覧する -Send `PROPFIND` with `Depth: 1` to list the buckets visible to the user: +ユーザーから見えるバケットを一覧するには、`Depth: 1` を付けた `PROPFIND` を送ります。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -115,7 +115,7 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/" ``` -### Create a bucket +### バケットを作成する ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -123,11 +123,11 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/" ``` -Bucket names must follow the same naming rules as buckets created through the S3 API. +バケット名は、S3 API で作成するバケットと同じ命名規則に従う必要があります。 -### Upload and download an object +### オブジェクトをアップロードおよびダウンロードする -Upload `/path/to/hello.txt`: +`/path/to/hello.txt` をアップロードします。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -135,7 +135,7 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/hello.txt" ``` -Download the object: +オブジェクトをダウンロードします。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -143,9 +143,9 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/hello.txt" ``` -### Create and list a directory +### ディレクトリを作成して一覧する -WebDAV directories below a bucket map to object key prefixes: +バケットより下の WebDAV ディレクトリは、オブジェクトキーのプレフィックスに対応します。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -158,9 +158,9 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/docs/" ``` -### Rename an object +### オブジェクトの名前を変更する -Use `MOVE` with a destination path on the same WebDAV endpoint: +同じ WebDAV エンドポイント上の宛先パスを指定して、`MOVE` を使います。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -169,11 +169,11 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/hello.txt" ``` -The IAM user needs permission to read and delete the source and to write the destination. If authorization fails, RustFS leaves the source unchanged. +IAM ユーザーには、ソースの読み取りと削除、および宛先への書き込みの権限が必要です。認可に失敗した場合、RustFS はソースを変更せずに残します。 -### Delete an object or bucket +### オブジェクトまたはバケットを削除する -Delete an object: +オブジェクトを削除します。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -181,7 +181,7 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/greeting.txt" ``` -Delete the bucket after removing its contents: +内容を削除したあと、バケットを削除します。 ```bash curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ @@ -189,20 +189,20 @@ curl --user "$WEBDAV_USER:$WEBDAV_PASSWORD" \ "$WEBDAV_URL/my-bucket/" ``` -### Connect a desktop client +### デスクトップクライアントから接続する -Use the WebDAV endpoint in a client that supports Basic authentication: +Basic 認証に対応したクライアントで、WebDAV エンドポイントを使います。 -| Client | Connection address | +| クライアント | 接続アドレス | | --- | --- | -| GNOME Files | `dav://:8080/` for HTTP or `davs://:8080/` for HTTPS | -| macOS Finder | `http://:8080/` or `https://:8080/` | +| GNOME Files | HTTP は `dav://:8080/`、HTTPS は `davs://:8080/` | +| macOS Finder | `http://:8080/` または `https://:8080/` | | Windows File Explorer | `https://:8080/` | -Enter the RustFS access key and secret key when the client prompts for credentials. Client behavior and supported WebDAV methods vary; use `curl` to isolate server-side errors when troubleshooting. +クライアントが認証情報を求めたら、RustFS のアクセスキーとシークレットキーを入力します。クライアントの動作と、対応する WebDAV メソッドは製品によって異なります。トラブルシューティングでサーバー側のエラーを切り分けるときは、`curl` を使います。 -## Next steps +## 次のステップ -- [Manage credentials](/operations/credentials) -- [Configure TLS](/integration/tls-configured) -- [Check service status](/operations/status-check) \ No newline at end of file +- [認証情報を管理する](/ja/operations/credentials) +- [TLS を設定する](/ja/integration/tls-configured) +- [サービスの状態を確認する](/ja/operations/status-check) diff --git a/content/ja/developer/examples/aws-cli.md b/content/ja/developer/examples/aws-cli.md index 2e7dad35b..cac06cf03 100644 --- a/content/ja/developer/examples/aws-cli.md +++ b/content/ja/developer/examples/aws-cli.md @@ -1,21 +1,21 @@ --- title: "AWS CLI" -description: "Connect the AWS CLI to RustFS and perform basic object operations." +description: "AWS CLI を RustFS に接続し、基本的なオブジェクト操作を行います。" --- -The [AWS CLI](https://docs.aws.amazon.com/cli/) is Amazon's official command-line tool for S3, and it works with RustFS via the `--endpoint-url` flag. +[AWS CLI](https://docs.aws.amazon.com/cli/) は、S3 向けの Amazon 公式コマンドラインツールです。`--endpoint-url` フラグを指定すると、RustFS でも動作します。 -## Install +## インストール -Follow the [official install guide](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), or on macOS: +[公式のインストールガイド](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)に従うか、macOS では次を実行します。 ```bash brew install awscli ``` -## Configure +## 設定 -Set your [access keys](../../security-compliance/iam/access-token.md) and region: +[アクセスキー](../../security-compliance/iam/access-token.md)とリージョンを設定します。 ```bash aws configure @@ -28,17 +28,17 @@ Default region name [None]: us-east-1 Default output format [None]: json ``` -Pass your RustFS address with `--endpoint-url` on every command. Replace `http://localhost:9000` with your server address. When `--endpoint-url` is set, the AWS CLI uses path-style addressing, which is what RustFS requires. +すべてのコマンドで、`--endpoint-url` に RustFS のアドレスを渡します。`http://localhost:9000` は、実際のサーバーアドレスに置き換えます。`--endpoint-url` を指定すると、AWS CLI はパススタイルアクセスを使います。RustFS では、このパススタイルアクセスが必要です。 :::note -If you did not set credentials at install, the local-test default is `rustfsadmin` / `rustfsadmin` — never use it beyond a throwaway local trial. +インストール時に認証情報を設定していない場合、ローカル試験用の既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル試用以外では使わないでください。 ::: -## Verify +## 検証 -Create a bucket: +バケットを作成します。 ```bash aws s3 mb s3://my-bucket --endpoint-url http://localhost:9000 @@ -48,7 +48,7 @@ aws s3 mb s3://my-bucket --endpoint-url http://localhost:9000 make_bucket: my-bucket ``` -Upload a file: +ファイルをアップロードします。 ```bash aws s3 cp /path/to/hello.txt s3://my-bucket/ --endpoint-url http://localhost:9000 @@ -58,7 +58,7 @@ aws s3 cp /path/to/hello.txt s3://my-bucket/ --endpoint-url http://localhost:900 upload: ../path/to/hello.txt to s3://my-bucket/hello.txt ``` -List the bucket: +バケットの内容を一覧表示します。 ```bash aws s3 ls s3://my-bucket --endpoint-url http://localhost:9000 @@ -68,6 +68,6 @@ aws s3 ls s3://my-bucket --endpoint-url http://localhost:9000 2026-07-15 10:30:00 12 hello.txt ``` -## Next steps +## 次のステップ -Build applications against RustFS with an [S3 SDK](../sdk/index.md), or manage objects with [`rc`](/operations/rc). +[S3 SDK](../sdk/index.md) を使って RustFS 向けのアプリケーションを作成するか、[`rc`](/ja/operations/rc) でオブジェクトを管理します。 diff --git a/content/ja/developer/examples/aws-sdk-go.md b/content/ja/developer/examples/aws-sdk-go.md index 70958b90c..640223666 100644 --- a/content/ja/developer/examples/aws-sdk-go.md +++ b/content/ja/developer/examples/aws-sdk-go.md @@ -1,11 +1,11 @@ --- title: "AWS SDK for Go" -description: "Connect the AWS SDK for Go v2 to RustFS and perform basic object operations." +description: "AWS SDK for Go v2 を RustFS に接続し、基本的なオブジェクト操作を行います。" --- -The [AWS SDK for Go v2](https://aws.github.io/aws-sdk-go-v2/docs/) connects to RustFS through a custom base endpoint. This is the minimal connection recipe; see the [Go SDK guide](../sdk/go.md) for a full program. +[AWS SDK for Go v2](https://aws.github.io/aws-sdk-go-v2/docs/) は、カスタムのベースエンドポイントを通じて RustFS に接続します。これは接続に必要な最小限の手順です。完全なプログラムについては、[Go SDK ガイド](../sdk/go.md)を参照します。 -## Install +## インストール ```bash go get github.com/aws/aws-sdk-go-v2/aws @@ -13,9 +13,9 @@ go get github.com/aws/aws-sdk-go-v2/credentials go get github.com/aws/aws-sdk-go-v2/service/s3 ``` -## Configure +## 設定 -Replace `http://localhost:9000` with your server address and use your own [access keys](../../security-compliance/iam/access-token.md). RustFS requires path-style addressing (`UsePathStyle: true`): +`http://localhost:9000` を実際のサーバーアドレスに置き換え、独自の[アクセスキー](../../security-compliance/iam/access-token.md)を使います。RustFS ではパススタイルアクセス（`UsePathStyle: true`）が必要です。 ```go {9,11} import ( @@ -34,7 +34,7 @@ client := s3.NewFromConfig(cfg, func(o *s3.Options) { }) ``` -## Verify +## 検証 ```go ctx := context.Background() @@ -50,6 +50,6 @@ for _, b := range out.Buckets { my-bucket ``` -## Next steps +## 次のステップ -See the full [Go SDK guide](../sdk/go.md), or manage objects with [`rc`](/operations/rc). +完全な [Go SDK ガイド](../sdk/go.md)を参照するか、[`rc`](/ja/operations/rc) でオブジェクトを管理します。 diff --git a/content/ja/developer/examples/aws-sdk-js.md b/content/ja/developer/examples/aws-sdk-js.md index 408757a10..49ab99641 100644 --- a/content/ja/developer/examples/aws-sdk-js.md +++ b/content/ja/developer/examples/aws-sdk-js.md @@ -1,19 +1,19 @@ --- title: "AWS SDK for JavaScript" -description: "Connect the AWS SDK for JavaScript v3 to RustFS and perform basic object operations from Node.js." +description: "AWS SDK for JavaScript v3 を RustFS に接続し、Node.js から基本的なオブジェクト操作を行います。" --- -The [AWS SDK for JavaScript v3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/) connects to RustFS through a custom endpoint. This is the minimal connection recipe; see the [JavaScript SDK guide](../sdk/javascript.md) for a full program. +[AWS SDK for JavaScript v3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/) は、カスタムエンドポイントを通じて RustFS に接続します。これは接続に必要な最小限の手順です。完全なプログラムについては、[JavaScript SDK ガイド](../sdk/javascript.md)を参照します。 -## Install +## インストール ```bash npm install @aws-sdk/client-s3 ``` -## Configure +## 設定 -Replace `http://localhost:9000` with your server address and use your own [access keys](../../security-compliance/iam/access-token.md). RustFS requires path-style addressing (`forcePathStyle: true`): +`http://localhost:9000` を実際のサーバーアドレスに置き換え、独自の[アクセスキー](../../security-compliance/iam/access-token.md)を使います。RustFS ではパススタイルアクセス（`forcePathStyle: true`）が必要です。 ```javascript title="index.mjs" {8} import { S3Client, CreateBucketCommand, PutObjectCommand, ListObjectsV2Command } from "@aws-sdk/client-s3"; @@ -27,7 +27,7 @@ const s3 = new S3Client({ }); ``` -## Verify +## 検証 ```javascript await s3.send(new CreateBucketCommand({ Bucket: "my-bucket" })); @@ -41,6 +41,6 @@ for (const obj of out.Contents ?? []) console.log(obj.Key, obj.Size); hello.txt 12 ``` -## Next steps +## 次のステップ -See the full [JavaScript SDK guide](../sdk/javascript.md), or manage objects with [`rc`](/operations/rc). +完全な [JavaScript SDK ガイド](../sdk/javascript.md)を参照するか、[`rc`](/ja/operations/rc) でオブジェクトを管理します。 diff --git a/content/ja/developer/examples/boto3.md b/content/ja/developer/examples/boto3.md index 99b812712..084e8f2ea 100644 --- a/content/ja/developer/examples/boto3.md +++ b/content/ja/developer/examples/boto3.md @@ -1,19 +1,19 @@ --- -title: "boto3 (Python)" -description: "Connect boto3 to RustFS and perform basic object operations from Python." +title: "boto3（Python）" +description: "boto3 を RustFS に接続し、Python から基本的なオブジェクト操作を行います。" --- -[boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) is the AWS SDK for Python and connects to RustFS through a custom endpoint. +[boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) は Python 向けの AWS SDK であり、カスタムエンドポイントを通じて RustFS に接続します。 -## Install +## インストール ```bash pip install boto3 ``` -## Configure +## 設定 -Point the client at your RustFS endpoint. Replace `http://localhost:9000` with your server address, and use your own [access keys](../../security-compliance/iam/access-token.md). RustFS requires path-style addressing, set via botocore `Config`: +クライアントを RustFS のエンドポイントに向けます。`http://localhost:9000` を実際のサーバーアドレスに置き換え、独自の[アクセスキー](../../security-compliance/iam/access-token.md)を使います。RustFS ではパススタイルアクセスが必要です。botocore の `Config` で設定します。 ```python import boto3 @@ -29,9 +29,9 @@ s3 = boto3.client( ) ``` -## Verify +## 検証 -Create a bucket, upload a file, and list the bucket: +バケットを作成し、ファイルをアップロードして、バケットを一覧表示します。 ```python s3.create_bucket(Bucket="my-bucket") @@ -42,12 +42,12 @@ for obj in s3.list_objects_v2(Bucket="my-bucket").get("Contents", []): print(obj["Key"], obj["Size"]) ``` -Expected output: +予想される出力は次のとおりです。 ```text hello.txt 12 ``` -## Next steps +## 次のステップ -See the [S3 SDK overview](../sdk/index.md) for more languages, or manage objects with [`rc`](/operations/rc). If you prefer a community-driven SDK with native async support and full typing, see [capo (Python)](../integration/others/capo.md). +他の言語については [S3 SDK の概要](../sdk/index.md)を参照するか、[`rc`](/ja/operations/rc) でオブジェクトを管理します。ネイティブの非同期処理と完全な型付けを備えた、コミュニティ主導の SDK を使う場合は、[capo（Python）](../integration/others/capo.md)を参照します。 diff --git a/content/ja/developer/examples/rclone.md b/content/ja/developer/examples/rclone.md index b93bedbf9..b900c9f1f 100644 --- a/content/ja/developer/examples/rclone.md +++ b/content/ja/developer/examples/rclone.md @@ -1,21 +1,21 @@ --- title: "rclone" -description: "Connect rclone to RustFS and perform basic object operations." +description: "rclone を RustFS に接続し、基本的なオブジェクト操作を行います。" --- -[rclone](https://rclone.org/) is a command-line program for syncing files with cloud storage and speaks the S3 protocol that RustFS implements. +[rclone](https://rclone.org/) は、クラウドストレージとの間でファイルを同期するコマンドラインプログラムです。RustFS が実装する S3 プロトコルで通信します。 -## Install +## インストール ```bash curl https://rclone.org/install.sh | sudo bash ``` -Or see the [official install guide](https://rclone.org/install/). +または、[公式のインストールガイド](https://rclone.org/install/)を参照します。 -## Configure +## 設定 -Add a remote to `~/.config/rclone/rclone.conf`. Replace `http://localhost:9000` with your server address, and use your own [access keys](../../security-compliance/iam/access-token.md). `force_path_style = true` is required because RustFS uses path-style addressing: +`~/.config/rclone/rclone.conf` にリモートを追加します。`http://localhost:9000` を実際のサーバーアドレスに置き換え、独自の[アクセスキー](../../security-compliance/iam/access-token.md)を使います。RustFS はパススタイルアクセスを使うため、`force_path_style = true` が必要です。 ```ini title="~/.config/rclone/rclone.conf" [rustfs] @@ -28,21 +28,21 @@ region = us-east-1 force_path_style = true ``` -## Verify +## 検証 -Create a bucket: +バケットを作成します。 ```bash rclone mkdir rustfs:my-bucket ``` -Upload a file: +ファイルをアップロードします。 ```bash rclone copy /path/to/hello.txt rustfs:my-bucket ``` -List buckets and contents: +バケットと内容を一覧表示します。 ```bash rclone lsd rustfs: @@ -54,6 +54,6 @@ rclone ls rustfs:my-bucket 12 hello.txt ``` -## Next steps +## 次のステップ -Build applications against RustFS with an [S3 SDK](../sdk/index.md), or manage objects with [`rc`](/operations/rc). +[S3 SDK](../sdk/index.md) を使って RustFS 向けのアプリケーションを作成するか、[`rc`](/ja/operations/rc) でオブジェクトを管理します。 diff --git a/content/ja/developer/examples/s3cmd.md b/content/ja/developer/examples/s3cmd.md index 16fbf31c0..e6e5ea407 100644 --- a/content/ja/developer/examples/s3cmd.md +++ b/content/ja/developer/examples/s3cmd.md @@ -1,11 +1,11 @@ --- title: "s3cmd" -description: "Connect s3cmd to RustFS and perform basic object operations from the command line." +description: "s3cmd を RustFS に接続し、コマンドラインから基本的なオブジェクト操作を行います。" --- -[s3cmd](https://s3tools.org/s3cmd) is a command-line client for S3-compatible storage. Point it at your RustFS endpoint with a small config file. +[s3cmd](https://s3tools.org/s3cmd) は、S3 互換ストレージ向けのコマンドラインクライアントです。小さな設定ファイルで、RustFS のエンドポイントを指定します。 -## Install +## インストール ```bash # macOS @@ -16,9 +16,9 @@ sudo apt install s3cmd pip install s3cmd ``` -## Configure +## 設定 -Create `~/.s3cfg`. Replace `localhost:9000` with your server address and use your own [access keys](../../security-compliance/iam/access-token.md). RustFS uses path-style addressing, so set the bucket host to the same endpoint: +`~/.s3cfg` を作成します。`localhost:9000` を実際のサーバーアドレスに置き換え、独自の[アクセスキー](../../security-compliance/iam/access-token.md)を使います。RustFS はパススタイルアクセスを使うため、バケットのホストを同じエンドポイントに設定します。 ```ini title="~/.s3cfg" [default] @@ -32,13 +32,13 @@ signature_v2 = False :::note -Set `use_https = True` and point at port `9000` if you have [configured TLS](../../integration/tls-configured.md). +[TLS を設定している](../../integration/tls-configured.md)場合は、`use_https = True` にし、ポート `9000` を指定します。 ::: -## Verify +## 検証 -Create a bucket, upload a file, and list it: +バケットを作成し、ファイルをアップロードして、一覧表示します。 ```bash s3cmd mb s3://my-bucket @@ -51,6 +51,6 @@ upload: '/path/to/hello.txt' -> 's3://my-bucket/hello.txt' [1 of 1] 2026-07-16 10:00 12 s3://my-bucket/hello.txt ``` -## Next steps +## 次のステップ -See the [SDK overview](../sdk/index.md) to connect an application, or manage objects with [`rc`](/operations/rc). +アプリケーションを接続するには [SDK の概要](../sdk/index.md)を参照するか、[`rc`](/ja/operations/rc) でオブジェクトを管理します。 diff --git a/content/ja/developer/examples/terraform.md b/content/ja/developer/examples/terraform.md index 08b7ea2d1..9a017c798 100644 --- a/content/ja/developer/examples/terraform.md +++ b/content/ja/developer/examples/terraform.md @@ -1,13 +1,13 @@ --- title: "Terraform" -description: "Manage RustFS buckets and objects with Terraform using the AWS provider pointed at a custom endpoint." +description: "カスタムエンドポイントを指定した AWS プロバイダーを使い、Terraform で RustFS のバケットとオブジェクトを管理します。" --- -The [Terraform AWS provider](https://registry.terraform.io/providers/hashicorp/aws/latest) works against RustFS when you point its S3 endpoint at your server and enable path-style addressing. +[Terraform の AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest)は、S3 エンドポイントをサーバーに向け、パススタイルアクセスを有効にすると、RustFS に対して動作します。 -## Configure +## 設定 -Replace `http://localhost:9000` with your server address and use your own [access keys](../../security-compliance/iam/access-token.md). The skip flags stop the provider from calling AWS-only metadata and STS endpoints: +`http://localhost:9000` を実際のサーバーアドレスに置き換え、独自の[アクセスキー](../../security-compliance/iam/access-token.md)を使います。skip フラグにより、プロバイダーは AWS 専用のメタデータエンドポイントと STS エンドポイントを呼び出しません。 ```hcl title="main.tf" provider "aws" { @@ -35,7 +35,7 @@ resource "aws_s3_object" "hello" { } ``` -## Apply +## 適用 ```bash terraform init @@ -51,6 +51,6 @@ aws_s3_object.hello: Creation complete after 0s [id=hello.txt] Apply complete! Resources: 2 added, 0 changed, 0 destroyed. ``` -## Next steps +## 次のステップ -See the [SDK overview](../sdk/index.md) to connect an application, or the [AWS CLI example](aws-cli.md) for ad-hoc commands. +アプリケーションを接続するには [SDK の概要](../sdk/index.md)を参照するか、都度実行するコマンドについては [AWS CLI の例](aws-cli.md)を参照します。 diff --git a/content/ja/developer/index.md b/content/ja/developer/index.md index 5141f84f2..adb09d92a 100644 --- a/content/ja/developer/index.md +++ b/content/ja/developer/index.md @@ -1,12 +1,12 @@ --- -title: Developer -description: "Integrate applications with RustFS by using STS, MCP, SDKs, and the S3-compatible API." +title: 開発者向け +description: "STS、MCP、SDK、および S3 互換 API を使って、アプリケーションを RustFS と連携します。" --- -Use this section to integrate applications with RustFS through temporary credentials, the Model Context Protocol (MCP), SDKs, and the S3-compatible API. +一時認証情報、Model Context Protocol（MCP）、SDK、および S3 互換 API を通じてアプリケーションを RustFS と連携するには、このセクションを使います。 -- [Security Token Service (STS)](/security-compliance/iam/sts) explains how to request temporary credentials. -- [MCP](/developer/mcp) connects AI tools and agents to RustFS. -- [SDKs](/developer/sdk) provide language-specific integration examples. -- [Integration guides](/developer/integration) cover proxies and data platforms. -- [S3 API](/administration/protocols/s3) documents client configuration and compatibility considerations. +- [セキュリティトークンサービス（STS）](/ja/security-compliance/iam/sts) では、一時認証情報を要求する方法を説明します。 +- [MCP](/ja/developer/mcp) では、AI ツールとエージェントを RustFS に接続します。 +- [SDK](/ja/developer/sdk) では、言語ごとの連携例を示します。 +- [連携ガイド](/ja/developer/integration) では、プロキシとデータ基盤を扱います。 +- [S3 API](/ja/administration/protocols/s3) では、クライアントの設定と、互換性に関する考慮事項を説明します。 diff --git a/content/ja/developer/integration/ai/mlflow.md b/content/ja/developer/integration/ai/mlflow.md index 46d3205ef..7a44e3f81 100644 --- a/content/ja/developer/integration/ai/mlflow.md +++ b/content/ja/developer/integration/ai/mlflow.md @@ -1,13 +1,13 @@ --- title: "MLflow" -description: "Run MLflow with RustFS as the S3 artifact store for experiment tracking, deployed with Docker Compose." +description: "実験追跡の S3 アーティファクトストアとして RustFS を使い、Docker Compose で MLflow をデプロイします。" --- -This guide connects [MLflow](https://github.com/mlflow/mlflow) — the experiment tracking and model registry platform — to **RustFS** as its S3 artifact store. You will start the MLflow tracking server with Docker Compose, log parameters, metrics, and artifacts from a training run, and verify that the artifacts are stored in RustFS. The workflow was verified with `ghcr.io/mlflow/mlflow:v2.22.1` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、実験追跡とモデルレジストリのプラットフォームである [MLflow](https://github.com/mlflow/mlflow) を、S3 アーティファクトストアとして **RustFS** に接続します。Docker Compose で MLflow のトラッキングサーバーを起動し、トレーニング実行からパラメーター、メトリクス、アーティファクトを記録し、アーティファクトが RustFS に保存されることを確認します。この流れは `ghcr.io/mlflow/mlflow:v2.22.1` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker with the Compose plugin. This deployment is intended for local integration testing, not production. +Docker と Compose プラグインが必要です。このデプロイはローカルでの統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,18 +16,18 @@ flowchart LR Server -->|"metadata"| DB["SQLite"] ``` -The tracking server keeps experiment and run metadata in SQLite and stores artifacts — model files, plots, reports — directly in RustFS through the `s3://` artifact root. The client needs the same RustFS credentials because it uploads artifacts itself, using boto3 and the `MLFLOW_S3_ENDPOINT_URL` setting. +トラッキングサーバーは、実験とランのメタデータを SQLite に保持し、モデルファイル、プロット、レポートなどのアーティファクトを `s3://` のアーティファクトルート経由で RustFS に直接保存します。クライアント自身が boto3 と `MLFLOW_S3_ENDPOINT_URL` の設定でアーティファクトをアップロードするため、同じ RustFS 認証情報がクライアントにも必要です。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create a working directory: +作業ディレクトリを作成します。 ```bash mkdir rustfs-mlflow cd rustfs-mlflow ``` -Create an environment file and replace both credential placeholders: +環境変数ファイルを作成し、両方の認証情報プレースホルダーを置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= @@ -35,9 +35,9 @@ RUSTFS_SECRET_KEY= MLFLOW_BUCKET=my-bucket ``` -Use dedicated credentials for the artifact bucket. Do not commit `.env` to source control. +アーティファクトバケットには専用の認証情報を使います。`.env` をバージョン管理にコミットしないでください。 -Create the Compose file: +Compose ファイルを作成します。 ```yaml title="compose.yaml" services: @@ -117,34 +117,34 @@ volumes: mlflow-db: ``` -The `create-bucket` service must run before the server starts because MLflow does not create the bucket. `MLFLOW_S3_ENDPOINT_URL` points the server's boto3 client at RustFS with path-style addressing. The SQLite database lives on a volume so experiment metadata survives restarts; production deployments should use a managed database backend instead. +MLflow はバケットを作成しないため、`create-bucket` サービスはサーバー起動前に実行する必要があります。`MLFLOW_S3_ENDPOINT_URL` は、パススタイルアクセスでサーバーの boto3 クライアントを RustFS に向けます。SQLite データベースはボリューム上にあるため、再起動後も実験メタデータが残ります。本番デプロイでは、マネージドなデータベースのバックエンドを使うことを推奨します。 -## 2. Validate and start the deployment +## 2. デプロイを検証して起動する -Resolve the Compose file before starting containers: +コンテナを起動する前に、Compose ファイルを解決します。 ```bash docker compose config ``` -Start the services and wait for the tracking server: +サービスを起動し、トラッキングサーバーを待ちます。 ```bash docker compose up -d docker compose ps ``` -The `create-bucket` service should exit with code `0`, and the MLflow UI should answer on `http://localhost:5000`: +`create-bucket` サービスは終了コード `0` で終わり、MLflow UI は `http://localhost:5000` で応答します。 ```bash curl -sf http://localhost:5000/ >/dev/null && echo ready ``` -Open the RustFS Console at `http://localhost:9001` to watch artifacts land in `my-bucket` during the next step. +このあとアーティファクトが `my-bucket` に届く様子を見るため、`http://localhost:9001` の RustFS Console を開きます。 -## 3. Log a training run +## 3. トレーニング実行を記録する -Create the client script — it runs inside the MLflow image, which ships every dependency: +クライアントスクリプトを作成します。依存関係がすべて同梱された MLflow イメージの中で実行します。 ```bash title="train_demo.py" {12} import mlflow @@ -163,18 +163,18 @@ with mlflow.start_run(run_name="rustfs-verify") as run: print("artifact_uri:", run.info.artifact_uri) ``` -Copy the script into the running container and execute it with the service environment: +スクリプトを実行中のコンテナへコピーし、サービスの環境で実行します。 ```bash docker compose cp train_demo.py mlflow:/tmp/train_demo.py docker compose exec -w /tmp mlflow python train_demo.py ``` -The `artifact_uri` prints as `s3://my-bucket/mlflow-artifacts///artifacts` — the artifact is uploaded straight to RustFS by the client. +`artifact_uri` は `s3://my-bucket/mlflow-artifacts///artifacts` と表示されます。アーティファクトはクライアントから RustFS へ直接アップロードされます。 -## 4. Verify artifacts in RustFS +## 4. RustFS でアーティファクトを確認する -Read the artifact back through the tracking server, then list the same object in RustFS. Save the following as `verify.py`, replace `` with the identifier printed in step 3, and run it the same way: +トラッキングサーバー経由でアーティファクトを読み戻し、同じオブジェクトを RustFS で一覧表示します。次の内容を `verify.py` として保存し、`` を手順 3 で表示された識別子に置き換え、同じ方法で実行します。 ```bash title="verify.py" {5} import mlflow @@ -186,59 +186,59 @@ path = client.download_artifacts("", "reports/model-summary.txt") print(open(path).read()) ``` -The download reads the object from RustFS through the tracking server. Then confirm the objects in the bucket: +ダウンロードはトラッキングサーバー経由で RustFS からオブジェクトを読み取ります。続いてバケット内のオブジェクトを確認します。 ```bash docker compose exec rustfs /usr/bin/rc ls local/my-bucket/mlflow-artifacts/ -r ``` -The output should include the artifact object: +出力にはアーティファクトのオブジェクトが含まれます。 ```text mlflow-artifacts/1/a1aece9243504f2680a52fba0c32765f/artifacts/reports/model-summary.txt ``` -![MLflow artifacts stored in the RustFS Console](./images/rustfs-mlflow-artifacts.png) +![RustFS Console に保存された MLflow のアーティファクト](./images/rustfs-mlflow-artifacts.png) -Runs, parameters, and metrics survive a server restart because they are stored in SQLite, while the artifacts stay in RustFS: +ラン、パラメーター、メトリクスは SQLite に保存されるためサーバーを再起動しても残り、アーティファクトは RustFS に残ります。 ```bash docker compose restart mlflow docker compose exec -w /tmp mlflow python verify.py ``` -The `list_artifacts` call succeeds again against the restarted server, reading from the same objects in RustFS. +再起動したサーバーに対して `list_artifacts` が再び成功し、RustFS 内の同じオブジェクトを読み取ります。 -## 5. Stop or reset the deployment +## 5. デプロイを停止またはリセットする -Stop the containers while keeping all data: +すべてのデータを残したままコンテナを停止します。 ```bash docker compose down ``` -The RustFS volume keeps the artifact objects and the MLflow volume keeps the metadata database. To delete everything, including the artifacts in RustFS, add `--volumes`. +RustFS のボリュームがアーティファクトオブジェクトを、MLflow のボリュームがメタデータデータベースを保持します。RustFS 内のアーティファクトを含むすべてを削除するには、`--volumes` を付けます。 -## Troubleshooting +## トラブルシューティング -### `ModuleNotFoundError: No module named 'boto3'` when logging artifacts +### アーティファクト記録時の `ModuleNotFoundError: No module named 'boto3'` -The client performing `log_artifact` needs boto3 because it uploads directly to S3. Install it in the environment that runs the training script, or run the script inside the MLflow image as shown in step 3. +`log_artifact` を実行するクライアントは S3 へ直接アップロードするため、boto3 が必要です。トレーニングスクリプトを実行する環境へインストールするか、手順 3 のとおり MLflow イメージ内でスクリプトを実行します。 -### `AccessDenied` or connection errors during artifact upload +### アーティファクトのアップロード時の `AccessDenied` または接続エラー -Confirm that `MLFLOW_S3_ENDPOINT_URL` is set in the client environment — without it, boto3 sends requests to real AWS S3. The endpoint must be reachable from the machine running the training script; use `http://localhost:9000` outside the Compose network and `http://rustfs:9000` inside it. +クライアント環境に `MLFLOW_S3_ENDPOINT_URL` が設定されていることを確認します。未設定の場合、boto3 は実際の AWS S3 へリクエストを送ります。エンドポイントは、トレーニングスクリプトを実行するマシンから到達できる必要があります。Compose ネットワークの外では `http://localhost:9000` 、中では `http://rustfs:9000` を使います。 -### The server fails to start with a bucket error +### バケットエラーでサーバーが起動しない -The artifact bucket must exist before the server starts. Check the `create-bucket` service logs: +アーティファクトバケットは、サーバー起動前に存在する必要があります。`create-bucket` サービスのログを確認します。 ```bash docker compose logs create-bucket ``` -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional MLflow operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [MLflow documentation](https://mlflow.org/docs/latest/) to add a model registry or move the metadata store to a managed database. +- 追加の MLflow 操作を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [MLflow ドキュメント](https://mlflow.org/docs/latest/)に従い、モデルレジストリを追加するか、メタデータストアをマネージドデータベースへ移します。 diff --git a/content/ja/developer/integration/ai/ray.md b/content/ja/developer/integration/ai/ray.md index e9f71b94c..6ff660b69 100644 --- a/content/ja/developer/integration/ai/ray.md +++ b/content/ja/developer/integration/ai/ray.md @@ -1,13 +1,13 @@ --- title: "Ray" -description: "Use Ray Data with RustFS as S3-compatible storage for dataset writes and reads." +description: "データセットの書き込みと読み取りに、S3 互換ストレージとして RustFS を Ray Data で使用します。" --- -This guide connects [Ray](https://github.com/ray-project/ray) — the distributed AI and Python compute framework — to **RustFS** through Ray Data's S3 filesystem support. You will run a Ray job inside the official image, write a dataset as Parquet to a RustFS bucket, read it back, and verify the objects. The workflow was verified with `rayproject/ray:2.44.0-py311` (Ray 2.44, pyarrow filesystem) and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、分散 AI および Python コンピュートのフレームワークである [Ray](https://github.com/ray-project/ray) を、Ray Data の S3 ファイルシステムサポートを通じて **RustFS** に接続します。公式イメージ内で Ray ジョブを実行し、データセットを Parquet として RustFS のバケットへ書き込み、読み戻してオブジェクトを確認します。この流れは `rayproject/ray:2.44.0-py311`（Ray 2.44、pyarrow のファイルシステム）と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR DS -->|"Parquet files"| RustFS["RustFS :9000"] ``` -Ray Data reads and writes datasets through pyarrow's `S3FileSystem`. Passing an `S3FileSystem` configured for RustFS redirects every dataset operation — Parquet, CSV, JSON — to the bucket. +Ray Data は pyarrow の `S3FileSystem` を通じてデータセットを読み書きします。RustFS 向けに構成した `S3FileSystem` を渡すと、Parquet、CSV、JSON を含むすべてのデータセット操作がバケットへ向きます。 -## 1. Create the job file +## 1. ジョブファイルを作成する -Create the script, replacing all connection placeholders: +接続用のプレースホルダーをすべて置き換えて、スクリプトを作成します。 ```python title="ray_s3.py" import ray @@ -45,11 +45,11 @@ print("sample:", back[0]) ray.shutdown() ``` -`endpoint_override` takes the full endpoint URL including the scheme. pyarrow's `S3FileSystem` uses path-style requests for custom endpoints, so no extra flag is needed. The same filesystem object works for `write_csv`, `read_json`, and the other Ray Data methods. +`endpoint_override` には、スキームを含む完全なエンドポイント URL を指定します。pyarrow の `S3FileSystem` はカスタムエンドポイントに対してパススタイルアクセスのリクエストを使うため、追加のフラグは不要です。同じファイルシステムオブジェクトは、`write_csv`、`read_json`、その他の Ray Data メソッドでも使えます。 -## 2. Run the job +## 2. ジョブを実行する -Run the script in the Ray image on the same Docker network as RustFS: +RustFS と同じ Docker ネットワーク上の Ray イメージで、スクリプトを実行します。 ```bash docker run --rm --network oo-rustfs_default \ @@ -62,42 +62,42 @@ rows: 5 sample: {'id': 0, 'value': 0.0} ``` -## 3. Verify objects in RustFS +## 3. RustFS でオブジェクトを確認する -List the dataset prefix: +データセットのプレフィックスを一覧表示します。 ```bash rc ls rustfs/my-bucket/ray-demo/ -r ``` -Ray Data wrote the dataset as a Parquet block: +Ray Data はデータセットを Parquet ブロックとして書き込みます。 ```text ray-demo/events/0_000000_000000.parquet ``` -![Ray dataset files stored in the RustFS Console](./images/rustfs-ray-data.png) +![RustFS Console に保存された Ray のデータセットファイル](./images/rustfs-ray-data.png) -## 4. Stop or reset +## 4. 停止またはリセット -Ray Data holds no state of its own. To delete the demo dataset: +Ray Data 自身は状態を持ちません。デモ用データセットを削除するには、次を実行します。 ```bash rc rm rustfs/my-bucket/ray-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `Unable to connect to endpoint` or timeouts +### `Unable to connect to endpoint` またはタイムアウト -Confirm `endpoint_override` includes the scheme and is reachable from the Ray container. Inside a Compose network the hostname is `rustfs`; from the host use `http://localhost:9000`. +`endpoint_override` にスキームが含まれ、Ray コンテナから到達できることを確認します。Compose ネットワーク内のホスト名は `rustfs` です。ホストからは `http://localhost:9000` を使います。 -### `Access Denied` on write +### 書き込み時の `Access Denied` -Confirm the access key and secret key are passed to `S3FileSystem` itself — Ray does not read the container's AWS environment variables through this code path. +アクセスキーとシークレットキーが `S3FileSystem` 自体に渡されていることを確認します。このコードパスでは、Ray はコンテナの AWS 環境変数を読み取りません。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Ray operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Ray Data documentation](https://docs.ray.io/en/latest/data/data.html) to chain transformations, training ingestion, and checkpointing on the same bucket. +- 追加の Ray 操作を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [Ray Data ドキュメント](https://docs.ray.io/en/latest/data/data.html)に従い、同じバケット上で変換の連鎖、トレーニングへの取り込み、チェックポイントを構成します。 diff --git a/content/ja/developer/integration/ai/vllm.md b/content/ja/developer/integration/ai/vllm.md index c471096cf..bcf9704db 100644 --- a/content/ja/developer/integration/ai/vllm.md +++ b/content/ja/developer/integration/ai/vllm.md @@ -1,13 +1,13 @@ --- title: "vLLM" -description: "Serve LLM inference with vLLM loading model weights stored in RustFS." +description: "RustFS に保存したモデルウェイトを読み込んで、vLLM で LLM 推論を提供します。" --- -This guide connects [vLLM](https://github.com/vllm-project/vllm) — the high-throughput LLM inference engine — to **RustFS** as its model-weight store. You will upload a model into a RustFS bucket, expose the bucket to the vLLM host through an rclone mount, and serve the model with the OpenAI-compatible API. The workflow was verified with `vllm/vllm-openai-cpu` (vLLM 0.30.0) serving `facebook/opt-125m` from a RustFS bucket backed by `rustfs/rustfs-x86-musl:v2.3.1`, on a CPU-only host. +このガイドでは、高スループットの LLM 推論エンジンである [vLLM](https://github.com/vllm-project/vllm) を、モデルウェイトのストアとして **RustFS** に接続します。モデルを RustFS のバケットへアップロードし、rclone マウントで vLLM ホストからバケットを参照し、OpenAI 互換 API でモデルを提供します。この流れは、CPU のみのホストで、`vllm/vllm-openai-cpu`（vLLM 0.30.0）が `rustfs/rustfs-x86-musl:v2.3.1` の RustFS バケットから `facebook/opt-125m` を提供する構成で検証済みです。 -You need Docker and an rclone binary on the host that runs vLLM. This deployment is intended for local integration testing, not production. +vLLM を実行するホストには、Docker と rclone バイナリが必要です。このデプロイはローカルでの統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -17,17 +17,17 @@ flowchart LR Client["OpenAI SDK / curl"] -->|"completions"| vLLM ``` -The bucket is the single copy of the model. Hosts that serve the model mount the bucket read-only, so every node pulls weights from RustFS and no local model store exists to drift. +バケットがモデルの唯一のコピーです。モデルを提供するホストはバケットを読み取り専用でマウントするため、各ノードは RustFS からウェイトを取得し、内容がずれるローカルのモデルストアは残りません。 -:::note[Why an rclone mount] +:::note[rclone マウントを使う理由] -vLLM 0.30 loads `s3://` model paths through the RunAI model streamer, whose ranged reads currently fail against custom S3 endpoints such as RustFS (the loader errors with `File access error` on any non-zero offset). Mounting the bucket as a filesystem is the verified way to keep the weights in RustFS while vLLM reads them as local files. +vLLM 0.30 は `s3://` のモデルパスを RunAI model streamer 経由で読み込みます。その範囲読み取りは、現時点では RustFS のようなカスタム S3 エンドポイントに対して失敗し、0 でないオフセットではローダーが `File access error` を返します。ウェイトを RustFS に置いたまま vLLM がローカルファイルとして読む、検証済みの方法は、バケットをファイルシステムとしてマウントすることです。 ::: -## 1. Upload the model to RustFS +## 1. モデルを RustFS にアップロードする -Create the bucket and copy model weights into it, replacing all connection placeholders: +接続用のプレースホルダーをすべて置き換え、バケットを作成してモデルウェイトをコピーします。 ```ini title="rclone.conf" [rustfs] @@ -44,11 +44,11 @@ rc mb rustfs/vllm-models rclone copy ./opt-125m rustfs:vllm-models/opt-125m --transfers 4 ``` -Any Hugging Face layout works — `config.json`, the tokenizer files, and the weight files (`model.safetensors` or `pytorch_model.bin`). Keep one model per prefix so several models can share the bucket. +Hugging Face のレイアウトであれば使えます。対象は `config.json`、トークナイザーのファイル、ウェイトファイル（`model.safetensors` または `pytorch_model.bin`）です。複数のモデルでバケットを共有できるよう、プレフィックスごとにモデルを 1 つにします。 -## 2. Mount the bucket on the vLLM host +## 2. vLLM ホストでバケットをマウントする -On the machine that runs vLLM, mount the bucket read-only for clients with `--allow-other`: +vLLM を実行するマシンで、クライアント向けに `--allow-other` を付け、バケットを読み取り専用でマウントします。 ```bash mkdir -p /mnt/vllm-models @@ -61,9 +61,9 @@ ls /mnt/vllm-models/opt-125m/ config.json merges.txt model.safetensors tokenizer.json vocab.json ``` -## 3. Run vLLM +## 3. vLLM を実行する -Start the CPU image against the mounted weights: +マウントしたウェイトを対象に、CPU イメージを起動します。 ```bash docker run -d --name vllm -p 8000:8000 --shm-size=2g \ @@ -73,7 +73,7 @@ docker run -d --name vllm -p 8000:8000 --shm-size=2g \ --dtype float32 --max-model-len 256 --gpu-memory-utilization 0.15 ``` -vLLM reads the weights through the mount — the container stays stateless and the model lives in RustFS. Wait for the server to come up: +vLLM はマウント経由でウェイトを読みます。コンテナはステートレスのままで、モデルは RustFS にあります。サーバーの起動を待ちます。 ```bash curl -s http://localhost:8000/v1/models | head -c 200 @@ -83,11 +83,11 @@ curl -s http://localhost:8000/v1/models | head -c 200 {"object":"list","data":[{"id":"opt-125m","object":"model","created":...,"root":"/models/opt-125m",...}]} ``` -`--gpu-memory-utilization` controls the fraction of RAM reserved for the KV cache on the CPU backend; lower it on small hosts. `--dtype float32` matches what the CPU attention kernels support for this model. +`--gpu-memory-utilization` は、CPU バックエンドで KV キャッシュ用に予約する RAM の割合を制御します。小規模なホストでは値を下げます。`--dtype float32` は、このモデルで CPU アテンションカーネルが対応する形式に合わせます。 -## 4. Run inference +## 4. 推論を実行する -Send an OpenAI-compatible completion request: +OpenAI 互換の補完リクエストを送信します。 ```bash curl -s http://localhost:8000/v1/completions \ @@ -101,7 +101,7 @@ curl -s http://localhost:8000/v1/completions \ "finish_reason":"length",...}]} ``` -The request is standard OpenAI schema, so the Python client works unchanged: +リクエストは標準の OpenAI スキーマなので、Python クライアントはそのまま動作します。 ```python from openai import OpenAI @@ -112,43 +112,43 @@ print(client.completions.create( ).choices[0].text) ``` -![vLLM model weights stored in the RustFS Console](./images/rustfs-vllm-models.png) +![RustFS Console に保存された vLLM のモデルウェイト](./images/rustfs-vllm-models.png) -## 5. Stop or reset +## 5. 停止またはリセット -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを解体するには、次を実行します。 ```bash docker rm -f vllm fusermount -u /mnt/vllm-models ``` -To delete the stored model: +保存したモデルを削除するには、次を実行します。 ```bash rclone purge rustfs:vllm-models ``` -## Troubleshooting +## トラブルシューティング ### `Cannot find any model weights with /models/...` -The mount had a stale directory cache or the weight files never made it to the bucket. Re-run `rclone copy` and confirm the files through the mount with `ls` before starting vLLM. A short `--dir-cache-time` (for example `10s`) helps while you iterate. +マウントのディレクトリキャッシュが古いか、ウェイトファイルがバケットに届いていません。`rclone copy` を再実行し、vLLM を起動する前にマウント経由の `ls` でファイルを確認します。反復作業中は、短い `--dir-cache-time`（例: `10s`）が有効です。 ### `Unsupported CPU attention configuration: head_dim=...` -vLLM's CPU kernels support a fixed set of head dimensions. Tiny test models such as `hf-internal-testing/tiny-random-*` use exotic shapes that fail at request time — use a real small model such as `facebook/opt-125m`. +vLLM の CPU カーネルが対応するヘッド次元は、固定の集合です。`hf-internal-testing/tiny-random-*` のような極小のテストモデルは特殊な形状を使うため、リクエスト時に失敗します。`facebook/opt-125m` のような実際の小型モデルを使います。 ### `Insufficient space in /dev/shm` -vLLM's CPU engine exchanges tensors through shared memory. Run the container with `--shm-size=2g` (or `--ipc=host`). +vLLM の CPU エンジンは、共有メモリ経由でテンソルを交換します。コンテナは `--shm-size=2g`（または `--ipc=host`）で実行します。 -### Server exits with `Available memory on node 0 ... is less than desired CPU memory utilization` +### `Available memory on node 0 ... is less than desired CPU memory utilization` でサーバーが終了する -The default KV-cache reservation is 90% of system RAM. Lower it with `--gpu-memory-utilization 0.15` (the flag applies to the CPU backend as a memory fraction despite its name). +KV キャッシュの既定の予約は、システム RAM の 90% です。`--gpu-memory-utilization 0.15` で下げます。このフラグは名前にかかわらず、CPU バックエンドではメモリ割合として適用されます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional serving setups. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [vLLM documentation](https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html) for chat templates, tensor parallelism, and quantized weights on top of the same bucket-backed model store. +- 追加のサービング構成を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [vLLM ドキュメント](https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html)に従い、同じバケットをバックエンドにしたモデルストアの上で、チャットテンプレート、テンソル並列、量子化ウェイトを確認します。 diff --git a/content/ja/developer/integration/backup/kopia.md b/content/ja/developer/integration/backup/kopia.md index fed21e5a3..586d7e546 100644 --- a/content/ja/developer/integration/backup/kopia.md +++ b/content/ja/developer/integration/backup/kopia.md @@ -1,13 +1,13 @@ --- title: "Kopia" -description: "Back up files to RustFS with Kopia's S3 repository backend." +description: "Kopia の S3 リポジトリのバックエンドとして RustFS にファイルをバックアップします。" --- -This guide connects [Kopia](https://github.com/kopia/kopia) — the open-source backup and restore tool — to **RustFS** as an S3 repository. You will create a repository in a RustFS bucket, take a snapshot of a directory, restore it into an empty directory, and compare checksums. The workflow was verified with `kopia/kopia:0.18.1` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、オープンソースのバックアップおよび復元ツールである [Kopia](https://github.com/kopia/kopia) を、S3 リポジトリとして **RustFS** に接続します。RustFS のバケットにリポジトリを作成し、ディレクトリのスナップショットを取得し、空のディレクトリへ復元してチェックサムを比較します。この流れは `kopia/kopia:0.18.1` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,11 +16,11 @@ flowchart LR Kopia -->|restore| Restore["Restored files"] ``` -Kopia stores the repository format files and deduplicated, encrypted content blocks in the bucket. Restores read the blocks back and reassemble the original files, so the checksum of every restored file must match the source. +Kopia は、リポジトリ形式のファイルと、重複排除され暗号化されたコンテンツブロックをバケットに保存します。復元ではブロックを読み戻して元のファイルを再構成するため、復元した各ファイルのチェックサムはソースと一致する必要があります。 -## 1. Create the repository +## 1. リポジトリを作成する -Create the bucket first, then initialize the Kopia repository inside it. The endpoint is a bare `host:port` (no scheme); `--disable-tls` switches the client to plain HTTP: +先にバケットを作成し、その中で Kopia リポジトリを初期化します。エンドポイントはスキームのない `host:port` です。`--disable-tls` はクライアントを平文 HTTP に切り替えます。 ```bash rc alias set rustfs http://:9000 @@ -37,11 +37,11 @@ docker run --rm --network oo-rustfs_default kopia/kopia:0.18.1 repository create --override-username demo --override-hostname workstation ``` -Kopia validates the provider by reading and writing through the S3 API before it reports success. +Kopia は成功を報告する前に、S3 API 経由の読み書きでプロバイダーを検証します。 -## 2. Connect, snapshot, and restore +## 2. 接続、スナップショット、復元 -Run the following commands from the directory holding your `repository.config` (created by the previous step). Kopia reads the connection settings from that file, so the S3 flags are only needed once: +前の手順で作成した `repository.config` があるディレクトリで、次のコマンドを実行します。Kopia はそのファイルから接続設定を読み取るため、S3 フラグが必要なのは一度だけです。 ```bash export KOPIA_PASSWORD= @@ -65,7 +65,7 @@ kopia snapshot create /source kopia snapshot list ``` -Restore the snapshot into an empty directory and compare checksums with the source. The snapshot ID is the `ka...` identifier printed by `snapshot list`: +スナップショットを空のディレクトリへ復元し、ソースとチェックサムを比較します。スナップショット ID は、`snapshot list` が表示する `ka...` 形式の識別子です。 ```bash kopia restore /restore @@ -78,15 +78,15 @@ bec4530e2798465b... source/blob.bin bec4530e2798465b... restore/blob.bin ``` -## 3. Verify objects in RustFS +## 3. RustFS でオブジェクトを確認する -List the bucket: +バケットを一覧表示します。 ```bash rc ls rustfs/kopia-backups/ -r ``` -The output shows the repository format files plus the packed content blocks written by the snapshot: +出力には、リポジトリ形式のファイルと、スナップショットが書き込んだパック済みコンテンツブロックが表示されます。 ```text kopia.blobcfg @@ -94,32 +94,32 @@ kopia.repository p0000.../... ``` -![Kopia repository blocks stored in the RustFS Console](./images/rustfs-kopia-repo.png) +![RustFS Console に保存された Kopia のリポジトリブロック](./images/rustfs-kopia-repo.png) -## 4. Stop or reset +## 4. 停止またはリセット -Kopia is a client-side tool and holds no running state. To delete the repository and all snapshots, remove the bucket: +Kopia はクライアント側のツールであり、実行中の状態は持ちません。リポジトリとすべてのスナップショットを削除するには、バケットを削除します。 ```bash rc rb rustfs/kopia-backups --force ``` -## Troubleshooting +## トラブルシューティング ### `Endpoint url cannot have fully qualified paths` -The endpoint must be a bare `host:port` value without a scheme or path — Kopia builds the object URLs itself. +エンドポイントは、スキームもパスもない `host:port` である必要があります。オブジェクト URL は Kopia が組み立てます。 ### `server gave HTTP response to HTTPS client` -Without `--disable-tls`, Kopia speaks HTTPS. RustFS without TLS needs the `--disable-tls` flag on both `repository create s3` and `repository connect s3`. +`--disable-tls` がないと、Kopia は HTTPS で通信します。TLS のない RustFS では、`repository create s3` と `repository connect s3` の両方に `--disable-tls` フラグが必要です。 -### `can't connect to storage` with a DNS error +### DNS エラーを伴う `can't connect to storage` -The S3 client is using virtual-hosted addressing. Keep the endpoint as a bare `host:port` value; Kopia uses path-style requests for endpoints given in that form. +S3 クライアントが仮想ホスト形式を使っています。エンドポイントはスキームのない `host:port` のままにします。その形式で指定したエンドポイントに対して、Kopia はパススタイルアクセスのリクエストを使います。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Kopia operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Kopia repository documentation](https://kopia.io/docs/repositories/) to add policies, retention, and scheduled snapshots. +- 追加の Kopia 操作を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [Kopia リポジトリのドキュメント](https://kopia.io/docs/repositories/)に従い、ポリシー、保持設定、スケジュールされたスナップショットを追加します。 diff --git a/content/ja/developer/integration/backup/longhorn.md b/content/ja/developer/integration/backup/longhorn.md index 497f43cdb..39cb5d6d9 100644 --- a/content/ja/developer/integration/backup/longhorn.md +++ b/content/ja/developer/integration/backup/longhorn.md @@ -1,13 +1,13 @@ --- title: "Longhorn" -description: "Configure Longhorn to store Kubernetes volume backups in RustFS through its S3 backup target." +description: "S3 バックアップターゲットを通じて、Kubernetes ボリュームのバックアップを RustFS に保存するよう Longhorn を構成します。" --- -This guide connects [Longhorn](https://github.com/longhorn/longhorn) — the distributed block storage system for Kubernetes — to **RustFS** as its S3 backup target. You will configure the backup target, back up a volume that contains data, delete the volume, restore it from RustFS, and verify the data. The workflow was verified with Longhorn 1.9.0 on k3s (Kubernetes 1.30) and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Kubernetes 向けの分散ブロックストレージである [Longhorn](https://github.com/longhorn/longhorn) を、S3 バックアップターゲットとして **RustFS** に接続します。バックアップターゲットを構成し、データを含むボリュームをバックアップし、ボリュームを削除して RustFS から復元し、データを確認します。この流れは、k3s（Kubernetes 1.30）上の Longhorn 1.9.0 と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need a Kubernetes cluster with Longhorn installed and `kubectl` access to it. This guide is intended for integration testing, not production. +Longhorn がインストールされた Kubernetes クラスターと、そのクラスターへの `kubectl` アクセスが必要です。このガイドは統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,22 +16,22 @@ flowchart LR Backup -->|"blocks + config"| RustFS["RustFS :9000"] ``` -Longhorn stores backups in the `backupstore/volumes/` prefix of the target bucket as content-addressed blocks plus a small volume configuration file. Restores read those objects back into a new volume on any node that can reach RustFS. +Longhorn は、ターゲットバケットの `backupstore/volumes/` プレフィックスに、コンテンツアドレス指定のブロックと小さなボリューム設定ファイルとしてバックアップを保存します。復元では、RustFS に到達できる任意のノード上の新しいボリュームへ、それらのオブジェクトを読み戻します。 -## 1. Create the backup bucket +## 1. バックアップバケットを作成する -Create a dedicated bucket with the [`rc` client](https://github.com/rustfs/cli), using your own endpoint and credentials: +独自のエンドポイントと認証情報を使い、[`rc` クライアント](https://github.com/rustfs/cli) で専用バケットを作成します。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/longhorn-backups ``` -Longhorn does not create the bucket, so this step must complete before the first backup. +Longhorn はバケットを作成しないため、最初のバックアップの前にこの手順を完了する必要があります。 -## 2. Configure the backup target +## 2. バックアップターゲットを構成する -Store the RustFS credentials in a secret in the `longhorn-system` namespace. `AWS_ENDPOINTS` must be an endpoint every node can reach — use the node IP or an internal load balancer address, not a port forward from your workstation: +`longhorn-system` 名前空間の Secret に RustFS の認証情報を保存します。`AWS_ENDPOINTS` は、すべてのノードから到達できるエンドポイントである必要があります。ノードの IP または内部ロードバランサーのアドレスを使います。作業用マシンからのポートフォワードは使えません。 ```bash kubectl -n longhorn-system create secret generic rustfs-s3-secret \ @@ -40,7 +40,7 @@ kubectl -n longhorn-system create secret generic rustfs-s3-secret \ --from-literal=AWS_ENDPOINTS=http://:9000 ``` -Longhorn 1.9 manages backup targets through the `BackupTarget` resource. Patch the `default` target with the RustFS bucket: +Longhorn 1.9 は `BackupTarget` リソースでバックアップターゲットを管理します。`default` ターゲットを RustFS のバケットでパッチします。 ```bash kubectl -n longhorn-system patch backupTarget default --type merge -p ' @@ -50,9 +50,9 @@ spec: pollInterval: 5m' ``` -The `@us-east-1` segment is the region annotation in the S3 URL format; it does not need to match a real deployment region. +`@us-east-1` の部分は、S3 URL 形式のリージョン注釈です。実際のデプロイのリージョンと一致している必要はありません。 -Wait for the target to become available — it confirms that Longhorn reached the bucket through the secret: +ターゲットが利用可能になるまで待ちます。これにより、Longhorn が Secret 経由でバケットに到達できたことを確認できます。 ```bash kubectl -n longhorn-system get backupTarget default @@ -63,9 +63,9 @@ NAME URL CREDENTIAL AVAILABLE LAST default s3://longhorn-backups@us-east-1/ rustfs-s3-secret true 2026-09-21T08:36:55Z ``` -## 3. Write data and create a backup +## 3. データを書き込んでバックアップを作成する -Create a test volume with data in it. The following manifest creates a 1 GiB PVC and a pod that writes a marker file: +データを含むテスト用ボリュームを作成します。次のマニフェストは、1 GiB の PVC と、マーカーファイルを書き込む Pod を作成します。 ```yaml title="demo.yaml" apiVersion: v1 @@ -97,14 +97,14 @@ spec: mountPath: /data ``` -Apply it and wait for the pod to run: +適用し、Pod が実行状態になるまで待ちます。 ```bash kubectl apply -f demo.yaml kubectl get pod demo-app ``` -Create a snapshot and back it up. You can do this in the Longhorn UI (Volume → Snapshot → Backup) or declaratively: +スナップショットを作成してバックアップします。Longhorn UI の **Volume**（ボリューム）→ **Snapshot**（スナップショット）→ **Backup**（バックアップ）で実行するか、宣言的に作成できます。 ```bash VOLUME=$(kubectl get pvc demo-vol -o jsonpath='{.spec.volumeName}') @@ -119,7 +119,7 @@ spec: EOF ``` -Then create the `Backup` resource for that snapshot: +そのスナップショットに対する `Backup` リソースを作成します。 ```bash kubectl -n longhorn-system apply -f - < --type merge -p ' @@ -276,18 +276,18 @@ spec: ### `failed to create backup ... missing input parameter` -The backup ran before the default backup target was configured. Complete step 2, confirm `AVAILABLE` is `true`, and create the backup again. +デフォルトのバックアップターゲットを構成する前に、バックアップが実行されました。手順 2 を完了し、`AVAILABLE` が `true` であることを確認してから、バックアップを再作成します。 -### The backup target never becomes available +### バックアップターゲットが利用可能にならない -The secret must exist before the target syncs, and `AWS_ENDPOINTS` must be reachable from the nodes themselves. Check the `longhorn-manager` logs for S3 errors: +ターゲットが同期する前に Secret が存在する必要があり、`AWS_ENDPOINTS` はノード自身から到達できる必要があります。S3 エラーがないか、`longhorn-manager` のログを確認します。 ```bash kubectl -n longhorn-system logs -l app=longhorn-manager | grep -i s3 | tail ``` -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional backup targets. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Longhorn backup documentation](https://longhorn.io/docs/1.9.0/backups-and-restore/) to configure recurring backup jobs and scheduled snapshots. +- 追加のバックアップターゲットを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [Longhorn のバックアップドキュメント](https://longhorn.io/docs/1.9.0/backups-and-restore/)に従い、定期バックアップジョブとスケジュールされたスナップショットを構成します。 diff --git a/content/ja/developer/integration/backup/restic.md b/content/ja/developer/integration/backup/restic.md index f07b47fae..47a29fad0 100644 --- a/content/ja/developer/integration/backup/restic.md +++ b/content/ja/developer/integration/backup/restic.md @@ -87,5 +87,5 @@ restic -o s3.bucket-lookup=path check ## 次のステップ -- [CLI クライアント（rc）](/operations/rc) でバケットを作成し、コマンドラインからオブジェクトを確認します。 -- RustFS を信頼できるネットワークの外に公開する場合は、[TLS の設定](/integration/tls-configured)を確認してください。 \ No newline at end of file +- [CLI クライアント（rc）](/ja/operations/rc) でバケットを作成し、コマンドラインからオブジェクトを確認します。 +- RustFS を信頼できるネットワークの外に公開する場合は、[TLS の設定](/ja/integration/tls-configured)を確認してください。 \ No newline at end of file diff --git a/content/ja/developer/integration/backup/velero.md b/content/ja/developer/integration/backup/velero.md index 0140296bf..366379d63 100644 --- a/content/ja/developer/integration/backup/velero.md +++ b/content/ja/developer/integration/backup/velero.md @@ -1,13 +1,13 @@ --- title: "Velero" -description: "Back up Kubernetes cluster resources to RustFS with Velero's AWS object store provider." +description: "Velero の AWS オブジェクトストアプロバイダーを使い、Kubernetes クラスターのリソースを RustFS にバックアップします。" --- -This guide connects [Velero](https://github.com/vmware-tanzu/velero) — the Kubernetes backup and restore tool — to **RustFS** as its object storage backend. You will install Velero into a Kubernetes cluster with a RustFS backup location, back up cluster resources, delete them, restore from the bucket, and verify the restored objects. The workflow was verified with Velero CLI 1.16.2, `velero-plugin-for-aws:v1.12.2` on k3s (Kubernetes 1.30), and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Kubernetes のバックアップおよび復元ツールである [Velero](https://github.com/vmware-tanzu/velero) を、オブジェクトストレージのバックエンドとして **RustFS** に接続します。Kubernetes クラスターに Velero をインストールして RustFS のバックアップロケーションを設定し、クラスターリソースをバックアップして削除し、バケットから復元して、復元されたオブジェクトを確認します。この流れは、k3s（Kubernetes 1.30）上の Velero CLI 1.16.2 と `velero-plugin-for-aws:v1.12.2`、および `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need a Kubernetes cluster with `kubectl` access and the Velero CLI. This guide is intended for integration testing, not production. +`kubectl` でアクセスできる Kubernetes クラスターと、Velero CLI が必要です。このガイドは統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,20 +15,20 @@ flowchart LR V -->|"backups + logs"| RustFS["RustFS :9000"] ``` -Velero serializes Kubernetes resources and (optionally) pod volume data into gzip archives under `backups//` in the bucket. Restores download those archives and recreate the resources in the cluster. +Velero は、Kubernetes リソースと（任意で）Pod のボリュームデータを、バケット内の `backups//` 配下にある gzip アーカイブへシリアライズします。復元ではそれらのアーカイブをダウンロードし、クラスター内にリソースを再作成します。 -## 1. Create the backup bucket +## 1. バックアップバケットを作成する -Create a dedicated bucket — Velero does not create buckets: +専用バケットを作成します。Velero はバケットを作成しません。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/velero-backups ``` -## 2. Install Velero +## 2. Velero をインストールする -Write the credentials to a file and install the Velero server. The `s3Url` must be an endpoint reachable from the cluster pods themselves — use the node IP or an internal address, not a port forward from your workstation: +認証情報をファイルに書き込み、Velero サーバーをインストールします。`s3Url` は、クラスターの Pod 自身から到達できるエンドポイントである必要があります。ノードの IP または内部アドレスを使います。作業用マシンからのポートフォワードは使えません。 ```bash cat > velero-creds <|"poll key"| RustFS ``` -Every S3 interaction inside a DAG goes through the provider's S3 client, pointed at RustFS by the connection's `endpoint_url`. Operators, sensors, and hooks share the same connection object. +DAG 内のすべての S3 操作は、接続の `endpoint_url` で RustFS を向いたプロバイダーの S3 クライアントを経由します。オペレーター、センサー、フックは同じ接続オブジェクトを共有します。 -## 1. Run Airflow +## 1. Airflow を実行する -Start a standalone instance with examples disabled, and create the demo bucket: +サンプルを無効にしたスタンドアロンインスタンスを起動し、デモ用バケットを作成します。 ```bash docker run -d --name airflow --network oo-rustfs_default -p 8080:8080 \ @@ -31,11 +31,11 @@ docker run -d --name airflow --network oo-rustfs_default -p 8080:8080 \ rc mb rustfs/airflow-demo ``` -The image ships with all providers preinstalled, including `apache-airflow-providers-amazon`. +イメージには、`apache-airflow-providers-amazon` を含むすべてのプロバイダーが事前にインストールされています。 -## 2. Register the RustFS connection +## 2. RustFS 接続を登録する -The S3 provider reads its endpoint from the connection's extra field. Replace all connection placeholders: +S3 プロバイダーは、接続の extra フィールドからエンドポイントを読み取ります。接続用のプレースホルダーをすべて置き換えます。 ```bash docker exec airflow airflow connections add rustfs \ @@ -43,11 +43,11 @@ docker exec airflow airflow connections add rustfs \ --conn-extra '{"endpoint_url": "http://:9000", "region_name": "us-east-1", "aws_access_key_id": "", "aws_secret_access_key": ""}' ``` -The keys `aws_access_key_id` and `aws_secret_access_key` inside `--conn-extra` supply credentials; `endpoint_url` redirects the boto3 client from AWS to RustFS. +`--conn-extra` 内の `aws_access_key_id` と `aws_secret_access_key` が認証情報を渡します。`endpoint_url` は boto3 クライアントの向き先を AWS から RustFS に変えます。 -## 3. Write the DAG +## 3. DAG を書く -The DAG writes an object with an operator, waits for the key with a sensor, and reads it back with the hook: +DAG はオペレーターでオブジェクトを書き込み、センサーでキーを待ち、フックで読み戻します。 ```python title="rustfs_demo.py" import datetime @@ -95,18 +95,18 @@ def rustfs_demo(): rustfs_demo() ``` -Note the import paths: `S3CreateObjectOperator` lives in the `operators` module while `S3KeySensor` lives in the `sensors` module — importing both from one place fails. +インポートパスに注意します。`S3CreateObjectOperator` は `operators` モジュールにあり、`S3KeySensor` は `sensors` モジュールにあります。両方を同じ場所からインポートすると失敗します。 -## 4. Unpause and trigger +## 4. 一時停止を解除してトリガーする -New DAGs start paused, and a trigger fired while paused stays queued forever. Unpause first, then trigger: +新しい DAG は一時停止状態で始まり、一時停止中に発火したトリガーは永久にキューへ残ります。先に一時停止を解除してからトリガーします。 ```bash docker exec airflow airflow dags unpause rustfs_demo docker exec airflow airflow dags trigger rustfs_demo ``` -Watch the run finish: +実行の完了を確認します。 ```bash docker exec airflow airflow dags list-runs rustfs_demo | head -3 @@ -117,11 +117,11 @@ dag_id run_id state rustfs_demo manual__2026-09-29T13:15:57.332688+00:00 success ``` -All three tasks succeed: `write_object`, `wait_for_object`, and `read_object`. +`write_object`、`wait_for_object`、`read_object` の 3 つのタスクがすべて成功します。 -## 5. Verify objects in RustFS +## 5. RustFS でオブジェクトを確認する -List the bucket prefix: +バケットのプレフィックスを一覧表示します。 ```bash rc ls rustfs/airflow-demo/ -r @@ -133,38 +133,38 @@ rc cat rustfs/airflow-demo/dags/airflow-put.txt written by airflow to rustfs ``` -![Airflow object stored in the RustFS Console](./images/rustfs-airflow-object.png) +![RustFS Console に保存された Airflow のオブジェクト](./images/rustfs-airflow-object.png) -## 6. Stop or reset +## 6. 停止またはリセット -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを解体するには、次を実行します。 ```bash docker rm -f airflow ``` -To delete the stored data: +保存したデータを削除するには、次を実行します。 ```bash rc rm rustfs/airflow-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Dag runs stay `queued` after triggering +### トリガー後も DAG の実行が `queued` のままになる -The DAG is paused. New DAGs are paused by default in Airflow 3, and runs triggered in that state never execute. Run `airflow dags unpause rustfs_demo`; queued runs then start on their own. +DAG が一時停止しています。Airflow 3 では新しい DAG が既定で一時停止し、その状態でトリガーしても実行は始まりません。`airflow dags unpause rustfs_demo` を実行すると、キューに入った実行は自動的に開始します。 ### `cannot import name 'S3KeySensor' from 'airflow.providers.amazon.aws.operators.s3'` -The sensor lives in a separate module: `from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor`. +センサーは別モジュールにあります。`from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor` を使います。 -### Tasks fail with connection errors +### 接続エラーでタスクが失敗する -The `endpoint_url` must be reachable from the Airflow container — use the Docker network hostname for RustFS, not `localhost`. Airflow 3 serves its health endpoint under `/api/v2/monitor/health` if you need to check component status. +`endpoint_url` は Airflow コンテナから到達できる必要があります。RustFS には Docker ネットワークのホスト名を使います。`localhost` では到達できません。コンポーネントの状態を確認する場合、Airflow 3 のヘルスチェック用エンドポイントは `/api/v2/monitor/health` です。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional provider hooks. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Amazon provider documentation](https://airflow.apache.org/docs/apache-airflow-providers-amazon/stable/index.html) for transfer operators such as `S3ToLocalFilesystemOperator` and `LocalFilesystemToS3Operator`. +- 追加のプロバイダーフックを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [Amazon プロバイダーのドキュメント](https://airflow.apache.org/docs/apache-airflow-providers-amazon/stable/index.html)に従い、`S3ToLocalFilesystemOperator` や `LocalFilesystemToS3Operator` などの転送オペレーターを確認します。 diff --git a/content/ja/developer/integration/big-data/automq.md b/content/ja/developer/integration/big-data/automq.md index 053a28dee..b5508bd8c 100644 --- a/content/ja/developer/integration/big-data/automq.md +++ b/content/ja/developer/integration/big-data/automq.md @@ -1,13 +1,13 @@ --- title: "AutoMQ" -description: "Run AutoMQ with RustFS as the S3-backed log storage." +description: "S3 をバックエンドにしたログストレージとして RustFS を使い、AutoMQ を実行します。" --- -This guide connects [AutoMQ](https://github.com/AutoMQ/automq) — the cloud-native Kafka distribution that keeps its log storage in object storage — to **RustFS**. You will start a single-node AutoMQ broker in KRaft mode with its S3 log buckets pointed at RustFS, then produce and consume messages. The workflow was verified with AutoMQ 1.3.0 (Kafka 3.9.0 API) against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、ログストレージをオブジェクトストレージに置くクラウドネイティブな Kafka ディストリビューションである [AutoMQ](https://github.com/AutoMQ/automq) を **RustFS** に接続します。KRaft モードのシングルノード AutoMQ ブローカーを、S3 ログバケットを RustFS に向けて起動し、メッセージを送信して消費します。この流れは、AutoMQ 1.3.0（Kafka 3.9.0 API）を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -17,11 +17,11 @@ flowchart LR Consumer["Console consumer"] -->|"fetch"| Broker ``` -AutoMQ decouples storage from brokers: the write-ahead log is buffered locally, then uploaded as immutable stream objects into the bucket. The broker keeps no local data directory beyond the WAL. +AutoMQ はストレージをブローカーから分離します。先行書き込みログ（WAL）はローカルにバッファしたあと、不変のストリームオブジェクトとしてバケットへアップロードします。ブローカーがローカルに保持するデータディレクトリは WAL だけです。 -## 1. Run the broker +## 1. ブローカーを実行する -Start AutoMQ with the S3 buckets pointed at RustFS. Four details are mandatory: space-separated script arguments (`--key=value` makes the startup script loop forever), `JAVA_TOOL_OPTIONS` with `-XX:-UseContainerSupport` (the bundled JDK 17 crashes on cgroup v2 detection otherwise), the `server` combined role, and credentials via `KAFKA_S3_ACCESS_KEY`/`KAFKA_S3_SECRET_KEY` environment variables (the `--s3.access.key` script arguments are ignored): +S3 バケットを RustFS に向けて AutoMQ を起動します。次の 4 点は必須です。スクリプト引数は空白区切りにします（`--key=value` 形式だと起動スクリプトが永久にループします）。`JAVA_TOOL_OPTIONS` に `-XX:-UseContainerSupport` を含めます（同梱の JDK 17 は、これがないと cgroup v2 の検出でクラッシュします）。複合ロールは `server` にします。認証情報は `KAFKA_S3_ACCESS_KEY` と `KAFKA_S3_SECRET_KEY` の環境変数で渡します（`--s3.access.key` のスクリプト引数は無視されます）。 ```bash docker run -d --name automq --hostname automq --network oo-rustfs_default -p 9092:9092 \ @@ -39,9 +39,9 @@ docker run -d --name automq --hostname automq --network oo-rustfs_default -p 909 --s3.endpoint http://rustfs:9000 ``` -The broker binds its listener to the container IP. For the console tools, address it by that IP (the hostname `automq` also works from inside the container). +ブローカーはリスナーをコンテナの IP にバインドします。コンソールツールからはその IP で接続します。コンテナ内からはホスト名 `automq` も使えます。 -## 2. Create a topic and produce +## 2. トピックを作成して送信する ```bash AIP= @@ -53,7 +53,7 @@ docker exec automq sh -c "cd /opt/automq/kafka && \ ./bin/kafka-console-producer.sh --bootstrap-server $AIP:9092 --topic rustfs-automq" ``` -## 3. Consume the messages +## 3. メッセージを消費する ```bash docker exec automq sh -c "cd /opt/automq/kafka && \ @@ -68,9 +68,9 @@ mq-msg-three Processed a total of 3 messages ``` -## 4. Verify objects in RustFS +## 4. RustFS でオブジェクトを確認する -List the bucket — AutoMQ writes its log streams and metrics as objects: +バケットを一覧表示します。AutoMQ はログストリームとメトリクスをオブジェクトとして書き込みます。 ```bash rc ls rustfs/automq-demo/ -r @@ -82,41 +82,41 @@ automq/logs/rZdE0DjZSrqy96PXrMUZVw/0/2026100701/52877dc7-... automq/metrics/rZdE0DjZSrqy96PXrMUZVw/0/2026100701/4733e680-... ``` -The log stream objects hold the topic data — the broker keeps only the WAL locally, so scaling brokers up or down does not move data. +ログストリームのオブジェクトがトピックデータを保持します。ブローカーがローカルに保持するのは WAL だけなので、ブローカーを増減してもデータは移動しません。 -![AutoMQ log streams stored in the RustFS Console](./images/rustfs-automq-logs.png) +![RustFS Console に保存された AutoMQ のログストリーム](./images/rustfs-automq-logs.png) -## 5. Stop or reset +## 5. 停止またはリセット ```bash docker rm -f automq rc rm rustfs/automq-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Startup script prints `setup_value:` lines forever at 100% CPU +### 起動スクリプトが CPU 使用率 100% のまま `setup_value:` の行を出し続ける -The argument parser only accepts the space-separated form (`--s3.bucket x`, not `--s3.bucket=x`). The `=` form makes the parser loop forever. +引数パーサーが受け付けるのは空白区切りの形式（`--s3.bucket x`）だけです。`--s3.bucket=x` のような `=` 形式では、パーサーが永久にループします。 ### `java.lang.NullPointerException ... CgroupInfo.getMountPoint()` -The bundled JDK 17 fails cgroup v2 detection in this image. Set `JAVA_TOOL_OPTIONS="-XX:-UseContainerSupport"`. +このイメージに同梱された JDK 17 は、cgroup v2 の検出に失敗します。`JAVA_TOOL_OPTIONS="-XX:-UseContainerSupport"` を設定します。 ### `unknown process role broker,controller` -AutoMQ 1.3.0's script expects the combined role to be spelled `server`. +AutoMQ 1.3.0 のスクリプトは、複合ロールの表記を `server` と想定しています。 -### Broker starts but clients get `Connection to node -1 could not be established` +### ブローカーは起動するがクライアントが `Connection to node -1 could not be established` になる -The listener binds to the container IP (`hostname -I`). Address the broker by that IP or by the hostname `automq` from inside the same Docker network — `localhost` only works for tools running inside the broker container itself. +リスナーはコンテナの IP（`hostname -I`）にバインドします。同じ Docker ネットワーク内からは、その IP またはホスト名 `automq` でブローカーに接続します。`localhost` が使えるのは、ブローカーコンテナ自身の中で動くツールだけです。 ### `List objects failed, cost: 120000+ ms` -AutoMQ uses virtual-host addressing by default and falls into a retry loop against IP endpoints. Force path-style buckets by overriding the bucket URLs with `KAFKA_CFG_S3_DATA_BUCKETS`/`KAFKA_CFG_S3_OPS_BUCKETS` set to `0@s3://?region=us-east-1&endpoint=http://rustfs:9000&pathStyle=true&authType=static`, and pass credentials via `KAFKA_S3_ACCESS_KEY`/`KAFKA_S3_SECRET_KEY`. +AutoMQ は既定で仮想ホスト形式を使い、IP エンドポイントに対して再試行ループに入ります。`KAFKA_CFG_S3_DATA_BUCKETS` と `KAFKA_CFG_S3_OPS_BUCKETS` でバケット URL を上書きし、値を `0@s3://?region=us-east-1&endpoint=http://rustfs:9000&pathStyle=true&authType=static` にしてパススタイルアクセスを強制します。認証情報は `KAFKA_S3_ACCESS_KEY` と `KAFKA_S3_SECRET_KEY` で渡します。 -## Next steps +## 次のステップ -- Compare with the [Kafka](/developer/integration/big-data/kafka) guide when you prefer connect-based S3 integration on stock Kafka. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [AutoMQ documentation](https://docs.automq.com/) for multi-node clusters and WAL parameter tuning on the same bucket. +- 標準の Kafka で Connect ベースの S3 連携を選ぶ場合は、[Kafka](/ja/developer/integration/big-data/kafka) のガイドと比較します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [AutoMQ ドキュメント](https://docs.automq.com/)に従い、同じバケット上でのマルチノードクラスターと WAL パラメーターの調整を確認します。 diff --git a/content/ja/developer/integration/big-data/delta-lake.md b/content/ja/developer/integration/big-data/delta-lake.md index b1bfae566..e606551ae 100644 --- a/content/ja/developer/integration/big-data/delta-lake.md +++ b/content/ja/developer/integration/big-data/delta-lake.md @@ -1,13 +1,13 @@ --- title: "Delta Lake" -description: "Write and read Delta tables on RustFS with delta-rs." +description: "delta-rs を使い、RustFS 上の Delta テーブルを書き込み、読み取ります。" --- -This guide connects [Delta Lake](https://github.com/delta-io/delta) — the open-source lakehouse table format — to **RustFS** through delta-rs, the Rust-native Delta implementation. You will write a Delta table to a RustFS bucket from Python, read it back with ACID transaction history, and confirm the `_delta_log` and Parquet files in the bucket. The workflow was verified with the `deltalake` Python package (delta-rs) and pandas against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、オープンソースのレイクハウステーブル形式である [Delta Lake](https://github.com/delta-io/delta) を、Rust ネイティブの Delta 実装である delta-rs を通じて **RustFS** に接続します。Python から RustFS のバケットへ Delta テーブルを書き込み、ACID のトランザクション履歴付きで読み戻し、バケット内の `_delta_log` と Parquet ファイルを確認します。この流れは、`deltalake` Python パッケージ（delta-rs）と pandas を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Python 3.9 or newer. This deployment is intended for local integration testing, not production. +Python 3.9 以降が必要です。このデプロイはローカルでの統合テストを目的としており、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,19 +16,19 @@ flowchart LR Query["DeltaTable"] -->|"read / time travel"| RustFS ``` -delta-rs stores each table as Parquet files plus a transaction log (`_delta_log/`). All I/O goes through the `object_store` crate, configured with the same AWS environment variables as other S3 clients. +delta-rs は、各テーブルを Parquet ファイルとトランザクションログ（`_delta_log/`）として保存します。すべての I/O は `object_store` クレートを経由し、他の S3 クライアントと同じ AWS 環境変数で構成します。 -## 1. Install the client +## 1. クライアントをインストールする ```bash pip install deltalake pandas pyarrow ``` -`pyarrow` is required to convert pandas frames into Delta-compatible record batches. +pandas のフレームを Delta 互換のレコードバッチへ変換するには、`pyarrow` が必要です。 -## 2. Write a Delta table +## 2. Delta テーブルを書き込む -Create the bucket and write a table, replacing all connection placeholders. `AWS_S3_ALLOW_UNSAFE_RENAME` is needed because RustFS does not provide copy-if-not-exists, which delta-rs otherwise uses for commit conflicts: +接続用のプレースホルダーをすべて置き換え、バケットを作成してテーブルを書き込みます。`AWS_S3_ALLOW_UNSAFE_RENAME` が必要なのは、RustFS が copy-if-not-exists（存在しないときだけコピーする操作）を提供せず、delta-rs がコミット競合の処理にそれを使うためです。 ```python title="delta_s3.py" import pandas as pd @@ -53,9 +53,9 @@ print("written:", df.shape[0], "rows") written: 3 rows ``` -The `table` URI uses the standard `s3://bucket/prefix` form; the endpoint and credentials come from `storage_options`. +`table` の URI は標準の `s3://bucket/prefix` 形式です。エンドポイントと認証情報は `storage_options` から渡します。 -## 3. Read the table back +## 3. テーブルを読み戻す ```python title="delta_read.py" from deltalake import DeltaTable @@ -75,51 +75,51 @@ read back: 3 rows version: 0 ``` -Because the version is tracked in the transaction log, the same table supports time travel with `DeltaTable(..., version=N)` and appends that bump the version. +バージョンはトランザクションログで追跡されるため、同じテーブルで `DeltaTable(..., version=N)` によるタイムトラベルと、バージョンを進める追記が使えます。 -## 4. Verify objects in RustFS +## 4. RustFS でオブジェクトを確認する -List the table prefix: +テーブルのプレフィックスを一覧表示します。 ```bash rc ls rustfs// -r ``` -The first commit created the transaction log and one Parquet file: +最初のコミットで、トランザクションログと Parquet ファイルが 1 つ作成されます。 ```text events/_delta_log/00000000000000000000.json events/part-00000-3859855e-45e4-4ae5-94ff-2d8eab5e7ebb-c000.snappy.parquet ``` -Every new write adds a `NNNNNNNNNNNNNNNNNNNN.json` log entry and Parquet parts; readers replay the log to get a consistent snapshot. +新しい書き込みのたびに、`NNNNNNNNNNNNNNNNNNNN.json` のログエントリと Parquet のパートが追加されます。読み取り側はログを再生して、一貫したスナップショットを得ます。 -![Delta table files stored in the RustFS Console](./images/rustfs-delta-table.png) +![RustFS Console に保存された Delta テーブルのファイル](./images/rustfs-delta-table.png) -## 5. Stop or reset +## 5. 停止またはリセット -delta-rs holds no state of its own. To delete the table: +delta-rs 自身は状態を持ちません。テーブルを削除するには、次を実行します。 ```bash rc rm rustfs//events/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `Import pyarrow failed` when writing a pandas DataFrame +### pandas の DataFrame 書き込み時の `Import pyarrow failed` -`write_deltalake` converts frames through Arrow. Install `pyarrow` alongside `deltalake` and `pandas`. +`write_deltalake` はフレームを Arrow 経由で変換します。`deltalake` と `pandas` に加えて `pyarrow` をインストールします。 -### `Generic DeltaTable error: commit conflict` or rename errors on commit +### コミット時の `Generic DeltaTable error: commit conflict` またはリネームエラー -delta-rs commits by copying and renaming temporary objects, which requires atomic rename on the backend. For S3-compatible stores without copy-if-not-exists, set `AWS_S3_ALLOW_UNSAFE_RENAME: "true"` in `storage_options` — acceptable for a single writer, not for concurrent writers. +delta-rs は一時オブジェクトのコピーとリネームでコミットするため、バックエンドにアトミックなリネームが必要です。copy-if-not-exists を持たない S3 互換ストアでは、`storage_options` に `AWS_S3_ALLOW_UNSAFE_RENAME: "true"` を設定します。単一ライターでは許容できます。同時ライターには向きません。 ### `Unknown lengthy error: AWS connectivity or endpoint errors` -Confirm `AWS_ENDPOINT_URL` includes the scheme and that `AWS_ALLOW_HTTP` is `"true"` for plain-HTTP endpoints; without it the S3 client only speaks HTTPS. +平文 HTTP のエンドポイントでは、`AWS_ENDPOINT_URL` にスキームが含まれることと、`AWS_ALLOW_HTTP` が `"true"` であることを確認します。設定しないと、S3 クライアントは HTTPS のみで通信します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Delta clients. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [delta-rs usage documentation](https://delta-io.github.io/delta-rs/usage/writing/writing-to-s3/) for concurrent-writer setups with DynamoDB-backed commit coordination. +- 追加の Delta クライアントを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [delta-rs の利用ドキュメント](https://delta-io.github.io/delta-rs/usage/writing/writing-to-s3/)に従い、DynamoDB をバックエンドにしたコミット調整による同時ライター構成を確認します。 diff --git a/content/ja/developer/integration/big-data/dolphinscheduler.md b/content/ja/developer/integration/big-data/dolphinscheduler.md index ca90bc0aa..a6bdde4ba 100644 --- a/content/ja/developer/integration/big-data/dolphinscheduler.md +++ b/content/ja/developer/integration/big-data/dolphinscheduler.md @@ -1,13 +1,13 @@ --- title: "DolphinScheduler" -description: "Store DolphinScheduler resources on RustFS over S3." +description: "S3 経由で DolphinScheduler のリソースを RustFS に保存します。" --- -This guide connects [Apache DolphinScheduler](https://github.com/apache/dolphinscheduler) — the workflow scheduler — to **RustFS** as its resource center storage. You will run the standalone server, switch the resource storage to S3, upload a resource file through the API, and verify the object in the bucket. The workflow was verified with DolphinScheduler 3.2.1 (standalone server) against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、ワークフロースケジューラーである [Apache DolphinScheduler](https://github.com/apache/dolphinscheduler) を、リソースセンターのストレージとして **RustFS** に接続します。スタンドアロンサーバーを実行し、リソースストレージを S3 に切り替え、API でリソースファイルをアップロードし、バケット内のオブジェクトを確認します。この流れは、DolphinScheduler 3.2.1（スタンドアロンサーバー）を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Docker. +Docker が必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,9 +15,9 @@ flowchart LR DS -->|"S3 API"| RustFS["RustFS :9000"] ``` -The resource center stores workflow scripts, dependency JARs, and other files. With S3 storage every uploaded file becomes an object under `dolphinscheduler//resources/` in the bucket. +リソースセンターは、ワークフローのスクリプト、依存 JAR、その他のファイルを保存します。S3 ストレージでは、アップロードした各ファイルがバケット内の `dolphinscheduler//resources/` 配下のオブジェクトになります。 -## 1. Run the standalone server +## 1. スタンドアロンサーバーを実行する ```bash docker run -d --name dolphinscheduler --hostname dolphinscheduler \ @@ -25,11 +25,11 @@ docker run -d --name dolphinscheduler --hostname dolphinscheduler \ apache/dolphinscheduler-standalone-server:3.2.1 ``` -The single container bundles master, worker, API, alert, and an embedded ZooKeeper. The UI is at `http://localhost:12345/dolphinscheduler/ui` (default login `admin` / `dolphinscheduler123`). +単一のコンテナに master、worker、API、alert、組み込み ZooKeeper が含まれます。UI は `http://localhost:12345/dolphinscheduler/ui` です（既定のログインは `admin` / `dolphinscheduler123`）。 -## 2. Switch the resource center to RustFS +## 2. リソースセンターを RustFS に切り替える -The storage backend lives in `/opt/dolphinscheduler/conf/common.properties`. Append the S3 properties to the existing file — do not replace the file, it holds many other settings: +ストレージのバックエンドは `/opt/dolphinscheduler/conf/common.properties` にあります。既存ファイルへ S3 のプロパティを追記します。ファイルには他の設定も多数あるため、置き換えないでください。 ```bash docker exec dolphinscheduler bash -c "cat >> /opt/dolphinscheduler/conf/common.properties << 'EOF' @@ -45,15 +45,15 @@ EOF" docker restart dolphinscheduler ``` -Wait for the API to come back (about a minute), then create the bucket: +API が復帰するまで待ち（およそ 1 分）、その後バケットを作成します。 ```bash rc mb rustfs/ds-demo ``` -## 3. Upload a resource file +## 3. リソースファイルをアップロードする -Log in through the API to get a session id, then upload a file. The endpoint requires both `name` and `fullName` parameters: +API でログインしてセッション ID を取得し、ファイルをアップロードします。エンドポイントには `name` と `fullName` の両方のパラメーターが必要です。 ```bash printf "ds resource file stored in rustfs" > /tmp/ds-file.txt @@ -71,9 +71,9 @@ curl -s -m 30 -X POST "http://localhost:12345/dolphinscheduler/resources" \ {"code":0,"msg":"success","data":null,"failed":false,"success":true} ``` -## 4. Verify in DolphinScheduler and RustFS +## 4. DolphinScheduler と RustFS で確認する -Read the file back through the API: +API 経由でファイルを読み戻します。 ```bash curl -s -m 30 "http://localhost:12345/dolphinscheduler/resources/view-ui?fullName=/ds-file.txt&skipLineNum=100&limit=100" \ @@ -84,7 +84,7 @@ curl -s -m 30 "http://localhost:12345/dolphinscheduler/resources/view-ui?fullNam ds resource file stored in rustfs ``` -List the bucket — the file sits under the tenant's resources prefix: +バケットを一覧表示します。ファイルはテナントの resources プレフィックス配下にあります。 ```bash rc ls rustfs/ds-demo/ -r @@ -95,31 +95,31 @@ dolphinscheduler/default/resources/ds-file.txt dolphinscheduler/default/udfs/ ``` -![DolphinScheduler resources stored in the RustFS Console](./images/rustfs-ds-resources.png) +![RustFS Console に保存された DolphinScheduler のリソース](./images/rustfs-ds-resources.png) -## 5. Stop or reset +## 5. 停止またはリセット ```bash docker rm -f dolphinscheduler rc rm rustfs/ds-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Server fails to start with an Azure `clientId/tenantId/clientSecret` error +### Azure の `clientId/tenantId/clientSecret` エラーでサーバーが起動しない -The storage config was written as a brand-new file instead of appended, so `resource.storage.type=S3` was lost and the defaults pointed at Azure. Always append to the existing `common.properties` as in step 2. +ストレージ設定を追記せず新規ファイルとして書いたため、`resource.storage.type=S3` が失われ、既定値が Azure を向いたままです。手順 2 のとおり、必ず既存の `common.properties` へ追記します。 ### `Required request parameter 'name'/'fullName' is not present` -The resource create endpoint requires both `name` and `fullName` form fields alongside `file`, `type`, and `currentDir`. +リソース作成エンドポイントには、`file`、`type`、`currentDir` に加えて、`name` と `fullName` のフォームフィールドが両方必要です。 -### API returns 405 for the token call +### トークン呼び出しで API が 405 を返す -The login/token endpoints accept POST but `/api/v2/token` style endpoints differ per version — use the login form shown in step 3 and pass `session-id` header plus `Cookie: sessionId=...` on every call. +ログインおよびトークンのエンドポイントは POST を受け付けます。バージョンによって `/api/v2/token` 形式のエンドポイントは異なります。手順 3 のログインフォームを使い、すべての呼び出しで `session-id` ヘッダーと `Cookie: sessionId=...` を渡します。 -## Next steps +## 次のステップ -- Compare with the [Airflow](/developer/integration/big-data/airflow) guide for orchestration without a built-in resource center. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [DolphinScheduler documentation](https://dolphinscheduler.apache.org/en-us/docs/latest/user_doc/common/resource-management.html) to wire the same S3 resource center into worker task execution. +- 組み込みのリソースセンターを使わないオーケストレーションについては、[Airflow](/ja/developer/integration/big-data/airflow) のガイドと比較します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [DolphinScheduler ドキュメント](https://dolphinscheduler.apache.org/en-us/docs/latest/user_doc/common/resource-management.html)に従い、同じ S3 リソースセンターをワーカーのタスク実行へ接続します。 diff --git a/content/ja/developer/integration/big-data/flink.md b/content/ja/developer/integration/big-data/flink.md index 2181bd244..291c71147 100644 --- a/content/ja/developer/integration/big-data/flink.md +++ b/content/ja/developer/integration/big-data/flink.md @@ -239,7 +239,7 @@ RustFS コンソールでこのプレフィックスを参照することもで ## 6. RustFS S3 Tables を使用する -RustFS S3 Tables は組み込みの Apache Iceberg REST カタログを提供します。Flink はテーブルバケットを管理された Iceberg ウェアハウスとして扱え、データは RustFS 内に保持されます。[S3 Tables](/administration/data/s3-tables) の説明に従ってテーブルバケットを有効化し、Flink Iceberg コネクタの REST カタログを RustFS に向けてください。REST カタログ URI は `http://:9000/iceberg`、ウェアハウスはバケット名で、カタログリクエスト（AWS Signature Version 4、署名名 `s3`）と S3 ファイルアクセスの両方がパススタイルアクセスを使います。 +RustFS S3 Tables は組み込みの Apache Iceberg REST カタログを提供します。Flink はテーブルバケットを管理された Iceberg ウェアハウスとして扱え、データは RustFS 内に保持されます。[S3 Tables](/ja/administration/data/s3-tables) の説明に従ってテーブルバケットを有効化し、Flink Iceberg コネクタの REST カタログを RustFS に向けてください。REST カタログ URI は `http://:9000/iceberg`、ウェアハウスはバケット名で、カタログリクエスト（AWS Signature Version 4、署名名 `s3`）と S3 ファイルアクセスの両方がパススタイルアクセスを使います。 S3 Tables のサポートマトリックスに従い、本番でこの経路を採用する前に、実際にデプロイする Flink と Iceberg のバージョンでカタログを検証してください。 @@ -273,6 +273,6 @@ S3 プラグインは `flink-conf.yaml` の `s3.*` プロパティから認証 ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [Apache Flink ドキュメント](https://nightlies.apache.org/flink/flink-docs-stable/)で、パーティショニングやコンパクションなど filesystem コネクタのオプションを確認してください。 diff --git a/content/ja/developer/integration/big-data/hive.md b/content/ja/developer/integration/big-data/hive.md index e1d506726..dde0128cb 100644 --- a/content/ja/developer/integration/big-data/hive.md +++ b/content/ja/developer/integration/big-data/hive.md @@ -1,13 +1,13 @@ --- title: "Hive" -description: "Store Hive table data on RustFS over S3A." +description: "S3A 経由で Hive のテーブルデータを RustFS に保存します。" --- -This guide connects [Apache Hive](https://github.com/apache/hive) — the classic data warehouse — to **RustFS** through the S3A filesystem. You will run the Hive 4.0.1 Docker image with a metastore and HiveServer2, configure S3A in three configuration layers, create an external table over a RustFS location, and load and query data. The workflow was verified with Hive 4.0.1 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、従来型のデータウェアハウスである [Apache Hive](https://github.com/apache/hive) を、S3A ファイルシステムを通じて **RustFS** に接続します。メタストアと HiveServer2 を含む Hive 4.0.1 の Docker イメージを実行し、3 つの設定レイヤーで S3A を構成し、RustFS のロケーション上に外部テーブルを作成して、データのロードとクエリを行います。この流れは、Hive 4.0.1 を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Docker (two containers: metastore and hiveserver2). +Docker が必要です（コンテナは 2 つ、metastore と hiveserver2 です）。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,9 +16,9 @@ flowchart LR HS2 -->|"Tez tasks: S3A"| RustFS["RustFS :9000"] ``` -Hive stores table metadata in the metastore (Derby in this test) and table data in the table's S3A location. Query execution runs on Tez inside the hiveserver2 container. +Hive は、テーブルのメタデータをメタストア（この検証では Derby）に、テーブルデータをテーブルの S3A ロケーションに保存します。クエリの実行は hiveserver2 コンテナ内の Tez で行われます。 -## 1. Run the metastore and HiveServer2 +## 1. メタストアと HiveServer2 を実行する ```bash docker run -d --name hive-metastore --hostname hive-meta --network oo-rustfs_default \ @@ -28,11 +28,11 @@ docker run -d --name hive-server --hostname hive-server --network oo-rustfs_defa -e SERVICE_NAME=hiveserver2 -e DB_DRIVER=derby apache/hive:4.0.1 ``` -The metastore takes 1-2 minutes to initialize its Derby schema; HiveServer2 listens on 10000, the metastore on 9083. +メタストアが Derby スキーマを初期化するまで 1〜2 分かかります。HiveServer2 は 10000、メタストアは 9083 で待ち受けます。 -## 2. Configure S3A in three places +## 2. S3A を 3 箇所に設定する -Tez tasks read the Hadoop configuration directory, HiveServer2 reads the Hive configuration, and the metastore needs the endpoint too. Create one properties file and copy it to all three paths: +Tez のタスクは Hadoop の設定ディレクトリを読み、HiveServer2 は Hive の設定を読みます。メタストアにもエンドポイントが必要です。プロパティファイルを 1 つ作成し、3 つのパスすべてへコピーします。 ```xml title="s3a-core-site.xml" @@ -61,9 +61,9 @@ docker exec hive-server bash -c \ docker restart hive-server ``` -The `hadoop-aws` jar ships in `/opt/hadoop/share/hadoop/tools/lib` — the `HADOOP_CLASSPATH` export puts it on the query classpath. `mkdir /home/hive/.beeline` silences a harmless beeline home-directory error. +`hadoop-aws` の JAR は `/opt/hadoop/share/hadoop/tools/lib` に同梱されています。`HADOOP_CLASSPATH` の export により、クエリのクラスパスに載ります。`mkdir /home/hive/.beeline` は、無害な beeline のホームディレクトリエラーを抑止します。 -## 3. Create an external table +## 3. 外部テーブルを作成する ```bash docker exec hive-server bash -c "cd /opt/hive && beeline -u 'jdbc:hive2://localhost:10000' \ @@ -72,11 +72,11 @@ docker exec hive-server bash -c "cd /opt/hive && beeline -u 'jdbc:hive2://localh LOCATION 's3a://hive-demo/warehouse/events';\"" ``` -An `EXTERNAL` table with an S3A `LOCATION` keeps all data in RustFS. (A managed `CREATE TABLE ... LOCATION` on a non-default database path is rejected by Hive 4 managed-table rules — use external tables for S3A locations.) +S3A の `LOCATION` を持つ `EXTERNAL` テーブルは、すべてのデータを RustFS に保持します。（既定以外のデータベースパスに対する管理テーブルの `CREATE TABLE ... LOCATION` は、Hive 4 の管理テーブル規則により拒否されます。S3A のロケーションには外部テーブルを使います。） -## 4. Load and query data +## 4. データをロードしてクエリする -`LOAD DATA INPATH` moves a local file into the table's S3A location (the rename is executed by HiveServer2, which has the credentials): +`LOAD DATA INPATH` はローカルファイルをテーブルの S3A ロケーションへ移動します（リネームは、認証情報を持つ HiveServer2 が実行します）。 ```bash docker exec hive-server bash -c "printf '1,alpha\n2,beta\n3,gamma\n' > /tmp/hive-load.txt" @@ -88,7 +88,7 @@ docker exec hive-server bash -c "cd /opt/hive && beeline -u 'jdbc:hive2://localh INFO : Loading data to table default.events from file:/tmp/hive-load.txt ``` -## 5. Query and verify in RustFS +## 5. クエリし、RustFS で確認する ```bash docker exec hive-server bash -c "cd /opt/hive && beeline -u 'jdbc:hive2://localhost:10000' \ @@ -101,7 +101,7 @@ docker exec hive-server bash -c "cd /opt/hive && beeline -u 'jdbc:hive2://localh 3 gamma ``` -List the table directory — the loaded file is an ordinary object: +テーブルディレクトリを一覧表示します。ロードしたファイルは通常のオブジェクトです。 ```bash rc ls rustfs/hive-demo/warehouse/events/ @@ -113,35 +113,35 @@ warehouse/events/hive-load_copy_1.txt warehouse/events/hive-load_copy_2.txt ``` -![Hive warehouse files stored in the RustFS Console](./images/rustfs-hive-warehouse.png) +![RustFS Console に保存された Hive のウェアハウスファイル](./images/rustfs-hive-warehouse.png) -## 6. Stop or reset +## 6. 停止またはリセット ```bash docker rm -f hive-server hive-metastore rc rm rustfs/hive-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `NoClassDefFoundError: org.apache.tez.mapreduce.hadoop.InputSplitInfo` on INSERT +### INSERT 時の `NoClassDefFoundError: org.apache.tez.mapreduce.hadoop.InputSplitInfo` -The Tez jars are missing from the query classpath. Add the `HADOOP_CLASSPATH` export from step 2 (tools lib + tez + tez lib) to `/opt/hive/conf/hive-env.sh`. +クエリのクラスパスに Tez の JAR がありません。手順 2 の `HADOOP_CLASSPATH` の export（tools lib、tez、tez lib）を `/opt/hive/conf/hive-env.sh` に追加します。 ### `NoAwsCredentialsException: SimpleAWSCredentialsProvider: No AWS credentials in the Hadoop configuration` -Tez task processes read `/opt/hadoop/etc/hadoop/core-site.xml`, not only the Hive conf directory. Copy the S3A properties to all three paths from step 2. +Tez のタスクプロセスが読むのは Hive の設定ディレクトリだけではありません。`/opt/hadoop/etc/hadoop/core-site.xml` も読みます。手順 2 の 3 つのパスすべてに S3A プロパティをコピーします。 -### `Permission denied` printed after every beeline command +### beeline コマンドのたびに `Permission denied` が表示される -beeline tries to create `/home/hive/.beeline`. Run `mkdir -p /home/hive/.beeline && chmod 777` once (as root in the container). +beeline は `/home/hive/.beeline` の作成を試みます。コンテナ内で root として、`mkdir -p /home/hive/.beeline && chmod 777` を一度実行します。 ### `Unable to create database managed path file:/user/hive/warehouse/...` -Hive 4 keeps managed databases inside the managed warehouse root. Use `CREATE EXTERNAL TABLE ... LOCATION 's3a://...'` for S3A locations. +Hive 4 は管理データベースを、管理ウェアハウスのルート内に保持します。S3A のロケーションには `CREATE EXTERNAL TABLE ... LOCATION 's3a://...'` を使います。 -## Next steps +## 次のステップ -- Compare with the [Trino](/developer/integration/database/trino) guide when you want interactive SQL over the same objects without a metastore. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Hive documentation](https://hive.apache.org/) to attach a MySQL-backed metastore and share the same warehouse across Hive and Spark on the same bucket. +- メタストアなしで同じオブジェクトに対する対話的な SQL が必要な場合は、[Trino](/ja/developer/integration/database/trino) のガイドと比較します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [Hive ドキュメント](https://hive.apache.org/)に従い、MySQL をバックエンドにしたメタストアを接続し、同じバケット上のウェアハウスを Hive と Spark で共有します。 diff --git a/content/ja/developer/integration/big-data/hudi.md b/content/ja/developer/integration/big-data/hudi.md index 42026454b..9b8903364 100644 --- a/content/ja/developer/integration/big-data/hudi.md +++ b/content/ja/developer/integration/big-data/hudi.md @@ -1,24 +1,24 @@ --- title: "Apache Hudi" -description: "Write Apache Hudi tables to RustFS through Spark and the s3a connector." +description: "Spark と s3a コネクタを通じて、Apache Hudi テーブルを RustFS に書き込みます。" --- -This guide connects [Apache Hudi](https://github.com/apache/hudi) — the transactional data lake platform — to **RustFS** as its copy-on-write table store. You will run Spark with the Hudi bundle, write a table to the `s3a://` location inside a RustFS bucket, read it back, and verify the table files. The workflow was verified with `apache/spark:3.5.6`, `hudi-spark3.5-bundle_2.12:0.15.0`, `hadoop-aws:3.3.4`, and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、トランザクション型データレイク基盤である [Apache Hudi](https://github.com/apache/hudi) を、コピーオンライトのテーブルストアとして **RustFS** に接続します。Hudi バンドル付きの Spark を実行し、RustFS バケット内の `s3a://` ロケーションへテーブルを書き込み、読み戻してテーブルファイルを確認します。この流れは `apache/spark:3.5.6`、`hudi-spark3.5-bundle_2.12:0.15.0`、`hadoop-aws:3.3.4`、`rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR Job["Spark + Hudi"] -->|"commit + parquet"| RustFS["RustFS :9000"] ``` -Hudi stores the `.hoodie/` timeline, commit files, and Parquet data blocks under the table path in the bucket. Reads resolve the latest table snapshot from the timeline, so every write and query goes through the S3 API. +Hudi は、バケット内のテーブルパス配下に `.hoodie/` タイムライン、コミットファイル、Parquet データブロックを保存します。読み取りはタイムラインから最新のテーブルスナップショットを解決するため、すべての書き込みとクエリは S3 API を経由します。 -## 1. Run the Spark write +## 1. Spark の書き込みを実行する -Hudi requires the Kryo serializer and the s3a credentials as Hadoop properties. The following `spark-shell` session creates a non-partitioned table in `my-bucket` — replace all connection placeholders: +Hudi では Kryo シリアライザーと s3a の認証情報を Hadoop プロパティとして指定する必要があります。次の `spark-shell` セッションは `my-bucket` に非パーティションテーブルを作成します。接続用のプレースホルダーはすべて置き換えます。 ```scala import org.apache.spark.sql.SaveMode @@ -52,7 +52,7 @@ docker run --rm --network oo-rustfs_default \ -i /tmp/hudi_test.scala ``` -The `--packages` flags download the Hudi bundle and the s3a connector on first run. The `spark.jars.ivy` setting avoids Ivy cache permission errors in the container. The read-back `show()` prints the three rows: +`--packages` フラグは、初回実行時に Hudi バンドルと s3a コネクタをダウンロードします。`spark.jars.ivy` は、コンテナ内の Ivy キャッシュ権限エラーを避けます。読み戻しの `show()` は次の 3 行を出力します。 ```text +---+----+ @@ -62,15 +62,15 @@ The `--packages` flags download the Hudi bundle and the s3a connector on first r +---+----+ ``` -## 2. Verify objects in RustFS +## 2. RustFS 内のオブジェクトを確認する -List the table prefix: +テーブルのプレフィックスを一覧します。 ```bash rc ls rustfs/my-bucket/hudi-demo/ -r ``` -The Hudi table layout appears under the table path — the `.hoodie/` timeline with the commit file, plus the Parquet data block: +Hudi のテーブルレイアウトはテーブルパス配下に現れます。コミットファイルを含む `.hoodie/` タイムラインと、Parquet データブロックです。 ```text hudi-demo/events/.hoodie/20260922015803291.commit @@ -78,32 +78,32 @@ hudi-demo/events/.hoodie/20260922015803291.commit.requested hudi-demo/events/// ``` -![Hudi table files stored in the RustFS Console](./images/rustfs-hudi-table.png) +![RustFS Console に保存された Hudi テーブルファイル](./images/rustfs-hudi-table.png) -## 3. Stop or reset +## 3. 停止またはリセットする -Spark runs as a one-shot client and holds no state. To delete the demo table: +Spark はワンショットのクライアントとして動作し、状態を保持しません。デモテーブルを削除します。 ```bash rc rm rustfs/my-bucket/hudi-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `hoodie only support org.apache.spark.serializer.KryoSerializer as spark.serializer` -Hudi rejects the default Spark serializer. Pass `--conf spark.serializer=org.apache.spark.serializer.KryoSerializer` as shown above. +Hudi は Spark のデフォルトシリアライザーを拒否します。上記のとおり `--conf spark.serializer=org.apache.spark.serializer.KryoSerializer` を渡します。 -### `Partition-path field has to be non-empty` or keygenerator class errors +### `Partition-path field has to be non-empty` または keygenerator クラスのエラー -For a non-partitioned table, keep the default key generator (do not set `hoodie.datasource.write.keygenerator.class`) and set `hoodie.datasource.write.partitionpath.field` to the empty string. +非パーティションテーブルでは、デフォルトのキージェネレーターを維持します（`hoodie.datasource.write.keygenerator.class` は設定しません）。`hoodie.datasource.write.partitionpath.field` は空文字列にします。 -### `NoSuchMethodError` or `ClassNotFoundException` in the Hudi write +### Hudi の書き込みで `NoSuchMethodError` または `ClassNotFoundException` が出る -The Spark and Hudi bundle versions must match: `hudi-spark3.5-bundle_2.12` goes with Spark 3.5.x, and the bundled Hadoop client must be compatible with `hadoop-aws:3.3.4`. +Spark と Hudi バンドルのバージョンは一致している必要があります。`hudi-spark3.5-bundle_2.12` は Spark 3.5.x と組み合わせ、同梱の Hadoop クライアントは `hadoop-aws:3.3.4` と互換である必要があります。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Hudi operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Hudi Spark guide](https://hudi.apache.org/docs/quick-start-guide/) to add upserts, compaction, and query integrations on the same table. +- 追加の Hudi 操作を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- [Hudi Spark ガイド](https://hudi.apache.org/docs/quick-start-guide/)に従い、同じテーブルへ upsert、コンパクション、クエリ連携を追加します。 diff --git a/content/ja/developer/integration/big-data/iceberg.md b/content/ja/developer/integration/big-data/iceberg.md index 6b9741a23..5b8f54ee6 100644 --- a/content/ja/developer/integration/big-data/iceberg.md +++ b/content/ja/developer/integration/big-data/iceberg.md @@ -5,7 +5,7 @@ description: "Docker Compose を使い、Spark、REST カタログ、RustFS の このガイドでは、Spark、Iceberg REST カタログ、S3 互換ウェアハウスとしての **RustFS** を用いて **Apache Iceberg** を実行します。Iceberg テーブルを作成し、行を書き込み、問い合わせ、テーブルファイルが RustFS に保存されていることを確認します。 -RustFS の組み込み REST カタログを使う場合は、[S3 Tables の設定](/administration/data/s3-tables)と [PyIceberg ガイド](/developer/integration/big-data/pyiceberg)を参照してください。以下の構成では、別のカタログサービスを起動します。 +RustFS の組み込み REST カタログを使う場合は、[S3 Tables の設定](/ja/administration/data/s3-tables)と [PyIceberg ガイド](/ja/developer/integration/big-data/pyiceberg)を参照してください。以下の構成では、別のカタログサービスを起動します。 Docker と Compose プラグイン、および 4 つのコンテナを動かすだけのローカルリソースが必要です。この構成はローカルの連携テスト向けであり、本番向けではありません。 @@ -270,6 +270,6 @@ REST カタログのプロパティでは、`CATALOG_IO__IMPL` と `CATALOG_S3_P ## 次のステップ -- ほかの Iceberg 操作を採用する前に、[S3 互換性に関する注意](/administration/protocols/s3)を確認します。 -- [アクセスキーの管理](/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- ほかの Iceberg 操作を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 - 既存の Spark 環境を設定するには、[Apache Iceberg の Spark ドキュメント](https://iceberg.apache.org/docs/latest/spark-getting-started/)に従ってください。 diff --git a/content/ja/developer/integration/big-data/kafka.md b/content/ja/developer/integration/big-data/kafka.md index ff1e92f9f..079ba9836 100644 --- a/content/ja/developer/integration/big-data/kafka.md +++ b/content/ja/developer/integration/big-data/kafka.md @@ -1,15 +1,15 @@ --- title: "Kafka" -description: "Offload Kafka topic data to RustFS with the Kafka Connect S3 sink connector." +description: "Kafka Connect の S3 シンクコネクタを使い、Kafka トピックのデータを RustFS へオフロードします。" --- -This guide connects [Apache Kafka](https://github.com/apache/kafka) — the distributed event streaming platform — to **RustFS** through the Kafka Connect S3 sink connector. You will run a KRaft broker and a Connect worker, deploy the S3 sink for a topic, and produce records that land as objects in a RustFS bucket. The workflow was verified with `apache/kafka:4.0.0` and `confluentinc/kafka-connect-s3` v10.5.25 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、分散イベントストリーミング基盤である [Apache Kafka](https://github.com/apache/kafka) を、Kafka Connect の S3 シンクコネクタを通じて **RustFS** に接続します。KRaft ブローカーと Connect ワーカーを実行し、トピック向けに S3 シンクをデプロイして、レコードを生成し RustFS バケット内のオブジェクトとして書き込みます。この流れは `apache/kafka:4.0.0`、`confluentinc/kafka-connect-s3` v10.5.25、`rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -Kafka's KIP-405 tiered storage needs a `RemoteLogStorageManager` plugin, and the S3 implementations in the ecosystem are vendor-proprietary. The Connect S3 sink is the open, self-hosted way to move topic data to S3-compatible storage and is the approach documented here. +Kafka の KIP-405 ティアードストレージには `RemoteLogStorageManager` プラグインが必要で、エコシステムにある S3 実装はベンダー独自です。Connect の S3 シンクは、トピックデータを S3 互換ストレージへ移すオープンでセルフホストの方法であり、このガイドで説明する方式です。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -18,11 +18,11 @@ flowchart LR Connect -->|"batched objects"| RustFS["RustFS :9000"] ``` -The sink task consumes a topic in a dedicated consumer group and writes record batches to the bucket, one object per `flush.size` records per partition. +シンクタスクは専用のコンシューマーグループでトピックを消費し、パーティションごとに `flush.size` 件のレコードを 1 オブジェクトとしてバケットへ書き込みます。 -## 1. Run the broker +## 1. ブローカーを実行する -Start a KRaft broker whose advertised listener is reachable from other containers: +他のコンテナから到達できるよう、アドバタイズするリスナーを設定した KRaft ブローカーを起動します。 ```bash docker run -d --name kafka --hostname kafka --network oo-rustfs_default \ @@ -46,20 +46,20 @@ docker exec kafka /opt/kafka/bin/kafka-topics.sh \ rc mb rustfs/kafka-demo ``` -The image defaults to advertising `localhost:9092`, which only works from inside the broker container. The `KAFKA_ADVERTISED_LISTENERS` override is what makes Connect (and any remote client) able to reach the broker. +イメージはデフォルトで `localhost:9092` をアドバタイズしますが、これはブローカーコンテナの内部からしか使えません。`KAFKA_ADVERTISED_LISTENERS` の上書きにより、Connect（およびリモートクライアント）がブローカーへ到達できます。 -## 2. Install the connector +## 2. コネクタをインストールする -Download the Confluent Hub archive, which bundles the connector and its dependencies, and unpack it where the worker can see it: +コネクタと依存関係をまとめた Confluent Hub のアーカイブをダウンロードし、ワーカーから見える場所へ展開します。 ```bash curl -Lo kafka-connect-s3.zip "https://hub-downloads.confluent.io/api/plugins/confluentinc/kafka-connect-s3/versions/10.5.25/confluentinc-kafka-connect-s3-10.5.25.zip" unzip kafka-connect-s3.zip -d /opt/kafka-conn/plugins ``` -## 3. Configure the worker and the sink +## 3. ワーカーとシンクを設定する -Create the worker properties. The value converter must be `ByteArrayConverter` so records are written verbatim: +ワーカーのプロパティを作成します。レコードをそのまま書き込むため、値コンバーターは `ByteArrayConverter` である必要があります。 ```ini title="worker.properties" bootstrap.servers=kafka:9092 @@ -70,7 +70,7 @@ offset.flush.interval.ms=5000 plugin.path=/opt/kafka-conn-plugins ``` -Create the sink connector configuration, replacing all connection placeholders: +接続用のプレースホルダーをすべて置き換え、シンクコネクタの設定を作成します。 ```ini title="rustfs-sink.properties" name=rustfs-sink @@ -87,11 +87,11 @@ format.class=io.confluent.connect.s3.format.bytearray.ByteArrayFormat consumer.override.auto.offset.reset=earliest ``` -Kafka 4.0 moved the class to `org.apache.kafka.connect.converters.ByteArrayConverter` — the old `storage` package path no longer resolves. +Kafka 4.0 ではクラスが `org.apache.kafka.connect.converters.ByteArrayConverter` に移りました。以前の `storage` パッケージパスは解決できなくなっています。 -## 4. Run the worker +## 4. ワーカーを実行する -Run `connect-standalone` in the foreground so its logs go to `docker logs`, with the bucket credentials in the environment: +ログが `docker logs` に出るよう、`connect-standalone` をフォアグラウンドで実行します。バケットの認証情報は環境変数で渡します。 ```bash docker run -d --name kafka-connect --hostname kafka-connect \ @@ -105,22 +105,22 @@ docker run -d --name kafka-connect --hostname kafka-connect \ /opt/kafka/bin/connect-standalone.sh /etc/kafka/worker.properties /etc/kafka/sink.properties ``` -The worker is ready when the sink task claims the partition: +シンクタスクがパーティションを取得すると、ワーカーの準備は完了です。 ```text INFO [rustfs-sink|task-0] Assigned topic partitions: [rustfs-topic-0] ``` -## 5. Produce records +## 5. レコードを生成する -Send at least `flush.size` records so the connector completes a batch: +コネクタがバッチを完了できるよう、少なくとも `flush.size` 件のレコードを送ります。 ```bash docker exec kafka sh -c "printf 'msg-one\nmsg-two\nmsg-three\n' | \ /opt/kafka/bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic rustfs-topic" ``` -After a few seconds the batch becomes an object in the bucket: +数秒後、バッチはバケット内のオブジェクトになります。 ```bash rc ls rustfs/kafka-demo/ -r @@ -135,44 +135,44 @@ msg-two msg-three ``` -The object name encodes topic, partition, and starting offset. Each subsequent batch of three records lands in the next object (`+0000000003.bin` and so on). +オブジェクト名にはトピック、パーティション、開始オフセットが入ります。続く 3 件ずつのバッチは次のオブジェクト（`+0000000003.bin` 以降）に書き込まれます。 -![Kafka sink objects stored in the RustFS Console](./images/rustfs-kafka-sink.png) +![RustFS Console に保存された Kafka シンクのオブジェクト](./images/rustfs-kafka-sink.png) -## 6. Stop or reset +## 6. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを撤去します。 ```bash docker rm -f kafka-connect kafka ``` -To delete the stored data: +保存したデータを削除します。 ```bash rc rm rustfs/kafka-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `AdminClient ... Rebootstrapping with Cluster (id: null)` loops forever +### `AdminClient ... Rebootstrapping with Cluster (id: null)` が無限に繰り返される -The broker advertises `localhost:9092`, so a remote client receives metadata pointing at itself. Set `KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092` (and matching listener variables) as in step 1. +ブローカーが `localhost:9092` をアドバタイズしているため、リモートクライアントは自分自身を指すメタデータを受け取ります。手順 1 のとおり `KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092`（と対応するリスナー変数）を設定します。 ### `Invalid schema type for ByteArrayConverter: STRING` -The `ByteArrayFormat` writer only accepts raw bytes. Either switch the worker's `value.converter` to the ByteArray converter or choose a format class that matches the converter you use. +`ByteArrayFormat` ライターは生のバイトだけを受け付けます。ワーカーの `value.converter` を ByteArray コンバーターに切り替えるか、使用するコンバーターに合うフォーマットクラスを選びます。 ### `Class org.apache.kafka.connect.storage.ByteArrayConverter could not be found` -Kafka 4.0 moved the class to `org.apache.kafka.connect.converters.ByteArrayConverter`. Use the new package path in `worker.properties`. +Kafka 4.0 ではクラスが `org.apache.kafka.connect.converters.ByteArrayConverter` に移りました。`worker.properties` では新しいパッケージパスを使います。 -### The connector downloads but the plugin is not found +### コネクタはダウンロードされるがプラグインが見つからない -The plain connector JAR from Maven lacks its dependencies. Use the Confluent Hub archive from step 2, which bundles the complete `lib/` directory, and make sure `plugin.path` points at the directory that contains the connector folder. +Maven のコネクタ JAR 単体には依存関係が含まれません。手順 2 の Confluent Hub アーカイブを使い、完全な `lib/` ディレクトリをまとめて配置します。`plugin.path` はコネクタフォルダーを含むディレクトリを指す必要があります。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional connectors. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Kafka Connect S3 sink documentation](https://docs.confluent.io/kafka-connect-s3/current/index.html) for Parquet and Avro formats, partitioning by time, and IAM-based credential chains. +- 追加のコネクタを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- Parquet と Avro のフォーマット、時刻によるパーティショニング、IAM ベースの認証情報チェーンについては、[Kafka Connect S3 シンクのドキュメント](https://docs.confluent.io/kafka-connect-s3/current/index.html)に従います。 diff --git a/content/ja/developer/integration/big-data/paimon.md b/content/ja/developer/integration/big-data/paimon.md index f8f542656..8ded2b646 100644 --- a/content/ja/developer/integration/big-data/paimon.md +++ b/content/ja/developer/integration/big-data/paimon.md @@ -1,13 +1,13 @@ --- title: "Paimon" -description: "Run Paimon lakehouse tables on RustFS with Spark." +description: "Spark を使い、RustFS 上で Paimon のレイクハウステーブルを実行します。" --- -This guide connects [Apache Paimon](https://github.com/apache/paimon) — the streaming lakehouse table format — to **RustFS** as its warehouse storage. You will create a Paimon catalog over a RustFS bucket with Spark, write a primary-key table, and read it back. The workflow was verified with Paimon 1.2.0 on Spark 3.5.6 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、ストリーミングレイクハウスのテーブルフォーマットである [Apache Paimon](https://github.com/apache/paimon) を、ウェアハウスストレージとして **RustFS** に接続します。Spark で RustFS バケット上に Paimon カタログを作成し、主キーテーブルを書き込んで読み戻します。この流れは Spark 3.5.6 上の Paimon 1.2.0 と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker and the `rc` client. +Docker と `rc` クライアントが必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,9 +15,9 @@ flowchart LR Paimon -->|"schemas, snapshots, data files"| RustFS["RustFS :9000"] ``` -Paimon stores each table under the catalog warehouse as a `*.db` directory containing `schema/`, `snapshot/`, and data files. All I/O goes through Paimon's own S3 FileIO (`paimon-s3`), not Hadoop S3A. +Paimon はカタログのウェアハウス配下に、各テーブルを `schema/`、`snapshot/`、データファイルを含む `*.db` ディレクトリとして保存します。入出力はすべて Paimon 自身の S3 FileIO（`paimon-s3`）を経由し、Hadoop S3A は使いません。 -## 1. Run Spark +## 1. Spark を実行する ```bash docker run -d --name spark-paimon --hostname spark --network oo-rustfs_default \ @@ -25,7 +25,7 @@ docker run -d --name spark-paimon --hostname spark --network oo-rustfs_default \ docker cp paimon_test.sql spark-paimon:/tmp/paimon_test.sql ``` -Create the SQL file (note: the catalog options are passed on the CLI below, not in the file): +SQL ファイルを作成します（カタログオプションはファイル内ではなく、後述の CLI で渡します）。 ```sql title="paimon_test.sql" CREATE TABLE paimon.default.events (id INT, label STRING) TBLPROPERTIES ("primary-key"="id"); @@ -33,9 +33,9 @@ INSERT INTO paimon.default.events VALUES (1,'alpha'),(2,'beta'),(3,'gamma'); SELECT * FROM paimon.default.events ORDER BY id; ``` -## 2. Run the SQL script +## 2. SQL スクリプトを実行する -Three pieces are required: the Spark extensions, Paimon's own S3 FileIO (`paimon-s3` — the Hadoop S3A jars are not used by Paimon's reader), and the catalog-level `s3.*` options: +必要なものは 3 つです。Spark 拡張、Paimon 自身の S3 FileIO（`paimon-s3`。Paimon のリーダーは Hadoop S3A の JAR を使いません）、カタログレベルの `s3.*` オプションです。 ```bash docker exec -u root spark-paimon bash -c "cd /opt/spark && \ @@ -59,9 +59,9 @@ Time taken: 9.447 seconds Time taken: 1.257 seconds, Fetched 3 row(s) ``` -Without the extensions line Paimon fails fast with a `requiredSparkConfsCheck` error; without `paimon-s3` the catalog fails with `UnsupportedSchemeException: Could not find a file io implementation for scheme 's3'`. +拡張の行がないと Paimon は `requiredSparkConfsCheck` エラーで即座に失敗します。`paimon-s3` がないと、カタログは `UnsupportedSchemeException: Could not find a file io implementation for scheme 's3'` で失敗します。 -## 3. Verify objects in RustFS +## 3. RustFS 内のオブジェクトを確認する ```bash rc ls rustfs/paimon-demo/warehouse/ -r | head -6 @@ -74,37 +74,37 @@ warehouse/default.db/events/bucket-0/data-... warehouse/default.db/events/manifest/... ``` -The bucket holds the full lakehouse layout: schemas, snapshots, manifests, and data files per bucket. +S3 バケットには、スキーマ、スナップショット、マニフェスト、Paimon バケットごとのデータファイルを含むレイクハウスのレイアウト全体が入ります。 -![Paimon warehouse stored in the RustFS Console](./images/rustfs-paimon-warehouse.png) +![RustFS Console に保存された Paimon ウェアハウス](./images/rustfs-paimon-warehouse.png) -## 4. Stop or reset +## 4. 停止またはリセットする ```bash docker rm -f spark-paimon rc rm rustfs/paimon-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `UnsupportedSchemeException: Could not find a file io implementation for scheme 's3'` -Paimon's own FileIO needs its S3 plugin on the classpath. Add `org.apache.paimon:paimon-s3:1.2.0` to `--packages` alongside the Spark connector. +Paimon 自身の FileIO には、クラスパス上の S3 プラグインが必要です。Spark コネクタとあわせて `--packages` に `org.apache.paimon:paimon-s3:1.2.0` を追加します。 ### `When using Paimon, it is necessary to configure spark.sql.extensions...` -Add `--conf spark.sql.extensions=org.apache.paimon.spark.extensions.PaimonSparkSessionExtensions` — Paimon fails fast without it. +`--conf spark.sql.extensions=org.apache.paimon.spark.extensions.PaimonSparkSessionExtensions` を追加します。これがないと Paimon は即座に失敗します。 ### `SCHEMA_NOT_FOUND: The schema paimon cannot be found` -The catalog was not registered. Register it as `spark.sql.catalog.paimon` and qualify table names with `paimon.`. +カタログが登録されていません。`spark.sql.catalog.paimon` として登録し、テーブル名は `paimon.` で修飾します。 -### Writes fail with S3 errors on the exec side +### エグゼキューター側の S3 エラーで書き込みが失敗する -The catalog-level `s3.*` options (`s3.endpoint`, `s3.access-key`, `s3.secret-key`, `s3.path-style-access`) are what Paimon's FileIO reads — Hadoop `fs.s3a.*` settings alone are not used by the exec-side file operations. +Paimon の FileIO が読むのはカタログレベルの `s3.*` オプション（`s3.endpoint`、`s3.access-key`、`s3.secret-key`、`s3.path-style-access`）です。Hadoop の `fs.s3a.*` 設定だけでは、エグゼキューター側のファイル操作には使われません。 -## Next steps +## 次のステップ -- Compare with the [Iceberg](/developer/integration/big-data/iceberg), [Hudi](/developer/integration/big-data/hudi), and [Delta Lake](/developer/integration/big-data/delta-lake) guides for the other lakehouse formats on the same bucket. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Paimon documentation](https://paimon.apache.org/docs/master/) for compaction, changelog producers, and Flink streaming writes on the same bucket. +- 同じバケット上のほかのレイクハウスフォーマットについては、[Iceberg](/ja/developer/integration/big-data/iceberg)、[Hudi](/ja/developer/integration/big-data/hudi)、[Delta Lake](/ja/developer/integration/big-data/delta-lake) のガイドと比較します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- 同じバケット上でコンパクション、changelog プロデューサー、Flink のストリーミング書き込みを設定するには、[Paimon ドキュメント](https://paimon.apache.org/docs/master/)に従います。 diff --git a/content/ja/developer/integration/big-data/pyiceberg.md b/content/ja/developer/integration/big-data/pyiceberg.md index 576768dc3..d57f5792e 100644 --- a/content/ja/developer/integration/big-data/pyiceberg.md +++ b/content/ja/developer/integration/big-data/pyiceberg.md @@ -7,7 +7,7 @@ description: "PyIceberg を使用して、RustFS S3 Tables の REST カタログ ## 前提条件 -- [S3 Tables の設定](/administration/data/s3-tables)を完了し、`my-bucket` を作成して有効にします。アカウントと TLS の要件も満たしてください。 +- [S3 Tables の設定](/ja/administration/data/s3-tables)を完了し、`my-bucket` を作成して有効にします。アカウントと TLS の要件も満たしてください。 - そのガイドで設定した `RUSTFS_ENDPOINT`、`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、`AWS_DEFAULT_REGION` を維持します。 ## 1. クライアントをインストールする @@ -159,7 +159,7 @@ PY :::note[カタログエントリのみを削除] -以下のコマンドは、このチュートリアルのテーブルエントリと、削除後に空になる名前空間を削除します。バケットと基になるオブジェクトは残ります。データのクリーンアップが必要な場合は、実行前に計画してください。`drop_table` の後は、テーブルメンテナンスでテーブルを見つけられなくなります。[メンテナンスとデータ保護](/administration/data/s3-tables)を参照してください。 +以下のコマンドは、このチュートリアルのテーブルエントリと、削除後に空になる名前空間を削除します。バケットと基になるオブジェクトは残ります。データのクリーンアップが必要な場合は、実行前に計画してください。`drop_table` の後は、テーブルメンテナンスでテーブルを見つけられなくなります。[メンテナンスとデータ保護](/ja/administration/data/s3-tables)を参照してください。 ::: @@ -175,4 +175,4 @@ PY ## 次のステップ - クライアント操作は [PyIceberg API ドキュメント](https://py.iceberg.apache.org/api/)を参照し、各操作が RustFS のサポート範囲に含まれるか確認します。 -- 別のカタログサービスを管理している場合は、[外部 Iceberg カタログとの連携](/developer/integration/big-data/iceberg)を使用します。 +- 別のカタログサービスを管理している場合は、[外部 Iceberg カタログとの連携](/ja/developer/integration/big-data/iceberg)を使用します。 diff --git a/content/ja/developer/integration/big-data/seatunnel.md b/content/ja/developer/integration/big-data/seatunnel.md index 0d1ebf67a..b192038ad 100644 --- a/content/ja/developer/integration/big-data/seatunnel.md +++ b/content/ja/developer/integration/big-data/seatunnel.md @@ -1,13 +1,13 @@ --- title: "SeaTunnel" -description: "Move data between SeaTunnel and RustFS with the S3File connector." +description: "S3File コネクタを使い、SeaTunnel と RustFS の間でデータを移動します。" --- -This guide connects [Apache SeaTunnel](https://github.com/apache/seatunnel) — the data integration engine — to **RustFS** through the S3File connector. You will run a batch job that generates rows with FakeSource and writes them as JSON files into a RustFS bucket. The workflow was verified with SeaTunnel 2.3.12 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、データ統合エンジンである [Apache SeaTunnel](https://github.com/apache/seatunnel) を、S3File コネクタを通じて **RustFS** に接続します。FakeSource で行を生成し、JSON ファイルとして RustFS バケットへ書き込むバッチジョブを実行します。この流れは SeaTunnel 2.3.12 と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker and the `rc` client. +Docker と `rc` クライアントが必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR Job -->|"S3File sink"| RustFS["RustFS :9000"] ``` -The S3File sink writes through the Hadoop S3A filesystem, so the connector accepts both its own credential options and the standard `fs.s3a.*` Hadoop keys. +S3File シンクは Hadoop S3A ファイルシステム経由で書き込むため、コネクタ独自の認証情報オプションと、標準の `fs.s3a.*` Hadoop キーの両方を受け付けます。 -## 1. Run the engine +## 1. エンジンを実行する -The connector and the Hadoop AWS jars ship inside the image: +コネクタと Hadoop AWS の JAR はイメージに同梱されています。 ```bash docker run --rm apache/seatunnel:2.3.12 \ @@ -31,9 +31,9 @@ connector-file-s3-2.3.12.jar seatunnel-hadoop-aws.jar ``` -## 2. Write the job config +## 2. ジョブ設定を書く -The tricky part: the sink validates `access_key`/`secret_key` at compile time, while the actual S3A client reads the `fs.s3a.*` keys. Provide both, and keep the endpoint without a scheme — the bundled Hadoop version rejects `http://` endpoints: +注意点は次のとおりです。シンクはコンパイル時に `access_key` と `secret_key` を検証しますが、実際の S3A クライアントが読むのは `fs.s3a.*` キーです。両方を指定し、エンドポイントはスキームなしにします。同梱の Hadoop バージョンは `http://` のエンドポイントを拒否します。 ```text title="seatunnel-rustfs.conf" env { @@ -71,7 +71,7 @@ sink { } ``` -## 3. Run the job +## 3. ジョブを実行する ```bash docker run --rm --network oo-rustfs_default \ @@ -84,7 +84,7 @@ docker run --rm --network oo-rustfs_default \ 2026-10-07 ... INFO ... Submit job finished, job id: 1159846059493556225 ``` -## 4. Verify objects in RustFS +## 4. RustFS 内のオブジェクトを確認する ```bash rc ls rustfs/seatunnel-demo/out/ @@ -96,38 +96,38 @@ out/T_1159846059493556225_2de3d99235_0_1_0.json {"id":168282592,"name":"ELyqD","value":1.594479327987022E308} ``` -Five FakeSource rows landed as one JSON file in the bucket. +FakeSource の 5 行が、バケット内の 1 つの JSON ファイルになりました。 -![SeaTunnel output files stored in the RustFS Console](./images/rustfs-seatunnel-out.png) +![RustFS Console に保存された SeaTunnel の出力ファイル](./images/rustfs-seatunnel-out.png) -## 5. Stop or reset +## 5. 停止またはリセットする -SeaTunnel in `-e local` mode is stateless. To delete the output: +`-e local` モードの SeaTunnel はステートレスです。出力を削除します。 ```bash rc rm rustfs/seatunnel-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `Plugin PluginIdentifier{... pluginName='S3'} not found` -The sink class is registered as `S3File`, not `S3`. +シンククラスは `S3` ではなく `S3File` として登録されています。 ### `There are unconfigured options, the options('access_key', 'secret_key') are required` -The S3File sink requires its own `access_key`/`secret_key` options even when `fs.s3a.*` keys are present. Provide both sets as in step 2. +`fs.s3a.*` キーがあっても、S3File シンクには独自の `access_key` と `secret_key` オプションが必要です。手順 2 のとおり両方の組を指定します。 ### `No AWS Credentials provided by InstanceProfileCredentialsProvider` -The S3A client on the coordinator side fell back to the instance-profile provider because `fs.s3a.aws.credentials.provider` and the `fs.s3a.access.key`/`fs.s3a.secret.key` pair were missing. Add all three as in step 2. +コーディネーター側の S3A クライアントは、`fs.s3a.aws.credentials.provider` と `fs.s3a.access.key` / `fs.s3a.secret.key` の組が無いため、インスタンスプロファイルのプロバイダーへフォールバックしました。手順 2 のとおり 3 つすべてを追加します。 -### Job hangs on `doesBucketExist` +### `doesBucketExist` でジョブがハングする -The bundled Hadoop version rejects `http://` scheme endpoints. Use the bare `host:port` form for `fs.s3a.endpoint` and add `fs.s3a.connection.ssl.enabled = "false"`. +同梱の Hadoop バージョンは `http://` スキームのエンドポイントを拒否します。`fs.s3a.endpoint` には `host:port` 形式だけを使い、`fs.s3a.connection.ssl.enabled = "false"` を追加します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional SeaTunnel connectors. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [SeaTunnel S3File documentation](https://seatunnel.apache.org/docs/connector-v2/sink/S3File) for parquet/orc formats, partitioned writes, and the matching S3File source. +- 追加の SeaTunnel コネクタを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- Parquet / ORC フォーマット、パーティション書き込み、対応する S3File ソースについては、[SeaTunnel S3File のドキュメント](https://seatunnel.apache.org/docs/connector-v2/sink/S3File)に従います。 diff --git a/content/ja/developer/integration/big-data/spark.md b/content/ja/developer/integration/big-data/spark.md index c63e49a38..d3c41daa7 100644 --- a/content/ja/developer/integration/big-data/spark.md +++ b/content/ja/developer/integration/big-data/spark.md @@ -177,7 +177,7 @@ RustFS コンソールでこのプレフィックスを参照することもで ## 4. RustFS S3 Tables を使用する -RustFS S3 Tables は組み込みの Apache Iceberg REST カタログを提供します。Flink と同様に、Spark はテーブルバケットを管理された Iceberg ウェアハウスとして扱え、データは RustFS 内に保持されます。[S3 Tables](/administration/data/s3-tables) の説明に従ってテーブルバケットを有効化し、Spark の Iceberg REST カタログを接続してください。REST カタログ URI は `http://:9000/iceberg`、ウェアハウスはバケット名で、カタログリクエスト（AWS Signature Version 4、署名名 `s3`）と S3 ファイルアクセスの両方がパススタイルアクセスを使います。 +RustFS S3 Tables は組み込みの Apache Iceberg REST カタログを提供します。Flink と同様に、Spark はテーブルバケットを管理された Iceberg ウェアハウスとして扱え、データは RustFS 内に保持されます。[S3 Tables](/ja/administration/data/s3-tables) の説明に従ってテーブルバケットを有効化し、Spark の Iceberg REST カタログを接続してください。REST カタログ URI は `http://:9000/iceberg`、ウェアハウスはバケット名で、カタログリクエスト（AWS Signature Version 4、署名名 `s3`）と S3 ファイルアクセスの両方がパススタイルアクセスを使います。 S3 Tables のサポートマトリックスに従い、本番でこの経路を採用する前に、実際にデプロイする Spark と Iceberg のバージョンでカタログを検証してください。 @@ -215,6 +215,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [Spark ドキュメント](https://spark.apache.org/docs/latest/)で構造化ストリーミングやデータソースのオプションを確認してください。 diff --git a/content/ja/developer/integration/big-data/zeppelin.md b/content/ja/developer/integration/big-data/zeppelin.md index e7f47375e..7a54de25c 100644 --- a/content/ja/developer/integration/big-data/zeppelin.md +++ b/content/ja/developer/integration/big-data/zeppelin.md @@ -1,13 +1,13 @@ --- title: "Apache Zeppelin" -description: "Store Apache Zeppelin notebooks in RustFS through the S3 notebook repository." +description: "S3 ノートブックリポジトリを通じて、Apache Zeppelin のノートブックを RustFS に保存します。" --- -This guide connects [Apache Zeppelin](https://github.com/apache/zeppelin) — the web-based notebook for data analytics — to **RustFS** through Zeppelin's S3 notebook storage. You will start Zeppelin pointed at a RustFS bucket, create a note, and verify that the notebook file is stored in RustFS and survives a restart. The workflow was verified with `apache/zeppelin:0.12.0` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、データ分析向けの Web ベースのノートブックである [Apache Zeppelin](https://github.com/apache/zeppelin) を、Zeppelin の S3 ノートブックストレージを通じて **RustFS** に接続します。RustFS バケットを指すように Zeppelin を起動し、ノートを作成して、ノートブックファイルが RustFS に保存され再起動後も残ることを確認します。この流れは `apache/zeppelin:0.12.0` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,18 +15,18 @@ flowchart LR Z -->|".zpln files"| RustFS["RustFS :9000"] ``` -With the `S3NotebookRepo` storage class, every note is persisted as a `.zpln` JSON file under the `user/notebook/` prefix of the bucket. Zeppelin reads and writes the bucket directly, so notes survive container restarts and can be shared between instances. +ストレージクラスが `S3NotebookRepo` の場合、各ノートはバケットの `user/notebook/` プレフィックス配下に `.zpln` JSON ファイルとして永続化されます。Zeppelin はバケットを直接読み書きするため、ノートはコンテナの再起動後も残り、インスタンス間で共有できます。 -## 1. Start Zeppelin +## 1. Zeppelin を起動する -Create an environment file and replace both credential placeholders: +環境ファイルを作成し、両方の認証情報プレースホルダーを置き換えます。 ```ini title=".env" AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= ``` -Start Zeppelin on the same Docker network as RustFS with the S3 storage settings: +S3 ストレージの設定を付け、RustFS と同じ Docker ネットワーク上で Zeppelin を起動します。 ```bash docker run -d --name zeppelin --network oo-rustfs_default \ @@ -40,11 +40,11 @@ docker run -d --name zeppelin --network oo-rustfs_default \ apache/zeppelin:0.12.0 ``` -Zeppelin reads `ZEPPELIN_*` environment variables as configuration properties, so no `zeppelin-site.xml` edit is needed. This guide uses the existing `my-bucket`; notes land under its `user/notebook/` prefix, which the S3 storage creates on demand. +Zeppelin は `ZEPPELIN_*` 環境変数を設定プロパティとして読むため、`zeppelin-site.xml` の編集は不要です。このガイドでは既存の `my-bucket` を使います。ノートは `user/notebook/` プレフィックス配下に置かれ、このプレフィックスは S3 ストレージが必要に応じて作成します。 -## 2. Create a note +## 2. ノートを作成する -Wait for the UI on `http://localhost:8080`, then create a note named `rustfs-demo` in the notebook list and add a paragraph, or use the REST API: +`http://localhost:8080` の UI を待ち、ノートブック一覧で `rustfs-demo` という名前のノートを作成してパラグラフを追加するか、REST API を使います。 ```bash NOTE=$(curl -s -X POST "http://localhost:8080/api/notebook" \ @@ -53,57 +53,57 @@ NOTE=$(curl -s -X POST "http://localhost:8080/api/notebook" \ echo "note id: $NOTE" ``` -## 3. Verify the notebook in RustFS +## 3. RustFS 内のノートブックを確認する -List the notebook prefix: +ノートブックのプレフィックスを一覧します。 ```bash rc ls rustfs/my-bucket/user/notebook/ -r ``` -The note is stored as a JSON file named after the note and its ID: +ノートは、ノート名と ID からなる JSON ファイルとして保存されます。 ```text user/notebook/rustfs-demo_2N4PY7UY5.zpln ``` -![Zeppelin notebooks stored in the RustFS Console](./images/rustfs-zeppelin-notebook.png) +![RustFS Console に保存された Zeppelin ノートブック](./images/rustfs-zeppelin-notebook.png) -Notes survive a restart because Zeppelin loads them from the bucket: +Zeppelin はバケットからノートを読み込むため、再起動後もノートは残ります。 ```bash docker restart zeppelin curl -s "http://localhost:8080/api/notebook" | head -c 200 ``` -The note list contains `2N4PY7UY5` again after the restart. +再起動後のノート一覧には、再び `2N4PY7UY5` が含まれます。 -## 4. Stop or reset the deployment +## 4. デプロイを停止またはリセットする -Stop Zeppelin while keeping the notes: +ノートを残したまま Zeppelin を停止します。 ```bash docker rm -f zeppelin ``` -The notes stay in the `user/notebook/` prefix of `my-bucket`. To delete them, remove the prefix: +ノートは `my-bucket` の `user/notebook/` プレフィックスに残ります。削除する場合はプレフィックスを取り除きます。 ```bash rc rm rustfs/my-bucket/user/notebook/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Zeppelin starts but notes never appear in the bucket +### Zeppelin は起動するがノートがバケットに現れない -Confirm the three `ZEPPELIN_NOTEBOOK_S3_*` variables are set and that the credentials environment variables reach the container — the S3 repository is initialized at startup, so the container must be recreated after any change. +3 つの `ZEPPELIN_NOTEBOOK_S3_*` 変数が設定され、認証情報の環境変数がコンテナに届いていることを確認します。S3 リポジトリは起動時に初期化されるため、変更後はコンテナを再作成する必要があります。 ### `UnknownHostException: my-bucket.rustfs` -The path-style flag was not picked up. Keep `ZEPPELIN_NOTEBOOK_S3_PATH_STYLE_ACCESS=true` exactly as shown; with path-style disabled Zeppelin treats the bucket as a hostname. +パススタイルアクセスのフラグが反映されていません。`ZEPPELIN_NOTEBOOK_S3_PATH_STYLE_ACCESS=true` を表示どおり維持します。パススタイルアクセスを無効にすると、Zeppelin はバケットをホスト名として扱います。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Zeppelin operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Zeppelin storage documentation](https://zeppelin.apache.org/docs/latest/setup/storage/storage.html#notebook-storage-in-s3) to organize notes in per-user prefixes. +- 追加の Zeppelin 操作を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- ユーザーごとのプレフィックスでノートを整理するには、[Zeppelin ストレージのドキュメント](https://zeppelin.apache.org/docs/latest/setup/storage/storage.html#notebook-storage-in-s3)に従います。 diff --git a/content/ja/developer/integration/cloud-native/celld.md b/content/ja/developer/integration/cloud-native/celld.md index 37e2a757c..1e7fd4caf 100644 --- a/content/ja/developer/integration/cloud-native/celld.md +++ b/content/ja/developer/integration/cloud-native/celld.md @@ -1,13 +1,13 @@ --- title: "celld" -description: "Run denoland celld — self-hosted Durable Objects — with fleet state on RustFS." +description: "フリートの状態を RustFS に置き、セルフホストの Durable Objects である denoland celld を実行します。" --- -This guide connects [celld](https://github.com/denoland/celld) — the self-hosted, distributed Durable Objects runtime from Denoland — to **RustFS** as its fleet bucket. You will run `celld diagnose` against a RustFS bucket (including the conditional-write probe), deploy a Counter worker, mutate Durable Object state over HTTP, restart celld, and confirm the state survives. The workflow was verified with celld v0.6.2 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Denoland のセルフホスト型で分散した Durable Objects ランタイムである [celld](https://github.com/denoland/celld) を、フリートバケットとして **RustFS** に接続します。RustFS のバケットに対して `celld diagnose` を実行し（条件付き書き込みのプローブを含む）、Counter ワーカーをデプロイし、HTTP 経由で Durable Object の状態を変更し、celld を再起動して状態が残ることを確認します。この流れは celld v0.6.2 を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need the `celld` binary, `esbuild` (for bundling), and Node.js to drive the deployed worker. +`celld` バイナリ、バンドル用の `esbuild`、デプロイしたワーカーを操作するための Node.js が必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,9 +15,9 @@ flowchart LR celld -->|"LTX replicas + ownership + deploy"| RustFS["RustFS :9000"] ``` -celld keeps only a local WAL. Every committed SQLite write is captured in LTX format and uploaded to the fleet bucket; a conditional bucket write (put-if-not-exists) assigns node ownership. The bucket is the source of truth — nodes can crash or restart without losing Durable Object state. +celld がローカルに持つのは WAL だけです。コミットされた SQLite の書き込みはすべて LTX 形式で捕捉され、フリートバケットへアップロードされます。条件付きのバケット書き込み（put-if-not-exists、存在しない場合のみ書き込み）がノードの所有権を割り当てます。バケットが正本であり、ノードがクラッシュしたり再起動したりしても Durable Object の状態は失われません。 -## 1. Install celld +## 1. celld をインストールする ```bash curl -sLo /tmp/celld.gz \ @@ -31,15 +31,15 @@ celld --version celld 0.6.2 ``` -Install esbuild as well — `celld deploy` bundles workers with it: +esbuild もインストールします。`celld deploy` はこれでワーカーをバンドルします。 ```bash npm install -g esbuild ``` -## 2. Diagnose the bucket +## 2. バケットを診断する -`celld diagnose` probes the bucket including the conditional write that celld requires for ownership fencing: +`celld diagnose` は、所有権フェンシングに celld が必要とする条件付き書き込みを含め、バケットをプローブします。 ```bash export S3_ENDPOINT=http://:9000 @@ -58,11 +58,11 @@ ok bucket conditional write: create, reject-create, update, reject-stale ok fleet: 0 node lease(s) enumerated ``` -`ok bucket conditional write` is the important line — RustFS supports put-if-not-exists natively, so no fallback storage is needed. +重要なのは `ok bucket conditional write` の行です。RustFS は put-if-not-exists をネイティブにサポートするため、フォールバック用のストレージは不要です。 -## 3. Start a node +## 3. ノードを起動する -A non-loopback `--listen` requires an explicit `--internal-listen`: +ループバック以外の `--listen` には、明示的な `--internal-listen` が必要です。 ```bash nohup celld --bucket s3://celld-demo \ @@ -76,9 +76,9 @@ INFO celld: host runtime initialized event="host_runtime" worker_count=4 INFO celld::fleet: no deployment yet; run `celld deploy` ... ``` -## 4. Deploy the Counter worker +## 4. Counter ワーカーをデプロイする -Use the counter example from the celld repository — a Durable Object that increments `n` in SQLite storage on every request: +celld リポジトリの counter サンプルを使います。リクエストのたびに SQLite ストレージ内の `n` を増やす Durable Object です。 ```bash curl -sLo /tmp/celld.zip https://codeload.github.com/denoland/celld/zip/refs/tags/v0.6.2 @@ -93,9 +93,9 @@ Uploaded counter (0.02 sec) Current Version ID: bf5806589892a6cc ``` -## 5. Mutate Durable Object state +## 5. Durable Object の状態を変更する -Each request routes to the `Counter` Durable Object, which reads `n` from storage, increments, and writes it back: +各リクエストは `Counter` Durable Object へルーティングされます。ストレージから `n` を読み、インクリメントして書き戻します。 ```bash curl -s "http://127.0.0.1:18080/?name=rustfs" @@ -109,9 +109,9 @@ curl -s "http://127.0.0.1:18080/?name=rustfs" {"n":3,"url":"http://127.0.0.1:18080/?name=rustfs"} ``` -## 6. Restart celld and verify persistence +## 6. celld を再起動して永続化を確認する -Kill the node, start it again, and hit the same URL — the counter continues from where it stopped, because the state was in RustFS the whole time: +ノードを停止して再起動し、同じ URL にアクセスします。状態はずっと RustFS にあったため、カウンターは停止したところから続きます。 ```bash pkill -f "celld --bucket" @@ -126,7 +126,7 @@ curl -s "http://127.0.0.1:18080/?name=rustfs" {"n":4,"url":"http://127.0.0.1:18080/?name=rustfs"} ``` -List the bucket — the fleet state is all there: +バケットを一覧します。フリートの状態がすべて入っています。 ```bash rc ls rustfs/celld-demo/ -r | head -5 @@ -139,35 +139,35 @@ deploy/counter/bf5806589892a6cc/index.js deploy/counter/current.json ``` -![celld state stored in the RustFS Console](./images/rustfs-celld-state.png) +![RustFS Console に保存された celld の状態](./images/rustfs-celld-state.png) -## 7. Stop or reset +## 7. 停止またはリセットする ```bash pkill -f "celld --bucket" rc rm rustfs/celld-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `bind --listen 127.0.0.0.1:8080 ... Address already in use` -Port 8080 is commonly taken (a local GitLab registry or dev server). Move the Worker listener: `--listen 0.0.0.0:18080`. +ポート 8080 はよく使われています（ローカルの GitLab レジストリや開発サーバーなど）。Worker のリスナーを移します。`--listen 0.0.0.0:18080` です。 ### `a non-loopback --listen requires an explicit --internal-listen` -Binding a public interface requires a separate peer listener: add `--internal-listen 0.0.0.0:9099 --advertise 127.0.0.1:9099`. +パブリックなインターフェースにバインドする場合は、別のピア用リスナーが必要です。`--internal-listen 0.0.0.0:9099 --advertise 127.0.0.1:9099` を追加します。 ### `esbuild not found` -`celld deploy` bundles the worker with esbuild. Install it globally (`npm install -g esbuild`) or point `CELLD_ESBUILD` at the binary. +`celld deploy` は esbuild でワーカーをバンドルします。グローバルにインストールする（`npm install -g esbuild`）か、`CELLD_ESBUILD` でバイナリを指定します。 -### `celld deploy` on the example prints `unknown command init for argo` at runtime +### サンプルで `celld deploy` すると実行時に `unknown command init for argo` と表示される -That means the executor container/pod is running an `argo` CLI binary instead of argoexec — a sign the wrong image was tagged as the executor in your cluster setup, unrelated to celld itself. On a plain host (no cluster) this does not occur. +executor のコンテナまたは Pod が argoexec ではなく `argo` CLI のバイナリを実行していることを意味します。クラスター設定で誤ったイメージが executor としてタグ付けされている兆候であり、celld 自体とは関係ありません。クラスターのない通常のホストでは発生しません。 -## Next steps +## 次のステップ -- Compare with the [Cloudflare Durable Objects documentation](https://developers.cloudflare.com/durable-objects/) — celld runs the same programming model on your own bucket. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [celld README](https://github.com/denoland/celld) for multi-node fleets: point a second node at the same bucket and let conditional writes elect the owner. +- [Cloudflare Durable Objects のドキュメント](https://developers.cloudflare.com/durable-objects/)と比較してください。celld は同じプログラミングモデルを、自前のバケット上で実行します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [celld の README](https://github.com/denoland/celld)に従い、マルチノードのフリートを構成します。2 台目のノードを同じバケットに向け、条件付き書き込みで所有者を選出します。 diff --git a/content/ja/developer/integration/cloud-native/cortex.md b/content/ja/developer/integration/cloud-native/cortex.md index 3db19b471..a1d2b2fc8 100644 --- a/content/ja/developer/integration/cloud-native/cortex.md +++ b/content/ja/developer/integration/cloud-native/cortex.md @@ -1,13 +1,13 @@ --- title: "Cortex" -description: "Run Cortex with RustFS as the S3-compatible blocks, ruler, and alertmanager storage backend." +description: "ブロック、Ruler、Alertmanager の S3 互換ストレージバックエンドとして RustFS を使って Cortex を実行します。" --- -This guide connects [Cortex](https://github.com/cortexproject/cortex) — the horizontally scalable Prometheus-compatible metrics backend — to **RustFS** through Cortex's native S3 bucket storage. You will run Cortex in single-binary mode with blocks, ruler, and alertmanager storage pointed at a RustFS bucket, push metrics with remote write, store a rule group, and verify the objects. The workflow was verified with `cortexproject/cortex:v1.21.1` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、水平スケール可能な Prometheus 互換のメトリクスバックエンドである [Cortex](https://github.com/cortexproject/cortex) を、Cortex ネイティブの S3 バケットストレージ経由で **RustFS** に接続します。ブロック、Ruler、Alertmanager のストレージを RustFS のバケットに向けたシングルバイナリモードで Cortex を実行し、リモートライトでメトリクスを push し、ルールグループを保存してオブジェクトを確認します。この流れは `cortexproject/cortex:v1.21.1` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR Cortex -->|"blocks, rules, configs"| RustFS["RustFS :9000"] ``` -Cortex stores every TSDB block, ruler rule group, and alertmanager configuration in object storage. Pointing the `s3` backend at RustFS makes the bucket the single source of truth for all tenant data. +Cortex はすべての TSDB ブロック、Ruler のルールグループ、Alertmanager の設定をオブジェクトストレージに保存します。`s3` バックエンドを RustFS に向けると、バケットがすべてのテナントデータの単一の正本になります。 -## 1. Create the Cortex config +## 1. Cortex の設定を作成する -Create the config file, replacing all connection placeholders: +接続情報のプレースホルダーをすべて置き換えて、設定ファイルを作成します。 ```yaml title="cortex.yaml" target: all @@ -88,11 +88,11 @@ alertmanager_storage: <<: *s3 ``` -Cortex names the bucket field `bucket_name` and controls addressing with `bucket_lookup_type: path`. `insecure: true` allows the plain-HTTP endpoint. The `block_ranges_period` and `ship_interval` values shorten the block cycle so the test produces objects quickly; keep the defaults in production. +Cortex のバケットフィールド名は `bucket_name` で、アドレス指定は `bucket_lookup_type: path` で制御します。`insecure: true` は平文 HTTP のエンドポイントを許可します。`block_ranges_period` と `ship_interval` はブロック周期を短くし、テストですぐにオブジェクトができるようにします。本番ではデフォルトを維持してください。 -## 2. Run Cortex +## 2. Cortex を実行する -Create the bucket and start Cortex on the same Docker network as RustFS: +バケットを作成し、RustFS と同じ Docker ネットワーク上で Cortex を起動します。 ```bash rc mb rustfs/cortex @@ -107,9 +107,9 @@ docker run -d --name cortex --network oo-rustfs_default -p 9009:9009 \ ts=... caller=cortex.go:469 level=info msg="Cortex started" ``` -## 3. Push metrics and rules +## 3. メトリクスとルールを push する -Start a Prometheus that scrapes itself and remote-writes into Cortex: +自身をスクレイプし、Cortex へリモートライトする Prometheus を起動します。 ```yaml title="prometheus.yml" global: @@ -128,7 +128,7 @@ docker run -d --name prom-writer --network oo-rustfs_default \ prom/prometheus:latest --config.file=/etc/prometheus/prometheus.yml ``` -Store a rule group through the ruler API: +Ruler API でルールグループを保存します。 ```bash cat > rules.yaml << "EOF" @@ -151,7 +151,7 @@ curl -s -o /dev/null -w "%{http_code}\n" \ 202 ``` -Query the ingested series back: +取り込んだ系列をクエリして読み戻します。 ```bash curl -s "http://localhost:9009/prometheus/api/v1/query?query=up" @@ -161,15 +161,15 @@ curl -s "http://localhost:9009/prometheus/api/v1/query?query=up" {"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up",...},"value":[...,"1"]}]}} ``` -## 4. Verify objects in RustFS +## 4. RustFS 内のオブジェクトを確認する -List the bucket prefixes: +バケットのプレフィックスを一覧します。 ```bash rc ls rustfs/cortex/ -r ``` -The ruler config landed immediately, and the ingester shipped two TSDB blocks (each with `chunks`, `index`, and `meta.json`): +Ruler の設定はすぐに保存され、ingester は 2 つの TSDB ブロックを送出しました（それぞれ `chunks`、`index`、`meta.json` を持ちます）。 ```text fake/01M35WE4B1G6RRKHRV0HSGADY1/chunks/000001 @@ -181,38 +181,38 @@ fake/01M35WWS2YCC7FBK1JSBKFQGRP/meta.json rules/fake/cnVzdGZzLWRlbW8=/cnVzdGZzLWRlbW8= ``` -![Cortex blocks and rules stored in the RustFS Console](./images/rustfs-cortex-blocks.png) +![RustFS Console に保存された Cortex のブロックとルール](./images/rustfs-cortex-blocks.png) -## 5. Stop or reset +## 5. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを破棄します。 ```bash docker rm -f cortex prom-writer ``` -To delete the stored data: +保存したデータを削除します。 ```bash rc rm rustfs/cortex/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `field bucket not found in type s3.Config` -Cortex uses `bucket_name`, not `bucket`. Path-style addressing is set with `bucket_lookup_type: path` — the `force_path_style` key used by Thanos does not exist in Cortex. +Cortex が使うのは `bucket` ではなく `bucket_name` です。パススタイルアクセスは `bucket_lookup_type: path` で設定します。Thanos で使う `force_path_style` キーは Cortex にはありません。 -### Blocks never appear in the bucket +### ブロックがバケットに現れない -The ingester only ships a block after the head is compacted at a `block_ranges_period` boundary (default 2h). For tests, set a small range such as `[15m]` together with `ship_interval: 30s` and wait for one period. +ingester は、ヘッドが `block_ranges_period` の境界（デフォルト 2 時間）でコンパクトされたあとでなければブロックを送出しません。テストでは `[15m]` のような短い範囲と `ship_interval: 30s` を設定し、1 周期待ちます。 -### `Unauthorized` or empty bucket listings +### `Unauthorized` または空のバケット一覧 -Confirm `access_key_id` and `secret_access_key` are present in every `s3` block that uses the bucket, and that `insecure: true` matches the plain-HTTP endpoint. +バケットを使うすべての `s3` ブロックに `access_key_id` と `secret_access_key` があること、および `insecure: true` が平文 HTTP のエンドポイントと一致することを確認します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Cortex storage options. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Combine Cortex with [Thanos](/developer/integration/observability/thanos) when you need block storage for long-term Prometheus data as well. +- 追加の Cortex ストレージオプションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 長期の Prometheus データ向けのブロックストレージも必要な場合は、Cortex を [Thanos](/ja/developer/integration/observability/thanos) と組み合わせてください。 diff --git a/content/ja/developer/integration/cloud-native/flux.md b/content/ja/developer/integration/cloud-native/flux.md index 0319cc855..a30952a67 100644 --- a/content/ja/developer/integration/cloud-native/flux.md +++ b/content/ja/developer/integration/cloud-native/flux.md @@ -1,13 +1,13 @@ --- title: "Flux" -description: "Deliver Kubernetes manifests to Flux CD from RustFS through the Bucket source API." +description: "Bucket ソース API を通じて、Kubernetes マニフェストを RustFS から Flux CD へ配信します。" --- -This guide connects [Flux CD](https://github.com/fluxcd/flux2) — the GitOps toolkit for Kubernetes — to **RustFS** through the source-controller Bucket API. You will seed a RustFS bucket with Kubernetes manifests, register the bucket as a Flux `Bucket` source with the `generic` provider, and let a Kustomization apply everything it contains. The workflow was verified with `flux v2.9.5` (source-controller) on `k3s v1.36.4+k3s1` against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Kubernetes 向け GitOps ツールキットである [Flux CD](https://github.com/fluxcd/flux2) を、source-controller の Bucket API 経由で **RustFS** に接続します。Kubernetes マニフェストを RustFS のバケットに配置し、`generic` プロバイダーの Flux `Bucket` ソースとして登録し、Kustomization で含まれる内容をすべて適用します。この流れは `k3s v1.36.4+k3s1` 上の `flux v2.9.5`（source-controller）を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need a Kubernetes cluster with Flux installed (`flux install`) and the `rc` client. This deployment is intended for local integration testing, not production. +Flux をインストールした Kubernetes クラスター（`flux install`）と、`rc` クライアントが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -17,11 +17,11 @@ flowchart LR kustomize-controller -->|"apply"| Cluster["Kubernetes cluster"] ``` -The source-controller lists and downloads objects from the bucket over the S3 API, packs them into an artifact, and the kustomize-controller applies the manifests from that artifact. RustFS acts as the pull-based source of truth for the cluster. +source-controller は S3 API でバケット内のオブジェクトを一覧してダウンロードし、アーティファクトにまとめます。kustomize-controller はそのアーティファクトからマニフェストを適用します。RustFS はクラスターにとってプル型の正本になります。 -## 1. Seed the bucket +## 1. バケットに初期データを入れる -Store a Kustomize overlay in the bucket, replacing all connection placeholders: +接続情報のプレースホルダーをすべて置き換え、Kustomize オーバーレイをバケットに保存します。 ```yaml title="clusters/staging/kustomization.yaml" apiVersion: kustomize.config.k8s.io/v1beta1 @@ -41,7 +41,7 @@ data: source: s3-bucket ``` -Upload the files: +ファイルをアップロードします。 ```bash rc mb rustfs/flux-src @@ -54,9 +54,9 @@ staging/kustomization.yaml staging/rustfs-demo-configmap.yaml ``` -## 2. Create the credentials secret +## 2. 認証情報の Secret を作成する -Flux reads the credentials from a secret in the same namespace as the source, using lowercase keys: +Flux は、ソースと同じ名前空間の Secret から、小文字のキーで認証情報を読みます。 ```bash kubectl -n flux-system create secret generic rustfs-creds \ @@ -64,11 +64,11 @@ kubectl -n flux-system create secret generic rustfs-creds \ --from-literal=secretkey= ``` -The field names must be `accesskey` and `secretkey` — capitalization such as `accessKey` fails with an `AuthenticationFailed` status. +フィールド名は `accesskey` と `secretkey` である必要があります。`accessKey` のような大文字を含む名前は `AuthenticationFailed` ステータスで失敗します。 -## 3. Register the Bucket source +## 3. Bucket ソースを登録する -Create the Bucket source with the `generic` provider: +`generic` プロバイダーで Bucket ソースを作成します。 ```bash flux create source bucket rustfs-demo \ @@ -85,18 +85,18 @@ flux create source bucket rustfs-demo \ ✔ Bucket source reconciliation completed ``` -If reconciliation is still running, check the status with `flux get sources bucket`: +リコンシリエーションがまだ実行中の場合は、`flux get sources bucket` でステータスを確認します。 ```text NAME REVISION SUSPENDED READY MESSAGE rustfs-demo sha256:481816d1 False True stored artifact: revision 'sha256:481816d1' ``` -The `generic` provider uses path-style requests and plain HTTP with `--insecure`, so the endpoint is the bare `host:port`. +`generic` プロバイダーは `--insecure` でパススタイルのリクエストと平文 HTTP を使います。そのためエンドポイントは `host:port` だけです。 -## 4. Apply the manifests +## 4. マニフェストを適用する -Create a Kustomization that consumes the artifact: +アーティファクトを取り込む Kustomization を作成します。 ```bash flux create kustomization rustfs-demo \ @@ -111,7 +111,7 @@ flux create kustomization rustfs-demo \ ✔ applied revision sha256:481816d1 ``` -Confirm the manifest landed on the cluster: +マニフェストがクラスターに反映されたことを確認します。 ```bash kubectl -n default get configmap rustfs-flux-demo -o jsonpath="{.data}" @@ -121,37 +121,37 @@ kubectl -n default get configmap rustfs-flux-demo -o jsonpath="{.data}" {"source":"s3-bucket","storage":"rustfs"} ``` -## 5. Stop or reset +## 5. 停止またはリセットする -Suspend or delete the Flux resources without touching the bucket: +バケットには触れずに、Flux リソースを一時停止または削除します。 ```bash flux suspend source bucket rustfs-demo --namespace=flux-system flux delete kustomization rustfs-demo --namespace=flux-system ``` -To delete the bucket contents: +バケットの内容を削除します。 ```bash rc rm rustfs/flux-src/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `invalid 'rustfs-creds' secret data: required fields 'accesskey' and 'secretkey'` -The secret keys are lowercase. Recreate the secret with `accesskey` and `secretkey` as literal key names. +Secret のキーは小文字です。`accesskey` と `secretkey` をリテラルのキー名として Secret を作り直します。 -### Reconciliation never becomes ready +### リコンシリエーションが Ready にならない -Confirm the endpoint is reachable from inside the cluster — pods cannot use `localhost`, so point the source at the host IP or the Docker bridge gateway (commonly `172.17.0.1`) that publishes the RustFS port. `--insecure` is required for plain HTTP. +エンドポイントがクラスター内から到達できることを確認します。Pod は `localhost` を使えません。ソースは、RustFS のポートを公開しているホストの IP、または Docker ブリッジのゲートウェイ（一般的には `172.17.0.1`）に向けます。平文 HTTP では `--insecure` が必要です。 -### `AuthenticationFailed` despite valid credentials +### 認証情報が正しいのに `AuthenticationFailed` になる -Check that the secret lives in the same namespace as the Bucket source and that the keys have no trailing whitespace or quoting. +Secret が Bucket ソースと同じ名前空間にあること、およびキーに末尾の空白や引用符がないことを確認します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional source types. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Flux Bucket source documentation](https://fluxcd.io/flux/components/source/buckets/) to combine bucket sources with Helm releases and image automation. +- 追加のソースタイプを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [Flux の Bucket ソースドキュメント](https://fluxcd.io/flux/components/source/buckets/)に従い、バケットソースを Helm リリースやイメージ自動化と組み合わせてください。 diff --git a/content/ja/developer/integration/database/clickhouse.md b/content/ja/developer/integration/database/clickhouse.md index ac9d8d4b2..7135c4735 100644 --- a/content/ja/developer/integration/database/clickhouse.md +++ b/content/ja/developer/integration/database/clickhouse.md @@ -1,13 +1,13 @@ --- title: "ClickHouse" -description: "Run ClickHouse with an S3 disk backed by RustFS for MergeTree table data." +description: "MergeTree テーブルのデータ向けに、RustFS をバックエンドとする S3 ディスクで ClickHouse を実行します。" --- -This guide connects [ClickHouse](https://github.com/ClickHouse/ClickHouse) — the real-time OLAP database — to **RustFS** through ClickHouse's S3 disk storage policy. You will start a ClickHouse server with Docker, create a MergeTree table that stores its parts on RustFS, insert rows, and verify that the table data lives in the bucket. The workflow was verified with `clickhouse/clickhouse-server:25.8` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、リアルタイム OLAP データベースである [ClickHouse](https://github.com/ClickHouse/ClickHouse) を、ClickHouse の S3 ディスクストレージポリシーを通じて **RustFS** に接続します。Docker で ClickHouse サーバーを起動し、パーツを RustFS に保存する MergeTree テーブルを作成して行を挿入し、テーブルデータがバケットにあることを確認します。この流れは `clickhouse/clickhouse-server:25.8` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,18 +15,18 @@ flowchart LR CH -->|"MergeTree parts"| RustFS["RustFS :9000"] ``` -The `rustfs` disk is a ClickHouse S3 disk pointed at the `clickhouse-data` bucket. Tables created with the matching storage policy write their parts — data, index, and checksum files — to the bucket instead of the local filesystem. +`rustfs` ディスクは、`clickhouse-data` バケットを指す ClickHouse の S3 ディスクです。対応するストレージポリシーで作成したテーブルは、パーツ（データ、インデックス、チェックサムのファイル）をローカルファイルシステムではなくバケットへ書き込みます。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create the bucket first — ClickHouse does not create buckets: +先にバケットを作成します。ClickHouse はバケットを作成しません。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/clickhouse-data ``` -Create the storage configuration, replacing both credential placeholders: +両方の認証情報プレースホルダーを置き換え、ストレージ設定を作成します。 ```xml title="storage.xml" @@ -52,9 +52,9 @@ Create the storage configuration, replacing both credential placeholders: ``` -The endpoint must end with `/` and includes the bucket name as the first path segment. Inside the Compose network the hostname is `rustfs`; from the host use `http://localhost:9000/clickhouse-data/`. +エンドポイントは `/` で終わる必要があり、先頭のパスセグメントにバケット名を含めます。Compose ネットワーク内のホスト名は `rustfs` です。ホストからは `http://localhost:9000/clickhouse-data/` を使います。 -Start ClickHouse with the configuration mounted: +設定をマウントして ClickHouse を起動します。 ```bash docker run -d --name clickhouse --network oo-rustfs_default \ @@ -64,9 +64,9 @@ docker run -d --name clickhouse --network oo-rustfs_default \ clickhouse/clickhouse-server:25.8 ``` -## 2. Create a table on the S3 disk +## 2. S3 ディスク上にテーブルを作成する -Wait for the HTTP interface, then create a database and a MergeTree table with the storage policy: +HTTP インターフェースを待ち、ストレージポリシー付きのデータベースと MergeTree テーブルを作成します。 ```bash curl "http://localhost:8123/?password=" \ @@ -83,7 +83,7 @@ curl "http://localhost:8123/?password=" \ VALUES (1, 'clickhouse-on-rustfs'), (2, 'second')" ``` -Read the rows back and confirm ClickHouse reports the part on the `rustfs` disk: +行を読み戻し、ClickHouse がパーツを `rustfs` ディスク上にあると報告することを確認します。 ```bash curl "http://localhost:8123/?password=" \ @@ -99,15 +99,15 @@ curl "http://localhost:8123/?password=" \ all_1_1_0 rustfs ``` -## 3. Verify objects in RustFS +## 3. RustFS 内のオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/clickhouse-data/ -r ``` -ClickHouse writes each part as content-addressed blobs. The output contains several small objects, and the count grows as more parts are written: +ClickHouse は各パーツをコンテンツアドレス方式のブロブとして書き込みます。出力には複数の小さなオブジェクトが含まれ、パーツが増えると件数も増えます。 ```text dtg/hpsyncexixvdnsgorvseobogcgowg @@ -115,9 +115,9 @@ dzp/zfblobhsatzdveqdrsfqcupkdehja izg/gvhchqobrizpkdftuvlmakkoutwps ``` -![ClickHouse parts stored in the RustFS Console](./images/rustfs-clickhouse-disk.png) +![RustFS Console に保存された ClickHouse のパーツ](./images/rustfs-clickhouse-disk.png) -The data survives a container restart because the parts live in RustFS: +パーツは RustFS にあるため、データはコンテナの再起動後も残ります。 ```bash docker restart clickhouse @@ -125,36 +125,36 @@ curl "http://localhost:8123/?password=" \ --data-binary "SELECT count() FROM rustfs_demo.events" ``` -## 4. Stop or reset the deployment +## 4. デプロイを停止またはリセットする -Stop the server while keeping the data: +データを残したままサーバーを停止します。 ```bash docker rm -f clickhouse ``` -The parts stay in the `clickhouse-data` bucket and the table can be queried again after the next start. To delete the data, remove the bucket: +パーツは `clickhouse-data` バケットに残り、次回起動後にテーブルを再びクエリできます。データを削除する場合はバケットを取り除きます。 ```bash rc rb rustfs/clickhouse-data --force ``` -## Troubleshooting +## トラブルシューティング -### `REQUIRED_PASSWORD` on every query +### すべてのクエリで `REQUIRED_PASSWORD` が出る -ClickHouse 25.8 images require a password for the `default` user. Set `CLICKHOUSE_PASSWORD` on the container and pass the same value as the `password` query parameter, as shown above. +ClickHouse 25.8 のイメージでは、`default` ユーザーにパスワードが必要です。コンテナに `CLICKHOUSE_PASSWORD` を設定し、上記のとおり同じ値を `password` クエリパラメーターとして渡します。 -### Table creation fails with a disk or endpoint error +### ディスクまたはエンドポイントのエラーでテーブル作成が失敗する -Confirm that the bucket exists before the table is created, that the endpoint ends with `/`, and that the credentials match the RustFS deployment. Check the server log for the underlying S3 error: +テーブル作成前にバケットが存在すること、エンドポイントが `/` で終わること、認証情報が RustFS のデプロイと一致することを確認します。根本の S3 エラーはサーバーログで確認します。 ```bash docker logs clickhouse | grep -i s3 | tail ``` -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional ClickHouse operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [ClickHouse S3 disk documentation](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-s3) to add a cache disk or a tiered hot/cold policy. +- 追加の ClickHouse 操作を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- キャッシュディスクやホット / コールドの階層ポリシーを追加するには、[ClickHouse S3 ディスクのドキュメント](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-s3)に従います。 diff --git a/content/ja/developer/integration/database/databend.md b/content/ja/developer/integration/database/databend.md index 829763398..aab0c98e2 100644 --- a/content/ja/developer/integration/database/databend.md +++ b/content/ja/developer/integration/database/databend.md @@ -1,13 +1,13 @@ --- title: "Databend" -description: "Run Databend with RustFS as the S3-compatible storage backend." +description: "S3 互換ストレージのバックエンドとして RustFS を使い、Databend を実行します。" --- -This guide connects [Databend](https://github.com/datafuselabs/databend) — the open-source cloud data warehouse — to **RustFS** as its object storage backend. You will start the meta service and query node, point the storage backend at a RustFS bucket, create a database and table, and verify the Parquet files in the bucket. The workflow was verified with Databend v1.2.925-patch-13 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、オープンソースのクラウドデータウェアハウスである [Databend](https://github.com/datafuselabs/databend) を、オブジェクトストレージのバックエンドとして **RustFS** に接続します。メタサービスとクエリノードを起動し、ストレージのバックエンドを RustFS バケットに向け、データベースとテーブルを作成して、バケット内の Parquet ファイルを確認します。この流れは Databend v1.2.925-patch-13 と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need the Databend release tarball on a Linux host (or Docker). This deployment is intended for local integration testing, not production. +Linux ホスト（または Docker）上に Databend のリリースターボールが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,11 +16,11 @@ flowchart LR Query -->|"Parquet SSTs + indexes"| RustFS["RustFS :9000"] ``` -Databend stores table data as Parquet files with bloom-filter indexes in object storage, so the bucket holds the entire table dataset and the query node stays stateless. +Databend はテーブルデータを、ブルームフィルターインデックス付きの Parquet ファイルとしてオブジェクトストレージに保存します。そのためバケットがテーブルデータセット全体を保持し、クエリノードはステートレスのままです。 -## 1. Download and install +## 1. ダウンロードしてインストールする -Grab a release tarball and unpack the binaries: +リリースターボールを取得し、バイナリを展開します。 ```bash curl -Lo /tmp/databend.tgz \ @@ -28,15 +28,15 @@ curl -Lo /tmp/databend.tgz \ tar -xzf /tmp/databend.tgz -C /opt ``` -Create the data directories: +データディレクトリを作成します。 ```bash mkdir -p /opt/databend/data /opt/databend/logs /opt/databend/meta-logs ``` -## 2. Configure the meta service +## 2. メタサービスを設定する -Create `databend-meta.toml` — note the top-level addresses and the `[raft_config]` section with `single = true`: +`databend-meta.toml` を作成します。トップレベルのアドレスと、`single = true` を含む `[raft_config]` セクションに注意します。 ```toml title="databend-meta.toml" admin_api_address = "0.0.0.0:28002" @@ -57,9 +57,9 @@ raft_advertise_host = "127.0.0.1" single = true ``` -## 3. Configure the query node +## 3. クエリノードを設定する -Create `databend-query.toml`. The `tenant_id` and `cluster_id` keys must live inside the `[query]` section, and `[storage.s3]` points at RustFS: +`databend-query.toml` を作成します。`tenant_id` と `cluster_id` は `[query]` セクション内に置く必要があり、`[storage.s3]` は RustFS を指します。 ```toml title="databend-query.toml" [query] @@ -96,9 +96,9 @@ secret_access_key = "" enable_virtual_host_style = false ``` -Keep all keys before the `[[query.users]]` array entry — TOML treats everything after it as part of that array element, and misplaced keys fail validation with confusing errors. +すべてのキーは `[[query.users]]` 配列要素より前に置きます。TOML ではそれ以降が配列要素の一部として扱われ、キーの位置がずれると分かりにくい検証エラーになります。 -## 4. Start the services +## 4. サービスを起動する ```bash nohup /opt/databend/bin/databend-meta -c /opt/databend/databend-meta.toml > /opt/databend/meta.out 2>&1 & @@ -107,9 +107,9 @@ nohup /opt/databend/bin/databend-query -c /opt/databend/databend-query.toml > /o sleep 20 ``` -## 5. Create a table and query +## 5. テーブルを作成してクエリする -Databend serves an HTTP API on port 8000. Create a database and a table, insert rows, and read them back — quotes inside SQL must be single quotes (double quotes mean identifiers): +Databend はポート 8000 で HTTP API を提供します。データベースとテーブルを作成し、行を挿入して読み戻します。SQL 内の引用符はシングルクォートである必要があります（ダブルクォートは識別子を意味します）。 ```bash curl -s -m 90 -u databend: http://127.0.0.1:8000/v1/query \ @@ -129,9 +129,9 @@ curl -s -m 120 -u databend: http://127.0.0.1:8000/v1/query \ {"id":"...","state":"Succeeded",...,"data":[["1","alpha"],["2","beta"],["3","gamma"]],...} ``` -## 6. Verify objects in RustFS +## 6. RustFS 内のオブジェクトを確認する -List the bucket — the table lives as Parquet blocks with index files under numeric prefixes: +バケットを一覧します。テーブルは、数値プレフィックス配下の Parquet ブロックとインデックスファイルとして存在します。 ```bash rc ls rustfs/databend-demo/ -r | head -4 @@ -142,35 +142,35 @@ rc ls rustfs/databend-demo/ -r | head -4 73/116/_i_b_v2/01a1192b11b07c38b9ae1178abc78882_v4.parquet ``` -![Databend Parquet files stored in the RustFS Console](./images/rustfs-databend-parquet.png) +![RustFS Console に保存された Databend の Parquet ファイル](./images/rustfs-databend-parquet.png) -## 7. Stop or reset +## 7. 停止またはリセットする ```bash pkill -f databend-query; pkill -f databend-meta rc rm rustfs/databend-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `cluster_id is empty without resources management` -`tenant_id` and `cluster_id` were placed outside the `[query]` section. In TOML, every key belongs to the most recent section header — move them back under `[query]`. +`tenant_id` と `cluster_id` が `[query]` セクションの外に置かれています。TOML では各キーが直前のセクションヘッダーに属します。`[query]` の下へ戻します。 ### `CannotListenerPort ... 127.0.0.1:9090` -The flight API defaults to 9090, which other local services often occupy. Set `flight_api_address`, `metric_api_address`, and `admin_api_address` to free ports inside `[query]`. +Flight API のデフォルトは 9090 で、ほかのローカルサービスが使うことが多いポートです。`[query]` 内で `flight_api_address`、`metric_api_address`、`admin_api_address` を空いているポートに設定します。 -### Query returns `Authentication error: no authorization header provided` +### クエリが `Authentication error: no authorization header provided` を返す -The HTTP API requires basic auth matching the `[[query.users]]` entry, e.g. `-u databend:` with `auth_type = "no_password"`. +HTTP API には、`[[query.users]]` エントリに一致する Basic 認証が必要です。たとえば `auth_type = "no_password"` のときは `-u databend:` を使います。 -### `Unknown table` right after CREATE succeeded +### CREATE の成功直後に `Unknown table` が出る -Double-quoted strings in SQL are identifiers, not literals. Use single quotes for VALUES and for the CONNECTION/LOCATION options. +SQL のダブルクォート文字列はリテラルではなく識別子です。VALUES と CONNECTION/LOCATION オプションにはシングルクォートを使います。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Databend storage options. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Databend documentation](https://docs.databend.com/) for multi-node clusters and share tables on top of the same bucket. +- 追加の Databend ストレージオプションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- 同じバケット上でマルチノードのクラスターと共有テーブルを使うには、[Databend ドキュメント](https://docs.databend.com/)に従います。 diff --git a/content/ja/developer/integration/database/doris.md b/content/ja/developer/integration/database/doris.md index 1c3665b5c..455833f84 100644 --- a/content/ja/developer/integration/database/doris.md +++ b/content/ja/developer/integration/database/doris.md @@ -1,13 +1,13 @@ --- title: "Apache Doris" -description: "Back up Apache Doris tables to RustFS through an S3 repository and restore them." +description: "S3 リポジトリを通じて Apache Doris のテーブルを RustFS にバックアップし、リストアします。" --- -This guide connects [Apache Doris](https://github.com/apache/doris) — the real-time analytical data warehouse — to **RustFS** through an S3 backup repository. You will start an all-in-one Doris container, create an S3 repository pointing at a RustFS bucket, back up a table, drop it, and restore it from RustFS. The workflow was verified with `apache/doris:all-in-one-4.1.3` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、リアルタイム分析データウェアハウスである [Apache Doris](https://github.com/apache/doris) を、S3 バックアップリポジトリを通じて **RustFS** に接続します。オールインワンの Doris コンテナを起動し、RustFS バケットを指す S3 リポジトリを作成してテーブルをバックアップし、削除したあと RustFS からリストアします。この流れは `apache/doris:all-in-one-4.1.3` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,27 +15,27 @@ flowchart LR Doris -->|"BACKUP / RESTORE"| RustFS["RustFS :9000"] ``` -The repository is a named S3 location under the `doris-backups` bucket. `BACKUP SNAPSHOT` uploads table metadata and tablet data files; `RESTORE SNAPSHOT` downloads them into a new table. +リポジトリは `doris-backups` バケット配下の名前付き S3 ロケーションです。`BACKUP SNAPSHOT` はテーブルのメタデータとタブレットのデータファイルをアップロードし、`RESTORE SNAPSHOT` はそれらを新しいテーブルへダウンロードします。 -## 1. Start Doris and create the repository +## 1. Doris を起動してリポジトリを作成する -Create the bucket first — Doris does not create buckets: +先にバケットを作成します。Doris はバケットを作成しません。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/doris-backups ``` -Start the all-in-one container on the same Docker network as RustFS: +RustFS と同じ Docker ネットワーク上でオールインワンコンテナを起動します。 ```bash docker run -d --name doris --network oo-rustfs_default \ -p 8030:8030 -p 9030:9030 apache/doris:all-in-one-4.1.3 ``` -Wait for the frontend to become healthy, then connect with the MySQL protocol (port 9030, user `root`, no password in the all-in-one image). +フロントエンドが健全になるのを待ち、MySQL プロトコルで接続します（ポート 9030、ユーザー `root`、オールインワンイメージではパスワードなし）。 -Create a test table with rows: +行を持つテストテーブルを作成します。 ```sql CREATE DATABASE rustfs_demo; @@ -46,7 +46,7 @@ CREATE TABLE rustfs_demo.events INSERT INTO rustfs_demo.events VALUES (1, 'doris-on-rustfs'), (2, 'backup-test'); ``` -Create the S3 repository, replacing the endpoint with the IP address of the RustFS container and both credential placeholders: +エンドポイントを RustFS コンテナの IP アドレスに、両方の認証情報プレースホルダーを置き換えて、S3 リポジトリを作成します。 ```sql CREATE REPOSITORY `rustfs_repo` @@ -61,11 +61,11 @@ CREATE REPOSITORY `rustfs_repo` ); ``` -Doris 4.1 resolves the bucket into the endpoint hostname even with `AWS_PATH_STYLE_ACCESS` enabled, so a hostname endpoint fails with `UnknownHostException: doris-backups.rustfs`. Using the container IP address forces path-style requests and works; `SHOW REPOSITORIES` confirms the repository registered with an empty `ErrMsg`. +Doris 4.1 は `AWS_PATH_STYLE_ACCESS` を有効にしても、バケットをエンドポイントのホスト名へ解決します。そのためホスト名のエンドポイントは `UnknownHostException: doris-backups.rustfs` で失敗します。コンテナの IP アドレスを使うとパススタイルアクセスのリクエストになり、動作します。`SHOW REPOSITORIES` で、リポジトリが空の `ErrMsg` とともに登録されたことを確認します。 -## 2. Back up a table to RustFS +## 2. テーブルを RustFS へバックアップする -Take a snapshot of the table: +テーブルのスナップショットを取得します。 ```sql BACKUP SNAPSHOT rustfs_demo.demo_snapshot @@ -73,23 +73,23 @@ BACKUP SNAPSHOT rustfs_demo.demo_snapshot ON (events); ``` -The statement returns immediately; the backup job runs in the background. Watch its state: +ステートメントはすぐに戻ります。バックアップジョブはバックグラウンドで実行されます。状態を監視します。 ```sql SHOW BACKUP; ``` -Wait until `State` reaches `FINISHED` — the snapshot metadata and tablet data files are now objects in the bucket. +`State` が `FINISHED` になるまで待ちます。スナップショットのメタデータとタブレットのデータファイルは、この時点でバケット内のオブジェクトになっています。 -## 3. Verify the backup in RustFS +## 3. RustFS 内のバックアップを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/doris-backups/ -r ``` -The repository stores a repository descriptor, the snapshot metadata, and the tablet files: +リポジトリには、リポジトリ記述子、スナップショットのメタデータ、タブレットファイルが保存されます。 ```text rustfs-repo/__palo_repository_rustfs_repo/__repo_info @@ -97,11 +97,11 @@ rustfs-repo/__palo_repository_rustfs_repo/__ss_demo_snapshot/__meta.d50ecf9b... rustfs-repo/__palo_repository_rustfs_repo/__ss_demo_snapshot/__ss_content/.../...dat... ``` -![Doris backup objects stored in the RustFS Console](./images/rustfs-doris-backup.png) +![RustFS Console に保存された Doris のバックアップオブジェクト](./images/rustfs-doris-backup.png) -## 4. Restore the table from RustFS +## 4. RustFS からテーブルをリストアする -Drop the table and restore it from the snapshot. The timestamp comes from the snapshot name shown by `SHOW SNAPSHOT ON REPOSITORY rustfs_repo;`: +テーブルを削除し、スナップショットからリストアします。タイムスタンプは `SHOW SNAPSHOT ON REPOSITORY rustfs_repo;` が表示するスナップショット名から取ります。 ```sql DROP TABLE rustfs_demo.events; @@ -115,7 +115,7 @@ RESTORE SNAPSHOT rustfs_demo.demo_snapshot ); ``` -Wait for the restore job to finish and confirm the data: +リストアジョブの完了を待ち、データを確認します。 ```sql SHOW RESTORE; @@ -126,36 +126,36 @@ SELECT count(*) FROM rustfs_demo.events; 2 ``` -## 5. Stop or reset the deployment +## 5. デプロイを停止またはリセットする -Stop Doris while keeping the data: +データを残したまま Doris を停止します。 ```bash docker rm -f doris ``` -The backup stays in the `doris-backups` bucket and can be restored into any Doris cluster that registers the same repository. To delete it, remove the bucket: +バックアップは `doris-backups` バケットに残り、同じリポジトリを登録した任意の Doris クラスターへリストアできます。削除する場合はバケットを取り除きます。 ```bash rc rb rustfs/doris-backups --force ``` -## Troubleshooting +## トラブルシューティング -### `UnknownHostException: doris-backups.rustfs` when creating the repository +### リポジトリ作成時に `UnknownHostException: doris-backups.rustfs` が出る -Doris is building a virtual-hosted hostname from the bucket and endpoint. Use the RustFS container IP address in `AWS_ENDPOINT` together with `AWS_PATH_STYLE_ACCESS = "true"`, as shown above. +Doris はバケットとエンドポイントから仮想ホスト形式のホスト名を組み立てています。上記のとおり、`AWS_ENDPOINT` に RustFS コンテナの IP アドレスを使い、`AWS_PATH_STYLE_ACCESS = "true"` を併用します。 -### The backup stays in `SNAPSHOTING` for a long time +### バックアップが長時間 `SNAPSHOTING` のままになる -The backend uploads the tablet files. Confirm the backend is healthy (`SHOW BACKENDS;`) and can reach the endpoint; the all-in-one image needs a minute or two after start before both processes report ready. +バックエンドがタブレットファイルをアップロードしています。バックエンドが健全で（`SHOW BACKENDS;`）、エンドポイントへ到達できることを確認します。オールインワンイメージでは、起動後に両方のプロセスが準備完了を報告するまで 1〜2 分かかります。 ### `Failed to create repository: ... file status` -The bucket does not exist or the credentials are wrong. Create `doris-backups` with `rc mb` and re-check the access key pair. +バケットが存在しないか、認証情報が誤っています。`rc mb` で `doris-backups` を作成し、アクセスキーの組を再確認します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Doris operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Doris backup and restore documentation](https://doris.apache.org/docs/data-operate/backup-restore/) to schedule periodic snapshots. +- 追加の Doris 操作を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- 定期スナップショットをスケジュールするには、[Doris のバックアップとリストアのドキュメント](https://doris.apache.org/docs/data-operate/backup-restore/)に従います。 diff --git a/content/ja/developer/integration/database/duckdb.md b/content/ja/developer/integration/database/duckdb.md index 578c34e34..8eecccd96 100644 --- a/content/ja/developer/integration/database/duckdb.md +++ b/content/ja/developer/integration/database/duckdb.md @@ -239,6 +239,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [DuckDB httpfs ドキュメント](https://duckdb.org/docs/stable/extensions/httpfs/overview)で、リージョン上書きや接続数制限などの高度なオプションを確認してください。 diff --git a/content/ja/developer/integration/database/index.md b/content/ja/developer/integration/database/index.md index 53e1550a6..09ce2d57e 100644 --- a/content/ja/developer/integration/database/index.md +++ b/content/ja/developer/integration/database/index.md @@ -1,11 +1,11 @@ --- -title: "Database" -description: "Connect databases to RustFS through S3-compatible object storage interfaces." +title: "データベース" +description: "S3 互換のオブジェクトストレージインターフェースを経由して、データベースを RustFS に接続します。" --- -Use **RustFS** as the object storage layer for databases that support an S3-compatible endpoint. +S3 互換エンドポイントをサポートするデータベースのオブジェクトストレージ層として **RustFS** を使用します。 -## Databases +## データベース - [ClickHouse](./clickhouse.md) - [Doris](./doris.md) @@ -17,4 +17,4 @@ Use **RustFS** as the object storage layer for databases that support an S3-comp - [Databend](./databend.md) - [Vitess](./vitess.md) -Keep database data and backups in a dedicated bucket and prefix, and use credentials scoped to the required bucket operations. +データベースのデータとバックアップは専用のバケットとプレフィックスにまとめ、必要なバケット操作だけに絞った認証情報を使用します。 diff --git a/content/ja/developer/integration/database/influxdb.md b/content/ja/developer/integration/database/influxdb.md index fd52a849c..45f38c92b 100644 --- a/content/ja/developer/integration/database/influxdb.md +++ b/content/ja/developer/integration/database/influxdb.md @@ -274,6 +274,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [InfluxDB 3 Core ドキュメント](https://docs.influxdata.com/influxdb3/core/)に従って、telegraf や書き込み API をデータプロデューサーとして接続してください。 diff --git a/content/ja/developer/integration/database/lancedb.md b/content/ja/developer/integration/database/lancedb.md index 38a0703ab..e846ffbbd 100644 --- a/content/ja/developer/integration/database/lancedb.md +++ b/content/ja/developer/integration/database/lancedb.md @@ -1,13 +1,13 @@ --- title: "LanceDB" -description: "Store and query LanceDB vector tables directly on RustFS." +description: "LanceDB のベクトルテーブルを RustFS 上に直接保存し、クエリします。" --- -This guide connects [LanceDB](https://github.com/lancedb/lancedb) — the open-source vector database built on the Lance columnar format — to **RustFS** as its storage backend. You will create a vector table directly at an `s3://` location, add rows, run a vector search, and confirm the Lance table files in the bucket. The workflow was verified with the `lancedb` Python package against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Lance カラムナ形式で構築されたオープンソースのベクトルデータベースである [LanceDB](https://github.com/lancedb/lancedb) を、ストレージのバックエンドとして **RustFS** に接続します。`s3://` ロケーションにベクトルテーブルを直接作成し、行を追加してベクトル検索を実行し、バケット内の Lance テーブルファイルを確認します。この流れは `lancedb` Python パッケージと `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Python 3.9 or newer. This deployment is intended for local integration testing, not production. +Python 3.9 以降が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,17 +15,17 @@ flowchart LR LanceDB -->|"Lance fragments + manifests"| RustFS["RustFS :9000"] ``` -LanceDB is embedded: there is no server to run. The Python (or Rust, or JavaScript) client talks to the bucket directly, storing each table as a `*.lance` directory with data fragments, version manifests, and transaction logs. +LanceDB は組み込みです。起動するサーバーはありません。Python（または Rust、JavaScript）クライアントがバケットと直接通信し、各テーブルをデータフラグメント、バージョンマニフェスト、トランザクションログを持つ `*.lance` ディレクトリとして保存します。 -## 1. Install the client +## 1. クライアントをインストールする ```bash pip install lancedb ``` -## 2. Create a table on RustFS +## 2. RustFS 上にテーブルを作成する -Connect straight to the bucket and create a table, replacing all connection placeholders. The `storage_options` keys follow Lance's object-store conventions; custom endpoints use path-style addressing: +バケットへ直接接続してテーブルを作成します。接続用のプレースホルダーはすべて置き換えます。`storage_options` のキーは Lance の object-store の規約に従います。カスタムエンドポイントではパススタイルアクセスを使います。 ```python title="lance_s3.py" import lancedb @@ -54,9 +54,9 @@ created: 5 rows after add: 6 rows ``` -The table URI uses the `s3://bucket/prefix` form; every write and read goes to RustFS over its S3 API. +テーブル URI は `s3://bucket/prefix` 形式です。すべての書き込みと読み取りは S3 API 経由で RustFS へ向かいます。 -## 3. Run a vector search +## 3. ベクトル検索を実行する ```python title="lance_search.py" import lancedb @@ -74,17 +74,17 @@ top3: [(99, 'query-target'), (4, 'row-4'), (3, 'row-3')] version: 2 ``` -The nearest neighbor is the row added in the previous step, and the version counter reflects the two commits (create and add). +最近傍は前の手順で追加した行であり、バージョンカウンタは 2 つのコミット（作成と追加）を反映します。 -## 4. Verify objects in RustFS +## 4. RustFS 内のオブジェクトを確認する -List the table prefix: +テーブルのプレフィックスを一覧します。 ```bash rc ls rustfs// -r ``` -Each table is a `.lance` directory holding data fragments, version manifests, and transaction records: +各テーブルは、データフラグメント、バージョンマニフェスト、トランザクションレコードを持つ `.lance` ディレクトリです。 ```text tables/events.lance/_transactions/0-b93cf795-fc3d-4bc9-88c8-e37baeefdd46.txn @@ -92,34 +92,34 @@ tables/events.lance/_versions/18446744073709551613.manifest tables/events.lance/data/101101011110110010000100e7a149411b847dbad6ebc7d47e.lance ``` -Multiple tables share the bucket under the `tables/` prefix, so one bucket can back an entire LanceDB workspace. +複数のテーブルは `tables/` プレフィックス配下でバケットを共有するため、1 つのバケットで LanceDB ワークスペース全体を支えられます。 -![LanceDB table files stored in the RustFS Console](./images/rustfs-lancedb-table.png) +![RustFS Console に保存された LanceDB のテーブルファイル](./images/rustfs-lancedb-table.png) -## 5. Stop or reset +## 5. 停止またはリセットする -LanceDB holds no server state. To delete the table: +LanceDB はサーバー状態を持ちません。テーブルを削除します。 ```bash rc rm rustfs//tables/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Connection or signature errors on first use +### 初回利用時の接続エラーまたは署名エラー -Confirm `endpoint` includes the scheme, `allow_http` is `"true"` for plain-HTTP endpoints, and the bucket exists. The `region` value is required by the S3 signer even though RustFS ignores it. +`endpoint` にスキームが含まれること、平文 HTTP のエンドポイントでは `allow_http` が `"true"` であること、バケットが存在することを確認します。`region` の値は、RustFS が無視しても S3 署名に必須です。 -### `Table not found` after creating it +### 作成後に `Table not found` が出る -LanceDB lists the bucket prefix to discover tables. A stale client cache or a wrong `tables/` prefix in the URI makes new tables invisible; reconnect with the same URI used at creation time. +LanceDB はバケットのプレフィックスを一覧してテーブルを検出します。クライアントキャッシュが古い場合や、URI の `tables/` プレフィックスが誤っている場合、新しいテーブルは見えません。作成時と同じ URI で再接続します。 -### Slow bulk loads over the network +### ネットワーク越しの一括ロードが遅い -Lance writes one fragment per commit. For large imports, batch rows into fewer `table.add` calls — each call produces a new data file in the bucket. +Lance はコミットごとに 1 つのフラグメントを書き込みます。大規模な取り込みでは、行をまとめて `table.add` の呼び出し回数を減らします。呼び出しのたびにバケットへ新しいデータファイルが作られます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional LanceDB storage options. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [LanceDB documentation](https://lancedb.github.io/lancedb/) for ANN indexes, hybrid search, and multi-tenant bucket layouts on top of the same backend. +- 追加の LanceDB ストレージオプションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- 同じバックエンド上で ANN インデックス、ハイブリッド検索、マルチテナントのバケットレイアウトを使うには、[LanceDB ドキュメント](https://lancedb.github.io/lancedb/)に従います。 diff --git a/content/ja/developer/integration/database/milvus.md b/content/ja/developer/integration/database/milvus.md index 2b17701bf..6f19d022f 100644 --- a/content/ja/developer/integration/database/milvus.md +++ b/content/ja/developer/integration/database/milvus.md @@ -1,19 +1,19 @@ --- title: "Milvus" -description: "Run Milvus with RustFS as its S3-compatible object storage backend using Docker Compose." +description: "Docker Compose を使い、S3 互換オブジェクトストレージのバックエンドとして RustFS で Milvus を実行します。" --- -This guide runs **Milvus Standalone** with **RustFS** as its S3-compatible object storage backend. You will start Milvus, etcd, RustFS, and Attu; insert sample vectors; and verify that Milvus persists objects in RustFS. +このガイドでは、S3 互換オブジェクトストレージのバックエンドとして **RustFS** を使い、**Milvus Standalone** を実行します。Milvus、etcd、RustFS、Attu を起動し、サンプルベクトルを挿入して、Milvus がオブジェクトを RustFS に永続化することを確認します。 -You need Docker with the Compose plugin and Python 3.9 or later. This deployment is intended for local integration testing, not production. +Docker と Compose プラグイン、および Python 3.9 以降が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -:::note[Milvus configuration names] +:::note[Milvus の設定名] -Milvus groups S3-compatible storage settings under the `minio` configuration key. The name does not require a MinIO server. In this guide, `minio.address` points to the RustFS service, and Milvus uses the S3 API exposed by RustFS. +Milvus は S3 互換ストレージの設定を `minio` 設定キーの下にまとめます。この名前であっても MinIO サーバーは不要です。このガイドでは `minio.address` が RustFS サービスを指し、Milvus は RustFS が公開する S3 API を使います。 ::: -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -24,27 +24,27 @@ flowchart LR Init["Bucket initializer"] -->|Create my-bucket| RustFS ``` -Milvus stores service metadata in etcd and persists vector data, indexes, and related objects under `s3://my-bucket/milvus` in RustFS. The local Milvus volume remains necessary for runtime data and caches. +Milvus はサービスのメタデータを etcd に保存し、ベクトルデータ、インデックス、関連オブジェクトを RustFS の `s3://my-bucket/milvus` 配下に永続化します。ローカルの Milvus ボリュームは、ランタイムデータとキャッシュのために引き続き必要です。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create a working directory: +作業ディレクトリを作成します。 ```bash mkdir rustfs-milvus cd rustfs-milvus ``` -Create an environment file and replace both credential placeholders: +環境ファイルを作成し、両方の認証情報プレースホルダーを置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use dedicated credentials for the Milvus bucket. Do not commit `.env` to source control. +Milvus バケットには専用の認証情報を使います。`.env` をソース管理にコミットしないでください。 -Create the Milvus storage override: +Milvus のストレージ上書きを作成します。 ```yaml title="user.yaml" common: @@ -62,9 +62,9 @@ minio: useVirtualHost: false ``` -`useVirtualHost: false` selects path-style S3 requests. The hostname `rustfs` resolves inside the Compose network; clients on the host use `http://localhost:9000`. +`useVirtualHost: false` はパススタイルアクセスの S3 リクエストを選びます。ホスト名 `rustfs` は Compose ネットワーク内で解決されます。ホスト上のクライアントは `http://localhost:9000` を使います。 -Create the Compose file: +Compose ファイルを作成します。 ```yaml title="compose.yaml" services: @@ -186,46 +186,46 @@ volumes: milvus-data: ``` -The `create-bucket` service uses the official [`rc`](https://github.com/rustfs/cli) image and exits after ensuring that `my-bucket` exists. Named volumes preserve etcd metadata, RustFS objects, and Milvus local data when containers are recreated. +`create-bucket` サービスは公式の [`rc`](https://github.com/rustfs/cli) イメージを使い、`my-bucket` が存在することを確認してから終了します。名前付きボリュームは、コンテナを作り直しても etcd のメタデータ、RustFS のオブジェクト、Milvus のローカルデータを保持します。 -:::warning[Protect local service ports] +:::warning[ローカルのサービスポートを保護する] -The Compose file publishes the RustFS API and Console, Milvus gRPC and health ports, and Attu on the host for local testing. Do not expose these ports to an untrusted network. Production deployments require scoped credentials, TLS, authentication, resource planning, backups, and independently operated dependencies. +Compose ファイルは、ローカルテストのため、RustFS の API と Console、Milvus の gRPC とヘルスポート、Attu をホストに公開します。これらのポートを信頼できないネットワークへ公開しないでください。本番のデプロイには、スコープを絞った認証情報、TLS、認証、リソース計画、バックアップ、および独立して運用する依存コンポーネントが必要です。 ::: -## 2. Validate and start the deployment +## 2. デプロイを検証して起動する -Resolve the Compose file before starting containers: +コンテナを起動する前に Compose ファイルを解決します。 ```bash docker compose config ``` -Start the services: +サービスを起動します。 ```bash docker compose up -d docker compose ps -a ``` -The `create-bucket` service should exit with code `0`, and `etcd`, `rustfs`, and `standalone` should become healthy. Inspect logs if a service does not reach its expected state: +`create-bucket` サービスはコード `0` で終了する想定です。`etcd`、`rustfs`、`standalone` は健全な状態になる想定です。期待する状態にならないサービスはログを確認します。 ```bash docker compose logs create-bucket rustfs standalone ``` -Open these local interfaces: +次のローカルインターフェースを開きます。 - RustFS Console: `http://localhost:9001` - Attu: `http://localhost:8000` -- Milvus health endpoint: `http://localhost:9091/healthz` +- Milvus のヘルスエンドポイント: `http://localhost:9091/healthz` -Attu connects to `standalone:19530` through the Compose network. If Attu asks for a connection address, use that service name instead of `localhost:19530`. +Attu は Compose ネットワーク経由で `standalone:19530` に接続します。Attu が接続先アドレスを求める場合は、`localhost:19530` ではなくそのサービス名を使います。 -## 3. Insert and query sample vectors +## 3. サンプルベクトルを挿入してクエリする -Create a Python virtual environment and install the Milvus client version that matches the server release: +Python の仮想環境を作成し、サーバーのリリースに合う Milvus クライアントのバージョンをインストールします。 ```bash python3 -m venv .venv @@ -233,7 +233,7 @@ source .venv/bin/activate python -m pip install "pymilvus==2.6.0" ``` -Create a test script: +テストスクリプトを作成します。 ```python title="verify_milvus.py" from pymilvus import MilvusClient @@ -270,85 +270,85 @@ print(results) client.close() ``` -Run the script: +スクリプトを実行します。 ```bash python verify_milvus.py ``` -The result should rank the row with ID `1` first. Open Attu and confirm that the `rustfs_demo` collection contains three entities. +結果では、ID `1` の行が先頭になる想定です。Attu を開き、`rustfs_demo` コレクションに 3 つのエンティティがあることを確認します。 -## 4. Verify Milvus objects in RustFS +## 4. RustFS 内の Milvus オブジェクトを確認する -Use the bucket-initializer image to list objects below the configured `milvus` root path: +バケット初期化用のイメージを使い、設定した `milvus` ルートパス配下のオブジェクトを一覧します。 ```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" --region us-east-1 --bucket-lookup path >/dev/null && /usr/bin/rc find rustfs/my-bucket/milvus' ``` -The output should contain objects created by Milvus below the `milvus/` prefix. You can also open `my-bucket` in the RustFS Console. +出力には、`milvus/` プレフィックス配下に Milvus が作成したオブジェクトが含まれる想定です。RustFS Console で `my-bucket` を開くこともできます。 -Milvus may buffer or compact data before every expected object appears. The successful insert, flush, query, and RustFS object listing together validate the integration path. +Milvus は、想定するオブジェクトがすべて現れる前にデータをバッファまたはコンパクトすることがあります。挿入、フラッシュ、クエリの成功と、RustFS のオブジェクト一覧をあわせて、連携経路を検証します。 -## 5. Stop or reset the stack +## 5. スタックを停止またはリセットする -Stop the containers while retaining all named volumes: +名前付きボリュームをすべて残したままコンテナを停止します。 ```bash docker compose down ``` -To delete the local test data, including the Milvus bucket contents and etcd metadata, explicitly remove the volumes: +Milvus バケットの内容と etcd のメタデータを含むローカルのテストデータを削除するには、ボリュームを明示的に取り除きます。 ```bash docker compose down --volumes ``` -:::warning[Reset removes the test data] +:::warning[リセットはテストデータを削除する] -The `--volumes` option permanently deletes the named volumes used by this Compose project. Do not run it against data you need to retain. +`--volumes` オプションは、この Compose プロジェクトが使う名前付きボリュームを完全に削除します。残す必要があるデータに対しては実行しないでください。 ::: -## Troubleshooting +## トラブルシューティング -### Milvus cannot reach RustFS +### Milvus から RustFS に到達できない -Use `rustfs:9000` as the S3 endpoint inside Compose. `localhost:9000` inside the Milvus container refers to that container, not RustFS. +Compose 内の S3 エンドポイントは `rustfs:9000` です。Milvus コンテナ内の `localhost:9000` はそのコンテナ自身を指し、RustFS ではありません。 -Confirm that `useVirtualHost` remains `false` and that the credential values passed to Milvus match the RustFS credentials: +`useVirtualHost` が `false` のままであること、Milvus に渡す認証情報が RustFS の認証情報と一致することを確認します。 ```bash docker compose logs standalone rustfs ``` -### The bucket initializer fails +### バケット初期化が失敗する -Check RustFS readiness and the initializer logs: +RustFS の準備完了と初期化ログを確認します。 ```bash curl -fsS http://localhost:9000/health/ready docker compose logs create-bucket ``` -Verify that `.env` contains non-empty credentials and that `docker compose config` resolves both variables. +`.env` に空でない認証情報があり、`docker compose config` が両方の変数を解決することを確認します。 -### Milvus starts without existing data +### 既存データなしで Milvus が起動する -Do not change `minio.bucketName`, `minio.rootPath`, or the etcd root for an existing deployment. Confirm that the `rustfs-data`, `etcd-data`, and `milvus-data` volumes still exist and that the same Compose project name is in use. +既存のデプロイでは `minio.bucketName`、`minio.rootPath`、etcd のルートを変更しないでください。`rustfs-data`、`etcd-data`、`milvus-data` のボリュームが残っており、同じ Compose プロジェクト名を使っていることを確認します。 -### Attu cannot connect +### Attu が接続できない -The Attu container must use `standalone:19530`. A browser or host-side client uses `localhost:19530`. Check Milvus health and Attu logs: +Attu コンテナは `standalone:19530` を使う必要があります。ブラウザーまたはホスト側のクライアントは `localhost:19530` を使います。Milvus のヘルスと Attu のログを確認します。 ```bash curl -fsS http://localhost:9091/healthz docker compose logs attu standalone ``` -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before enabling additional Milvus storage features. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Milvus documentation](https://milvus.io/docs) when adapting this local pattern to a managed or distributed deployment. \ No newline at end of file +- 追加の Milvus ストレージ機能を有効にする前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- このローカルのパターンをマネージドまたは分散デプロイへ合わせるときは、[Milvus ドキュメント](https://milvus.io/docs)に従います。 diff --git a/content/ja/developer/integration/database/trino.md b/content/ja/developer/integration/database/trino.md index c6ced2379..1a006468f 100644 --- a/content/ja/developer/integration/database/trino.md +++ b/content/ja/developer/integration/database/trino.md @@ -203,7 +203,7 @@ RustFS コンソールでこのプレフィックスを参照することもで ## 6. RustFS S3 Tables を使用する -RustFS S3 Tables は組み込みの Apache Iceberg REST カタログを提供します。Trino はテーブルバケットを管理された Iceberg ウェアハウスとして扱え、データは RustFS 内に保持されます。[S3 Tables](/administration/data/s3-tables) の説明に従ってテーブルバケットを有効化し、Trino の Iceberg コネクタを REST カタログに接続してください。REST カタログ URI は `http://:9000/iceberg`、ウェアハウスはバケット名で、カタログリクエスト（AWS Signature Version 4、署名名 `s3`）と S3 ファイルアクセスの両方がパススタイルアクセスを使います。 +RustFS S3 Tables は組み込みの Apache Iceberg REST カタログを提供します。Trino はテーブルバケットを管理された Iceberg ウェアハウスとして扱え、データは RustFS 内に保持されます。[S3 Tables](/ja/administration/data/s3-tables) の説明に従ってテーブルバケットを有効化し、Trino の Iceberg コネクタを REST カタログに接続してください。REST カタログ URI は `http://:9000/iceberg`、ウェアハウスはバケット名で、カタログリクエスト（AWS Signature Version 4、署名名 `s3`）と S3 ファイルアクセスの両方がパススタイルアクセスを使います。 S3 Tables のサポートマトリックスでは、Trino はカタログに対する読み取り専用プローブが行われた段階です。本番でこの経路を採用する前に、書き込み互換性と実際にデプロイする Trino バージョンを検証してください。 @@ -245,6 +245,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [Trino ドキュメント](https://trino.io/docs/current/)に従って、BI ツールを接続したりオブジェクトストレージカタログを追加したりしてください。 diff --git a/content/ja/developer/integration/database/vitess.md b/content/ja/developer/integration/database/vitess.md index 2260b7449..a2220f83f 100644 --- a/content/ja/developer/integration/database/vitess.md +++ b/content/ja/developer/integration/database/vitess.md @@ -1,13 +1,13 @@ --- title: "Vitess" -description: "Back up Vitess to RustFS through the S3 backup storage implementation." +description: "S3 バックアップストレージ実装を通じて、Vitess を RustFS にバックアップします。" --- -This guide connects [Vitess](https://github.com/vitessio/vitess) — the database clustering system for horizontal scaling of MySQL — to **RustFS** through Vitess's S3 backup storage implementation. You will bring up a minimal Vitess topology on a single host, run `Backup` on a tablet, and confirm the backup chunks and `MANIFEST` in the bucket, then read the backup list back from RustFS. The workflow was verified with `vitess/lite` (Vitess v25.0.0-SNAPSHOT, built 2026-09-22), MySQL 8.4, and `rustfs/rustfs-x86-musl:v2.3.1`; stable Vitess 20+ releases use the same flags. +このガイドでは、MySQL を水平スケールするためのデータベースクラスターシステムである [Vitess](https://github.com/vitessio/vitess) を、Vitess の S3 バックアップストレージ実装を通じて **RustFS** に接続します。単一ホスト上に最小の Vitess トポロジーを立ち上げ、タブレットで `Backup` を実行し、バケット内のバックアップチャンクと `MANIFEST` を確認したあと、バックアップ一覧を RustFS から読み戻します。この流れは `vitess/lite`（Vitess v25.0.0-SNAPSHOT、ビルド日 2026-09-22）、MySQL 8.4、`rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。安定版の Vitess 20 以降も同じフラグを使います。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,11 +16,11 @@ flowchart LR Tablet -->|"S3 API"| RustFS["RustFS :9000"] ``` -`vtctld` triggers the backup, but the `vttablet` owning the tablet performs it: it snapshots MySQL, compresses the data into numbered chunks, and uploads them together with a `MANIFEST` through the S3-compatible endpoint. +`vtctld` がバックアップを起動しますが、実行するのはそのタブレットを所有する `vttablet` です。MySQL をスナップショットし、データを番号付きチャンクへ圧縮し、`MANIFEST` とともに S3 互換エンドポイント経由でアップロードします。 -## 1. Run etcd and the Vitess image +## 1. etcd と Vitess イメージを実行する -Vitess stores its topology in etcd, and the `vitess/lite` image ships all Vitess binaries plus MySQL: +Vitess はトポロジーを etcd に保存します。`vitess/lite` イメージには Vitess のバイナリ一式と MySQL が含まれます。 ```bash docker run -d --name etcd --hostname etcd --network oo-rustfs_default \ @@ -34,26 +34,26 @@ docker run -d --name vtess --hostname vtess --network oo-rustfs_default \ vitess/lite:latest sleep infinity ``` -The AWS environment variables supply the credentials for the S3 backup storage in both `vtctld` and `vttablet`. +AWS の環境変数は、`vtctld` と `vttablet` の両方で S3 バックアップストレージの認証情報になります。 -## 2. Initialize MySQL +## 2. MySQL を初期化する -Initialize a MySQL instance in the standard Vitess tablet directory so `vttablet` can load its `my.cnf` later: +`vttablet` が後から `my.cnf` を読み込めるよう、標準の Vitess タブレットディレクトリで MySQL インスタンスを初期化します。 ```bash docker exec vtess sh -c \ "/vt/bin/mysqlctl --log_dir /tmp/vtlogs init --tablet-dir vt_0000000100" ``` -The instance is ready when the socket file exists: +ソケットファイルが存在すれば、インスタンスの準備は完了です。 ```text /vt/vtdataroot/vt_0000000100/mysql.sock ``` -## 3. Start vtctld and vttablet +## 3. vtctld と vttablet を起動する -Start `vtctld` with the S3 backup flags, register the cell, and start the tablet. Replace all connection placeholders: +S3 バックアップフラグ付きで `vtctld` を起動し、セルを登録してタブレットを起動します。接続用のプレースホルダーはすべて置き換えます。 ```bash docker exec vtess sh -c "nohup /vt/bin/vtctld \ @@ -95,7 +95,7 @@ docker exec vtess sh -c "nohup /vt/bin/vttablet \ --log_dir /tmp/vtlogs > /tmp/vtlogs/vttablet.out 2>&1 &" ``` -Both processes carry the S3 flags because `vttablet` performs the backup while `vtctld` lists and removes backups. `--s3-backup-force-path-style` is mandatory for non-AWS endpoints. Check that the tablet registered: +バックアップを実行するのは `vttablet` で、バックアップの一覧と削除を行うのは `vtctld` です。そのため両方のプロセスに S3 フラグを付けます。AWS 以外のエンドポイントでは `--s3-backup-force-path-style` が必須です。タブレットが登録されたことを確認します。 ```bash docker exec vtess /vt/bin/vtctldclient --server localhost:15998 GetTablets @@ -105,9 +105,9 @@ docker exec vtess /vt/bin/vtctldclient --server localhost:15998 GetTablets zone1-0000000100 commerce 0 replica vtess:15100 vtess:3306 [] ``` -## 4. Run the backup +## 4. バックアップを実行する -Create the bucket and trigger the backup: +バケットを作成し、バックアップを起動します。 ```bash rc mb rustfs/vitess-backups @@ -116,21 +116,21 @@ docker exec vtess /vt/bin/vtctldclient --server localhost:15998 \ Backup zone1-0000000100 ``` -The stream ends with the engine writing the manifest: +ストリームは、エンジンがマニフェストを書き込んで終了します。 ```text commerce/0 (zone1-0000000100): ... value:"Completed backing up MANIFEST (attempt 1/2)" ``` -## 5. Verify objects in RustFS +## 5. RustFS 内のオブジェクトを確認する -List the backup prefix: +バックアップのプレフィックスを一覧します。 ```bash rc ls rustfs/vitess-backups/ -r | head -4 ``` -The tablet uploaded compressed data chunks plus the metadata files: +タブレットは、圧縮したデータチャンクとメタデータファイルをアップロードしました。 ```text commerce/commerce/0/2026-09-23.011225.zone1-0000000100/0 @@ -138,9 +138,9 @@ commerce/commerce/0/2026-09-23.011225.zone1-0000000100/1 commerce/commerce/0/2026-09-23.011225.zone1-0000000100/MANIFEST ``` -![Vitess backup files stored in the RustFS Console](./images/rustfs-vitess-backups.png) +![RustFS Console に保存された Vitess のバックアップファイル](./images/rustfs-vitess-backups.png) -Read the backup list back from RustFS through `vtctld`: +`vtctld` を通じて、バックアップ一覧を RustFS から読み戻します。 ```bash docker exec vtess /vt/bin/vtctldclient --server localhost:15998 GetBackups commerce/0 @@ -150,40 +150,40 @@ docker exec vtess /vt/bin/vtctldclient --server localhost:15998 GetBackups comme 2026-09-23.011225.zone1-0000000100 ``` -## 6. Stop or reset +## 6. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを撤去します。 ```bash docker rm -f vtess etcd ``` -To delete the stored backups: +保存したバックアップを削除します。 ```bash rc rm rustfs/vitess-backups/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `cannot perform backup without my.cnf` -Passing connection parameters such as `--db-socket` or `--db-host` makes `vttablet` skip loading `my.cnf`, and backups refuse to run. Start `vttablet` with `--mycnf-file` pointing at the instance config and let it discover the socket from there — this is why the MySQL instance lives in the `vt_0000000100` directory from step 2. +`--db-socket` や `--db-host` などの接続パラメーターを渡すと、`vttablet` は `my.cnf` の読み込みを省略し、バックアップは実行を拒否します。インスタンス設定を指す `--mycnf-file` で `vttablet` を起動し、ソケットはそこから検出させます。手順 2 で MySQL インスタンスを `vt_0000000100` ディレクトリに置くのはこのためです。 ### `unknown service vtctlservice.Vtctld` -`vtctld` exposes the API used by `vtctldclient` only when the service map includes it: `--service-map grpc-vtctl,grpc-vtctld`. Also make sure `vtctldclient --server` points at the gRPC port (`15998` here), not the web UI port. +`vtctld` が `vtctldclient` の使う API を公開するのは、サービスマップにそれが含まれる場合だけです。`--service-map grpc-vtctl,grpc-vtctld` を指定します。また `vtctldclient --server` は Web UI のポートではなく gRPC ポート（ここでは `15998`）を指す必要があります。 ### `node doesn't exist: /vitess/global/cells/zone1/CellInfo` -The cell must exist before tablets register. Run `vtctldclient AddCellInfo` as shown in step 3 before starting `vttablet`. +タブレットが登録される前にセルが存在する必要があります。`vttablet` を起動する前に、手順 3 のとおり `vtctldclient AddCellInfo` を実行します。 -### Flag parse errors such as `unknown shorthand flag` +### `unknown shorthand flag` などのフラグ解析エラー -Vitess 20+ normalizes underscores to dashes, so write flags in dash style (`--tablet-path`). A single-dash long flag like `-tablet_dir` is parsed as shorthand options and fails. +Vitess 20 以降はアンダースコアをダッシュへ正規化するため、フラグはダッシュ形式（`--tablet-path`）で書きます。`-tablet_dir` のようなシングルダッシュのロングフラグは短縮オプションとして解析され、失敗します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Vitess storage options. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Vitess backup and restore documentation](https://vitess.io/docs/user-guides/configuration-basic/#backups) to schedule backups and restore tablets from the bucket. +- 追加の Vitess ストレージオプションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認します。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- バックアップのスケジュールと、バケットからのタブレットのリストアについては、[Vitess のバックアップとリストアのドキュメント](https://vitess.io/docs/user-guides/configuration-basic/#backups)に従います。 diff --git a/content/ja/developer/integration/devops/elasticsearch.md b/content/ja/developer/integration/devops/elasticsearch.md index 148211db6..6f7919408 100644 --- a/content/ja/developer/integration/devops/elasticsearch.md +++ b/content/ja/developer/integration/devops/elasticsearch.md @@ -1,13 +1,13 @@ --- title: "Elasticsearch" -description: "Use RustFS as the S3 snapshot repository for Elasticsearch indices, deployed with Docker Compose." +description: "Docker Compose でデプロイし、Elasticsearch インデックスの S3 スナップショットリポジトリとして RustFS を使用します。" --- -This guide connects [Elasticsearch](https://github.com/elastic/elasticsearch) — the distributed search and analytics engine — to **RustFS** as the S3 snapshot repository for its indices. You will start Elasticsearch with the `repository-s3` plugin, register a snapshot repository backed by RustFS, index documents, take a snapshot, and prove the full cycle by deleting the index and restoring it from RustFS. The workflow was verified with `docker.elastic.co/elasticsearch/elasticsearch:8.18.0` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、分散検索・分析エンジンである [Elasticsearch](https://github.com/elastic/elasticsearch) を、インデックスの S3 スナップショットリポジトリとして **RustFS** に接続します。`repository-s3` プラグインを有効にして Elasticsearch を起動し、RustFS をバックエンドとするスナップショットリポジトリを登録し、ドキュメントをインデックスに投入してスナップショットを取得します。その後インデックスを削除し、RustFS から復元して一連の流れを確認します。この流れは `docker.elastic.co/elasticsearch/elasticsearch:8.18.0` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker with the Compose plugin. This deployment is intended for local integration testing, not production. +Docker と Compose プラグインが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,27 +16,27 @@ flowchart LR Init["init-bucket job"] -->|"create my-bucket"| RustFS ``` -Elasticsearch stores its primary data on local disks and offloads index backups to a snapshot repository. The `repository-s3` plugin writes snapshot metadata and shard data blobs to RustFS through the S3 API with path-style addressing over plain HTTP. +Elasticsearch は主データをローカルディスクに保持し、インデックスのバックアップをスナップショットリポジトリへ退避します。`repository-s3` プラグインは、平文 HTTP 上のパススタイルアクセスで S3 API を使い、スナップショットのメタデータとシャードデータのブロブを RustFS に書き込みます。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create a working directory: +作業ディレクトリを作成します。 ```bash mkdir rustfs-elasticsearch cd rustfs-elasticsearch ``` -Create an environment file and replace both credential placeholders: +環境変数ファイルを作成し、2 つの認証情報プレースホルダーを置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use dedicated credentials for the bucket. Do not commit `.env` to source control. +バケットには専用の認証情報を使用してください。`.env` をバージョン管理にコミットしないでください。 -Elasticsearch splits its S3 settings between `elasticsearch.yml` (non-secret values) and the keystore (credentials). Create the configuration file: +Elasticsearch は S3 設定を `elasticsearch.yml`（機密でない値）とキーストア（認証情報）に分けます。設定ファイルを作成します。 ```yaml title="elasticsearch.yml" discovery.type: single-node @@ -47,7 +47,7 @@ s3.client.default.path_style_access: "true" s3.client.default.region: "us-east-1" ``` -Create the Compose file: +Compose ファイルを作成します。 ```yaml title="compose.yaml" services: @@ -121,26 +121,26 @@ volumes: rustfs-data: ``` -`repository-s3` is a bundled plugin and installs without network access. Only the access key and secret key belong in the keystore — non-secure settings such as the endpoint must live in `elasticsearch.yml`, otherwise the node refuses to start. +`repository-s3` は同梱プラグインであり、ネットワークなしでインストールできます。キーストアに入れるのはアクセスキーとシークレットキーだけです。エンドポイントなどの非セキュア設定は `elasticsearch.yml` に置く必要があります。そうしないとノードは起動を拒否します。 -## 2. Start the deployment +## 2. デプロイを開始する -Resolve the Compose file before starting containers: +コンテナを起動する前に Compose ファイルを解決します。 ```bash docker compose config ``` -Start the services and wait for Elasticsearch to finish booting (the first start installs the plugin and creates the keystore entries, which takes a minute or two): +サービスを起動し、Elasticsearch の起動完了を待ちます。初回起動ではプラグインのインストールとキーストアへの登録が行われ、1〜2 分かかります。 ```bash docker compose up -d curl -s http://localhost:9200 ``` -## 3. Register the snapshot repository and index documents +## 3. スナップショットリポジトリを登録してドキュメントを投入する -Register RustFS as the snapshot repository, create an index, and index five documents: +RustFS をスナップショットリポジトリとして登録し、インデックスを作成して 5 件のドキュメントを投入します。 ```bash curl -s -X PUT "http://localhost:9200/_snapshot/rustfs_repo" \ @@ -164,9 +164,9 @@ curl -s "http://localhost:9200/rustfs_index/_count" {"count":5,...} ``` -## 4. Take a snapshot +## 4. スナップショットを取得する -Create a snapshot with `wait_for_completion` so the result is known immediately: +`wait_for_completion` を付けてスナップショットを作成し、結果をすぐに確認できるようにします。 ```bash curl -s -X PUT "http://localhost:9200/_snapshot/rustfs_repo/snap1?wait_for_completion=true" @@ -176,16 +176,16 @@ curl -s -X PUT "http://localhost:9200/_snapshot/rustfs_repo/snap1?wait_for_compl {"snapshot":{"snapshot":"snap1",...,"indices":["rustfs_index"],"shards":{"total":1,"failed":0,"successful":1}}} ``` -## 5. Verify objects in RustFS +## 5. RustFS 内のオブジェクトを確認する -List the snapshot objects through the bucket-initializer image: +バケット初期化用イメージを使ってスナップショットのオブジェクトを一覧します。 ```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/indices --recursive' ``` -Snapshot metadata and shard data blobs live under `indices/` in the bucket: +スナップショットのメタデータとシャードデータのブロブは、バケット内の `indices/` 配下にあります。 ```text [2026-09-21 02:58:01] 3.56 KiB indices/mvyat2-dSEOG3uiCCiFzRA/0/__LbLsSgUUTpqji_EXvqHYCg @@ -193,13 +193,13 @@ Snapshot metadata and shard data blobs live under `indices/` in the bucket: [2026-09-21 02:58:01] 1.00 KiB indices/mvyat2-dSEOG3uiCCiFzRA/0/index-e9P8q6E9QhitpkiOdgjVDQ ``` -You can also browse the prefix in the RustFS Console: +RustFS Console（管理画面）でこのプレフィックスを参照することもできます。 -![Elasticsearch snapshot blobs stored in the RustFS Console](./images/rustfs-es-snapshots.png) +![RustFS Console に保存された Elasticsearch のスナップショットブロブ](./images/rustfs-es-snapshots.png) -## 6. Restore the index from RustFS +## 6. RustFS からインデックスを復元する -Delete the index, then restore it from the snapshot: +インデックスを削除してから、スナップショットから復元します。 ```bash curl -s -X DELETE "http://localhost:9200/rustfs_index" > /dev/null @@ -211,31 +211,31 @@ curl -s "http://localhost:9200/rustfs_index/_count" {"count":5,...} ``` -The documents come back because the snapshot blobs were read from RustFS. +スナップショットのブロブが RustFS から読み戻されるため、ドキュメントが戻ります。 -## 7. Stop or reset the stack +## 7. スタックを停止・リセットする -Stop the containers while keeping the RustFS data volume: +RustFS データボリュームを保持したままコンテナを停止します。 ```bash docker compose down ``` -To delete the snapshots and start from an empty RustFS volume, explicitly include `--volumes`: +スナップショットを削除して空の RustFS ボリュームからやり直す場合は、明示的に `--volumes` を付けます。 ```bash docker compose down --volumes ``` -## Troubleshooting +## トラブルシューティング -### The node refuses to start with "non-secure setting ... must be stored inside elasticsearch.yml" +### ノードが "non-secure setting ... must be stored inside elasticsearch.yml" で起動を拒否する -Only `s3.client.default.access_key` and `s3.client.default.secret_key` belong in the keystore. Endpoint, protocol, path-style access, and region are non-secure settings and must be defined in `elasticsearch.yml`. +キーストアに入れるのは `s3.client.default.access_key` と `s3.client.default.secret_key` だけです。エンドポイント、プロトコル、パススタイルアクセス、リージョンは非セキュア設定であり、`elasticsearch.yml` に定義する必要があります。 -### Restored or new shards stay unassigned +### 復元したシャードや新しいシャードが未割り当てのままになる -Elasticsearch stops allocating shards when disk usage passes the low watermark (85 percent by default). Free disk space, or disable the check for a local test: +ディスク使用率がローウォーターマーク（low watermark、デフォルト 85%）を超えると、Elasticsearch はシャードの割り当てを停止します。ディスクの空きを確保するか、ローカルテストでは次のチェックを無効にします。 ```bash curl -s -X PUT "http://localhost:9200/_cluster/settings" \ @@ -243,20 +243,20 @@ curl -s -X PUT "http://localhost:9200/_cluster/settings" \ -d '{"transient":{"cluster.routing.allocation.disk.threshold_enabled":false}}' ``` -### Restore fails because the index already exists +### インデックスが既に存在するため復元に失敗する -A previous failed restore leaves the index behind. Delete it with `DELETE /rustfs_index` and run the restore again. +以前の失敗した復元でインデックスが残っている場合があります。`DELETE /rustfs_index` で削除してから、復元を再実行します。 -### AccessDenied or 403 responses +### AccessDenied や 403 レスポンス -Confirm that the credentials in the keystore match the RustFS credentials and that the `create-bucket` service completed successfully: +キーストアの認証情報が RustFS の認証情報と一致しているか、`create-bucket` サービスが正常に完了しているかを確認します。 ```bash docker compose logs create-bucket ``` -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional S3 operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Elasticsearch snapshot documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html) for snapshot lifecycle management (SLM). +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [Elasticsearch のスナップショットドキュメント](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html)に従い、スナップショットライフサイクル管理（SLM）を設定してください。 diff --git a/content/ja/developer/integration/devops/gitea.md b/content/ja/developer/integration/devops/gitea.md index 239b6ad25..2eb512cb9 100644 --- a/content/ja/developer/integration/devops/gitea.md +++ b/content/ja/developer/integration/devops/gitea.md @@ -1,13 +1,13 @@ --- title: "Gitea" -description: "Run Gitea with RustFS as the S3 storage backend for LFS objects and attachments, deployed with Docker Compose." +description: "Docker Compose でデプロイし、LFS オブジェクトと添付ファイルの S3 ストレージバックエンドとして RustFS を使って Gitea を実行します。" --- -This guide connects [Gitea](https://github.com/go-gitea/gitea) — the self-hosted Git service — to **RustFS** through Gitea's `minio` storage type. You will start Gitea with Docker Compose, create a repository, push a Git LFS object, attach a file to an issue, and verify that both the LFS object and the attachment are stored in RustFS. The workflow was verified with `gitea/gitea:1.24.4` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、セルフホストの Git サービスである [Gitea](https://github.com/go-gitea/gitea) を、Gitea の `minio` ストレージタイプ経由で **RustFS** に接続します。Docker Compose で Gitea を起動し、リポジトリを作成し、Git LFS オブジェクトを push し、Issue にファイルを添付して、LFS オブジェクトと添付ファイルの両方が RustFS に保存されることを確認します。この流れは `gitea/gitea:1.24.4` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker with the Compose plugin and the `git` and `git-lfs` clients on your workstation. This deployment is intended for local integration testing, not production. +Docker と Compose プラグイン、およびワークステーション上の `git` と `git-lfs` クライアントが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,27 +15,27 @@ flowchart LR Gitea -->|"LFS + attachments"| RustFS["RustFS :9000"] ``` -Gitea stores the Git repository itself on its local disk, while the `minio` storage type routes large files — LFS objects, issue attachments, avatars, repository archives, packages, and Actions artifacts — to the `gitea-data` bucket in RustFS. Gitea creates the bucket on startup if it does not exist. +Gitea は Git リポジトリ自体をローカルディスクに保持し、`minio` ストレージタイプが大きなファイル（LFS オブジェクト、Issue の添付ファイル、アバター、リポジトリアーカイブ、パッケージ、Actions のアーティファクト）を RustFS の `gitea-data` バケットへ送ります。バケットが存在しない場合、Gitea は起動時に作成します。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create a working directory: +作業ディレクトリを作成します。 ```bash mkdir rustfs-gitea cd rustfs-gitea ``` -Create an environment file and replace both credential placeholders: +環境変数ファイルを作成し、2 つの認証情報プレースホルダーを置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use dedicated credentials for the `gitea-data` bucket. Do not commit `.env` to source control. +`gitea-data` バケットには専用の認証情報を使用してください。`.env` をバージョン管理にコミットしないでください。 -Create the Gitea configuration and replace both credential placeholders with the same values you set in `.env` — the global `minio` storage type applies to LFS, attachments, avatars, repository archives, packages, and Actions artifacts: +Gitea の設定を作成し、2 つの認証情報プレースホルダーを `.env` と同じ値に置き換えます。グローバルな `minio` ストレージタイプは、LFS、添付ファイル、アバター、リポジトリアーカイブ、パッケージ、Actions のアーティファクトに適用されます。 ```ini title="app.ini" APP_NAME = RustFS Gitea @@ -70,9 +70,9 @@ INSTALL_LOCK = true SECRET_KEY = change-me-to-a-random-string ``` -`LFS_START_SERVER` enables the Git LFS HTTP API. `MINIO_ENDPOINT` uses the Compose-internal hostname `rustfs`; the endpoint is reached with path-style requests by default. +`LFS_START_SERVER` は Git LFS の HTTP API を有効にします。`MINIO_ENDPOINT` は Compose 内部のホスト名 `rustfs` を使います。エンドポイントへはデフォルトでパススタイルのリクエストが送られます。 -Create the Compose file: +Compose ファイルを作成します。 ```yaml title="compose.yaml" services: @@ -123,36 +123,36 @@ volumes: gitea-data: ``` -The volume-backed `/data` directory keeps the SQLite database and the Git repositories across container restarts, while LFS objects and attachments live in RustFS. +ボリューム上の `/data` ディレクトリは、コンテナを再起動しても SQLite データベースと Git リポジトリを保持します。LFS オブジェクトと添付ファイルは RustFS にあります。 -## 2. Validate and start the deployment +## 2. デプロイを検証して開始する -Resolve the Compose file before starting containers: +コンテナを起動する前に Compose ファイルを解決します。 ```bash docker compose config ``` -Start the services: +サービスを起動します。 ```bash docker compose up -d docker compose ps ``` -Watch the Gitea log until every storage backend reports the Minio type: +すべてのストレージバックエンドが Minio タイプを報告するまで、Gitea のログを確認します。 ```bash docker compose logs gitea | grep "Initialising" ``` -The output should list `Attachment`, `Avatar`, `LFS`, and the remaining storage sections, each followed by a `Creating Minio storage at rustfs:9000:gitea-data` line. +出力には `Attachment`、`Avatar`、`LFS`、および残りのストレージセクションが並び、それぞれに `Creating Minio storage at rustfs:9000:gitea-data` の行が続くはずです。 -Open `http://localhost:3000` and create the administrator account, then open the RustFS Console at `http://localhost:9001` — the `gitea-data` bucket appears after the first storage operation. +`http://localhost:3000` を開いて管理者アカウントを作成し、続けて `http://localhost:9001` の RustFS Console（管理画面）を開きます。`gitea-data` バケットは、最初のストレージ操作のあとに現れます。 -## 3. Push a Git LFS object +## 3. Git LFS オブジェクトを push する -Create a repository named `rustfs-demo` in the Gitea web UI, then push an LFS-tracked file from your workstation: +Gitea の Web UI で `rustfs-demo` というリポジトリを作成し、ワークステーションから LFS で追跡するファイルを push します。 ```bash mkdir lfs-demo && cd lfs-demo @@ -169,68 +169,68 @@ git remote add origin http://localhost:3000//rustfs-demo.git git push origin main ``` -`git push` uploads the LFS object through the Gitea LFS API, which writes it to RustFS. Clone the repository into a second directory and run `git lfs pull` — the downloaded `dataset.bin` must be byte-identical to the original: +`git push` は Gitea の LFS API 経由で LFS オブジェクトをアップロードし、API がそれを RustFS に書き込みます。リポジトリを別のディレクトリに clone し、`git lfs pull` を実行します。ダウンロードした `dataset.bin` は、元のファイルとバイト単位で同一である必要があります。 ```bash sha256sum dataset.bin cd ../lfs-demo-clone && git lfs pull && sha256sum dataset.bin ``` -Both checksums match because both clients read the object from RustFS. +どちらのクライアントも RustFS からオブジェクトを読み込むため、両方のチェックサムが一致します。 -## 4. Attach a file to an issue +## 4. Issue にファイルを添付する -Open the `rustfs-demo` repository, create an issue, and attach a small text file through the issue form. Gitea stores the upload as `attachments//` in the `gitea-data` bucket and serves downloads through `/attachments/`. +`rustfs-demo` リポジトリを開き、Issue を作成し、Issue フォームから小さなテキストファイルを添付します。Gitea はアップロードを `gitea-data` バケット内の `attachments//` として保存し、`/attachments/` 経由でダウンロードを提供します。 -## 5. Verify objects in RustFS +## 5. RustFS 内のオブジェクトを確認する -List the bucket with the [`rc` client](https://github.com/rustfs/cli): +[`rc` クライアント](https://github.com/rustfs/cli)でバケットを一覧します。 ```bash docker compose exec rustfs /usr/bin/rc ls local/gitea-data/ -r ``` -The output should include the LFS object under `lfs/` and the attachment under `attachments/`: +出力には `lfs/` 配下の LFS オブジェクトと、`attachments/` 配下の添付ファイルが含まれるはずです。 ```text attachments/9/2/92fdd48d-531c-4cba-8b3f-4e2004a10fc7 lfs/37/76/6ddfc07e803de58a69328db9a58a07cf7080ddde55c155a7531bc650a000 ``` -The LFS object key is the SHA-256 content hash used by the Git LFS protocol. +LFS オブジェクトキーは、Git LFS プロトコルで使われる SHA-256 コンテンツハッシュです。 -![Gitea LFS and attachment objects in the RustFS Console](./images/rustfs-gitea-objects.png) +![RustFS Console 内の Gitea の LFS オブジェクトと添付ファイル](./images/rustfs-gitea-objects.png) -## 6. Stop or reset the deployment +## 6. デプロイを停止またはリセットする -Stop the containers while keeping all data: +データを残したままコンテナを停止します。 ```bash docker compose down ``` -The RustFS volume keeps the `gitea-data` bucket, so LFS objects and attachments survive a restart. To delete everything, including the objects in RustFS, add `--volumes`. +RustFS のボリュームは `gitea-data` バケットを保持するため、LFS オブジェクトと添付ファイルは再起動後も残ります。RustFS 内のオブジェクトを含めてすべて削除するには、`--volumes` を追加します。 -## Troubleshooting +## トラブルシューティング -### The Gitea install page appears instead of the login page +### ログインページではなく Gitea のインストールページが表示される -The configuration file must exist at `/data/gitea/conf/app.ini` inside the container. If the mount path is wrong, Gitea starts with defaults and shows the installation wizard. Mount the file as shown in the Compose example and restart. +設定ファイルはコンテナ内の `/data/gitea/conf/app.ini` に存在する必要があります。マウントパスが誤っていると、Gitea はデフォルト設定で起動し、インストールウィザードを表示します。Compose の例のとおりにファイルをマウントして再起動します。 -### Push fails with an LFS or 403 error +### push が LFS エラーまたは 403 で失敗する -Confirm the credentials in `app.ini` match the RustFS credentials and that the `rustfs` hostname resolves inside the Compose network: +`app.ini` の認証情報が RustFS の認証情報と一致していること、および `rustfs` ホスト名が Compose ネットワーク内で解決できることを確認します。 ```bash docker compose logs gitea | grep -i minio ``` -### Objects land in local storage instead of RustFS +### オブジェクトが RustFS ではなくローカルストレージに入る -The `GITEA__storage__STORAGE_TYPE: minio` environment variable and the `[storage]` section of `app.ini` must agree. After changing either, restart Gitea and check the `Initialising` log lines again. +環境変数 `GITEA__storage__STORAGE_TYPE: minio` と `app.ini` の `[storage]` セクションは一致している必要があります。どちらかを変更したら Gitea を再起動し、`Initialising` のログ行を再度確認します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Gitea storage targets. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Gitea storage documentation](https://docs.gitea.com/administration/storage-configurations) to move packages, Actions artifacts, or individual storage sections to separate buckets. +- 追加の Gitea ストレージターゲットを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [Gitea のストレージドキュメント](https://docs.gitea.com/administration/storage-configurations)に従い、パッケージ、Actions のアーティファクト、または個別のストレージセクションを別々のバケットへ移してください。 diff --git a/content/ja/developer/integration/devops/jenkins.md b/content/ja/developer/integration/devops/jenkins.md index 1d78f31b0..2812edfcf 100644 --- a/content/ja/developer/integration/devops/jenkins.md +++ b/content/ja/developer/integration/devops/jenkins.md @@ -1,13 +1,13 @@ --- title: "Jenkins" -description: "Store Jenkins build artifacts in RustFS with the Artifact Manager on S3 plugin." +description: "Artifact Manager on S3 プラグインを使い、Jenkins のビルドアーティファクトを RustFS に保存します。" --- -This guide connects [Jenkins](https://github.com/jenkinsci/jenkins) — the automation server — to **RustFS** through the Artifact Manager on S3 plugin. You will start Jenkins with the plugin, point its artifact manager at a RustFS bucket, run a job that archives an artifact, and verify that the artifact is stored in RustFS. The workflow was verified with `jenkins/jenkins:lts-jdk17` (Jenkins 2.5xx LTS) and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、自動化サーバーである [Jenkins](https://github.com/jenkinsci/jenkins) を、Artifact Manager on S3 プラグイン経由で **RustFS** に接続します。プラグインを入れた Jenkins を起動し、アーティファクトマネージャーを RustFS のバケットに向け、アーティファクトをアーカイブするジョブを実行して、アーティファクトが RustFS に保存されることを確認します。この流れは `jenkins/jenkins:lts-jdk17`（Jenkins 2.5xx LTS）と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,18 +15,18 @@ flowchart LR J -->|"archiveArtifacts"| RustFS["RustFS :9000"] ``` -With the plugin active, every job that publishes artifacts through the standard `archiveArtifacts` step (or `stash`/`unstash`) uploads them to the `jenkins-artifacts` bucket under the configured prefix instead of storing them on the controller disk. +プラグインが有効な場合、標準の `archiveArtifacts` ステップ（または `stash` / `unstash`）でアーティファクトを公開するすべてのジョブは、コントローラーのディスクではなく、設定したプレフィックス配下の `jenkins-artifacts` バケットへアップロードします。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create the bucket first — the plugin validates the bucket but does not create it: +先にバケットを作成します。プラグインはバケットを検証しますが、作成はしません。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/jenkins-artifacts ``` -Create a Dockerfile that installs the plugin into the Jenkins LTS image: +Jenkins LTS イメージにプラグインをインストールする Dockerfile を作成します。 ```dockerfile title="Dockerfile" FROM jenkins/jenkins:lts-jdk17 @@ -35,9 +35,9 @@ RUN jenkins-plugin-cli --plugins artifact-manager-s3 aws-credentials USER jenkins ``` -The `artifact-manager-s3` plugin brings in the AWS credentials support it needs; listing `aws-credentials` explicitly keeps the credential type available. +`artifact-manager-s3` プラグインは必要な AWS 認証情報サポートを取り込みます。`aws-credentials` を明示すると、その認証情報タイプを利用できます。 -Build and start Jenkins on the same Docker network as RustFS: +RustFS と同じ Docker ネットワーク上で Jenkins をビルドして起動します。 ```bash docker build -t jenkins-rustfs . @@ -45,31 +45,31 @@ docker run -d --name jenkins --network oo-rustfs_default \ -p 8080:8080 -v jenkins-home:/var/jenkins_home jenkins-rustfs ``` -Complete the setup wizard, then create an AWS credential: **Manage Jenkins → Credentials → global → Add Credentials**, kind **AWS Credential**, ID `rustfs-creds`, with your RustFS access key and secret key. +セットアップウィザードを完了し、AWS 認証情報を作成します。**Manage Jenkins**（Jenkins の管理）→ **Credentials**（認証情報）→ **global** → **Add Credentials**（認証情報の追加）を開き、種類は **AWS Credential**、ID は `rustfs-creds` とし、RustFS のアクセスキーとシークレットキーを入力します。 -## 2. Configure the artifact manager +## 2. アーティファクトマネージャーを設定する -Open **Manage Jenkins → AWS Configuration** (from the `aws-global-configuration` plugin) and set: +`aws-global-configuration` プラグインの **Manage Jenkins → AWS Configuration**（AWS 設定）を開き、次を設定します。 -- **Region name**: `us-east-1` +- **Region name**（リージョン名）: `us-east-1` - **Credentials**: `rustfs-creds` -Open **Manage Jenkins → System** and locate the **Artifact Management for Builds** section. Select **Cloud Provider Amazon S3**, and fill in the S3 configuration: +**Manage Jenkins → System**（システム設定）を開き、**Artifact Management for Builds**（ビルドのアーティファクト管理）を探します。**Cloud Provider Amazon S3** を選び、S3 設定に次を入力します。 -- **S3 Bucket Name**: `jenkins-artifacts` -- **S3 Bucket Region**: `us-east-1` -- **Base Prefix**: `artifacts/` -- **Custom Endpoint**: `:9000` (for example `rustfs:9000` inside the Compose network) -- **Custom Signing Region**: `us-east-1` -- **Use Path Style URL**: enabled -- **Use Insecure HTTP**: enabled -- **Disable Session Token**: enabled +- **S3 Bucket Name**（S3 バケット名）: `jenkins-artifacts` +- **S3 Bucket Region**（S3 バケットのリージョン）: `us-east-1` +- **Base Prefix**（ベースプレフィックス）: `artifacts/` +- **Custom Endpoint**（カスタムエンドポイント）: `:9000`（Compose ネットワーク内の例は `rustfs:9000`） +- **Custom Signing Region**（カスタム署名リージョン）: `us-east-1` +- **Use Path Style URL**（パススタイル URL を使用）: 有効 +- **Use Insecure HTTP**（非セキュア HTTP を使用）: 有効 +- **Disable Session Token**（セッショントークンを無効化）: 有効 -Path-style addressing and plain HTTP are required for a non-AWS endpoint without TLS. Disabling the session token stops the plugin from calling AWS STS, which a plain access key pair cannot answer. Click **Validate S3 Bucket configuration** to confirm the settings, then save. +TLS のない非 AWS エンドポイントでは、パススタイルアクセスと平文 HTTP が必要です。セッショントークンを無効にすると、プラグインは AWS STS を呼ばなくなります。単なるアクセスキーの組では STS に応答できません。**Validate S3 Bucket configuration**（S3 バケット設定の検証）をクリックして設定を確認し、保存します。 -## 3. Run a job that archives an artifact +## 3. アーティファクトをアーカイブするジョブを実行する -Create a freestyle job (or pipeline) that produces a file and archives it: +ファイルを生成してアーカイブするフリースタイルジョブ（またはパイプライン）を作成します。 ```groovy pipeline { @@ -89,56 +89,56 @@ pipeline { } ``` -Run the build and wait for it to finish. The artifact upload goes to RustFS transparently — the job configuration does not mention S3 at all. +ビルドを実行し、完了を待ちます。アーティファクトのアップロードは透過的に RustFS へ送られます。ジョブ設定に S3 は一切出てきません。 -## 4. Verify objects in RustFS +## 4. RustFS 内のオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/jenkins-artifacts/ -r ``` -The artifact is stored under the prefix, organized by job and build number: +アーティファクトはプレフィックス配下に、ジョブとビルド番号で整理されて保存されます。 ```text artifacts/s3-artifacts-demo/3/artifacts/report.txt ``` -![Jenkins artifacts stored in the RustFS Console](./images/rustfs-jenkins-artifacts.png) +![RustFS Console に保存された Jenkins のアーティファクト](./images/rustfs-jenkins-artifacts.png) -Downloading the artifact from the build page reads it back from RustFS. +ビルドページからアーティファクトをダウンロードすると、RustFS から読み戻されます。 -## 5. Stop or reset the deployment +## 5. デプロイを停止またはリセットする -Stop Jenkins while keeping the data: +データを残したまま Jenkins を停止します。 ```bash docker rm -f jenkins ``` -The artifacts stay in the `jenkins-artifacts` bucket. To delete them, remove the bucket: +アーティファクトは `jenkins-artifacts` バケットに残ります。削除するにはバケットを削除します。 ```bash rc rb rustfs/jenkins-artifacts --force ``` -## Troubleshooting +## トラブルシューティング ### `StsException: The security token included in the request is invalid` -The plugin is calling AWS STS to obtain session credentials. Enable **Disable Session Token** in the S3 configuration — a static access key pair cannot answer an STS call. +プラグインはセッション認証情報を得るために AWS STS を呼んでいます。S3 設定で **Disable Session Token** を有効にします。静的なアクセスキーの組では STS 呼び出しに応答できません。 ### `UnknownHostException: jenkins-artifacts.rustfs` -The plugin is using virtual-hosted addressing. Enable **Use Path Style URL** — RustFS resolves buckets from the URL path, not the hostname. +プラグインは仮想ホスト形式を使っています。**Use Path Style URL** を有効にします。RustFS はホスト名ではなく URL パスからバケットを解決します。 -### `No valid session credentials` or empty credential errors +### `No valid session credentials` または空の認証情報エラー -Confirm the AWS Configuration page has the credential selected and saved **before** the S3 bucket settings are used, and that the credential ID matches the one you created. +S3 バケット設定を使う**前に**、AWS Configuration ページで認証情報を選択して保存していること、および認証情報 ID が作成したものと一致することを確認します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Jenkins integrations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Artifact Manager on S3 plugin documentation](https://plugins.jenkins.io/artifact-manager-s3/) for stash support and cleanup options. +- 追加の Jenkins 連携を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [Artifact Manager on S3 プラグインのドキュメント](https://plugins.jenkins.io/artifact-manager-s3/)に従い、stash のサポートとクリーンアップのオプションを確認してください。 diff --git a/content/ja/developer/integration/devops/opensearch.md b/content/ja/developer/integration/devops/opensearch.md index 9d44e530b..8b5091dd5 100644 --- a/content/ja/developer/integration/devops/opensearch.md +++ b/content/ja/developer/integration/devops/opensearch.md @@ -1,13 +1,13 @@ --- title: "OpenSearch" -description: "Snapshot OpenSearch indices to RustFS with the repository-s3 plugin." +description: "repository-s3 プラグインで、OpenSearch インデックスのスナップショットを RustFS に保存します。" --- -This guide connects [OpenSearch](https://github.com/opensearch-project/OpenSearch) — the open-source search and analytics suite derived from Elasticsearch — to **RustFS** through the `repository-s3` plugin. You will register an S3 snapshot repository backed by a RustFS bucket, take a snapshot of an index, and restore it. The workflow was verified with `opensearchproject/opensearch:3.8.0` and the bundled `repository-s3` plugin against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Elasticsearch から派生したオープンソースの検索・分析スイートである [OpenSearch](https://github.com/opensearch-project/OpenSearch) を、`repository-s3` プラグイン経由で **RustFS** に接続します。RustFS のバケットをバックエンドとする S3 スナップショットリポジトリを登録し、インデックスのスナップショットを取得して復元します。この流れは `opensearchproject/opensearch:3.8.0` と同梱の `repository-s3` プラグインを、`rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Docker, or an OpenSearch node where you can install plugins and edit configuration. This deployment is intended for local integration testing, not production. +Docker、またはプラグインをインストールして設定を編集できる OpenSearch ノードが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,11 +16,11 @@ flowchart LR RustFS -->|"restore"| OS ``` -The `repository-s3` plugin writes snapshots as shard archives plus metadata blobs in the bucket. Registration is cluster-wide, so every node needs the plugin and the same client configuration. +`repository-s3` プラグインは、スナップショットをシャードアーカイブとメタデータのブロブとしてバケットに書き込みます。登録はクラスター全体に適用されるため、すべてのノードにプラグインと同じクライアント設定が必要です。 -## 1. Run OpenSearch +## 1. OpenSearch を実行する -Start a single node with security disabled and a small heap: +セキュリティを無効にし、ヒープを小さくしたシングルノードを起動します。 ```bash docker run -d --name opensearch --network oo-rustfs_default -p 9200:9200 \ @@ -30,20 +30,20 @@ docker run -d --name opensearch --network oo-rustfs_default -p 9200:9200 \ opensearchproject/opensearch:3.8.0 ``` -The node is ready when `curl http://localhost:9200` returns the cluster header (allow one to two minutes). +`curl http://localhost:9200` がクラスター情報を返せば、ノードは準備完了です。1〜2 分かかることがあります。 -## 2. Install the repository-s3 plugin +## 2. repository-s3 プラグインをインストールする -The S3 repository plugin is not preloaded. Install it and restart the node: +S3 リポジトリプラグインは事前に読み込まれていません。インストールしてノードを再起動します。 ```bash docker exec opensearch bin/opensearch-plugin install --batch repository-s3 docker restart opensearch ``` -## 3. Configure the S3 client +## 3. S3 クライアントを設定する -Credentials are secure settings: they belong in the OpenSearch keystore, not in the repository request or `opensearch.yml`. Create the keystore entries, replacing all connection placeholders: +認証情報はセキュア設定です。リポジトリのリクエストや `opensearch.yml` ではなく、OpenSearch のキーストアに入れます。接続情報のプレースホルダーをすべて置き換えて、キーストアのエントリを作成します。 ```bash docker exec opensearch sh -c \ @@ -52,7 +52,7 @@ docker exec opensearch sh -c \ printf '' | bin/opensearch-keystore add -f -x s3.client.default.secret_key" ``` -Add the non-secure client settings to `config/opensearch.yml`: +非セキュアなクライアント設定を `config/opensearch.yml` に追加します。 ```yaml title="opensearch.yml" network.host: 0.0.0.0 @@ -62,21 +62,21 @@ s3.client.default.protocol: http s3.client.default.path_style_access: "true" ``` -Restart the node once more so it reads both the keystore and the new settings: +キーストアと新しい設定の両方を読み込むよう、ノードをもう一度再起動します。 ```bash docker restart opensearch ``` -Create the bucket while the node boots: +ノードの起動中にバケットを作成します。 ```bash rc mb rustfs/opensearch-snapshots ``` -## 4. Register the repository and snapshot +## 4. リポジトリを登録してスナップショットを取得する -Create a test index with a document, then register the repository: +ドキュメント入りのテストインデックスを作成してから、リポジトリを登録します。 ```bash curl -sX PUT http://localhost:9200/rustfs-demo -H "Content-Type: application/json" \ @@ -89,9 +89,9 @@ curl -sX PUT "http://localhost:9200/_snapshot/rustfs-repo" -H "Content-Type: app -d '{"type":"s3","settings":{"bucket":"opensearch-snapshots","region":"us-east-1","server_side_encryption_type":"bucket_default"}}' ``` -The `server_side_encryption_type: bucket_default` setting matters: without it the plugin requests SSE-S3, which a self-hosted RustFS without a server-side encryption master key rejects. +`server_side_encryption_type: bucket_default` の設定が重要です。これがないとプラグインは SSE-S3 を要求し、サーバー側の暗号化のマスターキーがないセルフホストの RustFS は拒否します。 -Take a snapshot and wait for completion: +スナップショットを取得し、完了を待ちます。 ```bash curl -sX PUT "http://localhost:9200/_snapshot/rustfs-repo/snapshot-1?wait_for_completion=true" \ @@ -102,9 +102,9 @@ curl -sX PUT "http://localhost:9200/_snapshot/rustfs-repo/snapshot-1?wait_for_co {"snapshot":{"snapshot":"snapshot-1","state":"SUCCESS","indices":["rustfs-demo"],...}} ``` -## 5. Verify objects and restore +## 5. オブジェクトを確認して復元する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/opensearch-snapshots/ -r @@ -119,7 +119,7 @@ meta-kRgFBiuyQIyPo3_-CMp7Hw.dat snap-kRgFBiuyQIyPo3_-CMp7Hw.dat ``` -Delete the index and restore it from the snapshot: +インデックスを削除し、スナップショットから復元します。 ```bash curl -sX DELETE http://localhost:9200/rustfs-demo @@ -131,42 +131,42 @@ curl -s http://localhost:9200/rustfs-demo/_doc/1 {"_index":"rustfs-demo","_id":"1","found":true,"_source":{"product":"rustfs","via":"opensearch-snapshot"}} ``` -![OpenSearch snapshot stored in the RustFS Console](./images/rustfs-opensearch-snapshot.png) +![RustFS Console に保存された OpenSearch のスナップショット](./images/rustfs-opensearch-snapshot.png) -## 6. Stop or reset +## 6. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを破棄します。 ```bash docker rm -f opensearch ``` -To delete the stored snapshots: +保存したスナップショットを削除します。 ```bash rc rm rustfs/opensearch-snapshots/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `Setting [access_key] is insecure, but property [allow_insecure_settings] is not set` -Inline credentials in the repository request are rejected. Store them in the keystore as shown in step 3 — `access_key` and `secret_key` are secure settings in OpenSearch. +リポジトリリクエスト内のインライン認証情報は拒否されます。手順 3 のとおりキーストアに保存します。OpenSearch では `access_key` と `secret_key` はセキュア設定です。 ### `SSE-S3 requires RUSTFS_SSE_S3_MASTER_KEY ... (Status Code: 400)` -The plugin encrypts uploads with SSE-S3 by default. Register the repository with `"server_side_encryption_type": "bucket_default"` so no encryption header is sent, as in step 4. +プラグインはデフォルトで SSE-S3 によりアップロードを暗号化します。手順 4 のとおり `"server_side_encryption_type": "bucket_default"` でリポジトリを登録し、暗号化ヘッダーを送らないようにします。 -### `unknown setting [s3.client.default.access_key]` at startup +### 起動時に `unknown setting [s3.client.default.access_key]` が出る -The settings reference the repository-s3 plugin. If the node fails to start with them present, the plugin is not installed in that container — repeat step 2 (a fresh container loses plugins installed with `docker exec`). +この設定は repository-s3 プラグインを参照します。設定がある状態でノードが起動に失敗する場合、そのコンテナにプラグインが入っていません。手順 2 をやり直します。新しいコンテナでは、`docker exec` でインストールしたプラグインは失われます。 -### Repository verification fails with `path is not accessible` +### リポジトリ検証が `path is not accessible` で失敗する -The node cannot reach the bucket: check that `s3.client.default.endpoint` is reachable from the container, `path_style_access` is `"true"`, and the keystore credentials were loaded (they are read at startup — restart after adding them). +ノードがバケットに到達できません。`s3.client.default.endpoint` がコンテナから到達できること、`path_style_access` が `"true"` であること、キーストアの認証情報が読み込まれていることを確認します。認証情報は起動時に読まれるため、追加したあとは再起動します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional OpenSearch repositories. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [OpenSearch snapshots documentation](https://docs.opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/snapshots/index/) to automate snapshots with Snapshot Management (SM) policies. +- 追加の OpenSearch リポジトリを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [OpenSearch のスナップショットドキュメント](https://docs.opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/snapshots/index/)に従い、Snapshot Management（SM）ポリシーでスナップショットを自動化してください。 diff --git a/content/ja/developer/integration/devops/terraform.md b/content/ja/developer/integration/devops/terraform.md index 8744833a2..f4a227234 100644 --- a/content/ja/developer/integration/devops/terraform.md +++ b/content/ja/developer/integration/devops/terraform.md @@ -1,31 +1,31 @@ --- title: "Terraform" -description: "Store Terraform state in RustFS object storage with the S3 backend, including state locking." +description: "ステートロックを含め、S3 バックエンドで Terraform のステートを RustFS のオブジェクトストレージに保存します。" --- -This guide connects [Terraform](https://github.com/hashicorp/terraform) — the infrastructure as code tool from HashiCorp — to **RustFS** through the S3 backend: the state file, and the lock file that prevents concurrent runs, are stored as objects in RustFS. You will initialize the backend, apply a small configuration, and verify the state object in RustFS. The workflow was verified with `terraform 1.12.2` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、HashiCorp の Infrastructure as Code ツールである [Terraform](https://github.com/hashicorp/terraform) を、S3 バックエンド経由で **RustFS** に接続します。ステートファイルと、同時実行を防ぐロックファイルは、オブジェクトとして RustFS に保存されます。バックエンドを初期化し、小さな設定を apply し、RustFS 内のステートオブジェクトを確認します。この流れは `terraform 1.12.2` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need a RustFS deployment reachable from your workstation (see the guides under [Installation](/installation)) and Terraform 1.10 or later, which supports S3-native locking via `use_lockfile`. +ワークステーションから到達できる RustFS のデプロイ（[インストール](/ja/installation) 配下のガイドを参照）と、`use_lockfile` による S3 ネイティブのロックに対応した Terraform 1.10 以降が必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR Client["terraform init / apply"] -->|"state + lock objects"| RustFS["RustFS :9000"] ``` -The S3 backend stores the state file under the `key` prefix in the bucket. With `use_lockfile = true`, Terraform writes a `.tflock` object while a run holds the lock, replacing the former DynamoDB-based locking for this setup. +S3 バックエンドは、バケット内の `key` プレフィックス配下にステートファイルを保存します。`use_lockfile = true` にすると、実行がロックを保持しているあいだ Terraform は `.tflock` オブジェクトを書き込みます。この構成では、以前の DynamoDB ベースのロックに代わる仕組みです。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create a working directory: +作業ディレクトリを作成します。 ```bash mkdir rustfs-terraform cd rustfs-terraform ``` -Create the configuration. Replace the credential placeholders and point the endpoint at your RustFS server — `localhost:9000` when Terraform runs on the same host: +設定を作成します。認証情報のプレースホルダーを置き換え、エンドポイントを RustFS サーバーに向けます。Terraform を同じホストで実行する場合は `localhost:9000` です。 ```hcl title="main.tf" terraform { @@ -54,11 +54,11 @@ resource "local_file" "demo" { } ``` -`force_path_style` and `insecure` select path-style addressing over plain HTTP, which is what RustFS expects for the local endpoint. `use_lockfile` enables S3-native state locking so concurrent runs cannot corrupt the state. +`force_path_style` と `insecure` は、ローカルエンドポイントで RustFS が期待する、平文 HTTP 上のパススタイルアクセスを選びます。`use_lockfile` は S3 ネイティブのステートロックを有効にし、同時実行でステートが壊れないようにします。 -## 2. Initialize the backend +## 2. バックエンドを初期化する -Download the provider and configure the S3 backend: +プロバイダーをダウンロードし、S3 バックエンドを設定します。 ```bash terraform init -input=false @@ -69,9 +69,9 @@ Successfully configured the backend "s3"! Terraform will automatically use this backend unless the backend configuration changes. ``` -## 3. Apply the configuration +## 3. 設定を apply する -Create the resource and write the state to RustFS: +リソースを作成し、ステートを RustFS に書き込みます。 ```bash terraform apply -auto-approve -input=false @@ -81,9 +81,9 @@ terraform apply -auto-approve -input=false Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -## 4. Verify the state in RustFS +## 4. RustFS 内のステートを確認する -List the state objects through the `rc` CLI: +`rc` CLI でステートオブジェクトを一覧します。 ```bash docker run --rm --network -v "$PWD:/m" \ @@ -95,13 +95,13 @@ docker run --rm --network -v "$PWD:/m" \ [2026-09-21 03:05:03] 1.62 KiB rustfs-demo/terraform.tfstate ``` -You can also browse the prefix in the RustFS Console: +RustFS Console（管理画面）でこのプレフィックスを参照することもできます。 -![The Terraform state file stored in the RustFS Console](./images/rustfs-terraform-state.png) +![RustFS Console に保存された Terraform のステートファイル](./images/rustfs-terraform-state.png) -## 5. Confirm the state is reloaded from RustFS +## 5. ステートが RustFS から再読み込みされることを確認する -Run a plan — Terraform reads the state from RustFS and compares it against the configuration: +plan を実行します。Terraform は RustFS からステートを読み込み、設定と比較します。 ```bash terraform plan -input=false @@ -111,34 +111,34 @@ terraform plan -input=false No changes. Your infrastructure matches the configuration. ``` -The plan is clean because the state was read back from RustFS, not from any local file. +ローカルファイルではなく RustFS からステートが読み戻されているため、plan に差分はありません。 -## 6. Destroy and reset +## 6. 破棄してリセットする -Tear the resource down; the state update is written to RustFS the same way: +リソースを破棄します。ステートの更新も同じように RustFS へ書き込まれます。 ```bash terraform destroy -auto-approve -input=false ``` -Delete the state objects in the RustFS Console (or with `rc rm`) to start from scratch. +最初からやり直すには、RustFS Console でステートオブジェクトを削除します（`rc rm` でも削除できます）。 -## Troubleshooting +## トラブルシューティング -### "dial tcp: lookup rustfs ... server misbehaving" or connection failures +### "dial tcp: lookup rustfs ... server misbehaving" または接続失敗 -The `endpoint` must be reachable from the machine where Terraform runs. Inside a Compose network use `http://rustfs:9000`; from the host use `http://localhost:9000`. +`endpoint` は Terraform を実行するマシンから到達できる必要があります。Compose ネットワーク内では `http://rustfs:9000` を、ホストからは `http://localhost:9000` を使用します。 -### "Bucket cannot have ACLs set" or signature errors +### "Bucket cannot have ACLs set" または署名エラー -`skip_credentials_validation`, `skip_region_validation`, `skip_metadata_api_check`, `skip_requesting_account_id`, `force_path_style`, and `insecure` are all required for a non-AWS endpoint; missing any of them makes the backend talk to AWS defaults instead of RustFS. +非 AWS エンドポイントでは `skip_credentials_validation`、`skip_region_validation`、`skip_metadata_api_check`、`skip_requesting_account_id`、`force_path_style`、`insecure` がすべて必要です。いずれかが欠けると、バックエンドは RustFS ではなく AWS のデフォルトへ通信します。 -### The state does not appear in the bucket +### ステートがバケットに現れない -Confirm that the bucket exists and that the credentials match the RustFS credentials. The state object appears under the `key` path (`rustfs-demo/terraform.tfstate` in this guide) after the first `init` or `apply`. +バケットが存在すること、および認証情報が RustFS の認証情報と一致することを確認します。ステートオブジェクトは、最初の `init` または `apply` のあと、`key` のパス（このガイドでは `rustfs-demo/terraform.tfstate`）に現れます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional S3 operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Terraform S3 backend documentation](https://developer.hashicorp.com/terraform/language/backend/s3) for options such as workspace prefixes and role assumption. +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [Terraform の S3 バックエンドドキュメント](https://developer.hashicorp.com/terraform/language/backend/s3)に従い、ワークスペースのプレフィックスやロールの引き受けなどのオプションを確認してください。 diff --git a/content/ja/developer/integration/observability/fluentd.md b/content/ja/developer/integration/observability/fluentd.md index 4607c0ec3..c8f9fcd54 100644 --- a/content/ja/developer/integration/observability/fluentd.md +++ b/content/ja/developer/integration/observability/fluentd.md @@ -1,13 +1,13 @@ --- title: "Fluentd" -description: "Ship Fluentd log events to RustFS with the S3 output plugin." +description: "S3 出力プラグインで Fluentd のログイベントを RustFS へ送信します。" --- -This guide connects [Fluentd](https://github.com/fluent/fluentd) — the open-source data collector — to **RustFS** through the `out_s3` output plugin. You will run Fluentd with a tail source, buffer log events, and verify that the flushed objects are stored in RustFS. The workflow was verified with `fluent/fluentd:v1.17-1`, `fluent-plugin-s3` 1.8.6, and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、オープンソースのデータコレクターである [Fluentd](https://github.com/fluent/fluentd) を、`out_s3` 出力プラグイン経由で **RustFS** に接続します。tail ソースで Fluentd を実行し、ログイベントをバッファし、フラッシュされたオブジェクトが RustFS に保存されることを確認します。この流れは `fluent/fluentd:v1.17-1`、`fluent-plugin-s3` 1.8.6、`rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,18 +16,18 @@ flowchart LR Fluentd -->|"gzip objects"| RustFS["RustFS :9000"] ``` -The tail source reads new lines from `app.log` and hands them to the S3 output, which buffers events on a time key and uploads a gzip object per flush window. +tail ソースは `app.log` の新しい行を読み、S3 出力へ渡します。S3 出力はタイムキーでイベントをバッファし、フラッシュ区間ごとに gzip オブジェクトを 1 つアップロードします。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create the bucket first — Fluentd does not create buckets: +先にバケットを作成します。Fluentd はバケットを作成しません。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/fluentd-data ``` -The official Fluentd image runs as a non-root user and cannot install gems at startup, so build a small image with the S3 plugin: +公式の Fluentd イメージは非 root ユーザーで動作し、起動時に gem をインストールできません。S3 プラグインを入れた小さなイメージをビルドします。 ```dockerfile title="Dockerfile" FROM fluent/fluentd:v1.17-1 @@ -36,7 +36,7 @@ RUN gem install fluent-plugin-s3 --no-document USER fluent ``` -Create the Fluentd configuration, replacing both credential placeholders: +2 つの認証情報プレースホルダーを置き換えて、Fluentd の設定を作成します。 ```nginx title="fluent.conf" @@ -67,9 +67,9 @@ Create the Fluentd configuration, replacing both credential placeholders: ``` -`force_path_style true` is required — without it the plugin constructs `fluentd-data.rustfs` as a hostname and every request fails with a DNS error. Inside the Compose network the hostname is `rustfs`; from the host use `http://localhost:9000/`. +`force_path_style true` が必要です。これがないとプラグインは `fluentd-data.rustfs` をホスト名として組み立て、すべてのリクエストが DNS エラーで失敗します。Compose ネットワーク内のホスト名は `rustfs` です。ホストからは `http://localhost:9000/` を使用します。 -Build the image and start Fluentd on the same Docker network as RustFS: +イメージをビルドし、RustFS と同じ Docker ネットワーク上で Fluentd を起動します。 ```bash docker build -t fluentd-rustfs . @@ -79,74 +79,74 @@ docker run -d --name fluentd --network oo-rustfs_default \ -v "$PWD/logs":/var/log fluentd-rustfs ``` -## 2. Produce log events +## 2. ログイベントを生成する -Append lines to the watched file: +監視対象のファイルに行を追記します。 ```bash echo "rustfs fluentd demo line 1" >> logs/app.log echo "rustfs fluentd demo line 2" >> logs/app.log ``` -With a 30-second time key and immediate flush mode, each window uploads one gzip object shortly after it closes. Wait about a minute. +30 秒のタイムキーと即時フラッシュモードでは、各区間が閉じた直後に gzip オブジェクトが 1 つアップロードされます。1 分ほど待ちます。 -## 3. Verify objects in RustFS +## 3. RustFS 内のオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/fluentd-data/ -r ``` -Each flush window produces one gzipped object: +フラッシュ区間ごとに gzip 圧縮されたオブジェクトが 1 つできます。 ```text fluentd-logs20260921154400_0.gz fluentd-logs20260921154400_1.gz ``` -Read one object back to confirm the events are intact: +オブジェクトを 1 つ読み戻し、イベントが欠落していないことを確認します。 ```bash rc cat rustfs/fluentd-data/fluentd-logs20260921154400_0.gz | gunzip ``` -![Fluentd log objects stored in the RustFS Console](./images/rustfs-fluentd-logs.png) +![RustFS Console に保存された Fluentd のログオブジェクト](./images/rustfs-fluentd-logs.png) -## 4. Stop or reset the deployment +## 4. デプロイを停止またはリセットする -Stop Fluentd while keeping the data: +データを残したまま Fluentd を停止します。 ```bash docker rm -f fluentd ``` -The objects stay in the `fluentd-data` bucket. To delete them, remove the bucket: +オブジェクトは `fluentd-data` バケットに残ります。削除するにはバケットを削除します。 ```bash rc rb rustfs/fluentd-data --force ``` -## Troubleshooting +## トラブルシューティング ### `Unknown output plugin 's3'` -The plugin is not installed. Confirm the Dockerfile installs `fluent-plugin-s3` as `root` before switching back to the `fluent` user — installing at container start as the default user fails with permission errors. +プラグインがインストールされていません。Dockerfile が `fluent` ユーザーに戻す前に、`root` として `fluent-plugin-s3` をインストールしていることを確認します。デフォルトユーザーのままコンテナ起動時にインストールすると、権限エラーで失敗します。 ### `Failed to open TCP connection to fluentd-data.rustfs` -Virtual-hosted addressing is in use. Add `force_path_style true` to the `s3` output so the bucket stays in the URL path. +仮想ホスト形式が使われています。`s3` 出力に `force_path_style true` を追加し、バケットを URL パスに残します。 -### The worker crashes in a restart loop +### ワーカーが再起動ループでクラッシュする -The output fails hard when the bucket does not exist. Create `fluentd-data` before starting Fluentd and check the startup log: +バケットが存在しないと出力は致命的に失敗します。Fluentd を起動する前に `fluentd-data` を作成し、起動ログを確認します。 ```bash docker logs fluentd | grep -iE "error|bucket" | tail ``` -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Fluentd outputs. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [fluent-plugin-s3 documentation](https://github.com/fluent/fluent-plugin-s3) for object key formats and compression options. +- 追加の Fluentd 出力を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [fluent-plugin-s3 のドキュメント](https://github.com/fluent/fluent-plugin-s3)に従い、オブジェクトキーの形式と圧縮オプションを確認してください。 diff --git a/content/ja/developer/integration/observability/greptimedb.md b/content/ja/developer/integration/observability/greptimedb.md index 5b7ee6905..028e78581 100644 --- a/content/ja/developer/integration/observability/greptimedb.md +++ b/content/ja/developer/integration/observability/greptimedb.md @@ -1,13 +1,13 @@ --- title: "GreptimeDB" -description: "Run GreptimeDB with RustFS as the S3-compatible object storage backend." +description: "S3 互換のオブジェクトストレージバックエンドとして RustFS を使って GreptimeDB を実行します。" --- -This guide connects [GreptimeDB](https://github.com/GreptimeTeam/greptimedb) — the open-source, cloud-native time-series database — to **RustFS** as its object storage backend. You will start a standalone instance with its `[storage]` section pointed at a RustFS bucket, write time-series rows through the SQL API, and confirm the Parquet files and manifests in the bucket. The workflow was verified with `greptime/greptimedb` (main, commit `179ff8e5`) against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、オープンソースのクラウドネイティブな時系列データベースである [GreptimeDB](https://github.com/GreptimeTeam/greptimedb) を、オブジェクトストレージバックエンドとして **RustFS** に接続します。`[storage]` セクションを RustFS のバケットに向けたスタンドアロンインスタンスを起動し、SQL API で時系列の行を書き込み、バケット内の Parquet ファイルとマニフェストを確認します。この流れは `greptime/greptimedb`（main、コミット `179ff8e5`）を `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Docker, or a local GreptimeDB binary. This deployment is intended for local integration testing, not production. +Docker、またはローカルの GreptimeDB バイナリが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR DB -->|"SST + manifests"| RustFS["RustFS :9000"] ``` -GreptimeDB keeps its write-ahead log and recent data locally, then persists SSTables (Parquet) and table manifests to object storage. Pointing the storage backend at RustFS makes the bucket the durable home of all table data. +GreptimeDB は先行書き込みログ（WAL）と直近のデータをローカルに保持し、その後 SSTable（Parquet）とテーブルマニフェストをオブジェクトストレージへ永続化します。ストレージバックエンドを RustFS に向けると、バケットがすべてのテーブルデータの永続的な保管先になります。 -## 1. Configure the storage backend +## 1. ストレージバックエンドを設定する -Create the bucket and a config file with an S3 storage section, replacing all connection placeholders: +接続情報のプレースホルダーをすべて置き換え、S3 ストレージセクションを持つ設定ファイルを作成し、バケットも作成します。 ```toml title="greptimedb.toml" [storage] @@ -32,11 +32,11 @@ endpoint = "http://:9000" region = "us-east-1" ``` -GreptimeDB uses path-style requests for custom endpoints by default; virtual-hosted style must be opted into explicitly with `enable_virtual_host_style`, so no extra flag is needed for RustFS. +GreptimeDB はカスタムエンドポイントに対してデフォルトでパススタイルのリクエストを使います。仮想ホスト形式は `enable_virtual_host_style` で明示的に有効にする必要があり、RustFS では追加のフラグは不要です。 -## 2. Run GreptimeDB +## 2. GreptimeDB を実行する -Start a standalone instance with the config file: +設定ファイルを指定してスタンドアロンインスタンスを起動します。 ```bash docker run -d --name greptimedb --network oo-rustfs_default -p 4000:4000 -p 4002:4002 \ @@ -47,11 +47,11 @@ docker run -d --name greptimedb --network oo-rustfs_default -p 4000:4000 -p 4002 --config-file /etc/greptimedb/greptimedb.toml ``` -Port `4000` serves the HTTP SQL endpoint and `4002` the MySQL protocol. +ポート `4000` は HTTP の SQL エンドポイント、`4002` は MySQL プロトコルです。 -## 3. Write and query time series +## 3. 時系列を書き込んでクエリする -Create a table, insert rows, and read them back. The HTTP SQL endpoint takes form-encoded requests: +テーブルを作成し、行を挿入して読み戻します。HTTP の SQL エンドポイントはフォームエンコードのリクエストを受け付けます。 ```bash curl -s -X POST "http://localhost:4000/v1/sql" \ @@ -65,7 +65,7 @@ curl -s -X POST "http://localhost:4000/v1/sql" \ {"output":[{"affectedrows":3}],"execution_time_ms":2} ``` -Query the rows back: +行をクエリして読み戻します。 ```bash curl -s -X POST "http://localhost:4000/v1/sql" \ @@ -76,9 +76,9 @@ curl -s -X POST "http://localhost:4000/v1/sql" \ {"output":[{"records":{"rows":[["node-2",0.51,0.71,1790681000000],["node-1",0.35,0.63,1790681060000]],"total_rows":2}}]} ``` -## 4. Verify objects in RustFS +## 4. RustFS 内のオブジェクトを確認する -List the bucket — after the memtable flushes, the bucket holds Parquet SSTables and JSON manifests: +バケットを一覧します。memtable（メモリ上の書き込みバッファ）のフラッシュ後、バケットには Parquet の SSTable と JSON マニフェストが入ります。 ```bash rc ls rustfs// -r @@ -90,40 +90,40 @@ greptimedb/data/greptime/greptime_private/1025/1025_0000000000/b11e8b25-5763-4f0 greptimedb/data/greptime/greptime_private/1025/1025_0000000000/manifest/00000000000000000001.json ``` -Each database gets a directory under `data/`, and per-region `manifest/*.json` files describe the SSTables GreptimeDB reads back during queries. +各データベースは `data/` 配下にディレクトリを持ち、リージョン（GreptimeDB のデータ分割単位）ごとの `manifest/*.json` が、クエリ時に GreptimeDB が読み戻す SSTable を記述します。 -![GreptimeDB data stored in the RustFS Console](./images/rustfs-greptimedb-data.png) +![RustFS Console に保存された GreptimeDB のデータ](./images/rustfs-greptimedb-data.png) -## 5. Stop or reset +## 5. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを破棄します。 ```bash docker rm -f greptimedb ``` -To delete the stored data: +保存したデータを削除します。 ```bash rc rm rustfs// --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `Form requests must have Content-Type: application/x-www-form-urlencoded` -The `/v1/sql` HTTP endpoint only accepts form-encoded bodies. Pass SQL with `curl --data-urlencode "sql=..."` (or `application/x-www-form-urlencoded`), not as a JSON body. +`/v1/sql` の HTTP エンドポイントはフォームエンコードのボディだけを受け付けます。SQL は JSON ボディではなく、`curl --data-urlencode "sql=..."`（または `application/x-www-form-urlencoded`）で渡します。 -### Bucket stays empty +### バケットが空のままになる -GreptimeDB flushes memtables to object storage asynchronously. Run a few more inserts and wait a few seconds, or trigger a manual flush, then list the bucket again. +GreptimeDB は memtable をオブジェクトストレージへ非同期にフラッシュします。挿入を数回追加して数秒待つか、手動フラッシュを実行してから、バケットを再度一覧します。 -### Startup fails with an S3 error +### S3 エラーで起動に失敗する -Confirm `endpoint` includes the scheme, the bucket exists, and `access_key_id`/`secret_access_key` match a RustFS access key. The `root` value is optional but keeps the table tree under a known prefix. +`endpoint` にスキームが含まれていること、バケットが存在すること、`access_key_id` と `secret_access_key` が RustFS のアクセスキーと一致することを確認します。`root` は省略できますが、指定するとテーブルツリーが既知のプレフィックス配下にまとまります。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional GreptimeDB storage options. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [GreptimeDB configuration reference](https://docs.greptime.com/operational-guide/configure/configure-datanode/) to tune flush intervals and cache layers for production workloads. +- 追加の GreptimeDB ストレージオプションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [GreptimeDB の設定リファレンス](https://docs.greptime.com/operational-guide/configure/configure-datanode/)に従い、本番ワークロード向けにフラッシュ間隔とキャッシュ層を調整してください。 diff --git a/content/ja/developer/integration/observability/loki.md b/content/ja/developer/integration/observability/loki.md index 6b30c629b..c38fb7467 100644 --- a/content/ja/developer/integration/observability/loki.md +++ b/content/ja/developer/integration/observability/loki.md @@ -290,6 +290,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [Grafana Loki ドキュメント](https://grafana.com/docs/loki/latest/)に従って、Promtail、Alloy、OpenTelemetry Collector をログプロデューサーとして接続してください。 diff --git a/content/ja/developer/integration/observability/openobserve.md b/content/ja/developer/integration/observability/openobserve.md index 7c6665e30..5fb898984 100644 --- a/content/ja/developer/integration/observability/openobserve.md +++ b/content/ja/developer/integration/observability/openobserve.md @@ -306,6 +306,6 @@ RustFS イメージはユーザーとグループ `10001` で実行されます ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [OpenObserve ドキュメント](https://openobserve.ai/docs/)に従って、Fluent Bit や OpenTelemetry Collector などの実際のログプロデューサーを接続してください。 diff --git a/content/ja/developer/integration/observability/opentelemetry.md b/content/ja/developer/integration/observability/opentelemetry.md index 283df4135..3cf7fe34a 100644 --- a/content/ja/developer/integration/observability/opentelemetry.md +++ b/content/ja/developer/integration/observability/opentelemetry.md @@ -1,13 +1,13 @@ --- title: "OpenTelemetry" -description: "Export OpenTelemetry Collector logs to RustFS with the AWS S3 exporter." +description: "AWS S3 exporter で OpenTelemetry Collector のログを RustFS へエクスポートします。" --- -This guide connects the [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) — the CNCF telemetry pipeline — to **RustFS** through the collector's `awss3` exporter. You will run the contrib collector with a `filelog` receiver, ship the log lines of a file into the `otel-data` bucket, and verify the partitioned objects in RustFS. The workflow was verified with `otel/opentelemetry-collector-contrib:0.138.0` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、CNCF のテレメトリパイプラインである [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) を、Collector の `awss3` exporter 経由で **RustFS** に接続します。`filelog` レシーバーを持つ contrib 版 Collector を実行し、ファイルのログ行を `otel-data` バケットへ送り、RustFS 内のパーティション分割されたオブジェクトを確認します。この流れは `otel/opentelemetry-collector-contrib:0.138.0` と `rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,18 +15,18 @@ flowchart LR Collector -->|awss3| RustFS["RustFS :9000"] ``` -The `filelog` receiver tails the log file and the `awss3` exporter uploads batches to the bucket, partitioned into time-based prefixes. Metrics and traces can be routed through the same exporter with their own pipelines. +`filelog` レシーバーはログファイルを tail し、`awss3` exporter はバッチを時刻ベースのプレフィックスに分割してバケットへアップロードします。メトリクスとトレースも、それぞれのパイプラインで同じ exporter に通せます。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create the bucket first — the exporter does not create buckets: +先にバケットを作成します。exporter はバケットを作成しません。 ```bash rc alias set rustfs http://:9000 rc mb rustfs/otel-data ``` -Create the collector configuration, replacing both credential placeholders: +2 つの認証情報プレースホルダーを置き換えて、Collector の設定を作成します。 ```yaml title="config.yaml" receivers: @@ -52,9 +52,9 @@ service: exporters: [awss3] ``` -The exporter reads credentials from the standard `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_REGION` environment variables. `marshaler: body` writes each log line as plain text; omit it to store OTLP JSON instead. `s3_force_path_style` and `disable_ssl` are required for a plain-HTTP, non-AWS endpoint. +exporter は標準の環境変数 `AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、`AWS_REGION` から認証情報を読みます。`marshaler: body` は各ログ行をプレーンテキストとして書き込みます。省略すると OTLP JSON として保存されます。平文 HTTP の非 AWS エンドポイントでは `s3_force_path_style` と `disable_ssl` が必要です。 -Create the Compose file: +Compose ファイルを作成します。 ```yaml title="compose.yaml" services: @@ -75,9 +75,9 @@ networks: otel: ``` -## 2. Start the collector and produce logs +## 2. Collector を起動してログを生成する -Start the stack and append lines to the watched file: +スタックを起動し、監視対象のファイルに行を追記します。 ```bash echo "otel demo log line one" > app.log @@ -85,23 +85,23 @@ docker compose up -d echo "second line after start" >> app.log ``` -The collector tails the file from the beginning and uploads each buffer when the partition rolls over, so allow about a minute after the last line before checking. +Collector はファイルを先頭から tail し、パーティションが切り替わるときに各バッファをアップロードします。最後の行のあと、確認まで 1 分ほど見てください。 -## 3. Verify objects in RustFS +## 3. RustFS 内のオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/otel-data/ -r ``` -Log records are uploaded under time-based partitions with the configured file prefix: +ログレコードは、設定したファイルプレフィックス付きの時刻ベースのパーティション配下にアップロードされます。 ```text year=2026/month=09/day=21/hour=15/minute=53/logs/applogs_288361608.txt ``` -Read one object back to confirm the lines arrived intact: +オブジェクトを 1 つ読み戻し、行が欠落せず届いていることを確認します。 ```bash rc cat rustfs/otel-data/year=2026/month=09/day=21/hour=15/minute=53/logs/applogs_288361608.txt @@ -112,34 +112,34 @@ otel demo log line one second line after start ``` -![OpenTelemetry log objects stored in the RustFS Console](./images/rustfs-otel-logs.png) +![RustFS Console に保存された OpenTelemetry のログオブジェクト](./images/rustfs-otel-logs.png) -## 4. Stop or reset the deployment +## 4. デプロイを停止またはリセットする -Stop the collector while keeping the data: +データを残したまま Collector を停止します。 ```bash docker compose down ``` -The objects stay in the `otel-data` bucket. To delete them, remove the bucket: +オブジェクトは `otel-data` バケットに残ります。削除するにはバケットを削除します。 ```bash rc rb rustfs/otel-data --force ``` -## Troubleshooting +## トラブルシューティング -### `has invalid keys` when the collector starts +### Collector の起動時に `has invalid keys` が出る -The `awss3` exporter schema differs between collector releases. Version 0.138 nests the upload settings under `s3uploader` as shown above; the endpoint key is `endpoint` (not `s3_endpoint`). Newer releases move these keys to the top level — check the README for your exact collector version. +`awss3` exporter のスキーマは Collector のリリースによって異なります。バージョン 0.138 では、上記のとおりアップロード設定が `s3uploader` 配下に入り、エンドポイントのキーは `endpoint` です（`s3_endpoint` ではありません）。新しいリリースではこれらのキーがトップレベルに移っています。使用する Collector のバージョンの README を確認してください。 -### Nothing appears in the bucket +### バケットに何も現れない -Confirm the credentials environment variables are set on the collector container, that `s3_force_path_style` is `true`, and that the exporter can reach `http://rustfs:9000` from inside the Compose network. Enable the `debug` exporter on the same pipeline to see whether records flow at all. +Collector コンテナに認証情報の環境変数が設定されていること、`s3_force_path_style` が `true` であること、exporter が Compose ネットワーク内から `http://rustfs:9000` に到達できることを確認します。同じパイプラインで `debug` exporter を有効にすると、レコードが流れているかを確認できます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional collector operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [AWS S3 exporter documentation](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/awss3exporter) to add metrics and traces pipelines. +- 追加の Collector 操作を採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [AWS S3 exporter のドキュメント](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/awss3exporter)に従い、メトリクスとトレースのパイプラインを追加してください。 diff --git a/content/ja/developer/integration/observability/tempo.md b/content/ja/developer/integration/observability/tempo.md index ab5bcd8a0..ba8e7c356 100644 --- a/content/ja/developer/integration/observability/tempo.md +++ b/content/ja/developer/integration/observability/tempo.md @@ -288,6 +288,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [Grafana Tempo ドキュメント](https://grafana.com/docs/tempo/latest/)に従って、OpenTelemetry Collector や計装済みアプリケーションをトレースプロデューサーとして接続してください。 diff --git a/content/ja/developer/integration/observability/thanos.md b/content/ja/developer/integration/observability/thanos.md index 856c31db6..bf1358c2e 100644 --- a/content/ja/developer/integration/observability/thanos.md +++ b/content/ja/developer/integration/observability/thanos.md @@ -1,13 +1,13 @@ --- title: "Thanos" -description: "Run Thanos with RustFS as the S3 object storage backend for Prometheus blocks, deployed with Docker Compose." +description: "Docker Compose でデプロイし、Prometheus ブロックの S3 オブジェクトストレージバックエンドとして RustFS を使って Thanos を実行します。" --- -This guide connects [Thanos](https://github.com/thanos-io/thanos) — the highly available Prometheus setup with long-term storage — to **RustFS** as its object store. You will run Prometheus with a Thanos sidecar that uploads TSDB blocks to RustFS, then query the historical data back through a Store Gateway and a Query frontend. The workflow was verified with `thanosio/thanos:v0.37.2`, `prom/prometheus:v2.53.1`, and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、長期保存を備えた高可用性 Prometheus 構成である [Thanos](https://github.com/thanos-io/thanos) を、オブジェクトストアとして **RustFS** に接続します。TSDB ブロックを RustFS へアップロードする Thanos サイドカー付きの Prometheus を実行し、Store Gateway と Query フロントエンドを通じて過去データをクエリします。この流れは `thanosio/thanos:v0.37.2`、`prom/prometheus:v2.53.1`、`rustfs/rustfs-x86-musl:v2.3.1` で検証済みです。 -You need Docker with the Compose plugin. This deployment is intended for local integration testing, not production. +Docker と Compose プラグインが必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -18,27 +18,27 @@ flowchart LR Query -->|gRPC| Store ``` -The sidecar watches the Prometheus TSDB directory and uploads every two-hour block to the `thanos-data` bucket in RustFS. The Store Gateway reads the same bucket and answers queries about historical blocks, so Query resolves both live data through the sidecar and old data through the Store Gateway. +サイドカーは Prometheus の TSDB ディレクトリを監視し、2 時間ごとのブロックを RustFS の `thanos-data` バケットへアップロードします。Store Gateway は同じバケットを読み、過去のブロックに関するクエリに応答します。そのため Query は、ライブデータをサイドカー経由で、古いデータを Store Gateway 経由で解決します。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create a working directory: +作業ディレクトリを作成します。 ```bash mkdir rustfs-thanos cd rustfs-thanos ``` -Create an environment file and replace both credential placeholders: +環境変数ファイルを作成し、2 つの認証情報プレースホルダーを置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use dedicated credentials for the `thanos-data` bucket. Do not commit `.env` to source control. +`thanos-data` バケットには専用の認証情報を使用してください。`.env` をバージョン管理にコミットしないでください。 -Create the Prometheus configuration with an external label — Thanos requires it to deduplicate blocks: +外部ラベル付きの Prometheus 設定を作成します。Thanos はブロックの重複排除に外部ラベルを必要とします。 ```yaml title="prometheus.yml" global: @@ -56,7 +56,7 @@ scrape_configs: - targets: ["rustfs:9000"] ``` -Create the Thanos object store configuration: +Thanos のオブジェクトストア設定を作成します。 ```yaml title="bucket.yml" type: S3 @@ -68,13 +68,13 @@ config: insecure: true ``` -Thanos does not interpolate `.env` files itself. Before starting the stack, replace the placeholders with the same values you set in `.env`: +Thanos 自身は `.env` ファイルを展開しません。スタックを起動する前に、プレースホルダーを `.env` で設定した同じ値に置き換えます。 ```bash sed -i.bak "s|\${RUSTFS_ACCESS_KEY}|$(grep RUSTFS_ACCESS_KEY .env | cut -d= -f2)|;s|\${RUSTFS_SECRET_KEY}|$(grep RUSTFS_SECRET_KEY .env | cut -d= -f2)|" bucket.yml ``` -Create the Compose file: +Compose ファイルを作成します。 ```yaml title="compose.yaml" services: @@ -189,47 +189,47 @@ volumes: store-data: ``` -The `--storage.tsdb.min-block-duration` and `--storage.tsdb.max-block-duration` flags disable Prometheus compaction. The sidecar refuses to ship blocks from a compacting TSDB because the local blocks would no longer match the uploaded ones. +`--storage.tsdb.min-block-duration` と `--storage.tsdb.max-block-duration` は Prometheus のコンパクションを無効にします。コンパクション中の TSDB からブロックを送出すると、ローカルのブロックがアップロード済みのものと一致しなくなるため、サイドカーは送出を拒否します。 -## 2. Validate and start the deployment +## 2. デプロイを検証して開始する -Resolve the Compose file before starting containers: +コンテナを起動する前に Compose ファイルを解決します。 ```bash docker compose config ``` -Start the stack and wait until the sidecar reports itself ready: +スタックを起動し、サイドカーが ready を報告するまで待ちます。 ```bash docker compose up -d docker compose logs sidecar | grep -m1 "status=ready" ``` -Check that the sidecar picked up the Prometheus external labels: +サイドカーが Prometheus の外部ラベルを取り込んだことを確認します。 ```bash docker compose logs sidecar | grep "external labels" ``` -The Thanos Query UI answers on `http://localhost:9091`, and the RustFS Console runs at `http://localhost:9001`. +Thanos Query の UI は `http://localhost:9091` で応答し、RustFS Console（管理画面）は `http://localhost:9001` で動作します。 -## 3. Upload a block to RustFS +## 3. ブロックを RustFS へアップロードする -The sidecar uploads a block when Prometheus compacts one, which happens at a two-hour block boundary. To produce a block immediately, snapshot the TSDB through the admin API — with compaction disabled, the sidecar ships the head-block snapshot directly: +サイドカーは Prometheus がブロックをコンパクトしたときにアップロードします。これは 2 時間のブロック境界で起きます。すぐにブロックを作るには、管理 API で TSDB のスナップショットを取得します。コンパクションが無効な場合、サイドカーはヘッドブロックのスナップショットをそのまま送出します。 ```bash curl -s -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot | head -c 200 ``` -Wait for the upload, then check the shipper state inside Prometheus: +アップロードを待ち、Prometheus 内のシッパーの状態を確認します。 ```bash sleep 60 docker compose exec prometheus cat /prometheus/thanos.shipper.json ``` -The `uploaded` list should contain a block ID: +`uploaded` の一覧にブロック ID が入るはずです。 ```json { @@ -240,15 +240,15 @@ The `uploaded` list should contain a block ID: } ``` -## 4. Query historical data from RustFS +## 4. RustFS から過去データをクエリする -The Store Gateway periodically syncs the bucket. Confirm it downloaded the uploaded block: +Store Gateway はバケットを定期的に同期します。アップロードされたブロックをダウンロードしたことを確認します。 ```bash docker compose logs store | grep "loaded new block" ``` -Query a series through the Query frontend over the block's time range: +ブロックの時間範囲について、Query フロントエンド経由で系列をクエリします。 ```bash START=$(date -u -d '2 hours ago' +%s) @@ -256,17 +256,17 @@ END=$(date -u +%s) curl -s "http://localhost:9091/api/v1/query_range?query=up%7Bjob%3D%22prometheus%22%7D&start=$START&end=$END&step=30" | head -c 300 ``` -The Store Gateway serves the response from the blocks it downloaded from RustFS, while the sidecar answers for the live head — both paths resolve through the same Query endpoint. +Store Gateway は RustFS からダウンロードしたブロックで応答し、サイドカーはライブのヘッドに応答します。どちらの経路も同じ Query エンドポイントで解決されます。 -## 5. Verify objects in RustFS +## 5. RustFS 内のオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash docker compose exec rustfs /usr/bin/rc ls local/thanos-data/ -r ``` -Each block is stored as three objects — the chunk files, the index, and `meta.json`: +各ブロックは 3 つのオブジェクトとして保存されます。チャンクファイル、インデックス、`meta.json` です。 ```text 01M31EPTZC5E0SETZTP0SPFY79/chunks/000001 @@ -274,38 +274,38 @@ Each block is stored as three objects — the chunk files, the index, and `meta. 01M31EPTZC5E0SETZTP0SPFY79/meta.json ``` -![Thanos blocks stored in the RustFS Console](./images/rustfs-thanos-blocks.png) +![RustFS Console に保存された Thanos のブロック](./images/rustfs-thanos-blocks.png) -## 6. Stop or reset the deployment +## 6. デプロイを停止またはリセットする -Stop the containers while keeping all data: +データを残したままコンテナを停止します。 ```bash docker compose down ``` -The RustFS volume keeps the uploaded blocks, so the Store Gateway serves historical queries again after a restart. To delete everything, including the blocks in RustFS, add `--volumes`. +RustFS のボリュームはアップロード済みブロックを保持するため、再起動後も Store Gateway は過去のクエリに応答します。RustFS 内のブロックを含めてすべて削除するには、`--volumes` を追加します。 -## Troubleshooting +## トラブルシューティング -### The sidecar logs `Compaction needs to be disabled` +### サイドカーが `Compaction needs to be disabled` を記録する -Prometheus must run with `--storage.tsdb.min-block-duration` equal to `--storage.tsdb.max-block-duration` — set both to `2h` as shown in the Compose file. Otherwise the sidecar cannot guarantee that local blocks stay unchanged and refuses to upload. +Prometheus は `--storage.tsdb.min-block-duration` と `--storage.tsdb.max-block-duration` を同じ値で実行する必要があります。Compose ファイルのとおり両方を `2h` に設定します。そうしないと、サイドカーはローカルブロックが変化しないことを保証できず、アップロードを拒否します。 ### `The specified bucket does not exist` -Thanos does not create buckets. Check that the `create-bucket` service completed successfully: +Thanos はバケットを作成しません。`create-bucket` サービスが正常に完了したことを確認します。 ```bash docker compose logs create-bucket ``` -### Queries return no historical data +### クエリが過去データを返さない -Confirm that the Store Gateway has loaded at least one block (`docker compose logs store | grep "loaded new block"`) and that your query time range falls inside the uploaded block's window — check the block's `meta.json` in the RustFS Console for `minTime` and `maxTime`. +Store Gateway が少なくとも 1 つのブロックを読み込んでいること（`docker compose logs store | grep "loaded new block"`）、およびクエリの時間範囲がアップロード済みブロックの範囲内であることを確認します。ブロックの `minTime` と `maxTime` は、RustFS Console の `meta.json` で確認できます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Thanos components. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Thanos documentation](https://thanos.io/tip/thanos/getting-started.md) to add Compactor, Ruler, or Receive for a production topology. +- 追加の Thanos コンポーネントを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [Thanos のドキュメント](https://thanos.io/tip/thanos/getting-started.md)に従い、本番トポロジ向けに Compactor、Ruler、Receive を追加してください。 diff --git a/content/ja/developer/integration/observability/victoriametrics.md b/content/ja/developer/integration/observability/victoriametrics.md index efc799d9a..852c4e2fa 100644 --- a/content/ja/developer/integration/observability/victoriametrics.md +++ b/content/ja/developer/integration/observability/victoriametrics.md @@ -1,13 +1,13 @@ --- title: "VictoriaMetrics" -description: "Back up VictoriaMetrics snapshots to RustFS with vmbackup." +description: "vmbackup で VictoriaMetrics のスナップショットを RustFS へバックアップします。" --- -This guide connects [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) — the Prometheus-compatible time-series database — to **RustFS** through `vmbackup` and `vmrestore`. You will run a single-node instance, import metrics, create an instant snapshot, back it up to a RustFS bucket, and restore the data into a fresh directory. The workflow was verified with `victoria-metrics`, `vmbackup`, and `vmrestore` v1.x images against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Prometheus 互換の時系列データベースである [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) を、`vmbackup` と `vmrestore` 経由で **RustFS** に接続します。シングルノードのインスタンスを実行し、メトリクスをインポートし、即時スナップショットを作成して RustFS のバケットへバックアップし、新しいディレクトリへデータを復元します。この流れは `victoria-metrics`、`vmbackup`、`vmrestore` の v1.x イメージを `rustfs/rustfs-x86-musl:v2.3.1` に対して検証済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの統合テストを目的としており、本番環境向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -17,11 +17,11 @@ flowchart LR RustFS -->|"restore"| Restore["vmrestore"] ``` -`vmbackup` uploads a consistent point-in-time snapshot of the storage directory to any S3-compatible endpoint. `vmrestore` reverses the process, producing a data directory a VictoriaMetrics instance can open directly. +`vmbackup` はストレージディレクトリの一貫したある時点のスナップショットを、任意の S3 互換エンドポイントへアップロードします。`vmrestore` はその逆を行い、VictoriaMetrics インスタンスがそのまま開けるデータディレクトリを作ります。 -## 1. Run VictoriaMetrics +## 1. VictoriaMetrics を実行する -Create the bucket and start a single-node instance: +バケットを作成し、シングルノードのインスタンスを起動します。 ```bash rc mb rustfs/vm-backups @@ -32,16 +32,16 @@ docker run -d --name vm --network oo-rustfs_default -p 8428:8428 \ -storageDataPath=/storage -retentionPeriod=100y ``` -## 2. Import metrics +## 2. メトリクスをインポートする -Write a couple of samples through the Prometheus import API: +Prometheus のインポート API でサンプルを数件書き込みます。 ```bash echo "vm_demo_metric 123" | curl -s --data-binary @- http://localhost:8428/api/v1/import/prometheus echo "vm_demo_metric 456" | curl -s --data-binary @- http://localhost:8428/api/v1/import/prometheus ``` -The endpoint answers `204 No Content`. Confirm the data is queryable: +エンドポイントは `204 No Content` を返します。データをクエリできることを確認します。 ```bash curl -s "http://localhost:8428/api/v1/export?match[]=vm_demo_metric" @@ -51,9 +51,9 @@ curl -s "http://localhost:8428/api/v1/export?match[]=vm_demo_metric" {"metric":{"__name__":"vm_demo_metric"},"values":[123,456],"timestamps":[1790680894604,1790680894619]} ``` -## 3. Create a snapshot +## 3. スナップショットを作成する -Ask VictoriaMetrics for a consistent snapshot: +VictoriaMetrics に一貫したスナップショットを要求します。 ```bash curl -s http://localhost:8428/snapshot/create @@ -63,9 +63,9 @@ curl -s http://localhost:8428/snapshot/create {"status":"ok","snapshot":"20260929112134-18D9C6C76704F913"} ``` -## 4. Back the snapshot up to RustFS +## 4. スナップショットを RustFS へバックアップする -Run `vmbackup` against the same storage volume, replacing the credential placeholders. The snapshot name comes from step 3: +認証情報のプレースホルダーを置き換え、同じストレージボリュームに対して `vmbackup` を実行します。スナップショット名は手順 3 のものです。 ```bash docker run --rm --network oo-rustfs_default \ @@ -83,11 +83,11 @@ docker run --rm --network oo-rustfs_default \ backup ... to S3{bucket: "vm-backups", dir: "demo/"} is complete; uploaded 760 bytes ``` -`-customS3Endpoint` redirects the AWS SDK to RustFS; custom endpoints are addressed with path-style requests automatically. Set `AWS_EC2_METADATA_DISABLED=true` on hosts without an EC2 metadata service to skip credential lookup delays. +`-customS3Endpoint` は AWS SDK を RustFS へ向けます。カスタムエンドポイントには、自動的にパススタイルアクセスが使われます。EC2 メタデータサービスがないホストでは `AWS_EC2_METADATA_DISABLED=true` を設定し、認証情報の探索による遅延を避けます。 -## 5. Verify and restore +## 5. 確認して復元する -List the bucket prefix: +バケットのプレフィックスを一覧します。 ```bash rc ls rustfs/vm-backups/demo/ @@ -100,7 +100,7 @@ data/ metadata/ ``` -`backup_complete.ignore` marks a complete backup. Restore it into a fresh directory: +`backup_complete.ignore` はバックアップの完了を示します。新しいディレクトリへ復元します。 ```bash docker run --rm --network oo-rustfs_default \ @@ -117,41 +117,41 @@ docker run --rm --network oo-rustfs_default \ restored 760 bytes from backup in 0.055 seconds ``` -The restored directory contains `data/`, `metadata/`, and a lock file — exactly what a VictoriaMetrics instance expects at `-storageDataPath`. +復元先ディレクトリには `data/`、`metadata/`、ロックファイルが含まれます。これは VictoriaMetrics インスタンスが `-storageDataPath` に期待する構成そのものです。 -![VictoriaMetrics backup stored in the RustFS Console](./images/rustfs-vm-backups.png) +![RustFS Console に保存された VictoriaMetrics のバックアップ](./images/rustfs-vm-backups.png) -## 6. Stop or reset +## 6. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したままデモを破棄します。 ```bash docker rm -f vm docker volume rm vm-data ``` -To delete the stored backups: +保存したバックアップを削除します。 ```bash rc rm rustfs/vm-backups/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `vmbackup` hangs at startup or fails to find credentials +### `vmbackup` が起動時にハングする、または認証情報を見つけられない -The AWS SDK probes the EC2 metadata service when environment credentials are absent. On machines without IMDS, export `AWS_EC2_METADATA_DISABLED=true` next to the key variables. +環境変数の認証情報がないと、AWS SDK は EC2 メタデータサービスを探索します。IMDS がないマシンでは、キーの変数と一緒に `AWS_EC2_METADATA_DISABLED=true` をエクスポートします。 -### Backup parts re-upload on every run +### バックアップの一部が実行のたびに再アップロードされる -`vmbackup` performs incremental backups by comparing local and remote file hashes. Restoring to a fresh directory and running `vmbackup` from there re-uploads everything; keep the original data directory for incremental runs. +`vmbackup` はローカルとリモートのファイルハッシュを比較して増分バックアップを行います。新しいディレクトリへ復元してそこから `vmbackup` を実行すると、すべてが再アップロードされます。増分実行には元のデータディレクトリを維持します。 -### Query returns nothing right after import +### インポート直後のクエリが何も返さない -Imports are accepted asynchronously and the instant query endpoint can lag on a busy single node. Verify with `/api/v1/export` (or wait a few seconds) before creating the snapshot. +インポートは非同期に受け付けられ、負荷の高いシングルノードでは即時クエリのエンドポイントが遅れることがあります。スナップショットを作成する前に `/api/v1/export` で確認するか、数秒待ちます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional VictoriaMetrics components. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [vmbackup documentation](https://docs.victoriametrics.com/vmbackup/) to schedule backups and prune old snapshots. +- 追加の VictoriaMetrics コンポーネントを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- [vmbackup のドキュメント](https://docs.victoriametrics.com/vmbackup/)に従い、バックアップのスケジュールと古いスナップショットの削除を設定してください。 diff --git a/content/ja/developer/integration/others/juicefs.md b/content/ja/developer/integration/others/juicefs.md index 428b08cec..83589ccfc 100644 --- a/content/ja/developer/integration/others/juicefs.md +++ b/content/ja/developer/integration/others/juicefs.md @@ -1,13 +1,13 @@ --- title: "JuiceFS" -description: "Build a POSIX filesystem on RustFS with JuiceFS S3 object storage." +description: "JuiceFS の S3 オブジェクトストレージを使い、RustFS 上に POSIX ファイルシステムを構築します。" --- -This guide connects [JuiceFS](https://github.com/juicedata/juicefs) — the cloud-native distributed POSIX filesystem — to **RustFS** as its object storage backend. You will format a volume whose data chunks live in a RustFS bucket, mount it locally, and read and write files through the mount. The workflow was verified with `juicefs v1.3.1` (community edition, SQLite metadata engine) against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、クラウドネイティブな分散 POSIX ファイルシステムである [JuiceFS](https://github.com/juicedata/juicefs) を、オブジェクトストレージのバックエンドとして **RustFS** に接続します。データチャンクが RustFS のバケットに置かれるボリュームをフォーマットし、ローカルにマウントして、マウント経由でファイルを読み書きします。手順は `juicefs v1.3.1`（コミュニティ版、SQLite メタデータエンジン）と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need the JuiceFS binary, a metadata engine, and FUSE (`fuse3` on Linux). This deployment is intended for local integration testing, not production. +JuiceFS のバイナリ、メタデータエンジン、FUSE（Linux では `fuse3`）が必要です。このデプロイはローカルでの連携テスト用であり、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,11 +16,11 @@ flowchart LR JuiceFS -->|"data chunks"| RustFS["RustFS :9000"] ``` -JuiceFS splits every file into chunks and stores them as objects under `chunks/` in the bucket, while the metadata engine tracks names, inodes, and layout. The filesystem behaves like a local disk but holds no data locally. +JuiceFS は各ファイルをチャンクに分割し、バケット内の `chunks/` 配下にオブジェクトとして保存します。名前、inode、レイアウトはメタデータエンジンが追跡します。ファイルシステムはローカルディスクのように振る舞いますが、データ自体はローカルに持ちません。 -## 1. Format the volume +## 1. ボリュームをフォーマットする -Create the bucket and format a JuiceFS volume backed by RustFS, replacing all connection placeholders. The bucket URL carries the endpoint, which selects path-style addressing: +接続用のプレースホルダーをすべて置き換えて、バケットを作成し、RustFS をバックエンドとする JuiceFS ボリュームをフォーマットします。バケット URL にエンドポイントが含まれ、これによりパススタイルアクセスが選択されます。 ```bash rc mb rustfs/jfs-demo @@ -39,11 +39,11 @@ Data use s3://:9000/jfs-demo/rustfs-jfs/ OK, rustfs-jfs is ready ``` -`sqlite3:///opt/juicefs/jfs.db` is the metadata engine for this test. In production, use Redis, MySQL, or PostgreSQL instead so multiple clients can mount the same volume. +このテストのメタデータエンジンは `sqlite3:///opt/juicefs/jfs.db` です。本番では、複数のクライアントが同じボリュームをマウントできるよう、Redis、MySQL、または PostgreSQL を使います。 -## 2. Mount the volume +## 2. ボリュームをマウントする -Mount the filesystem with the same metadata URL: +同じメタデータ URL でファイルシステムをマウントします。 ```bash mkdir -p /mnt/jfs @@ -54,11 +54,11 @@ juicefs mount -d sqlite3:///opt/juicefs/jfs.db /mnt/jfs OK, rustfs-jfs is ready at /mnt/jfs ``` -The `-d` flag runs the mount in the background. The volume is now a POSIX filesystem. +`-d` フラグはマウントをバックグラウンドで実行します。これでボリュームは POSIX ファイルシステムになります。 -## 3. Read and write files +## 3. ファイルを読み書きする -Use the mount like any other directory: +ほかのディレクトリと同じようにマウントを使います。 ```bash echo "hello rustfs jfs" > /mnt/jfs/hello.txt @@ -71,7 +71,7 @@ cat /mnt/jfs/hello.txt hello rustfs jfs ``` -Inspect the volume with `juicefs info`: +`juicefs info` でボリュームを確認します。 ```text /mnt/jfs : @@ -81,15 +81,15 @@ Inspect the volume with `juicefs info`: length: 3.00 MiB ``` -## 4. Verify chunks in RustFS +## 4. RustFS でチャンクを確認する -List the bucket prefixes: +バケットのプレフィックスを一覧します。 ```bash rc ls rustfs/jfs-demo/ -r ``` -Every file was split into content-addressed chunk objects: +各ファイルは、コンテンツアドレス指定のチャンクオブジェクトに分割されています。 ```text rustfs-jfs/chunks/0/0/1_0_17 @@ -97,13 +97,13 @@ rustfs-jfs/chunks/0/0/3_0_3145728 rustfs-jfs/chunks/0/0/4_0_7 ``` -The chunk name encodes the inode, chunk index, and size — for example `3_0_3145728` is the 3 MiB file written in step 3. +チャンク名には inode、チャンクインデックス、サイズがエンコードされています。たとえば `3_0_3145728` は、手順 3 で書き込んだ 3 MiB のファイルです。 -![JuiceFS data chunks stored in the RustFS Console](./images/rustfs-juicefs-chunks.png) +![RustFS Console に保存された JuiceFS のデータチャンク](./images/rustfs-juicefs-chunks.png) -## 5. Stop or reset +## 5. 停止またはリセットする -Unmount the volume, then optionally wipe the volume metadata and bucket data: +ボリュームをアンマウントし、必要に応じてボリュームのメタデータとバケットデータを消去します。 ```bash juicefs umount /mnt/jfs @@ -111,22 +111,22 @@ juicefs destroy --force sqlite3:///opt/juicefs/jfs.db rustfs-jfs rc rm rustfs/jfs-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `unknown option: --daemon` -The background flag is a single dash: `juicefs mount -d`. Running without it keeps the mount in the foreground (useful for debugging). +バックグラウンド用フラグはハイフン 1 つです。`juicefs mount -d` を使います。付けないと、マウントはフォアグラウンドのままです（デバッグに便利です）。 ### `fusermount3: mount failed: Permission denied` -Mounting requires the FUSE device. Inside a container, add `--device /dev/fuse --cap-add SYS_ADMIN` (or `--privileged`); on a host, install `fuse3` and confirm `/dev/fuse` exists. +マウントには FUSE デバイスが必要です。コンテナ内では `--device /dev/fuse --cap-add SYS_ADMIN`（または `--privileged`）を追加します。ホストでは `fuse3` をインストールし、`/dev/fuse` が存在することを確認します。 -### Mount hangs or fails to reach storage +### マウントがハングする、またはストレージに到達できない -The client must reach both the metadata engine and the bucket endpoint. Because the bucket URL embeds the endpoint, verify it from the mounting host with `curl` before formatting. +クライアントは、メタデータエンジンとバケットのエンドポイントの両方に到達できる必要があります。バケット URL にはエンドポイントが埋め込まれているため、フォーマットの前にマウント元ホストから `curl` で確認します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional JuiceFS storage backends. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [JuiceFS documentation](https://juicefs.com/docs/community/quick_start_guide/) to switch the metadata engine to Redis and mount the volume from multiple clients. +- ほかの JuiceFS ストレージバックエンドを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- メタデータエンジンを Redis に切り替え、複数のクライアントからボリュームをマウントするには、[JuiceFS のドキュメント](https://juicefs.com/docs/community/quick_start_guide/)に従います。 diff --git a/content/ja/developer/integration/others/nextcloud.md b/content/ja/developer/integration/others/nextcloud.md index f506d75ca..e5e0c18f5 100644 --- a/content/ja/developer/integration/others/nextcloud.md +++ b/content/ja/developer/integration/others/nextcloud.md @@ -1,13 +1,13 @@ --- title: "Nextcloud" -description: "Use RustFS as S3 external storage for Nextcloud files." +description: "Nextcloud のファイル向け S3 外部ストレージとして RustFS を使います。" --- -This guide connects [Nextcloud](https://github.com/nextcloud/server) — the self-hosted content collaboration platform — to **RustFS** through its External Storage app with the S3 backend. You will enable `files_external`, mount a RustFS bucket into every user's files view, and upload a file through WebDAV that lands directly in the bucket. The workflow was verified with `nextcloud:32.0.15` (SQLite, single container) against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、セルフホスト型のコンテンツ共同作業プラットフォームである [Nextcloud](https://github.com/nextcloud/server) を、External Storage アプリの S3 バックエンド経由で **RustFS** に接続します。`files_external` を有効にし、各ユーザーのファイルビューに RustFS のバケットをマウントして、WebDAV 経由でアップロードしたファイルがバケットへ直接保存されることを確認します。手順は `nextcloud:32.0.15`（SQLite、単一コンテナ）と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker, or an existing Nextcloud instance with `occ` access. This deployment is intended for local integration testing, not production. +Docker、または `occ` にアクセスできる既存の Nextcloud インスタンスが必要です。このデプロイはローカルでの連携テスト用であり、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR Nextcloud -->|"files_external (S3)"| RustFS["RustFS :9000"] ``` -Nextcloud proxies file operations on the mount point to the S3 backend. Objects are stored under their mount-relative paths, so the bucket mirrors the names users see. +Nextcloud は、マウントポイント上のファイル操作を S3 バックエンドへ中継します。オブジェクトはマウントからの相対パスの下に保存されるため、バケットにはユーザーが見る名前がそのまま反映されます。 -## 1. Install Nextcloud +## 1. Nextcloud をインストールする -Run Nextcloud with an admin account, replacing all connection placeholders. SQLite keeps the test self-contained; use MariaDB or PostgreSQL in production: +接続用のプレースホルダーをすべて置き換えて、管理者アカウント付きで Nextcloud を実行します。SQLite にすると、テストを自己完結にできます。本番では MariaDB または PostgreSQL を使います。 ```bash docker run -d --name nextcloud --network oo-rustfs_default -p 8080:80 \ @@ -28,16 +28,16 @@ docker run -d --name nextcloud --network oo-rustfs_default -p 8080:80 \ nextcloud:32.0.15 ``` -If the web UI still shows the installer after startup, finish it manually: +起動後も Web UI にインストーラーが表示される場合は、手動で完了します。 ```bash docker exec -u www-data nextcloud php occ maintenance:install \ --admin-user --admin-password ``` -## 2. Enable the External Storage app +## 2. External Storage アプリを有効にする -The `files_external` app ships with Nextcloud but starts disabled, and its `occ` commands only exist once the app is enabled: +`files_external` アプリは Nextcloud に同梱されていますが、初期状態では無効です。このアプリの `occ` コマンドは、有効にした後にだけ存在します。 ```bash docker exec -u www-data nextcloud php occ app:enable files_external @@ -47,9 +47,9 @@ docker exec -u www-data nextcloud php occ app:enable files_external files_external 1.24.1 enabled ``` -## 3. Mount the RustFS bucket +## 3. RustFS のバケットをマウントする -Create an external storage of backend type `amazons3` with the `amazons3::accesskey` authentication backend. Replace all connection placeholders: +バックエンド種別 `amazons3` と、認証バックエンド `amazons3::accesskey` で外部ストレージを作成します。接続用のプレースホルダーをすべて置き換えます。 ```bash docker exec -u www-data nextcloud php occ files_external:create \ @@ -68,7 +68,7 @@ docker exec -u www-data nextcloud php occ files_external:create \ Storage created with id 1 ``` -The mount point `/rustfs` appears in the files view of the given user. `use_path_style=true` is required for a non-AWS endpoint. Check the connection before using it: +マウントポイント `/rustfs` は、指定したユーザーのファイルビューに表示されます。AWS 以外のエンドポイントでは `use_path_style=true` が必要です。使う前に接続を確認します。 ```bash docker exec -u www-data nextcloud php occ files_external:verify 1 @@ -79,9 +79,9 @@ docker exec -u www-data nextcloud php occ files_external:verify 1 - code: 0 ``` -## 4. Upload a file and verify +## 4. ファイルをアップロードして確認する -Upload through the WebDAV endpoint, which writes through the external storage: +外部ストレージ経由で書き込まれる WebDAV エンドポイントからアップロードします。 ```bash echo "nextcloud writes to rustfs" > /tmp/nc-demo.txt @@ -96,7 +96,7 @@ curl -u : \ 201 ``` -Read it back through the same path, then confirm the object in RustFS: +同じパスから読み戻し、RustFS でオブジェクトを確認します。 ```bash rc ls rustfs// -r @@ -106,40 +106,40 @@ rc ls rustfs// -r [2026-09-29 13:42:48] 27 B nc-demo.txt ``` -The object key equals the path inside the mount, so files uploaded through Nextcloud can also be read directly with any S3 client. +オブジェクトキーはマウント内のパスと一致するため、Nextcloud 経由でアップロードしたファイルは、任意の S3 クライアントから直接読み取れます。 -![Nextcloud file stored in the RustFS Console](./images/rustfs-nextcloud-file.png) +![RustFS Console に保存された Nextcloud のファイル](./images/rustfs-nextcloud-file.png) -## 5. Stop or reset +## 5. 停止またはリセットする -To remove the mount without touching the bucket: +バケットには触れずにマウントを削除します。 ```bash docker exec -u www-data nextcloud php occ files_external:delete 1 ``` -To delete the bucket contents: +バケットの内容を削除します。 ```bash rc rm rustfs// --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `There are no commands defined in the "files_external" namespace` -The app is not enabled yet. Run `occ app:enable files_external` first; the `occ files_external:*` commands only register afterwards. +アプリがまだ有効になっていません。先に `occ app:enable files_external` を実行します。`occ files_external:*` コマンドは、その後に登録されます。 ### `Not enough arguments (missing: "authentication_backend")` -`files_external:create` takes the storage backend and the authentication backend as two separate arguments: `amazons3 amazons3::accesskey`. The backend identifiers are listed by `occ files_external:backends`. +`files_external:create` は、ストレージバックエンドと認証バックエンドを別々の引数として受け取ります。指定する値は `amazons3 amazons3::accesskey` です。バックエンド識別子は `occ files_external:backends` で一覧できます。 -### Mount shows but is empty, or uploads fail +### マウントは表示されるが空である、またはアップロードが失敗する -Confirm `hostname` is reachable from the Nextcloud container (use the container network name, not `localhost`), `use_path_style` is `true`, and the bucket exists. `occ files_external:verify ` reports the exact connection error. +`hostname` が Nextcloud コンテナから到達できること（`localhost` ではなくコンテナのネットワーク名を使います）、`use_path_style` が `true` であること、バケットが存在することを確認します。`occ files_external:verify ` が、具体的な接続エラーを報告します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional external storage backends. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Nextcloud external storage documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage_configuration_gui.html) to share the mount with groups and enable versioning. +- ほかの外部ストレージバックエンドを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- マウントをグループと共有し、バージョニングを有効にするには、[Nextcloud の外部ストレージのドキュメント](https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage_configuration_gui.html)に従います。 diff --git a/content/ja/developer/integration/others/rclone.md b/content/ja/developer/integration/others/rclone.md index 34f9fe4aa..f96af63b7 100644 --- a/content/ja/developer/integration/others/rclone.md +++ b/content/ja/developer/integration/others/rclone.md @@ -1,13 +1,13 @@ --- title: "rclone" -description: "Sync, mount, and serve RustFS buckets with rclone over its S3-compatible API." +description: "rclone の S3 互換 API 経由で、RustFS のバケットの同期、マウント、配信を行います。" --- -This guide connects [rclone](https://github.com/rclone/rclone) — the command-line tool for syncing files to and from cloud storage — to **RustFS** through its S3 backend. You will configure an S3 remote for RustFS, copy and sync files, read objects back, publish a bucket over HTTP with `rclone serve`, and mount the bucket as a local filesystem with `rclone mount`. The workflow was verified with `rclone v1.75.1` against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、クラウドストレージとの間でファイルを同期するコマンドラインツールである [rclone](https://github.com/rclone/rclone) を、S3 バックエンド経由で **RustFS** に接続します。RustFS 向けの S3 リモートを設定し、ファイルのコピーと同期、オブジェクトの読み戻し、`rclone serve` による HTTP でのバケット公開、`rclone mount` によるローカルファイルシステムとしてのマウントを行います。手順は `rclone v1.75.1` と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker, or a local rclone binary. This deployment is intended for local integration testing, not production. +Docker、またはローカルの rclone バイナリが必要です。このデプロイはローカルでの連携テスト用であり、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -16,11 +16,11 @@ flowchart LR RustFS -->|"mount / serve"| Client["FUSE mount / HTTP clients"] ``` -One remote definition drives every rclone command: data transfer, mounting, and serving all use the same S3 connection. +すべての rclone コマンドは、1 つのリモート定義を使います。データ転送、マウント、配信は、同じ S3 接続を使います。 -## 1. Configure the remote +## 1. リモートを設定する -Create an rclone config file with an S3 remote for RustFS, replacing all connection placeholders. The `Other` provider disables AWS-specific behavior, and path-style addressing is used automatically for custom endpoints: +接続用のプレースホルダーをすべて置き換えて、RustFS 向けの S3 リモートを含む rclone の設定ファイルを作成します。`Other` プロバイダーは AWS 固有の動作を無効にします。カスタムエンドポイントでは、パススタイルアクセスが自動的に使われます。 ```ini title="rclone.conf" [rustfs] @@ -32,16 +32,16 @@ endpoint = http://:9000 region = us-east-1 ``` -## 2. Copy and read objects +## 2. オブジェクトをコピーして読み取る -Create the bucket and upload a directory with `rclone copy`: +バケットを作成し、`rclone copy` でディレクトリをアップロードします。 ```bash rc mb rustfs/rclone-demo rclone copy /data rustfs:rclone-demo/seed ``` -List and read back: +一覧して読み戻します。 ```bash rclone ls rustfs:rclone-demo/seed @@ -54,11 +54,11 @@ rclone cat rustfs:rclone-demo/seed/hello.txt hello from rclone ``` -`rclone lsd rustfs:` lists every bucket on the endpoint. +`rclone lsd rustfs:` は、エンドポイント上のすべてのバケットを一覧します。 -## 3. Sync a directory +## 3. ディレクトリを同期する -`rclone sync` makes the destination identical to the source, including deletions. Remove a local file and sync: +`rclone sync` は、削除を含めて宛先をソースと同一にします。ローカルファイルを削除して同期します。 ```bash rm /data/hello.txt @@ -70,17 +70,17 @@ rclone lsf rustfs:rclone-demo/seed blob.bin ``` -`hello.txt` disappears from the bucket. Add `--dry-run` first to preview the changes without touching the bucket. +`hello.txt` はバケットから消えます。バケットを変更せずに変更内容を確認するには、先に `--dry-run` を付けます。 -## 4. Serve a bucket over HTTP +## 4. HTTP でバケットを配信する -Publish the bucket contents as an HTTP file server: +バケットの内容を HTTP ファイルサーバーとして公開します。 ```bash rclone serve http --addr 0.0.0.0:8080 rustfs:rclone-demo/seed ``` -Any HTTP client can now download objects: +任意の HTTP クライアントからオブジェクトをダウンロードできます。 ```bash curl -s http://localhost:8080/blob.bin -o /dev/null -w "%{http_code} %{size_download} bytes\n" @@ -90,11 +90,11 @@ curl -s http://localhost:8080/blob.bin -o /dev/null -w "%{http_code} %{size_down 200 3145728 bytes ``` -`rclone serve` also supports WebDAV, SFTP, and S3 endpoints over the same remote. +`rclone serve` は、同じリモート上で WebDAV、SFTP、S3 のエンドポイントにも対応します。 -## 5. Mount the bucket as a filesystem +## 5. バケットをファイルシステムとしてマウントする -With FUSE available, mount the bucket locally and use it like a directory: +FUSE が使える場合、バケットをローカルにマウントし、ディレクトリと同じように使います。 ```bash rclone mount rustfs:rclone-demo /mnt/rclone --daemon @@ -103,7 +103,7 @@ echo test > /mnt/rclone/write-test.txt cat /mnt/rclone/write-test.txt ``` -Files written through the mount appear in RustFS as regular objects: +マウント経由で書き込んだファイルは、通常のオブジェクトとして RustFS に現れます。 ```bash rc ls rustfs/rclone-demo/ -r @@ -113,32 +113,32 @@ rc ls rustfs/rclone-demo/ -r [2026-09-29 11:12:41] 5 B write-test.txt ``` -Unmount with `fusermount -u /mnt/rclone` when finished. +終わったら `fusermount -u /mnt/rclone` でアンマウントします。 -## 6. Stop or reset +## 6. 停止またはリセットする -rclone holds no server-side state. To delete the demo data: +rclone はサーバー側の状態を持ちません。デモデータを削除するには、次を実行します。 ```bash rclone purge rustfs:rclone-demo ``` -## Troubleshooting +## トラブルシューティング -### `Access Denied` or empty listings +### `Access Denied`、または一覧が空になる -Confirm `endpoint` includes the scheme and that the key pair matches a RustFS access key. The `region` value is required by the S3 signer even though RustFS ignores it; keep `us-east-1`. +`endpoint` にスキームが含まれ、キーの組が RustFS のアクセスキーと一致することを確認します。`region` の値は、RustFS が無視しても S3 の署名処理では必須です。`us-east-1` のままにします。 -### Mount fails with `fusermount3: mount failed: Permission denied` +### `fusermount3: mount failed: Permission denied` でマウントが失敗する -Mounting needs the FUSE device and elevated privileges. Inside a container, run with `--device /dev/fuse --cap-add SYS_ADMIN` — and use `--privileged` if the mount helper still fails. On a host, verify that `fuse3` is installed and `/dev/fuse` exists. +マウントには FUSE デバイスと昇格した権限が必要です。コンテナ内では `--device /dev/fuse --cap-add SYS_ADMIN` を付けて実行します。マウントヘルパーがそれでも失敗する場合は、`--privileged` を使います。ホストでは、`fuse3` がインストールされ、`/dev/fuse` が存在することを確認します。 -### Sync deleted nothing on the destination +### 同期しても宛先のオブジェクトが削除されない -`rclone copy` never deletes. Only `rclone sync` (or `rclone delete`) removes destination objects, and `--dry-run` is the safe way to preview either. +`rclone copy` は削除しません。宛先のオブジェクトを削除するのは `rclone sync`（または `rclone delete`）だけです。どちらも `--dry-run` で、変更前に確認できます。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional rclone backends. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [rclone S3 documentation](https://rclone.org/s3/) for flags such as `--transfers`, bandwidth limits, and crypt overlays. +- ほかの rclone バックエンドを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- `--transfers`、帯域制限、crypt オーバーレイなどのフラグについては、[rclone の S3 ドキュメント](https://rclone.org/s3/)に従います。 diff --git a/content/ja/developer/integration/others/tusd.md b/content/ja/developer/integration/others/tusd.md index 99f3c5884..3001445a3 100644 --- a/content/ja/developer/integration/others/tusd.md +++ b/content/ja/developer/integration/others/tusd.md @@ -1,13 +1,13 @@ --- title: "tusd" -description: "Receive resumable uploads into RustFS with the tusd server's S3 backend." +description: "tusd サーバーの S3 バックエンドを使い、再開可能なアップロードを RustFS で受け付けます。" --- -This guide connects [tusd](https://github.com/tus/tusd) — the official reference implementation of the tus resumable-upload protocol — to **RustFS** as its S3 storage backend. You will run tusd against a RustFS bucket, create an upload with the tus protocol, send the file in two chunks with an interruption in between, resume from the reported offset, and verify the assembled object in the bucket. The workflow was verified with `tusproject/tusd:v2.10.1` against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、tus 再開可能アップロードプロトコルの公式リファレンス実装である [tusd](https://github.com/tus/tusd) を、S3 ストレージのバックエンドとして **RustFS** に接続します。RustFS のバケットに対して tusd を実行し、tus プロトコルでアップロードを作成し、途中で中断しながらファイルを 2 つのチャンクで送り、報告されたオフセットから再開して、組み立てられたオブジェクトをバケットで確認します。手順は `tusproject/tusd:v2.10.1` と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker, or a local tusd binary. This deployment is intended for local integration testing, not production. +Docker、またはローカルの tusd バイナリが必要です。このデプロイはローカルでの連携テスト用であり、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR tusd -->|"multipart upload"| RustFS["RustFS :9000"] ``` -tusd stores each in-progress upload as S3 multipart parts in the bucket. A client that loses its connection asks the server for the last committed offset with `HEAD` and continues from there — the data already received is never sent twice. +tusd は、進行中の各アップロードを、バケット内の S3 マルチパートアップロードのパートとして保存します。接続を失ったクライアントは、`HEAD` で最後にコミットされたオフセットをサーバーに問い合わせ、そこから続行します。すでに受信したデータが再送されることはありません。 -## 1. Run tusd +## 1. tusd を実行する -Create the bucket and start tusd with the S3 backend, replacing all connection placeholders. The AWS region must be set even though RustFS ignores it: +接続用のプレースホルダーをすべて置き換えて、バケットを作成し、S3 バックエンドを指定して tusd を起動します。RustFS はリージョンを無視しますが、AWS リージョンの設定は必須です。 ```bash rc mb rustfs/tus-uploads @@ -33,7 +33,7 @@ docker run -d --name tusd --network oo-rustfs_default -p 8080:8080 \ -s3-endpoint http://:9000 ``` -Check that the server is healthy: +サーバーが正常であることを確認します。 ```bash curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/health @@ -43,9 +43,9 @@ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/health 200 ``` -## 2. Create the upload +## 2. アップロードを作成する -Create a 6 MiB upload and read the `Location` header: +6 MiB のアップロードを作成し、`Location` ヘッダーを読み取ります。 ```bash curl -s -D - -o /dev/null -X POST http://localhost:8080/files/ \ @@ -57,11 +57,11 @@ curl -s -D - -o /dev/null -X POST http://localhost:8080/files/ \ Location: http://localhost:8080/files/b7338250daa9...+NGVmNDRhZjEt... ``` -The upload URL contains the file ID and a message-authentication tag. Strip the scheme and host before re-sending it (the server echoes whatever `Host` it received, which may not be reachable from your next client). +アップロード URL には、ファイル ID とメッセージ認証タグが含まれます。再送する前にスキームとホストを取り除きます。サーバーは受信した `Host` をそのまま返すため、次のクライアントから到達できないことがあります。 -## 3. Upload in chunks with an interruption +## 3. 中断を挟んでチャンクでアップロードする -Send the first 2.5 MB, then stop — this is the point where a mobile client would lose its connection: +最初の 2.5 MB を送ってから停止します。モバイルクライアントが接続を失う地点に相当します。 ```bash head -c 2500000 demo.bin > part1.bin @@ -76,7 +76,7 @@ curl -s -o /dev/null -w "%{http_code}\n" -X PATCH "http://localhost:8080${LOC}" 204 ``` -Ask the server how much it actually has — this is the resumable-upload core: +サーバーが実際に保持している量を問い合わせます。これが再開可能アップロードの中核です。 ```bash curl -s -X HEAD "http://localhost:8080${LOC}" \ @@ -87,9 +87,9 @@ curl -s -X HEAD "http://localhost:8080${LOC}" \ Upload-Offset: 2500000 ``` -## 4. Resume and finish +## 4. 再開して完了する -Continue from offset 2500000 with the remaining bytes: +残りのバイト列を、オフセット 2500000 から続行します。 ```bash tail -c 3791456 demo.bin > part2.bin @@ -104,7 +104,7 @@ curl -s -o /dev/null -w "%{http_code}\n" -X PATCH "http://localhost:8080${LOC}" 204 ``` -Download the finished upload through tusd and compare checksums with the source: +完了したアップロードを tusd 経由でダウンロードし、ソースとチェックサムを比較します。 ```bash curl -s -o download.bin "http://localhost:8080${LOC}" @@ -116,55 +116,55 @@ d9016032ced6c7515b67a0c556e006c4b25a5858 demo.bin d9016032ced6c7515b67a0c556e006c4b25a5858 download.bin ``` -## 5. Verify objects in RustFS +## 5. RustFS でオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/tus-uploads/ -r ``` -The bucket holds the assembled object plus one `.info` metadata file per upload — both live and finished: +バケットには、組み立てられたオブジェクトと、アップロードごとの `.info` メタデータファイルが入ります。進行中と完了済みの両方が対象です。 ```text b7338250daa9a1a79c1343502b57b28f 6 MiB b7338250daa9a1a79c1343502b57b28f.info 378 B ``` -The object key is the upload ID, and the object body is the uploaded file byte-for-byte — so any S3 client can read completed uploads directly from the bucket. +オブジェクトキーはアップロード ID で、オブジェクト本体はアップロードされたファイルとバイト単位で一致します。完了したアップロードは、任意の S3 クライアントからバケットを直接読み取れます。 -![tus uploads stored in the RustFS Console](./images/rustfs-tus-uploads.png) +![RustFS Console に保存された tus のアップロード](./images/rustfs-tus-uploads.png) -## 6. Stop or reset +## 6. 停止またはリセットする -To tear down the server while keeping the bucket objects: +バケット内のオブジェクトを残したまま、サーバーを解体します。 ```bash docker rm -f tusd ``` -To delete the stored uploads: +保存されたアップロードを削除します。 ```bash rc rm rustfs/tus-uploads/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `CreateMultipartUpload ... A region must be set when sending requests to S3` -tusd builds its S3 client from the AWS environment, and the region is mandatory for endpoint resolution. Export `AWS_REGION=us-east-1` next to the credentials, as in step 1. +tusd は AWS の環境変数から S3 クライアントを構築します。エンドポイント解決にはリージョンが必須です。手順 1 のように、認証情報と並べて `AWS_REGION=us-east-1` をエクスポートします。 -### `PATCH` returns `404` or connects to the wrong host +### `PATCH` が `404` を返す、または誤ったホストに接続する -The `Location` URL echoes the `Host` header of the creation request. When your client and the server use different hostnames (container name versus published port), strip the scheme and host from the URL and send the path to the address the client can reach. +`Location` の URL は、作成リクエストの `Host` ヘッダーをそのまま返します。クライアントとサーバーでホスト名が異なる場合（コンテナ名と公開ポート）は、URL からスキームとホストを取り除き、クライアントが到達できるアドレスへパスを送ります。 -### Upload disappears after server restart +### サーバー再起動後にアップロードが消える -The S3 backend keeps `.info` files in the bucket, so uploads survive restarts. If you run tusd against an empty bucket that another process prunes, the metadata is lost — protect the `tus-uploads` prefix from cleanup jobs. +S3 バックエンドは `.info` ファイルをバケットに保持するため、アップロードは再起動後も残ります。別のプロセスが整理する空のバケットに対して tusd を実行すると、メタデータは失われます。`tus-uploads` プレフィックスをクリーンアップジョブから保護します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional tusd backends. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [tus protocol documentation](https://tus.io/protocols/resumable-upload) for creation-with-upload, termination, and checksum extensions that tusd supports on top of the core protocol. +- ほかの tusd バックエンドを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- tusd がコアプロトコルの上で対応する creation-with-upload、termination、チェックサム拡張については、[tus プロトコルのドキュメント](https://tus.io/protocols/resumable-upload)に従います。 diff --git a/content/ja/developer/integration/registry/docker-registry.md b/content/ja/developer/integration/registry/docker-registry.md index ae84704a4..d63c233a8 100644 --- a/content/ja/developer/integration/registry/docker-registry.md +++ b/content/ja/developer/integration/registry/docker-registry.md @@ -1,13 +1,13 @@ --- title: "Docker Registry" -description: "Store container images from Docker Registry in RustFS." +description: "Docker Registry のコンテナイメージを RustFS に保存します。" --- -This guide connects the open-source [Docker Registry](https://github.com/distribution/distribution) (distribution) to **RustFS** as its S3 storage backend. You will run a registry that stores all layers and manifests in a RustFS bucket, then push and pull an image. The workflow was verified with `registry:2` against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、オープンソースの [Docker Registry](https://github.com/distribution/distribution)（distribution）を、S3 ストレージのバックエンドとして **RustFS** に接続します。すべてのレイヤーとマニフェストを RustFS のバケットに保存するレジストリを実行し、イメージを push および pull します。手順は `registry:2` と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker on the registry host. +レジストリのホストに Docker が必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR Reg -->|"blobs + manifests"| RustFS["RustFS :9000"] ``` -The registry stores every blob (layers and configs) and manifest as objects under `docker/registry/v2/` in the bucket. The container itself is stateless, so registry nodes can be scaled horizontally against the same bucket. +レジストリは、すべての blob（レイヤーと設定）とマニフェストを、バケット内の `docker/registry/v2/` 配下のオブジェクトとして保存します。コンテナ自体はステートレスなので、同じバケットに対してレジストリのノードを水平にスケールできます。 -## 1. Run the registry +## 1. レジストリを実行する -Configure the S3 driver entirely through environment variables. `REGISTRY_STORAGE_S3_REGIONENDPOINT` points the AWS SDK at RustFS: +S3 ドライバーは、環境変数だけで設定します。`REGISTRY_STORAGE_S3_REGIONENDPOINT` は、AWS SDK の接続先を RustFS に向けます。 ```bash docker run -d --name registry --network oo-rustfs_default -p 5000:5000 \ @@ -32,7 +32,7 @@ docker run -d --name registry --network oo-rustfs_default -p 5000:5000 \ registry:2 ``` -Check that the v2 API is up: +v2 API が起動していることを確認します。 ```bash curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5000/v2/ @@ -42,9 +42,9 @@ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5000/v2/ 200 ``` -## 2. Push an image +## 2. イメージを push する -Tag any local image for the registry and push it: +ローカルの任意のイメージにレジストリ用のタグを付け、push します。 ```bash docker pull alpine:3.20 @@ -56,7 +56,7 @@ docker push localhost:5000/rustfs-demo/alpine:3.20 3.20: digest: sha256:c64c687cbea9300178b30c95835354e34c4e4febc4badfe27102879de0483b5e ``` -## 3. Verify objects in RustFS +## 3. RustFS でオブジェクトを確認する ```bash rc ls rustfs/registry-demo/docker/registry/v2/repositories/rustfs-demo/alpine/ -r | head -4 @@ -68,13 +68,13 @@ _repositories/rustfs-demo/alpine/_manifests/revisions/sha256/c64c687c.../link _repositories/rustfs-demo/alpine/_manifests/tags/3.20/current/link ``` -Every `_layers` link points at a blob object stored in the same bucket — the image data itself lives in RustFS, not on the registry host. +各 `_layers` リンクは、同じバケットに保存された blob オブジェクトを指します。イメージデータ自体は RustFS にあり、レジストリのホスト上にはありません。 -![Registry layers stored in the RustFS Console](./images/rustfs-registry-layers.png) +![RustFS Console に保存されたレジストリのレイヤー](./images/rustfs-registry-layers.png) -## 4. Pull the image back +## 4. イメージを pull し直す -Remove the local copy and pull from the registry — the layers come back from RustFS: +ローカルのコピーを削除し、レジストリから pull します。レイヤーは RustFS から戻ってきます。 ```bash docker rmi localhost:5000/rustfs-demo/alpine:3.20 @@ -87,29 +87,29 @@ Digest: sha256:c64c687cbea9300178b30c95835354e34c4e4febc4badfe27102879de0483b5e Status: Downloaded newer image for localhost:5000/rustfs-demo/alpine:3.20 ``` -## 5. Stop or reset +## 5. 停止またはリセットする ```bash docker rm -f registry rc rm rustfs/registry-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Push fails with `unknown` or empty digest +### push が `unknown` または空のダイジェストで失敗する -Confirm `REGISTRY_STORAGE_S3_REGIONENDPOINT` is set — without it the registry sends requests to real AWS. Also check the bucket exists. +`REGISTRY_STORAGE_S3_REGIONENDPOINT` が設定されていることを確認します。未設定だと、レジストリは実際の AWS へリクエストを送ります。バケットが存在することも確認します。 -### `InvalidAccessKeyId` at push time +### push 時の `InvalidAccessKeyId` -The access key and secret key must be passed with `REGISTRY_STORAGE_S3_ACCESSKEY` / `SECRETKEY`; the registry does not read the AWS credential environment chain in this driver. +アクセスキーとシークレットキーは、`REGISTRY_STORAGE_S3_ACCESSKEY` と `SECRETKEY` で渡す必要があります。このドライバーは、AWS 認証情報の環境変数チェーンを読みません。 -### Pull returns `manifest unknown` after the registry restarted +### レジストリ再起動後の pull が `manifest unknown` を返す -Manifests and blobs live in the bucket, so a restart cannot lose them — check that both registry instances point at the same `REGISTRY_STORAGE_S3_BUCKET` and `REGIONENDPOINT`. +マニフェストと blob はバケットにあるため、再起動で失われることはありません。両方のレジストリインスタンスが、同じ `REGISTRY_STORAGE_S3_BUCKET` と `REGIONENDPOINT` を指していることを確認します。 -## Next steps +## 次のステップ -- Compare with the [Harbor](/developer/integration/registry/harbor) guide when you need a UI, RBAC, or replication on top of the same bucket. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [distribution documentation](https://distribution.github.io/distribution/) for storage driver tuning and proxy-caching setups. +- UI、RBAC、または同じバケット上のレプリケーションが必要な場合は、[Harbor](/ja/developer/integration/registry/harbor) のガイドと比較します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- ストレージドライバーの調整とプロキシキャッシュの構成については、[distribution のドキュメント](https://distribution.github.io/distribution/)に従います。 diff --git a/content/ja/developer/integration/registry/harbor.md b/content/ja/developer/integration/registry/harbor.md index 6b77f4511..ff4d27b73 100644 --- a/content/ja/developer/integration/registry/harbor.md +++ b/content/ja/developer/integration/registry/harbor.md @@ -274,6 +274,6 @@ docker compose logs create-bucket ## 次のステップ -- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/administration/protocols/s3)を確認してください。 -- [アクセスキー管理](/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 +- 追加の S3 オペレーションを採用する前に、[S3 互換性ノート](/ja/administration/protocols/s3)を確認してください。 +- [アクセスキー管理](/ja/security-compliance/iam/access-token)で本番用の専用認証情報を作成してください。 - [Harbor ドキュメント](https://goharbor.io/docs/)に従って、レプリケーション・脆弱性スキャン・RBAC を備えた完全な Harbor デプロイを構成してください。 diff --git a/content/ja/developer/integration/reverse-proxy/caddy.md b/content/ja/developer/integration/reverse-proxy/caddy.md index a49b24dae..8f92ebfb4 100644 --- a/content/ja/developer/integration/reverse-proxy/caddy.md +++ b/content/ja/developer/integration/reverse-proxy/caddy.md @@ -1,35 +1,35 @@ --- title: "Caddy" -description: "Deploy RustFS behind Caddy with automatic HTTPS for separate S3 API and Console hostnames." +description: "S3 API と Console を別々のホスト名で公開し、HTTPS を自動取得する Caddy の背後に RustFS をデプロイします。" --- -Use **Caddy** to obtain and renew TLS certificates automatically and route separate hostnames to the RustFS S3 API and Console. This deployment runs Caddy and a single-node RustFS instance with Docker Compose. You need Docker Engine, Docker Compose, a public server, and two DNS records that resolve to that server. +**Caddy** で TLS 証明書の取得と更新を自動化し、別々のホスト名を RustFS の S3 API と Console へ振り分けます。このデプロイでは、Docker Compose で Caddy とシングルノードの RustFS を動かします。Docker Engine、Docker Compose、公開サーバー、およびそのサーバーへ解決する DNS レコードが 2 件必要です。 -This guide uses these example hostnames: +このガイドでは、次のホスト名を例に使います。 -- `s3.example.com` for the S3 API -- `console.example.com` for the Console +- S3 API 用の `s3.example.com` +- Console 用の `console.example.com` -Replace them with your public hostnames. Caddy's default ACME challenges require inbound access to ports `80` and `443`. +公開するホスト名に置き換えます。Caddy の既定の ACME チャレンジでは、ポート `80` と `443` への着信アクセスが必要です。 -:::warning[Serve S3 from the root path] +:::warning[S3 はルートパスから公開する] -Do not publish the S3 API under a path such as `/s3/`. AWS Signature Version 4 includes the request path and host, so rewriting either value can invalidate signed requests. +`/s3/` のようなパスの下に S3 API を公開しないでください。AWS Signature Version 4 はリクエストパスとホストを署名対象に含めるため、どちらかを書き換えると署名済みリクエストが無効になることがあります。 ::: -## 1. Create the deployment directory +## 1. デプロイ用ディレクトリを作成する -Create a directory for the deployment: +デプロイ用のディレクトリを作成します。 ```bash mkdir rustfs-caddy cd rustfs-caddy ``` -## 2. Set deployment variables +## 2. デプロイ変数を設定する -Create an environment file and replace each value: +環境ファイルを作成し、各値を置き換えます。 ```ini title=".env" S3_HOSTNAME=s3.example.com @@ -39,11 +39,11 @@ RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use an email address that receives certificate notices. Do not commit `.env` to source control. +証明書の通知を受け取るメールアドレスを使います。`.env` はソース管理にコミットしないでください。 -## 3. Configure Caddy +## 3. Caddy を設定する -Create a Caddyfile with one site block for each RustFS endpoint: +RustFS のエンドポイントごとに、サイトブロックを 1 つ持つ Caddyfile を作成します。 ```text title="Caddyfile" { @@ -73,11 +73,11 @@ Create a Caddyfile with one site block for each RustFS endpoint: } ``` -Caddy preserves the incoming `Host` header, HTTP method, and request URI by default. It also forwards client information through `X-Forwarded-*` headers and handles Console WebSocket upgrades without additional header rules. +Caddy は既定で、受信した `Host` ヘッダー、HTTP メソッド、リクエスト URI をそのまま保持します。クライアント情報は `X-Forwarded-*` ヘッダーで転送し、追加のヘッダー規則なしで Console の WebSocket アップグレードも処理します。 -## 4. Create the Compose file +## 4. Compose ファイルを作成する -Create the Caddy and RustFS services: +Caddy と RustFS のサービスを作成します。 ```yaml title="compose.yaml" services: @@ -136,24 +136,24 @@ networks: rustfs: ``` -The persistent `caddy-data` volume stores certificates, private keys, and ACME account state. Back up this volume and do not share its contents. Only Caddy publishes host ports; RustFS remains reachable inside the Compose network. +永続ボリューム `caddy-data` には、証明書、秘密鍵、ACME アカウントの状態が保存されます。このボリュームはバックアップし、内容は共有しないでください。ホストのポートを公開するのは Caddy だけで、RustFS には Compose ネットワークの内部からのみ到達できます。 -## 5. Validate and start the deployment +## 5. デプロイを検証して起動する -Render the Compose configuration and start RustFS: +Compose の設定を展開し、RustFS を起動します。 ```bash docker compose config docker compose up -d rustfs ``` -Validate the Caddyfile with the same image used by the deployment: +デプロイと同じイメージで Caddyfile を検証します。 ```bash docker compose run --rm --no-deps caddy caddy validate --config /etc/caddy/Caddyfile ``` -Start Caddy and check both services: +Caddy を起動し、両方のサービスを確認します。 ```bash docker compose up -d caddy @@ -161,22 +161,22 @@ docker compose ps docker compose logs --follow caddy ``` -Caddy obtains certificates in the background and redirects HTTP requests to HTTPS. If issuance fails, confirm that both DNS records resolve to this host, ports `80` and `443` are reachable, and the `caddy-data` volume is writable. +Caddy はバックグラウンドで証明書を取得し、HTTP リクエストを HTTPS へリダイレクトします。発行に失敗した場合は、両方の DNS レコードがこのホストへ解決すること、ポート `80` と `443` へ到達できること、`caddy-data` ボリュームへ書き込めることを確認します。 -## 6. Verify both endpoints +## 6. 両方のエンドポイントを確認する -Verify the API and Console through their public HTTPS hostnames: +公開 HTTPS ホスト名経由で API と Console を確認します。 ```bash curl --fail https://s3.example.com/health/ready curl --fail https://console.example.com/rustfs/console/health ``` -Configure S3 clients with `https://s3.example.com` as the endpoint and enable path-style addressing. Open `https://console.example.com/rustfs/console/` to sign in to the Console. +S3 クライアントのエンドポイントを `https://s3.example.com` に設定し、パススタイルアクセスを有効にします。`https://console.example.com/rustfs/console/` を開いて Console にサインインします。 -## Multi-node upstreams +## マルチノードのアップストリーム -For a distributed RustFS deployment, list every node in the corresponding site block: +分散構成の RustFS デプロイでは、対応するサイトブロックにすべてのノードを列挙します。 ```text title="Caddyfile" {$S3_HOSTNAME} { @@ -200,10 +200,10 @@ For a distributed RustFS deployment, list every node in the corresponding site b } ``` -Replace `` with a random secret shared by all Caddy instances. Console affinity keeps an in-progress OpenID Connect login on the RustFS node that created its `state`. Keep port `9000` open directly between RustFS nodes because internal node RPC uses the same listener. +`` は、すべての Caddy インスタンスで共有するランダムなシークレットに置き換えます。Console のアフィニティにより、進行中の OpenID Connect ログインは、その `state` を作成した RustFS ノードに留まります。ノード間の内部 RPC は同じリスナーを使うため、RustFS ノード間ではポート `9000` を直接開けたままにします。 -## Next steps +## 次のステップ -- [Configure an S3 client](/developer/examples/aws-cli) -- [Enable virtual-hosted-style bucket URLs](/integration/virtual) -- [Review health and readiness endpoints](/operations/status-check) \ No newline at end of file +- [S3 クライアントを設定する](/ja/developer/examples/aws-cli) +- [仮想ホスト形式のバケット URL を有効にする](/ja/integration/virtual) +- [ヘルスと準備完了のエンドポイントを確認する](/ja/operations/status-check) diff --git a/content/ja/developer/integration/reverse-proxy/envoy.md b/content/ja/developer/integration/reverse-proxy/envoy.md index dc635a48d..0c18abdfd 100644 --- a/content/ja/developer/integration/reverse-proxy/envoy.md +++ b/content/ja/developer/integration/reverse-proxy/envoy.md @@ -1,33 +1,33 @@ --- title: "Envoy" -description: "Deploy RustFS behind Envoy with TLS-terminated routes for the S3 API and Console." +description: "S3 API と Console 向けに TLS を終端するルートを備え、Envoy の背後に RustFS をデプロイします。" --- -Use **Envoy** to terminate TLS and route separate hostnames to the RustFS S3 API and Console. This deployment runs Envoy and a single-node RustFS instance on one Docker network. You need Docker Engine, two DNS records, and a TLS certificate that covers both hostnames (the guide uses a self-signed certificate for testing). +**Envoy** で TLS を終端し、別々のホスト名を RustFS の S3 API と Console へ振り分けます。このデプロイでは、同一の Docker ネットワーク上で Envoy とシングルノードの RustFS を動かします。Docker Engine、DNS レコード 2 件、および両方のホスト名をカバーする TLS 証明書が必要です（このガイドでは検証用に自己署名証明書を使います）。 -This guide uses these example hostnames: +このガイドでは、次のホスト名を例に使います。 -- `s3.example.com` for the S3 API -- `console.example.com` for the Console +- S3 API 用の `s3.example.com` +- Console 用の `console.example.com` -Replace them with hostnames that resolve to the Docker host. +Docker ホストへ解決するホスト名に置き換えます。 -:::warning[Serve S3 from the root path] +:::warning[S3 はルートパスから公開する] -Do not publish the S3 API under a path such as `/s3/`. AWS Signature Version 4 includes the request path and host, so rewriting either value can invalidate signed requests. Envoy forwards the incoming `Host` header unchanged, which keeps signatures valid. +`/s3/` のようなパスの下に S3 API を公開しないでください。AWS Signature Version 4 はリクエストパスとホストを署名対象に含めるため、どちらかを書き換えると署名済みリクエストが無効になることがあります。Envoy は受信した `Host` ヘッダーを変更せずに転送するため、署名は有効なままです。 ::: -## 1. Create the deployment directories +## 1. デプロイ用ディレクトリを作成する -Create directories for the Envoy configuration and TLS certificate: +Envoy の設定と TLS 証明書用のディレクトリを作成します。 ```bash mkdir -p rustfs-envoy/certs cd rustfs-envoy ``` -For local testing, generate a self-signed certificate covering both hostnames: +ローカル検証では、両方のホスト名をカバーする自己署名証明書を生成します。 ```bash openssl req -x509 -newkey rsa:2048 -nodes \ @@ -37,11 +37,11 @@ openssl req -x509 -newkey rsa:2048 -nodes \ chmod 644 certs/privkey.pem ``` -Make the certificate readable by the non-root user the Envoy image runs as — a `600` private key produces a misleading `Failed to load incomplete private key` error. +Envoy イメージが実行される root 以外のユーザーから、証明書を読めるようにします。`600` の秘密鍵は、誤解を招く `Failed to load incomplete private key` エラーになります。 -## 2. Configure Envoy +## 2. Envoy を設定する -Create the configuration with an HTTPS listener and two virtual hosts. Route timeouts are disabled (`timeout: 0s`) so long streaming S3 uploads are not cut off: +HTTPS リスナーと 2 つの仮想ホストを含む設定を作成します。長時間のストリーミング S3 アップロードが途中で切れないよう、ルートのタイムアウトは無効（`timeout: 0s`）にしています。 ```yaml title="envoy.yaml" static_resources: @@ -99,11 +99,11 @@ static_resources: - endpoint: {address: {socket_address: {address: rustfs, port_value: 9001}}} ``` -The `host:*` domain entries matter: clients send `Host: s3.example.com:8443` on non-standard ports, and Envoy matches the authority including the port. +`host:*` のドメイン指定は重要です。標準外のポートではクライアントが `Host: s3.example.com:8443` を送り、Envoy はポートを含めた authority で照合します。 -## 3. Start Envoy +## 3. Envoy を起動する -Run Envoy on the same Docker network as RustFS, publishing only the proxy port: +RustFS と同じ Docker ネットワークで Envoy を実行し、公開するのはプロキシのポートだけにします。 ```bash docker run -d --name envoy --network oo-rustfs_default -p 8443:8443 \ @@ -112,9 +112,9 @@ docker run -d --name envoy --network oo-rustfs_default -p 8443:8443 \ envoyproxy/envoy:v1.34-latest -c /envoy.yaml ``` -## 4. Verify both endpoints +## 4. 両方のエンドポイントを確認する -Point the example hostnames at the proxy with `curl --resolve` (in production, DNS does this): +`curl --resolve` で例示ホスト名をプロキシへ向けます（本番では DNS がこれを行います）。 ```bash curl -sk --resolve s3.example.com:8443:127.0.0.1 \ @@ -129,11 +129,11 @@ s3 api: 200 console: 200 ``` -`-k` skips certificate validation because the certificate is self-signed; with a trusted certificate, drop it. +証明書が自己署名のため、`-k` は証明書の検証を省略します。信頼された証明書を使う場合は、このフラグを外します。 -## 5. Send signed S3 requests through Envoy +## 5. 署名済みの S3 リクエストを Envoy 経由で送る -Point any S3 client at the proxy as if it were RustFS. Configure the client with `https://s3.example.com:8443` as the endpoint and path-style addressing; when the proxy certificate is trusted, signed AWS Signature Version 4 requests pass through unchanged. For a quick test over plain HTTP, add an HTTP listener on port 8080 with the same virtual-host routing as the HTTPS listener, then use the endpoint `http://s3.example.com:8080`: +任意の S3 クライアントを、RustFS そのものと同様にプロキシへ向けます。エンドポイントを `https://s3.example.com:8443` にし、パススタイルアクセスを設定します。プロキシの証明書が信頼されていれば、署名済みの AWS Signature Version 4 リクエストはそのまま通過します。平文 HTTP で手早く試す場合は、HTTPS リスナーと同じ仮想ホストのルーティングを持つ HTTP リスナーをポート 8080 に追加し、エンドポイント `http://s3.example.com:8080` を使います。 ```bash rc alias set rustfs-envoy http://s3.example.com:8080 @@ -145,11 +145,11 @@ rc ls rustfs-envoy/rclone-demo/ [2026-09-29 11:12:41] 5 B write-test.txt ``` -The signatures validate because Envoy forwards the original `Host` header to RustFS. +Envoy が元の `Host` ヘッダーを RustFS へ転送するため、署名は検証に通ります。 -## Multi-node backends +## マルチノードのバックエンド -For a distributed RustFS deployment, add every node to the S3 cluster: +分散構成の RustFS デプロイでは、S3 用クラスターにすべてのノードを追加します。 ```yaml title="envoy.yaml" - name: rustfs_s3 @@ -169,24 +169,24 @@ For a distributed RustFS deployment, add every node to the S3 cluster: - endpoint: {address: {socket_address: {address: node4, port_value: 9000}}} ``` -The Console cluster follows the same pattern on port `9001`. +Console 用クラスターも、ポート `9001` で同じ形にします。 -## Troubleshooting +## トラブルシューティング ### `Failed to load incomplete private key from path` -The Envoy container runs as a non-root user and cannot read a `600` root-owned key. `chmod 644` the key files (or chown them to the container user, UID `1001` in the official image). +Envoy コンテナは root 以外のユーザーで動作し、root 所有かつ `600` の鍵を読めません。鍵ファイルに `chmod 644` を行うか、コンテナユーザー（公式イメージでは UID `1001`）へ chown します。 -### Routes return `404` with the correct hostnames +### 正しいホスト名でもルートが `404` を返す -Envoy matches the authority including the port. Add the `host:*` variants to each virtual host's `domains` list, as in the configuration above. +Envoy はポートを含めた authority で照合します。上の設定のとおり、各仮想ホストの `domains` リストに `host:*` のバリエーションを追加します。 -### `Access Denied` from RustFS on proxied requests +### プロキシしたリクエストで RustFS が `Access Denied` を返す -Confirm the proxy is not rewriting the path or the `Host` header. Signed requests must reach RustFS with the host the client signed for. +プロキシがパスまたは `Host` ヘッダーを書き換えていないことを確認します。署名済みリクエストは、クライアントが署名したホストのまま RustFS に届く必要があります。 -## Next steps +## 次のステップ -- [Configure an S3 client](/developer/examples/aws-cli) -- [Enable virtual-hosted-style bucket URLs](/integration/virtual) -- [Review health and readiness endpoints](/operations/status-check) +- [S3 クライアントを設定する](/ja/developer/examples/aws-cli) +- [仮想ホスト形式のバケット URL を有効にする](/ja/integration/virtual) +- [ヘルスと準備完了のエンドポイントを確認する](/ja/operations/status-check) diff --git a/content/ja/developer/integration/reverse-proxy/haproxy.md b/content/ja/developer/integration/reverse-proxy/haproxy.md index 87bf2a760..b261eba18 100644 --- a/content/ja/developer/integration/reverse-proxy/haproxy.md +++ b/content/ja/developer/integration/reverse-proxy/haproxy.md @@ -1,55 +1,55 @@ --- title: "HAProxy" -description: "Deploy RustFS behind HAProxy with separate HTTPS routes for the S3 API and Console." +description: "S3 API と Console を別々の HTTPS ルートで公開する HAProxy の背後に RustFS をデプロイします。" --- -Use **HAProxy** to terminate TLS and route separate hostnames to the RustFS S3 API and Console. This deployment runs HAProxy and a single-node RustFS instance with Docker Compose. You need Docker Engine, Docker Compose, two DNS records, and a TLS certificate that covers both hostnames. +**HAProxy** で TLS を終端し、別々のホスト名を RustFS の S3 API と Console へ振り分けます。このデプロイでは、Docker Compose で HAProxy とシングルノードの RustFS を動かします。Docker Engine、Docker Compose、DNS レコード 2 件、および両方のホスト名をカバーする TLS 証明書が必要です。 -This guide uses these example hostnames: +このガイドでは、次のホスト名を例に使います。 -- `s3.example.com` for the S3 API -- `console.example.com` for the Console +- S3 API 用の `s3.example.com` +- Console 用の `console.example.com` -Replace them with hostnames that resolve to the Docker host. +Docker ホストへ解決するホスト名に置き換えます。 -:::warning[Serve S3 from the root path] +:::warning[S3 はルートパスから公開する] -Do not publish the S3 API under a path such as `/s3/`. AWS Signature Version 4 includes the request path and host, so rewriting either value can invalidate signed requests. +`/s3/` のようなパスの下に S3 API を公開しないでください。AWS Signature Version 4 はリクエストパスとホストを署名対象に含めるため、どちらかを書き換えると署名済みリクエストが無効になることがあります。 ::: -## 1. Create the deployment directories +## 1. デプロイ用ディレクトリを作成する -Create directories for the HAProxy configuration and TLS certificate: +HAProxy の設定と TLS 証明書用のディレクトリを作成します。 ```bash mkdir -p rustfs-haproxy/config rustfs-haproxy/certs cd rustfs-haproxy ``` -HAProxy expects the certificate chain and private key in one PEM file. Combine them in this order: +HAProxy は、証明書チェーンと秘密鍵が 1 つの PEM ファイルにまとまっていることを前提にします。次の順で結合します。 ```bash cat fullchain.pem privkey.pem > certs/rustfs.pem chmod 600 certs/rustfs.pem ``` -The certificate must cover both public hostnames. +証明書は、公開する両方のホスト名をカバーする必要があります。 -## 2. Set RustFS credentials +## 2. RustFS の認証情報を設定する -Create an environment file and replace both credential placeholders: +環境ファイルを作成し、認証情報のプレースホルダーを両方とも置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Do not commit this file or the certificate private key to source control. +このファイルと証明書の秘密鍵は、ソース管理にコミットしないでください。 -## 3. Configure HAProxy +## 3. HAProxy を設定する -Create the HAProxy configuration: +HAProxy の設定を作成します。 ```text title="config/haproxy.cfg" global @@ -96,13 +96,13 @@ backend rustfs_console server rustfs rustfs:9001 check inter 10s fall 3 rise 2 cookie rustfs ``` -HAProxy preserves the incoming host and request path unless you explicitly rewrite them. The long client, server, and tunnel timeouts accommodate streaming S3 operations and Console WebSocket connections. +明示的に書き換えない限り、HAProxy は受信したホストとリクエストパスを保持します。クライアント、サーバー、トンネルのタイムアウトを長くしてあるのは、ストリーミングの S3 操作と Console の WebSocket 接続に合わせるためです。 -The Console backend sets an affinity cookie. With one RustFS server it has no routing effect, but keeping it in the base configuration makes the behavior consistent when you add nodes. +Console のバックエンドにはアフィニティ用の Cookie を設定します。RustFS サーバーが 1 台のときはルーティングへの影響はありませんが、基本設定に含めておくと、ノードを追加したときの動作が揃います。 -## 4. Create the Compose file +## 4. Compose ファイルを作成する -Create the HAProxy and RustFS services: +HAProxy と RustFS のサービスを作成します。 ```yaml title="compose.yaml" services: @@ -153,58 +153,58 @@ networks: rustfs: ``` -Only HAProxy publishes host ports. RustFS ports `9000` and `9001` remain reachable inside the Compose network. +ホストのポートを公開するのは HAProxy だけです。RustFS のポート `9000` と `9001` には、Compose ネットワークの内部からのみ到達できます。 -## 5. Validate and start the deployment +## 5. デプロイを検証して起動する -Render the Compose configuration and start RustFS: +Compose の設定を展開し、RustFS を起動します。 ```bash docker compose config docker compose up -d rustfs ``` -Validate the HAProxy configuration with the same image used by the deployment: +デプロイと同じイメージで HAProxy の設定を検証します。 ```bash docker compose run --rm --no-deps haproxy haproxy -c -f /usr/local/etc/haproxy/haproxy.cfg ``` -Start HAProxy and check both services: +HAProxy を起動し、両方のサービスを確認します。 ```bash docker compose up -d haproxy docker compose ps ``` -If a service does not become healthy, inspect its logs: +サービスが正常にならない場合は、ログを確認します。 ```bash docker compose logs haproxy docker compose logs rustfs ``` -## 6. Verify both endpoints +## 6. 両方のエンドポイントを確認する -Verify the API and Console through their public HTTPS hostnames: +公開 HTTPS ホスト名経由で API と Console を確認します。 ```bash curl --fail https://s3.example.com/health/ready curl --fail https://console.example.com/rustfs/console/health ``` -Configure S3 clients with `https://s3.example.com` as the endpoint and enable path-style addressing. Open `https://console.example.com/rustfs/console/` to sign in to the Console. +S3 クライアントのエンドポイントを `https://s3.example.com` に設定し、パススタイルアクセスを有効にします。`https://console.example.com/rustfs/console/` を開いて Console にサインインします。 -When you replace a renewed `certs/rustfs.pem`, validate the configuration and recreate the HAProxy container to load it: +更新した `certs/rustfs.pem` に差し替えたら、設定を検証し、HAProxy コンテナを再作成して読み込みます。 ```bash docker compose run --rm --no-deps haproxy haproxy -c -f /usr/local/etc/haproxy/haproxy.cfg docker compose up -d --force-recreate haproxy ``` -## Multi-node backends +## マルチノードのバックエンド -For a distributed RustFS deployment, add every RustFS node to both backends: +分散構成の RustFS デプロイでは、両方のバックエンドにすべての RustFS ノードを追加します。 ```text title="config/haproxy.cfg" backend rustfs_s3 @@ -227,10 +227,10 @@ backend rustfs_console server node4 node4.example.net:9001 check inter 10s fall 3 rise 2 cookie node4 ``` -The Console cookie keeps an in-progress OpenID Connect login on the RustFS node that created its `state`. Keep port `9000` open directly between RustFS nodes because internal node RPC uses the same listener. +Console の Cookie により、進行中の OpenID Connect ログインは、その `state` を作成した RustFS ノードに留まります。ノード間の内部 RPC は同じリスナーを使うため、RustFS ノード間ではポート `9000` を直接開けたままにします。 -## Next steps +## 次のステップ -- [Configure an S3 client](/developer/examples/aws-cli) -- [Enable virtual-hosted-style bucket URLs](/integration/virtual) -- [Review health and readiness endpoints](/operations/status-check) \ No newline at end of file +- [S3 クライアントを設定する](/ja/developer/examples/aws-cli) +- [仮想ホスト形式のバケット URL を有効にする](/ja/integration/virtual) +- [ヘルスと準備完了のエンドポイントを確認する](/ja/operations/status-check) diff --git a/content/ja/developer/integration/reverse-proxy/httpd.md b/content/ja/developer/integration/reverse-proxy/httpd.md index d98ce20de..8588f7767 100644 --- a/content/ja/developer/integration/reverse-proxy/httpd.md +++ b/content/ja/developer/integration/reverse-proxy/httpd.md @@ -1,33 +1,33 @@ --- title: "Apache HTTP Server" -description: "Deploy RustFS behind Apache HTTP Server with TLS termination for separate S3 API and Console hostnames." +description: "S3 API と Console を別々のホスト名で公開し、TLS を終端する Apache HTTP Server の背後に RustFS をデプロイします。" --- -Use **Apache HTTP Server** (httpd) to terminate TLS and route separate hostnames to the RustFS S3 API and Console. This deployment runs httpd and a single-node RustFS instance with Docker Compose. You need Docker Engine, Docker Compose, two DNS records, and a TLS certificate that covers both hostnames. +**Apache HTTP Server**（httpd）で TLS を終端し、別々のホスト名を RustFS の S3 API と Console へ振り分けます。このデプロイでは、Docker Compose で httpd とシングルノードの RustFS を動かします。Docker Engine、Docker Compose、DNS レコード 2 件、および両方のホスト名をカバーする TLS 証明書が必要です。 -This guide uses these example hostnames: +このガイドでは、次のホスト名を例に使います。 -- `s3.example.com` for the S3 API -- `console.example.com` for the Console +- S3 API 用の `s3.example.com` +- Console 用の `console.example.com` -Replace them with hostnames that resolve to the Docker host. +Docker ホストへ解決するホスト名に置き換えます。 -:::warning[Serve S3 from the root path] +:::warning[S3 はルートパスから公開する] -Do not publish the S3 API under a path such as `/s3/`. AWS Signature Version 4 includes the request path and host, so rewriting either value can invalidate signed requests. Apache rewrites proxied URLs unless you disable canonicalization, which this configuration does with `nocanon`. +`/s3/` のようなパスの下に S3 API を公開しないでください。AWS Signature Version 4 はリクエストパスとホストを署名対象に含めるため、どちらかを書き換えると署名済みリクエストが無効になることがあります。Apache は正規化を無効にしない限り、プロキシする URL を書き換えます。この構成では `nocanon` で正規化を無効にしています。 ::: -## 1. Create the deployment directories +## 1. デプロイ用ディレクトリを作成する -Create directories for the httpd configuration and TLS certificate: +httpd の設定と TLS 証明書用のディレクトリを作成します。 ```bash mkdir -p rustfs-httpd/config rustfs-httpd/certs cd rustfs-httpd ``` -Copy your certificate chain and private key into `certs/`: +証明書チェーンと秘密鍵を `certs/` へコピーします。 ```text rustfs-httpd/ @@ -37,28 +37,28 @@ rustfs-httpd/ └── config/ ``` -Restrict access to the private key: +秘密鍵へのアクセスを制限します。 ```bash chmod 600 certs/privkey.pem ``` -The certificate must cover both public hostnames. +証明書は、公開する両方のホスト名をカバーする必要があります。 -## 2. Set RustFS credentials +## 2. RustFS の認証情報を設定する -Create an environment file and replace both credential placeholders: +環境ファイルを作成し、認証情報のプレースホルダーを両方とも置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Do not commit this file to source control. +このファイルはソース管理にコミットしないでください。 -## 3. Build the httpd image +## 3. httpd イメージをビルドする -The stock `httpd` image ships with its proxy and TLS modules commented out. Build a small image that enables them and loads the RustFS virtual hosts: +標準の `httpd` イメージでは、プロキシと TLS のモジュールがコメントアウトされた状態で配布されています。これらを有効にし、RustFS の仮想ホストを読み込む小さなイメージをビルドします。 ```dockerfile title="Dockerfile" FROM httpd:2.4-alpine @@ -79,11 +79,11 @@ RUN sed -i \ && printf '\nInclude conf/rustfs.conf\n' >> /usr/local/apache2/conf/httpd.conf ``` -`proxy_balancer`, `slotmem_shm`, and `lbmethod_byrequests` are only used by the [multi-node](#multi-node-backends) configuration. Loading them on single-node deployments is harmless. +`proxy_balancer`、`slotmem_shm`、`lbmethod_byrequests` を使うのは、[マルチノード](#multi-node-backends)の設定だけです。シングルノードのデプロイで読み込んでも害はありません。 -## 4. Configure Apache HTTP Server +## 4. Apache HTTP Server を設定する -Create the httpd configuration with one virtual host per RustFS endpoint: +RustFS のエンドポイントごとに、仮想ホストを 1 つ持つ httpd の設定を作成します。 ```apache title="config/rustfs.conf" # Global settings shared by the RustFS virtual hosts. @@ -161,11 +161,11 @@ LimitRequestBody 0 ``` -`Listen 443` is required because the stock `httpd.conf` only opens port `80`; virtual hosts alone do not open ports. The two `VirtualHost *:80` blocks redirect all plain-HTTP traffic to HTTPS with explicit target hostnames. +標準の `httpd.conf` が開くのはポート `80` だけであり、仮想ホストだけではポートは開かないため、`Listen 443` が必要です。2 つの `VirtualHost *:80` ブロックは、平文 HTTP のトラフィックを、対象ホスト名を明示して HTTPS へリダイレクトします。 -## 5. Create the Compose file +## 5. Compose ファイルを作成する -Create the httpd and RustFS services: +httpd と RustFS のサービスを作成します。 ```yaml title="compose.yaml" services: @@ -216,126 +216,126 @@ networks: rustfs: ``` -Only httpd publishes host ports. RustFS ports `9000` and `9001` remain reachable inside the Compose network. +ホストのポートを公開するのは httpd だけです。RustFS のポート `9000` と `9001` には、Compose ネットワークの内部からのみ到達できます。 -:::note[RustFS log directory] +:::note[RustFS のログディレクトリ] -`RUSTFS_OBS_LOG_DIRECTORY` must point to a directory the container can create. The RustFS image runs as a non-root user, so `/logs` works while paths under `/var/log` make the container exit at startup with `Permission denied`. +`RUSTFS_OBS_LOG_DIRECTORY` は、コンテナが作成できるディレクトリを指す必要があります。RustFS イメージは root 以外のユーザーで動作するため、`/logs` は使えますが、`/var/log` 配下のパスでは起動時に `Permission denied` でコンテナが終了します。 ::: -## 6. Validate and start the deployment +## 6. デプロイを検証して起動する -Render the Compose configuration and start RustFS: +Compose の設定を展開し、RustFS を起動します。 ```bash docker compose config docker compose up -d rustfs ``` -Validate the httpd configuration with the same image used by the deployment: +デプロイと同じイメージで httpd の設定を検証します。 ```bash docker compose run --rm --no-deps httpd httpd -t ``` -Start httpd and check both services: +httpd を起動し、両方のサービスを確認します。 ```bash docker compose up -d httpd docker compose ps ``` -If a service does not become healthy, inspect its logs: +サービスが正常にならない場合は、ログを確認します。 ```bash docker compose logs httpd docker compose logs rustfs ``` -## 7. Verify both endpoints +## 7. 両方のエンドポイントを確認する -Verify the API and Console through their public HTTPS hostnames: +公開 HTTPS ホスト名経由で API と Console を確認します。 ```bash curl --fail https://s3.example.com/health/ready curl --fail https://console.example.com/rustfs/console/health ``` -Configure S3 clients with `https://s3.example.com` as the endpoint and enable path-style addressing. Open `https://console.example.com/rustfs/console/` to sign in to the Console. +S3 クライアントのエンドポイントを `https://s3.example.com` に設定し、パススタイルアクセスを有効にします。`https://console.example.com/rustfs/console/` を開いて Console にサインインします。 -:::note[Console root path] +:::note[Console のルートパス] -In RustFS v2.x the Console is served under the `/rustfs/console/` path prefix. Requesting the root path of the Console hostname returns an S3-style XML access-denied response, which is expected. +RustFS v2.x では、Console はパスプレフィックス `/rustfs/console/` の下で提供されます。Console ホスト名のルートパスをリクエストすると、S3 形式の XML によるアクセス拒否応答が返ります。これは想定どおりの動作です。 ::: -When you replace a renewed certificate or key in `certs/`, validate the configuration and reload httpd gracefully without dropping active transfers: +`certs/` の証明書または鍵を更新したものに差し替えたら、設定を検証し、進行中の転送を切らずに httpd をグレースフルに再読み込みします。 ```bash docker compose exec httpd httpd -t docker compose exec httpd httpd -k graceful ``` -## How this configuration preserves S3 signatures +## この設定が S3 署名を保持する仕組み -AWS Signature Version 4 signs the HTTP method, the `Host` header, and the raw request path. Every directive below keeps one of those values byte-identical between the client and RustFS: +AWS Signature Version 4 は、HTTP メソッド、`Host` ヘッダー、生のリクエストパスに署名します。以下の各ディレクティブは、これらの値のいずれかを、クライアントから RustFS まで 1 バイトも変えずに保ちます。 -- **`ProxyPreserveHost On`** keeps the client's `Host` header. With the default (`Off`), Apache rewrites `Host` to the backend host and RustFS answers `SignatureDoesNotMatch`. -- **`nocanon`** on the `ProxyPass` line passes the request path to RustFS without URL canonicalization. Without it, Apache rewrites paths during forwarding (for example collapsing `//`), and any signed path no longer matches. -- **`AllowEncodedSlashes NoDecode`** lets object keys containing `%2F` reach the proxy handlers instead of returning `404`, and keeps the encoding intact. -- **`RequestHeader set X-Forwarded-Proto "https"`** tells RustFS the original scheme. Apache's `ProxyAddHeaders` (default `On`) adds `X-Forwarded-For`, `X-Forwarded-Host`, and `X-Forwarded-Server`, but not `X-Forwarded-Proto`. +- **`ProxyPreserveHost On`** は、クライアントの `Host` ヘッダーを保持します。既定（`Off`）では Apache が `Host` をバックエンドのホストへ書き換えるため、RustFS は `SignatureDoesNotMatch` を返します。 +- `ProxyPass` 行の **`nocanon`** は、URL を正規化せずにリクエストパスを RustFS へ渡します。これがないと、Apache は転送中にパスを書き換えます（たとえば `//` を折りたたみます）。その結果、署名済みのパスが一致しなくなります。 +- **`AllowEncodedSlashes NoDecode`** は、`%2F` を含むオブジェクトキーが `404` にならずプロキシハンドラーへ届くようにし、エンコーディングもそのまま保ちます。 +- **`RequestHeader set X-Forwarded-Proto "https"`** は、元のスキームを RustFS に伝えます。Apache の `ProxyAddHeaders`（既定は `On`）が追加するのは `X-Forwarded-For`、`X-Forwarded-Host`、`X-Forwarded-Server` であり、`X-Forwarded-Proto` は含まれません。 -Presigned URLs, multipart uploads, and browser POST uploads rely on the same path and host preservation and need no extra directives. +署名付き URL、マルチパートアップロード、ブラウザーからの POST アップロードは、同じパスとホストの保持に依存するため、追加のディレクティブは不要です。 -The Console virtual host adds `upgrade=websocket` to its `ProxyPass` line so that WebSocket upgrades are tunneled end to end. Since 2.4.47, `mod_proxy_http` handles the upgrade itself and only tunnels connections the backend accepts with `101 Switching Protocols`; the older `mod_proxy_wstunnel` module is deprecated. +Console の仮想ホストは、`ProxyPass` 行に `upgrade=websocket` を付け、WebSocket のアップグレードをエンドツーエンドでトンネルします。2.4.47 以降、`mod_proxy_http` 自身がアップグレードを処理し、バックエンドが `101 Switching Protocols` で受け付けた接続だけをトンネルします。古い `mod_proxy_wstunnel` モジュールは非推奨です。 -## Request bodies, large objects, and timeouts +## リクエストボディ、大きなオブジェクト、タイムアウト -Apache forwards request bodies to RustFS without a size limit and without writing them to the proxy's disk. Bodies that arrive with a `Content-Length` (what AWS CLI, AWS SDKs, and `mc` send) stream through as they arrive. Bodies that arrive with `Transfer-Encoding: chunked` are also forwarded as chunked encoding, which RustFS rejects — see the warnings below. +Apache は、サイズ制限を設けず、プロキシのディスクへ書き出さずに、リクエストボディを RustFS へ転送します。`Content-Length` 付きで届くボディ（AWS CLI、AWS SDK、`mc` が送る形式）は、到着したままストリーム転送されます。`Transfer-Encoding: chunked` で届くボディもチャンク転送のまま転送されますが、RustFS はこれを拒否します。下記の警告を参照してください。 -The timeout directives trade safety for long transfers: +タイムアウトのディレクティブは、安全性を下げて長時間の転送を通します。 -- **`Timeout 600`** covers connection I/O in both directions, so slow downloads and uploads are not cut mid-transfer. -- **`ProxyTimeout 600`** applies the same budget to the connection with RustFS. -- **`RequestReadTimeout`** bounds slow clients without punishing steady ones: a request is dropped only when headers stall or the body rate falls below `MinRate`. -- **`LimitRequestBody 0`** states the default explicitly: request bodies of any size are accepted. +- **`Timeout 600`** は双方向の接続 I/O を対象にするため、遅いダウンロードやアップロードが転送の途中で切れません。 +- **`ProxyTimeout 600`** は、RustFS との接続に同じ上限を適用します。 +- **`RequestReadTimeout`** は、安定して送っているクライアントを不利にせず、遅いクライアントを制限します。リクエストが破棄されるのは、ヘッダーが停滞したとき、またはボディの速度が `MinRate` を下回ったときだけです。 +- **`LimitRequestBody 0`** は既定を明示したもので、任意のサイズのリクエストボディを受け付けます。 -:::warning[Uploads must carry a Content-Length] +:::warning[アップロードには Content-Length が必要] -RustFS rejects request bodies forwarded as `Transfer-Encoding: chunked` with `400 UnexpectedContent` (`This request does not support content.`). Clients must upload with a `Content-Length`. All major S3 clients do this out of the box, so this only affects hand-rolled HTTP scripts that stream from a pipe. Apache's default body handling converts small chunked bodies to `Content-Length` in memory but forwards large ones as chunked, so such a client can appear to work for small files and fail for large ones. `SetEnv proxy-sendcl 1` converts chunked bodies to `Content-Length` as a fallback — at the cost of spooling each body to the proxy's disk first. +RustFS は、`Transfer-Encoding: chunked` として転送されたリクエストボディを `400 UnexpectedContent`（`This request does not support content.`）で拒否します。クライアントは `Content-Length` 付きでアップロードする必要があります。主要な S3 クライアントはすべて最初からそうするため、影響があるのはパイプからストリームする自作の HTTP スクリプトだけです。Apache の既定のボディ処理は、小さなチャンクボディをメモリ上で `Content-Length` に変換しますが、大きなボディはチャンクのまま転送します。そのため、そのようなクライアントは小さなファイルでは動いて見え、大きなファイルで失敗することがあります。`SetEnv proxy-sendcl 1` はフォールバックとしてチャンクボディを `Content-Length` に変換します。その代わり、各ボディを先にプロキシのディスクへスプールします。 ::: -:::warning[Presigned URLs and the Content-Type header] +:::warning[署名付き URL と Content-Type ヘッダー] -A presigned URL fixes the headers covered by its signature. If the URL was generated without a `Content-Type`, the upload must not add one — RustFS answers `403 SignatureDoesNotMatch` for the unsigned header. Note that `curl -d` and `curl --data-binary` add `Content-Type: application/x-www-form-urlencoded` on their own. When the upload sends a `Content-Type`, presign the URL with the same value (the `ContentType` parameter in AWS SDKs) and make the request match it exactly. +署名付き URL は、署名の対象にしたヘッダーを固定します。`Content-Type` なしで URL を生成した場合、アップロード側でそのヘッダーを追加してはいけません。署名に含まれないヘッダーに対して、RustFS は `403 SignatureDoesNotMatch` を返します。`curl -d` と `curl --data-binary` は、独自に `Content-Type: application/x-www-form-urlencoded` を付けます。アップロードが `Content-Type` を送る場合は、同じ値で URL に署名し（AWS SDK では `ContentType` パラメーター）、リクエストをその値と完全に一致させます。 ::: -## Settings that do not suit RustFS +## RustFS に合わない設定 -The following Apache defaults and options break S3 semantics or waste resources. This configuration avoids all of them. +次の Apache の既定値とオプションは、S3 のセマンティクスを壊すか、リソースを無駄にします。この設定では、いずれも使っていません。 -| Setting | Effect on RustFS | +| 設定 | RustFS への影響 | | --- | --- | -| `ProxyPreserveHost Off` (default) | Rewrites `Host`; signed requests fail with `SignatureDoesNotMatch`. | -| `ProxyPass` without `nocanon` | Canonicalizes the request path; signed paths fail to verify. | -| `AllowEncodedSlashes Off` (default) | Returns `404` for object keys containing `%2F`. | -| Path prefixes (`ProxyPass /s3/`, `Alias`, rewrite rules) | Rewrites the request path; keep the S3 API on the root path. | -| `ProxyErrorOverride On` | Replaces RustFS S3 XML errors with Apache error pages; S3 SDKs cannot parse them. | -| `SetEnv proxy-sendcl 1`, `SetEnv force-proxy-request-1.0 1` | Forces a `Content-Length` upstream and spools chunked request bodies to disk before forwarding. It rescues chunked-only clients but adds disk I/O to large uploads. | -| `SetEnv proxy-sendchunked 1` | Forces chunked encoding upstream, which RustFS rejects with `400 UnexpectedContent`. | -| `mod_proxy_wstunnel` (`ProxyPass ... ws://`) | Deprecated since 2.4.47; use `upgrade=websocket` on `mod_proxy_http` instead. | +| `ProxyPreserveHost Off`（既定） | `Host` を書き換えます。署名済みリクエストは `SignatureDoesNotMatch` で失敗します。 | +| `nocanon` のない `ProxyPass` | リクエストパスを正規化します。署名済みのパスは検証に失敗します。 | +| `AllowEncodedSlashes Off`（既定） | `%2F` を含むオブジェクトキーに対して `404` を返します。 | +| パスプレフィックス（`ProxyPass /s3/`、`Alias`、rewrite ルール） | リクエストパスを書き換えます。S3 API はルートパスのままにします。 | +| `ProxyErrorOverride On` | RustFS の S3 XML エラーを Apache のエラーページに置き換えます。S3 SDK はこれを解析できません。 | +| `SetEnv proxy-sendcl 1`、`SetEnv force-proxy-request-1.0 1` | アップストリームへ `Content-Length` を強制し、転送前にチャンクのリクエストボディをディスクへスプールします。チャンクしか送れないクライアントは救えますが、大きなアップロードにディスク I/O が加わります。 | +| `SetEnv proxy-sendchunked 1` | アップストリームへチャンク転送を強制します。RustFS はこれを `400 UnexpectedContent` で拒否します。 | +| `mod_proxy_wstunnel`（`ProxyPass ... ws://`） | 2.4.47 以降は非推奨です。代わりに `mod_proxy_http` の `upgrade=websocket` を使います。 | -Two RustFS-side limits are worth marking because no proxy setting can remove them: +プロキシの設定では取り除けない、RustFS 側の制限が 2 つあります。 -- Object keys containing empty (`//`) or dot (`.`) path segments are rejected with `InvalidArgument` even without a proxy. -- In RustFS v2.x the Console lives under `/rustfs/console/`; the Console root path answers with S3-style XML. +- 空のパスセグメント（`//`）またはドット（`.`）を含むオブジェクトキーは、プロキシがなくても `InvalidArgument` で拒否されます。 +- RustFS v2.x では Console は `/rustfs/console/` の下にあり、Console のルートパスは S3 形式の XML で応答します。 -## Multi-node backends +## マルチノードのバックエンド [#multi-node-backends] -For a distributed RustFS deployment, replace each single `ProxyPass` target with a balancer that lists every RustFS node. Replace the S3 virtual host's proxy block with: +分散構成の RustFS デプロイでは、単一の `ProxyPass` 先を、すべての RustFS ノードを列挙したバランサーに置き換えます。S3 仮想ホストのプロキシブロックは、次に置き換えます。 ```apache title="config/rustfs.conf" @@ -349,7 +349,7 @@ For a distributed RustFS deployment, replace each single `ProxyPass` target with ProxyPassReverse / balancer://s3/ ``` -Replace the Console virtual host's proxy block with: +Console 仮想ホストのプロキシブロックは、次に置き換えます。 ```apache title="config/rustfs.conf" # Keep an in-progress login on the node that created its state. @@ -366,10 +366,10 @@ Replace the Console virtual host's proxy block with: ProxyPassReverse / balancer://console/ ``` -The `ROUTEID` cookie keeps an in-progress OpenID Connect login on the RustFS node that created its `state`. Keep `upgrade=websocket` on each `BalancerMember` line; `ProxySet` does not accept that parameter. Keep port `9000` open directly between RustFS nodes because internal node RPC uses the same listener. +`ROUTEID` Cookie により、進行中の OpenID Connect ログインは、その `state` を作成した RustFS ノードに留まります。`upgrade=websocket` は各 `BalancerMember` 行に残します。`ProxySet` はこのパラメーターを受け付けません。ノード間の内部 RPC は同じリスナーを使うため、RustFS ノード間ではポート `9000` を直接開けたままにします。 -## Next steps +## 次のステップ -- [Configure an S3 client](/developer/examples/aws-cli) -- [Enable virtual-hosted-style bucket URLs](/integration/virtual) -- [Review health and readiness endpoints](/operations/status-check) +- [S3 クライアントを設定する](/ja/developer/examples/aws-cli) +- [仮想ホスト形式のバケット URL を有効にする](/ja/integration/virtual) +- [ヘルスと準備完了のエンドポイントを確認する](/ja/operations/status-check) diff --git a/content/ja/developer/integration/reverse-proxy/index.md b/content/ja/developer/integration/reverse-proxy/index.md index 397cdad64..fd36c00c2 100644 --- a/content/ja/developer/integration/reverse-proxy/index.md +++ b/content/ja/developer/integration/reverse-proxy/index.md @@ -1,13 +1,13 @@ --- -title: "Reverse Proxy" -description: "Choose and configure a reverse proxy for the RustFS S3 API and Console." +title: "リバースプロキシ" +description: "RustFS の S3 API と Console 向けに、リバースプロキシを選択して設定します。" --- -Use a reverse proxy to expose the **RustFS** S3 API and Console through managed hostnames and TLS endpoints. +リバースプロキシを使い、管理しているホスト名と TLS エンドポイント経由で **RustFS** の S3 API と Console を公開します。 -We recommend using separate hostnames for the S3 API on port `9000` and the Console on port `9001`. Serve the S3 API from the root of its hostname because S3 clients sign the request path. +S3 API（ポート `9000`）と Console（ポート `9001`）には、別々のホスト名を使うことを推奨します。S3 クライアントはリクエストパスに署名するため、S3 API はそのホスト名のルートから提供します。 -## Supported guides +## 対応ガイド - [Nginx](./nginx.md) - [Traefik](./traefik.md) @@ -16,6 +16,6 @@ We recommend using separate hostnames for the S3 API on port `9000` and the Cons - [Envoy](./envoy.md) - [Apache HTTP Server](./httpd.md) -## Related configuration +## 関連する設定 -See [Virtual-Host Access](/integration/virtual) when clients access buckets through virtual-hosted-style URLs. \ No newline at end of file +クライアントが仮想ホスト形式の URL でバケットにアクセスする場合は、[仮想ホスト形式のアクセス](/ja/integration/virtual)を参照します。 diff --git a/content/ja/developer/integration/reverse-proxy/nginx.md b/content/ja/developer/integration/reverse-proxy/nginx.md index 5246711c6..37da64042 100644 --- a/content/ja/developer/integration/reverse-proxy/nginx.md +++ b/content/ja/developer/integration/reverse-proxy/nginx.md @@ -1,33 +1,33 @@ --- title: "Nginx" -description: "Deploy RustFS behind Nginx with separate HTTPS endpoints for the S3 API and Console." +description: "S3 API と Console を別々の HTTPS エンドポイントで公開する Nginx の背後に RustFS をデプロイします。" --- -Use **Nginx** to terminate TLS and route separate hostnames to the RustFS S3 API and Console. This deployment runs Nginx and a single-node RustFS instance with Docker Compose. You need Docker Engine, Docker Compose, two DNS records, and a TLS certificate that covers both hostnames. +**Nginx** で TLS を終端し、別々のホスト名を RustFS の S3 API と Console へ振り分けます。このデプロイでは、Docker Compose で Nginx とシングルノードの RustFS を動かします。Docker Engine、Docker Compose、DNS レコード 2 件、および両方のホスト名をカバーする TLS 証明書が必要です。 -This guide uses these example hostnames: +このガイドでは、次のホスト名を例に使います。 -- `s3.example.com` for the S3 API -- `console.example.com` for the Console +- S3 API 用の `s3.example.com` +- Console 用の `console.example.com` -Replace them with hostnames that resolve to the Docker host. +Docker ホストへ解決するホスト名に置き換えます。 -:::warning[Serve S3 from the root path] +:::warning[S3 はルートパスから公開する] -Do not publish the S3 API under a path such as `/s3/`. AWS Signature Version 4 includes the request path and host, so rewriting either value can invalidate signed requests. +`/s3/` のようなパスの下に S3 API を公開しないでください。AWS Signature Version 4 はリクエストパスとホストを署名対象に含めるため、どちらかを書き換えると署名済みリクエストが無効になることがあります。 ::: -## 1. Create the deployment directories +## 1. デプロイ用ディレクトリを作成する -Create directories for the Nginx configuration and TLS certificate: +Nginx の設定と TLS 証明書用のディレクトリを作成します。 ```bash mkdir -p rustfs-nginx/sites rustfs-nginx/certs cd rustfs-nginx ``` -Copy your certificate chain and private key into `certs/`: +証明書チェーンと秘密鍵を `certs/` へコピーします。 ```text rustfs-nginx/ @@ -37,26 +37,26 @@ rustfs-nginx/ └── sites/ ``` -Restrict access to the private key: +秘密鍵へのアクセスを制限します。 ```bash chmod 600 certs/privkey.pem ``` -## 2. Set RustFS credentials +## 2. RustFS の認証情報を設定する -Create an environment file and replace both credential placeholders: +環境ファイルを作成し、認証情報のプレースホルダーを両方とも置き換えます。 ```ini title=".env" RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Do not commit this file to source control. +このファイルはソース管理にコミットしないでください。 -## 3. Configure Nginx +## 3. Nginx を設定する -Create the Nginx configuration: +Nginx の設定を作成します。 ```nginx title="sites/rustfs.conf" map $http_upgrade $connection_upgrade { @@ -137,11 +137,11 @@ server { } ``` -The S3 server preserves the original host and request path, disables request buffering for streaming uploads, and does not convert signed `HEAD` requests. The Console server also forwards WebSocket upgrade headers. +S3 用の server ブロックは、元のホストとリクエストパスを保持し、ストリーミングアップロード向けにリクエストのバッファリングを無効にし、署名済みの `HEAD` リクエストを変換しません。Console 用の server ブロックは、WebSocket のアップグレードヘッダーも転送します。 -## 4. Create the Compose file +## 4. Compose ファイルを作成する -Create the deployment definition: +デプロイ定義を作成します。 ```yaml title="compose.yaml" services: @@ -192,11 +192,11 @@ networks: rustfs: ``` -Only Nginx publishes host ports. RustFS ports `9000` and `9001` remain reachable inside the Compose network. +ホストのポートを公開するのは Nginx だけです。RustFS のポート `9000` と `9001` には、Compose ネットワークの内部からのみ到達できます。 -## 5. Validate and start the deployment +## 5. デプロイを検証して起動する -Validate both configuration files before starting the services: +サービスを起動する前に、両方の設定ファイルを検証します。 ```bash docker compose config @@ -204,41 +204,41 @@ docker compose up -d rustfs docker compose run --rm --no-deps nginx nginx -t ``` -Start Nginx and check both services: +Nginx を起動し、両方のサービスを確認します。 ```bash docker compose up -d nginx docker compose ps ``` -If a service does not become healthy, inspect its logs: +サービスが正常にならない場合は、ログを確認します。 ```bash docker compose logs nginx docker compose logs rustfs ``` -## 6. Verify both endpoints +## 6. 両方のエンドポイントを確認する -Verify the API and Console through their public HTTPS hostnames: +公開 HTTPS ホスト名経由で API と Console を確認します。 ```bash curl --fail https://s3.example.com/health/ready curl --fail https://console.example.com/rustfs/console/health ``` -Configure S3 clients with `https://s3.example.com` as the endpoint and enable path-style addressing. Open `https://console.example.com/rustfs/console/` to sign in to the Console. +S3 クライアントのエンドポイントを `https://s3.example.com` に設定し、パススタイルアクセスを有効にします。`https://console.example.com/rustfs/console/` を開いて Console にサインインします。 -When you replace a renewed certificate or key in `certs/`, validate and reload Nginx without interrupting active connections: +`certs/` の証明書または鍵を更新したものに差し替えたら、既存の接続を中断せずに Nginx を検証して再読み込みします。 ```bash docker compose exec nginx nginx -t docker compose exec nginx nginx -s reload ``` -## Multi-node upstreams +## マルチノードのアップストリーム -For a distributed RustFS deployment, replace the single server in each upstream with all RustFS nodes: +分散構成の RustFS デプロイでは、各アップストリームの単一サーバーを、すべての RustFS ノードに置き換えます。 ```nginx title="sites/rustfs.conf" upstream rustfs_s3 { @@ -260,10 +260,10 @@ upstream rustfs_console { } ``` -The Console upstream uses client affinity because an in-progress OpenID Connect login stores its `state` on one RustFS node. Keep port `9000` open between RustFS nodes because internal node RPC uses the same listener. +Console のアップストリームがクライアントアフィニティを使うのは、進行中の OpenID Connect ログインが `state` を 1 台の RustFS ノードに保存するためです。ノード間の内部 RPC は同じリスナーを使うため、RustFS ノード間ではポート `9000` を開けたままにします。 -## Next steps +## 次のステップ -- [Configure an S3 client](/developer/examples/aws-cli) -- [Enable virtual-hosted-style bucket URLs](/integration/virtual) -- [Review health and readiness endpoints](/operations/status-check) \ No newline at end of file +- [S3 クライアントを設定する](/ja/developer/examples/aws-cli) +- [仮想ホスト形式のバケット URL を有効にする](/ja/integration/virtual) +- [ヘルスと準備完了のエンドポイントを確認する](/ja/operations/status-check) diff --git a/content/ja/developer/integration/reverse-proxy/traefik.md b/content/ja/developer/integration/reverse-proxy/traefik.md index 4d382cbc4..ae05c5a6b 100644 --- a/content/ja/developer/integration/reverse-proxy/traefik.md +++ b/content/ja/developer/integration/reverse-proxy/traefik.md @@ -1,26 +1,26 @@ --- title: "Traefik" -description: "Deploy RustFS behind Traefik with automatic TLS for separate S3 API and Console hostnames." +description: "S3 API と Console を別々のホスト名で公開し、TLS を自動取得する Traefik の背後に RustFS をデプロイします。" --- -Use **Traefik** and its Docker provider to discover RustFS, obtain TLS certificates from Let's Encrypt, and route separate hostnames to the S3 API and Console. You need Docker Engine, Docker Compose, a public server, and two DNS records that resolve to that server. +**Traefik** とその Docker プロバイダーで RustFS を検出し、Let's Encrypt から TLS 証明書を取得し、別々のホスト名を S3 API と Console へ振り分けます。Docker Engine、Docker Compose、公開サーバー、およびそのサーバーへ解決する DNS レコードが 2 件必要です。 -This guide uses these example hostnames: +このガイドでは、次のホスト名を例に使います。 -- `s3.example.com` for the S3 API -- `console.example.com` for the Console +- S3 API 用の `s3.example.com` +- Console 用の `console.example.com` -Replace them with your public hostnames. The ACME HTTP-01 challenge requires inbound access to ports `80` and `443`. +公開するホスト名に置き換えます。ACME の HTTP-01 チャレンジには、ポート `80` と `443` への着信アクセスが必要です。 -:::warning[Serve S3 from the root path] +:::warning[S3 はルートパスから公開する] -Do not publish the S3 API under a path such as `/s3/`. AWS Signature Version 4 includes the request path and host, so rewriting either value can invalidate signed requests. +`/s3/` のようなパスの下に S3 API を公開しないでください。AWS Signature Version 4 はリクエストパスとホストを署名対象に含めるため、どちらかを書き換えると署名済みリクエストが無効になることがあります。 ::: -## 1. Create the deployment directory +## 1. デプロイ用ディレクトリを作成する -Create a directory and an empty ACME storage file. Traefik requires restrictive permissions on this file: +ディレクトリと空の ACME 保存ファイルを作成します。Traefik はこのファイルに、制限の強いパーミッションを要求します。 ```bash mkdir rustfs-traefik @@ -29,9 +29,9 @@ touch acme.json chmod 600 acme.json ``` -## 2. Set deployment variables +## 2. デプロイ変数を設定する -Create an environment file and replace each value: +環境ファイルを作成し、各値を置き換えます。 ```ini title=".env" S3_HOSTNAME=s3.example.com @@ -41,11 +41,11 @@ RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -Use an email address that receives certificate expiration notices. Do not commit `.env` or `acme.json` to source control. +証明書の有効期限通知を受け取るメールアドレスを使います。`.env` と `acme.json` はソース管理にコミットしないでください。 -## 3. Create the Compose file +## 3. Compose ファイルを作成する -Create the Traefik and RustFS services: +Traefik と RustFS のサービスを作成します。 ```yaml title="compose.yaml" services: @@ -126,51 +126,51 @@ networks: name: rustfs ``` -The two routers use different host rules and backend ports. RustFS does not publish ports `9000` or `9001` on the Docker host, and the Traefik Dashboard is not exposed. +2 つのルーターは、異なるホスト規則とバックエンドのポートを使います。RustFS は Docker ホスト上でポート `9000` と `9001` を公開せず、Traefik Dashboard も公開しません。 -:::note[Docker socket access] +:::note[Docker ソケットへのアクセス] -Traefik reads container labels through the read-only Docker socket mount. Anyone who can modify Docker workloads can influence routes discovered by the Docker provider. Restrict Docker access on the proxy host. +Traefik は、読み取り専用でマウントした Docker ソケット経由でコンテナラベルを読み取ります。Docker のワークロードを変更できる人は、Docker プロバイダーが検出するルートに影響を与えられます。プロキシホストでは、Docker へのアクセスを制限します。 ::: -## 4. Validate and start the deployment +## 4. デプロイを検証して起動する -Render the Compose configuration and check that all variables resolve: +Compose の設定を展開し、すべての変数が解決することを確認します。 ```bash docker compose config ``` -Start both services: +両方のサービスを起動します。 ```bash docker compose up -d docker compose ps ``` -Follow the Traefik logs while it completes the ACME challenge and creates both certificates: +ACME チャレンジが完了し、両方の証明書が作成されるまで、Traefik のログを追います。 ```bash docker compose logs --follow traefik ``` -If certificate issuance fails, confirm that both DNS records resolve to this host and that ports `80` and `443` are reachable from the internet. Let's Encrypt rate limits apply, so correct DNS and firewall problems before repeatedly recreating the deployment. +証明書の発行に失敗した場合は、両方の DNS レコードがこのホストへ解決すること、およびポート `80` と `443` がインターネットから到達できることを確認します。Let's Encrypt にはレート制限があるため、DNS とファイアウォールの問題を直してから、デプロイの再作成を繰り返します。 -## 5. Verify both endpoints +## 5. 両方のエンドポイントを確認する -Verify the S3 API readiness endpoint and Console health endpoint through Traefik: +Traefik 経由で、S3 API の準備完了エンドポイントと Console のヘルスエンドポイントを確認します。 ```bash curl --fail https://s3.example.com/health/ready curl --fail https://console.example.com/rustfs/console/health ``` -Configure S3 clients with `https://s3.example.com` as the endpoint and enable path-style addressing. Open `https://console.example.com/rustfs/console/` to sign in to the Console. +S3 クライアントのエンドポイントを `https://s3.example.com` に設定し、パススタイルアクセスを有効にします。`https://console.example.com/rustfs/console/` を開いて Console にサインインします。 -## Multi-node services +## マルチノードのサービス -For an external multi-node RustFS cluster, enable Traefik's file provider in the `traefik` service: +外部のマルチノード RustFS クラスターでは、`traefik` サービスで Traefik のファイルプロバイダーを有効にします。 ```yaml title="compose.yaml" services: @@ -182,7 +182,7 @@ services: - ./dynamic.yaml:/etc/traefik/dynamic.yaml:ro ``` -Create the dynamic configuration with every RustFS node: +すべての RustFS ノードを含む動的設定を作成します。 ```yaml title="dynamic.yaml" http: @@ -234,10 +234,10 @@ http: - url: http://node4.example.net:9001 ``` -Configure sticky sessions for the Console service when you use OpenID Connect. An in-progress login stores its `state` on one RustFS node and the callback must return to that node. Keep port `9000` open directly between RustFS nodes because internal node RPC uses the same listener. +OpenID Connect を使う場合は、Console サービスにスティッキーセッションを設定します。進行中のログインは `state` を 1 台の RustFS ノードに保存するため、コールバックはそのノードへ戻る必要があります。ノード間の内部 RPC は同じリスナーを使うため、RustFS ノード間ではポート `9000` を直接開けたままにします。 -## Next steps +## 次のステップ -- [Configure an S3 client](/developer/examples/aws-cli) -- [Enable virtual-hosted-style bucket URLs](/integration/virtual) -- [Review health and readiness endpoints](/operations/status-check) \ No newline at end of file +- [S3 クライアントを設定する](/ja/developer/examples/aws-cli) +- [仮想ホスト形式のバケット URL を有効にする](/ja/integration/virtual) +- [ヘルスと準備完了のエンドポイントを確認する](/ja/operations/status-check) diff --git a/content/ja/developer/integration/storage/alluxio.md b/content/ja/developer/integration/storage/alluxio.md index df752710f..e1c5dfda5 100644 --- a/content/ja/developer/integration/storage/alluxio.md +++ b/content/ja/developer/integration/storage/alluxio.md @@ -1,13 +1,13 @@ --- title: "Alluxio" -description: "Cache RustFS buckets with Alluxio for faster reads." +description: "Alluxio で RustFS のバケットをキャッシュし、読み取りを高速化します。" --- -This guide connects [Alluxio](https://github.com/Alluxio/alluxio) — the distributed data orchestration layer — to **RustFS** as an under filesystem (UFS). You will run a standalone Alluxio cluster in Docker, mount a RustFS bucket, read an object through the cache, and write a file back to the bucket through Alluxio. The workflow was verified with Alluxio 2.9.4 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、分散データオーケストレーション層である [Alluxio](https://github.com/Alluxio/alluxio) を、アンダーファイルシステム（UFS）として **RustFS** に接続します。Docker 上でスタンドアロンの Alluxio クラスターを起動し、RustFS のバケットをマウントし、キャッシュ経由でオブジェクトを読み取り、Alluxio 経由でファイルをバケットへ書き戻します。手順は Alluxio 2.9.4 と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker with `--shm-size 2g` capacity (the worker uses a tmpfs ramdisk). +ワーカーは tmpfs の RAM ディスクを使うため、Docker には `--shm-size 2g` の共有メモリが必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -17,11 +17,11 @@ flowchart LR Writer["Alluxio writes"] -->|"persist"| RustFS ``` -Objects read once are cached in the worker's ramdisk; repeated reads are served from memory. Writes through Alluxio land in the bucket as regular objects. +一度読み取ったオブジェクトはワーカーの RAM ディスクにキャッシュされ、繰り返しの読み取りはメモリから応答されます。Alluxio 経由の書き込みは、通常のオブジェクトとしてバケットに保存されます。 -## 1. Run the master and worker +## 1. マスターとワーカーを起動する -The standalone image starts one process per invocation. Run the master first, then the worker: +スタンドアロンイメージは、1 回の起動につき 1 プロセスを開始します。先にマスターを起動し、続けてワーカーを起動します。 ```bash docker run -d --name alluxio-master --hostname alluxio --network oo-rustfs_default \ @@ -37,11 +37,11 @@ Capacity information for all workers: Total Capacity: 1024.00MB ``` -If the worker exits immediately with `tmpfs is smaller than the configured size`, the container was started without `--shm-size`. +ワーカーが `tmpfs is smaller than the configured size` ですぐに終了する場合、コンテナは `--shm-size` なしで起動されています。 -## 2. Mount the RustFS bucket +## 2. RustFS のバケットをマウントする -The credential options must use the full `alluxio.underfs.s3.*` key names — short `s3a.*` or `aws.*` keys are accepted by the CLI but ignored by the UFS client: +認証情報のオプションには、完全なキー名 `alluxio.underfs.s3.*` を使う必要があります。短い `s3a.*` や `aws.*` のキーは CLI では受け付けられますが、UFS クライアントは無視します。 ```bash docker exec alluxio alluxio fs mount \ @@ -57,11 +57,11 @@ docker exec alluxio alluxio fs mount \ Mounted s3://alluxio-demo/ at /rustfs ``` -`disable.dns.buckets` forces path-style addressing, which the IP-style endpoint requires. +`disable.dns.buckets` はパススタイルアクセスを強制します。IP 形式のエンドポイントではこれが必要です。 -## 3. Read through the cache +## 3. キャッシュ経由で読み取る -List the mount and read a seeded object: +マウントを一覧し、あらかじめ配置したオブジェクトを読み取ります。 ```bash docker exec alluxio alluxio fs ls /rustfs @@ -73,11 +73,11 @@ docker exec alluxio alluxio fs cat /rustfs/rustfs-test.txt hello from s3fs ``` -`PERSISTED` means the source of truth is in RustFS; the worker caches blocks after the first read. +`PERSISTED` は、正本が RustFS にあることを示します。ワーカーは初回の読み取り後にブロックをキャッシュします。 -## 4. Write through Alluxio +## 4. Alluxio 経由で書き込む -Copy a local file into the mount: +ローカルファイルをマウントへコピーします。 ```bash echo "written via alluxio cache to rustfs" > /tmp/rt.txt @@ -89,7 +89,7 @@ docker exec alluxio alluxio fs copyFromLocal /tmp/rt.txt /rustfs/alluxio-write.t Copied 'file:///tmp/rt.txt' to '/rustfs/alluxio-write.txt' ``` -Verify the object in RustFS: +RustFS でオブジェクトを確認します。 ```bash rc ls rustfs/alluxio-demo/ @@ -102,9 +102,9 @@ rc cat rustfs/alluxio-demo/alluxio-write.txt written via alluxio cache to rustfs ``` -![Alluxio-managed files stored in the RustFS Console](./images/rustfs-alluxio-mount.png) +![RustFS Console に保存された Alluxio 管理下のファイル](./images/rustfs-alluxio-mount.png) -## 5. Stop or reset +## 5. 停止またはリセットする ```bash docker exec alluxio alluxio fs unmount /rustfs @@ -112,22 +112,22 @@ docker rm -f alluxio rc rm rustfs/alluxio-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### Worker exits with `tmpfs is smaller than the configured size` +### `tmpfs is smaller than the configured size` でワーカーが終了する -The worker places its ramdisk in `/dev/shm`, which Docker caps at 64 MB by default. Start the container with `--shm-size 2g` or lower `alluxio.worker.ramdisk.size`. +ワーカーは RAM ディスクを `/dev/shm` に置きます。Docker の既定では、ここは 64 MB に制限されます。コンテナを `--shm-size 2g` で起動するか、`alluxio.worker.ramdisk.size` を下げます。 -### Mount succeeds but `fs ls` returns `InvalidAccessKeyId` +### マウントは成功するが `fs ls` が `InvalidAccessKeyId` を返す -The mount options used short key names (`s3a.*`, `aws.*`). Alluxio's UFS client only honors the full `alluxio.underfs.s3.*` keys shown in step 2. +マウントオプションに短いキー名（`s3a.*`、`aws.*`）が使われています。Alluxio の UFS クライアントが受け付けるのは、手順 2 に示した完全な `alluxio.underfs.s3.*` のキーだけです。 ### `S3 client v2 does not support global bucket access` -Path-style addressing is off. Add `--option alluxio.underfs.s3.disable.dns.buckets=true` — the IP-style RustFS endpoint requires it. +パススタイルアクセスが無効です。`--option alluxio.underfs.s3.disable.dns.buckets=true` を追加します。IP 形式の RustFS エンドポイントでは必須です。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional Alluxio UFS types. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [Alluxio documentation](https://docs.alluxio.io/os/user/stable/ufs/S3.html) for cache policies, TTLs, and multi-tier storage on top of the same bucket. +- ほかの Alluxio UFS タイプを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- 同じバケット上のキャッシュポリシー、TTL、多層ストレージについては、[Alluxio のドキュメント](https://docs.alluxio.io/os/user/stable/ufs/S3.html)に従います。 diff --git a/content/ja/developer/integration/storage/index.md b/content/ja/developer/integration/storage/index.md index 885c83dbc..6a30c83a7 100644 --- a/content/ja/developer/integration/storage/index.md +++ b/content/ja/developer/integration/storage/index.md @@ -1,11 +1,11 @@ --- -title: "Storage" -description: "Use RustFS as the S3 backend for storage systems and storage gateways." +title: "ストレージ" +description: "ストレージシステムとストレージゲートウェイの S3 バックエンドとして RustFS を使います。" --- -Use **RustFS** as the backend for storage systems and gateways built on top of object storage. +**RustFS** を、オブジェクトストレージの上に構築されたストレージシステムとゲートウェイのバックエンドとして使います。 -## Systems +## システム - [lakeFS](./lakefs.md) - [OpenDAL](./opendal.md) @@ -14,4 +14,4 @@ Use **RustFS** as the backend for storage systems and gateways built on top of o - [SFTPGo](./sftpgo.md) - [Alluxio](./alluxio.md) -Use a dedicated bucket and prefix per system, and scope credentials to the required bucket operations. +システムごとに専用のバケットとプレフィックスを使い、認証情報は必要なバケット操作に限定します。 diff --git a/content/ja/developer/integration/storage/lakefs.md b/content/ja/developer/integration/storage/lakefs.md index ba63ef224..b5221291d 100644 --- a/content/ja/developer/integration/storage/lakefs.md +++ b/content/ja/developer/integration/storage/lakefs.md @@ -1,13 +1,13 @@ --- title: "lakeFS" -description: "Run lakeFS with RustFS as its S3 blockstore for versioned data lakes." +description: "バージョン管理されたデータレイク向けに、S3 ブロックストアとして RustFS を使う lakeFS を実行します。" --- -This guide connects [lakeFS](https://github.com/treeverse/lakeFS) — the Git-like data lake versioning layer — to **RustFS** as its S3 blockstore. You will start lakeFS, create a repository whose storage namespace points at a RustFS bucket, commit an object, and verify that the lakeFS metadata and data files live in RustFS. The workflow was verified with `treeverse/lakefs:1.58.0` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、Git のようにデータレイクをバージョン管理する層である [lakeFS](https://github.com/treeverse/lakeFS) を、S3 ブロックストアとして **RustFS** に接続します。lakeFS を起動し、ストレージ名前空間が RustFS のバケットを指すリポジトリを作成し、オブジェクトをコミットして、lakeFS のメタデータとデータファイルが RustFS に保存されることを確認します。手順は `treeverse/lakefs:1.58.0` と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker. This deployment is intended for local integration testing, not production. +Docker が必要です。このデプロイはローカルでの連携テスト用であり、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR LakeFS -->|"metadata + data"| RustFS["RustFS :9000"] ``` -lakeFS stores repository metadata and committed data files in the blockstore under the storage namespace. The bucket holds one `repo/` prefix containing `_lakefs/` metadata and `data/` objects; lakeFS reads and writes them through the S3 API. +lakeFS は、リポジトリのメタデータとコミット済みのデータファイルを、ストレージ名前空間の下のブロックストアに保存します。バケットには、`_lakefs/` のメタデータと `data/` のオブジェクトを含む `repo/` プレフィックスが 1 つあります。lakeFS は S3 API 経由でそれらを読み書きします。 -## 1. Create the project files +## 1. プロジェクトファイルを作成する -Create the bucket, then the lakeFS configuration: +バケットを作成し、続けて lakeFS の設定を作成します。 ```bash rc alias set rustfs http://:9000 @@ -52,9 +52,9 @@ logging: level: info ``` -`force_path_style: true` is required — without it lakeFS builds `lakefs-data.` as a hostname and every request fails with a DNS error. The credentials are supplied through the standard `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables. +`force_path_style: true` は必須です。設定しないと、lakeFS は `lakefs-data.` をホスト名として組み立て、すべてのリクエストが DNS エラーで失敗します。認証情報は、標準の環境変数 `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` で渡します。 -Create the environment file for the service credentials and the initial admin user, replacing the placeholders: +サービスの認証情報と初期管理者ユーザー用の環境ファイルを作成し、プレースホルダーを置き換えます。 ```ini title=".env" AWS_ACCESS_KEY_ID= @@ -65,7 +65,7 @@ LAKEFS_INSTALLATION_SECRET_ACCESS_KEY= LAKEFS_STATS_ENABLED=false ``` -## 2. Start lakeFS +## 2. lakeFS を起動する ```bash docker run -d --name lakefs --network oo-rustfs_default \ @@ -75,7 +75,7 @@ docker run -d --name lakefs --network oo-rustfs_default \ treeverse/lakefs:1.58.0 run ``` -Wait for `http://localhost:8000/api/healthcheck` to return `200`, then create a repository with a storage namespace inside the bucket: +`http://localhost:8000/api/healthcheck` が `200` を返すまで待ち、バケット内のストレージ名前空間を持つリポジトリを作成します。 ```bash curl -s -u : \ @@ -84,9 +84,9 @@ curl -s -u : \ -d '{"name": "rustfs-demo", "storage_namespace": "s3://lakefs-data/repo"}' ``` -## 3. Commit an object +## 3. オブジェクトをコミットする -Upload a file to the `main` branch and commit it: +ファイルを `main` ブランチへアップロードしてコミットします。 ```bash echo "hello from lakefs on rustfs" > hello.txt @@ -101,60 +101,60 @@ curl -s -u : \ -d '{"message": "add hello"}' ``` -Read the object back through the branch ref — the response body is the committed content: +ブランチ参照経由でオブジェクトを読み戻します。レスポンス本文が、コミット済みの内容です。 ```bash curl -s -u : \ "http://localhost:8000/api/v1/repositories/rustfs-demo/refs/main/objects?path=hello.txt" ``` -## 4. Verify objects in RustFS +## 4. RustFS でオブジェクトを確認する -List the bucket: +バケットを一覧します。 ```bash rc ls rustfs/lakefs-data/ -r ``` -The output shows the lakeFS metadata objects and the committed data file under the repository prefix: +出力には、リポジトリのプレフィックス配下にある lakeFS のメタデータオブジェクトと、コミット済みのデータファイルが表示されます。 ```text repo/_lakefs/19b2b26e37cb20fc6763c527f88eb5151891b04a2c8c9ddd32870c5c3f353281 repo/data/fueia10jdra000e1c480/daots7ojdra000e1c490 ``` -![lakeFS objects stored in the RustFS Console](./images/rustfs-lakefs-repo.png) +![RustFS Console に保存された lakeFS のオブジェクト](./images/rustfs-lakefs-repo.png) -## 5. Stop or reset the deployment +## 5. デプロイを停止またはリセットする -Stop lakeFS while keeping the data: +データを残したまま lakeFS を停止します。 ```bash docker rm -f lakefs ``` -The repository metadata and data stay in the `lakefs-data` bucket, so restarting lakeFS with the same configuration brings the repository back. To delete everything, remove the bucket: +リポジトリのメタデータとデータは `lakefs-data` バケットに残るため、同じ設定で lakeFS を再起動するとリポジトリが戻ります。すべて削除するには、バケットを削除します。 ```bash rc rb rustfs/lakefs-data --force ``` -## Troubleshooting +## トラブルシューティング -### `failed to create repository: failed to access storage` with a DNS error +### DNS エラーを伴う `failed to create repository: failed to access storage` -lakeFS is using virtual-hosted addressing. Set `force_path_style: true` under `blockstore.s3` — in the 1.x configuration schema the older `path_style` key is rejected at startup. +lakeFS が仮想ホスト形式を使っています。`blockstore.s3` の下に `force_path_style: true` を設定します。1.x の設定スキーマでは、古い `path_style` キーは起動時に拒否されます。 ### `missing required keys: [auth.encrypt.secret_key]` -lakeFS 1.x requires an encryption key for the local database. Add the `auth.encrypt.secret_key` block as shown in the configuration above. +lakeFS 1.x では、ローカルデータベース用の暗号化キーが必要です。上の設定に示した `auth.encrypt.secret_key` のブロックを追加します。 ### `mkdir /lakefs: permission denied` -The container runs as a non-root user and cannot create the database directory. Run the container with `-u 0` for local testing, or mount a writable directory at the configured path. +コンテナは root 以外のユーザーで動作し、データベースディレクトリを作成できません。ローカルテストでは `-u 0` を付けてコンテナを実行するか、設定したパスに書き込み可能なディレクトリをマウントします。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional lakeFS operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [lakeFS S3 blockstore documentation](https://docs.lakefs.io/howto/using-s3.html) to configure the S3 gateway for tools that speak the S3 protocol. +- ほかの lakeFS 操作を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- S3 プロトコルを使うツール向けに S3 ゲートウェイを設定するには、[lakeFS の S3 ブロックストアのドキュメント](https://docs.lakefs.io/howto/using-s3.html)に従います。 diff --git a/content/ja/developer/integration/storage/opendal.md b/content/ja/developer/integration/storage/opendal.md index 074b7475f..7c3a15d57 100644 --- a/content/ja/developer/integration/storage/opendal.md +++ b/content/ja/developer/integration/storage/opendal.md @@ -1,13 +1,13 @@ --- title: "OpenDAL" -description: "Access RustFS objects from applications through the Apache OpenDAL data access layer." +description: "Apache OpenDAL のデータアクセス層を通じて、アプリケーションから RustFS のオブジェクトにアクセスします。" --- -This guide connects [Apache OpenDAL](https://github.com/apache/opendal) — the unified data access layer — to **RustFS** through its `s3` service. You will run the OpenDAL Python binding against RustFS, write and read an object, list a prefix, and delete it. The workflow was verified with the `opendal` Python package 0.46 on `python:3.12-slim` and `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、統一データアクセス層である [Apache OpenDAL](https://github.com/apache/opendal) を、`s3` サービス経由で **RustFS** に接続します。OpenDAL の Python バインディングを RustFS に対して実行し、オブジェクトの書き込みと読み取り、プレフィックスの一覧、削除を行います。手順は `python:3.12-slim` 上の `opendal` Python パッケージ 0.46 と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker and Python 3.9 or later. OpenDAL supports the same `s3` service from Rust, Java, Node.js, and Go bindings with equivalent settings. +Docker と Python 3.9 以降が必要です。OpenDAL は、同等の設定であれば、Rust、Java、Node.js、Go のバインディングからも同じ `s3` サービスを使えます。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,17 +15,17 @@ flowchart LR OpenDAL -->|"s3 service"| RustFS["RustFS :9000"] ``` -An OpenDAL `Operator` bound to the `s3` service exposes one uniform API — `write`, `read`, `stat`, `list`, `delete` — over the bucket, so the same code runs against S3, RustFS, or any other supported service by changing the connection settings. +`s3` サービスに結び付けた OpenDAL の `Operator` は、バケットに対して `write`、`read`、`stat`、`list`、`delete` という統一された API を公開します。接続設定を変えるだけで、同じコードを S3、RustFS、その他の対応サービスに対して実行できます。 -## 1. Set up the project +## 1. プロジェクトをセットアップする -Install the Python binding: +Python バインディングをインストールします。 ```bash pip install opendal ``` -Create the script, replacing all connection placeholders: +接続用のプレースホルダーをすべて置き換えて、スクリプトを作成します。 ```python title="opendal_demo.py" import opendal @@ -47,11 +47,11 @@ op.delete("opendal-demo/hello.txt") print("deleted:", not op.exists("opendal-demo/hello.txt")) ``` -The credential option names are `access_key_id` and `secret_access_key` — the shorter `access_key` names do not exist and fail with a signing error. Path-style addressing is the default for non-AWS endpoints. +認証情報のオプション名は `access_key_id` と `secret_access_key` です。短い `access_key` という名前は存在せず、署名エラーで失敗します。AWS 以外のエンドポイントでは、パススタイルアクセスが既定です。 -## 2. Run the demo +## 2. デモを実行する -Run the script from a machine that can reach RustFS: +RustFS に到達できるマシンからスクリプトを実行します。 ```bash python opendal_demo.py @@ -64,11 +64,11 @@ listed: opendal-demo/hello.txt deleted: True ``` -The round trip exercises the full object lifecycle: write uploads the bytes, `read` fetches them back, `stat` returns the object size, `list` enumerates the prefix, and `delete` removes the object. +往復検証では、オブジェクトのライフサイクル全体を確認します。write がバイト列をアップロードし、`read` が読み戻し、`stat` がオブジェクトサイズを返し、`list` がプレフィックスを列挙し、`delete` がオブジェクトを削除します。 -## 3. Verify objects in RustFS +## 3. RustFS でオブジェクトを確認する -Comment out the final `op.delete` line, run the script again, and list the prefix in RustFS: +最後の `op.delete` 行をコメントアウトし、スクリプトを再実行して、RustFS のプレフィックスを一覧します。 ```bash rc ls rustfs/my-bucket/opendal-demo/ -r @@ -79,30 +79,30 @@ hello.txt data/rows.csv ``` -![OpenDAL objects stored in the RustFS Console](./images/rustfs-opendal-objects.png) +![RustFS Console に保存された OpenDAL のオブジェクト](./images/rustfs-opendal-objects.png) -The objects visible in the RustFS Console are exactly the paths the OpenDAL API wrote. +RustFS Console に表示されるオブジェクトは、OpenDAL API が書き込んだパスそのものです。 -## 4. Stop or reset +## 4. 停止またはリセットする -OpenDAL is a library and holds no state of its own. To clean up the demo objects: +OpenDAL はライブラリであり、自身の状態は持ちません。デモ用オブジェクトを削除するには、次を実行します。 ```bash rc rm rustfs/my-bucket/opendal-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング ### `failed to load signing credential` -The operator received no usable credentials. Use the exact option names `access_key_id` and `secret_access_key`; other spellings are silently ignored and signing then fails. +オペレーターに使える認証情報が渡されていません。オプション名は `access_key_id` と `secret_access_key` をそのまま使います。ほかの綴りは黙って無視され、その後の署名が失敗します。 -### Connection or DNS errors on write +### 書き込み時の接続エラーまたは DNS エラー -Confirm the endpoint includes the scheme and port and is reachable from the application. Inside a Compose network the hostname is `rustfs`; from the host use `http://localhost:9000`. +エンドポイントにスキームとポートが含まれ、アプリケーションから到達できることを確認します。Compose ネットワーク内のホスト名は `rustfs` です。ホストからは `http://localhost:9000` を使います。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional OpenDAL operations. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [OpenDAL documentation](https://opendal.apache.org/docs/) to use the same operator from Rust, Java, or Node.js. +- ほかの OpenDAL 操作を採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- Rust、Java、Node.js から同じオペレーターを使うには、[OpenDAL のドキュメント](https://opendal.apache.org/docs/)に従います。 diff --git a/content/ja/developer/integration/storage/s3fs.md b/content/ja/developer/integration/storage/s3fs.md index f1a600d00..4642c38dc 100644 --- a/content/ja/developer/integration/storage/s3fs.md +++ b/content/ja/developer/integration/storage/s3fs.md @@ -1,13 +1,13 @@ --- title: "s3fs" -description: "Mount a RustFS bucket as a local filesystem with s3fs-fuse." +description: "s3fs-fuse で RustFS のバケットをローカルファイルシステムとしてマウントします。" --- -This guide connects [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) — the FUSE-based S3 filesystem — to **RustFS**. You will mount a bucket as a local directory, write files through the mount, unmount, and confirm the objects persist in the bucket. The workflow was verified with s3fs v1.93 against `rustfs/rustfs-x86-musl:v2.3.1` on Ubuntu 24.04. +このガイドでは、FUSE ベースの S3 ファイルシステムである [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) を **RustFS** に接続します。バケットをローカルディレクトリとしてマウントし、マウント経由でファイルを書き込み、アンマウントしたうえで、オブジェクトがバケットに残ることを確認します。手順は Ubuntu 24.04 上の s3fs v1.93 と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need a Linux host with FUSE (`fuse3` package) and the `s3fs` binary. +FUSE（`fuse3` パッケージ）と `s3fs` バイナリを備えた Linux ホストが必要です。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,9 +15,9 @@ flowchart LR Mount -->|"S3 API"| RustFS["RustFS :9000"] ``` -Every file created under the mount point becomes an object in the bucket, keyed by its relative path — a plain 1:1 mapping with no caching layer. +マウントポイント配下に作成した各ファイルは、相対パスをキーとするバケット内のオブジェクトになります。キャッシュ層のない、単純な 1 対 1 の対応です。 -## 1. Install +## 1. インストールする ```bash apt-get install -y s3fs @@ -28,16 +28,16 @@ s3fs --version Amazon Simple Storage Service File System V1.93 ... ``` -## 2. Store the credentials +## 2. 認証情報を保存する -Write the access key and secret key to the password file s3fs expects: +s3fs が想定するパスワードファイルに、アクセスキーとシークレットキーを書き込みます。 ```bash echo ":" > ~/.passwd-s3fs chmod 600 ~/.passwd-s3fs ``` -## 3. Mount the bucket +## 3. バケットをマウントする ```bash mkdir -p /mnt/s3fs-demo @@ -49,9 +49,9 @@ s3fs s3fs-demo /mnt/s3fs-demo \ -o allow_other -o umask=000 ``` -`use_path_request_style` selects path-style addressing, which is what RustFS serves. `allow_other` lets non-root users read the mount. +`use_path_request_style` は、RustFS が提供するパススタイルアクセスを選択します。`allow_other` を付けると、root 以外のユーザーもマウントを読み取れます。 -## 4. Write and read files +## 4. ファイルを書き込み、読み取る ```bash echo "hello from s3fs" > /mnt/s3fs-demo/s3fs-test.txt @@ -63,9 +63,9 @@ cat /mnt/s3fs-demo/s3fs-test.txt hello from s3fs ``` -## 5. Verify objects and persistence +## 5. オブジェクトと永続化を確認する -Unmount and remount — the objects persist in the bucket: +アンマウントして再マウントします。オブジェクトはバケットに残ります。 ```bash fusermount -u /mnt/s3fs-demo @@ -79,7 +79,7 @@ ls /mnt/s3fs-demo/ blob.bin s3fs-test.txt ``` -List the bucket to see the same objects from the S3 side: +バケットを一覧し、S3 側から同じオブジェクトを確認します。 ```bash rc ls rustfs/s3fs-demo/ @@ -90,31 +90,31 @@ rc ls rustfs/s3fs-demo/ [2026-10-06 12:09:26] 16 B s3fs-test.txt ``` -![s3fs files stored in the RustFS Console](./images/rustfs-s3fs-files.png) +![RustFS Console に保存された s3fs のファイル](./images/rustfs-s3fs-files.png) -## 6. Stop or reset +## 6. 停止またはリセットする ```bash fusermount -u /mnt/s3fs-demo rc rm rustfs/s3fs-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `fuse: device not found` inside a container +### コンテナ内で `fuse: device not found` になる -Pass `--device /dev/fuse --cap-add SYS_ADMIN` to `docker run`, or `--privileged` if the mount helper still fails. +`docker run` に `--device /dev/fuse --cap-add SYS_ADMIN` を渡します。マウントヘルパーがそれでも失敗する場合は、`--privileged` を使います。 -### `Permission denied` reading the mount as another user +### 別のユーザーがマウントを読むと `Permission denied` になる -s3fs mounts are private to the mounting user by default. Add `-o allow_other -o umask=000` (or a tighter umask) at mount time. +s3fs のマウントは、既定ではマウントしたユーザー専用です。マウント時に `-o allow_other -o umask=000`（またはより厳しい umask）を追加します。 -### Mount succeeds but listing is empty on another client +### マウントは成功するが、別のクライアントでは一覧が空になる -s3fs has no metadata cache shared across mounts, but clients and list operations are eventually consistent. Remount or re-list after a few seconds. +s3fs には、マウント間で共有されるメタデータキャッシュはありません。クライアントと一覧操作には結果整合性があります。数秒待ってから再マウントするか、一覧を再実行します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional FUSE options. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [s3fs-fuse documentation](https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-https) for performance tuning options such as `-o multipart` and `-o parallel_count`. +- ほかの FUSE オプションを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- `-o multipart` や `-o parallel_count` などの性能調整オプションについては、[s3fs-fuse のドキュメント](https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-https)に従います。 diff --git a/content/ja/developer/integration/storage/sftpgo.md b/content/ja/developer/integration/storage/sftpgo.md index d37db1408..4aff33532 100644 --- a/content/ja/developer/integration/storage/sftpgo.md +++ b/content/ja/developer/integration/storage/sftpgo.md @@ -1,13 +1,13 @@ --- title: "SFTPGo" -description: "Serve RustFS buckets over SFTP with SFTPGo." +description: "SFTPGo で RustFS のバケットを SFTP 経由で提供します。" --- -This guide connects [SFTPGo](https://github.com/drakkan/sftpgo) — the full-featured SFTP/WebDAV/FTP server — to **RustFS** as a per-user S3 backend. You will create an SFTP user whose home directory is a RustFS bucket prefix, upload files over SFTP, and verify the objects in the bucket. The workflow was verified with SFTPGo 2.7.6 against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、SFTP、WebDAV、FTP に対応するサーバーである [SFTPGo](https://github.com/drakkan/sftpgo) を、ユーザーごとの S3 バックエンドとして **RustFS** に接続します。ホームディレクトリが RustFS バケットのプレフィックスである SFTP ユーザーを作成し、SFTP 経由でファイルをアップロードして、バケット内のオブジェクトを確認します。手順は SFTPGo 2.7.6 と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker and an SFTP client (`sftp` ships with OpenSSH). +Docker と SFTP クライアントが必要です（`sftp` は OpenSSH に含まれます）。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,9 +15,9 @@ flowchart LR SFTPGo -->|"S3 API"| RustFS["RustFS :9000"] ``` -SFTPGo maps the user's virtual paths onto bucket prefixes. Files uploaded over SFTP become objects under the configured `key_prefix` — nothing is stored on the SFTPGo host itself. +SFTPGo は、ユーザーの仮想パスをバケットのプレフィックスへ対応付けます。SFTP 経由でアップロードしたファイルは、設定した `key_prefix` 配下のオブジェクトになります。SFTPGo ホスト自体には保存されません。 -## 1. Run SFTPGo +## 1. SFTPGo を起動する ```bash docker run -d --name sftpgo --hostname sftpgo --network oo-rustfs_default \ @@ -26,11 +26,11 @@ docker run -d --name sftpgo --hostname sftpgo --network oo-rustfs_default \ drakkan/sftpgo:latest ``` -`SFTPGO_COMMON__TEMP_PATH` matters: for S3 backends SFTPGo streams uploads through a local pipe file, and the default temp path may not exist or be writable. +`SFTPGO_COMMON__TEMP_PATH` は重要です。S3 バックエンドでは、SFTPGo がローカルのパイプファイル経由でアップロードをストリームします。既定の一時パスは、存在しないか書き込めないことがあります。 -## 2. Create the admin user +## 2. 管理者ユーザーを作成する -The image does not create the admin automatically. Open `http://localhost:8080/web/admin/setup` once and submit the form, or drive it with curl: +イメージは管理者を自動では作成しません。`http://localhost:8080/web/admin/setup` を一度開いてフォームを送信するか、curl で実行します。 ```bash FORM=$(curl -s -c /tmp/sg-cookie.txt http://localhost:8080/web/admin/setup) @@ -47,9 +47,9 @@ curl -s -b /tmp/sg-cookie.txt -X POST http://localhost:8080/web/admin/setup \ setup: 302 ``` -## 3. Create an S3-backed user +## 3. S3 バックエンドのユーザーを作成する -Get an API token and create the user. Three details matter: `home_dir` must be an existing writable directory inside the container (`/tmp` works), `force_path_style` must be `true` for RustFS, and `access_secret` is a KMS object — pass the secret inside `{"status": "Plain", "payload": ...}`: +API トークンを取得してユーザーを作成します。次の 3 点が重要です。`home_dir` はコンテナ内の既存の書き込み可能ディレクトリである必要があります（`/tmp` で動作します）。RustFS では `force_path_style` を `true` にする必要があります。`access_secret` は KMS オブジェクトなので、シークレットは `{"status": "Plain", "payload": ...}` の中に渡します。 ```json title="sftpgo-user.json" { @@ -85,7 +85,7 @@ curl -s -X POST http://localhost:8080/api/v2/users \ create-user: 201 ``` -## 4. Upload and read files over SFTP +## 4. SFTP 経由でファイルをアップロードし、読み取る ```bash printf "uploaded via sftpgo to rustfs\n" > /tmp/sftp-test.txt @@ -105,7 +105,7 @@ sftp> ls sftp-big.bin sftp-test.txt ``` -## 5. Verify objects in RustFS +## 5. RustFS でオブジェクトを確認する ```bash rc ls rustfs/sftpgo-demo/home/demo/ -r @@ -118,33 +118,33 @@ rc cat rustfs/sftpgo-demo/home/demo/sftp-test.txt uploaded via sftpgo to rustfs ``` -The object key is the user's virtual path under `key_prefix` — a plain mapping. +オブジェクトキーは、`key_prefix` 配下にあるユーザーの仮想パスです。単純な対応付けです。 -![SFTPGo files stored in the RustFS Console](./images/rustfs-sftpgo-home.png) +![RustFS Console に保存された SFTPGo のファイル](./images/rustfs-sftpgo-home.png) -## 6. Stop or reset +## 6. 停止またはリセットする ```bash docker rm -f sftpgo rc rm rustfs/sftpgo-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `create resource error` / `InvalidAccessKeyId` on upload +### アップロード時の `create resource error` / `InvalidAccessKeyId` -Check three things in order: `force_path_style` must be `true` (SFTPGo's AWS SDK defaults to virtual-host addressing, which breaks IP endpoints), `access_secret` must use the KMS-object form, and `home_dir` must point at a writable directory (SFTPGo pipes S3 uploads through it). +次の 3 点を順に確認します。`force_path_style` は `true` である必要があります。SFTPGo の AWS SDK は既定で仮想ホスト形式になり、IP のエンドポイントでは失敗します。`access_secret` は KMS オブジェクトの形式である必要があります。`home_dir` は書き込み可能なディレクトリを指す必要があります。SFTPGo は、ここを経由して S3 へのアップロードをパイプします。 -### `unknown command init` / admin login rejected +### `unknown command init`、または管理者ログインが拒否される -The admin account only exists after the web setup form is submitted once. Repeat step 2; do not reuse an old browser cookie jar. +管理者アカウントは、Web のセットアップフォームを一度送信した後にだけ存在します。手順 2 を繰り返します。古いブラウザのクッキーは再利用しません。 -### API returns `405 Method Not allowed` for the token +### トークン取得で API が `405 Method Not allowed` を返す -The token endpoint only accepts `GET` with basic auth: `GET /api/v2/token`. +トークンのエンドポイントが受け付けるのは、Basic 認証付きの `GET` だけです。`GET /api/v2/token` を使います。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional SFTPGo backends. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [SFTPGo documentation](https://github.com/drakkan/sftpgo/blob/main/README.md) to add WebDAV/FTP listeners, per-user quotas, and two-factor auth on top of the same bucket. +- ほかの SFTPGo バックエンドを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- 同じバケット上に WebDAV と FTP のリスナー、ユーザーごとのクォータ、二要素認証を追加するには、[SFTPGo のドキュメント](https://github.com/drakkan/sftpgo/blob/main/README.md)に従います。 diff --git a/content/ja/developer/integration/storage/zerofs.md b/content/ja/developer/integration/storage/zerofs.md index 2dd1640b6..5b32b2c44 100644 --- a/content/ja/developer/integration/storage/zerofs.md +++ b/content/ja/developer/integration/storage/zerofs.md @@ -1,13 +1,13 @@ --- title: "ZeroFS" -description: "Serve a RustFS bucket as a POSIX filesystem over NFS with ZeroFS." +description: "ZeroFS で RustFS のバケットを NFS 経由の POSIX ファイルシステムとして提供します。" --- -This guide connects [ZeroFS](https://github.com/Barre/ZeroFS) — the log-structured filesystem that serves S3 buckets as POSIX filesystems — to **RustFS** as its object storage backend. You will run ZeroFS with its LSM tree rooted in a RustFS bucket, mount the filesystem over NFS on a Linux host, write files through the mount, and verify they survive a ZeroFS restart as objects in the bucket. The workflow was verified with ZeroFS v2.3.5 (ghcr.io/barre/zerofs) against `rustfs/rustfs-x86-musl:v2.3.1`. +このガイドでは、S3 バケットを POSIX ファイルシステムとして提供するログ構造化ファイルシステムである [ZeroFS](https://github.com/Barre/ZeroFS) を、オブジェクトストレージのバックエンドとして **RustFS** に接続します。LSM ツリーのルートを RustFS のバケットに置いて ZeroFS を実行し、Linux ホストから NFS でファイルシステムをマウントし、マウント経由でファイルを書き込み、ZeroFS を再起動してもバケット内のオブジェクトとして残ることを確認します。手順は ZeroFS v2.3.5（ghcr.io/barre/zerofs）と `rustfs/rustfs-x86-musl:v2.3.1` の組み合わせで確認済みです。 -You need Docker and a Linux host with an NFS client (`nfs-common`). This deployment is intended for local integration testing, not production. +Docker と、NFS クライアント（`nfs-common`）を備えた Linux ホストが必要です。このデプロイはローカルでの連携テスト用であり、本番向けではありません。 -## Architecture +## アーキテクチャ ```mermaid flowchart LR @@ -15,11 +15,11 @@ flowchart LR ZeroFS -->|"LSM SSTs, WAL, manifests"| RustFS["RustFS :9000"] ``` -ZeroFS translates filesystem operations into an LSM key-value tree stored in the bucket: writes land in a write-ahead log, flush into SST segments, and compaction runs in the background. Clients see an ordinary directory tree over NFS (or 9P/NBD). +ZeroFS は、ファイルシステム操作をバケット内の LSM キーバリューツリーへ変換します。書き込みは先行書き込みログに入り、SST セグメントへフラッシュされ、コンパクションはバックグラウンドで実行されます。クライアントからは、NFS（または 9P/NBD）経由の通常のディレクトリツリーに見えます。 -## 1. Generate the configuration +## 1. 設定を生成する -Create the bucket and the config file, replacing all connection placeholders: +接続用のプレースホルダーをすべて置き換えて、バケットと設定ファイルを作成します。 ```bash rc mb rustfs/zerofs-demo @@ -28,7 +28,7 @@ docker run --rm -u root:root -v /opt/zerofs:/cfg -w /cfg \ --entrypoint /bin/sh ghcr.io/barre/zerofs:latest -c "zerofs init" ``` -Then edit `zerofs.toml` so the storage and AWS sections point at RustFS: +続けて `zerofs.toml` を編集し、storage セクションと AWS セクションが RustFS を指すようにします。 ```toml title="zerofs.toml" [cache] @@ -53,11 +53,11 @@ default_region = "us-east-1" allow_http = "true" ``` -The `endpoint` plus `allow_http` pair is what redirects ZeroFS from AWS to RustFS. Custom endpoints use path-style addressing, so no extra option is needed. +`endpoint` と `allow_http` の組み合わせにより、ZeroFS の接続先が AWS から RustFS へ切り替わります。カスタムエンドポイントではパススタイルアクセスが使われるため、追加のオプションは不要です。 -## 2. Run ZeroFS +## 2. ZeroFS を実行する -Run the server with the config file, credentials, and a writable cache directory (the image runs as UID 1001): +設定ファイル、認証情報、書き込み可能なキャッシュディレクトリを指定してサーバーを実行します（イメージは UID 1001 で動作します）。 ```bash mkdir -p /opt/zerofs/cache && chown -R 1001:1001 /opt/zerofs/cache @@ -75,9 +75,9 @@ docker run -d --name zerofs --network oo-rustfs_default -p 2049:2049 \ INFO zerofs::nfs: NFS server listening on 0.0.0.0:2049 ``` -## 3. Mount over NFS +## 3. NFS でマウントする -On the host, mount the export with the options ZeroFS recommends: +ホストで、ZeroFS が推奨するオプションを使ってエクスポートをマウントします。 ```bash apt-get install -y nfs-common @@ -87,16 +87,16 @@ mount -t nfs -o async,nolock,rsize=1048576,wsize=1048576,tcp,port=2049,mountport 127.0.0.1:/ /mnt/zerofs ``` -The mount is an ordinary POSIX filesystem: +マウントは通常の POSIX ファイルシステムです。 ```bash echo "written via zerofs nfs mount on rustfs" > /mnt/zerofs/hello.txt dd if=/dev/urandom of=/mnt/zerofs/data/inner/blob.bin bs=1M count=8 ``` -## 4. Verify persistence and objects in RustFS +## 4. 永続化と RustFS 内のオブジェクトを確認する -Force pending writes to the bucket, then restart ZeroFS and remount: +保留中の書き込みをバケットへ強制的に送り、ZeroFS を再起動して再マウントします。 ```bash docker exec zerofs zerofs flush -c /zerofs.toml @@ -106,7 +106,7 @@ mount -t nfs -o async,nolock,rsize=1048576,wsize=1048576,tcp,port=2049,mountport 127.0.0.1:/ /mnt/zerofs ``` -Everything written before the restart is still there: +再起動前に書き込んだ内容は、そのまま残っています。 ```bash cat /mnt/zerofs/hello.txt @@ -118,7 +118,7 @@ written via zerofs nfs mount on rustfs 645faaefe499f9ebda8edceeeb1a6261999aece7 /mnt/zerofs/data/inner/blob.bin ``` -List the bucket to see where the files actually live: +バケットを一覧し、ファイルの実体がどこにあるかを確認します。 ```bash rc ls rustfs/zerofs-demo/ -r | head -4 @@ -130,45 +130,45 @@ zerofs-data/manifest/0000000000000000.json zerofs-data/wal/00000000000000000001.sst ``` -Files are not stored 1:1 — they are keys and values inside the LSM tree, which is what lets ZeroFS serve a bucket as a filesystem. +ファイルは 1 対 1 では保存されません。LSM ツリー内のキーと値として保存されるため、ZeroFS はバケットをファイルシステムとして提供できます。 -![ZeroFS LSM data stored in the RustFS Console](./images/rustfs-zerofs-data.png) +![RustFS Console に保存された ZeroFS の LSM データ](./images/rustfs-zerofs-data.png) -## 5. Stop or reset +## 5. 停止またはリセットする -To tear down the demo while keeping the bucket objects: +バケット内のオブジェクトを残したまま、デモを解体します。 ```bash umount /mnt/zerofs docker rm -f zerofs ``` -To delete the stored data (this erases the filesystem itself): +保存データを削除します（ファイルシステム自体が消去されます）。 ```bash rc rm rustfs/zerofs-demo/ --recursive --force ``` -## Troubleshooting +## トラブルシューティング -### `Failed to parse config file: missing field uid` at `[servers.webui]` +### `[servers.webui]` で `Failed to parse config file: missing field uid` になる -ZeroFS v2.3.5 requires `uid` and `gid` in the `[servers.webui]` section when it is present. Either add `uid = 1000` and `gid = 1000` or delete the section entirely if you do not need the Web UI. +ZeroFS v2.3.5 では、`[servers.webui]` セクションがある場合に `uid` と `gid` が必要です。`uid = 1000` と `gid = 1000` を追加するか、Web UI が不要ならセクションごと削除します。 -### `Permission denied` creating the cache directory +### キャッシュディレクトリの作成時に `Permission denied` になる -The container runs as UID 1001. After mounting the cache volume, run `chown -R 1001:1001 ` before starting the container. +コンテナは UID 1001 で動作します。キャッシュボリュームをマウントしたあと、コンテナを起動する前に `chown -R 1001:1001 ` を実行します。 -### Mount fails or hangs +### マウントが失敗する、またはハングする -Confirm the NFS client package is installed (`nfs-common`) and that ZeroFS is listening on `0.0.0.0:2049` inside a network your client can reach. The `port=2049,mountport=2049` options matter because ZeroFS serves the mountd traffic on the same port. +NFS クライアントパッケージ（`nfs-common`）がインストールされていること、およびクライアントから到達できるネットワークで ZeroFS が `0.0.0.0:2049` を待ち受けていることを確認します。`port=2049,mountport=2049` が重要なのは、ZeroFS が mountd のトラフィックを同じポートで提供するためです。 -### Writes vanish after a container crash +### コンテナのクラッシュ後に書き込みが消える -ZeroFS buffers writes and flushes periodically. For the demo, run `docker exec zerofs zerofs flush -c /zerofs.toml`; in production, clients that need strict durability should fsync (or use the 9P mount, whose fsync waits for stable storage). +ZeroFS は書き込みをバッファし、定期的にフラッシュします。デモでは `docker exec zerofs zerofs flush -c /zerofs.toml` を実行します。本番で厳密な耐久性が必要なクライアントには、fsync、または fsync が安定したストレージへの書き込み完了を待つ 9P マウントを推奨します。 -## Next steps +## 次のステップ -- Review [S3 compatibility notes](/administration/protocols/s3) before adopting additional ZeroFS backends. -- Create dedicated production credentials with [Access Key Management](/security-compliance/iam/access-token). -- Follow the [ZeroFS configuration guide](https://www.zerofs.net/configuration) for cache sizing, 9P/NBD serving, and high-availability replication over the same bucket. +- ほかの ZeroFS バックエンドを採用する前に、[S3 互換性に関する注意](/ja/administration/protocols/s3)を確認します。 +- [アクセスキーの管理](/ja/security-compliance/iam/access-token)で、本番用の専用認証情報を作成します。 +- キャッシュサイズ、9P/NBD の提供、同じバケット上の高可用性レプリケーションについては、[ZeroFS の設定ガイド](https://www.zerofs.net/configuration)に従います。 diff --git a/content/ja/developer/license.md b/content/ja/developer/license.md index f2910342b..9075835e4 100644 --- a/content/ja/developer/license.md +++ b/content/ja/developer/license.md @@ -1,203 +1,96 @@ --- -title: RustFS Open Source License -description: RustFS is released under the Apache 2.0 license. +title: RustFS オープンソースライセンス +description: RustFS は Apache 2.0 ライセンスの下でリリースされています。 --- -## Open Source License +## オープンソースライセンス -- RustFS is released under the Apache 2.0 license. +- RustFS は Apache 2.0 ライセンスの下でリリースされています。 - [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0) -## License Terms +## ライセンス条項 -_Version 2.0, January 2004_ +_バージョン 2.0、2004年1月_ http://www.apache.org/licenses/ -### Terms and Conditions for use, reproduction, and distribution - -#### Definitions - -"License" shall mean the terms and conditions for use, reproduction, and -distribution as defined by Sections 1 through 9 of this document. - -"Licensor" shall mean the copyright owner or entity authorized by the copyright -owner that is granting the License. - -"Legal Entity" shall mean the union of the acting entity and all other entities -that control, are controlled by, or are under common control with that entity. -For the purposes of this definition, "control" means **(i)** the power, direct or -indirect, to cause the direction or management of such entity, whether by -contract or otherwise, or **(ii)** ownership of fifty percent (50%) or more of the -outstanding shares, or **(iii)** beneficial ownership of such entity. - -"You" (or "Your") shall mean an individual or Legal Entity exercising -permissions granted by this License. - -"Source" form shall mean the preferred form for making modifications, including -but not limited to software source code, documentation source, and configuration -files. - -"Object" form shall mean any form resulting from mechanical transformation or -translation of a Source form, including but not limited to compiled object code, -generated documentation, and conversions to other media types. - -"Work" shall mean the work of authorship, whether in Source or Object form, made -available under the License, as indicated by a copyright notice that is included -in or attached to the work (an example is provided in the Appendix below). - -"Derivative Works" shall mean any work, whether in Source or Object form, that -is based on (or derived from) the Work and for which the editorial revisions, -annotations, elaborations, or other modifications represent, as a whole, an -original work of authorship. For the purposes of this License, Derivative Works -shall not include works that remain separable from, or merely link (or bind by -name) to the interfaces of, the Work and Derivative Works thereof. - -"Contribution" shall mean any work of authorship, including the original version -of the Work and any modifications or additions to that Work or Derivative Works -thereof, that is intentionally submitted to Licensor for inclusion in the Work -by the copyright owner or by an individual or Legal Entity authorized to submit -on behalf of the copyright owner. For the purposes of this definition, -"submitted" means any form of electronic, verbal, or written communication sent -to the Licensor or its representatives, including but not limited to -communication on electronic mailing lists, source code control systems, and -issue tracking systems that are managed by, or on behalf of, the Licensor for -the purpose of discussing and improving the Work, but excluding communication -that is conspicuously marked or otherwise designated in writing by the copyright -owner as "Not a Contribution." - -"Contributor" shall mean Licensor and any individual or Legal Entity on behalf -of whom a Contribution has been received by Licensor and subsequently -incorporated within the Work. - -#### Grant of Copyright License - -Subject to the terms and conditions of this License, each Contributor hereby -grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, -irrevocable copyright license to reproduce, prepare Derivative Works of, -publicly display, publicly perform, sublicense, and distribute the Work and such -Derivative Works in Source or Object form. - -#### Grant of Patent License - -Subject to the terms and conditions of this License, each Contributor hereby -grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, -irrevocable (except as stated in this section) patent license to make, have -made, use, offer to sell, sell, import, and otherwise transfer the Work, where -such license applies only to those patent claims licensable by such Contributor -that are necessarily infringed by their Contribution(s) alone or by combination -of their Contribution(s) with the Work to which such Contribution(s) was -submitted. If You institute patent litigation against any entity (including a -cross-claim or counterclaim in a lawsuit) alleging that the Work or a -Contribution incorporated within the Work constitutes direct or contributory -patent infringement, then any patent licenses granted to You under this License -for that Work shall terminate as of the date such litigation is filed. - -#### Redistribution - -You may reproduce and distribute copies of the Work or Derivative Works thereof -in any medium, with or without modifications, and in Source or Object form, -provided that You meet the following conditions: - -* **(a)** You must give any other recipients of the Work or Derivative Works a copy of -this License; and -* **(b)** You must cause any modified files to carry prominent notices stating that You -changed the files; and -* **(c)** You must retain, in the Source form of any Derivative Works that You distribute, -all copyright, patent, trademark, and attribution notices from the Source form -of the Work, excluding those notices that do not pertain to any part of the -Derivative Works; and -* **(d)** If the Work includes a "NOTICE" text file as part of its distribution, then any -Derivative Works that You distribute must include a readable copy of the -attribution notices contained within such NOTICE file, excluding those notices -that do not pertain to any part of the Derivative Works, in at least one of the -following places: within a NOTICE text file distributed as part of the -Derivative Works; within the Source form or documentation, if provided along -with the Derivative Works; or, within a display generated by the Derivative -Works, if and wherever such third-party notices normally appear. The contents of -the NOTICE file are for informational purposes only and do not modify the -License. You may add Your own attribution notices within Derivative Works that -You distribute, alongside or as an addendum to the NOTICE text from the Work, -provided that such additional attribution notices cannot be construed as -modifying the License. - -You may add Your own copyright statement to Your modifications and may provide -additional or different license terms and conditions for use, reproduction, or -distribution of Your modifications, or for any such Derivative Works as a whole, -provided Your use, reproduction, and distribution of the Work otherwise complies -with the conditions stated in this License. - -#### Submission of Contributions - -Unless You explicitly state otherwise, any Contribution intentionally submitted -for inclusion in the Work by You to the Licensor shall be under the terms and -conditions of this License, without any additional terms or conditions. -Notwithstanding the above, nothing herein shall supersede or modify the terms of -any separate license agreement you may have executed with Licensor regarding -such Contributions. - -#### Trademarks - -This License does not grant permission to use the trade names, trademarks, -service marks, or product names of the Licensor, except as required for -reasonable and customary use in describing the origin of the Work and -reproducing the content of the NOTICE file. - -#### Disclaimer of Warranty - -Unless required by applicable law or agreed to in writing, Licensor provides the -Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, -including, without limitation, any warranties or conditions of TITLE, -NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are -solely responsible for determining the appropriateness of using or -redistributing the Work and assume any risks associated with Your exercise of -permissions under this License. - -#### Limitation of Liability - -In no event and under no legal theory, whether in tort (including negligence), -contract, or otherwise, unless required by applicable law (such as deliberate -and grossly negligent acts) or agreed to in writing, shall any Contributor be -liable to You for damages, including any direct, indirect, special, incidental, -or consequential damages of any character arising as a result of this License or -out of the use or inability to use the Work (including but not limited to -damages for loss of goodwill, work stoppage, computer failure or malfunction, or -any and all other commercial damages or losses), even if such Contributor has -been advised of the possibility of such damages. - -#### Accepting Warranty or Additional Liability - -While redistributing the Work or Derivative Works thereof, You may choose to -offer, and charge a fee for, acceptance of support, warranty, indemnity, or -other liability obligations and/or rights consistent with this License. However, -in accepting such obligations, You may act only on Your own behalf and on Your -sole responsibility, not on behalf of any other Contributor, and only if You -agree to indemnify, defend, and hold each Contributor harmless for any liability -incurred by, or claims asserted against, such Contributor by reason of your -accepting any such warranty or additional liability. - -_END OF TERMS AND CONDITIONS_ - -### APPENDIX: How to apply the Apache License to your work - -To apply the Apache License to your work, attach the following boilerplate -notice, with the fields enclosed by brackets `[]` replaced with your own -identifying information. (Don't include the brackets!) The text should be -enclosed in the appropriate comment syntax for the file format. We also -recommend that a file or class name and description of purpose be included on -the same "printed page" as the copyright notice for easier identification within -third-party archives. +### 使用、複製、および頒布に関する条項および条件 + +#### 定義 + +「ライセンス」とは、本文書の第 1 条から第 9 条までに定義される、使用、複製、および頒布に関する条項および条件を意味します。 + +「ライセンサー」とは、著作権所有者、またはライセンスを付与する権限を著作権所有者から与えられた団体を意味します。 + +「法人」とは、行為を行う団体と、その団体を支配し、その団体に支配され、またはその団体と共通の支配下にある他のすべての団体との結合を意味します。この定義において「支配」とは、**(i)** 契約その他の方法により、直接または間接に、当該団体の指揮または経営を行わせる権限、または **(ii)** 発行済株式の 50 パーセント（50%）以上の所有、または **(iii)** 当該団体の受益所有を意味します。 + +「あなた」（または「あなたの」）とは、このライセンスにより付与された許諾を行使する個人または法人を意味します。 + +「ソース」形式とは、修正を加えるための好ましい形式を意味し、ソフトウェアのソースコード、ドキュメントのソース、および設定ファイルを含みますが、これらに限定されません。 + +「オブジェクト」形式とは、ソース形式を機械的に変換または翻訳した結果生じるあらゆる形式を意味し、コンパイルされたオブジェクトコード、生成されたドキュメント、および他のメディア種別への変換を含みますが、これらに限定されません。 + +「作品」とは、ソース形式かオブジェクト形式かを問わず、ライセンスの下で利用可能にされた著作物であって、作品に含まれるか作品に添付された著作権表示により示されるものを意味します（例は下記の付録にあります）。 + +「派生物」とは、ソース形式かオブジェクト形式かを問わず、作品に基づく（または作品から派生した）著作物であって、編集上の改訂、注釈、加筆、またはその他の修正が、全体として独自の著作物を構成するものを意味します。このライセンスにおいて、派生物には、作品およびその派生物から分離したままである著作物、または作品およびその派生物のインターフェースに単にリンクする（もしくは名前により結合する）だけの著作物は含まれません。 + +「コントリビューション」とは、作品の原版、ならびに当該作品またはその派生物に対する修正または追加を含む著作物であって、著作権所有者、または著作権所有者に代わって提出する権限を与えられた個人もしくは法人が、作品に含めることを意図してライセンサーに意図的に提出したものを意味します。この定義において「提出」とは、ライセンサーまたはその代表者に送られる、電子的、口頭、または書面によるあらゆる形式の通信を意味します。これには、作品を議論し改善する目的で、ライセンサーにより、またはライセンサーのために管理される電子メーリングリスト、ソースコード管理システム、および課題追跡システム上の通信を含みますが、これらに限定されません。ただし、著作権所有者が「Not a Contribution」と顕著に表示するか、または書面でそのように指定した通信は除きます。 + +「コントリビューター」とは、ライセンサー、および、その者に代わってライセンサーがコントリビューションを受領し、その後作品に組み込んだ個人または法人を意味します。 + +#### 著作権ライセンスの付与 + +このライセンスの条項および条件に従うことを前提として、各コントリビューターは、あなたに対し、作品および当該派生物をソース形式またはオブジェクト形式で複製し、派生物を作成し、公に展示し、公に実演し、サブライセンスし、および頒布するための、永続的、全世界的、非独占的、無償、使用料無料、かつ取消不能の著作権ライセンスを、ここに付与します。 + +#### 特許ライセンスの付与 + +このライセンスの条項および条件に従うことを前提として、各コントリビューターは、あなたに対し、作品を製造し、製造させ、使用し、販売の申出をし、販売し、輸入し、およびその他の方法で移転するための、永続的、全世界的、非独占的、無償、使用料無料、かつ取消不能（この節に定める場合を除きます）の特許ライセンスを、ここに付与します。このライセンスは、当該コントリビューターがライセンスできる特許クレームのうち、そのコントリビューションのみによって、またはそのコントリビューションと、当該コントリビューションが提出された作品との組み合わせによって、必然的に侵害されるものにのみ適用されます。あなたがいずれかの団体に対し、作品または作品に組み込まれたコントリビューションが直接の特許侵害または寄与による特許侵害を構成すると主張して、特許訴訟（訴訟における交差請求または反訴を含みます）を提起した場合、このライセンスに基づき当該作品についてあなたに付与された特許ライセンスは、当該訴訟が提起された日に終了します。 + +#### 再頒布 + +あなたは、改変の有無を問わず、ソース形式またはオブジェクト形式で、いかなる媒体によっても、作品またはその派生物の複製を作成し、頒布できます。ただし、次の条件を満たす必要があります。 + +* **(a)** 作品または派生物の他の受領者に、このライセンスの複製を渡す必要があります。かつ +* **(b)** 改変したファイルには、あなたが当該ファイルを変更したことを述べる顕著な通知を記載する必要があります。かつ +* **(c)** あなたが頒布する派生物のソース形式には、作品のソース形式にある著作権、特許、商標、および帰属に関する表示のすべてを、派生物のいずれの部分にも関係しない表示を除いて、保持する必要があります。かつ +* **(d)** 作品の頒布物の一部として「NOTICE」テキストファイルが含まれる場合、あなたが頒布する派生物には、当該 NOTICE ファイルに含まれる帰属表示のうち、派生物のいずれの部分にも関係しないものを除いた、読み取ることのできる複製を、次の少なくとも 1 箇所に含める必要があります。すなわち、派生物の一部として頒布する NOTICE テキストファイルの中、派生物とともに提供される場合はそのソース形式またはドキュメントの中、または、そのような第三者の表示が通常表示される場合には、通常表示されるその場所にある、派生物が生成する表示の中です。NOTICE ファイルの内容は、情報提供のみを目的とし、ライセンスを変更しません。あなたは、頒布する派生物の中に、作品の NOTICE テキストと並べて、またはその補遺として、自身の帰属表示を追加できます。ただし、その追加の帰属表示が、ライセンスを変更するものと解釈できないことが条件です。 + +あなたは、自身の改変物に自身の著作権表示を追加でき、また、自身の改変物の使用、複製、もしくは頒布について、または当該派生物の全体について、追加の、または異なるライセンスの条項および条件を定めることができます。ただし、作品についてのあなたの使用、複製、および頒布が、その他の点でこのライセンスに記載された条件に従っていることが条件です。 + +#### コントリビューションの提出 + +あなたが明示的に別段の定めをしない限り、あなたが作品に含めることを意図してライセンサーに提出したコントリビューションは、追加の条項または条件を伴わず、このライセンスの条項および条件に従います。上記にかかわらず、本文書のいかなる規定も、当該コントリビューションについてあなたがライセンサーとの間で締結していることがある別個のライセンス契約の条項に、優先せず、またこれを変更しません。 + +#### 商標 + +このライセンスは、作品の出所を説明するとき、および NOTICE ファイルの内容を複製するときに合理的かつ慣行的に必要となる使用を除き、ライセンサーの商号、商標、サービスマーク、または製品名を使用する許諾を与えません。 + +#### 保証の否認 + +適用される法令により要求される場合、または書面により合意した場合を除き、ライセンサーは作品を（そして各コントリビューターは自身のコントリビューションを）、明示であると黙示であるとを問わず、権原（TITLE）、非侵害（NON-INFRINGEMENT）、商品性（MERCHANTABILITY）、もしくは特定目的適合性（FITNESS FOR A PARTICULAR PURPOSE）に関するものを含め、いかなる種類の保証も条件も伴わない「現状有姿」（AS IS）で提供します。作品を使用または再頒布することが適切であるかを判断する責任はあなたのみが負い、このライセンスに基づく許諾の行使に伴うリスクはあなたが引き受けます。 + +#### 責任の制限 + +いかなる場合においても、また不法行為（過失を含みます）、契約、またはその他のいずれの法理論においても、適用される法令により要求される場合（故意および重過失による行為など）、または書面により合意した場合を除き、コントリビューターは、このライセンスに起因し、または作品の使用もしくは使用不能から生じる損害について、あなたに対して責任を負いません。この損害には、直接、間接、特別、付随的、または結果的な、いかなる性質の損害も含まれます（営業権の喪失、業務の停止、コンピューターの故障もしくは誤動作、またはその他一切の商業上の損害もしくは損失に対する損害を含みますが、これらに限定されません）。当該コントリビューターがそのような損害の可能性を知らされていた場合であっても、同様です。 + +#### 保証または追加責任の引き受け + +作品またはその派生物を再頒布するにあたり、あなたは、このライセンスに整合するサポート、保証、補償、もしくはその他の責任に関する義務、および／または権利の引き受けを申し出、その対価を請求することを選べます。ただし、そのような義務を引き受ける場合、あなたは自己のために、かつ自己の単独の責任においてのみ行為でき、他のコントリビューターのために行為することはできません。また、あなたが当該の保証または追加の責任を引き受けたことを理由として、当該コントリビューターに生じた責任、または当該コントリビューターに対して主張された請求について、各コントリビューターを補償し、防御し、かつ免責することに、あなたが同意する場合に限ります。 + +_条項および条件の終わり_ + +### 付録: 作品に Apache ライセンスを適用する方法 + +作品に Apache ライセンスを適用するには、次の定型通知を添付し、角括弧 `[]` で囲まれた欄を、自身を特定する情報に置き換えます（括弧は含めないでください）。この文章は、ファイル形式に適したコメント構文で囲むことを推奨します。また、第三者のアーカイブ内で識別しやすくするため、ファイル名またはクラス名と目的の説明を、著作権表示と同じ「印刷ページ」に含めることを推奨します。 Copyright 2024-2026 RustFS, Inc. - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at + このファイルは、Apache License, Version 2.0（以下「ライセンス」）の下でライセンスされています。 + ライセンスに従う場合を除き、このファイルを使用することはできません。 + ライセンスの複製は、次の場所から入手できます。 http://www.apache.org/licenses/LICENSE-2.0 - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. + 適用される法令により要求される場合、または書面により合意した場合を除き、 + ライセンスの下で頒布されるソフトウェアは、「現状有姿」（AS IS）で頒布され、 + 明示であると黙示であるとを問わず、いかなる種類の保証も条件も伴いません。 + ライセンスに基づく許諾および制限を定める具体的な文言については、ライセンスを参照してください。 diff --git a/content/ja/developer/mcp.md b/content/ja/developer/mcp.md index fd997b019..d00dde9d8 100644 --- a/content/ja/developer/mcp.md +++ b/content/ja/developer/mcp.md @@ -1,38 +1,38 @@ --- -title: "RustFS MCP" -description: "RustFS MCP Usage Guide" +title: "RustFS MCP サーバー" +description: "RustFS MCP サーバーで、AI アシスタントを RustFS のオブジェクトストレージに接続します。" --- -**RustFS MCP Server** is a high-performance [Model Context Protocol (MCP)](https://www.anthropic.com/news/model-context-protocol) server that provides AI/LLM tools with seamless access to S3-compatible object storage operations. Built with Rust for performance and security, it enables AI assistants like Claude Desktop to interact with cloud storage through standardized protocols. +**RustFS MCP Server** は、[Model Context Protocol (MCP)](https://www.anthropic.com/news/model-context-protocol) のサーバーです。Claude Desktop などの AI アシスタントに、S3 互換のオブジェクトストレージへのアクセスを提供します。 -### What is MCP? +### MCP とは -The Model Context Protocol is an open standard that enables AI applications to establish secure, controlled connections with external systems. This server acts as a bridge between AI tools and S3-compatible storage services, providing structured access to file operations while maintaining security and observability. +Model Context Protocol は、AI アプリケーションが外部システムとの間に、安全で制御された接続を確立するためのオープン標準です。このサーバーは AI ツールと S3 互換ストレージサービスをつなぎ、セキュリティとオブザーバビリティを保ったまま、ファイル操作を構造化された形で提供します。 -## ✨ Features +## 機能 -### Supported S3 Operations +### 対応する S3 操作 -- **List Buckets**: Lists all accessible S3 buckets. -- **List Objects**: Browses bucket contents with optional prefix filtering. -- **Upload Files**: Uploads local files with automatic MIME type detection and cache control. -- **Get Objects**: Retrieves objects from S3 storage, supporting read or download modes. +- **バケットの一覧**: アクセスできる S3 バケットをすべて列挙します。 +- **オブジェクトの一覧**: 任意のプレフィックスで絞り込みながら、バケットの内容を参照します。 +- **ファイルのアップロード**: MIME タイプの自動判定とキャッシュ制御を使って、ローカルファイルをアップロードします。 +- **オブジェクトの取得**: S3 ストレージからオブジェクトを取得します。読み取りとダウンロードの両モードに対応します。 -## 🔧 Installation +## インストール -:::warning[Build instructions may be outdated] +:::warning[ビルド手順が古い可能性があります] -The `rustfs-mcp` crate is no longer part of the current `rustfs/rustfs` main branch, so the build commands below may fail against a fresh clone. Check the [RustFS GitHub organization](https://github.com/rustfs) for the MCP server's current location before building from source. +`rustfs-mcp` クレートは、現在の `rustfs/rustfs` の main ブランチには含まれていません。そのため、新しいクローンに対して以下のビルドコマンドは失敗することがあります。ソースからビルドする前に、[RustFS の GitHub 組織](https://github.com/rustfs) で MCP サーバーの現在の場所を確認します。 ::: -### Prerequisites +### 前提条件 -- Rust 1.75+ (for building from source) -- Configured AWS credentials (via environment variables, AWS CLI, or IAM roles) -- Access to S3-compatible storage services +- Rust 1.75 以降（ソースからビルドする場合） +- 設定済みの AWS 認証情報（環境変数、AWS CLI、または IAM ロール） +- S3 互換のストレージサービスへのアクセス -### Building from Source +### ソースからのビルド ```bash # Clone the repository @@ -46,9 +46,9 @@ cargo build --release -p rustfs-mcp ./target/release/rustfs-mcp ``` -## ⚙️ Configuration +## 設定 -### Environment Variables +### 環境変数 ```bash # AWS credentials (required) @@ -63,23 +63,23 @@ export AWS_ENDPOINT_URL=http://localhost:9000 export RUST_LOG=info ``` -### Command Line Options +### コマンドラインオプション ```bash rustfs-mcp --help ``` -The server supports various command line options to customize behavior: +サーバーは、動作をカスタマイズする複数のコマンドラインオプションに対応しています。 -- `--access-key-id`: AWS access key ID for S3 authentication -- `--secret-access-key`: AWS secret key for S3 authentication -- `--region`: AWS region for S3 operations (default: us-east-1) -- `--endpoint-url`: Custom S3 endpoint URL (for MinIO, LocalStack, etc.) -- `--log-level`: Log level configuration (default: rustfs_mcp_server=info) +- `--access-key-id`: S3 認証に使う AWS のアクセスキー ID +- `--secret-access-key`: S3 認証に使う AWS のシークレットキー +- `--region`: S3 操作に使う AWS リージョン（既定: us-east-1） +- `--endpoint-url`: カスタムの S3 エンドポイント URL（MinIO や LocalStack など） +- `--log-level`: ログレベルの設定（既定: rustfs_mcp_server=info） -## 🚀 Usage +## 使い方 -### Starting the Server +### サーバーの起動 ```bash # Start the MCP server @@ -89,9 +89,9 @@ rustfs-mcp rustfs-mcp --log-level debug --region us-west-2 ``` -### Integration with Chat Clients +### チャットクライアントとの連携 -#### Option 1: Using Command Line Arguments +#### 方法 1: コマンドライン引数を使う ```json { @@ -109,7 +109,7 @@ rustfs-mcp --log-level debug --region us-west-2 } ``` -#### Option 2: Using Environment Variables +#### 方法 2: 環境変数を使う ```json { @@ -126,9 +126,9 @@ rustfs-mcp --log-level debug --region us-west-2 } ``` -### Using with Docker +### Docker で使う -[RustFS MCP officially provides a Dockerfile](https://github.com/rustfs/rustfs/tree/main/crates/mcp) that can be used to build container images for using RustFS MCP. +コンテナイメージのビルドには、RustFS MCP の[公式 Dockerfile](https://github.com/rustfs/rustfs/tree/main/crates/mcp) を使えます。 ```bash # Clone RustFS repository code @@ -138,11 +138,11 @@ git clone https://github.com/rustfs/rustfs.git docker build -f crates/mcp/Dockerfile -t rustfs/rustfs-mcp . ``` -After successful build, you can configure it in the MCP configuration of AI IDEs. +ビルドが成功したら、IDE の MCP 設定にサーバーを追加します。 -#### Configuring MCP in AI IDEs +#### AI IDE での MCP 設定 -Currently, mainstream AI IDEs such as Cursor, Windsurf, Trae, etc. all support MCP. For example, in Trae, add the following content to the MCP configuration (**MCP --> Add**): +Cursor、Windsurf、Trae など、多くの AI IDE が MCP に対応しています。たとえば Trae では、MCP 設定の **MCP --> Add**（追加）に次の内容を追加します。 ```json { @@ -174,88 +174,88 @@ Currently, mainstream AI IDEs such as Cursor, Windsurf, Trae, etc. all support M } ``` -> `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are RustFS access keys. You can refer to the [Access Key Management chapter](../security-compliance/iam/access-token.md) for creation. +> `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` は、RustFS のアクセスキーです。作成方法は[アクセスキーの管理](../security-compliance/iam/access-token.md)を参照します。 -If added successfully, you can list the [available tools](#️-available-tools) on the MCP configuration page. +サーバーの追加に成功すると、MCP の設定ページに[利用できるツール](#available-tools)が一覧表示されます。 -![add rustfs mcp in trae mcp configuration successfully](images/add-rustfs-mcp-succ.png) +![Trae の MCP 設定に追加された RustFS MCP サーバー](images/add-rustfs-mcp-succ.png) -In Trae, you can use the corresponding tools by entering the corresponding prompts. For example, in Trae's chat dialog, enter: +Trae で MCP ツールを呼び出すには、チャットにプロンプトを入力します。例: ```text Please help me list the buckets in the current rustfs instance, thank you! ``` -Returns the following response: +Trae は次の応答を返します。 -![list rustfs bucket with rustfs mcp](images/list-rustfs-bucket-with-mcp.png) +![RustFS MCP でバケットを一覧した画面](images/list-rustfs-bucket-with-mcp.png) -Trae uses **Builder with MCP** mode, calling the `list_buckets` tool to list all buckets in the configured RustFS instance. The same applies to calls to other tools. +Trae は **Builder with MCP**（MCP を使うビルダー）モードで `list_buckets` ツールを呼び出し、設定済みの RustFS インスタンスにあるバケットをすべて列挙します。他のツールも同じように動作します。 -## 🛠️ Available Tools +## 利用できるツール [#available-tools] -The MCP server exposes the following tools that AI assistants can use: +MCP サーバーは、AI アシスタントが使える次のツールを公開します。 ### `list_buckets` -Lists all S3 buckets accessible with the configured credentials. +設定済みの認証情報でアクセスできる S3 バケットをすべて列挙します。 -**Parameters**: None +**パラメータ**: なし ### `list_objects` -Lists objects in an S3 bucket with optional prefix filtering. +任意のプレフィックスで絞り込みながら、S3 バケット内のオブジェクトを列挙します。 -**Parameters**: +**パラメータ**: -- `bucket_name` (string): Name of the S3 bucket -- `prefix` (string, optional): Prefix for filtering objects +- `bucket_name` (string): S3 バケットの名前 +- `prefix` (string, optional): オブジェクトを絞り込むプレフィックス ### `upload_file` -Uploads a local file to S3 with automatic MIME type detection. +MIME タイプを自動判定して、ローカルファイルを S3 にアップロードします。 -**Parameters**: +**パラメータ**: -- `local_file_path` (string): Local file path -- `bucket_name` (string): Target S3 bucket -- `object_key` (string): S3 object key (target path) -- `content_type` (string, optional): Content type (auto-detected if not provided) -- `storage_class` (string, optional): S3 storage class -- `cache_control` (string, optional): Cache control header +- `local_file_path` (string): ローカルファイルのパス +- `bucket_name` (string): アップロード先の S3 バケット +- `object_key` (string): S3 オブジェクトキー（保存先のパス） +- `content_type` (string, optional): コンテンツタイプ（未指定の場合は自動判定） +- `storage_class` (string, optional): S3 ストレージクラス +- `cache_control` (string, optional): Cache-Control ヘッダー ### `get_object` -Retrieves objects from S3 with two operation modes: direct content reading or download to file. +S3 からオブジェクトを取得します。内容を直接読むモードと、ファイルへダウンロードするモードがあります。 -**Parameters**: +**パラメータ**: -- `bucket_name` (string): Source S3 bucket -- `object_key` (string): S3 object key -- `version_id` (string, optional): Version ID for versioned objects -- `mode` (string, optional): Operation mode - "read" (default) returns content directly, "download" saves to local file -- `local_path` (string, optional): Local file path (required when mode is "download") -- `max_content_size` (number, optional): Maximum content size for read mode in bytes (default: 1MB) +- `bucket_name` (string): 取得元の S3 バケット +- `object_key` (string): S3 オブジェクトキー +- `version_id` (string, optional): バージョニングされたオブジェクトのバージョン ID +- `mode` (string, optional): 操作モード。"read"（既定）は内容を直接返し、"download" はローカルファイルへ保存します +- `local_path` (string, optional): ローカルファイルのパス（mode が "download" の場合は必須です） +- `max_content_size` (number, optional): read モードで返す内容の最大サイズ。単位はバイト（既定: 1MB） ### `create_bucket` -Creates a new RustFS bucket. +新しい RustFS バケットを作成します。 -**Parameters**: +**パラメータ**: -- `bucket_name` (string): Name of the bucket to create. +- `bucket_name` (string): 作成するバケットの名前。 ### `delete_bucket` -Deletes the specified RustFS bucket. +指定した RustFS バケットを削除します。 -**Parameters**: +**パラメータ**: -- `bucket_name` (string): Name of the bucket to delete. +- `bucket_name` (string): 削除するバケットの名前。 -## Architecture +## アーキテクチャ -The MCP server is built with a modular architecture: +MCP サーバーは、モジュール構成で構築されています。 ```text rustfs-mcp/ diff --git a/content/ja/developer/sdk/go.md b/content/ja/developer/sdk/go.md index b40cab279..0035904d9 100644 --- a/content/ja/developer/sdk/go.md +++ b/content/ja/developer/sdk/go.md @@ -1,23 +1,23 @@ --- -title: "Golang SDK Guide" -description: "Use the AWS SDK for Go v2 to operate on RustFS instances, including creating and deleting buckets and objects." +title: "Golang" +description: "AWS SDK for Go v2 で RustFS インスタンスを操作し、バケットとオブジェクトの作成および削除を行います。" --- -RustFS ships no first-party Go SDK — it is fully S3-compatible, so you use the official AWS SDK for Go v2 configured to point at your RustFS server. Through the SDK, you can operate on RustFS, including creating and deleting buckets/objects, uploading and downloading files, etc. +RustFS は独自の Go SDK を提供していません。S3 互換であるため、公式の AWS SDK for Go v2 を、RustFS サーバーを指すように設定して使います。この SDK で、バケットの作成と削除、およびオブジェクトのアップロード、ダウンロード、削除ができます。 -## Prerequisites +## 前提条件 -- Go 1.21 or later -- A working RustFS instance (refer to [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001` -- Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (refer to [Access Key Management](../../security-compliance/iam/access-token.md)) +- Go 1.21 以降 +- 動作している RustFS インスタンス（[インストールガイド](../../installation/index.md)を参照）。S3 API はポート `9000`、Console はポート `9001` で待ち受けます +- インストール時に環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` で設定するアクセスキー（[アクセスキーの管理](../../security-compliance/iam/access-token.md)を参照） -:::tip[Local test] +:::tip[ローカル検証] -If you did not set credentials at install time, the server defaults to `rustfsadmin` / `rustfsadmin` — fine for a throwaway local trial, never for anything reachable by others. +インストール時に認証情報を設定しなかった場合、サーバーの既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル検証であれば問題ありませんが、外部から到達できる環境では使わないでください。 ::: -Install the SDK modules: +SDK モジュールをインストールします。 ```bash go mod init rustfs-go-demo @@ -26,9 +26,9 @@ go get github.com/aws/aws-sdk-go-v2/credentials go get github.com/aws/aws-sdk-go-v2/service/s3 ``` -## Initializing the Client +## クライアントの初期化 -The following is a complete, runnable program. It reads its configuration from environment variables and initializes the client from an `aws.Config`: +次のプログラムは、そのまま実行できます。環境変数から設定を読み取り、`aws.Config` でクライアントを初期化します。 ```go title="main.go" package main @@ -83,11 +83,11 @@ func main() { :::note -These environment variable names (`RUSTFS_ENDPOINT_URL`, `RUSTFS_REGION`, `RUSTFS_ACCESS_KEY_ID`, `RUSTFS_SECRET_ACCESS_KEY`) are just this example's client-side conventions — they are read by your Go program, not by RustFS. They are distinct from the server-side `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` variables used when installing RustFS. +これらの環境変数名（`RUSTFS_ENDPOINT_URL`、`RUSTFS_REGION`、`RUSTFS_ACCESS_KEY_ID`、`RUSTFS_SECRET_ACCESS_KEY`）は、この例だけのクライアント側の取り決めです。Go プログラムが読み取り、RustFS サーバーは参照しません。インストール時に使うサーバー側の `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` とは別の変数です。 ::: -Run it (replace `localhost` with your server's IP address if RustFS runs on another machine): +実行します（RustFS が別のマシンで動作している場合は、`localhost` をそのサーバーの IP アドレスに置き換えます）。 ```bash export RUSTFS_ENDPOINT_URL="http://localhost:9000" @@ -102,9 +102,9 @@ Buckets: - my-bucket ``` -You can now perform bucket and object operations. The snippets below run inside the `main` function above, reusing `client` and `ctx`. +これで、バケットとオブジェクトを操作できます。以下のコード片は、上の `main` 関数の中で、`client` と `ctx` を再利用して実行します。 -## Create Bucket +## バケットの作成 ```go _, err = client.CreateBucket(ctx, &s3.CreateBucketInput{ @@ -120,7 +120,7 @@ fmt.Println("bucket created") bucket created ``` -## List Buckets +## バケットの一覧 ```go resp, err := client.ListBuckets(ctx, &s3.ListBucketsInput{}) @@ -139,7 +139,7 @@ Buckets: - my-bucket ``` -## Delete Bucket +## バケットの削除 ```go _, err = client.DeleteBucket(ctx, &s3.DeleteBucketInput{ @@ -155,7 +155,7 @@ fmt.Println("bucket deleted") bucket deleted ``` -## List Objects +## オブジェクトの一覧 ```go resp, err := client.ListObjectsV2(ctx, &s3.ListObjectsV2Input{ @@ -173,9 +173,9 @@ for _, obj := range resp.Contents { - hello.txt ``` -## Upload Object +## オブジェクトのアップロード -Uploading a string body (add `"strings"` to your imports): +文字列をボディとしてアップロードします（import に `"strings"` を追加します）。 ```go _, err = client.PutObject(ctx, &s3.PutObjectInput{ @@ -193,9 +193,9 @@ fmt.Println("object uploaded") object uploaded ``` -## Download Object +## オブジェクトのダウンロード -Reading the object body (add `"io"` to your imports): +オブジェクトのボディを読み取ります（import に `"io"` を追加します）。 ```go resp, err := client.GetObject(ctx, &s3.GetObjectInput{ @@ -219,4 +219,4 @@ fmt.Println("content is :", string(data)) content is : hello rustfs ``` -For other operations (presigned URLs, multipart uploads, and more), see the [AWS SDK for Go v2 documentation](https://aws.github.io/aws-sdk-go-v2/docs/) — every S3-compatible call works against RustFS the same way. +署名付き URL、マルチパートアップロードなどの操作については、[AWS SDK for Go v2 のドキュメント](https://aws.github.io/aws-sdk-go-v2/docs/)を参照します。ほとんどの S3 操作は、RustFS に対しても同じように動作します。例外は [S3 互換性](/ja/reference/s3-compatibility) を参照します。 diff --git a/content/ja/developer/sdk/index.md b/content/ja/developer/sdk/index.md index f57b4164b..530fc5c7e 100644 --- a/content/ja/developer/sdk/index.md +++ b/content/ja/developer/sdk/index.md @@ -1,43 +1,41 @@ --- -title: "RustFS SDK Overview" -description: "Overview of supported S3 SDKs for RustFS." +title: "SDK" +description: "RustFS で使える S3 SDK の概要です。" --- -RustFS is a distributed object storage system fully compatible with the S3 protocol. Users can: +RustFS は、S3 互換 API を備えた分散オブジェクトストレージです。次の方法で操作できます。 -- Manage RustFS through the Console management interface. -- Manage RustFS through S3 clients. -- Implement object storage operations and management on the business side through SDKs. +- Console で RustFS を管理します。 +- S3 クライアントで RustFS を管理します。 +- S3 SDK を使い、アプリケーションからバケットとオブジェクトを管理します。 -Currently, the SDKs provided by RustFS include: +次のガイドでは、RustFS で S3 SDK を使う方法を説明します。 - [Java SDK](./java.md) - [JavaScript SDK](./javascript.md) - [Python SDK](./python.md) - [Rust SDK](./rust.md) - [TypeScript SDK](./typescript.md) -- [Golang SDK](./go.md) +- [Go SDK](./go.md) -## Terminology +## 用語 -Amazon S3 (Simple Storage Service) was the first widely adopted object storage service. Its API has become the de facto standard for object storage. In this documentation, "S3" refers to the protocol. +Amazon Simple Storage Service（Amazon S3）は、広く採用された最初のオブジェクトストレージサービスです。その API は、オブジェクトストレージにおける事実上の標準になっています。このドキュメントで「S3」は、プロトコルを指します。 -## SDK Recommendations +## SDK の推奨 -We recommend using the official AWS S3 SDKs. These SDKs are mature, well-maintained, and highly optimized. +公式の AWS S3 SDK の使用を推奨します。これらの SDK は成熟しており、保守が行き届き、高度に最適化されています。 -If you have a familiar and trusted SDK from a vendor, you can use it. +必要な S3 操作に対応していれば、知っていて信頼できるベンダー SDK も使えます。 -Some third-party SDKs may have non-standard implementations. We recommend avoiding SDKs that are not strictly S3-compliant. +一部のサードパーティ SDK は、標準から外れた実装になっていることがあります。厳密に S3 に準拠していない SDK は、避けることを推奨します。 -## Compatibility with MinIO SDKs +## MinIO SDK との互換性 -Yes, RustFS is fully compatible with MinIO SDKs. +RustFS は MinIO SDK で動作します。 -If you are using MinIO SDKs, you can modify the Endpoint, AK, and SK to be directly compatible with RustFS. +MinIO SDK を RustFS に接続するには、エンドポイント、アクセスキー、シークレットキーを、RustFS の値に設定します。 -## Handling Incompatible SDKs +## 非互換な SDK への対処 -If you encounter an SDK that does not support standard S3, MinIO, or RustFS: - -We recommend switching to a standard AWS S3 SDK. +SDK が標準の S3、MinIO、RustFS のいずれとも動作しない場合は、公式の AWS SDK for S3 へ切り替えることを推奨します。 diff --git a/content/ja/developer/sdk/java.md b/content/ja/developer/sdk/java.md index 938a7f166..b4df7d829 100644 --- a/content/ja/developer/sdk/java.md +++ b/content/ja/developer/sdk/java.md @@ -1,25 +1,25 @@ --- -title: "Java SDK Guide" -description: "Use the official AWS SDK for Java v2 with RustFS." +title: "Java" +description: "公式の AWS SDK for Java v2 を RustFS で使います。" --- -RustFS ships no first-party Java SDK — it is S3-compatible, so you use the official AWS SDK for Java v2 configured to point at your RustFS server. +RustFS は独自の Java SDK を提供していません。S3 互換であるため、公式の AWS SDK for Java v2 を、RustFS サーバーを指すように設定して使います。 -## 1. Prerequisites +## 1. 前提条件 -* Java 8 or later and Maven (or Gradle) -* A running RustFS instance (see the [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001` -* Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (see [Access Key Management](../../security-compliance/iam/access-token.md)) +* Java 8 以降と Maven（または Gradle） +* 稼働している RustFS インスタンス（[インストールガイド](../../installation/index.md)を参照）。S3 API はポート `9000`、Console はポート `9001` で待ち受けます +* インストール時に環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` で設定するアクセスキー（[アクセスキーの管理](../../security-compliance/iam/access-token.md)を参照） -:::tip[Local test] +:::tip[ローカル検証] -If you did not set credentials at install time, the server defaults to `rustfsadmin` / `rustfsadmin` — fine for a throwaway local trial, never for anything reachable by others. +インストール時に認証情報を設定しなかった場合、サーバーの既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル検証であれば問題ありませんが、外部から到達できる環境では使わないでください。 ::: -### 1.1 Maven Project Setup +### 1.1 Maven プロジェクトの準備 -Create a new Maven project: +新しい Maven プロジェクトを作成します。 ```text rustfs-java-s3-demo/ @@ -32,9 +32,9 @@ rustfs-java-s3-demo/ └── RustfsS3Example.java ``` -### 1.2 Add Dependencies +### 1.2 依存関係の追加 -Add AWS SDK dependencies in `pom.xml`: +`pom.xml` に AWS SDK の依存関係を追加します。 ```xml title="pom.xml" @@ -46,15 +46,15 @@ Add AWS SDK dependencies in `pom.xml`: ``` -> Recommend using AWS SDK v2, which has more complete features and supports async, reactive, and other patterns. +AWS SDK for Java v2 の使用を推奨します。機能が充実しており、非同期プログラミングとリアクティブプログラミングに対応しています。 --- -## 2. Connecting to RustFS +## 2. RustFS への接続 -### 2.1 Complete Example +### 2.1 完全な例 -The following class compiles and runs as-is. Replace `localhost` with your server's IP address if RustFS runs on another machine, and fill in your own access keys: +次のクラスは、そのままコンパイルして実行できます。RustFS が別のマシンで動作している場合は `localhost` をサーバーの IP アドレスに置き換え、アクセスキーも自分の値にします。 ```java title="RustfsS3Example.java" package com.example; @@ -121,7 +121,7 @@ public class RustfsS3Example { } ``` -Expected output: +想定される出力: ```text Bucket created: my-bucket @@ -133,55 +133,55 @@ Deleted hello.txt --- -## 3. Common Issues and Troubleshooting +## 3. トラブルシューティング -| Issue | Cause | Solution | -| -------------------------------------- | ------------------------------------ | ----------------------------------------- | -| `S3Exception: 301 Moved Permanently` | Path-style not enabled or region error | Set `.forcePathStyle(true)` and use region `us-east-1` | -| `ConnectException: Connection refused` | RustFS not started or incorrect port | Check RustFS status and port | -| `403 Forbidden` | AccessKey / SecretKey error | Check authentication configuration | -| Upload fails with no response | SDK defaults to HTTPS, RustFS only supports HTTP (or needs certificates) | Use `http://` address and configure `endpointOverride` | +| 問題 | 原因 | 対処 | +| --- | --- | --- | +| `S3Exception: 301 Moved Permanently` | パススタイルアクセスが有効でない、またはリージョンが誤っている | `.forcePathStyle(true)` を設定し、リージョンには `us-east-1` を使います | +| `ConnectException: Connection refused` | RustFS が起動していない、またはポートが誤っている | RustFS の状態とポートを確認します | +| `403 Forbidden` | アクセスキーまたはシークレットキーが誤っている | 認証情報を確認します | +| 応答がないままアップロードが失敗する | SDK の既定は HTTPS であり、RustFS は HTTP のみに対応している（HTTPS には証明書が必要） | `http://` のアドレスを使い、`endpointOverride` を設定します | --- -## 4. Appendix +## 4. 付録 -### 4.1 Maven Package and Run +### 4.1 Maven でのパッケージ化と実行 -Package project: +プロジェクトをパッケージ化します。 ```bash mvn clean package ``` -Execute: +実行します。 ```bash java -cp target/rustfs-java-s3-demo-1.0-SNAPSHOT.jar com.example.RustfsS3Example ``` -### 4.2 RustFS Configuration Recommendations +### 4.2 推奨する RustFS の設定 -* Ensure SSL validation is disabled when service uses HTTP protocol. -* Enable CORS support (if used for web frontend). -* Recommend setting limits like `max_object_size` and `max_part_size` to prevent large file transfer failures. +* RustFS が平文の HTTP で提供している場合は、SDK 側で TLS 証明書の検証を無効にします。 +* Web フロントエンドで使う場合は、CORS を有効にします。 +* 大きなファイルの転送失敗を防ぐため、`max_object_size` や `max_part_size` などの上限を設定することを推奨します。 --- -The following advanced examples cover: +応用例では、次の内容を扱います。 -* Presigned URL generation and usage -* Multipart Upload complete process +* 署名付き URL の生成と利用 +* マルチパートアップロードの一連の手順 --- -## 5. Java Advanced Features Examples +## 5. 応用例 -### 5.1 Generate and Use Presigned URLs +### 5.1 署名付き URL の生成と利用 -> Presigned URLs allow clients to temporarily access private objects without exposing credentials, widely used for browser direct upload or download file scenarios. +署名付き URL を使うと、認証情報を公開せずに、クライアントが非公開オブジェクトへ一時的にアクセスできます。ブラウザーからの直接アップロードやダウンロードでよく使います。 -#### 5.1.1 Generate Download Link (GET) +#### 5.1.1 ダウンロードリンクの生成（GET） ```java import software.amazon.awssdk.auth.credentials.AwsBasicCredentials; @@ -229,11 +229,11 @@ System.out.println("Presigned URL: " + presignedRequest.url()); Presigned URL: http://localhost:9000/my-bucket/hello.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&... ``` -> 🔗 Open the link in browser to access the object. +ブラウザーで URL を開くと、オブジェクトにアクセスできます。 -#### 5.1.2 Upload Presigned URL (PUT) +#### 5.1.2 アップロード用の署名付き URL（PUT） -Similarly, you can also generate upload URLs: +アップロード用の URL も生成できます。 ```java import software.amazon.awssdk.services.s3.model.PutObjectRequest; @@ -257,11 +257,11 @@ System.out.println("Upload URL: " + presignedPut.url()); --- -### 5.2 Implement Multipart Upload +### 5.2 マルチパートアップロードの実装 -> Multipart Upload is the recommended way for large file uploads, enabling resume from breakpoint during network fluctuations. +大きなファイルのアップロードには、マルチパートアップロードを推奨します。ネットワークが中断しても、アップロード全体をやり直さず、失敗したパートだけを再試行できます。 -The examples below reuse the `s3` client from section 2 and need these additional imports: +以下の例では、セクション 2 の `s3` クライアントを再利用します。次の import も必要です。 ```java import software.amazon.awssdk.services.s3.model.*; @@ -271,7 +271,7 @@ import java.util.ArrayList; import java.util.List; ``` -#### 5.2.1 Start Multipart Upload +#### 5.2.1 マルチパートアップロードの開始 ```java CreateMultipartUploadRequest createRequest = CreateMultipartUploadRequest.builder() @@ -283,7 +283,7 @@ CreateMultipartUploadResponse createResponse = s3.createMultipartUpload(createRe String uploadId = createResponse.uploadId(); ``` -#### 5.2.2 Upload Each Part +#### 5.2.2 各パートのアップロード ```java List completedParts = new ArrayList<>(); @@ -306,7 +306,7 @@ for (int i = 1; i <= 3; i++) { } ``` -#### 5.2.3 Complete Multipart Upload +#### 5.2.3 マルチパートアップロードの完了 ```java CompletedMultipartUpload completedUpload = CompletedMultipartUpload.builder() @@ -328,7 +328,7 @@ System.out.println("Multipart upload completed."); Multipart upload completed. ``` -#### 5.2.4 Abort Upload on Exception (Optional) +#### 5.2.4 例外時のアップロード中止（任意） ```java AbortMultipartUploadRequest abortRequest = AbortMultipartUploadRequest.builder() @@ -342,4 +342,4 @@ s3.abortMultipartUpload(abortRequest); --- -For other operations (object tagging, bucket policies, and more), see the [AWS SDK for Java v2 documentation](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/) — every S3-compatible call works against RustFS the same way. +オブジェクトのタグ付けやバケットポリシーなどの操作については、[AWS SDK for Java v2 のドキュメント](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/)を参照します。ほとんどの S3 操作は、RustFS に対しても同じように動作します。例外は [S3 互換性](/ja/reference/s3-compatibility) を参照します。 diff --git a/content/ja/developer/sdk/javascript.md b/content/ja/developer/sdk/javascript.md index f010b46fa..81cfe25ed 100644 --- a/content/ja/developer/sdk/javascript.md +++ b/content/ja/developer/sdk/javascript.md @@ -1,39 +1,39 @@ --- -title: "JavaScript SDK Guide" -description: "Use the official AWS SDK for JavaScript v3 with RustFS." +title: "JavaScript" +description: "公式の AWS SDK for JavaScript v3 を RustFS で使います。" --- -## I. Overview +## 概要 -RustFS ships no first-party JavaScript SDK — it is S3-compatible, so you use the official AWS SDK for JavaScript (v3) configured to point at your RustFS server. This guide shows how to connect to RustFS and perform common object storage operations. +RustFS は独自の JavaScript SDK を提供していません。S3 互換であるため、公式の AWS SDK for JavaScript（v3）を、RustFS サーバーを指すように設定して使います。このガイドでは、RustFS への接続と、オブジェクトストレージの一般的な操作を説明します。 -## II. Prerequisites +## 前提条件 -* Node.js 18 or later -* A running RustFS instance (see the [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001` -* Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (see [Access Key Management](../../security-compliance/iam/access-token.md)) +* Node.js 18 以降 +* 稼働している RustFS インスタンス（[インストールガイド](../../installation/index.md)を参照）。S3 API はポート `9000`、Console はポート `9001` で待ち受けます +* インストール時に環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` で設定するアクセスキー（[アクセスキーの管理](../../security-compliance/iam/access-token.md)を参照） -:::tip[Local test] +:::tip[ローカル検証] -If you did not set credentials at install time, the server defaults to `rustfsadmin` / `rustfsadmin` — fine for a throwaway local trial, never for anything reachable by others. +インストール時に認証情報を設定しなかった場合、サーバーの既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル検証であれば問題ありませんが、外部から到達できる環境では使わないでください。 ::: -### 2.1 SDK Installation +### SDK のインストール -Install the required AWS SDK v3 modules with NPM: +npm で、必要な AWS SDK v3 のモジュールをインストールします。 ```bash npm install @aws-sdk/client-s3 @aws-sdk/s3-request-presigner ``` -The examples below use ES modules (`import`). Set `"type": "module"` in your `package.json`, or save the files with the `.mjs` extension. +以下の例は ES modules（`import`）を使います。`package.json` に `"type": "module"` を設定するか、ファイルの拡張子を `.mjs` にします。 --- -## III. Initializing the Client +## クライアントの初期化 -The following is a complete, runnable script. Replace `localhost` with your server's IP address if RustFS runs on another machine, and fill in your own access keys: +次のスクリプトは、そのまま実行できます。RustFS が別のマシンで動作している場合は `localhost` をサーバーの IP アドレスに置き換え、アクセスキーも自分の値にします。 ```js title="main.mjs" import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3"; @@ -53,7 +53,7 @@ const { Buckets } = await s3.send(new ListBucketsCommand({})); console.log(Buckets?.map((b) => b.Name) ?? []); ``` -Run it: +実行します。 ```bash node main.mjs @@ -63,13 +63,13 @@ node main.mjs [ 'my-bucket' ] ``` -All snippets below reuse this `s3` client. +以下のコード片は、すべてこの `s3` クライアントを再利用します。 --- -## IV. Basic Operations +## 基本操作 -### 4.1 Create Bucket +### 4.1 バケットの作成 ```js import { CreateBucketCommand } from "@aws-sdk/client-s3"; @@ -84,7 +84,7 @@ Bucket created --- -### 4.2 Upload Object +### 4.2 オブジェクトのアップロード ```js import { PutObjectCommand } from "@aws-sdk/client-s3"; @@ -109,7 +109,7 @@ File uploaded --- -### 4.3 Download Object +### 4.3 オブジェクトのダウンロード ```js import { GetObjectCommand } from "@aws-sdk/client-s3"; @@ -137,7 +137,7 @@ File downloaded --- -### 4.4 List Objects +### 4.4 オブジェクトの一覧 ```js import { ListObjectsV2Command } from "@aws-sdk/client-s3"; @@ -152,7 +152,7 @@ hello.txt (12 bytes) --- -### 4.5 Delete Object +### 4.5 オブジェクトの削除 ```js import { DeleteObjectCommand } from "@aws-sdk/client-s3"; @@ -167,13 +167,13 @@ File deleted --- -## V. Advanced Features +## 高度な機能 -### 5.1 Generate Presigned URLs +### 5.1 署名付き URL の生成 -> Allows frontend or third parties to use temporary links for uploading/downloading files +署名付き URL を使うと、ブラウザーのクライアントや第三者が、一時的なリンク経由でオブジェクトをアップロードまたはダウンロードできます。 -#### Download (GET) +#### ダウンロード（GET） ```js import { GetObjectCommand } from "@aws-sdk/client-s3"; @@ -192,7 +192,7 @@ console.log("Presigned GET URL:", url); Presigned GET URL: http://localhost:9000/my-bucket/hello.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&... ``` -#### Upload (PUT) +#### アップロード（PUT） ```js import { PutObjectCommand } from "@aws-sdk/client-s3"; @@ -209,7 +209,7 @@ console.log("Presigned PUT URL:", url); --- -### 5.2 Multipart Upload +### 5.2 マルチパートアップロード ```js import { @@ -275,23 +275,23 @@ Multipart upload completed --- -## VI. Common Issues and Notes +## トラブルシューティング -| Problem | Cause | Solution | -| --------------------------- | -------------------- | --------------------------------------- | -| SignatureDoesNotMatch | Wrong signature version | JS SDK v3 uses v4 by default, ensure RustFS supports v4 | -| EndpointConnectionError | Endpoint address misconfigured or not started | Check if RustFS address is accessible | -| NoSuchKey | File does not exist | Check if `Key` is spelled correctly | -| InvalidAccessKeyId / Secret | Credentials misconfigured | Check `accessKeyId` / `secretAccessKey` configuration | -| Upload failure (path issue) | Path-style not enabled | Set `forcePathStyle: true` | +| 問題 | 原因 | 対処 | +| --- | --- | --- | +| SignatureDoesNotMatch | 署名の不一致 | SDK v3 は既定で SigV4 による署名を行います。認証情報、リージョン、エンドポイントを確認します | +| EndpointConnectionError | エンドポイントのアドレス設定が誤っているか、サービスが起動していない | RustFS のアドレスへ到達できるか確認します | +| NoSuchKey | オブジェクトが存在しない | `Key` の綴りが正しいか確認します | +| InvalidAccessKeyId / Secret | 認証情報の設定が誤っている | `accessKeyId` / `secretAccessKey` の設定を確認します | +| アップロードの失敗（パスの問題） | パススタイルアクセスが有効になっていない | `forcePathStyle: true` を設定します | --- -## VII. Appendix: Frontend Upload Adaptation +## 付録: ブラウザーからのアップロード -Using presigned URLs allows browsers to upload files directly without passing AccessKey. +署名付き URL を使うと、ブラウザーは認証情報を持たずにオブジェクトを直接アップロードできます。 -Frontend (HTML+JS) upload example: +フロントエンド（HTML と JS）のアップロード例: ```html @@ -312,4 +312,4 @@ Frontend (HTML+JS) upload example: ``` -For other operations (object tagging, bucket policies, and more), see the [AWS SDK for JavaScript v3 documentation](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/) — every S3-compatible call works against RustFS the same way. +オブジェクトのタグ付けやバケットポリシーなどの操作については、[AWS SDK for JavaScript v3 のドキュメント](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/)を参照します。ほとんどの S3 操作は、RustFS に対しても同じように動作します。例外は [S3 互換性](/ja/reference/s3-compatibility) を参照します。 diff --git a/content/ja/developer/sdk/other.md b/content/ja/developer/sdk/other.md index 4b4380965..7aa60b3a7 100644 --- a/content/ja/developer/sdk/other.md +++ b/content/ja/developer/sdk/other.md @@ -1,43 +1,43 @@ --- -title: "Other SDKs" -description: "This article mainly explains the usage of various other language SDKs in RustFS." +title: "その他の SDK" +description: "公式の AWS SDK がない言語から、RustFS へ接続する方法を説明します。" --- -If AWS S3 doesn't officially support your language, you can adopt the following strategies to integrate with RustFS: +使っている言語向けの公式 SDK を AWS が提供していない場合は、次のいずれかの方法で RustFS と連携できます。 -## 1. Use HTTP Interface Direct Requests (Based on S3 API Protocol) +## 1. S3 API へ HTTP リクエストを直接送る -The S3 protocol is a standard RESTful API. You can encapsulate access logic yourself using any language that supports HTTP requests (such as C, Rust, Lua, Erlang). +S3 プロトコルは、標準的な RESTful API です。HTTP リクエストを送れる言語（C、Rust、Lua、Erlang など）であれば、クライアントの処理を自分で実装できます。 -### Key points include: +### 主な手順 -* **Signature Algorithm**: Implement AWS Signature Version 4 signature (more complex) -* **Construct correct Headers and Canonical Request** -* **Use HTTPS/HTTP client to send requests** +* **リクエスト署名**: AWS Signature Version 4 を実装します（最も複雑な部分です）。 +* **ヘッダーと正規リクエスト**: 正規リクエストと、必要なヘッダーを組み立てます。 +* **HTTP クライアント**: 署名済みのリクエストを、HTTP または HTTPS のクライアントで送ります。 -👉 Recommended to reference open-source project signature implementations, for example: +リクエスト署名については、既存のオープンソース実装を参照することを推奨します。例: * [https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html](https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html) --- -## 2. Call CLI Tools or Middleware Services of Existing SDKs +## 2. AWS CLI、または既存の SDK で構築したサービスを使う -If you don't want to implement signatures yourself, you can: +自分で署名を実装したくない場合は、次の方法を使えます。 -### 2.1. Use AWS CLI tools with existing language support: +### 2.1. AWS CLI を呼び出す -For example, call through Shell: +たとえば、アプリケーションからシェルで次のコマンドを実行します。 ```bash aws s3 cp local.txt s3://mybucket/myfile.txt --endpoint-url http://rustfs.local:9000 ``` -Or write a simple relay service using Node.js/Python SDK, and your language uploads/downloads by calling this service. +あるいは、Node.js または Python の SDK で小さな中継サービスを作り、アプリケーションから呼び出してオブジェクトをアップロードまたはダウンロードします。 -### 2.2. Set up a Proxy (such as Flask, FastAPI, Express) +### 2.2. プロキシサービスを動かす（Flask、FastAPI、Express など） -Let clients that don't support S3 call your encapsulated HTTP API: +S3 に対応していないクライアントが呼び出せる HTTP API を公開します。 ```http POST /upload -> Service internally calls SDK to upload objects to RustFS @@ -46,33 +46,33 @@ GET /presigned-url -> Generate presigned URL for frontend/client use --- -## 3. Find Third-Party Community SDKs +## 3. サードパーティのコミュニティ SDK を探す -Although AWS doesn't have official SDKs, some language communities have developed unofficial S3 clients. For example: +公式の AWS SDK がない言語では、コミュニティが保守している S3 クライアントを探します。例: * Haskell: `amazonka-s3` -* Rust: `rusoto` (deprecated) or `aws-sdk-rust` -* OCaml: May implement through `cohttp` yourself -* Delphi: Has commercial libraries supporting S3 protocol +* Rust: `rusoto`（非推奨）、または `aws-sdk-rust` +* OCaml: `cohttp` の上に、独自のクライアントを構築します +* Delphi: S3 に対応した商用ライブラリがあります -Community SDKs vary greatly in stability, so you should evaluate activity, documentation, and compatibility before use. +コミュニティ SDK は安定性の差が大きいため、使用前に活動状況、ドキュメント、互換性を評価することを推奨します。 --- -## 4. Delegate Core Upload Logic to Platform Hosting +## 4. 署名付き URL でクライアントから直接アップロードする -For example: +例: -* Delegate frontend (Web/Mobile) upload tasks to browser or App side execution (using presigned URLs) -* Backend uses Node.js/Python/Go and other proxies to implement upload logic +* ブラウザーやモバイルアプリから、署名付き URL を使って直接アップロードします。 +* バックエンドサービス（Node.js、Python、Go など）に、アップロード処理を実装します。 --- -## Summary Recommendations +## 方法の選び方 -| Scenario | Recommended Solution | -| ------------- | ---------------------------------- | -| Need complete control/embedded environment | Implement Signature V4 self-signing | -| Weak language support but has Shell | Call upload through AWS CLI | -| Can deploy relay service | Use Python/Node to build S3 API gateway | -| Frontend upload | Use presigned URLs | +| 状況 | 推奨する方法 | +| --- | --- | +| すべてを自分で制御する必要がある、または組み込み環境が対象 | SigV4 署名を自分で実装する | +| SDK の対応は限られるが、シェルは使える | AWS CLI でアップロードする | +| 中継サービスをデプロイできる | Python または Node.js で、小さな S3 ゲートウェイを構築する | +| フロントエンドからのアップロード | 署名付き URL を使う | diff --git a/content/ja/developer/sdk/python.md b/content/ja/developer/sdk/python.md index 672504524..6a67f868f 100644 --- a/content/ja/developer/sdk/python.md +++ b/content/ja/developer/sdk/python.md @@ -1,37 +1,37 @@ --- -title: "Python SDK Guide" -description: "Use the official AWS SDK for Python (Boto3) with RustFS." +title: "Python" +description: "公式の AWS SDK for Python（Boto3）を RustFS で使います。" --- -## 1. Overview +## 1. 概要 -RustFS ships no first-party SDKs — it is S3-compatible, so you use the official AWS SDK for Python, [Boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html), configured to point at your RustFS server. +RustFS は独自の SDK を提供していません。S3 互換であるため、公式の AWS SDK for Python である [Boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) を、RustFS サーバーを指すように設定して使います。 -This guide covers: +このガイドでは、次の内容を扱います。 -* Bucket creation/deletion -* Object upload/download/deletion -* Listing objects -* Generating presigned URLs -* Multipart upload for large files +* バケットの作成と削除 +* オブジェクトのアップロード、ダウンロード、削除 +* オブジェクトの一覧 +* 署名付き URL の生成 +* 大きなファイルのマルチパートアップロード --- -## 2. Prerequisites +## 2. 前提条件 -* Python 3.8 or later -* A running RustFS instance (see the [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001` -* Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (see [Access Key Management](../../security-compliance/iam/access-token.md)) +* Python 3.8 以降 +* 稼働している RustFS インスタンス（[インストールガイド](../../installation/index.md)を参照）。S3 API はポート `9000`、Console はポート `9001` で待ち受けます +* インストール時に環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` で設定するアクセスキー（[アクセスキーの管理](../../security-compliance/iam/access-token.md)を参照） -:::tip[Local test] +:::tip[ローカル検証] -If you did not set credentials at install time, the server defaults to `rustfsadmin` / `rustfsadmin` — fine for a throwaway local trial, never for anything reachable by others. +インストール時に認証情報を設定しなかった場合、サーバーの既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル検証であれば問題ありませんが、外部から到達できる環境では使わないでください。 ::: -### 2.1 Install Boto3 +### 2.1 Boto3 のインストール -We recommend using a virtual environment: +仮想環境の使用を推奨します。 ```bash python3 -m venv venv @@ -39,13 +39,13 @@ source venv/bin/activate pip install boto3 ``` -> Boto3 depends on `botocore`, which will be installed automatically. +> Boto3 は `botocore` に依存しており、自動的にインストールされます。 --- -## 3. Connecting to RustFS +## 3. RustFS への接続 -The following is a complete, runnable script. Replace `localhost` with your server's IP address if RustFS runs on another machine, and fill in your own access keys: +次のスクリプトは、そのまま実行できます。RustFS が別のマシンで動作している場合は `localhost` をサーバーの IP アドレスに置き換え、アクセスキーも自分の値にします。 ```python title="main.py" import boto3 @@ -68,26 +68,26 @@ for bucket in response['Buckets']: print(bucket['Name']) ``` -Run it: +実行します。 ```bash python main.py ``` -:::note[Client parameters explained] +:::note[クライアントパラメータの説明] -- `endpoint_url` — points to your RustFS S3 API (port `9000`, not the Console port `9001`) -- `signature_version='s3v4'` — RustFS supports v4 signatures -- `region_name='us-east-1'` — RustFS's default region -- `addressing_style='path'` — RustFS uses path-style URLs by default; virtual-host style requires `RUSTFS_SERVER_DOMAINS` +- `endpoint_url` — RustFS の S3 API を指します（ポート `9000`。Console のポート `9001` ではありません） +- `signature_version='s3v4'` — RustFS は v4 署名に対応しています +- `region_name='us-east-1'` — RustFS の既定リージョンです +- `addressing_style='path'` — RustFS は既定でパススタイルアクセスを使います。仮想ホスト形式には `RUSTFS_SERVER_DOMAINS` が必要です ::: --- -## 4. Basic Operations +## 4. 基本操作 -### 4.1 Create Bucket +### 4.1 バケットの作成 ```python bucket_name = 'my-bucket' @@ -105,7 +105,7 @@ Bucket my-bucket created. --- -### 4.2 Upload File +### 4.2 ファイルのアップロード ```python s3.upload_file('/path/to/hello.txt', bucket_name, 'hello.txt') @@ -118,7 +118,7 @@ File uploaded. --- -### 4.3 Download File +### 4.3 ファイルのダウンロード ```python s3.download_file(bucket_name, 'hello.txt', 'hello-downloaded.txt') @@ -131,7 +131,7 @@ File downloaded. --- -### 4.4 List Objects +### 4.4 オブジェクトの一覧 ```python response = s3.list_objects_v2(Bucket=bucket_name) @@ -145,7 +145,7 @@ for obj in response.get('Contents', []): --- -### 4.5 Delete Object and Bucket +### 4.5 オブジェクトとバケットの削除 ```python s3.delete_object(Bucket=bucket_name, Key='hello.txt') @@ -162,11 +162,11 @@ Bucket deleted. --- -## 5. Advanced Features +## 5. 高度な機能 -### 5.1 Generate Presigned URLs +### 5.1 署名付き URL の生成 -#### 5.1.1 Download Link (GET) +#### 5.1.1 ダウンロードリンク（GET） ```python url = s3.generate_presigned_url( @@ -182,7 +182,7 @@ print('Presigned GET URL:', url) Presigned GET URL: http://localhost:9000/my-bucket/hello.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&... ``` -#### 5.1.2 Upload Link (PUT) +#### 5.1.2 アップロードリンク（PUT） ```python url = s3.generate_presigned_url( @@ -194,7 +194,7 @@ url = s3.generate_presigned_url( print('Presigned PUT URL:', url) ``` -You can use the `curl` tool to upload: +`curl` でアップロードできます。 ```bash curl -X PUT --upload-file /path/to/hello.txt "http://localhost:9000/my-bucket/upload-by-url.txt?X-Amz-Algorithm=..." @@ -202,9 +202,9 @@ curl -X PUT --upload-file /path/to/hello.txt "http://localhost:9000/my-bucket/up --- -### 5.2 Multipart Upload +### 5.2 マルチパートアップロード -Suitable for files larger than 10 MB, allows manual control of each part. +各パートを制御する必要がある場合は、10 MB を超えるファイルにマルチパートアップロードを使います。 ```python file_path = 'largefile.bin' @@ -260,18 +260,18 @@ Multipart upload complete. --- -## 6. Common Issue Troubleshooting +## 6. トラブルシューティング -| Issue | Cause | Solution | -| ------------------------- | ----------------- | -------------------------------------------------------------- | -| `SignatureDoesNotMatch` | Not using v4 signature | Set `signature_version='s3v4'` | -| `EndpointConnectionError` | Wrong RustFS address or service not started | Check endpoint and RustFS service status | -| `AccessDenied` | Wrong credentials or insufficient permissions | Check AccessKey/SecretKey or bucket policies | -| `PermanentRedirect` / wrong bucket URL | Path-style not enabled | Set `s3={'addressing_style': 'path'}` in the `Config` | +| 問題 | 原因 | 対処 | +| --- | --- | --- | +| `SignatureDoesNotMatch` | v4 署名を使っていない | `signature_version='s3v4'` を設定します | +| `EndpointConnectionError` | RustFS のアドレスが誤っている、またはサービスが起動していない | エンドポイントと RustFS のサービス状態を確認します | +| `AccessDenied` | 認証情報が誤っている、または権限が不足している | アクセスキー、シークレットキー、バケットポリシーを確認します | +| `PermanentRedirect`、または誤ったバケット URL | パススタイルアクセスが有効になっていない | `Config` で `s3={'addressing_style': 'path'}` を設定します | --- -## 7. Appendix: Quick Upload/Download Script Template +## 7. 付録: アップロードとダウンロードの簡易スクリプトテンプレート ```python def upload_file(local_path, bucket, object_key): @@ -284,6 +284,6 @@ def download_file(bucket, object_key, local_path): print(f"Downloaded s3://{bucket}/{object_key} to {local_path}") ``` -For other operations (object tagging, bucket policies, and more), see the [Boto3 S3 documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html) — every S3-compatible call works against RustFS the same way. +オブジェクトのタグ付けやバケットポリシーなどの操作については、[Boto3 S3 のドキュメント](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html)を参照します。ほとんどの S3 操作は、RustFS に対しても同じように動作します。例外は [S3 互換性](/ja/reference/s3-compatibility) を参照します。 -If you prefer native async support and full type hints, the community-driven [capo](https://github.com/kap-sh/capo) SDK also works with RustFS — see the [capo (Python) integration guide](../integration/others/capo.md). +ネイティブな非同期と、一通りの型ヒントを重視する場合は、コミュニティ主導の [capo](https://github.com/kap-sh/capo) SDK も RustFS で動作します。[capo（Python）連携ガイド](../integration/others/capo.md)を参照します。 diff --git a/content/ja/developer/sdk/rust.md b/content/ja/developer/sdk/rust.md index 9d8181348..0f8020898 100644 --- a/content/ja/developer/sdk/rust.md +++ b/content/ja/developer/sdk/rust.md @@ -1,23 +1,23 @@ --- -title: "Rust SDK Guide" -description: "Operate RustFS instances through the AWS SDK for Rust, including creation and deletion of buckets and objects." +title: "Rust" +description: "AWS SDK for Rust を使い、RustFS でバケットとオブジェクトを作成および削除します。" --- -RustFS ships no first-party Rust client crate — it is fully S3-compatible, so you use the official AWS SDK for Rust (`aws-sdk-s3`) configured to point at your RustFS server. Through the SDK, you can operate RustFS, including creation and deletion of buckets/objects, file upload and download, etc. +RustFS は独自の Rust クライアントクレートを提供していません。S3 互換であるため、公式の AWS SDK for Rust（`aws-sdk-s3`）を、RustFS サーバーを指すように設定して使います。この SDK で、バケットの作成と削除、およびオブジェクトのアップロード、ダウンロード、削除ができます。 -## Prerequisites +## 前提条件 -- Rust 1.78 or later (install via [rustup](https://rustup.rs/)) -- An available RustFS instance (refer to [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001` -- Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (refer to [Access Key Management](../../security-compliance/iam/access-token.md)) +- Rust 1.78 以降（[rustup](https://rustup.rs/) でインストールします） +- 利用できる RustFS インスタンス（[インストールガイド](../../installation/index.md)を参照）。S3 API はポート `9000`、Console はポート `9001` で待ち受けます +- インストール時に環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` で設定するアクセスキー（[アクセスキーの管理](../../security-compliance/iam/access-token.md)を参照） -:::tip[Local test] +:::tip[ローカル検証] -If you did not set credentials at install time, the server defaults to `rustfsadmin` / `rustfsadmin` — fine for a throwaway local trial, never for anything reachable by others. +インストール時に認証情報を設定しなかった場合、サーバーの既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル検証であれば問題ありませんが、外部から到達できる環境では使わないでください。 ::: -Create a project and add the dependencies: +プロジェクトを作成し、依存関係を追加します。 ```bash cargo new rustfs-rust-demo && cd rustfs-rust-demo @@ -25,7 +25,7 @@ cargo add aws-config aws-sdk-s3 anyhow cargo add tokio --features full ``` -Your `Cargo.toml` should contain: +`Cargo.toml` は、次の内容になっているはずです。 ```toml title="Cargo.toml" [dependencies] @@ -35,9 +35,9 @@ aws-sdk-s3 = "1" tokio = { version = "1", features = ["full"] } ``` -## Initializing the Client +## クライアントの初期化 -The following is a complete, runnable program. It loads the connection settings from environment variables, initializes the S3 client, and lists your buckets: +次のプログラムは、そのまま実行できます。環境変数から接続設定を読み込み、S3 クライアントを初期化して、バケットを一覧します。 ```rust title="src/main.rs" use anyhow::Result; @@ -108,11 +108,11 @@ async fn main() -> Result<()> { :::note -These environment variable names (`RUSTFS_ENDPOINT_URL`, `RUSTFS_REGION`, `RUSTFS_ACCESS_KEY_ID`, `RUSTFS_SECRET_ACCESS_KEY`) are just this example's client-side conventions — they are read by your program, not by RustFS. They are distinct from the server-side `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` variables used when installing RustFS. +これらの環境変数名（`RUSTFS_ENDPOINT_URL`、`RUSTFS_REGION`、`RUSTFS_ACCESS_KEY_ID`、`RUSTFS_SECRET_ACCESS_KEY`）は、この例だけのクライアント側の取り決めです。このプログラムが読み取り、RustFS サーバーは参照しません。インストール時に使うサーバー側の `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` とは別の変数です。 ::: -Run it (replace `localhost` with your server's IP address if RustFS runs on another machine): +実行します（RustFS が別のマシンで動作している場合は、`localhost` をサーバーの IP アドレスに置き換えます）。 ```bash export RUSTFS_ENDPOINT_URL="http://localhost:9000" @@ -126,9 +126,9 @@ cargo run Bucket: Some("my-bucket") ``` -You can now use the client for the operations below. Each snippet runs inside `main`, reusing `rustfs_client`. +これで、以下の操作にクライアントを使えます。各コード片は `main` の中で実行し、`rustfs_client` を再利用します。 -## Create Bucket +## バケットの作成 ```rust match rustfs_client @@ -151,7 +151,7 @@ match rustfs_client Bucket created successfully ``` -## Delete Bucket +## バケットの削除 ```rust match rustfs_client @@ -174,7 +174,7 @@ match rustfs_client Bucket deleted successfully ``` -## List Buckets +## バケットの一覧 ```rust match rustfs_client.list_buckets().send().await { @@ -196,7 +196,7 @@ Total buckets number is 1 Bucket: Some("my-bucket") ``` -## List Objects +## オブジェクトの一覧 ```rust match rustfs_client @@ -223,16 +223,16 @@ Total objects number is 1 Object: Some("hello.txt") ``` -## Upload File +## ファイルのアップロード -Add these imports at the top of `src/main.rs`: +`src/main.rs` の先頭に、次の import を追加します。 ```rust use aws_sdk_s3::primitives::ByteStream; use tokio::fs; ``` -Then upload a local file: +続けて、ローカルファイルをアップロードします。 ```rust let data = fs::read("/path/to/hello.txt").await.expect("can not open the file"); @@ -259,7 +259,7 @@ match rustfs_client Object uploaded successfully, res: PutObjectOutput { e_tag: Some("\"...\""), ... } ``` -## Download Object +## オブジェクトのダウンロード ```rust match rustfs_client @@ -284,4 +284,4 @@ match rustfs_client Object content: hello rustfs ``` -For other operations (presigned URLs, multipart uploads, and more), see the [AWS SDK for Rust documentation](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/) — every S3-compatible call works against RustFS the same way. +署名付き URL、マルチパートアップロードなどの操作については、[AWS SDK for Rust のドキュメント](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/)を参照します。ほとんどの S3 操作は、RustFS に対しても同じように動作します。例外は [S3 互換性](/ja/reference/s3-compatibility) を参照します。 diff --git a/content/ja/developer/sdk/typescript.md b/content/ja/developer/sdk/typescript.md index d26b7a938..0dcb066be 100644 --- a/content/ja/developer/sdk/typescript.md +++ b/content/ja/developer/sdk/typescript.md @@ -1,32 +1,32 @@ --- -title: "RustFS TypeScript SDK Usage Guide" -description: "Operate RustFS from TypeScript with the AWS SDK for JavaScript v3, including creation and deletion of buckets and objects." +title: "TypeScript" +description: "AWS SDK for JavaScript v3 を使い、TypeScript から RustFS のバケットとオブジェクトを作成および削除します。" --- -RustFS ships no first-party TypeScript SDK — it is fully S3-compatible, so you use the official AWS SDK for JavaScript v3 (which ships its own TypeScript type definitions) configured to point at your RustFS server. Through the SDK, you can operate RustFS, including creation and deletion of buckets/objects, file upload and download, etc. +RustFS は独自の TypeScript SDK を提供していません。S3 互換であるため、公式の AWS SDK for JavaScript v3（TypeScript の型定義を含みます）を、RustFS サーバーを指すように設定して使います。この SDK で、バケットの作成と削除、およびオブジェクトのアップロード、ダウンロード、削除ができます。 -## Prerequisites +## 前提条件 -- Node.js 18 or later (the examples use ES modules — set `"type": "module"` in your `package.json`) -- An available RustFS instance (refer to [Installation Guide](../../installation/index.md) for installation) — the S3 API listens on port `9000`, the Console on port `9001` -- Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (refer to [Access Key Management](../../security-compliance/iam/access-token.md) for creation) +- Node.js 18 以降（例は ES modules を使います。`package.json` に `"type": "module"` を設定します） +- 稼働している RustFS インスタンス（[インストールガイド](../../installation/index.md)を参照）。S3 API はポート `9000`、Console はポート `9001` で待ち受けます +- インストール時に環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` で設定するアクセスキー（作成方法は[アクセスキーの管理](../../security-compliance/iam/access-token.md)を参照） -:::tip[Local test] +:::tip[ローカル検証] -If you did not set credentials at install time, the server defaults to `rustfsadmin` / `rustfsadmin` — fine for a throwaway local trial, never for anything reachable by others. +インストール時に認証情報を設定しなかった場合、サーバーの既定値は `rustfsadmin` / `rustfsadmin` です。使い捨てのローカル検証であれば問題ありませんが、外部から到達できる環境では使わないでください。 ::: -Install the dependencies: +依存関係をインストールします。 ```bash npm install @aws-sdk/client-s3 npm install --save-dev typescript tsx @types/node ``` -## Initializing the Client +## クライアントの初期化 -The following is a complete, runnable example. Replace `localhost` with your server's IP address if RustFS runs on another machine, and fill in your own access keys: +次の例は、そのまま実行できます。RustFS が別のマシンで動作している場合は `localhost` をサーバーの IP アドレスに置き換え、アクセスキーも自分の値にします。 ```typescript title="main.ts" import { @@ -55,7 +55,7 @@ const response = await rustfs_client.send(new ListBucketsCommand({})); console.log(response.Buckets?.map((bucket) => bucket.Name) ?? []); ``` -Run it: +実行します。 ```bash npx tsx main.ts @@ -65,9 +65,9 @@ npx tsx main.ts [ 'my-bucket' ] ``` -Then use the constructed `rustfs_client` for the operations below. +以降の操作では、ここで構築した `rustfs_client` を使います。 -## Create Bucket +## バケットの作成 ```typescript async function createBucket() { @@ -88,7 +88,7 @@ async function createBucket() { Bucket created: /my-bucket ``` -## Delete Bucket +## バケットの削除 ```typescript async function deleteBucket() { @@ -109,7 +109,7 @@ async function deleteBucket() { Bucket deleted ``` -## List Buckets +## バケットの一覧 ```typescript async function listBuckets() { @@ -126,7 +126,7 @@ async function listBuckets() { my-bucket ``` -## List Objects +## オブジェクトの一覧 ```typescript async function listObjects() { @@ -147,7 +147,7 @@ async function listObjects() { test/hello.txt (12 bytes) ``` -## Upload File +## ファイルのアップロード ```typescript async function uploadFile() { @@ -170,7 +170,7 @@ async function uploadFile() { Object uploaded ``` -## Download Object +## オブジェクトのダウンロード ```typescript async function getObject() { @@ -201,4 +201,4 @@ async function getObject() { Object content: hello rustfs ``` -For other operations (presigned URLs, multipart uploads, and more), see the [AWS SDK for JavaScript v3 documentation](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/) — every S3-compatible call works against RustFS the same way. +署名付き URL、マルチパートアップロードなどの操作については、[AWS SDK for JavaScript v3 のドキュメント](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/)を参照します。ほとんどの S3 操作は、RustFS に対しても同じように動作します。例外は [S3 互換性](/ja/reference/s3-compatibility) を参照します。 diff --git a/content/ja/installation/cloud-native/helm-chart/cert-manager.md b/content/ja/installation/cloud-native/helm-chart/cert-manager.md index 5386eaf38..9be1c5a1c 100644 --- a/content/ja/installation/cloud-native/helm-chart/cert-manager.md +++ b/content/ja/installation/cloud-native/helm-chart/cert-manager.md @@ -1,26 +1,26 @@ --- title: cert-manager -description: Use cert-manager to issue and renew TLS certificates for a RustFS Helm deployment. +description: cert-manager を使い、RustFS の Helm デプロイ向け TLS 証明書を発行し、更新します。 --- -Use **cert-manager** to issue the certificate referenced by the RustFS Ingress. This provides HTTPS for the public S3 API and Console endpoint and allows cert-manager to renew the certificate. +**cert-manager** を使い、RustFS の Ingress が参照する証明書を発行します。公開する S3 API と Console のエンドポイントで HTTPS を提供し、cert-manager が証明書を更新できます。 -## Requirements +## 要件 -- cert-manager is installed and its controller Pods are ready. -- An `Issuer` or `ClusterIssuer` is ready. -- The RustFS hostname resolves to the Ingress controller. +- cert-manager がインストールされ、コントローラーの Pod が準備完了である。 +- `Issuer` または `ClusterIssuer` が準備完了である。 +- RustFS のホスト名が Ingress コントローラーへ解決される。 -Verify the issuer before installing RustFS: +RustFS をインストールする前に、Issuer を確認します。 ```bash kubectl get clusterissuer letsencrypt-prod kubectl -n cert-manager get pods ``` -## 1. Configure Ingress TLS +## 1. Ingress の TLS を設定する -Add the Ingress and certificate settings to your standalone or distributed values file: +スタンドアロン用または分散用の values ファイルに、Ingress と証明書の設定を追加します。 ```yaml title="values.yaml" ingress: @@ -42,9 +42,9 @@ ingress: name: "" ``` -Replace the Ingress class, issuer, and hostname for your cluster. For a namespace-scoped Issuer, use the `cert-manager.io/issuer` annotation instead. +クラスターに合わせて、Ingress クラス、Issuer、ホスト名を置き換えます。名前空間スコープの Issuer には、`cert-manager.io/issuer` アノテーションを使います。 -## 2. Apply the configuration +## 2. 設定を適用する ```bash helm upgrade rustfs ./helm/rustfs \ @@ -52,9 +52,9 @@ helm upgrade rustfs ./helm/rustfs \ -f values.yaml ``` -The Ingress references the `rustfs-tls` Secret for a release named `rustfs`. cert-manager ingress-shim reads the issuer annotation and creates a Certificate that writes to this Secret. +リリース名が `rustfs` の場合、Ingress は `rustfs-tls` Secret を参照します。cert-manager の ingress-shim は Issuer のアノテーションを読み取り、この Secret へ書き込む Certificate を作成します。 -## 3. Verify the certificate +## 3. 証明書を確認する ```bash kubectl -n rustfs get ingress,certificate,certificaterequest @@ -62,8 +62,8 @@ kubectl -n rustfs describe certificate rustfs-tls kubectl -n rustfs get secret rustfs-tls ``` -Wait for the Certificate to report `Ready=True`, then open `https://s3.example.com`. +Certificate が `Ready=True` を報告するまで待ち、その後 `https://s3.example.com` を開きます。 -## Use cert-manager with mTLS +## mTLS で cert-manager を使う -The chart also uses cert-manager to issue server and client certificates when `mtls.enabled=true`. See [mTLS](./mtls.md) to use the chart-managed CA or reference an existing issuer. \ No newline at end of file +`mtls.enabled=true` のとき、チャートはサーバー証明書とクライアント証明書の発行にも cert-manager を使います。チャートが管理する CA、または既存の Issuer の参照については、[mTLS](./mtls.md) を参照します。 diff --git a/content/ja/installation/cloud-native/helm-chart/index.md b/content/ja/installation/cloud-native/helm-chart/index.md index 26652e5be..0b50a58f0 100644 --- a/content/ja/installation/cloud-native/helm-chart/index.md +++ b/content/ja/installation/cloud-native/helm-chart/index.md @@ -1,21 +1,21 @@ --- -title: Overview -description: Understand how the RustFS Helm chart deploys standalone and distributed clusters on Kubernetes. +title: 概要 +description: RustFS の Helm チャートが、Kubernetes 上のスタンドアロンおよび分散クラスターをどのようにデプロイするかを説明します。 --- -The official **RustFS Helm chart** deploys one RustFS cluster directly into Kubernetes. Helm renders the workload, Services, credentials, configuration, PersistentVolumeClaims (PVCs), Ingress, and optional certificate resources from a single values file. +公式の **RustFS Helm チャート**は、1 つの RustFS クラスターを Kubernetes へ直接デプロイします。Helm は、1 つの values ファイルから、ワークロード、Service、認証情報、設定、PersistentVolumeClaim（PVC）、Ingress、任意の証明書リソースを生成します。 -The chart supports two deployment modes: +チャートは 2 つのデプロイモードに対応しています。 -- **Standalone** creates one Pod with one data PVC. Use it for evaluation and development. -- **Distributed** creates a StatefulSet with multiple Pods and data PVCs. `replicaCount` controls the number of Pods and `drivesPerNode` controls the number of data PVCs mounted by each Pod. +- **スタンドアロン**は、データ PVC を 1 つ持つ Pod を 1 つ作成します。評価と開発に使います。 +- **分散**は、複数の Pod とデータ PVC を持つ StatefulSet を作成します。`replicaCount` は Pod 数を、`drivesPerNode` は各 Pod がマウントするデータ PVC の数を制御します。 -Distributed mode is enabled by default. The chart also supports multiple append-only server pools, but a single explicit topology is easier to operate for an initial deployment. Credentials must be supplied through chart values or an existing Secret; the chart rejects empty and well-known default credentials unless insecure development defaults are explicitly enabled. +分散モードはデフォルトで有効です。チャートは、追記のみのストレージプールを複数持つ構成にも対応していますが、初期のデプロイでは、明示した単一のトポロジーの方が運用しやすいです。認証情報は、チャートの値または既存の Secret で指定する必要があります。安全でない開発用のデフォルトを明示的に有効にしない限り、チャートは空の値と周知のデフォルト認証情報を拒否します。 -Use the Helm chart when you want Helm to manage one RustFS cluster. Use the [RustFS Operator](../operator/index.md) when you need Kubernetes custom resources, multiple Tenants, or Operator-driven pool management. +1 つの RustFS クラスターを Helm で管理する場合は、Helm チャートを使います。Kubernetes のカスタムリソース、複数の Tenant、Operator によるプール管理が必要な場合は、[RustFS Operator](../operator/index.md) を使います。 -## Helm chart workflows +## Helm チャートのワークフロー -- [Install](./installation.mdx) covers requirements and standalone or distributed deployment. -- [mTLS](./mtls.md) encrypts and authenticates traffic between RustFS Pods. -- [cert-manager](./cert-manager.md) issues and renews certificates for RustFS Ingress and mTLS. \ No newline at end of file +- [インストール](./installation.mdx)では、要件と、スタンドアロンまたは分散でのデプロイを扱います。 +- [mTLS](./mtls.md)では、RustFS の Pod 間トラフィックを暗号化し、認証します。 +- [cert-manager](./cert-manager.md)では、RustFS の Ingress と mTLS 向けの証明書を発行し、更新します。 diff --git a/content/ja/installation/cloud-native/helm-chart/installation.mdx b/content/ja/installation/cloud-native/helm-chart/installation.mdx index 5523fffb9..04fb872af 100644 --- a/content/ja/installation/cloud-native/helm-chart/installation.mdx +++ b/content/ja/installation/cloud-native/helm-chart/installation.mdx @@ -1,22 +1,22 @@ --- -title: Install -description: Install standalone or distributed RustFS on Kubernetes with the official Helm chart. +title: インストール +description: 公式の Helm チャートを使い、Kubernetes 上にスタンドアロンまたは分散構成の RustFS をインストールします。 --- -This guide gets the official RustFS chart from source or the Helm repository, installs it, and verifies access to the S3 API and Console. +このガイドでは、ソースまたは Helm リポジトリから公式の RustFS チャートを取得し、インストールして、S3 API と Console へのアクセスを確認します。 -## Requirements +## 要件 -| Component | Requirement | +| コンポーネント | 要件 | |-----------|-------------| -| Helm | Version 3 | -| Kubernetes | A cluster reachable with `kubectl` | -| StorageClass | Dynamic PVC provisioning for RustFS data | -| RustFS | `1.0.0-alpha.69` or later | +| Helm | バージョン 3 | +| Kubernetes | `kubectl` で到達できるクラスター | +| StorageClass | RustFS データ向けの動的な PVC プロビジョニング | +| RustFS | `1.0.0-alpha.69` 以降 | -An Ingress controller is optional. If you enable Ingress, set `ingress.className` to the controller in your cluster, such as `nginx` or `traefik`. +Ingress コントローラーは任意です。Ingress を有効にする場合は、`ingress.className` をクラスター内のコントローラー（`nginx` や `traefik` など）に設定します。 -Check the active cluster and available StorageClasses: +アクティブなクラスターと、利用できる StorageClass を確認します。 ```bash kubectl config current-context @@ -24,14 +24,14 @@ kubectl get storageclass helm version --short ``` -## 1. Get the chart +## 1. チャートを取得する -Choose how Helm should access the chart. Both options set `RUSTFS_CHART`, which the installation commands below use. +Helm がチャートへアクセスする方法を選びます。どちらの方法でも `RUSTFS_CHART` を設定し、以降のインストールコマンドで使います。 - - + + -Clone the RustFS source repository to use the chart at `helm/rustfs`: +RustFS のソースリポジトリをクローンし、`helm/rustfs` にあるチャートを使います。 ```bash git clone https://github.com/rustfs/rustfs.git @@ -40,9 +40,9 @@ export RUSTFS_CHART=./helm/rustfs ``` - + -Add the RustFS repository listed on [Artifact Hub](https://artifacthub.io/packages/helm/rustfs/rustfs), then update the local repository index: +[Artifact Hub](https://artifacthub.io/packages/helm/rustfs/rustfs) に掲載されている RustFS リポジトリを追加し、ローカルのリポジトリインデックスを更新します。 ```bash helm repo add rustfs https://charts.rustfs.com @@ -53,9 +53,9 @@ export RUSTFS_CHART=rustfs/rustfs -## 2. Install standalone mode +## 2. スタンドアロンモードをインストールする -Create a values file for a one-Pod development deployment: +Pod が 1 つの開発用デプロイ向けに、values ファイルを作成します。 ```yaml title="standalone-values.yaml" mode: @@ -78,7 +78,7 @@ ingress: enabled: false ``` -Replace `standard` with a StorageClass in your cluster, then install: +`standard` をクラスター内の StorageClass に置き換えてから、インストールします。 ```bash helm upgrade --install rustfs "$RUSTFS_CHART" \ @@ -87,9 +87,9 @@ helm upgrade --install rustfs "$RUSTFS_CHART" \ -f standalone-values.yaml ``` -## 3. Install distributed mode +## 3. 分散モードをインストールする -For a distributed cluster, set the Pod and drive counts explicitly. Total data drives equal `replicaCount * drivesPerNode`. +分散クラスターでは、Pod 数とドライブ数を明示します。データドライブの合計は `replicaCount * drivesPerNode` です。 ```yaml title="distributed-values.yaml" mode: @@ -115,7 +115,7 @@ ingress: enabled: false ``` -The example creates four Pods and eight data PVCs. Ensure the cluster can schedule all Pods and provision all PVCs, then install: +この例では、Pod を 4 つ、データ PVC を 8 つ作成します。すべての Pod をスケジュールでき、すべての PVC をプロビジョニングできることを確認してから、インストールします。 ```bash helm upgrade --install rustfs "$RUSTFS_CHART" \ @@ -124,45 +124,45 @@ helm upgrade --install rustfs "$RUSTFS_CHART" \ -f distributed-values.yaml ``` -:::warning[Choose the topology before installation] +:::warning[インストール前にトポロジーを決める] -Kubernetes does not allow updates to StatefulSet `volumeClaimTemplates`. Changing `drivesPerNode` later requires StatefulSet recreation or a new installation. +Kubernetes では、StatefulSet の `volumeClaimTemplates` を更新できません。後から `drivesPerNode` を変更するには、StatefulSet の再作成か、新規インストールが必要です。 ::: -## 4. Verify and access RustFS +## 4. RustFS を確認してアクセスする ```bash kubectl -n rustfs get pods,pvc,services kubectl -n rustfs rollout status statefulset/rustfs ``` -Standalone mode creates a Deployment instead of a StatefulSet. Check it with: +スタンドアロンモードでは、StatefulSet ではなく Deployment が作成されます。次のコマンドで確認します。 ```bash kubectl -n rustfs rollout status deployment/rustfs ``` -Forward the S3 API and Console to your workstation: +S3 API と Console を作業用マシンへポートフォワードします。 ```bash kubectl -n rustfs port-forward svc/rustfs 9000:9000 9001:9001 ``` -Use `http://localhost:9000` as the S3 endpoint and open `http://localhost:9001` for the Console. +S3 エンドポイントには `http://localhost:9000` を使い、Console は `http://localhost:9001` を開きます。 -## Key values +## 主要な値 -| Value | Purpose | Chart default | +| 値 | 目的 | チャートのデフォルト | |-------|---------|---------------| -| `mode.standalone.enabled` | Enable one-Pod standalone mode | `false` | -| `mode.distributed.enabled` | Enable distributed mode | `true` | -| `replicaCount` | Distributed Pod count | `4` | -| `drivesPerNode` | Data PVCs per Pod | Inferred from `replicaCount` | -| `storageclass.name` | StorageClass for PVCs | `local-path` | -| `storageclass.dataStorageSize` | Size of each data PVC | `256Mi` | -| `storageclass.logStorageSize` | Size of each log PVC | `256Mi` | -| `service.endpoint.port` | S3 API port | `9000` | -| `service.console.port` | Console port | `9001` | - -We recommend setting storage sizes explicitly; the chart defaults are intended only for basic evaluation. \ No newline at end of file +| `mode.standalone.enabled` | Pod が 1 つのスタンドアロンモードを有効にする | `false` | +| `mode.distributed.enabled` | 分散モードを有効にする | `true` | +| `replicaCount` | 分散モードの Pod 数 | `4` | +| `drivesPerNode` | Pod あたりのデータ PVC 数 | `replicaCount` から推定 | +| `storageclass.name` | PVC の StorageClass | `local-path` | +| `storageclass.dataStorageSize` | 各データ PVC のサイズ | `256Mi` | +| `storageclass.logStorageSize` | 各ログ PVC のサイズ | `256Mi` | +| `service.endpoint.port` | S3 API のポート | `9000` | +| `service.console.port` | Console のポート | `9001` | + +ストレージサイズは明示的に設定することを推奨します。チャートのデフォルトは、基本的な評価だけを想定しています。 diff --git a/content/ja/installation/cloud-native/helm-chart/mtls.md b/content/ja/installation/cloud-native/helm-chart/mtls.md index 5144b472e..0274e0a24 100644 --- a/content/ja/installation/cloud-native/helm-chart/mtls.md +++ b/content/ja/installation/cloud-native/helm-chart/mtls.md @@ -1,28 +1,28 @@ --- title: mTLS -description: Configure mutual TLS between RustFS Pods deployed by the Helm chart. +description: Helm チャートでデプロイした RustFS の Pod 間に、相互 TLS を設定します。 --- -The chart can enable mutual Transport Layer Security (mTLS) for RustFS Pod communication. When enabled, RustFS requires client certificates, uses HTTPS for generated peer URLs, and mounts server, client, and CA material into every Pod. +チャートでは、RustFS の Pod 間通信に相互トランスポート層セキュリティ（mTLS）を有効にできます。有効にすると、RustFS はクライアント証明書を要求し、生成されたピア URL に HTTPS を使い、サーバー用、クライアント用、CA 用の証明書データをすべての Pod へマウントします。 -## Requirements +## 要件 -mTLS uses cert-manager `Issuer` and `Certificate` resources. Install cert-manager before enabling it and confirm that its CRDs are available: +mTLS は cert-manager の `Issuer` と `Certificate` リソースを使います。有効にする前に cert-manager をインストールし、CRD が利用できることを確認します。 ```bash kubectl get crd certificates.cert-manager.io issuers.cert-manager.io ``` -## 1. Use the chart-managed CA +## 1. チャートが管理する CA を使う -Add the following setting to your existing values file: +既存の values ファイルに、次の設定を追加します。 ```yaml title="values.yaml" mtls: enabled: true ``` -Upgrade the release: +リリースをアップグレードします。 ```bash helm upgrade rustfs ./helm/rustfs \ @@ -30,11 +30,11 @@ helm upgrade rustfs ./helm/rustfs \ -f values.yaml ``` -The chart creates a self-signed root CA, a namespace Issuer, and server and client Certificates. It mounts the resulting Secrets and configures RustFS with `RUSTFS_SERVER_MTLS_ENABLE=1` and `RUSTFS_TLS_PATH=/opt/tls`. Health probes also use the generated client certificate. +チャートは、自己署名のルート CA、名前空間の Issuer、サーバー用とクライアント用の Certificate を作成します。生成された Secret をマウントし、`RUSTFS_SERVER_MTLS_ENABLE=1` と `RUSTFS_TLS_PATH=/opt/tls` で RustFS を設定します。ヘルスプローブも、生成されたクライアント証明書を使います。 -## 2. Use an existing Issuer +## 2. 既存の Issuer を使う -To use an Issuer or ClusterIssuer already managed by your platform, configure its reference: +プラットフォームで既に管理している Issuer または ClusterIssuer を使うには、その参照を設定します。 ```yaml title="values.yaml" mtls: @@ -46,9 +46,9 @@ mtls: group: cert-manager.io ``` -The issuer must be ready and able to issue both server and client certificates in the `rustfs` namespace. Use `kind: Issuer` for a namespace-scoped issuer. +Issuer は準備完了であり、`rustfs` 名前空間でサーバー証明書とクライアント証明書の両方を発行できる必要があります。名前空間スコープの Issuer には `kind: Issuer` を使います。 -## 3. Verify mTLS +## 3. mTLS を確認する ```bash kubectl -n rustfs get issuer,certificate,secret @@ -57,10 +57,10 @@ kubectl -n rustfs describe certificate rustfs-client-tls kubectl -n rustfs get pods ``` -For a release named `rustfs`, the generated certificate Secrets are `rustfs-server-tls` and `rustfs-client-tls`. +リリース名が `rustfs` の場合、生成される証明書の Secret は `rustfs-server-tls` と `rustfs-client-tls` です。 -:::warning[Plan external access] +:::warning[外部アクセスを計画する] -mTLS requires clients to present a trusted certificate. Validate how your Ingress controller or other external client presents that certificate before enabling mTLS on an existing deployment. +mTLS では、クライアントが信頼された証明書を提示する必要があります。既存のデプロイで mTLS を有効にする前に、Ingress コントローラーや他の外部クライアントが、その証明書をどのように提示するかを確認します。 -::: \ No newline at end of file +::: diff --git a/content/ja/installation/cloud-native/index.md b/content/ja/installation/cloud-native/index.md index 19175a9ec..3292b6bc2 100644 --- a/content/ja/installation/cloud-native/index.md +++ b/content/ja/installation/cloud-native/index.md @@ -1,28 +1,28 @@ --- -title: "Kubernetes Installation (Helm)" -description: "Deploy RustFS on Kubernetes with the official Helm chart: standalone or distributed mode, storage sizing, probes, production hardening, and server-pool expansion." +title: "Kubernetes インストール（Helm）" +description: "公式の Helm チャートを使い、スタンドアロンまたは分散モード、ストレージ容量、プローブ、本番向けの強化、ストレージプールの拡張を含めて、Kubernetes 上に RustFS をデプロイします。" --- -RustFS ships an official Helm chart that deploys either a single-node instance (a `Deployment` with one PVC) or a distributed cluster (a `StatefulSet` with multiple pods and PVCs). This guide walks through installing the chart, choosing a deployment mode, sizing storage correctly, and the production options the chart provides. +RustFS の公式 Helm チャートは、単一ノードのインスタンス（PVC が 1 つの `Deployment`）、または分散クラスター（複数の Pod と PVC を持つ `StatefulSet`）をデプロイします。このガイドでは、チャートのインストール、デプロイモードの選択、ストレージ容量の適切な設定、チャートが提供する本番向けのオプションを説明します。 -**Prerequisites** +**前提条件** -- A Kubernetes cluster and `kubectl` access +- Kubernetes クラスターと `kubectl` によるアクセス - Helm 3 -- RustFS image version `>= 1.0.0-alpha.69` (the chart requirement) -- A StorageClass with a working provisioner — the chart defaults to [`local-path`](https://github.com/rancher/local-path-provisioner); set `storageclass.name` to use your own -- [`rc`](/operations/rc) installed on the administration host before using the server-pool commands in this guide +- RustFS イメージのバージョン `>= 1.0.0-alpha.69`（チャートの要件） +- 動作するプロビジョナーを備えた StorageClass。チャートのデフォルトは [`local-path`](https://github.com/rancher/local-path-provisioner) です。独自の StorageClass を使う場合は `storageclass.name` を設定します +- このガイドのストレージプール用コマンドを使う前に、管理用ホストへ [`rc`](/ja/operations/rc) をインストールします -The chart lives in the RustFS source repository under `helm/rustfs`: +チャートは、RustFS のソースリポジトリ内の `helm/rustfs` にあります。 ```bash git clone https://github.com/rustfs/rustfs.git cd rustfs/helm/rustfs ``` -## 1. Quick install +## 1. クイックインストール -Install into a dedicated namespace, setting your own credentials and a realistic data size: +専用の名前空間へインストールし、独自の認証情報と実際の使用量に見合うデータサイズを設定します。 ```bash helm install rustfs . \ @@ -33,19 +33,19 @@ helm install rustfs . \ --set storageclass.logStorageSize=1Gi ``` -:::note[The chart refuses default credentials] +:::note[チャートはデフォルトの認証情報を拒否します] -Rendering fails by default unless one of the following is true: +デフォルトでは、次のいずれかを満たさない限り、マニフェストの生成に失敗します。 -1. `secret.existingSecret` names a Kubernetes Secret you control, or -2. `secret.rustfs.access_key` and `secret.rustfs.secret_key` are **both** set to non-empty, non-default values, or -3. `secret.allowInsecureDefaults: true` is set (only for local development). +1. `secret.existingSecret` に、管理している Kubernetes の Secret の名前を指定する。 +2. `secret.rustfs.access_key` と `secret.rustfs.secret_key` の**両方**に、空でなくデフォルトでもない値を設定する。 +3. `secret.allowInsecureDefaults: true` を設定する（ローカル開発のみ）。 -This prevents accidental deployment with the well-known default `rustfsadmin`/`rustfsadmin` credentials. Setting only one of the two keys is also rejected, so the chart never silently falls back to a default for the missing key. +これにより、周知のデフォルト認証情報 `rustfsadmin`/`rustfsadmin` での誤ったデプロイを防ぎます。2 つのキーのうち一方だけを設定した場合も拒否されるため、欠けているキーが通知なくデフォルトへ戻ることはありません。 ::: -Watch the pods come up: +Pod の起動を確認します。 ```bash kubectl -n rustfs get pods -w @@ -59,17 +59,17 @@ rustfs-2 1/1 Running 0 2m27s rustfs-3 1/1 Running 0 2m27s ``` -## 2. Choose a deployment mode +## 2. デプロイモードを選ぶ -The chart supports two modes, selected via the `mode` values: +チャートは、`mode` の値で選ぶ 2 つのモードに対応しています。 -| Mode | Values | Workload | Layout | +| モード | 値 | ワークロード | 構成 | | --- | --- | --- | --- | -| Distributed (**default**) | `mode.distributed.enabled=true` | StatefulSet | `replicaCount` pods (`>= 2`, default `4`) × `drivesPerNode` data PVCs per pod (`>= 1`, inferred as `4` when `replicaCount: 4` or `1` otherwise; 16 drives by default) | -| Standalone | `mode.standalone.enabled=true`, `mode.distributed.enabled=false` | Deployment | 1 pod, 1 data PVC (single node single disk) | +| 分散（**デフォルト**） | `mode.distributed.enabled=true` | StatefulSet | `replicaCount` 個の Pod（`>= 2`、デフォルト `4`）× Pod あたり `drivesPerNode` 個のデータ PVC（`>= 1`。`replicaCount: 4` のときは `4`、それ以外は `1` と推定。デフォルトはドライブ 16 台） | +| スタンドアロン | `mode.standalone.enabled=true`、`mode.distributed.enabled=false` | Deployment | Pod 1 つ、データ PVC 1 つ（シングルノード・シングルディスク） | -- **Standalone** matches single-node single-disk: no erasure-coding redundancy across nodes. Use it for development, testing, or small setups where the underlying storage provides its own durability. It can reuse existing PVCs via `mode.standalone.existingClaim.dataClaim` / `mode.standalone.existingClaim.logsClaim`. -- **Distributed** behaves like [multiple node multiple disk](../linux/multiple-node-multiple-disk.md): objects are erasure-coded across pods and PVCs. `replicaCount` sets the number of pods (`>= 2`) and `drivesPerNode` sets the number of data PVCs per pod (`>= 1`), giving `replicaCount * drivesPerNode` total drives. When `drivesPerNode` is left unset (`null`), the chart infers `4` data PVCs per pod when `replicaCount` is `4` (16 drives total) and `1` data PVC per pod for any other `replicaCount` (such as `replicaCount: 16` for 16 pods with 1 PVC each). Set both `replicaCount` and `drivesPerNode` explicitly (for example, `replicaCount: 4` and `drivesPerNode: 2` for 8 drives) to choose another layout. +- **スタンドアロン**はシングルノード・シングルディスクに相当し、ノードをまたぐイレイジャーコーディングの冗長性はありません。開発、テスト、または基盤のストレージ自身が耐久性を提供する小規模な構成に使います。既存の PVC は `mode.standalone.existingClaim.dataClaim` / `mode.standalone.existingClaim.logsClaim` で再利用できます。 +- **分散**は[マルチノード・マルチディスク](../linux/multiple-node-multiple-disk.md)と同様に動作し、オブジェクトは Pod と PVC にまたがってイレイジャーコーディングされます。`replicaCount` は Pod 数（`>= 2`）、`drivesPerNode` は Pod あたりのデータ PVC 数（`>= 1`）を指定し、合計ドライブ数は `replicaCount * drivesPerNode` になります。`drivesPerNode` を未設定（`null`）にすると、`replicaCount` が `4` のときは Pod あたりのデータ PVC を `4` つ（合計 16 ドライブ）、それ以外の `replicaCount`（たとえば Pod 16 台に PVC を 1 つずつ割り当てる `replicaCount: 16`）では Pod あたりのデータ PVC を `1` つと推定します。別の構成にするには `replicaCount` と `drivesPerNode` の両方を明示します（たとえば 8 ドライブにする場合は `replicaCount: 4` と `drivesPerNode: 2`）。 ```bash # Standalone mode @@ -80,9 +80,9 @@ helm install rustfs . -n rustfs --create-namespace \ --set secret.rustfs.secret_key= ``` -## 3. Storage sizing +## 3. ストレージ容量の設定 -PVC sizes come from the `storageclass` block: +PVC のサイズは `storageclass` ブロックで指定します。 ```yaml title="values-prod.yaml" storageclass: @@ -91,50 +91,50 @@ storageclass: logStorageSize: 256Mi # per logs PVC ``` -:::warning[The default PVC size is 256Mi — change it] +:::warning[デフォルトの PVC サイズ 256Mi は変更が必要です] -The chart's default size for the data and logs volumes is **256Mi**, which is only enough to verify the chart works. For any real workload set `storageclass.dataStorageSize` (for example `1Ti`) and `storageclass.logStorageSize` (for example `1Gi`) at install time. In distributed mode the data size applies to **each** data PVC (`replicaCount * drivesPerNode`, 16 PVCs by default). +データボリュームとログボリュームについて、チャートの既定サイズは **256Mi** であり、チャートの動作確認に足りるだけです。実際のワークロードでは、インストール時に `storageclass.dataStorageSize`（例: `1Ti`）と `storageclass.logStorageSize`（例: `1Gi`）を設定します。分散モードでは、データサイズは**各**データ PVC（`replicaCount * drivesPerNode`、デフォルトでは PVC 16 個）に適用されます。 ::: -Setting `config.rustfs.obs_log_directory` to `""` disables the log PVCs and mounts entirely. Custom PVC annotations go under `storageclass.pvcAnnotations.data` / `storageclass.pvcAnnotations.logs`. +`config.rustfs.obs_log_directory` を `""` に設定すると、ログ用 PVC とマウントが完全に無効になります。PVC のカスタムアノテーションは `storageclass.pvcAnnotations.data` / `storageclass.pvcAnnotations.logs` に指定します。 -## 4. Health probes +## 4. ヘルスプローブ -The chart templates HTTP probes on the S3 port (9000) out of the box, matching the server's health endpoints: +チャートは、サーバーのヘルスエンドポイントに合わせ、S3 ポート（9000）の HTTP プローブを標準で含みます。 -- **Liveness**: `GET /health` (`livenessProbe.httpGet.path`), initial delay 30s, period 5s -- **Readiness**: `GET /health/ready` (`readinessProbe.httpGet.path`), initial delay 10s, period 5s +- **Liveness**（生存確認）: `GET /health`（`livenessProbe.httpGet.path`）。初期遅延は 30 秒、間隔は 5 秒です +- **Readiness**（準備完了）: `GET /health/ready`（`readinessProbe.httpGet.path`）。初期遅延は 10 秒、間隔は 5 秒です -A pod is only added to the Service endpoints once `/health/ready` returns `200`, which in distributed mode requires the storage quorum to be met. Thresholds and timings are tunable via the `livenessProbe.*` and `readinessProbe.*` values. +Pod が Service のエンドポイントに追加されるのは、`/health/ready` が `200` を返したあとだけです。分散モードでは、この応答にストレージのクォーラムが満たされている必要があります。しきい値とタイミングは `livenessProbe.*` と `readinessProbe.*` の値で調整できます。 -## 5. Production hardening +## 5. 本番向けの強化 -### Pod Disruption Budget +### PodDisruptionBudget -Disabled by default. Enable it so voluntary evictions (node drains, cluster upgrades) never take more than one pod down at a time: +デフォルトでは無効です。有効にすると、自発的な退避（ノードのドレインやクラスターのアップグレード）で同時に停止する Pod は 1 つまでになります。 ```bash --set pdb.create=true # pdb.maxUnavailable defaults to 1 ``` -### Anti-affinity and topology spread +### アンチアフィニティとトポロジースプレッド -`affinity.podAntiAffinity.enabled` defaults to `true` with `topologyKey: kubernetes.io/hostname`, spreading pods across distinct nodes. For zone-level spreading, enable `topologySpreadConstraints.enabled` and supply raw constraint entries under `topologySpreadConstraints.constraints` (applied to the distributed StatefulSet). +`affinity.podAntiAffinity.enabled` のデフォルトは `true` で、`topologyKey: kubernetes.io/hostname` により Pod を別々のノードへ分散します。ゾーン単位で分散するには `topologySpreadConstraints.enabled` を有効にし、`topologySpreadConstraints.constraints` に制約エントリをそのまま指定します（分散モードの StatefulSet に適用されます）。 -### Inter-pod mTLS (cert-manager) +### Pod 間の mTLS（cert-manager） -Set `mtls.enabled=true` to encrypt traffic between pods; the chart renders cert-manager `Issuer`/`Certificate` resources for a CA, server, and client certificates. To use an issuer you already operate, set `mtls.existingIssuerRef.enabled=true` with its `name`, `kind` (`Issuer` or `ClusterIssuer`), and `group`. +`mtls.enabled=true` にすると、Pod 間のトラフィックが暗号化されます。チャートは、CA、サーバー証明書、クライアント証明書用に、cert-manager の `Issuer` と `Certificate` リソースを生成します。既に運用している Issuer を使う場合は、`mtls.existingIssuerRef.enabled=true` とともに `name`、`kind`（`Issuer` または `ClusterIssuer`）、`group` を指定します。 -### Ingress and Gateway API +### Ingress と Gateway API -Ingress is enabled by default (`ingress.enabled=true`) with `ingress.className: nginx`; set it to `traefik` if that is your controller — the chart applies the matching session-stickiness annotations for each. Set your domain via `ingress.hosts[0].host` (default `example.rustfs.com`). For HTTPS, enable `ingress.tls.enabled` and either pass the certificate with `--set-file ingress.tls.crt=./tls.crt --set-file ingress.tls.key=./tls.key`, point at an existing secret (`ingress.tls.existingSecret`), or let cert-manager issue one (`ingress.tls.certManager.enabled=true`). +Ingress はデフォルトで有効です（`ingress.enabled=true`）。`ingress.className: nginx` が設定されています。コントローラーが Traefik の場合は `traefik` にします。チャートは、コントローラーに対応するセッション固定のアノテーションを適用します。ドメインは `ingress.hosts[0].host` で設定します（デフォルトは `example.rustfs.com`）。HTTPS では `ingress.tls.enabled` を有効にし、`--set-file ingress.tls.crt=./tls.crt --set-file ingress.tls.key=./tls.key` で証明書を渡すか、既存の Secret を指定するか（`ingress.tls.existingSecret`）、cert-manager に発行させます（`ingress.tls.certManager.enabled=true`）。 -The chart also has alpha [Gateway API](https://gateway-api.sigs.k8s.io/) support (`gatewayApi.enabled=true` together with `ingress.enabled=false`, Traefik gateway class), rendering `Gateway` and `HTTPRoute` resources. +チャートには、アルファ版の [Gateway API](https://gateway-api.sigs.k8s.io/) サポートもあります（`gatewayApi.enabled=true` と `ingress.enabled=false` を併用し、Gateway クラスは Traefik）。`Gateway` と `HTTPRoute` リソースを生成します。 -## 6. Access RustFS +## 6. RustFS へアクセスする -Without an ingress, port-forward the Service: +Ingress を使わない場合は、Service をポートフォワードします。 ```bash kubectl -n rustfs port-forward svc/rustfs 9000:9000 9001:9001 @@ -143,13 +143,13 @@ kubectl -n rustfs port-forward svc/rustfs 9000:9000 9001:9001 - S3 API: `http://localhost:9000` - Console: `http://localhost:9001` -Log in to the Console with the access key and secret key you set at install time. With ingress enabled, use your configured host instead (check `kubectl -n rustfs get ing`). The Service defaults to `ClusterIP`; `service.type` can be switched to `NodePort` (S3 on `service.endpoint.nodePort: 32000`, Console on `service.console.nodePort: 32001`) or `LoadBalancer`. +インストール時に設定したアクセスキーとシークレットキーで Console にログインします。Ingress を有効にしている場合は、設定したホストを使います（`kubectl -n rustfs get ing` で確認します）。Service のデフォルトは `ClusterIP` です。`service.type` は `NodePort`（S3 は `service.endpoint.nodePort: 32000`、Console は `service.console.nodePort: 32001`）または `LoadBalancer` に切り替えられます。 -## 7. Scaling out with server pools +## 7. ストレージプールでスケールアウトする -In distributed mode the chart can run multiple **server pools** — independent StatefulSets whose drives together form one cluster. This is the chart-level equivalent of adding a Server Pool as described in [Pool Expansion](../../operations/scaling/storage-pool-expansion.md). +分散モードでは、チャートは複数の**ストレージプール**を実行できます。各プールは独立した StatefulSet であり、それらのドライブがまとまって 1 つのクラスターを構成します。これは、[ストレージプールの拡張](../../operations/scaling/storage-pool-expansion.md)で説明するストレージプールの追加を、チャート上で行う操作に相当します。 -To expand an existing deployment, enable pools and describe the current layout as pool 0 plus your new capacity: +既存のデプロイを拡張するには、プールを有効にし、現在の構成をプール 0 として残したうえで、新しい容量を追記します。 ```yaml title="values-prod.yaml (pools)" pools: @@ -162,27 +162,27 @@ pools: dataStorageSize: 10Gi ``` -Then apply with `helm upgrade`. Each entry may set `replicaCount` (`>= 2`) and/or a `storageclass` block; omitted fields inherit the top-level values. When top-level `drivesPerNode` is set explicitly, that drive count applies to every pool; when `drivesPerNode` is left unset (`null`), the chart infers the drive count per pool from that pool's `replicaCount` (`4` drives per pod when `replicaCount` is `4`, or `1` drive per pod otherwise). Additional pools render as `-pool` StatefulSets; all pools share the headless service, the main service, the configuration, and the credentials. +その後、`helm upgrade` で適用します。各エントリでは `replicaCount`（`>= 2`）と `storageclass` ブロックの一方または両方を設定できます。省略したフィールドはトップレベルの値を継承します。トップレベルの `drivesPerNode` を明示すると、そのドライブ数はすべてのプールに適用されます。`drivesPerNode` を未設定（`null`）にすると、チャートは各プールの `replicaCount` からドライブ数を推定します（`replicaCount` が `4` のときは Pod あたり `4` ドライブ、それ以外は Pod あたり `1` ドライブ）。追加のプールは `-pool` という名前の StatefulSet として生成されます。すべてのプールは、ヘッドレス Service、メインの Service、設定、認証情報を共有します。 -:::warning[Pools are append-only] +:::warning[プールは追記のみです] -The list index determines the StatefulSet name — never remove or reorder entries. Retire a pool with `rc admin decommission` before removing it from the list. +リストのインデックスが StatefulSet 名を決めます。エントリを削除したり、順序を変えたりしてはなりません。リストから除く前に `rc admin decommission` を実行し、データを排出してプールをデコミッションします。 ::: -What to expect during the rollout, per the chart's documentation: +ロールアウト中に想定される動作は、チャートのドキュメントでは次のとおりです。 -- **Crash/restart cycles are normal.** Pods restart until every pod of every pool is resolvable — the server refuses to start with unresolvable peers, so expect a few crash loops before the cluster converges. This is harmless. -- **Rebalance afterwards.** After the cluster converges, run `rc admin rebalance start ` to spread existing objects across the new pool. -- The PodDisruptionBudget spans all pools: with the default `pdb.maxUnavailable: 1`, at most one pod of the whole cluster may be evicted at a time. +- **再起動を想定します。** すべてのプールですべての Pod が名前解決できるようになるまで、Pod は再起動します。解決できないピアがあるとサーバーは起動を拒否するため、クラスターが収束するまでにクラッシュループが数回発生することがあります。これは問題ありません。 +- **その後にリバランスします。** クラスターが収束したら、`rc admin rebalance start ` を実行して、既存のオブジェクトを新しいプールへ分散します。 +- PodDisruptionBudget はすべてのプールに適用されます。デフォルトの `pdb.maxUnavailable: 1` では、クラスター全体で同時に退避できる Pod は最大 1 つです。 :::note -`rc` is the RustFS command-line client. Use `rc admin pool list`, `expand`, `rebalance`, and `decommission` for the server-pool workflows described by the chart. +`rc` は RustFS のコマンドラインクライアントです。チャートが説明するストレージプールの操作には、`rc admin pool list`、`expand`、`rebalance`、`decommission` を使います。 ::: -## 8. Uninstall +## 8. アンインストール ```bash helm uninstall rustfs -n rustfs @@ -190,12 +190,12 @@ helm uninstall rustfs -n rustfs :::note -Helm does not delete PVCs created by StatefulSet volume claim templates. If you intend to discard the data, remove the PVCs explicitly (`kubectl -n rustfs delete pvc -l app.kubernetes.io/name=rustfs`) — otherwise a later reinstall with the same release name reattaches them. +Helm は、StatefulSet の volumeClaimTemplates が作成した PVC を削除しません。データを破棄する場合は、PVC を明示的に削除します（`kubectl -n rustfs delete pvc -l app.kubernetes.io/name=rustfs`）。削除しない場合、同じリリース名で再インストールすると、それらの PVC が再び接続されます。 ::: -## Next steps +## 次のステップ -- [Pool Expansion](../../operations/scaling/storage-pool-expansion.md) — how Server Pool expansion works at the cluster level -- [Kubernetes Upgrade](../../operations/upgrade/kubernetes/index.md) — upgrade Helm- and Operator-managed deployments -- [TLS configuration](../../integration/tls-configured.md) — end-to-end TLS options +- [ストレージプールの拡張](../../operations/scaling/storage-pool-expansion.md) — クラスターレベルでのストレージプール拡張の仕組み +- [Kubernetes のアップグレード](../../operations/upgrade/kubernetes/index.md) — Helm と Operator で管理するデプロイのアップグレード +- [TLS の設定](../../integration/tls-configured.md) — エンドツーエンドの TLS オプション diff --git a/content/ja/installation/cloud-native/operator/index.md b/content/ja/installation/cloud-native/operator/index.md index 68777f69c..b74deaaa3 100644 --- a/content/ja/installation/cloud-native/operator/index.md +++ b/content/ja/installation/cloud-native/operator/index.md @@ -1,28 +1,28 @@ --- -title: Overview -description: Understand how RustFS Operator manages RustFS clusters on Kubernetes. +title: 概要 +description: RustFS Operator が Kubernetes 上の RustFS クラスターをどのように管理するかを説明します。 --- -**RustFS Operator** applies the Kubernetes Operator pattern to RustFS clusters. Instead of creating StatefulSets, Services, PersistentVolumeClaims (PVCs), and configuration by hand, you declare the required storage cluster as a Kubernetes custom resource. The controller watches that resource and continuously reconciles the running cluster with the declared state. +**RustFS Operator** は、Kubernetes の Operator パターンを RustFS クラスターに適用します。StatefulSet、Service、PersistentVolumeClaim（PVC）、設定を手作業で作成する代わりに、必要なストレージクラスターを Kubernetes のカスタムリソースとして宣言します。コントローラーはそのリソースを監視し、実行中のクラスターを宣言した状態へ継続的に調整します。 -The Operator installs two Custom Resource Definitions (CRDs): +Operator は、2 つのカスタムリソース定義（CRD）をインストールします。 -- `Tenant` (`rustfs.com/v1alpha1`) represents one RustFS cluster. It defines storage pools, credentials, scheduling, Transport Layer Security (TLS), and Key Management Service (KMS) settings. -- `PolicyBinding` (`sts.rustfs.com/v1alpha1`) maps a Kubernetes ServiceAccount to RustFS policies when workloads request temporary credentials from the Operator Security Token Service (STS). +- `Tenant`（`rustfs.com/v1alpha1`）は 1 つの RustFS クラスターを表します。ストレージプール、認証情報、スケジューリング、トランスポート層セキュリティ（TLS）、キー管理サービス（KMS）の設定を定義します。 +- `PolicyBinding`（`sts.rustfs.com/v1alpha1`）は、ワークロードが Operator の Security Token Service（STS）へ一時認証情報を要求するとき、Kubernetes の ServiceAccount を RustFS のポリシーへ対応付けます。 -One Operator can manage multiple Tenants across namespaces. Each Tenant has independent storage, credentials, S3 and Console services, and lifecycle. The Operator creates one StatefulSet for each pool, so you can add capacity by appending a pool without rebuilding the cluster. It also reports `Ready`, `Progressing`, or `Degraded` conditions and Kubernetes Events, and exposes health and metrics endpoints for cluster monitoring. +1 つの Operator で、名前空間をまたいで複数の Tenant を管理できます。各 Tenant は、ストレージ、認証情報、S3 と Console の Service、ライフサイクルを独立して持ちます。Operator はプールごとに StatefulSet を 1 つ作成するため、クラスターを作り直さずにプールを追加して容量を増やせます。また、`Ready`、`Progressing`、`Degraded` の Condition と Kubernetes Event を報告し、クラスター監視用にヘルスとメトリクスのエンドポイントを公開します。 -The same API covers small test clusters and distributed deployments. Sensitive credentials and KMS material stay in Kubernetes Secrets, while version-controlled Tenant manifests hold only Secret references. This makes deployments repeatable, supports GitOps workflows, and keeps routine operations such as multi-tenant management, pool expansion, TLS, and encryption within Kubernetes-native tools. +同じ API で、小規模なテスト用クラスターと分散デプロイの両方を扱えます。機密の認証情報と KMS の鍵材料は Kubernetes の Secret に置き、バージョン管理する Tenant のマニフェストには Secret の参照だけを記述します。これによりデプロイを繰り返し行え、GitOps のワークフローにも対応できます。マルチテナントの管理、プールの拡張、TLS、暗号化といった日常の運用は、Kubernetes ネイティブのツールで行えます。 -## Operator workflows +## Operator のワークフロー -- [Install](./installation.md) covers requirements, Helm installation, Console access, and TLS configuration. -- [Multi-Tenant](./tenant.md) creates isolated RustFS clusters for different teams or workloads. -- [Pool Expansion](./pool-expansion.md) adds storage capacity by appending a pool to an existing Tenant. -- [KMS Integration](./kms.md) configures local or HashiCorp Vault key management for encrypted data. +- [インストール](./installation.md)では、要件、Helm によるインストール、Console へのアクセス、TLS の設定を扱います。 +- [マルチテナント](./tenant.md)では、チームやワークロードごとに分離した RustFS クラスターを作成します。 +- [ストレージプールの拡張](./pool-expansion.md)では、既存の Tenant にプールを追加してストレージ容量を増やします。 +- [KMS 連携](./kms.md)では、暗号化データ向けに、ローカルまたは HashiCorp Vault のキー管理を設定します。 -:::warning[Pre-release software] +:::warning[プレリリースのソフトウェア] -RustFS Operator is currently `v0.1.0` pre-release software under active development. Validate upgrades and Tenant changes in a non-production cluster first. +RustFS Operator は、現在 `v0.1.0` のプレリリースであり、活発に開発されています。アップグレードと Tenant の変更は、まず本番以外のクラスターで検証します。 -::: \ No newline at end of file +::: diff --git a/content/ja/installation/cloud-native/operator/installation.md b/content/ja/installation/cloud-native/operator/installation.md index 778625e77..2b0fde43b 100644 --- a/content/ja/installation/cloud-native/operator/installation.md +++ b/content/ja/installation/cloud-native/operator/installation.md @@ -1,29 +1,29 @@ --- -title: Install -description: Prepare Kubernetes, install RustFS Operator, and access its Console securely. +title: インストール +description: Kubernetes を準備し、RustFS Operator をインストールして、Console へ安全にアクセスします。 --- -This guide installs the Operator with Helm, verifies the deployment, and exposes the Operator Console locally or through HTTPS. +このガイドでは、Helm で Operator をインストールし、デプロイを確認し、Operator の Console をローカルまたは HTTPS で公開します。 -## Requirements +## 要件 -| Component | Requirement | +| コンポーネント | 要件 | |-----------|-------------| -| Kubernetes | `v1.30` or later | -| Helm | `v3.0` or later | -| kubectl | Compatible with the Kubernetes cluster | -| StorageClass | Dynamic PVC provisioning for Tenant storage | +| Kubernetes | `v1.30` 以降 | +| Helm | `v3.0` 以降 | +| kubectl | Kubernetes クラスターと互換性があること | +| StorageClass | Tenant のストレージ向け動的な PVC プロビジョニング | -Your account must be able to create CRDs, cluster RBAC, Deployments, and Services. Confirm the target cluster before installation: +アカウントは、CRD、クラスター RBAC、Deployment、Service を作成できる必要があります。インストール前に、対象クラスターを確認します。 ```bash kubectl config current-context kubectl get storageclass ``` -## 1. Install the Operator +## 1. Operator をインストールする -The Helm chart is stored in the Operator repository: +Helm チャートは、Operator のリポジトリにあります。 ```bash git clone https://github.com/rustfs/operator.git @@ -34,7 +34,7 @@ helm upgrade --install rustfs-operator deploy/rustfs-operator/ \ --create-namespace ``` -Common settings belong in a values file: +一般的な設定は values ファイルに記述します。 ```yaml title="values.yaml" operator: @@ -50,9 +50,9 @@ console: type: ClusterIP ``` -Apply the file with `-f values.yaml`. The chart generates `OPERATOR_*` variables from these values; do not duplicate them under `operator.env`. +`-f values.yaml` でこのファイルを適用します。チャートはこれらの値から `OPERATOR_*` 変数を生成します。`operator.env` の下へ同じ内容を重複して定義してはなりません。 -## 2. Verify the installation +## 2. インストールを確認する ```bash kubectl -n rustfs-system get pods,services @@ -61,32 +61,32 @@ kubectl -n rustfs-system rollout status deployment/rustfs-operator kubectl -n rustfs-system rollout status deployment/rustfs-operator-console ``` -## 3. Access the Operator Console +## 3. Operator の Console にアクセスする -The Console listens on port `9090`. Generate a short-lived login token: +Console はポート `9090` で待ち受けます。有効期間の短いログイントークンを生成します。 ```bash kubectl -n rustfs-system create token rustfs-operator-console --duration=24h ``` -Forward the Console service to your workstation: +Console の Service を作業用マシンへポートフォワードします。 ```bash kubectl -n rustfs-system port-forward \ svc/rustfs-operator-console 19090:9090 ``` -Open `http://127.0.0.1:19090` and paste the token into the login form. The Helm installation notes print the exact ServiceAccount and Service names when release names or namespaces differ. +`http://127.0.0.1:19090` を開き、ログインフォームへトークンを貼り付けます。リリース名や名前空間が異なる場合は、Helm のインストール時の注記に、ServiceAccount と Service の正確な名前が出力されます。 -:::note[Local HTTP access] +:::note[ローカルの HTTP アクセス] -If your browser does not retain the login over HTTP, set `CONSOLE_COOKIE_SECURE=false` under `console.env` for local testing only. Keep secure cookies enabled for HTTPS. +ブラウザーが HTTP 上のログインを保持しない場合は、ローカルテストに限り `console.env` で `CONSOLE_COOKIE_SECURE=false` を設定します。HTTPS では、セキュア Cookie を有効のままにする必要があります。 ::: -## 4. Configure Console TLS +## 4. Console の TLS を設定する -Use one HTTPS hostname for both the Console UI and `/api/v1`. Create a TLS Secret, or let cert-manager create it, then enable Ingress: +Console の UI と `/api/v1` の両方に、同じ HTTPS ホスト名を使います。TLS 用の Secret を作成するか、cert-manager に作成させてから、Ingress を有効にします。 ```yaml title="values.yaml" console: @@ -106,7 +106,7 @@ console: - console.example.com ``` -Upgrade the release with the values file: +values ファイルでリリースをアップグレードします。 ```bash helm upgrade rustfs-operator deploy/rustfs-operator/ \ @@ -114,6 +114,6 @@ helm upgrade rustfs-operator deploy/rustfs-operator/ \ -f values.yaml ``` -Replace the Ingress class, issuer, and hostname for your environment. If cert-manager is not installed, create the `console-tls` Secret with your certificate and private key before the upgrade. +環境に合わせて、Ingress クラス、Issuer、ホスト名を置き換えます。cert-manager をインストールしていない場合は、アップグレードの前に、証明書と秘密鍵で `console-tls` Secret を作成します。 -Next, [create a Tenant](./tenant.md). \ No newline at end of file +次に、[Tenant を作成](./tenant.md)します。 diff --git a/content/ja/installation/cloud-native/operator/kms.md b/content/ja/installation/cloud-native/operator/kms.md index 60c89950f..a0ea39f82 100644 --- a/content/ja/installation/cloud-native/operator/kms.md +++ b/content/ja/installation/cloud-native/operator/kms.md @@ -1,17 +1,17 @@ --- -title: KMS Integration -description: Configure local or HashiCorp Vault key management for a RustFS Tenant through the Operator encryption API. +title: KMS 連携 +description: Operator の暗号化 API を通じて、RustFS の Tenant にローカルまたは HashiCorp Vault のキー管理を設定します。 --- -Configure Key Management Service (KMS) integration through `spec.encryption`. Do not add `RUSTFS_KMS_*` variables to `spec.env`; the Operator generates them from the structured Tenant configuration and Secret references. +`spec.encryption` でキー管理サービス（KMS）の連携を設定します。`RUSTFS_KMS_*` 変数を `spec.env` へ追加してはなりません。Operator は、構造化された Tenant の設定と Secret の参照から、これらの変数を生成します。 -## Choose a backend +## バックエンドを選ぶ -Use `local` only for a single-server Tenant. Use `vault` for distributed deployments where every Tenant Pod can reach HashiCorp Vault. +`local` は、サーバーが 1 台の Tenant に限り使います。すべての Tenant Pod が HashiCorp Vault へ到達できる分散デプロイでは、`vault` を使います。 -## Local KMS +## ローカル KMS -Create a master key Secret: +マスターキーの Secret を作成します。 ```yaml title="local-kms-secret.yaml" apiVersion: v1 @@ -24,7 +24,7 @@ stringData: local-master-key: "replace-with-a-random-master-key" ``` -Add the encryption block to the existing Tenant manifest: +既存の Tenant マニフェストに、encryption ブロックを追加します。 ```yaml title="tenant.yaml" spec: @@ -39,11 +39,11 @@ spec: defaultKeyId: tenant-default ``` -The key directory must be inside a mounted data path so it survives Pod replacement. +キーディレクトリは、マウントされたデータパスの内部にある必要があります。これにより、Pod が置き換わっても残ります。 -## HashiCorp Vault KMS +## HashiCorp Vault の KMS -Create a Secret containing a Vault token: +Vault トークンを含む Secret を作成します。 ```yaml title="vault-kms-secret.yaml" apiVersion: v1 @@ -56,7 +56,7 @@ stringData: vault-token: "replace-with-vault-token" ``` -Add the Vault configuration to the existing Tenant manifest: +既存の Tenant マニフェストに、Vault の設定を追加します。 ```yaml title="tenant.yaml" spec: @@ -70,9 +70,9 @@ spec: defaultKeyId: tenant-default ``` -Every Tenant Pod must be able to resolve and connect to the Vault endpoint and trust its certificate. +すべての Tenant Pod は、Vault のエンドポイントを名前解決して接続でき、その証明書を信頼する必要があります。 -## Apply the configuration +## 設定を適用する ```bash kubectl apply -f local-kms-secret.yaml @@ -80,10 +80,10 @@ kubectl apply -f tenant.yaml kubectl -n storage-a describe tenant tenant-a ``` -For Vault, apply `vault-kms-secret.yaml` before `tenant.yaml`. Changing encryption settings rolls the affected StatefulSets. +Vault の場合は、`tenant.yaml` の前に `vault-kms-secret.yaml` を適用します。暗号化の設定を変更すると、影響を受ける StatefulSet がローリング更新されます。 -:::warning[Protect encryption keys] +:::warning[暗号鍵を保護する] -Back up key material and test recovery before storing production data. Losing the local master key or Vault keys can make encrypted objects unrecoverable. +本番データを保存する前に、鍵材料をバックアップし、復旧をテストします。ローカルのマスターキーまたは Vault の鍵を失うと、暗号化されたオブジェクトを復旧できなくなる可能性があります。 -::: \ No newline at end of file +::: diff --git a/content/ja/installation/cloud-native/operator/pool-expansion.md b/content/ja/installation/cloud-native/operator/pool-expansion.md index 482c99b54..1dc495710 100644 --- a/content/ja/installation/cloud-native/operator/pool-expansion.md +++ b/content/ja/installation/cloud-native/operator/pool-expansion.md @@ -1,28 +1,28 @@ --- -title: Pool Expansion -description: Add storage capacity to a RustFS Tenant by appending a storage pool. +title: ストレージプールの拡張 +description: ストレージプールを追加して、RustFS の Tenant のストレージ容量を増やします。 --- -All pools in a Tenant form one RustFS cluster. Add capacity by appending a new pool to `spec.pools`; do not change the shape of an existing pool. +Tenant 内のすべてのプールは、1 つの RustFS クラスターを構成します。容量を増やすには `spec.pools` へ新しいプールを追加します。既存のプールの構成は変更しません。 -:::warning[Existing pools are immutable] +:::warning[既存のプールは不変です] -Do not change `servers` or `persistence.volumesPerServer` on an existing pool. The Operator creates an immutable StatefulSet for each pool. +既存のプールの `servers` と `persistence.volumesPerServer` は変更してはなりません。Operator は、プールごとに不変の StatefulSet を作成します。 ::: -## 1. Check the Tenant +## 1. Tenant を確認する ```bash kubectl -n storage-a get tenant tenant-a kubectl -n storage-a get pods,pvc -l rustfs.tenant=tenant-a ``` -Confirm that the Tenant is `Ready` and the cluster has enough compute and storage capacity. +Tenant が `Ready` であり、クラスターに十分な計算資源とストレージ容量があることを確認します。 -## 2. Add a pool +## 2. プールを追加する -Append the following entry to the existing `spec.pools` list in `tenant.yaml`. Keep all existing entries unchanged. +`tenant.yaml` にある既存の `spec.pools` リストの末尾に、次のエントリを追加します。既存のエントリはすべてそのままにします。 ```yaml title="tenant.yaml" - name: pool-1 @@ -38,13 +38,13 @@ Append the following entry to the existing `spec.pools` list in `tenant.yaml`. K storage: 100Gi ``` -This pool creates four PVCs: two servers multiplied by two volumes per server. Apply the complete Tenant manifest: +このプールは PVC を 4 つ作成します。サーバー 2 台 × サーバーあたりのボリューム 2 つです。Tenant マニフェスト全体を適用します。 ```bash kubectl apply -f tenant.yaml ``` -## 3. Watch the expansion +## 3. 拡張を監視する ```bash kubectl -n storage-a get tenant tenant-a -w @@ -52,4 +52,4 @@ kubectl -n storage-a get pods,pvc \ -l rustfs.pool=pool-1 ``` -Wait for the Tenant to return to `Ready` before making another topology change. Increasing an existing PVC size is a separate Kubernetes storage operation and depends on the StorageClass. \ No newline at end of file +次のトポロジー変更の前に、Tenant が `Ready` に戻るまで待ちます。既存 PVC のサイズを増やす操作は、これとは別の Kubernetes ストレージ操作であり、StorageClass に依存します。 diff --git a/content/ja/installation/cloud-native/operator/tenant.md b/content/ja/installation/cloud-native/operator/tenant.md index 08bec042f..4c45d729e 100644 --- a/content/ja/installation/cloud-native/operator/tenant.md +++ b/content/ja/installation/cloud-native/operator/tenant.md @@ -1,13 +1,13 @@ --- -title: Multi-Tenant -description: Create isolated RustFS Tenants and access their S3 API and Console services. +title: マルチテナント +description: 分離された RustFS の Tenant を作成し、その S3 API と Console の Service へアクセスします。 --- -A `Tenant` represents one independent RustFS cluster. Use a separate namespace, credentials Secret, and Tenant resource for each team or workload. +`Tenant` は、独立した 1 つの RustFS クラスターを表します。チームまたはワークロードごとに、別々の名前空間、認証情報の Secret、Tenant リソースを使います。 -## 1. Create a namespace and credentials +## 1. 名前空間と認証情報を作成する -Create the Secret directly so credentials are not stored in a manifest: +認証情報がマニフェストに残らないよう、Secret を直接作成します。 ```bash kubectl create namespace storage-a @@ -16,9 +16,9 @@ kubectl -n storage-a create secret generic rustfs-tenant-creds \ --from-literal=secretkey='' ``` -## 2. Define the Tenant +## 2. Tenant を定義する -This development example creates one RustFS Pod and one `10Gi` PVC. Replace `standard` with a StorageClass in your cluster. +この開発用の例は、RustFS の Pod を 1 つと `10Gi` の PVC を 1 つ作成します。`standard` は、クラスター内の StorageClass に置き換えます。 ```yaml title="tenant.yaml" apiVersion: rustfs.com/v1alpha1 @@ -44,7 +44,7 @@ spec: storage: 10Gi ``` -## 3. Apply and verify +## 3. 適用して確認する ```bash kubectl apply -f tenant.yaml @@ -52,23 +52,23 @@ kubectl -n storage-a get tenant,pods,pvc,svc kubectl -n storage-a describe tenant tenant-a ``` -## 4. Access RustFS +## 4. RustFS にアクセスする ```bash kubectl -n storage-a port-forward svc/tenant-a-io 9000:9000 kubectl -n storage-a port-forward svc/tenant-a-console 9001:9001 ``` -Run the commands in separate terminals. Use `http://localhost:9000` as the S3 endpoint and open `http://localhost:9001` for the Tenant Console. +各コマンドは別々のターミナルで実行します。S3 エンドポイントには `http://localhost:9000` を使い、Tenant の Console は `http://localhost:9001` を開きます。 -To add another Tenant, repeat the process with a different namespace, Secret, and Tenant name. List all managed Tenants with: +別の Tenant を追加するには、異なる名前空間、Secret、Tenant 名で同じ手順を繰り返します。管理している Tenant をすべて表示します。 ```bash kubectl get tenants --all-namespaces ``` -:::warning[Production topology] +:::warning[本番のトポロジー] -The one-server example is for evaluation. Production Tenants need a distributed pool layout, resource requests, scheduling constraints, and an immutable image reference. +サーバー 1 台の例は評価用です。本番の Tenant には、分散プールのレイアウト、リソース要求、スケジューリング制約、不変のイメージ参照が必要です。 -::: \ No newline at end of file +::: diff --git a/content/ja/installation/container/docker.md b/content/ja/installation/container/docker.md index c88d61007..51245045b 100644 --- a/content/ja/installation/container/docker.md +++ b/content/ja/installation/container/docker.md @@ -1,33 +1,33 @@ --- title: "Docker" -description: "Run RustFS with Docker: single-node setup, host-directory permissions, Docker Compose, TLS, and multi-node deployment." +description: "Docker で RustFS を実行するときの、シングルノード構成、ホストディレクトリの権限、Docker Compose、TLS、マルチノードデプロイを説明します。" --- -This page covers running the official RustFS image with Docker: a single-node instance with persistent storage, host-directory permissions for the non-root container user, Docker Compose with optional observability services, TLS, and a multi-node deployment. You need a working Docker Engine and permission to run containers. +このページでは、公式の RustFS イメージを Docker で実行する方法を説明します。永続ストレージを使ったシングルノードのインスタンス、root 以外のコンテナユーザー向けホストディレクトリの権限、任意のオブザーバビリティサービスを含む Docker Compose、TLS、マルチノードデプロイを扱います。動作する Docker Engine と、コンテナを実行する権限が必要です。 -## 1. Prerequisites +## 1. 前提条件 -* Docker Engine (≥ 20.10) installed and able to pull images and run containers normally -* Host ports 9000 (S3 API) and 9001 (Console) available, or consistent with your custom ports -* If you bind-mount a host directory, the directory owner must match the container user — see [Bind-mount a host directory](#bind-mount-a-host-directory) +* Docker Engine（20.10 以上）がインストールされ、イメージの取得とコンテナの実行ができること +* ホストのポート 9000（S3 API）と 9001（Console）が空いていること。使う予定のカスタムポートでも構いません +* ホストディレクトリをバインドマウントする場合、ディレクトリの所有者はコンテナユーザーと一致している必要があります。[ホストディレクトリをバインドマウントする](#bind-mount-a-host-directory)を参照してください -## 2. Pull the image +## 2. イメージを取得する ```bash docker pull rustfs/rustfs:latest ``` -## 3. Create persistent storage +## 3. 永続ストレージを作成する -Create a named volume so object data remains available when you replace the container: +コンテナを置き換えてもオブジェクトデータが残るよう、名前付きボリュームを作成します。 ```bash docker volume create rustfs-data ``` -## 4. Start RustFS +## 4. RustFS を起動する -Replace the credential placeholders before running the container: +コンテナを実行する前に、認証情報のプレースホルダーを置き換えます。 ```bash docker run -d \ @@ -47,15 +47,15 @@ docker run -d \ /data ``` -:::warning[Set credentials when creating the container] +:::warning[コンテナ作成時に認証情報を設定する] -Set unique `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET_KEY` environment variables before exposing RustFS to a network. Do not use the well-known `rustfsadmin` value for either credential. If the container was started without custom credentials, stop and recreate it with both `-e` options shown above; the `rustfs-data` volume remains intact. +ネットワークへ公開する前に、一意の `RUSTFS_ACCESS_KEY` と `RUSTFS_SECRET_KEY` を環境変数で設定します。どちらの認証情報にも、広く知られている `rustfsadmin` は使わないでください。カスタムの認証情報なしでコンテナを起動した場合は、停止し、上記の両方の `-e` オプションを付けて再作成します。`rustfs-data` ボリュームはそのまま残ります。 ::: -### Environment variables or command-line flags +### 環境変数またはコマンドラインフラグ -The example above configures RustFS with environment variables. You can pass the same settings as command-line flags instead; when both are present, command-line flags win: +上の例では、環境変数で RustFS を設定しています。同じ設定は、コマンドラインフラグでも渡せます。両方が指定されている場合は、コマンドラインフラグが優先されます。 ```bash docker run -d \ @@ -71,40 +71,40 @@ docker run -d \ /data ``` -## 5. Bind-mount a host directory +## 5. ホストディレクトリをバインドマウントする [#bind-mount-a-host-directory] -The named volume above needs no extra setup. If you mount a host directory instead (`-v /path/on/host:/data`), keep in mind that the container runs as non-root user `rustfs` with id `10001`. Make the host directory owned by `10001`, otherwise you will encounter permission denied errors: +上の名前付きボリュームには、追加の準備は不要です。ホストディレクトリをマウントする場合（`-v /path/on/host:/data`）、コンテナは id が `10001` の root 以外のユーザー `rustfs` として動作します。ホストディレクトリの所有者を `10001` にします。そうしないと、permission denied（権限拒否）エラーが発生します。 ```bash chown -R 10001:10001 /path/to/host_directory ``` -## 6. Verify the deployment +## 6. デプロイを確認する -Check the container and the S3 API health endpoint: +コンテナと、S3 API のヘルスチェックエンドポイントを確認します。 ```bash docker ps --filter name=rustfs curl --fail http://localhost:9000/health ``` -The S3 API is available at `http://localhost:9000`, and the Console is available at `http://localhost:9001`. +S3 API は `http://localhost:9000` で、Console は `http://localhost:9001` で利用できます。 ## Docker Compose -The RustFS repository ships a [`docker-compose.yml`](https://github.com/rustfs/rustfs/blob/main/docker-compose.yml) that includes `grafana`, `prometheus`, `otel-collector`, and `jaeger` services, mainly for observability. To deploy RustFS together with these services, clone the [RustFS code repository](https://github.com/rustfs/rustfs) locally: +RustFS のリポジトリには、主にオブザーバビリティ向けの `grafana`、`prometheus`、`otel-collector`、`jaeger` サービスを含む [`docker-compose.yml`](https://github.com/rustfs/rustfs/blob/main/docker-compose.yml) があります。これらのサービスと一緒に RustFS をデプロイするには、[RustFS のコードリポジトリ](https://github.com/rustfs/rustfs) をローカルにクローンします。 ```bash git clone https://github.com/rustfs/rustfs.git ``` -Run the command from the repository root: +リポジトリのルートで、次のコマンドを実行します。 ```bash docker compose --profile observability up -d ``` -The compose file uses an initialization container to grant the correct access rights to `rustfs`: the `rustfs_perms` service below changes the ownership of the mounted volumes to `10001` before `rustfs` starts, using `depends_on` to wait for it to complete. To keep logs persistent and accessible, the host log directory is mapped to the container's `/var/log/rustfs/` path: +compose ファイルは、初期化コンテナで `rustfs` に正しいアクセス権を付与します。次の `rustfs_perms` サービスは、`rustfs` の起動前に、マウントしたボリュームの所有者を `10001` へ変更します。`depends_on` により、この処理の完了を待ってから起動します。ログを永続化し、あとから参照できるように、ホストのログディレクトリをコンテナ内の `/var/log/rustfs/` にマッピングします。 ```yaml title="docker-compose.yml" services: @@ -134,21 +134,21 @@ The compose file uses an initialization container to grant the correct access ri # ... other configurations ``` -If you only want RustFS without Grafana, Prometheus, and the other observability services, start just the `rustfs` service (the compose file marks the collector dependency as optional): +Grafana、Prometheus、その他のオブザーバビリティサービスなしで RustFS だけを起動する場合は、`rustfs` サービスだけを起動します。compose ファイルでは、コレクターへの依存関係は任意です。 ```bash docker compose -f docker-compose.yml up -d rustfs ``` -This starts only the `rustfs-server` container. Whether you start only `rustfs-server` or the full stack, the S3 API is served at `http://localhost:9000`, and the RustFS Console is at `http://localhost:9001`. Open the Console in a browser and log in with the access key and secret key you configured above. Generate a strong secret with, for example, `openssl rand -base64 24`, and never ship the placeholder values to production. +これにより、`rustfs-server` コンテナだけが起動します。`rustfs-server` だけを起動する場合も、フルスタックを起動する場合も、S3 API は `http://localhost:9000` で、RustFS Console は `http://localhost:9001` で提供されます。ブラウザで Console を開き、上で設定したアクセスキーとシークレットキーでログインします。強力なシークレットは、たとえば `openssl rand -base64 24` で生成します。プレースホルダーの値を本番環境へデプロイしないでください。 -For Docker Compose, define unique `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET_KEY` values in the `rustfs` service environment or in the environment file used for variable substitution, then recreate the service with `docker compose up -d rustfs`. +Docker Compose では、`rustfs` サービスの環境設定、または変数置換に使う環境ファイルに、一意の `RUSTFS_ACCESS_KEY` と `RUSTFS_SECRET_KEY` を定義します。その後、`docker compose up -d rustfs` でサービスを再作成します。 -## Multi-node deployment +## マルチノードデプロイ -Docker's default bridge networking does not support multi-node deployments. Use `--network host` so each container can communicate directly with other nodes. +Docker のデフォルトの bridge ネットワークは、マルチノードデプロイに対応していません。各コンテナがほかのノードと直接通信できるよう、`--network host` を使います。 -Run the following on **each node**: +**各ノード**で次を実行します。 ```bash docker run -d \ @@ -166,7 +166,7 @@ docker run -d \ rustfs/rustfs:latest ``` -Add the entries to `/etc/hosts` on **every** node: +**すべての**ノードの `/etc/hosts` に、次のエントリを追加します。 ```ini title="/etc/hosts" 192.168.1.1 node1 @@ -175,21 +175,21 @@ Add the entries to `/etc/hosts` on **every** node: 192.168.1.4 node4 ``` -## TLS configuration +## TLS の設定 -If [using TLS](../../integration/tls-configured.md), mount the certificate directory and point RustFS at it: +[TLS を使う](../../integration/tls-configured.md)場合は、証明書ディレクトリをマウントし、そのパスを RustFS に指定します。 ```bash -v /path/to/certs:/certs \ -e RUSTFS_TLS_PATH=/certs \ ``` -## Before production +## 本番環境の前に -Work through the [Pre-Installation Checklists](../requirement/checklists/index.md) — hardware, network, software, and security — before deploying to production. Use a multi-node deployment architecture, [enable TLS encrypted communication](../../integration/tls-configured.md), configure a log rotation strategy, and set up a regular backup strategy. +本番へデプロイする前に、[インストール前チェックリスト](../requirement/checklists/index.md)（ハードウェア、ネットワーク、ソフトウェア、セキュリティ）を確認します。マルチノードデプロイを使い、[TLS を有効にし](../../integration/tls-configured.md)、ログローテーションを設定し、定期的なバックアップを計画します。 -## Next steps +## 次のステップ -- [RustFS Console](/administration/console) -- [Configure an S3 client](../../developer/examples/aws-cli.md) -- [TLS configuration](../../integration/tls-configured.md) +- [RustFS Console](/ja/administration/console) +- [S3 クライアントを設定する](../../developer/examples/aws-cli.md) +- [TLS の設定](../../integration/tls-configured.md) diff --git a/content/ja/installation/container/index.md b/content/ja/installation/container/index.md index 4ee47b47d..99ee37383 100644 --- a/content/ja/installation/container/index.md +++ b/content/ja/installation/container/index.md @@ -1,20 +1,20 @@ --- -title: "Container" -description: "Run the official RustFS container image with Docker or Podman." +title: "コンテナ" +description: "公式の RustFS コンテナイメージを、Docker または Podman で実行します。" --- -RustFS is a high-performance, S3-compatible open-source distributed object storage system. In single-node single-disk (SNSD) deployment mode, the backend uses zero erasure coding without additional data redundancy, which makes it suitable for local testing and small-scale scenarios. The official RustFS image packages the RustFS binary and its runtime environment into a container, so you can start a service with a single command and persistent storage. +RustFS は、オープンソースの S3 互換分散オブジェクトストレージシステムです。シングルノード・シングルディスク（SNSD）モードでは、RustFS はイレイジャーコーディングを使わず、冗長データも保存しません。そのため、このモードはローカルでのテストと小さなワークロードにだけ適しています。公式の RustFS イメージは、RustFS のバイナリと実行環境をコンテナにまとめているため、1 つのコマンドで永続ストレージ付きの RustFS を起動できます。 -The container runs as non-root user `rustfs` with id `10001`, so a bind-mounted host directory must be owned by `10001` to avoid permission denied errors. +コンテナは、id が `10001` の root 以外のユーザー `rustfs` として動作します。バインドマウントするホストディレクトリの所有者は `10001` である必要があります。そうしないと、permission denied（権限拒否）エラーが発生します。 -## Container runtimes +## コンテナランタイム -- [Docker](./docker.md): run a single-node instance with persistent storage, then extend it with Docker Compose, TLS, and multi-node networking. -- [Podman](./podman.md): run the same image in a daemonless workflow. +- [Docker](./docker.md): 永続ストレージを使ってシングルノードのインスタンスを実行し、Docker Compose、TLS、マルチノードのネットワークへ拡張します。 +- [Podman](./podman.md): デーモンなしのワークフローで、同じイメージを実行します。 -:::note[Directory permissions] +:::note[ディレクトリの権限] -If you mount a host directory into the container with `-v`, make sure the owner of the host directory is `10001`: +`-v` でホストディレクトリをコンテナにマウントする場合は、ホストディレクトリの所有者が `10001` であることを確認します。 ```bash chown -R 10001:10001 /path/to/host_directory @@ -22,4 +22,4 @@ chown -R 10001:10001 /path/to/host_directory ::: -For Kubernetes deployments, see the [Helm chart](/installation/cloud-native/helm-chart) or the [Operator](/installation/cloud-native/operator) instead. +Kubernetes へのデプロイは、[Helm チャート](/ja/installation/cloud-native/helm-chart)または [Operator](/ja/installation/cloud-native/operator) を参照してください。 diff --git a/content/ja/installation/container/podman.md b/content/ja/installation/container/podman.md index 9ce2a6fcd..21c88f151 100644 --- a/content/ja/installation/container/podman.md +++ b/content/ja/installation/container/podman.md @@ -1,27 +1,27 @@ --- title: "Podman" -description: "Run a single-node RustFS instance with Podman and persistent container storage." +description: "Podman と永続的なコンテナストレージを使い、シングルノードの RustFS インスタンスを実行します。" --- -Podman can run the official RustFS Open Container Initiative (OCI) image without a daemon. You need a working Podman installation and permission to create containers. +Podman は、デーモンなしで公式の RustFS Open Container Initiative（OCI）イメージを実行できます。動作する Podman のインストールと、コンテナを作成する権限が必要です。 -## 1. Pull the image +## 1. イメージを取得する ```bash podman pull docker.io/rustfs/rustfs:latest ``` -## 2. Create persistent storage +## 2. 永続ストレージを作成する -Create a named volume so object data remains available when you replace the container: +コンテナを置き換えてもオブジェクトデータが残るよう、名前付きボリュームを作成します。 ```bash podman volume create rustfs-data ``` -:::note[Bind-mounting a host directory] +:::note[ホストディレクトリのバインドマウント] -The named volume above needs no extra setup. If you bind-mount a host directory instead, keep in mind that the container runs as non-root user `rustfs` with id `10001`. Make the host directory owned by `10001`, otherwise you will encounter permission denied errors: +上の名前付きボリュームには、追加の準備は不要です。ホストディレクトリをバインドマウントする場合、コンテナは id が `10001` の root 以外のユーザー `rustfs` として動作します。ホストディレクトリの所有者を `10001` にします。そうしないと、permission denied（権限拒否）エラーが発生します。 ```bash chown -R 10001:10001 /path/to/host_directory @@ -29,9 +29,9 @@ chown -R 10001:10001 /path/to/host_directory ::: -## 3. Start RustFS +## 3. RustFS を起動する -Replace the credential placeholders before running the container: +コンテナを実行する前に、認証情報のプレースホルダーを置き換えます。 ```bash podman run -d \ @@ -50,25 +50,25 @@ podman run -d \ /data ``` -:::warning[Set credentials when creating the container] +:::warning[コンテナ作成時に認証情報を設定する] -Set unique `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET_KEY` environment variables before exposing RustFS to a network. Do not use the well-known `rustfsadmin` value for either credential. If the container was started without custom credentials, stop and recreate it with both `-e` options shown above; the `rustfs-data` volume remains intact. +ネットワークへ公開する前に、一意の `RUSTFS_ACCESS_KEY` と `RUSTFS_SECRET_KEY` を環境変数で設定します。どちらの認証情報にも、広く知られている `rustfsadmin` は使わないでください。カスタムの認証情報なしでコンテナを起動した場合は、停止し、上記の両方の `-e` オプションを付けて再作成します。`rustfs-data` ボリュームはそのまま残ります。 ::: -## 4. Verify the deployment +## 4. デプロイを確認する -Check the container and the S3 API health endpoint: +コンテナと、S3 API のヘルスチェックエンドポイントを確認します。 ```bash podman ps --filter name=rustfs curl --fail http://localhost:9000/health ``` -The S3 API is available at `http://localhost:9000`, and the Console is available at `http://localhost:9001`. +S3 API は `http://localhost:9000` で、Console は `http://localhost:9001` で利用できます。 -## Next steps +## 次のステップ -- [RustFS Console](/administration/console) -- [Configure an S3 client](../../developer/examples/aws-cli.md) -- [TLS configuration](../../integration/tls-configured.md) +- [RustFS Console](/ja/administration/console) +- [S3 クライアントを設定する](../../developer/examples/aws-cli.md) +- [TLS の設定](../../integration/tls-configured.md) diff --git a/content/ja/installation/index.md b/content/ja/installation/index.md index fedf60619..99315ed6d 100644 --- a/content/ja/installation/index.md +++ b/content/ja/installation/index.md @@ -1,43 +1,43 @@ --- -title: "Installation" -description: "Choose the right RustFS deployment path: local trial, single-node or multi-node production, containers, and Kubernetes." +title: "インストール" +description: "ローカルでの試用、シングルノードまたはマルチノードの本番、コンテナ、Kubernetes の中から、目的に合った RustFS のデプロイ方法を選びます。" --- -RustFS is a distributed object storage system written in Rust and released under the Apache 2.0 license. It runs on Linux, Windows, macOS, FreeBSD, and containers, across x86, ARM, RISC-V, and other CPU architectures. +RustFS は、Rust で書かれ、Apache 2.0 ライセンスで公開されている分散オブジェクトストレージです。Linux、Windows、macOS、FreeBSD、およびコンテナ上で動作し、x86、ARM、RISC-V などの CPU アーキテクチャに対応しています。 :::warning[開発とデバッグ専用] -Windows 版の RustFS は開発とデバッグ専用で、**本番環境での使用は推奨していません**。本番環境には [Linux](/ja/installation/linux) を推奨します。 +Windows 版の RustFS は、開発とデバッグ専用であり、**本番デプロイには推奨しません**。本番ワークロードには [Linux](/ja/installation/linux) を推奨します。 ::: -:::warning[Change the default credentials immediately] +:::warning[既定の認証情報は直ちに変更する] -After installation, set unique values for `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET_KEY` before exposing RustFS to a network. Do not use the well-known `rustfsadmin` value for either credential. +インストール後、RustFS をネットワークに公開する前に、`RUSTFS_ACCESS_KEY` と `RUSTFS_SECRET_KEY` に一意の値を設定します。よく知られた `rustfsadmin` をいずれの認証情報にも使わないでください。 -- For a Linux binary or systemd installation, set both values in `/etc/default/rustfs`, then restart the `rustfs` service. -- For Docker, Podman, or Docker Compose, pass both values as container environment variables when creating the container. Recreate an existing container if it was started without them. +- Linux バイナリまたは systemd でインストールした場合は、`/etc/default/rustfs` に両方の値を設定し、`rustfs` サービスを再起動します。 +- Docker、Podman、または Docker Compose の場合は、コンテナ作成時に両方の値をコンテナの環境変数として渡します。これらを設定せずに起動した既存のコンテナは、作り直します。 ::: -## Choose Your Path +## 方法を選ぶ -| Your goal | Recommended path | Guide | +| 目的 | 推奨する方法 | ガイド | | - | - | - | -| Try RustFS on a local machine | One-command install script, or a container | [Linux Quick Start](./linux/quick-start.md) · [Container](./container/index.md) | -| Single-server production | SNSD (one disk) or SNMD (multiple disks) | [Installing RustFS on Linux](./linux/index.md) | -| Multi-server production cluster | MNMD, after completing the production checklists | [Multiple Node Multiple Disk](./linux/multiple-node-multiple-disk.md) · [Checklists](./requirement/checklists/index.md) | -| Kubernetes / cloud-native | Container orchestration deployment | [Cloud Native](./cloud-native/index.md) | -| Windows or macOS host | Native installation | [Windows](./windows/index.md) · [macOS](./macos/index.md) | +| ローカルマシンで RustFS を試す | 1 コマンドのインストールスクリプト、またはコンテナ | [Linux クイックスタート](./linux/quick-start.md) · [コンテナ](./container/index.md) | +| 単一サーバーの本番 | SNSD（ディスク 1 台）または SNMD（複数ディスク） | [Linux に RustFS をインストールする](./linux/index.md) | +| 複数サーバーの本番クラスター | 本番チェックリストを完了したうえで MNMD | [マルチノード・マルチディスク（MNMD）](./linux/multiple-node-multiple-disk.md) · [チェックリスト](./requirement/checklists/index.md) | +| Kubernetes / クラウドネイティブ | Helm チャートまたは Operator でデプロイ | [クラウドネイティブ](./cloud-native/index.md) | +| Windows または macOS のホスト | ネイティブインストール | [Windows](./windows/index.md) · [macOS](./macos/index.md) | -## Deployment Mode Comparison +## デプロイ方式の比較 [#deployment-mode-comparison] -| Mode | Nodes | Disks | Fault Tolerance | Typical Use | +| 方式 | ノード | ディスク | 耐障害性 | 主な用途 | | - | - | - | - | - | -| [SNSD](./linux/single-node-single-disk.md) | 1 | 1 | None — rely on backups | Development, testing, low-density non-critical business | -| [SNMD](./linux/single-node-multiple-disk.md) | 1 | Multiple | Up to M parity disks within the node | Medium, non-critical business on a single server | -| [MNMD](./linux/multiple-node-multiple-disk.md) | 4+ | Multiple per node | Disk- and node-level via erasure coding across servers | Production workloads | +| [SNSD](./linux/single-node-single-disk.md) | 1 | 1 | なし（バックアップに依存） | 開発、テスト、および小規模で重要度の低いワークロード | +| [SNMD](./linux/single-node-multiple-disk.md) | 1 | 複数 | ノード内で最大 M 台のパリティディスク | 単一サーバー上の中規模で重要度の低いワークロード | +| [MNMD](./linux/multiple-node-multiple-disk.md) | 4 以上 | ノードごとに複数 | サーバー間のイレイジャーコーディングによるディスクおよびノード単位 | 本番ワークロード | -## Checklist +## チェックリスト -Before any production deployment, work through the [Pre-Installation Checklists](./requirement/checklists/index.md) — hardware, network, software, and security — to make sure your environment meets production guidance. +本番デプロイの前に、[インストール前チェックリスト](./requirement/checklists/index.md)（ハードウェア、ネットワーク、ソフトウェア、セキュリティ）を確認し、環境が本番要件を満たしていることを確かめます。 diff --git a/content/ja/installation/linux/index.md b/content/ja/installation/linux/index.md index 8f9f4f1be..7a2394e82 100644 --- a/content/ja/installation/linux/index.md +++ b/content/ja/installation/linux/index.md @@ -1,34 +1,34 @@ --- -title: "Installing RustFS on Linux" -description: "Choose a Linux deployment mode — SNSD, SNMD, or MNMD — and install RustFS on one or more servers." +title: "Linux に RustFS をインストールする" +description: "Linux のデプロイ方式である SNSD、SNMD、MNMD から選び、1 台または複数のサーバーに RustFS をインストールします。" --- -This section covers installing RustFS on Linux servers. For a one-command trial installation, use the [Quick Start](./quick-start.md). For a manual installation, pick one of the three deployment modes below — all three share the same [prerequisites and service setup](./prerequisites-and-service.md), and differ only in topology and volume configuration. +このセクションでは、Linux サーバーへの RustFS のインストールを説明します。1 コマンドで試す場合は [クイックスタート](./quick-start.md) を使います。手動でインストールする場合は、次の 3 つのデプロイ方式から選びます。いずれも同じ [前提条件とサービスのセットアップ](./prerequisites-and-service.md) を使い、異なるのはトポロジーとボリュームの設定だけです。 -:::warning[Change the default credentials immediately] +:::warning[既定の認証情報は直ちに変更する] -After installation, set unique `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET_KEY` values in `/etc/default/rustfs`. Do not use the well-known `rustfsadmin` value for either credential. Restart the service with `sudo systemctl restart rustfs` after changing the file. +インストール後、`/etc/default/rustfs` に一意の `RUSTFS_ACCESS_KEY` と `RUSTFS_SECRET_KEY` を設定します。よく知られた `rustfsadmin` をいずれの認証情報にも使わないでください。ファイルを変更したら、`sudo systemctl restart rustfs` でサービスを再起動します。 ::: -## Single Node Single Disk (SNSD) +## シングルノード・シングルディスク（SNSD） -One server, one data disk. The simplest mode, with no redundancy — a disk failure means data loss, so rely on backups. Suitable for development, testing, and low-density non-critical business. +サーバー 1 台、データディスク 1 台です。最も単純な方式で、冗長性はありません。ディスク障害はデータ損失になるため、バックアップに依存します。開発、テスト、および小規模で重要度の低いワークロードに適しています。 -→ [Single Node Single Disk installation](./single-node-single-disk.md) +→ [シングルノード・シングルディスク（SNSD）のインストール](./single-node-single-disk.md) -## Single Node Multiple Disk (SNMD) +## シングルノード・マルチディスク（SNMD） -One server, multiple data disks. Erasure coding shards data across the disks, so the node tolerates a limited number of disk failures, but a whole-server failure still means data loss. Suitable for medium, non-critical business on a single machine. +サーバー 1 台、データディスク複数台です。イレイジャーコーディングでデータをディスク間に分散するため、ノードは限られた台数のディスク障害に耐えられます。ただし、サーバー全体の障害はデータ損失になります。単一マシン上の中規模で重要度の低いワークロードに適しています。 -→ [Single Node Multiple Disk installation](./single-node-multiple-disk.md) +→ [シングルノード・マルチディスク（SNMD）のインストール](./single-node-multiple-disk.md) -## Multiple Node Multiple Disk (MNMD) +## マルチノード・マルチディスク（MNMD） -Four or more servers, each with one or more disks. Erasure coding spans servers, providing disk- and node-level fault tolerance plus horizontal scalability. This is the mode for production workloads. +4 台以上のサーバーで、各サーバーに 1 台以上のディスクがあります。イレイジャーコーディングがサーバー間にまたがり、ディスクおよびノード単位の耐障害性と水平スケーラビリティを提供します。本番ワークロード向けの方式です。 -→ [Multiple Node Multiple Disk installation](./multiple-node-multiple-disk.md) +→ [マルチノード・マルチディスク（MNMD）のインストール](./multiple-node-multiple-disk.md) -## Before Production +## 本番の前に -Work through the [Pre-Installation Checklists](../requirement/checklists/index.md) — hardware, network, software, and security — before deploying to production. If you don't need production standards, you can skip them. +本番にデプロイする前に、[インストール前チェックリスト](../requirement/checklists/index.md)（ハードウェア、ネットワーク、ソフトウェア、セキュリティ）を確認します。本番以外のデプロイでは省略できます。 diff --git a/content/ja/installation/linux/multiple-node-multiple-disk.md b/content/ja/installation/linux/multiple-node-multiple-disk.md index 797c9cd9e..4870cd569 100644 --- a/content/ja/installation/linux/multiple-node-multiple-disk.md +++ b/content/ja/installation/linux/multiple-node-multiple-disk.md @@ -1,16 +1,16 @@ --- -title: "RustFS Multiple Node Multiple Disk Installation" -description: "Install RustFS on multiple servers with multiple disks, data will be stored on multiple disks across multiple servers." +title: "マルチノード・マルチディスク（MNMD）" +description: "それぞれ複数のディスクを持つ複数のサーバーに、分散 RustFS クラスターをインストールします。" --- -Multiple Node Multiple Disk (MNMD) mode is the deployment mode for production workloads, providing enterprise-grade performance, security, and scalability. A minimum of **4 servers** is required, each with at least 1 disk, to safely start a distributed object storage cluster. +マルチノード・マルチディスク（MNMD）モードは、複数のサーバーにまたがるクラスター向けの本番デプロイです。分散オブジェクトストレージのクラスターを安全に起動するには、最低 **4 台のサーバー**が必要で、各サーバーに少なくとも 1 台のディスクが必要です。 -## Topology and Planning +## トポロジーと計画 -In the following architecture, requests are distributed to the servers through load balancing. With the default 12 + 4 erasure coding layout, each object is split into 12 data shards and 4 parity shards stored on different disks across different servers: +次の構成では、リクエストはロードバランサーを通じて各サーバーに分散されます。既定の 12 + 4 のイレイジャーコーディング配置では、各オブジェクトは 12 個のデータシャードと 4 個のパリティシャードに分割され、異なるサーバー上の異なるディスクに保存されます。 -- Any single server failure or maintenance does not affect data security. -- Corruption of up to 4 disks does not affect data security. +- いずれか 1 台のサーバーが故障した場合や、メンテナンスのために停止した場合でも、クラスターは稼働を続け、データは失われません。 +- 最大 4 台のディスクを失っても、データは失われません。 ```mermaid flowchart TD @@ -29,19 +29,19 @@ flowchart TD class N1D1,N1D2,N1D3,N1D4,N2D1,N2D2,N2D3,N2D4,N3D1,N3D2,N3D3,N3D4,N4D1,N4D2,N4D3,N4D4 disk ``` -Before installation, review the [Pre-Installation Checklists](../requirement/checklists/index.md) and ensure all items meet production guidance. +インストールの前に [インストール前チェックリスト](../requirement/checklists/index.md) を確認し、すべての項目が本番要件を満たしていることを確かめます。 -## Hostnames +## ホスト名 -Creating a RustFS cluster requires **identical, sequential** hostnames. There are two ways to achieve sequential hostnames: +RustFS クラスターには、一貫した連番のホスト名（例: `node1` から `node4`）が必要です。連番のホスト名を用意する方法は 2 つあります。 -**1. DNS Configuration:** +**1. DNS の設定:** -Configure your DNS resolution server to ensure name continuity. +各連番のホスト名が正しいノードに解決されるよう、DNS レコードを作成します。 -**2. HOSTS Configuration:** +**2. `/etc/hosts` の設定:** -Modify the local alias settings in `/etc/hosts` as follows: +すべてのノードの `/etc/hosts` に、次のエントリを追加します。 ```bash title="/etc/hosts" vim /etc/hosts @@ -53,13 +53,13 @@ vim /etc/hosts 192.168.1.4 node4 ``` -## Prerequisites and Service Setup +## 前提条件とサービスのセットアップ -On **every node**, complete the [common prerequisites and service setup](./prerequisites-and-service.md) — operating system, firewall, time synchronization, disk formatting, service user, binary download, and systemd unit — then continue below. Remember that all nodes must use the same listening port and must have synchronized clocks. +**すべてのノード**で、[共通の前提条件とサービスのセットアップ](./prerequisites-and-service.md)（オペレーティングシステム、ファイアウォール、時刻同期、ディスクのフォーマット、サービスユーザー、バイナリのダウンロード、systemd ユニット）を完了してから、以下に進みます。すべてのノードで、待受ポートを同じにし、クロックを同期させる必要があります。 -## Configure Environment Variables +## 環境変数を設定する -1. Create the same configuration file on every node. `RUSTFS_VOLUMES` uses brace expansion to enumerate all nodes and all disk mount points (this example: 4 nodes × 4 disks): +1. すべてのノードに同じ設定ファイルを作成します。`RUSTFS_VOLUMES` は、ブレース展開ですべてのノードとすべてのディスクマウントポイントを列挙します（この例: 4 ノード × 4 ディスク）。 ```ini title="/etc/default/rustfs" # Use a unique access key and a strong, random secret (e.g. openssl rand -base64 24) @@ -75,49 +75,49 @@ RUSTFS_OBS_LOG_DIRECTORY="/var/log/rustfs/" :::note -The access key, secret key, and `RUSTFS_VOLUMES` value must be identical on all nodes. The hostnames (`node1` – `node4`) must match the DNS or `/etc/hosts` configuration above. +アクセスキー、シークレットキー、および `RUSTFS_VOLUMES` の値は、すべてのノードで同一である必要があります。ホスト名（`node1` ～ `node4`）は、上記の DNS または `/etc/hosts` の設定と一致している必要があります。 ::: -2. Create the storage and log directories on every node: +2. すべてのノードで、ストレージとログのディレクトリを作成します。 ```bash sudo mkdir -p /data/rustfs{0..3} /var/log/rustfs /opt/tls sudo chmod -R 750 /data/rustfs* /var/log/rustfs ``` -## Start Service and Verification +## サービスを起動して確認する -1. Start the service on every node and enable auto-start on boot: +1. すべてのノードでサービスを起動し、起動時の自動開始を有効にします。 ```bash sudo systemctl enable --now rustfs ``` -2. Verify the service status: +2. サービスの状態を確認します。 ```bash systemctl status rustfs ``` -3. Check the service port: +3. サービスのポートを確認します。 ```bash netstat -ntpl ``` -4. View log files: +4. ログファイルを表示します。 ```bash tail -f /var/log/rustfs/rustfs*.log ``` -5. Access the console: enter any node's IP address (or the load balancer address) and the console port (default 9001) in a browser. You should see: +5. Console にアクセスします。ブラウザーに任意のノードの IP アドレス（またはロードバランサーのアドレス）と Console のポート（既定は 9001）を入力すると、次のように表示されます。 -![Console](./images/console.jpg) +![Console の画面](./images/console.jpg) -## Next Steps +## 次のステップ -- Put a load balancer in front of the cluster — see the [Nginx integration guide](/developer/integration/reverse-proxy/nginx). -- Enable TLS for production traffic — see [TLS configuration](../../integration/tls-configured.md). -- Review [Pool Expansion](../../operations/scaling/storage-pool-expansion.md) before scaling. +- クラスターの前段にロードバランサーを置きます。[Nginx 連携ガイド](/ja/developer/integration/reverse-proxy/nginx) を参照します。 +- 本番トラフィックでは TLS を有効にします。[TLS の設定](../../integration/tls-configured.md) を参照します。 +- スケールする前に、[ストレージプールの拡張](../../operations/scaling/storage-pool-expansion.md) を確認します。 diff --git a/content/ja/installation/linux/prerequisites-and-service.md b/content/ja/installation/linux/prerequisites-and-service.md index 606b43dc6..a622e766c 100644 --- a/content/ja/installation/linux/prerequisites-and-service.md +++ b/content/ja/installation/linux/prerequisites-and-service.md @@ -225,7 +225,7 @@ XFS が RustFS のワークロードに適する理由は 3 つあります。 - **巨大なファイルと大きなファイルサイズ**: XFS は 64 ビットのファイルシステムで、非常に大きなファイル（最大 8 EB）を扱えます。1 つのディレクトリに数百万のファイルがあっても、メタデータ管理の効率を保てます。RustFS は各オブジェクト（またはオブジェクトバージョン）を独立したファイルとして保存するため、この特性が重要です。 - **領域の予約**: XFS は効率的な `fallocate` API を提供します。RustFS はオブジェクトの書き込み前に連続したディスク領域を予約し、書き込み中の動的拡張とメタデータ更新のオーバーヘッドを避け、ファイルの断片化を抑えます。 -ディスクを識別しやすくするため、XFS のフォーマット時に **Label** を使うことを推奨します。 +ディスクを識別し、マウントしやすくするため、フォーマット時にファイルシステムラベル（`-L`）を付けることを推奨します。 まずディスク構成を確認します。 diff --git a/content/ja/installation/linux/quick-start.md b/content/ja/installation/linux/quick-start.md index b3afc15eb..8ff91aa38 100644 --- a/content/ja/installation/linux/quick-start.md +++ b/content/ja/installation/linux/quick-start.md @@ -1,26 +1,26 @@ --- -title: "Quick Start" -description: "Install RustFS with the one-click script, log in to the Console, and store your first object — in about ten minutes." +title: "クイックスタート" +description: "インストールスクリプトで RustFS を導入し、Console にログインして最初のオブジェクトを保存するまでの手順を、約 10 分で説明します。" --- -This guide takes you from an empty Linux server to a working RustFS instance: install, log in to the Console, create a bucket, and upload your first object. Production planning (multi-node layout, hardware sizing) is deliberately left for [the next step](#next-steps). +このガイドでは、空の Linux サーバーから動作する RustFS インスタンスまで進めます。インストールし、Console にログインし、バケットを作成して、最初のオブジェクトをアップロードします。本番の計画（マルチノード構成、ハードウェアのサイジング）は、意図的に [次のステップ](#next-steps) に残しています。 -**Prerequisites** +**前提条件** -- A Linux server (x86_64 or aarch64) with `systemd`, and root or sudo access -- `unzip` installed, and outbound network access to download the package -- Ports `9000` (S3 API) and `9001` (Console) reachable from your machine -- [`rc`](/operations/rc) installed on your workstation for the command-line verification workflow +- `systemd` を備えた Linux サーバー（x86_64 または aarch64）と、root または sudo の権限 +- `unzip` がインストール済みで、パッケージをダウンロードできる外向きのネットワークアクセスがあること +- 手元のマシンからポート `9000`（S3 API）と `9001`（Console）に到達できること +- コマンドラインでの確認に使う [`rc`](/ja/operations/rc) がワークステーションにインストール済みであること -## 1. Install and start RustFS +## 1. RustFS をインストールして起動する -Run the official installation script: +公式のインストールスクリプトを実行します。 ```bash curl -O https://rustfs.com/install_rustfs.sh && bash install_rustfs.sh ``` -The script installs the binary to `/usr/local/bin/rustfs`, registers a `rustfs` systemd service, and starts it. By default it stores data in `/data/rustfs0` and listens on port `9000` (S3 API) and `9001` (Console); the data path and ports can be adjusted during installation. On success it prints a summary like: +スクリプトはバイナリを `/usr/local/bin/rustfs` にインストールし、`rustfs` の systemd サービスを登録して起動します。既定ではデータを `/data/rustfs0` に保存し、ポート `9000`（S3 API）と `9001`（Console）で待ち受けます。データパスとポートはインストール中に変更できます。成功すると、次のような要約が表示されます。 ```text RustFS has been installed and started successfully! @@ -30,41 +30,41 @@ Service port: 9000, Console port: 9001, Data directory: /data/rustfs0 Config file: /etc/default/rustfs ``` -## 2. Set your credentials +## 2. 認証情報を設定する -The generated config file ships placeholder credentials. Set your own access key and secret key, then restart the service: +生成された設定ファイルには、プレースホルダーの認証情報が入っています。独自のアクセスキーとシークレットキーを設定し、サービスを再起動します。 ```ini title="/etc/default/rustfs" {1,2} RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ; e.g. output of: openssl rand -base64 24 ``` -Use an uppercase alphanumeric access key. Do not use unmodified Base64 output for `RUSTFS_ACCESS_KEY`, because Base64 can contain `/`, which conflicts with the AWS Signature Version 4 credential scope. See [Credential Management](/operations/credentials) for details. +アクセスキーには大文字の英数字を使います。`RUSTFS_ACCESS_KEY` に、加工していない Base64 の出力を使わないでください。Base64 には `/` が含まれることがあり、AWS Signature Version 4 の認証情報スコープと衝突します。詳細は [認証情報の管理](/ja/operations/credentials) を参照してください。 ```bash sudo systemctl restart rustfs sudo systemctl status rustfs --no-pager # should report: active (running) ``` -:::warning[Do not keep default credentials] +:::warning[既定の認証情報を残さない] -If `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` are not set, the server falls back to the built-in default `rustfsadmin` / `rustfsadmin` — acceptable for a throwaway local test, never for anything reachable by others. +`RUSTFS_ACCESS_KEY` と `RUSTFS_SECRET_KEY` が未設定の場合、サーバーは組み込みの既定値 `rustfsadmin` / `rustfsadmin` を使います。使い捨てのローカルテストでは許容できますが、ほかの人から到達できる環境では使わないでください。 ::: -## 3. Log in to the Console +## 3. Console にサインインする -Open `http://:9001` in your browser and sign in with the access key and secret key from step 2. +ブラウザーで `http://:9001` を開き、手順 2 のアクセスキーとシークレットキーでサインインします。 -![RustFS Console login](./images/console.jpg) +![RustFS Console のログイン画面](./images/console.jpg) -## 4. Create a bucket and upload a file +## 4. バケットを作成してファイルをアップロードする -1. In the Console home page, select **Create Bucket**, name it (for example `my-bucket`), and confirm. -2. Open the bucket and use the upload action to add any local file. -3. Click the uploaded object to view its details — you have a working object store. +1. Console のホーム画面で **Create Bucket**（バケットの作成）を選び、名前（例: `my-bucket`）を付けて確定します。 +2. バケットを開き、アップロード操作で任意のローカルファイルを追加します。 +3. アップロードしたオブジェクトをクリックして詳細を確認します。これでオブジェクトストレージが動作しています。 -Prefer the command line? Configure [`rc`](/operations/rc), then perform the same operations: +コマンドラインを使う場合は、[`rc`](/ja/operations/rc) を設定してから同じ操作を行います。 ```bash rc alias set rustfs http://:9000 @@ -79,14 +79,15 @@ rc object list rustfs/my-bucket ``` + -## Next steps +## 次のステップ -The quick install runs RustFS in **Single Node Single Disk (SNSD)** mode — zero redundancy, right for evaluation and development. Where to go from here: +クイックインストールでは、RustFS を **シングルノード・シングルディスク（SNSD）** モードで実行します。冗長性はなく、評価と開発に適しています。ここからの進め方は次のとおりです。 -- **Plan a production deployment** — choose a topology, then follow its guide: - - [Single Node Single Disk (SNSD)](./single-node-single-disk.md) — dev and small workloads - - [Single Node Multiple Disk (SNMD)](./single-node-multiple-disk.md) — disk-level fault tolerance on one machine - - [Multiple Node Multiple Disk (MNMD)](./multiple-node-multiple-disk.md) — production-grade availability and scale, with the [pre-installation checklists](../requirement/checklists/index.md) -- **Prefer containers?** — [Install with a container](../container/index.md) -- **Connect your application** — [SDKs and examples](../../developer/sdk/index.md) +- **本番デプロイを計画する**: トポロジーを選び、対応するガイドに従います。 + - [シングルノード・シングルディスク（SNSD）](./single-node-single-disk.md): 開発と小規模ワークロード + - [シングルノード・マルチディスク（SNMD）](./single-node-multiple-disk.md): 1 台のマシンでのディスク単位の耐障害性 + - [マルチノード・マルチディスク（MNMD）](./multiple-node-multiple-disk.md): 本番向けの可用性とスケール。[インストール前チェックリスト](../requirement/checklists/index.md) とあわせて確認します +- **コンテナを使う場合**: [コンテナでインストールする](../container/index.md) +- **アプリケーションを接続する**: [SDK とサンプル](../../developer/sdk/index.md) diff --git a/content/ja/installation/linux/single-node-multiple-disk.md b/content/ja/installation/linux/single-node-multiple-disk.md index 4f4c26906..45501a04e 100644 --- a/content/ja/installation/linux/single-node-multiple-disk.md +++ b/content/ja/installation/linux/single-node-multiple-disk.md @@ -1,17 +1,17 @@ --- -title: "RustFS Single Node Multiple Disk Installation" -description: "Install RustFS on a single server with multiple disks, data will be stored on multiple disks." +title: "シングルノード・マルチディスク（SNMD）" +description: "単一サーバーに RustFS をインストールし、データを複数のディスクに分散します。" --- -In Single Node Multiple Disk (SNMD) mode, one server stores data in sharded form across multiple data disks. Each object is split into K data shards and M parity shards (erasure coding), so the loss of up to M disks does not cause data loss. +シングルノード・マルチディスク（SNMD）モードでは、1 台のサーバーが複数のデータディスクにデータを分散します。各オブジェクトは K 個のデータシャードと M 個のパリティシャード（イレイジャーコーディング）に分割されるため、最大 M 台のディスクを失ってもデータは失われません。 :::warning -SNMD is suitable for medium, non-critical business. Damage to at most M disks does not pose a data risk, but if the entire server fails or more than M disks are damaged, data will be lost. Keep backups of important data. For node-level fault tolerance, use [MNMD](./multiple-node-multiple-disk.md). +SNMD は、中規模で重要度の低いワークロードに適しています。このデプロイでは、最大 M 台のディスクを失ってもデータは失われません。ただし、サーバー全体が故障した場合、または M 台を超えるディスクが損傷した場合は、データが失われます。重要なデータはバックアップを残します。ノード単位の耐障害性には、[MNMD](./multiple-node-multiple-disk.md) を使います。 ::: -## Topology and Planning +## トポロジーと計画 ```mermaid flowchart TD @@ -23,18 +23,18 @@ flowchart TD class D1,D2,D3,D4 disk ``` -- 1 server with multiple data disks (this example uses 4 disks mounted at `/data/rustfs0` through `/data/rustfs3`). -- Erasure coding spreads data and parity shards across the disks; fault tolerance is limited to disk failures within the single node. -- Format each disk with XFS and mount it separately (e.g., labels `RUSTFS0` – `RUSTFS3`), as described in the prerequisites page. -- For production deployments, also review the [Pre-Installation Checklists](../requirement/checklists/index.md). +- 複数のデータディスクを持つサーバー 1 台（この例では `/data/rustfs0` から `/data/rustfs3` にマウントした 4 台のディスク）。 +- イレイジャーコーディングは、データシャードとパリティシャードをディスク間に分散します。耐障害性は、単一ノード内のディスク障害に限られます。 +- 前提条件のページで説明しているとおり、各ディスクを XFS でフォーマットし、個別にマウントします（例: ラベル `RUSTFS0` ～ `RUSTFS3`）。 +- 本番デプロイでは、[インストール前チェックリスト](../requirement/checklists/index.md) も確認します。 -## Prerequisites and Service Setup +## 前提条件とサービスのセットアップ -Complete the [common prerequisites and service setup](./prerequisites-and-service.md) — operating system, firewall, time synchronization, disk formatting, service user, binary download, and systemd unit — then continue below. +[共通の前提条件とサービスのセットアップ](./prerequisites-and-service.md)（オペレーティングシステム、ファイアウォール、時刻同期、ディスクのフォーマット、サービスユーザー、バイナリのダウンロード、systemd ユニット）を完了してから、以下に進みます。 -## Configure Environment Variables +## 環境変数を設定する -1. Create the configuration file. `RUSTFS_VOLUMES` uses brace expansion to enumerate the four disk mount points: +1. 設定ファイルを作成します。`RUSTFS_VOLUMES` は、ブレース展開で 4 つのディスクマウントポイントを列挙します。 ```ini title="/etc/default/rustfs" # Use a unique access key and a strong, random secret (e.g. openssl rand -base64 24) @@ -48,44 +48,44 @@ RUSTFS_OBS_LOGGER_LEVEL=error RUSTFS_OBS_LOG_DIRECTORY="/var/log/rustfs/" ``` -2. Create the storage and log directories: +2. ストレージとログのディレクトリを作成します。 ```bash sudo mkdir -p /data/rustfs{0..3} /var/log/rustfs /opt/tls sudo chmod -R 750 /data/rustfs* /var/log/rustfs ``` -## Start Service and Verification +## サービスを起動して確認する -1. Start the service and enable auto-start on boot: +1. サービスを起動し、起動時に開始するよう有効にします。 ```bash sudo systemctl enable --now rustfs ``` -2. Verify the service status: +2. サービスの状態を確認します。 ```bash systemctl status rustfs ``` -3. Check the service port: +3. サービスのポートを確認します。 ```bash netstat -ntpl ``` -4. View log files: +4. ログファイルを表示します。 ```bash tail -f /var/log/rustfs/rustfs*.log ``` -5. Access the console: enter the server's IP address and the console port (default 9001) in a browser. You should see: +5. Console にアクセスします。ブラウザーにサーバーの IP アドレスと Console のポート（既定は 9001）を入力すると、次のように表示されます。 -![Console](./images/console.jpg) +![Console の画面](./images/console.jpg) -## Next Steps +## 次のステップ -- Need node-level fault tolerance and horizontal scalability? See [Multiple Node Multiple Disk Mode (MNMD)](./multiple-node-multiple-disk.md). -- Just experimenting? [Single Node Single Disk Mode (SNSD)](./single-node-single-disk.md) is simpler to set up. +- ノード単位の耐障害性と水平スケーラビリティが必要な場合は、[マルチノード・マルチディスク（MNMD）](./multiple-node-multiple-disk.md) を参照します。 +- 試すだけの場合は、[シングルノード・シングルディスク（SNSD）](./single-node-single-disk.md) のほうがセットアップは簡単です。 diff --git a/content/ja/installation/linux/single-node-single-disk.md b/content/ja/installation/linux/single-node-single-disk.md index b6c96e62f..b7e127a50 100644 --- a/content/ja/installation/linux/single-node-single-disk.md +++ b/content/ja/installation/linux/single-node-single-disk.md @@ -1,17 +1,17 @@ --- -title: RustFS Single Node Single Disk Installation -description: Install RustFS on a single disk of a single server, data will be stored on this one disk. +title: シングルノード・シングルディスク（SNSD） +description: すべてのデータを 1 台のディスクに保存する単一サーバーへ、RustFS をインストールします。 --- -In Single Node Single Disk (SNSD) mode, one server stores all data on a single data disk. It is the simplest deployment mode and the same topology that the [Linux Quick Start](./quick-start.md) script sets up. +シングルノード・シングルディスク（SNSD）モードでは、1 台のサーバーがすべてのデータを 1 台のデータディスクに保存します。最も単純なデプロイ方式であり、[Linux クイックスタート](./quick-start.md) のスクリプトが設定するトポロジーと同じです。 :::warning -A single disk offers no redundancy: if the disk fails, data is lost. SNSD is suitable for development, testing, and low-density non-critical business. For production use, maintain regular data backups or choose [SNMD](./single-node-multiple-disk.md) / [MNMD](./multiple-node-multiple-disk.md). +ディスクが 1 台の場合、冗長性はありません。ディスクが故障するとデータは失われます。SNSD は、開発、テスト、および小規模で重要度の低いワークロードに適しています。本番で使う場合は、定期的なデータバックアップを維持するか、[SNMD](./single-node-multiple-disk.md) または [MNMD](./multiple-node-multiple-disk.md) を選びます。 ::: -## Topology and Planning +## トポロジーと計画 ```mermaid flowchart TD @@ -23,17 +23,17 @@ flowchart TD class D1 disk ``` -- 1 server, 1 data disk (e.g., an XFS-formatted disk mounted at `/data/rustfs0`). -- No erasure coding across disks — fault tolerance depends entirely on backups. -- For production deployments, also review the [Pre-Installation Checklists](../requirement/checklists/index.md). +- サーバー 1 台、データディスク 1 台（例: `/data/rustfs0` にマウントした XFS フォーマットのディスク）。 +- ディスク間のイレイジャーコーディングはありません。耐障害性はすべてバックアップに依存します。 +- 本番デプロイでは、[インストール前チェックリスト](../requirement/checklists/index.md) も確認します。 -## Prerequisites and Service Setup +## 前提条件とサービスのセットアップ -Complete the [common prerequisites and service setup](./prerequisites-and-service.md) — operating system, firewall, time synchronization, disk formatting, service user, binary download, and systemd unit — then continue below. +[共通の前提条件とサービスのセットアップ](./prerequisites-and-service.md)（オペレーティングシステム、ファイアウォール、時刻同期、ディスクのフォーマット、サービスユーザー、バイナリのダウンロード、systemd ユニット）を完了してから、以下に進みます。 -## Configure Environment Variables +## 環境変数を設定する -1. Create the configuration file with the single-disk volume path: +1. シングルディスクのボリュームパスを含む設定ファイルを作成します。 ```ini title="/etc/default/rustfs" # Use a unique access key and a strong, random secret (e.g. openssl rand -base64 24) @@ -47,44 +47,44 @@ RUSTFS_OBS_LOGGER_LEVEL=error RUSTFS_OBS_LOG_DIRECTORY="/var/log/rustfs/" ``` -2. Create the storage and log directories: +2. ストレージとログのディレクトリを作成します。 ```bash sudo mkdir -p /data/rustfs0 /var/log/rustfs /opt/tls sudo chmod -R 750 /data/rustfs* /var/log/rustfs ``` -## Start Service and Verification +## サービスを起動して確認する -1. Start the service and enable auto-start on boot: +1. サービスを起動し、起動時に開始するよう有効にします。 ```bash sudo systemctl enable --now rustfs ``` -2. Verify the service status: +2. サービスの状態を確認します。 ```bash systemctl status rustfs ``` -3. Check the service port: +3. サービスのポートを確認します。 ```bash netstat -ntpl ``` -4. View log files: +4. ログファイルを表示します。 ```bash tail -f /var/log/rustfs/rustfs*.log ``` -5. Access the console: enter the server's IP address and the console port (default 9001) in a browser. You should see: +5. Console を開きます。ブラウザーで `http://:9001` にアクセスすると、次のように表示されます。 -![Console](./images/console.jpg) +![Console の画面](./images/console.jpg) -## Next Steps +## 次のステップ -- Need disk-level redundancy on one server? See [Single Node Multiple Disk Mode (SNMD)](./single-node-multiple-disk.md). -- Need a production cluster? See [Multiple Node Multiple Disk Mode (MNMD)](./multiple-node-multiple-disk.md). +- 1 台のサーバーでディスク単位の冗長性が必要な場合は、[シングルノード・マルチディスク（SNMD）](./single-node-multiple-disk.md) を参照します。 +- 本番クラスターが必要な場合は、[マルチノード・マルチディスク（MNMD）](./multiple-node-multiple-disk.md) を参照します。 diff --git a/content/ja/installation/macos/index.md b/content/ja/installation/macos/index.md index 2cb290a79..309579cea 100644 --- a/content/ja/installation/macos/index.md +++ b/content/ja/installation/macos/index.md @@ -1,124 +1,124 @@ --- -title: "Install RustFS on macOS" -description: "Install a local RustFS instance on macOS with RustFS Launcher or the standalone server binary." +title: "macOS に RustFS をインストールする" +description: "RustFS Launcher またはスタンドアロンのサーバーバイナリを使い、macOS にローカルの RustFS インスタンスをインストールします。" --- -This guide provides two ways to run **RustFS** on macOS: use the graphical **RustFS Launcher**, or run the standalone server binary from Terminal. Both methods create a local, single-node instance suitable for evaluation, development, and testing. +このガイドでは、macOS で **RustFS** を実行する 2 つの方法を説明します。グラフィカルな **RustFS Launcher** を使う方法と、Terminal からスタンドアロンのサーバーバイナリを実行する方法です。どちらも、評価、開発、テストに適したローカルのシングルノードインスタンスを作成します。 -:::note[Deployment scope] +:::note[デプロイの範囲] -These procedures run RustFS as a desktop process, not as a macOS background service. For a production or distributed deployment, use the [Linux installation guides](/installation/linux). +これらの手順では、RustFS を macOS のバックグラウンドサービスとしてではなく、デスクトッププロセスとして実行します。本番または分散デプロイには、[Linux のインストールガイド](/ja/installation/linux) を使います。 ::: -## 1. Check your Mac architecture +## 1. Mac のアーキテクチャを確認する -RustFS distinguishes between Apple Silicon (`arm64`) and Intel (`x86_64`) Macs. Open Terminal and run: +RustFS は、Apple シリコン（`arm64`）と Intel（`x86_64`）の Mac 向けに異なるビルドを提供しています。Terminal を開いて次を実行します。 ```bash uname -m ``` -Use the result to choose the correct package: +結果を見て、正しいパッケージを選びます。 -| Result | Mac type | Current standalone binary availability | +| 結果 | Mac の種類 | 現在のスタンドアロンバイナリの提供状況 | | --- | --- | --- | -| `arm64` | Apple Silicon | Download the macOS AArch64 package from current RustFS releases. | -| `x86_64` | Intel | RustFS releases after `v1.0.0-beta.9` do not provide a prebuilt Intel macOS package. Build the current version from source. | +| `arm64` | Apple シリコン | 現行の RustFS リリースから macOS AArch64 パッケージをダウンロードします。 | +| `x86_64` | Intel | `v1.0.0-beta.9` より後の RustFS リリースは、ビルド済みの Intel macOS パッケージを提供していません。現行バージョンはソースからビルドします。 | -:::warning[Intel Mac release boundary] +:::warning[Intel Mac のリリース境界] -Do not run the Apple Silicon binary on an Intel Mac. If you need a RustFS version newer than `v1.0.0-beta.9` on Intel macOS, follow the source-build procedure in this guide. An older beta.9 binary does not contain fixes and features from later releases. +Intel Mac で Apple シリコンのバイナリを実行しないでください。Intel macOS で `v1.0.0-beta.9` より新しい RustFS が必要な場合は、このガイドのソースビルド手順に従います。古い beta.9 のバイナリには、それ以降のリリースの修正と機能は含まれていません。 ::: -Before continuing, also make sure that: +続ける前に、次も確認します。 -- You have permission to install or run applications and write to the selected data directory. -- TCP ports `9000` and `9001` are available, or you have selected two other unused ports. -- You have created a dedicated data directory, such as `$HOME/rustfs/data`. +- アプリケーションのインストールまたは実行と、選択したデータディレクトリへの書き込みの権限があります。 +- TCP ポート `9000` と `9001` が空いているか、ほかの未使用ポートを 2 つ選んでいます。 +- `$HOME/rustfs/data` のような専用のデータディレクトリを作成しています。 ```bash mkdir -p "$HOME/rustfs/data" ``` -:::warning[Protect the data directory] +:::warning[データディレクトリを保護する] -Use an empty directory on a disk with enough free space. Do not store unrelated files in this directory, and do not edit RustFS data files while the server is running. +空き容量が十分なディスク上の空のディレクトリを使います。このディレクトリに無関係なファイルを置かず、サーバーの実行中に RustFS のデータファイルを編集しないでください。 ::: -## 2. Choose an installation method +## 2. インストール方法を選ぶ -| Method | Use it when | Architecture note | +| 方法 | 使う場面 | アーキテクチャに関する注意 | | --- | --- | --- | -| RustFS Launcher | You want a graphical setup and built-in log viewer. | Download a Launcher package that matches Apple Silicon or Intel. | -| Standalone binary | You want explicit Terminal commands or scripting. | Current releases provide Apple Silicon binaries; Intel users build releases after beta.9 from source. | +| RustFS Launcher | グラフィカルなセットアップと組み込みのログビューアーが必要な場合。 | Apple シリコンまたは Intel に一致する Launcher パッケージをダウンロードします。 | +| スタンドアロンバイナリ | 明示的な Terminal コマンドやスクリプトが必要な場合。 | 現行リリースは Apple シリコン向けバイナリを提供します。Intel では、beta.9 より後のリリースをソースからビルドします。 | -## Install with RustFS Launcher +## RustFS Launcher でインストールする -### 3. Download and install Launcher +### 3. Launcher をダウンロードしてインストールする -1. Open the [RustFS Launcher Releases page](https://github.com/rustfs/launcher/releases). -2. Select the latest release and expand **Assets**. -3. Download the macOS installer that matches your architecture: AArch64 for Apple Silicon or x86-64 for Intel. Do not download **Source code** unless you intend to build Launcher yourself. -4. Open the downloaded disk image and move **RustFS Launcher** to **Applications**. -5. Open **RustFS Launcher** from **Applications**. +1. [RustFS Launcher の Releases ページ](https://github.com/rustfs/launcher/releases) を開きます。 +2. 最新のリリースを選び、**Assets**（アセット）を展開します。 +3. アーキテクチャに一致する macOS インストーラーをダウンロードします。Apple シリコンは AArch64、Intel は x86-64 です。自分で Launcher をビルドする場合を除き、**Source code**（ソースコード）はダウンロードしないでください。 +4. ダウンロードしたディスクイメージを開き、**RustFS Launcher** を **Applications**（アプリケーション）に移動します。 +5. **Applications** から **RustFS Launcher** を開きます。 -If macOS blocks the first launch, confirm that the package came from the official `rustfs/launcher` Releases page. Then open **System Settings > Privacy & Security** and allow that specific application. Do not disable Gatekeeper globally. +macOS が初回起動をブロックした場合は、パッケージが公式の `rustfs/launcher` Releases ページから入手したものであることを確認します。その後、**System Settings > Privacy & Security**（システム設定 > プライバシーとセキュリティ）を開き、そのアプリケーションだけを許可します。Gatekeeper をシステム全体で無効にしないでください。 -### 4. Configure Launcher +### 4. Launcher を設定する -Configure the fields in the Launcher window: +Launcher ウィンドウの各フィールドを設定します。 -| Section | Field | Recommended value | Description | +| セクション | フィールド | 推奨値 | 説明 | | --- | --- | --- | --- | -| Dataset Mount | Data Path | `$HOME/rustfs/data` | Existing directory where RustFS stores object data. | -| Ports & Access | API Port | `9000` | S3-compatible API port. | -| Ports & Access | Host | `127.0.0.1` | Restricts access to this Mac. | -| Ports & Access | Console Endpoint | Enabled | Enables the web Console; Launcher disables it by default. | -| Ports & Access | Console Port | `9001` | Console port, which must differ from the API port. | -| Credentials | Access Key | `` | Administrator access key for this instance. | -| Credentials | Secret Key | `` | Administrator secret key for this instance. | +| Dataset Mount（データセットのマウント） | Data Path（データパス） | `$HOME/rustfs/data` | RustFS がオブジェクトデータを保存する、既存のディレクトリ。 | +| Ports & Access（ポートとアクセス） | API Port（API ポート） | `9000` | S3 互換 API のポート。 | +| Ports & Access | Host（ホスト） | `127.0.0.1` | アクセスをこの Mac に制限します。 | +| Ports & Access | Console Endpoint（Console エンドポイント） | Enabled（有効） | Web Console を有効にします。Launcher は既定で無効にしています。 | +| Ports & Access | Console Port（Console ポート） | `9001` | Console のポート。API ポートとは異なる必要があります。 | +| Credentials（認証情報） | Access Key（アクセスキー） | `` | このインスタンスの管理者アクセスキー。 | +| Credentials | Secret Key（シークレットキー） | `` | このインスタンスの管理者シークレットキー。 | -Use **Browse** to select the data directory or drag it into Launcher. Launcher requires the directory to exist before startup. The macOS file picker displays the expanded path instead of the literal `$HOME` variable. +**Browse**（参照）でデータディレクトリを選ぶか、Launcher にドラッグします。Launcher は、起動前にディレクトリが存在していることを要求します。macOS のファイル選択ダイアログは、リテラルの `$HOME` 変数ではなく、展開されたパスを表示します。 -Replace the credential placeholders with your own values. Launcher initially displays default local-test credentials; do not retain them on a Mac accessible by other users. +認証情報のプレースホルダーを独自の値に置き換えます。Launcher は最初、ローカルテスト用の既定の認証情報を表示します。ほかのユーザーがアクセスできる Mac では、その値を残さないでください。 -:::warning[Network exposure] +:::warning[ネットワークへの公開] -Keep **Host** set to `127.0.0.1` unless another computer must connect to RustFS. A non-loopback address exposes the API and Console on the corresponding network interfaces. Configure the macOS firewall and strong credentials before allowing remote access. +別のコンピューターが RustFS に接続する必要がある場合を除き、**Host** は `127.0.0.1` のままにします。ループバック以外のアドレスは、対応するネットワークインターフェース上で API と Console を公開します。リモートアクセスを許可する前に、macOS のファイアウォールと強力な認証情報を設定します。 ::: -### 5. Start and verify RustFS +### 5. RustFS を起動して確認する -1. Select **Launch RustFS**. -2. Wait for Launcher to report that the configured endpoint is online. -3. Open `http://localhost:9001` and sign in with the access key and secret key that you configured. -4. Use `http://localhost:9000` as the endpoint for S3-compatible clients. +1. **Launch RustFS**（RustFS を起動）を選びます。 +2. 設定したエンドポイントがオンラインになったと Launcher が報告するまで待ちます。 +3. `http://localhost:9001` を開き、設定したアクセスキーとシークレットキーでサインインします。 +4. S3 互換クライアントのエンドポイントとして `http://localhost:9000` を使います。 -![RustFS Launcher showing the service online with API port 9000, Console port 9001, and successful startup logs](../windows/images/windows-rustfs-launcher.jpg) +![API ポート 9000、Console ポート 9001、起動成功のログとともに、サービスがオンラインであることを示す RustFS Launcher](../windows/images/windows-rustfs-launcher.jpg) -If you changed the host or ports, use those values instead. The Console URL is available only when **Console Endpoint** is enabled. +ホストまたはポートを変更した場合は、その値を使います。Console の URL は、**Console Endpoint** が有効な場合にのみ使えます。 -Launcher locks its configuration while it manages a running process. It also creates a `logs` directory next to the data directory. For example, selecting `$HOME/rustfs/data` places server log files under `$HOME/rustfs/logs`. +Launcher は、実行中のプロセスを管理している間、設定をロックします。また、データディレクトリの隣に `logs` ディレクトリを作成します。たとえば、`$HOME/rustfs/data` を選んだ場合、サーバーのログファイルは `$HOME/rustfs/logs` に置かれます。 -### 6. Stop or exit Launcher +### 6. Launcher を停止または終了する -Select **Stop RustFS** before changing configuration, disconnecting an external data disk, or shutting down macOS. +設定を変更する前、外付けのデータディスクを取り外す前、または macOS をシャットダウンする前に、**Stop RustFS**（RustFS を停止）を選びます。 -Closing the Launcher window hides it in the menu bar; it does not stop RustFS. To stop the managed process and exit Launcher, open the Launcher menu bar icon and select **Quit**. Select **Show**, or select the icon, to restore the window. +Launcher ウィンドウを閉じると、メニューバーに隠れるだけで、RustFS は停止しません。管理対象のプロセスを停止して Launcher を終了するには、Launcher のメニューバーアイコンを開き、**Quit**（終了）を選びます。ウィンドウを戻すには、**Show**（表示）を選ぶか、アイコンを選択します。 -## Install the standalone binary +## スタンドアロンバイナリをインストールする -### 7. Download the Apple Silicon binary +### 7. Apple シリコンのバイナリをダウンロードする -Use this procedure when `uname -m` returns `arm64`: +`uname -m` が `arm64` を返す場合は、この手順を使います。 -1. Open the [RustFS Releases page](https://github.com/rustfs/rustfs/releases). -2. Select the required release and download the macOS AArch64 ZIP archive from **Assets**. The asset name begins with `rustfs-macos-aarch64`. -3. Create a program directory and extract the archive. Replace `` with the version in the downloaded filename: +1. [RustFS の Releases ページ](https://github.com/rustfs/rustfs/releases) を開きます。 +2. 必要なリリースを選び、**Assets** から macOS AArch64 の ZIP アーカイブをダウンロードします。アセット名は `rustfs-macos-aarch64` で始まります。 +3. プログラム用のディレクトリを作成し、アーカイブを展開します。`` は、ダウンロードしたファイル名のバージョンに置き換えます。 ```bash mkdir -p "$HOME/rustfs/bin" @@ -127,20 +127,20 @@ chmod +x "$HOME/rustfs/bin/rustfs" "$HOME/rustfs/bin/rustfs" --help ``` -If the archive contains a platform-specific binary name instead of `rustfs`, use that filename in the remaining commands or rename it to `$HOME/rustfs/bin/rustfs`. +アーカイブに `rustfs` ではなくプラットフォーム固有のバイナリ名が含まれている場合は、残りのコマンドでそのファイル名を使うか、`$HOME/rustfs/bin/rustfs` に名前を変更します。 -### 8. Build the Intel binary from source +### 8. Intel のバイナリをソースからビルドする -Use this procedure when `uname -m` returns `x86_64` and you need a release newer than `v1.0.0-beta.9`. +`uname -m` が `x86_64` を返し、`v1.0.0-beta.9` より新しいリリースが必要な場合は、この手順を使います。 -1. Install the Xcode command-line tools: +1. Xcode コマンドラインツールをインストールします。 ```bash xcode-select --install ``` -2. Install the current stable Rust toolchain from [rustup.rs](https://rustup.rs/), then open a new Terminal session. -3. Clone RustFS and check out the release that you need: +2. [rustup.rs](https://rustup.rs/) から現行の安定版 Rust ツールチェーンをインストールし、新しい Terminal セッションを開きます。 +3. RustFS をクローンし、必要なリリースをチェックアウトします。 ```bash git clone https://github.com/rustfs/rustfs.git @@ -148,23 +148,23 @@ cd rustfs git checkout ``` -4. Build the Intel macOS target with the repository build script: +4. リポジトリのビルドスクリプトで、Intel macOS 向けターゲットをビルドします。 ```bash ./build-rustfs.sh --platform x86_64-apple-darwin ``` -The build script includes Console assets by default and verifies the resulting binary. Use the binary reported at the end of the build output in the next step. +ビルドスクリプトは既定で Console のアセットを含め、生成されたバイナリを検証します。次の手順では、ビルド出力の末尾に表示されたバイナリを使います。 -:::note[Source-build dependencies] +:::note[ソースビルドの依存関係] -Building from source requires the tools used by the selected RustFS release in addition to Rust and the Xcode command-line tools. If the build reports a missing dependency, follow the requirements in that release's repository README rather than substituting a binary built for Apple Silicon. +ソースからビルドするには、Rust と Xcode コマンドラインツールに加えて、選択した RustFS リリースが使うツールが必要です。ビルドが不足している依存関係を報告した場合は、Apple シリコン向けにビルドしたバイナリで代用せず、そのリリースのリポジトリ README の要件に従います。 ::: -### 9. Start the standalone server +### 9. スタンドアロンサーバーを起動する -Set credentials for the current Terminal session and assign the path to your downloaded or compiled binary: +現在の Terminal セッションに認証情報を設定し、ダウンロードまたはコンパイルしたバイナリのパスを割り当てます。 ```bash export RUSTFS_ACCESS_KEY="" @@ -178,72 +178,72 @@ export RUSTFS_BIN="$HOME/rustfs/bin/rustfs" "$HOME/rustfs/data" ``` -For an Intel source build, replace `RUSTFS_BIN` with the binary path printed by `build-rustfs.sh`. Keep the Terminal window open while RustFS is running. Press `Control+C` to stop the server. +Intel のソースビルドでは、`RUSTFS_BIN` を `build-rustfs.sh` が表示したバイナリパスに置き換えます。RustFS の実行中は Terminal ウィンドウを開いたままにします。`Control+C` でサーバーを停止します。 -:::tip[Credential handling] +:::tip[認証情報の扱い] -Session environment variables avoid placing credentials directly in the command line. For repeated or automated use, prefer the `RUSTFS_ACCESS_KEY_FILE` and `RUSTFS_SECRET_KEY_FILE` environment variables and protect those files with macOS permissions. +セッションの環境変数を使うと、認証情報をコマンドラインに直接置かずに済みます。繰り返し使う場合や自動化する場合は、`RUSTFS_ACCESS_KEY_FILE` と `RUSTFS_SECRET_KEY_FILE` の環境変数を使い、それらのファイルを macOS の権限で保護することを推奨します。 ::: -### 10. Verify the standalone server +### 10. スタンドアロンサーバーを確認する -Open `http://localhost:9001` and sign in with the configured credentials. Use `http://localhost:9000` as the endpoint for S3-compatible clients. RustFS defaults to path-style addressing, so configure clients accordingly. +`http://localhost:9001` を開き、設定した認証情報でサインインします。S3 互換クライアントのエンドポイントとして `http://localhost:9000` を使います。RustFS は既定でパススタイルアクセスになるため、クライアントもそれに合わせて設定します。 -To perform an end-to-end check, create a bucket named `my-bucket`, upload `hello.txt`, and confirm that the object appears in the bucket. +エンドツーエンドで確認するには、`my-bucket` という名前のバケットを作成し、`hello.txt` をアップロードして、オブジェクトがバケットに表示されることを確認します。 -## Confirm a successful installation +## インストールの成功を確認する -Whether you used Launcher, an Apple Silicon binary, or an Intel source build, a successful Console sign-in opens the **Buckets** page. +Launcher、Apple シリコンのバイナリ、Intel のソースビルドのいずれを使った場合でも、Console へのサインインが成功すると **Buckets**（バケット）ページが開きます。 -![RustFS Console Buckets page after a successful sign-in](../windows/images/rustfs-console-login.png) +![サインイン成功後の RustFS Console の Buckets ページ](../windows/images/rustfs-console-login.png) -## Troubleshooting +## トラブルシューティング -### macOS blocks the application or binary +### macOS がアプリケーションまたはバイナリをブロックする -Verify that the file came from the official RustFS GitHub organization. For Launcher, allow the specific application under **System Settings > Privacy & Security**. For a standalone binary that macOS has quarantined, inspect the warning and verify the download source before changing its security attributes. +ファイルが公式の RustFS GitHub 組織から入手したものであることを確認します。Launcher の場合は、**System Settings > Privacy & Security** でそのアプリケーションを許可します。macOS が隔離したスタンドアロンバイナリの場合は、セキュリティ属性を変更する前に警告を確認し、ダウンロード元を確かめます。 -### The binary architecture does not match +### バイナリのアーキテクチャが一致しない -Run `uname -m` and inspect the binary: +`uname -m` を実行し、バイナリを確認します。 ```bash uname -m file "$RUSTFS_BIN" ``` -Use an AArch64 binary on Apple Silicon. On an Intel Mac, build releases after `v1.0.0-beta.9` from source for `x86_64-apple-darwin`. +Apple シリコンでは AArch64 のバイナリを使います。Intel Mac では、`v1.0.0-beta.9` より後のリリースを `x86_64-apple-darwin` 向けにソースからビルドします。 -### The data path is rejected +### データパスが拒否される -Confirm that the directory exists and that your macOS account has read and write access. Launcher does not create the selected data directory for you. +ディレクトリが存在し、macOS アカウントに読み取りと書き込みの権限があることを確認します。Launcher は、選択したデータディレクトリを自動では作成しません。 -### The API or Console port is unavailable +### API または Console のポートが使えない -The ports must be numbers from `1` to `65535`, must differ from each other, and must not already be in use. Inspect the default ports: +ポートは、`1` から `65535` の数値であり、互いに異なり、かつ未使用である必要があります。既定のポートを確認します。 ```bash lsof -nP -iTCP:9000 -iTCP:9001 -sTCP:LISTEN ``` -Stop the conflicting application or select unused ports, then start RustFS again. +競合しているアプリケーションを停止するか、未使用のポートを選んでから、RustFS を再度起動します。 -### The Console does not open +### Console が開かない -For Launcher, confirm that **Console Endpoint** is enabled. For the standalone binary, confirm that the process is still running and that `--console-enable true` is present. +Launcher の場合は、**Console Endpoint** が有効であることを確認します。スタンドアロンバイナリの場合は、プロセスがまだ実行中であり、`--console-enable true` があることを確認します。 -### Launcher reports an external RustFS process +### Launcher が外部の RustFS プロセスを報告する -Another process is listening on the configured API address, but Launcher did not start it. Stop that process or choose another API port. Launcher cannot stop a process it does not manage. +別のプロセスが、設定した API アドレスで待ち受けていますが、Launcher はそのプロセスを起動していません。そのプロセスを停止するか、別の API ポートを選びます。Launcher は、自身が管理していないプロセスを停止できません。 -### RustFS exits after launch +### 起動後に RustFS が終了する -In Launcher, inspect both the application and RustFS tabs in the built-in log viewer. For a standalone installation, inspect the Terminal output. Common causes include a missing data directory, insufficient permissions, an architecture mismatch, or a port conflict. +Launcher では、組み込みログビューアーのアプリケーションタブと RustFS タブの両方を確認します。スタンドアロンインストールでは、Terminal の出力を確認します。よくある原因は、データディレクトリがないこと、権限が不足していること、アーキテクチャの不一致、ポートの競合です。 -## Next steps +## 次のステップ -- Review the [S3 API guide](/administration/protocols/s3) before connecting a client. -- Learn how to [create a bucket](/administration/data/bucket/creation). -- See [status checks](/operations/status-check) for additional verification methods. -- Use the [Linux installation guides](/installation/linux) for a production-oriented deployment. +- クライアントを接続する前に、[S3 API ガイド](/ja/administration/protocols/s3) を確認します。 +- [バケットを作成する](/ja/administration/data/bucket/creation) 方法を確認します。 +- 追加の確認方法は、[ステータスチェック](/ja/operations/status-check) を参照します。 +- 本番向けのデプロイには、[Linux のインストールガイド](/ja/installation/linux) を使います。 diff --git a/content/ja/installation/requirement/checklists/hardware-checklists.md b/content/ja/installation/requirement/checklists/hardware-checklists.md index 8250d5512..796c19463 100644 --- a/content/ja/installation/requirement/checklists/hardware-checklists.md +++ b/content/ja/installation/requirement/checklists/hardware-checklists.md @@ -1,93 +1,93 @@ --- -title: "Production Environment Hardware Configuration Guide" -description: "RustFS is a high-performance distributed object storage system developed in Rust, suitable for massive unstructured data storage scenarios. This document provides comprehensive hardware selection and configuration guidance for production environment deployment." +title: "ハードウェアチェックリスト" +description: "本番の RustFS デプロイに向けた、ハードウェアのサイジングと構成の指針を示します。" --- -## Deployment Planning Factor Analysis +## 計画時の考慮事項 -Before formally deploying RustFS, it's recommended to conduct 2-3 weeks of business research, focusing on evaluating the following dimensions: +本番に RustFS をデプロイする前に、2 週間から 3 週間をかけてワークロードと容量の要件を評価します。次の点に注目します。 -1. **Data Scale Analysis** +1. **データ量** -- **Initial Data Volume**: Accurately calculate effective data volume at production startup (recommended in TiB units), considering hot/cold data ratios -- **Growth Trend Prediction**: Estimate data increments for the next 24 months based on business development plans (recommended quarterly growth rate model) -- **Object Scale**: Calculate total object count based on average object size (recommended 128 KB-1 MB range), note special optimization needed when exceeding 100 million objects + - **初期データ量**: 稼働開始時の使用可能なデータ量（TiB）と、ホットデータとコールドデータの比率を見積もります。 + - **増加予測**: 事業計画に基づき、今後 24 か月のデータ増加を見積もります。増加は四半期ごとに見積もることを推奨します。 + - **オブジェクト数**: 平均オブジェクトサイズ（理想的には 128 KB から 1 MB）から、オブジェクトの総数を見積もります。オブジェクト数が 1 億を超えるデプロイでは、追加の調整が必要です。 -2. **Business Characteristic Assessment** +2. **ワークロードの特性** -- **Access Patterns**: Distinguish read-intensive (such as content distribution) from write-intensive (such as log collection) scenarios -- **Compliance Requirements**: Data retention cycles must comply with industry regulatory requirements (e.g., financial industry must retain for at least 5 years) -- **Multi-site Deployment**: Cross-regional deployment requires network latency assessment (recommended controlled within 50ms) and bandwidth cost evaluation + - **アクセスパターン**: 読み取り中心のワークロード（コンテンツ配信など）と、書き込み中心のワークロード（ログ収集など）を区別します。 + - **コンプライアンス要件**: 保持期間は、業界規制を満たす必要があります（例: 一部の金融規制では、少なくとも 5 年の保持が必要です）。 + - **マルチサイトデプロイ**: リージョンをまたぐデプロイでは、ネットワークレイテンシ（理想的には 50 ms 未満）と帯域のコストを評価します。 -3. **Storage Architecture Design** +3. **ストレージアーキテクチャ** -- **Bucket Planning**: Divide storage buckets by business units, single cluster recommended not exceeding 500 active buckets -- **Disaster Recovery Strategy**: Choose dual-active architecture (recommended) or asynchronous replication based on data importance + - **バケットの計画**: 事業部門ごとにバケットを整理します。クラスターあたりのアクティブなバケットは 500 個以下にすることを推奨します。 + - **災害対策**: データの重要度に応じて、アクティブ-アクティブのレプリケーション（推奨）または非同期レプリケーションを選びます。 -## Hardware Configuration Matrix +## ハードウェア構成マトリックス -Baseline configuration solutions based on stress test results: +負荷テストの結果に基づく基準構成は次のとおりです。 -| Component | Basic Environment | Production Standard Configuration | High-Performance Configuration | +| コンポーネント | エントリー | 標準的な本番 | 高性能 | |--------------|---------------------------|--------------------------|--------------------------| -| Node Count | 4 nodes | 8 nodes | 16+ nodes | -| Storage Media | 4× NVMe SSD | 8×NVMe SSD | 12×NVMe SSD | -| Network Architecture | Dual 25GbE (link aggregation) | Dual 100GbE | 200GbE | -| CPU | 2×Intel Silver 4310 (16 cores) | 2×AMD EPYC 7313 (32 cores) | 2×Intel Platinum 8461Y (48 cores) | -| Memory | 64 GB DDR4-3200 ECC | 256 GB DDR5-4800 ECC | 512 GB DDR5-5600 ECC | -| Storage Controller | HBA 9500-8i | HBA 9600-16i | Dual controller redundant architecture | +| ノード数 | 4 ノード | 8 ノード | 16 ノード以上 | +| ストレージ媒体 | 4× NVMe SSD | 8×NVMe SSD | 12×NVMe SSD | +| ネットワーク構成 | デュアル 25GbE（リンクアグリゲーション） | デュアル 100GbE | 200GbE | +| CPU | 2×Intel Silver 4310（16 コア） | 2×AMD EPYC 7313（32 コア） | 2×Intel Platinum 8461Y（48 コア） | +| メモリ | 64 GB DDR4-3200 ECC | 256 GB DDR5-4800 ECC | 512 GB DDR5-5600 ECC | +| ストレージコントローラー | HBA 9500-8i | HBA 9600-16i | デュアルコントローラーの冗長構成 | -**Important Deployment Principles:** +**デプロイの指針:** -1. Adopt "server farm" mode, ensuring all nodes use identical hardware batches and firmware versions -2. Network architecture must meet: leaf-spine topology + physically isolated storage network + dual uplink paths -3. Recommend using 2U server models, single node recommended configuration of 12+ disk bays (based on actual hard disk count) +1. 同一構成のノードを使います。各ノードは、同一ロットの同一ハードウェアと、同一のファームウェアバージョンに揃えることを推奨します。 +2. ネットワークは、リーフスパイン構成、物理的に分離したストレージネットワーク、二重のアップリンクを使う必要があります。 +3. 必要なドライブ数に応じて、ノードあたり少なくとも 12 のドライブベイを備えた 2U サーバーを推奨します。 -## Performance Critical Path Optimization +## 性能チューニング -### Network Topology Optimization (Highest Priority) +### ネットワークトポロジーの最適化（最優先） -- **Bandwidth Calculation**: Reserve 0.5 Gbps bandwidth per TB of effective data (e.g., 100 TB data needs 50 Gbps dedicated bandwidth) -- **Latency Requirements**: -- Inter-node P99 latency ≤ 2ms -- Cross-rack latency ≤ 5ms +- **帯域のサイジング**: 使用可能なデータ 1 TB あたり 0.5 Gbps の帯域を用意します（例: データ 100 TB には、50 Gbps の専用帯域が必要です）。 +- **レイテンシの要件**: + - ノード間の P99 レイテンシは 2 ms 以下 + - ラック間のレイテンシは 5 ms 以下 -### Storage Subsystem Tuning +### ストレージサブシステムのチューニング -- **Controller Configuration**: -- Enable read-ahead cache (recommended 256 MB+) -- Disable all RAID functions, use pass-through mode -- Regularly check BBU battery health status -- **SSD Parameters**: -- Reserve 20% OP space to improve durability -- Enable atomic write features (requires hardware support) +- **コントローラーの設定**: + - 先読みキャッシュを有効にします（256 MB 以上を推奨）。 + - すべての RAID 機能を無効にし、パススルー（HBA/JBOD）モードを使います。 + - BBU の状態を定期的に確認します。 +- **SSD のパラメーター**: + - 耐久性を高めるため、20% のオーバープロビジョニング（OP）領域を確保します。 + - アトミック書き込みを有効にします（ハードウェアの対応が必要です）。 -### Memory Management Strategy +### メモリの割り当て -- **Allocation Ratios**: -- Metadata cache: 60% of total memory -- Read/write buffers: 30% -- System reserve: 10% +- **配分比率**: + - メタデータキャッシュ: 総メモリの 60% + - 読み書きバッファー: 30% + - システム予約: 10% -## Network Design Reference Model +## ネットワーク設計の参照モデル -### Bandwidth and Disk Ratio Relationship +### ネットワーク帯域とディスク数 -| Network Type | Theoretical Throughput | Suitable Disk Types | Maximum Disk Support | +| ネットワーク | 理論スループット | ディスクの種類 | ノードあたりの最大ディスク数 | |------------|------------|---------------------|----------------| -| 10GbE | 1.25 GB/s | 7.2K HDD (180 MB/s) | 8 disks | -| 25GbE | 3.125 GB/s | SATA SSD (550 MB/s) | 6 disks | -| 100GbE | 12.5 GB/s | NVMe Gen4 (7 GB/s) | 2 disks full-speed read/write | +| 10GbE | 1.25 GB/s | 7.2K HDD（180 MB/s） | 8 ディスク | +| 25GbE | 3.125 GB/s | SATA SSD（550 MB/s） | 6 ディスク | +| 100GbE | 12.5 GB/s | NVMe Gen4（7 GB/s） | 2（読み書きを最高速度で行う場合） | -**Best Practice Case**: A video platform uses 16-node cluster, each node configured with: +**例**: 動画プラットフォームが、16 ノードのクラスターを運用しています。各ノードの構成は次のとおりです。 - 8×7.68 TB NVMe SSD -- Dual 100GbE CX5 network cards -- Achieves aggregate throughput of 38 GB/s +- デュアル 100GbE の NVIDIA ConnectX-5 NIC +- 合計スループットは 38 GB/s に達します -## Memory Configuration Calculator +## メモリ容量の見積もり -Dynamic algorithm based on disk capacity and business characteristics: +ディスク容量とワークロードの種類に基づいてメモリを見積もるには、次の式を使います。 ```python # Memory calculation formula (unit: GB) @@ -101,25 +101,25 @@ def calc_memory(data_tb, access_pattern): return base + data_tb * 1.0 ``` -**Reference Configuration Table**: +**参照サイズ**: -| Data Scale | Read-Intensive | Write-Intensive | Mixed | +| データサイズ | 読み取り中心 | 書き込み中心 | 混合 | |-----------|----------|----------|---------| | 10 TB | 40 GB | 44 GB | 42 GB | | 100 TB | 112 GB | 152 GB | 132 GB | | 500 TB | 432 GB | 632 GB | 532 GB | -## Storage Deployment Standards +## ストレージの指針 -### Media Selection Criteria +### ストレージ媒体の選択 -| Metric | HDD Suitable Scenarios | SSD Suitable Scenarios | NVMe Mandatory Scenarios | +| 指標 | HDD | SATA SSD | NVMe（必須） | |-------------|------------------|---------------------|----------------------| -| Latency Requirements | >50ms | 1 to 10ms | < 1ms | -| Throughput Requirements | < 500 MB/s | 500 MB-3 GB/s | > 3 GB/s | -| Typical Use Cases | Archive storage | Hot data cache | Real-time analysis | +| レイテンシの要件 | 50 ms 超 | 1〜10 ms | 1 ms 未満 | +| スループットの要件 | 500 MB/s 未満 | 500 MB〜3 GB/s | 3 GB/s 超 | +| 典型的な用途 | アーカイブストレージ | ホットデータのキャッシュ | リアルタイム分析 | -### File System Configuration +### ファイルシステムの設定 ```bash # XFS formatting example @@ -129,30 +129,34 @@ mkfs.xfs -f -L rustfs_disk1 -d su=256k,sw=10 /dev/sdb UUID=xxxx /mnt/disk1 xfs defaults,noatime,nodiratime,logbsize=256k 0 0 ``` -## High Availability Assurance Measures +## 高可用性 -1. **Power Supply**: +1. **電源**: -- Adopt dual power supply architecture -- Each PDU connects to different substations -- Equip UPS (at least 30 minutes runtime) + - 二重化（冗長）電源を使います。 + - 各 PDU を別々の電源系統に接続します。 + - 少なくとも 30 分の稼働時間がある UPS を用意します。 -2. **Cooling Requirements**: +2. **冷却の要件**: -- Cabinet power density ≤ 15kW/cabinet -- Inlet/outlet temperature difference controlled within 8℃ + - ラックの電力密度は、1 ラックあたり 15 kW 以下にします。 + - 吸気と排気の温度差（ΔT）を 8 °C 以内に保ちます。 -3. **Firmware Management**: +3. **ファームウェアの管理**: -- Establish hardware compatibility matrix -- Use unified firmware versions + - ハードウェアの互換性マトリックスを維持します。 + - ノード間でファームウェアのバージョンを統一します。 -> **Implementation Recommendations**: Recommend conducting 72-hour stress testing before formal deployment, simulating the following scenarios: -> -> 1. Node failover testing -> 2. Network partition drills -> 3. Burst write pressure testing (recommended reaching 120% of theoretical value) +:::tip[本番稼働の前に] + +本番稼働の前に、次のシナリオを含む 72 時間のストレステストを実施することを推奨します。 + +1. ノードのフェイルオーバーテスト +2. ネットワーク分断のテスト +3. バースト書き込みの負荷テスト（理論上の最大値の 120% でテストすることを推奨します） + +::: --- -This guide is based on the latest RustFS development version. For actual deployment, please combine with specific hardware vendor white papers for parameter fine-tuning. Or contact RustFS official recommendations for quarterly hardware health assessments to ensure continuous stable operation of storage clusters. +このガイドは、最新の RustFS 開発バージョンに基づいています。本番デプロイでは、ハードウェアベンダーのドキュメントに従って、これらの設定を調整します。ハードウェアの健全性を四半期ごとに評価する場合は、RustFS に問い合わせてください。 diff --git a/content/ja/installation/requirement/checklists/hardware-selection.md b/content/ja/installation/requirement/checklists/hardware-selection.md index 8e4ede401..b3b688898 100644 --- a/content/ja/installation/requirement/checklists/hardware-selection.md +++ b/content/ja/installation/requirement/checklists/hardware-selection.md @@ -1,41 +1,41 @@ --- -title: Hardware Selection -description: Hardware requirements for RustFS. +title: ハードウェアの選定 +description: RustFS のテスト環境と本番環境における、最小要件と推奨ハードウェアを示します。 --- -> RustFS is designed for efficiency with a low memory footprint. +> RustFS は、メモリ使用量を抑えて効率的に動作するよう設計されています。 -## Test Environment +## テスト環境 -> Minimal requirements for testing: +テストに必要な最小要件は次のとおりです。 -| Component | Requirement | +| コンポーネント | 要件 | | - | - | -| CPU | 1 core+ | -| Architecture | x86, ARM | -| Memory | 1 GB+ | -| Storage | HDD or SSD | -| Docker | Supported | -| Network | Local or Offline | -| OS | Windows, Linux, macOS | -| Load Balancing | None | -| Nodes | 1 | +| CPU | 1 コア以上 | +| アーキテクチャ | x86、ARM | +| メモリ | 1 GB 以上 | +| ストレージ | HDD または SSD | +| Docker | 対応 | +| ネットワーク | ローカルまたはオフライン | +| OS | Windows、Linux、macOS | +| ロードバランサー | なし | +| ノード | 1 | -## Production Environment +## 本番環境 -Windows 版の RustFS は開発とデバッグ専用で、**本番環境での使用は推奨していません**。本番環境には [Linux](/ja/installation/linux) を推奨します。 +Windows 版の RustFS は、開発とデバッグのみを目的としており、**本番デプロイには推奨しません**。本番ワークロードには [Linux](/ja/installation/linux) を推奨します。 -| Component | Requirement | +| コンポーネント | 要件 | | - | - | -| CPU | 2 x 12 cores+ | -| Architecture | x86, ARM, etc. | -| Memory | 64 GB+ | -| Storage | SSD recommended | -| Network | 10 Gbps+ | -| OS | Linux (Recommended) | -| Load Balancing | Recommended | -| Nodes | 4+ | - -## Expert Services - -For complex deployments, contact support at hello@rustfs.com. +| CPU | 2 × 12 コア以上 | +| アーキテクチャ | x86、ARM など | +| メモリ | 64 GB 以上 | +| ストレージ | SSD を推奨 | +| ネットワーク | 10 Gbps 以上 | +| OS | Linux（推奨） | +| ロードバランサー | 推奨 | +| ノード | 4 以上 | + +## 専門サービス + +複雑なデプロイについては、hello@rustfs.com のサポートに問い合わせてください。 diff --git a/content/ja/installation/requirement/checklists/index.md b/content/ja/installation/requirement/checklists/index.md index 7b1f73a8b..8c9848128 100644 --- a/content/ja/installation/requirement/checklists/index.md +++ b/content/ja/installation/requirement/checklists/index.md @@ -1,24 +1,24 @@ --- -title: "Checklist" -description: "Pre-installation checklists." +title: "インストール前チェックリスト" +description: "本番環境に必要な準備を確認するための、インストール前チェックリストです。" --- -These checklists cover the necessary preparations for a production environment. +これらのチェックリストは、本番環境に必要な準備をまとめたものです。 :::note -These are general guidelines. Adjust them based on your specific architecture and requirements. +これらは一般的な指針です。具体的なアーキテクチャと要件に合わせて調整します。 ::: -For professional support, contact us at hello@rustfs.com. +プロフェッショナルサポートが必要な場合は、hello@rustfs.com に問い合わせてください。 -For community support, submit an issue on GitHub. +コミュニティサポートが必要な場合は、GitHub で issue を作成します。 -## Checklist +## チェックリスト -- [Hardware Checklist](./hardware-checklists.md) -- [Hardware Selection](./hardware-selection.md) -- [Security Checklist](./security-checklists.md) -- [Software Checklist](./software-checklists.md) -- [Network Checklist](./network-checklists.md) +- [ハードウェアチェックリスト](./hardware-checklists.md) +- [ハードウェアの選定](./hardware-selection.md) +- [セキュリティチェックリスト](./security-checklists.md) +- [ソフトウェアチェックリスト](./software-checklists.md) +- [ネットワークチェックリスト](./network-checklists.md) diff --git a/content/ja/installation/requirement/checklists/network-checklists.md b/content/ja/installation/requirement/checklists/network-checklists.md index 8f77cd5ad..2cbbc28b1 100644 --- a/content/ja/installation/requirement/checklists/network-checklists.md +++ b/content/ja/installation/requirement/checklists/network-checklists.md @@ -1,49 +1,49 @@ --- -title: "Network Checklist" -description: "Network checklist for enterprise deployments." +title: "ネットワークチェックリスト" +description: "エンタープライズのデプロイに使う、ネットワークのチェックリストです。" --- -## Network Architecture +## ネットワークアーキテクチャ -### Planning +### 計画 -- **Topology** - Verify the architecture (star/ring/mesh) meets high availability requirements. -- **Redundancy** - Ensure at least two independent physical links between nodes. -- **Bandwidth** - Calculate estimated traffic: object storage read/write bandwidth × node count × replica count + 20% redundancy. +- **トポロジー** + アーキテクチャ（スター、リング、メッシュ）が高可用性の要件を満たしていることを確認します。 +- **冗長性** + ノード間に、独立した物理リンクを少なくとも 2 本確保します。 +- **帯域** + トラフィックは、読み書き帯域 × ノード数 × レプリカ数に、20% の余裕を加えた値として見積もります。 -### IP Allocation +### IP の割り当て -- [ ] Separate management network from data network. -- [ ] Allocate continuous IP segments for storage nodes (recommend /24 subnet). -- [ ] Reserve at least 15% of IP addresses for expansion. +- [ ] 管理ネットワークとデータネットワークを分離します。 +- [ ] ストレージノード向けに、連続した IP アドレス範囲を割り当てます。/24 サブネットを推奨します。 +- [ ] 拡張用に、IP アドレスの少なくとも 15% を予約します。 --- -## Hardware Requirements +## ハードウェア要件 -### Switches +### スイッチ -| Check Item | Requirements | +| 項目 | 要件 | |--------|---------| -| Backplane Bandwidth | ≥ Full port line rate forwarding capability × 1.2 | -| Port Type | 10G/25G/100G SFP+/QSFP+ fiber ports | -| Flow Table Capacity | ≥ Node count × 5 | -| Spanning Tree | Enable RSTP/MSTP fast convergence | +| バックプレーン帯域 | 全ポートの回線速度の合計 × 1.2 以上 | +| ポートの種類 | 10G/25G/100G の SFP+/QSFP+ ファイバーポート | +| フローテーブル容量 | ノード数 × 5 以上 | +| スパニングツリー | 高速に収束するよう、RSTP または MSTP を有効にします | -### Cabling +### 配線 -- [ ] Fiber attenuation test (single mode ≤0.35dB/km). -- [ ] Port misalignment check (Node A eth0 ↔ Node B eth0). -- [ ] Cable labeling (including source/destination IP + port number). +- [ ] ファイバーの減衰試験（シングルモードは 0.35 dB/km 以下）。 +- [ ] ポートの対応を確認します（ノード A の eth0 ↔ ノード B の eth0）。 +- [ ] ケーブルにラベルを付けます（送信元と宛先の IP、およびポート番号を含む）。 --- -## OS Configuration +## OS の設定 -### Kernel Tuning +### カーネルのチューニング ```bash # Check the following parameter settings @@ -53,17 +53,17 @@ net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_slow_start_after_idle = 0 ``` -### NIC Configuration +### NIC の設定 -- [ ] Enable jumbo frames (MTU=9000, requires full path support). -- [ ] Verify bonding mode (recommend LACP mode4). -- [ ] Disable IPv6 (if not needed). +- [ ] ジャンボフレームを有効にします（MTU=9000。経路全体の対応が必要です）。 +- [ ] ボンディングモードを確認します（LACP mode4 を推奨）。 +- [ ] IPv6 を無効にします（不要な場合）。 --- -## Security +## セキュリティ -### Firewall +### ファイアウォール ```text # Necessary open ports @@ -72,43 +72,43 @@ net.ipv4.tcp_slow_start_after_idle = 0 - TCP 443 (only if you terminate HTTPS on a reverse proxy / load balancer) ``` -### Access Control +### アクセス制御 -- Switch port security MAC restrictions. -- IPSec tunnel encryption between storage nodes. -- Enable TLS 1.3 for management interfaces. +- スイッチでポートセキュリティ（MAC アドレス数の制限）を有効にします。 +- ストレージノード間の通信を IPsec で暗号化します。 +- 管理インターフェースでは TLS 1.3 を有効にします。 --- -## Performance Testing +## 性能テスト -### Benchmarks +### ベンチマーク -1. Inter-node latency: `ping -c 20 ` (run `iperf3 -s` on the target first for throughput tests) -2. Cross-rack bandwidth: `iperf3 -c -P 8 -t 30` -3. Failover: Randomly disconnect core links to observe recovery time. +1. ノード間のレイテンシ: `ping -c 20 `（スループットのテストでは、先に対象で `iperf3 -s` を実行します） +2. ラック間の帯域: `iperf3 -c -P 8 -t 30` +3. フェイルオーバー: 基幹リンクを無作為に切断し、復旧にかかる時間を確認します。 -### Criteria +### 基準 -| Metric | Requirements | +| 指標 | 要件 | |------|------| -| Node Latency | ≤1ms (same room) / ≤5ms (cross AZ) | -| Bandwidth Utilization | Peak ≤70% of design capacity | -| Failover | < 500ms BPDU convergence | +| ノードのレイテンシ | 1 ms 以下（同一データセンター）/ 5 ms 以下（AZ 間） | +| 帯域使用率 | ピーク時は設計容量の 70% 以下 | +| フェイルオーバー | BPDU の収束は 500 ms 未満 | --- -## Documentation Requirements +## ドキュメントの要件 -1. Network topology diagram (including physical connections and logical IPs) -2. Switch configuration backup files (with timestamps) -3. Baseline test reports (including raw data) -4. Change record table (including maintenance window information) +1. ネットワークトポロジー図（物理接続と論理 IP を含む） +2. スイッチ設定のバックアップファイル（タイムスタンプ付き） +3. ベースラインテストの報告書（生データを含む） +4. 変更履歴（メンテナンス時間帯を含む） :::tip -Recommend conducting 72-hour stress testing before formal deployment, simulating 110% peak traffic load scenarios +本番へデプロイする前に、想定されるピークトラフィックの 110% で 72 時間のストレステストを実施することを推奨します。 ::: -This checklist covers key checkpoints for enterprise storage system network deployment, specifically optimized parameter requirements for distributed object storage characteristics. You can contact RustFS for official technical support. +このチェックリストは、エンタープライズ環境に分散オブジェクトストレージをデプロイするときの、主要なネットワーク要件をまとめたものです。技術サポートが必要な場合は、RustFS に問い合わせてください。 diff --git a/content/ja/installation/requirement/checklists/security-checklists.md b/content/ja/installation/requirement/checklists/security-checklists.md index 5024450ed..f6ddafe76 100644 --- a/content/ja/installation/requirement/checklists/security-checklists.md +++ b/content/ja/installation/requirement/checklists/security-checklists.md @@ -1,78 +1,78 @@ --- -title: "Security Checklist" -description: "Security checklist for enterprise deployments." +title: "セキュリティチェックリスト" +description: "エンタープライズのデプロイに使う、セキュリティのチェックリストです。" --- -> Security best practices for RustFS. Review this checklist during deployment to ensure system security and reliability. +> RustFS のセキュリティに関するベストプラクティスです。デプロイ時にこのチェックリストを確認し、システムのセキュリティと信頼性を保ちます。 -## Authentication & Access Control +## 認証とアクセス制御 -- **Use S3-Compatible Key Authentication** - RustFS uses AWS Signature V4. Ensure all requests are authenticated with valid Access Keys and Secret Keys. +- **S3 互換のキー認証を使う** + RustFS は AWS Signature V4 を使います。すべてのリクエストが、有効なアクセスキーとシークレットキーで署名されていることを確認します。 -- **Policy-Based Access Control** - Define access policies based on the principle of least privilege. Explicitly define allowed operations; deny all others by default. +- **ポリシーに基づくアクセス制御** + 最小権限の原則に基づいてアクセスポリシーを定義します。許可する操作を明示し、それ以外はデフォルトで拒否します。 -## Encryption (TLS/SSL) +## 暗号化（TLS/SSL） -- **Enable TLS/SSL** - Configure valid SSL certificates. We recommend using different certificates for external and internal access, and enforcing TLS 1.2+. +- **TLS/SSL を有効にする** + 有効な TLS 証明書を設定します。外部アクセスと内部アクセスで別々の証明書を使い、TLS 1.2 以上を必須とすることを推奨します。 -- **Certificate Management** - Use certificates from trusted CAs. Protect private keys with strict file permissions. +- **証明書の管理** + 信頼できる CA が発行した証明書を使います。秘密鍵は、厳格なファイル権限で保護します。 -- **Multi-Domain and Cipher Suites** - Configure independent certificates for multiple domains. Use strong encryption algorithms (e.g., 2048-bit RSA or 256-bit ECC). +- **マルチドメインと暗号スイート** + ドメインごとに別の証明書を使います。強力な鍵アルゴリズム（例: RSA 2048 ビット、ECDSA P-256）を使います。 -## Credential Protection +## 認証情報の保護 -- **Change Default Credentials** - Never keep the example placeholders (`` / ``) in production. Set a unique access key and a strong, random secret — e.g. generate one with `openssl rand -base64 24` — immediately after initialization. +- **デフォルトの認証情報を変更する** + 本番環境では、例示用のプレースホルダー（`` / ``）を残さないでください。初期化の直後に、一意のアクセスキーと、強力でランダムなシークレットを設定します。シークレットは、たとえば `openssl rand -base64 24` で生成できます。 -- **Secure Storage** - Do not hardcode credentials. Use environment variables or secrets management systems (e.g., Kubernetes Secrets). +- **安全な保管** + 認証情報をハードコードしないでください。環境変数、またはシークレット管理システム（例: Kubernetes Secrets）を使います。 -## Logging & Auditing +## ログと監査 -- **Enable Audit Logs** - Export audit logs to external systems (HTTP Webhook, Kafka, ELK, Splunk). +- **監査ログを有効にする** + 監査ログを外部システム（HTTP Webhook、Kafka、ELK、Splunk）へエクスポートします。 -- **Log Collection** - Collect logs using standard tools (systemd, Docker, K8s) and analyze with ELK or Grafana Loki. +- **ログの収集** + 標準的なツール（journald、Docker、Kubernetes）でログを収集し、ELK または Grafana Loki で分析します。 -- **Monitoring and Alerts** - Set alerts for abnormal behavior (login failures, unusual access patterns, mass deletions). +- **監視とアラート** + 異常な挙動（ログイン失敗、通常と異なるアクセスパターン、大量削除）に対するアラートを設定します。 -- **Observability** - Monitor function execution times to optimize performance. +- **オブザーバビリティ** + リクエストのレイテンシを監視し、性能上の問題を見つけます。 -## API Security +## API のセキュリティ -- **Restrict Network Access** - Restrict access to the S3 API (port 9000) and Console (port 9001) using firewalls or security groups. +- **ネットワークアクセスを制限する** + ファイアウォールまたはセキュリティグループを使い、S3 API（ポート 9000）と Console（ポート 9001）へのアクセスを制限します。 -- **Network Isolation** - Use reverse proxies (e.g., Nginx) instead of exposing storage nodes directly. +- **ネットワークの分離** + ストレージノードを直接公開せず、リバースプロキシ（例: Nginx）を経由します。 -- **Close Unnecessary Ports** - Disable unused ports and do not expose management interfaces to the public internet. +- **不要なポートを閉じる** + 未使用のポートを無効にします。管理インターフェースを公開インターネットへ公開しないでください。 -## WORM Compliance +## WORM コンプライアンス -- **Version Control and Object Locking** - Enable versioning and object locking to meet regulatory requirements. +- **バージョニングとオブジェクトロック** + 規制要件を満たすため、バージョニングとオブジェクトロックを有効にします。 -## Updates +## 更新 -- **Apply Patches** - Regularly check for and apply RustFS updates. +- **パッチを適用する** + RustFS の更新を定期的に確認し、適用します。 -- **Non-Disruptive Upgrades** - Use the rolling restart process for zero-downtime upgrades. +- **無停止アップグレード** + ダウンタイムなしでアップグレードするには、ローリングリスタートの手順を使います。 -- **OS and Dependencies** - Keep the operating system and dependencies (e.g., OpenSSL) updated. +- **OS と依存関係** + オペレーティングシステムと依存関係（例: OpenSSL）を最新の状態に保ちます。 --- -Review this checklist regularly to maintain a secure RustFS deployment. +安全な RustFS のデプロイを維持するため、このチェックリストを定期的に見直します。 diff --git a/content/ja/installation/requirement/checklists/software-checklists.md b/content/ja/installation/requirement/checklists/software-checklists.md index d2ed35b81..7b9c77504 100644 --- a/content/ja/installation/requirement/checklists/software-checklists.md +++ b/content/ja/installation/requirement/checklists/software-checklists.md @@ -1,50 +1,50 @@ --- -title: "Software Checklist" -description: "Software requirements and considerations." +title: "ソフトウェアチェックリスト" +description: "デプロイ前に確認する、ソフトウェアの要件と考慮事項をまとめます。" --- -Ensure the following requirements are met before deployment. +デプロイの前に、次の要件を満たしていることを確認します。 -## OS Requirements +## OS の要件 -- **Operating System**: Use LTS versions (Ubuntu 20.04+, RHEL 8/9). -- **Kernel**: Linux 5.x+ is recommended. -- **CPU & Memory**: x86_64 or ARM. Minimum 2 GB RAM for testing, 64 GB+ for production. -- **Disable Interfering Services**: Disable file indexing and auditing services (e.g., `mlocate`, `auditd`, antivirus) to prevent I/O interference. +- **オペレーティングシステム**: LTS バージョン（Ubuntu 20.04 以降、RHEL 8/9）を使います。 +- **カーネル**: Linux 5.x 以降を推奨します。 +- **CPU とメモリ**: x86_64 または ARM です。テストでは最低 2 GB の RAM、本番では 64 GB 以上が必要です。 +- **干渉するサービスを無効にする**: I/O への干渉を防ぐため、ファイルのインデックス作成や監査のサービス（例: `mlocate`、`auditd`、ウイルス対策）を無効にします。 -> **Why Linux 5.x+?** -> Modern LTS kernels bring mature async I/O and filesystem improvements. RustFS also offers an optional `io_uring` read path (`RUSTFS_IO_URING_READ_ENABLE`, disabled by default), which requires Linux 5.10+ to be effective. +> **Linux 5.x 以降を使う理由** +> 近年の LTS カーネルには、十分に成熟した非同期 I/O と、ファイルシステムの改善が含まれています。RustFS には任意の `io_uring` 読み取りパス（`RUSTFS_IO_URING_READ_ENABLE`。デフォルトでは無効）もあり、効果を得るには Linux 5.10 以降が必要です。 -## Binary Deployment +## バイナリのデプロイ -- **Official Download**: Download binaries only from official RustFS channels. -- **Integrity Verification**: Verify SHA256 checksums. -- **Consistency**: Ensure all nodes run the same RustFS version. -- **Installation Location**: Place binaries in `/usr/local/bin` and ensure they are executable (`chmod +x`). +- **公式からのダウンロード**: バイナリは、RustFS の公式チャネルからのみダウンロードします。 +- **整合性の検証**: SHA256 チェックサムを検証します。 +- **一貫性**: すべてのノードで、同じ RustFS のバージョンを実行します。 +- **インストール先**: バイナリは `/usr/local/bin` に配置し、実行可能にします（`chmod +x`）。 -## File System & Disks +## ファイルシステムとディスク -- **Dedicated Data Disks**: Use dedicated disks for RustFS data. Do not share with the OS. -- **File System**: Use XFS or Ext4 with performance options (e.g., `noatime`). -- **Disk Configuration**: Use JBOD (independent volumes). Do not use hardware RAID. -- **Permissions**: Ensure the RustFS user has read/write access to data directories. +- **専用のデータディスク**: RustFS のデータには専用ディスクを使います。OS と同じディスクは共用しないでください。 +- **ファイルシステム**: XFS または ext4 を使い、`noatime` などの性能向けマウントオプションを指定します。 +- **ディスク構成**: JBOD（独立したボリューム）を使います。ハードウェア RAID は使わないでください。 +- **権限**: RustFS の実行ユーザーが、データディレクトリへの読み書き権限を持っていることを確認します。 -## Dependencies +## 依存関係 -- **Time Synchronization**: Synchronize time across all nodes using `ntp` or `chrony`. -- **Hostname and DNS**: Configure persistent hostnames and ensure proper DNS resolution. -- **Network Connectivity**: Ensure all nodes can communicate on the RustFS port (default 9000). -- **TLS/Certificates**: Install root certificates and prepare server certificates if using HTTPS. -- **Packages**: Ensure standard tools (`bash`, `glibc`, `openssl`) are installed. +- **時刻同期**: `ntp` または `chrony` を使い、すべてのノードの時刻を同期します。 +- **ホスト名と DNS**: 永続的なホスト名を設定し、DNS が正しく解決されることを確認します。 +- **ネットワーク接続**: すべてのノードが、RustFS のポート（デフォルトは 9000）で互いに通信できることを確認します。 +- **TLS と証明書**: HTTPS を使う場合は、ルート証明書をインストールし、サーバー証明書を準備します。 +- **パッケージ**: 標準ツール（`bash`、`glibc`、`openssl`）がインストールされていることを確認します。 -## User & Security +## ユーザーとセキュリティ -- **Dedicated User**: Run RustFS as a dedicated user (e.g., `rustfs-user`). -- **File Permissions**: Restrict access to binaries and configuration files. -- **SELinux/AppArmor**: Configure policies to allow RustFS operations, or disable if appropriate. -- **Systemd**: Configure the systemd service file correctly (`User=`, `ExecStart=`, environment variables). +- **専用ユーザー**: RustFS は専用ユーザー（例: `rustfs-user`）として実行します。 +- **ファイル権限**: バイナリと設定ファイルへのアクセスを制限します。 +- **SELinux/AppArmor**: RustFS の動作を許可するポリシーを設定します。適切な場合は、無効にすることもできます。 +- **systemd**: systemd のサービスファイルを正しく設定します（`User=`、`ExecStart=`、環境変数）。 -## Other +## その他 -- **Monitoring**: Configure Prometheus and Grafana. -- **Rollback Plan**: Prepare configuration backups and a rollback plan. +- **監視**: Prometheus と Grafana を設定します。 +- **ロールバック計画**: 設定のバックアップと、ロールバックの計画を用意します。 diff --git a/content/ja/installation/requirement/disk-preparation.md b/content/ja/installation/requirement/disk-preparation.md index e8fed45d8..f77fc0ada 100644 --- a/content/ja/installation/requirement/disk-preparation.md +++ b/content/ja/installation/requirement/disk-preparation.md @@ -1,83 +1,83 @@ --- -title: "Disk Preparation" -description: "Identify, format, mount, and verify dedicated data disks before installing RustFS on Linux." +title: "ディスクの準備" +description: "Linux に RustFS をインストールする前に、専用データディスクの識別、フォーマット、マウント、確認を行います。" --- -Prepare each RustFS data disk as an independent XFS file system with a stable label and mount point. Complete these steps on every Linux node before configuring `RUSTFS_VOLUMES`. +各 RustFS データディスクを、安定したラベルとマウントポイントを持つ独立した XFS ファイルシステムとして準備します。`RUSTFS_VOLUMES` を設定する前に、すべての Linux ノードでこれらの手順を完了します。 -:::warning[Formatting destroys data] +:::warning[フォーマットはデータを消去します] -The `mkfs.xfs` command erases the selected device. Confirm the device name, back up any required data, and ensure the disk is not used by the operating system before continuing. +`mkfs.xfs` コマンドは、選択したデバイスの内容を消去します。続行する前に、デバイス名を確認し、必要なデータをバックアップし、そのディスクがオペレーティングシステムで使われていないことを確認します。 ::: -## 1. Identify the data disks +## 1. データディスクを識別する -List block devices, file systems, labels, and current mount points: +ブロックデバイス、ファイルシステム、ラベル、現在のマウントポイントを一覧表示します。 ```bash sudo lsblk -o NAME,SIZE,TYPE,FSTYPE,LABEL,UUID,MOUNTPOINTS ``` -Choose only dedicated data disks. Do not format the operating-system disk or a device that contains data you need to retain. +専用のデータディスクだけを選びます。オペレーティングシステムのディスクや、保持が必要なデータを含むデバイスはフォーマットしないでください。 -## 2. Format a disk with XFS +## 2. ディスクを XFS でフォーマットする -The following example prepares `/dev/sdb` and assigns the label `RUSTFS0`. Replace the device name for your environment and use a unique label for each disk. +次の例では `/dev/sdb` を準備し、ラベル `RUSTFS0` を割り当てます。環境に合わせてデバイス名を置き換え、ディスクごとに一意のラベルを使います。 ```bash sudo mkfs.xfs -f -i size=512 -n ftype=1 -L RUSTFS0 /dev/sdb ``` -Repeat the command for additional disks with labels such as `RUSTFS1`, `RUSTFS2`, and `RUSTFS3`. +追加のディスクでは、`RUSTFS1`、`RUSTFS2`、`RUSTFS3` などのラベルを付けてコマンドを繰り返します。 -## 3. Create a persistent mount +## 3. 永続的なマウントを作成する -Create the mount point: +マウントポイントを作成します。 ```bash sudo mkdir -p /data/rustfs0 ``` -Add an entry to `/etc/fstab` so the disk is mounted by its stable file-system label after a restart: +再起動後も、安定したファイルシステムラベルでディスクがマウントされるよう、`/etc/fstab` にエントリを追加します。 ```ini title="/etc/fstab" LABEL=RUSTFS0 /data/rustfs0 xfs defaults,noatime,nodiratime 0 0 ``` -For more reliable device selection, we recommend mounting by file-system UUID. A UUID uniquely identifies the file system and avoids mounting the wrong disk if labels are duplicated or Linux device names change. Retrieve the UUID after formatting: +デバイスをより確実に選ぶには、ファイルシステムの UUID でマウントすることを推奨します。UUID はファイルシステムを一意に識別するため、ラベルが重複した場合や Linux のデバイス名が変わった場合でも、誤ったディスクのマウントを避けられます。フォーマット後に UUID を取得します。 ```bash sudo blkid -s UUID -o value /dev/sdb ``` -Replace `` with the returned value, and use this entry instead of the `LABEL` entry above: +`` を返された値に置き換え、上の `LABEL` エントリの代わりに、このエントリを使います。 ```ini title="/etc/fstab" UUID= /data/rustfs0 xfs defaults,noatime,nodiratime 0 0 ``` -Mount all entries and confirm the result: +すべてのエントリをマウントし、結果を確認します。 ```bash sudo mount -a findmnt /data/rustfs0 ``` -For multiple disks, create one mount point and one `/etc/fstab` entry per file-system UUID. +ディスクが複数ある場合は、ファイルシステムの UUID ごとに、マウントポイントと `/etc/fstab` のエントリを 1 つずつ作成します。 -## 4. Verify the prepared disks +## 4. 準備したディスクを確認する -Confirm that every expected mount uses XFS and has sufficient free space: +想定するすべてのマウントが XFS を使い、十分な空き容量があることを確認します。 ```bash df -hT /data/rustfs0 sudo xfs_info /data/rustfs0 ``` -Use the verified mount paths when you configure `RUSTFS_VOLUMES`. Keep disk labels and mount paths consistent across nodes in a distributed deployment. +`RUSTFS_VOLUMES` を設定するときは、確認済みのマウントパスを使います。分散デプロイでは、ディスクラベルとマウントパスをノード間で揃えます。 -## Next steps +## 次のステップ -- [Choose a deployment topology](/installation#deployment-mode-comparison) -- [Continue with Linux prerequisites and service setup](/installation/linux/prerequisites-and-service) \ No newline at end of file +- [デプロイトポロジーを選ぶ](/ja/installation#deployment-mode-comparison) +- [Linux の前提条件とサービスのセットアップに進む](/ja/installation/linux/prerequisites-and-service) diff --git a/content/ja/installation/requirement/ec-configuration.md b/content/ja/installation/requirement/ec-configuration.md index e38e4f7ea..3666f88df 100644 --- a/content/ja/installation/requirement/ec-configuration.md +++ b/content/ja/installation/requirement/ec-configuration.md @@ -1,32 +1,32 @@ --- -title: "EC Configuration" -description: "Plan and configure RustFS erasure-set size and parity before deploying storage pools." +title: "EC 構成" +description: "ストレージプールをデプロイする前に、RustFS のイレイジャーセットのサイズとパリティを計画し、設定します。" --- -RustFS uses Reed-Solomon erasure coding (EC) to distribute each object across the drives in an erasure set. Use this page to estimate usable capacity, understand the automatic defaults, and decide whether your deployment needs an explicit parity setting. +RustFS は Reed-Solomon イレイジャーコーディング（EC）を使い、各オブジェクトをイレイジャーセット内のドライブへ分散します。このページでは、使用可能な容量の見積もり、自動デフォルトの内容、デプロイに明示的なパリティ設定が必要かどうかの判断を説明します。 -## Understand the layout +## レイアウトを理解する -Each storage pool is divided into one or more erasure sets. For a set with `N` drives and `M` parity shards: +各ストレージプールは、1 つ以上のイレイジャーセットに分かれます。ドライブ数 `N`、パリティシャード数 `M` のセットでは、次のとおりです。 -- data shards: `N - M` -- parity shards: `M` -- maximum unavailable shards that can be reconstructed: `M` -- approximate capacity efficiency: `(N - M) / N` +- データシャード: `N - M` +- パリティシャード: `M` +- 再構成できる、利用不能なシャードの最大数: `M` +- おおよその容量効率: `(N - M) / N` -For example, a 16-drive set with `EC:4` stores 12 data shards and 4 parity shards. Its approximate capacity efficiency is 75% before file-system, metadata, and operational overhead. +たとえば、`EC:4` の 16 ドライブセットは、データシャード 12 個とパリティシャード 4 個を保存します。ファイルシステム、メタデータ、運用上のオーバーヘッドを除くと、おおよその容量効率は 75% です。 -:::note[Failure domains] +:::note[障害ドメイン] -Parity describes unavailable shards within one erasure set. Node-level fault tolerance depends on how the set's drives are distributed across nodes. Do not assume that `EC:4` always tolerates four complete node failures; a node can host multiple drives from the same set. +パリティが示すのは、1 つのイレイジャーセット内で利用不能になったシャードです。ノード単位の耐障害性は、そのセットのドライブがノード間にどう配置されているかで決まります。`EC:4` であれば、ノード 4 台の完全停止に常に耐えられるわけではありません。1 台のノードが、同じセットに属する複数のドライブを持つことがあります。 ::: -## Automatic parity +## 自動パリティ -We recommend leaving `RUSTFS_STORAGE_CLASS_STANDARD` unset unless you have a specific, validated durability or capacity requirement. RustFS derives STANDARD parity independently for each pool from its drives per erasure set: +検証済みの特定の耐久性要件または容量要件がない限り、`RUSTFS_STORAGE_CLASS_STANDARD` は未設定のままにすることを推奨します。RustFS は、イレイジャーセットあたりのドライブ数から、プールごとに STANDARD のパリティを独立して算出します。 -| Drives per erasure set (`N`) | Automatic STANDARD parity | Data shards | Approximate efficiency | +| イレイジャーセットあたりのドライブ数（`N`） | 自動の STANDARD パリティ | データシャード | おおよその効率 | | --- | --- | --- | --- | | 1 | `EC:0` | 1 | 100% | | 2–3 | `EC:1` | `N - 1` | 50%–67% | @@ -34,82 +34,82 @@ We recommend leaving `RUSTFS_STORAGE_CLASS_STANDARD` unset unless you have a spe | 6–7 | `EC:3` | `N - 3` | 50%–57% | | 8–16 | `EC:4` | `N - 4` | 50%–75% | -Multi-drive erasure sets contain between 2 and 16 drives. A single-drive deployment is a separate layout with zero parity. +複数ドライブのイレイジャーセットに含まれるドライブ数は 2 から 16 です。シングルドライブのデプロイは、パリティがゼロの別のレイアウトです。 -:::warning[Use the set width, not the cluster total] +:::warning[セット幅でパリティを検証する] -Validate parity against the number of drives in each erasure set, not the total number of drives in the cluster. A cluster can contain multiple sets or pools with different widths. +パリティは、クラスター内のドライブ総数ではなく、各イレイジャーセットのドライブ数に対して検証します。クラスターには、幅の異なる複数のセットやプールを含められます。 ::: -## Estimate usable capacity +## 使用可能な容量を見積もる -For a pool whose sets all use the same width and parity, estimate EC capacity with: +セットがすべて同じ幅とパリティを使うプールでは、次の式で EC の容量を見積もります。 $$ \text{usable capacity} \approx \text{raw capacity} \times \frac{N-M}{N} $$ -For example, 16 equal 10 TiB drives arranged as one 16-drive set with `EC:4` provide approximately: +たとえば、それぞれ 10 TiB のドライブ 16 台を、`EC:4` の 16 ドライブセット 1 つとして配置した場合、おおよそ次の容量になります。 $$ 160\ \text{TiB} \times \frac{16-4}{16} = 120\ \text{TiB} $$ -Reserve additional capacity for XFS, object metadata, versioning, incomplete uploads, healing, and normal operational headroom. Treat the result as a planning estimate, not guaranteed available space. +XFS、オブジェクトのメタデータ、バージョニング、未完了のアップロード、データ修復、通常の運用上の余裕のために、追加の容量を確保します。この結果は計画用の見積もりであり、利用できる容量を保証するものではありません。 -## Configure parity +## パリティを設定する -Set EC variables in the same environment file used by the RustFS service, such as `/etc/default/rustfs`. +EC の変数は、RustFS サービスが使う環境ファイル（例: `/etc/default/rustfs`）に設定します。 -To use the recommended automatic STANDARD parity, omit `RUSTFS_STORAGE_CLASS_STANDARD` or leave it empty: +推奨する自動の STANDARD パリティを使うには、`RUSTFS_STORAGE_CLASS_STANDARD` を省略するか、空のままにします。 ```ini title="/etc/default/rustfs" RUSTFS_STORAGE_CLASS_STANDARD= ``` -To pin parity explicitly, use the `EC:` format: +パリティを明示的に固定するには、`EC:` 形式を使います。 ```ini title="/etc/default/rustfs" RUSTFS_STORAGE_CLASS_STANDARD=EC:4 RUSTFS_STORAGE_CLASS_RRS=EC:1 ``` -`RUSTFS_STORAGE_CLASS_STANDARD` controls writes using the `STANDARD` storage class. `RUSTFS_STORAGE_CLASS_RRS` controls `REDUCED_REDUNDANCY` writes and defaults to one parity shard on multi-drive sets. RustFS accepts these two storage classes for local writes. +`RUSTFS_STORAGE_CLASS_STANDARD` は、`STANDARD` ストレージクラスを使う書き込みを制御します。`RUSTFS_STORAGE_CLASS_RRS` は `REDUCED_REDUNDANCY` の書き込みを制御し、複数ドライブのセットではデフォルトでパリティシャードが 1 個です。RustFS は、ローカル書き込みについて、これら 2 つのストレージクラスを受け付けます。 -Explicit settings must satisfy all of these rules: +明示的な設定は、次の規則をすべて満たす必要があります。 -- parity must be no greater than half of the drives in every target set: `M <= N / 2` -- STANDARD parity must be greater than or equal to REDUCED_REDUNDANCY parity when both are non-zero -- the configured parity must be valid for every pool, including the narrowest pool +- パリティは、対象となるすべてのセットで、ドライブ数の半分以下である必要があります: `M <= N / 2` +- 両方がゼロでない場合、STANDARD のパリティは REDUCED_REDUNDANCY のパリティ以上である必要があります +- 設定したパリティは、最も狭いプールを含むすべてのプールで有効である必要があります -RustFS validates explicit storage classes against each pool during startup. An invalid value causes startup to fail instead of silently reducing parity. Remove the explicit STANDARD value to return to per-pool automatic parity, or choose a value every pool can satisfy. +RustFS は起動時に、明示的なストレージクラスを各プールに対して検証します。値が無効な場合、パリティを暗黙に下げることはせず、起動が失敗します。プールごとの自動パリティに戻すには、明示的な STANDARD の値を削除します。すべてのプールが満たせる値を選ぶこともできます。 -## Control erasure-set width +## イレイジャーセットの幅を制御する -RustFS normally selects a valid set width automatically from the volume topology. Multi-drive set widths range from 2 through 16. +RustFS は通常、ボリュームトポロジーから有効なセット幅を自動的に選びます。複数ドライブのセット幅は 2 から 16 です。 -`RUSTFS_ERASURE_SET_DRIVE_COUNT` can pin the width when you need a specific symmetric layout: +特定の対称レイアウトが必要な場合は、`RUSTFS_ERASURE_SET_DRIVE_COUNT` で幅を固定できます。 ```ini title="/etc/default/rustfs" RUSTFS_ERASURE_SET_DRIVE_COUNT=16 ``` -The value must divide the pool topology symmetrically and be valid for every volume expansion pattern. RustFS rejects a width that cannot evenly partition the configured endpoints. Leave this variable unset unless you have verified the complete pool layout. +この値は、プールトポロジーを対称に分割でき、すべてのボリューム拡張パターンで有効である必要があります。設定されたエンドポイントを均等に分割できない幅は、RustFS が拒否します。プールレイアウト全体を確認していない場合は、この変数を未設定のままにします。 -## Validate the configuration +## 設定を検証する -Before starting or restarting RustFS: +RustFS を起動または再起動する前に、次を確認します。 -1. Determine the drives per erasure set for every pool. -2. Confirm that explicit parity does not exceed half of the narrowest set width. -3. Estimate usable capacity and reserve operational headroom. -4. Keep the same service environment configuration on every node. +1. すべてのプールについて、イレイジャーセットあたりのドライブ数を特定します。 +2. 明示的なパリティが、最も狭いセット幅の半分を超えないことを確認します。 +3. 使用可能な容量を見積もり、運用上の余裕を確保します。 +4. すべてのノードで、同じサービスの環境設定を維持します。 -After startup, use the Console **Status** page or `rc admin info cluster` to confirm the backend layout, erasure-coding parity, drive availability, and pool membership. See [Status Check](/operations/status-check) for the complete workflow. +起動後は、Console の **Status**（ステータス）ページ、または `rc admin info cluster` で、バックエンドのレイアウト、イレイジャーコーディングのパリティ、ドライブの可用性、プールへの所属を確認します。手順の全体は [ステータス確認](/ja/operations/status-check) を参照してください。 -## Next steps +## 次のステップ -- [Prepare data disks](./disk-preparation.md) -- [Choose a deployment topology](/installation#deployment-mode-comparison) -- [Review all storage environment variables](/reference/environment-variables#storage--erasure) \ No newline at end of file +- [データディスクを準備する](./disk-preparation.md) +- [デプロイトポロジーを選ぶ](/ja/installation#deployment-mode-comparison) +- [ストレージ関連の環境変数をすべて確認する](/ja/reference/environment-variables#storage--erasure) diff --git a/content/ja/installation/windows/index.md b/content/ja/installation/windows/index.md index 4d0c950ae..59a0035ec 100644 --- a/content/ja/installation/windows/index.md +++ b/content/ja/installation/windows/index.md @@ -1,125 +1,125 @@ --- -title: "Install RustFS on Windows" -description: "Install a local RustFS instance on Windows with RustFS Launcher or the standalone server binary." +title: "Windows に RustFS をインストールする" +description: "RustFS Launcher またはスタンドアロンのサーバーバイナリを使い、Windows にローカルの RustFS インスタンスをインストールします。" --- -This guide provides two ways to run **RustFS** on Windows: use the graphical **RustFS Launcher**, or download and run the standalone server binary from PowerShell. Both methods create a local, single-node instance suitable for evaluation, development, and testing. +このガイドでは、Windows で **RustFS** を実行する 2 つの方法を説明します。グラフィカルな **RustFS Launcher** を使う方法と、PowerShell からスタンドアロンのサーバーバイナリをダウンロードして実行する方法です。どちらも、評価、開発、テストに適したローカルのシングルノードインスタンスを作成します。 :::warning[開発とデバッグ専用] -Windows 版の RustFS は開発とデバッグ専用で、**本番環境での使用は推奨していません**。本番環境には [Linux](/ja/installation/linux) を推奨します。 +Windows 版の RustFS は、開発とデバッグ専用であり、**本番デプロイには推奨しません**。本番ワークロードには [Linux](/ja/installation/linux) を推奨します。 -These procedures run RustFS as a desktop process, not as a Windows service. For a production or distributed deployment, use the [Linux installation guides](/installation/linux). +これらの手順では、RustFS を Windows サービスとしてではなく、デスクトッププロセスとして実行します。本番または分散デプロイには、[Linux のインストールガイド](/ja/installation/linux) を使います。 ::: -## 1. Check the prerequisites +## 1. 前提条件を確認する -Before you begin, make sure that: +始める前に、次を確認します。 -- You are using 64-bit Windows on an x86-64 processor. Launcher currently bundles the Windows x86-64 RustFS binary. -- You have permission to install or run applications and to write to the selected data directory. -- TCP ports `9000` and `9001` are available, or you have selected two other unused ports. -- You have created a dedicated data directory, such as `D:\rustfs\data`. +- 使用しているのは、x86-64 プロセッサー上の 64 ビット Windows です。Launcher は現在、Windows x86-64 の RustFS バイナリを同梱しています。 +- アプリケーションのインストールまたは実行と、選択したデータディレクトリへの書き込みの権限があります。 +- TCP ポート `9000` と `9001` が空いているか、ほかの未使用ポートを 2 つ選んでいます。 +- `D:\rustfs\data` のような専用のデータディレクトリを作成しています。 -:::warning[Protect the data directory] +:::warning[データディレクトリを保護する] -Use an empty directory on a disk with enough free space. Do not store unrelated files in this directory, and do not edit RustFS data files while the server is running. +空き容量が十分なディスク上の空のディレクトリを使います。このディレクトリに無関係なファイルを置かず、サーバーの実行中に RustFS のデータファイルを編集しないでください。 ::: -## 2. Choose an installation method +## 2. インストール方法を選ぶ -| Method | Use it when | Management model | +| 方法 | 使う場面 | 管理モデル | | --- | --- | --- | -| RustFS Launcher | You want a graphical setup and built-in log viewer. | Launcher starts and stops the bundled RustFS process. | -| Standalone binary | You want explicit PowerShell commands or scripting. | The PowerShell session owns the RustFS process. | +| RustFS Launcher | グラフィカルなセットアップと組み込みのログビューアーが必要な場合。 | Launcher が、同梱の RustFS プロセスを起動し、停止します。 | +| スタンドアロンバイナリ | 明示的な PowerShell コマンドやスクリプトが必要な場合。 | RustFS プロセスは、その PowerShell セッションに属します。 | -## Install with RustFS Launcher +## RustFS Launcher でインストールする -### 3. Download and install Launcher +### 3. Launcher をダウンロードしてインストールする -1. Open the [RustFS Launcher Releases page](https://github.com/rustfs/launcher/releases). -2. Select the latest release and download its Windows x86-64 installer from **Assets**. Do not download **Source code**, which is for building Launcher from source. -3. Double-click the installer and follow the prompts. -4. Open **RustFS Launcher** from the Start menu if it does not open automatically. +1. [RustFS Launcher の Releases ページ](https://github.com/rustfs/launcher/releases) を開きます。 +2. 最新のリリースを選び、**Assets**（アセット）から Windows x86-64 のインストーラーをダウンロードします。ソースから Launcher をビルドするための **Source code**（ソースコード）はダウンロードしないでください。 +3. インストーラーをダブルクリックし、画面の指示に従います。 +4. 自動で開かない場合は、スタートメニューから **RustFS Launcher** を開きます。 -If Microsoft Defender SmartScreen displays a warning, verify that the installer came from the official `rustfs/launcher` Releases page before allowing it to run. Do not disable Windows security features globally. +Microsoft Defender SmartScreen が警告を表示した場合は、実行を許可する前に、インストーラーが公式の `rustfs/launcher` Releases ページから入手したものであることを確認します。Windows のセキュリティ機能をシステム全体で無効にしないでください。 -### 4. Configure Launcher +### 4. Launcher を設定する -Configure the fields in the Launcher window: +Launcher ウィンドウの各フィールドを設定します。 -| Section | Field | Recommended value | Description | +| セクション | フィールド | 推奨値 | 説明 | | --- | --- | --- | --- | -| Dataset Mount | Data Path | `D:\rustfs\data` | Existing directory where RustFS stores object data. | -| Ports & Access | API Port | `9000` | S3-compatible API port. | -| Ports & Access | Host | `127.0.0.1` | Restricts access to this computer. | -| Ports & Access | Console Endpoint | Enabled | Enables the web Console; Launcher disables it by default. | -| Ports & Access | Console Port | `9001` | Console port, which must differ from the API port. | -| Credentials | Access Key | `` | Administrator access key for this instance. | -| Credentials | Secret Key | `` | Administrator secret key for this instance. | +| Dataset Mount（データセットのマウント） | Data Path（データパス） | `D:\rustfs\data` | RustFS がオブジェクトデータを保存する、既存のディレクトリ。 | +| Ports & Access（ポートとアクセス） | API Port（API ポート） | `9000` | S3 互換 API のポート。 | +| Ports & Access | Host（ホスト） | `127.0.0.1` | アクセスをこのコンピューターに制限します。 | +| Ports & Access | Console Endpoint（Console エンドポイント） | Enabled（有効） | Web Console を有効にします。Launcher は既定で無効にしています。 | +| Ports & Access | Console Port（Console ポート） | `9001` | Console のポート。API ポートとは異なる必要があります。 | +| Credentials（認証情報） | Access Key（アクセスキー） | `` | このインスタンスの管理者アクセスキー。 | +| Credentials | Secret Key（シークレットキー） | `` | このインスタンスの管理者シークレットキー。 | -Select the data directory with **Browse** or drag it into Launcher. Launcher requires the directory to exist before startup. +**Browse**（参照）でデータディレクトリを選ぶか、Launcher にドラッグします。Launcher は、起動前にディレクトリが存在していることを要求します。 -Replace the credential placeholders with your own values. Launcher initially displays default local-test credentials; do not retain them on a computer accessible by other users. +認証情報のプレースホルダーを独自の値に置き換えます。Launcher は最初、ローカルテスト用の既定の認証情報を表示します。ほかのユーザーがアクセスできるコンピューターでは、その値を残さないでください。 -:::warning[Network exposure] +:::warning[ネットワークへの公開] -Keep **Host** set to `127.0.0.1` unless another computer must connect to RustFS. A non-loopback address exposes the API and Console on the corresponding network interfaces. Configure Windows Defender Firewall and strong credentials before allowing remote access. +別のコンピューターが RustFS に接続する必要がある場合を除き、**Host** は `127.0.0.1` のままにします。ループバック以外のアドレスは、対応するネットワークインターフェース上で API と Console を公開します。リモートアクセスを許可する前に、Windows Defender ファイアウォールと強力な認証情報を設定します。 ::: -### 5. Start and verify RustFS +### 5. RustFS を起動して確認する -1. Select **Launch RustFS**. -2. Wait for Launcher to report that the configured endpoint is online. -3. Open `http://localhost:9001` and sign in with the access key and secret key that you configured. -4. Use `http://localhost:9000` as the endpoint for S3-compatible clients. +1. **Launch RustFS**（RustFS を起動）を選びます。 +2. 設定したエンドポイントがオンラインになったと Launcher が報告するまで待ちます。 +3. `http://localhost:9001` を開き、設定したアクセスキーとシークレットキーでサインインします。 +4. S3 互換クライアントのエンドポイントとして `http://localhost:9000` を使います。 -![RustFS Launcher showing the service online with API port 9000, Console port 9001, and successful startup logs](./images/windows-rustfs-launcher.jpg) +![API ポート 9000、Console ポート 9001、起動成功のログとともに、サービスがオンラインであることを示す RustFS Launcher](./images/windows-rustfs-launcher.jpg) -If you changed the host or ports, use those values instead. The Console URL is available only when **Console Endpoint** is enabled. +ホストまたはポートを変更した場合は、その値を使います。Console の URL は、**Console Endpoint** が有効な場合にのみ使えます。 -Launcher locks its configuration while it manages a running process. It also creates a `logs` directory next to the data directory. For example, a data path of `D:\rustfs\data` places server log files under `D:\rustfs\logs`. +Launcher は、実行中のプロセスを管理している間、設定をロックします。また、データディレクトリの隣に `logs` ディレクトリを作成します。たとえば、データパスが `D:\rustfs\data` の場合、サーバーのログファイルは `D:\rustfs\logs` に置かれます。 -### 6. Stop or exit Launcher +### 6. Launcher を停止または終了する -Select **Stop RustFS** before changing configuration, disconnecting the data disk, or shutting down Windows. +設定を変更する前、データディスクを取り外す前、または Windows をシャットダウンする前に、**Stop RustFS**（RustFS を停止）を選びます。 -Closing the Launcher window hides it in the Windows system tray; it does not stop RustFS. To stop the managed process and exit Launcher, right-click the tray icon and select **Quit**. Select **Show**, or left-click the tray icon, to restore the window. +Launcher ウィンドウを閉じると、Windows のシステムトレイに隠れるだけで、RustFS は停止しません。管理対象のプロセスを停止して Launcher を終了するには、トレイアイコンを右クリックして **Quit**（終了）を選びます。ウィンドウを戻すには、**Show**（表示）を選ぶか、トレイアイコンを左クリックします。 -## Install the standalone binary +## スタンドアロンバイナリをインストールする -### 7. Download and extract the binary +### 7. バイナリをダウンロードして展開する -1. Open the [RustFS Releases page](https://github.com/rustfs/rustfs/releases). -2. Select the required release and download the Windows x86-64 ZIP archive from **Assets**. The asset name begins with `rustfs-windows-x86_64`. -3. Open PowerShell and create directories for the program and its data: +1. [RustFS の Releases ページ](https://github.com/rustfs/rustfs/releases) を開きます。 +2. 必要なリリースを選び、**Assets** から Windows x86-64 の ZIP アーカイブをダウンロードします。アセット名は `rustfs-windows-x86_64` で始まります。 +3. PowerShell を開き、プログラムとデータのディレクトリを作成します。 ```powershell New-Item -ItemType Directory -Force -Path C:\rustfs\bin New-Item -ItemType Directory -Force -Path D:\rustfs\data ``` -4. Extract the downloaded archive. Replace `` with the version in the downloaded filename: +4. ダウンロードしたアーカイブを展開します。`` は、ダウンロードしたファイル名のバージョンに置き換えます。 ```powershell Expand-Archive -Path "$HOME\Downloads\rustfs-windows-x86_64-.zip" -DestinationPath C:\rustfs\bin -Force ``` -5. Confirm that the extracted binary runs: +5. 展開したバイナリが実行できることを確認します。 ```powershell Set-Location C:\rustfs\bin .\rustfs.exe --help ``` -If the archive extracts `rustfs.exe` into a nested directory, change to that directory or move the executable into `C:\rustfs\bin` before continuing. +アーカイブが `rustfs.exe` をネストしたディレクトリに展開した場合は、続ける前にそのディレクトリへ移動するか、実行ファイルを `C:\rustfs\bin` に移動します。 -### 8. Start the standalone server +### 8. スタンドアロンサーバーを起動する -Set credentials only for the current PowerShell session, then start RustFS with explicit addresses: +現在の PowerShell セッションだけに認証情報を設定し、明示的なアドレスで RustFS を起動します。 ```powershell $env:RUSTFS_ACCESS_KEY = "" @@ -133,61 +133,61 @@ Set-Location C:\rustfs\bin "D:\rustfs\data" ``` -Keep the PowerShell window open while RustFS is running. Press `Ctrl+C` in that window to stop the server. +RustFS の実行中は、PowerShell ウィンドウを開いたままにします。そのウィンドウで `Ctrl+C` を押すと、サーバーが停止します。 -:::tip[Credential handling] +:::tip[認証情報の扱い] -Session environment variables avoid placing credentials directly in the command line. For repeated or automated use, prefer the `RUSTFS_ACCESS_KEY_FILE` and `RUSTFS_SECRET_KEY_FILE` environment variables and protect those files with Windows access controls. +セッションの環境変数を使うと、認証情報をコマンドラインに直接置かずに済みます。繰り返し使う場合や自動化する場合は、`RUSTFS_ACCESS_KEY_FILE` と `RUSTFS_SECRET_KEY_FILE` の環境変数を使い、それらのファイルを Windows のアクセス制御で保護することを推奨します。 ::: -### 9. Verify the standalone server +### 9. スタンドアロンサーバーを確認する -Open `http://localhost:9001` and sign in with the configured credentials. Use `http://localhost:9000` as the endpoint for S3-compatible clients. RustFS defaults to path-style addressing, so configure clients accordingly. +`http://localhost:9001` を開き、設定した認証情報でサインインします。S3 互換クライアントのエンドポイントとして `http://localhost:9000` を使います。RustFS は既定でパススタイルアクセスになるため、クライアントもそれに合わせて設定します。 -To perform an end-to-end check, create a bucket named `my-bucket`, upload `hello.txt`, and confirm that the object appears in the bucket. +エンドツーエンドで確認するには、`my-bucket` という名前のバケットを作成し、`hello.txt` をアップロードして、オブジェクトがバケットに表示されることを確認します。 -## Confirm a successful installation +## インストールの成功を確認する -Whether you used Launcher or the standalone binary, a successful Console sign-in opens the **Buckets** page. From here, you can create `my-bucket` and begin storing objects. +Launcher とスタンドアロンバイナリのどちらを使った場合でも、Console へのサインインが成功すると **Buckets**（バケット）ページが開きます。ここから `my-bucket` を作成し、オブジェクトの保存を始められます。 -![RustFS Console Buckets page after a successful sign-in](./images/rustfs-console-login.png) +![サインイン成功後の RustFS Console の Buckets ページ](./images/rustfs-console-login.png) -## Troubleshooting +## トラブルシューティング -### Windows blocks the installer or executable +### Windows がインストーラーまたは実行ファイルをブロックする -Confirm that the file came from the official RustFS GitHub organization. Inspect the file's **Properties** dialog and, when Windows provides the option, select **Unblock** only after verifying the source. +ファイルが公式の RustFS GitHub 組織から入手したものであることを確認します。ファイルの **Properties**（プロパティ）ダイアログを確認し、Windows がその選択肢を出した場合に限り、入手元を確認したうえで **Unblock**（ブロックの解除）を選びます。 -### The data path is rejected +### データパスが拒否される -Confirm that the directory exists and that your Windows account has read and write access. Launcher does not create the selected data directory for you. +ディレクトリが存在し、Windows アカウントに読み取りと書き込みの権限があることを確認します。Launcher は、選択したデータディレクトリを自動では作成しません。 -### The API or Console port is unavailable +### API または Console のポートが使えない -The ports must be numbers from `1` to `65535`, must differ from each other, and must not already be in use. Inspect the default ports in PowerShell: +ポートは、`1` から `65535` の数値であり、互いに異なり、かつ未使用である必要があります。PowerShell で既定のポートを確認します。 ```powershell Get-NetTCPConnection -LocalPort 9000,9001 -ErrorAction SilentlyContinue ``` -Stop the conflicting application or select unused ports, then start RustFS again. +競合しているアプリケーションを停止するか、未使用のポートを選んでから、RustFS を再度起動します。 -### The Console does not open +### Console が開かない -For Launcher, confirm that **Console Endpoint** is enabled. For the standalone binary, confirm that the process is still running and that `--console-enable true` is present. The current Console default is port `9001`; port `7001` is not used by the current Launcher configuration. +Launcher の場合は、**Console Endpoint** が有効であることを確認します。スタンドアロンバイナリの場合は、プロセスがまだ実行中であり、`--console-enable true` があることを確認します。現在の Console の既定ポートは `9001` です。現在の Launcher の設定では、ポート `7001` は使いません。 -### Launcher reports an external RustFS process +### Launcher が外部の RustFS プロセスを報告する -Another process is listening on the configured API address, but Launcher did not start it. Stop that process or choose another API port. Launcher cannot stop a process it does not manage. +別のプロセスが、設定した API アドレスで待ち受けていますが、Launcher はそのプロセスを起動していません。そのプロセスを停止するか、別の API ポートを選びます。Launcher は、自身が管理していないプロセスを停止できません。 -### RustFS exits after launch +### 起動後に RustFS が終了する -In Launcher, inspect both the application and RustFS tabs in the built-in log viewer. For a standalone installation, inspect the PowerShell output. Common causes include a missing data directory, insufficient permissions, or a port conflict. +Launcher では、組み込みログビューアーのアプリケーションタブと RustFS タブの両方を確認します。スタンドアロンインストールでは、PowerShell の出力を確認します。よくある原因は、データディレクトリがないこと、権限が不足していること、ポートの競合です。 -## Next steps +## 次のステップ -- Review the [S3 API guide](/administration/protocols/s3) before connecting a client. -- Learn how to [create a bucket](/administration/data/bucket/creation). -- See [status checks](/operations/status-check) for additional verification methods. -- Use the [Linux installation guides](/installation/linux) for a production-oriented deployment. +- クライアントを接続する前に、[S3 API ガイド](/ja/administration/protocols/s3) を確認します。 +- [バケットを作成する](/ja/administration/data/bucket/creation) 方法を確認します。 +- 追加の確認方法は、[ステータスチェック](/ja/operations/status-check) を参照します。 +- 本番向けのデプロイには、[Linux のインストールガイド](/ja/installation/linux) を使います。 diff --git a/content/ja/integration/tls-configured.md b/content/ja/integration/tls-configured.md index 862913e1d..27306a5cf 100644 --- a/content/ja/integration/tls-configured.md +++ b/content/ja/integration/tls-configured.md @@ -1,22 +1,22 @@ --- -title: "TLS Configuration" -description: "Configure TLS for secure access." +title: "TLS の設定" +description: "Linux と Docker で、RustFS の S3 API と Console に TLS を有効にします。" --- -Configure TLS for secure access. Set the `RUSTFS_TLS_PATH` environment variable. +安全にアクセスできるよう TLS を設定します。環境変数 `RUSTFS_TLS_PATH` を設定します。 -## Configuration +## 設定 -### Prerequisites +### 前提条件 -- A running RustFS instance (see [Installation Guide](../installation/index.md)). -- Certificate pair (cert and key). +- 稼働している RustFS インスタンス（[インストールガイド](../installation/index.md) を参照）。 +- TLS 証明書と、対になる秘密鍵。 -**Note**: Certificates must be named `rustfs_cert.pem` and `rustfs_key.pem` and placed in the specified path. +**注意**: 証明書のファイル名は `rustfs_cert.pem` と `rustfs_key.pem` である必要があり、指定したパスに配置します。 ### Linux -1. Edit the RustFS instance configuration file (default `/etc/default/rustfs`) and add the `RUSTFS_TLS_PATH` environment variable. +1. RustFS インスタンスの設定ファイル（既定は `/etc/default/rustfs`）を編集し、環境変数 `RUSTFS_TLS_PATH` を追加します。 ```bash # Edit RustFS instance configuration file @@ -26,19 +26,19 @@ Configure TLS for secure access. Set the `RUSTFS_TLS_PATH` environment variable. RUSTFS_TLS_PATH="/opt/tls" ``` -**Note**: You can specify any path for `RUSTFS_TLS_PATH`, but it must contain both `rustfs_cert.pem` and `rustfs_key.pem`. +**注意**: `RUSTFS_TLS_PATH` には任意のパスを指定できますが、`rustfs_cert.pem` と `rustfs_key.pem` の両方が含まれている必要があります。 -2. Restart the RustFS instance. +2. RustFS インスタンスを再起動します。 ```bash systemctl restart rustfs ``` -TLS now applies to both listeners: the S3 API at `https://rustfs.example.com:9000` and the Console at `https://rustfs.example.com:9001`. +これで TLS は両方のリスナーに適用されます。S3 API は `https://rustfs.example.com:9000` 、Console は `https://rustfs.example.com:9001` です。 ### Docker -1. Mount the certificate path via `-v` and specify `RUSTFS_TLS_PATH` via `-e`. +1. `-v` で証明書のパスをマウントし、`-e` で `RUSTFS_TLS_PATH` を指定します。 ```bash docker pull rustfs/rustfs:latest @@ -52,6 +52,10 @@ TLS now applies to both listeners: the S3 API at `https://rustfs.example.com:900 rustfs/rustfs:latest ``` -2. Restart the RustFS instance container, then access the S3 API at `https://rustfs.example.com:9000` and the Console at `https://rustfs.example.com:9001`. +2. RustFS インスタンスのコンテナを再起動したあと、S3 API は `https://rustfs.example.com:9000` 、Console は `https://rustfs.example.com:9001` でアクセスします。 -**Note**: Since the RustFS instance container runs as `rustfs` user by default, you need to ensure that the certificate files (`rustfs_key.pem` and `rustfs_cert.pem`) belong to the `rustfs` user, otherwise the RustFS instance will fail to read the certificate files due to permission issues, causing TLS configuration to fail. +:::note[証明書ファイルの所有者] + +RustFS コンテナは既定でユーザー `rustfs`（UID `10001`）として動作します。`rustfs_key.pem` と `rustfs_cert.pem` の所有者がこのユーザーであることを確認します。所有者でない場合、RustFS は証明書を読み取れず、TLS は起動に失敗します。 + +::: diff --git a/content/ja/integration/virtual.md b/content/ja/integration/virtual.md index 02a9ac4d5..8e74f2ffe 100644 --- a/content/ja/integration/virtual.md +++ b/content/ja/integration/virtual.md @@ -1,61 +1,64 @@ --- -title: "Virtual Host Style" -description: "RustFS S3 Virtual Host Style and Path Style configuration." +title: "仮想ホスト形式" +description: "RustFS でパススタイルアクセスと仮想ホスト形式の S3 URL を設定します。" --- -RustFS complies with S3 protocols. S3 supports two request modes: +RustFS は、次の 2 つの S3 URL 形式に対応しています。 -1. Virtual Host Style -2. Path Style +1. 仮想ホスト形式 +2. パススタイルアクセス -The difference lies in the bucket name placement. +2 つの形式は、URL のどこにバケット名が現れるかが異なります。 -## Path Style +## パススタイルアクセス -Path Style is the default. In Path Style, the bucket name follows the endpoint. +パススタイルアクセスが既定です。パススタイルの URL では、バケット名がエンドポイントの後ろに続きます。 -Example (Bucket: `test`, Host: `rustfs.yourdomain.com`): +例（バケット: `test`、ホスト: `rustfs.yourdomain.com`）: ```text http://rustfs.yourdomain.com/test ``` -**Note**: No configuration is required for Path Style. +**注意**: パススタイルアクセスに設定は不要です。 -## Virtual Host Style +## 仮想ホスト形式 -In Virtual Host Style, the bucket name is part of the domain. +仮想ホスト形式では、バケット名がドメインの一部になります。 -Example (Bucket: `test`, Host: `rustfs.yourdomain.com`): +例（バケット: `test`、ホスト: `rustfs.yourdomain.com`）: ```text http://test.rustfs.yourdomain.com/ ``` -### Configuration +### 設定 -1. **DNS**: Configure wildcard DNS resolution (e.g., `*.rustfs.yourdomain.com` -> Server IP). -2. **Configuration**: Modify the configuration file (Linux: `/etc/default/rustfs`, Docker/K8s: env vars). -3. **Set Domain**: Set `RUSTFS_SERVER_DOMAINS = "rustfs.yourdomain.com"`. -4. **Restart**: Restart the service (`systemctl restart rustfs`). +1. **DNS**: ワイルドカード DNS レコードを作成します（例: `*.rustfs.yourdomain.com` → サーバーの IP アドレス）。 +2. **設定**: 設定ファイルを変更します（Linux: `/etc/default/rustfs`、Docker / Kubernetes: 環境変数）。 +3. **ドメインの設定**: `RUSTFS_SERVER_DOMAINS = "rustfs.yourdomain.com"` を設定します。 +4. **再起動**: サービスを再起動します（`systemctl restart rustfs`）。 -### Port in Domain (Optional) +### ドメイン内のポート（任意） -Virtual-host routing applies to the S3 API listener (port 9000 by default); RustFS automatically matches `Host` headers that carry the S3 listener's own port. Only when clients reach RustFS through a **different** port (for example via a proxy) do you need to include that port in `RUSTFS_SERVER_DOMAINS`. +仮想ホストのルーティングは S3 API リスナー（既定のポートは 9000）に適用されます。RustFS は、S3 リスナー自身のポートを含む `Host` ヘッダーを自動的に照合します。クライアントが **別の** ポート経由で RustFS に到達する場合（プロキシ経由など）に限り、そのポートを `RUSTFS_SERVER_DOMAINS` に含める必要があります。 -Example (`rustfs.yourdomain.com:8000`): +例（`rustfs.yourdomain.com:8000`）: ```ini RUSTFS_SERVER_DOMAINS = "rustfs.yourdomain.com:8000" ``` -This ensures that requests like: +これにより、次のようなリクエストが、 ```text http://my-bucket.rustfs.yourdomain.com:8000/ ``` -can be correctly resolved in Virtual Host Style mode. +仮想ホスト形式で正しくルーティングされます。 -> ⚠️ Note: The value of `RUSTFS_SERVER_DOMAINS` must exactly match the **Host header** (including the port, if present) used by the client request +:::warning[Host ヘッダーとの一致] +`RUSTFS_SERVER_DOMAINS` の値は、クライアントが送信する `Host` ヘッダー（ポートが含まれる場合はそのポートも含む）と完全に一致する必要があります。 + +::: diff --git a/content/ja/operations/cluster-lifecycle.md b/content/ja/operations/cluster-lifecycle.md index 33a8535c6..c83d232aa 100644 --- a/content/ja/operations/cluster-lifecycle.md +++ b/content/ja/operations/cluster-lifecycle.md @@ -1,40 +1,40 @@ --- -title: "Cluster Lifecycle Operations" -description: "Plan, start, expand, rebalance, decommission, heal, and restart erasure-coded RustFS clusters with verified quorum and storage-class behavior." +title: "クラスターのライフサイクル運用" +description: "検証済みのクォーラムとストレージクラスの動作に基づき、イレイジャーコーディングを使う RustFS クラスターの計画、起動、拡張、リバランス、デコミッション、データ修復、再起動を行います。" --- -This runbook is the operator entry point for erasure-coded RustFS deployments: layout boundaries, storage classes and quorum, zero-parity mode, expansion, rebalancing, decommissioning, healing, drive replacement, and restarts. Every behavior described here was verified against the RustFS source; the upstream runbook in [rustfs/rustfs#7998](https://github.com/rustfs/rustfs/pull/7998) is the change that introduced it. +このランブックは、イレイジャーコーディングを使う RustFS デプロイを運用するときの入口です。レイアウトの境界、ストレージクラスとクォーラム、ゼロパリティ、拡張、リバランス、デコミッション、データ修復、ドライブ交換、再起動を扱います。ここに書いた動作は、いずれも RustFS のソースコードに照らして検証済みです。上流のランブックは [rustfs/rustfs#7998](https://github.com/rustfs/rustfs/pull/7998) で導入されました。 -Related task pages: [Storage Pool Expansion](./scaling/storage-pool-expansion.md), [Data Rebalancing](./scaling/data-rebalancing.md), [Storage Pool Decommission](./scaling/storage-pool-decommission.md), and [Node Healing](./high-availability/node-healing.md). +関連する手順: [ストレージプールの拡張](./scaling/storage-pool-expansion.md)、[データリバランス](./scaling/data-rebalancing.md)、[ストレージプールのデコミッション](./scaling/storage-pool-decommission.md)、[ノードのデータ修復](./high-availability/node-healing.md)。 -## Layout boundaries +## レイアウトの制約 -A pool's endpoint count, set count, drives per set, and position in the pool list are persisted layout. On startup RustFS compares the stored format with the configured drive count and set width and fails permanently with `PoolTopologyMismatch` (or `UnsupportedSnsdExpansion` for a single-drive deployment) instead of migrating. Restore the original endpoints and set width; do not delete `format.json` to get past the error. +ストレージプールのエンドポイント数、セット数、セットあたりのドライブ数、プール一覧での位置は、永続化されたレイアウトです。起動時に RustFS は、保存済みのフォーマットと、設定されたドライブ数およびセット幅を比較します。移行は行わず、`PoolTopologyMismatch`（シングルドライブのデプロイでは `UnsupportedSnsdExpansion`）で恒久的に失敗します。元のエンドポイントとセット幅を戻します。エラーを回避するために `format.json` を削除しないでください。 -:::warning[Never do these] +:::warning[行ってはいけない操作] -- Overwrite an existing pool with more or fewer endpoints, or change `RUSTFS_ERASURE_SET_DRIVE_COUNT` for an initialized pool. -- Reorder volume arguments or move a drive directory to another slot. -- Delete, copy, or rename object shards, `xl.meta`, or anything under `.rustfs.sys` by hand. -- Treat a manual file copy as data movement. Only rebalance and decommission move objects, under object locks with version re-checks and source cleanup. +- 既存のプールを、エンドポイント数を増減した構成で上書きしないでください。初期化済みプールの `RUSTFS_ERASURE_SET_DRIVE_COUNT` を変更しないでください。 +- ボリューム引数の順序を入れ替えたり、ドライブのディレクトリを別のスロットへ移したりしないでください。 +- オブジェクトのシャード、`xl.meta`、`.rustfs.sys` 以下の内容を、手作業で削除、コピー、名前変更しないでください。 +- 手作業のファイルコピーをデータ移動と見なさないでください。オブジェクトを移動するのはリバランスとデコミッションだけです。オブジェクトロックのもとで、バージョンの再確認とソース側のクリーンアップを行います。 ::: -Runtime roles: +実行時の役割は次のとおりです。 -- **Pool** — one endpoint list with persisted layout. Multi-drive sets contain 2 to 16 drives; a single local path is the only single-drive layout. -- **Pool leader** — the first endpoint of a pool. Decommission start, cancel, and clear may be sent to any node; requests are forwarded to the pool leader over authenticated internode RPC. -- **Cluster-wide state** — rebalance and root heal propagate to peers and recover from persisted metadata on restart. +- **プール** — 永続化されたレイアウトを持つ、1 つのエンドポイント一覧です。マルチドライブのセットは 2〜16 台のドライブで構成されます。シングルドライブのレイアウトは、ローカルパスが 1 つだけの場合に限ります。 +- **プールリーダー** — プールの先頭エンドポイントです。デコミッションの開始、キャンセル、クリアは任意のノードへ送れます。リクエストは、認証済みのノード間 RPC でプールリーダーへ転送されます。 +- **クラスター全体の状態** — リバランスとルート heal はピアへ伝播し、再起動時には永続化されたメタデータから復旧します。 -## Plan and first start +## 計画と初回起動 -1. Plan endpoints by node, rack, power, and network failure domain. Topology admission is not a high-availability guarantee: a single-node pool loses every shard with its host, and startup logs a `host_failure_data_unavailable` warning for every multi-drive pool. -2. Pick each pool's set width. Pools may differ in width, but each pool must split evenly into sets of one width from 2 to 16 drives; `RUSTFS_ERASURE_SET_DRIVE_COUNT` may pin a width that is already a valid divisor, nothing else. -3. Pick STANDARD and RRS parity per the rules in [Storage classes](#storage-classes-parity-and-quorum), then validate against the narrowest pool, because an explicit parity must fit every pool. -4. Record the full launch command, endpoint order, pool order, set width, and storage-class variables. They must be identical on every node and on every restart. -5. Give RustFS exclusive ownership of every endpoint path. +1. ノード、ラック、電源、ネットワークの障害ドメインを考慮してエンドポイントを計画します。トポロジが受理されることは、高可用性の保証にはなりません。シングルノードのプールでは、ホストを失うとそのシャードもすべて失われます。起動時には、マルチドライブのプールごとに `host_failure_data_unavailable` の警告が記録されます。 +2. 各プールのセット幅を選びます。プールごとに幅が異なってもかまいません。ただし各プールは、幅が 2〜16 台のいずれか 1 つであるセットへ、均等に分割できる必要があります。`RUSTFS_ERASURE_SET_DRIVE_COUNT` で固定できるのは、すでに有効な約数になっている幅だけです。 +3. [ストレージクラス](#storage-classes-parity-and-quorum)の規則に従って STANDARD と RRS のパリティを選び、最も狭いプールに対して検証します。明示したパリティは、すべてのプールに収まる必要があります。 +4. 起動コマンド一式、エンドポイントの順序、プールの順序、セット幅、ストレージクラスの変数を記録します。これらは、すべてのノードで、再起動のたびに同一である必要があります。 +5. すべてのエンドポイントパスは、RustFS だけが使うようにします。 -Volumes come from positional arguments or `RUSTFS_VOLUMES`; `rustfs` with no arguments behaves as `rustfs server` with volumes from the environment. Ellipsis expansion follows the MinIO pattern: +ボリュームは、位置引数または `RUSTFS_VOLUMES` から取ります。引数なしの `rustfs` は、環境変数のボリュームを使った `rustfs server` と同じ動作になります。省略記号の展開は MinIO の方式に従います。 ```bash # one pool, four nodes, four drives each: sixteen endpoints @@ -44,35 +44,35 @@ rustfs server http://node{1...4}:9000/data{1...4} rustfs server http://node{1...4}:9000/data{1...4} http://node{5...8}:9000/data{1...4} ``` -With more than one argument, every argument needs an ellipsis; each pool must expand to at least two distinct drive endpoints; a single-drive pool cannot join a multi-pool deployment; a singleton range such as `{3...3}` does not bypass the minimum. +引数が 2 つ以上ある場合、すべての引数に省略記号が必要です。各プールは、互いに異なるドライブエンドポイントを少なくとも 2 つへ展開できる必要があります。シングルドライブのプールは、マルチプールのデプロイに参加できません。`{3...3}` のような単一値の範囲では、この最小数を回避できません。 -A storage-class error stops startup before any disk is touched. Startup then initializes local disks, the lock clients, and the format quorum in that order. +ストレージクラスのエラーがあると、どのディスクにも書き込まずに起動が止まります。その後、起動処理はローカルディスク、ロッククライアント、フォーマットクォーラムの順に初期化します。 -## Startup configuration +## 起動時の設定 -| Variable | Effect | Boundary | +| 変数 | 効果 | 制約 | |---|---|---| -| `RUSTFS_ERASURE_SET_DRIVE_COUNT` | Pin the set width | Must be a valid symmetric divisor of the pool, at most 16; cannot change an initialized pool | -| `RUSTFS_STORAGE_CLASS_STANDARD` | STANDARD parity as `EC:` | Validated per pool; affects new writes only | -| `RUSTFS_STORAGE_CLASS_RRS` | RRS parity as `EC:` | Validated per pool; an explicit value fails on a single drive, the persisted default `EC:1` resolves to `0` there | -| `RUSTFS_STORAGE_CLASS_OPTIMIZE` | Accepted for MinIO compatibility | Stored but currently unused: it changes nothing at runtime | -| `RUSTFS_STORAGE_CLASS_INLINE_BLOCK` | Fixed per-shard inline limit (bytesize syntax such as `128KiB`) | Replaces the scaled default in [Inline objects](#inline-objects); values above 128 KiB log a warning | +| `RUSTFS_ERASURE_SET_DRIVE_COUNT` | セット幅を固定する | プールの有効な対称約数であり、最大 16 である必要があります。初期化済みのプールは変更できません | +| `RUSTFS_STORAGE_CLASS_STANDARD` | STANDARD のパリティを `EC:` で指定する | プールごとに検証されます。影響するのは新規の書き込みだけです | +| `RUSTFS_STORAGE_CLASS_RRS` | RRS のパリティを `EC:` で指定する | プールごとに検証されます。明示した値はシングルドライブでは失敗します。永続化されている既定の `EC:1` は、シングルドライブでは `0` に解決されます | +| `RUSTFS_STORAGE_CLASS_OPTIMIZE` | MinIO 互換のため受け付ける | 保存されますが、現時点では使われません。実行時の動作は変わりません | +| `RUSTFS_STORAGE_CLASS_INLINE_BLOCK` | シャードあたりのインライン上限を固定する（`128KiB` のようなバイトサイズ構文） | [インラインオブジェクト](#inline-objects)で比例して決まる既定値を置き換えます。128 KiB を超える値は警告を記録します | -An empty `RUSTFS_STORAGE_CLASS_STANDARD` or `RUSTFS_STORAGE_CLASS_RRS` restores the automatic policy and overrides a persisted value. `MINIO_`-prefixed spellings of these keys, of `ERASURE_SET_DRIVE_COUNT`, and of `VOLUMES` are mapped onto the `RUSTFS_` names when the `RUSTFS_` name is unset; when both are set the `RUSTFS_` value wins and the conflict is reported at startup. +`RUSTFS_STORAGE_CLASS_STANDARD` または `RUSTFS_STORAGE_CLASS_RRS` が空の場合は、自動ポリシーが復元され、永続化されている値は上書きされます。これらのキー、`ERASURE_SET_DRIVE_COUNT`、`VOLUMES` について、`MINIO_` 接頭辞の表記は、対応する `RUSTFS_` 名が未設定のときに `RUSTFS_` 名へ対応付けられます。両方とも設定されている場合は `RUSTFS_` の値が優先され、起動時に競合が報告されます。 -Other data-movement and listing knobs: `RUSTFS_REBALANCE_MAX_ATTEMPTS` (default 3), `RUSTFS_DECOMMISSION_BUCKET_CONCURRENCY` (default cap 4), `RUSTFS_DECOMMISSION_ENTRY_CONCURRENCY` (default cap 8, hard cap 64), and `RUSTFS_LIST_OBJECTS_QUORUM` (default `optimal`; accepts `disk`, `reduced`, `optimal`, `auto`, anything else means `strict`). None of them relaxes object quorum, object locks, or version checks. +データ移動と一覧取得に関するその他の調整項目は、`RUSTFS_REBALANCE_MAX_ATTEMPTS`（既定 3）、`RUSTFS_DECOMMISSION_BUCKET_CONCURRENCY`（既定の上限 4）、`RUSTFS_DECOMMISSION_ENTRY_CONCURRENCY`（既定の上限 8、ハード上限 64）、`RUSTFS_LIST_OBJECTS_QUORUM`（既定は `optimal`。受け付ける値は `disk`、`reduced`、`optimal`、`auto` で、それ以外は `strict`）です。いずれも、オブジェクトのクォーラム、オブジェクトロック、バージョン検査を緩めません。 -## Storage classes, parity, and quorum +## ストレージクラス、パリティ、クォーラム [#storage-classes-parity-and-quorum] -### Geometry +### 幾何構成 -Each object is Reed-Solomon coded across the `N` drives of one set into `K` data and `M` parity shards, `N = K + M`; any `K` shards rebuild it. The geometry is stored per object in `xl.meta`, so changing the default later rewrites nothing. Objects hash to a set and shards rotate within it; sets never share a failure budget. +各オブジェクトは、1 セットの `N` 台のドライブに対してリード・ソロモン符号化され、`K` 個のデータシャードと `M` 個のパリティシャードになります。`N = K + M` です。任意の `K` 個のシャードから再構築できます。この幾何構成はオブジェクトごとに `xl.meta` へ保存されるため、後から既定値を変えても既存オブジェクトは書き換わりません。オブジェクトはハッシュでセットへ割り当てられ、シャードはそのセット内でローテーションします。セットごとの障害許容は独立しており、ほかのセットとは共有しません。 -Default STANDARD parity by set width: 0 for one drive, 1 for 2 to 3, 2 for 4 to 5, 3 for 6 to 7, 4 for 8 to 16. Default RRS parity is 1 (0 on a single drive). +セット幅ごとの STANDARD パリティの既定値は、ドライブ 1 台で 0、2〜3 台で 1、4〜5 台で 2、6〜7 台で 3、8〜16 台で 4 です。RRS パリティの既定値は 1 です（シングルドライブでは 0）。 -Validation rules: each parity is at most `N/2` for every pool, and STANDARD parity is at least RRS parity only when both are non-zero. There is no minimum, so `EC:0` passes on any width. Only `STANDARD` and `REDUCED_REDUNDANCY` are accepted on PUT, CopyObject, and CreateMultipartUpload; other AWS storage classes return `InvalidStorageClass`. +検証規則では、各パリティはすべてのプールで最大 `N/2` です。STANDARD のパリティが RRS のパリティ以上である必要があるのは、両方が 0 以外の場合だけです。下限はないため、`EC:0` はどの幅でも通ります。PUT、CopyObject、CreateMultipartUpload で受け付けるのは `STANDARD` と `REDUCED_REDUNDANCY` だけです。その他の AWS ストレージクラスは `InvalidStorageClass` を返します。 -### Quorum and capacity +### クォーラムと容量 ```text usable capacity ≈ raw × K / N @@ -81,38 +81,38 @@ write quorum = K, or K + 1 when K == M delete markers = N/2 + 1 (majority, both write and vote) ``` -Sixteen drives at `EC:4`: `K = 12`, about 75 percent usable, four failures tolerated, twelve valid shards needed to read. Two drives at `EC:1`: `K = M = 1`, so one drive down still reads but no longer writes. Internal metadata under `.rustfs.sys` is always written with parity `N/2`, regardless of the configured class. +ドライブ 16 台で `EC:4` の場合、`K = 12`、使用可能容量は約 75%、4 台の障害まで許容し、読み取りには有効なシャードが 12 個必要です。ドライブ 2 台で `EC:1` の場合、`K = M = 1` なので、1 台が停止しても読み取りはできますが、書き込みはできなくなります。`.rustfs.sys` 以下の内部メタデータは、設定されたクラスに関係なく、常にパリティ `N/2` で書き込まれます。 -### Inline objects +### インラインオブジェクト [#inline-objects] -An object is stored inline in `xl.meta` when every shard is at most the per-shard budget. The default budget is `256 KiB / K` capped at 128 KiB per shard, so a wider set does not raise the maximum inline object size; on a versioned bucket the budget is divided by 8. `RUSTFS_STORAGE_CLASS_INLINE_BLOCK` replaces the scaled default with a fixed per-shard limit. Each drive keeps only its own shard inline, so inline data has the same loss semantics as external shards. Compressed or encrypted streams inline only when the stored size is known and within budget. +すべてのシャードがシャードあたりの上限以下である場合、オブジェクトは `xl.meta` にインラインで保存されます。既定の上限は `256 KiB / K` で、シャードあたり 128 KiB が頭打ちです。そのため、セットが広くなってもインラインオブジェクトの最大サイズは上がりません。バージョニングが有効なバケットでは、上限は 8 で割られます。`RUSTFS_STORAGE_CLASS_INLINE_BLOCK` は、比例して決まる既定値を、シャードあたりの固定上限に置き換えます。各ドライブがインラインで保持するのは自ドライブのシャードだけなので、インラインデータの喪失条件は外部シャードと同じです。圧縮または暗号化されたストリームがインラインになるのは、保存サイズが既知で、かつ上限以内の場合だけです。 -### Write and read paths +### 書き込みと読み取りの経路 -Writes resolve the layout per pool, encode with Reed-Solomon in 1 MiB blocks, write bitrot-protected shards, and commit only after write quorum. A write below quorum is never reported as success. Reads pick the authoritative metadata at read quorum, verify bitrot, decode from at least `K` shards, and fail closed below that; a read that succeeds with missing shards enqueues read-repair. Multipart parts use the object's geometry and write quorum; `CompleteMultipartUpload` re-checks metadata and commit quorum, so an uploaded part is not a committed object. +書き込みはプールごとにレイアウトを解決し、1 MiB ブロックでリード・ソロモン符号化し、ビットロット保護されたシャードを書き、書き込みクォーラムに達してからコミットします。クォーラム未満の書き込みが成功として報告されることはありません。読み取りは、読み取りクォーラムで正規のメタデータを選び、ビットロットを検証し、少なくとも `K` 個のシャードから復号します。それより少ない場合は失敗として扱います（フェイルクローズ）。欠落シャードがあっても読み取りが成功した場合は、read-repair がキューに入ります。マルチパートのパートは、オブジェクトの幾何構成と書き込みクォーラムを使います。`CompleteMultipartUpload` はメタデータとコミットクォーラムを再確認するため、アップロード済みのパートはコミット済みのオブジェクトではありません。 -## Zero parity (EC:0) +## ゼロパリティ（EC:0） -`EC:0` is accepted for STANDARD, for RRS, or for both, on any set width. It gives raw capacity and no redundancy. +`EC:0` は、任意のセット幅で、STANDARD、RRS、またはその両方に指定できます。得られるのは物理容量だけで、冗長性はありません。 -:::danger[EC:0 means one drive loss equals set loss] +:::danger[EC:0 ではドライブ 1 台の喪失でセット全体のデータが失われる] -A replaced or wiped drive permanently loses every zero-parity object that had a shard on it, unless a copy exists outside the set. Healing cannot rebuild zero-parity objects: heal reports `no-parity object is unrecoverable` for them. Production deployments should use `EC:1` or higher; `EC:2` or more per set is the usual floor once a set spans more than one node. Use `EC:0` only where an external layer (RAID, replication, backup, or a re-creatable source) owns durability and availability, and only with explicit sign-off. +交換または消去されたドライブは、そのドライブにシャードがあったゼロパリティのオブジェクトをすべて、恒久的に失います。セットの外にコピーがある場合を除きます。データ修復ではゼロパリティのオブジェクトを再構築できません。heal は、そのオブジェクトについて `no-parity object is unrecoverable` を報告します。本番デプロイでは `EC:1` 以上を使うことを推奨します。セットが複数のノードにまたがる場合、セットあたり `EC:2` 以上が通常の下限です。`EC:0` を使うのは、外部の層（RAID、レプリケーション、バックアップ、または再作成できるソース）が耐久性と可用性を担う場合に限り、明示的な承認があるときに限ってください。 ::: -Behavior details: +動作の詳細は次のとおりです。 -- **Configuration.** Explicit `EC:0` produces no startup warning — the zero-redundancy warning fires only for automatic zero parity, meaning a single-drive pool. `STANDARD=EC:2` with `RRS=EC:0` is valid because the ordering rule is skipped when either side is zero; only objects written with `x-amz-storage-class: REDUCED_REDUNDANCY` then carry zero-parity semantics. -- **Writes.** Write quorum is `N`: if any drive of the set is unwritable, the write fails with `ErasureWriteQuorum` and nothing is committed. Because a zero-parity shard cannot be rebuilt later, the write path verifies every shard it just wrote against its bitrot hash before commit and refuses to commit a shard that already fails. -- **Reads.** Read quorum is `N`. With any drive of the set offline, HEAD and GET of every zero-parity object in that set fail with `ErasureReadQuorum`. There is no degraded read. -- **Deletes.** Delete markers and version deletes use majority quorum (`N/2 + 1`), so a delete can succeed on a set whose reads and writes are failing. A successful delete is not evidence that the set is healthy. -- **What still works with one drive down.** Bucket operations, `.rustfs.sys` metadata, delete markers, and listings that satisfy the list quorum. Everything else in the set is unavailable, including rebalance and decommission of its objects, which must read all `N` shards. -- **Raising parity later rewrites nothing.** Re-upload or server-side copy each object after the change to re-protect it. +- **設定。** 明示的な `EC:0` では、起動時の警告は出ません。ゼロ冗長の警告が出るのは、自動的にゼロパリティになる場合、つまりシングルドライブのプールだけです。`STANDARD=EC:2` かつ `RRS=EC:0` は有効です。いずれか一方がゼロのときは、大小関係の規則は適用されません。このときゼロパリティの意味を持つのは、`x-amz-storage-class: REDUCED_REDUNDANCY` で書き込まれたオブジェクトだけです。 +- **書き込み。** 書き込みクォーラムは `N` です。セット内のいずれかのドライブに書き込めない場合、書き込みは `ErasureWriteQuorum` で失敗し、何もコミットされません。ゼロパリティのシャードは後から再構築できないため、書き込み経路はコミット前に、書き込んだすべてのシャードをビットロットハッシュと照合し、すでに不一致のシャードはコミットしません。 +- **読み取り。** 読み取りクォーラムは `N` です。セット内のいずれかのドライブがオフラインだと、そのセット内のすべてのゼロパリティオブジェクトに対する HEAD と GET は `ErasureReadQuorum` で失敗します。縮退読み取りはありません。 +- **削除。** 削除マーカーとバージョン削除は過半数クォーラム（`N/2 + 1`）を使います。そのため、読み取りと書き込みが失敗しているセットでも削除は成功できます。削除が成功しても、セットが正常である証拠にはなりません。 +- **ドライブが 1 台停止していても動作するもの。** バケット操作、`.rustfs.sys` のメタデータ、削除マーカー、一覧取得クォーラムを満たす一覧取得です。セット内のそれ以外は利用できません。対象オブジェクトのリバランスとデコミッションも含まれ、これらは `N` 個すべてのシャードを読む必要があります。 +- **後からパリティを上げても、既存のオブジェクトは書き換わりません。** 変更後に各オブジェクトを再アップロードするか、サーバー側でコピーして、保護し直します。 -## Post-start verification +## 起動後の検証 -Read-only admin checks: +読み取り専用の管理確認は次のとおりです。 ```text GET /rustfs/admin/v3/pools/list @@ -122,27 +122,27 @@ GET /rustfs/admin/v4/cluster/snapshot GET /rustfs/admin/v4/runtime/capabilities ``` -`pool` is a pool command line, or a zero-based index with `by-id=true`. Status queries ignore unknown parameters; mutation queries reject unknown or duplicate parameters and a `by-id` value other than `true` or `false`. +`pool` はプールのコマンドライン、または `by-id=true` を付けた 0 始まりのインデックスです。状態の照会は、未知のパラメーターを無視します。変更系のリクエストは、未知または重複したパラメーターと、`true` および `false` 以外の `by-id` 値を拒否します。 -Confirm: pool count, endpoints per pool, set count and width per pool, local versus remote endpoints, and no topology mismatch. +確認する項目は、プール数、プールごとのエンドポイント、プールごとのセット数と幅、ローカルとリモートのエンドポイント、トポロジの不一致がないことです。 -Data-plane checks: write one STANDARD and one RRS object; GET, HEAD, range GET, CopyObject, and a multipart upload; take one drive or node offline within parity and confirm reads continue and writes behave per the quorum table; bring it back and confirm the heal queue drains and bitrot errors stop; confirm every node reports the same pool metadata and cluster snapshot. +データプレーンの確認では、STANDARD と RRS のオブジェクトを 1 つずつ書き込みます。GET、HEAD、範囲指定の GET、CopyObject、マルチパートアップロードを実行します。パリティの範囲内でドライブまたはノードを 1 つオフラインにし、読み取りが継続し、書き込みがクォーラム表どおりに動作することを確認します。復帰させたあと、heal キューが空になり、ビットロットのエラーが止まることを確認します。すべてのノードが同じプールメタデータとクラスタースナップショットを報告することを確認します。 -## Expansion +## 拡張 -An existing pool cannot grow in place. Add a pool: +既存のプールを、その場で拡張することはできません。プールを追加します。 -1. Plan its nodes, drives, and failure domain; each new pool needs at least two drive endpoints and its own valid set layout. -2. Prepare empty, RustFS-exclusive paths on every node. -3. Append the pool to the launch arguments on **every** node, keeping existing pools, their order, endpoints, and set width unchanged. A single-node single-drive deployment cannot expand; migrate through S3 instead. -4. Restart and verify per the checks above. -5. New writes are placed across available pools; old objects stay where they are. To move them, start a rebalance. A restart never rebalances. +1. ノード、ドライブ、障害ドメインを計画します。新しいプールには、少なくとも 2 つのドライブエンドポイントと、それ自身の有効なセットレイアウトが必要です。 +2. すべてのノードで、空であり、RustFS だけが使うパスを準備します。 +3. **すべての**ノードの起動引数へプールを追加します。既存のプール、その順序、エンドポイント、セット幅は変えません。シングルノード・シングルドライブのデプロイは拡張できません。移行は S3 経由で行います。 +4. 再起動し、上記の確認項目に従って検証します。 +5. 新しい書き込みは、利用可能なプールへ配置されます。既存のオブジェクトはそのままです。移動するにはリバランスを開始します。再起動してもリバランスは実行されません。 -Adding a pool does not add parity to existing objects and does not copy anything. Cross-pool movement is rebalance or decommission only. See [Storage Pool Expansion](./scaling/storage-pool-expansion.md) for a worked example. +プールを追加しても、既存オブジェクトのパリティは増えず、何もコピーされません。プールをまたいでオブジェクトを移動するのは、リバランスとデコミッションだけです。具体例は [ストレージプールの拡張](./scaling/storage-pool-expansion.md) を参照してください。 -## Rebalance +## リバランス -Rebalance redistributes objects across pools by usage. Preconditions: more than one pool (a single pool returns `NotImplemented`), no decommission running or conflicting, and no query string on `start` or `stop`. +リバランスは、使用量に基づいてオブジェクトをプール間で再配置します。前提は、プールが複数あること（単一プールは `NotImplemented` を返す）、実行中または競合するデコミッションがないこと、`start` と `stop` にクエリ文字列がないことです。 ```text POST /rustfs/admin/v3/rebalance/start → {"id": ""} @@ -150,13 +150,13 @@ GET /rustfs/admin/v3/rebalance/status POST /rustfs/admin/v3/rebalance/stop ``` -Status reports per-pool `id`, `status`, `stopping`, `used`, `lastError`, `cleanupWarnings`, and `progress` (objects, versions, bytes, remaining buckets, current bucket and object, elapsed, ETA), plus `stoppedAt` and stop-propagation fields. +状態は、プールごとに `id`、`status`、`stopping`、`used`、`lastError`、`cleanupWarnings`、`progress`（オブジェクト数、バージョン数、バイト数、残りのバケット、現在のバケットとオブジェクト、経過時間、ETA）を報告します。加えて `stoppedAt` と、停止伝播のフィールドも報告します。 -Start propagates an admission fence and worker state to peers; a propagation failure rolls back to a terminal state and reports any peer that did not roll back. Stop closes admission, stops local and remote workers, and persists the stopped state. Treat a rebalance as finished only when no pool is active or stopping, `lastError` is empty or explained, `cleanupWarnings` are understood, stop propagation has completed, and migrated objects read from their new pool. Per-pool state lives in `rebalance.bin`; never delete it to unblock a run. See [Data Rebalancing](./scaling/data-rebalancing.md) for the walkthrough. +開始時は、新規受付を止めるフェンスとワーカー状態をピアへ伝播します。伝播に失敗すると終端状態へロールバックし、ロールバックできなかったピアを報告します。停止時は受付を閉じ、ローカルとリモートのワーカーを止め、停止状態を永続化します。リバランスを完了と見なしてよいのは、active または stopping のプールがなく、`lastError` が空か説明済みで、`cleanupWarnings` の内容を把握し、停止伝播が完了し、移行したオブジェクトを新しいプールから読めるときだけです。プールごとの状態は `rebalance.bin` にあります。実行を先へ進めるために削除してはいけません。手順は [データリバランス](./scaling/data-rebalancing.md) を参照してください。 -## Decommission +## デコミッション -Operator summary — supported only on multi-pool, non-legacy (ellipsis) deployments; anything else returns `NotImplemented`. A rebalance in progress blocks start. +運用上の要点です。対応しているのは、マルチプールかつ非レガシー（省略記号を使う）デプロイだけです。それ以外は `NotImplemented` を返します。実行中のリバランスは、開始をブロックします。 ```text POST /rustfs/admin/v3/pools/decommission?pool=[,] # by command line @@ -166,17 +166,17 @@ POST /rustfs/admin/v3/pools/cancel?pool=1&by-id=true POST /rustfs/admin/v3/pools/clear?pool=1&by-id=true ``` -- Targets are validated as a batch before anything is persisted: unknown, duplicate, active, queued, or completed targets are rejected; failed or canceled targets must be cleared first unless they hold unresolved listing entries, in which case a new start is the retry path. -- Entry states: `queued` → `active` → `completed`, `failed`, or `canceled`, persisted in `pool.bin`. Startup resumes non-terminal entries and skips terminal predecessors. -- A source pool in any decommission state rejects new ordinary PUTs and new multipart uploads (a staged PUT gets `SlowDown`); existing multipart uploads may drain while the source is non-terminal. -- `clear` removes failed or canceled metadata only and never moves data back. -- Remove a pool from the launch arguments only after its entry is `completed`, free versions and tier ownership have converged, and every node shows the same status. Never detach source drives before that, and never substitute a directory delete for the configuration change. +- ターゲットは、何も永続化する前にまとめて検証されます。未知、重複、active、queued、completed のターゲットは拒否されます。failed または canceled のターゲットは、先にクリアする必要があります。未解決の一覧エントリを持っている場合は、新たに開始することが再試行の経路です。 +- エントリの状態は `queued` → `active` → `completed`、`failed`、または `canceled` で、`pool.bin` に永続化されます。起動時は非終端のエントリを再開し、終端になっている先行エントリはスキップします。 +- デコミッションのいずれかの状態にあるソースプールは、通常の新規 PUT と新規マルチパートアップロードを拒否します（ステージ済みの PUT は `SlowDown` を受け取ります）。ソースが非終端のあいだは、既存のマルチパートアップロードを排出できます。 +- `clear` が消すのは failed または canceled のメタデータだけで、データを元へ戻すことはありません。 +- 起動引数からプールを外すのは、エントリが `completed` になり、解放されたバージョンとティアの所有権が収束し、すべてのノードが同じ状態を示すあとだけにしてください。それより前にソースドライブを切り離してはいけません。設定変更の代わりにディレクトリを削除してもいけません。 -See [Storage Pool Decommission](./scaling/storage-pool-decommission.md) for the walkthrough. +手順は [ストレージプールのデコミッション](./scaling/storage-pool-decommission.md) を参照してください。 -## Heal and drive replacement +## データ修復とドライブ交換 -### Admin heal +### 管理 heal ```text POST /rustfs/admin/v3/heal/ # root: cluster, or one erasure set with pool+set @@ -186,59 +186,59 @@ POST /rustfs/admin/v3/background-heal/status GET /rustfs/admin/v4/heal/replacement-recovery ``` -The JSON body carries `recursive`, `dryRun`, `remove`, `recreate`, `scanMode`, `updateParity`, `nolock`, `readRepair`, `pool`, and `set`. Handler rules: +JSON ボディには `recursive`、`dryRun`、`remove`、`recreate`、`scanMode`、`updateParity`、`nolock`、`readRepair`、`pool`、`set` が入ります。ハンドラーの規則は次のとおりです。 -- a root heal must set `recursive=true` or name both `pool` and `set`; a bucket heal without a prefix is always recursive, and a prefix heal honors `recursive`; -- `readRepair=true` is rejected with `InvalidArgument`; -- `nolock` is accepted on the wire but always forced to `false` — admin heals always take the object namespace lock, so there is no lock bypass; -- `clientToken` correlates start, status, and stop; `forceStart` and `forceStop` are validated against it, and unknown or duplicate query keys are rejected. +- ルート heal は `recursive=true` を指定するか、`pool` と `set` の両方を指定する必要があります。プレフィックスのないバケット heal は常に再帰的です。プレフィックス heal は `recursive` に従います。 +- `readRepair=true` は `InvalidArgument` で拒否されます。 +- `nolock` は通信上は受け付けられますが、常に `false` に強制されます。管理 heal は常にオブジェクト名前空間のロックを取得するため、ロックを回避する方法はありません。 +- `clientToken` は開始、状態、停止を関連付けます。`forceStart` と `forceStop` はそれに対して検証され、未知または重複したクエリキーは拒否されます。 -Heal selects the authoritative version from quorum metadata and refuses when more shards are missing than parity can rebuild or when the stored geometry does not match the set. It shares the `(bucket, object)` lock with PUT, delete, multipart complete, and data movement. +データ修復は、クォーラムのメタデータから正規のバージョンを選び、欠落シャードがパリティで再構築できる数を超える場合、または保存されている幾何構成がセットと一致しない場合は拒否します。`(bucket, object)` のロックを、PUT、削除、マルチパート完了、データ移動と共有します。 -### Drive replacement +### ドライブ交換 -1. Confirm the affected set still meets read quorum for its objects (impossible at `EC:0`) and record pool index, set index, slot, and the failed disk's UUID from the pool status. -2. Replace the drive at the **same** endpoint and mount path with an empty filesystem owned by RustFS. Do not copy the old drive's directories; a copied `format.json` claims an identity the set already tracks. -3. Bring the node back. The empty drive is not a format-quorum member, so its slot stays offline until the erasure-set heal task writes the format into the original slot and rebuilds the shards — through the recorded automatic replacement intent when startup or the disk scanner observes a changed mount identity, or through an admin erasure-set heal (`POST /rustfs/admin/v3/heal/` with `pool` and `set`). -4. Watch `GET /rustfs/admin/v4/heal/replacement-recovery`, background heal status, disk health, and bitrot counters. An `idle` queue or a readable object is not proof of completion. -5. The replacement is done when recovery reports `completed` for that instance and sampled objects have `xl.meta` and parts on the new drive. +1. 影響を受けるセットが、そのオブジェクトの読み取りクォーラムをまだ満たしていることを確認します（`EC:0` では不可能です）。プールの状態から、プールのインデックス、セットのインデックス、スロット、障害ディスクの UUID を記録します。 +2. **同じ**エンドポイントとマウントパスで、RustFS が所有する空のファイルシステムにドライブを交換します。古いドライブのディレクトリをコピーしないでください。コピーした `format.json` は、セットがすでに追跡している識別子だと主張します。 +3. ノードを復帰させます。空のドライブはフォーマットクォーラムのメンバーではないため、イレイジャーセットの heal タスクが元のスロットへフォーマットを書き、シャードを再構築するまで、そのスロットはオフラインのままです。再構築は、起動時またはディスクスキャナーがマウント識別情報の変化を観測したときに記録された自動交換インテントによって、または管理用のイレイジャーセット heal（`pool` と `set` を付けた `POST /rustfs/admin/v3/heal/`）によって行われます。 +4. `GET /rustfs/admin/v4/heal/replacement-recovery`、バックグラウンド heal の状態、ディスクの健全性、ビットロットのカウンタを監視します。キューが `idle` であることや、オブジェクトが読めることは、完了の証明にはなりません。 +5. 交換が完了するのは、そのインスタンスについてリカバリが `completed` を報告し、サンプルしたオブジェクトの `xl.meta` とパートが新しいドライブ上にあるときです。 -If a set has lost more drives than its parity, heal cannot rebuild; recover from replication, a remote tier, or backup. See [Node Healing](./high-availability/node-healing.md) for the broader healing model. +セットが失ったドライブ数がパリティを超えている場合、データ修復では再構築できません。レプリケーション、リモートティア、またはバックアップから復旧します。より広いデータ修復のモデルは [ノードのデータ修復](./high-availability/node-healing.md) を参照してください。 -## Restart and recovery +## 再起動と復旧 -- **Ordinary restart.** No topology change in flight, identical arguments on every node, one node at a time. Startup reloads pool metadata, `rebalance.bin`, the decommission queue, and heal recovery records, and resumes workers by leader and owner rules. -- **Rebalance.** Read `/rebalance/status` first. Handle active or stopping pools, `lastError`, cleanup warnings, and stop propagation before deciding to stop or restart. Do not delete `rebalance.bin`. -- **Decommission.** Non-terminal entries resume; failed and canceled entries survive restarts until cleared or retried through the allowed path. -- **Root heal.** A graceful shutdown persists an unfinished cluster heal as `root-heal-.json` under `.rustfs.sys` and replays it with the same task id. Invalid, oversized, or unsupported records move to quarantine prefixes and are skipped with a log line until an operator repairs them. Do not delete quarantine markers or reuse a task id. -- **Unclean shutdown.** When the previous run left its marker behind, the heal manager enqueues a full erasure-set heal for every local set; graceful shutdown clears the marker. +- **通常の再起動。** 進行中のトポロジ変更はなく、すべてのノードで引数は同一で、一度に 1 ノードずつ再起動します。起動時にプールメタデータ、`rebalance.bin`、デコミッションキュー、heal の復旧レコードを読み込み、リーダーと所有者の規則に従ってワーカーを再開します。 +- **リバランス。** まず `/rebalance/status` を読みます。停止するか再起動するかを決める前に、active または stopping のプール、`lastError`、クリーンアップ警告、停止伝播を扱います。`rebalance.bin` を削除しないでください。 +- **デコミッション。** 非終端のエントリは再開します。failed と canceled のエントリは、クリアされるか、許可された経路で再試行されるまで、再起動をまたいで残ります。 +- **ルート heal。** 正常なシャットダウンは、未完了のクラスター heal を `.rustfs.sys` 以下の `root-heal-.json` として永続化し、同じタスク ID で再実行します。無効、サイズ超過、または未対応のレコードは隔離用プレフィックスへ移され、運用担当者が修復するまでログを出してスキップされます。隔離マーカーを削除したり、タスク ID を再利用したりしないでください。 +- **異常なシャットダウン。** 前回の実行がマーカーを残している場合、heal マネージャーはローカルのすべてのセットに対して、イレイジャーセット全体の heal をキューに入れます。正常なシャットダウンではマーカーが消去されます。 -## Mutual exclusion and prohibited actions +## 相互排他と禁止操作 -| Operation | With rebalance | With decommission | Notes | +| 操作 | リバランス時 | デコミッション時 | 注意 | |---|---|---|---| -| PUT, DELETE, multipart complete | Object lock | Source pool rejects new publication | Never bypass the pool fence | -| Decommission | Rejected while rebalance runs | Serial queue | Leader-only mutation | -| Rebalance | Multi-pool only | Rejected while decommission runs or conflicts | No query parameters | -| Admin heal | Object lock | Repairs data, never changes decommission state | `nolock` is ignored | -| Drive replacement | Cannot change the layout | Avoid on a source pool mid-decommission | Same slot, empty drive | +| PUT、DELETE、マルチパート完了 | オブジェクトロック | ソースプールは新規の公開を拒否する | プールのフェンスを回避しない | +| デコミッション | リバランスの実行中は拒否される | 直列キュー | 変更できるのはリーダーだけ | +| リバランス | マルチプールのみ | デコミッションの実行中、または競合時は拒否される | クエリパラメーターは付けられない | +| 管理 heal | オブジェクトロック | データを修復し、デコミッションの状態は変えない | `nolock` は無視される | +| ドライブ交換 | レイアウトは変更できない | デコミッションの途中にあるソースプールでは避ける | 同じスロットの空ドライブ | -:::warning[Prohibited] +:::warning[禁止事項] -Do not change launch endpoints while rebalance or decommission runs; do not delete `.rustfs.sys`, `rebalance.bin`, `pool.bin`, or root-heal records; do not run manual heal, file copies, and drive replacement on one pool at the same time; do not treat an HTTP 200 on a start call as completion. +リバランスまたはデコミッションの実行中に、起動エンドポイントを変更しないでください。`.rustfs.sys`、`rebalance.bin`、`pool.bin`、ルート heal のレコードを削除しないでください。手動 heal、ファイルコピー、ドライブ交換を、同一プールで同時に実行しないでください。開始呼び出しが HTTP 200 を返しても、完了と見なしてはいけません。 ::: -## Checklists +## チェックリスト -- **After start or expansion**: identical endpoints and pool order on every node; topology equals the stored format; peers ready; new endpoints unique and RustFS-exclusive; GET, HEAD, range GET, and multipart verified. -- **After rebalance**: no pool active or stopping; `lastError` empty or explained; `cleanupWarnings` handled; stop propagation complete; migrated objects readable. -- **After decommission**: status `completed`; other entries handled by policy; source pool rejects new writes; free versions, tier ownership, and listing entries converged; launch arguments updated on every node before drives are detached. -- **After heal or replacement**: replacement recovery `completed`; slot and UUID correct; heal queue drained; no growing bitrot count; sampled current and historical versions readable; no leftover temporary directories. +- **起動または拡張のあと**: すべてのノードでエンドポイントとプール順が同一であること。トポロジが保存済みフォーマットと一致すること。ピアが準備完了であること。新しいエンドポイントが一意で、RustFS だけが使うこと。GET、HEAD、範囲指定の GET、マルチパートが検証済みであること。 +- **リバランスのあと**: active または stopping のプールがないこと。`lastError` が空か説明済みであること。`cleanupWarnings` を処理済みであること。停止伝播が完了していること。移行したオブジェクトが読めること。 +- **デコミッションのあと**: 状態が `completed` であること。他のエントリが方針どおりに処理されていること。ソースプールが新規の書き込みを拒否すること。解放されたバージョン、ティアの所有権、一覧エントリが収束していること。ドライブを切り離す前に、すべてのノードで起動引数を更新していること。 +- **データ修復または交換のあと**: 交換リカバリが `completed` であること。スロットと UUID が正しいこと。heal キューが空であること。ビットロット数が増えていないこと。サンプルした現行バージョンと過去バージョンが読めること。一時ディレクトリが残っていないこと。 -## rc command mapping +## rc コマンドの対応 -`rc` is the RustFS CLI (see [CLI Client (rc)](./rc.mdx)); its `expand` group is an alias of `rebalance` — there is no server-side expand API. Flags below are the commonly used ones; check `rc admin --help` for the installed version. +`rc` は RustFS の CLI です（[CLI クライアント（rc）](./rc.mdx) を参照）。`expand` グループは `rebalance` のエイリアスです。サーバー側の expand API はありません。以下は、よく使うフラグです。インストール済みのバージョンは `rc admin --help` で確認します。 ```bash rc alias set local http://localhost:9000 @@ -261,18 +261,18 @@ rc admin heal status local --client-token rc admin heal stop local --client-token ``` -| `rc` command | Server route | +| `rc` コマンド | サーバー側のパス | |---|---| | `rc ping` / `rc ready` | `GET /health` / `GET /health/ready` | | `rc admin pool list` / `status` | `GET /rustfs/admin/v3/pools/list` / `GET /rustfs/admin/v3/pools/status` | -| `rc admin rebalance …` (alias `expand`) | `/rustfs/admin/v3/rebalance/*` | +| `rc admin rebalance …` (エイリアス `expand`) | `/rustfs/admin/v3/rebalance/*` | | `rc admin decommission start` / `cancel` / `clear` | `POST /rustfs/admin/v3/pools/decommission` / `cancel` / `clear` | | `rc admin decommission status` | `GET /rustfs/admin/v3/decommission/status` | | `rc admin heal start` / `status` / `stop` | `/rustfs/admin/v3/heal/*`, `POST /rustfs/admin/v3/background-heal/status` | -`rc admin heal start` exposes `--bucket`, `--prefix`, `--scan-mode`, `--remove`, `--recreate`, and `--dry-run`; it does not expose `nolock`, `forceStart`, `forceStop`, `pool`, or `set`. There is no `rc` command for replacement recovery; call `GET /rustfs/admin/v4/heal/replacement-recovery` directly. +`rc admin heal start` が公開するのは `--bucket`、`--prefix`、`--scan-mode`、`--remove`、`--recreate`、`--dry-run` です。`nolock`、`forceStart`、`forceStop`、`pool`、`set` は公開しません。交換リカバリ用の `rc` コマンドはありません。`GET /rustfs/admin/v4/heal/replacement-recovery` を直接呼び出します。 -## References +## 参考資料 -- Upstream runbook: `docs/operations/cluster-lifecycle-operations.md` in [rustfs/rustfs#7998](https://github.com/rustfs/rustfs/pull/7998) — the source this page is adapted from, verified claim by claim against the RustFS source code. -- [Storage Pool Expansion](./scaling/storage-pool-expansion.md) · [Data Rebalancing](./scaling/data-rebalancing.md) · [Storage Pool Decommission](./scaling/storage-pool-decommission.md) · [Node Healing](./high-availability/node-healing.md) · [CLI Client (rc)](./rc.mdx) +- 上流のランブック: [rustfs/rustfs#7998](https://github.com/rustfs/rustfs/pull/7998) の `docs/operations/cluster-lifecycle-operations.md`。本ページはこの文書を基にしており、記載は RustFS のソースコードに対して項目ごとに検証済みです。 +- [ストレージプールの拡張](./scaling/storage-pool-expansion.md) · [データリバランス](./scaling/data-rebalancing.md) · [ストレージプールのデコミッション](./scaling/storage-pool-decommission.md) · [ノードのデータ修復](./high-availability/node-healing.md) · [CLI クライアント（rc）](./rc.mdx) diff --git a/content/ja/operations/credentials.md b/content/ja/operations/credentials.md index 91c4500e7..0590867c4 100644 --- a/content/ja/operations/credentials.md +++ b/content/ja/operations/credentials.md @@ -1,46 +1,46 @@ --- -title: "Credential Management" -description: "This article covers configuring RustFS root credentials via environment variables and secret files, rotating them safely, the internode RPC secret, and the MinIO-compatible environment aliases." +title: "認証情報の管理" +description: "RustFS のルート認証情報の設定とローテーション、ノード間 RPC シークレットの設定、MinIO 互換の環境変数エイリアスの使い方を説明します。" --- -## Root Credentials +## ルート認証情報 -RustFS reads its root (admin) credential pair from: +RustFS は、ルート（管理者）の認証情報の組を次から読み込みます。 ```bash RUSTFS_ACCESS_KEY= RUSTFS_SECRET_KEY= ``` -If neither is provided, the server falls back to the built-in default `rustfsadmin` / `rustfsadmin`. +どちらも指定されていない場合、サーバーは組み込みの既定値 `rustfsadmin` / `rustfsadmin` にフォールバックします。 -:::warning[Choose safe root credentials] +:::warning[安全なルート認証情報を選ぶ] -[AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-signing-elements.html) embeds the access key in a slash-delimited credential scope: +[AWS 署名バージョン 4（SigV4）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-signing-elements.html) は、スラッシュ区切りの認証情報スコープにアクセスキーを埋め込みます。 `////aws4_request` -Do not include `/` in `RUSTFS_ACCESS_KEY`, because it causes the access key and credential scope to be parsed incorrectly. We recommend using only uppercase ASCII letters and digits (`A-Z`, `0-9`), matching the format generated by RustFS. Do not use unmodified Base64 output as an access key; use a separate strong random value for `RUSTFS_SECRET_KEY`. +`RUSTFS_ACCESS_KEY` に `/` を含めてはなりません。含めると、アクセスキーと認証情報スコープが誤って解釈されます。RustFS が生成する形式に合わせ、大文字の ASCII 英字と数字（`A-Z`、`0-9`）だけを使うことを推奨します。Base64 の出力をそのままアクセスキーに使ってはなりません。`RUSTFS_SECRET_KEY` には、それとは別の強い乱数値を使います。 -The default `rustfsadmin` credentials are public and well-known. The container entrypoint prints a warning but still starts. Always set non-default credentials before exposing ports 9000/9001 beyond localhost. Additionally, a multi-node cluster running with an all-default pair **must** set `RUSTFS_RPC_SECRET` (see below) — the server refuses to derive internode RPC auth from the default secret key. +既定の `rustfsadmin` 認証情報は公開されており、広く知られています。コンテナのエントリポイントは警告を出力しますが、起動は継続します。ポート 9000/9001 を localhost の外へ公開する前に、必ず既定以外の認証情報を設定します。さらに、すべて既定の組で動作するマルチノードのクラスターでは、`RUSTFS_RPC_SECRET` を設定する必要があります（後述）。サーバーは、既定のシークレットキーからノード間 RPC 認証を導出することを拒否します。 ::: -## File-Based Injection (Docker/Kubernetes Secrets) +## ファイルからの読み込み（Docker/Kubernetes のシークレット） -Instead of putting secrets into the environment, point RustFS at files containing them: +シークレットを環境変数へ直接置かず、内容を収めたファイルを RustFS に指定します。 ```bash RUSTFS_ACCESS_KEY_FILE=/run/secrets/rustfs_access_key RUSTFS_SECRET_KEY_FILE=/run/secrets/rustfs_secret_key ``` -Equivalent CLI flags exist (`--access-key-file`, `--secret-key-file`). Rules enforced by the container entrypoint: +同等の CLI フラグ（`--access-key-file`、`--secret-key-file`）もあります。コンテナのエントリポイントが適用する規則は次のとおりです。 -- Only the **first line** of the file is read; surrounding whitespace and CR characters (CRLF-edited files) are trimmed. A file without a trailing newline is valid. -- Setting both the direct variable and the `_FILE` variant for the same credential is a hard error: `Set either RUSTFS_ACCESS_KEY or RUSTFS_ACCESS_KEY_FILE, not both.` -- An empty value, an empty file, or an unreadable file is a hard error (exit 1). -- A file containing the default `rustfsadmin` value triggers the same warning as the direct variable. +- 読み取るのはファイルの**先頭行だけ**です。前後の空白と CR 文字（CRLF で編集されたファイル）は取り除かれます。末尾に改行がないファイルも有効です。 +- 同じ認証情報について、直接の変数と `_FILE` 版の両方を設定すると、エラーになります。`Set either RUSTFS_ACCESS_KEY or RUSTFS_ACCESS_KEY_FILE, not both.` +- 空の値、空のファイル、読み取れないファイルは、エラーです（終了コード 1）。 +- 既定値 `rustfsadmin` を含むファイルは、直接の変数と同じ警告を出します。 ```yaml title="docker-compose example with secrets" services: @@ -59,60 +59,60 @@ secrets: file: ./secrets/secret_key.txt ``` -## Rotating the Root Credentials +## ルート認証情報のローテーション -All nodes of a cluster must run with the **same** root credential pair — internode RPC authentication is derived from it unless `RUSTFS_RPC_SECRET` is set explicitly. +クラスターのすべてのノードは、**同じ**ルート認証情報の組で動作する必要があります。`RUSTFS_RPC_SECRET` を明示的に設定していない場合、ノード間 RPC 認証はこの組から導出されます。 :::note -The step-by-step procedure below is standard operational practice composed from verified building blocks (env/file configuration plus the verified rolling-restart readiness signals); RustFS does not currently document an online root-credential rotation API. +以下の手順は、検証済みの構成要素（環境変数とファイルによる設定、および検証済みのローリングリスタート時の準備完了シグナル）から組み立てた、標準的な運用手順です。RustFS は現時点で、オンラインのルート認証情報ローテーション API を文書化していません。 ::: -1. If you have not already, set an explicit `RUSTFS_RPC_SECRET` (same value on all nodes) **before** the rotation. This decouples internode auth from the credential pair, so the cluster tolerates nodes temporarily running with mixed old/new root credentials during the rolling restart. -2. Update the environment file / secret on **every** node with the new `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` (or the files behind the `_FILE` variants). -3. Restart nodes **one at a time**, waiting for each to return `200` from `GET /health/ready` on port 9000 before restarting the next. -4. Update every client, SDK configuration, and automation that used the old pair. -5. Verify: sign a request with the old credentials and confirm it is rejected. +1. まだ設定していない場合は、ローテーションの**前に**、明示的な `RUSTFS_RPC_SECRET`（全ノードで同じ値）を設定します。これによりノード間認証が認証情報の組から分離され、ローリングリスタートの間、古いルート認証情報と新しいルート認証情報が一時期混在しても、クラスターは動作を続けられます。 +2. **すべての**ノードで、環境ファイルまたはシークレットを新しい `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY`（または `_FILE` 版が指すファイル）に更新します。 +3. ノードを**1 台ずつ**再起動します。次のノードを再起動する前に、ポート 9000 の `GET /health/ready` が `200` を返すまで待ちます。 +4. 古い組を使っていたすべてのクライアント、SDK の設定、自動化を更新します。 +5. 確認します。古い認証情報でリクエストに署名し、拒否されることを確認します。 -## RUSTFS_RPC_SECRET (Internode RPC Auth) +## RUSTFS_RPC_SECRET（ノード間 RPC 認証） -Nodes of a distributed cluster authenticate their internal RPC traffic with a shared secret: +分散クラスターのノードは、共有シークレットで内部の RPC トラフィックを認証します。 -- If `RUSTFS_RPC_SECRET` is set, that value is used directly. Set the **same value on every node**. -- If it is unset, the secret is **derived** (HMAC) from the active access/secret key pair — which is why all nodes must share the same root credentials. -- Derivation **fails closed** when the secret key is the default `rustfsadmin`: a publicly known secret would yield a publicly computable RPC secret that any network peer could use to forge internode signatures. In that configuration internode RPC cannot authenticate until you either set `RUSTFS_RPC_SECRET` or configure a non-default `RUSTFS_SECRET_KEY`. +- `RUSTFS_RPC_SECRET` が設定されている場合、その値をそのまま使います。**すべてのノードで同じ値**を設定します。 +- 未設定の場合、シークレットは有効なアクセスキーとシークレットキーの組から **HMAC で導出**されます。このため、すべてのノードが同じルート認証情報を共有する必要があります。 +- シークレットキーが既定の `rustfsadmin` のとき、導出は**フェイルクローズ**します。公開されているシークレットからは、誰でも計算できる RPC シークレットが得られ、ネットワーク上の任意のピアがノード間署名の偽造に使えます。この構成では、`RUSTFS_RPC_SECRET` を設定するか、既定以外の `RUSTFS_SECRET_KEY` を設定するまで、ノード間 RPC は認証できません。 -When to set it explicitly: +明示的に設定する場面は次のとおりです。 -- multi-node clusters that (temporarily or otherwise) run with default root credentials; -- before rotating root credentials, to keep internode auth stable during the rollout; -- environments where you want internode auth independent of the S3 root credential lifecycle. +- 既定のルート認証情報で（一時的かどうかにかかわらず）動作するマルチノードのクラスター。 +- ルート認証情報をローテーションする前。ロールアウト中もノード間認証を安定させます。 +- ノード間認証を、S3 のルート認証情報のライフサイクルから独立させたい環境。 ```bash # Same value on every node RUSTFS_RPC_SECRET= ``` -## Compatibility Aliases +## 互換エイリアス -For drop-in migration, RustFS accepts credential variables under legacy and MinIO-compatible names when the canonical `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` are not set: +移行時の互換のため、正規の `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` が設定されていない場合、RustFS はレガシー名および MinIO 互換名の認証情報変数を受け付けます。 -| Accepted alias | Canonical variable | +| 受け付けるエイリアス | 正規の変数 | | --- | --- | -| `RUSTFS_ROOT_USER` (legacy) | `RUSTFS_ACCESS_KEY` | -| `RUSTFS_ROOT_PASSWORD` (legacy) | `RUSTFS_SECRET_KEY` | +| `RUSTFS_ROOT_USER`（レガシー） | `RUSTFS_ACCESS_KEY` | +| `RUSTFS_ROOT_PASSWORD`（レガシー） | `RUSTFS_SECRET_KEY` | | `MINIO_ROOT_USER` | `RUSTFS_ROOT_USER` → `RUSTFS_ACCESS_KEY` | | `MINIO_ROOT_PASSWORD` | `RUSTFS_ROOT_PASSWORD` → `RUSTFS_SECRET_KEY` | -The `MINIO_` prefix mapping covers a broader allowlist of variables (address, console address, audit webhook settings, and more), applied at startup as "external-prefix compatibility mappings". +`MINIO_` 接頭辞の対応は、より広い許可リストの変数（アドレス、Console のアドレス、監査 Webhook の設定など）を対象とし、起動時に「external-prefix compatibility mappings」（外部接頭辞の互換マッピング）として適用されます。 :::note -Aliases are deprecated. When one is used, the server logs a one-time warning of the form `Environment variable MINIO_ROOT_USER is deprecated, use RUSTFS_ROOT_USER instead`. Use the `RUSTFS_`-prefixed canonical names in new deployments; the canonical name always wins when both are set. +エイリアスは非推奨です。使用すると、サーバーは `Environment variable MINIO_ROOT_USER is deprecated, use RUSTFS_ROOT_USER instead` の形式で、一度だけ警告をログに記録します。新しいデプロイでは、`RUSTFS_` 接頭辞の正規名を使います。両方を設定した場合は、常に正規名が優先されます。 ::: -## Beyond the Root Credential +## ルート認証情報以外 -Day-to-day access should not use the root pair. Create scoped users, groups, policies, and service accounts through the console on port 9001 or the IAM admin APIs, and reserve the root credential for administrative operations. See the IAM documentation in the administration section. +日常のアクセスには、ルートの組を使わないことを推奨します。ポート 9001 の Console（管理画面）、または IAM の管理 API で、権限範囲を限定したユーザー、グループ、ポリシー、サービスアカウントを作成し、ルート認証情報は管理操作のために残します。管理セクションの IAM ドキュメントを参照します。 diff --git a/content/ja/operations/event-notifications.md b/content/ja/operations/event-notifications.md index a6162a4f4..73d22833a 100644 --- a/content/ja/operations/event-notifications.md +++ b/content/ja/operations/event-notifications.md @@ -1,36 +1,36 @@ --- -title: "Event Notifications" -description: "Configure RustFS bucket event notifications and deliver filtered object events to external targets." +title: "イベント通知" +description: "RustFS のバケットイベント通知を設定し、絞り込んだオブジェクトイベントを外部ターゲットへ配信する方法を説明します。" --- -RustFS Event Notifications deliver S3 bucket activity to external systems. This guide configures a webhook target, associates it with a bucket, and verifies delivery with AWS CLI. +RustFS のイベント通知は、S3 バケットのアクティビティを外部システムへ配信します。このガイドでは、Webhook ターゲットを設定してバケットに関連付け、AWS CLI で配信を確認します。 -## Overview +## 概要 -An event notification has two independent parts: +イベント通知は、互いに独立した 2 つの部分で構成されます。 -- A **notification target** defines where RustFS sends events. -- A **bucket notification configuration** selects the target, event types, and optional object-key filters for one bucket. +- **通知ターゲット**は、RustFS がイベントを送る先を定義します。 +- **バケット通知設定**は、1 つのバケットについて、ターゲット、イベント種別、任意のオブジェクトキーフィルタを選びます。 -RustFS supports webhook, Kafka, MQTT, MySQL, PostgreSQL, NATS, Redis, AMQP, and Pulsar target families. The webhook workflow below is useful for HTTP services, serverless functions, and integration platforms. +RustFS は、Webhook、Kafka、MQTT、MySQL、PostgreSQL、NATS、Redis、AMQP、Pulsar のターゲット系統をサポートします。以下の Webhook の手順は、HTTP サービス、サーバーレス関数、連携プラットフォームに向いています。 -Bucket rules use the S3 `PutBucketNotificationConfiguration` and `GetBucketNotificationConfiguration` APIs. RustFS currently accepts queue configurations; AWS SNS topic and Lambda function configurations are not supported. +バケットのルールは、S3 の `PutBucketNotificationConfiguration` と `GetBucketNotificationConfiguration` API を使います。RustFS が現在受け付けるのはキュー設定です。AWS SNS のトピックと Lambda 関数の設定はサポートしていません。 -Common event families include: +主なイベントの系統は次のとおりです。 -| Event family | Example events | +| イベントの系統 | 例 | | --- | --- | -| Object creation | `s3:ObjectCreated:Put`, `s3:ObjectCreated:Copy`, `s3:ObjectCreated:CompleteMultipartUpload` | -| Object removal | `s3:ObjectRemoved:Delete`, `s3:ObjectRemoved:DeleteMarkerCreated` | -| Object access | `s3:ObjectAccessed:Get`, `s3:ObjectAccessed:Head` | -| Object tagging | `s3:ObjectTagging:Put`, `s3:ObjectTagging:Delete` | -| Lifecycle and tiering | Expiration, restore, replication, and transition events | +| オブジェクトの作成 | `s3:ObjectCreated:Put`、`s3:ObjectCreated:Copy`、`s3:ObjectCreated:CompleteMultipartUpload` | +| オブジェクトの削除 | `s3:ObjectRemoved:Delete`、`s3:ObjectRemoved:DeleteMarkerCreated` | +| オブジェクトへのアクセス | `s3:ObjectAccessed:Get`、`s3:ObjectAccessed:Head` | +| オブジェクトのタグ付け | `s3:ObjectTagging:Put`、`s3:ObjectTagging:Delete` | +| ライフサイクルと階層化 | 有効期限切れ、復元、レプリケーション、移行の各イベント | -Use a wildcard such as `s3:ObjectCreated:*` to subscribe to every event in a family. +系統内のすべてのイベントを購読するには、`s3:ObjectCreated:*` のようなワイルドカードを使います。 -## Configuration +## 設定 -Event Notifications are disabled by default. The following environment variables enable the module and create a webhook target named `primary`: +イベント通知は既定で無効です。次の環境変数でモジュールを有効にし、`primary` という名前の Webhook ターゲットを作成します。 ```bash export RUSTFS_NOTIFY_ENABLE="true" @@ -41,40 +41,40 @@ export RUSTFS_NOTIFY_WEBHOOK_QUEUE_DIR_PRIMARY="/var/lib/rustfs/notify-primary" export RUSTFS_OUTBOUND_ALLOW_ORIGINS="https://events.example.com" ``` -Restart RustFS after changing environment-managed targets. The target name is the lowercase form of the environment-variable suffix, so `_PRIMARY` creates `primary`. Use the target ARN `arn:rustfs:sqs:us-east-1:primary:webhook` in the bucket configuration. +環境変数で管理するターゲットを変更したあとは、RustFS を再起動します。ターゲット名は環境変数の接尾辞を小文字にしたものなので、`_PRIMARY` は `primary` を作成します。バケット設定では、ターゲット ARN `arn:rustfs:sqs:us-east-1:primary:webhook` を使います。 -RustFS sends a `HEAD` health check to the endpoint origin's root path, such as `https://events.example.com/`, and sends JSON `POST` requests to the complete configured endpoint. The origin must respond to `HEAD`, while delivery requests must return a successful HTTP status. Allow the RustFS service account to write to the queue directory. +RustFS は、エンドポイントのオリジンのルートパス（`https://events.example.com/` など）へ `HEAD` のヘルスチェックを送り、設定された完全なエンドポイントへ JSON の `POST` リクエストを送ります。オリジンは `HEAD` に応答する必要があります。配信リクエストは、成功を示す HTTP ステータスを返す必要があります。RustFS プロセスの実行アカウントには、キューディレクトリへの書き込みを許可します。 -### Webhook settings +### Webhook の設定 -Use the same `_PRIMARY` suffix on all settings for this target: +このターゲットのすべての設定で、同じ `_PRIMARY` 接尾辞を使います。 -| Variable | Purpose | +| 変数 | 用途 | | --- | --- | -| `RUSTFS_NOTIFY_WEBHOOK_ENDPOINT_PRIMARY` | HTTP or HTTPS delivery endpoint | -| `RUSTFS_NOTIFY_WEBHOOK_AUTH_TOKEN_PRIMARY` | Bearer token sent in the `Authorization` header | -| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_DIR_PRIMARY` | Directory for queued deliveries | -| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_LIMIT_PRIMARY` | Maximum number of queued events | -| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CERT_PRIMARY` | Client certificate for mutual TLS (mTLS) | -| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_KEY_PRIMARY` | Private key paired with the client certificate | -| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA_PRIMARY` | Certificate authority used to verify the receiver | -| `RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY` | Disable server certificate verification | +| `RUSTFS_NOTIFY_WEBHOOK_ENDPOINT_PRIMARY` | HTTP または HTTPS の配信エンドポイント | +| `RUSTFS_NOTIFY_WEBHOOK_AUTH_TOKEN_PRIMARY` | `Authorization` ヘッダーで送る Bearer トークン | +| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_DIR_PRIMARY` | キューに入れた配信を置くディレクトリ | +| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_LIMIT_PRIMARY` | キューに入れられるイベントの最大数 | +| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CERT_PRIMARY` | 相互 TLS（mTLS）用のクライアント証明書 | +| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_KEY_PRIMARY` | クライアント証明書と対になる秘密鍵 | +| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA_PRIMARY` | 受信側の検証に使う認証局 | +| `RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY` | サーバー証明書の検証を無効にします | -:::warning[Keep certificate verification enabled] +:::warning[証明書の検証は有効のままにする] -Do not enable `RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY` in production. Configure `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA_PRIMARY` when the receiver uses a private certificate authority. If you use mTLS, provide both the client certificate and private key. +本番では `RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY` を有効にしないでください。受信側がプライベート認証局を使う場合は、`RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA_PRIMARY` を設定します。mTLS を使う場合は、クライアント証明書と秘密鍵の両方を指定します。 ::: -For all target families and target-specific keys, see [Environment Variables](/reference/environment-variables#event--audit-targets). +すべてのターゲット系統と、ターゲット固有のキーについては、[環境変数](/ja/reference/environment-variables#event--audit-targets)を参照します。 -## Usage +## 使い方 -The following example sends creation and removal events for `.dat` objects under `uploads/` to the `primary` webhook. +次の例では、`uploads/` 配下の `.dat` オブジェクトに対する作成イベントと削除イベントを、`primary` の Webhook へ送ります。 -### Configure the bucket rule +### バケットルールを設定する -Create the notification configuration: +通知設定を作成します。 ```json title="notification.json" { @@ -99,7 +99,7 @@ Create the notification configuration: } ``` -Apply it to `my-bucket` with [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html): +[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) で `my-bucket` に適用します。 ```bash aws --endpoint-url http://localhost:9000 \ @@ -109,9 +109,9 @@ aws --endpoint-url http://localhost:9000 \ --notification-configuration file://notification.json ``` -Saving a bucket rule does not prove that its target exists or is online. Confirm that the module and target are enabled, the receiver answers health checks, and a test object operation produces a delivery. +バケットルールを保存しても、そのターゲットが存在することやオンラインであることは証明されません。モジュールとターゲットが有効であること、受信側がヘルスチェックに応答すること、テストのオブジェクト操作で配信が行われることを確認します。 -Read the active configuration: +有効な設定を読み取ります。 ```bash aws --endpoint-url http://localhost:9000 \ @@ -120,13 +120,13 @@ aws --endpoint-url http://localhost:9000 \ --bucket my-bucket ``` -Prefix and suffix filters are case-sensitive and are combined with AND logic. A rule can contain at most one prefix and one suffix filter. +プレフィックスとサフィックスのフィルタは大文字と小文字を区別し、AND 条件で組み合わせます。1 つのルールに含められるプレフィックスフィルタとサフィックスフィルタは、それぞれ最大 1 つです。 -### Manage rules with rc +### rc でルールを管理する -The `rc` client can add, list, and remove bucket notification rules. It does not configure the notification module or create the underlying webhook, broker, or database target; configure those first through environment variables or the Console. +`rc` クライアントでは、バケット通知ルールの追加、一覧、削除ができます。通知モジュールの設定や、基盤となる Webhook、ブローカー、データベースのターゲット作成は行いません。それらは先に、環境変数または Console（管理画面）で設定します。 -Add creation and removal events for the `primary` target: +`primary` ターゲットに、作成イベントと削除イベントを追加します。 ```bash rc bucket event add \ @@ -135,13 +135,13 @@ rc bucket event add \ --event put,delete ``` -List the active rules: +有効なルールを一覧します。 ```bash rc --json bucket event list rustfs/my-bucket ``` -Remove every rule associated with that target ARN: +そのターゲット ARN に関連付けられたルールをすべて削除します。 ```bash rc bucket event remove \ @@ -149,11 +149,11 @@ rc bucket event remove \ arn:rustfs:sqs:us-east-1:primary:webhook ``` -The current `rc bucket event add` command does not expose prefix or suffix filter options. Use AWS CLI when the rule must filter object keys. +現在の `rc bucket event add` コマンドには、プレフィックスやサフィックスのフィルタオプションがありません。ルールでオブジェクトキーをフィルタする必要がある場合は、AWS CLI を使います。 -### Trigger and inspect events +### イベントを発生させて確認する -Upload and remove a matching object: +条件に一致するオブジェクトをアップロードし、削除します。 ```bash printf 'hello from RustFS\n' > hello.txt @@ -167,7 +167,7 @@ aws --endpoint-url http://localhost:9000 \ s3 rm s3://my-bucket/uploads/hello.dat ``` -The webhook receives an S3-compatible JSON envelope. Important fields include the event name, bucket, object key, size, ETag, and request identifiers: +Webhook は S3 互換の JSON エンベロープを受け取ります。重要なフィールドには、イベント名、バケット、オブジェクトキー、サイズ、ETag、リクエスト識別子があります。 ```json { @@ -184,13 +184,13 @@ The webhook receives an S3-compatible JSON envelope. Important fields include th } ``` -Decode the object key as URL-encoded data before using it. Consumers should also be idempotent: queued delivery provides store-and-forward recovery, but a receiver can observe the same event more than once. +オブジェクトキーは、使う前に URL エンコードされたデータとしてデコードします。あわせて、コンシューマーは冪等であることを推奨します。キュー経由の配信は蓄積転送による回復を提供しますが、受信側は同じイベントを複数回観測できます。 -### Replace or remove rules +### ルールを置き換える、または削除する -`PutBucketNotificationConfiguration` replaces the complete notification configuration for the bucket. Include every rule that you want to retain when updating it. +`PutBucketNotificationConfiguration` は、バケットの通知設定全体を置き換えます。更新するときは、残すルールをすべて含めます。 -Remove all rules by applying an empty configuration: +空の設定を適用して、すべてのルールを削除します。 ```bash aws --endpoint-url http://localhost:9000 \ @@ -200,6 +200,6 @@ aws --endpoint-url http://localhost:9000 \ --notification-configuration '{}' ``` -## Next steps +## 次のステップ -Configure [Audit Targets](/security-compliance/audit-logs) when you need request-level security and compliance records instead of bucket-scoped object events. Review [Observability](/operations/observability) to monitor the RustFS service. \ No newline at end of file +バケット単位のオブジェクトイベントではなく、リクエスト単位のセキュリティとコンプライアンスの記録が必要な場合は、[監査ターゲット](/ja/security-compliance/audit-logs)を設定します。RustFS サービスを監視するには、[オブザーバビリティ](/ja/operations/observability)を確認します。 diff --git a/content/ja/operations/high-availability/index.md b/content/ja/operations/high-availability/index.md index d274c255a..b1657d60c 100644 --- a/content/ja/operations/high-availability/index.md +++ b/content/ja/operations/high-availability/index.md @@ -1,7 +1,7 @@ --- -title: "High Availability" -description: "Review RustFS site replication and node recovery guidance." +title: "高可用性" +description: "RustFS のサイトレプリケーションとノード復旧の手順を確認します。" --- -- [Site Replication](./site-replication.md) -- [Node Healing](./node-healing.md) \ No newline at end of file +- [サイトレプリケーション](./site-replication.md) +- [ノードのデータ修復](./node-healing.md) diff --git a/content/ja/operations/high-availability/node-healing.md b/content/ja/operations/high-availability/node-healing.md index ef7bbd8f9..86513b8e7 100644 --- a/content/ja/operations/high-availability/node-healing.md +++ b/content/ja/operations/high-availability/node-healing.md @@ -1,52 +1,52 @@ --- -title: "Node Healing" -description: "Recover failed RustFS nodes and disks, monitor automatic healing, and run bounded manual heal tasks with rc." +title: "ノードのデータ修復" +description: "障害が発生した RustFS のノードとディスクを復旧し、自動のデータ修復を監視し、rc で範囲を限定した手動のデータ修復タスクを実行します。" --- -RustFS healing reconstructs missing or inconsistent erasure-coded data from the healthy shards that remain in a storage set. Use this workflow after restoring an unavailable node, replacing a failed disk, or investigating scanner and heal alerts. +RustFS のデータ修復は、ストレージセットに残っている正常なシャードから、欠落または不整合なイレイジャーコーディングのデータを再構築します。利用できないノードを復旧したあと、障害ディスクを交換したあと、またはスキャナーと heal のアラートを調べるときに、この手順を使います。 -Healing is a cluster storage operation. It is different from [site replication](/operations/high-availability/site-replication), which copies data and identity configuration between independent RustFS deployments. +データ修復は、クラスターのストレージ操作です。独立した RustFS デプロイのあいだでデータとアイデンティティ設定をコピーする [サイトレプリケーション](/ja/operations/high-availability/site-replication) とは別の機能です。 -:::warning[Healing is not a backup] +:::warning[データ修復はバックアップではない] -RustFS can reconstruct data only while enough healthy shards remain in the affected erasure set. Healing cannot recover an object after failures exceed the set's available redundancy, and it does not protect against intentional deletion or application-level corruption. Maintain independent backups or replication according to your recovery requirements. +RustFS がデータを再構築できるのは、影響を受けるイレイジャーセットに十分な正常シャードが残っているあいだだけです。障害がセットの利用可能な冗長性を超えたあと、データ修復でオブジェクトを復旧することはできません。意図的な削除や、アプリケーション層の破損からも保護しません。復旧要件に合わせて、独立したバックアップまたはレプリケーションを維持します。 ::: -## How healing works +## データ修復の仕組み -RustFS coordinates several healing sources through the cluster heal queue: +RustFS は、クラスターの heal キューを通じて、複数のデータ修復ソースを調整します。 -- `autoHeal`: The automatic disk scanner detects disks that are unformatted or have returned after an outage and queues erasure-set healing. -- `scanner`: The background data scanner can queue object and bucket healing when it finds inconsistent storage state. -- `readRepair`: Read-repair paths can submit work discovered while serving requests. -- `internal`: Internal recovery paths can submit system-initiated work. -- `admin`: Administrators can submit a recursive, bucket, or prefix heal with `rc admin heal start`. +- `autoHeal`: 自動ディスクスキャナーは、未フォーマットのディスク、または障害のあと復帰したディスクを検出し、イレイジャーセットのデータ修復をキューに入れます。 +- `scanner`: バックグラウンドのデータスキャナーは、不整合なストレージ状態を見つけると、オブジェクトとバケットのデータ修復をキューに入れることができます。 +- `readRepair`: read-repair の経路は、リクエストの処理中に見つかった作業を投入できます。 +- `internal`: 内部の復旧経路は、システムが開始した作業を投入できます。 +- `admin`: 管理者は `rc admin heal start` で、再帰、バケット、またはプレフィックスの heal を投入できます。 -Automatic disk healing runs at low priority. The `healOperations` status object uses these source names to separate queued, active, and retrying work. +自動のディスク修復は、低い優先度で実行されます。`healOperations` 状態オブジェクトは、これらのソース名を使って、キュー待ち、実行中、再試行中の作業を分けます。 -:::note[Reconstruction consumes cluster resources] +:::note[再構築はクラスターのリソースを消費する] -Healing reads healthy shards and writes reconstructed data. Deep scans add read and checksum work. Monitor client latency, disk utilization, available capacity, and the heal queue while recovery is active. +データ修復は正常なシャードを読み、再構築したデータを書き込みます。ディープスキャンは、読み取りとチェックサムの作業を追加します。復旧が進んでいるあいだ、クライアントのレイテンシ、ディスク使用率、空き容量、heal キューを監視します。 ::: -## Requirements +## 要件 -Before recovering a node or disk, prepare: +ノードまたはディスクを復旧する前に、次を準備します。 -- A RustFS deployment that still has enough healthy shards to reconstruct the affected data. -- Stable node addresses and the original configured storage mount paths. -- Replacement storage with capacity appropriate for the affected erasure set. -- The RustFS [`rc`](/operations/rc) client on a secured administration host. -- Administrative credentials that permit cluster information, scanner, and heal operations. -- A maintenance window when replacing hardware or running a deep recursive scan. +- 影響を受けるデータを再構築できるだけの正常シャードが残っている RustFS デプロイ。 +- 安定したノードアドレスと、当初設定したストレージのマウントパス。 +- 影響を受けるイレイジャーセットに見合う容量の交換用ストレージ。 +- 保護された管理ホスト上の RustFS [`rc`](/ja/operations/rc) クライアント。 +- クラスター情報、スキャナー、heal の操作を許可する管理用認証情報。 +- ハードウェアを交換するとき、または再帰的なディープスキャンを実行するときのメンテナンス時間。 -Record the failed node, pool, set, disk endpoint, mount path, and file-system UUID before changing hardware. Do not remove additional disks from the same erasure set while recovery is incomplete. +ハードウェアを変更する前に、障害ノード、プール、セット、ディスクエンドポイント、マウントパス、ファイルシステムの UUID を記録します。復旧が完了するまで、同じイレイジャーセットから別のディスクを取り外さないでください。 -## 1. Identify the failed component +## 1. 障害のあるコンポーネントを特定する -Configure an `rc` alias if you do not already have one: +まだなければ、`rc` のエイリアスを設定します。 ```bash rc alias set rustfs https://rustfs.example.com:9000 \ @@ -54,7 +54,7 @@ rc alias set rustfs https://rustfs.example.com:9000 \ --region us-east-1 --bucket-lookup path ``` -Check cluster readiness, topology, storage health, and heal activity: +クラスターの準備完了、トポロジ、ストレージの健全性、heal の活動を確認します。 ```bash rc ready rustfs @@ -64,35 +64,35 @@ rc admin scanner status rustfs rc admin heal status rustfs ``` -Readiness can fail while the cluster is degraded. Use the administrative information commands to identify which node or disk is unavailable and note its pool and erasure-set location. +クラスターが縮退しているあいだは、準備完了の確認が失敗することがあります。管理情報のコマンドを使い、利用できないノードまたはディスクを特定し、そのプールとイレイジャーセットの位置を控えます。 -For machine-readable output, request JSON: +機械可読の出力が必要な場合は、JSON を要求します。 ```bash rc --json admin info storage rustfs rc --json admin heal status rustfs ``` -The aggregate heal status reports runtime state, queued and active tasks, retrying work, request sources, priorities, and available progress counters. A zero-length queue does not prove that an offline disk has been replaced or that every object is recoverable; correlate it with storage topology and readiness. +集約された heal 状態は、実行時の状態、キュー待ちと実行中のタスク、再試行中の作業、リクエストのソース、優先度、利用可能な進捗カウンタを報告します。キューの長さが 0 でも、オフラインのディスクが交換されたことや、すべてのオブジェクトを復旧できることの証明にはなりません。ストレージのトポロジと準備完了の状態と突き合わせます。 -## 2. Restore the node or disk +## 2. ノードまたはディスクを復旧する -Correct the underlying failure before starting a manual heal. +手動 heal を始める前に、根本原因の障害を直します。 -For a node outage: +ノード障害の場合は、次の手順です。 -1. Restore the node's configured network identity and connectivity to every other RustFS node on the S3 API port, normally `9000`. -2. Mount the original data disks at their configured paths. -3. Confirm that the RustFS process uses the same storage endpoint configuration as the rest of the cluster. -4. Start RustFS and verify that the node rejoins the cluster. +1. ノードに設定されていたネットワーク識別情報を復旧し、S3 API ポート（通常は `9000`）で、他のすべての RustFS ノードと通信できる状態にします。 +2. 元のデータディスクを、設定されていたパスへマウントします。 +3. RustFS プロセスが、クラスターの他のノードと同じストレージエンドポイント設定を使っていることを確認します。 +4. RustFS を起動し、ノードがクラスターへ再参加したことを確認します。 -For a failed disk: +障害ディスクの場合は、次の手順です。 -1. Stop the RustFS process on the affected node before removing or remounting storage. -2. Replace the failed device and prepare its file system according to [Disk Preparation](/installation/requirement/disk-preparation). -3. Mount the replacement at the exact path used by the failed disk and update `/etc/fstab` with its file-system UUID. -4. Verify the mount, file-system type, ownership, and available capacity before starting RustFS. -5. Start RustFS and confirm that the disk appears in the expected pool and erasure set. +1. ストレージを取り外す、または再マウントする前に、影響を受けるノードの RustFS プロセスを停止します。 +2. 障害デバイスを交換し、[ディスクの準備](/ja/installation/requirement/disk-preparation)に従ってファイルシステムを準備します。 +3. 交換用ディスクを、障害ディスクが使っていたパスそのものへマウントし、`/etc/fstab` をそのファイルシステムの UUID で更新します。 +4. RustFS を起動する前に、マウント、ファイルシステムの種類、所有権、空き容量を確認します。 +5. RustFS を起動し、ディスクが想定したプールとイレイジャーセットに現れることを確認します。 ```bash findmnt /data/rustfs0 @@ -100,15 +100,15 @@ df -hT /data/rustfs0 rc admin info storage rustfs ``` -:::warning[Do not reuse stale storage blindly] +:::warning[古いストレージを確認せずに再利用しない] -Confirm the identity and contents of every device before mounting it at a RustFS data path. Do not copy internal metadata between disks, combine multiple configured endpoints on one replacement file system, or mount a replacement over a path that still contains required data. +RustFS のデータパスへマウントする前に、各デバイスの識別情報と内容を確認します。ディスク間で内部メタデータをコピーしないでください。設定済みの複数のエンドポイントを、1 つの交換用ファイルシステムにまとめないでください。必要なデータが残っているパスの上に、交換用ディスクをマウントしないでください。 ::: -## 3. Monitor automatic healing +## 3. 自動のデータ修復を監視する -After the node or replacement disk is online, RustFS can detect the recovery candidate and queue erasure-set healing. Check both storage state and aggregate heal activity: +ノードまたは交換ディスクがオンラインになったあと、RustFS は復旧候補を検出し、イレイジャーセットのデータ修復をキューに入れることができます。ストレージの状態と、集約された heal の活動の両方を確認します。 ```bash rc admin info storage rustfs @@ -116,24 +116,24 @@ rc admin heal status rustfs rc admin scanner status rustfs ``` -In JSON output, watch these groups: +JSON 出力では、次のグループを監視します。 -| Field | Meaning | +| フィールド | 意味 | | --- | --- | -| `state` | Heal runtime state, such as `active` or `idle`. | -| `healQueueLength` | Total work waiting in the heal queue. | -| `healActiveTasks` | Total heal tasks currently running. | -| `healOperations` | Queue, active, and retry counts grouped by source (`scanner`, `admin`, `autoHeal`, `internal`, and `readRepair`) and priority. | -| `progress` | Available totals for objects scanned, healed, failed, and bytes processed. | -| `clusterStatusComplete` | Whether the response includes every expected node. | +| `state` | `active` や `idle` などの、heal の実行時状態。 | +| `healQueueLength` | heal キューで待機している作業の合計。 | +| `healActiveTasks` | 現在実行中の heal タスクの合計。 | +| `healOperations` | ソース（`scanner`、`admin`、`autoHeal`、`internal`、`readRepair`）と優先度で分けた、キュー、実行中、再試行の件数。 | +| `progress` | スキャン済み、修復済み、失敗、処理済みバイト数について、利用できる合計。 | +| `clusterStatusComplete` | 応答が、想定されるすべてのノードを含むかどうか。 | -Do not treat `idle` as successful recovery by itself. Confirm that the replacement disk is online, no heal failures remain, the cluster is ready, and representative objects are readable. +`idle` であることだけを、復旧の成功と見なさないでください。交換ディスクがオンラインであること、heal の失敗が残っていないこと、クラスターが準備完了であること、代表的なオブジェクトが読めることを確認します。 -## 4. Run a targeted manual heal +## 4. 対象を絞った手動 heal を実行する -Use a manual task when automatic recovery does not cover the required path or when you need an explicit scan after an incident. Start with the narrowest bucket or prefix that contains affected data. +自動復旧が必要なパスをカバーしない場合、またはインシデントのあと明示的なスキャンが必要な場合に、手動タスクを使います。影響を受けたデータを含む、最も狭いバケットまたはプレフィックスから始めます。 -Preview a bucket heal without applying changes: +変更を適用せずに、バケット heal をプレビューします。 ```bash rc admin heal start rustfs \ @@ -142,7 +142,7 @@ rc admin heal start rustfs \ --dry-run ``` -Run the targeted heal after reviewing the preview: +プレビューを確認したあと、対象を絞った heal を実行します。 ```bash rc admin heal start rustfs \ @@ -150,7 +150,7 @@ rc admin heal start rustfs \ --scan-mode normal ``` -Limit the task to an object prefix when the affected scope is known: +影響範囲が分かっている場合は、オブジェクトプレフィックスにタスクを限定します。 ```bash rc admin heal start rustfs \ @@ -159,19 +159,19 @@ rc admin heal start rustfs \ --scan-mode deep ``` -`normal` is the default scan mode. Use `deep` when you need deeper data verification and have planned for the additional disk I/O. Omit `--bucket` only when a recursive scan of all buckets is necessary. +`normal` が既定のスキャンモードです。より深いデータ検証が必要で、追加のディスク I/O を見込んでいる場合に `deep` を使います。`--bucket` を省略するのは、すべてのバケットを再帰スキャンする必要がある場合だけです。 -:::warning[Review mutation options separately] +:::warning[変更オプションは別に確認する] -The `--remove` option removes dangling objects or parts, and `--recreate` requests recreation of missing data. Do not add either option to an incident command until you have inspected the affected storage state, tested with `--dry-run`, and confirmed the intended result. +`--remove` は孤立したオブジェクトまたはパートを削除し、`--recreate` は欠落データの再作成を要求します。影響を受けたストレージの状態を調べ、`--dry-run` で確認し、意図した結果だと確かめるまで、インシデント対応のコマンドにどちらのオプションも足さないでください。 ::: -## 5. Track the manual task +## 5. 手動タスクを追跡する -Every manual heal returns a `clientToken`. Save it with the incident record because status and stop operations for that task require the token. +手動 heal は毎回 `clientToken` を返します。そのタスクの状態確認と停止にはトークンが必要なため、インシデントの記録と一緒に保存します。 -For a bucket or prefix task, pass the original target and token: +バケットまたはプレフィックスのタスクでは、元の対象とトークンを渡します。 ```bash rc admin heal status rustfs \ @@ -180,23 +180,23 @@ rc admin heal status rustfs \ --client-token ``` -For a recursive task started without `--bucket`, use the token alone: +`--bucket` なしで開始した再帰タスクでは、トークンだけを使います。 ```bash rc admin heal status rustfs --client-token ``` -The tokenless command remains the cluster-wide background summary: +トークンを付けないコマンドは、これまでどおりクラスター全体のバックグラウンド概要を表示します。 ```bash rc admin heal status rustfs ``` -Task status can include scanned, healed, and failed item totals, bytes processed, the current item, scan mode, start time, and last update. Investigate failed items rather than relying only on the task's aggregate state. +タスクの状態には、スキャン済み、修復済み、失敗の項目合計、処理済みバイト数、現在の項目、スキャンモード、開始時刻、最終更新が含まれることがあります。タスクの集計状態だけに頼らず、失敗した項目を調べます。 -## 6. Validate recovery +## 6. 復旧を検証する -After the heal queue drains, verify the cluster and the recovered data path: +heal キューが空になったあと、クラスターと復旧したデータパスを検証します。 ```bash rc ready rustfs @@ -205,20 +205,20 @@ rc admin info storage rustfs rc admin heal status rustfs ``` -Read representative objects from affected buckets and versions. For a known test object: +影響を受けたバケットとバージョンから、代表的なオブジェクトを読みます。既知のテストオブジェクトの場合は次のとおりです。 ```bash rc object stat rustfs/my-bucket/hello.txt rc object copy rustfs/my-bucket/hello.txt ./hello-recovered.txt ``` -Compare the downloaded object with an independent checksum or trusted source when one is available. A successful object read validates that request, not every object or every shard in the cluster. +独立したチェックサム、または信頼できるソースがある場合は、ダウンロードしたオブジェクトと照合します。オブジェクトの読み取りが成功しても、検証されるのはそのリクエストだけです。クラスター内のすべてのオブジェクトや、すべてのシャードが検証されるわけではありません。 -Continue monitoring storage health and heal failures after the cluster becomes ready. Preserve the incident timeline, failed-device information, task token, and final status output for review. +クラスターが準備完了になったあとも、ストレージの健全性と heal の失敗を監視し続けます。インシデントの時系列、障害デバイスの情報、タスクのトークン、最終的な状態の出力を、レビュー用に残します。 -## 7. Stop a manual heal +## 7. 手動 heal を停止する -Stop only the task you have identified. For a bucket or prefix task, include the original target and token: +特定したタスクだけを停止します。バケットまたはプレフィックスのタスクでは、元の対象とトークンを含めます。 ```bash rc admin heal stop rustfs \ @@ -227,44 +227,44 @@ rc admin heal stop rustfs \ --client-token ``` -Stop a recursive token-scoped task with: +トークンで対象を限定した再帰タスクは、次のコマンドで停止します。 ```bash rc admin heal stop rustfs --client-token ``` -The tokenless stop command targets the global background heal operation: +トークンなしの停止コマンドは、グローバルなバックグラウンド heal を対象にします。 ```bash rc admin heal stop rustfs ``` -Use the global stop only when continued background work creates a larger operational risk. Stopping healing leaves recovery incomplete; record the reason and confirm how healing will resume before closing the incident. +グローバルな停止を使うのは、バックグラウンドの処理を続ける方が運用上のリスクが大きい場合だけです。データ修復を止めると、復旧は完了しないまま残ります。インシデントを閉じる前に、理由を記録し、データ修復をどのように再開するかを確認します。 -## Troubleshooting +## トラブルシューティング -### The replacement disk is not healing +### 交換ディスクでデータ修復が進まない -Confirm that the replacement is mounted at the configured endpoint and appears in `rc admin info storage`. Check the RustFS logs for disk identification, formatting, permission, or queue-admission failures. Also confirm that healing services are initialized with `rc admin heal status`. +交換用ディスクが、設定されたエンドポイントにマウントされ、`rc admin info storage` に現れることを確認します。RustFS のログで、ディスクの識別、フォーマット、権限、キュー受付の失敗を確認します。あわせて、`rc admin heal status` でデータ修復サービスが初期化されていることを確認します。 -### Heal status is partial +### heal の状態が部分的である -If `clusterStatusComplete` is false, one or more expected nodes did not contribute to the aggregate response. Restore node-to-node connectivity and check each node's storage and process health before trusting cluster totals. +`clusterStatusComplete` が false の場合、想定していたノードのうち 1 つ以上が、集約応答に含まれていません。クラスターの合計値を信頼する前に、ノード間の接続を復旧し、各ノードのストレージとプロセスの健全性を確認します。 -### The queue remains active +### キューが active のままである -Compare queued, active, and retrying work by source. A growing `autoHeal` count points to disk or erasure-set recovery; scanner work points to background discovery; admin work belongs to manually submitted tasks. Check disk latency, free capacity, node connectivity, and repeated item failures before starting another task. +ソースごとに、キュー待ち、実行中、再試行中の作業を比較します。`autoHeal` の件数が増えているときは、ディスクまたはイレイジャーセットの復旧を示します。スキャナーの作業は、バックグラウンドでの検出を示します。admin の作業は、手動で投入したタスクのものです。別のタスクを開始する前に、ディスクのレイテンシ、空き容量、ノード間の接続、項目の繰り返し失敗を確認します。 -### Objects cannot be reconstructed +### オブジェクトを再構築できない -Stop additional maintenance on the affected erasure set. Preserve the remaining disks and logs, then determine whether enough healthy shards survive. Repeated deep scans cannot reconstruct data when the available redundancy has already been exceeded. +影響を受けるイレイジャーセットに対する追加のメンテナンスを止めます。残っているディスクとログを保存し、十分な正常シャードが残っているかを判断します。利用できる冗長性をすでに超えている場合、ディープスキャンを繰り返してもデータは再構築できません。 -### A manual task cannot be queried +### 手動タスクを照会できない -Use the `clientToken` returned by `heal start`. Bucket and prefix tasks must be queried with the same `--bucket` and `--prefix` target used at start; a recursive root task uses the token without a bucket. +`heal start` が返した `clientToken` を使います。バケットとプレフィックスのタスクは、開始時と同じ `--bucket` と `--prefix` を指定して照会する必要があります。再帰的なルートタスクは、バケットを付けずトークンだけを使います。 -## Next steps +## 次のステップ -- Review [Status Check](/operations/status-check) for readiness, cluster, and capacity checks. -- Configure [Observability](/operations/observability) to alert on disk health and sustained recovery work. -- Review [Site Replication](/operations/high-availability/site-replication) when recovery requires an independent RustFS deployment. +- 準備完了、クラスター、容量の確認は [ステータスチェック](/ja/operations/status-check) を参照してください。 +- ディスクの健全性と、継続する復旧作業へのアラートは [オブザーバビリティ](/ja/operations/observability) で設定します。 +- 復旧に独立した RustFS デプロイが必要な場合は、[サイトレプリケーション](/ja/operations/high-availability/site-replication) を参照してください。 diff --git a/content/ja/operations/high-availability/site-replication.md b/content/ja/operations/high-availability/site-replication.md index fb7ff8a1f..62a68dfc5 100644 --- a/content/ja/operations/high-availability/site-replication.md +++ b/content/ja/operations/high-availability/site-replication.md @@ -1,51 +1,51 @@ --- -title: "Site Replication" -description: "Configure and operate multi-site RustFS replication with the rc command-line client." +title: "サイトレプリケーション" +description: "rc コマンドラインクライアントを使い、複数サイトの RustFS レプリケーションを設定して運用します。" --- -Site replication links two or more independent **RustFS** deployments. It synchronizes buckets, object versions, and supported identity and access management (IAM) data across the linked sites. Use this workflow when applications need to write to separate RustFS sites while keeping their storage and identity configuration aligned. +サイトレプリケーションは、2 つ以上の独立した **RustFS** デプロイを結びます。リンクしたサイトのあいだで、バケット、オブジェクトバージョン、対応しているアイデンティティとアクセス管理（IAM）のデータを同期します。アプリケーションが別々の RustFS サイトへ書き込みつつ、ストレージとアイデンティティの設定を揃えておく必要がある場合に、この手順を使います。 -Site replication is different from [bucket replication](/administration/data/bucket/replication). Bucket replication is a directional rule between selected buckets; site replication establishes a broader relationship between complete RustFS deployments. +サイトレプリケーションは [バケットレプリケーション](/ja/administration/data/bucket/replication) とは別です。バケットレプリケーションは、選択したバケットのあいだの、方向を持つルールです。サイトレプリケーションは、RustFS デプロイ全体のあいだに、より広い関係を作ります。 -:::warning[Plan recovery separately] +:::warning[復旧は別に計画する] -Site replication is asynchronous. A successful write at one site does not confirm that another site already has the replicated version. Site replication also does not provide DNS failover, traffic routing, or application recovery orchestration. +サイトレプリケーションは非同期です。一方のサイトで書き込みが成功しても、もう一方のサイトが複製されたバージョンをすでに持っていることにはなりません。サイトレプリケーションは、DNS フェイルオーバー、トラフィックの振り分け、アプリケーション復旧のオーケストレーションも提供しません。 ::: -## Replicated resources +## 複製されるリソース -RustFS site replication synchronizes these resource families across linked sites: +RustFS のサイトレプリケーションは、リンクしたサイトのあいだで次のリソース群を同期します。 -- Buckets and object versions, including delete markers. -- Bucket metadata required by the site replication workflow. -- IAM users, groups, policies, policy mappings, and service accounts. +- バケットとオブジェクトバージョン（削除マーカーを含む）。 +- サイトレプリケーションの処理に必要なバケットメタデータ。 +- IAM のユーザー、グループ、ポリシー、ポリシーのマッピング、サービスアカウント。 -Bucket versioning support is required at every participating site. RustFS configures the site relationship and the underlying replication targets when you add the sites. +参加するすべてのサイトで、バケットのバージョニングに対応している必要があります。サイトを追加すると、RustFS がサイト間の関係と、その基礎になるレプリケーションターゲットを設定します。 -## Requirements +## 要件 -Before linking sites, prepare: +サイトをリンクする前に、次を準備します。 -- Two or more independent RustFS deployments running a release that exposes the site replication Admin API. -- A unique, stable S3 API endpoint for each deployment. -- Bidirectional network connectivity between every site endpoint on the S3 API port, normally `9000`. -- Trusted TLS certificates for production endpoints. -- The RustFS [`rc`](/operations/rc) client on a secured administration host. -- Root administrative credentials for every participating site. -- Compatible bucket-versioning support on every site. +- サイトレプリケーションの Admin API を公開しているリリースで動作する、2 つ以上の独立した RustFS デプロイ。 +- 各デプロイに固有で安定した S3 API エンドポイント。 +- すべてのサイトエンドポイントのあいだで、S3 API ポート（通常は `9000`）の双方向ネットワーク接続。 +- 本番エンドポイント向けの、信頼された TLS 証明書。 +- 保護された管理ホスト上の RustFS [`rc`](/ja/operations/rc) クライアント。 +- 参加するすべてのサイトの、ルートの管理認証情報。 +- すべてのサイトで、互換性のあるバケットバージョニングの対応。 -Use empty test sites when first validating the workflow. Before linking existing sites, inventory bucket names, object-lock settings, IAM identities, and policies for conflicts. +手順を初めて検証するときは、空のテストサイトを使います。既存のサイトをリンクする前に、バケット名、オブジェクトロックの設定、IAM のアイデンティティ、ポリシーを洗い出し、競合がないか確認します。 -:::warning[Protect administrative credentials] +:::warning[管理用認証情報を保護する] -The `add` operation resolves every peer endpoint and root credential from your local `rc` alias store. Run it only from a trusted administration host, restrict access to the local `rc` configuration, and do not place credentials in shell history, logs, or screenshots. +`add` 操作は、ローカルの `rc` エイリアスストアから、すべてのピアエンドポイントとルート認証情報を解決します。信頼できる管理ホストだけで実行し、ローカルの `rc` 設定へのアクセスを制限し、認証情報をシェルの履歴、ログ、スクリーンショットに残さないでください。 ::: -## 1. Configure site aliases +## 1. サイトのエイリアスを設定する -Configure one alias for each site. Replace the endpoint and credentials for both deployments: +サイトごとにエイリアスを 1 つ設定します。両方のデプロイについて、エンドポイントと認証情報を置き換えます。 ```bash rc alias set site1 https://site1.example.com:9000 \ @@ -57,7 +57,7 @@ rc alias set site2 https://site2.example.com:9000 \ --region us-east-1 --bucket-lookup path ``` -Check that both sites are reachable and ready: +両方のサイトに到達でき、準備完了であることを確認します。 ```bash rc ready site1 @@ -66,48 +66,48 @@ rc admin info cluster site1 rc admin info cluster site2 ``` -Use HTTPS endpoints in production. If a site uses a private certificate authority, install that authority in the administration host's trust store before continuing. +本番では HTTPS のエンドポイントを使います。サイトがプライベート認証局を使う場合は、先にその認証局を管理ホストの信頼ストアへインストールします。 -:::warning[Loopback endpoints are for tests only] +:::warning[ループバックのエンドポイントはテスト専用] -RustFS rejects loopback replication targets by default as an outbound-request security control. The server option `RUSTFS_REPLICATION_ALLOW_LOOPBACK_TARGET=true` exists only for single-host development and automated tests. Never enable it in production. +RustFS は、送信リクエストのセキュリティ制御として、既定でループバックのレプリケーションターゲットを拒否します。サーバーオプション `RUSTFS_REPLICATION_ALLOW_LOOPBACK_TARGET=true` は、単一ホストでの開発と自動テストのためだけに存在します。本番では有効にしないでください。 ::: -## 2. Link the sites +## 2. サイトをリンクする -Submit all participating aliases in one command. The first alias receives the administration request: +参加するエイリアスを、すべて 1 つのコマンドで指定します。管理リクエストを受け取るのは、最初のエイリアスです。 ```bash rc admin replicate add site1 site2 ``` -To create a relationship with more than two sites, include every alias in the initial command: +3 サイト以上の関係を作る場合は、最初のコマンドにすべてのエイリアスを含めます。 ```bash rc admin replicate add site1 site2 site3 ``` -Do not run separate pairwise `add` commands to build the same multi-site relationship. +同じマルチサイトの関係を、ペアごとの `add` を別々に実行して作らないでください。 -Inspect the resulting configuration from at least two sites: +結果の設定を、少なくとも 2 つのサイトから確認します。 ```bash rc admin replicate info site1 rc admin replicate info site2 ``` -The output identifies each linked deployment by its deployment ID, site name, and endpoint. Save the deployment IDs because edit and resync operations can select a site by exact deployment ID or exact unique name. +出力は、リンクされた各デプロイを、デプロイ ID、サイト名、エンドポイントで識別します。edit と resync は、デプロイ ID の完全一致、または一意な名前の完全一致でサイトを選べます。デプロイ ID を保存します。 -## 3. Check replication status +## 3. レプリケーションの状態を確認する -Request the default bucket and IAM summaries: +既定のバケットと IAM の概要を要求します。 ```bash rc admin replicate status site1 ``` -Select specific status sections when investigating an issue: +問題を調査するときは、特定の状態セクションを選びます。 ```bash rc admin replicate status site1 --buckets @@ -115,11 +115,11 @@ rc admin replicate status site1 --users --groups --policies rc admin replicate status site1 --metrics ``` -Check status from each site. A healthy response from `site1` confirms that site's view of the relationship; it does not replace checking the other deployments. +各サイトから状態を確認します。`site1` からの正常な応答が示すのは、そのサイトから見た関係です。ほかのデプロイの確認に代わるものではありません。 -## 4. Validate data and IAM replication +## 4. データと IAM のレプリケーションを検証する -Create a test bucket and object at the first site: +最初のサイトで、テスト用のバケットとオブジェクトを作成します。 ```bash rc bucket create site1/my-bucket @@ -127,20 +127,20 @@ printf 'hello rustfs\n' > hello.txt rc object copy hello.txt site1/my-bucket/hello.txt ``` -Poll the second site until the object appears: +オブジェクトが現れるまで、2 番目のサイトをポーリングします。 ```bash rc object stat site2/my-bucket/hello.txt rc object copy site2/my-bucket/hello.txt ./hello-from-site2.txt ``` -Compare the downloaded content before treating the data path as validated: +データパスを検証済みと見なす前に、ダウンロードした内容を比較します。 ```bash cmp hello.txt hello-from-site2.txt ``` -For IAM validation, create a temporary user and attach a test policy at one site, then inspect the user and policy mapping at another site. Remove the temporary identity after validation: +IAM の検証では、一方のサイトで一時ユーザーを作成してテストポリシーを付与し、もう一方のサイトでユーザーとポリシーのマッピングを確認します。検証後に、一時アイデンティティを削除します。 ```bash rc admin user add site1 replication-test @@ -152,17 +152,17 @@ rc admin policy entities site2 --user replication-test rc admin user rm site1 replication-test ``` -Use a randomly generated temporary secret and do not reuse an application or administrator credential. +ランダムに生成した一時シークレットを使い、アプリケーションや管理者の認証情報は再利用しないでください。 -## 5. Edit a site +## 5. サイトを編集する -Use `edit` when a linked site's name, endpoint, or TLS trust settings change. First inspect the current deployment IDs and names: +リンクしたサイトの名前、エンドポイント、または TLS の信頼設定が変わるときに `edit` を使います。まず、現在のデプロイ ID と名前を確認します。 ```bash rc admin replicate info site1 ``` -Rename a site: +サイトの名前を変更します。 ```bash rc admin replicate edit site1 \ @@ -171,7 +171,7 @@ rc admin replicate edit site1 \ --yes ``` -Replace an endpoint and keep TLS verification enabled: +エンドポイントを置き換え、TLS 検証は有効のままにします。 ```bash rc admin replicate edit site1 \ @@ -181,7 +181,7 @@ rc admin replicate edit site1 \ --yes ``` -For a private certificate authority, provide a certificate-only PEM bundle: +プライベート認証局の場合は、証明書のみの PEM バンドルを指定します。 ```bash rc admin replicate edit site1 \ @@ -190,7 +190,7 @@ rc admin replicate edit site1 \ --yes ``` -Clear a previously configured custom CA when the endpoint moves to a certificate trusted by the system trust store: +エンドポイントが、システム信頼ストアで信頼される証明書へ移るときは、以前設定したカスタム CA を消去します。 ```bash rc admin replicate edit site1 \ @@ -200,11 +200,11 @@ rc admin replicate edit site1 \ --yes ``` -The endpoint must be an HTTP or HTTPS origin without a path, query, fragment, or embedded credentials. Prefer a trusted certificate over `--skip-tls-verify`. +エンドポイントは、パス、クエリ、フラグメント、埋め込まれた認証情報を含まない HTTP または HTTPS のオリジンである必要があります。`--skip-tls-verify` より、信頼された証明書を使います。 -## 6. Resynchronize a site +## 6. サイトを再同期する -Use resynchronization after repairing a site that was unavailable or when status checks show missing replicated state. Start a resync for one exact peer: +利用できなかったサイトを修復したあと、または状態確認で複製された状態の欠落が見つかったときに、再同期を使います。対象のピアを 1 つ厳密に指定して、resync を開始します。 ```bash rc admin replicate resync start site1 \ @@ -212,14 +212,14 @@ rc admin replicate resync start site1 \ --yes ``` -Read the last persisted resync snapshot: +最後に永続化された resync のスナップショットを読みます。 ```bash rc admin replicate resync status site1 \ --site ``` -Cancel the selected resync only when you have confirmed it should stop: +選択した resync をキャンセルするのは、停止すべきだと確認したときだけです。 ```bash rc admin replicate resync cancel site1 \ @@ -227,23 +227,23 @@ rc admin replicate resync cancel site1 \ --yes ``` -:::warning[Resync status is not live progress] +:::warning[resync の状態はライブの進捗ではない] -The current RustFS resync status endpoint returns the persisted result of the most recent start or cancel request. It does not inspect live workers, and its lifecycle state is reported as unknown. Start operations can overlap, cancellation is not idempotent, and a network timeout can leave the mutation outcome unknown. After an ambiguous result, inspect `replicate info`, `replicate status`, and the target data before issuing another mutation. +現在の RustFS の resync 状態エンドポイントが返すのは、直近の開始またはキャンセル要求を永続化した結果です。実行中のワーカーは調べず、ライフサイクル状態は unknown と報告されます。開始操作は重なることがあり、キャンセルは冪等ではなく、ネットワークのタイムアウトで変更の結果が不明になることがあります。結果が曖昧なときは、次の変更を発行する前に `replicate info`、`replicate status`、対象データを確認します。 ::: -## 7. Remove site replication +## 7. サイトレプリケーションを解除する -Removing a site changes the replication relationship. It does not provide an application cutover or prove that every queued object has arrived. Check status and preserve any required data before proceeding. +サイトを外すと、レプリケーションの関係が変わります。アプリケーションの切り替えにはならず、キューに入っていたオブジェクトがすべて到着した証明にもなりません。先に状態を確認し、必要なデータを残してから進めます。 -Remove one named site: +名前を指定して、1 つのサイトを外します。 ```bash rc admin replicate remove site1 --site site2-dr ``` -Repeat `--site` to remove multiple named sites in one request: +1 回の要求で、名前を指定したサイトを複数外すには、`--site` を繰り返します。 ```bash rc admin replicate remove site1 \ @@ -251,41 +251,41 @@ rc admin replicate remove site1 \ --site site3 ``` -Dissolve the complete site replication relationship: +サイトレプリケーションの関係をすべて解消します。 ```bash rc admin replicate remove site1 --all ``` -Verify the result from the remaining deployments: +残っているデプロイから、結果を確認します。 ```bash rc admin replicate info site1 rc admin replicate status site1 ``` -## Troubleshooting +## トラブルシューティング -### A peer endpoint is rejected +### ピアのエンドポイントが拒否される -Confirm that the endpoint is a reachable HTTP or HTTPS origin and does not resolve to loopback. For production, make every site reachable through its stable network address and keep the loopback override disabled. +エンドポイントが到達可能な HTTP または HTTPS のオリジンであり、ループバックへ解決されないことを確認します。本番では、各サイトを安定したネットワークアドレスで到達できるようにし、ループバックの上書きは無効のままにします。 -### TLS validation fails +### TLS 検証が失敗する -Confirm that the endpoint certificate contains the peer hostname and that the issuing certificate authority is trusted. Use `replicate edit --ca-cert` for a private CA bundle. Do not make `--skip-tls-verify` the permanent fix. +エンドポイント証明書にピアのホスト名が含まれ、発行した認証局が信頼されていることを確認します。プライベート CA のバンドルには `replicate edit --ca-cert` を使います。`--skip-tls-verify` を恒久的な対処にしないでください。 -### A mutation times out +### 変更がタイムアウトする -Do not immediately repeat `add`, `edit`, `resync start`, `resync cancel`, or `remove`. The server may have applied the change before the client lost the response. Inspect the relationship and data first: +`add`、`edit`、`resync start`、`resync cancel`、`remove` をすぐには繰り返さないでください。クライアントが応答を失う前に、サーバー側で変更が適用されていることがあります。まず関係とデータを確認します。 ```bash rc admin replicate info site1 rc admin replicate status site1 ``` -### Replication falls behind +### レプリケーションが遅れる -Check the site status and metrics from every deployment, then verify endpoint reachability and storage readiness: +すべてのデプロイからサイトの状態とメトリクスを確認し、そのあとエンドポイントへの到達性と、ストレージの準備完了を検証します。 ```bash rc admin replicate status site1 --metrics @@ -293,10 +293,10 @@ rc ready site1 rc ready site2 ``` -Application writes can outpace asynchronous replication. Do not infer a recovery point objective from a single status sample; measure lag under your workload and alert on sustained backlog. +アプリケーションの書き込みが、非同期レプリケーションより速くなることがあります。状態を 1 回見ただけで、目標復旧時点（RPO）を判断しないでください。実際のワークロードで遅延を測り、バックログが続く場合はアラートします。 -## Next steps +## 次のステップ -- Review [Bucket Replication](/administration/data/bucket/replication) when you need directional replication for selected buckets instead of a complete site relationship. -- Monitor [cluster status and readiness](/operations/status-check) at every site. -- Review the [`rc` command guide](/operations/rc) and keep the client aligned with the RustFS server release. \ No newline at end of file +- サイト全体の関係ではなく、選択したバケットの方向付きレプリケーションが必要な場合は、[バケットレプリケーション](/ja/administration/data/bucket/replication) を参照してください。 +- すべてのサイトで、[クラスターの状態と準備完了](/ja/operations/status-check) を監視します。 +- [`rc` コマンドガイド](/ja/operations/rc) を確認し、クライアントを RustFS サーバーのリリースに合わせます。 diff --git a/content/ja/operations/index.md b/content/ja/operations/index.md index a7bd20cca..86d4a563d 100644 --- a/content/ja/operations/index.md +++ b/content/ja/operations/index.md @@ -1,16 +1,16 @@ --- -title: "Operations & Observability" -description: "Operate, monitor, scale, upgrade, and troubleshoot RustFS deployments." +title: "運用" +description: "RustFS のデプロイに対する運用、監視、スケーリング、アップグレード、トラブルシューティングを説明します。" --- -Use this section to keep RustFS deployments healthy through upgrades, scaling, availability planning, monitoring, and incident response. +このセクションでは、アップグレード、スケーリング、可用性の計画、監視、インシデント対応を通じて、RustFS のデプロイを健全な状態に保ちます。 -## Operational areas +## 運用領域 -- [Upgrade](./upgrade/index.md) covers binary, container, and Kubernetes upgrades. -- [Scaling](./scaling/index.md) covers storage expansion, rebalancing, and decommissioning. -- [High Availability](./high-availability/index.md) covers node healing and site replication. -- [Cluster Lifecycle Operations](./cluster-lifecycle.md) covers layout boundaries, quorum, expansion, rebalancing, decommissioning, healing, and restarts in one runbook. -- [Observability](./observability.md) covers metrics, logs, traces, monitoring integrations, and alert signals. -- [Status Check](./status-check.md) covers network ports, health probes, cluster status, and storage capacity checks. -- [Event Notifications](./event-notifications.md) covers bucket event targets. \ No newline at end of file +- [アップグレード](./upgrade/index.md)では、バイナリ、コンテナ、Kubernetes のアップグレードを扱います。 +- [スケーリング](./scaling/index.md)では、ストレージの拡張、リバランス、デコミッションを扱います。 +- [高可用性](./high-availability/index.md)では、ノードのデータ修復とサイトレプリケーションを扱います。 +- [クラスターのライフサイクル運用](./cluster-lifecycle.md)では、レイアウトの境界、クォーラム、拡張、リバランス、デコミッション、データ修復、再起動を 1 つの手順書にまとめています。 +- [オブザーバビリティ](./observability.md)では、メトリクス、ログ、トレース、監視連携、アラートのシグナルを扱います。 +- [ステータス確認](./status-check.md)では、ネットワークポート、ヘルスチェックのプローブ、クラスターの状態、ストレージ容量の確認を扱います。 +- [イベント通知](./event-notifications.md)では、バケットイベントのターゲットを扱います。 diff --git a/content/ja/operations/observability.md b/content/ja/operations/observability.md index b0531ca3a..c85788654 100644 --- a/content/ja/operations/observability.md +++ b/content/ja/operations/observability.md @@ -1,11 +1,11 @@ --- -title: "Observability" -description: "This article explains RustFS telemetry exports, monitoring integrations, metric names and labels, recommended alerts, and log collection." +title: "オブザーバビリティ" +description: "OTLP で RustFS のメトリクス、トレース、ログをエクスポートし、監視ツールと連携して、推奨アラートを設定する方法を説明します。" --- -## How RustFS Exposes Telemetry +## テレメトリの公開方法 -RustFS **pushes** metrics, traces, and logs over OTLP (OpenTelemetry Protocol). It does **not** expose a native Prometheus `/metrics` scrape endpoint — there is no HTTP route on port 9000 or 9001 that serves Prometheus text format. To get RustFS metrics into Prometheus you must run an OpenTelemetry Collector that receives OTLP from RustFS and re-exposes the data in Prometheus format: +RustFS は、メトリクス、トレース、ログを OTLP（OpenTelemetry Protocol）で**プッシュします**。ネイティブの Prometheus `/metrics` スクレイプエンドポイントは**公開しません**。ポート 9000 と 9001 のどちらにも、Prometheus のテキスト形式を返す HTTP ルートはありません。RustFS のメトリクスを Prometheus へ取り込むには、RustFS から OTLP を受信し、データを Prometheus 形式で再公開する OpenTelemetry Collector を実行する必要があります。 ```text RustFS (RUSTFS_OBS_ENDPOINT) --OTLP--> OpenTelemetry Collector --> Prometheus --> Grafana @@ -13,27 +13,27 @@ RustFS (RUSTFS_OBS_ENDPOINT) --OTLP--> OpenTelemetry Collector --> Prometheus -- \--> Tempo / Jaeger (traces) ``` -Point RustFS at the Collector with: +Collector の宛先は、次のように指定します。 ```bash # OTLP over HTTP (the Collector's default HTTP receiver port is 4318; gRPC is 4317) RUSTFS_OBS_ENDPOINT=http://otel-collector:4318 ``` -Related environment variables (all defined in the server configuration): +関連する環境変数（いずれもサーバー設定で定義されています）は次のとおりです。 -| Variable | Purpose | +| 変数 | 用途 | | --- | --- | -| `RUSTFS_OBS_ENDPOINT` | Base OTLP endpoint for traces, metrics, and logs | -| `RUSTFS_OBS_TRACE_ENDPOINT` / `RUSTFS_OBS_METRIC_ENDPOINT` / `RUSTFS_OBS_LOG_ENDPOINT` | Per-signal endpoint overrides | -| `RUSTFS_OBS_METRICS_EXPORT_ENABLED` / `RUSTFS_OBS_TRACES_EXPORT_ENABLED` / `RUSTFS_OBS_LOGS_EXPORT_ENABLED` | Toggle each signal | -| `RUSTFS_OBS_METER_INTERVAL` | Metric export interval | -| `RUSTFS_OBS_SERVICE_NAME` / `RUSTFS_OBS_ENVIRONMENT` | Resource attributes attached to exported telemetry | -| `RUSTFS_OBS_LOGGER_LEVEL` | Log verbosity (e.g. `info`) | +| `RUSTFS_OBS_ENDPOINT` | トレース、メトリクス、ログのベースとなる OTLP エンドポイント | +| `RUSTFS_OBS_TRACE_ENDPOINT` / `RUSTFS_OBS_METRIC_ENDPOINT` / `RUSTFS_OBS_LOG_ENDPOINT` | シグナルごとのエンドポイント上書き | +| `RUSTFS_OBS_METRICS_EXPORT_ENABLED` / `RUSTFS_OBS_TRACES_EXPORT_ENABLED` / `RUSTFS_OBS_LOGS_EXPORT_ENABLED` | 各シグナルのエクスポートを切り替える | +| `RUSTFS_OBS_METER_INTERVAL` | メトリクスのエクスポート間隔 | +| `RUSTFS_OBS_SERVICE_NAME` / `RUSTFS_OBS_ENVIRONMENT` | エクスポートするテレメトリに付けるリソース属性 | +| `RUSTFS_OBS_LOGGER_LEVEL` | ログの詳細度（例: `info`） | -## Reference Deployment (Docker Compose Observability Profile) +## 参照デプロイ（Docker Compose の Observability プロファイル） -The upstream `rustfs/rustfs` repository ships a complete reference stack in `docker-compose.yml` behind the `observability` profile: **otel-collector**, **Prometheus**, **Grafana**, **Loki** (logs), **Tempo** and **Jaeger** (traces). Its Collector configuration receives OTLP on 4317 (gRPC) and 4318 (HTTP) and re-exports metrics for Prometheus on port `8889`: +アップストリームの `rustfs/rustfs` リポジトリは、`docker-compose.yml` の `observability` プロファイル配下に、参照用スタック一式を同梱しています。構成は **otel-collector**、**Prometheus**、**Grafana**、**Loki**（ログ）、**Tempo** と **Jaeger**（トレース）です。Collector の設定は 4317（gRPC）と 4318（HTTP）で OTLP を受信し、Prometheus 向けにポート `8889` でメトリクスを再エクスポートします。 ```yaml # OpenTelemetry Collector (excerpt from the upstream reference config) @@ -54,7 +54,7 @@ service: exporters: [prometheus] ``` -Prometheus then scrapes the Collector, not RustFS: +Prometheus は RustFS をスクレイプせず、Collector をスクレイプします。 ```yaml # prometheus.yml (excerpt) @@ -69,150 +69,150 @@ scrape_configs: :::note -If Prometheus shows no `rustfs_*` series, check the chain in order: is `RUSTFS_OBS_ENDPOINT` set on every node, is the Collector reachable from the nodes, and is Prometheus scraping the Collector's `8889` exporter port. +Prometheus に `rustfs_*` の系列が出ない場合は、次の順で経路を確認します。すべてのノードに `RUSTFS_OBS_ENDPOINT` が設定されているか、ノードから Collector へ到達できるか、Prometheus が Collector の `8889` エクスポーターポートをスクレイプしているかです。 ::: -## Metrics Reference +## メトリクスリファレンス -Every name below is verified against the server source. The list covers the operations-relevant subset exported via OTLP; internal and experimental instruments are omitted, and new releases may add metrics not listed here. Label sets are those recorded at the emission site. The Collector and Prometheus may attach additional resource labels, such as `service_name` and instance. +以下の名前は、いずれもサーバーのソースコードに照らして確認済みです。一覧は、OTLP でエクスポートされる運用に関係するサブセットです。内部向けと実験的な計器は省略しており、新しいリリースではここにないメトリクスが追加されることがあります。ラベルセットは、メトリクスを出力する箇所で記録されるものです。Collector と Prometheus は、`service_name` や instance などのリソースラベルを追加することがあります。 -### Readiness and Process +### 準備完了とプロセス -| Metric | Type | Labels | Meaning | +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_start_total` | counter | — | Process starts; a rising rate indicates restart loops | -| `rustfs_runtime_readiness_ready` | gauge | — | `1` when the node is fully ready, `0` while degraded | -| `rustfs_runtime_readiness_degraded_total` | counter | `reason` | Degraded readiness evaluations, by `degradedReasons` value (e.g. `storage_quorum_unavailable`) | +| `rustfs_start_total` | counter | — | プロセスの起動回数。増加率が上がっている場合は、再起動ループを示します | +| `rustfs_runtime_readiness_ready` | gauge | — | ノードが完全に準備完了のとき `1`、劣化している間は `0` | +| `rustfs_runtime_readiness_degraded_total` | counter | `reason` | 準備完了が劣化した評価の回数。`degradedReasons` の値ごと（例: `storage_quorum_unavailable`） | -### Scanner +### スキャナー -| Metric | Type | Labels | Meaning | +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_scanner_objects_scanned_total` | counter | — | Objects visited by the background scanner | -| `rustfs_scanner_directories_scanned_total` | counter | — | Directories visited | -| `rustfs_scanner_buckets_scanned_total` | counter | `result`, `bucket`, `disk` | Bucket/drive scans completed, by outcome (`success` / `error` / `partial`) | -| `rustfs_scanner_cycles_total` | counter | `result` | Scanner cycles finished (`success` / `error` / `partial` / `unknown`) | -| `rustfs_scanner_cycle_duration_seconds` | gauge | — | Duration of the last completed scan cycle | -| `rustfs_scanner_bucket_drive_duration_seconds` | histogram | `bucket`, `disk` | Time to scan one bucket on one drive | -| `rustfs_scanner_leader_lock_total` | counter | `state` | Scanner leader-lock acquisition events | -| `rustfs_scanner_inline_heal_total` | counter | — | Objects queued for heal directly by the scanner | -| `rustfs_scanner_cache_save_duration_seconds` | histogram | `cache` | Time to persist the data-usage cache | -| `rustfs_scanner_set_scan_concurrency_limit` | gauge | — | Current per-set scan concurrency limit | -| `rustfs_scanner_disk_scan_concurrency_limit` | gauge | `pool`, `set` | Current per-disk scan concurrency limit | - -### Heal - -| Metric | Type | Labels | Meaning | +| `rustfs_scanner_objects_scanned_total` | counter | — | バックグラウンドスキャナーが走査したオブジェクト数 | +| `rustfs_scanner_directories_scanned_total` | counter | — | 走査したディレクトリ数 | +| `rustfs_scanner_buckets_scanned_total` | counter | `result`, `bucket`, `disk` | 完了したバケットとドライブのスキャン数。結果ごと（`success` / `error` / `partial`） | +| `rustfs_scanner_cycles_total` | counter | `result` | 完了したスキャナーのサイクル（`success` / `error` / `partial` / `unknown`） | +| `rustfs_scanner_cycle_duration_seconds` | gauge | — | 最後に完了したスキャンサイクルの所要時間 | +| `rustfs_scanner_bucket_drive_duration_seconds` | histogram | `bucket`, `disk` | 1 つのドライブ上で 1 つのバケットをスキャンする時間 | +| `rustfs_scanner_leader_lock_total` | counter | `state` | スキャナーのリーダーロック取得イベント | +| `rustfs_scanner_inline_heal_total` | counter | — | スキャナーが直接、データ修復のキューへ入れたオブジェクト数 | +| `rustfs_scanner_cache_save_duration_seconds` | histogram | `cache` | データ使用量キャッシュの永続化にかかった時間 | +| `rustfs_scanner_set_scan_concurrency_limit` | gauge | — | セットあたりの、現在のスキャン同時実行数の上限 | +| `rustfs_scanner_disk_scan_concurrency_limit` | gauge | `pool`, `set` | ディスクあたりの、現在のスキャン同時実行数の上限 | + +### データ修復 + +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_heal_task_running` | gauge | `type`, `set` | Currently running heal tasks per erasure set | -| `rustfs_heal_task_start_total` | counter | `type`, `set` | Heal tasks started | -| `rustfs_heal_queue_delay_seconds` | histogram | `type`, `set` | Time a heal task waited in queue before starting | -| `rustfs_heal_admission_total` | counter | `source`, `result`, `reason`, `context` | Heal admission decisions (accepted / rejected and why) | -| `rustfs_heal_mainline_throttle_total` | counter | `source`, `result`, `reason` | Background heal throttled to protect foreground traffic | -| `rustfs_heal_scheduler_skip_total` | counter | `reason`, `set` | Heal scheduling skipped (e.g. per-set limit reached) | -| `rustfs_heal_page_concurrency_current` | gauge | — | Current page-level heal concurrency | -| `rustfs_heal_candidate_enqueue_total` | counter | — | Heal candidates enqueued by the scanner | -| `rustfs_heal_candidate_merge_total` | counter | — | Candidates merged with an existing queue entry | -| `rustfs_heal_candidate_drop_total` | counter | — | Candidates dropped | -| `rustfs_heal_candidate_priority_reject_total` | counter | — | Candidates rejected by priority policy | -| `rustfs_heal_read_repair_dedup_total` | counter | `reason` | Read-path repair requests deduplicated | - -### API / IO Path - -| Metric | Type | Labels | Meaning | +| `rustfs_heal_task_running` | gauge | `type`, `set` | イレイジャーセットごとに、現在実行中のデータ修復タスク | +| `rustfs_heal_task_start_total` | counter | `type`, `set` | 開始されたデータ修復タスク | +| `rustfs_heal_queue_delay_seconds` | histogram | `type`, `set` | データ修復タスクが開始前にキューで待機した時間 | +| `rustfs_heal_admission_total` | counter | `source`, `result`, `reason`, `context` | データ修復の受付判定（受理または拒否と、その理由） | +| `rustfs_heal_mainline_throttle_total` | counter | `source`, `result`, `reason` | フォアグラウンドのトラフィックを守るため抑制された、バックグラウンドのデータ修復 | +| `rustfs_heal_scheduler_skip_total` | counter | `reason`, `set` | スキップされたデータ修復のスケジューリング（例: セットあたりの上限に到達） | +| `rustfs_heal_page_concurrency_current` | gauge | — | 現在の、ページ単位のデータ修復の同時実行数 | +| `rustfs_heal_candidate_enqueue_total` | counter | — | スキャナーがキューへ入れたデータ修復の候補 | +| `rustfs_heal_candidate_merge_total` | counter | — | 既存のキュー項目へマージされた候補 | +| `rustfs_heal_candidate_drop_total` | counter | — | 破棄された候補 | +| `rustfs_heal_candidate_priority_reject_total` | counter | — | 優先度ポリシーによって拒否された候補 | +| `rustfs_heal_read_repair_dedup_total` | counter | `reason` | 重複排除された、読み取りパスの修復リクエスト | + +### API／IO パス + +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_io_get_object_request_duration_seconds` | histogram | `status` | End-to-end GetObject latency | -| `rustfs_io_get_object_stage_duration_seconds` | histogram | `path`, `stage` | GetObject latency broken down by internal stage | -| `rustfs_io_get_object_response_size_bytes` | histogram | — | GetObject response sizes | -| `rustfs_io_operation_duration_seconds` | histogram | `operation` | Duration of IO operations | -| `rustfs_io_timeout_events_total` | counter | `operation` | IO operations that hit a timeout | -| `rustfs_operation_progress` | gauge | `operation` | Progress percentage of long-running operations | -| `rustfs_operation_stalled` | counter | `operation` | Operations detected as stalled | -| `rustfs_operation_completions` | counter | `operation`, `status` | Operation completions by status | -| `rustfs_io_queue_operations` | counter | `operation`, `priority` | IO queue enqueue/dequeue operations | -| `rustfs_io_queue_size` | gauge | `priority` | Current IO queue depth per priority | -| `rustfs_io_starvation_events` | counter | `priority` | Low-priority IO starvation events | -| `rustfs_io_bandwidth_bps` | gauge | — | Observed IO bandwidth (bytes/s) | -| `rustfs_io_scheduler_decisions` | counter | — | IO scheduler decisions taken | -| `rustfs_io_scheduler_load` | counter | `level` | Scheduler decisions by load level | -| `rustfs_io_load_changes` | counter | `from`, `to` | IO load-level transitions | - -### Backpressure - -| Metric | Type | Labels | Meaning | +| `rustfs_io_get_object_request_duration_seconds` | histogram | `status` | GetObject のエンドツーエンドのレイテンシ | +| `rustfs_io_get_object_stage_duration_seconds` | histogram | `path`, `stage` | 内部ステージ別に分解した GetObject のレイテンシ | +| `rustfs_io_get_object_response_size_bytes` | histogram | — | GetObject のレスポンスサイズ | +| `rustfs_io_operation_duration_seconds` | histogram | `operation` | IO 操作の所要時間 | +| `rustfs_io_timeout_events_total` | counter | `operation` | タイムアウトした IO 操作 | +| `rustfs_operation_progress` | gauge | `operation` | 長時間実行される操作の進捗率 | +| `rustfs_operation_stalled` | counter | `operation` | 停滞として検出された操作 | +| `rustfs_operation_completions` | counter | `operation`, `status` | ステータス別の操作完了数 | +| `rustfs_io_queue_operations` | counter | `operation`, `priority` | IO キューのエンキューとデキュー | +| `rustfs_io_queue_size` | gauge | `priority` | 優先度ごとの、現在の IO キュー深度 | +| `rustfs_io_starvation_events` | counter | `priority` | 低優先度 IO の枯渇イベント | +| `rustfs_io_bandwidth_bps` | gauge | — | 観測された IO 帯域（バイト/秒） | +| `rustfs_io_scheduler_decisions` | counter | — | 実行された IO スケジューラの判定 | +| `rustfs_io_scheduler_load` | counter | `level` | 負荷レベル別のスケジューラ判定 | +| `rustfs_io_load_changes` | counter | `from`, `to` | IO 負荷レベルの遷移 | + +### バックプレッシャー + +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_backpressure_state_changes` | counter | `from`, `to` | Backpressure state transitions | -| `rustfs_backpressure_activations` | counter | — | Times backpressure engaged | -| `rustfs_backpressure_deactivations` | counter | — | Times backpressure released | -| `rustfs_backpressure_rejections` | counter | — | Requests rejected due to backpressure | -| `rustfs_backpressure_concurrent` | gauge | — | Current concurrent requests tracked by the limiter | +| `rustfs_backpressure_state_changes` | counter | `from`, `to` | バックプレッシャー状態の遷移 | +| `rustfs_backpressure_activations` | counter | — | バックプレッシャーが働いた回数 | +| `rustfs_backpressure_deactivations` | counter | — | バックプレッシャーが解除された回数 | +| `rustfs_backpressure_rejections` | counter | — | バックプレッシャーにより拒否されたリクエスト | +| `rustfs_backpressure_concurrent` | gauge | — | リミッターが追跡している、現在の同時リクエスト数 | -### Capacity +### 容量 -| Metric | Type | Labels | Meaning | +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_capacity_current_bytes` | gauge | — | Current used capacity in bytes | -| `rustfs_capacity_update_total` | counter | `source` | Capacity recalculations | -| `rustfs_capacity_update_duration_seconds` | histogram | `source` | Time to recalculate capacity | -| `rustfs_capacity_cache_hits` | counter | — | Capacity cache hits | -| `rustfs_capacity_cache_misses` | counter | — | Capacity cache misses | -| `rustfs_capacity_cache_served_total` | counter | `state` | Capacity responses served from cache, by freshness state | +| `rustfs_capacity_current_bytes` | gauge | — | 現在の使用済み容量（バイト） | +| `rustfs_capacity_update_total` | counter | `source` | 容量の再計算回数 | +| `rustfs_capacity_update_duration_seconds` | histogram | `source` | 容量の再計算にかかった時間 | +| `rustfs_capacity_cache_hits` | counter | — | 容量キャッシュのヒット | +| `rustfs_capacity_cache_misses` | counter | — | 容量キャッシュのミス | +| `rustfs_capacity_cache_served_total` | counter | `state` | キャッシュから返した容量の応答。鮮度の状態ごと | -### Locking +### ロック -| Metric | Type | Labels | Meaning | +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_lock_contentions` | counter | — | Lock contention events | -| `rustfs_lock_hold_time_secs` | histogram | — | How long locks were held | -| `rustfs_lock_spin_successes` / `rustfs_lock_spin_failures` | counter | — | Spin-lock acquisition outcomes | -| `rustfs_lock_early_releases` | counter | — | Locks released early by optimization | -| `rustfs_object_lock_diag_acquire_duration_seconds` | histogram | — | Object-lock acquire latency (diagnostics mode) | -| `rustfs_object_lock_diag_hold_duration_seconds` | histogram | — | Object-lock hold duration (diagnostics mode) | -| `rustfs_object_lock_diag_slow_acquire_total` / `rustfs_object_lock_diag_slow_hold_total` | counter | — | Slow lock acquire/hold events (diagnostics mode) | +| `rustfs_lock_contentions` | counter | — | ロック競合のイベント | +| `rustfs_lock_hold_time_secs` | histogram | — | ロックを保持していた時間 | +| `rustfs_lock_spin_successes` / `rustfs_lock_spin_failures` | counter | — | スピンロック取得の結果 | +| `rustfs_lock_early_releases` | counter | — | 最適化によって早期に解放されたロック | +| `rustfs_object_lock_diag_acquire_duration_seconds` | histogram | — | オブジェクトロックの取得レイテンシ（診断モード） | +| `rustfs_object_lock_diag_hold_duration_seconds` | histogram | — | オブジェクトロックの保持時間（診断モード） | +| `rustfs_object_lock_diag_slow_acquire_total` / `rustfs_object_lock_diag_slow_hold_total` | counter | — | 取得または保持が遅かったロックのイベント（診断モード） | -### Log Cleaner +### ログクリーナー -| Metric | Type | Labels | Meaning | +| メトリクス | タイプ | ラベル | 意味 | | --- | --- | --- | --- | -| `rustfs_log_cleaner_runs_total` | counter | — | Log-cleaner runs | -| `rustfs_log_cleaner_deleted_files_total` | counter | — | Log files deleted | -| `rustfs_log_cleaner_freed_bytes_total` | counter | — | Bytes reclaimed | -| `rustfs_log_cleaner_rotation_total` / `rustfs_log_cleaner_rotation_failures_total` | counter | — | Log rotations and rotation failures | -| `rustfs_log_cleaner_rotation_duration_seconds` | histogram | — | Rotation duration | -| `rustfs_log_cleaner_active_file_size_bytes` | gauge | — | Size of the active log file | +| `rustfs_log_cleaner_runs_total` | counter | — | ログクリーナーの実行回数 | +| `rustfs_log_cleaner_deleted_files_total` | counter | — | 削除されたログファイル数 | +| `rustfs_log_cleaner_freed_bytes_total` | counter | — | 回収したバイト数 | +| `rustfs_log_cleaner_rotation_total` / `rustfs_log_cleaner_rotation_failures_total` | counter | — | ログのローテーションとその失敗 | +| `rustfs_log_cleaner_rotation_duration_seconds` | histogram | — | ローテーションの所要時間 | +| `rustfs_log_cleaner_active_file_size_bytes` | gauge | — | アクティブなログファイルのサイズ | -:::note[Additional metrics] +:::note[追加のメトリクス] -Additional verified metric names exist whose type/label details are not documented here, including `rustfs_scanner_cache_save_attempt_total`, `rustfs_scanner_cache_save_timeout_total`, `rustfs_scanner_cache_save_retry_total`, `rustfs_scanner_excess_object_versions_total`, `rustfs_scanner_excess_object_version_size_total`, `rustfs_scanner_excess_folders_total`, `rustfs_scanner_pending_heal_prune_total`, `rustfs_scanner_pending_heal_malformed_total`, and the `rustfs_io_scheduler_*` / `rustfs_io_buffer_*` / `rustfs_timeout_dynamic_*` families. Inspect them in Prometheus once the pipeline is live. +型やラベルの詳細をここでは文書化していない、確認済みのメトリクス名がほかにもあります。対象は `rustfs_scanner_cache_save_attempt_total`、`rustfs_scanner_cache_save_timeout_total`、`rustfs_scanner_cache_save_retry_total`、`rustfs_scanner_excess_object_versions_total`、`rustfs_scanner_excess_object_version_size_total`、`rustfs_scanner_excess_folders_total`、`rustfs_scanner_pending_heal_prune_total`、`rustfs_scanner_pending_heal_malformed_total`、および `rustfs_io_scheduler_*` / `rustfs_io_buffer_*` / `rustfs_timeout_dynamic_*` の系統です。パイプラインが稼働したら、Prometheus で確認します。 ::: -## Suggested Alerts +## 推奨アラート -| Alert | Signal | Suggested rule | +| アラート | シグナル | 推奨ルール | | --- | --- | --- | -| Node not ready > 2 min | `rustfs_runtime_readiness_ready` gauge, or an external probe on `GET /health/ready` returning non-200 | `rustfs_runtime_readiness_ready == 0` for `2m` | -| Restart loop | `rustfs_start_total` | `increase(rustfs_start_total[10m]) > 3` | -| Heal backlog growing | `rustfs_heal_task_running` and `rustfs_heal_queue_delay_seconds` | sustained non-zero running tasks plus rising queue delay for `30m` | -| Scanner stalled | `rustfs_scanner_cycles_total` | `increase(rustfs_scanner_cycles_total[24h]) == 0` | -| Cluster used capacity watermark | `rustfs_capacity_current_bytes` | compare against your deployed raw capacity (a constant you set), e.g. `rustfs_capacity_current_bytes > 0.8 * ` | +| ノードが 2 分を超えて準備完了でない | `rustfs_runtime_readiness_ready` ゲージ、または `GET /health/ready` への外部プローブが 200 以外を返す | `2m` の間 `rustfs_runtime_readiness_ready == 0` | +| 再起動ループ | `rustfs_start_total` | `increase(rustfs_start_total[10m]) > 3` | +| データ修復のバックログが増加 | `rustfs_heal_task_running` と `rustfs_heal_queue_delay_seconds` | 実行中タスクがゼロ以外のまま続き、キュー遅延が `30m` にわたって上昇 | +| スキャナーの停滞 | `rustfs_scanner_cycles_total` | `increase(rustfs_scanner_cycles_total[24h]) == 0` | +| クラスター使用容量のウォーターマーク | `rustfs_capacity_current_bytes` | デプロイ済みの総容量（自ら設定する定数）と比較します。例: `rustfs_capacity_current_bytes > 0.8 * ` | :::note -Per-disk usage and disk online/offline state are currently surfaced through the console and the admin API (server/storage info), not as dedicated OTLP metrics. For a per-disk watermark alert, poll the admin API from your own exporter or watch the console dashboard. +ディスクごとの使用量と、ディスクのオンライン／オフライン状態は、現時点では専用の OTLP メトリクスとしては出てきません。Console（管理画面）と管理 API（サーバーとストレージの情報）で確認できます。ディスクごとのウォーターマークアラートにするには、独自のエクスポーターから管理 API をポーリングするか、Console のダッシュボードを監視します。 ::: -## Log Collection +## ログの収集 -Where logs go is controlled by `RUSTFS_OBS_LOG_DIRECTORY`: +ログの出力先は `RUSTFS_OBS_LOG_DIRECTORY` で制御します。 -- **Unset** — logs go to stdout. In containers, use your log driver; on systemd hosts, stdout/stderr is captured by **journald**, so `journalctl -u rustfs -f` works without extra configuration. -- **A local directory** (e.g. `/var/log/rustfs/`) — RustFS writes rotating log files there. Rotation is tuned with `RUSTFS_OBS_LOG_FILENAME`, `RUSTFS_OBS_LOG_ROTATION_SIZE_MB`, `RUSTFS_OBS_LOG_ROTATION_TIME`, and `RUSTFS_OBS_LOG_KEEP_FILES`. -- **A URL** (contains `://`) — logs are shipped to a remote endpoint. +- **未設定**の場合、ログは stdout に出力されます。コンテナではログドライバーを使います。systemd のホストでは、stdout と stderr を **journald** が捕捉するため、追加設定なしで `journalctl -u rustfs -f` を使えます。 +- **ローカルディレクトリ**（例: `/var/log/rustfs/`）の場合、RustFS はそこにローテーションするログファイルを書き込みます。ローテーションは `RUSTFS_OBS_LOG_FILENAME`、`RUSTFS_OBS_LOG_ROTATION_SIZE_MB`、`RUSTFS_OBS_LOG_ROTATION_TIME`、`RUSTFS_OBS_LOG_KEEP_FILES` で調整します。 +- **URL**（`://` を含む）の場合、ログはリモートのエンドポイントへ送られます。 -When `RUSTFS_OBS_ENDPOINT` is set and log export is enabled, logs are additionally exported via OTLP; the reference stack routes them into Loki for querying from Grafana. +`RUSTFS_OBS_ENDPOINT` が設定され、ログのエクスポートが有効なときは、ログは OTLP でも追加でエクスポートされます。参照スタックは、Grafana から照会できるよう、これらを Loki へ送ります。 ```bash title="Example: file logs plus OTLP export" RUSTFS_ADDRESS=":9000" diff --git a/content/ja/operations/rc.mdx b/content/ja/operations/rc.mdx index 5339949e8..1eb718432 100644 --- a/content/ja/operations/rc.mdx +++ b/content/ja/operations/rc.mdx @@ -1,20 +1,20 @@ --- -title: "CLI Client (rc)" -description: "Install the RustFS command-line client and use it to connect to and inspect a RustFS cluster." +title: "CLI クライアント（rc）" +description: "RustFS のコマンドラインクライアントをインストールし、クラスターへの接続と状態確認に使う方法を説明します。" --- -`rc` is the RustFS command-line client for S3 object operations and RustFS administration. This guide installs `rc`, configures a cluster alias, and introduces the main inspection commands. The download examples use `v0.1.30`; check the [RustFS CLI releases](https://github.com/rustfs/cli/releases) for a newer version before installing. +`rc` は、S3 のオブジェクト操作と RustFS の管理に使うコマンドラインクライアントです。このガイドでは `rc` のインストール、クラスターエイリアスの設定、主な確認コマンドを説明します。ダウンロード例では `v0.1.30` を使います。インストールの前に、[RustFS CLI のリリース](https://github.com/rustfs/cli/releases)で、より新しいバージョンがないか確認します。 -## Installation +## インストール ### Linux -The default Linux archives are statically linked with musl for broad compatibility. Choose the tab that matches `uname -m`. +既定の Linux アーカイブは、広い互換性のために musl で静的リンクされています。`uname -m` と一致するタブを選びます。 -For an `x86_64` host: +`x86_64` のホストの場合は次のとおりです。 ```bash curl -fLO https://github.com/rustfs/cli/releases/download/v0.1.30/rustfs-cli-linux-amd64-v0.1.30.tar.gz @@ -25,7 +25,7 @@ sudo install -m 0755 rc /usr/local/bin/rc -For an `aarch64` host: +`aarch64` のホストの場合は次のとおりです。 ```bash curl -fLO https://github.com/rustfs/cli/releases/download/v0.1.30/rustfs-cli-linux-arm64-v0.1.30.tar.gz @@ -36,16 +36,16 @@ sudo install -m 0755 rc /usr/local/bin/rc -If your environment specifically requires a glibc-linked binary, select the `linux-amd64-gnu` or `linux-arm64-gnu` archive from the release page. +環境が特に glibc リンクのバイナリを必要とする場合は、リリースページから `linux-amd64-gnu` または `linux-arm64-gnu` のアーカイブを選びます。 ### macOS -Choose the tab that matches the value returned by `uname -m`. +`uname -m` が返す値と一致するタブを選びます。 -For an Intel (`x86_64`) Mac: +Intel（`x86_64`）の Mac の場合は次のとおりです。 ```bash curl -fLO https://github.com/rustfs/cli/releases/download/v0.1.30/rustfs-cli-macos-amd64-v0.1.30.tar.gz @@ -56,7 +56,7 @@ sudo install -m 0755 rc /usr/local/bin/rc -For an Apple silicon (`arm64`) Mac: +Apple silicon（`arm64`）の Mac の場合は次のとおりです。 ```bash curl -fLO https://github.com/rustfs/cli/releases/download/v0.1.30/rustfs-cli-macos-arm64-v0.1.30.tar.gz @@ -67,7 +67,7 @@ sudo install -m 0755 rc /usr/local/bin/rc -You can alternatively install the package through Homebrew: +Homebrew でパッケージをインストールすることもできます。 ```bash brew install rustfs/tap/rc @@ -75,63 +75,63 @@ brew install rustfs/tap/rc ### Windows -The current Windows release provides an AMD64 binary. Install it through the official Scoop bucket: +現在の Windows リリースが提供するのは AMD64 バイナリです。公式の Scoop バケットからインストールします。 ```powershell scoop bucket add rustfs https://github.com/rustfs/scoop-bucket scoop install rustfs/rc ``` -### Verify the installation +### インストールを確認する -Open a new terminal and verify that `rc` is available: +新しいターミナルを開き、`rc` が使えることを確認します。 ```bash rc --version rc --help ``` -## Usage +## 使い方 -### Configure an alias +### エイリアスを設定する -An alias stores the RustFS endpoint and credentials so you do not need to repeat them for every command. Replace the credentials before running: +エイリアスには、RustFS のエンドポイントと認証情報を保存できます。コマンドごとに繰り返す必要はありません。実行前に認証情報を置き換えます。 ```bash rc alias set local http://localhost:9000 rc alias list ``` -`alias set` replaces an existing alias with the same name. `alias list` does not print secret keys. +`alias set` は、同じ名前の既存エイリアスを置き換えます。`alias list` はシークレットキーを表示しません。 -### Check service health +### サービスの健全性を確認する -Check whether the service is live and whether its required dependencies are ready: +サービスが生存しているか、必要な依存関係が準備完了かを確認します。 ```bash rc ping local rc ready local ``` -### Inspect the cluster +### クラスターを確認する -Use the administrative cluster information command to inspect cluster status, servers, disks, and storage capacity: +管理用のクラスター情報コマンドで、クラスターの状態、サーバー、ディスク、ストレージ容量を確認します。 ```bash rc admin info cluster local ``` -List server pools when the deployment uses multiple pools: +デプロイが複数のプールを使う場合は、サーバープールを一覧します。 ```bash rc admin pool list local ``` -Administrative commands require credentials with the corresponding RustFS Admin API permissions. +管理コマンドには、対応する RustFS Admin API の権限を持つ認証情報が必要です。 -### Inspect buckets and objects +### バケットとオブジェクトを確認する -Prefer the noun-first command groups for new scripts: +新しいスクリプトでは、名詞を先頭にしたコマンドグループを使うことを推奨します。 ```bash rc bucket list local/ @@ -139,9 +139,9 @@ rc object list local/my-bucket rc object stat local/my-bucket/hello.txt ``` -### Manage lifecycle rules and storage tiers +### ライフサイクルルールとストレージ階層を管理する -`rc` groups lifecycle rules, remote storage tiers, and restore requests under `bucket lifecycle`: +`rc` は、ライフサイクルルール、リモートのストレージ階層、復元リクエストを `bucket lifecycle` にまとめています。 ```bash rc bucket lifecycle rule list local/my-bucket @@ -149,13 +149,13 @@ rc bucket lifecycle tier list local rc bucket lifecycle restore local/my-bucket/hello.txt --days 7 ``` -Use the `rule` commands to add, edit, remove, export, or import bucket lifecycle rules. Use the `tier` commands to add, inspect, update credentials for, or remove a remote tier. The older `rc ilm` form remains available as a compatibility alias, but we recommend `rc bucket lifecycle` for new scripts. +`rule` コマンドで、バケットのライフサイクルルールを追加、編集、削除、エクスポート、インポートします。`tier` コマンドで、リモート階層を追加、確認し、認証情報を更新し、削除します。古い `rc ilm` 形式は互換エイリアスとして残っています。新しいスクリプトでは `rc bucket lifecycle` を推奨します。 -See [Lifecycle Management](/administration/data/lifecycle-management) for rule and restore workflows, and [Tiered Storage](/administration/data/tiered-storage) for remote-tier configuration and maintenance. +ルールと復元の手順は[ライフサイクル管理](/ja/administration/data/lifecycle-management)を、リモート階層の設定と保守は[階層化ストレージ](/ja/administration/data/tiered-storage)を参照します。 -### Discover more commands +### ほかのコマンドを確認する -Use `--help` at any command level to see the commands and options supported by your installed version: +インストールしたバージョンがサポートするコマンドとオプションを見るには、どのコマンド階層でも `--help` を使います。 ```bash rc --help @@ -167,4 +167,4 @@ rc bucket lifecycle --help rc object --help ``` -For the complete source and command reference, see the [RustFS CLI repository](https://github.com/rustfs/cli). +ソース一式とコマンドリファレンスは、[RustFS CLI リポジトリ](https://github.com/rustfs/cli)を参照します。 diff --git a/content/ja/operations/scaling/data-rebalancing.md b/content/ja/operations/scaling/data-rebalancing.md index 5025f8540..4e2314206 100644 --- a/content/ja/operations/scaling/data-rebalancing.md +++ b/content/ja/operations/scaling/data-rebalancing.md @@ -1,84 +1,84 @@ --- -title: "Rebalancing" -description: "Redistribute existing objects across active RustFS storage pools through the Console or rc." +title: "リバランス" +description: "Console または rc を使い、既存のオブジェクトを稼働中の RustFS ストレージプールへ再配置します。" --- -## Overview +## 概要 -### Requirements +### 要件 -- Install [`rc`](/operations/rc) on the administration host before using the `rc` workflow in this guide. -- Configure credentials with rebalance administration permission. +- このガイドで `rc` の手順を使う前に、管理用ホストに [`rc`](/ja/operations/rc) をインストールします。 +- リバランスを管理する権限を持つ認証情報を設定します。 -After [Pool Expansion](./storage-pool-expansion.md), new writes can use the added capacity, but existing objects remain in their original pools. **Rebalancing** moves existing objects across all active pools so their used-capacity ratios converge. +[プールの拡張](./storage-pool-expansion.md) のあと、新しい書き込みは追加された容量を使えます。既存のオブジェクトは元のプールに残ります。**リバランス**は、使用容量の比率が近づくように、既存のオブジェクトを稼働中のすべてのプールへ移動します。 -Rebalancing requires at least two active pools. RustFS rejects a new rebalance while another rebalance or a pool decommission is running. Stopping a rebalance does not move already relocated objects back to their original pools. +リバランスには、稼働中のプールが 2 つ以上必要です。別のリバランス、またはプールのデコミッションが実行中のときは、RustFS は新しいリバランスを拒否します。リバランスを停止しても、すでに移動したオブジェクトは元のプールへは戻りません。 -Before starting, verify that all nodes and disks are healthy, no decommission is active, and the cluster has enough free capacity for normal writes during the operation. Schedule the operation during a lower-traffic period because object movement consumes disk, network, and CPU resources. +開始前に、すべてのノードとディスクが正常であること、デコミッションが実行中でないこと、操作中の通常の書き込みに足りる空き容量がクラスターにあることを確認します。オブジェクトの移動はディスク、ネットワーク、CPU を消費するため、トラフィックの少ない時間帯に実施します。 -## Operation +## 操作 -### Start rebalancing in the Console +### Console でリバランスを開始する -1. Sign in to the RustFS Console with an account that has rebalance administration permission. -2. Open **Rebalance**. -3. Review the active pools and their used-capacity ratios. -4. Select **Start Rebalance** and confirm the operation. -5. Keep the page open or return to it periodically to review per-pool progress. -6. Use **Stop Rebalance** only when you need to halt the operation. Data already moved remains in its new pool. +1. リバランスを管理する権限を持つアカウントで、RustFS Console にサインインします。 +2. **Rebalance**（リバランス）を開きます。 +3. 稼働中のプールと、それぞれの使用容量の比率を確認します。 +4. **Start Rebalance**（リバランスを開始）を選択し、操作を確定します。 +5. ページを開いたままにするか、定期的に戻って、プールごとの進捗を確認します。 +6. 操作を中断する必要がある場合に限り、**Stop Rebalance**（リバランスを停止）を使います。すでに移動したデータは、新しいプールに残ります。 -![RustFS Console showing a rebalance in progress with moved bytes and objects](./images/rebalance-running-console.png) +![移動済みのバイト数とオブジェクト数を伴う、実行中のリバランスを示す RustFS Console](./images/rebalance-running-console.png) -### Start rebalancing with rc +### rc でリバランスを開始する -Configure the cluster alias if it does not already exist: +クラスターのエイリアスが未設定の場合は、設定します。 ```bash rc alias set rustfs http://:9000 ``` -Start the rebalance: +リバランスを開始します。 ```bash rc admin rebalance start rustfs ``` -Check progress: +進捗を確認します。 ```bash rc admin rebalance status rustfs ``` -The status includes the operation ID and per-pool usage, moved bytes, object and version counts, remaining buckets, elapsed time, and estimated completion time when available. +ステータスには、操作 ID に加え、プールごとの使用量、移動済みバイト数、オブジェクト数とバージョン数、残りのバケット、経過時間、取得できる場合は完了見込み時刻が含まれます。 -To stop a running rebalance: +実行中のリバランスを停止するには、次を実行します。 ```bash rc admin rebalance stop rustfs ``` -`rc admin expand start|status|stop` and the `scale` alias expose the same post-expansion rebalance workflow. +`rc admin expand start|status|stop` と `scale` エイリアスは、拡張後のリバランスと同じ手順を提供します。 -## Verification +## 検証 -### Verify rebalancing in the Console +### Console でリバランスを検証する -Wait until the Rebalance page reports `Completed`. Confirm that: +**Rebalance** ページが `Completed` を報告するまで待ち、次を確認します。 -![RustFS Console showing a completed rebalance and balanced pool usage](./images/rebalance-completed-console.png) +![完了したリバランスと、均衡したプール使用量を示す RustFS Console](./images/rebalance-completed-console.png) -- No pool reports a failed or stopped state. -- Used-capacity ratios are closer across the active pools. -- All nodes and disks remain online. -- Normal object reads and writes succeed. +- 失敗または停止を報告しているプールがないこと。 +- 稼働中のプールの間で、使用容量の比率がより近づいていること。 +- すべてのノードとディスクがオンラインのままであること。 +- オブジェクトの通常の読み取りと書き込みが成功すること。 -### Verify rebalancing with rc +### rc でリバランスを検証する -Run: +次を実行します。 ```bash rc admin rebalance status rustfs rc admin pool list rustfs ``` -Verify that the rebalance status is `Completed`, remaining bucket counts are zero, and no failure is reported. Compare the per-pool usage ratios with the values recorded before the operation, then read an existing object and write a new test object through the S3 endpoint. +リバランスのステータスが `Completed` であり、残りのバケット数が 0 で、失敗が報告されていないことを確認します。プールごとの使用量の比率を、操作前に記録した値と比較します。その後、S3 エンドポイント経由で既存のオブジェクトを読み取り、新しいテストオブジェクトを書き込みます。 diff --git a/content/ja/operations/scaling/index.md b/content/ja/operations/scaling/index.md index ffa659899..a94eecd8c 100644 --- a/content/ja/operations/scaling/index.md +++ b/content/ja/operations/scaling/index.md @@ -1,10 +1,10 @@ --- -title: "Scaling" -description: "Expand, rebalance, and retire RustFS storage pools." +title: "スケーリング" +description: "RustFS のストレージプールを拡張し、リバランスし、デコミッションします。" --- -Choose the workflow that matches the topology change: +トポロジーの変更に合う手順を選びます。 -- [Pool Expansion](./storage-pool-expansion.md) -- [Rebalancing](./data-rebalancing.md) -- [Pool Decommission](./storage-pool-decommission.md) \ No newline at end of file +- [プールの拡張](./storage-pool-expansion.md) +- [リバランス](./data-rebalancing.md) +- [プールのデコミッション](./storage-pool-decommission.md) diff --git a/content/ja/operations/scaling/storage-pool-decommission.md b/content/ja/operations/scaling/storage-pool-decommission.md index 4b881793f..6a64d9927 100644 --- a/content/ja/operations/scaling/storage-pool-decommission.md +++ b/content/ja/operations/scaling/storage-pool-decommission.md @@ -1,119 +1,119 @@ --- -title: "Pool Decommission" -description: "Drain and retire a RustFS storage pool through the Console or rc, then verify that its data was relocated." +title: "プールのデコミッション" +description: "Console または rc で RustFS のストレージプールをデコミッションし、データが移動したことを確認します。" --- -## Overview +## 概要 -### Requirements +### 要件 -- Install [`rc`](/operations/rc) on the administration host before using the `rc` workflow in this guide. -- Configure credentials with decommission administration permission. +- このガイドで `rc` の手順を使う前に、管理用ホストに [`rc`](/ja/operations/rc) をインストールします。 +- デコミッションを管理する権限を持つ認証情報を設定します。 -**Pool decommission** moves objects from a selected pool to the remaining active pools so the target pool can be removed from the deployment. Use it when retiring hardware, replacing a pool, or consolidating capacity. +**プールのデコミッション**は、選択したプールのオブジェクトを残りの稼働中プールへ移動し、対象プールをデプロイから外せるようにします。データを排出してプールを停止する操作であり、ハードウェアを退役するとき、プールを置き換えるとき、または容量を集約するときに使います。 -Decommission is different from [Rebalancing](./data-rebalancing.md): rebalance keeps every pool active, while decommission drains and retires the selected pool. The two operations cannot run at the same time. +デコミッションは [リバランス](./data-rebalancing.md) とは別の操作です。リバランスはすべてのプールを稼働したままにします。デコミッションは、選択したプールのデータを排出して停止します。この 2 つの操作は同時には実行できません。 -Before starting: +開始前の条件と作業は、次のとおりです。 -- Keep at least one active pool after the operation. -- Verify that the remaining pools have enough free capacity. RustFS requires their free space to cover the used bytes being drained plus a 30% overhead. -- Confirm that every node and disk is healthy and no rebalance is running. -- Back up critical data and schedule the operation during a lower-traffic period. -- Record the exact pool ID and volume expression before selecting the target. +- 操作後も、稼働中のプールを 1 つ以上残す必要があります。 +- 残りのプールに十分な空き容量があることを確認します。RustFS では、排出する使用バイト数に 30% のオーバーヘッドを加えた容量を、残りのプールの空き領域でまかなう必要があります。 +- すべてのノードとディスクが正常であり、リバランスが実行中でないことを確認します。 +- 重要なデータをバックアップし、トラフィックの少ない時間帯に操作を予定します。 +- 対象を選ぶ前に、正確なプール ID とボリューム式を記録します。 -Canceling a decommission does not roll back completed moves. Objects already relocated remain in the destination pools. +デコミッションを取り消しても、完了した移動は元に戻りません。すでに移動したオブジェクトは、移動先のプールに残ります。 -## Operation +## 操作 -### Start decommissioning in the Console +### Console でデコミッションを開始する -1. Sign in to the RustFS Console with an account that has decommission administration permission. -2. Open **Pool Decommission**. -3. Locate the pool to retire and verify its ID, volume expression, used capacity, and status. +1. デコミッションを管理する権限を持つアカウントで、RustFS Console にサインインします。 +2. **Pool Decommission**（プールのデコミッション）を開きます。 +3. 停止するプールを特定し、ID、ボリューム式、使用容量、ステータスを確認します。 - ![RustFS Console showing the selected storage pool before decommissioning](./images/pool-decommission-selection-console.png) + ![デコミッション前に選択されたストレージプールを示す RustFS Console](./images/pool-decommission-selection-console.png) -4. Select **Start Decommission** for that pool. -5. Review the confirmation dialog carefully, then select **Start Decommission**. +4. そのプールの **Start Decommission**（デコミッションを開始）を選択します。 +5. 確認ダイアログをよく読み、**Start Decommission** を選択します。 - ![RustFS Console showing the pool decommission confirmation dialog](./images/pool-decommission-confirmation-console.png) + ![プールのデコミッション確認ダイアログを示す RustFS Console](./images/pool-decommission-confirmation-console.png) -6. Use **Sync** to refresh the pool state and movement counters until the operation completes. +6. 操作が完了するまで、**Sync**（同期）でプールの状態と移動カウンターを更新します。 - ![RustFS Console showing pool decommission progress and movement counters](./images/pool-decommission-running-console.png) + ![プールのデコミッションの進捗と移動カウンターを示す RustFS Console](./images/pool-decommission-running-console.png) -After completion, remove the drained pool expression from `RUSTFS_VOLUMES` on every remaining node and restart RustFS with the same ordered topology. For Helm, decommission the pool before removing its entry from `pools.list`; never remove or reorder a live pool entry. +完了後、残っているすべてのノードの `RUSTFS_VOLUMES` から、排出済みプールの式を削除し、同じ順序のトポロジーで RustFS を再起動します。Helm では、`pools.list` からエントリを外す前に、そのプールをデコミッションします。稼働中のプールエントリを削除したり、順序を変えたりしてはいけません。 -![RustFS Console showing the selected pool with a completed decommission status](./images/pool-decommission-completed-console.png) +![デコミッション完了のステータスが付いた、選択中のプールを示す RustFS Console](./images/pool-decommission-completed-console.png) -### Start decommissioning with rc +### rc でデコミッションを開始する -Configure the cluster alias if needed, then list the pools: +必要に応じてクラスターのエイリアスを設定し、プールを一覧表示します。 ```bash rc alias set rustfs http://:9000 rc admin pool list rustfs ``` -Start decommissioning pool `0` by its zero-based ID: +0 始まりの ID を指定して、プール `0` のデコミッションを開始します。 ```bash rc admin decommission start rustfs 0 --by-id ``` -You can instead pass the exact pool volume expression without `--by-id`: +`--by-id` を付けず、プールのボリューム式そのものを渡すこともできます。 ```bash rc admin decommission start rustfs 'http://rustfs-node1:9000/data/rustfs{1...4}/mnmd' ``` -Monitor all pools or only the target pool: +すべてのプール、または対象プールだけを監視します。 ```bash rc admin decommission status rustfs rc admin decommission status rustfs 0 --by-id ``` -To cancel a running operation, use: +実行中の操作を取り消すには、次を実行します。 ```bash rc admin decommission cancel rustfs 0 --by-id ``` -If a decommission is failed or canceled, clear its metadata before retrying: +デコミッションが失敗した、または取り消された場合は、再試行の前にメタデータを消去します。 ```bash rc admin decommission clear rustfs 0 --by-id ``` -After the target reports `complete`, remove its expression from `RUSTFS_VOLUMES` on every remaining node and restart RustFS with the reduced topology. +対象が `complete` を報告したら、残っているすべてのノードの `RUSTFS_VOLUMES` からその式を削除し、縮小したトポロジーで RustFS を再起動します。 -## Verification +## 検証 -### Verify decommissioning in the Console +### Console でデコミッションを検証する -Confirm that the target pool reports `Completed`, with zero failed objects and zero failed bytes. After removing the pool from the startup topology and restarting RustFS, verify that: +対象プールが `Completed` を報告し、失敗したオブジェクト数と失敗したバイト数が 0 であることを確認します。起動時のトポロジーからプールを外して RustFS を再起動したあと、次を確認します。 -![RustFS Console showing only the remaining pool after the retired pool was removed](./images/pool-decommission-final-topology-console.png) +![停止したプールを削除したあとに残ったプールだけを示す RustFS Console](./images/pool-decommission-final-topology-console.png) -- The retired pool no longer appears as an active pool. -- Every remaining node and disk is online. -- Remaining pools show the relocated data and have adequate free capacity. -- Existing objects can still be listed, read, and downloaded. +- 停止したプールが、稼働中のプールとして表示されていないこと。 +- 残っているすべてのノードとディスクがオンラインであること。 +- 残りのプールに移動したデータが表示され、空き容量が十分であること。 +- 既存のオブジェクトを、引き続き一覧表示、読み取り、ダウンロードできること。 -### Verify decommissioning with rc +### rc でデコミッションを検証する -Before removing the pool from the topology, run: +トポロジーからプールを外す前に、次を実行します。 ```bash rc admin decommission status rustfs 0 --by-id ``` -Confirm that the status is `complete` and the failed object and byte counters are zero. After updating `RUSTFS_VOLUMES` and restarting RustFS, run: +ステータスが `complete` であり、失敗したオブジェクトとバイトのカウンターが 0 であることを確認します。`RUSTFS_VOLUMES` を更新して RustFS を再起動したあと、次を実行します。 ```bash rc admin pool list rustfs ``` -Verify that only the intended active pools remain. Read objects that previously resided on the retired pool and write a new test object through the S3 endpoint. +意図した稼働中のプールだけが残っていることを確認します。以前は停止したプールに置かれていたオブジェクトを読み取り、S3 エンドポイント経由で新しいテストオブジェクトを書き込みます。 diff --git a/content/ja/operations/scaling/storage-pool-expansion.md b/content/ja/operations/scaling/storage-pool-expansion.md index e5cb761e7..3f6f652e7 100644 --- a/content/ja/operations/scaling/storage-pool-expansion.md +++ b/content/ja/operations/scaling/storage-pool-expansion.md @@ -1,104 +1,104 @@ --- -title: "Pool Expansion" -description: "Add a storage pool to a RustFS cluster and verify the expanded topology through the Console or rc." +title: "プールの拡張" +description: "RustFS クラスターにストレージプールを追加し、Console または rc で拡張後のトポロジーを確認します。" --- -## Overview +## 概要 -### Requirements +### 要件 -- Install [`rc`](/operations/rc) on the administration host before using the `rc` workflow in this guide. -- Configure credentials with permission to read RustFS cluster and pool status. +- このガイドで `rc` の手順を使う前に、管理用ホストに [`rc`](/ja/operations/rc) をインストールします。 +- RustFS のクラスター状態とプール状態を読み取る権限を持つ認証情報を設定します。 -RustFS expands capacity by appending a **server pool** to the cluster topology. Each pool is one space-separated volume expression in `RUSTFS_VOLUMES`. After the expanded topology is applied, new writes can use the added capacity; existing objects remain in their current pools until you run [Rebalancing](./data-rebalancing.md). +RustFS は、クラスターのトポロジーへ **サーバープール** を追加して容量を拡張します。各プールは、`RUSTFS_VOLUMES` 内でスペース区切りになったボリューム式の 1 つです。拡張したトポロジーを適用すると、新しい書き込みは追加された容量を使えます。既存のオブジェクトは、[リバランス](./data-rebalancing.md) を実行するまで、現在のプールに残ります。 -This guide uses the following two-pool example: +このガイドでは、次の 2 つのプールを例にします。 ```ini title="/etc/default/rustfs" RUSTFS_VOLUMES="http://rustfs-node1:9000/data/rustfs{1...4}/mnmd http://rustfs-node2:9000/data/rustfs{1...4}/mnmd" ``` -Before expanding: +拡張の前に、次を行います。 -- Back up critical data and run the workflow during a maintenance window. -- Use the same RustFS version, credentials, and complete `RUSTFS_VOLUMES` value on every node. -- Verify name resolution, time synchronization, and port `9000` connectivity between all old and new nodes. -- Prepare the new pool with the intended disk count and storage specification. +- 重要なデータをバックアップし、メンテナンス時間帯に手順を実行します。 +- すべてのノードで、同じ RustFS のバージョン、同じ認証情報、完全な `RUSTFS_VOLUMES` の値を使います。 +- 既存のノードと新しいノードのすべてについて、名前解決、時刻同期、ポート `9000` の疎通を確認します。 +- 新しいプールは、意図したディスク数とストレージ仕様で準備します。 -:::warning[Append the pool; do not replace the topology] +:::warning[プールは追加し、トポロジーは置き換えない] -Every node must start with the complete ordered pool list. Omitting the existing pool or using a different expression on one node creates an inconsistent topology. +すべてのノードは、順序を保った完全なプール一覧で起動する必要があります。既存のプールを省いたり、1 つのノードで別の式を使ったりすると、トポロジーが不整合になります。 ::: -## Operation +## 操作 -### Expand with Console assistance +### Console を補助にして拡張する -The Console displays storage pools but does not add a pool to the server startup topology. Use this Console-assisted workflow: +Console はストレージプールを表示します。サーバー起動時のトポロジーへプールを追加する機能はありません。次の手順では、Console を補助に使います。 -1. Record the existing pools and their usage from **Rebalance** or **Pool Decommission**. -2. Install the same RustFS version and service configuration on the new pool node or nodes. -3. Append the new pool expression to `RUSTFS_VOLUMES` on every existing and new node. Keep the existing expressions unchanged and in the same order. -4. Restart RustFS across all nodes so every process starts with the same expanded topology. -5. Wait for all nodes to become ready, then refresh the pool list in the Console. +1. **Rebalance**（リバランス）または **Pool Decommission**（プールのデコミッション）で、既存のプールと使用量を記録します。 +2. 新しいプールのノードへ、同じ RustFS のバージョンとサービス設定をインストールします。 +3. 既存ノードと新規ノードのすべての `RUSTFS_VOLUMES` へ、新しいプールの式を追加します。既存の式は変えず、順序も維持します。 +4. すべてのノードで RustFS を再起動し、各プロセスが同じ拡張後のトポロジーで起動するようにします。 +5. すべてのノードが準備完了になるまで待ち、Console のプール一覧を更新します。 -![RustFS Console showing the original and newly added storage pools](./images/pool-expansion-console.png) +![元のストレージプールと、新しく追加されたストレージプールを示す RustFS Console](./images/pool-expansion-console.png) -For a Helm deployment, append the new entry to `pools.list` and apply `helm upgrade`. Do not remove or reorder existing entries. +Helm のデプロイでは、`pools.list` に新しいエントリを追加し、`helm upgrade` を適用します。既存のエントリは削除せず、順序も変えません。 -### Inspect the expansion with rc +### rc で拡張結果を確認する -Configure an alias with credentials that can read cluster and pool status: +クラスターとプールの状態を読み取れる認証情報で、エイリアスを設定します。 ```bash rc alias set rustfs http://:9000 ``` -Record the current topology: +現在のトポロジーを記録します。 ```bash rc admin pool list rustfs ``` -Prepare the new nodes, append the new pool expression to the complete `RUSTFS_VOLUMES` value on every node, and restart RustFS across the cluster. `rc` does not mutate the server startup topology. +新しいノードを準備し、すべてのノードで完全な `RUSTFS_VOLUMES` の値に新しいプールの式を追加して、クラスター全体の RustFS を再起動します。`rc` は、サーバー起動時のトポロジーを変更しません。 -After the cluster returns, list the pools again: +クラスターが戻ったあと、プールを再度一覧表示します。 ```bash rc admin pool list rustfs ``` -Use a zero-based pool ID to inspect the new pool in detail: +0 始まりのプール ID で、新しいプールの詳細を確認します。 ```bash rc admin pool status rustfs 1 --by-id ``` -:::note[Rebalance aliases] +:::note[リバランスのエイリアス] -`rc admin expand start`, `status`, and `stop` are aliases for the post-expansion rebalance workflow. They redistribute existing data; they do not append a pool to `RUSTFS_VOLUMES`. +`rc admin expand start`、`status`、`stop` は、拡張後のリバランス手順のエイリアスです。既存のデータを再配置します。`RUSTFS_VOLUMES` へプールを追加する操作ではありません。 ::: -## Verification +## 検証 -### Verify the expansion in the Console +### Console で拡張を検証する -Confirm that: +次を確認します。 -- The pool list shows the original pool and the new pool. -- Every expected node and disk is online. -- The new pool reports the expected total and available capacity. -- The cluster reports no degraded nodes before you resume normal traffic. +- プール一覧に、元のプールと新しいプールが表示されること。 +- 想定するすべてのノードとディスクがオンラインであること。 +- 新しいプールが、想定どおりの合計容量と空き容量を報告すること。 +- 通常のトラフィックを再開する前に、クラスターが縮退したノードを報告していないこと。 -### Verify the expansion with rc +### rc で拡張を検証する -Run: +次を実行します。 ```bash rc admin pool list rustfs rc admin pool status rustfs 1 --by-id ``` -Verify that the new pool has the expected command-line expression and an active state. Write and read a test object through the normal S3 endpoint before starting a rebalance. +新しいプールが、想定したコマンドラインの式を持ち、稼働状態であることを確認します。リバランスを開始する前に、通常の S3 エンドポイント経由でテストオブジェクトを書き込み、読み取ります。 diff --git a/content/ja/operations/status-check.md b/content/ja/operations/status-check.md index 9627a3b5e..8b556b763 100644 --- a/content/ja/operations/status-check.md +++ b/content/ja/operations/status-check.md @@ -1,26 +1,26 @@ --- -title: "Status Check" -description: "Check RustFS network access, health endpoints, cluster status, and storage capacity." +title: "ステータス確認" +description: "RustFS のネットワーク到達性、ヘルスチェックのエンドポイント、クラスターの状態、ストレージ容量を確認する方法を説明します。" --- -Use network probes, the **Status** page in the RustFS Console, or the `rc` command line to review RustFS availability and storage consumption. Before using the command-line workflow, [install `rc`](/operations/rc) and configure an alias for the target cluster. +ネットワークのプローブ、RustFS Console（管理画面）の **Status**（ステータス）ページ、または `rc` のコマンドラインで、RustFS の可用性とストレージ使用量を確認します。コマンドラインの手順を使う前に、[`rc` をインストール](/ja/operations/rc)し、対象クラスターのエイリアスを設定します。 -## Network ports +## ネットワークポート -RustFS uses two listeners by default. You can change both bind addresses through environment variables or command-line flags. +RustFS は既定で 2 つのリスナーを使います。両方のバインドアドレスは、環境変数またはコマンドラインフラグで変更できます。 -| Port | Listener | Configured by | Traffic | +| ポート | リスナー | 設定方法 | トラフィック | | --- | --- | --- | --- | -| `9000` | S3 API | `RUSTFS_ADDRESS` / `--address` | S3 object API, admin API, and internal node-to-node RPC under `/rustfs/rpc/` and `/rustfs/peer/` | -| `9001` | Console | `RUSTFS_CONSOLE_ADDRESS` / `--console-address` | Embedded web console under `/rustfs/console/`; disable it with `RUSTFS_CONSOLE_ENABLE=false` | +| `9000` | S3 API | `RUSTFS_ADDRESS` / `--address` | S3 オブジェクト API、管理 API、および `/rustfs/rpc/` と `/rustfs/peer/` 配下のノード間内部 RPC | +| `9001` | Console | `RUSTFS_CONSOLE_ADDRESS` / `--console-address` | `/rustfs/console/` 配下の組み込み Web Console。`RUSTFS_CONSOLE_ENABLE=false` で無効にします | -:::note[Internode connectivity] +:::note[ノード間の接続] -Internode RPC shares port 9000. In a multi-node cluster, every node must be able to reach every other node on the S3 port; there is no separate cluster port. +ノード間 RPC はポート 9000 を共有します。マルチノードのクラスターでは、すべてのノードが S3 ポートでほかのすべてのノードへ到達できる必要があります。専用のクラスターポートはありません。 ::: -Open the default ports with `firewalld` when clients need to reach both listeners: +クライアントが両方のリスナーへ到達する必要がある場合は、`firewalld` で既定のポートを開きます。 ```bash title="firewall-cmd" firewall-cmd --permanent --add-port=9000/tcp @@ -28,25 +28,25 @@ firewall-cmd --permanent --add-port=9001/tcp firewall-cmd --reload ``` -:::warning[Restrict console access] +:::warning[Console へのアクセスを制限する] -Expose port 9001 only to trusted networks. If you do not need the console, set `RUSTFS_CONSOLE_ENABLE=false` and leave the port closed. +ポート 9001 は、信頼できるネットワークにだけ公開します。Console が不要な場合は、`RUSTFS_CONSOLE_ENABLE=false` を設定し、ポートは閉じたままにします。 ::: -## Health endpoints +## ヘルスチェックのエンドポイント -The S3 listener on port **9000** serves unauthenticated probe endpoints. Disable them with `RUSTFS_HEALTH_ENDPOINT_ENABLE=false`. The console on port **9001** has its own health path. +ポート **9000** の S3 リスナーは、認証のないプローブ用エンドポイントを提供します。`RUSTFS_HEALTH_ENDPOINT_ENABLE=false` で無効にします。ポート **9001** の Console には、専用のヘルスパスがあります。 -| Endpoint | Port | Meaning | +| エンドポイント | ポート | 意味 | | --- | --- | --- | -| `GET /health`, `HEAD /health`, `GET /health/live`, `GET /minio/health/live` | 9000 | Liveness — returns `200` as long as the process is up | -| `GET /health/ready` | 9000 | Readiness — `200` only when storage, IAM, and peer health are ready; `503` otherwise | -| `GET /minio/health/ready` | 9000 | MinIO-compatible alias of the readiness probe | -| `GET /minio/health/cluster`, `GET /minio/health/cluster/read` | 9000 | Cluster write/read health (additionally require lock quorum) | -| `GET /rustfs/console/health` | 9001 | Console process health | +| `GET /health`、`HEAD /health`、`GET /health/live`、`GET /minio/health/live` | 9000 | 生存確認（Liveness）。プロセスが動作している間は `200` を返します | +| `GET /health/ready` | 9000 | 準備完了。ストレージ、IAM、ピアがすべて準備できた場合だけ `200` を返し、それ以外は `503` を返します | +| `GET /minio/health/ready` | 9000 | 準備完了プローブの MinIO 互換エイリアス | +| `GET /minio/health/cluster`、`GET /minio/health/cluster/read` | 9000 | クラスターの書き込みと読み取りの健全性（ロックのクォーラムも必要です） | +| `GET /rustfs/console/health` | 9001 | Console プロセスの健全性 | -A ready node answers `200` with `"ready": true`. A degraded node answers `503` with per-dependency detail: +準備完了のノードは、`"ready": true` とともに `200` を返します。劣化したノードは、依存関係ごとの詳細とともに `503` を返します。 ```bash title="Probe examples" curl -fsS http://localhost:9000/health @@ -54,60 +54,60 @@ curl -s http://:9000/health/ready | jq curl -fsS http://localhost:9001/rustfs/console/health ``` -The `details` object reports `storage` / `iam` / `lock` (and `kms` when configured), and `degradedReasons` lists machine-readable causes such as `storage_quorum_unavailable`, `iam_not_ready`, or `lock_quorum_unavailable`. +`details` オブジェクトは `storage` / `iam` / `lock`（設定されている場合は `kms`）を報告し、`degradedReasons` は `storage_quorum_unavailable`、`iam_not_ready`、`lock_quorum_unavailable` のような機械可読の原因を列挙します。 -## Cluster status +## クラスターの状態 -### Check cluster status in the Console +### Console でクラスターの状態を確認する -1. Sign in to the RustFS Console. -2. Open **Status**. -3. Confirm that the cluster is online and review the server, network, and drive status. -4. Investigate any offline server, unavailable drive, or failed network connection before maintenance or capacity changes. +1. RustFS Console にサインインします。 +2. **Status** を開きます。 +3. クラスターがオンラインであることを確認し、サーバー、ネットワーク、ドライブの状態を確認します。 +4. メンテナンスや容量変更の前に、オフラインのサーバー、利用できないドライブ、失敗したネットワーク接続を調べます。 -### Check cluster status with rc +### rc でクラスターの状態を確認する -Run the cluster information command with your configured alias: +設定済みのエイリアスで、クラスター情報コマンドを実行します。 ```bash rc admin info cluster rustfs ``` -The overview reports the cluster state, RustFS version, server and disk counts, backend type, and erasure-coding parity. The node list shows uptime, network connectivity, drive availability, and pool membership. The disk list shows each drive's state and pool, set, and disk location. +概要には、クラスターの状態、RustFS のバージョン、サーバー数とディスク数、バックエンドの種類、イレイジャーコーディングのパリティが表示されます。ノード一覧には、稼働時間、ネットワーク接続、ドライブの可用性、所属するプールが表示されます。ディスク一覧には、各ドライブの状態と、プール、セット、ディスクの位置が表示されます。 -For machine-readable output, request JSON: +機械可読の出力にするには、JSON を指定します。 ```bash rc admin info cluster rustfs --json ``` -## Storage capacity +## ストレージ容量 -### Check storage capacity in the Console +### Console でストレージ容量を確認する -1. Sign in to the RustFS Console and open **Status**. -2. Review the cluster's used and total storage capacity. -3. Review the capacity and available space for each disk. -4. Compare usage over time and plan expansion before available capacity becomes insufficient for normal writes and maintenance. +1. RustFS Console にサインインし、**Status** を開きます。 +2. クラスターの使用済み容量と総容量を確認します。 +3. 各ディスクの容量と空き容量を確認します。 +4. 使用量の推移を比較し、通常の書き込みとメンテナンスに必要な空き容量が不足する前に、拡張を計画します。 -### Check storage capacity with rc +### rc でストレージ容量を確認する -Use the same cluster information command: +同じクラスター情報コマンドを使います。 ```bash rc admin info cluster rustfs ``` -The **Storage** summary reports used capacity, total capacity, and the used percentage for the cluster. Each entry under **Disks** reports used, total, and available capacity for that drive. +**Storage**（ストレージ）の概要には、クラスターの使用済み容量、総容量、使用率が表示されます。**Disks**（ディスク）の各項目には、そのドライブの使用済み容量、総容量、空き容量が表示されます。 -Use JSON output when collecting the values in a script or monitoring integration: +スクリプトや監視連携で値を集めるときは、JSON 出力を使います。 ```bash rc admin info cluster rustfs --json ``` -Administrative information commands require credentials with the corresponding RustFS Admin API permissions. +管理情報のコマンドには、対応する RustFS Admin API の権限を持つ認証情報が必要です。 -## Next steps +## 次のステップ -For continuous telemetry and alerting, continue with [Observability](./observability.md). To add storage, review [Pool Expansion](./scaling/storage-pool-expansion.md). +継続的なテレメトリとアラートについては、[オブザーバビリティ](./observability.md)に進みます。ストレージを追加する場合は、[ストレージプールの拡張](./scaling/storage-pool-expansion.md)を確認します。 diff --git a/content/ja/operations/upgrade/binary/index.md b/content/ja/operations/upgrade/binary/index.md index 594d2abe0..6ded6639f 100644 --- a/content/ja/operations/upgrade/binary/index.md +++ b/content/ja/operations/upgrade/binary/index.md @@ -1,28 +1,28 @@ --- -title: "Binary Upgrade" -description: "Upgrade RustFS binary deployments one node at a time while preserving cluster availability." +title: "バイナリ" +description: "クラスターの可用性を維持したまま、RustFS のバイナリデプロイを 1 ノードずつアップグレードします。" --- -Use a rolling upgrade to replace the RustFS executable on each node without taking the entire cluster offline. Before you begin, read the target release notes and confirm every node is healthy. +ローリングアップグレードにより、クラスター全体をオフラインにせず、各ノードの RustFS 実行ファイルを置き換えます。開始前に、対象リリースのリリースノートを読み、すべてのノードが正常であることを確認します。 -## Before you upgrade +## アップグレードの前に -Check readiness on every node: +すべてのノードで準備完了を確認します。 ```bash curl -fsS http://:9000/health/ready ``` -Back up the service configuration and retain the currently running executable for rollback: +サービス設定をバックアップし、ロールバックに備えて、現在実行中の実行ファイルを残します。 ```bash sudo cp /etc/default/rustfs /etc/default/rustfs.bak sudo cp /usr/local/bin/rustfs /usr/local/bin/rustfs.previous ``` -## Upgrade each node +## 各ノードをアップグレードする -Upgrade one node at a time. Do not continue until the restarted node reports ready. +一度に 1 ノードずつアップグレードします。再起動したノードが準備完了を報告するまで、次のノードには進みません。 ```bash sudo systemctl stop rustfs @@ -32,11 +32,11 @@ sudo systemctl start rustfs curl -fsS http://:9000/health/ready ``` -Repeat the procedure for each remaining node. +残りの各ノードでも、同じ手順を繰り返します。 -## Roll back +## ロールバック -If the new version fails validation, restore the previous executable on one node at a time and wait for readiness before continuing: +新しいバージョンの検証に失敗した場合は、一度に 1 ノードずつ以前の実行ファイルを復元し、準備完了を待ってから続行します。 ```bash sudo systemctl stop rustfs @@ -45,6 +45,6 @@ sudo systemctl start rustfs curl -fsS http://:9000/health/ready ``` -## Next steps +## 次のステップ -Review [Status Check](/operations/status-check) for additional post-upgrade validation. \ No newline at end of file +アップグレード後の追加の検証は、[状態の確認](/ja/operations/status-check) を参照します。 diff --git a/content/ja/operations/upgrade/container/index.md b/content/ja/operations/upgrade/container/index.md index e9e388f14..509ca378f 100644 --- a/content/ja/operations/upgrade/container/index.md +++ b/content/ja/operations/upgrade/container/index.md @@ -1,45 +1,45 @@ --- -title: "Container Upgrade" -description: "Upgrade RustFS containers started with Docker, Podman, or Docker Compose while preserving persistent data." +title: "コンテナ" +description: "永続データを維持したまま、Docker、Podman、または Docker Compose で起動した RustFS コンテナをアップグレードします。" --- -Upgrade a container deployment by recreating the RustFS container from a newer image. Choose the workflow that matches the original installation method: a container started directly with Docker or Podman, or a service managed by Docker Compose. +より新しいイメージから RustFS コンテナを再作成し、コンテナのデプロイをアップグレードします。元のインストール方法に合う手順を選びます。対象は、Docker または Podman で直接起動したコンテナと、Docker Compose で管理するサービスです。 -## Before you upgrade +## アップグレードの前に -Read the target release notes and use an explicit image tag for the upgrade. Record the current image and retain the original `docker run`, `podman run`, or Compose configuration because recreating a container does not copy its runtime options automatically. +対象リリースのリリースノートを読み、アップグレードには明示的なイメージタグを使います。現在のイメージを記録し、元の `docker run`、`podman run`、または Compose の設定を残します。コンテナを再作成しても、実行時のオプションは自動ではコピーされません。 -Confirm that RustFS is healthy before replacing it: +置き換える前に、RustFS が正常であることを確認します。 ```bash curl -fsS http://localhost:9000/health/ready ``` -:::warning[Preserve persistent storage] +:::warning[永続ストレージを維持する] -Do not remove the named volume or host directory mounted at `/data`. Commands such as `docker compose down -v`, `docker volume rm`, and `podman volume rm` delete persistent storage and are not part of an upgrade. +`/data` にマウントした名前付きボリューム、またはホストディレクトリは削除しません。`docker compose down -v`、`docker volume rm`、`podman volume rm` などのコマンドは永続ストレージを削除します。これらはアップグレード手順には含まれません。 ::: -## Upgrade a Docker container +## Docker コンテナをアップグレードする -The following workflow matches the container name and named volume used in the [Docker installation guide](/installation/container/docker). If your deployment uses different ports, environment variables, mounts, or startup arguments, keep those settings unchanged in the replacement command. +以下の手順は、[Docker のインストールガイド](/ja/installation/container/docker) で使うコンテナ名と名前付きボリュームに合わせています。ポート、環境変数、マウント、起動引数が異なるデプロイでは、置き換え用のコマンドでもそれらの設定をそのまま維持します。 -Record the current image, then pull the target version: +現在のイメージを記録し、対象バージョンを取得します。 ```bash docker inspect --format '{{.Config.Image}}' rustfs docker pull rustfs/rustfs: ``` -Stop and remove only the container. The `rustfs-data` volume remains intact: +停止して削除するのはコンテナだけです。`rustfs-data` ボリュームはそのまま残ります。 ```bash docker stop rustfs docker rm rustfs ``` -Recreate the container with the original configuration and the target image: +元の設定と対象イメージで、コンテナを再作成します。 ```bash docker run -d \ @@ -59,7 +59,7 @@ docker run -d \ /data ``` -Wait for the replacement container to become healthy: +置き換えたコンテナが正常になるまで待ちます。 ```bash docker ps --filter name=rustfs @@ -67,9 +67,9 @@ docker logs rustfs curl -fsS http://localhost:9000/health/ready ``` -## Upgrade a Podman container +## Podman コンテナをアップグレードする -The Podman workflow is the same replacement operation, using the image name from the [Podman installation guide](/installation/container/podman). +Podman の手順も同じ置き換え操作です。イメージ名は、[Podman のインストールガイド](/ja/installation/container/podman) のものを使います。 ```bash podman inspect --format '{{.Config.Image}}' rustfs @@ -78,7 +78,7 @@ podman stop rustfs podman rm rustfs ``` -Recreate the container with the original configuration and persistent volume: +元の設定と永続ボリュームで、コンテナを再作成します。 ```bash podman run -d \ @@ -97,7 +97,7 @@ podman run -d \ /data ``` -Verify the replacement before continuing: +続行する前に、置き換えたコンテナを確認します。 ```bash podman ps --filter name=rustfs @@ -105,16 +105,16 @@ podman logs rustfs curl -fsS http://localhost:9000/health/ready ``` -## Upgrade with Docker Compose +## Docker Compose でアップグレードする -Run Compose commands from the directory containing the deployment's `docker-compose.yml`. Before the upgrade, save the fully resolved configuration and confirm the current image: +デプロイの `docker-compose.yml` があるディレクトリで、Compose のコマンドを実行します。アップグレードの前に、変数を展開した完全な設定を保存し、現在のイメージを確認します。 ```bash docker compose config > docker-compose.resolved.yaml docker compose images rustfs ``` -Change the `rustfs` service to an explicit target image tag while leaving its volumes, environment, ports, and command unchanged: +ボリューム、環境変数、ポート、コマンドは変えず、`rustfs` サービスを明示的な対象イメージタグへ変更します。 ```yaml title="docker-compose.yml" services: @@ -122,7 +122,7 @@ services: image: rustfs/rustfs: ``` -Validate the file, pull the target image, and recreate only the RustFS service. `--no-deps` leaves optional observability services running: +ファイルを検証し、対象イメージを取得して、RustFS サービスだけを再作成します。`--no-deps` を付けると、オプションのオブザーバビリティサービスは稼働したままです。 ```bash docker compose config --quiet @@ -130,7 +130,7 @@ docker compose pull rustfs docker compose up -d --no-deps rustfs ``` -Check the service and the RustFS readiness endpoint: +サービスと RustFS の準備完了エンドポイントを確認します。 ```bash docker compose ps rustfs @@ -138,19 +138,19 @@ docker compose logs --tail=100 rustfs curl -fsS http://localhost:9000/health/ready ``` -If you started RustFS together with the `observability` profile, the RustFS service still upgrades with the same commands. Upgrade observability images separately according to each component's release notes. +`observability` プロファイルと一緒に RustFS を起動している場合でも、RustFS サービスは同じコマンドでアップグレードします。オブザーバビリティのイメージは、コンポーネントごとのリリースノートに従って、個別にアップグレードします。 -## Upgrade a multi-node deployment +## マルチノードのデプロイをアップグレードする -Replace one RustFS node at a time. Wait for the upgraded node's readiness endpoint to succeed and confirm cluster status before proceeding to the next node. Do not recreate all nodes simultaneously. +RustFS ノードは、一度に 1 つずつ置き換えます。アップグレードしたノードの準備完了エンドポイントが成功することを待ち、クラスターの状態を確認してから、次のノードへ進みます。全ノードを同時に再作成してはいけません。 -Use the same Docker, Podman, or Compose workflow on each node, preserving that node's existing mounts and configuration. +各ノードで同じ Docker、Podman、または Compose の手順を使い、そのノードの既存のマウントと設定は維持します。 -## Roll back +## ロールバック -For Docker or Podman, stop and remove the failed replacement container, then repeat the corresponding `run` command with the previously recorded image tag. Keep the same persistent volume and runtime configuration. +Docker または Podman では、失敗した置き換えコンテナを停止して削除し、以前に記録したイメージタグで、対応する `run` コマンドを再実行します。永続ボリュームと実行時の設定は、同じものを維持します。 -For Docker Compose, restore the previous `image` value in `docker-compose.yml`, then recreate the RustFS service: +Docker Compose では、`docker-compose.yml` の `image` を以前の値に戻し、RustFS サービスを再作成します。 ```bash docker compose pull rustfs @@ -158,8 +158,8 @@ docker compose up -d --no-deps rustfs curl -fsS http://localhost:9000/health/ready ``` -In a multi-node deployment, roll back one node at a time and wait for readiness before continuing. +マルチノードのデプロイでは、一度に 1 ノードずつロールバックし、準備完了を待ってから続行します。 -## Next steps +## 次のステップ -Review [Status Check](/operations/status-check) for additional post-upgrade validation. \ No newline at end of file +アップグレード後の追加の検証は、[状態の確認](/ja/operations/status-check) を参照します。 diff --git a/content/ja/operations/upgrade/index.md b/content/ja/operations/upgrade/index.md index b9521a4a7..642d70bf9 100644 --- a/content/ja/operations/upgrade/index.md +++ b/content/ja/operations/upgrade/index.md @@ -1,14 +1,14 @@ --- -title: "Upgrade" -description: "Plan and perform RustFS upgrades while preserving cluster availability." +title: "アップグレード" +description: "クラスターの可用性を維持したまま、RustFS のアップグレードを計画して実施します。" --- -Choose the upgrade workflow that matches how you deploy RustFS. For multi-node clusters, replace one node or pod at a time and wait for it to report ready before continuing. +RustFS のデプロイ方法に合うアップグレード手順を選びます。マルチノードのクラスターでは、ノードまたは Pod を一度に 1 つずつ置き換え、準備完了を報告するまで待ってから続行します。 -## Deployment methods +## デプロイ方法 -- [Binary Upgrade](./binary/index.md) covers systemd-managed executable replacement and rollback. -- [Container Upgrade](./container/index.md) covers image replacement with persistent data volumes. -- [Kubernetes Upgrade](./kubernetes/index.md) covers Helm- and Operator-managed workloads. +- [バイナリ](./binary/index.md) では、systemd で管理する実行ファイルの置き換えとロールバックを扱います。 +- [コンテナ](./container/index.md) では、永続データボリュームを維持したイメージの置き換えを扱います。 +- [Kubernetes](./kubernetes/index.md) では、Helm と Operator が管理するワークロードを扱います。 -Before any upgrade, read the target release notes and confirm the cluster is healthy. \ No newline at end of file +どのアップグレードでも、実施前に対象リリースのリリースノートを読み、クラスターが正常であることを確認します。 diff --git a/content/ja/operations/upgrade/kubernetes/index.md b/content/ja/operations/upgrade/kubernetes/index.md index 9914e1465..19532bfa4 100644 --- a/content/ja/operations/upgrade/kubernetes/index.md +++ b/content/ja/operations/upgrade/kubernetes/index.md @@ -1,26 +1,26 @@ --- -title: "Kubernetes Upgrade" -description: "Upgrade RustFS deployments managed by the Helm chart or RustFS Operator and verify each rollout." +title: "Kubernetes" +description: "Helm チャートまたは RustFS Operator で管理する RustFS デプロイをアップグレードし、各ロールアウトを確認します。" --- -Upgrade a Kubernetes deployment through the tool that owns its resources. Use Helm for a direct RustFS Helm chart installation. For an Operator installation, upgrade the Operator release and each Tenant through their respective declarative configurations. +リソースを所有するツールを通じて、Kubernetes のデプロイをアップグレードします。RustFS の Helm チャートを直接インストールしている場合は、Helm を使います。Operator でインストールしている場合は、Operator のリリースと各テナントを、それぞれの宣言的な設定を通じてアップグレードします。 -## Before you upgrade +## アップグレードの前に -Read the RustFS, chart, and Operator release notes that apply to your deployment. Confirm that the cluster has enough capacity to replace pods and that all current workloads are ready: +そのデプロイに関係する RustFS、チャート、Operator のリリースノートを読みます。Pod の置き換えに足りる容量がクラスターにあり、現在のワークロードがすべて準備完了であることを確認します。 ```bash kubectl get nodes kubectl -n get pods,pvc ``` -Do not delete PersistentVolumeClaims (PVCs) during an upgrade or rollback. Keep the existing deployment values and manifests under version control, including any image tags, storage topology, scheduling rules, and Secret references. +アップグレード中とロールバック中は、PersistentVolumeClaim（PVC）を削除してはいけません。イメージタグ、ストレージのトポロジー、スケジューリングルール、Secret の参照を含め、既存のデプロイの値とマニフェストはバージョン管理に残します。 -## Upgrade a Helm chart deployment +## Helm チャートのデプロイをアップグレードする -This workflow applies to RustFS installed directly with the [RustFS Helm chart](/installation/cloud-native/helm-chart/installation). It does not apply to a Tenant created by RustFS Operator. +この手順は、[RustFS Helm チャート](/ja/installation/cloud-native/helm-chart/installation) で直接インストールした RustFS に適用します。RustFS Operator が作成したテナントには適用しません。 -Record the current release revision, chart version, application version, and effective user-supplied values: +現在のリリースリビジョン、チャートのバージョン、アプリケーションのバージョン、現在有効なユーザー指定値を記録します。 ```bash helm status rustfs --namespace rustfs @@ -28,20 +28,20 @@ helm history rustfs --namespace rustfs helm get values rustfs --namespace rustfs -o yaml > rustfs-values.previous.yaml ``` -Prepare the target chart in the same way as the installation. If you use the chart repository, update its index and set the chart reference: +対象チャートは、インストール時と同じ方法で準備します。チャートリポジトリを使う場合は、インデックスを更新し、チャートの参照先を設定します。 ```bash helm repo update rustfs export RUSTFS_CHART=rustfs/rustfs ``` -If you use a source checkout, check out the target RustFS release and point `RUSTFS_CHART` at its chart directory: +ソースのチェックアウトを使う場合は、対象の RustFS リリースをチェックアウトし、`RUSTFS_CHART` をそのチャートディレクトリに向けます。 ```bash export RUSTFS_CHART=./helm/rustfs ``` -Update your maintained values file for any release-specific changes. Set `image.rustfs.tag` to the explicit RustFS version you intend to run, then apply the upgrade: +リリース固有の変更があれば、管理している値ファイルを更新します。`image.rustfs.tag` を、実行する RustFS の明示的なバージョンに設定し、アップグレードを適用します。 ```bash helm upgrade rustfs "$RUSTFS_CHART" \ @@ -52,34 +52,34 @@ helm upgrade rustfs "$RUSTFS_CHART" \ --timeout 10m ``` -Helm performs a rolling update. Monitor the release and pods until the rollout completes: +Helm はローリングアップデートを実行します。ロールアウトが完了するまで、リリースと Pod を監視します。 ```bash helm status rustfs --namespace rustfs kubectl -n rustfs get pods,pvc,services ``` -Distributed mode creates a StatefulSet: +分散モードでは、StatefulSet が作成されます。 ```bash kubectl -n rustfs rollout status statefulset/rustfs --timeout=10m ``` -Standalone mode creates a Deployment: +スタンドアロンモードでは、Deployment が作成されます。 ```bash kubectl -n rustfs rollout status deployment/rustfs --timeout=10m ``` -Verify the S3 API after the rollout. If it is not exposed outside the cluster, start the port forward documented in the installation guide first: +ロールアウトのあと、S3 API を確認します。S3 API をクラスターの外部へ公開していない場合は、先にインストールガイドに記載されたポートフォワードを開始します。 ```bash curl -fsS http://localhost:9000/health/ready ``` -### Roll back a Helm release +### Helm リリースをロールバックする -List the release history, identify the last working revision, and let Helm restore its chart, values, and image configuration: +リリース履歴を一覧し、最後に正常だったリビジョンを特定します。チャート、値、イメージ設定は Helm に復元させます。 ```bash helm history rustfs --namespace rustfs @@ -89,20 +89,20 @@ helm rollback rustfs \ --timeout 10m ``` -Check the workload and readiness endpoint again after rollback. Do not uninstall the release or delete its PVCs. +ロールバックのあと、ワークロードと準備完了エンドポイントを再度確認します。リリースをアンインストールしたり、その PVC を削除したりしてはいけません。 -## Upgrade an Operator deployment +## Operator のデプロイをアップグレードする -An Operator deployment has two independent upgrade surfaces: +Operator のデプロイには、互いに独立した 2 つのアップグレード対象があります。 -- The RustFS Operator and Operator Console run from the `rustfs-operator` Helm release. -- Each Tenant runs the RustFS image declared in that Tenant's `spec.image` field. +- RustFS Operator と Operator Console は、`rustfs-operator` の Helm リリースで動作します。 +- 各テナントは、そのテナントの `spec.image` フィールドで宣言された RustFS イメージを実行します。 -Upgrade and validate the Operator control plane before changing Tenant images. Do not combine an Operator upgrade with multiple Tenant upgrades in one maintenance step. +テナントのイメージを変える前に、Operator のコントロールプレーンをアップグレードし、検証します。1 回のメンテナンス作業で、Operator のアップグレードと複数のテナントのアップグレードを同時に行ってはいけません。 -### Upgrade the Operator release +### Operator のリリースをアップグレードする -Record the current release and save its values: +現在のリリースを記録し、その値を保存します。 ```bash helm status rustfs-operator --namespace rustfs-system @@ -111,7 +111,7 @@ helm get values rustfs-operator --namespace rustfs-system -o yaml \ > rustfs-operator-values.previous.yaml ``` -Update the Operator source checkout to the target release and review changes to its chart values and CustomResourceDefinitions (CRDs). Helm does not upgrade CRDs stored in a chart's `crds/` directory, so apply both target CRDs before upgrading the controller: +Operator のソースチェックアウトを対象リリースへ更新し、チャートの値と CustomResourceDefinition（CRD）の変更点を確認します。Helm は、チャートの `crds/` ディレクトリに置かれた CRD をアップグレードしません。コントローラーをアップグレードする前に、対象の 2 つの CRD をどちらも適用します。 ```bash kubectl apply --server-side --force-conflicts \ @@ -122,7 +122,7 @@ kubectl apply --server-side --force-conflicts \ -f deploy/rustfs-operator/crds/policybinding-crd.yaml ``` -The CRDs are cluster-scoped and shared by every Tenant namespace. Applying them first allows the Kubernetes API server to accept fields introduced by the new controller. After both commands succeed, upgrade the Operator with your maintained values file: +これらの CRD はクラスタースコープであり、すべてのテナントの Namespace で共有されます。先に適用すると、Kubernetes API サーバーは、新しいコントローラーが導入するフィールドを受け付けられるようになります。両方のコマンドが成功したら、管理している値ファイルで Operator をアップグレードします。 ```bash helm upgrade rustfs-operator deploy/rustfs-operator/ \ @@ -134,7 +134,7 @@ helm upgrade rustfs-operator deploy/rustfs-operator/ \ --timeout 10m ``` -Verify the CRDs and all control-plane components before upgrading a Tenant: +テナントをアップグレードする前に、CRD とコントロールプレーンの全コンポーネントを確認します。 ```bash kubectl get crd tenants.rustfs.com @@ -143,7 +143,7 @@ kubectl -n rustfs-system rollout status deployment/rustfs-operator-console --tim kubectl get tenants --all-namespaces ``` -CRD changes are not part of Helm release history and `helm rollback` does not restore them. Review the target release's compatibility and migration notes before considering a controller rollback. If that release explicitly supports downgrading, restore the previous Helm revision without applying older CRD files: +CRD の変更は Helm のリリース履歴に含まれません。`helm rollback` でも復元されません。コントローラーのロールバックを検討する前に、対象リリースの互換性と移行に関する注記を確認します。そのリリースがダウングレードを明示的にサポートしている場合は、古い CRD ファイルは適用せず、以前の Helm リビジョンを復元します。 ```bash helm history rustfs-operator --namespace rustfs-system @@ -153,13 +153,13 @@ helm rollback rustfs-operator \ --timeout 10m ``` -Do not downgrade across a documented one-way workload or security migration. Roll forward to a fixed Operator release instead. +文書で一方向とされているワークロード移行、またはセキュリティ移行を越えてダウングレードしてはいけません。修正を含む Operator リリースへロールフォワードします。 -### Upgrade a Tenant +### テナントをアップグレードする -The Operator owns each Tenant's StatefulSets. Do not change their container images directly because reconciliation restores the image declared by the Tenant. +各テナントの StatefulSet は、Operator が所有します。コンテナのイメージを直接変更しません。調整処理が、テナントで宣言されたイメージを復元します。 -Record the current Tenant image and confirm its `Ready` condition: +現在のテナントイメージを記録し、`Ready` 条件を確認します。 ```bash kubectl -n storage-a get tenant tenant-a \ @@ -168,7 +168,7 @@ kubectl -n storage-a get tenant tenant-a kubectl -n storage-a get pods,pvc -l rustfs.tenant=tenant-a ``` -In the complete `tenant.yaml` used to install the Tenant, change only `spec.image` to `rustfs/rustfs:`. Leave its pools, PVC templates, credentials, and other settings unchanged. Apply the complete manifest and wait for the Operator to reconcile the new generation: +テナントのインストールに使った完全な `tenant.yaml` では、`spec.image` だけを `rustfs/rustfs:` に変更します。プール、PVC テンプレート、認証情報、その他の設定は変更しません。完全なマニフェストを適用し、Operator が新しい世代を調整するまで待ちます。 ```bash kubectl apply -f tenant.yaml @@ -178,11 +178,11 @@ kubectl -n storage-a wait tenant/tenant-a \ kubectl -n storage-a get pods -l rustfs.tenant=tenant-a ``` -Upgrade one Tenant at a time. Confirm its S3 API and [cluster status](/operations/status-check) before updating another Tenant. +テナントは 1 つずつアップグレードします。別のテナントを更新する前に、その S3 API と [クラスターの状態](/ja/operations/status-check) を確認します。 -### Roll back a Tenant +### テナントをロールバックする -Restore the previously recorded image in `spec.image`, apply the complete Tenant manifest, and wait for `Ready` again: +以前に記録したイメージを `spec.image` に戻し、完全なテナントのマニフェストを適用して、再び `Ready` になるまで待ちます。 ```bash kubectl apply -f tenant.yaml @@ -191,8 +191,8 @@ kubectl -n storage-a wait tenant/tenant-a \ --timeout=10m ``` -The Operator reuses the Tenant's existing PVCs. Do not delete the Tenant, its StatefulSets, or its PVCs during rollback. +Operator は、テナントの既存 PVC を再利用します。ロールバック中に、テナント、その StatefulSet、その PVC を削除してはいけません。 -## Next steps +## 次のステップ -Review [Status Check](/operations/status-check) and [Observability](/operations/observability) to validate the deployment after the rollout. \ No newline at end of file +ロールアウト後にデプロイを検証するには、[状態の確認](/ja/operations/status-check) と [オブザーバビリティ](/ja/operations/observability) を参照します。 diff --git a/content/ja/reference/cli.md b/content/ja/reference/cli.md index 47fc0a905..3a3d9cee1 100644 --- a/content/ja/reference/cli.md +++ b/content/ja/reference/cli.md @@ -1,20 +1,20 @@ --- -title: "CLI Reference" -description: "Reference for the rustfs subcommands, server flags, environment variable equivalents, and volume path syntax." +title: "CLI リファレンス" +description: "rustfs のサブコマンド、サーバーフラグ、対応する環境変数、ボリュームパスの構文をまとめたリファレンスです。" --- -The `rustfs` binary ships six subcommands. Running `rustfs` with no subcommand starts the server. +`rustfs` バイナリは 6 つのサブコマンドを備えています。サブコマンドを付けずに `rustfs` を実行すると、サーバーが起動します。 -## Subcommands +## サブコマンド -| Command | Description | +| コマンド | 説明 | | --- | --- | -| `rustfs server [OPTIONS] ...` | Start the object storage server (default when no subcommand is given). | -| `rustfs info [--all] [--json] [system\|runtime\|build\|config\|deps]` | Display system, runtime, build, configuration, or dependency information. | -| `rustfs tls inspect --path ` | Inspect a TLS certificate directory layout and parsing status. | -| `rustfs diagnose [OPTIONS] ...` | Analyze log files and report probable failure causes. | -| `rustfs inspect ` | Inspect persisted bucket metadata without a running server. | -| `rustfs connect ` | Configure outbound RustFS Connect integration. | +| `rustfs server [OPTIONS] ...` | オブジェクトストレージサーバーを起動します（サブコマンドを省略したときの既定動作です）。 | +| `rustfs info [--all] [--json] [system\|runtime\|build\|config\|deps]` | システム、ランタイム、ビルド、設定、または依存関係の情報を表示します。 | +| `rustfs tls inspect --path ` | TLS 証明書ディレクトリの配置と解析状態を検査します。 | +| `rustfs diagnose [OPTIONS] ...` | ログファイルを分析し、可能性の高い障害原因を報告します。 | +| `rustfs inspect ` | サーバーを起動せずに、永続化されたバケットメタデータを検査します。 | +| `rustfs connect ` | 外向きの RustFS Connect 連携を設定します。 | ```bash title="Examples" rustfs server /data/rustfs @@ -22,62 +22,62 @@ rustfs info --all --json rustfs tls inspect --path /etc/rustfs/tls ``` -### Legacy invocation compatibility +### 従来の起動方法との互換性 -Arguments are preprocessed for backward compatibility, so older invocation styles keep working: +後方互換のため引数は前処理されるので、従来の起動方法もそのまま動作します。 -| Legacy form | Interpreted as | +| 従来の形式 | 解釈 | | --- | --- | | `rustfs /data` | `rustfs server /data` | | `rustfs --address :9000 /data` | `rustfs server --address :9000 /data` | -| `rustfs` (no arguments) | `rustfs server` with volumes read from `RUSTFS_VOLUMES` | +| `rustfs`（引数なし） | `RUSTFS_VOLUMES` からボリュームを読み込む `rustfs server` | | `rustfs --info` | `rustfs info` | | `rustfs help` | `rustfs --help` | -## Server flags +## サーバーフラグ -Every server flag has an environment variable equivalent; the flag wins when both are set. +すべてのサーバーフラグには、対応する環境変数があります。両方を設定した場合は、フラグが優先されます。 -| Flag | Environment variable | Default | Description | +| フラグ | 環境変数 | 既定値 | 説明 | | --- | --- | --- | --- | -| `...` (positional) | `RUSTFS_VOLUMES` | required | Storage volumes or endpoints, space-separated. | -| `--address` | `RUSTFS_ADDRESS` | `:9000` | S3 API bind address (`ADDRESS:PORT`, IP or hostname). | -| `--server-domains` | `RUSTFS_SERVER_DOMAINS` | unset | Comma-separated domains for virtual-hosted-style requests. | -| `--access-key` | `RUSTFS_ACCESS_KEY` | unset | Root access key (conflicts with `--access-key-file`). | -| `--access-key-file` | `RUSTFS_ACCESS_KEY_FILE` | unset | File containing the root access key. | -| `--secret-key` | `RUSTFS_SECRET_KEY` | unset | Root secret key (conflicts with `--secret-key-file`). | -| `--secret-key-file` | `RUSTFS_SECRET_KEY_FILE` | unset | File containing the root secret key. | -| `--console-enable` | `RUSTFS_CONSOLE_ENABLE` | `true` | Enable the embedded web console. | -| `--console-address` | `RUSTFS_CONSOLE_ADDRESS` | `:9001` | Console bind address. | -| `--obs-endpoint` | `RUSTFS_OBS_ENDPOINT` | empty | OTLP/HTTP base URL for traces, metrics, and logs. | -| `--tls-path` | `RUSTFS_TLS_PATH` | unset | TLS certificate directory for the API and console. | -| `--license` | `RUSTFS_LICENSE` | unset | License string. | -| `--region` | `RUSTFS_REGION` | unset | Service region reported to clients. | -| `--kms-enable` | `RUSTFS_KMS_ENABLE` | `false` | Enable KMS server-side encryption. | -| `--kms-backend` | `RUSTFS_KMS_BACKEND` | `local` | KMS backend: `local`, `vault` / `vault-kv2`, `vault-transit`. | -| `--kms-key-dir` | `RUSTFS_KMS_KEY_DIR` | unset | Key directory for the local KMS backend. | -| `--kms-local-master-key` | `RUSTFS_KMS_LOCAL_MASTER_KEY` | unset | Master key for local KMS key-file encryption. | -| `--kms-vault-address` | `RUSTFS_KMS_VAULT_ADDRESS` | unset | Vault address for the Vault backends. | -| `--kms-vault-token` | `RUSTFS_KMS_VAULT_TOKEN` | unset | Vault token for the Vault backends. | -| `--kms-vault-mount-path` | `RUSTFS_KMS_VAULT_MOUNT_PATH` | unset | Transit mount for `vault-transit` (defaults to `transit`); deprecated and unused for `vault` / `vault-kv2`. | -| `--kms-default-key-id` | `RUSTFS_KMS_DEFAULT_KEY_ID` | unset | Default KMS key ID for encryption. | -| `--kms-allow-insecure-dev-defaults` | `RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS` | `false` | Allow development-only insecure KMS defaults. | -| `--buffer-profile` | `RUSTFS_BUFFER_PROFILE` | `GeneralPurpose` | Workload profile for adaptive buffer sizing. | -| `--buffer-profile-disable` | `RUSTFS_BUFFER_PROFILE_DISABLE` | `false` | Use legacy fixed-size buffers. | +| `...`（位置引数） | `RUSTFS_VOLUMES` | required | ストレージボリュームまたはエンドポイントを、空白区切りで指定します。 | +| `--address` | `RUSTFS_ADDRESS` | `:9000` | S3 API のバインドアドレスです（`ADDRESS:PORT`。IP またはホスト名）。 | +| `--server-domains` | `RUSTFS_SERVER_DOMAINS` | unset | 仮想ホスト形式のリクエストに使う、カンマ区切りのドメインです。 | +| `--access-key` | `RUSTFS_ACCESS_KEY` | unset | ルートアクセスキーです（`--access-key-file` と競合します）。 | +| `--access-key-file` | `RUSTFS_ACCESS_KEY_FILE` | unset | ルートアクセスキーを格納したファイルです。 | +| `--secret-key` | `RUSTFS_SECRET_KEY` | unset | ルートシークレットキーです（`--secret-key-file` と競合します）。 | +| `--secret-key-file` | `RUSTFS_SECRET_KEY_FILE` | unset | ルートシークレットキーを格納したファイルです。 | +| `--console-enable` | `RUSTFS_CONSOLE_ENABLE` | `true` | 組み込みの Web Console を有効にします。 | +| `--console-address` | `RUSTFS_CONSOLE_ADDRESS` | `:9001` | Console のバインドアドレスです。 | +| `--obs-endpoint` | `RUSTFS_OBS_ENDPOINT` | empty | トレース、メトリクス、ログ向けの OTLP/HTTP ベース URL です。 | +| `--tls-path` | `RUSTFS_TLS_PATH` | unset | API と Console 用の TLS 証明書ディレクトリです。 | +| `--license` | `RUSTFS_LICENSE` | unset | ライセンス文字列です。 | +| `--region` | `RUSTFS_REGION` | unset | クライアントへ報告するサービスリージョンです。 | +| `--kms-enable` | `RUSTFS_KMS_ENABLE` | `false` | KMS によるサーバー側の暗号化を有効にします。 | +| `--kms-backend` | `RUSTFS_KMS_BACKEND` | `local` | KMS バックエンドです。指定できる値は `local`、`vault` / `vault-kv2`、`vault-transit` です。 | +| `--kms-key-dir` | `RUSTFS_KMS_KEY_DIR` | unset | ローカル KMS バックエンドのキーディレクトリです。 | +| `--kms-local-master-key` | `RUSTFS_KMS_LOCAL_MASTER_KEY` | unset | ローカル KMS のキーファイルを暗号化するマスターキーです。 | +| `--kms-vault-address` | `RUSTFS_KMS_VAULT_ADDRESS` | unset | Vault バックエンドが使う Vault のアドレスです。 | +| `--kms-vault-token` | `RUSTFS_KMS_VAULT_TOKEN` | unset | Vault バックエンドが使う Vault トークンです。 | +| `--kms-vault-mount-path` | `RUSTFS_KMS_VAULT_MOUNT_PATH` | unset | `vault-transit` の Transit マウントです（既定値は `transit`）。`vault` / `vault-kv2` では非推奨であり、使用されません。 | +| `--kms-default-key-id` | `RUSTFS_KMS_DEFAULT_KEY_ID` | unset | 暗号化に使う既定の KMS キー ID です。 | +| `--kms-allow-insecure-dev-defaults` | `RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS` | `false` | 開発専用の、安全でない KMS 既定値を許可します。 | +| `--buffer-profile` | `RUSTFS_BUFFER_PROFILE` | `GeneralPurpose` | 適応的なバッファサイズ決定に使うワークロードプロファイルです。 | +| `--buffer-profile-disable` | `RUSTFS_BUFFER_PROFILE_DISABLE` | `false` | 従来の固定サイズバッファを使います。 | :::note -If neither `--access-key`/`--secret-key` nor their file variants are provided, the server falls back to the built-in default credentials (`rustfsadmin`/`rustfsadmin`) and logs a warning. Set real credentials for any non-throwaway deployment. +`--access-key` と `--secret-key`、およびそれらのファイル形式のいずれも指定しない場合、サーバーは組み込みの既定認証情報（`rustfsadmin`/`rustfsadmin`）にフォールバックし、警告をログに記録します。一時的な検証以外のデプロイでは、実際の認証情報を設定します。 ::: -## Volume syntax +## ボリュームの構文 -Volumes are passed as positional arguments (or via `RUSTFS_VOLUMES`) and are space-separated. +ボリュームは位置引数（または `RUSTFS_VOLUMES`）として渡し、空白で区切ります。 -### Ellipses expansion +### 省略記号による展開 -A volume token may contain one or more `{N...M}` ranges, which expand numerically: +ボリュームトークンには、数値として展開される `{N...M}` 範囲を 1 つ以上含められます。 ```bash title="Ellipses expansion" # Expands to /data/rustfs0 /data/rustfs1 /data/rustfs2 /data/rustfs3 @@ -87,21 +87,21 @@ rustfs server /data/rustfs{0...3} rustfs server http://node{1...4}:9000/data/rustfs{0...3} ``` -Rules verified from the parser: +パーサーで確認済みの規則は次のとおりです。 -- The range format is `{N...M}` where `N` and `M` are decimal or hexadecimal positive integers and `M` must be greater than `N`. -- A single token may carry multiple ranges (e.g. host range plus disk range); all combinations are expanded. -- The maximum expanded size of one range is 10,000 entries. +- 範囲の形式は `{N...M}` です。`N` と `M` は 10 進または 16 進の正の整数であり、`M` は `N` より大きい必要があります。 +- 1 つのトークンに複数の範囲を含められます（例: ホスト範囲とディスク範囲）。すべての組み合わせが展開されます。 +- 1 つの範囲を展開したときの最大数は 10,000 エントリです。 -### Multiple pools +### 複数のプール -Separate server pools are expressed as space-separated groups of endpoints. Each argument (one per space) forms its own expansion group: +サーバープールを分けるには、エンドポイントのグループを空白区切りで並べます。各引数（空白で区切られた 1 つ）が、それぞれ独自の展開グループになります。 ```bash title="Two pools" rustfs server http://node{1...4}:9000/data/rustfs{0...3} http://node{5...8}:9000/data/rustfs{0...3} ``` -When set through the environment, the same string goes into `RUSTFS_VOLUMES`: +環境変数で設定する場合は、同じ文字列を `RUSTFS_VOLUMES` に指定します。 ```bash title="Via environment" export RUSTFS_VOLUMES="http://node{1...4}:9000/data/rustfs{0...3}" diff --git a/content/ja/reference/environment-variables.md b/content/ja/reference/environment-variables.md index 9db713983..651ca205f 100644 --- a/content/ja/reference/environment-variables.md +++ b/content/ja/reference/environment-variables.md @@ -1,201 +1,201 @@ --- -title: "Environment Variables" -description: "Reference for the environment variables that configure the RustFS server, console, TLS, KMS, observability, scanner, healing, storage classes, credentials, and event targets." +title: "環境変数" +description: "RustFS サーバー、Console、TLS、KMS、オブザーバビリティ、スキャナー、データ修復、ストレージクラス、認証情報、イベントターゲットを設定する環境変数のリファレンスです。" --- -This page lists the environment variables recognized by the `rustfs` server binary. It covers the operations-relevant subset verified against the RustFS source code; some internal tuning knobs are intentionally omitted. Every variable can also be supplied through the matching command-line flag where one exists (see the [CLI reference](./cli)). +このページでは、`rustfs` サーバーバイナリが認識する環境変数を一覧します。対象は、RustFS のソースコードで確認した、運用に関係する変数に限ります。内部向けの調整項目の一部は、意図的に省略しています。対応するコマンドラインフラグがある変数は、そのフラグでも指定できます（[CLI リファレンス](./cli) を参照）。 -:::note[Boolean values] +:::note[真偽値] -Boolean variables accept `true`/`false`. Values shown as "unset" have no default and the corresponding feature stays disabled or falls back to built-in behavior. +真偽値の変数は `true`/`false` を受け付けます。「unset」と示した値には既定値がなく、対応する機能は無効のままか、組み込みの動作にフォールバックします。 ::: -## Core server +## コアサーバー -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_VOLUMES` | unset (required) | Storage volumes or endpoints, space-separated. Supports `{N...M}` ellipses expansion, e.g. `/data/rustfs{0...3}` or `http://node{1...4}:9000/data/rustfs{0...3}`. The Docker image defaults to `/data`. | -| `RUSTFS_ADDRESS` | `:9000` | Bind address and port for the S3 API listener (also carries internal node RPC). | -| `RUSTFS_SERVER_DOMAINS` | unset | Comma-separated domain name(s) for virtual-hosted-style S3 requests, e.g. `s3.example.com` so `bucket.s3.example.com` resolves to bucket `bucket`. When unset, only path-style addressing works. | -| `RUSTFS_REGION` | unset | Region reported to S3 clients. When unset the server falls back to `us-east-1`. | -| `RUSTFS_LICENSE` | unset | License string. | -| `RUSTFS_BUFFER_PROFILE` | `GeneralPurpose` | Workload profile for adaptive buffer sizing. Options: `GeneralPurpose`, `AiTraining`, `DataAnalytics`, `WebWorkload`, `IndustrialIoT`, `SecureStorage`. | -| `RUSTFS_BUFFER_PROFILE_DISABLE` | `false` | Disable adaptive buffer sizing and use legacy fixed-size buffers. | -| `RUSTFS_HEALTH_ENDPOINT_ENABLE` | `true` | Register the unauthenticated `/health` and `/health/ready` probe endpoints. | -| `RUSTFS_HEALTH_READINESS_CACHE_TTL_MS` | `1000` | Cache TTL for readiness probe results, in milliseconds. | -| `RUSTFS_HEALTH_CLUSTER_TIMEOUT_MS` | `2000` | Timeout for cluster health probes (`/minio/health/cluster`), in milliseconds. | -| `RUSTFS_STARTUP_READINESS_MAX_WAIT_SECS` | `120` | Maximum time the readiness probe reports "starting" before startup is considered failed. | -| `RUSTFS_CHECK_UPDATE` | `true` | Check for a newer RustFS release at startup by sending one HTTPS request to `version.rustfs.com`; the user agent carries the current version. The result is logged only, and RustFS never updates itself. Set to `false` to skip the outbound request, for example in air-gapped deployments; unrecognized values fall back to `true`. | +| `RUSTFS_VOLUMES` | unset (required) | ストレージボリュームまたはエンドポイントを、空白区切りで指定します。`{N...M}` 形式の省略記号展開に対応します。例: `/data/rustfs{0...3}`、`http://node{1...4}:9000/data/rustfs{0...3}`。Docker イメージの既定値は `/data` です。 | +| `RUSTFS_ADDRESS` | `:9000` | S3 API リスナーのバインドアドレスとポートです（ノード間の内部 RPC もこのリスナーを使います）。 | +| `RUSTFS_SERVER_DOMAINS` | unset | 仮想ホスト形式の S3 リクエストに使うドメイン名を、カンマ区切りで指定します。例: `s3.example.com` を指定すると、`bucket.s3.example.com` はバケット `bucket` として解決されます。未設定の場合は、パススタイルアクセスのみが動作します。 | +| `RUSTFS_REGION` | unset | S3 クライアントへ報告するリージョンです。未設定の場合、サーバーは `us-east-1` にフォールバックします。 | +| `RUSTFS_LICENSE` | unset | ライセンス文字列です。 | +| `RUSTFS_BUFFER_PROFILE` | `GeneralPurpose` | 適応的なバッファサイズ決定に使うワークロードプロファイルです。選択肢は `GeneralPurpose`、`AiTraining`、`DataAnalytics`、`WebWorkload`、`IndustrialIoT`、`SecureStorage` です。 | +| `RUSTFS_BUFFER_PROFILE_DISABLE` | `false` | 適応的なバッファサイズ決定を無効にし、従来の固定サイズバッファを使います。 | +| `RUSTFS_HEALTH_ENDPOINT_ENABLE` | `true` | 認証不要のプローブエンドポイント `/health` と `/health/ready` を登録します。 | +| `RUSTFS_HEALTH_READINESS_CACHE_TTL_MS` | `1000` | 準備完了プローブの結果をキャッシュする TTL です。単位はミリ秒です。 | +| `RUSTFS_HEALTH_CLUSTER_TIMEOUT_MS` | `2000` | クラスターのヘルスチェック（`/minio/health/cluster`）のタイムアウトです。単位はミリ秒です。 | +| `RUSTFS_STARTUP_READINESS_MAX_WAIT_SECS` | `120` | 準備完了プローブが「starting」と報告する最長時間です。この時間を超えると、起動に失敗したとみなします。単位は秒です。 | +| `RUSTFS_CHECK_UPDATE` | `true` | 起動時に `version.rustfs.com` へ HTTPS リクエストを 1 回送り、新しい RustFS リリースがあるか確認します。ユーザーエージェントには現在のバージョンが含まれます。結果はログに記録されるだけで、RustFS が自ら更新することはありません。エアギャップ環境などでは `false` に設定し、外部へのリクエストを省略します。認識できない値は `true` にフォールバックします。 | ## Console -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_CONSOLE_ENABLE` | `true` | Enable the embedded web console (served on a separate listener). | -| `RUSTFS_CONSOLE_ADDRESS` | `:9001` | Bind address and port for the console listener. | +| `RUSTFS_CONSOLE_ENABLE` | `true` | 組み込みの Web Console を有効にします（別のリスナーで提供されます）。 | +| `RUSTFS_CONSOLE_ADDRESS` | `:9001` | Console リスナーのバインドアドレスとポートです。 | -## CORS +## CORS [#cors] -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_CORS_ALLOWED_ORIGINS` | empty | Comma-separated origins allowed to access the S3 API from a browser. Set `*` for wildcard origins without credentials. | -| `RUSTFS_CONSOLE_CORS_ALLOWED_ORIGINS` | `*` | Comma-separated origins allowed to access the Console from a browser, or `*` for all origins. | +| `RUSTFS_CORS_ALLOWED_ORIGINS` | empty | ブラウザから S3 API へアクセスできるオリジンを、カンマ区切りで指定します。認証情報を伴わないワイルドカードオリジンにする場合は `*` を設定します。 | +| `RUSTFS_CONSOLE_CORS_ALLOWED_ORIGINS` | `*` | ブラウザから Console へアクセスできるオリジンをカンマ区切りで指定します。すべてのオリジンを許可する場合は `*` です。 | -See [CORS Configuration](/administration/cors) for configuration and verification steps. +設定と確認の手順は [CORS の設定](/ja/administration/cors) を参照します。 -## TLS & KMS +## TLS と KMS -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_TLS_PATH` | unset | Directory containing the TLS certificate and key (`rustfs_cert.pem` / `rustfs_key.pem`) for the S3 API and console. TLS is enabled when set. | -| `RUSTFS_TLS_RELOAD_ENABLE` | `false` | Watch the TLS directory and hot-reload certificates. | -| `RUSTFS_TLS_KEYLOG` | `false` | Write TLS session keys to a keylog file for debugging. Do not enable in production. | -| `RUSTFS_TRUST_SYSTEM_CA` | `false` | Also trust the operating system CA store for outbound TLS connections. | -| `RUSTFS_TRUST_LEAF_CERT_AS_CA` | `false` | Trust a leaf certificate as if it were a CA (self-signed setups). | -| `RUSTFS_SERVER_MTLS_ENABLE` | `false` | Require client certificates (mutual TLS) on the server listeners. | -| `RUSTFS_MTLS_CLIENT_CERT` | unset | Client certificate presented for internode mTLS connections. | -| `RUSTFS_MTLS_CLIENT_KEY` | unset | Client private key for internode mTLS connections. | -| `RUSTFS_KMS_ENABLE` | `false` | Enable KMS-backed server-side encryption. | -| `RUSTFS_KMS_BACKEND` | `local` | KMS backend: `local`, `vault` / `vault-kv2` (Vault KV2 storage with local data-key wrapping), or `vault-transit`. | -| `RUSTFS_KMS_KEY_DIR` | unset | Key directory for the `local` backend. | -| `RUSTFS_KMS_LOCAL_MASTER_KEY` | unset | Master key protecting local KMS key files. | -| `RUSTFS_KMS_VAULT_ADDRESS` | unset | Vault server address for the Vault backends. | -| `RUSTFS_KMS_VAULT_TOKEN` | unset | Vault token for the Vault backends. | -| `RUSTFS_KMS_VAULT_MOUNT_PATH` | `transit` | Transit mount for `vault-transit`; deprecated and unused for `vault` / `vault-kv2`. | -| `RUSTFS_KMS_VAULT_KV_MOUNT` | `secret` | KV v2 mount for the `vault` / `vault-kv2` backend. | -| `RUSTFS_KMS_VAULT_KEY_PREFIX` | `rustfs/kms/keys` | Key record prefix within the KV v2 mount for `vault` / `vault-kv2`. | -| `RUSTFS_KMS_DEFAULT_KEY_ID` | unset | Default KMS key ID used for encryption. | -| `RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS` | `false` | Allow development-only insecure KMS defaults. Never enable in production. | - -## Observability - -The observability pipeline exports traces, metrics, and logs over OTLP/HTTP. - -| Variable | Default | Description | +| `RUSTFS_TLS_PATH` | unset | S3 API と Console 用の TLS 証明書と鍵（`rustfs_cert.pem` / `rustfs_key.pem`）を置くディレクトリです。設定すると TLS が有効になります。 | +| `RUSTFS_TLS_RELOAD_ENABLE` | `false` | TLS ディレクトリを監視し、証明書を再読み込みします。 | +| `RUSTFS_TLS_KEYLOG` | `false` | デバッグのため、TLS セッション鍵を keylog ファイルへ書き出します。本番では有効にしないでください。 | +| `RUSTFS_TRUST_SYSTEM_CA` | `false` | 外向きの TLS 接続で、オペレーティングシステムの CA ストアも信頼します。 | +| `RUSTFS_TRUST_LEAF_CERT_AS_CA` | `false` | リーフ証明書を CA であるかのように信頼します（自己署名の構成向けです）。 | +| `RUSTFS_SERVER_MTLS_ENABLE` | `false` | サーバーリスナーでクライアント証明書（相互 TLS）を要求します。 | +| `RUSTFS_MTLS_CLIENT_CERT` | unset | ノード間の mTLS 接続で提示するクライアント証明書です。 | +| `RUSTFS_MTLS_CLIENT_KEY` | unset | ノード間の mTLS 接続に使うクライアント秘密鍵です。 | +| `RUSTFS_KMS_ENABLE` | `false` | KMS を使ったサーバー側の暗号化を有効にします。 | +| `RUSTFS_KMS_BACKEND` | `local` | KMS バックエンドです。指定できる値は `local`、`vault` / `vault-kv2`（ローカルでデータキーをラップする Vault KV2 ストレージ）、`vault-transit` です。 | +| `RUSTFS_KMS_KEY_DIR` | unset | `local` バックエンドのキーディレクトリです。 | +| `RUSTFS_KMS_LOCAL_MASTER_KEY` | unset | ローカル KMS のキーファイルを保護するマスターキーです。 | +| `RUSTFS_KMS_VAULT_ADDRESS` | unset | Vault バックエンドが使う Vault サーバーのアドレスです。 | +| `RUSTFS_KMS_VAULT_TOKEN` | unset | Vault バックエンドが使う Vault トークンです。 | +| `RUSTFS_KMS_VAULT_MOUNT_PATH` | `transit` | `vault-transit` の Transit マウントです。`vault` / `vault-kv2` では非推奨であり、使用されません。 | +| `RUSTFS_KMS_VAULT_KV_MOUNT` | `secret` | `vault` / `vault-kv2` バックエンドの KV v2 マウントです。 | +| `RUSTFS_KMS_VAULT_KEY_PREFIX` | `rustfs/kms/keys` | `vault` / `vault-kv2` で、KV v2 マウント内のキーレコードに付けるプレフィックスです。 | +| `RUSTFS_KMS_DEFAULT_KEY_ID` | unset | 暗号化に使う既定の KMS キー ID です。 | +| `RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS` | `false` | 開発専用の、安全でない KMS 既定値を許可します。本番では決して有効にしないでください。 | + +## オブザーバビリティ + +オブザーバビリティのパイプラインは、トレース、メトリクス、ログを OTLP/HTTP でエクスポートします。 + +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_OBS_ENDPOINT` | empty | Root OTLP/HTTP base URL for traces, metrics, and logs, e.g. `http://otel-collector:4318`. When empty, logs go to stdout or local files. | -| `RUSTFS_OBS_TRACE_ENDPOINT` | unset | Per-signal override for the traces endpoint. | -| `RUSTFS_OBS_METRIC_ENDPOINT` | unset | Per-signal override for the metrics endpoint. | -| `RUSTFS_OBS_LOG_ENDPOINT` | unset | Per-signal override for the logs endpoint. | -| `RUSTFS_OBS_TRACES_EXPORT_ENABLED` | `true` | Export traces to the OTLP endpoint. | -| `RUSTFS_OBS_METRICS_EXPORT_ENABLED` | `true` | Export metrics to the OTLP endpoint. | -| `RUSTFS_OBS_LOGS_EXPORT_ENABLED` | `true` | Export logs to the OTLP endpoint. | -| `RUSTFS_OBS_USE_STDOUT` | unset | Force telemetry output to stdout. | -| `RUSTFS_OBS_SAMPLE_RATIO` | unset | Trace sampling ratio (0.0–1.0). | -| `RUSTFS_OBS_METER_INTERVAL` | unset | Metrics export interval in seconds. | -| `RUSTFS_OBS_SERVICE_NAME` | unset | Service name reported in telemetry resource attributes. | -| `RUSTFS_OBS_ENVIRONMENT` | unset | Deployment environment label (`production`, `development`, `test`, `staging`). | -| `RUSTFS_OBS_LOGGER_LEVEL` | unset | Log level filter (e.g. `info`, `debug`). | -| `RUSTFS_OBS_LOG_STDOUT_ENABLED` | unset | Also mirror logs to stdout when file/OTLP logging is active. | -| `RUSTFS_OBS_LOG_DIRECTORY` | unset | Local log directory. Unset means logs go to stdout; a URL value sends logs to a remote endpoint. | -| `RUSTFS_OBS_LOG_FILENAME` | `rustfs.log` | Log filename inside the log directory. | -| `RUSTFS_OBS_LOG_ROTATION_TIME` | `hourly` | Time-based log rotation: `daily`, `hourly`, `minutely`. | -| `RUSTFS_OBS_LOG_KEEP_FILES` | `30` | Number of rotated log files to keep. | -| `RUSTFS_OBS_LOG_MAX_TOTAL_SIZE_BYTES` | `2147483648` | Total size budget (2 GiB) for the log directory before cleanup. | -| `RUSTFS_OBS_LOG_COMPRESS_OLD_FILES` | `true` | Compress rotated log files (`zstd` by default, controllable via `RUSTFS_OBS_LOG_COMPRESSION_ALGORITHM`). | - -Metrics collection intervals follow the pattern `RUSTFS_METRICS__INTERVAL_SEC` with scopes `DEFAULT`, `SYSTEM`, `CLUSTER`, `BUCKET`, `NODE`, `RESOURCE`, `AUDIT`, `NOTIFICATION`, and `BUCKET_REPLICATION_BANDWIDTH` — for example `RUSTFS_METRICS_CLUSTER_INTERVAL_SEC=60`. - -## Scanner & Healing - -| Variable | Default | Description | +| `RUSTFS_OBS_ENDPOINT` | empty | トレース、メトリクス、ログ共通の OTLP/HTTP ベース URL です。例: `http://otel-collector:4318` 。空の場合、ログは標準出力またはローカルファイルへ出力されます。 | +| `RUSTFS_OBS_TRACE_ENDPOINT` | unset | トレースエンドポイントに対する、シグナル別の上書きです。 | +| `RUSTFS_OBS_METRIC_ENDPOINT` | unset | メトリクスエンドポイントに対する、シグナル別の上書きです。 | +| `RUSTFS_OBS_LOG_ENDPOINT` | unset | ログエンドポイントに対する、シグナル別の上書きです。 | +| `RUSTFS_OBS_TRACES_EXPORT_ENABLED` | `true` | トレースを OTLP エンドポイントへエクスポートします。 | +| `RUSTFS_OBS_METRICS_EXPORT_ENABLED` | `true` | メトリクスを OTLP エンドポイントへエクスポートします。 | +| `RUSTFS_OBS_LOGS_EXPORT_ENABLED` | `true` | ログを OTLP エンドポイントへエクスポートします。 | +| `RUSTFS_OBS_USE_STDOUT` | unset | テレメトリ出力を標準出力へ強制します。 | +| `RUSTFS_OBS_SAMPLE_RATIO` | unset | トレースのサンプリング率です（0.0〜1.0）。 | +| `RUSTFS_OBS_METER_INTERVAL` | unset | メトリクスのエクスポート間隔です。単位は秒です。 | +| `RUSTFS_OBS_SERVICE_NAME` | unset | テレメトリのリソース属性として報告するサービス名です。 | +| `RUSTFS_OBS_ENVIRONMENT` | unset | デプロイ環境のラベルです（`production`、`development`、`test`、`staging`）。 | +| `RUSTFS_OBS_LOGGER_LEVEL` | unset | ログレベルのフィルタです（例: `info`、`debug`）。 | +| `RUSTFS_OBS_LOG_STDOUT_ENABLED` | unset | ファイルまたは OTLP へのログ出力が有効なとき、ログを標準出力へも複製します。 | +| `RUSTFS_OBS_LOG_DIRECTORY` | unset | ローカルのログディレクトリです。未設定の場合、ログは標準出力へ出力されます。URL を指定すると、ログはリモートエンドポイントへ送信されます。 | +| `RUSTFS_OBS_LOG_FILENAME` | `rustfs.log` | ログディレクトリ内のログファイル名です。 | +| `RUSTFS_OBS_LOG_ROTATION_TIME` | `hourly` | 時間に基づくログローテーションです。指定できる値は `daily`、`hourly`、`minutely` です。 | +| `RUSTFS_OBS_LOG_KEEP_FILES` | `30` | 保持するローテーション済みログファイルの数です。 | +| `RUSTFS_OBS_LOG_MAX_TOTAL_SIZE_BYTES` | `2147483648` | クリーンアップ前における、ログディレクトリの合計サイズ上限です（2 GiB）。 | +| `RUSTFS_OBS_LOG_COMPRESS_OLD_FILES` | `true` | ローテーション済みのログファイルを圧縮します（既定は `zstd`。`RUSTFS_OBS_LOG_COMPRESSION_ALGORITHM` で変更できます）。 | + +メトリクスの収集間隔は、`RUSTFS_METRICS__INTERVAL_SEC` というパターンに従います。スコープは `DEFAULT`、`SYSTEM`、`CLUSTER`、`BUCKET`、`NODE`、`RESOURCE`、`AUDIT`、`NOTIFICATION`、`BUCKET_REPLICATION_BANDWIDTH` です。例: `RUSTFS_METRICS_CLUSTER_INTERVAL_SEC=60`。 + +## スキャナーとデータ修復 + +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_SCANNER_SPEED` | `default` | Scanner speed preset: `fastest`, `fast`, `default`, `slow`, `slowest`. Controls sleep factor, max sleep, and cycle interval. | -| `RUSTFS_SCANNER_DELAY` | preset | Overrides the scanner sleep multiplier (e.g. `30.0`). | -| `RUSTFS_SCANNER_MAX_WAIT_SECS` | preset | Overrides the maximum scanner sleep in seconds. | -| `RUSTFS_SCANNER_CYCLE` | preset | Overrides the scan cycle interval in seconds (e.g. `3600`). | -| `RUSTFS_SCANNER_START_DELAY_SECS` | unset | Startup delay in seconds before the first scan cycle. | -| `RUSTFS_SCANNER_CYCLE_MAX_DURATION_SECS` | `1800` | Caps one cycle's runtime in seconds; `0` disables the budget. | -| `RUSTFS_SCANNER_CYCLE_MAX_OBJECTS` | `0` | Caps objects processed per cycle; `0` disables the budget. | -| `RUSTFS_SCANNER_CYCLE_MAX_DIRECTORIES` | `0` | Caps directories entered per cycle; `0` disables the budget. | -| `RUSTFS_SCANNER_BITROT_CYCLE_SECS` | `2592000` | Periodic deep (bitrot) scan cycle in seconds (30 days). `0`/`true`/`on` makes every cycle deep; `false`/`off` disables deep scans. | -| `RUSTFS_SCANNER_IDLE_MODE` | `true` | When `true` the scanner throttles itself; `false` runs at full speed. | -| `RUSTFS_SCANNER_CACHE_SAVE_TIMEOUT_SECS` | `14` | Scanner cache save timeout in seconds (minimum `1`). | -| `RUSTFS_SCANNER_MAX_CONCURRENT_SET_SCANS` | `4` | Caps concurrent erasure-set scan tasks; `0` keeps topology-based concurrency. | -| `RUSTFS_SCANNER_MAX_CONCURRENT_DISK_SCANS` | `4` | Caps concurrent disk bucket walks per set; `0` keeps disk-count-based concurrency. | -| `RUSTFS_SCANNER_YIELD_EVERY_N_OBJECTS` | `128` | How often scanner object loops yield to the async runtime; `0` disables the extra yield. | -| `RUSTFS_SCANNER_ALERT_EXCESS_VERSIONS` | `100` | Object version count that triggers scanner alerts. | -| `RUSTFS_SCANNER_ALERT_EXCESS_VERSION_SIZE` | `1099511627776` | Cumulative version bytes (1 TiB) that trigger scanner alerts. | -| `RUSTFS_SCANNER_ALERT_EXCESS_FOLDERS` | `65538` | Direct subfolder count that triggers scanner alerts. | -| `RUSTFS_HEAL_AUTO_HEAL_ENABLE` | `true` | Enable automatic background healing of degraded objects. | -| `RUSTFS_HEAL_QUEUE_SIZE` | `10000` | Capacity of the heal-candidate queue. | -| `RUSTFS_HEAL_INTERVAL_SECS` | `10` | Interval between heal scheduler runs, in seconds. | -| `RUSTFS_HEAL_TASK_TIMEOUT_SECS` | `300` | Timeout for a single heal task, in seconds. | -| `RUSTFS_HEAL_MAX_CONCURRENT_HEALS` | `4` | Maximum concurrent heal tasks. | -| `RUSTFS_HEAL_MAX_CONCURRENT_PER_SET` | `1` | Maximum concurrent heal tasks per erasure set. | - -## Storage & Erasure - -| Variable | Default | Description | +| `RUSTFS_SCANNER_SPEED` | `default` | スキャナー速度のプリセットです。指定できる値は `fastest`、`fast`、`default`、`slow`、`slowest` です。スリープ係数、最大スリープ、サイクル間隔を制御します。 | +| `RUSTFS_SCANNER_DELAY` | preset | スキャナーのスリープ倍率を上書きします（例: `30.0`）。 | +| `RUSTFS_SCANNER_MAX_WAIT_SECS` | preset | スキャナーの最大スリープ時間を秒単位で上書きします。 | +| `RUSTFS_SCANNER_CYCLE` | preset | スキャンサイクルの間隔を秒単位で上書きします（例: `3600`）。 | +| `RUSTFS_SCANNER_START_DELAY_SECS` | unset | 最初のスキャンサイクルまでの起動遅延です。単位は秒です。 | +| `RUSTFS_SCANNER_CYCLE_MAX_DURATION_SECS` | `1800` | 1 サイクルの実行時間の上限です。単位は秒です。`0` でこの上限を無効にします。 | +| `RUSTFS_SCANNER_CYCLE_MAX_OBJECTS` | `0` | 1 サイクルで処理するオブジェクト数の上限です。`0` でこの上限を無効にします。 | +| `RUSTFS_SCANNER_CYCLE_MAX_DIRECTORIES` | `0` | 1 サイクルで進入するディレクトリ数の上限です。`0` でこの上限を無効にします。 | +| `RUSTFS_SCANNER_BITROT_CYCLE_SECS` | `2592000` | 定期的なディープ（bitrot）スキャンのサイクルです。単位は秒です（30 日）。`0` / `true` / `on` ですべてのサイクルをディープにし、`false` / `off` でディープスキャンを無効にします。 | +| `RUSTFS_SCANNER_IDLE_MODE` | `true` | `true` のとき、スキャナーは自ら処理を抑制します。`false` では全速で実行します。 | +| `RUSTFS_SCANNER_CACHE_SAVE_TIMEOUT_SECS` | `14` | スキャナーキャッシュの保存タイムアウトです。単位は秒です（最小値は `1`）。 | +| `RUSTFS_SCANNER_MAX_CONCURRENT_SET_SCANS` | `4` | 同時に実行するイレイジャーセットのスキャンタスク数の上限です。`0` ではトポロジーに基づく同時実行数を維持します。 | +| `RUSTFS_SCANNER_MAX_CONCURRENT_DISK_SCANS` | `4` | セットあたりで同時に行うディスク上のバケット走査数の上限です。`0` ではディスク数に基づく同時実行数を維持します。 | +| `RUSTFS_SCANNER_YIELD_EVERY_N_OBJECTS` | `128` | スキャナーのオブジェクトループが、非同期ランタイムへ処理を譲る頻度です。`0` で、この追加の譲り渡しを無効にします。 | +| `RUSTFS_SCANNER_ALERT_EXCESS_VERSIONS` | `100` | スキャナーアラートを発生させる、オブジェクトのバージョン数です。 | +| `RUSTFS_SCANNER_ALERT_EXCESS_VERSION_SIZE` | `1099511627776` | スキャナーアラートを発生させる、バージョンの累積バイト数です（1 TiB）。 | +| `RUSTFS_SCANNER_ALERT_EXCESS_FOLDERS` | `65538` | スキャナーアラートを発生させる、直下のサブフォルダー数です。 | +| `RUSTFS_HEAL_AUTO_HEAL_ENABLE` | `true` | 劣化したオブジェクトの自動バックグラウンドデータ修復を有効にします。 | +| `RUSTFS_HEAL_QUEUE_SIZE` | `10000` | 修復候補キューの容量です。 | +| `RUSTFS_HEAL_INTERVAL_SECS` | `10` | 修復スケジューラの実行間隔です。単位は秒です。 | +| `RUSTFS_HEAL_TASK_TIMEOUT_SECS` | `300` | 1 件の修復タスクのタイムアウトです。単位は秒です。 | +| `RUSTFS_HEAL_MAX_CONCURRENT_HEALS` | `4` | 同時に実行する修復タスクの最大数です。 | +| `RUSTFS_HEAL_MAX_CONCURRENT_PER_SET` | `1` | イレイジャーセットあたりの、同時修復タスクの最大数です。 | + +## ストレージとイレイジャーコーディング [#storage--erasure] + +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_STORAGE_CLASS_STANDARD` | auto | Parity for the STANDARD storage class in `EC:n` format, e.g. `EC:4`. When unset, parity is derived from the erasure set size. | -| `RUSTFS_STORAGE_CLASS_RRS` | `EC:1` | Parity for the REDUCED_REDUNDANCY storage class in `EC:n` format. | -| `RUSTFS_STORAGE_CLASS_OPTIMIZE` | `availability` | Optimization goal for parity selection. | -| `RUSTFS_STORAGE_CLASS_INLINE_BLOCK` | `131072` | Threshold (128 KiB) below which object data is inlined into metadata. | -| `RUSTFS_ERASURE_SET_DRIVE_COUNT` | `0` | Force the number of drives per erasure set; `0` selects the layout automatically. | -| `RUSTFS_DURABILITY_MODE` | unset | Write durability mode: `strict`, `relaxed`, or `none`. Takes precedence over the legacy drive-sync switch when set to a valid value. | +| `RUSTFS_STORAGE_CLASS_STANDARD` | auto | STANDARD ストレージクラスのパリティです。形式は `EC:n` です。例: `EC:4`。未設定の場合、パリティはイレイジャーセットのサイズから決まります。 | +| `RUSTFS_STORAGE_CLASS_RRS` | `EC:1` | REDUCED_REDUNDANCY ストレージクラスのパリティです。形式は `EC:n` です。 | +| `RUSTFS_STORAGE_CLASS_OPTIMIZE` | `availability` | パリティ選択における最適化の目標です。 | +| `RUSTFS_STORAGE_CLASS_INLINE_BLOCK` | `131072` | オブジェクトデータをメタデータへインライン化するサイズのしきい値です（128 KiB）。この値未満が対象です。 | +| `RUSTFS_ERASURE_SET_DRIVE_COUNT` | `0` | イレイジャーセットあたりのドライブ数を強制します。`0` ではレイアウトを自動選択します。 | +| `RUSTFS_DURABILITY_MODE` | unset | 書き込みの耐久性モードです。指定できる値は `strict`、`relaxed`、`none` です。有効な値を設定すると、従来のドライブ同期スイッチより優先されます。 | -## Credentials & Internal +## 認証情報と内部設定 -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_ACCESS_KEY` | `rustfsadmin` | Root access key. Mutually exclusive with `RUSTFS_ACCESS_KEY_FILE`. | -| `RUSTFS_SECRET_KEY` | `rustfsadmin` | Root secret key. Mutually exclusive with `RUSTFS_SECRET_KEY_FILE`. | -| `RUSTFS_ACCESS_KEY_FILE` | unset | Path to a file containing the access key (e.g. a Docker/Kubernetes secret mount). | -| `RUSTFS_SECRET_KEY_FILE` | unset | Path to a file containing the secret key. | -| `RUSTFS_RPC_SECRET` | derived | Secret used to authenticate internode RPC. When unset it is derived from the active access/secret key pair; with an all-default credential pair, multi-node clusters must set it explicitly. | +| `RUSTFS_ACCESS_KEY` | `rustfsadmin` | ルートアクセスキーです。`RUSTFS_ACCESS_KEY_FILE` とは同時に指定できません。 | +| `RUSTFS_SECRET_KEY` | `rustfsadmin` | ルートシークレットキーです。`RUSTFS_SECRET_KEY_FILE` とは同時に指定できません。 | +| `RUSTFS_ACCESS_KEY_FILE` | unset | アクセスキーを格納したファイルのパスです（例: Docker や Kubernetes の Secret マウント）。 | +| `RUSTFS_SECRET_KEY_FILE` | unset | シークレットキーを格納したファイルのパスです。 | +| `RUSTFS_RPC_SECRET` | derived | ノード間 RPC の認証に使うシークレットです。未設定の場合は、有効なアクセスキーとシークレットキーの組から導出されます。認証情報がすべて既定値の組である場合、マルチノードクラスターではこの値を明示的に設定する必要があります。 | :::warning -The built-in default credentials `rustfsadmin`/`rustfsadmin` are for first-boot convenience only. Always set non-default credentials for production deployments. +組み込みの既定認証情報 `rustfsadmin`/`rustfsadmin` は、初回起動を簡単にするためのものです。本番デプロイでは、既定以外の認証情報を設定する必要があります。 ::: -## Event & Audit targets +## イベントと監査のターゲット [#event--audit-targets] -Module switches: +モジュールのスイッチ: -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_NOTIFY_ENABLE` | `false` | Enable the bucket event notification module. | -| `RUSTFS_AUDIT_ENABLE` | `false` | Enable the audit logging module. | +| `RUSTFS_NOTIFY_ENABLE` | `false` | バケットイベント通知モジュールを有効にします。 | +| `RUSTFS_AUDIT_ENABLE` | `false` | 監査ログモジュールを有効にします。 | -Target configuration is pattern-based: `RUSTFS_NOTIFY__` for event notification and `RUSTFS_AUDIT__` for audit logs. Supported targets in both families: `WEBHOOK`, `KAFKA`, `MQTT`, `MYSQL`, `POSTGRES`, `NATS`, `REDIS`, `AMQP`, `PULSAR`. +ターゲットの設定はパターンに基づきます。イベント通知は `RUSTFS_NOTIFY__`、監査ログは `RUSTFS_AUDIT__` です。両系統でサポートされるターゲットは `WEBHOOK`、`KAFKA`、`MQTT`、`MYSQL`、`POSTGRES`、`NATS`、`REDIS`、`AMQP`、`PULSAR` です。 -Sub-keys for the webhook target (the same keys exist under `RUSTFS_AUDIT_WEBHOOK_*`): +Webhook ターゲットのサブキーです（同じキーが `RUSTFS_AUDIT_WEBHOOK_*` にもあります）。 -| Variable | Default | Description | +| 変数 | 既定値 | 説明 | | --- | --- | --- | -| `RUSTFS_NOTIFY_WEBHOOK_ENABLE` | `false` | Enable the webhook target. | -| `RUSTFS_NOTIFY_WEBHOOK_ENDPOINT` | unset | Webhook HTTP(S) endpoint URL. | -| `RUSTFS_NOTIFY_WEBHOOK_AUTH_TOKEN` | unset | Bearer token sent with each delivery. | -| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_DIR` | unset | Directory for the persistent delivery queue. | -| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_LIMIT` | unset | Maximum queued events. | -| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CERT` | unset | Client certificate for mTLS to the endpoint. | -| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_KEY` | unset | Client private key for mTLS to the endpoint. | -| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA` | unset | CA certificate used to verify the endpoint. | -| `RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY` | unset | Skip TLS verification of the endpoint (not recommended). | +| `RUSTFS_NOTIFY_WEBHOOK_ENABLE` | `false` | Webhook ターゲットを有効にします。 | +| `RUSTFS_NOTIFY_WEBHOOK_ENDPOINT` | unset | Webhook の HTTP(S) エンドポイント URL です。 | +| `RUSTFS_NOTIFY_WEBHOOK_AUTH_TOKEN` | unset | 各配信に付与する Bearer トークンです。 | +| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_DIR` | unset | 永続的な配信キューのディレクトリです。 | +| `RUSTFS_NOTIFY_WEBHOOK_QUEUE_LIMIT` | unset | キューに入れられるイベントの最大数です。 | +| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CERT` | unset | エンドポイントへの mTLS に使うクライアント証明書です。 | +| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_KEY` | unset | エンドポイントへの mTLS に使うクライアント秘密鍵です。 | +| `RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA` | unset | エンドポイントの検証に使う CA 証明書です。 | +| `RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY` | unset | エンドポイントの TLS 検証を省略します（推奨しません）。 | -Other targets follow the same shape with target-specific keys, e.g. `RUSTFS_NOTIFY_KAFKA_BROKERS`, `RUSTFS_NOTIFY_KAFKA_TOPIC`, `RUSTFS_NOTIFY_MQTT_BROKER`, `RUSTFS_NOTIFY_MQTT_TOPIC`, `RUSTFS_NOTIFY_MYSQL_DSN_STRING`, `RUSTFS_NOTIFY_NATS_ADDRESS`, `RUSTFS_NOTIFY_REDIS_URL`, `RUSTFS_NOTIFY_AMQP_URL`, `RUSTFS_NOTIFY_PULSAR_BROKER`. +ほかのターゲットも同じ形で、ターゲット固有のキーを持ちます。例: `RUSTFS_NOTIFY_KAFKA_BROKERS`、`RUSTFS_NOTIFY_KAFKA_TOPIC`、`RUSTFS_NOTIFY_MQTT_BROKER`、`RUSTFS_NOTIFY_MQTT_TOPIC`、`RUSTFS_NOTIFY_MYSQL_DSN_STRING`、`RUSTFS_NOTIFY_NATS_ADDRESS`、`RUSTFS_NOTIFY_REDIS_URL`、`RUSTFS_NOTIFY_AMQP_URL`、`RUSTFS_NOTIFY_PULSAR_BROKER`。 -## Legacy compatibility +## 従来互換 -### MINIO_* variable mapping +### MINIO_* 変数の対応 -For migration convenience, RustFS maps a fixed allowlist of `MINIO_*` variables to their `RUSTFS_*` equivalents at startup: +移行を簡単にするため、RustFS は起動時に、許可リストで固定された `MINIO_*` 変数を、対応する `RUSTFS_*` へ割り当てます。 -- If only the `MINIO_`-prefixed variable is set, its value is used and a deprecation warning is logged. -- If both `MINIO_*` and `RUSTFS_*` are set with different values, the `RUSTFS_*` value wins and a conflict is recorded. +- `MINIO_` 接頭辞の変数だけが設定されている場合は、その値が使われ、非推奨である旨の警告がログに記録されます。 +- `MINIO_*` と `RUSTFS_*` が異なる値で両方設定されている場合は、`RUSTFS_*` の値が優先され、競合が記録されます。 -The mapped suffixes include `ACCESS_KEY`, `SECRET_KEY`, `ACCESS_KEY_FILE`, `SECRET_KEY_FILE`, `ROOT_USER`, `ROOT_PASSWORD`, `ADDRESS`, `CONSOLE_ADDRESS`, `VOLUMES`, `REGION`, `LICENSE`, `ERASURE_SET_DRIVE_COUNT`, `STORAGE_CLASS_STANDARD`, `STORAGE_CLASS_RRS`, `STORAGE_CLASS_OPTIMIZE`, `STORAGE_CLASS_INLINE_BLOCK`, `SCANNER_SPEED`, `SCANNER_CYCLE`, `COMPRESS_ENABLE`, `COMPRESS_EXTENSIONS`, `COMPRESS_MIME_TYPES`, `DRIVE_ACTIVE_MONITORING`, `ILM_EXPIRATION_WORKERS`, `API_XFF_HEADER`, `POLICY_PLUGIN_URL`, `POLICY_PLUGIN_AUTH_TOKEN`, the `IDENTITY_OPENID_*` keys, and every variable starting with `NOTIFY_WEBHOOK_`, `NOTIFY_MQTT_`, `AUDIT_WEBHOOK_`, or `AUDIT_MQTT_`. For example, `MINIO_ROOT_USER` maps to `RUSTFS_ROOT_USER` and `MINIO_NOTIFY_WEBHOOK_ENDPOINT` maps to `RUSTFS_NOTIFY_WEBHOOK_ENDPOINT`. +対応する接尾辞には、`ACCESS_KEY`、`SECRET_KEY`、`ACCESS_KEY_FILE`、`SECRET_KEY_FILE`、`ROOT_USER`、`ROOT_PASSWORD`、`ADDRESS`、`CONSOLE_ADDRESS`、`VOLUMES`、`REGION`、`LICENSE`、`ERASURE_SET_DRIVE_COUNT`、`STORAGE_CLASS_STANDARD`、`STORAGE_CLASS_RRS`、`STORAGE_CLASS_OPTIMIZE`、`STORAGE_CLASS_INLINE_BLOCK`、`SCANNER_SPEED`、`SCANNER_CYCLE`、`COMPRESS_ENABLE`、`COMPRESS_EXTENSIONS`、`COMPRESS_MIME_TYPES`、`DRIVE_ACTIVE_MONITORING`、`ILM_EXPIRATION_WORKERS`、`API_XFF_HEADER`、`POLICY_PLUGIN_URL`、`POLICY_PLUGIN_AUTH_TOKEN`、`IDENTITY_OPENID_*` の各キー、および `NOTIFY_WEBHOOK_`、`NOTIFY_MQTT_`、`AUDIT_WEBHOOK_`、`AUDIT_MQTT_` で始まるすべての変数が含まれます。たとえば、`MINIO_ROOT_USER` は `RUSTFS_ROOT_USER` に、`MINIO_NOTIFY_WEBHOOK_ENDPOINT` は `RUSTFS_NOTIFY_WEBHOOK_ENDPOINT` に対応します。 -### Deprecated aliases +### 非推奨のエイリアス -| Deprecated variable | Use instead | +| 非推奨の変数 | 代替 | | --- | --- | | `RUSTFS_ROOT_USER` | `RUSTFS_ACCESS_KEY` | | `RUSTFS_ROOT_PASSWORD` | `RUSTFS_SECRET_KEY` | | `RUSTFS_DATA_SCANNER_START_DELAY_SECS` | `RUSTFS_SCANNER_START_DELAY_SECS` | -Deprecated aliases still work but log a warning; the canonical `RUSTFS_*` name always takes precedence when both are set. +非推奨のエイリアスは引き続き動作しますが、警告がログに記録されます。両方を設定した場合、正規の `RUSTFS_*` 名が常に優先されます。 diff --git a/content/ja/reference/index.md b/content/ja/reference/index.md index 8bcb95e50..729593e4f 100644 --- a/content/ja/reference/index.md +++ b/content/ja/reference/index.md @@ -1,11 +1,11 @@ --- -title: "Reference" -description: "Look up RustFS configuration variables and command-line options." +title: "リファレンス" +description: "RustFS の設定変数とコマンドラインオプションを参照します。" --- -Use this section for concise technical references while configuring, operating, or integrating RustFS. +RustFS の設定、運用、連携では、このセクションの簡潔な技術リファレンスを使います。 -## References +## 参照先 -- [Environment Variables](./environment-variables.md) -- [CLI](./cli.md) \ No newline at end of file +- [環境変数](./environment-variables.md) +- [CLI](./cli.md) diff --git a/content/ja/security-compliance/audit-logs.md b/content/ja/security-compliance/audit-logs.md index 593410ac2..e52456909 100644 --- a/content/ja/security-compliance/audit-logs.md +++ b/content/ja/security-compliance/audit-logs.md @@ -1,28 +1,28 @@ --- -title: "Audit Targets" -description: "Configure RustFS audit targets and deliver request-level audit records to external systems." +title: "監査ターゲット" +description: "RustFS の監査ターゲットを設定し、リクエスト単位の監査レコードを外部システムへ配信します。" --- -RustFS Audit Targets send request-level activity records to external systems for security monitoring, compliance, and incident investigation. This guide configures a webhook target and verifies audit delivery with an S3 request. +RustFS の監査ターゲットは、セキュリティ監視、コンプライアンス、インシデント調査のために、リクエスト単位のアクティビティレコードを外部システムへ送ります。このガイドでは、Webhook ターゲットを設定し、S3 リクエストで監査配信を確認します。 -## Overview +## 概要 -Audit Targets and Event Notifications serve different purposes: +監査ターゲットとイベント通知は、目的が異なります。 -| Feature | Audit Targets | Event Notifications | +| 機能 | 監査ターゲット | イベント通知 | | --- | --- | --- | -| Scope | Request and API activity across RustFS | Events selected by each bucket configuration | -| Routing | Every enabled audit target receives audit records | Each bucket rule selects a target | -| Filtering | No per-target event filter | Event, prefix, and suffix filters | -| Typical use | Security information and event management (SIEM), compliance, investigation | Application workflows and data pipelines | +| 対象範囲 | RustFS 全体のリクエストと API アクティビティ | 各バケットの設定で選択したイベント | +| ルーティング | 有効なすべての監査ターゲットが監査レコードを受け取る | 各バケットルールがターゲットを選択する | +| フィルタリング | ターゲットごとのイベントフィルタはない | イベント、プレフィックス、サフィックスのフィルタ | +| 主な用途 | セキュリティ情報およびイベント管理（SIEM）、コンプライアンス、調査 | アプリケーションのワークフローとデータパイプライン | -RustFS supports webhook, Kafka, MQTT, MySQL, PostgreSQL, NATS, Redis, AMQP, and Pulsar audit target families. Each enabled target receives the audit stream independently. +RustFS は、Webhook、Kafka、MQTT、MySQL、PostgreSQL、NATS、Redis、AMQP、Pulsar の監査ターゲットファミリーに対応しています。有効にした各ターゲットは、監査ストリームを独立して受け取ります。 -Audit records can contain request paths, query parameters, selected headers, identity claims, access-key identifiers, remote hosts, user agents, response status, and errors. Protect the destination and restrict access according to your retention and compliance requirements. +監査レコードには、リクエストパス、クエリパラメータ、選択されたヘッダー、アイデンティティクレーム、アクセスキー識別子、リモートホスト、ユーザーエージェント、レスポンスステータス、エラーが含まれることがあります。保存期間とコンプライアンス要件に従って、送信先を保護し、アクセスを制限します。 -## Configuration +## 設定 -Audit delivery is disabled by default. The following environment variables enable the module and create a webhook target named `primary`: +監査配信は、既定では無効です。次の環境変数は、モジュールを有効にし、`primary` という名前の Webhook ターゲットを作成します。 ```bash export RUSTFS_AUDIT_ENABLE="true" @@ -33,69 +33,69 @@ export RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY="/var/lib/rustfs/audit-primary" export RUSTFS_OUTBOUND_ALLOW_ORIGINS="https://audit.example.com" ``` -Restart RustFS after changing environment-managed targets. The target name is the lowercase form of the environment-variable suffix, so `_PRIMARY` creates `primary`. +環境変数で管理するターゲットを変更したあとは、RustFS を再起動します。ターゲット名は環境変数のサフィックスを小文字にしたものなので、`_PRIMARY` は `primary` を作成します。 -RustFS sends a `HEAD` health check to the endpoint origin's root path, such as `https://audit.example.com/`, and sends JSON `POST` requests to the complete configured endpoint. The origin must respond to `HEAD`, while delivery requests must return a successful HTTP status. Allow the RustFS service account to write to the queue directory. +RustFS は、エンドポイントのオリジンのルートパス（`https://audit.example.com/` など）へ `HEAD` ヘルスチェックを送り、設定した完全なエンドポイントへ JSON の `POST` リクエストを送ります。オリジンは `HEAD` に応答する必要があり、配信リクエストは成功した HTTP ステータスを返す必要があります。RustFS プロセスの実行ユーザーが、キューディレクトリへ書き込めるようにします。 -### Webhook settings +### Webhook の設定 -Use the same `_PRIMARY` suffix on all settings for this target: +このターゲットのすべての設定で、同じ `_PRIMARY` サフィックスを使います。 -| Variable | Purpose | +| 変数 | 用途 | | --- | --- | -| `RUSTFS_AUDIT_WEBHOOK_ENDPOINT_PRIMARY` | HTTP or HTTPS delivery endpoint | -| `RUSTFS_AUDIT_WEBHOOK_AUTH_TOKEN_PRIMARY` | Bearer token sent in the `Authorization` header | -| `RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY` | Directory for queued audit records | -| `RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY` | Maximum number of queued records | -| `RUSTFS_AUDIT_WEBHOOK_CLIENT_CERT_PRIMARY` | Client certificate for mutual TLS (mTLS) | -| `RUSTFS_AUDIT_WEBHOOK_CLIENT_KEY_PRIMARY` | Private key paired with the client certificate | -| `RUSTFS_AUDIT_WEBHOOK_CLIENT_CA_PRIMARY` | Certificate authority used to verify the receiver | -| `RUSTFS_AUDIT_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY` | Disable server certificate verification | +| `RUSTFS_AUDIT_WEBHOOK_ENDPOINT_PRIMARY` | HTTP または HTTPS の配信エンドポイント | +| `RUSTFS_AUDIT_WEBHOOK_AUTH_TOKEN_PRIMARY` | `Authorization` ヘッダーで送る Bearer トークン | +| `RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY` | キューに入れた監査レコードのディレクトリ | +| `RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY` | キューに入れられるレコードの最大数 | +| `RUSTFS_AUDIT_WEBHOOK_CLIENT_CERT_PRIMARY` | 相互 TLS（mTLS）用のクライアント証明書 | +| `RUSTFS_AUDIT_WEBHOOK_CLIENT_KEY_PRIMARY` | クライアント証明書と対になる秘密鍵 | +| `RUSTFS_AUDIT_WEBHOOK_CLIENT_CA_PRIMARY` | 受信側を検証するための認証局 | +| `RUSTFS_AUDIT_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY` | サーバー証明書の検証を無効にする | -:::warning[Protect audit data] +:::warning[監査データを保護する] -Use HTTPS for remote collectors. Keep certificate verification enabled, store bearer tokens outside source control, and provide both the client certificate and key when using mTLS. Audit payloads may contain security-sensitive request and identity metadata. +リモートのコレクターには HTTPS を使います。証明書の検証は有効のままにし、Bearer トークンはソース管理の外に保管し、mTLS を使う場合はクライアント証明書と鍵の両方を指定します。監査ペイロードには、セキュリティ上機密なリクエストとアイデンティティのメタデータが含まれることがあります。 ::: -For all target families and target-specific keys, see [Environment Variables](/reference/environment-variables#event--audit-targets). +すべてのターゲットファミリーとターゲット固有のキーについては、[環境変数](/ja/reference/environment-variables#event--audit-targets)を参照します。 -### Multiple targets +### 複数のターゲット -Add a distinct uppercase suffix to define another instance. For example, use `RUSTFS_AUDIT_WEBHOOK_ENABLE_ARCHIVE` and the corresponding `_ARCHIVE` settings to create an `archive` webhook alongside `primary`. +別のインスタンスを定義するには、区別できる大文字のサフィックスを追加します。たとえば、`RUSTFS_AUDIT_WEBHOOK_ENABLE_ARCHIVE` と対応する `_ARCHIVE` の設定を使うと、`primary` と並んで `archive` Webhook を作成できます。 -RustFS fans each audit record out to all enabled targets. A failure in one target does not prevent delivery attempts to the others. +RustFS は、各監査レコードを有効なすべてのターゲットへファンアウトします。1 つのターゲットの失敗は、他のターゲットへの配信試行を妨げません。 -:::note[Environment-managed targets] +:::note[環境変数で管理するターゲット] -A target defined by environment variables cannot be edited or removed through the Console or admin API. Change its environment variables and restart RustFS instead. Do not define the same target through both environment variables and persisted configuration. +環境変数で定義したターゲットは、Console または管理 API から編集または削除できません。環境変数を変更し、RustFS を再起動します。同じターゲットを、環境変数と永続化された設定の両方で定義しないでください。 ::: -## Usage +## 使い方 -:::note[rc command-line support] +:::note[rc のコマンドライン対応] -The current `rc` client does not provide commands for creating, listing, or removing Audit Targets. Configure them through environment variables or the Console. The `rc bucket event` commands manage bucket notification rules only; they do not manage audit delivery. +現在の `rc` クライアントには、監査ターゲットを作成、一覧、削除するコマンドがありません。環境変数または Console で設定します。`rc bucket event` コマンドが管理するのはバケット通知ルールだけであり、監査配信は管理しません。 ::: -### Verify the receiver +### 受信側を確認する -Before generating traffic, verify that the collector is reachable from the RustFS host and accepts the configured bearer token: +トラフィックを生成する前に、コレクターが RustFS ホストから到達でき、設定した Bearer トークンを受け付けることを確認します。 ```bash curl --fail --head \ https://audit.example.com/ ``` -The health check measures origin reachability and does not include the webhook authorization token. Separately confirm that the configured `/rustfs` delivery path accepts `Authorization: Bearer ` on `POST` requests. +ヘルスチェックはオリジンの到達性を測るもので、Webhook の認可トークンは含めません。別に、設定した `/rustfs` 配信パスが `POST` リクエストで `Authorization: Bearer ` を受け付けることを確認します。 -If the target remains offline, check DNS, firewall policy, `RUSTFS_OUTBOUND_ALLOW_ORIGINS`, certificate trust, and the origin's response to `HEAD /`. +ターゲットがオフラインのままの場合は、DNS、ファイアウォールポリシー、`RUSTFS_OUTBOUND_ALLOW_ORIGINS`、証明書の信頼、オリジンの `HEAD /` への応答を確認します。 -### Generate an audit record +### 監査レコードを生成する -Perform an authenticated S3 operation against RustFS: +RustFS に対して認証済みの S3 操作を実行します。 ```bash printf 'hello from RustFS\n' > hello.txt @@ -105,7 +105,7 @@ aws --endpoint-url http://localhost:9000 \ s3 cp hello.txt s3://my-bucket/hello.txt ``` -The webhook receives a JSON audit entry. Fields vary by operation and empty optional fields may be omitted. A representative subset is: +Webhook は JSON の監査エントリを受け取ります。フィールドは操作によって異なり、空の任意フィールドは省略されることがあります。代表的な一部は次のとおりです。 ```json { @@ -128,16 +128,16 @@ The webhook receives a JSON audit entry. Fields vary by operation and empty opti } ``` -Treat the payload schema as additive. Parse the fields you need and tolerate unknown or absent fields so collectors remain compatible with later RustFS releases. +ペイロードのスキーマは追加型として扱います。必要なフィールドを解析し、未知のフィールドや欠落したフィールドを許容することで、コレクターが今後の RustFS リリースとの互換性を保てます。 -### Delivery behavior +### 配信の動作 -When `RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY` is configured, RustFS stores pending records on disk and replays them after transient delivery failures. Size the queue directory and `RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY` for the expected outage window, then monitor both disk usage and target health. +`RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY` を設定すると、RustFS は未送信のレコードをディスクに保存し、一時的な配信失敗のあとで再送します。想定する停止時間に合わせて、キューディレクトリと `RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY` の容量を決め、ディスク使用量とターゲットの健全性の両方を監視します。 -Webhook delivery is at least once. A timeout can occur after the receiver processes a request but before RustFS observes the response, so use `requestID` and other stable fields to deduplicate records where required. +Webhook の配信は少なくとも 1 回です。受信側がリクエストを処理したあと、RustFS が応答を観測する前にタイムアウトすることがあります。必要な場合は、`requestID` とその他の安定したフィールドでレコードを重複排除します。 -The receiver should acknowledge a record only after it has durably accepted it. Returning a non-success status keeps failures visible to the delivery path; silently accepting and discarding a record cannot be recovered by RustFS. +受信側は、レコードを永続的に受け付けたあとでのみ応答確認することを推奨します。成功以外のステータスを返すと、失敗が配信経路から見える状態を保てます。黙って受け付けて破棄したレコードは、RustFS から回復できません。 -## Next steps +## 次のステップ -Configure [Event Notifications](/operations/event-notifications) for bucket-scoped application workflows. Review [Observability](/operations/observability) to monitor service health and [Credentials](/operations/credentials) to limit administrative access. \ No newline at end of file +バケット単位のアプリケーションワークフローには、[イベント通知](/ja/operations/event-notifications)を設定します。サービスの健全性を監視するには[オブザーバビリティ](/ja/operations/observability)を、管理アクセスを制限するには[認証情報](/ja/operations/credentials)を確認します。 diff --git a/content/ja/security-compliance/encryption/index.md b/content/ja/security-compliance/encryption/index.md index 0737b6cfa..36e1e7388 100644 --- a/content/ja/security-compliance/encryption/index.md +++ b/content/ja/security-compliance/encryption/index.md @@ -1,14 +1,14 @@ --- -title: "Data Encryption" -description: "Find the verified RustFS server-side encryption and key management references." +title: "データ暗号化" +description: "検証済みの RustFS のサーバー側の暗号化と鍵管理に関するリファレンスを確認できます。" --- -RustFS provides server-side encryption options for data stored in the object storage service. Use this section to choose the key-management model that matches your security requirements. +RustFS は、オブジェクトストレージサービスに保存するデータ向けに、サーバー側の暗号化の選択肢を提供します。このセクションでは、セキュリティ要件に合う鍵管理モデルを選びます。 -## Encryption options +## 暗号化の選択肢 -- [SSE-S3](./sse-s.md) covers server-managed server-side encryption with the S3 `AES256` mode. -- [SSE-C](./sse-c.md) covers server-side encryption with customer-provided keys. -- [SSE-KMS](./kms.md) covers Local, Vault KV2, and Vault Transit key-management backends. +- [SSE-S3](./sse-s.md)では、S3 の `AES256` モードによる、サーバー管理のサーバー側の暗号化を扱います。 +- [SSE-C](./sse-c.md)では、顧客が提供する鍵によるサーバー側の暗号化を扱います。 +- [SSE-KMS](./kms.md)では、ローカル、Vault KV2、Vault Transit の鍵管理バックエンドを扱います。 -For the currently verified KMS configuration surface, see the [CLI reference](/reference/cli) and [environment variable reference](/reference/environment-variables). \ No newline at end of file +現在検証済みの KMS 設定の対象範囲については、[CLI リファレンス](/ja/reference/cli)と[環境変数リファレンス](/ja/reference/environment-variables)を参照します。 diff --git a/content/ja/security-compliance/encryption/kms.md b/content/ja/security-compliance/encryption/kms.md index a1db65686..4fcb8715a 100644 --- a/content/ja/security-compliance/encryption/kms.md +++ b/content/ja/security-compliance/encryption/kms.md @@ -1,44 +1,44 @@ --- title: "SSE-KMS" -description: "Configure SSE-KMS with a local or HashiCorp Vault KMS backend for RustFS." +description: "RustFS で、ローカルまたは HashiCorp Vault の KMS バックエンドを使って SSE-KMS を設定します。" --- -RustFS Key Management Service (KMS) generates and wraps per-object data encryption keys for [SSE-S3](./sse-s.md) and SSE-KMS. This guide configures SSE-KMS at server startup with a local key store, Vault KV v2, or Vault Transit. +RustFS の鍵管理サービス（KMS）は、[SSE-S3](./sse-s.md) と SSE-KMS のために、オブジェクトごとのデータ暗号化鍵を生成してラップします。このガイドでは、ローカル鍵ストア、Vault KV v2、または Vault Transit を使い、サーバー起動時に SSE-KMS を設定します。 -## Requirements +## 要件 -- Install and configure [`rc`](/operations/rc) for the encryption verification workflow. -- Back up all existing data and KMS key material before changing encryption configuration. -- Apply the same KMS backend and default key ID to every RustFS node. -- Use a process manager or secret manager that injects secrets without committing them to source control. -- For Vault, enable the required secrets engines, create a least-privilege token, and make Vault reachable from every RustFS node. -- Provision a KMS master key before configuring its ID as the RustFS default key. +- 暗号化の確認手順のために、[`rc`](/ja/operations/rc) をインストールして設定します。 +- 暗号化設定を変更する前に、既存のデータと KMS の鍵材料をすべてバックアップします。 +- すべての RustFS ノードに、同じ KMS バックエンドとデフォルト鍵 ID を適用します。 +- シークレットをソース管理にコミットせずに注入する、プロセスマネージャーまたはシークレットマネージャーを使います。 +- Vault では、必要なシークレットエンジンを有効にし、最小権限のトークンを作成し、すべての RustFS ノードから Vault に到達できるようにします。 +- その ID を RustFS のデフォルト鍵として設定する前に、KMS マスターキーを用意します。 -:::warning[Key loss makes encrypted objects unreadable] +:::warning[鍵を失うと暗号化されたオブジェクトは読めなくなります] -RustFS does not store a recoverable copy of your KMS master key outside the configured backend. Back up local key files and their master key, or protect Vault data and recovery credentials, before writing encrypted objects. +RustFS は、設定したバックエンド以外に、回復できる KMS マスターキーのコピーを保存しません。暗号化されたオブジェクトを書き込む前に、ローカルの鍵ファイルとそのマスターキーをバックアップするか、Vault のデータと回復用認証情報を保護します。 ::: -## Choose a backend +## バックエンドを選ぶ -| Backend | `RUSTFS_KMS_BACKEND` | Key storage and wrapping | Intended use | +| バックエンド | `RUSTFS_KMS_BACKEND` | 鍵の保管とラッピング | 想定する用途 | | --- | --- | --- | --- | -| Local | `local` | Key files on the RustFS host | Development, testing, or a carefully backed-up single-host deployment | -| Vault KV2 | `vault` or `vault-kv2` | Master key material in Vault KV v2; data-key wrapping in RustFS | Centralized key storage | -| Vault Transit | `vault-transit` | Cryptographic operations through Vault Transit | Centralized production key management without the KV2 backend mode | +| ローカル | `local` | RustFS ホスト上の鍵ファイル | 開発、テスト、または慎重にバックアップした単一ホストのデプロイ | +| Vault KV2 | `vault` または `vault-kv2` | Vault KV v2 内のマスターキー材料。データ鍵のラッピングは RustFS 内 | 集中管理された鍵の保管 | +| Vault Transit | `vault-transit` | Vault Transit を通じた暗号操作 | KV2 バックエンドモードを使わない、集中管理された本番の鍵管理 | -SSE-S3 and SSE-KMS both require the KMS service to be running. Configuring a bucket default alone does not make encrypted writes succeed when KMS is unavailable. +SSE-S3 と SSE-KMS は、どちらも KMS サービスが稼働している必要があります。バケットのデフォルトだけを設定しても、KMS が利用できないときに暗号化された書き込みが成功するわけではありません。 -## Configure the local backend +## ローカルバックエンドを設定する -Create an absolute key directory owned by the RustFS service account: +RustFS プロセスの実行ユーザーが所有する、絶対パスの鍵ディレクトリを作成します。 ```bash sudo install -d -m 0700 -o rustfs -g rustfs /var/lib/rustfs/kms ``` -Add the KMS settings to the RustFS environment file on every node: +すべてのノードの RustFS 環境ファイルに、KMS 設定を追加します。 ```ini title="/etc/default/rustfs" RUSTFS_KMS_ENABLE=true @@ -47,18 +47,18 @@ RUSTFS_KMS_KEY_DIR=/var/lib/rustfs/kms RUSTFS_KMS_LOCAL_MASTER_KEY= ``` -`RUSTFS_KMS_KEY_DIR` is required by the RustFS server startup path. The local backend writes key files with owner-only permissions. RustFS rejects development defaults such as a temporary key directory or missing local master key unless you explicitly set `RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS=true`; never enable that override in production. +`RUSTFS_KMS_KEY_DIR` は、RustFS サーバーの起動経路で必須です。ローカルバックエンドは、所有者だけがアクセスできる権限で鍵ファイルを書き込みます。一時的な鍵ディレクトリやローカルマスターキーの欠落といった開発用の既定値は、`RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS=true` を明示的に設定しない限り、RustFS が拒否します。本番では、この上書きを有効にしないでください。 -Restart RustFS after updating the environment. This starts the KMS backend but does not create a master key: +環境を更新したあと、RustFS を再起動します。これで KMS バックエンドは起動しますが、マスターキーは作成されません。 ```bash sudo systemctl restart rustfs sudo systemctl status rustfs --no-pager ``` -## Configure Vault KV2 +## Vault KV2 を設定する -Enable a KV v2 engine for master key material and metadata. RustFS reads the master key material and wraps data keys locally; this backend does not call Vault Transit. Configure every RustFS node: +マスターキー材料とメタデータ用に、KV v2 エンジンを有効にします。RustFS はマスターキー材料を読み取り、データ鍵をローカルでラップします。このバックエンドは Vault Transit を呼び出しません。すべての RustFS ノードを設定します。 ```ini title="/etc/default/rustfs" RUSTFS_KMS_ENABLE=true @@ -69,15 +69,15 @@ RUSTFS_KMS_VAULT_KV_MOUNT=secret RUSTFS_KMS_VAULT_KEY_PREFIX=rustfs/kms/keys ``` -The KV mount defaults to `secret` and the key prefix to `rustfs/kms/keys`; the variables above let you select different paths. Use a Vault token authorized for the configured KV data and metadata paths. `RUSTFS_KMS_VAULT_MOUNT_PATH` is deprecated and unused for the KV2 backend. +KV マウントの既定値は `secret`、鍵プレフィックスの既定値は `rustfs/kms/keys` です。上の変数で別のパスを選べます。設定した KV のデータパスとメタデータパスに対して認可された Vault トークンを使います。`RUSTFS_KMS_VAULT_MOUNT_PATH` は非推奨であり、KV2 バックエンドでは使われません。 -Master key material is Base64-encoded in KV2. Any identity with KV read access to the key path can recover the plaintext master key, so restrict that access to trusted RustFS identities. +マスターキー材料は KV2 内で Base64 エンコードされます。鍵パスへの KV 読み取りアクセスを持つアイデンティティは、平文のマスターキーを復元できます。そのアクセスは、信頼できる RustFS のアイデンティティに制限します。 -RustFS validates the Vault URL and rejects insecure development defaults unless `RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS=true` is set. Use HTTPS and a certificate trusted by the RustFS hosts in production. +RustFS は Vault の URL を検証し、`RUSTFS_KMS_ALLOW_INSECURE_DEV_DEFAULTS=true` が設定されていない限り、安全でない開発用の既定値を拒否します。本番では、HTTPS と、RustFS ホストが信頼する証明書を使います。 -## Configure Vault Transit +## Vault Transit を設定する -Enable the Transit engine and configure every RustFS node: +Transit エンジンを有効にし、すべての RustFS ノードを設定します。 ```ini title="/etc/default/rustfs" RUSTFS_KMS_ENABLE=true @@ -87,13 +87,13 @@ RUSTFS_KMS_VAULT_TOKEN= RUSTFS_KMS_VAULT_MOUNT_PATH=transit ``` -Vault Transit retains historical key versions, so rotating a Transit key does not by itself make objects wrapped with an older version unreadable. Keep old versions enabled for as long as objects depend on them. +Vault Transit は過去の鍵バージョンを保持するため、Transit 鍵をローテーションしても、それだけでは古いバージョンでラップされたオブジェクトが読めなくなることはありません。オブジェクトが依存している間は、古いバージョンを有効なままにします。 -## Create and select the default key +## デフォルト鍵を作成して選択する -`RUSTFS_KMS_DEFAULT_KEY_ID` selects an existing key; it does not create one. Start the KMS backend without this variable, create the key, and only then add the variable and restart RustFS. +`RUSTFS_KMS_DEFAULT_KEY_ID` は既存の鍵を選択します。鍵は作成しません。この変数なしで KMS バックエンドを起動し、鍵を作成してから、変数を追加して RustFS を再起動します。 -When your installed `rc` exposes the KMS lifecycle commands, create and inspect a key with: +インストール済みの `rc` が KMS のライフサイクルコマンドを提供している場合は、次のコマンドで鍵を作成して確認します。 ```bash rc admin kms status rustfs @@ -101,29 +101,31 @@ rc admin kms key create rustfs --name rustfs-default-key rc admin kms key status rustfs rustfs-default-key ``` -Then add the same default key ID on every RustFS node: +その後、すべての RustFS ノードに同じデフォルト鍵 ID を追加します。 ```ini title="/etc/default/rustfs" RUSTFS_KMS_DEFAULT_KEY_ID=rustfs-default-key ``` -Restart every node consistently after changing the default. +デフォルトを変更したあとは、すべてのノードを一貫して再起動します。 -For Vault Transit, you can alternatively create the named Transit key directly in Vault before configuring it as the default: +Vault Transit では、デフォルトとして設定する前に、名前付きの Transit 鍵を Vault 上で直接作成することもできます。 ```bash vault write -f transit/keys/rustfs-default-key ``` -:::note[rc version boundary] +:::note[rc のバージョン要件] -The tested `rc 0.1.29` on the validation host does not expose `rc admin kms`; it supports only the bucket and object encryption commands used below. Run `rc admin --help` before following the key lifecycle commands. If the KMS command family is absent, use a newer `rc` release that includes it or provision the key through the native RustFS KMS Admin API. +`rc 0.1.29` には `rc admin kms` が含まれていません。対応しているのは、以下で使うバケットとオブジェクトの暗号化コマンドだけです。鍵のライフサイクルコマンドに従う前に、`rc admin --help` を実行します。KMS のコマンドファミリーがない場合は、それを含む新しい `rc` リリースを使うか、ネイティブの RustFS KMS Admin API で鍵を用意します。 ::: -## Verify KMS-backed encryption + -Create a test bucket, configure SSE-KMS with the default key, upload an object, and read it back: +## KMS を使った暗号化を確認する + +テスト用バケットを作成し、デフォルト鍵で SSE-KMS を設定し、オブジェクトをアップロードして読み戻します。 ```bash rc bucket create rustfs/my-bucket @@ -133,7 +135,7 @@ rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt rc object show rustfs/my-bucket/hello.txt ``` -To select a specific KMS key, set it on the bucket default or the individual write: +特定の KMS 鍵を選ぶには、バケットのデフォルトか、個々の書き込みに設定します。 ```bash rc bucket encryption set rustfs/my-bucket \ @@ -144,17 +146,17 @@ rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt \ --enc-kms rustfs/my-bucket/hello.txt=rustfs-default-key ``` -The selector before `=` must exactly match the destination passed to `rc object copy`. +`=` の前のセレクターは、`rc object copy` に渡す宛先と完全に一致する必要があります。 -## Rotate and recover keys +## 鍵をローテーションして回復する -- **Vault token:** issue a replacement token, update every RustFS node, restart consistently, verify encrypted reads and writes, and then revoke the old token. -- **Vault Transit key:** rotate the Transit key in Vault. New wrapping operations use the new version while Vault retains older versions for decryption. -- **Local or Vault KV2 key material:** back up the current material before rotation and verify that objects written before and after rotation remain readable. -- **Existing objects:** rotating a master key does not rewrite object data. Each object keeps the wrapped data key stored with its encryption metadata. +- **Vault トークン:** 代替トークンを発行し、すべての RustFS ノードを更新し、一貫して再起動し、暗号化された読み取りと書き込みを確認してから、古いトークンを失効させます。 +- **Vault Transit 鍵:** Vault で Transit 鍵をローテーションします。新しいラッピング操作は新しいバージョンを使い、Vault は復号のために古いバージョンを保持します。 +- **ローカルまたは Vault KV2 の鍵材料:** ローテーションの前に現在の材料をバックアップし、ローテーションの前後に書き込まれたオブジェクトが読めることを確認します。 +- **既存のオブジェクト:** マスターキーをローテーションしても、オブジェクトデータは書き換えられません。各オブジェクトは、暗号化メタデータとともに保存された、ラップ済みのデータ鍵を保持します。 -Do not delete or disable an old master-key version until you have established that no retained object depends on it. +保持しているオブジェクトが古いマスターキーのバージョンに依存していないことを確認するまで、そのバージョンを削除または無効にしないでください。 -## Next steps +## 次のステップ -Configure [SSE-S3](./sse-s.md), or use [SSE-C](./sse-c.md) when the client must retain control of the encryption key. \ No newline at end of file +[SSE-S3](./sse-s.md) を設定します。クライアントが暗号化鍵の制御を保持する必要がある場合は、[SSE-C](./sse-c.md) を使います。 diff --git a/content/ja/security-compliance/encryption/sse-c.md b/content/ja/security-compliance/encryption/sse-c.md index f397d1b62..2ebf3b7c6 100644 --- a/content/ja/security-compliance/encryption/sse-c.md +++ b/content/ja/security-compliance/encryption/sse-c.md @@ -1,26 +1,26 @@ --- title: "SSE-C" -description: "Use customer-provided AES-256 keys for RustFS object encryption and decryption." +description: "顧客が提供する AES-256 鍵を使い、RustFS のオブジェクトを暗号化および復号します。" --- -SSE-C encrypts an object with a 256-bit key supplied by the client on every write and read request. RustFS validates and uses the key for the request but does not persist the plaintext customer key. SSE-C does not use the RustFS KMS backend. +SSE-C は、書き込みと読み取りのリクエストごとにクライアントが提供する 256 ビット鍵でオブジェクトを暗号化します。RustFS はリクエストのために鍵を検証して使いますが、平文の顧客鍵は永続化しません。SSE-C は RustFS の KMS バックエンドを使いません。 -## Requirements +## 要件 -- Install and configure [`rc`](/operations/rc). -- Install OpenSSL for the key-generation example. -- Use HTTPS so customer keys are encrypted in transit. -- Store the customer key in a secret manager and maintain a mapping between each object and its key. +- [`rc`](/ja/operations/rc) をインストールして設定します。 +- 鍵生成の例のために OpenSSL をインストールします。 +- 顧客鍵が転送中に暗号化されるよう、HTTPS を使います。 +- 顧客鍵はシークレットマネージャーに保管し、各オブジェクトと鍵の対応関係を維持します。 -:::warning[The same key is required for every read] +:::warning[読み取りのたびに同じ鍵が必要です] -If you lose an SSE-C key, RustFS cannot recover it and the object becomes unreadable. Never log, commit, or send the key over an unencrypted connection. +SSE-C 鍵を失うと、RustFS は回復できず、オブジェクトは読めなくなります。鍵をログに記録したり、コミットしたり、暗号化されていない接続で送ったりしないでください。 ::: -## Prepare a customer key +## 顧客鍵を用意する -Generate 32 random bytes through a hexadecimal intermediate, then derive the Base64 key and its Base64-encoded MD5 checksum: +16 進数の中間表現を経由して 32 バイトの乱数を生成し、Base64 鍵とその Base64 エンコードされた MD5 チェックサムを導出します。 ```bash SSE_C_KEY_HEX=$(openssl rand -hex 32) @@ -29,11 +29,11 @@ SSE_C_KEY_MD5=$(printf '%s' "$SSE_C_KEY_HEX" | xxd -r -p \ | openssl dgst -md5 -binary | openssl base64 -A) ``` -Move these values into your approved secret-management workflow. Do not print them to the terminal or shell history. +これらの値は、承認されたシークレット管理の手順へ移します。端末やシェル履歴には出力しないでください。 -## Upload an encrypted object +## 暗号化したオブジェクトをアップロードする -`rc 0.1.29` has no dedicated SSE-C option. Its signed custom-header option can send the three S3 SSE-C headers: +`rc 0.1.29` には専用の SSE-C オプションがありません。署名付きカスタムヘッダーを送るオプションで、3 つの S3 SSE-C ヘッダーを送れます。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt \ @@ -42,17 +42,17 @@ rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt \ -H "x-amz-server-side-encryption-customer-key-md5:$SSE_C_KEY_MD5" ``` -The required request headers are: +必要なリクエストヘッダーは次のとおりです。 -| Header | Value | +| ヘッダー | 値 | | --- | --- | | `x-amz-server-side-encryption-customer-algorithm` | `AES256` | -| `x-amz-server-side-encryption-customer-key` | Base64-encoded 32-byte key | -| `x-amz-server-side-encryption-customer-key-md5` | Base64-encoded MD5 digest of the raw key | +| `x-amz-server-side-encryption-customer-key` | Base64 エンコードされた 32 バイトの鍵 | +| `x-amz-server-side-encryption-customer-key-md5` | 生の鍵の MD5 ダイジェストを Base64 エンコードした値 | -## Read the encrypted object +## 暗号化したオブジェクトを読み取る -Supply the same three headers on reads and metadata requests: +読み取りとメタデータのリクエストには、同じ 3 つのヘッダーを指定します。 ```bash rc object show rustfs/my-bucket/hello.txt \ @@ -61,24 +61,24 @@ rc object show rustfs/my-bucket/hello.txt \ -H "x-amz-server-side-encryption-customer-key-md5:$SSE_C_KEY_MD5" ``` -The same workflow was validated with `rc 0.1.29` against RustFS by uploading an object, reading it with the original key, and comparing the returned bytes with the source. +同じ手順は、`rc 0.1.29` を使って RustFS に対して検証済みです。オブジェクトをアップロードし、元の鍵で読み取り、返されたバイト列をソースと比較しています。 -:::warning[Protect command arguments] +:::warning[コマンド引数を保護する] -The generic `-H` method places expanded header values in the `rc` process arguments, which may be visible to other processes on the host. For production automation, prefer an S3 SDK that accepts SSE-C key material through protected memory or a credential provider instead of command-line arguments. +汎用の `-H` 方式は、展開されたヘッダー値を `rc` プロセスの引数に置くため、ホスト上の他のプロセスから見えることがあります。本番の自動化では、コマンドライン引数ではなく、保護されたメモリまたは認証情報プロバイダーを通じて SSE-C の鍵材料を受け取る S3 SDK を使うことを推奨します。 ::: -## Clear shell variables +## シェル変数を消去する -After the operation, remove key material from the shell environment: +操作のあと、シェル環境から鍵材料を削除します。 ```bash unset SSE_C_KEY_HEX SSE_C_KEY_B64 SSE_C_KEY_MD5 ``` -Changing a bucket's SSE-S3 or SSE-KMS default does not alter SSE-C objects. SSE-C is selected by the customer-key headers on each individual request and takes precedence for that request. +バケットの SSE-S3 または SSE-KMS のデフォルトを変更しても、SSE-C オブジェクトは変わりません。SSE-C は、個々のリクエストの顧客鍵ヘッダーによって選択され、そのリクエストでは優先されます。 -## Next steps +## 次のステップ -Compare [SSE-S3](./sse-s.md) for server-managed encryption and [KMS](./kms.md) for explicit KMS-backed key management. \ No newline at end of file +サーバー管理の暗号化については [SSE-S3](./sse-s.md) を、明示的な KMS による鍵管理については [KMS](./kms.md) を比較します。 diff --git a/content/ja/security-compliance/encryption/sse-s.md b/content/ja/security-compliance/encryption/sse-s.md index 7a4a9929b..46072925e 100644 --- a/content/ja/security-compliance/encryption/sse-s.md +++ b/content/ja/security-compliance/encryption/sse-s.md @@ -1,77 +1,77 @@ --- title: "SSE-S3" -description: "Configure server-managed SSE-S3 encryption for RustFS buckets and object writes." +description: "RustFS のバケットとオブジェクト書き込みに、サーバー管理の SSE-S3 暗号化を設定します。" --- -SSE-S3 uses the S3 `AES256` encryption mode. RustFS generates a unique data encryption key for each encrypted object and uses the configured KMS service to wrap that key. Clients do not provide or retain the encryption key. +SSE-S3 は、S3 の `AES256` 暗号化モードを使います。RustFS は、暗号化するオブジェクトごとに一意のデータ暗号化鍵を生成し、設定した KMS サービスでその鍵をラップします。クライアントは暗号化鍵を提供せず、保持もしません。 -## Requirements +## 要件 -- Configure and start [KMS](./kms.md), create its default key, and verify the key is available before enabling SSE-S3. -- Install and configure [`rc`](/operations/rc). -- Create the target bucket and verify that normal object writes succeed. +- [KMS](./kms.md) を設定して起動し、デフォルト鍵を作成し、SSE-S3 を有効にする前にその鍵が利用できることを確認します。 +- [`rc`](/ja/operations/rc) をインストールして設定します。 +- 対象のバケットを作成し、通常のオブジェクト書き込みが成功することを確認します。 -:::warning[KMS availability is required] +:::warning[KMS が利用できることが必要です] -RustFS accepts an SSE-S3 bucket default even when KMS is unavailable, but encrypted object writes then fail. Verify an encrypted write and read before using the bucket for production data. +KMS が利用できない場合でも、RustFS は SSE-S3 のバケットデフォルトを受け付けます。ただし、その状態で暗号化したオブジェクトの書き込みは失敗します。本番データにバケットを使う前に、暗号化された書き込みと読み取りを確認します。 ::: -## Set bucket default encryption +## バケットのデフォルト暗号化を設定する -Apply SSE-S3 to new writes that do not specify an object-level encryption mode: +オブジェクト単位の暗号化モードを指定しない新しい書き込みに、SSE-S3 を適用します。 ```bash rc bucket encryption set rustfs/my-bucket --mode sse-s3 rc bucket encryption info rustfs/my-bucket ``` -The reported mode should be `SSE-S3`. +報告されるモードは `SSE-S3` になるはずです。 -Upload and read a test object: +テストオブジェクトをアップロードして読み取ります。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt rc object show rustfs/my-bucket/hello.txt ``` -## Encrypt one object explicitly +## 1 つのオブジェクトを明示的に暗号化する -Apply SSE-S3 to a single destination without changing the bucket default: +バケットのデフォルトを変えずに、単一の宛先へ SSE-S3 を適用します。 ```bash rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt \ --enc-s3 rustfs/my-bucket/hello.txt ``` -For recursive writes, the encryption selector must exactly match the destination prefix: +再帰的な書き込みでは、暗号化セレクターが宛先のプレフィックスと完全に一致する必要があります。 ```bash rc object copy ./reports/ rustfs/my-bucket/reports/ --recursive \ --enc-s3 rustfs/my-bucket/reports/ ``` -## Clear the bucket default +## バケットのデフォルトを解除する -Remove the default rule: +デフォルトルールを削除します。 ```bash rc bucket encryption clear rustfs/my-bucket rc bucket encryption info rustfs/my-bucket ``` -Clearing or changing the bucket default affects only later writes. It does not decrypt or rewrite existing objects. +バケットのデフォルトを解除または変更しても、影響するのは以降の書き込みだけです。既存のオブジェクトは復号も書き換えもされません。 -## Request contract +## リクエストヘッダー -S3 clients request SSE-S3 with: +S3 クライアントは、次のヘッダーで SSE-S3 を要求します。 ```http x-amz-server-side-encryption: AES256 ``` -An object-level request overrides the bucket default for that write. If no object-level mode is supplied, RustFS resolves the effective mode from the bucket encryption configuration. +オブジェクト単位のリクエストは、その書き込みについてバケットのデフォルトを上書きします。オブジェクト単位のモードが指定されていない場合、RustFS はバケットの暗号化設定から有効なモードを解決します。 -## Next steps +## 次のステップ -Use [SSE-KMS](./kms.md#verify-kms-backed-encryption) when you need an explicit KMS key ID, or compare [SSE-C](./sse-c.md) for client-held keys. \ No newline at end of file +明示的な KMS 鍵 ID が必要な場合は [SSE-KMS](./kms.md#verify-kms-backed-encryption) を使います。クライアントが保持する鍵については [SSE-C](./sse-c.md) と比較します。 diff --git a/content/ja/security-compliance/iam/access-token.md b/content/ja/security-compliance/iam/access-token.md index f3442e3b1..5bf5f1070 100644 --- a/content/ja/security-compliance/iam/access-token.md +++ b/content/ja/security-compliance/iam/access-token.md @@ -1,29 +1,29 @@ --- -title: "RustFS Access Key Management" -description: "Creation, usage, and deletion of RustFS access keys." +title: "アクセスキー" +description: "Console で RustFS のアクセスキーを作成および削除します。" --- -RustFS access keys are the core credentials of the RustFS system, used for identity authentication and operation authorization, and are very useful in API and SDK scenarios. This chapter introduces the creation and deletion of RustFS access keys. +アクセスキーは、アプリケーションやツールが RustFS への認証とリクエストの認可に使う認証情報です。このページでは、Console でアクセスキーを作成および削除する方法を説明します。 -Prerequisites: +## 前提条件 -- An available RustFS instance. You can refer to the [Installation Guide](../../installation/index.md) for installation. +- 稼働中の RustFS インスタンス。手順は[インストールガイド](../../installation/index.md)を参照します。 -## Creating Access Keys +## アクセスキーの作成 -1. Log in to the RustFS UI console. -2. In the left navigation bar, select **Access Keys**. -3. On the access keys page, in the upper right corner, click **Add Access Key**. -4. Enter the key's **expiration time, name, and description**, then click **Submit**. -5. (Optional but recommended). On the access key page that appears, select **Copy** or **Export** to save the access key for future use. +1. RustFS Console にサインインします。 +2. 左のナビゲーションバーで **Access Keys**（アクセスキー）を選択します。 +3. アクセスキーのページで、右上の **Add Access Key**（アクセスキーの追加）をクリックします。 +4. キーの **Expiration**（有効期限）、**Name**（名前）、**Description**（説明）を入力し、**Submit**（送信）を選択します。 +5. （推奨）表示されたページで **Copy**（コピー）または **Export**（エクスポート）を選択し、キーを保存します。 -![access key list page](images/access_token_creation.png) +![アクセスキーの一覧ページ](images/access_token_creation.png) -## Deleting Access Keys +## アクセスキーの削除 -1. Log in to the RustFS UI console. -2. In the left navigation bar, select **Access Keys**. -3. On the access keys page, select the access key you want to delete. -4. Select the **Delete** button on the right side of the access key or **Delete Selected Items** in the upper right corner to delete the access key. +1. RustFS Console にサインインします。 +2. 左のナビゲーションバーで **Access Keys** を選択します。 +3. アクセスキーのページで、削除するアクセスキーを選択します。 +4. アクセスキーの横にある **Delete**（削除）を選択するか、右上の **Delete Selected Items**（選択項目の削除）を選択します。 -![access key deletion](images/access_token_deletion.png) \ No newline at end of file +![アクセスキーの削除](images/access_token_deletion.png) diff --git a/content/ja/security-compliance/iam/index.md b/content/ja/security-compliance/iam/index.md index 2d23161d0..98e8e0f9d 100644 --- a/content/ja/security-compliance/iam/index.md +++ b/content/ja/security-compliance/iam/index.md @@ -1,54 +1,56 @@ --- -title: "RustFS IAM Management" -description: "Overview of RustFS Identity and Access Management (IAM): identity types, policy attachment, and policy evaluation semantics." +title: "アイデンティティとアクセス管理（IAM）" +description: "RustFS のアイデンティティとアクセス管理（IAM）について、アイデンティティの種類、ポリシーの割り当て、ポリシー評価の意味を説明します。" --- -RustFS ships a built-in Identity and Access Management (IAM) system modeled on the AWS IAM policy language. Every request — S3 data access, Console operation, or admin API call — is authenticated against a credential and then authorized against the policies attached to that identity. +RustFS には、AWS IAM のポリシー言語をモデルにした、組み込みのアイデンティティとアクセス管理（IAM）があります。S3 のデータアクセス、Console の操作、管理 API の呼び出しを問わず、すべてのリクエストは認証情報で認証されたあと、そのアイデンティティに割り当てられたポリシーで認可されます。 -## Identity Types +## アイデンティティの種類 -RustFS distinguishes the following identity types: +RustFS では、次のアイデンティティの種類を区別します。 -| Identity | Created by | Typical use | +| アイデンティティ | 作成方法 | 主な用途 | | --- | --- | --- | -| Root credentials | `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables at server start | Initial setup and break-glass administration. The root account bypasses IAM identity-policy evaluation (owner semantics). | -| IAM users | Console or admin API (`add-user`) | Long-term named accounts for people or applications. | -| Groups | Console or admin API (`update-group-members`) | Attach one policy set to many users at once. Users inherit the policies of every group they belong to. | -| Service accounts (access keys) | Console or admin API (`add-service-account`) | Derived credentials that belong to a parent user. They inherit the parent's permissions, optionally restricted further by an embedded session policy, and can carry an expiration time. | -| STS temporary credentials | `AssumeRole` / `AssumeRoleWithWebIdentity` STS calls | Short-lived credentials (15 minutes to 12 hours) with an access key, secret key, and session token. | -| External OIDC identities | OpenID Connect providers (Keycloak, Authing, and other standard OIDC IdPs) | Console SSO. ID token claims are mapped to RustFS policy names, and RustFS issues STS credentials. | +| ルート認証情報 | サーバー起動時の環境変数 `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` | 初期設定と緊急時の管理。ルートアカウントは IAM のアイデンティティポリシー評価を迂回します（所有者としての扱い）。 | +| IAM ユーザー | Console または管理 API（`add-user`） | 人またはアプリケーション向けの、長期の名前付きアカウント。 | +| グループ | Console または管理 API（`update-group-members`） | 1 組のポリシーを多数のユーザーに一度に割り当てます。ユーザーは、所属するすべてのグループのポリシーを継承します。 | +| サービスアカウント（アクセスキー） | Console または管理 API（`add-service-account`） | 親ユーザーに属する派生認証情報です。親の権限を継承し、任意で埋め込まれたセッションポリシーによってさらに制限でき、有効期限を持てます。 | +| STS の一時認証情報 | `AssumeRole` / `AssumeRoleWithWebIdentity` の STS 呼び出し | アクセスキー、シークレットキー、セッショントークンを持つ短期間の認証情報（15 分から 12 時間）。 | +| 外部 OIDC アイデンティティ | OpenID Connect プロバイダー（Keycloak、Authing、その他の標準 OIDC IdP） | Console のシングルサインオン。ID トークンのクレームは RustFS のポリシー名に対応付けられ、RustFS は STS の一時認証情報を発行します。 | :::warning -Root credentials bypass IAM identity policies, but bucket policies can still deny root S3 requests. Only `GetBucketPolicy`, `PutBucketPolicy`, and `DeleteBucketPolicy` bypass a bucket-policy deny so the owner can recover access. Use root credentials only to bootstrap the deployment, then create IAM users and service accounts for day-to-day work. +ルート認証情報は IAM のアイデンティティポリシーを迂回しますが、バケットポリシーはルートの S3 リクエストを拒否できます。バケットポリシーの拒否を迂回するのは `GetBucketPolicy`、`PutBucketPolicy`、`DeleteBucketPolicy` だけであり、これは所有者がアクセスを回復できるようにするためです。ルート認証情報はデプロイの初期設定にだけ使い、日常の作業には IAM ユーザーとサービスアカウントを作成します。 ::: -## How Policies Attach to Identities +## ポリシーとアイデンティティの対応 -Policies are named JSON documents stored in RustFS. Attachment works as follows: +ポリシーは、RustFS に保存される名前付きの JSON ドキュメントです。割り当ては次のように機能します。 -- **User binding** — one or more policy names are attached to an IAM user (`set-user-or-group-policy`, or the `idp/builtin/policy/attach` endpoint which accepts a list of policies). -- **Group binding** — the same mechanism with `isGroup=true`; every member of the group receives the group's policies in addition to their own. -- **Service accounts** — do not get their own policy bindings. They evaluate under the parent user's combined policies. If the service account was created with an explicit policy document, that session policy is applied as an additional restriction (both must allow). -- **STS sessions** — inherit the parent identity's policies. The `Policy` request parameter of `AssumeRole` can embed an additional session policy that further restricts the temporary credentials. -- **OIDC identities** — the ID token's `groups`/`roles` claim values are matched against RustFS policy names; the matched policies govern the issued STS credentials. +- **ユーザーへの割り当て** — 1 つ以上のポリシー名を IAM ユーザーに割り当てます（`set-user-or-group-policy`、またはポリシーのリストを受け付ける `idp/builtin/policy/attach` エンドポイント）。 +- **グループへの割り当て** — `isGroup=true` による同じ仕組みです。グループの各メンバーは、自身のポリシーに加えてグループのポリシーを受け取ります。 +- **サービスアカウント** — 独自のポリシー割り当ては持ちません。親ユーザーのポリシーを組み合わせた結果の下で評価されます。サービスアカウント作成時に明示的なポリシードキュメントを指定した場合、そのセッションポリシーは追加の制限として適用されます（両方で許可される必要があります）。 +- **STS セッション** — 親アイデンティティのポリシーを継承します。`AssumeRole` のリクエストパラメータ `Policy` で、一時認証情報をさらに制限する追加のセッションポリシーを埋め込めます。 +- **OIDC アイデンティティ** — ID トークンの `groups` と `roles` のクレーム値が RustFS のポリシー名と照合されます。一致したポリシーが、発行される STS の一時認証情報を制御します。 -RustFS ships these built-in (canned) policies: `readwrite`, `readonly`, `writeonly`, `diagnostics`, and `consoleAdmin`. See [Users, Groups, and Policies](./policies.md) for their contents and for writing custom policies. +RustFS には、次の組み込み（canned）ポリシーがあります。`readwrite`、`readonly`、`writeonly`、`diagnostics`、`consoleAdmin` です。内容とカスタムポリシーの書き方は、[ユーザー、グループ、ポリシー](./policies.md)を参照します。 -## Policy Evaluation Semantics + -When an identity has multiple attached policies, RustFS merges their statements (dropping duplicates) and evaluates the merged document: +## ポリシー評価の意味 -1. **Explicit deny wins.** All `Deny` statements are checked first; if any matching `Deny` statement applies to the request, the request is rejected regardless of any `Allow`. -2. **Owner shortcut.** The root account bypasses IAM identity-policy evaluation; the bucket-policy checks and exceptions described above still apply. -3. **Explicit allow required.** Otherwise, at least one `Allow` statement must match the requested action and resource. -4. **Default deny.** If no statement matches, the request is denied. +アイデンティティに複数のポリシーが割り当てられている場合、RustFS はステートメントを統合し（重複は除く）、統合したドキュメントを評価します。 -For service accounts and STS sessions carrying a session policy, the effective permission is the intersection: the parent's policies and the session policy must both allow the request. +1. **明示的な拒否が優先されます。** すべての `Deny` ステートメントを最初に確認します。リクエストに一致する `Deny` ステートメントがあれば、`Allow` の有無にかかわらずリクエストは拒否されます。 +2. **所有者の特例。** ルートアカウントは IAM のアイデンティティポリシー評価を迂回します。上記のバケットポリシーの確認と例外は、引き続き適用されます。 +3. **明示的な許可が必要です。** それ以外の場合、要求されたアクションとリソースに一致する `Allow` ステートメントが少なくとも 1 つ必要です。 +4. **既定は拒否です。** 一致するステートメントがなければ、リクエストは拒否されます。 -## In This Section +セッションポリシーを持つサービスアカウントと STS セッションでは、有効な権限は積集合です。親のポリシーとセッションポリシーの両方が、リクエストを許可する必要があります。 -- [Users, Groups, and Policies](./policies.md) — managing users and groups, the policy document format, and built-in policies. -- [Service Accounts and STS](./sts.md) — derived access keys and temporary credentials via `AssumeRole`. -- [Access Keys](./access-token.md) — creating and deleting access keys from the Console. +## このセクションの内容 + +- [ユーザー、グループ、ポリシー](./policies.md) — ユーザーとグループの管理、ポリシードキュメントの形式、組み込みポリシー。 +- [サービスアカウントと STS](./sts.md) — `AssumeRole` による派生アクセスキーと一時認証情報。 +- [アクセスキー](./access-token.md) — Console からのアクセスキーの作成と削除。 diff --git a/content/ja/security-compliance/iam/policies.md b/content/ja/security-compliance/iam/policies.md index 0ff276e6e..30f8c11c0 100644 --- a/content/ja/security-compliance/iam/policies.md +++ b/content/ja/security-compliance/iam/policies.md @@ -7,7 +7,7 @@ description: "RustFS の IAM ユーザーとグループの管理、ポリシー ## 要件 -- RustFS の管理コマンドを使う前に、[`rc`](/operations/rc) をインストールします。 +- RustFS の管理コマンドを使う前に、[`rc`](/ja/operations/rc) をインストールします。 - 対応する `admin:*` アクションを許可する認証情報で、エイリアスを設定します。 ## ユーザーの管理 @@ -74,7 +74,7 @@ description: "RustFS の IAM ユーザーとグループの管理、ポリシー | ポリシーの作成または置換 | `PUT /rustfs/admin/v3/add-canned-policy?name=` | リクエスト本文はポリシーの JSON ドキュメントです。`admin:CreatePolicy` が必要です。 | | ポリシーの削除 | `DELETE /rustfs/admin/v3/remove-canned-policy?name=` | `admin:DeletePolicy` が必要です。 | -## ポリシードキュメントの形式 +## ポリシードキュメントの形式 [#policy-document-format] ポリシードキュメントは、`Version` と `Statement` フィールドを持つ JSON オブジェクトです。受け付ける `Version` の値は `2012-10-17` だけです。 diff --git a/content/ja/security-compliance/iam/sts.md b/content/ja/security-compliance/iam/sts.md index 8ba58d53b..02385037f 100644 --- a/content/ja/security-compliance/iam/sts.md +++ b/content/ja/security-compliance/iam/sts.md @@ -1,34 +1,34 @@ --- -title: "Service Accounts and STS" -description: "RustFS service accounts (derived access keys) and temporary credentials via the STS AssumeRole API." +title: "サービスアカウントと STS" +description: "RustFS のサービスアカウント（派生したアクセスキー）と、STS の AssumeRole API による一時認証情報を説明します。" --- -RustFS provides two mechanisms for issuing credentials that are derived from an existing identity: **service accounts** (long-lived access keys owned by a parent user) and **STS temporary credentials** (short-lived keys with a session token). +RustFS には、既存のアイデンティティから派生した認証情報を発行する仕組みが 2 つあります。**サービスアカウント**（親ユーザーが所有する長期のアクセスキー）と、**STS の一時認証情報**（セッショントークンを持つ短期間のキー）です。 -## Service Accounts +## サービスアカウント -A service account is an access key/secret key pair that belongs to a parent IAM user (or to the root account). It authenticates like a normal key but is authorized as its parent: +サービスアカウントは、親の IAM ユーザー（またはルートアカウント）に属するアクセスキーとシークレットキーの組です。通常のキーと同じように認証しますが、認可は親として行われます。 -- **Inherited policy (default).** If the service account is created without a policy, it inherits whatever the parent user's combined policies allow at request time. -- **Session-bound policy.** If a policy document is supplied at creation, it is embedded into the service account. Requests must then be allowed by *both* the parent's policies and the embedded policy. -- **Expiration.** An optional expiration timestamp (RFC 3339) can be set; the credential stops working after that time. +- **継承ポリシー（既定）。** ポリシーなしでサービスアカウントを作成すると、リクエスト時点で親ユーザーのポリシーを組み合わせた結果が許可する範囲を継承します。 +- **セッションに結び付くポリシー。** 作成時にポリシードキュメントを指定すると、それがサービスアカウントに埋め込まれます。リクエストは、親のポリシーと埋め込まれたポリシーの両方で許可される必要があります。 +- **有効期限。** 任意の有効期限タイムスタンプ（RFC 3339）を設定できます。その時刻を過ぎると、認証情報は動作しなくなります。 -Service accounts cannot call `AssumeRole`, and a service account access key cannot be turned into a regular IAM user. +サービスアカウントは `AssumeRole` を呼び出せず、サービスアカウントのアクセスキーを通常の IAM ユーザーに変換することもできません。 -In the Console, service accounts are managed on the **Access Keys** page — see [Access Key Management](./access-token.md). The admin API exposes: +Console では、サービスアカウントを **Access Keys**（アクセスキー）のページで管理します。[アクセスキーの管理](./access-token.md)を参照します。管理 API は次を提供します。 -| Operation | Method and path | Notes | +| 操作 | メソッドとパス | 備考 | | --- | --- | --- | -| Create service account | `PUT /rustfs/admin/v3/add-service-account` | Body below. Also served at `/add-service-accounts`. Requires `admin:CreateServiceAccount` when creating for another user (`targetUser`). | -| List service accounts | `GET /rustfs/admin/v3/list-service-accounts?user=` | Requires `admin:ListServiceAccounts` to list another user's accounts. | -| List access keys (bulk) | `GET /rustfs/admin/v3/list-access-keys-bulk` | Supports filtering to users only, service accounts only, or STS keys only. | -| Service account details | `GET /rustfs/admin/v3/info-service-account?accessKey=` | Returns name, description, parent, expiration, and the session policy (or `impliedPolicy: true` when inherited). | -| Temporary account details | `GET /rustfs/admin/v3/temporary-account-info?accessKey=` | For STS-issued keys. | -| Access key details | `GET /rustfs/admin/v3/info-access-key?accessKey=` | Unified lookup across users, service accounts, and STS keys. | -| Update service account | `POST /rustfs/admin/v3/update-service-account?accessKey=` | Can rotate the secret, change status, name, description, expiration, or replace the policy. | -| Delete service account | `DELETE /rustfs/admin/v3/delete-service-account?accessKey=` | Also served at `/delete-service-accounts`. Non-admin callers can delete only their own service accounts. | +| サービスアカウントの作成 | `PUT /rustfs/admin/v3/add-service-account` | 本文は下記のとおりです。`/add-service-accounts` でも提供されます。別のユーザー（`targetUser`）向けに作成する場合は `admin:CreateServiceAccount` が必要です。 | +| サービスアカウントの一覧 | `GET /rustfs/admin/v3/list-service-accounts?user=` | 別のユーザーのアカウントを一覧する場合は `admin:ListServiceAccounts` が必要です。 | +| アクセスキーの一括一覧 | `GET /rustfs/admin/v3/list-access-keys-bulk` | ユーザーのみ、サービスアカウントのみ、または STS キーのみへの絞り込みに対応します。 | +| サービスアカウントの詳細 | `GET /rustfs/admin/v3/info-service-account?accessKey=` | 名前、説明、親、有効期限、セッションポリシーを返します（継承時は `impliedPolicy: true`）。 | +| 一時アカウントの詳細 | `GET /rustfs/admin/v3/temporary-account-info?accessKey=` | STS が発行したキー向けです。 | +| アクセスキーの詳細 | `GET /rustfs/admin/v3/info-access-key?accessKey=` | ユーザー、サービスアカウント、STS キーを横断して検索します。 | +| サービスアカウントの更新 | `POST /rustfs/admin/v3/update-service-account?accessKey=` | シークレットのローテーション、状態、名前、説明、有効期限の変更、またはポリシーの置き換えができます。 | +| サービスアカウントの削除 | `DELETE /rustfs/admin/v3/delete-service-account?accessKey=` | `/delete-service-accounts` でも提供されます。管理者以外の呼び出し元は、自分のサービスアカウントだけを削除できます。 | -Creation body (all fields optional unless noted): +作成時の本文（注記がない限り、すべてのフィールドは任意です）。 ```json { @@ -44,32 +44,32 @@ Creation body (all fields optional unless noted): :::note -Omit `accessKey`/`secretKey` to have RustFS generate a random pair. Omit `policy` to create an inherited-policy service account. `targetUser` requires admin privileges; regular users create service accounts for themselves. +`accessKey` と `secretKey` を省略すると、RustFS がランダムな組を生成します。`policy` を省略すると、継承ポリシーのサービスアカウントが作成されます。`targetUser` には管理者権限が必要です。一般ユーザーは、自分自身のサービスアカウントを作成します。 ::: -## STS Temporary Credentials +## STS の一時認証情報 -RustFS implements an AWS-compatible STS endpoint at the server root (`POST /` with form-encoded parameters). Two actions are supported: +RustFS は、サーバールートに AWS 互換の STS エンドポイントを実装しています（フォームエンコードされたパラメータによる `POST /`）。対応するアクションは 2 つです。 -- `AssumeRole` — for existing IAM identities, signed with SigV4. -- `AssumeRoleWithWebIdentity` — for OIDC identities, authenticated by the JWT itself (see [External Identity (OIDC)](../oidc/index.md)). +- `AssumeRole` — 既存の IAM アイデンティティ向けです。SigV4 で署名します。 +- `AssumeRoleWithWebIdentity` — OIDC アイデンティティ向けです。JWT 自体で認証します（[外部アイデンティティ（OIDC）](../oidc/index.md)を参照）。 ### AssumeRole -The request must be signed (AWS Signature V4) by a long-term IAM credential — temporary credentials and service accounts cannot call `AssumeRole`. With built-in IAM authorization, RustFS evaluates `sts:AssumeRole` for regular IAM users in deny-only mode: a matching explicit `Deny` rejects the request, but a separate `Allow` is not required. The user must have at least one applicable user or group policy binding, and all bound policy names must resolve. +リクエストは、長期の IAM 認証情報で署名する必要があります（AWS Signature V4）。一時認証情報とサービスアカウントは `AssumeRole` を呼び出せません。組み込みの IAM 認可では、RustFS は通常の IAM ユーザーに対する `sts:AssumeRole` を拒否のみのモードで評価します。一致する明示的な `Deny` はリクエストを拒否しますが、別途 `Allow` は必須ではありません。ユーザーには、適用可能なユーザーまたはグループのポリシー割り当てが少なくとも 1 つ必要であり、割り当てられたポリシー名はすべて解決される必要があります。 -Form parameters: +フォームパラメータは次のとおりです。 -| Parameter | Required | Description | +| パラメータ | 必須 | 説明 | | --- | --- | --- | -| `Action` | Yes | `AssumeRole`. | -| `Version` | Yes | Must be `2011-06-15`. | -| `DurationSeconds` | No | Credential lifetime in seconds. Default 3600 (1 hour); values are clamped to the range 900 (15 minutes) to 43200 (12 hours). | -| `Policy` | No | An inline session policy (JSON) that further restricts the temporary credentials. | -| `RoleArn`, `RoleSessionName`, `ExternalId` | No | Accepted for AWS compatibility. | +| `Action` | はい | `AssumeRole`。 | +| `Version` | はい | `2011-06-15` である必要があります。 | +| `DurationSeconds` | いいえ | 認証情報の有効期間（秒）です。既定値は 3600（1 時間）です。値は 900（15 分）から 43200（12 時間）の範囲に収められます。 | +| `Policy` | いいえ | 一時認証情報をさらに制限する、インラインのセッションポリシー（JSON）です。 | +| `RoleArn`、`RoleSessionName`、`ExternalId` | いいえ | AWS との互換のために受け付けます。 | -Example: +例は次のとおりです。 ```bash curl -s -X POST "https://rustfs.example.com/" \ @@ -80,26 +80,26 @@ curl -s -X POST "https://rustfs.example.com/" \ -d "DurationSeconds=3600" ``` -The response is an XML `AssumeRoleResponse` containing `AccessKeyId`, `SecretAccessKey`, `SessionToken`, and `Expiration`. Use all three values on subsequent S3 requests (the session token goes in `X-Amz-Security-Token`). +レスポンスは XML の `AssumeRoleResponse` で、`AccessKeyId`、`SecretAccessKey`、`SessionToken`、`Expiration` を含みます。後続の S3 リクエストでは、3 つの値をすべて使います（セッショントークンは `X-Amz-Security-Token` に入れます）。 -The temporary credential inherits the caller's policies; the `parent` of the credential is the calling access key. If a `Policy` parameter was supplied, it is stored in the session and applied as an additional restriction. +一時認証情報は呼び出し元のポリシーを継承します。認証情報の `parent` は、呼び出しに使ったアクセスキーです。`Policy` パラメータを指定した場合、それはセッションに保存され、追加の制限として適用されます。 ### AssumeRoleWithWebIdentity -Used by the OIDC flow; no SigV4 signature is needed because the identity provider's JWT is the authentication: +OIDC フローで使います。アイデンティティプロバイダーの JWT が認証になるため、SigV4 署名は不要です。 -| Parameter | Required | Description | +| パラメータ | 必須 | 説明 | | --- | --- | --- | -| `Action` | Yes | `AssumeRoleWithWebIdentity`. | -| `Version` | Yes | Must be `2011-06-15`. | -| `WebIdentityToken` | Yes | The OIDC ID token issued by a configured provider. | -| `DurationSeconds` | No | Same default and 900–43200 clamping as `AssumeRole`. | -| `Policy` | No | Optional inline session policy. | +| `Action` | はい | `AssumeRoleWithWebIdentity`。 | +| `Version` | はい | `2011-06-15` である必要があります。 | +| `WebIdentityToken` | はい | 設定済みプロバイダーが発行した OIDC の ID トークンです。 | +| `DurationSeconds` | いいえ | `AssumeRole` と同じ既定値であり、900 から 43200 の範囲に収められます。 | +| `Policy` | いいえ | 任意のインラインセッションポリシーです。 | -RustFS verifies the token against the configured provider (signature, issuer, audience, expiry), maps its `groups`/`roles` claims to RustFS policy names, and rejects the request if no policies or groups can be mapped. The response is an XML `AssumeRoleWithWebIdentityResponse` with the same credential fields plus `SubjectFromWebIdentityToken`. +RustFS は、設定されたプロバイダーに対してトークンを検証し（署名、発行者、オーディエンス、有効期限）、`groups` と `roles` のクレームを RustFS のポリシー名に対応付けます。ポリシーまたはグループを対応付けできない場合、リクエストは拒否されます。レスポンスは XML の `AssumeRoleWithWebIdentityResponse` で、同じ認証情報フィールドに加えて `SubjectFromWebIdentityToken` を含みます。 :::warning -Keep `DurationSeconds` as short as your workload allows; a leaked temporary credential remains valid until its expiration. +ワークロードが許す限り、`DurationSeconds` を短くすることを推奨します。漏えいした一時認証情報は、有効期限まで有効なままです。 ::: diff --git a/content/ja/security-compliance/index.md b/content/ja/security-compliance/index.md index 68960b85d..ec6a97939 100644 --- a/content/ja/security-compliance/index.md +++ b/content/ja/security-compliance/index.md @@ -1,15 +1,15 @@ --- -title: "Security & Compliance" -description: "Configure identity, encryption, transport security, audit logging, and credentials for RustFS." +title: "セキュリティとコンプライアンス" +description: "RustFS のアイデンティティ、暗号化、通信の保護、監査ログ、認証情報を設定します。" --- -Use this section to secure access to RustFS and configure the controls required by your environment. +このセクションでは、RustFS へのアクセスを保護し、環境で必要な制御を設定します。 -## Security areas +## セキュリティの領域 -- [IAM Management](./iam/index.md) covers users, groups, policies, and access keys. -- [Data Encryption](./encryption/index.md) covers server-side encryption options and key management. -- [OIDC](./oidc/index.md) covers external identity providers. -- [TLS Configuration](/integration/tls-configured) covers encrypted client and node connections. -- [Audit Logs](./audit-logs.md) covers audit target configuration. -- [Credential Management](/operations/credentials) covers root credentials and secret injection. +- [IAM の管理](./iam/index.md)では、ユーザー、グループ、ポリシー、アクセスキーを扱います。 +- [データ暗号化](./encryption/index.md)では、サーバー側の暗号化の選択肢と鍵管理を扱います。 +- [OIDC](./oidc/index.md)では、外部のアイデンティティプロバイダーを扱います。 +- [TLS の設定](/ja/integration/tls-configured)では、クライアントとノードの暗号化された接続を扱います。 +- [監査ログ](./audit-logs.md)では、監査ターゲットの設定を扱います。 +- [認証情報の管理](/ja/operations/credentials)では、ルート認証情報とシークレットの注入を扱います。 diff --git a/content/ja/security-compliance/oidc/gitlab.md b/content/ja/security-compliance/oidc/gitlab.md index 2c8ead1fc..6caca26a9 100644 --- a/content/ja/security-compliance/oidc/gitlab.md +++ b/content/ja/security-compliance/oidc/gitlab.md @@ -1,76 +1,76 @@ --- title: "GitLab" -description: "Configure GitLab as an OpenID Connect identity provider for RustFS Console single sign-on." +description: "GitLab を、RustFS Console のシングルサインオン用 OpenID Connect アイデンティティプロバイダーとして設定します。" --- -RustFS integrates with **GitLab** through the OpenID Connect (OIDC) Authorization Code Flow. The examples on this page use the default RustFS provider ID, `default`. +RustFS は、OpenID Connect（OIDC）の Authorization Code Flow を通じて **GitLab** と連携します。このページの例では、RustFS のデフォルトプロバイダー ID である `default` を使います。 -## Requirements +## 要件 -Before you begin, prepare: +開始する前に、次を準備します。 -- An [installed GitLab instance](https://about.gitlab.com/install/) and access to its Admin area. -- A RustFS deployment with a public HTTPS Console origin. -- A RustFS policy to assign to GitLab users. The examples use `consoleAdmin`; use a policy with only the permissions your users require in production. +- [インストール済みの GitLab インスタンス](https://about.gitlab.com/install/)と、その管理エリアへのアクセス。 +- 公開 HTTPS の Console オリジンを持つ RustFS のデプロイ。 +- GitLab ユーザーに割り当てる RustFS ポリシー。例では `consoleAdmin` を使います。本番では、ユーザーに必要な権限だけを持つポリシーを使います。 -## Overview +## 概要 -The browser login flow is: +ブラウザのログインの流れは次のとおりです。 -1. RustFS sends an authorization-code request with a Proof Key for Code Exchange (PKCE) S256 challenge. -2. GitLab authenticates the user and redirects the browser to RustFS with `code` and `state`. -3. RustFS exchanges the code at the GitLab token endpoint. -4. RustFS verifies the ID token signature, issuer, audience, expiry, and nonce. -5. RustFS assigns the configured local Identity and Access Management (IAM) policy and issues temporary credentials for the Console session. +1. RustFS は、Proof Key for Code Exchange（PKCE）の S256 チャレンジ付きで認可コードリクエストを送ります。 +2. GitLab がユーザーを認証し、`code` と `state` を付けてブラウザを RustFS へリダイレクトします。 +3. RustFS は、GitLab のトークンエンドポイントでコードを交換します。 +4. RustFS は、ID トークンの署名、発行者、オーディエンス、有効期限、nonce を検証します。 +5. RustFS は、設定されたローカルのアイデンティティとアクセス管理（IAM）ポリシーを割り当て、Console セッション用の一時認証情報を発行します。 -GitLab authenticates the user, while RustFS policies authorize S3 and administration operations. +GitLab がユーザーを認証し、RustFS のポリシーが S3 と管理操作を認可します。 -The examples use the following values. Replace the hostnames and client secret for your environment: +例では次の値を使います。ホスト名とクライアントシークレットは、環境に合わせて置き換えます。 -| Setting | Example | +| 設定 | 例 | | --- | --- | -| GitLab issuer | `https://gitlab.example.com` | -| GitLab application ID | `` | -| Public RustFS origin | `https://rustfs.example.com` | -| RustFS callback URL | `https://rustfs.example.com/rustfs/admin/v3/oidc/callback/default` | +| GitLab の発行者 | `https://gitlab.example.com` | +| GitLab のアプリケーション ID | `` | +| 公開する RustFS のオリジン | `https://rustfs.example.com` | +| RustFS のコールバック URL | `https://rustfs.example.com/rustfs/admin/v3/oidc/callback/default` | -## Configuration +## 設定 -### GitLab configuration +### GitLab の設定 -#### Create the OAuth application +#### OAuth アプリケーションを作成する -1. Sign in to GitLab as an administrator. -2. Open **Admin Area**, select **Applications**, and select **New application**. -3. Enter `RustFS OIDC` as the application name. -4. Set **Redirect URI** to the exact RustFS callback URL: +1. GitLab に管理者としてサインインします。 +2. **Admin Area**（管理エリア）を開き、**Applications**（アプリケーション）を選択し、**New application**（新規アプリケーション）を選択します。 +3. アプリケーション名として `RustFS OIDC` を入力します。 +4. **Redirect URI**（リダイレクト URI）を、RustFS のコールバック URL に完全一致で設定します。 ```text https://rustfs.example.com/rustfs/admin/v3/oidc/callback/default ``` -5. Enable **Confidential**. -6. Enable **Trusted** to skip the user authorization prompt for this instance-wide application. -7. Select the `openid`, `profile`, and `email` scopes. -8. Save the application, then copy the generated application ID and secret. +5. **Confidential**（機密）を有効にします。 +6. このインスタンス全体のアプリケーションでユーザー認可の確認を省略するため、**Trusted**（信頼済み）を有効にします。 +7. `openid`、`profile`、`email` スコープを選択します。 +8. アプリケーションを保存し、生成されたアプリケーション ID とシークレットをコピーします。 -See the [GitLab OAuth provider documentation](https://docs.gitlab.com/integration/oauth_provider/) for details about administering applications. +アプリケーション管理の詳細は、[GitLab の OAuth プロバイダーに関するドキュメント](https://docs.gitlab.com/integration/oauth_provider/)を参照します。 -![GitLab Admin area showing the RustFS OIDC instance OAuth application as trusted and confidential](./images/gitlab-oidc-configuration.png) +![信頼済みかつ機密として表示された、RustFS OIDC のインスタンス OAuth アプリケーションを示す GitLab の管理エリア](./images/gitlab-oidc-configuration.png) -:::note[Test environment shown] +:::note[テスト環境の画面] -The screenshot shows an HTTP callback URL from a test environment. Use the public HTTPS callback URL for your RustFS deployment. +スクリーンショットは、テスト環境の HTTP コールバック URL を示しています。RustFS のデプロイでは、公開された HTTPS のコールバック URL を使います。 ::: -### RustFS configuration +### RustFS の設定 -Configure the GitLab provider through environment variables. +環境変数で GitLab プロバイダーを設定します。 -#### Configure with environment variables +#### 環境変数で設定する -Add the GitLab provider and public browser origin to the RustFS service environment: +GitLab プロバイダーと、ブラウザ向けの公開オリジンを、RustFS サービスの環境に追加します。 ```ini title="/etc/default/rustfs" RUSTFS_BROWSER_REDIRECT_URL="https://rustfs.example.com" @@ -88,23 +88,23 @@ RUSTFS_IDENTITY_OPENID_USERNAME_CLAIM="preferred_username" RUSTFS_IDENTITY_OPENID_ROLE_POLICY="consoleAdmin" ``` -Restart RustFS after applying the configuration. +設定を適用したあと、RustFS を再起動します。 -`RUSTFS_BROWSER_REDIRECT_URL` must contain the public scheme and authority without a path. It controls the Console success redirect and logout fallback URL. The provider callback URL must exactly match the URL registered in GitLab. +`RUSTFS_BROWSER_REDIRECT_URL` には、パスを除いた公開スキームとオーソリティを指定する必要があります。Console の成功時リダイレクトと、ログアウト時のフォールバック URL を制御します。プロバイダーのコールバック URL は、GitLab に登録した URL と完全に一致する必要があります。 -:::warning[Limit the assigned policy] +:::warning[割り当てるポリシーを制限する] -`RUSTFS_IDENTITY_OPENID_ROLE_POLICY` assigns the same RustFS policy to every user who signs in through this provider. Replace `consoleAdmin` with a policy that grants only the permissions required by your GitLab users. +`RUSTFS_IDENTITY_OPENID_ROLE_POLICY` は、このプロバイダー経由でサインインするすべてのユーザーに同じ RustFS ポリシーを割り当てます。`consoleAdmin` は、GitLab ユーザーに必要な権限だけを付与するポリシーに置き換えます。 ::: -For a reverse proxy or load balancer, preserve the callback query string and route the authorize and callback requests to the same RustFS node. The in-flight OIDC `state` is local to that node. +リバースプロキシまたはロードバランサーを使う場合は、コールバックのクエリ文字列を保持し、認可リクエストとコールバックリクエストを同じ RustFS ノードへルーティングします。処理中の OIDC `state` は、そのノードのローカルにあります。 -## Verification +## 確認 -### Verify GitLab discovery +### GitLab のディスカバリーを確認する -Query the GitLab discovery document: +GitLab のディスカバリードキュメントを問い合わせます。 ```bash curl -fsS "https://gitlab.example.com/.well-known/openid-configuration" | jq '{ @@ -117,44 +117,44 @@ curl -fsS "https://gitlab.example.com/.well-known/openid-configuration" | jq '{ }' ``` -Confirm that: +次を確認します。 -- `issuer` is `https://gitlab.example.com`. -- `authorization_endpoint`, `token_endpoint`, and `jwks_uri` are present. -- `scopes_supported` includes `openid`, `profile`, and `email`. -- `code_challenge_methods_supported` includes `S256`. +- `issuer` が `https://gitlab.example.com` であること。 +- `authorization_endpoint`、`token_endpoint`、`jwks_uri` があること。 +- `scopes_supported` に `openid`、`profile`、`email` が含まれること。 +- `code_challenge_methods_supported` に `S256` が含まれること。 -### Verify the RustFS provider +### RustFS のプロバイダーを確認する -After restarting RustFS, check that the provider is available: +RustFS を再起動したあと、プロバイダーが利用できることを確認します。 ```bash curl -fsS "https://rustfs.example.com/rustfs/admin/v3/oidc/providers" | jq ``` -The response should include the `default` provider with the display name `GitLab`. +レスポンスには、表示名 `GitLab` の `default` プロバイダーが含まれるはずです。 -### Test Console login +### Console ログインを試す -Open the RustFS Console and select **GitLab**, or open the authorization endpoint directly: +RustFS Console を開き **GitLab** を選択するか、認可エンドポイントを直接開きます。 ```text https://rustfs.example.com/rustfs/admin/v3/oidc/authorize/default ``` -![RustFS Console login page showing the Login with GitLab option](./images/rustfs-console-gitlab-oidc.png) +![Login with GitLab の選択肢を示す RustFS Console のログインページ](./images/rustfs-console-gitlab-oidc.png) -Verify the complete flow: +一連の流れを確認します。 -1. The browser redirects to GitLab. -2. The user signs in and authorizes the application when prompted. -3. GitLab redirects to the RustFS callback URL with `code` and `state`. -4. RustFS validates the ID token and creates the Console session. -5. The Console opens with the configured RustFS policy. +1. ブラウザが GitLab へリダイレクトされます。 +2. ユーザーがサインインし、確認を求められたらアプリケーションを認可します。 +3. GitLab が `code` と `state` を付けて RustFS のコールバック URL へリダイレクトします。 +4. RustFS が ID トークンを検証し、Console セッションを作成します。 +5. 設定した RustFS ポリシーで Console が開きます。 -If GitLab reports a redirect URI mismatch, confirm that the URI registered in the GitLab application exactly matches `RUSTFS_IDENTITY_OPENID_REDIRECT_URI`. +GitLab がリダイレクト URI の不一致を報告した場合は、GitLab アプリケーションに登録した URI が `RUSTFS_IDENTITY_OPENID_REDIRECT_URI` と完全に一致することを確認します。 -## Next steps +## 次のステップ -- Review [users, groups, and policies](../iam/policies.md) before selecting the policy assigned to GitLab users. -- Review the [Console security notes](/administration/console) before exposing the login endpoint publicly. \ No newline at end of file +- GitLab ユーザーに割り当てるポリシーを選ぶ前に、[ユーザー、グループ、ポリシー](../iam/policies.md)を確認します。 +- ログインエンドポイントを公開する前に、[Console のセキュリティに関する注意](/ja/administration/console)を確認します。 diff --git a/content/ja/security-compliance/oidc/index.md b/content/ja/security-compliance/oidc/index.md index 0d784b7ad..50ab8953b 100644 --- a/content/ja/security-compliance/oidc/index.md +++ b/content/ja/security-compliance/oidc/index.md @@ -1,40 +1,40 @@ --- title: "OIDC" -description: "Understand how RustFS uses OpenID Connect providers for Console single sign-on." +description: "RustFS が Console のシングルサインオンに OpenID Connect プロバイダーを使う仕組みを説明します。" --- -RustFS supports OpenID Connect (OIDC) for Console single sign-on. Use this overview to understand the authentication flow, prepare an identity provider, and choose a provider-specific configuration guide. +RustFS は、Console のシングルサインオンで OpenID Connect（OIDC）に対応しています。この概要では、認証の流れを理解し、アイデンティティプロバイダーを準備し、プロバイダー別の設定ガイドを選びます。 -## How OIDC works +## OIDC の仕組み -RustFS uses the OIDC Authorization Code Flow with Proof Key for Code Exchange (PKCE): +RustFS は、Proof Key for Code Exchange（PKCE）を伴う OIDC の Authorization Code Flow を使います。 -1. RustFS sends an authorization request with an S256 PKCE challenge. -2. The identity provider authenticates you and returns an authorization code to the RustFS callback URL. -3. RustFS exchanges the code at the provider's token endpoint. -4. RustFS verifies the ID token signature, issuer, audience, expiry, and nonce. -5. RustFS maps configured token claims to local Identity and Access Management (IAM) policies and creates a Console session with temporary credentials. +1. RustFS は、S256 の PKCE チャレンジ付きで認可リクエストを送ります。 +2. アイデンティティプロバイダーがユーザーを認証し、認可コードを RustFS のコールバック URL へ返します。 +3. RustFS は、プロバイダーのトークンエンドポイントでコードを交換します。 +4. RustFS は、ID トークンの署名、発行者、オーディエンス、有効期限、nonce を検証します。 +5. RustFS は、設定されたトークンクレームをローカルのアイデンティティとアクセス管理（IAM）ポリシーに対応付け、一時認証情報を持つ Console セッションを作成します。 -The identity provider authenticates you, while RustFS policies authorize S3 and administration operations. +アイデンティティプロバイダーがユーザーを認証し、RustFS のポリシーが S3 と管理操作を認可します。 -## Provider requirements +## プロバイダーの要件 -Before configuring a provider, prepare: +プロバイダーを設定する前に、次を準備します。 -- An OIDC discovery URL that exposes the authorization, token, and JSON Web Key Set (JWKS) endpoints. -- A confidential client that supports the Authorization Code Flow, S256 PKCE, and client-secret authentication in the token request body. -- An exact callback URL in the form `https:///rustfs/admin/v3/oidc/callback/`. -- A public HTTPS origin for the RustFS Console. -- A flat group or role claim whose values match existing RustFS policy names. +- 認可、トークン、JSON Web Key Set（JWKS）の各エンドポイントを公開する OIDC ディスカバリー URL。 +- Authorization Code Flow、S256 PKCE、トークンリクエスト本文でのクライアントシークレット認証に対応する機密クライアント。 +- `https:///rustfs/admin/v3/oidc/callback/` 形式の、完全一致するコールバック URL。 +- RustFS Console の公開 HTTPS オリジン。 +- 値が既存の RustFS ポリシー名と一致する、フラットなグループまたはロールのクレーム。 -Use a dedicated client for RustFS and grant each identity only the policies it requires. +RustFS 専用のクライアントを使い、各アイデンティティには必要なポリシーだけを付与します。 -## Provider guides +## プロバイダー別のガイド -- [Configure Keycloak](/security-compliance/oidc/keycloak) as an OIDC provider for the RustFS Console. -- [Configure GitLab](/security-compliance/oidc/gitlab) as an OIDC provider for the RustFS Console. +- [Keycloak の設定](/ja/security-compliance/oidc/keycloak)では、RustFS Console の OIDC プロバイダーとして Keycloak を設定します。 +- [GitLab の設定](/ja/security-compliance/oidc/gitlab)では、RustFS Console の OIDC プロバイダーとして GitLab を設定します。 -## Next steps +## 次のステップ -- Review [users, groups, and policies](/security-compliance/iam/policies) before mapping identity-provider claims. -- Review the [Console security notes](/administration/console) before exposing the login endpoint publicly. +- アイデンティティプロバイダーのクレームを対応付ける前に、[ユーザー、グループ、ポリシー](/ja/security-compliance/iam/policies)を確認します。 +- ログインエンドポイントを公開する前に、[Console のセキュリティに関する注意](/ja/administration/console)を確認します。 diff --git a/content/ja/security-compliance/oidc/keycloak.md b/content/ja/security-compliance/oidc/keycloak.md index 120c44a3d..473f1045c 100644 --- a/content/ja/security-compliance/oidc/keycloak.md +++ b/content/ja/security-compliance/oidc/keycloak.md @@ -184,4 +184,4 @@ https://rustfs.example.com/rustfs/admin/v3/oidc/authorize/default ## 次のステップ - Keycloak のグループを割り当てる前に、[ユーザー、グループ、ポリシー](../iam/policies.md)を確認します。 -- ログインエンドポイントを公開する前に、[Console のセキュリティに関する注意](/administration/console)を確認します。 +- ログインエンドポイントを公開する前に、[Console のセキュリティに関する注意](/ja/administration/console)を確認します。 diff --git a/content/ja/troubleshooting/driver.md b/content/ja/troubleshooting/driver.md index f0d48390f..702f4aa29 100644 --- a/content/ja/troubleshooting/driver.md +++ b/content/ja/troubleshooting/driver.md @@ -1,34 +1,25 @@ --- -title: "Hard Drive Failures" -description: "RustFS ensures read/write access can still be provided when some disks fail through mechanisms similar to erasure coding, and automatically heals data after replacing disks." +title: "ドライブ障害" +description: "RustFS のデプロイで障害が発生したドライブを交換し、データを自動的に修復します。" --- -RustFS ensures read/write access can still be provided when some disks fail through mechanisms similar to erasure coding, and automatically heals data after replacing disks. - -## Table of Contents - -1. [Unmount Failed Disk](#unmount-failed-disk) -2. [Replace Failed Disk](#replace-failed-disk) -3. [Update `/etc/fstab` or RustFS Configuration](#update-etcfstab-or-rustfs-configuration) -4. [Remount New Disk](#remount-new-disk) -5. [Trigger and Monitor Data Healing](#trigger-and-monitor-data-healing) -6. [Follow-up Checks and Notes](#follow-up-checks-and-notes) +RustFS はイレイジャーコーディングにより、一部のドライブが故障してもデータの読み書きを継続します。障害が発生したドライブを交換すると、RustFS は欠落したデータをそのドライブへ自動的に修復します。 -### Unmount Failed Disk +### 障害が発生したディスクのアンマウント -Before replacing the physical hard drive, you need to safely unmount the failed disk from the operating system level to avoid I/O errors in the file system or RustFS during the replacement process. +物理ハードディスクを交換する前に、OS 上で障害ディスクをアンマウントします。交換中にファイルシステムや RustFS で I/O エラーが起きるのを防ぎます。 ```bash # Assume the failed disk is /dev/sdb umount /dev/sdb ``` -:::note[Notes] +:::note[注意] -* If there are multiple mount points, execute `umount` separately. -* If encountering "device is busy", you can first stop the RustFS service: +* ディスクに複数のマウントポイントがある場合は、それぞれで `umount` を実行します。 +* 「device is busy」エラーが表示された場合は、先に RustFS サービスを停止します。 ```bash systemctl stop rustfs @@ -38,26 +29,28 @@ systemctl stop rustfs -### Replace Failed Disk +### 障害が発生したディスクの交換 -After physically replacing the failed disk, you need to partition and format the new disk, and apply the same label as the original disk. +障害ディスクを物理的に交換したあと、新しいディスクをパーティション分割してフォーマットし、元のディスクと同じラベルを付けます。 ```bash # Format as XFS and apply the same label as the original disk (RustFS requires XFS, like the other disks in the deployment) mkfs.xfs -L DISK1 /dev/sdb ``` -> **Requirements** -> -> * New disk capacity ≥ original disk capacity; -> * File system type consistent with other disks (XFS, per the [installation guide](../installation/linux/index.md)); -> * Recommend using labels (LABEL) or UUID for mounting to ensure disk order is not affected by system restarts. +:::note[要件] + +* 新しいディスクの容量は、元のディスク以上である必要があります。 +* ほかのディスクと同じファイルシステム（XFS）を使います。詳細は [インストールガイド](../installation/linux/index.md) を参照します。 +* 再起動後にデバイス名が変わってもマウント先がずれないよう、ラベル（LABEL）または UUID でファイルシステムをマウントすることを推奨します。 + +::: -### Update `/etc/fstab` or RustFS Configuration +### `/etc/fstab` または RustFS 設定の更新 -Confirm that the mount item labels or UUIDs in `/etc/fstab` point to the new disk. The mount point must stay identical to the one listed in `RUSTFS_VOLUMES` (in `/etc/default/rustfs`), so the healed disk rejoins the cluster at the same path. +`/etc/fstab` のエントリに書かれたラベルまたは UUID が、新しいディスクを指していることを確認します。マウントポイントは `/etc/default/rustfs` の `RUSTFS_VOLUMES` に記載されたパスと同一である必要があります。これにより、修復対象のディスクが同じパスでクラスターに再参加します。 ```bash # View current fstab @@ -67,16 +60,16 @@ cat /etc/fstab LABEL=DISK1 /data/rustfs0 xfs defaults,noatime 0 2 ``` -:::tip[Tips] +:::tip[ヒント] -* If using UUID: +* UUID を使う場合: ```bash blkid /dev/sdb # Get the new partition's UUID, then replace the corresponding field in fstab ``` -* After modifying fstab, be sure to validate syntax: +* `/etc/fstab` の編集後に、構文を検証します。 ```bash mount -a # If no errors, configuration is correct @@ -86,32 +79,32 @@ mount -a # If no errors, configuration is correct -### Remount New Disk +### 新しいディスクの再マウント -Execute the following commands to batch mount all disks and start the RustFS service: +次のコマンドで、設定済みのファイルシステムをすべてマウントし、RustFS を起動します。 ```bash mount -a systemctl start rustfs ``` -Confirm all disks are mounted normally: +想定しているファイルシステムがすべてマウントされていることを確認します。 ```bash df -h | grep /data/rustfs ``` -:::note +:::note[マウントの失敗] -If some mounts fail, please check if fstab entries are consistent with disk labels/UUIDs. +マウントに失敗した場合は、`/etc/fstab` のラベルまたは UUID が、対象ファイルシステム上の値と一致しているか確認します。 ::: -### Trigger and Monitor Data Healing +### データ修復の開始と監視 -Once RustFS detects a freshly formatted disk at a known mount point, its background scanner heals the missing data onto it automatically — no manual command is required. Confirm that recovery has started and track its progress through the service logs: +RustFS が既知のマウントポイントでフォーマット直後のディスクを検出すると、バックグラウンドスキャナーが欠落データをそのディスクへ自動的に修復します。手動のコマンドは不要です。サービスログで、復旧の開始と進捗を確認します。 ```bash # For systemd-managed installations @@ -121,28 +114,28 @@ journalctl -u rustfs -f tail -f /var/log/rustfs/rustfs.log ``` -You can also open the RustFS Console and check the disk status of the affected node. +RustFS Console を開き、対象ノードのディスク状態を確認することもできます。 -:::note[Notes] +:::note[注意] -* The healing process will complete in the background, usually with minimal impact on online access; -* After healing is complete, the tool will report success or list failed objects. +* データ修復はバックグラウンドで実行され、通常、クライアント要求への影響はわずかです。 +* データ修復が終わると、ログには成功が記録されるか、修復できなかったオブジェクトが一覧されます。 ::: -### Follow-up Checks and Notes +### 事後確認と注意点 -1. **Performance Monitoring** +1. **パフォーマンス監視** - * I/O may fluctuate slightly during healing, recommend monitoring disk and network load. -2. **Batch Failures** + * データ修復中は I/O 負荷が変動することがあります。ディスクとネットワークの使用率を監視することを推奨します。 +2. **同一製造ロットの障害** - * If multiple failures occur in the same batch of disks, consider more frequent hardware inspections. -3. **Regular Drills** + * 同じ製造ロットのディスクが複数故障した場合は、そのロットに残るディスクの点検頻度を上げます。 +3. **定期的な障害試験** - * Regularly simulate disk failure drills to ensure team familiarity with recovery processes. -4. **Maintenance Windows** + * 復旧手順を習熟できるよう、定期的にディスク障害の訓練を実施します。 +4. **メンテナンス時間** - * When failure rates are high, arrange dedicated maintenance windows to speed up replacement and healing. + * 障害率が高い場合は、交換とデータ修復を早めるため、専用のメンテナンス時間を設けます。 diff --git a/content/ja/troubleshooting/index.md b/content/ja/troubleshooting/index.md index 2d67143db..bc5e47108 100644 --- a/content/ja/troubleshooting/index.md +++ b/content/ja/troubleshooting/index.md @@ -1,11 +1,10 @@ --- -title: "Troubleshooting" -description: "Diagnose and resolve RustFS issues." +title: "トラブルシューティング" +description: "RustFS の問題を診断し、解決する方法を説明します。" --- -Contents: - -- [Node Failures](./node.md) -- [Driver Failures](./driver.md) -- [Node Healing](../operations/high-availability/node-healing.md) +このセクションでは、次の内容を扱います。 +- [ノード障害](./node.md) +- [ドライブ障害](./driver.md) +- [ノードのデータ修復](../operations/high-availability/node-healing.md) diff --git a/content/ja/troubleshooting/node.md b/content/ja/troubleshooting/node.md index 34f8fe953..25ed7e72a 100644 --- a/content/ja/troubleshooting/node.md +++ b/content/ja/troubleshooting/node.md @@ -1,83 +1,83 @@ --- -title: "Node Failures" -description: "Complete steps for handling node failures in RustFS clusters. Mainly includes: replacement node hardware preparation, configuration updates, service deployment, rejoining the cluster, data healing, and subsequent checks and best practices." +title: "ノード障害" +description: "代替ノードを準備し、設定を更新してクラスターへの参加を復旧し、データ修復を確認します。" --- -In distributed RustFS clusters, erasure coding mechanisms are adopted to ensure read/write access can still be provided when some nodes fail, and automatic data healing occurs after nodes rejoin. This document will guide you through the following process: +分散構成の RustFS クラスターは、イレイジャーコーディングにより一部のノードが故障しても読み書きを継続し、ノードが再参加するとデータを自動的に修復します。このガイドでは、次の手順を説明します。 -1. Start replacement node and synchronize environment -2. Update DNS/hostname to point old node identifiers to new nodes -3. Download and deploy RustFS services consistent with the cluster -4. Rejoin new nodes to the cluster and trigger data healing -5. Monitor healing progress and perform subsequent checks and optimization +1. 代替ノードを起動し、ソフトウェア環境をクラスターに合わせます。 +2. DNS または `/etc/hosts` を更新し、以前のホスト名が新しいノードへ解決されるようにします。 +3. ほかのノードと同じ RustFS バージョンをインストールします。 +4. 代替ノードを起動してクラスターへ再参加させ、データ修復を開始します。 +5. データ修復の進捗を監視したあと、事後確認を行います。 -## 1) Start Replacement Node +## 1. 代替ノードの準備 -* **Hardware and System Preparation** - Ensure the replacement node server hardware is roughly consistent with the failed node, including CPU, memory, network configuration, and disk type; even using higher configurations won't affect cluster performance. - Software environment needs to maintain version consistency with other nodes (operating system, kernel, dependency libraries, etc.) to avoid cluster abnormal behavior caused by environment differences. +* **ハードウェアとシステムの準備** + 代替ノードのハードウェア（CPU、メモリ、ネットワーク、ディスク種別）が、障害ノードとおおむね揃っていることを確認します。より高いスペックのハードウェアを使っても、クラスターの性能には影響しません。 + オペレーティングシステム、カーネル、依存関係を含め、ほかのノードと一致するソフトウェアバージョンを使い、環境の不一致による問題を避けます。 -* **Drive Exclusive Access** - As with physical drive operations, RustFS requires exclusive access to storage volumes, prohibiting any other processes or scripts from directly modifying data within storage volumes, otherwise data corruption or redundancy loss can easily occur. +* **ドライブへの排他アクセス** + 物理ドライブの操作と同様に、RustFS はそのストレージボリュームへの排他的なアクセスを必要とします。ほかのプロセスやスクリプトがこれらのボリュームのデータを直接変更しないようにします。直接変更すると、データが破損したり、冗長性が低下したりする可能性があります。 -## 2) Update Hostname and Network Resolution +## 2. ホスト名と名前解決の更新 -* **DNS/Hosts Configuration** - If the replacement node's IP address differs from the failed node, you need to re-resolve the old node's hostname (such as `rustfs-node-2.example.net`) to the new node to ensure nodes within the cluster discover each other through the same address. +* **DNS と hosts の設定** + 代替ノードの IP アドレスが障害ノードと異なる場合は、旧ノードのホスト名（例: `rustfs-node-2.example.net`）を新しいノードの IP アドレスへ向けます。これにより、クラスター内のノードは同じ名前で互いに到達できます。 ```bash # Example: Add or modify line in /etc/hosts 192.168.1.12 rustfs-node-2.example.net ``` - After correct resolution, you can verify the hostname points to the new node through `ping` or `nslookup`. + `ping` または `nslookup` を使い、ホスト名が新しいノードに解決されることを確認します。 -## 3) Deploy and Configure RustFS Services +## 3. RustFS サービスのデプロイと設定 -* **Download and Installation** - Follow the same version deployment process as RustFS official, download binaries or installation packages consistent with existing nodes, and extract to a unified directory. Ensure startup scripts, environment variables, and configuration files (such as `/etc/default/rustfs`) are completely consistent with other nodes in the cluster. +* **ダウンロードとインストール** + 既存ノードと同じ RustFS バージョンを、同じインストール方法とディレクトリでインストールします。起動スクリプト、環境変数、設定ファイル（`/etc/default/rustfs` など）が、ほかのノードと同一であることを確認します。 -* **Configuration Verification** +* **設定の確認** - * Check that `RUSTFS_VOLUMES` in `/etc/default/rustfs` is byte-for-byte identical to the other nodes, and that it covers the replacement node's hostname and port. - * Ensure all nodes have the same access keys and permission configurations to avoid new nodes being unable to join due to authentication failures. + * `/etc/default/rustfs` 内の `RUSTFS_VOLUMES` がほかのノードとバイト単位で同一であり、代替ノードのホスト名とポートを含んでいることを確認します。 + * すべてのノードが同じアクセスキーと権限設定を使っていることを確認します。異なると、新しいノードは認証に失敗し、クラスターに参加できません。 -## 4) Rejoin Cluster and Trigger Data Healing +## 4. クラスターへの再参加とデータ修復の開始 -* **Start Service** +* **サービスの起動** ```bash systemctl start rustfs ``` - Or use your custom startup script to start RustFS services, and view startup logs through `journalctl -u rustfs -f` to confirm the new node has detected other online nodes and started the data healing process. + 独自の起動スクリプトで RustFS を起動する方法もあります。続いて `journalctl -u rustfs -f` を実行し、新しいノードがほかのノードを検出してデータ修復を開始したことを確認します。 -* **Monitor Healing Status** - Healing runs in the background once the node rejoins; no manual command is required. Watch its progress through the service logs on the replacement node, and check node and disk status in the RustFS Console: +* **データ修復状態の監視** + ノードが再参加すると、データ修復はバックグラウンドで実行されます。手動コマンドは不要です。代替ノードのサービスログで進捗を確認し、RustFS Console でノードとディスクの状態を見ます。 ```bash journalctl -u rustfs -f ``` -* **Community Experience Reference** - Community testing shows that when nodes go offline and rejoin, RustFS will only perform healing operations on new nodes, not fully rebalance the cluster, thus avoiding unnecessary network and I/O peaks. +* **コミュニティでの観測結果** + コミュニティでの検証では、ノードがオフラインになってから再参加したとき、RustFS はクラスター全体をリバランスせず、そのノードだけを修復します。これにより、不要なネットワークと I/O の急増を避けられます。 -## 5) Subsequent Checks and Best Practices +## 5. 事後確認と推奨事項 -* **Monitoring and Alerts** +* **監視とアラート** - * During healing, monitor disk and network load to ensure the cluster meets read/write and network bandwidth requirements. - * Set up alerts to notify operations teams when node healing fails or progress stalls beyond thresholds. + * データ修復中はディスクとネットワークの負荷を監視し、クラスターが読み取り、書き込み、帯域幅の要件を満たしていることを確認します。 + * ノードのデータ修復が失敗したとき、または進捗がしきい値を超えて停滞したときに、運用チームへ通知するアラートを設定します。 -* **Repeated Failure Drills** - Regularly simulate node failures and drill the entire recovery process to ensure team familiarity with operation commands and emergency procedures. +* **定期的な障害試験** + 定期的にノード障害の訓練を行い、復旧手順の全体を練習して、コマンドとインシデント対応の流れに慣れておきます。 -* **Root Cause Analysis** - Conduct in-depth hardware health diagnostics (SMART, BIOS logs, etc.) on frequently failing nodes or disks, and implement preventive maintenance plans. +* **根本原因分析** + 繰り返し故障するノードやディスクでは、SMART データや BIOS ログなどの詳細なハードウェア診断を実施し、予防保守の計画を用意します。 -* **Professional Support** - If deeper-level fault location and recovery guidance is needed, contact the RustFS development team or community for help. +* **サポート** + 障害原因の診断やクラスター復旧の支援が必要な場合は、RustFS の開発チームまたはコミュニティへ連絡します。 --- -**Summary**: Through the above process, RustFS can quickly and safely replace nodes and complete data healing after node hardware completely fails, minimizing cluster availability interruptions. Be sure to cross-reference with your own environment and specific command-line tools to ensure configuration consistency and correct operation sequence. +これらの手順で、障害ノードを交換し、そのデータを修復します。コマンドは環境に合わせて調整し、ノード間の設定は同一に保ちます。