Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Migrer d'Oracle WebLogic vers Apache Tomcat (ToMee) sur Amazon ECS
Créée par Anya Epishcheva (AWS) et Harshad Gohil (AWS)
Récapitulatif
Ce modèle décrit les étapes de migration d'un système Oracle Solaris SPARC sur site exécutant Oracle WebLogic vers une installation basée sur des conteneurs Docker exécutant Apache ToMee (Apache Tomcat
Pour plus d'informations sur la migration des bases de données associées aux applications que vous migrez d'Oracle WebLogic vers Tomcat, consultez les modèles de migration de base de données de ce catalogue.
Bonnes pratiques
Les étapes de migration des applications Web Java et Java Enterprise Edition (Java EE) varient en fonction du nombre de ressources spécifiques au conteneur utilisées par l'application. Les applications basées sur Spring sont généralement plus faciles à migrer, car elles ne dépendent que d'un petit nombre de fois par rapport au conteneur de déploiement. En revanche, les applications Java EE qui utilisent Enterprise JavaBeans (EJBs) et des ressources de conteneur gérées telles que les pools de threads, le service d'authentification et d'autorisation Java (JAAS) et la persistance gérée par conteneur (CMP) nécessitent plus d'efforts.
Les applications développées pour Oracle Application Server utilisent fréquemment la suite Oracle Identity Management. Les clients qui migrent vers des serveurs d'applications open source choisissent souvent de réimplémenter la gestion des identités et des accès à l'aide de la fédération basée sur le protocole SAML. D'autres utilisent Oracle HTTP Server Webgate dans les cas où la migration depuis la suite Oracle Identity Management n'est pas une option.
Les applications Web Java et Java EE sont d'excellentes candidates pour le déploiement sur des services AWS basés sur Docker, tels que AWS Fargate et Amazon ECS. Les clients choisissent souvent une image Docker avec la dernière version du serveur d'applications cible (tel que ToMee) et le kit de développement Java (JDK) préinstallés. Ils installent leurs applications au-dessus de l'image Docker de base, la publient dans leur registre Amazon Elastic Container Registry (Amazon ECR) et l'utilisent pour le déploiement évolutif de leurs applications sur AWS Fargate ou Amazon ECS.
Idéalement, le déploiement des applications est élastique, c'est-à-dire que le nombre d'instances d'application augmente ou diminue en fonction du trafic ou de la charge de travail. Cela signifie que les instances d'application doivent être mises en ligne ou mises hors service pour ajuster la capacité à la demande.
Lorsque vous déplacez une application Java vers AWS, pensez à la rendre apatride. Il s'agit d'un principe architectural clé de l'AWS Well-Architected Framework qui permettra une mise à l'échelle horizontale à l'aide de la conteneurisation. Par exemple, la plupart des applications Web basées sur Java stockent les informations de session utilisateur localement. Pour éviter la fermeture d'une instance d'application en raison du dimensionnement automatique dans Amazon Elastic Compute Cloud (Amazon EC2) ou pour d'autres raisons, les informations de session utilisateur doivent être stockées dans le monde entier afin que les utilisateurs des applications Web puissent continuer à travailler de manière fluide et transparente sans se reconnecter ou se reconnecter à une application Web. Il existe plusieurs options architecturales pour cette approche, notamment Amazon ElastiCache pour Redis ou le stockage de l'état de session dans une base de données globale. Les serveurs d'applications tels que TomEE disposent de plug-ins qui permettent le stockage et la gestion des sessions via Redis, des bases de données et d'autres magasins de données mondiaux.
Utilisez un outil de journalisation et de débogage commun et centralisé qui s'intègre facilement à Amazon CloudWatch et AWS X-Ray. La migration permet d'améliorer les fonctionnalités du cycle de vie des applications. Par exemple, vous souhaiterez peut-être automatiser le processus de création afin que les modifications soient facilement apportées à l'aide d'un pipeline d'intégration et de livraison continues (CI/CD). Cela peut nécessiter des modifications de l'application afin qu'elle puisse être déployée sans interruption.
Conditions préalables et limitations
Prérequis
Un compte AWS actif
Code source Java et JDK
Application source créée avec Oracle WebLogic
Solution définie pour la gestion des identités et des accès (SAML ou Oracle Webgate)
Solution définie pour la gestion des sessions d'application (transfert like-for-like ou utilisation d'Amazon ElastiCache, ou mise en état de l'application si nécessaire)
Comprendre si l'équipe doit refactoriser les bibliothèques spécifiques à J2EE pour la portabilité vers Apache ToMee (voir État de l'implémentation de Java EE 7
sur le site Web d'Apache) Image TomEee renforcée en fonction de vos exigences de sécurité
Image du conteneur avec ToMee cible préinstallée
Corrections d'applications convenues et mises en œuvre si nécessaire (par exemple, journalisation, débogage, construction, authentification)
Versions du produit
Oracle WebLogic OC4 J, 9i, 10 g
Tomcat 7 (avec Java 1.6 ou version ultérieure)
Architecture
Pile technologique source
Application Web créée à l'aide d'Oracle WebLogic
Application Web utilisant l'authentification Oracle Webgate ou SAML
Applications Web connectées à Oracle Database version 10g et ultérieure
Pile technologique cible
TomEE (Apache Tomcat avec prise en charge des conteneurs ajoutée) s'exécutant sur Amazon ECS (voir également Déploiement d'applications Web Java
et de microservices Java sur Amazon ECS) Amazon Relational Database Service (Amazon RDS) pour Oracle ; pour les versions d'Oracle prises en charge par Amazon RDS, consultez
Amazon RDS pour Oracle
Architecture cible
Outils
Pour fonctionner sur TomEE, une application Java doit être reconstruite dans un fichier .war. Dans certains cas, des modifications d'application peuvent être nécessaires pour faire fonctionner l'application sur ToMee ; vous devez vérifier que les options de configuration et les propriétés d'environnement nécessaires sont correctement définies.
En outre, les recherches JNDI (Java Naming and Directory Interface) et les espaces de noms JavaServer Pages (JSP) doivent être définis correctement. Pensez à vérifier les noms de fichiers utilisés par l'application pour éviter les collisions de noms avec les bibliothèques T intégrées. Par exemple, persistence.xml est un nom de fichier utilisé par le framework Apache OpenJPA (qui est fourni avec OpenEJB dans TomEE) à des fins de configuration. Le fichier persistence.xml du PUI contient les déclarations de bean du framework Spring.
TomEE version 7.0.3 et versions ultérieures (Tomcat 8.5.7 et versions ultérieures) renvoie une réponse HTTP 400 (mauvaise requête) pour le format brut (non codé) avec des caractères spéciaux. URLs La réponse du serveur apparaît sous forme de page blanche à l'utilisateur final. Les versions antérieures de Tomee et Tomcat autorisaient l'utilisation de certains caractères spéciaux non codés URLs ; toutefois, cela est considéré comme dangereux, comme indiqué sur le site Web CVE-2016-6816.
Après avoir déployé le fichier .war dans ToMee, surveillez le journal de démarrage sur Linux cat pour détecter les bibliothèques partagées manquantes et les extensions spécifiques à Oracle afin d'ajouter les composants manquants dans les bibliothèques Tomcat.
Procédure générale
Configurez l'application sur TomEE.
Identifiez et reconfigurez les fichiers de configuration et les ressources spécifiques au serveur d'applications, du format source au format cible.
Identifiez et reconfigurez les ressources JNDI.
Ajustez l'espace de noms et les recherches EJB au format requis par le serveur d'applications cible (le cas échéant).
Reconfigurez les rôles de sécurité et les mappages principaux spécifiques au conteneur d'applications JAAS (le cas échéant).
Package de l'application et des bibliothèques partagées dans un fichier .war.
Déployez le fichier .war dans Tomee à l'aide du conteneur Docker fourni.
Surveillez le journal de démarrage pour identifier les extensions de bibliothèque partagée et de descripteur de déploiement manquantes. Si vous en trouvez, revenez à la première tâche.
Testez l'application installée par rapport à la base de données Amazon RDS restaurée.
Lancez l'architecture complète avec un équilibreur de charge et un cluster Amazon ECS en suivant les instructions de la section Déployer des conteneurs Docker
. Mettez à jour le URLs pour qu'il pointe vers l'équilibreur de charge.
Mettez à jour la base de données de gestion de configuration (CMDB).
Épopées
| Tâche | Description | Compétences requises |
|---|---|---|
| Effectuez la découverte des applications (empreinte de l'état actuel et référence de performances). | BA, responsable de la migration | |
| Validez les versions et les moteurs des bases de données source et cible. | DBA | |
| Validez la conception de l'application source et cible (gestion des identités et des sessions). | DBA, ingénieur en migration, propriétaire de l'application | |
| Identifiez les exigences matérielles et de stockage pour l'instance de serveur cible. | DBA, SysAdmin | |
| Choisissez le type d'instance approprié en fonction de la capacité, des fonctionnalités de stockage et des fonctionnalités réseau. | DBA, SysAdmin | |
| Identifiez les exigences de sécurité d'accès réseau pour les bases de données source et cible. | DBA, SysAdmin | |
| Identifiez la stratégie et les outils de migration des applications. | DBA, responsable de la migration | |
| Complétez le guide de conception et de migration de l'application. | Responsable de la création, responsable de la migration | |
| Terminez le runbook de migration des applications. | Responsable du développement, responsable du transfert, responsable des tests, responsable de la migration |
| Tâche | Description | Compétences requises |
|---|---|---|
| Créer un cloud privé virtuel (VPC) | SysAdmin | |
| Créez des groupes de sécurité. | SysAdmin | |
| Configurez et démarrez l'instance de base de données Amazon RDS. | DBA, SysAdmin | |
| Configurez le déploiement d'Amazon ECS. | SysAdmin | |
| Package de votre application sous forme d'image Docker. | SysAdmin | |
| Transférez l'image vers le registre Amazon ECR (ou ignorez cette étape et transférez-la vers le cluster Amazon ECS). | SysAdmin | |
| Configurez la définition de tâche pour l'application et les options de service Amazon ECS. | SysAdmin | |
| Configurez votre cluster, passez en revue les paramètres de sécurité et définissez les rôles AWS Identity and Access Management (IAM). | SysAdmin | |
| Lancez votre installation et exécutez les tests conformément au manuel de migration de votre application. | SysAdmin |
| Tâche | Description | Compétences requises |
|---|---|---|
| Obtenez l'autorisation de votre équipe d'assurance sécurité pour transférer les données de production vers AWS. | DBA, ingénieur en migration, propriétaire de l'application | |
| Créez et obtenez l'accès à des points de terminaison pour récupérer les fichiers de sauvegarde de la base de données. | DBA | |
| Utilisez le moteur de base de données natif ou des outils tiers pour migrer les objets et les données de base de données. | DBA | |
| Exécutez les tests nécessaires depuis le runbook de migration des applications pour confirmer la réussite de la migration des données. | DBA, ingénieur en migration, propriétaire de l'application |
| Tâche | Description | Compétences requises |
|---|---|---|
| Créez une demande de modification (CR) pour la migration. | Plomb de découpe | |
| Obtenez l'approbation du CR pour la migration. | Plomb de découpe | |
| Suivez la stratégie de migration des applications décrite dans le runbook de migration des applications. | DBA, ingénieur en migration, propriétaire de l'application | |
| Mettez à niveau l'application (si nécessaire). | DBA, ingénieur en migration, propriétaire de l'application | |
| Effectuez des tests fonctionnels, non fonctionnels, de validation des données, de SLA et de performance. | Responsable des tests, propriétaire de l'application, utilisateurs de l'application |
| Tâche | Description | Compétences requises |
|---|---|---|
| Obtenez l'approbation de l'application ou du propriétaire de l'entreprise. | Plomb de découpe | |
| Exécutez un exercice sur le thème d'un tableau pour suivre toutes les étapes du runbook de transition. | DBA, ingénieur en migration, propriétaire de l'application | |
| Basculez les clients de l'application vers la nouvelle infrastructure. | DBA, ingénieur en migration, propriétaire de l'application |
| Tâche | Description | Compétences requises |
|---|---|---|
| Arrêtez les ressources AWS temporaires. | DBA, ingénieur en migration, SysAdmin | |
| Passez en revue et validez les documents du projet. | Responsable de la migration | |
| Collectez des indicateurs concernant le délai de migration, le pourcentage de manuel par rapport à l'outil, les économies de coûts, etc. | Responsable de la migration | |
| Clôturez le projet et faites part de vos commentaires. | Responsable de la migration, propriétaire de l'application |
Ressources connexes
Références
Tutoriels et vidéos
