Partilhar via

Ciclo de vida da aplicação do Service Fabric

  • Artigo

Como em 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 fornece suporte de primeira classe para todo o ciclo de vida de aplicativos em nuvem, desde o desenvolvimento até a implantação, gerenciamento diário e manutenção até a eventual desativação. O modelo de serviço permite que várias funções diferentes participem independentemente do ciclo de vida do aplicativo. Este artigo fornece uma visão geral das APIs e como elas são usadas pelas diferentes funções ao longo das fases do ciclo de vida do aplicativo Service Fabric.

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

Importante

Existem dois utilitários CLI utilizados para interagir com o Service Fabric. A CLI do Azure serve para gerir os recursos do Azure, tal como um cluster do Service Fabric alojado no Azure. A CLI do Service Fabric serve para ligar diretamente ao cluster do Service Fabric (independentemente do local onde está alojado) e gerir o cluster, as aplicações e os serviços.

Funções do modelo de serviço

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

  • Desenvolvedor de serviços: Desenvolve serviços modulares e genéricos que podem ser reaproveitados e usados em várias aplicações do mesmo tipo ou tipos diferentes. Por exemplo, um serviço de fila pode ser usado para criar um aplicativo de tíquete (helpdesk) ou um aplicativo de comércio eletrônico (carrinho de compras).
  • Desenvolvedor de aplicativos: cria aplicativos integrando uma coleção de serviços para satisfazer determinados requisitos ou cenários específicos. Por exemplo, um site de comércio eletrônico pode integrar "JSON Stateless Front-End Service", "Auction Stateful Service" e "Queue Stateful Service" para criar uma solução de leilão.
  • Administrador de aplicativos: toma decisões sobre a configuração do aplicativo (preenchendo os parâmetros do modelo de configuração), implantação (mapeamento para recursos disponíveis) e qualidade do serviço. Por exemplo, um administrador de aplicativo decide a localidade do idioma (inglês para os Estados Unidos ou japonês para o Japão, por exemplo) do aplicativo. Um aplicativo implantado diferente pode ter configurações diferentes.
  • Operador: implanta aplicativos com base na configuração do aplicativo e nos requisitos especificados pelo administrador do aplicativo. Por exemplo, um operador provisiona e implanta o aplicativo e garante que ele esteja sendo executado no Azure. Os operadores monitoram as informações de integridade e desempenho do aplicativo e mantêm a infraestrutura física conforme necessário.

Programar

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

Consulte Introdução aos atores confiáveis e Introdução aos serviços confiáveis para obter exemplos.

Implementar

  1. Um administrador de aplicativo adapta o tipo de aplicativo a um aplicativo específico a ser implantado em um cluster do Service Fabric especificando os parâmetros apropriados do elemento ApplicationType no manifesto do aplicativo.
  2. Um operador carrega o pacote do aplicativo no armazenamento de imagens do cluster usando o método CopyApplicationPackage ou o cmdlet Copy-ServiceFabricApplicationPackage. O pacote do aplicativo contém o manifesto do aplicativo e a coleção de pacotes de serviço. O Service Fabric implanta aplicativos do pacote de aplicativos armazenado no repositório de imagens, que pode ser um repositório de blobs do Azure ou o serviço do sistema Service Fabric.
  3. Em seguida, o operador provisiona o tipo de aplicativo no cluster de destino a partir do pacote de aplicativo carregado usando o método ProvisionApplicationAsync, o cmdlet Register-ServiceFabricApplicationType ou a operação Provisionar um aplicativo REST.
  4. Depois de provisionar o 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 Create Application REST.
  5. Depois que o aplicativo é implantado, um operador usa o método CreateServiceAsync, o cmdlet New-ServiceFabricService ou a operação Create Service REST para criar novas instâncias de serviço para o aplicativo com base nos tipos de serviço disponíveis.
  6. O aplicativo agora está sendo executado no cluster do Service Fabric.

Consulte Implantar um aplicativo para obter exemplos.

Teste

  1. Depois de implantar no cluster de desenvolvimento local ou em 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 serviço especificado por meio de transições e failovers importantes para garantir que ele ainda esteja disponível e funcionando.
  2. Em seguida, o desenvolvedor do 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 de caos induz aleatoriamente várias falhas de nó, pacote de código e réplica 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 Introdução ao Serviço de Análise de Falhas para obter mais informações.

