Déployer W&B avec l’opérateur Kubernetes - Weights & Biases Documentation

Aperçu

Cette page explique aux administrateurs de la plateforme comment déployer et gérer W&B Server sur Kubernetes (dans le cloud ou sur site) à l’aide de l’opérateur Kubernetes W&B. À la fin, vous disposerez d’une installation W&B Server opérationnelle, gérée par l’opérateur et mise à niveau automatiquement. Utilisez ce guide si vous gérez vous-même un déploiement W&B et avez besoin d’une méthode d’installation qui fonctionne dans des environnements cloud, sur site et isolés du réseau. L’opérateur Kubernetes W&B est la méthode recommandée pour déployer W&B Server sur Kubernetes (dans le cloud ou sur site). Pour un aperçu de l’opérateur, savoir pourquoi W&B l’utilise et comprendre le fonctionnement de la hiérarchie de configuration, voir Autogéré.

Avant de commencer

Avant de déployer W&B avec l’opérateur Kubernetes, assurez-vous que votre infrastructure répond à toutes les exigences :

Vérifier les exigences de l’infrastructure : Voir la page des exigences d’infrastructure pour l’environnement Autogéré pour plus de détails sur :

Exigences relatives aux versions logicielles (Kubernetes, MySQL, Redis, Helm, ClickHouse)
- Exigences matérielles (architecture CPU, recommandations de dimensionnement)
- Configuration du cluster Kubernetes
- Exigences relatives au réseau, à SSL/TLS et au DNS

Obtenir une licence serveur W&B : Voir la section License sur la page des exigences.
Préparer les services externes : Configurer MySQL, Redis et le stockage d’objets avant le déploiement.

Pour plus d’informations, voir la page de l’architecture de référence.

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 des instructions complètes sur la configuration de MySQL, y compris les paramètres de configuration et la création de la base de données, voir la section MySQL de la page des exigences. Si vous effectuez une mise à niveau depuis MySQL 8.0.x, voir Mettre MySQL à niveau vers 8.4.x.

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

Voir la section de configuration de Redis externe pour savoir comment configurer une instance Redis externe dans les valeurs Helm.

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.

Provisionnez votre bucket de stockage

Avant de configurer W&B, vous devez provisionner votre bucket de stockage d’objets avec les politiques IAM requises, une configuration CORS et les identifiants d’accès nécessaires. Voir le guide Bring Your Own Bucket (BYOB) pour obtenir des instructions de provisionnement détaillées, étape par étape, pour :

Amazon S3 (y compris les politiques IAM et les politiques de bucket)
Google Cloud Storage (y compris les notifications PubSub)
Azure Blob Storage (y compris les identités gérées)
CoreWeave AI Object Storage
stockage compatible S3 (MinIO Enterprise, NetApp StorageGRID et d’autres solutions d’entreprise)

Voir la section de configuration du stockage d’objets pour plus de détails sur sa configuration dans les valeurs Helm.

clusters Kubernetes OpenShift

W&B prend en charge le déploiement sur les clusters Kubernetes OpenShift dans le cloud, sur site et dans des environnements isolés du réseau.

W&B recommande d’utiliser le chart Helm officiel de W&B pour l’installation.

Exécutez le conteneur avec un utilisateur non privilégié

OpenShift et d’autres orchestrateurs similaires rejettent souvent les conteneurs exécutés en tant que root. Les conteneurs W&B doivent donc être configurés pour s’exécuter sous un utilisateur non root qui appartient néanmoins au groupe root. Par défaut, les conteneurs utilisent un $UID de 999. Spécifiez un $UID >= 100000 et un $GID de 0 si votre orchestrateur exige que le conteneur s’exécute sous un utilisateur non root.

W&B doit démarrer avec le groupe root ($GID=0) pour que les autorisations du système de fichiers fonctionnent correctement.

Configurez des contextes de sécurité pour chaque composant W&B. Par exemple, pour configurer le composant API :

api:
  install: true
  image:
    repository: wandb/megabinary
    tag: 0.74.1  # Remplacez par votre version réelle
  pod:
    securityContext:
      fsGroup: 10001
      fsGroupChangePolicy: Always
      runAsGroup: 0
      runAsNonRoot: true
      runAsUser: 10001
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      privileged: false
      readOnlyRootFilesystem: false

Si nécessaire, configurez un contexte de sécurité personnalisé pour d’autres composants, comme app ou console. Pour plus de détails, voir Contexte de sécurité personnalisé.

Déployer l’application W&B Server

L’opérateur Kubernetes W&B avec Helm est la méthode d’installation recommandée pour tous les déploiements W&B Autogéré, y compris dans les environnements cloud, sur site et isolé du réseau.

Choisissez votre méthode de déploiement :

CLI Helm
Terraform

W&B fournit un chart Helm pour déployer l’opérateur Kubernetes W&B sur un cluster Kubernetes. Cette approche vous permet de déployer W&B Server avec la CLI Helm ou un outil de déploiement continu comme ArgoCD.Pour les considérations spécifiques au déploiement, voir Considérations spécifiques à l’environnement et Déployer avec Terraform sur un cloud public. Pour les environnements déconnectés, voir Déployer sur Kubernetes en environnement isolé.Suivez ces étapes pour installer l’opérateur Kubernetes W&B avec la CLI Helm :

Ajoutez le dépôt Helm W&B. Le chart Helm W&B est disponible dans le dépôt Helm W&B :
helm repo add wandb https://charts.wandb.ai helm repo update

Installez l’opérateur sur un cluster Kubernetes :

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

Configurez la ressource personnalisée de l’opérateur W&B pour déclencher l’installation de W&B Server. Créez un fichier nommé operator.yaml avec votre configuration de déploiement W&B. Référez-vous à la Référence de configuration pour connaître toutes les options disponibles. Voici une configuration minimale :

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

Lancez l’opérateur avec votre configuration personnalisée afin qu’il puisse installer, configurer et gérer l’application W&B Server :
kubectl apply -f operator.yaml
Attendez que le déploiement soit terminé. Cela prend quelques minutes.
Pour vérifier l’installation via l’interface utilisateur web, créez le premier compte administrateur, puis suivez les étapes de vérification décrites dans Vérifiez l’installation.

Une fois ces étapes terminées, vous disposez d’un opérateur Kubernetes W&B en cours d’exécution dans l’espace de noms wandb-cr et d’une application W&B Server que l’opérateur gère à partir de votre ressource personnalisée operator.yaml.

Déployez W&B avec Terraform pour des déploiements en infrastructure as code. Choisissez entre :

Module Terraform Helm : déploie l’opérateur sur une infrastructure Kubernetes existante.
Modules Terraform Cloud : déploiement complet de l’infrastructure et de l’application pour AWS, Google Cloud et Azure.

Pour les considérations propres à chaque déploiement, voir Considérations propres à l’environnement et Déployer avec Terraform sur le cloud public. Pour les environnements déconnectés, voir Déployer sur Kubernetes en environnement isolé.

Module Terraform Helm

Cette méthode prend en charge des déploiements personnalisés adaptés à des exigences spécifiques, en utilisant l’approche d’infrastructure as code de Terraform pour garantir la cohérence et la reproductibilité. Le module Terraform basé sur Helm officiel de W&B est disponible sur le Terraform Registry.Utilisez le code suivant comme point de départ. Il inclut toutes les options de configuration nécessaires pour un déploiement de niveau production :

module "wandb" {
  source  = "wandb/wandb/helm"

  spec = {
    values = {
      global = {
        host    = "https://<HOST_URI>"
        license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"

        bucket = {
          <details depend on the provider>
        }

        mysql = {
          <redacted>
        }
      }

      ingress = {
        annotations = {
          "a" = "b"
          "x" = "y"
        }
      }
    }
  }
}

Les options de configuration sont les mêmes que celles décrites dans la Référence de configuration, mais la syntaxe doit respecter le langage de configuration HashiCorp (HCL). Le module Terraform crée la définition de ressource personnalisée (CRD) de W&B.Pour voir comment W&B utilise en interne le module Terraform Helm pour déployer des installations de Cloud dédié pour ses clients, suivez ces liens :

Modules Terraform pour le cloud

W&B fournit un ensemble de modules Terraform pour AWS, Google Cloud et Azure. Ces modules déploient l’infrastructure complète, notamment des clusters Kubernetes, des équilibreurs de charge et des bases de données MySQL, ainsi que l’application W&B Server. L’opérateur Kubernetes W&B est inclus dans ces modules Terraform officiels W&B spécifiques à chaque cloud, dans les versions suivantes :

Registre Terraform	Code source	Version
AWS	https://github.com/wandb/terraform-aws-wandb	v4.0.0+
Azure	https://github.com/wandb/terraform-azurerm-wandb	v2.0.0+
Google Cloud	https://github.com/wandb/terraform-google-wandb	v2.0.0+

Ces modules installent l’opérateur Kubernetes W&B dans le cadre du déploiement, afin que vous puissiez l’utiliser pour gérer W&B Server dans votre environnement cloud sans configuration supplémentaire.Pour des instructions détaillées sur l’utilisation de ces modules spécifiques au cloud, voir Déployer avec Terraform sur un cloud public.

Vérifiez l’installation

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.

Activer le serveur MCP

Le serveur MCP de W&B est fourni comme sous-chart facultatif dans operator-wandb. Lorsqu’il est activé, l’opérateur déploie un serveur MCP au sein du cluster, exposé via votre ingress existant à l’adresse <global.host>/mcp, afin que tout client compatible MCP puisse s’y connecter à l’aide d’une clé API W&B. Il s’agit du même serveur que W&B propose dans sa version hébergée à l’adresse https://mcp.withwandb.com/mcp, mais pointé vers les données de votre déploiement. Pour la configuration du client côté utilisateur final et le catalogue des outils, voir Utiliser le serveur MCP de W&B. Cette section couvre uniquement l’activation côté opérateur.

Prérequis

Assurez-vous que votre déploiement remplit les exigences suivantes avant d’activer le serveur MCP :

Version du chart : operator-wandb 0.42.3 ou ultérieure. Le sous-chart mcp-server a été introduit dans 0.42.1, mais les champs Datadog et Confidentialité utilisés dans l’exemple suivant ont été ajoutés plus tard.
Weave Traces activé : le serveur MCP dépend de Weave Traces pour les outils de trace et pour la valeur par défaut de WF_TRACE_SERVER_URL. Définissez weave-trace.install: true. Si Weave Traces n’est pas activé, le rendu Helm échoue avec mcp-server requires weave-trace.install=true.
Ingress accessible : global.host doit déjà se résoudre et acheminer le trafic vers l’ingress W&B. Le pod MCP lit WANDB_BASE_URL depuis global.host et est disponible à l’adresse <global.host>/mcp.
Capacité des nœuds : le pod MCP demande par défaut 500m de CPU et 1Gi de mémoire (limites : 2 CPU et 4Gi de mémoire). Vérifiez que votre pool de nœuds dispose d’une marge de capacité suffisante avant d’activer le sous-chart.

Activez le sous-chart

Activez le sous-chart mcp-server afin que l’opérateur déploie un serveur MCP dans le cluster et ajoute une route /mcp à votre ingress W&B existant. Ajoutez les éléments suivants au bloc spec.values de votre ressource personnalisée WeightsAndBiases (CR) existante, aux côtés de vos valeurs global, ingress et autres redéfinitions existantes. Le bloc Datadog est facultatif, mais recommandé si un DaemonSet Datadog Agent collecte déjà les journaux et les traces des pods dans votre cluster.

spec:
  values:
    weave-trace:
      install: true

    mcp-server:
      install: true
      image:
        repository: us-docker.pkg.dev/wandb-production/public/wandb/mcp-server
        tag: "0.3.3"
      datadog:
        enabled: true
        mode: "agent"
        service: "wandb-mcp-server-<environment>"
        env: "<environment>"
        deploymentType: "self-managed"
        customer: "<customer-name>"
        extraTags:
          - "region:<region>"
          - "tier:<tier>"
      privacy:
        logLevel: "standard"

Configurez chaque bloc :

weave-trace.install: true : requis, sauf si vous définissez vous-même mcp-server.env.WF_TRACE_SERVER_URL.
datadog.mode: "agent" : à utiliser pour les déploiements Kubernetes où le DaemonSet Datadog Agent prend en charge la collecte des journaux et des traces. En mode agent, le pod MCP n’a pas besoin de clé API Datadog.
datadog.service, env, deploymentType, customer, extraTags : définissez ces valeurs pour qu’elles correspondent aux conventions de nommage d’observabilité de votre déploiement. Définissez customer sur une chaîne vide si vous ne souhaitez pas de tag client.
privacy.logLevel : utilisez "standard" pour la plupart des installations Kubernetes autogérées. Cela masque les valeurs de paramètres en texte libre dans les journaux tout en conservant les identifiants de déploiement que les opérateurs utilisent couramment pour le débogage. Utilisez "strict" lorsque les identifiants d’entité, de projet, de run ou d’utilisateur ne doivent pas rester en clair dans les journaux. Utilisez "off" uniquement si vous souhaitez explicitement une journalisation en clair pour ces valeurs.

Appliquez la modification pour déclencher la réconciliation :

kubectl apply -f operator.yaml

L’opérateur crée un déploiement wandb-mcp-server et un service dans l’espace de noms de la version, et ajoute le chemin /mcp à l’ingress W&B.

Vérifier le serveur MCP

Attendez que le pod passe à l’état Running, puis vérifiez le point de terminaison d’état de santé au sein du cluster et via l’ingress :

kubectl get pod -l app.kubernetes.io/component=mcp-server
kubectl port-forward svc/wandb-mcp-server 8080:8080
curl -s http://localhost:8080/mcp/health

curl -s "https://<HOST_URI>/mcp/health"

Les deux requêtes doivent renvoyer 200 OK. La vérification depuis le cluster confirme que le pod est sain. La vérification de l’ingress confirme que le routage fonctionne. Si la vérification depuis le cluster renvoie 200 OK mais que la vérification de l’ingress renvoie 404 Not Found, voir Troubleshooting. Si vous avez activé Datadog, les journaux du serveur MCP doivent également apparaître dans Datadog avec les valeurs configurées de mcp-server.datadog.service et mcp-server.datadog.env.

Connecter un client

Une fois le serveur MCP opérationnel, configurez votre client MCP pour utiliser https://<HOST_URI>/mcp avec une clé API W&B comme jeton Bearer. Pour la configuration des IDE et des agents, voir Utiliser le serveur MCP de W&B.

Dépannage

Symptôme	Cause et correctif
`helm render` échoue avec `mcp-server requires weave-trace.install=true`	Ajoutez `weave-trace.install: true` à `spec.values`. Le serveur MCP dépend de Weave Traces pour les outils de trace.
Le pod `wandb-mcp-server` reste bloqué à l’état `Pending` avec `Insufficient cpu` ou `Insufficient memory`	Ajoutez de la capacité aux nœuds, ou réduisez `mcp-server.resources.requests` dans votre CR. Les valeurs par défaut sont `500m` de CPU et `1Gi` de mémoire.
`curl https://<HOST_URI>/mcp/health` renvoie 404	Le chart ne génère le chemin d’ingress `/mcp` que lorsque `mcp-server.install: true`. Réappliquez le CR et attendez que le contrôleur d’ingress propage le nouveau chemin.
Les journaux MCP n’apparaissent pas dans Datadog	Vérifiez que `mcp-server.datadog.enabled: true` et `mcp-server.datadog.mode: "agent"` sont bien définis, et que le DaemonSet Datadog Agent collecte la sortie stdout du pod. Effectuez une recherche dans Datadog avec les valeurs `service` et `env` configurées.
Les journaux MCP incluent plus de texte fourni par les utilisateurs que prévu	Définissez `mcp-server.privacy.logLevel` sur `"standard"` ou `"strict"`. Utilisez `"strict"` lorsque des identifiants tels que des noms d’entité, de projet, de run ou d’utilisateur ne doivent pas rester dans les journaux en texte brut.
Le pod `wandb-mcp-server` est en `ImagePullBackOff` dans un cluster isolé du réseau ou en miroir	Mettez l’image en miroir dans votre registry et redéfinissez `mcp-server.image.repository` dans votre CR, selon le même principe que pour les autres images de composants W&B dans les installations isolées du réseau. Voir Déployer sur Kubernetes isolé du réseau.

Considérations spécifiques à l’environnement

Kubernetes fonctionne de la même manière, qu’il soit exécuté sur site ou dans le cloud. Les principales différences concernent les conventions de nommage et les services gérés (par exemple, MySQL par rapport à RDS, ou S3 par rapport au stockage d’objets sur site). Cette section aborde les considérations qui varient selon l’environnement.

sur site et bare metal

Lors d’un déploiement sur un cluster Kubernetes sur site ou bare metal, tenez compte des points suivants.

Configuration de l’équilibreur de charge

