> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. > Déployer W&B Platform avec l’opérateur Kubernetes dans le cloud ou sur site # 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é](/fr/products/wandb/platform/hosting/hosting-options/self-managed#about-the-wb-kubernetes-operator).

Avant de commencer

Avant de déployer W\&B avec l’opérateur Kubernetes, assurez-vous que votre infrastructure répond à toutes les exigences : 1. **Consultez les exigences relatives à l’infrastructure** : consultez la page [Exigences relatives à l’infrastructure autogérée](/fr/products/wandb/platform/hosting/self-managed/requirements) 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 2. **Obtenez une licence serveur W\&B** : voir la section [License](/fr/products/wandb/platform/hosting/self-managed/requirements#license) de la page des exigences. 3. **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](/fr/products/wandb/platform/hosting/self-managed/ref-arch).

Base de données MySQL

MySQL 8.0.x a atteint sa fin de vie en avril 2026. Les déploiements W\&B autogérés doivent exécuter une version de MySQL prise en charge qui bénéficie encore des correctifs de sécurité et des corrections de bugs critiques. Si vous utilisez MySQL Community, installez **MySQL 8.4.x** ou effectuez une mise à niveau vers cette version. Si vous utilisez un service géré, 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. Si vous utilisez encore MySQL 8.0.x, planifiez une mise à niveau en suivant les étapes décrites dans [Mettre à niveau MySQL vers 8.4.x](/fr/products/wandb/platform/hosting/self-managed/operator#upgrade-mysql-to-84x). 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 : * [AWS RDS Aurora MySQL](https://aws.amazon.com/rds/aurora/) * [Google Cloud SQL for MySQL](https://cloud.google.com/sql/mysql) * [Azure Database for MySQL](https://azure.microsoft.com/en-us/products/mysql/) 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](/fr/products/wandb/platform/hosting/self-managed/ref-arch#mysql) 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](/fr/products/wandb/platform/hosting/self-managed/operator#mysql-database). Pour toute question concernant la configuration de la base de données de votre déploiement, contactez l’[assistance](mailto:forge-support@coreweave.com) 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](/fr/products/wandb/platform/hosting/self-managed/requirements#mysql-database). Si vous effectuez une mise à niveau depuis MySQL 8.0.x, consultez [Mettre à niveau MySQL vers 8.4.x](#upgrade-mysql-to-84x).

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](https://aws.amazon.com/elasticache/) * [Google Cloud Memorystore](https://cloud.google.com/memorystore?hl=en) * [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache) * Redis auto-hébergé dans votre infrastructure cloud ou sur site Voir la [section Configuration de Redis externe](#external-redis) 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](https://aws.amazon.com/s3/) : service de stockage d’objets offrant évolutivité, disponibilité des données, sécurité et performances. * [Google Cloud Storage](https://cloud.google.com/storage) : service géré de stockage de données non structurées à grande échelle. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) : stockage d’objets dans le cloud pour les données non structurées à grande échelle. * [CoreWeave AI Object Storage](/products/storage/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)](https://www.min.io/product/aistor), [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) ou d’autres solutions d’entreprise. MinIO Open Source est en [mode maintenance](https://github.com/minio/minio) : 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)](/fr/products/wandb/platform/hosting/data-security/secure-storage-connector). 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](/fr/products/wandb/platform/hosting/self-managed/ref-arch#object-storage).

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)](/fr/products/wandb/platform/hosting/data-security/secure-storage-connector) 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](#object-storage-bucket).

Clusters Kubernetes OpenShift

W\&B prend en charge le déploiement sur des [clusters Kubernetes OpenShift](https://www.redhat.com/en/technologies/cloud-computing/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 : ```yaml theme={"system"} 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é](#custom-security-context).

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 : 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](#environment-specific-considerations) et [Déployer avec Terraform sur un cloud public](#deploy-with-terraform-on-public-cloud). Pour les environnements déconnectés, consultez [Déployer sur Kubernetes isolé du réseau](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped). Suivez ces étapes pour installer le W\&B Kubernetes Operator avec la CLI Helm : 1. Ajoutez le dépôt Helm W\&B, dans lequel le chart Helm W\&B est disponible : ```shell theme={"system"} helm repo add wandb https://charts.wandb.ai helm repo update ``` 2. Installez l’opérateur sur un cluster Kubernetes : ```shell theme={"system"} helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace ``` 3. 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](#configuration-reference-for-wb-server) pour connaître toutes les options disponibles. Voici un exemple de configuration minimale : ```yaml theme={"system"} 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:// license: eyJhbGnUzaH...j9ZieKQ2x5GGfw bucket:
mysql: ingress: annotations: ``` 4. Démarrez l’opérateur avec votre configuration personnalisée afin qu’il puisse installer, configurer et gérer l’application W\&B Server : ```shell theme={"system"} kubectl apply -f operator.yaml ``` Attendez la fin du déploiement, qui prend quelques minutes. 5. 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](#verify-the-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](#environment-specific-considerations) et [Déployer avec Terraform sur le cloud public](#deploy-with-terraform-on-public-cloud). Pour les environnements déconnectés, voir [Déployer sur Kubernetes isolé du réseau](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped).

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](https://registry.terraform.io/modules/wandb/wandb/helm/latest) 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 : ```hcl theme={"system"} module "wandb" { source = "wandb/wandb/helm" spec = { values = { global = { host = "https://" license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw" bucket = {
} mysql = { } } 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](#configuration-reference-for-wb-server), 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 : * [AWS](https://github.com/wandb/terraform-aws-wandb/blob/45e1d746f53e78e73e68f911a1f8cad5408e74b6/main.tf#L225) * [Azure](https://github.com/wandb/terraform-azurerm-wandb/blob/170e03136b6b6fc758102d59dacda99768854045/main.tf#L155) * [Google Cloud](https://github.com/wandb/terraform-google-wandb/blob/49ddc3383df4cefc04337a2ae784f57ce2a2c699/main.tf#L189)

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://registry.terraform.io/modules/wandb/wandb/aws/latest) | [https://github.com/wandb/terraform-aws-wandb](https://github.com/wandb/terraform-aws-wandb) | v4.0.0+ | | [Azure](https://github.com/wandb/terraform-azurerm-wandb) | [https://github.com/wandb/terraform-azurerm-wandb](https://github.com/wandb/terraform-azurerm-wandb) | v2.0.0+ | | [Google Cloud](https://github.com/wandb/terraform-google-wandb) | [https://github.com/wandb/terraform-google-wandb](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](#deploy-with-terraform-on-public-cloud).

Vérifiez l’installation

Pour vérifier l’installation, W\&B recommande d’utiliser la [CLI W\&B](/fr/products/wandb/ref/cli). 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 : 1. Installez la CLI W\&B : ```bash theme={"system"} pip install wandb ``` 2. Connectez-vous à W\&B : ```bash theme={"system"} wandb login --host=https://YOUR_DNS_DOMAIN ``` Par exemple : ```bash theme={"system"} wandb login --host=https://wandb.company-name.com ``` 3. Vérifiez l’installation : ```bash theme={"system"} wandb verify ``` Une fois la commande exécutée, si l’installation a réussi, la sortie suivante s’affiche : ```console theme={"system"} 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](/fr/products/wandb/platform/mcp-server) 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 `/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](/fr/products/wandb/platform/mcp-server). 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 `/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. ```yaml theme={"system"} 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-" env: "" deploymentType: "self-managed" customer: "" extraTags: - "region:" - "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 : ```bash theme={"system"} 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 : ```bash theme={"system"} 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:///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](#troubleshooting). 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:///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](/fr/products/wandb/platform/mcp-server).

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:///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](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped). |

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](/fr/products/wandb/platform/hosting/self-managed/ref-arch#networking).

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](/fr/products/wandb/platform/hosting/self-managed/requirements#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](#openshift-kubernetes-clusters). Pour des exemples OpenShift dans des environnements isolés du réseau, voir [Déployer sur Kubernetes isolé du réseau](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped#openshift-configuration).

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](/fr/products/wandb/platform/hosting/data-security/secure-storage-connector)), configurez-le dans votre Ressource personnalisée W\&B. **AWS S3 (sur site)** Pour AWS S3 sur site (via Outposts ou un stockage compatible) : ```yaml theme={"system"} bucket: kmsKey: # Clé KMS facultative pour le chiffrement name: # Exemple : wandb path: "" # Conserver une chaîne vide provider: s3 region: # Exemple : us-east-1 ``` **Stockage compatible S3, tel que MinIO, Ceph ou NetApp** Pour les systèmes de stockage compatibles S3 : ```yaml theme={"system"} bucket: kmsKey: null name: # Exemple : s3.example.com:9000 path: # Exemple : wandb provider: s3 region: # Exemple : us-east-1 ``` Pour activer TLS sur un stockage compatible S3, ajoutez `?tls=true` à la fin du chemin du bucket : ```yaml theme={"system"} 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](/fr/products/wandb/platform/hosting/self-managed/requirements#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 : 1. **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. 2. **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é. 3. **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](https://github.com/minio/minio) 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)](https://min.io/product/aistor). Parmi les solutions d’entreprise pour le stockage d’objets sur site, citons : * [Amazon S3 on Outposts](https://aws.amazon.com/s3/outposts/) * [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) * MinIO Enterprise (AIStor) * [Dell ObjectScale](https://www.dell.com/en-us/shop/cty/sf/objectscale) Si vous utilisez un déploiement MinIO existant ou MinIO Enterprise, vous pouvez créer un bucket à l’aide du client MinIO : ```bash theme={"system"} 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](#deploy-with-terraform-on-public-cloud).

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](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) ou [Cloud dédié de W\&B](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud). 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](https://developer.hashicorp.com/terraform/language/backend) disponibles pour Terraform afin d’y stocker le [fichier d’état (State File)](https://developer.hashicorp.com/terraform/language/state). 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 : W\&B recommande d’utiliser le [module Terraform AWS de W\&B Server](https://registry.terraform.io/modules/wandb/wandb/aws/latest) 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. 1. Préparez l’environnement de développement. * Installez [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) * W\&B recommande de créer un dépôt Git pour le contrôle de version. 2. 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. ```bash theme={"system"} 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. 3. 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 : ```bash theme={"system"} 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](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration) pour configurer le fournisseur AWS. W\&B recommande également d’ajouter la [configuration du backend distant](https://developer.hashicorp.com/terraform/language/backend) mentionnée au début de cette documentation. 4. 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. ```hcl theme={"system"} 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 } ``` 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. 1. 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 : ```hcl theme={"system"} 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 } ``` 2. Déployer W\&B Pour déployer W\&B, exécutez les commandes suivantes : ```bash theme={"system"} 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` : ```hcl theme={"system"} 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. ```hcl theme={"system"} 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

* [Documentation du module Terraform AWS](https://registry.terraform.io/modules/wandb/wandb/aws/latest) * [Code source du module Terraform AWS](https://github.com/wandb/terraform-aws-wandb) * [Migrer vers les modules Terraform AWS basés sur l’opérateur](#migrate-to-operator-based-aws-terraform-modules) Pour déployer la plateforme sur Google Cloud, W\&B recommande d’utiliser le [module Terraform W\&B Server pour Google Cloud](https://registry.terraform.io/modules/wandb/wandb/google/latest). La documentation du module répertorie toutes les options disponibles. Avant de commencer, W\&B vous recommande de choisir l’un des [backends distants](https://developer.hashicorp.com/terraform/language/backend/remote) disponibles pour Terraform afin de stocker le [fichier d’état](https://developer.hashicorp.com/terraform/language/state). 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. 1. Préparez l’environnement de développement. * Installez [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli). * 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](https://console.cloud.google.com/). * Authentifiez-vous auprès de Google Cloud avec la commande `gcloud auth application-default login` (veillez à [installer gcloud](https://cloud.google.com/sdk/docs/install) au préalable). 2. 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. ```bash theme={"system"} 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`. 3. 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. ```hcl theme={"system"} 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" } ``` 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. 1. 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 : ```hcl theme={"system"} 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 } ``` 2. Déployez W\&B. Pour déployer W\&B, exécutez les commandes suivantes : ```bash theme={"system"} 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` : ```hcl theme={"system"} [...] 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. ```hcl theme={"system"} [...] 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

* [Documentation du module Terraform pour Google Cloud](https://registry.terraform.io/modules/wandb/wandb/google/latest) * [Code source du module Terraform pour Google Cloud](https://github.com/wandb/terraform-google-wandb) W\&B recommande d’utiliser le [module Terraform Azure de W\&B Server](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest) 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](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/azure_cli). Pour l’automatisation, vous pouvez également utiliser un [principal de service Azure](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_client_secret). 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. 1. Préparez l’environnement de développement. * Installez [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) * W\&B recommande de créer un dépôt Git pour votre code, mais vous pouvez aussi conserver vos fichiers en local. 2. 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. ```bash theme={"system"} 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`. 3. 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 : ```bash theme={"system"} terraform { required_version = "~> 1.3" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.17" } } } ``` Référez-vous à la [documentation officielle de Terraform](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs) pour configurer le fournisseur Azure. W\&B vous recommande d’ajouter également la [configuration du backend distant](https://developer.hashicorp.com/terraform/language/backend) mentionnée au début de cette documentation. 4. 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. ```bash theme={"system"} 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" } ``` 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. 1. 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 : ```bash theme={"system"} 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 } ``` 2. Déployer W\&B Pour déployer W\&B, exécutez les commandes suivantes : ```bash theme={"system"} 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` : ```bash theme={"system"} # 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. ```bash theme={"system"} # 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

* [Documentation du module Terraform Azure](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest) * [Code source du module Terraform Azure](https://github.com/wandb/terraform-azurerm-wandb)

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 : * [Documentation du module AWS](https://registry.terraform.io/modules/wandb/wandb/aws/latest) * [Documentation du module Google Cloud](https://registry.terraform.io/modules/wandb/wandb/google/latest) * [Documentation du module Azure](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest)

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 : 1. 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/` 2. 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**. Accès à la System console W\&B recommande de suivre les étapes ci-dessous pour accéder à la console uniquement si l’option 1 ne fonctionne pas. 1. 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 : Accès direct à la System console 2. Récupérez le mot de passe dans le secret Kubernetes généré lors de l’installation : ```shell theme={"system"} kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d ``` Copiez le mot de passe. 3. 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](#migrate-self-managed-instances-to-wb-operator) 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. 1. Mettez à jour le dépôt avec [`helm repo update`](https://helm.sh/docs/helm/helm_repo_update/) : ```shell theme={"system"} helm repo update ``` 2. Mettez à jour le chart Helm avec [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/) : ```shell theme={"system"} 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](/fr/products/wandb/platform/hosting/self-managed/operator) et [isolés du réseau](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped). 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](mailto:forge-support@coreweave.com) ou votre équipe W\&B si vous avez des questions sur la compatibilité ou sur la topologie de votre déploiement. 1. 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. 2. Préparez la maintenance. Avant de commencer la mise à niveau, vous pouvez exécuter le [vérificateur de mise à niveau de MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html) 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. 3. 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. 4. Mettez à niveau MySQL vers 8.4.x conformément à la documentation de votre distribution MySQL. 5. Redémarrez MySQL et vérifiez qu’il est opérationnel. 6. 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](#verify-the-installation). 7. 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](/fr/release-notes/server-releases).

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](mailto:forge-support@coreweave.com) 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](#migrate-to-operator-based-aws-terraform-modules) * [Google Cloud](#migrate-to-operator-based-google-cloud-terraform-modules) * [Azure](#migrate-to-operator-based-azure-terraform-modules) * Si vous avez utilisé le [chart Helm W\&B sans opérateur](https://github.com/wandb/helm-charts/tree/main/charts/wandb), consultez [Migrer vers le chart Helm basé sur l’opérateur](#migrate-to-operator-based-helm-chart). * Si vous avez utilisé le [chart Helm W\&B sans opérateur avec Terraform](https://registry.terraform.io/modules/wandb/wandb/kubernetes/latest), consultez [Migrer vers le chart Helm Terraform basé sur l’opérateur](#migrate-to-operator-based-terraform-helm-chart). * Si vous avez créé les ressources Kubernetes à l’aide de manifestes, consultez [Migrer vers le chart Helm basé sur l’opérateur](#migrate-to-operator-based-helm-chart).

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](https://github.com/wandb/helm-charts/tree/main/charts/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](mailto:forge-support@coreweave.com) 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](mailto:forge-support@coreweave.com) 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 : 1. 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 : ```shell theme={"system"} helm get values wandb ``` Si vous avez déployé W\&B avec des manifestes Kubernetes, exportez les valeurs comme suit : ```shell theme={"system"} kubectl get deployment wandb -o yaml ``` Vous disposez maintenant de toutes les valeurs de configuration nécessaires pour l’étape suivante. 2. Créez un fichier nommé `operator.yaml`. Respectez le format décrit dans la [Référence de configuration](#configuration-reference-for-wb-operator). Utilisez les valeurs obtenues à l’étape 1. 3. Réduisez le déploiement actuel à 0 pod. Cette opération arrête le déploiement actuel. ```shell theme={"system"} kubectl scale --replicas=0 deployment wandb ``` 4. Mettez à jour le dépôt du chart Helm : ```shell theme={"system"} helm repo update ``` 5. Installez le nouveau chart Helm : ```shell theme={"system"} helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace ``` 6. Configurez le nouveau chart Helm et déclenchez le déploiement de l’application W\&B. Appliquez la nouvelle configuration. ```shell theme={"system"} kubectl apply -f operator.yaml ``` Le déploiement prend quelques minutes. 7. Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de la section [Vérifier l’installation](#verify-the-installation). 8. 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 : 1. 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](#deploy-wb-with-helm-terraform-module). Définissez les mêmes variables qu’auparavant. Si vous disposez d’un fichier `.tfvars`, ne le modifiez pas. 2. Exécutez Terraform. Exécutez `terraform init`, `terraform plan` et `terraform apply`. 3. Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de la section [Vérifier l’installation](#verify-the-installation). 4. 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](#how-it-works). 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](/fr/products/wandb/platform/hosting/env-vars) et [avancées](/fr/products/wandb/platform/hosting/iam/advanced_env_vars). 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](#complete-example). 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. ```yaml theme={"system"} 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:// license: eyJhbGnUzaH...j9ZieKQ2x5GGfw bucket:
mysql: ingress: annotations: ``` Vous trouverez l’ensemble complet des valeurs dans le [dépôt Helm W\&B](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml). **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 : ```yaml theme={"system"} 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

```yaml theme={"system"} # 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** ```yaml theme={"system"} global: bucket: provider: "s3" name: "" kmsKey: "" region: "" ``` **Google Cloud** ```yaml theme={"system"} global: bucket: provider: "gcs" name: "" ``` **Azure** ```yaml theme={"system"} 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 : ```yaml theme={"system"} 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 : ```yaml theme={"system"} 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

```yaml theme={"system"} 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 : ```yaml theme={"system"} 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

```yaml theme={"system"} global: # Licence d’exemple, remplacez-la par la vôtre license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi ``` Pour référencer la `license` à partir d’un secret : ```yaml theme={"system"} global: licenseSecret: name: license-secret key: CUSTOMER_WANDB_LICENSE ```

Ingress

Voir [Comment identifier la classe d’ingress Kubernetes](#how-to-identify-the-kubernetes-ingress-class). **Sans TLS** ```yaml theme={"system"} 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 ```console theme={"system"} 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 ```yaml theme={"system"} 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: - ``` Pour Nginx, vous devrez peut-être ajouter l’annotation suivante : ```yaml theme={"system"} 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é : ```yaml theme={"system"} 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` : ```yaml theme={"system"} 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. : ```yaml theme={"system"} 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 : ```yaml theme={"system"} app: serviceAccount: name: custom-service-account create: false console: serviceAccount: name: another-custom-service-account create: true global: ... ```

Redis externe

```yaml theme={"system"} redis: install: false global: redis: host: "" port: 6379 password: "" parameters: {} caCert: "" ``` Pour faire référence au `password` d’un secret : ```console theme={"system"} kubectl create secret generic redis-secret --from-literal=redis-password=supersecret ``` Faites-y référence dans la configuration suivante : ```yaml theme={"system"} 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` : ```yaml theme={"system"} 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 ``` Cette approche héritée n’est plus recommandée. Cette section est fournie à titre de référence. **Sans TLS** ```yaml theme={"system"} global: ldap: enabled: true # Adresse du serveur LDAP, y compris « ldap:// » ou « ldaps:// » host: # Base de recherche LDAP à utiliser pour trouver les utilisateurs baseDN: # Utilisateur LDAP avec lequel effectuer la liaison (si la liaison anonyme n’est pas utilisée) bindDN: # Nom et clé du secret contenant le mot de passe LDAP pour la liaison (si la liaison anonyme n’est pas utilisée) bindPW: # Noms des attributs LDAP pour l’e-mail et l’ID de groupe, sous forme de chaînes séparées par des virgules. attributes: # Liste d’autorisation des groupes LDAP groupAllowList: # Activer TLS pour LDAP tls: false ``` **Avec TLS** La configuration du certificat TLS LDAP nécessite une ConfigMap créée au préalable avec le contenu du certificat. Pour créer la ConfigMap, vous pouvez utiliser la commande suivante : ```console theme={"system"} kubectl create configmap ldap-tls-cert --from-file=certificate.crt ``` Utilisez ensuite la ConfigMap dans le YAML, comme dans l’exemple suivant. ```yaml theme={"system"} global: ldap: enabled: true # Adresse du serveur LDAP, y compris « ldap:// » ou « ldaps:// » host: # Base de recherche LDAP à utiliser pour trouver les utilisateurs baseDN: # Utilisateur LDAP avec lequel effectuer la liaison (si la liaison anonyme n’est pas utilisée) bindDN: # Nom et clé du secret contenant le mot de passe LDAP pour la liaison (si la liaison anonyme n’est pas utilisée) bindPW: # Noms des attributs LDAP pour l’e-mail et l’ID de groupe, sous forme de chaînes séparées par des virgules. attributes: # Liste d’autorisation des groupes LDAP groupAllowList: # Activer TLS pour LDAP tls: true # Nom et clé de la ConfigMap contenant le certificat CA du serveur LDAP tlsCert: configMap: name: "ldap-tls-cert" key: "certificate.crt" ```

SSO OIDC

```yaml theme={"system"} global: auth: sessionLengthHours: 720 oidc: clientId: "" secret: "" # À inclure uniquement si votre IdP l’exige. authMethod: "" issuer: "" ``` `authMethod` est facultatif.

SMTP

```yaml theme={"system"} global: email: smtp: host: "" port: 587 user: "" password: "" ```

Variables d’environnement

```yaml theme={"system"} 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. Pour activer la limitation de débit, vous devez définir `GORILLA_LIMITER` sur l’adresse de votre serveur Redis. ```yaml theme={"system"} 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. ```yaml theme={"system"} 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 : ```yaml theme={"system"} global: caCertsConfigMap: custom-ca-certs ``` Le ConfigMap doit se présenter comme suit : ```yaml theme={"system"} 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 : ```yaml theme={"system"} 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 : ```yaml theme={"system"} 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](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml).

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`). ```yaml theme={"system"} 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 : ```yaml theme={"system"} caCertsConfigMap: custom-ca-certs ``` La ConfigMap doit se présenter comme suit : ```yaml theme={"system"} 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](#access-the-wb-management-console).

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 : ```console theme={"system"} 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](#access-the-wb-management-console).

Comment consulter les journaux du serveur W\&B

Le pod de l’application s’appelle **wandb-app-xxx**. ```console theme={"system"} 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 ```console theme={"system"} kubectl get ingressclass ```