Přemístění služeb Aplikace Azure services do jiné oblasti

Článek
10/17/2024

Tento článek popisuje, jak přesunout prostředky služby App Service do jiné oblasti Azure.

Existují různé důvody, proč můžete chtít přesunout existující prostředky Azure z jedné oblasti do jiné. Možná budete chtít:

Využijte výhod nové oblasti Azure.
Nasaďte funkce nebo služby dostupné pouze v konkrétních oblastech.
Splnění interních zásad a požadavků zásad správného řízení
Sladění s fúzemi a akvizicemi společností
Splnění požadavků na plánování kapacity

Prostředky služby App Service jsou specifické pro jednotlivé oblasti a nedají se přesouvat mezi oblastmi. V cílové oblasti musíte vytvořit kopii existujících prostředků služby App Service a pak přemístit obsah do nové aplikace. Pokud vaše zdrojová aplikace používá vlastní doménu, můžete ji po dokončení přemístění migrovat do nové aplikace v cílové oblasti .

Pokud chcete usnadnit kopírování aplikace, můžete zálohovat a obnovovat jednotlivé aplikace app Service do plánu služby App Service v jiné oblasti.

Požadavky

Ujistěte se, že je aplikace App Service v oblasti Azure, ze které chcete přesunout.
Ujistěte se, že cílová oblast podporuje službu App Service a všechny související služby, jejichž prostředky chcete přesunout.
Ověřte, že existuje dostatečná oprávnění k nasazení prostředků služby App Service do cílového předplatného a oblasti.
Ověřte, jestli jsou nějaké zásady Azure přiřazené s omezením oblasti.
Vezměte v úvahu všechny provozní náklady, protože ceny výpočetních prostředků se můžou lišit od oblasti po oblast. Pokud chcete odhadnout možné náklady, přečtěte si cenovou kalkulačku.

Příprava

Identifikujte všechny prostředky služby App Service, které aktuálně používáte. Příklad:

Některé prostředky, jako jsou importované certifikáty nebo hybridní připojení, obsahují integraci s jinými službami Azure. Informace o přesunu těchto prostředků mezi oblastmi najdete v dokumentaci příslušných služeb.

Plánování

Tato část je kontrolní seznam pro plánování v následujících oblastech:

Stav, úložiště a podřízené závislosti
Certifikáty
Konfigurace
Připojení virtuální sítě / vlastní názvy / DNS
Identity
Koncové body služby

Stav, úložiště a podřízené závislosti

Určete, jestli je vaše aplikace App Service stavová nebo bezstavová. I když doporučujeme, aby aplikace App Service Byly bezstavové a soubory na %HOME%\site jednotce by měly být jenom ty, které jsou potřeba ke spuštění nasazené aplikace s libovolnými dočasnými soubory, je stále možné uložit stav aplikace runtime na %HOME%\site virtuální jednotce. Pokud vaše aplikace zapisuje stav na cestě ke sdílenému úložišti aplikace, nezapomeňte naplánovat, jak budete tento stav spravovat během přesunu prostředků.

Tip

Pomocí Kudu můžete společně s přístupem k portálu poskytnout rozhraní API pro přístup k souborům (VFS) umožňující čtení a zápis souborů v adresáři %HOME%\site . Další informace najdete na wikiwebu Kudu.
Zkontrolujte interní ukládání do mezipaměti a stav v kódu aplikace.
Zakažte nastavení spřažení relace. Pokud je to možné, doporučujeme zakázat nastavení spřažení relace. Zakázání spřažení relace zlepšuje vyrovnávání zatížení pro horizontální horizontální navýšení kapacity. Jakýkoliv interní stav může mít vliv na plánování snižování zatížení – zejména v případě, že je požadavkem nulový časový limit. Pokud je to možné, může být užitečné refaktorovat jakýkoli stav aplikace, aby aplikace byla bezstavová při přípravě na přesun.
Analýza databázových připojovací řetězec Databázové připojovací řetězec najdete v nastavení aplikace. Mohou však být také pevně zakódované nebo spravované v konfiguračních souborech, které jsou dodávány s aplikací. Analyzujte a naplánujte migraci a replikaci dat jako součást plánování vyšší úrovně pro přesun úlohy. U chatovacích nebo latencí kritických aplikací není aplikace v cílové oblasti výkonná, aby se vrátila ke zdrojům dat ve zdrojové oblasti.
Analýza externí mezipaměti (například Redis) Mezipaměti aplikací by měly být nasazeny co nejblíže aplikaci. Analyzujte, jak se naplní mezipaměti, zásady vypršení platnosti nebo vyřazení a jakýkoli dopad na studenou mezipaměť může mít u prvních uživatelů přístup k úloze po přerušení.
Analýza a plánování závislostí rozhraní API (nebo aplikací) komunikace mezi oblastmi je výrazně méně výkonná, pokud se aplikace v cílové oblasti vrátí zpět ke závislostem, které jsou stále ve zdrojové oblasti. V rámci přemístění úloh doporučujeme přemístit všechny podřízené závislosti. *místní* prostředky jsou však výjimkou, zejména prostředky, které jsou geograficky blíže cílové oblasti (jak se může jednat o scénáře opakování).

Azure Container Registry může být podřízená závislost (runtime) pro službu App Service, která je nakonfigurovaná tak, aby běžela proti vlastním imagím kontejnerů. Dává smysl, aby služba Container Registry byla ve stejné oblasti jako samotná aplikace. Zvažte nahrání požadovaných imagí do nové služby ACR v cílové oblasti get. Jinak zvažte použití funkce geografické replikace, pokud plánujete zachovat image ve zdrojové oblasti.
Analyzujte a naplánujte regionální služby. Data Application Insights a Log Analytics jsou regionální služby. Zvažte vytvoření nového úložiště Application Insights a Log Analytics v cílové oblasti. U App Insights má nový prostředek vliv také na připojovací řetězec, které je potřeba aktualizovat v rámci změny v App Configuration.

Certifikáty

Prostředky certifikátu služby App Service je možné přesunout do nové skupiny prostředků nebo předplatného, ale ne napříč oblastmi. Certifikáty, které je možné exportovat, je možné importovat také do aplikace nebo do služby Key Vault v nové oblasti. Tento proces exportu a importu je ekvivalentem přesunu mezi oblastmi.

Při plánování přemístění služeb je potřeba vzít v úvahu různé typy certifikátů:

Typ certifikátu	Exportovatelný	Komentáře
Spravovaná služba App Service	No	Znovu vytvořte tyto certifikáty v nové oblasti.
Spravovaná služba Azure Key Vault	Ano	Tyto certifikáty je možné exportovat ze služby Key Vault a pak je importovat do služby Key Vault v nové oblasti.
Privátní klíč (samospravovaný)	Ano	Certifikáty, které jste získali mimo Azure, je možné exportovat ze služby App Service a pak je importovat do nové aplikace nebo do služby Key Vault v nové oblasti.
Veřejný klíč	No	Aplikace může mít certifikáty jenom s veřejným klíčem a bez tajného klíče, které se používají pro přístup k jiným zabezpečeným koncovým bodům. Získejte požadované soubory certifikátu veřejného klíče a naimportujte je do aplikace v nové oblasti.

Další body, které je potřeba vzít v úvahu:

Adresy přiřazené aplikací, kde je připojení SSL aplikace služby App Service vázané na konkrétní určenou IP adresu, se dá použít k volání z sítí třetích stran do služby App Service. Například síť nebo správce IT může chtít uzamknout odchozí volání z místní sítě nebo virtuální sítě, aby používal statickou, dobře známou adresu. Pokud je například používána funkce Přiřazená adresa aplikace, musí být pro volající do aplikace kontrolována a informována o nové adrese upstreamová pravidla brány firewall , jako jsou interní, externí nebo třetí strany. Pravidla brány firewall můžou být interní, externí nebo třetí strany, jako jsou partneři nebo dobře známí zákazníci.
Zvažte jakékoli upstreamové síťové virtuální zařízení (NVA) nebo reverzní proxy server. Konfigurace síťového virtuálního zařízení může být potřeba změnit, pokud přepisujete hlavičku hostitele nebo ukončování protokolu SSL.

Poznámka:

App Service Environment je jediná nabídka služby App Service, která umožňuje podřízená volání podřízených aplikací přes SSL, kde ssl spoléhá na certifikáty podepsané svým držitelem nebo PKI s využitím nestandardních certifikátů kořenové certifikační autority. Služba s více tenanty neposkytuje zákazníkům přístup k nahrání do důvěryhodného úložiště certifikátů.

App Service Environment dnes neumožňuje nákup certifikátů SSL, pouze přineste si vlastní certifikáty. IP-SSL není možné (a nedává smysl), ale SNI je. Interní prostředí App Service Environment by nebylo přidruženo k veřejné doméně, a proto musí zákazník poskytnout certifikáty SSL a jsou proto přenositelné, například certifikáty pro interní použití vygenerované pomocí infrastruktury veřejných klíčů. App Service Environment v3 v externím režimu sdílí stejné funkce jako běžná víceklientová služba App Service.

