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.
Évaluation
L'évaluation des applications destinées à la conteneurisation permet de découvrir toutes les dépendances et tous les risques. L'évaluation permet également de classer les applications dans des compartiments prioritaires à des fins de modernisation et de migration.
Au cours de la phase d'évaluation, concentrez-vous sur les domaines clés suivants :
-
Dépendances du système d'exploitation pour la conteneurisation — Les outils de conteneurisation automatisés tels qu' AWS App2Container présentent certaines limites en ce qui concerne les frameworks d'applications et les systèmes d'exploitation utilisés pour la conteneurisation. Pour plus d'informations sur les applications prises en charge, veuillez consulter la documentation App2Container.
-
Conformité réglementaire : il est préférable de s'assurer que les applications conteneurisées sont conformes à toutes les réglementations avant de les déployer dans l'environnement cible, plutôt que d'agir de manière réactive après le déploiement et d'en atténuer les effets. Vérifiez la présence de vulnérabilités dans les images, les communications non autorisées entre les conteneurs, les contrôles d'accès aux conteneurs et aux données, ainsi que les analyses automatisées pour empêcher les activités malveillantes.
-
Solution de reprise après sinistre : chaque application dispose de son propre contrat de niveau de service (SLA) spécifique pour les temps d'arrêt. Tenez compte de l'objectif de point de reprise (RPO) et de l'objectif de délai de reprise (RTO) de l'application au moment de planifier la distribution des clusters de conteneurs. App2Container déploie par défaut l'application dans plusieurs zones de disponibilité.
-
Stockage de données : il est préférable d'utiliser les conteneurs sans état. Pour les conteneurs dynamiques, les données doivent être stockées à l'extérieur du conteneur. Si un conteneur est hors service, vous pouvez en lancer un nouveau à l'aide de l'image et du volume externe attachés sans perte de données.
-
Gestion de la configuration et des secrets : le magasin de paramètres de l'environnement cible ou le magasin de secrets peuvent être utilisés pour stocker et récupérer des informations de configuration et des secrets du conteneur. Il est essentiel de s'assurer que les secrets ne sont accessibles qu'au conteneur concerné. Toutes les opérations relatives à la configuration et aux secrets doivent être journalisées. Le canal de communication entre le conteneur et le magasin de secrets doit être sécurisé.
-
Gestion des journaux : à des fins d'audit, les journaux générés par chaque conteneur seront envoyés à un service de gestion des journaux situé à l'extérieur du conteneur. Une application étant composée de plusieurs services et processus, chacun résidant dans des conteneurs différents, les journaux de chaque conteneur doivent avoir un ID unique.
-
Processus de génération et de déploiement : la plupart des entreprises disposent d'une sorte de processus de génération et de déploiement pour publier leurs applications et leurs fonctionnalités. Pour tirer parti de la conteneurisation, la génération et le déploiement des applications doivent être automatisés à l'aide d'un pipeline CI/CD. Un pipeline présente des avantages tels que l'allocation et la mise hors service de l'infrastructure en un clic, des déploiements plus rapides et résistants aux erreurs, l'automatisation et une réduction du temps nécessaire au lancement de nouvelles fonctionnalités.
-
Applications en amont et en aval : il est recommandé de conteneuriser et de migrer toutes les applications dépendantes par lots. Dans les scénarios où cela n'est pas possible, les canaux de communication entre l'application conteneurisée et les applications en amont et en aval doivent être ouverts de manière sécurisée. Assurez-vous que la bande passante prise en charge par ce canal ne perturbe pas le fonctionnement de l'application.
-
Dépendances de licence : plusieurs instances d'une application s'exécutent dans des conteneurs, ce qui peut s'avérer coûteux. Vérifiez les contrats et les conditions requises pour déployer des logiciels sur des conteneurs. Découvrez quels outils sont utilisés pour mesurer le nombre de logiciels utilisés sur les conteneurs.
-
Possibilité de conteneurisation sur des serveurs d'applications ou des machines de travail : le processus de conteneurisation consomme des ressources supplémentaires sur le serveur, telles que l'espace disque, la puissance de calcul et la mémoire. Le serveur d'applications doit être analysé pour s'assurer qu'il est capable de prendre en charge le processus de conteneurisation. Sinon, vous pouvez utiliser une machine de travail disposant des ressources nécessaires et capable de communiquer avec le serveur d'applications.
-
Compétences des développeurs et prise en charge de la production sur les conteneurs : l'équipe d'application actuelle doit se former à la technologie de la conteneurisation. L'équipe doit être en mesure de résoudre les problèmes rencontrés au cours du processus, de modifier les configurations en cas de besoin et de prendre en charge les applications déployées sur des conteneurs.
Vous pouvez utiliser App2Container pour conteneuriser des applications Java exécutées sous Linux, telles que les applications autonomes, Apache Tomcat JBoss, IBM, Oracle. WebSphere WebLogic Vous pouvez également utiliser App2Container pour conteneuriser des applications Java génériques telles que Spring Boot. La conteneurisation des applications fonctionne avec les microservices et les applications distribuées. Bien que toutes les applications Java puissent être modernisées à l'aide d'App2Container, les critères suivants peuvent vous aider à choisir les applications adéquates à moderniser pour accélérer les migrations :
-
Les applications empaquetées sous forme de fichier binaire unique sont plus faciles à conteneuriser. En outre, les applications Java peuvent être conteneurisées avec un environnement d'exécution Java (JRE). Chaque conteneur peut utiliser le JRE spécifique dont il a besoin.
-
Les applications sans état constituent un bon choix pour la modernisation en conteneurs. Ces applications stockent un minimum d'informations localement et stockent la plupart de leurs données dans un magasin de données permanent.
-
Les applications qui sont publiées à l'aide d'un pipeline d'intégration et de déploiement continus (CI/CD) sont de bons candidats pour la conteneurisation. Conteneurisez chaque application et intégrez une plateforme d'orchestration de conteneurs telle qu'Amazon ECS ou Amazon EKS, qui est prise en charge automatiquement par App2Container.
La plupart des applications d'entreprise sont intégrées à divers autres services d'authentification, de stockage de données permanent, de mise en cache, de communication asynchrone, de journalisation et de notifications. L'application conteneurisée doit être testée sur site avec tous les points d'intégration existants pour garantir le succès de la conteneurisation. Lorsque vous êtes prêt à effectuer la migration vers AWS, tous les points d'intégration et de stockage de données appropriés doivent être migrés vers AWS. Toutes les mises à jour nécessaires doivent être apportées à la configuration avant que le conteneur d'applications puisse être déployé sur AWS.
Les données stockées dans les systèmes de fichiers peuvent être migrées à AWS l'aide de divers outils
AWS fournit son propre service de surveillance et d'enregistrement et de visualisation des données opérationnelles appelé Amazon CloudWatch. Un CloudWatch agent peut être intégré dans le conteneur avec l'application pour utiliser ce service.
Pour les entreprises où le code source n'est pas disponible ou ne peut pas être maintenu, App2Container convient parfaitement à la conteneurisation, car il fonctionne sur l'environnement d'exécution de l'application et n'a pas besoin du code source.
