Refaktoryzacja aplikacji lokalnej do aplikacji internetowej App Service i wystąpienia zarządzanego SQL

W tym artykule pokazano, jak fikcyjna firma Contoso refaktoryzuje dwuwarstwową aplikację .NET systemu Windows działającą na maszynach wirtualnych VMware w ramach migracji na platformę Azure. Zespół firmy Contoso migruje maszynę wirtualną frontonu aplikacji do aplikacji internetowej Azure App Service. W tym artykule pokazano również, jak firma Contoso migruje bazę danych aplikacji do wystąpienia zarządzanego Azure SQL.

Aplikacja SmartHotel360 używana w tym przykładzie jest udostępniana jako oprogramowanie typu open source. Jeśli chcesz używać go do własnych celów testowych, możesz pobrać go z usługi GitHub.

Biznesowa siła napędowa

Zespół liderów IT firmy Contoso ściśle współpracował z partnerami biznesowymi, aby zrozumieć, co chce osiągnąć dzięki tej migracji:

• Reagowanie na rosnące potrzeby biznesowe. Firma Contoso rozwija się i wywiera presję na lokalne systemy i infrastrukturę firmy.
• Zwiększenie wydajności. Firma Contoso musi usunąć niepotrzebne procedury i usprawnić procesy dla deweloperów i użytkowników. Firma chce, aby dział IT był szybki i nie tracił czasu ani pieniędzy, co pozwoli szybciej realizować wymagania klientów.
• Zwiększenie elastyczności. Dział IT firmy Contoso chce lepiej odpowiadać na zapotrzebowania biznesowe. Aby odnieść sukces w gospodarce globalnej, firma musi być w stanie reagować szybciej niż zmiany na platformie handlowej. Czas reakcji nie może dostać się w drogę lub stać się barierą biznesową.
• Skalowanie. W miarę rozwoju firmy dział IT firmy Contoso musi zapewniać systemy, które mogą rosnąć w tym samym tempie.
• Redukcja kosztów. Firma Contoso chce zminimalizować koszty licencjonowania.

Cele migracji

Aby ułatwić określenie najlepszej metody migracji, zespół ds. chmury firmy Contoso utworzył następujące cele:

Domena wymagań	Szczegóły
Aplikacja	Aplikacja na platformie Azure pozostanie tak krytyczna, jak jest obecnie lokalna. Aplikacja powinna mieć te same możliwości wydajności, które ma obecnie w programie VMware. Zespół nie chce inwestować w aplikację. Na razie administratorzy będą bezpiecznie przenosić aplikację do chmury. Zespół chce przestać obsługiwać system Windows Server 2008 R2, na którym obecnie działa aplikacja. Zespół chce również przenieść się z SQL Server 2008 R2 do nowoczesnej bazy danych platformy jako usługi (PaaS), co zminimalizuje potrzebę zarządzania. Firma Contoso chce skorzystać z inwestycji w licencjonowanie SQL Server i pakiet Software Assurance, gdy jest to możliwe. Firma Contoso chce wyeliminować pojedynczy punkt awarii w warstwie internetowej. Aplikacja składa się z aplikacji ASP.NET i usługi Windows Communication Foundation (WCF) działającej na jednej maszynie wirtualnej. Firma Contoso chce rozpowszechnić te składniki w dwóch aplikacjach internetowych przy użyciu App Service.
Azure	Firma Contoso chce przenieść aplikację na platformę Azure, ale nie chce jej uruchamiać na maszynach wirtualnych. Firma Contoso chce używać usług PaaS platformy Azure dla warstw internetowych i danych.
DevOps	Firma Contoso chce przejść do modelu DevOps, który korzysta z usługi Azure DevOps na potrzeby kompilacji i potoków wydania.

Projekt rozwiązania

Po określeniu celów i wymagań firma Contoso projektuje i przegląda rozwiązanie wdrożeniowe. Zespół identyfikuje również proces migracji, w tym usługi platformy Azure, których będą używać do migracji.

Bieżąca aplikacja

