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, déconnectés ou soumis à des restrictions réseau. En suivant ce guide, vous configurez un registre de conteneurs interne et un dépôt Helm pour héberger les images et charts W&B, installez l’opérateur Kubernetes W&B et déployez la plateforme W&B sans nécessiter de connectivité Internet sortante. Ce guide s’adresse aux administrateurs de plateforme et aux ingénieurs DevOps qui gèrent une infrastructure Kubernetes dans des réseaux réglementés ou isolés. Les déploiements isolés du réseau sont courants dans les environnements suivants :

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.

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.34 ou ultérieure (Versions de Kubernetes prises en charge)
Helm	v3.x
MySQL	Les déploiements W&B Autogéré doivent utiliser une version prise en charge de MySQL qui reçoit des correctifs de sécurité et des corrections de bugs critiques. Installez ou mettez à niveau vers MySQL 8.4.x, ou utilisez une version de service géré que votre fournisseur indique comme prise en charge et corrigée. Les chaînes de version d’Aurora MySQL diffèrent de celles de MySQL communautaire. Utilisez `SELECT version()` pour voir la chaîne complète de version du moteur et `SELECT aurora_version()` pour voir la version d’Aurora. La version 3 d’Aurora MySQL est compatible avec MySQL 8.0.x et reste prise en charge. Voir la gestion des versions d’Amazon Aurora ainsi que la documentation de votre fournisseur de cloud lorsque vous choisissez une version cible.
Redis	v7.x
ClickHouse	Requis pour Weave et certaines fonctionnalités OLAP de Models sur les déploiements autogérés. La version minimale dépend des fonctionnalités activées et de la version de votre serveur W&B. Voir la compatibilité de ClickHouse pour les mises à niveau et les versions du serveur W&B prises en charge.

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 ou de l’équilibreur de charge. L’application W&B Server ne termine pas les connexions SSL ou TLS.

W&B ne prend pas en charge les certificats auto-signés ni les autorités de certification personnalisées. Les certificats auto-signés entraînent des problèmes pour les utilisateurs et ne sont pas pris en charge.

Si possible, utilisez un service comme Let’s Encrypt pour 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 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 les exigences MySQL, y compris les recommandations de dimensionnement et les paramètres de configuration. Pour le SQL permettant de créer 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 la mise en file d’attente des jobs et la mise en cache des données. Pour les tests et les preuves de concept, W&B Autogéré inclut un déploiement Redis local. Ce déploiement intégré n’est pas adapté à un usage en production. Pour les déploiements en production, W&B peut se connecter à une instance Redis dans les environnements suivants :

Amazon ElastiCache
Google Cloud Memorystore
Azure Cache for Redis
Redis auto-hébergé dans votre cloud ou sur site

Stockage d’objets

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

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

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

Après avoir sélectionné un fournisseur, configurez le bucket afin que W&B puisse y accéder. Pour obtenir des instructions détaillées sur le provisionnement du bucket, notamment les stratégies IAM, la configuration CORS et la configuration des accès, voir le guide Bring Your Own Bucket (BYOB). Pour la liste complète des exigences de stockage d’objets, y compris les recommandations relatives à la capacité et aux performances, voir la section sur le stockage d’objets de l’architecture de référence. 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 précédentes, les déploiements isolés du réseau nécessitent ce qui suit :

Registre interne de conteneurs : un accès à un registre privé de conteneurs tel que Harbor, JFrog Artifactory ou Nexus, 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

Les étapes suivantes permettent de préparer votre environnement isolé du réseau à héberger les images de conteneur W&B et les charts Helm. Effectuez ces étapes avant d’installer l’opérateur ou de déployer la plateforme.

Étape 1 : Configurer le registre de conteneurs interne

Comme le cluster Kubernetes ne peut pas extraire d’images depuis des registres publics, toutes les images de conteneur requises doivent être disponibles dans votre registre de conteneurs interne isolé du réseau avant le déploiement.

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 operator
helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#"

# Extraire les références d'image du chart platform
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 précédente (grep -E "repository:|tag:"), qui affiche à la fois les noms des dépôts et les tags de version correspondants.

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

Sur un système connecté à Internet, téléchargez et enregistrez toutes les images requises.

Remplacez les numéros de version dans les exemples suivants par les versions réelles obtenues lors de l’inspection de votre chart Helm à l’étape précédente. Les versions indiquées ici sont données à titre d’exemple et deviennent obsolètes au fil du temps.

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"

# Télécharger 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}
# ... télécharger 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, par exemple une clé USB ou un transfert de fichiers sécurisé.

Dans votre environnement isolé du réseau, chargez les images et poussez-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

# Étiqueter 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}
# ... étiqueter toutes les autres images

# Pousser 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}
# ... pousser toutes les autres images

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

Une fois les images de conteneur en place, l’opérateur Kubernetes doit également avoir accès aux charts Helm W&B. 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 téléversez-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

Configurez votre client Helm local dans l’environnement isolé du réseau pour qu’il pointe vers votre dépôt interne, afin que les commandes d’installation suivantes puissent localiser les charts.

Dans votre environnement isolé du réseau, 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é du réseau

Une fois votre registre interne et votre dépôt Helm en place, vous pouvez désormais installer l’opérateur Kubernetes, configurer les services externes et déployer la plateforme W&B.

É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 devient obsolète au fil du temps.

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.

L’opérateur Kubernetes W&B est maintenant installé et prêt à déployer la plateforme W&B depuis votre dépôt de charts interne. 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 [PASSWORD] par un mot de passe robuste :

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;

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, au lieu de tenter d’accéder à des sources publiques.

L’exemple de configuration suivant inclut des tags de version d’image qui deviennent obsolètes au fil du temps. 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 appelé 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, telles que les noms d’hôte, les mots de passe et les tags, par vos valeurs de configuration réelles. L’exemple précédent 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, notamment les suivants :

settingsMigrationJob
weave-trace
filestream
flat-runs-table

Référez-vous au fichier de valeurs du dépôt Helm W&B pour consulter la liste complète des composants configurables.

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

Le fait d’appliquer la Ressource personnalisée déclenche l’installation par l’opérateur des composants de la plateforme W&B définis dans le chart operator-wandb, à partir de la configuration et des références d’image de wandb.yaml.

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

Surveillez la progression 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

# Afficher 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 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. Si vous effectuez un déploiement sur OpenShift, appliquez les configurations de cette section en plus des étapes précédentes.

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 pour OpenShift

L’exemple suivant montre une CR complète pour un déploiement OpenShift isolé du réseau :

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

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 des 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 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 afin de confirmer que la plateforme est accessible, que les pods sont en bon état et que le déploiement utilise uniquement vos ressources internes. Suivez les étapes générales de vérification, puis effectuez les vérifications supplémentaires propres aux environnements isolés du réseau dans la section suivante. Pour vérifier l’installation, W&B recommande d’utiliser le W&B CLI. La commande wandb verify exécute des tests qui confirment que les composants et les configurations fonctionnent comme prévu.

Cette procédure suppose que vous créez le premier compte administrateur dans un navigateur.

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 fois la commande exécutée, une installation réussie affiche 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 des images, vérifiez les points suivants :

Vérifiez que les images sont présentes dans votre registre interne.
Vérifiez que le secret de récupération d’image est correctement configuré.
Vérifiez la connectivité réseau entre les nœuds Kubernetes et le registre.
Vérifiez les identifiants d’authentification du registre.

Pour tester manuellement une récupération d’image :

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 autorisations 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 les points suivants :

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 ?

Pour configurer l’opérateur afin qu’il ne mette pas W&B à jour automatiquement, procédez comme suit :

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 effectue une mise à jour progressive des composants W&B.

Prochaines étapes

Après un déploiement réussi, effectuez les tâches suivantes :

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

​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 des 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é du réseau

​É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 pour 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 des 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é du réseau

É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 pour 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