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 がオペレーターを採用している理由、設定の階層構造の仕組みについては、セルフマネージドを参照してください。

始める前に

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

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

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

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

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

MySQL データベース

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

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

Redis

W&B は単一ノード構成の Redis 7.x デプロイメントを必要とし、W&B の各コンポーネントはこれをジョブのキュー管理やデータのキャッシュに使用します。テストや概念実証 (PoC) 向けに、W&B Self-Managed にはローカルの Redis デプロイメントが含まれています。このバンドルされたデプロイメントは、本番環境での使用には適していません。本番環境のデプロイメントでは、W&B は次の環境にある Redis インスタンスに接続できます。

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 のオープンソース版はメンテナンスモードに移行しており、現在は開発が行われておらず、コンパイル済みバイナリも提供されていません。本番デプロイメントでは、マネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ向け S3互換ソリューションの使用を推奨します。

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

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

W&B を設定する前に、オブジェクトストレージバケットをプロビジョニングし、必要な IAM ポリシー、CORS 設定、およびアクセス用の認証情報を構成しておく必要があります。以下の各ストレージにおけるプロビジョニングの詳しい手順については、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 クラスター

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

公式の 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 アプリケーションをデプロイする

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

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

Helm CLI
Terraform

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

W&B Helm リポジトリを追加します。W&B Helm チャートは W&B Helm リポジトリで提供されています。
helm repo add wandb https://charts.wandb.ai helm repo update

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

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

W&B オペレーターのカスタムリソースを設定して、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>

カスタム設定でオペレーターを起動します。これにより、オペレーターが W&B Server アプリケーションのインストール、設定、管理を行えるようになります。
kubectl apply -f operator.yaml
デプロイメントが完了するまで待ちます。完了までには数分かかります。
Web UI でインストールを確認するには、最初の管理者ユーザーアカウントを作成してから、インストールを確認するに記載されている検証手順に従います。

これらの手順が完了すると、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 向けに、インフラストラクチャーからアプリケーションまでをまとめてデプロイします。

デプロイメント固有の考慮事項については、環境固有の考慮事項およびパブリッククラウドで Terraform を使用してデプロイするを参照してください。インターネットから切り離された環境については、Deploy on Air-Gapped Kubernetes を参照してください。

Helm Terraform Module

この方法では、Terraform の Infrastructure as Code のアプローチによって一貫性と再現性を確保しつつ、特定の要件に合わせてカスタマイズしたデプロイメントを構築できます。W&B 公式の Helm ベースの Terraform モジュールは 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"
        }
      }
    }
  }
}

設定オプションは設定リファレンスで説明されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは W&B のカスタムリソース定義 (CRD) を作成します。W&B 自身が Helm Terraform モジュールを使用して、お客様向けの専用クラウドのインストールをどのようにデプロイしているかについては、以下のリンクを参照してください。

クラウド向け Terraform モジュール

W&B は、AWS、Google Cloud、Azure 向けの Terraform モジュール群を提供しています。これらのモジュールは、W&B Server アプリケーションとともに、Kubernetes クラスター、ロードバランサー、MySQL データベースを含むインフラストラクチャー一式をデプロイします。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 を Operator で管理できます。これらのクラウド別モジュールの使用方法の詳細については、パブリッククラウドで Terraform を使用してデプロイするを参照してください。

インストールを確認する

インストールを確認するため、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 サーバーを有効にする

