Création de fonctions Lambda avec Node.js - AWS Lambda

Création de fonctions Lambda avec Node.js

Vous pouvez exécuter du code JavaScript avec Node.js dans AWS Lambda. Lambda fournit des runtimes pour Node.js, qui exécutent votre code afin de traiter des événements. Votre code s’exécute dans un environnement incluant l’AWS SDK for JavaScript, avec les informations d’identification d’un rôle AWS Identity and Access Management (IAM) que vous gérez.

Lambda prend en charge les runtimes Node.js suivants.

Environnements d’exécution Node.js
Nom Identifiant SDK pour JavaScript Système d'exploitation Architectures

Node.js 14

nodejs14.x

2.1001.0

Amazon Linux 2

x86_64, arm64

Node.js 12

nodejs12.x

2.1001.0

Amazon Linux 2

x86_64, arm64

Les fonctions Lambda utilisent un rôle d’exécution pour obtenir l’autorisation d’écrire des journaux dans Amazon CloudWatch Logs, ainsi que d’accéder à d’autres services et ressources. Si vous ne possédez pas encore de rôle d’exécution pour le développement de fonctions, créez-en un.

Pour créer un rôle d’exécution

  1. Ouvrez la page Roles (Rôles) dans la console IAM.

  2. Sélectionnez Créer un rôle.

  3. Créez un rôle avec les propriétés suivantes :

    • Entité de confianceLambda.

    • AutorisationsAWSLambdaBasicExecutionRole.

    • Nom de rôlelambda-role.

    La stratégie AWSLambdaBasicExecutionRole possède les autorisations dont la fonction a besoin pour écrire des journaux dans CloudWatch Logs.

Vous pouvez ajouter des autorisations pour ce rôle plus tard, ou le remplacer par un autre rôle spécifique à une fonction particulière.

Pour créer une fonction Node.js.

  1. Ouvrez la console Lambda.

  2. Sélectionnez Créer une fonction.

  3. Configurez les paramètres suivants :

    • Nommy-function.

    • Environnement d’exécutionNode.js 14.x.

    • RoleChoisissez un rôle existant.

    • Rôle existantlambda-role.

  4. Sélectionnez Créer une fonction.

  5. Pour configurer un événement de test, choisissez Test.

  6. Dans Event name (Nom de l'événement), saisissez test.

  7. Sélectionnez Save Changes.

  8. Pour appeler la fonction, choisissez Test.

La console crée une fonction Lambda avec un seul fichier source nommé index.js. Vous pouvez modifier ce fichier et ajouter d'autres fichiers dans l'éditeur de code intégré. Choisissez Save pour enregistrer les changements. Ensuite, pour exécuter votre code, choisissez Test.

Note

La console Lambda utilise AWS Cloud9 pour fournir un environnement de développement intégré dans le navigateur. Vous pouvez également utiliser AWS Cloud9 pour développer des fonctions Lambda dans votre propre environnement. Pour plus d'informations, veuillez consulter la section Utilisation des fonctions Lambda dans le guide de l'utilisateur AWS Cloud9.

Le fichier index.js exporte une fonction nommée handler qui accepte un objet événement et un objet contexte. Il s’agit de la fonction de gestionnaire que Lambda appelle lors de l’appel de la fonction. Le runtime de la fonction Node.js obtient des événements d’appels à partir de Lambda et les transmet au gestionnaire. Dans la configuration de fonction, la valeur de gestionnaire est index.handler.

Lorsque vous enregistrez votre code de fonction, la console Lambda crée un package de déploiement d’archive de fichiers .zip. Lorsque vous développez votre code de fonction en dehors de la console (à l’aide d’un SDE), vous devez créer un package de déploiement pour charger votre code dans la fonction Lambda.

Note

Pour commencer à développer des applications dans votre environnement local, déployez l’un des exemples d’applications disponibles dans le référentiel GitHub de ce guide.

Exemples d’applications Lambda en Node.js

  • blank-nodejs – Fonction Node.js qui montre l’utilisation de la journalisation, des variables d’environnement, du suivi de AWS X-Ray, des couches, des tests unitaires et du kit SDK AWS.

  • nodejs-apig – Fonction avec un point de terminaison d’API public qui traite un événement d’API Gateway et renvoie une réponse HTTP.

  • rds-mysql – Fonction qui relaie les requêtes vers une base de données MySQL pour RDS. Cet exemple inclut un VPC privé et une instance de base de données configurée avec un mot de passe dans AWS Secrets Manager.

  • efs-nodejs – Fonction qui utilise un système de fichiers Amazon EFS dans un VPC Amazon. Cet exemple inclut un VPC, un système de fichiers, des cibles de montage et un point d’accès configurés pour une utilisation avec Lambda.

  • list-manager – Fonction qui traite les événements à partir d’un flux de données Amazon Kinesis et met à jour les listes agrégées dans Amazon DynamoDB. La fonction stocke un enregistrement de chaque événement dans une base de données MySQL pour RDS dans un VPC privé. Cet exemple inclut un VPC privé avec un point de terminaison de VPC pour DynamoDB et une instance de base de données.

  • error-processor – Fonction Node.js qui génère des erreurs pour un pourcentage spécifié de demandes. Un abonnement CloudWatch Logs appelle une deuxième fonction quand une erreur est enregistrée. La fonction de processeur utilise le kit SDK AWS pour collecter des détails sur la demande, qu’elle stocke dans un compartiment Amazon S3.

Le runtime de la fonction transmet un objet de contexte au gestionnaire, en plus de l’événement d’appel. L’objet de contexte contient des informations supplémentaires sur l’appel, la fonction et l’environnement d’exécution. Des informations supplémentaires sont disponibles dans les variables d’environnement.

Votre fonction Lambda intègre un groupe de journaux CloudWatch Logs. Le runtime de la fonction envoie à CloudWatch Logs des détails sur chaque appel. Il relaie tous les journaux que votre fonction génère pendant l'appel. Si votre fonction renvoie une erreur, Lambda met en forme l'erreur et la renvoie à l'appelant.

Initialisation de Node.js

Node.js possède un modèle de boucle d'événements exclusif qui rend son comportement d'initialisation différent des autres exécutions. Plus précisément, Node.js utilise un modèle d'I/O non bloquant qui prend en charge les opérations asynchrones. Ce modèle permet à Node.js de fonctionner efficacement pour la plupart des charges de travail. Par exemple, si une fonction Node.js effectue un appel réseau, cette demande peut être désignée comme une opération asynchrone et placée dans une file d'attente de rappel. La fonction peut continuer à traiter d'autres opérations dans la pile d'appels principale sans être bloquée en attendant le retour de l'appel réseau. Une fois l'appel réseau renvoyé, son rappel est exécuté, puis supprimé de la file d'attente de rappel.

Certaines tâches d'initialisation peuvent s'exécuter de manière asynchrone. L'exécution de ces tâches asynchrones n'est pas garantie avant l'appel. Par exemple, le code qui effectue un appel réseau pour récupérer un paramètre depuis AWS Parameter Store peut ne pas être terminé au moment où Lambda exécute la fonction de gestionnaire. Par conséquent, la variable peut être nulle lors d'un appel. Pour éviter cela, assurez-vous que les variables et autres codes asynchrones sont entièrement initialisés avant de poursuivre le reste de la logique métier principale de la fonction.

Désignation d'un gestionnaire de fonctions en tant que module ES

À partir de Node 14, vous pouvez garantir l'achèvement du code d'initialisation asynchrone avant les appels du gestionnaire en désignant votre code comme module ES et en utilisant le niveau supérieur d'attente. Les packages sont désignés en tant que modules CommonJS par défaut, ce qui signifie que vous devez d'abord désigner votre code de fonction comme module ES pour utiliser le niveau supérieur en attente. Vous pouvez effectuer cette opération de deux manières : spécifier le document type en tant que module dans le document package.json ou en utilisant l'extension de nom de fichier .mjs.

Dans le premier scénario, votre code de fonction traite tous les fichiers .js comme des modules ES, tandis que dans le second scénario, seul le fichier que vous spécifiez avec .mjs est un module ES. Vous pouvez mélanger les modules ES et les modules CommonJS en les nommant respectivement .mjs et .cjs, car les fichiers .mjs sont toujours des modules ES et les fichiers .cjs sont toujours des modules CommonJS.

Pour obtenir des informations et un exemple, consultez Utilisation des modules ES Node.js et de premier niveau d'attente dans AWS Lambda.