arrow_back

Créer un système résilient et asynchrone à l'aide de Cloud Run et de Pub/Sub

Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Créer un système résilient et asynchrone à l'aide de Cloud Run et de Pub/Sub

Lab 1 heure universal_currency_alt 5 crédits show_chart Intermédiaire
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP650

Google Cloud – Ateliers adaptés au rythme de chacun

Logo Pet Theory

Présentation

Dans le cadre des ateliers de la quête "Google Cloud Serverless Workshop : Pet Theory", vous allez découvrir un scénario métier fondé sur une entreprise fictive et aider les protagonistes à migrer vers une technologie sans serveur.

Il y a 12 ans, Lily a créé une chaîne de cliniques vétérinaires appelée Pet Theory. Au fil des ans, le nombre de cliniques a augmenté, ainsi que le besoin d'automatisation. Le processus de traitement que Pet Theory a mis en place pour les résultats des tests médicaux en provenance du laboratoire est trop lent et sujet aux erreurs ; Lily souhaite l'améliorer.

Actuellement, Patrick, l'administrateur informatique de Pet Theory, traite manuellement les résultats des tests. Chaque fois qu'il reçoit les résultats d'un test, il envoie un courrier électronique au client dont l'animal a été testé. À l'aide de son téléphone, il lui envoie ensuite les résultats du test par SMS.

Patrick travaille avec Ruby, une consultante en logiciels, pour concevoir un système plus évolutif. Ils souhaitent créer une solution qui nécessite peu de maintenance. Ils ont donc opté pour une technologie sans serveur.

Prérequis

Dans cet atelier, nous considérons que vous connaissez la console Cloud et les environnements shell. Cet atelier fait partie d'une série. Il est recommandé de suivre les ateliers précédents, mais ce n'est pas obligatoire :

Vous devez également savoir modifier des fichiers. Vous pouvez utiliser votre éditeur de texte préféré (comme nano, vi, etc.) ou lancer l'éditeur de code de Cloud Shell, qui se trouve dans le ruban supérieur :

Icône de l'éditeur de code Cloud Shell

Préparation

Remarque : Pour cet atelier, connectez-vous à la console Google Cloud en tant que Username 1. Si vous utilisez un identifiant différent, vous rencontrerez des erreurs au cours de l'atelier.

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

  • vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;
Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.
  • vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

  1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

    • Le bouton Ouvrir la console Google
    • Le temps restant
    • Les identifiants temporaires que vous devez utiliser pour cet atelier
    • Des informations complémentaires vous permettant d'effectuer l'atelier
  2. Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

    Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

    Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.
  3. Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

  4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

    Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.
  5. Accédez aux pages suivantes :

    • Acceptez les conditions d'utilisation.
    • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
    • Ne vous inscrivez pas aux essais offerts.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche. Icône du menu de navigation

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

  1. Cliquez sur Activer Cloud Shell Icône Activer Cloud Shell en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

  1. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :
gcloud auth list
  1. Cliquez sur Autoriser.

  2. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :
gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Définir votre région et votre zone

Certaines ressources Compute Engine sont hébergées dans des régions et des zones. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources. Chaque région se compose d'une ou plusieurs zones.

Exécutez les commandes gcloud suivantes dans la console Cloud pour définir la région et la zone par défaut de votre atelier :

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

Scénario

Pet Theory souhaite automatiser son processus de partage des résultats de tests avec les clients. Étant donné que la croissance du volume de rendez-vous devenait difficile à gérer, Lily a décidé de demander de l'aide à Ruby...

Lily

Lily, fondatrice de Pet Theory

Bonjour Ruby,

Merci d'avoir résolu le problème du portail d'assurance.

Je me demandais s'il était possible de faire quelque chose concernant les résultats des tests médicaux. Nous devons trouver un moyen plus efficace de les envoyer aux clients.

Lily

Ruby

Ruby, Consultante en logiciels

Bonjour Lily,

Bien sûr, je vais voir ce que je peux faire. J'ai quelques idées qui pourraient peut-être améliorer les choses.

Ruby

Tâche 1 : Architecture

Pet Theory fait appel à une entreprise externe pour réaliser les tests médicaux. Une fois que le laboratoire médical a effectué les tests,

