Secrets

Les workers ont souvent besoin d'identifiants, par exemple un token pour une API externe. Les déploiements gérés les lisent depuis le Secrets Manager de l'espace de travail : vous liez un secret de l'espace de travail à une variable d'environnement, et le worker lit la valeur dans son environnement au démarrage. Seuls les secrets de l'espace de travail du déploiement peuvent être liés.

Liez un secret de l'espace de travail à votre déploiement :

# /// script
# dependencies = [
#     "mistralai>=3.0",
# ]
# ///
import os

from mistralai.client import Mistral

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

deployment = client.workflows.deployments.update_deployment(
    name="<votre-nom-de-deploiement>",
    spec={
        "backend_spec": {
            "secrets": [
                {
                    "env_var_name": "GITHUB_TOKEN",
                    "reference": "secret:workspace:github_token",
                }
            ],
        }
    },
)
print(deployment.name)
Avertissement

Modifier la valeur d'un secret ne redémarre pas automatiquement le worker. Celui-ci conserve la valeur lue au démarrage. Pour le moment, redémarrez manuellement le déploiement pour prendre en compte une nouvelle valeur.

Disponibles au build et à l'exécution

Disponibles au build et à l'exécution

Une liaison atteint le worker deux fois :

  • À l'exécution, sous forme de variable d'environnement, lue au démarrage du worker.
  • Au build, sous forme d'argument de build Docker portant le même nom. Déclarez un ARG correspondant dans le Dockerfile pour l'utiliser, par exemple pour installer des paquets depuis un registre privé :
ARG UV_INDEX_USERNAME
ARG UV_INDEX_PASSWORD

RUN uv sync --frozen --no-dev

Les arguments de build sont stockés dans l'historique et les couches de l'image, donc toute personne pouvant accéder à l'image peut récupérer les valeurs. Privilégiez des identifiants que vous pouvez renouveler, et évitez de lier des secrets sensibles pour les builds.