Životní cyklus aplikace Service Fabric

  • Článek

Stejně jako u jiných platforem prochází aplikace v Azure Service Fabric obvykle 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 úplný životní cyklus cloudových aplikací, od vývoje přes 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í na životním cyklu aplikace. Tento článek obsahuje přehled rozhraní API a jejich používání 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 aplikace:

Důležité

Pro práci se Service Fabric se používají dva nástroje rozhraní příkazového řádku. Azure CLI se používá ke správě prostředků Azure, jako je cluster Service Fabric hostovaný v Azure. Rozhraní příkazového řádku Service Fabric se používá k přímému připojení ke clusteru Service Fabric (bez ohledu na to, kde je hostovaný) a ke správě clusteru, aplikací a služeb.

Role modelu služby

Role modelu služby jsou:

  • Vývojář služeb: Vyvíjí modulární a obecné služby, které lze znovu použít a použít ve více aplikacích stejného typu nebo různých typů. Službu fronty můžete například použít k vytvoření aplikace pro vytváření lístků (helpdesk) nebo aplikace elektronického obchodování (nákupní košík).
  • Vývojář aplikací: Vytváří aplikace integrací kolekce služeb pro splnění určitých specifických požadavků nebo scénářů. Web elektronického obchodování může například integrovat "JSON Stateless Front-End Service", "Auction Stateful Service" a "Queue Stateful Service" za účelem vytvoření aukčního řešení.
  • Správce aplikace: Rozhoduje o konfiguraci aplikace (vyplnění parametrů šablony konfigurace), nasazení (mapování na dostupné prostředky) a kvalitě služby. Správce aplikace například rozhodne o národním prostředí aplikace (angličtina pro USA nebo japonština pro Japonsko). Jiná nasazená aplikace může mít různá nastavení.
  • Operátor: Nasadí aplikace na základě konfigurace aplikace a požadavků zadaných správcem aplikace. Operátor například zřídí a nasadí aplikaci a zajistí, že běží v Azure. Operátoři monitorují informace o stavu a výkonu aplikací a podle potřeby udržují fyzickou infrastrukturu.

Vývoj

  1. Vývojář služeb 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 sestaví aplikaci pomocí 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ématech Začínáme se 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ů elementu ApplicationType v manifestu aplikace.
  2. Operátor odešle 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í, kterým 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 Rest zřízení aplikace.
  4. Po zřízení aplikace operátor spustí aplikaci s parametry zadanými správcem aplikace pomocí metody CreateApplicationAsync, rutiny New-ServiceFabricApplication nebo operace Create Application REST.
  5. Po nasazení aplikace operátor použije 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 vývojář služby spustí integrovaný testovací scénář 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í spustí 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ář testu chaosu pomocí tříd ChaosTestScenarioParameters a ChaosTestScenario nebo rutiny Invoke-ServiceFabricChaosTestScenario. Scénář testu chaosu náhodně indukuje do clusteru více uzlů, balíčků kódu a replik.
  3. Vývojář službytestuje komunikaci mezi službami vytvořením testovacích scénářů, které přesunují primární repliky kolem clusteru.

Další informace najdete v tématu Úvod do služby Fault Analysis Service .

Upgrade

  1. Vývojář služby aktualizuje základní služby aplikace s instancí 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 aplikace REST.
  7. Operátor kontroluje 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 provede parametry aktuálního upgradu aplikace pomocí metody UpdateApplicationUpgradeAsync, rutiny Update-ServiceFabricApplicationUpgrade nebo operace REST Update Application Upgrade.
  9. V případě potřeby operátor vrátí zpět aktuální upgrade aplikace pomocí metody RollbackApplicationUpgradeAsync, rutiny Start-ServiceFabricApplicationRollback nebo operace REST pro vrácení zpět.
  10. Service Fabric upgraduje cílovou aplikaci spuštěnou v clusteru, aniž by ztratila dostupnost některé z jejích základních služeb.

Příklady najdete v kurzu k upgradu aplikací .

Údržba

  1. V případě upgradů a oprav operačního systému Service Fabric spolupracuje s infrastrukturou Azure, aby byla zajištěna dostupnost všech aplikací spuštěných v clusteru.
  2. V případě upgradů a oprav platformy Service Fabric se Service Fabric upgraduje sám, aniž by se ztratila dostupnost jakékoli 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 se odeberou existující uzly, Service Fabric automaticky vyrovnává zatížení spuštěných aplikací napříč všemi uzly v clusteru, aby bylo dosaženo 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 REST Delete Service.
  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, rutiny Unregister-ServiceFabricApplicationType nebo zrušení zřízení operace REST aplikace. Zrušením zřízení typu aplikace se neodebere balíček aplikace z imageStore.
  4. Operátor odebere balíček aplikace z imageStore pomocí metody RemoveApplicationPackage nebo rutiny Remove-ServiceFabricApplicationPackage.

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 nahromadění souborů. Akumulace souborů může způsobit, že imageStoreService (fabric:/System/ImageStoreService) zaplní disk a může prodloužit dobu sestavení pro repliky ImageStoreService.

Pokud chcete zabránit kumulaci souborů, použijte následující posloupnost zřizování:

  1. Zkopírujte balíček do ImageStore a použijte možnost komprese.

  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ýše uvedeného postupu brání kumulaci souborů v úložišti imagí.

Konfigurace pro automatické č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>

Výše uvedený krok 5 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>

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

Replikace souborů aplikace nakonec distribuuje 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 není spuštěná žádná aktivní instance, soubory z bývalé instance se zachovají. Totéž platí pro data ze spolehlivých kolekcí používaných stavovým službami. To slouží k vyšší dostupnosti. V případě nové instance aplikace na stejném uzlu se nesmí kopírovat žádné soubory. U spolehlivých kolekcí musí být replikována pouze rozdílová hodnota.

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. Unregister-ServiceFabricApplicationType uvolní prostor úložiště odebráním souborů typu aplikace ze služby úložiště imagí a všech uzlů. Ve výchozím nastavení se správce odstraňování spouští každou hodinu.
  3. CleanupUnusedApplicationTypes automaticky vyčistí staré nepoužívané verze aplikací. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage odebere staré nepoužívané binární soubory instalace modulu runtime.

Poznámka

Ve vývoji je funkce, která service Fabricu umožňuje odstranit složky aplikací, jakmile je aplikace evakuována z uzlu.

Další kroky

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