Konfigurace

Snímek stávajícího nastavení aplikace a připojovací řetězec můžete zachytit na webu Azure Portal. Rozbalte proměnné prostředí nastavení>, v části Nastavení aplikace nebo Připojovací řetězce vyberte Upřesnit úpravy a uložte výstup JSON, který obsahuje existující nastavení nebo připojení. Tato nastavení je potřeba znovu vytvořit v nové oblasti, ale samotné hodnoty se pravděpodobně změní v důsledku následných změn oblastí v připojených službách.
Existující odkazy služby Key Vault se nedají exportovat přes geografickou hranici Azure. Je nutné znovu vytvořit všechny požadované odkazy v nové oblasti.
Konfiguraci aplikace může spravovat Aplikace Azure Konfigurace nebo jiná centrální (podřízená) databáze. Zkontrolujte libovolné úložiště app Configuration store nebo podobná úložiště pro prostředí a nastavení specifická pro danou oblast, která můžou vyžadovat úpravy.

Nezapomeňte zkontrolovat konfiguraci souboru disku, která může nebo nemusí být přepsána nastavením aplikace.

Připojení virtuální sítě / vlastní názvy / DNS

App Service Environment je služba jednoho tenanta vložená do virtuální sítě. Sítě služby App Service Environment se liší od víceklientské služby App Service, která vyžaduje jednu nebo obě privátní koncové body nebo regionální integraci virtuální sítě. Mezi další možnosti, které se můžou přehrávat, patří starší verze integrace virtuální sítě VPN založené na P2S a hybridní připojení (služba Azure Relay).

Poznámka:

Sítě ASEv3 jsou zjednodušené – provoz služby Azure Management a prostředí App Service Environment vlastní podřízené závislosti nejsou viditelné pro zákaznickou virtuální síť, což výrazně zjednodušuje konfiguraci potřebnou pro použití vynuceného tunelu pro veškerý provoz nebo odesílání podmnožinu odchozích přenosů prostřednictvím síťového virtuálního zařízení nebo brány firewall.

Hybridní připojení (Azure Relay) jsou regionální. Pokud se používají hybridní připojení a přestože je možné obor názvů služby Azure Relay přesunout do jiné oblasti, bylo by jednodušší znovu nasadit hybridní připojení (ujistěte se, že je hybridní připojení nastavené v nové oblasti pro nasazení cílových prostředků) a znovu ho propojte s Správce hybridního připojení. Umístění Správce hybridního připojení by se mělo pečlivě zvážit.
Postupujte podle strategie pro aktivní pohotovostní oblast. Před přemístěním prostředků se ujistěte, že jsou k dispozici základní sítě a připojení, centrální síť, řadiče domény, DNS, VPN nebo Express Route atd..
Ověřte všechny nadřazené nebo podřízené seznamy ACL a konfiguraci sítě. Představte si například externí podřízenou službu, která povoluje jenom provoz vaší aplikace. Přemístění do nového plánu aplikace pro víceklientských služeb App Service by pak také bylo změnou odchozích IP adres.
Ve většině případů je nejlepší zajistit, aby virtuální sítě cílové oblasti měly jedinečný adresní prostor. Jedinečný adresní prostor usnadňuje připojení virtuální sítě, pokud je třeba k replikaci dat. Proto v těchto scénářích existuje implicitní požadavek na změnu:
- Privátní DNS
- Jakákoli pevně zakódovaná nebo externí konfigurace, která odkazuje na prostředky podle IP adresy (bez názvu hostitele)
- Seznamy ACL sítě včetně skupin zabezpečení sítě a konfigurace brány firewall (zvažte také dopad na místní síťové virtuální zařízení).
- Všechna pravidla směrování, směrovací tabulky definované uživatelem
Nezapomeňte také zkontrolovat konfiguraci, včetně oblastí konkrétních rozsahů IP adres nebo značek služeb, pokud se budou předávat stávající prostředky nasazení DevOps.
Pro privátní DNS nasazené zákazníkem je potřeba méně změn, které jsou nakonfigurované tak, aby předávaly do Azure pro domény Azure a privátní zóny Azure DNS. Vzhledem k tomu, že privátní koncové body jsou založené na plně kvalifikovaném názvu domény prostředku a často se jedná o název prostředku (který se může v cílové oblasti lišit), nezapomeňte křížovou kontrolu konfigurace ověřit, že plně kvalifikované názvy domén odkazované v konfiguraci se odpovídajícím způsobem aktualizují.
Znovu vytvořte privátní koncové body, pokud se používají v cílové oblasti. Totéž platí pro místní integraci virtuální sítě.
DNS pro App Service Environment se obvykle spravuje prostřednictvím privátního vlastního řešení DNS zákazníků (pro jednotlivé aplikace je k dispozici ruční přepsání nastavení). App Service Environment poskytuje nástroj pro vyrovnávání zatížení pro příchozí a výchozí přenos dat, zatímco Služba App Service sama filtruje hlavičky hostitele. Proto lze více vlastních názvů odkazovat na stejný koncový bod příchozího přenosu dat služby App Service Environment. App Service Environment nevyžaduje ověření domény.

Poznámka:

Koncový bod Kudu pro App Service Environment v3 je k dispozici pouze na adrese {resourcename}.scm.{asename}.appserviceenvironment.net. Další informace o DNS a sítích služby App Service Environment v3 najdete v tématu Sítě služby App Service Environment.

V případě služby App Service Environment vlastní zákazník směrování, a proto prostředky používané pro přímé přesměrování. Všude, kde je povolený přístup k prostředí App Service Environment externě – obvykle prostřednictvím síťového virtuálního zařízení vrstvy 7 nebo reverzního proxy serveru – Traffic Manageru nebo služby Azure Front Door nebo jiné služby globálního vyrovnávání zatížení L7, je možné použít.
Pro veřejnou víceklientovou verzi služby se pro koncové body roviny dat zřizuje výchozí název {resourcename}.azurewebsites.net spolu s výchozím názvem koncového bodu Kudu (SCM). Vzhledem k tomu, že služba ve výchozím nastavení poskytuje veřejný koncový bod, musí být vazba ověřena, aby bylo možné prokázat vlastnictví domény. Po vytvoření vazby se ale nevyžaduje opětovné ověření ani není nutné, aby veřejné záznamy DNS ukazovaly na koncový bod služby App Service.
Pokud používáte vlastní doménu, vytvořte vazbu předem na cílovou aplikaci. Ověřte a povolte doménu v cílové aplikaci.

Identity

Potřebujete znovu vytvořit všechny spravované identity přiřazené systémem společně s vaší aplikací v nové cílové oblasti. Obvykle se automaticky vytvořená aplikace Microsoft Entra ID, kterou používá EasyAuth, standardně používá název prostředku aplikace.
Spravované identity přiřazené uživatelem se také nedají přesouvat mezi oblastmi. Pokud chcete zachovat spravované identity přiřazené uživatelem ve stejné skupině prostředků s vaší aplikací, musíte je znovu vytvořit v nové oblasti. Další informace najdete v tématu Přemístění spravovaných identit pro prostředky Azure do jiné oblasti.
Udělte spravovaným identitám stejná oprávnění ve vašich přemíscených službách jako původní identity, které nahrazují, včetně členství ve skupinách.

Naplánujte přemístění zprostředkovatele identity (IDP) do cílové oblasti. I když microsoft Entra ID je globální služba, některá řešení spoléhají na místní (nebo podřízené místní) IDP.
Aktualizujte všechny prostředky do služby App Service, které se můžou spoléhat na přihlašovací údaje Kudu FTP.

Koncové body služby

Koncové body služby virtuální sítě pro Aplikace Azure Služba omezují přístup k zadané virtuální síti. Koncové body můžou také omezit přístup k seznamu rozsahů adres IPv4 (protokol IPv4 verze 4). Přístup byl odepřen všem uživatelům, kteří se připojují ke službě Event Hubs mimo tyto zdroje. Pokud byly koncové body služby nakonfigurované ve zdrojové oblasti pro prostředek služby Event Hubs, je potřeba provést totéž v cílové oblasti.

V případě úspěšného obnovení služby Aplikace Azure do cílové oblasti je nutné předem vytvořit virtuální síť a podsíť. V případě, že se přesun těchto dvou prostředků provádí pomocí nástroje Azure Resource Mover, koncové body služby se nenakonfigurují automaticky. Proto je potřeba je nakonfigurovat ručně, což je možné provést prostřednictvím webu Azure Portal, Azure CLI nebo Azure PowerShellu.

Přemístit

Pokud chcete přemístit prostředky služby App Service, můžete použít Azure Portal nebo infrastrukturu jako kód (IaC).

