> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.
> Kubernetes Operator を使用して、クラウドまたはオンプレミス環境に W&B プラットフォームをデプロイします
# Kubernetes Operator を使用して W&B をデプロイする
概要
このページでは、プラットフォーム管理者向けに、W\&B Kubernetes Operator を使用して Kubernetes (クラウドまたはオンプレミス) 上に W\&B Server をデプロイおよび管理する方法を説明します。この手順を完了すると、オペレーターが自動で管理・アップグレードする W\&B Server 環境が稼働した状態になります。W\&B デプロイメントをセルフマネージドで運用しており、クラウド、オンプレミス、エアギャップ環境のいずれにも対応したインストール方法が必要な場合は、このガイドを参照してください。
W\&B Kubernetes Operator は、Kubernetes (クラウドまたはオンプレミス) 上に W\&B Server をデプロイする際の推奨方法です。オペレーターの概要、W\&B がオペレーターを採用している理由、設定の階層構造の仕組みについては、[セルフマネージド](/ja/products/wandb/platform/hosting/hosting-options/self-managed#about-the-wb-kubernetes-operator)を参照してください。
始める前に
Kubernetes Operator を使用して W\&B をデプロイする前に、インフラストラクチャーがすべての要件を満たしていることを確認してください。
1. **インフラストラクチャー要件を確認する**: 次の項目の詳細については、[セルフマネージドのインフラストラクチャー要件](/ja/products/wandb/platform/hosting/self-managed/requirements)ページを参照してください。
* ソフトウェアのバージョン要件 (Kubernetes、MySQL、Redis、Helm、ClickHouse)
* ハードウェア要件 (CPU アーキテクチャー、推奨サイジング)
* Kubernetes クラスターの設定
* ネットワーク、SSL/TLS、DNS の要件
2. **W\&B Server のライセンスを取得する**: 要件ページの [License](/ja/products/wandb/platform/hosting/self-managed/requirements#license) セクションを参照してください。
3. **外部サービスをプロビジョニングする**: デプロイの前に、MySQL、Redis、オブジェクトストレージを設定してください。
関連情報については、[リファレンスアーキテクチャ](/ja/products/wandb/platform/hosting/self-managed/ref-arch)ページを参照してください。
MySQL データベース
MySQL 8.0.x は 2026 年 4 月にサポート終了を迎えました。W\&B Self-Managed のデプロイメントでは、セキュリティパッチと重要なバグ修正が提供される、サポート対象の MySQL バージョンを実行する必要があります。コミュニティ版 MySQL を使用している場合は、**MySQL 8.4.x** をインストールするか、8.4.x にアップグレードしてください。マネージドサービスを使用している場合は、プロバイダーがサポート対象かつパッチ適用済みとして明記しているエンジンバージョンを実行してください (例: Amazon RDS for MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL)。W\&B は、MySQL 8.4.0 および現行の 8.4.x リリースでプラットフォームの動作を検証済みです。まだ MySQL 8.0.x を使用している場合は、[MySQL を 8.4.x にアップグレードする](/ja/products/wandb/platform/hosting/self-managed/operator#upgrade-mysql-to-84x) の手順を参照して、アップグレードを計画してください。
W\&B には外部の MySQL データベースが必要です。
本番環境では、マネージドデータベースサービスの使用を推奨します。
* [AWS RDS Aurora MySQL](https://aws.amazon.com/rds/aurora/)
* [Google Cloud SQL for MySQL](https://cloud.google.com/sql/mysql)
* [Azure Database for MySQL](https://azure.microsoft.com/en-us/products/mysql/)
マネージドデータベースサービスは、自動バックアップ、モニタリング、高可用性、パッチ適用などの機能を備えており、運用上の負担を軽減できます。
サイジングの推奨事項や設定パラメーターなど、MySQL の要件については[リファレンスアーキテクチャ](/ja/products/wandb/platform/hosting/self-managed/ref-arch#mysql)を参照してください。データベースを作成するための SQL については、[ベアメタルガイド](/ja/products/wandb/platform/hosting/self-managed/operator#mysql-database)を参照してください。デプロイメントのデータベース設定に関するご質問は、[サポート](mailto:forge-support@coreweave.com)または担当の AISE にお問い合わせください。
設定パラメーターやデータベースの作成方法など、MySQL のセットアップ手順の詳細については、[要件ページの MySQL セクション](/ja/products/wandb/platform/hosting/self-managed/requirements#mysql-database)を参照してください。
MySQL 8.0.x からアップグレードする場合は、[MySQL を 8.4.x にアップグレードする](#upgrade-mysql-to-84x)を参照してください。
Redis
W\&B は単一ノード構成の Redis 7.x デプロイメントを必要とし、W\&B の各コンポーネントはこれをジョブのキュー管理やデータのキャッシュに使用します。テストや概念実証 (PoC) 向けに、W\&B Self-Managed にはローカルの Redis デプロイメントが含まれています。このバンドルされたデプロイメントは、本番環境での使用には適していません。
本番環境のデプロイメントでは、W\&B は次の環境にある Redis インスタンスに接続できます。
* [Amazon ElastiCache](https://aws.amazon.com/elasticache/)
* [Google Cloud Memorystore](https://cloud.google.com/memorystore?hl=en)
* [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache)
* クラウドまたはオンプレミスのインフラストラクチャー上でセルフホストしている Redis
Helm values で外部 Redis インスタンスを設定する方法について詳しくは、[外部 Redis の設定セクション](#external-redis)を参照してください。
オブジェクトストレージ
W\&B には、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。
W\&B では、次のストレージプロバイダーを推奨しています。
* [Amazon S3](https://aws.amazon.com/s3/): スケーラビリティ、データの可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。
* [Google Cloud Storage](https://cloud.google.com/storage): 非構造化データを大規模に保存するためのマネージドサービスです。
* [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs): 非構造化データを大規模に保存するためのクラウドベースのオブジェクトストレージです。
* [CoreWeave AI Object Storage](/products/storage/object-storage): AI ワークロード向けに最適化された S3互換のオブジェクトストレージです。
* [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor)、[NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) などのエンタープライズ向け S3互換ストレージ、またはその他のエンタープライズソリューション。
MinIO のオープンソース版は[メンテナンスモード](https://github.com/minio/minio)に移行しており、現在は開発が行われておらず、コンパイル済みバイナリも提供されていません。本番デプロイメントでは、マネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ向け S3互換ソリューションの使用を推奨します。
プロバイダーを選択したら、W\&B がアクセスできるようにバケットを設定します。IAM ポリシー、CORS 設定、アクセスのセットアップなど、バケットのプロビジョニング手順の詳細については、[Bring Your Own Bucket (BYOB) ガイド](/ja/products/wandb/platform/hosting/data-security/secure-storage-connector)を参照してください。
キャパシティやパフォーマンスに関するガイダンスなど、オブジェクトストレージ要件の一覧については、[リファレンスアーキテクチャのオブジェクトストレージセクション](/ja/products/wandb/platform/hosting/self-managed/ref-arch#object-storage)を参照してください。
ストレージバケットをプロビジョニングする
W\&B を設定する前に、オブジェクトストレージバケットをプロビジョニングし、必要な IAM ポリシー、CORS 設定、およびアクセス用の認証情報を構成しておく必要があります。
以下の各ストレージにおけるプロビジョニングの詳しい手順については、[Bring your own bucket を使用する (BYOB) ガイド](/ja/products/wandb/platform/hosting/data-security/secure-storage-connector)を参照してください。
* Amazon S3 (IAM ポリシーおよびバケットポリシーを含む)
* Google Cloud Storage (PubSub 通知を含む)
* Azure Blob Storage (マネージド ID を含む)
* CoreWeave AI Object Storage
* S3互換ストレージ (MinIO Enterprise、NetApp StorageGRID、その他のエンタープライズ向けソリューション)
Helm values でオブジェクトストレージを設定する方法の詳細については、[オブジェクトストレージの設定](#object-storage-bucket)セクションを参照してください。
OpenShift Kubernetes クラスター
W\&B は、クラウド、オンプレミス、エアギャップ環境の [OpenShift Kubernetes クラスター](https://www.redhat.com/en/technologies/cloud-computing/openshift) へのデプロイをサポートしています。
公式の W\&B Helm チャートを使用してインストールすることを推奨します。
非特権ユーザーとしてコンテナーを実行する
OpenShift などのオーケストレーターでは、root として実行されるコンテナーが拒否されることがよくあります。そのため、W\&B のコンテナーは、root グループに属したまま非 root ユーザーとして実行されるように設定する必要があります。デフォルトでは、コンテナーは `$UID` として 999 を使用します。オーケストレーターがコンテナーを非 root ユーザーで実行するよう要求する場合は、`$UID` に 100000 以上の値を、`$GID` に 0 を指定してください。
ファイルシステムの権限を正しく機能させるには、W\&B を root グループ (`$GID=0`) で起動する必要があります。
W\&B の各コンポーネントにセキュリティコンテキストを設定します。たとえば、API コンポーネントの場合は次のように設定します。
```yaml theme={"system"}
api:
install: true
image:
repository: wandb/megabinary
tag: 0.74.1 # 実際に使用するバージョンに置き換えてください
pod:
securityContext:
fsGroup: 10001
fsGroupChangePolicy: Always
runAsGroup: 0
runAsNonRoot: true
runAsUser: 10001
seccompProfile:
type: RuntimeDefault
container:
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
privileged: false
readOnlyRootFilesystem: false
```
必要に応じて、`app` や `console` など他のコンポーネントにもカスタムセキュリティコンテキストを設定します。詳細については、[カスタムセキュリティコンテキスト](#custom-security-context)を参照してください。
W\&B Server アプリケーションをデプロイする
クラウド、オンプレミス、エアギャップ環境を含むすべての W\&B セルフマネージドのデプロイでは、**Helm を使用した W\&B Kubernetes Operator によるインストールを推奨します**。
デプロイ方法を選択してください。
W\&B は、W\&B Kubernetes Operator を Kubernetes クラスターにデプロイするための Helm チャートを提供しています。この方法を使用すると、Helm CLI または ArgoCD などの継続的デリバリーツールで W\&B Server をデプロイできます。
デプロイメント固有の考慮事項については、[環境固有の考慮事項](#environment-specific-considerations) および [パブリッククラウドで Terraform を使用してデプロイする](#deploy-with-terraform-on-public-cloud) を参照してください。インターネットに接続されていない環境については、[Deploy on Air-Gapped Kubernetes](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) を参照してください。
Helm CLI を使用して W\&B Kubernetes Operator をインストールするには、次の手順に従います。
1. W\&B Helm リポジトリを追加します。W\&B Helm チャートは W\&B Helm リポジトリで提供されています。
```shell theme={"system"}
helm repo add wandb https://charts.wandb.ai
helm repo update
```
2. Kubernetes クラスターにオペレーターをインストールします。
```shell theme={"system"}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
3. W\&B オペレーターのカスタムリソースを設定して、W\&B Server のインストールをトリガーします。W\&B デプロイメントの設定を記述した `operator.yaml` という名前のファイルを作成します。使用可能なすべてのオプションについては、[設定リファレンス](#configuration-reference-for-wb-server) を参照してください。
最小構成の例を次に示します。
```yaml theme={"system"}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
labels:
app.kubernetes.io/name: weightsandbiases
app.kubernetes.io/instance: wandb
name: wandb
namespace: default
spec:
values:
global:
host: https://
license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
bucket:
mysql:
ingress:
annotations:
```
4. カスタム設定でオペレーターを起動します。これにより、オペレーターが W\&B Server アプリケーションのインストール、設定、管理を行えるようになります。
```shell theme={"system"}
kubectl apply -f operator.yaml
```
デプロイメントが完了するまで待ちます。完了までには数分かかります。
5. Web UI でインストールを確認するには、最初の管理者ユーザーアカウントを作成してから、[インストールを確認する](#verify-the-installation) に記載されている検証手順に従います。
これらの手順が完了すると、`wandb-cr` namespace で W\&B Kubernetes Operator が実行され、そのオペレーターが `operator.yaml` カスタムリソースに基づいて W\&B Server アプリケーションを管理する状態になります。
Terraform を使用すると、Infrastructure as Code の手法で W\&B をデプロイできます。次のいずれかを選択してください。
* **Helm Terraform Module**: 既存の Kubernetes インフラストラクチャーにオペレーターをデプロイします。
* **Cloud Terraform Modules**: AWS、Google Cloud、Azure 向けに、インフラストラクチャーからアプリケーションまでをまとめてデプロイします。
デプロイメント固有の考慮事項については、[環境固有の考慮事項](#environment-specific-considerations) および [パブリッククラウドで Terraform を使用してデプロイする](#deploy-with-terraform-on-public-cloud) を参照してください。インターネットから切り離された環境については、[Deploy on Air-Gapped Kubernetes](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) を参照してください。
この方法では、Terraform の Infrastructure as Code のアプローチによって一貫性と再現性を確保しつつ、特定の要件に合わせてカスタマイズしたデプロイメントを構築できます。W\&B 公式の [Helm ベースの Terraform モジュール](https://registry.terraform.io/modules/wandb/wandb/helm/latest) は Terraform Registry で公開されています。
次のコードをベースとして使用してください。本番環境レベルのデプロイメントに必要な設定オプションがすべて含まれています。
```hcl theme={"system"}
module "wandb" {
source = "wandb/wandb/helm"
spec = {
values = {
global = {
host = "https://"
license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"
bucket = {
}
mysql = {
}
}
ingress = {
annotations = {
"a" = "b"
"x" = "y"
}
}
}
}
}
```
設定オプションは [設定リファレンス](#configuration-reference-for-wb-server) で説明されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは W\&B のカスタムリソース定義 (CRD) を作成します。
W\&B 自身が Helm Terraform モジュールを使用して、お客様向けの専用クラウドのインストールをどのようにデプロイしているかについては、以下のリンクを参照してください。
* [AWS](https://github.com/wandb/terraform-aws-wandb/blob/45e1d746f53e78e73e68f911a1f8cad5408e74b6/main.tf#L225)
* [Azure](https://github.com/wandb/terraform-azurerm-wandb/blob/170e03136b6b6fc758102d59dacda99768854045/main.tf#L155)
* [Google Cloud](https://github.com/wandb/terraform-google-wandb/blob/49ddc3383df4cefc04337a2ae784f57ce2a2c699/main.tf#L189)
W\&B は、AWS、Google Cloud、Azure 向けの Terraform モジュール群を提供しています。これらのモジュールは、W\&B Server アプリケーションとともに、Kubernetes クラスター、ロードバランサー、MySQL データベースを含むインフラストラクチャー一式をデプロイします。W\&B Kubernetes Operator は、W\&B 公式のクラウド別 Terraform モジュールの以下のバージョンに含まれています。
| Terraform Registry | ソースコード | バージョン |
| - | - | - |
| [AWS](https://registry.terraform.io/modules/wandb/wandb/aws/latest) | [https://github.com/wandb/terraform-aws-wandb](https://github.com/wandb/terraform-aws-wandb) | v4.0.0+ |
| [Azure](https://github.com/wandb/terraform-azurerm-wandb) | [https://github.com/wandb/terraform-azurerm-wandb](https://github.com/wandb/terraform-azurerm-wandb) | v2.0.0+ |
| [Google Cloud](https://github.com/wandb/terraform-google-wandb) | [https://github.com/wandb/terraform-google-wandb](https://github.com/wandb/terraform-google-wandb) | v2.0.0+ |
これらのモジュールはデプロイメント時に W\&B Kubernetes Operator をインストールするため、追加のセットアップなしで、クラウド環境の W\&B Server を Operator で管理できます。
これらのクラウド別モジュールの使用方法の詳細については、[パブリッククラウドで Terraform を使用してデプロイする](#deploy-with-terraform-on-public-cloud) を参照してください。
インストールを確認する
インストールを確認するため、W\&B は [W\&B CLI](/ja/products/wandb/ref/cli) の使用を推奨します。`wandb verify` コマンドは、コンポーネントと設定が期待どおりに動作することを確認するテストを実行します。
この手順では、ブラウザーで最初の管理者ユーザーアカウントを作成することを前提としています。
インストールを確認する：
1. W\&B CLI をインストールします：
```bash theme={"system"}
pip install wandb
```
2. W\&B にログインします：
```bash theme={"system"}
wandb login --host=https://YOUR_DNS_DOMAIN
```
例：
```bash theme={"system"}
wandb login --host=https://wandb.company-name.com
```
3. インストールを確認します：
```bash theme={"system"}
wandb verify
```
コマンドの実行後、インストールが成功すると、次の出力が表示されます：
```console theme={"system"}
Default host selected: https://wandb.company-name.com
Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
Checking if logged in...................................................✅
Checking signed URL upload..............................................✅
Checking ability to send large payloads through proxy...................✅
Checking requests to base url...........................................✅
Checking requests made over signed URLs.................................✅
Checking CORs configuration of the bucket...............................✅
Checking wandb package version is up to date............................✅
Checking logged metrics, saving and downloading a file..................✅
Checking artifact save and download workflows...........................✅
```
エラーが発生した場合は、W\&B サポートチームにお問い合わせください。
MCP サーバーを有効にする
[W\&B MCP Server](/ja/products/wandb/platform/mcp-server) は、`operator-wandb` のオプションのサブチャートとして提供されています。有効にすると、オペレーターがクラスター内に MCP サーバーをデプロイし、既存のイングレス経由で `/mcp` に公開します。これにより、MCP 対応クライアントであれば W\&B APIキーを使用して接続できます。このサーバーは、W\&B が `https://mcp.withwandb.com/mcp` でホスト型サービスとして運用しているものと同じですが、お使いのデプロイメントのデータを参照するように構成されています。
エンドユーザー向けのクライアント設定とツールカタログについては、[Use the W\&B MCP server](/ja/products/wandb/platform/mcp-server) を参照してください。このセクションでは、オペレーター側での有効化の手順のみを説明します。
前提条件
MCP サーバーを有効にする前に、デプロイメントが次の要件を満たしていることを確認してください。
* **チャートのバージョン**: `operator-wandb` `0.42.3` 以降。`mcp-server` サブチャートは `0.42.1` で導入されましたが、次の例で使用する Datadog とプライバシー関連のフィールドはそれ以降に追加されたものです。
* **Weave トレースの有効化**: MCP サーバーは、トレースツールと `WF_TRACE_SERVER_URL` のデフォルト値を Weave トレースに依存しています。`weave-trace.install: true` を設定してください。Weave トレースが有効になっていない場合、Helm のレンダリングは `mcp-server requires weave-trace.install=true` というエラーで失敗します。
* **到達可能なイングレス**: `global.host` の名前解決ができ、W\&B のイングレスにルーティングされている状態になっている必要があります。MCP Pod は `global.host` から `WANDB_BASE_URL` を読み取り、`/mcp` でアクセスできるようになります。
* **ノードのキャパシティ**: MCP Pod は、デフォルトで CPU `500m` とメモリ `1Gi` をリクエストします (制限は CPU `2`、メモリ `4Gi`)。サブチャートを有効にする前に、Node Pool に十分な空きリソースがあることを確認してください。
サブチャートを有効にする
`mcp-server` サブチャートを有効にして、オペレーターがクラスター内に MCP サーバーをデプロイし、既存の W\&B イングレスに `/mcp` ルートを追加するようにします。既存の `WeightsAndBiases` カスタムリソース (CR) の `spec.values` ブロックに、既存の `global`、`ingress`、その他のオーバーライドとあわせて以下を追加してください。Datadog ブロックは任意ですが、クラスター内の Datadog Agent DaemonSet がすでに Pod のログとトレースを収集している場合は追加することをお勧めします。
```yaml theme={"system"}
spec:
values:
weave-trace:
install: true
mcp-server:
install: true
image:
repository: us-docker.pkg.dev/wandb-production/public/wandb/mcp-server
tag: "0.3.3"
datadog:
enabled: true
mode: "agent"
service: "wandb-mcp-server-"
env: ""
deploymentType: "self-managed"
customer: ""
extraTags:
- "region:"
- "tier:"
privacy:
logLevel: "standard"
```
各ブロックを設定します。
* **`weave-trace.install: true`**: `mcp-server.env.WF_TRACE_SERVER_URL` を自分で設定する場合を除き、必須です。
* **`datadog.mode: "agent"`**: Datadog Agent DaemonSet がログとトレースの収集を担う Kubernetes デプロイメントで使用します。agent モードでは、MCP Pod に Datadog APIキーは不要です。
* **`datadog.service`、`env`、`deploymentType`、`customer`、`extraTags`**: デプロイメントの可観測性に関する命名規則に合わせて設定します。customer タグが不要な場合は、`customer` を空文字列に設定します。
* **`privacy.logLevel`**: ほとんどのセルフマネージド Kubernetes 環境では `"standard"` を使用します。この設定では、オペレーターがデバッグによく使用するデプロイメント識別子は残したまま、ログ内の自由記述のパラメーター値をマスクします。entity、project、run、またはユーザーの識別子を平文のログに残したくない場合は `"strict"` を使用します。`"off"` は、これらの値を平文でログすることを明示的に求める場合にのみ使用してください。
変更を適用して、リコンサイルをトリガーします。
```bash theme={"system"}
kubectl apply -f operator.yaml
```
オペレーターは、リリースの namespace に `wandb-mcp-server` のデプロイメントとサービスを作成し、W\&B のイングレスに `/mcp` パスを追加します。
MCP サーバーを確認する
Pod が `Running` 状態になるまで待ってから、クラスター内から、およびイングレス経由でヘルスエンドポイントを確認します。
```bash theme={"system"}
kubectl get pod -l app.kubernetes.io/component=mcp-server
kubectl port-forward svc/wandb-mcp-server 8080:8080
curl -s http://localhost:8080/mcp/health
curl -s "https:///mcp/health"
```
どちらのリクエストも `200 OK` を返すはずです。クラスター内チェックでは Pod が正常であることを、イングレスチェックではルーティングが機能していることを確認します。クラスター内チェックでは `200 OK` が返されるのに、イングレスチェックで `404 Not Found` が返される場合は、[トラブルシューティング](#troubleshooting)を参照してください。Datadog を有効にした場合は、MCP サーバーのログが、設定した `mcp-server.datadog.service` と `mcp-server.datadog.env` の値とともに Datadog にも表示されるはずです。
クライアントを接続する
MCP サーバーが正常な状態になったら、`https:///mcp` を使用するように MCP クライアントを設定し、W\&B APIキーを Bearer token として指定します。IDE やエージェントの設定については、[Use the W\&B MCP server](/ja/products/wandb/platform/mcp-server) を参照してください。
トラブルシューティング
| 症状 | 原因と対処法 |
| - | - |
| `helm render` が `mcp-server requires weave-trace.install=true` で失敗する | `spec.values` に `weave-trace.install: true` を追加します。MCP サーバーのトレースツールは Weave トレースに依存しています。 |
| `wandb-mcp-server` Pod が `Insufficient cpu` または `Insufficient memory` により `Pending` のまま停止している | ノードのキャパシティを追加するか、CR 内の `mcp-server.resources.requests` の値を下げます。デフォルトは CPU が `500m`、メモリが `1Gi` です。 |
| `curl https:///mcp/health` が 404 を返す | チャートは、`mcp-server.install: true` の場合にのみ `/mcp` のイングレスパスをレンダリングします。CR を再適用し、Ingress コントローラーに新しいパスが反映されるまで待ちます。 |
| MCP のログが Datadog に表示されない | `mcp-server.datadog.enabled: true` と `mcp-server.datadog.mode: "agent"` が設定されていること、および Datadog Agent の DaemonSet が Pod の stdout を収集していることを確認します。Datadog では、設定済みの `service` と `env` の値で検索します。 |
| MCP のログに、ユーザーが入力したテキストが想定以上に含まれている | `mcp-server.privacy.logLevel` を `"standard"` または `"strict"` に設定します。entity、project、run、ユーザー名などの識別子を平文のログに残したくない場合は、`"strict"` を使用します。 |
| エアギャップ環境またはミラー構成のクラスターで、`wandb-mcp-server` Pod が `ImagePullBackOff` 状態になる | イメージを自社のレジストリにミラーリングし、CR 内の `mcp-server.image.repository` を上書きします。これは、エアギャップ環境へのインストールで他の W\&B コンポーネントのイメージに用いる方法と同じです。[Deploy on Air-Gapped Kubernetes](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) を参照してください。 |
環境固有の考慮事項
Kubernetes は、オンプレミスとクラウドのどちらで実行しても同じように動作します。主な違いは、名称とマネージドサービスにあります (たとえば、MySQL と RDS、S3 とオンプレミスのオブジェクトストレージなど) 。このセクションでは、環境によって異なる考慮事項について説明します。
オンプレミスまたはベアメタルの Kubernetes にデプロイする場合は、次の点に注意してください。
ロードバランサーの設定
オンプレミスの Kubernetes クラスターでは、通常、ロードバランサーを手動で設定する必要があります。主な選択肢は次のとおりです。
* **外部ロードバランサー**: F5 や HAProxy など、既存のハードウェアまたはソフトウェアのロードバランサーを設定します。
* **Nginx Ingress Controller**: NodePort またはホストネットワークを使用して nginx-ingress-controller をデプロイします。
* **MetalLB**: ベアメタルの Kubernetes クラスターでは、MetalLB を使用してロードバランサーサービスを提供できます。
ロードバランサーの詳細な設定例については、[リファレンスアーキテクチャのネットワークセクション](/ja/products/wandb/platform/hosting/self-managed/ref-arch#networking)を参照してください。
永続ストレージ
Kubernetes クラスターに、Persistent Volume 用の StorageClass が設定されていることを確認してください。W\&B のコンポーネントでは、キャッシュや一時データの保存に永続ストレージが必要になる場合があります。
オンプレミス環境で一般的に使用されるストレージには、次のようなものがあります。
* NFS ベースのストレージクラス
* Ceph/Rook ストレージ
* ローカル Persistent Volume
* NetApp や Pure Storage などのエンタープライズストレージソリューション
DNS と証明書の管理
オンプレミスのデプロイメントでは、次のタスクを実施します。
* W\&B のホスト名を指すように内部 DNS レコードを設定します。
* 社内の認証局 (CA) から SSL/TLS 証明書を発行します。
* 自己署名証明書を使用する場合は、CA 証明書を信頼するようにオペレーターを設定します。
証明書の設定の詳細については、[SSL/TLS の要件](/ja/products/wandb/platform/hosting/self-managed/requirements#ssl-tls)を参照してください。
OpenShift デプロイメント
W\&B は、OpenShift Kubernetes クラスターへのデプロイを完全にサポートしています。OpenShift はセキュリティポリシーがより厳格なため、OpenShift デプロイメントではセキュリティコンテキストの追加設定が必要です。
OpenShift 固有の設定の詳細については、[OpenShift Kubernetes クラスター](#openshift-kubernetes-clusters) を参照してください。エアギャップ環境での OpenShift の設定例については、[Deploy on Air-Gapped Kubernetes](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped#openshift-configuration) を参照してください。
オンプレミスおよび S3互換のオブジェクトストレージ
オブジェクトストレージバケットをプロビジョニングしたら ([オブジェクトストレージのプロビジョニング](/ja/products/wandb/platform/hosting/data-security/secure-storage-connector)を参照) 、W\&B カスタムリソース でそのバケットを設定します。
**AWS S3 (オンプレミス)**
オンプレミスの AWS S3 (Outposts または互換ストレージを使用) の場合は、次のように設定します。
```yaml theme={"system"}
bucket:
kmsKey: # 暗号化に使用する KMS キー（オプション）
name: # 例: wandb
path: "" # 空文字列のままにしてください
provider: s3
region: # 例: us-east-1
```
**MinIO、Ceph、NetApp などの S3互換ストレージ**
S3互換ストレージシステムの場合：
```yaml theme={"system"}
bucket:
kmsKey: null
name: # 例: s3.example.com:9000
path: # 例: wandb
provider: s3
region: # 例: us-east-1
```
S3互換ストレージで TLS を有効にするには、バケットのパスの末尾に `?tls=true` を追加します。
```yaml theme={"system"}
bucket:
path: "wandb?tls=true"
```
証明書は信頼されたものである必要があります。自己署名証明書を使用する場合は、追加の設定が必要です。詳細については、[SSL/TLS の要件](/ja/products/wandb/platform/hosting/self-managed/requirements#ssl-tls)を参照してください。
**オンプレミスのオブジェクトストレージに関する重要な考慮事項**
独自のオブジェクトストレージを運用する場合は、次の点を考慮してください。
1. **ストレージのキャパシティとパフォーマンス**: ディスク容量を注意深く監視してください。W\&B の平均的な使用量は数十〜数百 GB です。使用量が多い場合、ストレージ消費量がペタバイト規模に達することがあります。
2. **フォールトトレランス**: 物理ディスクには、少なくとも RAID アレイを使用してください。S3互換ストレージの場合は、分散構成または高可用性構成を使用してください。
3. **可用性**: ストレージの可用性を維持できるよう、モニタリングを設定してください。
**MinIO に関する考慮事項**
MinIO Open Source は[メンテナンスモード](https://github.com/minio/minio)に移行しており、積極的な開発は行われていません。コンパイル済みバイナリの提供は終了しており、重要なセキュリティ修正のみが個別に検討されます。本番環境のデプロイメントには、マネージドオブジェクトストレージサービスまたは [MinIO Enterprise (AIStor)](https://min.io/product/aistor) の使用を W\&B は推奨します。
オンプレミスのオブジェクトストレージには、次のようなエンタープライズ向けの代替製品があります。
* [Amazon S3 on Outposts](https://aws.amazon.com/s3/outposts/)
* [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/)
* MinIO Enterprise (AIStor)
* [Dell ObjectScale](https://www.dell.com/en-us/shop/cty/sf/objectscale)
既存の MinIO デプロイメントまたは MinIO Enterprise を使用している場合は、MinIO クライアントでバケットを作成できます。
```bash theme={"system"}
mc config host add local http://$MINIO_HOST:$MINIO_PORT "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY" --api s3v4
mc mb --region=us-east-1 local/wandb-files
```
AWS、Google Cloud、または Azure で、インフラストラクチャーからアプリケーションまでを含むフルデプロイメントを行う場合は、[パブリッククラウドで Terraform を使用してデプロイする](#deploy-with-terraform-on-public-cloud)を参照してください。
W\&B では、[W\&B Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) や [W\&B 専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud) などの完全マネージドなデプロイメントタイプを推奨しています。完全マネージドサービスでは、設定はほとんど、またはまったく必要ありません。
W\&B は、パブリッククラウドプロバイダー上にプラットフォームをデプロイするための Terraform モジュールを提供しています。これらのモジュールによってインフラストラクチャーのプロビジョニングと W\&B Server のインストールが自動化されるため、クラウドリソースを 1 つずつ手動で作成しなくても、完全な環境を構築できます。
作業を始める前に、[State File](https://developer.hashicorp.com/terraform/language/state) の保存先として、Terraform で利用できる [リモートバックエンド](https://developer.hashicorp.com/terraform/language/backend) のいずれかを選択することをおすすめします。State File は、すべてのコンポーネントを再作成せずにアップグレードをロールアウトしたり、デプロイメントに変更を加えたりするために必要なリソースです。
クラウドプロバイダーを選択してください:
AWS にプラットフォームをデプロイするには、[W\&B Server AWS Terraform モジュール](https://registry.terraform.io/modules/wandb/wandb/aws/latest) を使用することを推奨します。
Terraform モジュールは、次の必須コンポーネントをデプロイします。
* ロードバランサー
* AWS Identity & Access Management (IAM)
* AWS Key Management System (KMS)
* Amazon Aurora MySQL
* Amazon VPC
* Amazon S3
* Amazon Route53
* Amazon Certificate Manager (ACM)
* Amazon Elastic Load Balancing (ALB)
* Amazon Secrets Manager
オプションのコンポーネントには次のものがあります。
* Elastic Cache for Redis
* SQS
前提として必要な権限
Terraform を実行するアカウントには、前のセクションに記載されたすべてのコンポーネントを作成できることに加えて、**IAM ポリシー**と **IAM ロール**を作成し、リソースにロールを割り当てる権限が必要です。
一般的な手順
このセクションの手順は、どのデプロイメントオプションでも共通です。
1. 開発環境を準備します。
* [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) をインストールします。
* W\&B では、バージョン管理用に Git リポジトリを作成することを推奨しています。
2. `terraform.tfvars` ファイルを作成します。
インストールのタイプに応じて、`tvfars` ファイルの内容をカスタマイズします。推奨される最小限の内容は次の例のとおりです。
```bash theme={"system"}
namespace = "wandb"
license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain = "wandb-aws"
domain_name = "wandb.ml"
zone_id = "xxxxxxxxxxxxxxxx"
allowed_inbound_cidr = ["0.0.0.0/0"]
allowed_inbound_ipv6_cidr = ["::/0"]
eks_cluster_version = "1.29"
```
`namespace` 変数は、Terraform が作成するすべてのリソースに付与される接頭辞の文字列です。そのため、デプロイする前に `tvfars` ファイルで変数を定義してください。
`subdomain` と `domain` を組み合わせたものが、W\&B インスタンスの FQDN になります。上記の例では、W\&B の FQDN は `wandb-aws.wandb.ml` となり、Terraform は DNS の `zone_id` で指定されたゾーンに FQDN レコードを作成します。
`allowed_inbound_cidr` と `allowed_inbound_ipv6_cidr` の両方も設定する必要があります。これらはモジュールの必須入力です。次の例では、すべてのソースから W\&B インストールへのアクセスを許可します。
3. `versions.tf` ファイルを作成します。
このファイルには、AWS に W\&B をデプロイするために必要な Terraform および Terraform プロバイダーのバージョンが記載されています：
```bash theme={"system"}
provider "aws" {
region = "eu-central-1"
default_tags {
tags = {
GithubRepo = "terraform-aws-wandb"
GithubOrg = "wandb"
Enviroment = "Example"
Example = "PublicDnsExternal"
}
}
}
```
AWS プロバイダーの設定方法については、[Terraform 公式ドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration)を参照してください。
W\&B では、このドキュメントの冒頭で説明した [リモートバックエンドの設定](https://developer.hashicorp.com/terraform/language/backend) もあわせて追加することを推奨しています。
4. `variables.tf` ファイルを作成します
Terraform では、`terraform.tfvars` で設定するすべてのオプションに対して、対応する変数宣言が必要です。
```hcl theme={"system"}
variable "namespace" {
type = string
description = "Name prefix used for resources"
}
variable "domain_name" {
type = string
description = "Domain name used to access instance."
}
variable "subdomain" {
type = string
default = null
description = "Subdomain for accessing the Weights & Biases UI."
}
variable "license" {
type = string
}
variable "zone_id" {
type = string
description = "Domain for creating the Weights & Biases subdomain on."
}
variable "allowed_inbound_cidr" {
description = "CIDRs allowed to access wandb-server."
nullable = false
type = list(string)
}
variable "allowed_inbound_ipv6_cidr" {
description = "CIDRs allowed to access wandb-server."
nullable = false
type = list(string)
}
variable "eks_cluster_version" {
description = "EKS cluster kubernetes version"
nullable = false
type = string
}
```
推奨デプロイメント
これは最もシンプルなデプロイメントオプションの設定です。必須のコンポーネントをすべて作成し、最新バージョンの W\&B を Kubernetes クラスターにインストールします。
1. `main.tf` を作成します
General Steps で作成したファイルと同じディレクトリに、次の内容で `main.tf` ファイルを作成します。
```hcl theme={"system"}
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "~>7.0"
namespace = var.namespace
domain_name = var.domain_name
license = var.license
subdomain = var.subdomain
zone_id = var.zone_id
allowed_inbound_cidr = var.allowed_inbound_cidr
allowed_inbound_ipv6_cidr = var.allowed_inbound_ipv6_cidr
public_access = true
external_dns = true
kubernetes_public_access = true
kubernetes_public_access_cidrs = ["0.0.0.0/0"]
eks_cluster_version = var.eks_cluster_version
}
data "aws_eks_cluster" "eks_cluster_id" {
name = module.wandb_infra.cluster_name
}
data "aws_eks_cluster_auth" "eks_cluster_auth" {
name = module.wandb_infra.cluster_name
}
provider "kubernetes" {
host = data.aws_eks_cluster.eks_cluster_id.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.eks_cluster_auth.token
}
provider "helm" {
kubernetes {
host = data.aws_eks_cluster.eks_cluster_id.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.eks_cluster_auth.token
}
}
output "url" {
value = module.wandb_infra.url
}
output "bucket" {
value = module.wandb_infra.bucket_name
}
```
2. W\&B をデプロイします
W\&B をデプロイするには、次のコマンドを実行します。
```bash theme={"system"}
terraform init
terraform apply -var-file=terraform.tfvars
```
Redis を有効にする
Redis を使用して SQL クエリをキャッシュし、メトリクスの読み込み時にアプリケーションの応答を高速化するには、`main.tf` ファイルに `create_elasticache_subnet = true` オプションを追加します。
```hcl theme={"system"}
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "~>7.0"
namespace = var.namespace
domain_name = var.domain_name
subdomain = var.subdomain
zone_id = var.zone_id
create_elasticache_subnet = true
}
[...]
```
メッセージブローカー (キュー) を有効にする
SQS を使用する外部メッセージブローカーを有効にするには、`main.tf` ファイルに `use_internal_queue = false` オプションを追加します：
W\&B にはブローカーが組み込まれているため、この設定は任意です。このオプションを使用してもパフォーマンスは向上しません。
```hcl theme={"system"}
module "wandb_infra" {
source = "wandb/wandb/aws"
version = "~>7.0"
namespace = var.namespace
domain_name = var.domain_name
subdomain = var.subdomain
zone_id = var.zone_id
use_internal_queue = false
[...]
}
```
その他のリソース
* [AWS Terraform モジュールのドキュメント](https://registry.terraform.io/modules/wandb/wandb/aws/latest)
* [AWS Terraform モジュールのソースコード](https://github.com/wandb/terraform-aws-wandb)
* [オペレーターベースの AWS Terraform モジュールへの移行](#migrate-to-operator-based-aws-terraform-modules)
Google Cloud にプラットフォームをデプロイする場合は、[W\&B Server Google Cloud Terraform モジュール](https://registry.terraform.io/modules/wandb/wandb/google/latest)の使用をおすすめします。
利用可能なすべてのオプションは、モジュールのドキュメントに記載されています。
開始する前に、Terraform で利用できる[リモートバックエンド](https://developer.hashicorp.com/terraform/language/backend/remote)のいずれかを選択し、[State File](https://developer.hashicorp.com/terraform/language/state) の保存先とすることを W\&B では推奨しています。State File は、すべてのコンポーネントを再作成せずにアップグレードをロールアウトしたり、デプロイメントに変更を加えたりするために必要なリソースです。
Terraform モジュールは、次の必須コンポーネントをデプロイします。
* VPC
* Cloud SQL for MySQL
* Cloud Storage バケット
* Google Kubernetes Engine
* Memorystore for Redis
* KMS 暗号鍵
* ロードバランサー
オプションのコンポーネントには次のものがあります。
* Pub/Sub メッセージングシステム
前提として必要な権限
Terraform を実行するアカウントには、使用する Google Cloud プロジェクトで `roles/owner` ロールが付与されている必要があります。
一般的な手順
このセクションの手順は、どのデプロイメントオプションでも共通です。
1. 開発環境を準備します。
* [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) をインストールします。
* W\&B ではコード用の Git リポジトリを作成することを推奨していますが、ファイルをローカルで管理することもできます。
* [Google Cloud Console](https://console.cloud.google.com/) でプロジェクトを作成します。
* `gcloud auth application-default login` を使用して Google Cloud の認証を行います (事前に [gcloud をインストール](https://cloud.google.com/sdk/docs/install)しておいてください) 。
2. `terraform.tfvars` ファイルを作成します。
インストールのタイプに応じて、`tvfars` ファイルの内容をカスタマイズします。推奨される最小限の内容は次の例のとおりです。
```bash theme={"system"}
project_id = "wandb-project"
region = "europe-west2"
zone = "europe-west2-a"
namespace = "wandb"
license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain = "wandb-gcp"
domain_name = "wandb.ml"
```
デプロイの前に、これらの変数の値を決めておく必要があります。`namespace` 変数は文字列で、Terraform が作成するすべてのリソース名の接頭辞として使用されます。
`subdomain` と `domain` を組み合わせたものが、W\&B の設定に使用される FQDN になります。上記の例では、W\&B の FQDN は `wandb-gcp.wandb.ml` です。
3. `variables.tf` ファイルを作成します。
Terraform では、`terraform.tfvars` で設定する各オプションに対応する変数宣言が必要です。
```hcl theme={"system"}
variable "project_id" {
type = string
description = "Project ID"
}
variable "region" {
type = string
description = "Google region"
}
variable "zone" {
type = string
description = "Google zone"
}
variable "namespace" {
type = string
description = "Namespace prefix used for resources"
}
variable "domain_name" {
type = string
description = "Domain name for accessing the Weights & Biases UI."
}
variable "subdomain" {
type = string
description = "Subdomain for access the Weights & Biases UI."
}
variable "license" {
type = string
description = "W&B License"
}
```
推奨デプロイメント
これは最もシンプルなデプロイメントオプションの設定です。必須のコンポーネントをすべて作成し、最新バージョンの W\&B を Kubernetes クラスターにインストールします。
1. `main.tf` を作成します
「General Steps」で作成したファイルと同じディレクトリに、次の内容で `main.tf` ファイルを作成します。
```hcl theme={"system"}
provider "google" {
project = var.project_id
region = var.region
zone = var.zone
}
provider "google-beta" {
project = var.project_id
region = var.region
zone = var.zone
}
data "google_client_config" "current" {}
provider "kubernetes" {
host = "https://${module.wandb.cluster_endpoint}"
cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
token = data.google_client_config.current.access_token
}
provider "helm" {
kubernetes {
host = "https://${module.wandb.cluster_endpoint}"
cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
token = data.google_client_config.current.access_token
}
}
# 必要なサービスをすべて起動します
module "wandb" {
source = "wandb/wandb/google"
version = "~> 10.0"
namespace = var.namespace
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
}
# プロビジョニングされた IP アドレスで DNS を更新してください
output "url" {
value = module.wandb.url
}
output "address" {
value = module.wandb.address
}
output "bucket_name" {
value = module.wandb.bucket_name
}
```
2. W\&B をデプロイします。
W\&B をデプロイするには、次のコマンドを実行します。
```bash theme={"system"}
terraform init
terraform apply -var-file=terraform.tfvars
```
Redis を有効にする
Redis を使用して SQL クエリをキャッシュし、メトリクス読み込み時のアプリケーションの応答を高速化するには、`main.tf` ファイルに `create_redis = true` オプションを追加します：
```hcl theme={"system"}
[...]
module "wandb" {
source = "wandb/wandb/google"
version = "~> 10.0"
namespace = var.namespace
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
create_redis = true
}
[...]
```
メッセージブローカー (キュー) を有効にする
Pub/Sub を使用した外部メッセージブローカーを有効にするには、`main.tf` ファイルに `use_internal_queue = false` オプションを追加します。
W\&B にはブローカーが組み込まれているため、この設定は任意です。このオプションを使用してもパフォーマンスは向上しません。
```hcl theme={"system"}
[...]
module "wandb" {
source = "wandb/wandb/google"
version = "~> 10.0"
namespace = var.namespace
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
use_internal_queue = false
}
[...]
```
その他のリソース
* [Google Cloud Terraform モジュールのドキュメント](https://registry.terraform.io/modules/wandb/wandb/google/latest)
* [Google Cloud Terraform モジュールのソースコード](https://github.com/wandb/terraform-google-wandb)
Azure にプラットフォームをデプロイする場合は、[W\&B Server Azure Terraform モジュール](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest)の使用を推奨します。
利用可能なすべてのオプションは、モジュールのドキュメントに記載されています。
Terraform モジュールは、次の必須コンポーネントをデプロイします。
* Azure Resource Group
* Azure Virtual Network (VPC)
* Azure MySQL Flexible Server
* Azure Storage Account と Blob Storage
* Azure Kubernetes Service
* Azure Application Gateway
オプションのコンポーネントには次のものがあります。
* Azure Cache for Redis
* Azure Event Grid
前提として必要な権限
AzureRM プロバイダーを設定する最も簡単な方法は、[Azure CLI](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/azure_cli) を使用することです。オートメーション用途では、[Azure サービスプリンシパル](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_client_secret)を使用することもできます。
どの認証方式を使用する場合でも、Terraform を実行するアカウントには、前のセクションに記載されているすべてのコンポーネントを作成できる権限が必要です。
一般的な手順
このセクションの手順は、どのデプロイメントオプションでも共通です。
1. 開発環境を準備します。
* [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) をインストールします。
* W\&B ではコード用の Git リポジトリを作成することを推奨していますが、ファイルをローカルで管理することもできます。
2. `terraform.tfvars` ファイルを作成します。
インストールのタイプに応じて、`tvfars` ファイルの内容をカスタマイズします。推奨される最小限の内容は次の例のとおりです。
```bash theme={"system"}
namespace = "wandb"
wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain = "wandb-azure"
domain_name = "wandb.ml"
location = "westeurope"
```
デプロイの前に、これらの変数の値を決めておく必要があります。`namespace` 変数は文字列で、Terraform が作成するすべてのリソース名の接頭辞として使用されます。
`subdomain` と `domain` を組み合わせたものが、W\&B の設定に使用される FQDN になります。上記の例では、W\&B の FQDN は `wandb-azure.wandb.ml` です。
3. `versions.tf` ファイルを作成します。
このファイルには、Azure に W\&B をデプロイするために必要な Terraform と Terraform プロバイダーのバージョンが記述されています：
```bash theme={"system"}
terraform {
required_version = "~> 1.3"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.17"
}
}
}
```
Azure プロバイダーの設定方法については、[Terraform 公式ドキュメント](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs)を参照してください。
W\&B では、このドキュメントの冒頭で説明した [リモートバックエンドの設定](https://developer.hashicorp.com/terraform/language/backend) もあわせて追加することを推奨しています。
4. `variables.tf` ファイルを作成します
Terraform では、`terraform.tfvars` で設定する各オプションに対応する変数宣言が必要です。
```bash theme={"system"}
variable "namespace" {
type = string
description = "String used for prefix resources."
}
variable "location" {
type = string
description = "Azure Resource Group location"
}
variable "domain_name" {
type = string
description = "Domain for accessing the Weights & Biases UI."
}
variable "subdomain" {
type = string
default = null
description = "Subdomain for accessing the Weights & Biases UI. Default creates record at Route53 Route."
}
variable "license" {
type = string
description = "Your wandb/local license"
}
```
推奨デプロイメント
これは最もシンプルなデプロイメントオプションの設定です。必須のコンポーネントをすべて作成し、最新バージョンの W\&B を Kubernetes クラスターにインストールします。
1. `main.tf` を作成します
General Steps で作成したファイルと同じディレクトリに、次の内容で `main.tf` ファイルを作成します。
```bash theme={"system"}
provider "azurerm" {
features {}
}
provider "kubernetes" {
host = module.wandb.cluster_host
cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
client_key = base64decode(module.wandb.cluster_client_key)
client_certificate = base64decode(module.wandb.cluster_client_certificate)
}
provider "helm" {
kubernetes {
host = module.wandb.cluster_host
cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
client_key = base64decode(module.wandb.cluster_client_key)
client_certificate = base64decode(module.wandb.cluster_client_certificate)
}
}
# 必要なサービスをすべて起動します
module "wandb" {
source = "wandb/wandb/azurerm"
version = "~> 1.2"
namespace = var.namespace
location = var.location
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
deletion_protection = false
tags = {
"Example" : "PublicDns"
}
}
output "address" {
value = module.wandb.address
}
output "url" {
value = module.wandb.url
}
```
2. W\&B をデプロイする
W\&B をデプロイするには、次のコマンドを実行します。
```bash theme={"system"}
terraform init
terraform apply -var-file=terraform.tfvars
```
Redis を有効にする
Redis を使用して SQL クエリをキャッシュし、メトリクス読み込み時のアプリケーションの応答を高速化するには、`main.tf` ファイルに `create_redis = true` オプションを追加します。
```bash theme={"system"}
# 必要なサービスをすべて起動します
module "wandb" {
source = "wandb/wandb/azurerm"
version = "~> 1.2"
namespace = var.namespace
location = var.location
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
create_redis = true
[...]
}
```
メッセージブローカー (キュー) を有効にする
Azure Event Grid を使用した外部メッセージブローカーを有効にするには、`main.tf` ファイルに `use_internal_queue = false` オプションを追加します：
W\&B にはブローカーが組み込まれているため、この設定は任意です。このオプションを使用してもパフォーマンスは向上しません。
```bash theme={"system"}
# 必要なサービスをすべて起動します
module "wandb" {
source = "wandb/wandb/azurerm"
version = "~> 1.2"
namespace = var.namespace
location = var.location
license = var.license
domain_name = var.domain_name
subdomain = var.subdomain
use_internal_queue = false
[...]
}
```
その他のリソース
* [Azure Terraform モジュールのドキュメント](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest)
* [Azure Terraform モジュールのソースコード](https://github.com/wandb/terraform-azurerm-wandb)
その他のデプロイメントオプション
すべての設定を同じファイルに追加することで、複数のデプロイメントオプションを組み合わせることができます。各 Terraform モジュールにはさまざまなオプションが用意されており、標準オプションや、推奨デプロイメントのセクションで紹介している最小設定と組み合わせて使用できます。
利用可能なすべてのオプションについては、お使いのクラウドプロバイダー向けのモジュールドキュメントを参照してください。
* [AWS モジュールのドキュメント](https://registry.terraform.io/modules/wandb/wandb/aws/latest)
* [Google Cloud モジュールのドキュメント](https://registry.terraform.io/modules/wandb/wandb/google/latest)
* [Azure モジュールのドキュメント](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest)
W\&B 管理コンソールにアクセスする
W\&B Kubernetes Operator には管理コンソールが付属しており、デプロイメントのステータスの確認、コンポーネントのメトリクスの表示、オペレーターレベルの設定の調整を行えます。管理コンソールには `${HOST_URI}/console` (例: `https://wandb.company-name.com/console`) からアクセスできます。
管理コンソールには、次の 2 つの方法でログインできます。
1. ブラウザーで W\&B アプリケーションを開いてログインします。`${HOST_URI}/` (例: `https://wandb.company-name.com/`) から W\&B アプリケーションにログインします。
2. コンソールにアクセスします。右上隅のアイコンをクリックし、**System console** をクリックします。**System console** エントリは、管理者権限を持つユーザーにのみ表示されます。
次の手順でコンソールにアクセスするのは、オプション 1 が機能しない場合のみにすることをお勧めします。
1. ブラウザーでコンソールアプリケーションを開きます。前のセクションで説明した URL を開くと、ログイン画面にリダイレクトされます。
2. インストール時に生成された Kubernetes シークレットからパスワードを取得します。
```shell theme={"system"}
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
パスワードをコピーします。
3. コンソールにログインします。コピーしたパスワードを貼り付けて、**Login** をクリックします。
W\&B Kubernetes Operator を更新する
このセクションでは、W\&B Kubernetes Operator 自体を更新する方法について説明します。バグ修正や新しいリコンサイル機能を適用するため、オペレーターを定期的に更新してください。
* W\&B Kubernetes Operator を更新しても、W\&B Server アプリケーションは更新されません。
* W\&B Kubernetes Operator を使用しない Helm チャートを使用している場合は、このセクションの手順で W\&B Operator を更新する前に、[移行手順](#migrate-self-managed-instances-to-wb-operator)を参照してください。
次のコードスニペットをターミナルにコピー＆ペーストします。
1. [`helm repo update`](https://helm.sh/docs/helm/helm_repo_update/) でリポジトリを更新します。
```shell theme={"system"}
helm repo update
```
2. [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/) で Helm チャートを更新します。
```shell theme={"system"}
helm upgrade operator wandb/operator -n wandb-cr --reuse-values
```
W\&B Server アプリケーションを更新する
W\&B Kubernetes Operator を使用している場合、W\&B Server アプリケーションを手動で更新する必要はなくなりました。
W\&B ソフトウェアの新しいバージョンがリリースされると、オペレーターが W\&B Server アプリケーションを自動的に更新します。
MySQL を 8.4.x にアップグレードする
MySQL 8.0.x はサポート終了となりました。セルフマネージドのデプロイでは、セキュリティパッチと重要なバグ修正が提供される、サポート対象の MySQL バージョンを実行する必要があります。コミュニティ版の MySQL を実行している場合は、**MySQL 8.4.x** をインストールするか、8.4.x にアップグレードしてください。マネージドサービスを使用している場合は、プロバイダーがサポート対象かつパッチ適用済みとして明記しているエンジンバージョンを実行してください (例: Amazon RDS for MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL) 。W\&B は、MySQL 8.4.0 および現行の 8.4.x リリースでプラットフォームの動作を検証済みです。
以下の手順は、W\&B 側から見た作業の流れを示したものです。バックアップやバージョンの移行パスなど、MySQL 自体のアップグレード方法については、ご使用の MySQL ディストリビューションまたはクラウドプロバイダーのドキュメントに従ってください。この手順は、[標準](/ja/products/wandb/platform/hosting/self-managed/operator)と[エアギャップ](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped)のどちらの Operator デプロイメントにも共通です。エアギャップ環境では、データベースをアップグレードする前に、社内の配布プロセスを通じて MySQL 8.4.x ソフトウェアを入手してください。
作業を開始する前に、メンテナンス期間を計画し、ユーザーに通知してください。互換性やデプロイメントのトポロジについてご質問がある場合は、[Customer Support](mailto:forge-support@coreweave.com) または W\&B の担当チームにお問い合わせください。
1. 移行先のバージョンと、その間にあるすべてのバージョンについて MySQL のリリースノートとドキュメントを確認し、要件などの詳細を把握します。
2. メンテナンスの準備をします。
アップグレードを開始する前に、データベースに対して [MySQL Shell upgrade checker](https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html) を実行すると、移行先バージョンとの互換性の問題を洗い出して修正できます。次に進む前に、チェッカーの出力に含まれるエラーや警告をすべて解決してください。詳しくは、ご使用の MySQL ディストリビューションのドキュメントを参照してください。
3. ご使用の MySQL ディストリビューションのドキュメントに従って MySQL をシャットダウンし、MySQL データベースのフルバックアップを取得します。
アップグレード中は MySQL を利用できません。その間、W\&B クライアントアプリケーションは接続できず、一時的なエラーが発生します。
4. ご使用の MySQL ディストリビューションのドキュメントに従って、MySQL を 8.4.x にアップグレードします。
5. MySQL を再起動し、正常に動作していることを確認します。
6. MySQL が起動したら、`wandb verify` を実行して W\&B デプロイメントを検証します。このコマンドは一連のチェックを実行し、結果を `STDOUT` に出力します。問題が報告された場合は、必要な修正を行ってから再度実行してください。セットアップとログインの手順については、[インストールを確認する](#verify-the-installation)を参照してください。
7. 検証が完了すると、ユーザーは通常どおり作業を再開できます。
アップグレード時の ClickHouse 互換性
外部の ClickHouse クラスターを使用するセルフマネージドのデプロイでは、W\&B Server をアップグレードする前に ClickHouse との互換性を確認する必要があります。
サポートされる ClickHouse バージョン
W\&B Weave を使用するには、ClickHouse Server と ClickHouse Keeper の両方がサポート対象のバージョンである必要があります。
* Weave は ClickHouse 25.8 から 25.12 まで、および 26.3 以降をサポートします。
* Weave は ClickHouse 26.1 および 26.2 では動作しません。
**W\&B セルフマネージドをアップグレードする *前に***、ClickHouse Server と ClickHouse Keeper の両方が、Weave がサポートするバージョンで動作していることを確認してください。ClickHouse のバージョンを変更する必要がある場合は、両方のコンポーネントをあわせてアップグレードしてください。
W\&B セルフマネージドのデプロイメントで Weave を使用していない場合、ClickHouse は必須ではないため、この要件はアップグレードには適用されません。
専用クラウドおよび Multi-tenant Cloud のデプロイメントでは、互換性のある ClickHouse バージョンがすでに実行されているため、影響はありません。
バージョンごとのリリースノートについては、[サポートされる W\&B Server リリース](/ja/release-notes/server-releases)を参照してください。
セルフマネージドのインスタンスを W\&B Operator に移行する
このセクションでは、W\&B Server のインストールを自身で管理する運用から、W\&B Operator に管理を任せる運用へ移行する方法について説明します。移行すると、オペレーターがリコンサイルと W\&B Server のアップグレードを自動的に行うため、アプリケーションのマニフェスト変更や Helm のアップグレードを自分で調整する必要がなくなります。移行手順は、W\&B Server のインストール方法によって異なります。
W\&B Operator は、W\&B Server のデフォルトかつ推奨のインストール方法です。ご不明な点がある場合は、[Customer Support](mailto:forge-support@coreweave.com) または W\&B の担当チームにお問い合わせください。
* 公式の W\&B Cloud Terraform モジュールを使用した場合は、該当するドキュメントにアクセスし、その手順に従ってください。
* [AWS](#migrate-to-operator-based-aws-terraform-modules)
* [Google Cloud](#migrate-to-operator-based-google-cloud-terraform-modules)
* [Azure](#migrate-to-operator-based-azure-terraform-modules)
* [W\&B Non-Operator Helm チャート](https://github.com/wandb/helm-charts/tree/main/charts/wandb)を使用した場合は、[オペレーターベースの Helm チャートに移行する](#migrate-to-operator-based-helm-chart)を参照してください。
* [W\&B Non-Operator Helm チャートを Terraform で](https://registry.terraform.io/modules/wandb/wandb/kubernetes/latest)使用した場合は、[オペレーターベースの Terraform Helm チャートに移行する](#migrate-to-operator-based-terraform-helm-chart)を参照してください。
* マニフェストを使用して Kubernetes リソースを作成した場合は、[オペレーターベースの Helm チャートに移行する](#migrate-to-operator-based-helm-chart)を参照してください。
移行プロセスの詳細については、[operator-wandb チャートのドキュメント](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)を参照してください。
ご不明な点がある場合やサポートが必要な場合は、[Customer Support](mailto:forge-support@coreweave.com) または W\&B の担当チームにお問い合わせください。
ご不明な点がある場合やサポートが必要な場合は、[Customer Support](mailto:forge-support@coreweave.com) または担当の W\&B チームまでお問い合わせください。
オペレーターベースの Helm チャートへの移行
オペレーターベースの Helm チャートに移行するには、次の手順に従います。
1. 現在の W\&B の設定を取得します。オペレーターベースではないバージョンの Helm チャートで W\&B をデプロイした場合は、次のように値をエクスポートします。
```shell theme={"system"}
helm get values wandb
```
Kubernetes マニフェストで W\&B をデプロイした場合は、次のように値をエクスポートします。
```shell theme={"system"}
kubectl get deployment wandb -o yaml
```
これで、次のステップに必要な設定値がすべて揃いました。
2. `operator.yaml` という名前のファイルを作成します。[設定リファレンス](#configuration-reference-for-wb-operator)に記載されている形式に従い、ステップ 1 で取得した値を使用します。
3. 現在のデプロイメントの Pod 数を 0 にスケールします。これにより、現在のデプロイメントが停止します。
```shell theme={"system"}
kubectl scale --replicas=0 deployment wandb
```
4. Helm チャートのリポジトリを更新します。
```shell theme={"system"}
helm repo update
```
5. 新しい Helm チャートをインストールします。
```shell theme={"system"}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
6. 新しい Helm チャートを設定し、W\&B アプリケーションのデプロイメントをトリガーします。次のコマンドで新しい設定を適用します。
```shell theme={"system"}
kubectl apply -f operator.yaml
```
デプロイメントが完了するまで数分かかります。
7. インストールを確認します。[インストールを確認する](#verify-the-installation)の手順に従って、すべてが正常に動作していることを確認してください。
8. 古いインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストで作成したリソースを削除します。
オペレーターベースの Helm チャートに移行するには、次の手順に従います。
1. Terraform の設定を準備します。Terraform の設定に含まれる旧デプロイメントの Terraform コードを、[Helm Terraform モジュールで W\&B をデプロイする](#deploy-wb-with-helm-terraform-module) で説明しているコードに置き換えます。変数は以前と同じ値を設定してください。`.tfvars` ファイルがある場合は、変更しないでください。
2. Terraform を実行します。`terraform init`、`terraform plan`、`terraform apply` を実行します。
3. インストールを確認します。[インストールを確認する](#verify-the-installation) の手順に従って、すべてが正常に動作することを確認します。
4. 旧インストールを削除します。旧 Helm チャートをアンインストールするか、マニフェストで作成したリソースを削除します。
W\&B Server の設定リファレンス
このセクションでは、`WeightsAndBiases` カスタムリソースで指定する設定オプションについて説明します。`operator.yaml` ファイルを作成または更新する際に、特定のサブシステム (MySQL、Redis、イングレス、OIDC など) の YAML スキーマを確認するためのリファレンスとしてご利用ください。
このセクションでは、W\&B Server アプリケーションの設定オプションについて説明します。アプリケーションの設定は、[WeightsAndBiases](#how-it-works) という名前のカスタムリソース定義を通じて渡されます。一部の設定オプションは、以下の設定で指定できます。それ以外のオプションは、環境変数として設定する必要があります。
環境変数の一覧は、[基本](/ja/products/wandb/platform/hosting/env-vars)と[高度](/ja/products/wandb/platform/hosting/iam/advanced_env_vars)の 2 つのドキュメントに分かれています。環境変数は、必要な設定オプションを Helm チャートで指定できない場合にのみ使用してください。
基本的な例
この例では、W\&B に必要な最小限の値を定義します。より実践的な本番環境向けの例については、[完全な設定例](#complete-example)を参照してください。
この YAML ファイルでは、バージョン、環境変数、データベースなどの外部リソース、その他の必要な設定を含め、W\&B デプロイメントのあるべき状態を定義します。
```yaml theme={"system"}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
labels:
app.kubernetes.io/name: weightsandbiases
app.kubernetes.io/instance: wandb
name: wandb
namespace: default
spec:
values:
global:
host: https://
license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
bucket:
mysql:
ingress:
annotations:
```
設定可能な値の一覧は [W\&B Helm repository](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml) で確認できます。**上書きが必要な値のみを変更してください**。
完全な設定例
この設定例では、Google Cloud Storage を使用して W\&B を Google Cloud Anthos にデプロイします。
```yaml theme={"system"}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
labels:
app.kubernetes.io/name: weightsandbiases
app.kubernetes.io/instance: wandb
name: wandb
namespace: default
spec:
values:
global:
host: https://abc-wandb.sandbox-gcp.wandb.ml
bucket:
name: abc-wandb-moving-pipefish
provider: gcs
mysql:
database: wandb_local
host: 10.218.0.2
name: wandb_local
password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
port: 3306
user: wandb
redis:
host: redis.example.com
port: 6379
password: password
api:
enabled: true
glue:
enabled: true
executor:
enabled: true
license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
ingress:
annotations:
ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
kubernetes.io/ingress.class: gce
kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address
```
ホスト
```yaml theme={"system"}
# プロトコルを含めた FQDN を指定します
global:
# ホスト名の例です。実際のホスト名に置き換えてください
host: https://wandb.example.com
```
オブジェクトストレージ (バケット)
**AWS**
```yaml theme={"system"}
global:
bucket:
provider: "s3"
name: ""
kmsKey: ""
region: ""
```
**Google Cloud**
```yaml theme={"system"}
global:
bucket:
provider: "gcs"
name: ""
```
**Azure**
```yaml theme={"system"}
global:
bucket:
provider: "az"
name: ""
secretKey: ""
```
**その他のプロバイダー (Minio、Ceph、その他の S3互換ストレージ) **
その他の S3互換プロバイダーを使用する場合は、バケットを次のように設定します。
```yaml theme={"system"}
global:
bucket:
# 以下は例です。実際の値に置き換えてください
provider: s3
name: storage.example.com
kmsKey: null
path: wandb
region: default
accessKey: 5WOA500...P5DK7I
secretKey: HDKYe4Q...JAp1YyjysnX
```
AWS 以外でホストされている S3互換ストレージの場合、`kmsKey` は `null` にする必要があります。
`accessKey` と `secretKey` をシークレットから参照するには、次のように設定します。
```yaml theme={"system"}
global:
bucket:
# 以下は例です。実際の値に置き換えてください
provider: s3
name: storage.example.com
kmsKey: null
path: wandb
region: default
secret:
secretName: bucket-secret
accessKeyName: ACCESS_KEY
secretKeyName: SECRET_KEY
```
MySQL
```yaml theme={"system"}
global:
mysql:
# 例示用の値です。実際の値に置き換えてください
host: db.example.com
port: 3306
database: wandb_local
user: wandb
password: 8wtX6cJH...ZcUarK4zZGjpV
```
シークレットの `password` を参照するには、次のようにします。
```yaml theme={"system"}
global:
mysql:
# 例示用の値です。実際の値に置き換えてください
host: db.example.com
port: 3306
database: wandb_local
user: wandb
passwordSecret:
name: database-secret
passwordKey: MYSQL_WANDB_PASSWORD
```
License
```yaml theme={"system"}
global:
# ライセンスの例です。実際のライセンスに置き換えてください
license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
```
シークレットから `license` を参照するには、次のようにします。
```yaml theme={"system"}
global:
licenseSecret:
name: license-secret
key: CUSTOMER_WANDB_LICENSE
```
Ingress
[Kubernetes の Ingress クラスを特定する方法](#how-to-identify-the-kubernetes-ingress-class)を参照してください。
**TLS なし**
```yaml theme={"system"}
global:
# 重要: YAML では、Ingress は 'global' と同じ階層に記述します（'global' の子要素ではありません）
ingress:
class: ""
```
**TLS を使用する場合**
証明書を含むシークレットを作成します
```console theme={"system"}
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
```
イングレスの設定でシークレットを参照します
```yaml theme={"system"}
global:
# 重要: YAML 内で ingress は 'global' の子要素ではなく、'global' と同じ階層に記述します
ingress:
class: ""
annotations:
{}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
tls:
- secretName: wandb-ingress-tls
hosts:
-
```
Nginx では、次のアノテーションの追加が必要になることがあります。
```yaml theme={"system"}
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 0
```
カスタム Kubernetes サービスアカウント
W\&B の Pod の実行に使用するカスタム Kubernetes サービスアカウントを指定します。
次のスニペットでは、デプロイメントの一部として、指定した名前のサービスアカウントを作成します。
```yaml theme={"system"}
app:
serviceAccount:
name: custom-service-account
create: true
parquet:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
サブシステム "app" と "parquet" は、指定したサービスアカウントで実行されます。それ以外のサブシステムは、デフォルトのサービスアカウントで実行されます。
サービスアカウントがすでにクラスター上に存在する場合は、`create: false` を設定します。
```yaml theme={"system"}
app:
serviceAccount:
name: custom-service-account
create: false
parquet:
serviceAccount:
name: custom-service-account
create: false
global:
...
```
サービスアカウントは、app、parquet、console など、さまざまなサブシステムに指定できます。
```yaml theme={"system"}
app:
serviceAccount:
name: custom-service-account
create: true
console:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
サービスアカウントは、サブシステムごとに異なるものを使用できます：
```yaml theme={"system"}
app:
serviceAccount:
name: custom-service-account
create: false
console:
serviceAccount:
name: another-custom-service-account
create: true
global:
...
```
外部 Redis
```yaml theme={"system"}
redis:
install: false
global:
redis:
host: ""
port: 6379
password: ""
parameters: {}
caCert: ""
```
シークレットから `password` を参照するには、次のようにします。
```console theme={"system"}
kubectl create secret generic redis-secret --from-literal=redis-password=supersecret
```
次の設定で参照します。
```yaml theme={"system"}
redis:
install: false
global:
redis:
host: redis.example
port: 9001
auth:
enabled: true
secret: redis-secret
key: redis-password
```
LDAP
現在の Helm チャートでは、LDAP 設定のサポートは限定的です。LDAP の設定でお困りの場合は、W\&B サポートまたは担当の AISE にお問い合わせください。
LDAP を設定するには、`global.extraEnv` に環境変数を指定します。
```yaml theme={"system"}
global:
extraEnv:
LDAP_ADDRESS: ldaps://ldap.company.example.com
LDAP_BASE_DN: cn=accounts,dc=company,dc=example,dc=com
LDAP_USER_BASE_DN: cn=users,cn=accounts,dc=company,dc=example,dc=com
LDAP_GROUP_BASE_DN: cn=groups,cn=accounts,dc=company,dc=example,dc=com
LDAP_BIND_DN: uid=ldapbind,cn=sysaccounts,cn=etc,dc=company,dc=example,dc=com
LDAP_BIND_PW: ********************
LDAP_ATTRIBUTES: email=mail,name=cn
LDAP_TLS_ENABLE: "true"
LDAP_LOGIN: "true"
LDAP_USER_OBJECT_CLASS: user
LDAP_GROUP_OBJECT_CLASS: group
```
この従来の方法は現在推奨されていません。このセクションは参考情報として記載しています。
**TLS を使用しない場合**
```yaml theme={"system"}
global:
ldap:
enabled: true
# "ldap://" または "ldaps://" を含む LDAP サーバーアドレス
host:
# ユーザーの検索に使用する LDAP 検索ベース
baseDN:
# バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
bindDN:
# バインドに使用する LDAP パスワードを含むシークレット名とキー（匿名バインドを使用しない場合）
bindPW:
# メールアドレスおよびグループ ID の LDAP 属性名（カンマ区切りの string 値）
attributes:
# LDAP グループの許可リスト
groupAllowList:
# LDAP TLS を有効にする
tls: false
```
**TLS を使用する場合**
LDAP TLS 証明書を設定するには、証明書の内容を含む ConfigMap をあらかじめ作成しておく必要があります。
ConfigMap を作成するには、次のコマンドを使用します。
```console theme={"system"}
kubectl create configmap ldap-tls-cert --from-file=certificate.crt
```
作成した ConfigMap を、次の例のように YAML で指定します。
```yaml theme={"system"}
global:
ldap:
enabled: true
# "ldap://" または "ldaps://" を含む LDAP サーバーアドレス
host:
# ユーザーの検索に使用する LDAP 検索ベース
baseDN:
# バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
bindDN:
# バインドに使用する LDAP パスワードを含むシークレット名とキー（匿名バインドを使用しない場合）
bindPW:
# メールアドレスおよびグループ ID の LDAP 属性名（カンマ区切りの string 値）
attributes:
# LDAP グループの許可リスト
groupAllowList:
# LDAP TLS を有効にする
tls: true
# LDAP サーバーの CA 証明書を含む ConfigMap 名とキー
tlsCert:
configMap:
name: "ldap-tls-cert"
key: "certificate.crt"
```
OIDC SSO
```yaml theme={"system"}
global:
auth:
sessionLengthHours: 720
oidc:
clientId: ""
secret: ""
# アイデンティティプロバイダで必要な場合にのみ指定します。
authMethod: ""
issuer: ""
```
`authMethod` は省略可能です。
SMTP
```yaml theme={"system"}
global:
email:
smtp:
host: ""
port: 587
user: ""
password: ""
```
環境変数
```yaml theme={"system"}
global:
extraEnv:
GLOBAL_ENV: "example"
```
レート制限を設定する
オペレーターを使用する専用クラウドおよびセルフマネージドのデプロイでは、必要に応じて `spec.values.global.extraEnv` に環境変数を設定し、レート制限を構成できます。参考までに、この例では各レート制限を明示的にデフォルト値に設定しています。実際の運用では、デフォルト値を上書きする場合にのみレート制限を定義してください。
レート制限を有効にするには、`GORILLA_LIMITER` に Redis サーバーのアドレスを設定する必要があります。
```yaml theme={"system"}
spec:
values:
global:
extraEnv:
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM: "5"
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_COUNT: "5"
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_PER_RUN_COUNT: "0.8"
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_SIZE: "10"
GORILLA_DEFAULT_RATE_LIMITS_RUN_UPDATE_COUNT: "10"
GORILLA_LIMITER: "redis://$HOST:6379?ttlInSeconds=900"
```
詳細については、次の表を参照してください。
| 環境変数 | デフォルト | 説明 |
| - | - | - |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM` | `5` | デフォルトの filestream リクエスト数。 |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_COUNT` | `5` | 1 秒あたりの filestream リクエスト数。 |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_PER_RUN_COUNT` | `0.8` | run ごとの 1 秒あたりの filestream リクエスト数。 |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_SIZE` | `10` | 1 秒あたりの filestream 取り込み量の制限 (MB)。 |
| `GORILLA_DEFAULT_RATE_LIMITS_RUN_UPDATE_COUNT` | `10` | 1 秒あたりの run メタデータ更新リクエスト数。 |
カスタム認証局
`customCACerts` はリスト形式で、複数の証明書を指定できます。`customCACerts` で指定した認証局は、W\&B Server アプリケーションにのみ適用されます。
```yaml theme={"system"}
global:
customCACerts:
- |
-----BEGIN CERTIFICATE-----
MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
-----END CERTIFICATE-----
```
CA 証明書は ConfigMap に保存することもできます：
```yaml theme={"system"}
global:
caCertsConfigMap: custom-ca-certs
```
ConfigMap は次のような形式にする必要があります。
```yaml theme={"system"}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
ConfigMap を使用する場合、ConfigMap 内の各キーの末尾は `.crt` にする必要があります (例: `my-cert.crt`、`ca-cert1.crt`) 。`update-ca-certificates` が各証明書を解析してシステムの CA ストアに追加するには、この命名規則に従う必要があります。
カスタムセキュリティコンテキスト
各 W\&B コンポーネントでは、次の形式のカスタムセキュリティコンテキスト設定がサポートされています。
```yaml theme={"system"}
pod:
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 0
fsGroup: 1001
fsGroupChangePolicy: Always
seccompProfile:
type: RuntimeDefault
container:
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
```
`runAsGroup:` に指定できる値は `0` のみです。それ以外の値を指定するとエラーになります。
たとえば、アプリケーションの Pod を設定するには、次のように設定に `app` セクションを追加します。
```yaml theme={"system"}
global:
...
app:
pod:
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 0
fsGroup: 1001
fsGroupChangePolicy: Always
seccompProfile:
type: RuntimeDefault
container:
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
```
`console`、`weave`、`weave-trace`、`parquet` にも同じ考え方が当てはまります。
W\&B Operator の設定リファレンス
このセクションでは、W\&B Kubernetes Operator (`wandb-controller-manager`) の設定オプションについて説明します。オペレーターは、YAML ファイル形式で設定を受け取ります。
W\&B Kubernetes Operator は、デフォルトでは設定ファイルを必要としません。必要に応じて設定ファイルを作成してください。たとえば、カスタム認証局を指定する場合や、エアギャップ環境にデプロイする場合などには、設定ファイルが必要になることがあります。
spec でカスタマイズできる項目の一覧は、[Helm リポジトリ](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml)で確認できます。
カスタム CA
カスタム認証局 (`customCACerts`) はリスト形式で、複数の証明書を指定できます。追加した認証局は、W\&B Kubernetes Operator (`wandb-controller-manager`) にのみ適用されます。
```yaml theme={"system"}
customCACerts:
- |
-----BEGIN CERTIFICATE-----
MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
-----END CERTIFICATE-----
```
CA 証明書は ConfigMap に保存することもできます。
```yaml theme={"system"}
caCertsConfigMap: custom-ca-certs
```
ConfigMap は次の形式にする必要があります。
```yaml theme={"system"}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
ConfigMap 内の各キーは、末尾を `.crt` にする必要があります (例: `my-cert.crt`、`ca-cert1.crt`) 。`update-ca-certificates` が各証明書を解析してシステムの CA ストアに追加するには、この命名規則に従うことが必須です。
よくある質問
各 Pod の目的と役割
W\&B Server のデプロイメントには、次の Pod が含まれます。
* **`wandb-app`**: GraphQL API とフロントエンドアプリケーションを含む、W\&B の中核となる Pod です。W\&B プラットフォームの機能の大部分を担います。
* **`wandb-console`**: 管理コンソールです。`/console` からアクセスします。
* **`wandb-otel`**: OpenTelemetry エージェントです。Kubernetes レイヤーのリソースからメトリクスとログを収集し、管理コンソールに表示します。
* **`wandb-prometheus`**: Prometheus サーバーです。さまざまなコンポーネントからメトリクスを取得し、管理コンソールに表示します。
* **`wandb-parquet`**: `wandb-app` Pod とは別のバックエンドマイクロサービスで、データベースのデータを Parquet 形式でオブジェクトストレージにエクスポートします。
* **`wandb-weave`**: もう 1 つのバックエンドマイクロサービスで、UI でのクエリ表の読み込みを行うほか、アプリのさまざまな中核機能をサポートします。
* **`wandb-weave-trace`**: LLM ベースのアプリケーションのトラッキング、実験、評価、デプロイ、改善を行うためのフレームワークです。このフレームワークには `wandb-app` Pod 経由でアクセスします。
W\&B Operator Console のパスワードを取得する方法
[W\&B 管理コンソールにアクセスする](#access-the-wb-management-console)を参照してください。
Ingress が機能しない場合に W\&B Operator Console にアクセスする方法
Kubernetes クラスターにアクセスできるホストで、次のコマンドを実行します。
```console theme={"system"}
kubectl port-forward svc/wandb-console 8082
```
ブラウザーで `https://localhost:8082/` にアクセスして、コンソールを開きます。
パスワードの取得方法 (オプション 2) については、[W\&B 管理コンソールにアクセスする](#access-the-wb-management-console)を参照してください。
W\&B Server のログを確認する方法
アプリケーション Pod の名前は **wandb-app-xxx** です。
```console theme={"system"}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
Kubernetes の Ingress クラスを確認する方法
クラスターにインストールされている Ingress クラスは、次のコマンドを実行すると確認できます。
```console theme={"system"}
kubectl get ingressclass
```