From 209546150ef0c77cf0975b95609a72a793046181 Mon Sep 17 00:00:00 2001 From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com> Date: Mon, 9 Nov 2026 15:46:31 +0000 Subject: [PATCH] Select the native tuple Server 3.3.2 and chart 1.1.0 Pin Server 3.3.2 (Git tag 3.3.2 -> 660217dd, index sha256:4aeceb42...) and Helm chart 1.1.0 with appVersion 3.3.2, built from chart source 0eea994a (server#1117, merged as f3408663) and published by Helm Chart Release run 42644498343. An anonymous GHCR read returns OCI manifest sha256:fd670cad... with a single chart layer sha256:a72dc4fd...; the downloaded layer hashes identically and matches the run's helm-release-evidence.json package_digest. qualification_url cites the readback on server#1117. Document the 3.0.x -> 3.3.2 upgrade: native schema 8 -> 11 on MySQL, MariaDB and PostgreSQL (8 -> 10 on SQLite) needs a backup and an explicit schema-upgrade (Compose: run --rm --no-deps server schema-upgrade; Helm: native.schemaUpgrade.enabled), and rollback means restoring the backup. Link the chart's Chart 1.1.0 / Server 3.3.2 UPGRADING section and the 3.3.0 upgrade notes. Update the Server guide's cluster-info example and protocol note to the 3.3.2 image, which now serves supported_sdk_versions and client_compatibility. Bind the database page to the 3.3.2 release smoke and exact-index Compose smoke without claiming more than they cover. Move the Kubernetes worker-guide fixture to the 3.3.2 index. All seven translations and their source hashes are updated. Co-Authored-By: Claude Opus 5.5 --- docs/deployment.md | 69 +++++++++++++++++++ docs/polyglot/database-support.md | 28 +++++--- docs/polyglot/server.md | 28 ++++++-- .../current/deployment.md | 33 +++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 28 ++++++-- i18n/de/source-hashes.json | 6 +- .../current/deployment.md | 64 +++++++++++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 24 +++++-- i18n/es/source-hashes.json | 6 +- .../current/deployment.md | 63 +++++++++++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 24 +++++-- i18n/fr/source-hashes.json | 6 +- .../current/deployment.md | 33 +++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 24 +++++-- i18n/ja/source-hashes.json | 6 +- .../current/deployment.md | 64 +++++++++++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 24 +++++-- i18n/pt-BR/source-hashes.json | 6 +- .../current/deployment.md | 58 ++++++++++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 28 ++++++-- i18n/uk/source-hashes.json | 6 +- .../current/deployment.md | 33 +++++++++ .../current/polyglot/database-support.md | 12 ++-- .../current/polyglot/server.md | 24 +++++-- i18n/zh-Hans/source-hashes.json | 6 +- static/stable-releases.json | 14 ++-- tests/kubernetes-workers/artifacts.json | 4 +- 33 files changed, 676 insertions(+), 117 deletions(-) diff --git a/docs/deployment.md b/docs/deployment.md index 485d4c32b65..c7a0d0aeac0 100644 --- a/docs/deployment.md +++ b/docs/deployment.md @@ -268,6 +268,62 @@ command-level Compose examples in the [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose) section. +### Upgrading from Server 3.0.x to 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +Server 3.3.2 crosses three minor releases from 3.0.x and changes the native +schema. On MySQL, MariaDB and PostgreSQL it moves from version 8 (3.0.x and +3.1.0) through 10 (3.2.0) to 11 (3.3.0 to 3.3.2). On SQLite it moves from 8 +to 10. A Server never upgrades its schema at startup: 3.3.2 started on a +version 8 database refuses with `native_schema_upgrade_required`, so changing +`DW_SERVER_IMAGE` alone leaves the new Server unable to start. The 3.3.2 +image's `schema-upgrade` command upgrades a version 8 database directly. The +[3.3.0 upgrade notes](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) +describe the step, and the Helm chart's +[Chart 1.1.0 / Server 3.3.2 notes](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) +list the schema steps and the runtime changes from 3.0.5 to 3.3.2. + +For the single-node Compose deployment: + +1. Stop the Server and leave MySQL running: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. Back up MySQL and `server_storage`, and record the current image + reference. This backup is the only way back to 3.0.x. +3. Change `DW_SERVER_IMAGE` to the 3.3.2 image, pull it and run + `schema-upgrade` once: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + It prints the backend and the schema versions before and after, for + example `"from_schema_version":8,"schema_version":11,"status":"upgraded"`. + On a database that is already current it only verifies the schema. +4. Start the Server with + `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`, + then confirm `/api/ready`, `/api/cluster/info` (`version` is `3.3.2`) and + worker registration. + +- **PostgreSQL:** the version 10 and 11 steps build their indexes with a plain + `CREATE INDEX`, which blocks writes to `workflow_tasks` until the build + finishes. On a large `workflow_tasks` table, plan the downtime for it. +- **MySQL and MariaDB:** DDL commits on its own there, so the upgrade marks the + database as upgrading until it finishes, and every Server refuses it + meanwhile with `native_schema_upgrade_incomplete`. If an upgrade is + interrupted, run `schema-upgrade` again to resume it. +- **Rollback needs the backup.** There is no schema downgrade. A 3.0.x Server + refuses an upgraded database with `native_schema_newer_than_binary`. To go + back, restore the backup taken in step 2, which discards everything written + after it, and then start the 3.0.x image. + +The worker protocol stays at `1.20` and the control plane at version `2`. + ## Small clustered deployments :::note PHP Server 2.x contract @@ -540,6 +596,19 @@ the PHP 2.x worker, scheduler, bootstrap job and Redis. To move to and keep `runtime: php` until the takeover is done. See the chart's [UPGRADING notes](%%artifact.helmChartUpgradeUrl%%). +Chart 1.1.0 changes the default image from Server 3.0.5 to 3.3.2, which needs +the [native schema upgrade](#native-schema-upgrade-3-0-to-3-3) from 8 to 11. +An ordinary `helm upgrade` from chart 1.0.x changes only the image, and the new +pods refuse to start with `native_schema_upgrade_required`. Follow the chart's +[Chart 1.1.0 / Server 3.3.2 steps](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native): +scale the Server to zero with autoscaling off, back up the database, then +upgrade to chart 1.1.0 with `native.schemaUpgrade.enabled=true`. Its +`pre-upgrade` hook runs `schema-upgrade` once before the new pods start, and +only when Helm's `lookup` shows every Server stopped. Argo CD, Flux and +`helm template` renders refuse the hook; use the chart README's manual Job +instead. A `helm rollback` to a chart 1.0.x revision does not bring the Server +back, because 3.0.x refuses the upgraded database: restore the backup instead. + ### Choosing a chart release {#helm-chart-selection} One chart release records the Server image it was tested against in `Chart.yaml`'s `appVersion`; the chart and Server have independent version numbers. The selected [compatibility tuple](./compatibility.md#last-qualified-reproducible-tuple) pairs chart **%%artifact.helmChartVersion%%** with Server **%%artifact.helmChartAppVersion%%**, from the same release metadata as the table and install command. Its [published OCI/package receipt](%%artifact.helmChartQualificationUrl%%) verifies that pairing, not a fresh Kubernetes installation. diff --git a/docs/polyglot/database-support.md b/docs/polyglot/database-support.md index 27152c9d189..79b3f910816 100644 --- a/docs/polyglot/database-support.md +++ b/docs/polyglot/database-support.md @@ -10,16 +10,16 @@ workers rather than a runtime database. A declared compatibility baseline is not proof that every later version is qualified. Source tests and installed, published artifacts are different -evidence. This snapshot binds Workflow 2.20.3 source and Server 3.0.5 release +evidence. This snapshot binds Workflow 2.20.3 source and Server 3.3.2 release receipts. It does not change runtime compatibility or establish a lowest/newest tested range. | Engine | Declared compatibility | Observed source qualification | Published-artifact qualification | | --- | --- | --- | --- | -| MySQL | Embedded: 8.0 baseline. Server: 8.0 baseline. | Core: 26.10.0 in the original floating-image feature jobs. Server profiles: 8.0.46 and 8.4.5. | Core observation is release-source-bound. Server 3.0.5 Compose uses floating `mysql:8.0` for schema/health smoke, not a full execution/capacity/TLS qualification. | -| PostgreSQL | Embedded: 13 baseline. Server: 13 baseline. | Core: 18.6. Server profiles: 16.15 and 17.11. | Core observation is release-source-bound. No Server 3.0.5-index-bound PostgreSQL endpoint receipt was found in the inspected release inventory. | -| MariaDB | Embedded: 10.5 baseline. Server accepts `mariadb`; no version baseline is established here. | Core: 10.5.29. Server profile: 10.11.19. | Core observation is release-source-bound. No Server 3.0.5-index-bound MariaDB endpoint receipt was found in the inspected release inventory. | -| SQLite | Embedded capability/tests include SQLite. Server declares a 3.35 baseline. | The original Core source jobs did not emit the SQLite library version. | Installed Core 2.20.3 acceptance exercised SQLite, without establishing a library-version range. Server's frozen 3.1.0 candidate corpus is separate from stable 3.0.5. | +| MySQL | Embedded: 8.0 baseline. Server: 8.0 baseline. | Core: 26.10.0 in the original floating-image feature jobs. Server profiles: 8.0.46 and 8.4.5. | Core observation is release-source-bound. Server 3.3.2's release smoke and exact-index Compose smoke use digest-pinned MySQL 8.0 for start/health checks, not a full execution/capacity/TLS qualification. | +| PostgreSQL | Embedded: 13 baseline. Server: 13 baseline. | Core: 18.6. Server profiles: 16.15 and 17.11. | Core observation is release-source-bound. Server 3.3.2's release smoke cold-starts each architecture's image on digest-pinned PostgreSQL 17 for readiness and cluster info only, not a full execution/capacity/TLS qualification. | +| MariaDB | Embedded: 10.5 baseline. Server accepts `mariadb`; no version baseline is established here. | Core: 10.5.29. Server profile: 10.11.19. | Core observation is release-source-bound. No Server 3.3.2-index-bound MariaDB endpoint receipt was found in the inspected release evidence. | +| SQLite | Embedded capability/tests include SQLite. Server declares a 3.35 baseline. | The original Core source jobs did not emit the SQLite library version. | Installed Core 2.20.3 acceptance exercised SQLite, without establishing a library-version range. Server 3.3.2's release smoke cold-starts on SQLite, also without a library-version range. | | SQL Server | Published embedded Core advertises `sqlsrv`, but it remains unqualified. Server qualification is not established here. | No SQL Server job was recovered from the published Core matrix. The proposed backend guard is separate source work. | No corresponding release qualification was recovered. Do not infer support from the embedded capability advertisement. | ## Reading the evidence {#reading-the-evidence} @@ -33,12 +33,20 @@ covers 67 SQLite-backed stream/replay/fake cases. Neither a PHP version nor a floating image selector supplies an unreported database version. The [Server inventory](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) -separates native and legacy PHP source-job scopes. The +separates native and legacy PHP source-job scopes. For Server 3.3.2, the +[release run](https://github.com/durable-workflow/server/actions/runs/42591612884) +cold-starts the amd64 and arm64 images on SQLite, PostgreSQL 17 and MySQL 8.0, +checks `/api/ready` and authenticated cluster info, and stops each with SIGTERM. +The [exact-index Compose smoke](https://github.com/durable-workflow/server/actions/runs/42602031026) +has four architecture/profile cells against index `sha256:4aeceb42…`. Both +`local` and `production` use MySQL, with `mysql:8.0` pinned by digest. The +[3.3.2 delivery record](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227) +accepts both. These runs start empty databases. They do not upgrade +an existing one, qualify write capacity or verify TLS, and their logs do not +report an exact engine patch version. The earlier [stable 3.0.5 receipt](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) -has four architecture/profile Compose smoke cells. Both `local` and `production` -use MySQL. The inspected logs do not recover an exact companion version/digest, -write-capacity qualification or verified TLS. Source profiles and a frozen -candidate do not qualify a different published image. +had the same Compose shape with a floating `mysql:8.0`. Source profiles do not +qualify a different published image. ## Vendor lifecycle and distributed engines {#vendor-lifecycle-and-distributed-engines} diff --git a/docs/polyglot/server.md b/docs/polyglot/server.md index cc96878003f..cbe73f6e346 100644 --- a/docs/polyglot/server.md +++ b/docs/polyglot/server.md @@ -516,15 +516,28 @@ curl http://localhost:8080/api/cluster/info \ Returns the build identity, capability flags, protocol manifests, limits and discovery for the namespace named by `X-Namespace` (or the `namespace` query -parameter, else `default`). Abridged output from the 3.0.5 image: +parameter, else `default`). Abridged output from the 3.3.2 image: ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -532,6 +545,8 @@ parameter, else `default`). Abridged output from the 3.0.5 image: "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -571,7 +586,7 @@ Key field notes for client code: - The build version is `version`, not `server_version`. `implementation` is `"rust"` on the native Server. - Check `control_plane.version` and `worker_protocol.version` before calling - the API. Native 3.0.5 serves control plane `2` and worker protocol `1.20`, + the API. Native 3.3.2 serves control plane `2` and worker protocol `1.20`, and accepts worker requests that send any protocol version from `1.0` to `1.20`. - Workflow-task commands live under @@ -580,8 +595,11 @@ Key field notes for client code: native does not serve. `response_compression` is empty because native sends uncompressed responses. - `native_unqualified` lists each member of the PHP 2.x response that native - leaves out, with the reason. It includes `topology`, - `supported_sdk_versions` and `client_compatibility`. + leaves out, with the reason. It includes `topology`. +- Since 3.1.0, native also serves `supported_sdk_versions` and + `client_compatibility`, which the CLI's `server:info` and `doctor` read. + `client_compatibility.authority` is `"protocol_manifests"`: check the + protocol manifests, not the SDK ranges, before calling the API. - The sole payload codec is Avro: `capabilities.payload_codecs` is exactly `["avro"]`. - `qualified_for_php_takeover` is always `false`. It describes the running diff --git a/i18n/de/docusaurus-plugin-content-docs/current/deployment.md b/i18n/de/docusaurus-plugin-content-docs/current/deployment.md index 8176737ad78..925079282a0 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/deployment.md @@ -195,6 +195,37 @@ Upgrade-Reihenfolge: Der native Server prüft sein Schema beim Start. Patch-Veröffentlichungen innerhalb einer nativen Minor-Linie behalten das Schema bei, daher genügt ein Image-Wechsel. Eine Veröffentlichung, deren Hinweise eine Schemaänderung ankündigen, benötigt zusätzlich den Befehl `schema-upgrade` des Images, ausgeführt nach einer Datenbanksicherung, während alle Server gestoppt sind. Die Server-Referenz enthält aktuelle Compose-Befehlsbeispiele unter [Offizielles Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose). +### Upgrade von Server 3.0.x auf 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +Server 3.3.2 liegt drei Minor-Veröffentlichungen nach 3.0.x und ändert das native Schema. Auf MySQL, MariaDB und PostgreSQL wechselt es von Version 8 (3.0.x und 3.1.0) über 10 (3.2.0) auf 11 (3.3.0 bis 3.3.2). Auf SQLite wechselt es von 8 auf 10. Ein Server aktualisiert sein Schema nie beim Start: 3.3.2 verweigert auf einer Datenbank mit Version 8 den Start mit `native_schema_upgrade_required`, daher kann der neue Server nicht starten, wenn nur `DW_SERVER_IMAGE` geändert wird. Der Befehl `schema-upgrade` des 3.3.2-Images aktualisiert eine Datenbank mit Version 8 direkt. Die [Upgrade-Hinweise zu 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) beschreiben den Schritt, und die [Hinweise zu Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) des Helm-Charts führen die Schemaschritte und die Laufzeitänderungen von 3.0.5 auf 3.3.2 auf. + +Für die Compose-Bereitstellung auf einem einzelnen Knoten: + +1. Stoppen Sie den Server und lassen Sie MySQL weiterlaufen: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. Sichern Sie MySQL und `server_storage` und halten Sie die aktuelle Image-Referenz fest. Diese Sicherung ist der einzige Weg zurück zu 3.0.x. +3. Ändern Sie `DW_SERVER_IMAGE` auf das 3.3.2-Image, rufen Sie es ab und führen Sie `schema-upgrade` einmal aus: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + Der Befehl gibt das Backend und die Schemaversionen vorher und nachher aus, zum Beispiel `"from_schema_version":8,"schema_version":11,"status":"upgraded"`. Auf einer bereits aktuellen Datenbank prüft er nur das Schema. +4. Starten Sie den Server mit `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` und bestätigen Sie dann `/api/ready`, `/api/cluster/info` (`version` ist `3.3.2`) und die Worker-Registrierung. + +- **PostgreSQL:** Die Schritte zu Version 10 und 11 erstellen ihre Indizes mit einem einfachen `CREATE INDEX`, das Schreibzugriffe auf `workflow_tasks` blockiert, bis der Aufbau abgeschlossen ist. Planen Sie bei einer großen Tabelle `workflow_tasks` die Ausfallzeit dafür ein. +- **MySQL und MariaDB:** DDL wird dort eigenständig committet, daher markiert das Upgrade die Datenbank bis zu seinem Abschluss als im Upgrade befindlich, und jeder Server verweigert sie währenddessen mit `native_schema_upgrade_incomplete`. Wird ein Upgrade unterbrochen, führen Sie `schema-upgrade` erneut aus, um es fortzusetzen. +- **Ein Rollback erfordert die Sicherung.** Es gibt kein Schema-Downgrade. Ein 3.0.x-Server verweigert eine aktualisierte Datenbank mit `native_schema_newer_than_binary`. Um zurückzuwechseln, stellen Sie die in Schritt 2 erstellte Sicherung wieder her, wodurch alles danach Geschriebene verworfen wird, und starten dann das 3.0.x-Image. + +Das Worker-Protokoll bleibt bei `1.20` und die Steuerungsebene bei Version `2`. + ## Kleine Clusterbereitstellungen {#small-clustered-deployments} :::note Vertrag des PHP-Servers 2.x @@ -405,6 +436,8 @@ Chart 1.x betreibt standardmäßig den nativen Server (`runtime: native`): ein S Ein bestehender PHP-2.x-Release wechselt bei einem gewöhnlichen Upgrade nicht auf den nativen Server: Das Chart verweigert das Upgrade, bis Sie `runtime` ausdrücklich setzen. Setzen Sie `runtime: php`, um Worker, Scheduler, Bootstrap-Job und Redis von PHP 2.x zu behalten. Um auf `runtime: native` zu wechseln, folgen Sie dem [Runbook zur nativen Übernahme](%%artifact.serverTakeoverRunbookUrl%%) und behalten `runtime: php` bei, bis die Übernahme abgeschlossen ist. Siehe die [UPGRADING-Hinweise](%%artifact.helmChartUpgradeUrl%%) des Charts. +Chart 1.1.0 ändert das Standard-Image von Server 3.0.5 auf 3.3.2, das das [native Schema-Upgrade](#native-schema-upgrade-3-0-to-3-3) von 8 auf 11 erfordert. Ein gewöhnliches `helm upgrade` von Chart 1.0.x ändert nur das Image, und die neuen Pods verweigern den Start mit `native_schema_upgrade_required`. Folgen Sie den [Schritten zu Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) des Charts: Skalieren Sie den Server bei ausgeschaltetem Autoscaling auf null, sichern Sie die Datenbank und führen Sie dann das Upgrade auf Chart 1.1.0 mit `native.schemaUpgrade.enabled=true` aus. Sein `pre-upgrade`-Hook führt `schema-upgrade` einmal aus, bevor die neuen Pods starten, und nur, wenn Helms `lookup` zeigt, dass alle Server gestoppt sind. Renderings durch Argo CD, Flux und `helm template` verweigern den Hook; verwenden Sie stattdessen den manuellen Job aus der README des Charts. Ein `helm rollback` auf eine Revision von Chart 1.0.x bringt den Server nicht zurück, weil 3.0.x die aktualisierte Datenbank verweigert: Stellen Sie stattdessen die Sicherung wieder her. + ### Einen Chart-Release auswählen {#helm-chart-selection} Jeder Chart-Release hält das getestete Server-Image in der `appVersion` der `Chart.yaml` fest; Chart und Server haben unabhängige Versionsnummern. Die ausgewählte [kompatible Kombination](./compatibility.md#last-qualified-reproducible-tuple) verbindet Chart **%%artifact.helmChartVersion%%** mit Server **%%artifact.helmChartAppVersion%%** aus denselben Release-Metadaten wie Tabelle und Installationsbefehl. Der [Prüfbericht zu OCI/veröffentlichtem Paket](%%artifact.helmChartQualificationUrl%%) bestätigt diese Kombination, keine neue Kubernetes-Installation. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/database-support.md index 741ca13146d..8a4e0cc9bbf 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: Datenbankkompatibilität Verwenden Sie diese Tabelle für Datenbanken im eingebetteten Laravel-Modus und für selbst gehosteten Server. Cloud verwaltet seine Laufzeitpersistenz. Cloud-Kunden konfigurieren SDK-Clients und Worker statt einer Laufzeitdatenbank. -Eine erklärte Kompatibilitätsbasis beweist nicht, dass jede neuere Version qualifiziert ist. Quelltests und installierte veröffentlichte Artefakte liefern unterschiedliche Nachweise. Diese Bestandsaufnahme bindet Workflow-2.20.3-Quellcode und Server-3.0.5-Veröffentlichungsnachweise. Sie ändert weder Laufzeitkompatibilität noch legt sie einen getesteten Mindest-/Höchstbereich fest. +Eine erklärte Kompatibilitätsbasis beweist nicht, dass jede neuere Version qualifiziert ist. Quelltests und installierte veröffentlichte Artefakte liefern unterschiedliche Nachweise. Diese Bestandsaufnahme bindet Workflow-2.20.3-Quellcode und Server-3.3.2-Veröffentlichungsnachweise. Sie ändert weder Laufzeitkompatibilität noch legt sie einen getesteten Mindest-/Höchstbereich fest. | Engine | Erklärte Kompatibilität | Beobachtete Quellqualifikation | Qualifikation veröffentlichter Artefakte | | --- | --- | --- | --- | -| MySQL | Eingebettet: Basis 8.0. Server: Basis 8.0. | Core: 26.10.0 in den ursprünglichen Feature-Jobs mit variablem Image-Tag. Server-Profile: 8.0.46 und 8.4.5. | Die Core-Beobachtung bindet den veröffentlichten Quellstand. Server 3.0.5 Compose nutzt `mysql:8.0` für Schema-/Health-Smoke, keine vollständige Ausführungs-, Kapazitäts- oder TLS-Qualifikation. | -| PostgreSQL | Eingebettet: Basis 13. Server: Basis 13. | Core: 18.6. Server-Profile: 16.15 und 17.11. | Die Core-Beobachtung bindet den veröffentlichten Quellstand. Im geprüften Bestand wurde kein an den Server-3.0.5-Index gebundener PostgreSQL-Endpunktnachweis gefunden. | -| MariaDB | Eingebettet: Basis 10.5. Server akzeptiert `mariadb`; hier ist keine Versionsbasis festgestellt. | Core: 10.5.29. Server-Profil: 10.11.19. | Die Core-Beobachtung bindet den veröffentlichten Quellstand. Im geprüften Bestand wurde kein an den Server-3.0.5-Index gebundener MariaDB-Endpunktnachweis gefunden. | -| SQLite | Eingebettete Fähigkeiten/Tests umfassen SQLite. Server erklärt Basis 3.35. | Die ursprünglichen Core-Quelljobs gaben keine SQLite-Bibliotheksversion aus. | Die Abnahme des installierten Core 2.20.3 verwendete SQLite, ohne einen Bibliotheksversionsbereich festzulegen. Der Korpus des eingefrorenen Server-3.1.0-Kandidaten bleibt getrennt von Stable 3.0.5. | +| MySQL | Eingebettet: Basis 8.0. Server: Basis 8.0. | Core: 26.10.0 in den ursprünglichen Feature-Jobs mit variablem Image-Tag. Server-Profile: 8.0.46 und 8.4.5. | Die Core-Beobachtung bindet den veröffentlichten Quellstand. Release-Smoke und Compose-Smoke mit exaktem Index von Server 3.3.2 nutzen per Digest fixiertes MySQL 8.0 für Start-/Health-Prüfungen, keine vollständige Ausführungs-, Kapazitäts- oder TLS-Qualifikation. | +| PostgreSQL | Eingebettet: Basis 13. Server: Basis 13. | Core: 18.6. Server-Profile: 16.15 und 17.11. | Die Core-Beobachtung bindet den veröffentlichten Quellstand. Der Release-Smoke von Server 3.3.2 startet das Image jeder Architektur kalt auf per Digest fixiertem PostgreSQL 17, nur für Readiness und Clusterinformationen, keine vollständige Ausführungs-, Kapazitäts- oder TLS-Qualifikation. | +| MariaDB | Eingebettet: Basis 10.5. Server akzeptiert `mariadb`; hier ist keine Versionsbasis festgestellt. | Core: 10.5.29. Server-Profil: 10.11.19. | Die Core-Beobachtung bindet den veröffentlichten Quellstand. In den geprüften Veröffentlichungsnachweisen wurde kein an den Server-3.3.2-Index gebundener MariaDB-Endpunktnachweis gefunden. | +| SQLite | Eingebettete Fähigkeiten/Tests umfassen SQLite. Server erklärt Basis 3.35. | Die ursprünglichen Core-Quelljobs gaben keine SQLite-Bibliotheksversion aus. | Die Abnahme des installierten Core 2.20.3 verwendete SQLite, ohne einen Bibliotheksversionsbereich festzulegen. Der Release-Smoke von Server 3.3.2 startet kalt auf SQLite, ebenfalls ohne Bibliotheksversionsbereich. | | SQL Server | Veröffentlichter eingebetteter Core bewirbt `sqlsrv`, bleibt jedoch unqualifiziert. Server-Qualifikation ist hier nicht festgestellt. | Kein SQL-Server-Job wurde aus der veröffentlichten Core-Matrix ermittelt. Der vorgeschlagene Backend-Guard ist separate Quellarbeit. | Keine entsprechende Veröffentlichungsqualifikation ermittelt. Leiten Sie Unterstützung nicht aus der eingebetteten Fähigkeitsangabe ab. | ## Nachweise einordnen {#reading-the-evidence} Das [Core-Inventar](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325) bindet die ursprünglichen Image-Digests und vier MySQL-, vier PostgreSQL- sowie einen MariaDB-Feature-Job am veröffentlichten Quellstand. Seine zwölf veröffentlichten Upgrade-Zellen prüfen Laravel/PHP-Kombinationen, nicht zwölf Datenbankendpunkte. Der separate [Nachweis mit normal installiertem Core](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927) umfasst 67 SQLite-basierte Stream-/Replay-/Fake-Fälle. Weder PHP-Version noch variables Image-Tag liefern eine nicht ausgegebene Datenbankversion. -Das [Server-Inventar](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) trennt native und ältere PHP-Quelljob-Bereiche. Der [Stable-3.0.5-Nachweis](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) enthält vier Compose-Smoke-Zellen für Architektur/Profile. `local` und `production` nutzen MySQL. Die geprüften Logs belegen keine genaue Begleitversion/Digest, Schreibkapazitätsqualifikation oder verifiziertes TLS. Quellprofile und eingefrorene Kandidaten qualifizieren kein anderes veröffentlichtes Image. +Das [Server-Inventar](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) trennt native und ältere PHP-Quelljob-Bereiche. Für Server 3.3.2 startet der [Release-Lauf](https://github.com/durable-workflow/server/actions/runs/42591612884) die amd64- und arm64-Images kalt auf SQLite, PostgreSQL 17 und MySQL 8.0, prüft `/api/ready` und authentifizierte Clusterinformationen und stoppt jedes mit SIGTERM. Der [Compose-Smoke mit exaktem Index](https://github.com/durable-workflow/server/actions/runs/42602031026) umfasst vier Zellen für Architektur/Profile gegen den Index `sha256:4aeceb42…`. `local` und `production` nutzen beide MySQL, wobei `mysql:8.0` per Digest fixiert ist. Der [Auslieferungsnachweis zu 3.3.2](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227) nimmt beide ab. Diese Läufe starten leere Datenbanken. Sie aktualisieren keine bestehende Datenbank, qualifizieren keine Schreibkapazität und verifizieren kein TLS, und ihre Logs melden keine genaue Patch-Version der Engine. Der frühere [Stable-3.0.5-Nachweis](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) hatte dieselbe Compose-Struktur mit variablem `mysql:8.0`. Quellprofile qualifizieren kein anderes veröffentlichtes Image. ## Herstellerlebenszyklus und verteilte Engines {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md index a2e643a375d..c9dde783bad 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -412,15 +412,28 @@ curl http://localhost:8080/api/cluster/info \ Liefert Build-Identität, Fähigkeitsflags, Protokollmanifeste, Limits und Erkennungsdaten für den Namespace aus `X-Namespace` (oder dem Abfrageparameter -`namespace`, sonst `default`). Gekürzte Ausgabe des Images 3.0.5: +`namespace`, sonst `default`). Gekürzte Ausgabe des Images 3.3.2: ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -428,6 +441,8 @@ Erkennungsdaten für den Namespace aus `X-Namespace` (oder dem Abfrageparameter "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -467,7 +482,7 @@ Wichtige Feldhinweise für Client-Code: - Die Build-Version steht in `version`, nicht in `server_version`. `implementation` ist auf dem nativen Server `"rust"`. - Prüfen Sie `control_plane.version` und `worker_protocol.version`, bevor Sie die - API aufrufen. Der native Server 3.0.5 bedient Steuerungsebene `2` und Worker-Protokoll + API aufrufen. Der native Server 3.3.2 bedient Steuerungsebene `2` und Worker-Protokoll `1.20` und akzeptiert Worker-Anfragen mit jeder Protokollversion von `1.0` bis `1.20`. - Workflow-Aufgabenbefehle stehen unter @@ -477,8 +492,11 @@ Wichtige Feldhinweise für Client-Code: `response_compression` ist leer, weil der native Server Antworten unkomprimiert sendet. - `native_unqualified` listet jedes Element der PHP-2.x-Antwort, das der native - Server auslässt, jeweils mit Begründung. Dazu gehören `topology`, - `supported_sdk_versions` und `client_compatibility`. + Server auslässt, jeweils mit Begründung. Dazu gehört `topology`. +- Seit 3.1.0 bedient der native Server auch `supported_sdk_versions` und + `client_compatibility`, die `server:info` und `doctor` der CLI lesen. + `client_compatibility.authority` ist `"protocol_manifests"`: Prüfen Sie die + Protokollmanifeste, nicht die SDK-Bereiche, bevor Sie die API aufrufen. - Der einzige Payload-Codec ist Avro: `capabilities.payload_codecs` ist genau `["avro"]`. - `qualified_for_php_takeover` ist immer `false`. Das Feld beschreibt den diff --git a/i18n/de/source-hashes.json b/i18n/de/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/de/source-hashes.json +++ b/i18n/de/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/i18n/es/docusaurus-plugin-content-docs/current/deployment.md b/i18n/es/docusaurus-plugin-content-docs/current/deployment.md index a7f7b871be7..8fd2b290e73 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/deployment.md @@ -263,6 +263,68 @@ la base de datos y con todos los Server detenidos. La referencia de Server mantiene los comandos Compose actualizados en [Imagen oficial + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose). +### Actualizar de Server 3.0.x a 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +Server 3.3.2 atraviesa tres versiones menores desde 3.0.x y cambia el esquema +nativo. En MySQL, MariaDB y PostgreSQL pasa de la versión 8 (3.0.x y 3.1.0) +por la 10 (3.2.0) hasta la 11 (de 3.3.0 a 3.3.2). En SQLite pasa de la 8 a la +10. Un Server nunca actualiza su esquema al arrancar: 3.3.2 iniciado sobre una +base de datos con la versión 8 se niega con `native_schema_upgrade_required`, +así que cambiar solo `DW_SERVER_IMAGE` deja el Server nuevo sin poder arrancar. +El comando `schema-upgrade` de la imagen 3.3.2 actualiza directamente una base +de datos con la versión 8. Las +[notas de actualización de 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) +describen el paso, y las +[notas de Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) +del chart de Helm enumeran los pasos de esquema y los cambios de runtime de +3.0.5 a 3.3.2. + +Para el despliegue Compose de un solo nodo: + +1. Detén el Server y deja MySQL en ejecución: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. Haz copia de MySQL y de `server_storage`, y registra la referencia de la + imagen actual. Esta copia es la única forma de volver a 3.0.x. +3. Cambia `DW_SERVER_IMAGE` a la imagen 3.3.2, descárgala y ejecuta + `schema-upgrade` una vez: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + Muestra el backend y las versiones de esquema anterior y posterior, por + ejemplo `"from_schema_version":8,"schema_version":11,"status":"upgraded"`. + En una base de datos que ya está al día solo verifica el esquema. +4. Inicia el Server con + `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` + y después confirma `/api/ready`, `/api/cluster/info` (`version` es `3.3.2`) y + el registro de workers. + +- **PostgreSQL:** los pasos de las versiones 10 y 11 crean sus índices con un + `CREATE INDEX` simple, que bloquea las escrituras en `workflow_tasks` hasta + que termina la creación. Con una tabla `workflow_tasks` grande, planifica el + tiempo de inactividad que esto supone. +- **MySQL y MariaDB:** allí el DDL se confirma por sí solo, así que la + actualización marca la base de datos como en actualización hasta que termina, + y mientras tanto todos los Server la rechazan con + `native_schema_upgrade_incomplete`. Si se interrumpe una actualización, + vuelve a ejecutar `schema-upgrade` para reanudarla. +- **La reversión necesita la copia.** No existe una reversión del esquema. Un + Server 3.0.x rechaza una base de datos actualizada con + `native_schema_newer_than_binary`. Para volver atrás, restaura la copia hecha + en el paso 2, lo que descarta todo lo escrito después, y luego inicia la + imagen 3.0.x. + +El protocolo de workers se mantiene en `1.20` y el plano de control en la +versión `2`. + ## Clústeres pequeños {#small-clustered-deployments} :::note Contrato de PHP Server 2.x @@ -515,6 +577,8 @@ El chart 1.x ejecuta el Server nativo de forma predeterminada (`runtime: native` Una versión PHP 2.x existente no pasa al Server nativo con una actualización ordinaria: el chart se niega hasta que defina `runtime` explícitamente. Defina `runtime: php` para conservar el worker, el programador, la tarea de inicialización y Redis de PHP 2.x. Para pasar a `runtime: native`, siga el [runbook de toma de control nativa](%%artifact.serverTakeoverRunbookUrl%%) y mantenga `runtime: php` hasta que la toma de control haya terminado. Consulte las [notas UPGRADING](%%artifact.helmChartUpgradeUrl%%) del chart. +El chart 1.1.0 cambia la imagen predeterminada de Server 3.0.5 a 3.3.2, que necesita la [actualización del esquema nativo](#native-schema-upgrade-3-0-to-3-3) de 8 a 11. Un `helm upgrade` ordinario desde el chart 1.0.x solo cambia la imagen, y los pods nuevos se niegan a arrancar con `native_schema_upgrade_required`. Siga los [pasos de Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) del chart: escale el Server a cero con el autoescalado desactivado, haga una copia de seguridad de la base de datos y después actualice al chart 1.1.0 con `native.schemaUpgrade.enabled=true`. Su hook `pre-upgrade` ejecuta `schema-upgrade` una vez antes de que arranquen los pods nuevos, y solo cuando el `lookup` de Helm muestra todos los Server detenidos. Los manifiestos generados por Argo CD, Flux y `helm template` rechazan el hook; use en su lugar el Job manual del README del chart. Un `helm rollback` a una revisión del chart 1.0.x no recupera el Server, porque 3.0.x rechaza la base de datos actualizada: restaure la copia de seguridad en su lugar. + ### Elegir una versión del chart {#helm-chart-selection} Cada versión del chart registra en `appVersion` de `Chart.yaml` la imagen del Server con la que se probó; el chart y el Server tienen números de versión independientes. La [combinación compatible seleccionada](./compatibility.md#last-qualified-reproducible-tuple) empareja el chart **%%artifact.helmChartVersion%%** con Server **%%artifact.helmChartAppVersion%%**, usando los mismos metadatos de versiones que la tabla y el comando de instalación. La [verificación OCI/del paquete publicado](%%artifact.helmChartQualificationUrl%%) comprueba ese par, no una instalación nueva de Kubernetes. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/database-support.md index a4252010afc..f90f48214e8 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: Compatibilidad de bases de datos Use esta tabla para elegir bases de datos de Laravel embebido y Server autogestionado. Cloud gestiona su persistencia de runtime. Sus clientes configuran clientes SDK y workers en lugar de una base de datos del runtime. -Una base de compatibilidad declarada no demuestra que todas las versiones posteriores estén cualificadas. Las pruebas de código y los artefactos publicados e instalados son evidencias distintas. Esta instantánea vincula el código de Workflow 2.20.3 y los recibos de Server 3.0.5. No cambia la compatibilidad ni establece un intervalo mínimo/máximo probado. +Una base de compatibilidad declarada no demuestra que todas las versiones posteriores estén cualificadas. Las pruebas de código y los artefactos publicados e instalados son evidencias distintas. Esta instantánea vincula el código de Workflow 2.20.3 y los recibos de Server 3.3.2. No cambia la compatibilidad ni establece un intervalo mínimo/máximo probado. | Motor | Compatibilidad declarada | Cualificación de código observada | Cualificación del artefacto publicado | | --- | --- | --- | --- | -| MySQL | Embebido: base 8.0. Server: base 8.0. | Core: 26.10.0 en los jobs originales con imagen flotante. Perfiles Server: 8.0.46 y 8.4.5. | La observación de Core está vinculada al código publicado. Compose de Server 3.0.5 usa `mysql:8.0` para smoke de esquema/salud, no cualificación completa de ejecución/capacidad/TLS. | -| PostgreSQL | Embebido: base 13. Server: base 13. | Core: 18.6. Perfiles Server: 16.15 y 17.11. | La observación de Core está vinculada al código publicado. No se encontró recibo de endpoint PostgreSQL vinculado al índice Server 3.0.5 en el inventario inspeccionado. | -| MariaDB | Embebido: base 10.5. Server acepta `mariadb`; aquí no se establece una versión base. | Core: 10.5.29. Perfil Server: 10.11.19. | La observación de Core está vinculada al código publicado. No se encontró recibo de endpoint MariaDB vinculado al índice Server 3.0.5 en el inventario inspeccionado. | -| SQLite | Las capacidades/pruebas embebidas incluyen SQLite. Server declara base 3.35. | Los jobs originales de código Core no imprimieron la versión de la biblioteca SQLite. | La aceptación de Core 2.20.3 instalado ejercitó SQLite sin establecer un intervalo de versiones. El corpus del candidato congelado Server 3.1.0 es independiente del estable 3.0.5. | +| MySQL | Embebido: base 8.0. Server: base 8.0. | Core: 26.10.0 en los jobs originales con imagen flotante. Perfiles Server: 8.0.46 y 8.4.5. | La observación de Core está vinculada al código publicado. El smoke de publicación de Server 3.3.2 y el smoke Compose de índice exacto usan MySQL 8.0 fijado por digest para comprobaciones de arranque/salud, no cualificación completa de ejecución/capacidad/TLS. | +| PostgreSQL | Embebido: base 13. Server: base 13. | Core: 18.6. Perfiles Server: 16.15 y 17.11. | La observación de Core está vinculada al código publicado. El smoke de publicación de Server 3.3.2 arranca en frío la imagen de cada arquitectura sobre PostgreSQL 17 fijado por digest solo para disponibilidad e información del clúster, no cualificación completa de ejecución/capacidad/TLS. | +| MariaDB | Embebido: base 10.5. Server acepta `mariadb`; aquí no se establece una versión base. | Core: 10.5.29. Perfil Server: 10.11.19. | La observación de Core está vinculada al código publicado. No se encontró recibo de endpoint MariaDB vinculado al índice Server 3.3.2 en la evidencia de publicación inspeccionada. | +| SQLite | Las capacidades/pruebas embebidas incluyen SQLite. Server declara base 3.35. | Los jobs originales de código Core no imprimieron la versión de la biblioteca SQLite. | La aceptación de Core 2.20.3 instalado ejercitó SQLite sin establecer un intervalo de versiones. El smoke de publicación de Server 3.3.2 arranca en frío sobre SQLite, también sin un intervalo de versiones de la biblioteca. | | SQL Server | Core embebido publicado anuncia `sqlsrv`, pero sigue sin cualificar. Aquí no se establece cualificación de Server. | No se recuperó job SQL Server de la matriz Core publicada. El guard propuesto del backend es trabajo de código separado. | No se recuperó cualificación publicada correspondiente. No infiera soporte del anuncio de capacidad embebida. | ## Cómo leer la evidencia {#reading-the-evidence} El [inventario Core](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325) vincula los digests originales y cuatro jobs MySQL, cuatro PostgreSQL y uno MariaDB en el código publicado. Sus doce celdas de actualización publicada cubren combinaciones Laravel/PHP, no doce endpoints de bases de datos. El [recibo de Core instalado normalmente](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927) cubre por separado 67 casos de streams/replay/fakes con SQLite. Ni la versión PHP ni una imagen flotante proporcionan una versión de base de datos no impresa. -El [inventario Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) separa los ámbitos de jobs de código nativo y PHP anterior. El [recibo estable 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) tiene cuatro celdas smoke Compose de arquitectura/perfil. Tanto `local` como `production` usan MySQL. Los logs inspeccionados no recuperan versión/digest exactos del acompañante, cualificación de escritura ni TLS verificado. Los perfiles de código y un candidato congelado no cualifican otra imagen publicada. +El [inventario Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) separa los ámbitos de jobs de código nativo y PHP anterior. Para Server 3.3.2, la [ejecución de publicación](https://github.com/durable-workflow/server/actions/runs/42591612884) arranca en frío las imágenes amd64 y arm64 sobre SQLite, PostgreSQL 17 y MySQL 8.0, comprueba `/api/ready` y la información del clúster autenticada, y detiene cada una con SIGTERM. El [smoke Compose de índice exacto](https://github.com/durable-workflow/server/actions/runs/42602031026) tiene cuatro celdas de arquitectura/perfil contra el índice `sha256:4aeceb42…`. Tanto `local` como `production` usan MySQL, con `mysql:8.0` fijado por digest. El [registro de entrega de 3.3.2](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227) acepta ambos. Estas ejecuciones arrancan bases de datos vacías. No actualizan una existente, no cualifican la capacidad de escritura ni verifican TLS, y sus logs no informan de una versión patch exacta del motor. El [recibo estable 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) anterior tenía la misma forma Compose con un `mysql:8.0` flotante. Los perfiles de código no cualifican otra imagen publicada. ## Ciclo del proveedor y motores distribuidos {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md index ae5ebd89b84..68d3c892bd8 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -377,15 +377,28 @@ curl http://localhost:8080/api/cluster/info \ -H "Authorization: Bearer $TOKEN" ``` -Devuelve la identidad de la compilación, los indicadores de capacidad, los manifiestos de protocolo, los límites y el descubrimiento del namespace indicado por `X-Namespace` (o por el parámetro de consulta `namespace`; si no, `default`). Salida abreviada de la imagen 3.0.5: +Devuelve la identidad de la compilación, los indicadores de capacidad, los manifiestos de protocolo, los límites y el descubrimiento del namespace indicado por `X-Namespace` (o por el parámetro de consulta `namespace`; si no, `default`). Salida abreviada de la imagen 3.3.2: ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -393,6 +406,8 @@ Devuelve la identidad de la compilación, los indicadores de capacidad, los mani "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -430,10 +445,11 @@ Devuelve la identidad de la compilación, los indicadores de capacidad, los mani Notas sobre los campos clave para el código cliente: - La versión de la compilación es `version`, no `server_version`. `implementation` es `"rust"` en el Server nativo. -- Compruebe `control_plane.version` y `worker_protocol.version` antes de llamar a la API. El Server nativo 3.0.5 sirve el plano de control `2` y el protocolo de workers `1.20`, y acepta solicitudes de workers que envíen cualquier versión de protocolo desde `1.0` hasta `1.20`. +- Compruebe `control_plane.version` y `worker_protocol.version` antes de llamar a la API. El Server nativo 3.3.2 sirve el plano de control `2` y el protocolo de workers `1.20`, y acepta solicitudes de workers que envíen cualquier versión de protocolo desde `1.0` hasta `1.20`. - Los comandos de tareas de workflow están en `worker_protocol.server_capabilities.supported_workflow_task_commands`. - Un indicador de capacidad con valor `false` designa una función o un contrato publicado que el Server nativo no sirve. `response_compression` está vacío porque el Server nativo envía respuestas sin comprimir. -- `native_unqualified` enumera cada miembro de la respuesta de PHP 2.x que el Server nativo omite, junto con el motivo. Incluye `topology`, `supported_sdk_versions` y `client_compatibility`. +- `native_unqualified` enumera cada miembro de la respuesta de PHP 2.x que el Server nativo omite, junto con el motivo. Incluye `topology`. +- Desde 3.1.0, el Server nativo también sirve `supported_sdk_versions` y `client_compatibility`, que leen `server:info` y `doctor` de la CLI. `client_compatibility.authority` es `"protocol_manifests"`: compruebe los manifiestos de protocolo, no los intervalos de SDK, antes de llamar a la API. - El único codec de cargas es Avro: `capabilities.payload_codecs` es exactamente `["avro"]`. - `qualified_for_php_takeover` siempre es `false`. Describe el Server en ejecución, que nunca toma el control de una base de datos al arrancar, no si `upgrade-takeover` aceptará la suya. - La respuesta también incluye los manifiestos `auth_composition_contract`, `principal_attribution_contract`, `service_catalog_read_contract` y `message_streams_contract`. diff --git a/i18n/es/source-hashes.json b/i18n/es/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/es/source-hashes.json +++ b/i18n/es/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md b/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md index f71cdbc0b3c..056c90974a8 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md @@ -269,6 +269,67 @@ pendant que tous les Servers sont arrêtés. La référence Server conserve les exemples Compose actuels au niveau des commandes dans la section [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose). +### Mettre à niveau de Server 3.0.x vers 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +Server 3.3.2 franchit trois versions mineures depuis 3.0.x et modifie le schéma +natif. Sur MySQL, MariaDB et PostgreSQL, il passe de la version 8 (3.0.x et +3.1.0) à la 10 (3.2.0), puis à la 11 (3.3.0 à 3.3.2). Sur SQLite, il passe de 8 +à 10. Un Server ne met jamais son schéma à niveau au démarrage : 3.3.2 démarré +sur une base en version 8 refuse avec `native_schema_upgrade_required`, si bien +que changer uniquement `DW_SERVER_IMAGE` laisse le nouveau Server incapable de +démarrer. La commande `schema-upgrade` de l'image 3.3.2 met directement à +niveau une base en version 8. Les +[notes de mise à niveau 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) +décrivent cette étape, et les +[notes Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) +du chart Helm énumèrent les étapes de schéma et les changements du runtime de +3.0.5 à 3.3.2. + +Pour le déploiement Compose sur un nœud : + +1. Arrêtez le Server et laissez MySQL en marche : + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. Sauvegardez MySQL et `server_storage`, et consignez la référence de l'image + actuelle. Cette sauvegarde est le seul moyen de revenir à 3.0.x. +3. Remplacez `DW_SERVER_IMAGE` par l'image 3.3.2, téléchargez-la et exécutez + `schema-upgrade` une fois : + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + La commande affiche le backend et les versions de schéma avant et après, par + exemple `"from_schema_version":8,"schema_version":11,"status":"upgraded"`. + Sur une base déjà à jour, elle vérifie seulement le schéma. +4. Démarrez le Server avec + `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`, + puis confirmez `/api/ready`, `/api/cluster/info` (`version` vaut `3.3.2`) et + l'enregistrement worker. + +- **PostgreSQL :** les étapes des versions 10 et 11 construisent leurs index + avec un simple `CREATE INDEX`, qui bloque les écritures dans `workflow_tasks` + jusqu'à la fin de la construction. Sur une grande table `workflow_tasks`, + prévoyez l'interruption correspondante. +- **MySQL et MariaDB :** le DDL y est validé de façon autonome ; la mise à + niveau marque donc la base comme en cours de mise à niveau jusqu'à son terme, + et chaque Server la refuse entre-temps avec `native_schema_upgrade_incomplete`. + Si une mise à niveau est interrompue, relancez `schema-upgrade` pour la + reprendre. +- **Le retour arrière nécessite la sauvegarde.** Il n'existe aucune + rétrogradation de schéma. Un Server 3.0.x refuse une base mise à niveau avec + `native_schema_newer_than_binary`. Pour revenir en arrière, restaurez la + sauvegarde prise à l'étape 2, ce qui supprime tout ce qui a été écrit depuis, + puis démarrez l'image 3.0.x. + +Le protocole worker reste à `1.20` et le plan de contrôle à la version `2`. + ## Petits clusters {#small-clustered-deployments} :::note Contrat PHP Server 2.x @@ -528,6 +589,8 @@ Le chart 1.x exécute par défaut le Server natif (`runtime: native`) : un seul Une version PHP 2.x existante ne passe pas au natif lors d’une mise à niveau ordinaire : le chart refuse tant que vous n’avez pas défini `runtime` explicitement. Définissez `runtime: php` pour conserver le worker, l’ordonnanceur, le job d’initialisation et Redis de PHP 2.x. Pour passer à `runtime: native`, suivez le [runbook de reprise native](%%artifact.serverTakeoverRunbookUrl%%) et conservez `runtime: php` jusqu’à ce que la reprise soit terminée. Consultez les [notes UPGRADING](%%artifact.helmChartUpgradeUrl%%) du chart. +Le chart 1.1.0 change l’image par défaut de Server 3.0.5 à 3.3.2, ce qui nécessite la [mise à niveau du schéma natif](#native-schema-upgrade-3-0-to-3-3) de 8 à 11. Un `helm upgrade` ordinaire depuis le chart 1.0.x ne change que l’image, et les nouveaux pods refusent de démarrer avec `native_schema_upgrade_required`. Suivez les [étapes Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) du chart : ramenez le Server à zéro réplica avec l’autoscaling désactivé, sauvegardez la base, puis passez au chart 1.1.0 avec `native.schemaUpgrade.enabled=true`. Son hook `pre-upgrade` exécute `schema-upgrade` une fois avant le démarrage des nouveaux pods, et seulement si le `lookup` de Helm montre que tous les Servers sont arrêtés. Les rendus Argo CD, Flux et `helm template` refusent le hook ; utilisez plutôt le Job manuel du README du chart. Un `helm rollback` vers une révision du chart 1.0.x ne rétablit pas le Server, car 3.0.x refuse la base mise à niveau : restaurez plutôt la sauvegarde. + ### Choisir une version du chart {#helm-chart-selection} Chaque version du chart enregistre l’image Server testée dans l’`appVersion` de `Chart.yaml` ; chart et Server ont des numéros de version indépendants. La [combinaison compatible sélectionnée](./compatibility.md#last-qualified-reproducible-tuple) associe le chart **%%artifact.helmChartVersion%%** à Server **%%artifact.helmChartAppVersion%%**, depuis les mêmes métadonnées que le tableau et la commande d’installation. La [vérification OCI/du paquet publié](%%artifact.helmChartQualificationUrl%%) confirme cette paire, pas une nouvelle installation Kubernetes. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/database-support.md index 9261b461bfe..65120a9f45c 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: Compatibilité des bases de données Utilisez ce tableau pour choisir la base du mode Laravel embarqué ou du Server autohébergé. Cloud gère sa persistance runtime. Les clients Cloud configurent clients SDK et workers, pas une base du runtime. -Une base de compatibilité déclarée ne prouve pas la qualification de toutes les versions ultérieures. Tests source et artefacts publiés installés constituent des preuves différentes. Cet état lie le code Workflow 2.20.3 et les reçus Server 3.0.5. Il ne change pas la compatibilité et ne définit pas de plage minimale/maximale testée. +Une base de compatibilité déclarée ne prouve pas la qualification de toutes les versions ultérieures. Tests source et artefacts publiés installés constituent des preuves différentes. Cet état lie le code Workflow 2.20.3 et les reçus de publication Server 3.3.2. Il ne change pas la compatibilité et ne définit pas de plage minimale/maximale testée. | Moteur | Compatibilité déclarée | Qualification source observée | Qualification de l’artefact publié | | --- | --- | --- | --- | -| MySQL | Embarqué : base 8.0. Server : base 8.0. | Core : 26.10.0 dans les jobs originaux à image flottante. Profils Server : 8.0.46 et 8.4.5. | L’observation Core est liée au code publié. Compose Server 3.0.5 utilise `mysql:8.0` pour un smoke schéma/santé, pas une qualification complète exécution/capacité/TLS. | -| PostgreSQL | Embarqué : base 13. Server : base 13. | Core : 18.6. Profils Server : 16.15 et 17.11. | L’observation Core est liée au code publié. Aucun reçu d’endpoint PostgreSQL lié à l’index Server 3.0.5 n’a été trouvé dans l’inventaire examiné. | -| MariaDB | Embarqué : base 10.5. Server accepte `mariadb` ; aucune version de base n’est établie ici. | Core : 10.5.29. Profil Server : 10.11.19. | L’observation Core est liée au code publié. Aucun reçu d’endpoint MariaDB lié à l’index Server 3.0.5 n’a été trouvé dans l’inventaire examiné. | -| SQLite | Les capacités/tests embarqués comprennent SQLite. Server déclare une base 3.35. | Les jobs source Core originaux n’ont pas affiché la version de la bibliothèque SQLite. | L’acceptation du Core 2.20.3 installé a exercé SQLite sans établir de plage de versions. Le corpus du candidat Server 3.1.0 figé reste distinct du stable 3.0.5. | +| MySQL | Embarqué : base 8.0. Server : base 8.0. | Core : 26.10.0 dans les jobs originaux à image flottante. Profils Server : 8.0.46 et 8.4.5. | L’observation Core est liée au code publié. Le smoke de publication et le smoke Compose à index exact de Server 3.3.2 utilisent MySQL 8.0 fixé par digest pour des vérifications de démarrage/santé, pas une qualification complète exécution/capacité/TLS. | +| PostgreSQL | Embarqué : base 13. Server : base 13. | Core : 18.6. Profils Server : 16.15 et 17.11. | L’observation Core est liée au code publié. Le smoke de publication de Server 3.3.2 démarre à froid l’image de chaque architecture sur PostgreSQL 17 fixé par digest, uniquement pour la disponibilité et les informations du cluster, pas une qualification complète exécution/capacité/TLS. | +| MariaDB | Embarqué : base 10.5. Server accepte `mariadb` ; aucune version de base n’est établie ici. | Core : 10.5.29. Profil Server : 10.11.19. | L’observation Core est liée au code publié. Aucun reçu d’endpoint MariaDB lié à l’index Server 3.3.2 n’a été trouvé dans les preuves de publication examinées. | +| SQLite | Les capacités/tests embarqués comprennent SQLite. Server déclare une base 3.35. | Les jobs source Core originaux n’ont pas affiché la version de la bibliothèque SQLite. | L’acceptation du Core 2.20.3 installé a exercé SQLite sans établir de plage de versions. Le smoke de publication de Server 3.3.2 démarre à froid sur SQLite, également sans plage de versions de la bibliothèque. | | SQL Server | Le Core embarqué publié annonce `sqlsrv`, mais reste non qualifié. La qualification Server n’est pas établie ici. | Aucun job SQL Server retrouvé dans la matrice Core publiée. Le garde backend proposé est un travail source distinct. | Aucune qualification publiée correspondante retrouvée. Ne déduisez pas la prise en charge de l’annonce de capacité embarquée. | ## Interpréter les preuves {#reading-the-evidence} L’[inventaire Core](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325) lie les digests d’image originaux et quatre jobs MySQL, quatre PostgreSQL et un MariaDB au code publié. Ses douze cellules de mise à niveau publiée couvrent Laravel/PHP, pas douze endpoints de base de données. Le [reçu Core installé normalement](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927) couvre séparément 67 cas stream/replay/fake sous SQLite. Ni version PHP ni sélecteur d’image flottant ne fournissent une version de base non affichée. -L’[inventaire Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) sépare les périmètres des jobs source natifs et PHP historiques. Le [reçu stable 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) contient quatre cellules smoke Compose architecture/profil. `local` et `production` utilisent MySQL. Les logs examinés ne récupèrent pas de version/digest exact du compagnon, de qualification de capacité d’écriture ou de TLS vérifié. Profils source et candidat figé ne qualifient pas une autre image publiée. +L’[inventaire Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) sépare les périmètres des jobs source natifs et PHP historiques. Pour Server 3.3.2, l’[exécution de publication](https://github.com/durable-workflow/server/actions/runs/42591612884) démarre à froid les images amd64 et arm64 sur SQLite, PostgreSQL 17 et MySQL 8.0, vérifie `/api/ready` et les informations du cluster authentifiées, puis arrête chacune avec SIGTERM. Le [smoke Compose à index exact](https://github.com/durable-workflow/server/actions/runs/42602031026) contient quatre cellules architecture/profil sur l’index `sha256:4aeceb42…`. `local` et `production` utilisent MySQL, avec `mysql:8.0` fixé par digest. L’[enregistrement de livraison 3.3.2](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227) accepte les deux. Ces exécutions démarrent des bases vides. Elles ne mettent pas à niveau une base existante, ne qualifient pas la capacité d’écriture et ne vérifient pas TLS, et leurs logs n’indiquent pas de version corrective exacte du moteur. Le [reçu stable 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) antérieur avait la même forme Compose avec un `mysql:8.0` flottant. Les profils source ne qualifient pas une autre image publiée. ## Cycle fournisseur et moteurs distribués {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md index 28afb1fd39e..31df5cfb374 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -377,15 +377,28 @@ curl http://localhost:8080/api/cluster/info \ -H "Authorization: Bearer $TOKEN" ``` -Renvoie l’identité du build, les indicateurs de capacités, les manifestes de protocole, les limites et la découverte pour le namespace désigné par `X-Namespace` (ou le paramètre de requête `namespace`, à défaut `default`). Sortie abrégée de l’image 3.0.5 : +Renvoie l’identité du build, les indicateurs de capacités, les manifestes de protocole, les limites et la découverte pour le namespace désigné par `X-Namespace` (ou le paramètre de requête `namespace`, à défaut `default`). Sortie abrégée de l’image 3.3.2 : ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -393,6 +406,8 @@ Renvoie l’identité du build, les indicateurs de capacités, les manifestes de "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -430,10 +445,11 @@ Renvoie l’identité du build, les indicateurs de capacités, les manifestes de Points clés pour le code client : - La version du build est `version`, pas `server_version`. `implementation` vaut `"rust"` sur le Server natif. -- Vérifiez `control_plane.version` et `worker_protocol.version` avant d’appeler l’API. Le natif 3.0.5 sert le plan de contrôle `2` et le protocole worker `1.20`, et accepte les requêtes worker annonçant toute version de protocole de `1.0` à `1.20`. +- Vérifiez `control_plane.version` et `worker_protocol.version` avant d’appeler l’API. Le natif 3.3.2 sert le plan de contrôle `2` et le protocole worker `1.20`, et accepte les requêtes worker annonçant toute version de protocole de `1.0` à `1.20`. - Les commandes de tâche workflow se trouvent sous `worker_protocol.server_capabilities.supported_workflow_task_commands`. - Un indicateur de capacité à `false` désigne une fonctionnalité ou un contrat publié que le natif ne sert pas. `response_compression` est vide, car le natif envoie des réponses non compressées. -- `native_unqualified` liste chaque membre de la réponse PHP 2.x que le natif omet, avec la raison. On y trouve `topology`, `supported_sdk_versions` et `client_compatibility`. +- `native_unqualified` liste chaque membre de la réponse PHP 2.x que le natif omet, avec la raison. On y trouve `topology`. +- Depuis 3.1.0, le natif sert aussi `supported_sdk_versions` et `client_compatibility`, que lisent `server:info` et `doctor` de la CLI. `client_compatibility.authority` vaut `"protocol_manifests"` : vérifiez les manifestes de protocole, et non les plages de SDK, avant d’appeler l’API. - Le seul codec de payload est Avro : `capabilities.payload_codecs` vaut exactement `["avro"]`. - `qualified_for_php_takeover` vaut toujours `false`. Il décrit le Server en cours d’exécution, qui ne reprend jamais une base au démarrage, et n’indique pas si `upgrade-takeover` acceptera la vôtre. - La réponse contient aussi les manifestes `auth_composition_contract`, `principal_attribution_contract`, `service_catalog_read_contract` et `message_streams_contract`. diff --git a/i18n/fr/source-hashes.json b/i18n/fr/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/fr/source-hashes.json +++ b/i18n/fr/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md b/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md index 74816c5df5c..74bfa9ed5bd 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md @@ -170,6 +170,37 @@ docker compose --env-file durable-workflow.prod.env \ ネイティブ Server は起動時にスキーマを確認します。ネイティブの同一マイナー系列内のパッチリリースはスキーマを維持するため、イメージの変更だけで済みます。リリースノートでスキーマ変更が告知されたリリースでは、データベースをバックアップし、全 Server を停止した状態で、イメージの `schema-upgrade` コマンドも実行する必要があります。最新のコマンド例は Server リファレンスの[公式イメージと Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose)にあります。 +### Server 3.0.x から 3.3.2 へのアップグレード {#native-schema-upgrade-3-0-to-3-3} + +Server 3.3.2 は 3.0.x から 3 つのマイナーリリースをまたぎ、ネイティブのスキーマを変更します。MySQL、MariaDB、PostgreSQL では、バージョン 8（3.0.x と 3.1.0）から 10（3.2.0）を経て 11（3.3.0～3.3.2）へ移行します。SQLite では 8 から 10 へ移行します。Server が起動時にスキーマをアップグレードすることはありません。3.3.2 はバージョン 8 のデータベースで起動すると `native_schema_upgrade_required` で拒否するため、`DW_SERVER_IMAGE` を変更するだけでは新しい Server を起動できません。3.3.2 イメージの `schema-upgrade` コマンドは、バージョン 8 のデータベースを直接アップグレードします。[3.3.0 のアップグレードノート](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade)がこの手順を説明し、Helm チャートの[チャート 1.1.0 / Server 3.3.2 のノート](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)が、3.0.5 から 3.3.2 までのスキーマ手順とランタイムの変更を列挙しています。 + +単一ノードの Compose デプロイでは次のようにします。 + +1. MySQL は稼働させたまま、Server を停止します。 + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. MySQL と `server_storage` をバックアップし、現在のイメージ参照を記録します。3.0.x へ戻る手段はこのバックアップだけです。 +3. `DW_SERVER_IMAGE` を 3.3.2 イメージに変更し、pull してから `schema-upgrade` を一度実行します。 + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + バックエンドと、アップグレード前後のスキーマバージョンを出力します。例: `"from_schema_version":8,"schema_version":11,"status":"upgraded"`。すでに最新のデータベースでは、スキーマの検証だけを行います。 +4. `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` で Server を起動し、`/api/ready`、`/api/cluster/info`（`version` が `3.3.2`）、Worker 登録を確認します。 + +- **PostgreSQL:** バージョン 10 と 11 の手順は通常の `CREATE INDEX` でインデックスを作成するため、作成が終わるまで `workflow_tasks` への書き込みがブロックされます。`workflow_tasks` テーブルが大きい場合は、そのためのダウンタイムを計画してください。 +- **MySQL と MariaDB:** これらでは DDL が単独でコミットされるため、アップグレードは完了までデータベースをアップグレード中としてマークし、その間はすべての Server が `native_schema_upgrade_incomplete` で拒否します。アップグレードが中断された場合は、`schema-upgrade` を再実行すると再開します。 +- **ロールバックにはバックアップが必要です。** スキーマのダウングレードはありません。3.0.x の Server はアップグレード済みのデータベースを `native_schema_newer_than_binary` で拒否します。戻すには、手順 2 で取得したバックアップを復元し（それ以降に書き込まれた内容はすべて失われます）、その後 3.0.x イメージを起動してください。 + +Worker プロトコルは `1.20`、コントロールプレーンはバージョン `2` のままです。 + ## 小規模クラスター {#small-clustered-deployments} :::note PHP Server 2.x の契約 @@ -340,6 +371,8 @@ helm install durable-workflow \ 既存の PHP 2.x リリースは、通常のアップグレードではネイティブへ移行しません。`runtime` を明示的に設定するまで、チャートはアップグレードを拒否します。PHP 2.x の Worker、スケジューラー、bootstrap Job、Redis を維持するには `runtime: php` を設定します。`runtime: native` へ移行するには、[ネイティブ移行（テイクオーバー）手順書](%%artifact.serverTakeoverRunbookUrl%%)に従い、テイクオーバーが完了するまでは `runtime: php` を維持してください。チャートの[UPGRADING ノート](%%artifact.helmChartUpgradeUrl%%)も参照してください。 +チャート 1.1.0 は既定のイメージを Server 3.0.5 から 3.3.2 に変更します。3.3.2 には 8 から 11 への[ネイティブスキーマのアップグレード](#native-schema-upgrade-3-0-to-3-3)が必要です。チャート 1.0.x からの通常の `helm upgrade` はイメージだけを変更するため、新しい Pod は `native_schema_upgrade_required` で起動を拒否します。チャートの[チャート 1.1.0 / Server 3.3.2 の手順](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)に従ってください。オートスケーリングを無効にして Server をゼロにスケールし、データベースをバックアップしてから、`native.schemaUpgrade.enabled=true` でチャート 1.1.0 にアップグレードします。その `pre-upgrade` フックは、新しい Pod の起動前に `schema-upgrade` を一度実行します。ただし実行するのは、Helm の `lookup` ですべての Server が停止していると確認できる場合だけです。Argo CD、Flux、`helm template` によるレンダリングではフックが拒否されるため、代わりにチャート README の手動 Job を使ってください。チャート 1.0.x のリビジョンへ `helm rollback` しても Server は戻りません。3.0.x はアップグレード済みのデータベースを拒否するためです。代わりにバックアップを復元してください。 + ### チャートのリリースを選ぶ {#helm-chart-selection} 各チャートリリースは、テスト対象の Server イメージを `Chart.yaml` の `appVersion` に記録します。チャートと Server のバージョン番号は独立しています。選択した[互換な組み合わせ](./compatibility.md#last-qualified-reproducible-tuple)は、チャート **%%artifact.helmChartVersion%%** と Server **%%artifact.helmChartAppVersion%%** で、表やインストールコマンドと同じリリースメタデータに基づきます。[公開済み OCI/パッケージの検証記録](%%artifact.helmChartQualificationUrl%%)が確認するのはその組み合わせであり、新たな Kubernetes インストールではありません。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/database-support.md index 200e3c4b0cc..6ab52a128d3 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: データベースの互換性 組み込み Laravel とセルフホスト Server のデータベース選択には、この表を使ってください。Cloud はランタイムの永続化を管理します。Cloud の利用者はランタイムのデータベースではなく SDK クライアントと Worker を設定します。 -宣言された互換性の基準は、それ以降の全バージョンの検証を意味しません。ソーステストと、公開済みパッケージをインストールした検証は別の証拠です。この一覧は Workflow 2.20.3 のソースと Server 3.0.5 の公開記録に紐づきます。ランタイム互換性を変更せず、検証済みの最小・最新バージョン範囲も定めません。 +宣言された互換性の基準は、それ以降の全バージョンの検証を意味しません。ソーステストと、公開済みパッケージをインストールした検証は別の証拠です。この一覧は Workflow 2.20.3 のソースと Server 3.3.2 の公開記録に紐づきます。ランタイム互換性を変更せず、検証済みの最小・最新バージョン範囲も定めません。 | エンジン | 宣言された互換性 | 観測されたソース検証 | 公開成果物の検証 | | --- | --- | --- | --- | -| MySQL | 組み込み: 基準 8.0。Server: 基準 8.0。 | Core: 元の可変イメージタグの機能ジョブでは 26.10.0。Server のプロファイル: 8.0.46 と 8.4.5。 | Core の観測は公開ソースに紐づきます。Server 3.0.5 Compose の `mysql:8.0` はスキーマ・ヘルスのスモークで、実行・容量・TLS 全体の検証ではありません。 | -| PostgreSQL | 組み込み: 基準 13。Server: 基準 13。 | Core: 18.6。Server のプロファイル: 16.15 と 17.11。 | Core の観測は公開ソースに紐づきます。調査した公開一覧には Server 3.0.5 のインデックスに紐づく PostgreSQL エンドポイントの記録はありません。 | -| MariaDB | 組み込み: 基準 10.5。Server は `mariadb` を受け付けますが、ここではバージョン基準を確定していません。 | Core: 10.5.29。Server のプロファイル: 10.11.19。 | Core の観測は公開ソースに紐づきます。調査した公開一覧には Server 3.0.5 のインデックスに紐づく MariaDB エンドポイントの記録はありません。 | -| SQLite | 組み込みの機能・テストには SQLite が含まれます。Server は基準 3.35 を宣言しています。 | 元の Core ソースジョブは SQLite ライブラリのバージョンを出力していません。 | インストール済み Core 2.20.3 の検証は SQLite を使いましたが、ライブラリのバージョン範囲は定めません。凍結された Server 3.1.0 候補のコーパスは安定版 3.0.5 と別です。 | +| MySQL | 組み込み: 基準 8.0。Server: 基準 8.0。 | Core: 元の可変イメージタグの機能ジョブでは 26.10.0。Server のプロファイル: 8.0.46 と 8.4.5。 | Core の観測は公開ソースに紐づきます。Server 3.3.2 のリリーススモークと正確なインデックスに対する Compose スモークは、起動・ヘルス確認にダイジェスト固定の MySQL 8.0 を使います。実行・容量・TLS 全体の検証ではありません。 | +| PostgreSQL | 組み込み: 基準 13。Server: 基準 13。 | Core: 18.6。Server のプロファイル: 16.15 と 17.11。 | Core の観測は公開ソースに紐づきます。Server 3.3.2 のリリーススモークは、各アーキテクチャのイメージをダイジェスト固定の PostgreSQL 17 上でコールドスタートし、準備状態とクラスター情報だけを確認します。実行・容量・TLS 全体の検証ではありません。 | +| MariaDB | 組み込み: 基準 10.5。Server は `mariadb` を受け付けますが、ここではバージョン基準を確定していません。 | Core: 10.5.29。Server のプロファイル: 10.11.19。 | Core の観測は公開ソースに紐づきます。調査したリリース証拠には Server 3.3.2 のインデックスに紐づく MariaDB エンドポイントの記録はありません。 | +| SQLite | 組み込みの機能・テストには SQLite が含まれます。Server は基準 3.35 を宣言しています。 | 元の Core ソースジョブは SQLite ライブラリのバージョンを出力していません。 | インストール済み Core 2.20.3 の検証は SQLite を使いましたが、ライブラリのバージョン範囲は定めません。Server 3.3.2 のリリーススモークは SQLite 上でコールドスタートしますが、こちらもライブラリのバージョン範囲は定めません。 | | SQL Server | 公開済み組み込み Core は `sqlsrv` を宣言していますが未検証です。Server の検証もここでは確定していません。 | 公開済み Core のマトリックスに SQL Server ジョブは見つかりません。提案中のバックエンドガードは別のソース作業です。 | 対応する公開検証は確認されていません。組み込み機能の宣言だけからサポートを推測しないでください。 | ## 証拠の読み方 {#reading-the-evidence} [Core の一覧](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325)は、公開ソースにおける元のイメージダイジェストと MySQL 4 ジョブ、PostgreSQL 4 ジョブ、MariaDB 1 ジョブを紐づけます。公開アップグレードの 12 セルは Laravel/PHP の組み合わせであり、12 種のデータベースではありません。別の[通常インストール済み Core の記録](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927)は、SQLite による stream・replay・fake の 67 ケースを対象とします。PHP バージョンや可変イメージタグから、出力されなかったデータベースバージョンは得られません。 -[Server の一覧](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277)はネイティブと旧 PHP のソースジョブの範囲を分けています。[安定版 3.0.5 の記録](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603)にはアーキテクチャ・プロファイル別の Compose スモークが 4 セルあります。`local` と `production` はどちらも MySQL です。調査したログでは、付属 DB の正確なバージョン・ダイジェスト、書き込み容量の検証、TLS 検証は確認できません。ソースのプロファイルや凍結候補は、別の公開イメージを検証しません。 +[Server の一覧](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277)はネイティブと旧 PHP のソースジョブの範囲を分けています。Server 3.3.2 では、[リリース実行](https://github.com/durable-workflow/server/actions/runs/42591612884)が amd64 と arm64 のイメージを SQLite、PostgreSQL 17、MySQL 8.0 上でコールドスタートし、`/api/ready` と認証付きのクラスター情報を確認して、それぞれを SIGTERM で停止します。[正確なインデックスに対する Compose スモーク](https://github.com/durable-workflow/server/actions/runs/42602031026)には、インデックス `sha256:4aeceb42…` を対象とするアーキテクチャ・プロファイル別の 4 セルがあります。`local` と `production` はどちらも MySQL を使い、`mysql:8.0` はダイジェストで固定されています。[3.3.2 の配信記録](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227)は両方を受理しています。これらの実行は空のデータベースで開始します。既存のデータベースのアップグレード、書き込み容量の検証、TLS の検証は行わず、ログは正確なエンジンのパッチバージョンを出力しません。以前の[安定版 3.0.5 の記録](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603)は、可変タグの `mysql:8.0` で同じ構成の Compose スモークを行っていました。ソースのプロファイルは、別の公開イメージを検証しません。 ## ベンダーのライフサイクルと分散エンジン {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md index 5232fcb9ef8..1e9e62f6ed3 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -367,15 +367,28 @@ curl http://localhost:8080/api/cluster/info \ -H "Authorization: Bearer $TOKEN" ``` -ビルド識別、能力フラグ、プロトコルのマニフェスト、制限値、そして `X-Namespace`（または `namespace` クエリパラメーター、どちらもなければ `default`）で指定した Namespace の検出情報を返します。3.0.5 イメージの出力を抜粋します。 +ビルド識別、能力フラグ、プロトコルのマニフェスト、制限値、そして `X-Namespace`（または `namespace` クエリパラメーター、どちらもなければ `default`）で指定した Namespace の検出情報を返します。3.3.2 イメージの出力を抜粋します。 ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -383,6 +396,8 @@ curl http://localhost:8080/api/cluster/info \ "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -420,10 +435,11 @@ curl http://localhost:8080/api/cluster/info \ クライアントコード向けの主なフィールドの注意点： - ビルドバージョンは `server_version` ではなく `version` です。ネイティブ Server では `implementation` が `"rust"` です。 -- API を呼び出す前に `control_plane.version` と `worker_protocol.version` を確認してください。ネイティブ 3.0.5 はコントロールプレーン `2` と Worker プロトコル `1.20` を提供し、`1.0` から `1.20` までの任意のプロトコルバージョンを送る Worker 要求を受け付けます。 +- API を呼び出す前に `control_plane.version` と `worker_protocol.version` を確認してください。ネイティブ 3.3.2 はコントロールプレーン `2` と Worker プロトコル `1.20` を提供し、`1.0` から `1.20` までの任意のプロトコルバージョンを送る Worker 要求を受け付けます。 - ワークフロータスクのコマンドは `worker_protocol.server_capabilities.supported_workflow_task_commands` にあります。 - `false` の能力フラグは、ネイティブが提供しない機能や公開契約を示します。ネイティブは圧縮しない応答を送るため、`response_compression` は空です。 -- `native_unqualified` は、PHP 2.x の応答のうちネイティブが含めない各メンバーを理由とともに列挙します。`topology`、`supported_sdk_versions`、`client_compatibility` が含まれます。 +- `native_unqualified` は、PHP 2.x の応答のうちネイティブが含めない各メンバーを理由とともに列挙します。`topology` が含まれます。 +- 3.1.0 以降、ネイティブは `supported_sdk_versions` と `client_compatibility` も提供し、CLI の `server:info` と `doctor` がこれらを読み取ります。`client_compatibility.authority` は `"protocol_manifests"` です。API を呼び出す前に、SDK の範囲ではなくプロトコルのマニフェストを確認してください。 - ペイロードコーデックは Avro だけです。`capabilities.payload_codecs` は正確に `["avro"]` です。 - `qualified_for_php_takeover` は常に `false` です。これは起動時にデータベースをテイクオーバーすることのない、実行中の Server を表すもので、`upgrade-takeover` がお使いのデータベースを受け入れるかどうかを示すものではありません。 - 応答には `auth_composition_contract`、`principal_attribution_contract`、`service_catalog_read_contract`、`message_streams_contract` のマニフェストも含まれます。 diff --git a/i18n/ja/source-hashes.json b/i18n/ja/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/ja/source-hashes.json +++ b/i18n/ja/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md index e9bb2e7ee61..241cffe1389 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md @@ -275,6 +275,68 @@ todos os Servers parados. A referência do Server mantém os exemplos mais recentes de comandos Compose na seção [Imagem oficial + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose). +### Atualizar do Server 3.0.x para o 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +O Server 3.3.2 atravessa três versões minor a partir da 3.0.x e muda o schema +nativo. No MySQL, MariaDB e PostgreSQL, ele passa da versão 8 (3.0.x e 3.1.0) +pela 10 (3.2.0) até a 11 (3.3.0 a 3.3.2). No SQLite, passa da 8 para a 10. Um +Server nunca atualiza seu schema na inicialização: o 3.3.2 iniciado em um +banco de dados na versão 8 se recusa a iniciar com +`native_schema_upgrade_required`, portanto alterar apenas `DW_SERVER_IMAGE` +deixa o novo Server incapaz de iniciar. O comando `schema-upgrade` da imagem +3.3.2 atualiza diretamente um banco de dados na versão 8. As +[notas de atualização da 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) +descrevem a etapa, e as +[notas Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) +do chart Helm listam as etapas de schema e as mudanças de runtime da 3.0.5 +para a 3.3.2. + +Para a implantação Compose em nó único: + +1. Pare o Server e deixe o MySQL em execução: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. Faça backup do MySQL e do `server_storage` e registre a referência da + imagem atual. Esse backup é o único caminho de volta para a 3.0.x. +3. Altere `DW_SERVER_IMAGE` para a imagem 3.3.2, baixe-a e execute + `schema-upgrade` uma vez: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + O comando imprime o backend e as versões do schema antes e depois, por + exemplo `"from_schema_version":8,"schema_version":11,"status":"upgraded"`. + Em um banco de dados que já está na versão atual, ele apenas verifica o + schema. +4. Inicie o Server com + `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`, + depois confirme `/api/ready`, `/api/cluster/info` (`version` é `3.3.2`) e o + registro de workers. + +- **PostgreSQL:** as etapas das versões 10 e 11 criam seus índices com um + `CREATE INDEX` simples, que bloqueia escritas em `workflow_tasks` até o fim + da criação. Em uma tabela `workflow_tasks` grande, planeje a + indisponibilidade necessária. +- **MySQL e MariaDB:** nesses bancos, o DDL faz commit por conta própria, por + isso a atualização marca o banco de dados como em atualização até terminar, + e enquanto isso todo Server o recusa com `native_schema_upgrade_incomplete`. + Se uma atualização for interrompida, execute `schema-upgrade` novamente para + retomá-la. +- **A reversão exige o backup.** Não existe downgrade de schema. Um Server + 3.0.x recusa um banco de dados atualizado com + `native_schema_newer_than_binary`. Para voltar, restaure o backup feito na + etapa 2, o que descarta tudo o que foi escrito depois dele, e então inicie a + imagem 3.0.x. + +O protocolo dos workers permanece em `1.20` e o plano de controle na versão `2`. + ## Implantações em cluster pequeno {#small-clustered-deployments} :::note Contrato do PHP Server 2.x @@ -537,6 +599,8 @@ O chart 1.x executa o Server nativo por padrão (`runtime: native`): um único D Uma release PHP 2.x existente não passa para o modo nativo em uma atualização comum: o chart recusa a atualização até que você defina `runtime` explicitamente. Defina `runtime: php` para manter o worker, o agendador, o job de bootstrap e o Redis do PHP 2.x. Para passar para `runtime: native`, siga o [runbook de migração para o Server nativo](%%artifact.serverTakeoverRunbookUrl%%) e mantenha `runtime: php` até que a migração esteja concluída. Consulte as [notas UPGRADING](%%artifact.helmChartUpgradeUrl%%) do chart. +O chart 1.1.0 muda a imagem padrão do Server 3.0.5 para o 3.3.2, que exige a [atualização do schema nativo](#native-schema-upgrade-3-0-to-3-3) da versão 8 para a 11. Um `helm upgrade` comum a partir do chart 1.0.x altera apenas a imagem, e os novos pods se recusam a iniciar com `native_schema_upgrade_required`. Siga as [etapas Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) do chart: reduza o Server a zero réplicas com o escalonamento automático desativado, faça backup do banco de dados e então atualize para o chart 1.1.0 com `native.schemaUpgrade.enabled=true`. O hook `pre-upgrade` do chart executa `schema-upgrade` uma vez antes de os novos pods iniciarem, e somente quando o `lookup` do Helm mostra todos os Servers parados. Renderizações do Argo CD, do Flux e do `helm template` recusam o hook; nesses casos, use o Job manual do README do chart. Um `helm rollback` para uma revisão do chart 1.0.x não traz o Server de volta, porque a 3.0.x recusa o banco de dados atualizado: em vez disso, restaure o backup. + ### Escolher uma versão do chart {#helm-chart-selection} Cada versão do chart registra em `appVersion` do `Chart.yaml` a imagem do Server com que foi testada; chart e Server têm números de versão independentes. A [combinação compatível selecionada](./compatibility.md#last-qualified-reproducible-tuple) associa o chart **%%artifact.helmChartVersion%%** ao Server **%%artifact.helmChartAppVersion%%**, usando os mesmos metadados da tabela e do comando de instalação. A [verificação OCI/do pacote publicado](%%artifact.helmChartQualificationUrl%%) comprova esse par, não uma nova instalação Kubernetes. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/database-support.md index 4d727243bb4..13e93840bcd 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: Compatibilidade de bancos de dados Use esta tabela para escolher o banco do Laravel embutido e do Server autogerenciado. Cloud gerencia a persistência do runtime. Clientes Cloud configuram clientes SDK e workers, não um banco do runtime. -Uma base de compatibilidade declarada não prova que toda versão posterior foi qualificada. Testes de código e artefatos publicados instalados são evidências diferentes. Este retrato vincula o código Workflow 2.20.3 e os recibos Server 3.0.5. Não muda a compatibilidade nem estabelece uma faixa mínima/máxima testada. +Uma base de compatibilidade declarada não prova que toda versão posterior foi qualificada. Testes de código e artefatos publicados instalados são evidências diferentes. Este retrato vincula o código Workflow 2.20.3 e os recibos de release Server 3.3.2. Não muda a compatibilidade nem estabelece uma faixa mínima/máxima testada. | Motor | Compatibilidade declarada | Qualificação de código observada | Qualificação do artefato publicado | | --- | --- | --- | --- | -| MySQL | Embutido: base 8.0. Server: base 8.0. | Core: 26.10.0 nos jobs originais com imagem flutuante. Perfis Server: 8.0.46 e 8.4.5. | A observação Core vincula o código publicado. Compose do Server 3.0.5 usa `mysql:8.0` para smoke de esquema/saúde, não qualificação completa de execução/capacidade/TLS. | -| PostgreSQL | Embutido: base 13. Server: base 13. | Core: 18.6. Perfis Server: 16.15 e 17.11. | A observação Core vincula o código publicado. Não foi encontrado recibo de endpoint PostgreSQL vinculado ao índice Server 3.0.5 no inventário inspecionado. | -| MariaDB | Embutido: base 10.5. Server aceita `mariadb`; nenhuma versão base é estabelecida aqui. | Core: 10.5.29. Perfil Server: 10.11.19. | A observação Core vincula o código publicado. Não foi encontrado recibo de endpoint MariaDB vinculado ao índice Server 3.0.5 no inventário inspecionado. | -| SQLite | Capacidades/testes embutidos incluem SQLite. Server declara base 3.35. | Os jobs originais de código Core não emitiram a versão da biblioteca SQLite. | A aceitação do Core 2.20.3 instalado exercitou SQLite sem estabelecer faixa de versões. O corpus do candidato Server 3.1.0 congelado é separado do estável 3.0.5. | +| MySQL | Embutido: base 8.0. Server: base 8.0. | Core: 26.10.0 nos jobs originais com imagem flutuante. Perfis Server: 8.0.46 e 8.4.5. | A observação Core vincula o código publicado. O smoke de release e o smoke Compose de índice exato do Server 3.3.2 usam MySQL 8.0 fixado por digest para verificações de inicialização/saúde, não qualificação completa de execução/capacidade/TLS. | +| PostgreSQL | Embutido: base 13. Server: base 13. | Core: 18.6. Perfis Server: 16.15 e 17.11. | A observação Core vincula o código publicado. O smoke de release do Server 3.3.2 inicia a frio a imagem de cada arquitetura sobre PostgreSQL 17 fixado por digest apenas para prontidão e informações do cluster, não qualificação completa de execução/capacidade/TLS. | +| MariaDB | Embutido: base 10.5. Server aceita `mariadb`; nenhuma versão base é estabelecida aqui. | Core: 10.5.29. Perfil Server: 10.11.19. | A observação Core vincula o código publicado. Não foi encontrado recibo de endpoint MariaDB vinculado ao índice Server 3.3.2 na evidência de release inspecionada. | +| SQLite | Capacidades/testes embutidos incluem SQLite. Server declara base 3.35. | Os jobs originais de código Core não emitiram a versão da biblioteca SQLite. | A aceitação do Core 2.20.3 instalado exercitou SQLite sem estabelecer faixa de versões. O smoke de release do Server 3.3.2 inicia a frio sobre SQLite, também sem faixa de versões da biblioteca. | | SQL Server | Core embutido publicado anuncia `sqlsrv`, mas continua sem qualificação. A qualificação Server não é estabelecida aqui. | Nenhum job SQL Server recuperado na matriz Core publicada. O guard proposto do backend é trabalho de código separado. | Nenhuma qualificação publicada correspondente recuperada. Não deduza suporte pelo anúncio da capacidade embutida. | ## Como interpretar a evidência {#reading-the-evidence} O [inventário Core](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325) vincula digests originais e quatro jobs MySQL, quatro PostgreSQL e um MariaDB no código publicado. As doze células de upgrade publicado cobrem combinações Laravel/PHP, não doze endpoints de banco. O [recibo do Core instalado normalmente](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927) cobre separadamente 67 casos stream/replay/fake com SQLite. Nem versão PHP nem seletor flutuante fornecem uma versão de banco não emitida. -O [inventário Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) separa os escopos dos jobs de código nativo e PHP anterior. O [recibo estável 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) tem quatro células smoke Compose de arquitetura/perfil. `local` e `production` usam MySQL. Os logs inspecionados não recuperam versão/digest exatos do banco acompanhante, qualificação de escrita ou TLS verificado. Perfis de código e candidato congelado não qualificam outra imagem publicada. +O [inventário Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) separa os escopos dos jobs de código nativo e PHP anterior. Para o Server 3.3.2, a [execução da release](https://github.com/durable-workflow/server/actions/runs/42591612884) inicia a frio as imagens amd64 e arm64 sobre SQLite, PostgreSQL 17 e MySQL 8.0, verifica `/api/ready` e as informações autenticadas do cluster e encerra cada uma com SIGTERM. O [smoke Compose de índice exato](https://github.com/durable-workflow/server/actions/runs/42602031026) tem quatro células de arquitetura/perfil contra o índice `sha256:4aeceb42…`. `local` e `production` usam MySQL, com `mysql:8.0` fixado por digest. O [registro de entrega da 3.3.2](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227) aceita ambos. Essas execuções iniciam bancos vazios. Não atualizam um banco existente, não qualificam capacidade de escrita nem verificam TLS, e seus logs não informam a versão patch exata do motor. O [recibo estável 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) anterior tinha o mesmo formato Compose com um `mysql:8.0` flutuante. Perfis de código não qualificam outra imagem publicada. ## Ciclo do fornecedor e motores distribuídos {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md index 06ceef7f1dc..769f2bfb3c1 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -377,15 +377,28 @@ curl http://localhost:8080/api/cluster/info \ -H "Authorization: Bearer $TOKEN" ``` -Retorna a identidade da compilação, os indicadores de capacidade, os manifestos de protocolo, os limites e a descoberta do namespace indicado por `X-Namespace` (ou pelo parâmetro de consulta `namespace`; na ausência de ambos, `default`). Saída resumida da imagem 3.0.5: +Retorna a identidade da compilação, os indicadores de capacidade, os manifestos de protocolo, os limites e a descoberta do namespace indicado por `X-Namespace` (ou pelo parâmetro de consulta `namespace`; na ausência de ambos, `default`). Saída resumida da imagem 3.3.2: ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -393,6 +406,8 @@ Retorna a identidade da compilação, os indicadores de capacidade, os manifesto "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -430,10 +445,11 @@ Retorna a identidade da compilação, os indicadores de capacidade, os manifesto Notas sobre os principais campos para o código cliente: - A versão de compilação está em `version`, não em `server_version`. `implementation` é `"rust"` no Server nativo. -- Verifique `control_plane.version` e `worker_protocol.version` antes de chamar a API. O nativo 3.0.5 serve o plano de controle `2` e o protocolo dos workers `1.20`, e aceita requisições de workers que enviem qualquer versão de protocolo de `1.0` a `1.20`. +- Verifique `control_plane.version` e `worker_protocol.version` antes de chamar a API. O nativo 3.3.2 serve o plano de controle `2` e o protocolo dos workers `1.20`, e aceita requisições de workers que enviem qualquer versão de protocolo de `1.0` a `1.20`. - Os comandos de tarefas de workflow ficam em `worker_protocol.server_capabilities.supported_workflow_task_commands`. - Um indicador de capacidade definido como `false` identifica um recurso ou contrato publicado que o Server nativo não oferece. `response_compression` está vazio porque o Server nativo envia respostas sem compressão. -- `native_unqualified` lista cada membro da resposta do PHP 2.x que o Server nativo omite, com o motivo. Inclui `topology`, `supported_sdk_versions` e `client_compatibility`. +- `native_unqualified` lista cada membro da resposta do PHP 2.x que o Server nativo omite, com o motivo. Inclui `topology`. +- Desde a 3.1.0, o Server nativo também oferece `supported_sdk_versions` e `client_compatibility`, que os comandos `server:info` e `doctor` da CLI leem. `client_compatibility.authority` é `"protocol_manifests"`: verifique os manifestos de protocolo, não as faixas de SDK, antes de chamar a API. - O único codec de payloads é Avro: `capabilities.payload_codecs` é exatamente `["avro"]`. - `qualified_for_php_takeover` é sempre `false`. Ele descreve o Server em execução, que nunca assume um banco de dados na inicialização, e não se o `upgrade-takeover` aceitará o seu. - A resposta também traz os manifestos `auth_composition_contract`, `principal_attribution_contract`, `service_catalog_read_contract` e `message_streams_contract`. diff --git a/i18n/pt-BR/source-hashes.json b/i18n/pt-BR/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/pt-BR/source-hashes.json +++ b/i18n/pt-BR/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md b/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md index 2aa2f310f5d..c4ce90de150 100644 --- a/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md @@ -269,6 +269,62 @@ docker compose --env-file durable-workflow.prod.env \ розділі [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose). +### Оновлення з Server 3.0.x до 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +Server 3.3.2 відділяють від 3.0.x три мінорні випуски, і він змінює нативну +схему. На MySQL, MariaDB і PostgreSQL вона переходить з версії 8 (3.0.x і +3.1.0) через 10 (3.2.0) до 11 (від 3.3.0 до 3.3.2). На SQLite вона переходить +з 8 до 10. Server ніколи не оновлює свою схему під час запуску: 3.3.2, +запущений на базі версії 8, відмовляє з `native_schema_upgrade_required`, тому +сама лише зміна `DW_SERVER_IMAGE` залишає новий Server нездатним запуститися. +Команда `schema-upgrade` образу 3.3.2 оновлює базу версії 8 безпосередньо. +[Нотатки оновлення 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) +описують цей крок, а +[нотатки Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) +чарта Helm перелічують кроки схеми та зміни runtime від 3.0.5 до 3.3.2. + +Для одновузлового розгортання Compose: + +1. Зупиніть Server, залишивши MySQL запущеним: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. Створіть резервні копії MySQL і `server_storage` та запишіть поточне + посилання на образ. Ця резервна копія — єдиний шлях назад до 3.0.x. +3. Змініть `DW_SERVER_IMAGE` на образ 3.3.2, завантажте його й один раз + виконайте `schema-upgrade`: + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + Команда виводить бекенд і версії схеми до й після, наприклад + `"from_schema_version":8,"schema_version":11,"status":"upgraded"`. + На базі, яка вже актуальна, вона лише перевіряє схему. +4. Запустіть Server командою + `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`, + потім перевірте `/api/ready`, `/api/cluster/info` (`version` дорівнює + `3.3.2`) та реєстрацію worker. + +- **PostgreSQL:** кроки версій 10 і 11 будують свої індекси звичайним + `CREATE INDEX`, який блокує записи в `workflow_tasks`, доки побудова не + завершиться. Для великої таблиці `workflow_tasks` заплануйте на це простій. +- **MySQL і MariaDB:** там DDL фіксується окремо, тому оновлення позначає базу + як таку, що оновлюється, доки воно не завершиться, і кожен Server тим часом + відмовляє їй з `native_schema_upgrade_incomplete`. Якщо оновлення перервано, + знову виконайте `schema-upgrade`, щоб продовжити його. +- **Відкат потребує резервної копії.** Пониження версії схеми не існує. Server + 3.0.x відмовляє оновленій базі з `native_schema_newer_than_binary`. Щоб + повернутися, відновіть резервну копію, створену на кроці 2, що відкидає все + записане після неї, а потім запустіть образ 3.0.x. + +Протокол worker залишається `1.20`, а площина керування — версією `2`. + ## Невеликі кластерні розгортання {#small-clustered-deployments} :::note Контракт PHP Server 2.x @@ -523,6 +579,8 @@ helm install durable-workflow \ Наявний випуск PHP 2.x не переходить на нативний Server під час звичайного оновлення: чарт відмовляє, доки ви явно не задасте `runtime`. Задайте `runtime: php`, щоб зберегти worker, планувальник, Job початкового налаштування та Redis PHP 2.x. Щоб перейти на `runtime: native`, дотримуйтеся [runbook переходу на нативний Server](%%artifact.serverTakeoverRunbookUrl%%) і зберігайте `runtime: php`, доки перехід не завершиться. Дивіться [нотатки UPGRADING](%%artifact.helmChartUpgradeUrl%%) чарта. +Чарт 1.1.0 змінює типовий образ із Server 3.0.5 на 3.3.2, якому потрібне [нативне оновлення схеми](#native-schema-upgrade-3-0-to-3-3) з 8 до 11. Звичайний `helm upgrade` із чарта 1.0.x змінює лише образ, і нові Pod відмовляються запускатися з `native_schema_upgrade_required`. Дотримуйтеся [кроків Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) чарта: масштабуйте Server до нуля з вимкненим автомасштабуванням, створіть резервну копію бази, а потім оновіться до чарта 1.1.0 з `native.schemaUpgrade.enabled=true`. Його hook `pre-upgrade` один раз виконує `schema-upgrade` перед запуском нових Pod і лише тоді, коли `lookup` Helm показує, що всі Server зупинені. Рендеринг через Argo CD, Flux і `helm template` відхиляє цей hook; натомість використовуйте ручний Job із README чарта. `helm rollback` до ревізії чарта 1.0.x не повертає Server, бо 3.0.x відмовляє оновленій базі: натомість відновіть резервну копію. + ### Вибір випуску чарту {#helm-chart-selection} Кожен випуск чарту записує образ Server, з яким його перевіряли, у `appVersion` файлу `Chart.yaml`; номери версій чарту й Server незалежні. Вибрана [сумісна комбінація](./compatibility.md#last-qualified-reproducible-tuple) поєднує чарт **%%artifact.helmChartVersion%%** із Server **%%artifact.helmChartAppVersion%%**, використовуючи ті самі метадані випусків, що й таблиця та команда встановлення. [Підтвердження опублікованих OCI/package](%%artifact.helmChartQualificationUrl%%) перевіряє цю пару, а не нове встановлення Kubernetes. diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/database-support.md index 1bf0fa0c83f..78734ce0c3d 100644 --- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: Сумісність баз даних Використовуйте цю таблицю для вибору бази вбудованого Laravel і самостійно розгорнутого Server. Cloud керує власним сховищем runtime. Клієнти Cloud налаштовують клієнти SDK та worker, а не базу runtime. -Заявлена база сумісності не доводить кваліфікацію кожної новішої версії. Тести коду й установлені опубліковані артефакти є різними доказами. Цей зріз прив’язаний до коду Workflow 2.20.3 і квитанцій Server 3.0.5. Він не змінює сумісність і не встановлює перевіреного мінімального/максимального діапазону. +Заявлена база сумісності не доводить кваліфікацію кожної новішої версії. Тести коду й установлені опубліковані артефакти є різними доказами. Цей зріз прив’язаний до коду Workflow 2.20.3 і квитанцій випуску Server 3.3.2. Він не змінює сумісність і не встановлює перевіреного мінімального/максимального діапазону. | Рушій | Заявлена сумісність | Спостережена кваліфікація коду | Кваліфікація опублікованого артефакту | | --- | --- | --- | --- | -| MySQL | Вбудований: база 8.0. Server: база 8.0. | Core: 26.10.0 у початкових feature jobs із плаваючим образом. Профілі Server: 8.0.46 і 8.4.5. | Спостереження Core прив’язане до випущеного коду. Compose Server 3.0.5 використовує `mysql:8.0` для schema/health smoke, а не повної перевірки виконання/ємності/TLS. | -| PostgreSQL | Вбудований: база 13. Server: база 13. | Core: 18.6. Профілі Server: 16.15 і 17.11. | Спостереження Core прив’язане до випущеного коду. У перевіреному переліку немає квитанції PostgreSQL endpoint, прив’язаної до індексу Server 3.0.5. | -| MariaDB | Вбудований: база 10.5. Server приймає `mariadb`; версійну базу тут не встановлено. | Core: 10.5.29. Профіль Server: 10.11.19. | Спостереження Core прив’язане до випущеного коду. У перевіреному переліку немає квитанції MariaDB endpoint, прив’язаної до індексу Server 3.0.5. | -| SQLite | Вбудовані можливості/тести включають SQLite. Server заявляє базу 3.35. | Початкові jobs коду Core не вивели версію бібліотеки SQLite. | Перевірка встановленого Core 2.20.3 використовувала SQLite, не встановлюючи діапазону версій. Корпус замороженого кандидата Server 3.1.0 відокремлений від стабільного 3.0.5. | +| MySQL | Вбудований: база 8.0. Server: база 8.0. | Core: 26.10.0 у початкових feature jobs із плаваючим образом. Профілі Server: 8.0.46 і 8.4.5. | Спостереження Core прив’язане до випущеного коду. Release smoke Server 3.3.2 і Compose smoke точного індексу використовують закріплений за digest MySQL 8.0 для перевірок запуску/health, а не повної перевірки виконання/ємності/TLS. | +| PostgreSQL | Вбудований: база 13. Server: база 13. | Core: 18.6. Профілі Server: 16.15 і 17.11. | Спостереження Core прив’язане до випущеного коду. Release smoke Server 3.3.2 виконує холодний запуск образу кожної архітектури на закріпленому за digest PostgreSQL 17 лише для перевірки готовності й інформації про кластер, а не повної перевірки виконання/ємності/TLS. | +| MariaDB | Вбудований: база 10.5. Server приймає `mariadb`; версійну базу тут не встановлено. | Core: 10.5.29. Профіль Server: 10.11.19. | Спостереження Core прив’язане до випущеного коду. У перевірених доказах випуску немає квитанції MariaDB endpoint, прив’язаної до індексу Server 3.3.2. | +| SQLite | Вбудовані можливості/тести включають SQLite. Server заявляє базу 3.35. | Початкові jobs коду Core не вивели версію бібліотеки SQLite. | Перевірка встановленого Core 2.20.3 використовувала SQLite, не встановлюючи діапазону версій. Release smoke Server 3.3.2 виконує холодний запуск на SQLite, так само без діапазону версій бібліотеки. | | SQL Server | Опублікований вбудований Core заявляє `sqlsrv`, але лишається некваліфікованим. Кваліфікацію Server тут не встановлено. | SQL Server job у випущеній матриці Core не знайдено. Запропонований backend guard є окремою роботою з кодом. | Відповідну кваліфікацію випуску не знайдено. Не виводьте підтримку лише із заяви про вбудовану можливість. | ## Як читати докази {#reading-the-evidence} [Інвентар Core](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325) прив’язує початкові digests образів і чотири MySQL, чотири PostgreSQL та один MariaDB feature job до випущеного коду. Його дванадцять клітинок оновлення пакета охоплюють Laravel/PHP, а не дванадцять endpoint баз даних. Окрема [квитанція звичайно встановленого Core](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927) охоплює 67 stream/replay/fake випадків із SQLite. Ані версія PHP, ані плаваючий селектор образу не надає невиведеної версії бази. -[Інвентар Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) розділяє обсяг jobs нативного коду й попереднього PHP. [Квитанція стабільного 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) має чотири Compose smoke клітинки архітектури/профілю. `local` і `production` використовують MySQL. Перевірені журнали не відновлюють точну версію/digest супутньої бази, перевірку записувальної ємності чи підтверджений TLS. Профілі коду й заморожений кандидат не кваліфікують іншого опублікованого образу. +[Інвентар Server](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277) розділяє обсяг jobs нативного коду й попереднього PHP. Для Server 3.3.2 [запуск випуску](https://github.com/durable-workflow/server/actions/runs/42591612884) виконує холодний запуск образів amd64 і arm64 на SQLite, PostgreSQL 17 і MySQL 8.0, перевіряє `/api/ready` та автентифіковану інформацію про кластер і зупиняє кожен через SIGTERM. [Compose smoke точного індексу](https://github.com/durable-workflow/server/actions/runs/42602031026) має чотири клітинки архітектури/профілю для індексу `sha256:4aeceb42…`. І `local`, і `production` використовують MySQL, а `mysql:8.0` закріплено за digest. [Запис постачання 3.3.2](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227) приймає обидва. Ці запуски стартують із порожніми базами. Вони не оновлюють наявну базу, не кваліфікують записувальну ємність і не підтверджують TLS, а їхні журнали не повідомляють точної patch-версії рушія. Попередня [квитанція стабільного 3.0.5](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603) мала таку саму форму Compose з плаваючим `mysql:8.0`. Профілі коду не кваліфікують іншого опублікованого образу. ## Життєвий цикл постачальника та розподілені рушії {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md index 0b8958d70dc..0c04a454211 100644 --- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -506,15 +506,28 @@ curl http://localhost:8080/api/cluster/info \ Повертає ідентичність збірки, прапорці можливостей, маніфести протоколів, ліміти та дані виявлення для namespace, названого в `X-Namespace` (або в -параметрі запиту `namespace`, інакше `default`). Скорочений вивід образу 3.0.5: +параметрі запиту `namespace`, інакше `default`). Скорочений вивід образу 3.3.2: ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -522,6 +535,8 @@ curl http://localhost:8080/api/cluster/info \ "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -561,7 +576,7 @@ curl http://localhost:8080/api/cluster/info \ - Версія збірки міститься в `version`, а не в `server_version`. На нативному Server `implementation` має значення `"rust"`. - Перевіряйте `control_plane.version` і `worker_protocol.version` перед - викликами API. Нативний 3.0.5 обслуговує площину керування `2` і протокол + викликами API. Нативний 3.3.2 обслуговує площину керування `2` і протокол worker `1.20`, а також приймає запити worker із будь-якою версією протоколу від `1.0` до `1.20`. - Команди workflow-task містяться в @@ -570,8 +585,11 @@ curl http://localhost:8080/api/cluster/info \ контракт, який нативний Server не обслуговує. `response_compression` порожній, бо нативний Server надсилає нестиснені відповіді. - `native_unqualified` перелічує кожен член відповіді PHP 2.x, який нативний - Server пропускає, разом із причиною. Серед них `topology`, - `supported_sdk_versions` і `client_compatibility`. + Server пропускає, разом із причиною. Серед них `topology`. +- Починаючи з 3.1.0, нативний Server також обслуговує `supported_sdk_versions` + і `client_compatibility`, які читають `server:info` і `doctor` CLI. + `client_compatibility.authority` має значення `"protocol_manifests"`: + перед викликами API перевіряйте маніфести протоколів, а не діапазони SDK. - Єдиний кодек payload — Avro: `capabilities.payload_codecs` дорівнює точно `["avro"]`. - `qualified_for_php_takeover` завжди дорівнює `false`. Поле описує запущений diff --git a/i18n/uk/source-hashes.json b/i18n/uk/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/uk/source-hashes.json +++ b/i18n/uk/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md index 896a7b14840..ec25337093c 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md @@ -169,6 +169,37 @@ docker compose --env-file durable-workflow.prod.env \ 原生 Server 在启动时检查其数据库模式。同一原生次版本线内的补丁发布保持模式不变，因此只需更换镜像。发布说明中宣布模式变更的版本还需要运行镜像的 `schema-upgrade` 命令，须在备份数据库后、所有 Server 都已停止时执行。Server 参考文档的[官方镜像 + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose)部分维护最新命令级 Compose 示例。 +### 从 Server 3.0.x 升级到 3.3.2 {#native-schema-upgrade-3-0-to-3-3} + +从 3.0.x 到 Server 3.3.2 跨越三个次版本，并会变更原生数据库模式。在 MySQL、MariaDB 和 PostgreSQL 上，模式版本从 8（3.0.x 和 3.1.0）经 10（3.2.0）升至 11（3.3.0 至 3.3.2）。在 SQLite 上，模式版本从 8 升至 10。Server 从不在启动时升级其数据库模式：在版本 8 的数据库上启动 3.3.2 会以 `native_schema_upgrade_required` 拒绝启动，因此仅修改 `DW_SERVER_IMAGE` 会使新 Server 无法启动。3.3.2 镜像的 `schema-upgrade` 命令可将版本 8 的数据库直接升级。[3.3.0 升级说明](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade)描述了这一步骤，Helm chart 的 [Chart 1.1.0 / Server 3.3.2 说明](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)列出了各模式升级步骤以及从 3.0.5 到 3.3.2 的运行时变更。 + +对于单节点 Compose 部署： + +1. 停止 Server，保持 MySQL 运行： + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml stop server + ``` +2. 备份 MySQL 和 `server_storage`，并记录当前镜像引用。此备份是回到 3.0.x 的唯一途径。 +3. 将 `DW_SERVER_IMAGE` 改为 3.3.2 镜像，拉取该镜像，并运行一次 `schema-upgrade`： + + ```bash + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml pull server + docker compose --env-file durable-workflow.prod.env \ + -f docker-compose.published.yml run --rm --no-deps server schema-upgrade + ``` + + 该命令会输出后端以及升级前后的模式版本，例如 `"from_schema_version":8,"schema_version":11,"status":"upgraded"`。在模式已是最新的数据库上，它只校验模式。 +4. 使用 `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` 启动 Server，然后确认 `/api/ready`、`/api/cluster/info`（`version` 为 `3.3.2`）和 Worker 注册。 + +- **PostgreSQL：** 版本 10 和 11 的步骤使用普通 `CREATE INDEX` 构建索引，在构建完成前会阻塞对 `workflow_tasks` 的写入。如果 `workflow_tasks` 表很大，请为此规划停机时间。 +- **MySQL 和 MariaDB：** 在这些数据库上 DDL 会自行提交，因此升级会在完成前将数据库标记为升级中，在此期间每个 Server 都会以 `native_schema_upgrade_incomplete` 拒绝该数据库。如果升级中断，请再次运行 `schema-upgrade` 以继续完成。 +- **回滚需要备份。** 不存在模式降级。3.0.x Server 会以 `native_schema_newer_than_binary` 拒绝已升级的数据库。要回退，请恢复第 2 步中的备份（这会丢弃备份之后写入的所有内容），然后启动 3.0.x 镜像。 + +Worker 协议保持为 `1.20`，控制平面保持为版本 `2`。 + ## 小型集群部署 {#small-clustered-deployments} :::note PHP Server 2.x 契约 @@ -329,6 +360,8 @@ Chart 1.x 默认运行原生 Server（`runtime: native`）：一个 Server Deplo 现有 PHP 2.x 发布不会在普通升级中迁移到原生 Server：在你显式设置 `runtime` 之前，Chart 会拒绝升级。设置 `runtime: php` 可保留 PHP 2.x 的 Worker、调度器、bootstrap 任务和 Redis。要迁移到 `runtime: native`，请按照[原生接管运行手册](%%artifact.serverTakeoverRunbookUrl%%)操作，并在接管完成之前保持 `runtime: php`。参见 Chart 的 [UPGRADING 说明](%%artifact.helmChartUpgradeUrl%%)。 +Chart 1.1.0 将默认镜像从 Server 3.0.5 改为 3.3.2，后者需要执行从 8 到 11 的[原生数据库模式升级](#native-schema-upgrade-3-0-to-3-3)。从 Chart 1.0.x 执行普通 `helm upgrade` 只会更换镜像，新 Pod 会以 `native_schema_upgrade_required` 拒绝启动。请按照 Chart 的 [Chart 1.1.0 / Server 3.3.2 步骤](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)操作：在关闭自动扩缩的情况下将 Server 缩容至零，备份数据库，然后使用 `native.schemaUpgrade.enabled=true` 升级到 Chart 1.1.0。其 `pre-upgrade` 钩子会在新 Pod 启动前运行一次 `schema-upgrade`，且仅在 Helm 的 `lookup` 显示所有 Server 均已停止时运行。Argo CD、Flux 和 `helm template` 渲染会拒绝该钩子；请改用 Chart README 中的手动 Job。`helm rollback` 回到 Chart 1.0.x 修订版本无法让 Server 恢复运行，因为 3.0.x 会拒绝已升级的数据库：请改为恢复备份。 + ### 选择 Chart 版本 {#helm-chart-selection} 每个 Chart 发布版都会在 `Chart.yaml` 的 `appVersion` 中记录其测试过的 Server 镜像；Chart 与 Server 的版本号彼此独立。所选[兼容组合](./compatibility.md#last-qualified-reproducible-tuple)使用 Chart **%%artifact.helmChartVersion%%** 和 Server **%%artifact.helmChartAppVersion%%**，与表格和安装命令共享同一份发布元数据。[已发布 OCI/软件包的验证记录](%%artifact.helmChartQualificationUrl%%)核实的是这个组合，并非一次新的 Kubernetes 安装。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/database-support.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/database-support.md index 11f7424f26c..1af22025b13 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/database-support.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/database-support.md @@ -6,21 +6,21 @@ title: 数据库兼容性 此表用于选择嵌入式 Laravel 与自托管 Server 的数据库。Cloud 管理其运行时持久化。Cloud 客户配置 SDK 客户端与 Worker，而不是运行时数据库。 -声明的兼容性基线不证明所有更高版本都通过验证。源码测试与安装已发布产物的验证是不同证据。此快照绑定 Workflow 2.20.3 源码与 Server 3.0.5 发布记录，不改变运行时兼容性，也不建立已测试的最低/最新版本范围。 +声明的兼容性基线不证明所有更高版本都通过验证。源码测试与安装已发布产物的验证是不同证据。此快照绑定 Workflow 2.20.3 源码与 Server 3.3.2 发布记录，不改变运行时兼容性，也不建立已测试的最低/最新版本范围。 | 引擎 | 声明的兼容性 | 观测到的源码验证 | 已发布产物验证 | | --- | --- | --- | --- | -| MySQL | 嵌入式：基线 8.0。Server：基线 8.0。 | Core：原始浮动镜像功能任务中为 26.10.0。Server 配置：8.0.46、8.4.5。 | Core 观测绑定发布源码。Server 3.0.5 Compose 的 `mysql:8.0` 仅用于模式/健康冒烟，不是完整执行、容量或 TLS 验证。 | -| PostgreSQL | 嵌入式：基线 13。Server：基线 13。 | Core：18.6。Server 配置：16.15、17.11。 | Core 观测绑定发布源码。在检查的发布清单中未找到绑定 Server 3.0.5 索引的 PostgreSQL 端点记录。 | -| MariaDB | 嵌入式：基线 10.5。Server 接受 `mariadb`，此处未确立版本基线。 | Core：10.5.29。Server 配置：10.11.19。 | Core 观测绑定发布源码。在检查的发布清单中未找到绑定 Server 3.0.5 索引的 MariaDB 端点记录。 | -| SQLite | 嵌入式能力和测试包含 SQLite。Server 声明基线 3.35。 | 原始 Core 源码任务没有输出 SQLite 库版本。 | 安装的 Core 2.20.3 验证使用了 SQLite，但未建立库版本范围。冻结的 Server 3.1.0 候选语料与稳定版 3.0.5 独立。 | +| MySQL | 嵌入式：基线 8.0。Server：基线 8.0。 | Core：原始浮动镜像功能任务中为 26.10.0。Server 配置：8.0.46、8.4.5。 | Core 观测绑定发布源码。Server 3.3.2 的发布冒烟和确切索引 Compose 冒烟使用按摘要固定的 MySQL 8.0 进行启动/健康检查，不是完整执行、容量或 TLS 验证。 | +| PostgreSQL | 嵌入式：基线 13。Server：基线 13。 | Core：18.6。Server 配置：16.15、17.11。 | Core 观测绑定发布源码。Server 3.3.2 的发布冒烟在按摘要固定的 PostgreSQL 17 上冷启动每种架构的镜像，仅检查就绪状态和集群信息，不是完整执行、容量或 TLS 验证。 | +| MariaDB | 嵌入式：基线 10.5。Server 接受 `mariadb`，此处未确立版本基线。 | Core：10.5.29。Server 配置：10.11.19。 | Core 观测绑定发布源码。在检查的发布证据中未找到绑定 Server 3.3.2 索引的 MariaDB 端点记录。 | +| SQLite | 嵌入式能力和测试包含 SQLite。Server 声明基线 3.35。 | 原始 Core 源码任务没有输出 SQLite 库版本。 | 安装的 Core 2.20.3 验证使用了 SQLite，但未建立库版本范围。Server 3.3.2 的发布冒烟在 SQLite 上冷启动，同样未建立库版本范围。 | | SQL Server | 已发布嵌入式 Core 声明 `sqlsrv`，但仍未验证。此处未确立 Server 验证。 | 已发布 Core 矩阵中未找到 SQL Server 任务。拟议的后端守卫是独立源码工作。 | 未找到对应发布验证。不要由嵌入式能力声明推断支持已获验证。 | ## 如何理解证据 {#reading-the-evidence} [Core 清单](https://github.com/durable-workflow/durable-workflow.github.io/issues/347#issuecomment-6642279325)将原始镜像摘要及四个 MySQL、四个 PostgreSQL 和一个 MariaDB 功能任务绑定到发布源码。十二个已发布升级单元覆盖 Laravel/PHP 组合，不是十二种数据库端点。独立的[正常安装 Core 记录](https://github.com/durable-workflow/workflow/pull/1025#issuecomment-6632522927)覆盖基于 SQLite 的 67 个 stream/replay/fake 用例。PHP 版本或浮动镜像选择器都不能补出未记录的数据库版本。 -[Server 清单](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277)区分原生与旧 PHP 源码任务范围。[稳定版 3.0.5 记录](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603)有四个架构/配置 Compose 冒烟单元。`local` 和 `production` 都使用 MySQL。检查的日志未恢复出配套数据库确切版本/摘要、写入容量验证或已验证 TLS。源码配置和冻结候选不能验证另一个已发布镜像。 +[Server 清单](https://github.com/durable-workflow/server/issues/563#issuecomment-6642659277)区分原生与旧 PHP 源码任务范围。对于 Server 3.3.2，[发布运行](https://github.com/durable-workflow/server/actions/runs/42591612884)在 SQLite、PostgreSQL 17 和 MySQL 8.0 上冷启动 amd64 和 arm64 镜像，检查 `/api/ready` 和经身份验证的集群信息，并使用 SIGTERM 停止每个实例。[确切索引 Compose 冒烟](https://github.com/durable-workflow/server/actions/runs/42602031026)针对索引 `sha256:4aeceb42…` 有四个架构/配置单元。`local` 和 `production` 都使用 MySQL，其中 `mysql:8.0` 按摘要固定。[3.3.2 交付记录](https://github.com/durable-workflow/server/issues/325#issuecomment-6739628227)接受了这两项运行。这些运行从空数据库启动，不升级已有数据库，不验证写入容量，也不验证 TLS，其日志也未报告确切的引擎补丁版本。更早的[稳定版 3.0.5 记录](https://github.com/durable-workflow/server/issues/563#issuecomment-6643169603)采用相同的 Compose 结构，但使用浮动的 `mysql:8.0`。源码配置不能验证另一个已发布镜像。 ## 厂商生命周期与分布式引擎 {#vendor-lifecycle-and-distributed-engines} diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md index e82335f844e..1047b0af7ed 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md @@ -366,15 +366,28 @@ curl http://localhost:8080/api/cluster/info \ -H "Authorization: Bearer $TOKEN" ``` -返回构建标识、能力标志、协议清单、限制，以及由 `X-Namespace`（或 `namespace` 查询参数，否则为 `default`）指定的命名空间的发现信息。以下为 3.0.5 镜像的节选输出： +返回构建标识、能力标志、协议清单、限制，以及由 `X-Namespace`（或 `namespace` 查询参数，否则为 `default`）指定的命名空间的发现信息。以下为 3.3.2 镜像的节选输出： ```json { - "version": "3.0.5", + "version": "3.3.2", "implementation": "rust", "development": false, "server_id": "2145ce2abb12", "default_namespace": "default", + "supported_sdk_versions": { + "php": ">=3.8.1,<4.0.0", + "python": ">=2.13.0,<3.0.0", + "rust": ">=4.10.3,<5.0.0", + "cli": ">=2.0.0,<3.0.0" + }, + "client_compatibility": { + "schema": "durable-workflow.v2.client-compatibility", + "version": 2, + "authority": "protocol_manifests", + "fail_closed": true, + "...": "..." + }, "capabilities": { "workflow_tasks": true, "activity_tasks": true, @@ -382,6 +395,8 @@ curl http://localhost:8080/api/cluster/info \ "queries": true, "updates": true, "schedules": true, + "child_workflow_start_turn": true, + "condition_wait_occurrence_deadline": true, "timer_runtime_contract": false, "payload_codecs": ["avro"], "response_compression": [] @@ -419,10 +434,11 @@ curl http://localhost:8080/api/cluster/info \ 面向客户端代码的关键字段说明： - 构建版本是 `version`，而不是 `server_version`。在原生 Server 上，`implementation` 为 `"rust"`。 -- 调用 API 之前，请检查 `control_plane.version` 和 `worker_protocol.version`。原生 3.0.5 提供控制平面 `2` 与 Worker 协议 `1.20`，并接受发送 `1.0` 至 `1.20` 之间任一协议版本的 Worker 请求。 +- 调用 API 之前，请检查 `control_plane.version` 和 `worker_protocol.version`。原生 3.3.2 提供控制平面 `2` 与 Worker 协议 `1.20`，并接受发送 `1.0` 至 `1.20` 之间任一协议版本的 Worker 请求。 - 工作流任务命令位于 `worker_protocol.server_capabilities.supported_workflow_task_commands`。 - 值为 `false` 的能力标志表示原生 Server 不提供的功能或已发布契约。`response_compression` 为空，因为原生 Server 发送未压缩的响应。 -- `native_unqualified` 列出原生 Server 省略的每个 PHP 2.x 响应成员及其原因，其中包括 `topology`、`supported_sdk_versions` 和 `client_compatibility`。 +- `native_unqualified` 列出原生 Server 省略的每个 PHP 2.x 响应成员及其原因，其中包括 `topology`。 +- 自 3.1.0 起，原生 Server 也提供 `supported_sdk_versions` 和 `client_compatibility`，CLI 的 `server:info` 和 `doctor` 会读取它们。`client_compatibility.authority` 为 `"protocol_manifests"`：调用 API 之前，请检查协议清单，而不是 SDK 版本范围。 - 唯一的载荷编解码器是 Avro：`capabilities.payload_codecs` 恰好为 `["avro"]`。 - `qualified_for_php_takeover` 始终为 `false`。它描述的是正在运行的 Server（启动时从不接管数据库），而不是表示 `upgrade-takeover` 是否会接受某个数据库。 - 响应还携带 `auth_composition_contract`、`principal_attribution_contract`、`service_catalog_read_contract` 和 `message_streams_contract` 清单。 diff --git a/i18n/zh-Hans/source-hashes.json b/i18n/zh-Hans/source-hashes.json index 6a91f5c9e5e..dbfeff3a615 100644 --- a/i18n/zh-Hans/source-hashes.json +++ b/i18n/zh-Hans/source-hashes.json @@ -28,7 +28,7 @@ "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf", "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529", "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c", - "deployment.md": "503230f8cc2378726d32557cc17bc4c44f527082c382c39a6b24ab1913476877", + "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7", "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c", "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082", "features/cancel-and-terminate.md": "c678fc7a0c9b11f0e1bee295aff259de9803219c0aa6769fb801622799e7deb1", @@ -73,7 +73,7 @@ "polyglot/cli-reference.md": "dc637af2ab17abc3f7e0233aeaacccc61dd1bbe7c94330e550a531ed1d8e48f8", "polyglot/cli.mdx": "5c4b80e371705aaf37cb39eb9bc6375ca2496522dbeb161046707324190cef13", "polyglot/cloud-control-plane.md": "bb375e598dd1afa3207171047fb81b0cb82c382ce535ab415cb09dc10f6d748e", - "polyglot/database-support.md": "9bf310e5ec31439555d5236b5efc2fc4400e80b5b387ff57cbad817b288a52ad", + "polyglot/database-support.md": "518f679ae723ae4d39db7cac78008bc8edb84a6cfba2e6c668d8f2be5d378d03", "polyglot/deployment-modes.md": "7b508db4be86c92de76cfd8dfd946d93941c8a6f0a601a161d4d3fd1711bf97f", "polyglot/embedded-to-server.md": "21a7e4c9439a73db3a97fd9b0610749faabf7c449806fe0ad55a0924f50d3b80", "polyglot/external-execution.md": "410728db1107c328d0cb129cbf0c58f4fa8c6427e0406610d6801dfeb8a2db31", @@ -91,7 +91,7 @@ "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5", "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc", "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2", - "polyglot/server.md": "d59d3443c7c28d56a3866613ae355b3b54aed91dc2bda4a4aa161a16065c6d2a", + "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043", "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27", "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d", "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327", diff --git a/static/stable-releases.json b/static/stable-releases.json index 4c38d4db7b9..b07032208c8 100644 --- a/static/stable-releases.json +++ b/static/stable-releases.json @@ -4,20 +4,20 @@ "updated_at": "2026-11-09", "artifacts": { "cli": "2.3.6", - "helm-chart": "1.0.3", + "helm-chart": "1.1.0", "sdk-php": "3.11.0", "sdk-python": "2.14.1", "sdk-rust": "4.12.0", - "server": "3.0.5", + "server": "3.3.2", "waterline": "2.14.0", "workflow": "2.22.0" }, "helm_chart": { - "app_version": "3.0.5", + "app_version": "3.3.2", "repository": "oci://ghcr.io/durable-workflow/charts/durable-workflow", - "oci_manifest_digest": "sha256:7f029b5963985ff33b899ae0e2a08f7f32d8fc5fb7a14cbf33484c832ed0a103", - "package_digest": "sha256:b46c8186f2e2fd42bbb6fe20794167315d55a1c17c93208a11518930028d5d4d", - "source_commit": "a3256a4a3e07c54ccd5f76ba658a585560730959", - "qualification_url": "https://github.com/durable-workflow/server/pull/1000#issuecomment-6618128273" + "oci_manifest_digest": "sha256:fd670cad2d12453f5d9923bacaec2ab6fba02ff7fe82570eee8f01f66bf73e89", + "package_digest": "sha256:a72dc4fda8a1c8913d19ad6611558e938a74c6dc109dd973a8bfcbce799c2e5d", + "source_commit": "0eea994a7f4796ceaec536604c7bd48af11124e2", + "qualification_url": "https://github.com/durable-workflow/server/pull/1117#issuecomment-6744052774" } } diff --git a/tests/kubernetes-workers/artifacts.json b/tests/kubernetes-workers/artifacts.json index f5365ac8f9d..3dce7328832 100644 --- a/tests/kubernetes-workers/artifacts.json +++ b/tests/kubernetes-workers/artifacts.json @@ -1,6 +1,6 @@ { - "server": "durableworkflow/server@sha256:3cb6e5bf8ec766ac2abd933369b40a77af62794b6d7b921ce21d3fb263e88b72", - "server_version": "3.0.5", + "server": "durableworkflow/server@sha256:4aeceb423ee4c8931f00ec2936149ac6b2a75479243b3930f9c6336ccdebf912", + "server_version": "3.3.2", "php_sdk": "3.4.1", "php_source": "cb1d11e57767e20e1fdb8081024f67057ff66714", "python_sdk": "2.9.0",