メインコンテンツへスキップ

​
概要

W&B Kubernetes Operator は、Kubernetes（クラウド環境またはオンプレミス環境）上に W&B Server をデプロイするための推奨される方法です。Operator の概要、W&B がそれを採用している理由、および設定階層の仕組みについては、セルフマネージドを参照してください。

​
始める前に

Kubernetes Operator を使用して W&B をデプロイする前に、インフラストラクチャがすべての要件を満たしていることを確認してください。
  1. インフラストラクチャ要件を確認する: 詳細については、自己管理環境のインフラストラクチャ要件 ページを参照してください。このページでは次の内容を網羅的に説明しています。
  • ソフトウェアのバージョン要件 (Kubernetes、MySQL、Redis、Helm)
    • ハードウェア要件 (CPU アーキテクチャ、サイジングの推奨事項)
    • Kubernetes クラスターの設定
    • ネットワーク、SSL/TLS、および DNS の要件
  1. W&B Server ライセンスを取得する: Requirements ページの License セクションを参照してください。
  2. 外部サービスを用意する: デプロイ前に MySQL、Redis、およびオブジェクトストレージをセットアップしてください。
追加の背景情報については、リファレンスアーキテクチャ ページを参照してください。

​
MySQL データベース

W&B では外部の MySQL データベースが必要です。 本番環境では、W&B はマネージド データベース サービスの使用を強く推奨します。 マネージド データベース サービスは、自動バックアップ、監視、高可用性、パッチ適用などを提供し、運用負荷を軽減します。 MySQL の要件（サイジングの推奨事項や設定パラメータを含む）の詳細については、リファレンス アーキテクチャを参照してください。データベース作成用の SQL については、ベアメタル ガイドを参照してください。デプロイのデータベース設定に関する質問がある場合は、サポート または AISE までお問い合わせください。 設定パラメータやデータベース作成を含む、MySQL の完全なセットアップ手順については、要件ページの MySQL セクションを参照してください。

​
Redis

W&B は、ジョブキューおよびデータキャッシュのために W&B のコンポーネントが使用する、単一ノード構成の Redis 7.x デプロイメントに依存しています。概念実証のテストや開発を容易にするため、W&B Self-Managed にはローカルの Redis デプロイメントが含まれていますが、これは本番環境での利用には適していません。 本番環境でのデプロイメントでは、W&B は次の環境にある Redis インスタンスに接続できます。 Helm values で外部 Redis インスタンスを設定する方法の詳細については、External Redis 設定セクションを参照してください。

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

W&B には、事前署名付き URL および CORS をサポートするオブジェクトストレージが必要です。 推奨ストレージプロバイダ:
  • Amazon S3: 業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービス。
  • Google Cloud Storage: 非構造化データを大規模に保存するためのマネージドサービス。
  • Azure Blob Storage: 大量の非構造化データを保存するためのクラウドベースのオブジェクトストレージソリューション。
  • CoreWeave AI Object Storage: AI ワークロード向けに最適化された、高性能で S3 互換のオブジェクトストレージサービス。
  • エンタープライズ向け S3 互換ストレージ: MinIO Enterprise (AIStor)、NetApp StorageGRID、その他のエンタープライズグレードのソリューション
MinIO Open Source はメンテナンスモードにあり、積極的な開発や事前コンパイル済みバイナリは提供されていません。本番環境へのデプロイには、W&B はマネージド型オブジェクトストレージサービス、または MinIO Enterprise (AIStor) のようなエンタープライズ向け S3 互換ソリューションの利用を推奨します。
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 は、公式の W&B Helm チャートを使用してインストールすることを推奨します。

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

デフォルトでは、コンテナは $UID は 999 を使用します。オーケストレーターがコンテナを root 以外のユーザーで実行することを要求する場合は、$UID を 100000 以上、$GID を 0 に指定します。
ファイルシステムのパーミッションを正しく機能させるため、W&B は root グループ（$GID=0）として起動する必要があります。
各 W&B コンポーネントごとに security context（セキュリティコンテキスト）を設定します。たとえば、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 セルフマネージド デプロイメントに推奨のインストール方法です。
デプロイ方法を選択します：
W&B は、W&B Kubernetes operator を Kubernetes クラスターにデプロイするための Helm チャートを提供します。この方法を使うと、Helm CLI または ArgoCD のような継続的デリバリーツールで W&B Server をデプロイできます。デプロイに特有の考慮事項については、環境固有の考慮事項 と パブリッククラウド上で Terraform を使用してデプロイ を参照してください。エアギャップ（インターネット非接続）環境については、エアギャップされた Kubernetes へのデプロイ を参照してください。Helm CLI を使用して W&B Kubernetes Operator をインストールするには、次の手順に従います。
  1. W&B Helm リポジトリを追加します。W&B Helm チャートは W&B Helm リポジトリで利用できます。 
    helm repo add wandb https://charts.wandb.ai
