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.
Domaines techniques
Cette section fournit une vue d'ensemble des principaux domaines technologiques pour la conteneurisation. Le schéma suivant montre l'architecture d'une application Java EE traditionnelle.
Le schéma suivant montre l'architecture d'une application Java EE conteneurisée.
1. État de la session
Dans la plupart des cas, les applications Java EE stockent les données de session associées aux demandes des utilisateurs, telles que les cookies pour les servlets et les sessions avec état Enterprise Java Beans (EJB). Nous vous recommandons d'éviter de stocker les informations d'état dans la mémoire de la machine virtuelle Java (JVM), car votre conteneur doit rester sans état. Pour plus d'informations sur le principe de cessibilité, veuillez consulter Principles of container-based application design
Le mécanisme de réplication de mémoire suppose qu'un ensemble particulier de serveurs existe toujours dans le cluster, ou qu'un petit nombre de serveurs rejoignent ou quittent le cluster. Ceci est incompatible avec un environnement de conteneur. Nous vous recommandons donc de vous débarrasser de votre mécanisme de réplication de mémoire. Dans un environnement de conteneur, les serveurs d'applications sont redéployés lorsqu'une nouvelle version de l'image de conteneur est créée. C'est-à-dire que toutes les données de mémoire répliquées sont également effacées.
2. Agents
Plusieurs processus d'agent exécutés sur un même serveur physique ou virtuel exécutent généralement des tâches d'automatisation et utilitaires, telles que les suivantes :
-
Surveillance : les environnements d'application Java EE traditionnels utilisent souvent des agents dédiés pour la surveillance. Ces agents sont chargés de surveiller le processeur du serveur, la mémoire, l'utilisation du disque, l'utilisation de la mémoire au sein de la JVM, les messages du journal, etc. Cependant, il n'est pas possible d'exécuter directement des agents de surveillance dans un environnement de conteneurs. Vous devez remplacer les agents de surveillance par le mécanisme de surveillance fourni par la plateforme de conteneurs, comme Amazon CloudWatch et Amazon CloudWatch Logs.
-
Tâches (tâches planifiées) : dans les environnements d'application Java EE traditionnels, l'environnement d'exécution des tâches réside souvent sur le même serveur que le serveur d'applications et est responsable des processus par lots de longue durée, à l'exception des demandes des utilisateurs. Par exemple, le traitement par lots contrôlé par le contrôleur de tâches accède à la base de données pour récupérer des données et créer un rapport. Étant donné que ces charges de travail multiples ne peuvent pas coexister dans un environnement de conteneur, vous devez créer l'environnement d'exécution des tâches et des lots séparément de l'environnement de conteneur.
-
Transfert de fichiers : les agents de transfert de fichiers ne sont généralement pas aussi courants dans les environnements d'application Java EE, mais ils s'exécutent parfois sur le même système d'exploitation avec l'application Java en tant que processus indépendant d'échange de fichiers vers ou depuis des applications externes. Par exemple, les données utilisées par d'autres applications sont transférées vers un fichier tous les jours et reflétées dans la base de données. Les agents de transfert de fichiers ne peuvent pas fonctionner à côté des conteneurs, mais doivent être exécutés sur un autre serveur ayant accès à la base de données et aux fichiers.
3. Serveurs d’applications
Le défi le plus important lié à la conteneurisation est le changement de serveurs d'applications. Les serveurs d'applications compatibles avec Java EE traditionnels supposent un environnement de calcul statique. Ils peuvent donc ne pas être adaptés à une exécution dans un environnement de conteneurs. En d'autres termes, les serveurs physiques ou virtuels sont considérés comme l'entité de l'environnement de calcul pour les applications Java EE. Par exemple, les serveurs d'applications Java EE propriétaires, tels qu'un serveur d' WebSphereapplications IBM (TWA) traditionnel et un WebLogic serveur Oracle, disposent de leur propre mécanisme de déploiement d'applications.
La situation est différente dans un environnement de conteneur. Dans cet environnement, les conteneurs incluent un serveur d'applications et un environnement d'exécution avec des packages de création d'applications (par exemple, des fichiers .war et .jar) et sont déployés sur des plateformes de conteneurs telles qu'Amazon ECS ou Amazon EKS. Nous vous recommandons d'utiliser un mécanisme de plateforme de conteneur pour déployer des applications dans des environnements. Les serveurs d'applications sont fréquemment déployés avec des conteneurs. Ils doivent donc être de petite taille (moins de 500 Mo) et rapides à démarrer. Pour répondre à cette exigence, vous devrez peut-être changer de serveur d'applications traditionnel et migrer vers un serveur d'applications plus convivial pour les conteneurs. Cela peut nécessiter une migration d'IBM WebSphere Application Server vers IBM WebSphere Liberty ou JBoss Enterprise Application Platform (EAP) vers WildFly.
Nous vous recommandons de tenir compte des impacts suivants qui peuvent résulter du changement de serveur d'applications :
-
Injection de configuration via des variables d'environnement (contrairement aux applications Java EE traditionnelles qui stockent les configurations dans un fichier, comme web.xml)
-
Compatibilité avec les fonctionnalités Java EE
-
Versions de JVM
4. Magasin de fichiers
Le magasin de fichiers le plus couramment utilisé pour les applications Java EE traditionnelles est le système de fichiers local. Les cas d'utilisation les plus courants incluent les fichiers journaux des applications, les fichiers générés par les applications tels que les rapports métier et le contenu chargé par les utilisateurs. Nous vous recommandons d'éviter de stocker des fichiers dans le conteneur, car les conteneurs sont sans état, ce qui signifie que les magasins de fichiers doivent être externalisés pour la conteneurisation.
Prenez les options de conteneurisation suivantes en considération :
-
Amazon Elastic File System (Amazon EFS) : Amazon EFS est un service NFS géré accessible depuis des conteneurs. Amazon EFS est intégré à Amazon ECS et Amazon EKS. Si vous utilisez Amazon EFS, vous n'avez pas besoin d'écrire de scripts personnalisés pour monter des volumes EFS sur vos conteneurs. La première étape de cette option consiste à répertorier tous les chemins de système de fichiers de votre application utilisés pour lire ou écrire. Après avoir identifié le chemin du système de fichiers à conserver, vous pouvez mapper le chemin du système de fichiers à un chemin du système de fichiers EFS. Pour plus d'informations, veuillez consulter Tutorial: Using Amazon EFS file systems with Amazon ECS dans la documentation Amazon ECS. Il n'est pas nécessaire que tous les chemins soient persistants, en particulier les fichiers journaux des applications. La plupart des applications d'entreprise écrivent des fichiers journaux dans un système de fichiers local. Dans le cadre du processus de conteneurisation, nous vous recommandons d'envisager de modifier la destination de la journalisation pour utiliser Standard Out et Standard Error. Cela vous permet de capturer toutes les sorties dans les CloudWatch journaux sans gérer le dimensionnement et les performances du stockage des journaux. Pour plus d'informations sur la connexion à Amazon ECS, veuillez consulter Using the awslogs log driver dans la documentation Amazon ECS.
-
Amazon Simple Storage Service (Amazon S3) : Amazon S3 est moins cher qu'Amazon EFS et prend en charge une bande passante plus large qu'Amazon EFS, mais il nécessite un changement de code d'application plus large qu'Amazon EFS. Cela est dû au fait qu'Amazon S3 n'est pas un système de fichiers.
5. Processus de génération et de déploiement
Le processus de conteneurisation implique de modifier et d'étendre le processus de déploiement des applications. Dans les environnements traditionnels, le processus de déploiement des applications implique principalement des artefacts Java (par exemple, les fichiers .war et .ear). Dans un environnement de conteneur, l'image du conteneur est l'unité de déploiement. Outre le processus de génération d'artefacts Java existants, vous devez générer un processus de création et de déploiement de conteneurs Docker. Pour plus d'informations sur le processus de pipeline, consultez la section Création et déploiement automatiques d'une application Java sur Amazon EKS à l'aide d'un CI/CD pipeline dans la documentation AWS Prescriptive Guidance.
6. Accès aux bases de données
Les conteneurisations d'applications traditionnelles s'accompagnent souvent d'une migration de base de données. Pour réduire les risques liés à la migration, nous vous recommandons de suivre la stratégie de migration pour les bases de données relationnelles (directives AWS prescriptives). Les environnements conteneurisés nécessitent une configuration externalisée, notamment des chaînes de connexion à la base de données. Vous pouvez utiliser des outils tels que Spring Cloud Config