• Aplikacja lokalna SmartHotel360 jest warstwowa na dwóch maszynach wirtualnych, maszynach wirtualnych WEBVM i MASZYNie SQLVM.
• Maszyny wirtualne znajdują się na contosohost1.contoso.com hosta VMware ESXi 6.5.
• Środowisko VMware jest zarządzane przez program vCenter Server 6.5 (vcenter.contoso.com), który działa na maszynie wirtualnej.
• Firma Contoso ma lokalne centrum danych (contoso-datacenter) z lokalnym kontrolerem domeny (contosodc1).
• Lokalne maszyny wirtualne w centrum danych firmy Contoso zostaną zlikwidowane po zakończeniu migracji.

Proponowane rozwiązanie

• W przypadku warstwy internetowej aplikacji firma Contoso będzie używać App Service. Firma Contoso może użyć tej usługi PaaS do wdrożenia aplikacji z zaledwie kilkoma zmianami konfiguracji. Firma Contoso będzie używać programu Visual Studio do wprowadzania zmian, a następnie wdroży dwie aplikacje internetowe, jedną dla witryny internetowej i jedną dla usługi WCF.
• Aby spełnić wymagania dotyczące potoku DevOps, firma Contoso będzie używać usługi Azure DevOps do zarządzania kodem źródłowym za pomocą repozytoriów Git. Użyją zautomatyzowanych kompilacji i wydania, aby skompilować kod i wdrożyć go w App Service.

Zagadnienia dotyczące bazy danych

Podczas procesu projektowania rozwiązania firma Contoso porównuje funkcje usługi Azure SQL Database z funkcjami SQL Managed Instance. Zespół decyduje się na użycie SQL Managed Instance w oparciu o następujące zagadnienia:

• SQL Managed Instance ma na celu zapewnienie niemal 100-procentowej zgodności z najnowszą lokalną wersją SQL Server. Firma Microsoft zaleca SQL Managed Instance dla organizacji, które działają SQL Server lokalnie lub na maszynach wirtualnych typu infrastruktura jako usługa (IaaS) i które chcą migrować aplikacje do w pełni zarządzanej usługi z minimalnymi zmianami projektu.
• Firma Contoso planuje migrację dużej liczby aplikacji ze środowiska lokalnego do maszyn wirtualnych IaaS. Wiele z tych maszyn wirtualnych jest dostarczanych przez niezależnych dostawców oprogramowania. Zespół firmy Contoso zdaje sobie sprawę, że korzystanie z SQL Managed Instance może pomóc zapewnić zgodność bazy danych dla tych aplikacji. Będą używać SQL Managed Instance, a nie SQL Database, co może nie być obsługiwane.
• Firma Contoso może przeprowadzić migrację metodą "lift-and-shift" do SQL Managed Instance przy użyciu w pełni zautomatyzowanego Azure Database Migration Service. Firma Contoso może również ponownie używać tej usługi na potrzeby przyszłych migracji baz danych.
• SQL Managed Instance obsługuje agenta SQL Server, który jest ważnym składnikiem aplikacji SmartHotel360. Firma Contoso potrzebuje tej zgodności. W przeciwnym razie musieliby przeprojektować plany konserwacji wymagane przez aplikację.
• Dzięki programowi Software Assurance firma Contoso może wymienić swoje bieżące licencje na obniżone stawki dla wystąpienia zarządzanego SQL przy użyciu Korzyść użycia hybrydowego platformy Azure dla SQL Server. Dzięki temu firma Contoso może zaoszczędzić nawet 30 procent przy użyciu SQL Managed Instance.
• Wystąpienie zarządzane SQL jest w pełni zawarte w sieci wirtualnej, dlatego zapewnia lepszą izolację i bezpieczeństwo danych firmy Contoso. Firma Contoso może uzyskać korzyści z chmury publicznej, zachowując jednocześnie izolację środowiska od publicznego Internetu.
• SQL Managed Instance obsługuje wiele funkcji zabezpieczeń, w tym Always Encrypted, dynamiczne maskowanie danych, zabezpieczenia Row-Level i wykrywanie zagrożeń.

Przegląd rozwiązania

Zespół firmy Contoso ocenia proponowany projekt, kompilując listę zalet i wad:

