Travailler avec des images de conteneurs Lambda - AWS Lambda
PrérequisUtilisation d’une image de base AWSUtilisation d'une image de base uniquement pour le système d'exploitation AWSUtilisation d'une image de base non-AWSClients d’interface d’exécutionAutorisations Amazon ECRParamètres d’images de conteneur

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.

Travailler avec des images de conteneurs Lambda

Le code de votre fonction AWS Lambda se compose de scripts ou de programmes compilés et 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 :

Astuce

Pour réduire le temps nécessaire à l’activation des fonctions du conteneur Lambda, consultez Utiliser des générations en plusieurs étapes (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 (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). Indiquez ensuite l’URI du référentiel lorsque vous créez la fonction. Le référentiel Amazon ECR doit être dans la même Région AWS que la fonction Lambda. Vous pouvez créer une fonction à l’aide d’une image dans un compte AWS différent, à condition que l’image soit dans la même région que la fonction Lambda. Pour plus d’informations, consultez Autorisations entre comptes Amazon ECR.

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 (.zip ou image de conteneur) pour une fonction existante. Par exemple, vous ne pouvez pas convertir une fonction d'image de conteneur pour utiliser une archive de fichier .zip. Vous devez créer une nouvelle fonction.

Prérequis

Installez l’AWS Command Line Interface (AWS CLI) version 2 et la CLI de Docker. En outre, notez les exigences suivantes :

  • L’image de conteneur doit implémenter l’API de l'environnement d'exécution Lambda. Les clients d’interface de runtime 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. 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 de base AWS pour Lambda

Vous pouvez utiliser l’une des images de base AWS 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 de base AWS 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. Afin d’utiliser l’image de base mise à jour, vous devez reconstruire votre image de conteneur et mettre à jour le code de la fonction.

Les images de base de Node.js 20, Python 3.12, Java 21, AL2023 et versions ultérieures sont basées sur l'image de conteneur minimale Amazon Linux 2023. Les images de base antérieures utilisaient Amazon Linux 2. AL2023 offre plusieurs avantages par rapport à Amazon  Linux2, notamment un encombrement de déploiement réduit et des versions mises à jour de bibliothèques telles que glibc.

Les images basées sur AL2023 utilisent microdnf (lien symbolique commednf) comme gestionnaire de packages au lieu deyum, qui est le gestionnaire de packages par défaut dans Amazon Linux 2. microdnfest une implémentation autonome de. dnf Pour obtenir la liste des packages inclus dans les images basées sur AL2023, reportez-vous aux colonnes Conteneur minimal de la section Comparaison des packages installés sur les images de conteneurs Amazon Linux 2023. Pour plus d'informations sur les différences entre AL2023 et Amazon Linux 2, consultez Présentation du runtime Amazon Linux 2023 AWS Lambda sur le blog AWS Compute.

Note

Pour exécuter des images basées sur AL2023 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 base AWS, choisissez les instructions correspondant à votre langage préféré :

Utilisation d'une image de base uniquement pour le système d'exploitation AWS

Les images de base de système d’exploitation AWS contiennent la distribution Amazon Linux et l'émulateur d'interface d'exécution. Ces images sont couramment utilisées pour créer des images de conteneur pour les langages compilés, tels que Go et Rust, 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é. Pour rendre l’image compatible avec Lambda, vous devez inclure un client d’interface d’exécution pour votre langage dans l’image.

Balises 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

al2

 Exécution uniquement basée sur le système d'exploitation Amazon Linux 2 Dockerfile pour OS uniquement Runtime sur GitHub

Galerie publique Amazon Elastic Container Registry : gallery.ecr.aws/lambda/fourni

Utilisation d'une image de base non-AWS

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 pour votre langage dans l’image.

Clients d’interface d’exécution

Si vous utilisez une image de base uniquement pour le système d’exploitation ou une autre image de base, vous devez inclure un client d'interface d'exécution dans votre image. Le client d’interface d’exécution doit étendre l’API de l'environnement d'exécution Lambda, 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 :

Si vous utilisez un langage qui ne dispose pas d’un client d’interface d’exécution fourni par AWS, vous devez créer votre propre interface.

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.

Vérifiez que les autorisations pour l’utilisateur ou le rôle qui crée la fonction contiennent les stratégies gérées AWS GetRepositoryPolicy et SetRepositoryPolicy.

Par exemple, utilisez la console IAM pour créer un rôle avec la stratégie suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "ecr:SetRepositoryPolicy",
        "ecr:GetRepositoryPolicy"
      ],
      "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 dans le Guide de l’utilisateur Amazon Elastic Container Registry.

