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.
# Création de fonctions Lambda avec Ruby
Vous pouvez exécuter du code Ruby dans AWS Lambda. Lambda fournit des [runtimes](lambda-runtimes.md) pour Ruby qui exécutent votre code afin de traiter des événements. Votre code s'exécute dans un environnement qui inclut le AWS SDK pour Ruby, avec les informations d'identification d'un rôle Gestion des identités et des accès AWS (IAM) que vous gérez. Pour en savoir plus sur les versions du kit SDK incluses dans les environnements d’exécution Ruby, consultez [Versions du SDK incluses dans l’environnement d’exécution](#ruby-sdk-included).
Lambda prend en charge les runtimes Ruby suivants.
| Nom | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 31 mars 2028 | 30 avril 2028 | 31 mai 2028 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 31 mars 2027 | 30 avril 2027 | 31 mai 2027 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 31 mars 2026 | 31 août 2026 | 30 sept. 2026 |
**Pour créer une fonction Ruby**
1. Ouvrez la [console Lambda](https://console.aws.amazon.com/lambda).
1. Sélectionnez **Créer une fonction**.
1. Configurez les paramètres suivants :
+ **Nom de la fonction** : saisissez le nom de la fonction.
+ **Runtime** : Choisissez **Ruby 3.4**.
1. Choisissez **Créer une fonction**.
La console crée une fonction Lambda avec un seul fichier source nommé `lambda_function.rb`. Vous pouvez modifier ce fichier et ajouter d'autres fichiers dans l'éditeur de code intégré. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction. Ensuite, pour exécuter votre code, choisissez **Créer un événement de test** dans la section **ÉVÉNEMENTS DE TEST**.
Le fichier `lambda_function.rb` exporte une fonction nommée `lambda_handler` qui accepte un objet événement et un objet contexte. Il s'agit de la [fonction de gestionnaire](ruby-handler.md) que Lambda appelle lors de l'invocation de la fonction. L'environnement d'exécution (runtime) de la fonction Ruby obtient les événements d'invocations de Lambda et les transmet au gestionnaire. Dans la configuration de fonction, la valeur de gestionnaire est `lambda_function.lambda_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 IDE), vous devez [créer un package de déploiement](ruby-package.md) pour charger votre code dans la fonction Lambda.
Le runtime de la fonction transmet un objet de contexte au gestionnaire, en plus de l’événement d’invocation. L’[objet de contexte](ruby-context.md) contient des informations supplémentaires sur l’invocation, la fonction et l’environnement d’exécution. Des informations supplémentaires sont disponibles dans les variables d’environnement.
Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs. La fonction runtime envoie les détails de chaque appel à CloudWatch Logs. Il relaie tous les [journaux que votre fonction génère](ruby-logging.md) pendant l’invocation. Si votre fonction renvoie une erreur, Lambda met en forme l’erreur et la renvoie à l’appelant.
**Topics**
+ [
## Versions du SDK incluses dans l’environnement d’exécution
](#ruby-sdk-included)
+ [
## Activer un autre JIT Ruby (YJIT)
](#ruby-yjit)
+ [
# Définition du gestionnaire de fonction Lambda dans Ruby
](ruby-handler.md)
+ [
# Déployer des fonctions Lambda en Ruby avec des archives de fichiers .zip
](ruby-package.md)
+ [
# Déploiement de fonctions Lambda en Ruby avec des images conteneurs
](ruby-image.md)
+ [
# Utilisation de couches pour les fonctions Lambda Ruby
](ruby-layers.md)
+ [
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Ruby
](ruby-context.md)
+ [
# Journalisation et surveillance des fonctions Lambda Ruby
](ruby-logging.md)
+ [
# Instrumentation du code Ruby dans AWS Lambda
](ruby-tracing.md)
## Versions du SDK incluses dans l’environnement d’exécution
La version du AWS SDK incluse dans le runtime Ruby dépend de la version d'exécution et de votre Région AWS. Le AWS SDK pour Ruby est conçu pour être modulaire et est séparé par Service AWS. Pour trouver le numéro de version d’un gem de service particulier inclus dans l’environnement d’exécution que vous utilisez, créez une fonction Lambda avec un code au format suivant. Remplacez `aws-sdk-s3` et `Aws::S3` par le nom des gems de service utilisés par votre code.
```
require 'aws-sdk-s3'
def lambda_handler(event:, context:)
puts "Service gem version: #{Aws::S3::GEM_VERSION}"
puts "Core version: #{Aws::CORE_GEM_VERSION}"
end
```
## Activer un autre JIT Ruby (YJIT)
Les environnements d'exécution Ruby supportent [YJIT](https://docs.ruby-lang.org/en/master/jit/yjit_md.html), un compilateur Ruby JIT léger et minimaliste. YJIT offre des performances nettement supérieures, mais utilise également plus de mémoire que l'interpréteur Ruby. YJIT est recommandé pour les charges de travail Ruby on Rails.
YJIT n'est pas activé par défaut. Pour activer YJIT pour une fonction Ruby, définissez la variable d'`RUBY_YJIT_ENABLE`environnement sur`1`. Pour confirmer que YJIT est activé, imprimez le résultat de la méthode `RubyVM::YJIT.enabled?`.
**Example – Confirmez que YJIT est activé**
```
puts(RubyVM::YJIT.enabled?())
# => true
```
# Définition du gestionnaire de fonction Lambda dans Ruby
Le *gestionnaire* de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.
**Topics**
+ [
## Notions de base sur le gestionnaire Ruby
](#ruby-handler-basics)
+ [
## Pratiques exemplaires en matière de code pour les fonctions Lambda Ruby
](#ruby-best-practices)
## Notions de base sur le gestionnaire Ruby
Dans l’exemple suivant, le fichier `function.rb` définit une méthode de gestionnaire nommée `handler`. La fonction de gestionnaire prend deux objets en tant qu’entrées et renvoie un document JSON.
**Example function.rb**
```
require 'json'
def handler(event:, context:)
{ event: JSON.generate(event), context: JSON.generate(context.inspect) }
end
```
Dans la configuration de votre fonction, le paramètre `handler` indique à Lambda où trouver le gestionnaire. Pour l’exemple précédent, la valeur correcte pour ce paramètre est **function.handler**. Elle inclut deux noms séparées par un point : le nom du fichier et le nom de la méthode de gestionnaire.
Vous pouvez également définir votre méthode de gestionnaire dans une classe. L’exemple suivant définit une méthode de gestionnaire nommée `process` sur une classe nommée `Handler` dans un module appelé `LambdaFunctions`.
**Example source.rb**
```
module LambdaFunctions
class Handler
def self.process(event:,context:)
"Hello!"
end
end
end
```
Dans ce cas, le paramètre de gestionnaire est **source.LambdaFunctions::Handler.process**.
Les deux objets qui sont acceptés par le gestionnaire sont l’événement d’invocation et le contexte. L’événement est un objet Ruby qui contient la charge utile qui est fournie par le mécanisme d’invocation. Si la charge utile est un document JSON, l’objet d’événement est un hachage Ruby. Sinon, il s’agit d’une chaîne. L’[objet de contexte](ruby-context.md) contient des méthodes et des propriétés qui fournissent des informations sur l’invocation, la fonction et l’environnement d’exécution.
Le gestionnaire de fonction est exécuté chaque fois que votre fonction Lambda est invoquée. Le code statique à l’extérieur du gestionnaire est exécuté une fois par instance de la fonction. Si votre gestionnaire utilise des ressources telles que les clients de kits SDK et les connexions de base de données, vous pouvez les créer à l’extérieur de la méthode de gestionnaire afin de les réutiliser pour plusieurs invocations.
Chaque instance de votre fonction peut traiter plusieurs événements d’invocations, mais elle ne traite qu’un événement à la fois. Le nombre d’instances traitant un événement à un moment donné est la *simultanéité de votre fonction*. Pour plus d’informations sur l’environnement d’exécution Lambda, consultez [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
## Pratiques exemplaires en matière de code pour les fonctions Lambda Ruby
Respectez les directives de la liste suivante pour utiliser les pratiques exemplaires de codage lors de la création de vos fonctions Lambda :
+ **Séparez le gestionnaire Lambda de votre logique principale.** Cela vous permet de créer une fonction testable plus unitaire. Par exemple, en Ruby, vous pouvez observer ce qui suit :
```
def lambda_handler(event:, context:)
foo = event['foo']
bar = event['bar']
result = my_lambda_function(foo:, bar:)
end
def my_lambda_function(foo:, bar:)
// MyLambdaFunction logic here
end
```
+ **Contrôlez les dépendances du package de déploiement de vos fonctions. ** L’environnement d’exécution AWS Lambda contient un certain nombre de bibliothèques. Pour l’environnement d’exécution Ruby, celles-ci incluent notamment le kit SDK AWS. Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.
+ **Réduisez la complexité de vos dépendances.** Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’[environnement d’exécution](lambda-runtime-environment.md).
+ **Réduisez la taille de votre package de déploiement selon ses besoins relatifs à l’environnement d’exécution. ** Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l’invocation. Pour les fonctions créées en Ruby, évitez de charger la totalité de la bibliothèque du kit SDK AWS comme partie intégrante de votre package de déploiement. À la place, appuyez-vous de façon sélective sur les gems qui sélectionnent les composants du kit SDK dont vous avez besoin (par exemple, les gems du kit SDK DynamoDB ou SDK Amazon S3).
**Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction.** Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire `/tmp`. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.
Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.
**Utilisez une directive keep-alive pour maintenir les connexions persistantes.** Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez [Réutilisation des connexions avec Keep-Alive dans Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
**Utilisez des [variables d’environnement](configuration-envvars.md) pour transmettre des paramètres opérationnels à votre fonction.** Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.
**Évitez d’utiliser des invocations récursives** dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur `0` afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.
**N’utilisez pas d’API non publiques non documentées** dans le code de votre fonction Lambda. Pour les exécutions gérées AWS Lambda, Lambda applique périodiquement des mises à jour de sécurité et fonctionnelles aux API internes de Lambda. Ces mises à jour internes de l’API peuvent être incompatibles avec les versions antérieures, entraînant des conséquences imprévues telles que des échecs d’invocation si votre fonction dépend de ces API non publiques. Consultez la [Référence d’API](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) pour obtenir la liste des API accessibles au public.
**Écriture du code idempotent.** L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulter[Comment faire en sorte que ma fonction Lambda soit idempotente ?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).
# Déployer des fonctions Lambda en Ruby avec des archives de fichiers .zip
Le code de votre fonction AWS Lambda comprend un fichier .rb contenant le code du gestionnaire de votre fonction, ainsi que toutes les dépendances (GEM) supplémentaires dont votre code dépend. Pour déployer ce code de fonction vers Lambda, vous utilisez un *package de déploiement*. Ce package peut être une archive de fichier .zip ou une image de conteneur. Pour plus d’informations sur l’utilisation d’images de conteneur avec Ruby, consultez la page [Déployer des fonctions Lambda Ruby avec des images de conteneur](https://docs.aws.amazon.com/lambda/latest/dg/ruby-image.html).
Pour créer votre package de déploiement sous forme d’archive de fichier .zip, vous pouvez utiliser l’utilitaire d’archivage .zip intégré à votre outil de ligne de commande, ou tout autre utilitaire .zip tel que [7zip](https://www.7-zip.org/download.html). Les exemples présentés dans les sections suivantes supposent que vous utilisez un outil `zip` de ligne de commande dans un environnement Linux ou macOS. Pour utiliser les mêmes commandes sous Windows, vous pouvez [installer le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et de Bash.
Notez que Lambda utilise les autorisations de fichiers POSIX. Ainsi, vous pourriez devoir [définir des autorisations pour le dossier du package de déploiement](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-deployment-package-errors/) avant de créer l’archive de fichiers .zip.
Les exemples de commandes présentés dans les sections suivantes utilisent l’utilitaire [Bundler](https://bundler.io/) pour ajouter des dépendances à votre package de déploiement. Pour installer Bundler, exécutez la commande suivante.
```
gem install bundler
```
**Topics**
+ [
## Dépendances dans Ruby
](#ruby-package-runtime-dependencies)
+ [
## Création d’un package de déploiement .zip sans dépendances
](#ruby-package-codeonly)
+ [
## Création d’un package de déploiement .zip avec dépendances
](#ruby-package-dependencies)
+ [
## Création d’une couche Ruby pour vos dépendances
](#ruby-package-dependencies-layers)
+ [
## Création de packages de déploiement .zip avec des bibliothèques natives
](#ruby-package-native)
+ [
## Création et mise à jour de fonctions Lambda Ruby à l’aide de fichiers .zip
](#ruby-package-create-functions)
## Dépendances dans Ruby
Pour les fonctions Lambda qui utilisent l’exécution Ruby, une dépendance peut être n’importe quelle GEM Ruby. Lorsque vous déployez votre fonction à l’aide d’une archive .zip, vous pouvez soit ajouter ces dépendances à votre fichier .zip avec votre code de fonction, soit utiliser une couche Lambda. Une couche est un fichier .zip séparé qui peut contenir du code supplémentaire et d’autres contenus. Pour en savoir plus sur l’utilisation des couches Lambda, consultez [Gestion des dépendances Lambda à l’aide de couches](chapter-layers.md).
L’environnement d’exécution Ruby inclut l’AWS SDK pour Ruby. Si votre fonction utilise le kit SDK, vous n’avez pas besoin de l’intégrer à votre code. Toutefois, pour garder le contrôle total de vos dépendances ou pour utiliser une version spécifique du kit SDK, vous pouvez l’ajouter au package de déploiement de votre fonction. Vous pouvez inclure le kit SDK dans votre fichier .zip ou bien l’ajouter à l’aide d’une couche Lambda. Les dépendances de votre fichier .zip ou des couches Lambda sont prioritaires sur les versions incluses dans l’exécution. Pour savoir quelle version du kit SDK pour Ruby est incluse dans votre version d’exécution, consultez [Versions du SDK incluses dans l’environnement d’exécution](lambda-ruby.md#ruby-sdk-included).
Dans le cadre du [modèle de responsabilité partagée AWS](lambda-runtimes.md#runtimes-shared-responsibility), vous êtes responsable de la gestion de toutes les dépendances dans les packages de déploiement de vos fonctions. Cela inclut l’application de mises à jour et de correctifs de sécurité. Pour mettre à jour les dépendances dans le package de déploiement de votre fonction, créez d’abord un nouveau fichier .zip, puis chargez-le sur Lambda. Pour plus d’informations, consultez [Création d’un package de déploiement .zip avec dépendances](#ruby-package-dependencies) et [Création et mise à jour de fonctions Lambda Ruby à l’aide de fichiers .zip](#ruby-package-create-functions).
## Création d’un package de déploiement .zip sans dépendances
Si le code de votre fonction ne comporte aucune dépendance, votre fichier .zip contient uniquement le fichier .rb contenant le code du gestionnaire de votre fonction. Utilisez votre utilitaire zip préféré pour créer un fichier .zip avec votre fichier .rb à la racine. Si le fichier .rb ne se trouve pas à la racine de votre fichier .zip, Lambda ne sera pas en mesure d’exécuter votre code.
Pour savoir comment déployer votre fichier .zip pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante, veuillez consulter la rubrique [Création et mise à jour de fonctions Lambda Ruby à l’aide de fichiers .zip](#ruby-package-create-functions).
## Création d’un package de déploiement .zip avec dépendances
Si votre code de fonction dépend de GEM Ruby supplémentaires, vous pouvez soit ajouter ces dépendances à votre fichier .zip avec votre code de fonction, soit utiliser une [couche Lambda](chapter-layers.md). Les instructions de cette section vous indiquent comment inclure les dépendances dans votre package de déploiement .zip. Pour obtenir des instructions sur la façon d’inclure vos dépendances dans une couche, voir [Création d’une couche Ruby pour vos dépendances](#ruby-package-dependencies-layers).
Supposons que votre code de fonction soit enregistré dans un fichier nommé `lambda_function.rb` dans le répertoire de votre projet. L’exemple de commandes d’interface de ligne de commande suivant crée un fichier .zip nommé `my_deployment_package.zip` contenant le code de votre fonction et ses dépendances.
**Pour créer le package de déploiement**
1. Dans le répertoire de votre projet, créez un fichier `Gemfile` pour y spécifier vos dépendances.
```
bundle init
```
1. En utilisant l’éditeur de texte de votre choix, modifiez le fichier `Gemfile` pour spécifier les dépendances de votre fonction. Par exemple, pour utiliser la GEM TZInfo, modifiez votre fichier `Gemfile` pour qu’il ressemble à ce qui suit.
```
source "https://rubygems.org"
gem "tzinfo"
```
1. Exécutez la commande suivante pour installer les GEM spécifiées dans votre fichier `Gemfile` dans votre répertoire de projet. Cette commande définit `vendor/bundle` comme chemin par défaut pour les installations de GEM.
```
bundle config set --local path 'vendor/bundle' && bundle install
```
Vous devez visualiser des résultats similaires à ce qui suit.
```
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Using bundler 2.4.13
Fetching tzinfo 2.0.6
Installing tzinfo 2.0.6
...
```
**Note**
Pour réinstaller globalement les GEM ultérieurement, exécutez la commande suivante.
```
bundle config set --local system 'true'
```
1. Créez une archive de fichiers .zip contenant le fichier `lambda_function.rb` avec le code du gestionnaire de votre fonction et les dépendances que vous avez installées à l’étape précédente.
```
zip -r my_deployment_package.zip lambda_function.rb vendor
```
Vous devez visualiser des résultats similaires à ce qui suit.
```
adding: lambda_function.rb (deflated 37%)
adding: vendor/ (stored 0%)
adding: vendor/bundle/ (stored 0%)
adding: vendor/bundle/ruby/ (stored 0%)
adding: vendor/bundle/ruby/3.2.0/ (stored 0%)
adding: vendor/bundle/ruby/3.2.0/build_info/ (stored 0%)
adding: vendor/bundle/ruby/3.2.0/cache/ (stored 0%)
adding: vendor/bundle/ruby/3.2.0/cache/aws-eventstream-1.0.1.gem (deflated 36%)
...
```
## Création d’une couche Ruby pour vos dépendances
Pour savoir comment empaqueter vos dépendances Ruby dans une couche Lambda, consultez [Utilisation de couches pour les fonctions Lambda Ruby](ruby-layers.md).
## Création de packages de déploiement .zip avec des bibliothèques natives
De nombreuses GEM Ruby courantes telles que `nokogiri`, `nio4r` et `mysql` contiennent des extensions natives écrites en C. Lorsque vous ajoutez des bibliothèques contenant du code C à votre package de déploiement, vous devez créer votre package correctement pour vous assurer qu’il est compatible avec l’environnement d’exécution Lambda.
Pour les applications de production, nous vous recommandons de créer et de déployer votre code en utilisant AWS Serverless Application Model (AWS SAM). Dans AWS SAM utilisez l’option `sam build --use-container` pour créer votre fonction dans un conteneur Docker de type Lambda. Pour en savoir plus sur l’utilisation de AWS SAM pour déployer le code de vos fonctions, consultez la section [Création d’applications](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-build.html) dans le *Guide du développeur AWS SAM*.
Pour créer un package de déploiement .zip contenant des GEM avec des extensions natives sans utiliser AWS SAM, vous pouvez également utiliser un conteneur pour regrouper vos dépendances dans un environnement identique à l’environnement d’exécution Lambda Ruby. Pour réaliser ces étapes, Docker doit être installé sur votre machine de génération. Pour en savoir plus sur l’installation de Docker, consultez [Installation du moteur Docker](https://docs.docker.com/engine/install/).
**Pour créer un package de déploiement .zip dans un conteneur Docker**
1. Créez un dossier sur votre machine de génération locale pour y enregistrer votre conteneur. Dans ce dossier, créez un fichier nommé `dockerfile` et collez-y le code suivant.
```
FROM public.ecr.aws/sam/build-ruby3.2:latest-x86_64
RUN gem update bundler
CMD "/bin/bash"
```
1. Dans le dossier dans lequel vous avez créé votre fichier `dockerfile`, exécutez la commande suivante pour créer le conteneur Docker.
```
docker build -t awsruby32 .
```
1. Accédez au répertoire du projet contenant le fichier `.rb` avec le code du gestionnaire de votre fonction et le fichier `Gemfile` spécifiant les dépendances de votre fonction. À partir de ce répertoire, exécutez la commande suivante pour démarrer le conteneur Lambda Ruby.
------
#### [ Linux/MacOS ]
```
docker run --rm -it -v $PWD:/var/task -w /var/task awsruby32
```
**Note**
Sous macOS, il se peut qu’un avertissement vous informe que la plateforme de l’image demandée ne correspond pas à la plateforme de l’hôte détectée. Ignorez cet avertissement.
------
#### [ Windows PowerShell ]
```
docker run --rm -it -v ${pwd}:var/task -w /var/task awsruby32
```
------
Lorsque votre conteneur démarre, vous devriez voir une invite bash.
```
bash-4.2#
```
1. Configurez l’utilitaire bundle pour installer les GEM spécifiées dans votre fichier `Gemfile` dans votre répertoire `vendor/bundle` local et installer vos dépendances.
```
bash-4.2# bundle config set --local path 'vendor/bundle' && bundle install
```
1. Créez le package de déploiement .zip avec le code de votre fonction et ses dépendances. Dans cet exemple, le fichier contenant le code du gestionnaire de votre fonction est nommé `lambda_function.rb`.
```
bash-4.2# zip -r my_deployment_package.zip lambda_function.rb vendor
```
1. Quittez le conteneur et retournez dans votre répertoire de projet local.
```
bash-4.2# exit
```
Vous pouvez désormais utiliser le package de déploiement du fichier .zip pour créer ou mettre à jour votre fonction Lambda. Consultez [Création et mise à jour de fonctions Lambda Ruby à l’aide de fichiers .zip](#ruby-package-create-functions)
## Création et mise à jour de fonctions Lambda Ruby à l’aide de fichiers .zip
Une fois que vous avez créé votre package de déploiement .zip, vous pouvez l’utiliser pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante. Vous pouvez déployer votre package .zip à l’aide de la console Lambda, de l’AWS Command Line Interface, et de l’API Lambda. Vous pouvez également créer et mettre à jour des fonctions Lambda à l’aide de l’AWS Serverless Application Model (AWS SAM) et de CloudFormation.
La taille maximale d’un package de déploiement .zip pour Lambda est de 250 Mo (décompressé). Notez que cette limite s’applique à la taille combinée de tous les fichiers que vous chargez, y compris les couches Lambda.
Le runtime Lambda a besoin d’une autorisation pour lire les fichiers de votre package de déploiement. Dans la notation octale des autorisations Linux, Lambda a besoin de 644 autorisations pour les fichiers non exécutables (rw-r--r--) et de 755 autorisations (rwxr-xr-x) pour les répertoires et les fichiers exécutables.
Sous Linux et macOS, utilisez la commande `chmod` pour modifier les autorisations de fichiers sur les fichiers et les répertoires de votre package de déploiement. Par exemple, pour octroyer à un fichier non exécutable les autorisations correctes, exécutez la commande suivante.
```
chmod 644
```
Pour modifier les autorisations relatives aux fichiers dans Windows, voir [Définir, afficher, modifier ou supprimer des autorisations sur un objet](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) dans la documentation Microsoft Windows.
**Note**
Si vous n’octroyez pas à Lambda les autorisations dont il a besoin pour accéder aux répertoires de votre package de déploiement, Lambda définit les autorisations de ces répertoires à 755 (rwxr-xr-x).
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de la console
Pour créer une nouvelle fonction, vous devez d’abord créer la fonction dans la console, puis charger votre archive .zip. Pour mettre à jour une fonction existante, ouvrez la page de votre fonction, puis suivez la même procédure pour ajouter votre fichier .zip mis à jour.
Si votre fichier .zip fait moins de 50 Mo, vous pouvez créer ou mettre à jour une fonction en chargeant le fichier directement à partir de votre ordinateur local. Pour les fichiers .zip de plus de 50 Mo, vous devez d’abord charger votre package dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l’aide de la AWS Management Console, veuillez consulter la rubrique [Premiers pas avec Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). Pour charger des fichiers à l’aide de l’AWS CLI, veuillez consulter la rubrique [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *Guide de l’utilisateur AWS CLI*.
**Note**
Vous ne pouvez pas modifier le [type de package de déploiement](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-PackageType) (.zip ou image de conteneur) d’une fonction existante. Par exemple, vous ne pouvez pas convertir une fonction d’image de conteneur pour utiliser un fichier d’archive .zip à la place. Vous devez créer une nouvelle fonction.
**Pour créer une nouvelle fonction (console)**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Informations de base**, procédez comme suit :
1. Pour **Nom de la fonction**, saisissez le nom de la fonction.
1. Pour **Exécution**, sélectionnez l’exécution que vous souhaitez utiliser.
1. (Facultatif) Pour **Architecture**, choisissez l’architecture de l’ensemble des instructions pour votre fonction. L’architecture par défaut est x86\$164. Assurez-vous que le package de déploiement .zip pour votre fonction est compatible avec l’architecture de l’ensemble d’instructions que vous sélectionnez.
1. (Facultatif) Sous **Permissions (Autorisations)**, développez **Change default execution role (Modifier le rôle d’exécution par défaut)**. Vous pouvez créer un **rôle d’exécution** ou en utiliser un existant.
1. Choisissez **Créer une fonction**. Lambda crée une fonction de base « Hello world » à l’aide de l’exécution de votre choix.
**Pour charger une archive .zip à partir de votre ordinateur local (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger le fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez **Fichier .zip**.
1. Pour charger un fichier .zip, procédez comme suit :
1. Sélectionnez **Charger**, puis choisissez votre fichier .zip dans le sélecteur de fichiers.
1. Choisissez **Ouvrir**.
1. Choisissez **Enregistrer**.
**Pour charger une archive .zip depuis un compartiment Amazon S3 (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger un nouveau fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez l’**emplacement Amazon S3**.
1. Collez l’URL du lien Amazon S3 de votre fichier .zip et choisissez **Enregistrer**.
### Mise à jour des fonctions du fichier .zip à l’aide de l’éditeur de code de la console
Pour certaines fonctions avec des packages de déploiement .zip, vous pouvez utiliser l’éditeur de code intégré de la console Lambda pour mettre à jour le code de votre fonction directement. Pour utiliser cette fonctionnalité, votre fonction doit répondre aux critères suivants :
+ Votre fonction doit utiliser l’une des exécutions des langages interprétés (Python, Node.js ou Ruby).
+ La taille du package de déploiement de votre fonction doit être inférieure à 50 Mo (décompressé).
Le code des fonctions avec les packages de déploiement d’images de conteneurs ne peut pas être édité directement dans la console.
**Pour mettre à jour le code de fonction à l’aide de l’éditeur de code de la console**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, sélectionnez votre fichier de code source et modifiez-le dans l’éditeur de code intégré.
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de l’AWS CLI
Vous pouvez utiliser l’[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) pour créer une nouvelle fonction ou pour mettre à jour une fonction existante à l’aide d’un fichier .zip. Utilisez les commandes [create-function](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) et [update-function-code](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) pour déployer votre package .zip. Si votre fichier .zip est inférieur à 50 Mo, vous pouvez charger le package .zip à partir d’un emplacement de fichier sur votre machine de génération locale. Pour les fichiers plus volumineux, vous devez charger votre package .zip à partir d’un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l’aide de l’AWS CLI, veuillez consulter la rubrique [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *Guide de l’utilisateur AWS CLI*.
**Note**
Si vous chargez votre fichier .zip à partir d’un compartiment Amazon S3 à l’aide de l’AWS CLI, le compartiment doit se trouver dans la même Région AWS que votre fonction.
Pour créer une nouvelle fonction à l’aide d’un fichier .zip avec l’AWS CLI, vous devez spécifier les éléments suivants :
+ Le nom de votre fonction (`--function-name`)
+ L’exécution de votre fonction (`--runtime`)
+ L’Amazon Resource Name (ARN) du [rôle d’exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de votre fonction (`--role`)
+ Le nom de la méthode du gestionnaire dans votre code de fonction (`--handler`)
Vous devez également indiquer l’emplacement de votre fichier .zip. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda create-function --function-name myFunction \
--runtime ruby3.2 --handler lambda_function.lambda_handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez l’option `--code` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `S3ObjectVersion` pour les objets soumis à la gestion des versions.
```
aws lambda create-function --function-name myFunction \
--runtime ruby3.2 --handler lambda_function.lambda_handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--code S3Bucket=amzn-s3-demo-bucket,S3Key=myFileName.zip,S3ObjectVersion=myObjectVersion
```
Pour mettre à jour une fonction existante à l’aide de l’interface de ligne de commande, vous devez spécifier le nom de votre fonction à l’aide du paramètre `--function-name`. Vous devez également spécifier l’emplacement du fichier .zip que vous souhaitez utiliser pour mettre à jour votre code de fonction. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda update-function-code --function-name myFunction \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez les options `--s3-bucket` et `--s3-key` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `--s3-object-version` pour les objets soumis à la gestion des versions.
```
aws lambda update-function-code --function-name myFunction \
--s3-bucket amzn-s3-demo-bucket --s3-key myFileName.zip --s3-object-version myObject Version
```
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de l’API Lambda
Pour créer et mettre à jour des fonctions à l’aide d’une archive de fichiers .zip, utilisez les opérations d’API suivantes :
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide d’AWS SAM
L’AWS Serverless Application Model (AWS SAM) est une boîte à outils qui permet de rationaliser le processus de création et d’exécution d’applications sans serveur sur AWS. Vous définissez les ressources de votre application dans un modèle YAML ou JSON et vous utilisez l’interface de ligne de commande AWS SAM (AWS SAM CLI) pour créer, empaqueter et déployer vos applications. Lorsque vous créez une fonction Lambda à partir d’un modèle AWS SAM, AWS SAM crée automatiquement un package de déploiement .zip ou une image de conteneur avec le code de votre fonction et les dépendances que vous spécifiez. Pour en savoir plus sur l’utilisation d’AWS SAM pour créer et déployer des fonctions Lambda, veuillez consulter la rubrique [Premiers pas avec AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started.html) dans le *Guide du développeur AWS Serverless Application Model*.
Vous pouvez également utiliser AWS SAM pour créer une fonction Lambda à l’aide d’une archive de fichiers .zip existante. Pour créer une fonction Lambda à l’aide d’AWS SAM, vous pouvez enregistrer votre fichier .zip dans un compartiment Amazon S3 ou dans un dossier local sur votre machine de génération. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l’aide de l’AWS CLI, veuillez consulter la rubrique [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *Guide de l’utilisateur AWS CLI*.
Dans votre modèle AWS SAM, la ressource `AWS::Serverless::Function` spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `CodeUri` : défini comme l’URI Amazon S3 du code de la fonction, le chemin d’accès vers le dossier local ou l’objet [FunctionCode](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-functioncode.html)
+ `Runtime` : défini sur votre exécution choisie
Avec AWS SAM, si votre fichier .zip est supérieur à 50 Mo, vous n’avez pas à le charger au préalable dans un compartiment Amazon S3. AWS SAM peut charger des packages .zip jusqu’à la taille maximale autorisée de 250 Mo (décompressés) à partir d’un emplacement sur votre machine de génération locale.
Pour en savoir plus sur le déploiement de fonctions à l’aide d’un fichier .zip dans AWS SAM, veuillez consulter [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) dans le *Guide du développeur AWS SAM*.
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide d’CloudFormation
Vous pouvez utiliser CloudFormation pour créer une fonction Lambda à l’aide d’une archive de fichiers .zip. Pour créer une fonction Lambda à partir d’un fichier .zip, vous devez d’abord charger votre fichier dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l’aide de l’AWS CLI, veuillez consulter la rubrique [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *Guide de l’utilisateur AWS CLI*.
Dans votre modèle CloudFormation, la ressource `AWS::Lambda::Function` spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `Code` : saisissez le nom du compartiment Amazon S3 et le nom du fichier .zip dans les champs `S3Bucket` et `S3Key`
+ `Runtime` : défini sur votre exécution choisie
Le fichier .zip que CloudFormation génère ne peut pas dépasser 4 Mo. Pour en savoir plus sur le déploiement de fonctions à l’aide d’un fichier .zip dans CloudFormation, veuillez consulter [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) dans le *Guide de l’utilisateur CloudFormation*.
# Déploiement de fonctions Lambda en Ruby avec des images conteneurs
Il existe trois méthodes pour créer une image de conteneur pour une fonction Lambda Ruby :
+ [Utiliser une image AWS de base pour Ruby](#ruby-image-instructions)
Les [images de base AWS](images-create.md#runtimes-images-lp) sont préchargées avec une exécution du langage, un client d’interface d’exécution pour gérer l’interaction entre Lambda et votre code de fonction, et un émulateur d’interface d’exécution pour les tests locaux.
+ [Utilisation d'une image de base AWS uniquement pour le système d'exploitation](images-create.md#runtimes-images-provided)
[AWS Les images de base réservées](https://gallery.ecr.aws/lambda/provided) au système d'exploitation contiennent une distribution Amazon Linux et l'émulateur [d'interface d'exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Ces images sont couramment utilisées pour créer des images de conteneur pour les langages compilés, tels que [Go](go-image.md#go-image-provided) et [Rust](lambda-rust.md), et pour une langue ou une version linguistique pour laquelle Lambda ne fournit pas d’image de base, comme Node.js 19. Vous pouvez également utiliser des images de base uniquement pour le système d’exploitation pour implémenter un [environnement d’exécution personnalisé](runtimes-custom.md). Pour rendre l’image compatible avec Lambda, vous devez inclure le [client d’interface d’exécution pour Ruby](#ruby-image-clients) dans l’image.
+ [Utilisation d'une image non AWS basique](#ruby-image-clients)
Vous pouvez utiliser une autre image de base à partir d’un autre registre de conteneur, comme Alpine Linux ou Debian. Vous pouvez également utiliser une image personnalisée créée par votre organisation. Pour rendre l’image compatible avec Lambda, vous devez inclure le [client d’interface d’exécution pour Ruby](#ruby-image-clients) dans l’image.
**Astuce**
Pour réduire le temps nécessaire à l’activation des fonctions du conteneur Lambda, consultez [Utiliser des générations en plusieurs étapes](https://docs.docker.com/build/building/multi-stage/) (français non garanti) dans la documentation Docker. Pour créer des images de conteneur efficaces, suivez la section [Bonnes pratiques pour l’écriture de Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) (français non garanti).
Cette page explique comment créer, tester et déployer des images de conteneur pour Lambda.
**Topics**
+ [
## AWS images de base pour Ruby
](#ruby-image-base)
+ [
## Utiliser une image AWS de base pour Ruby
](#ruby-image-instructions)
+ [
## Utilisation d’une autre image de base avec le client d’interface d’exécution
](#ruby-image-clients)
## AWS images de base pour Ruby
AWS fournit les images de base suivantes pour Ruby :
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| 3.4 | Ruby 3.4 | Amazon Linux 2023 | [Dockerfile pour Ruby 3.4 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/ruby3.4/Dockerfile.ruby3.4) | 31 mars 2028 |
| 3.3 | Ruby 3.3 | Amazon Linux 2023 | [Dockerfile pour Ruby 3.3 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/ruby3.3/Dockerfile.ruby3.3) | 31 mars 2027 |
| 3.2 | Ruby 3.2 | Amazon Linux 2 | [Dockerfile pour Ruby 3.2 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/ruby3.2/Dockerfile.ruby3.2) | 31 mars 2026 |
Référentiel Amazon ECR : [gallery.ecr. aws/lambda/ruby](https://gallery.ecr.aws/lambda/ruby)
## Utiliser une image AWS de base pour Ruby
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Ruby
### Création d’une image à partir d’une image de base
**Pour créer une image de conteneur pour Ruby**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir example
cd example
```
1. Créez un nouveau fichier appelé `Gemfile`. C'est ici que vous listez les RubyGems packages requis pour votre application. Le AWS SDK pour Ruby est disponible auprès de RubyGems. Vous devez choisir des gemmes AWS de service spécifiques à installer. Par exemple, pour utiliser la [gem Ruby pour Lambda](https://rubygems.org/gems/aws-sdk-lambda/), votre Gemfile doit ressembler à ceci :
```
source 'https://rubygems.org'
gem 'aws-sdk-lambda'
```
Sinon, la gemme [aws-sdk](https://rubygems.org/gems/aws-sdk/) contient toutes les gemmes de service disponibles. AWS Cette gem est très large. Nous vous recommandons de ne l'utiliser que si vous dépendez de nombreux AWS services.
1. Installez les dépendances spécifiées dans le fichier Gemfile à l’aide de [l’installation groupée](https://bundler.io/v2.4/man/bundle-install.1.html).
```
bundle install
```
1. Créez un nouveau fichier appelé `lambda_function.rb`. Vous pouvez ajouter l’exemple de code de fonction suivant au fichier pour le tester, ou utiliser le vôtre.
**Example Fonction Ruby**
```
module LambdaFunction
class Handler
def self.process(event:,context:)
"Hello from Lambda!"
end
end
end
```
1. Créez un nouveau fichier Docker. Voici un exemple de Dockerfile qui utilise une [image de base AWS](images-create.md#runtimes-images-lp). Le Dockerfile utilise la configuration suivante :
+ Définissez la propriété `FROM` sur l’URI de l’image de base.
+ Utilisez la commande COPY pour copier le code de la fonction et les dépendances de l’environnement d’exécution dans `{LAMBDA_TASK_ROOT}`, une [variable d’environnement définie par Lambda](configuration-envvars.md#configuration-envvars-runtime).
+ Définir l’argument `CMD` pour le gestionnaire de la fonction Lambda.
Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
```
FROM public.ecr.aws/lambda/ruby:3.4
# Copy Gemfile and Gemfile.lock
COPY Gemfile Gemfile.lock ${LAMBDA_TASK_ROOT}/
# Install Bundler and the specified gems
RUN gem install bundler:2.4.20 && \
bundle config set --local path 'vendor/bundle' && \
bundle install
# Copy function code
COPY lambda_function.rb ${LAMBDA_TASK_ROOT}/
# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "lambda_function.LambdaFunction::Handler.process" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l'image localement
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Dans cet exemple, `docker-image` est le nom de l’image et `test` est la balise.
```
docker run --platform linux/amd64 -p 9000:8080 docker-image:test
```
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. À partir d’une nouvelle fenêtre de terminal, publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
## Utilisation d’une autre image de base avec le client d’interface d’exécution
Si vous utilisez une [image de base uniquement pour le système d’exploitation](images-create.md#runtimes-images-provided) ou une autre image de base, vous devez inclure le client d’interface d’exécution dans votre image. Le client d’interface d’exécution étend le[API de runtime](runtimes-api.md), qui gère l’interaction entre Lambda et votre code de fonction.
Installez le [client d'interface d'exécution Lambda pour Ruby à](https://rubygems.org/gems/aws_lambda_ric) l'aide du gestionnaire de packages RubyGems .org :
```
gem install aws_lambda_ric
```
Vous pouvez également télécharger le [client d'interface d'exécution Ruby](https://github.com/aws/aws-lambda-ruby-runtime-interface-client) depuis GitHub.
L'exemple suivant montre comment créer une image de conteneur pour Ruby à l'aide d'une image non AWS basique. L’exemple Dockerfile utilise une image de base Ruby officielle. Le Dockerfile inclut le client d’interface d’exécution.
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Ruby
### Création d’une image à partir d’une image de base alternative
**Pour créer une image de conteneur pour Ruby au moyen d’une autre image de base**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir example
cd example
```
1. Créez un nouveau fichier appelé `Gemfile`. C'est ici que vous listez les RubyGems packages requis pour votre application. Le AWS SDK pour Ruby est disponible auprès de RubyGems. Vous devez choisir des gemmes AWS de service spécifiques à installer. Par exemple, pour utiliser la [gem Ruby pour Lambda](https://rubygems.org/gems/aws-sdk-lambda/), votre Gemfile doit ressembler à ceci :
```
source 'https://rubygems.org'
gem 'aws-sdk-lambda'
```
Sinon, la gemme [aws-sdk](https://rubygems.org/gems/aws-sdk/) contient toutes les gemmes de service disponibles. AWS Cette gem est très large. Nous vous recommandons de ne l'utiliser que si vous dépendez de nombreux AWS services.
1. Installez les dépendances spécifiées dans le fichier Gemfile à l’aide de [l’installation groupée](https://bundler.io/v2.4/man/bundle-install.1.html).
```
bundle install
```
1. Créez un nouveau fichier appelé `lambda_function.rb`. Vous pouvez ajouter l’exemple de code de fonction suivant au fichier pour le tester, ou utiliser le vôtre.
**Example Fonction Ruby**
```
module LambdaFunction
class Handler
def self.process(event:,context:)
"Hello from Lambda!"
end
end
end
```
1. Créez un nouveau fichier Docker. Le Dockerfile suivant utilise une image de base Ruby au lieu d’une [image de base AWS](images-create.md#runtimes-images-lp). Le Dockerfile inclut le [client d’interface d’exécution pour Ruby](https://github.com/aws/aws-lambda-ruby-runtime-interface-client), ce qui rend l’image compatible avec Lambda. Vous pouvez également ajouter le client de l’interface d’exécution au Gemfile de votre application.
+ Définissez la propriété `FROM` sur l’image de base Ruby.
+ Créez un répertoire pour le code de fonction et une variable d’environnement pointant vers ce répertoire. Dans cet exemple, le répertoire est `/var/task`, qui reflète l’environnement d’exécution Lambda. Cependant, vous pouvez choisir n'importe quel répertoire pour le code de fonction car le Dockerfile n'utilise pas d'image de AWS base.
+ Définissez le `ENTRYPOINT` sur le module que vous souhaitez que le conteneur Docker exécute lorsqu’il démarre. Dans ce cas, le module est le client d’interface d’exécution.
+ Définir l’argument `CMD` pour le gestionnaire de la fonction Lambda.
Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
```
FROM ruby:2.7
# Install the runtime interface client for Ruby
RUN gem install aws_lambda_ric
# Add the runtime interface client to the PATH
ENV PATH="/usr/local/bundle/bin:${PATH}"
# Create a directory for the Lambda function
ENV LAMBDA_TASK_ROOT=/var/task
RUN mkdir -p ${LAMBDA_TASK_ROOT}
WORKDIR ${LAMBDA_TASK_ROOT}
# Copy Gemfile and Gemfile.lock
COPY Gemfile Gemfile.lock ${LAMBDA_TASK_ROOT}/
# Install Bundler and the specified gems
RUN gem install bundler:2.4.20 && \
bundle config set --local path 'vendor/bundle' && \
bundle install
# Copy function code
COPY lambda_function.rb ${LAMBDA_TASK_ROOT}/
# Set runtime interface client as default command for the container runtime
ENTRYPOINT [ "aws_lambda_ric" ]
# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "lambda_function.LambdaFunction::Handler.process" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l’image localement
Utilisez l’[émulateur d’interface d’exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/) pour tester l’image localement. Vous pouvez [intégrer l’émulateur dans votre image](https://github.com/aws/aws-lambda-runtime-interface-emulator/?tab=readme-ov-file#build-rie-into-your-base-image) ou utiliser la procédure suivante pour l’installer sur votre machine locale.
**Pour installer et exécuter l’émulateur d’interface d’exécution sur votre ordinateur local**
1. Depuis le répertoire de votre projet, exécutez la commande suivante pour télécharger l'émulateur d'interface d'exécution (architecture x86-64) GitHub et l'installer sur votre machine locale.
------
#### [ Linux/macOS ]
```
mkdir -p ~/.aws-lambda-rie && \
curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && \
chmod +x ~/.aws-lambda-rie/aws-lambda-rie
```
Pour installer l'émulateur arm64, remplacez l'URL du GitHub référentiel dans la commande précédente par la suivante :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
#### [ PowerShell ]
```
$dirPath = "$HOME\.aws-lambda-rie"
if (-not (Test-Path $dirPath)) {
New-Item -Path $dirPath -ItemType Directory
}
$downloadLink = "https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie"
$destinationPath = "$HOME\.aws-lambda-rie\aws-lambda-rie"
Invoke-WebRequest -Uri $downloadLink -OutFile $destinationPath
```
Pour installer l’émulateur arm64, remplacez `$downloadLink` par ce qui suit :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Notez ce qui suit :
+ `docker-image` est le nom de l’image et `test` est la balise.
+ `aws_lambda_ric lambda_function.LambdaFunction::Handler.process` est le `ENTRYPOINT` suivi du `CMD` depuis votre Dockerfile.
------
#### [ Linux/macOS ]
```
docker run --platform linux/amd64 -d -v ~/.aws-lambda-rie:/aws-lambda -p 9000:8080 \
--entrypoint /aws-lambda/aws-lambda-rie \
docker-image:test \
aws_lambda_ric lambda_function.LambdaFunction::Handler.process
```
------
#### [ PowerShell ]
```
docker run --platform linux/amd64 -d -v "$HOME\.aws-lambda-rie:/aws-lambda" -p 9000:8080 `
--entrypoint /aws-lambda/aws-lambda-rie `
docker-image:test `
aws_lambda_ric lambda_function.LambdaFunction::Handler.process
```
------
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. Publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
# Utilisation de couches pour les fonctions Lambda Ruby
Utilisez les [couches Lambda](chapter-layers.md) pour empaqueter le code et les dépendances que vous souhaitez réutiliser dans plusieurs fonctions. Les couches contiennent généralement des dépendances de bibliothèque, une [exécution personnalisée](runtimes-custom.md), ou des fichiers de configuration. La création d’une couche implique trois étapes générales :
1. Empaquetez le contenu de votre couche. Cela signifie créer une archive de fichiers .zip contenant les dépendances que vous souhaitez utiliser dans vos fonctions.
1. Créez la couche dans Lambda.
1. Ajoutez la couche à vos fonctions.
**Topics**
+ [
## Empaqueter le contenu de votre couche
](#ruby-layers-package)
+ [
## Créer la couche dans Lambda
](#publishing-layer)
+ [
## Utiliser des gems provenant de couches dans une fonction
](#ruby-layers-bundler-limitations)
+ [
## Ajouter la couche à votre fonction
](#ruby-layer-adding)
+ [
## Exemple d’application
](#ruby-layer-sample-app)
## Empaqueter le contenu de votre couche
Pour créer une couche, regroupez vos packages dans une archive (fichier .zip) répondant aux exigences suivantes :
+ Créez la couche à l’aide de la même version de Ruby que celle que vous prévoyez d’utiliser pour la fonction Lambda. Par exemple, si vous créez votre couche pour Ruby 3.4, utilisez l’environnement d'exécution Ruby 3.4 pour votre fonction.
+ Le fichier .zip de votre couche doit utiliser l’une des structures de répertoires suivantes :
+ `ruby/gems/x.x.x` (où *x.x.x* est votre version de Ruby, par exemple `3.4.0`)
+ `ruby/lib`
Pour de plus amples informations, consultez [Chemins d’accès de couche pour chaque exécution Lambda](packaging-layers.md#packaging-layers-paths).
+ Les packages de votre couche doivent être compatibles avec Linux. Les fonctions Lambda s’exécutent sur Amazon Linux.
Vous pouvez créer des couches contenant des gems Ruby tierces ou vos propres modules et classes Ruby. De nombreuses gems Ruby populaires contiennent des extensions natives (code C) qui doivent être compilées pour l’environnement Lambda Linux.
### Gems Ruby pures
Les gems Ruby pures contiennent uniquement du code Ruby et ne nécessitent pas de compilation. Ces gems sont plus simples à empaqueter et à utiliser sur différentes plateformes.
**Créer une couche à l’aide de gems Ruby pures**
1. Créez un `Gemfile` pour spécifier les gems Ruby pures que vous souhaitez inclure dans votre couche :
**Example Gemfile**
```
source 'https://rubygems.org'
gem 'tzinfo'
```
1. Installez les gems dans le répertoire `vendor/bundle` à l’aide de Bundler :
```
bundle config set --local path vendor/bundle
bundle install
```
1. Copiez les gems installées dans la structure de répertoires requise par Lambda (`ruby/gems/3.4.0`) :
```
mkdir -p ruby/gems/3.4.0
cp -r vendor/bundle/ruby/3.4.0*/* ruby/gems/3.4.0/
```
1. Compressez le contenu de la couche :
------
#### [ Linux/macOS ]
```
zip -r layer.zip ruby/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\ruby -DestinationPath .\layer.zip
```
------
La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
ruby/
└── gems/
└── 3.4.0/
├── gems/
│ ├── concurrent-ruby-1.3.5/
│ └── tzinfo-2.0.6/
├── specifications/
├── cache/
├── build_info/
└── (other bundler directories)
```
**Note**
Vous devez requérir chaque gem individuellement dans le code de votre fonction. Vous ne pouvez pas utiliser `bundler/setup` ou `Bundler.require`. Pour de plus amples informations, consultez [Utiliser des gems provenant de couches dans une fonction](#ruby-layers-bundler-limitations).
### Gems avec des extensions natives
De nombreuses gems Ruby populaires contiennent des extensions natives (code C) qui doivent être compilées pour la plateforme cible. Les gems populaires dotées d’extensions natives incluent [nokogiri](https://rubygems.org/gems/nokogiri/), [pg](https://rubygems.org/gems/pg/), [mysql2](https://rubygems.org/gems/mysql2/), [sqlite3](https://rubygems.org/gems/sqlite3/), and [ffi](https://rubygems.org/gems/ffi/). Ces gems doivent être créées dans un environnement Linux compatible avec l’environnement d'exécution Lambda.
**Créer une couche à l’aide de gems avec des extensions natives**
1. Créer un de `Gemfile`.
**Example Gemfile**
```
source 'https://rubygems.org'
gem 'nokogiri'
gem 'httparty'
```
1. Utilisez Docker pour créer les gems dans un environnement Linux compatible avec Lambda. Spécifiez une [image de base AWS](ruby-image.md#ruby-image-base) dans votre Dockerfile :
**Example Dockerfile pour Ruby 3.4**
```
FROM public.ecr.aws/lambda/ruby:3.4
# Copy Gemfile
COPY Gemfile ./
# Install system dependencies for native extensions
RUN dnf update -y && \
dnf install -y gcc gcc-c++ make
# Configure bundler and install gems
RUN bundle config set --local path vendor/bundle && \
bundle install
# Create the layer structure
RUN mkdir -p ruby/gems/3.4.0 && \
cp -r vendor/bundle/ruby/3.4.0*/* ruby/gems/3.4.0/
# Create the layer zip file
RUN zip -r layer.zip ruby/
```
1. Créez l’image et extrayez la couche :
```
docker build -t ruby-layer-builder .
docker run --rm -v $(pwd):/output --entrypoint cp ruby-layer-builder layer.zip /output/
```
Cela crée les gems dans l’environnement Linux approprié et copie le fichier `layer.zip` dans votre répertoire local. La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
ruby/
└── gems/
└── 3.4.0/
├── gems/
│ ├── bigdecimal-3.2.2/
│ ├── csv-3.3.5/
│ ├── httparty-0.23.1/
│ ├── mini_mime-1.1.5/
│ ├── multi_xml-0.7.2/
│ ├── nokogiri-1.18.8-x86_64-linux-gnu/
│ └── racc-1.8.1/
├── build_info/
├── cache/
├── specifications/
└── (other bundler directories)
```
**Note**
Vous devez requérir chaque gem individuellement dans le code de votre fonction. Vous ne pouvez pas utiliser `bundler/setup` ou `Bundler.require`. Pour de plus amples informations, consultez [Utiliser des gems provenant de couches dans une fonction](#ruby-layers-bundler-limitations).
### Modules Ruby personnalisés
**Créer une couche à l’aide de votre propre code**
1. Créez la structure de répertoires requise pour votre couche :
```
mkdir -p ruby/lib
```
1. Créez vos modules Ruby dans le répertoire `ruby/lib`. L’exemple de module suivant valide les commandes en confirmant qu’elles contiennent les informations requises.
**Example ruby/lib/order\$1validator.rb**
```
require 'json'
module OrderValidator
class ValidationError < StandardError; end
def self.validate_order(order_data)
# Validates an order and returns formatted data
required_fields = %w[product_id quantity]
# Check required fields
missing_fields = required_fields.reject { |field| order_data.key?(field) }
unless missing_fields.empty?
raise ValidationError, "Missing required fields: #{missing_fields.join(', ')}"
end
# Validate quantity
quantity = order_data['quantity']
unless quantity.is_a?(Integer) && quantity > 0
raise ValidationError, 'Quantity must be a positive integer'
end
# Format and return the validated data
{
'product_id' => order_data['product_id'].to_s,
'quantity' => quantity,
'shipping_priority' => order_data.fetch('priority', 'standard')
}
end
def self.format_response(status_code, body)
# Formats the API response
{
statusCode: status_code,
body: JSON.generate(body)
}
end
end
```
1. Compressez le contenu de la couche :
------
#### [ Linux/macOS ]
```
zip -r layer.zip ruby/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\ruby -DestinationPath .\layer.zip
```
------
La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
ruby/
└── lib/
└── order_validator.rb
```
1. Dans votre fonction, exigez (require) et utilisez les modules. Vous devez requérir chaque gem individuellement dans le code de votre fonction. Vous ne pouvez pas utiliser `bundler/setup` ou `Bundler.require`. Pour de plus amples informations, consultez [Utiliser des gems provenant de couches dans une fonction](#ruby-layers-bundler-limitations). Exemple :
```
require 'json'
require 'order_validator'
def lambda_handler(event:, context:)
begin
# Parse the order data from the event body
order_data = JSON.parse(event['body'] || '{}')
# Validate and format the order
validated_order = OrderValidator.validate_order(order_data)
OrderValidator.format_response(200, {
message: 'Order validated successfully',
order: validated_order
})
rescue OrderValidator::ValidationError => e
OrderValidator.format_response(400, {
error: e.message
})
rescue => e
OrderValidator.format_response(500, {
error: 'Internal server error'
})
end
end
```
Vous pouvez utiliser l’[événement de test](testing-functions.md#invoke-with-event) suivant afin d’invoquer la fonction :
```
{
"body": "{\"product_id\": \"ABC123\", \"quantity\": 2, \"priority\": \"express\"}"
}
```
Réponse attendue :
```
{
"statusCode": 200,
"body": "{\"message\":\"Order validated successfully\",\"order\":{\"product_id\":\"ABC123\",\"quantity\":2,\"shipping_priority\":\"express\"}}"
}
```
## Créer la couche dans Lambda
Vous pouvez publier votre couche en utilisant AWS CLI ou la console Lambda.
------
#### [ AWS CLI ]
Exécutez la commande AWS CLI [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html) pour créer la couche Lambda :
```
aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes ruby3.4
```
Le paramètre [compatible runtimes](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) est facultatif. Lorsqu’il est spécifié, Lambda utilise ce paramètre pour filtrer les couches dans la console Lambda.
------
#### [ Console ]
**Pour créer une couche (console)**
1. Ouvrez la [page Couches](https://console.aws.amazon.com/lambda/home#/layers) de la console Lambda.
1. Sélectionnez **Créer un calque**.
1. Choisissez **Charger un fichier .zip**, puis chargez l’archive .zip que vous avez créée précédemment.
1. (Facultatif) Pour **Environnements d’exécution compatibles**, choisissez l’environnement d’exécution Ruby qui correspond à la version de Ruby que vous avez utilisée pour créer votre couche.
1. Choisissez **Créer**.
------
## Utiliser des gems provenant de couches dans une fonction
Dans le code de votre fonction, vous devez explicitement exiger chaque gem que vous souhaitez utiliser. Les commandes Bundler comme `bundler/setup` et `Bundler.require` ne sont pas prises en charge. Voici comment utiliser correctement les gems d’une couche dans une fonction Lambda :
```
# Correct: Use explicit requires for each gem
require 'nokogiri'
require 'httparty'
def lambda_handler(event:, context:)
# Use the gems directly
doc = Nokogiri::HTML(event['html'])
response = HTTParty.get(event['url'])
# ... rest of your function
end
# Incorrect: These Bundler commands will not work
# require 'bundler/setup'
# Bundler.require
```
## Ajouter la couche à votre fonction
------
#### [ AWS CLI ]
Pour associer la couche à votre fonction, exécutez la commande AWS CLI [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Utilisez l’ARN de la couche pour le paramètre `--layers`. L’ARN doit spécifier la version (par exemple, `arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1`). Pour de plus amples informations, consultez [Couches et versions de couches](chapter-layers.md#lambda-layer-versions).
```
aws lambda update-function-configuration --function-name my-function --cli-binary-format raw-in-base64-out --layers "arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1"
```
L’option **cli-binary-format** est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
------
#### [ Console ]
**Ajouter une couche à une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la fonction.
1. Faites défiler jusqu’à la section **Couches**, puis choisissez **Ajouter une couche**.
1. Sous **Choisir une couche**, sélectionnez **Couches personnalisées**, puis choisissez votre couche.
**Note**
Si vous n’avez pas ajouté d’[environnement d’exécution compatible](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) lors de la création de la couche, celle-ci ne sera pas répertoriée ici. Vous pouvez spécifier l’ARN de la couche à la place.
1. Choisissez **Ajouter**.
------
## Exemple d’application
Pour d’autres exemples d’utilisation des couches Lambda, consultez l’exemple d’application [layer-ruby](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/layer-ruby) dans le référentiel GitHub du Guide du développeur AWS Lambda. Cette application inclut une couche qui contient la bibliothèque [tzinfo](https://rubygems.org/gems/tzinfo). Après avoir créé la couche, vous pouvez déployer et invoquer la fonction correspondante pour confirmer que la couche fonctionne comme prévu.
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Ruby
Lorsque Lambda exécute votre fonction, il transmet un objet contexte au [gestionnaire](ruby-handler.md). Cet objet fournit des méthodes et des propriétés fournissant des informations sur l’invocation, la fonction et l’environnement d’exécution.
**Méthodes de contexte**
+ `get_remaining_time_in_millis` – Renvoie le nombre de millisecondes restant avant l’expiration de l’exécution.
**Propriétés du contexte**
+ `function_name` – Nom de la fonction Lambda.
+ `function_version` – [Version](configuration-versions.md) de la fonction.
+ `invoked_function_arn` – Amazon Resource Name (ARN) utilisé pour appeler la fonction. Indique si l’appelant a spécifié un numéro de version ou un alias.
+ `memory_limit_in_mb` – Quantité de mémoire allouée à la fonction.
+ `aws_request_id` – Identifiant de la demande d’invocation.
+ `log_group_name` – Groupe de journaux pour la fonction.
+ `log_stream_name` – Flux de journal de l’instance de fonction.
+ `deadline_ms` – Date d’expiration de l’exécution, exprimée en millisecondes au format horaire Unix.
+ `identity` – (applications mobiles) Informations sur l’identité Amazon Cognito qui a autorisé la demande.
+ `client_context` – (applications mobiles) Contexte client fourni à Lambda par l’application client.
# Journalisation et surveillance des fonctions Lambda Ruby
AWS Lambda surveille automatiquement les fonctions Lambda en votre nom et envoie les journaux à Amazon. CloudWatch Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs et un flux de journaux pour chaque instance de votre fonction. L’environnement d’exécution Lambda envoie des informations sur chaque invocation au flux de journaux et transmet les journaux et autres sorties provenant du code de votre fonction. Pour de plus amples informations, veuillez consulter [Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md).
Cette page explique comment générer une sortie de journal à partir du code de votre fonction Lambda et comment accéder aux journaux à l'aide de la AWS Command Line Interface console Lambda ou de la console. CloudWatch
**Topics**
+ [
## Création d’une fonction qui renvoie des journaux
](#ruby-logging-output)
+ [
## Affichage des journaux dans la console Lambda
](#ruby-logging-console)
+ [
## Afficher les journaux dans la CloudWatch console
](#ruby-logging-cwconsole)
+ [
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
](#ruby-logging-cli)
+ [
## Suppression de journaux
](#ruby-logging-delete)
+ [
## Utilisation de la bibliothèque Ruby logger
](#ruby-logging-lib)
## Création d’une fonction qui renvoie des journaux
Pour générer les journaux à partir de votre code de fonction, vous pouvez utiliser des déclarations `puts` ou n’importe quelle bibliothèque de journalisation qui écrit dans `stdout` ou `stderr`. L’exemple suivant consigne les valeurs des variables d’environnement et l’objet d’événement.
**Example lambda\$1function.rb**
```
# lambda_function.rb
def handler(event:, context:)
puts "## ENVIRONMENT VARIABLES"
puts ENV.to_a
puts "## EVENT"
puts event.to_a
end
```
**Example format des journaux**
```
START RequestId: 8f507cfc-xmpl-4697-b07a-ac58fc914c95 Version: $LATEST
## ENVIRONMENT VARIABLES
environ({'AWS_LAMBDA_LOG_GROUP_NAME': '/aws/lambda/my-function', 'AWS_LAMBDA_LOG_STREAM_NAME': '2020/01/31/[$LATEST]3893xmpl7fac4485b47bb75b671a283c', 'AWS_LAMBDA_FUNCTION_NAME': 'my-function', ...})
## EVENT
{'key': 'value'}
END RequestId: 8f507cfc-xmpl-4697-b07a-ac58fc914c95
REPORT RequestId: 8f507cfc-xmpl-4697-b07a-ac58fc914c95 Duration: 15.74 ms Billed Duration: 147 ms Memory Size: 128 MB Max Memory Used: 56 MB Init Duration: 130.49 ms
XRAY TraceId: 1-5e34a614-10bdxmplf1fb44f07bc535a1 SegmentId: 07f5xmpl2d1f6f85 Sampled: true
```
L’exécution Ruby enregistre les lignes `START`, `END` et `REPORT` pour chaque invocation. La ligne de rapport fournit les détails suivants.
**Champs de données de la ligne REPORT**
+ **RequestId**— L'identifiant de demande unique pour l'invocation.
+ **Duration** – Temps que la méthode de gestion du gestionnaire de votre fonction a consacré au traitement de l’événement.
+ **Billed Duration** : temps facturé pour l’invocation.
+ **Memory Size** – Quantité de mémoire allouée à la fonction.
+ **Max Memory Used** – Quantité de mémoire utilisée par la fonction. Lorsque les appels partagent un environnement d’exécution, Lambda indique la mémoire maximale utilisée pour toutes les invocations. Ce comportement peut entraîner une valeur signalée plus élevée que prévu.
+ **Init Duration** : pour la première requête servie, temps qu’il a pris à l’exécution charger la fonction et exécuter le code en dehors de la méthode du gestionnaire.
+ **XRAY TraceId** — Pour les demandes suivies, l'[ID de AWS X-Ray trace.](services-xray.md)
+ **SegmentId**— Pour les demandes tracées, l'identifiant du segment X-Ray.
+ **Sampled** : pour les demandes suivies, résultat de l’échantillonnage.
Pour obtenir des journaux plus détaillés, utilisez la bibliothèque [Utilisation de la bibliothèque Ruby logger](#ruby-logging-lib).
## Affichage des journaux dans la console Lambda
Vous pouvez utiliser la console Lambda pour afficher la sortie du journal après avoir invoqué une fonction Lambda.
Si votre code peut être testé à partir de l’éditeur **Code** intégré, vous trouverez les journaux dans les **résultats d’exécution**. Lorsque vous utilisez la fonctionnalité de test de console pour invoquer une fonction, vous trouverez **Sortie du journal** dans la section **Détails**.
## Afficher les journaux dans la CloudWatch console
Vous pouvez utiliser la CloudWatch console Amazon pour consulter les journaux de toutes les invocations de fonctions Lambda.
**Pour afficher les journaux sur la CloudWatch console**
1. Ouvrez la [page Groupes de journaux](https://console.aws.amazon.com/cloudwatch/home?#logs:) sur la CloudWatch console.
1. Choisissez le groupe de journaux pour votre fonction (***your-function-name*/aws/lambda/**).
1. Choisissez un flux de journaux.
Chaque flux de journal correspond à une [instance de votre fonction](lambda-runtime-environment.md). Un flux de journal apparaît lorsque vous mettez à jour votre fonction Lambda et lorsque des instances supplémentaires sont créées pour gérer les appels simultanés. Pour trouver les journaux d'un appel spécifique, nous vous recommandons d'instrumenter votre fonction avec. AWS X-Ray X-Ray enregistre des détails sur la demande et le flux de journaux dans le suivi.
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
AWS CLI Il s'agit d'un outil open source qui vous permet d'interagir avec les AWS services à l'aide de commandes dans votre interface de ligne de commande. Pour effectuer les étapes de cette section, vous devez disposer de la [version 2 de l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
Vous pouvez utiliser [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) pour récupérer les journaux d’une invocation à l’aide de l’option de commande `--log-type`. La réponse inclut un champ `LogResult` qui contient jusqu’à 4 Ko de journaux codés en base64 provenant de l’invocation.
**Example récupérer un ID de journal**
L’exemple suivant montre comment récupérer un *ID de journal* à partir du champ `LogResult` d’une fonction nommée `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example décoder les journaux**
Dans la même invite de commandes, utilisez l’utilitaire `base64` pour décoder les journaux. L’exemple suivant montre comment récupérer les journaux encodés en base64 pour `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez voir la sortie suivante :
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
L’utilitaire `base64` est disponible sous Linux, macOS et [Ubuntu sous Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Les utilisateurs de macOS auront peut-être besoin d’utiliser `base64 -D`.
**Example Script get-logs.sh**
Dans la même invite de commandes, utilisez le script suivant pour télécharger les cinq derniers événements de journalisation. Le script utilise `sed` pour supprimer les guillemets du fichier de sortie et attend 15 secondes pour permettre la mise à disposition des journaux. La sortie comprend la réponse de Lambda, ainsi que la sortie de la commande `get-log-events`.
Copiez le contenu de l’exemple de code suivant et enregistrez-le dans votre répertoire de projet Lambda sous `get-logs.sh`.
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS et Linux (uniquement)**
Dans la même invite de commandes, les utilisateurs macOS et Linux peuvent avoir besoin d’exécuter la commande suivante pour s’assurer que le script est exécutable.
```
chmod -R 755 get-logs.sh
```
**Example récupérer les cinq derniers événements de journal**
Dans la même invite de commande, exécutez le script suivant pour obtenir les cinq derniers événements de journalisation.
```
./get-logs.sh
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Suppression de journaux
Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker des journaux indéfiniment, supprimez le groupe de journaux ou [configurez une période de conservation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) à l’issue de laquelle les journaux sont supprimés automatiquement.
## Utilisation de la bibliothèque Ruby logger
La [bibliothèque Ruby logger](https://ruby-doc.org/stdlib-2.7.0/libdoc/logger/rdoc/index.html) renvoie des journaux simplifiés, faciles à lire. Utilisez l’utilitaire logger pour obtenir des informations détaillées, des messages et des codes d’erreur relatifs à votre fonction.
```
# lambda_function.rb
require 'logger'
def handler(event:, context:)
logger = Logger.new($stdout)
logger.info('## ENVIRONMENT VARIABLES')
logger.info(ENV.to_a)
logger.info('## EVENT')
logger.info(event)
event.to_a
end
```
La sortie de `logger` inclut le niveau de journal, l’horodatage et l’ID de demande.
```
START RequestId: 1c8df7d3-xmpl-46da-9778-518e6eca8125 Version: $LATEST
[INFO] 2020-01-31T22:12:58.534Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 ## ENVIRONMENT VARIABLES
[INFO] 2020-01-31T22:12:58.534Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 environ({'AWS_LAMBDA_LOG_GROUP_NAME': '/aws/lambda/my-function', 'AWS_LAMBDA_LOG_STREAM_NAME': '2020/01/31/[$LATEST]1bbe51xmplb34a2788dbaa7433b0aa4d', 'AWS_LAMBDA_FUNCTION_NAME': 'my-function', ...})
[INFO] 2020-01-31T22:12:58.535Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 ## EVENT
[INFO] 2020-01-31T22:12:58.535Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 {'key': 'value'}
END RequestId: 1c8df7d3-xmpl-46da-9778-518e6eca8125
REPORT RequestId: 1c8df7d3-xmpl-46da-9778-518e6eca8125 Duration: 2.75 ms Billed Duration: 117 ms Memory Size: 128 MB Max Memory Used: 56 MB Init Duration: 113.51 ms
XRAY TraceId: 1-5e34a66a-474xmpl7c2534a87870b4370 SegmentId: 073cxmpl3e442861 Sampled: true
```
# Instrumentation du code Ruby dans AWS Lambda
Lambda s'intègre AWS X-Ray pour vous permettre de suivre, de déboguer et d'optimiser les applications Lambda. Vous pouvez utiliser X-Ray pour suivre une demande lorsqu’elle qu’elle parcourt les ressources de votre application, de l’API frontale au stockage et à la base de données sur le backend. En ajoutant simplement la bibliothèque du SDK X-Ray à votre configuration de build, vous pouvez enregistrer les erreurs et le temps de latence pour chaque appel que votre fonction fait à un AWS service.
Une fois que vous avez configuré le suivi actif, vous pouvez observer des demandes spécifiques via votre application. Le [ graphique de services X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html#xray-concepts-servicegraph) affiche des informations sur votre application et tous ses composants. L’exemple suivant montre une application dotée de deux fonctions. La fonction principale traite les événements et renvoie parfois des erreurs. La deuxième fonction située en haut traite les erreurs qui apparaissent dans le groupe de journaux de la première et utilise le AWS SDK pour appeler X-Ray, Amazon Simple Storage Service (Amazon S3) et Amazon Logs. CloudWatch
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sample-errorprocessor-servicemap.png)
Pour activer/désactiver le traçage actif sur votre fonction Lambda avec la console, procédez comme suit :
**Pour activer le traçage actif**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez **Configuration**, puis choisissez **Outils de surveillance et d’opérations**.
1. Dans **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **Signaux CloudWatch d'application et AWS X-Ray** sélectionnez **Activer les traces** de **service Lambda**.
1. Choisissez **Enregistrer**.
**Tarification**
Vous pouvez utiliser le X-Ray Tracing gratuitement chaque mois jusqu'à une certaine limite dans le cadre du niveau AWS gratuit. Au-delà de ce seuil, X-Ray facture le stockage et la récupération du suivi. Pour en savoir plus, consultez [Pricing AWS X-Ray](https://aws.amazon.com/xray/pricing/) (Tarification).
Votre fonction a besoin d’une autorisation pour charger des données de suivi vers X-Ray. Lorsque vous activez le suivi actif dans la console Lambda, Lambda ajoute les autorisations requises au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Dans le cas contraire, ajoutez la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)politique au rôle d'exécution.
X-Ray ne trace pas toutes les requêtes vers votre application. X-Ray applique un algorithme d’échantillonnage pour s’assurer que le suivi est efficace, tout en fournissant un échantillon représentatif de toutes les demandes. Le taux d’échantillonnage est 1 demande par seconde et 5 % de demandes supplémentaires. Vous ne pouvez pas configurer ce taux d’échantillonnage X-Ray pour vos fonctions.
Dans X-Ray, un *suivi* enregistre des informations sur une demande traitée par un ou plusieurs *services*. Lambda enregistre deux segments par suivi, ce qui a pour effet de créer deux nœuds sur le graphique du service. L’image suivante met en évidence ces deux nœuds :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/xray-servicemap-function.png)
Le premier nœud sur la gauche représente le service Lambda qui reçoit la demande d’invocation. Le deuxième nœud représente votre fonction Lambda spécifique. L’exemple suivant illustre une trace avec ces deux segments. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Cet exemple développe le segment `AWS::Lambda::Function` pour afficher ses trois sous-segments.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
L’exemple de suivi présenté ici illustre le segment de fonction à l’ancienne. Les différences entre les segments à l’ancienne et de style moderne sont décrites dans les paragraphes suivants.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
Le segment de fonction à l’ancienne contient les sous-segments suivants :
+ **Initialization (Initialisation)** : représente le temps passé à charger votre fonction et à exécuter le [code d’initialisation](foundation-progmodel.md). Ce sous-segment apparaît pour le premier événement traité par chaque instance de votre fonction.
+ **Invocation** – Représente le temps passé à exécuter votre code de gestionnaire.
+ **Overhead (Travail supplémentaire)** – Représente le temps que le fichier d’exécution Lambda passe à se préparer à gérer l’événement suivant.
Le segment de fonction de style moderne ne contient pas de sous-segment `Invocation`. À la place, les sous-segments du client sont directement rattachés au segment de fonction. Pour plus d’informations sur la structure des segments de fonction à l’ancienne et de style moderne, consultez [Comprendre les suivis X-Ray](services-xray.md#services-xray-traces).
Vous pouvez instrumenter le code de gestionnaire pour enregistrer les métadonnées et suivre les appels en aval. Pour enregistrer des détails sur les appels que le gestionnaire effectue vers d’autres ressources et services, utilisez le kit SDK X-Ray pour Ruby. Pour obtenir ce kit SDK, ajoutez le package `aws-xray-sdk` aux dépendances de votre application.
**Example [blanc- ruby/function/Gemfile](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-ruby/function/Gemfile)**
```
# Gemfile
source 'https://rubygems.org'
gem 'aws-xray-sdk', '0.11.4'
gem 'aws-sdk-lambda', '1.39.0'
gem 'test-unit', '3.3.5'
```
Pour instrumenter les clients du AWS SDK, vous devez avoir besoin du `aws-xray-sdk/lambda` module après avoir créé un client dans le code d'initialisation.
**Example [blank- ruby/function/lambda \$1function.rb](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-ruby/function/lambda_function.rb) — Suivi d'un client SDK AWS**
```
# lambda_function.rb
require 'logger'
require 'json'
require 'aws-sdk-lambda'
$client = Aws::Lambda::Client.new()
$client.get_account_settings()
require 'aws-xray-sdk/lambda'
def lambda_handler(event:, context:)
logger = Logger.new($stdout)
...
```
Dans X-Ray, un *suivi* enregistre des informations sur une demande traitée par un ou plusieurs *services*. Lambda enregistre deux segments par suivi, ce qui a pour effet de créer deux nœuds sur le graphique du service. L’image suivante met en évidence ces deux nœuds :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/xray-servicemap-function.png)
Le premier nœud sur la gauche représente le service Lambda qui reçoit la demande d’invocation. Le deuxième nœud représente votre fonction Lambda spécifique. L’exemple suivant illustre une trace avec ces deux segments. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Cet exemple développe le segment `AWS::Lambda::Function` pour afficher ses trois sous-segments.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
L’exemple de suivi présenté ici illustre le segment de fonction à l’ancienne. Les différences entre les segments à l’ancienne et de style moderne sont décrites dans les paragraphes suivants.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
Le segment de fonction à l’ancienne contient les sous-segments suivants :
+ **Initialization (Initialisation)** : représente le temps passé à charger votre fonction et à exécuter le [code d’initialisation](foundation-progmodel.md). Ce sous-segment apparaît pour le premier événement traité par chaque instance de votre fonction.
+ **Invocation** – Représente le temps passé à exécuter votre code de gestionnaire.
+ **Overhead (Travail supplémentaire)** – Représente le temps que le fichier d’exécution Lambda passe à se préparer à gérer l’événement suivant.
Le segment de fonction de style moderne ne contient pas de sous-segment `Invocation`. À la place, les sous-segments du client sont directement rattachés au segment de fonction. Pour plus d’informations sur la structure des segments de fonction à l’ancienne et de style moderne, consultez [Comprendre les suivis X-Ray](services-xray.md#services-xray-traces).
Vous pouvez également utiliser des clients HTTP, enregistrer des requêtes SQL et créer des sous-segments personnalisés avec des annotations et des métadonnées. Pour plus d'informations, consultez [The X-Ray SDK for](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-ruby.html) Ruby dans AWS X-Ray le manuel du développeur.
**Topics**
+ [
## Activation du suivi actif avec l’API Lambda
](#ruby-tracing-api)
+ [
## Activation du suivi actif avec CloudFormation
](#ruby-tracing-cloudformation)
+ [
## Stockage des dépendances d’exécution dans une couche
](#ruby-tracing-layers)
## Activation du suivi actif avec l’API Lambda
Pour gérer la configuration du suivi avec le AWS SDK AWS CLI ou le SDK, utilisez les opérations d'API suivantes :
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
L'exemple de AWS CLI commande suivant active le suivi actif sur une fonction nommée **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
Le mode de suivi fait partie de la configuration spécifique de la version lorsque vous publiez une version de votre fonction. Vous ne pouvez pas modifier le mode de suivi sur une version publiée.
## Activation du suivi actif avec CloudFormation
Pour activer le suivi d'une `AWS::Lambda::Function` ressource dans un CloudFormation modèle, utilisez la `TracingConfig` propriété.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Pour une `AWS::Serverless::Function` ressource AWS Serverless Application Model (AWS SAM), utilisez la `Tracing` propriété.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
## Stockage des dépendances d’exécution dans une couche
Si vous utilisez le SDK X-Ray pour instrumenter le code de fonction des clients du AWS SDK, votre package de déploiement peut devenir très volumineux. Pour éviter de charger des dépendances d’environnement d’exécution chaque fois que vous mettez à jour votre code de fonction, empaquetez le kit SDK X-Ray dans une [couche Lambda](chapter-layers.md).
L’exemple suivant montre une ressource `AWS::Serverless::LayerVersion` qui stocke le kit SDK X-Ray pour Ruby.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-ruby/template.yml) : couche de dépendances**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
CodeUri: function/.
Tracing: Active
Layers:
- !Ref libs
...
libs:
Type: [AWS::Serverless::LayerVersion](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-layerversion.html)
Properties:
LayerName: blank-ruby-lib
Description: Dependencies for the blank-ruby sample app.
ContentUri: lib/.
CompatibleRuntimes:
- ruby2.5
```
Avec cette configuration, vous ne mettez à jour les fichiers de couche de bibliothèque que si vous modifiez vos dépendances d’exécution. Étant donné que le package de déploiement de la fonction contient uniquement votre code, cela peut contribuer à réduire les temps de chargement.
La création d’une couche de dépendances nécessite des modifications de génération pour créer l’archive des couches avant le déploiement. Pour un exemple fonctionnel, consultez l’exemple d’application [blank-ruby](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-ruby).