Les clusters Kubernetes sur site nécessitent généralement une configuration manuelle de l’équilibreur de charge. Les options possibles sont les suivantes :

Équilibreur de charge externe : configurez un équilibreur de charge matériel ou logiciel existant, tel que F5 ou HAProxy.
Nginx Ingress Controller : déployez nginx-ingress-controller avec NodePort ou le réseau hôte.
MetalLB : pour les clusters Kubernetes bare metal, MetalLB fournit des services d’équilibreur de charge.

Pour des exemples détaillés de configuration de l’équilibreur de charge, voir la section réseau de l’architecture de référence.

Stockage persistant

Assurez-vous que votre cluster Kubernetes dispose d’une StorageClass configurée pour les volumes persistants. Les composants W&B peuvent nécessiter un stockage persistant pour la mise en cache et les données temporaires. Les options courantes de stockage sur site incluent :

Classes de stockage basées sur NFS
Stockage Ceph/Rook
Volumes persistants locaux
Solutions de stockage d’entreprise telles que NetApp ou Pure Storage

Gestion du DNS et des certificats

Pour les déploiements sur site, effectuez les tâches suivantes :

Configurez les enregistrements DNS internes pour qu’ils pointent vers votre nom d’hôte W&B.
Générez des certificats SSL/TLS auprès de votre autorité de certification (CA) interne.
Si vous utilisez des certificats auto-signés, configurez l’opérateur pour qu’il fasse confiance à votre certificat d’autorité de certification (CA).

Voir les exigences SSL/TLS pour plus de détails sur la configuration des certificats.

Déploiements OpenShift

W&B prend entièrement en charge les déploiements sur des clusters Kubernetes OpenShift. Les déploiements OpenShift nécessitent des configurations supplémentaires du contexte de sécurité en raison des politiques de sécurité plus strictes d’OpenShift. Pour en savoir plus sur la configuration spécifique à OpenShift, voir clusters Kubernetes OpenShift. Pour des exemples de déploiement OpenShift dans des environnements isolés du réseau, voir Déployer sur Kubernetes isolé du réseau.

Stockage d’objets pour les environnements sur site et compatibles S3

Une fois votre bucket de stockage d’objets provisionné (voir Provisionnement du stockage d’objets), configurez-le dans votre Ressource personnalisée W&B. AWS S3 (sur site) Pour AWS S3 sur site (via Outposts ou un stockage compatible) :

bucket:
  kmsKey: <kms key arn>  # Clé KMS facultative pour le chiffrement
  name: <bucket name>    # Exemple : wandb
  path: ""               # Laisser comme chaîne vide
  provider: s3
  region: <region>       # Exemple : us-east-1

Stockage compatible avec S3 comme MinIO, Ceph ou NetApp Pour les systèmes de stockage compatibles avec S3 :

bucket:
  kmsKey: null
  name: <s3 endpoint>    # Exemple : s3.example.com:9000
  path: <bucket name>    # Exemple : wandb
  provider: s3
  region: <region>       # Exemple : us-east-1

Pour activer TLS pour le stockage compatible avec S3, ajoutez ?tls=true au chemin du bucket :

bucket:
  path: "wandb?tls=true"

Le certificat doit être approuvé. Les certificats autosignés nécessitent une configuration supplémentaire. Voir les exigences SSL/TLS pour en savoir plus.

Considérations importantes pour le stockage d’objets sur site Si vous exploitez votre propre stockage d’objets, tenez compte des points suivants :

Capacité de stockage et performances : Surveillez attentivement la capacité du disque. Une utilisation moyenne de W&B représente de quelques dizaines à quelques centaines de gigaoctets. Une utilisation intensive peut entraîner des pétaoctets de consommation de stockage.
Tolérance aux pannes : Au minimum, utilisez des baies RAID pour les disques physiques. Pour le stockage compatible S3, utilisez des configurations distribuées ou hautement disponibles.
Disponibilité : Mettez en place une supervision afin de garantir que le stockage reste disponible.

Considérations relatives à MinIO

MinIO Open Source est en mode maintenance et ne fait plus l’objet de développement actif. Les binaires précompilés ne sont plus fournis et seuls les correctifs de sécurité critiques sont examinés au cas par cas. Pour les déploiements de production, W&B recommande d’utiliser des services gérés de stockage d’objets ou MinIO Enterprise (AIStor).

Les alternatives Enterprise au stockage d’objets sur site incluent :

Si vous utilisez un déploiement MinIO existant ou MinIO Enterprise, vous pouvez créer un bucket à l’aide du client MinIO :

mc config host add local http://$MINIO_HOST:$MINIO_PORT "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY" --api s3v4
mc mb --region=us-east-1 local/wandb-files

Sur cloud public avec Terraform

Pour un déploiement complet de l’infrastructure et de l’application sur AWS, Google Cloud ou Azure, voir Déployer avec Terraform sur un cloud public.

Déployer avec Terraform sur un cloud public

W&B recommande des options de déploiement entièrement gérées, comme W&B Multi-tenant Cloud ou W&B Dedicated Cloud. Les services entièrement gérés nécessitent peu ou pas de configuration.

W&B fournit des modules Terraform pour déployer la plateforme chez des fournisseurs de cloud public. Ces modules automatisent le provisionnement de l’infrastructure et l’installation de W&B Server, afin que vous puissiez mettre en place un environnement complet sans créer manuellement chaque ressource cloud. Avant de commencer, W&B recommande de choisir l’un des backends distants disponibles pour Terraform afin d’y stocker le fichier d’état. Le fichier d’état est indispensable pour appliquer des mises à niveau ou apporter des modifications à votre déploiement sans recréer tous les composants. Sélectionnez votre fournisseur de cloud :

AWS
Google Cloud
Azure

W&B recommande d’utiliser le W&B Server AWS Terraform Module pour déployer la plateforme sur AWS.Le module Terraform déploie les composants obligatoires suivants :

Équilibreur de charge
AWS Identity & Access Management (IAM)
AWS Key Management System (KMS)
Amazon Aurora MySQL
Amazon VPC
Amazon S3
Amazon Route53
Amazon Certificate Manager (ACM)
Amazon Elastic Load Balancing (ALB)
Amazon Secrets Manager

Les composants facultatifs incluent :

ElastiCache pour Redis
SQS

Autorisations préalables

Le compte qui exécute Terraform doit pouvoir créer tous les composants répertoriés dans la section précédente et disposer des autorisations nécessaires pour créer des IAM Policies et des IAM Roles, ainsi qu’attribuer des rôles aux ressources.

Étapes générales

Les étapes de cette section sont communes à toutes les options de déploiement.

Préparez l’environnement de développement.
- Installez Terraform
- W&B recommande de créer un dépôt Git pour le suivi des versions.
Créez le fichier terraform.tfvars. Personnalisez le contenu du fichier tvfars selon le type d’installation. Le contenu minimum recommandé est illustré dans l’exemple suivant.
namespace = "wandb" license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz" subdomain = "wandb-aws" domain_name = "wandb.ml" zone_id = "xxxxxxxxxxxxxxxx" allowed_inbound_cidr = ["0.0.0.0/0"] allowed_inbound_ipv6_cidr = ["::/0"] eks_cluster_version = "1.29"
Veillez à définir les variables dans votre fichier tvfars avant de déployer, car la variable namespace est une chaîne de caractères utilisée comme préfixe pour toutes les ressources créées par Terraform. La combinaison de subdomain et domain forme le FQDN de votre instance W&B. Dans l’exemple précédent, le FQDN W&B est wandb-aws.wandb.ml, et le zone_id DNS est l’endroit où Terraform crée l’enregistrement FQDN. Les paramètres allowed_inbound_cidr et allowed_inbound_ipv6_cidr doivent également être définis. Dans le module, il s’agit d’une entrée obligatoire. L’exemple suivant autorise l’accès à l’installation W&B depuis n’importe quelle source.
Créez le fichier versions.tf. Ce fichier contiendra les versions requises de Terraform et du fournisseur Terraform pour déployer W&B sur AWS :
provider "aws" { region = "eu-central-1" default_tags { tags = { GithubRepo = "terraform-aws-wandb" GithubOrg = "wandb" Enviroment = "Example" Example = "PublicDnsExternal" } } }
Consultez la documentation officielle de Terraform pour configurer le fournisseur AWS. W&B recommande également d’ajouter la configuration du backend distant mentionnée au début de cette documentation.

Créez le fichier variables.tf Pour chaque option configurée dans terraform.tfvars, Terraform nécessite une déclaration de variable correspondante.

variable "namespace" {
  type        = string
  description = "Name prefix used for resources"
}

variable "domain_name" {
  type        = string
  description = "Domain name used to access instance."
}

variable "subdomain" {
  type        = string
  default     = null
  description = "Subdomain for accessing the Weights & Biases UI."
}

variable "license" {
  type = string
}

variable "zone_id" {
  type        = string
  description = "Domain for creating the Weights & Biases subdomain on."
}

variable "allowed_inbound_cidr" {
 description = "CIDRs allowed to access wandb-server."
 nullable    = false
 type        = list(string)
}

variable "allowed_inbound_ipv6_cidr" {
 description = "CIDRs allowed to access wandb-server."
 nullable    = false
 type        = list(string)
}

variable "eks_cluster_version" {
 description = "EKS cluster kubernetes version"
 nullable    = false
 type        = string
}

Déploiement recommandé

Il s’agit de la configuration de déploiement la plus simple, qui crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.

Créez le fichier main.tf Dans le même répertoire que celui où vous avez créé les fichiers dans les étapes General, créez un fichier main.tf avec le contenu suivant :

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  license     = var.license
  subdomain   = var.subdomain
  zone_id     = var.zone_id

  allowed_inbound_cidr           = var.allowed_inbound_cidr
  allowed_inbound_ipv6_cidr      = var.allowed_inbound_ipv6_cidr

  public_access                  = true
  external_dns                   = true
  kubernetes_public_access       = true
  kubernetes_public_access_cidrs = ["0.0.0.0/0"]
  eks_cluster_version            = var.eks_cluster_version
}

 data "aws_eks_cluster" "eks_cluster_id" {
   name = module.wandb_infra.cluster_name
 }

 data "aws_eks_cluster_auth" "eks_cluster_auth" {
   name = module.wandb_infra.cluster_name
 }

 provider "kubernetes" {
   host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
   cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
   token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
 }


 provider "helm" {
   kubernetes {
     host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
     cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
     token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
   }
 }

 output "url" {
   value = module.wandb_infra.url
 }

 output "bucket" {
   value = module.wandb_infra.bucket_name
 }

Déployer W&B Pour déployer W&B, exécutez les commandes suivantes :
terraform init terraform apply -var-file=terraform.tfvars

Activer Redis

Pour utiliser Redis afin de mettre en cache les requêtes SQL et accélérer la réponse de l’application lors du chargement des métriques, ajoutez l’option create_elasticache_subnet = true au fichier main.tf :

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
  create_elasticache_subnet = true
}
[...]

Activer le courtier de messages (file d’attente)

Pour activer un courtier de messages externe via SQS, ajoutez l’option use_internal_queue = false au fichier main.tf :

Ceci est facultatif, car W&B inclut un broker intégré. Cette option n’apporte aucune amélioration des performances.

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
  use_internal_queue = false

[...]
}

Ressources supplémentaires

W&B recommande d’utiliser le W&B Server Google Cloud Terraform Module pour déployer la plateforme sur Google Cloud.La documentation du module répertorie toutes les options disponibles.Avant de commencer, W&B vous recommande de choisir l’un des backends distants disponibles pour Terraform afin de stocker le fichier d’état. Le fichier d’état est la ressource indispensable pour déployer des mises à jour ou effectuer des modifications dans votre déploiement sans recréer tous les composants.Le module Terraform déploie les composants obligatoires suivants :

VPC
Cloud SQL for MySQL
Bucket de stockage dans le cloud
Google Kubernetes Engine
Memorystore for Redis
Clé cryptographique KMS
Équilibreur de charge

Les composants facultatifs incluent :

Système de messagerie Pub/Sub

Autorisations préalables

Le compte qui exécute Terraform doit disposer du rôle roles/owner dans le projet Google Cloud utilisé.

Étapes générales

Les étapes de cette section sont communes à toutes les options de déploiement.

Préparez l’environnement de développement.
- Installez Terraform.
- W&B recommande de créer un dépôt Git pour votre code, mais vous pouvez conserver vos fichiers en local.
- Créez un projet dans Google Cloud Console.
- Authentifiez-vous avec Google Cloud (veillez à installer gcloud au préalable) à l’aide de gcloud auth application-default login.
Créez le fichier terraform.tfvars. Personnalisez le contenu du fichier tvfars en fonction du type d’installation. Le contenu minimum recommandé est illustré par l’exemple suivant.
project_id = "wandb-project" region = "europe-west2" zone = "europe-west2-a" namespace = "wandb" license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz" subdomain = "wandb-gcp" domain_name = "wandb.ml"
Vous devez définir les valeurs de ces variables avant le déploiement. La variable namespace est une chaîne de caractères qui sert de préfixe à toutes les ressources créées par Terraform. La combinaison de subdomain et de domain forme le FQDN utilisé pour configurer W&B. Dans l’exemple précédent, le FQDN de W&B est wandb-gcp.wandb.ml.

Créez le fichier variables.tf. Pour chaque option configurée dans terraform.tfvars, Terraform nécessite une déclaration de variable correspondante.

variable "project_id" {
  type        = string
  description = "Project ID"
}

variable "region" {
  type        = string
  description = "Google region"
}

variable "zone" {
  type        = string
  description = "Google zone"
}

variable "namespace" {
  type        = string
  description = "Namespace prefix used for resources"
}

variable "domain_name" {
  type        = string
  description = "Domain name for accessing the Weights & Biases UI."
}

variable "subdomain" {
  type        = string
  description = "Subdomain for access the Weights & Biases UI."
}

variable "license" {
  type        = string
  description = "W&B License"
}

Déploiement recommandé

Il s’agit de la configuration de déploiement la plus simple, qui crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.

Créez le fichier main.tf Dans le même répertoire que celui où vous avez créé les fichiers dans les étapes General, créez un fichier main.tf avec le contenu suivant :

provider "google" {
 project = var.project_id
 region  = var.region
 zone    = var.zone
}

provider "google-beta" {
 project = var.project_id
 region  = var.region
 zone    = var.zone
}

data "google_client_config" "current" {}

provider "kubernetes" {
  host                   = "https://${module.wandb.cluster_endpoint}"
  cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
  token                  = data.google_client_config.current.access_token
}

provider "helm" {
  kubernetes {
    host                   = "https://${module.wandb.cluster_endpoint}"
    cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
    token                  = data.google_client_config.current.access_token
  }
}

# Lancer tous les services requis
module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 10.0"

  namespace   = var.namespace
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain
}

# Mettez à jour votre DNS avec l'adresse IP provisionnée
output "url" {
  value = module.wandb.url
}

output "address" {
  value = module.wandb.address
}

output "bucket_name" {
  value = module.wandb.bucket_name
}

Déployez W&B. Pour déployer W&B, exécutez les commandes suivantes :
terraform init terraform apply -var-file=terraform.tfvars

Activer Redis

Pour utiliser Redis afin de mettre en cache les requêtes SQL et accélérer la réponse de l’application lors du chargement des métriques, ajoutez l’option create_redis = true au fichier main.tf :

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 10.0"

  namespace    = var.namespace
  license      = var.license
  domain_name  = var.domain_name
  subdomain    = var.subdomain
  create_redis = true
}
[...]

Activer le courtier de messages (file d’attente)

Pour activer un courtier de messages externe via Pub/Sub, ajoutez l’option use_internal_queue = false au fichier main.tf :

Ceci est facultatif, car W&B inclut un broker intégré. Cette option n’apporte aucune amélioration des performances.

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 10.0"

  namespace          = var.namespace
  license            = var.license
  domain_name        = var.domain_name
  subdomain          = var.subdomain
  use_internal_queue = false
}

[...]

Ressources supplémentaires

W&B recommande d’utiliser le W&B Server Azure Terraform Module pour déployer la plateforme sur Azure.La documentation du module répertorie toutes les options disponibles.Le module Terraform déploie les composants obligatoires suivants :

Groupe de ressources Azure
Azure Virtual Network (VPC)
Azure MySQL Flexible Server
Compte de stockage Azure et Blob Storage
Azure Kubernetes Service
Azure Application Gateway

Les composants facultatifs incluent :

Azure Cache for Redis
Azure Event Grid

Autorisations préalables

La façon la plus simple de configurer le fournisseur AzureRM est via Azure CLI. Pour l’automatisation, vous pouvez également utiliser un Azure Service Principal.Quelle que soit la méthode d’authentification utilisée, le compte qui exécute Terraform doit pouvoir créer tous les composants répertoriés dans la section précédente.

Étapes générales

Les étapes de cette section sont communes à toutes les options de déploiement.

Préparez l’environnement de développement.
- Installez Terraform
- W&B recommande de créer un dépôt Git pour votre code, mais vous pouvez conserver vos fichiers en local.
Créez le fichier terraform.tfvars. Personnalisez le contenu du fichier tvfars selon le type d’installation. Le contenu minimum recommandé est le suivant :
namespace = "wandb" wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz" subdomain = "wandb-azure" domain_name = "wandb.ml" location = "westeurope"
Vous devez choisir les valeurs de ces variables avant le déploiement. La variable namespace est une chaîne de caractères qui sert de préfixe à toutes les ressources créées par Terraform. La combinaison de subdomain et de domain forme le FQDN qui configure W&B. Dans l’exemple précédent, le FQDN de W&B est wandb-azure.wandb.ml.
Créez le fichier versions.tf. Ce fichier contient les versions de Terraform et du fournisseur Terraform requises pour déployer W&B sur Azure :
terraform { required_version = "~> 1.3" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.17" } } }
Consultez la documentation officielle de Terraform pour configurer le fournisseur Azure. W&B recommande également d’ajouter la configuration du backend distant mentionnée au début de cette documentation.

Créez le fichier variables.tf Pour chaque option configurée dans terraform.tfvars, Terraform nécessite une déclaration de variable correspondante.

    variable "namespace" {
      type        = string
      description = "String used for prefix resources."
    }

    variable "location" {
      type        = string
      description = "Azure Resource Group location"
    }

    variable "domain_name" {
      type        = string
      description = "Domain for accessing the Weights & Biases UI."
    }

    variable "subdomain" {
      type        = string
      default     = null
      description = "Subdomain for accessing the Weights & Biases UI. Default creates record at Route53 Route."
    }

    variable "license" {
      type        = string
      description = "Your wandb/local license"
    }

Déploiement recommandé

Il s’agit de la configuration de déploiement la plus simple, qui crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.

Créez le fichier main.tf Dans le même répertoire que celui où vous avez créé les fichiers dans les étapes General, créez un fichier main.tf avec le contenu suivant :

  provider "azurerm" {
 features {}
  }

  provider "kubernetes" {
 host                   = module.wandb.cluster_host
 cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
 client_key             = base64decode(module.wandb.cluster_client_key)
 client_certificate     = base64decode(module.wandb.cluster_client_certificate)
  }

  provider "helm" {
 kubernetes {
   host                   = module.wandb.cluster_host
   cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
   client_key             = base64decode(module.wandb.cluster_client_key)
   client_certificate     = base64decode(module.wandb.cluster_client_certificate)
 }
  }

  # Lancer tous les services requis
  module "wandb" {
 source  = "wandb/wandb/azurerm"
 version = "~> 1.2"

 namespace   = var.namespace
 location    = var.location
 license     = var.license
 domain_name = var.domain_name
 subdomain   = var.subdomain

 deletion_protection = false

 tags = {
   "Example" : "PublicDns"
 }
  }

  output "address" {
 value = module.wandb.address
  }

  output "url" {
 value = module.wandb.url
  }

Déployer W&B Pour déployer W&B, exécutez les commandes suivantes :
terraform init terraform apply -var-file=terraform.tfvars

Activer Redis

# Lancer tous les services requis
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"

  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  create_redis = true
  [...]
}

Activer le courtier de messages (file d’attente)

Pour activer un courtier de messages externe à l’aide d’Azure Event Grid, ajoutez l’option use_internal_queue = false au fichier main.tf :

Ceci est facultatif, car W&B inclut un broker intégré. Cette option n’apporte aucune amélioration des performances.

# Lancer tous les services requis
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"

  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  use_internal_queue = false
  [...]
}

Ressources supplémentaires

Autres options de déploiement

Vous pouvez combiner plusieurs options de déploiement en ajoutant toutes les configurations dans le même fichier. Chaque module Terraform propose plusieurs options, que vous pouvez combiner avec les options standard et la configuration minimale décrite dans la section sur le déploiement recommandé. Consultez la documentation du module correspondant à votre cloud provider pour obtenir la liste complète des options disponibles :

Accéder à la console de gestion W&B

L’opérateur Kubernetes W&B inclut une console de gestion dans laquelle vous pouvez vérifier le statut du déploiement, consulter les métriques des composants et ajuster les paramètres au niveau de l’opérateur. Elle se trouve à l’adresse ${HOST_URI}/console, par exemple https://wandb.company-name.com/console. Vous pouvez vous connecter à la console de gestion de deux façons :

Option 1 (Recommandée)
Option 2

Ouvrez l’application W&B dans votre navigateur et connectez-vous. Connectez-vous à l’application W&B à l’adresse ${HOST_URI}/, par exemple https://wandb.company-name.com/
Accédez à la console. Cliquez sur l’icône dans le coin supérieur droit, puis sur Console système. Seuls les utilisateurs disposant des privilèges d’administrateur peuvent voir l’entrée Console système.

W&B recommande de suivre les étapes ci-dessous pour accéder à la console uniquement si l’option 1 ne fonctionne pas.

Ouvrez l’application de console dans votre navigateur. Ouvrez l’URL décrite dans la section précédente, qui vous redirige vers l’écran de connexion :
Récupérez le mot de passe depuis le secret Kubernetes généré par l’installation :
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
Copiez le mot de passe.
Connectez-vous à la console. Collez le mot de passe copié, puis cliquez sur Login.

Mettre à jour l’opérateur Kubernetes W&B

Cette section explique comment mettre à jour l’opérateur Kubernetes W&B lui-même. Mettez régulièrement à jour l’opérateur afin de bénéficier de correctifs et de nouvelles fonctionnalités de réconciliation.

La mise à jour de l’opérateur Kubernetes W&B ne met pas à jour l’application serveur W&B.
Si vous utilisez un chart Helm qui n’utilise pas l’opérateur Kubernetes W&B, consultez les instructions de migration avant de suivre les étapes de cette section pour mettre à jour le W&B Operator.

Copiez-collez les extraits de code suivants dans votre terminal.

Mettez à jour le dépôt avec helm repo update :
helm repo update

Mettez à jour le chart Helm avec helm upgrade :

helm upgrade operator wandb/operator -n wandb-cr --reuse-values

Mettre à jour l’application W&B Server

Vous n’avez plus besoin de mettre à jour l’application W&B Server si vous utilisez l’opérateur Kubernetes W&B. L’opérateur met automatiquement à jour votre application W&B Server lorsqu’une nouvelle version du logiciel W&B est publiée.

Mettre à niveau MySQL vers 8.4.x

MySQL 8.0.x est en fin de vie. Les déploiements autogérés doivent exécuter une version prise en charge de MySQL qui reçoit des correctifs de sécurité et des corrections de bugs critiques. Si vous exécutez MySQL Community, installez ou mettez à niveau MySQL 8.4.x. Si vous utilisez un service géré, exécutez une version du moteur que votre fournisseur indique comme prise en charge et corrigée (par exemple Amazon RDS for MySQL, Google Cloud SQL for MySQL ou Azure Database for MySQL). W&B a validé la plateforme avec MySQL 8.4.0 et les versions 8.4.x actuelles. Ces étapes décrivent la séquence du point de vue de W&B. Pour savoir comment mettre à niveau MySQL lui-même, y compris les sauvegardes et les chemins de mise à niveau entre versions, suivez la documentation de votre distribution MySQL ou de votre fournisseur de cloud. La même séquence s’applique aux déploiements Operator standard et isolés du réseau. Dans les environnements isolés du réseau, obtenez le logiciel MySQL 8.4.x via votre processus de distribution interne avant de mettre à niveau la base de données.

Prévoyez une fenêtre de maintenance et notifiez les utilisateurs avant de commencer. Contactez l’assistance client ou votre équipe W&B si vous avez des questions sur la compatibilité ou la topologie de votre déploiement.

Consultez les notes de version et la documentation MySQL pour votre version cible, ainsi que pour toutes les versions intermédiaires, afin de connaître les exigences et autres détails.
Préparez la maintenance. Avant de commencer la mise à niveau, vous pouvez exécuter le vérificateur de mise à niveau MySQL Shell sur votre base de données pour détecter et corriger les problèmes de compatibilité avec votre version cible. Résolvez toutes les erreurs et tous les avertissements signalés dans la sortie du vérificateur avant de continuer. Consultez la documentation de votre distribution MySQL.
Arrêtez MySQL et effectuez une sauvegarde complète de votre base de données MySQL conformément à la documentation de votre distribution MySQL. MySQL sera indisponible pendant la mise à niveau. Tant que la base de données est indisponible, les applications clientes W&B ne peuvent pas se connecter et rencontreront des erreurs temporaires.
Mettez à niveau MySQL vers 8.4.x conformément à la documentation de votre distribution MySQL.
Redémarrez MySQL et vérifiez qu’il est opérationnel.
Une fois MySQL opérationnel, exécutez wandb verify pour valider votre déploiement W&B. La commande exécute une série de vérifications et affiche les résultats dans STDOUT. Si elle signale des problèmes, effectuez les ajustements nécessaires et exécutez-la de nouveau. Pour les étapes de configuration et de connexion, voir Vérifiez l’installation.
Une fois la validation terminée, les utilisateurs peuvent reprendre les opérations normales.

