Déployer sur Kubernetes isolé du réseau - Weights & Biases Documentation

Introduction

Ce guide fournit des instructions détaillées pour déployer la plateforme W&B dans des environnements gérés par le client, isolés du réseau (isolés du réseau), entièrement déconnectés ou soumis à des restrictions réseau. Les déploiements isolés du réseau sont courants dans :

Les installations gouvernementales sécurisées
Les établissements financiers soumis à une isolation réseau stricte
Les organisations de santé soumises à des exigences de conformité
Les environnements de systèmes de contrôle industriels (ICS)
Les centres de recherche disposant de réseaux classifiés

Utilisez un registre de conteneurs interne et un dépôt Helm pour héberger les images et charts W&B requis. Exécutez ces commandes dans un terminal shell disposant d’un accès approprié au cluster Kubernetes. Vous pouvez adapter ces commandes à n’importe quel outil CI/CD utilisé pour déployer des applications Kubernetes. Pour les déploiements Kubernetes on-premises standard avec connectivité Internet, voir Déployer W&B avec l’opérateur Kubernetes.

Prérequis

Avant de commencer, assurez-vous que votre environnement isolé du réseau répond aux exigences suivantes.

Versions requises

Logiciel	Version minimale
Kubernetes	v1.32 ou ultérieure (Versions de Kubernetes prises en charge)
Helm	v3.x
MySQL	v8.0.x est requis ; v8.0.32 ou ultérieure ; v8.0.44 ou ultérieure est recommandée. Les versions Aurora MySQL 3.x doivent être en v3.05.2 ou ultérieure
Redis	v7.x

Prérequis SSL/TLS

W&B exige un certificat SSL/TLS valide, signé par une autorité reconnue, pour sécuriser les communications entre les clients et le serveur. La terminaison SSL/TLS doit se faire au niveau de l’ingress/de l’équilibreur de charge. L’application W&B Server ne termine pas les connexions SSL ou TLS. Important : W&B ne prend pas en charge les certificats auto-signés ni les autorités de certification personnalisées. L’utilisation de certificats auto-signés entraînera des problèmes pour les utilisateurs et n’est pas prise en charge. Si possible, utiliser un service comme Let’s Encrypt est un excellent moyen de fournir des certificats approuvés à votre équilibreur de charge. Des services comme Caddy et Cloudflare gèrent le SSL pour vous. Si vos politiques de sécurité exigent une communication SSL au sein de vos réseaux de confiance, envisagez d’utiliser un outil comme Istio et des conteneurs sidecar.

Prérequis matériels

Architecture CPU : W&B fonctionne uniquement sur des processeurs Intel (x86). ARM n’est pas pris en charge. Dimensionnement : Pour les recommandations de dimensionnement du processeur, de la mémoire et du disque pour les nœuds Kubernetes et MySQL, consultez la section Dimensionnement de l’architecture de référence. Les exigences varient selon que vous exécutez Models, Weave ou les deux.

Base de données MySQL

W&B nécessite une base de données MySQL externe. Pour la Production, W&B recommande fortement d’utiliser des services de base de données gérés :

Les services de base de données gérés offrent des sauvegardes automatisées, de la supervision, une haute disponibilité et l’application des correctifs, tout en réduisant la charge opérationnelle. Voir l’architecture de référence pour connaître l’ensemble des exigences MySQL, y compris les recommandations de dimensionnement et les paramètres de configuration. Pour le SQL de création de la base de données, consultez le guide bare-metal. Pour toute question sur la configuration de la base de données de votre déploiement, contactez l’assistance ou votre AISE. Pour les paramètres de configuration de MySQL pour les instances autogérées, voir la section de l’architecture de référence consacrée à la configuration de MySQL.

Redis

W&B dépend d’un déploiement Redis 7.x à nœud unique, utilisé par les composants de W&B pour mettre les jobs en file d’attente et mettre les données en cache. Pour plus de commodité lors des tests et du développement de preuves de faisabilité, W&B Self-Managed inclut un déploiement Redis local qui n’est pas adapté aux déploiements de production. Pour les déploiements de production, W&B peut se connecter à une instance Redis dans les environnements suivants :

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
Déploiement Redis hébergé dans votre cloud ou sur votre infrastructure sur site

