Upgrade einer App mit Containern

Unter diesem Thema wird beschrieben, wie Sie eine Snowflake Native App with Snowpark Container Services aktualisieren.

Allgemeine Informationen zum Upgraden einer App mit Containern

Der Prozess des Upgradens einer App mit Containern besteht aus zwei Phasen:

  • Upgrade der Dienste in den von der App verwalteten Containern.

    Wie andere Snowpark Container Services verwenden auch Container-Apps den Befehl ALTER SERVICE, um einen Dienst auf der Grundlage einer Dienstspezifikationsdatei für die neue Version zu ändern. Dieser Befehl wird asynchron ausgeführt.

  • Aktualisieren der anderen Objekte in der App.

    Nachdem die Dienste erfolgreich aktualisiert wurden, werden auch andere Objekte innerhalb der App aktualisiert. Dies ist ähnlich wie der normale Upgrade-Prozess einer Snowflake Native App. Weitere Informationen dazu finden Sie unter Allgemeine Informationen zu Upgrades.

Die Herausforderung beim Upgrade einer App mit Containern besteht darin, dass der Befehl ALTER SERVICE asynchron ausgeführt wird. Wenn ein Anbieter diesen Befehl direkt zum Setup-Skript hinzufügt, wird das Setup-Skript weiter ausgeführt, während das Dienst-Upgrade läuft. Anbieter müssen den Code für das Dienst-Upgrade so schreiben, dass die Dienste korrekt aktualisiert werden, bevor das Upgrade für andere Objekte in der App fortgesetzt wird.

Um Dienst-Upgrades korrekt zu handhaben, bietet Snowflake Native App Framework Features, die der App Folgendes ermöglichen:

  • Anhalten der Ausführung des Setup-Skripts bis das Upgrade der Dienste erfolgreich war oder fehlgeschlagen ist. Anbieter müssen sicherstellen, dass das Setup-Skript mit Situationen, die möglicherweise auftretenden könnten, verarbeiten kann. Weitere Informationen dazu finden Sie unter Ausführung des Setup-Skripts anhalten.

  • Verwenden einer Callback-Funktion, um zuvor aktualisierte Dienste auf eine frühere Version zurückzusetzen, wenn das Upgrade fehlschlägt. Weitere Informationen dazu finden Sie unter Dienst-Upgrades koordinieren.

Ausführung des Setup-Skripts anhalten

Damit die Dienste korrekt aktualisiert werden können, können Anbieter das Setup-Skript mit der Systemfunktion SYSTEM$WAIT_FOR_SERVICES innerhalb des Setup-Skripts anhalten. Die folgenden Beispiele zeigen die Verwendung dieser Systemfunktion:

SELECT SYSTEM$WAIT_FOR_SERVICES(600, 'services.web_ui', 'services.worker, 'services.aggregation');
Copy

Dieser Befehl veranlasst das Setup-Skript so lange zu pausieren, bis einer der folgenden Fälle eintritt:

  • Alle benannten Dienste, die an die Systemfunktion übergeben werden, haben den Status READY.

  • Einer der genannten Dienste hat den Status FAILED.

  • 600 Sekunden sind vergangen.

Dienst-Upgrades koordinieren

Das Snowflake Native App Framework bietet eine Callback-Funktion, die es Anbietern ermöglicht, die Aktualisierung von Diensten mit dem Rest des Upgrade-Vorgangs zu synchronisieren.

Mögliche Konflikte beim Upgraden von Diensten

Während des Upgrades einer Kern- Snowflake Native App wird das Setup-Skript auf die neue Version der App aktualisiert, indem Objekte innerhalb eines versionierten Schemas geändert werden. Wenn während des Upgrades ein Fehler auftritt, werden die Objekte im versionierten Schema auf die vorherige Version der App zurückgesetzt.

Im Falle einer App mit Containern werden die Dienste geändert, indem der Befehl ALTER SERVICE im Setup-Skript auf der Grundlage einer für die neue Version geltenden Dienstspezifikationsdatei ausgeführt wird. Da Dienste nicht innerhalb von versionierten Schemas erstellt werden, wird ein Dienst aktualisiert, sobald ALTER SERVICE erfolgreich ausgeführt wird. Wenn später im Setup-Skript ein Fehler auftritt, werden beispielsweise die Objekte in versionierten Schemas auf die vorherige Version zurückgesetzt, aber die geänderten Dienste sind die der neuen Version.

Callback-Funktion des Versionsinitialisierers verwenden, um Dienst-Upgrades zu verwalten

Das Snowflake Native App Framework bietet einen Versionsinitialisierer, der zum Starten oder Aktualisieren von Diensten oder anderen verwandten Prozessen, z. B. Aufgaben, verwendet wird. Der Versionsinitialisierer ist eine gespeicherte Callback-Prozedur, die in der Manifest-Datei angegeben wird.

Die Callback-Funktion des Versionsinitialisierers wird in den folgenden Kontexten aufgerufen:

  • Während der Installation wird der Versionsinitialisierer aufgerufen, sobald das Setup-Skript der App ohne Fehler abgeschlossen wurde.

  • Beim Upgrade des Versionsinitialisierers gibt es zwei mögliche Szenarios:

    • Wenn das Setup-Skript der neuen Version erfolgreich ist, wird die neue Version des Versionsinitialisierers aufgerufen.

    • Wenn das Setup-Skript oder der Versionsinitialisierer der neuen Version fehlschlägt, wird der Versionsinitialisierer der vorherigen Version aufgerufen. Dies ermöglicht es dem Versionsinitialisierer der vorherigen Version, den ALTER SERVICE-Befehl zu verwenden, um die Dienste auf die vorherige Version zurückzusetzen.

Versionsinitialisierer angeben

Um die gespeicherte Prozedur anzugeben, die als Versionsinitialisierer verwendet wird, fügen Sie Folgendes zur Datei manifest.yml hinzu:

lifecycle_callbacks:
  version_initializer: callbacks.version_init
Copy

In diesem Beispiel wird die Eigenschaft version_initializer auf eine gespeicherte Prozedur namens version_init in einem Schema namens callbacks gesetzt.

Innerhalb des Setup-Skripts kann ein Anbieter diese Prozedur innerhalb eines versionierten Schemas definieren, wie im folgenden Beispiel gezeigt:

CREATE OR ALTER VERSIONED SCHEMA callbacks;

CREATE OR REPLACE PROCEDURE callbacks.version_init()
  ...
  -- body of the version_init() procedure
  ...
Copy

Best Practices beim Upgraden von Apps mit Containern

  • Seien Sie vorsichtig, wenn Sie den Timeout-Wert für die Systemfunktion SYSTEM$WAIT_FOR_SERVICES() festlegen.

  • Snowflake empfiehlt, die als Versionsinitialisierer verwendete gespeicherte Prozedur in einem versionierten Schema zu erstellen. Wenn diese gespeicherte Prozedur nicht innerhalb eines Versionsschemas erstellt wird, existiert der Versionsinitialisierer möglicherweise nicht.

  • Wenn eine Anwendung einen Versionsinitialisierer angibt, dann darf die App nicht versuchen, Dienste innerhalb des Setup-Skripts zu starten oder zu aktualisieren.

  • Für den Versionsinitialisierer muss keine Anwendungsrolle zugewiesen werden.

Sprache: Deutsch