Compilation par défaut avec AWS SAM

Pour créer votre application sans serveur, utilisez la commande sam build. Cette commande rassemble également les artefacts de construction des dépendances de votre application et les place dans le format et l'emplacement appropriés pour les prochaines étapes, telles que les tests locaux, l'empaquetage et le déploiement.

Vous spécifiez les dépendances de votre application dans un fichier manifeste, tel que requirements.txt (Python) ou package.json (Node.js), ou à l'aide de la propriété Layers d'une ressource de fonction. La propriété Layers contient une liste de ressources de couche AWS Lambda dont dépend la fonction Lambda.

Le format des artefacts de construction de votre application dépend de la propriété PackageType de chaque fonction. Les options pour cette propriété sont :

• Zip – Une archive de fichiers .zip, comportant le code de votre application et ses dépendances. Si vous empaquetez le code sous la forme d’une archive de fichiers .zip, vous devez spécifier une exécution Lambda pour la fonction.

• Image : une image de conteneur incluant le système d’exploitation de base, l’exécution et les extensions, en plus du code de l’application et ses dépendances.

Pour de plus amples informations sur les types de packages Lambda, consultez Packages de déploiement Lambda dans le Guide du développeur AWS Lambda .

Création d'une archive de fichier .zip

Pour créer votre application sans serveur en tant qu'archive de fichier .zip, déclarez PackageType: Zip pour votre fonction sans serveur.

AWS SAM construit votre application pour l'architecture que vous spécifiez. Si vous ne spécifiez pas d'architecture, AWS SAM utilise x86_64 par défaut.

Si votre fonction Lambda dépend de packages qui ont compilé nativement des programmes, utilisez l'indicateur --use-container. Cet indicateur compile localement vos fonctions dans un conteneur Docker qui se comporte comme un environnement Lambda, afin qu'elles soient au bon format lorsque vous les déployez dans le Cloud. AWS

Lorsque vous utilisez --use-container cette option, l'image du conteneur AWS SAM est extraite par défaut d'Amazon ECR Public. Si vous souhaitez extraire une image de conteneur d'un autre référentiel, par exemple DockerHub, vous pouvez utiliser l'--build-imageoption et fournir l'URI d'une autre image de conteneur. Voici deux exemples de commandes permettant de créer des applications à l'aide d'images de conteneurs provenant du DockerHub référentiel :

# Build a Node.js 20 application using a container image pulled from DockerHub
sam build --use-container --build-image amazon/aws-sam-cli-build-image-nodejs20.x

# Build a function resource using the Python 3.12 container image pulled from DockerHub
sam build --use-container --build-image Function1=amazon/aws-sam-cli-build-image-python3.12 

Pour obtenir la liste des URI que vous pouvez utiliser--build-image, consultez celle Référentiels d'images qui contient les DockerHub URI pour un certain nombre d'environnements d'exécution pris en charge.

Pour obtenir d'autres exemples de création d'une application d'archivage de fichiers .zip, reportez-vous à la section Exemples plus loin dans cette rubrique.

Création d'une image de conteneur

Pour créer votre application sans serveur en tant qu'image de conteneur, déclarez PackageType: Image pour votre fonction sans serveur. Vous devez également déclarer l'attribut de ressource Metadata avec les entrées suivantes :

Dockerfile

Nom du Dockerfile associé à la fonction Lambda.

DockerContext

Emplacement du fichier journal.

DockerTag

(Facultatif) Balise à appliquer à l'image créée.

DockerBuildArgs

Arguments de construction pour la création.

Voici un exemple de section d'attribut de ressource Metadata :

    Metadata:
      Dockerfile: Dockerfile
      DockerContext: ./hello_world
      DockerTag: v1

Pour télécharger un exemple d'application configurée avec le type de package Image, consultez Tutoriel : Déployer une application Hello World dans Tutoriel : déploiement d'une application Hello World. En réponse à l'invite demandant quel type de package vous souhaitez installer, choisissez Image.

Note

Si vous spécifiez une image de base multi-architecture dans votre Dockerfile, AWS SAM crée votre image de conteneur pour l'architecture de votre machine hôte. Pour créer une architecture différente, spécifiez une image de base qui utilise l'architecture cible spécifique.

Fichier de variables d'environnement du conteneur.

Pour fournir un fichier JSON qui contient des variables d'environnement pour le conteneur de construction, utilisez l'argument --container-env-var-file avec la commande sam build. Vous pouvez fournir une variable d'environnement unique qui s'applique à toutes les ressources sans serveur, ou des variables d'environnement différentes pour chaque ressource.

Format

Le format de transmission des variables d'environnement à un conteneur de construction dépend du nombre de variables d'environnement que vous fournissez pour vos ressources.

Pour fournir une variable d'environnement unique pour toutes les ressources, spécifiez un objet Parameters se présentant comme suit :

{
  "Parameters": {
    "GITHUB_TOKEN": "TOKEN_GLOBAL"
  }
}

Pour fournir différentes variables d'environnement pour chaque ressource, spécifiez des objets pour chaque ressource comme suit :

{
  "MyFunction1": {
    "GITHUB_TOKEN": "TOKEN1"
  },
  "MyFunction2": {
    "GITHUB_TOKEN": "TOKEN2"
  }
}

Enregistrez vos variables d'environnement en tant que fichier, par exemple nommé env.json. La commande suivante utilise ce fichier pour transmettre vos variables d'environnement au conteneur de construction :

sam build --use-container --container-env-var-file env.json

Priorité

• Les variables d'environnement que vous fournissez pour des ressources spécifiques seront prioritaires sur la variable d'environnement unique pour toutes les ressources.

• Les variables d'environnement que vous fournissez sur la ligne de commande seront prioritaires sur les variables d'environnement d'un fichier.

Accélérez les temps de création en créant votre projet dans le dossier source

Pour les systèmes d'exécution et les méthodes de création pris en charge, vous pouvez utiliser l'option --build-in-source permettant de créer votre projet directement dans le dossier source. Par défaut, il est AWS SAM CLI compilé dans un répertoire temporaire, ce qui implique de copier le code source et les fichiers de projet. Avec--build-in-source, les AWS SAM CLI builds se trouvent directement dans votre dossier source, ce qui accélère le processus de compilation en supprimant le besoin de copier des fichiers dans un répertoire temporaire.

Pour obtenir une liste des systèmes d’exécution ainsi que des méthodes de création pris en charge, consultez --build-in-source.

Exemples

Exemple 1 : archive de fichier .zip

Les commandes sam build suivantes créent une archive de fichier .zip :

# Build all functions and layers, and their dependencies
sam build

# Run the build process inside a Docker container that functions like a Lambda environment
sam build --use-container

# Build a Node.js 20 application using a container image pulled from DockerHub
sam build --use-container --build-image amazon/aws-sam-cli-build-image-nodejs20.x

# Build a function resource using the Python 3.12 container image pulled from DockerHub
sam build --use-container --build-image Function1=amazon/aws-sam-cli-build-image-python3.12 

# Build and run your functions locally
sam build && sam local invoke

# For more options
sam build --help

Exemple 2 : image de conteneur

Le AWS SAM modèle suivant est créé sous forme d'image de conteneur :

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      PackageType: Image
      ImageConfig:
        Command: ["app.lambda_handler"]
    Metadata:
      Dockerfile: Dockerfile
      DockerContext: ./hello_world
      DockerTag: v1

Voici un exemple de Dockerfile :

FROM public.ecr.aws/lambda/python:3.12

COPY app.py requirements.txt ./

RUN python3.12 -m pip install -r requirements.txt

# Overwrite the command by providing a different command directly in the template.
CMD ["app.lambda_handler"]

Exemple 3 : npm ci

Pour les applications Node.js, vous pouvez utiliser npm ci au lieu de npm install pour installer les dépendances. Pour utiliser npm ci, spécifiez UseNpmCi: True sous BuildProperties dans votre attribut de ressource Metadata de la fonction Lambda. Pour utiliser npm ci, votre application doit disposer d'un fichier package-lock.json ou npm-shrinkwrap.json présent dans le CodeUripour votre fonction Lambda.

L'exemple suivant utilise npm ci pour installer des dépendances lorsque vous exécutez sam build :

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.handler
      Runtime: nodejs20.x
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get
    Metadata:
      BuildProperties:
        UseNpmCi: True

Fonctions du bâtiment en dehors de AWS SAM

Par défaut, lorsque vous exécutezsam build, AWS SAM crée toutes les ressources de vos fonctions. Les autres options sont les suivantes :

• Construire toutes les ressources fonctionnelles en dehors de AWS SAM — Si vous créez toutes vos ressources fonctionnelles manuellement ou via un autre outil, cela n'sam buildest pas obligatoire. Vous pouvez ignorer sam build et passer à l'étape suivante de votre processus, par exemple effectuer des tests locaux ou déployer votre application.

• Création de ressources fonctionnelles en dehors de AWS SAM : si vous AWS SAM souhaitez créer certaines de vos ressources fonctionnelles tout en créant d'autres ressources fonctionnelles en dehors de AWS SAM celles-ci, vous pouvez le spécifier dans votre AWS SAM modèle.

Créez des ressources fonctionnelles en dehors de AWS SAM

Pour AWS SAM ignorer une fonction lors de son utilisationsam build, configurez les éléments suivants dans votre AWS SAM modèle :

1. Ajoutez la propriété de métadonnées SkipBuild: True à votre fonction.

2. Spécifiez le chemin d'accès à vos ressources de fonction créées.

Voici un exemple, avec TestFunction configuré pour être ignoré. Ses ressources créées se trouvent à cet emplacement : built-resources/TestFunction.zip.

TestFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: built-resources/TestFunction.zip
    Handler: TimeHandler::handleRequest
    Runtime: java11
  Metadata:
    SkipBuild: True

Maintenant, lorsque vous exécuterezsam build, vous AWS SAM ferez ce qui suit :

1. AWS SAM ignorera les fonctions configurées avecSkipBuild: True.

2. AWS SAM créera toutes les autres ressources fonctionnelles et les mettra en cache dans le répertoire de .aws-sam construction.

3. Pour les fonctions ignorées, leur modèle dans le répertoire de création .aws-sam est automatiquement mis à jour pour référencer le chemin spécifié vers les ressources de vos fonctions créées.

   Voici un exemple du modèle mis en cache pour TestFunction dans le répertoire de création .aws-sam :

   TestFunction:
     Type: AWS::Serverless::Function
     Properties:
       CodeUri: ../../built-resources/TestFunction.zip
       Handler: TimeHandler::handleRequest
       Runtime: java11
     Metadata:
       SkipBuild: True