W&B Platform

• 1: Deployment options
• 1.1: Use W&B Multi-tenant SaaS
• 1.2: Dedicated Cloud
• 1.2.1: Supported Dedicated Cloud regions
• 1.2.2: Export data from Dedicated cloud
• 1.3: Self-managed
• 1.3.1: Reference Architecture
• 1.3.2: Run W&B Server on Kubernetes
• 1.3.2.1: Kubernetes operator for air-gapped instances
• 1.3.3: Install on public cloud
• 1.3.3.1: Deploy W&B Platform on AWS
• 1.3.3.2: Deploy W&B Platform on GCP
• 1.3.3.3: Deploy W&B Platform on Azure
• 1.3.4: Deploy W&B Platform On-premises
• 1.3.5: Update W&B license and version
• 2: Identity and access management (IAM)
• 2.1: Authentication
• 2.1.1: Configure SSO with LDAP
• 2.1.2: Configure SSO with OIDC
• 2.1.3: Use federated identities with SDK
• 2.1.4: Use service accounts to automate workflows
• 2.2: Access management
• 2.2.1: Manage your organization
• 2.2.2: Manage access control for projects
• 2.3: Automate user and team management
• 2.4: Manage users, groups, and roles with SCIM
• 2.5: Advanced IAM configuration
• 3: Data security
• 3.1: Bring your own bucket (BYOB)
• 3.2: Access BYOB using pre-signed URLs
• 3.3: Configure IP allowlisting for Dedicated Cloud
• 3.4: Configure private connectivity to Dedicated Cloud
• 3.5: Data encryption in Dedicated cloud
• 4: Configure privacy settings
• 5: Monitoring and usage
• 5.1: Track user activity with audit logs
• 5.2: Use Prometheus monitoring
• 5.3: Configure Slack alerts
• 5.4: View organization dashboard
• 6: Configure SMTP
• 7: Configure environment variables
• 8: Release process for W&B Server

1 - Deployment options

1.1 - Use W&B Multi-tenant SaaS

W&B Multi-tenant Cloud は、W&B の Google Cloud Platform (GCP) アカウント内の GPC の北米リージョン にデプロイされた、フルマネージドのプラットフォームです。 W&B Multi-tenant Cloud は、GCP の自動スケーリングを利用して、トラフィックの増減に基づいてプラットフォームが適切にスケーリングされるようにします。

データセキュリティ

エンタープライズプラン以外のユーザーの場合、すべての data は共有クラウドストレージにのみ保存され、共有クラウドコンピューティングサービスで処理されます。料金プランによっては、ストレージ制限が適用される場合があります。

エンタープライズプランのユーザーは、セキュアストレージコネクタを使用して、独自の bucket (BYOB) を持ち込む ことができます。team level で、model、datasets などのファイルを保存できます。複数の Teams に対して 1 つの bucket を設定することも、異なる W&B Teams に対して個別の buckets を使用することもできます。team に対してセキュアストレージコネクタを設定しない場合、その data は共有クラウドストレージに保存されます。

Identity and access management (IAM)

エンタープライズプランをご利用の場合、W&B Organization でセキュアな認証と効果的な承認のために、identity and access managements 機能を使用できます。 Multi-tenant Cloud の IAM では、次の機能が利用可能です。

• OIDC または SAML による SSO 認証。 Organization の SSO を設定する場合は、W&B team またはサポートにお問い合わせください。
• Organization のスコープ内および team 内で、適切な user ロールを設定 します。
• W&B project のスコープを定義して、制限付き projects で、誰が W&B runs を表示、編集、送信できるかを制限します。

モニター

Organization 管理者は、アカウントビューの [Billing] タブから、アカウントの使用状況と請求を管理できます。 Multi-tenant Cloud 上の共有クラウドストレージを使用している場合、管理者は organization 内の異なる Teams 間でストレージ使用量を最適化できます。

メンテナンス

W&B Multi-tenant Cloud は、マルチテナントのフルマネージドプラットフォームです。 W&B Multi-tenant Cloud は W&B によって管理されているため、W&B プラットフォームのプロビジョニングとメンテナンスのオーバーヘッドとコストは発生しません。

コンプライアンス

Multi-tenant Cloud のセキュリティコントロールは、定期的 内部および外部で監査されます。 SOC2 レポートおよびその他のセキュリティとコンプライアンスに関するドキュメントをリクエストするには、W&B Security Portal を参照してください。

次のステップ

エンタープライズ機能以外をお探しの場合は、Multi-tenant Cloud に直接アクセス してください。エンタープライズプランを開始するには、このフォーム を送信してください。

1.2 - Dedicated Cloud

専用クラウド (シングルテナントSaaS)

W&B 専用クラウド は、W&B の AWS、GCP、または Azure クラウドアカウントにデプロイされた、シングルテナントで完全に管理されたプラットフォームです。各 専用クラウド インスタンスは、他の W&B 専用クラウド インスタンスから独立したネットワーク、コンピューティング、ストレージを持っています。お客様の W&B 固有の メタデータ と データ は、独立したクラウドストレージに保存され、独立したクラウドコンピューティングサービスを使用して処理されます。

W&B 専用クラウド は、各クラウドプロバイダーの複数のグローバルリージョンで利用可能です。

データセキュリティ

セキュアストレージコネクタを使用して、インスタンスおよび Team レベルで、お客様自身の バケット (BYOB) を持ち込み、モデル、データセット などのファイル を保存できます。

W&B マルチテナント Cloud と同様に、複数の Team に対して単一の バケット を構成するか、異なる Team に対して別々の バケット を使用できます。Team に対してセキュアストレージコネクタを構成しない場合、その データ はインスタンスレベルの バケット に保存されます。

セキュアストレージコネクタによる BYOB に加えて、IP 許可リストを利用して、信頼できるネットワークロケーションからのみ 専用クラウド インスタンスへの アクセス を制限できます。

また、クラウドプロバイダーのセキュアな接続ソリューションを使用して、専用クラウド インスタンスにプライベートに接続することもできます。

ID と アクセス 管理 (IAM)

W&B Organization でセキュアな認証と効果的な認可のために、ID と アクセス 管理機能を使用します。専用クラウド インスタンスの IAM では、次の機能が利用可能です。

• OpenID Connect (OIDC) を使用した SSOまたはLDAPで認証します。
• Organization のスコープ内および Team 内で適切な ユーザー ロールを構成します。
• W&B プロジェクト のスコープを定義して、制限付き プロジェクトで、誰が W&B の run を表示、編集、および送信できるかを制限します。
• ID フェデレーションで JSON Web Tokens を利用して、W&B API に アクセス します。

モニター

監査 ログを使用して、Team 内の ユーザー アクティビティを追跡し、エンタープライズガバナンス要件に準拠します。また、W&B Organization Dashboardで 専用クラウド インスタンスの Organization の使用状況を表示できます。

メンテナンス

W&B マルチテナント Cloud と同様に、専用クラウド では W&B プラットフォーム のプロビジョニングとメンテナンスのオーバーヘッドとコストは発生しません。

W&B が 専用クラウド での更新をどのように管理するかを理解するには、サーバー リリース プロセスを参照してください。

コンプライアンス

W&B 専用クラウド のセキュリティコントロールは、定期的 に内部および外部で監査されます。製品評価の演習のためにセキュリティおよびコンプライアンスドキュメントをリクエストするには、W&B Security Portalを参照してください。

移行オプション

自己管理インスタンスまたはマルチテナント Cloudからの 専用クラウド への移行がサポートされています。

次のステップ

専用クラウド の使用にご興味がある場合は、このフォームを送信してください。

1.2.1 - Supported Dedicated Cloud regions

AWS、GCP、および Azure は、世界中の複数の場所でクラウドコンピューティングサービスをサポートしています。グローバルリージョンは、データ所在地とコンプライアンス、レイテンシー、コスト効率などに関連する要件を満たすのに役立ちます。W&B は、専用クラウドで利用可能な多くのグローバルリージョンをサポートしています。

サポートされている AWS リージョン

次の表は、W&B が現在専用クラウドインスタンスでサポートしている AWS リージョン を示しています。

AWS リージョンの詳細については、AWS ドキュメントの リージョン、アベイラビリティーゾーン、およびローカルゾーン を参照してください。

AWS リージョンを選択する際に考慮すべき要素の概要については、ワークロードのリージョンを選択する際に考慮すべきこと を参照してください。

サポートされている GCP リージョン

次の表は、W&B が現在専用クラウドインスタンスでサポートしている GCP リージョン を示しています。

GCP リージョンの詳細については、GCP ドキュメントの リージョンとゾーン を参照してください。

サポートされている Azure リージョン

次の表は、W&B が現在専用クラウドインスタンスでサポートしている Azure リージョン を示しています。

Azure リージョンの詳細については、Azure ドキュメントの Azure geography を参照してください。

1.2.2 - Export data from Dedicated cloud

もし、 専用クラウド インスタンスで管理されている全てのデータをエクスポートしたい場合は、W&B SDK API を使用して、runs、metrics、Artifacts などを抽出できます。詳しくは、インポートとエクスポート API を参照してください。以下の表は、主要なエクスポートの ユースケース をまとめたものです。

Secure Storage Connector で 専用クラウド に保存されている Artifacts を管理している場合、W&B SDK API を使用して Artifacts をエクスポートする必要はないかもしれません。

1.3 - Self-managed

セルフマネージドクラウドまたはオンプレミスインフラストラクチャーの使用

AWS、GCP、または Azure クラウドアカウント または オンプレミスインフラストラクチャー に W&B Server をデプロイします。

お客様の IT/DevOps/MLOps チームは、お客様のデプロイメントのプロビジョニング、アップグレードの管理、およびセルフマネージドな W&B Server インスタンスの継続的なメンテナンスを担当します。

セルフマネージドクラウドアカウント内への W&B Server のデプロイ

W&B は、W&B Server を AWS、GCP、または Azure クラウドアカウントにデプロイするために、公式の W&B Terraform スクリプトを使用することを推奨します。

AWS, GCP または Azure での W&B Server のセットアップ方法の詳細については、特定のクラウドプロバイダーのドキュメントを参照してください。

オンプレミスインフラストラクチャーへの W&B Server のデプロイ

オンプレミスインフラストラクチャーに W&B Server をセットアップするには、いくつかのインフラストラクチャーコンポーネントを設定する必要があります。これらのコンポーネントには、以下が含まれますが、これらに限定されません。

• (強く推奨) Kubernetes cluster
• MySQL 8 database cluster
• Amazon S3 互換 object storage
• Redis cache cluster

オンプレミスインフラストラクチャーへの W&B Server のインストール方法の詳細については、オンプレミスインフラストラクチャーへのインストール を参照してください。W&B は、さまざまなコンポーネントに関する推奨事項を提供し、インストールプロセスを通じてガイダンスを提供できます。

カスタムクラウドプラットフォームへの W&B Server のデプロイ

AWS、GCP、または Azure ではないクラウドプラットフォームに W&B Server をデプロイできます。そのための要件は、オンプレミスインフラストラクチャー にデプロイする場合と同様です。

W&B Server のライセンスの取得

W&B サーバーの設定を完了するには、W&B trial ライセンスが必要です。Deploy Manager を開いて、無料の trial ライセンスを生成してください。

URL をクリックすると、Get a License for W&B Local フォームにリダイレクトされます。次の情報を提供してください。

1. Choose Platform ステップで、デプロイメントタイプを選択します。
2. Basic Information ステップで、ライセンスの所有者を選択するか、新しい組織を追加します。
3. Get a License ステップの Name of Instance フィールドにインスタンスの名前を入力し、必要に応じて Description フィールドに説明を入力します。
4. Generate License Key ボタンを選択します。

ページに、デプロイメントの概要と、インスタンスに関連付けられたライセンスが表示されます。

1.3.1 - Reference Architecture

このページでは、Weights & Biases のデプロイメントのリファレンスアーキテクチャについて説明し、プラットフォームのプロダクションデプロイメントをサポートするために推奨されるインフラストラクチャとリソースの概要を示します。

Weights & Biases (W&B) に選択したデプロイメント環境に応じて、さまざまなサービスがデプロイメントの回復性を高めるのに役立ちます。

たとえば、主要なクラウドプロバイダーは、データベースの構成、メンテナンス、高可用性、および回復性の複雑さを軽減するのに役立つ、堅牢なマネージドデータベースサービスを提供しています。

このリファレンスアーキテクチャは、一般的なデプロイメントシナリオに対応し、最適なパフォーマンスと信頼性を実現するために、W&B のデプロイメントをクラウドベンダーサービスと統合する方法を示しています。

開始する前に

プロダクション環境でアプリケーションを実行するには、独自の課題があり、W&B も例外ではありません。プロセスの合理化を目指していますが、固有のアーキテクチャと設計上の決定によっては、特定の複雑さが発生する可能性があります。通常、プロダクションデプロイメントの管理には、ハードウェア、オペレーティングシステム、ネットワーク、ストレージ、セキュリティ、W&B プラットフォーム自体、およびその他の依存関係を含む、さまざまなコンポーネントの監視が含まれます。この責任は、環境の初期設定とその継続的なメンテナンスの両方に及びます。

W&B を使用した自己管理アプローチが、チームと特定の要件に適しているかどうかを慎重に検討してください。

プロダクショングレードのアプリケーションを実行および保守する方法をしっかりと理解しておくことは、自己管理の W&B をデプロイする前に重要な前提条件となります。チームが支援を必要とする場合は、当社の Professional Services チームとパートナーが、実装と最適化のサポートを提供します。

W&B を自分で管理する代わりに、W&B を実行するためのマネージドソリューションの詳細については、W&B Multi-tenant Cloud および W&B Dedicated Cloud を参照してください。

インフラストラクチャ

アプリケーション層

