Ler em inglês

Compartilhar via

Ciclo de vida do aplicativo Service Fabric

  • Artigo

Semelhante a outras plataformas, um aplicativo no Azure Service Fabric geralmente passa pelas seguintes fases: design, desenvolvimento, teste, implantação, atualização, manutenção e remoção. O Service Fabric dá um excelente suporte ao ciclo de vida completo dos aplicativos em nuvem, desde o desenvolvimento até a implantação, gerenciamento diário, manutenção e possível encerramento. O modelo de serviço permite que várias funções diferentes participem do ciclo de vida do aplicativo de forma independente. Este artigo fornece uma visão geral das APIs e como elas são usadas pelas diferentes funções em todas as fases do ciclo de vida de um aplicativo da Malha do Serviço.

Confira esta página para obter um vídeo de treinamento que descreve como gerenciar o ciclo de vida do aplicativo:

Importante

Há dois utilitários da CLI usados para interagir com o Service Fabric. A CLI do Azure é usada para gerenciar os recursos do Azure, como um cluster do Service Fabric hospedado no Azure. A CLI do Service Fabric é usada para se conectar ao cluster do Service Fabric (independentemente de onde ele esteja hospedado) diretamente e gerenciar o cluster, aplicativos e serviços.

Funções do modelo de serviço

As funções do modelo de serviço são:

  • Desenvolvedor de serviço: desenvolve serviços modulares e genéricos que podem ser redefinidos e usados em vários aplicativos do mesmo tipo ou de tipos diferentes. Por exemplo, um serviço de fila pode ser usado para criar um aplicativo de emissão de tíquetes (assistência técnica) ou um aplicativo de comércio eletrônico (carrinho de compras).
  • Desenvolvedor de aplicativos: cria aplicativos integrando uma coleção de serviços para atender a determinados requisitos ou cenários. Por exemplo, um site de comércio eletrônico pode integrar o “Serviço de Front-End JSON sem Monitoração de Estado”, "Serviço de Monitoração de Estado do Leilão" e "Serviço de Monitoração de Estado da Fila" para criar uma solução de leilão.
  • Administrador do aplicativo: toma decisões sobre a configuração do aplicativo (preenchendo os parâmetros de configuração do modelo), implantação (mapeamento os recursos disponíveis) e qualidade do serviço. Por exemplo, um administrador do aplicativo decide a localidade do idioma do aplicativo (inglês para os EUA ou japonês para o Japão, por exemplo). Outro aplicativo implantado pode ter configurações diferentes.
  • Operador: implanta os aplicativos baseados na configuração do aplicativo e nos requisitos especificados pelo administrador do aplicativo. Por exemplo, um operador provisiona, implanta o aplicativo e verifica se ele está em execução no Azure. Os operadores de monitoram as informações de integridade e de desempenho do aplicativo e mantêm a infra-estrutura física conforme necessário.

Desenvolver

  1. Um desenvolvedor de serviço desenvolve tipos diferentes de serviços usando o modelo de programação Reliable Actors ou Reliable Services.
  2. Um desenvolvedor de serviços declarativamente descreve os tipos de serviço desenvolvidos em um arquivo de manifesto do serviço que consiste em um ou mais pacotes de código, configuração e dados.
  3. Um desenvolvedor de aplicativos cria um aplicativo usando diferentes tipos de serviço.
  4. Um desenvolvedor de aplicativos declarativamente descreve o tipo de aplicativo em um manifesto do aplicativo, referenciando os manifestos do serviço dos serviços de componentes e adequadamente substituindo e parametrizando diferentes configurações e definições de implantação dos serviços de componentes.

Confira Introdução aos Reliable Actors e Introdução aos Reliable Services para obter exemplos.

Implantar

  1. Um administrador do aplicativo personaliza o tipo de aplicativo para um aplicativo específico a ser implantado para um cluster Service Fabric especificando os parâmetros apropriados do elemento ApplicationType no manifesto do aplicativo.
  2. Um operador carrega o pacote de aplicativos para o armazenamento de imagens do cluster usando o método CopyApplicationPackage ou o cmdlet Copy-ServiceFabricApplicationPackage. O pacote de aplicativo contém o manifesto do aplicativo e a coleção de pacotes de serviço. O Service Fabric implanta os aplicativos do pacote de aplicativos colocado no armazenamento de imagens, que pode ser um armazenamento de blobs do Azure ou o serviço do sistema Service Fabric.
  3. O operador, então, configura o tipo de aplicativo no cluster de destino do pacote de aplicativos carregado usando o método ProvisionApplicationAsync, o cmdlet Unregister-ServiceFabricApplicationType ou a operação RESTProvisionar um Aplicativo.
  4. Após a configuração do aplicativo, um operador inicia o aplicativo com os parâmetros fornecidos pelo administrador do aplicativo usando o método CreateApplicationAsync, o cmdlet New-ServiceFabricApplication ou a operação REST Criar Aplicativo.
  5. Depois de o aplicativo ser implantado, um operador usa o método CreateServiceAsync, o cmdlet New-ServiceFabricService ou a operação REST Criar Serviço para criar novas instâncias de serviço para o aplicativo com base nos tipos de serviço disponíveis.
  6. O aplicativo está sendo executado no cluster da Malha do Serviço.

