> ## 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 dans des environnements Kubernetes isolés du réseau et déconnectés # Déployer sur un cluster Kubernetes isolé du réseau

Introduction

Ce guide fournit des instructions détaillées pour déployer la W\&B Platform dans des environnements gérés par le client, qu’ils soient isolés du réseau, déconnectés ou à accès réseau restreint. En suivant ce guide, vous configurez un registre de conteneurs interne et un dépôt Helm pour héberger les images et les charts W\&B, vous installez l’opérateur Kubernetes W\&B, puis vous déployez la W\&B Platform sans aucune connexion Internet sortante. Ce guide s’adresse aux administrateurs de plateforme et aux ingénieurs DevOps qui gèrent une infrastructure Kubernetes dans des réseaux réglementés ou isolés. Les déploiements isolés du réseau sont courants dans les environnements suivants : * Installations gouvernementales sécurisées. * Institutions financières soumises à une isolation réseau stricte. * Organismes de santé soumis à des exigences de conformité. * Environnements de systèmes de contrôle industriels (ICS). * Centres de recherche disposant de réseaux classifiés. Exécutez ces commandes dans une console shell disposant des accès appropriés au cluster Kubernetes. Vous pouvez les adapter à n’importe quel outil CI/CD que vous utilisez pour déployer des applications Kubernetes. Pour un déploiement Kubernetes sur site standard avec connexion Internet, consultez [Déployer W\&B avec l’opérateur Kubernetes](/fr/products/wandb/platform/hosting/self-managed/operator).

Prérequis

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

Exigences de version

