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

概要

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

開始前に

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

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

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

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

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

MySQL データベース

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

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

Redis

W&B では、コンポーネントによるジョブキューイングとデータキャッシュのために、単一ノード構成の Redis 7.x デプロイが必要です。テストや概念実証の開発を容易にするため、W&B セルフマネージドにはローカルの Redis デプロイが含まれていますが、これは本番デプロイには適していません。本番デプロイでは、W&B は次の環境にある Redis インスタンスに接続できます。

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
お使いのクラウドまたはオンプレミスのインフラストラクチャーでホストされている Redis デプロイ

Helm values で外部 Redis インスタンスを設定する方法について詳しくは、外部 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 は、アクティブな開発や事前コンパイル済みバイナリの提供がない maintenance mode です。本番デプロイでは、W&B はマネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ向け S3 互換ソリューションの使用を推奨しています。

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 チャートを使用したインストールを推奨しています。

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

デフォルトでは、コンテナーは $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 を使用してインストールを確認するには、最初の管理者ユーザーアカウントを作成してから、インストールを確認するに記載された確認手順に従ってください。

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

Helm Terraform Module: 既存の Kubernetes インフラストラクチャーに operator をデプロイ
Cloud Terraform Modules: AWS、Google Cloud、Azure 向けのインフラストラクチャーと application を含む完全なデプロイ

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

Helm Terraform Module

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

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 の使用を推奨しています。verify command は、すべてのコンポーネントと設定を検証する複数のテストを実行します。

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

インストールを確認するには、次の step に従います。

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

インストールが成功し、W&B デプロイが正常に動作している場合、次のような出力が表示されます：

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サポートまでお問い合わせください。

環境固有の考慮事項

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 を参照してください。air-gapped 環境での OpenShift の包括的な例については、Air-Gapped Kubernetes へのデプロイを参照してください。

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

オブジェクトストレージのバケットをプロビジョニングしたら、W&B Custom Resource で設定します (オブジェクトストレージのプロビジョニングを参照) 。 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 要件を参照してください。

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

ストレージ容量とパフォーマンス: ディスク容量を注意深く監視してください。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 の完全マネージドサービスは、ほとんど、またはまったく設定不要で、シンプルかつ安全に使用できます。

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

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

開発環境を準備します。
- 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 で、FQDN レコードは DNS の zone_id に作成されます。 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 公式ドキュメントを参照してください。任意ですが、強く推奨するため、このドキュメントの冒頭で説明したリモートバックエンドの設定を追加してください。

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

variable "namespace" {
  type        = string
  description = "リソースに使用する名前プレフィックス"
}

variable "domain_name" {
  type        = string
  description = "インスタンスへのアクセスに使用するドメイン名。"
}

variable "subdomain" {
  type        = string
  default     = null
  description = "Weights & Biases UIにアクセスするためのサブドメイン。"
}

variable "license" {
  type = string
}

variable "zone_id" {
  type        = string
  description = "Weights & Biases サブドメインを作成するドメイン。"
}

variable "allowed_inbound_cidr" {
 description = "wandb-serverへのアクセスを許可するCIDR。"
 nullable    = false
 type        = list(string)
}

variable "allowed_inbound_ipv6_cidr" {
 description = "wandb-serverへのアクセスを許可するCIDR。"
 nullable    = false
 type        = list(string)
}

variable "eks_cluster_version" {
 description = "EKSクラスターのKubernetesバージョン"
 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 の使用を推奨します。モジュールのドキュメントは充実しており、使用可能なすべてのオプションが記載されています。開始する前に、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 step

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

開発環境を準備する。
- 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 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 Module の使用を W&B は推奨しています。モジュールのドキュメントは充実しており、使用可能なすべてのオプションが記載されています。Terraform Moduleは、以下の必須コンポーネントをデプロイします：

Azure リソースグループ
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 Service Principal の使用も有効です。使用する認証方法に関わらず、Terraformを実行するアカウントには、上記で説明したすべてのコンポーネントを作成する権限が必要です。

一般的な手順

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

開発環境を用意します。
- 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 Official Documentationを参照してください。任意ですが、強く推奨するため、このドキュメントの冒頭で説明したリモートバックエンド設定を追加してください。

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

推奨デプロイ構成

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

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

# 必要なサービスをすべて起動する
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 に組み込みの broker が含まれているため、任意です。このオプションを指定しても、パフォーマンスは向上しません。

# 必要なサービスをすべて起動する
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 には管理コンソールが付属しています。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 を更新する方法を説明します。

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

以下のコードスニペットをコピー＆ペーストして、ターミナルに貼り付けます。

まず、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 アプリケーションを自動的に更新します。

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

このセクションでは、W&B Server を自分で管理する構成から、W&B Operator による管理へ移行する方法を説明します。移行プロセスは、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 ベースの 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 チャートに移行する

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

Terraform 設定を準備します。Terraform 設定内の既存のデプロイ用 Terraform コードを、こちらで説明されているコードに置き換えます。変数はこれまでと同じものを設定してください。.tfvars ファイルがある場合は変更しないでください。
Terraform を実行します。terraform init、plan、apply を実行します。
インストールを確認します。インストールを確認するの step に従って、すべてが正常に動作することを確認します。
古いインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストで作成したリソースを削除します。

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

このセクションでは、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の例。実際のものに置き換えてください
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

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

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

イングレス

ingress クラスを確認するには、この FAQ のエントリを参照してください。 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"

カスタム認証局

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 の目的/役割は何ですか？

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

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

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

kubectl port-forward svc/wandb-console 8082

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

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

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

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

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

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

kubectl get ingressclass

W&B へようこそ

プロダクト

プラットフォームの詳細

リソース

​概要

​開始前に

​MySQL データベース

​Redis

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

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

​OpenShift Kubernetes clusters

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

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

​Helm Terraform Module

​クラウド Terraform モジュール

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

​環境固有の考慮事項

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

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

​永続ストレージ

​DNS と証明書の管理

​OpenShift デプロイ

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

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

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

​前提条件の権限

​General steps

​推奨デプロイ

​Redisを有効にする

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

​追加リソース

​前提となる権限

​General step

​推奨デプロイ構成

​Redisを有効にする

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

​追加リソース

​前提条件の権限

​一般的な手順

​推奨デプロイ構成

​Redisを有効にする

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

​追加リソース

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

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

​W&B Kubernetes Operator を更新する

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

​セルフマネージド インスタンスから 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

​ライセンス

​イングレス

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

​外部 Redis

​LDAP

​OIDC SSO

​SMTP

​環境変数

​カスタム認証局

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

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

​カスタム CA

​FAQ

​各 pod の目的/役割は何ですか？

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

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

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

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

概要

開始前に

MySQL データベース

Redis

オブジェクトストレージ

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

OpenShift Kubernetes clusters

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

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

Helm Terraform Module

クラウド Terraform モジュール

インストールを確認する

環境固有の考慮事項

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

ロードバランサーの設定

永続ストレージ

DNS と証明書の管理

OpenShift デプロイ

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

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

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

前提条件の権限

General steps

推奨デプロイ

Redisを有効にする

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

追加リソース

前提となる権限

General step

推奨デプロイ構成

Redisを有効にする

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

追加リソース

前提条件の権限

一般的な手順

推奨デプロイ構成

Redisを有効にする

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

追加リソース

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

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

W&B Kubernetes Operator を更新する

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

セルフマネージドインスタンスから 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

ライセンス

イングレス

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

外部 Redis

LDAP

OIDC SSO

SMTP

環境変数

カスタム認証局

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

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

カスタム CA

FAQ

各 pod の目的/役割は何ですか？

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

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

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

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