Refaktoring linuxové aplikace pomocí Azure App Service, Traffic Manageru a Azure Database for MySQL

Tento článek ukazuje, jak fiktivní společnost Contoso refaktoruje dvouvrstvou aplikaci založenou na lampě, která ji migruje z místního prostředí do Azure pomocí Azure App Service s integrací GitHubu a Azure Database for MySQL.

osTicket, aplikace servicedesku, kterou v tomto příkladu používáme, je poskytována jako opensourcový software. Pokud ho chcete použít pro vlastní účely testování, můžete si ho stáhnout z úložiště osTicket na GitHubu.

Obchodní faktory

Tým vedení IT úzce spolupracoval s obchodními partnery, aby porozuměl tomu, co chtějí dosáhnout:

• Řešení obchodního růstu. Firma Contoso roste a přesouvá se na nové trhy. Potřebuje další agenty zákaznických služeb.
• Škálování: Toto řešení by mělo být vytvořené tak, aby firma Contoso mohla s rozvojem podnikání přidávat další agenty zákaznických služeb.
• Zvýšení odolnosti. V minulosti byly problémy s interními uživateli ovlivněny pouze systémem. S novým obchodním modelem budou externí uživatelé ovlivněni a Společnost Contoso potřebuje aplikaci neustále spuštěnou a spuštěnou.

Cíle migrace

Pokud chcete určit nejlepší metodu migrace, připnul tým cloudu Contoso své cíle pro tuto migraci:

• Aplikace by se měla škálovat nad rámec aktuální místní kapacity a výkonu. Firma Contoso aplikaci přesouvá, aby v Azure využila výhod škálování na vyžádání.
• Společnost Contoso chce přesunout základ kódu aplikace do kanálu průběžného doručování. Když se změny aplikací nasdílí na GitHub, společnost Contoso chce tyto změny nasadit bez úkolů pro provozní pracovníky.
• Aplikace musí být odolná s možnostmi růstu a převzetí služeb při selhání. Společnost Contoso chce aplikaci nasadit ve dvou různých oblastech Azure a nastavit ji tak, aby se automaticky škálovat.
• Po přesunu aplikace do cloudu chce Contoso minimalizovat úlohy správce databáze.

Návrh řešení

Po vytyčení cílů a požadavků Contoso navrhne a zkontroluje řešení nasazení a identifikuje proces migrace včetně služeb Azure, které se k migraci využijí.

Současná architektura

• Aplikace se vrství na dvou virtuálních počítačích (OSTICKETWEB a OSTICKETMYSQL).
• Virtuální počítače jsou umístěné na hostiteli VMware ESXi contosohost1.contoso.com (verze 6.5).
• Správu prostředí VMware zajišťuje vCenter Server 6.5 (vcenter.contoso.com) spuštěný na virtuálním počítači.
• Contoso má místní datacentrum (contoso-datacenter) s místním řadičem domény (contosodc1).

Navrhovaná architektura

Zde je navrhovaná architektura:

• Aplikace webové vrstvy bude OSTICKETWEB migrována vytvořením webové aplikace Azure App Service ve dvou oblastech Azure. Tým Contoso implementuje Azure App Service pro Linux pomocí kontejneru Dockeru PHP 7.0.
• Kód aplikace se přesune na GitHub a webová aplikace Azure App Service se nakonfiguruje pro průběžné doručování pomocí GitHubu.
• Azure App Service se nasadí v primární oblasti (East US 2) i sekundární oblasti (Central US).
• Azure Traffic Manager se nastaví před dvěma webovými aplikacemi v obou oblastech.
• Traffic Manager se nakonfiguruje v režimu priority tak, aby vynutil provoz přes East US 2.
• Pokud server aplikací Azure přejde do East US 2 offline režimu, můžou uživatelé získat přístup k aplikaci, ve které Central USdošlo k převzetí služeb při selhání.
• Databáze aplikace se migruje do služby Azure Database for MySQL pomocí Azure Database Migration Service. Místní databáze bude zálohována místně a obnovena přímo do Azure Database for MySQL.
• Databáze se bude nacházet v primární oblasti (East US 2) v podsíti databáze (PROD-DB-EUS2) produkční sítě (VNET-PROD-EUS2).
• Vzhledem k tomu, že migrují produkční úlohu, budou prostředky Azure pro aplikaci umístěny v produkční skupině ContosoRGprostředků .
• Prostředek Traffic Manageru se nasadí ve skupině ContosoInfraRGprostředků infrastruktury společnosti Contoso.
• Po dokončení migrace budou místní virtuální počítače v datacentru společnosti Contoso vyřazeny z provozu.