les résultats sont envoyés via une requête POST HTTP(s) au point de terminaison Web de Pet Theory. L'illustration ci-dessous présente l'architecture générale.

Schéma de l&#39;architecture système de Pet Theroy

Après avoir examiné le processus général, Ruby pense qu'il est possible de concevoir un système qui permettrait à Pet Theory de traiter les opérations suivantes :

  1. Recevoir la requête POST HTTP et envoyer un accusé de réception au laboratoire médical
  2. Envoyer les résultats du test par e-mail au client
  3. Envoyer au client un SMS et un e-mail contenant les résultats du test

Le système de Ruby permet d'isoler chacune de ces tâches et nécessite :

  • Un service pour exécuter la requête et envoyer la réponse des résultats médicaux
  • Un service pour envoyer les résultats des tests au client par e-mail
  • Un service permettant d'envoyer un SMS au client
  • Pub/Sub pour la communication interservices
  • Une infrastructure sans serveur pour l'architecture de l'application

Ruby cherche à développer un code plus facile à écrire et contenant moins de bugs en s'appuyant sur des fonctions à usage unique.

Ruby

Ruby, Consultante en logiciels

Bonjour Patrick,

Lily souhaite que je crée un prototype visant à faciliter le traitement des dossiers médicaux.

Pour commencer, pourriez-vous configurer un sujet Pub/Sub nommé new-lab-report ?

Ruby

Patrick

Patrick, Administrateur informatique

Bonjour Ruby,

C'est un projet vraiment intéressant. Je pense pouvoir terminer cela dès ce matin. Avec Google Cloud, les deux configurations sont vraiment rapides à mettre en place.

Patrick

Créer un sujet Pub/Sub

Aidez Patrick à créer un sujet Pub/Sub appelé new-lab-report.

Cloud Pub/Sub mis en évidence dans le schéma de l&#39;architecture

Lorsqu'un service publie un message Pub/Sub, ce message doit être tagué avec un sujet. Le rapport du laboratoire est consommé via le service à créer et publie un message pour chaque rapport trouvé.

Vous devez d'abord créer un sujet qui peut être utilisé pour cette tâche.

  1. Exécutez la commande suivante pour créer un sujet Pub/Sub :
gcloud pubsub topics create new-lab-report

Tout service abonné au sujet "new-lab-report" pourra consommer le message publié par le service de rapport du laboratoire. Dans le diagramme ci-dessus, vous pouvez voir deux de ces services, le service de courrier électronique et le service SMS.

  1. Activez ensuite Cloud Run. Ce service exécutera votre code dans le cloud :
gcloud services enable run.googleapis.com

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer un sujet Pub/Sub

N'oubliez pas d'informer Ruby que le sujet Pub/Sub est prêt à être utilisé.

Patrick

Patrick, Administrateur informatique

Bonjour Ruby,

C'est fait.

Si vous avez un peu de temps, j'aimerais voir comment le prototype est mis en place. Peut-on le faire ensemble ?

Patrick

Ruby

Ruby, Consultante en logiciels

Bonjour Patrick,

Super ! Merci d'avoir fait si vite. Je vais caler une heure pour qu'on travaille dessus.

Ruby

Tâche 2 : Créer le service de rapport du laboratoire

Aidez Ruby à configurer le nouveau service de rapport du laboratoire.

Service de rapport du laboratoire mis en évidence dans le schéma d&#39;architecture

Ce service sera utilisé pour le prototypage. Son rôle se limite à ces deux opérations :

  1. Recevoir le rapport HTTPS POST du laboratoire contenant les données du rapport
  2. Publier un message sur Pub/Sub

Ajouter du code pour le service de rapport du laboratoire

  1. Repassez à Cloud Shell et clonez le dépôt nécessaire pour cet atelier :
git clone https://github.com/rosera/pet-theory.git
  1. Accédez au répertoire lab-service :
cd pet-theory/lab05/lab-service
  1. Installez les packages suivants, qui seront nécessaires pour réceptionner les requêtes HTTPS entrantes et assurer la publication dans Pub/Sub :
npm install express npm install body-parser npm install @google-cloud/pubsub

