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.
# Construit 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](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) 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](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html) dans le *Guide du développeur AWS Lambda *.
**Topics**
+ [
## Création d'une archive de fichier .zip
](#build-zip-archive)
+ [
## Création d'une image de conteneur
](#build-container-image)
+ [
## Fichier de variables d'environnement du conteneur.
](#serverless-sam-cli-using-container-environment-file)
+ [
## Accélérez les temps de création en créant votre projet dans le dossier source
](#serverless-sam-cli-using-build-in-source)
+ [
## Exemples
](#building-applications-examples)
+ [
## Fonctions du bâtiment en dehors de AWS SAM
](#building-applications-skip)
## 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](sam-resource-function.md#sam-function-architectures) 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 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.](https://docs.aws.amazon.com/AmazonECR/latest/public/what-is-ecr.html) Si vous souhaitez extraire une image de conteneur d'un autre référentiel ou pour une version spécifique de AWS SAM CLI, vous pouvez utiliser l'`--build-image`option 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 conteneur issues d'une version spécifique de la AWS SAM CLI :
```
# Build a Node.js 20 application using a container image for a specific version of AWS SAM CLI (1.136.0)
sam build --use-container --build-image public.ecr.aws/sam/build-nodejs22.x:1.136.0
# Build a function resource using the Python 3.13 container image from a specific version of AWS SAM CLI (1.136.0)(
sam build --use-container --build-image Function1=public.ecr.aws/sam/build-python3.13:1.136.0
```
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.
Le AWS SAMCLI ne supprime ni ne masque les informations que vous incluez dans les arguments. `DockerBuildArgs` Nous vous recommandons vivement de ne pas utiliser cette section pour stocker des informations sensibles, telles que des mots de passe ou des secrets.
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, consultez[Tutoriel : Déployer une application Hello World avec AWS SAM](serverless-getting-started-hello-world.md). 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 for a specific version of AWS SAM CLI (1.136.0)
sam build --use-container --build-image public.ecr.aws/sam/build-nodejs22.x:1.136.0
# Build a function resource using the Python 3.13 container image from a specific version of AWS SAM CLI (1.136.0)(
sam build --use-container --build-image Function1=public.ecr.aws/sam/build-python3.13:1.136.0
# 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 `CodeUri`pour 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
```
### Paquets parents Python
Pour les applications Python, vous pouvez conserver la structure de votre package pendant le processus de construction afin de permettre des importations absolues. Pour préserver la structure du package, spécifiez `ParentPackageMode` under `BuildProperties` dans l'attribut de `Metadata` ressource de votre fonction Lambda.
L'exemple suivant préserve la structure `app` du package lorsque vous exécutez `sam build` :
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.main.handler
Runtime: python3.12
Architectures:
- x86_64
Metadata:
BuildProperties:
ParentPackageMode: explicit
ParentPackages: app
```
Avec cette configuration, votre code peut utiliser des importations absolues `from app.utils import logger` au lieu d'importations relatives telles que`from .utils import logger`.
## Fonctions du bâtiment en dehors de AWS SAM
Par défaut, lorsque vous exécutez**sam 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 build**est 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 utilisation**sam 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.
1. 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écuterez**sam build**, vous AWS SAM ferez ce qui suit :
1. AWS SAM ignorera les fonctions configurées avec`SkipBuild: True`.
1. AWS SAM créera toutes les autres ressources fonctionnelles et les mettra en cache dans le répertoire de `.aws-sam` construction.
1. 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
```