アプリケーション層は、ノード障害に対する回復性を持つ、マルチノード Kubernetes クラスターで構成されています。Kubernetes クラスターは、W&B の pod を実行および保守します。

ストレージ層

ストレージ層は、MySQL データベースとオブジェクトストレージで構成されています。MySQL データベースはメタデータを格納し、オブジェクトストレージはモデルやデータセットなどの Artifacts を格納します。

インフラストラクチャ要件

Kubernetes

W&B Server アプリケーションは、複数の pod をデプロイする Kubernetes Operator としてデプロイされます。このため、W&B には次のものを持つ Kubernetes クラスターが必要です。

• 完全に構成され、機能する Ingress コントローラー。
• Persistent Volumes をプロビジョニングする機能。

MySQL

W&B は、メタデータを MySQL データベースに格納します。データベースのパフォーマンスとストレージ要件は、モデルパラメータと関連するメタデータの形状によって異なります。たとえば、トレーニング run を追跡するほどデータベースのサイズが大きくなり、run テーブル、ユーザー Workspace 、および Reports のクエリに基づいてデータベースの負荷が増加します。

自己管理の MySQL データベースをデプロイする場合は、以下を検討してください。

• バックアップ。データベースを別の施設に定期的にバックアップする必要があります。W&B は、少なくとも 1 週間の保持期間で毎日バックアップすることをお勧めします。
• パフォーマンス。サーバーが実行されているディスクは高速である必要があります。W&B は、SSD または高速化された NAS でデータベースを実行することをお勧めします。
• 監視。データベースの負荷を監視する必要があります。CPU 使用率がシステムの 40% を超えて 5 分以上維持されている場合は、サーバーのリソースが不足している可能性が高いことを示しています。
• 可用性。可用性と耐久性の要件に応じて、プライマリサーバーからリアルタイムですべての更新をストリーミングし、プライマリサーバーがクラッシュまたは破損した場合にフェイルオーバーに使用できる、別のマシン上のホットスタンバイを構成することができます。

オブジェクトストレージ

W&B には、次のいずれかにデプロイされた、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。

• Amazon S3
• Azure Cloud Storage
• Google Cloud Storage
• Amazon S3 と互換性のあるストレージサービス

バージョン

ネットワーク

ネットワーク化されたデプロイメントでは、インストール時と実行時の_両方_で、これらのエンドポイントへの出力が必要です。

• https://deploy.wandb.ai
• https://charts.wandb.ai
• https://docker.io
• https://quay.io
• https://gcr.io

エアギャップデプロイメントの詳細については、エアギャップインスタンス用の Kubernetes operator を参照してください。 トレーニングインフラストラクチャと、 Experiments のニーズを追跡する各システムには、W&B とオブジェクトストレージへのアクセスが必要です。

DNS

W&B デプロイメントの完全修飾ドメイン名 (FQDN) は、A レコードを使用して、イングレス/ロードバランサーの IP アドレスに解決される必要があります。

SSL/TLS

W&B では、クライアントとサーバー間の安全な通信のために、有効な署名付き SSL/TLS 証明書が必要です。SSL/TLS 終端は、イングレス/ロードバランサーで発生する必要があります。W&B Server アプリケーションは、SSL または TLS 接続を終端しません。

注意: W&B は、自己署名証明書とカスタム CA の使用を推奨していません。

サポートされている CPU アーキテクチャ

W&B は、Intel (x86) CPU アーキテクチャで実行されます。ARM はサポートされていません。

インフラストラクチャのプロビジョニング

Terraform は、プロダクション用に W&B をデプロイする推奨される方法です。Terraform を使用して、必要なリソース、他のリソースへの参照、および依存関係を定義します。W&B は、主要なクラウドプロバイダー向けの Terraform モジュールを提供しています。詳細については、自己管理のクラウドアカウント内で W&B Server をデプロイする を参照してください。

サイジング

デプロイメントを計画する際の開始点として、次の一般的なガイドラインを使用してください。W&B は、新しいデプロイメントのすべてのコンポーネントを注意深く監視し、観察された使用パターンに基づいて調整することをお勧めします。時間の経過とともにプロダクションデプロイメントを監視し続け、最適なパフォーマンスを維持するために必要に応じて調整します。

Models のみ

Kubernetes

数値は Kubernetes ワーカーノードごとの値です。

MySQL

数値は MySQL ノードごとの値です。

Weave のみ

Kubernetes

数値は Kubernetes ワーカーノードごとの値です。

MySQL

数値は MySQL ノードごとの値です。

Models と Weave

Kubernetes

数値は Kubernetes ワーカーノードごとの値です。

MySQL

数値は MySQL ノードごとの値です。

クラウドプロバイダーのインスタンス推奨事項

サービス

マシンタイプ

これらの推奨事項は、クラウドインフラストラクチャでの W&B の自己管理デプロイメントの各ノードに適用されます。

AWS

GCP

Azure

1.3.2 - Run W&B Server on Kubernetes

W&B Kubernetes Operator

W&B Kubernetes Operatorを使用すると、Kubernetes上でのW&B Serverのデプロイ、管理、トラブルシューティング、およびスケーリングを簡素化できます。このOperatorは、W&Bインスタンスのスマートアシスタントとして考えることができます。

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

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

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

従来、W&B アプリケーションは、Kubernetes クラスター内の単一のデプロイメントおよび pod として、または単一の Docker コンテナとしてデプロイされていました。W&B は、データベースと Object Store を外部化することを推奨しており、今後も推奨していきます。データベースと Object Store を外部化すると、アプリケーションの状態が分離されます。

アプリケーションの成長に伴い、モノリシックなコンテナから分散システム（マイクロサービス）に進化する必要性が明らかになりました。この変更により、バックエンドロジックの処理が容易になり、Kubernetes インフラストラクチャの機能がシームレスに組み込まれます。分散システムは、W&B が依存する追加機能に不可欠な新しいサービスのデプロイもサポートします。

2024年以前は、Kubernetes関連の変更を行うには、terraform-kubernetes-wandb Terraformモジュールを手動で更新する必要がありました。Terraformモジュールを更新することで、クラウドプロバイダー間での互換性が確保され、必要なTerraform変数が構成され、バックエンドまたはKubernetesレベルの変更ごとにTerraformが適用されます。

このプロセスは、W&Bサポートが各顧客のTerraformモジュールのアップグレードを支援する必要があったため、スケーラブルではありませんでした。

解決策は、中央のdeploy.wandb.aiサーバーに接続して、特定のリリースチャネルの最新の仕様変更をリクエストし、適用する operator を実装することでした。ライセンスが有効である限り、更新が受信されます。Helmは、W&B operator のデプロイメントメカニズムと、W&B Kubernetesスタックのすべての構成テンプレートを operator が処理する手段の両方として使用されます（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は、カスタムリソースの仕様、リリースチャネル、およびユーザー定義の構成に基づいて、charts/operator-wandbをインストールします。構成仕様の階層により、ユーザー側で最大限の構成の柔軟性が実現し、W&B は新しいイメージ、構成、機能、および Helm の更新を自動的にリリースできます。

構成オプションについては、構成仕様の階層および構成リファレンスを参照してください。

構成仕様の階層

構成仕様は、高レベルの仕様が低レベルの仕様をオーバーライドする階層モデルに従います。その仕組みは次のとおりです。

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

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

W&B Kubernetes Operatorを使用するための要件

W&B Kubernetes operator で W&B をデプロイするには、次の要件を満たす必要があります。

リファレンスアーキテクチャを参照してください。さらに、有効な W&B Server ライセンスを取得してください。

自己管理型インストールを設定および構成する方法の詳細な説明については、こちらのガイドを参照してください。

インストール方法によっては、次の要件を満たす必要がある場合があります。

• Kubectl がインストールされ、正しい Kubernetes クラスターコンテキストで構成されている。
• Helm がインストールされている。

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

エアギャップ環境に W&B Kubernetes Operator をインストールする方法については、Kubernetes を使用したエアギャップ環境での W&B のデプロイのチュートリアルを参照してください。

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

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

次のいずれかを選択してください。

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

Helm CLI を使用した W&B のデプロイ

W&B は、W&B Kubernetes operator を Kubernetes クラスターにデプロイするための Helm Chart を提供します。このアプローチを使用すると、Helm CLI または ArgoCD などの継続的デリバリー ツールで W&B Server をデプロイできます。上記の要件が満たされていることを確認してください。

Helm CLI を使用して W&B Kubernetes Operator をインストールするには、次の手順に従います。

1. W&B Helm リポジトリを追加します。W&B Helm チャートは、W&B Helm リポジトリで入手できます。次のコマンドを使用してリポジトリを追加します。

helm repo add wandb https://charts.wandb.ai
helm repo update

2. Kubernetes クラスターに Operator をインストールします。以下をコピーして貼り付けます。

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

3. W&B Server のインストールをトリガーするように W&B operator カスタムリソースを構成します。この構成例を 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 アプリケーションをインストールおよび構成できるように、カスタム構成で Operator を起動します。

   kubectl apply -f operator.yaml
   

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

4. 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 = {
          <details depend on the provider>
        }

        mysql = {
          <redacted>
        }
      }

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

構成オプションは構成リファレンスで説明されているものと同じですが、構文は HashiCorp Configuration Language（HCL）に従う必要があることに注意してください。Terraform モジュールは、W&B カスタムリソース定義（CRD）を作成します。

W&B&Biases 自体が Helm Terraform モジュールを使用して顧客向けの「Dedicated cloud」インストールをデプロイする方法については、次のリンクを参照してください。

• AWS
• Azure
• GCP

W&B Cloud Terraform モジュールを使用した W&B のデプロイ

W&B は、AWS、GCP、および Azure 用の一連の Terraform モジュールを提供します。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースなど、インフラストラクチャ全体と W&B Server アプリケーションをデプロイします。W&B Kubernetes Operator は、次のバージョンの公式 W&B クラウド固有の Terraform モジュールですでに事前構築されています。

この統合により、最小限のセットアップでインスタンスに W&B Kubernetes Operator を使用する準備が整い、クラウド環境での W&B Server のデプロイと管理への合理化されたパスが提供されます。

これらのモジュールの使用方法の詳細については、ドキュメントの自己管理型インストールセクションのこのセクションを参照してください。

インストールの検証

インストールを検証するために、W&B はW&B CLIを使用することをお勧めします。verify コマンドは、すべてのコンポーネントと構成を検証するいくつかのテストを実行します。

インストールを検証するには、次の手順に従います。

1. W&B CLI をインストールします。

   pip install wandb
   

2. W&B にログインします。

   wandb login --host=https://YOUR_DNS_DOMAIN
   

   例：

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

3. インストールを検証します。

   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 operator には、管理コンソールが付属しています。これは${HOST_URI}/consoleにあります。たとえば、https://wandb.company-name.com/ console などです。

管理コンソールにログインするには、次の2つの方法があります。

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

W&B Kubernetes operator の更新

このセクションでは、W&B Kubernetes operator を更新する方法について説明します。

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

1. まず、helm repo updateでリポジトリを更新します。

   helm repo update
   

2. 次に、helm upgradeで Helm チャートを更新します。

   helm upgrade operator wandb/operator -n wandb-cr --reuse-values
   

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

W&B Kubernetes operator を使用する場合は、W&B Server アプリケーションを更新する必要はなくなりました。

operator は、W&B のソフトウェアの新しいバージョンがリリースされると、W&B Server アプリケーションを自動的に更新します。

自己管理型インスタンスの W&B Operator への移行

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

• 公式の W&B Cloud Terraform Modules を使用した場合は、適切なドキュメントに移動し、そこに記載されている手順に従ってください。
  • AWS
  • GCP
  • Azure
• W&B Non-Operator Helm chart を使用した場合は、こちらに進んでください。
• Terraform を使用した W&B Non-Operator Helm chart を使用した場合は、こちらに進んでください。
• マニフェストを使用して Kubernetes リソースを作成した場合は、こちらに進んでください。

Operator ベースの AWS Terraform Modules への移行

移行プロセスの詳細については、こちらに進んでください。

Operator ベースの GCP Terraform Modules への移行

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

Operator ベースの Azure Terraform Modules への移行

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

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

Operator ベースの Helm チャートに移行するには、次の手順に従います。

1. 現在の W&B 構成を取得します。W&B が非 operator ベースのバージョンの Helm チャートでデプロイされた場合は、次のように値をエクスポートします。

   helm get values wandb
   

   W&B が Kubernetes マニフェストでデプロイされた場合は、次のように値をエクスポートします。

   kubectl get deployment wandb -o yaml
   

   これで、次のステップに必要なすべての構成値が揃いました。

2. operator.yaml というファイルを作成します。構成リファレンスで説明されている形式に従ってください。ステップ 1 の値を使用します。

3. 現在のデプロイメントを 0 pod にスケールします。このステップでは、現在のデプロイメントを停止します。

   kubectl scale --replicas=0 deployment wandb
   

4. Helm チャートリポジトリを更新します。

   helm repo update
   

5. 新しい Helm チャートをインストールします。

   helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
   

6. 新しい Helm チャートを構成し、W&B アプリケーションのデプロイメントをトリガーします。新しい構成を適用します。

   kubectl apply -f operator.yaml
   

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

7. インストールを検証します。インストールの検証の手順に従って、すべてが正常に動作することを確認します。

8. 古いインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

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

Operator ベースの Helm チャートに移行するには、次の手順に従います。

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

W&B Server の構成リファレンス

このセクションでは、W&B Server アプリケーションの構成オプションについて説明します。アプリケーションは、WeightsAndBiasesというカスタムリソース定義として構成を受け取ります。一部の構成オプションは以下の構成で公開され、一部は環境変数として設定する必要があります。

ドキュメントには、基本および詳細の2つの環境変数リストがあります。Helm Chart を使用して必要な構成オプションが公開されていない場合にのみ、環境変数を使用してください。