Proces migrace

Společnost Contoso dokončí proces migrace následujícím způsobem:

1. V prvním kroku správci Společnosti Contoso nastavují infrastrukturu Azure, včetně zřizování Azure App Service, nastavení Traffic Manageru a zřizování instance Azure Database for MySQL.
2. Po přípravě infrastruktury Azure migrují databázi pomocí Azure Database Migration Service.
3. Po spuštění databáze v Azure nahrají privátní úložiště GitHubu pro Azure App Service s průběžným doručováním a načtou ho pomocí aplikace osTicket.
4. V Azure Portal načtou aplikaci z GitHubu do kontejneru Dockeru spuštěním Azure App Service.
5. Upraví nastavení DNS a nakonfiguruje automatické škálování pro aplikaci.

Služby Azure

Služba	Popis	Náklady
Azure App Service	Služba spouští a škáluje aplikace pomocí platformy Azure jako služby (PaaS) pro weby.	Ceny jsou založené na velikosti instancí a požadovaných funkcích. Přečtěte si další informace.
Azure Traffic Manager	Nástroj pro vyrovnávání zatížení, který používá dns (Domain Name System) k nasměrování uživatelů do Azure nebo na externí weby a služby.	Ceny vycházejí z počtu přijatých dotazů DNS a počtu monitorovaných koncových bodů. Přečtěte si další informace.
Azure Database Migration Service	Azure Database Migration Service umožňuje bezproblémovou migraci z více zdrojů databáze na datové platformy Azure s minimálními výpadky.	Informace o podporovaných oblastech a cenách služby Database Migration Service
Azure Database for MySQL	Databáze je založená na opensourcovém databázovém stroji MySQL. Poskytuje plně spravovanou databázi MySQL připravenou pro podnikovou komunitu pro vývoj a nasazení aplikací.	Ceny jsou založené na požadavcích na výpočetní prostředky, úložiště a zálohování. Přečtěte si další informace.

Požadavky

Pokud chcete tento scénář spustit, musí společnost Contoso splnit následující požadavky:

Požadavky	Podrobnosti
Předplatné Azure	Firma Contoso vytvořila předplatná v dřívějším článku v této sérii. Pokud ještě nemáte předplatné Azure, vytvořte si bezplatný účet. Pokud vytvoříte bezplatný účet, jste správcem vašeho předplatného a můžete provádět všechny akce. Pokud používáte existující předplatné a nejste správcem, musíte správce požádat, aby vám udělil oprávnění Vlastník nebo Přispěvatel.
Infrastruktura Azure	Contoso nastaví svoji infrastrukturu Azure podle popisu v článku Infrastruktura Azure pro migraci.

Kroky scénáře

Tady je plán Společnosti Contoso pro dokončení migrace:

• Krok 1: Zřízení Azure App Service Správci Contoso zřídí webové aplikace v primární a sekundární oblasti.
• Krok 2: Nastavení Traffic Manageru Nastaví Traffic Manager před webovými aplikacemi pro účely směrování provozu a vyrovnávání zatížení.
• Krok 3: Zřízení Azure Database for MySQL V Azure zřídí instanci Azure Database for MySQL.
• Krok 4: Migrace databáze Migrují databázi pomocí Azure Database Migration Service.
• Krok 5: Nastavení GitHubu Nastavují místní úložiště GitHubu pro weby a kód aplikace.
• Krok 6: Konfigurace webových aplikací Nakonfigurují webové aplikace pomocí webů osTicket.

Krok 1: Zřízení Azure App Service

Správci Společnosti Contoso zřizují dvě webové aplikace (jednu v každé oblasti) pomocí Azure App Service.

1. Vytvoří prostředek webové aplikace (osticket-eus2) v primární oblasti (East US 2) prostřednictvím Azure Marketplace.

2. Umístí prostředek do produkční skupiny ContosoRGprostředků .

   

