Comment créer des fonctions Lambda à l'aide de SAM

Bien que Lambda dispose d'un éditeur Web pour mettre à jour vos fonctions, il est destiné aux débutants et n'est pas ce que vous devriez utiliser dans la pratique. La création de fonctions avec des modèles SAM vous permet de déplacer vos fonctions Lambda sur votre contrôle de source et votre pipeline CI / CD existants.

Le problème

Si vous apprenez AWS et Lambda, vous avez probablement vu cette interface:

Il s’agit de l’éditeur Web de Lambda, qui vous permet de modifier la fonction directement à partir de la page de cette fonction. Il est idéal pour les débutants et peut même être largement utilisé pour les petits projets lorsqu'il est étendu avec Cloud9 IDE, qui permet un débogage local et distant.

Cependant, ce n’est pas le réel comme vous devriez écrire des fonctions Lambda, en particulier si vous gérez un backend de microservices entier s'exécutant sur des centaines d'entre eux.

La solution est le modèle d’application sans serveur d’AWS, ou SAM en abrégé. AWS caractérise SAM comme un écureuil, pour une raison quelconque:

En réalité cependant, SAM est un modèle YAML. Dans le modèle, vous définissez votre application et toutes les ressources dont elle a besoin (telles que les fonctions Lambda individuelles). Plutôt que de mettre à jour vos fonctions manuellement, vous pouvez déployer des mises à jour via SAM, qui les gérera pour vous et mettra à jour toutes vos fonctions en même temps.

SAM est une extension d'AWS CloudFormation. Ils partagent la plupart de la même syntaxe, mais SAM est rationalisé et spécialement conçu pour Lambda. Chaque fois qu'une nouvelle modification est apportée et déployée, SAM met à jour la pile CloudFormation qu'il a créée lors du déploiement initial de votre modèle.

Étant donné que SAM n'est qu'un fichier YAML, il peut être suivi et contrôlé en version avec toutes vos fonctions. Cela vous permet de l'incorporer dans un pipeline CI / CD pour automatiser la construction et le déploiement directement à partir de Git. Une fois tout configuré, vous pouvez stocker vos fonctions Lambda dans un référentiel Git, et chaque fois que vous envoyez de nouveaux commits, CodePipeline prend les nouvelles modifications et exécute automatiquement un déploiement SAM pour créer une nouvelle version Lambda. Il est même capable de ralentir le trafic entre les versions à l'aide de l'équilibrage du trafic d'alias, qui peut vous aider à détecter les erreurs avant qu'elles ne deviennent des problèmes.

Si vous souhaitez en savoir plus sur l'utilisation de SAM dans un pipeline CI / CD pour automatiser les déploiements Lambda, vous pouvez lire notre guide ici. Pour l'instant cependant, nous allons nous concentrer sur l'utilisation de SAM lui-même et sur l'exécution de déploiements manuels à partir de l'interface de ligne de commande.

Comment écrire un fichier SAM

Un fichier SAM typique suivra ce format de base:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Specification template describing your function
Resources:
  HelloWorld:
    Type: AWS::Serverless::Function
    Properties:
      Handler:  HelloWorld/index.handler
      Runtime: nodejs8.10

Ce modèle définit simplement quelques variables de configuration, puis, dans la section «Ressources», définit les fonctions Lambda par leur nom. Par exemple, nous créons ici une fonction appelée "HelloWorld". cette fonction s'exécute sur nodejs8.10, et son gestionnaire (point de départ) est situé dans un sous-répertoire dans un index.js fichier.

Nous pouvons enregistrer ce modèle sous template.ymlet placez-le dans un répertoire de projet à côté des répertoires individuels contenant le code de fonction.

ProjectDirectory
  |- template.yml
  |- HelloWorld
      |-index.js

Cela présente déjà un moyen beaucoup plus simple de gérer les fonctions Lambda. Plusieurs fonctions peuvent être regroupées dans un seul modèle et toutes déployées en même temps.

Cependant, Lambda n'est pas qu'un simple code et nécessite beaucoup plus de configuration pour fonctionner. Plus particulièrement, les fonctions Lambda ont besoin d'un événement pour se déclencher. Vous pouvez définir cela dans la section «Propriétés» d'une fonction. Par exemple, pour définir la fonction de déclenchement d'une passerelle API

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Specification template describing your function
Resources:
  HelloWorld:
    Type: AWS::Serverless::Function
    Properties:
      Handler:  HelloWorld/index.handler
      Runtime: nodejs8.10
      Events:
        HelloWorldApi:
          Type: Api
          Properties:
            Path: /helloworld
            Method: GET

Lorsque cela est déployé, une nouvelle passerelle API pour le projet Lambda sera créée automatiquement par SAM dans CloudFormation et liée à la fonction nouvellement créée sur les chemins spécifiés.

SAM prend en charge tous les autres types de sources d'événements de Lambda. Vous pouvez trouver plus de documentation pour les autres types sur la page Github de SAM.

SAM peut également déployer plus que de simples fonctions Lambda. Comme il s'agit d'une extension complète de CloudFormation, vous pouvez déployer d'autres ressources dont votre application aura besoin, toutes à partir de SAM. Par exemple, si vous utilisez Lambda avec API Gateway, vous devez accorder l'autorisation API Gateway pour appeler votre fonction. Vous pouvez le faire avec le bit de code suivant définissant un AWS::Lambda::Permission Ressource:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Specification template describing your function
Resources:
  HelloWorld:
    Type: AWS::Serverless::Function
    Properties:
      Handler:  HelloWorld/index.handler
      Runtime: nodejs8.10
  HelloWorldPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName:
        Fn::GetAtt:
        - HelloWorld
        - Arn
      Principal: apigateway.amazonaws.com
      SourceArn:
        Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:*/*/*/*

C'est un peu plus compliqué, mais en gros, cela accorde à API Gateway l'autorisation d'appeler la fonction dans le FunctionName propriété. le Fn::GetAtt est une fonction intrinsèque, qui renvoie l'ARN de la fonction «HelloWorld», car vous ne saurez pas quel sera l'ARN exact.

Cela ne fait qu'effleurer la surface de tout ce que SAM peut faire. Pour plus d'informations sur la spécification de modèle SAM, vous pouvez consulter le schéma complet sur Github ou lire les guides du développeur AWS pour l'utilisation de SAM.

Déployer un fichier SAM

Pour que le fichier SAM fasse quoi que ce soit, il doit être déployé. Cela est géré automatiquement si vous utilisez CodePipeline, mais vous pouvez également déclencher un déploiement manuellement, ce qui est préférable pour les débutants.

SAM possède sa propre CLI, distincte de celle standard d'AWS. Vous pouvez l'installer à partir de pip:

pip install aws-sam-cli

Tout d'abord, vous devez tout empaqueter et envoyer les artefacts à un compartiment S3:

sam package 
--template-file template.yml 
--output-template-file package.yml 
--s3-bucket bucket-name

Ensuite, vous pouvez exécuter le déploiement à l'aide du modèle de sortie généré à partir de la commande précédente:

sam deploy 
--template-file package.yml 
--stack-name sam-hello-world 
--capabilities CAPABILITY_IAM

Notez que cette commande déploie une pile avec un nom particulier défini par cette commande; rien ne définit le nom de la pile dans le modèle SAM lui-même. Si vous souhaitez déployer une nouvelle pile, vous pouvez modifier ce nom ici. Sinon, gardez le même nom et la pile sera mise à jour à la place.

Une fois le déploiement SAM terminé, vous verrez une nouvelle application avec vos fonctions, ainsi qu'une nouvelle pile dans CloudFormation: