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

Aperçu

Cette page explique aux administrateurs de la plateforme comment déployer et gérer le serveur W&B sur Kubernetes (dans le cloud ou sur site) à l’aide de l’opérateur Kubernetes W&B. À l’issue de ce guide, vous disposerez d’une installation opérationnelle du serveur W&B, gérée et mise à niveau automatiquement par l’opérateur. Suivez ce guide si vous gérez vous-même un déploiement W&B et avez besoin d’une méthode d’installation adaptée aux 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 le serveur W&B sur Kubernetes (dans le cloud ou sur site). Pour découvrir l’opérateur, les raisons pour lesquelles W&B l’utilise et 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 :

Consultez les exigences relatives à l’infrastructure : consultez la page Exigences relatives à l’infrastructure autogérée pour en savoir plus sur :

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

Obtenez une licence serveur W&B : voir la section License de la page des exigences.
Provisionnez les services externes : configurez MySQL, Redis et le stockage d’objets avant le déploiement.

Pour plus de contexte, consultez la page Architecture de référence.

Base de données MySQL

W&B nécessite une base de données MySQL externe. En production, W&B recommande d’utiliser des services de base de données managés :

Les services de base de données managés fournissent des sauvegardes automatisées, la surveillance, la haute disponibilité et le patching, tout en réduisant la charge opérationnelle. Consultez l’architecture de référence pour connaître les exigences relatives à MySQL, notamment les recommandations de dimensionnement et les paramètres de configuration. Pour obtenir le code SQL permettant de créer la base de données, consultez le guide bare-metal. Pour toute question concernant la configuration de la base de données de votre déploiement, contactez l’assistance ou votre AISE. Pour obtenir les instructions complètes de configuration de MySQL, y compris les paramètres de configuration et la création de la base de données, consultez la section MySQL de la page des exigences. Si vous effectuez une mise à niveau depuis MySQL 8.0.x, consultez Mettre à niveau MySQL vers 8.4.x.

Redis

W&B repose sur un déploiement Redis 7.x à nœud unique, que les composants de W&B utilisent 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é à une utilisation 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 infrastructure cloud ou sur site

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

Stockage d’objets

W&B nécessite 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é de stockage de données non structurées à grande échelle.
Azure Blob Storage : stockage d’objets dans le 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 d’entreprise compatible S3, tel que MinIO Enterprise (AIStor), NetApp StorageGRID ou d’autres solutions d’entreprise.

MinIO Open Source est en mode maintenance : il ne fait plus l’objet d’un développement actif et aucun binaire précompilé n’est fourni. Pour les déploiements en production, W&B recommande des services de stockage d’objets gérés ou des solutions d’entreprise compatibles S3, telles que MinIO Enterprise (AIStor).

Après avoir choisi un fournisseur, configurez le bucket pour 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, consultez le guide Bring Your Own Bucket (BYOB). Pour la liste complète des exigences relatives au stockage d’objets, y compris les recommandations en matière de capacité et de performances, consultez la section consacrée au stockage d’objets dans l’architecture de référence.

Provisionner votre bucket de stockage

Avant de configurer W&B, vous devez provisionner votre bucket de stockage d’objets avec les stratégies IAM, la configuration CORS et les identifiants d’authentification requis. Consultez 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 stratégies IAM et les stratégies de bucket)
Google Cloud Storage (y compris les notifications PubSub)
Azure Blob Storage (y compris les identités managées)
CoreWeave AI Object Storage
Stockage compatible S3 (MinIO Enterprise, NetApp StorageGRID et autres solutions d’entreprise)

Pour savoir comment configurer le stockage d’objets dans les valeurs Helm, consultez la section Configuration du stockage d’objets.

Clusters Kubernetes OpenShift

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

W&B recommande d’effectuer l’installation à l’aide du chart Helm officiel de W&B.

Exécuter le conteneur en tant qu’utilisateur non privilégié

OpenShift et les 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 en tant qu’utilisateur non root appartenant néanmoins au groupe root. Par défaut, les conteneurs utilisent un $UID de 999. Si votre orchestrateur exige que le conteneur s’exécute avec un utilisateur non root, spécifiez un $UID >= 100000 et un $GID de 0.

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

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

api:
  install: true
  image:
    repository: wandb/megabinary
    tag: 0.74.1  # Remplacez par la version que vous utilisez
  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, consultez Contexte de sécurité personnalisé.

Déployer l’application serveur W&B

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és, que ce soit dans le cloud, sur site ou dans des environnements isolés du réseau.