Kwestie do rozważenia	Szczegóły
Zalety	Kod aplikacji SmartHotel360 nie wymaga zmian migracji na platformę Azure. Firma Contoso może skorzystać z inwestycji w pakiet Software Assurance przy użyciu Korzyść użycia hybrydowego platformy Azure zarówno dla SQL Server, jak i Windows Server. Po migracji firma Contoso nie będzie musiała obsługiwać systemu Windows Server 2008 R2. Aby uzyskać więcej informacji, zobacz Zasady cyklu życia firmy Microsoft. Firma Contoso może skonfigurować warstwę internetową aplikacji z wieloma wystąpieniami, dzięki czemu warstwa internetowa nie jest już pojedynczym punktem awarii. Baza danych nie będzie już zależeć od wieku programu SQL Server 2008 R2. Wystąpienie zarządzane SQL spełnia wymagania techniczne i cele firmy Contoso. Wystąpienie zarządzane SQL zapewni zgodność z bieżącym wdrożeniem w 100 procentach podczas odejścia od SQL Server 2008 R2. Firma Contoso może ponownie użyć Database Migration Service na potrzeby przyszłych migracji. Wystąpienie zarządzane SQL ma wbudowaną odporność na uszkodzenia, których firma Contoso nie musi konfigurować. Ta odporność na uszkodzenia zapewnia, że warstwa danych nie jest już pojedynczym punktem pracy w trybie failover.
Wady	App Service obsługuje tylko jedno wdrożenie aplikacji dla każdej aplikacji internetowej. Dlatego należy aprowizować dwie aplikacje internetowe: jedną dla witryny internetowej i jedną dla usługi WCF. W przypadku warstwy danych SQL Managed Instance może nie być najlepszym rozwiązaniem, jeśli firma Contoso chce dostosować system operacyjny lub serwer bazy danych lub czy chce uruchamiać aplikacje innych firm wraz z SQL Server. Uruchomienie programu SQL Server na maszynie wirtualnej IaaS może zapewnić taką elastyczność.

Proponowana architektura

Proces migracji

1. Firma Contoso aprowizuje wystąpienie zarządzane Azure SQL, a następnie migruje do niej bazę danych SmartHotel360 przy użyciu Database Migration Service.
2. Firma Contoso aprowizuje i konfiguruje aplikacje internetowe oraz wdraża w nich aplikację SmartHotel360.

Usługi platformy Azure

Usługa	Opis	Koszty
asystent migracji App Service	Bezpłatne, łatwe w użyciu narzędzie, które ułatwia migrowanie aplikacji internetowych platformy .NET ze środowiska lokalnego do chmury z minimalnymi zmianami kodu lub bez wprowadzania zmian w kodzie.	Jest to narzędzie do pobrania, bezpłatne.
Database Migration Service	Usługa platformy Azure, której można użyć do migracji z wielu źródeł baz danych na platformy danych platformy Azure z minimalnym przestojem.	Zobacz Azure Database Migration Service cennik i obsługiwane regiony.
Wystąpienie zarządzane SQL	Zarządzana usługa bazy danych reprezentująca w pełni zarządzane wystąpienie SQL Server na platformie Azure. Używa on tego samego kodu co najnowsza wersja aparatu bazy danych SQL Server i ma najnowsze funkcje, ulepszenia wydajności i poprawki zabezpieczeń.	Użycie wystąpienia zarządzanego SQL na platformie Azure powoduje naliczanie opłat na podstawie pojemności. Dowiedz się więcej o cenach SQL Managed Instance.
Azure App Service	Usługa, która może pomóc w tworzeniu zaawansowanych aplikacji w chmurze korzystających z w pełni zarządzanej platformy.	Cennik jest oparty na rozmiarze, lokalizacji i czasie trwania użycia. Dowiedz się więcej o cenach App Service.
Azure Pipelines	Usługa, która zapewnia potok ciągłej integracji i ciągłego dostarczania (CI/CD) na potrzeby tworzenia aplikacji. Potok rozpoczyna się od repozytorium Git do zarządzania kodem aplikacji, systemem kompilacji do tworzenia pakietów i innych artefaktów kompilacji oraz systemu zarządzania wydaniami na potrzeby wdrażania zmian w środowiskach deweloperskich, testowych i produkcyjnych.	Dowiedz się więcej o cenach usługi Azure Pipelines.

