---
title: Mettre à niveau Claude Managed Agents auto-hébergé
url: https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade
description: Mettre à niveau un déploiement Claude Managed Agents auto-hébergé sur Kubernetes ou Docker Compose, et revenir en arrière si la nouvelle version ne fonctionne pas.
---
Pour demander l’accès à Claude Managed Agents auto-hébergé, contactez l’équipe de votre compte Anthropic.
Cette page explique comment mettre à niveau un déploiement sur Kubernetes ou Docker Compose, et comment revenir en arrière. Sur Kubernetes, le temps d’arrêt dépend de l’ampleur de la mise à niveau :
| Mise à niveau | Sauvegarder d’abord la base de données | Temps d’arrêt sur Kubernetes |
| ---------------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Version de correctif : seul le troisième nombre change | Non. Le schéma de la base de données reste le même. | Aucun |
| Mineure : le deuxième nombre augmente de un, par exemple de `1.2.0` à `1.3.0` | Oui. Le schéma change. | Aucun, sauf si une section de `CHANGELOG.md` indique que les serveurs doivent être arrêtés |
| Saute une version mineure, par exemple de `1.1.0` à `1.3.0`, ou change le premier nombre | Oui. Le schéma change. | Depuis le moment où vous arrêtez les anciens serveurs jusqu’à ce que les nouveaux soient prêts |
Une pile Docker Compose est indisponible pendant son redémarrage, quel que soit le type de mise à niveau.
## Avant la mise à niveau
Lisez la section de la nouvelle version dans `CHANGELOG.md`, à la racine de l’archive extraite. Elle commence par les étapes de mise à niveau propres à cette version. Si vous sautez des versions, suivez chaque section plus récente que votre version, de la plus ancienne à la plus récente.
Parcourez ensuite [Paramètres et chemins à vérifier](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#settings-and-paths-to-check).
Une mise à niveau mineure ou majeure comprend une sauvegarde de la base de données. Le dump contient toutes les conversations en clair ; les commandes de cette page le chiffrent donc avec l’[outil de chiffrement age](https://age-encryption.org). Créez une paire de clés une seule fois, et conservez la clé privée, `cma-backup.agekey`, à l’écart des sauvegardes :
```bash
age-keygen -o cma-backup.agekey
age-keygen -y cma-backup.agekey > cma-backup.agepub
```
## Mettre à niveau sur Kubernetes
Les commandes `kubectl` de cette page lisent le nom du Deployment du serveur depuis une variable shell. Exécutez ces deux lignes dans chaque terminal où vous exécutez les commandes. La première ligne recherche le nom, et la seconde l’affiche :
```bash
server=$(kubectl -n cma-server get deployment -l anthropic.com/role=server -o jsonpath='{.items[*].metadata.name}')
echo "$server"
```
Si la deuxième ligne affiche `cma-server`, continuez. Si elle affiche un autre nom, lisez [les noms de vos objets](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#object-names) avant la mise à niveau. Si elle n’affiche rien, vérifiez que `kubectl` pointe vers le bon cluster, et exécutez à nouveau les deux lignes.
Extrayez la nouvelle archive. Construisez et publiez ses trois images sous la nouvelle version, comme dans [Construire et publier les images](https://platform.claude.com/docs/fr/managed-agents/self-hosted/kubernetes#build-and-push-the-images). Si vous exécutez la [passerelle de sortie](https://platform.claude.com/docs/fr/managed-agents/self-hosted/agent-identity#environment-variable-credentials), construisez et publiez également son image.
Si vous construisez votre propre image de sandbox, reconstruisez-la et publiez-la également, sous la nouvelle version. Comparez son Dockerfile avec `kubernetes/sandbox/Dockerfile` dans la nouvelle archive, et consultez [ce dont votre propre image a besoin](https://platform.claude.com/docs/fr/managed-agents/self-hosted/call-the-api#what-an-image-of-your-own-needs).
Si un fichier de valeurs définit `image.tag`, remplacez-le par la nouvelle version.
Effectuez cette étape uniquement dans les cas suivants :
* Un serveur que vous exécutez a plus d’une version mineure de retard sur la nouvelle version.
* Le premier nombre, la version majeure, augmente.
* Une section de `CHANGELOG.md` plus récente que la version que vous exécutez indique que les serveurs doivent être arrêtés.
De cette étape jusqu’à ce que les nouveaux serveurs soient prêts, les clients ne peuvent pas atteindre le déploiement ; prévoyez donc une fenêtre de maintenance.
```bash
kubectl -n cma-server scale deployment/$server --replicas=0
kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s
```
Faites ceci avant une mise à niveau mineure ou majeure, ou si vous avez arrêté les serveurs. Si l’ancienne version ne peut pas fonctionner avec le schéma modifié, cette sauvegarde est le seul moyen de revenir en arrière.
Utilisez `pg_dump` de la même version majeure de PostgreSQL que votre serveur de base de données. Pour `` et ``, utilisez les valeurs `user` et `dbname` de `database.url` dans `cma-server-values.yaml`. `pg_dump` demande le mot de passe du rôle.
```bash
set -o pipefail
PGSSLMODE=require pg_dump -h -U -d -Fc \
| age -r "$(cat cma-backup.agepub)" -o cma_server-.dump.age
```
Si l’une des commandes affiche une erreur, le fichier qu’elle laisse n’est pas une sauvegarde. Corrigez la cause et exécutez à nouveau la commande avant de poursuivre.
Si les serveurs sont en cours d’exécution, la sauvegarde ne contient que ce que les clients ont écrit avant le démarrage du dump.
Exécutez ces commandes depuis le répertoire racine de la nouvelle archive, en utilisant les fichiers de valeurs de votre installation :
```bash
helm upgrade cma-server kubernetes/server/chart --namespace cma-server -f cma-server-values.yaml --wait
helm upgrade cma kubernetes/chart --namespace cma -f cma-values.yaml --wait
```
Si vous exécutez plusieurs environnements, exécutez la deuxième commande pour chaque release de sandbox, avec le nom, l’espace de noms et le fichier de valeurs de cette release.
Si vous avez arrêté les serveurs, la première commande migre le schéma, rétablit le nombre de serveurs et rend la main une fois les nouveaux serveurs prêts.
Lorsque les serveurs sont en cours d’exécution, Helm démarre chaque nouveau serveur avant d’en arrêter un ancien, de sorte que le nombre de serveurs prêts ne diminue jamais. Lors d’une mise à niveau mineure, la première commande modifie le schéma pendant que les anciens serveurs continuent de servir les requêtes, puis elle les remplace. Un flux d’événements ouvert sur un serveur en cours de remplacement se termine proprement ; un client qui suit un flux doit donc se reconnecter.
Si une commande échoue, consultez [Si la mise à niveau échoue](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#if-the-upgrade-fails).
## Mettre à niveau sur Docker Compose
Les étapes sont les mêmes pour tous les types de mise à niveau. Exécutez chaque commande `docker compose` depuis le répertoire Compose d’une version, c’est-à-dire le répertoire qui contient `docker-compose.yml`. Dans l’archive extraite, ce répertoire est `compose`. Utilisez un terminal où `ANTHROPIC_BASE_URL`, `ANTHROPIC_API_KEY` et `ANTHROPIC_AUTH_TOKEN` ne sont pas définies, car Compose transmet au serveur les valeurs de ces variables définies dans le shell.
Faites ceci avant une mise à niveau mineure ou majeure, depuis le répertoire Compose de l’ancienne version :
```bash
set -o pipefail
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
| age -r "$(cat cma-backup.agepub)" -o cma_server-.dump.age
```
Dans la commande, laissez `$POSTGRES_USER` et `$POSTGRES_DB` tels quels. Le texte entre guillemets simples s’exécute à l’intérieur du conteneur `postgres`, qui contient les noms de son rôle et de sa base de données dans ces variables.
La pile continue de servir les requêtes pendant la sauvegarde ; le dump ne contient donc pas ce que les clients écrivent après le démarrage du dump. Si l’une des commandes affiche une erreur, le fichier qu’elle laisse n’est pas une sauvegarde. Corrigez la cause et exécutez à nouveau la commande avant de poursuivre.
Placez la nouvelle archive dans un répertoire où la nouvelle version peut rester, par exemple le répertoire parent de l’ancienne version. Les commandes extraient l’archive à cet endroit, et la nouvelle pile s’exécute à partir des fichiers extraits.
Si votre umask est plus strict que `022`, exécutez d’abord `umask 022`. Exécutez ensuite ceci depuis le répertoire Compose de l’ancienne version. À la place de ``, indiquez le chemin complet du répertoire qui contient la nouvelle archive. À la place de ``, indiquez le nom de l’archive sans `.tar.gz`.
```bash
releases=""
tar -xzf "$releases/.tar.gz" -C "$releases" && cp .env compose.config.yaml "$releases//compose/"
```
La deuxième ligne copie également vos fichiers `.env` et `compose.config.yaml` dans le répertoire `compose` extrait. L’ancienne pile continue de s’exécuter pendant les deux lignes. Si une ligne affiche une erreur, corrigez la cause et exécutez à nouveau les deux lignes.
Seuls `.env` et `compose.config.yaml` sont repris. Refaites vos autres modifications dans le répertoire Compose de la nouvelle version :
* **Un fichier que vous avez ajouté :** copiez-le.
* **Un fichier fourni que vous avez modifié :** apportez la même modification dans la copie de la nouvelle version. Ne copiez pas l’ancien fichier par-dessus, car cela annule les modifications que la version a apportées au fichier.
* **Identité de l’agent :** copiez le répertoire `agent-identity` avec `cp -a`, en utilisant `sudo` si root en est propriétaire, et modifiez à nouveau le bloc `volumes:` de `docker-compose.yml`.
* **Un fichier Compose personnel :** copiez-le et vérifiez ses chemins relatifs.
Apportez ensuite les modifications Docker Compose de [Paramètres et chemins à vérifier](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#settings-and-paths-to-check).
Exécutez ces lignes dans le terminal où vous avez extrait l’archive, car elles utilisent sa variable `$releases`. Restez dans le répertoire Compose de l’ancienne version, et indiquez le même nom à la place de ``. Si vous avez exporté `COMPOSE_FILE` pour l’ancienne pile, exportez d’abord la même valeur.
```bash
ls "$releases//compose/.env" && docker compose down
cd "$releases//compose" && docker compose up --build -d
```
La première ligne n’arrête l’ancienne pile que si le `.env` de la nouvelle version est en place. `docker compose down` conserve la base de données. N’ajoutez pas `-v`, qui la supprime. La nouvelle pile reprend la base de données, et son conteneur `migrate` met à jour le schéma avant le démarrage du serveur.
Si une commande échoue, consultez [Si la mise à niveau échoue](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#if-the-upgrade-fails).
## Si la mise à niveau échoue
Avant de revenir en arrière, trouvez la cause dans le journal :
* **Kubernetes :** si le Job de migration échoue, `helm upgrade` attend quelques minutes pendant que le Job effectue de nouvelles tentatives, puis échoue. Pendant cette attente, exécutez `kubectl -n cma-server logs job/$server-migrate` dans un second terminal, avec `$server` défini comme dans [Mettre à niveau sur Kubernetes](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes). Kubernetes supprime le journal lorsque le Job cesse ses nouvelles tentatives. Si vous l’avez manqué, exécutez à nouveau `helm upgrade`, ce qui relance le Job.
* **Docker Compose :** la sortie de `docker compose up --build -d` peut ne pas indiquer la raison. Exécutez `docker compose logs` pour la trouver.
| Ce qu’affiche le journal | Ce que cela signifie | Que faire |
| ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Une ligne contenant `refusing to migrate: servers of another release are still running against this database` | Certaines mises à niveau exigent que tous les serveurs soient arrêtés au préalable, et un serveur de l’ancienne version est encore en cours d’exécution. La migration n’a rien modifié. | Arrêtez tous les serveurs, comme dans [Mettre à niveau sur Kubernetes](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes), et exécutez à nouveau `helm upgrade`. Si un serveur ne s’est pas arrêté proprement, attendez d’abord 20 secondes : jusque-là, la migration considère toujours ce serveur comme en cours d’exécution. |
| Une ligne contenant `cannot downgrade`, lorsque vous déployez à nouveau l’ancienne version | L’ancienne version ne peut pas s’exécuter sur le schéma modifié. | Restaurez la sauvegarde, comme dans [Revenir en arrière](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#roll-back). |
| Une autre erreur de la migration | Vous n’avez pas besoin de revenir en arrière. Sur Kubernetes, les serveurs restent tels qu’ils étaient jusqu’à ce que la migration réussisse. | Corrigez la cause, et exécutez à nouveau `helm upgrade` ou `docker compose up --build -d`. |
La migration peut réussir sans que les nouveaux serveurs deviennent prêts. Pour trouver la cause, lisez le journal des serveurs :
* **Kubernetes :** `kubectl -n cma-server logs -l anthropic.com/role=server --prefix --tail=20`
* **Docker Compose :** `docker compose logs cma-server`
Par exemple, sur Kubernetes, une ligne contenant `has invalid keys` nomme un paramètre sous `server.config` que la nouvelle version n’accepte pas. Corrigez la cause et exécutez à nouveau la commande de mise à niveau avant d’envisager une restauration, car une restauration entraîne une perte de données. Sur Kubernetes, une fois le schéma modifié, un serveur de l’ancienne version en cours d’exécution continue de servir les requêtes, mais il risque de ne pas redémarrer s’il s’arrête.
## Revenir en arrière
Les commandes `kubectl` de cette section utilisent la variable `$server` de [Mettre à niveau sur Kubernetes](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes). Avant de revenir en arrière, consultez [Si la mise à niveau échoue](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#if-the-upgrade-fails). Revenez ensuite en arrière selon le type de mise à niveau :
* **Après une mise à niveau vers une version de correctif :** [Déployer à nouveau l’ancienne version](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#deploy-the-old-release-again). Les deux versions utilisent le même schéma.
* **Après une mise à niveau mineure ou majeure :** ouvrez `CHANGELOG.md` dans la nouvelle archive. Lisez la section de chaque version parue après celle vers laquelle vous revenez.
* Si une section indique que l’ancienne version ne peut pas démarrer sur la base de données migrée, restaurez la sauvegarde.
* Sinon, déployez à nouveau l’ancienne version. Si cela échoue avec `cannot downgrade`, restaurez la sauvegarde.
Une restauration fait perdre tout ce que les clients ont écrit après le début de la sauvegarde.
### Déployer à nouveau l’ancienne version
* **Kubernetes :** allez dans le répertoire de premier niveau de l’ancienne archive. Exécutez les deux commandes `helm upgrade` de [Mettre à niveau sur Kubernetes](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes), avec les fichiers de valeurs tels qu’ils étaient pour cette version. Par exemple, si vous avez ajouté `earlierNames` pour la mise à niveau, retirez-le. N’exécutez la deuxième commande que lorsque la première réussit.
* **Docker Compose :** exécutez `docker compose down` dans le répertoire Compose de la nouvelle version, puis `docker compose up --build -d` dans celui de l’ancienne.
Si l’ancienne version ne peut pas s’exécuter sur le schéma modifié, le journal affiche `cannot downgrade` :
* **Kubernetes :** le Job de migration échoue et les serveurs restent tels qu’ils sont. [Si la mise à niveau échoue](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#if-the-upgrade-fails) explique comment lire le journal du Job.
* **Docker Compose :** le serveur ne démarre pas. Lisez le journal avec `docker compose logs migrate`.
Sur Docker Compose, la sortie de `docker compose logs` peut plutôt afficher `stored value is encrypted but no encryption key is configured`. Dans ce cas, le fichier `.env` de l’ancienne version ne contient pas de ligne `CMA_STORE__CREDENTIALS_ENCRYPTION_KEY`. Copiez cette ligne depuis le fichier `.env` de la nouvelle version, et exécutez à nouveau `docker compose up --build -d`.
### Restaurer la sauvegarde sur Kubernetes
Votre serveur de base de données doit disposer de l’espace nécessaire pour une deuxième copie de la base de données. Pour `` et ``, utilisez les valeurs `user` et `dbname` de `database.url` dans `cma-server-values.yaml`.
Connectez-vous à la base de données `postgres` de votre serveur de base de données en tant qu’administrateur, et exécutez :
```sql
CREATE DATABASE _restored OWNER ;
```
Ensuite, sur la machine qui contient la sauvegarde, exécutez cette commande avec les chemins de votre clé et de votre fichier de sauvegarde. Utilisez un `pg_restore` de la même version majeure que votre serveur de base de données. Il demande le mot de passe du rôle et n’affiche rien s’il réussit.
```bash
age -d -i cma-backup.agekey cma_server-.dump.age \
| PGSSLMODE=require pg_restore -h -U -d _restored --no-owner --exit-on-error
```
Si ceci affiche une erreur, arrêtez-vous. Votre base de données n’a pas changé. Exécutez `DROP DATABASE _restored;` en tant qu’administrateur, et recommencez cette étape.
```bash
kubectl -n cma-server scale deployment/$server --replicas=0
kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s
```
Connectez-vous à la base de données `postgres` en tant qu’administrateur, et exécutez :
```sql
ALTER DATABASE RENAME TO _upgraded;
ALTER DATABASE _restored RENAME TO ;
```
Si la première instruction indique que d’autres sessions utilisent la base de données, fermez ces sessions et exécutez à nouveau les deux instructions. Un pooler de connexions peut maintenir de telles sessions.
Suivez l’élément Kubernetes de [Déployer à nouveau l’ancienne version](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#deploy-the-old-release-again). La première commande rétablit également le nombre de serveurs. Si elle échoue mais que `kubectl -n cma-server get pods` montre que les anciens serveurs sont prêts, consultez [Si la vérification de la clé échoue](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#if-the-key-check-fails).
Cette base de données contient encore ce que les clients ont écrit après la sauvegarde. Lorsque l’ancienne version fonctionne, supprimez-la avec `DROP DATABASE _upgraded;`.
#### Si la vérification de la clé échoue
À l’étape « Déployer l’ancienne version », la première commande `helm upgrade` attend que les anciens serveurs soient prêts. Elle vérifie ensuite la clé avec laquelle les sandboxes se connectent. Si la commande échoue mais que `kubectl -n cma-server get pods` montre que les anciens serveurs sont prêts, cette vérification a échoué.
Vos données sont restaurées et les serveurs fonctionnent, mais les sandboxes ne peuvent pas encore s’y connecter. Les sandboxes se connectent avec une clé du Secret `cma-environment` de leur propre espace de noms, `cma`. Cette clé est plus récente que votre sauvegarde ; la base de données restaurée ne la reconnaît donc pas.
Pour confirmer la cause, exécutez à nouveau la première commande. Pendant qu’elle attend, ouvrez un second terminal et définissez-y également `$server`. Exécutez ensuite `kubectl -n cma-server logs job/$server-environment-default`, en remplaçant `default` par le nom de votre environnement. Cherchez une ligne contenant `Secret cma/cma-environment records key`. Si le journal affiche une autre erreur, corrigez ce qu’elle indique.
Si le journal affiche cette ligne, supprimez le Secret avec `kubectl -n cma delete secret cma-environment`, et exécutez à nouveau la première commande. Elle recrée le Secret, avec une nouvelle clé. Exécutez ensuite la deuxième commande.
### Restaurer la sauvegarde sur Docker Compose
Exécutez `docker compose down` dans le répertoire Compose de la nouvelle version. Exécutez ensuite `docker compose up -d --wait postgres` dans le répertoire Compose de l’ancienne version. Restez dans ce répertoire pour les étapes suivantes.
Depuis le répertoire Compose de l’ancienne version, exécutez ceci avec les chemins de votre clé et de votre fichier de sauvegarde :
```bash
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres \
-c "DROP DATABASE IF EXISTS ${POSTGRES_DB}_restored" -c "CREATE DATABASE ${POSTGRES_DB}_restored"' \
&& age -d -i cma-backup.agekey cma_server-.dump.age \
| docker compose exec -T postgres sh -c 'pg_restore -U "$POSTGRES_USER" -d "${POSTGRES_DB}_restored" --no-owner --exit-on-error'
```
La commande a fonctionné si elle affiche `DROP DATABASE` et `CREATE DATABASE`, et aucune erreur.
Laissez `$POSTGRES_USER` et `$POSTGRES_DB` tels quels, ici et dans les étapes suivantes. Le texte entre guillemets simples s’exécute à l’intérieur du conteneur `postgres`, qui contient les noms de son rôle et de sa base de données dans ces variables.
Si elle affiche une erreur, votre base de données n’a pas changé ; vous pouvez donc exécuter à nouveau la commande entière. Si la sauvegarde ne peut pas être restaurée, exécutez `docker compose up --build -d` dans le répertoire Compose de la nouvelle version pour redémarrer cette version.
```bash
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres \
-c "ALTER DATABASE $POSTGRES_DB RENAME TO ${POSTGRES_DB}_upgraded" \
-c "ALTER DATABASE ${POSTGRES_DB}_restored RENAME TO $POSTGRES_DB"'
```
Exécutez `docker compose up --build -d`.
Cette base de données contient encore ce que les clients ont écrit après la sauvegarde. Lorsque l’ancienne version fonctionne, supprimez-la :
```bash
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres -c "DROP DATABASE ${POSTGRES_DB}_upgraded"'
```
### Après une restauration
Une restauration ramène les clés d’environnement à l’état où elles étaient au moment de la sauvegarde :
* **Une clé que vous avez révoquée après la sauvegarde :** elle fonctionne de nouveau. Révoquez-la à nouveau.
* **Une clé que vous avez créée après la sauvegarde :** elle a disparu. Créez une nouvelle clé pour les workers qui l’utilisaient.
[Remplacer une clé d’environnement pour vos propres workers](https://platform.claude.com/docs/fr/managed-agents/self-hosted/kubernetes#replace-an-environment-key-for-your-own-workers) contient les commandes, qui fonctionnent également sur Docker Compose. Les sandboxes que la pile Docker Compose démarre ne nécessitent aucune action, car la pile remplace leur clé à son démarrage.
Pour lister les clés d’un environnement, y compris les clés révoquées, exécutez `list-keys` comme suit :
* Utilisez le terminal que vous avez configuré dans [Appeler l’API sur un serveur auto-hébergé](https://platform.claude.com/docs/fr/managed-agents/self-hosted/call-the-api). N’utilisez pas le terminal qui exécute `docker compose`.
* Sur Kubernetes, exécutez d’abord `kubectl -n cma-server port-forward svc/$server 8400:8400` dans un autre terminal, avec `$server` défini également dans celui-ci.
* Exécutez la commande depuis le répertoire de premier niveau de l’archive, une fois pour chaque environnement, avec l’ID de cet environnement.
```bash
echo "$ANTHROPIC_API_KEY" | ./cma-server-admin list-keys \
-base-url http://127.0.0.1:8400 -env env_01595EKxaaTTGwwY3kyXdtbs \
-key-file - -all
```
### Tester une sauvegarde
Pour prouver qu’un dump peut être restauré, exécutez uniquement l’étape « Restaurer la sauvegarde dans une nouvelle base de données ». Elle se trouve dans [Restaurer la sauvegarde sur Kubernetes](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#restore-the-backup-on-kubernetes) et dans [Restaurer la sauvegarde sur Docker Compose](https://platform.claude.com/docs/fr/managed-agents/self-hosted/upgrade#restore-the-backup-on-docker-compose). Cette étape ne modifie pas la base de données en cours d’utilisation. Supprimez ensuite la nouvelle base de données. Sur Docker Compose, son nom est celui de votre base de données suivi de `_restored`.
## Paramètres et chemins à vérifier
Lisez cette section avant d’exécuter une commande de mise à niveau.
Vérifiez la section `web_tools` de votre [fichier de paramètres](https://platform.claude.com/docs/fr/managed-agents/self-hosted/configuration-reference#where-settings-go). Si le fichier ne contient pas une telle section, ou si la section ne définit aucune clé, les outils `web_search` et `web_fetch` sont désactivés après la mise à niveau. Un agent qui utilise l’ensemble d’outils par défaut s’exécute alors sans eux, sans erreur. Un agent dont l’ensemble d’outils active l’un ou l’autre de ces outils ne peut pas démarrer de session. Pour conserver les outils, consultez [Les outils web nécessitent un paramètre du serveur](https://platform.claude.com/docs/fr/managed-agents/self-hosted/differences#web-tools-need-a-server-setting).
Sur Kubernetes, vérifiez que chaque fichier de valeurs de sandbox, tel que `cma-values.yaml`, définit `egress.mode`. Pour conserver l’accès de vos sandboxes à l’internet public, ajoutez `mode: publicInternet` sous `egress`. Si un fichier ne définit aucun mode, le chart applique son mode par défaut, `closed`. La commande `helm upgrade` du chart de sandbox s’arrête alors avec une erreur telle que `egress.mode is closed and egress.closed.hosts is empty`, et ne modifie rien.
Vérifiez `sandbox.idleTimeout` dans les mêmes fichiers. Si un fichier ne le définit pas, le pod d’une session disparaît environ 5 minutes après la fin du tour de l’agent. Les processus que l’agent a laissés en cours d’exécution s’arrêtent avec le pod. Par défaut, les fichiers de `/workspace` sont conservés. Pour conserver le pod pendant 30 minutes, ajoutez `idleTimeout: 30m` sous `sandbox`.
Recherchez `inference.attribution` dans le fichier de paramètres, et `CMA_INFERENCE__ATTRIBUTION` dans l’environnement du serveur. Supprimez la ligne si vous en trouvez une. La version vers laquelle vous effectuez la mise à niveau ne possède pas ce paramètre, et son serveur ne démarre pas si l’un ou l’autre est défini.
Lorsque l’API Claude est votre fournisseur d’inférence, chaque appel de modèle transporte, après la mise à niveau, les ID de sa session ainsi que de l’agent et de l’environnement de cette session. Consultez [Ce que le serveur envoie à son fournisseur d’inférence](https://platform.claude.com/docs/fr/managed-agents/self-hosted-data-and-access#what-the-server-sends-to-its-inference-provider).
### Kubernetes : les noms de vos objets
`cma-server-values.yaml` doit indiquer quels noms utilise votre installation, dans son paramètre `earlierNames`. Pour trouver le nom du Deployment du serveur, exécutez `kubectl -n cma-server get deployment -l anthropic.com/role=server`.
| Le nom du Deployment | La ligne dans `cma-server-values.yaml` |
| -------------------- | -------------------------------------- |
| `cma-onprem` | `earlierNames: true` |
| `cma-server` | `earlierNames: false` |
Si le fichier ne contient pas cette ligne, ajoutez-la avant la mise à niveau, et conservez-la pour toutes les mises à niveau ultérieures. Sans elle, la commande `helm upgrade` du chart du serveur s’arrête avec une erreur qui mentionne `earlierNames`, et ne modifie rien.
Avec `earlierNames: true`, les objets du chart conservent leurs noms `cma-onprem`, et les serveurs trouvent toujours les Secrets que vous avez créés sous ces noms. Ces pages utilisent les noms de la colonne du milieu. Avec `earlierNames: true`, utilisez plutôt les noms de la dernière colonne :
| Objet | Nom dans ces pages | Nom avec `earlierNames: true` |
| ------------------------------------------------------------------ | ------------------------------- | ------------------------------- |
| Le Deployment et le Service du serveur | `cma-server` | `cma-onprem` |
| Le Job de migration | `cma-server-migrate` | `cma-onprem-migrate` |
| Le Job de chaque environnement | `cma-server-environment-` | `cma-onprem-environment-` |
| Le Secret contenant le mot de passe de la base de données | `cma-server-db` | `cma-onprem-db` |
| Le Secret contenant l’identifiant du fournisseur d’inférence | `cma-server-upstream` | `cma-onprem-upstream` |
| Le Secret contenant la clé API du serveur et la clé de chiffrement | `cma-server-keys` | `cma-onprem-server` |
Quelle que soit la valeur de `earlierNames`, l’espace de noms s’appelle `cma-server`, et l’image du serveur s’appelle `cma-server-image`.
Chaque fichier de valeurs de sandbox qui définit `egress.mode: gateway` doit nommer les deux Services du serveur, sous `egress.gateway`. Si un fichier ne le fait pas, ajoutez les deux lignes. Cet exemple contient les noms pour une installation avec `earlierNames: true` :
```yaml
egress:
gateway:
serverService: cma-onprem
serverEgressService: cma-onprem-egress
```
### Docker Compose : la structure de l’archive et les chemins
Si la version à partir de laquelle vous effectuez la mise à niveau n’a pas de répertoire `compose`, son `docker-compose.yml` se trouve à la racine de l’archive, à côté de `bin`. Dans la nouvelle archive, ce fichier se trouve un niveau plus bas, dans `compose`.
À l’étape « Refaire vos autres modifications », apportez également ces modifications :
* **Un fichier Compose personnel :** si l’ancienne archive n’avait pas de répertoire `compose`, votre fichier descend également d’un niveau. Un chemin tel que `./bin` qu’il contient devient `../bin`. Si le fichier nomme le service `cma-onprem`, remplacez ce nom par `cma-server`.
* **Chemins sous `/etc/cma-onprem/` ou `/run/cma-onprem/` :** modifiez chacun d’eux pour qu’il commence par `/etc/cma-server/` ou `/run/cma-server/`. Regardez dans les fichiers `.env` et `compose.config.yaml` de la nouvelle version, dans un fichier Compose personnel et dans chaque ligne `volumes:` que vous avez ajoutée. Dans une ligne `volumes:`, modifiez uniquement la partie située après le premier deux-points, qui correspond au chemin à l’intérieur du conteneur.