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 d’une fonction Lambda à l’aide d’une image de conteneur
Le code de votre AWS Lambda fonction se compose de scripts ou de programmes compilés et de leurs dépendances. Pour déployer votre code de fonction vers Lambda, vous utilisez un *package de déploiement*. Lambda prend en charge deux types de packages de déploiement : les images conteneurs et les archives de fichiers .zip.
Il existe trois méthodes pour créer une image de conteneur pour une fonction Lambda :
+ [Utilisation d'une image AWS de base pour Lambda](#runtimes-images-lp)
Les [images de base AWS](#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](#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 un [client d’interface d’exécution](#images-ric) pour votre langage dans l’image.
+ [Utilisation d'une image non AWS basique](#images-types)
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 un [client d’interface d’exécution](#images-ric) pour votre langage 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).
Pour créer une fonction Lambda à partir d’une image de conteneur, créez votre image localement et chargez-la dans un référentiel Amazon Elastic Container Registry (Amazon ECR). Si vous utilisez une image de conteneur fournie par un vendeur [AWS Marketplace](https://docs.aws.amazon.com/marketplace/latest/userguide/container-based-products.html), vous devez d’abord cloner l’image dans votre référentiel Amazon ECR privé. Indiquez ensuite l’URI du référentiel lorsque vous créez la fonction. Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda. 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](#configuration-images-xaccount-permissions).
**Note**
Lambda ne prend pas en charge les points de terminaison Amazon ECR FIPS pour les images de conteneurs. Si l’URI de votre dépôt contient `ecr-fips`, vous utilisez un point de terminaison FIPS. Exemple: `111122223333.dkr.ecr-fips.us-east-1.amazonaws.com`.
Cette page explique les types d’images de base et les exigences requises pour créer des images de conteneur compatibles avec Lambda.
**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.
**Topics**
+ [Exigences](#images-reqs)
+ [Utilisation d'une image AWS de base pour Lambda](#runtimes-images-lp)
+ [Utilisation d'une image de base AWS uniquement pour le système d'exploitation](#runtimes-images-provided)
+ [Utilisation d'une image non AWS basique](#images-types)
+ [Clients d’interface d’exécution](#images-ric)
+ [Autorisations Amazon ECR](#gettingstarted-images-permissions)
+ [Cycle de vie des fonctions](#images-lifecycle)
## Exigences
Installez l’[AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et la [CLI Docker](https://docs.docker.com/get-docker). En outre, notez les exigences suivantes :
+ L’image de conteneur doit implémenter l’[Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés](runtimes-api.md). Les [clients d’interface de runtime](#images-ric) open source AWS implémentent l’API. Vous pouvez ajouter un client d’interface de runtime à votre image de base préférée pour la rendre compatible avec Lambda.
+ L’image de conteneur doit pouvoir s’exécuter sur un système de fichiers en lecture seule. Votre code de fonction peut accéder à un répertoire `/tmp` inscriptible entre 512 Mo et 10 240 Mo de stockage, par incréments de 1 Mo.
+ L’utilisateur Lambda par défaut doit pouvoir lire tous les fichiers requis pour exécuter votre code de fonction. Lambda suit les bonnes pratiques de sécurité en définissant un utilisateur Linux par défaut avec des autorisations assortie d’un privilège minimum. Cela signifie que vous n’avez pas besoin de spécifier un [UTILISATEUR](https://docs.docker.com/reference/dockerfile/#user) dans votre Dockerfile. Vérifiez que votre code d’application ne repose pas sur des fichiers dont l’exécution n’est pas autorisée à d’autres utilisateurs Linux.
+ Lambda prend uniquement en charge les images de conteneur basées sur Linux.
+ Lambda fournit des images de base multi-architecture. Toutefois, l’image que vous créez pour la fonction ne doit avoir que l’une des architectures pour cible. Lambda ne prend pas en charge les fonctions qui utilisent les images de conteneur multi-architecture.
## Utilisation d'une image AWS de base pour Lambda
Vous pouvez utiliser l’une des [images de base AWS](https://gallery.ecr.aws/lambda/) pour Lambda afin de créer l’image de conteneur pour votre code de fonction. Les images de base sont préchargées avec une exécution de langage et d’autres composants requis pour exécuter une image conteneur sur Lambda. Vous ajoutez votre code de fonction et vos dépendances à l’image de base, puis vous l’empaquetez en tant qu’image de conteneur.
AWS fournit régulièrement des mises à jour des images AWS de base pour Lambda. Si votre Dockerfile inclut le nom de l’image dans la propriété FROM, votre client Docker extrait la dernière version de l’image du [référentiel Amazon ECR](https://gallery.ecr.aws/lambda/). Afin d’utiliser l’image de base mise à jour, vous devez reconstruire votre image de conteneur et [mettre à jour le code de la fonction](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html).
Les images de base de Node.js 20, Python 3.12, Java 21, .NET 8, Ruby 3.3 et versions ultérieures sont basées sur l’[image de conteneur minimale Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html). Les images de base antérieures utilisaient Amazon Linux 2. AL2023 offre plusieurs avantages par rapport à Amazon Linux 2, notamment un encombrement de déploiement réduit et des versions mises à jour de bibliothèques telles que`glibc`.
AL2023les images basées sur un lien symbolique sont utilisées `microdnf` comme gestionnaire de packages au lieu de`yum`, qui est le gestionnaire de packages par défaut dans Amazon Linux 2. `dnf` `microdnf`est une implémentation autonome de. `dnf` Pour obtenir la liste des packages inclus dans les images AL2023 basées, reportez-vous aux colonnes **Conteneur minimal** de la section [Comparaison des packages installés sur les images de conteneur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.html). Pour plus d'informations sur les différences entre Amazon Linux 2 AL2023 et Amazon, consultez [la section Présentation du runtime Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sur le blog AWS Compute.
**Note**
Pour exécuter des images AL2023 basées localement, y compris avec AWS Serverless Application Model (AWS SAM), vous devez utiliser Docker version 20.10.10 ou ultérieure.
Pour créer une image de conteneur à l'aide d'une image de AWS base, choisissez les instructions correspondant à votre langue préférée :
+ [Node.js](nodejs-image.md#nodejs-image-instructions)
+ [TypeScript](typescript-image.md#base-image-typescript)(utilise une image de base Node.js)
+ [Python](python-image.md#python-image-instructions)
+ [Java](java-image.md#java-image-instructions)
+ [Go](go-image.md#go-image-provided)
+ [.NET](csharp-image.md#csharp-image-instructions)
+ [Ruby](ruby-image.md#ruby-image-instructions)
## Utilisation d'une image de base AWS uniquement pour le système d'exploitation
[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 un [client d’interface d’exécution](#images-ric) pour votre langage dans l’image.
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| al2023 | Exécution uniquement basée sur le système d'exploitation | Amazon Linux 2023 | [Dockerfile pour OS uniquement Runtime sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2023/Dockerfile.provided.al2023) | 30 juin 2029 |
| al2 | Exécution uniquement basée sur le système d'exploitation | Amazon Linux 2 | [Dockerfile pour OS uniquement Runtime sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2/Dockerfile.provided.al2) | 31 juillet 2026 |
Galerie publique d'Amazon Elastic Container Registry : [gallery.ecr. aws/lambda/provided](https://gallery.ecr.aws/lambda/provided)
## Utilisation d'une image non AWS basique
Lambda prend en charge toute image conforme à l’un des formats de manifeste d’image suivants :
+ Manifeste d’images Docker V2, schéma 2 (utilisé avec la version 1.10 de Docker et les versions les plus récentes)
+ Spécifications OCI (Open Container initiative, soit initiative de conteneur ouvert) (v1.0.0 et versions ultérieures)
Lambda prend en charge une taille maximale d’image non compressée de 10 Go, comprenant toutes les couches.
**Note**
Pour rendre l’image compatible avec Lambda, vous devez inclure un [client d’interface d’exécution](#images-ric) pour votre langage dans l’image.
Pour des performances optimales, maintenez la taille de votre manifeste d’image inférieure à 25 400 octets. Pour réduire la taille du manifeste d’image, réduisez le nombre de couches de votre image et réduisez le nombre d’annotations.
## Clients d’interface d’exécution
Si vous utilisez une [image de base uniquement pour le système d’exploitation](#runtimes-images-provided) ou une autre image de base, vous devez inclure un client d'interface d'exécution dans votre image. Le client de l'interface d'exécution doit étendre le[Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés](runtimes-api.md), qui gère l'interaction entre Lambda et votre code de fonction. AWS fournit des clients d'interface d'exécution open source pour les langages suivants :
+ [Node.js](nodejs-image.md#nodejs-image-clients)
+ [Python](python-image.md#python-image-clients)
+ [Java](java-image.md#java-image-clients)
+ [.NET](csharp-image.md#csharp-image-clients)
+ [Go](go-image.md#go-image-clients)
+ [Ruby](ruby-image.md#ruby-image-clients)
+ [Rouille](lambda-rust.md) —
Si vous utilisez un langage qui ne possède pas de client d'interface d'exécution AWS fourni, vous devez créer le vôtre.
## Autorisations Amazon ECR
Avant de créer une fonction Lambda à partir d’une image de conteneur, vous devez créer l’image localement et la charger dans un référentiel Amazon ECR. Lorsque vous créez la fonction, indiquez l’URI du référentiel Amazon ECR.
Assurez-vous que les autorisations accordées à l'utilisateur ou au rôle qui crée la fonction incluent `GetRepositoryPolicy``SetRepositoryPolicy`,`BatchGetImage`, et`GetDownloadUrlForLayer`.
Par exemple, utilisez la console IAM pour créer un rôle avec la stratégie suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecr:SetRepositoryPolicy",
"ecr:GetRepositoryPolicy",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world"
}
]
}
```
------
### Politiques de référentiel Amazon ECR
Pour qu’une fonction dans le même compte accède à l’image conteneur dans Amazon ECR, vous pouvez ajouter des autorisations `ecr:BatchGetImage` et `ecr:GetDownloadUrlForLayer` à votre politique de référentiel Amazon ECR. L’exemple suivant présente la stratégie minimum :
```
{
"Sid": "LambdaECRImageRetrievalPolicy",
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
]
}
```
Pour plus d’informations sur les autorisations des référentiels Amazon ECR, consultez [Politiques des référentiels privés](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html) dans le *Guide de l’utilisateur Amazon Elastic Container Registry*.
Si le référentiel Amazon ECR n’inclut pas ces autorisations, Lambda tente de les ajouter automatiquement. Lambda ne peut ajouter ces autorisations que si le principal appelant Lambda dispose des autorisations `ecr:getRepositoryPolicy` et `ecr:setRepositoryPolicy`.
Pour afficher ou modifier les autorisations de votre référentiel Amazon ECR, suivez les instructions de la section [Définition d’une déclaration de politique de référentiel privé](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) dans le *Guide de l’utilisateur Amazon Elastic Container Registry*.
#### Autorisations entre comptes Amazon ECR
Un autre compte dans la même région peut créer une fonction qui utilise une image conteneur appartenant à votre compte. Dans l’exemple suivant, votre [politique d’autorisations de référentiel Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) a besoin des instructions suivantes pour accorder l’accès au numéro de compte 123456789012.
+ **CrossAccountPermission**— Permet au compte 123456789012 de créer et de mettre à jour des fonctions Lambda qui utilisent des images provenant de ce référentiel ECR.
+ **Lambda — ECRImage CrossAccountRetrievalPolicy** Lambda finira par définir l'état d'une fonction sur inactif si elle n'est pas invoquée pendant une période prolongée. Cette instruction est requise pour que Lambda puisse récupérer l’image conteneur à des fins d’optimisation et de mise en cache pour le compte de la fonction détenue par 123456789012.
**Example – Ajouter une autorisation entre comptes à votre référentiel**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CrossAccountPermission",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
},
{
"Sid": "LambdaECRImageCrossAccountRetrievalPolicy",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Condition": {
"ArnLike": {
"aws:sourceARN": "arn:aws:lambda:us-east-1:123456789012:function:*"
}
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
}
]
}
```
Pour donner accès à plusieurs comptes, vous ajoutez le compte IDs à la liste Principal de la `CrossAccountPermission` politique et à la liste d'évaluation des conditions dans le`LambdaECRImageCrossAccountRetrievalPolicy`.
Si vous travaillez avec plusieurs comptes au AWS sein d'une organisation, nous vous recommandons d'énumérer chaque ID de compte dans la politique d'autorisation ECR. Cette approche est conforme aux meilleures pratiques de AWS sécurité qui consistent à définir des autorisations restreintes dans les politiques IAM.
Outre les autorisations Lambda, l’utilisateur ou le rôle qui crée la fonction doit également disposer des autorisations `BatchGetImage` et `GetDownloadUrlForLayer`.
## Cycle de vie des fonctions
Après avoir chargé une nouvelle image de conteneur ou une image de conteneur mise à jour, Lambda optimise l'image avant que la fonction ne puisse traiter les appels. Le processus d'optimisation peut prendre quelques secondes. La fonction reste dans l’état `Pending` jusqu’à ce que le processus se termine, l’état passant alors à `Active`. Vous ne pouvez pas invoquer la fonction jusqu’à ce qu’elle atteigne l’état `Active`.
Si une fonction n'est pas appelée pendant plusieurs semaines, Lambda récupère sa version optimisée, et la fonction passe à l'état `Inactive`. Pour réactiver la fonction, vous devez l'appeler. Lambda rejette la première invocation et la fonction passe à l'état `Pending` jusqu'à ce que Lambda réoptimise l'image. La fonction revient ensuite à l'état `Active`.
Lambda récupère périodiquement l’image de conteneur associée à partir du référentiel Amazon ECR. Si l'image de conteneur correspondante n'existe plus sur Amazon ECR ou si les autorisations ont été révoquées, la fonction passera à l'état `Failed`, et Lambda renverra un message d'échec à tout appel de la fonction.
Vous pouvez utiliser l'API Lambda pour obtenir des informations sur l'état d'une fonction. Pour de plus amples informations, veuillez consulter [États de la fonction Lambda](functions-states.md).