Si le référentiel Amazon ECR n’inclut pas ces autorisations, Lambda ajoute les autorisations ecr:BatchGetImage et ecr:GetDownloadUrlForLayer aux autorisations du référentiel d’images conteneurs. 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é 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 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.

  • LambdaECR — ImageCrossAccountRetrievalPolicy 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.

Exemple – 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"
      }
    },
    {
      "Sid": "LambdaECRImageCrossAccountRetrievalPolicy",
      "Effect": "Allow",
      "Action": [
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ],
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Condition": {
        "StringLike": {
          "aws:sourceARN": "arn:aws:lambda:us-east-1:123456789012:function:*"
        }
      }
    }
  ]
}

Pour donner accès à plusieurs comptes, vous ajoutez les ID de compte à la liste Principal de la stratégie CrossAccountPermissionet à la liste d’évaluation des conditions dans leLambdaECRImageCrossAccountRetrievalPolicy.

Si vous travaillez avec plusieurs comptes dans uneAWSEntreprise, nous vous recommandons d’énumérer chaque ID de compte dans la stratégie d’autorisations ECR. Cette approche s’aligne sur les bonnes pratiques AWS de sécurité consistant à définir des autorisations étroites dans les stratégies IAM.

Paramètres d’images de conteneur

Les paramètres suivants sont des paramètres courants de l’image du conteneur. Si vous utilisez ces paramètres dans votre Dockerfile, notez comment Lambda interprète et traite ces paramètres :

  • ENTRYPOINT – Spécifie le chemin absolu vers le point d’entrée de l’application.

  • CMD – Spécifie les paramètres que vous souhaitez transmettre avec ENTRYPOINT.

  • WORKDIR – Spécifie le chemin absolu vers le répertoire de travail.

  • ENV – Spécifie une variable d’environnement pour la fonction Lambda.

Pour plus d’informations sur la manière dont Docker utilise les paramètres d’images de conteneur, consultez ENTRYPOINT dans la référence du fichier Docker, sur le site web Docker Docs. Pour plus d’informations sur l’utilisation des paramètres ENTRYPOINT et CMD, consultez Lumière sur les paramètres ENTRYPOINT et CMD dans Docker, sur le blog AWS Open Source.

Vous pouvez spécifier les paramètres d’images de conteneur dans le fichier Docker lorsque vous créez votre image. Vous pouvez également remplacer ces configurations à l’aide de la console Lambda ou de l’API Lambda. Cela vous permet de déployer plusieurs fonctions qui déploient la même image de conteneur, mais avec des configurations de runtime différentes.

Avertissement

Lorsque vous spécifiez ENTRYPOINT ou CMD dans le Dockerfile ou en tant que remplacement, veillez à saisir le chemin absolu. En outre, n’utilisez pas de liens symboliques en tant que point d’entrée du conteneur.

Pour remplacer les valeurs de configuration dans l’image de conteneur

  1. Ouvrez la page Functions (Fonctions) de la console Lambda.

  2. Sélectionnez la fonction à mettre à jour.

  3. Sous Image configuration (Configuration de l’image), sélectionnez Edit (Modifier).

  4. Saisissez de nouvelles valeurs pour l’un des paramètres de remplacement, puis sélectionnez Save (Enregistrer).

  5. (Facultatif) Pour ajouter ou remplacer des variables d’environnement, sous Environment variables (Variables d’environnement), sélectionnez Edit (Modifier).

Pour plus d'informations, consultez Utilisation des variables d’environnement Lambda.