Migrowanie aplikacji serwera Tomcat do serwera Tomcat w usłudze Azure App Service

  • Artykuł

W tym przewodniku opisano, na co należy zwrócić uwagę, aby przeprowadzić migrację istniejącej aplikacji serwera Tomcat w celu uruchomienia jej w usłudze Azure App Service przy użyciu serwera Tomcat 9.0.

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 następującymi przewodnikami po migracji towarzyszącej:

Przełączanie na obsługiwaną platformę

Usługa App Service oferuje określone wersje serwera Tomcat w określonych wersjach języka Java. Aby zapewnić zgodność, przed kontynuowaniem pozostałych kroków przeprowadź migrację aplikacji do jednej z obsługiwanych wersji oprogramowania Tomcat i języka Java w bieżącym środowisku. Pamiętaj, aby w pełni przetestować konfigurację wynikową. W tych testach użyj najnowszej stabilnej wersji dystrybucji systemu Linux.

Uwaga

Ta weryfikacja jest szczególnie ważna, jeśli bieżący serwer działa na nieobsługiwanym zestawie 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

W usłudze aplikacja systemu Azure pliki binarne dla środowiska Java 8 są dostarczane z poziomu środowiska Eclipse Temurin. W przypadku języka Java 11, 17 i wszystkich przyszłych wersji LTS języka Java usługa App Service udostępnia zestaw Microsoft Build zestawu OpenJDK. Te pliki binarne są dostępne do bezpłatnego pobrania w następujących witrynach:

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

${CATALINA_HOME}/bin/version.sh

Aby uzyskać informacje na temat bieżącej wersji używanej przez usługę Azure App Service, pobierz oprogramowanie Tomcat 9, w zależności od wersji, która ma być używana w usłudze Azure App Service.

Utworzenie spisu zasobów zewnętrznych

Zasoby zewnętrzne, takie jak źródła danych, brokery komunikatów JMS i inne, są wstrzykiwane za pośrednictwem interfejsu Java Naming and Directory Interface (JNDI). Niektóre takie zasoby mogą wymagać migracji lub ponownej konfiguracji.

W aplikacji

Sprawdź plik META-INF/context.xml. Poszukaj elementów <Resource> wewnątrz elementu <Context>.

Na serwerach aplikacji

Sprawdź pliki $CATALINA_BASE/conf/context.xml i $CATALINA_BASE/conf/server.xml oraz pliki .xml w katalogach $CATALINA_BASE/conf/[nazwa-aparatu]/[nazwa-hosta].

W plikach context.xml zasoby JNDI będą opisywane przez elementy <Resource> w elemencie <Context> najwyższego poziomu.

W plikach server.xml zasoby JNDI będą opisywane przez elementy <Resource> w elemencie <GlobalNamingResources>.

Źródła danych

Źródła danych to zasoby JNDI z atrybutem type ustawionym na javax.sql.DataSource. Dla każdego źródła danych należy udokumentować 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, zobacz przewodnik JNDI Datasource How-To (Źródło danych JNDI — porady) w dokumentacji serwera Tomcat.

Wszystkie inne zasoby zewnętrzne

Nie jest możliwe udokumentowanie każdej możliwej zależności zewnętrznej w tym przewodniku. Twój zespół odpowiada za sprawdzenie, czy każda zależność zewnętrzna aplikacji może być spełniona po migracji.

Utworzenie spisu wpisów tajnych

Hasła i bezpieczne ciągi

Sprawdź wszystkie pliki właściwości i konfiguracji na serwerach produkcyjnych pod kątem wszelkich ciągów wpisów tajnych i haseł. Sprawdź pliki server.xml i context.xml w katalogu $CATALINA_BASE/conf. Możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia wewnątrz aplikacji. Mogą one obejmować plik META-INF/context.xml oraz, w przypadku aplikacji Spring Boot, pliki application.properties lub application.yml.

Certyfikaty spisu

Udokumentuj wszystkie certyfikaty używane w przypadku publicznych punktów końcowych protokołu SSL lub komunikacji z bazami danych zaplecza i innymi systemami. Wszystkie certyfikaty na serwerach produkcyjnych można wyświetlić, uruchamiając następujące polecenie:

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

Określanie, czy i jak jest używany system plików

Każde użycie systemu plików na serwerze aplikacji będzie wymagało ponownej konfiguracji lub, w rzadkich przypadkach, zmiany architektury. 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ą, potrzebna jest dodatkowa lokalizacja. Warto rozważyć przeniesienie zawartości statycznej do usługi Azure Blob Storage i dodanie usługi Azure CDN, aby zapewnić błyskawiczne pobieranie na całym świecie. Aby uzyskać więcej informacji, zobacz Hostowanie statycznej witryny internetowej w usłudze Azure Storage i Szybki start: integrowanie konta usługi Azure Storage z usługą Azure CDN. Możesz również bezpośrednio wdrożyć zawartość statyczną w aplikacji w planie Azure Spring Apps Enterprise. Aby uzyskać więcej informacji, zobacz Wdrażanie internetowych plików statycznych.

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 w temacie Przekazywanie zawartości statycznej i jej wstępne ładowanie w usłudze CDN za pomocą usługi Azure Functions. Możesz również bezpośrednio wdrożyć zawartość statyczną w aplikacji w planie Azure Spring Apps Enterprise. Aby uzyskać więcej informacji, zobacz Wdrażanie internetowych plików statycznych.

