Partager via


Démarrage rapide : Créer une application de conversation avec une fonction Azure en mode serverless Socket.IO (préversion)

Dans cet article, vous apprenez à créer une application de conversation en utilisant Web PubSub pour Socket.IO en mode serverless avec Azure Functions. Le tutoriel vous guide dans la sécurisation de votre application avec l’authentification basée sur l’identité quand vous travaillez en ligne.

La source du projet utilise Bicep pour déployer l’infrastructure sur Azure, et Azure Functions Core Tools pour déployer le code sur l’application de fonction.

Prérequis

Obtenir l’exemple de code

Recherchez l’exemple de code : Socket.IO Serverless Sample (TS)

git clone https://github.com/Azure/azure-webpubsub.git
cd ./sdk/webpubsub-socketio-extension/examples/chat-serverless-typescript

Déployer l’infrastructure

Les exemples de conversation doivent déployer plusieurs services dans Azure :

Nous utilisons Bicep pour déployer l’infrastructure. Le fichier se trouve dans le dossier ./infra. Déployez-le avec la commande az :

az deployment sub create -n "<deployment-name>" -l "<deployment-location>" --template-file ./infra/main.bicep --parameters environmentName="<env-name>" location="<location>"
  • <deployment-name> : nom du déploiement.
  • <deployment-location> : emplacement des métadonnées du déploiement. Notez qu’il ne s’agit pas de l’emplacement où sont déployées les ressources.
  • <env-name> : le nom est une partie du nom du groupe de ressources et du nom de la ressource.
  • <location> : emplacement des ressources.

Vérification de l’infrastructure

Dans la version d’infrastructure, nous déployons une application de fonction Azure dans un plan de consommation ainsi que le compte Monitor et de stockage dont a besoin l’application de fonction. Nous déployons aussi une ressource Web PubSub pour Socket.IO en mode serverless.

Pour l’authentification basée sur l’identité, nous déployons une identité managée affectée par l’utilisateur, l’attribuons à l’application de fonction et à la ressource Socket.IO, et lui accordons certaines autorisations :

  • Rôle Propriétaire des données Blob de stockage : accès au stockage pour l’application de fonction
  • Rôle Éditeur des métriques de monitoring : accès au monitoring pour l’application de fonction
  • Rôle Propriétaire du service Web PubSub : accès à Web PubSub pour Socket.IO pour l’application de fonction

Conformément à Configurer votre application Azure Functions pour utiliser la connexion Microsoft Entra, nous créons un principal de service. Pour éviter d’utiliser un secret pour le principal de service, nous utilisons des informations d’identification d’identité fédérée.

Déployer l’exemple sur l’application de fonction

Nous avons préparé un script Bash pour déployer l’exemple de code sur l’application de fonction :

# Deploy the project
./deploy/deploy.sh "<deployment-name>"

Passer en revue les détails du déploiement

Nous devons effectuer deux étapes pour déployer l’exemple d’application.

  • Publier le code dans l’application de fonction (Utiliser Azure Functions Core Tools)

    func extensions sync
    npm install
    npm run build
    func azure functionapp publish <function-app-name>
    
  • Configurer Web PubSub pour Socket.IO afin d’ajouter un paramètre de hub pouvant envoyer une requête à l’application de fonction. Conformément à la limitation du fournisseur de webhook de l’application de fonction, vous devez obtenir une clé d’extension remplie par la fonction. Obtenez plus d’informations dans Liaison de déclencheur. Comme nous utilisons l’authentification basée sur l’identité, dans les paramètres du hub, vous devez attribuer la ressource cible, qui est l’ID client du principal de service créé précédemment.

    code=$(az functionapp keys list -g <resource-group> -n <function-name> --query systemKeys.socketio_extension -o tsv)
    az webpubsub hub create -n <socketio-name> -g <resource-group> --hub-name "hub" --event-handler url-template="https://${<function-name>}.azurewebsites.net/runtime/webhooks/socketio?code=${code}" user-event-pattern="*" auth-type="ManagedIdentity" auth-resource="<service-principal-client-id>"
    

Exécuter l’exemple d’application

Une fois le code déployé, visitez le site web pour essayer l’exemple :

https://<function-endpoint>/api/index

Capture d’écran de l’application de conversation serverless.

Étapes suivantes

Ensuite, vous pouvez suivre le tutoriel permettant d’écrire l’application étape par étape :