> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-wbdocs-1882.mintlify.site/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 (isolés du réseau), entièrement déconnectés ou soumis à des restrictions réseau. Les déploiements isolés du réseau sont courants dans : * 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 Utilisez un registre de conteneurs interne et un dépôt Helm pour héberger les images et charts W\&B requis. 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.32 ou ultérieure ([Versions de Kubernetes prises en charge](https://kubernetes.io/releases/patch-releases/)) | | Helm | v3.x | | MySQL | v8.0.x est requis ; v8.0.32 ou ultérieure ; v8.0.44 ou ultérieure est recommandée.
Les versions Aurora MySQL 3.x doivent être en v3.05.2 ou ultérieure | | 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/de l’équilibreur de charge. L’application W\&B Server ne termine pas les connexions SSL ou TLS. **Important** : W\&B ne prend pas en charge les certificats auto-signés ni les autorités de certification personnalisées. L’utilisation de certificats auto-signés entraînera des problèmes pour les utilisateurs et n’est pas prise en charge. Si possible, utiliser un service comme [Let's Encrypt](https://letsencrypt.org) est un excellent moyen de 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 fortement 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 l’ensemble des exigences MySQL, y compris les recommandations de dimensionnement et les paramètres de configuration. Pour le SQL de création de 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 mettre les jobs en file d’attente et mettre les données en cache. Pour plus de commodité lors des tests et du développement de preuves de faisabilité, W\&B Self-Managed inclut un déploiement Redis local qui n’est pas adapté aux déploiements de production. Pour les déploiements de production, W\&B peut se connecter à une instance Redis dans les environnements suivants : * [AWS Elasticache](https://aws.amazon.com/elasticache/) * [Google Cloud Memory Store](https://cloud.google.com/memorystore?hl=en) * [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache) * Déploiement Redis hébergé dans votre cloud ou sur votre infrastructure sur site
### Stockage d’objets
W\&B requiert un stockage d’objets prenant en charge les URL pré-signées et CORS. **Fournisseurs de stockage recommandés :** * [Amazon S3](https://aws.amazon.com/s3/) : service de stockage d’objets offrant une évolutivité, une disponibilité des données, une sécurité et des performances de premier plan. * [Google Cloud Storage](https://cloud.google.com/storage) : service géré permettant de stocker des données non structurées à grande échelle. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) : solution de stockage d’objets cloud pour stocker de grandes quantités de données non structurées. * [CoreWeave AI Object Storage](https://docs.coreweave.com/products/storage/object-storage) : service de stockage d’objets hautes performances, compatible S3, optimisé pour les charges de travail d’IA. * Stockage compatible S3 pour les entreprises : [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor), [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) ou d’autres solutions de niveau entreprise MinIO Open Source est en [mode de maintenance](https://github.com/minio/minio), sans développement actif ni binaires précompilés. Pour les déploiements de production, W\&B recommande d’utiliser des services de stockage d’objets gérés ou des solutions compatibles S3 pour les entreprises, telles que MinIO Enterprise (AIStor). Pour des instructions détaillées sur le provisionnement du bucket, y compris les stratégies IAM, la configuration CORS et la configuration de l’accès, voir le guide [Bring Your Own Bucket (BYOB)](/fr/platform/hosting/data-security/secure-storage-connector). 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 connaître l’ensemble des exigences. 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 ci-dessus, les déploiements isolés du réseau nécessitent : * **Registre interne de conteneurs** : un accès à un registre privé de conteneurs (Harbor, JFrog Artifactory, Nexus, etc.) 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
### Étape 1 : Configurer le registre de conteneurs interne
Pour réussir un déploiement isolé du réseau, toutes les images de conteneur requises doivent être disponibles dans votre registre de conteneurs isolé du réseau. 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 de l'opérateur helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#" # Extraire les références d'image 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 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 ci-dessus (`grep -E "repository:|tag:"`) ; elle affichera à la fois les noms des dépôts et les tags de version correspondants.
#### Transférer les images vers un registre isolé du réseau
1. Sur un système connecté à Internet, récupérez et enregistrez toutes les images requises. Remplacez les numéros de version dans les exemples ci-dessous par les versions réelles issues de l’inspection de votre chart Helm à l’étape 2 ci-dessus. Les versions indiquées ici sont données à titre d’exemple et deviendront obsolètes. 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" # 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 à l’aide de la méthode approuvée dans votre organisation (clé USB, transfert de fichiers sécurisé, etc.). 3. Dans votre environnement isolé du réseau, chargez les images et envoyez-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 # Ajouter un tag 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} # ... ajouter un tag à toutes les autres images # Envoyer 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} # ... envoyer toutes les autres images ```
### Étape 2 : Configurer le dépôt interne de charts Helm
En plus des images de conteneur, 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 importez-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
1. Dans votre environnement isolé, 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é (air-gapped)
### É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 deviendra obsolète. 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`. 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 `SOME_PASSWORD` par un mot de passe robuste de votre choix : ```sql theme={null} CREATE USER 'wandb_local'@'%' IDENTIFIED BY 'SOME_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. L’exemple de configuration ci-dessous inclut des tags de version d’image qui deviendront obsolètes. 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 nommé `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: port: 3306 user: wandb redis: host: redis.yourdomain.com port: 6379 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 (noms d’hôte, mots de passe, tags, etc.) par vos valeurs de configuration réelles. L’exemple ci-dessus 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, tels que : * `settingsMigrationJob` * `weave-trace` * `filestream` * `flat-runs-table` Consultez le [fichier values du dépôt Helm 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 plateforme W\&B
1. Appliquez la Ressource personnalisée W\&B pour déployer la plateforme : ```bash theme={null} kubectl apply -f wandb.yaml ``` 2. Surveillez l'avancement 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 # Consulter 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 entièrement 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.
### 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= \ --docker-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 d’OpenShift
Voici un exemple complet de CR pour un déploiement OpenShift en environnement isolé : Remplacez toutes les valeurs `tag:` de cet exemple par les versions réelles que vous avez transférées vers votre registre interne à l’étape 1. Les versions indiquées ici sont données à titre d’exemple et deviendront obsolètes. ```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: bucket: accessKey: secretKey: name: s3.yourdomain.com:9000 path: wandb provider: s3 region: us-east-1 mysql: database: wandb host: mysql.yourdomain.com password: port: 3306 user: wandb redis: host: redis.yourdomain.com port: 6379 password: # Spécifique à OpenShift : utiliser les 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 [l’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 : Pour vérifier l’installation, W\&B recommande d’utiliser le [W\&B CLI](/fr/models/ref/cli/). La commande verify exécute plusieurs tests pour vérifier l’ensemble des composants et de la configuration. Cette étape suppose que le premier compte administrateur a été créé depuis le navigateur. Suivez ces étapes 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 installation réussie et un déploiement W\&B pleinement opérationnel affichent 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 les images : 1. Vérifiez que les images existent dans votre registre interne 2. Vérifiez que le secret de récupération d’image est correctement configuré 3. Vérifiez la connectivité réseau depuis les nœuds Kubernetes vers le registre 4. Vérifiez les identifiants d’authentification du registre ```bash theme={null} # Tester la récupération d’image manuellement 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 -n wandb -o yaml | grep scc # Vérifier les permissions 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 : 1. Vérifiez l’URL du dépôt Helm dans la Ressource personnalisée 2. Vérifiez que le pod de l’opérateur peut accéder à votre dépôt Helm interne 3. 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 ?
Configurez l’opérateur pour qu’il ne mette pas W\&B à jour automatiquement : 1. Définissez `airgapped: true` dans l’installation de l’opérateur (cela désactive les vérifications automatiques de mise à jour) 2. Gérez les mises à jour de version en mettant à jour manuellement `spec.chart.version` dans votre Ressource personnalisée 3. 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 effectuera une mise à jour progressive des composants W\&B.
## Prochaines étapes
Après un déploiement réussi : 1. **Configurer l'authentification des utilisateurs** : Configurez [SSO](/fr/platform/hosting/iam/sso) ou d'autres méthodes d'authentification 2. **Mettre en place la supervision** : Configurez la supervision de votre instance W\&B et de votre infrastructure 3. **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 4. **Configurer les sauvegardes** : Mettez en place des procédures de sauvegarde pour votre base de données MySQL 5. **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