Ces commandes mettent à jour le fichier package.json pour indiquer les dépendances nécessaires à ce service.

Vous allez maintenant modifier le fichier package.json pour indiquer à Cloud Run comment lancer votre code.

  1. Ouvrez le fichier package.json.

  2. Dans la section "scripts" du fichier package.json, ajoutez la ligne de code "start": "node index.js", sur la ligne 7 (comme indiqué ci-dessous), puis enregistrez le fichier :

"scripts": { "start": "node index.js", "test": "echo \"Error: no test specified\" && exit 1" }, Remarque : Veillez à ajouter le code exactement tel qu'il a été fourni, en incluant la virgule finale.

"start": "node index.js",

Si vous ne respectez pas cette consigne, vous rencontrerez des erreurs au cours du déploiement.
  1. Créez un fichier nommé index.js et ajoutez-y le code suivant :
const {PubSub} = require('@google-cloud/pubsub'); const pubsub = new PubSub(); const express = require('express'); const app = express(); const bodyParser = require('body-parser'); app.use(bodyParser.json()); const port = process.env.PORT || 8080; app.listen(port, () => { console.log('Listening on port', port); }); app.post('/', async (req, res) => { try { const labReport = req.body; await publishPubSubMessage(labReport); res.status(204).send(); } catch (ex) { console.log(ex); res.status(500).send(ex); } }) async function publishPubSubMessage(labReport) { const buffer = Buffer.from(JSON.stringify(labReport)); await pubsub.topic('new-lab-report').publish(buffer); } Ces deux lignes font l'essentiel du travail du service :

const labReport = req.body;

await publishPubSubMessage(labReport);

Plus précisément, elles déclenchent les deux actions suivantes :

  • Extraction du rapport du laboratoire de la requête POST
  • Publication d'un message PubSub contenant le rapport récent du laboratoire
  1. Créez maintenant un fichier nommé Dockerfile et ajoutez-y le code ci-dessous :
FROM node:18 WORKDIR /usr/src/app COPY package.json package*.json ./ RUN npm install --only=production COPY . . CMD [ "npm", "start" ]

Ce fichier décrit comment créer un package du service Cloud Run dans un conteneur.

Déployer le service de rapport du laboratoire

  1. Créez un fichier nommé deploy.sh et collez-y les commandes suivantes :
gcloud builds submit \ --tag gcr.io/$GOOGLE_CLOUD_PROJECT/lab-report-service gcloud run deploy lab-report-service \ --image gcr.io/$GOOGLE_CLOUD_PROJECT/lab-report-service \ --platform managed \ --region {{{project_0.default_region | "REGION"}}} \ --allow-unauthenticated \ --max-instances=1
  1. Dans Cloud Shell, exécutez la commande suivante pour rendre ce fichier exécutable :
chmod u+x deploy.sh
  1. Il est temps de déployer le service de rapport du laboratoire. Exécutez le script de déploiement :
./deploy.sh

Un message d'erreur, imputable à un problème de synchronisation, peut vous être renvoyé la première fois que vous exécutez cette commande. Dans ce cas, il suffit d'exécuter à nouveau le script deploy.sh.

Une fois le déploiement terminé, un message semblable à celui-ci s'affiche :

Service [lab-report-service] revision [lab-report-service-00001] has been deployed and is serving traffic at https://lab-report-service-[hash].a.run.app

Bravo ! Le service de rapport du laboratoire a bien été déployé et va consommer les résultats du laboratoire médical via HTTP. Vous pouvez maintenant vérifier si le nouveau service est opérationnel.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Déployer le service de rapport de laboratoire : Compiler

Cliquez sur Vérifier ma progression pour valider l'objectif.

Déployer le service de rapport du laboratoire : Créer une révision

Tester le service de rapport du laboratoire

Pour valider le service de rapport de laboratoire, simulez trois requêtes HTTPS POST effectuées par le laboratoire médical, chacune contenant un rapport de laboratoire. À des fins de tests, les rapports de laboratoire créés ne contiendront qu'un ID.

  1. Tout d'abord, placez l'URL du rapport dans une variable d'environnement pour simplifier son utilisation.
export LAB_REPORT_SERVICE_URL=$(gcloud run services describe lab-report-service --platform managed --region {{{project_0.default_region | "REGION"}}} --format="value(status.address.url)")
  1. Vérifiez que l'URL LAB_REPORT_SERVICE_URL a bien été collectée :
echo $LAB_REPORT_SERVICE_URL
  1. Créez un fichier nommé post-reports.sh et ajoutez-y le code ci-dessous :
curl -X POST \ -H "Content-Type: application/json" \ -d "{\"id\": 12}" \ $LAB_REPORT_SERVICE_URL & curl -X POST \ -H "Content-Type: application/json" \ -d "{\"id\": 34}" \ $LAB_REPORT_SERVICE_URL & curl -X POST \ -H "Content-Type: application/json" \ -d "{\"id\": 56}" \ $LAB_REPORT_SERVICE_URL &

Le script ci-dessus utilise la commande curl pour publier trois identifiants distincts dans l'URL du service du laboratoire. Chaque commande sera exécutée individuellement en arrière-plan.

  1. Rendez le script post-reports.sh exécutable :
chmod u+x post-reports.sh
  1. Testez maintenant le point de terminaison du service de rapport du laboratoire en publiant sur ce service trois rapports de laboratoire à l'aide du script décrit ci-dessus :
./post-reports.sh

Ce script a publié trois rapports de laboratoire sur le service de rapport du laboratoire. Consultez les journaux pour voir les résultats.

  1. Dans la console Cloud, cliquez sur le menu de navigation (Icône du menu de navigation) puis sur Cloud Run.

  2. Vous devriez maintenant voir le service de rapport du laboratoire nouvellement déployé dans la liste Services. Cliquez dessus.

  3. La page suivante affiche des détails sur le service de rapport du laboratoire. Cliquez sur l'onglet Journaux.

Sur la page "Journaux" se trouvent les résultats concernant les trois rapports de test que vous venez de poster à l'aide du script. Normalement, les codes HTTP renvoyés sont 204, ce qui signifie OK - pas de contenu, comme indiqué ci-dessous. Si vous ne voyez pas d'entrée, essayez de faire défiler la page à l'aide de la barre de défilement située à droite. Cela permet d'actualiser le journal.

Résultats des journaux

La prochaine tâche consiste à écrire les services de SMS et de courrier électronique. Ces services sont déclenchés lorsque le service de rapport du laboratoire publie un message Pub/Sub sur le sujet "new-lab-report".

Tâche 3 : Le service de courrier électronique

Aidez Ruby à mettre en place le nouveau service de courrier électronique.

Service de courrier électronique mis en évidence dans le schéma de l&#39;architecture

Ajouter du code pour le service de courrier électronique

  1. Accédez au répertoire du service de courrier électronique :
cd ~/pet-theory/lab05/email-service
  1. Installez ces packages pour que le code soit en mesure de gérer les requêtes HTTPS entrantes :
npm install express npm install body-parser

La commande ci-dessus mettra à jour le fichier package.json, lequel décrit l'application et ses dépendances. Cloud Run doit savoir comment exécuter le code. Ajoutez donc une instruction de démarrage pour qu'il sache quoi faire.

  1. Ouvrez le fichier package.json.

  2. Dans la section "scripts", ajoutez la ligne "start": "node index.js", comme indiqué ci-dessous et enregistrez le fichier :

"scripts": { "start": "node index.js", "test": "echo \"Error: no test specified\" && exit 1" }, Remarque : Veillez à ajouter le code exactement tel qu'il a été fourni, en incluant la virgule finale.

"start": "node index.js",

Si vous ne respectez pas cette consigne, vous rencontrerez des erreurs au cours du déploiement.
  1. Créez un fichier appelé index.js et ajoutez-y ce qui suit :
const express = require('express'); const app = express(); const bodyParser = require('body-parser'); app.use(bodyParser.json()); const port = process.env.PORT || 8080; app.listen(port, () => { console.log('Listening on port', port); }); app.post('/', async (req, res) => { const labReport = decodeBase64Json(req.body.message.data); try { console.log(`Email Service: Report ${labReport.id} trying...`); sendEmail(); console.log(`Email Service: Report ${labReport.id} success :-)`); res.status(204).send(); } catch (ex) { console.log(`Email Service: Report ${labReport.id} failure: ${ex}`); res.status(500).send(); } }) function decodeBase64Json(data) { return JSON.parse(Buffer.from(data, 'base64').toString()); } function sendEmail() { console.log('Sending email'); }

Ce code s'exécute lorsque Pub/Sub publie un message sur le service. Voici comment il procède :

  • Il décode le message Pub/Sub et essaie ensuite d'appeler la fonction sendEmail().
  • Si l'opération réussit et qu'aucune exception n'est levée, il renvoie le code d'état 204 pour que Pub/Sub sache que le message a été traité.
  • S'il y a une exception, le service renvoie le code d'état 500 pour que Pub/Sub sache que le message n'a pas été traité et qu'il doit le renvoyer ultérieurement au service.

Une fois que la communication entre les services fonctionne, Ruby ajoute un code à la fonction sendEmail() pour envoyer effectivement l'e-mail.

  1. Créez maintenant un fichier nommé Dockerfile et ajoutez-y le code ci-dessous :
FROM node:18 WORKDIR /usr/src/app COPY package.json package*.json ./ RUN npm install --only=production COPY . . CMD [ "npm", "start" ]

Ce fichier décrit comment créer un package du service Cloud Run dans un conteneur.

Déployer le service de courrier électronique

  1. Créez un fichier appelé deploy.sh et ajoutez-y le contenu suivant :
gcloud builds submit \ --tag gcr.io/$GOOGLE_CLOUD_PROJECT/email-service gcloud run deploy email-service \ --image gcr.io/$GOOGLE_CLOUD_PROJECT/email-service \ --platform managed \ --region {{{project_0.default_region | "REGION"}}} \ --no-allow-unauthenticated \ --max-instances=1
  1. Rendez le fichier deploy.sh exécutable :
chmod u+x deploy.sh
  1. Déployez le service de courrier électronique :
./deploy.sh

Lorsque le déploiement est terminé, un message semblable à celui-ci s'affiche :

Service [email-service] revision [email-service-00001] has been deployed and is serving traffic at https://email-service-[hash].a.run.app

Le service a bien été déployé. Vous devez maintenant vous assurer que le service de courrier électronique est déclenché lorsqu'un message Pub/Sub est disponible.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Déployer le service de courrier électronique : Compiler

Cliquez sur Vérifier ma progression pour valider l'objectif.

Déployer le service de courrier électronique : Créer une révision

Configurer Pub/Sub pour déclencher le service de courrier électronique

Chaque fois qu'un nouveau message Pub/Sub est publié en utilisant la rubrique "new-lab-report", il doit déclencher le service de courrier électronique. Pour réaliser cette tâche, vous allez configurer un compte de service qui traitera automatiquement les requêtes associées à ce service.

Le schéma de l&#39;architecture met en évidence le flux de Cloud Pub/Sub vers le service de courrier électronique

  1. Créez un compte de service destiné à déclencher les services répondant aux messages Pub/Sub :
gcloud iam service-accounts create pubsub-cloud-run-invoker --display-name "PubSub Cloud Run Invoker"

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer un compte de service
  1. Accordez au compte de service que vous venez de créer l'autorisation d'appeler le service de courrier électronique :
gcloud run services add-iam-policy-binding email-service --member=serviceAccount:pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --role=roles/run.invoker --region {{{project_0.default_region | "REGION"}}} --platform managed

Ensuite, indiquez à Pub/Sub qu'il doit appeler le service SMS lorsqu'un message de type "new-lab-report" (nouveau rapport de laboratoire) est publié.

  1. Placez le numéro du projet dans une variable d'environnement pour en faciliter l'accès :
PROJECT_NUMBER=$(gcloud projects list --filter="qwiklabs-gcp" --format='value(PROJECT_NUMBER)')

Ensuite, vous devez autoriser le projet à créer des jetons d'authentification Pub/Sub.

  1. Exécutez le code ci-dessous :
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com --role=roles/iam.serviceAccountTokenCreator
  1. Mettez l'URL du service de courrier électronique dans une autre variable d'environnement :