Wymagania wstępne

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

Wymaganie	Szczegóły
Subskrypcja platformy Azure	Firma Contoso utworzyła subskrypcje we wcześniejszym artykule z tej serii. 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ś administratorem, administrator musi przypisać Ci uprawnienia Właściciel lub Współautor.
Infrastruktura platformy Azure	Firma Contoso skonfigurowała infrastrukturę platformy Azure zgodnie z opisem w temacie Infrastruktura platformy Azure na potrzeby migracji.

Etapy scenariusza

Firma Contoso przeprowadzi migrację w następujący sposób:

• Krok 1. Ocena i migracja aplikacji internetowych. Firma Contoso używa asystenta migracji App Service do przeprowadzania kontroli zgodności przed migracją i migrowania aplikacji internetowych do App Service.
• Krok 2. Konfigurowanie wystąpienia zarządzanego SQL. Firma Contoso potrzebuje istniejącego wystąpienia zarządzanego, do którego zostanie zmigrowana lokalna baza danych programu SQL Server.
• Krok 3. Migrowanie przy użyciu Database Migration Service. Firma Contoso migruje bazę danych aplikacji przy użyciu Database Migration Service.
• Krok 4. Konfigurowanie usługi Azure DevOps. Firma Contoso tworzy nowy projekt usługi Azure DevOps i importuje repozytorium Git.
• Krok 5. Konfigurowanie parametrów połączenia. Firma Contoso konfiguruje parametry połączenia, aby aplikacja internetowa warstwy internetowej, aplikacja internetowa usługi WCF i wystąpienie zarządzane SQL mogły komunikować się.
• Krok 6. Konfigurowanie potoków kompilacji i wydania w usłudze Azure DevOps. W ostatnim kroku firma Contoso konfiguruje potoki kompilacji i wydania w usłudze Azure DevOps w celu utworzenia aplikacji. Następnie zespół wdraża potoki w dwóch oddzielnych aplikacjach internetowych.

Krok 1. Ocena i migracja aplikacji internetowych

Administratorzy firmy Contoso oceniają i migrują swoje aplikacje internetowe przy użyciu asystenta migracji App Service. W trakcie procesu używają ścieżki szkoleniowej Migrate ASP.NET Apps do platformy Azure . Administratorzy wykonują następujące akcje:

• Używają narzędzia do oceny migracji App Service, aby ocenić wszelkie zależności między aplikacjami internetowymi i określić, czy istnieją niezgodności między lokalnymi aplikacjami internetowymi a tym, co jest obsługiwane przez App Service.

• Pobierają asystenta migracji App Service i logują się na swoje konto platformy Azure.

• Wybierają subskrypcję, grupę zasobów i nazwę domeny witryny internetowej.

Krok 2. Konfigurowanie wystąpienia zarządzanego SQL

Aby skonfigurować wystąpienie zarządzane Azure SQL, firma Contoso potrzebuje podsieci spełniającej następujące wymagania:

• Podsieć musi być dedykowana. Musi być pusty. Nie może zawierać żadnej innej usługi w chmurze. Podsieć nie może być podsiecią bramy.
• Po utworzeniu wystąpienia zarządzanego firma Contoso nie powinna dodawać zasobów do podsieci.
• Z podsiecią nie może być skojarzona żadna sieciowa grupa zabezpieczeń.
• Podsieć musi mieć zdefiniowaną przez użytkownika tabelę tras. Jedyną przypisaną trasą powinna być 0.0.0.0/0 z następnym przeskokiem do Internetu.
• Jeśli dla sieci wirtualnej określono opcjonalny niestandardowy system DNS, do listy należy dodać wirtualny adres IP 168.63.129.16 dla cyklicznych rozpoznawania nazw na platformie Azure. Dowiedz się, jak skonfigurować niestandardowy system DNS dla wystąpienia zarządzanego Azure SQL.
• Z podsiecią nie może być skojarzony żaden punkt końcowy usługi (magazyn lub SQL). Punkty końcowe usługi powinny być wyłączone w sieci wirtualnej.
• Podsieć musi mieć co najmniej 16 adresów IP. Dowiedz się, jak określać rozmiar podsieci wystąpienia zarządzanego.
• W środowisku hybrydowym firmy Contoso wymagane są niestandardowe ustawienia DNS. Firma Contoso skonfiguruje ustawienia DNS, aby używać co najmniej jednego serwera DNS platformy Azure firmy. Dowiedz się więcej o dostosowywaniu serwerów DNS.