Choisissez votre méthode de déploiement :

CLI Helm
Terraform

W&B fournit un chart Helm permettant de déployer le W&B Kubernetes Operator sur un cluster Kubernetes. Vous pouvez ainsi déployer W&B Server avec la CLI Helm ou avec un outil de livraison continue tel qu’ArgoCD.Pour les considérations propres à chaque déploiement, consultez Considérations propres à l’environnement et Déployer avec Terraform sur un cloud public. Pour les environnements déconnectés, consultez Déployer sur Kubernetes isolé du réseau.Suivez ces étapes pour installer le W&B Kubernetes Operator avec la CLI Helm :

Ajoutez le dépôt Helm W&B, dans lequel le chart Helm W&B est disponible :
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 afin de déclencher l’installation de W&B Server. Créez un fichier nommé operator.yaml contenant la configuration de votre déploiement W&B. Reportez-vous à la Référence de configuration pour connaître toutes les options disponibles. Voici un exemple de 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>

Démarrez 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 la fin du déploiement, qui prend quelques minutes.
Pour vérifier l’installation via l’interface web, créez le premier compte administrateur, puis suivez les étapes de vérification décrites dans Vérifier l’installation.

Une fois ces étapes terminées, un W&B Kubernetes Operator s’exécute dans le namespace wandb-cr, ainsi qu’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. Deux options s’offrent à vous :

Helm Terraform Module : déploie l’opérateur sur une infrastructure Kubernetes existante.
Cloud Terraform Modules : déploiement complet de l’infrastructure et de l’application sur 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 isolé du réseau.

Helm Terraform Module

Cette méthode permet des déploiements personnalisés, adaptés à des exigences spécifiques, et s’appuie sur l’approche infrastructure as code de Terraform pour garantir cohérence et 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 à un déploiement en 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 format HashiCorp Configuration Language (HCL). Le module Terraform crée la définition de ressource personnalisée (CRD) W&B.Pour découvrir comment W&B utilise lui-même le module Terraform Helm afin de déployer des installations Cloud dédié pour ses clients, consultez les liens suivants :

Modules Terraform cloud

W&B fournit un ensemble de modules Terraform pour AWS, Google Cloud et Azure. Ces modules déploient l’infrastructure complète, notamment les clusters Kubernetes, les équilibreurs de charge et les 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 propres à chaque cloud, à partir des versions suivantes :

Terraform Registry	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 lors du déploiement ; vous pouvez donc l’utiliser pour gérer W&B Server dans votre environnement cloud sans configuration supplémentaire.Pour obtenir des instructions détaillées sur l’utilisation de ces modules propres à chaque cloud, voir Déployer avec Terraform sur un cloud public.

Vérifiez l’installation

Pour vérifier l’installation, W&B recommande d’utiliser la CLI W&B. La commande wandb verify exécute des tests qui vérifient que les composants et les configurations fonctionnent comme prévu.

Cette procédure part du principe que vous créez le premier compte utilisateur administrateur dans un navigateur.

Pour vérifier l’installation :

Installez la CLI W&B :
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, si l’installation a réussi, la sortie suivante s’affiche :

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 si vous rencontrez des erreurs.

Activer le serveur MCP

Le serveur MCP de W&B est fourni sous la forme d’un sous-chart facultatif dans operator-wandb. Une fois celui-ci activé, l’opérateur déploie dans le cluster un serveur MCP exposé via votre ingress existant à l’adresse <global.host>/mcp, ce qui permet à tout client compatible MCP de s’y connecter avec une clé API W&B. Il s’agit du même serveur que celui proposé par W&B sous forme d’offre hébergée à l’adresse https://mcp.withwandb.com/mcp, mais configuré pour pointer vers les données de votre déploiement. Pour la configuration des clients par les utilisateurs finaux et le catalogue d’outils, consultez Utiliser le serveur MCP de W&B. Cette section porte uniquement sur l’activation côté opérateur.

Prérequis

Avant d’activer le serveur MCP, assurez-vous que votre déploiement répond aux exigences suivantes :

Version du chart : operator-wandb 0.42.3 ou version ultérieure. Le sous-chart mcp-server a été introduit dans la version 0.42.1, mais les champs Datadog et de confidentialité utilisés dans l’exemple suivant ont été ajoutés par la suite.
Weave Traces activé : le serveur MCP s’appuie sur 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 l’erreur mcp-server requires weave-trace.install=true.
Ingress accessible : global.host doit déjà être résolu et acheminé vers l’ingress W&B. Le pod MCP récupère WANDB_BASE_URL à partir de global.host et est accessible à l’adresse <global.host>/mcp.
Capacité des nœuds : par défaut, le pod MCP demande 500m de CPU et 1Gi de mémoire (limites : 2 CPU et 4Gi de mémoire). Vérifiez que votre Node Pool dispose d’une marge suffisante avant d’activer le sous-chart.

Activer 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 ce qui suit au bloc spec.values de votre ressource personnalisée (CR) WeightsAndBiases existante, à côté de vos redéfinitions global, ingress et autres. Le bloc Datadog est facultatif, mais recommandé si un DaemonSet agent Datadog 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 dans lesquels le DaemonSet de l’agent Datadog 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 conformément 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. Ce niveau masque les valeurs de paramètres en texte libre dans les journaux, tout en conservant les identifiants de déploiement couramment utilisés par les opérateurs pour le débogage. Utilisez "strict" si les identifiants d’entity, de projet, de run ou d’utilisateur ne doivent pas apparaître en clair dans les journaux. N’utilisez "off" que si vous souhaitez explicitement journaliser ces valeurs en clair.

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

kubectl apply -f operator.yaml

L’opérateur crée un déploiement et un service wandb-mcp-server dans le namespace de la version, puis ajoute un 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 de contrôle d’intégrité depuis le 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 interne au cluster confirme que le pod est opérationnel, et celle effectuée via l’ingress confirme le bon acheminement. Si la vérification interne au cluster renvoie 200 OK, mais que celle via l’ingress renvoie 404 Not Found, consultez la section Dépannage. Si vous avez activé Datadog, les journaux du serveur MCP doivent également apparaître dans Datadog avec les valeurs configurées pour mcp-server.datadog.service et mcp-server.datadog.env.

Connecter un client

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

Dépannage

Symptôme	Cause et solution
`helm render` échoue avec `mcp-server requires weave-trace.install=true`	Ajoutez `weave-trace.install: true` à `spec.values`. Le serveur MCP s’appuie sur Weave Traces pour ses outils de trace.
Le pod `wandb-mcp-server` reste bloqué à l’état `Pending` avec `Insufficient cpu` ou `Insufficient memory`	Augmentez la capacité des 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 une erreur 404	Le chart ne génère le chemin d’ingress `/mcp` que si `mcp-server.install: true` est défini. Appliquez de nouveau la 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 définis, et que le DaemonSet de l’Agent Datadog collecte la sortie stdout des pods. Recherchez dans Datadog à l’aide des valeurs `service` et `env` configurées.
Les journaux MCP contiennent plus de texte fourni par l’utilisateur que prévu	Définissez `mcp-server.privacy.logLevel` sur `"standard"` ou `"strict"`. Utilisez `"strict"` si des identifiants tels que les noms d’entity, de projet, de run ou d’utilisateur ne doivent pas figurer en clair dans les journaux.
Le pod `wandb-mcp-server` est à l’état `ImagePullBackOff` dans un cluster isolé du réseau ou utilisant un miroir	Copiez l’image dans votre registre et redéfinissez `mcp-server.image.repository` dans votre CR, comme 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 propres à chaque environnement

Kubernetes fonctionne de la même manière, qu’il soit exécuté sur site ou dans le cloud. Les principales différences portent sur le nommage et les services managés (par exemple, MySQL ou RDS, S3 ou un stockage d’objets sur site). Cette section présente les points à prendre en compte selon l’environnement.

Environnements 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. Plusieurs options sont possibles :

É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 en mode réseau hôte.
MetalLB : pour les clusters Kubernetes sur bare metal, MetalLB fournit des services d’équilibrage de charge.

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

Stockage persistant

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

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 des enregistrements DNS internes pointant vers votre nom d’hôte W&B.
Provisionnez des certificats SSL/TLS émis par votre autorité de certification (CA) interne.
Si vous utilisez des certificats autosignés, configurez l’opérateur pour qu’il approuve le certificat de votre CA.

Pour plus de détails sur la configuration des certificats, consultez les exigences SSL/TLS.

Déploiements OpenShift

W&B prend entièrement en charge le déploiement sur des clusters Kubernetes OpenShift. Les politiques de sécurité d’OpenShift étant plus strictes, les déploiements OpenShift nécessitent des configurations de contexte de sécurité supplémentaires. Pour plus de détails sur la configuration propre à OpenShift, voir Clusters Kubernetes OpenShift. Pour des exemples 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

Après avoir provisionné votre bucket de stockage d’objets (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: ""               # Conserver une chaîne vide
  provider: s3
  region: <region>       # Exemple : us-east-1

Stockage compatible S3, tel que MinIO, Ceph ou NetApp Pour les systèmes de stockage compatibles 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 sur un stockage compatible S3, ajoutez ?tls=true à la fin du chemin du bucket :

bucket:
  path: "wandb?tls=true"

Le certificat doit être approuvé. Les certificats autosignés nécessitent une configuration supplémentaire. Pour plus de détails, consultez les exigences SSL/TLS.

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é des disques. Une utilisation moyenne de W&B représente de quelques dizaines à quelques centaines de gigaoctets. Une utilisation intensive peut entraîner une consommation de stockage de l’ordre du pétaoctet.
Tolérance aux pannes : utilisez au minimum des grappes RAID pour les disques physiques. Pour un stockage compatible S3, privilégiez des configurations distribuées ou à haute disponibilité.
Disponibilité : mettez en place une supervision pour vous assurer que le stockage reste disponible.

Considérations relatives à MinIO

MinIO Open Source est en mode maintenance et ne fait plus l’objet d’aucun 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 en production, W&B recommande d’utiliser des services de stockage d’objets gérés ou MinIO Enterprise (AIStor).

Parmi les solutions d’entreprise pour le stockage d’objets sur site, citons :

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

Cloud public avec Terraform

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

Déployer avec Terraform sur un cloud public

W&B recommande les options de déploiement entièrement gérées, comme les types de déploiement Cloud mutualisé de W&B ou Cloud dédié de W&B. Les services entièrement gérés ne nécessitent que peu ou pas de configuration.

W&B fournit des modules Terraform pour déployer la plateforme chez les fournisseurs de cloud public. Ces modules automatisent le provisionnement de l’infrastructure et l’installation du serveur W&B, ce qui vous permet de mettre en place un environnement complet sans avoir à créer manuellement chaque ressource cloud. Avant de commencer, W&B vous recommande de choisir l’un des backends distants disponibles pour Terraform afin d’y stocker le fichier d’état (State File). Le fichier d’état est indispensable pour déployer des mises à niveau ou modifier 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 module Terraform AWS de W&B Server 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

Parmi les composants facultatifs, citons :

Elastic Cache for Redis
SQS

Autorisations requises

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 que pour attribuer des rôles aux ressources.

Étapes générales

Les étapes de cette section s’appliquent à 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 contrôle de version.
Créez le fichier terraform.tfvars. Personnalisez le contenu du fichier tvfars en fonction du type d’installation. Le contenu minimum recommandé se présente comme 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"
Définissez les variables dans votre fichier tvfars avant de procéder au déploiement, car 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 de votre instance W&B. Dans l’exemple précédent, le FQDN de W&B est wandb-aws.wandb.ml, et le zone_id DNS identifie la zone dans laquelle Terraform crée l’enregistrement correspondant au FQDN. Vous devez également définir allowed_inbound_cidr et allowed_inbound_ipv6_cidr. Dans le module, il s’agit d’entrées obligatoires. L’exemple suivant autorise l’accès à l’installation W&B depuis n’importe quelle source.
Créez le fichier versions.tf. Ce fichier contient les versions de Terraform et du fournisseur Terraform requises 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" } } }
Référez-vous à 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 le fichier terraform.tfvars, Terraform exige la déclaration d’une 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 : elle crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.

Créer le fichier main.tf Dans le répertoire où vous avez créé les fichiers lors des étapes générales, 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 d’accélérer les temps de 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 broker de messages (file d’attente)

Pour activer un broker de messages externe basé sur SQS, ajoutez l’option use_internal_queue = false au fichier main.tf :

Cette étape est facultative, car W&B intègre déjà un broker. Cette option n’améliore pas les 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 complémentaires

Pour déployer la plateforme sur Google Cloud, W&B recommande d’utiliser le module Terraform W&B Server pour 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 indispensable pour appliquer des mises à niveau ou modifier votre déploiement sans recréer tous les composants.Le module Terraform déploie les composants obligatoires suivants :

VPC
Cloud SQL pour MySQL
Bucket Cloud Storage
Google Kubernetes Engine
Memorystore pour Redis
Clé de chiffrement KMS
Équilibreur de charge

Les composants facultatifs sont les suivants :

Système de messagerie Pub/Sub

Autorisations requises

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 aussi conserver vos fichiers en local.
- Créez un projet dans la console Google Cloud.
- Authentifiez-vous auprès de Google Cloud avec la commande gcloud auth application-default login (veillez à installer gcloud au préalable).
Créez le fichier terraform.tfvars. Personnalisez le contenu du fichier tvfars en fonction du type d’installation. Le contenu minimal recommandé se présente comme dans 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 le fichier terraform.tfvars, Terraform exige la déclaration d’une 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 : elle crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.

Créer le fichier main.tf Dans le même répertoire que celui où vous avez créé les fichiers lors des étapes générales, 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
  }
}

# Déployer 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
}

# Pensez à mettre à 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 d’accélérer le temps de 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 broker de messages (file d’attente)

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

Cette option est facultative, car W&B intègre déjà un broker. Elle n’apporte aucun gain de 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 complémentaires

W&B recommande d’utiliser le module Terraform Azure de W&B Server 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
Réseau virtuel Azure (VPC)
Serveur flexible Azure Database pour MySQL
Compte de stockage Azure et stockage de blobs
Azure Kubernetes Service
Azure Application Gateway

Les composants facultatifs comprennent :

Azure Cache for Redis
Azure Event Grid

Autorisations requises

Le moyen le plus simple de configurer le fournisseur AzureRM est de passer par l’Azure CLI. Pour l’automatisation, vous pouvez également utiliser un principal de service Azure.Quelle que soit la méthode d’authentification utilisée, le compte qui exécute Terraform doit être en mesure de créer tous les composants énumérés dans la section précédente.

Étapes générales

Les étapes de cette section s’appliquent à 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 aussi conserver vos fichiers en local.
Créez le fichier terraform.tfvars. Personnalisez le contenu du fichier tvfars en fonction du type d’installation. Le contenu minimal recommandé se présente comme dans l’exemple suivant.
namespace = "wandb" wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz" subdomain = "wandb-azure" domain_name = "wandb.ml" location = "westeurope"
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-azure.wandb.ml.
Créez le fichier versions.tf. Ce fichier contient les versions de Terraform et du provider Terraform requises pour déployer W&B sur Azure :
terraform { required_version = "~> 1.3" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.17" } } }
Référez-vous à la documentation officielle de Terraform pour configurer le fournisseur Azure. W&B vous recommande d’ajouter également 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 le fichier terraform.tfvars, Terraform exige la déclaration d’une 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 : elle crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.

Créer le fichier main.tf Dans le répertoire où vous avez créé les fichiers lors des étapes générales, créez un fichier main.tf contenant ce qui suit :

  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)
 }
  }

  # Déployer 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

Pour utiliser Redis afin de mettre en cache les requêtes SQL et d’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 :

# Déployer 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 broker de messages (file d’attente)

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

Cette étape est facultative, car W&B intègre déjà un broker. Cette option n’améliore pas les performances.

# Déployer 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 complémentaires

Autres options de déploiement

Vous pouvez combiner plusieurs options de déploiement en ajoutant toutes les configurations au même fichier. Chaque module Terraform propose plusieurs options, que vous pouvez combiner avec les options standard et la configuration minimale décrites dans la section consacrée au déploiement recommandé. Reportez-vous à la documentation du module correspondant à votre fournisseur de cloud 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 qui vous permet de consulter le statut du déploiement, d’afficher les métriques des composants et d’ajuster les paramètres de l’opérateur. Elle est disponible à l’adresse ${HOST_URI}/console, par exemple https://wandb.company-name.com/console. Vous pouvez vous connecter à la console de gestion de deux manières :

Option 1 (recommandée)
Option 2

Ouvrez l’application W&B dans votre navigateur et connectez-vous. Connectez-vous à l’application W&B via ${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 System console. Seuls les utilisateurs disposant de privilèges d’administrateur voient l’entrée System console.

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 la console dans votre navigateur. Ouvrez l’URL indiquée dans la section précédente, qui vous redirige vers l’écran de connexion :
Récupérez le mot de passe dans le secret Kubernetes généré lors de 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 des corrections de bugs et des 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 ne repose pas sur 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 serveur W&B

Si vous utilisez l’opérateur Kubernetes W&B, vous n’avez plus besoin de mettre à jour vous-même l’application serveur W&B. L’opérateur met automatiquement à jour votre application serveur W&B dès qu’une nouvelle version de W&B est publiée.

Mettre à niveau MySQL vers 8.4.x

MySQL 8.0.x a atteint sa fin de vie. Les déploiements autogérés doivent exécuter une version de MySQL prise en charge qui reçoit les correctifs de sécurité et les corrections de bugs critiques. Si vous utilisez MySQL Community, installez MySQL 8.4.x ou effectuez la mise à niveau vers cette version. Si vous utilisez un service managé, exécutez une version du moteur que votre fournisseur indique comme prise en charge et à jour des correctifs (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 procédure du point de vue de W&B. Pour la mise à niveau de MySQL proprement dite, 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 procédure 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.

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

Consultez les notes de version et la documentation de MySQL pour votre version cible et 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 de MySQL Shell sur votre base de données afin de détecter et de corriger les problèmes de compatibilité avec votre version cible. Résolvez toutes les erreurs et tous les avertissements signalés par le vérificateur avant de continuer. Reportez-vous à 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 s’y 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 démarré, 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 sur STDOUT. Si elle signale des problèmes, effectuez les ajustements nécessaires et relancez-la. Pour les étapes de configuration et de connexion, voir Vérifiez l’installation.
Une fois la validation terminée, les utilisateurs peuvent reprendre normalement leurs activités.

Compatibilité de ClickHouse pour les mises à niveau

Pour les déploiements autogérés qui utilisent un cluster ClickHouse externe, vérifiez la compatibilité de ClickHouse avant de procéder à la mise à niveau du serveur W&B.

Versions de ClickHouse prises en charge

W&B Weave nécessite une version prise en charge du serveur ClickHouse et de ClickHouse Keeper.

Weave prend en charge les versions 25.8 à 25.12 de ClickHouse, ainsi que la version 26.3 et les versions ultérieures.
Weave ne fonctionne pas avec les versions 26.1 et 26.2 de ClickHouse.

Avant de mettre à niveau W&B autogéré, vérifiez que le serveur ClickHouse et ClickHouse Keeper exécutent tous deux une version prise en charge par Weave. Si vous devez changer de version de ClickHouse, mettez à niveau les deux composants en même temps. Si votre déploiement W&B autogéré n’utilise pas Weave, ClickHouse n’est pas requis et 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 consulter les notes de version détaillées de chaque version, voir Versions du serveur W&B prises en charge.

Migrer des instances autogérées vers le W&B Operator

Cette section explique comment passer d’une installation du serveur W&B que vous gérez vous-même à une installation gérée à votre place par le W&B Operator. Après la migration, l’opérateur prend en charge automatiquement la réconciliation et les mises à niveau du serveur W&B : vous n’avez donc plus à coordonner les modifications de manifestes ni les mises à niveau Helm de l’application. La procédure de migration dépend de la façon dont vous avez installé le serveur W&B :

Le W&B Operator est la méthode d’installation par défaut et recommandée pour le serveur W&B. Pour toute question, contactez l’assistance client ou votre équipe W&B.

Si vous avez utilisé les modules Terraform officiels W&B Cloud, consultez la documentation correspondante et suivez les étapes qui y sont décrites :
- AWS
- Google Cloud
- Azure
Si vous avez utilisé le chart Helm W&B sans opérateur, consultez Migrer vers le chart Helm basé sur l’opérateur.
Si vous avez utilisé le chart Helm W&B sans opérateur avec Terraform, consultez Migrer vers le chart Helm Terraform basé sur l’opérateur.
Si vous avez créé les ressources Kubernetes à l’aide de manifestes, consultez Migrer vers le chart Helm basé sur l’opérateur.

Migrer vers les 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

Si vous avez des questions ou besoin d’aide, contactez l’assistance client ou votre équipe W&B.

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

Pour toute question ou demande d’aide, contactez l’assistance client ou votre équipe W&B.

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

Pour migrer vers le chart Helm basé sur l’opérateur, suivez ces étapes :

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 suit :
helm get values wandb
Si vous avez déployé W&B avec des manifestes Kubernetes, exportez les valeurs comme suit :
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. Respectez le format décrit dans la Référence de configuration. Utilisez les valeurs obtenues à l’étape 1.
Réduisez le déploiement actuel à 0 pod. Cette opération 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 la section Vérifier l’installation.
Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources que vous avez créées à l’aide des manifestes.

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. Dans votre configuration Terraform, remplacez le code Terraform de l’ancien déploiement par le code décrit dans Déployer W&B avec le module Terraform Helm. Définissez les mêmes variables qu’auparavant. Si vous disposez d’un fichier .tfvars, ne le modifiez pas.
Exécutez Terraform. Exécutez terraform init, terraform plan et terraform apply.
Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de la section Vérifier l’installation.
Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources que vous avez créées à l’aide de manifestes.

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

Cette section décrit les options de configuration que vous définissez dans votre ressource personnalisée WeightsAndBiases. Consultez-la pour trouver le schéma YAML d’un sous-système donné (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 exposées dans la configuration ci-dessous. Les autres doivent être définies sous forme de variables d’environnement. La documentation propose deux listes de variables d’environnement : de base et avancées. N’utilisez les variables d’environnement que si l’option de configuration dont vous avez besoin n’est pas exposée par le chart Helm.

Exemple de base

Cet exemple définit l’ensemble minimal des valeurs requises pour W&B. Pour un exemple de production plus réaliste, consultez Exemple complet. Ce fichier YAML définit l’état souhaité de votre déploiement W&B, notamment la version, les variables d’environnement, les ressources externes telles que les bases de données, ainsi que les 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>

Vous trouverez l’ensemble complet des valeurs dans le dépôt Helm W&B. Ne modifiez que les valeurs que vous devez redéfinir.

Exemple complet

Cet exemple de configuration déploie W&B sur Google Cloud Anthos avec 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

 # Fournissez le FQDN avec le protocole
global:
  # nom d’hôte donné à titre d’exemple, remplacez-le 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 solutions de stockage compatibles S3) Pour les autres fournisseurs compatibles S3, configurez le bucket comme suit :

global:
  bucket:
    # Valeurs données à titre d’exemple, 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 référencer accessKey et secretKey depuis un secret :

global:
  bucket:
    # Valeurs données à titre d’exemple, 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:
     # Valeurs données à titre d’exemple, 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:
     # Valeurs données à titre d’exemple, remplacez-les 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:
  # Licence d’exemple, remplacez-la par la vôtre
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

Pour référencer 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 : dans le YAML, Ingress se situe au même niveau que 'global' (il n’en est 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

Référencez le secret dans la configuration de l’ingress

global:
# IMPORTANT : dans le YAML, ingress se situe au même niveau que 'global' (il ne s’agit pas d’une clé enfant)
ingress:
  class: ""
  annotations:
    {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  tls: 
    - secretName: wandb-ingress-tls
      hosts:
        - <HOST_URI>

Pour Nginx, vous devrez peut-être 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, dans le cadre du déploiement, un compte de service portant le nom spécifié :

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 sous le compte de service spécifié. Les autres sous-systèmes s’exécutent sous 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, comme app, parquet, console, etc. :

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 faire référence au password 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

Le chart Helm actuel ne prend en charge la configuration LDAP que de façon limitée. Pour obtenir de l’aide sur la configuration de LDAP, contactez l’assistance W&B ou votre AISE.

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

SSO OIDC

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 des limites de débit

Pour les déploiements Cloud dédié et autogérés qui utilisent l’opérateur, vous pouvez configurer des limites de débit en définissant des variables d’environnement dans spec.values.global.extraEnv. À titre de référence, cet exemple définit explicitement chaque limite de débit sur sa valeur par défaut. En pratique, ne définissez une limite de débit que si vous souhaitez remplacer 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"

Reportez-vous au tableau suivant pour plus de détails :

Variable d’environnement	Par défaut	Description
`GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM`	`5`	Requêtes filestream par défaut.
`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 seconde et par run.
`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 et peut contenir plusieurs certificats. Les autorités de certification définies dans customCACerts s’appliquent uniquement à l’application serveur W&B.

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 d’autorité de certification 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 un ConfigMap, chaque clé du 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 analyser chaque certificat et l’ajouter au magasin de certificats CA du système.

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 provoque 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 principe s’applique à console, weave, weave-trace et parquet.

Référence de configuration du W&B Operator

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 ne nécessite aucun fichier de configuration. Créez-en un si besoin. Un fichier de configuration peut par exemple s’avérer nécessaire pour spécifier des autorités de certification personnalisées ou pour effectuer un déploiement dans un environnement isolé (air gap). Vous trouverez la liste complète des personnalisations possibles de la spec dans le dépôt Helm.

Autorité de certification personnalisée

Le paramètre d’autorité de certification personnalisée (customCACerts) est une liste et peut 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 d’autorité de certification peuvent également être stockés dans une ConfigMap :

caCertsConfigMap: custom-ca-certs

La 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-----

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 analyser chaque certificat et l’ajouter au magasin de certificats CA du système.

FAQ

Objectif et rôle de chaque pod

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

wandb-app : le cœur de W&B, qui comprend l’API GraphQL et l’application frontend. Il prend en charge la plupart 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 de la couche 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 tableaux de requêtes dans l’interface utilisateur et prend en charge diverses fonctionnalités essentielles de l’application.
wandb-weave-trace : un framework permettant de suivre, d’expérimenter, d’évaluer, de déployer et d’améliorer des applications basées sur des LLM. Ce framework est accessible via le pod wandb-app.

Comment obtenir le mot de passe de la console W&B Operator

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

Comment accéder à la console W&B Operator si l’Ingress ne fonctionne pas

Exécutez la commande suivante sur un hôte pouvant accéder au cluster Kubernetes :

kubectl port-forward svc/wandb-console 8082

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

Comment consulter les journaux du serveur W&B

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

Pour obtenir la classe d’ingress installée dans votre cluster, exécutez

kubectl get ingressclass

Dernière modification le 30 septembre 2026

​Aperçu

​Avant de commencer

​Base de données MySQL

​Redis

​Stockage d’objets

​Provisionner votre bucket de stockage

​Clusters Kubernetes OpenShift

​Exécuter le conteneur en tant qu’utilisateur non privilégié

​Déployer l’application serveur W&B

​Helm Terraform Module

​Modules Terraform cloud

​Vérifiez l’installation

​Activer le serveur MCP

​Prérequis

​Activer le sous-chart

​Vérifier le serveur MCP

​Connecter un client

​Dépannage

​Considérations propres à chaque environnement

​Environnements 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

​Cloud public avec Terraform

​Déployer avec Terraform sur un cloud public

​Autorisations requises

​Étapes générales

​Déploiement recommandé

​Activer Redis

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

​Ressources complémentaires

​Autorisations requises

​Étapes générales

​Déploiement recommandé

​Activer Redis

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

​Ressources complémentaires

​Autorisations requises

​Étapes générales

​Déploiement recommandé

​Activer Redis

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

​Ressources complé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 serveur W&B

​Mettre à niveau MySQL vers 8.4.x

​Compatibilité de ClickHouse pour les mises à niveau

​Versions de ClickHouse prises en charge

​Migrer des instances autogérées vers le W&B Operator

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

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

​Migrer vers les 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 du 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

​SSO OIDC

​SMTP

​Variables d’environnement

​Définir des limites de débit

​Autorité de certification personnalisée

​Contexte de sécurité personnalisé

​Référence de configuration du W&B Operator

​Autorité de certification personnalisée

​FAQ

​Objectif et rôle de chaque pod

​Comment obtenir le mot de passe de la console W&B Operator

Aperçu

Avant de commencer

Base de données MySQL

Redis

Stockage d’objets

Provisionner votre bucket de stockage

Clusters Kubernetes OpenShift

Exécuter le conteneur en tant qu’utilisateur non privilégié

Déployer l’application serveur W&B

Helm Terraform Module

Modules Terraform cloud

Vérifiez l’installation

Activer le serveur MCP

Prérequis

Activer le sous-chart

Vérifier le serveur MCP

Connecter un client

Dépannage

Considérations propres à chaque environnement

Environnements 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

Cloud public avec Terraform

Déployer avec Terraform sur un cloud public

Autorisations requises

Étapes générales

Déploiement recommandé

Activer Redis

Activer le broker de messages (file d’attente)

Ressources complémentaires

Autorisations requises

Étapes générales

Déploiement recommandé

Activer Redis

Activer le broker de messages (file d’attente)

Ressources complémentaires

Autorisations requises

Étapes générales

Déploiement recommandé

Activer Redis

Activer le broker de messages (file d’attente)

Ressources complé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 serveur W&B

Mettre à niveau MySQL vers 8.4.x

Compatibilité de ClickHouse pour les mises à niveau

Versions de ClickHouse prises en charge

Migrer des instances autogérées vers le W&B Operator

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

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

Migrer vers les 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 du 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

SSO OIDC

SMTP

Variables d’environnement

Définir des limites de débit

Autorité de certification personnalisée

Contexte de sécurité personnalisé

Référence de configuration du W&B Operator

Autorité de certification personnalisée

FAQ

Objectif et rôle de chaque pod

Comment obtenir le mot de passe de la console W&B Operator