Migrowanie aplikacji serwera WebLogic do aplikacji JBoss EAP w usłudze aplikacja systemu Azure

  • Artykuł

W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz migrować istniejącą aplikację serwera WebLogic do uruchamiania w usłudze aplikacja systemu Azure przy użyciu protokołu EAP JBoss.

Przed migracją

Aby zapewnić pomyślną migrację, przed rozpoczęciem wykonaj kroki oceny i spisu opisane w poniższych sekcjach.

Jeśli nie możesz spełnić żadnego z tych wymagań przed migracją, zapoznaj się z przewodnikiem po migracji towarzyszącej, aby przeprowadzić migrację aplikacji do usługi Virtual Machines: Migrowanie aplikacji serwera WebLogic do usługi Azure Virtual Machines

Utworzenie spisu pojemności serwerów

Udokumentowanie sprzętu (pamięci, procesora CPU, dysku) bieżących serwerów produkcyjnych oraz średniej i szczytowej liczby żądań oraz wykorzystania zasobów. Te informacje będą potrzebne niezależnie od wybranej ścieżki migracji. Jest to przydatne, na przykład, aby ułatwić wybór planu usługi App Service.

Lista dostępnych warstw planu usługi App Service zawiera informacje o pamięci, rdzeniach procesora CPU, magazynie i cenach. Należy pamiętać, że protokół JBoss EAP w usłudze App Service jest dostępny tylko w warstwach Premium V3 i Izolowany plan usługi App Service w wersji 2 .

Utworzenie spisu wszystkich wpisów tajnych

Przed pojawieniem się technologii typu „konfiguracja jako usługa”, takich jak usługa Azure Key Vault, nie było dobrze zdefiniowanego pojęcia „wpisu tajnego”. Zamiast tego korzystano z odrębnych zestawów ustawień konfiguracji, które efektywnie funkcjonowały jak dzisiejsze „wpisy tajne”. W przypadku serwerów aplikacji, takich jak serwer WebLogic, te wpisy tajne znajdują się w wielu różnych plikach konfiguracji i w magazynach konfiguracji. Sprawdź wszystkie pliki właściwości i konfiguracji na serwerach produkcyjnych kątem jakichkolwiek wpisów tajnych i haseł. Sprawdź plik weblogic.xml w swoich plikach WAR. Możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia wewnątrz aplikacji. Aby uzyskać więcej informacji, zobacz Podstawowe pojęcia dotyczące usługi Azure Key Vault.

Utworzenie spisu wszystkich certyfikatów

Zapisz wszystkie certyfikaty używane na potrzeby publicznych punktów końcowych protokołu SSL. Wszystkie certyfikaty na serwerach produkcyjnych można wyświetlić, uruchamiając następujące polecenie:

keytool -list -v -keystore <path to keystore>

Utworzenie spisu zasobów JNDI

Utwórz spis wszystkich zasobów JNDI. Na przykład źródła danych, takie jak bazy danych, mogą mieć skojarzoną nazwę JNDI, która umożliwia interfejsowi JPA prawidłowe powiązanie wystąpień EntityManager z określoną bazą danych. Aby uzyskać więcej informacji na temat zasobów i baz danych JNDI, zobacz WebLogic Server Data Sources (Źródła danych serwera WebLogic) w dokumentacji firmy Oracle. Inne zasoby związane z JNDI, takie jak broker komunikatów JMS, mogą wymagać migracji lub ponownej konfiguracji. Aby uzyskać więcej informacji na temat konfiguracji pakietu JMS, zobacz Oracle WebLogic Server 12.2.1.4.0.

Sprawdzanie konfiguracji domeny

Główną jednostką konfiguracji na serwerze WebLogic jest domena. W związku z tym plik config.xml zawiera wiele konfiguracji, nad którymi trzeba dokładnie się zastanowić podczas migracji. Plik zawiera odwołania do dodatkowych plików XML przechowywanych w podkatalogach. Firma Oracle radzi, aby do konfigurowania obiektów i usług zarządzanych przez serwer WebLogic używać zazwyczaj konsoli administracyjnej oraz zezwalać serwerowi WebLogic na obsługę pliku config.xml. Aby uzyskać więcej informacji, zobacz Pliki konfiguracji domeny.

W aplikacji

Sprawdź WEB-INF/weblogic.xml i/lub plik WEB-INF/web.xml.

Określenie, czy jest używana replikacja sesji

Jeśli aplikacja korzysta z replikacji sesji, z modułem Oracle Coherence*Web lub bez niego, masz dwie możliwości:

  • Refaktoryzacja aplikacji w celu użycia bazy danych do zarządzania sesją.
  • Refaktoryzacja aplikacji w celu eksternalizacji sesji do usługi Azure Redis. Aby uzyskać więcej informacji, zobacz Pamięć podręczna Azure Cache for Redis.

W przypadku wszystkich tych opcji dobrym pomysłem jest opanowanie sposobu wykonywania replikacji stanu sesji HTTP przez serwer WebLogic. Aby uzyskać więcej informacji, zobacz temat HTTP Session State Replication (Replikacja stanu sesji HTTP) w dokumentacji firmy Oracle.

Udokumentowanie źródeł danych

Jeśli aplikacja korzysta z dowolnych baz danych, należy przechwycić następujące informacje:

  • Jaka jest nazwa źródła danych?
  • Jaka jest konfiguracja puli połączeń?
  • Gdzie mogę znaleźć plik JAR sterownika JDBC?

Aby uzyskać więcej informacji na temat sterowników JDBC w usłudze WebLogic, zobacz Using JDBC Drivers with WebLogic Server (Korzystanie ze sterowników JDBC z serwerem WebLogic).

Ustalanie, czy oprogramowanie WebLogic zostało dostosowane

Ustal, które z następujących dostosowań zostały wdrożone, i określ, jakie działania zostały wykonane.

  • Czy zostały zmienione skrypty uruchamiania? Takie skrypty to setDomainEnv, commEnv, startWebLogic i stopWebLogic.
  • Czy do środowiska JVM są przekazywane określone parametry?
  • Czy do ścieżki klas serwera zostały dodane pliki JAR?

Określenie, czy jest konieczne połączenie z lokalną usługą

Jeśli aplikacja wymaga dostępu do dowolnych usług lokalnych, musisz aprowizować jedną z usług łączności platformy Azure. Aby uzyskać więcej informacji, zobacz Wybieranie rozwiązania do łączenia sieci lokalnej z platformą Azure. Możesz również przeprowadzić refaktoryzację aplikacji, aby korzystać z publicznie dostępnych interfejsów API uwidacznianych przez Twoje zasoby lokalne.

Określanie, czy używane są kolejki lub tematy Java Message Service (JMS)

Jeśli aplikacja korzysta z kolejek lub tematów JMS, należy je zmigrować do zewnętrznie hostowanego serwera JMS. Usługa Azure Service Bus i protokół Advanced Message Queuing Protocol (AMQP) mogą stanowić doskonałą strategię migracji w przypadku korzystania z usługi JMS. Aby uzyskać więcej informacji, zobacz Używanie usługi JMS z usługą Azure Service Bus i protokołem AMQP 1.0.

W przypadku skonfigurowania magazynów trwałych usługi JMS należy przechwycić ich konfigurację i zastosować ją po migracji.

Ustalanie, czy są używane niestandardowe, udostępnione biblioteki Java EE

Jeśli korzystasz z funkcji udostępnionych bibliotek Java EE, masz dwie opcje:

  • Przeprowadź refaktoryzację kodu aplikacji, usuwając wszystkie zależności od bibliotek, i dołącz funkcje bezpośrednio do aplikacji.
  • Dodaj biblioteki do ścieżki klas serwera.

Określanie, czy są używane pakiety technologii OSGi

Jeśli użyto pakietów technologii OSGi dodanych do serwera WebLogic, należy dodać równoważne pliki JAR bezpośrednio do aplikacji internetowej.

Określanie, czy aplikacja zawiera kod właściwy dla systemu operacyjnego

Jeśli aplikacja zawiera dowolny kod z zależnościami w systemie operacyjnym hosta, musisz przeprowadzić jej refaktoryzację, aby usunąć te zależności. Na przykład może być konieczne zastąpienie każdego użycia symbolu / lub \ w ścieżkach systemu plików przez File.Separator lub Paths.get.

Określenie, czy używana jest magistrala usług Oracle Service Bus

