W&B サーバーを Kubernetes で実行する - Weights & Biases Documentation

W&B Kubernetes オペレーター

W&B Kubernetes オペレーターを使用して、Kubernetes 上の W&B Server デプロイメントを展開、管理、トラブルシューティング、およびスケーリングを簡素化します。このオペレーターは、W&B インスタンス用のスマートアシスタントと考えることができます。 W&B Server のアーキテクチャと設計は、AI 開発者のツール提供能力を拡張し、高性能でより優れたスケーラビリティと簡易な管理を提供するために進化し続けています。この進化は、コンピューティングサービス、関連ストレージ、およびそれらの接続性に適用されます。デプロイメントタイプ全体での継続的な更新と改善を促進するために、W&B は Kubernetes オペレーターを使用しています。

W&B はオペレーターを使用して、AWS、GCP、および Azure のパブリッククラウド上で専用クラウドインスタンスをデプロイおよび管理します。

Kubernetes オペレーターに関する詳細情報は、Kubernetes のドキュメントにあるオペレーターパターンを参照してください。

アーキテクチャの変更理由

歴史的に、W&B アプリケーションは Kubernetes クラスター内の単一デプロイメントおよびポッド、または単一の Docker コンテナとしてデプロイされていました。W&B は引き続き、データベースおよびオブジェクトストアを外部化することを推奨しています。データベースとオブジェクトストアの外部化は、アプリケーションの状態を切り離します。アプリケーションが成長するにつれて、モノリシックコンテナから分散システム（マイクロサービス）へ進化するニーズが明らかになりました。この変更はバックエンドロジックの処理を容易にし、組み込みの Kubernetes インフラストラクチャ能力をスムーズに導入します。分散システムはまた、新しいサービスの展開をサポートし、W&B が依存する追加の機能を提供します。 2024年以前、Kubernetes 関連の変更は、terraform-kubernetes-wandb Terraform モジュールを手動で更新する必要がありました。Terraform モジュールを更新することで、クラウドプロバイダー間の互換性が確保され、必要な Terraform 変数が設定され、すべてのバックエンドまたは Kubernetes レベルの変更ごとに Terraform を適用することが保証されました。このプロセスはスケーラブルではありませんでした。なぜなら、W&B サポートが各顧客に対して Terraform モジュールのアップグレードを支援しなければならなかったからです。その解決策は、中央の deploy.wandb.ai サーバーに接続するオペレーターを実装し、特定のリリースチャンネルに対する最新の仕様変更を要求して適用することでした。ライセンスが有効な限り、更新が受け取れます。Helm は、W&B オペレーターのデプロイメントメカニズムとして、また W&B Kubernetes スタックのすべての設定テンプレート処理を行う手段として使用され、Helm-セプションを実現します。

仕組み

オペレーターを helm でインストールするか、ソースからインストールすることができます。詳細な手順はcharts/operator を参照してください。インストールプロセスは controller-manager という名前のデプロイメントを作成し、spec をクラスターに適用する weightsandbiases.apps.wandb.com (shortName: wandb) という名前のカスタムリソース定義を使用します。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: weightsandbiases.apps.wandb.com

controller-manager は、カスタムリソース、リリースチャンネル、およびユーザー定義の設定の spec に基づいて charts/operator-wandb をインストールします。設定の仕様の階層は、ユーザー側での最大限の設定の柔軟性を実現し、新しい画像、設定、機能、および Helm 更新を自動的にリリースすることが可能です。設定オプションについては、設定仕様階層および設定参照を参照してください。

設定仕様階層

設定仕様は、上位レベルの仕様が下位レベルのものをオーバーライドする階層モデルに従います。以下はその仕組みです：

リリースチャンネル値: これは基本レベルの設定で、デプロイメントに対する W&B によって設定されたリリースチャンネルに基づいてデフォルトの値と設定を設定します。
ユーザー入力値: システムコンソールを通じて、ユーザーはリリースチャンネル Spec によって提供されるデフォルト設定をオーバーライドすることができます。
カスタムリソース値: ユーザーから提供される最高レベルの仕様です。ここで指定された値は、ユーザー入力およびリリースチャンネルの仕様の両方をオーバーライドします。設定オプションの詳細な説明については、設定参照を参照してください。

この階層モデルは、さまざまなニーズに合わせて柔軟でカスタマイズ可能な設定を保証し、管理可能で体系的なアップグレードと変更のアプローチを維持します。

W&B Kubernetes オペレーターを使用するための要件

W&B を W&B Kubernetes オペレーターでデプロイするために、次の要件を満たしてください: リファレンスアーキテクチャを参照してください。また、有効な W&B サーバーライセンスを取得します。セルフマネージドインストールのセットアップと構成方法についての詳細な説明は、こちらのガイドを参照してください。インストール方法によっては、次の要件を満たす必要がある場合があります:

正しい Kubernetes クラスターコンテキストでインストール済みかつ構成済みの Kubectl。
Helm がインストールされていること。

エアギャップインストール

エアギャップ環境での W&B Kubernetes オペレーターのインストール方法については、Deploy W&B in airgapped environment with Kubernetes チュートリアルを参照してください。

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

このセクションでは、W&B Kubernetes オペレーターをデプロイするさまざまな方法を説明しています。

W&B Operator は、W&B Server のデフォルトで推奨されるインストール方法です

以下のいずれかを選択してください:

必要なすべての外部サービスをプロビジョニング済みで、Helm CLI を使用して W&B を Kubernetes にデプロイしたい場合はこちらを参照してください。
インフラストラクチャと W&B Server を Terraform で管理することを好む場合はこちらを参照してください。
W&B Cloud Terraform Modules を利用したい場合はこちらを参照してください。

Helm CLI で W&B をデプロイする

W&B は W&B Kubernetes オペレーターを Kubernetes クラスターにデプロイするための Helm Chart を提供しています。この方法により、Helm CLI または ArgoCD などの継続的デリバリーツールを使用して W&B Server をデプロイできます。上記の要件が満たされていることを確認してください。次の手順に従って、Helm CLI を使用して W&B Kubernetes オペレーターをインストールします:

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 のインストールをトリガーします。この設定の例を operator.yaml というファイルにコピーし、W&B デプロイメントをカスタマイズできるようにします。設定参照を参照してください。

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/instance: wandb
    app.kubernetes.io/name: weightsandbiases
  name: wandb
  namespace: default

spec:
  chart:
    url: http://charts.yourdomain.com
    name: operator-wandb
    version: 0.18.0

  values:
    global:
      host: https://wandb.yourdomain.com
      license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      bucket:
        accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        name: s3.yourdomain.com:port #Ex.: s3.yourdomain.com:9000
        path: bucket_name
        provider: s3
        region: us-east-1
      mysql:
        database: wandb
        host: mysql.home.lab
        password: password
        port: 3306
        user: wandb
      extraEnv:
        ENABLE_REGISTRY_UI: 'true'

    # Ensure it's set to use your own MySQL
    mysql:
      install: false

    app:
      image:
        repository: registry.yourdomain.com/local
        tag: 0.59.2

    console:
      image:
        repository: registry.yourdomain.com/console
        tag: 2.12.2

    ingress:
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: 64m
      class: nginx

独自の設定でオペレーターを開始して、W&B Server アプリケーションをインストールおよび構成できるようにします。

kubectl apply -f operator.yaml

デプロイメントが完了するまで待ちます。これには数分かかります。

Web UI を使用してインストールを検証するには、最初の管理者ユーザーアカウントを作成し、インストールの検証で説明されている検証手順に従います。

Helm Terraform Module で W&B をデプロイする

この方法は、特定の要件に合わせたカスタマイズされたデプロイメントを可能にし、Terraform のインフラストラクチャ-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"
        }
      }
    }
  }
}

設定オプションは設定参照に記載されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは、W&B カスタムリソース定義 (CRD) を作成します。 W&B&Biases 自身が「Dedicated Cloud」インストールをデプロイするために Helm Terraform モジュールをどのように活用しているかを知るには、次のリンクをたどってください：

W&B Cloud Terraform Modules で W&B をデプロイする

W&B は AWS、GCP、および Azure のための Terraform Modules を提供しています。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースなどのインフラ全体と同様に W&B Server アプリケーションをデプロイします。これらの公式 W&B クラウド固有の Terraform Modules には、W&B Kubernetes オペレーターが既に組み込まれています。

Terraform Registry	Source Code	Version
AWS	https://github.com/wandb/terraform-aws-wandb	v4.0.0+
Azure	https://github.com/wandb/terraform-azurerm-wandb	v2.0.0+
GCP	https://github.com/wandb/terraform-google-wandb	v2.0.0+

この統合により、最小限のセットアップで W&B インスタンス用の W&B Kubernetes オペレーターの準備が整い、クラウド環境での W&B Server のデプロイと管理がスムーズに行えます。これらのモジュールの使用方法の詳細な説明については、セルフマネージドインストールセクションのドキュメントを参照してください。

インストールを検証する

インストールを検証するには、W&B は W&B CLI を使用することを推奨しています。検証コマンドは、すべてのコンポーネントと設定を検証するいくつかのテストを実行します。

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

インストールを検証するために以下の手順に従います:

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 管理コンソールへのアクセス

W&B Kubernetes オペレーターには管理コンソールが付属しています。 ${HOST_URI}/console にあり、例えば https://wandb.company-name.com/ です。管理コンソールにログインする方法は2つあります:

Option 1 (推奨)
Option 2

W&B アプリケーションをブラウザで開き、ログインします。W&B アプリケーションには ${HOST_URI}/ でログインします。例えば https://wandb.company-name.com/
コンソールにアクセスします。右上のアイコンをクリックし、次に System console をクリックします。管理者権限を持つユーザーだけが System console エントリを見ることができます。

W&B Kubernetes オペレーターの更新

このセクションでは、W&B Kubernetes オペレーターを更新する方法を説明します。

W&B Kubernetes オペレーターを更新しても、W&B サーバーアプリケーションは更新されません。
W&B Kubernetes オペレーターを使用していない helm chart を使用している場合は、続いて W&B オペレーターを更新する手順を実行する前にこちらの指示を参照してください。

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

まず、 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 オペレーターを使用する場合、W&B Server アプリケーションの更新は不要です。オペレーターは、W&B のソフトウェアの新しいバージョンがリリースされると、W&B Server アプリケーションを自動的に更新します。

W&B オペレーターへのセルフマネージドインスタンスの移行

このセクションでは、自分自身で W&B Server インストールを管理することから、W&B オペレーターを使用してこれを実行するための移行プロセスを説明しています。移行プロセスは、W&B Server をインストールした方法によって異なります:

W&B オペレーターは、W&B Server のデフォルトで推奨されるインストール方法です。質問がある場合や不明点がある場合は、カスタマーサポートまたは W&B チームに問い合わせてください。

公式の W&B Cloud Terraform Modules を使用した場合は、適切なドキュメントを参照し、次の手順に従ってください:
- AWS
- GCP
- Azure
W&B Non-Operator Helm チャートを使用した場合はこちらを続けてください。
W&B Non-Operator Helm チャート with Terraform を使用した場合はこちらを続けてください。
Kubernetes マニフェストでリソースを作成した場合はこちらを続けてください。

オペレーターを基にした AWS Terraform Modules への移行

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

オペレーターを基にした GCP Terraform Modules への移行

質問がある場合や支援が必要な際は、カスタマーサポートまたは W&B チームにお問い合わせください。

オペレーターを基にした Azure Terraform Modules への移行

質問がある場合や支援が必要な際は、カスタマーサポートまたは W&B チームにお問い合わせください。

オペレーターを基にした Helm チャートへの移行

オペレーターを基にした Helm チャートへの移行手順は次のとおりです:

現在の W&B 設定を取得します。W&B がオペレーターを基にしていないバージョンの Helm チャートでデプロイされている場合、次のように値をエクスポートします:
```
helm get values wandb
```
W&B が Kubernetes マニフェストでデプロイされている場合、次のように値をエクスポートします:
```
kubectl get deployment wandb -o yaml
```
これで、次のステップで必要なすべての設定値が手元にあります。
operator.yaml というファイルを作成します。設定参照で説明されている形式に従ってください。ステップ 1 の値を使用します。
現在のデプロイメントを 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 コードを、こちらで説明されているものに置き換えます。以前と同じ変数を設定します。.tfvars ファイルがある場合、それを変更しないでください。
Terraform run を実行します。terraform init、plan、および apply を実行します。
インストールを検証します。すべてが正常に動作することを確認するために、インストールの検証の手順に従います。
古いインストールの削除。古い helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

Configuration Reference for W&B Server

このセクションでは、W&B サーバーアプリケーションの設定オプションについて説明します。アプリケーションは、WeightsAndBiasesというカスタムリソース定義としてその設定を受け取ります。一部の設定オプションは以下の設定で公開され、他は環境変数として設定する必要があります。ドキュメントには環境変数が2つのリストに分かれています：basic および advanced。必要な設定オプションが 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 リポジトリにあります。オーバーライドする必要がある値のみを変更してください。

完全な例

これは、GCP Kubernetes を使用した GCP Ingress および GCS（GCP オブジェクトストレージ）を使用した設定例です：

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

ホスト

 # プロトコルと共に完全修飾ドメイン名を提供
global:
  # ホスト名の例、独自のものに置き換え
  host: https://wandb example com

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

AWS

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

GCP

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

Azure

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

その他のプロバイダー（Minio、Ceph、など） 他の S3 互換プロバイダーの場合、バケットの設定は次のようにします：

global:
  bucket:
    # 例の値、独自のものに置き換え
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    accessKey: 5WOA500...P5DK7I
    secretKey: HDKYe4Q...JAp1YyjysnX

AWS 外部でホスティングされている S3 互換ストレージの場合、kmsKey は null にする必要があります。 accessKey および secretKey をシークレットから参照するには：

global:
  bucket:
    # 例の値、独自のものに置き換え
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    secret:
      secretName: bucket-secret
      accessKeyName: ACCESS_KEY
      secretKeyName: SECRET_KEY

MySQL

global:
   mysql:
     # 例の値、独自のものに置き換え
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     password: 8wtX6cJH...ZcUarK4zZGjpV 

password をシークレットから参照するには：

global:
   mysql:
     # 例の値、独自のものに置き換え
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

ライセンス

global:
  # 例のライセンス、独自のものに置き換え
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

license をシークレットから参照するには：

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

Ingress

Kubernetes ingress クラスを識別する方法については、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: 64m

カスタム Kubernetes ServiceAccounts

W&B ポッドを実行するためにカスタム Kubernetes Service Account を指定します。次のスニペットは、指定された名前でデプロイメントの一部としてサービスアカウントを作成します：

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

TLS を使用しない場合

global:
  ldap:
    enabled: true
    # LDAP サーバーアドレスには "ldap://" または "ldaps://" を含める
    host:
    # ユーザーを見つけるために使用する LDAP 検索ベース
    baseDN:
    # バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
    bindDN:
    # バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
    bindPW:
    # 電子メールおよびグループ ID 属性名の LDAP 属性をカンマ区切りの文字列で指定
    attributes:
    # LDAP グループ許可リスト
    groupAllowList:
    # LDAP TLS の有効化
    tls: false

TLS 使用 LDAP TLS 証明書の設定には、証明書内容をプレ作成した config map が必要です。 config map を作成するには、次のコマンドを使用できます：

kubectl create configmap ldap-tls-cert --from-file=certificate.crt

そして、下記の例のように YAML 内で config map を使用します：

global:
  ldap:
    enabled: true
    # LDAP サーバーアドレスには "ldap://" または "ldaps://" を含める
    host:
    # ユーザーを見つけるために使用する LDAP 検索ベース
    baseDN:
    # バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
    bindDN:
    # バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
    bindPW:
    # 電子メールおよびグループ ID 属性名の LDAP 属性をカンマ区切りの文字列で指定
    attributes:
    # LDAP グループ許可リスト
    groupAllowList:
    # LDAP TLS の有効化
    tls: true
    # LDAP サーバーの CA 証明書を含む ConfigMap の名前とキー
    tlsCert:
      configMap:
        name: "ldap-tls-cert"
        key: "certificate.crt"

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

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

証明書機関を 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 だけが有効な値です。他の値はエラーです。

アプリケーションポッドを設定するには、設定に 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 にも適用されます。

Configuration Reference for W&B Operator

このセクションでは、W&B Kubernetes オペレーター（wandb-controller-manager）の設定オプションを説明しています。オペレーターは、YAML ファイルの形式でその設定を受け取ります。デフォルトでは、W&B Kubernetes オペレーターには設定ファイルは必要ありません。必要な場合にだけ設定ファイルを作成します。たとえば、カスタム証明書機関を指定したり、エアギャップ環境にデプロイしたりする必要がある場合などです。仕様のカスタマイズの完全なリストは、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 ストアに解析して追加するために必要です。

FAQ

各個別のポッドの役割/目的は何ですか？

