Ciclo di vita dell'applicazione Service Fabric

  • Articolo

Analogamente ad altre piattaforme, un'applicazione su Service Fabric di Azure in genere passa attraverso le fasi seguenti: progettazione, sviluppo, test, distribuzione, aggiornamento, manutenzione e rimozione. Service Fabric di Azure offre un supporto di prima categoria per l'intero ciclo di vita delle applicazioni cloud, dallo sviluppo alla distribuzione, alla gestione giornaliera, alla manutenzione e infine alla rimozione delle autorizzazioni. Il modello di servizio abilita diversi ruoli per la partecipazione indipendente al ciclo di vita delle applicazioni. Questo articolo offre una panoramica delle interfacce API e del modo in cui vengono utilizzate dai diversi ruoli nelle fasi del ciclo di vita di un'applicazione di Service Fabric.

Vedere questa pagina per un video di training che descrive come gestire il ciclo di vita dell'applicazione:

Importante

Sono disponibili due utilità dell'interfaccia della riga di comando per interagire con Service Fabric. L'interfaccia della riga di comando di Azure viene usata per gestire le risorse di Azure, ad esempio un cluster di Service Fabric ospitato in Azure. L'interfaccia della riga di comando di Service Fabric viene usata per connettersi direttamente al cluster di Service Fabric (indipendentemente dalla posizione in cui è ospitato) e gestire il cluster, le applicazioni e i servizi.

Ruoli del modello di servizio

I ruoli del modello di servizio sono i seguenti:

  • Sviluppatore di servizi: elabora servizi modulari e generici che possono essere riutilizzati e usati in più applicazioni dello stesso tipo o tipi diversi. Un servizio di accodamento ad esempio può essere usato per creare un'applicazione di controllo di attività e richieste basata su ticket (supporto tecnico) o un'applicazione di e-commerce (carrello acquisti).
  • Sviluppatore di applicazioni: crea applicazioni integrando una raccolta di servizi per soddisfare determinati requisiti o scenari. Un sito Web di e-commerce ad esempio può integrare i servizi "JSON Stateless Front-end Service", "Auction Stateful Service" e "Queue Stateful Service" per creare una soluzione per vendite all'asta.
  • Amministratore di applicazioni: prende decisioni relative alla configurazione (specificando i parametri del modello di configurazione), alla distribuzione (eseguendo il mapping con le risorse disponibili) e alla qualità del servizio delle applicazioni. Un amministratore di applicazioni ad esempio decide le impostazioni locali della lingua (come inglese per gli Stati Uniti o giapponese per Giappone) dell'applicazione. Un'altra applicazione distribuita può avere impostazioni diverse.
  • Operatore: distribuisce le applicazioni in base alla configurazione e ai requisiti specificati dall'amministratore di applicazioni. Un operatore ad esempio effettua il provisioning e la distribuzione dell'applicazione e verifica che sia in esecuzione in Azure. Gli operatori monitorano l'integrità e le informazioni sulle prestazioni delle applicazioni e gestiscono l'infrastruttura fisica a seconda delle esigenze.

Sviluppo

  1. Uno sviluppatore di servizi sviluppa diversi tipi di servizi usando il modello di programmazione Reliable Actors o Reliable Services.
  2. Uno sviluppatore del servizio descrive in modo dichiarativo i tipi di servizi sviluppati in un file manifesto del servizio formato da uno o più codici, configurazioni e pacchetti di dati.
  3. Uno sviluppatore dell'applicazione compila quindi un'applicazione usando tipi di servizi diversi.
  4. Uno sviluppatore dell'applicazione descrive in modo dichiarativo il tipo di applicazione in un'applicazione del servizio facendo riferimento ai manifesti dei servizi costituenti ed eseguendo in modo appropriato l'override e la parametrizzazione di diverse impostazioni di configurazione e distribuzione dei servizi costituenti.

Per gli esempi, vedere gli articoli relativi all'introduzione ai modelli di programmazione Reliable Actors e all'introduzione ai modelli di programmazione Reliable Services.

Distribuisci

  1. Un amministratore di applicazioni personalizza il tipo di applicazione in un'applicazione specifica da distribuire in un cluster di Service Fabric specificando i parametri appropriati dell'elemento ApplicationType nel manifesto dell'applicazione.
  2. Un operatore carica il pacchetto dell'applicazione nell'archivio immagini cluster usando il metodo CopyApplicationPackage o il cmdlet Copy-ServiceFabricApplicationPackage. Il pacchetto applicazione contiene il manifesto dell'applicazione e la raccolta di pacchetti servizio. Service Fabric distribuisce le applicazioni dal relativo pacchetto archiviato nell’archivio immagini, che può essere un archivio BLOB di Azure o un servizio di sistema di Service Fabric.
  3. L'operatore effettua quindi il provisioning del tipo di applicazione nel cluster di destinazione dal pacchetto dell'applicazione caricato usando il metodo ProvisionApplicationAsync, il cmdlet Register-ServiceFabricApplicationType o l'operazione Provisioning di un'applicazione REST.
  4. Dopo aver eseguito il provisioning dell'applicazione, un operatore avvia l'applicazione con i parametri forniti dall'amministratore di applicazioni mediante il metodo CreateApplicationAsync, il cmdlet New-ServiceFabricApplication o l'operazione Create Application REST.
  5. Dopo la distribuzione dell'applicazione, un operatore usa il metodo CreateServiceAsync, il cmdlet New-ServiceFabricService o l'operazione Create Service REST per creare nuove istanze di servizi per l'applicazione in base ai tipi di servizio disponibili.
  6. L'applicazione è ora in esecuzione nel cluster di Service Fabric.