Jeśli aplikacja korzysta z magistrali usług Oracle Service Bus (OSB), należy przechwycić sposób konfiguracji OSB. Aby uzyskać więcej informacji, zobacz About the Oracle Service Bus Installation (Informacje dotyczące instalacji magistrali usług Oracle Service Bus).

Ustalanie, czy aplikacja składa się z wielu plików WAR

Jeśli Twoja aplikacja składa się z wielu plików WAR, należy traktować poszczególne pliki jako oddzielne aplikacje. W przypadku każdej z nich należy wykonać instrukcje opisane w tym przewodniku.

Ustalanie, czy aplikacja jest spakowana jako plik EAR

Jeśli Twoja aplikacja jest spakowana jako plik EAR, zarejestruj konfiguracje plików application.xml i weblogic-application.xml.

Identyfikacja wszystkich procesów i demonów zewnętrznych działających na serwerach produkcyjnych

Jeśli masz jakiekolwiek procesy działające poza serwerem aplikacji, takie jak demony monitorowania, musisz wyeliminować je lub zmigrować do innego miejsca.

Sprawdzanie, czy obsługiwana wersja języka Java działa poprawnie

Protokół JBoss EAP w usłudze aplikacja systemu Azure obsługuje środowisko Java 8 i 11. Dlatego musisz sprawdzić, czy Twoja aplikacja może działać prawidłowo, używając tej obsługiwanej wersji. Ta weryfikacja jest szczególnie ważna, jeśli bieżący serwer używa obsługiwanego zestawu JDK (na przykład Oracle JDK lub IBM OpenJ9).

Aby uzyskać informacje na temat bieżącej wersji języka Java, zaloguj się na serwerze produkcyjnym i uruchom następujące polecenie:

java -version

Określanie, czy Twoja aplikacja bazuje na zaplanowanych zadaniach

Zaplanowane zadania, takie jak zadania usługi Quartz Scheduler lub zadania cron systemu Unix, nie powinny być używane z usługą aplikacja systemu Azure Service. usługa aplikacja systemu Azure nie uniemożliwi wdrażania aplikacji zawierającej zaplanowane zadania wewnętrznie. Jeśli jednak aplikacja jest skalowana w poziomie, to samo zaplanowane zadanie może zostać uruchomione więcej niż raz w zaplanowanym okresie. Ta sytuacja może prowadzić do niezamierzonych konsekwencji.

Aby wykonać zaplanowane zadania na platformie Azure, rozważ użycie usługi Azure Functions z wyzwalaczem czasomierza. Aby uzyskać więcej informacji, zobacz Wyzwalacz czasomierza dla usługi Azure Functions. Nie musisz migrować kodu zadania do funkcji. Aby wyzwolić zadanie, funkcja może po prostu wywoływać adres URL w aplikacji.

Uwaga

Aby zapobiec złośliwemu użyciu, prawdopodobnie trzeba będzie wprowadzić wymaganie podania poświadczeń w punkcie końcowym wywoływania zadania. W takim przypadku poświadczenia muszą zostać podane przez funkcję wyzwalacza.

Ustalanie, czy jest używane narzędzie WebLogic Scripting Tool (WLST)

Jeśli obecnie używasz narzędzia WLST do wykonania wdrożenia, musisz ocenić, co robi. Jeśli WLST zmienia jakiekolwiek parametry aplikacji (runtime) w ramach wdrożenia, należy upewnić się, że te parametry są zgodne z jedną z następujących opcji:

  • Są one uzewnętrzniane jako ustawienia aplikacji.
  • Są one osadzone w aplikacji.
  • Podczas wdrażania korzystają one z interfejsu wiersza polecenia JBoss.

Jeśli WLST wykonuje więcej niż to, co zostało wymienione powyżej, będziesz mieć dodatkową pracę do wykonania podczas migracji.

Określanie, czy aplikacja używa interfejsów API specyficznych dla serwera WebLogic

Jeśli aplikacja korzysta z interfejsów API specyficznych dla serwera WebLogic, należy refaktoryzować aplikację, aby nie używać ich. Na przykład jeśli użyto klasy wymienionej w dokumentacji interfejsu Java API dla programu Oracle WebLogic Server, to w aplikacji zastosowano interfejs API specyficzny dla serwera WebLogic. Zestaw narzędzi Red Hat Migration Toolkit for Apps może pomóc w usuwaniu i refaktoryzacji tych zależności.

Określanie, czy aplikacja używa obiektów bean jednostek lub obiektów bean CMP w stylu EJB 2.x

Jeśli aplikacja używa fasoli typu Entity Beans lub EJB 2.x style CMP, należy refaktoryzować aplikację, aby nie używać ich.

Określanie, czy jest używana funkcja klienta aplikacji Java EE

Jeśli masz aplikacje klienckie, które łączą się z aplikacją (serwer) przy użyciu funkcji klienta aplikacji Java EE, należy refaktoryzować zarówno aplikacje klienckie, jak i aplikację (serwer) w celu używania interfejsów API HTTP.

Określanie, czy użyto planu wdrożenia

Jeśli plan wdrożenia został użyty do wykonania wdrożenia, należy ocenić, co robi plan wdrożenia. Jeśli plan wdrożenia to proste wdrożenie, będzie można wdrożyć aplikację internetową bez wprowadzania żadnych zmian. Jeśli plan wdrożenia jest bardziej rozbudowany, będzie trzeba określić, czy da się użyć interfejsu wiersza polecenia JBoss do poprawnego skonfigurowania aplikacji w ramach wdrożenia. Jeśli nie da się użyć interfejsu wiersza polecenia JBoss, konieczna będzie refaktoryzacja aplikacji w taki sposób, aby plan wdrożenia nie był już potrzebny.

Określanie, czy są używane czasomierze EJB

Jeśli aplikacja używa czasomierzy EJB, należy sprawdzić, czy kod czasomierza EJB może być wyzwalany niezależnie przez każde wystąpienie protokołu JBoss EAP. Ta weryfikacja jest wymagana, ponieważ gdy usługa App Service jest skalowana w poziomie, każdy czasomierz EJB zostanie wyzwolony we własnym wystąpieniu protokołu EAP JBoss.

Sprawdzanie, czy system plików jest używany i jak jest używany

Każde użycie systemu plików na serwerze aplikacji będzie wymagało ponownej konfiguracji lub, w rzadkich przypadkach, zmiany architektury. System plików może być używany przez moduły udostępnione WebLogic lub kod aplikacji. Można zidentyfikować niektóre lub wszystkie z następujących scenariuszy.

Zawartość statyczna tylko do odczytu

Jeśli aplikacja aktualnie obsługuje zawartość statyczną, wymagana będzie alternatywna lokalizacja dla tej zawartości statycznej. Możesz rozważyć przeniesienie zawartości statycznej do usługi Azure Blob Storage i dodanie usługi Azure CDN w celu uzyskania błyskawicznych pobrań na całym świecie.

Dynamicznie publikowana zawartość statyczna

Jeśli aplikacja zezwala na zawartość statyczną, która została przekazana/utworzona przez aplikację, ale pozostaje niezmienna po jej utworzeniu, możesz użyć usług Azure Blob Storage i Azure CDN, jak opisano powyżej, oraz usługi Azure Function do obsługiwania przekazywania i odświeżania usługi CDN. Udostępniliśmy przykładową implementację do użycia.

Zawartość dynamiczna lub wewnętrzna

W przypadku plików często zapisywanych i odczytywanych przez aplikację (takich jak pliki danych tymczasowych) lub plików statycznych, które są widoczne tylko dla aplikacji, usługa Azure Storage może być instalowana w systemie plików usługi App Service.

Określanie, czy są używane łączniki JCA

Jeśli aplikacja używa łączników JCA, musisz sprawdzić, czy łącznik JCA może być używany w aplikacji JBoss EAP. Jeśli implementacja JCA jest powiązana z aplikacją WebLogic, musisz refaktoryzować aplikację, aby nie używać łącznika JCA. Jeśli można go użyć, należy dodać pliki JAR do ścieżki klasy serwera i umieścić niezbędne pliki konfiguracji w odpowiedniej lokalizacji w katalogach serwerów JBoss EAP, aby były dostępne.

Określanie, czy aplikacja używa adaptera zasobów

Jeśli aplikacja wymaga karty zasobów (RA), musi być zgodna z protokołem JBoss EAP. Ustal, czy usługa RA działa prawidłowo w autonomicznym wystąpieniu protokołu JBoss EAP, wdrażając go na serwerze i prawidłowo ją konfigurując. Jeśli ra działa prawidłowo, należy dodać pliki JAR do ścieżki klas serwera wystąpienia usługi App Service i umieścić niezbędne pliki konfiguracji w prawidłowej lokalizacji w katalogach serwerów JBoss EAP, aby były dostępne.

