Introduction au modèle d’application AWS Serverless

CloudFormation est un service AWS pour le provisionnement automatique des ressources d'infrastructure AWS. Un utilisateur définit toutes les ressources requises dans un plan directeur (appelé modèle) et AWS se charge de l'approvisionnement et de la configuration.

Les termes et concepts suivants sont essentiels pour comprendre CloudFormation et SAM:

A template is a description of an application, comment il doit être structuré à l'exécution. Nous pouvons définir un ensemble de ressources requises, ainsi que la manière dont ces ressources doivent être configurées. CloudFormation fournit un langage commun pour la définition de modèles, prenant en charge JSON et YAML en tant que format.

Resources are the building blocks in CloudFormation. Une ressource peut être n'importe quoi, comme un RestApi, une étape d'un RestApi, un Batch Job, une table DynamoDB, une instance EC2, une interface réseau, un rôle IAM et bien d'autres. The official documentation répertorie actuellement environ 300 types de ressources pour CloudFormation.

A stack is the instantiation of a template. CloudFormation prend en charge l'approvisionnement et la configuration de la pile.

Comme souvent, l’utilisation d’outils puissants peut devenir très complexe et peu pratique, comme dans le cas de CloudFormation.

C'est pourquoi Amazon a introduit le modèle SAM (Serverless Application Model). SAM started with the claim to provide a clean and straightforward syntax for defining serverless applications. Currently, it has only three resource types, which are Lambda functions, DynamoDB tables, and APIs.

SAM est basé sur la syntaxe du modèle CloudFormation. Nous pouvons donc définir notre modèle à l'aide de la syntaxe SAM simple. CloudFormation traitera ensuite ce modèle.

Plus de détails sont disponiblesat the official GitHub repository ainsi que dans lesAWS documentation.

Tout d'abord, examinons la structure globale de notre modèle:

Comme on peut le constater, le modèle consiste en un en-tête et un corps:

L'en-tête spécifie la version du modèle CloudFormation (AWSTemplateFormatVersion) ainsi que la version de notre modèle SAM (Transform). Nous pouvons également spécifier unDescription.

Le corps se compose d'un ensemble de ressources: chaque ressource a un nom, une ressourceType et un ensemble deProperties.

La spécification SAM prend actuellement en charge trois types:AWS::Serverless::Api,AWS::Serverless::Function ainsi queAWS::Serverless::SimpleTable.

Comme nous voulons déployer nosexample application, nous devons définir unSimpleTable, deuxFunctions, ainsi qu'unApi dans notre template-body.

Définissons maintenant notre table DynamoDB:

Il suffit de définir deux propriétés pour nosSimpleTable: le nom de la table, ainsi qu'une clé primaire, qui s'appelleid et a le typeNumber dans notre cas.

Une liste complète des propriétésSimpleTable prises en charge peut être trouvéein the official specification.

Remarque: comme nous voulons uniquement accéder à la table en utilisant la clé primaire, lesAWS::Serverless::SimpleTable nous suffisent. Pour des exigences plus complexes, le type CloudFormation natifAWS::DynamoDB::Table peut être utilisé à la place.

Ensuite, définissons nos deux fonctions:

Comme on peut le constater, chaque fonction a les mêmes propriétés:

Handler defines the logic of the function. Comme nous utilisons Java, c'est le nom de la classe incluant le package, en relation avec le nom de la méthode.

Runtime defines how the function was implemented, qui est Java 8 dans notre cas.

Timeout defines how long the execution of the code may take at most avant qu'AWS ne termine l'exécution.

MemorySizedefines the size of the assigned memory in MB. Il est important de savoir qu'AWS attribue les ressources CPU proportionnellement àMemorySize. Ainsi, dans le cas d’une fonction gourmande en ressources processeur, il peut être nécessaire d’augmenter lesMemorySize, même si la fonction n’a pas besoin de beaucoup de mémoire.

CodeUridefines the location of the function code. Il fait actuellement référence au dossier cible dans notre espace de travail local. Lorsque nous téléchargerons notre fonction ultérieurement à l'aide de CloudFormation, nous obtiendrons un fichier mis à jour avec une référence à un objet S3.

Policiescan hold a set of AWS-managed IAM policies or SAM-specific policy templates. Nous utilisons les politiques spécifiques SAMDynamoDBCrudPolicy pour lesStorePersonFunction etDynamoDBReadPolicy pour lesGetPersonByPathParamFunction etGetPersonByQueryParamFunction.

Environmentdefines environment properties at runtime. Nous utilisons une variable d'environnement pour contenir le nom de notre table DynamoDB.

Eventscan hold a set of AWS events, which shall be able to trigger the function. Dans notre cas, nous définissons unEvent de typeApi. La combinaison unique depath, d'un HTTPMethod et d'unRestApiId relie la fonction à une méthode de notre API, que nous définirons dans la section suivante.

Une liste complète des propriétésFunction prises en charge peut être trouvéein the official specification.

Après avoir défini la table et les fonctions DynamoDB, nous pouvons maintenant définir l’API.

La première possibilité consiste à définir notre API en ligne en utilisant le format Swagger:

NotreApi partage trois propriétés:StageNamedéfinit l'étape de l'API,EndpointConfiguration définit si l'API est régionale ou optimisée en périphérie, etDefinitionBody contient la structure réelle de l'API.

Dans lesDefinitionBody, nous définissons trois paramètres: laswagger version en“2.0”, lesinfo:title: en“TestAPI”, ainsi qu'un ensemble depaths .

Comme on peut le voir, lespaths représentent la structure de l'API, que nous avons dû définir manuellementbefore. Lespaths dans Swagger sont équivalents aux ressources de la console AWS. Juste comme ça, chaquepath peut avoir un ou plusieurs verbes HTTP, qui sont équivalents aux méthodes de l'AWS Console.

Chaque méthode peut avoir un ou plusieurs paramètres ainsi qu'un validateur de requête.

La partie la plus intéressante est l'attributx-amazon-apigateway-integration, qui est une extension spécifique à AWS de Swagger:

uri spécifie quelle fonction Lambda doit être appelée.

responses spécifie les règles de transformation des réponses renvoyées par la fonction. Comme nous utilisons l'intégration du proxy Lambda, nous n'avons besoin d'aucune règle spécifique.

type définit que nous voulons utiliser l'intégration du proxy Lambda, et par conséquent, nous devons définirhttpMethod sur“POST”, car c'est ce à quoi s'attendent les fonctions Lambda.

Une liste complète des propriétésApi prises en charge peut être trouvéein the official specification.

Une deuxième option consiste à définir l'API implicitement dans les ressources Function:

Comme nous pouvons le voir, notre modèle est légèrement différent maintenant: il n'y a plus de ressourceAWS::Serverless::Api .

Cependant, CloudFormation prend les attributsEvents de typeApi comme une définition implicite et crée quand même une API. Dès que nous testons notre application, nous verrons qu'elle se comporte de la même manière que lors de la définition explicite de l'API à l'aide de Swagger.

De plus, il existe une sectionGlobals, où nous pouvons définir le nom de notre API, ainsi que le fait que notre point de terminaison doit être régional.

Une seule limitation survient: lors de la définition implicite de l'API, nous ne pouvons pas définir de nom d'étape. C'est pourquoi AWS créera dans tous les cas une étape appeléeProd.

Dans un premier temps, nous devons télécharger le code de fonction sur S3.

Nous pouvons le faire en appelant CloudFormation via l'AWS CLI:

Avec cette commande, nous déclenchons CloudFormation pour prendre le code de fonction spécifié dansCodeUri: et pour le télécharger sur S3. CloudFormation créera un fichierpackaged-template.yml, qui a le même contenu, sauf queCodeUri: pointe maintenant vers l'objet S3.

Jetons un œil à la sortie CLI:

Maintenant, nous pouvons déclencher le déploiement réel:

Comme notre pile a également besoin de rôles IAM (comme les rôles des fonctions pour accéder à notre table DynamoDB), nous devons explicitement le reconnaître en spécifiant les–capabilities parameter.

Et la sortie de la CLI devrait ressembler à:

Après le déploiement, nous pouvons examiner le résultat:

CloudFormation listera toutes les ressources qui font partie de notre pile.

Enfin, nous pouvons tester notre application en utilisant n’importe quel client HTTP.

Voyons quelques exemples de commandescURL que nous pouvons utiliser pour ces tests.

StorePersonFunction:

GetPersonByPathParamFunction:

GetPersonByQueryParamFunction:

Au final, nous pouvons nettoyer en supprimant la pile et toutes les ressources incluses: