Životní cyklus aplikace Service Fabric

Stejně jako u jiných platforem obvykle aplikace v Azure Service Fabric prochází následujícími fázemi: návrh, vývoj, testování, nasazení, upgrade, údržba a odebrání. Service Fabric poskytuje prvotřídní podporu pro celý životní cyklus aplikací cloudu, od vývoje po nasazení, každodenní správu a údržbu až po případné vyřazení z provozu. Model služby umožňuje nezávislé účasti několika různých rolí v životním cyklu aplikace. Tento článek obsahuje přehled rozhraní API a jejich použití různými rolemi v průběhu fází životního cyklu aplikace Service Fabric.

Na této stránce najdete školicí video, které popisuje, jak spravovat životní cyklus vaší aplikace:

Role modelu služby

Role modelu služby jsou:

• Vývojář služeb: Vyvíjí modulární a obecné služby, které lze změnit a použít v několika aplikacích stejného typu nebo různých typů. Službu fronty lze například použít k vytvoření aplikace lístků (helpdesk) nebo aplikace elektronického obchodování (nákupní košík).
• Vývojář aplikací: Vytváří aplikace integrací kolekce služeb, aby splňovaly určité konkrétní požadavky nebo scénáře. Například web elektronického obchodování může integrovat "bezstavovou front-endovou službu JSON", "aukční stavovou službu" a "stavovou službu fronty", aby se vytvořilo řešení pro aukci.
• Správce aplikace: Rozhoduje o konfiguraci aplikace (vyplňování parametrů šablony konfigurace), nasazení (mapování na dostupné prostředky) a kvalitě služby. Správce aplikace například rozhodne národní prostředí jazyka (angličtina pro USA nebo japonštinu pro Japonsko, například) aplikace. Jiná nasazená aplikace může mít různá nastavení.
• Operátor: Nasadí aplikace na základě konfigurace aplikace a požadavků určených správcem aplikace. Operátor například zřídí a nasadí aplikaci a zajistí, že běží v Azure. Operátoři monitorují stav aplikace a informace o výkonu a podle potřeby udržují fyzickou infrastrukturu.

Vývoj

1. Vývojář služby vyvíjí různé typy služeb pomocí programovacího modelu Reliable Actors nebo Reliable Services.
2. Vývojář služby deklarativní popisuje vyvinuté typy služeb v souboru manifestu služby, který se skládá z jednoho nebo více kódů, konfigurace a datových balíčků.
3. Vývojář aplikace pak vytvoří aplikaci s použitím různých typů služeb.
4. Vývojář aplikace deklarativní popisuje typ aplikace v manifestu aplikace odkazováním na manifesty služby základních služeb a odpovídajícím přepsáním a parametrizací různých nastavení konfigurace a nasazení základních služeb.

Příklady najdete v tématu Začínáme s Reliable Actors a Začínáme se Reliable Services .

Nasadit

1. Správce aplikace přizpůsobí typ aplikace konkrétní aplikaci, která se má nasadit do clusteru Service Fabric zadáním příslušných parametrů prvku ApplicationType v manifestu aplikace.
2. Operátor nahraje balíček aplikace do úložiště imagí clusteru pomocí metody CopyApplicationPackage nebo rutiny Copy-ServiceFabricApplicationPackage. Balíček aplikace obsahuje manifest aplikace a kolekci balíčků služeb. Service Fabric nasazuje aplikace z balíčku aplikace uloženého v úložišti imagí, což může být úložiště objektů blob Azure nebo systémová služba Service Fabric.
3. Operátor pak zřídí typ aplikace v cílovém clusteru z nahraného balíčku aplikace pomocí metody ProvisionApplicationAsync, rutiny Register-ServiceFabricApplicationType nebo operace Zřízení rest aplikace.
4. Po zřízení aplikace spustí operátor aplikaci s parametry zadanými správcem aplikace pomocí metody CreateApplicationAsync, rutiny New-ServiceFabricApplication nebo operace Create Application REST.
5. Po nasazení aplikace použije operátor metodu CreateServiceAsync, rutinu New-ServiceFabricService nebo operaci Create Service REST k vytvoření nových instancí služby pro aplikaci na základě dostupných typů služeb.
6. Aplikace je teď spuštěná v clusteru Service Fabric.

Příklady najdete v tématu Nasazení aplikace .

Test

1. Po nasazení do místního vývojového clusteru nebo testovacího clusteru spustí vývojář služby integrovaný scénář testu převzetí služeb při selhání pomocí tříd FailoverTestScenarioParameters a FailoverTestScenario nebo rutiny Invoke-ServiceFabricFailoverTestScenario. Scénář testu převzetí služeb při selhání spouští zadanou službu prostřednictvím důležitých přechodů a převzetí služeb při selhání, aby se zajistilo, že je stále dostupná a funkční.
2. Vývojář služby pak spustí předdefinovaný scénář testování chaosu pomocí tříd ChaosTestScenarioParameters a ChaosTestScenario nebo rutiny Invoke-ServiceFabricChaosTestScenario. Scénář testování chaosu náhodně indukuje do clusteru několik uzlů, balíčků kódu a chyb repliky.
3. Vývojář služby testuje komunikaci mezi službami vytvořením testovacích scénářů, které přesouvají primární repliky kolem clusteru.

Další informace najdete v tématu Úvod do služby Analýza chyb.

Upgrade

1. Vývojář služby aktualizuje základní služby instance aplikace nebo opravuje chyby a poskytuje novou verzi manifestu služby.
2. Vývojář aplikace přepíše a parametrizuje nastavení konfigurace a nasazení konzistentních služeb a poskytuje novou verzi manifestu aplikace. Vývojář aplikace pak do aplikace začlení nové verze manifestů služby a poskytne novou verzi typu aplikace v aktualizovaném balíčku aplikace.
3. Správce aplikace začlení novou verzi typu aplikace do cílové aplikace aktualizací příslušných parametrů.
4. Operátor nahraje aktualizovaný balíček aplikace do úložiště imagí clusteru pomocí metody CopyApplicationPackage nebo rutiny Copy-ServiceFabricApplicationPackage. Balíček aplikace obsahuje manifest aplikace a kolekci balíčků služeb.
5. Operátor zřídí novou verzi aplikace v cílovém clusteru pomocí metody ProvisionApplicationAsync, rutiny Register-ServiceFabricApplicationType nebo operace Provision an Application REST.
6. Operátor upgraduje cílovou aplikaci na novou verzi pomocí metody UpgradeApplicationAsync, rutiny Start-ServiceFabricApplicationUpgrade nebo operace Upgrade aplikační rest.
7. Operátor zkontroluje průběh upgradu pomocí metody GetApplicationUpgradeProgressAsync, rutiny Get-ServiceFabricApplicationUpgrade nebo operace REST get Application Upgrade Progress.
8. V případě potřeby operátor upraví a znovu použije parametry aktuálního upgradu aplikace pomocí metody UpdateApplicationUpgradeAsync, rutiny Update-ServiceFabricApplicationUpgrade nebo operace Update Application Upgrade REST.
9. V případě potřeby vrátí operátor zpět aktuální upgrade aplikace pomocí metody RollbackApplicationUpgradeAsync, rutiny Start-ServiceFabricApplicationRollback nebo operace Rest upgradu aplikace rollback.
10. Service Fabric upgraduje cílovou aplikaci spuštěnou v clusteru bez ztráty dostupnosti žádné ze svých základních služeb.

Příklady najdete v kurzu upgradu aplikace.

Údržba

1. Pro upgrady a opravy operačního systému service Fabric zajišťuje rozhraní Service Fabric s infrastrukturou Azure, která zaručuje dostupnost všech aplikací spuštěných v clusteru.
2. Pro upgrady a opravy platformy Service Fabric se Service Fabric upgraduje sám, aniž by se ztratila dostupnost žádné aplikace spuštěné v clusteru.
3. Správce aplikace schválí přidání nebo odebrání uzlů z clusteru po analýze historických dat o využití kapacity a předpokládané budoucí poptávce.
4. Operátor přidá a odebere uzly určené správcem aplikace.
5. Když se do clusteru přidají nové uzly nebo existující uzly odeberou, Service Fabric automaticky vyrovnává zatížení spuštěných aplikací napříč všemi uzly v clusteru, aby dosáhla optimálního výkonu.

Odebrat

1. Operátor může odstranit konkrétní instanci spuštěné služby v clusteru bez odebrání celé aplikace pomocí metody DeleteServiceAsync, rutiny Remove-ServiceFabricService nebo operace DELETE Service REST.
2. Operátor může také odstranit instanci aplikace a všechny její služby pomocí metody DeleteApplicationAsync, rutiny Remove-ServiceFabricApplication nebo operace Delete Application REST.
3. Jakmile se aplikace a služby zastaví, operátor může zrušit zřízení typu aplikace pomocí metody UnprovisionApplicationAsync, unregister-ServiceFabricApplicationType nebo unprovision an Application REST operation. Zrušení zřízení typu aplikace neodebere balíček aplikace z ImageStore.
4. Operátor odebere balíček aplikace z ImageStore pomocí Metody RemoveApplicationPackage nebo Remove-ServiceFabricApplicationPackage rutiny.

Příklady najdete v tématu Nasazení aplikace .

Zachování místa na disku v úložišti imagí clusteru

ImageStoreService uchovává zkopírované a zřízené balíčky, což může vést k akumulace souborů. Akumulace souborů může způsobit, že imageStoreService (fabric:/System/ImageStoreService) zaplní disk a zvýší čas sestavení pro repliky ImageStoreService.

Pokud se chcete vyhnout akumulace souborů, použijte následující sekvenci zřizování:

1. Kopírování balíčku do ImageStore a použití možnosti komprimace

2. Zřízení balíčku

3. Odebrání balíčku v úložišti imagí

4. Upgrade aplikace nebo clusteru

5. Zrušení zřízení staré verze

Kroky 3 a 5 v postupu výše brání akumulace souborů v úložišti imagí.

Konfigurace pro automatické vyčištění

Výše uvedený krok 3 můžete automatizovat pomocí PowerShellu nebo XML. To způsobí, že se balíček aplikace po úspěšné registraci typu aplikace automaticky odstraní.

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

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

Krok 5 výše můžete automatizovat pomocí XML. To způsobí, že se nepoužívané typy aplikací automaticky zruší registrace.

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

Vyčištění souborů a dat na uzlech

Replikace souborů aplikace bude nakonec distribuovat soubory do všech uzlů v závislosti na akcích vyrovnávání. To může vytvořit tlak na disk v závislosti na počtu aplikací a jejich velikosti souboru. I když na uzlu neběží žádná aktivní instance, budou soubory z bývalé instance zachovány. Totéž platí pro data ze spolehlivých kolekcí používaných stavovými službami. Slouží k zajištění vyšší dostupnosti. V případě nové instance aplikace na stejném uzlu se nesmí kopírovat žádné soubory. U spolehlivých kolekcí se musí replikovat pouze rozdíl.

Pokud chcete binární soubory aplikace úplně odebrat, musíte zrušit registraci typu aplikace.

Doporučení ke snížení zatížení disku:

1. Remove-ServiceFabricApplicationPackage odebere balíček z dočasného umístění pro nahrání.
2. Zrušení registrace ServiceFabricApplicationType uvolní prostor úložiště odebráním souborů typu aplikace ze služby úložiště i všech uzlů. Správce odstranění běží každou hodinu za výchozí.
3. CleanupUnusedApplicationTypes automaticky vyčistí staré nepoužívané verze aplikace.

   {
     "name": "Management",
     "parameters": [
       {
         "name": "CleanupUnusedApplicationTypes",
         "value": true
       },
       {
         "name": "MaxUnusedAppTypeVersionsToKeep",
         "value": "3"
       }
     ]
   }
   

4. Remove-ServiceFabricClusterPackage odebere staré binární soubory instalace nepoužívaného modulu runtime.

Další kroky

Další informace o vývoji, testování a správě aplikací a služeb Service Fabric najdete v tématech:

• Reliable Actors
• Reliable Services
• Nasazení aplikace
• Upgrade aplikací
• Přehled testovatelnosti