Refaktoryzacja aplikacji systemu Linux przy użyciu Azure App Service, usługi Traffic Manager i Azure Database for MySQL

W tym artykule pokazano, w jaki sposób fikcyjna firma Contoso refaktoryzuje dwuwarstwową aplikację opartą na lampie, migrując ją ze środowiska lokalnego do platformy Azure przy użyciu Azure App Service integracji z usługą GitHub i Azure Database for MySQL.

osTicket, aplikacja pomocy technicznej używana w tym przykładzie, jest dostarczana jako oprogramowanie typu open source. Jeśli chcesz używać go do własnych celów testowych, możesz pobrać go z repozytorium osTicket w usłudze GitHub.

Biznesowa siła napędowa

Zespół liderów IT ściśle współpracował z partnerami biznesowymi, aby zrozumieć, co chcą osiągnąć:

• Reagowanie na rosnące potrzeby biznesowe. Firma Contoso rozwija się i przenosi na nowe rynki. Potrzebuje więc dodatkowych agentów obsługi klienta.
• Skalowanie. Rozwiązanie należy skompilować tak, aby firma Contoso mogła dodawać kolejnych agentów obsługi klienta w miarę rozwoju firmy.
• Zwiększanie odporności. W przeszłości problemy z systemem dotyczyły tylko użytkowników wewnętrznych. W przypadku nowego modelu biznesowego wpłynie to na użytkowników zewnętrznych, a firma Contoso potrzebuje aplikacji przez cały czas.

Cele migracji

Aby określić najlepszą metodę migracji, zespół ds. chmury firmy Contoso określił cele tej migracji:

• Aplikacja powinna skalować poza bieżącą lokalną pojemność i wydajność. Firma Contoso przenosi aplikację, aby wykorzystać możliwości skalowania na żądanie na platformie Azure.
• Firma Contoso chce przenieść bazę kodu aplikacji do potoku ciągłego dostarczania. Gdy zmiany aplikacji są wypychane do usługi GitHub, firma Contoso chce wdrożyć te zmiany bez zadań dla personelu operacyjnego.
• Aplikacja musi być odporna z możliwościami zwiększania i przełączania w tryb failover. Firma Contoso chce wdrożyć aplikację w dwóch różnych regionach świadczenia usługi Azure i skonfigurować ją do automatycznego skalowania.
• Firma Contoso chce zminimalizować zadania administratora bazy danych po przeniesieniu aplikacji do chmury.

Projekt rozwiązania

Po określeniu swoich celów i wymagań firma Contoso planuje i ocenia rozwiązanie do wdrożenia oraz ustala proces migracji, w tym usługi platformy Azure, które będą używane do tego celu.

Bieżąca architektura

• Aplikacja jest warstwowa na dwóch maszynach wirtualnych (maszynach wirtualnych) (OSTICKETWEB i OSTICKETMYSQL).
• Maszyny wirtualne znajdują się na hoście VMware ESXi contosohost1.contoso.com (wersja 6.5).
• Środowisko VMware jest zarządzane przez program vCenter Server 6.5 (vcenter.contoso.com) uruchomiony na maszynie wirtualnej.
• Firma Contoso ma lokalne centrum danych (contoso-datacenter) i lokalny kontroler domeny (contosodc1).

Proponowana architektura

Oto proponowana architektura:

• Aplikacja OSTICKETWEB warstwy internetowej zostanie zmigrowana przez utworzenie aplikacji internetowej Azure App Service w dwóch regionach świadczenia usługi Azure. Zespół firmy Contoso zaimplementuje Azure App Service dla systemu Linux przy użyciu kontenera platformy Docker w języku PHP 7.0.
• Kod aplikacji zostanie przeniesiony do usługi GitHub, a Azure App Service aplikacja internetowa zostanie skonfigurowana do ciągłego dostarczania w usłudze GitHub.
• Azure App Service zostaną wdrożone zarówno w regionie podstawowym (East US 2), jak i w regionie pomocniczym (Central US).
• Usługa Azure Traffic Manager zostanie skonfigurowana przed dwiema aplikacjami internetowymi w obu regionach.
• Usługa Traffic Manager zostanie skonfigurowana w trybie priorytetu, aby wymusić ruch przez East US 2usługę .
• Jeśli serwer aplikacji platformy Azure w systemie przejdzie w East US 2 tryb offline, użytkownicy będą mogli uzyskać dostęp do aplikacji przełączonej w tryb failover w systemie Central US.
• Baza danych aplikacji zostanie zmigrowana do usługi Azure Database for MySQL przy użyciu Azure Database Migration Service. Kopia zapasowa lokalnej bazy danych zostanie utworzona lokalnie, a lokalna baza danych zostanie przywrócona bezpośrednio do usługi Azure Database for MySQL.
• Baza danych będzie znajdować się w regionie podstawowym (East US 2) w podsieci bazy danych (PROD-DB-EUS2) sieci produkcyjnej (VNET-PROD-EUS2).
• Ponieważ migrują obciążenie produkcyjne, zasoby platformy Azure dla aplikacji będą znajdować się w produkcyjnej grupie ContosoRGzasobów .
• Zasób usługi Traffic Manager zostanie wdrożony w grupie ContosoInfraRGzasobów infrastruktury firmy Contoso.
• Lokalne maszyny wirtualne w centrum danych firmy Contoso zostaną zlikwidowane po zakończeniu migracji.

Proces migracji

Firma Contoso kończy proces migracji w następujący sposób:

1. W pierwszym kroku administratorzy firmy Contoso konfigurują infrastrukturę platformy Azure, w tym aprowizację Azure App Service, konfigurowanie usługi Traffic Manager i aprowizowanie wystąpienia Azure Database for MySQL.
2. Po przygotowaniu infrastruktury platformy Azure przeprowadzają migrację bazy danych przy użyciu Azure Database Migration Service.
3. Po uruchomieniu bazy danych na platformie Azure przekazują prywatne repozytorium GitHub dla Azure App Service z ciągłym dostarczaniem i ładują je za pomocą aplikacji osTicket.
4. W Azure Portal ładują aplikację z usługi GitHub do kontenera platformy Docker, uruchamiając Azure App Service.
5. Dostrajają ustawienia DNS i konfigurują skalowanie automatyczne dla aplikacji.

Usługi platformy Azure

Usługa	Opis	Koszty
Azure App Service	Usługa uruchamia i skaluje aplikacje przy użyciu platformy Azure jako usługi (PaaS) dla witryn internetowych.	Ceny zależą od rozmiaru wystąpień i wymaganych funkcji. Dowiedz się więcej.
Azure Traffic Manager	Moduł równoważenia obciążenia, który używa systemu nazw domen (DNS) do kierowania użytkowników do platformy Azure lub do zewnętrznych witryn internetowych i usług.	Ceny są oparte na liczbie odebranych zapytań DNS i liczbie monitorowanych punktów końcowych. Dowiedz się więcej.
Azure Database Migration Service	Azure Database Migration Service umożliwia bezproblemową migrację z wielu źródeł baz danych do platform danych platformy Azure przy minimalnych przestojach.	Dowiedz się więcej o obsługiwanych regionach i cenniku usługi Database Migration Service.
Azure Database for MySQL	Baza danych jest oparta na a aparatu bazy danych MySQL typu open source. Zapewnia w pełni zarządzaną, gotową do użycia w przedsiębiorstwie bazę danych MySQL na potrzeby tworzenia i wdrażania aplikacji.	Cennik jest oparty na wymaganiach obliczeniowych, magazynowych i kopii zapasowych. Dowiedz się więcej.

Wymagania wstępne

Aby uruchomić ten scenariusz, firma Contoso musi spełnić następujące wymagania wstępne:

Wymagania	Szczegóły
Subskrypcja platformy Azure	Firma Contoso utworzyła subskrypcje wcześniej w tej serii artykułów. Jeśli nie masz subskrypcji platformy Azure, utwórz bezpłatne konto. Jeśli bezpłatne konto właśnie zostało utworzone, jesteś administratorem subskrypcji i możesz wykonywać wszystkie akcje. Jeśli używasz istniejącej subskrypcji i nie jesteś jej administratorem, musisz skontaktować się z administratorem w celu uzyskania uprawnień właściciela lub współautora.
Infrastruktura platformy Azure	Firma Contoso skonfigurowała infrastrukturę platformy Azure zgodnie z opisem w artykule Azure infrastructure for Migration (Infrastruktura platformy Azure wymagana do migracji).

