エアギャップ Kubernetes へのデプロイ - Weights & Biases Documentation

はじめに

このガイドでは、エアギャップ環境、完全に切り離された環境、または制限付きネットワークの顧客管理環境に W&B Platform をデプロイするためのステップごとの手順を説明します。エアギャップデプロイは、次のような環境で一般的です。

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

必要な W&B イメージとチャートをホストするために、内部コンテナーレジストリと Helm リポジトリを使用します。これらのコマンドは、Kubernetes クラスターに適切にアクセスできるシェルコンソールで実行してください。これらのコマンドは、Kubernetes アプリケーションのデプロイに使用している任意の CI/CD ツールで動作するように調整できます。インターネット接続のある標準的なオンプレミス Kubernetes デプロイについては、Deploy W&B with Kubernetes Operator を参照してください。

前提条件

始める前に、エアギャップ環境が以下の要件を満たしていることを確認してください。

バージョン要件

ソフトウェア	最小バージョン
Kubernetes	v1.32 以降 (サポートされる Kubernetes バージョン)
Helm	v3.x
MySQL	v8.0.x が必須です (v8.0.32 以降) 。v8.0.44 以降を推奨します。 Aurora MySQL 3.x version は v3.05.2 以降である必要があります
Redis	v7.x

SSL/TLS 要件

W&B では、クライアントとサーバー間の安全な通信のために、有効な署名付き SSL/TLS 証明書が必要です。SSL/TLS の終端は ingress/load balancer で行う必要があります。W&B Server アプリケーション自体は、SSL または TLS 接続を終端しません。重要: W&B は自己署名証明書およびカスタム CA をサポートしていません。自己署名証明書を使用するとユーザーに問題が生じるため、サポート対象外です。可能であれば、Let’s Encrypt のようなサービスを使用して、load balancer に信頼できる証明書を提供するのが効果的です。Caddy や Cloudflare のようなサービスを使えば、SSL を代わりに管理できます。セキュリティポリシーで、信頼できるネットワーク内でも SSL 通信が必要な場合は、Istio のようなツールや side car containers の使用を検討してください。

ハードウェア要件

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

MySQL データベース

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

マネージドデータベースサービスには、自動バックアップ、監視、高可用性、パッチ適用の機能があり、運用負荷を軽減できます。 MySQL の要件全体 (推奨サイジングや設定パラメーターを含む) については、リファレンスアーキテクチャを参照してください。データベース作成用の SQL については、ベアメタルガイドを参照してください。デプロイ環境のデータベース設定に関するご質問は、サポートまたは担当の AISE までお問い合わせください。セルフマネージドインスタンス向けの MySQL の設定パラメーターについては、リファレンスアーキテクチャの MySQL 設定セクションを参照してください。

Redis

W&B では、コンポーネントによるジョブキューイングとデータキャッシュのために、単一ノード構成の Redis 7.x デプロイが必要です。テストや概念実証の開発を容易にするため、W&B セルフマネージドにはローカルの Redis デプロイが含まれていますが、これは本番デプロイには適していません。本番デプロイでは、W&B は次の環境にある Redis インスタンスに接続できます。

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
お使いのクラウドまたはオンプレミスのインフラストラクチャーでホストされている Redis デプロイ

オブジェクトストレージ

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

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

MinIO Open Source は、アクティブな開発や事前コンパイル済みバイナリの提供がない maintenance mode です。本番デプロイでは、W&B はマネージドオブジェクトストレージサービス、または MinIO Enterprise (AIStor) などのエンタープライズ向け S3 互換ソリューションの使用を推奨しています。

IAM ポリシー、CORS 設定、アクセス設定を含む詳細なバケットプロビジョニング手順については、Bring Your Own Bucket (BYOB) ガイドを参照してください。完全な要件については、リファレンスアーキテクチャのオブジェクトストレージセクションを参照してください。オブジェクトストレージのプロビジョニングに関する詳細は、Bring Your Own Bucket (BYOB) ガイドを参照してください。エアギャップ環境では、通常、MinIO Enterprise、NetApp StorageGRID、Dell ECS などのオンプレミスの S3 互換ストレージを使用します。

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

上記の標準的な要件に加えて、エアギャップ環境でのデプロイには次のものが必要です。

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

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

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

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

エアギャップ環境でデプロイを成功させるには、必要なすべてのコンテナーイメージを、エアギャップ環境内のコンテナーレジストリで利用できるようにしておく必要があります。

W&B Operator の要件を把握し、コンテナーレジストリ内のイメージを定期的に更新して維持する責任は、お客様にあります。必要なコンテナーイメージとそのバージョンの最新一覧については、Helm チャートを参照するか、W&B サポートまたは担当の 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 charts repository から W&B Helm チャートをダウンロードします。
# helm-charts リポジトリをクローンする git clone https://github.com/wandb/helm-charts.git cd helm-charts

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

# 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 "^#"

または、次のコマンドを使用してリポジトリ名のみを抽出できます (バージョンタグは除く) 。

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

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

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

以下の例にあるバージョン番号は、上記の step 2 で確認した Helm チャートの実際のバージョンに置き換えてください。ここで示しているバージョンはあくまで例であり、古くなる可能性があります。

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

# バージョン変数を設定する（Helm チャートのバージョンに合わせて更新してください）
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
# ...そのほかのすべてのイメージも保存する

承認済みの方法 (USB ドライブ、セキュアなファイル転送など) を使用して、.tar ファイルをエアギャップ環境に転送します。

エアギャップ環境で、イメージをロードし、内部レジストリに push します。

# 上で使用したものと同じバージョン変数を設定する
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}
# ...そのほかのすべてのイメージにもタグを付ける

# 内部レジストリに 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 チャートリポジトリを設定する

コンテナーイメージに加えて、次の 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 (Controller Manager) をデプロイします。operator-wandb チャートは、Custom Resource (CR) で設定した値を使用して W&B Platform をデプロイします。

Step 3: 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 をデプロイする

Step 4: Kubernetes Operator をインストールする

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

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

operator と Custom Resource Definition (CRD) をインストールします。

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

operator が実行中であることを確認します。
kubectl get pods -n wandb
Running 状態の operator pod が表示されるはずです。

サポートされる values の詳細については、Kubernetes operator GitHub repository の values ファイルを参照してください。

Step 5: MySQL データベースを設定する

W&B Custom Resource を設定する前に、外部の MySQL データベースを設定してください。本番デプロイでは、利用可能であればマネージドデータベースサービスを使用することを W&B は強く推奨しています。ただし、独自の MySQL インスタンスを運用している場合は、データベースとユーザーを作成してください。次の 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;

MySQL の設定パラメーターについては、リファレンスアーキテクチャの MySQL 設定パラメーターのセクションを参照してください。

Step 6: W&B Custom Resource を設定する

W&B Kubernetes Operator をインストールしたら、Custom Resource (CR) を設定して、社内の Helm リポジトリとコンテナーレジストリを参照するようにします。この設定により、W&B プラットフォームに必要なコンポーネントのデプロイ時に、Kubernetes operator は社内の registry と repository を使用します。

以下の設定例には、いずれ古くなるイメージのバージョン tags が含まれています。すべての tag: の値を、Step 1 で社内 registry に転送した実際のバージョンに置き換えてください。

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

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

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

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

# 作成中の 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 では、pod の権限を制御するために Security Context Constraints (SCC) を使用します。デフォルトでは、pod には restricted 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

    # 他のcomponentsにも同様に繰り返す: 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 Routes

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

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

OpenShift のイメージプル設定

OpenShift クラスターで認証が必要な内部イメージレジストリを使用している場合:

イメージプルシークレットを作成します。

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: の値を、Step 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制限付き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 サポートまたは担当の W&B サポートエンジニアにお問い合わせください。