Określanie, czy jest używana usługa JAAS

Jeśli aplikacja korzysta z usługi JAAS, musisz przechwycić sposób konfigurowania usługi JAAS. Jeśli używa ona bazy danych, możesz przekonwertować ją na domenę JAAS w aplikacji JBoss EAP. Jeśli jest to implementacja niestandardowa, należy sprawdzić, czy może być używana w aplikacji JBoss EAP.

Ustalanie, czy jest używane klastrowanie serwera WebLogic

W większości przypadków aplikację wdraża się na wielu serwerach WebLogic w celu zapewnienia wysokiej dostępności. aplikacja systemu Azure Service jest w stanie skalować, ale jeśli używasz interfejsu API klastra WebLogic, musisz refaktoryzować kod, aby wyeliminować użycie tego interfejsu API.

Migracja

Red Hat Migration Toolkit for Apps

Zestaw narzędzi Red Hat Migration Toolkit for Applications to bezpłatne rozszerzenie dla programu Visual Studio Code. To rozszerzenie analizuje kod i konfigurację aplikacji, aby udostępnić zalecenia dotyczące migrowania aplikacji Jakarta EE do protokołu JBoss EAP z innych serwerów aplikacji, takich jak usuwanie zależności z zastrzeżonych interfejsów API. Rozszerzenie udostępnia również zalecenia w przypadku migracji do chmury ze środowiska lokalnego. Aby uzyskać więcej informacji, zobacz Migration Toolkit for Applications overview (Omówienie zestawu narzędzi migracji dla aplikacji).

Zawartość tego przewodnika pomoże Ci rozwiązać inne składniki podróży migracji, takie jak wybór prawidłowego typu planu usługi App Service, zewnętrzna lokalizacja sesji oraz zarządzanie wystąpieniami protokołu EAP zamiast interfejsu zarządzania JBoss przy użyciu platformy Azure.

Aprowizacja planu usługi App Service

Z listy dostępnych planów usług wybierz plan, którego specyfikacje spełniają lub przekraczają specyfikacje bieżącego sprzętu produkcyjnego.

Uwaga

Jeśli planujesz uruchamianie wdrożeń przejściowych/kanarkowych lub korzystanie z miejsc wdrożenia, plan usługi App Service musi uwzględniać dodatkową pojemność. W przypadku aplikacji języka Java zalecamy korzystanie z planów Premium lub wyższych.

Utwórz plan usługi App Service.

Tworzenie i wdrażanie aplikacji internetowych

Musisz utworzyć aplikację internetową w planie usługi App Service dla każdego pliku WAR wdrożonego na serwerze JBoss EAP.

Uwaga

Chociaż istnieje możliwość wdrożenia wielu plików WAR w pojedynczej aplikacji internetowej, jest to wysoce niepożądane. Wdrożenie wielu plików WAR w pojedynczej aplikacji internetowej uniemożliwia skalowanie poszczególnych aplikacji zgodnie z ich wymaganiami dotyczącymi użycia. Zwiększa również złożoność kolejnych potoków wdrażania. Jeśli pod pojedynczym adresem URL musi być dostępnych wiele aplikacji, rozważ użycie rozwiązania routingu, takiego jak Azure Application Gateway.

Aplikacje Maven

Jeśli aplikacja została skompilowana z pliku POM narzędzia Maven, użyj wtyczki Webapp dla narzędzia Maven, aby utworzyć aplikację internetową i wdrożyć aplikację. Aby uzyskać więcej informacji, zobacz sekcję Konfigurowanie wtyczki Maven w przewodniku Szybki start: tworzenie aplikacji Java w usłudze aplikacja systemu Azure Service.

Aplikacje inne niż Maven

Jeśli nie możesz użyć wtyczki Maven, musisz zaaprowizować aplikację internetową za pomocą innych mechanizmów, takich jak:

Po utworzeniu aplikacji internetowej użyj jednego z dostępnych mechanizmów wdrażania, aby wdrożyć aplikację. Aby uzyskać więcej informacji, zobaczWdrażanie plików w usłudze App Service.

Migracja opcji środowiska uruchomieniowego JVM

Jeśli aplikacja wymaga określonych opcji środowiska uruchomieniowego, użyj najbardziej odpowiedniego mechanizmu, aby je określić. Aby uzyskać więcej informacji, zobacz sekcję Ustawianie opcji środowiska uruchomieniowego języka Java w temacie Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service.

Migrowanie parametrów zewnętrznych

Jeśli musisz użyć parametrów zewnętrznych, musisz ustawić je jako ustawienia aplikacji. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień aplikacji.

Migrowanie skryptów uruchamiania

Jeśli oryginalna aplikacja użyła niestandardowego skryptu uruchamiania, musisz zmigrować ją do skryptu powłoki Bash. Aby uzyskać więcej informacji, zobacz Dostosowywanie konfiguracji serwera aplikacji.

Wypełnianie wpisów tajnych

Do przechowywania wszelkich wpisów tajnych specyficznych dla aplikacji użyj ustawień aplikacji. Jeśli zamierzasz używać tego samego wpisu tajnego lub wpisów tajnych w wielu aplikacjach lub potrzebujesz precyzyjnych zasad dostępu i możliwości inspekcji, zamiast tego użyj odwołań usługi Azure Key Vault. Aby uzyskać więcej informacji, zobacz sekcję Use KeyVault References (Używanie odwołań do usługi KeyVault) w temacie Configure a Java app for aplikacja systemu Azure Service (Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service).

Konfigurowanie domeny niestandardowej i protokołu SSL

Jeśli aplikacja będzie widoczna w domenie niestandardowej, należy na nią zamapować aplikację internetową. Aby uzyskać więcej informacji, zobacz Samouczek: mapowania istniejącej niestandardowej nazwy DNS na usługę aplikacja systemu Azure Service.

Następnie należy powiązać certyfikat TLS/SSL dla tej domeny z aplikacją internetową usługi App Service. Aby uzyskać więcej informacji, zobacz Zabezpieczanie niestandardowej nazwy DNS przy użyciu powiązania TLS/SSL w usłudze aplikacja systemu Azure.

Migracja źródeł danych, bibliotek i zasobów JNDI

Aby przeprowadzić migrację źródeł danych, wykonaj kroki opisane w sekcji Konfigurowanie źródeł danych w temacie Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service.

Przeprowadź migrację wszelkich dodatkowych zależności ścieżki klas na poziomie serwera, postępując zgodnie z instrukcjami w sekcji JBoss EAP w temacie Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service.

Migrowanie wszelkich dodatkowych udostępnionych zasobów JDNI na poziomie serwera. Aby uzyskać więcej informacji, zobacz sekcję JBoss EAP w temacie Configure a Java app for aplikacja systemu Azure Service (Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure).

Migrowanie łączników JCA i modułów JAAS

Przeprowadź migrację wszystkich łączników JCA i modułów JAAS, postępując zgodnie z instrukcjami w temacie Instalowanie modułów i zależności.

Uwaga

Jeśli korzystasz z zalecanej architektury jednej architektury WAR na aplikację, rozważ migrację bibliotek klas na poziomie serwera i zasobów JNDI do aplikacji. W ten sposób znacznie uprości zarządzanie składnikami i zarządzanie zmianami. Jeśli chcesz wdrożyć więcej niż jedną war na aplikację, zapoznaj się z jednym z naszych przewodników towarzyszących wymienionych na początku tego przewodnika.

Migrowanie zaplanowanych zadań

Co najmniej należy przenieść zaplanowane zadania na maszynę wirtualną platformy Azure, aby nie były już częścią aplikacji. Alternatywnie możesz zmodernizować je w środowisku Java opartym na zdarzeniach przy użyciu usług platformy Azure, takich jak Azure Functions, SQL Database i Event Hubs.

Ponowne uruchamianie i test dymny

Na koniec musisz ponownie uruchomić aplikację internetową, aby zastosować wszystkie zmiany konfiguracji. Po zakończeniu ponownego uruchamiania sprawdź, czy aplikacja działa prawidłowo.

Po migracji

Po przeprowadzeniu migracji aplikacji do usługi aplikacja systemu Azure należy sprawdzić, czy działa zgodnie z oczekiwaniami. Po wykonaniu tej czynności mamy pewne zalecenia, które mogą sprawić, że aplikacja będzie bardziej natywna dla chmury.

Zalecenia