3. Vytvoří plán App Service , APP-SVP-EUS2v primární oblasti a používají standardní velikost.

   

4. Vyberou sadu operačního systému Linux s PHP 7.0, což je kontejner Dockeru.

   

5. Vytvoří druhou webovou aplikaci osticket-cusa plán Azure App Service pro USA – střed.

   

Potřebujete další pomoc?

• Seznamte se s webovými aplikacemi Azure App Service.
• Seznamte se se službou Azure App Service v Linuxu.

Krok 2: Nastavení Traffic Manageru

Správci společnosti Contoso nastavují Traffic Manager tak, aby směrovat příchozí webové požadavky na webové aplikace, které běží na webové vrstvě osTicket.

1. V Azure Marketplace vytvoří prostředek Traffic Manageru. osticket.trafficmanager.net Používají prioritní směrování, aby usa – východ 2 byly primární lokalitou. Umístí prostředek do své stávající skupiny prostředků infrastruktury. ContosoInfraRG Traffic Manager je globální a není vázaný na konkrétní umístění.

   

2. Nakonfigurují Traffic Manager s koncovými body. Přidají webovou aplikaci v oblasti USA – východ 2 jako primární lokalitu osticket-eus2a webová aplikace v oblasti USA – střed jako sekundární lokalita osticket-cus.

   

3. Po přidání koncových bodů je můžou správci monitorovat.

   

Potřebujete další pomoc?

• Seznamte se s Traffic Managerem.
• Seznamte se se směrováním provozu do prioritního koncového bodu.

Krok 3: Zřízení Azure Database for MySQL

Správci společnosti Contoso zřídí instanci databáze MySQL v primární oblasti USA – východ 2.

1. Na webu Azure Portal vytvoří prostředek Azure Database for MySQL.

   

2. Přidají název contosoosticket databáze Azure. Přidají databázi do produkční skupiny ContosoRG prostředků a pak pro ni zadají přihlašovací údaje.

3. Místní databáze MySQL je verze 5.7, takže tuto verzi vyberou pro zajištění kompatibility. Použijí výchozí velikosti, které odpovídají jejich požadavkům na databázi.

   

4. U možností redundance zálohování vyberou geograficky redundantní. Tato možnost umožňuje obnovit databázi v sekundární oblasti (USA – střed), pokud dojde k výpadku. Tuto možnost můžou nakonfigurovat pouze při zřizování databáze.

   

5. Nastaví zabezpečení připojení. V databázi vyberou zabezpečení připojení a pak nastaví pravidla brány firewall, která databázi umožní přístup ke službám Azure.

6. Do počátečních a koncových IP adres přidají místní IP adresu klienta pracovní stanice. Webovým aplikacím a klientovi databáze, který provádí migraci, to umožní získat přístup k databázi MySQL.

   

Krok 4: Migrace databáze

Databázi MySQL můžete přesunout několika způsoby. Každá možnost vyžaduje, aby správci společnosti Contoso vytvořili instanci Azure Database for MySQL cíle. Po vytvoření instance můžou databázi migrovat pomocí jedné ze dvou cest:

• Krok 4a: Azure Database Migration Service
• Krok 4b: Zálohování a obnovení aplikace MySQL Workbench

Krok 4a: Migrace databáze přes Azure Database Migration Service

Správci společnosti Contoso migrují databázi prostřednictvím Azure Database Migration Service podle podrobného kurzu migrace. Můžou provádět online, offline a hybridní migrace (Preview) pomocí MySQL 5.6 nebo 5.7.

Poznámka

MySQL 8.0 je podporován v Azure Database for MySQL, ale nástroj Database Migration Service tuto verzi zatím nepodporuje.

Stručně řečeno společnost Contoso provede následující:

• Zajišťují splnění všech požadavků na migraci:

  • Zdroj databázového serveru MySQL musí odpovídat verzi, kterou Azure Database for MySQL podporuje. Azure Database for MySQL podporuje MySQL Community Edition, modul úložiště InnoDB a migraci napříč zdrojovými a cílovými verzemi.

  • Povolí binární protokolování v my.ini systému (Windows) nebo my.cnf (Unix). Pokud to neuděláte, v Průvodci migrací dojde k následující chybě:

    Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

    Další informace najdete v tématu Možnosti a proměnné binárního protokolování v dokumentaci k MySQL.

  • Uživatel musí mít ReplicationAdmin roli.

  • Migrujte schémata databáze bez cizích klíčů a triggerů.

