Selbst gehostetes Claude Managed Agents aktualisieren

Diese Seite zeigt, wie du eine Bereitstellung auf Kubernetes oder Docker Compose aktualisierst und wie du ein Rollback durchführst. Auf Kubernetes hängt die Ausfallzeit davon ab, wie weit das Upgrade reicht:

Ein Docker-Compose-Stack ist bei jeder Art von Upgrade während des Neustarts nicht verfügbar.

Vor dem Upgrade

Lies den Abschnitt des neuen Releases in CHANGELOG.md, ganz oben im entpackten Archiv. Er beginnt mit den Upgrade-Schritten, die speziell für dieses Release gelten. Wenn du Releases überspringst, befolge jeden Abschnitt, der neuer als deine Version ist, beginnend mit dem ältesten.

Geh dann Zu prüfende Einstellungen und Pfade durch.

Ein Minor- oder Major-Upgrade beinhaltet ein Datenbank-Backup. Der Dump enthält jede Unterhaltung im Klartext, daher verschlüsseln die Befehle auf dieser Seite ihn mit dem age-Verschlüsselungstool. Erstelle einmalig ein Schlüsselpaar und bewahre den privaten Schlüssel, cma-backup.agekey, getrennt von den Backups auf:

age-keygen -o cma-backup.agekey
age-keygen -y cma-backup.agekey > cma-backup.agepub

Upgrade auf Kubernetes

Die kubectl-Befehle auf dieser Seite lesen den Namen des Deployments des Servers aus einer Shell-Variablen. Führe diese zwei Zeilen in jedem Terminal aus, in dem du die Befehle ausführst. Die erste Zeile ermittelt den Namen, und die zweite gibt ihn aus:

server=$(kubectl -n cma-server get deployment -l anthropic.com/role=server -o jsonpath='{.items[*].metadata.name}')
echo "$server"

Wenn die zweite Zeile cma-server ausgibt, fahre fort. Wenn ein anderer Name ausgegeben wird, lies vor dem Upgrade die Namen deiner Objekte. Wenn nichts ausgegeben wird, prüfe, ob kubectl auf den richtigen Cluster zeigt, und führe die zwei Zeilen erneut aus.

1. 1

   Die neuen Images bauen und pushen

   Entpacke das neue Archiv. Baue und pushe seine drei Images unter der neuen Version, wie in Die Images bauen und pushen beschrieben. Wenn du das Egress-Gateway betreibst, baue und pushe auch dessen Image.

   Wenn du ein eigenes Sandbox-Image baust, baue und pushe es ebenfalls neu, unter der neuen Version. Vergleiche sein Dockerfile mit kubernetes/sandbox/Dockerfile im neuen Archiv und lies nach, was ein eigenes Image braucht.

2. 2

   Die neue Version in deinen Values-Dateien setzen

   Wenn eine Values-Datei image.tag setzt, ändere den Wert auf die neue Version.

3. 3

   Alle Server stoppen, wenn das Upgrade es erfordert

   Führe diesen Schritt nur in diesen Fällen aus:

   • Ein Server, den du betreibst, liegt mehr als ein Minor-Release hinter dem neuen Release zurück.
   • Die erste Zahl, die Major-Version, steigt.
   • Ein Abschnitt in CHANGELOG.md, der neuer ist als das Release, das du betreibst, besagt, dass die Server gestoppt werden müssen.

   Von diesem Schritt an, bis die neuen Server bereit sind, können Clients die Bereitstellung nicht erreichen. Plane daher ein Wartungsfenster ein.

   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

   Die Datenbank sichern

   Tu dies vor einem Minor- oder Major-Upgrade oder wenn du die Server gestoppt hast. Wenn das alte Release nicht mit dem geänderten Schema laufen kann, ist dieses Backup der einzige Weg zurück.

   Verwende pg_dump aus derselben Hauptversion von PostgreSQL wie dein Datenbankserver. Verwende für <role> und <database> die Werte user und dbname aus database.url in cma-server-values.yaml. pg_dump fragt nach dem Passwort der Rolle.

   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

   

   Wenn einer der beiden Befehle einen Fehler ausgibt, ist die zurückgelassene Datei kein Backup. Behebe die Ursache und führe den Befehl erneut aus, bevor du fortfährst.

   Wenn die Server laufen, enthält das Backup nur, was Clients vor Beginn des Dumps geschrieben haben.

