> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wandb.ai/llms.txt
> Use this file to discover all available pages before exploring further.
> エアギャップ および切り離されたネットワークの Kubernetes 環境に W&B Platform をデプロイする
# エアギャップ Kubernetes へのデプロイ
## はじめに
このガイドでは、エアギャップ環境、切り離された環境、または制限付きネットワークの顧客管理環境に W\&B Platform をデプロイするためのステップごとの手順を説明します。このガイドに従うことで、W\&B イメージとチャートをホストするための内部コンテナーレジストリと Helm リポジトリを設定し、W\&B Kubernetes Operator をインストールして、外部へのインターネット接続なしで W\&B Platform をデプロイできます。このガイドは、規制対象または分離されたネットワークで Kubernetes インフラストラクチャーを管理するプラットフォーム管理者および DevOps エンジニアを対象としています。
エアギャップデプロイは、次のような環境で一般的です。
* セキュアな政府施設
* 厳格なネットワーク分離が求められる金融機関
* コンプライアンス要件のある医療機関
* 産業用制御システム (ICS) 環境
* 機密ネットワークを持つ研究施設
これらのコマンドは、Kubernetes クラスターに適切にアクセスできるシェルコンソールで実行してください。これらのコマンドは、Kubernetes アプリケーションのデプロイに使用している任意の CI/CD ツールで動作するように調整できます。
インターネット接続のある標準的なオンプレミス Kubernetes デプロイについては、[Deploy W\&B with Kubernetes Operator](/ja/platform/hosting/self-managed/operator) を参照してください。
## 前提条件
始める前に、エアギャップ環境が以下の要件を満たしていることを確認してください。
### バージョン要件
| ソフトウェア | 最小バージョン |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Kubernetes | v1.34 以降 ([サポートされる Kubernetes バージョン](https://kubernetes.io/releases/patch-releases/)) |
| Helm | v3.x |
| MySQL | W\&B Self-Managed のデプロイでは、セキュリティパッチと重大なバグ修正が提供される、サポート対象の MySQL バージョンを実行する必要があります。**MySQL 8.4.x** をインストールまたはアップグレードするか、プロバイダのドキュメントでサポート対象かつパッチ適用済みとされているマネージドサービスのバージョンを使用してください。
Aurora MySQL のバージョン文字列は、コミュニティ版 MySQL のバージョンとは異なります。完全な推論エンジンのバージョン文字列を確認するには `SELECT version()` を、Aurora のバージョンを確認するには `SELECT aurora_version()` を使用してください。[Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) は MySQL 8.0.x と互換性があり、引き続きサポートされています。対象のバージョンを選択する際は、[Amazon Aurora versioning](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.Versioning.html) とご利用の cloud provider のドキュメントを参照してください。 |
| Redis | v7.x |
| ClickHouse | セルフマネージドのデプロイで Weave および一部の Models の OLAP 機能を使用するには必須です。最小バージョンは、有効になっている機能と W\&B Server のバージョンによって異なります。[アップグレード時の ClickHouse 互換性](/ja/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) と [サポートされる W\&B Server リリース](/ja/release-notes/server-releases) を参照してください。 |
### SSL/TLS 要件
W\&B では、クライアントとサーバー間の安全な通信のために、有効な署名付き SSL/TLS 証明書が必要です。SSL/TLS の終端は ingress または load balancer で行う必要があります。W\&B Server アプリケーション自体は、SSL または TLS 接続を終端しません。
W\&B は自己署名証明書またはカスタム CA をサポートしていません。自己署名証明書を使用するとユーザーに問題が生じるため、サポート対象外です。
可能であれば、[Let's Encrypt](https://letsencrypt.org) のようなサービスを使用して、load balancer に信頼できる証明書を提供するのが効果的です。Caddy や Cloudflare のようなサービスを使えば、SSL を代わりに管理できます。
セキュリティポリシーで、信頼できるネットワーク内でも SSL 通信が必要な場合は、Istio のようなツールや [side car containers](https://istio.io/latest/docs/reference/config/networking/sidecar/) の使用を検討してください。
### ハードウェア要件
**CPU アーキテクチャ**: W\&B は Intel (x86) CPU アーキテクチャでのみ動作します。ARM はサポートされていません。
**サイジング**: Kubernetes ノードと MySQL の CPU、メモリ、ディスクのサイジング推奨事項については、リファレンスアーキテクチャの [サイジング セクション](/ja/platform/hosting/self-managed/ref-arch/#sizing) を参照してください。要件は、Models、Weave、またはその両方を実行するかどうかによって異なります。
### MySQL データベース
W\&B では、外部の MySQL データベースが必要です。
本番環境では、W\&B はマネージドデータベースサービスの利用を推奨しています。
* [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/platform/hosting/self-managed/ref-arch/#mysql)を参照してください。データベースを作成するための SQL については、[ベアメタルガイド](/ja/platform/hosting/self-managed/operator/#mysql-database)を参照してください。デプロイ環境のデータベース設定に関するご質問は、[サポート](mailto:support@wandb.com)または担当の AISE までお問い合わせください。
セルフマネージドインスタンス向けの MySQL の設定パラメーターについては、[リファレンスアーキテクチャの MySQL 設定セクション](/ja/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters)を参照してください。
### Redis
W\&B は単一ノードの Redis 7.x デプロイに依存しており、W\&B の components はこれをジョブキューイングとデータのキャッシュに使用します。テストや概念実証の用途では、W\&B Self-Managed にローカル Redis デプロイが含まれています。このバンドル版のデプロイは、本番環境での使用には適していません。
本番デプロイでは、W\&B は次の環境にある Redis instance に接続できます。
* [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
### オブジェクトストレージ
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](https://docs.coreweave.com/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互換ストレージ。
MinIO Open Source は現在[メンテナンスモード](https://github.com/minio/minio)であり、アクティブな開発は行われておらず、事前コンパイル済みバイナリも提供されていません。本番環境へのデプロイでは、W\&B は、マネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ S3互換ソリューションを推奨しています。
プロバイダを選択したら、W\&B がアクセスできるようにバケットを設定してください。IAM ポリシー、CORS 設定、アクセス設定を含むバケットの詳細なプロビジョニング手順については、[Bring Your Own Bucket (BYOB) ガイド](/ja/platform/hosting/data-security/secure-storage-connector)を参照してください。
容量やパフォーマンスに関するガイダンスを含む、オブジェクトストレージ要件の完全な一覧については、[リファレンスアーキテクチャのオブジェクトストレージ セクション](/ja/platform/hosting/self-managed/ref-arch/#object-storage)を参照してください。
オブジェクトストレージのプロビジョニングに関する詳細は、[Bring Your Own Bucket (BYOB)](/ja/platform/hosting/data-security/secure-storage-connector) ガイドを参照してください。エアギャップ 環境では、通常、MinIO Enterprise、NetApp StorageGRID、Dell ECS などのオンプレミスの S3 互換ストレージを使用します。
### エアギャップ環境固有の要件
前述の標準的な要件に加えて、エアギャップ環境でのデプロイには次のものが必要です。
* **内部コンテナーRegistry**: 必要なすべての W\&B コンテナーイメージを含むプライベートなコンテナーRegistry (Harbor、JFrog Artifactory、Nexus など) へのアクセス
* **内部 Helm リポジトリ**: W\&B Helm チャートを含むプライベートな Helm チャートリポジトリへのアクセス
* **イメージ転送機能**: インターネットに接続されたシステムからエアギャップ環境のRegistryにコンテナーイメージを転送するための手段
* **ライセンスファイル**: 有効な W\&B Enterprise ライセンス。ライセンスを取得するには (たとえば、インターネットに接続されたマシンから取得する場合) 、要件ページの [License](/ja/platform/hosting/self-managed/requirements#license) セクションを参照するか、W\&B の担当アカウントチームにお問い合わせください。
ネットワークやロードバランサーの設定を含む、完全なインフラストラクチャー要件については、[リファレンスアーキテクチャ](/ja/platform/hosting/self-managed/ref-arch#infrastructure-requirements) を参照してください。
## エアギャップ 環境を準備する
以下の手順では、W\&B のコンテナーイメージと Helm チャート をホストするための エアギャップ 環境を準備します。operator をインストールしたり、プラットフォームをデプロイしたりする前に、これらの手順を完了してください。
### Step 1: 内部コンテナーRegistryを設定する
Kubernetes クラスターはパブリックRegistryからイメージをプルできないため、デプロイ前に、必要なすべてのコンテナーイメージを内部のエアギャップ環境用コンテナーRegistryで利用できるようにしておく必要があります。
W\&B Operator の要件を把握し、コンテナーRegistry内のイメージを定期的に更新して維持する責任は、お客様にあります。必要なコンテナーイメージとそのバージョンの最新一覧については、Helm チャートを参照するか、[W\&B サポート](mailto:support@wandb.com) または担当の W\&B サポートエンジニアにお問い合わせください。
#### 主要なW\&Bコンポーネントのコンテナー
以下の主要なイメージは必須です。
* [`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)。
#### 依存コンテナー
次のサードパーティ製依存イメージが必要です。
* [`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 の依存イメージ。
#### 完全なイメージ一覧を取得する
必要なイメージとバージョンの完全な一覧を Helm チャートから抽出するには、次の手順を実行します。
1. インターネットに接続されたシステムで、[W\&B Helm charts リポジトリ](https://github.com/wandb/helm-charts) から W\&B Helm チャートをダウンロードします。
```bash theme={null}
# helm-charts リポジトリをクローンする
git clone https://github.com/wandb/helm-charts.git
cd helm-charts
```
2. `values.yaml` ファイルを確認し、すべてのコンテナーイメージとそのバージョンを特定します。
```bash theme={null}
# operator チャートからイメージ参照を抽出する
helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#"
# platform チャートからイメージ参照を抽出する
helm show values charts/operator-wandb | grep -E "repository:|tag:" | grep -v "^#"
```
または、次のコマンドを使用してリポジトリ名のみを抽出できます (バージョンタグは除く) 。
```bash theme={null}
helm show values charts/operator-wandb \
| awk -F': *' '/^[[:space:]]*repository:/{print $2}' \
| grep -v "^#" \
| sort -u
```
リポジトリの一覧は、次のようになります。
```text theme={null}
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:"`) を使用します。このコマンドでは、リポジトリ名と対応するバージョンタグの両方が表示されます。
#### イメージをエアギャップ環境の Registry に転送する
1. インターネットに接続されたシステムで、必要なイメージをすべて pull して保存します。
以下の例にあるバージョン番号は、前の手順で Helm チャート を確認して特定した実際のバージョンに置き換えてください。ここに示しているバージョンはあくまで例であり、時間の経過とともに古くなります。
シェル変数を使用して、バージョンを一貫して管理します。
```bash theme={null}
# バージョン変数を設定します（Helm chart のバージョンに合わせて更新してください）
CONTROLLER_VERSION="1.13.3"
APP_VERSION="0.59.2"
CONSOLE_VERSION="2.12.2"
# イメージを pull します
docker pull wandb/controller:${CONTROLLER_VERSION}
docker pull wandb/local:${APP_VERSION}
docker pull wandb/console:${CONSOLE_VERSION}
docker pull wandb/megabinary:${APP_VERSION}
# ...必要な他のすべてのイメージも、それぞれのバージョンで pull します
# イメージを .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. `.tar` ファイルを、USB ドライブや安全なファイル転送など、承認済みの方法でエアギャップ環境に転送します。
3. エアギャップ環境で、イメージをロードし、内部 Registry に push します。
```bash theme={null}
# 上で使用したものと同じバージョン変数を設定します
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
# ...他のすべてのイメージもロードします
# 内部 Registry 向けにタグ付けします
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}
# ...他のすべてのイメージにもタグ付けします
# 内部 Registry に push します
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}
# ...他のすべてのイメージも push します
```
### Step 2: 内部 Helm チャートリポジトリを設定する
コンテナーイメージを配置したら、Kubernetes Operator が W\&B Helm チャートにアクセスできるようにする必要もあります。次の Helm チャートを内部 Helm リポジトリで利用できるようにしてください。
* [W\&B Operator chart](https://github.com/wandb/helm-charts/tree/main/charts/operator)
* [W\&B Platform chart](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)
1. インターネットに接続されたシステムで、チャートをダウンロードします。
```bash theme={null}
# 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 (Controller Manager) をデプロイします。`operator-wandb` チャートは、Custom Resource (CR) で設定した値を使用して W\&B Platform をデプロイします。
### Step 3: Helm リポジトリへのアクセスを設定する
後続のインストール コマンドでチャートを参照できるように、エアギャップ環境内のローカル Helm クライアントが内部リポジトリを参照するように設定します。
1. エアギャップ環境で、Helm が内部リポジトリを使用するように設定します。
```bash theme={null}
helm repo add local-repo https://charts.yourdomain.com
helm repo update
```
2. チャートが利用可能であることを確認します。
```bash theme={null}
helm search repo local-repo/operator
helm search repo local-repo/operator-wandb
```
## エアギャップ環境に W\&B をデプロイする
内部Registryと Helm リポジトリを用意したら、Kubernetes Operator をインストールし、外部サービスを設定して、W\&B Platform をデプロイできます。
### Step 4: Kubernetes Operator をインストールする
W\&B Kubernetes Operator (コントローラーマネージャー) は、W\&B プラットフォームの各コンポーネントを管理します。これをエアギャップ環境にインストールするには、内部コンテナーRegistryを使用するように設定します。
1. 次の内容で `values.yaml` ファイルを作成します。
```yaml theme={null}
image:
repository: registry.yourdomain.com/wandb/controller
tag: 1.13.3
airgapped: true
```
repository と tag は、Step 1 で内部Registryに転送した実際のバージョンに置き換えてください。ここに示したバージョン (`1.13.3`) はあくまで例であり、時間の経過とともに古くなります。
2. operator と Custom Resource Definition (CRD) をインストールします。
```bash theme={null}
helm upgrade --install operator local-repo/operator \
--namespace wandb \
--create-namespace \
--values values.yaml
```
3. operator が実行中であることを確認します。
```bash theme={null}
kubectl get pods -n wandb
```
`Running` 状態の operator pod が表示されるはずです。
これで W\&B Kubernetes Operator のインストールが完了し、内部 チャート リポジトリから W\&B プラットフォームをデプロイする準備が整いました。
サポートされる values の詳細については、[Kubernetes operator GitHub repository の values ファイル](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml)を参照してください。
### Step 5: MySQL データベースを設定する
W\&B Custom Resource を設定する前に、外部の MySQL データベースを設定してください。本番デプロイでは、利用可能であればマネージドデータベースサービスを使用することを W\&B は強く推奨しています。ただし、独自の MySQL インスタンスを運用している場合は、データベースとユーザーを作成してください。
次の SQL コマンドを使用して、データベースとユーザーを作成します。`[PASSWORD]` は、強力なパスワードに置き換えてください。
```sql theme={null}
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/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters)を参照してください。
### ステップ 6: W\&B Custom Resource を設定する
W\&B Kubernetes Operator をインストールしたら、Custom Resource (CR) を設定して、内部の Helm リポジトリ とコンテナー registry を参照するようにします。この設定により、W\&B Platform の必須コンポーネントをデプロイする際、Kubernetes operator はパブリックなソースへのアクセスを試みるのではなく、内部の registry と リポジトリ を使用します。
次の設定例には、時間の経過とともに古くなるイメージのバージョン tags が含まれています。すべての `tag:` の値を、ステップ 1 で内部 registry に転送した実際のバージョンに置き換えてください。
次の内容で、`wandb.yaml` という名前の file を作成します。
```yaml theme={null}
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
```
ホスト名、パスワード、タグなどのプレースホルダー値は、すべて実際の設定値に置き換えてください。前述の例では、最も一般的に使用されるコンポーネントを示しています。
デプロイ要件によっては、次のような追加コンポーネントのイメージリポジトリも設定する必要があります。
* `settingsMigrationJob`
* `weave-trace`
* `filestream`
* `flat-runs-table`
設定可能なコンポーネントの一覧全体については、[W\&B Helm リポジトリ の values ファイル](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml)を参照してください。
### ステップ 7: W\&B Platform をデプロイする
Custom Resource を適用すると、operator が `wandb.yaml` の設定とイメージ参照を使用して、`operator-wandb` チャートで定義されている W\&B Platform のコンポーネントをインストールします。
1. プラットフォームをデプロイするには、W\&B Custom Resource を適用します。
```bash theme={null}
kubectl apply -f wandb.yaml
```
2. デプロイの進行状況を監視します。
```bash theme={null}
# 作成中の pod を監視
kubectl get pods -n wandb --watch
# デプロイのステータスを確認
kubectl get weightsandbiases -n wandb
# operator のログを表示
kubectl logs -n wandb deployment/wandb-operator-controller-manager
```
operator が必要なコンポーネントをすべて作成するため、デプロイの完了までに数分かかる場合があります。
## OpenShift の設定
W\&B は、エアギャップ環境の OpenShift Kubernetes クラスターへのデプロイをサポートしています。OpenShift へのデプロイでは、OpenShift のより厳格なセキュリティポリシーに対応するため、追加のセキュリティコンテキスト設定が必要です。OpenShift にデプロイする場合は、前のステップに加えて、このセクションの設定も適用してください。
### OpenShift のセキュリティコンテキスト制約
OpenShift では、pod の権限を制御するために Security Context Constraints (SCC) を使用します。デフォルトでは、pod には `restricted` SCC が割り当てられ、root としての実行が禁止されるほか、特定のユーザー ID が必要になります。
#### オプション1: `restricted` SCCを使用する (推奨)
Custom Resource で適切なセキュリティコンテキストを設定し、W\&B コンポーネントが `restricted` SCC で実行されるように構成します。
```yaml theme={null}
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
```
#### オプション 2: カスタム SCC を作成する (必要な場合)
デプロイに `restricted` SCC では利用できないケーパビリティが必要な場合は、カスタム SCC を作成します。
```yaml theme={null}
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={null}
oc apply -f wandb-scc.yaml
```
2. SCC を W\&B のサービスアカウントに関連付けます。
```bash theme={null}
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
```
### OpenShift Routes
OpenShift では、標準の Kubernetes Ingress ではなく Routes を使用します。W\&B で OpenShift Routes を使用するように設定します。
```yaml theme={null}
spec:
values:
ingress:
enabled: false
route:
enabled: true
host: wandb.apps.openshift.yourdomain.com
tls:
enabled: true
termination: edge
insecureEdgeTerminationPolicy: Redirect
```
### OpenShift のイメージプル設定
OpenShift クラスターで認証が必要な内部イメージRegistryを使用している場合:
1. イメージプルシークレットを作成します。
```bash theme={null}
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={null}
spec:
values:
imagePullSecrets:
- name: wandb-registry-secret
```
### OpenShift の完全な例
以下の例は、OpenShift の エアギャップ deployment 向けの完全な CR を示しています。
この例内のすべての `tag:` の値を、ステップ 1 で内部 Registry に転送した実際のバージョンに置き換えてください。ここに示しているバージョンはあくまで例であり、時間の経過とともに古くなります。
```yaml theme={null}
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ではなくRoutesを使用する
ingress:
enabled: false
route:
enabled: true
host: wandb.apps.openshift.yourdomain.com
tls:
enabled: true
termination: edge
# 内部レジストリ用のイメージプルシークレット
imagePullSecrets:
- name: wandb-registry-secret
# OpenShift制限付き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にも同様のセキュリティコンテキストを設定する
# （簡略化のため省略）
```
セキュリティ要件に応じた包括的な OpenShift 設定例については、[W\&B Support](mailto:support@wandb.com) または担当の W\&B サポートエンジニアにお問い合わせください。
## インストールを確認する
W\&B をデプロイしたら、プラットフォームにアクセス可能であり、pod が正常で、デプロイメントが内部リソースのみを使用していることを確認できるように、インストールが正常に機能していることを確認してください。
一般的な確認手順に従ってから、次のセクションで追加の エアギャップ チェックを実施してください。
インストールを確認するには、W\&B では [W\&B CLI](/ja/models/ref/cli/) の使用を推奨しています。`wandb verify` コマンドは、コンポーネントと設定が想定どおりに動作することを確認するテストを実行します。
この手順では、最初の管理者ユーザーアカウントをブラウザで作成することを前提としています。
インストールを確認するには:
1. W\&B CLI をインストールします:
```bash theme={null}
pip install wandb
```
2. W\&B にログインします:
```bash theme={null}
wandb login --host=https://YOUR_DNS_DOMAIN
```
例えば:
```bash theme={null}
wandb login --host=https://wandb.company-name.com
```
3. インストールを確認する:
```bash theme={null}
wandb verify
```
コマンドの実行後、インストールが成功すると、次の出力が表示されます:
```console theme={null}
Default host selected: https://wandb.company-name.com
Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
Checking if logged in...................................................✅
Checking signed URL upload..............................................✅
Checking ability to send large payloads through proxy...................✅
Checking requests to base url...........................................✅
Checking requests made over signed URLs.................................✅
Checking CORs configuration of the bucket...............................✅
Checking wandb package version is up to date............................✅
Checking logged metrics, saving and downloading a file..................✅
Checking artifact save and download workflows...........................✅
```
エラーが発生した場合は、W\&Bサポートまでお問い合わせください。
### エアギャップ 環境での追加検証
エアギャップ デプロイでは、次の点も確認してください。
1. **イメージプル**: すべての Pod が内部レジストリからイメージを正常にプルできていることを確認します。
```bash theme={null}
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={null}
kubectl logs -n wandb deployment/wandb-app --tail=100 | grep -i "connection"
```
3. **ライセンス検証**: W\&B コンソールにアクセスし、ライセンスが有効になっていることを確認します。
## トラブルシューティング
### イメージプルエラー
Pod がイメージをプルできない場合は、次の点を確認してください。
* イメージが内部Registryに存在することを確認してください。
* イメージプルシークレットが正しく設定されていることを確認してください。
* Kubernetes ノードからRegistryへのネットワーク接続を確認してください。
* Registryの認証情報を確認してください。
イメージプルを手動でテストするには、次のようにします。
```bash theme={null}
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
```
### OpenShift の SCC エラー
OpenShift で Pod が権限エラーで失敗する場合:
```bash theme={null}
# 使用されている SCC を確認する
oc get pod [POD-NAME] -n wandb -o yaml | grep scc
# サービスアカウントの権限を確認する
oc describe scc wandb-scc
oc get rolebinding -n wandb
```
### Helm チャートが見つからない
operator が platform チャートを見つけられない場合は、次を確認してください:
* Custom Resource 内のチャートリポジトリ URL を確認します。
* operator の pod から内部 Helm リポジトリにアクセスできることを確認します。
* リポジトリ内にチャートが存在することを確認します:
```bash theme={null}
helm search repo local-repo/operator-wandb
```
## よくある質問
### 別の ingress class を使用できますか？
はい。Custom Resource の ingress 設定を変更して、使用する ingress class を設定できます。
```yaml theme={null}
spec:
values:
ingress:
class: your-ingress-class
```
### 複数の証明書を含む証明書バンドルはどうすればよいですか
証明書を `customCACerts` セクションで複数のエントリに分割します。
```yaml theme={null}
spec:
values:
customCACerts:
cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
### どうすれば自動更新を防止できますか
operator が W\&B を自動更新しないように設定するには、次の手順を実行します。
* operator のインストール時に `airgapped: true` を設定します (これにより自動更新のチェックが無効になります)。
* Custom Resource の `spec.chart.version` を手動で更新して、version の更新を管理します。
* 必要に応じて、W\&B System Console から自動更新を無効にします。
詳しくは、[自動アプリ version 更新を無効にする](/ja/platform/hosting/self-managed/disable-automatic-app-version-updates)を参照してください。
W\&B では、セルフマネージド環境のインスタンスをご利用のお客様に対し、サポートを維持し、最新の機能、パフォーマンス改善、修正を利用できるようにするため、少なくとも四半期に 1 回はデプロイを最新 version に更新することを強く推奨しています。W\&B は、各メジャーリリースを初回リリース日から 12 か月間サポートします。詳しくは、[リリースポリシーとプロセス](/ja/release-notes/release-policies)を参照してください。
### このデプロイはパブリックリポジトリに接続しなくても動作しますか？
はい。Operator の設定で `airgapped: true` を指定すると、Kubernetes Operator は内部リソースのみを使用し、パブリックリポジトリへの接続は試みません。
### エアギャップ環境で W\&B を更新するにはどうすればよいですか？
W\&B を更新するには、次の手順を実行します。
1. インターネットに接続されたシステムで新しいコンテナーイメージを取得します。
2. イメージをエアギャップ環境のRegistryに転送します。
3. 新しい Helm チャートを内部リポジトリにアップロードします。
4. Custom Resource の `spec.chart.version` とイメージタグを更新します。
5. 更新した Custom Resource を適用します。
operator は W\&B コンポーネントのローリングアップデートを実行します。
## 次のステップ
デプロイが正常に完了したら、次のタスクを完了します:
* **ユーザー認証を設定する**: [SSO](/ja/platform/hosting/iam/sso) またはその他の認証方式を設定します
* **監視を設定する**: W\&B インスタンスとインフラストラクチャーの監視を設定します
* **更新を計画する**: [Server upgrade process](/ja/platform/hosting/server-upgrade-process) を確認し、更新の実施頻度を定めます
* **バックアップを設定する**: MySQL データベースのバックアップ手順を確立します
* **プロセスを文書化する**: ご利用の エアギャップ 環境向けの更新手順の runbook を作成します
## サポートを受ける
デプロイ中に問題が発生した場合:
* インフラストラクチャーに関するガイダンスは、[リファレンスアーキテクチャ](/ja/platform/hosting/self-managed/ref-arch)を参照してください。
* 設定の詳細は、[Operator ガイド](/ja/platform/hosting/self-managed/operator)を確認してください。
* [W\&B サポート](mailto:support@wandb.com)または担当の W\&B サポートエンジニアに連絡してください。
* OpenShift 固有の問題については、Red Hat OpenShift のドキュメントを参照してください。