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

はじめに

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

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

これらのコマンドは、Kubernetes クラスターへの適切なアクセス権を持つシェルコンソールで実行してください。Kubernetes アプリケーションのデプロイに使用している CI/CD ツールに合わせて、これらのコマンドを調整することもできます。インターネットに接続された標準的なオンプレミスの Kubernetes デプロイメントについては、Kubernetes Operator を使用して W&B をデプロイするを参照してください。

前提条件

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

バージョン要件

ソフトウェア	最低バージョン
Kubernetes	v1.34 以降 (サポートされる Kubernetes バージョン)
Helm	v3.x
MySQL	W&B Self-Managed のデプロイメントでは、セキュリティパッチと重要なバグ修正が提供されている、サポート対象の MySQL バージョンを実行する必要があります。MySQL 8.4.x をインストールするか、同バージョンにアップグレードしてください。または、プロバイダーがサポート対象かつパッチ適用済みと明記しているマネージドサービスのバージョンを使用してください。 Aurora MySQL のバージョン文字列は、コミュニティ版 MySQL のバージョンとは異なります。データベースエンジンの完全なバージョン文字列を確認するには `SELECT version()` を、Aurora のバージョンを確認するには `SELECT aurora_version()` を使用してください。Aurora MySQL バージョン 3 は MySQL 8.0.x と互換性があり、引き続きサポートされています。移行先のバージョンを選択する際は、Amazon Aurora のバージョン管理およびご利用のクラウドプロバイダーのドキュメントを参照してください。
Redis	v7.x
ClickHouse	セルフマネージドのデプロイで Weave を使用する場合は必須です。Weave を使用しないデプロイメントでは不要です。アップグレード時の ClickHouse 互換性およびサポートされる W&B Server リリースを参照してください。

SSL/TLS の要件

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

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

可能であれば、Let’s Encrypt などのサービスを使用して、信頼された証明書をロードバランサーに提供してください。Caddy や Cloudflare などのサービスを利用すると、SSL の管理を任せることができます。セキュリティポリシー上、信頼されたネットワーク内でも SSL 通信が必要な場合は、Istio などのツールとサイドカーコンテナーの使用を検討してください。

ハードウェア要件

CPU アーキテクチャー: W&B は Intel (x86) の CPU アーキテクチャーでのみ動作します。ARM はサポートされていません。 Sizing: Kubernetes ノードおよび MySQL の CPU、メモリ、ディスクのサイジングに関する推奨事項については、リファレンスアーキテクチャの Sizing セクションを参照してください。要件は、Models と Weave のどちらを実行するか、または両方を実行するかによって異なります。

MySQL データベース

W&B には外部の MySQL データベースが必要です。本番環境では、マネージドデータベースサービスの使用を推奨します。

マネージドデータベースサービスは、自動バックアップ、モニタリング、高可用性、パッチ適用などの機能を備えており、運用上の負担を軽減できます。サイジングの推奨事項や設定パラメーターなど、MySQL の要件についてはリファレンスアーキテクチャを参照してください。データベースを作成するための SQL については、ベアメタルガイドを参照してください。デプロイメントのデータベース設定に関するご質問は、サポートまたは担当の AISE にお問い合わせください。セルフマネージドインスタンスの MySQL 設定パラメーターについては、リファレンスアーキテクチャの MySQL 設定セクションを参照してください。

Redis

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

Amazon ElastiCache
Google Cloud Memorystore
Azure Cache for Redis
クラウドまたはオンプレミスのインフラストラクチャー上でセルフホストしている Redis

オブジェクトストレージ

W&B には、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。 W&B では、次のストレージプロバイダーを推奨しています。