helm repo update
  2. Kubernetes クラスターに Operator をインストールします。 
    helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
  3. W&B operator のカスタムリソースを設定して、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>
  4. カスタム設定を Operator に適用し、W&B Server アプリケーションをインストール、設定、および管理できるようにします。 
    kubectl apply -f operator.yaml
    デプロイが完了するまで待ちます。数分かかる場合があります。
  5. Web UI を使用してインストールを検証するには、最初の管理者ユーザーアカウントを作成し、インストールの検証 に記載されている検証手順に従ってください。

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

インストールを検証するには、W&B では W&B CLI の使用を推奨します。verify コマンドは、すべてのコンポーネントと設定が正しく動作しているか確認するために、いくつかのテストを実行します。
この手順では、最初の管理者ユーザーアカウントがブラウザーで作成されていることを前提とします。
次の手順に従ってインストールを検証します。
  1. W&B CLI をインストールします。
pip install wandb
  1. W&B にログインします：
wandb login --host=https://YOUR_DNS_DOMAIN
例えば、 
wandb login --host=https://wandb.company-name.com
  1. インストールを確認する：
wandb verify
インストールが正常に完了し、W&B デプロイ環境が問題なく動作している場合は、次のような出力が表示されます。 
選択されたデフォルトホスト:  https://wandb.company-name.com
このテストの詳細ログの保存先: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
ログイン状態を確認中...................................................✅
署名付きURLアップロードを確認中..............................................✅
プロキシ経由で大きなペイロードを送信できるか確認中...................✅
ベースURLへのリクエストを確認中...........................................✅
署名付きURLを使用したリクエストを確認中.................................✅
バケットのCORS設定を確認中...............................✅
wandbパッケージのバージョンが最新か確認中............................✅
ログされたメトリクスの確認、ファイルの保存とダウンロードを確認中..................✅
アーティファクトの保存とダウンロードのワークフローを確認中...........................✅
エラーが発生した場合は W&B サポートまでお問い合わせください。

​
環境ごとの考慮事項

Kubernetes は、オンプレミスで実行されているかクラウドで実行されているかに関係なく同じです。主な違いは、リソースの名称やマネージドサービスの有無です（たとえば MySQL と RDS、あるいは S3 とオンプレミスのオブジェクトストレージの違いなど）。このセクションでは、環境ごとに異なる考慮事項について説明します。

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

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

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

オンプレミスの Kubernetes クラスターでは、通常、ロードバランサーを手動で設定する必要があります。主な選択肢は次のとおりです。
  • 外部ロードバランサー: 既存のハードウェアまたはソフトウェアのロードバランサー (F5、HAProxy など) を設定する
  • Nginx Ingress Controller: NodePort またはホストネットワークを利用して nginx-ingress-controller をデプロイする
  • MetalLB: ベアメタルの Kubernetes クラスター向けに、MetalLB がロードバランサーサービスを提供する
ロードバランサー設定の詳細な例については、Reference Architecture のネットワーキング セクションを参照してください。

​
永続ストレージ

Kubernetes クラスターに PersistentVolume 用の StorageClass が設定されていることを確認してください。W&B コンポーネントは、キャッシュや一時的なデータのために永続ストレージを必要とする場合があります。 オンプレミス環境で一般的なストレージオプション:
  • NFS ベースの StorageClass
  • Ceph/Rook ストレージ
  • ローカル PersistentVolume
  • エンタープライズ向けストレージソリューション（NetApp、Pure Storage など）

​
DNS と証明書の管理

オンプレミス環境でのデプロイの場合:
  • 内部 DNS レコードを、W&B のホスト名を指すように設定する
  • 内部証明書局 (CA) から SSL/TLS 証明書を発行する
  • 自己署名証明書を使用する場合は、オペレーターで CA 証明書を信頼するように設定する