• Vytvoří virtuální privátní síť (VPN), která se připojuje přes ExpressRoute nebo VPN k místní síti.

• Vytvoří instanci Azure Database Migration Service s skladovou jednotkou Premium, která je připojená k virtuální síti.

• Zajišťují, aby Azure Database Migration Service měli přístup k databázi MySQL prostřednictvím virtuální sítě. To znamená, že všechny příchozí porty jsou povolené z Azure do MySQL na úrovni virtuální sítě, sítě VPN a počítače, který hostuje MySQL.

• Spustí nástroj Database Migration Service a pak provede následující akce:

  1. Vytvořte projekt migrace, který je založený na skladové posílce Premium.

     

     

  2. Přidání zdroje (místní databáze)

     

  3. Vyberte cíl.

     

  4. Vyberte databáze, které chcete migrovat.

     

  5. Nakonfigurujte upřesňující nastavení.

     

  6. Spusťte replikaci a vyřešte případné chyby.

     

  7. Proveďte konečnou přímou operaci.

     

     

     

  8. Obnovte všechny cizí klíče a triggery.

  9. Upravte aplikace tak, aby používaly novou databázi.

     

Krok 4b: Migrace databáze (MySQL Workbench)

1. Správci společnosti Contoso zkontrolují požadavky a stáhnutí aplikace MySQL Workbench.

2. Nainstalují MySQL Workbench pro Windows podle pokynů k instalaci. Počítač, na který nainstalují MySQL Workbench, musí být přístupný pro osticketmysql virtuální počítač a do Azure přes internet.

3. V aplikaci MySQL Workbench vytvoří připojení MySQL k osticketmysql.

   

4. Exportují databázi do osticket místního souboru s vlastním obsahem.

   

5. Po místním zálohování databáze vytvoří správci připojení k instanci Azure Database for MySQL.

   

6. Teď můžou databázi importovat (obnovit) v instanci Azure Database for MySQL ze souboru s vlastním obsahem. Pro instanci se vytvoří nové schéma osticket.

   

7. Po obnovení dat je můžou správci dotazovat pomocí aplikace MySQL Workbench. Data se zobrazí v Azure Portal.

   

   

8. Správci aktualizují informace o databázi webových aplikací. V instanci MySQL otevřou Připojovací řetězce.

   

9. V seznamu připojovacích řetězců vyberou nastavení webové aplikace a pak je zkopírují tak, že je vyberete Kliknutím zkopírujete.

   

10. Otevřou nový soubor v Poznámkovém bloku, vloží do něj řetězec a aktualizují řetězec tak, aby odpovídal databázi osTicket, instanci MySQL a nastavení přihlašovacích údajů.

    

11. Můžou ověřit název serveru a přihlásit se prostřednictvím podokna Přehled instance MySQL v Azure Portal.

    

Krok 5: Nastavení GitHubu

Správci Společnosti Contoso vytvoří nové privátní úložiště GitHub a nastaví připojení k databázi osTicket v Azure Database for MySQL. Pak načtou webovou aplikaci do Azure App Service.

1. Přejdou do veřejného úložiště GitHubu softwaru osTicket a forkují ho na účet Contoso GitHub.

   

2. Po vytvoření forku úložiště přejdou do include složky a vyberou ost-config.php soubor.

   

3. Soubor se otevře v prohlížeči a upraví ho.

   

4. V editoru správci aktualizují podrobnosti databáze, konkrétně pro DBHOST a DBUSER.

   

5. Změny potvrdí.

   

6. Pro každou webovou aplikaci (osticket-eus2a osticket-cus) v Azure Portal vyberou nastavení aplikace v levém podokně a pak upraví nastavení.

   

7. Zadají připojovací řetězec s názvem osticketa zkopírují řetězec z Poznámkového bloku do oblasti hodnot. V rozevíracím seznamu vedle tohoto řetězce vyberou MySQL a uloží nastavení.

   

Krok 6: Konfigurace webových aplikací

Jako poslední krok v procesu migrace správci společnosti Contoso nakonfigurují webové aplikace pomocí webů osTicket.

1. V primární webové aplikaci osticket-eus2otevřou možnost Nasazení a pak nastaví zdroj na GitHub.

   

2. Vyberou možnosti nasazení.

   

3. Po nastavení možností se v Azure Portal konfigurace zobrazí jako Čeká na vyřízení.

   

4. Po aktualizaci konfigurace a načtení webové aplikace osTicket z GitHubu do kontejneru Dockeru, který spouští Azure App Service, se web zobrazí jako aktivní.

   

5. Opakují předchozí kroky pro sekundární webovou aplikaci. osticket-cus

6. Po nakonfigurování je lokalita přístupná přes profil Traffic Manageru. Název DNS je nové umístění aplikace osTicket. Přečtěte si další informace.

   

7. Společnost Contoso chce použít název DNS, který je snadno zapamatovatelný. V podokně Nový záznam prostředku vytvoří alias, CNAME a plně kvalifikovaný název domény, osticket.contoso.comkterý odkazuje na název Traffic Manageru v DNS na řadičích domény.

   

8. Nakonfigurují jak webové aplikace, osticket-eus2osticket-cus tak webové aplikace tak, aby umožňovaly názvy vlastních hostitelů.

   

Nastavení automatického škálování

Správci společnosti Contoso nakonec nastavují automatické škálování aplikace. Automatické škálování zajišťuje, že když agenti aplikaci používají, instance aplikací se zvyšují a snižují podle obchodních potřeb.

1. V App Service APP-SVP-EUS2otevřou jednotku škálování.

2. Nakonfigurují nové nastavení automatického škálování s jedním pravidlem, které zvýší počet instancí o jedno, když využití procesoru pro aktuální instanci překročí 70 procent po dobu 10 minut.

   

3. Nakonfigurují stejné nastavení APP-SVP-CUS , aby se zajistilo, že stejné chování platí, pokud aplikace převezme služby při selhání do sekundární oblasti. Jediným rozdílem je, že nastaví výchozí instanci na 1, protože se jedná pouze o převzetí služeb při selhání.

   

Vyčištění po migraci

Po dokončení migrace se aplikace osTicket refaktoruje tak, aby běžela v Azure App Service webové aplikaci s průběžným doručováním pomocí privátního úložiště GitHub. Aplikace běží ve dvou oblastech pro zvýšení odolnosti. Databáze osTicket běží v Azure Database for MySQL po migraci na platformu PaaS.

Společnost Contoso provede vyčištění po migraci následujícím postupem:

• Odeberou virtuální počítače VMware z inventáře vCenter.
• Odeberou místní virtuální počítače z místních úloh zálohování.
• Aktualizují interní dokumentaci tak, aby zobrazovaly nová umístění a IP adresy.
• Zkontrolují všechny prostředky, které pracují s místními virtuálními počítači, a aktualizují všechna relevantní nastavení nebo dokumentaci, aby odrážely novou konfiguraci.
• Překonfigurují monitorování tak, aby odkazovali na osticket.trafficmanager.net adresu URL a sledovali, že je aplikace spuštěná.

Kontrola nasazení

Když je aplikace teď spuštěná, společnost Contoso potřebuje plně zprovoznit a zabezpečit svou novou infrastrukturu.

Zabezpečení

Bezpečnostní tým Společnosti Contoso zkontroluje aplikaci a určí případné problémy se zabezpečením. Identifikují, že komunikace mezi aplikací osTicket a instancí databáze MySQL není nakonfigurovaná pro SSL. To všechno dělají, aby se zajistilo, že se provoz databáze nedá hacknout. Přečtěte si další informace.

Zálohování

• Webové aplikace osTicket neobsahují stavová data, a proto nevyžadují zálohování.
• Tým Společnosti Contoso nemusí konfigurovat zálohování databáze. Azure Database for MySQL automaticky vytváří a ukládá zálohy serveru. Tým se rozhodl pro databázi používat geografickou redundanci, takže je odolný a připravený pro produkční prostředí. Zálohy je možné použít k obnovení serveru k určitému bodu v čase. Přečtěte si další informace.

Licencování a optimalizace nákladů

• U nasazení PaaS nejsou žádné licenční problémy.
• Společnost Contoso použije Azure Cost Management + Billing k zajištění toho, aby zůstal v rámci rozpočtů vytvořených vedením IT.