Kubernetes Operator を使用して W&B をデプロイする

概要

このページでは、W&B Kubernetes Operator を使用して Kubernetes (クラウドまたはオンプレミス) 上に W&B Server をデプロイおよび管理する方法を、プラットフォーム管理者向けに説明します。これにより、Operator によって管理され、自動的にアップグレードされる稼働中の W&B Server を構築できます。W&B のデプロイをセルフマネージドで運用しており、クラウド、オンプレミス、エアギャップ環境のいずれでも使用できるインストール方法が必要な場合は、このガイドを使用してください。 W&B Kubernetes Operator は、Kubernetes (クラウドまたはオンプレミス) 上に W&B Server をデプロイするための推奨方法です。Operator の概要、W&B がこれを使用する理由、設定階層の仕組みについては、セルフマネージドを参照してください。

開始前に

Kubernetes Operator を使用して W&B をデプロイする前に、インフラストラクチャーがすべての要件を満たしていることを確認してください。

インフラストラクチャー要件を確認する: 次の項目の詳細については、セルフマネージドのインフラストラクチャー要件ページを参照してください。

ソフトウェアのバージョン要件 (Kubernetes、MySQL、Redis、Helm、ClickHouse)
- ハードウェア要件 (CPU アーキテクチャー、推奨サイジング)
- Kubernetes クラスターの設定
- ネットワーク、SSL/TLS、DNS の要件

W&B Server のライセンスを取得する: 要件ページの License セクションを参照してください。
外部サービスをプロビジョニングする: デプロイ前に、MySQL、Redis、オブジェクトストレージを設定してください。

詳細については、リファレンスアーキテクチャページを参照してください。

MySQL データベース

W&B では、外部の MySQL データベースが必要です。本番環境では、W&B はマネージドデータベースサービスの利用を推奨しています。

マネージドデータベースサービスには、自動バックアップ、監視、高可用性、パッチ適用の機能があり、運用負荷を軽減できます。 MySQL の要件 (推奨サイジングや設定パラメーターを含む) については、リファレンスアーキテクチャを参照してください。データベースを作成するための SQL については、ベアメタルガイドを参照してください。デプロイ環境のデータベース設定に関するご質問は、サポートまたは担当の AISE までお問い合わせください。設定パラメーターやデータベースの作成を含む、MySQL の完全なセットアップ手順については、要件ページの MySQL セクションを参照してください。 MySQL 8.0.x からアップグレードする場合は、MySQL を 8.4.x にアップグレードを参照してください。

Redis

W&B は単一ノードの Redis 7.x デプロイに依存しており、W&B の components はこれをジョブキューイングとデータのキャッシュに使用します。テストや概念実証の用途では、W&B Self-Managed にローカル Redis デプロイが含まれています。このバンドル版のデプロイは、本番環境での使用には適していません。本番デプロイでは、W&B は次の環境にある Redis instance に接続できます。

Amazon ElastiCache
Google Cloud Memorystore
Azure Cache for Redis
クラウドまたはオンプレミスのインフラストラクチャーでセルフホストする Redis

Helm values で外部 Redis インスタンスを設定する方法について詳しくは、外部 Redis 設定セクションを参照してください。

オブジェクトストレージ

W&B では、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。 W&B は、次のストレージプロバイダを推奨しています。

Amazon S3: スケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。
Google Cloud Storage: 非構造化データを大規模に保存するためのマネージドサービスです。
Azure Blob Storage: 非構造化データを大規模に保存するためのクラウドベースのオブジェクトストレージです。
CoreWeave AI Object Storage: AI ワークロード向けに最適化された S3互換オブジェクトストレージです。
MinIO Enterprise (AIStor)、NetApp StorageGRID、その他のエンタープライズソリューションなどのエンタープライズ S3互換ストレージ。

MinIO Open Source は現在メンテナンスモードであり、アクティブな開発は行われておらず、事前コンパイル済みバイナリも提供されていません。本番環境へのデプロイでは、W&B は、マネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ S3互換ソリューションを推奨しています。

プロバイダを選択したら、W&B がアクセスできるようにバケットを設定してください。IAM ポリシー、CORS 設定、アクセス設定を含むバケットの詳細なプロビジョニング手順については、Bring Your Own Bucket (BYOB) ガイドを参照してください。容量やパフォーマンスに関するガイダンスを含む、オブジェクトストレージ要件の完全な一覧については、リファレンスアーキテクチャのオブジェクトストレージセクションを参照してください。

ストレージバケットをプロビジョニングする

W&B を設定する前に、必須の IAM ポリシー、CORS 設定、アクセス認証情報を用意して、オブジェクトストレージバケットをプロビジョニングしてください。以下についての詳細な step ごとのプロビジョニング手順は、Bring Your Own Bucket (BYOB) ガイドを参照してください。

Amazon S3 (IAM ポリシーとバケットポリシーを含む)
Google Cloud Storage (PubSub 通知を含む)
Azure Blob Storage (マネージド ID を含む)
CoreWeave AI Object Storage
S3 互換ストレージ (MinIO Enterprise、NetApp StorageGRID、その他のエンタープライズソリューション)

Helm values でオブジェクトストレージを設定する方法の詳細については、オブジェクトストレージの設定セクションを参照してください。

OpenShift Kubernetes clusters

W&B は、クラウド、オンプレミス、およびエアギャップ環境の OpenShift Kubernetes clusters 上でのデプロイをサポートしています。

W&B では、公式の W&B Helm チャートを使用したインストールを推奨しています。

コンテナーを非特権ユーザーとして実行する

OpenShift や同様のオーケストレーターでは、root として実行されるコンテナーが拒否されることが多いため、W&B コンテナーは、root グループに属したまま、root 以外のユーザーとして実行されるように設定する必要があります。デフォルトでは、コンテナーは $UID に 999 を使用します。オーケストレーターでコンテナーを root 以外のユーザーとして実行する必要がある場合は、$UID を >= 100000、$GID を 0 に指定してください。

ファイルシステムの権限を正しく機能させるため、W&B は root グループ ($GID=0) で起動する必要があります。

各 W&B コンポーネントのセキュリティコンテキストを設定します。たとえば、API コンポーネントを設定するには次のようにします。

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 などの他のコンポーネントにもカスタムセキュリティコンテキストを設定できます。詳細は、カスタムセキュリティコンテキストを参照してください。

W&B Server アプリケーションをデプロイ

Helm を使用する W&B Kubernetes Operator は、クラウド、オンプレミス、エアギャップ環境を含むすべての W&B セルフマネージドデプロイで推奨されるインストール方法です

デプロイ方法を選択してください：

Helm CLI
Terraform

W&B は、W&B Kubernetes Operator を Kubernetes クラスターにデプロイするための Helm チャートを提供しています。この方法を使うと、Helm CLI や ArgoCD などの継続的デリバリーツールで W&B Server をデプロイできます。デプロイ固有の考慮事項については、環境固有の考慮事項とパブリッククラウドで Terraform を使用してデプロイするを参照してください。切断された環境については、Air-Gapped Kubernetes にデプロイするを参照してください。Helm CLI で W&B Kubernetes Operator をインストールするには、次の step に従います。

W&B Helm repository を追加します。W&B Helm チャートは W&B Helm repository で利用できます。
helm repo add wandb https://charts.wandb.ai helm repo update

Kubernetes クラスターに Operator をインストールします。

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

W&B Operator の Custom Resource を設定して、W&B Server のインストールをトリガーします。W&B のデプロイ設定を含む operator.yaml という名前のファイルを作成します。使用可能なすべてのオプションについては、設定リファレンスを参照してください。最小構成の例を次に示します。

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://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

カスタム設定で Operator を起動し、W&B Server application をインストール、設定、管理できるようにします。
kubectl apply -f operator.yaml
デプロイが完了するまで待ちます。これには数分かかります。
Web UI を使用してインストールを確認するには、最初の管理者ユーザーアカウントを作成してから、インストールを確認するに記載された確認手順に従ってください。

これらの手順が完了すると、wandb-cr namespace で実行される W&B Kubernetes Operator と、operator.yaml の Custom Resource から operator が管理する W&B Server application が用意されます。

Terraform を使用して、Infrastructure as Code による W&B のデプロイを行います。次のいずれかを選択してください。

Helm Terraform Module: 既存の Kubernetes インフラストラクチャーに operator をデプロイします。
Cloud Terraform Modules: AWS、Google Cloud、Azure 向けに、インフラストラクチャーに加えてアプリケーションも含めた完全なデプロイを行います。

デプロイ固有の考慮事項については、環境ごとの考慮事項とパブリッククラウドで Terraform を使用してデプロイするを参照してください。切り離された環境については、Air-Gapped Kubernetes へのデプロイを参照してください。

Helm Terraform Module

この method は、Terraform の Infrastructure as Code アプローチを使用して一貫性と再現性を確保しながら、特定の要件に合わせてカスタマイズしたデプロイをサポートします。公式の W&B Helm ベースの Terraform Module は Terraform Registry で利用できます。次のコードを出発点として使用してください。これには、本番グレードのデプロイに必要な設定オプションがすべて含まれています。

module "wandb" {
  source  = "wandb/wandb/helm"

  spec = {
    values = {
      global = {
        host    = "https://<HOST_URI>"
        license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"

        bucket = {
          <details depend on the provider>
        }

        mysql = {
          <redacted>
        }
      }

      ingress = {
        annotations = {
          "a" = "b"
          "x" = "y"
        }
      }
    }
  }
}

設定オプションは Configuration Reference に記載されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは W&B の Custom Resource Definition (CRD) を作成します。W&B が Helm Terraform モジュールを使用して顧客向けの専用クラウド環境をデプロイしている方法を確認するには、以下のリンクを参照してください。

クラウド Terraform モジュール

W&B は、AWS、Google Cloud、Azure 向けの Terraform モジュール一式を提供しています。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースを含む完全なインフラストラクチャーに加えて、W&B Server アプリケーションもデプロイします。W&B Kubernetes Operator は、以下のバージョンでこれらの公式 W&B クラウド向け Terraform モジュールに含まれています。

Terraform Registry	ソースコード	バージョン
AWS	https://github.com/wandb/terraform-aws-wandb	v4.0.0+
Azure	https://github.com/wandb/terraform-azurerm-wandb	v2.0.0+
Google Cloud	https://github.com/wandb/terraform-google-wandb	v2.0.0+

これらのモジュールは、デプロイの一部として W&B Kubernetes Operator をインストールするため、追加のセットアップなしでクラウド環境の W&B Server の管理に使用できます。これらのクラウド向けモジュールの詳しい使用方法については、Deploy with Terraform on public cloud を参照してください。

インストールを確認する

インストールを確認するには、W&B では W&B CLI の使用を推奨しています。wandb verify コマンドは、コンポーネントと設定が想定どおりに動作することを確認するテストを実行します。

この手順では、最初の管理者ユーザーアカウントをブラウザで作成することを前提としています。

インストールを確認するには:

W&B CLI をインストールします:
pip install wandb

W&B にログインします:

wandb login --host=https://YOUR_DNS_DOMAIN

例えば:

wandb login --host=https://wandb.company-name.com

インストールを確認する:
wandb verify

コマンドの実行後、インストールが成功すると、次の出力が表示されます:

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 server を有効にする

W&B MCP Server は、operator-wandb のオプションのサブチャートとして提供されています。有効にすると、operator は既存の ingress を通じて <global.host>/mcp で公開されるクラスター内の MCP server をデプロイするため、MCP 対応クライアントであれば W&B APIキーを使用して接続できます。これは、W&B が https://mcp.withwandb.com/mcp で hosted 版として提供しているものと同じ server ですが、接続先はお使いの deployment のデータになります。エンドユーザー向けのクライアント設定と tool カタログについては、W&B MCP server を使用するを参照してください。このセクションでは、operator 側での有効化のみを説明します。

前提条件

MCP server を有効にする前に、デプロイメントが次の要件を満たしていることを確認してください。

チャートバージョン: operator-wandb 0.42.3 以降。mcp-server サブチャートは 0.42.1 で導入されましたが、次の例で使用する Datadog フィールドと privacy フィールドはその後に追加されました。
Weave Traces が有効: MCP server は、トレース用ツールと WF_TRACE_SERVER_URL のデフォルト値のために Weave Traces に依存します。weave-trace.install: true を設定してください。Weave Traces が有効になっていない場合、Helm のレンダリングは mcp-server requires weave-trace.install=true というエラーで失敗します。
アクセス可能な ingress: global.host は、すでに名前解決されて W&B ingress にルーティングされている必要があります。MCP pod は global.host から WANDB_BASE_URL を読み取り、<global.host>/mcp で利用できます。
ノード容量: MCP pod はデフォルトで 500m CPU と 1Gi メモリを要求します (制限は 2 CPU と 4Gi メモリ) 。サブチャートを有効にする前に、ノードプールに十分な空き容量があることを確認してください。

サブチャートを有効にする

mcp-server サブチャートを有効にすると、operator がクラスター内に MCP server をデプロイし、既存の W&B ingress に /mcp ルートを追加します。既存の WeightsAndBiases カスタムリソース (CR) の spec.values ブロックに、すでに設定している global、ingress、その他のオーバーライドとあわせて、以下を追加します。Datadog ブロックは任意ですが、クラスター内で Datadog Agent DaemonSet がすでに pod のログとトレースを収集している場合は、追加することを推奨します。

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-<environment>"
        env: "<environment>"
        deploymentType: "self-managed"
        customer: "<customer-name>"
        extraTags:
          - "region:<region>"
          - "tier:<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 を空文字列に設定します。
privacy.logLevel: ほとんどのセルフマネージド Kubernetes 環境では "standard" を使用します。これは、運用担当者がデバッグで一般的に使用するデプロイ識別子は保持したまま、ログ内の自由記述のパラメーター値をマスクします。entity、project、run、またはユーザー識別子を平文ログに残したくない場合は、"strict" を使用します。これらの値を明示的に平文でログに記録したい場合にのみ、"off" を使用します。

変更を適用してリコンシリエーションをトリガーします。

kubectl apply -f operator.yaml

operator は、release namespace に wandb-mcp-server の deployment と service を作成し、W&B ingress に /mcp パスを追加します。

MCP server を確認する

pod が Running になるまで待ってから、クラスター内および ingress 経由でヘルスエンドポイントを確認します。

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://<HOST_URI>/mcp/health"

どちらのリクエストでも 200 OK が返るはずです。クラスター内チェックでは、pod が正常であることを確認します。ingress チェックでは、ルーティングを確認します。クラスター内チェックで 200 OK が返っても、ingress チェックで 404 Not Found が返る場合は、Troubleshootingを参照してください。Datadog を有効にしている場合は、設定した mcp-server.datadog.service および mcp-server.datadog.env の値で、MCP server のログも Datadog に表示されるはずです。

クライアントを接続する

MCP server が正常に稼働したら、Bearer token に W&B APIキーを指定して https://<HOST_URI>/mcp を使用するよう、MCP クライアントを設定してください。IDE およびエージェントの設定については、W&B MCP server を使用するを参照してください。

トラブルシューティング

症状	原因と対処方法
`helm render` が `mcp-server requires weave-trace.install=true` で失敗する	`spec.values` に `weave-trace.install: true` を追加してください。MCP server はトレースツールのために Weave Traces に依存しています。
`wandb-mcp-server` pod が `Pending` のままで、`Insufficient cpu` または `Insufficient memory` が表示される	ノードの容量を増やすか、CR の `mcp-server.resources.requests` を引き下げてください。デフォルトは `500m` CPU と `1Gi` メモリです。
`curl https://<HOST_URI>/mcp/health` が 404 を返す	chart は、`mcp-server.install: true` の場合にのみ `/mcp` の ingress path をレンダリングします。CR を再適用し、ingress controller に新しい path が反映されるまで待ってください。
MCP のログが Datadog に表示されない	`mcp-server.datadog.enabled: true`、`mcp-server.datadog.mode: "agent"`、および Datadog Agent DaemonSet が pod の stdout を収集していることを確認してください。設定した `service` と `env` の値で Datadog を検索してください。
MCP のログに、想定より多くのユーザー入力テキストが含まれる	`mcp-server.privacy.logLevel` を `"standard"` または `"strict"` に設定してください。entity、project、run、またはユーザー名などの識別子を平文ログに残したくない場合は、`"strict"` を使用してください。
エアギャップ環境またはミラーリングされたクラスターで `wandb-mcp-server` pod が `ImagePullBackOff` になる	イメージを使用中の Registry にミラーリングし、CR で `mcp-server.image.repository` をオーバーライドしてください。これは、エアギャップ環境でのインストール時に他の W&B コンポーネントイメージで使用するのと同じパターンです。詳細は Deploy on Air-Gapped Kubernetes を参照してください。

環境固有の考慮事項

Kubernetes 自体は、オンプレミスでもクラウドでも変わりません。主な違いは、名称やマネージドサービス (たとえば、MySQL と RDS、または S3 とオンプレミスのオブジェクトストレージ) にあります。このセクションでは、環境によって異なる考慮事項について説明します。

オンプレミスおよびベアメタル

オンプレミスまたはベアメタルの Kubernetes にデプロイする場合は、以下の点に注意してください。

ロードバランサーの設定

オンプレミスの Kubernetes クラスターでは、通常、ロードバランサーを手動で設定する必要があります。主な選択肢は次のとおりです。

外部ロードバランサー: F5 や HAProxy など、既存のハードウェアまたはソフトウェアのロードバランサーを設定します。
Nginx Ingress Controller: NodePort またはホストネットワークを使用して nginx-ingress-controller をデプロイします。
MetalLB: ベアメタルの Kubernetes クラスターでは、MetalLB を使用してロードバランサーサービスを提供できます。

ロードバランサー設定の詳しい例については、リファレンスアーキテクチャのネットワークセクションを参照してください。

永続ストレージ

Kubernetes クラスターで、永続ボリューム用の StorageClass が設定されていることを確認してください。W&B コンポーネントでは、キャッシュや一時データの保存に永続ストレージが必要になる場合があります。一般的なオンプレミス向けストレージオプションには、次のものがあります:

NFS ベースのストレージクラス
Ceph/Rook ストレージ
ローカル永続ボリューム
NetApp や Pure Storage などのエンタープライズ向けストレージソリューション

DNS と証明書の管理

オンプレミス環境にデプロイする場合は、次のタスクを完了してください:

内部 DNS レコードを設定して、W&B のホスト名を指すようにします。
社内の認証局 (CA) から SSL/TLS 証明書を発行します。
自己署名証明書を使用する場合は、operator が CA 証明書を信頼するように設定します。

証明書の設定の詳細については、SSL/TLS 要件を参照してください。

OpenShift デプロイ

W&B は、OpenShift Kubernetes clusters へのデプロイを全面的にサポートしています。OpenShift ではセキュリティポリシーがより厳格なため、デプロイ時に追加のセキュリティコンテキスト設定が必要です。 OpenShift 固有の設定の詳細については、OpenShift Kubernetes clusters を参照してください。エアギャップ環境での OpenShift の例については、エアギャップ Kubernetes へのデプロイを参照してください。

オンプレミスおよび S3 互換向けのオブジェクトストレージ

オブジェクトストレージのバケットをプロビジョニングしたら、W&B カスタムリソースで設定します (オブジェクトストレージのプロビジョニングを参照) 。 AWS S3 (オンプレミス) オンプレミスの AWS S3 (Outposts または互換ストレージ経由) の場合：

bucket:
  kmsKey: <kms key arn>  # 暗号化用のオプションの KMS キー
  name: <bucket name>    # 例: wandb
  path: ""               # 空文字列のままにしてください
  provider: s3
  region: <region>       # 例: us-east-1

MinIO、Ceph、NetApp などの S3互換ストレージ S3互換のストレージシステムでは:

bucket:
  kmsKey: null
  name: <s3 endpoint>    # 例: s3.example.com:9000
  path: <bucket name>    # 例: wandb
  provider: s3
  region: <region>       # 例: us-east-1

S3互換ストレージでTLSを有効にするには、バケットパスに ?tls=true を追加します。

bucket:
  path: "wandb?tls=true"

証明書は信頼済みである必要があります。自己署名証明書を使用する場合は、追加の設定が必要です。詳しくは、SSL/TLS 要件を参照してください。

オンプレミスのオブジェクトストレージに関する重要な考慮事項 独自のオブジェクトストレージを運用する場合は、次の点を考慮してください。

ストレージ容量とパフォーマンス: ディスク容量を注意深く監視してください。W&B の平均的な使用量では、数十 GB から数百 GB 程度になります。利用量が多い場合は、ペタバイト級のストレージ消費量になることがあります。
耐障害性: 最低でも、物理ディスクには RAID アレイを使用してください。S3 互換ストレージには、分散構成または高可用構成を使用してください。
可用性: ストレージを利用可能な状態に保つための監視を設定してください。

MinIO に関する重要事項

MinIO Open Source は、現在メンテナンスモードで、アクティブな開発は行われていません。事前コンパイル済みバイナリの提供は終了しており、重大なセキュリティ修正のみが個別に検討されます。本番デプロイでは、W&B はマネージドオブジェクトストレージサービスまたは MinIO Enterprise (AIStor) の使用を推奨します。

オンプレミスのオブジェクトストレージ向けの Enterprise の代替製品には、次のものがあります。

既存の MinIO デプロイまたは MinIO Enterprise を使用している場合は、MinIO クライアントを使用して bucket を作成できます。

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

Terraform によるパブリッククラウド

AWS、Google Cloud、または Azure でインフラストラクチャーからアプリケーションまで含めて完全にデプロイするには、パブリッククラウドへの Terraform によるデプロイを参照してください。

パブリッククラウドで Terraform を使用してデプロイする

W&B では、W&B Multi-tenant Cloud や W&B Dedicated Cloud などの完全マネージドのデプロイオプションを推奨しています。完全マネージドサービスでは、設定はほとんど、またはまったく不要です。

W&B は、パブリッククラウドプロバイダー上にプラットフォームをデプロイするための Terraform モジュールを提供しています。これらのモジュールは、インフラストラクチャーのプロビジョニングと W&B Server のインストールを自動化するため、各クラウドリソースを手動で作成しなくても完全な環境を構築できます。開始する前に、State File を保存するために、Terraform で使用可能な remote backends のいずれかを選択することを W&B では推奨しています。State File は、すべてのコンポーネントを再作成することなく、アップグレードを適用したりデプロイに変更を加えたりするために必要なリソースです。クラウドプロバイダーを選択してください:

AWS
Google Cloud
Azure

AWS 上にプラットフォームをデプロイするには、W&B Server AWS Terraform Module の使用を W&B では推奨しています。Terraform Moduleは、以下の必須コンポーネントをデプロイします：

ロードバランサー
AWS Identity & Access Management (IAM)
AWS Key Management System (KMS)
Amazon Aurora MySQL
Amazon VPC
Amazon S3
Amazon Route 53
Amazon Certificate Manager (ACM)
Amazon Elastic Load Balancing (ALB)
Amazon Secrets Manager

オプションのコンポーネントには以下が含まれます：

Elastic Cache for Redis
SQS

前提条件の権限

Terraformを実行するアカウントには、前のセクションに記載されたすべてのコンポーネントを作成する権限に加え、IAMポリシーおよびIAMロールを作成してリソースにロールを割り当てる権限が必要です。

General steps

このセクションの手順は、どのデプロイオプションにも共通です。

開発環境を準備します。
- Terraform をインストールする
- W&B では、バージョン管理のために Git リポジトリを作成することを推奨しています。
terraform.tfvars ファイルを作成します。 tvfars ファイルの内容は、インストールタイプに応じてカスタマイズしてください。最低限の推奨内容は、以下の例のとおりです。
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"
Terraform が作成するすべてのリソース名のプレフィックスとなる文字列が namespace 変数であるため、デプロイ前に tvfars ファイルで変数を定義してください。 subdomain と domain を組み合わせると、W&B インスタンスの FQDN が構成されます。前述の例では、W&B の FQDN は wandb-aws.wandb.ml であり、DNS の zone_id は Terraform が FQDN レコードを作成する DNS ゾーンです。 allowed_inbound_cidr と allowed_inbound_ipv6_cidr は、どちらも設定する必要があります。モジュールでは、これは必須入力です。次の例では、任意のソースから W&B インストールへのアクセスを許可します。
versions.tf ファイルを作成します。このファイルには、AWS に W&B をデプロイするために必要な Terraform および Terraform プロバイダのバージョンが記載されています:
provider "aws" { region = "eu-central-1" default_tags { tags = { GithubRepo = "terraform-aws-wandb" GithubOrg = "wandb" Enviroment = "Example" Example = "PublicDnsExternal" } } }
AWS プロバイダーの設定については、Terraform 公式ドキュメントを参照してください。 W&B では、このドキュメントの冒頭で説明したリモートバックエンドの設定も追加することを推奨しています。

variables.tf ファイルを作成する terraform.tfvars で設定した各オプションには、Terraform で対応する変数宣言が必要です。

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
}

推奨デプロイ

これは、すべての必須コンポーネントを作成し、Kubernetes クラスターに W&B の最新バージョンをインストールする、最もシンプルなデプロイオプションの設定です。

main.tf を作成する General のステップでファイルを作成したのと同じディレクトリに、次の内容で main.tf ファイルを作成します。

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
 }

W&B をデプロイする W&B をデプロイするには、以下のコマンドを実行します。
terraform init terraform apply -var-file=terraform.tfvars

Redisを有効にする

Redisを使用してSQLクエリをキャッシュし、メトリクス読み込み時のアプリケーションのレスポンスを高速化するには、main.tfファイルにcreate_elasticache_subnet = trueオプションを追加します。

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 には組み込みのブローカーが含まれているため、これは省略可能です。このオプションを使用しても、パフォーマンスは向上しません。

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

[...]
}

追加リソース

Google Cloud 上にプラットフォームをデプロイするには、W&B Server Google Cloud Terraform Module の使用を W&B は推奨します。モジュールのドキュメントには、利用可能なすべてのオプションが記載されています。開始する前に、Terraform の State File を保存するため、利用可能なリモートバックエンドのいずれかを選択することを W&B では推奨しています。State File は、すべてのコンポーネントを再作成せずにデプロイのアップグレードや変更を適用するために必要なリソースです。Terraform Moduleは、以下の必須コンポーネントをデプロイします：

VPC
Cloud SQL for MySQL
Cloud Storage バケット
Google Kubernetes Engine
Memorystore for Redis
KMS 暗号鍵
ロードバランサー

オプションのコンポーネントには以下が含まれます：

Pub/Sub メッセージングシステム

前提条件の権限

Terraformを実行するアカウントには、使用するGoogle Cloudプロジェクトに対してroles/ownerロールが必要です。

General steps

このセクションの手順は、どのデプロイオプションにも共通です。

開発環境を準備します。
- Terraform をインストールします。
- W&B では、コード用の Git リポジトリを作成することを推奨していますが、ファイルをローカルに置いたままでも構いません。
- Google Cloud Console でプロジェクトを作成します。
- Google Cloud で認証するには、gcloud auth application-default login を使用します (事前に gcloud をインストールしてください) 。
terraform.tfvars ファイルを作成します。インストールタイプに応じて tvfars ファイルの内容をカスタマイズしてください。最低限の推奨内容は以下の例のようになります。
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 です。

variables.tf ファイルを作成する terraform.tfvars で設定した各オプションには、Terraform で対応する変数宣言が必要です。

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"
}

推奨デプロイ

main.tf を作成する General のステップでファイルを作成したのと同じディレクトリに、次の内容で main.tf ファイルを作成します。

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
}

W&B をデプロイします。 W&B をデプロイするには、以下のコマンドを実行します。
terraform init terraform apply -var-file=terraform.tfvars

Redisを有効にする

Redisを使用してSQLクエリをキャッシュし、メトリクス読み込み時のアプリケーションのレスポンスを高速化するには、main.tfファイルにcreate_redis = trueオプションを追加します。

[...]

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 には組み込みのブローカーが含まれているため、これは省略可能です。このオプションを使用しても、パフォーマンスは向上しません。

[...]

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
}

[...]

追加リソース

Azure 上にプラットフォームをデプロイするには、W&B Server Azure Terraform Module の使用を W&B は推奨しています。モジュールのドキュメントには、利用可能なすべてのオプションが記載されています。Terraform Moduleは、以下の必須コンポーネントをデプロイします：

Azure リソースグループ
Azure Virtual Network (VPC)
Azure MySQL Flexible Server
Azure Storage アカウントと Blob Storage
Azure Kubernetes Service
Azure Application Gateway

オプションのコンポーネントには以下が含まれます：

Azure Cache for Redis
Azure Event Grid

前提条件の権限

AzureRM プロバイダーを設定する最もシンプルな方法は Azure CLI を使用することです。オートメーションの場合は、Azure Service Principal を使用することもできます。使用する認証方法に関わらず、Terraformを実行するアカウントには、前のセクションに記載されたすべてのコンポーネントを作成する権限が必要です。

General steps

このセクションの手順は、どのデプロイオプションにも共通です。

開発環境を準備します。
- Terraform をインストールします
- W&B では、コード用の Git リポジトリを作成することを推奨していますが、ファイルはローカルに保存したままでも構いません。
terraform.tfvars ファイルを作成します。インストールタイプに応じて tvfars file の内容をカスタマイズしてください。最低限の推奨構成は以下の例のようになります。
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 です。
versions.tf ファイルを作成するこのファイルには、Azure で W&B をデプロイするために必要な Terraform 本体および Terraform プロバイダのバージョンが記載されています:
terraform { required_version = "~> 1.3" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.17" } } }
Azure プロバイダーの設定については、Terraform Official Documentationを参照してください。 W&B では、このドキュメントの冒頭で説明したリモートバックエンドの設定も追加することを推奨しています。

variables.tf ファイルを作成する terraform.tfvars で設定した各オプションには、Terraform で対応する変数宣言が必要です。

    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"
    }

推奨デプロイ

main.tf を作成する General のステップでファイルを作成したのと同じディレクトリに、次の内容で main.tf ファイルを作成します。

  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
  }

W&Bをデプロイする W&B をデプロイするには、以下のコマンドを実行します。
terraform init terraform apply -var-file=terraform.tfvars

Redisを有効にする

# 必要なサービスをすべて起動する
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 には組み込みのブローカーが含まれているため、これは省略可能です。このオプションを使用しても、パフォーマンスは向上しません。

# 必要なサービスをすべて起動する
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
  [...]
}

追加リソース

その他のデプロイオプション

すべての設定を同じファイルに追加することで、複数のデプロイオプションを組み合わせることができます。各 Terraform モジュールには、標準オプションや、推奨デプロイのセクションにある最小限の設定と組み合わせて使えるオプションがいくつか用意されています。利用可能なオプションの一覧については、ご利用のクラウドプロバイダ向けのモジュールドキュメントを参照してください。

W&B Management Console にアクセスする

W&B Kubernetes operator には管理コンソールが付属しており、デプロイメントのステータスの確認、コンポーネントのメトリクスの表示、operator レベルの Settings の調整を行えます。URL は ${HOST_URI}/console です。たとえば https://wandb.company-name.com/console です。管理コンソールにログインする方法は 2 つあります。

オプション 1（推奨）
オプション 2

ブラウザで W&B App を開き、ログインします。${HOST_URI}/ (たとえば https://wandb.company-name.com/) から W&B App にログインします。
コンソールにアクセスします。画面右上のアイコンをクリックし、System console をクリックします。System console のエントリが表示されるのは、管理者権限を持つUsersのみです。

W&B では、オプション 1 が機能しない場合にのみ、以下の手順でコンソールにアクセスすることを推奨しています。

ブラウザでコンソールアプリケーションを開きます。前のセクションで説明した URL を開くと、ログイン画面にリダイレクトされます。
インストール時に生成される Kubernetes secret からパスワードを取得します。
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
パスワードをコピーします。
コンソールにログインします。コピーしたパスワードを貼り付け、Login をクリックします。

W&B Kubernetes Operator を更新する

このセクションでは、W&B Kubernetes Operator 自体を更新する方法を説明します。バグ修正や新しいリコンサイル機能を利用できるよう、定期的に operator を更新してください。

W&B Kubernetes Operator を更新しても、W&B Server アプリケーションは更新されません。
W&B Kubernetes Operator を使用しない Helm チャートを使用している場合は、W&B Operator を更新するためにこのセクションの手順を実行する前に、移行手順を参照してください。

以下のコードスニペットをターミナルにコピー＆ペーストしてください。

helm repo update でリポジトリを更新します。
helm repo update

helm upgrade で Helm チャートを更新します。

helm upgrade operator wandb/operator -n wandb-cr --reuse-values

W&B Server アプリケーションを更新する

W&B Kubernetes Operator を使用している場合、W&B Server アプリケーションを更新する必要はありません。 W&B ソフトウェアの新しいバージョンがリリースされると、Operator が W&B Server アプリケーションを自動的に更新します。

MySQL を 8.4.x にアップグレードする

MySQL 8.0.x はサポート終了です。セルフマネージドのデプロイでは、セキュリティパッチと重大なバグ修正を受けられる、サポート対象の MySQL バージョンを実行する必要があります。community MySQL を実行している場合は、MySQL 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 ディストリビューションまたはクラウドプロバイダーのドキュメントに従ってください。同じ手順は、standard と air-gapped の Operator デプロイに適用されます。air-gapped 環境では、データベースをアップグレードする前に、社内の配布プロセスを通じて MySQL 8.4.x のソフトウェアを入手してください。

開始前にメンテナンスウィンドウを計画し、ユーザーに通知してください。互換性やデプロイのトポロジについて質問がある場合は、Customer Support または担当の W&B チームにお問い合わせください。

対象バージョンと、その間に挟まる各バージョンの要件や詳細について、MySQL のリリースノートとドキュメントを確認します。
メンテナンスの準備をします。アップグレードを開始する前に、データベースに対して MySQL Shell upgrade checker を実行し、対象バージョンとの互換性の問題を洗い出して修正できます。先に進む前に、checker の出力にあるエラーや警告をすべて解消してください。詳細については、お使いの MySQL ディストリビューションのドキュメントを参照してください。
MySQL を停止し、お使いの MySQL ディストリビューションのドキュメントに従って、MySQL データベースの完全バックアップを取得します。アップグレード中は MySQL を利用できません。データベースが利用できない間は、W&B クライアントアプリケーションは接続できず、一時的なエラーが発生します。
お使いの MySQL ディストリビューションのドキュメントに従って、MySQL を 8.4.x にアップグレードします。
MySQL を再起動し、正常に稼働していることを確認します。
MySQL の起動後、wandb verify を実行して W&B デプロイを検証します。このコマンドは一連のチェックを実行し、結果を STDOUT に出力します。問題が報告された場合は、必要な調整を行ってから再度実行してください。セットアップとログインの手順については、インストールを確認するを参照してください。
検証が完了したら、ユーザーは通常の運用を再開できます。

アップグレード時の ClickHouse 互換性

外部 ClickHouse クラスターを使用するセルフマネージドのデプロイでは、W&B Server をアップグレードする前に ClickHouse との互換性を確認する必要があります。

サポート対象外の ClickHouse バージョン

W&B セルフマネージドデプロイで W&B Weave または Models OLAP 機能を使用する場合は、ClickHouse Server と ClickHouse Keeper の両方でサポートされるバージョンが必要です。

Weave は ClickHouse 26.1 および 26.2 では動作しません。
次のセクションで説明する Models OLAP 機能には、ClickHouse 26.2 以降が必要です。
Weave と Models OLAP 機能の両方を使用するデプロイには、ClickHouse 26.3 が必要です。

W&B セルフマネージドデプロイで Weave も Models OLAP 機能も使用しない場合、ClickHouse は不要です。

Models OLAP 機能

W&B Server 0.81.0+ では、ClickHouse 26.2+ が必要なスキーマ移行が導入されています。これらの移行は、Helm values で以下の Models OLAP 機能のいずれかを有効にすると実行されます。

global:
  olap:
    registrySearch:
      enabled: true
    runStoreAccelerator:
      enabled: true
    history:
      enabled: true

W&B セルフマネージドを Server v0.81+ にアップグレードする前に、次のいずれかを実行する必要があります。

Helm values でこれらを false に設定する、または:
ClickHouse Server と ClickHouse Keeper の両方を 26.2 以降にアップグレードする (デプロイで Weave も使用している場合は 26.3 以降) 。

これらの機能が無効になっている場合、または Models の OLAP ワークロードに ClickHouse を使用していない場合は、この要件はアップグレードには適用されません。専用クラウドおよび Multi-tenant Cloud のデプロイは、すでに互換性のある ClickHouse バージョンで実行されているため、影響を受けません。バージョン固有のリリースノートについては、サポートされる W&B Server リリースを参照してください。

セルフマネージドインスタンスから W&B Operator へ移行する

このセクションでは、W&B Server を自分で管理する構成から、W&B Operator による管理へ移行する方法を説明します。移行すると、operator がリコンシリエーションと W&B Server のアップグレードを自動的に処理するため、アプリケーションの manifest の変更や Helm のアップグレードを調整する必要がなくなります。移行プロセスは、W&B Server をどのようにインストールしたかによって異なります。

W&B Operator は、W&B Server のデフォルトかつ推奨のインストール方法です。ご不明な点がある場合は、Customer Support または担当の W&B チームにお問い合わせください。

公式の W&B Cloud Terraform Modules を使用した場合は、該当するドキュメントにアクセスし、記載されている手順に従ってください。
- AWS
- Google Cloud
- Azure
W&B Non-Operator Helm チャートを使用した場合は、こちらに進んでください。
Terraform を使用した W&B Non-Operator Helm チャートを使用した場合は、こちらに進んでください。
マニフェストを使用して Kubernetes リソースを作成した場合は、こちらに進んでください。

Operator ベースの AWS Terraform Modules への移行

移行手順の詳細については、operator-wandb チャートのドキュメントを参照してください。

Operator ベースの Google Cloud Terraform Modules への移行

ご不明な点やサポートが必要な場合は、Customer Support または担当のW&Bチームまでお問い合わせください。

Operator ベースの Azure Terraform Modules への移行

ご不明な点やサポートが必要な場合は、Customer Support または担当の W&B チームまでお問い合わせください。

Operator ベースの Helm チャートに移行する

Operator ベースの Helm チャートに移行するには、次の step に従います。

現在の W&B 設定を取得します。W&B が Operator ベースではないバージョンの Helm チャートでデプロイされている場合は、次のように values をエクスポートします。
helm get values wandb
W&B が Kubernetes マニフェストでデプロイされている場合は、次のように値をエクスポートします。
kubectl get deployment wandb -o yaml
これで、次の step に必要な設定値がすべてそろいました。
operator.yaml という名前のファイルを作成します。設定リファレンスで説明されている形式に従います。step 1 で取得した値を使用します。
現在のデプロイを 0 pod にスケールします。この step で現在のデプロイを停止します。
kubectl scale --replicas=0 deployment wandb
Helm チャートのリポジトリを更新します。
helm repo update

新しい Helm チャートをインストールします。

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

新しい Helm チャートを設定し、W&B アプリケーションのデプロイをトリガーします。新しい設定を適用します。
kubectl apply -f operator.yaml
デプロイの完了には数分かかります。
インストールを確認する。インストールを確認するの手順に従って、すべてが正しく動作することを確認します。
古いインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストを使用して作成したリソースを削除します。

Operator ベースの Terraform Helm チャートに移行する

次の手順に従って、Operator ベースの Helm チャートに移行します。

Terraform 設定を準備します。Terraform 設定内の古いデプロイの Terraform コードを、Deploy W&B with Helm Terraform module に記載されているコードに置き換えます。変数は以前と同じものを設定します。.tfvars file がある場合は変更しないでください。
Terraform run を実行します。terraform init、terraform plan、terraform apply を実行します。
インストールを確認します。Verify the installation の手順に従って、すべてが正しく動作することを確認します。
古いインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストで作成したリソースを削除します。

W&B Server の設定リファレンス

このセクションは、WeightsAndBiases Custom Resource で設定する設定オプションのリファレンスです。operator.yaml ファイルを作成または更新する際に、特定のサブシステム (たとえば、MySQL、Redis、ingress、OIDC) の YAML スキーマを確認するために使用してください。このセクションでは、W&B Server アプリケーションの設定オプションについて説明します。アプリケーションは、WeightsAndBiases という名前の Custom Resource Definition として設定を受け取ります。一部の設定オプションは以下の設定で公開されていますが、環境変数として設定する必要があるものもあります。このドキュメントには、環境変数の一覧が 2 つあります。basic と advanced です。必要な設定オプションが Helm チャートで公開されていない場合にのみ、環境変数を使用してください。

基本例

この例では、W&B に必要な最小限の値を定義します。より実際の本番環境に近い例については、完全な例を参照してください。この YAML ファイルでは、バージョン、環境変数、データベースなどの外部リソース、そのほか必要な設定を含む、W&B デプロイの望ましい状態を定義します。

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://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

値の一覧全体は W&B Helm repository で確認できます。上書きが必要な値だけを変更してください。

完全な例

この設定例では、Google Cloud Storage を使用して W&B を Google Cloud Anthos にデプロイします。

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

ホスト

 # プロトコルを含むFQDNを指定してください
global:
  # ホスト名の例です。ご自身のものに置き換えてください
  host: https://wandb.example.com

オブジェクトストレージ (バケット)

AWS

global:
  bucket:
    provider: "s3"
    name: ""
    kmsKey: ""
    region: ""

Google Cloud

global:
  bucket:
    provider: "gcs"
    name: ""

Azure

global:
  bucket:
    provider: "az"
    name: ""
    secretKey: ""

その他のプロバイダ (Minio、Ceph、その他のS3互換ストレージ) その他のS3互換プロバイダでは、以下のようにバケットを設定します。

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 を参照するには:

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

global:
   mysql:
     # 値の例です。実際の値に置き換えてください
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     password: 8wtX6cJH...ZcUarK4zZGjpV 

シークレット内のpasswordを参照するには:

global:
   mysql:
     # 値の例です。ご自身の値に置き換えてください
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

ライセンス

global:
  # ライセンスの例。ご自身のものに置き換えてください
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

シークレット内のlicenseを参照するには:

global:
  licenseSecret:
    name: license-secret
    key: CUSTOMER_WANDB_LICENSE

Ingress

Kubernetes ingress class を確認する方法を参照してください。 TLS なし

global:
# 重要: Ingress は YAML 内で 'global' と同じレベルにあります（子要素ではありません）
ingress:
  class: ""

TLS あり 証明書を格納したシークレットを作成します

kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt

Ingress 設定でシークレットを参照する

global:
# 重要: Ingress は YAML 内で 'global' と同じレベルにあります（子要素ではありません）
ingress:
  class: ""
  annotations:
    {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  tls: 
    - secretName: wandb-ingress-tls
      hosts:
        - <HOST_URI>

Nginx の場合、次のアノテーションを追加する必要があることがあります:

ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 0

カスタム Kubernetes サービスアカウント

W&B Pod の実行に使用するカスタム Kubernetes サービスアカウントを指定します。次のスニペットは、指定した名前のサービスアカウントをデプロイの一部として作成します:

app:
  serviceAccount:
    name: custom-service-account
    create: true

parquet:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

サブシステム “app” と “parquet” は、指定したサービスアカウントで実行されます。その他のサブシステムは、デフォルトのサービスアカウントで実行されます。サービスアカウントがクラスター上にすでに存在する場合は、create: false を設定します。

app:
  serviceAccount:
    name: custom-service-account
    create: false

parquet:
  serviceAccount:
    name: custom-service-account
    create: false
    
global:
  ...

app、parquet、console などの各サブシステムに対して、サービスアカウントを指定できます。

app:
  serviceAccount:
    name: custom-service-account
    create: true

console:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

サブシステムごとに、サービスアカウントが異なる場合があります:

app:
  serviceAccount:
    name: custom-service-account
    create: false

console:
  serviceAccount:
    name: another-custom-service-account
    create: true

global:
  ...

外部 Redis

redis:
  install: false

global:
  redis:
    host: ""
    port: 6379
    password: ""
    parameters: {}
    caCert: ""

シークレット内のpasswordを参照するには:

kubectl create secret generic redis-secret --from-literal=redis-password=supersecret

以下の設定で参照してください。

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 で環境変数を設定します:

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

OIDC SSO

global: 
  auth:
    sessionLengthHours: 720
    oidc:
      clientId: ""
      secret: ""
      # IdPが必要とする場合のみ含めてください。
      authMethod: ""
      issuer: ""

authMethod は省略可能です。

SMTP

global:
  email:
    smtp:
      host: ""
      port: 587
      user: ""
      password: ""

環境変数

global:
  extraEnv:
    GLOBAL_ENV: "example"

レート制限を設定する

Operator を使用する専用クラウドおよびセルフマネージド環境では、必要に応じて spec.values.global.extraEnv に環境変数を設定し、レート制限を構成できます。参考として、この例では各レート制限を明示的にデフォルト値に設定しています。実際には、デフォルト値を上書きする場合にのみレート制限を定義してください。

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 アプリケーションにのみ適用されます。

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 certificates は、ConfigMap にも保存できます:

global:
  caCertsConfigMap: custom-ca-certs

ConfigMap は次のように記述する必要があります。

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 コンポーネントは、以下の形式のカスタムセキュリティコンテキスト設定をサポートします：

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 セクションを追加します。

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) の設定オプションについて説明します。この Operator は、YAML ファイルの形式で設定を受け取ります。デフォルトでは、W&B Kubernetes Operator に設定ファイルは必要ありません。必要な場合にのみ、設定ファイルを作成してください。たとえば、カスタム認証局を指定する場合や、エアギャップ環境にデプロイする場合などに、設定ファイルが必要になることがあります。 spec のカスタマイズ項目の完全な一覧は、Helm repository を参照してください。

カスタム CA

カスタム証明書認証局 (customCACerts) はリスト形式で、複数の証明書を指定できます。追加したこれらの認証局は、W&B Kubernetes Operator (wandb-controller-manager) にのみ適用されます。

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 certificatesは、ConfigMapに保存することもできます。

caCertsConfigMap: custom-ca-certs

ConfigMap は次のようになっている必要があります:

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 ストアに追加できるようにするために必要な命名規則です。

FAQ

各 pod の目的と役割

W&B Server のデプロイメントには、次の pod が含まれます。

wandb-app: GraphQL API とフロントエンドアプリケーションを含む、W&B の中核です。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 管理コンソールへのアクセスを参照してください。

Ingress が機能しない場合に W&B Operator Console にアクセスする方法

Kubernetes クラスターに接続できるホストで、次のコマンドを実行します。

kubectl port-forward svc/wandb-console 8082

ブラウザで https://localhost:8082/ にアクセスして、コンソールを開きます。パスワードの取得方法 (オプション 2) については、W&B 管理コンソールへのアクセスを参照してください。

W&B Server のログを表示する方法

アプリケーション Pod の名前は wandb-app-xxx です。

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes の ingress クラスを確認する方法

次を実行すると、クラスターにインストールされている ingress クラスを確認できます

kubectl get ingressclass

レート制限

エアギャップ Kubernetes へのデプロイ

⌘I

​概要

​開始前に

​MySQL データベース

​Redis

​オブジェクトストレージ

​ストレージバケットをプロビジョニングする

​OpenShift Kubernetes clusters

​コンテナーを非特権ユーザーとして実行する

​W&B Server アプリケーションをデプロイ

​Helm Terraform Module

​クラウド Terraform モジュール

​インストールを確認する

​MCP server を有効にする

​前提条件

​サブチャートを有効にする

​MCP server を確認する

​クライアントを接続する

​トラブルシューティング

​環境固有の考慮事項

​オンプレミスおよびベアメタル

​ロードバランサーの設定

​永続ストレージ

​DNS と証明書の管理

​OpenShift デプロイ

​オンプレミスおよび S3 互換向けのオブジェクトストレージ

​Terraform によるパブリッククラウド

​パブリッククラウドで Terraform を使用してデプロイする

​前提条件の権限

​General steps

​推奨デプロイ

​Redisを有効にする

​メッセージブローカー (キュー) を有効にする

​追加リソース

​前提条件の権限

​General steps

​推奨デプロイ

​Redisを有効にする

​メッセージブローカー (キュー) を有効にする

​追加リソース

​前提条件の権限

​General steps

​推奨デプロイ

​Redisを有効にする

​メッセージブローカー (キュー) を有効にする

​追加リソース

​その他のデプロイオプション

​W&B Management Console にアクセスする

​W&B Kubernetes Operator を更新する

​W&B Server アプリケーションを更新する

​MySQL を 8.4.x にアップグレードする

​アップグレード時の ClickHouse 互換性

​サポート対象外の ClickHouse バージョン

​Models OLAP 機能

​セルフマネージド インスタンスから W&B Operator へ移行する

​Operator ベースの AWS Terraform Modules への移行

​Operator ベースの Google Cloud Terraform Modules への移行

​Operator ベースの Azure Terraform Modules への移行

​Operator ベースの Helm チャートに移行する

​Operator ベースの Terraform Helm チャート に移行する

​W&B Server の設定リファレンス

​基本例

​完全な例

​ホスト

​オブジェクトストレージ (バケット)

​MySQL

​ライセンス

​Ingress

​カスタム Kubernetes サービスアカウント

​外部 Redis

​LDAP

​OIDC SSO

​SMTP

​環境変数

​レート制限を設定する

​カスタム認証局

​カスタムセキュリティコンテキスト

​W&B Operator の設定リファレンス

​カスタム CA

​FAQ

​各 pod の目的と役割

概要

開始前に

MySQL データベース

Redis

オブジェクトストレージ

ストレージバケットをプロビジョニングする

OpenShift Kubernetes clusters

コンテナーを非特権ユーザーとして実行する

W&B Server アプリケーションをデプロイ

Helm Terraform Module

クラウド Terraform モジュール

インストールを確認する

MCP server を有効にする

前提条件

サブチャートを有効にする

MCP server を確認する

クライアントを接続する

トラブルシューティング

環境固有の考慮事項

オンプレミスおよびベアメタル

ロードバランサーの設定

永続ストレージ

DNS と証明書の管理

OpenShift デプロイ

オンプレミスおよび S3 互換向けのオブジェクトストレージ

Terraform によるパブリッククラウド

パブリッククラウドで Terraform を使用してデプロイする

前提条件の権限

General steps

推奨デプロイ

Redisを有効にする

メッセージブローカー (キュー) を有効にする

追加リソース

前提条件の権限

General steps

推奨デプロイ

Redisを有効にする

メッセージブローカー (キュー) を有効にする

追加リソース

前提条件の権限

General steps

推奨デプロイ

Redisを有効にする

メッセージブローカー (キュー) を有効にする

追加リソース

その他のデプロイオプション

W&B Management Console にアクセスする

W&B Kubernetes Operator を更新する

W&B Server アプリケーションを更新する

MySQL を 8.4.x にアップグレードする

アップグレード時の ClickHouse 互換性

サポート対象外の ClickHouse バージョン

Models OLAP 機能

セルフマネージドインスタンスから W&B Operator へ移行する

Operator ベースの AWS Terraform Modules への移行

Operator ベースの Google Cloud Terraform Modules への移行

Operator ベースの Azure Terraform Modules への移行

Operator ベースの Helm チャートに移行する

Operator ベースの Terraform Helm チャートに移行する

W&B Server の設定リファレンス

基本例

完全な例

ホスト

オブジェクトストレージ (バケット)

MySQL

ライセンス

Ingress

カスタム Kubernetes サービスアカウント

外部 Redis

LDAP

OIDC SSO

SMTP

環境変数

レート制限を設定する

カスタム認証局

カスタムセキュリティコンテキスト

W&B Operator の設定リファレンス

カスタム CA

FAQ

各 pod の目的と役割