> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-serverless-sft-revamp.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Kubernetes 上での W&B Server の実行 > Kubernetes Operator を使用した W&B プラットフォーム のデプロイ ## 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 パターン](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) を参照してください。 ### アーキテクチャー移行の理由 歴史的に、W\&B アプリケーションは、Kubernetes クラスター内の単一のデプロイメントおよび Pod、または単一の Docker コンテナとしてデプロイされてきました。W\&B はこれまでも、そしてこれからも、データベースとオブジェクトストアの外出しを推奨しています。データベースとオブジェクトストアを外出しにすることで、アプリケーションの状態を切り離すことができます。 アプリケーションが成長するにつれ、モノリシックなコンテナから分散システム（マイクロサービス）へと進化させる必要性が明らかになりました。この変更により、バックエンドロジックの処理が容易になり、組み込みの Kubernetes インフラストラクチャー機能をシームレスに導入できるようになります。また、分散システムは、W\&B が依存する追加機能に不可欠な新しいサービスのデプロイもサポートします。 2024 年以前は、Kubernetes 関連の変更には、[terraform-kubernetes-wandb](https://github.com/wandb/terraform-kubernetes-wandb) Terraform モジュールを手動で更新する必要がありました。Terraform モジュールを更新することで、クラウドプロバイダー間の互換性を確保し、必要な Terraform 変数を設定し、バックエンドまたは Kubernetes レベルの変更ごとに Terraform apply を実行していました。 このプロセスは、W\&B サポートが各顧客の Terraform モジュールのアップグレードを支援する必要があったため、スケーラブルではありませんでした。 その解決策として、中央の [deploy.wandb.ai](https://deploy.wandb.ai) サーバーに接続し、特定のリリースチャンネルに対する最新の仕様変更をリクエストして適用する Operator を実装しました。ライセンスが有効である限り、アップデートを受け取ることができます。デプロイメカニズムと、W\&B Kubernetes スタックのすべての設定テンプレートを処理する手段の両方に [Helm](https://helm.sh/) が使用されています（Helm-ception）。 ### 仕組み Operator は Helm またはソースからインストールできます。詳細な手順については [charts/operator](https://github.com/wandb/helm-charts/tree/main/charts/operator) を参照してください。 インストールプロセスでは、`controller-manager` という名前のデプロイメントが作成され、`weightsandbiases.apps.wandb.com`（shortName: `wandb`）という名前の [カスタムリソース](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 定義が使用されます。これは単一の `spec` を受け取り、クラスターに適用します。 ```yaml theme={null} apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: weightsandbiases.apps.wandb.com ``` `controller-manager` は、カスタムリソースの spec、リリースチャンネル、およびユーザー定義の設定に基づいて [charts/operator-wandb](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb) をインストールします。この設定仕様の階層構造により、ユーザー側での最大限の設定柔軟性が得られ、W\&B は新しいイメージ、設定、機能、および Helm のアップデートを自動的にリリースできるようになります。 設定オプションについては、[設定仕様の階層構造](#configuration-specification-hierarchy) および [W\&B Operator の設定リファレンス](#configuration-reference-for-wb-operator) を参照してください。 デプロイメントは複数の Pod で構成され、サービスごとに 1 つずつ配置されます。各 Pod の名前には `wandb-` というプレフィックスが付きます。 ### 設定仕様の階層構造 設定仕様は、上位の仕様が下位の仕様を上書きする階層モデルに従います。仕組みは以下の通りです： * **Release Channel Values（リリースチャンネル値）**: この基本レベルの設定は、W\&B がデプロイメント用に設定したリリースチャンネルに基づいてデフォルト値と設定を決定します。 * **User Input Values（ユーザー入力値）**: ユーザーはシステムコンソールを通じて、リリースチャンネル仕様によって提供されたデフォルト設定を上書きできます。 * **Custom Resource Values（カスタムリソース値）**: ユーザーから提供される最高レベルの仕様です。ここで指定された値は、ユーザー入力およびリリースチャンネルの両方の仕様を上書きします。設定オプションの詳細は、[設定リファレンス](#configuration-reference-for-wb-operator) を参照してください。 この階層モデルにより、アップグレードや変更に対して管理可能かつ系統的なアプローチを維持しつつ、多様なニーズを満たすための柔軟でカスタマイズ可能な設定が可能になります。 ## 始める前に 1. インフラストラクチャーの完全な要件については [リファレンスアーキテクチャー](/platform/hosting/self-managed/ref-arch/#infrastructure-requirements) を参照してください。これには以下が含まれます： * ソフトウェアバージョンの要件（Kubernetes, MySQL, Redis, Helm） * ハードウェアの要件（CPU アーキテクチャー、サイジングの推奨事項） * ネットワーク、SSL/TLS、および DNS の要件 1. [有効な W\&B Server ライセンスを取得](/platform/hosting/hosting-options/self-managed#obtain-your-wb-server-license) してください。 2. W\&B Self-Managed のセットアップと設定の詳細な手順については、以下のセクションおよび [ベアメタルインストールガイド](/platform/hosting/self-managed/bare-metal/) を参照してください。インストール方法によっては、追加のソフトウェアのインストールや要件が必要になる場合があります。 ### MySQL データベース W\&B requires an external MySQL database. For production, W\&B strongly recommends using managed database services: * [AWS RDS Aurora MySQL](https://aws.amazon.com/rds/aurora/) * [Google Cloud SQL for MySQL](https://cloud.google.com/sql/mysql) * [Azure Database for MySQL](https://azure.microsoft.com/products/mysql/) Managed database services provide automated backups, monitoring, high availability, patching, and reduce operational overhead. See the [reference architecture](/platform/hosting/self-managed/ref-arch/#mysql) for complete MySQL requirements, including sizing recommendations and configuration parameters. For database creation SQL, see the [bare-metal guide](/platform/hosting/self-managed/bare-metal/#mysql-database). For questions about your deployment's database configuration, contact [support](mailto:support@wandb.com) 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](https://aws.amazon.com/pm/elasticache/) * [Google Cloud Memory Store](https://cloud.google.com/memorystore?hl=en) * [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache) * Redis deployment hosted in your cloud or on-premise infrastructure 外部 Redis インスタンスの設定方法の詳細については、[外部 Redis 設定セクション](#external-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](https://aws.amazon.com/s3/): Object storage service offering industry-leading scalability, data availability, security, and performance. * [Google Cloud Storage](https://cloud.google.com/storage): Managed service for storing unstructured data at scale. * [Azure Blob Storage](https://azure.microsoft.com/products/storage/blobs): Cloud-based object storage solution for storing massive amounts of unstructured data. * [CoreWeave AI Object Storage](https://docs.coreweave.com/docs/products/storage/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](/platform/hosting/self-managed/bare-metal/#object-storage) for detailed setup instructions including CORS configuration and enterprise alternatives. MinIO Open Source is in [maintenance mode](https://github.com/minio/minio) 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](/platform/hosting/self-managed/ref-arch/#object-storage) for complete requirements. Helm 値でのオブジェクトストレージの設定方法の詳細については、[オブジェクトストレージバケット設定セクション](#object-storage-bucket) を参照してください。 ### ネットワーク要件 For a networked deployment, egress to these endpoints is required during *both* installation and runtime: * [https://deploy.wandb.ai](https://deploy.wandb.ai) * [https://charts.wandb.ai](https://charts.wandb.ai) * [https://quay.io](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](/platform/hosting/self-managed/operator-airgapped/). 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 コントローラのオプションおよび設定例については、[リファレンスアーキテクチャーのロードバランサーセクション](/platform/hosting/self-managed/ref-arch/#load-balancer-and-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](https://letsencrypt.org) 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](https://istio.io/latest/docs/reference/config/networking/sidecar/). ### エアギャップ環境でのインストール エアギャップ環境で W\&B Kubernetes Operator をインストールする方法については、[Deploy W\&B in airgapped environment with Kubernetes](/platform/hosting/self-managed/operator-airgapped/) チュートリアルを参照してください。 ### OpenShift Kubernetes クラスター W\&B は、クラウド、オンプレミス、およびエアギャップ環境における [OpenShift Kubernetes clusters](https://www.redhat.com/en/technologies/cloud-computing/openshift) へのデプロイをサポートしています。 W\&B は公式の W\&B Helm チャートを使用したインストールを推奨しています。 #### 非特権ユーザーとしてコンテナを実行する デフォルトでは、コンテナは 999 の `$UID` を使用します。オーケストレーターが非 root ユーザーでのコンテナ実行を必要とする場合は、100000 以上の `$UID` と 0 の `$GID` を指定してください。 ファイルシステムのパーミッションが正しく機能するために、W\&B は root グループ（`$GID=0`）として起動する必要があります。 各 W\&B コンポーネントのセキュリティコンテキストを設定します。例えば、API コンポーネントを設定するには次のようにします： ```yaml theme={null} 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` などの他のコンポーネントに対してカスタムセキュリティコンテキストを設定してください。詳細については、[カスタムセキュリティコンテキスト](#custom-security-context) を参照してください。 ## 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](/platform/hosting/self-managed/bare-metal/) * 切断された環境については [Kubernetes operator for air-gapped instances](/platform/hosting/self-managed/operator-airgapped/) ### Helm CLI による W\&B のデプロイ W\&B は、W\&B Kubernetes Operator を Kubernetes クラスターにデプロイするための Helm チャートを提供しています。このアプローチにより、Helm CLI や ArgoCD のような継続的デリバリーツールを使用して W\&B Server をデプロイできます。前述の要件が整っていることを確認してください。 Helm CLI で W\&B Kubernetes Operator をインストールするには、以下の手順に従います： 1. W\&B Helm リポジトリを追加します。W\&B Helm チャートは W\&B Helm リポジトリで利用可能です： ```shell theme={null} helm repo add wandb https://charts.wandb.ai helm repo update ``` 2. Kubernetes クラスターに Operator をインストールします： ```shell theme={null} helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace ``` 3. W\&B Server のインストールをトリガーするように W\&B Operator カスタムリソースを設定します。W\&B デプロイ設定を含む `operator.yaml` という名前のファイルを作成します。利用可能なすべてのオプションについては、[設定リファレンス](#configuration-reference-for-wb-server) を参照してください。 最小限の設定例は以下の通りです： ```yaml theme={null} 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:// license: eyJhbGnUzaH...j9ZieKQ2x5GGfw bucket: <プロバイダーによって詳細が異なります> mysql: <非表示> ingress: annotations: <非表示> ``` 4. W\&B Server アプリケーションをインストール、設定、および管理できるように、カスタム設定で Operator を起動します： ```shell theme={null} kubectl apply -f operator.yaml ``` デプロイが完了するまで待ちます。これには数分かかります。 5. Web UI を使用してインストールを確認するには、最初の管理者ユーザーアカウントを作成し、[インストールの確認](#verify-the-installation) に記載されている確認手順に従ってください。 ### Helm Terraform モジュールによる W\&B のデプロイ この方法では、一貫性と再現性のために Terraform の Infrastructure-as-code アプローチを活用し、特定の要件に合わせてカスタマイズされたデプロイが可能です。公式の W\&B Helm ベースの Terraform モジュールは [こちら](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb) にあります。 以下のコードは出発点として使用でき、プロダクショングレードのデプロイに必要なすべての設定オプションが含まれています。 ```hcl theme={null} module "wandb" { source = "wandb/wandb/helm" spec = { values = { global = { host = "https://" license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw" bucket = { <プロバイダーによって詳細が異なります> } mysql = { <非表示> } } ingress = { annotations = { "a" = "b" "x" = "y" } } } } } ``` 設定オプションは [設定リファレンス](#configuration-reference-for-wb-operator) で説明されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があることに注意してください。Terraform モジュールは W\&B カスタムリソース定義 (CRD) を作成します。 W\&B 自身が顧客向けに「Dedicated Cloud」インスタンスをデプロイするために Helm Terraform モジュールをどのように使用しているかを確認するには、以下のリンクを参照してください： * [AWS](https://github.com/wandb/terraform-aws-wandb/blob/45e1d746f53e78e73e68f911a1f8cad5408e74b6/main.tf#L225) * [Azure](https://github.com/wandb/terraform-azurerm-wandb/blob/170e03136b6b6fc758102d59dacda99768854045/main.tf#L155) * [Google Cloud](https://github.com/wandb/terraform-google-wandb/blob/49ddc3383df4cefc04337a2ae784f57ce2a2c699/main.tf#L189) ### 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://registry.terraform.io/modules/wandb/wandb/aws/latest) | [https://github.com/wandb/terraform-aws-wandb](https://github.com/wandb/terraform-aws-wandb) | v4.0.0+ | | [Azure](https://github.com/wandb/terraform-azurerm-wandb) | [https://github.com/wandb/terraform-azurerm-wandb](https://github.com/wandb/terraform-azurerm-wandb) | v2.0.0+ | | [Google Cloud](https://github.com/wandb/terraform-google-wandb) | [https://github.com/wandb/terraform-google-wandb](https://github.com/wandb/terraform-google-wandb) | v2.0.0+ | この統合により、最小限のセットアップで W\&B Kubernetes Operator をインスタンスで使用できるようになり、クラウド環境での W\&B Server のデプロイと管理が効率化されます。 これらのモジュールの使用方法に関する詳細な説明については、ドキュメントの [Self-Managed インストールセクション](/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-self-managed-cloud-accounts) を参照してください。 ### インストールの確認 To verify the installation, W\&B recommends using the [W\&B CLI](/models/ref/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: 1. Install the W\&B CLI: ```bash theme={null} pip install wandb ``` 2. Log in to W\&B: ```bash theme={null} wandb login --host=https://YOUR_DNS_DOMAIN ``` For example: ```bash theme={null} wandb login --host=https://wandb.company-name.com ``` 3. Verify the installation: ```bash theme={null} wandb verify ``` A successful installation and fully working W\&B deployment shows the following output: ```console theme={null} 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. ブラウザで W\&B アプリケーションを開き、ログインします。`${HOST_URI}/`（例: `https://wandb.company-name.com/`）を使用して W\&B アプリケーションにログインしてください。 2. コンソールにアクセスします。右上のアイコンをクリックし、**System console** をクリックします。管理者権限を持つユーザーのみが **System console** エントリを表示できます。 System console access オプション 1 が機能しない場合にのみ、以下の手順を使用してコンソールにアクセスすることをお勧めします。 1. ブラウザでコンソールアプリケーションを開きます。前述の URL を開くと、ログイン画面にリダイレクトされます： Direct system console access 2. インストール時に生成される Kubernetes シークレットからパスワードを取得します： ```shell theme={null} kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d ``` パスワードをコピーします。 3. コンソールにログインします。コピーしたパスワードを貼り付け、**Login** をクリックします。 ## W\&B Kubernetes Operator のアップデート このセクションでは、W\&B Kubernetes Operator をアップデートする方法について説明します。 * W\&B Kubernetes Operator をアップデートしても、W\&B Server アプリケーションはアップデートされません。 * W\&B Kubernetes Operator を使用していない Helm チャートを使用している場合は、W\&B Operator をアップデートする前に [こちら](#migrate-Self-Managed-instances-to-wb-operator) の手順に従って移行してください。 以下のコードスニペットをコピーしてターミナルに貼り付けます。 1. まず、[`helm repo update`](https://helm.sh/docs/helm/helm_repo_update/) でリポジトリを更新します： ```shell theme={null} helm repo update ``` 2. 次に、[`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/) で Helm チャートをアップデートします： ```shell theme={null} 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 のデフォルトで推奨されるインストール方法です。ご不明な点がございましたら、[カスタマーサポート](mailto:support@wandb.com) または W\&B 担当チームまでお問い合わせください。 * 公式の W\&B Cloud Terraform モジュールを使用していた場合は、該当するドキュメントに移動し、そこにある手順に従ってください： * [AWS](#migrate-to-operator-based-aws-terraform-modules) * [Google Cloud](#migrate-to-operator-based-google-cloud-terraform-modules) * [Azure](#migrate-to-operator-based-azure-terraform-modules) * [W\&B Non-Operator Helm チャート](https://github.com/wandb/helm-charts/tree/main/charts/wandb) を使用していた場合は、[こちら](#migrate-to-operator-based-helm-chart) に進んでください。 * [Terraform を使用した W\&B Non-Operator Helm チャート](https://registry.terraform.io/modules/wandb/wandb/kubernetes/latest) を使用していた場合は、[こちら](#migrate-to-operator-based-terraform-helm-chart) に進んでください。 * マニフェストを使用して Kubernetes リソースを作成した場合は、[こちら](#migrate-to-operator-based-helm-chart) に進んでください。 ### Operator ベースの AWS Terraform モジュールへの移行 移行プロセスの詳細については、[こちら](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb) を参照してください。 ### Operator ベースの Google Cloud Terraform モジュールへの移行 ご不明な点やサポートが必要な場合は、[カスタマーサポート](mailto:support@wandb.com) または W\&B 担当チームまでお問い合わせください。 ### Operator ベースの Azure Terraform モジュールへの移行 ご不明な点やサポートが必要な場合は、[カスタマーサポート](mailto:support@wandb.com) または W\&B 担当チームまでお問い合わせください。 ### Operator ベースの Helm チャートへの移行 以下の手順に従って、Operator ベースの Helm チャートに移行します： 1. 現在の W\&B 設定を取得します。Operator ベースではないバージョンの Helm チャートでデプロイされていた場合は、次のように値をエクスポートします： ```shell theme={null} helm get values wandb ``` Kubernetes マニフェストでデプロイされていた場合は、次のようにエクスポートします： ```shell theme={null} kubectl get deployment wandb -o yaml ``` これで、次のステップに必要なすべての設定値が揃いました。 2. `operator.yaml` というファイルを作成します。[設定リファレンス](#configuration-reference-for-wb-operator) に記載されている形式に従い、ステップ 1 の値を使用してください。 3. 現在のデプロイメントを 0 Pod にスケールします。このステップで現在のデプロイメントを停止します。 ```shell theme={null} kubectl scale --replicas=0 deployment wandb ``` 4. Helm チャートリポジトリを更新します： ```shell theme={null} helm repo update ``` 5. 新しい Helm チャートをインストールします： ```shell theme={null} helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace ``` 6. 新しい Helm チャートを設定し、W\&B アプリケーションのデプロイをトリガーします。新しい設定を適用します。 ```shell theme={null} kubectl apply -f operator.yaml ``` デプロイが完了するまで数分かかります。 7. インストールを確認します。[インストールの確認](#verify-the-installation) の手順に従い、すべてが動作していることを確認してください。 8. 旧いインストールを削除します。旧い Helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。 ### Operator ベースの Terraform Helm チャートへの移行 以下の手順に従って、Operator ベースの Helm チャートに移行します： 1. Terraform 設定の準備。Terraform 設定内の旧いデプロイメントの Terraform コードを、[こちら](#deploy-wb-with-helm-terraform-module) で説明されているものに置き換えます。以前と同じ変数を設定してください。.tfvars ファイルがある場合は変更しないでください。 2. Terraform 実行。terraform init, plan, apply を実行します。 3. インストールを確認します。[インストールの確認](#verify-the-installation) の手順に従い、すべてが動作していることを確認してください。 4. 旧いインストールを削除します。旧い Helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。 ## W\&B Server の設定リファレンス このセクションでは、W\&B Server アプリケーションの設定オプションについて説明します。アプリケーションは、[WeightsAndBiases](#how-it-works) という名前のカスタムリソース定義として設定を受け取ります。一部の設定オプションは以下の設定で公開されており、一部は環境変数として設定する必要があります。 ドキュメントには [基本](/platform/hosting/env-vars/) と [詳細](/platform/hosting/iam/advanced_env_vars/) の 2 つの環境変数リストがあります。必要な設定オプションが Helm チャートで公開されていない場合にのみ、環境変数を使用してください。 ### 基本的な例 この例では、W\&B に最低限必要な値のセットを定義します。より現実的なプロダクション環境の例については、[完全な例](#complete-example) を参照してください。 この YAML ファイルは、バージョン、環境変数、データベースなどの外部リソース、およびその他の必要な設定を含む、W\&B デプロイメントの望ましい状態を定義します。 ```yaml theme={null} 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:// license: eyJhbGnUzaH...j9ZieKQ2x5GGfw bucket: <プロバイダーによって詳細が異なります> mysql: <非表示> ingress: annotations: <非表示> ``` すべての値のセットは [W\&B Helm リポジトリ](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml) で確認できます。**上書きが必要な値のみを変更してください**。 ### 完全な例 この例では、Google Cloud Storage を使用して Google Cloud Anthos に W\&B をデプロイする設定を示します： ```yaml theme={null} 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 ```yaml theme={null} # プロトコル付きの FQDN を提供 global: # ホスト名の例。ご自身のものに置き換えてください host: https://wandb.example.com ``` ### オブジェクトストレージ (bucket) **AWS** ```yaml theme={null} global: bucket: provider: "s3" name: "" kmsKey: "" region: "" ``` **Google Cloud** ```yaml theme={null} global: bucket: provider: "gcs" name: "" ``` **Azure** ```yaml theme={null} global: bucket: provider: "az" name: "" secretKey: "" ``` **その他のプロバイダー (Minio, Ceph など)** その他の S3 互換プロバイダーについては、バケット設定を次のように設定します： ```yaml theme={null} 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` を参照する場合： ```yaml theme={null} 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 ```yaml theme={null} global: mysql: # 設定例。ご自身のものに置き換えてください host: db.example.com port: 3306 database: wandb_local user: wandb password: 8wtX6cJH...ZcUarK4zZGjpV ``` シークレットから `password` を参照する場合： ```yaml theme={null} global: mysql: # 設定例。ご自身のものに置き換えてください host: db.example.com port: 3306 database: wandb_local user: wandb passwordSecret: name: database-secret passwordKey: MYSQL_WANDB_PASSWORD ``` ### ライセンス ```yaml theme={null} global: # ライセンスの例。ご自身のものに置き換えてください license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi ``` シークレットから `license` を参照する場合： ```yaml theme={null} global: licenseSecret: name: license-secret key: CUSTOMER_WANDB_LICENSE ``` ### Ingress Ingress クラスを特定するには、こちらの FAQ [エントリ](#how-to-identify-the-kubernetes-ingress-class) を参照してください。 **TLS なし** ```yaml theme={null} global: # 重要: Ingress は YAML 内で ‘global’ と同レベル（子ではない）です ingress: class: "" ``` **TLS あり** 証明書を含むシークレットを作成します ```console theme={null} kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt ``` Ingress 設定でシークレットを参照します ```yaml theme={null} global: # 重要: Ingress は YAML 内で ‘global’ と同レベル（子ではない）です ingress: class: "" annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" tls: - secretName: wandb-ingress-tls hosts: - ``` Nginx の場合、以下のアノテーションを追加する必要がある場合があります： ``` ingress: annotations: nginx.ingress.kubernetes.io/proxy-body-size: 0 ``` ### カスタム Kubernetes ServiceAccounts W\&B Pod を実行するためにカスタム Kubernetes サービスアカウントを指定します。 以下のスニペットは、デプロイの一部として指定された名前でサービスアカウントを作成します： ```yaml theme={null} app: serviceAccount: name: custom-service-account create: true parquet: serviceAccount: name: custom-service-account create: true global: ... ``` サブシステム "app" と "parquet" は指定されたサービスアカウントで実行されます。他のサブシステムはデフォルトのサービスアカウントで実行されます。 サービスアカウントがクラスター上に既に存在する場合は、`create: false` を設定します： ```yaml theme={null} app: serviceAccount: name: custom-service-account create: false parquet: serviceAccount: name: custom-service-account create: false global: ... ``` app、parquet、console などの異なるサブシステムでサービスアカウントを指定できます： ```yaml theme={null} app: serviceAccount: name: custom-service-account create: true console: serviceAccount: name: custom-service-account create: true global: ... ``` サブシステム間で異なるサービスアカウントを使用することも可能です： ```yaml theme={null} app: serviceAccount: name: custom-service-account create: false console: serviceAccount: name: another-custom-service-account create: true global: ... ``` ### 外部 Redis ```yaml theme={null} redis: install: false global: redis: host: "" port: 6379 password: "" parameters: {} caCert: "" ``` シークレットから `password` を参照する場合： ```console theme={null} kubectl create secret generic redis-secret --from-literal=redis-password=supersecret ``` 以下の設定で参照します： ```yaml theme={null} 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 を構成します： ```yaml theme={null} 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 ``` このレガシーなアプローチは現在推奨されていません。このセクションは参照用に提供されています。 **TLS なし** ```yaml theme={null} global: ldap: enabled: true # "ldap://" または "ldaps://" を含む LDAP サーバーアドレス host: # ユーザーを検索するために使用する LDAP 検索ベース baseDN: # バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合） bindDN: # バインドに使用する LDAP パスワードを含むシークレット名とキー（匿名バインドを使用しない場合） bindPW: # メールおよびグループ ID 属性名の LDAP 属性。カンマ区切りの文字列値。 attributes: # LDAP グループ許可リスト groupAllowList: # LDAP TLS を有効にする tls: false ``` **TLS あり** LDAP TLS 証明書の設定には、証明書の内容であらかじめ作成された ConfigMap が必要です。 ConfigMap を作成するには、以下のコマンドを使用します： ```console theme={null} kubectl create configmap ldap-tls-cert --from-file=certificate.crt ``` そして、以下の例のように YAML で ConfigMap を使用します： ```yaml theme={null} global: ldap: enabled: true # "ldap://" または "ldaps://" を含む LDAP サーバーアドレス 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 ```yaml theme={null} global: auth: sessionLengthHours: 720 oidc: clientId: "" secret: "" # IdP が必要な場合にのみ含めます authMethod: "" issuer: "" ``` `authMethod` はオプションです。 ### SMTP ```yaml theme={null} global: email: smtp: host: "" port: 587 user: "" password: "" ``` ### 環境変数 ```yaml theme={null} global: extraEnv: GLOBAL_ENV: "example" ``` ### カスタム認証局 (CA) `customCACerts` はリスト形式で、複数の証明書を指定できます。`customCACerts` で指定された認証局は、W\&B Server アプリケーションにのみ適用されます。 ```yaml theme={null} 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 に保存することもできます： ```yaml theme={null} global: caCertsConfigMap: custom-ca-certs ``` ConfigMap は以下のようになります： ```yaml theme={null} 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 コンポーネントは、以下の形式のカスタムセキュリティコンテキスト設定をサポートしています： ```yaml theme={null} 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` セクションを追加します： ```yaml theme={null} 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 リポジトリ](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml) で確認できます。 ### カスタム CA カスタム認証局 (`customCACerts`) はリスト形式で、複数の証明書を指定できます。これらが追加された場合、W\&B Kubernetes Operator (`wandb-controller-manager`) にのみ適用されます。 ```yaml theme={null} 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 に保存することもできます： ```yaml theme={null} caCertsConfigMap: custom-ca-certs ``` ConfigMap は以下のようになります： ```yaml theme={null} 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 管理コンソールへのアクセス](#access-the-wb-management-console) を参照してください。 ### Ingress が機能しない場合に W\&B Operator コンソールにアクセスする方法 Kubernetes クラスターに到達可能なホストで以下のコマンドを実行します： ```console theme={null} kubectl port-forward svc/wandb-console 8082 ``` ブラウザで `https://localhost:8082/console` にアクセスします。 パスワードの取得方法については、[W\&B Kubernetes Operator 管理コンソールへのアクセス](#access-the-wb-management-console)（オプション 2）を参照してください。 ### W\&B Server のログを表示する方法 アプリケーション Pod の名前は **wandb-app-xxx** です。 ```console theme={null} kubectl get pods kubectl logs wandb-XXXXX-XXXXX ``` ### Kubernetes の Ingress クラスを特定する方法 クラスターにインストールされている Ingress クラスは、以下のコマンドで確認できます。 ```console theme={null} kubectl get ingressclass ```