Compatibilité de ClickHouse pour les mises à niveau

Les déploiements autogérés qui utilisent un cluster ClickHouse externe doivent vérifier la compatibilité de ClickHouse avant de mettre à niveau le serveur W&B.

Versions de ClickHouse non prises en charge

Les déploiements W&B Autogéré qui utilisent les fonctionnalités OLAP de W&B Weave ou de Models nécessitent une version prise en charge de ClickHouse Server et de ClickHouse Keeper.

Weave ne fonctionne pas avec ClickHouse 26.1 ni 26.2.
Les fonctionnalités OLAP de Models décrites dans la section suivante nécessitent ClickHouse 26.2 ou version ultérieure.
Les déploiements qui utilisent à la fois les fonctionnalités OLAP de Weave et de Models nécessitent ClickHouse 26.3.

Si votre déploiement W&B Autogéré n’utilise ni Weave ni les fonctionnalités OLAP de Models, ClickHouse n’est pas requis.

Fonctionnalités OLAP de Models

serveur W&B 0.81.0+ introduit des migrations de schéma qui nécessitent ClickHouse 26.2+. Ces migrations s’exécutent lorsque l’une des fonctionnalités OLAP de Models ci-dessous est activée dans vos valeurs Helm :

global:
  olap:
    registrySearch:
      enabled: true
    runStoreAccelerator:
      enabled: true
    history:
      enabled: true

Avant la mise à niveau de W&B Autogéré vers Server v0.81+, vous devez soit :

définir ces valeurs sur false dans vos valeurs Helm, soit :
mettre à niveau ClickHouse Server et ClickHouse Keeper vers la version 26.2 ou ultérieure (26.3 ou ultérieure si votre déploiement utilise également Weave).

Si ces fonctionnalités sont désactivées ou si vous n’utilisez pas ClickHouse pour les charges de travail OLAP de Models, cette exigence ne s’applique pas à votre mise à niveau. Les déploiements Cloud dédié et Cloud mutualisé exécutent déjà une version compatible de ClickHouse et ne sont pas concernés. Pour les notes de version propres à chaque version, voir Versions du serveur W&B prises en charge.

Migrer des instances Autogéré vers W&B Operator

La section suivante explique comment passer d’une gestion autonome de votre propre installation serveur W&B à l’utilisation de W&B Operator pour la gérer à votre place. La migration permet à l’opérateur de gérer automatiquement la réconciliation et les mises à niveau de serveur W&B, de sorte que vous n’avez plus à coordonner les modifications des manifestes ou les mises à niveau Helm pour l’application. Le processus de migration dépend de la façon dont vous avez installé serveur W&B :

W&B Operator est la méthode d’installation par défaut et recommandée pour serveur W&B. Contactez assistance client ou votre équipe W&B si vous avez des questions.

Si vous avez utilisé les modules Terraform officiels de W&B Cloud, accédez à la documentation appropriée et suivez les étapes indiquées :
- AWS
- Google Cloud
- Azure
Si vous avez utilisé le chart Helm W&B Non-Operator, voir Migrer vers le chart Helm basé sur l’opérateur.
Si vous avez utilisé le chart Helm W&B Non-Operator avec Terraform, voir Migrer vers le chart Helm Terraform basé sur l’opérateur.
Si vous avez créé les ressources Kubernetes à l’aide de manifestes, voir Migrer vers le chart Helm basé sur l’opérateur.

Migrer vers des modules Terraform AWS basés sur l’opérateur

Pour une description détaillée du processus de migration, consultez la documentation du chart operator-wandb.

Migrer vers les modules Terraform Google Cloud basés sur l’opérateur

Contactez assistance client ou votre équipe W&B si vous avez des questions ou besoin d’assistance.

Migrer vers des modules Terraform Azure basés sur l’opérateur

Contactez assistance client ou votre équipe W&B si vous avez des questions ou besoin d’assistance.

Migrer vers le chart Helm basé sur l’opérateur

Suivez ces étapes pour migrer vers le chart Helm basé sur l’opérateur :

Obtenez la configuration W&B actuelle. Si vous avez déployé W&B avec une version du chart Helm non basée sur l’opérateur, exportez les valeurs comme ceci :
helm get values wandb
Si vous avez déployé W&B avec des manifests Kubernetes, exportez les valeurs comme ceci :
kubectl get deployment wandb -o yaml
Vous disposez maintenant de toutes les valeurs de configuration nécessaires pour l’étape suivante.
Créez un fichier nommé operator.yaml. Suivez le format décrit dans la Référence de configuration. Utilisez les valeurs de l’étape 1.
Réduisez le déploiement actuel à 0 pods. Cette étape arrête le déploiement actuel.
kubectl scale --replicas=0 deployment wandb
Mettez à jour le dépôt du chart Helm :
helm repo update

Installez le nouveau chart Helm :

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

Configurez le nouveau chart Helm et déclenchez le déploiement de l’application W&B. Appliquez la nouvelle configuration.
kubectl apply -f operator.yaml
Le déploiement prend quelques minutes.
Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de Vérifiez l’installation.
Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources que vous avez créées à l’aide de manifests.

Migrer vers le chart Helm Terraform basé sur l’opérateur

Suivez ces étapes pour migrer vers le chart Helm basé sur l’opérateur :

Préparez la configuration Terraform. Remplacez, dans votre configuration Terraform, le code Terraform de l’ancien déploiement par celui décrit dans Déployer W&B avec le module Terraform Helm. Définissez les mêmes variables qu’auparavant. Ne modifiez pas le fichier .tfvars si vous en avez un.
Exécutez les commandes Terraform. Exécutez terraform init, terraform plan et terraform apply.
Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes indiquées dans Vérifiez l’installation.
Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources que vous avez créées à l’aide de manifests.

Référence de configuration pour serveur W&B

Cette section sert de référence pour les options de configuration que vous définissez dans votre ressource personnalisée WeightsAndBiases. Utilisez-la pour consulter le schéma YAML d’un sous-système spécifique (par exemple, MySQL, Redis, ingress ou OIDC) lorsque vous créez ou mettez à jour votre fichier operator.yaml. Cette section décrit les options de configuration de l’application serveur W&B. L’application reçoit sa configuration sous la forme d’une définition de ressource personnalisée nommée WeightsAndBiases. Certaines options de configuration sont disponibles dans la configuration suivante. Vous devez définir les autres au moyen de variables d’environnement. La documentation comporte deux listes de variables d’environnement : de base et avancées. Utilisez des variables d’environnement uniquement si l’option de configuration dont vous avez besoin n’est pas exposée via le chart Helm.

Exemple de base

Cet exemple définit le jeu minimal de valeurs requis pour W&B. Pour un exemple de production plus réaliste, voir Exemple complet. Ce fichier YAML définit l’état souhaité de votre déploiement W&B, y compris la version, les variables d’environnement, les ressources externes comme les bases de données, ainsi que d’autres paramètres nécessaires.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

Consultez la liste complète des valeurs dans le dépôt Helm W&B. Modifiez uniquement les valeurs que vous devez surcharger.

Exemple complet

Cet exemple de configuration déploie W&B sur Google Cloud Anthos à l’aide de Google Cloud Storage :

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://abc-wandb.sandbox-gcp.wandb.ml
      bucket:
        name: abc-wandb-moving-pipefish
        provider: gcs
      mysql:
        database: wandb_local
        host: 10.218.0.2
        name: wandb_local
        password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
        port: 3306
        user: wandb
      redis:
        host: redis.example.com
        port: 6379
        password: password
      api:
        enabled: true
      glue:
        enabled: true
      executor:
        enabled: true
      license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
    ingress:
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
        kubernetes.io/ingress.class: gce
        kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address

Hôte

 # Fournir le FQDN avec le protocole
global:
  # exemple de nom d'hôte, remplacez par le vôtre
  host: https://wandb.example.com

Stockage d’objets (bucket)

AWS

