Deploying to Azure App Service

Um portal Power Portals Pro é um único aplicativo Core ASP.NET qual for a pilha escolhida, então implantá-lo é algo comum dotnet publish para um App Service comum. Esta página aborda os recursos a serem criados, as configurações que o portal lê, o que sugerimos como padrão e os poucos passos específicos do Power Portals Pro em vez do ASP.NET Core.

O que você está implantando

Ambos os templates produzem uma aplicação web e uma saída de publicação. Não há um host front-end separado para montar, nenhum recurso de site estático e nenhum segundo App Service:

Nota

Como o react publish shells para npm, o Node precisa ser instalado em qualquer máquina que rode dotnet publish — seu laptop ou o agente de compilação. O cliente do template pede o Node ^20.19.0 || >=22.12.0. O próprio serviço de aplicativos nunca precisa do Node; ele só vê a saída construída.

Padrões sugeridos

Pontos de partida, não regras — mas são esses os que escolheríamos para um novo portal de produção.

1. Criar o Serviço de Aplicativo

Três comandos. Substitua seus próprios nomes — myportal é usado ao longo desta página.

O nome do aplicativo web se torna https://myportal.azurewebsites.net e precisa ser globalmente único. Escolha deliberadamente: a menos que você coloque um domínio personalizado na frente, é a URL à qual sua chave de licença fica vinculada.

2. Defina as opções da plataforma

Esses são os que têm os padrões errados para um portal.

3. Configuração

As configurações do aplicativo de aplicativo aparecem como variáveis de ambiente e sobrescrevem appsettings.json, que é exatamente o que você quer: deixe o arquivo como está e defina os valores por ambiente aqui.

Importante

Segredos de usuário não viajam. Tudo com que você armazenou dotnet user-secrets durante o desenvolvimento fica apenas na sua máquina. Cada uma dessas chaves precisa ser recriada como uma configuração de aplicativo — ou como referência ao Key Vault — ou o aplicativo implantado não vai iniciar.

Use um duplo sublinhado para o separador de seção: D365:ClientId torna-se D365__ClientId. O formulário dos dois-pontos funciona no Windows App Service, mas não no Linux, então __ o formulário a ser usado em todos os lugares é o caso.

Sempre obrigatório

Obrigatório se você ativou esse provedor de login

Opcional

Nota

As chaves necessárias são lidas com GetRequiredValue, então uma que falta é lançada durante a inicialização em vez de falhar depois na primeira chamada Dataverse. Em um serviço de aplicativos que aparece como um site que nunca aparece — leia o fluxo de log, e a exceção nomeia a chave.

4. Dê ao portal um endereço para enviar

D365__EmailSenderEmailAddress é de onde vem o e-mail de confirmação de conta e redefinição de senha, e o framework resolve isso procurando um usuário do Dataverse com esse endereço, depois uma fila, depois uma equipe. Use uma fila. O endereço dele precisa de uma caixa de correio compartilhada no Exchange Online, que não aceita licença, e todo o resto acontece no Dataverse. Apontar a configuração para uma pessoa real custa três coisas:

Quatro etapas: uma no Exchange e depois três no Dataverse. O servidor MCP faz as três etapas do Dataverse em uma única chamada com create_email_queue, e check_email_sender diz qual etapa está faltando quando o e-mail não chega:

  1. Crie uma caixa de correio compartilhada com o endereço, no centro de administração do Exchange (Destinatários → Caixas de Correio → Adicionar uma caixa de correio compartilhada). Não precisa de licença. É o que a sincronização do lado do servidor envia, então sem ela a última etapa falha com um erro ao validar a configuração da caixa de correio no servidor remoto.
  2. Crie uma fila privada com o endereço (por exemplo noreply@contoso.com), a entrega recebida Nenhum e a Sincronização do Lado do Servidor da entrega de saída. O nome da fila é o que os destinatários veem como remetente, então nomeie para o portal em vez de uma pessoa.
  3. Aprove o endereço. Dois flags precisam coincidir e eles ficam em registros diferentes: a aprovação do endereço de e-mail da fila e a caixa de correio aprovada pelo administrador do O365. Uma fila é criada pendente em ambos, e apenas um Administrador Global do Office 365 ou um Administrador do Exchange pode aprovar o segundo.
  4. Teste e ative a caixa de correio no centro de administração do Power Platform → Configurações → Configuração de e-mails → Caixas de Correio. Ela envia uma mensagem de teste do endereço para si mesma, e a caixa de correio só envia depois que ela tiver sucesso. create_email_queue Executa e reporta o resultado.

Importante

