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. Es la única opción que no necesita ningún trabajo en Exchange: el buzón que Dataverse crea para una cola apunta al perfil existente de Exchange Online de la organización, así que no hay buzón que provisionar ni licencia para comprar la dirección. Apuntar la configuración a una persona real te cuesta tres cosas:

Tres pasos, todos dentro de Dataverse. El servidor MCP realiza los dos primeros en una sola llamada con create_email_queue:

  1. 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.
  2. Aprobar la dirección. Dos banderas tienen que 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.
  3. Prueba y activa el buzón en el centro de administración de Power Platform → Configuración → Configuración del correo electrónico → Buzones. Este es el único paso que hay que hacer a mano, y es un solo botón.

Importante

Un buzón no aprobado o no probado falla silenciosamente. Dataverse acepta el correo, lo registra 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 que un usuario diga 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 se ha pasado este paso.

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 asocia a la app, create_key_vault crea la bóveda y concede acceso a esa identidad por lectura, y las herramientas secretas luego la aceptan destination: "key-vault" — lo que envía un secreto cliente recién creado de 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.

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. Si se configura D365__ManagedIdentityId el id de cliente de una identidad gestionada, el portal se autentica a Dataverse como esa identidad, sin secreto y por tanto sin nada que caduque. 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 que el usuario de la aplicación Dataverse construyó 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.

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 y -stage hosts con sufijo, y los mismos cuatro como subdominios iniciales, por lo que los entornos inferiores 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 B1 — y la razón para dejarlo cuando los necesitas, y no antes de hacerlo. Hay dos cosas que necesitan cuidado.

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 pide confirmar primero y te dice cuánto costará antes de que respondas — la cifra mensual real de tu región, con una nota de que la lista de tiendas ignora cualquier Acuerdo de Empresa 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