5. 5

   Erst den Server, dann die Sandboxes aktualisieren

   Führe diese Befehle im obersten Verzeichnis des neuen Archivs aus und verwende dabei die Values-Dateien deiner 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

   

   Wenn du mehr als eine Umgebung betreibst, führe den zweiten Befehl für jedes Sandbox-Release aus, mit dem Namen, dem Namespace und der Values-Datei des jeweiligen Releases.

   Wenn du die Server gestoppt hast, migriert der erste Befehl das Schema, stellt die Serveranzahl wieder her und kehrt zurück, sobald die neuen Server bereit sind.

Bei laufenden Servern startet Helm jeden neuen Server, bevor es einen alten stoppt, sodass die Anzahl der bereiten Server nie sinkt. Bei einem Minor-Upgrade ändert der erste Befehl das Schema, während die alten Server weiterhin Anfragen bedienen, und ersetzt sie danach. Ein offener Event-Stream auf einem Server, der ersetzt wird, endet sauber, sodass ein Client, der einem Stream folgt, sich neu verbinden muss.

Wenn ein Befehl fehlschlägt, lies Wenn das Upgrade fehlschlägt.

Upgrade auf Docker Compose

Die Schritte sind für jede Art von Upgrade gleich. Führe jeden docker compose-Befehl im Compose-Verzeichnis eines Release aus, also in dem Verzeichnis, das docker-compose.yml enthält. Im entpackten Archiv ist das das Verzeichnis compose. Verwende ein Terminal, in dem ANTHROPIC_BASE_URL, ANTHROPIC_API_KEY und ANTHROPIC_AUTH_TOKEN nicht gesetzt sind, denn Compose übergibt die Werte dieser Variablen aus der Shell an den Server.

1. 1

   Die Datenbank sichern

   Tu dies vor einem Minor- oder Major-Upgrade im Compose-Verzeichnis des alten Release:

   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

   

   Lass $POSTGRES_USER und $POSTGRES_DB im Befehl unverändert. Der Text in einfachen Anführungszeichen läuft im Container postgres, der die Namen seiner Rolle und seiner Datenbank in diesen Variablen hält.

   Der Stack bedient während des Backups weiterhin Anfragen, daher fehlt im Dump, was Clients nach Beginn des Dumps schreiben. Wenn einer der beiden Befehle einen Fehler ausgibt, ist die zurückgelassene Datei kein Backup. Behebe die Ursache und führe den Befehl erneut aus, bevor du fortfährst.

2. 2

   Das neue Archiv entpacken

   Lege das neue Archiv in ein Verzeichnis, in dem das neue Release bleiben kann, etwa das übergeordnete Verzeichnis des alten Release. Die Befehle entpacken das Archiv dort, und der neue Stack läuft aus den entpackten Dateien.

   Wenn deine umask strenger als 022 ist, führe zuerst umask 022 aus. Führe dann Folgendes im Compose-Verzeichnis des alten Release aus. Schreibe anstelle von <directory> den vollständigen Pfad des Verzeichnisses, das das neue Archiv enthält. Schreibe anstelle von <archive> den Namen des Archivs ohne .tar.gz.

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

   

   Die zweite Zeile kopiert außerdem deine .env und compose.config.yaml in das entpackte Verzeichnis compose. Der alte Stack läuft während beider Zeilen weiter. Wenn eine Zeile einen Fehler ausgibt, behebe die Ursache und führe beide Zeilen erneut aus.

3. 3

   Deine anderen Änderungen wiederholen

   Nur .env und compose.config.yaml werden übernommen. Nimm deine anderen Änderungen im Compose-Verzeichnis des neuen Release erneut vor:

   • Eine Datei, die du hinzugefügt hast: Kopiere sie.
   • Eine mitgelieferte Datei, die du bearbeitet hast: Nimm dieselbe Bearbeitung in der Kopie des neuen Release vor. Kopiere die alte Datei nicht darüber, denn damit machst du die Änderungen des Release an der Datei rückgängig.
   • Agent-Identität: Kopiere das Verzeichnis agent-identity mit cp -a, mit sudo, wenn es root gehört, und bearbeite den Block volumes: von docker-compose.yml erneut.
   • Eine eigene Compose-Datei: Kopiere sie und prüfe ihre relativen Pfade.

   Nimm dann die Docker-Compose-Änderungen unter Zu prüfende Einstellungen und Pfade vor.