EMAIL_SERVICE_URL=$(gcloud run services describe email-service --platform managed --region {{{project_0.default_region | "REGION"}}} --format="value(status.address.url)")
  1. Vérifiez que l'URL EMAIL_SERVICE_URL a bien été collectée :
echo $EMAIL_SERVICE_URL
  1. Créez un abonnement Pub/Sub pour le service de courrier électronique :
gcloud pubsub subscriptions create email-service-sub --topic new-lab-report --push-endpoint=$EMAIL_SERVICE_URL --push-auth-service-account=pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

Bravo ! Le service est maintenant configuré pour répondre aux messages Cloud Pub/Sub. L'étape suivante consiste à valider le code pour confirmer qu'il répond aux exigences.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer l'abonnement Pub/Sub

Tester ensemble le service de rapport du laboratoire et le service de courrier électronique

  1. À l'aide du script créé précédemment, publiez à nouveau les rapports du laboratoire :
~/pet-theory/lab05/lab-service/post-reports.sh
  1. Ouvrez ensuite le journal (Menu de navigation > Cloud Run). Vous pouvez voir les deux services Cloud Run (email-service et lab-report-service) dans votre compte.

  2. Cliquez sur email-service, puis sur Journaux.
    Vous devez voir le résultat du déclenchement de ce service par Pub/Sub. Si vous ne voyez pas les messages que vous attendez, faites défiler le journal à l'aide de la barre de défilement pour forcer son actualisation.

Bravo ! Le service de messagerie électronique est désormais en mesure d'écrire des informations dans le journal chaque fois qu'un message est traité à partir de la file d'attente des sujets Cloud Pub/Sub. La dernière tâche consiste à créer le service SMS.

Tâche 4 : Le service SMS

Aidez Ruby à mettre en place le nouveau service SMS.

Service SMS mis en évidence dans le schéma de l&#39;architecture

Ajouter du code pour le service SMS

  1. Créez un répertoire pour le service SMS :
cd ~/pet-theory/lab05/sms-service
  1. Installez les packages nécessaires pour la réception des requêtes HTTPS entrantes :
npm install express npm install body-parser
  1. Ouvrez le fichier package.json.

  2. Dans la section "scripts", ajoutez la ligne "start": "node index.js", comme indiqué ci-dessous et enregistrez le fichier :

... "scripts": { "start": "node index.js", "test": "echo \"Error: no test specified\" && exit 1" }, ... Remarque : Veillez à ajouter le code exactement tel qu'il a été fourni, en incluant la virgule finale.

"start": "node index.js",

Si vous ne respectez pas cette consigne, vous rencontrerez des erreurs au cours du déploiement.
  1. Créez un fichier appelé index.js et ajoutez-y ce qui suit :
const express = require('express'); const app = express(); const bodyParser = require('body-parser'); app.use(bodyParser.json()); const port = process.env.PORT || 8080; app.listen(port, () => { console.log('Listening on port', port); }); app.post('/', async (req, res) => { const labReport = decodeBase64Json(req.body.message.data); try { console.log(`SMS Service: Report ${labReport.id} trying...`); sendSms(); console.log(`SMS Service: Report ${labReport.id} success :-)`); res.status(204).send(); } catch (ex) { console.log(`SMS Service: Report ${labReport.id} failure: ${ex}`); res.status(500).send(); } }) function decodeBase64Json(data) { return JSON.parse(Buffer.from(data, 'base64').toString()); } function sendSms() { console.log('Sending SMS'); }
  1. Créez maintenant un fichier nommé Dockerfile et ajoutez-y le code ci-dessous :
FROM node:18 WORKDIR /usr/src/app COPY package.json package*.json ./ RUN npm install --only=production COPY . . CMD [ "npm", "start" ]

Ce fichier décrit comment créer un package du service Cloud Run dans un conteneur. Maintenant que le code a été créé, l'étape suivante consiste à déployer le service.

Déployer le service SMS

  1. Créez un fichier nommé deploy.sh et ajoutez-y le code suivant :
gcloud builds submit \ --tag gcr.io/$GOOGLE_CLOUD_PROJECT/sms-service gcloud run deploy sms-service \ --image gcr.io/$GOOGLE_CLOUD_PROJECT/sms-service \ --platform managed \ --region {{{project_0.default_region | "REGION"}}} \ --no-allow-unauthenticated \ --max-instances=1
  1. Rendez le fichier deploy.sh exécutable :
chmod u+x deploy.sh
  1. Déployez le service SMS :
./deploy.sh

Une fois le déploiement terminé, un message semblable à celui-ci s'affiche :

Service [sms-service] revision [sms-service-00001] has been deployed and is serving traffic at https://sms-service-[hash].a.run.app

Le service SMS a bien été déployé, mais il n'est pas lié au service Cloud Pub/Sub. Corrigez cela dans la section suivante.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Déployer le service SMS

Configurer Cloud Pub/Sub pour déclencher le service SMS

Comme pour le service de courrier électronique, le lien entre Cloud Pub/Sub et le service SMS doit être configuré pour que les messages puissent être consommés.

Le schéma de l&#39;architecture met en évidence le flux entre Cloud Pub/Sub et le service SMS

  1. Définissez les autorisations nécessaires pour permettre à Pub/Sub de déclencher le service SMS :
gcloud run services add-iam-policy-binding sms-service --member=serviceAccount:pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --role=roles/run.invoker --region {{{project_0.default_region | "REGION"}}} --platform managed

Ensuite, indiquez à Pub/Sub qu'il doit appeler le service SMS lorsqu'un message de type "new-lab-report" (nouveau rapport de laboratoire) est publié.

  1. La première étape consiste à placer l'URL du service SMS dans une variable d'environnement :
SMS_SERVICE_URL=$(gcloud run services describe sms-service --platform managed --region {{{project_0.default_region | "REGION"}}} --format="value(status.address.url)")
  1. Vérifiez que l'URL SMS_SERVICE_URL a bien été collectée :

    echo $SMS_SERVICE_URL
  2. Créez ensuite l'abonnement Pub/Sub :

gcloud pubsub subscriptions create sms-service-sub --topic new-lab-report --push-endpoint=$SMS_SERVICE_URL --push-auth-service-account=pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com
  1. Exécutez à nouveau le script de test pour publier trois rapports sur le service de rapport du laboratoire :
~/pet-theory/lab05/lab-service/post-reports.sh
  1. Ouvrez ensuite le journal (Menu de navigation > Cloud Run). Les trois services Cloud Run (email-service, lab-report-service et sms-service) sont affichés dans votre compte.

  2. Cliquez sur sms-service, puis sur Journaux. Vous verrez le résultat de ce service déclenché par Pub/Sub.

Le prototype du système a été créé et testé avec succès. Toutefois, Patrick est préoccupé par le fait que la résilience n'a pas été testée dans le cadre du processus de validation initial.

Tâche 5 : Tester la résilience du système

Que se passe-t-il si l'un des services est défectueux ? Patrick a déjà été confronté à cette situation courante.

Aidez Ruby à étudier comment faire pour que le système puisse gérer ce scénario. Elle veut tester ce qui se passe lorsqu'un service est défectueux, en déployant une mauvaise version du service de courrier électronique.

  1. Revenez au répertoire email-service :
cd ~/pet-theory/lab05/email-service

Ajoutez du texte non valide dans l'application du service de courrier électronique pour provoquer une erreur.

  1. Modifiez le fichier index.js et ajoutez la ligne throw à la fonction sendEmail(), comme indiqué ci-dessous. Une exception est alors renvoyée, comme si le serveur de messagerie était en panne :
... function sendEmail() { throw 'Email server is down'; console.log('Sending email'); } ...

L'ajout de ce code permet de faire planter le service lorsqu'il est appelé.

  1. Déployez cette version défaillante du service de courrier électronique :
./deploy.sh
  1. Une fois le déploiement du service de courrier électronique terminé, publiez à nouveau les données dans les rapports du laboratoire, puis examinez de près l'état du journal email-service :
~/pet-theory/lab05/lab-service/post-reports.sh
  1. Ouvrez les journaux du service de courrier électronique pour afficher les journaux du service défaillant : menu de navigation > Cloud Run.

  2. Lorsque vous voyez les trois services "Cloud Run" dans votre compte, cliquez sur email-service.

Le service de courrier électronique est appelé, mais il continue à planter. Si vous remontez dans les journaux, vous découvrirez la cause : "Email server is down" (Le serveur de messagerie est en panne). Vous verrez également que le service renvoie le code d'état 500, et que Pub/Sub continue à tenter d'appeler le service.

Si vous vérifiez les journaux du service SMS, vous verrez qu'il fonctionne correctement.

Corrigez maintenant l'erreur dans le service de courrier électronique pour restaurer l'application.

  1. Ouvrez le fichier index.js et supprimez la ligne de renvoi de l'exception que vous avez saisie précédemment, puis enregistrez le fichier.

La fonction sendEmail de votre fichier index.js ressemble maintenant à ceci :

function sendEmail() { console.log('Sending email'); }
  1. Déployez la version corrigée du service de courrier électronique :
./deploy.sh
  1. Une fois le déploiement terminé, cliquez sur l'icône d'actualisation dans l'angle supérieur droit.

Vous verrez que les e-mails des rapports 12, 34 et 56 ont finalement été envoyés, le service de courrier électronique a renvoyé le code d'état 204, et Pub/Sub a cessé d'appeler le service. Aucune donnée n'a été perdue ; Pub/Sub a refait des tentatives jusqu'à ce que ça marche. C'est la base d'un système robuste !

Enseignements

  1. Si les services communiquent entre eux de manière asynchrone via Pub/Sub au lieu de s'appeler directement, le système peut être plus résilient.
  2. Grâce à Pub/Sub, le déclenchement du service de rapport du laboratoire est indépendant des autres services. Par exemple, si les clients souhaitent également recevoir les résultats du laboratoire via un autre service de messagerie, il est possible de l'ajouter sans avoir à mettre à jour le service de rapport du laboratoire.
  3. Cloud Pub/Sub a géré les tentatives, les services n'ont pas eu à le faire. Les services sont uniquement tenus de renvoyer un code d'état : succès ou échec.
  4. Dans le cas où un service s'interrompt, le système est capable de se "réparer" automatiquement lorsque le service est remis en ligne, par le biais de nouvelles tentatives effectuées par Pub/Sub.

Félicitations !

Grâce à votre aide, Ruby a réussi à créer un prototype de système résilient. Le service est capable d'envoyer automatiquement à chaque client un e-mail et un SMS. En cas d'interruption temporaire de certains services, le système met en place un mécanisme de répétition de tentatives afin qu'aucune donnée ne soit perdue. Ruby reçoit des félicitations bien méritées...

Lily

Lily, fondatrice de Pet Theory

Bonjour Ruby,

Aucun mot ne peut exprimer ma gratitude pour votre travail et votre professionnalisme.

En peu de temps, nos systèmes de base ont été totalement remaniés.

Nous organisons une petite réception vendredi pour fêter cela et nous espérons que vous serez des nôtres !

Lily

MelodyMelody, Directrice générale

Bonjour Ruby,

J'ai reçu des éloges de la part de Pet Theory pour votre travail. Vous avez beaucoup apporté à l'équipe.

Maintenant que cette mission est terminée, j'aimerais vous parler d'un rôle plus important que vous pourriez avoir dans un nouveau projet.

Melody

Directrice générale

Computer Consulting Inc.

Terminer votre quête

Cet atelier d'auto-formation fait partie de la quête Google Cloud Run Serverless Workshop. Une quête est une série d'ateliers associés qui constituent un parcours de formation. Si vous terminez cette quête, vous obtenez le badge ci-dessus, lequel atteste de votre réussite. Vous pouvez rendre publics les badges que vous recevez et ajouter leur lien dans votre CV en ligne ou sur vos comptes de réseaux sociaux. Inscrivez-vous à cette quête pour obtenir immédiatement les crédits associés à cet atelier si vous l'avez suivi. Découvrez les autres quêtes disponibles.

Atelier suivant

Poursuivez votre quête avec le prochain atelier de la série, Développer une API REST avec Go et Cloud Run.

Étapes suivantes et informations supplémentaires

Article de Medium : Cloud Run as an internal async worker

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 20 septembre 2023

Dernier test de l'atelier : 20 septembre 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.