> ## 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.
> Configurez une installation autogérée du serveur W&B à l'aide de variables d'environnement pour les paramètres de base de données, de stockage, Redis et IAM.
# Configurer les variables d'environnement
En plus de configurer les paramètres de l'instance via l'interface d'administration System Settings, W\&B permet également de configurer ces valeurs dans le code à l'aide de variables d'environnement. Cette page répertorie les variables d'environnement que vous pouvez définir pour contrôler la base de données, le stockage, Redis, le fournisseur d'identité et d'autres paramètres au niveau de l'instance pour un déploiement autogéré du serveur W\&B. Vous pouvez utiliser ces variables pour gérer la configuration sous forme de code plutôt que via l'interface d'administration. Pour les variables spécifiques à IAM, voir [la configuration avancée pour IAM](./iam/advanced_env_vars).
## Référence des variables d’environnement
Le tableau suivant décrit chaque variable d’environnement, le comportement qu’elle contrôle, ainsi que les éventuelles contraintes liées à sa valeur.
| Variable d’environnement | Description |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `LICENSE` | Votre licence wandb/local |
| `MYSQL` | La chaîne de connexion MySQL |
| `BUCKET` | Le bucket S3 / GCS utilisé pour stocker les données |
| `BUCKET_QUEUE` | La file d’attente SQS / Google PubSub pour les événements de création d’objet |
| `NOTIFICATIONS_QUEUE` | La file d’attente SQS sur laquelle publier les événements de run |
| `AWS_REGION` | La région AWS dans laquelle se trouve votre bucket |
| `HOST` | Le FQD de votre instance, par exemple `https://my.domain.net` |
| `OIDC_ISSUER` | Une URL vers votre fournisseur d’identité OpenID Connect, par exemple `https://cognito-idp.us-east-1.amazonaws.com/us-east-1_uiIFNdacd` |
| `OIDC_CLIENT_ID` | L’ID client de l’application auprès de votre fournisseur d’identité |
| `OIDC_AUTH_METHOD` | Implicit (par défaut) ou pkce. Pour plus de contexte, voir les sections suivantes. |
| `SLACK_CLIENT_ID` | L’ID client de l’application Slack que vous souhaitez utiliser pour les alertes |
| `SLACK_SECRET` | Le secret de l’application Slack que vous souhaitez utiliser pour les alertes |
| `LOCAL_RESTORE` | Si vous ne pouvez pas accéder à votre instance, vous pouvez temporairement définir cette valeur sur true. Consultez les journaux du conteneur pour obtenir des identifiants temporaires. |
| `REDIS` | Peut être utilisé pour configurer une instance Redis externe avec W\&B. |
| `LOGGING_ENABLED` | Lorsque cette valeur est définie sur true, les journaux d’accès sont envoyés vers stdout. Vous pouvez également monter un conteneur sidecar et suivre `/var/log/gorilla.log` sans définir cette variable. |
| `GORILLA_ALLOW_USER_TEAM_CREATION` | Lorsque cette valeur est définie sur true, elle permet aux utilisateurs non administrateurs de créer une nouvelle équipe. False par défaut. |
| `GORILLA_CUSTOMER_SECRET_STORE_SOURCE` | Définit le gestionnaire de secrets pour stocker les secrets d’équipe utilisés par W\&B Weave. Les gestionnaires de secrets suivants sont pris en charge : - Gestionnaire de secrets interne (par défaut) :
k8s-secretmanager://wandb-secret - AWS Secret Manager :
aws-secretmanager - Google Cloud Secret Manager :
gcp-secretmanager - Azure :
az-secretmanger
|
| `GORILLA_DATA_RETENTION_PERIOD` | Durée de conservation, en heures, des données supprimées des runs. Les données de run supprimées sont irrécupérables. Ajoutez un `h` à la valeur saisie. Par exemple, `"24h"`. |
| `GORILLA_DISABLE_PERSONAL_ENTITY` | Lorsque cette valeur est définie sur true, elle désactive les [entités personnelles](/fr/support/models/articles/what-is-the-difference-between-team-and-). Elle empêche la création de nouveaux projets personnels dans ces entités personnelles et empêche l’écriture dans les projets personnels existants. |
| `GORILLA_GRAPHQL_DISABLE_INTROSPECTION` | Lorsque cette valeur est définie sur true, elle désactive l’introspection GraphQL : les requêtes `__type` et `__schema` ne renvoient aucune donnée de schéma, mais la requête aboutit toujours. Sur **Autogéré**, définir le champ de configuration Gorilla `graphql-disable-introspection` a le même effet. Définissez cette variable sous `spec.values.global.extraEnv` dans votre ressource personnalisée `WeightsAndBiases` (voir l’[exemple `global.extraEnv`](/fr/platform/hosting/self-managed/operator#ldap) dans le guide de l’opérateur). **Les applications clientes nécessitent [W\&B SDK v0.26.0](/fr/release-notes/sdk-releases#0-26-0) ou une version ultérieure** pour fonctionner avec des déploiements où l’introspection est déjà désactivée. |
| `GRAPHQL_REJECT_UNAUTHED_REQUESTS` | Lorsque cette valeur est définie sur `true` sur le service **API**, les requêtes GraphQL qui ne sont associées à aucun utilisateur authentifié sont rejetées. Les requêtes non authentifiées reçoivent une réponse HTTP 401. **Autogéré** et **Cloud dédié** v0.80.0+ uniquement ; non disponible sur Cloud mutualisé. Cette fonctionnalité est facultative : si la variable d’environnement n’est pas définie ou n’est pas `true`, le comportement reste inchangé. Définissez-la uniquement sur le composant API (par exemple, `api.env` dans les valeurs Helm). Avant de l’activer, vérifiez que les flux de travail qui reposent sur un accès GraphQL anonyme (comme l’affichage de reports partagés sans se connecter, ou des Open Projects) répondent toujours à vos exigences. Sur **Autogéré**, définir le champ de configuration Gorilla `graphql-reject-unauthed-requests` sur `true` a le même effet. |
| `GORILLA_ARTIFACT_GC_ENABLED` | Lorsque cette valeur est définie sur true, elle active le nettoyage automatique des Artifacts supprimés. Requis pour les déploiements Autogéré. Voir [Supprimer un artifact](/fr/models/artifacts/delete-artifacts) pour plus d’informations. |
| `WANDB_ARTIFACT_DIR` | Emplacement où stocker tous les Artifacts téléchargés. Si cette variable n’est pas définie, l’emplacement par défaut est le répertoire `artifacts` relatif à votre script d’entraînement. Assurez-vous que ce répertoire existe et que l’utilisateur en cours d’exécution a l’autorisation d’y écrire. Cela ne contrôle pas l’emplacement des fichiers de métadonnées générés, que vous pouvez définir à l’aide de la variable d’environnement `WANDB_DIR`. |
| `WANDB_DATA_DIR` | Emplacement où téléverser les Artifacts intermédiaires. L’emplacement par défaut dépend de votre plateforme, car il utilise la valeur de `user_data_dir` du package Python `platformdirs`. Assurez-vous que ce répertoire existe et que l’utilisateur en cours d’exécution a l’autorisation d’y écrire. |
| `WANDB_DIR` | Emplacement où stocker tous les fichiers générés. Si cette variable n’est pas définie, l’emplacement par défaut est le répertoire `wandb` relatif à votre script d’entraînement. Assurez-vous que ce répertoire existe et que l’utilisateur en cours d’exécution a l’autorisation d’y écrire. Cela ne contrôle pas l’emplacement des Artifacts téléchargés, que vous pouvez définir à l’aide de la variable d’environnement `WANDB_ARTIFACT_DIR`. |
| `WANDB_IDENTITY_TOKEN_FILE` | Pour la [fédération d’identités](/fr/platform/hosting/iam/identity_federation/), le chemin absolu vers le répertoire local où sont stockés les JSON Web Tokens (JWT). |
* Utilisez la variable d'environnement `GORILLA_DATA_RETENTION_PERIOD` avec prudence. Elle s'applique aux **données de run supprimées** (y compris les fichiers associés au run, comme les médias, après les opérations de suppression). Elle ne supprime **pas** les artifacts ; utilisez la suppression d'artifact et `GORILLA_ARTIFACT_GC_ENABLED` comme décrit dans [Supprimer un artifact](/fr/models/artifacts/delete-artifacts). Pour comprendre le lien entre la suppression des runs et des fichiers, le stockage et ce paramètre, voir [Quand les données de run supprimées sont retirées du stockage](/fr/models/runs/delete-runs#when-deleted-run-data-is-removed-from-storage) dans **Supprimer des runs**. Une fois la variable définie, les données sont supprimées selon la période de rétention. Sauvegardez à la fois la base de données et le bucket de stockage avant d'activer ou de modifier cette valeur.
La suppression en arrière-plan des objets de votre bucket est **approximative** et n'est pas garantie dans un délai précis. Pour connaître le comportement attendu, les étapes de dépannage et le lien avec les coûts de stockage, voir [Gérer le stockage et les coûts du bucket](/fr/platform/hosting/managing-bucket-storage).
* Pour activer `GRAPHQL_REJECT_UNAUTHED_REQUESTS` avec le [Kubernetes Operator](/fr/platform/hosting/self-managed/operator), définissez-le uniquement sur le composant API :
```yaml theme={null}
api:
env:
GRAPHQL_REJECT_UNAUTHED_REQUESTS: "true"
```
Appliquez vos modifications et attendez que les pods de l’API soient mis à jour avant de vérifier le paramètre. Vous pouvez désactiver ce comportement en supprimant la variable ou en lui attribuant une autre valeur.
## Paramètres avancés de fiabilité
La section suivante décrit la configuration facultative que vous pouvez appliquer pour améliorer la fiabilité et les performances du déploiement de votre serveur W\&B.
### Redis
Un serveur Redis externe est facultatif, mais recommandé pour les systèmes de production. Redis contribue à améliorer la fiabilité du service et à activer la mise en cache afin de réduire les temps de chargement, en particulier dans les grands projets. Utilisez un service Redis géré tel qu'ElastiCache avec haute disponibilité (HA) et les spécifications suivantes :
* Minimum 4 Go de mémoire, 8 Go recommandés
* Version Redis 6.x
* Chiffrement en transit
* Authentification activée
Pour configurer l'instance Redis avec W\&B, accédez à la page Settings de W\&B à l'adresse `http(s)://YOUR-W&B-SERVER-HOST/system-admin`. Activez l'option **Use an external Redis instance**, puis renseignez la chaîne de connexion Redis au format suivant :
Vous pouvez également configurer Redis à l'aide de la variable d'environnement `REDIS` sur le conteneur ou dans votre déploiement Kubernetes. Vous pouvez aussi définir `REDIS` comme secret Kubernetes.
Cette page suppose que l'instance Redis s'exécute sur le port par défaut `6379`. Si vous configurez un autre port, activez l'authentification et souhaitez également activer TLS sur l'instance `redis`, le format de la chaîne de connexion est : `redis://$USER:$PASSWORD@$HOST:$PORT?tls=true`