Přemístění pomocí webu Azure Portal

Největší výhodou použití webu Azure Portal k přemístění je jeho jednoduchost. Aplikace, plán a obsah a mnoho nastavení se naklonují do nového prostředku a plánu služby App Service.

Mějte na paměti, že pro úrovně služby App Service Environment (izolované) je potřeba nejprve znovu nasadit celé prostředí App Service Environment v jiné oblasti a pak můžete začít znovu nasadit jednotlivé plány v nové službě App Service Environment v nové oblasti.

Přemístění prostředků služby App Service do nové oblasti pomocí webu Azure Portal:

Vytvořte zálohu zdrojové aplikace.
Vytvořte aplikaci v novém plánu služby App Service v cílové oblasti.
Obnovení zálohy v cílové aplikaci
Pokud používáte vlastní doménu, svázat ji předem s cílovou aplikací a asuid. povolit ji v cílové aplikaci.
Nakonfigurujte všechno ostatní v cílové aplikaci tak, aby bylo stejné jako zdrojová aplikace, a ověřte konfiguraci.
Až budete připraveni na vlastní doménu odkazovat na cílovou aplikaci, znovu namapujte název domény.

Přemístění pomocí IaC

IaC použijte, pokud existuje existující kanál kontinuální integrace a průběžného doručování nebo nasazování (CI/CD), nebo je možné ho vytvořit. S nasazeným kanálem CI/CD je možné prostředek služby App Service vytvořit v cílové oblasti pomocí akce nasazení nebo nasazení souboru Kudu zip.

Požadavky na smlouvu SLA by měly určovat, kolik dalšího úsilí je potřeba. Například: Jedná se o opětovné nasazení s omezenými výpadky, nebo se jedná o téměř v reálném čase, který se vyžaduje s minimálním nebo žádným výpadkem?

Zahrnutí externích, globálních hraničních služeb směrování provozu, jako je Traffic Manager nebo Azure Front Door, pomáhá usnadnit přímé přenosy pro externí uživatele a aplikace.

Tip

Traffic Manager (ATM) je možné použít při převzetí služeb při selhání služby App Services za privátními koncovými body. I když privátní koncové body nejsou dostupné sondami Traffic Manageru – pokud jsou všechny koncové body degradované, atM umožňuje směrování. Další informace najdete v tématu Řízení provozu služby Aplikace Azure pomocí Azure Traffic Manageru.

Ověřit

Po dokončení přemístění otestujte a ověřte službu Aplikace Azure s doporučenými pokyny:

Jakmile se služba Aplikace Azure přemístí do cílové oblasti, spusťte orientační a integrační test. Test můžete testovat nebo spouštět ručně pomocí skriptu. Ujistěte se, že jsou všechny konfigurace a závislé prostředky správně propojené a že jsou všechna nakonfigurovaná data přístupná.
Ověřte všechny součásti služby Aplikace Azure a integraci.
Proveďte testování integrace v nasazení cílové oblasti, včetně veškerého formálního regresního testování. Testování integrace by mělo odpovídat obvyklému rytmu nasazení firmy a testovacím procesům použitelným pro úlohu.
V některých scénářích, zejména v případech, kdy přemístění zahrnuje aktualizace, změny aplikací nebo prostředků Azure nebo změnu v profilu využití, použijte zátěžové testování k ověření, jestli je nová úloha vhodná pro účely. Zátěžové testování je také příležitostí k ověření provozu a monitorování pokrytí. Například pomocí zátěžového testování ověřte, že se správně generují požadované protokoly infrastruktury a aplikací. Zátěžové testy by se měly měřit podle zavedených standardních hodnot výkonu úloh.

Tip

Přemístění služby App Service je také příležitostí k opětovnému vyhodnocení plánování dostupnosti a zotavení po havárii. App Service a App Service Environment (App Service Environment v3) podporují zóny dostupnosti a doporučuje se nakonfigurovat konfiguraci zóny dostupnosti. Mějte na paměti předpoklady pro nasazení, ceny a omezení a mějte na paměti, že se jedná o plánování přesunu prostředků. Další informace o zónách dostupnosti a službě App Service najdete v tématu Spolehlivost ve službě Aplikace Azure Service.

Vyčištění

Odstraňte zdrojovou aplikaci a plán služby App Service. Plán služby App Service v neplacené úrovni nese poplatek, i když v ní není spuštěná žádná aplikace.

Další kroky

Klonování aplikací služby Aplikace Azure Pomocí PowerShellu

Sdílet prostřednictvím