> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

> エアギャップ環境やインターネットから切断された Kubernetes 環境に W&B プラットフォームをデプロイします

# エアギャップ環境の Kubernetes へのデプロイ

<h2 id="introduction">
  はじめに
</h2>

このガイドでは、エアギャップ環境、オフライン環境、またはネットワークが制限されたお客様管理の環境に W\&B プラットフォームをデプロイする手順を詳しく説明します。このガイドに従うと、W\&B のイメージとチャートをホストする内部コンテナーレジストリと Helm リポジトリを設定し、W\&B Kubernetes Operator をインストールしたうえで、外部へのインターネット接続なしで W\&B プラットフォームをデプロイできます。このガイドは、規制対象のネットワークや隔離されたネットワークで Kubernetes インフラストラクチャーを管理するプラットフォーム管理者および DevOps エンジニアを対象としています。

エアギャップ環境でのデプロイメントは、次のような環境で一般的です。

* 高度なセキュリティが求められる政府施設。
* 厳格なネットワーク分離を行っている金融機関。
* コンプライアンス要件のある医療機関。
* 産業用制御システム (ICS) 環境。
* 機密ネットワークを持つ研究施設。

これらのコマンドは、Kubernetes クラスターへの適切なアクセス権を持つシェルコンソールで実行してください。Kubernetes アプリケーションのデプロイに使用している CI/CD ツールに合わせて、これらのコマンドを調整することもできます。

インターネットに接続された標準的なオンプレミスの Kubernetes デプロイメントについては、[Kubernetes Operator を使用して W\&B をデプロイする](/ja/products/wandb/platform/hosting/self-managed/operator)を参照してください。

<h2 id="prerequisites">
  前提条件
</h2>

作業を開始する前に、エアギャップ環境が次の要件を満たしていることを確認してください。

<h3 id="version-requirements">
  バージョン要件
</h3>