4. 4

   Den alten Stack stoppen und den neuen starten

   Führe diese Zeilen in dem Terminal aus, in dem du das Archiv entpackt hast, denn sie verwenden dessen Variable $releases. Bleib im Compose-Verzeichnis des alten Release und schreibe denselben Namen anstelle von <archive>. Wenn du COMPOSE_FILE für den alten Stack exportiert hast, exportiere zuerst denselben Wert.

   ls "$releases/<archive>/compose/.env" && docker compose down
   cd "$releases/<archive>/compose" && docker compose up --build -d

   

   Die erste Zeile stoppt den alten Stack nur, wenn die .env des neuen Release vorhanden ist. docker compose down behält die Datenbank bei. Füge kein -v hinzu, denn das löscht sie. Der neue Stack übernimmt die Datenbank, und sein migrate-Container aktualisiert das Schema, bevor der Server startet.

Wenn ein Befehl fehlschlägt, lies Wenn das Upgrade fehlschlägt.

Wenn das Upgrade fehlschlägt

Finde vor einem Rollback die Ursache im Log:

• Kubernetes: Wenn der Migrations-Job fehlschlägt, wartet helm upgrade einige Minuten, während der Job es erneut versucht, und schlägt dann fehl. Führe während dieser Wartezeit in einem zweiten Terminal kubectl -n cma-server logs job/$server-migrate aus, mit $server gesetzt wie unter Upgrade auf Kubernetes. Kubernetes löscht das Log, wenn der Job keine weiteren Versuche mehr unternimmt. Wenn du es verpasst hast, führe helm upgrade erneut aus, wodurch der Job erneut startet.
• Docker Compose: Die Ausgabe von docker compose up --build -d zeigt möglicherweise nicht den Grund. Führe docker compose logs aus, um ihn zu finden.

Die Migration kann erfolgreich sein, während die neuen Server nicht bereit werden. Um die Ursache zu finden, lies das Log der Server:

• Kubernetes: kubectl -n cma-server logs -l anthropic.com/role=server --prefix --tail=20
• Docker Compose: docker compose logs cma-server

Auf Kubernetes nennt zum Beispiel eine Zeile, die has invalid keys enthält, eine Einstellung unter server.config, die das neue Release nicht akzeptiert. Behebe die Ursache und führe den Upgrade-Befehl erneut aus, bevor du eine Wiederherstellung in Betracht ziehst, denn bei einer Wiederherstellung gehen Daten verloren. Sobald sich auf Kubernetes das Schema geändert hat, bedient ein laufender Server des alten Releases weiterhin Anfragen, startet aber möglicherweise nicht erneut, wenn er stoppt.

Rollback

Die kubectl-Befehle in diesem Abschnitt verwenden die Variable $server aus Upgrade auf Kubernetes. Prüfe vor einem Rollback Wenn das Upgrade fehlschlägt. Führe das Rollback dann je nach Art des Upgrades durch:

• Nach einem Patch-Upgrade: Das alte Release erneut bereitstellen. Beide Releases verwenden dasselbe Schema.
• Nach einem Minor- oder Major-Upgrade: Öffne CHANGELOG.md im neuen Archiv. Lies den Abschnitt jedes Release, das nach dem Release erschienen ist, zu dem du zurückkehrst.
  • Wenn ein Abschnitt besagt, dass das alte Release nicht mit der migrierten Datenbank starten kann, stelle das Backup wieder her.
  • Andernfalls stelle das alte Release erneut bereit. Wenn das mit cannot downgrade fehlschlägt, stelle das Backup wieder her.

Das alte Release erneut bereitstellen

• Kubernetes: Wechsle in das oberste Verzeichnis des alten Archivs. Führe die zwei helm upgrade-Befehle aus Upgrade auf Kubernetes aus, mit den Values-Dateien, wie sie für dieses Release waren. Wenn du zum Beispiel für das Upgrade earlierNames hinzugefügt hast, entferne es wieder. Führe den zweiten Befehl erst aus, wenn der erste erfolgreich ist.
• Docker Compose: Führe docker compose down im Compose-Verzeichnis des neuen Release aus und dann docker compose up --build -d im Compose-Verzeichnis des alten.

Wenn das alte Release nicht mit dem geänderten Schema laufen kann, zeigt das Log cannot downgrade:

• Kubernetes: Der Migrations-Job schlägt fehl, und die Server bleiben unverändert. Wenn das Upgrade fehlschlägt beschreibt, wie du das Log des Jobs liest.
• Docker Compose: Der Server startet nicht. Lies das Log mit docker compose logs migrate.

Auf Docker Compose zeigt die Ausgabe von docker compose logs stattdessen möglicherweise stored value is encrypted but no encryption key is configured. In diesem Fall hat die .env des alten Release keine Zeile CMA_STORE__CREDENTIALS_ENCRYPTION_KEY. Kopiere diese Zeile aus der .env des neuen Release und führe docker compose up --build -d erneut aus.

Das Backup auf Kubernetes wiederherstellen

Dein Datenbankserver braucht Platz für eine zweite Kopie der Datenbank. Verwende für <role> und <database> die Werte user und dbname aus database.url in cma-server-values.yaml.

1. 1

   Das Backup in eine neue Datenbank wiederherstellen

   Verbinde dich als Administrator mit der Datenbank postgres auf deinem Datenbankserver und führe Folgendes aus:

   CREATE DATABASE <database>_restored OWNER <role>;

   

   Führe dann auf dem Rechner, auf dem das Backup liegt, diesen Befehl mit den Pfaden zu deinem Schlüssel und deiner Backup-Datei aus. Verwende ein pg_restore derselben Hauptversion wie dein Datenbankserver. Es fragt nach dem Passwort der Rolle und gibt nichts aus, wenn es funktioniert.

   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

   

   Wenn dabei ein Fehler ausgegeben wird, brich ab. Deine Datenbank ist unverändert. Führe DROP DATABASE <database>_restored; als Administrator aus und beginne diesen Schritt von vorn.

2. 2

   Alle Server stoppen

   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

   Zur wiederhergestellten Datenbank wechseln

   Verbinde dich als Administrator mit der Datenbank postgres und führe Folgendes aus:

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

   

   Wenn die erste Anweisung meldet, dass andere Sitzungen die Datenbank verwenden, schließe diese Sitzungen und führe beide Anweisungen erneut aus. Ein Connection-Pooler kann solche Sitzungen offen halten.

4. 4

   Das alte Release bereitstellen

   Befolge den Kubernetes-Punkt aus Das alte Release erneut bereitstellen. Der erste Befehl stellt außerdem die Anzahl der Server wieder her. Wenn er fehlschlägt, kubectl -n cma-server get pods aber zeigt, dass die alten Server bereit sind, lies Wenn die Schlüsselprüfung fehlschlägt.

5. 5

   Die beiseitegelegte Datenbank löschen

   Diese Datenbank enthält noch, was Clients nach dem Backup geschrieben haben. Wenn das alte Release funktioniert, lösche sie mit DROP DATABASE <database>_upgraded;.

Wenn die Schlüsselprüfung fehlschlägt

Im Schritt „Das alte Release bereitstellen“ wartet der erste helm upgrade-Befehl, bis die alten Server bereit sind. Dann prüft er den Schlüssel, mit dem sich die Sandboxes verbinden. Wenn der Befehl fehlschlägt, kubectl -n cma-server get pods aber zeigt, dass die alten Server bereit sind, ist diese Prüfung fehlgeschlagen.

Deine Daten sind wiederhergestellt und die Server funktionieren, aber die Sandboxes können sich noch nicht mit ihnen verbinden. Die Sandboxes verbinden sich mit einem Schlüssel aus dem Secret cma-environment in ihrem eigenen Namespace, cma. Dieser Schlüssel ist neuer als dein Backup, daher erkennt die wiederhergestellte Datenbank ihn nicht.

Um die Ursache zu bestätigen, führe den ersten Befehl erneut aus. Öffne, während er wartet, ein zweites Terminal und setze dort ebenfalls $server. Führe dann kubectl -n cma-server logs job/$server-environment-default aus und setze dabei den Namen deiner Umgebung anstelle von default ein. Suche nach einer Zeile, die Secret cma/cma-environment records key enthält. Wenn das Log einen anderen Fehler zeigt, behebe, was er nennt.

Wenn das Log diese Zeile zeigt, lösche das Secret mit kubectl -n cma delete secret cma-environment und führe den ersten Befehl erneut aus. Er erstellt das Secret erneut, mit einem neuen Schlüssel. Führe dann den zweiten Befehl aus.

Das Backup auf Docker Compose wiederherstellen

