Share via


Java-toepassingen migreren naar Azure AD

Dit artikel bevat een overzicht van aanbevolen strategieën voor het migreren van Java-toepassingen naar Azure.

De migratiehandleiding is ontworpen voor de belangrijkste Java-in-Azure-scenario's en voor suggesties en overwegingen voor op het hoogste planningsniveau. Als u een specifiek Migratiescenario voor Java-apps wilt bespreken met het Microsoft Java on Azure-team, vult u de volgende vragenlijst in en neemt een vertegenwoordiger contact met u op.

Het toepassingstype identificeren

Voordat u een clouddoel voor uw Java-toepassing selecteert, moet u het toepassingstype van deze toepassing identificeren. De gebruikelijkste typen Java-toepassingen zijn als volgt:

Deze typen worden gedetailleerd beschreven in de volgende secties.

Spring Boot-/JAR-toepassingen

Veel nieuwere toepassingen worden rechtstreeks vanaf de opdrachtregel aangeroepen. Via deze toepassingen worden nog wel webaanvragen verwerkt. Er wordt echter niet meer gebruikgemaakt van een toepassingsserver om HTTP-aanvragen te verwerken, maar de HTTP-communicatie en alle andere afhankelijkheden worden direct in het toepassingspakket opgenomen. Dergelijke toepassingen zijn vaak gebaseerd op frameworks zoals Spring Boot, Dropwizard, Micronaut, MicroProfile, VERT.x en andere.

Deze toepassingen worden in archieven verpakt met de extensie .jar (JAR-bestanden).

Spring-toepassingen die gebruikmaken van Spring Cloud-middlewaremodules

De architectuurstijl van de microservice is een benadering voor het ontwikkelen van één toepassing als een suite met kleine services. Elke service wordt uitgevoerd in een eigen proces en communiceert met behulp van lichtgewicht mechanismen, vaak een HTTP-resource-API. Deze services zijn gebouwd rondom zakelijke mogelijkheden en kunnen onafhankelijk worden geïmplementeerd door volledig geautomatiseerde implementatiemachines. Er is een nauwelijks minimaal gecentraliseerd beheer van deze services, die in verschillende programmeertalen kunnen worden geschreven en verschillende technologieën voor gegevensopslag kunnen gebruiken. Dergelijke services zijn vaak gebaseerd op frameworks zoals Spring Cloud.

Deze services worden in meerdere toepassingen verpakt met de extensie .jar (JAR-bestanden).

Java EE-toepassingen

Java EE-toepassingen (ook wel J2EE-toepassingen of meer recent Jakarta EE-toepassingen genoemd) kunnen enkele, alle of geen van de elementen van webtoepassingen bevatten. Deze toepassingen kunnen ook veel meer onderdelen bevatten en verbruiken zoals gedefinieerd door de Jakarta EE-specificatie.

Java EE-toepassingen kunnen worden verpakt als archieven met de extensie .ear extensie (EAR-bestanden) of als archieven met de extensie .war (WAR-bestanden).

Java EE-toepassingen moeten worden geïmplementeerd op Java EE-compatibele toepassingsservers (zoals Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara en andere).

Toepassingen die alleen afhankelijk zijn van functies die worden verstrekt door de Java EE-specificatie (dat wil zeggen, app-serveronafhankelijke toepassingen), kunnen worden gemigreerd van één compatibele toepassingsserver naar een andere. Als uw toepassing afhankelijk is van een specifieke toepassingsserver (app-serverafhankelijk), moet u mogelijk een Azure-servicedoel selecteren waarmee u die toepassingsserver kunt hosten.

Webtoepassingen

Webtoepassingen worden uitgevoerd binnen een servlet-container. Sommige van deze toepassingen maken rechtstreeks gebruik van servlet-API's, terwijl veel andere frameworks gebruiken die servlet-API's inkapselen, zoals Apache Struts, Spring MVC, JavaServer Faces (JSF) en andere.