wandb-app: W&B の中枢であり、GraphQL API およびフロントエンドアプリケーションを含みます。これは私たちのプラットフォームの大部分の機能を提供します。
wandb-console: 管理コンソールであり、/console を通じてアクセスできます。
wandb-otel: OpenTelemetry エージェントであり、Kubernetes レイヤーでのリソースからメトリクスおよびログを収集して管理コンソールに表示します。
wandb-prometheus: Prometheus サーバーであり、管理コンソールに表示するためにさまざまなコンポーネントからメトリクスを収集します。
wandb-parquet: wandb-app ポッドとは別のバックエンドマイクロサービスであり、データベースデータを Parquet 形式でオブジェクトストレージにエクスポートします。
wandb-weave: UI でクエリテーブルをロードし、さまざまなコアアプリ機能をサポートする別のバックエンドマイクロサービス。
wandb-weave-trace: LLM ベースのアプリケーションを追跡、実験、評価、展開、および改善するためのフレームワーク。このフレームワークは wandb-app ポッドを介してアクセスできます。

W&B オペレーターコンソールパスワードの取得方法

W&B Kubernetes オペレーターマネジメントコンソールへのアクセスを参照してください。

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

Kubernetes クラスターに到達可能なホストで以下のコマンドを実行してください：

kubectl port-forward svc/wandb-console 8082

https://localhost:8082/ console でブラウザからコンソールにアクセスしてください。コンソールのパスワードの取得方法については、W&B Kubernetes オペレーターマネジメントコンソールへのアクセス（Option 2）を参照してください。

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

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

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes ingress クラスを識別する方法

クラスターにインストールされている ingress クラスを取得するには、次のコマンドを実行します:

kubectl get ingressclass

デプロイメントオプション

Configuring W&B

​W&B Kubernetes オペレーター

​アーキテクチャの変更理由

​仕組み

​設定仕様階層

​W&B Kubernetes オペレーターを使用するための要件

​エアギャップインストール

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

​Helm CLI で W&B をデプロイする

​Helm Terraform Module で W&B をデプロイする

​W&B Cloud Terraform Modules で W&B をデプロイする

​インストールを検証する

​W&B 管理コンソールへのアクセス

​W&B Kubernetes オペレーターの更新

​W&B Server アプリケーションの更新

​W&B オペレーターへのセルフマネージドインスタンスの移行

​オペレーターを基にした AWS Terraform Modules への移行

​オペレーターを基にした GCP Terraform Modules への移行

​オペレーターを基にした Azure Terraform Modules への移行

​オペレーターを基にした Helm チャートへの移行

​オペレーターを基にした Terraform Helm チャートへの移行

​Configuration Reference for W&B Server

​完全な例

​ホスト

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

​MySQL

​ライセンス

​Ingress

​カスタム Kubernetes ServiceAccounts

​外部 Redis

​LDAP

​OIDC SSO

​SMTP

​環境変数

​カスタム証明書機関

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

​Configuration Reference for W&B Operator

​カスタム CA

​FAQ

​各個別のポッドの役割/目的は何ですか？

​W&B オペレーターコンソールパスワードの取得方法

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

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

​Kubernetes ingress クラスを識別する方法

W&B Kubernetes オペレーター

アーキテクチャの変更理由

仕組み

設定仕様階層

W&B Kubernetes オペレーターを使用するための要件

エアギャップインストール

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

Helm CLI で W&B をデプロイする

Helm Terraform Module で W&B をデプロイする

W&B Cloud Terraform Modules で W&B をデプロイする

インストールを検証する

W&B 管理コンソールへのアクセス

W&B Kubernetes オペレーターの更新

W&B Server アプリケーションの更新

W&B オペレーターへのセルフマネージドインスタンスの移行

オペレーターを基にした AWS Terraform Modules への移行

オペレーターを基にした GCP Terraform Modules への移行

オペレーターを基にした Azure Terraform Modules への移行

オペレーターを基にした Helm チャートへの移行

オペレーターを基にした Terraform Helm チャートへの移行

Configuration Reference for W&B Server

完全な例

ホスト

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

MySQL

ライセンス

Ingress

カスタム Kubernetes ServiceAccounts

外部 Redis

LDAP

OIDC SSO

SMTP

環境変数

カスタム証明書機関

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

Configuration Reference for W&B Operator

カスタム CA

FAQ

各個別のポッドの役割/目的は何ですか？

W&B オペレーターコンソールパスワードの取得方法

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

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

Kubernetes ingress クラスを識別する方法