Déployer vers Azure App Service

Un portail Power Portals Pro est une application Core à ASP.NET unique, quelle que soit la pile choisie, donc son déploiement est un standard dotnet publish pour un service d’application ordinaire. Cette page couvre les ressources à créer, les paramètres que le portail lit à l’écran, ce que nous suggérons comme valeurs par défaut, ainsi que les quelques étapes spécifiques à Power Portals Pro plutôt qu’à ASP.NET Core.

Ce que vous déployez

Les deux modèles produisent une application web et une sortie de publication. Il n’y a pas d’hôte front-end séparé à installer, pas de ressource statique du site, et pas de second service d’application :

Note

Parce que les versions de publication de React sont déployées vers npm, Node doit être installé sur la machine qui tourne dotnet publish — votre ordinateur portable ou l’agent de compilation. Le client du modèle demande Node ^20.19.0 || >=22.12.0. App Service lui-même n’a jamais besoin de Node ; il ne voit que la sortie intégrée.

Paramètres par défaut suggérés

Des points de départ, pas des règles — mais ce sont ce que nous choisirions pour un nouveau portail de production.

1. Créer le service d’application

Trois commandes. Substituez vos propres noms — myportal est utilisée tout au long de cette page.

Le nom de l’application web devient https://myportal.azurewebsites.net et doit être globalement unique. Choisissez-le délibérément : à moins de mettre un domaine personnalisé devant, c’est l’URL à laquelle votre clé de licence est liée.

2. Définir les options de plateforme

Ce sont ceux dont les défauts sont mauvais pour un portail.

3. Configuration

Les paramètres de l’application du service d’applications arrivent sous forme de variables d’environnement et supplantent appsettings.json, ce qui est exactement ce que vous voulez : laissez le fichier tel quel et définissez ici les valeurs par environnement.

Important

Les secrets utilisateur ne voyagent pas. Tout ce que vous stockiez dotnet user-secrets pendant le développement reste uniquement sur votre machine. Chacune de ces clés doit être recréée sous forme de paramètre d’application — ou de référence Key Vault — sinon l’application déployée ne démarrera pas.

Utilisez un double soulignement pour le séparateur de section : D365:ClientId devient D365__ClientId. Le formulaire deux-points fonctionne sur Windows App Service mais pas sous Linux, donc __ le formulaire à utiliser partout est le cas.

Toujours obligatoire

Obligatoire si vous avez activé ce fournisseur de connexion

Optionnel

Note

Les clés requises sont lues avec GetRequiredValue, donc une clé manquante est lancée au démarrage plutôt que de casser plus tard lors du premier appel Dataverse. Sur un service d’applications, cela apparaît comme un site qui n’apparaît jamais — lisez le flux de journal, et l’exception nomme la clé.

4. Donner au portail une adresse à partir de laquelle envoyer

D365__EmailSenderEmailAddress c’est d’où provient l’email de confirmation de compte et de réinitialisation de mot de passe, et le framework le résout en cherchant un utilisateur Dataverse avec cette adresse, puis une file d’attente, puis une équipe. Utilisez une file d’attente. C’est l’option qui ne nécessite aucun travail dans Exchange : la boîte aux lettres créée par Dataverse pour une file d’attente est orientée vers le profil Exchange Online existant de l’organisation, donc il n’y a pas de boîte aux lettres à provisionner ni de licence pour acheter l’adresse. Pointer le paramètre vers une personne réelle vous coûte plutôt trois choses :

Trois étapes, toutes à l’intérieur de Dataverse. Le serveur MCP effectue les deux premiers appels en un seul appel avec create_email_queue:

  1. Créez une file d’attente privée avec l’adresse (par noreply@contoso.comexemple ), la livraison entrante None et la synchronisation côté serveur de la livraison sortante. Le nom de la file d’attente correspond à ce que les destinataires perçoivent comme l’expéditeur, donc nomme-le pour le portail plutôt que pour une personne.
  2. Approuvez l’adresse. Deux drapeaux doivent s’aligner et ils résident sur des enregistrements différents : l’approbation de l’adresse e-mail de la file d’attente, et la boîte mail approuvée par l’administrateur O365. Une file d’attente est créée en attente sur les deux.
  3. Testez et activez la boîte aux lettres dans le centre d’administration Power Platform → Paramètres → Configuration des e-mails → Mailboxs. C’est l’étape à faire manuellement, et c’est un seul bouton.

Important

Une boîte aux lettres non approuvée ou non testée échoue silencieusement. Dataverse accepte l’email, l’enregistre et ne le livre jamais — ce qui, du côté du portail, est indiscernable d’un envoi réussi. Rien ne se déclenche, rien n’est enregistré comme une erreur, et le premier signe de problème est un utilisateur qui dit n’avoir jamais reçu son lien de confirmation. Si les emails d’inscription n’arrivent pas, vérifiez le statut sortant de la boîte mail avant toute autre chose : Not Run signifie que cette étape a été manquée.

5. Garder les secrets dans le coffre à clés

Donnez à l’application une identité gérée, accordez-lui un accès de lecture à un coffre-fort, et placez l’URI de chaque secret dans les paramètres de l’application au lieu du secret lui-même. App Service résout la référence pour vous, et la valeur n’apparaît jamais dans la page de configuration, dans un script ou dans un journal de déploiement.

Quand un secret client expire — Entra est par défaut à un an — ajoutez une nouvelle version au coffre-fort et redémarrez l’application. Le paramètre de l’application lui-même ne change pas.

Le serveur MCP fait toute cette séquence : create_managed_identity crée une identité attribuée par l’utilisateur, enable_managed_identity l’attache à l’application, create_key_vault crée le coffre et accorde à cette identité un accès à la lecture, puis les outils secrets acceptent destination: "key-vault" — ce qui envoie un client secret fraîchement créé d’Entra directement dans le coffre-fort et ne laisse que la référence dans les paramètres de l’application. La valeur ne devient jamais un réglage littéral et ne passe jamais entre les mains de quiconque.

Important

Un nom de Key Vault est réservé 90 jours après la suppression. La suppression progressive est activée par défaut et ne peut pas être désactivée, donc supprimer un vault ne libère pas son nom — recréer un nom portant le même nom dans cette fenêtre nécessite une purge explicite, qui nécessite elle-même une autorisation et est irréversible. C’est la seule ressource ici qui n’est pas facilement irréalisable, alors choisissez le nom aussi délibérément que celui du service d’applications.

Note

Mieux encore, supprimez complètement le secret client Dataverse. Réglez D365__ManagedIdentityId l’identifiant client d’une identité gérée et le portail authentifie Dataverse sous cette identité, sans secret et donc rien à expirer. Il n’y a pas de vérification d’environnement ni de commutateur de compilation : le paramètre appartient à la configuration du service d’application plutôt qu’à appsettings.json, donc il est absent localement et présent lors du déploiement, et une compilation se comporte correctement dans les deux. Utilisez une identité assignée par l’utilisateur — une identité assignée par le système est créée et détruite avec l’application et diffère selon le slot de déploiement, donc reconstruire l’application crée une nouvelle identité et orpheline que l’utilisateur de l’application Dataverse a construite sur l’ancienne. L’identité nécessite toujours cet utilisateur de l’application, créé à partir de son identifiant d’application plutôt que de l’id principal affiché par le portail Azure en premier.

6. Publier

Publiez selon le framework, zipez la sortie, poussez le zip. Sur un portail React, la même dotnet publish chose construit aussi le SPA et le met en scène dans wwwroot.

Zipez le contenu du dossier publié, pas le dossier lui-même — App Service décompresse l’archive directement dans la racine du site, donc un répertoire imbriqué de premier niveau produit un site qui ne sert à rien.

La boîte de dialogue Publish de Visual Studio fait la même chose de manière interactive, et un workflow GitHub Actions ou Azure Pipelines le fait sur push. La seule étape supplémentaire pour un portail React est une étape de configuration Node en avance sur la compilation, puisque dotnet publish le CP est fourni à npm.

7. Pointer la licence vers l’URL déployée

La licence du site web est liée à une URL. Dans l’application modèle Power Portals Pro, ouvrez (ou créez) l’enregistrement Portal Web contenant votre clé de licence et réglez son URL sur l’URL de production du portail que vous venez de déployer — https://myportal.azurewebsites.net, ou votre domaine personnalisé si un domaine est mis devant.

Enregistrez uniquement l’URL de production . La validation accepte -devégalement , -test, -uat et -stage les hôtes suffixés, et les mêmes quatre comme sous-domaines principaux, donc les environnements inférieurs n’ont pas besoin d’enregistrement séparé. La page Licence contient la liste complète.

Important

Faites cela avant d’envoyer le trafic. Chaque point de terminaison de service de données vérifie la licence, donc tant que l’enregistrement n’existe pas et correspond à l’hôte, le portail affiche mais chaque appel de données revient 402.

8. Ajouter l’URI de redirection de production

Si le portail propose la connexion Microsoft, l’enregistrement de l’application de connexion ne connaît toujours que l’URI de redirection localhost. Ajoutez celui déployé à côté — Entra accepte plusieurs, donc le local continue de fonctionner :

Même schéma pour les autres fournisseurs sur leurs propres chemins de rappel (/signin-google, /signin-facebook). Ajouter un par environnement, et un par domaine personnalisé.

Emplacements de déploiement

Un emplacement de staging et un swap vous offrent une application échauffée et un retour instantané. Ce sont les seuls éléments qui valent vraiment la peine de quitter B1 — et la raison de le quitter quand on en a besoin, plutôt qu’à l’avance. Deux choses nécessitent des soins.

Les clés de protection des données sont par emplacement. ASP.NET Core conserve le trépositeur sous %HOME%, dont chaque emplacement a sa propre copie, donc un échange le remplace — et chaque cookie d’authentification émis par le slot précédent devient indéchiffrable. Tout le monde est déconnecté. Déplacez le porte-clés quelque part que les deux emplacements partagent avant de compter sur l’échange :

Marquez les réglages spécifiques à l’environnement comme réglages de slot pour qu’ils restent en arrière pendant un échange. L’URL de l’environnement Dataverse est celle qui prend le dessus : sans elle, échanger un emplacement de staging pointant vers un bac à sable favorise cette connexion bac à sable en production.

Mise en échelle,

L’échellement est une décision à prendre quand on mesure le besoin, pas lors de la provision. Une instance du niveau par défaut transporte une quantité surprenante de trafic de portail.

Faire tout cela depuis un agent IA

Le serveur Power Portals Pro MCP peut effectuer toutes les étapes de cette page. Liez le dossier à un abonnement une fois, sur un terminal — le lien appartient à ce dossier, donc plusieurs projets peuvent cibler différents clients en même temps, et rien ne change à l’échelle de la machine :

Note

Chaque outil qui modifie quoi que ce soit dans Azure vous demande d’abord de confirmer, et vous indique combien cela coûtera avant que vous ne répondiez — le chiffre mensuel réel pour votre région, avec une note indiquant que la liste de vente ignore tout accord d’entreprise ou réservation que vous détenez. Les outils qui ne lisent que ne demandent jamais. Le serveur n’utilise pas la ligne de ligne de ligne Azure et ne lit ni ne change jamais son état de connexion.

Dépannage