| Logiciel | Version minimale | | - | - | | Kubernetes | v1.34 ou ultérieure ([Versions de Kubernetes prises en charge](https://kubernetes.io/releases/patch-releases/)) | | Helm | v3.x | | MySQL | Les déploiements W\&B autogérés doivent exécuter une version de MySQL prise en charge qui bénéficie des patchs de sécurité et des corrections de bugs critiques. Installez **MySQL 8.4.x** ou effectuez une mise à niveau vers cette version, ou utilisez une version de service managé que votre fournisseur indique comme prise en charge et maintenue à jour.
Les chaînes de version d’Aurora MySQL diffèrent de celles des versions communautaires de MySQL. Utilisez `SELECT version()` pour afficher la chaîne de version complète du moteur et `SELECT aurora_version()` pour afficher la version d’Aurora. [Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) est compatible avec MySQL 8.0.x et reste prise en charge. Pour choisir une version cible, consultez [Gestion des versions d’Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.Versioning.html) ainsi que la documentation de votre fournisseur de cloud. | | Redis | v7.x | | ClickHouse | Requis pour Weave sur les déploiements autogérés. Non requis si votre déploiement n’utilise pas Weave. Voir [Compatibilité de ClickHouse pour les mises à niveau](/fr/products/wandb/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) et [Versions du serveur W\&B prises en charge](/fr/release-notes/server-releases). |

Exigences SSL/TLS

W\&B nécessite un certificat SSL/TLS valide et signé pour sécuriser les communications entre les clients et le serveur. La terminaison SSL/TLS doit être effectuée au niveau de l’ingress ou de l’équilibreur de charge. L’application serveur W\&B n’assure pas la terminaison des connexions SSL ou TLS. W\&B ne prend pas en charge les certificats autosignés ni les autorités de certification (CA) personnalisées. Les certificats autosignés posent des problèmes aux utilisateurs et ne sont pas pris en charge. Dans la mesure du possible, utilisez un service comme [Let's Encrypt](https://letsencrypt.org) pour fournir des certificats de confiance à votre équilibreur de charge. Des services comme Caddy et Cloudflare gèrent le SSL pour vous. Si vos politiques de sécurité exigent des communications SSL au sein de vos réseaux de confiance, envisagez d’utiliser un outil comme Istio avec des [conteneurs sidecar](https://istio.io/latest/docs/reference/config/networking/sidecar/).

Exigences matérielles

**Architecture CPU** : W\&B fonctionne uniquement sur une architecture CPU Intel (x86). ARM n’est pas pris en charge. **Dimensionnement** : pour connaître les recommandations de dimensionnement du CPU, de la mémoire et du disque des nœuds Kubernetes et de MySQL, consultez la [section Dimensionnement](/fr/products/wandb/platform/hosting/self-managed/ref-arch#sizing) de l’architecture de référence. Les exigences varient selon que vous exécutez Models, Weave ou les deux.

Base de données MySQL

W\&B nécessite une base de données MySQL externe. 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 connaître les paramètres de configuration MySQL des instances autogérées, consultez la [section Configuration MySQL de l’architecture de référence](/fr/products/wandb/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters).

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

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). Pour obtenir des instructions détaillées sur le provisionnement du stockage d’objets, consultez le guide [Bring Your Own Bucket (BYOB)](/fr/products/wandb/platform/hosting/data-security/secure-storage-connector). Dans les environnements isolés du réseau, vous utiliserez généralement un stockage compatible S3 sur site, comme MinIO Enterprise, NetApp StorageGRID ou Dell ECS.

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

Outre les exigences standard mentionnées ci-dessus, les déploiements isolés du réseau nécessitent les éléments suivants : * **Registre de conteneurs interne** : accès à un registre de conteneurs privé tel que Harbor, JFrog Artifactory ou Nexus, contenant toutes les images W\&B requises. * **Dépôt Helm interne** : accès à un dépôt de charts Helm privé contenant les charts Helm W\&B. * **Moyen de transfert d’images** : une méthode permettant de transférer des images de conteneur depuis un système connecté à Internet vers votre registre isolé du réseau. * **Fichier de licence** : une licence W\&B Enterprise valide. Pour obtenir une licence (par exemple depuis une machine connectée à Internet), consultez la section [License](/fr/products/wandb/platform/hosting/self-managed/requirements#license) de la page des exigences, ou contactez votre équipe de compte W\&B. Pour connaître l’ensemble des exigences d’infrastructure, y compris la configuration du réseau et de l’équilibreur de charge, consultez l’[architecture de référence](/fr/products/wandb/platform/hosting/self-managed/ref-arch#infrastructure-requirements).

Préparer votre environnement isolé du réseau

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

Étape 1 : Configurer un registre de conteneurs interne

Comme le cluster Kubernetes ne peut pas récupérer d’images depuis des registres publics, toutes les images de conteneur requises doivent être disponibles dans votre registre de conteneurs interne isolé du réseau avant le déploiement. Il vous incombe de suivre les exigences du W\&B Operator et de mettre régulièrement à jour les images de votre registre de conteneurs. Pour obtenir la liste à jour des images de conteneur requises et de leurs versions, reportez-vous au chart Helm, ou contactez l’[assistance W\&B](mailto:forge-support@coreweave.com) ou l’ingénieur d’assistance W\&B qui vous a été attribué.

Conteneurs des composants principaux de W\&B

Les images principales suivantes sont requises : * [`docker.io/wandb/controller`](https://hub.docker.com/r/wandb/controller) : opérateur Kubernetes W\&B. * [`docker.io/wandb/local`](https://hub.docker.com/r/wandb/local) : serveur d’applications W\&B. * [`docker.io/wandb/console`](https://hub.docker.com/r/wandb/console) : console d’administration W\&B. * [`docker.io/wandb/megabinary`](https://hub.docker.com/r/wandb/megabinary) : microservices W\&B (API, executor, glue, parquet).

Conteneurs de dépendances

Les images de dépendances tierces suivantes sont requises : * [`docker.io/bitnamilegacy/redis`](https://hub.docker.com/r/bitnamilegacy/redis) : requise pour le déploiement local de Redis lors des tests et du développement. Pour connaître les exigences relatives à Redis en production, consultez la [section Redis](#redis) des prérequis. * [`docker.io/otel/opentelemetry-collector-contrib`](https://hub.docker.com/r/otel/opentelemetry-collector-contrib) : agent OpenTelemetry chargé de collecter les métriques et les journaux. * [`quay.io/prometheus/prometheus`](https://quay.io/repository/prometheus/prometheus) : Prometheus, pour la collecte des métriques. * [`quay.io/prometheus-operator/prometheus-config-reloader`](https://quay.io/repository/prometheus-operator/prometheus-config-reloader) : dépendance de Prometheus.

Obtenir la liste complète des images

Pour extraire du chart Helm la liste complète des images requises et de leurs versions : 1. Sur un système connecté à Internet, téléchargez les charts Helm W\&B depuis le [dépôt des charts Helm W\&B](https://github.com/wandb/helm-charts) : ```bash theme={"system"} # Cloner le dépôt helm-charts git clone https://github.com/wandb/helm-charts.git cd helm-charts ``` 2. Examinez les fichiers `values.yaml` pour identifier toutes les images de conteneur et leurs versions : ```bash theme={"system"} # Extraire les références d'images du chart de l'opérateur helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#" # Extraire les références d'images du chart de la plateforme helm show values charts/operator-wandb | grep -E "repository:|tag:" | grep -v "^#" ``` Vous pouvez également utiliser cette commande pour extraire uniquement les noms de dépôts (sans les tags de version) : ```bash theme={"system"} helm show values charts/operator-wandb \ | awk -F': *' '/^[[:space:]]*repository:/{print $2}' \ | grep -v "^#" \ | sort -u ``` La liste des dépôts se présente comme suit : ```text theme={"system"} wandb/controller wandb/local wandb/console wandb/megabinary wandb/weave-python wandb/weave-trace otel/opentelemetry-collector-contrib prometheus/prometheus prometheus-operator/prometheus-config-reloader bitnamilegacy/redis ``` Pour obtenir le tag de version précis de chaque image, utilisez la première commande ci-dessus (`grep -E "repository:|tag:"`), qui affiche à la fois les noms de dépôts et les tags de version correspondants.

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

1. Sur un système connecté à Internet, récupérez (pull) et enregistrez toutes les images requises. Dans les exemples suivants, remplacez les numéros de version par les versions réelles relevées lors de l’inspection de votre chart Helm à l’étape précédente. Les versions indiquées ici ne sont que des exemples et deviendront obsolètes avec le temps. Utilisez des variables shell pour gérer les versions de manière cohérente : ```bash theme={"system"} # Définir les variables de version (mettez-les à jour en fonction des versions de votre chart Helm) CONTROLLER_VERSION="1.13.3" APP_VERSION="0.59.2" CONSOLE_VERSION="2.12.2" # Récupérer les images docker pull wandb/controller:${CONTROLLER_VERSION} docker pull wandb/local:${APP_VERSION} docker pull wandb/console:${CONSOLE_VERSION} docker pull wandb/megabinary:${APP_VERSION} # ... récupérer toutes les autres images requises avec leurs versions # Enregistrer les images dans des fichiers .tar docker save wandb/controller:${CONTROLLER_VERSION} -o wandb-controller-${CONTROLLER_VERSION}.tar docker save wandb/local:${APP_VERSION} -o wandb-local-${APP_VERSION}.tar docker save wandb/console:${CONSOLE_VERSION} -o wandb-console-${CONSOLE_VERSION}.tar docker save wandb/megabinary:${APP_VERSION} -o wandb-megabinary-${APP_VERSION}.tar # ... enregistrer toutes les autres images ``` 2. Transférez les fichiers `.tar` vers votre environnement isolé du réseau par la méthode approuvée au sein de votre organisation, par exemple une clé USB ou un transfert de fichiers sécurisé. 3. Dans votre environnement isolé du réseau, chargez les images et téléversez-les vers votre registre interne : ```bash theme={"system"} # Définir les mêmes variables de version que ci-dessus CONTROLLER_VERSION="1.13.3" APP_VERSION="0.59.2" CONSOLE_VERSION="2.12.2" INTERNAL_REGISTRY="registry.yourdomain.com" # Charger les images docker load -i wandb-controller-${CONTROLLER_VERSION}.tar docker load -i wandb-local-${APP_VERSION}.tar docker load -i wandb-console-${CONSOLE_VERSION}.tar docker load -i wandb-megabinary-${APP_VERSION}.tar # ... charger toutes les autres images # Étiqueter pour le registre interne docker tag wandb/controller:${CONTROLLER_VERSION} ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION} docker tag wandb/local:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION} docker tag wandb/console:${CONSOLE_VERSION} ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION} docker tag wandb/megabinary:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION} # ... étiqueter toutes les autres images # Téléverser vers le registre interne docker push ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION} docker push ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION} docker push ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION} docker push ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION} # ... téléverser toutes les autres images ```

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

Une fois les images de conteneur en place, l’opérateur Kubernetes doit également avoir accès aux charts Helm W\&B. Vérifiez que les charts Helm suivants sont disponibles dans votre dépôt Helm interne : * [Chart W\&B Operator](https://github.com/wandb/helm-charts/tree/main/charts/operator) * [Chart W\&B Platform](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb) 1. Sur un système connecté à Internet, téléchargez les charts : ```bash theme={"system"} # Ajouter le dépôt Helm W&B helm repo add wandb https://wandb.github.io/helm-charts helm repo update # Télécharger les charts helm pull wandb/operator --version 1.13.3 helm pull wandb/operator-wandb --version 0.18.0 ``` 2. Transférez les fichiers de charts `.tgz` vers votre environnement isolé du réseau, puis téléversez-les dans votre dépôt Helm interne en suivant les procédures propres à ce dépôt. Le chart `operator` déploie l’opérateur Kubernetes W\&B (gestionnaire de contrôleurs). Le chart `operator-wandb` déploie W\&B Platform à partir des valeurs configurées dans la ressource personnalisée (CR).

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

Dans l’environnement isolé du réseau, configurez votre client Helm local pour qu’il pointe vers votre dépôt interne, afin que les commandes d’installation suivantes puissent trouver les charts. 1. Dans votre environnement isolé du réseau, configurez Helm pour qu’il utilise votre dépôt interne : ```bash theme={"system"} helm repo add local-repo https://charts.yourdomain.com helm repo update ``` 2. Vérifiez que les charts sont disponibles : ```bash theme={"system"} helm search repo local-repo/operator helm search repo local-repo/operator-wandb ```

Déployer W\&B dans un environnement isolé du réseau

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

Étape 4 : installer l’opérateur Kubernetes

L’opérateur Kubernetes W\&B (gestionnaire de contrôleurs) gère les composants de la W\&B Platform. Pour l’installer dans un environnement isolé du réseau, configurez-le pour qu’il utilise votre registre de conteneurs interne. 1. Créez un fichier `values.yaml` avec le contenu suivant : ```yaml theme={"system"} image: repository: registry.yourdomain.com/wandb/controller tag: 1.13.3 airgapped: true ``` Remplacez le dépôt et le tag par les versions que vous avez réellement transférées vers votre registre interne à l’étape 1. La version indiquée ici (`1.13.3`) n’est qu’un exemple et finira par devenir obsolète. 2. Installez l’opérateur et la Custom Resource Definition (CRD) : ```bash theme={"system"} helm upgrade --install operator local-repo/operator \ --namespace wandb \ --create-namespace \ --values values.yaml ``` 3. Vérifiez que l’opérateur est en cours d’exécution : ```bash theme={"system"} kubectl get pods -n wandb ``` Le pod de l’opérateur doit apparaître à l’état `Running`. L’opérateur Kubernetes W\&B est maintenant installé et prêt à déployer la W\&B Platform à partir de votre dépôt de charts interne. Pour obtenir la description complète des valeurs prises en charge, reportez-vous au [fichier de valeurs du dépôt GitHub de l’opérateur Kubernetes](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml).

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

Avant de configurer la Ressource personnalisée W\&B, mettez en place une base de données MySQL externe. Pour les déploiements en production, W\&B recommande vivement d’utiliser des services de base de données managés lorsqu’ils sont disponibles. Toutefois, si vous exécutez votre propre instance MySQL, créez la base de données et l’utilisateur : Créez une base de données et un utilisateur à l’aide des commandes SQL suivantes. Remplacez `[PASSWORD]` par un mot de passe sécurisé : ```sql theme={"system"} CREATE USER 'wandb_local'@'%' IDENTIFIED BY '[PASSWORD]'; CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION; ``` Pour les paramètres de configuration MySQL, consultez la [section Configuration MySQL de l’architecture de référence](/fr/products/wandb/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters).

Étape 6 : configurer la Ressource personnalisée W\&B

Après avoir installé l’opérateur Kubernetes W\&B, configurez la Ressource personnalisée (CR) pour qu’elle pointe vers votre dépôt Helm interne et votre registre de conteneurs. Cette configuration permet à l’opérateur Kubernetes d’utiliser votre registre et votre dépôt internes lors du déploiement des composants requis de la W\&B Platform, plutôt que de tenter d’accéder à des sources publiques. L’exemple de configuration suivant contient des tags de version d’image qui deviennent obsolètes avec le temps. Remplacez toutes les valeurs `tag:` par les versions que vous avez effectivement transférées vers votre registre interne à l’étape 1. Créez un fichier nommé `wandb.yaml` avec le contenu suivant : ```yaml theme={"system"} apiVersion: apps.wandb.com/v1 kind: WeightsAndBiases metadata: labels: app.kubernetes.io/instance: wandb app.kubernetes.io/name: weightsandbiases name: wandb namespace: wandb spec: chart: url: https://charts.yourdomain.com name: operator-wandb version: 0.18.0 values: global: host: https://wandb.yourdomain.com license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bucket: accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: s3.yourdomain.com:9000 path: wandb provider: s3 region: us-east-1 mysql: database: wandb host: mysql.yourdomain.com password: [YOUR-MYSQL-PASSWORD] port: 3306 user: wandb redis: host: redis.yourdomain.com port: 6379 password: [YOUR-REDIS-PASSWORD] api: enabled: true glue: enabled: true executor: enabled: true extraEnv: ENABLE_REGISTRY_UI: 'true' # Configurer les images de tous les composants pour qu’elles utilisent le registre interne app: image: repository: registry.yourdomain.com/wandb/local tag: 0.59.2 console: image: repository: registry.yourdomain.com/wandb/console tag: 2.12.2 api: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 executor: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 glue: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 parquet: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 weave: image: repository: registry.yourdomain.com/wandb/weave-python tag: 0.59.2 otel: image: repository: registry.yourdomain.com/otel/opentelemetry-collector-contrib tag: 0.97.0 prometheus: server: image: repository: registry.yourdomain.com/prometheus/prometheus tag: v2.47.0 configmapReload: prometheus: image: repository: registry.yourdomain.com/prometheus-operator/prometheus-config-reloader tag: v0.67.0 ingress: annotations: nginx.ingress.kubernetes.io/proxy-body-size: "0" class: nginx ``` Remplacez toutes les valeurs d’espace réservé, telles que les noms d’hôte, les mots de passe et les tags, par vos propres valeurs de configuration. L’exemple précédent présente les composants les plus couramment utilisés. Selon les besoins de votre déploiement, vous devrez peut-être également configurer des dépôts d’images pour d’autres composants, par exemple : * `settingsMigrationJob` * `weave-trace` * `filestream` * `flat-runs-table` Reportez-vous au [fichier de valeurs du dépôt Helm de W\&B](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml) pour obtenir la liste complète des composants configurables.

Étape 7 : Déployer la W\&B Platform

L’application de la ressource personnalisée déclenche l’installation, par l’opérateur, des composants de la W\&B Platform définis dans le chart `operator-wandb`, à partir de la configuration et des références d’image fournies dans `wandb.yaml`. 1. Appliquez la ressource personnalisée W\&B pour déployer la plateforme : ```bash theme={"system"} kubectl apply -f wandb.yaml ``` 2. Surveillez la progression du déploiement : ```bash theme={"system"} # Suivre la création des pods kubectl get pods -n wandb --watch # Vérifier le statut du déploiement kubectl get weightsandbiases -n wandb # Afficher les journaux de l’opérateur kubectl logs -n wandb deployment/wandb-operator-controller-manager ``` Le déploiement peut prendre plusieurs minutes, le temps que l’opérateur crée tous les composants nécessaires.

Configuration d’OpenShift

W\&B prend en charge le déploiement sur des clusters Kubernetes OpenShift isolés du réseau. Les déploiements OpenShift nécessitent des configurations de contexte de sécurité supplémentaires, car les politiques de sécurité d’OpenShift sont plus strictes. Si vous déployez sur OpenShift, appliquez les configurations de cette section en plus des étapes précédentes.

Contraintes de contexte de sécurité OpenShift

OpenShift utilise des Security Context Constraints (SCC) pour contrôler les autorisations des pods. Par défaut, OpenShift attribue la SCC `restricted` aux pods, ce qui interdit l’exécution en tant que root et impose des ID utilisateur spécifiques. Configurez les composants W\&B pour qu’ils s’exécutent avec la SCC restricted en définissant les contextes de sécurité appropriés dans votre Ressource personnalisée : ```yaml theme={"system"} spec: values: # Configurer les contextes de sécurité de tous les pods app: podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault console: podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault # Procéder de même pour les autres composants : api, executor, glue, parquet, weave ```

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

Si votre déploiement requiert des capacités qui ne sont pas disponibles dans la SCC `restricted`, créez une SCC personnalisée : ```yaml theme={"system"} apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: wandb-scc allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: false allowPrivilegedContainer: false allowedCapabilities: [] defaultAddCapabilities: [] fsGroup: type: MustRunAs ranges: - min: 1000 max: 65535 readOnlyRootFilesystem: false requiredDropCapabilities: - ALL runAsUser: type: MustRunAsRange uidRangeMin: 1000 uidRangeMax: 65535 seLinuxContext: type: MustRunAs supplementalGroups: type: RunAsAny volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret ``` 1. Appliquez la SCC : ```bash theme={"system"} oc apply -f wandb-scc.yaml ``` 2. Associez la SCC aux comptes de service W\&B : ```bash theme={"system"} oc adm policy add-scc-to-user wandb-scc -z wandb-app -n wandb oc adm policy add-scc-to-user wandb-scc -z wandb-console -n wandb ```

Routes OpenShift

OpenShift utilise des Routes au lieu de l’Ingress Kubernetes standard. Configurez W\&B pour qu’il utilise les Routes OpenShift : ```yaml theme={"system"} spec: values: ingress: enabled: false route: enabled: true host: wandb.apps.openshift.yourdomain.com tls: enabled: true termination: edge insecureEdgeTerminationPolicy: Redirect ```

Configuration de la récupération d’images pour OpenShift

Si votre cluster OpenShift utilise un registre d’images interne avec authentification : 1. Créez un secret de récupération d’image (image pull secret) : ```bash theme={"system"} kubectl create secret docker-registry wandb-registry-secret \ --docker-server=registry.yourdomain.com \ --docker-username=[USERNAME] \ --docker-password=[PASSWORD] \ --namespace=wandb ``` 2. Référencez le secret dans votre ressource personnalisée (Custom Resource) : ```yaml theme={"system"} spec: values: imagePullSecrets: - name: wandb-registry-secret ```

Exemple complet pour OpenShift

L’exemple suivant présente une CR complète pour un déploiement OpenShift isolé du réseau : Remplacez toutes les valeurs `tag:` de cet exemple par les versions que vous avez réellement transférées vers votre registre interne à l’étape 1. Les versions indiquées ne sont données qu’à titre d’exemple et deviendront obsolètes avec le temps. ```yaml theme={"system"} apiVersion: apps.wandb.com/v1 kind: WeightsAndBiases metadata: name: wandb namespace: wandb spec: chart: url: https://charts.yourdomain.com name: operator-wandb version: 0.18.0 values: global: host: https://wandb.apps.openshift.yourdomain.com license: [YOUR-LICENSE] bucket: accessKey: [YOUR-ACCESS-KEY] secretKey: [YOUR-SECRET-KEY] name: s3.yourdomain.com:9000 path: wandb provider: s3 region: us-east-1 mysql: database: wandb host: mysql.yourdomain.com password: [YOUR-MYSQL-PASSWORD] port: 3306 user: wandb redis: host: redis.yourdomain.com port: 6379 password: [YOUR-REDIS-PASSWORD] # Spécifique à OpenShift : utiliser des Routes au lieu d’un Ingress ingress: enabled: false route: enabled: true host: wandb.apps.openshift.yourdomain.com tls: enabled: true termination: edge # Secret de récupération d’image pour le registre interne imagePullSecrets: - name: wandb-registry-secret # Contextes de sécurité pour la SCC restricted d’OpenShift app: image: repository: registry.yourdomain.com/wandb/local tag: 0.59.2 podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault console: image: repository: registry.yourdomain.com/wandb/console tag: 2.12.2 podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault # Répéter les contextes de sécurité pour : api, executor, glue, parquet, weave # (exemple abrégé pour plus de clarté) ``` Contactez l’[assistance W\&B](mailto:forge-support@coreweave.com) ou l’ingénieur d’assistance W\&B qui vous a été attribué pour obtenir des exemples complets de configuration OpenShift adaptés à vos exigences en matière de sécurité.

Vérifier votre installation

Après avoir déployé W\&B, vérifiez que l’installation fonctionne correctement afin de vous assurer que la plateforme est accessible, que les pods sont opérationnels et que le déploiement utilise uniquement vos ressources internes. Suivez les étapes de vérification générales, puis effectuez les vérifications supplémentaires propres aux environnements isolés du réseau, décrites dans la section suivante. 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.

Vérifications supplémentaires pour les environnements isolés du réseau

Pour les déploiements isolés du réseau, vérifiez également les points suivants : 1. **Récupération d’image** : vérifiez que tous les pods ont bien récupéré leurs images depuis votre registre interne : ```bash theme={"system"} kubectl get pods -n wandb -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[*].image}{"\n"}{end}' ``` Toutes les images doivent pointer vers votre registre interne et tous les pods doivent être à l’état `Running`. 2. **Connectivité externe** : vérifiez que W\&B ne tente pas d’établir de connexions externes (ce qui ne doit pas se produire en mode isolé du réseau) : ```bash theme={"system"} kubectl logs -n wandb deployment/wandb-app --tail=100 | grep -i "connection" ``` 3. **Validation de la licence** : accédez à la console W\&B et vérifiez que votre licence est active.

Dépannage

Erreurs de récupération d’image

Si les pods ne parviennent pas à récupérer les images, vérifiez les points suivants : * Assurez-vous que les images existent bien dans votre registre interne. * Vérifiez que le secret de récupération d’image est correctement configuré. * Contrôlez la connectivité réseau entre les nœuds Kubernetes et le registre. * Vérifiez les identifiants d’authentification du registre. Pour tester manuellement la récupération d’une image : ```bash theme={"system"} kubectl run test-pull --image=registry.yourdomain.com/wandb/local:0.59.2 --namespace=wandb kubectl logs test-pull -n wandb kubectl delete pod test-pull -n wandb ```

Erreurs SCC OpenShift

Si des pods échouent en raison d'erreurs d'autorisation sur OpenShift : ```bash theme={"system"} # Vérifier quelle SCC est utilisée oc get pod [POD-NAME] -n wandb -o yaml | grep scc # Vérifier les autorisations du compte de service oc describe scc wandb-scc oc get rolebinding -n wandb ```

Chart Helm introuvable

Si l’opérateur ne parvient pas à trouver le chart de la plateforme, effectuez les vérifications suivantes : * Vérifiez l’URL du dépôt de charts dans la Ressource personnalisée. * Assurez-vous que le pod de l’opérateur peut accéder à votre dépôt Helm interne. * Vérifiez que le chart existe bien dans votre dépôt : ```bash theme={"system"} helm search repo local-repo/operator-wandb ```

Questions fréquentes

Puis-je utiliser une autre classe d’ingress ?

Oui. Pour configurer votre classe d’ingress, modifiez les paramètres d’ingress dans votre Ressource personnalisée : ```yaml theme={"system"} spec: values: ingress: class: your-ingress-class ```

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

Séparez les certificats en plusieurs entrées dans la section `customCACerts` : ```yaml theme={"system"} spec: values: customCACerts: cert1.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- cert2.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ```

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

Pour que l’opérateur ne mette pas automatiquement à jour W\&B, procédez comme suit : * Définissez `airgapped: true` dans l’installation de l’opérateur (cela désactive la vérification automatique des mises à jour). * Gérez les mises à jour de version en modifiant manuellement `spec.chart.version` dans votre ressource personnalisée. * Vous pouvez également désactiver les mises à jour automatiques depuis la System Console de W\&B. Pour plus de détails, voir [Désactiver les mises à jour automatiques de la version de l’application](/fr/products/wandb/platform/hosting/self-managed/disable-automatic-app-version-updates). W\&B recommande vivement aux clients disposant d’instances autogérées de mettre à jour leurs déploiements vers la dernière version au moins une fois par trimestre, afin de continuer à bénéficier de l’assistance ainsi que des dernières fonctionnalités, améliorations des performances et correctifs. W\&B prend en charge chaque version majeure pendant 12 mois à compter de sa date de publication initiale. Reportez-vous à [Politiques et processus de publication](/fr/release-notes/release-policies).

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

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

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

Pour mettre à jour W\&B : 1. Récupérez (pull) les nouvelles images de conteneur sur un système connecté à Internet. 2. Transférez les images vers votre registre isolé du réseau. 3. Téléversez les nouveaux charts Helm dans votre dépôt interne. 4. Mettez à jour `spec.chart.version` et les tags d’image dans votre ressource personnalisée. 5. Appliquez la ressource personnalisée mise à jour. L’opérateur effectue une mise à jour progressive (rolling update) des composants W\&B.

Étapes suivantes

Une fois le déploiement terminé, effectuez les tâches suivantes : * **Configurer l’authentification des utilisateurs** : configurez le [SSO](/fr/products/wandb/platform/hosting/iam/sso) ou d’autres méthodes d’authentification. * **Configurer la surveillance** : mettez en place la surveillance de votre instance W\&B et de votre infrastructure. * **Planifier les mises à jour** : consultez le [processus de mise à niveau du serveur](/fr/products/wandb/platform/hosting/server-upgrade-process) et définissez un rythme de mise à jour. * **Configurer les sauvegardes** : mettez en place des procédures de sauvegarde pour votre base de données MySQL. * **Documenter votre processus** : rédigez des runbooks décrivant vos procédures de mise à jour propres à votre environnement isolé du réseau.

Obtenir de l’aide

Si vous rencontrez des problèmes lors du déploiement : * Consultez l’[architecture de référence](/fr/products/wandb/platform/hosting/self-managed/ref-arch) pour obtenir des recommandations sur l’infrastructure. * Reportez-vous au [guide de l’opérateur](/fr/products/wandb/platform/hosting/self-managed/operator) pour en savoir plus sur la configuration. * Contactez l’[assistance W\&B](mailto:forge-support@coreweave.com) ou l’ingénieur d’assistance W\&B qui vous a été attribué. * Pour les problèmes propres à OpenShift, consultez la documentation Red Hat OpenShift.