本番環境デプロイメント用の W&B Server アプリケーション構成ファイルには、次の内容が必要です。この 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 Ingress と GCS（GCP Object storage）を備えた GCP Kubernetes を使用する構成例です。

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

ホスト

 # プロトコルを含む FQDN を指定します
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

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 ServiceAccount

カスタム Kubernetes サービスアカウントを指定して、W&B pod を実行します。

次のスニペットは、指定された名前でデプロイメントの一部としてサービスアカウントを作成します。

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://" または "ldaps://" を含む LDAP サーバーアドレス
    host:
    # ユーザーの検索に使用する LDAP 検索ベース
    baseDN:
    # バインドする LDAP ユーザー (匿名バインドを使用しない場合)
    bindDN:
    # バインドする LDAP パスワードを含むシークレット名とキー (匿名バインドを使用しない場合)
    bindPW:
    # 電子メールとグループ ID 属性の LDAP 属性名をコンマ区切りの文字列値として指定します。
    attributes:
    # LDAP グループ許可リスト
    groupAllowList:
    # LDAP TLS を有効にする
    tls: false

TLS あり

LDAP TLS 証明書構成には、証明書コンテンツで事前に作成された構成マップが必要です。

構成マップを作成するには、次のコマンドを使用します。

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

次の例のように、YAML で構成マップを使用します。

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

global: 
  auth:
    sessionLengthHours: 720
    oidc:
      clientId: ""
      secret: ""
      # IdP が必要な場合にのみ含めます。
      authMethod: ""
      issuer: ""

authMethod はオプションです。

SMTP

global:
  email:
    smtp:
      host: ""
      port: 587
      user: ""
      password: ""

環境変数

global:
  extraEnv:
    GLOBAL_ENV: "example"

カスタム認証局

customCACerts はリストであり、多くの証明書を使用できます。customCACerts で指定された認証局は、W&B Server アプリケーションにのみ適用されます。

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

CA 証明書は、ConfigMap にも保存できます。

global:
  caCertsConfigMap: custom-ca-certs

ConfigMap は次のようになります。

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

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

各 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

たとえば、アプリケーション 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-----    

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

1.3.2.1 - Kubernetes operator for air-gapped instances

イントロダクション

このガイドでは、エアギャップされた顧客管理環境に W&B Platform をデプロイするためのステップごとの手順を説明します。

内部リポジトリまたはレジストリを使用して、Helm chartとコンテナイメージをホストします。 Kubernetes クラスターへの適切なアクセス権を持つシェルコンソールですべてのコマンドを実行します。

Kubernetes アプリケーションのデプロイに使用する継続的デリバリー ツールで、同様のコマンドを利用できます。

ステップ 1: 前提条件

開始する前に、ご使用の環境が次の要件を満たしていることを確認してください。

• Kubernetes バージョン >= 1.28
• Helm バージョン >= 3
• 必要な W&B イメージを持つ内部コンテナレジストリへのアクセス
• W&B Helm chart 用の内部 Helm リポジトリへのアクセス

ステップ 2: 内部コンテナレジストリの準備

デプロイメントに進む前に、次のコンテナイメージが内部コンテナレジストリで利用可能であることを確認する必要があります。

• docker.io/wandb/controller
• docker.io/wandb/local
• docker.io/wandb/console
• docker.io/bitnami/redis
• docker.io/otel/opentelemetry-collector-contrib
• quay.io/prometheus/prometheus
• quay.io/prometheus-operator/prometheus-config-reloader

これらのイメージは、W&B コンポーネントを正常にデプロイするために重要です。 W&B は、WSM を使用してコンテナレジストリを準備することを推奨します。

組織がすでに内部コンテナレジストリを使用している場合は、イメージをそこに追加できます。 それ以外の場合は、次のセクションに従って、WSM と呼ばれるものを使用してコンテナリポジトリを準備します。

Operator の要件の追跡、およびイメージのアップグレードの確認とダウンロードは、WSM を使用するか、組織独自のプロセスを使用することによって、ユーザーが行う必要があります。

WSM のインストール

次のいずれかの方法を使用して WSM をインストールします。

Bash

GitHub から Bash スクリプトを直接実行します。

curl -sSL https://raw.githubusercontent.com/wandb/wsm/main/install.sh | bash

スクリプトは、スクリプトを実行したフォルダーにバイナリをダウンロードします。 別のフォルダーに移動するには、次を実行します。

sudo mv wsm /usr/local/bin

GitHub

W&B が管理する GitHub リポジトリ wandb/wsm（https://github.com/wandb/wsm）から WSM をダウンロードまたはクローンします。 最新リリースについては、wandb/wsm の リリースノートを参照してください。

イメージとそのバージョンのリスト

wsm list を使用して、イメージバージョンの最新リストを取得します。

wsm list

出力は次のようになります。

:package: Starting the process to list all images required for deployment...
Operator Images:
  wandb/controller:1.16.1
W&B Images:
  wandb/local:0.62.2
  docker.io/bitnami/redis:7.2.4-debian-12-r9
  quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
  quay.io/prometheus/prometheus:v2.47.0
  otel/opentelemetry-collector-contrib:0.97.0
  wandb/console:2.13.1
Here are the images required to deploy W&B. Ensure these images are available in your internal container registry and update the values.yaml accordingly.

イメージのダウンロード

wsm download を使用して、最新バージョンのすべてのイメージをダウンロードします。

wsm download

出力は次のようになります。

Downloading operator helm chart
Downloading wandb helm chart
✓ wandb/controller:1.16.1
✓ docker.io/bitnami/redis:7.2.4-debian-12-r9
✓ otel/opentelemetry-collector-contrib:0.97.0
✓ quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
✓ wandb/console:2.13.1
✓ quay.io/prometheus/prometheus:v2.47.0

  Done! Installed 7 packages.

WSM は、各イメージの .tgz アーカイブを bundle ディレクトリーにダウンロードします。

ステップ 3: 内部 Helm chart リポジトリの準備

コンテナイメージに加えて、次の Helm chartが内部 Helm Chart リポジトリで利用可能であることも確認する必要があります。 前のステップで紹介した WSM ツールは、Helm chartもダウンロードできます。 または、ここでダウンロードしてください。

• W&B Operator
• W&B Platform

operator chartは、Controller Manager とも呼ばれる W&B Operator をデプロイするために使用されます。 platform chartは、カスタムリソース定義 (CRD) で構成された値を使用して W&B Platform をデプロイするために使用されます。

ステップ 4: Helm リポジトリの設定

次に、内部リポジトリから W&B Helm chartをプルするように Helm リポジトリを設定します。 次のコマンドを実行して、Helm リポジトリを追加および更新します。

helm repo add local-repo https://charts.yourdomain.com
helm repo update

ステップ 5: Kubernetes operator のインストール

コントローラマネージャとも呼ばれる W&B Kubernetes operator は、W&B platform コンポーネントの管理を担当します。 エアギャップ環境にインストールするには、内部コンテナレジストリを使用するように構成する必要があります。

これを行うには、内部コンテナレジストリを使用するようにデフォルトのイメージ設定をオーバーライドし、キー airgapped: true を設定して、予想されるデプロイメントタイプを示す必要があります。 次に示すように、values.yaml ファイルを更新します。

image:
  repository: registry.yourdomain.com/library/controller
  tag: 1.13.3
airgapped: true

タグを、内部レジストリで使用可能なバージョンに置き換えます。

operator と CRD をインストールします。

helm upgrade --install operator wandb/operator -n wandb --create-namespace -f values.yaml

サポートされている値の詳細については、Kubernetes operator GitHub リポジトリを参照してください。

ステップ 6: W&B カスタムリソースの設定

W&B Kubernetes operator をインストールしたら、内部 Helm リポジトリとコンテナレジストリを指すようにカスタムリソース (CR) を構成する必要があります。

この設定により、Kubernetes operator は、W&B platform の必要なコンポーネントをデプロイするときに、内部レジストリとリポジトリを使用することが保証されます。

この CR の例を wandb.yaml という新しいファイルにコピーします。

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'
    
    # If install: true, Helm installs a MySQL database for the deployment to use. Set to `false` to use your own external MySQL deployment.
    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 platform をデプロイするために、Kubernetes Operator は CR の値を使用して、内部リポジトリから operator-wandb Helm chart を構成します。

すべてのタグ/バージョンを、内部レジストリで使用可能なバージョンに置き換えます。

上記の構成ファイルの作成の詳細については、こちらをご覧ください。

ステップ 7: W&B platform のデプロイ

Kubernetes operator と CR が構成されたので、wandb.yaml 構成を適用して W&B platform をデプロイします。

kubectl apply -f wandb.yaml

FAQ

デプロイメントプロセス中に、以下のよくある質問 (FAQ) とトラブルシューティングのヒントを参照してください。

別の ingress クラスがあります。 そのクラスを使用できますか？

はい、values.yaml で ingress 設定を変更することで、ingress クラスを構成できます。

証明書バンドルに複数の証明書があります。 それは機能しますか？

証明書を values.yaml の customCACerts セクションの複数のエントリに分割する必要があります。

Kubernetes operator が無人アップデートを適用するのを防ぐにはどうすればよいですか。 それは可能ですか？

W&B console から自動アップデートをオフにすることができます。 サポートされているバージョンに関する質問については、W&B チームにお問い合わせください。 また、W&B は過去 6 か月以内にリリースされた platform バージョンをサポートしていることに注意してください。 W&B は定期的なアップグレードを実行することをお勧めします。

環境がパブリックリポジトリに接続されていない場合、デプロイメントは機能しますか？

構成で airgapped を true に設定すると、Kubernetes operator は内部リソースのみを使用し、パブリックリポジトリへの接続を試みません。

1.3.3 - Install on public cloud

1.3.3.1 - Deploy W&B Platform on AWS

W&B は、W&B Server AWS Terraform Module を使用して、AWS にプラットフォームをデプロイすることをお勧めします。

開始する前に、W&B は、Terraform で利用可能な リモートバックエンド のいずれかを選択して、State File を保存することをお勧めします。

State File は、すべてのコンポーネントを再作成せずに、アップグレードを展開したり、デプロイメントに変更を加えたりするために必要なリソースです。

Terraform Module は、次の 必須 コンポーネントをデプロイします。

• ロードバランサー
• AWS Identity & Access Management (IAM)
• AWS Key Management System (KMS)
• Amazon Aurora MySQL
• Amazon VPC
• Amazon S3
• Amazon Route53
• Amazon Certificate Manager (ACM)
• Amazon Elastic Load Balancing (ALB)
• Amazon Secrets Manager

その他のデプロイメントオプションには、次のオプションコンポーネントを含めることもできます。

• Redis 用 Elastic Cache
• SQS

前提条件のアクセス許可

Terraform を実行するアカウントは、イントロダクションで説明されているすべてのコンポーネントを作成でき、IAM Policies と IAM Roles を作成し、リソースにロールを割り当てるアクセス許可が必要です。

一般的な手順

このトピックの手順は、このドキュメントで説明されているすべてのデプロイメントオプションに共通です。

1. 開発環境を準備します。

   • Terraform をインストールします。
   • W&B は、バージョン管理のために Git リポジトリーを作成することをお勧めします。

2. terraform.tfvars ファイルを作成します。

   tvfars ファイルの内容は、インストールタイプに応じてカスタマイズできますが、最小限の推奨設定は以下の例のようになります。

   namespace                  = "wandb"
   license                    = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
   subdomain                  = "wandb-aws"
   domain_name                = "wandb.ml"
   zone_id                    = "xxxxxxxxxxxxxxxx"
   allowed_inbound_cidr       = ["0.0.0.0/0"]
   allowed_inbound_ipv6_cidr  = ["::/0"]
   eks_cluster_version        = "1.29"
   

   namespace 変数は、Terraform によって作成されたすべてのリソースのプレフィックスとなる文字列であるため、デプロイする前に 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 インストールへのアクセスを許可しています。

3. ファイル versions.tf を作成します。

   このファイルには、AWS に W&B をデプロイするために必要な Terraform および Terraform プロバイダーのバージョンが含まれます。

   provider "aws" {
     region = "eu-central-1"
   
     default_tags {
       tags = {
         GithubRepo = "terraform-aws-wandb"
         GithubOrg  = "wandb"
         Enviroment = "Example"
         Example    = "PublicDnsExternal"
       }
     }
   }
   

   AWS プロバイダーの設定については、Terraform Official Documentation を参照してください。

   オプションですが、強く推奨されるのは、このドキュメントの冒頭で説明した リモートバックエンド構成 を追加することです。

4. ファイル 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 Cluster に最新バージョンの W&B をインストールする、最も簡単なデプロイメントオプション構成です。

1. main.tf を作成します。

   「一般的な手順」でファイルを作成したのと同じディレクトリーに、次の内容で main.tf ファイルを作成します。

   module "wandb_infra" {
     source  = "wandb/wandb/aws"
     version = "~>7.0"
   
     namespace   = var.namespace
     domain_name = var.domain_name
     subdomain   = var.subdomain
     zone_id     = var.zone_id
   
     allowed_inbound_cidr           = var.allowed_inbound_cidr
     allowed_inbound_ipv6_cidr      = var.allowed_inbound_ipv6_cidr
   
     public_access                  = true
     external_dns                   = true
     kubernetes_public_access       = true
     kubernetes_public_access_cidrs = ["0.0.0.0/0"]
     eks_cluster_version            = var.eks_cluster_version
   }
   
    data "aws_eks_cluster" "eks_cluster_id" {
      name = module.wandb_infra.cluster_name
    }
   
    data "aws_eks_cluster_auth" "eks_cluster_auth" {
      name = module.wandb_infra.cluster_name
    }
   
    provider "kubernetes" {
      host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
      cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
      token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
    }
   
   
    provider "helm" {
      kubernetes {
        host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
        cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
        token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
      }
    }
   
    output "url" {
      value = module.wandb_infra.url
    }
   
    output "bucket" {
      value = module.wandb_infra.bucket_name
    }
   

2. W&B をデプロイします。

   W&B をデプロイするには、次のコマンドを実行します。

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS を有効にする

別のデプロイメントオプションでは、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスをロードする際のアプリケーションの応答を高速化します。

キャッシュを有効にするには、推奨されるデプロイメント セクションで説明されているのと同じ main.tf ファイルにオプション create_elasticache_subnet = true を追加する必要があります。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
	**create_elasticache_subnet = true**
}
[...]

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

デプロイメントオプション 3 は、外部 message broker を有効にすることで構成されています。これは、W&B にブローカーが埋め込まれているため、オプションです。このオプションは、パフォーマンスの向上をもたらしません。

メッセージブローカーを提供する AWS リソースは SQS であり、これを有効にするには、推奨されるデプロイメント セクションで説明されているのと同じ main.tf にオプション use_internal_queue = false を追加する必要があります。

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

[...]
}

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

3 つのデプロイメントオプションすべてを組み合わせて、すべての構成を同じファイルに追加できます。 Terraform Module は、標準オプションと Deployment - Recommended にある最小構成とともに組み合わせることができるいくつかのオプションを提供します。

手動構成

Amazon S3 バケットを W&B のファイルストレージバックエンドとして使用するには、次の操作を行う必要があります。

• Amazon S3 バケットとバケット通知の作成
• SQS キューの作成
• W&B を実行するノードへのアクセス許可の付与

バケットと、そのバケットからオブジェクト作成通知を受信する SQS キューを構成する必要があります。インスタンスには、このキューから読み取るためのアクセス許可が必要です。

S3 バケットとバケット通知の作成

Amazon S3 バケットを作成し、バケット通知を有効にするには、以下の手順に従います。

1. AWS コンソールで Amazon S3 に移動します。
2. [バケットの作成] を選択します。
3. [詳細設定] で、[イベント] セクションの [通知の追加] を選択します。
4. 以前に構成した SQS キューに送信されるように、すべてのオブジェクト作成イベントを構成します。

CORS アクセスを有効にします。CORS 構成は次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

SQS キューの作成

SQS キューを作成するには、以下の手順に従います。

1. AWS コンソールで Amazon SQS に移動します。
2. [キューの作成] を選択します。
3. [詳細] セクションで、[標準] キュータイプを選択します。
4. [アクセス ポリシー] セクションで、次のプリンシパルへのアクセス許可を追加します。

• SendMessage
• ReceiveMessage
• ChangeMessageVisibility
• DeleteMessage
• GetQueueUrl

オプションで、[アクセス ポリシー] セクションに高度なアクセス ポリシーを追加します。たとえば、ステートメントを含む Amazon SQS にアクセスするためのポリシーは次のとおりです。

{
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Principal" : "*",
        "Action" : ["sqs:SendMessage"],
        "Resource" : "<sqs-queue-arn>",
        "Condition" : {
          "ArnEquals" : { "aws:SourceArn" : "<s3-bucket-arn>" }
        }
      }
    ]
}

W&B を実行するノードへのアクセス許可の付与

W&B サーバーが実行されているノードは、Amazon S3 および Amazon SQS へのアクセスを許可するように構成する必要があります。選択したサーバーデプロイメントのタイプに応じて、次のポリシー ステートメントをノードロールに追加する必要がある場合があります。

{
   "Statement":[
      {
         "Sid":"",
         "Effect":"Allow",
         "Action":"s3:*",
         "Resource":"arn:aws:s3:::<WANDB_BUCKET>"
      },
      {
         "Sid":"",
         "Effect":"Allow",
         "Action":[
            "sqs:*"
         ],
         "Resource":"arn:aws:sqs:<REGION>:<ACCOUNT>:<WANDB_QUEUE>"
      }
   ]
}

W&B サーバーの設定

最後に、W&B サーバーを設定します。

1. http(s)://YOUR-W&B-SERVER-HOST/system-admin で W&B 設定ページに移動します。
2. [**外部ファイルストレージバックエンドを使用する] オプションを有効にします。
3. 次の形式で、Amazon S3 バケット、リージョン、および Amazon SQS キューに関する情報を提供します。

• ファイルストレージバケット: s3://<bucket-name>
• ファイルストレージリージョン (AWS のみ): <region>
• 通知サブスクリプション: sqs://<queue-name>

4. [設定の更新] を選択して、新しい設定を適用します。

W&B バージョンをアップグレードする

W&B を更新するには、ここに概説されている手順に従います。

1. wandb_app モジュールの構成に wandb_version を追加します。アップグレードする W&B のバージョンを指定します。たとえば、次の行は W&B バージョン 0.48.1 を指定します。

module "wandb_app" {
    source  = "wandb/wandb/kubernetes"
    version = "~>1.0"

    license       = var.license
    wandb_version = "0.48.1"

2. 構成を更新した後、推奨されるデプロイメントセクション で説明されている手順を完了します。

オペレーターベースの AWS Terraform モジュールへの移行

このセクションでは、terraform-aws-wandb モジュールを使用して、プレオペレーター 環境から ポストオペレーター 環境にアップグレードするために必要な手順について詳しく説明します。

移行前後のアーキテクチャ

以前の W&B アーキテクチャでは、次のものが使用されていました。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "1.16.10"
  ...
}

インフラストラクチャを制御します。

また、このモジュールを使用して W&B サーバーをデプロイします。

module "wandb_app" {
  source  = "wandb/wandb/kubernetes"
  version = "1.12.0"
}

移行後のアーキテクチャでは、次のものが使用されます。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "4.7.2"
  ...
}

インフラストラクチャのインストールと Kubernetes クラスターへの W&B サーバーのデプロイの両方を管理するため、post-operator.tf では module "wandb_app" は不要になります。

このアーキテクチャの移行により、SRE/インフラストラクチャチームによる手動の Terraform 操作を必要とせずに、追加機能 (OpenTelemetry、Prometheus、HPA、Kafka、およびイメージ更新など) を有効にできます。