Amazon S3: スケーラビリティ、データの可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。
Google Cloud Storage: 非構造化データを大規模に保存するためのマネージドサービスです。
Azure Blob Storage: 非構造化データを大規模に保存するためのクラウドベースのオブジェクトストレージです。
CoreWeave AI Object Storage: AI ワークロード向けに最適化された S3互換のオブジェクトストレージです。
MinIO Enterprise (AIStor)、NetApp StorageGRID などのエンタープライズ向け S3互換ストレージ、またはその他のエンタープライズソリューション。

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

プロバイダーを選択したら、W&B がアクセスできるようにバケットを設定します。IAM ポリシー、CORS 設定、アクセスのセットアップなど、バケットのプロビジョニング手順の詳細については、Bring Your Own Bucket (BYOB) ガイドを参照してください。キャパシティやパフォーマンスに関するガイダンスなど、オブジェクトストレージ要件の一覧については、リファレンスアーキテクチャのオブジェクトストレージセクションを参照してください。オブジェクトストレージのプロビジョニングについて詳しくは、Bring Your Own Bucket (BYOB) ガイドを参照してください。エアギャップ環境では通常、MinIO Enterprise、NetApp StorageGRID、Dell ECS などのオンプレミスの S3互換ストレージを使用します。

エアギャップ環境固有の要件

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

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

ネットワークやロードバランサーの設定を含むインフラストラクチャー要件の詳細については、リファレンスアーキテクチャを参照してください。

エアギャップ環境を準備する

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

ステップ 1: 内部コンテナーレジストリを設定する

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

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

W&B コアコンポーネントのコンテナー

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

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

依存関係のコンテナー

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

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

イメージの完全なリストを取得する

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

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

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

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

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

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

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

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

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:") を使用してください。このコマンドを実行すると、リポジトリ名と対応するバージョンタグの両方が表示されます。

エアギャップ環境のレジストリにイメージを転送する

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

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

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

# バージョン変数を設定します（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
# ... その他のイメージもすべて保存します

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

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

# 上記と同じバージョン変数を設定します
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}
# ... その他のイメージもすべてプッシュします

ステップ 2: 内部 Helm チャートリポジトリを設定する

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

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

# 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

.tgz 形式のチャートファイルをエアギャップ環境に転送し、組織のリポジトリ運用手順に従って内部 Helm リポジトリにアップロードします。 operator チャートは W&B Kubernetes Operator (コントローラーマネージャー) をデプロイします。operator-wandb チャートは、Custom Resource (CR) に設定された値を使用して W&B プラットフォームをデプロイします。

ステップ 3: Helm リポジトリへのアクセスを設定する

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

エアギャップ環境で、内部リポジトリを使用するように Helm を設定します。
helm repo add local-repo https://charts.yourdomain.com helm repo update

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

helm search repo local-repo/operator
helm search repo local-repo/operator-wandb

エアギャップ環境に W&B をデプロイする

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

ステップ 4: Kubernetes Operator をインストールする

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

次の内容で values.yaml ファイルを作成します。
image: repository: registry.yourdomain.com/wandb/controller tag: 1.13.3 airgapped: true
リポジトリとタグは、ステップ 1 で内部レジストリに転送した実際のバージョンに置き換えてください。ここに示すバージョン (1.13.3) は一例であり、時間の経過とともに古くなります。

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

helm upgrade --install operator local-repo/operator \
  --namespace wandb \
  --create-namespace \
  --values values.yaml

オペレーターが実行されていることを確認します。
kubectl get pods -n wandb
オペレーターの Pod が Running 状態になっていれば問題ありません。

これで W&B Kubernetes Operator のインストールが完了し、内部チャートリポジトリから W&B プラットフォームをデプロイできるようになりました。サポートされる値の詳細については、Kubernetes Operator GitHub リポジトリの values ファイルを参照してください。

ステップ 5: MySQL データベースを設定する

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

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 設定セクションを参照してください。

ステップ 6: W&B Custom Resource を設定する

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

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

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

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

ステップ 7: W&B プラットフォームをデプロイする

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

W&B Custom Resource を適用して、プラットフォームをデプロイします。
kubectl apply -f wandb.yaml

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

# 作成される Pod を監視する
kubectl get pods -n wandb --watch

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

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

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

OpenShift の設定

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

OpenShift のセキュリティコンテキスト制約

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

オプション 1: restricted SCC を使用する (推奨)

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

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 を作成します。

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

SCC を適用します。
oc apply -f wandb-scc.yaml

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

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 ルート

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

spec:
  values:
    ingress:
      enabled: false
    
    route:
      enabled: true
      host: wandb.apps.openshift.yourdomain.com
      tls:
        enabled: true
        termination: edge
        insecureEdgeTerminationPolicy: Redirect

OpenShift のイメージプル設定

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

image pull secret を作成します。

kubectl create secret docker-registry wandb-registry-secret \
  --docker-server=registry.yourdomain.com \
  --docker-username=[USERNAME] \
  --docker-password=[PASSWORD] \
  --namespace=wandb

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

spec:
  values:
    imagePullSecrets:
      - name: wandb-registry-secret

OpenShift の完全な設定例

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

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

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 にも同じセキュリティコンテキストを設定します
    # (見やすくするため省略しています)

セキュリティ要件に応じた OpenShift の包括的な設定例については、W&B Supportまたは担当の W&B サポートエンジニアにお問い合わせください。

インストールを確認する

W&B をデプロイしたら、インストールが正しく動作していることを確認します。これにより、プラットフォームにアクセスできること、Pod が正常に稼働していること、デプロイメントが社内のリソースのみを使用していることを確かめられます。まず一般的な検証ステップを実行し、次に以下のセクションにあるエアギャップ環境向けの追加チェックを完了してください。インストールを確認するため、W&B は W&B CLI の使用を推奨します。wandb verify コマンドは、コンポーネントと設定が期待どおりに動作することを確認するテストを実行します。

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

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

W&B CLI をインストールします：
pip install wandb

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

wandb login --host=https://YOUR_DNS_DOMAIN

例：

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

インストールを確認します：
wandb verify

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

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 サポートチームにお問い合わせください。

エアギャップ環境での追加の検証

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

イメージプル: すべての Pod が内部レジストリからイメージを正常にプルできたことを確認します。
kubectl get pods -n wandb -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[*].image}{"\n"}{end}'
すべてのイメージが内部レジストリを参照し、すべての Pod が Running 状態になっていれば問題ありません。
外部との接続性: W&B が外部への接続を試みていないことを確認します (エアギャップモードでは外部接続は発生しないはずです)。
kubectl logs -n wandb deployment/wandb-app --tail=100 | grep -i "connection"
ライセンスの検証: W&B Console にアクセスし、ライセンスが有効であることを確認します。

トラブルシューティング

イメージプルのエラー

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

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

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

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 が権限エラーで失敗する場合は、次の手順を実行します。

# 使用中の SCC を確認します
oc get pod [POD-NAME] -n wandb -o yaml | grep scc

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

Helm チャートが見つからない

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

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

よくある質問

別のイングレスクラスを使用できますか？

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

spec:
  values:
    ingress:
      class: your-ingress-class

複数の証明書を含む証明書バンドルを扱うにはどうすればよいですか？

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

spec:
  values:
    customCACerts:
      cert1.crt: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
      cert2.crt: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----

自動更新を防ぐにはどうすればよいですか？

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

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

詳細については、アプリバージョンの自動更新を無効にするを参照してください。

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

パブリックリポジトリに接続できない環境でもデプロイメントは動作しますか？

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

エアギャップ環境で W&B を更新するにはどうすればよいですか？

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

インターネットに接続されたシステムで、新しいコンテナーイメージをプルします。
イメージをエアギャップ環境のレジストリに転送します。
新しい Helm チャートを内部リポジトリにアップロードします。
Custom Resource の spec.chart.version とイメージタグを更新します。
更新した Custom Resource を適用します。オペレーターによって、W&B の各コンポーネントがローリングアップデートされます。

次のステップ

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

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

ヘルプ

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

インフラストラクチャーに関するガイダンスについては、リファレンスアーキテクチャを確認してください。
設定の詳細については、オペレーターガイドを確認してください。
W&B Support または担当の W&B サポートエンジニアにお問い合わせください。
OpenShift 固有の問題については、Red Hat OpenShift のドキュメントを参照してください。

最終更新日 2026年9月30日

​はじめに

​前提条件

​バージョン要件

​SSL/TLS の要件

​ハードウェア要件

​MySQL データベース

​Redis

​オブジェクトストレージ

​エアギャップ環境固有の要件

​エアギャップ環境を準備する

​ステップ 1: 内部コンテナーレジストリを設定する

​W&B コアコンポーネントのコンテナー

​依存関係のコンテナー

​イメージの完全なリストを取得する

​エアギャップ環境のレジストリにイメージを転送する

​ステップ 2: 内部 Helm チャートリポジトリを設定する

​ステップ 3: Helm リポジトリへのアクセスを設定する

​エアギャップ環境に W&B をデプロイする

​ステップ 4: Kubernetes Operator をインストールする

​ステップ 5: MySQL データベースを設定する

​ステップ 6: W&B Custom Resource を設定する

​ステップ 7: W&B プラットフォームをデプロイする

​OpenShift の設定

​OpenShift のセキュリティコンテキスト制約

​オプション 1: restricted SCC を使用する (推奨)

​オプション 2: カスタム SCC を作成する (必要な場合)

​OpenShift ルート

​OpenShift のイメージプル設定

​OpenShift の完全な設定例

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

​エアギャップ環境での追加の検証

​トラブルシューティング

​イメージプルのエラー

​OpenShift SCC エラー

​Helm チャートが見つからない

​よくある質問

​別のイングレスクラスを使用できますか？

​複数の証明書を含む証明書バンドルを扱うにはどうすればよいですか？

​自動更新を防ぐにはどうすればよいですか？

​パブリックリポジトリに接続できない環境でもデプロイメントは動作しますか？

​エアギャップ環境で W&B を更新するにはどうすればよいですか？

​次のステップ

​ヘルプ

はじめに

前提条件

バージョン要件

SSL/TLS の要件

ハードウェア要件

MySQL データベース

Redis

オブジェクトストレージ

エアギャップ環境固有の要件

エアギャップ環境を準備する

ステップ 1: 内部コンテナーレジストリを設定する

W&B コアコンポーネントのコンテナー

依存関係のコンテナー

イメージの完全なリストを取得する

エアギャップ環境のレジストリにイメージを転送する

ステップ 2: 内部 Helm チャートリポジトリを設定する

ステップ 3: Helm リポジトリへのアクセスを設定する

エアギャップ環境に W&B をデプロイする

ステップ 4: Kubernetes Operator をインストールする

ステップ 5: MySQL データベースを設定する

ステップ 6: W&B Custom Resource を設定する

ステップ 7: W&B プラットフォームをデプロイする

OpenShift の設定

OpenShift のセキュリティコンテキスト制約

オプション 1: restricted SCC を使用する (推奨)

オプション 2: カスタム SCC を作成する (必要な場合)

OpenShift ルート

OpenShift のイメージプル設定

OpenShift の完全な設定例

インストールを確認する

エアギャップ環境での追加の検証

トラブルシューティング

イメージプルのエラー

OpenShift SCC エラー

Helm チャートが見つからない

よくある質問

別のイングレスクラスを使用できますか？

複数の証明書を含む証明書バンドルを扱うにはどうすればよいですか？

自動更新を防ぐにはどうすればよいですか？

パブリックリポジトリに接続できない環境でもデプロイメントは動作しますか？

エアギャップ環境で W&B を更新するにはどうすればよいですか？

次のステップ

ヘルプ