証明書の設定の詳細については、SSL/TLS 要件 を参照してください。

​
OpenShift デプロイ

W&B は、OpenShift Kubernetes クラスターへのデプロイを完全にサポートしています。OpenShift デプロイでは、OpenShift のより厳格なセキュリティポリシーのため、追加のセキュリティコンテキストの設定が必要になります。 OpenShift 固有の設定の詳細については、上記の OpenShift Kubernetes クラスター を参照してください。エアギャップ環境における OpenShift 向けの包括的な例については、Deploy on Air-Gapped Kubernetes を参照してください。

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

オブジェクトストレージのバケットをプロビジョニングしたら（Object storage provisioning を参照）、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
S3 互換ストレージ（MinIO、Ceph、NetApp など） 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 requirements を参照してください。
オンプレミスのオブジェクトストレージに関する重要な考慮事項 独自のオブジェクトストレージを運用する場合、次の点を考慮してください。
  1. ストレージ容量とパフォーマンス: ディスク容量を慎重に監視してください。平均的な W&B の使用量でも、数十〜数百 GB のデータが発生します。集中的な利用では、ストレージ使用量がペタバイト単位になる可能性があります。
  2. 耐障害性: 最低限、物理ディスクには RAID 構成を使用してください。S3 互換ストレージの場合は、分散構成または高可用性構成を使用してください。
  3. 可用性: ストレージが常に利用可能な状態を維持できているか確認するため、監視を設定してください。
MinIO に関する考慮事項
MinIO Open Source は現在メンテナンスモードであり、アクティブな開発は行われていません。事前コンパイル済みバイナリは提供されなくなっており、重大なセキュリティ修正のみがケースバイケースで検討されます。本番環境でのデプロイには、W&B はマネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) の利用を推奨します。
オンプレミスオブジェクトストレージ向けのエンタープライズ向け代替ソリューションには、次のようなものがあります。 既存の 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 Dedicated Cloud などのフルマネージドなデプロイオプションを推奨しています。W&B のフルマネージドサービスは、ほとんど、あるいはまったく設定が不要で、シンプルかつ安全に利用できます。
W&B は、パブリッククラウドプロバイダ上にプラットフォームをデプロイするための Terraform モジュールを提供しています。これらのモジュールは、インフラストラクチャのプロビジョニングと W&B Server のインストールを自動化します。 開始する前に、Terraform の remote backends のいずれかを選択し、State File を保存することを W&B は推奨します。State File は、すべてのコンポーネントを再作成することなく、デプロイメントのアップグレードや変更を行うために必要なリソースです。 クラウドプロバイダを選択してください:
AWS 上にプラットフォームをデプロイするには、W&B Server AWS Terraform Module の使用を W&B では推奨しています。Terraform Moduleは以下の必須コンポーネントをデプロイします。
  • ロードバランサー
  • AWS Identity and Access Management (IAM)
  • AWS Key Management Service (KMS)
  • Amazon Aurora MySQL
  • Amazon VPC
  • Amazon S3
  • Amazon Route 53
  • Amazon Certificate Manager（ACM）
  • Amazon Elastic Load Balancing (ALB)
  • Amazon Secrets Manager
オプションのコンポーネントは以下のとおりです：
  • Redis 用 Elastic Cache
  • SQS

​
前提条件の権限

Terraformを実行するアカウントには、上記のすべてのコンポーネントを作成する権限、およびIAMポリシーとIAMロールを作成してリソースにロールを割り当てる権限が必要です。

​
一般的な手順