W&B Pre-Operator の基本インストールを開始するには、post-operator.tf に .disabled ファイル拡張子があり、pre-operator.tf がアクティブであることを確認します (.disabled` 拡張子がない)。これらのファイルは、ここ にあります。

前提条件

移行プロセスを開始する前に、次の前提条件が満たされていることを確認してください。

• エグレス: デプロイメントはエアギャップにできません。Release Channel の最新の仕様を取得するには、deploy.wandb.ai へのアクセスが必要です。
• AWS 認証情報: AWS リソースと対話するように構成された適切な AWS 認証情報。
• Terraform のインストール: 最新バージョンの Terraform がシステムにインストールされている必要があります。
• Route53 ホストゾーン: アプリケーションが提供されるドメインに対応する既存の Route53 ホストゾーン。
• Pre-Operator Terraform ファイル: pre-operator.tf および関連する変数ファイル (例: pre-operator.tfvars) が正しく設定されていることを確認します。

Pre-Operator の設定

次の Terraform コマンドを実行して、Pre-Operator セットアップの構成を初期化して適用します。

terraform init -upgrade
terraform apply -var-file=./pre-operator.tfvars

pre-operator.tf は次のようになります。

namespace     = "operator-upgrade"
domain_name   = "sandbox-aws.wandb.ml"
zone_id       = "Z032246913CW32RVRY0WU"
subdomain     = "operator-upgrade"
wandb_license = "ey..."
wandb_version = "0.51.2"

pre-operator.tf 構成は、次の 2 つのモジュールを呼び出します。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "1.16.10"
  ...
}

このモジュールはインフラストラクチャを起動します。

module "wandb_app" {
  source  = "wandb/wandb/kubernetes"
  version = "1.12.0"
}

このモジュールはアプリケーションをデプロイします。

Post-Operator の設定

pre-operator.tf に .disabled 拡張子があり、post-operator.tf がアクティブであることを確認します。

post-operator.tfvars には、追加の変数が含まれています。

...
# wandb_version = "0.51.2" は、リリースチャネルを介して管理されるか、ユーザースペックで設定されるようになりました。

# アップグレードに必要なオペレーター変数:
size                 = "small"
enable_dummy_dns     = true
enable_operator_alb  = true
custom_domain_filter = "sandbox-aws.wandb.ml"

次のコマンドを実行して、Post-Operator 構成を初期化して適用します。

terraform init -upgrade
terraform apply -var-file=./post-operator.tfvars

プランと適用手順では、次のリソースが更新されます。

actions:
  create:
    - aws_efs_backup_policy.storage_class
    - aws_efs_file_system.storage_class
    - aws_efs_mount_target.storage_class["0"]
    - aws_efs_mount_target.storage_class["1"]
    - aws_eks_addon.efs
    - aws_iam_openid_connect_provider.eks
    - aws_iam_policy.secrets_manager
    - aws_iam_role_policy_attachment.ebs_csi
    - aws_iam_role_policy_attachment.eks_efs
    - aws_iam_role_policy_attachment.node_secrets_manager
    - aws_security_group.storage_class_nfs
    - aws_security_group_rule.nfs_ingress
    - random_pet.efs
    - aws_s3_bucket_acl.file_storage
    - aws_s3_bucket_cors_configuration.file_storage
    - aws_s3_bucket_ownership_controls.file_storage
    - aws_s3_bucket_server_side_encryption_configuration.file_storage
    - helm_release.operator
    - helm_release.wandb
    - aws_cloudwatch_log_group.this[0]
    - aws_iam_policy.default
    - aws_iam_role.default
    - aws_iam_role_policy_attachment.default
    - helm_release.external_dns
    - aws_default_network_acl.this[0]
    - aws_default_route_table.default[0]
    - aws_iam_policy.default
    - aws_iam_role.default
    - aws_iam_role_policy_attachment.default
    - helm_release.aws_load_balancer_controller

  update_in_place:
    - aws_iam_policy.node_IMDSv2
    - aws_iam_policy.node_cloudwatch
    - aws_iam_policy.node_kms
    - aws_iam_policy.node_s3
    - aws_iam_policy.node_sqs
    - aws_eks_cluster.this[0]
    - aws_elasticache_replication_group.default
    - aws_rds_cluster.this[0]
    - aws_rds_cluster_instance.this["1"]
    - aws_default_security_group.this[0]
    - aws_subnet.private[0]
    - aws_subnet.private[1]
    - aws_subnet.public[0]
    - aws_subnet.public[1]
    - aws_launch_template.workers["primary"]

  destroy:
    - kubernetes_config_map.config_map
    - kubernetes_deployment.wandb
    - kubernetes_priority_class.priority
    - kubernetes_secret.secret
    - kubernetes_service.prometheus
    - kubernetes_service.service
    - random_id.snapshot_identifier[0]

  replace:
    - aws_autoscaling_attachment.autoscaling_attachment["primary"]
    - aws_route53_record.alb
    - aws_eks_node_group.workers["primary"]

次のようなものが表示されます。

post-operator.tf には、次のように 1 つがあります。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "4.7.2"
  ...
}

ポストオペレーター構成の変更点:

1. 必要なプロバイダーの更新: プロバイダーの互換性を保つために、required_providers.aws.version を 3.6 から 4.0 に変更します。
2. DNS とロード バランサーの構成: Ingress を介して DNS レコードと AWS ロード バランサーの設定を管理するために、enable_dummy_dns と enable_operator_alb を統合します。
3. ライセンスとサイズの構成: 新しい運用要件に合わせて、license パラメーターと size パラメーターを wandb_infra モジュールに直接転送します。
4. カスタムドメインの処理: 必要に応じて、kube-system 名前空間内の外部 DNS ポッドログを確認して DNS の問題をトラブルシューティングするために、custom_domain_filter を使用します。
5. Helm プロバイダーの構成: Helm プロバイダーを有効にして構成し、Kubernetes リソースを効果的に管理します。

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.app_cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.app_cluster.certificate_authority[0].data)
    token                  = data.aws_eks_cluster_auth.app_cluster.token
    exec {
      api_version = "client.authentication.k8s.io/v1beta1"
      args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.app_cluster.name]
      command     = "aws"
    }
  }
}

この包括的な設定により、オペレーターモデルによって有効になる新しい効率と機能を活用して、Pre-Operator 構成から Post-Operator 構成へのスムーズな移行が保証されます。

1.3.3.2 - Deploy W&B Platform on GCP

W&B Server の自己管理を行う場合、GCP 上にプラットフォームをデプロイするために、W&B Server GCP Terraform Module を使用することを推奨します。

モジュールのドキュメントは広範囲にわたり、利用可能なすべてのオプションが記載されています。

開始する前に、Terraform の リモートバックエンド のいずれかを選択して、State File を保存することを推奨します。

State File は、すべてのコンポーネントを再作成せずに、アップグレードを展開したり、デプロイメントに変更を加えたりするために必要なリソースです。

Terraform Module は、以下の必須コンポーネントをデプロイします。

• VPC
• Cloud SQL for MySQL
• Cloud Storage Bucket
• Google Kubernetes Engine
• KMS Crypto Key
• Load Balancer

その他のデプロイメントオプションには、以下のオプションコンポーネントを含めることもできます。

• Redis 用のメモリーストア
• Pub/Sub メッセージシステム

事前requisite 権限

Terraform を実行するアカウントには、使用する GCP プロジェクトで roles/owner のロールが必要です。

一般的な手順

このトピックの手順は、このドキュメントで説明するすべてのデプロイメントオプションに共通です。

1. 開発環境を準備します。

   • Terraform をインストールします。
   • 使用するコードで Git リポジトリを作成することをお勧めしますが、ファイルをローカルに保存することもできます。
   • Google Cloud Console でプロジェクトを作成します。
   • GCP で認証します (gcloud をインストールしてください)。 gcloud auth application-default login

2. 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 の組み合わせで、Weights & Biases が設定される FQDN が形成されます。上記の例では、Weights & Biases の FQDN は wandb-gcp.wandb.ml になります。

3. ファイル 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 = "Weights & Biases UI にアクセスするためのドメイン名"
   }
   
   variable "subdomain" {
     type        = string
     description = "Weights & Biases UI にアクセスするためのサブドメイン"
   }
   
   variable "license" {
     type        = string
     description = "W&B License"
   }
   

デプロイメント - 推奨 (~20 分)

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

1. main.tf を作成します。

   一般的な手順 でファイルを作成したのと同じディレクトリーに、次の内容で 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
   }
   
   # Spin up all required services
   module "wandb" {
     source  = "wandb/wandb/google"
     version = "~> 5.0"
   
     namespace   = var.namespace
     license     = var.license
     domain_name = var.domain_name
     subdomain   = var.subdomain
   }
   
   # You'll want to update your DNS with the provisioned IP address
   output "url" {
     value = module.wandb.url
   }
   
   output "address" {
     value = module.wandb.address
   }
   
   output "bucket_name" {
     value = module.wandb.bucket_name
   }
   

2. 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 = "~> 1.0"

  namespace    = var.namespace
  license      = var.license
  domain_name  = var.domain_name
  subdomain    = var.subdomain
  allowed_inbound_cidrs = ["*"]
  #Enable Redis
  create_redis = true

}
[...]

外部キューを使用したデプロイメント

デプロイメントオプション 3 は、外部 message broker を有効にすることです。W&B にはブローカーが組み込まれているため、これはオプションです。このオプションは、パフォーマンスの向上をもたらしません。

メッセージブローカーを提供する GCP リソースは Pub/Sub であり、これを有効にするには、推奨される デプロイメントオプションのセクション で指定されている同じ main.tf にオプション use_internal_queue = false を追加する必要があります。

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 1.0"

  namespace          = var.namespace
  license            = var.license
  domain_name        = var.domain_name
  subdomain          = var.subdomain
  allowed_inbound_cidrs = ["*"]
  #Create and use Pub/Sub
  use_internal_queue = false

}

[...]

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

3 つのデプロイメントオプションすべてを組み合わせて、すべての構成を同じファイルに追加できます。 Terraform Module は、標準オプションと Deployment - Recommended にある最小限の構成とともに組み合わせることができるいくつかのオプションを提供します。

手動構成

GCP Storage バケットを W&B のファイルストレージバックエンドとして使用するには、以下を作成する必要があります。

• PubSub トピックとサブスクリプション
• ストレージバケット
• PubSub 通知

PubSub トピックとサブスクリプションを作成する

PubSub トピックとサブスクリプションを作成するには、以下の手順に従ってください。

1. GCP Console 内の Pub/Sub サービスに移動します。
2. [トピックを作成] を選択し、トピックの名前を指定します。
3. ページの下部で、[サブスクリプションを作成] を選択します。[配信タイプ] が [プル] に設定されていることを確認します。
4. [作成] をクリックします。

インスタンスを実行しているサービスアカウントまたはアカウントに、このサブスクリプションに対する pubsub.admin ロールがあることを確認してください。詳細については、https://cloud.google.com/pubsub/docs/access-control#console を参照してください。

ストレージバケットを作成する

1. [Cloud Storage バケット] ページに移動します。
2. [バケットを作成] を選択し、バケットの名前を指定します。[標準] ストレージクラス を選択してください。

インスタンスを実行しているサービスアカウントまたはアカウントに、以下の両方があることを確認してください。

• 前の手順で作成したバケットへのアクセス
• このバケットに対する storage.objectAdmin ロール。詳細については、https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add を参照してください。

3. CORS アクセスを有効にします。これはコマンドラインでのみ実行できます。まず、次の CORS 構成で JSON ファイルを作成します。

cors:
- maxAgeSeconds: 3600
  method:
   - GET
   - PUT
     origin:
   - '<YOUR_W&B_SERVER_HOST>'
     responseHeader:
   - Content-Type

オリジンのスキーム、ホスト、ポートの値が正確に一致する必要があることに注意してください。

4. gcloud がインストールされ、正しい GCP プロジェクトにログインしていることを確認します。
5. 次に、以下を実行します。

gcloud storage buckets update gs://<BUCKET_NAME> --cors-file=<CORS_CONFIG_FILE>

PubSub 通知を作成する

ストレージバケットから Pub/Sub トピックへの通知ストリームを作成するには、コマンドラインで以下の手順に従ってください。

1. GCP プロジェクトにログインします。
2. ターミナルで以下を実行します。

gcloud pubsub topics list  # list names of topics for reference
gcloud storage ls          # list names of buckets for reference

# create bucket notification
gcloud storage buckets notifications create gs://<BUCKET_NAME> --topic=<TOPIC_NAME>

詳細については、Cloud Storage の Web サイトをご覧ください。

W&B サーバーを設定する

1. 最後に、http(s)://YOUR-W&B-SERVER-HOST/console/settings/system で W&B の [システム接続] ページに移動します。
2. プロバイダー Google Cloud Storage (gcs) を選択します。
3. GCS バケットの名前を指定します。

4. [設定を更新] を押して、新しい設定を適用します。

W&B サーバーをアップグレードする

W&B を更新するには、ここで概説する手順に従ってください。

1. wandb_app モジュールの構成に wandb_version を追加します。アップグレードする W&B のバージョンを指定します。たとえば、次の行は W&B バージョン 0.48.1 を指定します。

module "wandb_app" {
    source  = "wandb/wandb/kubernetes"
    version = "~>5.0"

    license       = var.license
    wandb_version = "0.58.1"

2. 構成を更新したら、デプロイメントオプションのセクション で説明されている手順を完了します。

1.3.3.3 - Deploy W&B Platform on Azure

W&B Server の自己管理を選択した場合、Azure にプラットフォームをデプロイするには、W&B Server Azure Terraform Module を使用することをお勧めします。

このモジュールのドキュメントは広範囲にわたり、利用可能なすべてのオプションが記載されています。このドキュメントでは、いくつかのデプロイメントオプションについて説明します。

開始する前に、Terraform で利用可能な remote backends のいずれかを選択して、State File を保存することをお勧めします。

State File は、すべてのコンポーネントを再作成せずに、アップグレードを展開したり、デプロイメントに変更を加えたりするために必要なリソースです。

Terraform Module は、次の mandatory コンポーネントをデプロイします。

• Azure Resource Group
• Azure Virtual Network (VPC)
• Azure MySQL Fliexible 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 を実行するアカウントは、イントロダクションで説明されているすべてのコンポーネントを作成できる必要があります。

一般的な手順

このトピックの手順は、このドキュメントで説明されているすべてのデプロイメントオプションに共通です。

1. 開発 環境 を準備します。

• Terraform をインストールします。
• 使用する コード で Git リポジトリを作成することをお勧めしますが、ファイルをローカルに保持することもできます。

2. terraform.tfvars ファイルを作成します。 tvfars ファイルの内容は、インストールタイプに応じてカスタマイズできますが、推奨される最小限の内容は以下の例のようになります。

    namespace     = "wandb"
    wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
    subdomain     = "wandb-aws"
    domain_name   = "wandb.ml"
    location      = "westeurope"
   

   ここで定義されている変数は、デプロイメントの前に決定する必要があります。namespace 変数は、Terraform によって作成されたすべてのリソースにプレフィックスを付ける 文字列 になります。

   subdomain と domain の組み合わせで、Weights & Biases が設定される FQDN が形成されます。上記の例では、Weights & Biases の FQDN は wandb-aws.wandb.ml になり、FQDN レコードが作成される DNS zone_id になります。

3. ファイル versions.tf を作成します。 このファイルには、Weights & Biases を AWS にデプロイするために必要な Terraform および Terraform プロバイダーの バージョン が含まれます。

terraform {
  required_version = "~> 1.3"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.17"
    }
  }
}

AWS プロバイダーを設定するには、Terraform Official Documentation を参照してください。

オプションで、強く推奨されますが、このドキュメントの冒頭で説明した remote backend configuration を追加できます。

4. ファイル 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"
  }

推奨されるデプロイメント

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

1. 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)
  }
}

# Spin up all required services
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
}

2. W&B にデプロイします。 W&B をデプロイするには、次の コマンド を実行します。

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS Cache を使用したデプロイメント

別のデプロイメントオプションでは、SQL クエリをキャッシュし、Experiments の Metrics をロードする際のアプリケーション応答を高速化するために Redis を使用します。

キャッシュを有効にするには、推奨されるデプロイメント で使用したのと同じ main.tf ファイルにオプション create_redis = true を追加する必要があります。

# Spin up all required services
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 # Create Redis
  [...]

外部キューを使用したデプロイメント

デプロイメントオプション 3 は、外部 message broker を有効にすることで構成されます。W&B にはブローカーが組み込まれているため、これはオプションです。このオプションは、パフォーマンスの向上をもたらしません。

message broker を提供する Azure リソースは Azure Event Grid であり、これを有効にするには、推奨されるデプロイメント で使用したのと同じ main.tf にオプション use_internal_queue = false を追加する必要があります。

# Spin up all required services
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 # Enable Azure Event Grid
  [...]
}

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

3 つのデプロイメントオプションすべてを組み合わせて、すべての構成を同じファイルに追加できます。 Terraform Module には、標準オプションと 推奨されるデプロイメント にある最小限の構成とともに組み合わせることができる、いくつかのオプションが用意されています。

1.3.4 - Deploy W&B Platform On-premises

関連する質問については、W&B のセールスチーム (contact@wandb.com) にお問い合わせください。

インフラストラクチャーのガイドライン

W&B のデプロイメントを開始する前に、リファレンスアーキテクチャー、特にインフラストラクチャーの要件を参照してください。

MySQL データベース

スケーラブルな MySQL データベースの運用を簡単にするエンタープライズサービスが多数あります。W&B では、以下のソリューションのいずれかを検討することをお勧めします。

https://www.percona.com/software/mysql-database/percona-server

https://github.com/mysql/mysql-operator

W&B Server MySQL 8.0 を実行する場合、または MySQL 5.7 から 8.0 にアップグレードする場合は、以下の条件を満たしてください。

binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'

MySQL 8.0 での sort_buffer_size の処理方法の変更により、sort_buffer_size パラメータをデフォルト値の 262144 から更新する必要がある場合があります。W&B と MySQL が効率的に連携するように、値を 67108864 (64MiB) に設定することをお勧めします。MySQL は v8.0.28 以降でこの設定をサポートしています。

データベースに関する考慮事項

次の SQL クエリで、データベースと ユーザーを作成します。SOME_PASSWORD は任意のパスワードに置き換えてください。

CREATE USER 'wandb_local'@'%' IDENTIFIED BY 'SOME_PASSWORD';
CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION;

パラメータグループの設定

データベースのパフォーマンスを調整するために、次のパラメータグループが設定されていることを確認してください。

binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'
sort_buffer_size = 67108864

オブジェクトストレージ

オブジェクトストレージは、Minio cluster で外部ホストすることも、署名付き URL をサポートする Amazon S3 互換のオブジェクトストレージでホストすることもできます。オブジェクトストレージが署名付き URL をサポートしているかどうかを確認するには、次のスクリプト を実行してください。

また、オブジェクトストレージには、次の CORS ポリシーを適用する必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Amazon S3 互換のオブジェクトストレージに接続するときに、接続文字列で認証情報を指定できます。たとえば、次のように指定できます。

s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME

オブジェクトストレージに信頼できる SSL 証明書を設定している場合は、W&B が TLS 経由でのみ接続するように指示することもできます。これを行うには、URL に tls クエリパラメータを追加します。たとえば、次の URL の例は、Amazon S3 URI に TLS クエリパラメータを追加する方法を示しています。

s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME?tls=true

サードパーティのオブジェクトストレージを使用する場合は、BUCKET_QUEUE を internal:// に設定します。これにより、W&B サーバーは、外部の SQS キューまたは同等のものに依存する代わりに、すべてのオブジェクト通知を内部で管理するように指示されます。

独自のオブジェクトストレージを実行する際に考慮すべき最も重要な点は次のとおりです。

1. ストレージ容量とパフォーマンス。磁気ディスクを使用しても問題ありませんが、これらのディスクの容量を監視する必要があります。W&B の平均的な使用量では、10 ギガバイトから 100 ギガバイトになります。ヘビーな使用では、ペタバイト単位のストレージを消費する可能性があります。
2. フォールトトレランス。少なくとも、オブジェクトを保存する物理ディスクは RAID アレイ上にある必要があります。minio を使用する場合は、分散モード で実行することを検討してください。
3. 可用性。ストレージが利用可能であることを確認するために、監視を設定する必要があります。

独自のオブジェクトストレージサービスを実行する代わりに、次のようなエンタープライズの代替手段が多数あります。

1. https://aws.amazon.com/s3/outposts/
2. https://www.netapp.com/data-storage/storagegrid/

MinIO のセットアップ

minio を使用する場合は、次のコマンドを実行して バケット を作成できます。

mc config host add local http://$MINIO_HOST:$MINIO_PORT "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY" --api s3v4
mc mb --region=us-east1 local/local-files

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

推奨されるインストール方法は、公式の W&B Helm チャートを使用する方法です。W&B Server アプリケーションをデプロイするには、このセクション に従ってください。

OpenShift

W&B は、OpenShift Kubernetes cluster 内からの運用をサポートしています。

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

デフォルトでは、コンテナ は $UID 999 を使用します。オーケストレーターが非 root ユーザー で コンテナ を実行する必要がある場合は、$UID >= 100000 および $GID 0 を指定します。

Kubernetes のセキュリティコンテキストの例を次に示します。

spec:
  securityContext:
    runAsUser: 100000
    runAsGroup: 0

ネットワーク

ロードバランサー

適切なネットワーク境界でネットワークリクエストを停止する ロードバランサー を実行します。

一般的な ロードバランサー には次のものがあります。

1. Nginx Ingress
2. Istio
3. Caddy
4. Cloudflare
5. Apache
6. HAProxy

機械学習 ペイロード を実行するために使用されるすべてのマシンと、Web ブラウザー を介してサービスにアクセスするために使用されるデバイスが、この エンドポイント と通信できることを確認してください。

SSL / TLS

W&B Server は SSL を停止しません。セキュリティポリシーで信頼できるネットワーク内での SSL 通信が必要な場合は、Istio や side car containers などの ツール の使用を検討してください。ロードバランサー 自体が有効な証明書で SSL を終端する必要があります。自己署名証明書の使用はサポートされておらず、ユーザー に多くの問題を引き起こします。可能であれば、Let’s Encrypt のようなサービスを使用すると、ロードバランサー に信頼できる証明書を提供できます。Caddy や Cloudflare などのサービスは、SSL を管理します。

Nginx の設定例

以下は、Nginx をリバースプロキシとして使用した設定例です。

events {}
http {
    # If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
    # scheme used to connect to this server
    # X-Forwarded-Proto を受信した場合は、そのまま渡します。それ以外の場合は、このサーバーへの接続に使用されたスキームを渡します。
    map $http_x_forwarded_proto $proxy_x_forwarded_proto {
        default $http_x_forwarded_proto;
        ''      $scheme;
    }

    # Also, in the above case, force HTTPS
    # また、上記の場合、HTTPS を強制します
    map $http_x_forwarded_proto $sts {
        default '';
        "https" "max-age=31536000; includeSubDomains";
    }

    # If we receive X-Forwarded-Host, pass it though; otherwise, pass along $http_host
    # X-Forwarded-Host を受信した場合は、そのまま渡します。それ以外の場合は、$http_host を渡します。
    map $http_x_forwarded_host $proxy_x_forwarded_host {
        default $http_x_forwarded_host;
        ''      $http_host;
    }

    # If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
    # server port the client connected to
    # X-Forwarded-Port を受信した場合は、そのまま渡します。それ以外の場合は、クライアントが接続したサーバーポートを渡します。
    map $http_x_forwarded_port $proxy_x_forwarded_port {
        default $http_x_forwarded_port;
        ''      $server_port;
    }

    # If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
    # Connection header that may have been passed to this server
    # Upgrade を受信した場合は、Connection を "upgrade" に設定します。それ以外の場合は、このサーバーに渡された可能性のある Connection ヘッダーを削除します。
    map $http_upgrade $proxy_connection {
        default upgrade;
        '' close;
    }

    server {
        listen 443 ssl;
        server_name         www.example.com;
        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;

        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $proxy_connection;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
        proxy_set_header X-Forwarded-Host $proxy_x_forwarded_host;

        location / {
            proxy_pass  http://$YOUR_UPSTREAM_SERVER_IP:8080/;
        }

        keepalive_timeout 10;
    }
}

インストール の検証

W&B Server が正しく設定されていることを確認します。ターミナル で次の コマンド を実行します。

pip install wandb
wandb login --host=https://YOUR_DNS_DOMAIN
wandb verify

ログ ファイル を調べて、W&B Server の起動時に発生した エラー を確認します。次の コマンド を実行します。

• Docker
• Kubernetes

docker logs wandb-local

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

エラー が発生した場合は、W&B Support にお問い合わせください。

1.3.5 - Update W&B license and version

W&B サーバー のバージョンとライセンスの更新は、W&B サーバー のインストール時と同じ方法で行います。以下の表は、さまざまなデプロイメント方法に基づいてライセンスとバージョンを更新する方法をまとめたものです。

Terraform で更新

Terraform でライセンスとバージョンを更新します。次の表に、W&B が管理する Terraform モジュールをクラウド プラットフォーム ごとに示します。

1. まず、適切なクラウド プロバイダー 用に W&B が管理している Terraform モジュールに移動します。クラウド プロバイダー に基づいて適切な Terraform モジュールを見つけるには、上記の表を参照してください。

2. Terraform の 設定 内で、Terraform wandb_app モジュール 設定 の wandb_version と license を更新します。

   module "wandb_app" {
       source  = "wandb/wandb/<cloud-specific-module>"
       version = "new_version"
       license       = "new_license_key" # 新しいライセンスキー
       wandb_version = "new_wandb_version" # 希望する W&B の バージョン
       ...
   }
   

3. terraform plan と terraform apply で Terraform 設定 を適用します。

   terraform init
   terraform apply
   

4. (オプション) terraform.tfvars または他の .tfvars ファイルを使用する場合。

   新しい W&B の バージョン とライセンス キー で terraform.tfvars ファイルを更新または作成します。

   terraform plan -var-file="terraform.tfvars"
   

   設定 を適用します。Terraform ワークスペース ディレクトリー で以下を実行します。

   terraform apply -var-file="terraform.tfvars"
   

Helm で更新

spec で W&B を更新

1. Helm chart *.yaml 設定 ファイルで、image.tag や license の 値 を変更して、新しい バージョン を指定します。

   license: 'new_license'
   image:
     repository: wandb/local
     tag: 'new_version'
   

2. 次の コマンド で Helm アップグレード を実行します。

   helm repo update
   helm upgrade --namespace=wandb --create-namespace \
     --install wandb wandb/wandb --version ${chart_version} \
     -f ${wandb_install_spec.yaml}
   

ライセンスとバージョンを直接更新

1. 新しいライセンス キー とイメージ タグ を 環境 変数 として設定します。

   export LICENSE='new_license'
   export TAG='new_version'
   

2. 以下の コマンド で Helm リリース をアップグレードし、新しい 値 を既存の 設定 とマージします。

   helm repo update
   helm upgrade --namespace=wandb --create-namespace \
     --install wandb wandb/wandb --version ${chart_version} \
     --reuse-values --set license=$LICENSE --set image.tag=$TAG
   

詳細については、パブリック リポジトリー の アップグレード ガイド を参照してください。

admin UI で更新

このメソッド は、通常セルフホスト Docker インストールで、W&B サーバー コンテナー の 環境 変数 で設定されていないライセンスを更新する場合にのみ機能します。

1. W&B Deployment Page から新しいライセンスを取得し、アップグレードする デプロイメント の正しい organization と デプロイメント ID に一致することを確認します。
2. <host-url>/system-settings で W&B Admin UI にアクセスします。
3. ライセンス管理セクションに移動します。
4. 新しいライセンス キー を入力して変更を保存します。

2 - Identity and access management (IAM)

W&B Platform には、W&B 内に3つの IAM スコープがあります。Organizations、Teams、および Projectsです。

Organization

Organization は、W&B アカウントまたはインスタンスのルートスコープです。アカウントまたはインスタンス内のすべてのアクションは、そのルートスコープのコンテキスト内で実行されます。これには、ユーザーの管理、Teams の管理、Teams 内の Projects の管理、使用状況の追跡などが含まれます。

Multi-tenant Cloud を使用している場合、複数の Organization を持つことができ、それぞれが事業部門、個人のユーザー、他の企業との共同パートナーシップなどに対応する場合があります。

Dedicated Cloud または Self-managed instance を使用している場合は、1つの Organization に対応します。貴社は、事業部門や部署に対応するために、複数の Dedicated Cloud または Self-managed instance を持つことができますが、これは厳密には、貴社のビジネスまたは部署全体で AI 実務者を管理するためのオプションの方法です。

詳細については、Organization の管理を参照してください。

Team

Team は、Organization 内のサブスコープであり、事業部門/機能、部署、または社内の project team に対応する場合があります。デプロイメントの種類と料金プランに応じて、Organization 内に複数の Team を持つことができます。

AI projects は、Team のコンテキスト内で編成されます。Team 内のアクセス制御は、親 Organization レベルの管理者である場合とそうでない場合がある Team 管理者によって管理されます。

詳細については、Team の追加と管理を参照してください。

Project

Project は、Team 内のサブスコープであり、特定の意図された結果を持つ実際の AI project に対応します。Team 内に複数の project を持つことができます。各 project には、誰がアクセスできるかを決定する可視性モードがあります。

すべての project は、Workspaces と Reports で構成され、関連する Artifacts、Sweeps、および Automations にリンクされています。

2.1 - Authentication

2.1.1 - Configure SSO with LDAP

W&B サーバー LDAP サーバーで認証情報を認証します。次のガイドでは、W&B サーバーの 設定を構成する方法について説明します。必須およびオプションの設定、システム設定 UI から LDAP 接続を構成する手順について説明します。また、アドレス、ベース識別名、属性など、LDAP 設定のさまざまな入力に関する情報も提供します。これらの属性は、W&B App UI または 環境変数を使用して指定できます。匿名バインド、または管理者 DN とパスワードを使用したバインドのいずれかをセットアップできます。

LDAP 接続を構成する

• W&B App
• Environment variable

設定 パラメータ

次の表に、必須およびオプションの LDAP 構成を示し、説明します。

2.1.2 - Configure SSO with OIDC

W&B Server の OpenID Connect (OIDC) 互換アイデンティティプロバイダーのサポートにより、Okta、Keycloak、Auth0、Google、Entra などの外部アイデンティティプロバイダーを介したユーザーアイデンティティとグループメンバーシップの管理が可能になります。

OpenID Connect (OIDC)

W&B Server は、外部 Identity Provider (IdP) との統合のために、以下の OIDC 認証フローをサポートしています。

1. フォームポストによる暗黙的フロー
2. Proof Key for Code Exchange (PKCE) を使用した認証コードフロー

これらのフローはユーザーを認証し、アクセス制御を管理するために必要なアイデンティティ情報 (ID トークンの形式) を W&B Server に提供します。

ID トークンは、ユーザーの名前、ユーザー名、メール、グループメンバーシップなどのユーザーのアイデンティティ情報を含む JWT です。W&B Server はこのトークンを使用してユーザーを認証し、システム内の適切なロールまたはグループにマップします。

W&B Server のコンテキストでは、アクセス トークンはユーザーに代わって API へのリクエストを承認しますが、W&B Server の主な関心事はユーザー認証とアイデンティティであるため、ID トークンのみが必要です。

環境変数を使用して、IAM オプションを設定 して、専用クラウド または Self-managed インスタンスを構成できます。

専用クラウド または Self-managed W&B Server インストール用に Identity Provider を構成するには、次のガイドラインに従って、さまざまな IdP に従ってください。W&B の SaaS バージョンを使用している場合は、support@wandb.com に連絡して、組織の Auth0 テナントの構成を支援してください。

• Cognito
• Okta
• Entra

W&B Server で SSO をセットアップする

SSO を設定するには、管理者権限と以下の情報が必要です。

• OIDC クライアント ID
• OIDC 認証方式 (implicit または pkce)
• OIDC Issuer URL
• OIDC クライアントシークレット (オプション、IdP の設定方法によって異なります)

W&B Server UI を使用するか、環境変数 を wandb/local pod に渡すことによって、SSO を設定できます。環境変数は UI より優先されます。

• システムコンソール
• システム設定

システムコンソールは、システム設定ページの後継です。W&B Kubernetes Operator ベースのデプロイで使用できます。

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

2. Settings に移動し、次に Authentication に移動します。Type ドロップダウンで OIDC を選択します。

3. 値を入力します。

4. Save をクリックします。

5. ログアウトし、再度ログインします。今回は IdP ログイン画面を使用します。

1. Weights&Biases インスタンスにサインインします。

2. W&B アプリケーションに移動します。

   

3. ドロップダウンから、System Settings を選択します。

   

4. 発行者、クライアント ID、および認証方式を入力します。

5. Update settings を選択します。

Security Assertion Markup Language (SAML)

W&B Server は SAML をサポートしていません。

2.1.3 - Use federated identities with SDK

Identity federation を使用して、W&B SDK 経由で組織の認証情報を使用してサインインします。W&B organization の管理者が organization 向けに SSO を設定している場合、すでに組織の認証情報を使用して W&B アプリの UI にサインインしているはずです。その意味で、identity federation は W&B SDK の SSO のようなものですが、JSON Web Tokens (JWT) を直接使用します。identity federation は、APIキー の代替として使用できます。

RFC 7523 は、SDK との identity federation の基礎を形成します。

JWT issuer の設定

最初の手順として、organization の管理者は、W&B organization と公開されている JWT issuer の間の federation を設定する必要があります。

• organization の ダッシュボード で Settings タブに移動します
• Authentication オプションで、Set up JWT Issuer を押します
• テキストボックスに JWT issuer の URL を追加し、Create を押します

W&B は、${ISSUER_URL}/.well-known/oidc-configuration のパスで OIDC discovery document を自動的に検索し、discovery document 内の関連する URL で JSON Web Key Set (JWKS) を見つけようとします。JWKS は、JWT が関連する identity provider によって発行されたことを確認するために、JWT のリアルタイム検証に使用されます。

JWT を使用して W&B にアクセスする

JWT issuer が W&B organization 用に設定されると、ユーザーはその identity provider によって発行された JWT を使用して、関連する W&B プロジェクト へのアクセスを開始できます。JWT を使用するメカニズムは次のとおりです。

• organization で利用可能なメカニズムのいずれかを使用して、identity provider にサインインする必要があります。一部のプロバイダーには、API または SDK を使用して自動化された方法でアクセスできますが、関連する UI を使用してのみアクセスできるプロバイダーもあります。詳細については、W&B organization の管理者または JWT issuer の所有者にお問い合わせください。
• identity provider へのサインイン後に JWT を取得したら、安全な場所にファイルに保存し、環境変数 WANDB_IDENTITY_TOKEN_FILE に絶対ファイルパスを設定します。
• W&B SDK または CLI を使用して W&B project にアクセスします。SDK または CLI は、JWT を自動的に検出し、JWT が正常に検証された後、W&B access token と交換する必要があります。W&B access token は、AI ワークフローを有効にするための関連する API にアクセスするために使用されます。つまり、run、メトリクス、Artifacts などを ログ に記録します。access token は、デフォルトで ~/.config/wandb/credentials.json のパスに保存されます。環境変数 WANDB_CREDENTIALS_FILE を指定することで、そのパスを変更できます。

JWT の検証

JWT を W&B access token と交換し、project にアクセスする ワークフロー の一部として、JWT は次の検証を受けます。

• JWT 署名は、W&B organization レベルで JWKS を使用して検証されます。これは最初の防御線であり、これが失敗した場合、JWKS または JWT の署名方法に問題があることを意味します。
• JWT の iss クレームは、organization レベルで設定された issuer URL と同じである必要があります。
• JWT の sub クレームは、W&B organization で設定されているユーザーのメールアドレスと同じである必要があります。
• JWT の aud クレームは、AI ワークフローの一部としてアクセスしている project を収容する W&B organization の名前と同じである必要があります。Dedicated Cloud または Self-managed インスタンスの場合、インスタンスレベルの環境変数 SKIP_AUDIENCE_VALIDATION を true に設定して、オーディエンスクレームの検証をスキップするか、オーディエンスとして wandb を使用できます。
• JWT の exp クレームは、トークンが有効かどうか、または期限切れで更新が必要かどうかを確認するためにチェックされます。

外部サービスアカウント

W&B は、有効期間の長い APIキー を持つ組み込みのサービスアカウントを長年サポートしてきました。SDK および CLI 向けの identity federation 機能を使用すると、organization レベルで設定されているのと同じ issuer によって発行されている限り、JWT を認証に使用できる外部サービスアカウントも導入できます。team 管理者は、組み込みのサービスアカウントと同様に、team のスコープ内で外部サービスアカウントを設定できます。

外部サービスアカウントを設定するには:

• team の Service Accounts タブに移動します
• New service account を押します
• サービスアカウントの名前を入力し、Authentication Method として Federated Identity を選択し、Subject を入力して、Create を押します

外部サービスアカウントの JWT の sub クレームは、team 管理者が team レベルの Service Accounts タブでサブジェクトとして設定したものと同じである必要があります。そのクレームは、JWT の検証 の一部として検証されます。aud クレームの要件は、ヒューマンユーザー JWT の要件と同様です。

外部サービスアカウントの JWT を使用して W&B にアクセスする 場合、通常は、初期 JWT を生成し、継続的に更新する ワークフロー を自動化する方が簡単です。外部サービスアカウントを使用して ログ に記録された run をヒューマンユーザーに帰属させたい場合は、組み込みのサービスアカウントの場合と同様に、AI ワークフローの環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定できます。

2.1.4 - Use service accounts to automate workflows

サービスアカウントは、チーム内またはチーム間で、プロジェクトを横断して共通タスクを自動的に実行できる、人間ではないまたは機械の ユーザー を表します。

• 組織の 管理者 は、組織の スコープ で サービスアカウント を作成できます。
• チーム の 管理者 は、その チーム の スコープ で サービスアカウント を作成できます。

サービスアカウント の APIキー を使用すると、呼び出し元は サービスアカウント の スコープ 内の プロジェクト から読み取りまたは書き込みができます。

サービスアカウント を使用すると、複数の ユーザー または チーム による ワークフロー の集中管理、W&B Models の 実験管理 の自動化、または W&B Weave の トレース の ログ記録 が可能になります。 環境変数 WANDB_USERNAME または WANDB_USER_EMAIL のいずれかを使用することにより、人間の ユーザー の ID を サービスアカウント によって管理される ワークフロー に関連付けるオプションがあります。

組織スコープ の サービスアカウント

組織に スコープ された サービスアカウント は、 制限付き プロジェクト を除き、 チーム に関係なく、組織内のすべての プロジェクト で読み取りおよび書き込みの権限を持ちます。組織スコープ の サービスアカウント が 制限付き プロジェクト に アクセス するには、その プロジェクト の 管理者 が サービスアカウント を プロジェクト に明示的に追加する必要があります。

組織の 管理者 は、組織またはアカウント ダッシュボード の [ Service Accounts ] タブから、組織スコープ の サービスアカウント の APIキー を取得できます。

新しい組織スコープ の サービスアカウント を作成するには:

• 組織 ダッシュボード の [ Service Accounts ] タブにある [ New service account ] ボタンをクリックします。
• [ Name ] を入力します。
• サービスアカウント のデフォルト チーム を選択します。
• [ Create ] をクリックします。
• 新しく作成された サービスアカウント の横にある [ Copy API key ] をクリックします。
• コピーした APIキー を、シークレットマネージャーまたはその他の安全で アクセス 可能な場所に保存します。

チームスコープ の サービスアカウント

チームスコープ の サービスアカウント は、その チーム 内のすべての プロジェクト で読み取りおよび書き込みができます。ただし、その チーム 内の 制限付き プロジェクト は除きます。チームスコープ の サービスアカウント が 制限付き プロジェクト に アクセス するには、その プロジェクト の 管理者 が サービスアカウント を プロジェクト に明示的に追加する必要があります。

チーム の 管理者 として、チームスコープ の サービスアカウント の APIキー を <WANDB_HOST_URL>/<your-team-name>/service-accounts で取得できます。または、チーム の [ Team settings ] に移動し、[ Service Accounts ] タブを参照することもできます。

チーム の新しい チーム スコープ の サービスアカウント を作成するには:

• チーム の [ Service Accounts ] タブにある [ New service account ] ボタンをクリックします。
• [ Name ] を入力します。
• 認証 方法として [ Generate API key (Built-in) ] を選択します。
• [ Create ] をクリックします。
• 新しく作成された サービスアカウント の横にある [ Copy API key ] をクリックします。
• コピーした APIキー を、シークレットマネージャーまたはその他の安全で アクセス 可能な場所に保存します。

チームスコープ の サービスアカウント を使用する モデルトレーニング または 生成AI アプリ 環境 で チーム を構成しない場合、モデル の run または Weave トレース は、 サービスアカウント の親 チーム 内の名前付き プロジェクト に ログ 記録 されます。このようなシナリオでは、WANDB_USERNAME または WANDB_USER_EMAIL 変数 を使用した ユーザー 属性は、参照される ユーザー が サービスアカウント の親 チーム の一部である場合を除き、機能しません。

外部 サービスアカウント

Built-in サービスアカウント に加えて、W&B は、JSON Web Tokens (JWT) を発行できる ID プロバイダー (IdP) との Identity federation を使用して、W&B SDK および CLI を使用した チーム スコープ の External service accounts もサポートしています。

2.2 - Access management

組織内の ユーザー と Teams を管理する

一意の組織ドメインで W&B に最初にサインアップした ユーザー は、その組織の インスタンス管理者ロール として割り当てられます。組織管理者は、特定の ユーザー に チーム 管理者ロールを割り当てます。

チーム管理者 は、 チーム 内で管理権限を持つ組織内の ユーザー です。

組織管理者は、https://wandb.ai/account-settings/ で組織のアカウント 設定 にアクセスして使用し、 ユーザー の招待、 ユーザー のロールの割り当てまたは更新、 Teams の作成、組織からの ユーザー の削除、請求管理者の割り当てなどを行うことができます。詳細については、ユーザー の追加と管理を参照してください。

組織管理者が チーム を作成すると、インスタンス管理者または チーム 管理者は次のことができます。

• デフォルトでは、管理者のみがその チーム に ユーザー を招待したり、 チーム から ユーザー を削除したりできます。この 振る舞い を変更するには、チーム の 設定 を参照してください。
• チームメンバー のロールを割り当てるか、更新します。
• 新しい ユーザー が組織に参加したときに、自動的に ユーザー を チーム に追加します。

組織管理者と チーム 管理者の両方が、https://wandb.ai/<your-team-name> の チーム ダッシュボード を使用して Teams を管理します。詳細、および チーム のデフォルトのプライバシー 設定 の構成については、Teams の追加と管理を参照してください。

特定の Projects への可視性を制限する

W&B の Project のスコープを定義して、誰が W&B の Runs を表示、編集、および送信できるかを制限します。 チーム が機密 データ を扱う場合、 Project を表示できる ユーザー を制限すると特に役立ちます。

組織管理者、 チーム 管理者、または Project のオーナーは、 Project の可視性を 設定 および編集できます。

詳細については、Project の可視性を参照してください。

2.2.1 - Manage your organization

組織の管理者として、組織内の 個々のユーザーを管理 したり、Teams を管理 したりできます。

Team の管理者として、Teams を管理 できます。

組織内のユーザー管理を簡素化したい場合は、ユーザーと Team の管理の自動化 を参照してください。

組織名の変更

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンの アカウント セクションで、設定 を選択します。
3. 設定 タブ内で、一般 を選択します。
4. 名前の変更 ボタンを選択します。
5. 表示されるモーダル内で、組織の新しい名前を入力し、名前を保存 ボタンを選択します。

ユーザーの追加と管理

管理者として、組織のダッシュボードを使用して以下を行います。

• ユーザーの招待または削除。
• ユーザーの組織ロールの割り当てまたは更新、およびカスタムロールの作成。
• 課金管理者の割り当て。

組織管理者が組織にユーザーを追加する方法はいくつかあります。

1. 招待によるメンバー追加
2. SSO による自動プロビジョニング
3. ドメインキャプチャ

シートと料金

以下の表は、Models と Weave のシートの仕組みをまとめたものです。

ユーザーの招待

管理者は、ユーザーを組織、および組織内の特定の Team に招待できます。

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

ユーザーの自動プロビジョニング

SSO を構成し、SSO プロバイダーが許可している場合、一致するメールアドレスドメインを持つ W&B ユーザーは、シングルサインオン (SSO) で W&B Organization にサインインできます。SSO は、すべてのエンタープライズライセンスで利用できます。

W&B は、自動プロビジョニングユーザーにデフォルトで「メンバー」ロールを割り当てます。自動プロビジョニングされたユーザーのロールはいつでも変更できます。

SSO を使用したユーザーの自動プロビジョニングは、Dedicated cloud インスタンスと Self-managed デプロイメントではデフォルトでオンになっています。自動プロビジョニングはオフにすることができます。自動プロビジョニングをオフにすると、特定のユーザーを選択的に W&B 組織に追加できます。

以下のタブでは、デプロイメントタイプに基づいて SSO をオフにする方法について説明します。

• Dedicated cloud
• Self-managed

カスタムロールの作成

組織管理者は、表示のみまたはメンバーロールに基づいて新しいロールを作成し、追加の権限を追加して、きめ細かいアクセス制御を実現できます。Team 管理者は、Team メンバーにカスタムロールを割り当てることができます。カスタムロールは組織レベルで作成されますが、Team レベルで割り当てられます。

カスタムロールを作成するには:

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

これで、Team 管理者は Team の設定 から Team のメンバーにカスタムロールを割り当てることができます。

ドメインキャプチャ

ドメインキャプチャは、従業員が会社組織に参加するのに役立ち、新しいユーザーが会社の管轄外で資産を作成しないようにします。

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

ユーザーのロールの割り当てまたは更新

Organization のすべてのメンバーは、W&B Models と Weave の両方に対して組織ロールとシートを持っています。シートのタイプによって、課金ステータスと各製品ラインで実行できるアクションが決まります。

最初にユーザーを組織に招待するときに、ユーザーに組織ロールを割り当てます。ユーザーのロールは後で変更できます。

組織内のユーザーは、次のいずれかのロールを持つことができます。

ユーザーのロールを変更するには:

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンから、ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. ユーザーの名前の横にある TEAM ROLE ドロップダウンからロールを選択します。

ユーザーのアクセスの割り当てまたは更新

組織内のユーザーは、フル、ビューアー、またはアクセスなしのいずれかのモデルシートまたは Weave アクセスタイプを持っています。

モデルシートタイプと Weave アクセスタイプは組織レベルで定義され、Team に継承されます。ユーザーのシートタイプを変更する場合は、組織の設定に移動し、次の手順に従ってください。

1. SaaS ユーザーの場合は、https://wandb.ai/account-settings/<organization>/settings で組織の設定に移動します。山かっこ (<>) で囲まれた値を組織名に置き換えてください。他の Dedicated および Self-managed デプロイメントの場合は、https://<your-instance>.wandb.io/org/dashboard に移動します。
2. ユーザー タブを選択します。
3. ロール ドロップダウンから、ユーザーに割り当てるシートタイプを選択します。

ユーザーの削除

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンから、ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. 表示されたら、省略記号または 3 つのドットのアイコン (…) を選択します。
5. ドロップダウンから、メンバーを削除 を選択します。

課金管理者の割り当て

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンから、ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. 課金管理者 列で、課金管理者として割り当てるユーザーを選択します。

Team の追加と管理

組織のダッシュボードを使用して、組織内に Team を作成および管理します。組織管理者または Team 管理者は次のことができます。

• ユーザーを Team に招待したり、Team からユーザーを削除したりします。
• Team メンバーのロールを管理します。
• 組織に参加するときに、ユーザーを Team に自動的に追加します。
• https://wandb.ai/<team-name> の Team のダッシュボードで Team のストレージを管理します。

Team の作成

組織のダッシュボードを使用して Team を作成します。

1. https://wandb.ai/home に移動します。
2. 左側のナビゲーションパネルの Team の下にある コラボレーションする Team を作成 を選択します。
3. 表示されるモーダルの Team 名 フィールドに Team の名前を入力します。
4. ストレージタイプを選択します。
5. Team を作成 ボタンを選択します。

Team を作成 ボタンを選択すると、W&B は https://wandb.ai/<team-name> の新しい Team ページにリダイレクトします。<team-name> は、Team の作成時に入力した名前で構成されます。

Team を作成したら、その Team にユーザーを追加できます。

Team へのユーザーの招待

組織内の Team にユーザーを招待します。Team のダッシュボードを使用して、メールアドレスまたは W&B のユーザー名を使用してユーザーを招待します (すでに W&B アカウントを持っている場合)。

1. https://wandb.ai/<team-name> に移動します。
2. ダッシュボードの左側にあるグローバルナビゲーションで Team の設定 を選択します。
3. ユーザー タブを選択します。
4. 新しいユーザーを招待 を選択します。
5. 表示されるモーダルで、メールアドレスまたはユーザー名 フィールドにユーザーのメールアドレスを入力し、Team ロールを選択 ドロップダウンからユーザーに割り当てるロールを選択します。ユーザーが Team で持つことができるロールの詳細については、Team ロール を参照してください。
6. 招待を送信 ボタンを選択します。

デフォルトでは、Team またはインスタンス管理者のみが Team にメンバーを招待できます。この振る舞いを変更するには、Team の設定 を参照してください。

メールでの招待を使用して手動でユーザーを招待するだけでなく、新しいユーザーの メールが組織のドメインと一致する 場合、新しいユーザーを Team に自動的に追加できます。

サインアップ時にメンバーを Team 組織に一致させる

組織内の新しいユーザーがサインアップ時に組織内の Teams を見つけられるようにします。新しいユーザーは、組織の検証済みメールアドレスドメインと一致する検証済みのメールアドレスドメインを持っている必要があります。検証済みの新しいユーザーは、W&B アカウントにサインアップするときに、組織に属する検証済みの Team のリストを表示できます。

組織管理者は、ドメインの要求を有効にする必要があります。ドメインキャプチャを有効にするには、ドメインキャプチャ に記載されている手順を参照してください。

Team メンバーのロールの割り当てまたは更新

1. Team メンバーの名前の横にあるアカウントタイプのアイコンを選択します。
2. ドロップダウンから、Team メンバーに持たせるアカウントタイプを選択します。

次の表に、Team のメンバーに割り当てることができるロールを示します。

Team からのユーザーの削除

Team のダッシュボードを使用して Team からユーザーを削除します。run を作成したメンバーがその Team にいなくなった場合でも、W&B は Team で作成された run を保持します。

1. https://wandb.ai/<team-name> に移動します。
2. 左側のナビゲーションバーで Team の設定 を選択します。
3. ユーザー タブを選択します。
4. 削除するユーザーの名前の横にマウスを移動します。表示されたら、省略記号または 3 つのドットのアイコン (…) を選択します。
5. ドロップダウンから、ユーザーを削除 を選択します。

2.2.2 - Manage access control for projects

W&B のプロジェクトのスコープを定義して、誰が W&B の run を表示、編集、送信できるかを制限します。

いくつかのコントロールを組み合わせて、W&B の Teams 内のプロジェクトに対するアクセスレベルを設定できます。可視性スコープ は、より高レベルなメカニズムです。これを使用して、どのユーザーグループがプロジェクト内の run を表示または送信できるかを制御します。Team または Restricted の可視性スコープを持つプロジェクトの場合、プロジェクトレベルのロール を使用して、各 ユーザー がプロジェクト内で持つアクセスレベルを制御できます。

可視性スコープ

選択できるプロジェクトの可視性スコープは 4 つあります。最も公開されているものから最もプライベートなものの順に示します。

新規または既存のプロジェクトに可視性スコープを設定する

プロジェクトの可視性スコープは、プロジェクトの作成時、または後で編集するときに設定します。

新しいプロジェクトを作成するときに可視性スコープを設定する

1. SaaS Cloud、 専用クラウド 、またはセルフマネージドインスタンスで、W&B 組織に移動します。
2. 左側のサイドバーの My projects セクションにある Create a new project ボタンをクリックします。または、 Team の Projects タブに移動し、右上隅にある Create new project ボタンをクリックします。
3. 親 Team を選択し、プロジェクトの名前を入力したら、Project Visibility ドロップダウンから目的のスコープを選択します。

Restricted の可視性スコープを選択した場合は、次の手順を完了してください。

4. Invite team members フィールドに、1 人または複数の W&B の チームメンバー の名前を入力します。プロジェクトで共同作業するために不可欠なメンバーのみを追加してください。

既存のプロジェクトの可視性スコープを編集する

1. W&B の プロジェクト に移動します。
2. 左側の列で Overview タブを選択します。
3. 右上隅にある Edit Project Details ボタンをクリックします。
4. Project Visibility ドロップダウンから、目的のスコープを選択します。

Restricted の可視性スコープを選択した場合は、次の手順を完了してください。

5. プロジェクトの Users タブに移動し、Add user ボタンをクリックして、特定の ユーザー を制限付きプロジェクトに招待します。

制限付きスコープに関するその他の重要な注意事項

• 制限付きプロジェクトで Team レベルの サービス アカウント を使用する場合は、その サービス アカウント をプロジェクトに明示的に招待または追加する必要があります。そうしないと、 Team レベルの サービス アカウント はデフォルトで制限付きプロジェクトにアクセスできません。
• 制限付きプロジェクトから run を移動することはできませんが、制限されていないプロジェクトから制限付きプロジェクトに run を移動することはできます。
• Team のプライバシー設定 将来のすべての Team プロジェクトを非公開にする (公開共有は許可されません) に関係なく、制限付きプロジェクトの可視性を Team スコープのみに変換できます。
• 制限付きプロジェクトのオーナーが親 Team の一部でなくなった場合、 Team 管理者はプロジェクトのシームレスな運用を確保するためにオーナーを変更する必要があります。

プロジェクトレベルのロール

Team 内の Team または Restricted スコープのプロジェクトの場合、 ユーザー に特定のロールを割り当てることができます。これは、その ユーザー の Team レベルのロールとは異なる場合があります。たとえば、 ユーザー が Team レベルで Member ロールを持っている場合、その Team 内の Team または Restricted スコープのプロジェクト内で、その ユーザー に View-Only、Admin、または使用可能なカスタムロールを割り当てることができます。

ユーザー にプロジェクトレベルのロールを割り当てる

1. W&B の プロジェクト に移動します。
2. 左側の列で Overview タブを選択します。
3. プロジェクトの Users タブに移動します。
4. Project Role フィールドで、関係する ユーザー に現在割り当てられているロールをクリックします。これにより、他の使用可能なロールを一覧表示するドロップダウンが開きます。
5. ドロップダウンから別のロールを選択します。すぐに保存されます。

プロジェクトレベルのロールに関するその他の重要な注意事項

• デフォルトでは、Team または Restricted スコープのプロジェクト内のすべての ユーザー のプロジェクトレベルのロールは、それぞれの Team レベルのロールを 継承 します。
• Team レベルで View-only ロールを持っている ユーザー のプロジェクトレベルのロールを 変更することはできません。
• 特定のプロジェクト内の ユーザー のプロジェクトレベルのロールが Team レベルのロール と同じである 場合、 Team 管理者が Team レベルのロールを変更すると、関連するプロジェクトロールは Team レベルのロールを追跡するように自動的に変更されます。
• 特定のプロジェクト内の ユーザー のプロジェクトレベルのロールを、Team レベルのロール とは異なる ように変更した場合、 Team 管理者が Team レベルのロールを変更しても、関連するプロジェクトレベルのロールはそのままになります。
• プロジェクトレベルのロールが Team レベルのロールと異なる場合に、 ユーザー を restricted プロジェクトから削除し、しばらくしてからその ユーザー をプロジェクトに再度追加すると、デフォルトの動作により Team レベルのロールを継承します。必要に応じて、プロジェクトレベルのロールを再度変更して、 Team レベルのロールと異なるようにする必要があります。

2.3 - Automate user and team management

SCIM API

SCIM API を使用して、ユーザーと、ユーザーが所属する Teams を効率的かつ反復可能な方法で管理します。SCIM API を使用して、カスタムロールを管理したり、W&B organization 内の Users にロールを割り当てることもできます。ロールエンドポイントは、公式の SCIM スキーマの一部ではありません。W&B は、カスタムロールの自動管理をサポートするために、ロールエンドポイントを追加します。

SCIM API は、特に次のような場合に役立ちます。

• 大規模なユーザーのプロビジョニングとプロビジョニング解除を管理する
• SCIM をサポートする Identity Provider で Users を管理する

SCIM API には、大きく分けて User、Group、Roles の 3 つのカテゴリがあります。

User SCIM API

User SCIM API を使用すると、User の作成、非アクティブ化、詳細の取得、または W&B organization 内のすべての Users の一覧表示が可能です。この API は、定義済みまたはカスタムロールを organization 内の Users に割り当てることもサポートしています。

Group SCIM API

Group SCIM API を使用すると、organization 内の Teams の作成や削除など、W&B Teams を管理できます。PATCH Group を使用して、既存の Team に Users を追加または削除します。

Custom role API

Custom role SCIM API を使用すると、organization 内のカスタムロールの作成、一覧表示、または更新など、カスタムロールを管理できます。

W&B Python SDK API

SCIM API で User と Team の管理を自動化できるのと同じように、W&B Python SDK API で利用できる メソッド の一部もその目的に使用できます。次の メソッド に注意してください。

2.4 - Manage users, groups, and roles with SCIM

System for Cross-domain Identity Management（SCIM）API を使用すると、インスタンスまたは organization の管理者は、W&B organization 内の user、グループ、およびカスタムロールを管理できます。SCIM グループは W&B の Teams にマッピングされます。

SCIM API は <host-url>/scim/ でアクセスでき、RC7643 プロトコルにあるフィールドのサブセットを使用して、/Users および /Groups エンドポイントをサポートします。さらに、公式の SCIM スキーマにはない /Roles エンドポイントが含まれています。W&B は、W&B organization でのカスタムロールの自動管理をサポートするために、/Roles エンドポイントを追加します。

認証

organization またはインスタンスの管理者は、 APIキー を使用して基本認証で SCIM API にアクセスできます。HTTP リクエストの Authorization ヘッダーを文字列 Basic に設定し、その後にスペース、次に username:API-KEY の形式で base-64 エンコードされた文字列を設定します。つまり、username と APIキー を : 文字で区切られた value に置き換え、その結果を base-64 エンコードします。たとえば、demo:p@55w0rd として認証するには、ヘッダーを Authorization: Basic ZGVtbzpwQDU1dzByZA== にする必要があります。

User リソース

SCIM の user リソースは W&B の Users にマッピングされます。

User を取得

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: GET
• 説明: user の一意の ID を指定して、SaaS Cloud organization または Dedicated Cloud あるいは Self-managed インスタンス内の特定の user の情報を取得します。
• リクエストの例:

GET /scim/Users/abc

• レスポンスの例:

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

Users をリスト表示

• エンドポイント: <host-url>/scim/Users
• メソッド: GET
• 説明: SaaS Cloud organization または Dedicated Cloud あるいは Self-managed インスタンス内のすべての Users のリストを取得します。
• リクエストの例:

GET /scim/Users

• レスポンスの例:

(Status 200)

{
    "Resources": [
        {
            "active": true,
            "displayName": "Dev User 1",
            "emails": {
                "Value": "dev-user1@test.com",
                "Display": "",
                "Type": "",
                "Primary": true
            },
            "id": "abc",
            "meta": {
                "resourceType": "User",
                "created": "2023-10-01T00:00:00Z",
                "lastModified": "2023-10-01T00:00:00Z",
                "location": "Users/abc"
            },
            "schemas": [
                "urn:ietf:params:scim:schemas:core:2.0:User"
            ],
            "userName": "dev-user1"
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 1
}

User を作成

• エンドポイント: <host-url>/scim/Users
• メソッド: POST
• 説明: 新しい user リソースを作成します。
• サポートされているフィールド:

• リクエストの例:

POST /scim/Users

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "emails": [
    {
      "primary": true,
      "value": "admin-user2@test.com"
    }
  ],
  "userName": "dev-user2"
}

• レスポンスの例:

(Status 201)

{
    "active": true,
    "displayName": "Dev User 2",
    "emails": {
        "Value": "dev-user2@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "def",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "location": "Users/def"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user2"
}

User を削除

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: DELETE
• 説明: user の一意の ID を指定して、SaaS Cloud organization または Dedicated Cloud あるいは Self-managed インスタンスから user を完全に削除します。必要に応じて、User を作成 API を使用して、user を organization またはインスタンスに再度追加します。
• リクエストの例:

DELETE /scim/Users/abc

• レスポンスの例:

(Status 204)

User を非アクティブ化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: user の一意の ID を指定して、Dedicated Cloud または Self-managed インスタンス内の user を一時的に非アクティブ化します。必要に応じて、User を再アクティブ化 API を使用して、user を再アクティブ化します。
• サポートされているフィールド:

• リクエストの例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": false}
        }
    ]
}

• レスポンスの例: これにより、User オブジェクトが返されます。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

User を再アクティブ化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: user の一意の ID を指定して、Dedicated Cloud または Self-managed インスタンス内の非アクティブ化された user を再アクティブ化します。
• サポートされているフィールド:

• リクエストの例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": true}
        }
    ]
}

• レスポンスの例: これにより、User オブジェクトが返されます。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

User に organization レベルのロールを割り当てる

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: user に organization レベルのロールを割り当てます。ロールは、こちらで説明されているように、admin、viewer、または member のいずれかになります。SaaS Cloud の場合は、user 設定で SCIM API 用に正しい organization を構成していることを確認してください。
• サポートされているフィールド:

• リクエストの例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin" // user の organization スコープのロールを admin に設定します
        }
    ]
}

• レスポンスの例: これにより、User オブジェクトが返されます。

(Status 200)