Confira implantar um aplicativo para obter exemplos.

Teste

  1. Depois de implantar o cluster de desenvolvimento local ou um cluster de teste, um desenvolvedor de serviço executa o cenário de teste de failover interno usando as classes FailoverTestScenarioParameters e FailoverTestScenario ou o cmdlet Invoke-ServiceFabricFailoverTestScenario. O cenário de teste de failover executa um determinado serviço através de transições e failovers importantes para garantir que ainda estará disponível e funcionando.
  2. O desenvolvedor de serviço executa o cenário de teste de caos interno usando as classes ChaosTestScenarioParameters e ChaosTestScenario ou o cmdlet Invoke-ServiceFabricChaosTestScenario. O cenário de teste caos induz vários nós, pacote de código e falhas de réplica aleatoriamente no cluster.
  3. O desenvolvedor de serviços testa a comunicação serviço a serviço criando cenários de teste que movem réplicas primárias pelo cluster.

Consulte Introduction to the Fault Analysis Service (Introdução ao Fault Analysis Service) para obter mais informações.

Atualizar

  1. Um desenvolvedor de serviço atualiza os serviços membros do aplicativo instanciado e/ou corrige erros e fornece uma nova versão do manifesto do serviço.
  2. Um desenvolvedor de aplicativos substitui e parametriza as configurações de implantação e configuração dos serviços membros e fornece uma nova versão do manifesto do aplicativo. O desenvolvedor do aplicativo incorpora as novas versões dos manifestos do serviço no aplicativo e fornece uma nova versão do tipo de aplicativo em um pacote de aplicativo atualizado.
  3. Um administrador de aplicativos incorpora a nova versão do tipo de aplicativo para o aplicativo de destino atualizando os parâmetros apropriados.
  4. Um operador carrega o pacote de aplicativos atualizado no armazenamento de imagens de cluster usando o método CopyApplicationPackage ou o cmdlet Copy-ServiceFabricApplicationPackage. O pacote de aplicativo contém o manifesto do aplicativo e a coleção de pacotes de serviço.
  5. Um operador configura a nova versão do aplicativo no cluster de destino usando o método ProvisionApplicationAsync, o cmdlet Register-ServiceFabricApplicationType ou a operação REST Configurar um Aplicativo.
  6. Um operador atualiza o aplicativo de destino para a nova versão usando o método UpgradeApplicationAsync, o cmdlet Start-ServiceFabricApplicationUpgrade ou a operação REST Atualizar um Aplicativo.
  7. Um operador verifica o progresso de atualização usando o método GetApplicationUpgradeProgressAsync, o cmdlet Get-ServiceFabricApplicationUpgrade ou a operação REST Obter Progresso de Atualização do Aplicativo.
  8. Se necessário, o operador modifica e reaplica os parâmetros da atualização do aplicativo atual usando o método UpdateApplicationUpgradeAsync, o cmdlet Update-ServiceFabricApplicationUpgrade ou a operação REST Fazer Atualização do Aplicativo.
  9. Se necessário, o operador reverte a atualização do aplicativo atual usando o método RollbackApplicationUpgradeAsync, o cmdlet Start-ServiceFabricApplicationRollback ou a operação REST Reverter Atualização do Aplicativo.
  10. A Malha do Serviço atualiza o aplicativo de destino em execução no cluster sem perder a disponibilidade de qualquer um dos seus serviços membros.

Consulte Tutorial sobre a atualização do aplicativo para obter exemplos.

Manter

  1. Para patches e atualizações do sistema operacional, a Malha do Serviço faz a interface com a infraestrutura do Azure para garantir a disponibilidade de todos os aplicativos executados no cluster.
  2. Para ver as atualizações e as correções para a plataforma Service Fabric, o Service Fabric se atualiza automaticamente sem perder a disponibilidade de qualquer aplicativo em execução no cluster.
  3. Um administrador do aplicativo aprova a adição ou remoção de nós de um cluster depois de analisar os dados do histórico de utilização da capacidade e demanda futura projetada.
  4. Um operador adiciona e remove nós especificados pelo administrador do aplicativo.
  5. Quando novos nós são adicionados ou os nós existentes são removidos do cluster, o Service Fabric balanceia a carga automaticamente dos aplicativos em execução em todos os nós do cluster para obter o desempenho ideal.

Remover

  1. Um operador pode excluir uma instância específica de um serviço em execução no cluster sem remover o aplicativo inteiro usando o método DeleteServiceAsync, o cmdlet Remove-ServiceFabricService ou a operação REST Excluir Serviço.
  2. Um operador também pode excluir uma instância do aplicativo e todos os serviços usando o método DeleteApplicationAsync, o cmdlet Remove-ServiceFabricApplication ou a operação REST Excluir Aplicativo.
  3. Depois de os aplicativos e serviços serem interrompidos, o operador pode desconfigurar o tipo de aplicativo usando o método UnprovisionApplicationAsync, o cmdlet Unregister-ServiceFabricApplicationType ou a operação REST Desconfigurar um Aplicativo. Desconfigurar o tipo de aplicativo não remove o pacote de aplicativos do ImageStore.
  4. Um operador remove o pacote de aplicativos do ImageStore usando o método RemoveApplicationPackage ou o cmdlet Remove-ServiceFabricApplicationPackage.

Confira implantar um aplicativo para obter exemplos.

Preservação de espaço em disco no repositório de imagens do cluster

O ImageStoreService mantém os pacotes copiados e provisionados, o que pode levar ao acúmulo de arquivos. O acúmulo de arquivos pode fazer com que o ImageStoreService (fabric:/System/ImageStoreService) encha o disco e pode aumentar o tempo de compilação das réplicas ImageStoreService.

Para evitar o acúmulo de arquivos, use a seguinte sequência de provisionamento:

  1. Copiar pacote para ImageStore e usar a opção de compactação

  2. Provisionar o pacote

  3. Remover o pacote no repositório de imagens

  4. Atualizar o aplicativo/cluster

  5. Cancelar o provisionamento da versão antiga

As etapas 3 e 5 no procedimento acima impedem o acúmulo de arquivos no repositório de imagens.

Configuração para limpeza automática

Você pode automatizar a etapa 3 acima usando o PowerShell ou o XML. Isso fará com que o pacote de aplicativos seja excluído automaticamente, após o registro bem-sucedido do tipo de aplicativo.

PowerShell:

PowerShell 
Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

XML 
<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

Você pode automatizar a etapa 5 acima usando o XML. Isso fará com que o registro dos tipos de aplicativo não utilizados seja cancelado automaticamente.

XML 
<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

Limpar arquivos e dados em nós

A replicação de arquivos de aplicativo distribuirá eventualmente os arquivos para todos os nós, dependendo das ações de balanceamento. Isso pode criar pressão de disco dependendo do número de aplicativos e do tamanho do arquivo. Mesmo quando nenhuma instância ativa estiver em execução em um nó, serão mantidos os arquivos de uma instância anterior. O mesmo vale para dados de coleções confiáveis usadas por serviços com estado. Isso serve à finalidade de maior disponibilidade. No caso de uma nova instância de aplicativo no mesmo nó, não deve ser copiado nenhum arquivo. Para coleções confiáveis, somente o delta deve ser replicado.

Para remover completamente os binários do aplicativo, você precisa cancelar o registro do tipo de aplicativo.

Recomendações para reduzir a pressão do disco:

  1. Remove-ServiceFabricApplicationPackage que remove o pacote do local de carregamento temporário.
  2. Unregister-ServiceFabricApplicationType libera espaço de armazenamento removendo os arquivos de tipo de aplicativo do serviço de repositório de imagens e todos os nós. O gerenciador de exclusão é executado a cada hora por padrão.
  3. CleanupUnusedApplicationTypes limpa automaticamente versões antigas de aplicativos não utilizados.
    ARM 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage remove binários antigos de instalação de runtime não utilizados.

Observação

Um recurso está em desenvolvimento para permitir que Service Fabric exclua pastas de aplicativo depois que o aplicativo é evacuado do nó.

Próximas etapas

Para saber mais sobre o desenvolvimento, o teste e o gerenciamento de aplicativos e serviços da Malha do Serviço, confira: