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éation de fonctions Lambda avec Go
Go est implémenté différemment des autres exécutions gérées. Go se compilant nativement en un binaire exécutable, il n’a pas besoin d’un environnement d’exécution dédié au langage. Utilisez un [environnement d’exécution réservé au système d’exploitation](runtimes-provided.md) (la famille d’environnement d’exécution `provided`) pour déployer les fonctions Go sur Lambda.
**Topics**
+ [
## Prise en charge de l’exécution Go
](#golang-al1)
+ [
## Outils et bibliothèques
](#golang-libraries)
+ [
# Définition du gestionnaire de fonction Lambda dans Go
](golang-handler.md)
+ [
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Go
](golang-context.md)
+ [
# Déployer des fonctions Lambda Go avec des archives de fichiers .zip
](golang-package.md)
+ [
# Déployer des fonctions Lambda Go avec des images conteneurs
](go-image.md)
+ [
# Utilisation de couches pour les fonctions Lambda Go
](golang-layers.md)
+ [
# Journalisation et surveillance des fonctions Lambda Go
](golang-logging.md)
+ [
# Instrumentation du code Go AWS Lambda
](golang-tracing.md)
## Prise en charge de l’exécution Go
L’environnement d’exécution géré par Go 1.x pour Lambda est [obsolète](lambda-runtimes.md#runtime-support-policy). Si vous utilisez l’environnement d’exécution Go 1.x, vous devez transférer vos fonctions vers `provided.al2023` ou `provided.al2`. Les environnements d'`provided.al2`exécution `provided.al2023` et offrent plusieurs avantages`go1.x`, notamment la prise en charge de l'architecture arm64 (processeurs AWS Graviton2), des fichiers binaires plus petits et des temps d'appel légèrement plus rapides.
Aucune modification du code n’est requise pour cette migration. Les seules modifications requises concernent la façon dont vous créez votre package de déploiement et l’exécution que vous utilisez pour créer votre fonction. *Pour plus d'informations, consultez la section [Migration des AWS Lambda fonctions de l'environnement d'exécution Go1.x vers le runtime personnalisé sur Amazon Linux 2](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/) sur le AWS blog Compute.*
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Exécution réservée au système d’exploitation | `provided.al2023` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Exécution réservée au système d’exploitation | `provided.al2` | Amazon Linux 2 | 31 juillet 2026 | 31 août 2026 | 30 sept. 2026 |
## Outils et bibliothèques
Lambda fournit les outils et bibliothèques suivants pour l’environnement d’exécution Go :
+ [AWS SDK pour Go v2](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2) : Le AWS SDK officiel pour le langage de programmation Go.
+ [github. com/aws/aws-lambda-go/lambda](https://github.com/aws/aws-lambda-go/tree/master/lambda): L'implémentation du modèle de programmation Lambda pour Go. Ce package est utilisé AWS Lambda pour appeler votre [gestionnaire](golang-handler.md).
+ [github. com/aws/aws-lambda-go/lambdacontext](https://github.com/aws/aws-lambda-go/tree/master/lambdacontext): aides pour accéder aux informations contextuelles à partir de l'[objet de contexte](golang-context.md).
+ [github. com/aws/aws-lambda-go/events](https://github.com/aws/aws-lambda-go/tree/master/events): Cette bibliothèque fournit des définitions de type pour les intégrations de sources d'événements courantes.
+ [github. com/aws/aws-lambda-go/cmd/build-lambda-zip](https://github.com/aws/aws-lambda-go/tree/master/cmd/build-lambda-zip) : Cet outil peut être utilisé pour créer une archive de fichiers .zip sous Windows.
Pour plus d'informations, voir [aws-lambda-go](https://github.com/aws/aws-lambda-go)ci-dessous GitHub.
Lambda fournit les exemples d'applications suivants pour l'environnement d'exécution Go :
**Exemples d’applications Lambda en Go**
+ [go-al2](https://github.com/aws-samples/sessions-with-aws-sam/tree/master/go-al2) – Une fonction Hello World qui renvoie l’adresse IP publique. Cette application utilise l’exécution personnalisée `provided.al2`.
+ [blank-go](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-go) — Une fonction Go qui montre l'utilisation des bibliothèques Go de Lambda, de la journalisation, des variables d'environnement et du SDK. AWS Cette application utilise l’exécution `go1.x`.
# Définition du gestionnaire de fonction Lambda dans Go
Le *gestionnaire* de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.
Cette page explique comment utiliser les gestionnaires de fonctions Lambda dans Go, notamment la configuration du projet, les conventions de dénomination et les pratiques exemplaires. Cette page inclut également un exemple de fonction Lambda Go qui collecte des informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon Simple Storage Service (Amazon S3). Pour plus d’informations sur le déploiement de votre fonction après l’avoir écrite, consultez [Déployer des fonctions Lambda Go avec des archives de fichiers .zip](golang-package.md) ou [Déployer des fonctions Lambda Go avec des images conteneurs](go-image.md).
**Topics**
+ [
## Configuration de votre projet de gestionnaire Go
](#golang-handler-setup)
+ [
## Exemple de fonction Lambda Go
](#golang-example-code)
+ [
## Convention de nommage du gestionnaire
](#golang-handler-naming)
+ [
## Définition et accès à l’objet d’événement d’entrée
](#golang-example-input)
+ [
## Accès et utilisation de l’objet de contexte Lambda
](#golang-example-context)
+ [
## Signatures de gestionnaire valides pour les gestionnaires Go
](#golang-handler-signatures)
+ [
## Utilisation de l’AWS SDK pour Go v2 dans votre gestionnaire
](#golang-example-sdk-usage)
+ [
## Accès aux variables d’environnement
](#golang-example-envvars)
+ [
## Utilisation de l'état global
](#golang-handler-state)
+ [
## Pratiques exemplaires en matière de code pour les fonctions Lambda Go
](#go-best-practices)
## Configuration de votre projet de gestionnaire Go
Une fonction Lambda écrite en [Go](https://golang.org/) est créée en tant qu'exécutable Go. Vous pouvez initialiser un projet de fonction Lambda Go de la même manière que vous initialisez n’importe quel autre projet Go à l’aide de la commande suivante : `go mod init`
```
go mod init example-go
```
Ici, `example-go` est le nom du module. Vous pouvez le remplacer par n’importe quelle valeur. Cette commande initialise votre projet et génère le fichier `go.mod` répertoriant les dépendances de votre projet.
Utilisez la commande `go get` pour ajouter des dépendances externes à votre projet. Par exemple, pour toutes les fonctions Lambda en Go, vous devez inclure le package [github.com/aws/aws-lambda-go/lambda](https://github.com/aws/aws-lambda-go/tree/master/lambda), qui met en œuvre le modèle de programmation Lambda pour Go. Installez ce package à l’aide de la commande `go get` suivante :
```
go get github.com/aws/aws-lambda-go
```
Le code de votre fonction doit résider dans un fichier Go. Dans l’exemple suivant, nous nommons ce fichier `main.go`. Dans ce fichier, vous implémentez la logique de votre fonction de base dans une méthode de gestion, ainsi que dans une fonction `main()` qui appelle ce gestionnaire.
## Exemple de fonction Lambda Go
L’exemple de code de fonction Lambda Go suivant prend en compte les informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon S3.
**Example Fonction Lambda `main.go`**
```
package main
import (
"context"
"encoding/json"
"fmt"
"log"
"os"
"strings"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/s3"
)
type Order struct {
OrderID string `json:"order_id"`
Amount float64 `json:"amount"`
Item string `json:"item"`
}
var (
s3Client *s3.Client
)
func init() {
// Initialize the S3 client outside of the handler, during the init phase
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
log.Fatalf("unable to load SDK config, %v", err)
}
s3Client = s3.NewFromConfig(cfg)
}
func uploadReceiptToS3(ctx context.Context, bucketName, key, receiptContent string) error {
_, err := s3Client.PutObject(ctx, &s3.PutObjectInput{
Bucket: &bucketName,
Key: &key,
Body: strings.NewReader(receiptContent),
})
if err != nil {
log.Printf("Failed to upload receipt to S3: %v", err)
return err
}
return nil
}
func handleRequest(ctx context.Context, event json.RawMessage) error {
// Parse the input event
var order Order
if err := json.Unmarshal(event, &order); err != nil {
log.Printf("Failed to unmarshal event: %v", err)
return err
}
// Access environment variables
bucketName := os.Getenv("RECEIPT_BUCKET")
if bucketName == "" {
log.Printf("RECEIPT_BUCKET environment variable is not set")
return fmt.Errorf("missing required environment variable RECEIPT_BUCKET")
}
// Create the receipt content and key destination
receiptContent := fmt.Sprintf("OrderID: %s\nAmount: $%.2f\nItem: %s",
order.OrderID, order.Amount, order.Item)
key := "receipts/" + order.OrderID + ".txt"
// Upload the receipt to S3 using the helper method
if err := uploadReceiptToS3(ctx, bucketName, key, receiptContent); err != nil {
return err
}
log.Printf("Successfully processed order %s and stored receipt in S3 bucket %s", order.OrderID, bucketName)
return nil
}
func main() {
lambda.Start(handleRequest)
}
```
Ce fichier `main.go` comprend les sections suivantes :
+ `package main` : dans Go, le package contenant votre fonction `func main()` doit toujours être nommé `main`.
+ Bloc `import` : utilisez ce bloc pour inclure les bibliothèques que votre fonction Lambda requiert.
+ Bloc `type Order struct {}` : définissez la forme de l’événement d’entrée attendu dans cette structure Go.
+ Bloc `var ()` : utilisez ce bloc pour définir les variables globales que vous utiliserez dans votre fonction Lambda.
+ `func init() {}` : incluez tout code que vous voulez que Lambda exécute pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib) dans cette méthode `init()`.
+ `func uploadReceiptToS3(...) {}` : il s’agit d’une méthode auxiliaire référencée par la méthode de gestion principale `handleRequest`.
+ `func handleRequest(ctx context.Context, event json.RawMessage) error {}` : il s’agit de la **méthode de gestion principale**, qui contient la logique principale de votre application.
+ `func main() {}` : il s’agit d’un point d’entrée obligatoire pour votre gestionnaire Lambda. L’argument de la méthode `lambda.Start()` est votre méthode de gestion principale.
Pour que cette fonction fonctionne correctement, son [rôle d’exécution](lambda-intro-execution-role.md) doit autoriser l’action `s3:PutObject`. Assurez-vous également de définir la variable d’environnement `RECEIPT_BUCKET`. Après une invocation réussie, le compartiment Amazon S3 doit contenir un fichier de reçu.
## Convention de nommage du gestionnaire
Pour les fonctions Lambda dans Go, vous pouvez utiliser n’importe quel nom pour le gestionnaire. Dans cet exemple, le nom de la méthode de traitement est `handleRequest`. Pour référencer la valeur du gestionnaire dans votre code, vous pouvez utiliser la variable d'environnement `_HANDLER`.
Pour les fonctions Go qui utilisent l’exécution dans un [package de déploiement .zip](golang-package.md), le fichier exécutable qui contient le code de votre fonction doit être nommé `bootstrap`. De plus, le fichier `bootstrap` doit se trouver à la racine du fichier .zip. Pour les fonctions Go déployées à l’aide d’une [image de conteneur](go-image.md#go-image-provided), vous pouvez utiliser n’importe quel nom pour le fichier exécutable.
## Définition et accès à l’objet d’événement d’entrée
JSON est le format d’entrée le plus courant et standard pour les fonctions Lambda. Dans cet exemple, la fonction exige une entrée similaire à l’exemple suivant :
```
{
"order_id": "12345",
"amount": 199.99,
"item": "Wireless Headphones"
}
```
Lorsque vous utilisez des fonctions Lambda dans Go, vous pouvez définir la forme de l’événement d’entrée attendu sous la forme d’une structure Go. Dans cet exemple, nous définissons une structure pour représenter un `Order` :
```
type Order struct {
OrderID string `json:"order_id"`
Amount float64 `json:"amount"`
Item string `json:"item"`
}
```
Cette structure correspond à la forme d’entrée attendue. Après avoir défini votre structure, vous pouvez écrire une signature de gestionnaire qui utilise un type JSON générique compatible avec la [bibliothèque standard encoding/json](https://pkg.go.dev/encoding/json). Vous pouvez ensuite le désérialiser dans votre structure à l’aide de la fonction [func Unmarshal](https://golang.org/pkg/encoding/json/#Unmarshal). Ceci est illustré dans les premières lignes du gestionnaire :
```
func handleRequest(ctx context.Context, event json.RawMessage) error {
// Parse the input event
var order Order
if err := json.Unmarshal(event, &order); err != nil {
log.Printf("Failed to unmarshal event: %v", err)
return err
...
}
```
Après cette désérialisation, vous pouvez accéder aux champs de la variable `order`. Par exemple, `order.OrderID` récupère la valeur de `"order_id"` à partir de l’entrée d’origine.
**Note**
Le package `encoding/json` ne peut accéder qu’aux champs exportés. Pour être exportées, les noms de champs de la structure d'événement doivent être en majuscules.
## Accès et utilisation de l’objet de contexte Lambda
L’[objet de contexte](golang-context.md) Lambda contient des informations sur l’invocation, la fonction et l’environnement d’exécution. Dans cet exemple, nous avons déclaré cette variable comme `ctx` dans la signature du gestionnaire :
```
func handleRequest(ctx context.Context, event json.RawMessage) error {
...
}
```
L’entrée `ctx context.Context` est un argument facultatif dans votre gestionnaire de fonctions. Pour plus d’informations sur les signatures de gestionnaire acceptées, consultez [Signatures de gestionnaire valides pour les gestionnaires Go](#golang-handler-signatures).
Si vous appelez d’autres services à l’aide du kit SDK AWS, l’objet de contexte est requis dans quelques domaines clés. Par exemple, pour initialiser correctement vos clients SDK, vous pouvez charger la configuration du kit SDK AWS appropriée à l’aide de l’objet de contexte comme suit :
```
// Load AWS SDK configuration using the default credential provider chain
cfg, err := config.LoadDefaultConfig(ctx)
```
Les appels du kit SDK eux-mêmes peuvent nécessiter l’objet de contexte comme entrée. Par exemple, l’appel `s3Client.PutObject` accepte l’objet de contexte comme premier argument :
```
// Upload the receipt to S3
_, err = s3Client.PutObject(ctx, &s3.PutObjectInput{
...
})
```
En dehors des requêtes du kit SDK AWS, vous pouvez également utiliser l’objet de contexte pour surveiller les fonctions. Pour plus d’informations sur la copie d’objets, consultez [Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Go](golang-context.md).
## Signatures de gestionnaire valides pour les gestionnaires Go
Vous disposez de plusieurs options lorsque vous créez un gestionnaire de fonction Lambda dans Go, mais vous devez respecter les règles suivantes :
+ Le gestionnaire doit être une fonction.
+ Le gestionnaire peut accepter entre 0 et 2 arguments. S'il y a deux arguments, le premier argument doit implémenter `context.Context`.
+ Le gestionnaire peut retourner entre 0 et 2 arguments. S'il y a une seule valeur renvoyée, elle doit implémenter `error`. S'il y a deux valeurs renvoyées, la seconde valeur doit implémenter `error`.
Voici la liste des signatures de gestionnaire valides. `TIn` et `TOut` représentent des types compatibles avec la bibliothèque *encoding/json* standard. Pour en savoir plus, reportez-vous à la section [func Unmarshal](https://golang.org/pkg/encoding/json/#Unmarshal) pour savoir comment ces types sont désérialisés.
+
```
func ()
```
+
```
func () error
```
+
```
func () (TOut, error)
```
+
```
func (TIn) error
```
+
```
func (TIn) (TOut, error)
```
+
```
func (context.Context) error
```
+
```
func (context.Context) (TOut, error)
```
+
```
func (context.Context, TIn) error
```
+
```
func (context.Context, TIn) (TOut, error)
```
## Utilisation de l’AWS SDK pour Go v2 dans votre gestionnaire
Vous utiliserez souvent les fonctions Lambda pour interagir avec d’autres ressources AWS ou pour les mettre à jour. Le moyen le plus simple d’interagir avec ces ressources est d’utiliser l’[AWS SDK pour Go v2](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2).
**Note**
L’AWS SDK pour Go (v1) est en mode de maintenance et atteindra la fin du support le 31 juillet 2025. Nous vous recommandons de n’utiliser que l’AWS SDK pour Go v2 à l’avenir.
Pour ajouter des dépendances au SDK à votre fonction, utilisez la commande `go get` correspondant aux clients SDK spécifiques dont vous avez besoin. Dans l’exemple de code précédent, nous avons utilisé les bibliothèques `config` et `s3`. Ajoutez ces dépendances en exécutant les commandes suivantes dans le répertoire qui contient vos fichiers `go.mod` et `main.go ` :
```
go get github.com/aws/aws-sdk-go-v2/config
go get github.com/aws/aws-sdk-go-v2/service/s3
```
Importez ensuite les dépendances en conséquence dans le bloc d’importation de votre fonction :
```
import (
...
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/s3"
)
```
Lorsque vous utilisez le kit SDK dans votre gestionnaire, configurez vos clients avec les bons paramètres. La méthode la plus simple consiste à utiliser la [chaîne de fournisseurs d’informations d’identification par défaut](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain). Cet exemple illustre une manière de charger cette configuration :
```
// Load AWS SDK configuration using the default credential provider chain
cfg, err := config.LoadDefaultConfig(ctx)
if err != nil {
log.Printf("Failed to load AWS SDK config: %v", err)
return err
}
```
Après avoir chargé cette configuration dans la variable `cfg`, vous pouvez transmettre cette variable aux instanciations du client. L’exemple de code instancie un client Amazon S3 comme suit :
```
// Create an S3 client
s3Client := s3.NewFromConfig(cfg)
```
Dans cet exemple, nous avons initialisé notre client Amazon S3 dans la fonction `init()` pour éviter d’avoir à l’initialiser à chaque fois que nous invoquons notre fonction. Le problème est que dans la fonction `init()`, Lambda n’a pas accès à l’objet de contexte. Pour contourner le problème, vous pouvez transmettre un espace réservé, comme `context.TODO()`, lors de la phase d’initialisation. Plus tard, lorsque vous passez un appel à l’aide du client, transmettez l’objet de contexte complet. Cette solution est également décrite dans [Utilisation du contexte dans les initialisations et les appels du client du kit SDK AWS](golang-context.md#golang-context-sdk).
Après avoir configuré et initialisé votre client SDK, vous pouvez l’utiliser pour interagir avec d’autres services AWS. L’exemple de code appelle l’API Amazon S3 `PutObject` comme suit :
```
_, err = s3Client.PutObject(ctx, &s3.PutObjectInput{
Bucket: &bucketName,
Key: &key,
Body: strings.NewReader(receiptContent),
})
```
## Accès aux variables d’environnement
Dans le code de votre gestionnaire, vous pouvez référencer n’importe quelle [variable d’environnement](configuration-envvars.md) à l’aide de la méthode `os.Getenv()`. Dans cet exemple, nous référençons la variable d’environnement `RECEIPT_BUCKET` définie à l’aide de la ligne de code suivante :
```
// Access environment variables
bucketName := os.Getenv("RECEIPT_BUCKET")
if bucketName == "" {
log.Printf("RECEIPT_BUCKET environment variable is not set")
return fmt.Errorf("missing required environment variable RECEIPT_BUCKET")
}
```
## Utilisation de l'état global
Pour éviter de créer des ressources à chaque fois que vous invoquez votre fonction, vous pouvez déclarer et modifier les variables globales en dehors du code de votre gestionnaire de fonction Lambda. Vous définissez ces variables globales dans un bloc ou une instruction `var`. De plus, votre gestionnaire peut déclarer une fonction `init()` qui est exécutée pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib). La méthode `init` se comporte de la même manière dans AWS Lambda que dans les programmes Go standard.
## Pratiques exemplaires en matière de code pour les fonctions Lambda Go
Respectez les directives de la liste suivante pour utiliser les pratiques exemplaires de codage lors de la création de vos fonctions Lambda :
+ **Séparez le gestionnaire Lambda de votre logique principale.** Cela vous permet de créer une fonction testable plus unitaire.
+ **Réduisez la complexité de vos dépendances.** Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’[environnement d’exécution](lambda-runtime-environment.md).
+ **Réduisez la taille de votre package de déploiement selon ses besoins relatifs à l’environnement d’exécution.** Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l'invocation.
**Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction.** Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire `/tmp`. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.
Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.
**Utilisez une directive keep-alive pour maintenir les connexions persistantes.** Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez [Réutilisation des connexions avec Keep-Alive dans Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
**Utilisez des [variables d’environnement](configuration-envvars.md) pour transmettre des paramètres opérationnels à votre fonction.** Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.
**Évitez d’utiliser des invocations récursives** dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur `0` afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.
**N’utilisez pas d’API non publiques non documentées** dans le code de votre fonction Lambda. Pour les exécutions gérées AWS Lambda, Lambda applique périodiquement des mises à jour de sécurité et fonctionnelles aux API internes de Lambda. Ces mises à jour internes de l’API peuvent être incompatibles avec les versions antérieures, entraînant des conséquences imprévues telles que des échecs d’invocation si votre fonction dépend de ces API non publiques. Consultez la [Référence d’API](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) pour obtenir la liste des API accessibles au public.
**Écriture du code idempotent.** L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulter[Comment faire en sorte que ma fonction Lambda soit idempotente ?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Go
Dans Lambda, l’objet de contexte fournit aux méthodes et aux propriétés des informations sur l’invocation, la fonction et l’environnement d’exécution. Lorsque Lambda exécute votre fonction, il transmet un objet contexte au [gestionnaire](golang-handler.md). Pour utiliser l’objet de contexte dans votre gestionnaire, vous pouvez éventuellement le déclarer comme paramètre d’entrée dans votre gestionnaire. L’objet de contexte est nécessaire si vous souhaitez effectuer les opérations suivantes dans votre gestionnaire :
+ Vous devez accéder à toutes les [variables, méthodes ou propriétés globales](#golang-context-library) proposées par l’objet de contexte. Ces méthodes et propriétés sont utiles pour des tâches telles que la détermination de l’entité qui a appelé votre fonction ou la mesure du temps d’invocation de votre fonction, comme illustré dans [Accès aux informations du contexte d'appel](#golang-context-access).
+ Vous devez utiliser l’AWS SDK pour Go pour effectuer des appels à d’autres services. L’objet de contexte est un paramètre d’entrée important pour la plupart de ces appels. Pour de plus amples informations, consultez [Utilisation du contexte dans les initialisations et les appels du client du kit SDK AWS](#golang-context-sdk).
**Topics**
+ [
## Variables, méthodes et propriétés prises en charge par l’objet de contexte
](#golang-context-library)
+ [
## Accès aux informations du contexte d'appel
](#golang-context-access)
+ [
## Utilisation du contexte dans les initialisations et les appels du client du kit SDK AWS
](#golang-context-sdk)
## Variables, méthodes et propriétés prises en charge par l’objet de contexte
La bibliothèque de contexte Lambda fournit les variables globales, méthodes et propriétés suivantes.
**Variables globales**
+ `FunctionName` – Nom de la fonction Lambda.
+ `FunctionVersion` – [Version](configuration-versions.md) de la fonction.
+ `MemoryLimitInMB` – Quantité de mémoire allouée à la fonction.
+ `LogGroupName` – Groupe de journaux pour la fonction.
+ `LogStreamName` – Flux de journal de l'instance de fonction.
**Méthodes de contexte**
+ `Deadline` – Retourne la date d'expiration de l'exécution, exprimée en millisecondes au format horaire Unix.
**Propriétés du contexte**
+ `InvokedFunctionArn` – Amazon Resource Name (ARN) utilisé pour appeler la fonction. Indique si l'appelant a spécifié un numéro de version ou un alias.
+ `AwsRequestID` – Identifiant de la demande d'appel.
+ `Identity` – (applications mobiles) Informations sur l'identité Amazon Cognito qui a autorisé la demande.
+ `ClientContext` – (applications mobiles) Contexte client fourni à Lambda par l'application client.
## Accès aux informations du contexte d'appel
Les fonctions Lambda ont accès aux métadonnées sur leur environnement et la demande d'appel. Elles sont accessibles à l'adresse du [contexte du package](https://golang.org/pkg/context/). Si votre gestionnaire inclut `context.Context` en tant que paramètre, Lambda insère les informations sur votre fonction dans la propriété `Value` du contexte. Notez que vous devez importer la bibliothèque `lambdacontext` pour accéder au contenu de l'objet `context.Context`.
```
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-lambda-go/lambdacontext"
)
func CognitoHandler(ctx context.Context) {
lc, _ := lambdacontext.FromContext(ctx)
log.Print(lc.Identity.CognitoIdentityPoolID)
}
func main() {
lambda.Start(CognitoHandler)
}
```
Dans l'exemple ci-dessus, `lc` est la variable utilisée pour consommer les informations que l'objet de contexte a capturées et `log.Print(lc.Identity.CognitoIdentityPoolID)` affiche ces informations, dans ce cas, le CognitoPoolID.
L'exemple suivant présente la façon d'utiliser l'objet contexte pour surveiller le temps nécessaire à l'exécution de votre fonction Lambda. Cela vous permet d'analyser les attentes de performance et d'ajuster le code de votre fonction en conséquence, si nécessaire.
```
package main
import (
"context"
"log"
"time"
"github.com/aws/aws-lambda-go/lambda"
)
func LongRunningHandler(ctx context.Context) (string, error) {
deadline, _ := ctx.Deadline()
deadline = deadline.Add(-100 * time.Millisecond)
timeoutChannel := time.After(time.Until(deadline))
for {
select {
case <- timeoutChannel:
return "Finished before timing out.", nil
default:
log.Print("hello!")
time.Sleep(50 * time.Millisecond)
}
}
}
func main() {
lambda.Start(LongRunningHandler)
}
```
## Utilisation du contexte dans les initialisations et les appels du client du kit SDK AWS
Si votre gestionnaire doit utiliser l’AWS SDK pour Go pour appeler d’autres services, incluez l’objet de contexte en tant qu’entrée dans votre gestionnaire. Dans AWS, il est recommandé de transmettre l’objet de contexte dans la plupart des appels au kit SDK AWS. Par exemple, l’appel Amazon S3 `PutObject` accepte l’objet de contexte (`ctx`) comme premier argument :
```
// Upload an object to S3
_, err = s3Client.PutObject(ctx, &s3.PutObjectInput{
...
})
```
Pour initialiser correctement vos clients SDK, vous pouvez également utiliser l’objet de contexte pour charger la configuration correcte avant de transmettre cet objet de configuration au client :
```
// Load AWS SDK configuration using the default credential provider chain
cfg, err := config.LoadDefaultConfig(ctx)
...
s3Client = s3.NewFromConfig(cfg)
```
Si vous souhaitez initialiser vos clients SDK en dehors de votre gestionnaire principal (c’est-à-dire pendant la phase d’initialisation), vous pouvez transmettre un objet de contexte de remplacement :
```
func init() {
// Initialize the S3 client outside of the handler, during the init phase
cfg, err := config.LoadDefaultConfig(context.TODO())
...
s3Client = s3.NewFromConfig(cfg)
}
```
Si vous initialisez vos clients de cette façon, assurez-vous de transmettre le bon objet de contexte dans les appels du SDK depuis votre gestionnaire principal.
# Déployer des fonctions Lambda Go avec des archives de fichiers .zip
Le code de votre AWS Lambda fonction se compose de scripts ou de programmes compilés et de leurs dépendances. Pour déployer votre code de fonction vers Lambda, vous utilisez un *package de déploiement*. Lambda prend en charge deux types de packages de déploiement : les images conteneurs et les archives de fichiers .zip.
Cette page explique comment créer un fichier .zip en tant que package de déploiement pour le moteur d'exécution Go, puis utiliser le fichier .zip pour déployer votre code de fonction à AWS Lambda l'aide des AWS Management Console, AWS Command Line Interface (AWS CLI) et AWS Serverless Application Model (AWS SAM).
Notez que Lambda utilise les autorisations de fichiers POSIX. Ainsi, vous pourriez devoir [définir des autorisations pour le dossier du package de déploiement](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-deployment-package-errors/) avant de créer l’archive de fichiers .zip.
**Topics**
+ [
## Création d’un fichier .zip sur macOS et Linux
](#golang-package-mac-linux)
+ [
## Création d’un fichier .zip sous Windows
](#golang-package-windows)
+ [
## Création et mise à jour de fonctions Lambda Go à l’aide de fichiers .zip
](#golang-package-create-function)
## Création d’un fichier .zip sur macOS et Linux
Les étapes suivantes montrent comment compiler votre exécutable à l’aide de la commande `go build` et créer un package de déploiement de fichiers .zip pour Lambda. Avant de compiler votre code, assurez-vous d'avoir installé le package [lambda depuis](https://github.com/aws/aws-lambda-go/tree/master/lambda). GitHub Ce module fournit une implémentation de l’interface d’exécution, qui gère l’interaction entre Lambda et le code de votre fonction. Pour télécharger cette bibliothèque, exécutez la commande suivante.
```
go get github.com/aws/aws-lambda-go/lambda
```
Si votre fonction utilise le AWS SDK pour Go, téléchargez l'ensemble standard de modules du SDK, ainsi que tous les clients d'API de AWS service requis par votre application. Pour savoir comment installer le SDK pour Go, [consultez Getting Started with AWS SDK pour Go the](https://github.com/aws/aws-sdk-go-v2?tab=readme-ov-file#getting-started) V2.
### Utilisation de la famille d’environnement d’exécution fournie
Go est implémenté différemment des autres exécutions gérées. Go se compilant nativement en un binaire exécutable, il n’a pas besoin d’un environnement d’exécution dédié au langage. Utilisez un [environnement d’exécution réservé au système d’exploitation](runtimes-provided.md) (la famille d’environnement d’exécution `provided`) pour déployer les fonctions Go sur Lambda.
**Pour créer un package de déploiement .zip (macOS/Linux)**
1. Dans le répertoire du projet qui contient le fichier `main.go` de votre application, compilez votre exécutable. Notez ce qui suit :
+ L’exécutable doit être nommé `bootstrap`. Pour de plus amples informations, veuillez consulter [Convention de nommage du gestionnaire](golang-handler.md#golang-handler-naming).
+ Définissez l’[architecture de jeu d’instructions](foundation-arch.md) cible. Les environnements d’exécution réservés au système d’exploitation prennent en charge les architectures arm64 et x86\$164.
+ Vous pouvez utiliser la balise optionnelle `lambda.norpc` pour exclure le composant RPC (Remote Procedure Call) de la bibliothèque [lambda](https://github.com/aws/aws-lambda-go/tree/master/lambda). Le composant RPC n’est nécessaire que lorsque vous utilisez l’environnement d’exécution Go 1.x. L’exclusion du RPC réduit la taille du package de déploiement.
Pour l’architecture arm64 :
```
GOOS=linux GOARCH=arm64 go build -tags lambda.norpc -o bootstrap main.go
```
Pour l’architecture x86\$164 :
```
GOOS=linux GOARCH=amd64 go build -tags lambda.norpc -o bootstrap main.go
```
1. (Facultatif) Vous devrez peut-être compiler des packages avec `CGO_ENABLED=0` configuré sur Linux :
```
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -o bootstrap -tags lambda.norpc main.go
```
Cette commande crée un package binaire stable pour les versions de bibliothèque C standard (`libc`), qui peuvent être différentes sur Lambda et d’autres appareils.
1. Créez un package de déploiement en empaquetant l’exécutable dans un fichier .zip.
```
zip myFunction.zip bootstrap
```
**Note**
Le fichier `bootstrap` doit se situer à la racine du fichier .zip.
1. Créez la fonction . Notez ce qui suit :
+ Le binaire doit être nommé `bootstrap`, mais le nom du gestionnaire peut être quelconque. Pour de plus amples informations, veuillez consulter [Convention de nommage du gestionnaire](golang-handler.md#golang-handler-naming).
+ L’option `--architectures` n’est nécessaire que si vous utilisez arm64. La valeur par défaut est x86\$164.
+ Pour `--role`, spécifiez l’Amazon Resource Name (ARN) du [rôle d’exécution](lambda-intro-execution-role.md).
```
aws lambda create-function --function-name myFunction \
--runtime provided.al2023 --handler bootstrap \
--architectures arm64 \
--role arn:aws:iam::111122223333:role/lambda-ex \
--zip-file fileb://myFunction.zip
```
## Création d’un fichier .zip sous Windows
Les étapes suivantes indiquent comment télécharger l'[build-lambda-zip](https://github.com/aws/aws-lambda-go/tree/main/cmd/build-lambda-zip)outil pour Windows depuis GitHub, compiler votre exécutable et créer un package de déploiement .zip.
**Note**
Si vous ne l’avez pas déjà fait, vous devez installer [git](https://git-scm.com/), puis ajouter l’exécutable `git` à votre variable d’environnement Windows `%PATH%`.
Avant de compiler votre code, assurez-vous d'avoir installé la bibliothèque [Lambda depuis](https://github.com/aws/aws-lambda-go/tree/master/lambda). GitHub Pour télécharger cette bibliothèque, exécutez la commande suivante.
```
go get github.com/aws/aws-lambda-go/lambda
```
Si votre fonction utilise le AWS SDK pour Go, téléchargez l'ensemble standard de modules du SDK, ainsi que tous les clients d'API de AWS service requis par votre application. Pour savoir comment installer le SDK pour Go, [consultez Getting Started with AWS SDK pour Go the](https://aws.github.io/aws-sdk-go-v2/docs/getting-started/) V2.
### Utilisation de la famille d’environnement d’exécution fournie
Go est implémenté différemment des autres exécutions gérées. Go se compilant nativement en un binaire exécutable, il n’a pas besoin d’un environnement d’exécution dédié au langage. Utilisez un [environnement d’exécution réservé au système d’exploitation](runtimes-provided.md) (la famille d’environnement d’exécution `provided`) pour déployer les fonctions Go sur Lambda.
**Pour créer un package de déploiement .zip (Windows)**
1. Téléchargez l'**build-lambda-zip**outil depuis GitHub.
```
go install github.com/aws/aws-lambda-go/cmd/build-lambda-zip@latest
```
1. Utilisez l’outil de votre `GOPATH` pour créer un fichier .zip. Si vous disposez d’une installation de Go par défaut, l’outil est généralement dans `%USERPROFILE%\Go\bin`. Dans le cas contraire, accédez à l’endroit où vous avez installé l’environnement d’exécution Go et effectuez l’une des instructions suivantes :
------
#### [ cmd.exe ]
Dans cmd.exe, exécutez l’une des commandes suivantes, en fonction de l’[architecture de jeu d’instructions](foundation-arch.md) cible. Les environnements d’exécution réservés au système d’exploitation prennent en charge les architectures arm64 et x86\$164.
Vous pouvez utiliser la balise optionnelle `lambda.norpc` pour exclure le composant RPC (Remote Procedure Call) de la bibliothèque [lambda](https://github.com/aws/aws-lambda-go/tree/master/lambda). Le composant RPC n’est nécessaire que lorsque vous utilisez l’environnement d’exécution Go 1.x. L’exclusion du RPC réduit la taille du package de déploiement.
**Example — Pour l’architecture x86\$164**
```
set GOOS=linux
set GOARCH=amd64
set CGO_ENABLED=0
go build -tags lambda.norpc -o bootstrap main.go
%USERPROFILE%\Go\bin\build-lambda-zip.exe -o myFunction.zip bootstrap
```
**Example — Pour l’architecture arm64**
```
set GOOS=linux
set GOARCH=arm64
set CGO_ENABLED=0
go build -tags lambda.norpc -o bootstrap main.go
%USERPROFILE%\Go\bin\build-lambda-zip.exe -o myFunction.zip bootstrap
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez l'une des opérations suivantes, en fonction de l'[architecture de votre jeu d'instructions](foundation-arch.md) cible. Les environnements d’exécution réservés au système d’exploitation prennent en charge les architectures arm64 et x86\$164.
Vous pouvez utiliser la balise optionnelle `lambda.norpc` pour exclure le composant RPC (Remote Procedure Call) de la bibliothèque [lambda](https://github.com/aws/aws-lambda-go/tree/master/lambda). Le composant RPC n’est nécessaire que lorsque vous utilisez l’environnement d’exécution Go 1.x. L’exclusion du RPC réduit la taille du package de déploiement.
Pour l’architecture x86\$164 :
```
$env:GOOS = "linux"
$env:GOARCH = "amd64"
$env:CGO_ENABLED = "0"
go build -tags lambda.norpc -o bootstrap main.go
~\Go\Bin\build-lambda-zip.exe -o myFunction.zip bootstrap
```
Pour l’architecture arm64 :
```
$env:GOOS = "linux"
$env:GOARCH = "arm64"
$env:CGO_ENABLED = "0"
go build -tags lambda.norpc -o bootstrap main.go
~\Go\Bin\build-lambda-zip.exe -o myFunction.zip bootstrap
```
------
1. Créez la fonction . Notez ce qui suit :
+ Le binaire doit être nommé `bootstrap`, mais le nom du gestionnaire peut être quelconque. Pour de plus amples informations, veuillez consulter [Convention de nommage du gestionnaire](golang-handler.md#golang-handler-naming).
+ L’option `--architectures` n’est nécessaire que si vous utilisez arm64. La valeur par défaut est x86\$164.
+ Pour `--role`, spécifiez l’Amazon Resource Name (ARN) du [rôle d’exécution](lambda-intro-execution-role.md).
```
aws lambda create-function --function-name myFunction \
--runtime provided.al2023 --handler bootstrap \
--architectures arm64 \
--role arn:aws:iam::111122223333:role/lambda-ex \
--zip-file fileb://myFunction.zip
```
## Création et mise à jour de fonctions Lambda Go à l’aide de fichiers .zip
Une fois que vous avez créé votre package de déploiement .zip, vous pouvez l’utiliser pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante. Vous pouvez déployer votre package .zip à l'aide de la console Lambda, de l'API Lambda et AWS Command Line Interface de l'API Lambda. Vous pouvez également créer et mettre à jour des fonctions Lambda à l’aide de l’ AWS Serverless Application Model (AWS SAM) et de CloudFormation.
La taille maximale d’un package de déploiement .zip pour Lambda est de 250 Mo (décompressé). Notez que cette limite s’applique à la taille combinée de tous les fichiers que vous chargez, y compris les couches Lambda.
Le runtime Lambda a besoin d’une autorisation pour lire les fichiers de votre package de déploiement. Dans la notation octale des autorisations Linux, Lambda a besoin de 644 autorisations pour les fichiers non exécutables (rw-r--r--) et de 755 autorisations () pour les répertoires et les fichiers exécutables. rwxr-xr-x
Sous Linux et macOS, utilisez la commande `chmod` pour modifier les autorisations de fichiers sur les fichiers et les répertoires de votre package de déploiement. Par exemple, pour octroyer à un fichier non exécutable les autorisations correctes, exécutez la commande suivante.
```
chmod 644
```
Pour modifier les autorisations relatives aux fichiers dans Windows, voir [Définir, afficher, modifier ou supprimer des autorisations sur un objet](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) dans la documentation Microsoft Windows.
**Note**
Si vous n'accordez pas à Lambda les autorisations nécessaires pour accéder aux répertoires de votre package de déploiement, Lambda définit les autorisations pour ces répertoires sur 755 (). rwxr-xr-x
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de la console
Pour créer une nouvelle fonction, vous devez d’abord créer la fonction dans la console, puis charger votre archive .zip. Pour mettre à jour une fonction existante, ouvrez la page de votre fonction, puis suivez la même procédure pour ajouter votre fichier .zip mis à jour.
Si votre fichier .zip fait moins de 50 Mo, vous pouvez créer ou mettre à jour une fonction en chargeant le fichier directement à partir de votre ordinateur local. Pour les fichiers .zip de plus de 50 Mo, vous devez d’abord charger votre package dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS Management Console, consultez [Getting started with Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). Pour télécharger des fichiers à l'aide de AWS CLI, voir [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
**Note**
Vous ne pouvez pas convertir une fonction d’image de conteneur existante pour utiliser une archive .zip. Vous devez créer une nouvelle fonction.
**Pour créer une nouvelle fonction (console)**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Informations de base**, procédez comme suit :
1. Pour **Nom de la fonction**, saisissez le nom de la fonction.
1. Dans **Runtime (Exécution)**, choisissez `provided.al2023`.
1. (Facultatif) Sous **Permissions (Autorisations)**, développez **Change default execution role (Modifier le rôle d’exécution par défaut)**. Vous pouvez créer un **rôle d’exécution** ou en utiliser un existant.
1. Choisissez **Créer une fonction**. Lambda crée une fonction de base « Hello world » à l’aide de l’exécution de votre choix.
**Pour charger une archive .zip à partir de votre ordinateur local (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger le fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez **Fichier .zip**.
1. Pour charger un fichier .zip, procédez comme suit :
1. Sélectionnez **Charger**, puis choisissez votre fichier .zip dans le sélecteur de fichiers.
1. Choisissez **Ouvrir**.
1. Choisissez **Enregistrer**.
**Pour charger une archive .zip depuis un compartiment Amazon S3 (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger un nouveau fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez l’**emplacement Amazon S3**.
1. Collez l’URL du lien Amazon S3 de votre fichier .zip et choisissez **Enregistrer**.
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide du AWS CLI
Vous pouvez utiliser l’[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) pour créer une nouvelle fonction ou pour mettre à jour une fonction existante à l’aide d’un fichier .zip. Utilisez la [fonction de création](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) et [update-function-code](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html)les commandes pour déployer votre package .zip. Si votre fichier .zip est inférieur à 50 Mo, vous pouvez charger le package .zip à partir d’un emplacement de fichier sur votre machine de génération locale. Pour les fichiers plus volumineux, vous devez charger votre package .zip à partir d’un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
**Note**
Si vous chargez votre fichier .zip depuis un compartiment Amazon S3 à l'aide de AWS CLI, le compartiment doit se trouver au même endroit Région AWS que votre fonction.
Pour créer une nouvelle fonction à l'aide d'un fichier .zip avec le AWS CLI, vous devez spécifier les éléments suivants :
+ Le nom de votre fonction (`--function-name`)
+ L’exécution de votre fonction (`--runtime`)
+ L’Amazon Resource Name (ARN) du [rôle d’exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de votre fonction (`--role`)
+ Le nom de la méthode du gestionnaire dans votre code de fonction (`--handler`)
Vous devez également indiquer l’emplacement de votre fichier .zip. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda create-function --function-name myFunction \
--runtime provided.al2023 --handler bootstrap \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez l’option `--code` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `S3ObjectVersion` pour les objets soumis à la gestion des versions.
```
aws lambda create-function --function-name myFunction \
--runtime provided.al2023 --handler bootstrap \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--code S3Bucket=amzn-s3-demo-bucket,S3Key=myFileName.zip,S3ObjectVersion=myObjectVersion
```
Pour mettre à jour une fonction existante à l’aide de l’interface de ligne de commande, vous devez spécifier le nom de votre fonction à l’aide du paramètre `--function-name`. Vous devez également spécifier l’emplacement du fichier .zip que vous souhaitez utiliser pour mettre à jour votre code de fonction. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda update-function-code --function-name myFunction \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez les options `--s3-bucket` et `--s3-key` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `--s3-object-version` pour les objets soumis à la gestion des versions.
```
aws lambda update-function-code --function-name myFunction \
--s3-bucket amzn-s3-demo-bucket --s3-key myFileName.zip --s3-object-version myObject Version
```
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de l’API Lambda
Pour créer et mettre à jour des fonctions à l’aide d’une archive de fichiers .zip, utilisez les opérations d’API suivantes :
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide de AWS SAM
The AWS Serverless Application Model (AWS SAM) est une boîte à outils qui permet de rationaliser le processus de création et d'exécution d'applications sans serveur sur AWS. Vous définissez les ressources de votre application dans un modèle YAML ou JSON et vous utilisez l'interface de ligne de AWS SAM commande (AWS SAM CLI) pour créer, empaqueter et déployer vos applications. Lorsque vous créez une fonction Lambda à partir d'un AWS SAM modèle, elle crée AWS SAM automatiquement un package de déploiement ou une image de conteneur .zip avec le code de votre fonction et les dépendances que vous spécifiez. Pour en savoir plus sur l'utilisation des fonctions Lambda AWS SAM pour créer et déployer des fonctions Lambda, consultez [Getting started with AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started.html) dans le Guide du *AWS Serverless Application Model développeur*.
Vous pouvez également l'utiliser AWS SAM pour créer une fonction Lambda à l'aide d'une archive de fichiers .zip existante. Pour créer une fonction Lambda à l'aide de AWS SAM, vous pouvez enregistrer votre fichier .zip dans un compartiment Amazon S3 ou dans un dossier local sur votre machine de génération. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
Dans votre AWS SAM modèle, la `AWS::Serverless::Function` ressource spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `CodeUri`- défini sur l'URI Amazon S3, le chemin d'accès au dossier local ou à l'[FunctionCode](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-functioncode.html)objet du code de fonction
+ `Runtime` : défini sur votre exécution choisie
Ainsi AWS SAM, si votre fichier .zip est supérieur à 50 Mo, vous n'avez pas besoin de le télécharger au préalable dans un compartiment Amazon S3. AWS SAM peut télécharger des packages .zip jusqu'à la taille maximale autorisée de 250 Mo (décompressés) à partir d'un emplacement sur votre machine de compilation locale.
Pour en savoir plus sur le déploiement de fonctions à l'aide d'un fichier .zip dans AWS SAM, consultez [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)le *manuel du AWS SAM développeur*.
**Exemple : utilisation AWS SAM pour créer une fonction Go avec provided.al2023**
1. Créez un AWS SAM modèle avec les propriétés suivantes :
+ **BuildMethod**: Spécifie le compilateur de votre application. Utilisez `go1.x`.
+ **Runtime** : utilisez `provided.al2023`.
+ **CodeUri**: Entrez le chemin d'accès à votre code.
+ **Architectures** : Utilisez `[arm64]` pour l’architecture arm64. Pour l’architecture x86\$164, utilisez `[amd64]` ou supprimez la propriété `Architectures`.
**Example template.yaml**
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: go1.x
Properties:
CodeUri: hello-world/ # folder where your main program resides
Handler: bootstrap
Runtime: provided.al2023
Architectures: [arm64]
```
1. Utilisez la commande [sam build](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-build.html) pour compiler l’exécutable.
```
sam build
```
1. Utilisez la commande [sam deploy](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) pour déployer la fonction vers Lambda.
```
sam deploy --guided
```
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide de CloudFormation
Vous pouvez l'utiliser CloudFormation pour créer une fonction Lambda à l'aide d'une archive de fichiers .zip. Pour créer une fonction Lambda à partir d’un fichier .zip, vous devez d’abord charger votre fichier dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur.*
Dans votre CloudFormation modèle, la `AWS::Lambda::Function` ressource spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `Code` : saisissez le nom du compartiment Amazon S3 et le nom du fichier .zip dans les champs `S3Bucket` et `S3Key`
+ `Runtime` : défini sur votre exécution choisie
Le fichier .zip CloudFormation généré ne peut pas dépasser 4 Mo. Pour en savoir plus sur le déploiement de fonctions à l'aide d'un fichier .zip dans CloudFormation, consultez [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)le *Guide de l'CloudFormation utilisateur*.
# Déployer des fonctions Lambda Go avec des images conteneurs
Il existe deux méthodes pour créer une image de conteneur pour une fonction Lambda Go :
+ [Utilisation d'une image de base AWS uniquement pour le système d'exploitation](#go-image-provided)
Go est implémenté différemment des autres exécutions gérées. Go se compilant nativement en un binaire exécutable, il n’a pas besoin d’un environnement d’exécution dédié au langage. Utilisez une [image de base réservée au système d’exploitation](images-create.md#runtimes-images-provided) pour créer des images Go pour Lambda. Pour rendre l’image compatible avec Lambda, vous devez inclure le package `aws-lambda-go/lambda` dans l’image.
+ [Utilisation d'une image non AWS basique](#go-image-other)
Vous pouvez utiliser une autre image de base à partir d’un autre registre de conteneur, comme Alpine Linux ou Debian. Vous pouvez également utiliser une image personnalisée créée par votre organisation. Pour rendre l'image compatible avec Lambda, vous devez inclure le package `aws-lambda-go/lambda` dans l'image.
**Astuce**
Pour réduire le temps nécessaire à l’activation des fonctions du conteneur Lambda, consultez [Utiliser des générations en plusieurs étapes](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds) (français non garanti) dans la documentation Docker. Pour créer des images de conteneur efficaces, suivez la section [Bonnes pratiques pour l’écriture de Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) (français non garanti).
Cette page explique comment créer, tester et déployer des images de conteneur pour Lambda.
## AWS images de base pour le déploiement des fonctions Go
Go est implémenté différemment des autres exécutions gérées. Go se compilant nativement en un binaire exécutable, il n’a pas besoin d’un environnement d’exécution dédié au langage. Utilisez une [image de base réservée au système d’exploitation](images-create.md#runtimes-images-provided) pour déployer les fonctions Go sur Lambda.
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Exécution réservée au système d’exploitation | `provided.al2023` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Exécution réservée au système d’exploitation | `provided.al2` | Amazon Linux 2 | 31 juillet 2026 | 31 août 2026 | 30 sept. 2026 |
Galerie publique d'Amazon Elastic Container Registry : [gallery.ecr. aws/lambda/provided](https://gallery.ecr.aws/lambda/provided)
## Client d’interface d’environnement d’exécution Go
Le package `aws-lambda-go/lambda` inclut une implémentation de l’interface d’exécution. Pour obtenir des exemples d’utilisation de `aws-lambda-go/lambda` dans votre image, consultez [Utilisation d'une image de base AWS uniquement pour le système d'exploitation](#go-image-provided) ou [Utilisation d'une image non AWS basique](#go-image-other).
## Utilisation d'une image de base AWS uniquement pour le système d'exploitation
Go est implémenté différemment des autres exécutions gérées. Go se compilant nativement en un binaire exécutable, il n’a pas besoin d’un environnement d’exécution dédié au langage. N’utilisez une [image de base réservée au système d’exploitation](images-create.md#runtimes-images-provided) que pour créer des images de conteneur pour les fonctions Go.
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| al2023 | Exécution uniquement basée sur le système d'exploitation | Amazon Linux 2023 | [Dockerfile pour OS uniquement Runtime sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2023/Dockerfile.provided.al2023) | 30 juin 2029 |
| al2 | Exécution uniquement basée sur le système d'exploitation | Amazon Linux 2 | [Dockerfile pour OS uniquement Runtime sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2/Dockerfile.provided.al2) | 31 juillet 2026 |
Pour plus d’informations sur ces images de base, consultez [fourni](https://gallery.ecr.aws/lambda/provided) située dans la galerie publique Amazon ECR.
Vous devez inclure le package [aws-lambda-go/lambda](https://github.com/aws/aws-lambda-go) dans votre gestionnaire Go. Ce package implémente le modèle de programmation pour Go, y compris l’interface d’exécution.
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Go
### Création d’une image à partir de l’image de base provided.al2023
**Pour créer et déployer une fonction Go avec l’image de base `provided.al2023`**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir hello
cd hello
```
1. Initialisez un nouveau module Go.
```
go mod init example.com/hello-world
```
1. Ajoutez la bibliothèque **lambda** comme dépendance de votre nouveau module.
```
go get github.com/aws/aws-lambda-go/lambda
```
1. Créez un fichier nommé `main.go` et ouvrez-le dans un éditeur de texte. Il s’agit du code de la fonction Lambda. Vous pouvez utiliser l’exemple de code suivant pour le tester, ou le remplacer par le vôtre.
```
package main
import (
"context"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, event events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
response := events.APIGatewayProxyResponse{
StatusCode: 200,
Body: "\"Hello from Lambda!\"",
}
return response, nil
}
func main() {
lambda.Start(handler)
}
```
1. Utilisez un éditeur de texte afin de créer un Dockerfile dans votre répertoire de projets.
+ L’exemple de fichier Docker suivant utilise une [génération en plusieurs étapes](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds). Cela vous permet d’utiliser une image de base différente à chaque étape. Vous pouvez utiliser une image, telle qu’une [image de base Go](https://hub.docker.com/_/golang), pour compiler votre code et générer le binaire exécutable. Vous pouvez ensuite utiliser une image différente, telle que `provided.al2023`, dans l’instruction finale `FROM` pour définir l’image que vous déployez sur Lambda. Le processus de génération est séparé de l’image de déploiement final, de sorte que l’image finale ne contient que les fichiers nécessaires à l’exécution de l’application.
+ Vous pouvez utiliser la balise optionnelle `lambda.norpc` pour exclure le composant RPC (Remote Procedure Call) de la bibliothèque [lambda](https://github.com/aws/aws-lambda-go/tree/master/lambda). Le composant RPC n’est nécessaire que lorsque vous utilisez l’environnement d’exécution Go 1.x. L’exclusion du RPC réduit la taille du package de déploiement.
+ Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example – Dockerfile de génération en plusieurs étapes**
**Note**
Assurez-vous que la version de Go que vous spécifiez dans votre Dockerfile (par exemple, `golang:1.20`) est la même que celle que vous avez utilisée pour créer votre application.
```
FROM golang:1.20 as build
WORKDIR /helloworld
# Copy dependencies list
COPY go.mod go.sum ./
# Build with optional lambda.norpc tag
COPY main.go .
RUN go build -tags lambda.norpc -o main main.go
# Copy artifacts to a clean image
FROM public.ecr.aws/lambda/provided:al2023
COPY --from=build /helloworld/main ./main
ENTRYPOINT [ "./main" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l’image localement
Utilisez l’[émulateur d’interface d’exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/) pour tester votre image localement. L’émulateur d’interface d’exécution est inclus dans l’image de base `provided.al2023`.
**Pour exécuter l’émulateur d’interface d’exécution sur votre ordinateur local**
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Notez ce qui suit :
+ `docker-image` est le nom de l’image et `test` est la balise.
+ `./main` est le `ENTRYPOINT` de votre Dockerfile.
```
docker run -d -p 9000:8080 \
--entrypoint /usr/local/bin/aws-lambda-rie \
docker-image:test ./main
```
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
1. À partir d’une nouvelle fenêtre de terminal, publiez un événement sur le point de terminaison suivant au moyen d’une commande **curl** :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Certaines fonctions peuvent nécessiter l’ajout d’une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
## Utilisation d'une image non AWS basique
Vous pouvez créer une image de conteneur pour Go à partir d'une image non AWS basique. L’exemple de Dockerfile dans les étapes suivantes utilise une [image de base Alpine](https://hub.docker.com/_/golang/).
Vous devez inclure le package [aws-lambda-go/lambda](https://github.com/aws/aws-lambda-go) dans votre gestionnaire Go. Ce package implémente le modèle de programmation pour Go, y compris l’interface d’exécution.
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Go
### Création d’une image à partir d’une image de base alternative
**Pour créer et déployer une fonction Go avec une image de base Alpine**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir hello
cd hello
```
1. Initialisez un nouveau module Go.
```
go mod init example.com/hello-world
```
1. Ajoutez la bibliothèque **lambda** comme dépendance de votre nouveau module.
```
go get github.com/aws/aws-lambda-go/lambda
```
1. Créez un fichier nommé `main.go` et ouvrez-le dans un éditeur de texte. Il s’agit du code de la fonction Lambda. Vous pouvez utiliser l’exemple de code suivant pour le tester, ou le remplacer par le vôtre.
```
package main
import (
"context"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, event events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
response := events.APIGatewayProxyResponse{
StatusCode: 200,
Body: "\"Hello from Lambda!\"",
}
return response, nil
}
func main() {
lambda.Start(handler)
}
```
1. Utilisez un éditeur de texte afin de créer un Dockerfile dans votre répertoire de projets. L’exemple de Dockerfile suivant utilise une [image de base Alpine](https://hub.docker.com/_/golang/). Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
**Note**
Assurez-vous que la version de Go que vous spécifiez dans votre Dockerfile (par exemple, `golang:1.20`) est la même que celle que vous avez utilisée pour créer votre application.
```
FROM golang:1.20.2-alpine3.16 as build
WORKDIR /helloworld
# Copy dependencies list
COPY go.mod go.sum ./
# Build
COPY main.go .
RUN go build -o main main.go
# Copy artifacts to a clean image
FROM alpine:3.16
COPY --from=build /helloworld/main /main
ENTRYPOINT [ "/main" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l’image localement
Utilisez l’[émulateur d’interface d’exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/) pour tester l’image localement. Vous pouvez [intégrer l’émulateur dans votre image](https://github.com/aws/aws-lambda-runtime-interface-emulator/?tab=readme-ov-file#build-rie-into-your-base-image) ou utiliser la procédure suivante pour l’installer sur votre machine locale.
**Pour installer et exécuter l’émulateur d’interface d’exécution sur votre ordinateur local**
1. Depuis le répertoire de votre projet, exécutez la commande suivante pour télécharger l'émulateur d'interface d'exécution (architecture x86-64) GitHub et l'installer sur votre machine locale.
------
#### [ Linux/macOS ]
```
mkdir -p ~/.aws-lambda-rie && \
curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && \
chmod +x ~/.aws-lambda-rie/aws-lambda-rie
```
Pour installer l'émulateur arm64, remplacez l'URL du GitHub référentiel dans la commande précédente par la suivante :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
#### [ PowerShell ]
```
$dirPath = "$HOME\.aws-lambda-rie"
if (-not (Test-Path $dirPath)) {
New-Item -Path $dirPath -ItemType Directory
}
$downloadLink = "https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie"
$destinationPath = "$HOME\.aws-lambda-rie\aws-lambda-rie"
Invoke-WebRequest -Uri $downloadLink -OutFile $destinationPath
```
Pour installer l’émulateur arm64, remplacez `$downloadLink` par ce qui suit :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Notez ce qui suit :
+ `docker-image` est le nom de l’image et `test` est la balise.
+ `/main` est le `ENTRYPOINT` de votre Dockerfile.
------
#### [ Linux/macOS ]
```
docker run --platform linux/amd64 -d -v ~/.aws-lambda-rie:/aws-lambda -p 9000:8080 \
--entrypoint /aws-lambda/aws-lambda-rie \
docker-image:test \
/main
```
------
#### [ PowerShell ]
```
docker run --platform linux/amd64 -d -v "$HOME\.aws-lambda-rie:/aws-lambda" -p 9000:8080 `
--entrypoint /aws-lambda/aws-lambda-rie `
docker-image:test `
/main
```
------
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. Publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
# Utilisation de couches pour les fonctions Lambda Go
Nous déconseillons d’utiliser des [couches](chapter-layers.md) pour gérer les dépendances des fonctions Lambda écrites en Go. Cela est dû au fait que les fonctions Lambda en Go sont compilées en un seul exécutable, que vous fournissez à Lambda lorsque vous déployez votre fonction. Cet exécutable contient votre code de fonction compilé, ainsi que toutes ses dépendances. L’utilisation de couches complique non seulement ce processus, mais entraîne également une augmentation des temps de démarrage à froid, car vos fonctions doivent charger manuellement des assemblages supplémentaires en mémoire pendant la phase d’initialisation.
Pour utiliser des dépendances externes avec vos gestionnaires Go, incluez-les directement dans votre package de déploiement. Ce faisant, vous simplifiez le processus de déploiement et profitez des optimisations du compilateur Go intégré. Pour un exemple d’importation et d’utilisation d’une dépendance telle que le kit SDK AWS pour Go dans votre fonction, consultez [Définition du gestionnaire de fonction Lambda dans Go](golang-handler.md).
# Journalisation et surveillance des fonctions Lambda Go
AWS Lambda surveille automatiquement les fonctions Lambda en votre nom et envoie les journaux à Amazon. CloudWatch Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs et un flux de journaux pour chaque instance de votre fonction. L’environnement d’exécution Lambda envoie des informations sur chaque invocation au flux de journaux et transmet les journaux et autres sorties provenant du code de votre fonction. Pour de plus amples informations, veuillez consulter [Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md).
Cette page explique comment générer une sortie de journal à partir du code de votre fonction Lambda et comment accéder aux journaux à l'aide de la AWS Command Line Interface console Lambda ou de la console. CloudWatch
**Topics**
+ [
## Création d’une fonction qui renvoie des journaux
](#golang-logging-output)
+ [
## Affichage des journaux dans la console Lambda
](#golang-logging-console)
+ [
## Afficher les journaux dans la CloudWatch console
](#golang-logging-cwconsole)
+ [
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
](#golang-logging-cli)
+ [
## Suppression de journaux
](#golang-logging-delete)
## Création d’une fonction qui renvoie des journaux
Pour générer les journaux à partir de votre code de fonction, vous pouvez utiliser des méthodes sur [le package fmt](https://golang.org/pkg/fmt/) ou n’importe quelle bibliothèque de journalisation qui écrit dans `stdout` ou `stderr`. L’exemple suivant utilise [le package de journal](https://golang.org/pkg/log/).
**Example [main.go](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-go/function/main.go) – journalisation**
```
func handleRequest(ctx context.Context, event events.SQSEvent) (string, error) {
// event
eventJson, _ := json.MarshalIndent(event, "", " ")
log.Printf("EVENT: %s", eventJson)
// environment variables
log.Printf("REGION: %s", os.Getenv("AWS_REGION"))
log.Println("ALL ENV VARS:")
for _, element := range os.Environ() {
log.Println(element)
}
```
**Example format des journaux**
```
START RequestId: dbda340c-xmpl-4031-8810-11bb609b4c71 Version: $LATEST
2020/03/27 03:40:05 EVENT: {
"Records": [
{
"messageId": "19dd0b57-b21e-4ac1-bd88-01bbb068cb78",
"receiptHandle": "MessageReceiptHandle",
"body": "Hello from SQS!",
"md5OfBody": "7b27xmplb47ff90a553787216d55d91d",
"md5OfMessageAttributes": "",
"attributes": {
"ApproximateFirstReceiveTimestamp": "1523232000001",
"ApproximateReceiveCount": "1",
"SenderId": "123456789012",
"SentTimestamp": "1523232000000"
},
...
2020/03/27 03:40:05 AWS_LAMBDA_LOG_STREAM_NAME=2020/03/27/[$LATEST]569cxmplc3c34c7489e6a97ad08b4419
2020/03/27 03:40:05 AWS_LAMBDA_FUNCTION_NAME=blank-go-function-9DV3XMPL6XBC
2020/03/27 03:40:05 AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128
2020/03/27 03:40:05 AWS_LAMBDA_FUNCTION_VERSION=$LATEST
2020/03/27 03:40:05 AWS_EXECUTION_ENV=AWS_Lambda_go1.x
END RequestId: dbda340c-xmpl-4031-8810-11bb609b4c71
REPORT RequestId: dbda340c-xmpl-4031-8810-11bb609b4c71 Duration: 38.66 ms Billed Duration: 243 ms Memory Size: 128 MB Max Memory Used: 54 MB Init Duration: 203.69 ms
XRAY TraceId: 1-5e7d7595-212fxmpl9ee07c4884191322 SegmentId: 42ffxmpl0645f474 Sampled: true
```
L’environnement d’exécution Go enregistre les lignes `START`, `END` et `REPORT` pour chaque invocation. La ligne de rapport fournit les détails suivants.
**Champs de données de la ligne REPORT**
+ **RequestId**— L'identifiant de demande unique pour l'invocation.
+ **Duration** – Temps que la méthode de gestion du gestionnaire de votre fonction a consacré au traitement de l’événement.
+ **Billed Duration** : temps facturé pour l’invocation.
+ **Memory Size** – Quantité de mémoire allouée à la fonction.
+ **Max Memory Used** – Quantité de mémoire utilisée par la fonction. Lorsque les appels partagent un environnement d’exécution, Lambda indique la mémoire maximale utilisée pour toutes les invocations. Ce comportement peut entraîner une valeur signalée plus élevée que prévu.
+ **Init Duration** : pour la première requête servie, temps qu’il a pris à l’exécution charger la fonction et exécuter le code en dehors de la méthode du gestionnaire.
+ **XRAY TraceId** — Pour les demandes suivies, l'[ID de AWS X-Ray trace.](services-xray.md)
+ **SegmentId**— Pour les demandes tracées, l'identifiant du segment X-Ray.
+ **Sampled** – Pour les demandes suivies, résultat de l’échantillonnage.
## Affichage des journaux dans la console Lambda
Vous pouvez utiliser la console Lambda pour afficher la sortie du journal après avoir invoqué une fonction Lambda.
Si votre code peut être testé à partir de l’éditeur **Code** intégré, vous trouverez les journaux dans les **résultats d’exécution**. Lorsque vous utilisez la fonctionnalité de test de console pour invoquer une fonction, vous trouverez **Sortie du journal** dans la section **Détails**.
## Afficher les journaux dans la CloudWatch console
Vous pouvez utiliser la CloudWatch console Amazon pour consulter les journaux de toutes les invocations de fonctions Lambda.
**Pour afficher les journaux sur la CloudWatch console**
1. Ouvrez la [page Groupes de journaux](https://console.aws.amazon.com/cloudwatch/home?#logs:) sur la CloudWatch console.
1. Choisissez le groupe de journaux pour votre fonction (***your-function-name*/aws/lambda/**).
1. Choisissez un flux de journaux.
Chaque flux de journal correspond à une [instance de votre fonction](lambda-runtime-environment.md). Un flux de journal apparaît lorsque vous mettez à jour votre fonction Lambda et lorsque des instances supplémentaires sont créées pour gérer les appels simultanés. Pour trouver les journaux d'un appel spécifique, nous vous recommandons d'instrumenter votre fonction avec. AWS X-Ray X-Ray enregistre des détails sur la demande et le flux de journaux dans le suivi.
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
AWS CLI Il s'agit d'un outil open source qui vous permet d'interagir avec les AWS services à l'aide de commandes dans votre interface de ligne de commande. Pour effectuer les étapes de cette section, vous devez disposer de la [version 2 de l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
Vous pouvez utiliser [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) pour récupérer les journaux d’une invocation à l’aide de l’option de commande `--log-type`. La réponse inclut un champ `LogResult` qui contient jusqu’à 4 Ko de journaux codés en base64 provenant de l’invocation.
**Example récupérer un ID de journal**
L’exemple suivant montre comment récupérer un *ID de journal* à partir du champ `LogResult` d’une fonction nommée `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example décoder les journaux**
Dans la même invite de commandes, utilisez l’utilitaire `base64` pour décoder les journaux. L’exemple suivant montre comment récupérer les journaux encodés en base64 pour `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez voir la sortie suivante :
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
L’utilitaire `base64` est disponible sous Linux, macOS et [Ubuntu sous Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Les utilisateurs de macOS auront peut-être besoin d’utiliser `base64 -D`.
**Example Script get-logs.sh**
Dans la même invite de commandes, utilisez le script suivant pour télécharger les cinq derniers événements de journalisation. Le script utilise `sed` pour supprimer les guillemets du fichier de sortie et attend 15 secondes pour permettre la mise à disposition des journaux. La sortie comprend la réponse de Lambda, ainsi que la sortie de la commande `get-log-events`.
Copiez le contenu de l’exemple de code suivant et enregistrez-le dans votre répertoire de projet Lambda sous `get-logs.sh`.
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS et Linux (uniquement)**
Dans la même invite de commandes, les utilisateurs macOS et Linux peuvent avoir besoin d’exécuter la commande suivante pour s’assurer que le script est exécutable.
```
chmod -R 755 get-logs.sh
```
**Example récupérer les cinq derniers événements de journal**
Dans la même invite de commande, exécutez le script suivant pour obtenir les cinq derniers événements de journalisation.
```
./get-logs.sh
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Suppression de journaux
Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker des journaux indéfiniment, supprimez le groupe de journaux ou [configurez une période de conservation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) à l’issue de laquelle les journaux sont supprimés automatiquement.
# Instrumentation du code Go AWS Lambda
Lambda s'intègre pour vous aider AWS X-Ray à suivre, à déboguer et à optimiser les applications Lambda. Vous pouvez utiliser X-Ray pour suivre une demande lorsque celle-ci parcourt les ressources de votre application, qui peuvent inclure des fonctions Lambda et d'autres services AWS .
Pour envoyer des données de suivi à X-Ray, vous pouvez utiliser l'une des deux bibliothèques SDK suivantes :
+ [AWS Distro for OpenTelemetry (ADOT)](https://aws.amazon.com/otel) — Une distribution sécurisée, prête pour la production et AWS prise en charge du SDK (). OpenTelemetry OTel
+ [AWS X-Ray SDK for](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go.html) Go : SDK permettant de générer et d'envoyer des données de suivi à X-Ray.
Chacune d'entre elles SDKs propose des moyens d'envoyer vos données de télémétrie au service X-Ray. Vous pouvez ensuite utiliser X-Ray pour afficher, filtrer et avoir un aperçu des métriques de performance de votre application, afin d’identifier les problèmes et les occasions d’optimiser votre application.
**Important**
Les outils X-Ray et Powertools pour AWS Lambda SDKs font partie d'une solution d'instrumentation étroitement intégrée proposée par AWS. Les couches ADOT Lambda font partie d’une norme industrielle pour l’instrumentation de traçage qui collecte plus de données en général, mais qui peut ne pas convenir à tous les cas d’utilisation. Vous pouvez implémenter le end-to-end traçage dans X-Ray en utilisant l'une ou l'autre solution. Pour en savoir plus sur le choix entre les deux, consultez [Choosing between the AWS Distro for Open Telemetry and](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-choosing) X-Ray. SDKs
**Topics**
+ [
## Utilisation d'ADOT pour instrumenter vos fonctions Go
](#golang-adot)
+ [
## Utilisation du kit SDK X-Ray pour instrumenter vos fonctions Go
](#golang-xray-sdk)
+ [
## Activation du suivi avec la console Lambda
](#golang-tracing-console)
+ [
## Activation du suivi avec l’API Lambda
](#golang-tracing-api)
+ [
## Activation du traçage avec CloudFormation
](#golang-tracing-cloudformation)
+ [
## Interprétation d’un suivi X-Ray
](#golang-tracing-interpretation)
## Utilisation d'ADOT pour instrumenter vos fonctions Go
ADOT fournit des couches [Lambda](chapter-layers.md) entièrement gérées qui regroupent tout ce dont vous avez besoin pour collecter des données de télémétrie à l'aide du SDK. OTel En consommant cette couche, vous pouvez instrumenter vos fonctions Lambda sans avoir à modifier le code de fonction. Vous pouvez également configurer votre couche pour effectuer une initialisation personnalisée de OTel. Pour de plus amples informations, veuillez consulter [Configuration personnalisée pour ADOT Collector sur Lambda](https://aws-otel.github.io/docs/getting-started/lambda#custom-configuration-for-the-adot-collector-on-lambda) dans la documentation ADOT.
Pour les exécutions python, vous pouvez ajouter la **AWS couche Lambda gérée pour ADOT Go** pour instrumenter automatiquement vos fonctions. Pour obtenir des instructions détaillées sur la façon d'ajouter cette couche, consultez [AWS Distro for OpenTelemetry Lambda Support](https://aws-otel.github.io/docs/getting-started/lambda/lambda-go) for Go dans la documentation ADOT.
## Utilisation du kit SDK X-Ray pour instrumenter vos fonctions Go
Pour enregistrer les détails des appels que votre fonction Lambda effectue vers d'autres ressources de votre application, vous pouvez également utiliser le AWS X-Ray SDK for Go. Pour obtenir le SDK, téléchargez-le depuis son [GitHub dépôt](https://github.com/aws/aws-xray-sdk-go) avec : `go get`
```
go get github.com/aws/aws-xray-sdk-go
```
Pour instrumenter les clients du AWS SDK, transmettez-les à la `xray.AWS()` méthode. Ensuite, vous pouvez suivre vos appels à l'aide de la version `WithContext` de la méthode.
```
svc := s3.New(session.New())
xray.AWS(svc.Client)
...
svc.ListBucketsWithContext(ctx aws.Context, input *ListBucketsInput)
```
Une fois que vous avez ajouté les bonnes dépendances et effectué les modifications de code nécessaires, activez le suivi dans la configuration de votre fonction via la console Lambda ou l’API.
## Activation du suivi avec la console Lambda
Pour activer/désactiver le traçage actif sur votre fonction Lambda avec la console, procédez comme suit :
**Pour activer le traçage actif**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez **Configuration**, puis choisissez **Outils de surveillance et d’opérations**.
1. Dans **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **Signaux CloudWatch d'application et AWS X-Ray** sélectionnez **Activer les traces** de **service Lambda**.
1. Choisissez **Enregistrer**.
## Activation du suivi avec l’API Lambda
Configurez le suivi sur votre fonction Lambda avec le AWS SDK AWS CLI or, utilisez les opérations d'API suivantes :
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
L'exemple de AWS CLI commande suivant active le suivi actif sur une fonction nommée **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
Le mode de suivi fait partie de la configuration spécifique de la version lorsque vous publiez une version de votre fonction. Vous ne pouvez pas modifier le mode de suivi sur une version publiée.
## Activation du traçage avec CloudFormation
Pour activer le suivi d'une `AWS::Lambda::Function` ressource dans un CloudFormation modèle, utilisez la `TracingConfig` propriété.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Pour une `AWS::Serverless::Function` ressource AWS Serverless Application Model (AWS SAM), utilisez la `Tracing` propriété.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
## Interprétation d’un suivi X-Ray
Votre fonction a besoin d’une autorisation pour charger des données de suivi vers X-Ray. Lorsque vous activez le suivi actif dans la console Lambda, Lambda ajoute les autorisations requises au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Sinon, ajoutez la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)politique au rôle d'exécution.
Une fois que vous avez configuré le suivi actif, vous pouvez observer des demandes spécifiques via votre application. Le [ graphique de services X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html#xray-concepts-servicegraph) affiche des informations sur votre application et tous ses composants. L’exemple suivant montre une application dotée de deux fonctions. La fonction principale traite les événements et renvoie parfois des erreurs. La deuxième fonction située en haut traite les erreurs qui apparaissent dans le groupe de journaux de la première et utilise le AWS SDK pour appeler X-Ray, Amazon Simple Storage Service (Amazon S3) et Amazon Logs. CloudWatch
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sample-errorprocessor-servicemap.png)
X-Ray ne trace pas toutes les requêtes vers votre application. X-Ray applique un algorithme d’échantillonnage pour s’assurer que le suivi est efficace, tout en fournissant un échantillon représentatif de toutes les demandes. Le taux d’échantillonnage est 1 demande par seconde et 5 % de demandes supplémentaires. Vous ne pouvez pas configurer ce taux d’échantillonnage X-Ray pour vos fonctions.
Dans X-Ray, un *suivi* enregistre des informations sur une demande traitée par un ou plusieurs *services*. Lambda enregistre deux segments par suivi, ce qui a pour effet de créer deux nœuds sur le graphique du service. L’image suivante met en évidence ces deux nœuds :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/xray-servicemap-function.png)
Le premier nœud sur la gauche représente le service Lambda qui reçoit la demande d’invocation. Le deuxième nœud représente votre fonction Lambda spécifique. L’exemple suivant illustre une trace avec ces deux segments. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Cet exemple développe le segment `AWS::Lambda::Function` pour afficher ses trois sous-segments.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
L’exemple de suivi présenté ici illustre le segment de fonction à l’ancienne. Les différences entre les segments à l’ancienne et de style moderne sont décrites dans les paragraphes suivants.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
Le segment de fonction à l’ancienne contient les sous-segments suivants :
+ **Initialization (Initialisation)** : représente le temps passé à charger votre fonction et à exécuter le [code d’initialisation](foundation-progmodel.md). Ce sous-segment apparaît pour le premier événement traité par chaque instance de votre fonction.
+ **Invocation** – Représente le temps passé à exécuter votre code de gestionnaire.
+ **Overhead (Travail supplémentaire)** – Représente le temps que le fichier d’exécution Lambda passe à se préparer à gérer l’événement suivant.
Le segment de fonction de style moderne ne contient pas de sous-segment `Invocation`. À la place, les sous-segments du client sont directement rattachés au segment de fonction. Pour plus d’informations sur la structure des segments de fonction à l’ancienne et de style moderne, consultez [Comprendre les suivis X-Ray](services-xray.md#services-xray-traces).
Vous pouvez également utiliser des clients HTTP, enregistrer des requêtes SQL et créer des sous-segments personnalisés avec des annotations et des métadonnées. Pour plus d'informations, consultez [AWS X-Ray Kit SDK X-Ray pour Go](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-python.html) dans le *AWS X-Ray Guide du développeur*.
**Tarification**
Vous pouvez utiliser le X-Ray Tracing gratuitement chaque mois jusqu'à une certaine limite dans le cadre du niveau AWS gratuit. Au-delà de ce seuil, X-Ray facture le stockage et la récupération du suivi. Pour en savoir plus, consultez [Pricing AWS X-Ray](https://aws.amazon.com/xray/pricing/) (Tarification).