| ソフトウェア | 最低バージョン |
| - | - |
| Kubernetes | v1.34 以降 ([サポートされる Kubernetes バージョン](https://kubernetes.io/releases/patch-releases/)) |
| Helm | v3.x |
| MySQL | W\&B Self-Managed のデプロイメントでは、セキュリティパッチと重要なバグ修正が提供されている、サポート対象の MySQL バージョンを実行する必要があります。**MySQL 8.4.x** をインストールするか、同バージョンにアップグレードしてください。または、プロバイダーがサポート対象かつパッチ適用済みと明記しているマネージドサービスのバージョンを使用してください。<br />Aurora MySQL のバージョン文字列は、コミュニティ版 MySQL のバージョンとは異なります。データベースエンジンの完全なバージョン文字列を確認するには `SELECT version()` を、Aurora のバージョンを確認するには `SELECT aurora_version()` を使用してください。[Aurora MySQL バージョン 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) は MySQL 8.0.x と互換性があり、引き続きサポートされています。移行先のバージョンを選択する際は、[Amazon Aurora のバージョン管理](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.Versioning.html) およびご利用のクラウドプロバイダーのドキュメントを参照してください。 |
| Redis | v7.x |
| ClickHouse | セルフマネージドのデプロイで Weave を使用する場合は必須です。Weave を使用しないデプロイメントでは不要です。[アップグレード時の ClickHouse 互換性](/ja/products/wandb/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) および [サポートされる W\&B Server リリース](/ja/release-notes/server-releases) を参照してください。 |

<h3 id="ssltls-requirements">
  SSL/TLS の要件
</h3>

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

<Warning>
  W\&B は自己署名証明書やカスタム CA をサポートしていません。自己署名証明書はユーザー側で問題を引き起こすため、サポート対象外です。
</Warning>

可能であれば、[Let's Encrypt](https://letsencrypt.org) などのサービスを使用して、信頼された証明書をロードバランサーに提供してください。Caddy や Cloudflare などのサービスを利用すると、SSL の管理を任せることができます。

セキュリティポリシー上、信頼されたネットワーク内でも SSL 通信が必要な場合は、Istio などのツールと[サイドカーコンテナー](https://istio.io/latest/docs/reference/config/networking/sidecar/)の使用を検討してください。

<h3 id="hardware-requirements">
  ハードウェア要件
</h3>

**CPU アーキテクチャー**: W\&B は Intel (x86) の CPU アーキテクチャーでのみ動作します。ARM はサポートされていません。

**Sizing**: Kubernetes ノードおよび MySQL の CPU、メモリ、ディスクのサイジングに関する推奨事項については、リファレンスアーキテクチャの [Sizing セクション](/ja/products/wandb/platform/hosting/self-managed/ref-arch#sizing) を参照してください。要件は、Models と Weave のどちらを実行するか、または両方を実行するかによって異なります。

<h3 id="mysql-database">
  MySQL データベース
</h3>

W\&B には外部の MySQL データベースが必要です。

本番環境では、マネージドデータベースサービスの使用を推奨します。

* [AWS RDS Aurora MySQL](https://aws.amazon.com/rds/aurora/)
* [Google Cloud SQL for MySQL](https://cloud.google.com/sql/mysql)
* [Azure Database for MySQL](https://azure.microsoft.com/en-us/products/mysql/)

マネージドデータベースサービスは、自動バックアップ、モニタリング、高可用性、パッチ適用などの機能を備えており、運用上の負担を軽減できます。

サイジングの推奨事項や設定パラメーターなど、MySQL の要件については[リファレンスアーキテクチャ](/ja/products/wandb/platform/hosting/self-managed/ref-arch#mysql)を参照してください。データベースを作成するための SQL については、[ベアメタルガイド](/ja/products/wandb/platform/hosting/self-managed/operator#mysql-database)を参照してください。デプロイメントのデータベース設定に関するご質問は、[サポート](mailto:forge-support@coreweave.com)または担当の AISE にお問い合わせください。

セルフマネージドインスタンスの MySQL 設定パラメーターについては、[リファレンスアーキテクチャの MySQL 設定セクション](/ja/products/wandb/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters)を参照してください。

<h3 id="redis">
  Redis
</h3>

W\&B は単一ノード構成の Redis 7.x デプロイメントを必要とし、W\&B の各コンポーネントはこれをジョブのキュー管理やデータのキャッシュに使用します。テストや概念実証 (PoC) 向けに、W\&B Self-Managed にはローカルの Redis デプロイメントが含まれています。このバンドルされたデプロイメントは、本番環境での使用には適していません。

本番環境のデプロイメントでは、W\&B は次の環境にある Redis インスタンスに接続できます。

* [Amazon ElastiCache](https://aws.amazon.com/elasticache/)
* [Google Cloud Memorystore](https://cloud.google.com/memorystore?hl=en)
* [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache)
* クラウドまたはオンプレミスのインフラストラクチャー上でセルフホストしている Redis

<h3 id="object-storage">
  オブジェクトストレージ
</h3>

W\&B には、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。

W\&B では、次のストレージプロバイダーを推奨しています。

* [Amazon S3](https://aws.amazon.com/s3/): スケーラビリティ、データの可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。
* [Google Cloud Storage](https://cloud.google.com/storage): 非構造化データを大規模に保存するためのマネージドサービスです。
* [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs): 非構造化データを大規模に保存するためのクラウドベースのオブジェクトストレージです。
* [CoreWeave AI Object Storage](/products/storage/object-storage): AI ワークロード向けに最適化された S3互換のオブジェクトストレージです。
* [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor)、[NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) などのエンタープライズ向け S3互換ストレージ、またはその他のエンタープライズソリューション。

<Note>
  MinIO のオープンソース版は[メンテナンスモード](https://github.com/minio/minio)に移行しており、現在は開発が行われておらず、コンパイル済みバイナリも提供されていません。本番デプロイメントでは、マネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ向け S3互換ソリューションの使用を推奨します。
</Note>

プロバイダーを選択したら、W\&B がアクセスできるようにバケットを設定します。IAM ポリシー、CORS 設定、アクセスのセットアップなど、バケットのプロビジョニング手順の詳細については、[Bring Your Own Bucket (BYOB) ガイド](/ja/products/wandb/platform/hosting/data-security/secure-storage-connector)を参照してください。

キャパシティやパフォーマンスに関するガイダンスなど、オブジェクトストレージ要件の一覧については、[リファレンスアーキテクチャのオブジェクトストレージセクション](/ja/products/wandb/platform/hosting/self-managed/ref-arch#object-storage)を参照してください。

オブジェクトストレージのプロビジョニングについて詳しくは、[Bring Your Own Bucket (BYOB)](/ja/products/wandb/platform/hosting/data-security/secure-storage-connector) ガイドを参照してください。エアギャップ環境では通常、MinIO Enterprise、NetApp StorageGRID、Dell ECS などのオンプレミスの S3互換ストレージを使用します。

<h3 id="air-gapped-specific-requirements">
  エアギャップ環境固有の要件
</h3>

前述の標準要件に加えて、エアギャップ環境のデプロイメントには以下が必要です。

* **内部コンテナーレジストリ**: Harbor、JFrog Artifactory、Nexus などのプライベートコンテナーレジストリにアクセスでき、必要な W\&B イメージがすべて格納されていること。
* **内部 Helm リポジトリ**: W\&B の Helm チャートを格納したプライベート Helm チャートリポジトリにアクセスできること。
* **イメージ転送手段**: インターネットに接続されたシステムから、エアギャップ環境のレジストリへコンテナーイメージを転送する手段があること。
* **ライセンスファイル**: 有効な W\&B Enterprise ライセンス。ライセンスの取得方法 (インターネットに接続されたマシンから取得する場合など) については、要件ページの [License](/ja/products/wandb/platform/hosting/self-managed/requirements#license) セクションを参照するか、W\&B のアカウントチームにお問い合わせください。

ネットワークやロードバランサーの設定を含むインフラストラクチャー要件の詳細については、[リファレンスアーキテクチャ](/ja/products/wandb/platform/hosting/self-managed/ref-arch#infrastructure-requirements)を参照してください。

<h2 id="prepare-your-air-gapped-environment">
  エアギャップ環境を準備する
</h2>

以下の手順では、W\&B のコンテナーイメージと Helm チャートをホストするためのエアギャップ環境を準備します。オペレーターのインストールやプラットフォームのデプロイを行う前に、これらの手順を完了してください。

<h3 id="step-1-set-up-internal-container-registry">
  ステップ 1: 内部コンテナーレジストリを設定する
</h3>

Kubernetes クラスターはパブリックレジストリからイメージをプルできないため、デプロイの前に、必要なすべてのコンテナーイメージをエアギャップ環境の内部コンテナーレジストリに用意しておく必要があります。

<Note>
  W\&B Operator の要件を把握し、コンテナーレジストリのイメージを定期的に最新の状態に保つのはお客様の責任です。必要なコンテナーイメージとそのバージョンの最新の一覧については、Helm チャートを参照するか、[W\&B Support](mailto:forge-support@coreweave.com) または担当の W\&B サポートエンジニアにお問い合わせください。
</Note>

<h4 id="core-wb-component-containers">
  W\&B コアコンポーネントのコンテナー
</h4>

次のコアイメージが必要です。

* [`docker.io/wandb/controller`](https://hub.docker.com/r/wandb/controller): W\&B Kubernetes Operator
* [`docker.io/wandb/local`](https://hub.docker.com/r/wandb/local): W\&B アプリケーションサーバー
* [`docker.io/wandb/console`](https://hub.docker.com/r/wandb/console): W\&B 管理コンソール
* [`docker.io/wandb/megabinary`](https://hub.docker.com/r/wandb/megabinary): W\&B マイクロサービス (API、executor、glue、parquet)

<h4 id="dependency-containers">
  依存関係のコンテナー
</h4>

次のサードパーティ製の依存関係イメージが必要です。

* [`docker.io/bitnamilegacy/redis`](https://hub.docker.com/r/bitnamilegacy/redis): テストおよび開発時にローカルで Redis をデプロイする際に必要です。本番環境における Redis の要件については、前提条件の [Redis セクション](#redis) を参照してください。
* [`docker.io/otel/opentelemetry-collector-contrib`](https://hub.docker.com/r/otel/opentelemetry-collector-contrib): メトリクスとログを収集するための OpenTelemetry エージェントです。
* [`quay.io/prometheus/prometheus`](https://quay.io/repository/prometheus/prometheus): メトリクスを収集するための Prometheus です。
* [`quay.io/prometheus-operator/prometheus-config-reloader`](https://quay.io/repository/prometheus-operator/prometheus-config-reloader): Prometheus の依存関係です。

<h4 id="get-the-complete-image-list">
  イメージの完全なリストを取得する
</h4>

Helm チャートから、必要なイメージとバージョンの完全なリストを抽出するには、次の手順を実行します。

1. インターネットに接続されたシステムで、[W\&B Helm チャートのリポジトリ](https://github.com/wandb/helm-charts)から W\&B Helm チャートをダウンロードします。

   ```bash theme={"system"}
   # helm-charts リポジトリをクローンする
   git clone https://github.com/wandb/helm-charts.git
   cd helm-charts
   ```

2. `values.yaml` ファイルを確認し、すべてのコンテナーイメージとそのバージョンを特定します。

   ```bash theme={"system"}
   # オペレーターチャートからイメージの参照を抽出する
   helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#"

   # プラットフォームチャートからイメージの参照を抽出する
   helm show values charts/operator-wandb | grep -E "repository:|tag:" | grep -v "^#"
   ```

   リポジトリ名のみ (バージョンタグを除く) を抽出する場合は、次のコマンドを使用することもできます。

   ```bash theme={"system"}
   helm show values charts/operator-wandb \
     | awk -F': *' '/^[[:space:]]*repository:/{print $2}' \
     | grep -v "^#" \
     | sort -u
   ```

   リポジトリのリストは次のようになります。

   ```text theme={"system"}
   wandb/controller
   wandb/local
   wandb/console
   wandb/megabinary
   wandb/weave-python
   wandb/weave-trace
   otel/opentelemetry-collector-contrib
   prometheus/prometheus
   prometheus-operator/prometheus-config-reloader
   bitnamilegacy/redis
   ```

   各イメージの具体的なバージョンタグを取得するには、前述の最初のコマンド (`grep -E "repository:|tag:"`) を使用してください。このコマンドを実行すると、リポジトリ名と対応するバージョンタグの両方が表示されます。

<h4 id="transfer-images-to-air-gapped-registry">
  エアギャップ環境のレジストリにイメージを転送する
</h4>

1. インターネットに接続されたシステムで、必要なイメージをすべてプルして保存します。

   <Note>
     以下の例に含まれるバージョン番号は、前のステップで Helm チャートを確認した際の実際のバージョンに置き換えてください。ここに示すバージョンはあくまで例であり、時間の経過とともに古くなります。
   </Note>

   シェル変数を使用すると、バージョンを一貫して管理できます。

   ```bash theme={"system"}
   # バージョン変数を設定します（Helm チャートのバージョンに合わせて更新してください）
   CONTROLLER_VERSION="1.13.3"
   APP_VERSION="0.59.2"
   CONSOLE_VERSION="2.12.2"

   # イメージをプルします
   docker pull wandb/controller:${CONTROLLER_VERSION}
   docker pull wandb/local:${APP_VERSION}
   docker pull wandb/console:${CONSOLE_VERSION}
   docker pull wandb/megabinary:${APP_VERSION}
   # ... その他の必要なイメージもすべて、それぞれのバージョンでプルします

   # イメージを .tar ファイルに保存します
   docker save wandb/controller:${CONTROLLER_VERSION} -o wandb-controller-${CONTROLLER_VERSION}.tar
   docker save wandb/local:${APP_VERSION} -o wandb-local-${APP_VERSION}.tar
   docker save wandb/console:${CONSOLE_VERSION} -o wandb-console-${CONSOLE_VERSION}.tar
   docker save wandb/megabinary:${APP_VERSION} -o wandb-megabinary-${APP_VERSION}.tar
   # ... その他のイメージもすべて保存します
   ```

2. USB ドライブや安全なファイル転送など、承認された方法で `.tar` ファイルをエアギャップ環境に転送します。

3. エアギャップ環境で、イメージを読み込んで内部レジストリにプッシュします。

   ```bash theme={"system"}
   # 上記と同じバージョン変数を設定します
   CONTROLLER_VERSION="1.13.3"
   APP_VERSION="0.59.2"
   CONSOLE_VERSION="2.12.2"
   INTERNAL_REGISTRY="registry.yourdomain.com"

   # イメージを読み込みます
   docker load -i wandb-controller-${CONTROLLER_VERSION}.tar
   docker load -i wandb-local-${APP_VERSION}.tar
   docker load -i wandb-console-${CONSOLE_VERSION}.tar
   docker load -i wandb-megabinary-${APP_VERSION}.tar
   # ... その他のイメージもすべて読み込みます

   # 内部レジストリ用のタグを付けます
   docker tag wandb/controller:${CONTROLLER_VERSION} ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION}
   docker tag wandb/local:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION}
   docker tag wandb/console:${CONSOLE_VERSION} ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION}
   docker tag wandb/megabinary:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION}
   # ... その他のイメージにもすべてタグを付けます

   # 内部レジストリにプッシュします
   docker push ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION}
   docker push ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION}
   docker push ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION}
   docker push ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION}
   # ... その他のイメージもすべてプッシュします
   ```

<h3 id="step-2-set-up-internal-helm-chart-repository">
  ステップ 2: 内部 Helm チャートリポジトリを設定する
</h3>

コンテナーイメージの準備ができたら、次に Kubernetes Operator が W\&B の Helm チャートにもアクセスできるようにする必要があります。内部 Helm リポジトリで以下の Helm チャートを利用できることを確認してください。

* [W\&B Operator チャート](https://github.com/wandb/helm-charts/tree/main/charts/operator)
* [W\&B プラットフォームチャート](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)

1. インターネットに接続されたシステムで、チャートをダウンロードします。

   ```bash theme={"system"}
   # W&B Helm リポジトリを追加
   helm repo add wandb https://wandb.github.io/helm-charts
   helm repo update

   # チャートをダウンロード
   helm pull wandb/operator --version 1.13.3
   helm pull wandb/operator-wandb --version 0.18.0
   ```

2. `.tgz` 形式のチャートファイルをエアギャップ環境に転送し、組織のリポジトリ運用手順に従って内部 Helm リポジトリにアップロードします。

   `operator` チャートは W\&B Kubernetes Operator (コントローラーマネージャー) をデプロイします。`operator-wandb` チャートは、Custom Resource (CR) に設定された値を使用して W\&B プラットフォームをデプロイします。

<h3 id="step-3-configure-helm-repository-access">
  ステップ 3: Helm リポジトリへのアクセスを設定する
</h3>

エアギャップ環境内のローカル Helm クライアントが内部リポジトリを参照するように設定します。これにより、以降のインストールコマンドでチャートを検出できるようになります。

1. エアギャップ環境で、内部リポジトリを使用するように Helm を設定します。

   ```bash theme={"system"}
   helm repo add local-repo https://charts.yourdomain.com
   helm repo update
   ```

2. チャートが利用可能であることを確認します。

   ```bash theme={"system"}
   helm search repo local-repo/operator
   helm search repo local-repo/operator-wandb
   ```

<h2 id="deploy-wb-in-air-gapped-environment">
  エアギャップ環境に W\&B をデプロイする
</h2>

内部レジストリと Helm リポジトリの準備が整ったので、Kubernetes Operator をインストールし、外部サービスを設定して、W\&B プラットフォームをデプロイします。

<h3 id="step-4-install-the-kubernetes-operator">
  ステップ 4: Kubernetes Operator をインストールする
</h3>

W\&B Kubernetes Operator (コントローラーマネージャー) は、W\&B プラットフォームのコンポーネントを管理します。エアギャップ環境にインストールする場合は、内部コンテナーレジストリを使用するように設定します。

1. 次の内容で `values.yaml` ファイルを作成します。

   ```yaml theme={"system"}
   image:
     repository: registry.yourdomain.com/wandb/controller
     tag: 1.13.3

   airgapped: true
   ```

   <Note>
     リポジトリとタグは、ステップ 1 で内部レジストリに転送した実際のバージョンに置き換えてください。ここに示すバージョン (`1.13.3`) は一例であり、時間の経過とともに古くなります。
   </Note>

2. オペレーターとカスタムリソース定義 (CRD) をインストールします。

   ```bash theme={"system"}
   helm upgrade --install operator local-repo/operator \
     --namespace wandb \
     --create-namespace \
     --values values.yaml
   ```

3. オペレーターが実行されていることを確認します。

   ```bash theme={"system"}
   kubectl get pods -n wandb
   ```

   オペレーターの Pod が `Running` 状態になっていれば問題ありません。

これで W\&B Kubernetes Operator のインストールが完了し、内部チャートリポジトリから W\&B プラットフォームをデプロイできるようになりました。

サポートされる値の詳細については、[Kubernetes Operator GitHub リポジトリの values ファイル](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml)を参照してください。

<h3 id="step-5-set-up-mysql-database">
  ステップ 5: MySQL データベースを設定する
</h3>

W\&B Custom Resource を設定する前に、外部 MySQL データベースを設定します。本番環境のデプロイメントでは、可能であればマネージドデータベースサービスを使用することを W\&B は強く推奨しています。独自の MySQL インスタンスを運用する場合は、データベースとユーザーを作成してください。

次の SQL コマンドを使用して、データベースとユーザーを作成します。`[PASSWORD]` は安全なパスワードに置き換えてください。

```sql theme={"system"}
CREATE USER 'wandb_local'@'%' IDENTIFIED BY '[PASSWORD]';
CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION;
```

MySQL の設定パラメーターについては、[リファレンスアーキテクチャの MySQL 設定セクション](/ja/products/wandb/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters)を参照してください。

<h3 id="step-6-configure-wb-custom-resource">
  ステップ 6: W\&B Custom Resource を設定する
</h3>

W\&B Kubernetes Operator をインストールしたら、内部の Helm リポジトリとコンテナーレジストリを参照するように Custom Resource (CR) を設定します。この設定により、Kubernetes Operator は W\&B プラットフォームの必須コンポーネントをデプロイする際に、パブリックなソースにアクセスせず、内部レジストリとリポジトリを使用するようになります。

<Note>
  以下の設定例に含まれるイメージのバージョンタグは、時間の経過とともに古くなります。すべての `tag:` の値を、ステップ 1 で内部レジストリに転送した実際のバージョンに置き換えてください。
</Note>

次の内容で `wandb.yaml` という名前のファイルを作成します。

```yaml theme={"system"}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/instance: wandb
    app.kubernetes.io/name: weightsandbiases
  name: wandb
  namespace: wandb

spec:
  chart:
    url: https://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:9000
        path: wandb
        provider: s3
        region: us-east-1
      
      mysql:
        database: wandb
        host: mysql.yourdomain.com
        password: [YOUR-MYSQL-PASSWORD]
        port: 3306
        user: wandb
      
      redis:
        host: redis.yourdomain.com
        port: 6379
        password: [YOUR-REDIS-PASSWORD]
      
      api:
        enabled: true
      
      glue:
        enabled: true
      
      executor:
        enabled: true
      
      extraEnv:
        ENABLE_REGISTRY_UI: 'true'

    # すべてのコンポーネントのイメージを内部レジストリから取得するように設定します
    app:
      image:
        repository: registry.yourdomain.com/wandb/local
        tag: 0.59.2

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

    api:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    executor:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    glue:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    parquet:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    weave:
      image:
        repository: registry.yourdomain.com/wandb/weave-python
        tag: 0.59.2

    otel:
      image:
        repository: registry.yourdomain.com/otel/opentelemetry-collector-contrib
        tag: 0.97.0

    prometheus:
      server:
        image:
          repository: registry.yourdomain.com/prometheus/prometheus
          tag: v2.47.0
      configmapReload:
        prometheus:
          image:
            repository: registry.yourdomain.com/prometheus-operator/prometheus-config-reloader
            tag: v0.67.0

    ingress:
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: "0"
      class: nginx
```

<Note>
  ホスト名、パスワード、タグなどのプレースホルダー値はすべて、実際の設定値に置き換えてください。上記の例では、最もよく使用されるコンポーネントを示しています。
</Note>

デプロイメントの要件によっては、次のような追加コンポーネントのイメージリポジトリも設定する必要があります。

* `settingsMigrationJob`
* `weave-trace`
* `filestream`
* `flat-runs-table`

設定可能なコンポーネントの一覧については、[W\&B Helm リポジトリの values ファイル](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml)を参照してください。

<h3 id="step-7-deploy-the-wb-platform">
  ステップ 7: W\&B プラットフォームをデプロイする
</h3>

Custom Resource を適用すると、オペレーターが `wandb.yaml` の設定とイメージ参照に基づいて、`operator-wandb` チャートで定義されている W\&B プラットフォームのコンポーネントをインストールします。

1. W\&B Custom Resource を適用して、プラットフォームをデプロイします。

   ```bash theme={"system"}
   kubectl apply -f wandb.yaml
   ```

2. デプロイメントの進行状況を監視します。

   ```bash theme={"system"}
   # 作成される Pod を監視する
   kubectl get pods -n wandb --watch

   # デプロイメントのステータスを確認する
   kubectl get weightsandbiases -n wandb

   # オペレーターのログを表示する
   kubectl logs -n wandb deployment/wandb-operator-controller-manager
   ```

   オペレーターが必要なコンポーネントをすべて作成するまで、デプロイメントには数分かかる場合があります。

<h2 id="openshift-configuration">
  OpenShift の設定
</h2>

W\&B は、エアギャップ環境の OpenShift Kubernetes クラスターへのデプロイをサポートしています。OpenShift ではセキュリティポリシーがより厳格なため、デプロイ時には追加のセキュリティコンテキスト設定が必要です。OpenShift にデプロイする場合は、前述の手順に加えて、このセクションの設定も適用してください。

<h3 id="openshift-security-context-constraints">
  OpenShift のセキュリティコンテキスト制約
</h3>

OpenShift では、Security Context Constraints (SCC) を使用して Pod の権限を制御します。デフォルトでは、OpenShift は Pod に `restricted` SCC を割り当てます。この SCC では root としての実行が禁止され、特定のユーザー ID の使用が求められます。

<h4 id="option-1-use-restricted-scc-recommended">
  オプション 1: restricted SCC を使用する (推奨)
</h4>

Custom Resource で適切なセキュリティコンテキストを設定し、W\&B のコンポーネントを restricted SCC で実行するように構成します。

```yaml theme={"system"}
spec:
  values:
    # すべての Pod のセキュリティコンテキストを設定します
    app:
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    console:
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    # 他のコンポーネント（api、executor、glue、parquet、weave）にも同様に設定します
```

<h4 id="option-2-create-custom-scc-if-required">
  オプション 2: カスタム SCC を作成する (必要な場合)
</h4>

`restricted` SCC では利用できない機能がデプロイメントに必要な場合は、カスタム SCC を作成します。

```yaml theme={"system"}
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: wandb-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities: []
defaultAddCapabilities: []
fsGroup:
  type: MustRunAs
  ranges:
    - min: 1000
      max: 65535
readOnlyRootFilesystem: false
requiredDropCapabilities:
  - ALL
runAsUser:
  type: MustRunAsRange
  uidRangeMin: 1000
  uidRangeMax: 65535
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret
```

1. SCC を適用します。

   ```bash theme={"system"}
   oc apply -f wandb-scc.yaml
   ```

2. SCC を W\&B のサービスアカウントにバインドします。

   ```bash theme={"system"}
   oc adm policy add-scc-to-user wandb-scc -z wandb-app -n wandb
   oc adm policy add-scc-to-user wandb-scc -z wandb-console -n wandb
   ```

<h3 id="openshift-routes">
  OpenShift ルート
</h3>

OpenShift では、標準の Kubernetes Ingress ではなく Routes を使用します。OpenShift Routes を使用するように W\&B を設定します。

```yaml theme={"system"}
spec:
  values:
    ingress:
      enabled: false
    
    route:
      enabled: true
      host: wandb.apps.openshift.yourdomain.com
      tls:
        enabled: true
        termination: edge
        insecureEdgeTerminationPolicy: Redirect
```

<h3 id="openshift-image-pull-configuration">
  OpenShift のイメージプル設定
</h3>

OpenShift クラスターで認証が必要な内部イメージレジストリを使用している場合は、次の手順を実行します。

1. image pull secret を作成します。

   ```bash theme={"system"}
   kubectl create secret docker-registry wandb-registry-secret \
     --docker-server=registry.yourdomain.com \
     --docker-username=[USERNAME] \
     --docker-password=[PASSWORD] \
     --namespace=wandb
   ```

2. Custom Resource でこのシークレットを参照します。

   ```yaml theme={"system"}
   spec:
     values:
       imagePullSecrets:
         - name: wandb-registry-secret
   ```

<h3 id="openshift-complete-example">
  OpenShift の完全な設定例
</h3>

次の例は、OpenShift のエアギャップデプロイメント向けの完全な CR です。

<Note>
  この例に含まれるすべての `tag:` の値は、ステップ 1 で内部レジストリに転送した実際のバージョンに置き換えてください。ここに記載されているバージョンはあくまで例であり、時間の経過とともに古くなります。
</Note>

```yaml theme={"system"}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  name: wandb
  namespace: wandb

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

  values:
    global:
      host: https://wandb.apps.openshift.yourdomain.com
      license: [YOUR-LICENSE]
      
      bucket:
        accessKey: [YOUR-ACCESS-KEY]
        secretKey: [YOUR-SECRET-KEY]
        name: s3.yourdomain.com:9000
        path: wandb
        provider: s3
        region: us-east-1
      
      mysql:
        database: wandb
        host: mysql.yourdomain.com
        password: [YOUR-MYSQL-PASSWORD]
        port: 3306
        user: wandb
      
      redis:
        host: redis.yourdomain.com
        port: 6379
        password: [YOUR-REDIS-PASSWORD]

    # OpenShift 固有の設定: Ingress の代わりに Route を使用します
    ingress:
      enabled: false
    
    route:
      enabled: true
      host: wandb.apps.openshift.yourdomain.com
      tls:
        enabled: true
        termination: edge

    # 内部レジストリ用のイメージプルシークレット
    imagePullSecrets:
      - name: wandb-registry-secret

    # OpenShift の restricted SCC に対応するセキュリティコンテキスト
    app:
      image:
        repository: registry.yourdomain.com/wandb/local
        tag: 0.59.2
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    console:
      image:
        repository: registry.yourdomain.com/wandb/console
        tag: 2.12.2
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    # api、executor、glue、parquet、weave にも同じセキュリティコンテキストを設定します
    # (見やすくするため省略しています)
```

<Note>
  セキュリティ要件に応じた OpenShift の包括的な設定例については、[W\&B Support](mailto:forge-support@coreweave.com)または担当の W\&B サポートエンジニアにお問い合わせください。
</Note>

<h2 id="verify-your-installation">
  インストールを確認する
</h2>

W\&B をデプロイしたら、インストールが正しく動作していることを確認します。これにより、プラットフォームにアクセスできること、Pod が正常に稼働していること、デプロイメントが社内のリソースのみを使用していることを確かめられます。

まず一般的な検証ステップを実行し、次に以下のセクションにあるエアギャップ環境向けの追加チェックを完了してください。

インストールを確認するため、W\&B は [W\&B CLI](/ja/products/wandb/ref/cli) の使用を推奨します。`wandb verify` コマンドは、コンポーネントと設定が期待どおりに動作することを確認するテストを実行します。

<Note>
  この手順では、ブラウザーで最初の管理者ユーザーアカウントを作成することを前提としています。
</Note>

インストールを確認する：

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

   ```bash theme={"system"}
   pip install wandb
   ```

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

   ```bash theme={"system"}
   wandb login --host=https://YOUR_DNS_DOMAIN
   ```

   例：

   ```bash theme={"system"}
   wandb login --host=https://wandb.company-name.com
   ```

3. インストールを確認します：

   ```bash theme={"system"}
   wandb verify
   ```

コマンドの実行後、インストールが成功すると、次の出力が表示されます：

```console theme={"system"}
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 サポートチームにお問い合わせください。

<h3 id="additional-air-gapped-verification">
  エアギャップ環境での追加の検証
</h3>

エアギャップ環境のデプロイメントでは、以下の項目も確認してください。

1. **イメージプル**: すべての Pod が内部レジストリからイメージを正常にプルできたことを確認します。

   ```bash theme={"system"}
   kubectl get pods -n wandb -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[*].image}{"\n"}{end}'
   ```

   すべてのイメージが内部レジストリを参照し、すべての Pod が `Running` 状態になっていれば問題ありません。

2. **外部との接続性**: W\&B が外部への接続を試みていないことを確認します (エアギャップモードでは外部接続は発生しないはずです)。

   ```bash theme={"system"}
   kubectl logs -n wandb deployment/wandb-app --tail=100 | grep -i "connection"
   ```

3. **ライセンスの検証**: W\&B Console にアクセスし、ライセンスが有効であることを確認します。

<h2 id="troubleshooting">
  トラブルシューティング
</h2>

<h3 id="image-pull-errors">
  イメージプルのエラー
</h3>

Pod がイメージをプルできない場合は、次の点を確認してください。

* 内部レジストリにイメージが存在することを確認します。
* image pull secret が正しく設定されていることを確認します。
* Kubernetes ノードからレジストリへのネットワーク接続を確認します。
* レジストリの認証情報を確認します。

イメージプルを手動でテストするには、次のようにします。

```bash theme={"system"}
kubectl run test-pull --image=registry.yourdomain.com/wandb/local:0.59.2 --namespace=wandb
kubectl logs test-pull -n wandb
kubectl delete pod test-pull -n wandb
```

<h3 id="openshift-scc-errors">
  OpenShift SCC エラー
</h3>

OpenShift で Pod が権限エラーで失敗する場合は、次の手順を実行します。

```bash theme={"system"}
# 使用中の SCC を確認します
oc get pod [POD-NAME] -n wandb -o yaml | grep scc

# サービスアカウントの権限を確認します
oc describe scc wandb-scc
oc get rolebinding -n wandb
```

<h3 id="helm-chart-not-found">
  Helm チャートが見つからない
</h3>

オペレーターがプラットフォームのチャートを見つけられない場合は、次の点を確認してください。

* Custom Resource に指定したチャートリポジトリの URL が正しいことを確認します。
* オペレーターの Pod から社内の Helm リポジトリにアクセスできることを確認します。
* チャートがリポジトリに存在することを確認します。

  ```bash theme={"system"}
  helm search repo local-repo/operator-wandb
  ```

<h2 id="frequently-asked-questions">
  よくある質問
</h2>

<h3 id="can-i-use-a-different-ingress-class">
  別のイングレスクラスを使用できますか？
</h3>

はい。Custom Resource のイングレス設定を変更することで、イングレスクラスを設定できます：

```yaml theme={"system"}
spec:
  values:
    ingress:
      class: your-ingress-class
```

<h3 id="how-do-i-handle-certificate-bundles-with-multiple-certificates">
  複数の証明書を含む証明書バンドルを扱うにはどうすればよいですか？
</h3>

証明書を分割し、`customCACerts` セクション内の複数のエントリとして記述します：

```yaml theme={"system"}
spec:
  values:
    customCACerts:
      cert1.crt: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
      cert2.crt: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
```

<h3 id="how-do-i-prevent-automatic-updates">
  自動更新を防ぐにはどうすればよいですか？
</h3>

W\&B が自動的に更新されないようにオペレーターを設定するには、次の手順を実行します。

* オペレーターのインストール時に `airgapped: true` を設定します (これにより、自動更新チェックが無効になります) 。
* Custom Resource の `spec.chart.version` を手動で更新し、バージョンの更新を管理します。
* 必要に応じて、W\&B System Console から自動更新を無効にします。

詳細については、[アプリバージョンの自動更新を無効にする](/ja/products/wandb/platform/hosting/self-managed/disable-automatic-app-version-updates)を参照してください。

<Note>
  W\&B は、セルフマネージドインスタンスをご利用のお客様に対し、サポートを継続して受けられるよう、また最新の機能、パフォーマンス改善、修正を適用できるよう、少なくとも四半期に 1 回はデプロイメントを最新リリースに更新することを強く推奨しています。W\&B は、各メジャーリリースを初回リリース日から 12 か月間サポートします。詳しくは、[リリースポリシーとプロセス](/ja/release-notes/release-policies)を参照してください。
</Note>

<h3 id="does-the-deployment-work-with-no-connection-to-public-repositories">
  パブリックリポジトリに接続できない環境でもデプロイメントは動作しますか？
</h3>

はい。オペレーターの設定で `airgapped: true` を指定すると、Kubernetes Operator は社内のリソースのみを使用し、パブリックリポジトリへの接続を試みません。

<h3 id="how-do-i-update-wb-in-an-air-gapped-environment">
  エアギャップ環境で W\&B を更新するにはどうすればよいですか？
</h3>

W\&B を更新するには、次の手順を実行します。

1. インターネットに接続されたシステムで、新しいコンテナーイメージをプルします。
2. イメージをエアギャップ環境のレジストリに転送します。
3. 新しい Helm チャートを内部リポジトリにアップロードします。
4. Custom Resource の `spec.chart.version` とイメージタグを更新します。
5. 更新した Custom Resource を適用します。

   オペレーターによって、W\&B の各コンポーネントがローリングアップデートされます。

<h2 id="next-steps">
  次のステップ
</h2>

デプロイメントが完了したら、次のタスクを実施してください。

* **ユーザー認証を設定する**: [SSO](/ja/products/wandb/platform/hosting/iam/sso) またはその他の認証方式を設定します。
* **モニタリングを設定する**: W\&B インスタンスとインフラストラクチャーのモニタリングを設定します。
* **アップデートを計画する**: [Server のアップグレードプロセス](/ja/products/wandb/platform/hosting/server-upgrade-process)を確認し、アップデートの実施頻度を決めます。
* **バックアップを設定する**: MySQL データベースのバックアップ手順を整備します。
* **プロセスを文書化する**: エアギャップ環境に固有のアップデート手順をまとめた Runbook を作成します。

<h2 id="get-help">
  ヘルプ
</h2>

デプロイ中に問題が発生した場合は、以下を参照してください。

* インフラストラクチャーに関するガイダンスについては、[リファレンスアーキテクチャ](/ja/products/wandb/platform/hosting/self-managed/ref-arch)を確認してください。
* 設定の詳細については、[オペレーターガイド](/ja/products/wandb/platform/hosting/self-managed/operator)を確認してください。
* [W\&B Support](mailto:forge-support@coreweave.com) または担当の W\&B サポートエンジニアにお問い合わせください。
* OpenShift 固有の問題については、Red Hat OpenShift のドキュメントを参照してください。


## Related topics

- [W&B Self-Managed デプロイメントの概要](/ja/products/wandb/platform/hosting/hosting-options/self-managed.md)
