DéveloppeurWeb.Com
    DéveloppeurWeb.Com
    • Agile Zone
    • AI Zone
    • Cloud Zone
    • Database Zone
    • DevOps Zone
    • Integration Zone
    • Web Dev Zone
    DéveloppeurWeb.Com
    Home»Uncategorized»Lever et déplacer une application Web vers AWS Serverless
    Uncategorized

    Lever et déplacer une application Web vers AWS Serverless

    février 15, 2023
    Lever et déplacer une application Web vers AWS Serverless
    Share
    Facebook Twitter Pinterest Reddit WhatsApp Email

    Cet article a été rédigé par AWS Principal Developer Advocate, Marcia Villalba, et publié avec autorisation.

    Cet article fournit un guide sur la façon de migrer un MERN (Mécouter, Express, Ragir, et Node.js) application Web dans un environnement sans serveur. Il examine non seulement le processus de migration d’une application Web non sans serveur vers un environnement sans serveur, mais il explore également deux problèmes qui surviennent au cours du processus de migration.

    Lift and Shift est souvent le moyen le plus rapide de mettre une application migrée en production, et il permet à l’équipe de développement de refactoriser les parties de l’application qui peuvent bénéficier des technologies sans serveur.

    Avant de commencer toute migration, il est important de définir les exigences non fonctionnelles que la nouvelle application doit avoir. Pour cette application, ces exigences sont :

    • Un environnement qui s’adapte à zéro
    • Payer le moins possible pour les temps morts
    • Configurer le moins d’infrastructure possible
    • Haute disponibilité automatique de l’application
    • Modifications minimes du code d’origine

    Aperçu des applications

    Ce billet de blog vous explique comment migrer une application MERN. L’application d’origine est hébergée sur deux serveurs différents : l’un contient la base de données Mongo et l’autre contient les applications Node/js/Express et ReactJS.

    Migrer une application MERN

    Cette application de démonstration simule un site e-commerce swag. La couche de base de données stocke les produits, les utilisateurs et l’historique des achats. La couche serveur s’occupe de la logique commerciale du commerce électronique, hébergeant les images des produits, ainsi que l’authentification et l’autorisation des utilisateurs. La couche Web prend en charge toutes les interactions de l’utilisateur et communique avec la couche serveur à l’aide des API REST.

    Boutique FooBar

    Migration d’applications

    La couche de base de données de l’application est migrée vers MongoDB Atlas, un cluster de bases de données basé sur le cloud qui évolue automatiquement et est payé pour ce qui est utilisé. Ce cas est aussi simple que de vider le contenu de la base de données dans un dossier local, puis de le restaurer dans le cloud.

    Le backend Node.js/Express est migré vers AWS Lambda à l’aide de l’adaptateur Web AWS Lambda, un projet open source qui permet de créer une application Web et de l’exécuter sur Lambda. Vous pouvez en savoir plus sur la migration dans cette vidéo.

    L’étape suivante consiste à créer un point de terminaison HTTP pour l’application serveur. Cette démonstration utilise des URL de fonction Lambda, car elles sont simples à configurer, et une URL de fonction transmet toutes les routes au serveur Express. Vous pouvez en savoir plus sur les URL des fonctions Lambda dans cette vidéo.

    L’application Web React est migrée vers AWS Amplify, un service entièrement géré qui fournit des fonctionnalités telles que l’hébergement d’applications Web et la gestion du pipeline CI/CD pour l’application Web. Vous pouvez voir comment effectuer la migration en suivant cette vidéo.

    Défis migratoires

    Jusqu’ici, l’application est migrée d’un environnement hébergé dans un environnement traditionnel vers une exécution à l’aide de l’infrastructure sans serveur. Cependant, lors de cette migration, deux problèmes se posent : l’authentification et l’autorisation, et le stockage.

    Migration d’authentification et d’autorisation

    L’application d’origine gère elle-même l’authentification et l’autorisation. Cependant, avec l’application migrée actuelle, chaque fois que vous vous connectez, vous êtes déconnecté de l’application de manière inattendue. En effet, le code du serveur est responsable de la gestion de l’authentification et de l’autorisation des utilisateurs, et maintenant notre serveur s’exécute dans une fonction AWS Lambda et les fonctions sont sans état. Cela signifie qu’il y aura une fonction en cours d’exécution par demande – une demande peut charger tous les produits sur la page de destination, obtenir les détails d’un produit ou se connecter au site – et si vous faites quelque chose dans l’une de ces fonctions, le l’état n’est pas partagé.

    Pour résoudre ce problème, vous devez supprimer les mécanismes d’authentification et d’autorisation de la fonction et utiliser un service qui peut conserver l’état à travers plusieurs appels des fonctions. C’est pourquoi cette migration utilise Amazon Cognito pour gérer l’authentification et l’autorisation. Vous pouvez en savoir plus sur Amazon Cognito dans cette vidéo.

    Avec cette nouvelle architecture, l’application appelle les API Amazon Cognito directement depuis l’application AWS Amplify, minimisant ainsi la quantité de code nécessaire. Pour savoir comment cette partie de la migration a été effectuée, consultez cette autre vidéo.

    Migration du stockage

    Dans l’application d’origine, lorsqu’un nouveau produit est créé, une nouvelle image est téléchargée sur le serveur Node.js/Express. Cependant, l’application réside maintenant dans une fonction Lambda. Le code (et les fichiers) qui font partie de cette fonction ne peuvent pas changer à moins que la fonction ne soit redéployée. Par conséquent, vous devez séparer le stockage utilisateur du code serveur.

    Pour résoudre ce problème, cette migration utilisera Amazon S3, un service de stockage d’objets qui offre évolutivité, disponibilité des données, sécurité et performances. De plus, Amazon CloudFront peut être utilisé pour accélérer la récupération d’images à partir du cloud. Si vous voulez savoir comment cette migration a été effectuée, vous pouvez consulter cette vidéo.

    Conclusion

    En suivant ce guide, vous pouvez rapidement et facilement migrer votre application Web vers un environnement sans serveur et profiter des avantages du sans serveur, tels que la mise à l’échelle automatique et le paiement de ce qui est utilisé.

    Voici un résumé des étapes de migration suggérées par cet article :

    • Migration de base de données: migrez la base de données sur site vers MongoDB Atlas.
    • Migration principale: migrez l’application NodeJS/Express sur site vers un AWS Lambda à l’aide de l’adaptateur Web Lambda et des URL de fonction Lambda.
    • Migration d’applications Web: migrez l’application Web React sur site vers AWS Amplify.
    • Migration d’authentification: migrez l’authentification personnalisée pour utiliser Amazon Cognito.
    • Migration de stockage: migrez le stockage local des images pour utiliser Amazon S3 et Amazon CloudFront.

    L’image suivante montre la solution proposée pour l’application migrée :

    Solution proposée pour l'application migrée

    Si vous souhaitez lire un article détaillé expliquant comment procéder, pourquoi chaque service a été choisi parmi d’autres et accéder au code de l’application d’origine et migrée, vous pouvez lire « Lifting and shifting a web application to AWS Serverless : Part 1,  » et si vous êtes plutôt une personne visuelle, la vidéo ci-dessous le couvre également.

    Share. Facebook Twitter Pinterest LinkedIn WhatsApp Reddit Email
    Add A Comment

    Leave A Reply Cancel Reply

    Catégories

    • Politique de cookies
    • Politique de confidentialité
    • CONTACT
    • Politique du DMCA
    • CONDITIONS D’UTILISATION
    • Avertissement
    © 2023 DéveloppeurWeb.Com.

    Type above and press Enter to search. Press Esc to cancel.