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).

Diagram bieżącej architektury.

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.

Diagram architektury scenariusza.

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.

Diagram procesu migracji firmy Contoso.

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 .

    Zrzut ekranu przedstawiający okienko Aplikacja internetowa do tworzenia aplikacji internetowej w systemie Linux.

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

    Zrzut ekranu przedstawiający okienko Nowy plan App Service do tworzenia planu App Service.

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

    Zrzut ekranu przedstawiający okienko Aplikacja internetowa z wybranym systemem operacyjnym Linux, lokalizacją Wschodnie stany USA 2 i językiem PHP 7.0.

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

    Zrzut ekranu przedstawiający okienko Aplikacja internetowa z wybranym systemem operacyjnym Linux, centralną lokalizacją USA i językiem PHP 7.0.

Potrzebujesz dodatkowej pomocy?

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ą.

    Zrzut ekranu przedstawiający okienko Tworzenie profilu usługi Traffic Manager.

  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ą.

    Zrzut ekranu przedstawiający okienko Dodawanie punktu końcowego w usłudze Traffic Manager.

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

    Zrzut ekranu przedstawiający okienko Punkty końcowe monitorowania punktów końcowych w usłudze Traffic Manager.

Potrzebujesz dodatkowej pomocy?

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.

    Zrzut ekranu przedstawiający link Azure Database for MySQL w Azure Portal.

  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.

    Zrzut ekranu przedstawiający okienko Serwer MySQL z wybraną wersją 5.7.

  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.

    Zrzut ekranu przedstawiający okienko Opcje nadmiarowości kopii zapasowej z wybraną opcją Geo-Redundant.

  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ę.

    Zrzut ekranu przedstawiający okienko Zabezpieczenia połączenia z włączonym dostępem do usług platformy Azure i wybranym adresem IP klienta.

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.

      Zrzut ekranu przedstawiający okienko Przegląd bazy danych MySQL z komunikatem informującym o pomyślnym utworzeniu usługi migracji.

      Zrzut ekranu przedstawiający okienko nowy projekt migracji MySQL.

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

      Zrzut ekranu przedstawiający okienko Dodawanie szczegółów źródła w kreatorze migracji.

    3. Wybierz element docelowy.

      Zrzut ekranu przedstawiający okienko Szczegóły elementu docelowego kreatora migracji.

    4. Wybierz bazy danych do migracji.

      Zrzut ekranu przedstawiający okienko Kreator migracji Mapowanie na docelowe bazy danych.

    5. Konfigurowanie ustawień zaawansowanych.

      Zrzut ekranu przedstawiający okienko Ustawienia migracji kreatora migracji.

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

      Zrzut ekranu przedstawiający okienko szczegółów serwera.

    7. Wykonaj ostatnią operację przecięcia.

      Zrzut ekranu przedstawiający okienko szczegółów osTicket.

      Zrzut ekranu przedstawiający okienko Ukończone przełączanie jednorazowe.

      Zrzut ekranu przedstawiający tabelę stanu działań migracji.

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

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

      Zrzut ekranu przedstawiający tabelę Działania migracji.

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ą .

    Zrzut ekranu przedstawiający okienko szczegółów połączenia programu MySQL Workbench.

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

    Zrzut ekranu przedstawiający okienko Eksportowanie danych programu MySQL Workbench.

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

    Okienko Konfigurowanie nowego połączenia w programie MySQL Workbench.

  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, .

    Zrzut ekranu przedstawiający okienko Importowanie danych programu MySQL Workbench.

  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.

    Zrzut ekranu przedstawiający Azure Portal z wyświetlonymi przywróconych danych.

    Zrzut ekranu przedstawiający blok Bazy danych MySQL ze strzałką wskazującą bazę danych osTicket.

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

    Zrzut ekranu przedstawiający link Parametry połączenia w wystąpieniu programu MySQL.

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

    Zrzut ekranu przedstawiający ustawienia aplikacji internetowej w wystąpieniu programu MySQL.

  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ń.

    Zrzut ekranu przedstawiający parametry połączenia wklejone w pliku Notatnika.

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

    Zrzut ekranu przedstawiający okienko grupy zasobów z wyświetloną nazwą serwera i nazwą konta administratora serwera.

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.

    Zrzut ekranu przedstawiający stronę repozytorium GitHub z wyróżnionym przyciskiem Rozwidlenie.

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

    Zrzut ekranu przedstawiający plik PHP w usłudze GitHub.

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

    Zrzut ekranu przedstawiający ikonę edytowania pliku (ołówka) w usłudze GitHub.

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

    Zrzut ekranu przedstawiający okienko edycji pliku w usłudze GitHub.

  5. Zatwierdzają zmiany.

    Zrzut ekranu przedstawiający przycisk Zatwierdź zmiany w okienku edycji.

  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.

    Zrzut ekranu przedstawiający link Ustawienia aplikacji w Azure Portal.

  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.

    Zrzut ekranu przedstawiający okienko Parametry połączenia z wyróżnionymi parametrami połączenia osTicket.

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.

    Zrzut ekranu przedstawiający okienko opcji Wdrożenie z usługą GitHub wybraną jako źródło.

  2. Wybierają opcje wdrażania.

    Zrzut ekranu przedstawiający szczegóły opcji w okienku opcji Wdrożenie.

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

    Zrzut ekranu przedstawiający okienko Opcje wdrożenia z oczekującym stanem witryny.

  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.

    Zrzut ekranu przedstawiający okienko Opcje wdrażania.

  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.

    Zrzut ekranu przedstawiający okienko profilu usługi Traffic Manager z wyświetloną nazwą DNS.

  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.

    Zrzut ekranu przedstawiający okienko Nowy rekord zasobu z nazwą aliasu i wskaźnikiem do usługi Traffic Manager.

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

    Zrzut ekranu przedstawiający okienko Nazwa hosta usługi Ad z wyróżnionym przyciskiem Weryfikuj.

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.

    Zrzut ekranu przedstawiający stronę ustawień autoskalowania dla pierwszego regionu.

  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.

    Zrzut ekranu przedstawiający stronę ustawień autoskalowania dla drugiego regionu.

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.