インストールを確認する

W&B をデプロイしたら、インストールが正常に機能していることを確認してください。インストールを確認するには、W&B では W&B CLI の使用を推奨しています。verify command は、すべてのコンポーネントと設定を検証する複数のテストを実行します。

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

インストールを確認するには、次の step に従います。

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

インストールが成功し、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サポートまでお問い合わせください。

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

エアギャップデプロイでは、次の点も確認してください。

イメージプル: すべての 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 コンソールにアクセスし、ライセンスが有効になっていることを確認します。

トラブルシューティング

イメージプルエラー

Pod がイメージをプルできない場合:

イメージが内部レジストリに存在することを確認します
イメージプルシークレットが正しく設定されていることを確認します
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 チャートが見つからない

operator が platform チャートを見つけられない場合:

Custom Resource 内のチャートリポジトリ URL を確認します
operator の pod から内部 Helm リポジトリにアクセスできることを確認します
リポジトリ内にチャートが存在することを確認します:
helm search repo local-repo/operator-wandb

よくある質問

別の ingress class を使用できますか？

はい。Custom Resource の ingress 設定を変更して、使用する ingress class を設定できます。

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 が自動更新されないように operator を設定します。

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

詳しくは、自動アプリ version 更新を無効にするを参照してください。

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

このデプロイはパブリックリポジトリに接続しなくても動作しますか？

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

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

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

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

次のステップ

デプロイが正常に完了したら:

ユーザー認証を設定する: SSO またはその他の認証方式を設定します
監視を設定する: W&B インスタンスとインフラストラクチャーの監視を設定します
更新を計画する: Server upgrade process を確認し、更新の実施頻度を定めます
バックアップを設定する: MySQL データベースのバックアップ手順を確立します
プロセスを文書化する: ご利用のエアギャップ環境向けの更新手順の runbook を作成します

サポートを受ける

デプロイ中に問題が発生した場合:

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

Kubernetes Operator を使用して W&B をデプロイする W&B のライセンスとバージョンを更新する

⌘I

​はじめに

​前提条件

​バージョン要件

​SSL/TLS 要件

​ハードウェア要件

​MySQL データベース

​Redis

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

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

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

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

​主要なW&Bコンポーネントのコンテナー

​依存コンテナー

​完全なイメージ一覧を取得する

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

​Step 2: 内部 Helm チャートリポジトリを設定する

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

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

​Step 4: Kubernetes Operator をインストールする

​Step 5: MySQL データベースを設定する

​Step 6: W&B Custom Resource を設定する

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

​OpenShift の設定

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

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

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

​OpenShift Routes

​OpenShift のイメージプル設定

​OpenShift の完全な設定例

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

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

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

​イメージプルエラー

​OpenShift の SCC エラー

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

​よくある質問

​別の ingress class を使用できますか？

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

​どうすれば自動更新を防止できますか

​このデプロイはパブリックリポジトリに接続しなくても動作しますか？

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

​次のステップ

​サポートを受ける

はじめに

前提条件

バージョン要件

SSL/TLS 要件

ハードウェア要件

MySQL データベース

Redis

オブジェクトストレージ

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

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

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

主要なW&Bコンポーネントのコンテナー

依存コンテナー

完全なイメージ一覧を取得する

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

Step 2: 内部 Helm チャートリポジトリを設定する

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

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

Step 4: Kubernetes Operator をインストールする

Step 5: MySQL データベースを設定する

Step 6: W&B Custom Resource を設定する

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

OpenShift の設定

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

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

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

OpenShift Routes

OpenShift のイメージプル設定

OpenShift の完全な設定例

インストールを確認する

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

トラブルシューティング

イメージプルエラー

OpenShift の SCC エラー

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

よくある質問

別の ingress class を使用できますか？

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

どうすれば自動更新を防止できますか

このデプロイはパブリックリポジトリに接続しなくても動作しますか？

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

次のステップ

サポートを受ける