Stockage d’objets

W&B requiert un stockage d’objets prenant en charge les URL pré-signées et CORS. Fournisseurs de stockage recommandés :

Amazon S3 : service de stockage d’objets offrant une évolutivité, une disponibilité des données, une sécurité et des performances de premier plan.
Google Cloud Storage : service géré permettant de stocker des données non structurées à grande échelle.
Azure Blob Storage : solution de stockage d’objets cloud pour stocker de grandes quantités de données non structurées.
CoreWeave AI Object Storage : service de stockage d’objets hautes performances, compatible S3, optimisé pour les charges de travail d’IA.
Stockage compatible S3 pour les entreprises : MinIO Enterprise (AIStor), NetApp StorageGRID ou d’autres solutions de niveau entreprise

MinIO Open Source est en mode de maintenance, sans développement actif ni binaires précompilés. Pour les déploiements de production, W&B recommande d’utiliser des services de stockage d’objets gérés ou des solutions compatibles S3 pour les entreprises, telles que MinIO Enterprise (AIStor).

Pour des instructions détaillées sur le provisionnement du bucket, y compris les stratégies IAM, la configuration CORS et la configuration de l’accès, voir le guide Bring Your Own Bucket (BYOB). Voir la section sur le stockage d’objets de l’architecture de référence pour connaître l’ensemble des exigences. Pour des conseils détaillés sur le provisionnement du stockage d’objets, consultez le guide Bring Your Own Bucket (BYOB). Dans les environnements isolés du réseau, vous utiliserez généralement une solution de stockage sur site compatible S3, telle que MinIO Enterprise, NetApp StorageGRID ou Dell ECS.

Exigences spécifiques aux environnements isolés du réseau

En plus des exigences standard ci-dessus, les déploiements isolés du réseau nécessitent :

Registre interne de conteneurs : un accès à un registre privé de conteneurs (Harbor, JFrog Artifactory, Nexus, etc.) contenant toutes les images W&B requises
Dépôt Helm interne : un accès à un dépôt privé de chart Helm contenant les charts Helm W&B
Capacité de transfert d’images : une méthode permettant de transférer des images de conteneur depuis un système connecté à Internet vers votre registre isolé du réseau
Fichier de licence : une licence W&B Enterprise valide. Pour obtenir une licence (par exemple, depuis une machine connectée à Internet), voir la section License de la page Requirements, ou contactez votre équipe commerciale W&B.

Pour consulter l’ensemble des exigences d’infrastructure, y compris la configuration du réseau et de l’équilibreur de charge, voir l’architecture de référence.

Préparez votre environnement isolé du réseau

Étape 1 : Configurer le registre de conteneurs interne

Pour réussir un déploiement isolé du réseau, toutes les images de conteneur requises doivent être disponibles dans votre registre de conteneurs isolé du réseau.

Il vous incombe de suivre les exigences de l’opérateur W&B et de tenir votre registre de conteneurs à jour avec les dernières images. Pour obtenir la liste la plus récente des images de conteneur et des versions requises, référez-vous au chart Helm ou contactez l’assistance W&B ou votre ingénieur d’assistance W&B attitré.

Conteneurs des composants W&B essentiels

Les images principales suivantes sont requises :

docker.io/wandb/controller - opérateur Kubernetes W&B
docker.io/wandb/local - serveur d’application W&B
docker.io/wandb/console - console de gestion W&B
docker.io/wandb/megabinary - microservices W&B (API, executor, glue, parquet)

Conteneurs de dépendances

Les images de dépendances tierces suivantes sont requises :

docker.io/bitnamilegacy/redis - Requis pour le déploiement local de Redis pendant les phases de test et de développement. Pour les exigences Redis en Production, voir la section Redis dans les prérequis.
docker.io/otel/opentelemetry-collector-contrib - Agent OpenTelemetry pour collecter les métriques et les journaux
quay.io/prometheus/prometheus - Prometheus pour la collecte de métriques
quay.io/prometheus-operator/prometheus-config-reloader - Dépendance Prometheus

Obtenir la liste complète des images

Pour extraire la liste complète des images et des versions requises depuis le chart Helm :

Sur un système connecté à Internet, téléchargez les charts Helm W&B depuis le dépôt des charts Helm W&B :
# Cloner le dépôt helm-charts git clone https://github.com/wandb/helm-charts.git cd helm-charts

Inspectez les fichiers values.yaml pour identifier toutes les images de conteneur et leurs versions :

# Extraire les références d'image du chart de l'opérateur
helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#"

# Extraire les références d'image du chart de la plateforme
helm show values charts/operator-wandb | grep -E "repository:|tag:" | grep -v "^#"

Vous pouvez également utiliser cette commande pour extraire uniquement les noms des dépôts (sans les tags de version) :

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

La liste des dépôts ressemblera à ceci :

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

Pour obtenir les tags de version spécifiques à chaque image, utilisez la première commande ci-dessus (grep -E "repository:|tag:") ; elle affichera à la fois les noms des dépôts et les tags de version correspondants.

Transférer les images vers un registre isolé du réseau

Sur un système connecté à Internet, récupérez et enregistrez toutes les images requises.

Remplacez les numéros de version dans les exemples ci-dessous par les versions réelles issues de l’inspection de votre chart Helm à l’étape 2 ci-dessus. Les versions indiquées ici sont données à titre d’exemple et deviendront obsolètes.

Utilisez des variables shell pour gérer les versions de manière cohérente :

# Définir les variables de version (mettez-les à jour selon les versions de votre chart Helm)
CONTROLLER_VERSION="1.13.3"
APP_VERSION="0.59.2"
CONSOLE_VERSION="2.12.2"

# Récupérer les images
docker pull wandb/controller:${CONTROLLER_VERSION}
docker pull wandb/local:${APP_VERSION}
docker pull wandb/console:${CONSOLE_VERSION}
docker pull wandb/megabinary:${APP_VERSION}
# ... récupérer toutes les autres images requises avec leurs versions

# Enregistrer les images dans des fichiers .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
# ... enregistrer toutes les autres images

Transférez les fichiers .tar vers votre environnement isolé du réseau à l’aide de la méthode approuvée dans votre organisation (clé USB, transfert de fichiers sécurisé, etc.).

Dans votre environnement isolé du réseau, chargez les images et envoyez-les vers votre registre interne :

# Définir les mêmes variables de version que ci-dessus
CONTROLLER_VERSION="1.13.3"
APP_VERSION="0.59.2"
CONSOLE_VERSION="2.12.2"
INTERNAL_REGISTRY="registry.yourdomain.com"

# Charger les images
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
# ... charger toutes les autres images

# Ajouter un tag pour le registre interne
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}
# ... ajouter un tag à toutes les autres images

# Envoyer vers le registre interne
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}
# ... envoyer toutes les autres images

Étape 2 : Configurer le dépôt interne de charts Helm

En plus des images de conteneur, assurez-vous que les charts Helm suivants sont disponibles dans votre dépôt Helm interne :

Sur un système connecté à Internet, téléchargez les charts :

# Ajouter le dépôt Helm W&B
helm repo add wandb https://wandb.github.io/helm-charts
helm repo update

# Télécharger les charts
helm pull wandb/operator --version 1.13.3
helm pull wandb/operator-wandb --version 0.18.0

Transférez les fichiers de chart .tgz vers votre environnement isolé du réseau et importez-les dans votre dépôt Helm interne conformément aux procédures de votre dépôt. Le chart operator déploie l’opérateur Kubernetes W&B (Controller Manager). Le chart operator-wandb déploie la plateforme W&B à l’aide des valeurs configurées dans la Ressource personnalisée (CR).

Étape 3 : Configurer l’accès au dépôt Helm

Dans votre environnement isolé, configurez Helm pour utiliser votre dépôt interne :
helm repo add local-repo https://charts.yourdomain.com helm repo update

Vérifiez que les charts sont disponibles :

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

Déployer W&B dans un environnement isolé (air-gapped)

Étape 4 : Installer l’opérateur Kubernetes

L’opérateur Kubernetes W&B (controller manager) gère les composants de la plateforme W&B. Pour l’installer dans un environnement isolé du réseau, configurez-le pour utiliser votre registre de conteneurs interne.

Créez un fichier values.yaml avec le contenu suivant :
image: repository: registry.yourdomain.com/wandb/controller tag: 1.13.3 airgapped: true
Remplacez le dépôt et le tag par les versions réelles que vous avez transférées vers votre registre interne à l’étape 1. La version indiquée ici (1.13.3) est un exemple et deviendra obsolète.

Installez l’opérateur et la définition de ressource personnalisée (CRD) :

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

Vérifiez que l’opérateur est en cours d’exécution :
kubectl get pods -n wandb
Vous devriez voir le pod de l’opérateur dans l’état Running.

Pour plus de détails sur les valeurs prises en charge, voir le fichier values du dépôt GitHub de l’opérateur Kubernetes.

Étape 5 : Configurer la base de données MySQL

Avant de configurer la Ressource personnalisée W&B, configurez une base de données MySQL externe. Pour les déploiements de production, W&B recommande fortement d’utiliser des services de base de données gérés lorsqu’ils sont disponibles. Cependant, si vous exploitez votre propre instance MySQL, créez la base de données et l’utilisateur : Créez une base de données et un utilisateur à l’aide des commandes SQL suivantes. Remplacez SOME_PASSWORD par un mot de passe robuste de votre choix :

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;

Pour les paramètres de configuration MySQL, voir la section de configuration MySQL de l’architecture de référence.

Étape 6 : Configurer la ressource personnalisée W&B

Après avoir installé l’opérateur Kubernetes W&B, configurez la ressource personnalisée (CR) pour qu’elle pointe vers votre dépôt Helm interne et votre registre de conteneurs interne. Cette configuration garantit que l’opérateur Kubernetes utilise votre registre et votre dépôt internes lors du déploiement des composants requis de la plateforme W&B.

L’exemple de configuration ci-dessous inclut des tags de version d’image qui deviendront obsolètes. Remplacez toutes les valeurs tag: par les versions réelles que vous avez transférées vers votre registre interne à l’étape 1.

Créez un fichier nommé wandb.yaml avec le contenu suivant :

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'

    # Configurer toutes les images de composants pour utiliser le registre interne
    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

Remplacez toutes les valeurs fictives (noms d’hôte, mots de passe, tags, etc.) par vos valeurs de configuration réelles. L’exemple ci-dessus présente les composants les plus couramment utilisés.

Selon vos besoins de déploiement, vous devrez peut-être également configurer les dépôts d’images pour des composants supplémentaires, tels que :

settingsMigrationJob
weave-trace
filestream
flat-runs-table

Consultez le fichier values du dépôt Helm W&B pour obtenir la liste complète des composants configurables.

Étape 7 : Déployer la plateforme W&B

Appliquez la Ressource personnalisée W&B pour déployer la plateforme :
kubectl apply -f wandb.yaml

Surveillez l’avancement du déploiement :

# Surveiller la création des pods
kubectl get pods -n wandb --watch

# Vérifier le statut du déploiement
kubectl get weightsandbiases -n wandb

# Consulter les journaux de l'opérateur
kubectl logs -n wandb deployment/wandb-operator-controller-manager

Le déploiement peut prendre plusieurs minutes, le temps que l’opérateur crée tous les composants nécessaires.

Configuration d’OpenShift

W&B prend entièrement en charge le déploiement sur des clusters Kubernetes OpenShift isolés. Les déploiements OpenShift nécessitent une configuration supplémentaire du contexte de sécurité en raison des politiques de sécurité plus strictes d’OpenShift.

Contraintes de contexte de sécurité d’OpenShift

OpenShift utilise les Security Context Constraints (SCC) pour contrôler les autorisations des pods. Par défaut, OpenShift attribue la SCC restricted aux pods, ce qui empêche de s’exécuter en tant que root et exige des identifiants utilisateur spécifiques.

Option 1 : Utiliser la SCC restricted (recommandée)

Configurez les composants W&B pour qu’ils s’exécutent avec la SCC restricted en définissant les contextes de sécurité appropriés dans votre Ressource personnalisée :

spec:
  values:
    # Configurer les contextes de sécurité pour tous les pods
    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

    # Répéter pour les autres composants : api, executor, glue, parquet, weave

Option 2 : Créer une SCC personnalisée (si nécessaire)

Si votre déploiement nécessite des capacités qui ne sont pas disponibles dans la SCC restricted, créez une SCC personnalisée :

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

Appliquez le SCC :
oc apply -f wandb-scc.yaml

Associez le SCC aux comptes de service de 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

Routes d’OpenShift

OpenShift utilise des Routes au lieu de l’ingress Kubernetes standard. Configurez W&B pour utiliser les Routes d’OpenShift :

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

Configuration de récupération d’image pour OpenShift

Si votre cluster OpenShift utilise un registre d’images interne avec authentification :

Créez un secret de récupération d’image :

kubectl create secret docker-registry wandb-registry-secret \
  --docker-server=registry.yourdomain.com \
  --docker-username=<username> \
  --docker-password=<password> \
  --namespace=wandb

Ajoutez une référence au secret dans votre Ressource personnalisée :

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

Exemple complet d’OpenShift

Voici un exemple complet de CR pour un déploiement OpenShift en environnement isolé :

Remplacez toutes les valeurs tag: de cet exemple par les versions réelles que vous avez transférées vers votre registre interne à l’étape 1. Les versions indiquées ici sont données à titre d’exemple et deviendront obsolètes.

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>

    # Spécifique à OpenShift : utiliser les Routes plutôt que l'Ingress
    ingress:
      enabled: false
    
    route:
      enabled: true
      host: wandb.apps.openshift.yourdomain.com
      tls:
        enabled: true
        termination: edge

    # Secret de récupération d'image pour le registre interne
    imagePullSecrets:
      - name: wandb-registry-secret

    # Contextes de sécurité pour le SCC restricted d'OpenShift
    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

    # Répéter les contextes de sécurité pour : api, executor, glue, parquet, weave
    # (abrégé par souci de clarté)

Contactez l’assistance W&B ou votre ingénieur d’assistance W&B attitré pour obtenir des exemples complets de configuration d’OpenShift adaptés à vos exigences de sécurité.

Vérifiez votre installation

Après avoir déployé W&B, vérifiez que l’installation fonctionne correctement : Pour vérifier l’installation, W&B recommande d’utiliser le W&B CLI. La commande verify exécute plusieurs tests pour vérifier l’ensemble des composants et de la configuration.

Cette étape suppose que le premier compte administrateur a été créé depuis le navigateur.

Suivez ces étapes pour vérifier l’installation :

Installez le W&B CLI :

pip install wandb

Connectez-vous à W&B :

wandb login --host=https://YOUR_DNS_DOMAIN

Par exemple :

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

Vérifiez l’installation :

wandb verify

Une installation réussie et un déploiement W&B pleinement opérationnel affichent la sortie suivante :

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...........................✅

Contactez l’assistance W&B en cas d’erreur.

Vérifications supplémentaires pour un environnement isolé du réseau

Pour les déploiements isolés du réseau, vérifiez également les points suivants :

Récupération d’image : assurez-vous que tous les pods ont bien récupéré les images depuis votre registre interne :
kubectl get pods -n wandb -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[*].image}{"\n"}{end}'
Toutes les images doivent pointer vers votre registre interne, et tous les pods doivent être dans l’état Running.
Connectivité externe : vérifiez que W&B ne tente pas d’établir de connexions externes (cela ne devrait pas arriver en mode isolé du réseau) :
kubectl logs -n wandb deployment/wandb-app --tail=100 | grep -i "connection"
Validation de la licence : accédez à la console W&B et vérifiez que votre licence est active.

Dépannage

Erreurs de récupération d’image

Si les pods ne parviennent pas à récupérer les images :

Vérifiez que les images existent dans votre registre interne
Vérifiez que le secret de récupération d’image est correctement configuré
Vérifiez la connectivité réseau depuis les nœuds Kubernetes vers le registre

Vérifiez les identifiants d’authentification du registre

# Tester la récupération d’image manuellement
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

Erreurs SCC d’OpenShift

Si des pods échouent en raison d’erreurs d’autorisation sur OpenShift :

# Vérifier quel SCC est utilisé
oc get pod <pod-name> -n wandb -o yaml | grep scc

# Vérifier les permissions du compte de service
oc describe scc wandb-scc
oc get rolebinding -n wandb

Chart Helm introuvable

Si l’opérateur ne parvient pas à trouver le chart de la plateforme :

Vérifiez l’URL du dépôt Helm dans la Ressource personnalisée
Vérifiez que le pod de l’opérateur peut accéder à votre dépôt Helm interne
Vérifiez que le chart existe dans votre dépôt :
helm search repo local-repo/operator-wandb

Foire aux questions

Puis-je utiliser une autre classe d’ingress ?

Oui, configurez votre classe d’ingress en modifiant les paramètres d’ingress dans votre ressource personnalisée :

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

Comment puis-je gérer des bundles de certificats contenant plusieurs certificats ?

Répartissez les certificats en plusieurs entrées dans la section customCACerts :

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

Comment puis-je empêcher les mises à jour automatiques ?

Configurez l’opérateur pour qu’il ne mette pas W&B à jour automatiquement :

Définissez airgapped: true dans l’installation de l’opérateur (cela désactive les vérifications automatiques de mise à jour)
Gérez les mises à jour de version en mettant à jour manuellement spec.chart.version dans votre Ressource personnalisée
Si nécessaire, désactivez les mises à jour automatiques depuis la console système de W&B

Voir Désactiver les mises à jour automatiques de la version de l’application pour plus de détails.

W&B recommande vivement aux clients disposant d’instances autogérées de mettre à jour leurs déploiements avec la dernière version au moins une fois par trimestre afin de conserver l’assistance et de bénéficier des dernières fonctionnalités, améliorations des performances et correctifs. W&B prend en charge une version majeure pendant 12 mois à compter de sa date de sortie initiale. Reportez-vous à Politiques et processus de version.

Le déploiement fonctionne-t-il sans connexion à des dépôts publics ?

Oui. Lorsque airgapped: true est défini dans la configuration de l’opérateur, l’opérateur Kubernetes utilise uniquement vos ressources internes et n’essaie pas de se connecter à des dépôts publics.

Comment puis-je mettre à jour W&B dans un environnement isolé du réseau ?

Pour mettre à jour W&B :

Téléchargez les nouvelles images de conteneur sur un système connecté à Internet
Transférez les images vers votre registre isolé du réseau
Téléversez les nouveaux charts Helm dans votre dépôt interne
Mettez à jour spec.chart.version et les tags d’image dans votre Ressource personnalisée
Appliquez la Ressource personnalisée mise à jour L’opérateur effectuera une mise à jour progressive des composants W&B.

Prochaines étapes

Après un déploiement réussi :

Configurer l’authentification des utilisateurs : Configurez SSO ou d’autres méthodes d’authentification
Mettre en place la supervision : Configurez la supervision de votre instance W&B et de votre infrastructure
Planifier les mises à jour : Consultez le processus de mise à niveau du serveur et définissez une cadence de mise à jour
Configurer les sauvegardes : Mettez en place des procédures de sauvegarde pour votre base de données MySQL
Documenter votre processus : Créez des runbooks pour vos procédures spécifiques de mise à jour en environnement isolé

Obtenir de l’aide

Si vous rencontrez des problèmes pendant le déploiement :