このセクションの手順は、すべてのデプロイオプションに共通です。
  1. 開発環境を準備する。
    • Terraform をインストールします
    • W&B では、バージョン管理のために Git リポジトリを作成することを推奨しています。
  2. 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"
    デプロイする前に、tvfars ファイル内で変数を必ず定義してください。namespace 変数は、Terraform によって作成されるすべてのリソース名の先頭に付与される文字列です。 subdomain と domain を組み合わせたものが、W&B を設定する際の FQDN を構成します。上記の例では、W&B の FQDN は wandb-aws.wandb.ml となり、その FQDN レコードを作成する DNS の zone_id を指定します。 allowed_inbound_cidr と allowed_inbound_ipv6_cidr も設定する必要があります。このモジュールでは、これらは必須の入力変数です。次の例では、任意の送信元から W&B インストールへのアクセスを許可しています。
  3. 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 の公式ドキュメント を参照してください。 任意ですが、強く推奨される手順として、ドキュメント冒頭で説明した remote backend 設定 を追加してください。
  4. 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 の最新バージョンをインストールする、最もシンプルなデプロイオプションの設定です。
  1. main.tf を作成します General Steps でファイルを作成したのと同じディレクトリに、次の内容を記述した main.tf ファイルを作成します。 
    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

  allowed_inbound_cidr           = var.allowed_inbound_cidr
  allowed_inbound_ipv6_cidr      = var.allowed_inbound_ipv6_cidr

  public_access                  = true
  external_dns                   = true
  kubernetes_public_access       = true
  kubernetes_public_access_cidrs = ["0.0.0.0/0"]
  eks_cluster_version            = var.eks_cluster_version
}

 data "aws_eks_cluster" "eks_cluster_id" {
   name = module.wandb_infra.cluster_name
 }

 data "aws_eks_cluster_auth" "eks_cluster_auth" {
   name = module.wandb_infra.cluster_name
 }

 provider "kubernetes" {
   host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
   cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
   token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
 }


 provider "helm" {
   kubernetes {
     host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
     cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
     token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
   }
 }

 output "url" {
   value = module.wandb_infra.url
 }

 output "bucket" {
   value = module.wandb_infra.bucket_name
 }
  2. W&B をデプロイする W&B をデプロイするには、次のコマンドを実行してください。 
    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

[...]
}

​
追加リソース

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

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

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

W&B Kubernetes operator には management console が用意されています。${HOST_URI}/console でアクセスできます。例: https://wandb.company-name.com/console management console にログインする方法は 2 通りあります:

​
W&B Kubernetes operator を更新する

このセクションでは、W&B Kubernetes operator を更新する方法について説明します。
  • W&B Kubernetes operator を更新しても、W&B server アプリケーションは更新されません。
  • W&B Kubernetes operator を使用していない Helm チャートを使用している場合は、W&B operator を更新するために以下の手順に進む前に、こちら の手順を参照してください。
以下のコードスニペットをコピーしてターミナルで実行します。
  1. まず、helm repo update でリポジトリを更新します: 
    helm repo update
  2. 次に、helm upgrade で Helm チャートを更新します: 
    helm upgrade operator wandb/operator -n wandb-cr --reuse-values

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

W&B Kubernetes オペレーターを使用している場合、W&B Server アプリケーションを手動で更新する必要はありません。 オペレーターは、W&B の新しいバージョンがリリースされたときに、W&B Server アプリケーションを自動的に更新します。

​
自己管理インスタンスを W&B Operator に移行する

以降のセクションでは、自己管理している W&B Server インスタンスを、W&B Operator を使った管理に移行する方法を説明します。移行プロセスは、W&B Server をどのようにインストールしたかによって異なります。
W&B Operator は、W&B Server に対して推奨されるデフォルトのインストール方法です。質問がある場合は、Customer Support または担当の W&B チームまでお問い合わせください。

​
Operator ベースの AWS 向け Terraform モジュールに移行する

移行プロセスの詳細については、こちらを参照してください。

​
Operator ベースの Google Cloud Terraform モジュールへ移行する

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

​
Operator ベースの Azure Terraform モジュールへの移行

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

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

Operator ベースの Helm チャートに移行するには、次の手順に従います。
  1. 現在の W&B の設定を取得します。W&B が Operator 非対応版の Helm チャートでデプロイされている場合は、次のように値をエクスポートします: 
    helm get values wandb
    W&B が Kubernetes マニフェストを使ってデプロイされている場合は、次のように値をエクスポートします: 
    kubectl get deployment wandb -o yaml
    これで、次のステップに必要なすべての設定値が揃いました。
  2. operator.yaml というファイルを作成します。設定リファレンス で説明されている形式に従い、ステップ 1 で取得した値を使用します。
  3. 現在のデプロイメントを 0 個の Pod にスケールダウンします。このステップで現在のデプロイメントを停止します。 
    kubectl scale --replicas=0 deployment wandb
  4. Helm チャートのリポジトリを更新します: 
    helm repo update
  5. 新しい Helm チャートをインストールします: 
    helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
  6. 新しい Helm チャートを設定し、W&B アプリケーションのデプロイをトリガーします。次のコマンドで新しい設定を適用します。 
    kubectl apply -f operator.yaml
    デプロイメントの完了には数分かかります。
  7. インストールを検証します。インストールの検証 の手順に従って、すべてが正しく動作していることを確認します。
  8. 既存のインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

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

Operator ベースの Helm チャートへ移行するには、次の手順に従います。
  1. Terraform 設定を準備します。Terraform 設定内の旧デプロイメントの Terraform コードを、こちら で説明しているコードに置き換えます。以前と同じ変数を設定します。.tfvars ファイルがある場合は変更しないでください。
  2. Terraform を実行します。terraform init、plan、apply を実行します。
  3. インストールを検証します。Verify the installation の手順に従って、すべてが正しく動作していることを確認します。
  4. 既存のインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

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

このセクションでは、W&B Server アプリケーションの設定オプションについて説明します。アプリケーションは、WeightsAndBiases という名前のカスタムリソース定義として設定を受け取ります。一部の設定オプションは以下の設定で指定でき、その他は環境変数として設定する必要があります。 このドキュメントには、環境変数の一覧が 2 つあります: 基本 と 高度な。必要とする設定オプションが Helm Chart 経由で公開されていない場合にのみ、環境変数を使用してください。

​
基本的な例

この例では、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 リポジトリ で確認できます。上書きが必要な値のみを変更してください。

​
完全な例

以下の設定例は、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

Ingress クラスの特定方法については、FAQ のこちらの項目を参照してください。 TLS なし 
global:
# 重要: IngressはYAML内で'global'と同じレベルにあります（子要素ではありません）
ingress:
  class: ""
TLS を使用する場合 証明書を含む Secret を作成します。 
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
Ingress の設定でこの Secret を参照します 
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 ServiceAccounts

W&B の Pod を実行するために、カスタム Kubernetes ServiceAccount を指定します。 次のスニペットは、指定した名前の ServiceAccount をデプロイメントの一部として作成します。 
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 Support または担当の AISE までお問い合わせください。
global.extraEnv に環境変数を設定して LDAP を設定します: 
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"

​
カスタム認証局

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

​
カスタム CA

カスタム認証局（customCACerts）はリスト型で、複数の証明書を指定できます。これらの認証局は追加しても、W&B Kubernetes オペレーター（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 個別の目的／役割は何ですか？

  • wandb-app: GraphQL API とフロントエンドアプリケーションを含む W&B の中核コンポーネントです。プラットフォームのほとんどの機能を提供します。
  • wandb-console: /console からアクセスする管理コンソールです。
  • wandb-otel: OpenTelemetry エージェントで、Kubernetes レイヤーのリソースからメトリクスとログを収集し、管理コンソールに表示します。
  • wandb-prometheus: Prometheus サーバーで、さまざまなコンポーネントからメトリクスを取得し、管理コンソールに表示します。
  • wandb-parquet: データベース内のデータを Parquet 形式でオブジェクトストレージにエクスポートする、wandb-app pod とは別のバックエンドマイクロサービスです。
  • wandb-weave: UI でクエリテーブルを読み込み、さまざまなコアアプリケーション機能をサポートする別のバックエンドマイクロサービスです。
  • wandb-weave-trace: LLM ベースのアプリケーションのトラッキング、実験、評価、デプロイ、および改善を行うためのフレームワークです。このフレームワークには wandb-app pod 経由でアクセスします。

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

「W&B Kubernetes Operator 管理コンソールへのアクセス」を参照してください。

​
Ingress が動作しない場合の W&B Operator Console へのアクセス方法

Kubernetes クラスターに到達できるホスト上で、次のコマンドを実行します。 
kubectl port-forward svc/wandb-console 8082
ブラウザで https://localhost:8082/ にアクセスしてコンソールを開きます。 パスワードの取得方法（オプション 2）については、Accessing the W&B Kubernetes Operator Management Console を参照してください。

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

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

​
Kubernetes の IngressClass を特定する方法

クラスタにインストールされている IngressClass を確認するには、次のコマンドを実行します。 
kubectl get ingressclass