Atualizar um app usando canais de lançamento¶
Este tópico fornece informações sobre como atualizar um Snowflake Native App usando canais de lançamento.
Sobre as atualizações de aplicativos¶
O Snowflake Native App Framework permite que os provedores atualizem um app para uma nova versão ou patch.
Os provedores podem iniciar uma atualização de um app para uma nova versão ou patch definindo a diretiva de lançamento em um canal de lançamento. Quando a diretriz de versão é modificada, o Snowflake atualiza automaticamente todas as instâncias instaladas da versão atual do aplicativo para a versão especificada pela diretriz de versão.
Quando o provedor inicia uma atualização, o Snowflake adiciona cada aplicativo a ser atualizado a uma fila. Cada aplicativo é atualizado à medida que os recursos estão disponíveis. O processo de atualização pode demorar um pouco para ser concluído em todas as versões instaladas do aplicativo. Para agilizar o processo de atualização, os consumidores também podem iniciar manualmente uma atualização de um aplicativo quando uma nova versão ou patch estiver disponível.
Nota
Após o início do processo de atualização de um app, os consumidores não poderão mais atualizar o aplicativo manualmente.
Considerações ao atualizar um app com várias versões¶
Quando um provedor publica uma nova versão de um app, o Snowflake garante que apenas a versão anterior do app esteja ativa. Por exemplo, se um provedor publicou as versões v1 e v2 de um app, o Snowflake garante que apenas a v2 esteja instalada em uma conta do consumidor antes da atualização para a v3. Isso requer que todos os aplicativos instalados que usam a versão v1 sejam migrados para a versão v2.
Isso garante que o script de configuração do aplicativo só tenha que levar em conta as diferenças entre a v2 e a v3. O script de configuração é compatível apenas com a versão mais recente do aplicativo. Se um provedor fizer uma alteração de estado no aplicativo, por exemplo, criar uma nova tabela ou adicionar colunas a uma tabela, os provedores só precisam garantir que não haja problemas de compatibilidade entre duas versões.
Por outro lado, quando um provedor cria um novo patch para uma versão de um aplicativo, o Snowflake Native App Framework não impõe nenhuma restrição ao número de patches ativos em execução. Os provedores devem evitar fazer alterações no estado de um aplicativo em um patch para evitar incompatibilidade entre vários patches.
Considerações sobre a remoção de uma versão de um app após uma atualização¶
Embora um aplicativo possa ser atualizado na conta do consumidor, a versão anterior do aplicativo ainda pode ter um código em execução. Os provedores não podem remover a versão anterior do app do canal de lançamento até que todo o código em execução da versão anterior seja concluído. Isso se aplica a todas as versões instaladas do aplicativo em todas as contas de consumidores. Se um único upgrade falhar, os provedores deverão corrigir o motivo da falha no upgrade antes de poder remover a versão.
Atualizações em todas as regiões¶
Para obter informações sobre como atualizar um app em várias regiões, consulte Atualização de um aplicativo em todas as regiões.
Fluxo de trabalho para atualizar um app¶
Um provedor atualiza um app usando o seguinte fluxo de trabalho:
Atualize o aplicativo para incluir novos recursos.
Se você estiver criando uma nova versão do aplicativo e houver duas versões atualmente definidas para o aplicativo:
Certifique-se de que nenhum consumidor esteja executando a versão no momento.
Descarte a versão do aplicativo que você está substituindo.
Crie uma nova versão ou patch para as alterações no canal de lançamento.
Se a propriedade DISTRIBUTION do pacote do aplicativo estiver definida como EXTERNAL, a verificação de segurança automatizada será iniciada. A verificação de segurança deve passar antes que o upgrade possa ocorrer.
Teste a nova versão instalando o app em sua conta de teste.
Atualize a diretriz de versão da versão ou patch.
Isso inicia um upgrade automatizado que atualizará todas as instâncias instaladas da versão anterior. Um provedor pode notificar o consumidor de que uma atualização está disponível e solicitar que ele atualize o app manualmente.
Definir uma data e hora de início para um upgrade¶
Os provedores podem definir uma data e hora que especifica quando um upgrade automático deve começar. Essa data e hora são definidas na diretiva de lançamento (padrão ou personalizada) usando a cláusula UPGRADE_AFTER do comando ALTER APPLICATION PACKAGE. Há suporte para diretivas de lançamento padrão e personalizadas.
A data e a hora do upgrade podem ser qualquer tipo válido de data e hora. Se o carimbo de data/hora já tiver passado, o upgrade será agendado imediatamente. Esse é o mesmo comportamento de não definir a cláusula UPGRADE_AFTER.
Você só pode usar a cláusula UPGRADE_AFTER se estiver definindo a versão e o patch. Essa cláusula não pode ser usada para modificar apenas a data e a hora do upgrade.
Definir a data e a hora do upgrade para a diretiva de lançamento padrão¶
Para definir a data e a hora do upgrade para a diretiva de lançamento padrão:
ALTER APPLICATION PACKAGE hello_snowflake_package MODIFY RELEASE CHANNEL DEFAULT SET DEFAULT RELEASE DIRECTIVE VERSION = 'v1_0' PATCH = '2' UPGRADE_AFTER = '2025-04-06T11:00:00Z'
Este comando define a data e a hora da atualização para o patch 2 ou a versão v1_0 do canal de lançamento DEFAULT para 6 de abril de 2025 às 11h.
Nota
Esta é a data e hora mais antigas em que a atualização pode começar. A atualização real pode ocorrer mais tarde, dependendo do número de apps que estão sendo atualizados, do número de contas de consumidores etc.
Definir a data e a hora do upgrade para uma diretiva de lançamento personalizada¶
Para definir a data e a hora da atualização para uma diretiva de lançamento padrão:
ALTER APPLICATION PACKAGE hello_snowflake_package MODIFY RELEASE CHANNEL DEFAULT SET DEFAULT RELEASE DIRECTIVE VERSION = 'v1_0' PATCH = '2' UPGRADE_AFTER = '2025-04-06T11:00:00Z'
Este comando define a data e a hora da atualização para o patch 2 ou a versão v1_0 do canal de lançamento DEFAULT para 6 de abril de 2025 às 11h.
Nota
Esta é a data e hora mais antigas em que a atualização pode começar. A atualização real pode ocorrer mais tarde, dependendo do número de apps que estão sendo atualizados, do número de contas de consumidores etc.
Alterar a data e a hora do upgrade de uma diretiva de lançamento personalizada¶
Para alterar a data e a hora do upgrade de uma diretiva de lançamento padrão:
ALTER APPLICATION PACKAGE hello_snowflake_package MODIFY RELEASE CHANNEL DEFAULT SET DEFAULT RELEASE DIRECTIVE ACCOUNTS = ( USER_ACCOUNT.snowflakecomputing.com ) VERSION = 'v1_0' PATCH = '2' UPGRADE_AFTER = '2025-04-06T11:00:00Z'
Este comando altera a data e a hora da atualização para o patch 2 ou a versão v1_0 do canal de lançamento DEFAULT para 6 de abril de 2025 às 11h.
Nota
Esta é a data e hora mais antigas em que a atualização pode começar. A atualização real pode ocorrer mais tarde, dependendo do número de apps que estão sendo atualizados, do número de contas de consumidores etc.
Início da atualização¶
O processo de atualização começa automaticamente quando um provedor atualiza a diretiva de lançamento (padrão ou personalizada) do canal de lançamento para apontar para uma nova versão ou patch. Use o comando ALTER APPLICATION PACKAGE … RELEASE DIRECTIVE para definir a diretriz de versão, conforme mostrado nos exemplos a seguir:
ALTER APPLICATION PACKAGE my_application_package
MODIFY RELEASE CHANNEL DEFAULT
SET DEFAULT RELEASE DIRECTIVE
VERSION = v2
PATCH = 0;
Este comando define a diretiva de lançamento padrão para a versão v2 e o patch 0 para o canal de lançamento padrão.
ALTER APPLICATION PACKAGE my_application_package
MODIFY RELEASE CHANNEL DEFAULT
SET RELEASE DIRECTIVE my_custom_release_directive
ACCOUNTS = ( USER_ACCOUNT.snowflakecomputing.com )
VERSION = v2
PATCH = 0;
Esse comando define a diretriz de versão personalizada chamada my_custom_release_directive para a versão v2 e o patch 0 para a conta USER_ACCOUNT.snowflakecomputing.com.
Consulte Set the release directive for an app (Legacy) para obter mais informações.
Atualização manual de um aplicativo¶
As atualizações manuais permitem que um consumidor atualize seu aplicativo instalado mais rapidamente do que as atualizações automatizadas. Quando uma nova versão ou patch estiver disponível, o provedor poderá solicitar ao consumidor que faça uma atualização manual.
O consumidor realiza uma atualização manual executando o ALTER APPLICATION. Este comando inicia a atualização de uma versão ou patch instalado de um app usando a diretiva de lançamento especificada no canal de lançamento.
Para fazer o upgrade de um Snowflake Native App instalado para a versão mais recente disponível, um consumidor pode usar a cláusula UPGRADE do comando ALTER APPLICATION para modificar o aplicativo:
ALTER APPLICATION <name> UPGRADE
Atualização de um aplicativo em todas as regiões¶
Depois de atualizar o aplicativo, as alterações no Snowflake Native App instalado na conta do consumidor podem não ficar visíveis até que a atualização para regiões remotas seja executada.
Você pode usar o Exibição APPLICATION_STATE no esquema Uso de Data Sharing para monitorar o estado. Se o upgrade não for concluído mais de um dia após a primeira atualização depois do upgrade, pode haver um problema com o processo de atualização. Entre em contato com o suporte Snowflake.
Se um provedor publicar um Snowflake Native App usando o Preenchimento automático entre nuvens, as atualizações automatizadas poderão demorar um pouco para serem atualizadas, dependendo de vários fatores, inclusive:
O valor do agendamento de atualização.
O número de instâncias instaladas do aplicativo.
O número de regiões onde o aplicativo está implantado.
Se a atualização contiver uma correção urgente que precise ser atualizada em uma região remota, o provedor poderá reduzir a frequência de atualização da listagem para um valor menor. Consulte Gerenciar e monitorar as configurações de preenchimento automático para saber como definir a frequência de atualização no nível da conta.
Cuidado
A redução da frequência de atualização pode aumentar os custos associados à replicação.
Atualização de estados¶
Durante o processo de atualização, o aplicativo passa por diferentes estados. O diagrama a seguir mostra os possíveis estados ao fazer upgrade da versão anterior, v1, para uma nova versão, v2.
Nota
Embora esse diagrama mostre uma atualização para uma versão, ele também se aplica a atualizações de patches.
A tabela a seguir mostra cada estágio do processo de upgrade de um aplicativo na mesma região em que o pacote do aplicativo está localizado:
Estágio |
Descrição |
|
|---|---|---|
1 |
O aplicativo está desativado? |
Se o aplicativo estiver desativado, não será possível fazer upgrade. |
2 |
Definir a diretriz de versão como v2.0 |
O provedor define a diretriz de versão como v2.0. |
3 |
Elegível para upgrade |
O Snowflake realiza verificações para confirmar se o aplicativo é elegível para upgrade. Essas verificações incluem verificar se o aplicativo não está desativado, se o pacote do aplicativo está disponível, se a versão e o patch são válidos para atualização, se a conta do consumidor é válida etc. |
4 |
Obter slot de upgrade? |
Dependendo do número de aplicativos que estão sendo atualizados, do número de contas de consumidores etc., eles podem ter que esperar para iniciar o processo de atualização. |
5 |
O script de configuração foi executado com êxito? |
Quando a atualização começa, o Snowflake executa o script de configuração. Se ocorrer algum erro não detectado, a execução do script de configuração será interrompida. O Snowflake coloca o aplicativo na fila para atualização novamente com base no número de tentativas configuradas. |
6 |
A versão está atualizada? |
O Snowflake verifica se a atualização é para uma versão ou patch. Se a atualização for para uma versão, o Snowflake realizará verificações adicionais e aguardará até que todos os trabalhos da versão anterior do aplicativo tenham sido concluídos. |
A tabela a seguir mostra o processo de upgrade para aplicativos que são implementados em regiões remotas:
Estágio |
Descrição |
|
|---|---|---|
7 |
Diretriz de versão v2.0 replicada na região remota |
Quando um provedor define a diretriz de versão para um aplicativo implantado em uma região remota, a diretriz de versão é propagada para o pacote do aplicativo implantado na região remota. |
8 |
Região ativa para a v2.0? |
Quando a maioria dos aplicativos na região primária tiver sido atualizada, o Snowflake envia mensagens para a região remota para iniciar a atualização do aplicativo. |
9 |
Iniciar o processo de upgrade |
Inicie o processo de upgrade do aplicativo conforme descrito na tabela anterior. |
A tabela a seguir descreve cada um dos possíveis estados do processo de upgrade:
Estado |
Descrição |
|---|---|
DISABLED |
O aplicativo está desativado e não é elegível para atualização. |
QUEUED |
O aplicativo está na fila de espera para ser atualizado com base no número de aplicativos e contas de consumidores. |
UPGRADING |
O aplicativo está em processo de atualização. |
COMPLETED |
A atualização do aplicativo foi bem-sucedida. |
QUEUED_RETRY |
O script de configuração ou outra verificação falhou e o aplicativo é devolvido à fila de atualização. |
FAILED |
A atualização do aplicativo falhou. As atualizações podem falhar no lado do provedor, por exemplo, devido a um erro no script de configuração. As atualizações também podem falhar no lado do consumidor se o aplicativo estiver desativado, a conta do consumidor estiver inativa etc. |
Monitoramento do estado de uma atualização¶
Para visualizar o estado de atualização de um aplicativo, use o Exibição APPLICATION_STATE.
Por exemplo, em uma situação em que você atualizou a diretriz de versão padrão e deseja verificar se todos os aplicativos atingiram a versão de destino. Para localizar instâncias de aplicativos que ainda não concluíram o upgrade, use a consulta do exemplo a seguir:
SELECT * FROM snowflake.data_sharing_usage.APPLICATION_STATE
Essa exibição inclui colunas específicas para upgrades, incluindo o estado do upgrade e a região onde o aplicativo está implantado. Para obter informações sobre os estados de upgrade, consulte Atualização de estados.
Solução de problemas durante a atualização¶
O Snowflake Native App Framework fornece várias maneiras de solucionar problemas de atualização, conforme descrito nas seções a seguir:
Como identificar erros de upgrade¶
Os consumidores podem usar o comando DESCRIBE APPLICATION para visualizar mensagens de erro relacionadas a upgrades com falha. Esse comando fornece informações sobre os erros que ocorreram durante o processo de upgrade.
Os provedores podem usar o Exibição APPLICATION_STATE para visualizar mensagens de erro de upgrades com falha. Usando essa visualização, os provedores podem diagnosticar problemas com aplicativos específicos. Consulte Monitoramento do estado de uma atualização para obter mais informações.
Como usar o registro em log e o rastreamento de eventos¶
Se o registro em log e o rastreamento de eventos estiverem configurados para o aplicativo, os provedores poderão consultar a tabela de eventos para diagnosticar problemas com a atualização do aplicativo.
Consulte Exibição dos logs e eventos na tabela de eventos para obter mais informações.
Monitoramento do estado de um serviço do aplicativo¶
Para visualizar informações sobre o status de um pool de computação ou serviço em um aplicativo, os consumidores podem usar as seguintes funções do sistema:
Os consumidores podem compartilhar essas informações com os provedores. Os provedores também podem configurar o compartilhamento de eventos para retornar essas informações.
Aplicativos desativados¶
Quando um aplicativo instalado na conta do consumidor é desativado, ele não pode mais ser usado. Um aplicativo instalado em uma conta de consumidor pode ser desativado por vários motivos, inclusive:
Problemas com o pacote do aplicativo
Problemas com o aplicativo instalado
Problemas com a conta do consumidor
Tanto os provedores quanto os consumidores devem evitar situações em que um aplicativo permaneça desativado por um longo período. Os aplicativos desativados podem se tornar inutilizáveis e precisam ser reinstalados
Atualização de um aplicativo desativado¶
Os aplicativos desativados não fazem parte do processo normal de atualização e não podem ser atualizados. Se um app desativado for reativado, ele será atualizado automaticamente para a versão e o patch da diretiva de lançamento. No entanto, se a versão ou o patch não estiver mais disponível, o app não poderá ser atualizado e deverá ser reinstalado.
Por exemplo, se um app desativado estiver na versão v1, mas as versões atual e anterior no canal de lançamento forem v2 e v3, o app não poderá ser atualizado e ficará inutilizável.
Motivos pelos quais um aplicativo pode ser desativado¶
Você pode visualizar a coluna DISABLEMENT_REASONS do Exibição APPLICATION_STATE para ver os motivos pelos quais um aplicativo está desativado. A tabela a seguir lista os valores possíveis para a coluna DISABLEMENT_REASONS:
Valor |
Descrição do status |
É recuperável? |
|---|---|---|
MANUALLY_DISABLED |
O aplicativo foi desabilitado pelo Snowflake |
Sim. Para reativar o aplicativo, entre em contato com o suporte Snowflake. |
ACCOUNT_INACTIVE |
A conta fica inativa ao ser bloqueada ou suspensa, fazendo com que o aplicativo fique indisponível. Nesse estado, o consumidor não pode executar nenhuma consulta SQL em sua conta e o aplicativo não pode ser atualizado. |
Sim. O aplicativo é reativado automaticamente se o bloqueio ou suspensão da conta for removido |
PACKAGE_VERSION_IS_MISSING |
A versão do pacote de aplicativo para o aplicativo foi descartada pelo provedor. |
Não. O aplicativo não pode mais ser usado e deve ser descartado e reinstalado a partir de uma listagem válida ou pacote de aplicativo. |
CMK_ACCESS_DENIED |
O consumidor gerencia a chave de criptografia (ENCRYPT_USE_CMK_KMS está habilitado) e o Snowflake não tem acesso a essa chave. |
Sim. Para reativar o aplicativo, certifique-se de que a configuração do provedor de nuvem para recuperar a CMK esteja correta e que o Snowflake tenha acesso à chave. |
LISTING_ACCESS_REVOKED |
A listagem usada para criar o aplicativo não está mais disponível. Possíveis razões para esse status incluem:
|
Possivelmente. A recuperabilidade depende do motivo pelo qual o acesso foi revogado. Por exemplo, se o listagem foi excluída, ela não poderá ser recuperada. Se uma conta de consumidor foi removida manualmente da listagem privada, o acesso à listagem e ao aplicativo pode ser restaurado. |
LISTING_TRIAL_USAGE_EXCEEDED |
O aplicativo excedeu o limite de uso para uma listagem de teste baseada no uso. |
Não |
LISTING_PAYMENT_REQUIRED |
A listagem usada para instalar o aplicativo é uma listagem paga e exige pagamento para uso posterior. |
Sim. O consumidor deve definir corretamente o pagamento do aplicativo. |
LISTING_TRIAL_TIME_EXCEEDED |
O aplicativo excedeu o período de teste. |
Não |
APPLICATION_PACKAGE_NOT_AVAILABLE |
O pacote de aplicativo usado para criar o aplicativo não existe mais. O provedor pode ter descartado o pacote de aplicativo correspondente. |
Não |
APPLICATION_PACKAGE_DISABLED |
O pacote de aplicativo usado para criar o aplicativo é desabilitado pelo Snowflake. |
Sim. O aplicativo será reativado se o Snowflake reativar o pacote do aplicativo. |
APPLICATION_SUSPENDED |
Os recursos do aplicativo, por exemplo, tarefas, serviços e pools de computação, são suspensos porque o aplicativo está desabilitado. Os objetos suspensos permanecem suspensos até que o aplicativo seja reativado e não haja outros motivos para a desativação do aplicativo. |
Sim |
APPLICATION_SUSPEND_RESUME_IN_PROGRESS |
Os recursos do aplicativo, por exemplo, tarefas, serviços e pools de computação, estão sendo retomados no momento. |
Sim |