Per gli esempi, vedere l'articolo relativo alla distribuzione di un'applicazione .

Test

  1. Dopo la distribuzione nel cluster di sviluppo locale o in un cluster di test, uno sviluppatore di servizi esegue lo scenario di test di failover predefinito usando le classi FailoverTestScenarioParameters e FailoverTestScenario o il cmdlet Invoke-ServiceFabricFailoverTestScenario. Lo scenario di test di failover esegue un servizio specifico attraverso importanti transizioni e failover per verificare che sia sempre disponibile e funzionante.
  2. Lo sviluppatore di servizi esegue quindi lo scenario di test CHAOS predefinito usando le classi ChaosTestScenarioParameters e ChaosTestScenario o il cmdlet Invoke-ServiceFabricChaosTestScenario. Lo scenario di test CHAOS induce nel cluster più errori casuali di nodi, pacchetti di codice e repliche.
  3. Lo sviluppatore di servizitesta la comunicazione tra servizi creando scenari di test che spostano le repliche primarie nel cluster.

Per altre informazioni, vedere la pagina sull' introduzione al servizio di analisi degli errori .

Aggiornamento

  1. Uno sviluppatore di servizi aggiorna i servizi costituenti dell'applicazione di cui sono state create istanze e/o corregge i bug e fornisce una nuova versione del manifesto del servizio.
  2. Uno sviluppatore di applicazioni esegue l'override e la parametrizzazione delle impostazioni di configurazione e distribuzione dei servizi coerenti e fornisce una nuova versione del manifesto dell'applicazione. Lo sviluppatore di applicazioni incorpora quindi le nuove versioni dei manifesti dei servizi nell'applicazione e fornisce una nuova versione del tipo di applicazione in un pacchetto applicazione aggiornato.
  3. Un amministratore dell'applicazione incorpora la nuova versione del tipo di applicazione nell'applicazione di destinazione aggiornando i parametri appropriati.
  4. Un operatore carica il pacchetto dell'applicazione aggiornato nell'archivio immagini cluster usando il metodo CopyApplicationPackage o il cmdlet Copy-ServiceFabricApplicationPackage. Il pacchetto applicazione contiene il manifesto dell'applicazione e la raccolta di pacchetti servizio.
  5. Un operatore esegue il provisioning della nuova versione dell'applicazione nel cluster di destinazione usando il metodo ProvisionApplicationAsync, il cmdlet Register-ServiceFabricApplicationType o l'operazione Provision an Application REST.
  6. Un operatore aggiorna l'applicazione di destinazione alla nuova versione usando il metodo UpgradeApplicationAsync, il cmdlet Start-ServiceFabricApplicationUpgrade o l'operazione Upgrade an Application REST.
  7. Un operatore controlla lo stato dell'aggiornamento usando il metodo GetApplicationUpgradeProgressAsync, il cmdlet Get-ServiceFabricApplicationUpgrade o l'operazione Get Application Upgrade Progress REST.
  8. Se necessario, l'operatore modifica e riapplica i parametri dell'aggiornamento dell'applicazione corrente usando il metodo UpdateApplicationUpgradeAsync, il cmdlet Update-ServiceFabricApplicationUpgrade o l'operazione Update Application Upgrade REST.
  9. Se necessario, l'operatore esegue il rollback dell'aggiornamento dell'applicazione corrente usando il metodo RollbackApplicationUpgradeAsync, il cmdlet Start-ServiceFabricApplicationRollback o l'operazione Rollback Application Upgrade REST.
  10. Service Fabric aggiorna l'applicazione di destinazione in esecuzione nel cluster senza perdere la disponibilità dei servizi costituenti.

Per gli esempi, vedere l'articolo relativo all' esercitazione sull'aggiornamento di un'applicazione .