Konfigurowanie sieci wirtualnej dla wystąpienia zarządzanego

Administratorzy firmy Contoso konfigurują sieć wirtualną w następujący sposób:

1. Tworzą sieć wirtualną (VNET-SQLMI-EUS2) w regionie podstawowym (Wschodnie stany USA 2). Tworzą sieć wirtualną w grupie zasobów ContosoNetworkingRG.

2. Przypisują przestrzeń adresową 10.235.0.0/24. Zapewniają one, że zakres nie nakłada się na żadne inne sieci w przedsiębiorstwie.

3. Dodają dwie podsieci do sieci:

   • SQLMI-DB-EUS2 (10.235.0.0/25).

   • SQLMI-SAW-EUS2 (10.235.0.128/29). Ta podsieć służy do dołączania katalogu do wystąpienia zarządzanego.

     

4. Po wdrożeniu sieci wirtualnej i podsieci sieci są one łączone równorzędnie w następujący sposób:

   • Równorzędna sieć wirtualna-SQLMI-EUS2 z siecią wirtualną VNET-HUB-EUS2 (sieć wirtualna piasty dla wschodnich stanów USA 2).

   • Sieć równorzędna VNET-SQLMI-EUS2 z siecią wirtualną VNET-PROD-EUS2 (siecią produkcyjną).

     

5. Określają niestandardowe ustawienia DNS. Ustawienia DNS najpierw wskazują kontrolery domeny platformy Azure firmy Contoso. Serwer DNS platformy Azure jest pomocniczy. Kontrolery domeny platformy Azure firmy Contoso znajdują się w następujących lokalizacjach:

   • Znajdują się one w podsieci PROD-DC-EUS2 sieci produkcyjnej (VNET-PROD-EUS2) w regionie Wschodnie stany USA 2.

   • Adres CONTOSODC3: 10.245.42.4

   • Adres CONTOSODC4: 10.245.42.5

   • Rozpoznawanie nazw dns platformy Azure: 168.63.129.16

   

Potrzebujesz dodatkowej pomocy?

• Przeczytaj omówienie SQL Managed Instance.
• Dowiedz się, jak utworzyć sieć wirtualną dla wystąpienia zarządzanego SQL.
• Dowiedz się, jak skonfigurować komunikację równorzędną.
• Dowiedz się, jak zaktualizować ustawienia DNS usługi Azure Active Directory.

Konfigurowanie routingu

Wystąpienie zarządzane jest umieszczane w prywatnej sieci wirtualnej. Firma Contoso potrzebuje tabeli tras, aby umożliwić sieci wirtualnej komunikowanie się z usługą zarządzania platformą Azure. Jeśli sieć wirtualna nie może komunikować się z usługą, która nią zarządza, ta sieć wirtualna staje się niedostępna.

Firma Contoso bierze pod uwagę następujące czynniki:

• Tabela tras zawiera zestaw reguł (tras), które określają sposób kierowania pakietów wysyłanych z wystąpienia zarządzanego w sieci wirtualnej.
• Tabela tras jest skojarzona z podsieciami, w których są wdrażane wystąpienia zarządzane. Każdy pakiet, który opuszcza podsieć, jest obsługiwany na podstawie skojarzonej tabeli tras.
• Podsieć może być skojarzona tylko z jedną tabelą tras.
• Za tworzenie tabel tras na platformie Azure nie są naliczane żadne dodatkowe opłaty.

Aby skonfigurować routing, administratorzy firmy Contoso wykonaj następujące kroki:

1. Tworzą tabelę tras zdefiniowaną przez użytkownika w grupie zasobów ContosoNetworkingRG :

   