1. 1

   Nur die Datenbank starten

   Führe docker compose down im Compose-Verzeichnis des neuen Release aus. Führe dann docker compose up -d --wait postgres im Compose-Verzeichnis des alten Release aus. Bleib für die nächsten Schritte in diesem Verzeichnis.

2. 2

   Das Backup in eine neue Datenbank wiederherstellen

   Führe im Compose-Verzeichnis des alten Release Folgendes mit den Pfaden deines Schlüssels und deiner Backup-Datei aus:

   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'

   

   Sie hat funktioniert, wenn DROP DATABASE und CREATE DATABASE ausgegeben werden und kein Fehler.

   Lass $POSTGRES_USER und $POSTGRES_DB hier und in den nächsten Schritten unverändert. Der Text in einfachen Anführungszeichen läuft im Container postgres, der die Namen seiner Rolle und seiner Datenbank in diesen Variablen hält.

   Wenn ein Fehler ausgegeben wird, ist deine Datenbank unverändert, sodass du den gesamten Befehl erneut ausführen kannst. Wenn das Backup nicht wiederhergestellt werden kann, führe docker compose up --build -d im Compose-Verzeichnis des neuen Release aus, um dieses Release wieder zu starten.

3. 3

   Zur wiederhergestellten Datenbank wechseln

   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

   Das alte Release starten

   Führe docker compose up --build -d aus.

5. 5

   Die beiseitegelegte Datenbank löschen

   Diese Datenbank enthält noch, was Clients nach dem Backup geschrieben haben. Wenn das alte Release funktioniert, lösche sie:

   docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres -c "DROP DATABASE ${POSTGRES_DB}_upgraded"'

   

Nach einer Wiederherstellung

Eine Wiederherstellung setzt Umgebungsschlüssel auf den Zeitpunkt des Backups zurück:

• Ein Schlüssel, den du nach dem Backup widerrufen hast: Er funktioniert wieder. Widerrufe ihn erneut.
• Ein Schlüssel, den du nach dem Backup erstellt hast: Er ist weg. Erstelle einen neuen Schlüssel für die Worker, die ihn verwendet haben.

Einen Umgebungsschlüssel für deine eigenen Worker ersetzen enthält die Befehle, die auch auf Docker Compose funktionieren. Die Sandboxes, die der Docker-Compose-Stack startet, erfordern keine Aktion, denn der Stack ersetzt ihren Schlüssel, wenn er startet.

Um die Schlüssel einer Umgebung aufzulisten, einschließlich widerrufener, führe list-keys wie folgt aus:

• Verwende das Terminal, das du in Die API auf einem selbst gehosteten Server aufrufen eingerichtet hast. Verwende nicht das Terminal, in dem docker compose läuft.
• Führe auf Kubernetes zuerst kubectl -n cma-server port-forward svc/$server 8400:8400 in einem anderen Terminal aus, in dem $server ebenfalls gesetzt ist.
• Führe den Befehl im obersten Verzeichnis des Archivs aus, einmal für jede Umgebung, mit der ID der jeweiligen Umgebung.

echo "$ANTHROPIC_API_KEY" | ./cma-server-admin list-keys \
  -base-url http://127.0.0.1:8400 -env env_01595EKxaaTTGwwY3kyXdtbs \
  -key-file - -all

Ein Backup testen

Um zu beweisen, dass sich ein Dump wiederherstellen lässt, führe nur den Schritt „Das Backup in eine neue Datenbank wiederherstellen“ aus. Er steht unter Das Backup auf Kubernetes wiederherstellen und unter Das Backup auf Docker Compose wiederherstellen. Dieser Schritt ändert die verwendete Datenbank nicht. Lösche danach die neue Datenbank. Auf Docker Compose ist ihr Name der Name deiner Datenbank mit _restored am Ende.

Zu prüfende Einstellungen und Pfade

Lies diesen Abschnitt, bevor du einen Upgrade-Befehl ausführst.

Prüfe den Abschnitt web_tools deiner Einstellungsdatei. Wenn die Datei keinen solchen Abschnitt hat oder der Abschnitt keine Schlüssel setzt, sind die Tools web_search und web_fetch nach dem Upgrade ausgeschaltet. Ein Agent, der das Standard-Toolset verwendet, läuft dann ohne sie und ohne Fehler. Ein Agent, dessen Toolset eines der beiden Tools einschaltet, kann keine Sitzung starten. Wie du die Tools behältst, erfährst du unter Web-Tools brauchen eine Server-Einstellung.

