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. Son adresse nécessite une boîte aux lettres partagée dans Exchange Online, qui ne prend aucune licence, et tout le reste se passe dans Dataverse. Pointer le paramètre vers une personne réelle vous coûte plutôt trois choses :

Quatre étapes : une dans Exchange, puis trois dans Dataverse. Le serveur MCP effectue les trois étapes Dataverse en un seul appel avec create_email_queue, et check_email_sender indique quelle étape manque lorsque le courrier n’arrive pas :

  1. Créez une boîte aux lettres partagée avec l’adresse, dans le centre d’administration Exchange (Destinataires → Boîte aux lettres → Ajouter une boîte aux lettres partagée). Elle ne nécessite pas de licence. C’est ce que la synchronisation côté serveur envoie, donc sans elle, la dernière étape échoue avec une erreur concernant la validation de la configuration de la boîte aux lettres dans le serveur distant.
  2. 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.
  3. 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 aux lettres approuvée par l’administrateur O365. Une file d’attente est créée en attente sur les deux, et seul un administrateur global Office 365 ou un administrateur Exchange peut approuver le second.
  4. Tester et activer la boîte aux lettres dans le centre d’administration Power Platform → Paramètres → Configuration des e-mails → Boîtes aux lettres. Elle envoie un message test de l’adresse vers elle-même, et la boîte ne l’envoie qu’une fois qu’elle a réussi. create_email_queue L’exécute et rapporte le résultat.

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 jette, rien n’est enregistré comme une erreur, et le premier signe de problème est un utilisateur disant qu’il n’a jamais reçu son lien de confirmation. Si les emails d’enregistrement n’arrivent pas, vérifiez le statut sortant de la boîte mail avant toute autre chose : Not Run signifie que le test n’a jamais été exécuté, et Failure avec une alerte concernant la validation de la configuration de la boîte mail dans le serveur distant signifie que l’adresse n’a pas de boîte partagée dans Exchange Online. check_email_sender Signale les deux, avec les alertes de la boîte aux lettres.

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é l’accès à la lecture, puis les outils secrets acceptent destination: "key-vault" — ce qui envoie un secret client 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 personne. Les secrets déjà présents dans vos secrets utilisateur vont avec push_secrets_to_key_vault, qui vous demande de cocher chacun avant qu’il ne soit copié et pointe les paramètres correspondants de l’application vers eux ; check_deployment puis confirme que chaque secret de référence existe et que l’identité de l’application peut le lire.

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 sur l’ID client d’une identité gérée et le portail authentifie Dataverse sous cette identité, sans secret et donc sans rien à expirer. Il n’y a pas de vérification d’environnement ni de commutateur de build : 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 version 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 l’utilisateur de l’application Dataverse construite sur l’ancienne. L’identité nécessite toujours cet utilisateur applicatif, créé à partir de son id d’application plutôt que de l’id principal affiché par le portail Azure en premier. Cela ne s’applique que lorsque l’App Service et l’environnement Dataverse sont dans le même locataire Entra ; s’ils ne le sont pas, voir Quand Dataverse est dans un autre locataire ci-dessous.

Lorsque Dataverse est dans un autre locataire

Tout ce qui précède suppose que le service d’applications et l’environnement Dataverse appartiennent au même locataire Entra — le cas habituel lorsqu’une organisation héberge son propre portail. Si vous gérez le portail et que votre client possède l’environnement Dataverse, ils sont dans des locataires différents, et l’avis d’identité change.

Important

Une identité gérée ne peut pas s’authentifier à Dataverse dans un autre locataire seul. Son principal de service appartient au locataire propre de l’abonnement et ne peut être consenti à celui de quelqu’un d’autre, il n’y a donc rien contre lequel le Dataverse du client puisse créer un utilisateur applicatif. Ne le D365__ManagedIdentityId définissez pas seul sous cette forme — le portail recevrait un jeton puis serait refusé à chaque appel, ce qui ressemble à un rôle de sécurité défaillant plutôt qu’à un mauvais type d’identité. Il peut cependant être l’accréditation d’une inscription multi-locataire, ce qui est ce qui traverse les locataires : voir la première option ci-dessous.

Le portail se connecte comme une inscription d’application pour laquelle le locataire du client a un principal de service. Il existe trois façons de gérer cela, et elles diffèrent quant à qui contrôle la durée de vie de l’identifiant :

Quel que soit votre choix, un administrateur du locataire du client doit consentir une seule fois à l’enregistrement. C’est ce qui crée le principal du service — un objet portant votre identifiant client, auquel leur Dataverse peut ensuite lier un utilisateur d’application. Envoyez-leur ce lien :

Important

Le consentement vient avant l’utilisateur de l’application, pas après. Tant que cela n’a pas eu lieu, il n’y a pas de principal de service dans le locataire du client, donc la création de l’utilisateur de l’application Dataverse échoue à cause d’une erreur concernant une application inconnue — qui ne mentionne ni les locataires ni le consentement, et constitue le point le plus déroutant sur ce chemin. Vous ne pouvez pas effectuer cette étape pour eux : c’est leur locataire qui accorde l’accès à une inscription qu’il ne possède pas, donc il a besoin de leur autorité plutôt que de la vôtre.

Mettez ce secret dans Key Vault plutôt que dans un cadre applicatif. C’est une attestation sur les données de quelqu’un d’autre, et un réglage littéral est lisible pour quiconque utilise Contributor sur l’application et voyage avec toute exportation de la configuration. check_deployment Signalez-le si ce n’est pas le cas.

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, -stage et -prod les hôtes suffixés, ainsi que les mêmes cinq que les sous-domaines principaux, donc les autres environnements n’ont pas besoin d’enregistrement séparé. La page Licences 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 améliorée et un retour en arrière instantané. Ce sont la seule chose qui vaut vraiment la peine de quitter Basic — et la raison de le laisser quand on en a besoin, plutôt qu’à l’avance. Deux choses doivent être entretenues.

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 montre ce qu’il fera avant qu’on ne vous demande de confirmer, y compris le coût mensuel réel pour votre région, avec une note indiquant que la liste de détail ignore tout accord d’entreprise ou réservation que vous détenez. Les outils qui ne lisent jamais de notification. 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