Mettre à niveau une application avec des conteneurs¶

Cette rubrique décrit comment mettre à niveau un Snowflake Native App with Snowpark Container Services.

À propos de la mise à niveau d’une application avec des conteneurs¶

Le processus de mise à niveau d’une appli avec des conteneurs se déroule en deux grandes zones de préparation :

Mettez à niveau les services dans les conteneurs gérés par l’application.

Comme les autres Snowpark Continer Services, les applications de conteneur utilisent la commande ALTER SERVICE pour modifier un service sur la base d’un fichier de spécification de service pour la nouvelle version. Cette commande s’exécute de manière asynchrone.
Mettez à niveau d’autres objets dans l’application.

Une fois les services mis à niveau avec succès, les autres objets de l’application sont mis à niveau. Cette procédure est similaire à la procédure normale de mise à niveau de Snowflake Native App. Pour plus d’informations, voir À propos des mises à niveau.

La difficulté lors de la mise à niveau d’une application avec des conteneurs est que la commande ALTER SERVICE s’exécute de manière asynchrone. Si un fournisseur ajoute cette commande directement au script d’installation, ce dernier continue de s’exécuter pendant la mise à niveau du service. Les fournisseurs doivent écrire le code pour la mise à niveau des services afin que ceux-ci soient mis à niveau correctement avant de poursuivre la mise à niveau des autres objets de l’application.

Pour gérer correctement les mises à niveau de service, le Snowflake Native App Framework propose des fonctions qui permettent à l’appli d’effectuer les opérations suivantes :

Interrompre l’exécution du script d’installation jusqu’à ce que la mise à niveau des services réussisse ou échoue. Les fournisseurs doivent s’assurer que le script d’installation peut gérer les situations possibles. Pour plus d’informations, voir Interrompre l’exécution du script d’installation.
Utiliser une fonction de rappel pour ramener les services précédemment mis à niveau à une version antérieure en cas d’échec de la mise à niveau. Pour plus d’informations, voir Coordonner l’amélioration des services.

Interrompre l’exécution du script d’installation¶

Pour permettre aux services de se mettre à niveau correctement, les fournisseurs peuvent mettre en pause le script d’installation à l’aide de la fonction système SYSTEM$WAIT_FOR_SERVICES dans le script d’installation. L’exemple suivant montre comment utiliser cette fonction système :

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

Copy

Cette commande met le script d’installation en pause jusqu’à ce que l’un des événements suivants se produise :

Tous les services nommés transmis à la fonction système ont le statut READY.
N’importe lequel des services nommés a le statut FAILED.
600 secondes se sont écoulées.

Coordonner l’amélioration des services¶

Le Snowflake Native App Framework fournit une fonction de rappel qui permet aux fournisseurs de synchroniser la mise à niveau des services avec le reste de la procédure de mise à niveau.

Conflits possibles lors de la mise à niveau des services¶

Lors de la mise à niveau d’une Snowflake Native App principale, le script d’installation passe à la nouvelle version de l’application en modifiant les objets au sein d’un schéma versionné. Si une erreur survient lors de la mise à niveau, les objets du schéma versionné reviennent à la version précédente de l’application.

Dans le cas d’une application avec conteneurs, les services sont modifiés en exécutant la commande ALTER SERVICE dans le script d’installation sur la base d’un fichier de spécification de service applicable à la nouvelle version. Comme les services ne sont pas créés dans des schémas versionnés, un service est mis à niveau dès que ALTER SERVICE s’exécute avec succès. En cas d’échec plus tard dans le script d’installation, par exemple, les objets des schémas versionnés sont ramenés à la version précédente, mais les services modifiés sont ceux de la nouvelle version.

Utiliser une fonction de rappel de l’initialisateur de version pour gérer les mises à niveau des services¶

Le Snowflake Native App Framework fournit un initialisateur de version utilisé pour démarrer ou mettre à niveau des services ou d’autres processus connexes, par exemple des tâches. L’initialisateur de version est une procédure stockée de rappel qui est spécifiée dans le fichier manifeste.

La fonction de rappel de l’initialisateur de version est appelée dans les contextes suivants :

Lors de l’installation, l’initialisateur de version est appelé dès que le script d’installation de l’application se termine sans erreur.
Lors de la mise à niveau, l’initialisateur de version peut être utilisé dans deux cas de figure :
- Si le script d’installation de la nouvelle version réussit, la nouvelle version de l’initialisateur de version est appelée.
- Si le script d’installation ou l’initialisateur de version de la nouvelle version échoue, l’initialisateur de version de la version précédente est appelé. Cela permet à l’initialisateur de la version précédente d’utiliser ALTER SERVICE pour ramener les services à la version précédente.

Spécifier l’initialisateur de la version¶

Pour spécifier la procédure stockée utilisée comme initialisateur de version, ajoutez ce qui suit au fichier manifest.yml :

lifecycle_callbacks:
  version_initializer: callbacks.version_init

Copy

Dans cet exemple, la propriété version_initializer est définie sur une procédure stockée nommée version_init dans un schéma nommé callbacks.

Dans le script d’installation, un fournisseur peut définir cette procédure dans un schéma versionné, comme le montre l’exemple suivant :

CREATE OR ALTER VERSIONED SCHEMA callbacks;

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

Copy

Meilleures pratiques lors de la mise à niveau d’applications avec des conteneurs¶

Faites attention lorsque vous définissez la valeur du délai d’attente pour la fonction système SYSTEM$WAIT_FOR_SERVICES().
Snowflake recommande de créer la procédure stockée utilisée comme initialisateur de version dans un schéma versionné. Si cette procédure stockée n’est pas créée dans un schéma de version, il se peut que l’initialisateur de version n’existe pas.
Si une application spécifie un initialisateur de version, elle ne doit pas essayer de démarrer ou de mettre à niveau des services dans le script d’installation.
L’initialisateur de version ne nécessite pas l’attribution d’un rôle d’application.