チュートリアル3: コンテナーでアプリをアップグレードする¶
概要¶
Snowflake Native App Framework は、プロバイダーはSnowflake Data Cloud内でアプリを構築、販売、配布することができます。プロバイダーは、Snowflakeのコア機能を活用してコンシューマーとデータやアプリケーションロジックを共有するアプリケーションを作成できます。アプリはSnowpark Container Servicesを実装して、Snowflakeエコシステム内でのコンテナー化されたアプリのデプロイ、管理、スケーリングを容易にすることもできます。
Snowflake Native App Framework では、プロバイダーはアプリのアップデートを行い、新しいバージョンやパッチをコンシューマーに公開することができます。このチュートリアルでは、以下のタスクの実行方法について説明します。
アプリにバージョンイニシャライザーを追加します。
アプリに加えられた変更のバージョンとパッチを作成します。
コンシューマーアカウントでアプリをアップグレードします。
前提条件のチュートリアル¶
このチュートリアルでは、基本的な Snowflake Native App の開発方法を知っており、 Snowflake Native App with Snowpark Container Services を作成できることを前提としています。このチュートリアルは、以下のチュートリアルを修了して得た知識を基に構成されています。
このチュートリアルに従ってコンテナーを使ってアプリをアップグレードする前に、これらのチュートリアルの両方を完了していることを確認してください。
注意
このチュートリアルは、 チュートリアル2: コンテナーでアプリを作成する で作成したアプリを基に構成されています。アプリケーションファイルとSnowflakeオブジェクトがアカウントにない場合は、このチュートリアルを始める前に、もう一度そのチュートリアルを行う必要があります。詳細については、 前のチュートリアルのアプリがアカウントに存在することを確認します。 をご参照ください。
このチュートリアルで学べること¶
このチュートリアルでは、 チュートリアル2: コンテナーでアプリを作成する で作成したコンテナーを使ってアプリを拡張します。このチュートリアルでは、次の方法を学びます。
バージョン初期化コールバック関数を使用して、サービスのアップグレードや障害を処理します。
アプリのバージョン定義を作成します。
アプリのアップグレード
アプリのアップグレード失敗をシミュレートします。
アプリのパッチを作成して障害を修正します。
前のチュートリアルのアプリがアカウントに存在することを確認します。¶
チュートリアル2: コンテナーでアプリを作成する で作成したコンテナー付きアプリがアカウントでまだ可用性であることを確認するには、以下のタスクを実行します。
注意
以下のタスクのいずれかが正常に完了しない場合は、 チュートリアル2: コンテナーでアプリを作成する を再度実行する必要があります。
Snow CLI が正しく構成されていることを確認するには、以下のコマンドを実行します。
snow connection test -c tut-connection
このコマンドの出力は以下のようになるはずです。
+----------------------------------------------------------------------------------+ | key | value | |-----------------+----------------------------------------------------------------| | Connection name | tut-connection | | Status | OK | | Host | USER_ACCOUNT.snowflakecomputing.com | | Account | USER_ACCOUNT | | User | tutorial_user | | Role | TUTORIAL_ROLE | | Database | TUTORIAL_IMAGE_DATABASE | | Warehouse | TUTORIAL_WAREHOUSE | +----------------------------------------------------------------------------------+
このコマンドは、以下の要件を確認します。
Snow CLI 接続はうまくいっています。
TUTORIAL_ROLE は存在します。
TUTORIAL_WAREHOUSE は存在します。
その他の必要なSnowflakeオブジェクトが存在することを確認するには、ワークシートから以下のコマンドを実行します。
USE ROLE tutorial_role;
SHOW DATABASES LIKE 'tutorial_image_database';
SHOW SCHEMAS LIKE 'tutorial_image_schema';
SHOW IMAGE REPOSITORIES LIKE 'tutorial_image_repo';
これらのコマンドはそれぞれSnowflakeオブジェクトの名前を返すはずです。
サービスがまだ実行されていることを確認するには、ワークシートから以下のコマンドを実行してください。
CALL na_spcs_tutorial_app.app_public.service_status();
ローカルのディレクトリ構造が以下の例のようになっていることを確認してください:
├── app └── manifest.yml └── README.md └── setup_script.sql ├── README.md ├── service └── echo_service.py ├── echo_spec.yaml ├── Dockerfile └── templates └── basic_ui.html ├── snowflake.yml
また、
snow app run
コマンドによって生成されたアプリファイルを含むoutput
というフォルダが表示されるかもしれません。
アプリケーションオブジェクトの削除¶
チュートリアル2: コンテナーでアプリを作成する で作成したアプリケーションがまだアカウントに存在する場合、このチュートリアルを進める前にアプリケーションオブジェクトを削除する必要があります。
注釈
ステージングされたファイルから直接開発モードで作成されたアプリはアップグレードできないため、既存のアプリを削除する必要があります。
前のチュートリアルのアプリ(
na_spcs_tutorial_app
)がアカウントに存在するかどうかを調べるには、ワークシートから以下のコマンドを実行します。SHOW APPLICATIONS LIKE 'na_spcs_tutorial_app';
このコマンドの出力に
na_spcs_tutorial_app
アプリが表示される場合は、ワークシートから以下のコマンドを実行してアプリを削除してください。USE ROLE tutorial_role; DROP APPLICATION IF EXISTS na_spcs_tutorial_app CASCADE;
このセクションで記入した内容¶
このセクションでは、前回のチュートリアルで使用したアプリケーションファイルとSnowflakeオブジェクトがアカウント内で正常に動作していることを確認しました。
次のセクションでは、 Snowflake Native App Framework のバージョンとアップグレードについて詳しく説明します。
バージョン、パッチ、アップグレードの理解¶
このセクションでは、このチュートリアルで扱う以下のような概念を紹介します。
バージョンとパッチ
アップグレード
バージョンイニシャライザ
バージョンおよびパッチについて¶
Snowflake Native App Framework のバージョンは、バージョン番号とパッチ番号の組み合わせです。これらはアプリケーションパッケージで定義されています。
. rst-class:: 箇条書き定義リスト
- バージョン
一般的には Snowflake Native App の主な更新が含まれます。バージョンはアプリケーションパッケージで定義されます。
- パッチ
一般的には Snowflake Native App に対するより小さな更新が含まれます。バージョンと同様、パッチもアプリケーションパッケージで定義されます。
注釈
アプリケーションパッケージは、一度に2つのアクティブバージョンを持つことができます。アプリの1つのバージョンには、最大130のパッチがあります。
アップグレードについて¶
Snowflake Native App Framework の文脈では、アップグレードとは、コンシューマーアカウントにインストールされている Snowflake Native App のバージョンまたはパッチに対する更新を指します。 Snowflake Native App Framework は2つのタイプのアップグレードに対応しています。
- 自動アップグレード
自動アップグレードは、プロバイダーによって開始されるアップグレードです。新しいバージョンやパッチが利用可能になると、プロバイダーはアプリケーションパッケージのリリースディレクティブを変更します。これは、リリースディレクティブで指定されたアプリのすべてのインストール済みインスタンスの自動アップグレードをトリガーします。
- 手動アップグレード
手動アップグレードとは、プロバイダーからの通知に応じてコンシューマーが開始するアップグレードのことです。手動アップグレードは、プロバイダーがコンシューマーにバグ修正などのアップデートを迅速にリリースする必要がある場合に便利です。
注釈
このチュートリアルでは、コンテナーを使用したアプリの手動アップグレードの方法について説明します。
新しいバージョンやパッチが可用性になると、プロバイダーはアプリケーションパッケージのリリースディレクティブを変更し、新しいバージョンが利用可能になったことをコンシューマーに通知します。
コンシューマーは、自分のアカウントで ALTER APPLICATION コマンドを実行してアップグレードを実行します。一般的に、手動アップグレードにより、コンシューマーは自動アップグレードよりも早くインストール済みアプリをアップグレードできます。
バージョンイニシャライザーについて¶
バージョンイニシャライザーは、サービスやその他の関連プロセスを起動したり、アップグレードしたりするために使用されます。バージョン イニシャライザは、マニフェスト ファイルで定義され、セットアップ スクリプトで実装されるコールバック ストアドプロシージャです。バージョン初期化子コールバック関数は、次のコンテキストで呼び出されます。
インストール中、アプリのセットアップスクリプトがエラーなしで終了するとすぐに、バージョン初期化子が呼び出されます。
アップグレードの際、バージョン・イニシャライザーが呼び出されるシナリオは2つ考えられます:
新しいバージョンのセットアップスクリプトが成功すると、バージョン初期化子の新しいバージョンが呼び出されます。
新しいバージョンのセットアップスクリプトまたはバージョン初期化子が失敗した場合は、以前のバージョンのバージョン初期化子が呼び出されます。これにより、以前のバージョンのイニシャライザーは、 ALTER SERVICE コマンドを使用してサービスを以前のバージョンに戻すことができます。
アプリにバージョンイニシャライザーを追加¶
前回のチュートリアルでは、コンテナーを使って基本的なアプリを作成しました。このセクションでは、このアプリを更新し、アプリにバージョンイニシャライザーを追加します。また、アプリケーションパッケージにバージョンを追加します。
マニフェストファイルにバージョンイニシャライザーを追加します。¶
バージョンイニシャライザは、アプリのマニフェストファイルで定義されます。バージョン・イニシャライザーを定義するには、 manifest.yml
ファイルの最後に以下のコードを追加します。
lifecycle_callbacks:
version_initializer: app_public.version_init
これは、バージョンのイニシャライザとして使用されるストアドプロシージャのスキーマと名前を指定します。次のセクションでは、 version_init
ストアドプロシージャを実装します。
セットアップスクリプトにストアドプロシージャとしてバージョンイニシャライザを追加します。¶
前のセクションでは、バージョンイニシャライザの名前をマニフェストファイルに追加しました。このセクションでは、ストアド プロシージャのコードをセットアップ スクリプトに追加します。
setup_script.sql
ファイルの最後に以下のコードを追加します:
CREATE OR REPLACE PROCEDURE app_public.version_init()
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
can_create_compute_pool BOOLEAN; -- Flag to check if 'CREATE COMPUTE POOL' privilege is held
BEGIN
-- Check if the account holds the 'CREATE COMPUTE POOL' privilege
SELECT SYSTEM$HOLD_PRIVILEGE_ON_ACCOUNT('CREATE COMPUTE POOL')
INTO can_create_compute_pool;
ALTER SERVICE IF EXISTS core.echo_service
FROM SPECIFICATION_FILE = 'service/echo_spec.yaml';
IF (can_create_compute_pool) THEN
-- When installing app, the app has no 'CREATE COMPUTE POOL' privilege at that time,
-- so it will not execute the code below
-- Since the ALTER SERVICE is an async process, wait for the service to be ready
SELECT SYSTEM$WAIT_FOR_SERVICES(120, 'core.echo_service');
END IF;
RETURN 'DONE';
END;
$$;
変更したファイルをアップロードし、バージョンを作成します。¶
セットアップスクリプトを修正したら、修正したファイルをステージングにアップロードし、以下のプロシージャを実行してバージョンを作成します:
以下のコマンドを実行してファイルをアップロードし、バージョンを作成します。
snow app version create v1 -c tut-connection
snow app version
コマンドは更新されたファイルをステージにアップロードします。アプリケーションパッケージとファイルがすでに存在する場合、このコマンドは変更されたファイルのみをアップロードします。
このコマンドはv1という新しいバージョンのアプリを作成し、デフォルトのパッチは0にセットされます。
アプリのデフォルトリリースディレクティブのセット¶
前のセクションでは、変更したファイルをアップロードし、アプリのバージョン v1
を作成しました。このセクションでは、デフォルトのリリースディレクティブがバージョン v1
を使うようにセットします。
デフォルトのリリース指令を更新するには、ワークシートから以下のコマンドを実行してください。
ALTER APPLICATION PACKAGE na_spcs_tutorial_pkg
SET DEFAULT RELEASE DIRECTIVE VERSION=v1 PATCH=0;
アプリのデフォルトリリースディレクティブをセットすると、コンシューマーは自分のアカウントにアプリをインストールするときに、自動的にそのバージョンをインストールします。次のセクションでは、リリースディレクティブに基づいてローカルアカウントにアプリを作成します。
アプリを作成およびテストする¶
バージョンを追加し、デフォルトのリリースディレクティブをセットしたので、アプリを作成し、必要な権限を付与することができます。
以下のコマンドを実行して、リリース・ディレクティブからアプリを作成します:
snow app run --from-release-directive -c tut-connection
このコマンドは、前のセクションで定義したreleaseディレクティブを使ってアプリを作成します。
アプリを作成したら、ワークシートから以下のコマンドを実行して、アプリを実行できるように必要な権限をアプリに付与します。
GRANT CREATE COMPUTE POOL ON ACCOUNT TO APPLICATION na_spcs_tutorial_app; GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO APPLICATION na_spcs_tutorial_app;
ワークシートから以下のコマンドを実行して、
setup_script.sql
ファイルで定義したapp_public.start_app
プロシージャを呼び出します:CALL na_spcs_tutorial_app.app_public.start_app();
ワークシートから以下のコマンドを実行して、関数が作成されたことを確認してください:
SHOW FUNCTIONS LIKE '%my_echo_udf%' IN APPLICATION na_spcs_tutorial_app;
サービスが作成され、健全であることを確認するには、ワークシートから以下のコマンドを実行します。
CALL na_spcs_tutorial_app.app_public.service_status();
サービス関数を呼び出してサービスにリクエストを送信し、レスポンスを確認するには、ワークシートから以下のコマンドを実行します。
SELECT na_spcs_tutorial_app.core.my_echo_udf('hello');
アプリの情報を表示するには、ワークシートから以下のコマンドを実行します。
DESC APPLICATION na_spcs_tutorial_app;
このセクションで学んだことを復習する¶
このセクションでは、以下のタスクを完了しました。
バージョンイニシャライザーと、それをマニフェストファイルとセットアップスクリプトに追加する方法について学びました。
Snowflake Native App Framework バージョンとパッチの基本を学びました。
アプリの特定のバージョンを指すようにデフォルトのリリースディレクティブをセットします。
リリースディレクティブに基づいてアプリがインストールされました。
ストアドプロシージャを呼び出してアプリをテストし、 DESCRIBE APPLICATION コマンドを使用してアプリのステータスを表示しました。
注釈
このチュートリアルでは、アプリケーションオブジェクトをローカルアカウントで作成し、 DESCRIBE APPLICATION コマンドを使用しました。これはコンシューマーアカウントのアプリの動作を模倣したものです。
アプリのアップデートと新バージョンへのアップグレード¶
前のセクションでは、ストアドプロシージャとしてバージョンイニシャライザを追加することで、元のアプリを修正しました。また、デフォルトのリリースディレクティブに基づいて、アプリの新しいバージョンv1を作成しました。
このセクションでは、アプリに別の変更を加え、バージョンv2を作成し、デフォルトのリリースディレクティブを更新し、インストールされたアプリをバージョンv1からバージョンv2にアップグレードします。
アプリに新しいテーブルを追加¶
アプリに新しい機能を追加するシミュレーションを行うには、セットアップスクリプトに新しいテーブルを追加します。
setup_script.yml
の最後に以下のコマンドを追加します。CREATE TABLE IF NOT EXISTS core.setup_script_run(run_at TIMESTAMP); GRANT SELECT ON TABLE core.setup_script_run to APPLICATION ROLE app_user; INSERT INTO core.setup_script_run(run_at) values(current_timestamp());
アプリのバージョンを作成¶
修正したセットアップスクリプトをステージにアップロードし、アプリのバージョンv2を作成します。
na-spcs-tutorial
フォルダ内で以下のコマンドを実行します。
snow app version create v2 -c tut-connection
このコマンドはv2という新しいバージョンのアプリを作成し、デフォルトのパッチは0にセットされます。
snow app version
コマンドは更新されたファイルをステージにアップロードします。アプリケーションパッケージとファイルがすでに存在する場合、このコマンドは変更されたファイルのみをアップロードします。
アプリのデフォルトリリースディレクティブのセット¶
アプリケーションのバージョン v2
を作成した後、ワークシートから以下のコマンドを実行して、アプリケーションパッケージのリリースディレクティブをセットします:
ALTER APPLICATION PACKAGE na_spcs_tutorial_pkg
SET DEFAULT RELEASE DIRECTIVE VERSION=v2 PATCH=0;
このコマンドは、リリースディレクティブをバージョン v2
とパッチ 0
にセットします。
アプリをv1からv2にアップグレード¶
リリースディレクティブを新しいバージョンを指すように更新したので、ワークシートから以下のコマンドを実行してアプリをアップグレードします。
snow app run --from-release-directive -c tut-connection
アップグレードしたアプリのテスト¶
アプリをアップグレードした後、ワークシートから以下のコマンドを実行してアプリをテストします:
SELECT na_spcs_tutorial_app.core.my_echo_udf('hello');
このセクションで学んだことを復習する¶
おめでとうございます。アプリのバージョン v1
からバージョン v2
へのアップグレードに成功しました。
このセクションでは、以下のタスクを完了しました。
アプリにテーブルを追加するように更新しました。
このアップデートに基づき、アプリの新バージョンを作成しました。
デフォルトのリリースディレクティブが新しいバージョンを指すように更新しました。
手動でアプリをアップグレードしました。
次のセクションでは、アプリのサービスをアップグレードし、セットアップスクリプトに意図的にエラーを追加することで、アップグレードプロセスでのエラーをシミュレートします。
アップグレードエラーのシミュレーション¶
前のセクションでは、アプリに新しいテーブルを追加し、新しいバージョンを作成し、アプリをアップグレードしました。
このセクションでは、サービス仕様を更新し、サービスの更新をシミュレートします。また、セットアップスクリプトに意図的なエラーを追加してアップグレードの失敗をシミュレートし、アップグレードが失敗したときにバージョンイニシャライザがサービスのアップグレードをどのように処理するかを示します。
サービス仕様ファイルの更新¶
このセクションでは、アプリのサービス仕様を更新し、サービスの変更をシミュレートします。
service/echo_spec.yaml
ファイルで、CHARACTER_NAME
の値をBob
からTom
に変更します。この変更により、サービスは以下のメッセージを返します.
`Tom said hello.`
この変更の目的は、以下のセクションでアップグレードを試みた後に、どのバージョンのサービスが実行されているかを確認できるようにすることです。
意図的なエラーを含むようにセットアップスクリプトを更新します。¶
アップグレード処理中のエラーをシミュレートするには、存在しないテーブルに対する SELECT ステートメントを追加して、セットアップスクリプトに意図的なエラーを導入します。
setup_script.sql
の app_public.version_init()
プロシージャの最後に以下のステートメントを追加してください。
SELECT * FROM table_does_not_exist;
このステートメントは構文的には正しいのですが、存在しないテーブルを参照しています。このため、アップグレード中にセットアップスクリプトを実行するとエラーが発生します。
この変更を行うと、 app_public.version_init()
関数は次の例のようになります:
GRANT USAGE ON PROCEDURE app_public.service_status() TO APPLICATION ROLE app_user;
CREATE OR REPLACE PROCEDURE app_public.version_init()
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
-- Flag to check if 'CREATE COMPUTE POOL' privilege is held
can_create_compute_pool BOOLEAN;
BEGIN
-- Check if the account holds the 'CREATE COMPUTE POOL' privilege
SELECT SYSTEM$HOLD_PRIVILEGE_ON_ACCOUNT('CREATE COMPUTE POOL')
INTO can_create_compute_pool;
ALTER SERVICE IF EXISTS core.echo_service
FROM SPECIFICATION_FILE = 'service/echo_spec.yaml';
IF (can_create_compute_pool) THEN
-- When installing app, the app has no 'CREATE COMPUTE POOL' privilege at that time,
-- so it will not execute the code below
-- Since the ALTER SERVICE is an async process, wait for the service to be ready
SELECT SYSTEM$WAIT_FOR_SERVICES(120, 'core.echo_service');
END IF;
-- trigger an error. The upgrade fails
SELECT * FROM non_exist_table;
RETURN 'DONE';
END;
$$;
修正したファイルをアップロードし、新しいパッチを作成します。¶
前のセクションでは、アプリのサービス仕様とセットアップスクリプトを更新しました。
ファイルをアップロードしてアプリの新しいパッチを作成するには、以下のタスクを実行してください。
以下のコマンドを実行して、アプリケーション・パッケージにパッチを追加します。
snow app version create v2 --patch 1 -c tut-connection
プロンプトが表示されたら、
y
と入力し、アプリケーションパッケージに新しいパッチを追加します。
アプリのデフォルトリリースディレクティブのセット¶
前のセクションでは、ファイルをアップロードし、アップデート用のパッチを作成しました。パッチのデフォルトリリースディレクティブをセットするには、ワークシートから以下のコマンドを実行してください。
ALTER APPLICATION PACKAGE na_spcs_tutorial_pkg
SET DEFAULT RELEASE DIRECTIVE VERSION=v2 PATCH=1;
このコマンドは、アプリのパッチを 1
にセットします。
アプリのアップグレード¶
前のセクションでは、アプリのアップデートを行い、新しいパッチを作成しました。このセクションでは、前のセクションで紹介したエラーによってアプリが失敗することを想定して、アプリをアップグレードします。
アプリをアップグレードするには、以下のコマンドを実行します。
snow app run --from-release-directive -c tut-connection
アプリのアップグレード状態を表示するには、ワークシートから以下のコマンドを実行します。
DESC APPLICATION na_spcs_tutorial_app;
このコマンドは、アップグレードの状態、アップグレードの試行回数、アップグレードに失敗した理由など、アプリに関する情報を表示します。
アップグレードが失敗すると、 Snowflake CLI は次のようなメッセージを返します:
Object 'TABLE_DOES_NOT_EXIST' does not exist or not authorized.'
また、アップグレードが失敗した後、 DESC APPLICATION コマンドは、アップグレードに関連する以下のプロパティを表示します:
プロパティ
値
upgrade_state
FAILED
upgrade_failure_reason
upgrade_failure_reason[ErrorCode 2003] Uncaught exception of type 'STATEMENT_ERROR' on line 89 at position 0 : Uncaught exception of type 'STATEMENT_ERROR' on line 19 at position 3 : SQL コンパイルエラーです: オブジェクト 'TABLE_DOES_NOT_EXIST' が存在しないか、許可されていません。
どのバージョンのサービスが実行されているか確認するためにアプリサービスを実行します。¶
前のセクションでは、バージョン v2, パッチ 0 からバージョン v2, パッチ 1 へのアップグレードの失敗をシミュレートしました。
どのバージョンのサービスが現在実行されているかを調べるには、ワークシートから以下のコマンドを実行します。
SELECT na_spcs_tutorial_app.core.my_echo_udf('hello');
このコマンドは以下の文字列を返します。
Bob said hello
ここでは、アップグレードが失敗したため、アプリはv2、パッチ0のサービスを実行し続けていることがわかります。
しかし、アプリにバージョンイニシャライザを含めなかった場合、アプリのアップグレードは失敗したものの、アップグレードプロセスはサービスをv2、パッチ1にアップグレードしたことになります。アプリのアップグレードが失敗した場合、バージョンイニシャライザはサービスのバージョンがアップグレードされず、アプリと同期し続けることを保証します。
このセクションで学んだことを復習する¶
このセクションでは、以下のタスクを完了しました。
アップグレードプロセスでのエラーをシミュレートするため、セットアップスクリプトにエラーを導入しました。
障害発生後、アプリとサービスの両方のバージョンを確認しました。
バージョンイニシャライザーが、アップグレードに失敗したときにサービスのバージョンとアプリのバージョンが同期していることを保証する方法を学びました。
アップグレードエラーを修正するパッチの作成¶
前のセクションでは、アプリのセットアップスクリプトでエラーが発生しました。アプリをアップグレードした際、アプリとサービスの両方がバージョンv2パッチ0を使用して実行され続けていることを確認できました。
このセクションでは、エラーを修正するためにアプリのセットアップスクリプトを修正し、アップデート用のパッチを作成し、アプリをアップグレードします。
セットアップスクリプトの修正¶
前のセクションで紹介した意図的なエラーを修正するには、 setup_script.yaml
ファイルから以下のステートメントを削除します。
SELECT * FROM table_does_not_exist;
更新されたファイルをアップロードし、新しいパッチを作成します。¶
変更したセットアップスクリプトをステージングにアップロードし、新しいパッチを作成するには、以下のタスクを実行します。
以下のコマンドを実行して、アプリの新しいパッチを作成します。
プロンプトが表示されたら、
y
と入力し、アプリケーションパッケージに新しいパッチを追加します。
デフォルトのリリースディレクティブの更新¶
前のセクションでは、アプリのパッチ 2
を作成しました。パッチのデフォルトリリースディレクティブをセットするには、ワークシートから以下のコマンドを実行してください。
ALTER APPLICATION PACKAGE na_spcs_tutorial_pkg
SET DEFAULT RELEASE DIRECTIVE VERSION=v2 PATCH=2;
アプリのアップグレードとサービスのバージョン確認¶
新しいバージョンを作成し、デフォルトのリリースディレクティブをセットしたら、以下のタスクを実行してアプリをアップグレードし、サービスをテストします。
アプリをバージョン
v2
パッチ0
からバージョンv2
パッチ2
にアップグレードするには、以下のコマンドを実行します。snow app run --from-release-directive -c tut-connection
現在実行中のサービスのバージョンを確認するには、ワークシートから以下のコマンドを実行します。
SELECT na_spcs_tutorial_app.core.my_echo_udf('hello');
現在インストールされているバージョンなど、アプリのステータスを表示するには、以下のコマンドを実行します。
DESC APPLICATION na_spcs_tutorial_app;
出力では、
version
プロパティはv2
で、パッチプロパティは2
です。
このセクションで学んだことを復習する¶
おめでとうございます。アップグレード失敗後、アプリのアップグレードに成功しました。
このセクションでは、以下のタスクを完了しました。
セットアップスクリプトのエラーを修正しました。
新しいパッチ
p2
を作成し、アプリをアップデートしました。アプリを新しいパッチにアップグレードしました。
チュートリアルで作成したアプリとオブジェクトを取り壊します。¶
アプリはCompute Poolを使用するため、アカウントのクレジットを使用し、実行にはコストがかかります。アプリケーションがリソースを消費しないようにするには、アプリケーション・オブジェクトと、アプリケーション・オブジェクトが作成したアカウントレベルのオブジェクト(Compute Poolなど)の両方を破棄する必要があります。
Compute Poolが現在実行中であることを確認するには、以下のコマンドを実行してください。
snow object list compute-pool -l "na_spcs_tutorial_app_%"
Compute Poolが実行されている場合は、アプリケーションオブジェクトによって作成された
ACTIVE
Compute Poolの行が表示されます。以下の Snowflake CLI コマンドを実行して、アプリをティアダウンします:
snow app teardown --cascade --force -c tut-connection
このコマンドは、アプリによって作成されたすべてのSnowflakeオブジェクトを削除します。
--force
オプションがない場合、アプリケーション・パッケージにはバージョンが含まれているため、このコマンドはアプリケーション・パッケージを削除しません。Compute Poolが削除されたことを確認するために、もう一度以下のコマンドを実行してください。
snow object list compute-pool -l "na_spcs_tutorial_app_%"
このコマンドは、Compute Poolが正常に削除された場合には
no data
を返します。
注釈
snow app teardown
コマンドはアプリケーションパッケージとアプリケーションオブジェクトの両方を削除します。したがって、ステートフルなデータはすべて失われます。
詳細¶
おめでとうございます。このチュートリアルでは、コンテナーを使ってアプリを手動でアップグレードする方法を学びました。
概要¶
このチュートリアルでは、以下のタスクを完了しました。
アップグレードや障害時のサービスを処理するためのバージョンイニシャライザーストアドプロシージャを追加しました。
アプリケーション・パッケージにアプリケーションの新しいバージョン定義を作成しました。バージョン定義は、アプリのバージョン番号とパッチを指定します。
アプリのデフォルトリリースディレクティブをセットします。リリースディレクティブは、コンシューマーがアプリをインストールしたりアップグレードしたりするときに、どのバージョンやパッチがインストールされるかを決定します。
アプリをアップグレードし、アップグレード失敗時の動作を確認しました。