Mettre à niveau Claude Managed Agents auto-hébergé

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 :

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.

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. Créez une paire de clés une seule fois, et conservez la clé privée, cma-backup.agekey, à l’écart des sauvegardes :

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 :

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 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.

1. 1

   Construire et publier les nouvelles images

   Extrayez la nouvelle archive. Construisez et publiez ses trois images sous la nouvelle version, comme dans Construire et publier les images. Si vous exécutez la passerelle de sortie, 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.

2. 2

   Définir la nouvelle version dans vos fichiers de valeurs

   Si un fichier de valeurs définit image.tag, remplacez-le par la nouvelle version.

3. 3

   Arrêter tous les serveurs, si la mise à niveau l’exige

   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.

   kubectl -n cma-server scale deployment/$server --replicas=0
   kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s

   
4. 4

   Sauvegarder la base de données

   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 <role> et <database>, utilisez les valeurs user et dbname de database.url dans cma-server-values.yaml. pg_dump demande le mot de passe du rôle.

   set -o pipefail
   PGSSLMODE=require pg_dump -h <database-host> -U <role> -d <database> -Fc \
     | age -r "$(cat cma-backup.agepub)" -o cma_server-<old-version>.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.

5. 5

   Mettre à niveau le serveur, puis les sandboxes

   Exécutez ces commandes depuis le répertoire racine de la nouvelle archive, en utilisant les fichiers de valeurs de votre installation :

   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.

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.

1. 1

   Sauvegarder la base de données

   Faites ceci avant une mise à niveau mineure ou majeure, depuis le répertoire Compose de l’ancienne version :

   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-<old-version>.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.

2. 2

   Extraire la nouvelle archive

   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 <directory>, indiquez le chemin complet du répertoire qui contient la nouvelle archive. À la place de <archive>, indiquez le nom de l’archive sans .tar.gz.

   releases="<directory>"
   tar -xzf "$releases/<archive>.tar.gz" -C "$releases" && cp .env compose.config.yaml "$releases/<archive>/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.

3. 3

   Refaire vos autres modifications

   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.

4. 4

   Arrêter l’ancienne pile et démarrer la nouvelle

   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 <archive>. Si vous avez exporté COMPOSE_FILE pour l’ancienne pile, exportez d’abord la même valeur.

   ls "$releases/<archive>/compose/.env" && docker compose down
   cd "$releases/<archive>/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.

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. 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.

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. Avant de revenir en arrière, consultez Si la mise à niveau échoue. 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. 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.

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, 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 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 <role> et <database>, utilisez les valeurs user et dbname de database.url dans cma-server-values.yaml.

1. 1

   Restaurer la sauvegarde dans une nouvelle base de données

   Connectez-vous à la base de données postgres de votre serveur de base de données en tant qu’administrateur, et exécutez :

   CREATE DATABASE <database>_restored OWNER <role>;

   

   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.

   age -d -i cma-backup.agekey cma_server-<old-version>.dump.age \
     | PGSSLMODE=require pg_restore -h <database-host> -U <role> -d <database>_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 <database>_restored; en tant qu’administrateur, et recommencez cette étape.

2. 2

   Arrêter tous les serveurs

   kubectl -n cma-server scale deployment/$server --replicas=0
   kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s

   
3. 3

   Basculer vers la base de données restaurée

   Connectez-vous à la base de données postgres en tant qu’administrateur, et exécutez :

   ALTER DATABASE <database> RENAME TO <database>_upgraded;
   ALTER DATABASE <database>_restored RENAME TO <database>;

   

   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.

4. 4

   Déployer l’ancienne version

   Suivez l’élément Kubernetes de Déployer à nouveau l’ancienne version. 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.

5. 5

   Supprimer la base de données mise de côté

   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 <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

1. 1

   Démarrer uniquement la base de données

   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.

2. 2

   Restaurer la sauvegarde dans une nouvelle base de données

   Depuis le répertoire Compose de l’ancienne version, exécutez ceci avec les chemins de votre clé et de votre fichier de sauvegarde :

   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-<old-version>.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.

3. 3

   Basculer vers la base de données restaurée

   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"'

   
4. 4

   Démarrer l’ancienne version

   Exécutez docker compose up --build -d.

5. 5

   Supprimer la base de données mise de côté

   Cette base de données contient encore ce que les clients ont écrit après la sauvegarde. Lorsque l’ancienne version fonctionne, supprimez-la :

   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 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é. 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.

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 et dans Restaurer la sauvegarde sur 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. 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.

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.

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.

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 :

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 :

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.