Deployment options

• 1: Use W&B Multi-tenant SaaS
• 2: Dedicated Cloud
• 2.1: Supported Dedicated Cloud regions
• 2.2: Export data from Dedicated cloud
• 3: Self-managed
• 3.1: Reference Architecture
• 3.2: Run W&B Server on Kubernetes
• 3.2.1: Kubernetes operator for air-gapped instances
• 3.3: Install on public cloud
• 3.3.1: Deploy W&B Platform on AWS
• 3.3.2: Deploy W&B Platform on GCP
• 3.3.3: Deploy W&B Platform on Azure
• 3.4: Deploy W&B Platform On-premises
• 3.5: Update W&B license and version

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 に直接アクセス してください。エンタープライズプランを開始するには、このフォーム を送信してください。

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からの 専用クラウド への移行がサポートされています。

次のステップ

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

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 を参照してください。

2.2 - Export data from Dedicated cloud

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

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

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 ボタンを選択します。

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

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

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

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 は内部リソースのみを使用し、パブリックリポジトリへの接続を試みません。

3.3 - Install on public cloud

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 構成へのスムーズな移行が保証されます。

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

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 には、標準オプションと 推奨されるデプロイメント にある最小限の構成とともに組み合わせることができる、いくつかのオプションが用意されています。

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

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. 新しいライセンス キー を入力して変更を保存します。