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éez votre application avec AWS SAM
Après avoir ajouté votre infrastructure sous forme de code (iAc) à votre AWS SAM modèle, vous serez prêt à commencer à créer votre application à l'aide de la **sam build** commande. Cette commande crée des artefacts de construction à partir des fichiers du répertoire de votre projet d'application (c'est-à-dire votre fichier AWS SAM modèle, le code de l'application et tous les fichiers et dépendances spécifiques au langage applicable). Ces artefacts de build préparent votre application sans serveur pour les étapes ultérieures du développement de votre application, telles que les tests locaux et le déploiement AWS dans le cloud. Les tests et le déploiement utilisent des artefacts de construction comme entrées.
Vous pouvez l'utiliser **sam build** pour créer l'intégralité de votre application sans serveur. En outre, vous pouvez créer des versions personnalisées, par exemple des versions avec des fonctions, des couches ou des environnements d'exécution personnalisés spécifiques. Pour en savoir plus sur comment et pourquoi vous l'utilisez**sam build**, consultez les rubriques de cette section. Pour une introduction à l'utilisation de la commande `sam build`, consultez [Initiation à la construction avec AWS SAM](using-sam-cli-build.md).
**Topics**
+ [Initiation à la construction avec AWS SAM](using-sam-cli-build.md)
+ [Construit par défaut avec AWS SAM](serverless-sam-cli-using-build.md)
+ [Personnalisez les builds avec AWS SAM](building-lambda-functions.md)
# Initiation à la construction avec AWS SAM
Utilisez la AWS Serverless Application Model commande Command Line Interface (AWS SAMCLI) `sam build` pour préparer votre application sans serveur aux étapes suivantes de votre flux de travail de développement, telles que les tests locaux ou le déploiement sur le AWS Cloud. Cette commande crée un répertoire `.aws-sam` qui structure votre application dans un format et un emplacement que `sam local` et `sam deploy` nécessitent.
+ Pour une introduction à la AWS SAMCLI, voir[Qu'est-ce que c'est AWS SAMCLI ?](what-is-sam-overview.md#what-is-sam-cli).
+ Pour obtenir la liste des options de commande `sam build`, consultez [sam build](sam-cli-command-reference-sam-build.md).
+ Pour un exemple d'utilisation de `sam build` dans le cadre d'un flux de travail de développement classique, consultez [Étape 2 : créer votre application](serverless-getting-started-hello-world.md#serverless-getting-started-hello-world-build).
**Note**
L'utilisation de `sam build` nécessite que vous commenciez avec les composants de base d'une application sans serveur sur votre machine de développement. Cela inclut un AWS SAM modèle, un code de AWS Lambda fonction, ainsi que tous les fichiers et dépendances spécifiques au langage. Pour en savoir plus, veuillez consulter la section [Créez votre application dans AWS SAM](using-sam-cli-init.md).
**Topics**
+ [Création d'applications avec sam build](#using-sam-cli-build-apps)
+ [Test et déploiement au niveau local](#using-sam-cli-build-test-deploy)
+ [Bonnes pratiques](#using-sam-cli-build-best)
+ [Options pour sam build](#using-sam-cli-build-options)
+ [Résolution des problèmes](#using-sam-cli-build-troubleshooting)
+ [Exemples](#using-sam-cli-build-examples)
+ [En savoir plus](#using-sam-cli-build-learn)
## Création d'applications avec sam build
Avant de l'utiliser`sam build`, pensez à configurer les éléments suivants :
1. **Fonctions et couches Lambda** : la commande `sam build` permet de créer des fonctions et des couches Lambda. Pour en savoir plus sur les couches Lambda, consultez [Création de couches Lambda dans AWS SAM](building-layers.md).
1. **Exécution Lambda** : l'*exécution* fournit un environnement spécifique au langage qui exécute votre fonction dans un environnement d'exécution lorsqu'elle est invoquée. Vous pouvez configurer des environnements d'exécution natifs et personnalisés.
1. **Exécution native** : créez vos fonctions Lambda dans une exécution Lambda prise en charge et créez vos fonctions pour utiliser une exécution Lambda native dans le AWS Cloud.
1. **Exécution personnalisée** : créez vos fonctions Lambda à l'aide de n'importe quel langage de programmation et créez votre exécution à l'aide d'un processus personnalisé défini dans un makefile ou dans un créateur tiers tel que esbuild. Pour en savoir plus, veuillez consulter la section [Création de fonctions Lambda avec des environnements d'exécution personnalisés dans AWS SAM](building-custom-runtimes.md).
1. **Type de package Lambda** : les fonctions Lambda peuvent être packagées dans les types de packages de déploiement Lambda suivants :
1. **.zip file archive** : contient le code de votre application et ses dépendances.
1. **Image du conteneur** : contient le système d'exploitation de base, l'exécution, les extensions Lambda, le code de votre application et ses dépendances.
Ces paramètres d'application peuvent être configurés lors de l'initialisation d'une application à l'aide de `sam init`.
+ Pour en savoir plus sur l'utilisation de `sam init`, consultez [Créez votre application dans AWS SAM](using-sam-cli-init.md).
+ Pour en savoir plus sur la configuration de ces paramètres dans votre application, consultez [Construit par défaut avec AWS SAM](serverless-sam-cli-using-build.md).
**Pour créer une application**
1. `cd` à la racine de votre projet. Il s'agit du même emplacement que celui de votre AWS SAM modèle.
```
$ cd sam-app
```
1. Exécutez les commandes suivantes :
```
sam-app $ sam build
```
**Note**
Une option couramment utilisée est `--use-container`. Pour en savoir plus, veuillez consulter la section [Création d'une fonction Lambda à l'intérieur d'un conteneur fourni](#using-sam-cli-build-options-container).
Voici un exemple de réponse générée par la CLI AWS SAM :
```
sam-app $ sam build
Starting Build use cache
Manifest file is changed (new hash: 3298f1304...d4d421) or dependency folder (.aws-sam/deps/4d3dfad6-a267-47a6-a6cd-e07d6fae318c) is missing for (HelloWorldFunction), downloading dependencies and copying/building source
Building codeuri: /Users/.../sam-app/hello_world runtime: python3.12 metadata: {} architecture: x86_64 functions: HelloWorldFunction
Running PythonPipBuilder:CleanUp
Running PythonPipBuilder:ResolveDependencies
Running PythonPipBuilder:CopySource
Running PythonPipBuilder:CopySource
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
1. La CLI AWS SAM crée un répertoire de création `.aws-sam`. Voici un exemple :
```
.aws-sam
├── build
│ ├── HelloWorldFunction
│ │ ├── __init__.py
│ │ ├── app.py
│ │ └── requirements.txt
│ └── template.yaml
└── build.toml
```
En fonction de la configuration de votre application, la CLI AWS SAM effectue les opérations suivantes :
1. Elle télécharge, installe et organise les dépendances dans le répertoire `.aws-sam/build`.
1. Elle prépare votre code Lambda. Il peut s'agir de compiler votre code, de créer des fichiers binaires exécutables et de créer des images de conteneurs.
1. Elle copie les artefacts de création dans le répertoire `.aws-sam`. Le format varie en fonction du type du package de l'application.
1. Pour les types de packages .zip, les artefacts ne sont pas encore compressés afin de pouvoir être utilisés pour des tests locaux. La CLI AWS SAM compresse votre application lorsqu'elle utilise `sam deploy`.
1. Pour les types de packages d'images de conteneurs, une image de conteneur est créée localement et référencée dans le fichier `.aws-sam/build.toml`.
1. Copie le AWS SAM modèle `.aws-sam` dans le répertoire et le modifie avec de nouveaux chemins de fichiers si nécessaire.
Les principaux composants qui constituent vos artefacts de création dans le répertoire `.aws-sam` sont les suivants :
+ **Le répertoire de création** : contient vos fonctions et couches Lambda structurées indépendamment les unes des autres. La structure est donc unique pour chaque fonction ou couche du répertoire `.aws-sam/build`.
+ **Le AWS SAM modèle** : modifié avec des valeurs mises à jour en fonction des modifications apportées au cours du processus de création.
+ **Le fichier build.toml : fichier** de configuration contenant les paramètres de construction utilisés par le. AWS SAMCLI
## Test et déploiement au niveau local
Lorsque vous effectuez des tests locaux avec `sam local` ou un déploiement avec `sam deploy`, la CLI AWS SAM effectue les opérations suivantes :
1. Il vérifie d'abord si un `.aws-sam` répertoire existe et si un AWS SAM modèle se trouve dans ce répertoire. Si ces conditions sont remplies, la CLI AWS SAM considère qu'il s'agit du répertoire racine de votre application.
1. Si ces conditions ne sont pas remplies, l' AWS SAMCLIemplacement d'origine de votre AWS SAM modèle est considéré comme le répertoire racine de votre application.
Lors du développement, si des modifications sont apportées à vos fichiers d'application originaux, exécutez `sam build` pour mettre à jour le répertoire `.aws-sam` avant de tester localement.
## Bonnes pratiques
+ Ne modifiez aucun code dans le répertoire `.aws-sam/build`. Mettez plutôt à jour votre code source original dans le dossier de votre projet et exécutez `sam build` pour mettre à jour le répertoire `.aws-sam/build`.
+ Lorsque vous modifiez vos fichiers originaux, exécutez `sam build` pour mettre à jour le répertoire `.aws-sam/build`.
+ Il se peut que vous souhaitiez que la CLI AWS SAM fasse référence au répertoire racine d'origine de votre projet plutôt qu'au répertoire `.aws-sam`, par exemple lors du développement et des tests avec `sam local`. Supprimez le `.aws-sam` répertoire ou le AWS SAM modèle dans le `.aws-sam` répertoire pour que le répertoire de votre projet d'origine soit AWS SAMCLI reconnu comme le répertoire racine du projet. Lorsque vous êtes prêt, exécutez à nouveau `sam build` pour créer le répertoire `.aws-sam`.
+ Lorsque vous exécutez `sam build`, le répertoire `.aws-sam/build` est remplacé à chaque fois. Le répertoire `.aws-sam` ne l'est pas. Si vous souhaitez stocker des fichiers, tels que des journaux, stockez-les dans `.aws-sam` pour éviter qu'ils ne soient remplacés.
## Options pour sam build
### Création d'une seule ressource
Fournissez l'ID logique de la ressource pour ne créer que cette ressource. Voici un exemple :
```
$ sam build HelloWorldFunction
```
Pour créer une ressource d'une application ou d'une pile imbriquée, fournissez l'identifiant logique de l'application ou de la pile avec l'identifiant logique de la ressource en utilisant le format `/` :
```
$ sam build MyNestedStack/MyFunction
```
### Création d'une fonction Lambda à l'intérieur d'un conteneur fourni
L'option `--use-container` télécharge une image de conteneur et l'utilise pour créer vos fonctions Lambda. Le conteneur local est ensuite référencé dans votre fichier `.aws-sam/build.toml`.
Cette option nécessite que Docker soit installé. Pour obtenir des instructions, veuillez consulter [Installation de Docker](install-docker.md).
Voici un exemple de cette commande :
```
$ sam build --use-container
```
Vous pouvez spécifier l'image de conteneur à utiliser avec l'option `--build-image`. Voici un exemple :
```
$ sam build --use-container --build-image amazon/aws-sam-cli-build-image-nodejs20.x
```
Pour spécifier l'image du conteneur à utiliser pour une seule fonction, fournissez l'ID logique de la fonction. Voici un exemple :
```
$ sam build --use-container --build-image Function1=amazon/aws-sam-cli-build-image-python3.12
```
### Transmettre des variables d'environnement au conteneur de création
Utilisez `--container-env-var` pour transmettre les variables d'environnement au conteneur de création. Voici un exemple :
```
$ sam build --use-container --container-env-var Function1.GITHUB_TOKEN= --container-env-var GLOBAL_ENV_VAR=
```
Pour transmettre des variables d'environnement à partir d'un fichier, utilisez l'option `--container-env-var-file`. Voici un exemple :
```
$ sam build --use-container --container-env-var-file
```
Exemple de fichier `env.json` :
```
{
"MyFunction1": {
"GITHUB_TOKEN": "TOKEN1"
},
"MyFunction2": {
"GITHUB_TOKEN": "TOKEN2"
}
}
```
### Accélérez la création d'applications contenant plusieurs fonctions
Lorsque vous exécutez `sam build` sur une application comportant plusieurs fonctions, la CLI AWS SAM crée chaque fonction une par une. Pour accélérer le processus de création, utilisez l'option `--parallel`. Cela crée toutes les fonctions et couches en même temps.
Voici un exemple de cette commande :
```
$ sam build —-parallel
```
### 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`.
## Résolution des problèmes
Pour résoudre le problème AWS SAMCLI, voir[Résolution des problèmes de la CLI AWS SAM](sam-cli-troubleshooting.md).
## Exemples
### Création d'une application utilisant une exécution native et un type de package .zip
Pour cet exemple, consultez [Tutoriel : Déployer une application Hello World avec AWS SAM](serverless-getting-started-hello-world.md).
### Création d'une application utilisant une exécution native et un type de package d'images
Tout d'abord, nous exécutons `sam init` pour initialiser une nouvelle application. Au cours du flux interactif, nous sélectionnons le type de package `Image`. Voici un exemple :
```
$ sam init
...
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
4 - Scheduled task
5 - Standalone function
6 - Data processing
7 - Hello World Example With Powertools
8 - Infrastructure event management
9 - Serverless Connector Hello World Example
10 - Multi-step workflow with Connectors
11 - Lambda EFS example
12 - DynamoDB Example
13 - Machine Learning
Template: 1
Use the most popular runtime and package type? (Python and zip) [y/N]: ENTER
Which runtime would you like to use?
...
10 - java8
11 - nodejs20.x
12 - nodejs18.x
13 - nodejs16.x
...
Runtime: 12
What package type would you like to use?
1 - Zip
2 - Image
Package type: 2
Based on your selections, the only dependency manager available is npm.
We will proceed copying the template using npm.
Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER
Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER
Project name [sam-app]: ENTER
Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)
-----------------------
Generating application:
-----------------------
Name: sam-app
Base Image: amazon/nodejs18.x-base
Architectures: x86_64
Dependency Manager: npm
Output Directory: .
Configuration file: sam-app/samconfig.toml
Next steps can be found in the README file at sam-app/README.md
...
```
AWS SAMCLIInitialise une application et crée le répertoire de projet suivant :
```
sam-app
├── README.md
├── events
│ └── event.json
├── hello-world
│ ├── Dockerfile
│ ├── app.mjs
│ ├── package.json
│ └── tests
│ └── unit
│ └── test-handler.mjs
├── samconfig.toml
└── template.yaml
```
Ensuite, nous exécutons `sam build` pour créer notre application :
```
sam-app $ sam build
Building codeuri: /Users/.../build-demo/sam-app runtime: None metadata: {'DockerTag': 'nodejs18.x-v1', 'DockerContext': '/Users/.../build-demo/sam-app/hello-world', 'Dockerfile': 'Dockerfile'} architecture: arm64 functions: HelloWorldFunction
Building image for HelloWorldFunction function
Setting DockerBuildArgs: {} for HelloWorldFunction function
Step 1/4 : FROM public.ecr.aws/lambda/nodejs:18
---> f5b68038c080
Step 2/4 : COPY app.mjs package*.json ./
---> Using cache
---> 834e565aae80
Step 3/4 : RUN npm install
---> Using cache
---> 31c2209dd7b5
Step 4/4 : CMD ["app.lambdaHandler"]
---> Using cache
---> 2ce2a438e89d
Successfully built 2ce2a438e89d
Successfully tagged helloworldfunction:nodejs18.x-v1
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
### Création d'une application qui inclut un langage de programmation compilé
Dans cet exemple, nous créons une application contenant une fonction Lambda à l'aide de l'exécution Go.
Tout d'abord, nous initialisons une nouvelle application en utilisant `sam init` et configurons notre application pour qu'elle utilise Go :
```
$ sam init
...
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
...
Template: 1
Use the most popular runtime and package type? (Python and zip) [y/N]: ENTER
Which runtime would you like to use?
...
4 - dotnetcore3.1
5 - go1.x
6 - go (provided.al2)
...
Runtime: 5
What package type would you like to use?
1 - Zip
2 - Image
Package type: 1
Based on your selections, the only dependency manager available is mod.
We will proceed copying the template using mod.
Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER
Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER
Project name [sam-app]: ENTER
Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)
-----------------------
Generating application:
-----------------------
Name: sam-app
Runtime: go1.x
Architectures: x86_64
Dependency Manager: mod
Application Template: hello-world
Output Directory: .
Configuration file: sam-app/samconfig.toml
Next steps can be found in the README file at sam-app-go/README.md
...
```
AWS SAMCLIInitialise ensuite l'application. Voici un exemple de la structure du répertoire de l'application :
```
sam-app
├── Makefile
├── README.md
├── events
│ └── event.json
├── hello-world
│ ├── go.mod
│ ├── go.sum
│ ├── main.go
│ └── main_test.go
├── samconfig.toml
└── template.yaml
```
Nous référençons le fichier `README.md` pour les exigences de cette application.
```
...
## Requirements
* AWS CLI already configured with Administrator permission
* [Docker installed](https://www.docker.com/community-edition)
* [Golang](https://golang.org)
* SAM CLI - [Install the SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)
...
```
Ensuite, nous exécutons `sam local invoke` pour tester notre fonction. Cette commande provoque une erreur, car Go n'est pas installé sur notre machine locale :
```
sam-app $ sam local invoke
Invoking hello-world (go1.x)
Local image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-go1.x
Building image.................................................................................................................................................................................................................................................
Using local image: public.ecr.aws/lambda/go:1-rapid-x86_64.
Mounting /Users/.../Playground/build/sam-app/hello-world as /var/task:ro,delegated inside runtime container
START RequestId: c6c5eddf-042b-4e1e-ba66-745f7c86dd31 Version: $LATEST
fork/exec /var/task/hello-world: no such file or directory: PathError
null
END RequestId: c6c5eddf-042b-4e1e-ba66-745f7c86dd31
REPORT RequestId: c6c5eddf-042b-4e1e-ba66-745f7c86dd31 Init Duration: 0.88 ms Duration: 175.75 ms Billed Duration: 176 ms Memory Size: 128 MB Max Memory Used: 128 MB
{"errorMessage":"fork/exec /var/task/hello-world: no such file or directory","errorType":"PathError"}%
```
Ensuite, nous exécutons `sam build` pour créer notre application. Nous rencontrons une erreur car Go n'est pas installée sur notre machine locale :
```
sam-app $ sam build
Starting Build use cache
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../Playground/build/sam-app/hello-world runtime: go1.x metadata: {} architecture: x86_64 functions: HelloWorldFunction
Build Failed
Error: GoModulesBuilder:Resolver - Path resolution for runtime: go1.x of binary: go was not successful
```
Bien que nous puissions configurer notre machine locale pour créer correctement notre fonction, nous utilisons plutôt l'option `--use-container` avec `sam build`. AWS SAMCLITélécharge une image de conteneur, construit notre fonction en utilisant le natif GoModulesBuilder et copie le binaire obtenu `.aws-sam/build/HelloWorldFunction` dans notre répertoire.
```
sam-app $ sam build --use-container
Starting Build use cache
Starting Build inside a container
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../build/sam-app/hello-world runtime: go1.x metadata: {} architecture: x86_64 functions: HelloWorldFunction
Fetching public.ecr.aws/sam/build-go1.x:latest-x86_64 Docker container image.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Mounting /Users/.../build/sam-app/hello-world as /tmp/samcli/source:ro,delegated inside runtime container
Running GoModulesBuilder:Build
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
Voici un exemple du répertoire `.aws-sam` :
```
.aws-sam
├── build
│ ├── HelloWorldFunction
│ │ └── hello-world
│ └── template.yaml
├── build.toml
├── cache
│ └── c860d011-4147-4010-addb-2eaa289f4d95
│ └── hello-world
└── deps
```
Ensuite, nous exécutons `sam local invoke`. Notre fonction est appelée avec succès :
```
sam-app $ sam local invoke
Invoking hello-world (go1.x)
Local image is up-to-date
Using local image: public.ecr.aws/lambda/go:1-rapid-x86_64.
Mounting /Users/.../Playground/build/sam-app/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated inside runtime container
START RequestId: cfc8ffa8-29f2-49d4-b461-45e8c7c80479 Version: $LATEST
END RequestId: cfc8ffa8-29f2-49d4-b461-45e8c7c80479
REPORT RequestId: cfc8ffa8-29f2-49d4-b461-45e8c7c80479 Init Duration: 1.20 ms Duration: 1782.46 ms Billed Duration: 1783 ms Memory Size: 128 MB Max Memory Used: 128 MB
{"statusCode":200,"headers":null,"multiValueHeaders":null,"body":"Hello, 72.21.198.67\n"}%
```
## En savoir plus
Pour en savoir plus sur l'utilisation de la commande `sam build`, reportez-vous à ce qui suit :
+ **[Learning AWS SAM : sam build](https://www.youtube.com/watch?v=fDhYKp4op_g)** — Série « Learning AWS SAM » de Serverless Land surYouTube.
+ **[Learning AWS SAM \$1 sam build \$1 E3](https://www.youtube.com/watch?v=vsAvRyLnB7Y)** — Serverless Land « Learning AWS SAM » série surYouTube.
+ **[AWS SAM build : comment il fournit des artefacts pour le déploiement (sessions avec SAM S2E8)](https://www.youtube.com/watch?v=bNbBd6XoDHg)** — Sessions avec AWS SAM série activée. YouTube
+ **[AWS SAM versions personnalisées : Comment utiliser les Makefiles pour personnaliser les versions dans SAM (S2E9) — Sessions](https://www.youtube.com/watch?v=wpccutnSbAk)** avec séries activées. AWS SAM YouTube
# 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
```
# Personnalisez les builds avec AWS SAM
Vous pouvez personnaliser votre build pour inclure des fonctions Lambda ou des couches Lambda spécifiques. Une fonction est une ressource que vous pouvez appeler pour exécuter votre code dans Lambda. Une couche Lambda vous permet d'extraire le code d'une fonction Lambda qui peut ensuite être réutilisé dans plusieurs fonctions Lambda. Vous pouvez choisir de personnaliser votre build avec des fonctions Lambda spécifiques lorsque vous souhaitez vous concentrer sur le développement et le déploiement de fonctions sans serveur individuelles sans la complexité liée à la gestion de dépendances ou de ressources partagées. En outre, vous pouvez choisir de créer une couche Lambda pour vous aider à réduire la taille de vos packages de déploiement, à séparer la logique des fonctions de base des dépendances et à partager les dépendances entre plusieurs fonctions.
Les rubriques de cette section explorent certaines des différentes manières de créer des fonctions Lambda. AWS SAM Cela inclut la création de fonctions Lambda avec les environnements d'exécution des clients et la création de couches Lambda. Les environnements d'exécution personnalisés vous permettent d'installer et d'utiliser un langage qui n'est pas répertorié dans les environnements d'exécution Lambda du Guide du développeur. AWS Lambda Cela vous permet de créer un environnement d'exécution spécialisé pour exécuter des fonctions et des applications sans serveur. La création de couches Lambda uniquement (au lieu de créer l'intégralité de votre application) peut vous être bénéfique de plusieurs manières. Cela peut vous aider à réduire la taille de vos packages de déploiement, à séparer la logique des fonctions de base des dépendances et à partager les dépendances entre plusieurs fonctions.
Pour plus d'informations sur les fonctions, consultez les [concepts Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-concepts.html) dans le Guide du *AWS Lambda développeur*.
**Topics**
+ [Création de fonctions Lambda dans Node.js avec esbuild AWS SAM](serverless-sam-cli-using-build-typescript.md)
+ [Création de fonctions Lambda .NET avec une compilation native AOT dans AWS SAM](build-dotnet7.md)
+ [Création de fonctions Rust Lambda avec in Cargo Lambda AWS SAM](building-rust.md)
+ [Création de fonctions Lambda en Python avec in uv AWS SAM](building-python-uv.md)
+ [Création de fonctions Lambda avec des environnements d'exécution personnalisés dans AWS SAM](building-custom-runtimes.md)
+ [Création de couches Lambda dans AWS SAM](building-layers.md)
# Création de fonctions Lambda dans Node.js avec esbuild AWS SAM
Pour créer et empaqueter AWS Lambda les fonctions Node.js, vous pouvez les utiliser AWS SAMCLI avec le JavaScript bundler esbuild. Le bundler esbuild prend en charge les fonctions Lambda que vous écrivez. TypeScript
Pour créer une fonction Lambda Node.js avec esbuild, ajoutez un objet `Metadata` à votre `AWS:Serverless::Function` ressource et spécifiez `esbuild` pour `BuildMethod`. Lorsque vous exécutez la **sam build** commande, AWS SAM utilise esbuild pour regrouper le code de votre fonction Lambda.
## Propriétés de métadonnées
L'objet `Metadata` prend en charge les propriétés suivantes pour esbuild.
### BuildMethod
Spécifie le bundler de votre application. La seule valeur prise en charge est `esbuild`.
### BuildProperties
Spécifie les propriétés de création du code de votre fonction Lambda.
L'objet `BuildProperties` prend en charge les propriétés suivantes pour esbuild. Toutes les propriétés sont facultatives. Par défaut, AWS SAM utilise votre gestionnaire de fonctions Lambda comme point d'entrée.
**EntryPoints**
Spécifie les points d'entrée de votre application.
**Externe**
Spécifie la liste des packages à omettre de la création. Pour plus d'informations, veuillez consulter la section [Externe](https://esbuild.github.io/api/#external) sur le *site Web esbuild* (langue française non garantie).
**Format**
Spécifie le format de sortie des JavaScript fichiers générés dans votre application. Pour plus d'informations, consultez la section [Format](https://esbuild.github.io/api/#format) du *site Web esbuild*.
**Chargeur**
Spécifie la liste des configurations de chargement des données pour un type de fichier donné.
**MainFields**
Spécifie les champs `package.json` à essayer d'importer lors de la résolution d'un package. La valeur par défaut est `main,module`.
**Réduire**
Spécifie s'il faut réduire le code de sortie groupé. La valeur par défaut est `true`.
**OutExtension**
Personnalisez l'extension des fichiers générés par esbuild. Pour plus d'informations, veuillez consulter [Out extension](https://esbuild.github.io/api/#out-extension) sur le *site Web esbuild*.
**Carte source**
Spécifie si le bundler produit un fichier de carte source. La valeur par défaut est `false`.
Lorsqu'il a la valeur `true`, `NODE_OPTIONS: --enable-source-maps` est ajouté aux variables d'environnement de la fonction Lambda, et une carte source est générée et incluse dans la fonction.
Sinon, lorsque `NODE_OPTIONS: --enable-source-maps` est inclus dans les variables d'environnement de la fonction, `Sourcemap` est automatiquement défini sur `true`.
En cas de conflit, `Sourcemap: false` a la priorité sur `NODE_OPTIONS: --enable-source-maps`.
Par défaut, Lambda chiffre toutes les variables d'environnement au repos avec AWS Key Management Service (AWS KMS). Lorsque vous utilisez des cartes sources, pour que le déploiement réussisse, le rôle d'exécution de votre fonction doit avoir l'autorisation d'effectuer l'action `kms:Encrypt`.
**SourcesContent**
Indique s'il faut inclure votre code source dans votre fichier de carte source. Configurez cette propriété lorsque `Sourcemap` est définie sur `'true'`.
+ Spécifiez `SourcesContent: 'true'` pour inclure tout le code source.
+ Spécifiez `SourcesContent: 'false'` pour exclure tout le code source. Cela permet de réduire la taille des fichiers de cartes sources, ce qui est utile en production en réduisant les temps de démarrage. Cependant, le code source ne sera pas disponible dans le débogueur.
La valeur par défaut est `SourcesContent: true`.
Pour plus d'informations, consultez la section [Contenu des sources](https://esbuild.github.io/api/#sources-content) du *site web esbuild*.
**Cible**
Spécifie la ECMAScript version cible. La valeur par défaut est `es2020`.
## TypeScript Exemple de fonction Lambda
L'exemple d'extrait de AWS SAM modèle suivant utilise esbuild pour créer une fonction Lambda Node.js à partir du code dans. TypeScript `hello-world/app.ts`
```
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
Environment:
Variables:
NODE_OPTIONS: --enable-source-maps
Metadata:
BuildMethod: esbuild
BuildProperties:
Format: esm
Minify: false
OutExtension:
- .js=.mjs
Target: "es2020"
Sourcemap: true
EntryPoints:
- app.ts
External:
- ""
```
# Création de fonctions Lambda .NET avec une compilation native AOT dans AWS SAM
Créez et empaquetez vos AWS Lambda fonctions .NET 8 avec le AWS Serverless Application Model (AWS SAM), en utilisant la compilation native Ahead-of-Time (AOT) pour améliorer les temps de démarrage à AWS Lambda froid.
**Topics**
+ [Présentation de .NET 8 Native AOT](#build-dotnet7-overview)
+ [Utilisation AWS SAM avec vos fonctions Lambda .NET 8](#build-dotnet7-sam)
+ [Installer les prérequis](#build-dotnet7-prerequisites)
+ [Définissez les fonctions Lambda .NET 8 dans votre modèle AWS SAM](#build-dotnet7-sam-define)
+ [Créer votre application à l'aide de la CLI AWS SAM](#build-dotnet7-sam-build)
+ [En savoir plus](#build-dotnet7-learn-more)
## Présentation de .NET 8 Native AOT
Historiquement, les fonctions Lambda .NET ont eu des temps de démarrage à froid affectant l'expérience utilisateur, la latence du système et les coûts d'utilisation de vos applications sans serveur. Avec la compilation .NET Native AOT, vous pouvez améliorer les temps de démarrage à froid de vos fonctions Lambda. Pour en savoir plus sur l'AOT natif pour .NET 8, voir [Utilisation de l'AOT natif](https://github.com/dotnet/runtime/tree/main/src/coreclr/nativeaot#readme) dans le référentiel * GitHub Dotnet*.
## Utilisation AWS SAM avec vos fonctions Lambda .NET 8
Procédez comme suit pour configurer vos fonctions Lambda .NET 8 avec le AWS Serverless Application Model ()AWS SAM :
+ Installez les prérequis sur votre machine de développement.
+ Définissez les fonctions Lambda .NET 8 dans votre AWS SAM modèle.
+ Créez votre application à l'aide du AWS SAMCLI.
## Installer les prérequis
Les prérequis sont les suivants :
+ Le AWS SAMCLI
+ La CLI .NET Core
+ L'outil global .NET Core d'Amazon.Lambda.Tools
+ Docker
**Installer la CLI AWS SAM**
1. Pour vérifier si la CLI AWS SAM est déjà installée, procédez comme suit :
```
sam --version
```
1. Pour installer le AWS SAMCLI, voir[Installer la CLI AWS SAM](install-sam-cli.md).
1. Pour mettre à niveau une version installée du AWS SAMCLI, voir[Mise à niveau de la CLI AWS SAM en cours](manage-sam-cli-versions.md#manage-sam-cli-versions-upgrade).
**Installer la CLI .NET Core**
1. Pour télécharger et installer la CLI .NET Core, veuillez consulter la rubrique [Télécharger .NET](https://dotnet.microsoft.com/download) (langue française non garantie) du site web Microsoft.
1. Pour plus d'informations sur la CLI .NET Core, veuillez consulter la rubrique [Interface de ligne de commande .NET Core](https://docs.aws.amazon.com/lambda/latest/dg/csharp-package-cli.html) dans le *Guide du développeur AWS Lambda *.
**Installer l'outil global .NET Core d'Amazon.Lambda.Tools**
1. Exécutez la commande suivante :
```
dotnet tool install -g Amazon.Lambda.Tools
```
1. Si cet outil est déjà installé, vous pouvez vérifier qu'il s'agit de la dernière version avec la commande suivante :
```
dotnet tool update -g Amazon.Lambda.Tools
```
1. Pour plus d'informations sur l'outil global .NET Core d'Amazon.Lambda.Tools, consultez les extensions [AWS pour le référentiel .NET](https://github.com/aws/aws-extensions-for-dotnet-cli) CLI sur. GitHub
**Installer Docker**
+ Docker doit être installé pour permettre la création avec la compilation anticipée native. Pour obtenir des instructions d’installation, consultez [Installation de Docker pour une utilisation avec la CLI AWS SAM](install-docker.md).
## Définissez les fonctions Lambda .NET 8 dans votre modèle AWS SAM
Pour définir un. NET8 Fonction Lambda dans votre AWS SAM modèle, procédez comme suit :
1. Exécutez la commande suivante depuis le répertoire de départ de votre choix :
```
sam init
```
1. Sélectionnez `AWS Quick Start Templates` pour choisir un modèle de départ.
1. Choisissez le modèle `Hello World Example`.
1. Choisissez de ne pas utiliser le moteur d'exécution et le type de package les plus populaires en saisissant`n`.
1. Pour l'exécution, choisissez`dotnet8`.
1. Pour le type de package, choisissez`Zip`.
1. Pour votre modèle de démarrage, choisissez`Hello World Example using native AOT`.
**Installer Docker**
+ Docker doit être installé pour permettre la création avec la compilation anticipée native. Pour obtenir des instructions d’installation, consultez [Installation de Docker pour une utilisation avec la CLI AWS SAM](install-docker.md).
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src/HelloWorldAot/
Handler: bootstrap
Runtime: dotnet8
Architectures:
- x86_64
Events:
HelloWorldAot:
Type: Api
Properties:
Path: /hello
Method: get
```
**Note**
Lorsque la `Event` propriété de an `AWS::Serverless::Function` est définie sur`Api`, mais que la `RestApiId` propriété n'est pas spécifiée, AWS SAM la `AWS::ApiGateway::RestApi` CloudFormation ressource est générée.
## Créer votre application à l'aide de la CLI AWS SAM
Depuis le répertoire racine de votre projet, exécutez la `sam build` commande pour commencer à créer votre application. Si la `PublishAot` propriété a été définie dans votre fichier de projet .NET 8, elle AWS SAMCLI sera compilée avec la compilation native AOT. Pour en savoir plus sur la propriété `PublishAot`, veuillez consulter la rubrique [Déploiement anticipé natif](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/) (langue française non garantie) dans la *documentation .NET* de Microsoft.
Pour créer votre fonction, la CLI AWS SAM invoque la CLI .NET Core qui utilise l'outil global .NET Core d'Amazon.Lambda.Tools.
**Note**
Lors de la création, si un fichier `.sln` existe dans le même répertoire ou dans le répertoire parent de votre projet, le répertoire contenant le fichier `.sln` sera monté dans le conteneur. Si aucun fichier `.sln` n'est trouvé, seul le dossier du projet est monté. Par conséquent, si vous créez une application multi-projets, assurez-vous que le fichier `.sln` est bien localisé.
## En savoir plus
Pour plus d'informations sur la création de fonctions Lambda .NET 8, consultez [Présentation du moteur d'exécution .NET 8](https://aws.amazon.com/blogs/compute/introducing-the-net-8-runtime-for-aws-lambda/) pour. AWS Lambda
Pour obtenir la référence de la commande **sam build**, consultez [sam build](sam-cli-command-reference-sam-build.md).
# Création de fonctions Rust Lambda avec in Cargo Lambda AWS SAM
| |
| --- |
| Cette fonctionnalité est en version préliminaire AWS SAM et est sujette à modification. |
Utilisez l'interface de ligne de AWS Serverless Application Model commande (AWS SAMCLI) avec vos AWS Lambda fonctions Rust.
**Topics**
+ [Conditions préalables](#building-rust-prerequisites)
+ [Configuration AWS SAM à utiliser avec les fonctions Rust Lambda](#building-rust-configure)
+ [Exemples](#building-rust-examples)
## Conditions préalables
**Langage Rust**
Pour installer Rust, consultez la section [Installer Rust](https://www.rust-lang.org/tools/install) sur le *site web du langage Rust*.
**Cargo Lambda**
La CLI AWS SAM nécessite l'installation de [https://www.cargo-lambda.info/guide/what-is-cargo-lambda.html](https://www.cargo-lambda.info/guide/what-is-cargo-lambda.html), une sous-commande pour Cargo. Pour les instructions d'installation, consultez la rubrique [Installation](https://www.cargo-lambda.info/guide/installation.html) dans la *documentation Cargo Lambda*.
**Docker**
La création et le test de fonctions Lambda Rust nécessitent Docker. Pour obtenir des instructions d’installation, consultez [Installation de Docker](install-docker.md).
**Activer la fonctionnalité bêta de la CLI AWS SAM**
Cette fonctionnalité étant en cours de prévisualisation, vous devez l'activer en utilisant l'une des méthodes suivantes :
1. Utiliser la variable d'environnement : `SAM_CLI_BETA_RUST_CARGO_LAMBDA=1`.
1. Ajoutez ce qui suit à votre fichier `samconfig.toml` :
```
[default.build.parameters]
beta_features = true
[default.sync.parameters]
beta_features = true
```
1. Utilisez l'option `--beta-features` lorsque vous utilisez une commande de la CLI AWS SAM prise en charge. Par exemple :
```
$ sam build --beta-features
```
1. Choisissez l'option `y` lorsque la CLI AWS SAM vous y invite. Voici un exemple :
```
$ sam build
Starting Build use cache
Build method "rust-cargolambda" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
```
## Configuration AWS SAM à utiliser avec les fonctions Rust Lambda
### Étape 1 : Configuration de votre AWS SAM modèle
Configurez votre AWS SAM modèle avec les éléments suivants :
+ **Binaire** : facultatif. Spécifiez quand votre modèle contient plusieurs fonctions Lambda Rust.
+ **BuildMethod** – `rust-cargolambda`.
+ **CodeUri**— chemin d'accès à votre `Cargo.toml` fichier.
+ **Gestionnaire** : `bootstrap`.
+ **Exécution** : `provided.al2`.
Pour en savoir plus sur les environnements d'exécution personnalisés, consultez la section [AWS Lambda Runtimes personnalisés](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html) dans le manuel du *AWS Lambda développeur*.
Voici un exemple de AWS SAM modèle configuré :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
BuildProperties: function_a
Properties:
CodeUri: ./rust_app
Handler: bootstrap
Runtime: provided.al2
...
```
### Étape 2 : utiliser la CLI AWS SAM avec votre fonction Lambda Rust
Utilisez n'importe quelle AWS SAMCLI commande avec votre AWS SAM modèle. Pour de plus amples informations, veuillez consulter [AWS SAM CLI](using-sam-cli.md).
## Exemples
### Exemple Hello World
**Dans cet exemple, nous créons l'exemple d'application Hello World en utilisant Rust comme notre exécution.**
Tout d'abord, nous initialisons une nouvelle application sans serveur en utilisant `sam init`. Au cours du flux interactif, nous sélectionnons l'**application Hello World** et choisissons l'exécution **Rust**.
```
$ sam init
...
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
...
Template: 1
Use the most popular runtime and package type? (Python and zip) [y/N]: ENTER
Which runtime would you like to use?
1 - dotnet8
2 - dotnet6
3 - go (provided.al2)
...
18 - python3.11
19 - python3.10
20 - ruby3.3
21 - ruby3.2
22 - rust (provided.al2)
23 - rust (provided.al2023)
Runtime: 22
Based on your selections, the only Package type available is Zip.
We will proceed to selecting the Package type as Zip.
Based on your selections, the only dependency manager available is cargo.
We will proceed copying the template using cargo.
Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER
Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER
Project name [sam-app]: hello-rust
-----------------------
Generating application:
-----------------------
Name: hello-rust
Runtime: rust (provided.al2)
Architectures: x86_64
Dependency Manager: cargo
Application Template: hello-world
Output Directory: .
Configuration file: hello-rust/samconfig.toml
Next steps can be found in the README file at hello-rust/README.md
Commands you can use next
=========================
[*] Create pipeline: cd hello-rust && sam pipeline init --bootstrap
[*] Validate SAM template: cd hello-rust && sam validate
[*] Test Function in the Cloud: cd hello-rust && sam sync --stack-name {stack-name} --watch
```
Voici la structure de notre application Hello World :
```
hello-rust
├── README.md
├── events
│ └── event.json
├── rust_app
│ ├── Cargo.toml
│ └── src
│ └── main.rs
├── samconfig.toml
└── template.yaml
```
Dans notre AWS SAM modèle, notre Rust fonction est définie comme suit :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
Properties:
CodeUri: ./rust_app
Handler: bootstrap
Runtime: provided.al2
Architectures:
- x86_64
Events:
HelloWorld:
Type: Api
Path: /hello
Method: get
```
Ensuite, nous exécutons `sam build` pour créer notre application et préparer son déploiement. La CLI AWS SAM crée un répertoire `.aws-sam` et organise nos artefacts de création. Notre fonction est construite en utilisant Cargo Lambda et stockée sous forme de binaire exécutable à l'emplacement suivant : `.aws-sam/build/HelloWorldFunction/bootstrap`.
**Note**
Si vous envisagez d'exécuter la **sam local invoke** commande sous macOS, vous devez créer des fonctions différentes avant de l'invoquer. Pour ce faire, utilisez la commande suivante :
**SAM\$1BUILD\$1MODE=debug sam build**
Cette commande n'est nécessaire que si des tests locaux doivent être effectués. Cela n'est pas recommandé lors de la création en vue du déploiement.
```
hello-rust$ sam build
Starting Build use cache
Build method "rust-cargolambda" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
Experimental features are enabled for this session.
Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/.
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../hello-rust/rust_app runtime: provided.al2 metadata: {'BuildMethod': 'rust-cargolambda'} architecture: x86_64 functions: HelloWorldFunction
Running RustCargoLambdaBuilder:CargoLambdaBuild
Running RustCargoLambdaBuilder:RustCopyAndRename
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
Ensuite, nous déployons notre application en utilisant `sam deploy --guided`.
```
hello-rust$ sam deploy --guided
Configuring SAM deploy
======================
Looking for config file [samconfig.toml] : Found
Reading default arguments : Success
Setting default arguments for 'sam deploy'
=========================================
Stack Name [hello-rust]: ENTER
AWS Region [us-west-2]: ENTER
#Shows you resources changes to be deployed and require a 'Y' to initiate deploy
Confirm changes before deploy [Y/n]: ENTER
#SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation [Y/n]: ENTER
#Preserves the state of previously provisioned resources when an operation fails
Disable rollback [y/N]: ENTER
HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y
Save arguments to configuration file [Y/n]: ENTER
SAM configuration file [samconfig.toml]: ENTER
SAM configuration environment [default]: ENTER
Looking for resources needed for deployment:
...
Uploading to hello-rust/56ba6585d80577dd82a7eaaee5945c0b 817973 / 817973 (100.00%)
Deploying with following values
===============================
Stack name : hello-rust
Region : us-west-2
Confirm changeset : True
Disable rollback : False
Deployment s3 bucket : aws-sam-cli-managed-default-samclisam-s3-demo-bucket-1a4x26zbcdkqr
Capabilities : ["CAPABILITY_IAM"]
Parameter overrides : {}
Signing Profiles : {}
Initiating deployment
=====================
Uploading to hello-rust/a4fc54cb6ab75dd0129e4cdb564b5e89.template 1239 / 1239 (100.00%)
Waiting for changeset to be created..
CloudFormation stack changeset
---------------------------------------------------------------------------------------------------------
Operation LogicalResourceId ResourceType Replacement
---------------------------------------------------------------------------------------------------------
+ Add HelloWorldFunctionHelloW AWS::Lambda::Permission N/A
orldPermissionProd
...
---------------------------------------------------------------------------------------------------------
Changeset created successfully. arn:aws:cloudformation:us-west-2:012345678910:changeSet/samcli-deploy1681427201/f0ef1563-5ab6-4b07-9361-864ca3de6ad6
Previewing CloudFormation changeset before deployment
======================================================
Deploy this changeset? [y/N]: y
2023-04-13 13:07:17 - Waiting for stack create/update to complete
CloudFormation events from stack operations (refresh every 5.0 seconds)
---------------------------------------------------------------------------------------------------------
ResourceStatus ResourceType LogicalResourceId ResourceStatusReason
---------------------------------------------------------------------------------------------------------
CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole -
CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole Resource creation
...
---------------------------------------------------------------------------------------------------------
CloudFormation outputs from deployed stack
---------------------------------------------------------------------------------------------------------
Outputs
---------------------------------------------------------------------------------------------------------
Key HelloWorldFunctionIamRole
Description Implicit IAM Role created for Hello World function
Value arn:aws:iam::012345678910:role/hello-rust-HelloWorldFunctionRole-10II2P13AUDUY
Key HelloWorldApi
Description API Gateway endpoint URL for Prod stage for Hello World function
Value https://ggdxec9le9.execute-api.us-west-2.amazonaws.com/Prod/hello/
Key HelloWorldFunction
Description Hello World Lambda Function ARN
Value arn:aws:lambda:us-west-2:012345678910:function:hello-rust-HelloWorldFunction-
yk4HzGzYeZBj
---------------------------------------------------------------------------------------------------------
Successfully created/updated stack - hello-rust in us-west-2
```
Pour tester, nous pouvons appeler notre fonction Lambda à l'aide du point de terminaison de l'API.
```
$ curl https://ggdxec9le9.execute-api.us-west-2.amazonaws.com/Prod/hello/
Hello World!%
```
Pour tester notre fonction localement, nous devons d'abord nous assurer que la propriété `Architectures`de notre fonction correspond à notre ordinateur local.
```
...
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
Metadata:
BuildMethod: rust-cargolambda # More info about Cargo Lambda: https://github.com/cargo-lambda/cargo-lambda
Properties:
CodeUri: ./rust_app # Points to dir of Cargo.toml
Handler: bootstrap # Do not change, as this is the default executable name produced by Cargo Lambda
Runtime: provided.al2
Architectures:
- arm64
...
```
Comme nous avons modifié notre architecture en passant de `x86_64` à `arm64` dans cet exemple, nous exécutons `sam build` pour mettre à jour nos artefacts de création. Nous exécutons ensuite `sam local invoke` pour appeler notre fonction localement.
```
hello-rust$ sam local invoke
Invoking bootstrap (provided.al2)
Local image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-provided.al2
Building image.....................................................................................................................................
Using local image: public.ecr.aws/lambda/provided:al2-rapid-arm64.
Mounting /Users/.../hello-rust/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated, inside runtime container
START RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 Version: $LATEST
{"statusCode":200,"body":"Hello World!"}END RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6
REPORT RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 Init Duration: 0.68 ms Duration: 130.63 ms Billed Duration: 131 ms Memory Size: 128 MB Max Memory Used: 128 MB
```
### Projet de fonction Lambda unique
**Voici un exemple d'application sans serveur contenant une fonction Lambda Rust.**
Structure du répertoire du projet :
```
.
├── Cargo.lock
├── Cargo.toml
├── src
│ └── main.rs
└── template.yaml
```
AWS SAM modèle :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
Properties:
CodeUri: ./
Handler: bootstrap
Runtime: provided.al2
...
```
### Projet de fonctions Lambda multiples
**Voici un exemple d'application sans serveur contenant plusieurs fonctions Lambda Rust.**
Structure du répertoire du projet :
```
.
├── Cargo.lock
├── Cargo.toml
├── src
│ ├── function_a.rs
│ └── function_b.rs
└── template.yaml
```
AWS SAM modèle :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
FunctionA:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
BuildProperties:
Binary: function_a
Properties:
CodeUri: ./
Handler: bootstrap
Runtime: provided.al2
FunctionB:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
BuildProperties:
Binary: function_b
Properties:
CodeUri: ./
Handler: bootstrap
Runtime: provided.al2
```
Fichier `Cargo.toml` :
```
[package]
name = "test-handler"
version = "0.1.0"
edition = "2021"
[dependencies]
lambda_runtime = "0.6.0"
serde = "1.0.136"
tokio = { version = "1", features = ["macros"] }
tracing = { version = "0.1", features = ["log"] }
tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
[[bin]]
name = "function_a"
path = "src/function_a.rs"
[[bin]]
name = "function_b"
path = "src/function_b.rs"
```
# Création de fonctions Lambda en Python avec in uv AWS SAM
| |
| --- |
| Cette fonctionnalité est en version préliminaire AWS SAM et est sujette à modification. |
Utilisez l'interface de ligne de AWS Serverless Application Model commande (AWS SAMCLI) avecuv, un installateur et un résolveur rapides de paquets Python, pour créer vos AWS Lambda fonctions Python.
**Topics**
+ [Conditions préalables](#building-python-uv-prerequisites)
+ [Configuration AWS SAM à utiliser avec les fonctions Lambda en Python et uv](#building-python-uv-configure)
+ [Exemples](#building-python-uv-examples)
## Conditions préalables
**Python**
Pour installer Python, consultez [la section Télécharger Python](https://www.python.org/downloads/) sur le *site Web de Python*.
**uv**
AWS SAMCLINécessite l'installation d'[https://docs.astral.sh/uv/](https://docs.astral.sh/uv/)un programme d'installation et d'un résolveur de paquets Python extrêmement rapides. Pour les instructions d'installation, consultez la rubrique [Installation](https://docs.astral.sh/uv/getting-started/installation/) dans la *documentation uv*.
**Activer la fonctionnalité bêta de la CLI AWS SAM**
Cette fonctionnalité étant en cours de prévisualisation, vous devez l'activer en utilisant l'une des méthodes suivantes :
1. Utiliser la variable d'environnement : `SAM_CLI_BETA_PYTHON_UV=1`.
1. Ajoutez ce qui suit à votre fichier `samconfig.toml` :
```
[default.build.parameters]
beta_features = true
[default.sync.parameters]
beta_features = true
```
1. Utilisez l'option `--beta-features` lorsque vous utilisez une commande de la CLI AWS SAM prise en charge. Par exemple :
```
$ sam build --beta-features
```
1. Choisissez l'option `y` lorsque la CLI AWS SAM vous y invite. Voici un exemple :
```
$ sam build
Starting Build use cache
Build method "python-uv" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
```
## Configuration AWS SAM à utiliser avec les fonctions Lambda en Python et uv
### Étape 1 : Configuration de votre AWS SAM modèle
Configurez votre AWS SAM modèle avec les éléments suivants :
+ **BuildMethod** – `python-uv`.
+ **CodeUri**— chemin d'accès au répertoire de votre code de fonction contenant `pyproject.toml` ou`requirements.txt`.
+ **Handler** — votre gestionnaire de fonctions (par exemple,`app.lambda_handler`).
+ **Runtime** — Version d'exécution de Python (par exemple,`python3.12`).
Voici un exemple de AWS SAM modèle configuré :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./my_function
Handler: app.lambda_handler
Runtime: python3.12
Metadata:
BuildMethod: python-uv
...
```
## Exemples
### Exemple Hello World
**Dans cet exemple, nous créons un exemple d'application Hello World en utilisant Python uv comme gestionnaire de packages.**
uvpeut utiliser l'un `pyproject.toml` ou l'autre ou `requirements.txt` pour lire les dépendances. Si les deux sont fournis, `sam build` je lirai depuis `requirements.txt` pour les dépendances.
Voici la structure de notre application Hello World :
```
hello-python-uv
├── README.md
├── events
│ └── event.json
├── hello_world
│ ├── __init__.py
│ ├── app.py
│ └── pyproject.toml
├── samconfig.toml
└── template.yaml
```
Fichier `pyproject.toml` :
```
[project]
name = "my-function"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
"requests>=2.31.0",
"boto3>=1.28.0",
]
```
Dans notre AWS SAM modèle, notre fonction Python est définie comme suit :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.12
Architectures:
- x86_64
Metadata:
BuildMethod: python-uv
```
Ensuite, nous exécutons `sam build` pour créer notre application et préparer son déploiement. La CLI AWS SAM crée un répertoire `.aws-sam` et organise nos artefacts de création. Nos dépendances fonctionnelles sont installées à uv l'aide de`.aws-sam/build/HelloWorldFunction/`.
```
hello-python-uv$ sam build
Starting Build use cache
Build method "python-uv" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
Experimental features are enabled for this session.
Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/.
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../hello-python-uv/hello_world runtime: python3.12 metadata: {'BuildMethod': 'python-uv'} architecture: x86_64 functions: HelloWorldFunction
Running PythonUvBuilder:UvBuild
Running PythonUvBuilder:CopySource
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
**Note**
La méthode de `python-uv` construction est configurée par fonction dans la `Metadata` section. Chaque fonction de votre modèle peut utiliser une méthode de construction différente, ce qui vous permet de mélanger des fonctions uv `pip` basées avec des fonctions basées dans le même AWS SAM modèle. Si aucune méthode de construction n'est spécifiée, elle `pip` est utilisée par défaut.
# Création de fonctions Lambda avec des environnements d'exécution personnalisés dans AWS SAM
Vous pouvez utiliser la commande `sam build` pour créer des exécutions personnalisées requises pour votre fonction Lambda. Vous déclarez votre fonction Lambda pour utiliser une exécution personnalisée en spécifiant `Runtime: provided` pour la fonction.
Pour créer une exécution personnalisée, déclarez l'attribut de ressource `Metadata` avec une entrée `BuildMethod: makefile`. Vous fournissez un makefile personnalisé, où vous déclarez une cible de génération du formulaire `build-function-logical-id` qui contient les commandes de création de votre exécution. Votre makefile est responsable de la compilation de l'exécution personnalisée si nécessaire, et de la copie des artefacts de construction dans l'emplacement approprié requis pour les étapes suivantes de votre flux. L'emplacement du makefile est spécifié par la propriété `CodeUri` de la ressource de fonction, et doit être nommé `Makefile`.
## Exemples
### Exemple 1 : exécution personnalisée pour une fonction écrite en Rust
**Note**
Nous vous recommandons de créer des fonctions Lambda avec Cargo Lambda. Pour en savoir plus, veuillez consulter la section [Création de fonctions Rust Lambda avec in Cargo Lambda AWS SAM](building-rust.md).
Le AWS SAM modèle suivant déclare une fonction qui utilise un environnement d'exécution personnalisé pour une fonction Lambda écrite en Rust et demande d'exécuter les `sam build` commandes pour la `build-HelloRustFunction` cible de construction.
```
Resources:
HelloRustFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: HelloRust
Handler: bootstrap.is.real.handler
Runtime: provided
MemorySize: 512
CodeUri: .
Metadata:
BuildMethod: makefile
```
Le makefile suivant contient la cible de génération et les commandes qui seront exécutées. Notez que la propriété `CodeUri` est définie sur `.`. Le makefile doit donc se trouver dans le répertoire racine du projet (c'est-à-dire dans le même répertoire que le fichier de modèle de l'application AWS SAM ). Le nom de fichier doit être `Makefile`.
```
build-HelloRustFunction:
cargo build --release --target x86_64-unknown-linux-musl
cp ./target/x86_64-unknown-linux-musl/release/bootstrap $(ARTIFACTS_DIR)
```
Pour de plus amples informations sur la configuration de votre environnement de développement afin d'exécuter la commande `cargo build` dans le `makefile` précédent, consultez l'article de blog [Exécution Rust pour AWS Lambda](https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/).
### Exemple 2 : générateur de fichiers Makefile pour Python3.12 (alternative à l'utilisation du générateur groupé)
Vous pouvez utiliser une bibliothèque ou un module qui n'est pas inclus dans un générateur groupé. Cet exemple montre un AWS SAM modèle pour un environnement d'exécution Python3.12 avec un générateur de makefile.
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.12
Metadata:
BuildMethod: makefile
```
Le makefile suivant contient la cible de génération et les commandes qui seront exécutées. Notez que la propriété `CodeUri` est définie sur `hello_world`. Le makefile doit donc se trouver dans la racine du répertoire `hello_world`, et le nom de fichier doit être `Makefile`.
```
build-HelloWorldFunction:
cp *.py $(ARTIFACTS_DIR)
cp requirements.txt $(ARTIFACTS_DIR)
python -m pip install -r requirements.txt -t $(ARTIFACTS_DIR)
rm -rf $(ARTIFACTS_DIR)/bin
```
# Création de couches Lambda dans AWS SAM
Vous pouvez l'utiliser AWS SAM pour créer des couches Lambda personnalisées. Les couches Lambda vous permettent d'extraire le code d'une fonction Lambda qui peut ensuite être réutilisé dans plusieurs fonctions Lambda. La création de couches Lambda uniquement (au lieu de créer l'intégralité de votre application) peut vous être bénéfique de plusieurs manières. Cela peut vous aider à réduire la taille de vos packages de déploiement, à séparer la logique des fonctions de base des dépendances et à partager les dépendances entre plusieurs fonctions. Pour davantage d'informations sur les couches, consultez [Couches Lambda AWS](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) dans le *Guide du développeur AWS Lambda *.
## Comment créer une couche Lambda dans AWS SAM
**Note**
Avant de créer une couche Lambda, vous devez d'abord écrire une couche Lambda dans votre modèle. AWS SAM Pour obtenir des informations et des exemples à ce sujet, consultez[Améliorez l'efficacité en utilisant les couches Lambda avec AWS SAM](serverless-sam-cli-layers.md).
Pour créer une couche personnalisée, déclarez-la dans votre fichier modèle AWS Serverless Application Model (AWS SAM) et incluez une section d'attribut de `Metadata` ressource avec une `BuildMethod` entrée. Les valeurs valides pour `BuildMethod` sont des identifiants pour une [exécution AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html), ou `makefile`. Incluez une entrée `BuildArchitecture` pour préciser les architectures de jeux d'instructions prises en charge par votre couche. Les valeurs valides pour `BuildArchitecture` sont [Architectures du jeu d'instructions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html).
Si vous spécifiez `makefile`, vous fournissez un makefile personnalisé, où vous déclarez une cible de génération du formulaire `build-layer-logical-id` qui contient les commandes de création de votre couche. Votre makefile est responsable de la compilation de la couche si nécessaire, et de la copie des artefacts de construction dans l'emplacement approprié requis pour les étapes suivantes de votre flux. L'emplacement du makefile est spécifié par la propriété `ContentUri` de la ressource de couche, et doit être nommé `Makefile`.
**Note**
Lorsque vous créez une couche personnalisée, AWS Lambda cela dépend des variables d'environnement pour trouver votre code de couche. Les exécutions Lambda incluent des chemins dans le répertoire `/opt` dans lequel votre code de couche est copié. La structure de dossier d'artefact de construction de votre projet doit correspondre à la structure de dossier attendue de l'exécution pour que votre code de couche personnalisé puisse être trouvé.
Par exemple, pour Python, vous pouvez placer votre code dans le sous-répertoire `python/`. Pour NodeJS, vous pouvez placer votre code dans le sous-répertoire `nodejs/node_modules/`.
Pour de plus amples informations, consultez [Inclusion de dépendances de bibliothèques dans une couche](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-path) dans le *Guide du développeur AWS Lambda *.
Voici un exemple de section d'attribut de ressource `Metadata`.
```
Metadata:
BuildMethod: python3.12
BuildArchitecture: arm64
```
**Note**
Si vous n'incluez pas la section `Metadata` des attributs de ressource, AWS SAM cela ne crée pas la couche. Au lieu de cela, il copie les artefacts de construction à partir de l'emplacement spécifié dans la propriété `CodeUri` de la ressource de couche. Pour plus d'informations, consultez la propriété [ContentUri](sam-resource-layerversion.md#sam-layerversion-contenturi) du type de ressource `AWS::Serverless::LayerVersion`.
Lorsque vous incluez la section `Metadata` des attributs de ressource, vous pouvez utiliser la `sam build` commande pour créer la couche, à la fois en tant qu'objet indépendant ou en tant que dépendance d'une AWS Lambda fonction.
+ ****En tant qu'objet indépendant.**** Vous pouvez souhaiter créer uniquement l'objet de la couche, par exemple si vous testez localement une modification de code de la couche et que vous n'avez pas besoin de créer l'ensemble de votre application. Pour créer la couche indépendamment, spécifiez la ressource de couche à l'aide de la commande `sam build layer-logical-id`.
+ **En tant que dépendance d'une fonction Lambda.** Lorsque vous incluez l'ID logique d'une couche dans la propriété `Layers` d'une fonction Lambda dans le même fichier modèle AWS SAM , la couche sera une dépendance de cette fonction Lambda. Lorsque cette couche inclut également une section d'attribut de ressource `Metadata` avec une entrée `BuildMethod`, vous créez la couche soit en créant la totalité de l'application à l'aide de l'option `sam build` ou en spécifiant la ressource de fonction avec la commande `sam build function-logical-id`.
## Exemples
### Exemple de modèle 1 : création d'une couche dans l'environnement d'exécution Python 3.12
L'exemple de AWS SAM modèle suivant crée une couche sur l'environnement d'exécution Python 3.12.
```
Resources:
MyLayer:
Type: AWS::Serverless::LayerVersion
Properties:
ContentUri: my_layer
CompatibleRuntimes:
- python3.12
Metadata:
BuildMethod: python3.12 # Required to have AWS SAM build this layer
```
### Exemple de modèle 2 : création d'une couche à l'aide d'un makefile personnalisé
L'exemple de AWS SAM modèle suivant utilise un modèle personnalisé `makefile` pour créer la couche.
```
Resources:
MyLayer:
Type: AWS::Serverless::LayerVersion
Properties:
ContentUri: my_layer
CompatibleRuntimes:
- python3.12
Metadata:
BuildMethod: makefile
```
Le `makefile` suivant contient la cible de génération et les commandes qui seront exécutées. Notez que la propriété `ContentUri` est définie sur `my_layer`. Le makefile doit donc se trouver dans la racine du répertoire `my_layer`, et le nom de fichier doit être `Makefile`. Notez également que les artefacts de construction sont copiés dans le `python/` sous-répertoire afin que AWS Lambda celui-ci puisse trouver le code de couche.
```
build-MyLayer:
mkdir -p "$(ARTIFACTS_DIR)/python"
cp *.py "$(ARTIFACTS_DIR)/python"
python -m pip install -r requirements.txt -t "$(ARTIFACTS_DIR)/python"
```
**Note**
Lorsque le `makefile` est appelé, la cible appropriée est déclenchée et les artefacts doivent être copiés dans la variable environnementale exposée`$ARTIFACTS_DIR`. Pour plus d'informations, reportez-vous [aws-lambda-builders à GitHub](https://github.com/aws/aws-lambda-builders/blob/develop/aws_lambda_builders/workflows/custom_make/DESIGN.md).
### Exemple de commandes de création sam
Procédez comme suit : les commandes `sam build` créent des couches qui incluent la section d'attribut de ressource `Metadata`.
```
# Build the 'layer-logical-id' resource independently
$ sam build layer-logical-id
# Build the 'function-logical-id' resource and layers that this function depends on
$ sam build function-logical-id
# Build the entire application, including the layers that any function depends on
$ sam build
```