### Prérequis
Assurez-vous que votre déploiement remplit les exigences suivantes avant d’activer le serveur MCP :
* **Version du chart** : `operator-wandb` `0.42.3` ou ultérieure. Le sous-chart `mcp-server` a été introduit dans `0.42.1`, mais les champs Datadog et Confidentialité utilisés dans l’exemple suivant ont été ajoutés plus tard.
* **Weave Traces activé** : le serveur MCP dépend de Weave Traces pour les outils de trace et pour la valeur par défaut de `WF_TRACE_SERVER_URL`. Définissez `weave-trace.install: true`. Si Weave Traces n’est pas activé, le rendu Helm échoue avec `mcp-server requires weave-trace.install=true`.
* **Ingress accessible** : `global.host` doit déjà se résoudre et acheminer le trafic vers l’ingress W\&B. Le pod MCP lit `WANDB_BASE_URL` depuis `global.host` et est disponible à l’adresse `
### Activez le sous-chart
Activez le sous-chart `mcp-server` afin que l’opérateur déploie un serveur MCP dans le cluster et ajoute une route `/mcp` à votre ingress W\&B existant. Ajoutez les éléments suivants au bloc `spec.values` de votre ressource personnalisée `WeightsAndBiases` (CR) existante, aux côtés de vos valeurs `global`, `ingress` et autres redéfinitions existantes. Le bloc Datadog est facultatif, mais recommandé si un DaemonSet Datadog Agent collecte déjà les journaux et les traces des pods dans votre cluster.
```yaml theme={null}
spec:
values:
weave-trace:
install: true
mcp-server:
install: true
image:
repository: us-docker.pkg.dev/wandb-production/public/wandb/mcp-server
tag: "0.3.3"
datadog:
enabled: true
mode: "agent"
service: "wandb-mcp-server-
### Vérifier le serveur MCP
Attendez que le pod passe à l’état `Running`, puis vérifiez le point de terminaison d’état de santé au sein du cluster et via l’ingress :
```bash theme={null}
kubectl get pod -l app.kubernetes.io/component=mcp-server
kubectl port-forward svc/wandb-mcp-server 8080:8080
curl -s http://localhost:8080/mcp/health
curl -s "https://
### Connecter un client
Une fois le serveur MCP opérationnel, configurez votre client MCP pour utiliser `https://
### Dépannage
| Symptôme | Cause et correctif |
| ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `helm render` échoue avec `mcp-server requires weave-trace.install=true` | Ajoutez `weave-trace.install: true` à `spec.values`. Le serveur MCP dépend de Weave Traces pour les outils de trace. |
| Le pod `wandb-mcp-server` reste bloqué à l’état `Pending` avec `Insufficient cpu` ou `Insufficient memory` | Ajoutez de la capacité aux nœuds, ou réduisez `mcp-server.resources.requests` dans votre CR. Les valeurs par défaut sont `500m` de CPU et `1Gi` de mémoire. |
| `curl https://
## Considérations spécifiques à l’environnement
Kubernetes fonctionne de la même manière, qu’il soit exécuté sur site ou dans le cloud. Les principales différences concernent les conventions de nommage et les services gérés (par exemple, MySQL par rapport à RDS, ou S3 par rapport au stockage d’objets sur site). Cette section aborde les considérations qui varient selon l’environnement.
### sur site et bare metal
Lors d’un déploiement sur un cluster Kubernetes sur site ou bare metal, tenez compte des points suivants.
#### Configuration de l’équilibreur de charge
Les clusters Kubernetes sur site nécessitent généralement une configuration manuelle de l’équilibreur de charge. Les options possibles sont les suivantes :
* **Équilibreur de charge externe** : configurez un équilibreur de charge matériel ou logiciel existant, tel que F5 ou HAProxy.
* **Nginx Ingress Controller** : déployez nginx-ingress-controller avec NodePort ou le réseau hôte.
* **MetalLB** : pour les clusters Kubernetes bare metal, MetalLB fournit des services d’équilibreur de charge.
Pour des exemples détaillés de configuration de l’équilibreur de charge, voir la [section réseau de l’architecture de référence](/fr/platform/hosting/self-managed/ref-arch#networking).
#### Stockage persistant
Assurez-vous que votre cluster Kubernetes dispose d’une StorageClass configurée pour les volumes persistants. Les composants W\&B peuvent nécessiter un stockage persistant pour la mise en cache et les données temporaires.
Les options courantes de stockage sur site incluent :
* Classes de stockage basées sur NFS
* Stockage Ceph/Rook
* Volumes persistants locaux
* Solutions de stockage d’entreprise telles que NetApp ou Pure Storage
#### Gestion du DNS et des certificats
Pour les déploiements sur site, effectuez les tâches suivantes :
* Configurez les enregistrements DNS internes pour qu’ils pointent vers votre nom d’hôte W\&B.
* Générez des certificats SSL/TLS auprès de votre autorité de certification (CA) interne.
* Si vous utilisez des certificats auto-signés, configurez l’opérateur pour qu’il fasse confiance à votre certificat d’autorité de certification (CA).
Voir les [exigences SSL/TLS](/fr/platform/hosting/self-managed/requirements#ssl-tls) pour plus de détails sur la configuration des certificats.
#### Déploiements OpenShift
W\&B prend entièrement en charge les déploiements sur des clusters Kubernetes OpenShift. Les déploiements OpenShift nécessitent des configurations supplémentaires du contexte de sécurité en raison des politiques de sécurité plus strictes d'OpenShift.
Pour en savoir plus sur la configuration spécifique à OpenShift, voir [clusters Kubernetes OpenShift](#openshift-kubernetes-clusters). Pour des exemples de déploiement OpenShift dans des environnements isolés du réseau, voir [Déployer sur Kubernetes isolé du réseau](/fr/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped#openshift-configuration).
#### Stockage d’objets pour les environnements sur site et compatibles S3
Une fois votre bucket de stockage d’objets provisionné (voir [Provisionnement du stockage d’objets](/fr/platform/hosting/data-security/secure-storage-connector)), configurez-le dans votre Ressource personnalisée W\&B.
**AWS S3 (sur site)**
Pour AWS S3 sur site (via Outposts ou un stockage compatible) :
```yaml theme={null}
bucket:
kmsKey:
### Sur cloud public avec Terraform
Pour un déploiement complet de l’infrastructure et de l’application sur AWS, Google Cloud ou Azure, voir [Déployer avec Terraform sur un cloud public](#deploy-with-terraform-on-public-cloud).
## Déployer avec Terraform sur un cloud public
### Autres options de déploiement
Vous pouvez combiner plusieurs options de déploiement en ajoutant toutes les configurations dans le même fichier. Chaque module Terraform propose plusieurs options, que vous pouvez combiner avec les options standard et la configuration minimale décrite dans la section sur le déploiement recommandé.
Consultez la documentation du module correspondant à votre cloud provider pour obtenir la liste complète des options disponibles :
* [Documentation du module AWS](https://registry.terraform.io/modules/wandb/wandb/aws/latest)
* [Documentation du module Google Cloud](https://registry.terraform.io/modules/wandb/wandb/google/latest)
* [Documentation du module Azure](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest)
## Accéder à la console de gestion W\&B
L’opérateur Kubernetes W\&B inclut une console de gestion dans laquelle vous pouvez vérifier le statut du déploiement, consulter les métriques des composants et ajuster les paramètres au niveau de l’opérateur. Elle se trouve à l’adresse `${HOST_URI}/console`, par exemple `https://wandb.company-name.com/console`.
Vous pouvez vous connecter à la console de gestion de deux façons :
2. Récupérez le mot de passe depuis le secret Kubernetes généré par l’installation :
```shell theme={null}
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
Copiez le mot de passe.
3. Connectez-vous à la console. Collez le mot de passe copié, puis cliquez sur **Login**.
## Mettre à jour l’opérateur Kubernetes W\&B
Cette section explique comment mettre à jour l’opérateur Kubernetes W\&B lui-même. Mettez régulièrement à jour l’opérateur afin de bénéficier de correctifs et de nouvelles fonctionnalités de réconciliation.
## Mettre à jour l’application W\&B Server
Vous n’avez plus besoin de mettre à jour l’application W\&B Server si vous utilisez l’opérateur Kubernetes W\&B.
L’opérateur met automatiquement à jour votre application W\&B Server lorsqu’une nouvelle version du logiciel W\&B est publiée.
## Mettre à niveau MySQL vers 8.4.x
MySQL 8.0.x est en fin de vie. Les déploiements autogérés doivent exécuter une version prise en charge de MySQL qui reçoit des correctifs de sécurité et des corrections de bugs critiques. Si vous exécutez MySQL Community, installez ou mettez à niveau **MySQL 8.4.x**. Si vous utilisez un service géré, exécutez une version du moteur que votre fournisseur indique comme prise en charge et corrigée (par exemple Amazon RDS for MySQL, Google Cloud SQL for MySQL ou Azure Database for MySQL). W\&B a validé la plateforme avec MySQL 8.4.0 et les versions 8.4.x actuelles.
Ces étapes décrivent la séquence du point de vue de W\&B. Pour savoir comment mettre à niveau MySQL lui-même, y compris les sauvegardes et les chemins de mise à niveau entre versions, suivez la documentation de votre distribution MySQL ou de votre fournisseur de cloud. La même séquence s’applique aux déploiements Operator [standard](/fr/platform/hosting/self-managed/operator) et [isolés du réseau](/fr/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped). Dans les environnements isolés du réseau, obtenez le logiciel MySQL 8.4.x via votre processus de distribution interne avant de mettre à niveau la base de données.
## Migrer des instances Autogéré vers W\&B Operator
La section suivante explique comment passer d’une gestion autonome de votre propre installation serveur W\&B à l’utilisation de W\&B Operator pour la gérer à votre place. La migration permet à l’opérateur de gérer automatiquement la réconciliation et les mises à niveau de serveur W\&B, de sorte que vous n’avez plus à coordonner les modifications des manifestes ou les mises à niveau Helm pour l’application. Le processus de migration dépend de la façon dont vous avez installé serveur W\&B :
### Migrer vers des modules Terraform AWS basés sur l’opérateur
Pour une description détaillée du processus de migration, consultez la [documentation du chart operator-wandb](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb).
### Migrer vers les modules Terraform Google Cloud basés sur l’opérateur
Contactez [assistance client](mailto:support@wandb.com) ou votre équipe W\&B si vous avez des questions ou besoin d’assistance.
### Migrer vers des modules Terraform Azure basés sur l’opérateur
Contactez [assistance client](mailto:support@wandb.com) ou votre équipe W\&B si vous avez des questions ou besoin d’assistance.
### Migrer vers le chart Helm basé sur l’opérateur
Suivez ces étapes pour migrer vers le chart Helm basé sur l’opérateur :
1. Obtenez la configuration W\&B actuelle. Si vous avez déployé W\&B avec une version du chart Helm non basée sur l’opérateur, exportez les valeurs comme ceci :
```shell theme={null}
helm get values wandb
```
Si vous avez déployé W\&B avec des manifests Kubernetes, exportez les valeurs comme ceci :
```shell theme={null}
kubectl get deployment wandb -o yaml
```
Vous disposez maintenant de toutes les valeurs de configuration nécessaires pour l’étape suivante.
2. Créez un fichier nommé `operator.yaml`. Suivez le format décrit dans la [Référence de configuration](#configuration-reference-for-wb-operator). Utilisez les valeurs de l’étape 1.
3. Réduisez le déploiement actuel à 0 pods. Cette étape arrête le déploiement actuel.
```shell theme={null}
kubectl scale --replicas=0 deployment wandb
```
4. Mettez à jour le dépôt du chart Helm :
```shell theme={null}
helm repo update
```
5. Installez le nouveau chart Helm :
```shell theme={null}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
6. Configurez le nouveau chart Helm et déclenchez le déploiement de l’application W\&B. Appliquez la nouvelle configuration.
```shell theme={null}
kubectl apply -f operator.yaml
```
Le déploiement prend quelques minutes.
7. Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de [Vérifiez l’installation](#verify-the-installation).
8. Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources que vous avez créées à l’aide de manifests.
### Migrer vers le chart Helm Terraform basé sur l’opérateur
Suivez ces étapes pour migrer vers le chart Helm basé sur l’opérateur :
1. Préparez la configuration Terraform. Remplacez, dans votre configuration Terraform, le code Terraform de l’ancien déploiement par celui décrit dans [Déployer W\&B avec le module Terraform Helm](#deploy-wb-with-helm-terraform-module). Définissez les mêmes variables qu’auparavant. Ne modifiez pas le fichier `.tfvars` si vous en avez un.
2. Exécutez les commandes Terraform. Exécutez `terraform init`, `terraform plan` et `terraform apply`.
3. Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes indiquées dans [Vérifiez l’installation](#verify-the-installation).
4. Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources que vous avez créées à l’aide de manifests.
## Référence de configuration pour serveur W\&B
Cette section sert de référence pour les options de configuration que vous définissez dans votre ressource personnalisée `WeightsAndBiases`. Utilisez-la pour consulter le schéma YAML d’un sous-système spécifique (par exemple, MySQL, Redis, ingress ou OIDC) lorsque vous créez ou mettez à jour votre fichier `operator.yaml`.
Cette section décrit les options de configuration de l’application serveur W\&B. L’application reçoit sa configuration sous la forme d’une définition de ressource personnalisée nommée [WeightsAndBiases](#how-it-works). Certaines options de configuration sont disponibles dans la configuration suivante. Vous devez définir les autres au moyen de variables d’environnement.
La documentation comporte deux listes de variables d’environnement : [de base](/fr/platform/hosting/env-vars/) et [avancées](/fr/platform/hosting/iam/advanced_env_vars/). Utilisez des variables d’environnement uniquement si l’option de configuration dont vous avez besoin n’est pas exposée via le chart Helm.
### Exemple de base
Cet exemple définit le jeu minimal de valeurs requis pour W\&B. Pour un exemple de production plus réaliste, voir [Exemple complet](#complete-example).
Ce fichier YAML définit l'état souhaité de votre déploiement W\&B, y compris la version, les variables d'environnement, les ressources externes comme les bases de données, ainsi que d'autres paramètres nécessaires.
```yaml theme={null}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
labels:
app.kubernetes.io/name: weightsandbiases
app.kubernetes.io/instance: wandb
name: wandb
namespace: default
spec:
values:
global:
host: https://
mysql:
ingress:
annotations:
```
Consultez la liste complète des valeurs dans le [dépôt Helm W\&B](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml). **Modifiez uniquement les valeurs que vous devez surcharger**.
```
Dans le cas de Nginx, il se peut que vous deviez ajouter l’annotation suivante :
```yaml theme={null}
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 0
```
La prise en charge de la configuration LDAP dans le chart Helm actuel est limitée. Contactez l’équipe d’assistance de W\&B ou votre AISE pour vous aider à configurer LDAP.
Configurez LDAP en définissant des variables d’environnement dans `global.extraEnv` :
```yaml theme={null}
global:
extraEnv:
LDAP_ADDRESS: ldaps://ldap.company.example.com
LDAP_BASE_DN: cn=accounts,dc=company,dc=example,dc=com
LDAP_USER_BASE_DN: cn=users,cn=accounts,dc=company,dc=example,dc=com
LDAP_GROUP_BASE_DN: cn=groups,cn=accounts,dc=company,dc=example,dc=com
LDAP_BIND_DN: uid=ldapbind,cn=sysaccounts,cn=etc,dc=company,dc=example,dc=com
LDAP_BIND_PW: ********************
LDAP_ATTRIBUTES: email=mail,name=cn
LDAP_TLS_ENABLE: "true"
LDAP_LOGIN: "true"
LDAP_USER_OBJECT_CLASS: user
LDAP_GROUP_OBJECT_CLASS: group
```
Cette ancienne approche n'est plus recommandée. Cette section est fournie à titre de référence.
**Sans TLS**
```yaml theme={null}
global:
ldap:
enabled: true
# Adresse du serveur LDAP, y compris "ldap://" ou "ldaps://"
host:
# Base de recherche LDAP à utiliser pour rechercher des utilisateurs
baseDN:
# Utilisateur LDAP à utiliser pour la liaison (si vous n'utilisez pas de liaison anonyme)
bindDN:
# Nom du secret et clé contenant le mot de passe LDAP à utiliser pour la liaison (si vous n'utilisez pas de liaison anonyme)
bindPW:
# Attribut LDAP pour l'adresse e-mail et noms d'attribut d'ID de groupe sous forme de chaînes séparées par des virgules.
attributes:
# Liste d'autorisation des groupes LDAP
groupAllowList:
# Activer TLS pour LDAP
tls: false
```
**Avec TLS**
La configuration du certificat TLS LDAP nécessite une ConfigMap créée au préalable avec le contenu du certificat.
Pour créer la ConfigMap, vous pouvez utiliser la commande suivante :
```console theme={null}
kubectl create configmap ldap-tls-cert --from-file=certificate.crt
```
Utilisez ensuite la ConfigMap dans le YAML, comme dans l'exemple suivant.
```yaml theme={null}
global:
ldap:
enabled: true
# Adresse du serveur LDAP, y compris "ldap://" ou "ldaps://"
host:
# Base de recherche LDAP à utiliser pour rechercher des utilisateurs
baseDN:
# Utilisateur LDAP à utiliser pour la liaison (si vous n'utilisez pas de liaison anonyme)
bindDN:
# Nom du secret et clé contenant le mot de passe LDAP à utiliser pour la liaison (si vous n'utilisez pas de liaison anonyme)
bindPW:
# Attribut LDAP pour l'adresse e-mail et noms d'attribut d'ID de groupe sous forme de chaînes séparées par des virgules.
attributes:
# Liste d'autorisation des groupes LDAP
groupAllowList:
# Activer TLS pour LDAP
tls: true
# Nom de la ConfigMap et clé contenant le certificat CA du serveur LDAP
tlsCert:
configMap:
name: "ldap-tls-cert"
key: "certificate.crt"
```
Pour activer les limites de débit, vous devez définir `GORILLA_LIMITER` sur l’adresse de votre serveur Redis.
```yaml theme={null}
spec:
values:
global:
extraEnv:
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM: "5"
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_COUNT: "5"
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_PER_RUN_COUNT: "0.8"
GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_SIZE: "10"
GORILLA_DEFAULT_RATE_LIMITS_RUN_UPDATE_COUNT: "10"
GORILLA_LIMITER: "redis://$HOST:6379?ttlInSeconds=900"
```
Se référer au tableau suivant pour plus de détails :
| Environment variable | Default | Description |
| ------------------------------------------------------ | ------- | ----------------------------------------------------------- |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM` | `5` | Nombre par défaut de requêtes filestream. |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_COUNT` | `5` | Requêtes filestream par seconde. |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_PER_RUN_COUNT` | `0.8` | Requêtes filestream par run et par seconde. |
| `GORILLA_DEFAULT_RATE_LIMITS_FILESTREAM_SIZE` | `10` | Limite d'ingestion filestream en Mo par seconde. |
| `GORILLA_DEFAULT_RATE_LIMITS_RUN_UPDATE_COUNT` | `10` | Requêtes de mise à jour des métadonnées de run par seconde. |
`customCACerts` est une liste qui peut contenir plusieurs certificats. Les autorités de certification spécifiées dans `customCACerts` s’appliquent uniquement à l’application W\&B Server.
```yaml theme={null}
global:
customCACerts:
- |
-----BEGIN CERTIFICATE-----
MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
-----END CERTIFICATE-----
```
Les certificats CA peuvent également être stockés dans une ConfigMap :
```yaml theme={null}
global:
caCertsConfigMap: custom-ca-certs
```
Le ConfigMap doit se présenter comme suit :
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
Si vous utilisez une ConfigMap, chaque clé de la ConfigMap doit se terminer par `.crt` (par exemple, `my-cert.crt` ou `ca-cert1.crt`). Cette convention de nommage est requise pour que `update-ca-certificates` puisse traiter et ajouter chaque certificat au magasin système des autorités de certification.
La seule valeur valide pour `runAsGroup:` est `0`. Toute autre valeur constitue une erreur.
Par exemple, pour configurer le pod de l’application, ajoutez une section `app` à votre configuration :
```yaml theme={null}
global:
...
app:
pod:
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 0
fsGroup: 1001
fsGroupChangePolicy: Always
seccompProfile:
type: RuntimeDefault
container:
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
```
Le même concept s'applique à `console`, `weave`, `weave-trace` et `parquet`.
Chaque clé du ConfigMap doit se terminer par `.crt` (par exemple, `my-cert.crt` ou `ca-cert1.crt`). Cette convention de nommage est nécessaire pour que `update-ca-certificates` puisse interpréter et ajouter chaque certificat au magasin système d’autorités de certification.
### Exemple complet
Cet exemple de configuration déploie W\&B sur Google Cloud Anthos à l’aide de Google Cloud Storage :
```yaml theme={null}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
labels:
app.kubernetes.io/name: weightsandbiases
app.kubernetes.io/instance: wandb
name: wandb
namespace: default
spec:
values:
global:
host: https://abc-wandb.sandbox-gcp.wandb.ml
bucket:
name: abc-wandb-moving-pipefish
provider: gcs
mysql:
database: wandb_local
host: 10.218.0.2
name: wandb_local
password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
port: 3306
user: wandb
redis:
host: redis.example.com
port: 6379
password: password
api:
enabled: true
glue:
enabled: true
executor:
enabled: true
license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
ingress:
annotations:
ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
kubernetes.io/ingress.class: gce
kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address
```
### Hôte
```yaml theme={null}
# Fournir le FQDN avec le protocole
global:
# exemple de nom d'hôte, remplacez par le vôtre
host: https://wandb.example.com
```
### Stockage d’objets (bucket)
**AWS**
```yaml theme={null}
global:
bucket:
provider: "s3"
name: ""
kmsKey: ""
region: ""
```
**Google Cloud**
```yaml theme={null}
global:
bucket:
provider: "gcs"
name: ""
```
**Azure**
```yaml theme={null}
global:
bucket:
provider: "az"
name: ""
secretKey: ""
```
**Autres fournisseurs (Minio, Ceph et autres services de stockage compatibles S3)**
Pour les autres fournisseurs compatibles S3, définissez la configuration du bucket comme suit :
```yaml theme={null}
global:
bucket:
# Exemples de valeurs, remplacez-les par les vôtres
provider: s3
name: storage.example.com
kmsKey: null
path: wandb
region: default
accessKey: 5WOA500...P5DK7I
secretKey: HDKYe4Q...JAp1YyjysnX
```
Pour un stockage compatible S3 hébergé en dehors d’AWS, `kmsKey` doit être `null`.
Pour faire référence à `accessKey` et `secretKey` depuis un secret :
```yaml theme={null}
global:
bucket:
# Exemples de valeurs, remplacez-les par les vôtres
provider: s3
name: storage.example.com
kmsKey: null
path: wandb
region: default
secret:
secretName: bucket-secret
accessKeyName: ACCESS_KEY
secretKeyName: SECRET_KEY
```
### MySQL
```yaml theme={null}
global:
mysql:
# Exemples de valeurs, remplacez-les par les vôtres
host: db.example.com
port: 3306
database: wandb_local
user: wandb
password: 8wtX6cJH...ZcUarK4zZGjpV
```
Pour référencer le `password` d’un secret :
```yaml theme={null}
global:
mysql:
# Exemples de valeurs, remplacez par les vôtres
host: db.example.com
port: 3306
database: wandb_local
user: wandb
passwordSecret:
name: database-secret
passwordKey: MYSQL_WANDB_PASSWORD
```
### License
```yaml theme={null}
global:
# Exemple de licence, remplacez-la par la vôtre
license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
```
Pour faire référence à la `license` à partir d’un secret :
```yaml theme={null}
global:
licenseSecret:
name: license-secret
key: CUSTOMER_WANDB_LICENSE
```
### Ingress
Voir [Comment identifier la classe d’ingress Kubernetes](#how-to-identify-the-kubernetes-ingress-class).
**Sans TLS**
```yaml theme={null}
global:
# IMPORTANT : Ingress est au même niveau dans le YAML que 'global' (pas un enfant)
ingress:
class: ""
```
**Avec TLS**
Créez un secret contenant le certificat
```console theme={null}
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
```
Indiquez le secret dans la configuration d’ingress
```yaml theme={null}
global:
# IMPORTANT : Ingress est au même niveau dans le YAML que 'global' (et non un enfant)
ingress:
class: ""
annotations:
{}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
tls:
- secretName: wandb-ingress-tls
hosts:
-
### Comptes de service Kubernetes personnalisés
Spécifiez des comptes de service Kubernetes personnalisés pour exécuter les pods W\&B.
L’extrait suivant crée un compte de service dans le déploiement avec le nom indiqué :
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: true
parquet:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
Les sous-systèmes "app" et "parquet" s’exécutent avec le compte de service spécifié. Les autres sous-systèmes s’exécutent avec le compte de service par défaut.
Si le compte de service existe déjà sur le cluster, définissez `create: false` :
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: false
parquet:
serviceAccount:
name: custom-service-account
create: false
global:
...
```
Vous pouvez spécifier des comptes de service pour différents sous-systèmes, tels que app, parquet, console et autres :
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: true
console:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
Les comptes de service peuvent varier d’un sous-système à l’autre :
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: false
console:
serviceAccount:
name: another-custom-service-account
create: true
global:
...
```
### Redis externe
```yaml theme={null}
redis:
install: false
global:
redis:
host: ""
port: 6379
password: ""
parameters: {}
caCert: ""
```
Pour référencer le `password` à partir d’un secret :
```console theme={null}
kubectl create secret generic redis-secret --from-literal=redis-password=supersecret
```
Faites-y référence dans la configuration suivante :
```yaml theme={null}
redis:
install: false
global:
redis:
host: redis.example
port: 9001
auth:
enabled: true
secret: redis-secret
key: redis-password
```
### LDAP
### OIDC SSO
```yaml theme={null}
global:
auth:
sessionLengthHours: 720
oidc:
clientId: ""
secret: ""
# À inclure uniquement si votre IdP l'exige.
authMethod: ""
issuer: ""
```
`authMethod` est facultatif.
### SMTP
```yaml theme={null}
global:
email:
smtp:
host: ""
port: 587
user: ""
password: ""
```
### Variables d’environnement
```yaml theme={null}
global:
extraEnv:
GLOBAL_ENV: "example"
```
### Définir les limites de débit
Pour les déploiements en Cloud dédié et Autogéré qui utilisent l’opérateur, vous pouvez aussi configurer des limites de débit en définissant des variables d’environnement dans `spec.values.global.extraEnv`. À titre indicatif, cet exemple définit explicitement chaque limite de débit sur sa valeur par défaut. En pratique, définissez une limite de débit uniquement pour redéfinir la valeur par défaut.
### Contexte de sécurité personnalisé
Chaque composant W\&B prend en charge des configurations de contexte de sécurité personnalisées sous la forme suivante :
```yaml theme={null}
pod:
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 0
fsGroup: 1001
fsGroupChangePolicy: Always
seccompProfile:
type: RuntimeDefault
container:
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
```
## Référence de configuration pour l’opérateur W\&B
Cette section décrit les options de configuration de l’opérateur Kubernetes W\&B (`wandb-controller-manager`). L’opérateur reçoit sa configuration sous la forme d’un fichier YAML.
Par défaut, l’opérateur Kubernetes W\&B n’a pas besoin de fichier de configuration. Créez un fichier de configuration si nécessaire. Par exemple, vous pouvez en avoir besoin pour spécifier des autorités de certification personnalisées, déployer dans un environnement isolé (air gap), etc.
Consultez la liste complète des personnalisations de la spécification [dans le dépôt Helm](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml).
### CA personnalisée
Une autorité de certification personnalisée (`customCACerts`) correspond à une liste pouvant contenir plusieurs certificats. Une fois ajoutées, ces autorités de certification s’appliquent uniquement à l’opérateur Kubernetes W\&B (`wandb-controller-manager`).
```yaml theme={null}
customCACerts:
- |
-----BEGIN CERTIFICATE-----
MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
-----END CERTIFICATE-----
```
Les certificats CA peuvent également être stockés dans une ConfigMap :
```yaml theme={null}
caCertsConfigMap: custom-ca-certs
```
Le ConfigMap doit se présenter ainsi :
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
## FAQ
### Objectif et rôle de chaque pod
Un déploiement du serveur W\&B inclut les pods suivants :
* **`wandb-app`**: le cœur de W\&B, y compris l’API GraphQL et l’application frontend. Il assure la majeure partie des fonctionnalités de la plateforme W\&B.
* **`wandb-console`**: la console d’administration, accessible via `/console`.
* **`wandb-otel`**: l’agent OpenTelemetry, qui collecte les métriques et les journaux des ressources au niveau de Kubernetes pour les afficher dans la console d’administration.
* **`wandb-prometheus`**: le serveur Prometheus, qui capture les métriques de différents composants pour les afficher dans la console d’administration.
* **`wandb-parquet`**: un microservice backend distinct du pod `wandb-app` qui exporte les données de la base de données vers le stockage d’objets au format Parquet.
* **`wandb-weave`**: un autre microservice backend qui charge les tables de requête dans l’UI et prend en charge diverses fonctionnalités essentielles de l’application.
* **`wandb-weave-trace`**: un framework pour le suivi, l’expérimentation, l’évaluation, le déploiement et l’amélioration d’applications basées sur des LLM. Le framework est accessible via le pod `wandb-app`.
### Comment obtenir le mot de passe de la console de l’opérateur W\&B
Voir [Accéder à la console de gestion W\&B](#access-the-wb-management-console).
### Comment accéder à la console de l’opérateur W\&B si l’ingress ne fonctionne pas
Exécutez la commande suivante sur un hôte ayant accès au cluster Kubernetes :
```console theme={null}
kubectl port-forward svc/wandb-console 8082
```
Ouvrez la console dans votre navigateur à l’adresse `https://localhost:8082/`.
Pour savoir comment obtenir le mot de passe (option 2), voir [Accéder à la console de gestion W\&B](#access-the-wb-management-console).
### Comment consulter les journaux de W\&B Server
Le pod de l’application s’appelle **wandb-app-xxx**.
```console theme={null}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
### Comment identifier la classe d’ingress Kubernetes
Vous pouvez obtenir la classe d’ingress installée dans votre cluster en exécutant
```console theme={null}
kubectl get ingressclass
```