Consultez l’architecture de référence pour obtenir des conseils sur l’infrastructure
Consultez le guide de l’opérateur pour plus de détails sur la configuration
Contactez l’assistance W&B ou votre ingénieur d’assistance W&B dédié
Pour les problèmes spécifiques à OpenShift, consultez la documentation Red Hat OpenShift

Déployer W&B avec l’opérateur Kubernetes

Mettre à jour la licence et la version de W&B

⌘I

​Introduction

​Prérequis

​Versions requises

​Prérequis SSL/TLS

​Prérequis matériels

​Base de données MySQL

​Redis

​Stockage d’objets

​Exigences spécifiques aux environnements isolés du réseau

​Préparez votre environnement isolé du réseau

​Étape 1 : Configurer le registre de conteneurs interne

​Conteneurs des composants W&B essentiels

​Conteneurs de dépendances

​Obtenir la liste complète des images

​Transférer les images vers un registre isolé du réseau

​Étape 2 : Configurer le dépôt interne de charts Helm

​Étape 3 : Configurer l’accès au dépôt Helm

​Déployer W&B dans un environnement isolé (air-gapped)

​Étape 4 : Installer l’opérateur Kubernetes

​Étape 5 : Configurer la base de données MySQL

​Étape 6 : Configurer la ressource personnalisée W&B

​Étape 7 : Déployer la plateforme W&B

​Configuration d’OpenShift

​Contraintes de contexte de sécurité d’OpenShift

​Option 1 : Utiliser la SCC restricted (recommandée)

​Option 2 : Créer une SCC personnalisée (si nécessaire)

​Routes d’OpenShift

​Configuration de récupération d’image pour OpenShift

​Exemple complet d’OpenShift

​Vérifiez votre installation

​Vérifications supplémentaires pour un environnement isolé du réseau

​Dépannage

​Erreurs de récupération d’image

​Erreurs SCC d’OpenShift

​Chart Helm introuvable

​Foire aux questions

​Puis-je utiliser une autre classe d’ingress ?

​Comment puis-je gérer des bundles de certificats contenant plusieurs certificats ?

​Comment puis-je empêcher les mises à jour automatiques ?

​Le déploiement fonctionne-t-il sans connexion à des dépôts publics ?

​Comment puis-je mettre à jour W&B dans un environnement isolé du réseau ?

​Prochaines étapes

​Obtenir de l’aide

Introduction

Prérequis

Versions requises

Prérequis SSL/TLS

Prérequis matériels

Base de données MySQL

Redis

Stockage d’objets

Exigences spécifiques aux environnements isolés du réseau

Préparez votre environnement isolé du réseau

Étape 1 : Configurer le registre de conteneurs interne

Conteneurs des composants W&B essentiels

Conteneurs de dépendances

Obtenir la liste complète des images

Transférer les images vers un registre isolé du réseau

Étape 2 : Configurer le dépôt interne de charts Helm

Étape 3 : Configurer l’accès au dépôt Helm

Déployer W&B dans un environnement isolé (air-gapped)

Étape 4 : Installer l’opérateur Kubernetes

Étape 5 : Configurer la base de données MySQL

Étape 6 : Configurer la ressource personnalisée W&B

Étape 7 : Déployer la plateforme W&B

Configuration d’OpenShift

Contraintes de contexte de sécurité d’OpenShift

Option 1 : Utiliser la SCC restricted (recommandée)

Option 2 : Créer une SCC personnalisée (si nécessaire)

Routes d’OpenShift

Configuration de récupération d’image pour OpenShift

Exemple complet d’OpenShift

Vérifiez votre installation

Vérifications supplémentaires pour un environnement isolé du réseau

Dépannage

Erreurs de récupération d’image

Erreurs SCC d’OpenShift

Chart Helm introuvable

Foire aux questions

Puis-je utiliser une autre classe d’ingress ?

Comment puis-je gérer des bundles de certificats contenant plusieurs certificats ?

Comment puis-je empêcher les mises à jour automatiques ?

Le déploiement fonctionne-t-il sans connexion à des dépôts publics ?

Comment puis-je mettre à jour W&B dans un environnement isolé du réseau ?

Prochaines étapes

Obtenir de l’aide