Deploying to Azure App Service

Un portal de Power Portals Pro es una aplicación Core de un solo ASP.NET según la pila que elijas, por lo que desplegarlo es algo ordinario dotnet publish para un servicio de aplicaciones ordinario. Esta página cubre los recursos a crear, los ajustes que lee el portal, qué sugerimos como predeterminados y los pocos pasos específicos de Power Portals Pro en lugar de ASP.NET Core.

Lo que estás desplegando

Ambas plantillas producen una aplicación web y una salida de publicación. No hay un host front-end separado que pueda montar, ni un recurso de sitio estático, ni un segundo servicio de aplicaciones:

Nota

Como el react publish se distribuye a npm, Node tiene que instalarse en cualquier máquina que se ejecute dotnet publish — tu portátil o el agente de compilación. El cliente de la plantilla pide Node ^20.19.0 || >=22.12.0. App Service nunca necesita Node; solo ve la salida compilada.

Valores predeterminados sugeridos

Puntos de partida, no reglas — pero estos son los que elegiríamos para un nuevo portal de producción.

1. Crear el servicio de aplicaciones

Tres comandos. Sustituid vuestros propios nombres — myportal se usa a lo largo de esta página.

El nombre de la aplicación web se convierte https://myportal.azurewebsites.net y tiene que ser globalmente único. Elígelo deliberadamente: a menos que pongas un dominio personalizado delante, es la URL a la que se vincula tu clave de licencia.

2. Establecer las opciones de plataforma

Estos son los que no tienen ningún valor por defecto para un portal.

3. Configuración

La configuración de la aplicación de App Service aparece como variables de entorno y anula appsettings.json, que es exactamente lo que quieres: deja el archivo intacto y establece aquí los valores por entorno.

Importante

Los secretos de usuario no viajan. Todo lo que almacenaste dotnet user-secrets durante el desarrollo solo está en tu máquina. Cada una de esas claves debe recrearse como configuración de aplicación — o como referencia de Key Vault — o la aplicación desplegada no arrancará.

Utiliza un guion bajo doble para el separador de sección: D365:ClientId se convierte D365__ClientIden . El formulario de dos puntos funciona en Windows App Service pero no en Linux, por lo que __ el formulario es para usar en todas partes.

Siempre es necesario

Obligatorio si activaste ese proveedor de inicio de sesión

Opcional

Nota

Las claves requeridas se leen con GetRequiredValue, así que una que falta se lanza durante el arranque en lugar de fallar más tarde en la primera llamada a Dataverse. En el servicio de aplicaciones que aparece como un sitio que nunca aparece — lee el flujo de registro, y la excepción nombra la clave.

4. Proporciona al portal una dirección desde la cual enviar

D365__EmailSenderEmailAddress es de donde proviene el correo de confirmación de cuenta y restablecimiento de contraseña, y el framework lo resuelve buscando un usuario de Dataverse con esa dirección, luego una cola, y después un equipo. Usa una cola. Su dirección necesita un buzón compartido en Exchange Online, que no toma licencia, y todo lo demás ocurre en Dataverse. En cambio, apuntar la configuración a una persona real te cuesta tres cosas:

Cuatro pasos: uno en Exchange y luego tres en Dataverse. El servidor MCP realiza los tres pasos de Dataverse en una sola llamada con create_email_queue, y check_email_sender dice qué paso falta cuando no llega correo:

  1. Crea un buzón compartido con la dirección, en el centro de administración de Exchange (Destinatarios → Buzones → Añadir un buzón compartido). No necesita licencia. Es lo que envía la sincronización del lado del servidor, así que sin él el último paso falla con un error al validar la configuración del buzón en el servidor remoto.
  2. Crea una cola privada con la dirección (por ejemplo, noreply@contoso.com), la entrega entrante Ninguna y la entrega saliente Sincronización del Lado del Servidor. El nombre de la cola es lo que los destinatarios ven como el remitente, así que ponle nombre para el portal en lugar de para una persona.
  3. Aprobar la dirección. Dos banderas deben coincidir y están en registros diferentes: la aprobación de la dirección de correo electrónico de la cola y la aprobación del buzón por el administrador de O365. Se crea una cola pendiente en ambas, y solo un administrador global de Office 365 o un administrador de Exchange puede aprobar la segunda.
  4. Prueba y activa el buzón en el centro de administración de Power Platform → Configuración → Configuración del correo electrónico → Buzones. Envía un mensaje de prueba desde la dirección a sí mismo, y el buzón solo se envía una vez que ha tenido éxito. create_email_queue Lo ejecuta y reporta el resultado.

Importante