Etapy scenariusza

Oto plan firmy Contoso na zakończenie migracji:

• Krok 1. Aprowizuj Azure App Service. Administratorzy firmy Contoso będą aprowizować aplikacje internetowe w regionach podstawowym i pomocniczym.
• Krok 2. Konfigurowanie usługi Traffic Manager. Konfigurują oni usługę Traffic Manager przed aplikacjami internetowymi na potrzeby ruchu routingu i równoważenia obciążenia.
• Krok 3. Aprowizuj Azure Database for MySQL. Na platformie Azure aprowizują oni wystąpienie usługi Azure Database for MySQL.
• Krok 4. Migrowanie bazy danych. Migrują bazę danych przy użyciu Azure Database Migration Service.
• Krok 5. Konfigurowanie usługi GitHub. Konfigurują lokalne repozytorium GitHub dla witryn internetowych i kodu aplikacji.
• Krok 6. Konfigurowanie aplikacji internetowych. Konfigurują aplikacje internetowe za pomocą witryn internetowych osTicket.

Krok 1. Aprowizowania Azure App Service

Administratorzy firmy Contoso aprowizować dwie aplikacje internetowe (po jednym w każdym regionie) przy użyciu Azure App Service.

1. Tworzą zasób aplikacji internetowej () w regionie podstawowym (osticket-eus2East US 2) za pośrednictwem Azure Marketplace.

2. Umieszczają zasób w produkcyjnej grupie ContosoRGzasobów .

   

3. Tworzą plan App Service, APP-SVP-EUS2, w regionie podstawowym i używają rozmiaru standardowego.

   

4. Wybierają system operacyjny Linux z stosem środowiska uruchomieniowego PHP 7.0, który jest kontenerem platformy Docker.

   

5. Tworzą drugą aplikację internetową, osticket-cusoraz plan Azure App Service dla środkowych stanów USA.

   

Potrzebujesz dodatkowej pomocy?

• Dowiedz się więcej o aplikacjach internetowych usługi Azure App Service.
• Dowiedz się więcej o usłudze Azure App Service dla systemu Linux.

Krok 2. Konfigurowanie usługi Traffic Manager

Administratorzy firmy Contoso skonfigurowali usługę Traffic Manager w celu kierowania przychodzących żądań internetowych do aplikacji internetowych działających w warstwie internetowej osTicket.

1. W Azure Marketplace tworzą zasób osticket.trafficmanager.netusługi Traffic Manager. Używają routingu priorytetowego, aby wschodnie stany USA 2 były lokacją główną. Umieszczają zasób w istniejącej grupie zasobów infrastruktury. ContosoInfraRG Zauważ, że usługa Traffic Manager jest globalna i nie jest powiązana z określoną lokalizacją.

   

2. Konfigurują usługę Traffic Manager z punktami końcowymi. Dodają aplikację internetową w regionie Wschodnie stany USA 2 jako lokację główną, osticket-eus2oraz aplikację internetową w środkowych stanach USA jako lokację osticket-cusdodatkową.

   

3. Po dodaniu punktów końcowych administratorzy mogą je monitorować.

   

Potrzebujesz dodatkowej pomocy?

• Dowiedz się więcej o usłudze Traffic Manager.
• Dowiedz się więcej o kierowaniu ruchu do priorytetowego punktu końcowego.

Krok 3. Aprowizuj Azure Database for MySQL

Administratorzy firmy Contoso aprowizją wystąpienie bazy danych MySQL w regionie podstawowym Wschodnie stany USA 2.

1. W witrynie Azure Portal tworzą zasób usługi Azure Database for MySQL.

   

2. Dodają nazwę contosoosticket bazy danych platformy Azure. Dodają bazę danych do produkcyjnej grupy ContosoRG zasobów, a następnie określają poświadczenia dla niej.

3. Wersja lokalnej bazy danych MySQL to 5.7, dlatego wybierają tę wersję w celu zachowania zgodności. Używają rozmiarów domyślnych, które spełniają wymagania dotyczące bazy danych.

   

4. W obszarze Opcje nadmiarowości kopii zapasowych wybierają pozycję Geograficznie nadmiarowe. Ta opcja umożliwia przywrócenie bazy danych w regionie pomocniczym (Środkowe stany USA), jeśli wystąpi awaria. Mogą one skonfigurować tę opcję tylko wtedy, gdy aprowizacja bazy danych.

   

5. Konfigurują zabezpieczenia połączeń. W bazie danych wybierają pozycję Zabezpieczenia połączeń , a następnie konfigurują reguły zapory, aby umożliwić bazie danych dostęp do usług platformy Azure.

6. Dodają adres IP klienta lokalnej stacji roboczej do początkowego i końcowego adresu IP. Dzięki temu aplikacje internetowe mogą uzyskiwać dostęp do bazy danych MySQL razem z klientem bazy danych, który przeprowadza migrację.

   

Krok 4. Migrowanie bazy danych

Istnieje kilka sposobów przenoszenia bazy danych MySQL. Każda opcja wymaga od administratorów firmy Contoso utworzenia wystąpienia Azure Database for MySQL dla elementu docelowego. Po utworzeniu wystąpienia mogą migrować bazę danych przy użyciu jednej z dwóch ścieżek:

• Krok 4a: Azure Database Migration Service
• Krok 4b: Tworzenie i przywracanie kopii zapasowej aplikacji MySQL Workbench

Krok 4a. Migrowanie bazy danych za pośrednictwem Azure Database Migration Service

Administratorzy firmy Contoso migrują bazę danych za pośrednictwem Azure Database Migration Service, wykonując instrukcje krok po kroku dotyczące migracji. Mogą wykonywać migracje online, offline i hybrydowe (wersja zapoznawcza) przy użyciu programu MySQL 5.6 lub 5.7.

Uwaga

Program MySQL 8.0 jest obsługiwany w Azure Database for MySQL, ale narzędzie Database Migration Service nie obsługuje jeszcze tej wersji.

Krótko mówiąc, firma Contoso wykonuje następujące czynności:

• Zapewniają one spełnienie wszystkich wymagań wstępnych migracji:

  • Źródło serwera bazy danych MySQL musi być zgodne z wersją obsługiwaną przez Azure Database for MySQL. Azure Database for MySQL obsługuje program MySQL Community Edition, aparat magazynu InnoDB i migrację między źródłami i obiektami docelowymi z tymi samymi wersjami.

  • Umożliwiają one rejestrowanie binarne w my.ini systemie (Windows) lub my.cnf (Unix). Nie można to zrobić, co spowoduje następujący błąd w Kreatorze migracji:

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

    Aby uzyskać więcej informacji, zobacz Opcje rejestrowania binarnego i zmienne w dokumentacji programu MySQL.

  • Użytkownik musi mieć ReplicationAdmin rolę.

  • Migrowanie schematów bazy danych bez kluczy obcych i wyzwalaczy.

• Tworzą wirtualną sieć prywatną (VPN), która łączy się za pośrednictwem usługi ExpressRoute lub sieci VPN z siecią lokalną.

• Tworzą wystąpienie Azure Database Migration Service za pomocą jednostki SKU Premium połączonej z siecią wirtualną.

• Zapewniają one, że Azure Database Migration Service mogą uzyskiwać dostęp do bazy danych MySQL za pośrednictwem sieci wirtualnej. Wiąże się to z zapewnieniem, że wszystkie porty przychodzące są dozwolone z platformy Azure do usługi MySQL na poziomie sieci wirtualnej, sieci VPN i maszyny, która hostuje program MySQL.

• Uruchamiają narzędzie Database Migration Service, a następnie wykonują następujące czynności:

  1. Utwórz projekt migracji oparty na jednostce SKU Premium.

     

     

  2. Dodaj źródło (lokalną bazę danych).

     

  3. Wybierz element docelowy.

     

  4. Wybierz bazy danych do migracji.

     

  5. Konfigurowanie ustawień zaawansowanych.

     

  6. Uruchom replikację i rozwiąż wszelkie błędy.

     

  7. Wykonaj ostatnią operację przecięcia.

     

     

     

  8. Przywrócić wszystkie klucze obce i wyzwalacze.

  9. Zmodyfikuj aplikacje, aby korzystały z nowej bazy danych.

     

Krok 4b. Migrowanie bazy danych (MySQL Workbench)

1. Administratorzy firmy Contoso sprawdzają wymagania wstępne i pobierają aplikację MySQL Workbench.

2. Instalują program MySQL Workbench dla systemu Windows zgodnie z instrukcjami instalacji. Maszyna, na której instaluje aplikację osticketmysql MySQL Workbench, musi być dostępna dla maszyny wirtualnej i platformy Azure za pośrednictwem Internetu.

3. W aplikacji MySQL Workbench tworzą połączenie MySQL z osticketmysqlusługą .

   

4. Eksportują bazę danych jako osticket do lokalnego pliku samodzielnego.

   

5. Po utworzeniu kopii zapasowej bazy danych lokalnie administratorzy tworzą połączenie z wystąpieniem Azure Database for MySQL.

   

6. Teraz mogą zaimportować (przywrócić) bazę danych w wystąpieniu Azure Database for MySQL z pliku samodzielnego. Dla wystąpienia jest tworzony nowy schemat osticket, .

   

7. Po przywróceniu danych administratorzy mogą wysyłać do nich zapytania przy użyciu aplikacji MySQL Workbench. Dane są wyświetlane w Azure Portal.

   

   

8. Administratorzy aktualizują informacje o bazie danych w aplikacjach internetowych. W wystąpieniu usługi MySQL otwierają obszar Parametry połączenia.

   

9. Na liście parametrów połączenia wybierają ustawienia aplikacji internetowej, a następnie kopiują je, wybierając pozycję Kliknij, aby skopiować.

   

10. Otwierają nowy plik w Notatniku, wklejają do niego ciąg i aktualizują ciąg tak, aby był zgodny z ustawieniami bazy danych osTicket, wystąpienia programu MySQL i poświadczeń.

    

11. Mogą zweryfikować nazwę serwera i zalogować się za pomocą okienka Przegląd dla wystąpienia programu MySQL w Azure Portal.

    

Krok 5. Konfigurowanie usługi GitHub

Administratorzy firmy Contoso tworzą nowe prywatne repozytorium GitHub i konfigurują połączenie z bazą danych osTicket w Azure Database for MySQL. Następnie ładują aplikację internetową do usługi Azure App Service.

1. Przechodzą do publicznego repozytorium GitHub oprogramowania osTicket i tworzą rozwidlenie na koncie usługi GitHub firmy Contoso.

   

2. Po rozwidleniu repozytorium przechodzą do include folderu i wybierają ost-config.php plik.

   

3. Plik zostanie otwarty w przeglądarce i zmodyfikuje go.

   

4. W edytorze administratorzy aktualizują szczegóły bazy danych, w szczególności dla DBHOST poleceń i DBUSER.

   

5. Zatwierdzają zmiany.

   

6. Dla każdej aplikacji internetowej (osticket-eus2 i osticket-cus) w Azure Portal wybierają pozycję Ustawienia aplikacji w okienku po lewej stronie, a następnie modyfikują ustawienia.

   

7. Wprowadzają parametry połączenia o nazwie osticketi kopiują parametry z Notatnika do obszaru wartości. Wybierają opcję MySQL na liście rozwijanej obok parametrów i zapisują ustawienia.

   

Krok 6. Konfigurowanie aplikacji internetowych

W ostatnim kroku procesu migracji administratorzy firmy Contoso konfigurują aplikacje internetowe za pomocą witryn internetowych osTicket.

1. W podstawowej aplikacji internetowej otwierają opcję Wdrażanie, osticket-eus2a następnie ustawiają źródło na GitHub.

   

2. Wybierają opcje wdrażania.

   

3. Po ustawieniu opcji konfiguracja będzie wyświetlana jako Oczekująca w Azure Portal.

   

4. Po zaktualizowaniu konfiguracji i załadowaniu aplikacji internetowej osTicket z usługi GitHub do kontenera platformy Docker, który uruchamia Azure App Service, witryna jest wyświetlana jako Aktywna.

   

5. Powtórzą poprzednie kroki dla pomocniczej aplikacji internetowej. osticket-cus

6. Po skonfigurowaniu lokacji będzie ona dostępna za pośrednictwem profilu usługi Traffic Manager. Nazwa DNS jest nową lokalizacją aplikacji osTicket. Dowiedz się więcej.

   

7. Firma Contoso chce użyć nazwy DNS, która jest łatwa do zapamiętania. W okienku Nowy rekord zasobu tworzą alias, rekord CNAME i w pełni kwalifikowaną nazwę domeny , osticket.contoso.comktóra wskazuje nazwę usługi Traffic Manager w systemie DNS na kontrolerach domeny.

   

8. Konfigurują zarówno aplikacje internetowe, jak osticket-eus2 i osticket-cus , aby zezwalały na niestandardowe nazwy hostów.

   

Konfigurowanie skalowania automatycznego

Na koniec administratorzy firmy Contoso konfigurują automatyczne skalowanie dla aplikacji. Automatyczne skalowanie zapewnia, że w miarę używania aplikacji przez agentów wystąpienia aplikacji zwiększają się i zmniejszają zgodnie z potrzebami biznesowymi.

1. W App Service APP-SVP-EUS2otwierają jednostkę skalowania.

2. Konfigurują nowe ustawienie automatycznego skalowania przy użyciu pojedynczej reguły, która zwiększa liczbę wystąpień o jedną, gdy użycie procesora CPU dla bieżącego wystąpienia jest powyżej 70 procent przez 10 minut.

   

3. Konfigurują to samo ustawienie, APP-SVP-CUS aby upewnić się, że to samo zachowanie ma zastosowanie, jeśli aplikacja przełącza się w tryb failover w regionie pomocniczym. Jedyną różnicą jest to, że ustawiają domyślne wystąpienie na 1, ponieważ dotyczy to tylko trybu failover.

   

Czyszczenie zasobów po migracji

Po zakończeniu migracji aplikacja osTicket jest refaktoryzowana do uruchamiania w Azure App Service aplikacji internetowej z ciągłym dostarczaniem przy użyciu prywatnego repozytorium GitHub. Aplikacja działa w dwóch regionach w celu zwiększenia odporności. Baza danych osTicket działa w Azure Database for MySQL po migracji na platformę PaaS.

Aby wyczyścić po migracji, firma Contoso wykonuje następujące czynności:

• Usuwają maszyny wirtualne VMware ze spisu programu vCenter.
• Usuwają lokalne maszyny wirtualne z lokalnych zadań tworzenia kopii zapasowych.
• Aktualizują dokumentację wewnętrzną, aby wyświetlać nowe lokalizacje i adresy IP.
• Przeglądają wszystkie zasoby, które wchodzą w interakcję z lokalnymi maszynami wirtualnymi, i aktualizują wszelkie odpowiednie ustawienia lub dokumentację, aby odzwierciedlić nową konfigurację.
• Konfigurują ponownie monitorowanie, aby wskazywały osticket.trafficmanager.net adres URL, aby śledzić, czy aplikacja jest uruchomiona.

Przegląd wdrożenia

Po uruchomieniu aplikacji firma Contoso musi w pełni zoperalizować i zabezpieczyć nową infrastrukturę.

Zabezpieczenia

Zespół ds. zabezpieczeń firmy Contoso przegląda aplikację, aby określić wszelkie problemy z zabezpieczeniami. Określają one, że komunikacja między aplikacją osTicket i wystąpieniem bazy danych MySQL nie jest skonfigurowana na potrzeby protokołu SSL. Robią to wszystko, aby upewnić się, że ruch bazy danych nie może zostać zhakowany. Dowiedz się więcej.

Tworzenie kopii zapasowych

• Aplikacje internetowe osTicket nie zawierają danych o stanie i w związku z tym nie wymagają tworzenia kopii zapasowej.
• Zespół firmy Contoso nie musi konfigurować kopii zapasowej bazy danych. Usługa Azure Database for MySQL automatycznie tworzy kopie zapasowe i magazyny serwerów. Zespół wybrany do używania nadmiarowości geograficznej dla bazy danych, dzięki czemu jest odporny i gotowy do produkcji. Kopie zapasowe mogą służyć do przywracania serwera do punktu w czasie. Dowiedz się więcej.

Licencjonowanie i optymalizacja kosztów

• Brak problemów z licencjonowaniem dla wdrożenia PaaS.
• Firma Contoso będzie używać usługi Azure Cost Management + Billing , aby upewnić się, że pozostaną w budżetach ustanowionych przez kierownictwo DZIAŁU IT.