Comment exécuter une API Web ASP.NET sur AWS avec Lambda et API Gateway
AWS Lambda est une plate-forme sans serveur permettant d'exécuter du code sans gérer le matériel sous-jacent. Il est très flexible et peut exécuter de nombreuses charges de travail différentes, y compris des API C# complètes utilisant ASP.NET Core.
Attendez, vous pouvez faire ça sur Lambda ?
Ouais! Non seulement vous pouvez exécuter des fonctions basées sur des environnements d'exécution .NET, mais vous pouvez également répondre aux demandes à l'aide de tous les outils mis à votre disposition par ASP.NET. Vous pouvez créer des API qui communiquent avec des bases de données, comme la base de données RDS gérée d'AWS, tout en étant parfaitement évolutives et fonctionnant sur des fonctions sans serveur.
Alors que les versions précédentes d'ASP.NET s'exécutant sur .NET Framework (l'ancien runtime Windows uniquement) étaient connues pour être volumineuses, la nouvelle pile ASP.NET Core s'exécutant sur .NET Core 3.1 et le plus récent .NET 5 ont apporté une amélioration des performances et de l'utilisation de la mémoire.
Cela ne serait normalement pas possible, car ASP.NET utilise son propre serveur Web HTTP appelé Kestrel pour répondre aux demandes, ce qui ne fonctionnerait pas car cela est géré par le runtime Lambda. Cependant, AWS a fourni une solution ingénieuse pour cela ; traditionnellement, une configuration ASP.NET implique généralement leur serveur Web Kestrel derrière IIS ou NGINX. Cela communique avec le framework ASP.NET pour gérer les demandes.
AWS a créé une classe proxy, Amazon.Lambda.AspNetCoreServer, qui s'occupe de tout devant ASP.NET. Cela vous permet de réutiliser la majeure partie de votre code tout en reliant votre API à Lambda.
Cela signifie que vous devrez utiliser API Gateway, mais ce n'est pas une mauvaise chose car API Gateway est très utile pour gérer votre API. Il vous permet de définir strictement toutes les règles qui font fonctionner votre API ; bien sûr, vous devrez configurer votre application ASP.NET pour gérer toutes les demandes d'API Gateway.
Cependant, ce ne sera pas la meilleure expérience en termes de temps de démarrage. Par rapport aux langages de script légers comme JavaScript et Python, les packages .NET ont beaucoup plus de surcharge. Il existe quelques astuces que vous pouvez utiliser pour accélérer les performances, et vous pouvez même les payer avec une capacité provisionnée. Sinon, vous devez vous préparer à des temps de démarrage à froid d'environ 1 à 2 secondes.
Cela ne signifie pas que chaque exécution prendra 2 secondes pour charger la page. Une fois le premier chargement effectué, tout est initialisé et il est maintenu chaud dans Lambda pendant 5 minutes. Si quelqu'un d'autre le demande, la fonction traitera la demande comme si elle s'exécutait normalement sur un serveur réel.
Configuration d'ASP.NET
AWS inclut un générateur pour les projets ASP.NET Lambda qui est préconfiguré avec le code passe-partout et le déploiement sur CloudFormation. Nous vous recommandons de commencer ici, de tester les choses, puis de déplacer votre code d'API, mais si vous souhaitez l'intégrer à un projet existant, AWS propose également un guide pour cela.
Vous aurez besoin de l'extension AWS Toolkit for Visual Studio installée, que vous pouvez gérer à partir de Extensions dans la barre de menus. C'est ce qui contient les modèles de projet pour les applications AWS.
À partir de l'écran de démarrage principal de Visual Studio, créez un nouveau projet :
Vous voudrez probablement mettre cela dans sa propre solution, alors sélectionnez Solution vide sous Autre.
Ensuite, vous pouvez cliquer avec le bouton droit dans le volet des fichiers pour ajouter un nouveau projet et sélectionner «Application AWS sans serveur» ou «Application AWS sans serveur avec tests», selon votre préférence.
Assurez-vous que c'est en C #, sauf si vous souhaitez utiliser F # pour une raison quelconque.
Gardez également à l'esprit qu'il s'agit d'un projet Application sans serveur, qui gère toutes les ressources via le service d'infrastructure en tant que code d'AWS, CloudFormation. Si vous vouliez simplement créer des fonctions Lambda, il existe également un projet pour cela.
Vous serez redirigé vers un sous-menu où vous pourrez choisir le type de plan que vous souhaitez créer. Sélectionnez API Web ASP.NET Core et créez le projet.
Pour la plupart, cela est configuré comme un projet ASP.NET standard. La principale différence est que le Program.cs traditionnel est remplacé par LambdaEntryPoint.cs comme point d'entrée principal, et il contient la classe shim qui relie le code AWS d'ASP.NET au IWebHostBuilder, qui est utilisé pour démarrer l'application.
Une fois que tout est opérationnel, vous devrez copier vos contrôleurs, modèles et services, et remplacer Startup.cs par votre configuration.
Utilisation de votre API
Pour déployer ce projet, AWS inclut des options de publication intégrées à l'aide de l'extension AWS Toolkit. Faites un clic droit sur votre projet et sélectionnez « Publier sur AWS Lambda… ».
Vous devrez lui attribuer un compartiment dans lequel effectuer le téléchargement et définir un nom pour le déploiement CloudFormation.
Le téléchargement et la publication prendront une seconde, mais vous pourrez ensuite accéder à la console de gestion AWS Lambda pour afficher votre fonction. Il aura un nom généré automatiquement en utilisant le nom de la pile CloudFormation comme préfixe.
Sous Configuration > Déclencheurs, vous pouvez afficher tous les déclencheurs API Gateway qui appellent cette fonction et les tester par vous-même à l'aide du point de terminaison.
Vous pouvez également afficher la pile CloudFormation complète créée automatiquement à l'aide de votre configuration.
Si vous souhaitez le modifier, vous devez modifier le serverless.template dans votre projet. Pour plus d'informations, vous pouvez vous référer à notre guide sur l'utilisation d'AWS CloudFormation.