Prüfe auf Kubernetes, ob jede Sandbox-Values-Datei, etwa cma-values.yaml, egress.mode setzt. Damit deine Sandboxes ihren Zugriff auf das öffentliche Internet behalten, füge mode: publicInternet unter egress hinzu. Wenn eine Datei keinen Modus setzt, wendet das Chart seinen Standardmodus closed an. Der helm upgrade-Befehl des Sandbox-Charts bricht dann mit einem Fehler wie egress.mode is closed and egress.closed.hosts is empty ab und ändert nichts.

Prüfe sandbox.idleTimeout in denselben Dateien. Wenn eine Datei den Wert nicht setzt, verschwindet der Pod einer Sitzung etwa 5 Minuten nach dem Ende des Agent-Turns. Die Prozesse, die der Agent laufen gelassen hat, stoppen mit dem Pod. Standardmäßig bleiben die Dateien in /workspace erhalten. Um den Pod 30 Minuten lang zu behalten, füge idleTimeout: 30m unter sandbox hinzu.

Prüfe die Einstellungsdatei auf inference.attribution und die Umgebung des Servers auf CMA_INFERENCE__ATTRIBUTION. Lösche die Zeile, wenn du eine findest. Das Release, auf das du aktualisierst, hat diese Einstellung nicht, und sein Server startet nicht, wenn eines der beiden gesetzt ist.

Wenn die Claude API dein Inferenzanbieter ist, trägt nach dem Upgrade jeder Modellaufruf die IDs seiner Sitzung sowie des Agents und der Umgebung dieser Sitzung. Siehe Was der Server an seinen Inferenzanbieter sendet.

Kubernetes: die Namen deiner Objekte

cma-server-values.yaml muss in seiner Einstellung earlierNames angeben, welche Namen deine Installation hat. Um den Namen des Deployments des Servers zu finden, führe kubectl -n cma-server get deployment -l anthropic.com/role=server aus.

Wenn die Datei diese Zeile nicht hat, füge sie vor dem Upgrade hinzu und behalte sie für jedes spätere Upgrade bei. Ohne sie bricht der helm upgrade-Befehl des Server-Charts mit einem Fehler ab, der earlierNames nennt, und ändert nichts.

Mit earlierNames: true behalten die Objekte des Charts ihre cma-onprem-Namen, und die Server finden weiterhin die Secrets, die du unter diesen Namen erstellt hast. Diese Seiten verwenden die Namen in der mittleren Spalte. Verwende mit earlierNames: true stattdessen die Namen in der letzten Spalte:

Unabhängig davon, was earlierNames angibt, heißt der Namespace cma-server und das Image des Servers cma-server-image.

Jede Sandbox-Values-Datei, die egress.mode: gateway setzt, muss unter egress.gateway die zwei Services des Servers nennen. Wenn eine Datei das nicht tut, füge beide Zeilen hinzu. Dieses Beispiel enthält die Namen für eine Installation mit earlierNames: true:

egress:
  gateway:
    serverService: cma-onprem
    serverEgressService: cma-onprem-egress

Docker Compose: das Layout und die Pfade des Archivs

Wenn das Release, von dem aus du aktualisierst, kein Verzeichnis compose hat, liegt seine docker-compose.yml ganz oben im Archiv, neben bin. Im neuen Archiv liegt diese Datei eine Ebene tiefer, in compose.

Nimm im Schritt „Deine anderen Änderungen wiederholen“ auch diese Änderungen vor:

• Eine eigene Compose-Datei: Wenn das alte Archiv kein Verzeichnis compose hatte, wandert auch deine Datei eine Ebene tiefer. Ein Pfad wie ./bin darin wird zu ../bin. Wenn die Datei den Dienst cma-onprem nennt, ändere diesen Namen in cma-server.
• Pfade unter /etc/cma-onprem/ oder /run/cma-onprem/: Ändere jeden so, dass er mit /etc/cma-server/ oder /run/cma-server/ beginnt. Sieh in der .env und compose.config.yaml des neuen Release nach, in einer eigenen Compose-Datei und in jeder volumes:-Zeile, die du hinzugefügt hast. Ändere in einer volumes:-Zeile nur den Teil nach dem ersten Doppelpunkt, also den Pfad innerhalb des Containers.