Kubernetes 上での W&B Server の実行 - Weights & Biases Documentation

W&B Kubernetes Operator

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

W&B は、AWS、Google Cloud、Azure のパブリッククラウド上で Dedicated Cloud インスタンスをデプロイおよび管理するために Operator を使用しています。

Kubernetes Operator の詳細については、Kubernetes ドキュメントの Operator パターンを参照してください。

アーキテクチャー移行の理由

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

仕組み

Operator は Helm またはソースからインストールできます。詳細な手順については charts/operator を参照してください。インストールプロセスでは、controller-manager という名前のデプロイメントが作成され、weightsandbiases.apps.wandb.com（shortName: wandb）という名前のカスタムリソース定義が使用されます。これは単一の spec を受け取り、クラスターに適用します。

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

controller-manager は、カスタムリソースの spec、リリースチャンネル、およびユーザー定義の設定に基づいて charts/operator-wandb をインストールします。この設定仕様の階層構造により、ユーザー側での最大限の設定柔軟性が得られ、W&B は新しいイメージ、設定、機能、および Helm のアップデートを自動的にリリースできるようになります。設定オプションについては、設定仕様の階層構造および W&B Operator の設定リファレンスを参照してください。デプロイメントは複数の Pod で構成され、サービスごとに 1 つずつ配置されます。各 Pod の名前には wandb- というプレフィックスが付きます。

設定仕様の階層構造

設定仕様は、上位の仕様が下位の仕様を上書きする階層モデルに従います。仕組みは以下の通りです：

Release Channel Values（リリースチャンネル値）: この基本レベルの設定は、W&B がデプロイメント用に設定したリリースチャンネルに基づいてデフォルト値と設定を決定します。
User Input Values（ユーザー入力値）: ユーザーはシステムコンソールを通じて、リリースチャンネル仕様によって提供されたデフォルト設定を上書きできます。
Custom Resource Values（カスタムリソース値）: ユーザーから提供される最高レベルの仕様です。ここで指定された値は、ユーザー入力およびリリースチャンネルの両方の仕様を上書きします。設定オプションの詳細は、設定リファレンスを参照してください。

この階層モデルにより、アップグレードや変更に対して管理可能かつ系統的なアプローチを維持しつつ、多様なニーズを満たすための柔軟でカスタマイズ可能な設定が可能になります。

始める前に

インフラストラクチャーの完全な要件についてはリファレンスアーキテクチャーを参照してください。これには以下が含まれます：

ソフトウェアバージョンの要件（Kubernetes, MySQL, Redis, Helm）
ハードウェアの要件（CPU アーキテクチャー、サイジングの推奨事項）
ネットワーク、SSL/TLS、および DNS の要件

有効な W&B Server ライセンスを取得してください。
W&B Self-Managed のセットアップと設定の詳細な手順については、以下のセクションおよびベアメタルインストールガイドを参照してください。インストール方法によっては、追加のソフトウェアのインストールや要件が必要になる場合があります。

MySQL データベース

W&B requires an external MySQL database. For production, W&B strongly recommends using managed database services:

Managed database services provide automated backups, monitoring, high availability, patching, and reduce operational overhead. See the reference architecture for complete MySQL requirements, including sizing recommendations and configuration parameters. For database creation SQL, see the bare-metal guide. For questions about your deployment’s database configuration, contact support or your AISE.

Redis

W&B depends on a single-node Redis 7.x deployment used by W&B’s components for job queuing and data caching. For convenience during testing and development of proofs of concept, W&B Self-Managed includes a local Redis deployment that is not appropriate for production deployments. For production deployments, W&B can connect to a Redis instance in the following environments:

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
Redis deployment hosted in your cloud or on-premise infrastructure

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

オブジェクトストレージ

W&B requires object storage with pre-signed URL and CORS support. For production deployments, W&B recommends using managed object storage services:

Amazon S3: Object storage service offering industry-leading scalability, data availability, security, and performance.
Google Cloud Storage: Managed service for storing unstructured data at scale.
Azure Blob Storage: Cloud-based object storage solution for storing massive amounts of unstructured data.
CoreWeave AI Object Storage: High-performance, S3-compatible object storage service optimized for AI workloads.

For self-hosted object storage options, see the bare-metal guide object storage section for detailed setup instructions including CORS configuration and enterprise alternatives.

MinIO Open Source is in maintenance mode with no active development or pre-compiled binaries. For production deployments, W&B recommends using managed object storage services or enterprise-grade S3-compatible solutions.

See the reference architecture object storage section for complete requirements. Helm 値でのオブジェクトストレージの設定方法の詳細については、オブジェクトストレージバケット設定セクションを参照してください。

ネットワーク要件

For a networked deployment, egress to these endpoints is required during both installation and runtime:

https://deploy.wandb.ai
https://charts.wandb.ai
https://quay.io (used for Prometheus images)

Additional container registries may be required depending on your deployment configuration:

https://gcr.io is needed when deploying Bufstream and etcd for Weave online evaluations.

To learn about air-gapped deployments, refer to Kubernetes operator for air-gapped instances. Access to W&B and to the object storage is required for the training infrastructure and for each system that tracks the needs of experiments. ロードバランサーと Ingress コントローラのオプションおよび設定例については、リファレンスアーキテクチャーのロードバランサーセクションを参照してください。

SSL/TLS 要件

W&B requires a valid signed SSL/TLS certificate for secure communication between clients and the server. SSL/TLS termination must occur on the ingress/load balancer. The W&B Server application does not terminate SSL or TLS connections. Important: W&B does not support self-signed certificates and custom CAs. Using self-signed certificates will cause challenges for users and is not supported. If possible, using a service like Let’s Encrypt is a great way to provide trusted certificates to your load balancer. Services like Caddy and Cloudflare manage SSL for you. If your security policies require SSL communication within your trusted networks, consider using a tool like Istio and side car containers.

エアギャップ環境でのインストール

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

OpenShift Kubernetes クラスター

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

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

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

デフォルトでは、コンテナは 999 の $UID を使用します。オーケストレーターが非 root ユーザーでのコンテナ実行を必要とする場合は、100000 以上の $UID と 0 の $GID を指定してください。

ファイルシステムのパーミッションが正しく機能するために、W&B は root グループ（$GID=0）として起動する必要があります。

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

api:
  install: true
  image:
    repository: wandb/megabinary
    tag: 0.74.1
  pod:
    securityContext:
      fsGroup: 10001
      fsGroupChangePolicy: Always
      runAsGroup: 0
      runAsNonRoot: true
      runAsUser: 10001
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      privileged: false
      readOnlyRootFilesystem: false

必要に応じて、app や console などの他のコンポーネントに対してカスタムセキュリティコンテキストを設定してください。詳細については、カスタムセキュリティコンテキストを参照してください。

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

クラウド、オンプレミス、エアギャップ環境を含むすべての W&B Self-Managed デプロイメントにおいて、Helm を使用した W&B Kubernetes Operator が推奨されるインストール方法です。

このセクションでは、W&B Kubernetes Operator をデプロイするさまざまな方法について説明します：

Helm CLI: Helm コマンドを使用した直接デプロイ
Helm Terraform Module: Infrastructure-as-code によるデプロイ
W&B Cloud Terraform Modules: AWS、Google Cloud、Azure 向けの完全なインフラストラクチャー + アプリケーションのデプロイ

デプロイ固有の考慮事項については、以下も参照してください：

データセンター/ベアメタル環境については Deploy W&B Platform On-premises
切断された環境については Kubernetes operator for air-gapped instances

Helm CLI による W&B のデプロイ

W&B は、W&B Kubernetes Operator を Kubernetes クラスターにデプロイするための Helm チャートを提供しています。このアプローチにより、Helm CLI や ArgoCD のような継続的デリバリーツールを使用して W&B Server をデプロイできます。前述の要件が整っていることを確認してください。 Helm CLI で W&B Kubernetes Operator をインストールするには、以下の手順に従います：

W&B Helm リポジトリを追加します。W&B Helm チャートは W&B Helm リポジトリで利用可能です：
```
helm repo add wandb https://charts.wandb.ai
helm repo update
```
Kubernetes クラスターに Operator をインストールします：
```
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```

W&B Server のインストールをトリガーするように W&B Operator カスタムリソースを設定します。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:
        <プロバイダーによって詳細が異なります>
      mysql:
        <非表示>
    ingress:
      annotations:
        <非表示>

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

Helm Terraform モジュールによる W&B のデプロイ

この方法では、一貫性と再現性のために Terraform の Infrastructure-as-code アプローチを活用し、特定の要件に合わせてカスタマイズされたデプロイが可能です。公式の W&B Helm ベースの Terraform モジュールはこちらにあります。以下のコードは出発点として使用でき、プロダクショングレードのデプロイに必要なすべての設定オプションが含まれています。

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

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

        bucket = {
          <プロバイダーによって詳細が異なります>
        }

        mysql = {
          <非表示>
        }
      }

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

設定オプションは設定リファレンスで説明されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があることに注意してください。Terraform モジュールは W&B カスタムリソース定義 (CRD) を作成します。 W&B 自身が顧客向けに「Dedicated Cloud」インスタンスをデプロイするために Helm Terraform モジュールをどのように使用しているかを確認するには、以下のリンクを参照してください：

W&B Cloud Terraform モジュールによる W&B のデプロイ

W&B は、AWS、Google Cloud、Azure 向けの Terraform モジュールセットを提供しています。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースなどのインフラ全体と、W&B Server アプリケーションをデプロイします。W&B Kubernetes Operator は、以下のバージョンの公式 W&B クラウド固有 Terraform モジュールにあらかじめ組み込まれています：

Terraform レジストリ	ソースコード	バージョン
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 のデプロイと管理が効率化されます。これらのモジュールの使用方法に関する詳細な説明については、ドキュメントの Self-Managed インストールセクションを参照してください。

インストールの確認

To verify the installation, W&B recommends using the W&B CLI. The verify command executes several tests that verify all components and configurations.

This step assumes that the first admin user account is created with the browser.

Follow these steps to verify the installation:

Install the W&B CLI:

pip install wandb

wandb login --host=https://YOUR_DNS_DOMAIN

For example:

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

Verify the installation:

wandb verify

A successful installation and fully working W&B deployment shows the following output:

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

Contact W&B Support if you encounter errors.

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

W&B Kubernetes Operator には管理コンソールが付属しています。場所は ${HOST_URI}/console（例: https://wandb.company-name.com/console）です。管理コンソールにログインする方法は 2 つあります：

オプション 1 (推奨)
オプション 2

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

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

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

W&B Kubernetes Operator のアップデート

このセクションでは、W&B Kubernetes Operator をアップデートする方法について説明します。

W&B Kubernetes Operator をアップデートしても、W&B Server アプリケーションはアップデートされません。
W&B Kubernetes Operator を使用していない Helm チャートを使用している場合は、W&B Operator をアップデートする前にこちらの手順に従って移行してください。

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

まず、helm repo update でリポジトリを更新します：
```
helm repo update
```
次に、helm upgrade で Helm チャートをアップデートします：
```
helm upgrade operator wandb/operator -n wandb-cr --reuse-values
```

W&B Server アプリケーションのアップデート

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

Self-Managed インスタンスから W&B Operator への移行

このセクションでは、ご自身で管理している W&B Server のインストールから、W&B Operator を使用した管理への移行方法について説明します。移行プロセスは W&B Server のインストール方法によって異なります：

W&B Operator は W&B Server のデフォルトで推奨されるインストール方法です。ご不明な点がございましたら、カスタマーサポートまたは W&B 担当チームまでお問い合わせください。

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

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

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

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

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

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

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

Operator ベースの Helm チャートへの移行

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

現在の W&B 設定を取得します。Operator ベースではないバージョンの Helm チャートでデプロイされていた場合は、次のように値をエクスポートします：
```
helm get values wandb
```
Kubernetes マニフェストでデプロイされていた場合は、次のようにエクスポートします：
```
kubectl get deployment wandb -o yaml
```
これで、次のステップに必要なすべての設定値が揃いました。
operator.yaml というファイルを作成します。設定リファレンスに記載されている形式に従い、ステップ 1 の値を使用してください。
現在のデプロイメントを 0 Pod にスケールします。このステップで現在のデプロイメントを停止します。
```
kubectl scale --replicas=0 deployment wandb
```
Helm チャートリポジトリを更新します：
```
helm repo update
```
新しい Helm チャートをインストールします：
```
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
新しい Helm チャートを設定し、W&B アプリケーションのデプロイをトリガーします。新しい設定を適用します。
```
kubectl apply -f operator.yaml
```
デプロイが完了するまで数分かかります。
インストールを確認します。インストールの確認の手順に従い、すべてが動作していることを確認してください。
旧いインストールを削除します。旧い Helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

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

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

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

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

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

基本的な例

この例では、W&B に最低限必要な値のセットを定義します。より現実的なプロダクション環境の例については、完全な例を参照してください。この YAML ファイルは、バージョン、環境変数、データベースなどの外部リソース、およびその他の必要な設定を含む、W&B デプロイメントの望ましい状態を定義します。

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <プロバイダーによって詳細が異なります>
      mysql:
        <非表示>
    ingress:
      annotations:
        <非表示>

すべての値のセットは W&B Helm リポジトリで確認できます。上書きが必要な値のみを変更してください。

完全な例

この例では、Google Cloud Storage を使用して Google Cloud Anthos に 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://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

Host

 # プロトコル付きの FQDN を提供
global:
  # ホスト名の例。ご自身のものに置き換えてください
  host: https://wandb.example.com

オブジェクトストレージ (bucket)

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 互換プロバイダーについては、バケット設定を次のように設定します：

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 あり 証明書を含むシークレットを作成します

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 ServiceAccounts

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 にお問い合わせください。

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"

カスタム認証局 (CA)

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 を使用する場合、各キーは .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 は設定ファイルを必要としません。必要に応じて設定ファイルを作成してください。例えば、カスタム認証局の指定やエアギャップ環境でのデプロイなどが必要な場合です。スペックのカスタマイズに関する全リストは Helm リポジトリで確認できます。

カスタム CA

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

customCACerts:
- |
  -----BEGIN CERTIFICATE-----
  MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
  SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
  P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
  -----END CERTIFICATE-----
- |
  -----BEGIN CERTIFICATE-----
  MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
  SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
  aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
  -----END CERTIFICATE-----

CA 証明書は ConfigMap に保存することもできます：

caCertsConfigMap: custom-ca-certs

ConfigMap は以下のようになります：

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

ConfigMap 内の各キーは .crt で終わる必要があります（例: my-cert.crt や ca-cert1.crt）。この命名規則は、update-ca-certificates が各証明書を解析してシステムの CA ストアに追加するために必要です。

FAQ

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

wandb-app: W&B のコア。GraphQL API とフロントエンドアプリケーションを含みます。プラットフォーム機能の大部分を担います。
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 コンソールのパスワードを取得する方法

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

Ingress が機能しない場合に W&B Operator コンソールにアクセスする方法

Kubernetes クラスターに到達可能なホストで以下のコマンドを実行します：

kubectl port-forward svc/wandb-console 8082

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

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

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

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes の Ingress クラスを特定する方法

クラスターにインストールされている Ingress クラスは、以下のコマンドで確認できます。

kubectl get ingressclass

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

Configuring W&B

​W&B Kubernetes Operator

​アーキテクチャー移行の理由

​仕組み

​設定仕様の階層構造

​始める前に

​MySQL データベース

​Redis

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

​ネットワーク要件

​SSL/TLS 要件

​エアギャップ環境でのインストール

​OpenShift Kubernetes クラスター

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

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

​Helm CLI による W&B のデプロイ

​Helm Terraform モジュールによる W&B のデプロイ

​W&B Cloud Terraform モジュールによる W&B のデプロイ

​インストールの確認

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

​W&B Kubernetes Operator のアップデート

​W&B Server アプリケーションのアップデート

​Self-Managed インスタンスから W&B Operator への移行

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

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

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

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

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

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

​基本的な例

​完全な例

​Host

​オブジェクトストレージ (bucket)

​MySQL

​ライセンス

​Ingress

​カスタム Kubernetes ServiceAccounts

​外部 Redis

​LDAP

​OIDC SSO

​SMTP

​環境変数

​カスタム認証局 (CA)

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

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

​カスタム CA

​FAQ

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

​W&B Operator コンソールのパスワードを取得する方法

​Ingress が機能しない場合に W&B Operator コンソールにアクセスする方法

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

​Kubernetes の Ingress クラスを特定する方法

W&B Kubernetes Operator

アーキテクチャー移行の理由

仕組み

設定仕様の階層構造

始める前に

MySQL データベース

Redis

オブジェクトストレージ

ネットワーク要件

SSL/TLS 要件

エアギャップ環境でのインストール

OpenShift Kubernetes クラスター

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

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

Helm CLI による W&B のデプロイ

Helm Terraform モジュールによる W&B のデプロイ

W&B Cloud Terraform モジュールによる W&B のデプロイ

インストールの確認

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

W&B Kubernetes Operator のアップデート

W&B Server アプリケーションのアップデート

Self-Managed インスタンスから W&B Operator への移行

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

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

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

Operator ベースの Helm チャートへの移行

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

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

基本的な例

完全な例

Host

オブジェクトストレージ (bucket)

MySQL

ライセンス

Ingress

カスタム Kubernetes ServiceAccounts

外部 Redis

LDAP

OIDC SSO

SMTP

環境変数

カスタム認証局 (CA)

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

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

カスタム CA

FAQ

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

W&B Operator コンソールのパスワードを取得する方法

Ingress が機能しない場合に W&B Operator コンソールにアクセスする方法

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

Kubernetes の Ingress クラスを特定する方法