global:
  bucket:
    provider: "s3"
    name: ""
    kmsKey: ""
    region: ""

Google Cloud

global:
  bucket:
    provider: "gcs"
    name: ""

Azure

global:
  bucket:
    provider: "az"
    name: ""
    secretKey: ""

Autres fournisseurs (Minio, Ceph et autres services de stockage compatibles S3) Pour les autres fournisseurs compatibles S3, définissez la configuration du bucket comme suit :

global:
  bucket:
    # Exemples de valeurs, remplacez-les par les vôtres
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    accessKey: 5WOA500...P5DK7I
    secretKey: HDKYe4Q...JAp1YyjysnX

Pour un stockage compatible S3 hébergé en dehors d’AWS, kmsKey doit être null. Pour faire référence à accessKey et secretKey depuis un secret :

global:
  bucket:
    # Exemples de valeurs, remplacez-les par les vôtres
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    secret:
      secretName: bucket-secret
      accessKeyName: ACCESS_KEY
      secretKeyName: SECRET_KEY

MySQL

global:
   mysql:
     # Exemples de valeurs, remplacez-les par les vôtres
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     password: 8wtX6cJH...ZcUarK4zZGjpV 

Pour référencer le password d’un secret :

global:
   mysql:
     # Exemples de valeurs, remplacez par les vôtres
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

License

global:
  # Exemple de licence, remplacez-la par la vôtre
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

Pour faire référence à la license à partir d’un secret :

global:
  licenseSecret:
    name: license-secret
    key: CUSTOMER_WANDB_LICENSE

Ingress

Voir Comment identifier la classe d’ingress Kubernetes. Sans TLS

global:
# IMPORTANT : Ingress est au même niveau dans le YAML que 'global' (pas un enfant)
ingress:
  class: ""

Avec TLS Créez un secret contenant le certificat

kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt

Indiquez le secret dans la configuration d’ingress

global:
# IMPORTANT : Ingress est au même niveau dans le YAML que 'global' (et non un enfant)
ingress:
  class: ""
  annotations:
    {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  tls: 
    - secretName: wandb-ingress-tls
      hosts:
        - <HOST_URI>

Dans le cas de Nginx, il se peut que vous deviez ajouter l’annotation suivante :

ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 0

Comptes de service Kubernetes personnalisés

Spécifiez des comptes de service Kubernetes personnalisés pour exécuter les pods W&B. L’extrait suivant crée un compte de service dans le déploiement avec le nom indiqué :

app:
  serviceAccount:
    name: custom-service-account
    create: true

parquet:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

Les sous-systèmes “app” et “parquet” s’exécutent avec le compte de service spécifié. Les autres sous-systèmes s’exécutent avec le compte de service par défaut. Si le compte de service existe déjà sur le cluster, définissez create: false :

app:
  serviceAccount:
    name: custom-service-account
    create: false

parquet:
  serviceAccount:
    name: custom-service-account
    create: false
    
global:
  ...

Vous pouvez spécifier des comptes de service pour différents sous-systèmes, tels que app, parquet, console et autres :

app:
  serviceAccount:
    name: custom-service-account
    create: true

console:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

Les comptes de service peuvent varier d’un sous-système à l’autre :

app:
  serviceAccount:
    name: custom-service-account
    create: false

console:
  serviceAccount:
    name: another-custom-service-account
    create: true

global:
  ...

Redis externe

redis:
  install: false

global:
  redis:
    host: ""
    port: 6379
    password: ""
    parameters: {}
    caCert: ""

Pour référencer le password à partir d’un secret :

kubectl create secret generic redis-secret --from-literal=redis-password=supersecret

Faites-y référence dans la configuration suivante :

redis:
  install: false

global:
  redis:
    host: redis.example
    port: 9001
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password

LDAP

La prise en charge de la configuration LDAP dans le chart Helm actuel est limitée. Contactez l’équipe d’assistance de W&B ou votre AISE pour vous aider à configurer LDAP.

Configurez LDAP en définissant des variables d’environnement dans global.extraEnv :

global:
  extraEnv:
    LDAP_ADDRESS: ldaps://ldap.company.example.com
    LDAP_BASE_DN: cn=accounts,dc=company,dc=example,dc=com
    LDAP_USER_BASE_DN: cn=users,cn=accounts,dc=company,dc=example,dc=com
    LDAP_GROUP_BASE_DN: cn=groups,cn=accounts,dc=company,dc=example,dc=com
    LDAP_BIND_DN: uid=ldapbind,cn=sysaccounts,cn=etc,dc=company,dc=example,dc=com
    LDAP_BIND_PW: ********************
    LDAP_ATTRIBUTES: email=mail,name=cn
    LDAP_TLS_ENABLE: "true"
    LDAP_LOGIN: "true"
    LDAP_USER_OBJECT_CLASS: user
    LDAP_GROUP_OBJECT_CLASS: group

OIDC SSO

global: 
  auth:
    sessionLengthHours: 720
    oidc:
      clientId: ""
      secret: ""
      # À inclure uniquement si votre IdP l'exige.
      authMethod: ""
      issuer: ""

authMethod est facultatif.

SMTP

global:
  email:
    smtp:
      host: ""
      port: 587
      user: ""
      password: ""

Variables d’environnement

global:
  extraEnv:
    GLOBAL_ENV: "example"

Définir les limites de débit

Pour les déploiements en Cloud dédié et Autogéré qui utilisent l’opérateur, vous pouvez aussi configurer des limites de débit en définissant des variables d’environnement dans spec.values.global.extraEnv. À titre indicatif, cet exemple définit explicitement chaque limite de débit sur sa valeur par défaut. En pratique, définissez une limite de débit uniquement pour redéfinir la valeur par défaut.

spec:
  values:
    global:
      extraEnv:
        GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM: "5"
        GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_COUNT: "5"
        GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_PER_RUN_COUNT: "0.8"
        GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_SIZE: "10"
        GORILLA_DEFAULT_RATE_LIMITS_RUN_UPDATE_COUNT: "10"
        GORILLA_LIMITER: "redis://$HOST:6379?ttlInSeconds=900"

Se référer au tableau suivant pour plus de détails :

Environment variable	Default	Description
`GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM`	`5`	Nombre par défaut de requêtes filestream.
`GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_COUNT`	`5`	Requêtes filestream par seconde.
`GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_PER_RUN_COUNT`	`0.8`	Requêtes filestream par run et par seconde.
`GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_SIZE`	`10`	Limite d’ingestion filestream en Mo par seconde.
`GORILLA_DEFAULT_RATE_LIMITS_RUN_UPDATE_COUNT`	`10`	Requêtes de mise à jour des métadonnées de run par seconde.

Autorité de certification personnalisée

customCACerts est une liste qui peut contenir plusieurs certificats. Les autorités de certification spécifiées dans customCACerts s’appliquent uniquement à l’application W&B Server.

global:
  customCACerts:
  - |
    -----BEGIN CERTIFICATE-----
    MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
    SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
    P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
    -----END CERTIFICATE-----
  - |
    -----BEGIN CERTIFICATE-----
    MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
    SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
    aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
    -----END CERTIFICATE-----

Les certificats CA peuvent également être stockés dans une ConfigMap :

global:
  caCertsConfigMap: custom-ca-certs

Le ConfigMap doit se présenter comme suit :

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Si vous utilisez une ConfigMap, chaque clé de la ConfigMap doit se terminer par .crt (par exemple, my-cert.crt ou ca-cert1.crt). Cette convention de nommage est requise pour que update-ca-certificates puisse traiter et ajouter chaque certificat au magasin système des autorités de certification.

Contexte de sécurité personnalisé

Chaque composant W&B prend en charge des configurations de contexte de sécurité personnalisées sous la forme suivante :

pod:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    runAsGroup: 0
    fsGroup: 1001
    fsGroupChangePolicy: Always
    seccompProfile:
      type: RuntimeDefault
container:
  securityContext:
    capabilities:
      drop:
        - ALL
    readOnlyRootFilesystem: false
    allowPrivilegeEscalation: false 

La seule valeur valide pour runAsGroup: est 0. Toute autre valeur constitue une erreur.

Par exemple, pour configurer le pod de l’application, ajoutez une section app à votre configuration :

global:
  ...
app:
  pod:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001
      runAsGroup: 0
      fsGroup: 1001
      fsGroupChangePolicy: Always
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: false
      allowPrivilegeEscalation: false 

Le même concept s’applique à console, weave, weave-trace et parquet.

Référence de configuration pour l’opérateur W&B

Cette section décrit les options de configuration de l’opérateur Kubernetes W&B (wandb-controller-manager). L’opérateur reçoit sa configuration sous la forme d’un fichier YAML. Par défaut, l’opérateur Kubernetes W&B n’a pas besoin de fichier de configuration. Créez un fichier de configuration si nécessaire. Par exemple, vous pouvez en avoir besoin pour spécifier des autorités de certification personnalisées, déployer dans un environnement isolé (air gap), etc. Consultez la liste complète des personnalisations de la spécification dans le dépôt Helm.

CA personnalisée

Une autorité de certification personnalisée (customCACerts) correspond à une liste pouvant contenir plusieurs certificats. Une fois ajoutées, ces autorités de certification s’appliquent uniquement à l’opérateur Kubernetes W&B (wandb-controller-manager).

customCACerts:
- |
  -----BEGIN CERTIFICATE-----
  MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
  SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
  P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
  -----END CERTIFICATE-----
- |
  -----BEGIN CERTIFICATE-----
  MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
  SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
  aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
  -----END CERTIFICATE-----

Les certificats CA peuvent également être stockés dans une ConfigMap :

caCertsConfigMap: custom-ca-certs

Le ConfigMap doit se présenter ainsi :

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Chaque clé du ConfigMap doit se terminer par .crt (par exemple, my-cert.crt ou ca-cert1.crt). Cette convention de nommage est nécessaire pour que update-ca-certificates puisse interpréter et ajouter chaque certificat au magasin système d’autorités de certification.

FAQ

Objectif et rôle de chaque pod

Un déploiement du serveur W&B inclut les pods suivants :

wandb-app: le cœur de W&B, y compris l’API GraphQL et l’application frontend. Il assure la majeure partie des fonctionnalités de la plateforme W&B.
wandb-console: la console d’administration, accessible via /console.
wandb-otel: l’agent OpenTelemetry, qui collecte les métriques et les journaux des ressources au niveau de Kubernetes pour les afficher dans la console d’administration.
wandb-prometheus: le serveur Prometheus, qui capture les métriques de différents composants pour les afficher dans la console d’administration.
wandb-parquet: un microservice backend distinct du pod wandb-app qui exporte les données de la base de données vers le stockage d’objets au format Parquet.
wandb-weave: un autre microservice backend qui charge les tables de requête dans l’UI et prend en charge diverses fonctionnalités essentielles de l’application.
wandb-weave-trace: un framework pour le suivi, l’expérimentation, l’évaluation, le déploiement et l’amélioration d’applications basées sur des LLM. Le framework est accessible via le pod wandb-app.

Comment obtenir le mot de passe de la console de l’opérateur W&B

Voir Accéder à la console de gestion W&B.

Comment accéder à la console de l’opérateur W&B si l’ingress ne fonctionne pas

Exécutez la commande suivante sur un hôte ayant accès au cluster Kubernetes :

kubectl port-forward svc/wandb-console 8082

Ouvrez la console dans votre navigateur à l’adresse https://localhost:8082/. Pour savoir comment obtenir le mot de passe (option 2), voir Accéder à la console de gestion W&B.

Comment consulter les journaux de W&B Server

Le pod de l’application s’appelle wandb-app-xxx.

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Comment identifier la classe d’ingress Kubernetes

Vous pouvez obtenir la classe d’ingress installée dans votre cluster en exécutant

kubectl get ingressclass

Limites de débit

Déployer sur Kubernetes isolé du réseau

⌘I

​Aperçu

​Avant de commencer

​Base de données MySQL

​Redis

​Stockage d’objets

​Provisionnez votre bucket de stockage

​clusters Kubernetes OpenShift

​Exécutez le conteneur avec un utilisateur non privilégié

​Déployer l’application W&B Server

​Module Terraform Helm

​Modules Terraform pour le cloud

​Vérifiez l’installation

​Activer le serveur MCP

​Prérequis

​Activez le sous-chart

​Vérifier le serveur MCP

​Connecter un client

​Dépannage

​Considérations spécifiques à l’environnement

​sur site et bare metal

​Configuration de l’équilibreur de charge

​Stockage persistant

​Gestion du DNS et des certificats

​Déploiements OpenShift

​Stockage d’objets pour les environnements sur site et compatibles S3

​Sur cloud public avec Terraform

​Déployer avec Terraform sur un cloud public

​Autorisations préalables

​Étapes générales

​Déploiement recommandé

​Activer Redis

​Activer le courtier de messages (file d’attente)

​Ressources supplémentaires

​Autorisations préalables

​Étapes générales

​Déploiement recommandé

​Activer Redis

​Activer le courtier de messages (file d’attente)

​Ressources supplémentaires

​Autorisations préalables

​Étapes générales

​Déploiement recommandé

​Activer Redis

​Activer le courtier de messages (file d’attente)

​Ressources supplémentaires

​Autres options de déploiement

​Accéder à la console de gestion W&B

​Mettre à jour l’opérateur Kubernetes W&B

​Mettre à jour l’application W&B Server

​Mettre à niveau MySQL vers 8.4.x

​Compatibilité de ClickHouse pour les mises à niveau

​Versions de ClickHouse non prises en charge

​Fonctionnalités OLAP de Models

​Migrer des instances Autogéré vers W&B Operator

​Migrer vers des modules Terraform AWS basés sur l’opérateur

​Migrer vers les modules Terraform Google Cloud basés sur l’opérateur

​Migrer vers des modules Terraform Azure basés sur l’opérateur

​Migrer vers le chart Helm basé sur l’opérateur

​Migrer vers le chart Helm Terraform basé sur l’opérateur

​Référence de configuration pour serveur W&B

​Exemple de base

​Exemple complet

​Hôte

​Stockage d’objets (bucket)

​MySQL

​License

​Ingress

​Comptes de service Kubernetes personnalisés

​Redis externe

​LDAP

​OIDC SSO

​SMTP

​Variables d’environnement

​Définir les limites de débit

​Autorité de certification personnalisée

​Contexte de sécurité personnalisé

​Référence de configuration pour l’opérateur W&B

​CA personnalisée

​FAQ

​Objectif et rôle de chaque pod

Aperçu

Avant de commencer

Base de données MySQL

Redis

Stockage d’objets

Provisionnez votre bucket de stockage

clusters Kubernetes OpenShift

Exécutez le conteneur avec un utilisateur non privilégié

Déployer l’application W&B Server

Module Terraform Helm

Modules Terraform pour le cloud

Vérifiez l’installation

Activer le serveur MCP

Prérequis

Activez le sous-chart

Vérifier le serveur MCP

Connecter un client

Dépannage

Considérations spécifiques à l’environnement

sur site et bare metal

Configuration de l’équilibreur de charge

Stockage persistant

Gestion du DNS et des certificats

Déploiements OpenShift

Stockage d’objets pour les environnements sur site et compatibles S3

Sur cloud public avec Terraform

Déployer avec Terraform sur un cloud public

Autorisations préalables

Étapes générales

Déploiement recommandé

Activer Redis

Activer le courtier de messages (file d’attente)

Ressources supplémentaires

Autorisations préalables

Étapes générales

Déploiement recommandé

Activer Redis

Activer le courtier de messages (file d’attente)

Ressources supplémentaires

Autorisations préalables

Étapes générales

Déploiement recommandé

Activer Redis

Activer le courtier de messages (file d’attente)

Ressources supplémentaires

Autres options de déploiement

Accéder à la console de gestion W&B

Mettre à jour l’opérateur Kubernetes W&B

Mettre à jour l’application W&B Server

Mettre à niveau MySQL vers 8.4.x

Compatibilité de ClickHouse pour les mises à niveau

Versions de ClickHouse non prises en charge

Fonctionnalités OLAP de Models

Migrer des instances Autogéré vers W&B Operator

Migrer vers des modules Terraform AWS basés sur l’opérateur

Migrer vers les modules Terraform Google Cloud basés sur l’opérateur

Migrer vers des modules Terraform Azure basés sur l’opérateur

Migrer vers le chart Helm basé sur l’opérateur

Migrer vers le chart Helm Terraform basé sur l’opérateur

Référence de configuration pour serveur W&B

Exemple de base

Exemple complet

Hôte

Stockage d’objets (bucket)

MySQL

License

Ingress

Comptes de service Kubernetes personnalisés

Redis externe

LDAP

OIDC SSO

SMTP

Variables d’environnement

Définir les limites de débit

Autorité de certification personnalisée

Contexte de sécurité personnalisé

Référence de configuration pour l’opérateur W&B

CA personnalisée

FAQ

Objectif et rôle de chaque pod