Un buzón no aprobado o no probado falla silenciosamente. Dataverse acepta el correo, lo graba y nunca lo entrega — lo cual, desde el lado del portal, es indistinguible de un envío exitoso. Nada se lanza, nada se registra como error, y la primera señal de problema es un usuario que dice que nunca recibió su enlace de confirmación. Si los correos de registro no llegan, comprueba el estado saliente del buzón antes de nada: No Ejecutar significa que la prueba nunca se ejecutó, y Fallo con una alerta sobre validación de la configuración del buzón en el servidor remoto significa que la dirección no tiene buzón compartido en Exchange Online. check_email_sender Reporta ambos, con las alertas del buzón.

5. Guarda los secretos en la Bóveda de las Llaves

Dale a la app una identidad gestionada, concédele acceso de lectura a una bóveda y pon el URI de cada secreto en la configuración de la app en lugar del secreto en sí. App Service resuelve la referencia por ti, y el valor nunca aparece en la hoja de configuración, en un script o en un registro de despliegue.

Cuando un secreto de cliente expira — Entra por defecto tiene un año — añade una nueva versión a la bóveda y reinicia la aplicación. La configuración de la app en sí no cambia.

El servidor MCP hace toda esta secuencia: create_managed_identity crea una identidad asignada por el usuario, enable_managed_identity la anexa a la app, create_key_vault crea la bóveda y concede acceso a esa identidad por lectura, y las herramientas secretas luego aceptan destination: "key-vault" — lo que envía un secreto cliente recién creado desde Entra directamente a la bóveda y deja solo la referencia en la configuración de la app. El valor nunca se convierte en una configuración literal y nunca pasa por las manos de nadie. Los secretos que ya están en tus secretos de usuario van con push_secrets_to_key_vault, que te pide marcar cada uno antes de copiarlo y apunta a la configuración correspondiente de la app; check_deployment luego confirma que el secreto de cada referencia existe y que la identidad de la app puede leerlo.

Importante

Un nombre de Key Vault está reservado para 90 días después de la eliminación. La eliminación suave está activada por defecto y no puede desactivarse, por lo que eliminar una bóveda no libera su nombre — recrear una con el mismo nombre dentro de esa ventana requiere una purga explícita, que a su vez necesita permiso y es irreversible. Es el único recurso aquí que no es fácilmente inaccesible, así que elige el nombre tan deliberadamente como lo harías con el del servicio de aplicaciones.

Nota

Mejor aún, elimina por completo el secreto del cliente de Dataverse. Configura D365__ManagedIdentityId el id de cliente de una identidad gestionada y el portal se autentica a Dataverse como esa identidad, sin secreto y por tanto sin nada que caducar. No hay comprobación de entorno ni switch de compilación: la configuración pertenece a la configuración del App Service en lugar de appsettings.json, por lo que está ausente localmente y presente cuando se despliega, y una compilación se comporta correctamente en ambas. Usa una identidad asignada por el usuario — una asignada por el sistema se crea y destruye con la app y varía según el slot de despliegue, así que reconstruir la app crea una nueva identidad y deja huérfanos al usuario de la aplicación Dataverse construida sobre la antigua. La identidad sigue necesitando ese usuario de la aplicación, creado a partir de su id de aplicación en lugar del id principal que muestra el portal de Azure. Esto solo se aplica cuando el App Service y el entorno Dataverse están en el mismo tenant de Entra; si no lo están, véase Cuando Dataverse está en otro tenant más abajo.

Cuando Dataverse está en otro tenant

Todo lo anterior asume que el Servicio de Aplicaciones y el entorno Dataverse pertenecen al mismo tenant de Entra — el caso habitual cuando una organización aloja su propio portal. Si ejecutas el portal y tu cliente es propietario del entorno Dataverse, están en tenants diferentes y el asesoramiento de identidad cambia.

Importante

Una identidad gestionada no puede autenticarse a Dataverse en otro tenant por sí sola. Su principal de servicio pertenece al propio tenant de la suscripción y no puede ser consentido en el de nadie más, por lo que no hay nada contra lo que el Dataverse del cliente pueda crear un usuario de aplicación. No lo D365__ManagedIdentityId configures solo en esta forma: el portal recibiría un token y luego sería rechazado por cada llamada, lo que parece un rol de seguridad roto en lugar de un tipo de identidad incorrecto. Sin embargo, puede ser la credencial de un registro de aplicación multi-inquilino, que es lo que cruza los inquilinos: véase la primera opción a continuación.

El portal inicia sesión como un registro de aplicación para el que el inquilino del cliente tiene un principal de servicio. Hay tres formas de organizarlo, y difieren en quién controla la vida útil de la credencial:

Elijas lo que elijas, un administrador en el tenant del cliente debe dar su consentimiento para el registro una vez. Eso es lo que crea el principal de servicio allí: un objeto que lleva tu id de cliente, al que su Dataverse puede vincular a un usuario de la aplicación. Envíales este enlace:

Importante

El consentimiento viene antes que el usuario de la aplicación, no después. Hasta que ocurra, no hay un principal de servicio en el tenant del cliente, por lo que crear el usuario de la aplicación Dataverse falla con un error sobre una aplicación desconocida — que no menciona ni a los inquilinos ni el consentimiento, y es el punto más confuso de este camino. No puedes realizar este paso por ellos: es su inquilino quien concede acceso a un registro que no posee, así que necesita su autoridad en lugar de la tuya.

Pon ese secreto en Key Vault en lugar de en una aplicación. Es una credencial contra los datos de otra persona, y una configuración literal es legible para cualquiera que tenga Contributor en la app y viaja con cualquier exportación de la configuración. check_deployment Repórtala si no lo haces.

6. Publicar

Publicar dependiente del framework, comprimir la salida y empujar el zip. En un portal React lo mismo dotnet publish también construye el SPA y lo está en etapas en wwwroot.

Comprime el contenido de la carpeta de publicación, no la carpeta en sí: App Service desempaqueta el archivo directamente en la raíz del sitio, así que un directorio anidado de nivel superior produce un sitio que no sirve para nada.

El diálogo Publish de Visual Studio hace lo mismo de forma interactiva, y un flujo de trabajo de GitHub Actions o Azure Pipelines lo hace en push. El único paso extra para un portal React es un paso de configuración de Node antes de la compilación, ya que dotnet publish se despliega a npm.

7. Apunta la licencia a la URL desplegada

La licencia del sitio web está vinculada a una URL. En la aplicación orientada a modelos Power Portals Pro, abre (o crea) el registro del Portal que contiene tu clave de licencia y establece su URL en la URL de producción del portal que acabas de desplegar — https://myportal.azurewebsites.net, o en tu dominio personalizado si uno va delante de él.

Registra solo la URL de producción . La validación también acepta -dev, -test, -uat, -stage y -prod hosts con sufijo, y los mismos cinco que los subdominios principales, por lo que otros entornos no necesitan un registro separado. La página de Licencias tiene la lista completa.

Importante

Haz esto antes de enviar el tráfico. Cada endpoint de servicio de datos revisa la licencia, así que hasta que el registro exista y coincida con el host, el portal se renderiza pero todas las llamadas de datos regresan 402.

8. Añadir el URI de redirección de producción

Si el portal ofrece inicio de sesión con Microsoft, el registro de la app de inicio de sesión solo conoce el URI de redirección de tu localhost. Añade el desplegado junto a él — Entra acepta varios, así que el local sigue funcionando:

Mismo patrón para los otros proveedores en sus propias rutas de callback (/signin-google, /signin-facebook). Añade uno por entorno y uno por dominio personalizado.

Ranuras de despliegue

Un espacio de staging y un swap te dan una app de calentamiento y un retroceso instantáneo. Son lo único por lo que realmente merece la pena dejar Basic — y la razón para dejarlo cuando los necesitas, y no por adelantado. Hay dos cosas que hay que cuidar.

Las claves de protección de datos son por ranura. ASP.NET Core mantiene el llavero bajo %HOME%, del cual cada ranura tiene su propia copia, por lo que un swap lo reemplaza — y cada cookie de autenticación emitida por la ranura anterior se vuelve indescifrable. Todos están desconectados. Mueve el llavero a un lugar donde compartan ambas ranuras antes de depender del intercambio:

Marca los ajustes específicos del entorno como ajustes de ranura para que se queden durante el intercambio. La URL del entorno de Dataverse es la que más afecta: sin ella, cambiar una ranura de staging que apunta a un sandbox promueve esa conexión sandbox en producción.

Escalando

Escalar es una decisión que debes tomar cuando mides la necesidad, no cuando provisionas. Una instancia del nivel por defecto tiene una sorprendente cantidad de tráfico de portal.

Todo esto desde un agente de IA

El servidor MCP de Power Portals Pro puede realizar todos los pasos de esta página. Vincula la carpeta a una suscripción una vez, en un terminal — la vinculación pertenece a esa carpeta, así que varios proyectos pueden dirigirse a diferentes clientes al mismo tiempo, y nada cambia a nivel de máquina:

Nota

Cada herramienta que cambia algo en Azure te muestra lo que hará antes de que te pidan confirmar, incluyendo cuánto costará — la cifra mensual real para tu región, con una nota de que la lista minorista ignora cualquier Acuerdo Empresarial o reserva que tengas. Las herramientas que solo leen nunca lo solicitan. El servidor no usa la CLI de Azure y nunca lee ni cambia su estado de inicio.

Resolución de problemas