Zawartość dynamiczna lub wewnętrzna

Na potrzeby plików często zapisywanych i odczytywanych przez aplikację (na przykład plików danych tymczasowych) lub plików statycznych, które są widoczne tylko dla aplikacji, możesz zainstalować usługę Azure Storage w systemie plików usługi App Service. Aby uzyskać więcej informacji, zobacz Obsługa zawartości z usługi Azure Storage w usłudze App Service w systemie Linux.

Określanie mechanizmu trwałości sesji

Aby zidentyfikować używanego menedżera trwałości sesji, sprawdź pliki context.xml w aplikacji i konfiguracji serwera Tomcat. Poszukaj elementu <Manager>, a następnie zanotuj wartość atrybutu className.

Wbudowane na serwerze Tomcat implementacje aplikacji PersistentManager, na przykład StandardManager czy FileStore, nie są przeznaczone do użycia z rozproszoną, skalowaną platformą, taką jak usługa App Service. Ponieważ usługa App Service może równoważyć obciążenie między kilkoma wystąpieniami i w dowolnym momencie w niewidoczny sposób uruchomić ponownie dowolne wystąpienie, nie zaleca się utrwalania modyfikowalnego stanu w systemie plików.

Jeśli wymagana jest trwałość sesji, należy użyć alternatywnej PersistentManager implementacji, która będzie zapisywać w zewnętrznym magazynie danych, takim jak VMware Tanzu Session Manager z pamięcią podręczną Redis Cache. Aby uzyskać więcej informacji, zobacz Korzystanie z usługi Redis jako pamięci podręcznej sesji na serwerze Tomcat.

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.

Przypadki szczególne

Niektóre scenariusze produkcyjne mogą wymagać dodatkowych zmian lub wprowadzać dodatkowe ograniczenia. Chociaż takie scenariusze mogą być rzadkie, ważne jest, aby upewnić się, że są one niestosowalne do aplikacji lub poprawnie rozwiązane.

Określanie, czy aplikacja korzysta z zaplanowanych zadań

Z usługą App Service nie można używać zaplanowanych zadań, takich jak zadania Quartz Scheduler lub cron. Usługa App Service 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.

Utwórz spis wszystkich zaplanowanych zadań, wewnątrz lub na zewnątrz serwera aplikacji.

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ślanie, czy jest używane klastrowanie serwera Tomcat

Usługa Azure App Service nie obsługuje klastrowania serwera Tomcat. W zamian można skonfigurować skalowanie i równoważenie obciążenia oraz zarządzać nimi za pośrednictwem usługi Azure App Service bez funkcji specyficznych dla serwera Tomcat. Stan sesji można utrwalić w innej lokalizacji, aby udostępnić ją w replikach. Aby uzyskać więcej informacji, zobacz Określanie mechanizmu trwałości sesji.

Aby ustalić, czy aplikacja używa klastrowania, poszukaj elementu <Cluster> wewnątrz elementów <Host> lub <Engine> w pliku server.xml.

Określanie, czy są używane łączniki inne niż HTTP

Usługa App Service obsługuje tylko pojedynczy łącznik HTTP. Jeśli aplikacja wymaga dodatkowych łączników, na przykład łącznika AJP, nie używaj usługi App Service.

Aby zidentyfikować łączniki HTTP używane przez aplikację, poszukaj elementów <Connector> wewnątrz pliku server.xml w konfiguracji serwera Tomcat.

Określanie, czy jest używana klasa MemoryRealm

Klasa MemoryRealm wymaga utrwalonego pliku XML. W aplikacja systemu Azure Service należy przekazać ten plik do katalogu /home lub jednego z jego podkatalogów lub do zainstalowanego magazynu. Następnie należy odpowiednio zmodyfikować pathName parametr.

Aby ustalić, czy klasa MemoryRealm jest aktualnie używana, sprawdź, czy w plikach server.xml i context.xml znajdują się elementy <Realm>, których atrybut className jest ustawiony na org.apache.catalina.realm.MemoryRealm.

Określanie, czy jest używane śledzenie sesji SSL

Usługa App Service wykonuje odciążanie sesji poza środowiskiem uruchomieniowym serwera Tomcat, więc nie można używać śledzenia sesji SSL. W zamian użyj innego trybu śledzenia sesji (COOKIE lub URL). Jeśli potrzebujesz śledzenia sesji SSL, nie używaj usługi App Service.

Określanie, czy jest używana klasa AccessLogValve

