> ## Documentation Index > Fetch the complete documentation index at: https://docs.wandb.ai/llms.txt > Use this file to discover all available pages before exploring further. > Déployer la plateforme W&B dans des environnements Kubernetes isolés du réseau et déconnectés # Déployer sur Kubernetes isolé du réseau
## Introduction
Ce guide fournit des instructions détaillées pour déployer la plateforme W\&B dans des environnements gérés par le client, isolés du réseau, déconnectés ou soumis à des restrictions réseau. En suivant ce guide, vous configurez un registre de conteneurs interne et un dépôt Helm pour héberger les images et charts W\&B, installez l’opérateur Kubernetes W\&B et déployez la plateforme W\&B sans nécessiter de connectivité Internet sortante. Ce guide s’adresse aux administrateurs de plateforme et aux ingénieurs DevOps qui gèrent une infrastructure Kubernetes dans des réseaux réglementés ou isolés. Les déploiements isolés du réseau sont courants dans les environnements suivants : * Les installations gouvernementales sécurisées. * Les établissements financiers soumis à une isolation réseau stricte. * Les organisations de santé soumises à des exigences de conformité. * Les environnements de systèmes de contrôle industriels (ICS). * Les centres de recherche disposant de réseaux classifiés. Exécutez ces commandes dans un terminal shell disposant d’un accès approprié au cluster Kubernetes. Vous pouvez adapter ces commandes à n’importe quel outil CI/CD utilisé pour déployer des applications Kubernetes. Pour les déploiements Kubernetes on-premises standard avec connectivité Internet, voir [Déployer W\&B avec l’opérateur Kubernetes](/fr/platform/hosting/self-managed/operator).
## Prérequis
Avant de commencer, assurez-vous que votre environnement isolé du réseau répond aux exigences suivantes.
### Versions requises
| Logiciel | Version minimale | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Kubernetes | v1.34 ou ultérieure ([Versions de Kubernetes prises en charge](https://kubernetes.io/releases/patch-releases/)) | | Helm | v3.x | | MySQL | Les déploiements W\&B Autogéré doivent utiliser une version prise en charge de MySQL qui reçoit des correctifs de sécurité et des corrections de bugs critiques. Installez ou mettez à niveau vers **MySQL 8.4.x**, ou utilisez une version de service géré que votre fournisseur indique comme prise en charge et corrigée.
Les chaînes de version d'Aurora MySQL diffèrent de celles de MySQL communautaire. Utilisez `SELECT version()` pour voir la chaîne complète de version du moteur et `SELECT aurora_version()` pour voir la version d'Aurora. La [version 3 d'Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) est compatible avec MySQL 8.0.x et reste prise en charge. Voir la [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 lorsque vous choisissez une version cible. | | Redis | v7.x |
### Prérequis SSL/TLS
W\&B exige un certificat SSL/TLS valide, signé par une autorité reconnue, pour sécuriser les communications entre les clients et le serveur. La terminaison SSL/TLS doit se faire au niveau de l’ingress ou de l’équilibreur de charge. L’application W\&B Server ne termine pas les connexions SSL ou TLS. W\&B ne prend pas en charge les certificats auto-signés ni les autorités de certification personnalisées. Les certificats auto-signés entraînent des problèmes pour les utilisateurs et ne sont pas pris en charge. Si possible, utilisez un service comme [Let's Encrypt](https://letsencrypt.org) pour fournir des certificats approuvés à votre équilibreur de charge. Des services comme Caddy et Cloudflare gèrent le SSL pour vous. Si vos politiques de sécurité exigent une communication SSL au sein de vos réseaux de confiance, envisagez d’utiliser un outil comme Istio et des [conteneurs sidecar](https://istio.io/latest/docs/reference/config/networking/sidecar/).
### Prérequis matériels
**Architecture CPU** : W\&B fonctionne uniquement sur des processeurs Intel (x86). ARM n’est pas pris en charge. **Dimensionnement** : Pour les recommandations de dimensionnement du processeur, de la mémoire et du disque pour les nœuds Kubernetes et MySQL, consultez la [section Dimensionnement](/fr/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. Pour la Production, W\&B recommande d’utiliser des services de base de données géré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 gérés offrent des sauvegardes automatisées, de la supervision, une haute disponibilité et l’application des correctifs, tout en réduisant la charge opérationnelle. Voir l’[architecture de référence](/fr/platform/hosting/self-managed/ref-arch/#mysql) pour connaître les exigences MySQL, y compris les recommandations de dimensionnement et les paramètres de configuration. Pour le SQL permettant de créer la base de données, consultez le [guide bare-metal](/fr/platform/hosting/self-managed/operator/#mysql-database). Pour toute question sur la configuration de la base de données de votre déploiement, contactez l’[assistance](mailto:support@wandb.com) ou votre AISE. Pour les paramètres de configuration de MySQL pour les instances autogérées, voir la [section de l’architecture de référence consacrée à la configuration de MySQL](/fr/platform/hosting/self-managed/ref-arch#mysql-configuration-parameters).
### Redis
W\&B dépend d'un déploiement Redis 7.x à nœud unique, utilisé par les composants de W\&B pour la mise en file d'attente des jobs et la mise en cache des données. Pour les tests et les preuves de concept, W\&B Autogéré inclut un déploiement Redis local. Ce déploiement intégré n'est pas adapté à un usage en production. Pour les déploiements en production, W\&B peut se connecter à une instance Redis dans les environnements suivants : * [Amazon ElastiCache](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 cloud ou sur site
### Stockage d’objets
W\&B requiert un stockage d’objets prenant en charge les URL pré-signées et CORS. W\&B recommande les fournisseurs de stockage suivants : * [Amazon S3](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é pour stocker des données non structurées à grande échelle. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) : service de stockage d’objets cloud pour les données non structurées à grande échelle. * [CoreWeave AI Object Storage](https://docs.coreweave.com/products/storage/object-storage) : stockage d’objets compatible S3 optimisé pour les charges de travail d’IA. * Stockage compatible S3 de niveau entreprise, comme [MinIO Enterprise (AIStor)](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), sans développement actif ni binaires précompilés. Pour les déploiements en production, W\&B recommande les services de stockage d’objets gérés ou les solutions compatibles S3 de niveau entreprise, comme MinIO Enterprise (AIStor). Après avoir sélectionné un fournisseur, configurez le bucket afin que W\&B puisse y accéder. Pour obtenir des instructions détaillées sur le provisionnement du bucket, notamment les stratégies IAM, la configuration CORS et la configuration des accès, voir le [guide Bring Your Own Bucket (BYOB)](/fr/platform/hosting/data-security/secure-storage-connector). Pour la liste complète des exigences de stockage d’objets, y compris les recommandations relatives à la capacité et aux performances, voir la [section sur le stockage d’objets de l’architecture de référence](/fr/platform/hosting/self-managed/ref-arch/#object-storage). Pour des conseils détaillés sur le provisionnement du stockage d’objets, consultez le guide [Bring Your Own Bucket (BYOB)](/fr/platform/hosting/data-security/secure-storage-connector). Dans les environnements isolés du réseau, vous utiliserez généralement une solution de stockage sur site compatible S3, telle que MinIO Enterprise, NetApp StorageGRID ou Dell ECS.
### Exigences spécifiques aux environnements isolés du réseau
En plus des exigences standard précédentes, les déploiements isolés du réseau nécessitent ce qui suit : * **Registre interne de conteneurs** : un accès à un registre privé de conteneurs tel que Harbor, JFrog Artifactory ou Nexus, contenant toutes les images W\&B requises. * **Dépôt Helm interne** : un accès à un dépôt privé de chart Helm contenant les charts Helm W\&B. * **Capacité de transfert d’images** : une méthode permettant de transférer des images de conteneur depuis un système connecté à Internet vers votre registre isolé du réseau. * **Fichier de licence** : une licence W\&B Enterprise valide. Pour obtenir une licence (par exemple, depuis une machine connectée à Internet), voir la section [License](/fr/platform/hosting/self-managed/requirements#license) de la page Requirements, ou contactez votre équipe commerciale W\&B. Pour consulter l’ensemble des exigences d’infrastructure, y compris la configuration du réseau et de l’équilibreur de charge, voir l’[architecture de référence](/fr/platform/hosting/self-managed/ref-arch#infrastructure-requirements).
## Préparez votre environnement isolé du réseau
Les étapes suivantes permettent de préparer votre environnement isolé du réseau à héberger les images de conteneur W\&B et les charts Helm. Effectuez ces étapes avant d’installer l’opérateur ou de déployer la plateforme.
### Étape 1 : Configurer le registre de conteneurs interne
Comme le cluster Kubernetes ne peut pas extraire d’images depuis des registres publics, toutes les images de conteneur requises doivent être disponibles dans votre registre de conteneurs interne isolé du réseau avant le déploiement. Il vous incombe de suivre les exigences de l’opérateur W\&B et de tenir votre registre de conteneurs à jour avec les dernières images. Pour obtenir la liste la plus récente des images de conteneur et des versions requises, référez-vous au chart Helm ou contactez [l’assistance W\&B](mailto:support@wandb.com) ou votre ingénieur d’assistance W\&B attitré.
#### Conteneurs des composants W\&B essentiels
Les images principales suivantes sont requises : * [`docker.io/wandb/controller`](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’application W\&B. * [`docker.io/wandb/console`](https://hub.docker.com/r/wandb/console): console de gestion 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): Requis pour le déploiement local de Redis pendant les phases de test et de développement. Pour les exigences Redis en Production, voir la [section Redis](#redis) dans les prérequis. * [`docker.io/otel/opentelemetry-collector-contrib`](https://hub.docker.com/r/otel/opentelemetry-collector-contrib): Agent OpenTelemetry pour collecter les métriques et les journaux. * [`quay.io/prometheus/prometheus`](https://quay.io/repository/prometheus/prometheus): Prometheus pour la collecte de métriques. * [`quay.io/prometheus-operator/prometheus-config-reloader`](https://quay.io/repository/prometheus-operator/prometheus-config-reloader): Dépendance Prometheus.
#### Obtenir la liste complète des images
Pour extraire la liste complète des images et des versions requises depuis le chart Helm : 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={null} # Cloner le dépôt helm-charts git clone https://github.com/wandb/helm-charts.git cd helm-charts ``` 2. Inspectez les fichiers `values.yaml` pour identifier toutes les images de conteneur et leurs versions : ```bash theme={null} # Extraire les références d'image du chart operator helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#" # Extraire les références d'image du chart platform helm show values charts/operator-wandb | grep -E "repository:|tag:" | grep -v "^#" ``` Vous pouvez également utiliser cette commande pour extraire uniquement les noms des dépôts (sans les tags de version) : ```bash theme={null} helm show values charts/operator-wandb \ | awk -F': *' '/^[[:space:]]*repository:/{print $2}' \ | grep -v "^#" \ | sort -u ``` La liste des dépôts ressemblera à ceci : ```text theme={null} wandb/controller wandb/local wandb/console wandb/megabinary wandb/weave-python wandb/weave-trace otel/opentelemetry-collector-contrib prometheus/prometheus prometheus-operator/prometheus-config-reloader bitnamilegacy/redis ``` Pour obtenir les tags de version spécifiques à chaque image, utilisez la première commande précédente (`grep -E "repository:|tag:"`), qui affiche à la fois les noms des dépôts et les tags de version correspondants.
#### Transférer des images vers un registre isolé du réseau
1. Sur un système connecté à Internet, téléchargez et enregistrez toutes les images requises. Remplacez les numéros de version dans les exemples suivants par les versions réelles obtenues lors de l'inspection de votre chart Helm à l'étape précédente. Les versions indiquées ici sont données à titre d'exemple et deviennent obsolètes au fil du temps. Utilisez des variables shell pour gérer les versions de manière cohérente : ```bash theme={null} # Définir les variables de version (mettez-les à jour selon les versions de votre chart Helm) CONTROLLER_VERSION="1.13.3" APP_VERSION="0.59.2" CONSOLE_VERSION="2.12.2" # Télécharger les images docker pull wandb/controller:${CONTROLLER_VERSION} docker pull wandb/local:${APP_VERSION} docker pull wandb/console:${CONSOLE_VERSION} docker pull wandb/megabinary:${APP_VERSION} # ... télécharger toutes les autres images requises avec leurs versions # Enregistrer les images dans des fichiers .tar docker save wandb/controller:${CONTROLLER_VERSION} -o wandb-controller-${CONTROLLER_VERSION}.tar docker save wandb/local:${APP_VERSION} -o wandb-local-${APP_VERSION}.tar docker save wandb/console:${CONSOLE_VERSION} -o wandb-console-${CONSOLE_VERSION}.tar docker save wandb/megabinary:${APP_VERSION} -o wandb-megabinary-${APP_VERSION}.tar # ... enregistrer toutes les autres images ``` 2. Transférez les fichiers `.tar` vers votre environnement isolé du réseau à l'aide de la méthode approuvée, par exemple une clé USB ou un transfert de fichiers sécurisé. 3. Dans votre environnement isolé du réseau, chargez les images et poussez-les vers votre registre interne : ```bash theme={null} # Définir les mêmes variables de version que ci-dessus CONTROLLER_VERSION="1.13.3" APP_VERSION="0.59.2" CONSOLE_VERSION="2.12.2" INTERNAL_REGISTRY="registry.yourdomain.com" # Charger les images docker load -i wandb-controller-${CONTROLLER_VERSION}.tar docker load -i wandb-local-${APP_VERSION}.tar docker load -i wandb-console-${CONSOLE_VERSION}.tar docker load -i wandb-megabinary-${APP_VERSION}.tar # ... charger toutes les autres images # Étiqueter pour le registre interne docker tag wandb/controller:${CONTROLLER_VERSION} ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION} docker tag wandb/local:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION} docker tag wandb/console:${CONSOLE_VERSION} ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION} docker tag wandb/megabinary:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION} # ... étiqueter toutes les autres images # Pousser vers le registre interne docker push ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION} docker push ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION} docker push ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION} docker push ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION} # ... pousser toutes les autres images ```
### Étape 2 : Configurer le dépôt interne de charts Helm
Une fois les images de conteneur en place, l’opérateur Kubernetes doit également avoir accès aux charts Helm W\&B. Assurez-vous que les charts Helm suivants sont disponibles dans votre dépôt Helm interne : * [chart de l’opérateur W\&B](https://github.com/wandb/helm-charts/tree/main/charts/operator) * [chart de la plateforme W\&B](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={null} # 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 chart `.tgz` vers votre environnement isolé du réseau et téléversez-les dans votre dépôt Helm interne conformément aux procédures de votre dépôt. Le chart `operator` déploie l’opérateur Kubernetes W\&B (Controller Manager). Le chart `operator-wandb` déploie la plateforme W\&B à l’aide des valeurs configurées dans la Ressource personnalisée (CR).
### Étape 3 : Configurer l’accès au dépôt Helm
Configurez votre client Helm local dans l’environnement isolé du réseau pour qu’il pointe vers votre dépôt interne, afin que les commandes d’installation suivantes puissent localiser les charts. 1. Dans votre environnement isolé du réseau, configurez Helm pour utiliser votre dépôt interne : ```bash theme={null} helm repo add local-repo https://charts.yourdomain.com helm repo update ``` 2. Vérifiez que les charts sont disponibles : ```bash theme={null} helm search repo local-repo/operator helm search repo local-repo/operator-wandb ```
## Déployer W\&B dans un environnement isolé du réseau
Une fois votre registre interne et votre dépôt Helm en place, vous pouvez désormais installer l’opérateur Kubernetes, configurer les services externes et déployer la plateforme W\&B.
### Étape 4 : Installer l’opérateur Kubernetes
L’opérateur Kubernetes W\&B (controller manager) gère les composants de la plateforme W\&B. Pour l’installer dans un environnement isolé du réseau, configurez-le pour utiliser votre registre de conteneurs interne. 1. Créez un fichier `values.yaml` avec le contenu suivant : ```yaml theme={null} image: repository: registry.yourdomain.com/wandb/controller tag: 1.13.3 airgapped: true ``` Remplacez le dépôt et le tag par les versions réelles que vous avez transférées vers votre registre interne à l’étape 1. La version indiquée ici (`1.13.3`) est un exemple et devient obsolète au fil du temps. 2. Installez l’opérateur et la définition de ressource personnalisée (CRD) : ```bash theme={null} 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={null} kubectl get pods -n wandb ``` Vous devriez voir le pod de l’opérateur dans l’état `Running`. L’opérateur Kubernetes W\&B est maintenant installé et prêt à déployer la plateforme W\&B depuis votre dépôt de charts interne. Pour plus de détails sur les valeurs prises en charge, voir le [fichier values du dépôt GitHub de l’opérateur Kubernetes](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, configurez une base de données MySQL externe. Pour les déploiements de production, W\&B recommande fortement d’utiliser des services de base de données gérés lorsqu’ils sont disponibles. Cependant, si vous exploitez votre propre instance MySQL, créez la base de données et l’utilisateur : Créez une base de données et un utilisateur à l’aide des commandes SQL suivantes. Remplacez `[PASSWORD]` par un mot de passe robuste : ```sql theme={null} CREATE USER 'wandb_local'@'%' IDENTIFIED BY '[PASSWORD]'; CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION; ``` Pour les paramètres de configuration MySQL, voir la [section de configuration MySQL de l’architecture de référence](/fr/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 interne. Cette configuration garantit que l’opérateur Kubernetes utilise votre registre et votre dépôt internes lors du déploiement des composants requis de la plateforme W\&B, au lieu de tenter d’accéder à des sources publiques. L’exemple de configuration suivant inclut des tags de version d’image qui deviennent obsolètes au fil du temps. Remplacez toutes les valeurs `tag:` par les versions réelles que vous avez transférées vers votre registre interne à l’étape 1. Créez un fichier appelé `wandb.yaml` avec le contenu suivant : ```yaml theme={null} apiVersion: apps.wandb.com/v1 kind: WeightsAndBiases metadata: labels: app.kubernetes.io/instance: wandb app.kubernetes.io/name: weightsandbiases name: wandb namespace: wandb spec: chart: url: https://charts.yourdomain.com name: operator-wandb version: 0.18.0 values: global: host: https://wandb.yourdomain.com license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bucket: accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: s3.yourdomain.com:9000 path: wandb provider: s3 region: us-east-1 mysql: database: wandb host: mysql.yourdomain.com password: [YOUR-MYSQL-PASSWORD] port: 3306 user: wandb redis: host: redis.yourdomain.com port: 6379 password: [YOUR-REDIS-PASSWORD] api: enabled: true glue: enabled: true executor: enabled: true extraEnv: ENABLE_REGISTRY_UI: 'true' # Configurer toutes les images de composants pour utiliser le registre interne app: image: repository: registry.yourdomain.com/wandb/local tag: 0.59.2 console: image: repository: registry.yourdomain.com/wandb/console tag: 2.12.2 api: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 executor: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 glue: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 parquet: image: repository: registry.yourdomain.com/wandb/megabinary tag: 0.59.2 weave: image: repository: registry.yourdomain.com/wandb/weave-python tag: 0.59.2 otel: image: repository: registry.yourdomain.com/otel/opentelemetry-collector-contrib tag: 0.97.0 prometheus: server: image: repository: registry.yourdomain.com/prometheus/prometheus tag: v2.47.0 configmapReload: prometheus: image: repository: registry.yourdomain.com/prometheus-operator/prometheus-config-reloader tag: v0.67.0 ingress: annotations: nginx.ingress.kubernetes.io/proxy-body-size: "0" class: nginx ``` Remplacez toutes les valeurs fictives, telles que les noms d’hôte, les mots de passe et les tags, par vos valeurs de configuration réelles. L’exemple précédent présente les composants les plus couramment utilisés. Selon vos besoins de déploiement, vous devrez peut-être également configurer les dépôts d’images pour des composants supplémentaires, notamment les suivants : * `settingsMigrationJob` * `weave-trace` * `filestream` * `flat-runs-table` Référez-vous au [fichier de valeurs du dépôt Helm W\&B](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml) pour consulter la liste complète des composants configurables.
### Étape 7 : Déployer la plateforme W\&B
Le fait d'appliquer la Ressource personnalisée déclenche l'installation par l'opérateur des composants de la plateforme W\&B définis dans le chart `operator-wandb`, à partir de la configuration et des références d'image de `wandb.yaml`. 1. Appliquez la Ressource personnalisée W\&B pour déployer la plateforme : ```bash theme={null} kubectl apply -f wandb.yaml ``` 2. Surveillez la progression du déploiement : ```bash theme={null} # Surveiller la création des pods kubectl get pods -n wandb --watch # Vérifier le statut du déploiement kubectl get weightsandbiases -n wandb # Afficher les journaux de l'opérateur kubectl logs -n wandb deployment/wandb-operator-controller-manager ``` Le déploiement peut prendre plusieurs minutes, le temps que l'opérateur crée tous les composants nécessaires.
## Configuration d’OpenShift
W\&B prend en charge le déploiement sur des clusters Kubernetes OpenShift isolés. Les déploiements OpenShift nécessitent une configuration supplémentaire du contexte de sécurité en raison des politiques de sécurité plus strictes d’OpenShift. Si vous effectuez un déploiement sur OpenShift, appliquez les configurations de cette section en plus des étapes précédentes.
### Contraintes de contexte de sécurité d’OpenShift
OpenShift utilise les Security Context Constraints (SCC) pour contrôler les autorisations des pods. Par défaut, OpenShift attribue la SCC `restricted` aux pods, ce qui empêche de s’exécuter en tant que root et exige des identifiants utilisateur spécifiques. 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={null} spec: values: # Configurer les contextes de sécurité pour tous les pods app: podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault console: podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault # Répéter pour les autres composants : api, executor, glue, parquet, weave ```
#### Option 2 : Créer une SCC personnalisée (si nécessaire)
Si votre déploiement nécessite des capacités qui ne sont pas disponibles dans la SCC `restricted`, créez une SCC personnalisée : ```yaml theme={null} 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 le SCC : ```bash theme={null} oc apply -f wandb-scc.yaml ``` 2. Associez le SCC aux comptes de service de W\&B : ```bash theme={null} oc adm policy add-scc-to-user wandb-scc -z wandb-app -n wandb oc adm policy add-scc-to-user wandb-scc -z wandb-console -n wandb ```
### Routes d’OpenShift
OpenShift utilise des Routes au lieu de l’ingress Kubernetes standard. Configurez W\&B pour utiliser les Routes d’OpenShift : ```yaml theme={null} spec: values: ingress: enabled: false route: enabled: true host: wandb.apps.openshift.yourdomain.com tls: enabled: true termination: edge insecureEdgeTerminationPolicy: Redirect ```
### Configuration de récupération d’image pour OpenShift
Si votre cluster OpenShift utilise un registre d’images interne avec authentification : 1. Créez un secret de récupération d’image : ```bash theme={null} kubectl create secret docker-registry wandb-registry-secret \ --docker-server=registry.yourdomain.com \ --docker-username=[USERNAME] \ --docker-password=[PASSWORD] \ --namespace=wandb ``` 2. Ajoutez une référence au secret dans votre Ressource personnalisée : ```yaml theme={null} spec: values: imagePullSecrets: - name: wandb-registry-secret ```
### Exemple complet pour OpenShift
L’exemple suivant montre une CR complète pour un déploiement OpenShift isolé du réseau : Remplacez toutes les valeurs `tag:` de cet exemple par les versions réelles que vous avez transférées dans votre registre interne à l’étape 1. Les versions indiquées ici sont fournies à titre d’exemple et deviennent obsolètes avec le temps. ```yaml theme={null} apiVersion: apps.wandb.com/v1 kind: WeightsAndBiases metadata: name: wandb namespace: wandb spec: chart: url: https://charts.yourdomain.com name: operator-wandb version: 0.18.0 values: global: host: https://wandb.apps.openshift.yourdomain.com license: [YOUR-LICENSE] bucket: accessKey: [YOUR-ACCESS-KEY] secretKey: [YOUR-SECRET-KEY] name: s3.yourdomain.com:9000 path: wandb provider: s3 region: us-east-1 mysql: database: wandb host: mysql.yourdomain.com password: [YOUR-MYSQL-PASSWORD] port: 3306 user: wandb redis: host: redis.yourdomain.com port: 6379 password: [YOUR-REDIS-PASSWORD] # Spécifique à OpenShift : utiliser des Routes plutôt que l'Ingress ingress: enabled: false route: enabled: true host: wandb.apps.openshift.yourdomain.com tls: enabled: true termination: edge # Secret de récupération d'image pour le registre interne imagePullSecrets: - name: wandb-registry-secret # Contextes de sécurité pour le SCC restricted d'OpenShift app: image: repository: registry.yourdomain.com/wandb/local tag: 0.59.2 podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault console: image: repository: registry.yourdomain.com/wandb/console tag: 2.12.2 podSecurityContext: fsGroup: 1000 runAsUser: 1000 runAsNonRoot: true securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true seccompProfile: type: RuntimeDefault # Répéter les contextes de sécurité pour : api, executor, glue, parquet, weave # (abrégé par souci de clarté) ``` Contactez [assistance W\&B](mailto:support@wandb.com) ou votre ingénieur d’assistance W\&B attitré pour obtenir des exemples complets de configuration d’OpenShift adaptés à vos exigences de sécurité.
## Vérifiez votre installation
Après avoir déployé W\&B, vérifiez que l’installation fonctionne correctement afin de confirmer que la plateforme est accessible, que les pods sont en bon état et que le déploiement utilise uniquement vos ressources internes. Suivez les étapes générales de vérification, puis effectuez les vérifications supplémentaires propres aux environnements isolés du réseau dans la section suivante. Pour vérifier l’installation, W\&B recommande d’utiliser le [W\&B CLI](/fr/models/ref/cli/). La commande `wandb verify` exécute des tests qui confirment que les composants et les configurations fonctionnent comme prévu. Cette procédure suppose que vous créez le premier compte administrateur dans un navigateur. Pour vérifier l’installation : 1. Installez le W\&B CLI : ```bash theme={null} pip install wandb ``` 2. Connectez-vous à W\&B : ```bash theme={null} wandb login --host=https://YOUR_DNS_DOMAIN ``` Par exemple : ```bash theme={null} wandb login --host=https://wandb.company-name.com ``` 3. Vérifiez l’installation : ```bash theme={null} wandb verify ``` Une fois la commande exécutée, une installation réussie affiche la sortie suivante : ```console theme={null} Default host selected: https://wandb.company-name.com Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb Checking if logged in...................................................✅ Checking signed URL upload..............................................✅ Checking ability to send large payloads through proxy...................✅ Checking requests to base url...........................................✅ Checking requests made over signed URLs.................................✅ Checking CORs configuration of the bucket...............................✅ Checking wandb package version is up to date............................✅ Checking logged metrics, saving and downloading a file..................✅ Checking artifact save and download workflows...........................✅ ``` Contactez l’assistance W\&B en cas d’erreur.
### Vérifications supplémentaires pour un environnement isolé du réseau
Pour les déploiements isolés du réseau, vérifiez également les points suivants : 1. **Récupération d’image** : assurez-vous que tous les pods ont bien récupéré les images depuis votre registre interne : ```bash theme={null} kubectl get pods -n wandb -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[*].image}{"\n"}{end}' ``` Toutes les images doivent pointer vers votre registre interne, et tous les pods doivent être dans l’état `Running`. 2. **Connectivité externe** : vérifiez que W\&B ne tente pas d’établir de connexions externes (cela ne devrait pas arriver en mode isolé du réseau) : ```bash theme={null} 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 des images, vérifiez les points suivants : * Vérifiez que les images sont présentes dans votre registre interne. * Vérifiez que le secret de récupération d’image est correctement configuré. * Vérifiez la connectivité réseau entre les nœuds Kubernetes et le registre. * Vérifiez les identifiants d'authentification du registre. Pour tester manuellement une récupération d’image : ```bash theme={null} kubectl run test-pull --image=registry.yourdomain.com/wandb/local:0.59.2 --namespace=wandb kubectl logs test-pull -n wandb kubectl delete pod test-pull -n wandb ```
### Erreurs SCC d’OpenShift
Si des pods échouent en raison d’erreurs d’autorisation sur OpenShift : ```bash theme={null} # Vérifier quel SCC est utilisé oc get pod [POD-NAME] -n wandb -o yaml | grep scc # Vérifier les autorisations du compte de service oc describe scc wandb-scc oc get rolebinding -n wandb ```
### Chart Helm introuvable
Si l’opérateur ne parvient pas à trouver le chart de la plateforme, vérifiez les points suivants : * Vérifiez l’URL du dépôt Helm dans la Ressource personnalisée. * Vérifiez que le pod de l’opérateur peut accéder à votre dépôt Helm interne. * Vérifiez que le chart existe dans votre dépôt : ```bash theme={null} helm search repo local-repo/operator-wandb ```
## Foire aux questions
### Puis-je utiliser une autre classe d’ingress ?
Oui, configurez votre classe d’ingress en modifiant les paramètres d’ingress dans votre ressource personnalisée : ```yaml theme={null} spec: values: ingress: class: your-ingress-class ```
### Comment puis-je gérer des bundles de certificats contenant plusieurs certificats ?
Répartissez les certificats en plusieurs entrées dans la section `customCACerts` : ```yaml theme={null} spec: values: customCACerts: cert1.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- cert2.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ```
### Comment puis-je empêcher les mises à jour automatiques ?
Pour configurer l’opérateur afin qu’il ne mette pas W\&B à jour automatiquement, procédez comme suit : * Définissez `airgapped: true` dans l’installation de l’opérateur (cela désactive les vérifications automatiques de mise à jour). * Gérez les mises à jour de version en mettant à jour manuellement `spec.chart.version` dans votre Ressource personnalisée. * Si nécessaire, désactivez les mises à jour automatiques depuis la console système de W\&B. Voir [Désactiver les mises à jour automatiques de la version de l’application](/fr/platform/hosting/self-managed/disable-automatic-app-version-updates) pour plus de détails. W\&B recommande vivement aux clients disposant d’instances autogérées de mettre à jour leurs déploiements avec la dernière version au moins une fois par trimestre afin de conserver l’assistance et de bénéficier des dernières fonctionnalités, améliorations des performances et correctifs. W\&B prend en charge une version majeure pendant 12 mois à compter de sa date de sortie initiale. Reportez-vous à [Politiques et processus de version](/fr/release-notes/release-policies).
### Le déploiement fonctionne-t-il sans connexion à des dépôts publics ?
Oui. Lorsque `airgapped: true` est défini dans la configuration de l’opérateur, l’opérateur Kubernetes utilise uniquement vos ressources internes et n’essaie pas de se connecter à des dépôts publics.
### Comment puis-je mettre à jour W\&B dans un environnement isolé du réseau ?
Pour mettre à jour W\&B : 1. Téléchargez 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 des composants W\&B.
## Prochaines étapes
Après un déploiement réussi, effectuez les tâches suivantes : * **Configurer l'authentification des utilisateurs** : Configurez [SSO](/fr/platform/hosting/iam/sso) ou d'autres méthodes d'authentification. * **Mettre en place la supervision** : Configurez la supervision de votre instance W\&B et de votre infrastructure. * **Planifier les mises à jour** : Consultez le [processus de mise à niveau du serveur](/fr/platform/hosting/server-upgrade-process) et définissez une cadence de mise à jour. * **Configurer les sauvegardes** : Mettez en place des procédures de sauvegarde pour votre base de données MySQL. * **Documenter votre processus** : Créez des runbooks pour vos procédures spécifiques de mise à jour en environnement isolé.
## Obtenir de l’aide
Si vous rencontrez des problèmes pendant le déploiement : * Consultez l’[architecture de référence](/fr/platform/hosting/self-managed/ref-arch) pour obtenir des conseils sur l’infrastructure. * Consultez le [guide de l’opérateur](/fr/platform/hosting/self-managed/operator) pour plus de détails sur la configuration. * Contactez [l’assistance W\&B](mailto:support@wandb.com) ou votre ingénieur d’assistance W\&B dédié. * Pour les problèmes spécifiques à OpenShift, consultez la documentation Red Hat OpenShift.