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.

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 Layers propriété contient une liste de AWS Lambdaressources de couche 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 :

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

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 aucune 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. Elles sont donc au bon format lorsque vous les déployez sur AWS Nuage.

Lorsque vous utilisez l'--use-containeroption, par défaut AWS SAM extrait l'image du conteneur depuis 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 une autre image URI 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 environnements d'exécution URIs que vous pouvez utiliser--build-image, reportez-vous à la section Référentiels d'images pour AWS SAM qui contient un certain nombre DockerHub URIs 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 :

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é avec le type de Image package, consultezTutoriel : Déployer une application Hello World avec AWS SAM. En réponse à l'invite demandant quel type de package vous souhaitez installer, choisissez Image.

Fichier de variables d'environnement du conteneur.

Pour fournir un JSON fichier contenant des variables d'environnement pour le conteneur de construction, utilisez l'--container-env-var-fileargument avec la sam build commande. 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é

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, le AWS SAM CLI se construit dans un répertoire temporaire, ce qui implique de copier le code source et les fichiers de projet. Avec--build-in-source, le AWS SAM CLI se construit directement dans votre dossier source, ce qui accélère le processus de génération 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

Procédez comme suit : AWS SAM le modèle est construit 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 construit toutes vos ressources fonctionnelles. Les autres options sont les suivantes :

Créez des ressources fonctionnelles en dehors de AWS SAM

Avoir AWS SAM ignorez une fonction lors de l'utilisationsam build, configurez ce qui suit dans votre AWS SAM modèle :

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, quand tu courssam build, AWS SAM effectuera les opérations suivantes :