Jeśli używasz metody AccessLogValve, należy ustawić directory parametr na /home/LogFiles lub jeden z jego podkatalogów.

Migracja

Parametryzacja konfiguracji

W krokach przed migracją prawdopodobnie zidentyfikowano niektóre wpisy tajne i zależności zewnętrzne, takie jak źródła danych, w plikach server.xml i context.xml . Dla każdego zidentyfikowanego elementu zastąp dowolną nazwę użytkownika, hasło, parametry połączenia lub adres URL zmienną środowiskową.

Na przykład załóżmy, że plik context.xml zawiera następujący element:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

W takim przypadku można go zmienić w sposób pokazany w następującym przykładzie:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Aby upewnić się, że podstawianie parametrów występuje dla dowolnego pliku context.xml w folderze META-INF wewnątrz wdrożonego pliku war, pamiętaj, aby ustawić zmienną CATALINA_OPTS środowiskową, jak pokazano w poniższym przykładzie:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

Aprowizacja planu usługi App Service

Z listy dostępnych planów usług na stronie App Service — cennik wybierz plan, którego specyfikacje spełniają lub przekraczają specyfikacje obecnego 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. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowisk przejściowych w usłudze Azure App Service.

Następnie utwórz plan usługi App Service. Aby uzyskać więcej informacji, zobacz Zarządzanie planem usługi App Service na platformie Azure.

Tworzenie i wdrażanie aplikacji internetowych

Dla każdego pliku WAR wdrożonego na serwerze Tomcat musisz utworzyć aplikację internetową w ramach planu usługi App Service (wybierając wersję serwera Tomcat jako stos środowiska uruchomieniowego).

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

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

Migracja opcji środowiska uruchomieniowego JVM

Jeśli aplikacja wymaga określonych opcji środowiska uruchomieniowego, użyj najbardziej odpowiedniego mechanizmu, aby je określić.

Wypełnianie wpisów tajnych

Do przechowywania wszelkich wpisów tajnych specyficznych dla aplikacji użyj ustawień aplikacji. Jeśli zamierzasz używać tych samych wpisów tajnych w wielu aplikacjach lub potrzebujesz szczegółowych zasad dostępu i funkcji inspekcji, zamiast tego skorzystaj z usługi Azure Key Vault.

Konfigurowanie domeny niestandardowej oraz 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 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 SSL w usłudze Azure App Service.

Importowanie certyfikatów zaplecza

Wszystkie certyfikaty do komunikacji z systemami zaplecza, takimi jak bazy danych, muszą zostać udostępnione w usłudze App Service. Aby uzyskać więcej informacji, zobacz Dodawanie certyfikatu SSL w usłudze App Service.

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

Aby poznać kroki konfiguracji źródła danych, zapoznaj się z sekcją Źródła danych artykułu Konfigurowanie aplikacji Java systemu Linux dla usługi Azure App Service.

Aby uzyskać dodatkowe instrukcje dotyczące źródła danych, zapoznaj się z następującymi sekcjami przewodnika JNDI Datasource How-To (Źródło danych JNDI — porady) w dokumentacji serwera Tomcat:

Przeprowadź migrację wszelkich dodatkowych zależności ścieżki klasy na poziomie serwera, wykonując te same czynności co w przypadku plików JAR źródła danych.

Przeprowadź migrację wszelkich dodatkowych udostępnionych zasobów JDNI na poziomie serwera.

Uwaga

Jeśli korzystasz z zalecanej architektury obejmującej jeden plik WAR na każdą aplikację internetową, rozważ przeprowadzenie migracji bibliotek ścieżki klasy i zasobów JNDI na poziomie serwera do swojej aplikacji. Znacznie uprości to nadzór nad składnikami i zarządzanie zmianami.

Migracja pozostałej konfiguracji

Po ukończeniu poprzedniej sekcji w katalogu /home/tomcat/conf powinna znajdować się dostosowywalna konfiguracja serwera.

Przeprowadź migrację, kopiując wszelkie dodatkowe konfiguracje (na przykład obszary i JASPIC)

Migrowanie zaplanowanych zadań

Aby wykonać zaplanowane zadania na platformie Azure, warto użyć wyzwalacza 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. Jeśli wykonywane zadania muszą być wywoływane dynamicznie i/lub śledzone centralnie, warto użyć harmonogramu Spring Batch.

Można też utworzyć aplikację logiki z wyzwalaczem cyklicznym, aby wywoływać adres URL bez pisania kodu poza aplikacją. Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Logic Apps — omówienie i Tworzenie, planowanie i uruchamianie cyklicznych zadań oraz przepływów pracy za pomocą wyzwalacza cyklicznego w usłudze Azure Logic Apps.

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.

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 Azure App Service sprawdź, czy działa ona zgodnie z oczekiwaniami. Po wykonaniu tych czynności skorzystaj z naszych zaleceń, dzięki którym Twoja aplikacja będzie bardziej natywna dla chmury.

Zalecenia