2. Aby spełnić SQL Managed Instance wymagania, po wdrożeniu tabeli tras (MIRouteTable) administratorzy dodają trasę z prefiksem adresu 0.0.0.0/0. Ustawiają wartość typu Następny przeskok na Internet:

   

3. Kojarzą tabelę tras z podsiecią SQLMI-DB-EUS2 w sieci VNET-SQLMI-EUS2:

   

Potrzebujesz dodatkowej pomocy?

Dowiedz się, jak skonfigurować trasy dla wystąpienia zarządzanego.

Tworzenie wystąpienia zarządzanego

Następnie administratorzy firmy Contoso aprowizją wystąpienie zarządzane SQL, wykonując następujące kroki:

1. Ponieważ wystąpienie zarządzane obsługuje aplikację biznesową, administratorzy wdrażają wystąpienie zarządzane w regionie podstawowym firmy (Wschodnie stany USA 2). Dodają wystąpienie zarządzane do grupy zasobów ContosoRG.

2. Wybierają warstwę cenową, rozmiar obliczeniowy i magazyn dla wystąpienia. Dowiedz się więcej o cenach SQL Managed Instance.

   

   Po wdrożeniu wystąpienia zarządzanego w grupie zasobów ContosoRG są wyświetlane dwa nowe zasoby:

   • Wystąpienie zarządzane SQL.

   • Klaster wirtualny, na wypadek gdyby firma Contoso ma wiele wystąpień zarządzanych.

     

Potrzebujesz dodatkowej pomocy?

Dowiedz się, jak aprowizować wystąpienie zarządzane.

Krok 3. Migrowanie przy użyciu Database Migration Service

Administratorzy firmy Contoso migrują wystąpienie zarządzane przy użyciu Database Migration Service. Postępują zgodnie z instrukcjami w samouczku dotyczącym migracji krok po kroku. Mogą wykonywać migracje online, offline i hybrydowe (wersja zapoznawcza).

Administratorzy firmy Contoso wykonaj następujące czynności:

• Tworzą wystąpienie Database Migration Service przy użyciu jednostki SKU w warstwie Premium połączonej z siecią wirtualną.
• Zapewniają one Database Migration Service dostęp do zdalnego wystąpienia SQL Server za pośrednictwem sieci wirtualnej. Ten krok obejmuje upewnienie się, że wszystkie porty przychodzące z platformy Azure mogą SQL Server na poziomie sieci wirtualnej, sieci VPN i maszyny, która hostuje SQL Server.
• Konfigurują Database Migration Service:
  • Utwórz projekt migracji.
  • Dodaj źródło (lokalną bazę danych).
  • Wybierz element docelowy.
  • Wybierz bazy danych do migracji.
  • Konfigurowanie ustawień zaawansowanych.
  • Uruchom replikację.
  • Usuń wszelkie błędy.
  • Wykonaj ostateczną migrację jednorazową.

Krok 4. Konfigurowanie usługi Azure DevOps

Firma Contoso musi utworzyć infrastrukturę metodyki DevOps i potoki dla aplikacji. W tym celu administratorzy firmy Contoso tworzą nowy projekt DevOps, importują kod, a następnie konfigurują potoki kompilacji i wydania.

1. Na koncie usługi Azure DevOps firmy Contoso tworzą nowy projekt ContosoSmartHotelRefactor, a następnie wybierają pozycję Git w celu kontroli wersji.

   

2. Importują repozytorium Git, które obecnie przechowuje kod aplikacji. Pobierają go z publicznego repozytorium GitHub.

   

3. Łączą program Visual Studio z repozytorium, a następnie klonują kod na maszynę dewelopera przy użyciu programu Team Explorer.

   

4. Otwierają plik rozwiązania dla aplikacji. Aplikacja internetowa i usługa WCF mają oddzielne projekty w pliku.

   

Krok 5. Konfigurowanie parametrów połączenia

Administratorzy firmy Contoso zapewniają, że aplikacje internetowe i baza danych mogą komunikować się ze sobą. W tym celu konfigurują parametry połączenia w kodzie i w aplikacjach internetowych.

1. W aplikacji internetowej dla usługi WCF SHWCF-EUS2 w obszarze Ustawienia>ustawienia aplikacji dodają nowe parametry połączenia o nazwie DefaultConnection.

2. Pobierają parametry połączenia z bazy danych SmartHotel-Registration, a następnie aktualizują je przy użyciu poprawnych poświadczeń:

   

3. W programie Visual Studio administratorzy otwierają projekt SmartHotel.Registration.wcf z pliku rozwiązania. W projekcie aktualizują sekcję connectionStrings pliku web.config, dodając parametry połączenia:

   

4. Aktualizują sekcję client pliku web.config smartHotel.Registration.Web, tak aby wskazuje nową lokalizację usługi WCF. Wskaźnik jest adresem URL aplikacji internetowej WCF, która hostuje punkt końcowy usługi.

   

5. Administratorzy zatwierdzają i synchronizują zmiany kodu przy użyciu programu Team Explorer w programie Visual Studio.

Krok 6. Konfigurowanie potoków kompilacji i wydania w usłudze Azure DevOps

Administratorzy firmy Contoso konfigurują teraz usługę Azure DevOps do wykonywania procesu kompilacji i wydania.

1. W usłudze Azure DevOps wybierają pozycję Kompiluj i wydaj>nowy potok:

   

2. Wybierają Azure Repos git i odpowiednie repozytorium:

   

3. W obszarze Wybierz szablon wybierają szablon ASP.NET dla swojej kompilacji:

   

4. Używają nazwy ContosoSmartHotelRefactor-ASP.NET-CI dla kompilacji, a następnie wybierają pozycję Zapisz & kolejkę, która inicjuje pierwszą kompilację.

   

5. Wybierają numer kompilacji, aby mogli obserwować proces. Po zakończeniu procesu administratorzy mogą zobaczyć opinię na temat procesu. Wybierają pozycję Artefakty , aby przejrzeć wyniki kompilacji:

   

   Zostanie otwarte okno Eksplorator artefaktów . Wyniki kompilacji są widoczne w folderze drop .

   • Dwa pliki .zip to pakiety zawierające aplikacje.
   • Te pliki .zip są używane w potoku wydania do wdrożenia w celu App Service.

   

6. Wybierają pozycję Wydania>Nowy potok:

   

7. Wybierają szablon wdrożenia dla App Service:

   

8. Nazwa potoku wydania ContosoSmartHotel360Refactor i w polu Nazwa etapu podaj nazwę SHWCF-EUS2 jako nazwę aplikacji internetowej WCF:

   

9. W ramach etapów wybierają 1 zadanie, 1 zadanie do skonfigurowania wdrożenia usługi WCF:

   

10. Sprawdzają, czy subskrypcja została wybrana i autoryzowana, a następnie wybierają nazwę usługi App Service:

    

11. W potoku wybierają pozycję Artefakty, wybierz pozycję Dodaj artefakt, wybierz pozycję Kompiluj jako typ źródła, a następnie skompilują przy użyciu potoku ContosoSmarthotel360Refactor :

    

12. Aby włączyć wyzwalacz ciągłego wdrażania, administratorzy wybierają przycisk piorun na artefaktie:

    

13. Ustawiają wyzwalacz ciągłego wdrażania na włączone:

    

14. Administratorzy wracają do etapu 1 zadania, 1 zadania i wybierają pozycję Wdróż Azure App Service:

    

15. W obszarze Wybierz plik lub folder rozwiń folder listy rozwijanej , wybierz plikSmartHotel.Registration.Wcf.zip utworzony podczas kompilacji, a następnie wybierz pozycję Zapisz:

    

16. Wybierająpozycję Etapypotoku>, a następnie wybierają pozycję Dodaj, aby dodać środowisko dla programu SHWEB-EUS2. Wybierają inne wdrożenie usługi Azure App Service.

    

17. Powtarzają proces publikowania aplikacji internetowej SmartHotel.Registration.Web.zip pliku w odpowiedniej aplikacji internetowej, a następnie wybierają pozycję Zapisz:

    

    Potok wydania jest wyświetlany, jak pokazano poniżej:

    

18. Wracają do pozycji Kompilacja, wybierają pozycję Wyzwalacze, a następnie wybierają pozycję Włącz ciągłą integrację. Ta akcja umożliwia potok, aby po zatwierdzeniu zmian w kodzie nastąpiła pełna kompilacja i wydanie.

    

19. Wybierają pozycję Zapisz & kolejkę , aby uruchomić pełny potok. Zostanie wyzwolona nowa kompilacja, która z kolei utworzy pierwszą wersję aplikacji do App Service.

    

20. Administratorzy firmy Contoso mogą wykonywać kroki procesu potoku kompilowania i wydawania z poziomu usługi Azure DevOps. Po zakończeniu kompilacji wydanie zostanie uruchomione:

    

21. Po zakończeniu potoku obie lokacje są wdrażane, a aplikacja działa w trybie online:

    

    Aplikacja została pomyślnie zmigrowana na platformę Azure.

Czyszczenie po migracji

Po zakończeniu migracji zespół firmy Contoso wykonuje następujące kroki oczyszczania:

• Usuwają lokalne maszyny wirtualne ze spisu programu vCenter.
• Usuwają maszyny wirtualne z lokalnych zadań tworzenia kopii zapasowych.
• Aktualizują dokumentację wewnętrzną, aby wyświetlić nowe lokalizacje aplikacji SmartHotel360. W dokumentacji pokazano, że baza danych działa w wystąpieniu zarządzanym SQL i że fronton działa w dwóch aplikacjach internetowych.
• Przejrzyją wszystkie zasoby, które wchodzą w interakcję z zlikwidowanymi maszynami wirtualnymi, i aktualizują wszelkie odpowiednie ustawienia lub dokumentację, aby odzwierciedlić nową konfigurację.

Przegląd wdrożenia

Po przeprowadzeniu migracji zasobów na platformę Azure firma Contoso musi w pełni zoperacjonalizować nową infrastrukturę i zapewnić jej bezpieczeństwo.

Zabezpieczenia

• Firma Contoso zapewnia bezpieczeństwo nowej bazy danych SmartHotel-Registration. Aby uzyskać więcej informacji, zobacz Azure SQL Database and SQL Managed Instance security (Zabezpieczenia usługi Azure SQL Database i SQL Managed Instance).
• W szczególności firma Contoso aktualizuje aplikacje internetowe do używania protokołu SSL z certyfikatami.

Tworzenie kopii zapasowych

• Zespół firmy Contoso sprawdza wymagania dotyczące tworzenia kopii zapasowych bazy danych w SQL Managed Instance. Aby uzyskać więcej informacji, zobacz Automatyczne kopie zapasowe w usłudze Azure SQL Database.
• Dowiesz się również, jak zarządzać SQL Database kopiami zapasowymi i przywracaniem. Aby uzyskać więcej informacji, zobacz automatyczne kopie zapasowe.
• Rozważą zaimplementowanie grup trybu failover w celu zapewnienia regionalnego trybu failover dla bazy danych. Aby uzyskać więcej informacji, zobacz Omówienie grup automatycznego trybu failover.
• Rozważą wdrożenie aplikacji internetowej w regionie głównym (Wschodnie stany USA 2) i regionie pomocniczym (Środkowe stany USA) w celu uzyskania odporności. Zespół może skonfigurować usługę Traffic Manager w celu zapewnienia przejścia w tryb failover podczas regionalnych awarii.

Licencjonowanie i optymalizacja kosztów

• Po wdrożeniu wszystkich zasobów firma Contoso przypisuje tagi platformy Azure, które zdecydowały podczas planowania infrastruktury.
• Wszystkie licencje są wbudowane w koszt usług PaaS używanych przez firmę Contoso. Ten koszt jest odliczany od Enterprise Agreement.
• Firma Contoso będzie używać usługi Azure Cost Management i rozliczeń , aby upewnić się, że działają one w budżetach ustanowionych przez ich kierownictwo IT.

Podsumowanie

W tym artykule firma Contoso refaktoryzowała aplikację SmartHotel360 na platformie Azure, migrując maszynę wirtualną frontonu aplikacji do dwóch aplikacji internetowych App Service. Firma Contoso przeprowadziła migrację bazy danych aplikacji do wystąpienia zarządzanego Azure SQL.