Effettuare la manutenzione

  1. Per gli aggiornamenti e le patch del sistema operativo, Service Fabric interagisce con l'infrastruttura di Azure per garantire la disponibilità di tutte le applicazioni in esecuzione nel cluster.
  2. Per gli aggiornamenti e le patch della piattaforma Service Fabric, Service Fabric si aggiorna automaticamente senza perdere la disponibilità delle applicazioni in esecuzione nel cluster.
  3. Un amministratore di applicazioni approva l'aggiunta o la rimozione di nodi da un cluster dopo aver analizzato i dati cronologici di uso della capacità e la proiezione della domanda futura.
  4. Un operatore aggiunge e rimuove i nodi specificati dall'amministratore di applicazioni.
  5. Quando nel cluster vengono aggiunti nuovi nodi o rimossi nodi esistenti, Service Fabric esegue automaticamente il bilanciamento del carico delle applicazioni in esecuzione in tutti i nodi del cluster per ottenere prestazioni ottimali.

Rimuovi

  1. Un operatore può eliminare un'istanza specifica di un servizio in esecuzione nel cluster senza rimuovere l'intera applicazione usando il metodo DeleteServiceAsync, il cmdlet Remove-ServiceFabricService o l'operazione Delete Service REST.
  2. Un operatore può anche eliminare un'istanza di un'applicazione e tutti i relativi servizi usando il metodo DeleteApplicationAsync, il cmdlet Remove-ServiceFabricApplication o l'operazione Delete Application REST.
  3. Dopo che l'applicazione e i servizi sono stati arrestati, l'operatore può annullare il provisioning del tipo di applicazione usando il metodo UnprovisionApplicationAsync, il cmdlet Unregister-ServiceFabricApplicationType o unprovisioning di un'operazione REST dell'applicazione. L'annullamento del provisioning del tipo di applicazione non comporta la rimozione del pacchetto applicazione da ImageStore.
  4. Un operatore rimuove il pacchetto dell'applicazione da ImageStore usando il metodo RemoveApplicationPackage o il cmdlet Remove-ServiceFabricApplicationPackage.

Per gli esempi, vedere l'articolo relativo alla distribuzione di un'applicazione .

Mantenimento dello spazio su disco nell'archivio immagini del cluster

ImageStoreService mantiene i pacchetti copiati e di cui è stato effettuato il provisioning, che possono causare l'accumulo di file. L'accumulo di file può causare il riempimento del disco di ImageStoreService (fabric:/System/ImageStoreService) e può aumentare il tempo di compilazione per le repliche ImageStoreService.

Per evitare l'accumulo di file, usare la sequenza di provisioning seguente:

  1. Copiare il pacchetto in ImageStore e usare l'opzione di compressione

  2. Effettuare il provisioning del pacchetto

  3. Rimuovere il pacchetto nell'archivio immagini

  4. Aggiornare l'applicazione/il cluster

  5. Annullare il provisioning della versione precedente

I passaggi 3 e 5 nella procedura precedente impediscono l'accumulo di file nell'archivio immagini.

Configurazione per la pulizia automatica

È possibile automatizzare il passaggio 3 precedente usando PowerShell o XML. In questo modo il pacchetto dell'applicazione verrà eliminato automaticamente dopo la corretta registrazione del tipo di applicazione.

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

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

È possibile automatizzare il passaggio 5 precedente usando XML. In questo modo i tipi di applicazione inutilizzati verranno annullati automaticamente.

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

Pulizia di file e dati nei nodi

La replica dei file dell'applicazione distribuirà infine i file a tutti i nodi a seconda delle azioni di bilanciamento. Ciò può creare una pressione su disco a seconda del numero di applicazioni e delle relative dimensioni del file. Anche quando non è in esecuzione alcuna istanza attiva in un nodo, i file di un'istanza precedente verranno mantenuti. Lo stesso vale per i dati provenienti da raccolte reliable usate dai servizi con stato. Questo serve allo scopo di una disponibilità più elevata. Nel caso di una nuova istanza dell'applicazione nello stesso nodo, non è necessario copiare alcun file. Per le raccolte affidabili, è necessario replicare solo il delta.

Per rimuovere completamente i file binari dell'applicazione, è necessario annullare la registrazione del tipo di applicazione.

Raccomandazioni per ridurre la pressione del disco:

  1. Remove-ServiceFabricApplicationPackage rimuove il pacchetto dal percorso di caricamento temporaneo.
  2. Unregister-ServiceFabricApplicationType rilascia spazio di archiviazione rimuovendo i file del tipo di applicazione dal servizio archivio immagini e da tutti i nodi. Gestione eliminazione viene eseguita ogni ora per impostazione predefinita.
  3. CleanupUnusedApplicationTypes pulisce automaticamente le versioni precedenti dell'applicazione inutilizzate. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage rimuove i file binari di installazione di runtime inutilizzati precedenti.

Nota

Una funzionalità è in fase di sviluppo per consentire a Service Fabric di eliminare le cartelle dell'applicazione dopo che l'applicazione viene evacuata dal nodo.

Passaggi successivi

Per altre informazioni sullo sviluppo, il test e la gestione di applicazioni e servizi di Service Fabric, vedere: