Implémentation de fonctions Node.js sans serveur à l'aide de Google Cloud

Publié: 2022-03-11

La création de logiciels ne s'arrête pas à l'écriture d'un bon code. Il est terminé lorsque le logiciel est déployé et capable de gérer correctement les demandes et lorsque nous pouvons évoluer sans entraver les performances et le coût de son fonctionnement.

Vous pensez probablement à la façon dont vous avez le cloud computing pour prendre soin de toutes ces choses. "Alors, quelle est cette nouvelle chose sans serveur , Vignes?"

Fonctions Node.js sans serveur à l'aide de Google Cloud

L'informatique sans serveur est un style d'architecture dans lequel le code est exécuté sur une plate-forme cloud où nous n'avons pas à nous soucier de la configuration matérielle et logicielle, de la sécurité, des performances et des coûts de temps d'inactivité du processeur. C'est une avancée du cloud computing qui va au-delà de l'infrastructure qui fait également abstraction de l'environnement logiciel. Cela signifie qu'aucune configuration n'est requise pour exécuter le code.

Avec le serverless, voici votre style de travail :

  1. Développer le code.

  2. Téléchargez le code au fournisseur de services.

  3. Configurez le déclencheur (une requête HTTP, dans notre cas).

Notre travail est terminé ! Désormais, le fournisseur de plateforme s'occupera des demandes entrantes et de la mise à l'échelle.

Introduction aux microservices sans serveur

L'architecture sans serveur est souvent associée à une conception de style microservices. Un microservice est une partie autonome d'un gros logiciel qui gère les demandes d'un module spécifique. En créant des microservices pouvant s'exécuter dans un environnement sans serveur, il devient facile de maintenir le code et d'accélérer les déploiements.

Introduction à AWS Lambda & GCF, une comparaison

Une fonctionnalité sans serveur est souvent appelée "back-end en tant que service" ou "fonction en tant que service". Le nombre de fournisseurs d'informatique sans serveur commence à augmenter. Cependant, certains des grands acteurs traditionnels proposent également des options sans serveur, telles que les fonctions AWS Lambda d'Amazon Web Services et les fonctions Google Cloud (GCF) de Google Cloud , dont la dernière, bien qu'actuellement en version bêta, est celle que j'utilise. Bien qu'ils fonctionnent de la même manière, il existe quelques différences importantes entre eux.

AWS Lambda Fonctions Google Cloud
Support linguistique Node.js, Python, C#, Java Node.js
Déclencheurs DynamoDB, Kinesis, S3, SNS, passerelle API (HTTP), CloudFront, et plus HTTP, Cloud PubSub, bucket de stockage dans le cloud
Temps d'exécution maximal 300 secondes 540 secondes

Dans cet article, nous allons passer en revue le processus de mise en œuvre du déploiement de code sans serveur à l'aide de GCF. Google Cloud Functions est une solution de calcul asynchrone légère, basée sur les événements, qui vous permet de créer de petites fonctions à usage unique qui répondent aux événements cloud sans avoir à gérer un serveur ou un environnement d'exécution.

GCF a trois implémentations possibles séparées en fonction des déclencheurs.

  1. Déclencheur HTTP Achemine les requêtes HTTP vers les fonctions cloud

  2. Déclencheur pub/sub interne de Google Achemine les demandes de publication et d'abonnement vers les fonctions cloud

  3. Déclencheur de bucket de stockage cloud Achemine toutes les modifications apportées au bucket de stockage vers la fonction cloud

Créons une configuration basée sur un déclencheur HTTP à l'aide de Google Cloud Functions

Google Cloud Functions ne nécessite aucune configuration ou installation spéciale supplémentaire. GCF garantit que l'environnement de nœud par défaut est configuré et prêt à être exécuté. Lorsqu'une fonction cloud est créée avec HTTP comme déclencheur, elle fournit une URL pour déclencher la fonction. Par rapport à AWS Lambda, qui utilise une passerelle API comme moyen de communication avec lui, Google Cloud Functions fournit l'URL immédiatement en fonction de l' projectID du projet et de la région.

Schéma de Google Cloud Platform - Cloud Functions & AWS Lambda

Création d'une application Node.js sans serveur

Pour rendre notre code exécutable dans GCF, nous devons encapsuler le code dans une seule fonction. GCF appellera cette fonction particulière chaque fois que le déclencheur se produira. Les moyens possibles de le faire sont le téléchargement,

  1. Fichier unique : exportez une fonction par défaut qui appellera d'autres fonctions en fonction de la demande.

  2. Fichiers multiples : avoir un fichier index.js nécessitant tous les autres fichiers et exportant la fonction par défaut comme point de départ.

  3. Fichiers multiples : avoir un fichier principal configuré dans package.json en utilisant "main": "main.js" comme point de départ.

Toutes les méthodes ci-dessus fonctionneront.

GCF a une version d'exécution Node particulière prise en charge. Assurez-vous que le code est écrit pour prendre en charge cette version particulière. Au moment de la création de cet article, GCF prend en charge la version v6.11.1 de Node.

Pour créer une fonction, il y a peu d'options à considérer.

  1. Mémoire Cela indique la quantité de mémoire nécessaire pour traiter la demande pendant une exécution. Défini en Mo. Pour une petite application, 128 Mo devraient être tout à fait suffisants, mais peuvent être augmentés jusqu'à 2 Go.

  2. Timeout Timeout, comme son nom l'indique, définit le délai d'attente d'exécution du code attendu. Après cela, le code sera tué et arrêté. Toute exécution après ce point s'arrêtera brusquement. Le délai maximum est de 540 secondes.

  3. Fonction à exécuter Bien que plusieurs fonctions puissent être exportées depuis le fichier du gestionnaire principal, nous devons configurer une fonction qui doit être déclenchée pour traiter la requête. Cela permet au développeur d'avoir plusieurs points d'entrée basés sur la méthode HTTP/URL.

Pour uploader le code, il suffit de faire un copier-coller du code pour créer un portail de fonction. Pour plus d'un fichier, compressez le contenu et téléchargez le fichier. Assurez-vous que, dans le cas d'un fichier ZIP, il devrait y avoir soit un fichier index.js , soit un fichier package.json avec le fichier principal mentionné.

Toute dépendance de module NPM doit être mentionnée dans package.json . GCF tente d'installer les modules mentionnés dans le fichier package.json lors de la première installation.

Créons un gestionnaire simple pour renvoyer un statut 200 et un message. Créez une fonction et ajoutez le code suivant à la source.

 exports.httpServer = function httpServer(req, res) { console.log(req); res.status(200).send('Server is working'); } 

Capture d'écran de la fonction en cours de création

Une fois la fonction créée, ouvrez l'URL fournie pour déclencher la fonction. Il devrait répondre comme suit.

Capture d'écran de la sortie du navigateur "Le serveur fonctionne"

Examinons maintenant l'objet req dans les journaux. Pour afficher les journaux, GCF fournit des options directement depuis la console. Cliquez sur les points verticaux et ouvrez l'option journaux.

Capture d'écran de l'ouverture de l'option de journaux

Maintenant, mettons à jour le code pour gérer les routes simples pour /users .

Le code suivant est utilisé pour gérer une simple requête GET & POST pour la route /users :

 exports.httpServer = function httpServer(req, res) { const path = req.path; switch(path) { case '/users': handleUsers(req, res); break; default: res.status(200).send('Server is working'); } }; const handleUsers = (req, res) => { if (req.method === 'GET') { res.status(200).send('Listing users...'); } else if (req.method === 'POST') { res.status(201).send('Creating User...') } else { res.status(404); } }

Après la mise à jour, testons-le maintenant dans le navigateur, mais cette fois avec /users à la fin.

Capture d'écran de la sortie du navigateur "Liste des utilisateurs..."

C'est super. Nous avons créé un serveur HTTP de base avec routage.

Opérations et débogage

Si le code était là où l'histoire se terminait, vous ne rechercheriez pas d'options d'infrastructure comme les applications Node.js sans serveur. Voici un bref résumé de la façon de prendre en charge les tâches courantes telles que le déploiement et le débogage. Ce que les développeurs Node.js font déjà pour d'autres applications.

Déploiement:

Le code des fonctions peut être déployé de quatre manières.

  • Copier coller le code dans la console

  • Téléchargement d'un fichier ZIP

  • Déploiement à partir du compartiment de stockage cloud sous forme de fichier ZIP

  • Déploiement à partir du référentiel source cloud

L'option la plus pratique consiste évidemment à déployer à partir d'un référentiel source.

Invocation:

Lors de la création de la fonction, la console fournit l'URL HTTP pour déclencher la fonction qui est au format : https://<region>-<project-id>.cloudfunctions.net/<function-name>

La fonction d'AWS Lambda présente des problèmes de démarrage à froid qui font que l'exécution de la fonction prend plus de temps pour démarrer. Une fois lancées, les exécutions suivantes répondront normalement. Ce temps de démarrage supplémentaire initial est appelé démarrage à froid. Bien que nous ne disposions pas de la documentation officielle de GCF relative à ce sujet, les problèmes de démarrage à froid ne sont pas apparus lors de nos tests.

Débogage :

GCF s'intègre au service Stackdriver Logging dans Google Cloud. Tous les journaux et erreurs de la console seront consignés ici, et cela aide à déboguer le code qui est déjà déployé.

Essai:

La console fournit des options pour tester la fonction en passant un JSON en entrée. La fonction sera appelée avec JSON comme entrée et la sortie sera affichée dans la console. La requête (entrée) et la réponse sont similaires au framework Express.js et peuvent être testées à l'unité pendant le processus de développement lui-même. Si vous avez besoin d'un rappel sur les tests Node.js, consultez Un guide Node.js pour effectuer réellement des tests d'intégration

Limitations et prochaines étapes

L'utilisation de fonctions sans serveur a ses propres avantages, elle comporte également des limitations

  • Verrouillage du fournisseur : il limite le code que nous écrivons à un fournisseur de services particulier. Déplacer le code vers un autre fournisseur nécessite de réécrire le code avec des efforts importants vers la migration. Comme cela peut être un gros problème, nous devons être très prudents lors du choix d'un fournisseur de services.

  • Limitations du nombre de requêtes et de ressources matérielles : les fournisseurs limitent souvent le nombre de requêtes parallèles qu'une fonction traitera à la fois. Il existe également des restrictions de mémoire. Ces types de restrictions peuvent être augmentées en parlant au fournisseur, mais elles existeront toujours.

Google Cloud Functions mûrit et s'améliore beaucoup. Il est encore amélioré et mis à jour fréquemment, en particulier dans les langues qu'il peut prendre en charge. Si vous envisagez d'utiliser les fonctions de Google Cloud, gardez un œil sur les journaux des modifications pour éviter toute modification avec rupture dans l'implémentation.


Lectures complémentaires sur le blog Toptal Engineering :

  • Utilisation de TypeScript et de la prise en charge de Jest : un didacticiel AWS SAM