Deze webtoepassingen worden in archieven verpakt met de extensie .war (WAR-bestanden).

Batch-/geplande taken

Sommige toepassingen zijn bedoeld om kort te worden uitgevoerd, een bepaalde workload uit te voeren en vervolgens te worden afgesloten in plaats van te wachten op aanvragen of gebruikersinvoer. Soms moeten dergelijke taken eenmaal of met regelmatige, geplande tussenpozen worden uitgevoerd. On-premises worden dergelijke taken vaak aangeroepen vanuit de crontab van een server.

Deze toepassingen worden in archieven verpakt met de extensie .jar (JAR-bestanden).

Notitie

Als uw toepassing gebruikmaakt van een planner (zoals een Spring Batch of Quartz) om geplande taken uit te voeren, wordt het ten zeerste aanbevolen om deze taken buiten de toepassing uit te voeren. Als uw toepassing wordt geschaald naar meerdere exemplaren in de cloud, wordt dezelfde taak meer dan één keer uitgevoerd. Als uw planningsmechanisme gebruikmaakt van de lokale tijdzone van de host, kan er verder ongewenst gedrag optreden bij het schalen van uw toepassing in verschillende regio's.

Het Azure-servicedoel selecteren

In de volgende secties ziet u welke servicedoelen voldoen aan de vereisten van uw toepassing en welke verantwoordelijkheden ervoor nodig zijn.

Raster met hostingopties

Gebruik het volgende raster om potentiële bestemmingen voor uw toepassingstype te identificeren. Zoals u ziet, ondersteunen Azure Kubernetes Service (AKS) en Azure Virtual Machines alle toepassingstypen, maar ze vereisen dat uw team meer verantwoordelijkheden krijgt, zoals wordt weergegeven in de volgende sectie.

Doel-→

Toepassingstype ↓
App
Service
Java SE
App
Service
Tomcat
App
Service
JBoss EAP
Azure Container Apps AKS Virtueel
Computers
Spring Boot-/JAR-toepassingen
Spring Cloud-toepassingen
Webtoepassingen (WAR)
Java EE-toepassingen (WAR | EAR)
Commerciële toepassingsservers
(zoals Oracle WebLogic Server of IBM WebSphere)
Clustering op toepassingsserverniveau
Batch-/geplande taken
VNet-integratie/hybride connectiviteit
Beschikbaarheid voor Azure-regio's DETAILS DETAILS DETAILS DETAILS DETAILS DETAILS

Raster met doorlopende verantwoordelijkheden

Gebruik het volgende raster om inzicht te krijgen in de verantwoordelijkheden die na de migratie voor elke doellocatie van uw team worden gevraagd.

Taken waarmee Azure wordt aangegeven, worden volledig of voornamelijk beheerd door Azure. Uw team is continu verantwoordelijk voor de aangegeven 👉taken. Het wordt aanbevolen om een robuust en sterk geautomatiseerd proces te implementeren om aan al deze verantwoordelijkheden te voldoen.

Notitie

Dit is geen volledig overzicht van verantwoordelijkheden.

Doel-→

Taak ↓
App
Service
Azure
Container
Apps
AKS Virtueel
Computers
Bibliotheken bijwerken
(inclusief het oplossen van beveiligingsproblemen)
👉 👉 👉 👉
De toepassingsserver bijwerken
(inclusief het oplossen van beveiligingsproblemen)
Azure 👉 👉 👉
De Java Runtime bijwerken
(inclusief het oplossen van beveiligingsproblemen)
Azure 👉 👉 👉
Kubernetes-updates activeren
(uitgevoerd door Azure met een handmatige trigger)
N.v.t. Azure 👉 N.v.t.
Herstel na noodgevallen Azure 👉 👉 Azure
Niet-achterwaarts compatibele Kubernetes-API-wijzigingen afstemmen N.v.t. 👉 👉 N.v.t.
De basisinstallatiekopie van de container bijwerken
(inclusief het oplossen van beveiligingsproblemen)
N.v.t. 👉 👉 N.v.t.
Het besturingssysteem bijwerken
(inclusief het oplossen van beveiligingsproblemen)
Azure Azure Azure1 👉
Mislukte exemplaren detecteren en opnieuw opstarten Azure Azure Azure 👉
Draining en rolling van opnieuw opstarten voor updates implementeren Azure Azure Azure 👉
Infrastructuurbeheer Azure 👉 👉 👉
Bewaking- en waarschuwingsbeheer 👉 👉 👉 👉

1 Sommige beveiligingsupdates vereisen mogelijk opnieuw opstarten van knooppunten, die niet automatisch worden uitgevoerd. Zie Beveiligingsupdates en kernelupdates toepassen op Linux-knooppunten in Azure Kubernetes Service (AKS) voor meer informatie.

Als u de servlet-container (zoals een Spring Boot) implementeert als onderdeel van uw toepassing, moet u deze beschouwen als een bibliotheek, die als zodanig onder uw verantwoordelijkheid valt.

On-premises connectiviteit garanderen

Als voor uw toepassing toegang nodig is tot een van uw on-premises services, moet u een van de connectiviteitsservices van Azure inrichten. Zie Connect an on-premises network to Azure (Een on-premises netwerk verbinden met Azure) voor meer informatie. U moet uw toepassing ook herstructureren voor het gebruik van openbaar beschikbare API's in uw on-premises resources.

U moet deze inspanning voltooien voordat u een migratie start.

De huidige capaciteit en het resourcegebruik inventariseren

Documenteer de hardware van de huidige productieserver(s), plus het gemiddelde en de piek van het aantal aanvragen en het resourcegebruik. U hebt deze informatie nodig om resources in te richten in het servicedoel.

Migratierichtlijnen

Gebruik de volgende rasters om migratierichtlijnen te vinden op basis van het toepassingstype en het Azure-servicedoel.

Java-toepassingen

Gebruik de onderstaande rijen om het type van uw Java-toepassing te vinden en gebruik de kolommen om het Azure-servicedoel te vinden dat als host zal fungeren voor uw toepassing.

Als u een JBoss EAP-app wilt migreren naar Tomcat in App Service, converteert u eerst de Java EE-app naar Java Web Apps (servlets) die wordt uitgevoerd op Tomcat en volgt u de onderstaande richtlijnen.

Doel-→

Toepassingstype ↓
App
Service
Java SE
App
Service
Tomcat
App
Service
JBoss EAP
Azure
Container
Apps
AKS Virtueel
Computers
Spring Boot/
JAR-toepassingen
N.v.t. N.v.t. N.v.t. N.v.t. N.v.t. N.v.t.
Spring Cloud/
datacentrumbatterijten
N.v.t. N.v.t. N.v.t. N.v.t. hulp
gepland
hulp
gepland
Webtoepassingen
in Tomcat
N.v.t. hulp N.v.t. hulp hulp hulp
gepland

Java EE-toepassingen

Gebruik de onderstaande rijen om het Java EE-toepassingstype te vinden dat op een specifieke app-server wordt uitgevoerd. Gebruik de kolommen om het Azure-servicedoel te vinden dat als host zal fungeren voor uw toepassing.

Doel-→

App-server ↓
App
Service
Java SE
App
Service
Tomcat
App
Service
JBoss EAP
Azure
Container
Apps
AKS Virtueel
Computers
WildFly/
JBoss AS
N.v.t. N.v.t. hulp N.v.t. hulp hulp
gepland
Oracle WebLogic Server N.v.t. N.v.t. hulp N.v.t. hulp hulp
IBM WebSphere N.v.t. N.v.t. hulp N.v.t. hulp hulp
gepland
Red Hat JBoss EAP N.v.t. N.v.t. hulp N.v.t. hulp hulp

Zie ook