Atualização

  1. Um desenvolvedor de serviço atualiza os serviços constituintes do aplicativo instanciado e/ou corrige bugs e fornece uma nova versão do manifesto do serviço.
  2. Um desenvolvedor de aplicativos substitui e parametriza as configurações de configuração e implantação dos serviços consistentes e fornece uma nova versão do manifesto do aplicativo. Em seguida, o desenvolvedor do aplicativo incorpora as novas versões dos manifestos de serviço no aplicativo e fornece uma nova versão do tipo de aplicativo em um pacote de aplicativo atualizado.
  3. Um administrador de aplicativo incorpora a nova versão do tipo de aplicativo no aplicativo de destino atualizando os parâmetros apropriados.
  4. Um operador carrega o pacote de aplicativo atualizado para o armazenamento de imagens de cluster usando o método CopyApplicationPackage ou o cmdlet Copy-ServiceFabricApplicationPackage. O pacote do aplicativo contém o manifesto do aplicativo e a coleção de pacotes de serviço.
  5. Um operador provisiona a nova versão do aplicativo no cluster de destino usando o método ProvisionApplicationAsync, o cmdlet Register-ServiceFabricApplicationType ou a operação Provisionar um aplicativo REST.
  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 Upgrade an Application REST.
  7. Um operador verifica o progresso da atualização usando o método GetApplicationUpgradeProgressAsync, o cmdlet Get-ServiceFabricApplicationUpgrade ou a operação REST Get Application Upgrade Progress.
  8. Se necessário, o operador modifica e reaplica os parâmetros da atualização atual do aplicativo usando o método UpdateApplicationUpgradeAsync, o cmdlet Update-ServiceFabricApplicationUpgrade ou a operação REST Update Application Upgrade.
  9. Se necessário, o operador reverte a atualização atual do aplicativo usando o método RollbackApplicationUpgradeAsync, o cmdlet Start-ServiceFabricApplicationRollback ou a operação REST de Atualização do Aplicativo de Reversão.
  10. O Service Fabric atualiza o aplicativo de destino em execução no cluster sem perder a disponibilidade de nenhum de seus serviços constituintes.

Consulte o tutorial de atualização do aplicativo para obter exemplos.

Manter

  1. Para atualizações e patches do sistema operacional, o Service Fabric faz interface com a infraestrutura do Azure para garantir a disponibilidade de todos os aplicativos em execução no cluster.
  2. Para atualizações e patches para a plataforma do Service Fabric, o Service Fabric se atualiza sem perder a disponibilidade de nenhum dos aplicativos em execução no cluster.
  3. Um administrador de aplicativo aprova a adição ou remoção de nós de um cluster depois de analisar dados históricos 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 nós existentes são removidos do cluster, o Service Fabric equilibra automaticamente a carga 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 Delete Service REST.
  2. Um operador também pode excluir uma instância de aplicativo e todos os seus serviços usando o método DeleteApplicationAsync, o cmdlet Remove-ServiceFabricApplication ou a operação Delete Application REST.
  3. Depois que o aplicativo e os serviços forem interrompidos, o operador poderá desprovisionar o tipo de aplicativo usando o método UnprovisionApplicationAsync, o cmdlet Unregister-ServiceFabricApplicationType ou a operação Unprovision an Application REST. O desprovisionamento do tipo de aplicativo não remove o pacote do aplicativo do ImageStore.
  4. Um operador remove o pacote de aplicativo do ImageStore usando o método RemoveApplicationPackage ou o cmdlet Remove-ServiceFabricApplicationPackage.

Consulte Implantar um aplicativo para obter exemplos.

Preservando espaço em disco no armazenamento de imagens de cluster

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

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

  1. Copie o pacote para o ImageStore e use a opção de compactação

  2. Provisionar o pacote

  3. Remover o pacote no armazenamento de imagens

  4. Atualizar o aplicativo/cluster

  5. Desprovisionar a versão antiga

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

Configuração para limpeza automática

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

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

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

Você pode automatizar a etapa 5 acima usando XML. Isso fará com que os tipos de aplicativos não utilizados sejam automaticamente cancelados.

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

Limpeza de 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ó, os arquivos de uma instância anterior serão mantidos. O mesmo vale para dados de coleções confiáveis usadas por serviços com monitoração de estado. Isto serve o propósito de uma maior disponibilidade. No caso de uma nova instância de aplicativo no mesmo nó, nenhum arquivo deve ser copiado. Para coleções confiáveis, apenas 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 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 armazenamento 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. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage remove binários de instalação de tempo de execução antigos não utilizados.

Nota

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

Próximos passos

Para obter mais informações sobre como desenvolver, testar e gerenciar aplicativos e serviços do Service Fabric, consulte: