Architecture orientée services avec AWS Lambda : un didacticiel pas à pas

Lors de la création d'applications Web, il existe de nombreux choix à faire qui peuvent soit aider, soit entraver votre application à l'avenir une fois que vous vous y êtes engagé. Des choix tels que la langue, le framework, l'hébergement et la base de données sont cruciaux.

L'un de ces choix consiste à créer une application basée sur les services à l'aide de l'architecture orientée services (SOA) ou une application monolithique traditionnelle. Il s'agit d'une décision architecturale courante affectant les startups, les scale-ups et les grandes entreprises.

L'architecture orientée services est utilisée par un grand nombre de licornes bien connues et d'entreprises de pointe telles que Google, Facebook, Twitter, Instagram et Uber. Apparemment, ce modèle d'architecture fonctionne pour les grandes entreprises, mais peut-il fonctionner pour vous ?

Dans cet article, nous présenterons le sujet de l'architecture orientée services et comment AWS Lambda en combinaison avec Python peut être exploité pour créer facilement des services évolutifs et rentables. Pour illustrer ces idées, nous allons créer un service simple de téléchargement et de redimensionnement d'images à l'aide de Python, AWS Lambda, Amazon S3 et quelques autres outils et services pertinents.

Qu'est-ce que l'architecture orientée services ?

L'architecture orientée services (SOA) n'est pas nouvelle, ses racines remontent à plusieurs décennies. Ces dernières années, sa popularité en tant que modèle a augmenté en raison de l'offre de nombreux avantages pour les applications Web.

La SOA est, par essence, l'abstraction d'une grande application en plusieurs petites applications communicantes. Cela fait suite à plusieurs bonnes pratiques de génie logiciel telles que le découplage, la séparation des préoccupations et l'architecture à responsabilité unique.

Les implémentations de SOA varient en termes de granularité : de très peu de services couvrant de vastes domaines de fonctionnalités à plusieurs dizaines ou centaines de petites applications dans ce que l'on appelle une architecture de « microservices ». Quel que soit le niveau de granularité, ce qui est généralement convenu parmi les praticiens de la SOA, c'est qu'il ne s'agit en aucun cas d'un repas gratuit. Comme de nombreuses bonnes pratiques en génie logiciel, il s'agit d'un investissement qui nécessitera une planification, un développement et des tests supplémentaires.

Qu'est-ce qu'AWS Lambda ?

AWS Lambda est un service proposé par la plateforme Amazon Web Services. AWS Lambda vous permet de charger du code qui sera exécuté sur un conteneur à la demande géré par Amazon. AWS Lambda gérera le provisionnement et la gestion des serveurs pour exécuter le code, donc tout ce dont l'utilisateur a besoin est un ensemble de code à exécuter et quelques options de configuration pour définir le contexte dans lequel le serveur s'exécute. Ces applications gérées sont appelées fonctions Lambda.

AWS Lambda a deux modes de fonctionnement principaux :

Asynchrone/piloté par les événements :

Les fonctions Lambda peuvent être exécutées en réponse à un événement en mode asynchrone. Aucune source d'événements, telle que S3, SNS, etc. ne se bloquera et les fonctions Lambda peuvent en tirer parti de plusieurs manières, par exemple en établissant un pipeline de traitement pour une chaîne d'événements. Il existe de nombreuses sources d'informations et, selon la source, les événements seront poussés vers une fonction Lambda à partir de la source de l'événement ou interrogés pour les événements par AWS Lambda.

Synchrone/Requête->Réponse :

Pour les applications qui nécessitent qu'une réponse soit renvoyée de manière synchrone, Lambda peut être exécuté en mode synchrone. Généralement, cela est utilisé conjointement avec un service appelé API Gateway pour renvoyer les réponses HTTP d'AWS Lambda à un utilisateur final, mais les fonctions Lambda peuvent également être appelées de manière synchrone via un appel direct à AWS Lambda.

Les fonctions AWS Lambda sont téléchargées sous forme de fichier zip contenant le code du gestionnaire en plus de toutes les dépendances requises pour le fonctionnement du gestionnaire. Une fois téléchargé, AWS Lambda exécutera ce code si nécessaire et fera passer le nombre de serveurs de zéro à des milliers si nécessaire, sans aucune intervention supplémentaire requise par le consommateur.

Fonctions Lambda en tant qu'évolution de la SOA

La SOA de base est un moyen de structurer votre base de code en petites applications afin de bénéficier d'une application de la manière décrite précédemment dans cet article. En conséquence, la méthode de communication entre ces applications est mise au point. La SOA pilotée par les événements (alias SOA 2.0) permet non seulement la communication directe traditionnelle de service à service de SOA 1.0, mais également la propagation des événements dans toute l'architecture afin de communiquer les changements.

L'architecture événementielle est un modèle qui favorise naturellement le couplage lâche et la composabilité. En créant et en réagissant aux événements, des services peuvent être ajoutés ad hoc pour ajouter de nouvelles fonctionnalités à un événement existant, et plusieurs événements peuvent être composés pour fournir des fonctionnalités plus riches.

AWS Lambda peut être utilisé comme plate-forme pour créer facilement des applications SOA 2.0. Il existe de nombreuses façons de déclencher une fonction Lambda ; de l'approche traditionnelle de file d'attente de messages avec Amazon SNS, aux événements créés par un fichier chargé sur Amazon S3 ou un e-mail envoyé avec Amazon SES.

Implémentation d'un service de téléchargement d'images simples

Nous allons créer une application simple pour télécharger et récupérer des images à l'aide de la pile AWS. Cet exemple de projet contiendra deux fonctions lambda : une exécutée en mode requête-> réponse qui sera utilisée pour servir notre interface Web simple, et une autre qui détectera les images téléchargées et les redimensionnera.

La première fonction lambda s'exécutera de manière asynchrone en réponse à un événement de téléchargement de fichier déclenché sur le compartiment S3 qui hébergera les images téléchargées. Il prendra l'image fournie et la redimensionnera pour l'adapter à une image 400x400.

L'autre fonction lambda servira la page HTML, fournissant à la fois la fonctionnalité permettant à un utilisateur d'afficher les images redimensionnées par notre autre fonction Lambda ainsi qu'une interface pour télécharger une image.

Configuration AWS initiale

Avant de pouvoir commencer, nous devrons configurer certains services AWS nécessaires tels que IAM et S3. Ceux-ci seront configurés à l'aide de la console Web AWS. Cependant, la majeure partie de la configuration peut également être réalisée à l'aide de l'utilitaire de ligne de commande AWS, que nous utiliserons plus tard.

Création de compartiments S3

S3 (ou Simple Storage Service) est un service de magasin d'objets Amazon qui offre un stockage fiable et économique de toutes les données. Nous utiliserons S3 pour stocker les images qui seront téléchargées, ainsi que les versions redimensionnées des images que nous avons traitées.

Le service S3 se trouve dans la liste déroulante « Services » de la console AWS, sous la sous-section « Stockage et livraison de contenu ». Lors de la création d'un compartiment, vous serez invité à saisir à la fois le nom du compartiment et à sélectionner une région. La sélection d'une région proche de vos utilisateurs permettra à S3 d'optimiser la latence et le coût, ainsi que certains facteurs réglementaires. Pour cet exemple, nous sélectionnerons la région « US Standard ». Cette même région sera ensuite utilisée pour héberger les fonctions AWS Lambda.

Il convient de noter que les noms de compartiment S3 doivent être uniques, donc si le nom choisi est pris, vous devrez choisir un nouveau nom unique.

Pour cet exemple de projet, nous allons créer deux buckets de stockage nommés "test-upload" et "test-resized". Le bucket "test-upload" sera utilisé pour télécharger des images et stocker l'image téléchargée avant qu'elle ne soit traitée et redimensionnée. Une fois redimensionnée, l'image sera enregistrée dans le compartiment "test redimensionné" et l'image brute téléchargée sera supprimée.

Autorisations de téléchargement S3

Par défaut, les autorisations S3 sont restrictives et n'autorisent pas les utilisateurs externes ou même les utilisateurs non administrateurs à lire, écrire, mettre à jour ou supprimer des autorisations ou des objets sur le compartiment. Pour changer cela, nous devrons être connectés en tant qu'utilisateur avec les droits de gestion des autorisations de compartiment AWS.

En supposant que nous sommes sur la console AWS, nous pouvons afficher les autorisations pour notre compartiment de téléchargement en sélectionnant le compartiment par son nom, en cliquant sur le bouton "Propriétés" en haut à droite de l'écran et en ouvrant la section "Autorisations" réduite.

Afin de permettre aux utilisateurs anonymes de télécharger dans ce compartiment, nous devrons modifier la stratégie de compartiment pour autoriser l'autorisation spécifique qui autorise le téléchargement. Ceci est accompli via une politique de configuration basée sur JSON. Ce type de politiques JSON est largement utilisé dans AWS en conjonction avec le service IAM. Après avoir cliqué sur le bouton "Edit Bucket Policy", collez simplement le texte suivant et cliquez sur "Save" pour autoriser les téléchargements d'images publiques :

 { "Version": "2008-10-17", "Id": "Policy1346097257207", "Statement": [ { "Sid": "Allow anonymous upload to /", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::test-upload/*" } ] }

Après cela, nous pouvons vérifier que la stratégie de compartiment est correcte en essayant de télécharger une image dans le compartiment. La commande cURL suivante fera l'affaire :

 curl https://test-upload.s3.amazonaws.com -F 'key=test.jpeg' -F '[email protected]'

Si une réponse de plage 200 est renvoyée, nous saurons que la configuration du compartiment de téléchargement a été appliquée avec succès. Nos compartiments S3 devraient maintenant être (principalement) configurés. Nous reviendrons plus tard sur ce service dans la console afin de connecter nos événements de téléchargement d'image à l'invocation de notre fonction de redimensionnement.

Autorisations IAM pour Lambda

Les rôles Lambda s'exécutent tous dans un contexte d'autorisation, dans ce cas un « rôle » défini par le service IAM. Ce rôle définit toutes les autorisations dont dispose la fonction Lambda lors de son appel. Pour les besoins de cet exemple de projet, nous allons créer un rôle générique qui sera utilisé entre les deux fonctions Lambda. Cependant, dans un scénario de production, une granularité plus fine dans les définitions d'autorisation est recommandée pour garantir que toutes les exploitations de sécurité sont isolées uniquement du contexte d'autorisation qui a été défini.

Le service IAM se trouve dans la sous-section "Sécurité et identité" du menu déroulant "Services". Le service IAM est un outil très puissant pour gérer l'accès aux services AWS, et l'interface fournie peut être un peu écrasante au début si vous n'êtes pas familier avec des outils similaires.

Une fois sur la page du tableau de bord IAM, la sous-section "Rôles" se trouve sur le côté gauche de la page. De là, nous pouvons utiliser le bouton "Créer un nouveau rôle" pour faire apparaître un assistant en plusieurs étapes pour définir les autorisations du rôle. Utilisons « lambda_role » comme nom de notre autorisation générique. Après avoir continué à partir de la page de définition du nom, vous aurez la possibilité de sélectionner un type de rôle. Comme nous n'avons besoin que d'un accès S3, cliquez sur "AWS Service Roles" et dans la zone de sélection, sélectionnez "AWS Lambda". Vous serez présenté avec une page de politiques qui peuvent être attachées à ce rôle. Sélectionnez la politique « AmazonS3FullAccess » et passez à l'étape suivante pour confirmer le rôle à créer.

Il est important de noter le nom et l'ARN (Amazon Resource Name) du rôle créé. Il sera utilisé lors de la création d'une nouvelle fonction Lambda pour identifier le rôle à utiliser pour l'appel de la fonction.

Remarque : AWS Lambda consignera automatiquement toutes les sorties des appels de fonction dans AWS Cloudwatch, un service de journalisation. Si cette fonctionnalité est souhaitée, ce qui est recommandé pour un environnement de production, l'autorisation d'écrire dans un flux de journaux Cloudwatch doit être ajoutée aux stratégies pour ce rôle.

Le code!

Aperçu

Nous sommes maintenant prêts à commencer à coder. Nous supposerons à ce stade que vous avez configuré la commande "awscli". Si ce n'est pas le cas, vous pouvez suivre les instructions sur https://aws.amazon.com/cli/ pour configurer awscli sur votre ordinateur.

Remarque : le code utilisé dans ces exemples est raccourci pour faciliter la visualisation à l'écran. Pour une version plus complète, visitez le référentiel à l'adresse https://github.com/gxx/aws-lambda-python/.

Tout d'abord, mettons en place une structure squelette pour notre projet.

 aws-lambda-python/ - image_list/ - handler.py - list.html - Makefile - requirements.txt - image_resize/ - handler.py - resize.py - Makefile - requirements.txt - .pydistutils.cfg

Nous avons deux sous-répertoires dans notre structure, un pour chacune de nos fonctions lambda. Dans chacun d'eux, nous avons les fichiers communs handler.py, Makefile et requirements.txt. Le fichier handler.py contiendra la méthode à appeler lors de l'invocation de chacune des fonctions lambda, et peut être considéré comme le point d'entrée des fonctions. Le fichier requirements.txt contiendra une liste de nos dépendances, afin que nous puissions facilement spécifier et mettre à jour les exigences. Enfin, la commande Makefile que nous utiliserons pour fournir un mécanisme simple d'interaction avec awscli. Cela facilitera grandement le processus de création et de mise à jour de notre fonction lambda.

Vous remarquerez le fichier .pydistutils.cfg à la racine de notre répertoire de projet. Ce fichier est requis si vous travaillez avec Python sous Homebrew. En raison de la méthode de déploiement d'une fonction Lambda (traitée dans la section suivante), ce fichier est nécessaire. Voir le dépôt pour plus de détails.

Fonction Lambda de redimensionnement de l'image

Code

En commençant par la fonction resize_image, nous allons geler la dépendance Wand, notre bibliothèque de traitement d'image, en enregistrant Wand==0.4.2 dans requirements.txt. Ce sera la seule dépendance pour notre fonction lambda image_resize. La fonction resize_image dans resize.py devra gérer une ressource image de la bibliothèque Wand et la redimensionner en fonction des paramètres de largeur et de hauteur spécifiés. Afin de préserver l'image qui est redimensionnée, nous utiliserons un algorithme de redimensionnement "best-fit" qui maintiendra le rapport d'image de l'image d'origine, tout en réduisant la taille de l'image pour l'adapter à la largeur et à la hauteur spécifiées.

 def resize_image(image, resize_width, resize_height): ... original_ratio = image.width / float(image.height) resize_ratio = resize_width / float(resize_height) # We stick to the original ratio here, regardless of what the resize ratio is if original_ratio > resize_ratio: # If width is larger, we base the resize height as a function of the ratio of the width resize_height = int(round(resize_width / original_ratio)) else: # Otherwise, we base the width as a function of the ratio of the height resize_width = int(round(resize_height * original_ratio)) if ((image.width - resize_width) + (image.height - resize_height)) < 0: filter_name = 'mitchell' else: filter_name = 'lanczos2' image.resize(width=resize_width, height=resize_height, filter=filter_name, blur=1) return image

Avec cela à l'écart, une fonction de gestionnaire est nécessaire pour accepter l'événement généré par une image téléchargée S3, le transmettre à la fonction resize_image et enregistrer l'image redimensionnée résultante.

 from __future__ import print_function import boto3 from wand.image import Image from resize import resize_image def handle_resize(event, context): # Obtain the bucket name and key for the event bucket_name = event['Records'][0]['s3']['bucket']['name'] key_path = event['Records'][0]['s3']['object']['key'] response = boto3.resource('s3').Object(bucket_name, key_path).get() # Retrieve the S3 Object # Perform the resize operation with Image(blob=response['Body'].read()) as image: resized_data = resize_image(image, 400, 400).make_blob() # And finally, upload to the resize bucket the new image s3_connection.Object('test-resized', key_path).put(ACL='public-read', Body=resized_data) # Finally remove, as the bucket is public and we don't want just anyone dumping the list of our files! s3_object.delete()

Déploiement

Une fois le code terminé, il devra être chargé sur Amazon Lambda en tant que nouvelle fonction Lambda. C'est là que le Makefile qui a été ajouté à la structure du répertoire entre en jeu. Ce Makefile sera utilisé pour déployer les définitions de fonctions Lambda que nous créons.

 ROLE_ARN = arn:aws:iam::601885388019:role/lambda_role FUNCTION_NAME = ResizeImage REGION = us-west-1 TIMEOUT = 15 MEMORY_SIZE = 512 ZIPFILE_NAME = image_resize.zip HANDLER = handler.handle_resize clean_pyc : find . | grep .pyc$ | xargs rm install_deps : pip install -r requirements.txt -t . build : install_deps clean_pyc zip $(ZIPFILE_NAME) -r * create : build aws lambda create-function --region $(REGION) \ --function-name $(FUNCTION_NAME) \ --zip-file fileb://$(ZIPFILE_NAME) \ --role $(ROLE_ARN) \ --handler $(HANDLER) \ --runtime python2.7 \ --timeout $(TIMEOUT) \ --memory-size $(MEMORY_SIZE) update : build aws lambda update-function-code --region $(REGION) \ --function-name $(FUNCTION_NAME) \ --zip-file fileb://$(ZIPFILE_NAME) \ --publish

Les fonctions principales de ce Makefile sont « créer » et « mettre à jour ». Ces fonctions regroupent d'abord le répertoire actuel, qui représente tout le code nécessaire pour exécuter la fonction Lambda. Ensuite, toutes les dépendances spécifiées dans le fichier requirements.txt seront installées dans le sous-répertoire actuel pour être empaquetées. L'étape d'empaquetage comprime le contenu du répertoire pour le télécharger ultérieurement avec la commande « awscli ». Notre Makefile peut être adapté pour être utilisé dans l'autre définition de fonction Lambda.

Dans l'utilitaire Makefile, nous définissons quelques variables nécessaires à la création/mise à jour de notre image. Configurez-les si nécessaire pour que les commandes Makefile fonctionnent correctement pour vous.

• ROLE_ARN : il s'agit de l'Amazon Resource Name qui identifie notre rôle sous lequel exécuter la fonction Lambda.
• FUNCTION_NAME : le nom de la fonction Lambda que nous créons/mettons à jour.
• REGION : la région dans laquelle la fonction Lambda sera créée/mise à jour.
• TIMEOUT : délai d'expiration en secondes avant qu'une invocation Lambda ne soit supprimée.
• MEMORY_SIZE : taille de la mémoire en mégaoctets à laquelle la fonction Lambda aura accès lorsqu'elle sera invoquée.
• ZIPFILE_NAME : nom du package compressé contenant le code de la fonction Lambda et ses dépendances.
• HANDLER : le chemin d'importation absolu, en notation pointée, de la fonction de gestionnaire.

Une fois configuré, l'exécution de la commande make create générera quelque chose de similaire à la sortie suivante :

 $ make create pip install -r requirements.txt -t . ... find . | grep .pyc| xargs rm zip image_resize.zip -r * ... aws lambda create-function --region ap-northeast-1 \ --function-name ResizeImage2 \ --zip-file fileb://image_resize.zip \ --role arn:aws:iam::11111111111:role/lambda_role \ --handler handler.handle_resize \ --runtime python2.7 \ --timeout 15 \ --memory-size 512 { "CodeSha256": "doB1hsujmZnxZHidnLKP3XG2ifHM3jteLEBvsK1G2nasKSo=", "FunctionName": "ResizeImage", "CodeSize": 155578, "MemorySize": 512, "FunctionArn": "arn:aws:lambda:us-west-1:11111111111:function:ResizeImage", "Version": "$LATEST", "Role": "arn:aws:iam::11111111111:role/lambda_role", "Timeout": 15, "LastModified": "2016-01-10T11:11:11.000+0000", "Handler": "handler.handle_resize", "Runtime": "python2.7", "Description": "" }

Essai

Après avoir exécuté la commande de création, la fonction de redimensionnement de nos images est disponible pour être utilisée, mais elle n'a pas été connectée au compartiment S3 afin de recevoir des événements. Nous pouvons toujours tester la fonction via la console AWS pour affirmer que la fonction gère correctement les événements de téléchargement de fichiers S3. Sur le tableau de bord AWS Lambda, qui se trouve dans la sous-section "Calcul" du menu déroulant "Services", sélectionnez le nom de la fonction que nous avons créée. Cette page de détails de la fonction Lambda fournit une liste déroulante intitulée « Actions » contenant une option intitulée « Configure Test Event ».

Cliquer dessus ouvrira un modal vous permettant de spécifier un événement de test et quelques exemples de modèles. Choisissez l'exemple "S3 Put" et remplacez toute mention d'un nom de compartiment par le nom du compartiment qui a été configuré. Une fois que cela a été configuré, l'utilisation ultérieure du bouton « Tester » sur la page de la fonction Lambda appellera la fonction Lambda comme si l'événement précédemment configuré s'était réellement produit.

Afin de surveiller les traces de pile d'erreurs ou les messages de journal, vous pouvez afficher le flux de journal dans Cloudwatch. Un nouveau groupe de journaux aura été créé en même temps que la fonction Lambda a été créée. Ces flux de journaux sont utiles et peuvent être redirigés vers d'autres services.

Connexion aux événements de compartiment S3

De retour dans le tableau de bord S3, développez la section "Événements" réduite située dans le menu "Propriétés" pour afficher le formulaire "Notifications d'événements". Les champs obligatoires que nous devons remplir sont les entrées « Événements » et « Envoyer à ». Dans "Événements", sélectionnez l'événement "Objet créé (Tous)". Cela permettra l'interception de tous les événements qui créent un objet sur le compartiment de téléchargement. Pour l'entrée "Envoyé à", sélectionnez le bouton radio "Fonction Lambda". Une nouvelle section apparaîtra avec une liste déroulante contenant la fonction lambda "ResizeImage" que nous avons configurée en option. En cliquant sur « Enregistrer », tout événement « Objet créé » sera désormais acheminé en tant qu'entrée vers l'appel de la fonction Lambda « ResizeImage ».

Nous avons maintenant la fonctionnalité de base de l'application. Exécutons un autre test cURL pour nous assurer que tout fonctionne comme prévu. Utilisez cURL pour charger une image dans le compartiment S3 et vérifiez manuellement que l'image est chargée dans le compartiment de redimensionnement.

 curl https://test-upload.s3.amazonaws.com -F 'key=test.jpeg' -F '[email protected]'

Lors de l'exécution de cette commande, l'image redimensionnée doit être créée dans le compartiment "test-resized" après 50 à 1 000 ms, selon que la fonction Lambda a déjà été "réchauffée".

Fonction Lambda de l'image de liste

Code

La fonction ListImage Lambda récupère une liste d'images redimensionnées et les affiche sur une page HTML pour l'utilisateur. Cette page HTML fournit également la fonctionnalité permettant à l'utilisateur de télécharger ses propres images. Jinja2 est utilisé dans la fonction pour rendre le HTML à partir d'une définition de modèle. Comme auparavant, ces exigences sont spécifiées dans le fichier requirements.txt .

 from __future__ import print_function import os import boto3 from jinja2 import Environment from jinja2 import FileSystemLoader def _render_template(image_urls): env = Environment(loader=FileSystemLoader(os.path.abspath(os.path.dirname(__file__)))) template = env.get_template('list.html') rendered_template = template.render(image_urls=image_urls) return rendered_template def handle_list_image(event, context): bucket = boto3.resource('s3').Bucket('test-resized') image_summaries = sorted((image_summary for image_summary in bucket.objects.all()), key=lambda o: o.last_modified) image_urls = [] for summary in image_summaries: image_urls.append( boto3.client('s3').generate_presigned_url( 'get_object', Params={ 'Bucket': summary.bucket_name, 'Key': summary.key } ) ) return {'htmlContent': _render_template(image_urls)}

 <html> <head> <title>List Images</title> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script> <script> var uploadImage = (function () { var inProgress = false; return function () { if (inProgress) { return; } inProgress = true; var formData = new FormData(); var fileData = $('#image-file').prop('files')[0]; formData.append('key', parseInt(Math.random() * 1000000)); formData.append('acl', 'public-read'); formData.append('file', fileData); $.ajax({ url: 'https://test-upload.s3.amazonaws.com/', type: 'POST', data: formData, processData: false, contentType: false, success: function (data) { window.location.reload(); } }); } })(); </script> <style type="text/css"> .image__container { float: left; width: 30%; margin-left: 2.5%; margin-right: 2.5%; max-width: 400px; } </style> </head> <body> <nav> <input type="file" onchange="uploadImage()" value="Upload Image" /> </nav> <section> {% for image_url in image_urls %} <div class="image__container"> <img src="{{ image_url }}" /> </div> {% endfor %} </section> </body> </html>

Encore une fois, nous pouvons modifier le Makefile précédent et utiliser la commande create pour déployer notre fonction lambda.

Passerelle API

La fonction ImageList Lambda est terminée, mais elle ne peut être servie à aucun utilisateur. En effet, les fonctions Lambda ne peuvent être appelées qu'en réponse à un événement d'un autre service ou par programmation. C'est là que le service Amazon AWS API Gateway entre en place. API Gateway se trouve dans la sous-section "Services d'application".

API Gateway est un moyen de modéliser les points de terminaison comme un ensemble de ressources et de méthodes, essentiellement une interface REST. En plus de fournir une fonction de validation et de transformation des demandes, API Gateway exécute d'autres fonctions telles que la fourniture de demandes de limitation/limitation du débit.

À partir du tableau de bord API Gateway, créez une nouvelle API pour servir la fonction ListImage. Le nom et la description peuvent être définis selon vos préférences. Une fois créée, cliquez sur le nom de la nouvelle API pour accéder aux détails de l'API. Créez une nouvelle ressource pour l'URL racine "/". Cette URL sera utilisée pour servir la page HTML.

Lors de l'affichage des détails de la page de ressource racine, ajoutez une méthode GET. Définissez le «Type d'intégration» sur «Fonction Lambda», définissez la «Région Lambda» sur «us-west-1» ou la région que vous avez sélectionnée, puis saisissez le nom de la fonction ListImage Lambda.

Avant de pouvoir commencer à mapper notre réponse à une sortie HTML, nous devons définir un "modèle" qui définira un schéma pour la réponse du serveur en plus de mapper cette réponse à un type de contenu. Sélectionnez la section "Modèles" pour l'API et cliquez sur "Créer" pour créer un nouveau modèle. Donnez au modèle le nom « HTML », avec un type de contenu de « text/html » et définissez le schéma comme suit :

 { "$schema": "http://json-schema.org/draft-04/schema#", "title" : "HTML", "type" : "object" }

De retour sur le tableau de bord de l'API, sélectionnez la ressource que nous avons créée et accédez à la section "Réponse d'intégration". Cette section définit toute transformation à traiter après avoir reçu une réponse de la fonction Lambda avant de diriger la réponse vers l'étape finale.

Ouvrez la section "Mapping Templates" et ajoutez un nouveau "Content Type" de "text/html". Supprimez l'ancien "Type de contenu" en même temps. Sur la droite, changez le menu déroulant de "Output Passthrough" à "Mapping template". Cela nous permettra de modifier le JSON brut accepté par API Gateway et d'utiliser à la place le contenu HTML dans la propriété "htmlContent" de nos données renvoyées. Pour le modèle de mappage, spécifiez "$input.htmlContent" comme modèle. Enfin, modifiez la section "Method Response" en supprimant "application/json" de "Response Models for 200" et en ajoutant "text/html" à la place.

En revenant au tableau de bord de l'API, il y a un bouton en haut à gauche de la page intitulé "Déployer l'API". Cliquez sur ce bouton pour mettre à jour ou créer l'API avec les ressources, méthodes, modèles et mappages spécifiés. Une fois cela fait, une URL sera affichée pour l'étape de déploiement qui a été sélectionnée (étape par défaut). Enfin, l'exemple est complet ! Vous pouvez télécharger quelques fichiers pour tester et afficher les images redimensionnées.

Emballer

AWS est un grand service et ne va pas disparaître de sitôt. Bien qu'il faille toujours faire attention au verrouillage du fournisseur, AWS Lambda offre un service relativement léger avec un riche ensemble d'options de configuration auxiliaires. Tirer parti des services fournis par AWS pour mettre en œuvre des applications facilement évolutives et maintenables offrira le plus grand avantage de l'utilisation de la plate-forme AWS. AWS Lambda fournit une solution élégante, évolutive et économique soutenue par une plate-forme de niveau entreprise utilisée par un très grand nombre de consommateurs. Je crois que les applications "sans serveur" sont la voie de l'avenir. Faites-nous savoir ce que vous pensez dans les commentaires ci-dessous.