W&B MCP Server は、operator-wandb のオプションのサブチャートとして提供されています。有効にすると、オペレーターがクラスター内に MCP サーバーをデプロイし、既存のイングレス経由で <global.host>/mcp に公開します。これにより、MCP 対応クライアントであれば W&B APIキーを使用して接続できます。このサーバーは、W&B が https://mcp.withwandb.com/mcp でホスト型サービスとして運用しているものと同じですが、お使いのデプロイメントのデータを参照するように構成されています。エンドユーザー向けのクライアント設定とツールカタログについては、Use the W&B 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 を読み取り、<global.host>/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 のログとトレースを収集している場合は追加することをお勧めします。

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 タグが不要な場合は、customer を空文字列に設定します。
privacy.logLevel: ほとんどのセルフマネージド Kubernetes 環境では "standard" を使用します。この設定では、オペレーターがデバッグによく使用するデプロイメント識別子は残したまま、ログ内の自由記述のパラメーター値をマスクします。entity、project、run、またはユーザーの識別子を平文のログに残したくない場合は "strict" を使用します。"off" は、これらの値を平文でログすることを明示的に求める場合にのみ使用してください。

変更を適用して、リコンサイルをトリガーします。

kubectl apply -f operator.yaml

オペレーターは、リリースの namespace に wandb-mcp-server のデプロイメントとサービスを作成し、W&B のイングレスに /mcp パスを追加します。

MCP サーバーを確認する

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

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 が正常であることを、イングレスチェックではルーティングが機能していることを確認します。クラスター内チェックでは 200 OK が返されるのに、イングレスチェックで 404 Not Found が返される場合は、トラブルシューティングを参照してください。Datadog を有効にした場合は、MCP サーバーのログが、設定した mcp-server.datadog.service と mcp-server.datadog.env の値とともに Datadog にも表示されるはずです。

クライアントを接続する

MCP サーバーが正常な状態になったら、https://<HOST_URI>/mcp を使用するように MCP クライアントを設定し、W&B APIキーを Bearer token として指定します。IDE やエージェントの設定については、Use the W&B 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://<HOST_URI>/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 を参照してください。

環境固有の考慮事項

Kubernetes は、オンプレミスとクラウドのどちらで実行しても同じように動作します。主な違いは、名称とマネージドサービスにあります (たとえば、MySQL と RDS、S3 とオンプレミスのオブジェクトストレージなど) 。このセクションでは、環境によって異なる考慮事項について説明します。

オンプレミスとベアメタル

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

ロードバランサーの設定

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

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

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

永続ストレージ

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

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

DNS と証明書の管理

オンプレミスのデプロイメントでは、次のタスクを実施します。

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

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

OpenShift デプロイメント

W&B は、OpenShift Kubernetes クラスターへのデプロイを完全にサポートしています。OpenShift はセキュリティポリシーがより厳格なため、OpenShift デプロイメントではセキュリティコンテキストの追加設定が必要です。 OpenShift 固有の設定の詳細については、OpenShift Kubernetes クラスターを参照してください。エアギャップ環境での OpenShift の設定例については、Deploy on Air-Gapped 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 です。使用量が多い場合、ストレージ消費量がペタバイト規模に達することがあります。
フォールトトレランス: 物理ディスクには、少なくとも RAID アレイを使用してください。S3互換ストレージの場合は、分散構成または高可用性構成を使用してください。
可用性: ストレージの可用性を維持できるよう、モニタリングを設定してください。

MinIO に関する考慮事項

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

オンプレミスのオブジェクトストレージには、次のようなエンタープライズ向けの代替製品があります。

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

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 専用クラウドなどの完全マネージドなデプロイメントタイプを推奨しています。完全マネージドサービスでは、設定はほとんど、またはまったく必要ありません。

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

AWS
Google Cloud
Azure

AWS にプラットフォームをデプロイするには、W&B Server AWS Terraform モジュールを使用することを推奨します。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 ロールを作成し、リソースにロールを割り当てる権限が必要です。

一般的な手順

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

開発環境を準備します。
- 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"
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 インストールへのアクセスを許可します。
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 では、terraform.tfvars で設定するすべてのオプションに対して、対応する変数宣言が必要です。

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 クラスターにインストールします。

main.tf を作成します General Steps で作成したファイルと同じディレクトリに、次の内容で 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 モジュールの使用をおすすめします。利用可能なすべてのオプションは、モジュールのドキュメントに記載されています。開始する前に、Terraform で利用できるリモートバックエンドのいずれかを選択し、State File の保存先とすることを 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 ロールが付与されている必要があります。

一般的な手順

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

開発環境を準備します。
- Terraform をインストールします。
- W&B ではコード用の Git リポジトリを作成することを推奨していますが、ファイルをローカルで管理することもできます。
- Google Cloud Console でプロジェクトを作成します。
- gcloud auth application-default login を使用して Google Cloud の認証を行います (事前に 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 では、terraform.tfvars で設定する各オプションに対応する変数宣言が必要です。

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 Steps」で作成したファイルと同じディレクトリに、次の内容で 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 モジュールの使用を推奨します。利用可能なすべてのオプションは、モジュールのドキュメントに記載されています。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 を使用することです。オートメーション用途では、Azure サービスプリンシパルを使用することもできます。どの認証方式を使用する場合でも、Terraform を実行するアカウントには、前のセクションに記載されているすべてのコンポーネントを作成できる権限が必要です。

一般的な手順

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

開発環境を準備します。
- Terraform をインストールします。
- W&B ではコード用の Git リポジトリを作成することを推奨していますが、ファイルをローカルで管理することもできます。
terraform.tfvars ファイルを作成します。インストールのタイプに応じて、tvfars ファイルの内容をカスタマイズします。推奨される最小限の内容は次の例のとおりです。
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 公式ドキュメントを参照してください。 W&B では、このドキュメントの冒頭で説明したリモートバックエンドの設定もあわせて追加することを推奨しています。

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

    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 Steps で作成したファイルと同じディレクトリに、次の内容で 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 を有効にする

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

# 必要なサービスをすべて起動します
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 管理コンソールにアクセスする

W&B Kubernetes Operator には管理コンソールが付属しており、デプロイメントのステータスの確認、コンポーネントのメトリクスの表示、オペレーターレベルの設定の調整を行えます。管理コンソールには ${HOST_URI}/console (例: https://wandb.company-name.com/console) からアクセスできます。管理コンソールには、次の 2 つの方法でログインできます。

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

ブラウザーで W&B アプリケーションを開いてログインします。${HOST_URI}/ (例: https://wandb.company-name.com/) から W&B アプリケーションにログインします。
コンソールにアクセスします。右上隅のアイコンをクリックし、System console をクリックします。System console エントリは、管理者権限を持つユーザーにのみ表示されます。

次の手順でコンソールにアクセスするのは、オプション 1 が機能しない場合のみにすることをお勧めします。

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

W&B Kubernetes Operator を更新する

このセクションでは、W&B Kubernetes 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 ソフトウェアの新しいバージョンがリリースされると、オペレーターが 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 ディストリビューションまたはクラウドプロバイダーのドキュメントに従ってください。この手順は、標準とエアギャップのどちらの Operator デプロイメントにも共通です。エアギャップ環境では、データベースをアップグレードする前に、社内の配布プロセスを通じて MySQL 8.4.x ソフトウェアを入手してください。

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

移行先のバージョンと、その間にあるすべてのバージョンについて MySQL のリリースノートとドキュメントを確認し、要件などの詳細を把握します。
メンテナンスの準備をします。アップグレードを開始する前に、データベースに対して MySQL Shell upgrade 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 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 リリースを参照してください。

セルフマネージドのインスタンスを W&B Operator に移行する

このセクションでは、W&B Server のインストールを自身で管理する運用から、W&B Operator に管理を任せる運用へ移行する方法について説明します。移行すると、オペレーターがリコンサイルと W&B Server のアップグレードを自動的に行うため、アプリケーションのマニフェスト変更や Helm のアップグレードを自分で調整する必要がなくなります。移行手順は、W&B Server のインストール方法によって異なります。

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

公式の W&B Cloud Terraform モジュールを使用した場合は、該当するドキュメントにアクセスし、その手順に従ってください。
- AWS
- Google Cloud
- Azure
W&B Non-Operator Helm チャートを使用した場合は、オペレーターベースの Helm チャートに移行するを参照してください。
W&B Non-Operator Helm チャートを Terraform で使用した場合は、オペレーターベースの Terraform Helm チャートに移行するを参照してください。
マニフェストを使用して Kubernetes リソースを作成した場合は、オペレーターベースの Helm チャートに移行するを参照してください。

オペレーターベースの AWS Terraform モジュールへの移行

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

オペレーターベースの Google Cloud Terraform モジュールへの移行

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

オペレーターベースの Azure Terraform モジュールへの移行

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

オペレーターベースの Helm チャートへの移行

オペレーターベースの Helm チャートに移行するには、次の手順に従います。

現在の W&B の設定を取得します。オペレーターベースではないバージョンの Helm チャートで W&B をデプロイした場合は、次のように値をエクスポートします。
helm get values wandb
Kubernetes マニフェストで W&B をデプロイした場合は、次のように値をエクスポートします。
kubectl get deployment wandb -o yaml
これで、次のステップに必要な設定値がすべて揃いました。
operator.yaml という名前のファイルを作成します。設定リファレンスに記載されている形式に従い、ステップ 1 で取得した値を使用します。
現在のデプロイメントの Pod 数を 0 にスケールします。これにより、現在のデプロイメントが停止します。
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 チャートをアンインストールするか、マニフェストで作成したリソースを削除します。

オペレーターベースの Terraform Helm チャートに移行する

オペレーターベースの Helm チャートに移行するには、次の手順に従います。

Terraform の設定を準備します。Terraform の設定に含まれる旧デプロイメントの Terraform コードを、Helm Terraform モジュールで W&B をデプロイするで説明しているコードに置き換えます。変数は以前と同じ値を設定してください。.tfvars ファイルがある場合は、変更しないでください。
Terraform を実行します。terraform init、terraform plan、terraform apply を実行します。
インストールを確認します。インストールを確認するの手順に従って、すべてが正常に動作することを確認します。
旧インストールを削除します。旧 Helm チャートをアンインストールするか、マニフェストで作成したリソースを削除します。

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

このセクションでは、WeightsAndBiases カスタムリソースで指定する設定オプションについて説明します。operator.yaml ファイルを作成または更新する際に、特定のサブシステム (MySQL、Redis、イングレス、OIDC など) の YAML スキーマを確認するためのリファレンスとしてご利用ください。このセクションでは、W&B Server アプリケーションの設定オプションについて説明します。アプリケーションの設定は、WeightsAndBiases という名前のカスタムリソース定義を通じて渡されます。一部の設定オプションは、以下の設定で指定できます。それ以外のオプションは、環境変数として設定する必要があります。環境変数の一覧は、基本と高度の 2 つのドキュメントに分かれています。環境変数は、必要な設定オプションを 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

License

global:
  # ライセンスの例です。実際のライセンスに置き換えてください
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

シークレットから license を参照するには、次のようにします。

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

Ingress

Kubernetes の Ingress クラスを特定する方法を参照してください。 TLS なし

global:
# 重要: YAML では、Ingress は 'global' と同じ階層に記述します（'global' の子要素ではありません）
ingress:
  class: ""

TLS を使用する場合 証明書を含むシークレットを作成します

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

イングレスの設定でシークレットを参照します

global:
# 重要: YAML 内で ingress は 'global' の子要素ではなく、'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: ""
      # アイデンティティプロバイダで必要な場合にのみ指定します。
      authMethod: ""
      issuer: ""

authMethod は省略可能です。

SMTP

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

環境変数

global:
  extraEnv:
    GLOBAL_ENV: "example"

レート制限を設定する

オペレーターを使用する専用クラウドおよびセルフマネージドのデプロイでは、必要に応じて 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 証明書は 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) の設定オプションについて説明します。オペレーターは、YAML ファイル形式で設定を受け取ります。 W&B Kubernetes Operator は、デフォルトでは設定ファイルを必要としません。必要に応じて設定ファイルを作成してください。たとえば、カスタム認証局を指定する場合や、エアギャップ環境にデプロイする場合などには、設定ファイルが必要になることがあります。 spec でカスタマイズできる項目の一覧は、Helm リポジトリで確認できます。

カスタム 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 証明書は 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 ストアに追加するには、この命名規則に従うことが必須です。

よくある質問

各 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 管理コンソールにアクセスするを参照してください。

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

最終更新日 2026年9月30日

​概要

​始める前に

​MySQL データベース

​Redis

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

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

​OpenShift Kubernetes クラスター

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

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

​Helm Terraform Module

​クラウド向け Terraform モジュール

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

​MCP サーバーを有効にする

​前提条件

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

​MCP サーバーを確認する

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

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

​環境固有の考慮事項

​オンプレミスとベアメタル

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

​永続ストレージ

​DNS と証明書の管理

​OpenShift デプロイメント

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

​Terraform を使用したパブリッククラウド

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

​前提として必要な権限

​一般的な手順

​推奨デプロイメント

​Redis を有効にする

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

​その他のリソース

​前提として必要な権限

​一般的な手順

​推奨デプロイメント

​Redis を有効にする

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

​その他のリソース

​前提として必要な権限

​一般的な手順

​推奨デプロイメント

​Redis を有効にする

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

​その他のリソース

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

​W&B 管理コンソールにアクセスする

​W&B Kubernetes Operator を更新する

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

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

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

​サポートされる ClickHouse バージョン

​セルフマネージドのインスタンスを W&B Operator に移行する

​オペレーターベースの AWS Terraform モジュールへの移行

​オペレーターベースの Google Cloud Terraform モジュールへの移行

​オペレーターベースの Azure Terraform モジュールへの移行

​オペレーターベースの Helm チャートへの移行

​オペレーターベースの Terraform Helm チャートに移行する

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

​基本的な例

​完全な設定例

​ホスト

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

​MySQL

​License

​Ingress

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

​外部 Redis

​LDAP

​OIDC SSO

​SMTP

​環境変数

​レート制限を設定する

​カスタム認証局

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

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

​カスタム CA

​よくある質問

​各 Pod の目的と役割

​W&B Operator Console のパスワードを取得する方法

概要

始める前に

MySQL データベース

Redis

オブジェクトストレージ

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

OpenShift Kubernetes クラスター

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

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

Helm Terraform Module

クラウド向け Terraform モジュール

インストールを確認する

MCP サーバーを有効にする

前提条件

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

MCP サーバーを確認する

クライアントを接続する

トラブルシューティング

環境固有の考慮事項

オンプレミスとベアメタル

ロードバランサーの設定

永続ストレージ

DNS と証明書の管理

OpenShift デプロイメント

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

Terraform を使用したパブリッククラウド

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

前提として必要な権限

一般的な手順

推奨デプロイメント

Redis を有効にする

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

その他のリソース

前提として必要な権限

一般的な手順

推奨デプロイメント

Redis を有効にする

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

その他のリソース

前提として必要な権限

一般的な手順

推奨デプロイメント

Redis を有効にする

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

その他のリソース

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

W&B 管理コンソールにアクセスする

W&B Kubernetes Operator を更新する

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

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

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

サポートされる ClickHouse バージョン

セルフマネージドのインスタンスを W&B Operator に移行する

オペレーターベースの AWS Terraform モジュールへの移行

オペレーターベースの Google Cloud Terraform モジュールへの移行

オペレーターベースの Azure Terraform モジュールへの移行

オペレーターベースの Helm チャートへの移行

オペレーターベースの Terraform Helm チャートに移行する

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

基本的な例

完全な設定例

ホスト

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

MySQL

License

Ingress

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

外部 Redis

LDAP

OIDC SSO

SMTP

環境変数

レート制限を設定する

カスタム認証局

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

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

カスタム CA

よくある質問

各 Pod の目的と役割

W&B Operator Console のパスワードを取得する方法