Uma caixa de correio não aprovada ou não testada falha silenciosamente. O Dataverse aceita o e-mail, registra-o e nunca o entrega — o que, do lado do portal, é indistinguível de um envio bem-sucedido. Nada é lançado, nada é registrado como erro, e o primeiro sinal de problema é um usuário dizendo que nunca recebeu o link de confirmação. Se os e-mails de registro não estiverem chegando, verifique o status de saída da caixa de correio antes de qualquer outra coisa: Não Executa significa que o teste nunca foi executado, e Falha com um alerta sobre validação da configuração da caixa de correio no servidor remoto significa que o endereço não tem caixa compartilhada no Exchange Online. check_email_sender Reporta ambos, com os alertas da caixa de correio.

5. Guarde os segredos no Cofre da Chave

Dê ao app uma identidade gerenciada, conceda acesso de leitura a um cofre e coloque o URI de cada segredo na configuração do app em vez do segredo em si. O App Service resolve a referência para você, e o valor nunca aparece na blade de configuração, em um script ou em um log de implantação.

Quando um segredo do cliente expira — o Entra tem um ano por padrão — adicione uma nova versão ao cofre e reinicie o app. A configuração do app em si não muda.

O servidor MCP faz toda essa sequência: create_managed_identity cria uma identidade atribuída pelo usuário, enable_managed_identity anexa ao app, create_key_vault cria o cofre e concede acesso à leitura dessa identidade, e as ferramentas secretas então aceitam destination: "key-vault" — o que envia um segredo recém-criado do Entra direto para o cofre e deixa apenas a referência nas configurações do app. O valor nunca se torna uma configuração literal e nunca passa pelas mãos de ninguém. Segredos já presentes nos seus segredos de usuário vão com push_secrets_to_key_vault, que pede para você marcar cada um antes de ser copiado e aponta as configurações correspondentes do app para eles; check_deployment depois confirma que o segredo de cada referência existe e que a identidade do app pode lê-lo.

Importante

Um nome de Cofre de Chaves é reservado por 90 dias após a exclusão. A exclusão suave está ativada por padrão e não pode ser desativada, então excluir um cofre não libera seu nome — recriar um com o mesmo nome dentro dessa janela exige uma purga explícita, que por si só precisa de permissão e é irreversível. É o único recurso aqui que não é facilmente desfazível, então escolha o nome com a mesma deliberação que escolheria o do App Service.

Nota

Melhor ainda, elimine completamente o secreto do cliente Dataverse. Defina D365__ManagedIdentityId para o id de cliente de uma identidade gerenciada e o portal autentica Dataverse como essa identidade, sem segredo e, portanto, sem nada a expirar. Não há verificação de ambiente nem switch de build: a configuração pertence à configuração do App Service e não appsettings.json, então está ausente localmente e presente quando implantada, e uma build se comporta corretamente em ambos. Use uma identidade atribuída pelo usuário — uma identidade atribuída pelo sistema é criada e destruída junto com o app e varia conforme o slot de implantação, então reconstruir o app cria uma nova identidade e deixa órfãos que o usuário do aplicativo Dataverse construiu sobre a antiga. A identidade ainda precisa desse usuário da aplicação, criada a partir do id de aplicação em vez do id principal que o portal Azure mostra primeiro. Isso se aplica apenas quando o App Service e o ambiente Dataverse estão no mesmo tenant do Entra; se não estiverem, veja Quando o Dataverse está em outro tenant abaixo.

Quando o Dataverse está em outro tenant

Tudo acima assume que o App Service e o ambiente Dataverse pertencem ao mesmo tenant Entra — o caso usual quando uma organização hospeda seu próprio portal. Se você executa o portal e seu cliente é dono do ambiente Dataverse, eles estão em tenants diferentes, e o orientamento de identidade muda.

Importante

Uma identidade gerenciada não pode autenticar o Dataverse em outro tenant sozinha. Seu principal de serviço pertence ao próprio tenant da assinatura e não pode ser consentido no de outra pessoa, então não há nada contra o qual o Dataverse do cliente possa criar um usuário de aplicativo. Não defina D365__ManagedIdentityId sozinho nesse formato — o portal receberia um token e seria recusado a cada chamada, o que soa como um papel de segurança quebrado, e não como o tipo errado de identidade. No entanto, ele pode ser a credencial de um registro de app multi-locatário, que é o que cruza os inquilinos: veja a primeira opção abaixo.

O portal faz login como um registro de aplicativo para o qual o locatário do cliente tem um principal de serviço. Existem três formas de organizar isso, e elas diferem quanto a quem controla a vida útil da credencial:

Seja qual for a sua escolha, um administrador no tenant do cliente precisa consentir com o registro uma vez. É isso que cria o principal de serviço ali — um objeto carregando seu ID de cliente, ao qual o Dataverse deles pode então vincular um usuário de aplicativo. Envie este link para eles:

Importante

O consentimento vem antes do usuário da aplicação, não depois. Até que isso aconteça, não há um principal de serviço no locatário do cliente, então criar o usuário da aplicação Dataverse falha com um erro sobre uma aplicação desconhecida — que não menciona nem locatários nem consentimento, e é o ponto mais confuso nesse caminho. Você não pode realizar essa etapa para eles: é o locatário deles concedendo acesso a um registro que não possuem, então precisa da autoridade deles e não da sua.

Coloque esse segredo no Key Vault em vez de em uma configuração de aplicativo. É uma credencial contra os dados de outra pessoa, e uma configuração literal pode ser legida por qualquer pessoa com Contribuidor no app e viaja com qualquer exportação da configuração. check_deployment Reporte se não fizer isso.

6. Publicar

Publicar dependente do framework, zipar a saída, empurrar o zip. Em um portal React, o mesmo dotnet publish também constrói o SPA e o posiciona em wwwroot.

Zipe o conteúdo da pasta de publicação, não a pasta em si — o App Service desembala o arquivo diretamente na raiz do site, então um diretório aninhado de nível superior produz um site que não serve a nada.

O diálogo Publish do Visual Studio faz a mesma coisa de forma interativa, e um fluxo de trabalho GitHub Actions ou Azure Pipelines faz isso no push. O único passo extra para um portal React é um passo de configuração do Node antes da build, já que dotnet publish o CPL é enviado para o npm.

7. Apontar a licença para a URL implantada

A licença do site está vinculada a uma URL. No aplicativo orientado por modelos Power Portals Pro, abra (ou crie) o registro do site do portal que contém sua chave de licença e defina sua URL para a URL de produção do portal que você acabou de lançar — https://myportal.azurewebsites.net, ou seu domínio personalizado, se estiver indo à frente dele.

Registre apenas a URL de produção . Validação também aceita -dev, -test, -uat, -stage e -prod hosts sufixos, e os mesmos cinco que subdomínios iniciais, então outros ambientes não precisam de registro separado. A página de Licenciamento tem a lista completa.

Importante

Faça isso antes de enviar tráfego. Todo endpoint de serviço de dados verifica a licença, então até que o registro exista e corresponda ao host, o portal renderiza mas toda chamada de dados retorna 402.

8. Adicionar o URI de redirecionamento de produção

Se o portal oferece login Microsoft, o registro do aplicativo de login ainda só conhece o URI do seu redirecionamento localhost. Adicione o portal implantado junto — o Entra aceita vários, então o local continua funcionando:

Mesmo padrão para os outros provedores em seus próprios caminhos de callback (/signin-google, /signin-facebook). Adicione um por ambiente e um por domínio personalizado.

Espaços de implantação

Um slot de staging e uma troca dão um aplicativo aquecido e um retrocesso instantâneo. Eles são a única coisa que realmente vale a pena deixar o Basic — e o motivo para sair quando você precisar, e não antecipadamente. Duas coisas precisam de cuidados.

As chaves de Proteção de Dados são por slot. ASP.NET Core mantém o chaveiro sob %HOME%, do qual cada slot tem sua própria cópia, então uma troca o substitui — e todo cookie de autenticação emitido pelo slot anterior se torna indecifrável. Todos estão desconectados. Mova o chaveiro para algum lugar onde ambos os slots sejam compartilhados antes de depender da troca:

Marque as configurações específicas do ambiente como configurações de slot para que fiquem para o lado durante a troca. A URL do ambiente do Dataverse é a que mais funciona: sem ela, trocar um slot de staging que aponta para um sandbox promove essa conexão sandbox para a produção.

Escalonamento

Escalar é uma decisão a ser tomada quando você mede a necessidade dela, não quando você provisiona. Uma instância do nível padrão carrega uma quantidade surpreendente de tráfego de portais.

Fazendo tudo isso a partir de um agente de IA

O servidor MCP Power Portals Pro pode realizar todas as etapas desta página. Vincule a pasta a uma assinatura uma vez, em um terminal — o vínculo pertence a essa pasta, então vários projetos podem direcionar clientes diferentes ao mesmo tempo, e nada muda em toda a máquina:

Nota

Toda ferramenta que altera algo no Azure mostra o que ela fará antes de ser solicitado a confirmar, incluindo o valor real mensal para sua região, com uma nota de que a lista de varejo ignora qualquer Acordo de Empresa ou reserva que você tenha. Ferramentas que apenas leem nunca solicitam. O servidor não usa a CLI do Azure e nunca lê ou altera seu estado de logado.

Solução de problemas