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, e então uma equipe. Use uma fila. É a única opção que não precisa de nenhum trabalho no Exchange: a caixa de correio que o Dataverse cria para uma fila aponta para o perfil existente do Exchange Online da organização, então não há caixa de correio para provisionar nem licença para comprar para o endereço. Apontar a configuração para uma pessoa real, em vez disso, custa três coisas:

Três etapas, todas dentro do Dataverse. O servidor MCP faz as duas primeiras em uma única chamada com create_email_queue:

  1. 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.
  2. 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.
  3. 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. Essa é a única etapa que precisa ser feita manualmente, e é um único botão.

Importante

Uma caixa de correio não aprovada ou não testada falha silenciosamente. O Dataverse aceita o e-mail, grava-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 antes de qualquer outra coisa: Não Executar significa que essa etapa foi perdida.

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 cliente 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.

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 cliente secreto do Dataverse. Defina D365__ManagedIdentityId para o id de cliente de uma identidade gerenciada e o portal autentica o 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 em vez de appsettings.json, então ela está ausente localmente e presente quando implantada, e uma build se comporta corretamente em ambas. 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 do aplicativo, criado a partir do id de aplicação em vez do id principal que o portal Azure mostra primeiro.

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 e -stage hosts com sufixo, e os mesmos quatro como subdomínios iniciais, então ambientes inferiores 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 sair do B1 — 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 pede para você confirmar primeiro, e informa quanto vai custar antes de você responder — o valor mensal real da 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